Metodología para el diseño de Sistemas robóticos Autónomos

Como los sistemas robóticos autónomos son intrínsecamente más complejos es cada vez más claro que los métodos de diseño ad-hoc(solución especifica) no podrán ofrecer un rendimiento predecible y garantizado. En este trabajo se motiva la necesidad de un proceso de diseño racional del sistema y da la propiedades necesarias y la estructura requerida que un proceso debe tener.

El campo de la robótica es inherentemente interdisciplinaria y abarca la mayoría de áreas de las ciencias naturales e incluso los diversos aspectos de la gestión de proyectos y de las ciencias sociales. Cada disciplina de las ciencias naturales ha sido objeto de intensa investigación a través de las últimas décadas, y presenta un ritmo cada vez mayor de componentes sofisticados y más complejos para el mercado. De igual manera hay un apoyo a la creciente demanda de nuevos servicios a los consumidores industriales y soluciones para robot. Un gran número de estas soluciones en el futuro se basa en robots móviles capaces de tener un comportamiento autónomo en un contexto específico, ya sea de limpieza en el hogar, el corte de grama en un campo de golf o el transporte de unidades en un hospital.

Tradicionalmente, los robots móviles se han aplicado en dos escenarios principales:

1) Como simples unidades de transporte en entornos estructurados ejemplo: para los pisos de fábrica o 2) como plataformas de investigación concebidas en los laboratorios para el ensayo de diversas investigaciones específicas de componentes - por ejemplo los sistemas de navegación nuevos o arquitecturas de control. La nueva generación de robots móviles colocados en entornos no estructurados y desconocidos, posiblemente, tienen tareas muy específicas para llevar a cabo, y se ven limitados en diversas formas por los requisitos rigurosos de seguridad en las empresas, el cumplimiento legal y social, la estabilidad, robustez, mantenimiento, operatividad, el costo y los criterios de rendimiento evidente.

En esencia, el campo de la robótica móvil se está desplazando de un dominio mecatrónico puro a un dominio más socio-técnico, donde las personas son las que usan e interactúan con los robots, los procesos operativos y las propiedades emergentes de los sistemas en su conjunto es crucial. En este artículo nos referimos a la constelación de robots autónomos, sus usuarios, el medio ambiente en el que trabajan y las tareas que llevan a cabo como un sistema de robot autónomo, y, si nos enfocamos en un contexto para un servicio orientado de índole industrial, el sistema robótico autónomo es abreviado como ARS.

Hoy, cuando los investigadores y desarrolladores del robot han de concebir y diseñar un nuevo robot, el proceso es a menudo guiado por varios diseños "locales" de cada uno de los enfoques vinculados a un dominio específico, lo que resulta en un enfoque natural hacia los componentes del sistema, más que en el sistema en su conjunto. Estos tradicionales enfoques "de los componentes de diseño" suelen ser suficientes en la solución del diseño de las partes de un sistema, pero, si un robot completo o sistema robótico tiene que ser concebido, lo más probable, es que un inevitable proceso de integración se guié únicamente por la experiencia y los enfoques ad-hoc. En nuestra experiencia esta práctica conduce a menudo en sistemas que no obedecen a sus requisitos iniciales del sistema y puede en el peor de los resultados en provocar un total colapso del proyecto - esto, por supuesto, dependiendo de la complejidad del sistema.

Como los robots cada vez más entran en nuestros hogares y se convierten en partes integrantes de las unidades de servicio en los hospitales, el cumplimiento social y legal deben ser garantizados por el proveedor. Estas cuestiones no son fáciles de abordar después que un robot ha sido ideado, pero esto debe ser inherente y necesario como parte del diseño desde el principio. En estos casos la necesidad de un proceso racional en el diseño del sistema se hace particularmente urgente.

El enfoque de diseño ad-hoc para un robot ya no es suficiente y se requiere un enfoque que sea capaz de equilibrar el diseño (o elección) de sistemas físicos para robots y sus componentes, su entorno de trabajo, y las tareas que se requieren para resolver, bajo las restricciones que imponen las necesidades tanto del sistema y los niveles de los componentes. Este punto de vista es esencial, ya que sólo se mantiene el enfoque en el diseño, mientras que a nivel de sistema el manejo del nivel de los componentes puede ser concebido como un diseño que puede dar cuenta de las complejas interacciones interdisciplinarias inherentes a los sistemas de robóticos .

El propósito de este trabajo es ofrecer los primeros pasos hacia la elaboración de una metodología de diseño racional de las ARS. Este documento se centra principalmente en las propiedades necesarias y la estructura de tal metodología de diseño y sólo ligeramente frente a la manera de aplicarlo en la vida real.

TRABAJOS PREVIOS

La ingeniería de Software tiene una larga historia a nivel de sistemas en las interfaces de usuario, el mantenimiento y las consideraciones económicas junto con el diseño actual de la funcionalidad del software, son cuestiones clave que a menudo se toman en cuenta. Se pueden encontrar ejemplos al considerar, el ámbito del Análisis Orientado a Objetos y el Análisis y Diseño (OOAD) y la Programación Extrema.

En el diseño de la electrónica digital y los sistemas integrados que contienen por ejemplo, Field Programmable Gate Array (FPGA) y micro-controladores, y existen diversos métodos de diseño a nivel de sistema. Un ejemplo de ello es una metodología de diseño basado en UML para tiempo real y sistemas integrados.

En la ingeniería tradicional para el control Robótico, existen algunos enfoques más amplios a nivel de sistemas, que se preocupan por el diseño de configuraciones modulares de la cinemática de los robots para adaptarse a la propuesta en los contextos de aplicación, como es por ejemplo el caso de la obra de Farritor y Paredis.

En el ámbito de la Ingeniería de Sistemas existen varios métodos a nivel de sistemas, sin embargo, lo mejor de nuestro conocimiento no se ha aplicado directamente al campo de la robótica por lo menos con los resultados a disposición del público.

El campo de desarrollo de productos tradicionalmente enfocados a nivel de sistemas como los modelos de desarrollo que tratan todos los aspectos desde el desarrollo del concepto del producto hasta el mantenimiento. Algunos herramientas de uso frecuente en estos modelos, tales como Quality Function Deployment (QFD), se han aplicado a los sistemas de robótica. Sin embargo, no hemos encontrado ninguna referencia para sistemas robóticos completos que estén siendo desarrollados únicamente usando metodologías de desarrollo de productos.

Sólo disciplinas relativamente escasas dentro de la comunidad de investigación robótica parecen haber tratado con los enfoques de diseño a nivel de sistema orientado para el diseño completo de las ARS, y la mayor parte de este trabajo se basa en el diseño y la evolución de la arquitectura del controlador de los robots "o el propio controlador ya que es en el caso de muchas disciplinas en el campo de la IA (inteligencia artificial). De estos, el soportado por la IA es posiblemente la disciplina con la mayor atención para nosotros.

A partir de esta breve descripción de los métodos de diseño y metodologías diferentes y en nuestras experiencias personales, no creemos que una metodología actual de diseño completa a nivel de sistemas haya sido aún desarrollada para las ARS.


Propiedades de la Metodología

El objetivo general es una metodología de diseño que facilite la tarea de diseño de equipamiento de los diseñadores de sistemas robot con herramientas y directrices que permitan a él / ella para transformar 1) la tarea a realizar a cabo, 2) el entorno en el que el sistema debe funcionar y 3) las limitaciones impuestas, en una descripción del proceso que conduce a sistemas de diseños suficientes que cumplan los requisitos iniciales.

La descripción del proceso consistirá en técnicas de varios campos científicos que faciliten un proceso racional a nivel de sistema de diseño, mientras que al mismo tiempo vigila la gestión de los aspectos organizativos del proyecto. Los diseños de sistemas suficientes consistirá en juegos de diseño recomendados de los robots que se necesitan, de su diseño funcional, de la posible alteración del medio ambiente y de la posible la adaptación del pliego de condiciones de trabajo inicial. Estas recomendaciones describen los diferentes escenarios que conducen a soluciones del
problema inicial.

La estructura general de la metodología de diseño se esquematiza en la Fig. 1, donde la alteración del Medio Ambiente y la adaptación de tareas se denota como: Medio Ambiente* y Tareas*, respectivamente.
Con el fin de garantizar que la metodología de diseño propuesta pueda proporcionar los medios necesarios para manejar efectivamente un proceso de diseño que se traduce en diseños de sistemas suficientes, su estructura debe estar bien establecida. Buscando inspiración en Ingeniería de Software, Mathiassen dice: se trata de equilibrar la elección de un modo de operación, que puede ser analítica o experimental, y una elección de los medios de expresión, que puede ser las especificaciones o prototipos. Mathiassen resume sus resultados en lo que ellos llaman "El principio de reducción limitada" en el que sostienen que el éxito en el proceso de diseño de un sistema complejo(software) tiene que incluir modos tanto analíticos y experimentales de funcionamiento y las especificaciones y los prototipos como medio de expresión. Creemos que este principio se aplica igualmente bien al diseño de las ARS y por lo tanto, se puede utilizar como base para comparar y combinar diferentes enfoques de diseño.

Hemos identificado 12 criterios que consideramos esenciales en la metodología de diseño racional de las ARS, los primeros diez criterios ponen atención al nivel de proceso de diseño y los dos últimos el nivel de diseño de sistemas. Cada uno de los criterios se presentarán a continuación con un elaboración respectiva de síntesis de sus datos.

1. Facilitar un proceso de diseño racional: Un proceso de diseño racional implica que cada paso que se da está siempre en el camino óptimo a la meta. Estos procesos, obviamente, sólo existen en teoría, sin embargo es posible estar en un error si se sigue el proceso ideal. En la mayor medida posible la producción de la documentación debe ser por diseño racional.

2. Facilitar iteraciones: Desarrollo de prototipos de componentes y la realización de experimentos son parte integral de un proceso de diseño de un sistema robótico, ya que es a menudo la única forma de obtener la información necesaria para tomar decisiones racionales. Las iteraciones por lo tanto son imperativas en el proceso de diseño.

3. Ofrecer los medios para evaluar la idoneidad de un diseño: Es imprescindible una forma de evaluar la idoneidad de un determinado diseño de sistema. Esta medida permitirá un seguimiento continuo de los avances de diseño en general lo que facilita que el proceso de diseño puede ser lo más racional posible.

4. Facilitar la colaboración en el diseño: A menudo varios socios han de colaborar en el diseño y la construcción de un sistema robótico debido a su naturaleza intrínsecamente interdisciplinaria. Los medios para establecer qué competencias son requeridas para llevar a cabo un determinado proyecto, por lo tanto una metodología de diseño es necesaria.

5. Facilitar prototipos y montajes experimentales: Los prototipos y montajes experimentales a menudo crean ramas no deseadas en el proceso de un un proyecto. La metodología de diseño debe incorporar los medios para determinar qué tipo de construcción física es factible en un momento dado durante el proceso.

6. Proceso de obtención de resultados: Es imprescindible para producir prestaciones suficientes al final de cada incremento de diseño, que contenga como mínimo la documentación de procesos, la documentación de diseño y, posiblemente, cualquier construcción de prototipos.

7. Facilitar herramientas de diseño diferentes: La metodología de diseño debe proporcionar interfaces flexibles que permitan el empleo fácil de las herramientas especificas necesarias durante el proceso de diseño.

8. Ser fácil de explicar y usar: La estructura de la metodología, sus herramientas y los instrumentos específicos del proyecto constituyen el real método de diseño, y es importante que las tareas de diseño individual puedan ser fácilmente comunicadas y entendidas por las personas que realmente las lleven a cabo.

9. Permitir diferentes niveles de generalización: El diseño metodologíco debe apoyar el desarrollo de sistemas robóticos con varios niveles de generalización, es decir, sistemas que comprenden plataformas genéricas de robot a sistemas que abarcan plataformas de robot altamente especializadas.

10. Permitir diferentes niveles de autonomía: La metodología de diseño debería apoyar las soluciones que emplean los diferentes niveles de autonomía, es decir, sistemas que van desde aquellos robots controlados a control remoto hasta los robots autónomos.

11. Proporcionar un conjunto de soluciones: El diseño de un sistema robótico es una tarea compleja y, naturalmente, puede resultar factible en el diseño de varias soluciones si se sigue los requisitos iniciales y la solución de la tarea. La metodología de diseño debe ser capaz de producir estos conjuntos de soluciones y no desechar las soluciones antes de tiempo.

12. Producir documentación de diseño: Dado que el proceso de diseño es racional, los documentos de diseño entregados al final del proceso deben reflejar un proceso de diseño racional, es decir, un receta que muestra el progreso desde el análisis inicial del diseño hasta el diseño final en un solo paso, por lo que el proceso se enmarca en pasos estrictamente secuenciales.


Estructura de la Metodologia

Con el fin de ser una herramienta útil para el diseñador del sistema robótico la metodologia de diseño debe proporcionar un contexto homogéneo y racional en el escenario en el que tanto el diseño del proceso y el diseño real puede ser representado. Esto significa que los diversos componentes de la metodologia deben tener interfaces claras a componentes vecinos a fin de garantizar una metodología clara, pero adaptable.

Una opción natural es la de dividir el proceso en fases que representan el flujo secuencial del proceso incremental. Cada fase puede tienen varias iteraciones internas y al final producen un conjunto de las prestaciones que comprende la documentación, prototipos y, posiblemente, componentes. Esta estructura general se ha dibujado en la figura. 2.

Una fase inicial, pre-fase, es necesaria para procesar la información del dominio del problema y hacer un análisis preliminar en todo el proceso de diseño - por ejemplo las partes interesadas en el análisis y el análisis de las competencias necesarias para realizar el proyecto. La información también ayudará a establecer la estructura de gestión del proyecto.

Las fases posteriores, la Fase 1-Fase N, comprenden cada una las disciplinas necesarias para llevar a cabo el proceso de diseño para el sistema de que se trate. Varias herramientas y métodos normalizados del producto en Desarrollo, Ingeniería de Sistemas e Ingeniería de Software puede fácilmente ser utilizados para manejar las tareas del proceso más general y específicaciones tales como requisitos de cliente, pruebas y la planificación de la experimentacion, y gestión de proyectos, junto con el dominio de las tareas más específicas, como simulaciones de herramientas, aplicaciones CAD y equipos de prototipos rápidos. También una personalización por sistema a menudo se requiere en fin de dar cabida, por ejemplo, a requisitos particulares del proyecto. Si un sistema robótico basado en robots móviles se dio cuenta de que puede llevar a cabo tareas de personas con discapacidad, los conocimientos sobre, por ejemplo, el diseño, construcción y control de equipos especializados a tomar en cuenta puede ser crucial. Las herramientas que apoyen esto serán directamente aplicables en la metodología de diseño.


Comparaciones

Muchas contribuciones existen en los campos relacionados con la Ingeniería del Software e Ingeniería de Sistemas. Ambos llevan muchos años contribuyendo a la teoría y la la práctica de métodos y metodologías y, por tanto forman una base natural de comparación con nuestra propuesta.

Ocho métodos han sido elegidos para la comparación: El Proceso Unificado(UP), el modelo de cascada (WM), el modelo en espiral (SM), Extreme Programming (XP), NASA's, DoD's-,-y INCOSE's y SMC metodologías de ingeniería a sistemas. En la Tabla 1 se muestra cada método y se evalúa en relación con las propiedades requeridas presentadas anteriormente, y están marcados con una "x"si el método admite la la propiedad.

La comparación revela que dentro de la Ingeniería de Software, el Proceso Unificado (UP) y la programación extrema parecen los métodos que cumplen los mejores criterios. El modelo TheWaterfall se cae por si mismo y el modelo en espiral es más un modelo de referencia que un modelo fijo - sin embargo este último se puede adaptar a las necesidades requeridas.

Dentro de Ingeniería de Sistemas, las metodologías de prueba identificadas estan en la actualidad todas llenas de modelos en desarrollo repartidos con los criterios exigidos más o menos de la misma manera. Sin embargo, su ámbito de aplicación es muy extenso y dedicado principalmente a equipos militares de alto rendimiento, lo que potencialmente les hace engorroso de aplicar en nuestro contexto. Esto no los descalifica en cualquier camino, pero nuestra impresión es que a lo largo de nuestro progreso en la investigación encontramos cuestiones específicas que requieren una metodología más de diseño dedicado.

La conclusión es, que los métodos y metodologías existentes en ambos Ingeniería del Software e Ingeniería de Sistemas se pueden utilizar adaptandolos - por lo menos parcialmente - en el diseño de las ARS. Eso implica que varios conceptos, métodos e ideas de los casos de prueba ayudarán a dar forma a nuestra metodología y así deberán ser parte directa en su caja de herramientas finales.


Autores:
Lars Dalgaard
Danish Technological Institute
Centre for Robot Technology
Forskerparken 10
DK-5230 Odense M
Denmark

John Hallam
Maersk McKinney Moller Institute University
of Southern Denmark Campusvej
55 DK-5230 Odense M Denmark

Traducción y adaptación: ESCRITOR DE LETRAS