Control de Robots Autónomos: Tesis en Sistemas Embebidos

CONTROL DE ROBOTS AUTÓNOMOS MÓVILES
BASADOS EN ARQUITECTURAS DE SISTEMAS
EMBEBIDOS
Propuesta de Modelo de Aplicación y Uso
Potencial
Alumno
APU Jonatan Matías Ponzo
Director
Mg. Diego Azcurra
TRABAJO FINAL PRESENTADO PARA OBTENER EL GRADO
DE
LICENCIADO EN SISTEMAS
DEPARTAMENTO
DE DESARROLLO PRODUCTIVO Y TECNOLOGICO
UNIVERSIDAD NACIONAL DE LANUS
2013
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.
4.1.1. Generalidades
13
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
i
JONATAN PONZO
INDICE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
ANEXO I – RELEVAMIENTO DE HARDWARE
47
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
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
1. Modelo de requisitos para sistemas embebidos
117
127
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
ii
JONATAN PONZO
INDICE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
iii
JONATAN PONZO
INDICE
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
iv
JONATAN PONZO
INDICE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
Í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
v
JONATAN PONZO
INDICE
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
vi
JONATAN PONZO
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
1
JONATAN PONZO
INTRODUCCION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
2
JONATAN PONZO
INTRODUCCION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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 embebidosy generar mediante su combinación y adaptación, un nuevo modelo de gestión integral de proyectos
destinados al control de Robots Autónomos Móviles basados en Arquitecturas de Sistemas
Embebidos.
Objetivo particular II: Relevar las ASE existentes en el mercado local e internacional focalizando
el análisis en sus características técnicas, físicas y comerciales a fin de crear un perfil de las mismas
y generar una matriz comparativa que permita contribuir en el proceso de Selección del Hardware
óptimo para el desarrollo de la solución requerida.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
3
JONATAN PONZO
INTRODUCCION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
4
JONATAN PONZO
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
INFORMÁTICOS
PROCESOS
PARA
SISTEMAS
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
5
JONATAN PONZO
ESTADO DE LA CUESTIÓN
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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].
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
6
JONATAN PONZO
ESTADO DE LA CUESTIÓN
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
7
JONATAN PONZO
ESTADO DE LA CUESTIÓN
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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].
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
8
JONATAN PONZO
ESTADO DE LA CUESTIÓN
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
Modelo de Requisitos para Sistemas
Embebidos. ABC-BENSOINS-SEM
•
•
Goal-Oriented Patterns for UMLBased Modeling of Embedded
Systems Requirements
•
•
Amplia cobertura de la fase de
•
Ingeniería de Requisitos de
Sistemas Embebidos
Estructura en torno a Categorías y
Sub-categorías que abordan los
requerimientos funcionales y no
funcionales del sistema según su
origen y condición.
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.
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)
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
Carencias
Esquema comparativo de modelos
9
JONATAN PONZO
ESTADO DE LA CUESTIÓN
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
Tabla 2.2. b) Esquema
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
•
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.
comparativo de modelos
10
JONATAN PONZO
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
11
JONATAN PONZO
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?
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
12
JONATAN PONZO
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
13
JONATAN PONZO
SOLUCION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
14
JONATAN PONZO
SOLUCION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
15
JONATAN PONZO
SOLUCION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
16
JONATAN PONZO
SOLUCION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
Documentación de Salida:
▪ Plan de Evaluación
▪ Plan de Gestión de la Configuraciones
▪ Plan de Transición e Informe de Impacto
▪ Plan de Instalación
▪ Plan de Documentación
▪ Plan de Entrenamiento
▪ Plan de Gestión del Proyecto
▪ Plan de Integración
▪ Plan de Gestión del Lanzamiento
▪ Plan de Mantenimiento
▪ Plan de Retiro
Técnicas sugeridas:
▪ WRS (Working Breakdown Structure)
▪ Diagramas PERT y Gantt
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
Documentación de Salida:
▪ Reporte de Riesgos
▪ Reporte de Gestión del Proyecto
▪ Reporte de Necesidades de mejora en el Ciclo de Vida
▪ Registro Histórico de Proyectos
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
17
JONATAN PONZO
SOLUCION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
▪ Reporte de Métricas
▪ Información necesaria para el archivo del Proyecto al
momento de su cierre
Técnicas Sugeridas:
▪ Análisis de Riesgo técnico
◦ Modelización y Simulación Estática y Dinámica
◦ Prototipado
◦ Revisiones y Auditorías
▪ Análisis de Riesgo económico (Finanzas y Retorno de la
Inversión)
▪ Análisis de Riesgo Operativo y de Soporte
▪ Análisis de Riesgo del Programa
◦ Análisis de camino critico CPM
◦ Técnicas de nivelación de recursos
▪ Análisis de riesgo del Hardware. Prototipos
◦ Modelo de ingeniería de requisitos ABC-BesoinsSEM
•
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.
Documentación de Salida:
▪ Informe preliminar de necesidades
▪ Informe de Soluciones potenciales. Análisis de beneficios y
limitaciones
▪ Informe de Viabilidad
▪ Informe de Necesidades
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
18
JONATAN PONZO
SOLUCION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
Técnicas Sugeridas:
▪ Técnicas de Adquisición de Conocimientos
▪ Análisis Económico (Coste/Beneficio)
▪ Análisis Técnico
▪ Análisis de Alternativos
▪ Técnicas de Modelización y Prototipado
▪ Diagramas de Flujos de Datos (DFD)
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
Documentación de Salida:
▪ Descripción Funcional del Sistema
▪ Arquitectura del Sistema
▪ Requerimientos de Hardware del Sistema
▪ Requerimientos Funcionales del Sistema
▪ Requerimientos No Funcionales del Sistema
▪ Requerimientos de Interface del Sistema
▪ Requerimientos del entorno del Sistema
Técnicas Sugeridas:.
▪ Técnicas de Modelización y Prototipado.
▪ Diagramas de Flujo de Datos (DFD).
▪ Modelo de Ingeniería de Requerimientos ABC-BESOINSSEM
▪ 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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
19
JONATAN PONZO
SOLUCION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
4.1.4.3.1.5. Integrar los requisitos
Documentación de Salida:
▪ Informe preliminar de requisitos del sistema
▪ Especificación de requisitos de hardware
▪ Especificación de requisitos de interfaces y entorno
▪ Especificación de requisitos de software
▪ Especificación de requerimientos del sistema
Técnicas Sugeridas:
▪ Técnicas orientadas a los procesos
◦ Modelo de ingeniería de requisitos ABC-Besoins-SEM
◦ Patrones Orientados a Metas para Modelado UML de
Requerimientos de Sistemas Embebidos
◦ Análisis estructurado
•
Diagrama de flujos de datos DFD
•
Diccionario de datos DD
◦ SADT (Structured Analysis and Design Techniques)
•
Diagramas de transición de estados
◦ Actigramas o Diagramas de Actividades
▪ Técnicas formales de especificación
◦ Técnicas orientadas al estado
•
Tablas de decisión
•
Tablas de eventos
•
Tablas de transición
•
Mecanismos de estados finitos
•
Redes de Petri
•
Modelo de ingeniería de requisitos ABCBesoins-SEM
◦ Categoría Disponibilidad de objetos
(estados, eventos)
◦ Categoría Selección de alternativas (modos
y submodos de operación)
▪ Técnicas de prototipado
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
20
JONATAN PONZO
SOLUCION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
Documentación de Salida:
▪ Diseño arquitectónico
▪ Diseño de la base de datos
▪ Diseño de las interfaces
▪ Diseño detallado
Técnicas Sugeridas:
▪ Técnicas orientadas a los procesos
◦ Patrones COBRA para modelos UML y basados en
Metas.
◦ Diagramas de Flujo
◦ Diseño estructurados Análisis de transformación
◦ Análisis de transacción
◦ Diagramas jerárquicos de procesos Warnier
◦ Diagramas de Chapin o Nassi-Schneiderman
▪ Diseño del dialogo de los interfaces
◦ Patrones COBRA para modelos UML y basados en
Metas
◦ Diagramas de Flujo
◦ HIPO (Hierarchy Input Process Output)
◦ Diagramas de Chapin o Nassi-Schneiderman
▪ Técnicas Orientadas a los datos
◦ DFD
◦ Modelos lógicos y físicos de datos
◦ Diagramas jerárquicos Warnier
◦ Diagramas estructurados Jackson
◦ Diagramas de Flujo
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
21
JONATAN PONZO
SOLUCION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
◦ Diagramas Entidad-Relacion
▪ Técnicas orientadas a los objetos
◦ UML
▪ Técnicas de diseño de bajo nivel
◦ Programación estructurada
◦ Diagramas arborescentes
◦ Diagramas de Chapin o Nassi-Schneiderman
◦ Diagramas jerarquicos Warnier
◦ Diagramas estructurados Jackson
▪ Técnicas de prototipado y refinamiento
▪ ANEXO I – Relevamiento de Hardware y ANEXO II –
Matriz Comparativa (selección del hardware apropiado)
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
Documentación de Salida:
•
Código fuente
•
Especificación de Software
•
Especificación de Hardware
•
Base de datos (si aplica)
•
Documentación operacional
•
Paquete del producto lanzado
Técnicas Sugeridas:
•
Lenguajes de programación
•
Herramientas de versionado de software
•
Entornos de modelado de Bases de Datos
•
Entorno de Programación del hardware seleccionado
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
22
JONATAN PONZO
SOLUCION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
Documentación de Salida:
▪ Reporte de Instalación y operación del Sistema
▪ Reporte del estado de la configuración
▪ Informe de aceptación del software por parte del usuario
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
Documentación de Salida:
▪ 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
Documentación de Salida:
▪ Sugerencia de mejoras al software
▪ Sugerencia de mejoras del hardware
▪ Reporte de anomalías
▪ Reporte de corrección de anomalías
▪ Recomendaciones de Mantenimiento
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
23
JONATAN PONZO
SOLUCION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
Documentación de Salida:
▪ 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
Documentación de Salida:
▪ Resultados de revisión en-proceso
▪ Reporte de revisión Post-implementacion
▪ Recomendación de mejoras en los procesos
▪ Reporte de estado de la gestión
▪ Reporte de análisis de trazabilidad
▪ Reporte de cambios en la asignación del sistema
▪ Matriz de Trazabilidad
▪ Reporte de Auditoría
▪ Plan de Prueba (Procedimientos y datos)
▪ Sumario de Pruebas
▪ Reporte de Evaluación
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
24
JONATAN PONZO
SOLUCION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
Técnicas Sugeridas:
▪ Técnicas de prueba de caja blanca
◦ Cobertura de sentencias
◦ Cobertura de decisión o ramificación
◦ Cobertura de condición
◦ Cobertura de decisión/condición
◦ Cobertura de condición múltiple
▪ Técnicas de prueba de caja negra
◦ Partición de equivalencias
◦ Análisis de valores limites
◦ Gráficos causa-efecto
◦ Conjetura de errores
▪ Revisiones formales
▪ Auditorías
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
Documentación de Salida:
▪
4.1.4.5.3.
Reporte de Identificación de la Configuración
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 de Salida:
▪ 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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
25
JONATAN PONZO
SOLUCION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
Documentación de Salida:
▪ 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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
26
JONATAN PONZO
SOLUCION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
27
JONATAN PONZO
SOLUCION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
28
JONATAN PONZO
SOLUCION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
29
JONATAN PONZO
SOLUCION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
Mediante esta actividad y con base en la asignación de requisitos se definen los requisitos de
hardware del proyecto.
4.1.5.3.1.3. Definir los requisitos del entorno
Mediante esta actividad y con base en la asignación de requisitos se definen los requisitos de
entorno del proyecto.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
30
JONATAN PONZO
SOLUCION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
4.1.5.3.1.4. Definir los requisitos de interfaz
Mediante esta actividad y con base en la asignación de requisitos se definen los requisitos de
Interfaz del proyecto tanto con el usuario y el entorno como con otros sistemas.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
31
JONATAN PONZO
SOLUCION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
32
JONATAN PONZO
SOLUCION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
33
JONATAN PONZO
SOLUCION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
34
JONATAN PONZO
SOLUCION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
35
JONATAN PONZO
SOLUCION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
36
JONATAN PONZO
SOLUCION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
37
JONATAN PONZO
SOLUCION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
38
JONATAN PONZO
SOLUCION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
39
JONATAN PONZO
SOLUCION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
Selección
de un modelo
de ciclo de vida
Modelo de Ciclo de Vida
Creación del
Ciclo de vida
del proyecto
Ciclo de Vida y Mapa de Actividades
Secuencia de
Actividades
Secuencia de Actividades
Asignación de
documentos
Inicio del Proyecto
Figura 4.1.
Mapa de
Documentos
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
40
JONATAN PONZO
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
INSPECCION DE CULTIVOS EN INVERNADERO
CONCEPTO:
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
41
JONATAN PONZO
PRUEBA DE CONCEPTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
42
JONATAN PONZO
PRUEBA DE CONCEPTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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, PreDesarrollo, 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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
43
JONATAN PONZO
PRUEBA DE CONCEPTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
44
JONATAN PONZO
PRUEBA DE CONCEPTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
45
JONATAN PONZO
PRUEBA DE CONCEPTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
46
JONATAN PONZO
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 UMLBased
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
47
JONATAN PONZO
REFERENCIAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
IEEE (2006) Software Engineering Standards Committee of the IEEE Computer Society (2006).
IEEE Standard for Developing Software Life Cycle Processes.
IEEE (2013) Software Engineering Standards Committee of the IEEE Computer Society (1990).
URL 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://desarrollodesoftwarejorgepelaez.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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
48
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES
BASADOS EN ARQUITECTURAS DE SISTEMAS
EMBEBIDOS
Propuesta de Modelo de Aplicación y Uso Potencial
Jonatan Ponzo - [email protected]
Universidad Nacional de Lanús – Lic. Sistemas
ANEXO I – RELEVAMIENTO DE HARDWARE
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
49
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
50
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
51
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
52
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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).
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
53
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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].
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
54
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
55
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
56
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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,
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
57
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
58
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
59
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
60
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
Memoria (SDRAM):
1080p30 H.264
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
61
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
•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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
62
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
63
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
•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 externallyaccessibleSR 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
# of Cores
# of Threads
Clock Speed
L2 Cache
Bus/Core Ratio
FSB Speed
FSB Parity
Instruction Set
Instruction Set Extensions
Embedded Options Available
Supplemental SKU
Lithography
Max TDP
VID Voltage Range
Z510
1
1
1.1 GHz
512 KB
11
400 MHz
No
32-bit
SSE2, SSE3, SSSE3
Yes
No
45 nm
2W
0.75-1.1V
Z530
1
2
1.6 GHz
512 KB
12
533 MHz
No
32-bit
SSE2. SSE3, SSSE3
Yes
No
45 nm
2W
0.75 -1.1V
Tabla 2. Especificaciones técnicas de los procesadores Atom Z510 y Z530
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
64
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
65
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
La placa puede operar con un voltaje de alimentación desde 6v a 20v pero el rango recomendado es
de 7v a 12v.
Fig. 7. Diagrama Arduino UNO
Los PINs de alimentación son los siguientes:
•VIN: Permite alimentar la placa o utilizar la tensión de alimentación provista a través del
conector.
•5V: Salida de tensión regulada 5V. .
•3V3: Salida de tensión regulada de 3.3V x 50 mA.
•GND: Tierra.
A continuación un cuadro comparativo de los niveles de tensión manejados por los 3 modelos de
Atmega soportados por Arduino en sus diversos modelos siendo 328 correspondiente a Arduino
UNO.
Atmega168
Voltaje operativo
Voltaje de entrada
recomendado
Voltaje de entrada
límite
Atmega328
Atmega1280
5V
(Arduino UNO)
5V
7-12 V
7-12 V
7-12 V
6-20 V
6-20 V
6-20 V
5V
Tabla 3. Niveles de tensión manejados por los procesadores Atmega
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
66
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
3.2. PIC - ICP05 IBOARD LITE
La placa provee tensiones de 5V y 3.3V seleccionables para el microcontrolador PIC.
Sus dimensiones son muy pequeñas, tan solo 10cm x 5.5cm tornándolo ideal para aplicaciones
móviles o en espacios reducidos.
El PIC PIC16F722 posee un rango de voltaje de operación de 1.8V – 3.6V y admite un rango de
temperaturas de -40°C - 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.
Consumo energético:
Modelo A
Modelo B
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
67
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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].
3.5. PC/104 - PIC MICROSTACK
La placa MicroStack puede ser alimentada a través de una fuente externa de 5V o bien a través de
un cable USB y su conexión a cualquier PC y entrega un rango de tensiones de entre 5V y 3.3V.
Sus medidas son 65mm x 80mm y su altura 16mm
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
68
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
3.7. PC/104 - COOL LITERUNNER-LX800
Este es un desarrollo de similares características al anterior, sus medidas responden al Standard
PC/104, 96mm x 90mm (3.775” x 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.
3.8. PC/104 - COREMODULE 435
Completando los desarrollos PC/104 encontramos condiciones similares en el CoreModule 435 el
cual implementa un micro Vortex86DX.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
69
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
70
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
4.1. ARDUINO UNO
El micro controlador ATmega328 posee 32 KB de memoria de los cuales 0.5KB están destinados al
bootloader o sector de arranque, 2 KB de SDRAM y 1 KB de EEPROM integrados en el mismo
chip lo cual evita en la mayoría de los casos la necesidad de utilizar almacenamiento externo
requerido por algunas aplicaciones [9].
Memoria de Programa
Las instrucciones del programa son almacenadas en la memoria Flash. Aunque la MCU es de 8 bits,
cada instrucción puede tomar una o 2 palabras de 16 bits.
El tamaño de la memoria de programa usualmente forma parte de la nomenclatura del dispositivo,
Por ej. la linea Atmega64x posee 64kb de memoria Flash [9].
Memoria de Datos
El espacio de direccionamiento de datos consiste en registros de archivo, registros de I/O y SRAM.
Registros Internos
Los microcontroladores de la familia AVR poseen 32 registros de trabajo de 8 bits cada uno. En
muchas ocasiones son mapeados en las primeras 32 posiciones de memoria y seguidos de los 64
registros correspondientes a I/O [9].
EEPROM
Casi todos los micro controladores AVR poseen una memoria EEPROM destinada al
almacenamiento semi-permanente. Al igual que la Flash, la memora EEPROM es no volatil.
En muchos casos, la memoria interna EEPROM no se encuentra mapeada dentro del espacio de
direccionamiento de la MCU y por ello puede ser solamente accedida de la misma manera que una
memoria externa. La memoria SDRAM es utilizada para el almacenamiento temporal de datos [9].
Atmega168
Memoria Flash
SRAM
EEPROM
16KB (2KB reservados
para el bootloader)
1 KB
512 bytes
Atmega328 (Arduino
UNO)
32KB (2KB
reservados para el
bootloader)
2 KB
1 KB
Atmega1280
128KB (4KB reservados
para el bootloader)
8 KB
4 KB
Tabla 5. Tamaño de memorias en los procesadores Atmega
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
71
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
72
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
73
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
4.5. PC/104 - PIC MICROSTACK
La arquitectura responde a la de PIC. La cantidad de memoria de datos y programa varía según el
PIC elegido.
El PIC16F887 posee una memoria de programa Flash de 14Kb, una memoria RAM de 368Bytes y
una memoria de datos EEPROM de 256Kb.
4.6. PC/104 - COOL LITERUNNER-ECO
Al igual que Raspberry Pi, Cool LiteRunner-ECO ejecuta el sistema operativo desde una memoria
µSD booteable. Además posee una memoria RAM de 2GB DDR2 (tamaño variable según
preferencia) soldada a la placa y su micro posee una cache de nivel 1 de 32KB para instrucciones y
una de nivel 2 de 512 Kb.
El Procesador posee un nivel de cache primario de 32KB para instrucciones y 24KB para datos y un
nivel secundario de 512KB 8-way set associative.
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.
4.8. PC/104 - COREMODULE 435
La placa implementa los procesadores Vortex86SX 300MHz y Vortex86DX 800MHz. Los mismos
poseen una Cache 16kB I-cache, 16kB D-cache.
La placa posee una memoria RAM DDR2 de 256MB soldada y un puerto para conectar
almacenamiento CompactFlash y 2 interfaces PATA DMA 100 IDE capaces de soportar hasta 2
discos rígidos.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
74
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
5.
INTERFACES
DISPONIBLES
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
Y
PUERTOS
DE
ENTRADA/SALIDA
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(813). 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;
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
75
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
76
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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).
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
77
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
System-on-a-chip o SoC (también referido como system-on-chip), describe la tendencia cada vez
más frecuente de usar tecnologías de fabricación que integran todos o gran parte de los módulos
componentes de un ordenador o cualquier otro sistema informático o electrónico en un único
circuito integrado o chip. El diseño de estos sistemas puede estar basado en circuitos de señal
digital, señal analógica, o incluso de señal mixta y a menudo módulos o sistemas de radiofrecuencia (módulos de comunicación inalámbrica: Wi-Fi, Bluetooth, etc.) [38].
Modelo A
1
Conector RCA,
Puertos USB 2.0:
Salidas de vídeo:
Salidas de audio:
Conectividad de red:
Periféricos de bajo
HDMI
3.5 mm jack, HDMI
Ninguna
Pines GPIO, SPI, I²C,
nivel:
UART26
Modelo B
2 (vía hub USB integrado)
Conector RCA, HDMI
3.5 mm jack, HDMI
RJ45
Pines GPIO, SPI, I²C, UART26
Tabla 6. Puertos de entrada y salida disponibles en los modelos A y B de Raspberry Pi
A diferencia del modelo A, el modelo B incorpora un segundo puerto USB2.0 y un puerto de red
10/100 Base T. Si bien aún no se ha integrado un modulo WiFi, existe la posibilidad de utilizar un
adaptador WiFi USB. A continuación una lista detallada de los puertos de entrada y salida presentes
en Raspberry Pi Modelo B:
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
78
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
•
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)
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
79
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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 submódulos de circuitos integrados, y es muy útil también como mecanismo para depuración de
aplicaciones empotradas, puesto que provee una puerta trasera hacia dentro del sistema. Cuando se
utiliza como herramienta de depuración, un emulador en circuito que usa JTAG como mecanismo
de transporte permite al programador acceder al módulo de depuración que se encuentra integrado
dentro de la CPU. El módulo de depuración permite al programador corregir sus errores de código y
lógica de sus sistemas [40].
Periféricos de Bajo Nivel
Además de los ya conocidos puertos USB, Ethernet y HDMI, Raspberry Pi ofrece una serie de
interfaces de bajo nivel diseñadas para conectar al mismo de manera más directa con otros chips o
módulos. Esta GPIO (I/O de propósito general) es capaz de controlar LEDs, servo motores y otros
componentes electrónicos.
I/O de Propósito General (GPIO)
Las GPIO se presentan en forma de PINs genéricos cuyo comportamiento, incluyendo su condición
de entrada o salida, puede ser programada a través del software.
La Raspberry Pi permite a los periféricos y los módulos de expansión acceder a la CPU a través de
estos PINs. Los mismos se presentan el la placa en un cabezal de expansión de 26 pines distribuidos
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
80
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
5.4. FREESCALE – EDUKIT08
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
81
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
• 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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
82
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
• 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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
83
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
5.6. PC/104 - COOL LITERUNNER-ECO
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
5.7. PC/104 - COOL LITERUNNER-LX800
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
84
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
•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
5.8. PC/104 - COREMODULE 435
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
85
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
•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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
86
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
•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
6.3. FREESCALE – EDUKIT08
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
87
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
88
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
89
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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:
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
90
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
91
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
• 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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
92
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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).
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
93
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
• 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,
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
94
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
95
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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)
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
96
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
• 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)
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
97
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
98
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
99
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
•PrimerLabs CodeHero
Lenguajes orientados a Robótica:
•Lego Mindstorms
•Kturtle and other Logo/turtle graphics (The IO board supports motor drive outputs)
7.4. FREESCALE – EDUKIT08
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
100
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
• 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]
7.5. PC/104 - PIC MICROSTACK
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.
7.6. PC/104 - COOL LITERUNNER-ECO
Sistemas Operativos soportados: Windows XP, XP Embedded, Windows CE, Linux, DOS
7.7. PC/104 - COOL LITERUNNER-LX800
Sistemas Operativos soportados: Windows XP, XP Embedded, Windows CE, Linux, VxWorks
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
101
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
7.8. PC/104 - COREMODULE 435
Sistemas Operativos soportados:: QNX v6.3; Windows CE 5.0, 6.0
8. DISPONIBILIDAD EN EL
INTERNACIONAL Y COSTOS.
MERCADO
LOCAL
E
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
102
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
•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.
8.2. PIC - ICP05 IBOARD LITE
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-lcddevelopment-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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
103
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
•
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 ElectroComponentes. 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]
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
104
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
105
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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€
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
106
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
• 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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
107
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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/
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
108
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
109
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
110
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
111
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
112
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
11. REFERENCIAS
1. Arduino,
2012.
Interfacing
with
Other
http://www.arduino.cc/playground/Main/InterfacingWithSoftware
Pagina
Software.
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
http://ww1.microchip.com/downloads/en/DeviceDoc/39630C.pdf.
Pagina
Solutions.
Vigente
al
26/09/12.
11. Microchip,
2009.
PIC16F722
http://ww1.microchip.com/downloads/en/DeviceDoc/41341E.pdf.
Datasheet,
Pagina
Vigente
al
26/09/12.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
113
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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/CoolLiteRunnerECO/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/CoolLiteRunnerLX800/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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
114
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
21. Power
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
Pagina vigente al 26/09/2012
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.
Pagina vigente al 26/09/2012
31. Shiffman, Daniel. 2009. Interview with Casey Reas and Ben Fry.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
115
JONATAN PONZO
ANEXO I – RELEVAMIENTO DE HARDWARE
32.
Wikipedia,
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
2012.
Microcontrolador
http://es.wikipedia.org/wiki/Microcontrolador_PIC#Referencias.
Pagina
PIC.
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.
Pagina vigente al 26/09/2012
36.
Wikipedia, 2012. Arquitectura ARM. http://es.wikipedia.org/wiki/Arquitectura_ARM.
Pagina vigente al 26/09/2012
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.
Pagina vigente al 26/09/2012
40.
Wikipedia, 2012. JTAG. http://es.wikipedia.org/wiki/JTAG. Pagina vigente al 26/09/2012
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
116
JONATAN PONZO
ANEXO II – MATRIZ COMPARATIVA
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES
BASADOS EN ARQUITECTURAS DE SISTEMAS
EMBEBIDOS.
Propuesta de Modelo de Aplicación y Uso Potencial
Jonatan Ponzo - [email protected]
Universidad Nacional de Lanús – Lic. Sistemas
ANEXO II – MATRIZ COMPARATIVA
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
117
JONATAN PONZO
AVR Atmel
PIC
ARM
Freescale
Arduino UNO
iBoard Lite
Raspberry Pi B
EDUKIT08
ARM 1176JZF-S 32bits
SoC Broadcomm BCM2835
MC908AP32CFBE 8 bits
AVR Atmega328 8bits
PICs 28 Pins
PIC16F722 8bits
Arquitectura
Harvard – RISC
Harvard
RISC
CISC
Frecuencia
20 Mhz
16 MHz – 5 MIPS
8 MHz
Cache
-
-
700 MHz
L1 Cache 32Kb (Instr.)
L2 Cache 128Kb (GPU)
85.60mm × 53.98mm <40g
210 mm x 160 mm
Dimensiones
2.7' x 2.1'
10cm x 5.5cm
Rangos de Temperatura
-40°C y 85°C
-40°C - 125°C
-
-
Rangos de Tensión
1.8V – 5.5V
3.6v – 6v
5V USB – Fuente externa
7 a 16V
Alimentación
6v-20v / Recom 7v-12v
9V Recomendado
USB – Fuente externa
Consumo
30MA+
25mA+
700mA 3.5W
-
Memoria de Programa
32Kb Flash
3.5KB Flash
MicroSD Slot
32 Kb Flash
Memoria de Datos
2Kb SDRAM
128 bytes RAM
256MB DDR2
2KB RAM
Registros Internos
32 x 8bits
-
-
-
Almacenamiento Pte.
1KB EEPROM
-
MicroSD Slot
EEPROM (24LC256)256Kb
Microcontrolador
5V USB – Fuente externa
-
5V USB – Fuente Externa
Puertos E/S
AVR Atmel
PIC
Arduino UNO
iBoard Lite
*14 PINs E/S Dig Prog
5v x 40mA TTL, PWM
*1 x USB
*2 PINs Serial
*6 PINs Ent Analogicas
UART TTL – Serie via USB
Comunicación
Módulos de expansión
Modo de programación
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
USB (Arduino Soft)
ICSP MPLAB
ICSP
Display LCD in
IO x 8 canales
8 canales analógico
Servo motores x 4
Mot. PaP ULN2003A
500mA Darl. x 1
Mot. DC L293D x 1
Conv Boost/Buck x 1
SPI/I2C/USART/PS2/USB
ICM07A - 4X3 KEYPAD
ICP01 - USB PIC PROGRAMMER
ICM17 - ULN2003A DRIVER
CODE01 TIMER/TEMPERATURE DISP
ICA05 - GRAPHIC LCD DEV KIT
ICM25 – PS/2 PORT
ARM
Freescale
Raspberry Pi B
EDUKIT08
Micro USB
DSI x 15-PINs
HDMI
Video Composite RCA
MIPI CSI-2 de 15 PINs.
Audio Stereo de 3.5mm
SD/MMC/SDIO
2x USB 2.0
26-pin TTL UART GPIO
ARM JTAG
2 x I2C
8-pin GPU JTAG
7-pin LAN9512 JTAG
TP1/TP2 +5V/GND
RS-485 Master / Slave
IRDA / SIR
LCD 16 carac x 2 líneas
LED de 4 díg x 7 seg
4 pulsadores
Diodos LEDs
Diodo LED de potencia
Sensor Temperatura (LM335Z)
Preset p/ conversor A/D
I/O de propósitos grales
IRQ e interface SPI
Ethernet 10/100Mb RJ45
WiFi via Dongle USB
UART RS-232C/RS-485/IRDA
Heber x10i I/O USB
AFLEX DC Motores
GELI 'jelly' DC Motores
aLaMode Clon Arduino
PiBorg PaP Motores
Pi232 RS232 board
Relay board
MiniPiio L293D H-Bridge
MiniPiio DIO16 I/O Dig
MiniPiio 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.
WinIDE
CodeWarrior 5.x/6.x
ICC08 de Imagecraft
Cosmic Compiler
ICSP MPLAB
Carga externa de MicroSD
Lenguajes soportados
Programación Gráfica
AVR Atmel
PIC
ARM
Freescale
Arduino UNO
iBoard Lite
Raspberry Pi B
EDUKIT08
Arduino (Processing)
Java
Flash
C#
Perl
Python
Ruby
Pduino y Minibloq
Assembler
C
BASIC.
PASCAL
Forth
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.06B
PICAT 1.25 (USB2.0)
WinPic 800 paral/seriE/USB)
PICKit 2 (USB)
PICKit 3 (USB)
Terusb1.0
Eclipse (PICs y AVRs. USB.)
MasterProg (USB)
Gcc, Clojure
g++
Interp
Mono (C#)
OCaml
NodeJS 0.6.18 (Jscript)
Perl
Python
Ruby 1.9.2 (KidsRuby)
Scala
Java
Eclipse
Tcl/Tk
Lazarus
(maybe) BoaConstructor
Anjuta for C/C++
Dev-C++
CodeBlocks
Lua
BBC BASICJ
mdfs.net
ROOL
Small Basic
Squeak (Smalltalk)
Processing
basic256
bwbasic
sdlbasic
yabasic
Regina Rexx
GalaxC
Gambas
Scratch
Alice
Android App Inventor
Kodu
Star Logo
PrimerLabs CodeHero
Assembler, C
WinIDE
CodeWarrior 5.x/6.x
ICC08 de Imagecraft
Cosmic Compiler
AVR Atmel
PIC
Arduino UNO
iBoard Lite
ARM
Freescale
Sistemas Operativos
Windows, Linux y MacOS
Windows, Linuxm MacOS
Raspberry
Pi B
Arch Linux
ARM
Debian 6.0 (Squeeze)
Gentoo Linux
Google Chrome OS
Puppy Linux
Raspberry Pi Fedora Remix
Raspbian (Wheezy port)
RiscOS
Slackware ARM
QtonPi (embedded Linux)
Squeezed Arm Puppy ARMv6
IPFire
OpenELEC
Raspbmc (Media Center)
XBMC (Media Center)
Disponibilidad local
SI, < 5 días hábiles
NO
NO
SI
Costo local
$ 257.81 IVA Incluido
-
U$S240+IVA
Costo Internacional
U$S 25 + U$S7(Envío,Imp)
U$S 40 + envío 6U$S
U$S42
Imp y Envío Incluido
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
Multiplataforma
Open Hardware
Open Software
Escalabilidad
Diversidad de disp I/O
Amplia documentación
Fácil Programación
Gran Comunidad
Dimensiones reducidas
Bajo costo
Diversidad de disp I/O
Compatibilidad PICs 28PINs
Bajo Costo
Dimensiones reducidas
Interfaces MultMedia HD
Gran Comunidad
Simplicidad de programación
Amplia documentación c/ejem
Soporte técnico local
Comercialización local
Diversidad de I/O on board
Orientación Educativa
Industria
Docencia
Servo Motores
Sensores
Industria
Control de motores DC
Medición, registro y control
de condiciones ambientales
Monitoreo de señales
Visualización de gráficos
Dispositivos de seguridad
Docencia/investigación
Automatización de Hogares
Servicios de Internet
Media Center
PC Portatil
Aplicaciones posibles
EDUKIT08
Windows
-
Educación
Prototipado
PC/104
PIC MicroStack
Cool LiteRunner ECO
Cool LiteRunner LX800
CoreModule 435
PICs 40 Pins
PIC16F887 – 8bits
Intel Atom Z510-Z530
32bits
AMD LX800 32bits
Microcontrolador
Vortex86SX - 86DX
32Bits
Arquitectura
Harvard
x86
x86
x86
Frecuencia
8Mhz
-
500MHz
L1 Cache 64Kb
L2 Cache 128Kb
300MHz – 800MHz
Cache
1.1GHz – 1.6GHz
L1 Cache 32Kb (Instr)
L2 Cache 512Kb
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°C
Extendido: -40°C - +85°C
Almacenamiento: -55°C - +85°C
L1 Cache 16Kb
Dimensiones
Rangos de Temperatura
-
Rangos de Tensión
-
4.75v – 5.25v
4.75v – 5.25v
4.75v – 5.25v
Alimentación
5V USB – Fuente Externa
5V ±5 % Fuente externa
5V ±5 % Fuente externa
5V ±5 % Fuente externa
Consumo
-
11W
5W – 6W
6.5W
Memoria de Programa
14Kb Flash
MicroSD Slot
MicroSD Slot
MicroSD Slot
Memoria de Datos
368 Bytes
2GB DDR2 exp.
DDR400 de 256Mb 400MHz Exp
RAM DDR2 de 256MB exp.
Registros Internos
-
-
-
MicroSD Slot, 2 x SATA
MicroSD Slot
IDE UltraATA100
CompactFlashTM
MicroSD Slot
PATA DMA 100 IDE x 2 HDD
Storage CompactFlash socket
Almacenamiento Pte.
EEPROM 256Kb
PC/104
PIC MicroStack
Cool LiteRunner ECO
Cool LiteRunner LX800
CoreModule 435
2 x USB
Puerto PC/104 (ISA)
VGA and LVDS (c/ backlight)
2 x SATA
7 x USB 2.0 hosts
HD Audio
I/O Signals 8 GPIO
Mini PCI Express 1 slot
ISA Bus PC/104
4 x USB 2.0
IDE Ultra ATA100
CompactFlashTM socket
Mini-PCI slot
CRT VGA
1920x1440 85HZ
TFT S/CH
18 bits 1600x1200 60Hz
LVDS S/CH
18/24 bits 1600x1200 60Hz
Audio AC97 2.1 2CH
LPT bi-directional
PS2 Keyboard, mouse
GPIO x 8
ISA Bus PC/104
PCI Bus Mini-PCI slot
I2C bus Supported
UART
2 x Gigabit LAN
2 x RS232/RS422/RS485
2x 100/10 BaseT Ethernet
S2 x RS232/RS422/RS485
1 x RS485/Irda
PC/104 ISA
PATA DMA 100 IDE
Storage CompactFlash socket
USB 2x USB 2.0 ports
KB/MS PS/2 interface
8 x GPIO digital I/O PINs
1 x VGA Video Interface
100MHz/1600x768/32MB/64MBDDR2
TTL/TFT D/C 12-bit S/C 18-bit
1 x Ethernet 10/100
1 x Ethernet Intel 82451PI
1 x Gigabit Ethernet
2x RS-232
2x RS-232/422/485
Módulos de expansión
MiniModule SIO
PCM-MIO-G
Cualquier Modulo PC/104
Idem F
Idem F
Idem F
Modo de programación
Mecanique Microcode Loader
ICSP MPLAB
Carga externa de MicroSD
Carga externa de MicroSD
Carga externa de MicroSD
Puertos E/S
Comunicación
PC/104
PIC MicroStack
Cool LiteRunner ECO
Cool LiteRunner LX800
CoreModule 435
Assembler
C
BASIC.
PASCAL
Forth
Depende del SO
Depende del SO
Depende del SO
Depende del SO
Depende del SO
Depende del SO
Lenguajes soportados
Programación Gráfica
Mecanique Microcode Loader
ICSP MPLAB
PC/104
PIC MicroStack
Cool LiteRunner ECO
Cool LiteRunner LX800
CoreModule 435
Sistemas Operativos
Windows
(MPLab, MML)
XP, XP Embedded, Windows CE
Linux
DOS
Windows XP
XP Embedded
Win CE
Linux, VxWorks
Supported QNX v6.3
Windows CE 5.0, 6.0
Disponibilidad local
SI
BAJA, Microtec
BAJA, Microtec
BAJA, Microtec
Costo local
~U$S103
Desconocido
Desconocido
Desconocido
Costo Internacional
U$S73 + U$S20 Envio e Imp
$494.00/$529.00/$713.00
$633.00/$686.00/$892.00
$792.00/$858.00/$1116.00
Tiempo de entrega
~15 días hábiles
~15 días hábiles
~15 días hábiles
~15 días hábiles
Dimensiones Reducidas
Bajo Costo
Compatibilidad PICs 40 PINs
Compatibilidad Std PC/104
Diversidad de modulos exp.
Disponibilidad Local
Fuertemente Industrial
Control de maquinas
Instrumental médico
Telecomunicaciones
Equipamiento de diagnostico
Manejo remoto de redes
Sistemas de seguridad
Sistemas de medición
Poder de Procesamiento
Memoria Ram
Bajo Costo
Fuertemente Industrial
Control de maquinas
Instrumental médico
Telecomunicaciones
Equipamiento de diagnostico
Manejo remoto de redes
Sistemas de seguridad
Sistemas de medición
Diversidad de Ifaces I/O
Bajo Consumo
Fuertemente Industrial
Control de maquinas
Instrumental médico
Telecomunicaciones
Equipamiento de diagnostico
Manejo remoto de redes
Sistemas de seguridad
Sistemas de medición
Diversidad de Ifaces I/O
Bajo Consumo
Fuertemente Industrial
Control de maquinas
Instrumental médico
Telecomunicaciones
Equipamiento de diagnostico
Manejo remoto de redes
Sistemas de seguridad
Sistemas de medición
Principales virtudes
Aplicaciones posibles
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES
BASADOS EN ARQUITECTURAS DE SISTEMAS
EMBEBIDOS
Propuesta de Modelo de Aplicación y Uso Potencial
Jonatan Ponzo - [email protected]
Universidad Nacional de Lanús – Lic. Sistemas
ANEXO III – MODELOS DE PROCESOS PARA SISTEMAS INFORMATICOS
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
127
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
128
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
129
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
130
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE 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
1. Estados
Disponibilidad de objetos
2. Eventos
Convocación y demostración
3. Interfaces
1. Modos de Operación
Selección de alternativas
2. Submodos de Operación
•
Interacciones con
súper-sistema
Interacción de agentes
•
Interacciones con otros
SE y el ambiente.
•
Funcionalidades de
entrada
•
Acción del agente
Funcionalidades de
proceso
•
Transferencia / Actualización
Funcionalidades de salida
Sin Subcategorías
Interrupción / Restitución /
•
Prevención de fallas
Conservación
•
Detección de fallas
Desempeño / Cambio
Sin Subcategorias
Precio y costos
•
Tamaño
•
Consumo de energía
1. Disponibilidad
Descripción o caracterización de los
agentes
2. Fiabilidad
3. Seguridad frente al exterior
4. Seguridad frente a ataques
5. Eficiencia
Tabla 1. Categorías del modelo ABC-BENSOINS-SEM
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
131
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
[Palacio – Giraldo, 2008].
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
132
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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].
Subcategorias: No posee
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].
Subcategorias: No posee
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
133
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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].
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
134
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
•
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
Subcategorias: No posee
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].
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
135
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
1.2.1.11 Desempeño / Cambio
Estos requisitos permiten incluir formas de optimizar tiempos para realizar una operación.
Subcategorias: No posee
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
[Palacio – Giraldo, 2008].
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).
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
136
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
•
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
137
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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].
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
138
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
Softgoal
Operationalization
Functional Goal
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
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 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 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
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
Functional Goal
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
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
[Heather et al, 2007].
helps/hurts
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].
OR/AND
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].
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
140
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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].
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
141
JONATAN PONZO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
Descripcion
Meta Funcional Principal
Sensor Activo
Estructural
Especifica diversos tipos de sensores activos
y sus relaciones con el componente computacional
Sensor Pasivo
Estructural
Especifica diversos tipos de sensores pasivos
y sus relaciones con el componente computacional
Actuador
Estructural
Especifica diversos tipos de actuadores
y sus relaciones con el componente computacional
Control
Estructural
NFR
Control
Descomposicion
Indicador
Comunicacion
Componente
Computacional
Corrector
Detector
Gestor de Fallas
Describe como modelar los controles de una
interface de usuario a fin de adquirir valores de entrada
Estructural Una vision global de las relaciones de los componentes
en el sistema
Describe como modelar los indicadores de una interface
Estructural de usuario a fin de señalozar el estado actual al usuario
Especifica como debe interactuar el sistema con entidades
Operativo
externas como dispositivos de diagnostico
Especifica diversos modos operativos del componente
Operativo
computacional de un sistema embebido
Describe como pueden ser incluidas capacidades de
Operativo correccion de fallas en el sistema
Describe como pueden ser incluidas capacidades de
Operativo
deteccion de fallas en el sistema
Operativo
Describe como modelar gestores globales y locales
a fin de proveer un mayor nivel de abstraccion
Monitoreo del entorno,
envio de informacion
Monitoreo del entorno,
Requiere explicita solicitud de
Informacion
Influencia del entorno mediante
la configuracion de un valor
en el actuador
Recepcion de informacion
del usuario
Descomposicion del sistema en
Componentes
Proveer informacion al usuario
Reusabilidad
Clasificacion
Rendimiento
Nombre
Adaptabilidad
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
+
-
+
-
+
+
+
+
-
+
+
+
-
+
Interactuar con entidades externas
como dispositivos de diagnostico
-
+
Distribuir tareas computacionales
-
+
Corregir fallas
-
+
-
Detectar fallas
-
+
-
Gestion centralizada de fallas
-
+
-
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
142
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
143
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
144
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
[Heather et al, 2007].
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
145
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
146
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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:
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
147
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
148
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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,
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
149
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
150
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
Documentación de Salida:
▪ 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
Técnicas Sugeridas:
▪ 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)
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
151
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
▪ 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
Documentación de Salida:
▪ 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
Documentación de Salida:
▪ Reporte de Riesgos
▪ Reporte de Gestión del Proyecto
▪ Reporte de necesidades de mejora en el Ciclo de Vida
▪ Registro Histórico de Proyectos
▪ Reporte de Métricas
▪ Información necesaria para el archivo del Proyecto al momento de su cierre
Técnicas Sugeridas:
▪ Análisis de riesgo técnico
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
152
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
◦ 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.
Documentación de Salida:
▪ Informe preliminar de necesidades
▪ Informe de Soluciones potenciales. Beneficios y Limitaciones
▪ Informe de Viabilidad
▪ Informe de Necesidades
Técnicas Sugeridas:
▪ 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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
153
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
Documentación de Salida:
▪ 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 Sugeridas:
▪ 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
Documentación de Salida:
▪ 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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
154
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
▪ Integrar los requisitos del software
Documentación de Salida:
▪ Informe preliminar de requisitos del sistema
▪ Especificación de requisitos de interfaces
▪ Especificación de requerimientos del sistema
Técnicas Sugeridas:
▪ Técnicas orientadas a los procesos
◦ 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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
155
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
▪ Realizar el diseño de la base de datos (si aplica)
▪ Diseñar las interfaces
▪ Realizar el diseño detallado
Documentación de Salida:
▪ Diseño arquitectónico
▪ Diseño de la base de datos
▪ Diseño de las interfaces
▪ Diseño detallado
Técnicas Sugeridas:
▪ Técnicas orientadas a los procesos
◦ 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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
156
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
▪ 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
Documentación de Salida:
•
Codigo fuente
•
Software Ejecutable
•
Base de datos
•
Documentación operacional
•
Software integrado
•
Paquete del producto lanzado
Técnicas Sugeridas:
4.
•
Warnier
•
Jackson
•
Lenguajes de programación
•
Entorno de Programación del hardware seleccionado
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
Documentación de Salida:
•
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:
•
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
Operar el sistema
157
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
•
Proveer de asistencia técnica y consultas
•
Mantener el histórico de peticiones de soporte
Documentación de Salida:
•
Registro de Operaciones
•
Registro de Anomalías
•
Registro de Peticiones de Soporte
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
Documentación de Salida:
•
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
Documentación de Salida:
5.
•
Notificación oficial al usuario
•
Registro de operaciones en paralelo
•
Reporte de revisión Post-Operacion
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
158
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
•
Ejecutar pruebas
•
Reportar Resultados de la evaluación
•
Confirmar Acreditación de Seguridad
Documentación de Salida:
•
Resultados de revisión en-proceso
•
Reporte de revisión Post-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 Sugeridas:
•
Técnicas de prueba de caja blanca
◦ Cobertura de sentencias
◦ Cobertura de decisión o ramificación
◦ Cobertura de condición
◦ Cobertura de decisión/condición
◦ Cobertura de condición múltiple
•
Técnicas de prueba de caja negra
◦ Partición de equivalencias
◦ Análisis de valores limites
◦ Gráficos causa-efecto
◦ Conjetura de errores
•
Revisiones formales
•
Auditorías
5.2. Sub-proceso de gestión de la configuración
Actividades:
•
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
Realizar la identificación de la configuración
159
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
•
Realizar el control de la configuración
•
Realizar la información del estado de la configuración
Documentación de Salida:
•
Reporte de Identificación de la Configuración
5.3. Sub-proceso de desarrollo de Documentación
Actividades:
•
Implementar la Documentación
•
Producir y Distribuir la Documentación
Documentación de Salida:
•
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
Documentación de Salida:
•
Manual de entrenamiento
•
Materiales de entrenamiento
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
160
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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-eldesarrollo-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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
161
JONATAN PONZO
ANEXO III – MODELADO DE SISTEMAS EMBEBIDOS
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
162
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES
BASADOS EN ARQUITECTURAS DE SISTEMAS
EMBEBIDOS
Propuesta de Modelo de Aplicación y Uso Potencial
Jonatan Ponzo - [email protected]
Universidad Nacional de Lanús – Lic. Sistemas
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
163
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
164
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
Robot para Automatización de Tareas de Invernadero
Plan de Inicialización del Proyecto
Versión 1.0
Autor: Jonatan Ponzo
Lanzamiento: Septiembre 2013
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
165
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
166
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
Histórico de Modificaciones
Fecha
12/01/13
Descripción del cambio
Creación del Documento
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
167
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
168
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
169
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
170
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
1.
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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:
1. Selección de un Modelo de Ciclo de Vida
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
2.
Selección de un Modelo de Ciclo de Vida
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
171
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
172
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
Apéndice A. Mapa de Actividades
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
173
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
174
JONATAN PONZO
A.1
A.1.1
A.1.1.1
A.1.1.2
A.1.1.3
A.1.1.4
A.1.1.5
A.1.1.6
A.1,2
A.1.2.1
A.1.2.2
A.1.2.3
A.1.2.4
A.1.2.5
A.1.2.6
A.1.2.7
A.1.2.8
A.1.2.9
A.1.2.10
A.1.2.11
A.1.3
A.1.3.1
A.1.3.2
A.1.3.3
A.1.3.4
A.1.3.5
A.1.3.6
A.2
A.2.1
A.2.1.1
A.2.1.2
A.2.1.3
A.2.1.4
A.2.2
A.2.2.1
A.2.2.2
A.2.2.3
A.3
A.3.1
A.3.1.1
A.3.1.2
A.3.1.3
A.3.1.4
A.3.1.5
A.3.2
A.3.2.1
A.3.2.2
A.3.2.3
A.3.2.4
Proceso de Gestion del Proyecto
Sub-proceso de Iniciación del proyecto
Seleccionar un modelo de Ciclo de Vida
Realizar Estimaciones
Asignar Recursos
Definir Métricas
Determinar objetivos de Seguridad
Entendimiento del Negocio
Sub-proceso de Planificación del proyecto
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
Planificación del Mantenimiento
Planificación del Retiro
Sub-proceso de Seguimiento y Control del Proyecto
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
Proceso de Desarrollo Pre-Desarrollo
Sub-proceso de Exploración de Conceptos
Identificar ideas o necesidades.
Formular soluciones potenciales.
Conducir estudios de viabilidad.
Refinar y Finalizar la idea o necesidad.
Sub-proceso de Asignación del Sistema
Analizar las funciones del sistema.
Desarrollar la arquitectura del sistema.
Asignar los requisitos del Sistema
Proceso de Desarrollo
Sub-proceso de Requisitos
Definir y desarrollar los requisitos del hardware
Definir y desarrollar los requisitos del interfaces
Definir los requisitos del entorno
Definir los requisitos de software
Integrar los requisitos
Sub-proceso de Diseño
Realizar el diseño arquitectónico
Realizar el diseño de la base de datos (si aplica)
Selección de la Arquitectura de Hardware mas conveniente.
Diseñar las interfaces
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
175
GARANTIA DE CALIDAD
PLANIFICACIÓN
MAPA DE ACTIVIDADES
IMPLEMENTACIÓN Y PRUEBA
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
ANÁLISIS Y DISEÑO
ANEXO IV – DOCUMENTOS DEL PROYECTO
X
X
X
X
X
X
X
X
NA NA NA NA
X
X
NA NA NA NA
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
NA NA NA NA
X
X
JONATAN PONZO
A.4.2
A.4.2.1
A.4.2.2
A.4.2.3
A.4.3
A.4.3.1
A.4.3.2
A.4.3.3
A.4.3.4
A.4.4
A.4.4.1
A.4.4.2
A.4.4.3
A.5
A.5.1
A.5.1.1
A.5.1.2
A.5.1.3
A.5.1.4
A.5.1.5
A.5.1.6
A.5.1.7
A.5.1.8
A.5.2
A.5.2.1
A.5.2.2
A.5.2.3
A.5.3
A.5.3.1
A.5.3.2
A.5.4
A.5.4.1
A.5.4.2
A.5.4.3
A.3.3
A.3.3.1
A.3.3.2
A.3.3.3
A.3.3.4
A.3.3.5
A.4
Sub-proceso de operación y soporte
Operar el sistema
Proveer de asistencia técnica y consultas
Mantener el histórico de peticiones de soporte
Sub-proceso de mantenimiento
Identificación de necesidades de mejora del Software
Identificación de necesidades de mejora del Hardware y Entorno Configurable
Implementación de un método de reporte de problemas
Iteración del Ciclo de Vida
Sub-proceso de retiro
Notificar al usuario
Conducir operaciones en paralelo (si aplica)
Retirar el sistema
Procesos Integrales del Proyecto
Subproceso de Verificación y Validación
Conducir Revisiones
Crear Matriz de Trazabilidad
Conducir Auditorías
Desarrollar Procedimientos de prueba
Crear datos de prueba
Ejecutar pruebas
Reportar Resultados de la evaluación
Confirmar Acreditación de Seguridad
Sub-proceso de gestión de la configuración
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
Sub-proceso de desarrollo de Documentación
Implementar la Documentación
Producir y Distribuir la Documentación
Sub-proceso de Formación
Desarrollar los materiales de formación
Validar el programa de formación
Implementar el programa de formación
Sub-proceso de Implementación
Configurar e integrar el hardware y las interfaces físicas
Crear el código fuente
Crear la Documentación operacional
Realizar la integración
Gestionar las versiones del Software
Proceso de Post-Desarrollo
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
176
GARANTIA DE CALIDAD
PLANIFICACIÓN
MAPA DE ACTIVIDADES
IMPLEMENTACIÓN Y PRUEBA
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
ANÁLISIS Y DISEÑO
ANEXO IV – DOCUMENTOS DEL PROYECTO
X
X
X
X
X
X
X
NA NA NA NA
NA NA NA NA
NA NA NA NA
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
NA NA NA NA
NA NA NA NA
NA NA NA NA
X
X
X
X
X
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
JUSTIFICACION DE ACTIVIDADES NO REALIZADAS
A.1.2.3
Planificación de la Transición (si se requiere)
A.3.2.2
Realizar el diseño de la base de datos (si aplica)
A.4.4.2
Conducir operaciones en paralelo (si aplica)
A.1.2.11
Planificación del Retiro
A.4.4.3
Retirar el sistema
A.4.4.1
Notificar al usuario
A.5.4.1
Desarrollar los materiales de formación
A.5.4.2
Validar el programa de formación
A.5.4.3
Implementar el programa de formación
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
No se presenta una transición
No se utilizara una base de datos
No se prevén actividades en paralelo
No se prevé el retiro del sistema
No se prevé el retiro del sistema
No se prevé el retiro del sistema
No son necesarias actividades de formación
No son necesarias actividades de formación
No son necesarias actividades de formación
177
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
178
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
Apéndice B. Secuencia de Actividades
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
179
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
180
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
Fase del Ciclo de Vida
PLANIFICACION
Identificar la misión del proyecto
Identificar los Recursos
Identificar Metricas de Calidad
Planificar el Proyecto
ANÁLISIS Y DISEÑO
Definir Objetivos
Definir Requisitos y Requerimientos
Diseñar el Sistema
IMPLEMENTACIÓN Y PRUEBA
Desarrollar Componentes
Integrar e implementar el Sistema
Verificacion y Validacion
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
Actividad del Modelo
A.1.1.6
A.1.1.1
A.1.1.2
A.1.1.3
A.1.1.4
A.1.3.1
A.1.1.5
A.4.3.3
A.1.2.7
A.1.2.4
A.1.2.8
A.1.2.1
A.1.2.9
A.1.2.2
A.1.2.10
A.1.2.5
A.5.1.1
Entendimiento del Negocio
Seleccionar un modelo de Ciclo de Vida
Realizar Estimaciones
Asignar Recursos
Definir Métricas
Gestión de Riesgos
Determinar objetivos de Seguridad
Implementación de un método de reporte de problemas
Planificación de la Gestión del Proyecto.
Planificación de la Instalación
Planificación de la Integración
Planificación de la Evaluación
Planificación de la Gestión del Lanzamiento
Planificación de la Gestión de la Configuración
Planificación del Mantenimiento
Planificación de la Documentación
Conducir Revisiones
A.2.1.1
A.2.1.2
A.2.1.3
A.2.1.4
A.2.2.1
A.2.2.2
A.2.2.3
A.3.1.1
A.3.1.2
A.3.2.3
A.3.1.3
A.3.1.4
A.3.1.5
A.3.2.1
A.3.2.4
A.3.2.5
A.5.1.1
Identificar ideas o necesidades.
Formular soluciones potenciales.
Conducir estudios de viabilidad.
Refinar y Finalizar la idea o necesidad.
Analizar las funciones del sistema.
Desarrollar la arquitectura del sistema.
Asignar los requerimientos del Sistema
Definir y desarrollar los requisitos del hardware
Definir y desarrollar los requisitos del Interfaces
Selección de la Arquitectura de Hardware mas conveniente.
Definir los requisitos del entorno
Definir los requisitos de software
Integrar los requisitos
Realizar el diseño arquitectónico
Diseñar las interfaces
Realizar el diseño detallado
Conducir Revisiones
A.3.3.2
A.3.3.5
A.3.3.1
A.3.3.4
A.4.1.1
A.4.1.2
Crear el código fuente
Gestionar las versiones del Software
Configurar e integrar el hardware y las interfaces físicas
Realizar la integración
Ajustar parámetros del entorno
Configurar y adaptar interfaces con el entorno productivo
y otros sistemas
Crear la Documentación operativa
Operar el sistema
Proveer de asistencia técnica y consultas
Mantener el histórico de peticiones de soporte
Desarrollar Procedimientos de prueba
Crear Matriz de Trazabilidad
Crear datos de prueba
Ejecutar pruebas
Almacenamiento de Registros
Reportar Resultados de la evaluación
Aceptar el producto en el ambiente operativo
Conducir Revisiones
A.3.3.3
A.4.2.1
A.4.2.2
A.4.2.3
A.5.1.4
A.5.1.2
A.5.1.5
A.5.1.6
A.1.3.4
A.5.1.7
A.4.1.3
A.5.1.1
181
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
Fase del Ciclo de Vida
GARANTIA DE CALIDAD
Conducir revisiones y determinar
mejoras en el producto
Planificar el Mantenimiento
Conducir Auditorias y determinar
mejoras en los procesos
Implementar Documentación
Cerrar el Proyecto
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
Actividad del Modelo
A.5.2.1
A.5.2.2
A.5.2.3
A.5.1.1
A.4.3.1
A.4.3.2
A.5.1.8
A.1.2.10
A.1.3.5
A.1.3.3
A.5.1.3
A.5.3.1
A.5.3.2
A.4.3.4
A.1.3.6
Desarrollar la identificación de la configuración
Realizar el control de la configuración
Realizar la información del estado de la configuración
Conducir Revisiones
Identificación de necesidades de mejora del Software
Identificación de necesidades de mejora del Hardware y Entorno
Confirmar Acreditación de Seguridad
Planificación del Mantenimiento
Recopilación y Análisis de Métricas
Identificación de Mejoras al Ciclo de Vida
Conducir Auditorías
Implementar la Documentación
Producir y Distribuir la Documentación
Iteración del Ciclo de Vida
Cierre del Proyecto
182
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
Apéndice C. Mapa de Documentos y Actividades
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
183
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
184
JONATAN PONZO
Actividad
A.1.1.6 Entendimiento del Negocio
A.1.1.1 Seleccionar un modelo de Ciclo de Vida
A.1.1.2 Realizar Estimaciones
A.1.1.3 Asignar Recursos
A.1.1.4 Definir Métricas
A.1.3.1 Gestión de Riesgos
A.1.1.5 Determinar objetivos de Seguridad
A.4.3.3 Implementación de un método de reporte de problemas
A.1.2.7 Planificación de la Gestión del Proyecto.
A.1.2.4 Planificación de la Instalación
A.1.2.8 Planificación de la Integración
A.1.2.1 Planificación de la Evaluación
A.1.2.9 Planificación de la Gestión del Lanzamiento
A.1.2.2 Planificación de la Gestión de la Configuración
A.1.2.10 Planificación del Mantenimiento
A.1.2.5 Planificación de la Documentación
A.2.1.1 Identificar ideas o necesidades.
A.2.1.2 Formular soluciones potenciales.
A.2.1.3 Conducir estudios de viabilidad.
A.2.1.4 Refinar y Finalizar la idea o necesidad.
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 Sistema
A.3.1.1 Definir y desarrollar los requisitos del hardware
A.3.1.2 Definir y desarrollar los requisitos del interfaces
A.3.1.3 Definir los requisitos del entorno
A.3.2.3 Selección de la Arquitectura de Hardware mas conveniente.
A.3.1.4 Definir los requisitos de software
A.3.1.5 Integrar los requisitos
A.3.2.1 Realizar el diseño arquitectónico
A.3.2.4 Diseñar las interfaces
A.3.2.5 Realizar el diseño detallado
A.3.3.2 Crear el código fuente
A.3.3.5 Gestionar las versiones del Software
A.3.3.1 Configurar e integrar el hardware y las interfaces físicas
A.3.3.4 Realizar la integración
Salida del Proceso
Propuesta, Alcances y Objetivos
Ciclo de vida Seleccionado
Mapa de Actividades
Lista de actividades no utilizadas
Mapa de Documentos
Estimaciones del Proyecto
Asignación de Recursos
Definición de Métricas
Especificación de Riesgos
Especificación de Objetivos de Seguridad
Método de Reporte de Problemas
Plan de Gestión del Proyecto
Plan de Instalación
Plan de Integración
Plan de Evaluación
Plan de Gestión del Lanzamiento
Plan de Gestión del la Configuración
Plan de Mantenimiento
Plan de Documentación
Informe Preliminar de Necesidades
Informe Preliminar de Soluciones Potenciales
Informe de Viabilidad
Descripción de Idea o Necesidad
Descripción de Funciones del Sistema
Descripción de Arquitectura del Sistema
Asignación de requerimientos
Informe de requerimientos de Software
Informe de requerimientos de Hardware
Informe de requerimientos de Entorno
Especificación de Hardware
Informe de requerimientos de Interfaz
Informe de Integración de los requerimientos
Diseño Arquitectónico
Diseño de Interfaces
Diseño detallado
Código ejecutable
Control de Versiones del Software
Hardware Integrado
Software y Hardware Integrado
Documento Generado
Plan de Proyecto
Plan de Proyecto
Plan de Proyecto
Plan de Proyecto
Plan de Proyecto
Plan de Proyecto
Plan de Proyecto
Plan de Proyecto
Plan de Proyecto
Plan de Proyecto
Plan de Proyecto
Plan de Proyecto
Plan de Proyecto
Plan de Proyecto
Plan de Proyecto
Plan de Proyecto
Plan de Proyecto
Plan de Proyecto
Plan de Proyecto
Especificación de Requisitos
Especificación de Requisitos
Especificación de Requisitos
Especificación de Requisitos
Especificación de Requisitos
Especificación de Requisitos
Especificación de Requisitos
Especificación de Requisitos
Especificación de Requisitos
Especificación de Requisitos
Especificación de Requisitos
Especificación de Requisitos
Especificación de Requisitos
Especificación de Diseño
Especificación de Diseño
Especificación de Diseño
Actividad
A.4.1.1
A.4.1.2
A.3.3.3
A.4.2.1
A.4.2.2
A.4.2.3
A.5.1.4
A.5.1.2
A.5.1.5
A.5.1.6
A.1.3.4
A.5.1.7
A.4.1.3
A.5.2.1
A.5.2.2
A.5.2.3
A.5.1.1
A.4.3.1
A.4.3.2
A.5.1.8
A.1.3.3
A.1.3.5
A.5.1.3
A.5.3.1
Salida del Proceso
Ajustar parámetros del entorno
Configurar y adaptar interfaces con el entorno productivo y otros sistemas
Crear la Documentación operativa
Instrucciones de operación
Operar el sistema
Proveer de asistencia técnica y consultas
Mantener el histórico de peticiones de soporte
Reporte Histórico de Peticiones de Soporte
Desarrollar Procedimientos de prueba
Procedimientos de Prueba
Crear Matriz de Trazabilidad
Matriz de Trazabilidad
Crear datos de prueba
Datos de Prueba
Ejecutar pruebas
Almacenamiento de Registros
Reportar Resultados de la evaluación
Informe de Resultados de Prueba
Aceptar el producto en el ambiente operativo
Robot Instalado
Desarrollar 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 del estado de la configuración
Conducir Revisiones
Informe de revisión del proceso
Identificación de necesidades de mejora del Software
Necesidades de Mejora del Software
Identificación de necesidades de mejora del Hardware y Entorno ConfigurableNecesidades
(EC)
de Mejora del Hardware y EC
Confirmar Acreditación de Seguridad
Verificación de Objetivos de Seguridad
Identificación de Mejoras al Ciclo de Vida
Recomendaciones de mejora en los procesos
Recopilación y Análisis de Métricas
Conducir Auditorías
Resultados de la auditoría
Implementar la Documentación
Documentación
Documento Generado
Reporte de Instalación y operación del Sistema
Reporte de Instalación y operación del Sistema
Manual de Operaciones
Reporte de Instalación y operación del Sistema
Reporte de Instalación y operación del Sistema
Reporte de Instalación y operación del Sistema
Reporte de Evaluación del Sistema
Reporte de Evaluación del Sistema
Reporte de Evaluación del Sistema
Reporte de Evaluación del Sistema
Reporte de Evaluación del Sistema
Reporte de Evaluación del Sistema
Reporte de Evaluación del Sistema
Informe de Estado de la Configuración
Informe de Estado de la Configuración
Informe de Estado de la Configuración
Informe de Garantía de Calidad
Informe de Garantía de Calidad
Informe de Garantía de Calidad
Informe de Garantía de Calidad
Informe de Garantía de Calidad
Informe de Garantía de Calidad
Informe de Garantía de Calidad
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
Robot para Automatización de Tareas de Invernadero
Plan de Proyecto
Versión 1.0
Autor: Jonatan Ponzo
Lanzamiento: Septiembre 2013
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
187
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
188
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
Histórico de Modificaciones
Fecha
Descripción del cambio
14/01/13
Creación del Documento
23/02/13
Planificación del Mantenimiento
24/02/13
Actualización de Objetivos de Seguridad
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
189
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
190
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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
9. Apéndices/Anexos
Apéndice A - Planillas
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
191
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
192
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
1.
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
193
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
194
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
195
JONATAN PONZO
PLANIFICACION
A.1.1.6
Entendimiento del Negocio
A.1.1.1
Seleccionar un modelo de Ciclo de Vida
A.1.1.2
Realizar Estimaciones
A.1.1.3
Asignar Recursos
A.1.1.4
Definir Métricas
A.1.3.1
Gestión de Riesgos
A.1.1.5
Determinar objetivos de Seguridad
A.4.3.3
Implementación de un método de reporte de problemas
A.1.2.7
Planificación de la Gestión del Proyecto.
A.1.2.4
Planificación de la Instalación
A.1.2.8
Planificación de la Integración
A.1.2.1
Planificación de la Evaluación
A.1.2.9
Planificación de la Gestión del Lanzamiento
A.1.2.2
Planificación de la Gestión de la Configuración
A.1.2.10
Planificación del Mantenimiento
A.1.2.5
Planificación de la Documentación
A.5.1.1
Conducir Revisiones
ANÁLISIS Y DISEÑO
A.2.1.1
Identificar ideas o necesidades.
Formular soluciones potenciales.
A.2.1.2
Conducir estudios de viabilidad.
A.2.1.3
A.2.1.4
Refinar y Finalizar la idea o necesidad.
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 Sistema
A.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 entorno
A.3.1.4
Definir los requisitos de software
A.3.1.5
Integrar los requisitos
A.3.2.1
Realizar el diseño arquitectónico
A.3.2.4
Diseñar las interfaces
A.3.2.5
Realizar el diseño detallado
Recurso
Actividad
Costo (ARS$)
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
Duración (HS)
ANEXO IV – DOCUMENTOS DEL PROYECTO
4
16
1
1
1
1
1
1
2
1
1
1
1
1
1
1
1
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
1
1
1
1
1
4
1
8
4
4
4
4
16
2
2
16
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
Fig. 1.a) Cuadro de Estimaciones
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
196
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
IMPLEMENTACION Y PRUEBA
A.3.3.2
Crear el código fuente
A.3.3.5
Gestionar las versiones del Software
A.3.3.1
Configurar e integrar el hardware y las interfaces físicas
A.3.3.4
Realizar la integración
A.4.1.1
Ajustar parámetros del entorno
A.4.1.2
Configurar y adaptar interfaces con el entorno productivo
y otros sistemas
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.4.2.3
Mantener el histórico de peticiones de soporte
A.5.1.4
Desarrollar Procedimientos de prueba
A.5.1.2
Crear Matriz de Trazabilidad
A.5.1.5
Crear datos de prueba
A.5.1.6
Ejecutar pruebas
Almacenamiento de Registros
A.1.3.4
A.5.1.7
Reportar Resultados de la evaluación
A.4.1.3
Aceptar el producto en el ambiente operativo
A.5.1.1
Conducir Revisiones
GARANTIA DE CALIDAD
A.5.2.1
Desarrollar la identificación de la configuración
A.5.2.2
Realizar el control de la configuración
A.5.2.3
Realizar la información del estado de la configuración
A.4.3.1
Identificación de necesidades de mejora del Software
A.4.3.2
Identificación de necesidades de mejora del Hardware y Entorno
A.5.1.8
Confirmar Acreditación de Seguridad
A.1.2.10
Planificación del Mantenimiento
A.5.1.1
Conducir Revisiones
Recopilación y Análisis de Métricas
A.1.3.5
A.1.3.3
Identificación de Mejoras al Ciclo de Vida
A.5.1.3
Conducir Auditorías
A.5.3.1
Implementar la Documentación
A.5.3.2
Producir y Distribuir la Documentación
A.4.3.4
Iteración del Ciclo de Vida
A.1.3.6
Cierre del Proyecto
Recurso
ponzoj
Descripcion
Jonatan Matias Ponzo
16
1
8
2
1
1
1
2
2
4
2
1
8
1
1
2
1
5
2
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
1
1
1
1
1
2
1
1
1
2
8
1
4
1
195
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
$0,00
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
ponzoj
$/Hs
$0,00
Hs Asignadas
195
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
197
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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.
Recurso
Descripción
Costo
Kit ROBOT N6 V1.1
Kit Arduino, Carcaza, 2 Motores
2 Sensores IR, 2 Sensores Ultrasonido
$1.700,00
(Provisto por la Universidad)
2 Sensores IR
Sensores IR para deteccion de marcas
$64,00
1 Modulo MicroSD Arduino
Modulo Lecto-Grabador de tarjetas micro SD
$60,00
Cables y Conectores
Cables y Conectores necesarios
$20,00
PC/Laptop
Necesaria para la generación del código
fuente y la integración del mismo con
el hardware
Entorno de Prueba
Materiales necesarios para el montaje
de un entorno de prueba.
$100,00
Sensor de Temperatura
y Humedad
Componente electrónico para el sensado
de Temperatura y Humedad
$50,00
$0,00
(Provisto por el Desarrollador)
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
Líder de Proyecto
Analista de Requerimientos
Técnico Electrónico
Arquitecto de Software
Programador
Instalador
Verificador
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
Horas
70
36
16
20
17
12
19
190
198
Cantidad
1
1
1
1
1
1
1
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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.
Riesgo
Procesos del Proyecto
Descripción
Criticidad
Procesos o Actividades
No contempladas en el
Ciclo de Vida del Proyecto
Variable
El Robot enfrenta situaciones
imprevistas durante el recorrido
Dificultad en la Implementación de el entorno de prueba
Dificultades con el Hardware
El Robot presenta alguna
dificultad relacionada al
hardware o requiere de
componentes o interfaces
Adicionales
Contingencia
Seguimiento
Ejecución de cualquier
actividad o proceso
necesario no especificado
en el Ciclo de Vida del
Proyecto y registro del
mismo en el informe de
Sugerencia de Mejoras
en los Procesos
Media
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
Media
Se contacta a RobotGroup;
desarrollador y distribuidor
del producto
*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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
199
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
200
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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 USBMiniUSB. 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-
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
201
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
202
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
203
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
204
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
205
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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).
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
206
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
207
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
•
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
208
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
209
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
210
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
Apéndice A. Planillas
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
211
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
212
JONATAN PONZO
Planilla de Reporte de Problemas
REPORTE
ID
FECHA
PROPIETARIO
DEL PROBLEMA
FASE
DESCRIPCION
SOLUCIONES
POTENCIALES
SEGUIMIENTO
CORRECCION
FECHA
DESCRIPCION
EJECUTOR
PROPUESTAS
DE MEJORA
FINALIZADO
Planilla de Reporte de Asistencia Técnica
NOTIFICACION
ID
FECHA
CATEGORIA
hard/soft
DESCRIPCION
ASISTENCIA TÉCNICA
CRITICIDAD
RESOLUCION
EJECUTOR
FECHA
alta/media/baja
Planilla de Solicitud de Asistencia técnica
SOLICITUD DE ASISTENCIA TÉCNICA
FECHA:
SISTEMA:
CATEGORIA: SOFTWARE HARDWARE
DESCRIPCION DEL PROBLEMA:
CRITICIDAD:
CONTACTO PRINCIPAL:
EMAIL DE CONTACTO:
TELEFONO DE CONTACTO:
ENTORNO
COMENTARIOS
Planilla de Reporte de Mantenimiento
ORDEN DE MANTENIMIENTO
ID
CLIENTE
FECHA
PRODUCTO
ACTIVIDAD
PROBLEMAS REPORTADOS
ID
FECHA
RESULTADO
CATEGORIA
IDENTIFICACION DE POSIBLES MEJORAS
ID
CATEGORIA
COMENTARIOS
DESCRIPCION
CRITICIDAD
DESCRIPCION
EJECUTOR
FECHA
COMENTARIOS
COSTO
BENEFICIO
Planilla de Control de Actividades
ACTIVIDAD
COMIENZO
FECHA
CONTROL DE ACTIVIDADES
FINALIZACION
EJECUTOR
FECHA
FINALIZADO
COMENTARIOS
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
Planilla de Solicitud de Cambio
Información General
ID del Cambio
Nombre del Sistema
Solicitante
Fecha
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
Hardware
Correctivo
Entorno
Procedimientos
Mejora
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
217
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
Información General
ID del Cambio
Nombre del Sistema
Fecha
Demorado
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
218
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
Robot para Automatización de Tareas de Invernadero
Especificación de Requisitos
Versión 1.0
Autor: Jonatan Ponzo
Lanzamiento: Septiembre 2013
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
219
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
220
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
Histórico de Modificaciones
Fecha
Descripción del cambio
23/01/13
Creación del Documento
21/02/13
Actualización de Requerimientos de Software del Proyecto
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
221
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
222
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
223
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
224
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
225
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
226
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
227
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
228
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
229
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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 ABCBESOINS-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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
230
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
231
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
232
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
233
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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.
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.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
234
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
235
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
236
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
10.1 Prevención de fallas
El sistema no presenta requerimientos de este tipo
10.2 Detección de fallas
El sistema no presenta requerimientos de este tipo
11. Desempeño / Cambio
El sistema no presenta requerimientos de este tipo
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
El sistema no presenta requisitos de este tipo
13.2 Fiabilidad
El sistema no presenta requisitos de este tipo
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
237
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
238
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
Entorno
Sensores
Actuadores
Controlador
Sistema Embebido
Almacenamiento
Microcontrolador
Entradas / Salidas
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
239
JONATAN PONZO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
1.2.1
1.2.2
1.2.3
1.2.4
1.2.5
2.1.1
2.1.2
2.1.3
2.1.4
2.1.5
2.1.6
2.1.7
2.1.8
3.1.1
3.2.1.1
3.2.1.2
3.2.1.3
4.1.1.1
4.1.1.2
4.1.1.3
4.1.2.1
4.1.3.1
5.1
7.2.2
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
7.2.3
7.2.4
7.2.5
7.2.6
8.1.1
8.1.2
8.1.3
8.1.4
8.1.5
8.1.6
8.2.1
8.2.2
8.2.3
8.3.1
8.3.2
9.1
9.2
9.3
12.1.1
12.2.1
13.1.1
13.3.1
13.4.1
13.5.1
X
X
X
Entorno
Hardware/Interfaz
Funcionalidad
X
X
X
X
X
X
X
X
X
Requerimiento
Entorno
Hardware/Interfaz
Funcionalidad
Software
Requerimiento
Software
ANEXO IV – DOCUMENTOS DEL PROYECTO
X
X
X
Ver 2.1.7
Ver 2.1.8
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
240
JONATAN PONZO
Funcionalidad
2.1.1
2.1.2
2.1.3
2.1.4
2.1.5
2.1.6
2.1.7
2.1.8
7.2.2
7.2.3
7.2.6
8.1.3
8.1.4
8.1.5
8.1.6
8.2.1
12.1.1
12.2.1
13.1.1
13.3.1
13.4.1
Hardware / Interfaz
ANEXO IV – DOCUMENTOS DEL PROYECTO
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
241
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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
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 en 2.1.6
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
242
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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
▪ Requerimiento cubierto en 2.1.4
8.1.4 El sistema debe recibir una entrada de los sensores ultrasónicos a fin de detectar le
presencia de un obstáculo.
▪ Requerimiento cubierto en 2.1.7
8.1.5 El sistema debe recibir datos relevados por el sensor de temperatura y humedad y
almacenarlos.
▪ Requerimiento cubierto en 2.1.3
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
▪ Requerimiento cubierto en 2.1.3
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
243
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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.
▪ Requerimiento cubierto en 13.3.1
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
reducido de energía.
•
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
244
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
▪ 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
Funcionalidad
1.2.4
2.1.6
7.2.2
7.2.3
8.1.1
Entorno
10. Informe de Requerimientos de Entorno
X
X
X
X
X
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.
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.
▪ 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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
245
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
▪ 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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
246
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
Punto de Partida
Camino
Adaptación
suelo irregular
Puesto a relevar
Punto de Partida
Camino
Adaptación
suelo blanco
Puesto a relevar
Fig. 5 Adaptacion del camino
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
247
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
11.
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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
reducido de energía.
•
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
248
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
249
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
250
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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 standalone (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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
251
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
• 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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
252
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
253
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS
sus entradas y respuestas.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
254
JONATAN PONZO
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.
TABLA DE EVENTOS
EVENTOS
#
TIPO
ENTIDAD
EXTERNA
DESCRIPCION
FLUJO DE DATOS
ESTIMULO
RESPUESTA
FUNCION
ASOCIADA
1 TEMP
SENSADO DE
AMBIENTE
TEMPERATURA
Y HUMEDAD
SENSAR
AMBIENTE
2 TEMP
SENSADO DE
CAMINO
DISPOSICION
DEL CAMINO
SENSAR
CAMINO
3 TEMP
SENSADO DE
OBSTACULOS
DISPOSICION
DEL OBSTACULO
SENSAR
OBSTACULOS
4 TEMP
SENSADO DE
PUESTOS
DISPOSICION
DEL PUESTO
SENSAR
PUESTOS
5 TEMP
SENSADO DEL
CIRCUITO
DISPOSICION
DEL CIRCUITO
(INICIO – FIN)
SENSAR
CIRCUITO
DATOS RELEVADOS
DESCARGAR
DATOS
7 TEMP
ARRANQUE
TEMPORIZADO
ORDEN DE
DESPLAZAMIENTO
TEMPORIZADO
INICIO
TEMPORIZADO
8 TEMP
ESQUIVAR
OBSTACULO
OBSTACULO
ESQUIVADO
ESQUIVAR
OBSTACULO
9 TEMP
DESPLAZARSE
POR EL CAMINO
DESPLAZAMIENTO
DESPLAZARSE
10 EXT
SOLICITUD DE
INICIAR / PARAR
ARRANQUE / PARADA
FORZADO
FORZADA
6
EXT
PUESTO DE
DESCARGA
USUARIO
DESCARGA DE
DATOS
SOLICITUD DE DATOS
ORDEN DE INICIO / INICIAR / PARAR
PARADA FORZADA
FORZADO
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
257
JONATAN PONZO
ANEXO IV - DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
258
JONATAN PONZO
ANEXO IV - DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
Robot para Automatización de Tareas de Invernadero
Especificación de Diseño
Versión 1.0
Autor: Jonatan Ponzo
Lanzamiento: Septiembre 2013
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
259
JONATAN PONZO
ANEXO IV - DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
260
JONATAN PONZO
ANEXO IV - DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
Histórico de Modificaciones
Fecha
07/02/13
Descripción del cambio
Creación del Documento
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
261
JONATAN PONZO
ANEXO IV - DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
262
JONATAN PONZO
ANEXO IV - DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
263
JONATAN PONZO
ANEXO IV - DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
264
JONATAN PONZO
ANEXO IV - DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
265
JONATAN PONZO
ANEXO IV - DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
5
3
6
SE
SE
1
4
2
Sensores
Actuadores
1. Ultrasonido
2. Infrarrojo
3. Humedad y Temperatura
4. Ruedas x 2
5. LED
6. Buzzer
Fig. 1 Diagrama de Arquitectura del Hardware del Sistema
Sensores Actuadores
Entorno
Controlador
Sistema Embebido
Almacenamiento Microcontrolador
Entradas / Salidas
Fig.2 Disposición jerárquica de los módulos del sistema.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
266
JONATAN PONZO
ANEXO IV - DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
267
JONATAN PONZO
Sensores
TEMP/HUM
SENSADO
Actuadores
NOTIFICACIONES
ALMACENAMIENTO
RUEDAS
CIRCUITO PUESTOS
ACTUADO
RELEVAMIENTO
CAMINO
OBSTACULOS
SENSADO
DESPLAZAMIENTO
CONTROLADOR
Sistema Embebido
Almacenamiento
Microcontrolador
Fig.3 Diagrama de Arquitectura de Software del Sistema
Entradas / Salidas
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.
SENSORES
IR
ACTUADORES
ULTRASONICO TEMP/HUM
MOTOR DC
LED
BUZZER
Controlador
Sistema Embebido
Almacenamiento
Microcontrolador
Entradas / Salidas
Fig. 4 Diagrama Arquitectónico de Interfaces
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
269
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
270
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
271
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
272
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
Fig 7. Diagrama de Flujo Submódulo Camino
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
273
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
Fig 8. Diagrama de Flujo Submódulo
Obstaculos
Fig 9. Diagrama de Flujo Submódulo Puestos
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
274
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
Fig 10. Diagrama de Flujo Submódulo
Circuito
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
infrarrojo utilizado en el submódulo de puestos aunque
con un valor disparador diferente. El resultado es la
275
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
276
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
Fig. 11.b) Diagrama de flujo completo
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
277
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
278
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
Robot para Automatización de Tareas de Invernadero
Manual de Operaciones
Versión 1.0
Autor: Jonatan Ponzo
Lanzamiento: Septiembre 2013
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
279
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
280
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
Histórico de Modificaciones
Fecha
11/02/13
Descripción del cambio
Creación del Documento
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
281
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
282
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
283
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
284
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
285
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
286
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
• 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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
287
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
288
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
289
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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:
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
290
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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 [email protected]
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
291
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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:
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
292
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
Robot para Automatización de Tareas de Invernadero
Reporte de Instalación y Operación del Sistema
Versión 1.0
Autor: Jonatan Ponzo
Lanzamiento: Septiembre 2013
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
293
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
294
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
Histórico de Modificaciones
Fecha
14/02/13
Descripción del cambio
Creación del Documento
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
295
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
296
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
297
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
298
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
299
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
0.8 m
1m
OBSTACULO
(MOVIL)
INICIO / FIN
DEL CIRCUITO
PUESTO I
PUESTO II
(MOVIL)
Fig. 1 Entorno de Prueba
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
300
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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:
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
301
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
302
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
•
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
303
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
304
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
Robot para Automatización de Tareas de Invernadero
Reporte de Evaluación del Sistema
Versión 1.0
Autor: Jonatan Ponzo
Lanzamiento: Septiembre 2013
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
305
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
306
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
Histórico de Modificaciones
Fecha
Descripción del cambio
21/02/13
Creación del Documento
22/02/13
Aceptación del Sistema
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
307
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
308
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
7. Apéndices/Anexos
Apéndice A – Casos de Prueba
Apéndice B – Matriz de Trazabilidad
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
309
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
310
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
311
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
312
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
313
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
314
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
Apéndice A – Casos de Prueba
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
315
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
316
JONATAN PONZO
ID
CP001
CP002
CP003
DESCRIPCION
Seguimiento de Circuito
Detección de Puesto
Detección y sorteo de
un obstaculo
CATEGORIA
Funcional
Funcional
Funcional
Detección de fin de circuito
CP004
CP005
CP006
Funcional
Sensado de Temperatura
y Humedad en Puesto
Almacenamiento de valores
de Humedad y Temperatura
relevados
Funcional
Funcional
CP006
Inicio forzado
Funcional
CP007
Parada forzada
Funcional
CP008
Inicio temporizado
Funcional
CP009
Descarga de Información
Funcional
CP010
Consumo
No Funcional
CP011
Operación en condiciones
adversas
No Funcional
CONDICIONES
El robot dispone de un
circuito que cumple con
la especificación de
Requerimientos y se encuentra en
modo operativo
El robot se encuentra en
movimiento y el un puesto
se encuentra señalizado
en el circuito
El robot se encuentra en
movimiento y un obstáculo
se dispone en el circuito.
El robot se encuentra en
movimiento y el fin del circuito
se encuentra proximo y señalizado
acorde a lo requerido.
El robot se encuentra en modo sensado
como resultado de la deteccion de un
puesto.
El robot ha sensado recientemente
las condiciones de humedad y temperatura
del ambiente y aun se encuentra en modo
sensado
El robot se encuentra en modo espera
El robot se encuentra en modo operativo
El robot se encuentra en modo espera y
el temporizador ha sido configurado en un
valor de prueba de 5 minutos
El robot ha concluido su recorrido y se
encuentra en modo espera
El robot funciona toda una jornada con el
mismo set de baterias
El robot opera en condiciones adversas
de temperatura
ENTRADA
RESULTADO
EVALUACION
Linea dispuesta
en el camino, acorde
a lo requerido}
El robot se desplaza
por el circuito siguiendo
la linea dispuesta
Exitosa un 100% cuando no
debe enfrentar un obstaculo y
un 60% cuando debe hacerlo
Ninguna
Ninguna
Ninguna
El robot se detiene en
el puesto, conmuta su
estado a modo Sensado y notifica el evento
mediante un sonido
El robot golpea el obstáculo
hasta liberar el camino
El robot se detiene, conmuta
su estado al modo Espera y notifica el evento
mediante un sonido
Valores de Humedad y
Temperatura relevados
El robot solicita al sensor
de humedad y temperatura
los valores presentes en el entorno
en ese momento
El robot almacena los valores obtenidos
en la memoria interna
Pulsación del botón de
inicio forzado
Pulsación del botón de
parada forzada
Finalización del
temporizador
El robot conmuta al modo operativo
y comienza el recorrido
El robot se detiene y conmuta al modo
espera.
El robot conmuta al modo operativo
y comienza el recorrido
Conexión del robot al puesto
de descarga y ejecución
del programa descargador
Ninguna
El programa descargador informa los
valores de temperatura y humedad relevados
en cada puesto
El robot no requiere del reemplazo de baterias
Valores de Humedad y
Temperatura fuera del
promedio
El robot no altera su operatividad
Condiciones Ambientales
Exitosa
Existosa en un 50% de las
pruebas realizadas dependiendo
de la ubicación y caracteristicas
del obstaculo
Exitosa
Exitosa
Exitosa
Exitosa
Exitosa
Exitosa
Exitosa
Exitosa
Exitosa
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
318
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
Apéndice B – Matriz de Trazabilidad
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
319
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
320
JONATAN PONZO
Caso de Prueba
CP001 CP002 CP003 CP004 CP005 CP006 CP007 CP008 CP009 CP010 CP011
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.
NO REQUIERE UN CASO DE PRUEBA
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.
X
X
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.
X
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
X
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.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.
X
NO REQUIERE UN CASO DE PRUEBA
X
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
X
X
X
X
X
X
X
X
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.
X
X
El sistema debe proporcionar un puerto de descarga de la información relevada a una PC.
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.
X
X
X
X
X
X
Requerimiento
Caso 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
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
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
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.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
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.
X
X
X
X
X
X
X
X
X
X
X
X
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
X
X
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.
El hardware debe estar protegido ante una eventual caída o choque leve del robot.
X
X
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.
13.4.1
X
X
X
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
Robot para Automatización de Tareas de Invernadero
Informe de Estado de la Configuración
Versión 1.0
Autor: Jonatan Ponzo
Lanzamiento: Septiembre 2013
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
323
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
324
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
Histórico de Modificaciones
Fecha
23/02/13
Descripción del cambio
Creación del Documento
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
325
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
326
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
327
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
328
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
2.5.1.
Documentación
CI013: Documentos de Usuario
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
329
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
2.5.2.
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
330
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
•
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
331
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
332
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
1.0
2.2.2.
CI002: Código Fuente
1.0
2.2
Hardware
2.2.1.
CI003: Estructura
1.0
2.2.2.
CI004: Modulo Principal
1.0
2.2.3.
CI005: Sensores
1.0
2.2.4.
CI006: Actuadores
1.0
2.3
Entorno
2.3.1.
CI007: Circuito
1,0
2.3.2.
CI008: Sistema de Descarga de Información
1.0
2.4
Procesos
2.4.1.
CI009: Planificación
1.0
2.4.2.
CI010: Análisis y Diseño
1.0
2.4.3.
CI011: Implementación y Prueba
1.0
2.4.4.
CI012: Garantía de Calidad
1.0
2.5
Documentación
2.5.1.
CI013: Documentos de Usuario
1.0
2.5.2.
CI014: Documentos internos del proyecto
1.0
2.5.2.1.
CI015: Planificación
1.0
2.5.2.2.
CI016: Análisis y Diseño
1.0
2.5.2.3.
CI017: Implementación y Prueba
1.0
2.5.2.4.
CI018: Garantía de Calidad
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
333
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
334
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
Robot para Automatización de Tareas de Invernadero
Informe de Garantía de Calidad
Versión 1.0
Autor: Jonatan Ponzo
Lanzamiento: Septiembre 2013
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
335
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
336
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
Histórico de Modificaciones
Fecha
24/02/13
Descripción del cambio
Creación del Documento
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
337
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
338
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
10. Apéndices/Anexos
Apéndice A – Planilla de Reporte de Problemas
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
339
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
340
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
341
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
342
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
PLANIFICACIÓN
ANALISIS Y DISEÑO
IMPLEMENTACION Y PRUEBA
GARANTIA DE CALIDAD
Horas
Estimadas
36
71
61
26
Horas
Reales
41
53
46
28
TOTAL
194
168
Fase
Fig 2. Contraste de Estimación de Esfuerzo
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
343
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
A.1.1.6
A.1.1.1
A.1.1.2
A.1.1.3
A.1.1.4
A.1.3.1
A.1.1.5
A.4.3.3
A.1.2.7
A.1.2.4
A.1.2.8
A.1.2.1
A.1.2.9
A.1.2.2
A.1.2.10
A.1.2.5
A.5.1.1
A.2.1.1
A.2.1.2
A.2.1.3
A.2.1.4
A.2.2.1
A.2.2.2
A.2.2.3
A.3.1.1
A.3.1.2
A.3.2.3
A.3.1.3
A.3.1.4
A.3.1.5
A.3.2.1
A.3.2.4
A.3.2.5
A.5.1.1
A.3.3.2
A.3.3.5
A.3.3.1
A.3.3.4
A.4.1.1
A.4.1.2
A.3.3.3
A.4.2.1
A.4.2.2
A.4.2.3
A.5.1.4
A.5.1.2
A.5.1.5
A.5.1.6
A.1.3.4
A.5.1.7
A.4.1.3
A.5.1.1
A.5.2.1
A.5.2.2
A.5.2.3
A.5.1.1
A.4.3.1
A.4.3.2
A.5.1.8
A.1.2.10
Entendimiento del Negocio
Seleccionar un modelo de Ciclo de Vida
Realizar Estimaciones
Asignar Recursos
Definir Métricas
Gestión de Riesgos
Determinar objetivos de Seguridad
Implementación de un método de reporte de problemas
Planificación de la Gestión del Proyecto.
Planificación de la Instalación
Planificación de la Integración
Planificación de la Evaluación
Planificación de la Gestión del Lanzamiento
Planificación de la Gestión de la Configuración
Planificación del Mantenimiento
Planificación de la Documentación
Conducir Revisiones
Identificar ideas o necesidades.
Formular soluciones potenciales.
Conducir estudios de viabilidad.
Refinar y Finalizar la idea o necesidad.
Analizar las funciones del sistema.
Desarrollar la arquitectura del sistema.
Asignar los requerimientos del Sistema
Definir y desarrollar los requisitos del hardware
Definir y desarrollar los requisitos del Interfaces
Selección de la Arquitectura de Hardware mas conveniente.
Definir los requisitos del entorno
Definir los requisitos de software
Integrar los requisitos
Realizar el diseño arquitectónico
Diseñar las interfaces
Realizar el diseño detallado
Conducir Revisiones
Crear el código fuente
Gestionar las versiones del Software
Configurar e integrar el hardware y las interfaces físicas
Realizar la integración
Ajustar parámetros del entorno
Configurar y adaptar interfaces con el entorno productivo y otros sistemas
Crear la Documentación operativa
Operar el sistema
Proveer de asistencia técnica y consultas
Mantener el histórico de peticiones de soporte
Desarrollar Procedimientos de prueba
Crear Matriz de Trazabilidad
Crear datos de prueba
Ejecutar pruebas
Almacenamiento de Registros
Reportar Resultados de la evaluación
Aceptar el producto en el ambiente operativo
Conducir Revisiones
Desarrollar la identificación de la configuración
Realizar el control de la configuración
Realizar la información del estado de la configuración
Conducir Revisiones
Identificación de necesidades de mejora del Software
Identificación de necesidades de mejora del Hardware y Entorno
Confirmar Acreditación de Seguridad
Planificación del Mantenimiento
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
344
2
16
2
2
1
1
1
1
2
2
1
2
1
2
2
2
1
2
2
2
2
4
4
3
2
2
2
3
2
1
4
2
14
2
14
1
2
1
1
1
5
4
0
0
4
3
0
5
1
2
1
1
2
2
1
1
1
1
1
2
EJECUTOR
12/01/13
13/01/13
13/01/13
13/01/13
13/01/13
13/01/13
13/01/13
13/01/13
14/01/13
14/01/13
14/01/13
15/01/13
15/01/13
15/01/13
16/01/13
16/01/13
16/01/13
23/01/13
23/01/13
23/01/13
23/01/13
24/01/13
25/01/13
25/01/13
25/01/13
26/01/13
26/01/13
26/01/13
27/01/13
27/01/13
07/02/13
07/02/13
10/01/13
10/01/13
13/01/13
11/02/13
11/02/13
11/02/13
13/02/13
14/02/13
11/02/13
14/02/13
14/02/13
14/02/13
21/02/13
22/02/13
22/02/13
23/02/13
22/02/13
22/02/13
22/02/13
22/02/13
23/02/13
23/02/13
23/02/13
24/02/13
24/02/13
24/02/13
24/02/13
25/02/13
HORAS
12/01/13
12/01/13
13/01/13
13/01/13
13/01/13
13/01/13
13/01/13
13/01/13
14/01/13
14/01/13
14/01/13
15/01/13
15/01/13
15/01/13
16/01/13
16/01/13
16/01/13
23/01/13
23/01/13
23/01/13
23/01/13
24/01/13
24/01/13
25/01/13
25/01/13
26/01/13
26/01/13
26/01/13
27/01/13
27/01/13
07/02/13
07/01/13
08/01/13
10/01/13
11/02/13
11/02/13
11/02/13
11/02/13
13/02/13
14/02/13
11/02/13
14/02/13
14/02/13
14/02/13
21/02/13
22/02/13
22/02/13
22/02/13
22/02/13
22/02/13
22/02/13
22/02/13
23/02/13
23/02/13
23/02/13
24/02/13
24/02/13
24/02/13
24/02/13
25/02/13
CANTIDAD
FINALIZACION
ACTIVIDAD
COMIENZO
CONTROL DE ACTIVIDADES
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ 41
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ 53
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ 46
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
JONATAN PONZO
A.1.3.5
A.1.3.3
A.5.1.3
A.5.3.1
A.5.3.2
A.4.3.4
A.1.3.6
Recopilación y Análisis de Métricas
Identificación de Mejoras al Ciclo de Vida
Conducir Auditorías
Implementar la Documentación
Producir y Distribuir la Documentación
Iteración del Ciclo de Vida
Cierre del Proyecto
TOTAL
EJECUTOR
24/02/13
25/02/13
HORAS
24/02/13
25/02/13
ACTIVIDAD
CANTIDAD
FINALIZACION
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
COMIENZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
2
1
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ
PONZOJ 14
154
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.
Recurso
Descripción
Costo
Estimado
Costo
Real
Kit ROBOT N6 V1.1
Kit Arduino, Carcaza, 2 Motores
2 Sensores IR, 2 Sensores Ultrasonido
$1.700,00
(Provisto por
la Universidad)
Provisto por
la Universidad
2 Sensores IR
Sensores IR para deteccion de marcas
$100,00
$64,00
1 Modulo MicroSD
Modulo Lecto-Grabador
de tarjetas micro SD
$80,00
$60,00
Cables y Conectores
Cables y Conectores necesarios
$30,00
$22,00
PC/Laptop
Necesaria para la generación del código
fuente y la integración del mismo con
el hardware
Entorno de Prueba
Materiales necesarios para el montaje
$0,00
(Provisto por
el Desarrollador)
$100,00
$120,00
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
345
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
346
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
347
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
348
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
349
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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 opensource 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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
350
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
351
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
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.
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
352
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
Apéndice A. Planilla de Reporte de Problemas
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
353
JONATAN PONZO
ANEXO IV – DOCUMENTOS DEL PROYECTO
TRABAJO FINAL DE LICENCIATURA EN SISTEMAS
CONTROL DE ROBOTS AUTÓNOMOS MÓVILES BASADOS EN ARQUITECTURAS DE SISTEMAS EMBEBIDOS.
354
JONATAN PONZO
REPORTE
ID
FECHA
PROPIETARIO
DEL PROBLEMA
FASE
DESCRIPCION
CORRECCION
SOLUCIONES
POTENCIALES
SEGUIMIENTO
I001
FECHA
DESCRIPCION
11/02/13
11/02/13
PONZOJ
ANALISIS Y
DISEÑO
EL SENSOR DE HUMEDAD Y
TEMPERATURA DHT11 UTILIZA
UNA ENTRADA DIGITAL EN
LUGAR DE UNA ENTRADA
ANALOGICA
UTILIZAR UNA ENTRADA
DIGITAL DISPONIBLE
UTILIZAR UNA ENTRADA
ANALOGICA Y EL CONVERSOR
ANALOGICO DIGITAL
11/02/13
FINALIZADO
SI
SE UTILIZA LA ENTRADA
ANALOGICA S0 COMO
ENTRADA DIGITAL
N/A
11/02/13
PROPUESTAS
DE MEJORA
EJECUTOR
PONZOJ
NINGUNA
PONZOJ
SOLICITUD DE
CAMBIO: MEJ001
SI
ADAPTAR LAS LIBRERIAS
EXISTENTES
I002
PONZOJ
ANALISIS Y
DISEÑO
LAS LIBRERIAS PARA EL
MANEJO DEL MODULO
SDCARD EN ARDUINO
NO SON COMPATIBLES
CON DUINOBOT
UTILIZAR LA MEMORIA
EEPROM
NO ALMACENAR LOS
DATOS RELEVADOS
SINO VISUALIZARLOS
EN TIEMPO REAL
MEDIANTE EL MONITOR
SERIAL
N/A
03/02/13
I003
PONZOJ
EL SITIO WEB DEL ROBOTGROUP,
PROVEEDOR DEL HARDWARE
IMPLEMENTACION
DUINOBOT SE ENCUENTRA
Y PRUEBA
FUERA DE SERVICIO
SOLICITAR EL ENVIO DE
DOCUMENTACION Y
COTIZACION DE SENSORES
ADICIONALES POR
OTRO MEDIO
TRANSCURRIDA UNA
SEMANAEL SITIO
CONTINUA INACCESIBLE
SE UTILIZARA LA MEMORIA
INTERNA O BIEN EL MONITOR
SERIAL.
11/02/13 SE CONTACTA TELEFONICAMENTE
AL PROVEEDOR Y SE COORDINA
UNA VISITA PARA RETIRAR LOS
PRODUCTOS ADQUIRIDOS.
LA DOCUMENTACION ES ENVIADA
POR CORREO ELECTRONICO
ADAPTAR LAS LIBRERIAS
DISPONIBLES PARA ARDUINO
A DUINOBOT
PONZOJ
SI
NINGUNA