Download organización de un autómata programable bajo rtlinux

ORGANIZACIÓN DE UN AUTÓMATA PROGRAMABLE BAJO
RTLINUX
Inmaculada Plaza
Carlos Medrano
Departamento de Ingeniería Electrónica y Comunicaciones
Escuela Universitaria Politécnica de Teruel, Universidad de Zaragoza
c/ Ciudad Escolar s/n, 44003 Teruel
{ctmedra, iplaza}@unizar.es
Resumen
En este trabajo presentamos la organización de una
aplicación que permite a un PC con el sistema
operativo RTLinux funcionar como un autómata
programable. El usuario introduce la configuración
hardware y software, así como los programas de las
tareas en lenguaje lista de instrucciones, siguiendo
un subconjunto de la norma IEC 61131-3. A partir
de dicha información y de ficheros predefinidos, el
gestor de la aplicación genera automáticamente el
código en lenguaje C y el fichero Makefile para su
compilación con las herramientas habituales (gcc y
make). El resultado es un módulo RTLinux que puede
ser insertado y que ejecutará los programas del
usuario. Adicionalmente, el proyecto en su conjunto
se ha desarrollado procurando seguir la filosofía de
Calidad Total, prestando especial atención a la
normativa aplicable (ISO, IEC). Para gestionar el
proceso, se ha elegido un modelo en espiral, con tres
ciclos, correspondiendo la versión presentada aquí
al primero de ellos, denominado "autómata
booleano".
Palabras Clave: Autómatas Programables, Linux,
PC, Tiempo Real.
1
INTRODUCCIÓN
Los autómatas programables son sistemas
ampliamente conocidos y utilizados en la industria
[1]. Las soluciones que aparecen en el mercado son
soluciones propietarias, dependientes de casas
comerciales.
Frente a ellos, se observa un creciente uso del PC en
aplicaciones de control [5]. Este hecho se debe al
bajo costo del hardware, al incremento de las
prestaciones, la posibilidad de su integración en los
sistemas de información de las empresas y a la
aparición de plataformas, específicas, como el
PC/104 [7, 5].
Finalmente, debemos citar la aparición del sistema
operativo Linux. El hecho de que este sistema sea
abierto, fiable y estable, ha facilitado su extensión en
el mundo del PC. En el contexto que nos ocupa,
destacamos la existencia de la versión en tiempo real
denominada RTLinux [2, 3, 9], que permite un
control temporal preciso. Existen trabajos previos en
los que se realizan sistemas de control bajo Linux
entre los que destacamos el proyecto MatPLC [13,
8], en el que la implementación de un autómata
programable es una de sus partes.
El propósito del presente trabajo es describir la
organización de una aplicación que permite a un PC
operar como autómata programable, ejecutándose las
tareas del autómata bajo RTLinux.
2
AUTÓMATAS PROGRAMABLES
Y NORMATIVA APLICABLE
A la hora de abordar el desarrollo de un autómata
programable bajo la filosofía de la Calidad Total,
varias normas deberían ser consideradas: aquellas
aplicables al propio proceso de desarrollo y las
referentes al producto. En nuestro trabajo se han
intentado integrar las familias de normas que se
muestran en el apartado de referencias. De este
modo, se busca asegurar la calidad del producto final
obtenido, la eficiencia y eficacia en el desarrollo del
mismo, facilitar la posterior consecución del marcado
CE y su integración del producto final en cualquier
tipo de empresa [10, 11].
Desde esta perspectiva, también deben considerarse
los esfuerzos de estandarización realizados en el
campo de la automatización, que han dado lugar a la
norma IEC 61131 (ver listado de normas en el
apartado de referencias), elaborada con el apoyo de
los principales fabricantes. Dicho estándar desarrolla
y unifica todos los aspectos técnicos necesarios para
el diseño, puesta en marcha y mantenimiento de este
tipo de sistemas. En el presente trabajo nos
centraremos en la parte 3 del estándar, en la que se
definen los lenguajes de programación para
autómatas programables: lenguajes literales (LI Lista de Instrucciones y ST - Texto Estructurado) y
lenguajes gráficos (LD - Diagrama de Escalera y
FBD - Diagrama de Bloques Funcionales).
Paralelamente, la norma presenta el SFC - Cuadro
Funcional Secuencial, cuyos elementos pueden ser
utilizados junto con cualquiera de los lenguajes
gráficos anteriormente citados. En la parte 8 del
estándar (guía de aplicación e implementación de
lenguajes de programación), se tratan aspectos tales
como planificación, concurrencia y mecanismos de
sincronización.
Como primer lenguaje para desarrollar nuestro
proyecto, se ha elegido la Lista de Instrucciones - LI.
En concreto, se van a implementar las instrucciones
que se muestran en la tabla 1, que constituyen un
subconjunto de la tabla 52 de la norma IEC 61131-3.
Su similitud con un lenguaje ensamblador,
relativamente sencillo, hace de este lenguaje un
candidato para poder realizar un compilador y poder
comprobar el funcionamiento del sistema en sus
primeras versiones.
Operador
Modificador (*)
LD
N
ST
N
S
R
AND
N,(
OR
N,(
XOR
N,(
GT
GE
EQ
NE
LE
LT
JMP
C, N
CAL
)
Tabla 1. Operadores de lista de instrucciones
implementados.
(*) N = negación, C = condicional.
La llamada (CAL) mostrada en la tabla 1, permite
invocar a los siguientes bloques funcionales:
biestable (posicionar o rearmar dominante);
detectores de flanco (ascendente o descendente);
contadores
(ascendente
y
descendente);
temporizadores (de impulso, retardo al conectar y
retardo al desconectar).
3
RTLINUX
RTLinux fue desarrollado inicialmente por M.
Barabanov y V. Yodaiken [2]. RTLinux se sitúa entre
el hardware y el propio sistema operativo, creando
una máquina virtual para que Linux pueda seguir
funcionando, fig.1 [12]. RTLinux es el encargado de
gestionar las interrupciones y del acceso al hardware.
Las tareas de tiempo real comparten el mismo
espacio de memoria que el núcleo y se ejecutan con
todos los privilegios; es decir, pueden ejecutar
cualquier instrucción del procesador y tienen acceso
a las entradas/salidas. Las tareas tienen prioridades
fijas y pueden hacerse periódicas, compartir recursos
mediante
FIFOs
o
memoria
compartida,
sincronizarse etc, lo que representa una serie de
capacidades típicas de los sistemas operativos de
tiempo real. De forma sucinta, podemos considerar
que Linux es la tarea de más baja prioridad, que sólo
se ejecutará cuando no haya una tarea de tiempo real
preparada. De esta forma, podemos mantener todas
las aplicaciones típicas de Linux en una capa superior
(ver figura 1).
USUARIO
Aplicaciones del
usuario
BIBLIOTECAS
Llamada al sistema
Drivers
SISTEMA OPERATIVO LINUX
Tarea de
tiempo real A
SISTEMA
OPERATIVO
Tarea de
tiempo real B
Interrupción Software
REAL TIME LINUX
PLANIFICADOR
MÁQUINA
VIRTUAL
Interrupción Hardware
HARDWARE
MÁQUINA
REAL
Figura 1: Arquitectura de RTLinux (adaptado de
[12])
RTLinux ha evolucionado y actualmente su interfaz
de programación cumple POSIX 1003.13 el mínimo
estándar de sistemas operativos de tiempo real,
además de incluir funciones adicionales no
conformes con POSIX. Es posible obtener una
versión libre, aunque existen también versiones
comerciales [3].
En nuestro trabajo, hemos elegido RTLinux por la
posibilidad de obtener un sistema de bajo coste,
fiable, y con compatibilidad con las aplicaciones de
Linux habituales.
4
IMPLEMENTACIÓN
En la primera versión, la aplicación se ejecuta desde
la línea de comandos. En la figura 2 se encuentra el
flujo de información dentro de los programas.
Información del
usuario
Hardware
Conf. Softw
Tareas
Programas
Interfaz
RUN
Fichero de
Configuración
Compilador LI
Fallos,
resultados…
Librerías y
funciones
predefinida
GESTOR
Fichero de
texto
Chequear
coherencia
Módulo ---Fichero
patrón
GCC
Generación
ficheros
----.h
----.c
Makefile
Figura 2. Flujo de información en el "autómata
booleano"
El usuario introduce la información acerca de los
siguientes aspectos:
• La configuración software (número de
bloques funcionales y número de bits de
memoria internos).
• La configuración hardware (entre una serie
de posibilidades dependiendo de posibles
tarjetas de E/S que se instalen, que deben ser
conocidas a priori; para pruebas sencillas
podemos elegir el puerto paralelo).
• Los programas en lista de instrucciones
asociados a cada tarea.
• Las características de las tareas. Existen dos
tareas periódicas, de periodo variable, y una
tarea por evento.
Esta información se almacena en un fichero de
configuración, utilizado por el gestor de la
aplicación. También se posibilita la edición directa
de dicho fichero.
A partir de este fichero de configuración, el gestor
comprueba la coherencia (por ejemplo, que no
intentamos acceder a un bit de entrada que no está
presente en el hardware escogido), y compila los
programas asociados en lista de instrucciones. La
salida son programas en código C que contienen las
funciones a realizar dentro de cada ciclo de una tarea
del autómata y el fichero necesario en el paso final de
compilación habitual en Linux (Makefile). Este
fichero Makefile hace referencia a una serie de
ficheros patrón, predefinidos, así como a los ficheros
específicos generados por el gestor.
Se ha decidido que el compilador de lista de
instrucciones obtenga como salida directamente
código C, de similar manera a como se ha realizado
en casos precedentes encontrados en la literatura [4].
Esta es la solución que proporciona una ejecución
posterior más rápida. No obstante, uno de los
ficheros intermedios de la compilación contiene
códigos de operación y operandos, que podrían ser
llevados a memoria e interpretados en tiempo de
ejecución si se prefiere esta alternativa.
El programa final para RTLinux es en realidad un
módulo insertable en el kernel de Linux [12]. En el
inicio del módulo se crean los hilos (cada uno
asociado a una tarea periódica del autómata), se
solicitan las interrupciones (tareas por eventos) y
puertos de E/S dependiendo del hardware, y se
asignan las zonas de memoria para los objetos del
lenguaje (imagen de entrada/salida, memoria y
bloques funcionales). Al terminar el módulo, se
liberan todos los recursos.
Por ejemplo, la estructura de una tarea periódica, que
se encuentra en un fichero patrón, es sencilla:
void *task1 (void *arg){
struct sched_param p;
p.sched_priority = 2;
pthread_setschedparam (pthread_self(), \
SCHED_FIFO, &p);
pthread_make_periodic_np (pthread_self(),\
gethrtime(), \
PERIOD1);
while (1) {
pthread_wait_np ();
/* Read physical inputs */
update_input_image();
/* Execute user program */
do_plc_program[0]();
/* Set physical outputs */
update_output();
}
return 0;
}
La tarea se marca a sí misma como de prioridad 2 en
este ejemplo, (en nuestra implementación, la tarea de
menor periodo sería la más prioritaria), y con la
política del planificador SCHED_FIFO, la única
posible en RTLinux. Después se hace periódica, con
periodo denominado PERIOD1, a través de
pthread_make_periodic_np, una función no definida
en POSIX. Con pthread_wait_np, se suspende la
ejecución del thread hasta el próximo periodo [12].
En cada periodo se ejecuta el clásico ciclo del
autómata. Las funciones update_input_image y
update_output dependen del hardware y están
definidas en un fichero externo, realizado a priori. La
primera actualiza la imagen de entradas, mientras que
la segunda copia la imagen de las salidas en la salida
física. El gestor de la aplicación las hará visibles a
través del Makefile. La función do_plc_program[0]
está definida en un fichero externo generado tras la
compilación de los programas de lista de
instrucciones, y es el que ejecutará realmente el
programa introducido por el usuario, accediendo a la
imagen de entradas, salidas, bits de memoria internos
y bloques funcionales, cada uno con su espacio de
memoria compartida. El Makefile generado por el
gestor permite compilar todos los ficheros adecuados
conjuntamente.
Una aplicación en Linux (baja prioridad) permite
obtener información de las tareas, objetos del sistema
(entradas, salidas, etc) a través de la memoria
compartida, para realizar una supervisión del trabajo
del autómata.
El usuario tan sólo debe tener unos conocimientos
mínimos sobre Linux, tales como editar ficheros de
texto, gestionar sus ficheros y ejecutar programas.
5
CONCLUSIONES
Se ha realizado una primera versión de un autómata
programable sobre PC cuyas tareas se ejecutan en
RTLinux. A continuación se resumen las principales
conclusiones obtenidas:
• La utilización de un sistema operativo de
tiempo
real
permite
implementar
adecuadamente las funciones de los
autómatas programables tal y como
aparecen definidas en la norma IEC 61131.
Las tareas periódicas se implementan como
hilos de RTLinux. Por contra, el sistema
operativo Linux habitual sin el soporte de
tiempo real no asegura un comportamiento
temporal adecuado.
• Se han integrado tres aspectos de gran
interés en la actualidad: los autómatas
programables, el uso de sistemas operativos
de código abierto y la filosofía de Calidad
Total (este último ha sido desarrollado en
otros documentos [10]).
• El trabajo presentado ofrece una primera
versión funcional de un autómata
programable, junto a las ventajas de un
sistema operativo ampliamente conocido y
utilizado como es Linux.
Como mejoras futuras en posteriores ciclos,
siguiendo el modelo de espiral, podemos destacar:
• Realización de una interfaz gráfica para el
gestor.
•
•
•
Ampliar hasta el conjunto completo de
órdenes de lista de instrucciones.
Incluir otros lenguajes, en concreto el
diagrama de contactos, ampliamente
demandado
[6],
así
como
otras
funcionalidades típicas de los autómatas
comerciales.
Permitir acceso remoto al autómata.
La posibilidad de trabajar con un sistema autómata
programable sobre PC tendría aplicaciones en dos
campos:
• La industria. De especial interés es la
facilidad de trabajar de forma remota
mediante las técnicas habituales en sistemas
"tipo Unix". Adicionalmente, destacamos la
potencia de cálculo de los PC.
• En educación, al permitir a cualquier
institución tener sistemas de autómata
programable. Incluso, a partir del trabajo
presentado, sería posible realizar un
simulador de autómata programable.
Agradecimientos
Agradecemos la financiación de la Diputación
Provincial de Teruel (OTRI 2001/0333) y de la
Diputación General de Aragón (P097/2001).
Referencias
[1] Balcells, J., Romeral, J.L., (1997) Autómatas
Programables, Serie Mundo Electrónico,
Editorial Marcombo.
[2] Barabanov, M., (1997) Linux-based Real-Time
Operating System, PhD Thesis, New Mexico
Institute of Mining and Technology, Socorro,
New Mexico.
[3] http://www.fsmlabs.com/, última visita en Julio
de 2003.
[4] Gil, E., Caparí, R., (1996) "Editor gráfico y
compilador de grafcet a lenguaje C", Seminario
Anual de Automática y Electrónica Industrial,
p. 957.
[5] Horrillo, J., (2002) "Informática Industrial:
panorama
actual",
Automática
e
Instrumentación, nº 232, pp. 60-75.
[6] Jafrate, R.J., (2001) "The Linux PLC:
Requirements to Gain Acceptance in Industry",
Real Time Linux Workshop, Milano, Italy, 2629 November.
[7] Lehrbaum, R., (1997) "PC/104 The nonbackplane alternative", Real Time Magazine,
pp. 37-40.
[8] http://mat.sourceforge.net, última visita en Julio
de 2003.
[9] http://www.ocera.org/, última visita en Julio de
2003.
[10] Plaza, I., Medrano, C., (2003), "Quality in PC
based Programmable Logic Controllers using
RTOS", EUROMICRO Digital Systems Design,
Symposium DSD 2003, Proceedings of the WIP
session, Belek (Turquía).
[11] Plaza, I., Ubé, M., Blesa, A., (2001) "ISO
9001:2000 aplicada a un grupo de investigación
y desarrollo universitario en TIC" in Forum
Calidad, vol 124, pp. 27-33.
[12] Ripoll, I., Tutorial de las API de RTLinux,
accesible a través de la dirección web
http://rtportal.upv.es/, el portal RTLinux de la
Universidad Politécnica de Valencia, última
visita en Julio 2003.
[13] Sousa, Mario (2001) Linux-Based PLC for
Industrial Control, Embedded Linux Journal,
May 2001, pp. 32-38.
Estándares
ISO 9001:2000
Requirements.
ISO 9004:2000
improvement.
Quality
management
Guidelines
for
systems.
performance
ISO/IEC 9126-1:2001(E) Software engineering Product quality. Part 1: Quality model.
ISO/IEC 12207:1995(E) Information technology Software life cycle processes.
ISO/IEC 12207:1995/Amd.1:2002(E) Information
technology - Software life cycle processes.
Amendment 1.
ISO/IEC 14598-1: 1999(E) Information technology Software product evaluation - Part 1: General
overview.
ISO/IEC 14598:2000(E) Information technology Software product evaluation -Parts: 12,3, and 6.
UNE-EN 61131-1:1996 Programmable controllers.
Part 1: General information.
UNE-EN 61131-2:1997 Programmable controllers.
Part 2: Equipment requirements and tests.
UNE-EN 61131-3:1993, Programmable controllers –
Part 3: Programming languages.
IEC TR 61131-8:2000 Programmable Controllers Part 8: Guidelines for the application and
implementation of programming languages.