Wiki » History » Version 8

« Previous - Version 8/24 (diff) - Next » - Current version
Txinto Vaz, 08/10/2013 03:55 AM


Wiki

Introducción

Hoy en día no es normal que cualquier aplicación para un sistema embedded tenga restricciones de tiempo real y de seguridad. La programación “clásica” de los ordenadores ha ido derivando hacia sistemas petición/respuesta, donde el tiempo real no es un factor clave. La velocidad de los ordenadores y la lógica del “cuanto antes mejor” hacen que las aplicaciones de gestión acerquen su enfoque hacia la construcción de arquitecturas, ontologías basadas en orientación a objetos, escalabilidad, manejo de gran cantidad de datos a grandes velocidades, etc.

La programación de sistemas embedded, en cambio, aparenta mucha más sencillez en su arquitectura y con prestaciones menores. Sin embargo tanto los ya mencionados requisitos de tiempo real y seguridad, como la alta integración con otras disciplinas (hardware, mecánica, neumática...), así como su recurrente papel como controlador de sistemas retroalimentados, hacen que la dificultad de asegurar el correcto funcionamiento del conjunto sea mayor que en el caso anteriormente expuesto.

Los programadores amateur o las pequeñas empresas que se acercan a la programación / construcción de sistemas embedded carecen del trasfondo, conocimiento, o herramientas que les permitan abordar de forma coherente esa integración con el resto del sistema, o garantizar el cumplimiento de los requisitos de seguridad o de tiempo real.

En los sistemas embedded, la ingeniería de sistemas es fundamental para construir un dispositivo que funcione eficaz y eficientemente integrando varias disciplinas. El software, por tanto, debe poder dar visibilidad de la parte del sistema que implementa, y no puede ser una caja cerrada que sólo se puede validar correctamente en el momento de su integración.

Entre otras características, necesitamos que la arquitectura del software entronque funcional y arquitectónicamente con la del resto del sistema. También necesitamos la capacidad de simular el comportamiento del sistema completo antes de abordar la construcción de cada una de las partes, por lo que el software (igual que la mecánica o electrónica) debe poder ser “maquetado” mediante modelos fácilmente evaluables e integrables con los modelos mecánicos y electrónicos, de la misma forma que una representación en ecuaciones diferenciales de una mecánica (p.e. un modelo Simulink) o una simulación de los componentes electrónicos (p.e. SPICE) lo hacen.

También es muy importante disponer de la fase de prototipaje, como lo hacen el resto de disciplinas, que nos permita conocer el funcionamiento del software antes de disponer de su plataforma final. Para ello hemos dispuesto de emuladores y placas de evaluación, que con las correspondientes adaptaciones hardware nos permitían mover motores y leer sensores antes de disponer de un hardware final, y antes de cerrar el desarrollo del software como un todo. Pero, sin embargo y al contrario de otras disciplinas, este prototipaje en software puede ser adelantado probando el mismo código fuente incrustado en un modelo como los mencionados en la etapa anterior.

El software embedded, como el software clásico, también necesita ser verificado y validado, y además debe acogerse a unas directrices de programación más estrictas que el software “clásico” (p.e. el MISRA C). El ciclo de desarrollo más adoptado por los desarrolladores es, hoy en día, una variante del Modelo en V, que nos impulsa a especificar, crear planes de prueba del sistema, diseñar, crear planes de integración, implementar, probar unitariamente, integrar, probar la integración, y probar el sistema completo casi siempre en ese orden.

Por último, la gran mayoría de software embedded es, en un porcentaje muy alto, una suma de sistemas combinacionales y secuenciales implementando automatismos. Podríamos decir que desarrollar software embedded es diseñar e implementar multitud de máquinas de estado finitas y deterministas. La máquina de estado finita es una estructura de sobras conocida y, por tanto, hay que asegurar que el desarrollador dispone de herramientas para diseñar máquinas de estado, y de motores que codifiquen automáticamente dichas máquinas de estado en código fuente. También es deseable para los requisitos “combinacionales”. Programar una y otra vez a mano cada una de las máquinas de estado, definiendo sus variables, sus condiciones, etc. no sólo es poco productivo sino que a la vez es peligroso.

Aunque quedan muchísimas características que deberíamos pedir al software embedded, a su proceso de desarrollo y a sus desarrolladores, podemos concluir ya que una suite de herramientas que nos ayude a que nuestro software cumpla todas éstas características es muy conveniente, productivo, beneficioso, y suma muchas garantías al correcto y seguro funcionamiento de nuestro software final. De hecho, los más importantes desarrolladores de software embedded cuenta con su propio ToolKit de desarrollo o paga licencias (normalmente muy caras) por software comercial que le permita trabajar al nivel exigido por el mercado y las normativas internacionales.

Cambiemos ahora el foco hacia el desarrollador amateur, el estudiante, la pequeña empresa con bajo presupuesto, el experto que quiere hacer sus propios proyectos, las organizaciones sin ánimo de lucro que quieran desarrollar algún dispositivo beneficioso para su comunidad, el tan de moda hoy en día desarrollador/consumidor de circuitos electrónicos con licencia abierta (Arduino)... Podríamos decir que se encuentran en la siguiente disyuntiva: o trabajar sin herramientas o usarlas ilegalmente. Es decir, en desarrollos embedded nos encontramos en la misma situación que en desarrollo de software “clásico” antes de la irrupción y control del estado del arte que ha ejercido el código libre o gratuito. De la misma forma que hoy LibreOffice, NetBeans, Eclipse, Blender, Inkscape, Gimp, Ruby on Rails, Java, PHP proporcionan alternativas consistentes (cuando no dominan directamente su sector) se necesita una o varias alternativas abiertas que permitan eliminar este abismo entre los grandes y pequeños desarrolladores.

uCANca pretende ser una de esas alternativas. Más que un producto es un ciclo sencillo de desarrollo que combina herramientas ya existentes en el mercado con otras específicas del proyecto. Se ha inspirado en lenguajes de modelado como AADL (de hecho quiere converger a respetar dicho estándar en un futuro próximo), y también en herramientas de desarrollo comerciales.

Funcionalidades de uCANca

uCANca (de momento) no puede proporcionar toda la variedad de diferentes maneras de desarrollar software embedded, no pudiento, por tanto, competir con muchas herramientas comerciales, pero sí intenta dar al menos una solución para el modo más común de desarrollar este tipo de sistemas, intentando no cerrar la puerta y seguir siendo útil para el resto. En general se encuentra actualmente enfocado hacia la automoción, y centrado (aunque no cerrado) en la creación de software de ciclo de tiempo fijo (no multitarea, ver http://www-verimag.imag.fr/~maler/Papers/caspimaler.pdf) que comparte la información en una biblioteca de variables llamada comúnmente Data Runtime Environment (DRE).

A continuación mostramos una lista de las cosas que se pueden (o podrán en un futuro próximo) hacer con uCANca.

  • Realizar una arquitectura modular de un sistema, detallando a cada módulo:
    • Sus flujos de entrada y salida.
    • Los submódulos que lo forman.
    • Las funcionalidades que debe cumplir.
      • Definir los test que comprueban el cumplimiento de esas funcionalidades.
  • Generar el Data Runtime Environment para el microcontrolador (o los microcontroladores) que ejecutarán el software del proyecto. Podemos entender este Data Runtime Environment como las variables que contendrán todos esos flujos de entrada y salida tanto del sistema como de cada uno de los módulos que lo componen.
  • Generar automáticamente el código fuente de la librería de entrada y salida del microcontrolador (o microcontroladores), incluyendo todas las entradas y salidas analógicas, digitales, por pulsos PWM, o mensajes de buses de comunicaciones (CAN, Serie, etc...).
  • Diseñar las máquinas de estado que deban estar contenidas en el software, asociándolas a cada módulo que vaya a implementarlas, y permitiendo fácilmente al desarrollador su acceso al Data Runtime Environment.
  • Generar automáticamente un proyecto de CodeDesigner RAD (editor de máquinas de estado open source) con todas las máquinas de estado del proyecto, para que el usuario pueda completarlas y generar el código fuente desde él.
    • En un futuro próximo también se quiere conseguir una sincronización entre el software de definición modular y el proyecto de CodeDesigner RAD, de forma que el usuario pueda diseñar o refinar las máquinas de estado en cualquiera de las dos plataformas en cualquier momento del desarrollo.
  • Generar automáticamente los mecanismos de diagnóstico necesarios para cada bloque funcional o cada flujo. Estos mecanismos permitirían al operario de test (o al test automatizado), por ejemplo, suplantar la señal de un sensor para probar el software en todas las condiciones de su entrada, o manejar a voluntad una variable de salida para probar el funcionamiento de un motor, una mecánica, o alimentar a voluntad el software que la consuma. Podría también, en un futuro próximo, generar la librería que de servicio a un protocolo de diagnóstico como UDS.
  • Generar automáticamente los ficheros en A2L que permiten calibrar cada una de las variables del Data Runtime Environment mediante protocolos como CCP, XCP, con la seguridad de que las funciones de transferencia implicadas en dichas calibraciones se cambian a la vez en el código fuente del microcontrolador y en el fichero A2L de la herramienta de calibración.
  • Generar automáticamente la librería de AutoDiagnóstico (On board diagnostics) del sistema embedded a partir de una tabla de especificación de dicho autodiagnóstico, siguiendo el mecanismo clásico de la detección /calificación /recuperación /rehabilitación que posibilita el cumplimiento de los estándares tipo ODBII.
  • Generar automáticamente el “esqueleto” de XCos (del paquete Scilab, alternativa open source de Matlab/Simulink) de toda (o parte) de la arquitectura y los flujos de información. De esa manera es muy rápido y fácil construir el modelo de funcionamiento para integrarlo con modelados de la mecánica y del hardware.
    • Gran parte de la tarea de dichos modelos está en la elaboración de las cajas de cada módulo, de los flujos (y sus tipos y nombres) que conectan cada módulo, por lo que ésta funcionalidad es altamente productiva.
    • También facilita después la “incrustación” del código fuente para su test sobre el propio modelo.
    • También está pensada para que en un futuro puedan incluirse automáticamente los test de las funcionalidades en dicho modelo XCos.
uCANca consta en la actualidad de tres herramientas web que se apoyan en otros programas de la comunidad de código abierto para realizar su trabajo:
  • uCANca-ODB: Permite especificar los autodiagnósticos y genera las librerías de detección de los mismos así como la generación de códigos ODBII.
  • uCANca-Calib: Permite especificar flujos y las funciones de transferencia asociadas y crea el código fuente que las inicializa dentro del microcontrolador, y el fichero A2L que la herramienta de calibración necesita para realizar su función sobre dichos flujos.
  • uCANca-Arch: Realiza el resto de funciones enumeradas anteriormente.

En un futuro próximo se desean unificar éstas tres herramientas en una única que las englobe.

A qué debe uCANca su nombre?

Lo primero, al Llano de Ucanca, en las cañadas del Teide. Lo segundo, es un juego de palabras. “u can” (en inglés “you can”) expresa una de los objetivos del proyecto: que cualquier desarrollador sin gran presupuesto pueda hacer software de calidad. También es muy recurrente en automoción que aparezca la palabra CAN en todas las herramientas centradas en ese bus, y el germen de uCANca fue precísamente ese: un generador automático de código realizado por Txinto Vaz para el proyecto de final de carrera de la FIB-UPC. Dicho generador era capaz de tomar un modelo Simulink donde aparecían varios microcontroladores unidos por el bus CAN y cuya funcionalidad estaba modelada con Stateflow y generaba el código para cada uno de esos nodos (al menos parcialmente en el proyecto). Una de las tareas “satélite” del proyecto sería recuperar ese uCANca-Legacy para aquellos usuarios que puedan disponer de Simulink/Stateflow y quieran aprovecharlo en sus desarrollos. La última es que es el nombre de una pequeña bonita y muy valiente gata callejera que vive en la calle Pi de Abrera, uno de esos animales que, por lo especiales, mejoran a las personas.

Esperamos que lo leído aquí te haya motivado para seguir interesado en nuestro proyecto.