LA INGENIERÍA DE REQUERIMIENTOS EN SISTEMAS EMBEBIDOS DE TIEMPO REAL Silvia Rivadeneira, Juan Fontana, Andrés Prato, Diana Cruz, Fabián Altamirano Grupo de Investigación “Sistemas autónomos integrados” Instituto de Tecnología Aplicada Departamento de Ciencias Exactas y Naturales Unidad Académica Río Turbio Universidad Nacional de la Patagonia Austral
CONTEXTO La Ingeniería de Requerimientos es una rama de la Ingeniería de Software, una de las líneas de investigación de nuestro proyecto de investigación 29/C066 “Diseño y desarrollo de sistema de control para un UAV” cuyo periodo de ejecución será 2016- 2017. El proyecto se radica en la Unidad Académica Río Turbio y cuenta con financiamiento de la Universidad Nacional de la Patagonia Austral.
RESUMEN Este trabajo analiza casos de estudio relacionados con la ingeniería de requerimientos en sistemas embebidos de tiempo real para encontrar un método adecuado para nuestro desarrollo que nos permita trabajar adecuadamente en esta etapa. Palabras clave: ingeniería de software, ingeniería de requerimientos, sistemas embebidos, VANT
1. INTRODUCCION Aún hoy, bastante tiempo después de la crisis de software que tuvo como consecuencia el nacimiento de la Ingeniería de Software, algunas etapas o fases del proceso de desarrollo de software no se tienen en cuenta, y esto provoca que la gestión de proyectos de software no tenga resultados exitosos. A esto, se agregan dificultades adicionales, en el caso de los sistemas embebidos, debido a los siguientes hechos: (a) estos sistemas son realizados por expertos en electrónica sin conocimiento de esta disciplina; (b) ausencia de metodologías específicas que son reemplazadas por aquellas de propósito general sin adaptación a los sistemas embebidos; y (c) las metodologías existentes en el campo de sistemas embebidos no cubren todas las fases de IR [1]. Tal cual lo estipulan los autores [3] el proceso de la Ingeniería de Requerimientos, conlleva tres actividades: Elicitar los requerimientos de las distintas fuentes. Asegurar que las necesidades de todos los usuarios son consistentes y factibles.
Validar que los requerimientos que se derivaron son reflejo exacto de los requerimientos de los usuarios. La elicitación de requerimientos es el proceso de adquirir todo el conocimiento relevante necesario para producir un modelo de requerimientos de un dominio del problema [6]. Antonelli y Oliveros [5] nos permiten conocer las técnicas de elicitación que los desarrolladores argentinos utilizan mayormente, es así que el 100% utiliza las técnicas tradicionales, tales como: entrevistas, cuestionarios, encuestas y análisis de formularios; el 29% utiliza técnicas grupales como focus group y brainstorming, pero también el prototipado se encuentra con el mismo porcentaje; el 16% utiliza técnicas contextuales, así como observación de participantes, etnometodología, análisis de conversación; un 3% utiliza técnicas dirigidas por modelos como goalsbased o escenarios; dejando de lado aquellas que son denominadas cognitivas como análisis de protocolo, laddering, card sorting o repertory grids. Loucopoulos y Karakostas [6] mencionan las siguientes seis fuentes de elicitación: expertos del dominio, literatura sobre el dominio, software existente acerca del dominio, software de otros dominios, estándares nacionales e internacionales, y otros interesados del sistema. SWEBOK [7] muestra una visión más amplia donde se establece que las fuentes de los requerimientos pueden ser: los objetivos, el conocimiento de dominio, los interesados en el sistema, el entorno de operación y el entorno de la organización; y que entre las técnicas de elicitación se encuentran: las entrevistas, los escenarios, los prototipos, las reuniones y la observación. Por otro lado, en la elaboración de las especificaciones de un sistema es importante la notación empleada. Se pueden distinguir tres niveles de notación: Informal: Usualmente hace uso del lenguaje natural y varias formas de diagramas, generalmente imprecisos. Tiene la ventaja que lo puede entender cualquiera que conozca el idioma empleado. Estructurada: A menudo usa una representación gráfica pero, a diferencia de los diagramas de la notación informal, estos están bien definidos. Se construyen a
partir de un pequeño número de componentes predefinidos que se interconectan de una manera controlada. Aunque es una notación rigurosa, no puede ser analizado y manipulado de forma automática. Formal: Está basada en un lenguaje matemático y, por tanto, puede manipularse utilizando propiedades y métodos matemáticos. Tiene la ventaja que se pueden hacer una descripción muy precisa y, además, se puede hacer un estudio de las propiedades que poseerá nuestro sistema, como por ejemplo, que el diseño satisface la especificación de requerimientos. La desventaja del método formal es que no se entiende fácilmente si no se posee un dominio del lenguaje matemático utilizado en la notación. La alta seguridad que requieren los sistemas de tiempo real está provocando que, cada vez más, se estén utilizando métodos formales. Con estos se utilizan también técnicas rigurosas de verificación. La característica fundamental de los sistemas embebidos por ser sistemas abiertos es su interacción con el mundo exterior. Esto obliga que el sistema que se desarrolle deba incorporar requerimientos tales como los relacionados con disponibilidad, fiabilidad o seguridad; pero también hay que tener en cuenta, otras características de estos sistemas son las siguientes [8] [9]: Están compuestos de hardware y software, y ese software interactúa directamente con el hardware, por lo que resulta necesario poder representar comportamiento (estados, eventos, señales) y estructura. Existen relaciones jerárquicas entre el sistema embebido y el que lo contiene o bien entre el sistema embebido y otros sistemas del mismo nivel. El comportamiento se basa en el estado de los componentes. Gestionan eventos, que permiten conocer el cambio de estado de los componentes. Cuentan con recursos limitados como ser el tamaño, el consumo de energía, la memoria, y otros. No interactúan demasiado con el usuario, deben funcionar sin errores por mucho tiempo manejar la tolerancia a fallos, con un alto grado de autonomía. Presencia de sincronización y comunicación para permitir el flujo de información entre componentes. Los requerimientos no funcionales mencionados deben definirse en etapas tempranas.
La mayoría son pensados para control y por
Rescate/ Búsqueda de Personas Control de Obras Control Fiscal Control de campos Aplicaciones
Vigilancia Fronteriza Control de Aire Zonas Rurales Biología
Investigaciones
Requerimientos Operacionales
Vientos
Fitosanitario: Seguimiento de masas Forestales
Largo alcance Entorno Zonas montañosas
Zonas nevadas
Figura Requerimientos operacionales de un VANT según aplicación. sus características son fácilmente controlables. En el caso particular de los VANT en la Figura 1 podemos ver algunos requerimientos no funcionales según su aplicación. Algunas metodologías orientadas a sistemas embebidos permiten expresar requerimientos funcionales pero no así los requerimientos no funcionales. Son orientadas al diseño e ignoran las actividades de elicitación y análisis de requerimientos, tal es el caso de la metodología basada en el análisis de estados; o la metodología CARA específica para sistemas embebidos médicos, donde en el proceso se transforman requisitos de diseño informales a lenguajes formales, similar a las máquinas de estado finito [1]. La propuesta [1] interviene la metodología ABCBesoins diseñada para sistemas web adaptándola para que tenga aspectos del dominio de sistemas embebidos y permita construir un modelo conceptual que facilite la entrada a un lenguaje de especificación como SystemC. Los autores se deciden por esta metodología porque ofrece soporte para todas las fases del análisis de requisitos y provee un modelo de requisitos bien estructurado. Los autores [2], incluso, proponen un proceso de diseño basado en modelos, donde los mismos se crean para especificar los datos en el sistema, interfaces, lógica de control, lógica discreta y comportamiento en tiempo real. Aquí un diagrama de bloques o un modelo de diagrama de estado pueden servir como requisitos del sistema. El modelado de comportamiento permite especificar los requisitos y el diseño en todos los aspectos de cada subsistema.
La metodología HRT-HOOD (Hard Real-Time Hierarchical Object Oriented Desing) ha sido desarrollada, para la construcción de sistemas de tiempo real, considerados hard, los cuales por las limitantes de tiempo, una demora en su respuesta ocasiona una situación desastrosa. Esta metodología establece un ciclo de vida del software iterativo (ver Figura 2) y concurrente desarrollando tanto la arquitectura lógica, como la física. En este proyecto particularmente, ambas arquitecturas tienen la misma importancia. Haciendo que sean interdependientes entre ellas. Esta metodología tiene en cuenta las necesidades de los sistemas de tiempo real. En ésta el proceso de diseño se ve como una progresión creciente de compromisos específicos. Los compromisos definen las propiedades que se deben ir cumpliendo en el diseño del sistema y que el diseñador no puede modificar en niveles de mayor detalle. Aquellos aspectos del diseño que no suponen un compromiso en un determinado nivel se deben asumir como obligación es en los niveles inferiores (mayor detalle) del sistema. Las obligaciones en el nivel superior corresponden a las propiedades que aparecen en las especificaciones. Los compromisos son las concreciones que se hacen en el diseño que hacen que se cumplan las propiedades correspondientes a las obligaciones. El proceso de refinamiento del diseño consiste en ir transformando las obligaciones en compromisos. Este proceso está sujeto a restricciones impuestas principalmente por el entorno de ejecución .El entorno de ejecución es un conjunto de componentes software y hardware sobre los que se construye el sistema.
Figura 2. Metodología HRT-HOOD. Cada uno de estos compromisos se pueden describir con una serie de obligaciones que, a su vez, se podrán concretar en compromisos cada vez más detallados y sencillos. 2. LINEAS DE INVESTIGACION y DESARROLLO Básicamente los ejes de trabajo que se están manejando en esta línea son los siguientes: a) Elicitación de requerimientos.
b) Análisis de requerimientos. c) Especificación de requerimientos. d) Validación de requerimientos. En este contexto por tratarse de un proyecto de investigación (PI) experimental, nos encontramos que no existen grupos de usuarios específicos, aunque habría varios interesados en sus resultados. Los requerimientos nacen justamente de las necesidades que se propone suplir este PI. A continuación expondremos lo trabajado en cada eje. a) Elicitación. Se identificaron en primera instancia las características básicas que debe cumplir el modelo físico a desarrollar, (tipo de planos, características aerodinámicas básicas, relaciones peso/empuje, etc.) que a su vez responden a condicionantes climatológicas y geográficas. Este es el punto de partida de los requerimientos que el software debe cumplir (control, respuesta en tiempo real, autonomía en la toma de decisiones) ya que no es lo mismo un vehículo de planos rotativos a un vehículo de planos fijos, el software de control de dichos planos difiere de igual manera que difieren las características y capacidades de vuelo. Al incluir en el grupo un miembro con formación en ingeniería aeronáutica nos permitió obtener gran parte de los mismos. Revisamos la literatura especializada en el tema, así como también otros desarrollos relacionados, con el fin de obtener las características físicas del modelo. b) Análisis. Avanzando en la confirmación de las definiciones de las características físicas del modelo. Una particularidad concerniente al desarrollo de software embebido, con respecto a otro tipo de software, es justamente que este tipo software debe poder responder a las necesidades del mundo físico, es directamente dependiente del modelo, y su entorno. Tiene que proveer de las soluciones dentro de una gama amplia de situaciones cambiantes en tiempo real. Las actividades que realizamos fueron estudiar las diferentes opciones en herramientas que nos permitan proceder a obtener el software que cumpla con los requerimientos de simulación del modelo. c) Especificación. Se optó por seguir el IEEE Std 830-1998 [4] tratando de incluir toda la información necesaria, para que pueda ser validada y, más tarde, trabajada en la etapa de diseño de la solución. En cuanto a modelos gráficos seguramente se utilice UML (Figura 3).
desarrollo de trabajo final/tesis de carreras de posgrado. Durante el mes de agosto del corriente año la Lic. Cruz viajó a la ciudad de Buenos Aires para cumplir actividades en el marco de su beca. Durante el mes de septiembre el Dr. Giribet se trasladará hacia nuestra localidad para dictar el Curso de Posgrado “Sistemas de navegación integrada” que se encuentra en proceso de formalización.
Figura 2. Portada de IEEE Std 830-1998 d) Validación. Se consiguió reconfirmando los requerimientos obtenidos, validándolos con los usuarios. En este caso la utilización de ROS, con su herramienta de visualización RVIZ, el entorno de simulación GAZEBO, y la utilización de herramientas CAD/CAM. 3. RESULTADOS OBTENIDOS/ ESPERADOS Los resultados obtenidos luego de las actividades mencionadas en el ítem 2 siguen siendo trabajados en el grupo. El documento de especificación de requerimientos generado continúa en permanente actualización. El grupo está adquiriendo bibliografía actualizada que le permite conocer otros desarrollos similares y aplicarlos en el propio. La validación del documento se realiza desde la visión de los interesados en el sistema, pero principalmente hacia el interior del grupo. Esperamos refinar el documento hasta lograr algunas definiciones respecto a los requisitos no funcionales necesarios para el funcionamiento del VANT en nuestra región. 4. FORMACION DE RECURSOS HUMANOS Nuestro grupo de investigación está iniciando y, en 2015, se vinculó al Grupo de Procesamiento de Señales, Identificación y Control de la Facultad de Ingeniería de la Universidad de Buenos Aires, logrando que uno de sus investigadores principales y miembro del CONICET, el Dr. Juan Giribet dirija nuestro primer proyecto, y el plan de trabajo de la becaria de posgrado con la que contamos, la Lic. Diana Cruz. El resto de los miembros también se encuentran en formación ya que existen investigadores con categoría de incentivos IV y V, y en algunos sin categoría de investigación quienes están haciendo sus primeros pasos en estas actividades. Entre ellos hay dos integrantes que se encuentran en proceso de
5. BIBLIOGRAFIA [1] González, L. y Urrego, G. Modelo de requisitos para sistemas embebidos. Revista Ingenierías Universidad de Medellín. Vol. 7, No. 13, Pp. 111-127. Jul-Dic 2008. [2] Erkkinen, T. y Langenwalter, J. Desarrollo de sistemas embebidos steer-by-wire. REE. Pp. 56-60. Enero 2009 [3] Rzepka, W. E. "A Requirements Engineering Tested: Concept, Status, and First Results", en Bruce D. Shriver (Ed.) Proceedings of the 22nd Annual Hawaii International Conference of Systems Sciences, IEEE Computer Society, 1989. [4] Software Engineering Standards Comitee of the IEEE Computer Society. IEEE Recommended practice for software requirements specifications. 1998. [5] Antonelli, L. y Oliveros, A.: Fuentes utilizadas por desarrolladores de software en Argentina para elicitar requerimientos. WER. 2002. [6] Loucopoulos, P. & Karakostas, V.: System Requirements Engineering. Mc Graw Hill. 1995. [7] SWEBOK: Guide to the Software Engineering Body of Knowledge. En: http://www.computer.org/portal/web/swebo k/htmlformat. 2004. [8] MARWEDEL, P. Embedded system design. Kluwer Academic Publishers University of Dortmund. Germany. 2003. [9] LAVI, J, KUDISH, J. Systems modelling & requirements specification using ECSAM: an analysis method for embedded & computer-based systems”. Innovations Syst Softw Eng. 1: 100–115.
