seminario en el departamento GIM-TEISA


Hoy por la mañana hemos tenido un seminario de dos de nuestros compañeros (Fernando Herrera y Sara Real) que trabajan en uno de los proyectos europeos en los que participa en departamento (ANDRES) La presentación seminario, que en principio tenía que haber durado media hora al final se prolongó durante casi tres horas en las que se mezclaron tramos de presentación y discusiones. Yo tendré que hacer la mía sobre la marcha y entregable de nuestro proyecto para el próximo día 24 de Noviembre.

En el seminario, nos estuvieron explicando un poco la participación de nuestro grupo en uno de los entregables del proyecto ANDRES. En concreto un entregable en el que se implementa una librería para el modelado de software adaptativo. Esta librería se basa en SystemC y una librería llamada HetSC que forma parte del núcleo de la tesis doctoral de Fernando Herrera. La librería HetSC tiene una parte de generación de código en SystemC cumpliendo una serie patrones de diseño para diferentes modelos de computación mediante una herramienta complementaria SWGen.

Mediante una cuidadosa guía de modelado en la que se explican la utilización de varios patrones de diseño, se emplea HetSC y SWGen para el modelado de hardware reconfigurable y software adaptativo, poniendo énfasis en este último en el entregable de fin de este mes. En la guía de diseño se hace un uso extensivo de programación genérica (templates) y una separación de computación y comunicación reforzada por una programación adecuada (guía de modelado) en SystemC. La representación de los sistemas adaptativos se hace mediante procesos dentro de módulos que se comunican con otros módulos mediante puertos y canales.

Sara hizo un repaso del estado del arte en la programación y modelado de software adaptativo. El diseño de sistemas adaptativos implica tener hardware y software que cambie su comportamiento en función de un cambio en la especificaciones o de un cambio en el entorno (run-time adaptation) en el que opera de una forma autónoma (self-adaptive) La evolución de la programación desde la programación estructurada a la programación orientada a objetos ha permitido diseñar e implementar esos sistemas. Sara habló de modelos como el DAS (Dynamically Adaptive System) Model, del AC (Adaptive Component) Model (en la que hay una herramienta llanada CACTUS para sistemas distribuidos) También expuso lenguajes de programación específicos: Dylan, Lead++ (procedimientos adaptables en función del estado del entorno), Little-JIL (modelo de agentes)

Hubo un interesante debate en la definición de lo que era software adaptativo. Existe una diferencia semántica entre lo que considera el proyecto ANDRES como software adaptativo (un proceso con relación funcional entre entrada y salida en donde se tienen unas entradas básicas y una entrada de adaptación) y lo que se considera en la comunidad científica de Inteligencia Artificial por el mismo concepto (utilizando el paradigma de agentes software que tienen unos objetivos en forma de deseos e intenciones y que auscultan el entorno en busca de información sobre se estado en función de la cual realizan unas acciones que le afectan y que buscan maximizar su utilidad para conseguir los fines)

Eugenio Villar no quería entrar en ese terreno porque nuestra competencia es el hardware, no el software. Se intentó ofrecer la posibilidad de una nueva aportación que responda a la pregunta de: ¿ante un cambio en el hardware tras una reconfiguración (no se entra a valorar qué o quién ha ordenado ese cambio), cómo afecta eso al software? Y obtener una respuesta de modelado a nivel de especificación, que luego pueda ser refinada en el lado del software y/o hardware (codiseño)

Se propuso un diagrama por capas en la que se tenía un sistema heterogéneo en el fondo (compuesto por procesadores generales, procesadores específicos, aceleradores hardware, hardware reconfigurable, bloques analógicos) y una capa software por encima (nivel de abstracción hardware, drivers, RTOS, middleware y aplicaciones) y se hizo la pregunta de dónde debe ir la adaptación, debatiéndose si se podía lograr en los drivers …

En mi opinión lo que se intenta es programar agentes reactivos hardware que permitan la reconfiguración automática del hardware incluyendo la capa de software dependiente del hardware (HAL, drivers) Estos agentes tendrían una tabla de estados y acciones fija; deberían estar supervisados o creados por agentes deliberativos software que conocieran las posibles opciones de reconfiguración hardware y aprendieran del entorno y de las capacidades de las aplicaciones. Todo esto tiene intuyo relación con el campo del cognitive radio (software defined radio, etc.) donde se dan estas circunstancias de reconfiguración y adaptación del software.

Pongo aquí una serie de notas desordenadas que cogí durante la presentación por si me sirven de inspiración posterior:

  • Relación entre IP-XACT y la especificación de hardware y software adaptativo
  • aplicación de los conceptos del modelado orientado a objetos (encapsulación, herencia, polimorfismo, introspección por RTTI, interfaces, etc.), la programación genérica y los patrones de diseño (p.e factory, prototype, decorator, adapter, etc.) al modelado de software adaptativo
  • HetSC (UC), ForSyde (KTH): dominios (untimed, synchronous, …), tipos de adaptación (paramétrica, funcional, algorítmica, …)
  • Analogía entre lo que intentan hacer en ANDRES con la programación genérica y los patrones: generar clases parametrizables que modelen la capacidad de adaptación del la parte software de un sistema … me recuerda a las librerías estándar de C++ y Boost
  • ¿Cómo se modela la concurrencia en SystemC?
  • ¿Dónde se colocan los componentes adaptativos? (Sistema Operativo, Middleware, Aplicación); (HAL, Drivers) …
  • ¿Existen patrones de diseño en SystemC para modelar … concurrencia o software adaptativo o hardware reconfigurable?
  • Modelling and Simulating Self-Reconfigurable Systems: OSSS+R/FOSSY de Offis (Google Search)

Conclusiones

Esta presentación me ha servido de guía para planificar la mía. Y para intentar no hacerla tan larga. Yo creo que lo mejor es hacerla en 20 minutos y hacer un turno de preguntas. Las fases en que se puede dividir la presentación es una introducción de cinco minutos en la que se mete en contexto a la audiencia hablando del proyecto MULTICUBE y los casos de uso. Otros cinco minutos en los que se relata las (posibles) contribuciones del GIM-TEISA en el proyecto (SCoPE y el plug-in) Y otros diez minutos describiendo la carencias y posibles soluciones a aportar (con vistas a publicación, si es posible)

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s