Control de Robots Autónomos Móviles Basados en Arquitecturas de ...

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 GRADODE

LICENCIADO EN SISTEMAS

DEPARTAMENTO

DE DESARROLLO PRODUCTIVO Y TECNOLOGICO

UNIVERSIDAD NACIONAL DE LANUS

2013

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.

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.

INDICE CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.

ÍNDICE

1. INTRODUCCIÓN 1 1.1. Contexto del Trabajo Final 1

1.2. Objetivo del Trabajo Final 2

1.2.1. Objetivo general 2

1.2.2. Objetivos particulares 3

1.3. Visión General del Trabajo Final 3

2. ESTADO DE LA CUESTIÓN 5 2.1. Modelos de procesos para sistemas informáticos 5

2.1.1. Modelo de requisitos para sistemas embebidos 6

2.1.2. Goal-oriented patterns for UML-Based modeling of embedded systems requirements 7

2.1.3. IEEE Standard for Developing Software Life Cycle Processes 1074-2006 8

2.2. Esquema Comparativo 9

3. DESCRIPCIÓN DEL PROBLEMA 11 3.1. Identificación del problema de investigación 11

3.2. Problema abierto 12

3.3. Sumario de investigación 12

4. SOLUCIÓN 13 4.1. Modelo de gestión integral de proyectos destinados al control de Robots

Autónomos Móviles basados en Arquitecturas de Sistemas Embebidos. 13

4.1.1. Generalidades 13

4.1.2. Influencias 13

4.1.3. Estructura general del modelo 15

4.1.4. Procesos, sub-procesos, actividades, documentos de salida y técnicas sugeridas 15

4.1.5. Descripción y objetivos de los procesos, sub-procesos y actividades propuestas 26

4.1.6. Procedimiento de implementación de la solución 38

4.1.6.1. Selección de un modelo de ciclo de vida 38

4.1.6.2. Creación del ciclo de vida del proyecto, Mapa de actividades 38

4.1.6.3. Secuenciamiento de actividades 39

4.1.6.4. Asignación de documentos de salida 39

4.1.6.5. Iniciación del proyecto 39

5. PRUEBA DE CONCEPTO 41 5.1. Descripción de la prueba de concepto: inspección de cultivos en invernadero 41

5.1.1. Descripción del negocio 41

5.1.2. Descripción del producto a desarrollar 42

TRABAJO FINAL DE LICENCIATURA EN SISTEMAS JONATAN PONZOi


5.2. Implementación de la prueba de concepto 42

6. CONCLUSIONES 43 6.1. Aportaciones del Trabajo Final 43

6.2. Futuras Líneas de Investigación 44

7. REFERENCIAS 47

ANEXO I – RELEVAMIENTO DE HARDWARE 49 1. Introducción a las familias seleccionadas 52

2. Microprocesador. Arquitectura, frecuencias disponibles y características principales 57

3. Dimensiones, alimentación y condiciones de ambiente soportadas 65

4. Memoria de datos y programa 70

5. Interfaces y puertos de entrada / salida disponibles 75

6. Módulos de expansión 86

7. Programación 92

8. Disponibilidad en el mercado local e internacional y costos 102

9. Principales mercados de aplicación, ventajas y desventajas 106

10. Matriz comparativa 111

11. Referencias 113

ANEXO II – MATRIZ COMPARATIVA 117

ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS 127

1. Modelo de requisitos para sistemas embebidos 130

1.1 Introducción 130

1.2 Descripción del modelo 131

1.2.1 Categorías y subcategorías 132

1.2.1.1. Disponibilidad de objetos 132

1.2.1.2. Convocación y demostración 132

1.2.1.3. Selección de alternativas 132

1.2.1.4. Solicitud de acceso 133

1.2.1.5. Aporte (entrada respuesta) 133

1.2.1.6. Verificación / Decisión 133

1.2.1.7. Intervención de agentes 133

1.2.1.8. Acción del agente 134

1.2.1.9. Transferencia / Actualización 135

1.2.1.10 Interrupción / Restitución / Conservación 135

1.2.1.11. Despeño / Cambio 136

1.2.1.12. Precio y Costos 136

1.2.1.13. Descripción y caracterización de los agentes 136

TRABAJO FINAL DE LICENCIATURA EN SISTEMAS JONATAN PONZOii


2. Goal-Oriented Patterns for UML-Based Modeling of Embedded Systems Requirements 138

2.1. Introducción 138

2.2. Notación del modelo basado en metas 139

2.3. Análisis del comportamiento 141

2.4. Patrones COBRA 141

2.5. Plantillas COBRA 142

2.6. Análisis de consistencia en la construcción 147

2.6.1. Consistencia estructural por construcción 147

2.6.2. Consistencia en el comportamiento mediante análisis 149

3. Standard IEEE 1074-2006 para el Desarrollo de procesos de ciclo de vida de Software 149

3.1. Introducción 149

3.2. Descripción general del modelo 150

3.3. 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

TRABAJO FINAL DE LICENCIATURA EN SISTEMAS JONATAN PONZOiii


TRABAJO FINAL DE LICENCIATURA EN SISTEMAS JONATAN PONZOiv


Í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 Arquitecturas de Sistemas Embebidos

COBRA Constraints and OBjects for Requirements Analysis

IR Ingeniería de Requerimientos

PyMEs Pequeñas y Medianas Empresas

RAM Robot Autónomo Móvil

SC Sistema de Control

SE Sistemas Embebidos

SE-RAM Sistemas Embebidos utilizables en Robótica Autónoma Móvil

SI Sistemas Informáticos

TFL Trabajo Final de Licenciatura

UML Unified Modeling Languaje

TRABAJO FINAL DE LICENCIATURA EN SISTEMAS JONATAN PONZOv


TRABAJO FINAL DE LICENCIATURA EN SISTEMAS JONATAN PONZOvi

INTRODUCCION CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.

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).

1.1. 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.

TRABAJO FINAL DE LICENCIATURA EN SISTEMAS JONATAN PONZO1


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.

1.2. 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.

1.2.1. 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



soluciones que aseguren la satisfacción de las necesidades del cliente alcanzando niveles de

eficiencia y calidad apropiados para la disciplina.

1.2.1. 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 embebidos-

y 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.

1.3. 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



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.


ESTADO DE LA CUESTIÓN CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.

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 2.1.1 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.

2.1. 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



Cycle Processes 1074-2006” del Software Engineering Standards Committee of the IEEE Computer

Societ, en su ultima versión correspondiente al año 2006.

2.1.1. “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].



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.

2.1.2. “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



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 .

2.1.3. “IEEE STANDARD FOR DEVELOPING SOFTWARE LIFE CYCLE PROCESSES 1074-2006” 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].



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.

2.2. 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

• 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.

• 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.

Goal-Oriented Patterns for UML-Based Modeling of Embedded Systems Requirements

• 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

• 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.

Tabla 2.2. a) Esquema comparativo de modelos



IEE 1074-2006 • 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 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.

• 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.

Tabla 2.2. b) Esquema comparativo de modelos


DESCRIPCION DEL PROBLEM A CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.

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).

3.1. 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.


DESCRIPCION DEL PROBLEM A CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.

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.

3.3. 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?


SOLUCION CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.

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.

4.1. 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.

4.1.1. GENERALIDADES

El modelo propuesto surge de la adaptación de los subprocesos y actividades existentes en el

standard IEEE 1074-2006 [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].

4.1.2. 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

1074-2006”. Además de estos modelos y a modo de complementar la propuesta del standard IEEE

1074-2006, se referencia una 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 ” 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 1074-2006

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.



4.1.3. ESTRUCTURA GENERAL DEL MODELO PROPUESTO

El modelo toma como columna vertebral la estructura propuesta por el standard IEEE 1074-2006

[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.

4.1.3.1. Procesos de Gestión del Proyecto

4.1.3.1.1 Sub-proceso de Iniciación del proyecto

4.1.3.1.2 Sub-proceso de Planificación del proyecto

4.1.3.1.3 Sub-proceso de Monitoreo y Control

4.1.3.2. Proceso de Pre-Desarrollo

4.1.3.2.1 Sub-proceso de Exploración de Conceptos

4.1.3.2.2 Sub-proceso de Asignación del Sistema

4.1.3.3. Proceso de Desarrollo

4.1.3.3.1 Sub-proceso de Requisitos

4.1.3.3.2 Sub-proceso de Diseño

4.1.3.3.3 Sub-proceso de Implementación

4.1.3.4. Proceso de Post-Desarrollo

4.1.3.4.1 Sub-proceso de Instalación y Validación

4.1.3.4.2 Sub-proceso de Operación y Soporte

4.1.3.4.3 Sub-proceso de Mantenimiento

4.1.3.4.4 Sub-proceso de Retiro

4.1.3.5. Procesos Integrales del Proyecto

4.1.3.5.1 Subproceso de Evaluación

4.1.3.5.2 Sub-proceso de Gestión de la configuración

4.1.3.5.3 Sub-proceso de Desarrollo de Documentación

4.1.3.5.4 Sub-proceso de Formación

4.1.4. 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



para cada subproceso, los documentos de salida que se esperan obtener a partir de las mismas y las

técnicas sugeridas para lograrlo.

4.1.4.1. Proceso de Gestión del Proyecto

4.1.4.1.1 Sub-proceso de Iniciación del proyecto

Actividades:

4.1.4.1.1.1. Entendimiento del Negocio

4.1.4.1.1.2. Seleccionar un modelo de Ciclo de Vida

4.1.3.1.1.3. Realizar Estimaciones

4.1.3.1.1.4. Asignar Recursos

4.1.3.1.1.5. Definir Métricas

4.1.3.1.1.6. 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)

4.1.4.1.2. Sub-proceso de Planificación del proyecto

Actividades:

4.1.4.1.2.1. Planificación de la Evaluación

4.1.4.1.2.2. Planificación de la Gestión de la Configuración

4.1.4.1.2.3. Planificación de la Transición (si se requiere)

4.1.4.1.2.4. Planificación de la Instalación

4.1.4.1.2.5. Planificación de la Documentación



4.1.4.1.2.6. Planificación del Entrenamiento

4.1.4.1.2.7. Planificación de la Gestión del Proyecto.

4.1.4.1.2.8. Planificación de la Integración

4.1.4.1.2.9. Planificación de la Gestión del Lanzamiento

4.1.4.1.2.10. Planificación del Mantenimiento

4.1.4.1.2.11. Planificación del Retiro


▪ 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

4.1.4.1.3. Sub-proceso de Seguimiento y Control del Proyecto

Actividades:

4.1.4.1.3.1. Gestión de Riesgos

4.1.4.1.3.2. Gestión del Proyecto

4.1.4.1.3.3. Identificación de Mejoras al Ciclo de Vida

4.1.4.1.3.4. Almacenamiento de Registros

4.1.4.1.3.5. Recopilación y Análisis de Métricas

4.1.4.1.3.6. Cierre del Proyecto


▪ Reporte de Riesgos

▪ Reporte de Gestión del Proyecto

▪ Reporte de Necesidades de mejora en el Ciclo de Vida

▪ Registro Histórico de Proyectos



▪ Reporte de Métricas

▪ Información necesaria para el archivo del Proyecto al

momento de su cierre


▪ 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 )

4.1.4.2 . Proceso de Pre-Desarrollo

4.1.4.2.1 Sub-proceso de Exploración de Conceptos

Actividades:

4.1.4.2.1.1. Identificar ideas o necesidades.

4.1.4.2.1.2. Formular soluciones potenciales.

4.1.4.2.1.3. Conducir estudios de viabilidad.

4.1.4.2.1.4. Refinar y finalizar la idea o necesidad.


▪ Informe preliminar de necesidades

▪ Informe de Soluciones potenciales. Análisis de beneficios y

limitaciones

▪ Informe de Viabilidad

▪ Informe de Necesidades




▪ 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)

4.1.4.2.2. Sub-proceso de Asignación del Sistema

Actividades:

4.1.4.2.2.1. Analizar las funciones del sistema.

4.1.4.2.2.2. Desarrollar la arquitectura del sistema.

4.1.4.2.2.3. Asignar los requisitos del Sistema


▪ 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

4.1.4.3. Proceso de Desarrollo

4.1.4.3.1. Sub-proceso de Requisitos

Actividades:

4.1.4.3.1.1. Definir y desarrollar los requisitos del software

4.1.4.3.1.2. Definir y desarrollar los requisitos del hardware

4.1.4.3.1.3. Definir los requisitos del entorno

4.1.4.3.1.4. Definir los requisitos de interfaz



4.1.4.3.1.5. Integrar los requisitos


▪ 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 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



4.1.4.3.2. Sub-proceso de Diseño

Actividades:

4.1.4.3.2.1. Realizar el diseño arquitectónico

4.1.4.3.2.2. Realizar el diseño de la base de datos (si aplica)

4.1.4.3.2.3. Selección de la Arquitectura de Hardware mas conveniente

4.1.4.3.2.4. Diseñar las interfaces

4.1.4.3.2.5. Realizar el diseño detallado


▪ Diseño arquitectónico

▪ Diseño de la base de datos

▪ Diseño de las interfaces

▪ Diseño detallado



◦ 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


◦ HIPO (Hierarchy Input Process Output)


▪ Técnicas Orientadas a los datos

◦ DFD

◦ Modelos lógicos y físicos de datos

◦ Diagramas jerárquicos Warnier

◦ Diagramas estructurados Jackson




◦ Diagramas Entidad-Relacion

▪ Técnicas orientadas a los objetos

◦ UML

▪ Técnicas de diseño de bajo nivel

◦ Programación estructurada

◦ Diagramas arborescentes


◦ 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)

4.1.4.3.3. Sub-proceso de Implementación

Actividades:

4.1.3.3.1. Configurar e integrar el hardware y las interfaces físicas

4.1.3.3.2. Crear el código fuente

4.1.3.3.3. Crear la Documentación operacional

4.1.3.3.4. Realizar la integración

4.1.3.3.5. Gestionar las versiones del Software


• Código fuente

• Especificación de Software

• Especificación de Hardware

• Base de datos (si aplica)

• Documentación operacional

• Paquete del producto lanzado


• Lenguajes de programación

• Herramientas de versionado de software

• Entornos de modelado de Bases de Datos

• Entorno de Programación del hardware seleccionado



4.1.4.4. Proceso de Post-Desarrollo

4.1.4.4.1. Sub-proceso de instalación y Validación

Actividades:

4.1.4.4.1.1. Ajustar parámetros del entorno

4.1.4.4.1.2. Configurar y adaptar interfaces con el entorno productivo y

otros sistemas

4.1.4.4.1.3. Aceptar el producto en el ambiente operativo


▪ 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

4.1.4.4.2. Sub-proceso de operación y soporte

Actividades:

4.1.4.4.2.1. Operar el sistema

4.1.4.4.2.2. Proveer de asistencia técnica y consultas

4.1.4.4.2.3. Mantener el histórico de peticiones de soporte


▪ Registro de Operaciones

▪ Registro de Anomalías

▪ Registro de Peticiones de Soporte

4.1.4.4.3. Sub-proceso de mantenimiento

Actividades:

4.1.4.4.3.1. Identificación de necesidades de mejora del Software

4.1.4.4.3.2. Identificación de necesidades de mejora del Hardware y

Entorno Configurable

4.1.4.4.3.3. Implementación de un método de reporte de problemas

4.1.4.4.3.4. Iteración del Ciclo de Vida


▪ Sugerencia de mejoras al software

▪ Sugerencia de mejoras del hardware

▪ Reporte de anomalías

▪ Reporte de corrección de anomalías

▪ Recomendaciones de Mantenimiento



4.1.4.4.4. Sub-proceso de retiro

Actividades:

4.1.4.4.4.1. Notificar al usuario

4.1.4.4.4.2. Conducir operaciones en paralelo (si aplica)

4.1.4.4.4.3. Retirar el sistema


▪ Notificación oficial al usuario

▪ Registro de operaciones en paralelo

▪ Reporte de revisión Post-Operacion

4.1.4.5. Procesos Integrales del Proyecto

4.1.4.5.1. Subproceso de Evaluación

Actividades:

4.1.4.5.1.1. Revisión de Conducta

4.1.4.5.1.2. Crear Matriz de Trazabilidad

4.1.4.5.1.3. Conducir Auditorías

4.1.4.5.1.4. Desarrollar Procedimientos de prueba

4.1.4.5.1.5. Crear datos de prueba

4.1.4.5.1.6. Ejecutar pruebas

4.1.4.5.1.7. Reportar Resultados de la evaluación

4.1.4.5.1.8. Confirmar Acreditación de Seguridad


▪ 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




▪ 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

4.1.4.5.2 Sub-proceso de gestión de la configuración

Actividades:

4.1.4.5.2.1. Realizar la identificación de la configuración

4.1.4.5.2.2. Realizar el control de la configuración

4.1.4.5.2.3. Realizar la información del estado de la configuración


▪ Reporte de Identificación de la Configuración

4.1.4.5.3. Sub-proceso de desarrollo de Documentación

Actividades:

4.1.4.5.3.1. Implementar la Documentación

4.1.4.5.3.2. Producir y Distribuir la Documentación


▪ Documentación entregable

▪ Documentación interna del proyecto

4.1.4.5.4. Sub-proceso de Formación

Actividades:

4.1.4.5.4.1. Desarrollar los materiales de formación

4.1.4.5.4.2. Validar el programa de formación

4.1.4.5.4.3. Implementar el programa de formación




▪ Manual de procedimientos y materiales de entrenamiento

4.1.5. 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.

4.1.5.1. 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 4.1.6.

4.1.5.1.1. Sub-proceso de Iniciación del proyecto

4.1.5.1.1.1. 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.

4.1.5.1.1.2. 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 4.1.6.

4.1.5.1.1.3. 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.



4.1.5.1.1.4. Asignar Recursos

En esta actividad se estiman los recursos materiales y humanos necesarios para la realización del

proyecto y sus costos.

4.1.5.1.1.5. 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.

4.1.5.1.1.6. Determinar objetivos de Seguridad:

Mediante esta actividad se identifican objetivos de seguridad en el proyecto.

4.1.5.1.2. Sub-proceso de Planificación del proyecto

4.1.5.1.2.1. 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.

4.1.5.1.2.2. 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.

4.1.5.1.2.3. 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.

4.1.5.1.2.4. 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.

4.1.5.1.2.5. 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.



4.1.5.1.2.6. 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.

4.1.5.1.2.7. 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.

4.1.5.1.2.8. 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.

4.1.5.1.2.9. 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.

4.1.5.1.3. Sub-proceso de Seguimiento y Control del Proyecto

4.1.5.1.3.1. 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.

4.1.5.1.3.2. 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.



4.1.5.1.3.3. 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.

4.1.5.1.3.4. 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.

4.1.5.1.3.5. 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.

4.1.5.1.3.6. Cierre del Proyecto

Se concluye el proyecto, se archivan los registros obtenidos y se notifica a las partes involucradas.

4.1.5.2. 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.

4.1.5.2.1. 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.

4.1.5.2.1.1. Identificar ideas o necesidades

A partir de los requerimientos planteados por el cliente, se identifican las principales ideas y

necesidades del proyecto.

4.1.5.2.1.2. Formular soluciones potenciales

Con base en las ideas y necesidades identificadas se elaboran soluciones potenciales.

4.1.5.2.1.3. 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.

4.1.5.2.1.4. 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.



4.1.5.2.2. 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.

4.1.5.2.2.1. 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.

4.1.5.2.2.2. Desarrollar la arquitectura del sistema:

A partir del análisis de las funcionalidades del sistema se desarrolla la arquitectura básica del

sistema.

4.1.5.2.2.3. 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.

4.1.5.3. PROCESO DE DESARROLLO

En este proceso se presentan las actividades referentes al modelado de requisitos, diseño e

implementación de la solución.

4.1.5.3.1. Sub-proceso de Requisitos

En este sub-proceso se presentan las actividades relacionadas al modelado de requisitos del sistema

a desarrollar.

4.1.5.3.1.1. 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.

4.1.5.3.1.2. Definir y desarrollar los requisitos del hardware


hardware del proyecto.

4.1.5.3.1.3. Definir los requisitos del entorno


entorno del proyecto.



4.1.5.3.1.4. Definir los requisitos de interfaz


Interfaz del proyecto tanto con el usuario y el entorno como con otros sistemas.

4.1.5.3.1.5. 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.

4.1.5.3.2. Sub-proceso de Diseño

En este sub-proceso se definen las actividades inherentes al diseño arquitectónico y detallado del

sistema.

4.1.5.3.2.1. 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.

4.1.5.3.2.2. 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.

4.1.5.3.2.3. 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.

4.1.5.3.2.4. 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.

4.1.5.3.2.5. 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.

4.1.5.3.3. 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.



4.1.5.3.3.1. 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.

4.1.5.3.3.2. Crear el código fuente

Mediante esta actividad se genera el código fuente del programa.

4.1.5.3.3.3. 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.

4.1.5.3.3.4. 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.

4.1.5.3.3.5. 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.

4.1.5.4. 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.

4.1.5.4.1. 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.

4.1.5.4.1.1. 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.

4.1.5.4.1.2. 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.

4.1.5.4.1.3. 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



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 .

4.1.5.4.1.4. 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.

4.1.5.4.1.5. 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.

4.1.5.4.1.6. Proveer asistencia técnica y consultas:

Brindar asistencia técnica y proveer respuestas a cualquier consulta que provenga del usuario.

4.1.5.4.1.7. 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.

4.1.5.4.2. 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.

4.1.5.4.2.1. 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.

4.1.5.4.2.2. 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.

4.1.5.4.2.3. 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



problemas detectados así como también de mejoras. Cualquier corrección o mejora implementada

debe ser registrada para futuras consideraciones.

4.1.5.4.2.4. 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.

4.1.5.4.3. 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.

4.1.5.4.3.1. 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.

4.1.5.4.3.2. 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.

4.1.5.4.3.3. Retirar el sistema

Esta actividad supone la remoción y archivo del sistema en concordancia con el Plan de Retiro

previsto.

4.1.5.5. PROCESOS INTEGRALES DEL PROYECTO

Este proceso supone las actividades necesarias para la finalización exitosa y el aseguramiento de la

calidad del proyecto.

4.1.5.5.1. 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.



4.1.5.5.1.1. Conducir Revisiones

Diferentes tipos de revisiones son realizadas a lo largo del proyectos. Estas pueden pertenecer a las

siguientes categorías:

4.1.5.5.1.1.1. 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.

4.1.5.5.1.1.2. Revisiones Gerenciales

Tienen por objetivo asegurar el progreso del proyecto, un correcto uso de los recursos y

recomendar acciones correctivas.

4.1.5.5.1.1.3. Inspecciones

Tienen por objetivo detectar e identificar defectos en el producto y controlar su corrección.

4.1.5.5.1.1.4. “Walkthroughs”

Tienen por objetivo detectar defectos de un producto, examinar alternativas y generar un

foro de aprendizaje.

4.1.5.5.1.2. 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.

4.1.5.5.1.3. 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.

4.1.5.5.1.4. 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.



4.1.5.5.1.5. 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.

4.1.5.5.1.6. 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.

4.1.5.5.1.7. Reportar Resultados de la evaluación

Mediante esta actividad se presentan los resultados de los procedimientos de prueba ejecutados.

4.1.5.5.1.8. 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.

4.1.5.5.2. 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.

4.1.5.5.2.1. 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.

4.1.5.5.2.2. 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.



4.1.5.5.2.3. 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

4.1.5.5.3. 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.

4.1.5.5.3.1. Implementar la Documentación

Esta actividad incluye el diseño, elaboración y mantenimiento de la documentación.

4.1.5.5.3.2. 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.

4.1.5.5.4. 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.

4.1.5.5.4.1. 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.

4.1.5.5.4.2. 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.



4.1.5.5.4.3. 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.

4.1.6 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 4.1.6.1), (3) Creación del Ciclo de Vida del Proyecto (Sección 4.1.6.2), (4)

Secuenciamiento de Actividades (Sección 4.1.6.3), (5) Asignación de Documentos de Salida

(Sección 4.1.6.4) y (6) Iniciación del Proyecto (Sección 4.1.6.5).

4.1.6.1. 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:

4.1.6.1.1. Identificar todos los modelos de ciclo de vida disponibles para el proyecto

4.1.6.1.2. Identificar los atributos que aplican al finalidad del sistema deseado y al

entorno del proyecto

4.1.6.1.3. Identificar las limitaciones que podría suponer la selección del modelo de

ciclo de vida evaluado

4.1.6.1.4. Evaluar modelos de ciclo de vida utilizados en proyectos anteriores

4.1.6.1.5. Seleccionar el modelo de ciclo de vida que mejor satisfaga los atributos y

limitaciones del proyecto

4.1.6.2. 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.



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.

4.1.6.3 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.

4.1.6.4 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.

4.1.6.5 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.



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.

TRABAJO FINAL DE LICENCIATURA EN SISTEMAS JONATAN PONZO

Selecciónde un modelo

de ciclo de vida

Creación del Ciclo de vidadel proyecto

Secuencia deActividades

Asignación dedocumentos

Modelo de Ciclo de Vida

Ciclo de Vida y Mapa de Actividades

Secuencia de Actividades

Inicio del ProyectoMapa de Documentos

40

PRUEBA DE CONCEPTO CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.

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.

5.1.1 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.



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.

5.1.2 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.

5.2. 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.



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).

6.1. 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



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.

6.2. 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:

6.2.1. 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?

6.2.2. 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



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?

6.2.3. 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.


REFERENCIAS CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.

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: 34-38. ISSN 0163-5719.

Fritz, W. (1992). World view and learning systems. Robotics and Autonomous Systems 10(1): 1-7.

ISSN 0921-8890.

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 610.12-1990.


REFERENCIAS CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.


IEEE Standard for Developing Software Life Cycle Processes.


URL http://www.ieee.org.ar/. 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. 272.

Lavi, J, Kudish, J. (2005). Systems modelling & requirements specification using ECSAM: an

Analysis Method for Embedded & Computer-based Systems. Innovations Syst Softw Eng.

1: 100–115.

Peláez, J (2013). El desarrollo de Software. http://desarrollodesoftware-

jorgepelaez.blogspot.com.ar/2013/03/2-el-desarrollo-de-software.html. Sitio vigente

11/2013

Ross, D, Schoman, K. (1977). Structured Analysis for Requirements Definition. Transactions on

Software Engineering, IEEE, 3(1): 6-15.

Tangelson, O (2004). Argentina frente al siglo XXI. Desarrollo e Integración. Departamento de

DesarrolloProductivo y Tecnológico. Universidad Nacional de Lanús.


http://www.ieee.org.ar/

http://desarrollodesoftware-jorgepelaez.blogspot.com.ar/2013/03/2-el-desarrollo-de-software.html


ANEXO I – RELEVAMIENTO DE HARDWARE CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.


EMBEBIDOS


Jonatan Ponzo - [email protected]

Universidad Nacional de Lanús – Lic. Sistemas

ANEXO I – RELEVAMIENTO DE HARDWARE


mailto:[email protected]


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.



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.

1.1. 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



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 CP16000. 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 32.000 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).



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].



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 2006. 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



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.



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 90.17 mm × 95.89 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,



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



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.



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.

2.2.1. 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) 5

2.1.3 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



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]

2.4.1. 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: 32768



•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



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.

2.5.1. 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



•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 2Clock Speed 1.1 GHz 1.6 GHz

L2 Cache 512 KB 512 KBBus/Core Ratio 11 12

FSB Speed 400 MHz 533 MHzFSB Parity No No

Instruction Set 32-bit 32-bitInstruction Set Extensions SSE2, SSE3, SSSE3 SSE2. SSE3, SSSE3

Embedded Options Available Yes YesSupplemental SKU No No

Lithography 45 nm 45 nmMax TDP 2 W 2 W

VID Voltage Range 0.75-1.1V 0.75 -1.1VTabla 2. Especificaciones técnicas de los procesadores Atom Z510 y Z530



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].

2.7.1. Características Geode LX800

•Processor AMD Geode [email protected]

•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.



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.

Atmega168Atmega328

(Arduino UNO)Atmega1280

Voltaje operativo 5 V 5 V 5 VVoltaje de entrada

recomendado7-12 V 7-12 V 7-12 V

Voltaje de entrada

límite6-20 V 6-20 V 6-20 V

Tabla 3. Niveles de tensión manejados por los procesadores Atmega



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.


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 - 125°C.

3.3. 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: 5 V vía Micro USB o GPIO header

Dimensiones: 85.60mm × 53.98mm27 (3.370 × 2.125 inch)

Peso < 40g

Tabla 4. Información de consumo y dimensiones de Raspberry Pi Modelo A y B



Fig. 8. Raspberry Pi Model B. Diagrama de conexiones.

3.4. 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].


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



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 3.550”) 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.


Este es un desarrollo de similares características al anterior, sus medidas responden al Standard

PC/104, 96mm x 90mm (3.775” x 3.550”) 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.


Completando los desarrollos PC/104 encontramos condiciones similares en el CoreModule 435 el

cual implementa un micro Vortex86DX.



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 - +70°C

• Extendido: -40°C - +85°C

• Almacenamiento: -55°C - +85°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.



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].

Atmega168Atmega328 (Arduino

UNO)Atmega1280

Memoria Flash16KB (2KB reservados

para el bootloader)

32KB (2KB

reservados para el

bootloader)

128KB (4KB reservados

para el bootloader)

SRAM 1 KB 2 KB 8 KBEEPROM 512 bytes 1 KB 4 KB

Tabla 5. Tamaño de memorias en los procesadores Atmega



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



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.

4.4. 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.




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.


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.

4.7. 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/400.


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.



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 = B11111110;



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].

5.2. 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.



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).



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 radio-

frecuencia (módulos de comunicación inalámbrica: Wi-Fi, Bluetooth, etc.) [38].

Modelo A Modelo BPuertos USB 2.0: 1 2 (vía hub USB integrado)

Salidas de vídeo:Conector RCA,

HDMIConector RCA, HDMI

Salidas de audio: 3.5 mm jack, HDMI 3.5 mm jack, HDMIConectividad de red: Ninguna RJ45Periféricos de bajo

nivel:

Pines GPIO, SPI, I²C,

UART26Pines 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:

5.3.1. 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



• 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 - 3.3 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)



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 1149.1 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 sub-

mó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



en 2 columnas de 13 PINs cada una. Proveen 8 PINs GPIO y acceso a interfaces I²C, SPI, UART,

SPI (Serial Peripheral Interface), terminales de alimentación +3v3, +5v y GND, terminales PWM

(Pulse-width modulation), entre otros.

El nivel de voltaje manejado por las GPIO es de 3.3 V x 2-16 mA y no toleran la utilización de 5v.

Si bien no esta soportado en el kernel oficial, las GPUs pueden ser utilizadas como interrupción

recompilando el kernel desde fuentes modificadas.

MIPI CSI-2

Es una interface de Cámara Serial ubicada entre los conectores Ethernet y HDMI a través de la cual

se podrá conectar una Cámara compatible que será producida a corto plazo.

DSI

Interface de Pantalla Serie. Posee 2 canales de datos y 1 de clock pensados para controlar

dispositivos LCD. Algunos Smartphones implementan esta tecnología en la actualidad.

CEC

Consumer Electronics Control (CEC) es una característica de la interface de video HDMI diseñada

para controlar otros dispositivos con la misma característica a través de un solo comando remoto.

Esa característica se torna sumamente relevante a la hora de pensar en Raspberry Pi como un media

center. Mas adelante conoceremos el software necesario para implementar esta aplicación.


El EDUKIT08 fue diseñado como un dispositivo fuertemente orientado a la educación, por ello

implementa una gran variedad de módulos de entrada y salida directamente incorporados en la placa

y listos para ser utilizados.

Algunas características sobresalientes relativas a la interacción con el medio son las siguientes:

• Plataforma de trabajo completa, con los circuitos necesarios para realizar prácticas de distintos

periféricos utilizados frecuentemente en las aplicaciones con microcontroladores.

• No es necesario “cableado” o armado de placa alguna por parte del estudiante, facilitando las

prácticas, ahorrando costos en materiales, y reduciendo los tiempos de “puesta en marcha” de las

experiencias.



• Permite “focalizar” al estudiante y al docente en las prácticas con los distintos módulos que

componen un MCU de la familia Freescale, y no “gastar” tiempo en la preparación de las

mismas.

• Herramienta de Emulación en Tiempo Real / grabación de la memoria Flash incorporada dentro

del sistema didáctico, lo que permite facilidad de uso y ahorro de dinero al no usar herramientas

externas.

• El sistema “EDUKIT08” está equipado con periféricos poco comunes en otros sistemas

didácticos, como la interface RS-485 Master / Slave para soportar redes de hasta 32 nodos, o la

interface IRDA / SIR que permite establecer comunicaciones inalámbricas infrarrojas hasta una

distancia de 1 mts y 115 KBps con otro sistema idéntico o con otro dispositivo IRDA.

• Facilidad de adaptación para trabajar con distintas familias de 8 y 32 Bits de Freescale, por medio

de las placas removibles “PLUGIN”.

• El sistema didáctico ha sido diseñado para crecer en prestaciones y aplicaciones gracias a una

gama de “placas de expansión” que permiten realizar múltiples experiencias (sistemas de control,

comunicación por RF con tecnología ZigBee, manejo de display gráfico, etc.).

A continuación, los módulos incluidos:

• Display inteligente LCD 16 caracteres x 2 líneas con backlight, control de Contraste para

escritura a 8 y 4 bits de datos.

• Display LED de 4 dígitos de 7 segmentos con punto decimal para escritura por

multiplexación de líneas.

• Puerto Serial UART RS-232C (SCI1) para prácticas de comunicación con distintos

dispositivos externos (PCs, Modems, Impresoras, otros EDUKIT08, etc.).

• Puerto Serial UART RS-232C / RS-485 / Infrarrojo IRDA (SCI2), seleccionable por medio

de Jumpers, para comunicaciones en red, inalámbricas, etc.).

• 4 pulsadores para función KBI (KeyBoard Interrupt) y usos grales

• Diodos LEDs de usos grales., indicaciones y “monitoreo” de señales varias.

• Dispositivo de memoria externa EEPROM (24LC256) para prácticas de comunicaciones

I2C.

• MCU integrado para emular comunicaciones SPI y Generación de Señales para prácticas de

función ICAP (captura de pulsos).

• Diodo LED de potencia para prácticas de control por PWM.



• Sensor de Temperatura (LM335Z) y Preset para prácticas conversor A/D de 8 y 10 Bits de

Resolución.

• Puertos I/O de propósitos grales., IRQ e interface SPI disponibles mediante jumpers.

. Fig. 12. Pulsadores y displays de 7 segmentos en EDUKIT08

5.5. PC104 – PIC MICROSTACK

Mas alla de sus 2 puertos USB, el PIC MicroStack no incorpora una gran variedad de módulos de

entrada y salida embebidos en la placa principal pero compensa dicha carencia su apego al standard

PC/104 lo que lo hace ampliamente compatible con cualquier desarrollos que se ajuste a dicho

standard. Existe una gran variedad de placas PC/104 que adicionan dispositivos de entrada y salida

como sensores, actuadores, etc. Posteriormente conoceremos en mas detalle algunos de los módulos

disponibles en el mercado.

Fig. 13. Diagrama de modulos de PIC Microstak




Esta placa incorpora una interesante combinación de interfaces. Posee 2 Puertos Ethernet de 1Gbi

para comunicaciones de alta velocidad, 2 puertos SATA para la conexión de dispositivos de

almacenamiento semi permanente como discos rígidos mecánicos (HDD) o de estado sólido (SSD),

Puertos seriales LPT y PS2 y 8 PINs de entrada/salida de propósito general libremente

configurables por software.

En el plano audiovisual, posee conexiones VGA y LVDS e interfaces de sonido de alta definición

digital y analógica. A continuación una lista de los puertos presentes en la placa:

•VGA and LVDS (c/ backlight)

•2 x Gigabit LAN

•2 x SATA

•7 x USB 2.0 hosts

•2 x RS232/RS422/RS485

•HD Audio

•I/O Signals 8 GPIO

•Mini PCI Express 1 slot


Cool LiteRunner-LX800 presenta una configuración muy similar a la de una PC convencional.

Posee 2 puertos de red Ethernet 100/10 BaseT, 4 puertos USB 2.0, Puertos serial PS2,

RS232/RS422/RS485, puerto de video VGA y Audio AC97. Adicionalmente incorpora 8 entradas y

salida.

A continuación una lista completa de los dispositivos e interfaces de entrada y salida disponibles en

este desarrollo.

•Graphics up to 1920 x 1440 pixels - CRT, TFT, LVDS, with backlight

•2x 100/10 BaseT Ethernet

•4 x USB 2.0

•AC97 sound

•IDE Ultra ATA100, CompactFlash™ socket

•Mini-PCI slot



•Graphics Integrated in the Geode LX800. Up to 254 MB video memory.

•CRT Analog VGA 1920 x 1440 pixel at 85 Hz max.

•TFT Single channel, 18 bits 1600 x 1200 pixel at 60 Hz max.

•LVDS Single channel, 18 and 24 bits 1600 x 1200 pixel at 60 Hz max.

•Audio AC97 2.1, 2 channels

•Serial 2 x RS232/RS422/RS485

•1 x RS485/Irda with termination

•IDE 1 x Ultra ATA100 (ATA6) port

•Compact Flash Type 2 socket

•LPT Multi-Mode™ bi-directional Parallel

•PS2 Keyboard, mouse

•GPIO 8 programmable signals

•Status LED HDD, power, standby, power mode, live, 4x Ethernet, watchdog

•ISA Bus PC/104

•PCI Bus Mini-PCI slot

•I²C bus Supported


De similares características a Cool LiteRunner-LX800, CoreModule 435 presenta los siguientes

puertos de entrada y salida:

•4 Serial, 2 USB, 8 GPIOs

•PC/104 ISA

•PATA DMA 100 IDE interface supports up to two hard drives

•Storage CompactFlash socket

•Serial 2x RS-232, 2x RS-232/422/485

•USB 2x USB 2.0 ports

•KB/MS PS/2 interface

•GPIO Eight general-purpose digital I/O PINs

•Ethernet 1x integrated Vortex86 10/100 port and 1x Intel 82451PI

•1 x Gigabit Ethernet



•1 x VGA Video Interface, Graphics Engine Integrated 2D, 64-bit, single-cycle, 100MHz

Resolution 1600x768, Video Memory 32MB/64MB DDR2

•TTL/TFT Dual channels 12-bit or Single Channel 18-bit color depths

6. MÓDULOS DE EXPANSIÓN

Además de los dispositivos y puertos de entrada y salida embebidos en la placa, cada desarrollo

permite anexar a si mismo diversos módulos independientes, capaces de ampliar su capacidad de

interacción con el medio. A continuación presentaremos algunos de los módulos mas significativos

disponibles en el mercado para cada desarrollo.

6.1. ARDUINO UNO

Las denominadas placas "Shield" son extensiones para Arduino (generalmente Arduino UNO o

Arduino Pro 328) que permiten expandir sus posibilidades de inter-conectividad.

Fig. 14. Placas de expansion PC/104

Mencionamos a continuación, las placas mas destacadas.

•Arduino WIFI Shield

•Arduino Motor Shield

•Arduino Wireless SD Shield

•EasyVR Arduino Shield



•Arduino RFID Shield

•Arduino Musical Shield

•Arduino CAN-BUS Shield

•Arduino MicroSD Shield

•Arduino USB Host Shield

•Arduino Screw Shield

•Arduino Cellular Shield

•Arduino GPS Shield

•Arduino SD Shield

•Arduino Photo Shield

•Arduino Ethernet Shield

6.2. PIC – IBOARD ICA05

Entre los módulos de expansión disponibles para el iBoard ICA05 destacamos el siguiente.

ICA05 – Kit de desarrollo gráfico LCD

Este kit incorpora un completo set capaz de abarcar cualquier tipo de aplicación (Oscilosconpio,

monitoreo de señales, visualización de gráficos, etc.). Posee un puerto externo GLCD a través del

cual el usuario puede montar LCD a la estructura cobertora del modulo.

Adicionalmente incluye sensores de temperatura, luz y voltaje fácilmente interconectables con los

PINs del PIC.

Fig. 15. Modulo de expansion serial y display 7 segmentos en iBoard Lite


Gracias al diseño “removible” de las placas “PLUGIN”, el sistema puede personalizarse para

trabajar con 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.

[16]

Algunas de las placas “PLUGIN” para trabajar con HC908, HC9S08, y Serie FLEXIS 8 / 32 Bits

disponibles son:

9. Placa “PLUGIN_AP” contiene MC68HC908AP32 para HC908.

10. Placa “PLUGIN_AW” contiene MC9S08AW60 para HC9S08.

11. Placa “PLUGIN_FLX08” contiene MC9S08AC60CFUE para HC9S08 Flexis.

12. Placa “PLUGIN_FLXCV1” contiene MCF51AC256AVFUE para ColdFire “V1”Flexis con

módulo CAN.

13. Placa “PLUGIN_FLXJM” contiene MCF51JM128CFUE para ColdFire “V1” Flexis con

módulo USB.

6.4. RASPBERRY PI

Existe una gran cantidad de conexiones en Raspberry Pi capaces de ser utilizadas como puertos de

expansión. Entre los principales encontramos:

•Rpi GPIO (Entrada/Salida de propósito general) completamente configurable por software.

•Conector DSI que permite la conexión y control de pantallas LCD.

•Conector CSI que permite la conexión de una cámara.

Fig. 16. Modulo de expansion en Raspberry Pi

Los módulos adicionales más significativos disponibles para Raspberry Pi son los siguientes:

Heber x10i

Heber x10i permite administrar múltiples entradas y salidas vía USB en tiempo real desde una PC.



AFLEX

Es un módulo de control dual de motores y adquisición de datos con interfaces I2C y serial. Provee

drivers para el manejo de 2 motores de hasta 3.5A, un puerto de 8bits con PINs configurables como

entrada, salida o entrada analógica, un conversor analógico digital ADC de 10 bits con hasta 4

canales analógicos, 4 entradas para conexiones de sensores y un sensor infrarrojo.

GELI 'jelly'(GPIO Experimenter and Lab Interface Board)

Modulo expansor de GPIO que incorpora conversores analogico-digitales, control de motores de

continua, un puerto RS232, un clock de tiempo real FS1307 y una placa de desarrollo iWire de

150mm x 100mm.

aLaMode

“À la mode” es un clon de Arduino diseñado para oficiar de interface con Raspberry Pi. Incorpora

sensores, manejo de servo motores y un clock de tiempo real.

PiBorg

Pi borg es un modulo que permite controlar motores de continua, motores paso a paso, BLDC y

Solenoides de hasta 10A desde Raspberry PI. Permite administrar velocidad, aceleración y sentido

de los mismos.

Pi232 RS232 board

Pi232 incorpora un puerto RS232 que se conecta al GPIO.

Relay board and Raspberry Pi GPIO

Modulo expansor que incorpora 8 relays y 8 entradas adicionales.

MiniPiio L293D

Es un pequeño modulo (50mm x 40mm) que adiciona dual H-Bridge para el control de motores de

continua utilizando un chip L283D

MiniPiio DIO16

Es un modulo que adiciona 16 canales de entradas/salidas digitales. Puede añadirse a partir del

puerto SP1 o I2C.

MiniPiio RS232

Incorpora una interface basica TTL-RS232. Sus medidas son 50mm x 40mm



Para conocer mas módulos visitar http://elinux.org/RPi_Expansion_Boards

6.5. PC/104

El standard PC/104 vuelve fácilmente expandibles a los desarrollos que lo implementan. La medida

de las placas es fija al igual que el puerto de interconexión (ISA, PCI o PCI-Express) y su posición

en la placa con la intención de agruparlas en forma de pila ahorrando espacio y reduciendo la

cantidad de conectores necesarios.

Existen 3 implementaciones del standard PC/104 que varían en el puerto utilizado para la

interconexión de las capas.

•PC/104: Utiliza el puerto ISA

•PCI-104: Utiliza el puerto PCI

•PC/104-Plus: Permite utilizar ISA o PCI

•PC/104-Express: Permite utilizar los puertos PCI y PCI Express.

Fig. 17. Diagrama de interconexion de placas PC/104

Algunos módulos de expansión disponibles en el standard PC/104 y sus variantes son:

MiniModule SIO

Provee una gran flexibilidad a sistemas basados en CoreModule 730 expandiendo sus opciones de

entrada/salida. Incluye además del puerto de interconexión PC/104 (ISA), puertos seriales,

paralelos, Lectora de diskettes (Floppy) e interfaces PS/2. Sus principales características son:


http://elinux.org/RPi_Expansion_Boards


14. PC/104 (ISA Bus)

15. 4 serial ports - 2 with DB-9 connectors on I/O edge, 2 by pin header

16. 2 USB 2.0 ports, Parallel Port, Floppy, PS/2, I2C, LPC

Modulo Multi-funcion analogico y digital PCM-MIO-G

Diseñada principalmente para asistir a la conversion analogico-digital de alta

precision, el modulo PCM-MIO-G presenta las siguientes especificaciones:

Fig. 18. Interconexion de placas PC/104 o “Stack”

Entradas Analógicas:

• Two 8-channel, 16-bit Analog-to-Digital (A/D) (LTC-1859CG) with sample-and-hold circuit

support

• Sample Rate: 85 ksps

• Conversion Rate: 100 ksps

• Each channel independently software programmable for input type and range

• Input ranges:

0-5V, 0-10V, +/-5V or +/-10V

• Input Protection: +/-25V

• Supports industry standard signal conditioners



• Any combination of up to 16 single-ended input channels and up to 8 differential input

channels

• DMA or interrupt I/O supported

Salidas Analógicas:

• Two, 4-channel, 12-bit Digital-to-Analog (D/A) (LTC-2704CGW-12)

• Output ranges:

0-5V, 0-10V, +/-5V or +/-10V

• Each channel independently software programmable for output type and range

• Output channels can be updated and cleared individually or simultaneously

• Interrupt I/O supported

• Supports industry standard signal conditioners

• Digital I/O

• 48 Bidirectional lines with Input, Output or Output with Readback with event-sense support

(WS16C48)

• 12 mA Sink Current

• Compatible with industry standard I/O racks

El modulo opera dentro del rango de temperatura -40°C to +85°C.

7. PROGRAMACIÓN

7.1. ARDUINO UNO

El entorno de programación de Arduino es fácil de usar para principiantes y lo suficientemente

flexible para los usuarios avanzados. Pensando en los docentes, Arduino está basado en el entorno

de programación de Procesing con lo que el estudiante que aprenda a programar en este entorno se

sentirá familiarizado con el entorno de desarrollo Arduino. [33]

La plataforma Arduino se programa mediante el uso de un lenguaje propio basado en el popular

lenguaje de programación de alto nivel Processing. Sin embargo, es posible utilizar otros lenguajes

de programación y aplicaciones populares en Arduino. Algunos ejemplos son Java, Flash, C#, Perl,

Python, y Ruby, entre otros. Esto es posible debido a que Arduino se comunica mediante la

transmisión de datos en formato serie que es algo que la mayoría de los lenguajes anteriormente



citados soportan. Para los que no soportan el formato serie de forma nativa, es posible utilizar

software intermediario que traduzca los mensajes enviados por ambas partes para permitir una

comunicación fluida [33].

Es interesante tener la posibilidad de operar Arduino mediante esta gran variedad de sistemas y

lenguajes puesto que dependiendo de cuales sean las necesidades del problema que vamos a

resolver podremos aprovecharnos de la gran compatibilidad de comunicación que ofrece.

Arduino esta basado en C y soporta todas sus funciones estándar y algunas de C++. Además existen

interfaces de programación gráfica como Pduino y Minibloq.

El micro controlador ATmega 328 contiene un bootloader pre grabado que permite la carga del

código a través del mismo sin la necesidad de programadores externos, puede ser programado a

través del puerto USB mediante el software Arduino o utilizando la interface ICSP de programación

serial (In-Circuit Serial Programming) lo cual sobreescribirá el bootloader. El software Arduino de

programación puede ejecutarse tanto en MS Windows como en GNU/Linux o bien puede utilizarse

Atmel para Windows o DFU en Linux y Mac OS X [33].

Librerías

Arduino posee una gran variedad de Librerías que facilitan ampliamente su programación. Entre

ellas destacamos:

• Serial: Lectura y escritura mediante el puerto serie.

• EEPROM: Lectura y escritura en el almacenamiento permanente.

• Ethernet: Conexión a Internet mediante “Arduino Ethernet Shield“. Puede funcionar como

servidor que acepta peticiones remotas o como cliente. Se permiten hasta cuatro conexiones

simultaneas;

• Firmata: Comunicación con aplicaciones de PC utilizando el protocolo estándar del puerto

serie.

• LiquidCrystal: Control de LCDs con chipset Hitachi HD44780 o compatibles. La biblioteca

soporta los modos de 4 y 8 bits.

• Servo: Control de servo motores. A partir de la versión 0017 de Arduino la biblioteca

soporta hasta 12 motores en la mayoría de placas Arduino y 48 en la Arduino Mega. El manejo

de la biblioteca es bastante sencillo. Mediante attach(número de pin) añadimos un servo y

mediante write podemos indicar los grados que queremos que tenga el motor (habitualmente

de 0 a 180).



• SoftwareSerial: Comunicación serie en pines digitales. Por defecto Arduino incluye

comunicación sólo en los pines 0 y 1 pero gracias a esta biblioteca podemos realizar esta

comunicación con el resto de pines.

• Stepper: Control de motores paso a paso unipolares o bipolares. El manejo es sencillo. Basta

con iniciar el motor mediante Stepper indicando los pasos que tiene y los pines a los que esta

asociado. Se indica la velocidad a la que queramos que gire en revoluciones por minuto con

setSpeed(rpm) y se indican los pasos que queremos que avance con step(pasos). Existe la

posibilidad de anexar el modulo Arduino Motor Shield basado en el circuito integrado L298,

el cual es driver doble "full bridge" diseñado para controlar cargas inductivas como relays,

solenoides, motores DC y motores paso a paso. Permite manejar dos motores DC con la placa

Arduino, controlando la velocidad y dirección de cada uno de forma independiente. También

se puede medir la absorción de corriente de cada motor, entre otras características.

• Wire: Envío y recepción de datos sobre una red de dispositivos o sensores mediante Two

Wire Interface (TWI/I2C).

Además las bibliotecas Matrix y Sprite de Wiring son totalmente compatibles con Arduino y sirven

para manejo de matrices de leds.

Creación de bibliotecas

Además de las bibliotecas base, las que son compatibles y las que han aportado otras personas

tenemos la posibilidad de escribir nuestra propia biblioteca. Esto es muy interesante por varias

razones:

• Permite disponer de código que puede reutilizarse en otros proyectos de forma cómoda

• Nos permite mantener el código fuente principal separado de las bibliotecas de forma que

sean mantenibles de forma separada;

• Permite una organización de los programas construidos más clara y elegante.

7.2. PIC

El PIC usa un juego de instrucciones tipo RISC, cuyo número puede variar desde 35 para PICs de

gama baja a 70 para los de gama alta. Las instrucciones se clasifican entre las que realizan

operaciones entre el acumulador y una constante, entre el acumulador y una posición de memoria,



instrucciones de condicionamiento y de salto/retorno, implementación de interrupciones y una para

pasar a modo de bajo consumo llamada sleep [32].

Microchip proporciona un entorno de desarrollo freeware llamado MPLAB que incluye un

simulador software y un ensamblador aunque otras empresas desarrollan compiladores C y BASIC.

Microchip también vende compiladores para los PICs de gama alta ("C18" para la serie F18 y

"C30" para los dsPICs) y se puede descargar una edición para estudiantes del C18 que inhabilita

algunas opciones después de un tiempo de evaluación.

Para el lenguaje de programación Pascal existe un compilador de código abierto, JAL, lo mismo

que PicForth para el lenguaje Forth. GPUTILS es una colección de herramientas distribuidas bajo

licencia GPL que incluye ensamblador y enlazador, y funciona en Linux, MacOS y Microsoft

Windows. GPSIM es otra herramienta libre que permite simular diversos dispositivos hardware

conectados al PIC [32].

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.

Existe un solo acumulador (W), cuyo uso (como operador de origen) es implícito (no está

especificado en la instrucción) y todas las posiciones de la RAM funcionan como registros de

origen y/o de destino de operaciones matemáticas y otras funciones.

Implementa una pila de hardware para almacenar instrucciones de regreso de funciones y posee 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 [32].

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.

Para transferir el código de un ordenador al PIC normalmente se usa un dispositivo llamado

programador. La mayoría de PICs que Microchip que se distribuyen hoy en día incorporan ICSP (In

Circuit Serial Programming, programación serie incorporada) o LVP (Low Voltage Programming,

programación a bajo voltaje), lo que permite programar el PIC directamente en el circuito destino.

Para la ICSP se usan los pines RB6 y RB7 (En algunos modelos pueden usarse otros pines como el



GP0 y GP1 o el RA0 y RA1) como reloj y datos y el MCLR para activar el modo programación

aplicando un voltaje de 13 voltios [32].

Existen muchos programadores de PICs, desde los más simples que dejan al software los detalles de

comunicaciones, a los más complejos, que pueden verificar el dispositivo a diversas tensiones de

alimentación e implementan en hardware casi todas las funcionalidades. Muchos de estos

programadores complejos incluyen ellos mismos PICs preprogramados como interfaz para enviar

las órdenes al PIC que se desea programar. Uno de los programadores más simples es el TE20, que

utiliza la línea TX del puerto RS232 como alimentación y las líneas DTR y CTS para mandar o

recibir datos cuando el microcontrolador está en modo programación. El software de programación

puede ser el ICprog, muy común entre la gente que utiliza este tipo de microcontroladores. Entornos

de programación basados en interpretes BASIC ponen al alcance de cualquiera proyectos que

parecieran ser ambiciosos [32]. A continuación una buena recopilación de herramientas de

desarrollo para PICs:

• PICStart Plus (puerto serie y USB)

• Promate II (puerto serie)

• MPLAB PM3 (puerto serie y USB)

• ICD2 (puerto serie y USB)

• ICD3 (USB)

• PICKit 1 (USB)

• IC-Prog 1.06B

• PICAT 1.25 (puerto USB2.0 para PICs y Atmel)

• WinPic 800 (puerto paralelo, serie y USB)

• PICKit 2 (USB)

• PICKit 3 (USB)

• Terusb1.0

• Eclipse (PICs y AVRs. USB.)

• MasterProg (USB)

• Además es posible hacer un programador de manera casera, en

http://microspics.blogspot.com hay una lista con los más utilizados.

• Depuradores integrados

• ICD (Serie)

• ICD2 (Serie ó full speed USB - 2M bits/s)



• ICD3 (High speed USB - 480M bits/s)

• Emuladores

• Proteus - ISIS

• ICE2000 (puerto paralelo, convertidor a USB disponible)

• ICE4000 (USB)

• PIC EMU

• PIC Cdlite

7.2.1. PIC- ICP05 iBoard Lite

Como se menciono en el apartado anterior, una de las metodologías de programación utilizadas en

los PICs distribuidos en la actualidad es ICSP (In Circuit Serial Programming). ICP05 iBoard Lite

no es la excepción e incorpora dicho puerto. Además posee puertos de comunicación

SPI/I2C/USART/PS2/USB.

7.3. RASPBERRY PI

Como fue mencionado anteriormente, Raspberry Pi esta diseñado para utilizar sistemas operativos

basados en el kernel de Linux debido a su gran capacidad de adaptabilidad a especificaciones de

hardware de baja y mediana performance permitiendo optimizar la utilización de los recursos.

Si bien la distribución de Linux Debian es la mas recomendada en la actualidad y puede ser

descargada libremente del sitio de Raspberry, existen diversas opciones compatibles como:

OS Completo:

•Arch Linux ARM

•Debian 6.0 (Squeeze)

•Gentoo Linux

•Google Chrome OS

•Puppy Linux

•Raspberry Pi Fedora Remix

•Raspbian (Wheezy port with faster FP support)

•RiscOS

•Slackware ARM (formally ARMedslack)

•QtonPi (embedded Linux)



Distribuciones livianas multi-proposito:

• Squeezed Arm Puppy for ARMv6 (sap6)

Distribuciones livianas dedicadas:

• IPFire

• OpenELEC

• Raspbmc (Media Center)

• XBMC (Media Center)

La GPU es accedida a través del firmware que es cargado en la misma en tiempo de booteo

proveniente de la tarjeta SD. Esta imagen es conocida como Image Blob.

Las aplicaciones utilizan llamadas en tiempo de ejecución a librerías de código cerrado las cuales a

su vez, realizan llamadas a drivers de código abierto en el Kernel de Linux.

Las aplicaciones de vídeo utilizan OpenMax, las aplicaciones 3D utilizan OpenGL ES y las

aplicaciones 2D utilizan OpenVG. Estos últimos 2 a su vez, utilizan EGL. OpenMAX y EGL

utilizan drivers de código abierto del Kernel.

Programación

El Sistema Operativo de Raspberry Pi se basa en el kernel de Linux como mencionamos

anteriormente y soporta, entro otros lenguajes de programación como Python, BBC Basic, C y Perl

principalmente, los mencionados en la siguiente lista:

Testeados en la placa:

•Clojure

•gcc

•g++

•Interp

•Mono (C#)

•OCaml

•NodeJS 0.6.18 (Javascript)

•Perl

•Python (Lenguaje principal)

•Ruby 1.9.2 (KidsRuby)

•Scala



Se espera que funcionen:

• Java

• Eclipse

• Tcl/Tk

• Lazarus

• (maybe) BoaConstructor

• Anjuta for C/C++

• Dev-C++

• CodeBlocks

• Lua

• BBC BASIC

• mdfs.net

• ROOL

• Small Basic

• Squeak implementation of Smalltalk

• Processing

• Other BASIC variants common to Debian/Ubuntu/Fedora etc. are all likely to work fine,

including:

• basic256 - educational BASIC programming environment for children

• bwbasic - Bywater BASIC Interpreter

• sdlbasic - BASIC interpreter for game development

• yabasic - Yet Another BASIC interpreter

• Regina Rexx

• GalaxC programming language and XXICC "Chicken Coop" environment (works in

progress)

Entornos gráficos de Programación soportados:

•Gambas (Estilo Visual Basic)

•Scratch

•Alice

•Android App Inventor

•Kodu

•Star Logo



•PrimerLabs CodeHero

Lenguajes orientados a Robótica:

•Lego Mindstorms

•Kturtle and other Logo/turtle graphics (The IO board supports motor drive outputs)


El sistema EDUKIT08 es 100% compatible con entornos integrados de desarrollo como el WinIDE

de P&E Microcomputer Systems, CodeWarrior 5.x / 6.x de Freescale Semiconductor, ICC08 de

Imagecraft, Cosmic Compiler, etc

Entorno WinIDE:

El sistema didáctico soporta entornos integrados de trabajo como el WinIDE (un entorno muy

sencillo para el estudiante que recién hace sus primeros pasos en el mundo de los MCUs) que

permite trabajar en Assembler en forma muy integrada. [16]

• Edición con WinIDE (editor de Texto).

• Ensamblado con CASM08 compilador assembler.

• Programación de la memoria FLASH con el PROG8SZ y múltiples Algoritmos de

programación ".08p".

• Carga de código en memoria FLASH para uso de depuración.

Emulación en Tiempo Real y depuración con ICD08SZ, incluyendo:

•Carga de código en RAM.

•Ejecución "Real -Time" en RAM o FLASH (grabada con PROG08SZ)

•Un "hardware breakpoint" en FLASH (en cualquier posición flash)

•Multiples breakpoints en RAM

•Modos de ejecución Paso a Paso, Multi-paso, y continuo.

•Depuración en "Real - Time" sin demoras o instrucciones extra.

•Visualización en pantalla de registros del CPU, ventana de memoria, variables elegidas por

el usuario, etc.

•Documentación de Ayuda "On-Line" para todo el software.



•Software integrado dentro del entorno WinIDE, permite acceso inmediato a

las aplicaciones.

Entorno Integrado CodeWarrior:

El entorno CodeWarrior de Freescale Semiconductor es un entorno muy profesional apto para

trabajar con todas las familias de 8 a 32 bits que permite realizar proyectos tanto en Assembler

como en código “C” y posee una herramienta de configuración de periféricos llamada “Processor

Expert” que facilita la tarea de configuración de los registros de cada uno de los periféricos

utilizados en una aplicación por medio de simples “Clicks” en distintas opciones. [16]


La metodología de programación de los PICs ha sido explicada en apartados anteriores por lo cual

continuaremos con particularidades que incorpora el desarrollo MicroStack.

La instalación del software Mecanique Microcode Loader automáticamente instala un puerto COM

virtual en la PC o Laptop habilitando al conexión directa con el MicroStack a través de un cable

USB y permitiendo la carga de archivos .hex generados por la mayoria de los compiladores PIC

como MPLAB. El software de programacion MicroCode Loader funciona en Windows 95, 98, ME,

NT, 2000, XP y Vista y es muy intuitivo.

No es necesario hardware adicional para la programación en tanto se utilice un PIC con

BootLoader y la placa sea alimentada a través del puerto USB.

El puerto COM virtual permite la comunicación serial simple a traves del USB1 para, por eje, log

de datos.

Los desarrollos siguientes implementan arquitecturas tradicionales de PC como x86 por lo cual

soportan sistemas operativos convencionales como Windows y Linux y consecuentemente todos los

entornos de desarrollo correspondientes a los lenguajes de programación soportados por dichas

plataformas. A continuación los sistemas operativos soportados por cada desarrollo.


Sistemas Operativos soportados: Windows XP, XP Embedded, Windows CE, Linux, DOS


Sistemas Operativos soportados: Windows XP, XP Embedded, Windows CE, Linux, VxWorks




Sistemas Operativos soportados:: QNX v6.3; Windows CE 5.0, 6.0

8. DISPONIBILIDAD EN EL MERCADO LOCAL E INTERNACIONAL Y COSTOS.

8.1. ARDUINO UNO

Las productos Arduino son fabricados en Italia por SmartProjects. La mejor alternativa para adquirir

placas o Shields Arduino en Argentina es a través de su distribuidor local Intek Elelronica.

Su sitio web es http://www.intekelectronica.com.ar/ y el Arduino UNO se comercializa a un costo

de $257.81. Dada la popularidad del modelo, su disponibilidad es alta y el tiempo de entrega no

supera los 7 dias.

Existe la posibilidad de adquirir Arduino UNO junto con un kit de desarrollo que contiene los

siguientes elementos:

•1 Arduino Uno + 1 cable USB

•1 conector recto, linea individual 2,54 40x1

•1 placa de experimentación (Protoboards) con 840 puntos

•1 kit de 70 hilos para el cableado

•5 10K Ohm Resistencias 1/4W

•5 2.2K Ohm Resistencias 1/4 W

•10 220 Ohm Resistencias 1/4W

•5 330K Ohm Resistencias 1/4W

•5 100nF condensadores polyester

•5 10nF condensadores polyester

•3 100uF condensadores electrolíticos 25Vdc

•1 4,7K Ohm Termistore

•1 70..100K Ohm LDR VT90N2

•3 5mm LED ROJOS

•1 5mm LED VERDES

•1 5mm LED AMARILLOS

•1 10Kohm potenciómetro, para PCB



•2 BC547 Transistores TO92

•1 Zumbador

•5 Pulsadores para PCB, 12x12mm de tamaño

•2 4N35 Optoacoplador 6DIP

•2 sensores Tilt

•1 Diodo 1n4007

•1 MOS Irf520

Otras alternativas internacionales con envío a la Argentina son las siguientes:

• DitenTec - http://www.ditentec.com.ar – Arduino UNO U$S 215

• OpenHacks - http://www.openhacks.com/ - Arduino UNO U$S 215

Si bien el costo del producto es inferior a el del distribuidor local, se deben afrontar impuestos

de importación del orden de los U$S90 y tiempos de entrega superiores a las 2 semanas.


ICP05 iBoard lite puede adquirirse a través su sitio de internet:

PICCircuit.com - http://www.piccircuit.com/shop/pic-dev-board/21-icp05-iboard lite.html a un

costo de U$S 40 + envìo 6U$S ambos abonables mediante Paypal. El tiempo de entrega es de 6 a

21 dìas habiles. Durante ese periodo el producto puede ser rastreado mediante el uso del Tracking

Number provisto por el comercializador

El modulo de expansión gráfica ICA05 puede ser adquirido bajo las mismas condiciones a un costo

de U$S40 en el siguiente sitio: http://www.piccircuit.com/shop/pic-dev-board/67-ica05-graphic-lcd-

development-kit.html U$S 39.90.

8.3. RASPBERRY PI

Raspberry Pi puede ser adquirido a través de distribuidores diferentes, RS y Element14 y su precio

es de U$D 35 + impuestos y envio alcanzando un valor estimado de U$S42 a la provincia de

Buenos Aires.


http://www.piccircuit.com/shop/pic-dev-board/67-ica05-graphic-lcd-development-kit.html

http://www.piccircuit.com/shop/pic-dev-board/67-ica05-graphic-lcd-development-kit.html

http://www.piccircuit.com/shop/pic-dev-board/21-icp05-iboard%20lite.html


• RS online http://raspberrypi.rsdelivers.com/default.aspx?cl=1

• Element14. Precio http://www.element14.com/community/groups/raspberry-pi

Ambos comercializadores realizan envíos a la Argentina. Al momento de la redacción de este

documento existe una sobre demanda del producto que retrasa notablemente los tiempos de entrega

incluso debiendo ocupar listas de espera. Se prevé que bajo circunstancias convencionales, el

tiempo de entrega serà de entre 2 y 3 semanas.

Raspberry Pi posee garantía y acepta devoluciones. En algunos casos, la fundación Raspberry Pi se

hace cargo de los gastos de envío.

8.4. FREESCALE EDUKIT08

EDUKIT08 puede es desarrollado por EDU Devices y puede ser adquirido en Argentina a través de

su sitio http://www.edudevices.com.ar/index.htm.

Su costo es de U$S $ 240.- + I.V.A (10,5%) ,

Existe también la posibilidad de adquirir una versión mas completa que incluye EDUKIT08 + el

PLUGIN_AW + R(S)_POD por un costo de U$S350.

Su desarrollador es de origen nacional por lo cual su nivel de disponibilidad es muy alto y el tiempo

de entrega bastante reducido.

8.5. PC/104

PC104 PIC MicroStack es comercializado por Farnell y distribuido de manera local por Electro-

Componentes. Su precio internacional es de U$S73 y puede ser adquirido a través de los siguientes

sitios:

Farnell:

http://uk.farnell.com/powerlite-systems/usb-microstak/main-board-kit-usb-microstak/dp/1466680

debiendo afrontar gastos de envío e impuestos de importación (20U$S aproximadamente) y tiempos

de entrega aproximados de entre 2 y 3 semanas dependiendo de la existencia de stock.

Electrocomponentes (Distribuidor local de Farnell):

Solís 225/227/229, 1078-Buenos Aires, Argentina

Tel: +54 11443753366

Email: [email protected]


http://uk.farnell.com/powerlite-systems/usb-microstak/main-board-kit-usb-microstak/dp/1466680

http://www.edudevices.com.ar/index.htm

http://www.element14.com/community/groups/raspberry-pi


Web: www.electrocomponentes.com

Mediante este distribuidor se disminuyen los costos de importación y se elimina el costo de envío

internacional aunque su disponibilidad es reducida y los tiempos de entrega pueden no variar

respecto de Farnell.

Linea Cool LiteRunner y CoreModule

Cool LiteRunner-ECO, Cool LiteRunner-LX800 y CoreModule 435 son comercializados por

AdLink y distribuida por SCS Embeeded Tech y pueden adquirirse a través de su sitio web

http://scsembeddedtech.com/Lippert_PC-104_Price_List.php.

Los precios varían según el rango de temperatura de operación. A continuación los costos de los 3

desarrollos en todas sus variantes.

Cool LiteRuneer LX800:

Modelo: Cool LiteRunner-LX800 (CLR-LX800),

Prod. 702-0008-10 - Rango de Temperatura: 0°C .. +60°C - Costo: $494.00

Prod. 802-0008-10 - Rango de Temperatura: -20°C .. +60°C - Costo: $529.00

Prod. 902-0008-10 - Rango de Temperatura: -40°C .. +85°C - Costo: $713.00

Cool LiteRunner-ECO

Modelo: Cool LiteRunner-ECO (CLR-ECO), Intel Atom Z510 (1.1GHz), 2GB RAM

Prod: 702-0012-12 - Rango de temperatura: 0°C .. +60°C - Costo: $633.00

Prod: 802-0012-12 - Rango de temperatura: -20°C .. +60°C- Costo: $686.00

Prod: 902-0012-12 - Rango de temperatura: -40°C .. +85°C - Costo: $892.00

Modelo: Cool LiteRunner-ECO (CLR-ECO), Intel Atom Z530 (1.6GHz), 2GB RAM, incl.

Disipador de calor

Prod: 702-0012-15 - Rango de temperatura: 0°C .. +60°C - Costo: $792.00

Prod: 802-0012-15 - Rango de temperatura: -20°C .. +60°C - Costo: $858.00.

Prod: 902-0012-15 - Rango de temperatura: -40°C .. +85°C - Costo: $1116.00.

Existen modelos con inferior capacidad de memoria RAM a precios mas económicos.


http://scsembeddedtech.com/Lippert_PC-104_Price_List.php

http://www.electrocomponentes.com/


Distribucion Local:

Existe un distribuidor de desarrollos PC/104 en Argentina llamado Microtec. Su sitio web es

http://microtec.com.ar/ y distribuyen entre otras la línea Cool LiteRunner y modulos de expansion

PC/104:

http://microtec.com.ar/productos/adquisicion/pc104/modulos-pc-104_50.html

9. PRINCIPALES MERCADOS DE APLICACIÓN, VENTAJAS Y DESVENTAJAS.

9.1. ARDUINO UNO

Las aplicaciones que nos ofrece Arduino son múltiples, y dependerá de nuestra imaginación.

Mediante sensores podemos crear aplicaciones sencillas enfocadas a la docencia para estudiantes de

electrónica, proyectos más elaborados para la industria utilizando servomotores o incluso sistemas

dirigidos simplemente al ocio. Es muy utilizado también en los entornos artísticos para crear obras

más elaboradas, dada su facilidad de programación [2].

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 se pueden montar a mano o adquirirse y el entorno de desarrollo integrado libre se puede

descargar gratuitamente [2].

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].

¿Por qué Arduino?

Hay muchos otros microcontroladores y plataformas con microcontroladores disponibles para la

computación física. Parallax Basic Stamp, BX-24 de Netmedia, Phidgets, Handyboard del MIT, y

muchos otros ofrecen funcionalidades similares. Todas estas herramientas organizan el complicado

trabajo de programar un microcontrolador en paquetes fáciles de usar. Arduino, además de

simplificar el proceso de trabajar con microcontroladores, ofrece algunas ventajas respecto a otros

sistemas a profesores, estudiantes y amateurs: [33]

• Asequible - Las placas Arduino son más asequibles comparadas con otras plataformas de

microcontroladores. La versión más cara de un modulo de Arduino puede ser montada a mano,

e incluso ya montada cuesta bastante menos de 60€


http://microtec.com.ar/productos/adquisicion/pc104/modulos-pc-104_50.html

http://microtec.com.ar/


• Multi-Plataforma - El software de Arduino funciona en los sistemas operativos Windows,

Macintosh OSX y Linux. La mayoría de los entornos para microcontroladores están limitados

a Windows.

• Software ampliable y de código abierto- El software Arduino esta publicado bajo una

licencia libre y preparado para ser ampliado por programadores experimentados. El lenguaje

puede ampliarse a través de librerías de C++, y si se está interesado en profundizar en los

detalles técnicos, se puede dar el salto a la programación en el lenguaje AVR C en el que está

basado. De igual modo se puede añadir directamente código en AVR C en tus programas si así

lo deseas.

• Hardware ampliable y de Código abierto - Arduino está basado en los microcontroladores

ATMEGA168,ATMEGA328 y ATMEGA1280. Los planos de los módulos están publicados

bajo licencia Creative Commons, por lo que diseñadores de circuitos con experiencia pueden

hacer su propia versión del módulo, ampliándolo u optimizándolo. Incluso usuarios

relativamente inexpertos pueden construir la versión para placa de desarrollo para entender

cómo funciona y ahorrar algo de dinero. [33]

9.2. PIC – ICP05 IBOARD LITE

Este diminuto desarrollo, tan solo 10cm x 5.5cm posee un increíble espectro de aplicación.

Su gran cantidad y variedad de dispositivos de entrada/salida y módulos disponibles en el mercado

hace que pueda ser implementado para el control de motores DC, medición, registro y control de

condiciones ambientales, monitoreo de señales, visualización de gráficos, dispositivos de seguridad

y muchos mas. Además de sus condiciones técnicas, se puede adquirir a un precio realmente bajo,

U$S40.

En su sitio web encontraremos una gran cantidad de video-tutoriales referentes a las diversas

aplicaciones disponibles. http://www.piccircuit.com/shop/pic-code/41-tutorial-5a-4x3-keypad-

demo.html

ICA05 – Kit de desarrollo gráfico LCD

Este kit incorpora un completo set capaz de abarcar cualquier tipo de aplicación (Oscilosconpio,

monitoreo de señales, visualización de gráficos, etc.). Posee un puerto externo GLCD a través del

cual el usuario puede montar LCD a la estructura cobertora del modulo.

Adicionalmente incluye sensores de temperatura, luz y voltaje fácilmente interconectables con los

PINs del PIC.


http://www.piccircuit.com/shop/pic-code/41-tutorial-5a-4x3-keypad-demo.html%20

http://www.piccircuit.com/shop/pic-code/41-tutorial-5a-4x3-keypad-demo.html%20


Keypad y Display 7 Segmentos

Existe la posibilidad de adicionar a la placa un teclado numérico de 12 dígitos y displays de 7

segmentos. En el siguiente sitio web se encuentran diversos tutoriales inherentes a su aplicación:

http://www.piccircuit.com/shop/pic-code/41-tutorial-5a-4x3-keypad-demo.html

Fig. 19. Modulos de expansion Keypad y Display 7 segmentos en iBoard Lite

9.3. RASPBERRY PI

El Raspberry Pi es un dispositivo de un tamaño diminuto (mide casi lo mismo que una tarjeta de

crédito), pero en sus ínfimas dimensiones de 85,6 x 53,98 x 17 mm atesora grandes posibilidades,

como la reproducción de vídeo 1080p, conexión a redes e Internet y la administración de

dispositivos de demótica lo cual la torna muy versátil a la hora de pensar en sus posibles

aplicaciones. Además de sus características técnicas, Raspberry Pi es sumamente asequible en

relación a sus prestaciones, tan solo U$35 dólares.

A continuación se listan algunos de los proyectos activos mas interesantes que involucran a la

Raspberry Pi y sus fuentes de consulta:

Automatización y Monitoreo de Hogares

Proyectos que involucran la utilización de tecnologías como x10 y 1-Wire en combinación con

Raspberry Pi al servicio de la automatización y monitoreo de Hogares, principalmente orientado a

la calefacción y refrigeración de los mismos, control de iluminación, etc.

Mas información sobre proyectos activos en http://www.domoticaforum.eu/ y

http://raspberrypi.homelabs.org.uk/


http://raspberrypi.homelabs.org.uk/

http://www.domoticaforum.eu/

http://www.piccircuit.com/shop/pic-code/41-tutorial-5a-4x3-keypad-demo.html


Reproducción de Medios

Su tamaño, bajo costo y capacidad de reproducción de video y sonido de alta definición, hacen de

Raspberry Pi una alternativa muy tentadora a la hora de pensar en el mercado de media centers.

XBMC, uno de los software mas reconocidos este ámbito y con una gran comunidad de desarrollo a

lo largo del mundo, ya posee su versión compatible con Raspberry Pi y directamente booteable

desde una memoria flash.

El proyecto OpenELEC ha tomado la gran iniciativa de ofrecer soporte para el Raspberry Pi con su

distribución XBMC lista para funcionar desde memorias flash. Al usar OpenELEC la memoria

RAM se reconfigura de manera automática para dedicar el 50% a los gráficos y de esta manera

funcionar sin complicaciones (sólo un 25% del RAM se invierte en gráficos).

Si a esto le sumamos la compatibilidad de Raspberry Pi con el protocolo CEC que nos permite

controlar nuestro nuevo media center desde el control remoto de nuestro televisor, no podemos

dejar de posicionar a esta aplicación como una de las mas prometedoras.

Mas información sobre XBMC en Raspberry Pi en:

http://www.raspbmc.com/

http://wiki.openelec.tv/index.php?title=Building_and_Installing_OpenELEC_for_Raspberry_Pi

Servicios de Internet

Raspberry Pi utiliza Linux como sistema operativo y por ello puede ser fácilmente configurado para

funcionar como Web Server Apache, Proxy Server utilizando Squid, un servidor de correo

electrónico con Sendmail o Squirrel, un servidor de descargas torrent a través de Rtorrent o

Transmission y hasta utilizarse para telefonía IP con Skype o Ekiga.

Como vemos, el espectro de aplicación de Raspberry Pi tan amplio como el de una PC

convencional pero con el plus que le brinda su ínfimo tamaño y su extremadamente conveniente

costo.

9.4. FREESCALE EDUKIT08

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


http://wiki.openelec.tv/index.php?title=Building_and_Installing_OpenELEC_for_Raspberry_Pi


variedad de periféricos en un ambiente controlado que facilita el aprendizaje del estudiante del área

de microcontroladores.

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]

Es común que el estudiante de microcontroladores deba enfrentar una serie de dificultades al

comenzar con su aprendizaje, no solo en los aspectos teóricos, sino también en los prácticos,

lidiando con el manejo de herramientas de hardware, software y circuitos de aplicación específicos

de cada práctica. El sistema didáctico “EDUKIT08” facilita el acceso al mundo de los

microcontroladores al contar con un “ambiente controlado” de sus distintos periféricos, prácticas

guiadas paso a paso y herramientas sencillas e intuitivas de software. [16]

Al ser un desarrollo destinado a la educación, su simplicidad de programación y su gran versatilidad

a la hora de interactuar con el medio lo torna muy conveniente para la generación de prototipos de

prueba utilizando microcontroladores Freescale y una gran variedad de dispositivos de

entrada/salida.

Su espectro de aplicación es muy amplio y va desde la medición, registro y control de condiciones

ambientales como temperatura y luz y comando remoto de dispositivos infrarrojos y a través de

puerto serie hasta la automatización de motores DC en pequeños y medianos emprendimientos.

9.5. PC/104

PC/104 o PC104 es un estándar de ordenador embebido que define el formato de la placa base

(form factor) y el bus del sistema.

A diferencia de la clásica arquitectura ATX y bus PCI que son usados en la mayoría de los

ordenadores personales, los dispositivos PC/104 están diseñado para funcionar en ambientes

industriales donde las condiciones ambientales no son las convencionales y además son fácilmente

adaptables a cualquier aplicación a través del anexo de módulos que compatibles con el mismo

standard de interconexión.

La gran disponibilidad y variedad de módulos en el mercado permite pensar en PC/104 como

soporte de aplicaciones destinadas a control de maquinas, instrumental médico, telecomunicaciones,

equipamiento de diagnostico, manejo remoto de redes, sistemas de seguridad y sistemas de

medición garantizando un alto nivel de estabilidad frente a condiciones de operación adversas.



10. MATRIZ COMPARATIVA

A lo largo de este documento hemos efectuado un relevamiento y análisis técnico y comercial

detallado de los diversos desarrollos preseleccionados y las familias que los integran intentando

identificar sus principales virtudes y defectos a fin de categorizarlos según su potencial aplicación.

Adicional a este, se ha realizado un anexo conteniendo una matriz comparativa a fin de agilizar el

proceso de selección del desarrollo mas adecuado a las necesidades del usuario que lo requiere. Para

mas información consultar el Anexo II – Matriz Comparativa.



11. REFERENCIAS

1. Arduino, 2012. Interfacing with Other Software.

http://www.arduino.cc/playground/Main/InterfacingWithSoftware Pagina Vigente al

26/09/12.

2. Arduino, 2012. Arduino Home Page. http://arduino.cc/. Pagina Vigente al 26/09/12.

3. Arduino, 2012. Languaje Reference. http://arduino.cc/en/Reference/HomePage?

from=Reference.Extended. Pagina Vigente al 26/09/12.

4. Arduino, 2012. Serial. http://arduino.cc/en/Reference/Serial. Pagina Vigente al 26/09/12.

5. Arduino, 2012. Port Registers. http://arduino.cc/en/Reference/PortManipulation. Pagina

Vigente al 26/09/12.

6. Arduino, 2012. Libraries. http://arduino.cc/en/Reference/Libraries. Pagina Vigente al

26/09/12.

7. Arduino, 2012. Shields. http://arduino.cc/en/Main/ArduinoShields. Pagina Vigente al

26/09/12.

8. Wiring, 2012. Wiring overview. http://wiring.org.co/. Pagina Vigente al 26/09/12.

9. Atmel Corportation, 2012. ATmega328 Datasheet.

http://www.atmel.com/devices/atmega328.aspx. Pagina Vigente al 26/09/12.

10. Microchip, 2006. Microchip 8-bit PIC Microcontroller Solutions.

http://ww1.microchip.com/downloads/en/DeviceDoc/39630C.pdf. Pagina Vigente al

26/09/12.

11. Microchip, 2009. PIC16F722 Datasheet,

http://ww1.microchip.com/downloads/en/DeviceDoc/41341E.pdf. Pagina Vigente al

26/09/12.


http://arduino.cc/en/Reference/HomePage


12. Microchip, 2009. PIC16F887 Datasheet,

http://ww1.microchip.com/downloads/en/DeviceDoc/41291D.pdf. Pagina Vigente al

26/09/12.

13. iCircuit Technologies, 2010. ICP05 iBoard Lite Datasheet.

http://www.piccircuit.com/shop/doc/iCP05v1.2.pdf. Pagina Vigente al 26/09/12.

14. Edudevices, 2009. Placa Didáctica / Entrenamiento Para las flias. HC908 / HC9S08 y Serie

Flexis HC9S08 / V1 ColdFire, Revision 0.

http://www.edudevices.com.ar/download/productos/edukit/edukit/BROCHURE_EDUKIT0

8_ED.pdf. Pagina vifente al 26/09/12

15. Edudevices, 2011, Sistema Didáctico para MCUs Freescale Edukit 08.

http://www.edudevices.com.ar/productos_edukit.htm. Pagina vigente al 26/09/12

16. Freescale, 2005, 8-bit Microcontrollers (MCU) MCU 32K FLASH 10 bit ADC Datasheet.

http://www.rlocman.ru/i/File/dat/Freescale/Microcontrollers_MCU/MC908AP16CFAE.pdf.

pagina vigente al 26/09/12

17. PC/104 Consortium, 2008, Specifications, Version 2.6.

http://www.pc104.org/pc104_specs.php. Pagina vigente al 26/09/2012

18. Lippert ADLink Technology, 2012, Cool LiteRunner ECO Datasheet.

http://www.adlinktech.com/PD/marketing/Datasheet/CoolLiteRunner-

ECO/CoolLiteRunner-ECO_Datasheet_en_1.pdf. Pagina vigente al 26/09/2012

19. Lippert ADLink Technology, 2012, Cool LiteRunner LX800 Datasheet.

http://www.adlinktech.com/PD/marketing/Datasheet/CoolLiteRunner-

LX800/CoolLiteRunner-LX800_Datasheet_en_1.pdf. Pagina vigente al 26/09/2012

20. Lippert ADLink Technology, 2012, CoreModule 435 Datasheet.

http://www.adlinktech.com/PD/marketing/Datasheet/CoreModule435/CoreModule435_Dat

asheet_en_1.pdf. Pagina vigente al 26/09/2012



21. Power Lite Systems, 2012, USB Microstak Datasheet.

http://www.farnell.com/datasheets/95552.pdf. Pagina vigente al 26/09/2012

22. Raspberry Pi Foundation, 2012, Raspberry Pi Frequently asked questions.

http://www.raspberrypi.org/faqs#. Pagina vigente al 26/09/2012

23. Raspberry Pi Wiki Council, 2012, Raspberry Pi Wiki. http://elinux.org/RaspberryPiBoard.

Pagina vigente al 26/09/2012

24. Raspberry Pi Wiki Council, 2012, Raspberry Pi Hardware. http://elinux.org/RPi_Hardware.


25. Raspberry Pi Wiki Council, 2012, Raspberry Pi Low-Level Peripherals.

http://elinux.org/RPi_Low-level_peripherals. Pagina vigente al 26/09/2012

26. Raspberry Pi Wiki Council, 2012, Raspberry Pi Expansion Boards.

http://elinux.org/RPi_Expansion_Boards. Pagina vigente al 26/09/2012

27. Raspberry Pi Wiki Council, 2012, Raspberry Pi Programming.

http://elinux.org/RPi_Programming. Pagina vigente al 26/09/2012

28. ARM, 2009, ARM1176JZF-S™ Technical Reference Manual r0p7.

http://infocenter.arm.com/help/topic/com.arm.doc.ddi0301h/DDI0301H_arm1176jzfs_r0p7

_trm.pdf. Pagina vigente al 26/09/2012

29. Communications of the ACM, 2011, An interview with Steve Furber, Volume 54 Issue 5,

page 34. http://dl.acm.org/citation.cfm?doid=1941487.1941501. Pagina vigente al

26/09/2012

30. Stas Khirman, 2004, JTAG Version: 0.04. http://hri.sourceforge.net/tools/jtag_faq_org.html.


31. Shiffman, Daniel. 2009. Interview with Casey Reas and Ben Fry.


http://hri.sourceforge.net/tools/jtag_faq_org.html.%20Pagina%20vigente%20al%2026/09/2012

http://hri.sourceforge.net/tools/jtag_faq_org.html.%20Pagina%20vigente%20al%2026/09/2012


32. Wikipedia, 2012. Microcontrolador PIC.

http://es.wikipedia.org/wiki/Microcontrolador_PIC#Referencias. Pagina vigente al

26/09/2012

33. Wikipedia, 2012. Atmel AVR. http://en.wikipedia.org/wiki/Atmel_AVR. Pagina vigente al

26/09/2012

34. Wikipedia, 2012. Freescale. http://es.wikipedia.org/wiki/Freescale. Pagina vigente al

26/09/2012

35. Unmanned Industrial. Atmel AVR. http://www.unmannedindustrial.com/Atmel%20AVR.


36. Wikipedia, 2012. Arquitectura ARM. http://es.wikipedia.org/wiki/Arquitectura_ARM.


37. Wikipedia, 2012. AMD Geode. http://es.wikipedia.org/wiki/AMD_Geode. Pagina vigente al

26/09/2012

38. Wikipedia, 2012. x86. http://es.wikipedia.org/wiki/X86. Pagina vigente al 26/09/2012

39. Wikipedia, 2012. System on a Chip (SoC)http://es.wikipedia.org/wiki/System_on_a_chip.


40. Wikipedia, 2012. JTAG. http://es.wikipedia.org/wiki/JTAG. Pagina vigente al 26/09/2012


http://es.wikipedia.org/wiki/JTAG

http://es.wikipedia.org/wiki/System_on_a_chip

http://es.wikipedia.org/wiki/X86

http://es.wikipedia.org/wiki/AMD_Geode

http://es.wikipedia.org/wiki/Arquitectura_ARM

http://www.unmannedindustrial.com/Atmel%20AVR

http://es.wikipedia.org/wiki/Freescale

http://en.wikipedia.org/wiki/Atmel_AVR

http://es.wikipedia.org/wiki/Microcontrolador_PIC#Referencias

ANEXO II – MATRIZ COMPARATIVA CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.


EMBEBIDOS.




ANEXO II – MATRIZ COMPARATIVA



PIC ARM Freescale

Arduino UNO iBoard Lite Raspberry Pi B EDUKIT08

Microcontrolador

Arquitectura RISC CISC

Frecuencia 20 Mhz 16 MHz – 5 MIPS 700 MHz 8 MHz

Cache - - -

Dimensiones

Rangos de Temperatura -40°C y 85°C -40°C - 125°C - -

Rangos de Tensión 1.8V – 5.5V 3.6v – 6v 7 a 16V

Alimentación 5V USB – Fuente externa 5V USB – Fuente Externa

Consumo 30MA+ 25mA+ 700mA 3.5W -

Memoria de Programa 32Kb Flash 3.5KB Flash

Memoria de Datos 2Kb SDRAM 128 bytes RAM 256MB DDR2 2KB RAM

Registros Internos - - -

1KB EEPROM - EEPROM (24LC256)256Kb

AVR Atmel

AVR Atmega328 8bits PICs 28 PinsPIC16F722 8bits

ARM 1176JZF-S 32bitsSoC Broadcomm BCM2835 MC908AP32CFBE 8 bits

Harvard – RISC Harvard

L1 Cache 32Kb (Instr.)L2 Cache 128Kb (GPU)

2.7' x 2.1' 10cm x 5.5cm85.60mm × 53.98mm <40g 210 mm x 160 mm

6v-20v / Recom 7v-12v9V RecomendadoUSB – Fuente externa

5V USB – Fuente externa

MicroSD Slot 32 Kb Flash

32 x 8bits

Almacenamiento Pte. MicroSD Slot

Puertos E/S

Comunicación UART RS-232C/RS-485/IRDA

Módulos de expansión

Modo de programación ICSP MPLAB

*14 PINs E/S Dig Prog 5v x 40mA TTL, PWM*1 x USB*2 PINs Serial*6 PINs Ent Analogicas

ICSPDisplay LCD inIO x 8 canales8 canales analógico Servo motores x 4Mot. PaP ULN2003A

500mA Darl. x 1Mot. DC L293D x 1Conv Boost/Buck x 1

Micro USBDSI x 15-PINs HDMIVideo Composite RCAMIPI CSI-2 de 15 PINs. Audio Stereo de 3.5mmSD/MMC/SDIO2x USB 2.026-pin TTL UART GPIOARM JTAG2 x I2C 8-pin GPU JTAG7-pin LAN9512 JTAGTP1/TP2 +5V/GND

RS-485 Master / SlaveIRDA / SIRLCD 16 carac x 2 líneasLED de 4 díg x 7 seg4 pulsadoresDiodos LEDs Diodo LED de potenciaSensor Temperatura (LM335Z) Preset p/ conversor A/D I/O de propósitos gralesIRQ e interface SPI

UART TTL – Serie via USB SPI/I2C/USART/PS2/USB Ethernet 10/100Mb RJ45WiFi via Dongle USB

Arduino WIFI ShieldArduino Motor ShieldArduino Wireless SD ShieldEasyVR Arduino ShieldArduino RFID ShieldArduino Musical ShieldArduino CAN-BUS ShieldArduino MicroSD ShieldArduino USB Host ShieldArduino Screw ShieldArduino Cellular ShieldArduino GPS ShieldArduino SD ShieldArduino Photo ShieldArduino Ethernet Shield

ICM07A - 4X3 KEYPADICP01 - USB PIC PROGRAMMERICM17 - ULN2003A DRIVERCODE01 TIMER/TEMPERATURE DISPICA05 - GRAPHIC LCD DEV KITICM25 – PS/2 PORT

Heber x10i I/O USBAFLEX DC MotoresGELI 'jelly' DC MotoresaLaMode Clon ArduinoPiBorg PaP MotoresPi232 RS232 boardRelay board MiniPiio L293D H-BridgeMiniPiio DIO16 I/O DigMiniPiio RS232 Serial

*PLUGIN_APMC68HC908AP32 HC908*PLUGIN_AW MC9S08AW60 HC9S08*PLUGIN_FLX08 MC9S08AC60CFUE HC9S08 Flexis*PLUGIN_FLXCV1 MCF51AC256AVFUE ColdFire V1 Flexis CAN.*PLUGIN_FLXJM” MCF51JM128CFUE ColdFire V1 Flexis USB.

USB (Arduino Soft)ICSP MPLAB Carga externa de MicroSD

WinIDECodeWarrior 5.x/6.xICC08 de ImagecraftCosmic Compiler

PIC ARM Freescale


AVR Atmel

Lenguajes soportados Assembler, C

Programación Gráfica

Arduino (Processing)JavaFlashC#PerlPythonRuby

AssemblerCBASIC.PASCALForth

Gcc, Clojureg++InterpMono (C#)OCamlNodeJS 0.6.18 (Jscript)PerlPythonRuby 1.9.2 (KidsRuby)ScalaJavaEclipseTcl/TkLazarus(maybe) BoaConstructorAnjuta for C/C++Dev-C++CodeBlocksLuaBBC BASICJmdfs.netROOLSmall BasicSqueak (Smalltalk)Processingbasic256 bwbasicsdlbasic yabasic Regina RexxGalaxC

Pduino y Minibloq

MPLAB PICStart Plus (serie y USB)Promate II (serie)MPLAB PM3 (serie y USB)ICD2 (puerto serie y USB)ICD3 (USB)PICKit 1 (USB)IC-Prog 1.06BPICAT 1.25 (USB2.0)WinPic 800 paral/seriE/USB)PICKit 2 (USB)PICKit 3 (USB)Terusb1.0Eclipse (PICs y AVRs. USB.)MasterProg (USB)

GambasScratchAliceAndroid App InventorKoduStar LogoPrimerLabs CodeHero

WinIDECodeWarrior 5.x/6.xICC08 de ImagecraftCosmic Compiler

PIC ARM Freescale


AVR Atmel

Sistemas Operativos

Disponibilidad local SI, < 5 días hábiles NO NO SI

Costo local $ 257.81 IVA Incluido - - U$S240+IVA

Costo Internacional U$S 40 + envío 6U$S -

Tiempo de entrega ~15 días hábiles ~15 días hábiles ~15 días hábiles < 5 días hábiles

Principales virtudes

Aplicaciones posibles

Windows, Linux y MacOS Windows, Linuxm MacOS

Arch Linux ARMDebian 6.0 (Squeeze)Gentoo LinuxGoogle Chrome OSPuppy LinuxRaspberry Pi Fedora RemixRaspbian (Wheezy port)RiscOSSlackware ARM QtonPi (embedded Linux)Squeezed Arm Puppy ARMv6 IPFireOpenELECRaspbmc (Media Center)XBMC (Media Center) Windows

U$S 25 + U$S7(Envío,Imp)U$S42 Imp y Envío Incluido

MultiplataformaOpen HardwareOpen SoftwareEscalabilidadDiversidad de disp I/OAmplia documentaciónFácil ProgramaciónGran Comunidad

Dimensiones reducidasBajo costoDiversidad de disp I/OCompatibilidad PICs 28PINs

Bajo CostoDimensiones reducidasInterfaces MultMedia HDGran Comunidad

Simplicidad de programaciónAmplia documentación c/ejemSoporte técnico localComercialización localDiversidad de I/O on boardOrientación Educativa

IndustriaDocenciaServo MotoresSensores

IndustriaControl de motores DCMedición, registro y control de condiciones ambientalesMonitoreo de señalesVisualización de gráficosDispositivos de seguridad

Docencia/investigaciónAutomatización de HogaresServicios de InternetMedia CenterPC Portatil Educación

Prototipado

PIC ARM Freescale


AVR Atmel

PC/104

x86 x86 x86

8Mhz 1.1GHz – 1.6GHz 500MHz 300MHz – 800MHz

- L1 Cache 16Kb

-

- 4.75v – 5.25v 4.75v – 5.25v 4.75v – 5.25v

5V USB – Fuente Externa 5V ±5 % Fuente externa 5V ±5 % Fuente externa 5V ±5 % Fuente externa

- 11W 5W – 6W 6.5W

14Kb Flash

368 Bytes

- - - -

EEPROM 256Kb

PIC MicroStack Cool LiteRunner ECO Cool LiteRunner LX800 CoreModule 435

PICs 40 PinsPIC16F887 – 8bits

Intel Atom Z510-Z530 32bits

AMD LX800 32bits Vortex86SX - 86DX32Bits

Harvard

L1 Cache 32Kb (Instr) L2 Cache 512Kb

L1 Cache 64Kb L2 Cache 128Kb

65mm x 80mm x 16mm esp. 96mm x 90mm 96mm x 90mm 90x96mm

0°C...+60°C (comercial)-20°C...+60°C (industrial)-40°C...+85°C (extendido)

0°C...+60°C (comercial)-20°C...+60°C (industrial)-40°C...+85°C (extendido)

Standard: -20°C - +70°CExtendido: -40°C - +85°CAlmacenamiento: -55°C - +85°C

MicroSD Slot MicroSD Slot MicroSD Slot

2GB DDR2 exp. DDR400 de 256Mb 400MHz Exp RAM DDR2 de 256MB exp.

MicroSD Slot, 2 x SATAMicroSD Slot IDE UltraATA100 CompactFlashTM

MicroSD SlotPATA DMA 100 IDE x 2 HDDStorage CompactFlash socket

Microcontrolador

Arquitectura

Frecuencia

Cache -

Dimensiones

Rangos de Temperatura

Rangos de Tensión

Alimentación

Consumo

Memoria de Programa

Memoria de Datos

Registros Internos

Almacenamiento Pte.

MiniModule SIOPCM-MIO-GCualquier Modulo PC/104 Idem F Idem F Idem F

Mecanique Microcode Loader ICSP MPLAB Carga externa de MicroSD Carga externa de MicroSD Carga externa de MicroSD

UART

2 x USBPuerto PC/104 (ISA)

VGA and LVDS (c/ backlight)2 x SATA7 x USB 2.0 hostsHD AudioI/O Signals 8 GPIOMini PCI Express 1 slotISA Bus PC/104

4 x USB 2.0IDE Ultra ATA100CompactFlashTM socketMini-PCI slotCRT VGA 1920x1440 85HZTFT S/CH 18 bits 1600x1200 60HzLVDS S/CH 18/24 bits 1600x1200 60HzAudio AC97 2.1 2CHLPT bi-directional PS2 Keyboard, mouseGPIO x 8ISA Bus PC/104PCI Bus Mini-PCI slotI2C bus Supported

PC/104 ISAPATA DMA 100 IDEStorage CompactFlash socketUSB 2x USB 2.0 portsKB/MS PS/2 interface8 x GPIO digital I/O PINs1 x VGA Video Interface 100MHz/1600x768/32MB/64MBDDR2TTL/TFT D/C 12-bit S/C 18-bit

2 x Gigabit LAN2 x RS232/RS422/RS485

2x 100/10 BaseT EthernetS2 x RS232/RS422/RS4851 x RS485/Irda

1 x Ethernet 10/100 1 x Ethernet Intel 82451PI1 x Gigabit Ethernet2x RS-2322x RS-232/422/485

PC/104


Puertos E/S

Comunicación

Módulos de expansión

Modo de programación

Depende del SO Depende del SO Depende del SO

Depende del SO Depende del SO Depende del SO

AssemblerCBASIC.PASCALForth

Mecanique Microcode Loader ICSP MPLAB

PC/104


Lenguajes soportados

Programación Gráfica

SI

~U$S103 Desconocido Desconocido Desconocido

$494.00/$529.00/$713.00 $633.00/$686.00/$892.00 $792.00/$858.00/$1116.00

~15 días hábiles ~15 días hábiles ~15 días hábiles ~15 días hábiles

Windows(MPLab, MML)

XP, XP Embedded, Windows CELinuxDOS

Windows XPXP EmbeddedWin CE

Supported QNX v6.3Windows CE 5.0, 6.0

Linux, VxWorks

BAJA, Microtec BAJA, Microtec BAJA, Microtec

U$S73 + U$S20 Envio e Imp

Dimensiones ReducidasBajo CostoCompatibilidad PICs 40 PINsCompatibilidad Std PC/104Diversidad de modulos exp.Disponibilidad Local

Poder de ProcesamientoMemoria RamBajo Costo

Diversidad de Ifaces I/OBajo Consumo

Diversidad de Ifaces I/OBajo Consumo

Fuertemente IndustrialControl de maquinasInstrumental médicoTelecomunicacionesEquipamiento de diagnosticoManejo remoto de redesSistemas de seguridadSistemas de medición




PC/104


Sistemas Operativos

Disponibilidad local

Costo local

Costo Internacional

Tiempo de entrega

Principales virtudes

Aplicaciones posibles

ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.


EMBEBIDOS




ANEXO III – MODELOS DE PROCESOS PARA SISTEMAS INFORMATICOS




ANEXO III - MODELOS DE PROCESOS PARA SISTEMAS INFORMATICOS

A lo largo de este anexo se presentan y describen 3 modelos de aplicación seleccionados,

pertenecientes al ámbito de los sistemas informáticos -preferentemente embebidos- cuyo objetivo es

asistir al profesional informático en la realización de ciertas actividades contenidas en las etapas de

un proyecto. La descripción de los modelos contiene fragmentos textuales extraídos de las

publicaciones originales, ya sea en su idioma original o bien una traducción al castellano. A

continuación se mencionan los modelos a describir:

1. “Modelo de Requisitos para Sistemas Embebebidos”.

Autores: Liliana Gonzalez Palacio, German Urrego Giraldo, 2008.

2. “Goal-Oriented Patterns for UML-Based Modeling of Embedded Systems

Requirements” (Patrones Orientados a Metas para Modelado UML de

Requerimientos de Sistemas Embebidos).

Autores: Heather J. Goldsby1, Sascha Konrad, Betty H.C. Cheng,

3. “IEEE Standard for Developing Software Life Cycle Processes”.

Autor: Software Engineering Standards Committee of the IEEE Computer

Society, 2006.



1. “MODELO DE REQUISITOS PARA SISTEMAS EMBEBIDOS” DE LILIANA GONZALEZ Y GERMAN URREGO, 2008.

1.1 INTRODUCCIÓN

En la actualidad, las metodologías de ingeniería de requisitos propuestas para el dominio de los

sistemas embebidos, no establecen continuidad en su proceso de desarrollo, ya que poseen una

fuerte orientación a la etapa de diseño y un énfasis más débil en la etapa de Análisis. Por ello, a

menudo 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 a los que

les falta delimitación, lo cual 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 en el incumplimiento de los

plazos establecidos [Palacio – Giraldo, 2008].

Entre las metodologías existentes en el ámbito de los sistemas informáticos, ABC-Besoins, con el

concepto de “Intervención de agentes” 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 dichos requisitos 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 –

Giraldo, 2008].

A fin de cubrir la carencia identificada en el comienzo de esta sección, los autores de este modelo

propusieron intervenir la metodología ABC-Besoins, originalmente diseñada para el dominio de

sistemas web, adaptándola y transformándola para tener en cuenta aspectos del dominio de sistemas

embebidos, y construir un modelo conceptual que facilite la entrada a un lenguaje de especificación

[Palacio – Giraldo, 2008].

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 incorporaran los elementos propios de los sistemas

embebidos.



1.2. DESCRIPCIÓN DEL MODELO

A continuación se mencionan las categorías del modelo original ABC-Bensoins y las sub-categorías

adicionadas y que conforman el nuevo modelo ABC-Besoins-SEM:

Categorías

(Originales ABC-Besoins) Subcategorías

Disponibilidad de objetos 1. Estados

2. Eventos

Convocación y demostración 3. Interfaces

Selección de alternativas 1. Modos de Operación

2. Submodos de Operación

Interacción de agentes

• Interacciones con

súper-sistema

• Interacciones con otros

SE y el ambiente.

Acción del agente

• Funcionalidades de

entrada

• Funcionalidades de

proceso

• Funcionalidades de salida

Transferencia / Actualización Sin Subcategorías

Interrupción / Restitución /

Conservación

• Prevención de fallas

• Detección de fallas

Desempeño / Cambio Sin Subcategorias

Precio y costos • Tamaño

• Consumo de energía

Descripción o caracterización de los

agentes

1. Disponibilidad

2. Fiabilidad

3. Seguridad frente al exterior

4. Seguridad frente a ataques

5. Eficiencia Tabla 1. Categorías del modelo ABC-BENSOINS-SEM



1.2.1. CATEGORÍAS Y SUBCATEGORIAS

1.2.1.1. Disponibilidad de objetos

Son requisitos que permiten indicar la forma en que se deben comportar y comunicar los

componentes del sistema de acuerdo a los diferentes modos de operación, que se dan de acuerdo a

los valores de determinadas señales que fluyen entre procesos y entre componentes del sistema


Subcategorias:

• Estados / Eventos : Una señal comunica la ocurrencia de un evento que genera

consecuencias como un cambio de estado (Lavi et al,. 2005). Representa una condición

necesaria para que un proceso de ejecute.

1.2.1.2. Convocación y demostración

Estos requisitos tienen que ver con la comunicación que debe establecer el sistema con otros

sistemas, tales como su súper-sistema y demás sistemas embebidos que se encuentran dentro de él.

Se relacionan con las interfaces provistas para comunicarse

hacia el exterior [Palacio – Giraldo, 2008].

Subcategorias:

• Interfaces: Es importante resaltar que los sistemas embebidos usualmente no tienen una

interfaz propia con el usuario humano, sino que operan a través de una interfaz provista

por el sistema global o el súper sistema. Como consecuencia, la especificación de

requisitos de interfaz de usuario del sistema embebido será similar a la del sistema global o

contenedor. [Palacio – Giraldo, 2008]

1.2.1.3. Selección de alternativas

Son requisitos relacionados con la forma en que el sistema debe desplegar al usuario las posibles

alternativas de uso. Este tipo de requisitos da paso a los modos y submodos de operación [Palacio –

Giraldo, 2008].

Subcategorias:

• Modos de operación: Un modo de operación es un conjunto de funcionalidades del sistema

que se activan o desactivan con la ocurrencia de un evento, envío de una señal y posterior



entrada a un modo de operación. Los modos de operación típicos de un sistema embebido

son: encendido, apagado (Lavi et al., 2005).

• Submodos de operación: Pensando en jerarquía, cada modo de operación puede ser

refinado en submodos. Por ejemplo, si el sistema embebido está en modo encendido, a su

vez puede estar en uno de los siguientes submodos: en configuración, en operación normal,

en mantenimiento (Lavi et al., 2005)

1.2.1.4. Solicitud de Acceso

Descripción de la categoría: Luego de conocer las posibilidades que ofrece el sistema, el usuario

selecciona cual es la de su interés. Estos requisitos tienen entonces que ver con dicha selección, y

continuando con los modos de operación, tienen que ver con las funcionalidades que deben estar

activas por cada modo [Palacio – Giraldo, 2008].

Subcategorias: No posee

1.2.1.5 Aporte (entrada-respuesta)

Siguiendo con el proceso para el ofrecimiento y posterior selección de servicios, estos requisitos

reflejan las acciones que el usuario debe realizar para acceder a alguna de las alternativas que ofrece

el sistema. Por ejemplo, si el sistema es un cajero automático, luego de seleccionar la opción de

ingresar al sistema, el cajero pide el ingreso de una contraseña para poder continuar y desplegar

otras opciones [Palacio – Giraldo, 2008].


1.2.1.6. Verificación / Decisión

Posterior al aporte del usuario para obtener el servicio o funcionalidad requerida, el sistema hace

verificaciones internas y continúa con el proceso para la prestación del servicio o la activación de la

funcionalidad [Palacio – Giraldo, 2008].


1.2.1.7. Interacción de Agentes

Estos requisitos, al igual que los denominados “Acción del agente”, hacen parte de los más

conocidos como “requisitos funcionales”. De manera general, un requisito funcional indica cuales



son las funciones que debe proveer el sistema a los agentes que lo usan, incluyendo como agentes

los otros sistemas con los que debe interactuar.

Aunque los sistemas embebidos están más orientados a la acción que a la interacción, existen

relaciones que se establecen con los sistemas interactuantes y que aportan al cumplimiento de la

función general del súper-sistema [Palacio – Giraldo, 2008].

Subcategorias:

• Interrelaciones con Súper-Sistema: Aquí solo se detallan las funciones que permiten la

interacción del sistema embebido y el súper-sistema.

• Interrelación con otros sistemas embebidos y el ambiente: Como ya se mencionó en las

características propias de los sistemas embebidos, la presencia de jerarquía permite que

cada sistema embebido incluido en un súper-sistema tenga asignada una función

específica, que aporta al logro de una función general. En esta subcategoría se tendrán en

cuenta las interrelaciones con los sistemas embebidos incluidos dentro del súper-sistema y

la comunicación con el ambiente [Palacio – Giraldo, 2008].

1.2.1.8. Acción del Agente

Estos requisitos también hacen parte de los “requisitos funcionales”, pero no se ocupan de las

interacciones, sino de las funcionalidades y servicios que debe proveer el sistema para cumplir con

su propósito específico dentro del súper-sistema (Fuentes y Zúñiga, 2003) [Palacio – Giraldo,

2008].

Subcategorias:

• Funcionalidades de entrada: Para determinar estas funcionalidades es preciso observar

el sistema embebido como una caja negra, y analizar cuales son las entradas que debe

recibir, tanto del súper-sistema, como de los otros sistemas embebidos, para comenzar

su funcionamiento [Palacio – Giraldo, 2008].

• Funcionalidades de proceso: En este punto es preciso observar el sistema embebido

como una caja blanca, para encontrar las funciones que debe proveer y lograr las salidas

que se conectarán con otros sistemas. Entre las funciones típicas de proceso en un

sistema embebido se cuentan: iniciación, configuración, diagnóstico, almacenamiento,

terminación [Palacio – Giraldo, 2008].



• Funcionalidades de salida: Al igual que las funcionalidades de entrada, para esta

subcategoría se observa el sistema como una caja negra y se determina que debe

entregar a los demás sistemas para cumplir con su función específica [Palacio –

Giraldo, 2008].

1.2.1.9. Transferencia / Actualización

Son requisitos que reflejan cambios o actualizaciones a realizar luego de que el usuario lleve a cabo

determinada acción.


1.2.1.10 Interrupción/ restitución/ conservación

Son requisitos relacionados con la reacción del sistema ante errores y fallos, por lo tanto es la forma

de convertir en funcional un requisito como la fiabilidad del sistema [Palacio – Giraldo, 2008].

Subcategorias:

• Prevención de fallas: Estos requisitos expresan características que deben ser incluidas

para minimizar las posibilidades de error del sistema antes de su entrada en

funcionamiento. Por ejemplo, es importante incorporar componentes hardware fiables,

y usar metodologías de especificación y diseño rigurosas [Palacio – Giraldo, 2008].

• Detección de fallas: A pesar de definir características para evitar que ocurran fallas,

éstas pueden ocurrir, y es preciso tener mecanismos que permitan determinar cuando el

sistema entró en un estado de error y que acciones se deben emprender para

recuperarse. La incorporación de facilidades de auto chequeo y el uso de módulos del

sistema redundantes son ejemplos. La inclusión de planes de contingencia también

aumenta la tolerancia ante fallas, esto implica identificar las funciones críticas del

sistema, y por cada función determinar las posibles fallas que puedan ocurrir, y por

último, indicar posibles soluciones ante cada falla. Es importante hacer énfasis en estos

requisitos, si se tiene en cuenta que será el propio sistema embebido el que se recupere,

teniendo en cuenta que tiene poca interacción con el usuario humano [Palacio –

Giraldo, 2008].



1.2.1.11 Desempeño / Cambio

Estos requisitos permiten incluir formas de optimizar tiempos para realizar una operación.


1.2.1.12 Precio y Costos

Las principales características que determinan el precio de un sistema embebido son: su tamaño y el

consumo de energía, factores que pueden sacar a un competidor del mercado, por lo cual, es preciso

hallar un punto de equilibrio entre lo que cuestan las componentes a incluir y su ventaja frente a

tamaño y consumo de energía [Palacio – Giraldo, 2008].

Sub-categorías:

• Tamaño: Son requisitos que indican cual debe ser el tamaño de las componentes del

sistema. La mayoría de los sistemas embebidos deben ser fáciles de transportar por el

usuario y además, hacen parte de dispositivos que deben ser en esencia pequeños (por

ejemplo, teléfonos celulares, PDA). Los diseñadores deben tener especial cuidado con

los componentes que seleccionan [Palacio – Giraldo, 2008].

• Consumo de Energía: El consumo de energía es una de las características que indica el

grado de portabilidad de un sistema embebido, y también depende de los componentes

que el diseñador escoja a la hora de construir e implementar el sistema embebido


1.2.1.13 Descripción y caracterización de los agentes

Son requisitos no funcionales que definen propiedades emergentes del sistema, tales como

disponibilidad, eficiencia, seguridad, confiabilidad. Pueden especificar también la utilización de una

herramienta particular, un lenguaje de programación o un método de desarrollo

durante la construcción del sistema. En los sistemas embebidos pueden ser más críticos que los

requisitos funcionales [Palacio – Giraldo, 2008].

Subcategorias:

• Disponibilidad: Requisitos que manifiestan la necesidad de que un sistema, en un punto

del tiempo, sea operativo y capaz de ofrecer los servicios requeridos por los usuarios

(Humanes et al., 2004).



• Fiabilidad: Requisitos creados para garantizar que el sistema ejecute sus

funcionalidades libre de fallos en un tiempo especificado y en un ambiente determinado

(Humanes et al., 2004). Para cumplir con estos requisitos puede ser necesario

especificar requisitos adicionales relacionados con la gestión de fallas .

• Seguridad frente al exterior: Requisitos relacionados con aquellos atributos que debe

tener el sistema para operar sin provocar daños en el ambiente y sin entorpecer las

funciones de los demás sistemas con los cuales interactúa [Palacio – Giraldo, 2008].

• Seguridad frente a ataques: Requisitos orientados a evitar ataques externos que pongan

en peligro las funcionalidades del sistema, o que permitan comportamientos como:

Denegación de servicio (que pone en peligro la disponibilidad), corrupción de

programas o datos manejados por el sistema (lo cual puede afectar el comportamiento

del sistema y, por tanto, la fiabilidad y la seguridad), revelación de información

manejada por el sistema. Si no se garantiza este tipo de seguridad, el sistema puede ser

corrompido y puede comportarse de una forma inesperada [Palacio – Giraldo, 2008].

• Eficiencia: Requisitos que permiten lograr un efecto determinado optimizando los

recursos disponibles.



2. “GOAL-ORIENTED PATTERNS FOR UML-BASED MODELING OF EMBEDDED SYSTEMS REQUIREMENTS” (PATRONES ORIENTADOS A METAS PARA MODELADO UML DE REQUERIMIENTOS DE SISTEMAS EMBEBIDOS) DE HEATHER J. GOLDSBY1, SASCHA KONRAD, BETTY H.C. CHENG,

2.1. INTRODUCCIÓN

Los sistemas embebidos son utilizados en aplicaciones criticas que deben ajustarse a diversas

restricciones de seguridad. Sus desarrolladores, 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 y (3) analizar los modelos de requerimientos de

comportamiento en adhesión a las restricciones planteadas [Heather et al, 2007].

Si bien existen diversos enfoques que proveen patrones que relacionan modelos basados en metas

con modelos UML, ninguno de ellos logra abordar los requerimientos funcionales del sistema y por

ello no son capaces de asistir a los desarrolladores a determinar formalmente si el comportamiento

especificado por el modelo UML satisface los requerimientos funcionales de un sistema embebido.

A fin de cubrir esta carencia y sobrepasar los retos planteados al inicio de esta sección, este

desarrollo introduce patrones COBRA que proveen plantillas de modelos UML y modelos basados

en Metas, implementables en conjunto para crear modelos 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 relacionan 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 sistema es capturada utilizando diagramas de clase UMLy el Comportamiento mediante

diagramas de estado UML. (3) La consistencia estructural y de comportamiento es establecida entre

los modelos UML y basado 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 requerimientos tardíos

[Heather et al, 2007].

2.2. NOTACIÓN DEL MODELO BASADO EN METAS

Se utiliza el enfoque de requerimientos no funcionales para especificar la plantilla de modelos

orientados a metas. En general, las metas son objetivos del sistema y los modelos orientados a

metas las especifican y describen sus relaciones. Los modelos orientados a metas habilitan a los

desarrolladores a evaluar soluciones alternativas y documentar la racionalidad detrás de los

requerimientos, es decir, describen por que existen los requerimientos. Los patrones COBRA

contienen cuatro tipos de metas con sus respectiva representación gráfica [Heather et al, 2007];


Softgoal

SoftgoalOperationalization

Functional Goal

Se representa mediante una nube sombreada y describe una técnica de desarrollo o una artefacto que contribuye al éxito de un softgoal. En este caso, se utiliza para relacionar softgoals con requerimientos tardíos.

Se representa mediante una nube y describe objetivos no funcionales cuyo cumplimiento no puede ser siempre evaluado formalmente, por ejemplo, la reusabilidad o calidad.

Se representa mediante un rectángulo de bordes redondeados y describe un objetivo funcional que el sistema puede alcanzar, por ejemplo, le detección de una falla.

139


Existen 2 tipos de relaciones entre las metas o goals anteriormente descriptas, estas son,

Contribution Relationship y Refinement Relationship y se describen a continuación..

1 Contribution Relationship; representada mediante una flecha con la palabra “helps” o ”hurts”, si

el elemento origen ayuda o perjudica la realización del Softgoal destino respectivamente


2 Refinement Relationship; representada mediante una flecha con la palabra “AND” u ”OR”,

establece la dependencia exclusiva o no de diversos sub-goals para con la realización de un

Softgoal jerárquicamente superior. Una meta o goal posee una relación AND si y solo si todas

sus sub-metas deben ser alcanzadas para ella también serlo mientras que es OR si solo alguna de

las sub-metas deben ser alcanzadas para que ella alcance su propósito [Heather et al, 2007].

Dentro de los patrones CORBA, los softgoals operationalization contribuyen al alcance de los

softgoal. Adicionalmente, los softgoals son refinados por los functional goals, los cuales a su vez

son refinados por los constraint goals [Heather et al, 2007].


Functional Goal

OR/AND

helps/hurts

Se representa mediante un rectángulo de bordes redondeados sombreado y describe un objetivo funcional que el sistema puede verificar mediante un análisis formal.

140


2.3. ANÁLISIS DEL COMPORTAMIENTO

Después de instanciar un patrón COBRA, es necesario validar la consistencia del comportamiento

en los modelos UML y orientados a Metas mediante una herramienta llamada SPIN Model Checker.

Esta herramienta verifica que el modelo UML contemple las restricciones especificadas en el

modelo orientado a metas. Antes de utilizar SPIN, es necesario traducir los modelos orientados a

metas y UML a una representación formal. Se utiliza la herramienta Hydra para traducir los

modelos UML y Spider (Specification Pattern Instantiation and Derivation EnviRonment) para los

orientados a Metas [Heather et al, 2007].

2.4. PATRONES COBRA

En la Tabla 2 se observa un catalogo de patrones COBRA indicando su clasificación (estructural o

funcional), una breve descripción del mismo, su meta funcional primaria y como algunos de los

requerimientos no funcionales clave del sistema embebido como el rendimiento, adaptabilidad y

reusabilidad son afectados por el mismo [Heather et al, 2007].

Los patrones clasificados como estructurales contienen plantillas UML enfocadas en la

identificación de objetos, abstracción de objetos en clases y la captura de relaciones entre clases

mientras que los patrones funcionales contienen plantillas UML que especifican el comportamiento

de los objetos/clases mediante la definición del comportamiento esencial de los objetos reactivos.

En las columnas de los requerimientos no funcionales, los signos menos (-) y más (+) indican si un

patrón dado ayuda o perjudica un requerimiento establecido. Si el campo esta en blanco, el impacto

del patrón sobre el Soft-goal no es significante [Heather et al, 2007].



Tabla 2. Evaluación de Patrones Cobra

2.5. PLANTILLAS COBRA

La plantilla de patrones esta dividida en 4 secciones. La primera sección describe el nombre y

clasificación del patrón (estructural o de comportamiento). Las secciones correspondientes a la

ingeniería de requerimientos tempranos (2) y tardíos (3) incluyen campos adaptados a las

respectivas fases del ciclo de vida de desarrollo de software. La sección de ingeniería temprana de

requerimientos incluye una plantilla correspondiente al modelo orientado a metas mientras que la

sección de ingeniería tardía de requerimientos incluye un diagrama de clases UML estructural y un

diagrama de estado y secuencia para el modelado del comportamiento. La cuarta y última sección

Meta-Data Patterns identifica los patrones COBRA y de diseño y su utilización [Heather et al,

2007].

A continuación se describe la plantilla de patrones CORBA en detalle.

1. Nombre del Patrón y Clasificación

1.1. Componente computacional: Patrón de Comportamiento

2. Ingeniería de Requerimientos temprana


Nombre Meta Funcional Principal NFR

Ren

dim

ient

o

Ada

ptab

ilida

d

Reu

sabi

lidad

Sensor Activo Estructural + - +

Sensor Pasivo Estructural - + +

Actuador Estructural +

Control Estructural + - +

Estructural +

Indicador Estructural + - +

Operativo - +

Operativo Distribuir tareas computacionales - +

Corrector Operativo Corregir fallas - + -

Detector Operativo Detectar fallas - + -

Gestor de Fallas Operativo - + -

Clasificacion Descripcion

Ase

quib

ilida

d

Especifica diversos tipos de sensores activos y sus relaciones con el componente computacional

Monitoreo del entorno, envio de informacion

Especifica diversos tipos de sensores pasivos y sus relaciones con el componente computacional

Monitoreo del entorno, Requiere explicita solicitud de Informacion

Especifica diversos tipos de actuadores y sus relaciones con el componente computacional

Influencia del entorno mediantela configuracion de un valoren el actuador

Describe como modelar los controles de una interface de usuario a fin de adquirir valores de entrada

Recepcion de informaciondel usuario

ControlDescomposicion

Una vision global de las relaciones de los componentesen el sistema

Descomposicion del sistema enComponentes

Describe como modelar los indicadores de una interface de usuario a fin de señalozar el estado actual al usuario Proveer informacion al usuario

Comunicacion Especifica como debe interactuar el sistema con entidades externas como dispositivos de diagnostico

Interactuar con entidades externascomo dispositivos de diagnostico

Componente Computacional

Especifica diversos modos operativos del componentecomputacional de un sistema embebidoDescribe como pueden ser incluidas capacidades decorreccion de fallas en el sistemaDescribe como pueden ser incluidas capacidades dedeteccion de fallas en el sistema

Describe como modelar gestores globales y localesa fin de proveer un mayor nivel de abstraccion Gestion centralizada de fallas

142


2.1. Motivación

Este patrón se encarga de lo componentes computacionales usualmente

llamados controladores de un sistema embebido. Estos componentes tienen

la tarea de realizar los cómputos necesarios e interactuar con el entorno

mediante sensores y actuadores. En un sistema embebido distribuido, en

contraste con uno centralizado, existen numerosos componentes que

interactúan entre mediante el intercambio de mensajes [Heather et al,

2007].

Los componentes computacionales usualmente tienen diversos modos de

operación. Por ejemplo en un sistema distribuido de control de vuelo de un

aeroplano, ningún componente debería apagarse completamente sino entrar

en un modo de apagado parcial ofreciendo la posibilidad de ejecutar

funciones básicas necesarias para operar el avión. Generalmente,

dependiendo de la gravedad de la falla, un componente computacional

podría cambiar su modo de operación actual luego de la detección de la

misma [Heather et al, 2007].

.

2.2. Aplicabilidad

El Patrón de Componente Computacional es aplicable para el modelado de

componentes computacionales en sistemas embebidos centralizados y

distribuidos[Heather et al, 2007].

2.3. Plantilla del Modelo orientado a Metas

La Figura 2 representa la plantilla del Modelo orientado a Metas para el

Patrón de Componente Computacional. Se utilizan círculos con letras para

etiquetar los elementos del diagrama y así facilitar su descripción. El

Patrón de Componente Computacional perjudica (A) la asequibilidad

debido a que redundancia de hardware y/o software podría ser requerida en

algunos modos de operación pero a su vez contribuye a la reusabilidad

porque numerosos componentes computacionales podrían ser construidos

utilizando variantes del mismo modelo[Heather et al, 2007].

El Softgoal operationalization, por ejemplo las metas C-H, restringen la

estructura de la instanciación de la plantilla del modelo UML.

Las metas funcionales (I) Initialize components, (J) Change operational

mode y (K), alcanzan la meta operacional y especifican los requerimientos



funcionales que deberían ser satisfechos por el patrón. Además, son

refinadas al tipo AND por Constraint Goals como (L), que describen una

propiedad especifica y analizable, que instancias de la plantilla del modelo

UML para componentes computacionales deberían satisfacer. Estos

Constraint Goals son especificados utilizando lenguajes naturales

estructurados que permiten al desarrollador utilizar la herramienta Spider

para traducirlos a una forma de representación [Heather et al, 2007].

Nota: Instanciar una plantilla de modelo orientado a metas tiene 2 pasos.

Primero, cada meta en la plantilla es adaptada remplazando el valor

genérico subrayado con la información especifica relativa al sistema

embebido en desarrollo. La plantilla puede ser adicionalmente adaptada

añadiendo softgoals adicionales relevantes para el sistema. Estos softgoals

podrían refinar a los existentes o introducir nuevos requisitos no

funcionales.

Segundo, la plantilla instanciada del modelo orientado a metas es

incorporada dentro de la totalidad del modelo orientado a metas para el

sistema embebido estableciendo una relación de refinamiento o

contribución entre la nomenclatura del softgoal y la instancia del patrón.

Por ejemplo, (D) y un softgoal en el modelo de metas del sistema [Heather

et al, 2007].

3. Ingeniería de Requerimientos tardía

3.1. Estructural

El diagrama de clases UML del patrón Componente Computacional puede

ser observado en la Figura 3. En un sistema distribuido, un Componente

Computacional se comunica con otros de su tipo mediante el intercambio

de mensajes mientras que en un sistema centralizado solo existe un

Componente Computacional. Adicionalmente, un Componente

Computacional puede interactuar con una Interface de usuario a fin de

proveer información al usuario acerca de el estado actual de operación así

como recibir entradas [Heather et al, 2007].

Nota: Un desarrollador instancia este diagrama para construir clases

concretas que heredan de las clases abstractas presentadas en el diagrama.



3.2. Comportamientos

Los siguientes modos de operación son provistos por el Componente

Computacional. Cada modo de operación es representado como un estado


3.2.1. Apagado

Estado que precede a la activación del Componente Computacional

3.2.2. Inicialización

En este estado se produce la inicialización del Componente

Computacional en el cual, por ejemplo, se revisa el estado de todos

los componentes.

3.2.3. Comportamiento normal

Estado en el cual no han ocurrido fallas y el Componente

Computacional funciona normalmente.

3.2.4. Control Manual/Externo

En este estado el Componente Computacional es operado por una

entidad externa como un dispositivo de diagnóstico.

3.2.5. Parada de Producción

Cesa la operación inmediatamente pero no corta la alimentación.

Este estado es apropiado cuando un Componente Computacional

necesita ser detenido pero un dispositivo debería continuar

operando para evitar situaciones riesgosas. Por ejemplo, la

refrigeración de un dispositivo debería continuar incluso ante un

caso de un mal funcionamiento del sistema.

3.2.6. Parada de Protección

Este estado es útil por ejemplo cuando un humano ingresa en un

área peligrosa. El Componente Computacional debería ser capaz de

completar su tarea actual y asegurar el entorno pero a su vez

apagarse lo antes posible.



3.2.7. Apagado Parcial

Es un estado en el cual el Componente Computacional ofrece solo

funcionalidades básicas; Por ejemplo, en dispositivos médicos debe

permanecer en un estado de monitoreo.

3.2.8. Suspensión

Ninguna funcionalidad es prevista en este estado aunque se realizan

acciones seguras como por ejemplo, la auto destrucción de un

cohete en caso de funcionamiento inesperado. La única manera de

salir de este estado es mediante el reinicio completo del sistema.

3.3. Participantes

Los participantes son el Componente Computacional y la Interface de Usuario.

3.4. Colaboraciones

3.4.1. Componente Computacional

Efectúa las operaciones necesarias e interactúa con el entorno.

3.4.2. Interface de Usuario

Es utilizada para indicar al usuario el estado actual del sistema.

Esta información es importante para que el usuario este al tanto de

que el sistema esta funcionando en un modo seguro.

Adicionalmente el usuario puede provee entradas al sistema

mediante este dispositivo.

3.5. Consecuencias

3.5.1. Los modos operacionales seguros requeridos deben ser

implementados los Componentes Computacionales.

3.5..2. Redundancia de Hardware y Software podría ser requerida para

algunos modos de operación, incrementando el costo del sistema.



4. Patrón Meta-Data

4.1. Patrones de Diseño aplicables

Strategy pattern [10], Double

Checked Locking pattern [32], Acceptor-Connector pattern [32]

4.2. Alias

A determinar.

4.3. Usos probables

A determinar.

4.4. Patrones COBRA relacionados:

Detector, Corrector, Fault Handler, Indicator.

2.6. ANÁLISIS DE CONSISTENCIA EN LA CONSTRUCCIÓN.

Es necesario establecer una consistencia entre los modelos UML y basados en Metas. La

consistencia estructural es establecida mediante la construcción de diagramas UML relacionando

elementos del modelo basado en Metas mientras que la consistencia de comportamiento, es

alcanzada mediante el Análisis de los modelos UML en consideración de las restricciones

especificadas en el modelo basado en Metas [Heather et al, 2007].

2.6.1. Consistencia estructural por construcción.

La consistencia estructural identifica las clases/objetos cuyo comportamiento está limitado por la

aplicación del patrón y se establece durante la construcción de la meta y los modelos UML. En

concreto, la consistencia estructural crea una relación explícita entre los softgoals

operationalization de la instanciación de una plantilla de modelo orientado a metas y elementos

correspondientes a la instanciación de la plantilla del modelo UML. Hay cuatro tipos de softgoal

operationalization y cada uno proporciona información cada vez más concreta acerca de la creación

de instancias de la plantilla de diagrama de clases [Heather et al, 2007]. Pueden observarse los tipos

de softgoal operationalization referentes a los elementos genéricos definidos por la plantilla del

modelo Componente Computacional en la Figura 2:



Fig. 2. Plantilla del modelo orientado a metas para el patrón Componente Computacional

El nombre del patrón es identificado a un cierto nivel de abstracción, por ejemplo Patrón de Componente

Computacional

El contexto es provisto mediante la nomenclatura de la instancia del patrón, por ejemplo, Componente Computacional

N.

Los Softgoal operationalization identifican los componentes de la plantilla del diagrama de clases UML. Por ejemplo

(E) Clase abstracta del Componente Computacional y (F) La clase abstracta de la interface de usuario identifica las

clases abstractas definidas por la plantilla de diagrama de clases UML para este patrón como puede observarse en la

Figura 3.

Los softgoal operationalization identifican las clases que deben ser usadas para instanciar las plantillas de diagrama de

clases UML. Por ejemplo, (G) Componente Computacional Concreto y (H) Interface de Usuario Concreta, nombren

las clases concretas construidas para instanciar la plantilla de diagrama de clases UML para un Componente

Computacional especifico.

Notas Fig. 2.

La consistencia estructural provee a los desarrolladores una guía para el mantenimiento de ambos

modelos. Si una meta restrictiva dentro de la instancia de una plantilla de un modelo orientado a

metas es modificada, las relaciones de consistencia estructural indicaran aquellos elementos del

diagrama de clases UML cuyos diagramas de estado potencialmente necesitaran ser modificados



para satisfacer la restricción. De igual manera, si un diagrama de estado de una clase UML es

modificado, las relaciones de consistencia estructural indicaran las metas que deberían ser

modificadas [Heather et al, 2007].

2.6.2. Consistencia en el comportamiento mediante análisis.

La consistencia en el comportamiento es establecida mediante un Análisis formal. Específicamente

el modelo UML resultante de la instanciación de los patrones COBRA es analizado en considerando

las metas restrictivas. El Análisis tiene tres pasos: (1) Utilizando la herramienta Hydra se traduce el

modelo UML a una representación formal capaz de ser analizada con la herramienta de revisión de

modelos Spin. (2) Utilizando la herramienta Spider, las metas restrictivas son traducidas a una

representación formal mediante la instanciación de todos. (2) El modelo formalizado UML es

analizado considerando la meta restrictiva declarada. Cualquier error que sea detectado debe ser

corregido antes de aplicar otro patrón. Para determinar la fuente de un error, se puede utilizar la

herramienta Violation Trace provista en Spin o bien revisar el modelo original UML con la

herramienta Theseus. Si estas herramientas arrojaran como resultado que el comportamiento es

valido entonces la propiedad especificada por la meta restrictiva es errónea y debe ser modificada.

En casos donde un comportamiento erróneo es detectado, el modelo UML debe ser corregido antes

de aplicar otro patrón que incorpore mas detalles al modelo [Heather et al, 2007].

3. STANDARD IEEE 1074-2006 PARA EL DESARROLLO DE PROCESOS DE CICLO DE VIDA DE SOFTWARE

3.1. INTRODUCCIÓN

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].

3.2. DESCRIPCIÓN GENERAL DEL MODELO

El standard se encuentra estructurado en torno a procesos y subprocesos los cuales a su vez

contienen actividades a llevar a cabo utilizando Técnicas sugeridas. El trabajo realizado a lo largo

de cada etapa se ve reflejado en diversos documentos de salida que brindan un marco profesional y

controlado a la actividad. A continuación se describen los procesos, sub-procesos y actividades

asociadas al standard.

1. Procesos de Gestión del Proyecto

1.1. Sub-proceso de iniciación del proyecto

1.2. Sub-proceso de Planificación del proyecto

1.3. Sub-proceso de Monitoreo y Control

2. Proceso de Pre-Desarrollo

2.1. Sub-proceso de Exploración de Conceptos

2.2.Sub-proceso de Asignación del Sistema

2.3. Sub-proceso de Importación de Software

3. Proceso de Desarrollo

3.1. Sub-proceso de requisitos

3.2. Sub-proceso de Diseño

3.3. Sub-proceso de implementación

4. Proceso de Post-Desarrollo

4.1. Sub-proceso de instalación

4.2. Sub-proceso de operación y soporte

4.3. Sub-proceso de mantenimiento

4.4. Sub-proceso de retiro

5. Procesos Integrales del Proyecto

5.1. Subproceso de Evaluación

5.2. Sub-proceso de gestión de la configuración

5.3. Sub-proceso de desarrollo de Documentación

5.4. Sub-proceso de Formación



3.3. DESCRIPCIÓN DETALLADA DE SUBPROCESOS

A continuación se detallan los procesos y sub-procesos presentados anteriormente, las actividades

que los componen y se incluye un conjunto de técnicas sugeridas y documentación de salida,

propuestos en la guía de estudio “Ciclo de Vida de Software, Proceso Software y Plan de

Actividades" [García Martínez, 2009].

1. Procesos de Gestión del Proyecto

1.1. Sub-proceso de iniciación del proyecto

Actividades:

1.1.1. Seleccionar un modelo de Ciclo de Vida

1.1.2. Realizar Estimaciones

1.1.3. Asignar Recursos

1.1.4. Definir Métricas

1.1.5. Determinar objetivos de Seguridad


▪ Modelo de Ciclo de Vida Seleccionado

▪ Estimaciones del Proyecto

▪ Asignación de Recursos

▪ Métricas Definidas y Métodos de Análisis y Captura de las mismas

▪ Especificación de Objetivos de Seguridad


▪ Análisis de camino critico

▪ Análisis PERT

▪ Diagrama de Gantt

▪ Técnicas estadísticas

▪ Técnicas de Simulación (Metodo Montecarlo)

▪ Modelos empíricos de estimación de esfuerzo del Software(COCOMO,

PUTNAM)

1.2. 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

▪ 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


▪ Plan de Evaluación

▪ Plan de Gestión de la Configuraciones

▪ Plan de Transición e Informa 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

1.3. 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


▪ Reporte de Riesgos

▪ Reporte de Gestión del Proyecto

▪ Reporte de necesidades de mejora en el Ciclo de Vida

▪ Registro Histórico de Proyectos

▪ Reporte de Métricas

▪ Información necesaria para el archivo del Proyecto al momento de su cierre


▪ Análisis de riesgo técnico



◦ Modelización y Simulación Estática y Dinámica

◦ Prototipado

◦ Revisiones

◦ Auditorías

▪ Análisis de riesgo económico

▪ Análisis de finanzas

▪ 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

2. Proceso de Pre-Desarrollo

2.1. 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.


▪ Informe preliminar de necesidades

▪ Informe de Soluciones potenciales. Beneficios y Limitaciones

▪ Informe de Viabilidad

▪ Informe de Necesidades


▪ Técnicas de Adquisición de Conocimientos.

▪ Análisis Económico (Coste/Beneficio).

▪ Análisis Técnico.

▪ Análisis Alternativos.

▪ Técnicas de Modelización.

▪ Diagramas de Flujos de Datos (DFD).

▪ Prototipado.



2.2. Sub-proceso de Asignación del Sistema

Actividades:

▪ Analizar las funciones del sistema.

▪ Desarrollar la arquitectura del sistema.

▪ Asignar los requisitos del Sistema


▪ Descripción Funcional del Sistema

▪ Arquitectura del Sistema y Requerimientos de Seguridad

▪ Requerimientos Humanos y de Hardware del Sistema

▪ Requerimientos Funcionales del Sistema

▪ Requerimientos de Interfaces del Sistema


▪ Técnicas de Adquisición de Conocimientos.

▪ Técnicas de Modelización.

▪ Diagramas de Flujo de Datos (DFD).

2.3. Sub-proceso de Importación de Actividades

Actividades:

▪ Identificar Requerimientos de software importados

▪ Evaluar fuentes de software importado

▪ Definir método de importación de software

▪ Importar software


▪ Especificación de requerimientos de software importados

▪ Fuentes del software importados

▪ Métodos candidatos para la importación del software

▪ Método seleccionado para la importación del software

▪ Software Importados

▪ Documentación del Software Importados

3. Proceso de Desarrollo

3.1. Sub-proceso de requisitos

Actividades:

▪ Definir y desarrollar los requisitos del software

▪ Definir los requisitos de interfaz



▪ Integrar los requisitos del software


▪ Informe preliminar de requisitos del sistema

▪ Especificación de requisitos de interfaces

▪ Especificación de requerimientos del sistema



◦ 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

◦ Diagramas de descomposición

▪ WRS Working Breackdown Structure

▪ RBS Resource Breakdown Structure

▪ OBS Object Breakdown Structure

◦ Actigramas o Diagramas de Actividades

• Técnicas formales de especificación

◦ Técnicas relacionales

▪ Ecuaciones implícitas

▪ Relaciones recurrentes

▪ Axiomas algebraicos

▪ Expresiones regulares

◦ Técnicas orientadas al estado

▪ Tablas de decisión

▪ Tablas de eventos

▪ Tablas de transición

▪ Mecanismos de estados finitos

▪ Redes de Petri

• Técnicas de prototipado

3.2. Sub-proceso de Diseño

Actividades:

▪ Realizar el diseño arquitectónico



▪ Realizar el diseño de la base de datos (si aplica)

▪ Diseñar las interfaces

▪ Realizar el diseño detallado


▪ Diseño arquitectónico

▪ Diseño de la base de datos

▪ Diseño de las interfaces

▪ Diseño detallado



◦ Diseño estructurados Análisis de transformación

◦ Análisis de transacción

◦ Patrones COBRA para modelos UML y basados en Metas.

▪ Diseño del dialogo de los interfaces

◦ Diseño lógico o diseño del perfil

◦ HIPO (Hierarchy Input Process Output)

◦ Patrones COBRA para modelos UML y basados en Metas.

▪ Técnicas Orientadas a los datos

◦ Modelo lógico de datos

◦ Modelo físico de datos

◦ Warnier

◦ Jackson

▪ Técnicas orientadas a los objetos

◦ Modelo de clases/objetos

◦ Diagrama de módulos

▪ Técnicas de diseño de bajo nivel

◦ Programación estructurada

▪ Diagramas arborescentes

▪ Diagramas de Chapin

◦ Programación orientada a objetos

◦ Warnier

◦ Jackson



▪ Técnicas de prototipado

▪ Técnicas de refinamiento

3.3. Sub-proceso de Implementación

Actividades:

• Crear el código fuente

• Crear la Documentación operacional

• Realizar la integración

• Gestionar las versiones del Software


• Codigo fuente

• Software Ejecutable

• Base de datos

• Documentación operacional

• Software integrado

• Paquete del producto lanzado


• Warnier

• Jackson

• Lenguajes de programación

• Entorno de Programación del hardware seleccionado

4. Proceso de Post-Desarrollo

4.1. Sub-proceso de instalación

Actividades:

• Distribuir el Software

• Instalar el software

• Aceptar el software en el ambiente operativo


• Reporte de Instalación del Software

• Informe de aceptación del software por parte del usuario

4.3. 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


• Registro de Operaciones

• Registro de Anomalías

• Registro de Peticiones de Soporte

4.4. Sub-proceso de mantenimiento

Actividades:

• Identificación de necesidades de mejora del Software

• Verificación del método de reporte de problemas

• Iteración del Ciclo de Vida


• Sugerencia de mejoras al software

• Reporte de anomalías

• Reporte de corrección de anomalías

• Recomendaciones de Mantenimiento

4.5. Sub-proceso de retiro

Actividades:

• Notificar al usuario

• Conducir operaciones en paralelo (si aplica)

• Retirar el sistema


• Notificación oficial al usuario

• Registro de operaciones en paralelo

• Reporte de revisión Post-Operacion

5. Procesos Integrales del Proyecto

5.1. Subproceso de Verificación y validación

Actividades:

• Revisión de Conducta

• Crear Matriz de Trazabilidad

• Conducir Auditorias

• Desarrollar Procedimientos de prueba

• Crear datos de prueba



• Ejecutar pruebas

• Reportar Resultados de la evaluación

• Confirmar Acreditación de Seguridad


• Resultados de revisión en-proceso

• Reporte de revisión Post-implementación

• 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

• Sumario de Pruebas

• Reporte de Evaluación


• 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

5.2. 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


• Reporte de Identificación de la Configuración

5.3. Sub-proceso de desarrollo de Documentación

Actividades:

• Implementar la Documentación

• Producir y Distribuir la Documentación


• Documentación publicada

5.4. Sub-proceso de Formación

Actividades:

• Desarrollar los materiales de formación

• Validar el programa de formación

• Implementar el programa de formación


• Manual de entrenamiento

• Materiales de entrenamiento



4. 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.

Fuentes, A, Hardings, J, Zuñiga, M. (2003). Software libre en sistemas embebidos. Seminario de software libre.

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.

Heather J. Goldsby1, Sascha Konrad, Betty H.C. Cheng. Goal-Oriented Patterns for UML-Based Modeling of

Embedded Systems Requirements (Patrones Orientados a Metas para Modelado UML de

Requerimientos de Sistemas Embebidos)

Humanes, D, López, J, Robles, I, Sánchez, C. (2004). Sistemas Críticos. Ingeniería Técnica en Informática de

Gestión. Escuela Politécnica. Universidad de Alcalá de Henares. España.

IEEE (2013) Software Engineering Standards Committee of the IEEE Computer Society (1990). URL

http://www.ieee.org.ar/. 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. 272.

Lavi, J, Kudish, J. (2005). Systems modelling & requirements specification using ECSAM: an analysis method for

embedded & computer-based systems”. Innovations Syst Softw Eng. 1: 100– 115

Liliana Gonzalez Palacio, German Urrego Giraldo, 2008. Modelo de Requisitos para Sistemas Embebebidos.

Peláez, J (2013). El desarrollo de Software. http://desarrollodesoftware-jorgepelaez.blogspot.com.ar/2013/03/2-el-

desarrollo-de-software.html. Sitio vigente 11/2013

Ross, D, Schoman, K. (1977). Structured Analysis for Requirements Definition. Transactions on Software

Engineering, IEEE, 3(1): 6-15.

Software Engineering Standards Committee of the IEEE Computer Society, 2006. IEEE Standard for Developing

Software Life Cycle Processes.




ANEXO IV – DOCUMENTOS DEL PROYECTO CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS


EMBEBIDOS




ANEXO IV – DOCUMENTOS DEL PROYECTO




Robot para Automatización de Tareas de Invernadero

Plan de Inicialización del Proyecto

Versión 1.0

Autor: Jonatan Ponzo

Lanzamiento: Septiembre 2013



Histórico de Modificaciones

Fecha Descripción del cambio

12/01/13 Creación del Documento



Tabla de Contenidos

1. Introducción

2. Selección de un Modelo de Ciclo de Vida

3. Creación del Ciclo de Vida del Proyecto y Mapa de Actividades-Documentos

4. Organización de las Actividades en Secuencia de Ejecución

5. Mapa de Documentos y Actividades-Documento

6. Apéndices/Anexos

Apéndice A: Mapa de Actividades

Apéndice B: Secuencia de Actividades

Apéndice C: Mapa de Documentos y Actividades



1. Introducción

A lo largo de este documento se desarrolla y presenta la estructura de procesos y actividades que

determinan la conformación de la columna vertebral del proyecto que busca garantizar la

conclusión efectiva y eficiente del mismo.

Las 4 fases que definen la estructura general del proyecto son las siguientes:


2. Creación del Ciclo de Vida del Proyecto y Mapa de Actividades

3. Organización de las Actividades Secuencia de Ejecución

4. Mapa de Documentos y Actividades


Iniciamos el Proyecto con el proceso de selección de un Modelo de Ciclo de Vida acorde a las

etapas y actividades que se presumen necesarias para la realización exitosa del mismo.

Hemos seleccionado un Modelo de Ciclo de Vida “Simple Evolutivo”. Sus etapas y actividades se

presentan a continuación:

1 Planificación

1.1 Identificar la misión del proyecto

1.2 Identificar los recursos

1.3 Identificar métricas de calidad

1.4 Planificar el Proyecto

2 Análisis y Diseño

2.1 Definir objetivos

2.2 Definir requisitos y requerimientos

2.3 Diseñar el Sistema

3 Implementación y Prueba

3.1 Desarrollar componentes

3.2 Integrar e implementar el Sistema

3.3 Verificación y Validación



4 Garantía de Calidad

4.1 Conducir revisiones y determinar mejoras en el Producto

4.2 Planificar el Mantenimiento

4.3 Conducir auditorías y determinar mejoras en los Procesos

4.4 Implementar Documentación

4.5 Cerrar el proyecto

3. Creación del Ciclo de Vida del Proyecto y Mapa de Actividades.

Seleccionado y presentado el Modelo de Ciclo de Vida procedemos a la elaboración de un Mapa de

Actividades conteniendo la asignación de las actividades propuestas por el Modelo Integral de

Gestión de Proyectos destinados al control de Robots Autónomos Móviles basados en Arquitecturas

de Sistemas Embebidos propuesto y foco de esta Prueba de Concepto, a las fases propuestas en el

Modelo de Ciclo de Vida seleccionado. En el Mapa de Actividades, el cual puede encontrarse en el

apéndice A a continuación, se pueden además observar las actividades desestimadas y su

correspondiente justificación.

4. Organización de Actividades en secuencia de ejecución

Definido el Mapa de Actividades, se deben organizan las mismas 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. El mismo puede observarse en el apéndice B.

5. Mapa de Documentación y Actividades

Organizadas las actividades en torno a una secuencia de ejecución, solo resta establecer la

participación de cada actividad en la conformación de los documentos a producir a lo largo del

proyecto. Para ello se desarrolla un Mapa de Documentación que relaciona todas las actividades

previstas con los documentos a producir. El mismo puede encontrarse en el apéndice C.

Para continuar con el flujo de la Prueba de Concepto, dirigirse a los documentos generados a lo

largo del Ciclo de Vida del proyecto y referenciados como fue anteriormente mencionado, en el

Mapa de Documentación.



Apéndice A. Mapa de Actividades




MAPA DE ACTIVIDADES

PL

AN

IFIC

AC

IÓN

AN

ÁL

ISIS

Y D

ISE

ÑO

IMP

LE

ME

NT

AC

IÓN

Y P

RU

EB

A

GA

RA

NT

IA D

E C

AL

IDA

D

A.1A.1.1 Sub-proceso de Iniciación del proyectoA.1.1.1 XA.1.1.2 XA.1.1.3 XA.1.1.4 XA.1.1.5 Determinar objetivos de Seguridad XA.1.1.6 Entendimiento del Negocio XA.1,2 Sub-proceso de Planificación del proyectoA.1.2.1 XA.1.2.2 XA.1.2.3 NA NA NA NAA.1.2.4 XA.1.2.5 XA.1.2.6 NA NA NA NAA.1.2.7 XA.1.2.8 XA.1.2.9 Planificación de la Gestión del Lanzamiento XA.1.2.10 Planificación del Mantenimiento X XA.1.2.11 Planificación del Retiro XA.1.3 Sub-proceso de Seguimiento y Control del ProyectoA.1.3.1 XA.1.3.2 XA.1.3.3 XA.1.3.4 XA.1.3.5 XA.1.3.6 XA.2A.2.1 Sub-proceso de Exploración de ConceptosA.2.1.1 Identificar ideas o necesidades. XA.2.1.2 XA.2.1.3 XA.2.1.4 Refinar y Finalizar la idea o necesidad. XA.2.2 Sub-proceso de Asignación del SistemaA.2.2.1 Analizar las funciones del sistema. XA.2.2.2 Desarrollar la arquitectura del sistema. XA.2.2.3 Asignar los requisitos del Sistema XA.3 Proceso de DesarrolloA.3.1 Sub-proceso de RequisitosA.3.1.1 Definir y desarrollar los requisitos del hardware XA.3.1.2 Definir y desarrollar los requisitos del interfaces XA.3.1.3 Definir los requisitos del entorno XA.3.1.4 Definir los requisitos de software XA.3.1.5 Integrar los requisitos XA.3.2 Sub-proceso de DiseñoA.3.2.1 Realizar el diseño arquitectónico XA.3.2.2 Realizar el diseño de la base de datos (si aplica) NA NA NA NAA.3.2.3 Selección de la Arquitectura de Hardware mas conveniente. XA.3.2.4 Diseñar las interfaces X

Proceso de Gestion del Proyecto

Seleccionar un modelo de Ciclo de Vida Realizar Estimaciones Asignar Recursos Definir Métricas

Planificación de la Evaluación Planificación de la Gestión de la ConfiguraciónPlanificación de la Transición (si se requiere)Planificación de la InstalaciónPlanificación de la Documentación Planificación del EntrenamientoPlanificación de la Gestión del Proyecto. Planificación de la Integración

Gestión de RiesgosGestión del ProyectoIdentificación de Mejoras al Ciclo de VidaAlmacenamiento de RegistrosRecopilación y Análisis de MétricasCierre del ProyectoProceso de Desarrollo Pre-Desarrollo

Formular soluciones potenciales.Conducir estudios de viabilidad.

175



MAPA DE ACTIVIDADES

PLA

NIF

ICA

CIÓ

N

AN

ÁLI

SIS

Y D

ISE

ÑO

IMP

LEM

EN

TA

CIÓ

N Y

PR

UE

BA

GA

RA

NT

IA D

E C

ALI

DA

D

A.4.2 Sub-proceso de operación y soporteA.4.2.1 Operar el sistema XA.4.2.2 Proveer de asistencia técnica y consultas XA.4.2.3 Mantener el histórico de peticiones de soporte XA.4.3 Sub-proceso de mantenimientoA.4.3.1 Identificación de necesidades de mejora del Software XA.4.3.2 Identificación de necesidades de mejora del Hardware y Entorno Configurable XA.4.3.3 Implementación de un método de reporte de problemas XA.4.3.4 Iteración del Ciclo de Vida XA.4.4 Sub-proceso de retiroA.4.4.1 Notificar al usuario NA NA NA NAA.4.4.2 Conducir operaciones en paralelo (si aplica) NA NA NA NAA.4.4.3 Retirar el sistema NA NA NA NAA.5 Procesos Integrales del ProyectoA.5.1 Subproceso de Verificación y ValidaciónA.5.1.1 Conducir Revisiones X X X XA.5.1.2 Crear Matriz de Trazabilidad XA.5.1.3 Conducir Auditorías XA.5.1.4 Desarrollar Procedimientos de prueba XA.5.1.5 Crear datos de prueba XA.5.1.6 Ejecutar pruebas XA.5.1.7 Reportar Resultados de la evaluación XA.5.1.8 Confirmar Acreditación de Seguridad XA.5.2 Sub-proceso de gestión de la configuraciónA.5.2.1 Realizar la identificación de la configuración XA.5.2.2 Realizar el control de la configuración XA.5.2.3 Realizar la información del estado de la configuración XA.5.3 Sub-proceso de desarrollo de DocumentaciónA.5.3.1 Implementar la Documentación XA.5.3.2 Producir y Distribuir la Documentación XA.5.4 Sub-proceso de FormaciónA.5.4.1 Desarrollar los materiales de formación NA NA NA NAA.5.4.2 Validar el programa de formación NA NA NA NAA.5.4.3 Implementar el programa de formación NA NA NA NAA.3.3 Sub-proceso de ImplementaciónA.3.3.1 Configurar e integrar el hardware y las interfaces físicas XA.3.3.2 Crear el código fuente XA.3.3.3 Crear la Documentación operacional XA.3.3.4 Realizar la integración XA.3.3.5 Gestionar las versiones del Software XA.4 Proceso de Post-Desarrollo

176



JUSTIFICACION DE ACTIVIDADES NO REALIZADASA.1.2.3 No se presenta una transiciónA.3.2.2 Realizar el diseño de la base de datos (si aplica) No se utilizara una base de datosA.4.4.2 Conducir operaciones en paralelo (si aplica) No se prevén actividades en paraleloA.1.2.11 Planificación del Retiro No se prevé el retiro del sistemaA.4.4.3 Retirar el sistema No se prevé el retiro del sistemaA.4.4.1 Notificar al usuario No se prevé el retiro del sistemaA.5.4.1 Desarrollar los materiales de formación No son necesarias actividades de formaciónA.5.4.2 Validar el programa de formación No son necesarias actividades de formaciónA.5.4.3 Implementar el programa de formación No son necesarias actividades de formación

Planificación de la Transición (si se requiere)

177


Apéndice B. Secuencia de Actividades




Fase del Ciclo de Vida Actividad del ModeloPLANIFICACION

A.1.1.6 Entendimiento del NegocioA.1.1.1A.1.1.2

Identificar los Recursos A.1.1.3A.1.1.4

Planificar el Proyecto A.1.3.1A.1.1.5 Determinar objetivos de Seguridad A.4.3.3 Implementación de un método de reporte de problemasA.1.2.7A.1.2.4A.1.2.8A.1.2.1A.1.2.9 Planificación de la Gestión del LanzamientoA.1.2.2A.1.2.10A.1.2.5A.5.1.1 Conducir Revisiones

ANÁLISIS Y DISEÑODefinir Objetivos A.2.1.1 Identificar ideas o necesidades.

A.2.1.2A.2.1.3A.2.1.4 Refinar y Finalizar la idea o necesidad.

Definir Requisitos y Requerimientos A.2.2.1 Analizar las funciones del sistema.A.2.2.2 Desarrollar la arquitectura del sistema.A.2.2.3 Asignar los requerimientos del SistemaA.3.1.1 Definir y desarrollar los requisitos del hardware A.3.1.2 Definir y desarrollar los requisitos del Interfaces A.3.2.3 Selección de la Arquitectura de Hardware mas conveniente. A.3.1.3 Definir los requisitos del entornoA.3.1.4 Definir los requisitos de softwareA.3.1.5 Integrar los requisitos

Diseñar el Sistema A.3.2.1 Realizar el diseño arquitectónicoA.3.2.4 Diseñar las interfacesA.3.2.5 Realizar el diseño detalladoA.5.1.1 Conducir Revisiones

IMPLEMENTACIÓN Y PRUEBADesarrollar Componentes A.3.3.2 Crear el código fuente

A.3.3.5 Gestionar las versiones del SoftwareA.3.3.1 Configurar e integrar el hardware y las interfaces físicas

Integrar e implementar el Sistema A.3.3.4 Realizar la integraciónA.4.1.1 Ajustar parámetros del entornoA.4.1.2 Configurar y adaptar interfaces con el entorno productivo

y otros sistemasA.3.3.3 Crear la Documentación operativaA.4.2.1 Operar el sistemaA.4.2.2 Proveer de asistencia técnica y consultasA.4.2.3 Mantener el histórico de peticiones de soporteA.5.1.4 Desarrollar Procedimientos de pruebaA.5.1.2 Crear Matriz de TrazabilidadA.5.1.5 Crear datos de pruebaA.5.1.6 Ejecutar pruebasA.1.3.4A.5.1.7 Reportar Resultados de la evaluaciónA.4.1.3 Aceptar el producto en el ambiente operativoA.5.1.1 Conducir Revisiones

Identificar la misión del proyectoSeleccionar un modelo de Ciclo de Vida Realizar Estimaciones Asignar Recursos

Identificar Metricas de Calidad Definir Métricas Gestión de Riesgos

Planificación de la Gestión del Proyecto. Planificación de la InstalaciónPlanificación de la IntegraciónPlanificación de la Evaluación

Planificación de la Gestión de la ConfiguraciónPlanificación del MantenimientoPlanificación de la Documentación


Verificacion y Validacion

Almacenamiento de Registros

181



GARANTIA DE CALIDADConducir revisiones y determinar A.5.2.1 Desarrollar la identificación de la configuraciónmejoras en el producto A.5.2.2 Realizar el control de la configuración

A.5.2.3 Realizar la información del estado de la configuraciónA.5.1.1 Conducir RevisionesA.4.3.1 Identificación de necesidades de mejora del SoftwareA.4.3.2 Identificación de necesidades de mejora del Hardware y Entorno A.5.1.8 Confirmar Acreditación de SeguridadA.1.2.10 Planificación del Mantenimiento

mejoras en los procesos A.1.3.5A.1.3.3A.5.1.3 Conducir Auditorías

Implementar Documentación A.5.3.1 Implementar la DocumentaciónA.5.3.2 Producir y Distribuir la Documentación

Cerrar el Proyecto A.4.3.4 Iteración del Ciclo de VidaA.1.3.6

Planificar el MantenimientoConducir Auditorias y determinar

Recopilación y Análisis de MétricasIdentificación de Mejoras al Ciclo de Vida

Cierre del Proyecto

Fase del Ciclo de Vida Actividad del Modelo

182


Apéndice C. Mapa de Documentos y Actividades


Salida del Proceso Documento GeneradoA.1.1.6 Entendimiento del Negocio Propuesta, Alcances y Objetivos Plan de ProyectoA.1.1.1 Ciclo de vida Seleccionado Plan de Proyecto

Mapa de Actividades Plan de ProyectoLista de actividades no utilizadas Plan de ProyectoMapa de Documentos Plan de Proyecto

A.1.1.2 Estimaciones del Proyecto Plan de ProyectoA.1.1.3 Asignación de Recursos Plan de ProyectoA.1.1.4 Definición de Métricas Plan de ProyectoA.1.3.1 Especificación de Riesgos Plan de ProyectoA.1.1.5 Determinar objetivos de Seguridad Especificación de Objetivos de Seguridad Plan de ProyectoA.4.3.3 Implementación de un método de reporte de problemas Método de Reporte de Problemas Plan de ProyectoA.1.2.7 Plan de Gestión del Proyecto Plan de ProyectoA.1.2.4 Plan de Instalación Plan de ProyectoA.1.2.8 Plan de Integración Plan de ProyectoA.1.2.1 Plan de Evaluación Plan de ProyectoA.1.2.9 Planificación de la Gestión del Lanzamiento Plan de Gestión del Lanzamiento Plan de ProyectoA.1.2.2 Plan de Gestión del la Configuración Plan de ProyectoA.1.2.10 Plan de Mantenimiento Plan de ProyectoA.1.2.5 Plan de Documentación Plan de ProyectoA.2.1.1 Identificar ideas o necesidades. Informe Preliminar de Necesidades Especificación de RequisitosA.2.1.2 Informe Preliminar de Soluciones Potenciales Especificación de RequisitosA.2.1.3 Informe de Viabilidad Especificación de RequisitosA.2.1.4 Refinar y Finalizar la idea o necesidad. Descripción de Idea o Necesidad Especificación de RequisitosA.2.2.1 Analizar las funciones del sistema. Descripción de Funciones del Sistema Especificación de RequisitosA.2.2.2 Desarrollar la arquitectura del sistema. Descripción de Arquitectura del Sistema Especificación de RequisitosA.2.2.3 Asignar los requerimientos del Sistema Asignación de requerimientos Especificación de RequisitosA.3.1.1 Definir y desarrollar los requisitos del hardware Informe de requerimientos de Software Especificación de RequisitosA.3.1.2 Definir y desarrollar los requisitos del interfaces Informe de requerimientos de Hardware Especificación de RequisitosA.3.1.3 Definir los requisitos del entorno Informe de requerimientos de Entorno Especificación de RequisitosA.3.2.3 Selección de la Arquitectura de Hardware mas conveniente. Especificación de Hardware Especificación de RequisitosA.3.1.4 Definir los requisitos de software Informe de requerimientos de Interfaz Especificación de RequisitosA.3.1.5 Integrar los requisitos Informe de Integración de los requerimientos Especificación de RequisitosA.3.2.1 Realizar el diseño arquitectónico Diseño Arquitectónico Especificación de DiseñoA.3.2.4 Diseñar las interfaces Diseño de Interfaces Especificación de DiseñoA.3.2.5 Realizar el diseño detallado Diseño detallado Especificación de DiseñoA.3.3.2 Crear el código fuente Código ejecutableA.3.3.5 Gestionar las versiones del Software Control de Versiones del SoftwareA.3.3.1 Configurar e integrar el hardware y las interfaces físicas Hardware IntegradoA.3.3.4 Realizar la integración Software y Hardware Integrado

Actividad

Seleccionar un modelo de Ciclo de Vida

Realizar Estimaciones Asignar Recursos Definir Métricas Gestión de Riesgos

Planificación de la Gestión del Proyecto. Planificación de la InstalaciónPlanificación de la IntegraciónPlanificación de la Evaluación

Planificación de la Gestión de la ConfiguraciónPlanificación del MantenimientoPlanificación de la Documentación


A.4.1.1 Ajustar parámetros del entorno Reporte de Instalación y operación del SistemaA.4.1.2 Configurar y adaptar interfaces con el entorno productivo y otros sistemas Reporte de Instalación y operación del SistemaA.3.3.3 Crear la Documentación operativa Instrucciones de operación Manual de OperacionesA.4.2.1 Operar el sistema Reporte de Instalación y operación del SistemaA.4.2.2 Proveer de asistencia técnica y consultas Reporte de Instalación y operación del SistemaA.4.2.3 Mantener el histórico de peticiones de soporte Reporte Histórico de Peticiones de Soporte Reporte de Instalación y operación del SistemaA.5.1.4 Desarrollar Procedimientos de prueba Procedimientos de Prueba Reporte de Evaluación del SistemaA.5.1.2 Crear Matriz de Trazabilidad Matriz de Trazabilidad Reporte de Evaluación del SistemaA.5.1.5 Crear datos de prueba Datos de Prueba Reporte de Evaluación del SistemaA.5.1.6 Ejecutar pruebas Reporte de Evaluación del SistemaA.1.3.4 Reporte de Evaluación del SistemaA.5.1.7 Reportar Resultados de la evaluación Informe de Resultados de Prueba Reporte de Evaluación del SistemaA.4.1.3 Aceptar el producto en el ambiente operativo Robot Instalado Reporte de Evaluación del SistemaA.5.2.1 Desarrollar la identificación de la configuración Informe de Estado de la ConfiguraciónA.5.2.2 Realizar el control de la configuración Informe de Estado de la ConfiguraciónA.5.2.3 Realizar la información del estado de la configuración Reporte del estado de la configuración Informe de Estado de la ConfiguraciónA.5.1.1 Conducir Revisiones Informe de revisión del proceso Informe de Garantía de CalidadA.4.3.1 Identificación de necesidades de mejora del Software Necesidades de Mejora del Software Informe de Garantía de CalidadA.4.3.2 Identificación de necesidades de mejora del Hardware y Entorno Configurable (EC)Necesidades de Mejora del Hardware y EC Informe de Garantía de CalidadA.5.1.8 Confirmar Acreditación de Seguridad Verificación de Objetivos de Seguridad Informe de Garantía de CalidadA.1.3.3 Recomendaciones de mejora en los procesos Informe de Garantía de CalidadA.1.3.5 Informe de Garantía de CalidadA.5.1.3 Conducir Auditorías Resultados de la auditoría Informe de Garantía de CalidadA.5.3.1 Implementar la Documentación Documentación

Almacenamiento de Registros

Identificación de Mejoras al Ciclo de VidaRecopilación y Análisis de Métricas

Actividad Salida del Proceso Documento Generado



Plan de Proyecto

Versión 1.0








23/02/13 Planificación del Mantenimiento

24/02/13 Actualización de Objetivos de Seguridad



Tabla de Contenidos

1. Generalidades del Proyecto

1.1 Sumario del Proyecto

1.1.1. Descripción del Negocio

1.1.2. Propósito, Alcance y Objetivos

1.1.3. Supuestos y Limitaciones

1.1.4. Entregables

1.1.5. Reporte de Problemas

1.2 Estimaciones

1.3 Recursos

1.4 Riesgos

1.5 Métricas

1.6 Objetivos de Seguridad

2. Plan de Integración

3. Plan de Evaluación

4. Plan de Instalación

5. Plan de Gestión de la Configuración

6. Plan de Mantenimiento

7. Plan de Documentación

8. Plan de Gestión de Lanzamiento


Apéndice A - Planillas



1. Generalidades del Proyecto

En esta sección se describen los las características generales del proyecto y el negocio.

1.1 Sumario del Proyecto

1.1.1 Descripción del Negocio

El trabajo en invernaderos 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,

implican un movimiento en el interior del invernadero, por lo cual disponer de un vehículo con

capacidad autónoma de desplazamiento sería de real utilidad y conveniencia1.

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 resta al monto de dinero obtenido por ventas, del monto gastado o invertido en

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 en este caso, y © personal

capaz de llevar a cabo las tareas de siembra, mantenimiento y recolección del producto.

La implementación de un robot autónomo móvil en este entorno, podría suponer el remplazo de un

alto porcentaje de los recursos humanos requeridos para las tareas de siembra, mantenimiento y

1 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.



recolección del producto, lo cual no solo implicaría una disminución notable en los costos por

reducción de salarios sino también la de los tiempos de operación con la capacidad que esto

conlleva de permitir un aumento en el volumen de producción y un incremento en los niveles de

control sobre los procesos utilizados que permite implementar procesos de mejora continua de la

calidad de los productos elaborados.

1.1.2 Propósito, Alcance y Objetivos

El propósito de este proyecto es la planificación, construcción y mantenimiento de un Robot

Autónomo Móvil destinado a la automatización de tareas de invernadero requeridas por el cliente.

Todas las actividades directamente relacionadas con el propósito son consideradas dentro del

alcance del proyecto.

Los Objetivos del Proyecto son los siguientes:

• Culminar exitosamente el proyecto dentro del plazo de tiempo estimado.

• Culminar exitosamente el proyecto haciendo uso de los recursos asignados.

• Proveer la totalidad de los entregables supuestos en la sección 1.1.4

• Entregar un producto correctamente construido y que satisfaga las necesidades planteadas

por el cliente.

1.1.3 Supuestos y Limitaciones

El proyecto es planificado en torno a los siguientes supuestos y limitaciones:

• Este proyecto se encuadra en la etapa de Prueba de Concepto del Trabajo Final de

Licenciatura en Sistemas que propone un modelo de gestión integral de proyectos destinados

al control de robots autónomos móviles basados en Arquitecturas de Sistemas Embebidos.

• Por el supuesto anterior, el proyecto contara solo con 1 recurso humano no remunerado

encargado de llevar a cabo todas las tareas del proyecto, incluso las inherentes al cliente.

• Por tratarse de una prueba de concepto y no un requerimiento real por parte del cliente, no se

cuenta con un entorno productivo (un invernadero) y la validación y verificación se llevaran

a cabo en un entorno de prueba desarrollado para la ocasión. El sistema a desarrollar es un

prototipo.

• No se cuenta con un registro histórico de proyectos.



1.1.4 Entregables

Los ítems mencionados a continuación son entregados como resultado de este proyecto.

• Robot Autónomo Móvil para tareas de Invernadero (prototipo)

• Código Fuente y Librerías utilizadas

• Manual de operaciones del Robot. Especificación de Hardware y Diagrama de Ensamblado

1.1.5 Reporte de Problemas

A fin de proceder satisfactoriamente y mantener un registro apropiado ante la ocurrencia de

problemas de cualquier índole y origen surgidos a lo largo del proyecto se implementa una Planilla

de Reporte y Registro de Problemas. La misma puede sen encontrado en el Apéndice I – Planillas.

Sus resultados serán evaluados durante la etapa de Aseguramiento de la Calidad.

1.2 Estimaciones

En esta sección se supone la estimación del esfuerzo y costo necesario para la realización de los

procesos y actividades involucradas en el Ciclo de Vida del Proyecto.

El esfuerzo se obtiene de la estimación expresada en cantidad de horas necesarias para llevar a cabo

una actividad, realizada por los recursos humanos encargados de las mismas. El costo surge de la

multiplicación del esfuerzo estimado y el valor en pesos argentinos de la hora de trabajo del recurso

humano.

Como fue mencionado en la sección 1.1.3, el proyecto cuenta únicamente con 1 recurso humano y

el mismo no es remunerado por lo cual se desestima el calculo de costos asociados al mismo.

No se cuenta con un registro histórico de proyectos que faciliten el proceso de estimación.

Se genera un cuadro de estimación que se puede observar en la Figura 1, en el cual se listan las

fases y actividades del ciclo de vida del proyecto y la estimaciones del tiempo requerido para la

realización de cada uno de ellas.



Fig. 1.a) Cuadro de Estimaciones


Actividad

Dur

ació

n (H

S)

Cos

to (

AR

S$)

Rec

urso

PLANIFICACIONA.1.1.6 Entendimiento del Negocio 4 $0,00A.1.1.1 16 $0,00A.1.1.2 1 $0,00A.1.1.3 1 $0,00A.1.1.4 1 $0,00A.1.3.1 1 $0,00A.1.1.5 Determinar objetivos de Seguridad 1 $0,00A.4.3.3 Implementación de un método de reporte de problemas 1 $0,00A.1.2.7 2 $0,00A.1.2.4 1 $0,00A.1.2.8 1 $0,00A.1.2.1 1 $0,00A.1.2.9 Planificación de la Gestión del Lanzamiento 1 $0,00A.1.2.2 1 $0,00A.1.2.10 1 $0,00A.1.2.5 1 $0,00A.5.1.1 Conducir Revisiones 1 $0,00ANÁLISIS Y DISEÑOA.2.1.1 Identificar ideas o necesidades. 1 $0,00A.2.1.2 1 $0,00A.2.1.3 1 $0,00A.2.1.4 Refinar y Finalizar la idea o necesidad. 1 $0,00A.2.2.1 Analizar las funciones del sistema. 1 $0,00A.2.2.2 Desarrollar la arquitectura del sistema. 4 $0,00A.2.2.3 Asignar los requerimientos del Sistema 1 $0,00A.3.1.1 Definir y desarrollar los requisitos del hardware 8 $0,00A.3.1.2 Definir y desarrollar los requisitos del Interfaces 4 $0,00A.3.2.3 Selección de la Arquitectura de Hardware mas conveniente. 4 $0,00A.3.1.3 Definir los requisitos del entorno 4 $0,00A.3.1.4 Definir los requisitos de software 4 $0,00A.3.1.5 Integrar los requisitos 16 $0,00A.3.2.1 Realizar el diseño arquitectónico 2 $0,00A.3.2.4 Diseñar las interfaces 2 $0,00A.3.2.5 Realizar el diseño detallado 16 $0,00

ponzojSeleccionar un modelo de Ciclo de Vida ponzojRealizar Estimaciones ponzojAsignar Recursos ponzojDefinir Métricas ponzojGestión de Riesgos ponzoj

ponzojponzoj

Planificación de la Gestión del Proyecto. ponzojPlanificación de la Instalación ponzojPlanificación de la Integración ponzojPlanificación de la Evaluación ponzoj

ponzojPlanificación de la Gestión de la Configuración ponzojPlanificación del Mantenimiento ponzojPlanificación de la Documentación ponzoj

ponzoj

ponzojFormular soluciones potenciales. ponzojConducir estudios de viabilidad. ponzoj

ponzojponzojponzojponzojponzojponzojponzojponzojponzojponzojponzojponzojponzoj

196


Fig. 1.b) Cuadro de Estimaciones

Estimado el tiempo necesario para cada actividad y teniendo en cuenta que solo se cuenta con 1

recurso humano, estaríamos en condiciones de establecer un Diagrama Gantt a fin de ubicar las

actividades y su prolongación temporal en el calendario y así poder estimar una posible fecha de

finalización del proyecto. Sin embargo, la disponibilidad variable del recurso humano quita

cualquier sentido a la aplicación de esta técnica. Se fija como meta de finalización del proyecto el


IMPLEMENTACION Y PRUEBAA.3.3.2 Crear el código fuente 16 $0,00A.3.3.5 Gestionar las versiones del Software 1 $0,00A.3.3.1 Configurar e integrar el hardware y las interfaces físicas 8 $0,00A.3.3.4 Realizar la integración 2 $0,00A.4.1.1 Ajustar parámetros del entorno 1 $0,00A.4.1.2 Configurar y adaptar interfaces con el entorno productivo 1 $0,00

y otros sistemas 1 $0,00A.3.3.3 Crear la Documentación operativa 2 $0,00A.4.2.1 Operar el sistema 2 $0,00A.4.2.2 Proveer de asistencia técnica y consultas 4 $0,00A.4.2.3 Mantener el histórico de peticiones de soporte 2 $0,00A.5.1.4 Desarrollar Procedimientos de prueba 1 $0,00A.5.1.2 Crear Matriz de Trazabilidad 8 $0,00A.5.1.5 Crear datos de prueba 1 $0,00A.5.1.6 Ejecutar pruebas 1 $0,00A.1.3.4 2 $0,00A.5.1.7 Reportar Resultados de la evaluación 1 $0,00A.4.1.3 Aceptar el producto en el ambiente operativo 5 $0,00A.5.1.1 Conducir Revisiones 2 $0,00GARANTIA DE CALIDADA.5.2.1 Desarrollar la identificación de la configuración 1 $0,00A.5.2.2 Realizar el control de la configuración 1 $0,00A.5.2.3 Realizar la información del estado de la configuración 1 $0,00A.4.3.1 Identificación de necesidades de mejora del Software 1 $0,00A.4.3.2 Identificación de necesidades de mejora del Hardware y Entorno 1 $0,00A.5.1.8 Confirmar Acreditación de Seguridad 2 $0,00A.1.2.10 Planificación del Mantenimiento 1 $0,00A.5.1.1 Conducir Revisiones 1 $0,00A.1.3.5 1 $0,00A.1.3.3 2 $0,00A.5.1.3 Conducir Auditorías 8 $0,00A.5.3.1 Implementar la Documentación 1 $0,00A.5.3.2 Producir y Distribuir la Documentación 4 $0,00A.4.3.4 Iteración del Ciclo de Vida 1 $0,00A.1.3.6 195

Recurso$0,00 195

ponzojponzojponzojponzojponzojponzojponzojponzojponzojponzojponzojponzojponzojponzojponzoj

Almacenamiento de Registros ponzojponzojponzojponzoj

ponzojponzojponzojponzojponzojponzojponzojponzoj

Recopilación y Análisis de Métricas ponzojIdentificación de Mejoras al Ciclo de Vida ponzoj

ponzojponzojponzojponzoj

Cierre del Proyecto

Descripcion $/Hs Hs Asignadasponzoj Jonatan Matias Ponzo

197


día 16 de Febrero de 2013.

1.3 Recursos

Además del tiempo y costo de asociado al trabajo realizado por los recursos humanos, existen

costos asociados a los recursos materiales necesarios para llevar a cabo el proyecto. A continuación

se realiza la estimación correspondiente.

En lo que respecta a los recursos humanos requeridos por el proyecto, si bien fue expresado en

secciones anteriores que se cuenta con tan solo 1 recurso, a continuación se listan los roles que el

mismo deberá tomar a lo largo del proyecto y la carga de tiempo requerida por cada uno de ellos.


Rol Horas CantidadLíder de Proyecto 70 1Analista de Requerimientos 36 1Técnico Electrónico 16 1Arquitecto de Software 20 1Programador 17 1Instalador 12 1Verificador 19 1

190

Recurso Descripción Costo

Kit ROBOT N6 V1.1 $1.700,002 Sensores IR, 2 Sensores Ultrasonido (Provisto por la Universidad)

2 Sensores IR $64,00

$60,00

Cables y Conectores Cables y Conectores necesarios $20,00

PC/Laptop Necesaria para la generación del código $0,00fuente y la integración del mismo con (Provisto por el Desarrollador)el hardware

Entorno de Prueba Materiales necesarios para el montaje $100,00de un entorno de prueba.

Sensor de Temperatura Componente electrónico para el sensado $50,00y Humedad de Temperatura y Humedad

Kit Arduino, Carcaza, 2 Motores

Sensores IR para deteccion de marcas

1 Modulo MicroSD Arduino Modulo Lecto-Grabador de tarjetas micro SD

198


El proyecto cuenta con un Robot Múltiplo N6 (Duinobot v1.2) provisto por la UNLa. El mismo

contiene los actuadores necesarios, 2 sensores infrarrojos para el sensado de linea, y un sensor

ultrasónico.

Se cuenta con un presupuesto de $600 para la adquisición de los sensores faltantes y la construcción

del entorno de prueba.

1.4 Riesgos

La realización de un proyecto de estas características supone la aparición de ciertos riesgos

asociados a los procesos y actividades a llevar a cabo y a los recursos a utilizar. A continuación se

presentan los potenciales riesgos identificados y el plan de contingencia asociado a cada uno de

ellos.

El cuadro desarrollado sufrirá modificaciones a lo largo del proyecto ya sea para la introducción de

nuevos registros o para la actualización de los existentes.

*Actualización (23/02/13): No se identificaron nuevos riesgos a lo largo de todo el proyecto.

1.5 Métricas

En esta sección se describen las métricas que serán recogidas a lo largo del proyecto y los métodos

utilizados para hacerlo.


Riesgo Descripción Criticidad Contingencia Seguimiento

Procesos del Proyecto Variable

Dificultad en la Implementación Media

Dificultades con el Hardware Media

Procesos o Actividades No contempladas en el Ciclo de Vida del Proyecto

Ejecución de cualquieractividad o procesonecesario no especificadoen el Ciclo de Vida delProyecto y registro del mismo en el informe de Sugerencia de Mejoras en los Procesos

El Robot enfrenta situacionesimprevistas durante el recorrido de el entorno de prueba

Se evalúa la probabilidad de ocurrencia del imprevisto en el entorno productivo y se Actúa en consecuencia sobre el robot o sobre el entorno

El Robot presenta alguna dificultad relacionada al hardware o requiere decomponentes o interfaces Adicionales

Se contacta a RobotGroup;desarrollador y distribuidor del producto

199


Métrica M1: En primer lugar se implementara una métrica cuyo objetivo es la validación y ajuste de

la estimación de tiempo realizada.

El registro de esta métrica se llevara a cabo mediante la notación del tiempo utilizado para cada

actividad una vez finalizada la misma por parte de la persona encargada de llevarla a cabo. El

mismo se llevara a cabo en la Planilla de Control de Actividades presentada en el Apéndice A -

Planillas

Al finalizar cada fase del ciclo de vida esta estipulada una actividad de revisión en la cual se

relevaran las métricas recolectadas y se evaluará tanto la eficacia de la estimación realizada como la

evolución del proyecto aplicando las medidas que se consideren necesarias para mantener el normal

curso del proyecto y satisfacer las expectativas y objetivos planteados.

Métrica M2: En segundo lugar, se implementara una métrica referente a la cantidad de obstáculos y

problemas encontrados a lo largo del proyecto ya sea bien en los procesos utilizados como en las

cuestiones meramente técnicas.

El registro de esta métrica se llevara a cabo mediante el método de reporte de problemas propuesto

en la sección 1.1.5.

La evaluación de esta métrica se llevara a cabo en la actividad de revisión prevista en el final de

cada fase del Ciclo de Vida.

Métrica M3: Por ultimo se implementara una métrica destinada al control de cambios. Los datos

serán obtenidos de la Planilla de Control de Cambios presentada en el Apendice A – Planillas, en la

cual se asientan todas las solicitudes a fin de evaluar su implementación y registrar el evento . La

misma será descripta con mayor detalle en el Plan de Gestión de la Configuración.

La evaluación de esta métrica se realizara en las mismas circunstancias que las anteriores, es decir,

durante la actividad de revisión prevista en el final de cada fase del Ciclo de Vida.

Además del propósito particular de cada métrica, todas ellas poseen un objetivo en común que es la

alimentación del registro histórico de proyectos que fomente la mejora constante de los procesos y

consecuentemente de los productos elaborados.

1.6 Objetivos de Seguridad

No se identifican objetivos de seguridad en la etapa inicial del proyecto. A pesar de que el producto



a desarrollar no prevé el uso de datos ni información sensible se deja el proceso abierto a futuras

consideraciones que puedan surgir a lo largo del proyecto.

*Actualización (23/02/13): No se identificaron Objetivos de Seguridad a lo largo de todo el

proyecto.

2. Plan de Integración

El objetivo principal de esta sección es la planificación de las actividades y recursos necesarios para

llevar a cabo la integración de los componentes de software entre si y con el hardware del robot

para finalmente consolidar el sistema requerido.

Las dimensiones de este proyecto en particular tornan innecesaria la modularización del desarrollo

del software por lo cual la planificación de la integración se refiere únicamente a la necesaria entre

el software y el hardware.

Como requerimiento principal de esta tarea es necesaria la concreción de las actividades referentes a

la generación del código de programa y a la selección y ensamblado del hardware apropiado,

incluyendo las interfaces físicas.

La integración se llevará a cabo mediante el entorno de programación DuinoPack provisto por

RobotGroup junto con el hardware. El mismo es una versión del Arduino IDE con la incorporación

de las librerías y agregados necesarios para trabajar con el hardware provisto. La documentación de

instalación y operación de dicho software se encuentra disponible en la base de conocimiento del

proyecto (Guide.Robotics-1.ESP.20120229 ).

La comunicación entre el hardware y el entorno de programación es mediante un cable USB-

MiniUSB. El mismo se encuentra disponible al igual que los drivers requeridos.

Las actividades requeridas para la integración:

• Desarrollado y compilación del código fuente mediante el entorno de programación

• Conexión del Hardware Arduino al entorno de programación mediante el cable usb-



micro.usb provisto.

• Alimentación y Encendido del hardware

• Instalación de los drivers provistos

• Carga del código en el hardware Duinobot. (Instrucciones provistas en el manual

Guide.Robotics-1.ESP.20120229 )

• Operación del Robot.

Concluidas estas actividades el Robot se encuentra en condiciones de ser verificado y validado

siguiendo las actividades establecidas en el Plan de Evaluación.

3. Plan de Evaluación

A través de este plan se establecen las actividades y recursos necesarios para la evaluación eficaz

del producto desarrollado y los procesos utilizados para hacerlo. Es por eso que organizaremos el

documento en torno a las evaluaciones del Producto y del Proceso.

3.1 Evaluación del Producto

Como requerimiento principal para la realización de las tareas de evaluación, es necesaria la

concreción de las actividades descriptas en el Plan de Integración.

La metodología de verificación del producto consta de las siguientes actividades:

A.5.1.4 Desarrollar procedimientos de prueba

A.5.1.2 Crear una Matriz de Trazabilidad

A.5.1.5 Crear datos de Prueba

A.5.1.6 Ejecutar las Pruebas

A.5.1.7 Reportar los Resultados de la Evaluación.

Se realizarán pruebas dinámicas de Sistema y Aceptación utilizando metodologías funcionales de

Caja Negra a fin de verificar que el sistema esta correctamente construido y validar que la

funcionalidad presentada es la requerida.



Se desestiman las pruebas unitarias y de integración por considerarse innecesarias dadas las

dimensiones y características del proyecto.

Se generarán los casos de pruebas con base en la especificación de requisitos y funcionalidades del

proyecto y las metodologías de prueba seleccionadas. Posteriormente se desarrollará una matriz de

trazabilidad con el objetivo de asegurar que la evaluación de todas las funcionalidades esta cubierta

por alguno de los casos de prueba desarrollados.

Estas actividades se desarrollan y presenta en mayor detalle en el Informe de Pruebas del Sistema.

Será necesaria la construcción de un entorno de prueba que emule las condiciones básicas de un

invernadero e incorpore los aspectos requeridos por el robot para realizar correctamente su tarea. La

especificación básica de requerimientos del entorno de prueba se describe a continuación y será

refinada con el correr de las pruebas:

• La ancho mínimo del camino debe ser de 30 cm dadas las dimensiones del robot.

• Se debe fijar sobre el centro del camino una franja blanca de 15 cm de ancho como mínimo

conteniendo a su vez en su centro, una linea de color negro opaco de al menos 3 cm de

ancho. La disposición de la cinta debe acompañar el recorrido del camino. Esto es necesario

para el garantizar el correcto desplazamiento del robot.

• Es importante despejar cualquier tipo de obstáculo que impida la normal circulación del

robot aunque en caso de encontrarse, el mismo intentara superarlo.

• Se debe disponer en el recorrido marcas transversales al mismo que señalicen la ubicación

de un puesto a relevar sobre uno de los laterales y la disposición de una marca de fin de

recorrido sobre el otro. Ambas deben ser color negro opaco y presentar un espesor de al

menos 3 cm. Los requerimientos del entorno de prueba serán descriptos con mayor detalle

posteriormente.

Desarrolladas y ejecutadas las pruebas, se describen sus procedimientos, se almacenan y presentan

sus resultados, se corrigen y reportan los errores detectados y se registran las posibilidades de

mejora observadas en el Plan de Pruebas del Sistema.

3.1.1 Condiciones de Aceptación

Por tratarse de una prueba de concepto en la cual no interviene un cliente real, las condiciones de



aceptación del sistema serán descriptas en este documento y se limitan a las descriptas debajo. En

un proyecto real podría ser necesaria la elaboración de un documento independiente y se debe

solicitar la conformidad escrita del cliente respecto del acuerdo establecido.

• El sistema cumple con la totalidad de los requisitos funcionales excluyentes

• El sistema cumple con la totalidad de los requisitos no funcionales

3.2 Evaluación del Proceso

La evaluación de los procesos utilizados se llevará a cabo mediante la aplicación de técnicas

estáticas de pruebas como revisiones técnicas y gerenciales y a través del estudio de métricas

establecidas en el proyecto como la métrica M2 que refleja la cantidad de obstáculos y problemas

encontrados a lo largo del proyecto ya sea bien en los procesos utilizados como en las cuestiones

meramente técnicas.

Las conclusiones serán reflejadas en el Reporte de Sugerencia de Mejoras al Ciclo de Vida, dentro

del Informe de Garantía de Calidad.

4. Plan de Instalación

Culminada la fase de evaluación del producto se procede a la Instalación del mismo en el entorno

productivo.

Las Actividades requeridas por este proceso son las siguientes:

A.4.1.1 Ajustar parámetros de entorno

A.4.1.2 Configurar y Adaptar las interfaces al entorno productivo y otros sistemas

A.4.1.3 Adaptar el Software al ambiente operativo

A.3.3.3 Crear la Documentación Operativa

A.4.2.1 Operar el Sistema

A.4.2.2 Proveer de asistencia técnica y consultas

A.5.1.4 Mantener el histórico de peticiones de soporte



Culminadas estas actividades, el sistema se encuentra técnicamente listo para entrar en operación.

Los parámetros de entorno tales como la señalización del recorrido, el circuito de caminos que

recorren los invernaderos, los niveles de temperatura, etc han sido fijados en el software del robot.

El proceso de relevamiento y sintonía de estos parámetros comienza en la Fase de Evaluación del

Proyecto.

Los resultados de este proceso puede encontrarse en el Reporte de Instalación y Operación del

Sistema.

5. Plan de Gestión de la Configuración

Se denomina Gestión de la Configuración1 al conjunto de procesos destinados a asegurar la calidad

de todo producto obtenido durante cualquiera de las etapas del desarrollo de un Sistema de

Información (S.I.), a través del estricto control de los cambios realizados sobre los mismos y de la

disponibilidad constante de una versión estable de cada elemento para toda persona involucrada en

el citado desarrollo. Estos dos elementos (control de cambios y control de versiones de todos los

elementos del S.I.) facilitan también el mantenimiento de los sistemas al proporcionar una imagen

detallada del sistema en cada etapa del desarrollo. La gestión de la configuración se realiza durante

todas las fases del desarrollo de un sistema de información, incluyendo el mantenimiento y control

de cambios, una vez realizada la puesta en producción.

Previo al paso a producción del sistema, es necesario identificar los ítems de la configuraciones (de

aquí en mas, Configuration Ítems o CI) que estarán sujetos a control, establecer una metodología de

control de cambios que garantice la ejecución ordenada y documentada de los mismos y por ultimo

identificar y describir el primer “baseline”, es decir el estado actual de los CI. Los CI serán

definidos en el Informe de Estado de la Configuración. A continuación se describe el procedimiento

a llevar a cabo ante la necesidad de realizar una modificación en el sistema productivo. Se generan

una Planilla de Control de Cambios a fin de registrar las actividades realizadas durante el proceso.

La misma puede encontrarse en el Apéndice A.

1 Wikipedia Foundation, Inc. 2008. Gestión de la configuración. http://es.wikipedia.org/wiki/Configuration_management. Vigencia 11/2013.


http://es.wikipedia.org/wiki/Configuration_management


1. Identificación y Solicitud

◦ Se registra e identifica mediante un código único el cambio requerido y su

respectivo plan de acción en la planilla de Solicitud de Cambios. El mismo puede

surgir de un incidente o una sugerencia de mejora.

2. Evaluación

◦ Se analiza el cambio solicitado focalizando en la identificación y análisis de los

ítems de configuración afectados, la relación riesgo-costo/beneficio de la

implementación y evaluando el potencial impacto en el desempeño del sistema.

3. Respuesta

◦ Se aprueba o rechaza el cambio justificando la elección. Se registra la decisión en

la Planilla de Solicitud de Cambio

4. Notificación, Implementación y Prueba

◦ En caso de ser aprobado, se notifica al usuario con antelación al evento, se

implementa el cambio y se procede a la evaluación del mismo.

5. Registro

◦ Se actualiza el Informe de Estado de la Configuración a fin de reflejar los

cambios realizados y se establece un nuevo “baseline”. Se llama “baseline” a una

configuración que ha sido revisado formalmente, sobre el que se ha llegado a un

acuerdo, que de ahí en adelante servirá como base para un desarrollo posterior y

que puede cambiarse solamente a través de procedimientos formales de control

de cambios.

Los cambios pueden ser preventivos o reactivos, es decir, planificarse a partir de una necesidad de

mejora o en respuesta a un incidente. En ambos casos, se debe seguir el mismo proceso indicando

en el los 3 dígitos iniciales del identificador de la Planilla de Control de Cambios si el mismo fue

originado por un Incidente (INC) o una necesidad de Mejora (MEJ).



6. Plan de Mantenimiento

Ya en producción, el sistema puede requerir de un cronograma de mantenimiento tanto perfectivo

como correctivo que permitan garantizar la continuidad de funcionamiento del Robot con el

transcurso del tiempo. Se sugiere el siguiente Cronograma de Mantenimiento:

1. Relevamiento semanal de los registros de Solicitud de Asistencia Técnica y planificación de

cambios perfectivos.

2. Evaluación mensual en el entorno productivo por parte del personal técnico del proyecto, del

funcionamiento del hardware y las interfaces físicas. Limpieza y lubricación de la estructura

y las partes móviles. Reemplazo de baterías. Relevamiento de posibilidades de mejora.

Duración promedio 2hs, dependiendo de las dimensiones y complejidad del entorno.

3. Evaluación y corrección diaria por parte del usuario de las condiciones del entorno; caminos

y sus señalizaciones, invernaderos, obstáculos, etc.

Las actividades a realizar en la visita de mantenimiento y los resultados de las mismas son

registrados en la Planilla de Reporte de Mantenimiento. Pueden encontrarse las Planillas de

Solicitud de Asistencia Técnica y Reporte de Mantenimiento en el Apéndice A.

7. Plan de Documentación

Esta sección describe el plan de documentación entregable y no entregable del proyecto.

Los documentos serán desarrollados a lo largo de todo el proyecto y no como última actividad del

mismo. A continuación se listan los documentos a producir. La participación de actividades en la

conformación de los documentos puede encontrarse en el Mapa de Documentos.

• Inicialización del Proyecto

◦ Mapa de Actividades

◦ Mapa de Documentos

◦ Secuencia de Actividades



• Plan de Proyecto

◦ Cuadro de Estimaciones

◦ Planillas

▪ Reporte de Problemas

▪ Control de Actividades

▪ Control de Cambios

▪ Asistencia Técnica

▪ Mantenimiento

• Especificación de Requisitos

• Especificación de Diseño

• Manual de Operaciones

◦ Instructivo de Operación básica

◦ Descarga de Datos

◦ Alteración del Entorno

◦ Mantenimiento

◦ Instrucciones de Soporte Técnico

• Reporte de Instalación y Operación del Sistema

• Reporte de Evaluación del Sistema

• Informe de Estado de la Configuración

• Informe de Garantía de Calidad

8. Plan de Gestión de Lanzamiento

En esta sección se planifican las actividades y recursos necesarios para la transición del producto,

desde el entorno de prueba hacia el entorno productivo.

Como fue mencionado en apartados anteriores, este proyecto se enmarca en las condiciones de una

Prueba de Concepto de un Trabajo Final de Licenciatura en Sistemas por lo cual no prevé la

implementación inmediata del producto en un entorno productivo sino que busca validar un modelo

de aplicación propuesto.



A pesar de esto, se listan algunas consideraciones y una secuencia de actividades clave sugeridas

para la conducción exitosa de esta fase. Se omite la asignación de recursos a las actividades.

• El sistema no interactúa ni interfiere con otros sistemas informáticos o electrónicos

productivos lo cual reduce notablemente el riesgo de impacto negativo en la productividad.

• Dependiendo de la dimensión y disposición del camino en los invernaderos, el sistema

podría eventualmente interferir en la realización de ciertas actividades manuales realizadas

por personal del Invernadero. La prolongación temporal del proceso de transición del

producto podría generar un deterioro en el nivel de productividad del negocio.

La metodología de lanzamiento del producto se alinea a la propuesta en el Plan de Gestión de

Cambios. De igual manera que ante un cambio, previo al lanzamiento del producto, se debe validar

y verificar el producto a implementar, analizar la relación costo-riesgo/beneficio y elaborar planes

de contingencia necesarios para minimizar el riesgo de impacto negativo en la producción.

La secuencia básica de actividades sugerida para el Plan de Lanzamiento de un producto de

características similares a las de este proyecto es la siguiente:

1. Planificar el Lanzamiento

2. Coordinar el diseño, construcción y configuración del entregable

3. Coordinar la evaluación y aprobación del producto por parte de Gestión de Cambios.

4. Planificar la transición del producto al entorno operativo. Evaluar Riesgos.

5. Coordinar las actividades de comunicación y entrenamiento

6. Coordinar la distribución e instalación del producto

7. Registrar y proveer información referente a la calidad del lanzamiento y la operación del

producto.



Apéndice A. Planillas


Planilla de Reporte de Problemas

REPORTE

ID FECHA FASE DESCRIPCION SEGUIMIENTOPROPIETARIO

DEL PROBLEMASOLUCIONES POTENCIALES

CORRECCION

FECHA DESCRIPCION EJECUTOR FINALIZADOPROPUESTAS DE MEJORA

Planilla de Reporte de Asistencia Técnica

Planilla de Solicitud de Asistencia técnica

ASISTENCIA TÉCNICANOTIFICACION RESOLUCION

ID FECHA CATEGORIA DESCRIPCION CRITICIDAD EJECUTOR FECHA COMENTARIOS

alta/media/bajahard/soft

SOLICITUD DE ASISTENCIA TÉCNICAFECHA:

SISTEMA:CATEGORIA: SOFTWARE HARDWARE ENTORNO

DESCRIPCION DEL PROBLEMA:

CRITICIDAD:CONTACTO PRINCIPAL:

EMAIL DE CONTACTO:TELEFONO DE CONTACTO:

Planilla de Reporte de Mantenimiento

ORDEN DE MANTENIMIENTOID FECHA

CLIENTE PRODUCTO

ACTIVIDAD RESULTADO COMENTARIOS

PROBLEMAS REPORTADOSID FECHA CATEGORIA DESCRIPCION CRITICIDAD EJECUTOR FECHA COMENTARIOS

IDENTIFICACION DE POSIBLES MEJORASID CATEGORIA DESCRIPCION COSTO BENEFICIO

Planilla de Control de Actividades

CONTROL DE ACTIVIDADES

ACTIVIDAD COMIENZO FINALIZACION EJECUTOR FINALIZADO COMENTARIOSFECHA FECHA


Planilla de Solicitud de Cambio

Información General

ID del Cambio Nombre del Sistema Fecha

Solicitante Teléfono Email

Definición de la Solicitud de Cambio

Descripción – Describir el cambio propuesto.

Justificación

Impacto ante la no implementación del cambio

Soluciones Alternativas

Riesgos a tener en cuenta

Estimación de Esfuerzo y Recursos

Origen (marcar con una X) Impacto (marcar con una X)

Preventivo Software

Correctivo

Hardware

Entorno

Mejora

Procedimientos

Documentación

Configuration Items Afectados

Revisión de la Solicitud de Cambio

Fecha de Revisión Nombre del Revisor Resolución Justificación

Aprobado

Rechazado



Información General

ID del Cambio Nombre del Sistema Fecha

Demorado




Especificación de Requisitos

Versión 1.0








21/02/13 Actualización de Requerimientos de Software del Proyecto



Tabla de Contenidos

1. Introducción

2. Informe preliminar de Necesidades

3. Informe preliminar de Soluciones Potenciales

a. Solución A: Robot Autónomo Móvil

b. Solución B: Aplicación de Tecnología al Entorno

4. Informe de Viabilidad

a. Solución A: Robot Autónomo Móvil

b. Solución B: Aplicación de Tecnología al Entorno

4.1. Selección de la Solución mas conveniente

5. Descripción de Idea o Necesidad

6. Descripción de Funciones del Sistema

7. Descripción de Arquitectura del Sistema

8. Asignación de Requerimientos

9. Informe de Requerimientos de Hardware e Interfaces

10. Informe de Requerimientos de Entorno

11. Especificación de Desarrollo de Hardware Seleccionado.

11.1 Selección de Hardware

11.2 Descripción del Hardware seleccionado

12. Informe de Requerimientos de Software del Proyecto

13. Informa de Requerimientos de Software del Sistema

14. Informe de Integración de Requisitos



1. Introducción

A lo largo de este documento abordaremos las actividades necesarias para identificar con el

mayor grado de precisión posible las necesidades del cliente respecto de la solución a

construir y de esta manera derivar la especificación de requisitos y funcionalidades de

hardware, software y entorno que permitan abordar adecuadamente la fase de diseño. Esta

fase se considera una de las mas criticas de todo proyecto de ingeniería de sistemas ya que

una deficiente especificación de requisitos puede derivar en la construcción de un producto

que no responde a las necesidades del cliente provocando la necesidad de reiniciar el

proyecto.

2. Informe Preliminar de Necesidades

El trabajo en invernaderos1 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. Entre las mismas podemos mencionar el control de

condiciones ambientales de temperatura y humedad de los cultivos, pulverización de

insecticidas, recolección o transporte de materiales.

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 resta al monto de dinero obtenido por ventas, del monto

gastado o invertido en 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)

1 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.

materia prima; semillas en este caso, y © personal capaz de llevar a cabo las tareas de

siembra, mantenimiento y recolección del producto.

La automatización de las tareas mencionadas , podría suponer el remplazo de un alto

porcentaje de los recursos humanos requeridos para las tareas de siembra, mantenimiento y

recolección del producto, lo cual no solo implicaría una disminución notable en los costos por

reducción de salarios innecesarios sino también la de los tiempos de operación con la

capacidad que esto conlleva de permitir aumentar el volumen de producción y un incremento

en los niveles de control sobre los procesos utilizados que permite implementar procesos de

mejora continua de la calidad de los productos elaborados.

3. Informe Preliminar de Soluciones Potenciales

En respuesta a las necesidades planteadas en la sección anterior, se plantean las siguientes

soluciones potenciales:

Solución A: Robot Autónomo Móvil

La primera solución potencial consta de la construcción de un robot con capacidad autónoma

de desplazamiento cuyo objetivo sea el recorrido de los invernaderos a través de caminos

preexistentes, en busca del relevamiento de condiciones de temperatura y humedad y a

futuro tenga la capacidad de incorporar funciones como pulverización de insecticidas,

recolección de materiales, captura de imágenes.

Solución B: Aplicación de tecnología al entorno

La segunda solución potencial busca implementar tecnología al entorno, en este caso el

invernadero. La instalación de sensores de temperatura y humedad en cada invernadero, la

disposición de aspersores tanto para riego como para aplicación de insecticidas, la utilización

de cámaras de seguridad para el control y seguimiento del cultivo, entre otras.



4. Informe de Viabilidad

El objetivo del Estudio de Viabilidad del Sistema es el análisis de un conjunto concreto de

necesidades para proponer una solución a corto plazo, que tenga en cuenta restricciones

económicas, técnicas, legales y operativas.

A continuación abordaremos el análisis de las soluciones propuestas focalizando en los

aspectos recientemente sugeridos.

Solución A: Robot Autónomo Móvil

Económico: Desde el punto de vista económico, esta propuesta supone una inversión

reducida respecto del hardware ya que se prevé que el mismo robot releve la totalidad de los

invernaderos. Existen arquitecturas de sistemas embebidos en el mercado local como

internacional capaces de satisfacer las necesidades a costos realmente convenientes.

Técnico: Existen numerosas implementaciones de robots autónomos móviles utilizando

sistemas embebidos en la actualidad y diversos tipos de sensores compatibles con los

mismos. En lo que respecta al recorrido del entorno, se pueden establecer diversos tipos y

técnicas de algoritmos de recorrido según la conveniencia. Entre ellos podemos destacar por

su simpleza de implementación, el Seguimiento de una Linea o la indicación preestablecida

de coordenadas de desplazamiento.

Las condiciones ambientales de operación como ser la temperatura no son factores de riesgo

para el hardware.

Legales: No se presumen acciones o características en el sistema que puedan provocar

conflictos legales.

Operativos: Se considera que este sistema puede suponer una mejora notable en la

productividad de un invernadero. No se detectan aspectos técnicos o referentes al entorno que

puedan poner en riesgo la factibilidad de implementación del Robot.

Solución B: Aplicación de tecnología al entorno

Económico: Desde el punto de vista económico, esta solución supone un nivel de inversión



relativamente alto respecto del caso anteriormente analizado. Cada invernadero debe contar

con sus propios sensores, cámaras, aspersores, etc. Además de ello, es necesaria el

establecimiento de un medio de comunicación y centralización de la información obtenida.

Técnico: En lo que respecta a las cuestiones técnicas, la solución es perfectamente

implementable ya que existen una gran diversidad dispositivos de sensado de condiciones

ambientales y medios de comunicación y centralización de la información obtenida,

disponibles en el mercado.

Legal: No se presumen acciones o características en el sistema que puedan provocar

conflictos legales.

Operativo: Se considera que este sistema puede suponer una mejora notable en la

productividad de un invernadero. No se detectan aspectos técnicos o referentes al entorno que

puedan poner en riesgo la factibilidad de implementación de la solución.

4.1 Selección de la Solución mas conveniente

Presentadas y analizadas las soluciones potenciales se decide la selección de la opción A, un

Robot Autónomo Móvil por suponer una conveniencia tanto en el aspecto Técnico como

Económico. Los motivos que impulsaron esta decisión se listan a continuación.

• Utilizando un robot autónomo móvil, se reduce la cantidad de hardware necesario ya

que la misma unidad recorrerá la totalidad de los invernaderos.

• La adaptabilidad y escalabilidad del robot autónomo móvil es notablemente superior a

la de la opción B. Ante la necesidad de modificar la ubicación o agregar un

invernadero simplemente se requieren modificaciones leves en el software y el

camino y no en el hardware.

• Un robot autónomo móvil puede incorporar con mayor facilidad que la opción B. la

habilidad de recolectar residuos y materiales.

La principal desventaja o riesgo detectado en la utilización de la opción A, es la dependencia

que se genera en torno a una sola unidad, es decir, si ocurre alguna falla que provoque la



caída del servicio del robot, la totalidad de los invernaderos se verán impactados. La opción

B en cambio, tendría una composición modular que evitaría la denegación total del servicio.

Sin embargo, la relación costo-beneficio y el nivel de criticidad que el cliente le asigna a la

actividad, hacen que la opción a implementar sea la A, un Robot Autónomo Móvil.

5. Descripción de Idea o Necesidad

Con base en el Informe Preliminar de Necesidades y el Informe de Viabilidad se refina y

presenta la descripción de la Idea o Necesidad.

A fin de satisfacer la necesidad de automatización de un conjunto de tareas inherentes a la

actividad diaria de un Invernadero, como ser el relevamiento de condiciones ambientales

tales como temperatura y humedad, la aspersión de insecticidas, recolección y/o transporte de

materiales y captura de imágenes, entre otras, es necesaria la construcción de un Robot móvil

capaz de desplazarse de manera autónoma y programada a lo largo de los caminos dispuestos

en el interior de uno o mas invernaderos.

El robot debe partir de una posición inicial preestablecida y desandar los caminos dispuestos

y conocidos con el fin de visitar la totalidad de los invernaderos o puestos dentro de ellos,

deseados, a fin de realizar las actividades mencionadas anteriormente.

Es un aspecto a definir la técnica y los algoritmos a utilizar para el recorrido del entorno.

Entre las opciones principales se encuentran la disposición de una linea de seguimiento en el

camino y diversas marcas que le permitan al robot identificar los distintos puestos a relevar y

el inicio/fin del circuito.

Es un requisito no excluyente pero deseado que el robot tenga la capacidad de superar

obstáculos simples que se le presenten en el camino.

Una vez completado el recorrido, el robot debe retornar al punto de partida donde la

información relevada sera descargada manualmente para su análisis y llegado el momento,

desde donde deberá emprender un nuevo recorrido.



En la primera etapa de este desarrollo, se prevé solo la implementación de la funcionalidad de

sensado de humedad y temperatura aunque debe considerarse en el diseño la posibilidad de

una futura incorporación de las funcionalidades restantes.

6. Descripción de Funciones del Sistema

Refinada la Idea o Necesidad, se describen las funcionalidades requeridas en el sistema a

desarrollar. Para ello se utiliza el Modelo de Requisitos para Sistemas Embebidos ABC-

BESOINS-SEM propuesto en las técnicas sugeridas.

Se listaran las categorías y subcategorías indicadas por el modelo y se analizaran los

requisitos del sistema particular de este proyecto.

1. Disponibilidad de Objetos

1.1 Estados

1.1.1 Los estados responden a los modos y submodos mencionados en la

categoría Selección de Alternativas

1.2 Eventos

El Sistema deberá conmutar su modo y submodos de operación de acuerdo

a los siguientes eventos:

1.2.1 La pulsación de un botón físico de Encendido y Apagado provoca la

transición del modo Encendido a Apagado y viceversa.

1.2.2 La pulsación de un botón físico de Comienzo y Parada forzada,

ubicado en el robot, provoca el cambio de submodo de operación de Espera

a Operacional y viceversa.



1.2.3 El sistema debe poseer la capacidad de cronogramar la frecuencia de

los recorridos. El temporizador conmutara el submodo de operación del

sistema de Espera a Operacional.

1.2.4 La culminación del recorrido planificado provocará que el robot se

dirija a una posición de finalización preestablecida donde conmutara el

submodo del sistema de Operacional a Espera

1.2.5 El sistema debe ser capaz de identificar el momento en el cual se

encuentra en un puesto donde debe realizar la actividad deseada. En ese

momento conmutara el submodo de operación a Sensado.

2. Convocación y demostración

2.1 Interfaces

2.1.1 El sistema debe contener un pulsador de encendido y apagado.

2.1.2 El sistema debe contener un pulsador de arranque y parada de

emergencia.

2.1.3 El sistema debe ser capaz de sensar las condiciones de humedad y

temperatura de un puesto o invernadero y almacenarla en su memoria para la

posterior descarga y análisis de la misma.

2.1.4 El Sistema debe ser capaz de desplazarse de manera autónoma

utilizando preferentemente ruedas o cualquier otro tipo de actuadores por un

camino regular siguiendo una linea trazada en el mismo o bien ejecutando

instrucciones preconfiguradas.

2.1.5 El sistema debe proporcionar un puerto de descarga de la información

relevada a una PC.




encuentra en un puesto donde debe realizar la actividad deseada, detener su

marcha y posicionarse de manera apropiada.

2.1.7 Es un requerimiento no excluyente pero deseable que el sistema sea

capaz de sortear obstáculos básicos que se le presenten en el camino.

2.1.8 El sistema debe informar la conclusión del relevamiento de un puesto o

del recorrido completo mediante un actuador lumínico o sonoro.

3. Selección de alternativas

3.1 Modos de operación

3.1.1 El sistema posee 2 modos de operación; Encendido o Apagado y 3

submodos de operación dentro del modo de operación Encendido. Estos son

En Espera, Operacional y Sensado.

3.2 Submodos de operación

3.2.1 Modo Encendido

3.2.1.1 Submodo En Espera: El robot esta realizando una descarga de

información, esperando un recorrido cronogramado o bien que se

aguardando a que se presione el botón de comienzo forzado.

3.2.1.2 Submodo Operativo: El robot se encuentra en movimiento

3.2.1.3 Submodo Sensado: El robot se encuentra detenido y

realizando mediciones de temperatura y humedad.



3.2.2 Modo Apagado

No hay submodos de operación

4. Solicitud de Acceso

4.1 Modo Encendido

4.1.1 Submodo Espera:

4.1.1.1 Debe estar disponible la funcionalidad del botón de comienzo

y parada forzada

4.1.1.2 Debe estar disponible la funcionalidad de Cronograma de

Recorridos

4.1.1.3 Debe estar disponible la funcionalidad de descarga de

información

4.1.2 Submodo Operativo:

4.1.2.1 Deben estar disponibles todas las funcionalidades descriptas

en la categorías “Interacción de Agentes” y “Acción del agente”

4.1.3 Submodo Sensado:

4.1.3.1 Deben estar disponibles todas las funcionalidades

descriptas en la categorías “Interacción de Agentes” y “Acción del

agente”

4.2 Modo Apagado

No hay submodos presentes en este modo de operación.



5. Aporte (entrada-respuesta)

5.1 El usuario debe presionar el botón de Comienzo/Parada de emergencia o

Encendido/Apagado para alterar el estado del robot y acceder a las

funcionalidades que brinda.

6. Verificación / Decisión

6.1 El sistema no presenta requerimientos de este tipo

7. Interacción de Agentes

7.1 Interrelaciones con Súper-Sistema

El sistema no presenta requisitos de este tipo

7.2 Interrelación con otros sistemas embebidos y el ambiente

7.2.1 El sistema debe permitir la descarga de datos relevados por el sensor

mediante su conexión a una PC

7.2.2 Debe ser capaz de detectar una linea en el camino y desplazarse

siguiendo la disposición de la misma. Esta lo llevara a los diversos puestos

que deben ser relevados.


encuentra en un puesto donde debe realizar la actividad deseada, detener

su marcha y posicionarse de manera apropiada.

7.2.4 Es un requerimiento no excluyente pero deseable que el sistema sea

capaz de sortear obstáculos básicos que se le presenten en el camino.

7.2.5 Concluido el relevamiento de un puesto, el sistema debe notificar la



situación mediante una señal lumínica o sonora.

7.2.6 Concluido el recorrido, el sistema debe retornar al punto de partida o

bien detenerse en un punto de culminación preestablecido y notificar

mediante una señal lumínica o sonora dicha condición.

8. Acción del Agente

8.1 Funcionalidades de entrada

8.1.1 El sistema debe recibir una entrada proveniente de la pulsación del

botón de Comienzo y Parada forzada que le permita conmutar el submodo

de operación.

8.1.2 El sistema debe recibir una entrada del modulo temporizador que le

permita conmutar el submodo de operación.

8.1.3 El sistema debe recibir una entrada de los sensores infrarrojos

detectores de linea que le permitan establecer una ruta de desplazamiento

8.1.4 El sistema debe recibir una entrada de los sensores ultrasónicos a fin

de detectar le presencia de un obstáculo.

8.1.5 El sistema debe recibir datos relevados por el sensor de temperatura

y humedad y almacenarlos.

8.1.6 El sistema debe recibir una entrada proveniente de la fuente de

alimentación.

8.2 Funcionalidades de proceso

8.2.1 El sistema debe almacenar los datos obtenidos por el sensor de

temperatura



8.2.2 El sistema debe analizar las entradas obtenidas por los sensores

infrarrojos detectores de linea

8.2.3 El sistema debe analizar las entradas obtenidas por los sensores de

ultrasonido

8.3 Funcionalidades de salida

8.3.1 El sistema debe proveer una señal a los actuadores (motores de las

ruedas) para provocar su desplazamiento

8.3.2 El sistema debe proveer una señal a un actuador lumínico o sonoro

para notificar la conclusión del relevamiento de un puesto o de la totalidad

del recorrido.

9. Transferencia / Actualización

9.1 El sistema debe analizar las entradas obtenidas por los sensores infrarrojos y

enviar una señal a los actuadores para provocar su movimiento en seguimiento de

la linea existente en el camino

9.2 El sistema debe analizar las entradas obtenidas por los sensores de

ultrasonido y enviar una señal a los actuadores para provocar un movimiento que

busque evitar el obstáculo detectado.

9.3 El sistema debe analizar la entrada provista por el usuario mediante la

pulsación del botón de Comienzo o Parada forzada y conmutar el submodo de

operación entre Espera u Operativo según corresponda.

10. Interrupción/ restitución/ conservación



10.1 Prevención de fallas

El sistema no presenta requerimientos de este tipo

10.2 Detección de fallas


11. Desempeño / Cambio


12. Precio y Costos

12.1 Tamaño

12.1.1 El sistema debe poder desplazarse fácilmente por caminos de

dimensiones reducidas.

12.2 Consumo de energía

12.2.1 Al tratarse de un sistema móvil autónomo, es deseable que el

consumo del mismo sea bajo ya que será alimentado por baterías

13. Descripción y caracterización de los agentes

13.1 Disponibilidad


13.2 Fiabilidad


13.3 Seguridad frente al exterior

13.3.1 El sistema debe ser capaz de soportar condiciones ambientales con

altos niveles de humedad y en algunos casos temperaturas por debajo o



encima del promedio.

13.4 Seguridad frente a ataques

13.4.1 El hardware debe estar protegido ante una eventual caída o choque

leve del robot.

13.5 Eficiencia

13.5.1 Por tratarse de una prueba de concepto, el robot debe presentar un

porcentaje de eficiencia de al menos 60%.

7. Descripción de la Arquitectura del Sistema

A partir de la descripción de funcionalidades realizada, se plantea una arquitectura básica

basada en un sistema embebido capaz de incorporar un conjunto de actuadores y sensores

destinados a provocar a partir del procesamiento de señales obtenidas del entorno y mediante

una serie de algoritmos por parte del microcontrolador del sistema, su propio movimiento.

En la Figura 1 se puede observar la composición modular del sistema y en la Figura 2 la

disposición jerárquica de los módulos.

Fig. 1 Diagrama básico de Arquitectura del Sistema. MC: Microcontrolador, M: Memoria,

SE: Sistema Embebido



Fig. 2 Disposición jerárquica de los módulos del sistema.

8. Asignación de Requerimientos

Con base en la descripción de funcionalidades presentada en la sección 6, se procede a la

asignación de las mismas al tipo de requerimiento que suponen; Requerimiento de Software,

Hardware, Interfaces o Entorno.

En la Figura 3 puede observarse el mapa de Asignación de requerimientos que servirá de

entrada principal en las secciones siguientes; Especificación de Requisitos de Hardware,

Especificación de Requisitos de Interfaces, Especificación de Requisitos de Software y

Especificación de Requisitos de Entorno.


Entorno

Sistema Embebido

Controlador

Sensores Actuadores

Almacenamiento Microcontrolador Entradas / Salidas

239


Fig. 3 Mapa de Asignación de Requisitos

9. Informe de Requerimientos de Hardware e Interfaces

En esta sección se listan las funcionalidades que supondrían un requerimiento de Hardware,

se analizan y se extrae de ellas la especificación de requisitos de hardware del proyecto.


Requerimiento Requerimiento

Funcionalidad

Softw

are

Har

dwar

e/In

terf

az

Ento

rno

Funcionalidad

Softw

are

Har

dwar

e/In

terf

az

Ento

rno

1.2.1 X 7.2.3 X X X1.2.2 X 7.2.4 Ver 2.1.71.2.3 X 7.2.5 Ver 2.1.81.2.4 X X 7.2.6 X X1.2.5 X 8.1.1 X2.1.1 X 8.1.2 X2.1.2 X 8.1.3 X2.1.3 X X 8.1.4 X2.1.4 X X 8.1.5 X2.1.5 X 8.1.6 X2.1.6 X X X 8.2.1 X X2.1.7 X X 8.2.2 X2.1.8 X X 8.2.3 X3.1.1 X 8.3.1 X

3.2.1.1 X 8.3.2 X3.2.1.2 X 9.1 X3.2.1.3 X 9.2 X4.1.1.1 X 9.3 X4.1.1.2 X 12.1.1 X4.1.1.3 X 12.2.1 X4.1.2.1 X 13.1.1 X X4.1.3.1 X 13.3.1 X

5.1 X 13.4.1 X7.2.2 X X X 13.5.1 X

240


2.1.1 El sistema debe contener un pulsador de

encendido y apagado.

▪ 1 Entrada Digital

▪ 1 Pulsador

2.1.2 El sistema debe contener un pulsador de

arranque y parada de emergencia.

▪ 1 Entrada Digital

▪ 1 Pulsador

2.1.3 El sistema debe ser capaz de sensar las

condiciones de humedad y temperatura de un

puesto o invernadero y almacenarla en su

memoria para la posterior descarga y análisis de la

misma.

▪ 1 Entrada Analógica o Digital

▪ 1 Sensor de Temperatura y Humedad

▪ Unidad de almacenamiento

permanente integrada

2.1.4 El Sistema debe ser capaz de desplazarse de

manera autónoma utilizando preferentemente

ruedas o cualquier otro tipo de actuadores por un

camino regular siguiendo una linea trazada en el

mismo.

▪ 2 Salidas Digitales o Analógicas

▪ 2 Motores DC

▪ 2 Ruedas

▪ 2 Sensor Infrarrojo para la detección

de Linea

▪ 2 entradas analogicas


Funcionalidad

Har

dw

are

/ In

terf

az2.1.1 X2.1.2 X2.1.3 X2.1.4 X2.1.5 X2.1.6 X2.1.7 X2.1.8 X7.2.2 X7.2.3 X7.2.6 X8.1.3 X8.1.4 X8.1.5 X8.1.6 X8.2.1 X12.1.1 X12.2.1 X13.1.1 X13.3.1 X13.4.1 X

241


2.1.5 El sistema debe proporcionar un puerto de descarga de la información relevada a una

PC.

▪ Puerto de comunicación preferentemente USB.

2.1.6 El sistema debe ser capaz de identificar el momento en el cual se encuentra en un

puesto donde debe realizar la actividad deseada, detener su marcha y posicionarse de

manera apropiada.

▪ 1 Entrada Analógica

▪ 1 Sensor Infrarrojo para la detección de una marca

2.1.7 Es un requerimiento no excluyente pero deseable que el sistema sea capaz de sortear

obstáculos básicos que se le presenten en el camino.

▪ 1 Entrada Analógica

▪ 1 Sensor Ultrasónico

2.1.8 El sistema debe informar la conclusión del relevamiento de un puesto o del recorrido

completo mediante un actuador lumínico o sonoro.

▪ 2 Salidas Digitales

▪ 1 LED

▪ 1 Buzzer

7.2.2 Debe ser capaz de detectar una linea en el camino y desplazarse siguiendo la

disposición de la misma. Esta lo llevara a los diversos puestos que deben ser relevados.

▪ Requerimiento cubierto en 2.1.4



manera apropiada.




7.2.6 Concluido el recorrido, el sistema debe retornar al punto de partida o bien detenerse

en un punto de culminación preestablecido y notificar mediante una señal lumínica o sonora

dicha condición.

▪ 1 entrada analógica

8.1.3 El sistema debe recibir una entrada de los sensores infrarrojos detectores de linea que

le permitan establecer una ruta de desplazamiento


8.1.4 El sistema debe recibir una entrada de los sensores ultrasónicos a fin de detectar le

presencia de un obstáculo.


8.1.5 El sistema debe recibir datos relevados por el sensor de temperatura y humedad y

almacenarlos.


8.1.6 El sistema debe recibir una entrada proveniente de la fuente de alimentación.

▪ Fuente de alimentación mediante baterías. La especificación del

voltaje y potencia requerida se efectuara una vez seleccionado el

hardware a utilizar.

8.2.1 El sistema debe almacenar los datos obtenidos por el sensor de temperatura


12.1.1 El sistema debe poder desplazarse fácilmente por caminos de dimensiones

reducidas.

▪ El desarrollo de hardware debe presentar dimensiones reducidas.

12.2.1 Al tratarse de un sistema móvil autónomo, es deseable que el consumo de energía del

mismo sea reducido ya que será alimentado por baterías.

▪ El desarrollo de hardware seleccionado debe suponer un consumo

reducido de energía.



13.1.1 El sistema debe ofrecer una disponibilidad de 12 horas durante 5 días de la semana.

▪ El sistema debe presentar un nivel de consumo que le permita

funcionar durante 12 hs con la menor cantidad de interrupciones

posibles.

13.3.1 El sistema debe ser capaz de soportar condiciones ambientales con altos niveles de

humedad y en algunos casos temperaturas por encima del promedio.

▪ El robot debe presentar una carrocería resistente a las condiciones

supuestas.

13.4.1 El hardware debe estar protegido ante una eventual caída o choque leve del robot.


A continuación se listan los requerimientos de Hardware extraídos del análisis realizado:

▪ Arquitectura de Sistema Embebido

• 2 Entrada Digital

• 6 Entradas Analógicas

• 2 Salidas Digitales

• 2 Salidas Digitales o Analógicas

• Unidad de almacenamiento permanente integrada

• Puerto de comunicación preferentemente USB.

• Fuente de alimentación mediante baterías. La especificación del voltaje y

potencia requerida se efectuara una vez seleccionado el hardware a utilizar.

• El desarrollo de hardware debe presentar dimensiones reducidas.

• El desarrollo de hardware seleccionado debe suponer un consumo


• El sistema debe presentar un nivel de consumo que le permita funcionar

durante 12 hs con la menor cantidad de interrupciones posibles.

• El robot debe presentar una carrocería resistente a las condiciones

supuestas.



▪ Interfaces

• 2 Pulsadores

• 1 Sensor de Temperatura y Humedad

• 2 Motores DC

• 2 Ruedas

• 2 Sensor Infrarrojo para la detección de Linea

• 2 Sensor Infrarrojo para la detección de marcas

• 1 Sensor Ultrasónico

• 1 Modulo SDCARD

• 1 LED

• 1 Buzzer

10. Informe de Requerimientos de Entorno

1.2.4 La culminación del recorrido planificado

provocará que el robot se dirija a una posición de

finalización preestablecida donde conmutara el

submodo del sistema de Operacional a Espera

▪ Debe colocarse una linea transversal al

camino en la posición de partida y espera. Ver

Figura 5.



manera apropiada.

▪ Debe Realizarse una linea transversal al camino en la posición

donde se encuentra un puesto a verificar. Ver Figura 5.

7.2.2 Debe ser capaz de detectar una linea en el camino y desplazarse siguiendo la

disposición de la misma. Esta lo llevara a los diversos puestos que deben ser relevados.


Funcionalidad

En

torn

o

1.2.4 X2.1.6 X7.2.2 X7.2.3 X8.1.1 X

245


▪ El camino a recorrer debe disponer en su centro de una linea negra

opaca de 3- centímetros sobre un fondo blanco. Esto se puede lograr o

bien pintando la misma si es que la superficie del camino es

totalmente blanca o bien desplegando una suerte de rollo de material

blanco con una linea pintada en su centro como puede apreciarse en la

Figura 4.

7.2.3 El sistema debe ser capaz de identificar el momento en el cual se encuentra en

un puesto donde debe realizar la actividad deseada, detener su marcha y posicionarse

de manera apropiada.

▪Requerimiento cubierto por 2.1.68.1.1 El sistema debe recibir

una entrada proveniente de la pulsación del botón de Comienzo

y Parada forzada que le permita conmutar el submodo de

operación.

▪El usuario debe presionar el botón de Comienzo y Parada

Forzada


Puesto a relevar

Camino

Adaptación suelo irregular

Puesto a relevar

Camino

Adaptación suelo blanco

Punto de Partida

Punto de Partida



Fig. 5 Adaptacion del camino

247


11. Especificación de Desarrollo de Hardware Seleccionado.

Conocida la especificación de requerimientos y en carácter previo a la concepción de la

especificación de requisitos de software se procede, mediante la utilización del documento

de Relevamiento de Hardware y la Matriz Comparativa provista por el modelo objeto de

validación, a la selección del hardware que mejor se adapte a las necesidades planteadas.

Especificación de requerimientos de Hardware:

▪ Arquitectura de Sistema Embebido

• 2 Entrada Digital

• 3 Entradas Analógicas

• 2 Salidas Digitales

• 2 Salidas Digitales o Analógicas

• Unidad de almacenamiento permanente integrada

• Puerto de comunicación preferentemente USB.

• Fuente de alimentación mediante baterías. La especificación del voltaje y

potencia requerida se efectuara una vez seleccionado el hardware a utilizar.

• El desarrollo de hardware debe presentar dimensiones reducidas.

• El desarrollo de hardware seleccionado debe suponer un consumo


• El sistema debe presentar un nivel de consumo que le permita funcionar

durante 12 hs con la menor cantidad de interrupciones posibles.

• El robot debe presentar una carrocería resistente a las condiciones

supuestas.

Luego de analizar la especificación de requerimientos de hardware y con soporte en

Diagrama Comparativo de Hardware propuesto por el TFL y accesible a través del ANEXO II

adjunto al mismo, se selecciona la plataforma Arduino por satisfacer la necesidad de entradas

y salidas analógicas, ofrecer la posibilidad de almacenamiento permanente, presentar un nivel



de consumo bajo y dimensiones reducidas además de una gran comunidad de desarrollo y

documentación disponible de manera gratuita. Cabe destacar además que Arduino es una

plataforma Libre.

Tras el análisis de la carrocería, sensores y actuadores necesarios para el robot;

▪ Interfaces

• 2 Pulsadores

• 1 Sensor de Temperatura y Humedad

• 2 Motores DC

• 2 Ruedas

• 2 Sensor Infrarrojo para la detección de Linea

• 2 Sensores Infrarrojos para la detección de una marca

• 1 Sensor Ultrasónico

• 1 LED

• 1 Buzzer

11.1 Selección del Hardware

Se selecciona el desarrollo basado en Arduino llamado Kit Duinobot - Multiplo N6

desarrollado por RobotGroup Argentina que incorpora la mayor parte de los sensores y

actuadores requeridos simplificando la etapa de ensamblado del robot.

El kit Duinobot no incluye el sensor de Temperatura y Humedad ni los sensores infrarrojos

laterales para la detección de marcas en el camino. Estos serán adquiridos de manera

independiente e integrados en el sistema. Se selecciona el sensor de humedad y temperatura

DHT11 de amplia disponibilidad en el mercado y probado éxito en implementaciones con

Arduino. Los sensores IR laterales son iguales a los frontales y provistos por RobotGroup.



11.2 Descripción General del Hardware Seleccionado

A continuación se detallan las características de Múltiplo N6:

El Múltiplo N6 es un modelo de robot con fines educativos diseñado y ensamblado en el país

por la empresa RobotGroup.

Para poder moverse, el robot cuenta con tres ruedas, dos delanteras independientes y una

trasera mas pequeña que gira libremente. Las ruedas delanteras cuentan con tracción

diferencial gracias a dos motores de corriente continua que se controlan por software

independientemente uno del otro. Esto permite programar el robot para que vaya hacia

adelante, hacia atrás o que gire variando la velocidad de una a rueda con respecto de la otra.

Para poder percibir el entorno, posee varios sensores: dos sensores reflexivos y uno

ultrasónico. Los reflexivos emiten luz infrarroja y detectan cambios de contraste entre las

superficies claras y oscuras, permitiendo programar el robot para que siga una linea o detecte

un borde, entre otras cosas. El sensor ultrasónico agrega la posibilidad de detectar o

obstáculos a distancia con una precisión del orden de los centímetros. Todos estos sensores,

los motores y un buzzer que emite frecuencias en el espectro audible se conectan a una placa

central llamada Duinobot basada en Arduino, con un microcontrolador programable

Atmega32U4. Recordemos que Arduino es una plataforma Libre y puede ser modificada

respetando las pautas establecidas en su licencia (Creative Commons), es por esto que

Robotgroup ha diseñado Duinobot, una implementación de Arduino a la cual le han realizado

modificaciones de acuerdo a sus deseos y necesidades.

El robot, además, tiene algunos conectores libres para otros tipos de sensores que pueden ser

agregados adicionalmente a futuro.

11.3 Especificaciones técnicas del Hardware seleccionado

A continuación se listan las principales características del desarrollo de hardware

seleccionado. Las mismas fueron tomadas del documento Guide.Robotics-1.ESP.20120229 el



cual puede ser descargado de manera gratuita del sitio oficial del desarrollador:

http://www.robotgroup.com.ar

Alimentación:

• El controlador Duinobot posee un sistema de alimentación que permite entregar hasta 12 V

a los motores partiendo de sólo 3 pilas AA (o cualquier otra celda de 3.6 V, ya sea NiMH o

Li- Ion). Además, es capaz de elevar la tensión de alimentación de la lógica del circuito,

permitiendo la conexión de todo tipo de sensores estándar y otros accesorios Múltiplo de 5V.

• También es posible alimentar la placa mediante un puerto USB.

Sensores :

• Dos sensores infrarrojos reflexivos. Se pueden utilizar tanto como para medir luz reflejada

(por ejemplo, color), como para medir luz incidente. La aplicación mas común es detectar

una linea en el piso para poder seguirla.

• Un sensor de distancia ultrasónico que permite identificar la distancia a un obstáculo con

precisión de centímetros.

• Un sensor interno de carga de la batería que permite conocer el voltaje de la fuente de

alimentación.

Software:

El controlador DuinoBot se basa en Arduino y puede ser programado de forma nativa stand-

alone (escribiendo software de modo que quede residente en el microcontrolador del robot)

en C++, Bitlash y otros lenguajes de alto nivel.

Microcontrolador :

• Placa controladora DuinoBot basada en el microprocesador AVR ATMega32U4 y

desarrollada por RobotGroup.

• Memoria de programa: Flash de 32 KBytes.

• Memoria de datos volátil: SRAM 2.5 KBytes.

• Memoria de datos no volátil: EEPROM de 1 KByte.


http://www.robotgroup.com.ar/


• Velocidad: 14-16 MIPS @ 16 Mhz.

Interfaz de usuario:

• Un buzzer permite la generación de tonos a diferentes frecuencias.

• LED de usuario.

• LED indicador de 5V (alimentación lógica).

• LED indicador de alimentación de motores (6V / 12V).

• 4 LEDs indicadores de sentido de giro de los motores.

• Un pulsador de Reset.

• Un pulsador de Usuario/Run.

Comunicaciones :

• USB por hardware en el microcontrolador (lo cual permite utilizarlo como CDC, HID, entre

otros, según el software que el usuario baje al microcontrolador). Esto permite utilizar la

placa controladora también como kit de desarrollo para aplicaciones USB.

• Puerto extra serie TTL con conector estándar para módulos de comunicaciones Múltiplo

(C0).

Entradas y Salidas :

• Seis entradas para sensores analógicos de 10 bits, con ficha estándar para los sensores

Múltiplo . (S0 a S5).

Las entradas analógicas pueden funcionar también como salidas digitales programables de

hasta 40 mA (200 mA como máximo entre todos los pines).

• Doble puente H MOSFET de alto rendimiento para motores de 2.5 a 13.5 V, corriente

promedio de 1.2 A y pico de 3.2 A (M0 y M1).

• Mas entradas y salidas disponibles en los conectores estándar Arduino.



12. Informe de Requerimientos de Software del Proyecto

Los requerimientos del software necesario para la construcción del sistema requerido se

desprenden principalmente de la arquitectura de hardware seleccionada (Sección 11).

Como fue mencionado en la sección anterior, el hardware a utilizar para la construcción del

sistema es Múltiplo N6 de Robotgroup, el cual contiene una placa base Duinobot basada en

Arduino. Esta plataforma ofrece la posibilidad de desarrollar el software en diversos

lenguajes y proporciona junto con el hardware, Duinopack; un entorno Arduino 0022

(entorno de programación oficial de Arduino) modificado especialmente por el fabricante de

Múltiplo N6 para incorporar todas las librerías necesarias para el comando de los sensores y

actuadores incluidos. Arduino 0022 además, posee una gran cantidad de documentación de

acceso libre y una gran comunidad de programadores.

El entorno de programación Duinopack puede descargarse de manera gratuita desde el sitio

web del fabricante http://multiplo.org/files/soft/DuinoPack.v1.0.zip. A la fecha, la versión

mas reciente es la 1.0 y es la que utilizaremos.

*Actualización (21/02/13): Se requiere el uso de una librería para el manejo del sensor

DHT11. La misma puede ser descargada y utilizada de manera gratuita.

13. Informe de Requerimientos de Software del Sistema

Los requerimientos de software para la implementación del sistema requerido se desprenden

principalmente de descripción de funcionalidades (Sección 6) y la arquitectura del sistema

(Sección 7).

A continuación se presenta el Diagrama de Contexto (Figura 6) que presenta un esquema

básico de interacción del sistema con el entorno, el usuario y otros sistemas, la Tabla de

Eventos (Figura 7), en la cual se describen los procesos principales del sistema y se

describen sus entradas y respuestas y por ultimo el Diagrama de Flujo de Datos (Figura 8),

que representa gráficamente los procesos descriptos en la Tabla de Eventos e interrelaciona


http://multiplo.org/files/soft/DuinoPack.v1.0.zip


sus entradas y respuestas.


Fig. 6 Diagrama de Contexto

Fig. 8 Diagrama de Flujo de Datos

ANEXO IV - DOCUMENTOS DEL PROYECTO CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.

Fig. 7 Tabla de Eventos

14. Informe de Integración de Requisitos

Analizadas las especificaciones de requerimientos de Hardware e Interfaces, Entorno y Software

detalladas en las secciones anteriores, no se identifica el desprendimiento de un nuevo

requerimiento relativo a la integración de los mismos aunque no se descarta la posibilidad de

ocurrencia durante la fase de Diseño e Implementación.


TABLA DE EVENTOS

#EVENTOS FLUJO DE DATOS

TIPO DESCRIPCION ESTIMULO RESPUESTA

1 TEMP

2 TEMP

3 TEMP

4 TEMP

5 TEMP

6 EXT SOLICITUD DE DATOS DATOS RELEVADOS

7 TEMP

8 TEMP

9 TEMP DESPLAZAMIENTO DESPLAZARSE

10 EXT USUARIO

ENTIDADEXTERNA

FUNCION ASOCIADA

SENSADO DE AMBIENTE

TEMPERATURAY HUMEDAD

SENSAR AMBIENTE

SENSADO DE CAMINO

DISPOSICION DEL CAMINO

SENSAR CAMINO

SENSADO DE OBSTACULOS

DISPOSICION DEL OBSTACULO

SENSAR OBSTACULOS

SENSADO DE PUESTOS

DISPOSICION DEL PUESTO

SENSAR PUESTOS

SENSADO DEL CIRCUITO

DISPOSICION DEL CIRCUITO(INICIO – FIN)

SENSAR CIRCUITO

PUESTO DE DESCARGA

DESCARGA DE DATOS

DESCARGARDATOS

ARRANQUE TEMPORIZADO

ORDEN DE DESPLAZAMIENTO

TEMPORIZADO

INICIO TEMPORIZADO

ESQUIVAR OBSTACULO

OBSTACULO ESQUIVADO

ESQUIVAR OBSTACULO

DESPLAZARSE POR EL CAMINO

INICIAR / PARAR FORZADO

SOLICITUD DE ARRANQUE / PARADA

FORZADA

ORDEN DE INICIO / PARADA FORZADA

INICIAR / PARAR FORZADO



Especificación de Diseño

Versión 1.0





Tabla de Contenidos

1. Introducción

2. Especificación de Diseño Arquitectónico

3. Especificación de Diseño de Interfaces

4. Especificación de Diseño Detallado.

1. Diseño Detallado de Hardware

2. Diseño Detallado de Software



1. Introducción

En este capitulo, tomaremos como base la información generada en el capitulo anterior inherente a

la especificación de requisitos de Hardware e Interfaces, Software y Entorno y derivaremos el

Diseño Arquitectónico del Sistema (Sección 2) tanto a nivel Hardware (Sección 2.1) como Software

(Sección 2.2). Realizaremos la Especificación de Diseño de las Interfaces (Sección 3) y por ultimo

presentaremos el Diseño Detallado del Sistema que permitirá alimentar las fases subsiguientes de

desarrollo e implementación del robot.

2. Especificación de Diseño Arquitectónico

El sistema se compone de una placa base la cual contiene un microcontrolador, unidades de

almacenamiento temporario y permanente y una serie de entradas y salidas digitales y analógicas

programables que le permiten al robot interactuar con el entrono y planificar su conducta. Cuanta

además con un grupo de sensores; Sensor de Temperatura y Humedad, Sensor Ultrasónico,

Sensores Infrarrojos, y un grupo de actuadores; 2 motores DC para el movimiento de las ruedas, 1

LED y 1 Buzzer.

El hardware será gestionado por un sistema embebido basado en el lenguaje de programación

sugerido para la arquitectura seleccionada, el cual se encargara de analizar las señales obtenidas del

entorno y proporcionar las señales necesarias a los actuadores, para desplazarse de la manera mas

conveniente.

A partir de la descripción de la arquitectura básica y disminuyendo el nivel de abstracción

empleado, se desarrolla un diagrama de la arquitectura del sistema con un mayor nivel de detalle. El

mismo puede observarse en la Figura 1

En la Figura 2, anteriormente presentada en el documento de Especificación de Requisitos, se puede

observar un esquema que presenta la arquitectura y disposición jerárquica de los módulos que

componen al sistema embebido.

A continuación, en la Figura 3 del presente documento, presentaremos una representación de dicho

esquema con un nivel de abstracción mayor a fin de conocer los submódulos que componen a cada

uno de los bloques principales del sistema embebido.



Fig. 1 Diagrama de Arquitectura del Hardware del Sistema

Fig.2 Disposición jerárquica de los módulos del sistema.


14

3

Sensores

Actuadores

2

5 6

1. Ultrasonido2. Infrarrojo3. Humedad y Temperatura

4. Ruedas x 25. LED6. Buzzer

SE SE

Entorno

Sistema Embebido

Controlador

Sensores Actuadores



Como se puede observar en la Figura 2, el sistema presenta un modulo principal inmediatamente

sobre la capa del sistema embebido, llamado Controlador. El mismo es el encargado de interactuar

con las Interfaces ya sean de sensado o actuado.

En la Figura 3 podemos observar la descomposición del modulo Controlador. El mismo presenta 2

módulos en su base. Una capa de Relevamiento, destinada a la gestión de la tarea de sensado de

temperatura y humedad en los Puestos y almacenamiento de los registros obtenidos y una capa de

Desplazamiento, destinada a la gestión del movimiento del Robot a lo largo del camino. Esta capa

contiene submódulos dedicados a la gestión del sensado (del Circuito, Puestos, Obstáculos y

Camino) y del Actuado, principalmente a través de los motores DC que provocaran el giro de las

ruedas aunque también de los dispositivos de señalización como LEDs y Buzzers que indican la

finalización de ciertas actividades.


Fig.3 Diagrama de Arquitectura de Software del Sistema

DESPLAZAMIENTO

CIRCUITO PUESTOS OBSTACULOSCAMINO

ACTUADO SENSADO

RUEDASNOTIFICACIONES

RELEVAMIENTO

SENSADO ALMACENAMIENTO

TEMP/HUM

CONTROLADOR

Sistema Embebido


Sensores Actuadores

ANEXO IV – DOCUMENTOS DEL PROYECTO CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.

3. Especificación de Diseño de Interfaces

De la Especificación de Requerimiento se desprende la necesidad de contar con un conjunto de

Sensores y Actuadores que permitan al Robot interactuar con el Entorno, botones que permitan la

interacción con el Usuario y un puerto USB que permita la interacción con el sistema de descarga

de datos. La disposición física de los mismos puede observarse en la Figura 1 de la Sección 2.

A continuación presentamos el Diseño Arquitectónico de las interfaces del sistema con un mayor

nivel de abstracción. No se contemplan el puerto USB ni los botones de encendido/apagado y

arranque/parada forzada en el diagrama por considerarlos parte componente integrada en el

hardware base Arduino de Múltiplo N6 aunque serán tenidos en cuenta a la hora de realizar el

diseño detallado.

Fig. 4 Diagrama Arquitectónico de Interfaces


IR ULTRASONICO TEMP/HUM MOTOR DC LED BUZZER

ACTUADORESSENSORES

Controlador

Sistema Embebido



4. Especificación de Diseño Detallado

A lo largo de esta sección, profundizaremos la descripción del diseño Arquitectónico de Hardware

del Sistema presentado en la Figura 1, detallando las conexiones entre las interfaces físicas y la

plataforma de hardware Arduino (Sección 3.1).

Posteriormente y ya dentro del ámbito del software, analizaremos los submódulos Desplazamiento

y Relevamiento, principales componentes del módulo Controlador y presentados en la Figura 3 de

la sección 2. Desarrollaremos los diagramas de flujo correspondientes a los mismos a fin de

describir con el mayor nivel de precisión posible los distintos escenarios que el sistema puede

enfrentar (Sección 3.2).

4.1 Diseño detallado de Hardware

Como fue mencionado en el documento de especificación de requisitos, el hardware a utilizar

consta de un kit desarrollado por RobotGroup llamado Múltiplo. El mismo utiliza Duinobot (una

implementación de Arduino) y su carcasa fue especialmente diseñada para facilitar el conexionado

de las distintas interfaces que provee el kit, como los motores y ruedas, sensores infrarrojos,

sensores ultrasónicos, leds y buzzers. Presenta un sistema de conectores en el frente del robot que

permiten conectar cualquier sensor provisto por RobotGroup de manera simple y ágil. Puede

descargarse de manera gratuita desde el sitio web de RobotGroup ( robotgroup.com.ar ), el

documento con las indicaciones de montaje del robot Múltiplo, incluyendo tanto las referentes al

montaje de la carcasa y las partes mecánicas como el conexionado de las interfaces en la placa

Arduino.

El sensor de humedad y temperatura DHT11 no esta incluido en el kit y su conexionado no presenta

la ficha standard de RobotGroup, por lo cual a continuación en la figura 5 presentaremos el

diagrama de conexionado con la placa Duinobot.



Fig. 5 Diagrama de conexión del sensor DHT11

Por último, en la figura 6, presentamos el diagrama completo de conexionado de los

diversos sensores requeridos, al modulo principal. La disposición de los actuadores no

sufrió modificaciones respectos del diseño original del kit Múltiplo N6 por lo cual se omite

su descripción en el gráfico.



Fig 6. Diagrama de conexión del hardware

4.2 Diseño detallado de Software

En esta sección desarrollaremos el diseño detallado de cada uno de los submódulos del módulo

Controlador, identificados en el diseño arquitectónico desde el nivel de abstracción mas alto hasta el

mas bajo.



Fig 7. Diagrama de Flujo Submódulo Camino




Fig 8. Diagrama de Flujo Submódulo Obstaculos

Fig 9. Diagrama de Flujo Submódulo Puestos


En la Figura 7 puede observarse el submódulo

correspondiente a la detección del camino y

desplazamiento. El mismo utiliza 2 sensores infrarrojos

frontales para detectar una linea en el camino y envía

la señal correspondiente a los actuadores (2 motores

DC). El resultado es el movimiento recto del robot o

bien la corrección de la trayectoria según corresponda.

En la Figura 8 se observa el submódulo de Obstáculos.

El mismo es el encargado de detectar cualquier

obstáculo que se presente en el recorrido y planificar el

movimiento de manera tal de sortear el mismo. Utiliza

un sensor ultrasónico y envía la señal correspondiente

a los motores DC. El resultado de este modulo es la

continuación del estado anterior del robot o bien la

corrección de la trayectoria según corresponda.

En la Figura 9 se puede observar el submódulo de

Puestos. El mismo es el responsable de detectar la

presencia de un puesto a sensar. Para ello utiliza un

sensor infrarrojo lateral para detectar una marca en el

camino. El resultado es la continuación del estado

anterior del robot o bien el paso del mismo al modo de

sensado.

En la Figura 10 se puede observar el submódulo de

Circuito, encargado de detectar la finalización del

recorrido. Esto es posible a través de el sensado de una

marca lateral en el camino mediante el mismo sensor

infrarrojo utilizado en el submódulo de puestos aunque

con un valor disparador diferente. El resultado es la


Fig 10. Diagrama de Flujo Submódulo Circuito


continuación del estado anterior o bien el paso del

robot al modo Espera.

En la Figura 11, puede observarse el diagrama de flujo completo del sistema. El mismo incorpora el

requerimiento de arranque temporizado e inicio/parada forzada mediante la pulsación de un botón

por parte del usuario. Dadas las dimensiones del diagrama, se presenta en 2 tramos.

Fig. 11.a) Diagrama de flujo completo



Fig. 11.b) Diagrama de flujo completo




Manual de Operaciones

Versión 1.0





Tabla de Contenidos

1. Introducción

2. Especificación de Hardware

3. Operación básica

4. Descarga de datos

5. Modificaciones en el Recorrido – Nuevos Puestos

6. Mantenimiento

7. Soporte técnico



1. Introducción

El producto desarrollado se trata de un Robot Autónomo Móvil de pequeñas dimensiones, destinado

a la realización de tareas de invernadero, particularmente en esta fase inicial, la medición de valores

de temperatura y humedad relativa.

Cuenta con sensores infrarrojos y ultrasónicos que le permiten planificar su accionar respecto de las

condiciones del entorno y con actuadores que le permiten desplazarse por los caminos dispuestos.

Este manual de operaciones fue desarrollado con el objetivo de guiar al usuario final en la ejecución

de las actividades necesarias para la correcta operación y mantenimiento del Robot. El mismo esta

estructurado en 6 secciones que se describen brevemente a continuación.

La sección 1 hace referencia a la Operación básica del sistema; Provee las indicaciones necesarias

para la puesta en marcha y normal operación del robot en el entorno productivo. La sección 2 esta

dedicada a la Descarga de Datos relevados por el robot a una PC. La sección 3 busca guiar al

usuario en el proceso de modificación del entorno ya sea bien para adicionar o remover un puesto a

relevar o para realizar modificaciones en el camino. En la sección 5 se proveen sugerencias y

consideraciones a la hora de pensar en el mantenimiento del equipo y por ultimo, en la sección

numero 6, se presenta la información necesaria a la hora de solicitar asistencia técnica.

2. Especificación de Hardware

El sistema esta basado en la implementación de hardware Múltiplo N6 la cual utiliza el modulo

Duinobot v1.2, una variación de Arduino al cual le fueron adicionados 2 sensores infrarrojos para la

detección de marcas laterales y un sensor de humedad y temperatura. A continuación la

especificación completa de hardware del sistema y un diagrama de conexión.

Alimentación:

• El sistema posee un sistema de alimentación que permite entregar hasta 12 V a los motores

partiendo de sólo 3 pilas AA (o cualquier otra celda de 3.6 V, ya sea NiMH o Li- Ion). Además, es



capaz de elevar la tensión de alimentación de la lógica del circuito, permitiendo la conexión de todo

tipo de sensores estándar y otros accesorios Múltiplo de 5V.

• También es posible alimentar la placa mediante un puerto USB.

Sensores :

• Cuatro sensores infrarrojos reflexivos destinados al sensado del camino y la disposición de

los puestos y el circuito.

• Un sensor de distancia ultrasónico que permite identificar la distancia a un obstáculo con

precisión de centímetros.

• Un sensor interno de carga de la batería que permite conocer el voltaje de la fuente de

alimentación.

• Un sensor de humedad y temperatura DHT11

Software:

El controlador del robot ha sido programado con un entorno Arduino modificado por el fabricante

de Multiplo N6 a fin de proveer las librerias necesarias para el manejo de las diversas interfaces

presentes.

Microcontrolador :

• Placa controladora DuinoBot basada en el microprocesador AVR ATMega32U4 y desarrollada

por RobotGroup.

• Memoria de programa: Flash de 32 KBytes.

• Memoria de datos volátil: SRAM 2.5 KBytes.

• Memoria de datos no volátil: EEPROM de 1 KByte.

• Velocidad: 14-16 MIPS @ 16 Mhz.

Interfaz de usuario:

• Un buzzer permite la generación de tonos a diferentes frecuencias.

• LED de usuario.



• LED indicador de 5V (alimentación lógica).

• LED indicador de alimentación de motores (6V / 12V).

• 4 LEDs indicadores de sentido de giro de los motores.

• Un pulsador de Reset.

• Un pulsador de Usuario/Run.

Comunicaciones :

• USB por hardware en el microcontrolador (lo cual permite utilizarlo como CDC, HID, entre otros,

según el software que el usuario baje al microcontrolador).

• Puerto extra serie TTL con conector estándar para módulos de comunicaciones Múltiplo (C0).

Entradas y Salidas :

• Seis entradas para sensores analógicos de 10 bits, con ficha estándar para los sensores Múltiplo.

(S0 a S5).

Las entradas analógicas pueden funcionar también como salidas digitales programables de hasta 40

mA (200 mA como máximo entre todos los pines).

• Doble puente H MOSFET de alto rendimiento para motores de 2.5 a 13.5 V, corriente promedio

de 1.2 A y pico de 3.2 A (M0 y M1).

• Mas entradas y salidas disponibles en los conectores estándar Arduino. (4 entradas analógicas y 13

entradas/salidas digitales entre otras)

En la Figura 1 puede observarse el diagrama de conexión especificado respecto de los puertos de

entrada/salida standard de Multiplo N6 y la disposición de los sensores en la estructura del robot.

Cabe destacar que el sensor de Humedad y Temperatura DHT11 no presenta una ficha standard de

Multiplo N6 y sera conectado directamente a la placa Duinobot, ocupando la entrada que utiliza el

puerto S0.



Fig. 1 Diagrama de conexión y disposición de los sensores

3. Operación Básica

El sistema cuenta con 3 modos de operación una vez encendido; Modo Espera, Modo Operativo y

Modo Sensado y es capaz de conmutar su condición entre estos estados por eventos sucedidos

internamente o provenientes del entorno. Entre los eventos provenientes del entorno se encuentran

principalmente las condiciones relevadas del camino como marcas en el camino, obstáculos y los

puestos y el accionar del usuario mediante el accionar de un botón. A continuación se describen los

modos de operación disponibles y las acciones que determinan su activación.



Modo Espera:

Al ser encendido, el Sistema se sitúa en este modo automáticamente. Se encuentra detenida su

marcha y no se realizan actividades de sensado del entorno.

Existen 2 variables capaces de modificar este estado; La pulsación del botón de arranque / parada

forzada por parte del usuario o bien la culminación del temporizador interno pre-programado. En

ambos casos, el robot conmutara del estado Espera al estado Operativo que se describe a

continuación.

Modo Operativo:

En este modo, el sistema se encuentra en movimiento o relevando las condiciones del camino y

planificando su accionar en consecuencia. Los eventos que hacen posible la alteración de este

estado son la activación del botón de arranque / parada forzada por parte del usuario o la detección

de una marca de fin de circuito, acciones que provocarán la inmediata conmutación al estado de

espera o la detección de un puesto, evento que provocara la conmutación al estado de sensado,

descripto a continuación.

Modo Sensado:

Este modo se inicia a partir de la detección de un puesto a relevar en el camino. El robot detiene su

marcha, realiza mediciones de temperatura y humedad del ambiente, almacena los datos obtenidos y

señaliza la finalización del proceso mediante una señal sonora y/o lumínica. La culminación del

proceso de medición, automáticamente supone el paso al modo Operativo nuevamente. En este

modo además, es posible la descarga de datos mediante una PC.

4. Descarga de Datos

Culminado un recorrido o la jornada productiva, el usuario debe descargar los datos de temperatura

y humedad relavados por el sistema. EL procedimiento para realizar esta actividad se describe a

continuación:

1. Conmutar el estado del robot al modo Espera



2. Conectar el robot a una PC que contenga el entorno de desarrollo Arduino mediante un

cable USB-MiniUSB

3. Iniciar el Entorno de Programación Arduino

4. Abrir el Software Descargador. El código fuente del descargador se adjunta al proyecto

junto con el código del sistema.

5. Modificar el parámetro referente a la cantidad de puestos presentes en el circuito.

6. Cargar el código en el Sistema y observar los resultados en el Monitor Serial.

El monitor serial presentara los datos de Temperatura y Humedad relevados en cada puesto.

5. Modificación del Recorrido – Nuevos Puestos

Este sistema ha sido diseñado para adaptarse fácilmente y sin necesidad de intervenir en el código

de programa, a la variación del entorno ya sea por la adición o remoción de un puesto, por la

modificación del camino o por la aparición de un obstáculo imprevisto. El robot no posee un mapa

precargado del recorrido sino que evalúa el camino y planifica su desplazamiento en consecuencia.

De ser requerida la adición de un nuevo puesto, simplemente es necesario conectar el mismo al

circuito original mediante un camino que satisfaga la especificación de requerimientos provista en

el Informe de Especificación de Requerimientos, es decir, que presente la señalización

correspondiente en su centro para guiar el recorrido del robot y la marca transversal en el sitio de

sensado para posibilitar la identificación del puesto a sensar. Para mas información consultar el

Informe de Requerimientos, sección Requerimientos del Entorno.

6. Mantenimiento

A fin de garantizar la efectividad y eficiencia en la operación del sistema y prolongar su vida útil se

ha elaborado un plan de mantenimiento del sistema. EL mismo fue presentado en el Plan de

Proyecto y se describe a continuación:



Ya en producción, el sistema puede requerir de un cronograma de mantenimiento tanto perfectivo

como correctivo que permitan garantizar la continuidad de funcionamiento del Robot con el

transcurso del tiempo.

Se sugiere el siguiente Cronograma de Mantenimiento:

1. Relevamiento semanal de los registros de Solicitud de Asistencia Técnica y planificación de

cambios perfectivos.

2. Evaluación mensual en el entorno productivo por parte del personal técnico del proyecto, del

funcionamiento del hardware y las interfaces físicas. Limpieza, ajuste y lubricación de la

estructura y las partes móviles según sea necesario. Reemplazo de baterías. Relevamiento de

posibilidades de mejora. Duración promedio 2hs, dependiendo de las dimensiones y

complejidad del entorno.

3. Evaluación y corrección diaria por parte del usuario de las condiciones del entorno; caminos

y sus señalizaciones, invernaderos, obstáculos, etc.

Las actividades a realizar en la visita de mantenimiento y los resultados de las mismas son

registrados en la Planilla de Reporte de Mantenimiento. Pueden encontrarse las Planillas de

Solicitud de Asistencia Técnica y Reporte de Mantenimiento en el Apéndice A o bien en la sección

6 de desde documento, dedicada al Soporte Técnico del producto.

7. Soporte Técnico

Como se describe en la sección anterior, fue planificado al inicio de este proyecto, el mantenimiento

preventivo y reactivo del sistema. Sin embargo, es posible la necesidad de contar con asistencia

técnica en cualquier momento.

Para solicitar asistencia técnica, enviar un correo electrónico a soporte@ robotinvernadero .com.ar

presentando la siguiente planilla completa. La misma permitirá asegurar la provisión de la

información necesaria para que personal de soporte técnico sea capaz de realizar un primer

diagnostico del problema, coordinar una visita y registrar la solicitud para futuras revisiones y

auditorías.






Planilla de Solicitud de Asistencia Técnica


SOLICITUD DE ASISTENCIA TÉCNICA

FECHA:

SISTEMA:

CATEGORIA: SOFTWARE HARDWARE ENTORNO

DESCRIPCION DEL PROBLEMA:

CRITICIDAD:

CONTACTO PRINCIPAL:

EMAIL DE CONTACTO:

TELEFONO DE CONTACTO:



Reporte de Instalación y Operación del Sistema

Versión 1.0





Tabla de Contenidos

1. Introducción

2. Configuración del Entorno

3. Adaptación de Interfaces al Entorno

4. Operación

4.1 Defectos encontrados

4.2 Propuesta de Mejoras

4.3 Observaciones



1. Introducción

Completadas las actividades referentes al desarrollo e integración, es momento de operar el sistema

en el entorno de prueba, o en caso de no utilizarse este, en el entorno productivo. El objetivo de esta

tarea es la detección preliminar de fallas tanto en el hardware como en el software y la sugerencia

de correcciones o mejoras en carácter previo al proceso de evaluación formal.

2. Configuración del Entorno

En carácter previo a la operación del sistema, es necesario configurar el entorno en conformidad

con la especificación de requerimientos del entorno elaborada.

Por tratarse de una prueba de concepto, el proyecto no dispone de un entorno productivo real por lo

cual se desarrollara un entorno de prueba a escala que presentara las características requeridas por el

sistema para despeñarse normalmente. A continuación se describen sus principales características.

El entorno de prueba consta de un circuito cerrado de dimensiones reducidas que dispone a lo largo

de su recorrido de 1 o 2 puestos a relevar.

El camino presenta las dimensiones mínimas requeridas para el normal desplazamiento del robot y

esta montado sobre una superficie rectangular de madera pintada de color blanco brillante de modo

de potenciar el proceso de reflejado de luz. Las marcas en el camino tanto para el desplazamiento

como para la señalización de puestos e inicio / fin de recorrido fueron pintadas con pintura de color

negro opaco a fin de potenciar el efecto de absorción de luz.

A lo largo del circuito, se encuentran 1 o 2 puestos a relevar construidos con materiales descartables

que simulan simplemente la estructura de un invernadero y no sus condiciones ambientales internas.

Los mismos están señalizados en la superficie del camino de acuerdo a la especificación de

requerimientos. Además, se dispuso una marca adicional para la indicación de fin de circuito. En la

figura 1 se puede observar un diagrama del entorno construido.



Además del entorno fijo, es necesario disponer de un obstáculo móvil capaz de ser ubicado

aleatoriamente a lo largo del camino a fin de evaluar la capacidad del robot de sortearlo. No se

especifican características del obstáculo ya que en condiciones reales podría presentarse de diversas

formas.

Fig. 1 Entorno de Prueba


INICIO / FIN DEL CIRCUITO PUESTO I

PUESTO II (MOVIL)

0.8 m

1m

OBSTACULO (MOVIL)


3. Adaptación de Interfaces al Entorno

Configurado el entorno es pertinente evaluar la disposición de las interfaces físicas del robot

respecto del mismo.

En primer lugar se debe evaluar la posición de los sensores infrarrojos frontales destinados al

sensado del camino. Los mismos deben ser capaces de ubicarse totalmente sobre la linea central del

camino.

Pasando a los sensores infrarrojos encargado de la detección de las marcas de los puestos y el inicio

y fin del circuito, los mismos debe estar ubicados sobre los laterales izquierdo y derecho del robot

respectivamente, de manera transversal al camino.

Los sensores ultrasónicos por defecto están correctamente ubicados por lo cual solo resta verificar

el sensor de humedad y temperatura. No se prevé una posición ideal para el mismo por lo cual se

debe chequear simplemente que se encuentre separado algunos centímetros de la carcasa del robot

para evitar interferencias en la medición.

4. Operación

Se procede a operar el robot siguiendo las instrucciones provistas en el manual de Operaciones. A

continuación se detallan las observaciones realizadas, defectos encontrados y mejoras sugeridas.

Durante la operación del sistema se realizaron diversos ajustes inherentes a la relación del robot con

el entorno, es decir, se alteraron algunas características de la señalización en el entorno y la

disposición y ubicación de los sensores destinados al sensado del camino. Con el correr de las

ejecuciones se refinaron los parámetros de velocidad y ángulo de giro del robot así como la

disposición de las marcas en el entorno a fin de estabilizar la marcha.

Se registró el proceso de operación del sistema y descarga de información mediante la filmación de

2 videos. Los mismos se encuentran adjuntos al proyecto o bien pueden observarse a través de

internet mediante los siguientes links:



Video Operación: http://www.youtube.com/watch?v=JIziVltf3iA

Video Descarga de Información: http://www.youtube.com/watch?v=zXe7yXsXopM

Los links se encuentran vigentes a la fecha de lanzamiento inicial de este documento.

4.1 Defectos encontrados

Se detecto un problema relacionado con los sensores laterales. Los mismos, al cursar una curva

pronunciada, se posicionaban por encima de la linea central provocando su activación ante un

evento no deseado. Para solucionarlo se modifico la ubicación de los mismos en el cuerpo del

robot.

Se detecto un problema de obstrucción en la rueda de giro trasera, ocasionada por la disposición del

cable conector de uno de los sensores laterales. Se solucionó fijando el cable a la estructura del

robot.

Se detectaron además algunas situaciones en las cuales el robot se comporta de forma errónea o

imprevista. Al enfrentarse con un obstáculo, el robot intenta desplazarlo mediante una serie de

golpes aplicados sobre el mismo. Al avanzar a una velocidad considerablemente mayor a la

promedio, en ocasiones puede perder orientación y acabar fuera del circuito e imposibilitado de

continuar con la operación. La funcionalidad relacionada con el sorteo de obstáculos no es

excluyente por lo cual no se prevén acciones a efectuar para corregir este defecto.

4.2 Propuesta de Mejoras

Luego de operar el sistema en reiteradas oportunidades y refinar la relación entre el robot y el

entorno para su óptimo desempeño, se proponen las siguientes mejoras:

• Disminuir el espesor de las marcas de puesto un 25% a fin de evitar el sensado reiterado.

• Prolongar la longitud de la marca de fin de circuito un 25% a fin de evitar el sorteo de la

marca ocasionado por una maniobra de corrección de curso.

• Adicionar al entorno una marca de puesto móvil a fin de ser utilizada durante la fase de

pruebas, en la validación de la funcionalidad que requiere la posibilidad de modificar la

cantidad de puestos a relevar sin alterar el software.


http://www.youtube.com/watch?v=zXe7yXsXopM

http://www.youtube.com/watch?v=JIziVltf3iA


• Perfeccionar los algoritmos de sensado y desplazamiento a fin de sortear situaciones

imprevistas que puedan mediante la generación de comportamientos indeseados, dejar al

sistema fuera de operación.

4.3 Observaciones

El grado de eficacia del robot es aproximadamente del 60%. Es decir, 4 de cada 10 veces en

promedio, que el mismo es puesto en operación, se encuentra con una situación improvista que le

impide continuar operando. Este valor es aceptado en el marco de una prueba de concepto aunque

no lo seria si el equipo debiera operar en un entorno productivo.

La memoria EEPROM tiene una cantidad finita de ciclos de escritura disponibles por lo cual no es

recomendable su utilización en aplicaciones productivas. En su lugar se recomienda el uso de

memorias del tipo SDCard. A la fecha no se dispone de librerías para el manejo de memorias

SDCard, compatibles con Duinobot.




Reporte de Evaluación del Sistema

Versión 1.0








22/02/13 Aceptación del Sistema



Tabla de Contenidos

1. Introducción

2. Procedimientos de Prueba

3. Matriz de Trazabilidad

4. Datos de Prueba

5. Ejecución y Resultados

6. Aceptación del Sistema


Apéndice A – Casos de Prueba

Apéndice B – Matriz de Trazabilidad



1. Introducción

A lo largo de este capitulo y con base en la especificación de funcionalidades y requisitos del

sistema, se diseñan los procedimientos de prueba necesarios (Sección 2), se realiza una matriz de

trazabilidad a fin de garantizar la evaluación de la totalidad de las funcionalidades requeridas

(Sección 3), se generan los datos necesarios para las pruebas (Sección 4) y por ultimo se ejecutan

las mismas y se reportan sus resultados.

2. Procedimientos de Prueba

Por las dimensiones del proyecto y por tratarse de una prueba de concepto, se obviaran las pruebas

unitarias y de integración y solo se llevaran a cabo pruebas de sistema y aceptación mediante

técnicas funcionales de caja negra a fin de verificar que el sistema desarrollado cumple con la

totalidad de las funcionalidades descriptas en el documento de especificación de requerimientos.

Los casos de prueba desarrollados pueden observarse en el Apéndice A – Planilla de Casos de

Prueba. Cada caso de prueba contiene un código identificador que lo diferencia del resto y presenta

una descripción breve de la funcionalidad a evaluar, la categoría del requerimiento a evaluar, es

decir, si es un requerimiento funcional o no funcional, las condiciones en las cuales la prueba es

llevada a cabo, los resultados esperados y por ultimo el resultado de la misma. Dado que el proyecto

solo cuenta con un recurso humano, no se provee dicha información en la descripción del caso de

prueba.

3. Matriz de Trazabilidad

A fin de garantizar la evaluación de la totalidad de las funcionalidades requeridas, se desarrolla la

matriz de Trazabilidad que puede observarse en el Apéndice B – Matriz de Trazabilidad. En la

misma se lista la totalidad de los requerimientos funcionales y no funcionales del proyecto y los

casos de prueba diseñados y se asigna cada requerimiento funcional a uno o mas casos de prueba

según corresponda.



4. Datos de prueba

Construido el entorno de prueba de manera acorde a la especificación de requisitos provista, no se

requiere el desarrollo de datos de prueba adicionales para los casos de prueba previstos.

5. Ejecución y Resultados

Elaborados los casos de prueba y garantizada la evaluación de la totalidad de las funcionalidades

requeridas mediante su ejecución, se procede a iniciar la ejecución de los casos de prueba

elaborados.

Como fue mencionado anteriormente, el robot desarrollado es el resultado de una prueba de

concepto por lo cual no existe un entorno productivo sino simplemente un entorno de prueba,

construido para la ocasión. Por la misma razón, el cliente y usuario final encargado de aceptar el

producto, es quien lo ha desarrollado y llevará a cabo las pruebas. Finalizadas las mismas y

obteniendo los resultados esperados, el producto es formalmente aceptado.

Ejecutadas las pruebas, pueden observarse sus resultados en el Apéndice A – Casos de Prueba.

Aproximadamente el 88% de los casos de prueba arrojaron resultados totalmente satisfactorios

mientras que el 12% de los casos de prueba restantes no fueron fallidos sino que arrojaron

resultados parcialmente exitosos, es decir, presentaron fallas en un porcentaje minoritario de

iteraciones de la prueba.



6. Aceptación del Sistema

Concluida la etapa de pruebas y habiendo obtenido los resultados esperados tanto técnica

como documentalmente, se procede a aceptar formalmente el sistema.

Firma

Aclaración

Fecha



Apéndice A – Casos de Prueba


ID DESCRIPCION CATEGORIA CONDICIONES ENTRADA RESULTADO EVALUACION

CP001 Seguimiento de Circuito Funcional

CP002 Detección de Puesto Funcional

El robot se encuentra en

Ninguna

El robot se detiene en

Exitosamovimiento y el un puesto el puesto, conmuta su se encuentra señalizado estado a modo Sensado y notifica el evento

en el circuito mediante un sonido

CP003

Detección y sorteo de

Funcional


Ninguna

El robot golpea el obstáculomovimiento y un obstáculo hasta liberar el camino pruebas realizadas dependiendose dispone en el circuito.

CP004

Detección de fin de circuito

Funcional


Ninguna

El robot se detiene, conmuta

Exitosamovimiento y el fin del circuito su estado al modo Espera y notifica el evento

mediante un sonidoacorde a lo requerido.

CP005

Sensado de Temperatura

Funcional

El robot se encuentra en modo sensado

Condiciones Ambientales

El robot solicita al sensor

Exitosay Humedad en Puesto de humedad y temperatura

puesto. los valores presentes en el entornoen ese momento

CP006

Almacenamiento de valores

Funcional

El robot ha sensado recientemente Valores de Humedad y El robot almacena los valores obtenidos

Exitosade Humedad y Temperatura las condiciones de humedad y temperatura Temperatura relevados en la memoria interna

relevados del ambiente y aun se encuentra en modosensado

CP006 Inicio forzado FuncionalEl robot se encuentra en modo espera Pulsación del botón de El robot conmuta al modo operativo

Exitosainicio forzado y comienza el recorrido

CP007 Parada forzada FuncionalEl robot se encuentra en modo operativo Pulsación del botón de El robot se detiene y conmuta al modo

Exitosaparada forzada espera.

CP008 Inicio temporizado FuncionalEl robot se encuentra en modo espera y Finalización del El robot conmuta al modo operativo

Exitosael temporizador ha sido configurado en un temporizador y comienza el recorridovalor de prueba de 5 minutos

CP009 Descarga de Información FuncionalEl robot ha concluido su recorrido y se Conexión del robot al puesto El programa descargador informa los

Exitosaencuentra en modo espera de descarga y ejecución valores de temperatura y humedad relevadosdel programa descargador en cada puesto

CP010 Consumo No FuncionalEl robot funciona toda una jornada con el Ninguna

Exitosa

CP011 No FuncionalEl robot opera en condiciones adversas Valores de Humedad y El robot no altera su operatividad

Exitosade temperatura Temperatura fuera delpromedio

El robot dispone de uncircuito que cumple con

la especificación de Requerimientos y se encuentra en

modo operativo

Linea dispuestaen el camino, acorde

a lo requerido}

El robot se desplazapor el circuito siguiendo

la linea dispuesta

Exitosa un 100% cuando no debe enfrentar un obstaculo y un 60% cuando debe hacerlo

Existosa en un 50% de lasun obstaculo

de la ubicación y caracteristicasdel obstaculo

se encuentra proximo y señalizado

como resultado de la deteccion de un

El robot no requiere del reemplazo de bateriasmismo set de baterias

Operación en condicionesadversas


Apéndice B – Matriz de Trazabilidad


Caso de PruebaCP001 CP002 CP003 CP004 CP005 CP006 CP007 CP008 CP009 CP010 CP011

NO REQUIERE UN CASO DE PRUEBA

X X

X

X

X

2.1.1 El sistema debe contener un pulsador de encendido y apagado. NO REQUIERE UN CASO DE PRUEBA

2.1.2 El sistema debe contener un pulsador de arranque y parada de emergencia. X X

X X X

X X X X X

2.1.5 El sistema debe proporcionar un puerto de descarga de la información relevada a una PC. X

X

X

X X X X

1.2.1 La pulsación de un botón físico de Encendido y Apagado provoca la transición del modo Encendido a Apagado y viceversa.

1.2.2 La pulsación de un botón físico de Comienzo y Parada forzada, ubicado en el robot, provoca el cambio de submodo de operación de Espera a Operacional y viceversa.

1.2.3 El sistema debe poseer la capacidad de cronogramar la frecuencia de los recorridos. El temporizador conmutara el submodo de operación del sistema de Espera a Operacional.

1.2.4 La culminación del recorrido planificado provocará que el robot se dirija a una posición de finalización preestablecida donde conmutara el submodo del sistema de Operacional a Espera

1.2.5 El sistema debe ser capaz de identificar el momento en el cual se encuentra en un puesto donde debe realizar la actividad deseada. En ese momento conmutara el submodo de operación a Sensado.

2.1.3 El sistema debe ser capaz de sensar las condiciones de humedad y temperatura de un puesto o invernadero y almacenarla en su memoria para la posterior descarga y análisis de la misma.

2.1.4 El Sistema debe ser capaz de desplazarse de manera autónoma utilizando preferentemente ruedas o cualquier otro tipo de actuadores por un camino regular siguiendo una linea trazada en el mismo o bien ejecutando instrucciones preconfiguradas.

2.1.6 El sistema debe ser capaz de identificar el momento en el cual se encuentra en un puesto donde debe realizar la actividad deseada, detener su marcha y posicionarse de manera apropiada.

2.1.7 Es un requerimiento no excluyente pero deseable que el sistema sea capaz de sortear obstáculos básicos que se le presenten en el camino.

2.1.8 El sistema debe informar la conclusión del relevamiento de un puesto o del recorrido completo mediante un actuador lumínico o sonoro.

RequerimientoCaso de Prueba

CP001 CP002 CP003 CP004 CP005 CP006 CP007 CP008 CP009 CP010 CP011

4.1.1.1 En el submodo Espera debe estar disponible la funcionalidad del botón de comienzo y parada forzada

4.1.1.2 En el submodo Espera debe estar disponible la funcionalidad de Cronograma de Recorridos X X

4.1.1.3 En el submodo Espera debe estar disponible la funcionalidad de descarga de información X

7.2.1 El sistema debe permitir la descarga de datos relevados por el sensor mediante su conexión a una PC X

7.2. 5 Concluido el relevamiento de un puesto, el sistema debe notificar la situación mediante una señal lumínica o sonora. X X X X

X

8.2.1 El sistema debe almacenar los datos obtenidos por el sensor de temperatura X X

8.2.2 El sistema debe analizar las entradas obtenidas por los sensores infrarrojos detectores de linea X X X

8.2.3 El sistema debe analizar las entradas obtenidas por los sensores de ultrasonido X

X X X

X

X X

X

X

13.4.1 El hardware debe estar protegido ante una eventual caída o choque leve del robot. X

7.2. 6 Concluido el recorrido, el sistema debe retornar al punto de partida o bien detenerse en un punto de culminación preestablecido y notificar mediante una señal lumínica o sonora dicha condición.

9.1 El sistema debe analizar las entradas obtenidas por los sensores infrarrojos y enviar una señal a los actuadores para provocar su movimiento en seguimiento de la linea existente en el camino

9.2 El sistema debe analizar las entradas obtenidas por los sensores de ultrasonido y enviar una señal a los actuadores para provocar un movimiento que busque evitar el obstáculo detectado.

9.3 El sistema debe analizar la entrada provista por el usuario mediante la pulsación del botón de Comienzo o Parada forzada y conmutar el submodo de operación entre Espera u Operativo según corresponda.

12. 2.1 Al tratarse de un sistema móvil autónomo, es deseable que el consumo del mismo sea bajo ya que será alimentado por baterías

13.3.1 El sistema debe ser capaz de soportar condiciones ambientales con altos niveles de humedad y en algunos casos temperaturas por debajo o encima del promedio.



Informe de Estado de la Configuración

Versión 1.0





Tabla de Contenidos

1. Introducción

2. Identificación de la Configuración

3. Control de la Configuración

4. Informe de estado de la Configuración.



1. Introducción

A lo largo de este documento, se identifican los aspectos inherentes al proyecto, tanto técnicos

como procedimentales, que estarán sujetos al proceso de control de la configuración (Sección 1), se

describirá la metodología a utilizar para el requerimiento, ejecución y registro de un cambio y por

ultimo se presentara un reporte del estado de la configuración de los ítems sujetos a control.

2. Identificación de la Configuración

En esta sección se identifican los Configuration Items (CI) sujetos al proceso de control de la

configuración según las siguientes categorías: Software, Hardware, Entorno, Procesos y

Documentación. Los mismos serán referenciados en la Planilla de Solicitud de Cambios.

2.1 Software

2.1.1. Diseño

2.1.2. Código Fuente

2.2 Hardware

2.2.1. CI003: Estructura

2.2.2. CI004: Modulo Principal

2.2.3. CI005: Sensores

2.2.4. CI006: Actuadores

2.3 Entorno

2.3.1. CI007: Circuito

2.3.2. CI008: Sistema de Descarga de Información

2.4 Procesos

2.4.1. CI009: Planificación

2.4.2. CI010: Análisis y Diseño

2.4.3. CI011: Implementación y Prueba

2.4.4. CI012: Garantía de Calidad

2.5 Documentación

2.5.1. CI013: Documentos de Usuario



2.5.2. CI014: Documentos internos del proyecto

2.5.2.1. CI015: Planificación

2.5.2.2. CI016: Análisis y Diseño

2.5.2.3. CI017: Implementación y Prueba

2.5.2.4. CI018: Garantía de Calidad

3. Control de la Configuración

Habiendo definido los diversos Configuration Items del proyecto, es preciso establecer una

metodología de control de cambios. La misma fue presentada en el Plan de Gestión de la

Configuración y se describirá con mas detalle a continuación.

La solicitud, planificación y evaluación de cada cambio se registra a través de la Planilla de Control

de Cambios presentada en el Apéndice A del Plan del Proyecto.

3.1 Identificación y Solicitud

Las solicitudes pueden ingresar provenientes de un incidente reportado por los usuarios del sistema,

o bien por una sugerencia de mejora o cambio preventivo presentada en un reporte de

mantenimiento del sistema.

El solicitante debe registrar el cambio en la planilla desarrollada para este fin (Planilla de Solicitud

de Cambios) describiendo diversos aspectos requeridos. A continuación se describen algunos de los

principales campos a completar.

• Identificador: Se asignan códigos identificadores correlativos. Los mismos se componen de

3 letras que reflejan el origen del cambio (INC=Incidente, MEJ=Mejora) y 4 dígitos

numéricos que identifican unívocamente el cambio.

• Información del solicitante: El solicitante provee información de contacto.

• Justificación: Se debe argumentar la necesidad de implementación del cambio.



• Impacto: Se identifican y describen los riesgos inherentes a la no implementación del

cambio.

• Soluciones Alternativas: Se describen al menos 2 soluciones alternativas al cambio

propuesto.

• Riesgos: Se identifican y describen los riesgos inherentes a la implementación del cambio.

• Estimaciones: El solicitante estima los recursos humanos y materiales y el esfuerzo

requerido para la implementación del cambio.

• Origen / Impacto: Se selecciona el origen del cambio según corresponda a un cambio

Correctivo, Preventivo o Evolutivo y se mencionan los aspectos del proyecto que se verán

impactados.

• Configuration Items: Se mencionan los Configuration Items afectados por el cambio.

• Revisión: Un evaluador revisa y aprueba, rechaza o demora el cambio justificando su

elección.

Los campos de la planilla responden a la secuencia temporal de ejecución de las distintas fases del

proceso de Solicitud de Cambio.

3.1 Evaluación y Respuesta

El evaluador debe observar y analizar la información provista por el solicitante y tomar la decisión

mas conveniente para el proyecto; Aprobar, Rechazar o Demorar formalmente el cambio solicitado,

justificando su elección.

3.2 Planificación, Implementación, Prueba y Registro

En caso de ser aprobado el cambio se procede de la siguiente manera:

1. Diseño detallado del Plan de acción



2. Asignación del cambio

3. Cronograma del cambio

4. Notificación del cambio

5. Ejecución

6. Evaluación

7. Notificación de finalización y reporte de Resultados

8. Registro del estado de la configuración en los Configuration Items afectados.

9. Creación y lanzamiento de un nuevo Baseline.

10. Seguimiento durante un periodo determinado

11. Cierre y archivo en el registro histórico del proyecto.

En caso de ser demorado el cambio se procede a su almacenamiento temporal hasta la fecha

establecida donde sera nuevamente evaluado. En caso de ser rechazado, se procede a su archivo

permanente en el registro histórico del proyecto.

4. Informe de estado de la Configuración.

Cualquier cambio solicitado tiene impacto sobre al menos un Configuration Item y es aplicado

sobre un Baseline de modo que, en caso de fallar la implementación sea posible retornar a un estado

productivo de la configuración. Como resultado de este proyecto, se obtiene un primer baseline, el

cual se compone de todos los Configuration Items en su versión inicial.

Un baseline se registra mediante un código identificador, su fecha de puesta en producción, una

breve descripción del mismo y el listado de la totalidad de los configuration Items del sistema con

sus respectivas versiones vigentes. Los datos correspondientes al primer baseline se muestran en la

Tabla 1.



Baseline: BL0001

Fecha de Lanzamiento: 01/03/13

Descripción: Baseline inicial

Configuration Items Versión

2.2 Software

2.2.1. CI001: Diseño

2.2.2. CI002: Código Fuente

2.2 Hardware

2.2.1. CI003: Estructura

2.2.2. CI004: Modulo Principal

2.2.3. CI005: Sensores

2.2.4. CI006: Actuadores

2.3 Entorno

2.3.1. CI007: Circuito

2.3.2. CI008: Sistema de Descarga de Información

2.4 Procesos

2.4.1. CI009: Planificación

2.4.2. CI010: Análisis y Diseño

2.4.3. CI011: Implementación y Prueba

2.4.4. CI012: Garantía de Calidad

2.5 Documentación

2.5.1. CI013: Documentos de Usuario

2.5.2. CI014: Documentos internos del proyecto

2.5.2.1. CI015: Planificación

2.5.2.2. CI016: Análisis y Diseño

2.5.2.3. CI017: Implementación y Prueba

2.5.2.4. CI018: Garantía de Calidad

1.0

1.0

1.0

1.0

1.0

1.0

1,0

1.0

1.0

1.0

1.0

1.0

1.0

1.0

1.0

1.0

1.0

1.0

Tabla 1. Estado de la Configuración

Cada Configuration Item debe especificar su numero de versión y fecha de lanzamiento a fin de ser

identificado.




Informe de Garantía de Calidad

Versión 1.0





Tabla de Contenidos

1. Introducción

2. Revisiones

1. Revisiones Técnicas

1. Fase Análisis y Diseño

2. Fase Implementación y Prueba

2. Revisiones Gerenciales

1. Estimaciones

2. Métricas

3. Sugerencia de Mejora del Software

4. Sugerencia de Mejoras del Hardware

5. Sugerencia de Mejoras del Entorno

6. Sugerencia de Mejoras del Ciclo de Vida

7. Acreditación de Seguridad

8. Auditoría

9. Cierre del Proyecto


Apéndice A – Planilla de Reporte de Problemas



1. Introducción

A lo largo de este proceso se evalúan y auditar los productos generados y los procesos utilizados

durante el proyecto, con el objetivo de garantizar su calidad y detectar posibles mejoras. Este

documento no solo busca garantizar la calidad de este proyecto sino que contribuye a la constante

mejora en los procesos utilizados y como consecuencia, de los productos elaborados.

2. Revisiones

Diferentes tipos de revisiones son llevadas a cabo en diversas etapas del proyecto. Las mismas

tienen como objetivo detectar errores en los productos generados y en los procesos utilizados a lo

largo del proyecto. A continuación se describen las etapas de revisión propuestas para este proyecto

según su categoría y se presentan sus resultados.

2.1 Revisiones Técnicas

Las revisiones Técnicas están destinadas a detectar y corregir errores en las etapas preliminares de

requisitos y diseño, codificación e implementación y prueba del sistema.

A continuación se describen los inconvenientes enfrentados durante las etapas de Análisis y Diseño

e Implementación y Prueba del Proyecto, registrados en la planilla de Reporte de Problemas.

2.1.1 Fase Análisis y Diseño

I001: Durante la etapa de Análisis de requerimientos, se llevo a cabo la asignación de requisitos de

hardware, software y entorno. En esa instancia, fue seleccionada la arquitectura de hardware a a

utilizar (Arduino) y se estableció la necesidad de utilizar, entre otras interfaces, un sensor de

humedad y temperatura aunque no se especifico su modelo. Se estimo que el mismo utilizaría una

entrada analógica pero finalmente requirió de una entrada digital. El error no tuvo consecuencias

técnicas porque el hardware base seleccionado contenía entradas digitales suficientes pero pudo

haberlo ocasionado un problema considerable en la etapa de diseño e implementación.



I002: En las mismas condiciones que las del problema reportado I002, se identifico la necesidad de

utilizar un módulo para el manejo de memorias SDCard, destinado al almacenamiento de los datos

relevados por el sensor de humedad y temperatura.

En la etapa de implementación se enfrentaron inconvenientes técnicos durante la integración y

manejo del módulo adquirido, mediante la utilización de librerías standard. Esta situación fue

prevista en la planificación de riesgos por lo cual se procedió de acuerdo al plan de contingencia;

Comunicarse con el fabricante en búsqueda de asistencia técnica. Como respuesta se obtuvo la

información de que no existen librerías compatibles con Duinobot para el manejo de SDCards.

El inconveniente fue solucionado mediante la utilización de la memoria interna del modulo base.

Esta solución es apta solo para un proyecto de características similares a las actuales y no podría

haber sido implementada en un proyecto productivo, dada la limitación de el tipo de memoria

utilizada (EEPROM) respecto de la cantidad de escrituras y lecturas factibles.

Una solución alternativa es la adaptación a Duinobot de las librerías existentes para Arduino UNO.

2.1.2 Fase Implementación y Prueba.

No se identificaron problemas relevantes durante las etapas de Implementación y Prueba.

A pesar de los inconvenientes descriptos en las puntos anteriores, el proyecto se desarrolló

técnicamente según lo planificado. La especificación de requisitos de hardware, Software y Entorno

fue adecuada y permitió la construcción de un sistema correcto y adecuado a las necesidades del

cliente.

2.2 Revisiones Gerenciales

Las revisiones Gerenciales tienen por objetivo asegurar el progreso del proyecto, un correcto uso de

los recursos y recomendar acciones correctivas. Se han realizado revisiones gerenciales en la

finalización de las etapas de Análisis y Diseño e Implementación y Prueba.

2.2.1 Estimaciones

Durante la fase de Planificación se estimaron los recursos materiales y humanos, costo y esfuerzo

necesario para la realización de este proyecto. A continuación se contrastarán los valores estimados

con los con los obtenidos en la practica.



Tiempo

2.2.1.1 Tiempos

Durante la fase de Planificación se estimo el esfuerzo requerido medido en horas/hombre para la

concreción de las actividades requeridas por el proyecto. A continuación, en la Figura 1, se presenta

la Planilla de Control de Actividades y en la Figura 2 se contrastan los valores estimados en el Plan

del Proyecto con los obtenidos en la práctica, y expresados en la Planilla de Control de Actividades.

Fig 2. Contraste de Estimación de Esfuerzo


FaseHoras Horas

Estimadas RealesPLANIFICACIÓN 36 41

ANALISIS Y DISEÑO 71 53IMPLEMENTACION Y PRUEBA 61 46

GARANTIA DE CALIDAD 26 28

TOTAL 194 168



CONTROL DE ACTIVIDADES

ACTIVIDAD

CO

MIE

NZ

O

FIN

AL

IZA

CIO

N

CA

NT

IDA

D

HO

RA

S

EJE

CU

TO

R

A.1.1.6 Entendimiento del Negocio 12/01/13 12/01/13 2 PONZOJA.1.1.1 Seleccionar un modelo de Ciclo de Vida 12/01/13 13/01/13 16 PONZOJA.1.1.2 Realizar Estimaciones 13/01/13 13/01/13 2 PONZOJA.1.1.3 Asignar Recursos 13/01/13 13/01/13 2 PONZOJA.1.1.4 Definir Métricas 13/01/13 13/01/13 1 PONZOJA.1.3.1 Gestión de Riesgos 13/01/13 13/01/13 1 PONZOJA.1.1.5 Determinar objetivos de Seguridad 13/01/13 13/01/13 1 PONZOJA.4.3.3 Implementación de un método de reporte de problemas 13/01/13 13/01/13 1 PONZOJA.1.2.7 Planificación de la Gestión del Proyecto. 14/01/13 14/01/13 2 PONZOJA.1.2.4 Planificación de la Instalación 14/01/13 14/01/13 2 PONZOJA.1.2.8 Planificación de la Integración 14/01/13 14/01/13 1 PONZOJA.1.2.1 Planificación de la Evaluación 15/01/13 15/01/13 2 PONZOJA.1.2.9 Planificación de la Gestión del Lanzamiento 15/01/13 15/01/13 1 PONZOJA.1.2.2 Planificación de la Gestión de la Configuración 15/01/13 15/01/13 2 PONZOJA.1.2.10 Planificación del Mantenimiento 16/01/13 16/01/13 2 PONZOJA.1.2.5 Planificación de la Documentación 16/01/13 16/01/13 2 PONZOJA.5.1.1 Conducir Revisiones 16/01/13 16/01/13 1 PONZOJ 41A.2.1.1 Identificar ideas o necesidades. 23/01/13 23/01/13 2 PONZOJA.2.1.2 Formular soluciones potenciales. 23/01/13 23/01/13 2 PONZOJA.2.1.3 Conducir estudios de viabilidad. 23/01/13 23/01/13 2 PONZOJA.2.1.4 Refinar y Finalizar la idea o necesidad. 23/01/13 23/01/13 2 PONZOJA.2.2.1 Analizar las funciones del sistema. 24/01/13 24/01/13 4 PONZOJA.2.2.2 Desarrollar la arquitectura del sistema. 24/01/13 25/01/13 4 PONZOJA.2.2.3 Asignar los requerimientos del Sistema 25/01/13 25/01/13 3 PONZOJA.3.1.1 Definir y desarrollar los requisitos del hardware 25/01/13 25/01/13 2 PONZOJA.3.1.2 Definir y desarrollar los requisitos del Interfaces 26/01/13 26/01/13 2 PONZOJA.3.2.3 Selección de la Arquitectura de Hardware mas conveniente. 26/01/13 26/01/13 2 PONZOJA.3.1.3 Definir los requisitos del entorno 26/01/13 26/01/13 3 PONZOJA.3.1.4 Definir los requisitos de software 27/01/13 27/01/13 2 PONZOJA.3.1.5 Integrar los requisitos 27/01/13 27/01/13 1 PONZOJA.3.2.1 Realizar el diseño arquitectónico 07/02/13 07/02/13 4 PONZOJA.3.2.4 Diseñar las interfaces 07/01/13 07/02/13 2 PONZOJA.3.2.5 Realizar el diseño detallado 08/01/13 10/01/13 14 PONZOJA.5.1.1 Conducir Revisiones 10/01/13 10/01/13 2 PONZOJ 53A.3.3.2 Crear el código fuente 11/02/13 13/01/13 14 PONZOJA.3.3.5 Gestionar las versiones del Software 11/02/13 11/02/13 1 PONZOJA.3.3.1 Configurar e integrar el hardware y las interfaces físicas 11/02/13 11/02/13 2 PONZOJA.3.3.4 Realizar la integración 11/02/13 11/02/13 1 PONZOJA.4.1.1 Ajustar parámetros del entorno 13/02/13 13/02/13 1 PONZOJA.4.1.2 Configurar y adaptar interfaces con el entorno productivo y otros sistemas 14/02/13 14/02/13 1 PONZOJA.3.3.3 Crear la Documentación operativa 11/02/13 11/02/13 5 PONZOJA.4.2.1 Operar el sistema 14/02/13 14/02/13 4 PONZOJA.4.2.2 Proveer de asistencia técnica y consultas 14/02/13 14/02/13 0 PONZOJA.4.2.3 Mantener el histórico de peticiones de soporte 14/02/13 14/02/13 0 PONZOJA.5.1.4 Desarrollar Procedimientos de prueba 21/02/13 21/02/13 4 PONZOJA.5.1.2 Crear Matriz de Trazabilidad 22/02/13 22/02/13 3 PONZOJA.5.1.5 Crear datos de prueba 22/02/13 22/02/13 0 PONZOJA.5.1.6 Ejecutar pruebas 22/02/13 23/02/13 5 PONZOJA.1.3.4 Almacenamiento de Registros 22/02/13 22/02/13 1 PONZOJA.5.1.7 Reportar Resultados de la evaluación 22/02/13 22/02/13 2 PONZOJA.4.1.3 Aceptar el producto en el ambiente operativo 22/02/13 22/02/13 1 PONZOJA.5.1.1 Conducir Revisiones 22/02/13 22/02/13 1 PONZOJ 46A.5.2.1 Desarrollar la identificación de la configuración 23/02/13 23/02/13 2 PONZOJA.5.2.2 Realizar el control de la configuración 23/02/13 23/02/13 2 PONZOJA.5.2.3 Realizar la información del estado de la configuración 23/02/13 23/02/13 1 PONZOJA.5.1.1 Conducir Revisiones 24/02/13 24/02/13 1 PONZOJA.4.3.1 Identificación de necesidades de mejora del Software 24/02/13 24/02/13 1 PONZOJA.4.3.2 Identificación de necesidades de mejora del Hardware y Entorno 24/02/13 24/02/13 1 PONZOJA.5.1.8 Confirmar Acreditación de Seguridad 24/02/13 24/02/13 1 PONZOJA.1.2.10 Planificación del Mantenimiento 25/02/13 25/02/13 2 PONZOJ


Fig. 1 Planilla de Control de Actividades

2.2.1.2 Recursos

Durante la etapa de Planificación se estimaron los recursos necesarios para la conclusión exitosa de

las actividades propuestas en el ciclo de vida. A continuación se contrastan los recursos estimados

con los realmente utilizados en la practica.

Fig 3. Validación de Estimación de Recursos

Como puede observarse en la Figura 3, la estimación de recursos fue satisfactoria. Los gastos

efectuados se encontraron dentro del presupuesto.


Recurso Descripción Costo CostoEstimado Real

Kit ROBOT N6 V1.1 $1.700,00 Provisto por2 Sensores IR, 2 Sensores Ultrasonido (Provisto por la Universidad

la Universidad)

2 Sensores IR $100,00 $64,00

$80,00 $60,00de tarjetas micro SD

Cables y Conectores Cables y Conectores necesarios $30,00 $22,00

Necesaria para la generación del código $0,00fuente y la integración del mismo con (Provisto porel hardware el Desarrollador)

Entorno de Prueba Materiales necesarios para el montaje $100,00 $120,00

Kit Arduino, Carcaza, 2 Motores

Sensores IR para deteccion de marcas

1 Modulo MicroSD Modulo Lecto-Grabador

PC/Laptop

A.1.3.5 Recopilación y Análisis de Métricas 24/02/13 24/02/13 2 PONZOJA.1.3.3 Identificación de Mejoras al Ciclo de Vida 25/02/13 25/02/13 1 PONZOJA.5.1.3 Conducir Auditorías PONZOJA.5.3.1 Implementar la Documentación PONZOJA.5.3.2 Producir y Distribuir la Documentación PONZOJA.4.3.4 Iteración del Ciclo de Vida PONZOJA.1.3.6 Cierre del Proyecto PONZOJ 14

TOTAL 154

ACTIVIDAD

CO

MIE

NZ

O

FIN

AL

IZA

CIO

N

CA

NT

IDA

D

HO

RA

S

EJE

CU

TO

R


2.2.2 Métricas

Durante la fase de Planificación también se establecieron las métricas del proyecto.

A continuación se presenta la recolección de las mismas.

Métrica M1: Esta métrica fue implementada con el objetivo de evaluar el desarrollo del proyecto

respecto del tiempo consumido y ajustar la estimación realizada según corresponda. Como puede

observarse en la sección 2.2.1, la estimación de tiempos si bien no fue exacta, se encontró dentro

del rango tolerable por lo que no fue necesario ajustar la estimación en ninguna fase del proyecto.

Podemos inferir a partir del estudio de la Métrica M1 que la fase de estimación de tiempo fue

llevada a cabo correctamente y que el proyecto se desarrollo dentro de los plazos establecidos.

Métrica M2: La métrica M2 fue implementada con el objetivo monitorear la cantidad de obstáculos

y problemas encontrados a lo largo del proyecto ya sea bien en los procesos utilizados como en las

cuestiones meramente técnicas.

Como puede observarse en la Planilla de de Problemas presentada en el Apéndice A, se enfrentaron

una escasa cantidad de inconvenientes en el proyecto y los mismos fueron de una severidad y

complejidad muy baja.

Conclusión: Esta información sugiere que la fase de planificación del proyecto fue llevada a cabo

con un alto nivel de satisfacción.

Métrica M3: Por ultimo la Métrica M3, fue implementada con el objetivo de monitorear las

solicitudes de cambios mediante el control de los registros ingresados en la Planilla de Solicitud de

Cambios. Tras su evaluación, se identifica solo una Solicitud de Cambio, la cual además fue

aprobada y concluida.

Esto permite concluir que las fases previas a la implementación fueron, en un alto porcentaje,

exitosas.



3. Sugerencia de Mejora del Software

A continuación se sugieren mejoras en el Software de Sistema.

1. Optimización de los algoritmos de planificación del desplazamiento a fin de evitar

comportamientos imprevistos.

2. Optimización del algoritmo de sorteo de obstáculos a fin de evitar que el robot se salga de

la pista y no pueda retornar, como consecuencia de las acciones efectuadas para sortear un

obstáculo.

3. Adición de un modulo de re-enrutamiento que permita al Robot volver al circuito en caso de

quedar fuera del mismo como consecuencia de una situación imprevista.

4. Incluir un modulo de configuración del temporizador que permita al usuario seleccionar el

intervalo de tiempo deseado para la espera entro cada ciclo de operación.

5. Adaptar las librerías para el manejo de módulos SDCard, existentes para Arduino, a la

plataforma Duinobot 1.2 a fin de reemplazar el medio de almacenamiento utilizado

actualmente (memoria EEPROM) por tarjetas SDCard. Se recuerda que la utilización de la

memoria EEPROM como medio de almacenamiento de datos provenientes de las

mediciones realizadas por el sensor DHT11 no es recomendada ya que este tipo de memoria

posee un numero finito de ciclos de grabación el cual, tras ser alcanzado, provoca la

necesidad de remplazar chip.

6. Incorporar un modulo de monitoreo del estado de la batería. El desarrollo de hardware

cuenta con un sensor disponible para dicha tarea.

4. Sugerencia de Mejora del Hardware

A continuación se sugieren mejoras en el Hardware del Sistema

1. Una vez adaptadas las librerías para su manejo en Duinobot, incorporar un modulo para el

manejo de memorias SDCard a fin de utilizar esta tecnología para el almacenamiento

permanente de los datos registrados por el sensor de humedad y temperatura DHT11.



2. Incorporar un suplemento de 5cm de largo aproximadamente, para el montaje de los

sensores infrarrojos laterales a fin de evitar cualquier riesgo potencial de posicionamiento de

los mismos sobre la linea central del circuito.

3. Incorporar un suplemento para la fijación del sensor DHT11 y en caso de utilizarse, el

modulo SDCard.

4. Incorporar un modulo display LCD y los pulsadores necesarios para la configuración por

parte del usuario del temporizador del sistema y el relevamiento del estado de la batería del

sistema y la eventual ocurrencia de una falla.

5. Incorporación de un modulo emisor y receptor RF para el monitoreo a distancia de los datos

relevados.

6. Como línea futura de desarrollo, se propone la implementación de una segunda fase de

hardware destinada exclusivamente al control del robot y que permita la programación

remota del mismo a través de una señal WIFI o Bluetooth. Se propone la utilización del

hardware Raspberry Pi con un sistema operativo Linux. Para mas información acerca de la

arquitectura de hardware sugerida, dirigirse al Anexo I del trabajo final de licenciatura,

titulado “Relevamiento de Hardware”

5. Sugerencia de Mejora del Entorno

A continuación se sugieren mejoras en el Entorno de operación del Sistema.

1. Prolongación del largo de las marcas laterales. Actualmente tienen una longitud de 4cm y se

sugieren al menos 7 cm. En caso de que se realice la sugerencia de mejora de hardware

numero 2, se deberán adaptar las marcas laterales en consecuencia.

6. Sugerencia de Mejora del Ciclo de Vida

Por tratarse de una prueba de concepto, el Ciclo de Vida ha sido corregido y refinado iterativamente

con el correr del proyecto. Es por eso que llegada la etapa final del mismo no se sugieren mejoras.



7. Acreditación de Seguridad

Durante la etapa de planificación del proyecto y debido a las características del mismo, no se

plantearon objetivos de seguridad.

Habiendo finalizado exitosamente la etapa de evaluación del sistema, se procede a confirmar la

aptitud del mismo para la operación en el ambiente productivo y a autorizar formalmente su entrega

al cliente.

Firma Aclaración Fecha

8. Auditoría

Como fase final de este proceso de garantía de calidad, se realiza una auditoría interna del proyecto.

Es importante que la misma sea realizada por un área o equipo externo al proyecto.

8.1. Licencias de software y hardware utilizado durante el proyecto

8.2. Licencias de Software y hardware requeridas en el producto desarrollado

8.3. Derechos de propiedad intelectual en el Producto desarrollado

8.4. Acuerdos establecidos con el cliente

8.5. Confidencialidad de la Información del cliente

8.6. Concreción de todas las actividades propuestas en el Ciclo de Vida del Proyecto

8.7. Consistencia de los objetivos a lo largo del proyecto

8.8. Documentación de todos los procesos utilizados en el Proyecto

8.9. Procedimientos existentes para el control de la configuración

8.10. Procedimientos existentes para el reporte y solución de problemas

• Todos los inconvenientes reportados durante el proyecto fueron

solucionados

8.11. Procedimientos existente para la ejecución de revisiones

8.12. Definición y Validación de Métricas



8.13. Realización y Validación de Estimaciones

8.14. Documentación de Pruebas realizadas al sistema

• Todas las fallas detectadas en esta etapa fueron solucionadas

8.15. Aprobación formal por parte del usuario de la Especificación de Requisitos

8.16. Aceptación formal del Sistema por parte del usuario

8.17. Acreditación formal de Seguridad para la operación

8.1. Licencias de Software y Hardware utilizados durante el proyecto.

Las actividades de codificación y documentación del proyecto fueron realizadas utilizando una

Laptop HP ProBook 6455b S/N CNU03800TB con un Sistema Operativo Ubuntu 9.10 open-source

8.2. Licencias de Software y hardware requeridas en el producto desarrollado

El sistema desarrollado esta basado en Arduino; un plataforma de prototipado electrónico open-

source regida bajo licencias Creative Commons que establecen la posibilidad de utilizar y modificar

el el diseño sin ningún tipo de permiso. Para mas información acerca de las licencias Creative

Commons dirigirse a la siguiente URL: http://www.creativecommons.org.ar/licencias

8.3. Derechos de propiedad intelectual en el Producto desarrollado

El sistema desarrollado es el producto de la prueba de concepto de un trabajo final de licenciatura y

no esta prevista su implementación productiva ni distribución.

8.4. Acuerdos establecidos con el cliente

No existen acuerdos preestablecidos con el cliente

8.5. Confidencialidad de la información del cliente

A lo largo del proyecto no se manipula información sensible del cliente y por ello no se a efectuado

ningún acuerdo con el mismo.

8.6. Concreción de todas las actividades propuestas en el Ciclo de Vida del Proyecto

La totalidad de las actividades propuestas en el Ciclo de Vida del Proyecto fueron concluidas.


http://www.creativecommons.org.ar/licencias


8.7. Consistencia de los objetivos a lo largo del proyecto

Los objetivos planteados en las etapas iniciales del proyecto no sufrieron modificaciones a lo largo

del mismo

8.8. Documentación de todos los procesos utilizados en el Proyecto

La totalidad de los procesos ejecutados a lo largo del proyecto fueron debidamente documentados y

generaron los resultados esperados.

8.9. Procedimientos existentes para el control de cambios

El proyecto cuenta con un metodología de control de cambios. La misma puede ser encontrada en el

Plan de Gestión de la Configuración y el Informe del Estado de la Configuración.

8.10. Procedimientos existentes para el reporte y solución de problemas

El proyecto cuenta con una metodología de reporte y solución de problemas. La misma puede ser

encontrada en el Plan del Proyecto.

Todos los inconvenientes reportados a través de dicha metodología fueron solucionados. Para mas

información dirigirse a la Planilla de Reporte de problemas presentada en el Apéndice A.

8.11. Procedimientos existentes para la ejecución de revisiones

El proyecto cuenta con procesos periódicos de revisiones técnicas y gerenciales. Para mas

información dirigirse al Plan del Proyecto y a la sección 2 del presente documento.

8.12. Definición y Validación de Métricas

Durante la etapa inicial del proyecto fueron establecidas métricas. Las mismas fueron validadas en

carácter previo a la conclusión del proyecto. Para mas información dirigirse al Plan del Proyecto y a

la sección 2.2 del presente documento.

8.13. Realización y Validación de Estimaciones

Durante la etapa inicial del proyecto se realizaron estimaciones de recursos y esfuerzo requeridos.

Las mismas fueron validadas en carácter previo a la conclusión del proyecto. Para mas información

dirigirse al Plan del Proyecto y a la sección 2.1 del presente documento.



8.14. Documentación de Pruebas realizadas al sistema

Se ha documentado efectivamente el proceso de evaluación. La totalidad de los defectos

encontrados fueron corregidos. Para mas información dirigirse al Plan del Proyecto y al Reporte de

Evaluación del Sistema.

8.15. Aprobación formal por parte del usuario de la Especificación de Requisitos

El usuario ha provisto formalmente su aprobación respecto de la especificación de requisitos. La

misma fue registrada en el documento Especificación de Requisitos.

8.16. Aceptación formal del Sistema por parte del usuario

El sistema ha sido aceptado formalmente por el usuario. El registro fue efectuado en el Reporte de

Evaluaciones del Sistema.

8.17. Acreditación formal de Seguridad para la operación

El Sistema fue acreditado formalmente para pasar a operación. El registro fue llevado a cabo en la

sección 7 del presente documento.

8. Cierre del proyecto

Concluida la totalidad de las actividades propuestas en el ciclo de vida, se procede a dar cierre

formal al proyecto. Se adjunta la totalidad de los documentos elaborados, el sistema y su código

fuente.



Apéndice A. Planilla de Reporte de Problemas


REPORTE CORRECCION

ID FECHA FASE DESCRIPCION SEGUIMIENTO FECHA DESCRIPCION EJECUTOR FINALIZADO

I001

11/02/13

PONZOJ N/A

11/02/13 PONZOJ

NINGUNA

SI

I002

11/02/13

PONZOJ N/A

11/02/13 PONZOJ SI

I003

03/02/13

PONZOJ

11/02/13 PONZOJ

NINGUNA

SI

PROPIETARIODEL PROBLEMA

SOLUCIONES POTENCIALES

PROPUESTAS DE MEJORA

ANALISIS YDISEÑO

EL SENSOR DE HUMEDAD Y TEMPERATURA DHT11 UTILIZAUNA ENTRADA DIGITAL ENLUGAR DE UNA ENTRADAANALOGICA

UTILIZAR UNA ENTRADADIGITAL DISPONIBLE

UTILIZAR UNA ENTRADA ANALOGICA Y EL CONVERSORANALOGICO DIGITAL

SE UTILIZA LA ENTRADA ANALOGICA S0 COMO ENTRADA DIGITAL

SOLICITUD DE CAMBIO: MEJ001

ANALISIS YDISEÑO

LAS LIBRERIAS PARA EL MANEJO DEL MODULO SDCARD EN ARDUINONO SON COMPATIBLES CON DUINOBOT

ADAPTAR LAS LIBRERIASEXISTENTES

UTILIZAR LA MEMORIAEEPROM

NO ALMACENAR LOSDATOS RELEVADOSSINO VISUALIZARLOSEN TIEMPO REALMEDIANTE EL MONITORSERIAL

SE UTILIZARA LA MEMORIA INTERNA O BIEN EL MONITOR SERIAL.

ADAPTAR LAS LIBRERIASDISPONIBLES PARA ARDUINO A DUINOBOT

IMPLEMENTACIONY PRUEBA

EL SITIO WEB DEL ROBOTGROUP,PROVEEDOR DEL HARDWARE DUINOBOT SE ENCUENTRA FUERA DE SERVICIO

SOLICITAR EL ENVIO DE DOCUMENTACION Y COTIZACION DE SENSORESADICIONALES POR OTRO MEDIO

TRANSCURRIDA UNA SEMANAEL SITIO

CONTINUA INACCESIBLE

SE CONTACTA TELEFONICAMENTEAL PROVEEDOR Y SE COORDINA UNA VISITA PARA RETIRAR LOSPRODUCTOS ADQUIRIDOS.

LA DOCUMENTACION ES ENVIADAPOR CORREO ELECTRONICO

Control de Robots Autónomos Móviles Basados en Arquitecturas de ...

Documents

Transcript of Control de Robots Autónomos Móviles Basados en Arquitecturas de ...