Wiki » History » Version 1

Version 1/24 - Next » - Current version
Txinto Vaz, 08/10/2013 02:19 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 ante 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 uso de 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 empotrados 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. PSpice) 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 normativas de programación más estrictas que el software “clásico”. El ciclo de desarrollo más aceptado como estándar es, hoy en día, una variante del modelo en V: especificar, crear planes de prueba, diseñar, crear planes de integración, implementar, probar unitariamente, integrar, probar la integración, probar el sistema completo.

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 ADL (de hecho quiere converger a respetar dicho estándar en un futuro próximo), y también en herramientas de desarrollo comerciales.

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.

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