PLATAFORMA DE SIMULACIÓN Y CONTROL DISTRIBUIDO BAJO TIEMPO REAL
S. García-Nieto, A. Llosá, F. Llaneras.
[sergarro, anllogui, frallaes] @isa.upv.es
Dpto. Ingeniería de sistemas y Automática
Universidad Politécnica de Valencia
Camino de Vera 14, Apdo. 22012 E-46071 Valencia
http://personales.upv.es/sergarro/RTLinuxGPL
Resumen
El presente artículo
aborda el desarrollo de una plataforma de control distribuido en
tiempo real. La descripción de la plataforma se realiza desde
una perspectiva educacional, con el objetivo de mostrar la
versatilidad de la plataforma en un ámbito académico.
El aspecto más destacable, es la inclusión de un bus
de campo determinista en el diseño del sistema. El
cumplimiento de las restricciones temporales de las tareas de
control, pasa por la utilización de un sistema operativo
específico de tiempo real.
Palabras Clave: Control distribuido, tiempo real, Bus de
campo, RTLinux, CAN, CANOpen.
1 INTRODUCCIÓN
El presente artículo describe una plataforma de control
distribuido, centrándose en las posibilidades que ofrece a la
hora de realizar ejercicios y prácticas de laboratorio.
La plataforma esta formada por un bus de campo de carácter
industrial y por los nodos que se conectan al mismo. En una
configuración inicial, dichos nodos son: módulos
industriales de entrada/salida y un PC de escritorio.
Los módulos de entrada y salida se conectaran a los
diferentes sensores y actuadores del sistema, y los algoritmos de
control se programaran en los PC’s. Esta configuración
proporciona una gran flexibilidad al sistema, tanto a la hora de
seleccionar diferentes procesos o prototipos, como a la de
implementar controles bajo diversas metodologías.
Cabe señalar que la plataforma es altamente adaptable y que
puede ser ampliada y modificada libremente, debido a la posibilidad
de acceso al código fuente, ya que tanto el protocolo de
comunicaciones del bus, como el sistema operativo de los nodos PC
son “abiertos” lo que facilita los cambios.
Desde una perspectiva didáctica y educacional, la plataforma
permite tomar contacto con diferentes áreas del control
industrial de procesos:
Control distribuido industrial: La plataforma tiene como núcleo
fundamental un bus de campo industrial, CAN. Además
se emplean módulos de entrada/salida convencionales. Es
destacable también el uso de un protocolo de alto nivel como
CANOpen, que permite establecer un modo de comunicación
cíclico (y por lo tanto determinista), muy útil en
sistema de control.
Control en Tiempo Real: El uso de un sistema operativo de tiempo
real (RT-Linux-gpl) y el establecer una comunicación
determinista a través del bus de campo, permite llevar a
cabo control bajo tiempo real duro. Obviamente también es
posible realizar control en tiempo real blando, empleando un
sistema operativo Linux en el nodo de control.
Proceso real o simulado: La plataforma es capaz de trabajar de
igual forma sobre un proceso real o un prototipo, como de emplear
un modelo matemático de simulación. Es decir, los
módulos de entrada/salida pueden conectarse a los sensores y
actuadores de un proceso físico, o bien a una plataforma de
simulación.
Teoría de control: Desde la perspectiva de teoría de
control la plataforma es muy flexible y potente, ya que los
algoritmos de control se implementan en C. De esta manera es
posible emplear controles sobre sistemas multivariable, con
controladores analíticos o iterativos, lineales o no
lineales, bajo tiempo real duro o blando, etcétera.
Por ultimo, a modo de resumen se enumeran algunas de las
características fundamentales de la plataforma:
Control distribuido industrial.
Plataforma de control distribuido real.
Uso de un bus de campo industrial (CAN).
Protocolo estándar y abierto CANOpen.
Empleo de módulos industriales genéricos.
Control en Tiempo Real.
Determinismo de la plataforma
Control bajo tiempo real duro y blando.
Gestión de las tareas del sistema.
S.O. de tiempo real abierto que cumple el estándar POSIX.
Proceso real o simulado.
Control de procesos reales o prototipos.
Control de modelos de simulación.
Teoría de control.
Fácil implementación de algoritmos.
Control de procesos multivariable.
En definitiva, la plataforma ofrece un amplio conjunto de
posibilidades a la hora de diseñar y desarrollar prácticas
y ejercicios de laboratorio.
2 DESCRIPCIÓN
En el primer apartado se aborda la descripción desde una
perspectiva de alto nivel de la plataforma en su conjunto. En
apartados sucesivos se trataran con más detalle algunos de
los aspectos importantes de al misma.
2.1 DESCRIPCIÓN GENERAL DE LA PLATAFORMA
La configuración básica de la plataforma esta formada
por el bus, los módulos industriales de entrada/salida (tanto
digitales como analógicos) y los PC de escritorio que
implementan el control.
Por lo tanto, el núcleo central de la plataforma lo
constituye el bus de campo CAN. Con el fin de establecer una
comunicación, el resto de componentes se conectan al mismo.
A la hora de afrontar un problema de control industrial distribuido,
los módulos de entrada/salida servirán de interfaz con
el proceso a controlar. Es decir, los módulos de entrada se
conectaran a los diferentes sensores del sistema y los módulos
de salida a los actuadores.
El siguiente esquema viene a ilustrar la estructura de la
plataforma, bajo la configuración descrita hasta ahora:
Figura
1: Esquema General de la Plataforma
Dicha estructura recoge la esencia del control distribuido, donde
los sensores, los actuadores y los dispositivos de control se
encuentran alejados y se comunican a través del bus. Además
es muy flexible ya que permite afrontar el control de muy diferentes
procesos y emplear casi cualquier algoritmo de control. También
es importante su escalabilidad. Si se desea incorporar nuevos
sensores, actuadores o dispositivos de control, basta con
conectarlos a bus, y realizar su configuración.
A continuación se enumeran los elementos hardware y software
que conforman la plataforma:
Modulo CAN de 4 entradas analógicas, conforme a ISO 11898 y
CiA 401, el perfil de CANOpen para módulos de entrada/salida
genéricos.
Modulo CAN de 4 salidas analógicas, conforme a ISO 11898 y
CiA 401.
Modulo CAN de 8 entradas/salidas digitales, conforme a ISO 11898 y
CiA 401.
Ordenador PC de escritorio.
Tarjeta PCI que permita la comunicación de los PC’s
con el bus CAN.
Sistema operativo Linux con el kernel 2.4.18 parcheado para
utilizar como planificador de tareas RTLinux-GPL.
Dado el carácter abierto de la plataforma, es posible emplear
dispositivos de muchos fabricantes diferentes, siempre con la
precaución de que estos cumplan con los estándares.
Pese a ello, a continuación se incluye una relación de
los dispositivos que actualmente emplea la plataforma:
1 Tarjeta PCI-CAN 7841 de ADLINK technology
Inc.
2 Módulos BK5120, de BECKHOFF
Industrie Elektronik GMBH.
1 Modulo CAN-CBM-AI410, de Esd electronic
system design GMBH.
1 Modulo CANbloc-Mini, I/O Modules DIO,
de Esd electronic system design GMBH.
1 ordenador PC, con procesador AMD-K6 a 400 Mhz. y 128 Mb
RAM.
2.2 BUS DE CAMPO
Los buses de campo son un elemento cada vez más frecuente en
proyectos de automatización y control distribuido. La
industria considera que los buses de campo son un perfecto
sustitutivo al cableado punto a punto convencional, ya que reducen
costes, espacio y tiempo, redundando en un ahorro significativo.
Frente a los primeros sistemas propietarios, se están
consolidando los buses de campo basados en estándares
abiertos. La principal ventaja de dichas soluciones es que amplían
el abanico de suministradores de equipos compatibles, facilitando
también el mantenimiento de las instalaciones y su
crecimiento. Actualmente la mayoría de fabricantes incorporan
en sus equipos interfaces con uno o más estándares
abiertos.
2.2.1 Bus De Campo Can
CAN (Controller Area Network) es un bus de campo, desarrollado
originalmente para aplicaciones en la industria de automoción.
El protocolo CAN
fue estandarizado en 1993 como
ISO 11898-1.
CAN define la capa de datos y parte del nivel físico del
modelo OSI de siete capas. En cuanto al nivel físico CAN
incorpora un estándar ISO: “physical signaling”,
que incluye bit encoding y decoding (NRZ), bit timing
y sincronización. Además, existen diferentes
protocolos basados en CAN que comprenden las capas OSI superiores,
como CANOpen.
Desde la perspectiva del usuario, CAN proporciona dos servicios de
comunicación: el envió de mensajes y la petición
de mensajes. Además incluye otros servicios de bajo nivel y
transparentes al usuario como procesado de errores y retransmisión
automática.
Algunas de las principales funciones que proporciona CAN son las
siguientes:
Comunicación broadcast. Un emisor
de información transmite a todos los nodos a través
del bus. Todos los nodos reciben el mensaje y deciden si es
relevante o no para ellos. Este mecanismo garantiza la integridad
de la información de todos los nodos.
Priorización de mensajes. El protocolo
proporciona mecanismos hardware que garantizan que no se produzcan
colisiones entre mensajes cuando varios nodos desean emitir
mensajes.
Mecanismo sofisticado de detección de errores y
retransmisión de mensajes fallidos.
Estructura multi-maestro, que permite construir redes con
tolerancia a fallo (redundantes).
Las principales aplicaciones de CAN incluyen: coches de pasajeros,
camiones y autobuses, electrónica marítima, aérea
y aeroespacial, automatización de factorías, control
de maquinaria industrial, ascensores y montacargas, equipamiento
medico, equipamiento no industrial, etcétera.
Si se desea más información sobre CAN, puede
consultarse la Web de CiA (CAN in Automation), la organización
internacional de usuarios y fabricantes que desarrolla y da soporte
a los protocolos de alto nivel basados en CAN [3].
2.2.2 Protocolo CanOpen
CANopen es un protocolo basado en CAN que implementa la capa de
aplicación. Actualmente esta ampliamente extendido, y ha sido
adoptado como un estándar internacional. Las especificaciones
de CANOpen cubren la capa de aplicación y los perfiles de
comunicación (CiA DS
301) así como una estructura para dispositivos programables
(CiA 302), recomendaciones para cableado y conectores (CiA 303-1) y
sobre el empleo de unidades del sistema internacional y
representación mediante prefijos (CiA 303-2).
Aunque a continuación se describen algunas de las
características fundamentales del protocolo, es evidente que
una descripción exhaustiva del mismo requiriere mayor
extensión. Además de la documentación de la CiA
[3], pueden consultarse algunas referencias adicionales [5] y [9].
Los principales elementos que el protocolo define son los
siguientes:
Capa de aplicación (application layer)
Perfil de comunicación
(communication profile)
Diccionario de objetos (OD, Object Dictionary)
Servicios de gestión de red (NMT)
Perfiles de dispositivos (device profiles)
La capa de aplicación y el perfil de comunicación de
CANOpen (EN 50325-4; CiA 301) dan soporte el acceso directo a los
parámetros de cada dispositivo y la transmisión de la
información propia del proceso (por ejemplo señales de
sensores, acciones de control, referencias, mensajes de error,
etcétera). Son por tanto la base fundamental del protocolo.
El diccionario de objetos (OD, Object Dictionary) describe
completamente la funcionalidad de cada dispositivo y permite su
configuración mediante mensajes a través del propio
bus. En el se describen tanto los parámetros de
funcionamiento del dispositivo, como los mensajes con información
del proceso que recibe y transmite. Dicha información se
almacena de forma estandarizada y estructurada, en un archivo de
configuración genérico, formado por una lista de
entradas (cada entrada se define con un índice de 16 bits y
un subíndice de 8).
Además, los servicios de gestión de red (NMT, network
management services) de CANOpen facilitan el diseño de la
red, su configuración, puesta en marcha e integración,
así como el diagnostico de fallos.
Por ultimo, CANOpen define una serie de perfiles de dispositivos
(device profiles) que estandarizan la información contenida
para diferentes tipos de dispositivos: módulos de
entrada/salida, dispositivos de control, PLC’s, encoders,
inclinómetros, control de puertas, etcétera. De esta
manera el usuario final puede utilizar indistintamente dispositivos
de diferentes fabricantes, siempre que estos cumplan dichos
estándares.
2.2.2.1 Tipo de Mensajes
El protocolo define una serie de tipos de mensajes diferentes en
función de su utilidad. Fundamentalmente hay que distinguir
los mensajes que operan con información del proceso
propiamente dicho (es decir, la información que deseamos
transmitir a través del bus) de los mensajes que manejan
información sobre la propia red, su configuración y su
funcionamiento.
La consulta de la información del diccionario de objetos y su
configuración se realiza mediante mensajes SDO (service data
objects). Estos mensajes permiten conocer la configuración de
cada nodo y modificarla.
Por otro lado, la transmisión de datos del proceso (no
parámetros de configuración) se realiza a través
de mensajes especiales (process data objects, PDO). Son estos
mensajes los que contienen la información que cada nodo o
dispositivo ofrece a los demás, a través del bus de
campo. Los mensajes PDO de un nodo o dispositivo pueden dividirse en
dos categorías. Los tPDO son aquello mensajes con información
del proceso que el nodo transmite al bus de campo (por ejemplo la
lectura de un sensor). Por otro lado, los rPDO son los mensajes con
información del proceso que el nodo escucha o recibe del bus
de campo (por ejemplo un nodo que controle la apertura de una bomba
escuchara el bus en busca de ordenes o acciones a realizar). Cada
PDO tiene un identificador único, y se genera en un nodo
particular. Pero puede ser recibido por múltiples nodos.
Además, existen algunos mensajes especiales para gestión
de la red (NMT), sincronización, informe de errores,
etcétera.
2.2.2.2 Tipo de comunicación
CANopen define varios mecanismos de comunicación para la
información del proceso (mensajes PDO):
Por evento: Los mensajes se envían en cuanto se produce un
cambio en su contenido. Es decir, el estado del proceso no se
transmite de forma continuada, solo cuando se producen cambios.
Cíclica sincrona: Un mensaje de sincronización (SYNC)
le indica a cada nodo que debe aceptar la información
recibida previamente y enviar la información
correspondiente.
Por petición: Un mensaje indica al nodo que debe enviar
determinada información a través del bus.
2.2.2.3 Tasa de transmisión
La tasa de transmisión puede configurarse a diferentes
valores, desde 10kbaud hasta 1Mbaud.
2.2.2.4 Topología de la red
CAN se basa en una topología lineal. El numero de nodos en
cada red esta limitado a 128. Además, el tamaño de la
red también viene limitado por el flujo de información
y el tiempo de transmisión necesario.
2.2.2.5 Ventajas de CANOpen
A continuación se enumeran algunas de las características
más interesantes de CANOpen como protocolo de comunicaciones.
Gestión sencilla del flujo de información del proceso
(mensajes PDO).
Configuración estándar de los dispositivos (OD).
Fácil configuración de los dispositivos a través
del propio bus (mensajes SDO).
Diferentes modos de comunicación (por eventos, síncrono
o por peticiones).
Amplio abanico de dispositivos compatibles.
Compatibilidad entre fabricantes (device profiles).
Servicios adicionales (NMT, Heartbeat, etcétera)
Potencia y flexibilidad para soluciones particulares más
complejas.
Es un protocolo abierto.
Conserva las ventajas de CAN, como la priorización de
mensajes o la gestión de errores.
En resumen, puede decirse que CANOpen proporciona una estructura
genérica pero altamente flexible (abierta) a la hora de
implementar una comunicación entre dispositivos a través
de un bus de campo.
2.2.3 CanOpen Y Tiempo Real
En el apartado anterior se describió el protocolo CANOpen
desde una perspectiva general. En este apartado se analiza la
idoneidad del empleo de dicho protocolo para el control de proceso
en tiempo real.
A la hora de abordar el control de proceso en tiempo real es
necesario tomar una serie de precauciones adicionales que garanticen
que las señales involucradas se procesaran en un tiempo
determinado. Por lo tanto, si se emplea un medio de comunicación
(como el bus de campo) es imprescindible garantizar que este tiene
un comportamiento determinista, es decir, que podemos acotar el
tiempo máximo que llevara la transmisión de cada
mensaje. Es bien sabido que redes de propósito general (como
Ethernet) no garantizan determinismo en absoluto, de ahí el
empleo de redes orientadas al control industrial. Pero no hay que
caer en el error de suponer que, empleando una red de dichas
características estamos solventando inmediatamente el
problema del determinismo.
En el caso de CANOpen, para posibilitar un comportamiento
determinista, es necesario realizar una configuración
particular.
Como se comento en un apartado anterior, CANOpen permite emplear
tres mecanismos de comunicación diferentes: comunicación
ante eventos, comunicación cíclica y sincronía
y comunicación por petición.
Para proporcionar el determinismo la comunicación debe ser
cíclica y síncrona. La idea consiste en emplear un
mensaje de sincronización (mensaje SYNC), generado por un
determinado nodo (por ejemplo el nodo de control). Ante la llegada
de dicho mensaje cada nodo aceptara o procesara la información
recibida previamente (mensajes rPDO) y enviara la información
correspondiente (mensajes tPDO). Este comportamiento permite
planificar tareas con especificaciones de tiempo real que hagan uso
del bus.
Cabe señalar que es posible configurar los nodos para atender
todos los mensajes de sincronización o solo uno de cada x, lo
que permite que los dispositivos empleen diferentes periodos.
También es posible que coexistan diferentes mensajes de
sincronización en un mismo bus.
2.6 SISTEMA DE TIEMPO REAL
Existen en el mercado todo tipo de sistemas operativos de tiempo
real. En este caso se ha decidido utilizar RT-Linux-GPL,
desarrollado en el proyecto europeo Ocera [10] a partir de
RT-Linux de Fsmlabs, y Linux. Para la implementación
de los módulos se ha utilizado como referencia un tutorial de
dominio público [11].
2.6.1 Elección Del S.O. de Tiempo Real
La razón para esta elección es que RTLinux-GPL y Linux
poseen una licencia de tipo GPL. Esto implica, entre otras
cosas, la posibilidad de obtención del código fuente
para su modificación o ampliación. En el caso de
investigación, este punto es muy importante, debido a la
necesidad del investigador a saber, en caso de necesidad, como
funcionan las herramientas en las que está basando sus
investigaciones, o modificarlas para poder ampliar el uso de éstas
y adaptarlas a los objetivos propios de la investigación.
En el caso de que se realice algún tipo de cambio en el
código, éste pasa al conocimiento del licenciatario
principal, de manera que, en caso de que sea útil para el
proyecto general, es incluido en éste, y el resto de usuarios
pueden ser beneficiarios. En caso de la comunidad investigadora,
esto es necesario, ya que de esta manera los esfuerzos de muchas
personas se pueden ir sumando para un beneficio común.
Otro factor de la elección ha sido el económico, ya
que el coste el software utilizado para desarrollar e implementar la
plataforma ha sido nulo, habiéndose utilizado herramientas de
código abierto.
Todo el trabajo realizado ha sido licenciado como GPL para su libre
modificación y distribución, siguiendo la filosofía
[6] de las herramientas y utilidades en las cuales se ha basado.
2.6.2 Definiciones de Tiempo Real
En ocasiones existe confusión a la hora de definir un sistema
de tiempo real. Por lo tanto, a continuación se van a
introducir las definiciones sobre las cuales se va a trabajar.
Con respecto a un sistema de tiempo real, es un sistema
informático en el que es significativo el tiempo en el que se
producen sus acciones. No es suficiente que las acciones del sistema
sean correctas lógicamente, sino que, además, deben
producirse dentro de un intervalo de tiempo determinado, que en este
caso es el periodo de muestreo establecido.
En función de los requisitos de tiempo real que se imponen a
un sistema, estos pueden clasificarse como:
Críticos o “Hard Real Time Systems”: El
tiempo de respuesta se debe garantizar a toda costa, ya que una
respuesta tardía puede tener consecuencias fatales.
Esenciales o “Soft Real Time Systems”: Sistemas
con restricciones de tiempo, en los cuales una respuesta fuera de
periodo no tiene consecuencias fatales para el sistema.
Adaptativos: La calidad de la respuesta obtenida depende del
tiempo disponible para su cálculo, adaptándose así
a la carga del sistema.
No esenciales: Tareas sin restricciones temporales.
En el caso de la plataforma descrita en este articulo, se ha
implementado un sistema tiempo real “duro”, ya que es la
opción con más dificultades en su implementación,
y la mejor opción a la hora de implantar cualquier tipo de
control.
Para las pruebas, en un primer momento se desarrolló un
sistema de control en tiempo real “blando” con Ada, pero
solamente se consiguió un periodo mínimo de muestreo
de 20 ms, y no se aseguraba el tiempo real.
El ejecutable corría bajo Linux, siendo uno más del
sistema operativo, y las tareas de control eran controladas por el
planificador interno de Ada.
El código también se encuentra en la página
referenciada.
2.6.3 Estructura del Modulo de Control
El esquema general en la ejecución del sistema es el
siguiente:
Figura
2: Esquema de Ejecución
RTLinux toma como proceso de máxima prioridad el “Módulo
de control” y mantiene a Linux como otro proceso de menor
prioridad. Esto significa, que mientras tenga algo que ejecutar el
módulo de control, Linux pasará a la espera. Por lo
tanto, en caso de que el tiempo necesario de ejecución del
control fuese superior al tiempo asignado previamente, Linux no se
ejecutaría, por lo que el sistema daría la impresión
de estar colgado, ya que el módulo de control se apoderaría
completamente de la CPU.
Cuando el modulo de control no se está ejecutando, entra en
funcionamiento Linux, y se ejecutan el resto de procesos del
sistema.
A continuación se describen con más detalle las
tareas.
2.6.3.1 Tarea de control
Esta tarea se encarga de realizar el control del sistema y tiene la
típica estructura de una tarea de control (leer sensores,
calcular acción de control, escribir acción de
control). Tiene la máxima prioridad.
Los pasos que se siguen dentro de esta tarea son los siguientes:
Aplicar acción de control.
En los ordenadores actuales, no es posible calcular el tiempo que se
tarda en calcular líneas de código, debido a la
incertidumbre causada por las nuevas estructuras de
microprocesadores, ya que varía de un ciclo de ejecución
a otro. Esto lleva a que no se es posible asegurar que el tiempo que
tarda la tarea en calcular la acción de control en un periodo
sea el mismo que en el periodo anterior.
Por ello, en primer lugar se aplica la acción de control
calculada en el instante anterior, de manera que se elimina este
tipo de incertidumbre, teniendo así un retardo fijo en la
aplicación de la acción de control.
Lectura de los sensores.
El siguiente paso después de aplicar la acción de
control es leer los sensores para poder realizar el cálculo
de ésta.
Para ello utilizamos los drivers desarrollados que funcionan de la
siguiente manera:
Se manda una señal para que todos los nodos Can que
funcionan como sensores adquieran al mismo tiempo señales del
proceso, y a continuación manden la información al
nodo principal las señales leídas. Esto último
se realiza de forma secuencial.
Cálculo de la acción de control.
En este paso se calcula la acción de control, con el
algoritmo de control implementado, que se va a aplicar en el
siguiente periodo.
Un ejemplo del algoritmo de control lo tenemos en el punto 3.3 de
este artículo, donde se explica como calcular el algoritmo de
control para controlar el proceso ejemplo.
Para más detalle, mirar el código del programa. Los
pasos están comentados.
2.6.3.2 Tarea de visualización
Debido a que la visualización de los datos no es prioritaria,
ésta se hace con un periodo de muestreo menor a la acción
de control y con una prioridad más baja. En estos momentos la
visualización se realiza en modo texto en la pantalla del PC.
Se está trabajando para poder enviar vía ethernet los
datos obtenido para su visualización en otros PC's.
2.6.3.3 Resumen
Las dos tareas se ejecutan en “hard real time”. El
código está implementado como un módulo del
sistema debido a las restricciones de RTLinux, y utiliza los drivers
Can que están compilados para ejecutarse en tiempo real.
Los drivers de Can han sido modificados para utilizar un
configurador de nodos de CanOpen. Dicho configurador ha sido
desarrollado con el propósito de ser empleado en la
plataforma. Aunque cabe señalar que las modificaciones del
driver pueden ser empleadas de forma genérica en nuevos
proyectos, donde se desee emplear el protocolo CanOpen.
2.7 PROCESOS REALES VS PLATAFORMAS DE SIMULACIÓN
El objetivo final que persigue la realización de esta
práctica, es enfrentar al alumno al diseño e
implementación de controladores de tiempo real en sistemas
distribuidos.
El entorno ideal para el alumno sería aquel en que pudiese
interaccionar con un proceso físico real, cosa que resulta
muy difícil en la mayoría de ocasiones. Por ello, es
habitual la utilización de plataformas de simulación,
las cuales emulan el comportamiento de los procesos reales. En este
caso, el alumno no se enfrenta a algunos de los problemas presentes
en la implementación física de un controlador.
Fundamentalmente, no se consideran los siguientes aspectos:
No se programan los dispositivos de adquisición de señales
de entrada/salida.
No existe ruido en las medidas.
No existe retardo debido al cálculo de la acción de
control.
Sin embargo, la utilización de procesos reales en los que si
se tendría en consideración los aspectos señalados
anteriormente; en ocasiones resultan inviables debido a las
restricciones espaciales y económicas de los laboratorios de
control. Por ello, cuando se quiere realizar el estudio de sistema
complejos, resulta imprescindible la utilización de
simuladores.
El presente artículo aborda la utilización de dos
plataformas de simulación:
PC-Desktop con sistema operativo xPC de MathWorks [12].
RT-PXI Compact PCI Controller de National Instruments [7].
2.7.1 xPC MathWorks
xPC target es un toolbox de la compañía
The MathWorks para la construcción de prototipos, testado y
desarrollo de sistemas de tiempo real. En particular, es adecuado
para la simulación o el control en tiempo real de procesos,
ya que permite al PC comunicarse con el exterior usando tarjetas de
adquisición de datos.
Inicialmente, la aplicación se desarrolla en un PC de
escritorio (host), con MATLAB, Simulink, Real-Time Workshop y un
compilador de C instalados. En este PC se crean los modelos usando
bloques de Simulink y se genera el código correspondiente.
Posteriormente, este código se ejecuta en tiempo real en un
segundo PC (target). Tanto el host como el target no requieren
ningún hardware específico, basta con un PC de
escritorio.
El PC target arranca usando un disquete (creado por el toolbox xPC
target) que contiene el kernel de tiempo real. Una vez cargado el
sistema operativo, desde el PC host se descarga el código
generado a partir del diagrama de Simulink, ya sea vía red o
a través del puerto serie.
Aparte de esta modalidad normal de funcionamiento, xPC target posee
otra, denominada embebida (precisa la instalación de xPC
Target Embedded Option, producto de The MathWorks que requiere
licencia adicional). En este caso, el PC target arranca en modo
MS-DOS y carga el kernel de tiempo real. Hay dos modos de
funcionamiento:
DOSLoader: Ejecuta el kernel desde un dispositivo diferente al
disquete, como un disco duro o una memoria flash. La
aplicación se también se transfiere desde el PC host.
StandAlone: Ejecuta tanto el kernel como la aplicación desde
el disquete o cualquier otro dispositivo de arranque del PC target.
De esta forma, el PC target funciona de forma completamente
independiente del host.
Existen algunas limitaciones en cuanto a como diseñar el
diagrama de Simulink a utilizar. En particular, no es posible:
Tener bucles algebraicos.
Utilizar métodos de integración de paso variable.
Utilizar el bloque de M-function (en su lugar se pueden usar
S-functions escritas en C).
´
El xPC target ofrece una interacción del usuario con la
aplicación sencilla e intuitiva. Para ello, se dispone de las
siguientes posibilidades:
Interfaz gráfico ejecutable desde MATLAB en el PC host
(xpcrtool).
Línea de comandos de MATLAB.
Diagrama de Simulink.
Línea de comandos del PC target.
Interfaz de explorador Web.
Interfaz programado por el propio usuario.
2.7.2 RT-PXI Compact PCI Controller de National Instruments.
El RT-PXI es una estructura modular que permite la utilización
sincronizada de varias topologías de tarjeta de uso común
en los procesos de medición y control en la industria. Para
su funcionamiento hace falta un módulo de control que
supervise todas las operaciones de sincronización entre
los periféricos. Es decir, existe una tarjeta controladora
que es la que se encarga de gestionar las tarjetas de E/S del
sistema; ya sean tarjetas de adquisición de datos o de
cualquier otro tipo. En realidad la tarjeta controladora tiene su
equivalencia en la placa base de un PC de escritorio.
Figura
3: Aspecto del dispositivo RT-PXI
Los
productos PXI de National Instruments se basan en el estándar
PXI-Compact PCI (fundado por un consorcio de empresas al cual
pertenece National Instruments), fue creado ante la necesidad
de incrementar la funcionalidad y fiabilidad de sistemas
industriales compactos de altas prestaciones. Uno de los objetivos
principales que caracterizan al estándar es garantizar la
compatibilidad con los PC industriales (basados en bus PCI)
ya existentes, así como permitir a los usuarios utilizar las
herramientas ya desarrolladas y de uso corriente.
La gran versatilidad del PXI reside en la posibilidad de programar
todo el sistema mediante la utilización de LabView. Este
hecho permite desarrollar arquitecturas de control o simulación
en tiempo real de una forma rápida y sistemática.
El usuario desarrolla la aplicación de control o simulación
en la herramienta de programación gráfica LabView, la
cual debe incluir el REAL-TIME MODULE que hace posible la
comunicación entre la herramienta de programación y el
PXI.
Una vez concluida la programación se descarga el código
en el PXI, esta descarga se realiza mediante una conexión
red; ya que el PXI posee tarjeta de conexión a redes
Ethernet.
El RT-PXI utiliza el sistema operativo de tiempo real Pharlap, el
cual se encarga de ejecutar el código descargado vía
ethernet.
Las dos soluciones empleadas en el presente artículo (xPC y
RT-PXI), serán empleadas en el ejemplo propuesto en el
siguiente apartado.
3 EJEMPLO: LA PLATAFORMA EN FUNCIONAMIENTO
El presente apartado aborda la realización de un ejemplo
práctico utilizando las herramientas que se han descrito en
los apartados anteriores. El objetivo de dicho ejemplo es ilustrar
de forma simple el funcionamiento de la plataforma.
En concreto se pretende controlar el sistema físico
denominado péndulo invertido. El cual viene descrito por la
siguiente figura.
Figura
4: Esquema del Péndulo Invertido
El sistema presenta el modelo en espacio de estados linealizado que
muestra la ecuación (1), tomando como punto de equilibrio el
péndulo en posición vertical. El origen de coordenadas
también se encuentra situado en el punto de equilibrio.
Cabe destacar que el modelo presenta como acción de control
la fuerza, en general, esta fuerza se genera mediante un motor que
proporciona tracción a las ruedas del carro. Por ello
obtenemos las ecuaciones lineales del motor y las incluimos en el
modelo.
Tabla 1: Variables y Parámetros del Modelo
Variable
Descripción
Magnitud
Valor
F
Fuerza sobre carro
N
m
masa péndulo
Kg
0,21
M
masa carro
Kg
0,45
l
centro gravedad péndulo
m
0,61
x
posición carro
m
velocidad carro
a
ángulo péndulo
rad
velocidad angular
V
voltaje motor
V
I
intensidad motor
A
resistencia armadura
Ohm
2,6
Constante motor
4,47
Utilizando las ecuaciones (2) obtenemos el modelo en espacio de
estados que se muestra a continuación:
Una vez descrito el modelo del sistema real se debe construir los
modelos de simulación para la plataforma xPC o para el
RT-PXI. A continuación se describen ambas alternativas.
3.1 MODELADO EN xPC
Modelar en Simulink la dinámica del péndulo
invertido. Es importante recordar las excepciones comentadas en el
apartado 2.7.1. Se debe elegir un periodo de simulación lo
suficientemente pequeño comparado con el de muestreo
del controlador para que se asemeje a un proceso continuo.
Añadir al diagrama Simulink los bloques correspondientes al
hardware de adquisición de señales de entrada/salida.
Dichos bloques están disponibles al instalar el toolbox xPC
target en la librería de Simulink correspondiente. En
concreto, para la tarjeta de adquisición PC-Lab 812PG, un
ejemplo de diagrama Simulink se muestra en la figura siguiente:
Figura
5: Diagrama Simulink
Si el PC simulador del proceso tiene un monitor y se desea que los
alumnos visualicen gráficas en el se pueden añadir
bloques scope. Para ello, existen diferentes posibilidades.
Una de ellas, es la de añadir los bloques de la librería
xPC target Scope(xPC) .
Figura
6: Diagrama Simulink con Scope
Transferir la aplicación al PC target. Para ello, tenemos
tres opciones:
En el caso de que los PCs de los puestos de practicas dispongan de
una tarjeta de red con uno de los chipsets compatibles con la
toolbox de Matlab, podemos descargar directamente desde el PC host
una aplicación a cada uno de ellos. Bastara con arrancarlos
con el disco generado para la modalidad normal y conocer su
dirección IP.
Si no se dispone de las tarjetas de red, pero sí de la
licencia para xPC Target Embedded Option, se puede funcionar en la
modalidad stand-alone, creando los discos de arranque con la
aplicación deseada embebida, de forma que al arrancar el PC
target comience a funcionar el modelo directamente.
Si las dos opciones anteriores no son factibles, se puede
descargar la aplicación via RS-232 a cada uno de los PC
(aunque esta es una solución muy lenta).
Es importante resaltar que la ejecución de xPC target, tanto
en su modalidad normal como en stand-alone, no tiene ningún
efecto en el software instalado previamente en el disco duro del PC
target, ya que el sistema no accede a este. Una vez se reinicia el
PC target, se puede continuar utilizando como un PC estándar
ejecutando Windows, Linux o cualquier otro sistema operativo o
software. Esto es muy conveniente en el caso de que en el
laboratorio en el que se realizan las practicas se necesite utilizar
los PCs target con alguna otra finalidad.
El modelo de simulink completo, incluyendo la adquisición de
señales se muestra seguidamente:
Figura
7: Modelo Simulink
3.2 MODELADO EN RT-PXI
Modelar en Labview la dinámica del péndulo invertido.
Una de las cuestiones más relevantes, es la selección
del periodo de muestreo. Este debe ser lo suficientemente rápido
para que el sistema se asemeje al proceso físico continuo.
Añadir al modelo de LabView los componentes necesarios para
realizar la adquisición de señales. Se debe utilizar
la adquisición de señales punto a punto; ya que el
simulador del proceso se integra dentro de un lazo de control,
donde las acciones de control se proporcionan en cada periodo de
muestreo.
Añadir al modelo los elementos de visualización
propios de LabView. Estos componentes permiten la visualización
de las magnitudes del proceso en tiempo real.
Transferir la aplicación diseñada en LabView al
RT-PXI :
Conectar a través de la red Ethernet con el PXI.
Compilar la aplicación diseñada en el entorno de
LabView.
Descargar la aplicación compilada.
Figura
8: Esquema de LabView
El control de la aplicación y la visualización de las
señales del proceso se realizan desde el PC de escritorio
donde se diseño la aplicación. Ya que el RT-PXI
trasfiere todos los datos del proceso a través de la red
Ethernet.
3.3 DISEÑO DEL CONTROLADOR
El presente apartado aborda el cálculo de un regulador en
espacio de estados. El cual será implementado en la
plataforma descrita en el apartado 3.1.
Se opta por la utilización de un regulador por realimentación
del estado, debido a su sencilla implementación y cálculo.
El diseño del regulador se realiza mediante asignación
de polos. En concreto se fijan los polos del sistema en:
La matriz de realimentación obtenida se muestra a
continuación:
La utilización de la plataforma descrita en este artículo,
permite el estudio de múltiples leyes de control realizando
mínimos cambios en la estructura del sistema. Este hecho
permite focalizar el esfuerzo del alumno en los aspectos
relacionados con el diseño de controladores, pero sin perder
la visión general de un sistema de control real.
3.3 RESULTADOS OBTENIDOS
A continuación se muestran los resultados obtenidos en el
control del péndulo invertido.
Figura
9: Histograma
En la figura 9 muestra el histograma de la duración de los
periodos de muestreo. El valor implementado en el código era
de 3 ms. El histograma muestra como los valores reales tienen un
desvío de 5 nanosegundos respecto al periodo de muestreo
teórico.
Figura
10. Acción de control
Figura
11. Ángulo del péndulo
Figura
12. Posición del carro
En las figuras 10, 11 y 12 puede observarse como el controlador
diseñado es capaz de estabilizar el sistema, manteniendo el
péndulo en la vertical. Las discrepancias entre el
comportamiento del sistema distribuido y la simulación bajo
Simulink son debido a tres factores:
Errores de cuantificación en las tarjetas de adquisición.
Jitters no controlados en la acción de control.
Ruidos en módulos de entradas y salidas analógicos
(debidos a interferencias electromagnéticas).
En conclusión, la plataforma es capaz de controlar el sistema
del péndulo invertido, presentando pequeñas
discrepancias con el control simulado.
4 PRÁCTICAS Y EJERCICIOS PROPUESTOS
El presente apartado describe los diferentes enfoques que engloban
los ejercicios y practicas de laboratorio que pueden realizarse
empleando la plataforma de control distribuido en tiempo real.
Implementación y validación de algoritmos de control
diseñados bajo diversas metodologías de teoría
de control. La validación puede realizarse sobre modelos
simulados o reales.
Análisis exhaustivo de periodo de muestreo, tiempo de
cómputo, jitters y planificación de tareas.
Diseño, configuración y estudio de un sistema de
control industrial distribuido: inclusión de nuevos nodos,
protocolos de comunicaciones, manejo de módulos comerciales
estándar, etcétera.
Los ejercicios y prácticas pueden dividirse en dos grupos
fundamentales. Por un lado, aquellos que pueden realizarse bajo la
estructura básica de la plataforma, es decir la descrita en
el ejemplo del apartado anterior. Por otro lado, existen ejercicios
y practicas adicionales que pueden realizarse llevando a cabo
pequeños cambios sobre la plataforma.
7 CONCLUSIONES FINALES
En el presente artículo se ha descrito una plataforma de
control distribuido en tiempo real. Dicha descripción ha sido
abordada desde una perspectiva académica, con el fin de
ilustrar las posibilidades de la plataforma en dicho ámbito.
La plataforma establece un lazo entre soluciones estándar en
la industria (bus de campo, módulos de entrada salida,
etcétera) y el empleo de algoritmos de control avanzado,
típicos del ámbito académico. En conclusión,
resulta un complemento ideal en la realización de prácticas
en el ámbito de Control.
Agradecimientos
Este proyecto ha sido parcialmente financiado por FEDER
AGL2002-04108-C02-01 y FEDER DPI2004-8383-C03-02 (MEC-Spain).
Referencias
[1] “Adlink technology inc.”,
http://www.adlinktech.com/
[2] “Beckhoff Automation Gmbh”,
http://www.beckhoff.com/
[3] “CAN in Automation, CiA”,
http:/www.can-cia.org/
[4] “ESD electronic system design Gmbh.”,
http:/www.esd-electronics.com/
[5] Farsi, M. (1999) CANopen implementation:
applications to industrial networks, Research Studies.
[6] “GNU Project”,
http:/www.gnu.org/
[7] “National Instruments Corporation”,
http:/www.ni.com/
[8] Pérez E., Pieroni E., Blasco F., Salcedo J. V., (2003) ,
“Uso del Toolbox xPC Target en Prácticas de control e
Identificación”, Seminario anual de automática,
electrónica industrial e instrumentación. SAAEI'03,
Vigo.
[9] Pfeiffer, O. (2003) Embedded networking with
CAN and CANopen, RTC Books.
[10] “Proyecto Ocera”, http://www.ocera.org
[11] Ripoll, I. “Tutotial RT-Linux”,
http://bernia.disca.upv.es/rtportal/tutorial/
[12] xPC Target User’s Guide, Version 2
ed., (2002) The Mathworks, Inc., Natick, MA.
