Download Generación automática de código para sistemas - FCEIA

XV Reunión de Trabajo en Procesamiento de la Información y Control, 16 al 20 de septiembre de 2013
Generación automática de código para sistemas embebidos con PowerDEVS
Martı́n Moncada†‡ , Ernesto Kofman†§ , Federico Bergero†§ y Leandro Gentili‡
† Facultad de Cs. Exactas, Ingenierı́a y Agrim., UNR, Argentina
‡ FORKWORKS
mmoncada1989@gmail.com - lgentili@forkworks.com
§ CIFASIS-CONICET
kofman@fceia.unr.edu.ar - fbergero@fceia.unr.edu.ar
Resumen— En este trabajo se presenta una extensión del software de modelado y simulación PowerDEVS que permite generar automáticamente código
para plataformas ARM embebidas. Esta nueva funcionalidad permite construir el modelo de un sistema
de control en PowerDEVS y, de manera completamente automatizada, realizar la compilación y su escritura
a la memoria flash de un microcontrolador ARM.
En el artı́culo se describen los principales detalles
de la implementación y se muestra un ejemplo de aplicación consistente en el control embebido de un motor
brushless.
P alabras Clave— Sistemas Embebidos, ARM,
DEVS, Rapid Prototyping
1.
INTRODUCCIÓN
La gran mayorı́a de los sistemas de control que se
implementan actualmente son embebidos, es decir, utilizan internamente microprocesadores dedicados para cerrar sus lazos de control. Los sistemas embebidos son
usuales en fábricas, plantas de procesamiento quı́mico,
aviones, automóviles, etc. [1].
Las etapas de diseño de un sistema de control embebido involucran el modelado de la planta, el diseño de la
ley de control y la implementación del controlador en el
dispositivo embebido.
Tanto en las etapas de modelado como en las de diseño del control, se recurre a la simulación para verificar
y ajustar los parámetros de la planta y el controlador. Una
vez que los resultados de simulación son satisfactorios, se
procede a la programación de la ley de control en el sistema embebido.
Hasta hace poco menos de dos décadas, debido a la
baja performance de los microprocesadores disponibles y
falta de compiladores para ellos, la escritura del código
del controlador era un proceso manual generalmente realizado directamente en lenguaje Assembler. Con el advenimiento de los microprocesadores más modernos y poderosos y sus herramientas de desarrollo (compiladores,
depuradores), este enfoque fue cambiado sustancialmente [2].
Hoy en dı́a, se busca siempre generar el código del controlador en forma automática a partir del modelo utilizado
en el simulador. De esta forma, se reduce notablemente
el tiempo de implementación del sistema y se evitan muchos posibles errores de programación. Esta estrategia se
conoce como Rapid Prototyping, y existen actualmente
varios entornos de simulación que incluyen la posibilidad
de generar automáticamente código para sistemas embebidos siguiendo esta idea. Entre las herramientas comerciales más difundidas encontramos al Real Time Workshop de Matlab/Simulink [3] y LabView [4].
Basado en el uso de aproximaciones de eventos discretos, en los últimos años nuestro grupo desarrolló la herramienta de modelado y simulación PowerDEVS [5]. Esta
herramienta, libre y de código abierto, permite modelar y
simular sistemas continuos mediante aproximaciones de
Quantized State Systems [6, 7] y es muy eficiente en la
simulación de sistemas con discontinuidades. Su interfaz
es similar a la de Simulink y utiliza Scilab [8] como espacio de trabajo y de cálculo.
En lo que respecta a aplicaciones de control, una versión de PowerDEVS funciona bajo un sistema operativo
de tiempo real (Linux RTAI) [5] y, al estar basado en un
motor de simulación de eventos discretos, permite implementar no sólo estrategias de control digital clásicas sino
también distintos tipos de controladores ası́ncronos [9].
Sin embargo, una limitación de PowerDEVS es que
ciertas caracterı́sticas del motor de simulación y de los
controladores está limitada a la arquitectura PC.
En este trabajo, motivados por dicha limitación, presentamos una extensión a PowerDEVS que permite generar código automáticamente para sistemas embebidos basados en plataformas ARM. Esta extensión permite desde
la propia interfaz de PowerDEVS grabar en la memoria
flash de un microprocesador ARM el programa que implementa un modelo (controlador) previamente simulado
en la PC.
Además de describir la herramienta desarrollada, presentamos resultados del uso de la misma en el control
embebido de un motor brushless.
XV Reunión de Trabajo en Procesamiento de la Información y Control, 16 al 20 de septiembre de 2013
2.
2.1.
CONCEPTOS PREVIOS
PowerDEVS
PowerDEVS [5] es una herramienta de modelado y simulación basada en el formalismo DEVS [10]. El módulo
principal de PowerDEVS es un editor gráfico de modelos
que permite editar diagramas de bloques al estilo Simulink como muestra la Fig.1.
Desde el punto de vista de un usuario, PowerDEVS
ofrece una funcionalidad similar a la de Simulink. Sin
embargo, sus bloques utilizan un formalismo clásico
(DEVS) y están programados en C++, lo que permite a cualquier usuario programar nuevos bloques con
cualquier funcionalidad que permita el lenguaje C++.
Además, su motor de eventos discretos le permite implementar eficientemente algoritmos de control ası́ncrono.
2.2.
Figura 1: Pantalla principal de PowerDEVS.
Cada bloque de un modelo tiene asociado un código
en C++ que determina el comportamiento del mismo. Dichos códigos pueden ser editado mediante un editor provisto por PowerDEVS o bien, por cualquier editor de texto.
Los bloques pueden ser creados por los usuarios o pueden arrastrarse desde las librerı́as de PowerDEVS, que
contienen un conjunto completo de bloques funcionales
para simular sistemas continuos, discretos e hı́bridos basado en los métodos de QSS además de bloques de entrada y salida de datos. Todos los bloques de las librerı́as
además pueden tomar parámetros desde el espacio de trabajo de Scilab. A la izquierda de la Fig.1, por ejemplo,
pueden verse parte de la librerı́a de bloques para sistemas
Continuos.
Al invocar la ejecución de una simulación, el preprocesador de PowerDEVS genera automáticamente el código C++ que representa la estructura del modelo y ésta
se compila junto con los códigos de cada bloque y el del
motor de simulación. Esto genera un programa ejecutable
que realiza la simulación y puede ser comandado desde
la interfaz de PowerDEVS. Para la compilación de los
modelos, PowerDEVS utiliza la GNU Compiler Collection (GCC) que brinda una solución Open Source, libre y
multiplataforma.
Las simulaciones pueden realizarse tanto de manera
off–line como en tiempo real (es decir, sincronizadas con
un reloj fı́sico). Esta última opción es la que permite implementar sistemas de control. PowerDEVS fue concebido como una herramienta multiplataforma, y funciona bajo Linux, Windows y bajo el sistema operativo de tiempo
real Linux–RTAI, que permite sincronizar con precisión
de 1 µseg. las simulaciones de tiempo real en una PC.
Arquitecturas ARM
La arquitectura Advance RISC Machine (ARM) [11]
es una familia de procesadores RISC de 32 bits de
propósito general. Por sus caracterı́sticas (bajo consumo
energético, menor disipación de calor, bajo costo) son
muy utilizados en dispositivos embebidos y portátiles como celulares, tablets, netbooks, etc.
Los procesadores ARM cuentan con el soporte necesario para ejecutar un sistema operativo (protección, memoria virtual, etc) tal como los sistemas especı́ficos (iOs,
Android, VxWork, etc) o sistemas de escritorio como
Linux, lo cual facilita el desarrollo y la depuración de
las aplicaciones realizadas. En dispositivos con memoria reducida normalmente se desarrollan soluciones baremetal, esto es, sin sistema operativo.
2.3.
Herramientas libres para ARM
El proyecto GNU ha desarrollado varias herramientas
libres para la arquitectura ARM. Estas incluyen:
Soporte en el compilador C/C++ (gcc) para generar
código ARM.
Un depurador (gdb) que permite realizar ejecuciones Debug-On-Chip.
Una implementación simplificada de la librerı́a
estándar C, llamada newlib.
Estas herramientas conforman el ARM toolchain y son
utilizadas para obtener un binario ejecutable para arquitecturas ARM. Luego este binario debe ser escrito en la
memoria flash del procesador. Para ello, se utiliza un dispositivo llamado programador.
En general cada programador se distribuye con su software y controladores pero muchas veces éste se ejecuta
en plataformas Windows y no es de código abierto. Otra
opción es utilizar la herramienta libre Open On-Chip Debugger (OpenOCD) [12] que tiene soporte para múltiples
programadores y se conecta con el depurador GNU (gdb)
para realizar las ejecuciones on-chip.
Juntos, el ARM toolchain y OpenOCD, proveen un
marco libre y sin costo, para desarrollar sistemas embebidos sobre arquitecturas ARM.
3.
DESARROLLO
En esta sección describimos el trabajo realizado para
que PowerDEVS genere automáticamente el código para
su uso en arquitecturas ARM.
XV Reunión de Trabajo en Procesamiento de la Información y Control, 16 al 20 de septiembre de 2013
3.1.
Hardware utilizado
Para la demostración de este trabajo, la empresa ForkWorks cedió un equipo consistente de dos placas de desarrollo Hitex (“LPC2939” y “LPC-BLDC Motor Control
Board”), un programador N-Link y las fuentes correspondientes.
La placa LPC2939 contiene un microcontrolador del
mismo nombre y diversos periféricos. De ellos, se utilizaron los dos display 7-segmentos (usados en conjunto),
una entrada analógica a través de un potenciómetro, y un
puerto serie.
El microcontrolador contiene un núcleo ARM91 ,
768Kb de memoria Flash y 32Kb de memoria RAM interna. También se encuentran integrados diversos periféricos, en este ejemplo se hizo uso, principalmente, de los
timers y los puertos de entrada-salida.
La segunda placa cuenta con una luz LED y un motor
BLDC (BrushLess Direct Current), con el correspondiente hardware para su excitación, y sensores Hall.
La Figura 2 ilustra los dispositivos mencionados.
Sin embargo, tanto las funciones de sincronización como las de entrada–salida son especı́ficas del sistema operativo. De hecho, el motor de simulación de PowerDEVS
contiene una implementación distinta de las mismas para
cada uno de los tres SO soportados (Linux, Windows y
Linux–RTAI).
Por esto, se realizó una implementación especı́fica para
ARM con la particularidad de que, por razones de eficiencia, la misma funciona sin sistema operativo (implementación bare–metal).
Las funciones implementadas a nivel de motor incluyen:
Lectura de un timer de microcontrolador. Reemplazamos también la llamada clock de la librerı́a de
C para utilizar este timer.
Funciones de Entrada/Salida via puerto serie.
Aquı́ también modificamos las llamadas de librerı́a
C correspondiente (printf,scanf,etc).
Dado que en ARM no se tiene una instancia de Scilab ejecutando, implementamos una funcionalidad mı́nima en el
motor de simulación PowerDEVS para soportar el uso de
parámetros vectoriales y matriciales. El resto de las funciones especı́ficas, que involucran comunicación con Scilab o lectura/escritura de archivos, fueron sólo definidas
como dummy functions.
Las funciones implementadas tienen parámetros que
dependen del hardware especı́fico utilizado, como por
ejemplo las direcciones del puerto serie y del timer y la
frecuencia del timer. Previendo el uso en hardware diferente, estos parámetros están definidos en archivos C
especı́ficos, los cuales se incluyen condicionalmente dependiendo de las bandera de compilación activadas.
3.3.
Figura 2: Hardware utilizado: Dos placas Hitex con un
motor BLDC y un programador N-Link
3.2.
Modificaciones en el Motor de simulación de
PowerDEVS
El motor de simulación de PowerDEVS es el encargado de ejecutar la simulación, avanzando el tiempo, coordinando las funciones de los distintos bloques que componen el modelo. Además, cuando las simulaciones se
realizan en tiempo real, el motor es el que realiza la sincronización con el reloj fı́sico.
Por otro lado, el motor de simulación incluye funciones de entrada–salida, de comunicación con Scilab, que
pueden ser invocadas desde los bloques.
Dado que el motor de simulación está programado en
C++ (al igual que todo el código de los bloques y el modelo) y que hay compiladores de C++ para ARM incluyendo la GCC, en principio el motor no requerirı́a modificaciones.
1 El
núcleo ARM-9 pertenece a la generación ARM-v6 de microporcesadores
Drivers
En este trabajo se implementaron drivers para el display 7 segmentos, para la entrada analógica (conectada
al potenciómetro de la placa), el puerto serie, las salidas
digitales (conectadas a los LEDs) y para leer los sensores
y comandar el motor brushless.
En general cada una de estos drivers tiene definida una
función “Init”, que se ejecuta al inicializar el modelo, y
configura el hardware. Una función “Get” que permite
leer la variable o el estado asociado a el periférico. Y una
función “Set” para establecer una salida.
Tanto en el caso del display de 7 segmentos como en el
comando del motor brushless, se recurrió al uso de interrupciones. El LPC2939 implementa las mismas a través
de un vector de interrupciones por software por lo que
se programó un pequeño sistema operativo para administrarlas.
3.4.
Módulo de Startup y Script Enlazador
Dado que el programa generado debe ejecutarse sin
sistema operativo, al compilar un modelo en modo ARM
se incluye un código de start-up y un script para el enlazador. El primero contiene el punto de inicio del programa,
XV Reunión de Trabajo en Procesamiento de la Información y Control, 16 al 20 de septiembre de 2013
configura el clock del microcontrolador, el vector de interrupciones e inicializa la memoria RAM. Una vez inicializado el procesador, el start-up, llama a la función main,
la cual a su vez realiza la simulación, con los parámetros
que ésta requiere.
El script para el enlazador contiene la información necesaria para generar el ejecutable, como mapeo de las memorias flash y RAM y direcciones donde se ubicarán los
segmentos del programa. En éste también se definen los
tamaños de de la pila y la memoria heap, destinada a almacenar variables creadas en tiempo de ejecución.
3.5.
Nuevos Elementos en la Interfaz Gráfica
El menú de la interfaz gráfica de PowerDEVS es editable por usuario. Aprovechando esto, se agregaron dos
nuevas funciones al mismo.
La primera opción genera el código para ARM a partir
del modelo. Esto es, invoca al preprocesador de PowerDEVS para generar el código C++ del modelo y luego al
compilador cruzado Linux–ARM con la bandera de compilación especı́fica que hace uso de las implementaciones
ARM de las funciones especı́ficas del motor. De esta manera, se genera el binario para grabar en la memoria flash
del microcontrolador.
La segunda opción del menú permite directamente grabar la memoria flash desde la propia interfaz, haciendo
uso de la herramienta Open Source OpenOCD.
3.6.
FromSerial: La contra parte del bloque ToSerial.
Este bloque toma las señales provenientes del puerto serie y las de-multiplexa enviándolas al modelo.
El uso conjunto de este bloque y el anterior permite
comunicar la PC y el sistema embebido en ambos
sentidos.
Motor: Este bloque recibe una señal que indica el
ciclo de trabajo del PWM que alimenta el motor
brushless antes mencionado. En el caso de ejecutarse en la computadora, el bloque no genera ninguna acción.
Speedometer: Este bloque tiene una salida que representa la velocidad del rotor. El driver que realiza
la medición de la velocidad lo hace cronometrando
el tiempo que demora el motor en dar una vuelta completa, utilizando para esto las interrupciones
que provocan los sensores hall en el microcontrolador. En el caso de utilizarse en una PC, el bloque
no genera ninguna salida.
A la izquierda de la interfaz de PowerDEVS mostrada
en la Fig.3 puede verse la librerı́a con estos bloques.
Bloques de Librerı́a
En el marco del proyecto, se crearon además bloques
de librerı́a especı́ficos para hacer uso de los componentes
de hardware. Estos bloques internamente invocan a los
drivers antes mencionados, y ofrecen una interfaz muy
simple para el usuario.
Para mantener la filosofı́a multiplataforma de PowerDEVS, dichos bloques cuentan también con una implementación en Linux y Windows. De esta manera, cuando
un modelo se ejecuta en la PC, mantiene su funcionalidad
(si bien no comanda realmente ningún hardware).
A continuación se detalla el funcionamiento de algunos de los bloques construidos.
Knob: Este bloque funciona como una fuente de
señal. En ARM introduce al modelo el nivel de
tensión del potenciómetro. En la computadora, el
valor de salida del bloque es el de una perilla que
aparece en un panel de la pantalla.
LCD: Es el correspondiente al display de 7 segmentos. La señal de entrada al bloque se ve representada en el display de la placa. La implementación en la PC muestra el valor en un display dibujado en un panel de la pantalla.
ToSerial: Este bloque toma señales del modelo y
las envı́a a través del puerto serie de la placa. En
el caso de ejecutarse el modelo sobre un sistema
operativo, utiliza el puerto serie de la computadora.
Permite además multiplexar señales provenientes
de distintos bloques.
Figura 3: Librerı́a de bloques para ARM.
4.
EJEMPLO DE APLICACIÓN
Para demostrar el uso de la herramienta desarrollada, implementamos un sistema de control para un motor
brushless, que se muestra en la Figura 4.
En este sistema de control pueden distinguirse las siguientes partes:
El controlador propiamente dicho, en la parte superior, correspondiente a un PI con antiWindup.
Aquı́, el bloque integrador utiliza el método de
QSS, por lo que el controlador sigue una estrategia de Quantized State Control [9].
XV Reunión de Trabajo en Procesamiento de la Información y Control, 16 al 20 de septiembre de 2013
Figura 4: Sistema de control para un motor brushless en
PowerDEVS.
Figura 5: Modelo en PowerDEVS para comunicación con
el sistema embebido.
La señal de referencia de velocidad la generan los
bloques de abajo a la izquierda. Hay una llave que
selecciona entre dos entradas: la del potenciómetro
o la del bloque FromSerial, que viene desde la PC.
El bloque motor que recibe la señal del controlador
(o alternativamente una señal igual a 0 para detenerse).
Un bloque Speedometer que mide la velocidad del
motor, que se compara luego con la referencia para
cerrar el lazo de realimentación.
Un bloque LCD que muestra en el display de 7 segmentos la medición de velocidad.
Un bloque ToSerial que envı́a a la PC la señal de
referencia, la medición de velocidad y el valor de
salida del controlador.
Este modelo no necesita de la PC para funcionar, pero
cuando se conecta con la PC, ésta puede enviar la señal
de referencia y recibir las mediciones de velocidad y de
esfuerzo de control.
Aprovechando los mismos bloques, se construyó también un modelo en la PC que se comunica con el sistema
embebido para dibujar en tiempo real las trayectorias y
eventualmente comandar la referencia. La Fig.5 muestra
este nuevo modelo.
Al ejecutar este modelo se abre un panel que contiene
una perilla (correspondiente al bloque Knob) y dos displays (correspondientes a los bloques LCD). Este panel
se muestra en la Fig.6.
Además, debido al bloque GNUPlot, se abre una ventana que grafica en tiempo real las señales recibidas (en este
caso, la velocidad, referencia y esfuerzo de control). La
Figura 7 muestra estas señales para una ejecución, donde
puede apreciarse un correcto seguimiento de la referencia.
5.
CONCLUSIONES
Se realizó una extensión del software PowerDEVS que
permite implementar automáticamente sistemas de con-
Figura 6: Panel con la perilla y los displays correspondientes a los bloques del modelo de la Fig.5
trol embebidos en plataformas ARM. Esta extensión brinda a la herramienta una funcionalidad similar a la del Real
Time Workshop de Matlab/Simulink, si bien limitada a
una plataforma especı́fica de hardware (aunque fácilmente extensible a otras).
Se presentó además un ejemplo de aplicación de relativa complejidad, que muestra el potencial de la herramienta desarrollada.
A futuro, estamos estudiando la alternativa de extender
aún más la aplicación a otras configuraciones de hardware dentro de la familia ARM y eventualmente a otras arquitecturas.
PowerDEVS,
incluyendo
la
extensión
de
ARM, puede bajarse gratuitamente del sitio
http://sourceforge.net/projects/powerdevs/
6.
AGRADECIMIENTOS
El desarrollo de este trabajo fue financiado por la empresa FORKWORKS a través de un convenio FORKWORKS–
CONICET y mediante el proyecto PIP 2009/2011 – 00183.
REFERENCIAS
[1] D. Hristu-Varsakelis and W. S. Levine, Handbook of networked and embedded control systems. Birkhauser Boston, 2005.
[2] A. Monti, E. Santi, R. A. Dougal, and M. Riva, “Rapid prototyping of digital controls for power electronics,”
IEEE Transactions on Power Electronics, vol. 18, no. 3,
pp. 915–923, 2003.
XV Reunión de Trabajo en Procesamiento de la Información y Control, 16 al 20 de septiembre de 2013
[5] F. Bergero and E. Kofman, “PowerDEVS. A Tool for Hybrid System Modeling and Real Time Simulation,” Simulation: Transactions of the Society for Modeling and Simulation International, vol. 87, no. 1–2, pp. 113–132, 2011.
[6] E. Kofman and S. Junco, “Quantized State Systems. A
DEVS Approach for Continuous System Simulation,”
Transactions of SCS, vol. 18, no. 3, pp. 123–132, 2001.
[7] F. Cellier and E. Kofman, Continuous System Simulation.
New York: Springer, 2006.
[8] C. Gómez, Engineering and scientific computing with Scilab. Springer, 1999.
Figura 7: Gráfica de las variables transmitidas desde la
placa a la PC
[3] P. J. Mosterman, S. Prabhu, A. Dowd, J. Glass, T. Erkkinen, J. Kluza, and R. Shenoy, “Embedded real-time control via matlab, simulink, and xpc target,” in Handbook
of networked and embedded control systems. Springer,
2005, pp. 419–446.
[4] J. Limroth, J. S. Falcon, D. Leonard, and J. Loy, “Lab view
real-time for networked/embedded control,” in Handbook
of networked and embedded control systems. Springer,
2005, pp. 447–470.
[9] E. Kofman, “Quantized-State Control. A Method for Discrete Event Control of Continuous Systems.” Latin American Applied Research, vol. 33, no. 4, pp. 399–406, 2003.
[10] B. Zeigler, T. Kim, and H. Praehofer, Theory of Modeling
and Simulation. Second edition. New York: Academic
Press, 2000.
[11] D. Seal, ARM Architecture Reference Manual, 2nd ed.
Boston, MA, USA: Addison-Wesley Longman Publishing
Co., Inc., 2000.
[12] H. Högl and D. Rath, “Open on-chip debugger – openocd
–,” Fakultat fur Informatik, Tech. Rep., 2006.