CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS. Propuesta de Modelo de Aplicación y Uso Potencial

Transcripción

1 CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS Propuesta de Modelo de Aplicación y Uso Potencial Alumno APU Jonatan Matías Ponzo Director Mg. Diego Azcurra TRABAJO FINAL PRESENTADO PARA OBTENER EL GRADO DE LICENCIADO EN SISTEMAS DEPARTAMENTO DE DESARROLLO PRODUCTIVO Y TECNOLOGICO UNIVERSIDAD NACIONAL DE LANUS 2013

2

3 RESUMEN La aplicación sistemática, disciplinada y cuantificable de procesos [IEEE, 1990] permite llevar adelante proyectos de desarrollo de sistemas de manera efectiva y eficiente. La ausencia de una metodología de planificación y control puede llevar a la no conclusión de un proyecto o a la elaboración de un sistema que no satisface las expectativas y requerimientos del cliente. En la actualidad, se identifican diversos modelos que asisten al proceso de ingeniería de requisitos y modelado de sistemas embebidos en la base de conocimiento referente al área de estudio, aunque todos ellos carecen del enfoque necesario para abordar la gestión integral de los proyectos. Esta carencia sin embargo, se encuentra ampliamente cubierta en el ámbito de la Ingeniería de Software. Es por ello que este trabajo final de licenciatura busca seleccionar y analizar algunos de los principales modelos de procesos de sistemas informáticos -preferentemente embebidos- disponibles en la actualidad y generar a partir de su combinación, adaptación y complemento, un nuevo modelo de gestión integral de proyectos destinados al control de Robots Autónomos Móviles basados en Arquitecturas de Sistemas Embebidos que cubra la carencia identificada.

4

5 ABSTRACT Systematic, disciplined and quantifiable application of processes [IEEE, 1990] allow the carry of systems development projects effectively and efficiently. The lack of planning and control methodology might lead to non-completion of a project or the development of a product that does not meet the expectations and requirements of the client. Nowadays, there are several models that assist in the requirements engineering and embedded systems modeling but they all lack the focus needed to carry out the management of the entire projects. This lack, however, is widely covered in the Software Engineering field. This paper is intended to select and analyze some of the major informatics system's process-based methodologies, preferably embedded systems, available nowadays and to develop, based on their combination and adaptation, a new embedded systems controlled robots's integrated management model.

6

7 INDICE ÍNDICE 1. INTRODUCCIÓN Contexto del Trabajo Final Objetivo del Trabajo Final Objetivo general Objetivos particulares Visión General del Trabajo Final 3 2. ESTADO DE LA CUESTIÓN Modelos de procesos para sistemas informáticos Modelo de requisitos para sistemas embebidos Goal-oriented patterns for UML-Based modeling of embedded systems requirements IEEE Standard for Developing Software Life Cycle Processes Esquema Comparativo 9 3. DESCRIPCIÓN DEL PROBLEMA Identificación del problema de investigación Problema abierto Sumario de investigación SOLUCIÓN Modelo de gestión integral de proyectos destinados al control de Robots Autónomos Móviles basados en Arquitecturas de Sistemas Embebidos Generalidades Influencias Estructura general del modelo Procesos, sub-procesos, actividades, documentos de salida y técnicas sugeridas Descripción y objetivos de los procesos, sub-procesos y actividades propuestas Procedimiento de implementación de la solución Selección de un modelo de ciclo de vida Creación del ciclo de vida del proyecto, Mapa de actividades Secuenciamiento de actividades Asignación de documentos de salida Iniciación del proyecto PRUEBA DE CONCEPTO Descripción de la prueba de concepto: inspección de cultivos en invernadero Descripción del negocio Descripción del producto a desarrollar 42 i

8 INDICE 5.2. Implementación de la prueba de concepto CONCLUSIONES Aportaciones del Trabajo Final Futuras Líneas de Investigación REFERENCIAS 47 ANEXO I RELEVAMIENTO DE HARDWARE Introducción a las familias seleccionadas Microprocesador. Arquitectura, frecuencias disponibles y características principales Dimensiones, alimentación y condiciones de ambiente soportadas Memoria de datos y programa Interfaces y puertos de entrada / salida disponibles Módulos de expansión Programación Disponibilidad en el mercado local e internacional y costos Principales mercados de aplicación, ventajas y desventajas Matriz comparativa Referencias 113 ANEXO II MATRIZ COMPARATIVA 117 ANEXO III MODELADO DE SISTEMAS EMBEBIDOS Modelo de requisitos para sistemas embebidos Introducción Descripción del modelo Categorías y subcategorías Disponibilidad de objetos Convocación y demostración Selección de alternativas Solicitud de acceso Aporte (entrada respuesta) Verificación / Decisión Intervención de agentes Acción del agente Transferencia / Actualización Interrupción / Restitución / Conservación Despeño / Cambio Precio y Costos Descripción y caracterización de los agentes 136 ii

9 INDICE 2. Goal-Oriented Patterns for UML-Based Modeling of Embedded Systems Requirements Introducción Notación del modelo basado en metas Análisis del comportamiento Patrones COBRA Plantillas COBRA Análisis de consistencia en la construcción Consistencia estructural por construcción Consistencia en el comportamiento mediante análisis Standard IEEE para el Desarrollo de procesos de ciclo de vida de Software Introducción Descripción general del modelo Descripción detallada de subprocesos 151 4, Referencias 161 ANEXO IV DOCUMENTOS DEL PROYECTO 163 Plan de iniciación del proyecto 165 Plan de proyecto 187 Especificación de requisitos 219 Especificación de diseño 257 Manual de operaciones 279 Reporte de instalación y operación del sistema 293 Reporte de evaluación del sistema 305 Informe de estado de la configuración 323 Informe de garantía de calidad 335 iii

10 INDICE iv

11 INDICE ÍNDICE DE TABLAS Tabla 2.2. Esquema comparativo de modelos 9 ÍNDICE DE FIGURAS Figura 4.1. Secuencia de implementación del modelo solución. 40 NOMENCLATURA ASE COBRA IR PyMEs RAM SC SE SE-RAM SI TFL UML Arquitecturas de Sistemas Embebidos Constraints and OBjects for Requirements Analysis Ingeniería de Requerimientos Pequeñas y Medianas Empresas Robot Autónomo Móvil Sistema de Control Sistemas Embebidos Sistemas Embebidos utilizables en Robótica Autónoma Móvil Sistemas Informáticos Trabajo Final de Licenciatura Unified Modeling Languaje v

12 INDICE vi

13 INTRODUCCION 1. INTRODUCCION En este Capítulo se plantea el contexto del trabajo final (sección 1.1), se establece su objetivo (sección 1.2), y se resume su estructura (sección 1.3) CONTEXTO DEL TRABAJO FINAL En un contexto mundial donde la tecnología avanza a pasos agigantados y se inserta en todos los ámbitos de la sociedad, desde hogares y escuelas hasta medios de comunicación, industrias y organizaciones de toda índole, es imperativo adaptarse y acompañar el crecimiento intentando anticipar los fenómenos de cambio. En muchos casos la introducción de nuevas tecnologías en algunos de estos ámbitos es sinónimo de progreso y ventaja competitiva. A la hora de pensar en el sector industrial, particularmente en PyMEs, principales impulsoras de un país que atraviesa el inicio de un proceso de cambio de paradigma productivo solo comparable con el atravesado durante la década de 1880 [Tangelson, 2004], podemos destacar a la Robótica como una de las principales disciplinas tecnológicas potencialmente aplicables al sector, en pos de su evolución y la búsqueda del aumento de los niveles de eficiencia en la productividad. La Robótica es una disciplina que busca desarrollar unidades electrónicas y mecánicas destinadas a llevar a cabo un conjunto de tareas de manera automatizada, precisa y controlada. La Robótica Autónoma particularmente, es una sub-disciplina de la Robótica convencional enfocada en dotar al robot de un cierto nivel de inteligencia que le permita desempeñarse sin intervención humana. Un Robot autónomo se compone de una estructura electrónica-mecánica [Azcurra et al, 2011] basada en sensores y actuadores y una placa base con un Sistema Embebido encargado de gestionarlos. Un Sistema Embebido [Heath Steve, 2003], a diferencia de un sistema tradicional como puede ser el que posee una computadora personal y cuyo objetivo es cubrir un rango amplio de necesidades, se construye para cubrir un conjunto de necesidades especificas y opera en un sistema computacional dedicado. La clave de los robots autónomos se encuentra en la inteligencia que presenta este Sistema Embebido, la cual le permite, mediante el análisis de las señales obtenidas del entorno, planificar su accionar en pos de alcanzar los objetivos planteados durante su diseño y concepción. Si a un robot autónomo se le incorporara dentro del conjunto de actuadores, un sistema mecánico de desplazamiento controlado, estaríamos en presencia de un sistema denominado Robot Autónomo Móvil. Este trabajo se sitúa en el marco de un Trabajo Final de Licenciatura en Sistemas por lo cual focalizaremos el estudio de los Robots Autónomos Móviles en su Sistema Embebido (SE) de control por sobre su sistema mecánico. 1

14 INTRODUCCION Los avances tecnológicos a nivel mundial y la gran demanda de estos en todos los sectores hace que existan tanto en el mercado nacional como internacional, numerosos desarrollos de hardware -muchos de ellos open-source o de libre utilización- asequibles y potencialmente utilizables en robótica autónoma móvil [Azcurra et al, 2011]. Esto permite a las industrias acceder de manera directa a la posibilidad de insertar tecnología en sus procesos productivos, mas allá de cuales sean sus dimensiones y su capacidad adquisitiva. Es claro que además de contar con la tecnología adecuada, es importante la intervención de profesionales informáticos tanto en el desarrollo e implementación de soluciones adecuadas a los requerimientos del cliente como en la generación del conocimiento requerido para lograrlo, es decir, la elaboración de metodologías, modelos de procesos, estándares, técnicas y procedimientos que permitan garantizar la conclusión exitosa y controlada de los proyectos generados asegurando niveles de calidad, seguridad, eficiencia y eficacia adecuados. Es importante hacer hincapié en este ultimo requerimiento, el conocimiento. La ausencia de una metodología integral y estandarizada de planificación y control puede derivar en numerosos inconvenientes a lo largo de un proyecto; desde el incremento en los plazos de entrega a causa de la mala planificación previa y un consecuente incremento en los costos, la construcción de un sistema que no satisface o satisface de manera parcial las expectativas y requisitos del cliente debido a la mala ejecución y documentación del proceso de ingeniería de requerimientos hasta la imposibilidad de realizar modificaciones o mantenimiento en el sistema debido a la falta de documentación. La existencia de una metodología integral y estandarizada para el manejo de proyectos de desarrollo de Sistemas Embebidos, permitiría reducir significativamente la aparición de imprevistos a lo largo de un proyecto que deriven en el incumplimiento de acuerdos y plazos establecidos con el cliente o alteren la calidad del producto final, independientemente del equipo de trabajo u organización que lleve adelante el proyecto OBJETIVOS DEL TRABAJO FINAL En esta sección se establece el objetivo general del trabajo y los objetivos particulares propuestos para contribuir al alcance del mismo OBJETIVO GENERAL El objetivo general de este TFL es la elaboración de un modelo de gestión integral de proyectos destinados al control de Robots Autónomos Móviles (RAM) basados en Arquitecturas de Sistemas Embebidos (ASE), que permita al Profesional de Sistemas contribuir en el proceso de inserción de la tecnología en la industria (preferentemente PyMEs) mediante el desarrollo e implementación de 2

15 INTRODUCCION soluciones que aseguren la satisfacción de las necesidades del cliente alcanzando niveles de eficiencia y calidad apropiados para la disciplina OBJETIVOS PARTICULARES En torno a lo descripto anteriormente, se plantean los objetivos particulares que guían la realización de este trabajo: Objetivo particular I: Efectuar un relevamiento de estándares, modelos de procesos y técnicas existentes en el cuerpo de conocimiento de los sistemas informáticos -preferentemente embebidosy generar mediante su combinación y adaptación, un nuevo modelo de gestión integral de proyectos destinados al control de Robots Autónomos Móviles basados en Arquitecturas de Sistemas Embebidos. Objetivo particular II: Relevar las ASE existentes en el mercado local e internacional focalizando el análisis en sus características técnicas, físicas y comerciales a fin de crear un perfil de las mismas y generar una matriz comparativa que permita contribuir en el proceso de Selección del Hardware óptimo para el desarrollo de la solución requerida VISIÓN GENERAL DEL TRABAJO FINAL Este trabajo final de licenciatura se estructura en torno a 7 capítulos. En el capítulo inicial, se establece una introducción, en la cual se describe el contexto del mismo focalizando en la importancia de la introducción de nuevas tecnologías en diversos ámbitos sociales, principalmente en el sector industrial. Posteriormente se presenta el objetivo general planteado y los objetivos particulares que guían y contribuyen a su alcance. En el capítulo II - Estado de la Cuestión, se realiza un estudio de distintos modelos y estándares existentes en la base de conocimiento de los sistemas informáticos y cuyo objetivo es asistir al profesional del área en la realización de las actividades que puedan estar contenidas en las fases o procesos de un proyecto de desarrollo de sistemas, ya sean estos embebidos o artefactos software. En el capitulo III Descripción del Problema, se describe la problemática identificada que motiva a la realización de este trabajo final de licenciatura focalizando en el estudio de la conveniencia por parte de los sectores industriales respecto de insertar la tecnología en sus procesos productivos en pos de incrementar su productividad y la carencia de metodologías estandarizadas asociadas a la disciplina que permitan al profesional de sistemas alcanzar este objetivo de manera controlada y cumpliendo con ciertos estándares de calidad. En primer lugar se describe el problema de 3

16 INTRODUCCION investigación planteado, posteriormente se presenta el problema abierto y finalmente se concluye el capitulo con un sumario de investigación. En el capitulo IV Solución, se propone un modelo que busca alcanzar el objetivo general planteado y de esta manera cubrir la problemática identificada en este TFL. El capitulo contiene la presentación y descripción del modelo propuesto partiendo de una introducción a las cuestiones generales del mismo. Posteriormente se realiza una descripción detallada de sus procesos, subprocesos, actividades asociadas, técnicas sugeridas y documentación de salida y finalmente, se concluye indicando el procedimiento de implementación de la misma. En el Capitulo V Prueba de Concepto, se presenta un caso de aplicación concreta del nuevo modelo generado, que busca desarrollar un sistema que satisfaga las necesidades de automatización de un proceso productivo descripto y de esta manera, validar la factibilidad de aplicación de la solución planteada. En el capitulo VI Conclusiones, se describen los aportes realizados por este TFL y se proponen futuras lineas de investigación. En el capitulo VII y final, se enumeran las referencias. 4

17 ESTADO DE LA CUESTIÓN 2. ESTADO DE LA CUESTIÓN A lo largo de este capitulo se describe el estado de la cuestión en el dominio de los modelos de procesos para Sistemas Informáticos. En la sección 2.1 se presentan y describen tres modelos de procesos para Sistemas Informáticos. Dos de ellos pertenecen al ámbito de los sistemas embebidos (secciones y 2.1.2), disciplina en la cual se identifico una gran carencia respecto a este tipo de conocimiento y el restante (sección 2.1.3), a pesar de pertenecer al dominio de la ingeniería de software, fue seleccionado por su potencialidad de contribución, tanto desde el aspecto técnico como metodológico, a la generación de una nuevo modelo que cubra la problemática identificada. Por último, en la sección 2.2 se desarrolla un esquema comparativo de las principales ventajas y desventajas de cada modelo seleccionado. Para obtener información mas detallada de los modelos seleccionados y brevemente descriptos a continuación, referirse al ANEXO III Modelos de Procesos para Sistemas Informáticos MODELOS DE PROCESOS PARA SISTEMAS INFORMÁTICOS Los modelos de procesos, ya sea en sistemas o cualquier otra disciplina, buscan asistir al profesional de la misma en la ejecución ordenada, controlada, documentada y por sobre todo estandarizada, de un conjunto de actividades necesarias para la concepción de un producto o servicio que satisfaga una necesidad planteada. Es por ello que este tipo de conocimiento es considerado de suma relevancia en cualquier asignatura. En el ámbito de la ingeniería de software, se dispone de una gran cantidad y diversidad de modelos de procesos y standards que cumplen con las características anteriormente mencionadas como el Standard IEEE 1074 o el modelo de procesos de software MoProSoft, por mencionar algunos de los mas relevantes. Sin embargo, no sucede lo mismo en la base de conocimiento de los sistemas embebidos donde solo se encontraron al momento de redacción de este trabajo final de licenciatura, una escasa cantidad modelos de procesos y técnicas orientadas a asistir al profesional en fases aisladas de un proyecto como es -tal vez una de las mas determinantes- la fase de ingeniería de requerimientos (IR). A continuación se presentan y describen 2 modelos provenientes del ámbito de los SE, (1) Modelo de Requisitos para Sistemas Embebidos de Liliana Gonzalez y German Urrego (2008) y (2) Model Integrated Systems de Akos Ledeczi, Arpad Bakay y Miklos Maroti y un standard referente de la ingeniería de software como lo es IEEE Standard for Developing Software Life 5

18 ESTADO DE LA CUESTIÓN Cycle Processes del Software Engineering Standards Committee of the IEEE Computer Societ, en su ultima versión correspondiente al año MODELO DE REQUISITOS PARA SISTEMAS EMBEBEBIDOS - LILIANA GONZALEZ, GERMAN URREGO (2008). En la actualidad, las metodologías de IR disponibles en el dominio de los sistemas embebidos poseen una fuerte orientación a la etapa de diseño y un énfasis más débil en la etapa de Análisis. Es por esto que usualmente, los diseñadores de sistemas cometen el error de comenzar a diseñar e implementar soluciones que no han sido completamente especificadas y que corresponden a problemas carentes de delimitación. Esto conduce a la construcción de sistemas que no satisfacen las necesidades de los clientes y que incurren en el aumento de los costos y el incumplimiento de los plazos establecidos. Además del fenómeno planteado anteriormente surgen entre otros, los siguientes supuestos: a) Los sistemas basados en embebidos suelen ser desarrollados generalmente por expertos en electrónica, pero alejados del uso de las metodologías de Análisis y Diseño. b) La ausencia de metodologías específicas, reemplazadas por aquellas de propósito general que no contienen ninguna adaptación a los sistemas embebidos. c) Las metodologías existentes en el campo de los SE no cubren todas las fases de la Ingeniería de Requisitos. [Palacio y Giraldo, 2008]. Entre las metodologías existentes, los autores de este modelo focalizaron en ABC-Besoins, un modelo originalmente diseñado para el dominio de sistemas web, que introduce el concepto de Intervención de agentes mediante el cual logra integrar y relacionar los requisitos de diferentes contextos y propone además, pautas para el Análisis de Requisitos desde la fase de captura hasta la fase de especificación, logrando la operacionalización de los mismos y la construcción de un modelo conceptual. Todas estas ventajas se deben a un modelo de requisitos expresivo que permite relacionar requisitos de diferentes niveles y capturar las necesidades de los agentes [Palacio y Giraldo, 2008]. La propuesta fue entonces intervenir la metodología ABC-Besoins a fin de adaptarla y transformarla para abarcar aspectos del dominio de SE, y construir un modelo conceptual que facilite la entrada a un lenguaje de especificación [Palacio y Giraldo, 2008], es decir, un lenguaje formal o semi-formal que permita construir modelos de los sistemas que se desea elaborar. El nuevo modelo generado fue bautizado ABC-Besoins-SEM y construido respetando las categorías principales definidas en el modelo tradicional a las cuales se le incorporaron nuevas sub-categorías a fin de definir requisitos más específicos que incorporan los elementos propios de los sistemas embebidos [Palacio y Giraldo, 2008]. 6

19 ESTADO DE LA CUESTIÓN El modelo ABC-BENSOINS-SEM fue seleccionado entre la escasa oferta que presenta la base de conocimiento de los sistemas embebidos, por su aporte a la organización y conducción del proceso de ingeniería de requerimientos funcionales y no funcionales de SE dentro de un marco metodológico y controlado basado en la organización de los mismos en torno a Categorías y Subcategorias inherentes a su condición. Además, su concepción se asemeja a la linea de desarrollo planteada en este trabajo final de licenciatura, es decir, la construcción de un nuevo modelo de procesos mediante la adaptación y complemento de modelos existentes y de probado éxito en el ámbito de los sistemas informáticos. Si bien este modelo incorpora algunas categorías enfocadas a la gestión de costos y contempla el comportamiento y algunos aspectos del sistema producido como su disponibilidad y su capacidad de detección de fallas, carece de actividades orientadas a la planificación, gestión y control del proyecto GOAL-ORIENTED PATTERNS FOR UML-BASED MODELING OF EMBEDDED SYSTEMS REQUIREMENTS DE HEATHER J. GOLDSBY1, SASCHA KONRAD, BETTY H.C. CHENG. Los autores de este modelo tomaron como premisa la naturaleza de utilización de los sistemas embebidos en aplicaciones criticas y por ello su necesidad de ajustarse a diversas restricciones de seguridad. Identificaron además. que los desarrolladores de estos sistemas, usualmente deben enfrentarse a tres retos clave a la hora de aplicar enfoques existentes de Análisis de Requerimientos; Estos son: (1) Modelar y declarar literalmente requerimientos funcionales, no funcionales y restricciones; (2) Modelar de manera operativa el comportamiento deseado; (3) Analizar los modelos de requerimientos de comportamiento en adhesión a las restricciones planteadas. [Heather et al, 2007]. A fin de sobrepasar estos retos, introdujeron patrones COBRA (Constraints and OBjects for Requirements Analysis) que proporcionan plantillas de modelos UML y modelos basados en Metas, implementables en conjunto en la creación de modelos de representación gráfica que capturen múltiples vistas de los requerimientos del sistema y sus restricciones [Heather et al, 2007]. A fin de capturar los componentes esenciales de un sistema embebido, los patrones COBRA modelan los requerimientos asociados a sensores, actuadores, controladores e interfaces de usuarios mediante la relación de modelos basados en metas con modelos UML a nivel de los requerimientos. Esta combinación supone tres beneficios clave: (1) La plantilla del modelo basado en metas especifica de manera declarativa los requerimientos funcionales y no funcionales de un sistema embebido y los refina en las restricciones; (2) La plantilla del modelo UML especifica de manera operativa el comportamiento que satisface los requerimientos; Específicamente, la estructura del 7

20 ESTADO DE LA CUESTIÓN sistema es capturada utilizando diagramas de clase UML y el comportamiento mediante diagramas de estado UML. (3) La consistencia estructural y de comportamiento es establecida entre los modelos UML y basados en metas, resultantes [Heather et al, 2007].. Para facilitar la implementación de este modelo, se utiliza una plantilla diseñada para direccionar los requerimientos tempranos y tardíos identificando cuando aplicar un patrón, como hacerlo y las metas del mismo -para casos de requerimientos tempranos- e identificando la estructura y comportamiento de los componentes mas relevantes del sistema para los casos de requerimientos tardíos [Heather et al, 2007]. Se ha seleccionado este modelo por introducir a la base de conocimiento de los sistemas embebidos, una técnica de representación gráfica y modelado de requisitos mediante la utilización de patrones COBRA y diagramas UML, capaz de especificar de manera declarativa los requerimientos funcionales y no funcionales de un sistema embebido, refinarlos en las restricciones identificadas y especificar de manera operativa el comportamiento [Heather et al, 2007].. Este modelo carece por completo de actividades destinadas a la planificación y gestión del proyecto y se enfoca exclusivamente en la fase de IR del sistema embebido a desarrollar. Estas características lo tornan insuficiente para cubrir de manera independiente la carencia planteada pero si muy importante a la hora de complementar un modelo gestión de proyectos dedicados al control de Robots Autónomos mediante sistemas embebidos IEEE STANDARD FOR DEVELOPING SOFTWARE LIFE CYCLE PROCESSES SOFTWARE ENGINEERING STANDARDS COMMITTEE OF THE IEEE COMPUTER SOCIETY (2006). IEEE es la asociación profesional sin fines de lucro más grande y prestigiosa del mundo [IEEE, 2013] dedicada a fomentar el avance de la innovación tecnológica y la excelencia en beneficio de la humanidad. Sus miembros, ingenieros electrónicos, informáticos, científicos de la computación y expertos en telecomunicaciones de mas de 160 países, inspiran a la comunidad global a través de publicaciones, conferencias, estándares de tecnología y diversas actividades profesionales y educativas. El standard 1074 desarrollado por dicha asociación y cuya ultima versión data del año 2006 está dirigido a los gestores de proyectos, desarrolladores de software, responsables de la garantía de la calidad, a quienes ejecutan tareas de apoyo, a los usuarios y al personal de mantenimiento de productos software y determina un conjunto de actividades esenciales, no ordenadas en el tiempo, que deben ser incorporadas dentro de un Modelo de Ciclo de Vida del producto software a desarrollar, establecido por el usuario para el proyecto a llevar a cabo -la norma no define un ciclo de vida en particular- [Peláez, 2013]. 8

21 ESTADO DE LA CUESTIÓN El standard se estructura en torno a procesos y subprocesos, los cuales proponen a su vez actividades a llevar a cabo. El trabajo realizado a lo largo de cada fase se ve reflejado en diversos documentos de salida que brindan marco profesional y controlado a la actividad. Es importante destacar que el mismo es perfectamente adaptable a las necesidades, características y dimensiones de cada proyecto. De manera complementaria, se referencia la guía de estudio Ciclo de Vida de Software, Proceso Software y Plan de Actividades" [García Martínez, 2009], en la cual se introduce el concepto de Técnicas Sugeridas para las actividades propuestas en cada subproceso. Si bien este standard fue diseñado para contribuir en la mejora de la calidad los proyectos de Ingeniería de software, es considerado una importante fuente de aporte, fundamentalmente desde el punto de vista estructural y metodológico, para el desarrollo de un nuevo modelo de gestión de proyectos destinados al control Robots Autónomos mediante Sistemas Embebidos a partir de la adaptación de sus procesos, sub-procesos, actividades relacionadas y documentación de salida, y la inserción y adaptación en su estructura de otros modelos y técnicas seleccionadas de la base de conocimientos de los sistemas embebidos y afines como los descriptos anteriormente en la presente sección ESQUEMA COMPARATIVO En la Tabla 2.2 se presentan las principales virtudes y carencias de cada modelo expuesto en la sección anterior a modo de llevar a cabo un ejercicio comparativo de rápida interpretación. Modelo Virtudes Carencias Modelo de Requisitos para Sistemas Embebidos. ABC-BENSOINS-SEM Goal-Oriented Patterns for UML- Based Modeling of Embedded Systems Requirements Amplia cobertura de la fase de Ingeniería de Requisitos de Sistemas Embebidos Estructura en torno a Categorías y Sub-categorías que abordan los requerimientos funcionales y no funcionales del sistema según su origen y condición. Propone una metodología de análisis y modelado de requerimientos funcionales y no funcionales con representación gráfica mediante diagramas UML y patrones COBRA. Aborda los requerimientos desde diversos enfoques y valida su consistencia Tabla 2.2. a) Esquema comparativo de modelos Su espectro de acción es la fase de ingeniería de requisitos por lo cual carece de todo tipo de actividades destinadas a la planificación, gestión, control y documentación del proyecto. Su espectro de acción es la fase de ingeniería de requisitos por lo cual carece de todo tipo de actividades destinadas a la planificación, gestión, control y documentación del proyecto. 9

22 ESTADO DE LA CUESTIÓN IEE Desarrollado por la IEEE, presenta una estructura sumamente completa basada en procesos, subprocesos y actividades que abarcan la totalidad de las fases de un proyecto de ingeniería de Su espectro de acción es la Ingeniería de software por lo cual carece del enfoque necesario para satisfacer las necesidades de proyectos destinados al control de Robots Autónomos mediante sistemas embebidos. software. Se adapta a las necesidades y dimensiones de cada proyecto. Su éxito en el ámbito de la ingeniería de software esta ampliamente comprobado. Tabla 2.2. b) Esquema comparativo de modelos 10

23 DESCRIPCION DEL PROBLEM A 3. DESCRIPCIÓN DEL PROBLEMA A lo largo de este capitulo se presenta y describe el problema que motiva a la realización de este trabajo final de licenciatura, haciendo hincapié en el análisis de las ventajas que supone la inserción de la Robótica Autónoma en la industria, la carencia actual de metodologías que permitan llevar a cabo dicha tarea de manera estandarizada y como ésta carencia impacta en la calidad de las soluciones implementadas actualmente. Inicialmente se identifica el problema de investigación (sección 3.1) para luego presentar el problema abierto (sección 3.2). Finalmente se concluye con un sumario de investigación (sección 3.3) IDENTIFICACIÓN DEL PROBLEMA DE INVESTIGACIÓN Desde sus inicios, las empresas e industrias han buscado incrementar sus niveles de productividad y elevar la calidad de sus productos y servicios de diversas maneras, entre ellas, mediante la inserción de nuevas tecnologías en sus procesos productivos. Este fenómeno puede suponer una reducción en los costos y tiempos de producción, un incremento en los niveles de control sobre dichos procesos y hasta un incremento en la calidad de los productos o servicio elaborados. A fin de llevar a cabo exitosamente este proceso es imperativa la utilización de metodologías y estándares que permitan asegurar el cumplimiento de los objetivos establecidos en un proyecto de manera controlada, eficaz y eficiente. Este comportamiento puede observarse con un alto grado de madurez en disciplinas afines como la Ingeniería de Software, la cual cuenta con diversos estándares y metodologías de probado éxito en su base de conocimiento como son el Standard IEEE 1074 o el modelo de procesos de software MoProSoft. Estos últimos asisten no solo en las fases inherentes al diseño e implementación de los sistemas desde el punto de vista técnico sino también a la planificación y gestión integral de los proyectos. En el ámbito de los Sistemas Embebidos, sin embargo, se identifica una carencia respecto de este tipo de conocimiento lo cual provoca que los profesionales de sistemas o áreas afines, tiendan a desarrollar soluciones focalizando su labor únicamente en las cuestiones técnicas y sin contemplar actividades de planificación y gestión de los proyectos que generan. De esta manera es factible que deban enfrentar diversos tipos de dificultades durante la ejecución de los mismos y que éstas deriven en comportamientos indeseados como la utilización ineficiente de los recursos disponibles (materiales, humanos y económicos), en la generación de un producto final que muchas veces no satisface o satisface de manera parcial los requerimientos del cliente, entre otros. 11

24 DESCRIPCION DEL PROBLEM A 3.2. PROBLEMA ABIERTO El problema abierto que se plantea surge de la identificación de una carencia en el cuerpo de conocimiento de los SE, de un modelo de gestión integral de proyectos destinados al control de Robots Autónomos Móviles basados en Arquitecturas de Sistemas Embebidos, que permita al Profesional de Sistemas contribuir en el proceso de inserción de la tecnología en la industria (preferentemente PyMEs) mediante el desarrollo e implementación de soluciones que aseguren la satisfacción de las necesidades del cliente alcanzando niveles de eficiencia y calidad apropiados para la disciplina SUMARIO DE INVESTIGACIÓN De lo expuesto anteriormente surge el siguiente interrogante que guía la investigación: Es posible generar un modelo de gestión integral de proyectos destinados al control de Robots Autónomos Móviles utilizando sistemas embebidos mediante la combinación y adaptación de modelos y estándares de sistemas informáticos seleccionados del cuerpo de conocimiento de la Ingeniería de Software y los Sistemas Embebidos. En caso de que la respuesta a la pregunta anterior sea afirmativa, Es factible la implementación exitosa del modelo generado en un caso de prueba representativo de una problemática real? 12

25 SOLUCION 4. SOLUCION A lo largo de este capitulo se propone un modelo de gestión integral de proyectos destinados al control de Robots Autónomos Móviles mediante Sistemas Embebidos que busca cubrir la carencia identificada MODELO DE GESTION INTEGRAL DE PROYECTOS DESTINADOS AL CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS. A continuación se realiza una introducción general al modelo propuesto (sección 4.1.1), se mencionan y justifican sus principales influencias (sección 4.1.2) y se describe su estructura principal (sección 4.1.3). En la sección 4.1.4, se realiza un desmembramiento de cada sub-proceso en torno a las actividades, técnicas y documentos que lo componen y por ultimo se realiza una descripción detallada de cada uno de los procesos, subprocesos y actividades propuestas y del procedimiento de implementación del nuevo modelo GENERALIDADES El modelo propuesto surge de la adaptación de los subprocesos y actividades existentes en el standard IEEE [IEEE, 2006] a las características y necesidades de un proyecto de SE; especializa su fase de ingeniería de requerimientos mediante la inserción de dos modelos fuertemente orientados a esta disciplina e incorpora y adapta el concepto de sugerencia de técnicas y documentos de salida para cada subproceso, propuesto por la guía de estudio correspondiente a la carrera de Lic. en Sistemas de la UNLa titulada Ciclo de Vida de Software, Proceso Software y Plan de Actividades [García Martínez,2009] INFLUENCIAS Los modelos seleccionados para contribuir a la composición del modelo a proponer fueron mencionados y brevemente descriptos en el capitulo 3. Estos son Modelo de Requisitos para Sistemas Embebidos, Goal-Oriented Patterns for UML-Based Modeling of Embedded Systems Requirements y Software Engineering Standards Committee of the IEEE Computer Society Además de estos modelos y a modo de complementar la propuesta del standard IEEE , se referencia una la guía de estudio correspondiente a la carrera de Lic. en Sistemas de 13

26 SOLUCION la UNLa titulada Ciclo de Vida de Software, Proceso Software y Plan de Actividades la cual sugiere diversas técnicas a utilizar y documentos a elaborar a lo largo de las actividades propuestas en cada subproceso [García Martínez, 2009]. El primer modelo seleccionado, Modelo de Requisitos para Sistemas Embebidos, se inserta en el proceso Desarrollo del nuevo modelo generado, particularmente en el subproceso Requisitos a fin de adaptar y especializar esta fase en el dominio de los sistemas embebidos y ofrecer al profesional una procedimiento estandarizado y sumamente eficaz que permita llevar a cabo exitosamente la fase de ingeniería de requisitos. El mismo fue considerado por introducir una metodología sistemática basada en categorías y subcategorías que busca integrar y relacionar los requisitos de los sistemas embebidos desde diferentes contextos y proponer además, pautas para el análisis de los mismos desde la fase de captura hasta la fase de especificación, logrando su operacionalización y la construcción de un modelo conceptual [Palacio y Giraldo, 2008]. El segundo modelo, Goal-Oriented Patterns for UML-Based Modeling of Embedded Systems Requirements se integra de igual manera que el primero, en el proceso Desarrollo y subproceso Requisitos. El objetivo es poner a disposición una herramienta de igual nivel de eficacia que la anteriormente mencionada, que permita al profesional optar por la mas conveniente según sean las características y necesidades del proyecto en curso. Este modelo fue considerado por incorporar una técnica de modelado y representación gráfica mediante la utilización de Patrones COBRA y Diagramas UML capaz de abordar los requerimientos funcionales y no funcionales de un sistema y refinarlos en torno a las restricciones existentes [Heather et al, 2007] de manera sumamente efectiva. Ambas técnicas por si solas abarcan en su totalidad la fase de IR pero son insuficientes para brindar soporte a las fases previas y posteriores a la misma. Es aquí donde el standard IEEE adquiere protagonismo como columna vertebral del nuevo modelo, con el objetivo de guiar al profesional de sistemas a lo largo de todo el proyecto y actuar de base estructural tanto para las modelos anteriormente mencionados e integrados, como para cualquier otro que pueda ser desarrollado con el objetivo de asistir en cualquier etapa del proyecto. Su estructura en torno a procesos, subprocesos y actividades -que van desde la concepción del Ciclo de vida hasta el Retiro del Producto- se considera adaptable a las necesidades que puedan desprenderse de un proyecto enfocado al control de Robots Autónomos Móviles basados en SE. Por ultimo y de manera complementaria, la adopción del concepto de técnicas sugeridas, propuesto originalmente en el marco del standard IEEE 1074 en la guía de estudio correspondiente a la carrera de Lic. en Sistemas de la UNLa titulada Ciclo de Vida de Software, Proceso Software y Plan de Actividades [García Martínez, 2009] contribuye a la selección de la técnica apropiada para cada actividad o bien brinda una guía o referencia. 14

27 SOLUCION ESTRUCTURA GENERAL DEL MODELO PROPUESTO El modelo toma como columna vertebral la estructura propuesta por el standard IEEE [IEEE, 2006], es decir, se organiza en torno a procesos y subprocesos que buscan cubrir todos las fases correspondientes a un proyecto dedicado al control de Robots Autónomos Móviles basados en Arquitecturas de Sistemas Embebidos. A continuación se presenta la estructura general del modelo IEEE 2006 adaptada y complementada para satisfacer las necesidades del tipo de proyecto mencionado anteriormente Procesos de Gestión del Proyecto Sub-proceso de Iniciación del proyecto Sub-proceso de Planificación del proyecto Sub-proceso de Monitoreo y Control Proceso de Pre-Desarrollo Sub-proceso de Exploración de Conceptos Sub-proceso de Asignación del Sistema Proceso de Desarrollo Sub-proceso de Requisitos Sub-proceso de Diseño Sub-proceso de Implementación Proceso de Post-Desarrollo Sub-proceso de Instalación y Validación Sub-proceso de Operación y Soporte Sub-proceso de Mantenimiento Sub-proceso de Retiro Procesos Integrales del Proyecto Subproceso de Evaluación Sub-proceso de Gestión de la configuración Sub-proceso de Desarrollo de Documentación Sub-proceso de Formación PROCESOS, SUB-PROCESOS, ACTIVIDADES, DOCUMENTOS DE SALIDA Y TÉCNICAS SUGERIDAS En esta sección se describe con mayor profundidad la estructura del modelo. Los procesos son desmembrados en torno a los subprocesos que los componen y se listan las actividades propuestas 15

28 SOLUCION para cada subproceso, los documentos de salida que se esperan obtener a partir de las mismas y las técnicas sugeridas para lograrlo Proceso de Gestión del Proyecto Sub-proceso de Iniciación del proyecto Actividades: Entendimiento del Negocio Seleccionar un modelo de Ciclo de Vida Realizar Estimaciones Asignar Recursos Definir Métricas Determinar objetivos de Seguridad Documentación de Salida: Modelo de Ciclo de Vida Seleccionado Estimaciones del Proyecto Asignación de Recursos Métricas Definidas, Métodos de Análisis y Captura de las mismas Especificación de Objetivos de Seguridad Técnicas Sugeridas: Investigación documental. Entrevistas al cliente. Análisis de camino critico Diagrama PERT Diagrama Gantt Técnicas estadísticas y de Simulación (Metodo Montecarlo) Modelos empíricos de estimación de esfuerzo del Software(COCOMO, PUTNAM) Sub-proceso de Planificación del proyecto Actividades: Planificación de la Evaluación Planificación de la Gestión de la Configuración Planificación de la Transición (si se requiere) Planificación de la Instalación Planificación de la Documentación 16

29 SOLUCION Planificación del Entrenamiento Planificación de la Gestión del Proyecto Planificación de la Integración Planificación de la Gestión del Lanzamiento Planificación del Mantenimiento Planificación del Retiro Documentación de Salida: Plan de Evaluación Plan de Gestión de la Configuraciones Plan de Transición e Informe de Impacto Plan de Instalación Plan de Documentación Plan de Entrenamiento Plan de Gestión del Proyecto Plan de Integración Plan de Gestión del Lanzamiento Plan de Mantenimiento Plan de Retiro Técnicas sugeridas: WRS (Working Breakdown Structure) Diagramas PERT y Gantt Sub-proceso de Seguimiento y Control del Proyecto Actividades: Gestión de Riesgos Gestión del Proyecto Identificación de Mejoras al Ciclo de Vida Almacenamiento de Registros Recopilación y Análisis de Métricas Cierre del Proyecto Documentación de Salida: Reporte de Riesgos Reporte de Gestión del Proyecto Reporte de Necesidades de mejora en el Ciclo de Vida Registro Histórico de Proyectos 17

30 SOLUCION Reporte de Métricas Información necesaria para el archivo del Proyecto al momento de su cierre Técnicas Sugeridas: Análisis de Riesgo técnico Modelización y Simulación Estática y Dinámica Prototipado Revisiones y Auditorías Análisis de Riesgo económico (Finanzas y Retorno de la Inversión) Análisis de Riesgo Operativo y de Soporte Análisis de Riesgo del Programa Análisis de camino critico CPM Técnicas de nivelación de recursos Análisis de riesgo del Hardware. Prototipos Modelo de ingeniería de requisitos ABC-Besoins- SEM Categoría Descripción y caracterización de los agentes (disponibilidad, eficiencia, seguridad, confiabilidad ) Proceso de Pre-Desarrollo Sub-proceso de Exploración de Conceptos Actividades: Identificar ideas o necesidades Formular soluciones potenciales Conducir estudios de viabilidad Refinar y finalizar la idea o necesidad. Documentación de Salida: Informe preliminar de necesidades Informe de Soluciones potenciales. Análisis de beneficios y limitaciones Informe de Viabilidad Informe de Necesidades 18

31 SOLUCION Técnicas Sugeridas: Técnicas de Adquisición de Conocimientos Análisis Económico (Coste/Beneficio) Análisis Técnico Análisis de Alternativos Técnicas de Modelización y Prototipado Diagramas de Flujos de Datos (DFD) Sub-proceso de Asignación del Sistema Actividades: Analizar las funciones del sistema Desarrollar la arquitectura del sistema Asignar los requisitos del Sistema Documentación de Salida: Descripción Funcional del Sistema Arquitectura del Sistema Requerimientos de Hardware del Sistema Requerimientos Funcionales del Sistema Requerimientos No Funcionales del Sistema Requerimientos de Interface del Sistema Requerimientos del entorno del Sistema Técnicas Sugeridas:. Técnicas de Modelización y Prototipado. Diagramas de Flujo de Datos (DFD). Modelo de Ingeniería de Requerimientos ABC-BESOINS- SEM Patrones Orientados a Metas para Modelado UML de Requerimientos de Sistemas Embebidos Proceso de Desarrollo Sub-proceso de Requisitos Actividades: Definir y desarrollar los requisitos del software Definir y desarrollar los requisitos del hardware Definir los requisitos del entorno Definir los requisitos de interfaz 19

32 SOLUCION Integrar los requisitos Documentación de Salida: Informe preliminar de requisitos del sistema Especificación de requisitos de hardware Especificación de requisitos de interfaces y entorno Especificación de requisitos de software Especificación de requerimientos del sistema Técnicas Sugeridas: Técnicas orientadas a los procesos Modelo de ingeniería de requisitos ABC-Besoins-SEM Patrones Orientados a Metas para Modelado UML de Requerimientos de Sistemas Embebidos Análisis estructurado Diagrama de flujos de datos DFD Diccionario de datos DD SADT (Structured Analysis and Design Techniques) Diagramas de transición de estados Actigramas o Diagramas de Actividades Técnicas formales de especificación Técnicas orientadas al estado Tablas de decisión Tablas de eventos Tablas de transición Mecanismos de estados finitos Redes de Petri Modelo de ingeniería de requisitos ABC- Besoins-SEM Categoría Disponibilidad de objetos (estados, eventos) Categoría Selección de alternativas (modos y submodos de operación) Técnicas de prototipado 20

33 SOLUCION Sub-proceso de Diseño Actividades: Realizar el diseño arquitectónico Realizar el diseño de la base de datos (si aplica) Selección de la Arquitectura de Hardware mas conveniente Diseñar las interfaces Realizar el diseño detallado Documentación de Salida: Diseño arquitectónico Diseño de la base de datos Diseño de las interfaces Diseño detallado Técnicas Sugeridas: Técnicas orientadas a los procesos Patrones COBRA para modelos UML y basados en Metas. Diagramas de Flujo Diseño estructurados Análisis de transformación Análisis de transacción Diagramas jerárquicos de procesos Warnier Diagramas de Chapin o Nassi-Schneiderman Diseño del dialogo de los interfaces Patrones COBRA para modelos UML y basados en Metas Diagramas de Flujo HIPO (Hierarchy Input Process Output) Diagramas de Chapin o Nassi-Schneiderman Técnicas Orientadas a los datos DFD Modelos lógicos y físicos de datos Diagramas jerárquicos Warnier Diagramas estructurados Jackson Diagramas de Flujo 21

34 SOLUCION Diagramas Entidad-Relacion Técnicas orientadas a los objetos UML Técnicas de diseño de bajo nivel Programación estructurada Diagramas arborescentes Diagramas de Chapin o Nassi-Schneiderman Diagramas jerarquicos Warnier Diagramas estructurados Jackson Técnicas de prototipado y refinamiento ANEXO I Relevamiento de Hardware y ANEXO II Matriz Comparativa (selección del hardware apropiado) Sub-proceso de Implementación Actividades: Configurar e integrar el hardware y las interfaces físicas Crear el código fuente Crear la Documentación operacional Realizar la integración Gestionar las versiones del Software Documentación de Salida: Código fuente Especificación de Software Especificación de Hardware Base de datos (si aplica) Documentación operacional Paquete del producto lanzado Técnicas Sugeridas: Lenguajes de programación Herramientas de versionado de software Entornos de modelado de Bases de Datos Entorno de Programación del hardware seleccionado 22

35 SOLUCION Proceso de Post-Desarrollo Sub-proceso de instalación y Validación Actividades: Ajustar parámetros del entorno Configurar y adaptar interfaces con el entorno productivo y otros sistemas Aceptar el producto en el ambiente operativo Documentación de Salida: Reporte de Instalación y operación del Sistema Reporte del estado de la configuración Informe de aceptación del software por parte del usuario Sub-proceso de operación y soporte Actividades: Operar el sistema Proveer de asistencia técnica y consultas Mantener el histórico de peticiones de soporte Documentación de Salida: Registro de Operaciones Registro de Anomalías Registro de Peticiones de Soporte Sub-proceso de mantenimiento Actividades: Identificación de necesidades de mejora del Software Identificación de necesidades de mejora del Hardware y Entorno Configurable Implementación de un método de reporte de problemas Iteración del Ciclo de Vida Documentación de Salida: Sugerencia de mejoras al software Sugerencia de mejoras del hardware Reporte de anomalías Reporte de corrección de anomalías Recomendaciones de Mantenimiento 23

36 SOLUCION Sub-proceso de retiro Actividades: Notificar al usuario Conducir operaciones en paralelo (si aplica) Retirar el sistema Documentación de Salida: Notificación oficial al usuario Registro de operaciones en paralelo Reporte de revisión Post-Operacion Procesos Integrales del Proyecto Subproceso de Evaluación Actividades: Revisión de Conducta Crear Matriz de Trazabilidad Conducir Auditorías Desarrollar Procedimientos de prueba Crear datos de prueba Ejecutar pruebas Reportar Resultados de la evaluación Confirmar Acreditación de Seguridad Documentación de Salida: Resultados de revisión en-proceso Reporte de revisión Post-implementacion Recomendación de mejoras en los procesos Reporte de estado de la gestión Reporte de análisis de trazabilidad Reporte de cambios en la asignación del sistema Matriz de Trazabilidad Reporte de Auditoría Plan de Prueba (Procedimientos y datos) Sumario de Pruebas Reporte de Evaluación 24

37 SOLUCION Técnicas Sugeridas: Técnicas de prueba de caja blanca Cobertura de sentencias Cobertura de decisión o ramificación Cobertura de condición Cobertura de decisión/condición Cobertura de condición múltiple Técnicas de prueba de caja negra Partición de equivalencias Análisis de valores limites Gráficos causa-efecto Conjetura de errores Revisiones formales Auditorías Sub-proceso de gestión de la configuración Actividades: Realizar la identificación de la configuración Realizar el control de la configuración Realizar la información del estado de la configuración Documentación de Salida: Reporte de Identificación de la Configuración Sub-proceso de desarrollo de Documentación Actividades: Implementar la Documentación Producir y Distribuir la Documentación Documentación de Salida: Documentación entregable Documentación interna del proyecto Sub-proceso de Formación Actividades: Desarrollar los materiales de formación Validar el programa de formación Implementar el programa de formación 25

38 SOLUCION Documentación de Salida: Manual de procedimientos y materiales de entrenamiento DESCRIPCIÓN Y OBJETIVOS DE LOS PROCESOS, SUB-PROCESOS Y ACTIVIDADES PROPUESTAS A continuación se describen los objetivos de los procesos, subprocesos y actividades del modelo PROCESO DE GESTIÓN DEL PROYECTO En este proceso se sugieren actividades relacionadas a la iniciación, planificación y control del proyecto a lo largo de su ciclo de vida. Las mismas no presentan un orden cronológico de ejecución sino que deben ser asignadas al Ciclo de Vida Seleccionado. Este proceso sera descripto en mayor detalle en la sección Sub-proceso de Iniciación del proyecto Entendimiento del Negocio Mediante esta actividad se describen y analizan las condiciones inherentes al negocio del cual el sistema formara parte, focalizando en los motivos que alientan y justifican la realización del proyecto Seleccionar un modelo de Ciclo de Vida En esta actividad se establece la columna vertebral del proyecto mediante la selección de un modelo de ciclo de vida y la elaboración a partir del mismo del Ciclo de Vida del proyecto, un mapa de actividades, una secuencia de actividades y un mapa de documentos. Para conocer con mayor detalle este proceso referirse a la sección Realizar Estimaciones Con base en la descripción de los requisitos del producto a desarrollar, se realizan estimaciones del costo y esfuerzo necesarios para la conclusión exitosa del proyecto. El esfuerzo se obtiene de la estimación expresada en cantidad de horas necesarias para llevar a cabo una actividad por parte de uno o mas recursos asignados. El costo surge de la multiplicación del esfuerzo estimado y la remuneración por hora correspondiente al recurso asignado. Como resultado de esta actividad se obtiene un cuadro de estimación en el cual se listan las fases y actividades del ciclo de vida del proyecto y la estimaciones de costo y tiempo requerido para la realización de cada uno de ellas. 26

39 SOLUCION Asignar Recursos En esta actividad se estiman los recursos materiales y humanos necesarios para la realización del proyecto y sus costos Definir Métricas En esta sección se describen las métricas que serán recogidas a lo largo del proyecto y los métodos propuestos para hacerlo Determinar objetivos de Seguridad: Mediante esta actividad se identifican objetivos de seguridad en el proyecto Sub-proceso de Planificación del proyecto Planificación de la Evaluación A través de esta actividad se establecen las actividades y recursos necesarios para la evaluación eficaz del producto desarrollado y los procesos utilizados para hacerlo. En este proceso se deben establecer formalmente los criterios de aceptación del sistema por parte del cliente Planificación de la Gestión de la Configuración En esta actividad se planifican las acciones y recursos necesarios para la gestión de la Configuración del Sistema, focalizando en deberes y responsabilidades de los miembros de la organización respecto de los procesos a ejecutar y registros a generar Planificación de la Transición (si se requiere) Esta actividad aplica únicamente cuando el sistema a generar remplazará a otro sistema existente. De ser así, se planifican las actividades y recursos necesarios para garantizar una transición suave y exitosa. Se establecen deberes y responsabilidades, cronogramas, riesgos y requisitos de seguridad Planificación de la Instalación En esta actividad se planifican los recursos y procedimientos necesarios para llevar a cabo la instalación del sistema en el entorno productivo Planificación de la Documentación Mediante esta actividad se planifican los documentos entregables y de uso interno, a desarrollar durante el proyecto. Se asignan responsabilidades y plazos y se establecen cronogramas. 27

40 SOLUCION Planificación del Entrenamiento Esta actividad consta de la planificación de las actividades y recursos necesarios para el entrenamiento tanto del personal afectado a la realización del proyecto como del usuario final del producto entregado Planificación de la Gestión del Proyecto Esta actividad requiere la recopilación y síntesis de una gran cantidad de información. Deberá detallar la organización del proyecto y asignar responsabilidades. Sugerir estándares, metodologías y herramientas para la configuración, gestión de la calidad, seguridad, evaluación, formación y documentación. Definirá los procedimientos para la programación, seguimiento y presentación de informes. Dirigirá consideraciones tales como la planificación empresarial, el entorno, aprobaciones, certificaciones, participación de los usuarios, subcontratación y la seguridad entre otras. Esta actividad incluirá la planificación del soporte, el informe de problemas, gestión de riesgos, el cumplimiento de la seguridad, y la jubilación y retiro del producto Planificación de la Integración Esta actividad aplica cuando el sistema debe ser integrado con un sistema existente. En tal caso se planifican las actividades y recursos necesarios para garantizar una integración exitosa. Se establecen deberes y responsabilidades, cronogramas y se identifican riesgos y requisitos de seguridad Planificación de la Gestión del Lanzamiento Mediante esta actividad se planifica la transición del sistema del entorno de desarrollo y prueba al productivo. Se asignan deberes y responsabilidades, se establecen plazos, procesos y técnicas requeridas Sub-proceso de Seguimiento y Control del Proyecto Gestión de Riesgos Esta actividad busca identificar potenciales riesgos técnicos, comerciales y administrativos en el proyecto y elaborar planes de contingencia que disminuyan el impacto de su ocurrencia Gestión del Proyecto Mediante esta actividad se debe controlar la ejecución del proyecto comparando las estimaciones realizadas con los valores reales del proyecto. 28

41 SOLUCION Identificación de Mejoras al Ciclo de Vida A través de esta actividad y con base en métricas relevadas a lo largo del proyecto, se identifican y proponen mejoras en los procesos utilizados en el Ciclo de Vida del Proyecto Almacenamiento de Registros Se almacenan registros resultantes en todos los procesos y subprocesos del Ciclo de Vida del Proyecto para la composición y alimentación del registro histórico de proyectos. El mismo servirá de base para el proceso de estimación en proyectos futuros Recopilación y Análisis de Métricas Se recopilan las métricas definidas en la planificación, en momentos claves preestablecidos en el proyecto, se analizan las mismas y se planifican acciones correctivas de ser necesario Cierre del Proyecto Se concluye el proyecto, se archivan los registros obtenidos y se notifica a las partes involucradas PROCESO DE PRE-DESARROLLO El grupo de actividades del proceso de pre-desarrollo se enfocan en la exploración y asignación de funcionalidades y requerimientos del sistema Sub-proceso de Exploración de Conceptos Este sub-proceso contiene actividades referentes a la identificación de necesidades y planteamiento de soluciones en primera instancia Identificar ideas o necesidades A partir de los requerimientos planteados por el cliente, se identifican las principales ideas y necesidades del proyecto Formular soluciones potenciales Con base en las ideas y necesidades identificadas se elaboran soluciones potenciales Conducir estudios de viabilidad En esta actividad se conducen estudios de viabilidad sobre las soluciones potenciales planteadas. Se evalúan tanto los costos, beneficios y riesgos técnicos como comerciales y administrativos de la solución propuesta. Se evalúa el estudio de viabilidad y se selecciona la solución mas conveniente Refinar y Finalizar la idea o necesidad Seleccionada la solución, se refina y completa la descripción de la idea o necesidad del proyecto. 29

42 SOLUCION Sub-proceso de Asignación del Sistema Este sub-proceso es el nexo entre la Exploración de Conceptos y la Definición de Requerimientos del sistema Analizar las funciones del sistema Con base en la información obtenida a partir de la actividad de Refinación y Finalización de la Idea o Necesidad, se identifican y analizan las funciones del sistema contemplando requerimientos funcionales, no funcionales y restricciones Desarrollar la arquitectura del sistema: A partir del análisis de las funcionalidades del sistema se desarrolla la arquitectura básica del sistema Asignar los requisitos del Sistema: Mediante esta actividad y con base en la arquitectura del sistema, se categorizan las funcionalidades del sistema identificadas en torno los requerimientos que suponen, es decir, requerimientos de Software, Hardware o Entorno PROCESO DE DESARROLLO En este proceso se presentan las actividades referentes al modelado de requisitos, diseño e implementación de la solución Sub-proceso de Requisitos En este sub-proceso se presentan las actividades relacionadas al modelado de requisitos del sistema a desarrollar Definir y desarrollar los requisitos del software: Mediante esta actividad y con base en la asignación de requisitos se definen los requisitos de software del proyecto Definir y desarrollar los requisitos del hardware Mediante esta actividad y con base en la asignación de requisitos se definen los requisitos de hardware del proyecto Definir los requisitos del entorno Mediante esta actividad y con base en la asignación de requisitos se definen los requisitos de entorno del proyecto. 30

43 SOLUCION Definir los requisitos de interfaz Mediante esta actividad y con base en la asignación de requisitos se definen los requisitos de Interfaz del proyecto tanto con el usuario y el entorno como con otros sistemas Integrar los requisitos En esta actividad se analizan e integran los requisitos definidos anteriormente y se evalúan nuevos requerimientos surgidos durante este proceso como producto de la integración Sub-proceso de Diseño En este sub-proceso se definen las actividades inherentes al diseño arquitectónico y detallado del sistema Realizar el diseño arquitectónico Esta actividad transforma las especificaciones de requerimientos y la arquitectura del sistema en conceptos de diseño de alto nivel. El resultado de la misma es el diseño arquitectónico del software y hardware del sistema, con distintos niveles de abstracción Realizar el diseño de la base de datos (si aplica) Si el sistema prevé la utilización de una base de datos, en esta actividad debe ser diseñada Selección de la Arquitectura de Hardware mas conveniente. Esta actividad consta de la selección de la arquitectura de hardware mas conveniente a partir de la especificación de requisitos de hardware desarrollada Diseñar las interfaces El objetivo de esta actividad es el diseño de las interfaces del sistema ya sea con el entorno, el usuario u otros sistemas Realizar el diseño detallado En esta actividad se refina el diseño arquitectónico disminuyendo el nivel de abstracción empleado en cada componente del sistema. Como resultado de esta actividad, las estructuras de datos y algoritmos son especificadas, al igual que los módulos de hardware y su integración Sub-proceso de Implementación Durante este proceso se presentan las actividades necesarias para transformar el diseño detallado en un sistema compuesto por hardware y software integrado. 31

44 SOLUCION Configurar e integrar el hardware y las interfaces físicas Esta actividad sugiere el ensamblado del hardware y la integración de las interfaces físicas en la estructura principal del sistema Crear el código fuente Mediante esta actividad se genera el código fuente del programa Crear la Documentación operacional Durante esta actividad se genera la documentación necesaria para la instalación, operación y mantenimiento del sistema implementado Realizar la integración Esta actividad prevé la transformación del código fuente en una unidad ejecutable y su integración en el hardware ensamblado Gestionar las versiones del Software En caso de existir distintas versiones del software desarrollado, esta actividad prevé la compilación, nomenclatura y documentación de las mismas PROCESO DE POST-DESARROLLO Este proceso contiene el conjunto de actividades necesarias para conducir la instalación, operación, mantenimiento y eventual retiro del sistema Sub-proceso de instalación Mediante este sub-proceso se proponen las actividades necesarias para llevar a cabo exitosamente el proceso de instalación del sistema desarrollado en el entorno productivo Ajustar parámetros del entorno Mediante esta actividad y a partir del sistema ensamblado y la especificación de requisitos del entorno, se establecen las condiciones necesarias para el entorno de prueba Configurar y adaptar interfaces con el entorno productivo y otros sistemas Establecidas las condiciones del entorno, se ajustan las interfaces físicas del sistema para un despeño óptimo Aceptar el producto en el ambiente operativo Esta actividad consiste en el análisis de la información provista por el reporte de Instalación y Operación del Sistema y el reporte de Evaluación del Sistema y su contraste con las condiciones de 32

45 SOLUCION aceptación del usuario establecidas, a fin de determinar que el producto construido es el correcto. En esta actividad se contempla la participación del usuario durante la operación del sistema a fin de que, concluida la misma y bajo las condiciones adecuadas, el producto sea aceptado. La aceptación debe expresarse formalmente por escrito Sub-proceso de operación y soporte Este grupo de actividades supone la asistencia técnica al usuario durante el periodo en el cual el mismo opera el sistema por primera vez Operar el sistema Durante esta actividad, se opera el sistema siguiendo las instrucciones provistas en el manual de operación. Los resultados obtenidos son registrados para su utilización en los procesos de sugerencia de mejoras y en el Reporte de Instalación y Operación del Sistema Proveer asistencia técnica y consultas: Brindar asistencia técnica y proveer respuestas a cualquier consulta que provenga del usuario Mantener el histórico de peticiones de soporte: A través de esta actividad se registran todas las peticiones de registro efectuadas a lo largo del proyecto Sub-proceso de mantenimiento Este sub-proceso se compone de las actividades requeridas para la identificación y corrección de anomalías y la implementación de mejoras en el sistema Identificación de necesidades de mejora del Software lo largo de esta actividad y con base en el Reporte de Instalación del Sistema y los datos entregados por la metodología de Reporte de Problemas, se identifican las necesidades de mejora del Software Identificación de necesidades de mejora del Hardware y Entorno Configurable A lo largo de esta actividad y con base en el Reporte de Instalación del Sistema y los datos entregados por la metodología de Reporte de Problemas, se identifican las necesidades de mejora del Hardware y Entorno configurable Implementación de un método de reporte de problemas Esta actividad prevé la implementación de una metodología de reporte de problemas de cualquier índole y origen a lo largo del proyecto. Es posible la sugerencia de soluciones potenciales a los 33

46 SOLUCION problemas detectados así como también de mejoras. Cualquier corrección o mejora implementada debe ser registrada para futuras consideraciones Iteración del Ciclo de Vida: Los registros provistos por la Metodología de Reporte de Problemas, en conjunto con las sugerencias de mejora del Software, Hardware y entorno configurable son la base de la iteración del Ciclo de Vida del Proyecto a partir del Subproceso Exploración de Conceptos. Esta actividad busca controlar de manera certera las tareas de corrección de los problemas identificados a fin de asegurar y registrar su concreción Sub-proceso de retiro Este grupo de actividades contempla las tareas necesarias para el retiro del sistema ya sea bien por el cese de las operaciones o por el remplazo del mismo por una versión nueva o actualizada Notificar al usuario Esta actividad consta de la notificación formal a los usuarios internos y externos del sistema que el mismo sera retirado de servicio parcial o prontamente. Se deben proveer fechas exactas a fin de tomar los recaudos necesarios que permitan evitar impactos negativos no deseados en el normal funcionamiento de la organización Conducir operaciones en paralelo (si aplica) Si el sistema sera reemplazado por uno nuevo o una versión actualizada del mismo, se debe planificar la operación simultanea temporal de ambos (el sistema nuevo y el sistema a retirar) a fin de garantizar una transición segura y exitosa Retirar el sistema Esta actividad supone la remoción y archivo del sistema en concordancia con el Plan de Retiro previsto PROCESOS INTEGRALES DEL PROYECTO Este proceso supone las actividades necesarias para la finalización exitosa y el aseguramiento de la calidad del proyecto Subproceso de Evaluación Este subproceso contiene las actividades destinadas a verificar técnicamente el sistema y auditar los procesos utilizados a lo largo del proyecto. 34

47 SOLUCION Conducir Revisiones Diferentes tipos de revisiones son realizadas a lo largo del proyectos. Estas pueden pertenecer a las siguientes categorías: Revisiones Técnicas Destinadas a detectar y corregir errores en las etapas preliminares de requisitos y diseño, codificación e implementación y prueba del sistema Revisiones Gerenciales Tienen por objetivo asegurar el progreso del proyecto, un correcto uso de los recursos y recomendar acciones correctivas Inspecciones Tienen por objetivo detectar e identificar defectos en el producto y controlar su corrección Walkthroughs Tienen por objetivo detectar defectos de un producto, examinar alternativas y generar un foro de aprendizaje Crear Matriz de Trazabilidad La matriz de Trazabilidad busca asegurar que todas las requisitos funcionales y no funcionales serán evaluados en al menos 1 caso de prueba Conducir Auditorías Si bien es posible y aconsejable realizar auditorías internas complementarias, las auditorías deben ser efectuadas por examinadores independientes al proyecto y preferentemente a la organización. Su propósito principal es el relevamiento y revisión de los productos desarrollados y los procesos utilizados a lo largo del proyecto a fin de evaluar su conformidad ante normas internas o externas ya sean de seguridad, calidad, etc., o bien ante cualquier tipo de acuerdo que pudiere existir con el cliente Desarrollar Procedimientos de prueba Mediante esta actividad se desarrollan los procedimientos de prueba para los distintos niveles del sistema (pruebas unitarias, de integración, de aceptación, de regresión y sistema). Se debe especificar el tipo de prueba (caja blanca o negra), los ítems a evaluar, los datos de prueba a utilizar, los resultados esperados, los requerimientos de entorno y los procedimientos a seguir para llevar a cabo las pruebas. 35

48 SOLUCION Crear datos de prueba A través de esta actividad y con base en en las especificaciones de requerimientos, el diseño detallado del sistema y el código fuente, se construyen los datos necesarios para llevar a cabo los diversos procedimientos de prueba. En caso de tratarse de pruebas de regresión, se requerirá la información correspondiente a las evaluaciones fallidas que motivaron su realización y los aportes surgidos de la experiencia de los usuarios Ejecutar pruebas Mediante esta actividad se configura el entorno de evaluación y se llevan a cabo los procedimientos descriptos en los casos de prueba, utilizando los datos generados. Esta actividad puede ser iterativa y realizada en diversas etapas del ciclo de vida del proyecto según se considere necesario. La conclusión exitosa de la prueba estará determinada por la coincidencia de los valores esperados y los valores obtenidos en las pruebas y bajo el marco de la especificación de criterios de aprobación establecida Reportar Resultados de la evaluación Mediante esta actividad se presentan los resultados de los procedimientos de prueba ejecutados Confirmar Acreditación de Seguridad Mediante esta actividad el sistema obtiene la autorización formal para operar en el entorno productivo. Para ello, totalidad de la documentación del proyecto debe ser verificada y aprobada por escrito por una autoridad de la organización, capaz de asumir la responsabilidad por los potenciales riesgos que puedan surgir durante la operación del sistema Sub-proceso de gestión de la configuración Este sub-proceso identifica los componentes del sistema desarrollado y asiste tanto en su control como en la generación de informes de situación destinados a las áreas gerenciales y financieras de la organización Realizar la identificación de la configuración Mediante esta actividad se debe identificar la configuración de todos los productos del proyecto ya sean entregables o no, técnicos o documentales Realizar el control de la configuración A través de esta actividad se realiza el control de la configuración de los productos identificados acorde a lo establecido en el Ciclo de Vida del Proyecto. Los cambios realizados en los productos identificados deben ser debidamente registrados. 36

49 SOLUCION Realizar la información del estado de la configuración Mediante esta actividad y con base en la información provista por el proceso de identificación y control de la configuración y el Reporte de Cambios Control de Cambios, se genera un Informe de Estado de la Configuración del Sistema Sub-proceso de desarrollo de Documentación Este subproceso prevé el diseño, implementación, edición, distribución y mantenimiento de la documentación técnica y procedimental necesarias tanto para los usuarios como los desarrolladores del sistema Implementar la Documentación Esta actividad incluye el diseño, elaboración y mantenimiento de la documentación Producir y Distribuir la Documentación Elaborada la documentación, se debe producir y distribuir la misma entre sus usuarios. Esta puede ser presentada en formato digital, escrito o cualquier otro medio de presentación según la audiencia lo requiera Sub-proceso de Formación A lo largo de este proceso se presentan las actividades necesarias para conducir las tareas de formación de recursos y usuarios del sistema Desarrollar los materiales de formación Esta actividad consta de la identificación y revisión de los materiales e información disponibles, pertinentes a los objetivos de entrenamiento. Se prevé el desarrollo de manuales y materiales necesarios para llevar a cabo las actividades de entrenamiento. Los instructores deber revisar el material de formación y desarrollar presentaciones Validar el programa de formación Esta actividad consiste en la presentación del entrenamiento por parte de los instructores, a una clase compuesta de evaluadores, utilizando los manuales y materiales desarrollados en detalle. El objetivo de la actividad es la validación de la exposición y el material elaborado antes de su utilización. 37

50 SOLUCION Implementar el programa de formación Esta actividad contempla la provisión de los materiales y la locación necesarios para el entrenamiento y la ejecución del mismo en concordancia con las pautas establecidas en el Plan de Entrenamiento PROCEDIMIENTO DE IMPLEMENTACIÓN DE LA SOLUCIÓN En esta sección se presentan y describen los pasos a seguir para la implementación de la solución en un caso de aplicación. Estos son; (1) Selección de un Modelo de Ciclo de Vida. (2) Mapa de Actividades (Sección ), (3) Creación del Ciclo de Vida del Proyecto (Sección ), (4) Secuenciamiento de Actividades (Sección ), (5) Asignación de Documentos de Salida (Sección ) y (6) Iniciación del Proyecto (Sección ) SELECCIÓN DE UN MODELO DE CICLO DE VIDA Inicialmente se debe identificar, evaluar y seleccionar un Modelo de Ciclo de Vida acorde a las características, necesidades y expectativas del proyecto y en el cual posteriormente realizar la asignación de las actividades previstas. El proceso de evaluación y selección del modelo de ciclo de vida consta de 5 pasos: Identificar todos los modelos de ciclo de vida disponibles para el proyecto Identificar los atributos que aplican al finalidad del sistema deseado y al entorno del proyecto Identificar las limitaciones que podría suponer la selección del modelo de ciclo de vida evaluado Evaluar modelos de ciclo de vida utilizados en proyectos anteriores Seleccionar el modelo de ciclo de vida que mejor satisfaga los atributos y limitaciones del proyecto CREACIÓN DEL CICLO DE VIDA DEL PROYECTO. MAPA DE ACTIVIDADES Seleccionado y presentado el Modelo de Ciclo de Vida es tiempo de elaborar el Ciclo de Vida del Proyecto. Esta actividad comienza a partir de la confección de un Mapa de Actividades, el cual contiene la asignación de las actividades propuestas por la solución, a las fases propuestas en el Modelo de Ciclo de Vida seleccionado en el paso anterior. En el Mapa de Actividades además, se deben listar las actividades desestimadas y justificar las razones que motivaron tal decisión. 38

51 SOLUCION En este paso además, todas las actividades seleccionadas son nomencladas mediante un codigo identificador para su referencia a lo largo de todo el proyecto SECUENCIAMIENTO DE ACTIVIDADES Asignadas las actividades a realizar, se debe proceder a su organización en torno a la secuencia de ejecución apropiada para el Proyecto. Para ello se genera un cuadro de Secuencia de Actividades organizadas en torno a las fases definidas por el Modelo de Ciclo Vida seleccionado y la secuencia temporal de ejecución mas apropiada ASIGNACIÓN DE DOCUMENTOS DE SALIDA Organizadas las actividades en torno a una secuencia de ejecución, solo resta definir que documentos serán producidos durante el proyecto y la intervención de cada actividad en la conformación de los mismos Para ello se elabora un Mapa de Documentación que relaciona todas las actividades previstas con los documentos a desarrollar INICIACIÓN DEL PROYECTO Los resultados de las actividades anteriormente descriptas conforman el primer documento del Proyecto, titulado Inicialización del Proyecto. El mismo será la guía principal y fuente de consulta permanente a lo largo de todo el proyecto y concluido el mismo formará parte del registro histórico de la organización. A continuación, en la figura 4.1 se ilustra la secuencia de ejecución de procedimiento explicado. La misma se puede organizar en torno a 4 bloques principales; Selección de un Modelo de Ciclo de Vida (SMCV), Creación del Ciclo de Vida del Proyecto (CCVP), Secuenciamiento de Actividades (SA) y Asignación de Documentos (AD). Cada uno de esos bloques se alimenta de una entrada y otorga una salida que alimenta al modulo siguiente. 39

52 SOLUCION Selección de un modelo de ciclo de vida Modelo de Ciclo de Vida Creación del Ciclo de vida del proyecto Ciclo de Vida y Mapa de Actividades Secuencia de Actividades Secuencia de Actividades Asignación de documentos Inicio del Proyecto Mapa de Documentos Figura 4.1. Secuencia de implementación del modelo solución. En el capitulo número 5 titulado Prueba de Concepto, se presenta un caso de aplicación real de la solución propuesta, a fin de validar su factibilidad de aplicación en un entorno práctico. 40

53 PRUEBA DE CONCEPTO 5. PRUEBA DE CONCEPTO A lo largo este capitulo se presenta un caso de potencial aplicación en la industria a fin de verificar la validez y plausibilidad de la solución planteada en el capitulo anterior. En la sección 5.1 se describe la prueba de concepto a realizar, focalizando el análisis en la descripción del negocio (Sección 5.1.1) y del producto a desarrollar (Sección 5.1.2). Por ultimo se da inicio a la ejecución de la prueba de concepto (Sección 5.2) 5.1. DESCRIPCION DE LA PRUEBA DE CONCEPTO: INSPECCION DE CULTIVOS EN INVERNADERO En esta sección se analiza el caso de aplicación planteado, correspondiente a la construcción de un robot autónomo móvil utilizando un sistema embebido, destinado a tareas de relevamiento de condiciones de temperatura y humedad en invernaderos DESCRIPCIÓN DEL NEGOCIO El trabajo en invernaderos [González et al, 2007] requiere de una serie de tareas repetitivas, tediosas y usualmente perjudiciales para la salud por la posible inhalación de productos insecticidas, que son susceptibles de ser robotizadas. Las actividades como control de condiciones ambientales de temperatura y humedad de los cultivos, pulverización de insecticidas, recolección o transporte de materiales, etc, implican un movimiento en el interior del invernadero, por lo cual disponer de una unidad con capacidad autónoma de desplazamiento sería de real utilidad y conveniencia. Ahora bien, Por que automatizar este tipo de tareas? Que beneficios supondría respecto de la ejecución de las mismas por parte de personal humano?. Como bien sabemos, toda actividad comercial como la que nos compete en esta ocasión, cultivo y cosecha de flores y hortalizas en invernadero, persiguen un interés económico principalmente regido por el margen de ganancias que la misma pueda generar. Ese margen de ganancias se obtiene a partir de la sustracción al monto de dinero obtenido por ventas, del monto invertido en los recursos necesarios para la elaboración de los productos a comercializar, en este caso, flores y hortalizas. A la hora de pensar de manera general en los recursos necesarios para la realización exitosa de esta actividad, podemos mencionar la necesidad de contar con; ( a ) infraestructura necesaria para el montaje de los invernaderos, ( b ) materia prima; semillas, fertilizantes, tierra, etc, en este caso, y ( c ) personal capaz de llevar a cabo las tareas de siembra, mantenimiento y recolección del producto, entre otras. La implementación de un robot autónomo móvil en este entorno, podría suponer una reducción en los recursos humanos abocados a las tareas de siembra, mantenimiento y recolección del producto. 41

54 PRUEBA DE CONCEPTO una disminución en los tiempos de operación, una consecuente posibilidad de aumentar el volumen de producción y un incremento en los niveles de control sobre los procesos utilizados, que permita llevar a cabo una mejora continua de la calidad de los productos elaborados DESCRIPCIÓN DEL PRODUCTO A DESARROLLAR El robot desarrollado deberá ser capaz de recorrer de manera autónoma y periódica la totalidad de los invernaderos existentes a fin de relevar las condiciones de temperatura y humedad relativa presentes en cada uno de ellos. En un caso de aplicación real en la industria, el robot podría incorporar capacidades de recolección y transporte de materiales, pulverización de insecticidas en los cultivos, acceso remoto a los datos relevados y modificación de las políticas de funcionamiento del robot por parte del usuario, entre otras. Esto supondría una modificación en la especificación de requisitos que podría eventualmente derivar en una modificación del hardware y software utilizado aunque la implementación del modelo de gestión propuesto en este Trabajo Final de Licenciatura no presentaría variación respecto de su metodología de aplicación y eficacia. Por tratarse simplemente de una prueba de concepto que busca validar la factibilidad de implementación de una solución propuesta, la aplicación contemplará simplemente el desempeño de manera autónoma del robot y el relevamiento de valores de temperatura y humedad en los cultivos. La descarga de los registros obtenidos será realizada de manera manual IMPLEMENTACIÓN DE LA PRUEBA DE CONCEPTO Descriptos el negocio (Sección 5.1.1) y el producto a desarrollar (Sección 5.1.2) y conocida la solución propuesta (Capitulo 4), se procede a la implementación del nuevo modelo a fin de elaborar y conducir exitosamente un proyecto destinado al control de Robot Autónomo Móvil basado en una Arquitectura de Sistema Embebido, capaz de llevar a cabo tareas de relevamiento de condiciones ambientales tales como humedad y temperatura en invernaderos. Se adjunta a la presente el ANEXO IV, conteniendo la totalidad de los documentos desarrollados como consecuencia de la implementación de la solución propuesta para la elaboración del sistema requerido. Para continuar con la secuencia de ejecución de la prueba de concepto, dirigirse al capítulo inicial de dicho anexo, titulado Iniciación del Proyecto. En él se describe la estructura general del proyecto y se referencian los documentos y productos elaborados y las actividades realizadas a lo largo del proyecto. 42

55 PRUEBA DE CONCEPTO 6. CONCLUSIONES En este Capítulo se enuncian los aportes de este trabajo (Sección 6.1) y se destacan las futuras líneas de investigación que se consideran de interés en base al problema abierto presentado (Sección 6.2) APORTES DEL TRABAJO FINAL DE LICENCIATURA A modo de respuesta al interrogante planteado en el capitulo numero tres, podemos afirmar que a lo largo de este trabajo se ha validado la posibilidad de generar un nuevo modelo de gestión integral de proyectos destinados al control de Robots Autónomos Móviles basados en Arquitecturas de Sistemas Embebidos, a partir de la adaptación y combinación de modelos y standards existentes en la actualidad en el dominio de los sistemas informáticos y que el mismo a sido sometido a un caso de prueba en el cual se ha desempeñado de la manera esperada. En este contexto, podemos afirmar que este trabajo final de licenciatura ha propuesto: Un modelo de gestión integral de proyectos destinados al control de Robots Autónomos Móviles basados en Arquitecturas de Sistemas Embebidos, que busca abordar los proyectos desde su fase de planificación hasta la puesta en producción, mantenimiento y retiro del sistema desarrollado, dotar de un mayor carácter sistémico y profesional a la actividad y garantizar la calidad de los productos desarrollados a través del aseguramiento de la calidad de los procesos implementados. Las fases propuestas son Gestión del Proyecto, Pre- Desarrollo, Desarrollo, Post-Desarrollo y Procesos integrales del Proyecto y las mismas son desmembradas en subprocesos, actividades, técnicas sugeridas y documentación de salida. Un informe de relevamiento de las arquitecturas de hardware potencialmente utilizables en robótica autónoma y disponibles en el mercado local e internacional a la fecha de redacción de este trabajo final de licenciatura. Un informe del relevamiento de modelos y técnicas disponibles en la base de conocimiento de los sistemas informáticos -disponibles a la fecha de redacción de este trabajo final de licenciatura- que inspiraron e influyeron la creación del modelo propuesto. Una matriz comparativa que se desprende del informe de relevamiento de hardware realizado y que busca agilizar el proceso de selección de la arquitectura que mejor se adapte a la especificación de requerimientos del proyecto. La misma posee información de los 43

56 PRUEBA DE CONCEPTO desarrollos disponibles al momento de redacción de este trabajo final de licenciatura, aunque establece la estructura necesaria para su adaptación a los constantes cambios en materia de tecnología. El modelo propuesto ha sido sometido a una prueba de concepto que simula un requerimiento productivo surgido del mercado. El mismo se trata de la necesidad de automatización de un conjunto de tareas desarrolladas en invernaderos como el relevamiento de sus condiciones de temperatura y humedad relativa FUTURAS LÍNEAS DE INVESTIGACIÓN Del proceso de desarrollo de este trabajo final de licenciatura en sistemas, se desprenden las siguientes cuestiones que darían lugar a futuras lineas de investigación: En la fase final del modelo propuesto se propone la realización de una auditoría completa del proyecto a fin validar los productos elaborados a partir del análisis de los procesos utilizados en su construcción y la evaluación de la conformidad del proyecto con normas internas o externas a la organización ya sean de seguridad o calidad, legislaciones, etc, o bien ante cualquier tipo de acuerdo que pudiera existir con el cliente. En este marco, el profesional de sistemas debe enfrentar situaciones que se encuentran fuera de su ámbito de acción y para las cuales no se encuentra debidamente capacitado. De los motivos anteriormente descriptos surgen los siguientes interrogantes: Es posible la creación de un modelo de auditoría de proyectos destinados al control de Robots Autónomos Móviles basados en Arquitecturas de SE, capaz de guiar al profesional de sistemas en la auditoría de los procesos utilizados y productos desarrollados a lo largo de los mismos? Es necesario acudir profesionales de otras disciplinas? En caso afirmativo, que disciplinas deberían ser tenidas en cuenta? A lo largo de este Trabajo Final de Licenciatura se han adaptado y modificado en número y contenido, diversos procesos, subprocesos, técnicas y documentos propuestos por un standard referente de la ingeniería de software y se han integrado a su estructura, modelos de procesos y técnicas de probado éxito en la fase de IR de Sistemas Embebidos a fin de obtener un nuevo modelo que permita gestionar de manera integral proyectos 44

57 PRUEBA DE CONCEPTO destinados a la producción de sistemas de esta índole. En este contexto se plantea el siguiente interrogante: Existen técnicas o modelos en el cuerpo de conocimiento de los sistemas embebidos o áreas afines, capaces de ser integrados a uno o mas subprocesos o actividades del modelo propuesto? Si bien el modelo generado aporta sistematicidad al proceso de gestión de proyectos destinados al control de RAM basados en ASE y el mismo ha sido sometido a un caso de prueba representativo de una situación de aplicación real, se recomienda su implementación en un proyecto de dimensiones mayores al presentado durante la prueba de concepto y surgido de una necesidad productiva real, a fin de validar su eficacia y evaluar su eficiencia de manera mas precisa. 45

58 PRUEBA DE CONCEPTO 46

59 REFERENCIAS 7. REFERENCIAS Azcurra, D., Rodriguez, D., Pytel, P., Santos, D., Giordano, V., Arboleya, H., García- Martínez, R. (2011). Arquitecturas de Sistemas Embebidos utilizables en Robótica Autónoma. Grupo Investigación en Sistemas de Información Departamento Desarrollo Productivo y Tecnológico. Universidad Nacional de Lanús. Cheng, B, Konrad, S, Kamdoum, S. (2006). Enabling a Roundtrip Engineering Process for the Modeling andanalysis of Embedded Systems. Proceedings of the ACM/IEEE International Conference on Model Driven Engineering Languages and Systems (MODELS 2006). Fritz, W. (1984). The Intelligent System. SIGART Newsletter, 90: ISSN Fritz, W. (1992). World view and learning systems. Robotics and Autonomous Systems 10(1): 1-7. ISSN Garcia Martinez. (2009 ). Ciclo de Vida de Software, Proceso Software y Plan de Actividades. Guía de Estudio de la Materia Ingeniería de Software I, Cohorte 2008, Lic. Sistemas, UNLa. R. González 1(P), F. Rodríguez, J. Sánchez-Hermosilla, J. G. Donaire (2007). Experiencias en Sistemas de Navegación de Robots móviles para tareas en invernadero. IV Congreso Nacional y I Congreso Ibérico de Agroingeniería. Gonzalez Palacio, L., Urrego Giraldo, G. (2008). Modelo de Requisitos para Sistemas Embebidos. Heather J. Goldsby1, Sascha Konrad, Betty H.C. Cheng. (2007) Goal-Oriented Patterns for UML- Based Modeling of Embedded Systems Requirements. Heath, Steve (2003). Embedded Systems Design. IEEE (1990) Software Engineering Standards Committee of the IEEE Computer Society (1990). IEEE Standard Glossary of Software Engineering Terminology, IEEE std

60 REFERENCIAS IEEE (2006) Software Engineering Standards Committee of the IEEE Computer Society (2006). IEEE Standard for Developing Software Life Cycle Processes. IEEE (2013) Software Engineering Standards Committee of the IEEE Computer Society (1990). URL Sitio vigente 11/2013 Kovitz, B. (2001). Is backtracking so bad? The role of learning in software development. Proceedings of Fifth IEEE International Symposium on Requirements Engineering, Toronto, Canada, pp Lavi, J, Kudish, J. (2005). Systems modelling & requirements specification using ECSAM: an Analysis Method for Embedded & Computer-based Systems. Innovations Syst Softw Eng. 1: Peláez, J (2013). El desarrollo de Software. Sitio vigente 11/2013 Ross, D, Schoman, K. (1977). Structured Analysis for Requirements Definition. Transactions on Software Engineering, IEEE, 3(1): Tangelson, O (2004). Argentina frente al siglo XXI. Desarrollo e Integración. Departamento de DesarrolloProductivo y Tecnológico. Universidad Nacional de Lanús. 48

61 ANEXO I RELEVAMIENTO DE HARDWARE CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS Propuesta de Modelo de Aplicación y Uso Potencial Jonatan Ponzo - ponzo.jonatan@gmail.com Universidad Nacional de Lanús Lic. Sistemas ANEXO I RELEVAMIENTO DE HARDWARE 49

62 ANEXO I RELEVAMIENTO DE HARDWARE 50

63 ANEXO I RELEVAMIENTO DE HARDWARE ANEXO I RELEVAMIENTO DE HARDWARE A lo largo de este documento se realizará un análisis técnico y posterior caracterización según su potencial aplicación en la industria, de 8 desarrollos de hardware preseleccionados en representación de 5 familias tecnológicas diferentes, focalizando en la identificación de sus principales atributos y falencias, su disponibilidad en el mercado y el nivel de accesibilidad a las mismas por parte de una PyME. Los desarrollos seleccionados que serán objeto de comparación a lo largo de este documento pertenecen a las familias Arduino, PIC, Raspberry Pi, PC/104 y Freescale y los principales aspectos a contrastar serán: 1. Arquitectura del microprocesador, frecuencias soportadas y principales características del mismo. 2. Dimensiones y condiciones de ambiente soportadas por el producto. 3. Disposición y características de la Memoria de datos y Programa, 4. Interfaces de entrada/salida disponibles 5. Módulos de expansión compatibles 6. Programación 7. Disponibilidad en el mercado local e internacional y costos 8. Espectro de aplicación Para comenzar realizaremos una breve descripción de cada familia a modo introductorio del posterior análisis técnico comparativo de los desarrollos seleccionados. 51

64 ANEXO I RELEVAMIENTO DE HARDWARE 1. INTRODUCCIÓN A LAS FAMILIAS SELECCIONADAS Existen 5 familias que engloban a los 8 desarrollos seleccionados. Ellas son Arduino, PIC, Raspberry PI, Freescale y PC/104. Cada una de ellas posee características técnicas, físicas y comerciales que las diferencian del resto y las presuponen mas aptas para su aplicación en diversos nichos productivos ATMEL AVR - ARDUINO Arduino es una plataforma de hardware libre basada en una placa con un micro controlador Atmel AVR, diversos puertos de entrada/salida y un entorno de desarrollo y esta básicamente diseñada para facilitar el uso de la electrónica en proyectos multidisciplinarios [2]. Los micro controladores AVR presentan una arquitectura tipo Harvard 8-bit RISC modificada desarrollada por Atmel en 1996 y es una de las primeras familias en implementar un chip de memoria flash para el almacenamiento del programa en lugar de ROM, EPROM o EEPROM. Los más usados por Arduino dentro de esta familia son son el Atmega168, Atmega328, Atmega1280 y ATmega8 por su sencillez y bajo coste. El lenguaje de programación de Arduino es una implementación de Wiring, una plataforma de computación física parecida, que a su vez se basa en Processing, un entorno de programación multimedia. El entorno de desarrollo integrado es libre y se puede descargar gratuitamente [3]. Arduino se puede utilizar para desarrollar objetos interactivos autónomos o puede ser conectado a software del ordenador (por ejemplo: Macromedia Flash, Processing, Max/MSP, Pure Data). Las placas pueden ser montadas a mano o adquirirse ensambladas y al ser open-hardware, tanto su diseño como su distribución es libre. Es decir, puede utilizarse libremente para el desarrollo de cualquier tipo de proyecto sin haber adquirido ninguna licencia [2]. El modelo seleccionado como objeto de comparación en representación de esta familia es el Arduino UNO. Fig. 1. Arduino UNO 52

65 ANEXO I RELEVAMIENTO DE HARDWARE 1.2. PIC PIC es una familia de microcontroladores tipo RISC fabricados por Microchip Technology Inc. y derivados del PIC1650, originalmente desarrollado por la división de microelectrónica de General Instrument. El nombre actual no es un acrónimo. En realidad, el nombre completo es PICmicro, aunque generalmente se utiliza como Peripheral Interface Controller (controlador de interfaz periférico) [32]. El PIC original se diseñó para ser usado con la nueva CPU de 16 bits CP Siendo en general una buena CPU, ésta tenía malas prestaciones de entrada y salida, y el PIC de 8 bits se desarrolló en 1975 para mejorar el rendimiento del sistema quitando peso de E/S a la CPU. El PIC utilizaba microcódigo simple almacenado en ROM para realizar estas tareas; y aunque el término no se usaba por aquel entonces, se trata de un diseño RISC que ejecuta una instrucción cada 4 ciclos del oscilador[32]. En 1985 la división de microelectrónica de General Instrument se separa como compañía independiente que es incorporada como filial (el 14 de diciembre de 1987 cambia el nombre a Microchip Technology y en 1989 es adquirida por un grupo de inversores) y el nuevo propietario canceló casi todos los desarrollos, que para esas fechas la mayoría estaban obsoletos. El PIC, sin embargo, se mejoró con EPROM para conseguir un controlador de canal programable. Hoy en día multitud de PICs vienen con varios periféricos incluidos (módulos de comunicación serie, UARTs, núcleos de control de motores, etc.) y con memoria de programa desde 512 a palabras (una palabra corresponde a una instrucción en lenguaje ensamblador y puede ser de 12, 14, 16 ó 32 bits, dependiendo de la familia específica de PICmicro)[32]. Los viejos PICs con memoria PROM o EPROM se están renovando gradualmente por chips con memoria Flash. Así mismo, el juego de instrucciones original de 12 bits del PIC1650 y sus descendientes directos ha sido suplantado por juegos de instrucciones de 14 y 16 bits. Microchip todavía vende versiones PROM y EPROM de la mayoría de los PICs para soporte de aplicaciones antiguas o grandes pedidos [32]. Se pueden considerar tres grandes gamas de MCUs PIC en la actualidad: Los básicos (Linebase), los de medio rango (Mid Range) y los de alto desempeño (high performance). Los PIC18 son considerandos de alto desempeño y tienen entre sus miembros a PICs con módulos de comunicación y protocolos avanzados (USB, Ethernet, Zigbee por ejemplo). 53

66 ANEXO I RELEVAMIENTO DE HARDWARE Se ha seleccionado en representación de esta familia, el desarrollo ICP05 - IBOARD LITE el cual permite la utilización de una gran variedad de PICs de 40 PINs [32]. Fig. 2. ICP05 iboard Lite 1.3. ARM - RASPBERRY PI La Raspberry Pi es una placa computadora (SBC) de bajo coste desarrollada en Reino Unido por la Fundación Raspberry Pi. Su diseño incluye un procesador ARM1176JZF-S a 700 MHz y 256 MiB de memoria RAM con el objetivo de ejecutar Linux. No incluye un disco duro o una unidad de estado sólido sino que utiliza una tarjeta SD para el sistema operativo y el almacenamiento permanente de datos [23]. El desarrollo del dispositivo es llevado a cabo por la Fundación Raspberry Pi, una asociación caritativa registrada en la Comisión de Caridad de Inglaterra y Gales cuyo objetivo es "Promover el estudio de las ciencias de la computación y temas relacionados, sobre todo a nivel escolar a fin de recuperar la diversión de aprender computación" [23]. La Fundación Raspberry Pi promoverá principalmente el aprendizaje del lenguaje de programación Python, aunque también apoyará el uso de BBC BASIC y Perl. Muchos otros lenguajes que tienen soporte para Linux y ARM estarán disponibles también y serán mencionados posteriormente. [23] Actualmente existen 2 modelos de Raspberry en el mercado, el Modelo A y el Modelo B, siendo el ultimo una evolución técnica de su antecesor. A diferencia del modelo A, el modelo B incorpora un segundo puerto USB2.0 y un puerto de red 10/100 Base T. Si bien aún no se ha integrado un modulo WiFi, existe la posibilidad de utilizar un adaptador WiFi USB. Al momento Raspberry Pi no es hardware libre sin embargo, miembros de la fundación dieron a conocer su intención de liberar los esquemas y diagramas del producto a fin de promover el desarrollo de módulos compatibles con el mismo [23]. 54

67 ANEXO I RELEVAMIENTO DE HARDWARE Seleccionaremos el Modelo B como objeto de comparación. Fig. 3. Raspberry Pi 1.4. FREESCALE - EDUKIT 08 Freescale Semiconductor Inc. es un fabricante estadounidense de semiconductores creado a partir de la división de semiconductores de Motorola en 2004 centrada en el mercado de los sistemas integrados y las comunicaciones [34]. Freescale también se ha estado encargando de los procesadores PowerPC para los Apple PowerBook y Mac mini hasta la transición de Apple a Intel en La compañía forma parte desde 2006 de Power.org como miembro fundador de esta asociación para el desarrollo y promoción de la arquitectura PowerPC [34]. El sistema EDUKIT08 es una plataforma universal que permite trabajar con las familias más populares de 8 y 32 Bits de Freescale Semiconductor y realizar prácticas completas con una gran variedad de periféricos en un ambiente controlado que facilita el aprendizaje del estudiante del área de microcontroladores. [16 et al] Fig. 4. Edukit08 55

68 ANEXO I RELEVAMIENTO DE HARDWARE Gracias al diseño removible de las placas PLUGIN, el sistema puede personalizarse para trabajar en las distintas familias de 8 Bits y de 32 Bits Flash que posee Freescale, haciendo que el sistema evolucione hacia familias más poderosas y con más prestaciones que la popular HC908. De esta forma, el sistema se adapta a las necesidades de los distintos niveles de estudio que presenta una carrera técnica, tanto en el ámbito de escuelas técnicas, como en el de las universidades, institutos o áreas de capacitación técnica dentro de las empresas. [16 et al] El EDUKIT08 permite al estudiante trabajar en forma profesional usando herramientas de depuración de código de programa avanzadas, como la Emulación en Tiempo Real o la grabación En Circuito de la memoria Flash del MCU bajo estudio, sin complicaciones de ningún tipo, en un ambiente controlado, guiado paso a paso y con un completo soporte teórico-práctico totalmente en castellano. [16 et al] El sistema ha sido diseñado para soportar el mal trato de los estudiantes, muy frecuente durante el aprendizaje, y la fácil y rápida reparación del mismo si así lo requiriera, ya que se entrega con documentación completa y detallada del mismo. [16 et al] El sistema EDUKIT08 está compuesto por una placa base o plataforma de trabajo (Motherboard) y una placa de personalización para la familia HC908 (Placa PLUGIN_AP ) que contiene al MCU MC908AP32CFBE, uno de los miembros más completos de esta popular familia. [16 et al] 1.5. PC/104 PC/104 o PC104 es un estándar de ordenador embebido controlado por el Consorcio que lleva su nombre y que define entre otras cosas, el formato de la placa base o Form Factor y el bus del sistema a fin de facilitar y garantizar la comunicación y expansión entre diversos desarrollos así como la optimización del espacio y los recursos de interconexión [17]. Existen 3 versiones que responden a esta norma; PC/104, PC/104-PLUS y PCI-104. El bus de la versión de 1992 del PC/104 usa 104 pines. Estos pines incluyen todas las líneas normales usadas por el bus ISA, además añade líneas de masa para mejorar la integridad de las señales. La sincronización de las señales y los niveles de tensión son idénticos al bus ISA, pero con menos requisitos de corriente [17]. De forma similar, el bus del PC/104-Plus es una versión compacta del bus PCI. En este caso nos basaremos en desarrollos PC/104 standard. 56

69 ANEXO I RELEVAMIENTO DE HARDWARE A diferencia de la clásica arquitectura ATX y bus PCI que son usados en la mayoría de los ordenadores personales, el PC/104 está diseñado para aplicaciones específicas, como adquisición de datos o sistemas de control industrial en ambientes no tradicionales. La arquitectura de la placa base no es la típica placa de circuitos integrados backplane en el que van insertados los componentes; en lugar de eso, los componentes se encuentran en módulos que son apilados unos encima de otros. El tamaño estándar es de mm mm y la altura es proporcional al número de módulos conectados. Una instalación típica incluye una placa base, conversores analógico-digital y módulos I/O digitales [17]. La arquitectura del microprocesador dependerá de la placa base seleccionada. Existen desarrollos que implementan PIC, AMD, ARM, Intel y Vortex entre otros. Seleccionaremos 1 modelo por cada arquitectura a fin de adicionar una etapa comparativa interna dentro de la misma familia: Pic Microstack, Cool LiteRunner-ECO, Cool LiteRunner-LX800 y CoreModule 435. Fig. 5. PC/104 Developments 2. MICROPROCESADOR: ARQUITECTURA, FRECUENCIAS DISPONIBLES Y CARACTERÍSTICAS PRINCIPALES Presentadas las familias, haremos un recorrido por los diversos desarrollos seleccionados focalizando el análisis en aspectos que entendemos ayudaran a su posterior categorización e identificación del entorno mas apropiado para su aplicación. Los aspectos que serán el foco principal del análisis son: 1. Microprocesador. Arquitectura, frecuencias disponibles y características principales.. 2. Dimensiones, alimentación y condiciones de ambiente soportadas por el producto. 3. Disposición y características de la Memoria de datos y Programa, 57

70 ANEXO I RELEVAMIENTO DE HARDWARE 4. Interfaces de entrada/salida disponibles 5. Módulos de expansión compatibles 6. Programación 7. Disponibilidad en el mercado local e internacional y costos 8. Espectro de aplicación 2.1. ARDUINO - ARDUINO UNO Como mencionamos durante la introducción, Arduino implementa microcontroladores de la familia AVR. El AVR es una CPU de arquitectura Harvard, posee 32 registros de 8 bits aunque algunas instrucciones sólo operan en un subconjunto de estos registros. La concatenación de los 32 registros, los registros de entrada/salida y la memoria de datos conforman un espacio de direcciones unificado, al cual se accede a través de operaciones de carga/almacenamiento. A diferencia de los microcontroladores PIC, el stack se ubica en este espacio de memoria unificado, y no está limitado a un tamaño fijo [35]. AVR se puede dividir en los siguientes grupos: ATxmega: procesadores muy potentes con de 16 a 384 kb de memoria flash programable, encapsulados de 44, 64 y 100 pines (A4, A3, A1), capacidad de DMA, eventos, criptografía y amplio conjunto de periféricos con DACs. ATmega: microcontroladores AVR grandes con de 4 a 256 kb de memoria flash programable, encapsulados de 28 a 100 pines, conjunto de instrucciones extendido (multiplicación y direccionamiento de programas mayores) y amplio conjunto de periféricos. ATtiny: pequeños microcontroladores AVR con de 0,5 a 8 kb de memoria flash programable, encapsulados de 6 a 20 pines y un limitado set de periféricos. AT90USB: ATmega integrado con controlador USB AT90CAN: ATmega con controlador de bus CAN Tipos especiales: algunos modelos especiales, por ejemplo, para el control de los cargadores de baterías, pantallas LCD y los controles de los motores o la iluminación. AT90S: tipos obsoletos, los AVRs clásicos 58

71 ANEXO I RELEVAMIENTO DE HARDWARE Arduino UNO esta basado en el microprocesador Atmega328 aunque existen otros desarrollos basados en Atmega168 y Atmega1280. Posee 14 PINs de entrada salida de los cuales 6 pueden ser usados como salidas PWM, 6 entradas analógicas y un cristal oscilador de 16MHz. La línea AVR puede soportar normalmente clocks de 0-20MHz alcanzando incluso los 32MHz en algunos dispositivos. Además existe un prescaler capaz de dividir el clock hasta 1024 veces. El mismo puede ser configurado por software en tiempo de ejecución 2.2. PIC - ICP05 IBOARD LITE La arquitectura del PIC es sumamente minimalista. Esta caracterizada por las siguientes prestaciones: Área de código y de datos separadas (Arquitectura Harvard), Un reducido número de instrucciones de longitud fija. La mayoría de las instrucciones se ejecutan en un solo ciclo de ejecución (4 ciclos de clock), con ciclos de único retraso en las bifurcaciones y saltos. Un solo acumulador (W), cuyo uso (como operador de origen) es implícito (no está especificado en la instrucción). Todas las posiciones de la RAM funcionan como registros de origen y/o de destino de operaciones matemáticas y otras funciones. Una pila de hardware para almacenar instrucciones de regreso de funciones. Una relativamente pequeña cantidad de espacio de datos direccionable (típicamente, 256 bytes), extensible a través de manipulación de bancos de memoria. El espacio de datos está relacionado con el CPU, puertos, y los registros de los periféricos. El contador de programa esta también relacionado dentro del espacio de datos, y es posible escribir en él (permitiendo saltos indirectos). A diferencia de la mayoría de otros CPU, no hay distinción entre los espacios de memoria y los espacios de registros, ya que la RAM cumple ambas funciones, y esta es normalmente referida como "archivo de registros" o simplemente, registros. 59

72 ANEXO I RELEVAMIENTO DE HARDWARE ICP05 permite implementar cualquier PIC de 28 PINs por lo cual las características inherentes al microcontrolador dependerá del modelo seleccionado. En este caso, basaremos el análisis en el PIC16F722 que se incluye en el empaque de la placa Características PIC16F722 Mid-Range core with 35 Instruction, 8 Stack Levels Flash Program Memory Internal 16MHz oscillator I²C, SPI, AUSART 2 X CCP (Caputure/Compare/PWM) 11 Channel 8b ADC 25mA Source/Sink current I/O One 8-bit Timer (TMR0) Two 16-bit Timer (TMR1/TMR2) Watchdog Timer (WDT) Enhanced Power-On/Off-Reset Brown-Out Reset (BOR) In Circuit Serial Programming (ICSP ) Built-in mtouch capacative sensing module Wide Operating Voltage (1.8V 5.5V) CPU speed (MIPS) ARM RASPBERRY PI Tanto el modelo A como B de Raspberry Pi, poseen un procesador ARM 1176JZF-S integrado en un SoC Broadcomm BCM2835. ARM es una arquitectura RISC (Reduced Instruction Set Computer) de 32 bits desarrollada por ARM Holdings y es en la actualidad, el conjunto de instrucciones de 32 bits más utilizado en unidades producidas [36]. La relativa simplicidad de los procesadores ARM los hace ideales para aplicaciones de baja potencia. Como resultado, se han convertido en dominante en el mercado de la electrónica móvil e integrada, encarnados en microprocesadores y microcontroladores pequeños, de bajo consumo y 60

73 ANEXO I RELEVAMIENTO DE HARDWARE relativamente bajo coste. En 2005, alrededor del 98% de los más de mil millones de teléfonos móviles vendidos cada año utilizan al menos un procesador ARM.3 Desde 2009, los procesadores ARM son aproximadamente el 90% de todos los procesadores RISC de 32 bits embebidos y se utilizan ampliamente en la electrónica de consumo, incluyendo PDAs, tabletas, teléfonos móviles, consolas de mano, calculadoras, reproductores digitales de música y medios (fotos, vídeos, etc.), y periféricos de ordenador como discos duros y routers [36]. Un aspecto importante a la hora de pensar en nuevos desarrollos es que la arquitectura ARM es licenciable. SoC: Broadcom BCM2835 (CPU + GPU + DSP + SDRAM) CPU: ARM1176JZF-S a 700 MHz GPU: Broadcom VideoCore IV,26 OpenGL ES 2.0, decodificador 1080p30 H.264 Memoria (SDRAM): 256 MiB (compartidos con la GPU) Tabla 1. Especificaciones técnicas generales de Raspberry Pi Modelo B 2.4. FREESCALE EDUKIT08 El sistema EDUKIT08 básico está compuesto por una placa base o plataforma de trabajo (Motherboard) y una placa de personalización para la familia HC908 (Placa PLUGIN_AP ) que contiene al MCU MC908AP32CFBE, uno de los miembros más completos de esta popular familia. [16 et al] Características MC908AP32CFBE CPU Speed: 8 MHz Clock Frequency: 8 MHz Core Size: 8 bit Flash Memory Size: 32 Kb IC Generic Number: 908AP32 Interface: I2C, SCI, SPI Logic Function Number: 32CFBE Memory Size:

74 ANEXO I RELEVAMIENTO DE HARDWARE Memory Type: FLASH Microprocessor/Controller Features: LVI, WDT Mounting Type: SMD Number of ADC Inputs: 8 Number of Bits: 8 Number of I/O Lines: 32 Number of PWM Channels: 8 Number of PINs: 44 Number of Timers: 2 Number of bits in ADC: 10 Operating Temperature Range: -40 C to +85 C Oscillator Type: External, Internal Package / Case: QFP Packaging Type: Peel Pack Peripherals: ADC, LED Drive Program Memory Size: 32 Kb Qualified Segment: COMMERCIAL, INDUSTRIAL RAM Size: 2 Kb SVHC: No SVHC (20-Jun-2011) Series: HC08 Supply Voltage Range: 4.5 V to 5.5 V Fig. 6. Edukit08 MCU MC908AP32CFBE 62

75 ANEXO I RELEVAMIENTO DE HARDWARE 2.5. PC/104 - PIC MICROSTACK USB MicroStack es una implementación del Standard PC104 para PIC. Permite la utilización de cualquier PIC de 40 PINs por lo cual las características técnicas del microcontrolador dependerán del modelo seleccionado Características PIC16F887 Oscilador interno de precisión calibrado de fabrica y con un rango de frecuencia seleccionable por software entre (Mhz y 32Khz. Monitoreo de Clock a prueba de fallos para aplicaciones criticas. Modo ahorro de energia Power-on Reset (POR) Voltage Brown-out Reset (BOR) seleccionable Watchdog Timer (WDT) Extendido con oscilador propio In-Circuit Serial Programming (ICSP ) via twopins In-Circuit Debug (ICD) via two PINs High-endurance Flash/EEPROM cell:- 100,000 erase/write cycle enhanced Flashprogram memory, typical- 1,000,000 erase/write cycle data EEPROMmemory, typical- Data EEPROM retention > 40 years Self-reprogrammable under software control Programmable code protection Peripheral Features: Device Features:- 1 input only pin- 36 I/O- High sink/source current 25 ma- Interrupt-on-pin change option Timers:- TMR0: 8-bit timer/counter with 8-bit prescaler- TMR1 enhanced: 16-bit timer/counter withprescaler, External Gate Input mode anddedicated low-power 32 khz oscillator- TMR2: 8-bit timer/counter with 8-bit periodregister, prescaler and postscaler Capture/Compare/PWM (CCP) module Enhanced Capture/Compare/PWM (ECCP)module with auto-shutdown and PWM steering Master Synchronous Serial Port (MSSP) modulespi mode, I2C mode with address maskcapability Enhanced Universal Synchronous AsynchronousReceiver Transmitter (EUSART) module:- Supports RS-485, RS-232 and LINcompatibility- Auto-Baud Detect- Auto-wake-up on Start bit 63

76 ANEXO I RELEVAMIENTO DE HARDWARE Ultra Low-Power Wake-up (ULPWU)Analog Features: 10-bit 14 channel Analog-to-Digital (A/D)Converter 2 Analog Comparator modules with:- Programmable on-chip Voltage Reference(CVREF) module (% of VDD)- Fixed 0.6 Vref- Comparator inputs and outputs externallyaccessible- SR Latch mode 2.6. PC/104 COOL LITERUNNER-ECO Los procesadores Atom están basados en la micro arquitectura Bonell. Como muchos otros microprocesadores x86, este traduce las instrucciones CISC en operaciones internas más simples, como por ejemplo instrucciones RISC, antes de su ejecución. Los Intel Atom pueden ejecutar hasta dos instrucciones por ciclo y el rendimiento de un Atom de núcleo único es igual a, aproximadamente, la mitad de un Intel Celeron M equivalente, de su misma frecuencia. Implementan el conjunto de instrucciones x86-64 y x86 (IA-32); excepto en los primeros modelos del Intel Atom (versiones N2xx y Z5xx); dichos modelos solo implementan el conjunto de instrucciones x86. Hasta la fecha, todos los Intel Atom actuales ya integran instrucciones x86-64 (las versiones N2xx y Z5xx de Intel Atom están oficialmente descatalogadas). La placa Cool LiterRunner-ECO implementa un microprocesador Intel Atom Z5xx, 1.1 GHz / 1.6 GH dependiendo la frecuencia del modelo elegido. A continuación una comparación entre los modelos disponibles: Processor Number Z510 Z530 # of Cores 1 1 # of Threads 1 2 Clock Speed 1.1 GHz 1.6 GHz L2 Cache 512 KB 512 KB Bus/Core Ratio FSB Speed 400 MHz 533 MHz FSB Parity No No Instruction Set 32-bit 32-bit Instruction Set Extensions SSE2, SSE3, SSSE3 SSE2. SSE3, SSSE3 Embedded Options Available Yes Yes Supplemental SKU No No Lithography 45 nm 45 nm Max TDP 2 W 2 W VID Voltage Range V V Tabla 2. Especificaciones técnicas de los procesadores Atom Z510 y Z530 64

77 ANEXO I RELEVAMIENTO DE HARDWARE 2.7. PC/104 - COOL LITERUNNER-LX800 Este modelo presenta un SoC AMD GEODE LX800. Geode es una serie de System on chip "todo en uno" compatibles con el conjunto de instrucciones x86, junto a los componentes de E/S producidos por AMD, dirigidos al mercado de sistemas embebidos [37]. x86 es la denominación genérica dada a ciertos microprocesadores de la familia Intel, sus compatibles y la arquitectura básica a la que estos procesadores pertenecen, por la terminación de sus nombres numéricos: 8086, 80286, 80386, 80486, etc. Han constituido desde su nacimiento un estándar para los ordenadores del tipo Compatible IBM PC [38] Características Geode LX800 Processor AMD Geode LX800@0.9W Speed 500 MHz Core Logic I/O companion: CS5536 Super I/O: ITE8712 RAM clock 400 MHz Graphics Integrated in the Geode LX800. Up to 254 MB video memory. Watchdog yes 2.8. PC/104 - COREMODULE 435 El CPU implementa la arquitectura x86 i586 de bajo consumo mencionada anteriormente con un CPU Vortex86SX de 300MHz o Vortex86DX de 800MHz ambos con 16Kb de cache. Además posee un motor gráfico integrado 2D de 64-bit y 100MHz. 3. DIMENSIONES, ALIMENTACIÓN Y CONDICIONES DE AMBIENTE SOPORTADAS 3.1. ARDUINO UNO La placa base del Arduino UNO tiene un tamaño máximo de 2.7' x 2.1' y presenta 4 perforaciones para su fijación a un contenedor. El Arduino puede ser alimentado vía USB o a través de una fuente externa o batería. 65

78 ANEXO I RELEVAMIENTO DE HARDWARE La placa puede operar con un voltaje de alimentación desde 6v a 20v pero el rango recomendado es de 7v a 12v. Fig. 7. Diagrama Arduino UNO Los PINs de alimentación son los siguientes: VIN: Permite alimentar la placa o utilizar la tensión de alimentación provista a través del conector. 5V: Salida de tensión regulada 5V.. 3V3: Salida de tensión regulada de 3.3V x 50 ma. GND: Tierra. A continuación un cuadro comparativo de los niveles de tensión manejados por los 3 modelos de Atmega soportados por Arduino en sus diversos modelos siendo 328 correspondiente a Arduino UNO. Atmega168 Atmega328 (Arduino UNO) Atmega1280 Voltaje operativo 5 V 5 V 5 V Voltaje de entrada recomendado 7-12 V 7-12 V 7-12 V Voltaje de entrada límite 6-20 V 6-20 V 6-20 V Tabla 3. Niveles de tensión manejados por los procesadores Atmega 66

79 ANEXO I RELEVAMIENTO DE HARDWARE El microcontrolador Atmega trabaja dentro de un rango de temperaturas de entre -40 C y 85 C permitiéndole al Arduino UNO desempeñarse en ambientes hostiles realizando tareas, por ejemplo, de medición de condiciones climáticas PIC - ICP05 IBOARD LITE La placa provee tensiones de 5V y 3.3V seleccionables para el microcontrolador PIC. Sus dimensiones son muy pequeñas, tan solo 10cm x 5.5cm tornándolo ideal para aplicaciones móviles o en espacios reducidos. El PIC PIC16F722 posee un rango de voltaje de operación de 1.8V 3.6V y admite un rango de temperaturas de -40 C C RASPBERRY PI Raspberry PI puede ser alimentada por una fuente externa de 5V o bien a través de un cable USB y su consumo varía según el modelo siendo la más reciente versión la de mayor demanda. Uno de las mayores virtudes de este desarrollo y un gran argumento publicitario además es justamente su tamaño. La placa posee las medidas de una tarjeta de crédito, esto es 85.60mm 53.98mm y pesa menos de 40g. Modelo A Modelo B Consumo energético: 500 ma, (2.5 W) 700 ma, (3.5 W) Fuente de alimentación: Dimensiones: 5 V vía Micro USB o GPIO header 85.60mm 53.98mm27 ( inch) Peso < 40g Tabla 4. Información de consumo y dimensiones de Raspberry Pi Modelo A y B 67

80 ANEXO I RELEVAMIENTO DE HARDWARE Fig. 8. Raspberry Pi Model B. Diagrama de conexiones FREESCALE EDUKIT 08 La alimentación del sistema EDUKIT08 se lleva a cabo por medio de fuentes externas de corriente continua o corriente alterna (DC o AC desde 7 a 16V) o a través del puerto USB 2.0 que dispone cualquier PC o Notebook y el rango de tensión que provee es de 4.5V a 5.5V. Las dimensiones de la placa son 210 mm de largo y 160 mm de ancho aproximadamente. Al ser un desarrollo destinado al aprendizaje, deja de lado la optimización del espacio e incorpora una gran variedad de interfaces de entrada y salida a lo largo de toda su superficie [16] PC/104 - PIC MICROSTACK La placa MicroStack puede ser alimentada a través de una fuente externa de 5V o bien a través de un cable USB y su conexión a cualquier PC y entrega un rango de tensiones de entre 5V y 3.3V. Sus medidas son 65mm x 80mm y su altura 16mm 68

81 ANEXO I RELEVAMIENTO DE HARDWARE 3.6. PC/104 - COOL LITERUNNER-ECO Estos desarrollos fueron diseñados íntegramente pensando en su aplicación comercial o industrial por lo cual soportan grandes rangos de temperatura y sus medidas son ajustadas teniendo en cuenta su potencial de procesamiento. Sus dimensiones responden al Standard PC/104, 96mm x 90mm (3.775 x ) y los rangos de temperaturas soportados los siguientes: 0 C +60 C (comercial) -20 C +60 C (industrial) -40 C +85 C (extendido) Su alimentación es a través de una fuente externa de 5V ±5 % y todas las tensiones necesarias son generadas en la placa. El consumo es aproximadamente 11W PC/104 - COOL LITERUNNER-LX800 Este es un desarrollo de similares características al anterior, sus medidas responden al Standard PC/104, 96mm x 90mm (3.775 x ) y los rangos de temperatura soportados son los siguientes: 0 C +60 C (comercial) -20 C +60 C (industrial) -40 C +85 C (extendido, opcional) La alimentación se realiza a través de una fuente externa de 5 V ±5 y todas las tensiones necesarias son generadas en la placa. Su consumo típico es menor al del desarrollo anterior rondando los 5W aunque en ocasiones puede alcanzar los 6W PC/104 - COREMODULE 435 Completando los desarrollos PC/104 encontramos condiciones similares en el CoreModule 435 el cual implementa un micro Vortex86DX. 69

82 ANEXO I RELEVAMIENTO DE HARDWARE Sus dimensiones, al igual que las 2 placas anteriores responden al Standard PC/104, es decir, 90x96mm (3.6x3.8 ) y una altura de 2.36mm Los rangos de temperatura soportados son: Standard: -20 C C Extendido: -40 C C Almacenamiento: -55 C C La alimentación se realiza a través de una fuente externa de 5V y posee un consumo de 6.5W 4. MEMORIA DE DATOS Y PROGRAMA La disposición de la memoria de datos y de programa esta fuertemente ligada a el tipo de arquitectura implementada siendo las mas representativas Harvard, caracterizada por poseer almacenamientos físicamente separados para los datos y las instrucciones y Von Neumann que utiliza el mismo dispositivo de almacenamiento tanto para datos como para instrucciones. Vale aclarar además las variantes técnicas de dispositivos de almacenamiento que encontraremos a lo largo del análisis. EEPROM: Memoria programable y borrable electrónicamente. SDRAM: Memoria de acceso dinámico y almacenamiento temporal por su condición de volátil. FLASH: La memoria flash es una tecnología de almacenamiento derivada de la memoria EEPROM que permite la lecto-escritura de múltiples posiciones de memoria en la misma operación. DDR: Memoria de acceso aleatorio y almacenamiento temporal por su condición de volátil. Es una evolución de la SDRAM. MicroSD: Formato de memoria de almacenamiento permanente flash. Habiendo sido mencionada la arquitectura de cada desarrollo durante el comienzo de este documento, haremos una descripción de las características de las memorias de datos y programa de los desarrollos seleccionados. 70

83 ANEXO I RELEVAMIENTO DE HARDWARE 4.1. ARDUINO UNO El micro controlador ATmega328 posee 32 KB de memoria de los cuales 0.5KB están destinados al bootloader o sector de arranque, 2 KB de SDRAM y 1 KB de EEPROM integrados en el mismo chip lo cual evita en la mayoría de los casos la necesidad de utilizar almacenamiento externo requerido por algunas aplicaciones [9]. Memoria de Programa Las instrucciones del programa son almacenadas en la memoria Flash. Aunque la MCU es de 8 bits, cada instrucción puede tomar una o 2 palabras de 16 bits. El tamaño de la memoria de programa usualmente forma parte de la nomenclatura del dispositivo, Por ej. la linea Atmega64x posee 64kb de memoria Flash [9]. Memoria de Datos El espacio de direccionamiento de datos consiste en registros de archivo, registros de I/O y SRAM. Registros Internos Los microcontroladores de la familia AVR poseen 32 registros de trabajo de 8 bits cada uno. En muchas ocasiones son mapeados en las primeras 32 posiciones de memoria y seguidos de los 64 registros correspondientes a I/O [9]. EEPROM Casi todos los micro controladores AVR poseen una memoria EEPROM destinada al almacenamiento semi-permanente. Al igual que la Flash, la memora EEPROM es no volatil. En muchos casos, la memoria interna EEPROM no se encuentra mapeada dentro del espacio de direccionamiento de la MCU y por ello puede ser solamente accedida de la misma manera que una memoria externa. La memoria SDRAM es utilizada para el almacenamiento temporal de datos [9]. Atmega168 Atmega328 (Arduino UNO) Atmega1280 Memoria Flash 32KB (2KB 16KB (2KB reservados 128KB (4KB reservados reservados para el para el bootloader) para el bootloader) bootloader) SRAM 1 KB 2 KB 8 KB EEPROM 512 bytes 1 KB 4 KB Tabla 5. Tamaño de memorias en los procesadores Atmega 71

84 ANEXO I RELEVAMIENTO DE HARDWARE 4.2. PIC A diferencia de la mayoría de CPUs, no hay distinción entre los espacios de memoria y los espacios de registros, ya que la RAM cumple ambas funciones, y esta es normalmente referida como "archivo de registros" o simplemente, registros. Memoria de datos Los microcontroladores PIC poseen registros que funcionan como una RAM de propósito general. Los registros de propósito específico para los recursos de hardware disponibles dentro del propio chip también están direccionados en la RAM. La direccionalidad de la memoria varía dependiendo la línea de dispositivos, y todos los dispositivos PIC tienen algún tipo de mecanismo de manipulación de bancos de memoria que pueden ser usados para acceder memoria externa o adicional. Las series más recientes de dispositivos disponen de funciones que pueden cubrir todo el espacio direccionable, independientemente del banco de memoria seleccionado. En los dispositivos anteriores, esto debía lograrse mediante el uso del acumulador. Para implementar direccionamiento indirecto, se usa un registro de "selección de registro de archivo" (FSR) y uno de "registro indirecto" (INDF): Un número de registro es escrito en el FSR, haciendo que las lecturas o escrituras al INDF serán realmente hacia o desde el registro apuntado por el FSR. Los dispositivos más recientes extienden este concepto con post y pre incrementos/decrementos para mayor eficiencia al acceder secuencialmente a la información almacenada. Esto permite que se pueda tratar al FSR como un puntero de pila. La memoria de datos externa no es directamente direccionable excepto en algunos microcontroladores PIC 18 de gran cantidad de pines [32]. Tamaño de palabra El tamaño de palabra de los microcontroladores PIC es fuente de muchas confusiones. Todos los PICs (excepto los dspic) manejan datos en trozos de 8 bits, con lo que se deberían llamar microcontroladores de 8 bits. Pero a diferencia de la mayoría de las CPU, el PIC usa arquitectura Harvard, por lo que el tamaño de las instrucciones puede ser distinto del de la palabra de datos. De hecho, las diferentes familias de PICs usan tamaños de instrucción distintos, lo que hace difícil comparar el tamaño del código del PIC con el de otros microcontroladores. Por ejemplo, un microcontrolador tiene 6144 bytes de memoria de programa: para un PIC de 12 bits esto significa 4096 palabras y para uno de 16 bits, 3072 palabras [32]. El PIC16F1933 posee una memoria de programa tipo flash de 3.5KB y una RAM de 128 bytes 72

85 ANEXO I RELEVAMIENTO DE HARDWARE 4.3. RASPBERRY PI Raspberry PI posee 256 MB de memoria RAM con el objetivo de ejecutar Linux. No incluye un disco duro o una unidad de estado sólido sino que utiliza una tarjeta SD para el sistema operativo y el almacenamiento permanente de datos. Se recomienda utilizar memorias SD de alta velocidad para el almacenamiento del sistema operativo FREESCALE EDUKIT 08 El CPU08 pertenece a la arquitectura del tipo Von Neuman clásica, característica de la familia 68xx de Freescale y ampliamente utilizada en todo el mundo. En este tipo de arquitectura, existe un solo Bus de datos, tanto para memoria de programas como para memoria de datos, lo que da origen a un mapa lineal de acceso a memoria y por consiguiente no existen instrucciones especiales y diferentes para trabajar con datos o con código de programa. De esta forma, todas las instrucciones son aplicables en cualquier parte del mapa de memoria sin importar si se trabaja con datos o código. Por lo que no es raro encontrar aplicaciones cuyos programas corran desde RAM como si estuvieran en FLASH. Esto no podría hacerlo una arquitectura Hardvard clásica MCU MC908AP32CFBE. Las características relacionadas con la memoria en el EDUKIT08 son las siguientes [34] Memoria de programa Flash de 32 Kb Memoria RAM de 2KB Dispositivo de memoria externa EEPROM (24LC256) para prácticas de comunicaciones I2C 256kbits Los sistemas PC/104 usualmente requieren de dispositivos de almacenamiento semi permanente no volátiles. Las mas populares actualmente son las memorias Flash y los discos de estado solido (SSD) debido a su bajo consumo y a que los discos convencionales de desplazamiento mecánico son mas permeables a fallas en entornos hostiles. 73

86 ANEXO I RELEVAMIENTO DE HARDWARE 4.5. PC/104 - PIC MICROSTACK La arquitectura responde a la de PIC. La cantidad de memoria de datos y programa varía según el PIC elegido. El PIC16F887 posee una memoria de programa Flash de 14Kb, una memoria RAM de 368Bytes y una memoria de datos EEPROM de 256Kb PC/104 - COOL LITERUNNER-ECO Al igual que Raspberry Pi, Cool LiteRunner-ECO ejecuta el sistema operativo desde una memoria µsd booteable. Además posee una memoria RAM de 2GB DDR2 (tamaño variable según preferencia) soldada a la placa y su micro posee una cache de nivel 1 de 32KB para instrucciones y una de nivel 2 de 512 Kb. El Procesador posee un nivel de cache primario de 32KB para instrucciones y 24KB para datos y un nivel secundario de 512KB 8-way set associative PC/104 - COOL LITERUNNER-AMD LX800 El microcontrolador de la placa AMD LX800 posee una memoria de programa de 64k, una cache de nivel 1 de 64K y una de nivel 2 de de 128K. Posee una memoria RAM DDR400 de 256Mb 400MHz soldada a la placa y además dispone de un puerto SODIMM de 200-pin para capaz de soportar hasta 1GB DDR 333/ PC/104 - COREMODULE 435 La placa implementa los procesadores Vortex86SX 300MHz y Vortex86DX 800MHz. Los mismos poseen una Cache 16kB I-cache, 16kB D-cache. La placa posee una memoria RAM DDR2 de 256MB soldada y un puerto para conectar almacenamiento CompactFlash y 2 interfaces PATA DMA 100 IDE capaces de soportar hasta 2 discos rígidos. 74

87 ANEXO I RELEVAMIENTO DE HARDWARE 5. INTERFACES Y PUERTOS DE ENTRADA/SALIDA DISPONIBLES 5.1. ARDUINO UNO Cualquiera de los 14 PINs digitales en el Arduino UNO puede ser programado para ser utilizados como entrada o Salida mediante funciones simples. Operan con una tensión de 5V y pueden proveer o recibir una corriente de 40 ma. Además existe la posibilidad de utilizar una resistencia de pull-up de 20-50KOhms [2]. Si bien todos los PINs pueden ser utilizados como entradas o salidas, existen algunos PINs que poseen funciones especiales como transmisión y recepción de datos seriales TTL, manejo de interrupciones externas, salidas analógicas PWM, manejo de LEDs, etc. De manera similar a Freescale Edukit08, los registros de puertos permiten la manipulación a mas bajo nivel y de forma mas rápida de los pines de E/S del micro controlador de las placas Arduino. Los pines de las placas Arduino están repartidos entre los registros B(0-7), C (analógicos) y D(8-13). Mediante las siguientes variables podemos ver y modificar su estado: DDR[B/C/D]: Data Direction Register (o dirección del registro de datos) del puerto B, C ó D. Sirve para especificar que pines queremos usar como de entrada y cuales de salida. Variable de Lectura/Escritura. PORT[B/C/D]: Data Register (o registro de datos) del puerto B, C ó D. Variable de Lectura/Escritura. PIN[B/C/D]: Input PINs Register (o registro de pines de entrada) del puerto B, C ó D. Variable de sólo lectura. Por ejemplo, para especificar que queremos utilizar los pines 1 a 7 como salidas y el 0 como entrada, bastaría utilizar la siguiente asignación DDRD = B ; 75

88 ANEXO I RELEVAMIENTO DE HARDWARE Fig. 9. Diagrama de componentes de Arduino UNO El Arduino UNO es capaz de establecer comunicación con una computadora, otro Arduino o incluso oto Micro controlador El ATmega328 implementa la tecnología de comunicación serial UART TTL (5V) mediante la utilización de los PINs 0 (RX) y 1 (TX). EL Firmware ATmega16U2 canaliza esta comunicación serial a través del puerto USB y facilita la conexión con el software de programación por computadora utilizando los drivers COM standard, es decir sin la necesidad de utilizar drivers externos [9] PIC ICP05 IBOARD LITE iboard Lite fue construido incorporando un amplio set de puertos que cubren diversos entornos de aplicación como control de Motores, Sensores, Log de datos, etc. A través de todos estos puertos, el usuario puede fácilmente conectar diferentes tipos de módulos externos de entrada salida con diversas fuentes de alimentación. Además incluye un puerto para la conexión de una pantalla LCD con la posibilidad de controlar el backlight y conexión directa con los PINs del PIC. 76

89 ANEXO I RELEVAMIENTO DE HARDWARE Fig. 10. Conexion de modulos en iboard Lite A continuación se detallan los puertos de entrada y salida disponibles en la placa. Diferentes entradas de alimentación VS1 y VS2 provenientes del PIC y de una fuente externa. Conector ICSP para la programación on-board del PIC Puerto para la conexión del display LCD Socket 28-Pin IC Puerto IO de 8 canales Puerto analógico de 8 canales Puerto para el manejo de servo motores de 4 canales. Puerto USART de 1 canal Puertos de comunicación (SPI/I2C/USART/PS2/USB) Puerto para el manejo de motores paso a paso (ULN2003A - 500mA Darlington driver) - 1 canal Puerto para manejo de motores de DC (L293D con control de sentido y velocidad) - 1 canal (ULN2003A & L293D no son provistos con la placa) Convertidor Boost/Buck - 1 canal Botones de encendido - SW1 (VS1) y SW2 (VS2) 5.3. RASPBERRY PI A la hora de describir la composición de hardware de un Raspberry PI no podemos evitar realizar una breve introducción al concepto de SoC (System on Chip). 77

90 ANEXO I RELEVAMIENTO DE HARDWARE System-on-a-chip o SoC (también referido como system-on-chip), describe la tendencia cada vez más frecuente de usar tecnologías de fabricación que integran todos o gran parte de los módulos componentes de un ordenador o cualquier otro sistema informático o electrónico en un único circuito integrado o chip. El diseño de estos sistemas puede estar basado en circuitos de señal digital, señal analógica, o incluso de señal mixta y a menudo módulos o sistemas de radiofrecuencia (módulos de comunicación inalámbrica: Wi-Fi, Bluetooth, etc.) [38]. Modelo A Modelo B Puertos USB 2.0: 1 2 (vía hub USB integrado) Salidas de vídeo: Conector RCA, HDMI Conector RCA, HDMI Salidas de audio: 3.5 mm jack, HDMI 3.5 mm jack, HDMI Conectividad de red: Ninguna RJ45 Periféricos de bajo Pines GPIO, SPI, I²C, nivel: UART26 Pines GPIO, SPI, I²C, UART26 Tabla 6. Puertos de entrada y salida disponibles en los modelos A y B de Raspberry Pi A diferencia del modelo A, el modelo B incorpora un segundo puerto USB2.0 y un puerto de red 10/100 Base T. Si bien aún no se ha integrado un modulo WiFi, existe la posibilidad de utilizar un adaptador WiFi USB. A continuación una lista detallada de los puertos de entrada y salida presentes en Raspberry Pi Modelo B: Características Raspberry Pi Modelo B LAN9512 (Solo Modelo B) : 10/100Mb Ethernet (Auto-MDIX)[4] Conector Micro USB (5v Solo para alimentación) Interface DSI de 15-PINs que provee 2 canales de datos, 1 canal de clock, 1 de 3.3v y 1 de GND. A futuro dará soporte a la conexión de múltiples pantallas. Salida de Video HDMI Salida de video Composite RCA Interface MIPI CSI-2 de 15 PINs. A futuro dará soporte a módulos de expansión de cámara. La GPU soporta la captura de imágenes de hasta 40MPixels y captura de video 1080p 30fps Salida de Audio Stereo de 3.5mm Slot de memoria SD/MMC/SDIO 78

91 ANEXO I RELEVAMIENTO DE HARDWARE 1x USB 2.0 (Modelo A) 2x USB 2.0 (Modelo B) Cabezal de expansión 26-pin 2.54 mm: see 8 GPIOs 3v3 (entradas/salidas de propósito general) 2-pin UART consola serial, 3v3 TTL (depuración); o 2 GPIOs 3v3 Interfaz I²C (3v3); or 2 GPIOs at 3v3 Interfaz SPI (3v3); or 5 GPIOs at 3v3 3v3, 5v y GND ARM JTAG Segunda Interfaz I²C interface (3v3) (PINs configurados por software) Interfaz I²S (PINs configurados por software) 6 PINs reservados para uso futuro Cabezal de expansión de 8-pin 2.54 mm destinado a GPU JTAG* Cabezal de expansión 7-pin 2.54 mm destinado a LAN9512 JTAG* Puerto Ethernet 10/100Mb RJ45 (Modelo B) TP1 and TP2 que proveen +5V y GND respectivamente 5 Leds de estado: D5(Green) - OK Actividad SDCard D6(Red) - PWR V Alimentación D7(Green) - FDX - Full Duplex (LAN) (Modelo B) D8(Green) - LNK - Link/Activity (LAN) (Modelo B) D9(Yellow) - 10M - 10/100Mbit (LAN) (Modelo B) 79

92 ANEXO I RELEVAMIENTO DE HARDWARE Fig. 11. Diagrama de modulos Raspberry Pi Model B (*) JTAG, un acrónimo para Joint Test Action Group, es el nombre común utilizado para la norma IEEE titulada Standard Test Access Port and Boundary-Scan Architecture para test access ports utilizada para testear PCBs (Printed Circuit Boards) utilizando escaneo de límites. Diseñado originalmente para circuitos impresos, actualmente es utilizado para la prueba de submódulos de circuitos integrados, y es muy útil también como mecanismo para depuración de aplicaciones empotradas, puesto que provee una puerta trasera hacia dentro del sistema. Cuando se utiliza como herramienta de depuración, un emulador en circuito que usa JTAG como mecanismo de transporte permite al programador acceder al módulo de depuración que se encuentra integrado dentro de la CPU. El módulo de depuración permite al programador corregir sus errores de código y lógica de sus sistemas [40]. Periféricos de Bajo Nivel Además de los ya conocidos puertos USB, Ethernet y HDMI, Raspberry Pi ofrece una serie de interfaces de bajo nivel diseñadas para conectar al mismo de manera más directa con otros chips o módulos. Esta GPIO (I/O de propósito general) es capaz de controlar LEDs, servo motores y otros componentes electrónicos. I/O de Propósito General (GPIO) Las GPIO se presentan en forma de PINs genéricos cuyo comportamiento, incluyendo su condición de entrada o salida, puede ser programada a través del software. La Raspberry Pi permite a los periféricos y los módulos de expansión acceder a la CPU a través de estos PINs. Los mismos se presentan el la placa en un cabezal de expansión de 26 pines distribuidos 80