RtfCANopen: UNA IMPLEMENTACIÓN MODULAR Y ECONÓMICA APLICADA EN EL CONTROL DE UN MÓVIL AUTÓNOMO

Javier Portillo, Marga Marcos, Aitor Olarra, Itziar Cabanes Escuela Superior de Ingenieros de Bilbao (Universidad del País Vasco)

Alameda Urquijo s/n 48013 Bilbao Teléfono: 34 94 601 7216; Fax: 34 94 601 4187

e-mail: jtppobej@bi.ehu.es

Resumen Soporte tanto del modelo Cliente/Servidor como del modelo Productor/Consumidor El comportamiento temporal determinista del bus CAN lo hace muy apropiado para sistemas distribuidos con requisitos temporales. Además, es determinista; es posible calcular el comportamiento temporal de peor caso de todos los mensajes de una red CAN (Tindell and Burns 1994).

Este artículo describe el diseño (hardware y software) y la implementación de un sistema de comunicación modular basado en la red CAN. El objetivo es la construcción de Sistemas Distribuidos de Tiempo Real basados en implementaciones modificables (código fuente disponible) de los protocolos de comunicación. Esto permitirá el control absoluto de la pila de comunicaciones para resolver de manera óptima los requisitos que sobre la comunicación imponga el rendimiento global en tiempo real (cálculo de tiempos de ejecución de peor caso, asignación de prioridades a tareas y mensajes, etc). Esta implementación en CAN (rtfCANopen) es modular, económica, auto-descargable y auto-configurable. En particular, en este trabajo se describe como caso de estudio la aplicación de rtfCANopen en el control de un robot móvil autónomo. Este prototipo se diseña y analiza empleando el conjunto de herramientas Real-Time Framework, desarrollado por los autores. Este entorno abarca todas las fases del ciclo de vida de Sistemas Distribuidos en Tiempo Real: especificación, análisis, simulación y generación de código.

El protocolo CAN básico sólo especifica hasta la capa de enlace o nivel 2 (Modelo de Referencia OSI de ISO). Por tanto, es abierto a protocolos de aplicación y el estándar no especifica nada acerca de temas tales como la gestión de red, planificación de mensajes o formato de datos. Esto significa que uno puede construir ‘a medida’ su propio protocolo de alto nivel sobre la capa de enlace CAN. Este enfoque flexible ha permitido adoptar CAN en campos muy diferentes. Los productores de dispositivos CAN se han unido en diferentes asociaciones para definir protocolos estándar de alto nivel. De esta manera, han aparecido varios protocolos de alto nivel: CAL/CANopen de Can in Automation (CiA), DeviceNet de Open DeviceNet Vendor Association (ODVA), SDS de Honeywell, etc. Además, en algunas de estas asociaciones se han desarrollado perfiles concretos dirigidos a un sector específico de mercado (industria textil, de automoción, etc). Por tanto, los desarrolladores de CAN pueden decidir construir su propio protocolo de alto nivel (dirigido a cubrir requisitos específicos), o utilizar uno estándar.

Palabras clave: Aplicaciones y comunicaciones en tiempo real, bus de campo, sistemas de control distribuidos, sistemas basados en microcontroladores, aplicaciones de control de comunicaciones, programación.

1 INTRODUCCIÓN Los beneficios de adoptar un protocolo de alto nivel estándar, se pueden resumir en los siguientes:

Aunque inicialmente el bus CAN (Controller Area Network) se desarrolló en la Industria del Automóvil (CAN 1991), posteriormente se demostró que es un bus muy adecuado para aplicaciones industriales en general. Entre sus características destacan:

Interconexión e intercambiabilidad de productos de diferentes fabricantes Sencilla conexión y configuración de nuevos dispositivos Disponibilidad de servicios estándar para el arranque y la configuración de la red

Fiabilidad a interferencias electromagnéticas Tiempos de latencia bajos

Capacidad multi-maestro (cualquier nodo puede iniciar la comunicación) Los autores de este artículo trabajan actualmente en

el área de Sistemas Distribuidos en Tiempo Real, particularmente en la integración de diferentes

Muy baja probabilidad de errores residuales

herramientas en el entorno denominado Real Time Framework (RTF). Este entorno de herramientas consigue abarcar las fases de diseño, simulación y generación de código para Sistemas Distribuidos en Tiempo Real (Marcos et al 2000, Portillo y Marcos 2001). También resulta de gran importancia el análisis en tiempo real de las tareas y mensajes, de forma que se asegure que se cumplen los plazos (Marcos y Portillo 2000). Continuando con esta línea de investigación, el entorno RTF debería facilitar el diseño de controladores, topología de la red, sincronización de las tareas concurrentes, etc. También debe calcular los tiempos de respuesta de peor caso para los mensajes y las tareas concurrentes, y obtener las prioridades más adecuadas para ambos. Finalmente, RTF deberá generar el código para todo el sistema distribuido (varios nodos). Al intentar trasladar los resultados teóricos a la aplicación real (fase de generación de código), parece que la adopción de un protocolo de alto nivel particular es la alternativa más lógica ya que: Estudios temporales conducen a implementaciones particulares de los protocolos de alto nivel para lograr una planificación global (tareas y mensajes). Los protocolos de alto nivel existentes no tienen esta flexibilidad. Deben calcularse valores de WCET (Worst Case Execution Time) para asegurar el cumplimiento de plazos extremo a extremo.

Ambas restricciones podrían ser satisfechas a partir del código fuente (en lugar de librerías de código objeto) de los protocolos ya existentes, pero su adquisición resulta extremadamente cara. Adicionalmente a la reducción de costes se desean otras características para la fase de implementación en RTF: Descarga y configuración automática. Deberá descargarse el código a cada nodo a través de la propia red CAN y el sistema será capaz de configurarse por sí mismo. RTF será lo más autónomo posible en las fases de generación de código e implementación del sistema diseñado, se limitarán las operaciones manuales.

Diseño modular, de forma que los aspectos de la comunicación se aíslan de los del control en la filosofía de RTF.

En definitiva, ante la disyuntiva planteada en cuanto a la elección del protocolo de alto nivel, se ha adoptado una solución intermedia. Se ha decidido no empezar desde cero, sino basarse en la especificación de CiA (CANopen, CiA 1996a) para construir una

implementación particular, rtfCANopen. RtfCANopen servirá como puente que permita aplicar los análisis teóricos a la implementación en RTF. De este modo, se consigue la posibilidad de modificar características de la comunicación, pero manteniendo las ventajas del uso de CANopen (conjunto de servicios ya diseñados, interoperabilidad con dispositivos CANopen comerciales). En resumen, el objetivo es construir una red CAN (tanto hardware como software) basada en CANopen y diseñada de forma adecuada para su empleo en el entorno RTF. Esta implementación se denominará rtfCANopen y será capaz de coexistir en la misma red con dispositivos de CANopen. El trabajo que aquí se expone se divide en los siguientes apartados: en el apartado 2 se describen las principales características de CANopen, en el apartado 3 se describe el diseño HW, en el apartado 4 se esboza la arquitectura SW, mientras que los apartados 5 y 6 explican con más detalle los módulos de comunicación y aplicación. En el apartado 7, se realiza un breve resumen del entorno Real Time Framework. Finalmente, se presenta en el apartado 8 un caso de estudio y por último se mencionan las conclusiones obtenidas durante el presente estudio. 2 CANopen CANopen (CiA 1996a) es un protocolo ampliamente adoptado en una gran variedad de aplicaciones. CANopen define varios tipos de mensajes para tratar con datos de diferente naturaleza: PDO (Process Data Object) para datos de tiempo real SDO (Service Data Object) para datos de configuración de los nodos NMT (Network Management Service) para datos de gestión de red

Tal vez, algunos comentarios de los servicios NMT puedan ayudar a entender el funcionamiento completo de CANopen. Los servicios NMT (CiA 1996b) proporcionan una forma de controlar el estado de cada nodo. La fig. 1 muestra los posibles estados del nodo y cómo los comandos NMT permiten pasar de un estado a otro. También es interesante comentar la función del mensaje SYNC, que permite el funcionamiento síncrono de los PDO. Sólo el nodo maestro NMT puede enviar mensajes de sincronismo, y los PDO sincronizados sólo podrán ser transmitidos después de un mensaje SYNC (o un número múltiplo de ellos). De esta forma, un nodo puede ser programado para enviar un mensaje PDO con datos en tiempo real una vez recibidos un número n concreto de mensajes de sincronismo, donde n

depende de la frecuencia con la que estos datos se refrescan.

Fig.1. Estados NMT de los nodos CANopen (EP,

Enter Preoperational)

3 DESCRIPCION HARDWARE Los nodos rtfCANopen, se han diseñado e implementado para formar parte de una red CANopen empotrada, integrada en un prototipo. RtfCANopen controlará y gestionará las comunicaciones en estos nodos, mientras que el código específico de las aplicaciones de control se encargará de gobernar los dispositivos de entrada y salida conectados a cada nodo CAN. Los nodos diseñados se basan en un microcontrolador PIC16F873 (Microchip 1998) tal y como se muestra en la fig. 2. Este utiliza el interfaz SPI (Serial Peripheral Interface) para comunicarse con un controlador CAN MCP2510 (Microchip 1999) y acceder a la red CAN por medio de un transceiver PCA82C250 (Philips 1997).

Fig. 2. Nodo rtfCANopen.

Las características principales del microcontrolador empleado son: 4K word FLASH de memoria de programa, 192 bytes de RAM, 5 MIPS a 20Mhz y un importante conjunto de periféricos donde se incluyen tres contadores, interfaz SPI, USART y conversor analógico/digital. El controlador CAN (MCP2510) gestiona los mensajes transmitidos y recibidos. Este

dispositivo dispone de filtros de recepción (configurados por el PIC) y disparará una interrupción dirigida al PIC cuando se reciba un mensaje esperado.

Fig. 3. Nodo rtfCANopen en red empotrada.

Los parámetros de un nodo básico (velocidad de red, nodeID y la velocidad del microprocesador) se establecen con ‘switches’. Un LED indicará el estado actual del nodo conforme al estándar CANopen (pre-operacional, operacional o parado). Los nodos construidos son protegidos por una pequeña caja, dejando acceso a los ‘switches’, entradas / salidas y conectores CAN para que sea posible su instalación en la red. La fig. 3 muestra un nodo rtfCANopen que envía datos a los sensores infrarrojos de proximidad a través de la red. El coste total de cada nodo es de unos 45 €.

COM(Communication

module)

APP(Application

module)

Interface

I / O Devices

CAN controllerCAN network

COM(Communication

module)

APP(Application

module)

Interface

I / O Devices

CAN controllerCAN network

Fig. 4. Arquitectura Software (nivel 1).

4 ARQUITECTURA SOFTWARE Considerando que se busca la modularidad para aislar los aspectos de comunicación y aplicación, el software que ejecutan los microcontroladores PIC está separado en dos módulos. El módulo de

comunicación (COM) es el mismo para todos los nodos, configurará y gestionará el MCP2510 y se encargará de las comunicaciones a través del bus CAN, de acuerdo al estándar de CANopen. Mientras que el código de aplicación (APP) es diferente en cada nodo para llevar a cabo funcionalidades propias. Como también varían los dispositivos conectados al nodo, las labores de configuración serán diferentes.

NMT (Network Management). En este módulo se implementa la máquina de estados finitos que controla la operación del nodo, según lo establecido en CANopen estándar (CiA 96b). PDO (Process Data Object). Gestiona los mensajes PDO y SYNC. SDO (Service Data Object). Gestiona los mensajes que se utilizan para configurar el nodo, según lo establecido en CANopen.

Los módulos COM y APP se comunican por medio de una interfaz estándar, ya que el módulo COM es siempre el mismo y tiene que colaborar con diferentes códigos de aplicación. En la fig. 4 se muestra esta interfaz estándar, donde las flechas sombreadas muestran el flujo de datos, las líneas curvas señalan las interrupciones y las líneas simples las llamadas entre módulos. Las llamadas realizadas por el módulo COM encontrarán puntos de entrada estándar en algún módulo APP. Es decir, el módulo APP ‘es visto’ siempre de la misma forma.

SPI. Rutinas para acceder al controlador CAN a través de la interfaz de periféricos serie. EEPROM. Rutinas para acceder a la EEPROM en el PIC.

Por tanto, ISR puede considerarse parte de los módulos COM y APP ya que trata cada interrupción del microcontrolador, proveniente de cualquiera de las dos fuentes. De todas formas, la relación entre los módulos ISR y APP se restringe a llamar a appIsr cuando el origen de la interrupción no es el controlador CAN (ver fig. 6), por tanto, ISR se ha incluido en el módulo COM.

El módulo COM está formado por varios sub-módulos (ver fig. 5):

Interruptvector

Savecontext

CANcontroller? appIsr

no

yes

Messagetype?

sdoEntry

pdoEntry

pdoSYNC

SDO

PDO

SYNC

nmtEntryNMT

Interruptvector

Savecontext

CANcontroller? appIsr

no

yes

Messagetype?

sdoEntry

pdoEntry

pdoSYNC

SDO

PDO

SYNC

nmtEntryNMT

ISR (Interrupt Service Routine). Este módulo se encarga de procesar las interrupciones. Las interrupciones pueden ser debidas a los dispositivos conectados al nodo (en este caso ISR llama a appISR del módulo APP), o bien al controlador CAN cuando se recibe un mensaje. En este caso, ISR decide a qué submódulo de COM debe llamar en función del mensaje recibido.

NMT

PDO

SDO

OBJ

APPstandardinterface

ISR

SPI

CAN controller

rtfCANopen

Application

interrupt

I / O DEVICES

interrupts

CAN network

appIsr

NMT

PDO

SDO

OBJ

APPstandardinterface

ISR

SPI

CAN controller

rtfCANopen

Application

interrupt

I / O DEVICES

interrupts

CAN network

appIsr

Fig. 6. Sub-módulo ISR. El módulo APP lo constituyen los siguientes dos sub-módulos: OBJ. Estructuras de datos que definen los objetos implementados en el nodo. APP. Código para acceder a los datos de la aplicación concreta. También realiza la configuración y el control de los dispositivos empleados por la aplicación. Fig. 5. Arquitectura Software (nivel 2).

De esta forma, resulta fácil codificar un módulo APP que trabaja con rtfCANopen (módulo COM). Los programadores solo deben respetar la interfaz estándar mostrada en la fig. 5 (permite la comunicación con los sub-módulos NMT, PDO y SDO) y el punto de entrada appIsr (permite sincronizar los dispositivos y aplicaciones específicas). 5 MÓDULO DE COMUNICACION

(COM) 5.1 SUB-MÓDULO ISR Este módulo llamará a diferentes rutinas dependiendo del tipo de interrupción. Existen dos posibles fuentes de interrupción: el controlador CAN (cuando recibe un mensaje significativo) y la aplicación (cuando alguno de los dispositivos conectados al nodo requiere la atención del microcontrolador).

Como se observa en la fig. 6, cuando la interrupción proviene del controlador CAN, ISR decide qué modulo debe ejecutarse en función del tipo de mensaje (se lee en una estructura de datos del sub-módulo SPI). En caso contrario, se llama a appIsr para alguna operación específica de la aplicación. 5.2 SUB-MÓDULO NMT Cada mensaje de gestión de la red produce una interrupción pero no se ejecutará ninguna acción a menos que el mensaje recibido posea el presente NodeID como destino o sea un mensaje broadcast (identificador 0). Si es así, se ejecutará el correspondiente comando (ver fig. 7). Los comandos NMT pueden cambiar el estado del nodo (variable nmtState) y el LED externo refleja este estado; el LED parpadeará después de los comandos Reset Communications o Reset Application, brillará después del comando Node Start y se apagará con Node Stop. Los mensajes que se reciban serán función del estado actual del nodo (ver Tabla 1). Cuando se recibe el comando Reset Application se llama a la rutina appReset (en el módulo APP) para configurar todo lo relacionado con la aplicación. Por tanto, se llama automáticamente a Reset Communication, de forma que se configuran los PDOs por defecto (conforme a la tabla almacenada en APP) y se ejecuta NmtStarting. NmtStarting configura el funcionamiento del controlador CAN: lee las posiciones de los ‘switches’, establece el nodeID y la velocidad de la red en baudios, configura

los filtros de recepción conforme a los objetos PDO y habilita las interrupciones con la recepción de cada mensaje.

81h

82h

80h

01h

02h

nmtEntry

nodeID

command

isrEnd

Reset application

Reset communications

Enter Pre-operational

Node Start

Node Stop

other

0 or the nodeIDof this node

81h

82h

80h

01h

02h

nmtEntry

nodeID

command

isrEnd

Reset application

Reset communications

Enter Pre-operational

Node Start

Node Stop

other

0 or the nodeIDof this node

Fig. 7. Sub-módulo NMT. 5.3 SUB-MÓDULO PDO La configuración para los PDOs se describe en estructuras de datos, las cuales son almacenadas en la EEPROM. Esta descripción consiste en los siguientes campos: IDH e IDL (alto y bajo bit del identificador), TxType, M1-M8 (objetos mapeados) y RES (reservado). La fig. 8 muestra el funcionamiento de este sub-módulo. Las rutinas Handle_message y Build_message llaman a APP para escribir (de un mensaje a la memoria) o leer datos (de la memoria ponerlos en el mensaje) de acuerdo a las estructuras de datos descritas en la EEPROM. Cuando se recibe un mensaje SYNC, se debe comprobar si los PDOs para el envío están siendo utilizados o no (pdoVALIDRTR en EEPROM). Si es así, los PDOs se enviarán automáticamente cada mensaje SYNC, o (conforme a su configuración) después de múltiples mensajes SYNC. Si ambos mensajes tienen que ser enviados (se configuran ambos PDOs de transmisión), el mensaje de mayor prioridad se enviará primero. La variable PdoVALIDRTR y las estructuras de datos en la EEPROM pueden ser modificadas mediante mensajes SDO, accediendo a las entradas estándar del diccionario de configuración PDO.

buffer

Download SDOroutine

All bytes havebeen received

Object accessroutine

ISR

message

Objectvariables

Sendconfirmationand isrEnd

All bytes haven´tbeen received

buffer

Download SDOroutine

All bytes havebeen received

Object accessroutine

ISR

message

Objectvariables

Sendconfirmationand isrEnd

All bytes haven´tbeen received

5.4 SUB-MÓDULO SDO Existen dos diferencias fundamentales entre objetos PDO y SDO que deben tenerse en cuenta: Se permite la segmentación de mensajes para SDO, por lo que son necesarios buffers para almacenar los datos temporalmente hasta que la totalidad del mensaje esté construido. Los envíos SDO requieren confirmación.

Las figuras 9 y 10 indican cómo escribir y leer los SDOs.

Pre Operational

Operational

Stopped

yes

yes

NMT

yes

yes

no

SDO

yes

yes

no

PDO

no

yes

no

SYNC

no

nmtState

Fig. 9. Proceso de descarga.

Tabla 1. Aceptación de mensajes

buffer

Upload SDOroutine

Object accessroutine

ISR

message

Objectvariables

Send confirmation

with dataand isrEnd

Sendconfirmation and isrEnd

SDOroutines

initializationNext

segments

buffer

Upload SDOroutine

Object accessroutine

ISR

message

Objectvariables

Send confirmation

with dataand isrEnd

Sendconfirmation and isrEnd

SDOroutines

initializationNext

segments

pdoTx

Build_messageSend message

isrEnd

pdoRx

Handle_message

isrEnd

PDO1 in use ? No, exit blockbuild_messagePDO1 to be sent ? Yes, set flag1

PDO2 in use ? No, exit blockbuild_messagePDO2 to be sent ? Yes, set flag2

pdoSYNC

Send pending PDOs

isrEnd

pdoTx

Build_messageSend message

isrEnd

pdoRx

Handle_message

isrEnd

PDO1 in use ? No, exit blockbuild_messagePDO1 to be sent ? Yes, set flag1

PDO2 in use ? No, exit blockbuild_messagePDO2 to be sent ? Yes, set flag2

pdoSYNC

Send pending PDOs

isrEnd

Fig. 10. Proceso de upload.

5.5 SUB-MÓDULOS SPI Y EEPROM Fig. 8. Módulo PDO. Estos módulos constan de todas las rutinas y macros utilizadas por otros módulos para acceder fácilmente a la EEPROM y a los registros del controlador CAN mediante Serial Peripheral Interface. La estructura de datos del buffer SPI tiene los mismos campos que los buffer emisor y receptor del controlador CAN: CTRL, SIDH, SIDL, D0-D7.

El diccionario de objetos es el conjunto de objetos a los que se puede acceder utilizando SDOs (CiA 1996a). Parte de este diccionario (aquellos objetos requeridos por CANopen) se desarrolla en el módulo COM, y otra parte se define por la aplicación en el módulo APP.

Rutinas de acceso a objetos definidas por la aplicación

IndexHigh IndexLow SubIndex Properties

sdoObject = xx

1 point to required entry

2 call desiredtable

3get theresult

IndexHighIndexHigh IndexLowIndexLow SubIndexSubIndex PropertiesProperties

sdoObject = xx

1 point to required entry

2 call desiredtable

3get theresult

...goto appRoutine1...

...goto appRoutine3...

goto app1goto app2goto app3...

@app1instr1instr2....

@app2instr1instr2...

@app3instr1instr2....

Program memory spaceof Communications module

Fixed memory spaceof the jump table

Program memory spaceof aplication module

...goto appRoutine1...

...goto appRoutine3...

goto app1goto app2goto app3...

@app1instr1instr2....

@app2instr1instr2...

@app3instr1instr2....

Program memory spaceof Communications module

Fixed memory spaceof the jump table

Program memory spaceof aplication module

Fig. 11. Tablas de uso del módulo OBJ.

6 MÓDULO DE APLICACIÓN (APP) 6.1 SUB-MÓDULO OBJ Contiene estructuras de datos que describen cada objeto implementado en el nodo. La siguiente información debe ser especificada para cada uno de los elementos en el diccionario de objetos (CiA 1996a): Índice del objeto (16 bits, necesita 2 tablas) Subíndice Propiedades (objeto de sólo lectura ó lectura / escritura, el objeto puede ser mapeado a un PDO ó no, la longitud en bytes de la variable ó registro que desarrolla el objeto) Fig. 12. Tabla de saltos.

Toda esta información se guarda en cuatro tablas (fig.

11) y la variable SdoObject es el apuntador utilizado para acceder a ellas. Estas tablas deben estar en una posición fija de la memoria, de manera que el módulo COM pueda localizarlas.

7 REAL TIME FRAMEWORK (RTF) Como ya se ha mencionado, los autores (Marcos et al 1999, Marcos y Portillo 2000 y Marcos et al 2000a, 2000b, Portillo y Marcos 2001) trabajan en un entorno para desarrollar aplicaciones distribuidas en tiempo real basadas en el bus CAN. Este entorno (RTF) abarca todas las fases incluidas en el diseño de un Sistema de Control Distribuido en Tiempo Real, desde las especificaciones hasta la generación de código. El núcleo de RTF es la definición de los metamodelos del sistema (Funcional, Arquitectura, Temporal e Implementación). RTF manipula los 4 modelos ofreciendo diferentes herramientas software que permiten al usuario definir y analizar el sistema, antes de generar el código de la aplicación.

6.2 SUB-MODULO APP Una interfaz estándar permitirá al módulo de comunicación llamar a las rutinas en APP. Esta interfaz consiste en una ‘tabla de saltos’ (ver fig. 12) localizada en una posición fija de la memoria. Las instrucciones de salto conducen a las diferentes rutinas específicas. Las rutinas específicas que deben constar en APP son las siguientes:

AppReset. Iniciación de la aplicación y de los dispositivos controlados. RTF ha sido completamente desarrollado utilizando

Matlab y toolboxes relacionadas (Mathworks 1999a, 1999b, 1999c, 1999d). Las caractyerísticas ofrecidas por Simulink y Stateflow se han completado con algunos bloques nuevos (Librería RTF) para especificar el sistema distribuido completo. El sistema especificado genera los cuatro modelos diferentes mencionados anteriormente, por lo que el sistema puede ser analizado y simulado desde varios puntos de vista. Los resultados obtenidos suponen la realimentación necesaria para rediseñar partes del sistema. Cuando se valida el diseño (la simulación de

AppIsr. Rutinas de servicio de interrupciones. AppStarting. Rutinas relacionadas con el comienzo o puesta en marcha de la aplicación. AppStop. Rutinas relacionadas con el final de la aplicación.

Otras informaciones en APP: Identificación de las tablas (entradas al diccionario de objetos) Tabla de configuración de objetos PDO por defecto

cada modelo es satisfactoria), se debe dividir en subsistemas ya que el código correspondiente se generará para cada target durante la fase de implementación. Algunas mejoras en Real Time Workshop (Mathworks 1999d) permiten la generación de código para cada target especificado. En el nivel superior, el usuario debe definir la arquitectura general del sistema distribuido en términos de los nodos que se conectarán a través del bus CAN y los enlaces de comunicación. El modelo de arquitectura (Architecture Model) se especifica en RTF por medio de un conjunto de bloques de librería que han sido integrados como nuevos bloques de Simulink. Los nodos pueden ser bien CPUs, donde se ejecutarán los algoritmos de control definidos por el usuario, o bien nodos de entrada / salida, dispositivos que conectan los sensores y actuadores a la red CAN. Siguiendo un enfoque jerárquico, el usuario puede definir la arquitectura software para cada nodo en términos de: tareas concurrentes existentes, sincronización entre dichas tareas y comunicación entre el nodo y la red CAN (mensajes enviados y/o recibidos). Para ello, se dispone de un conjunto de bloques que permiten una especificación intuitiva y gráfica del modelo. Utilizando la potencia de Simulink y las toolboxes de Stateflow, el usuario especifica los algoritmos de control así como el comportamiento de eventos discretos para cada tarea. Esta información constituye el Modelo Funcional. El Modelo Temporal se especifica en términos de requisitos de tiempo y una herramienta específica, denominada BERTA (Marcos y Portillo 2000) utiliza este modelo para realizar el análisis temporal. El Modelo de Implementación recoge las características del hardware y software de la aplicación, en términos de los nodos CAN, placas base CPU, sistemas operativos, etc. En este contexto, rtfCANopen se ha incluido como protocolo de alto nivel soportado por RTF. Tras depurar el sistema desde la visión de estos modelos, se utiliza la toolbox Real Time Workshop de Matlab para generar el código a ejecutar en cada target, así como para configurar y poner en marcha los nodos CAN. 8 CASO DE ESTUDIO El hardware y software rtfCANopen descrito se ha aplicado para el desarrollo de un sistema de control distribuido concreto, un robot móvil autónomo (fig. 13). Los servos, sensores infrarrojos, motores, sónar,

LCD y teclado se controlan empleando los nodos microcontroladores diseñados. Por ejemplo, en la fig. 14 se muestra un nodo microcontrolador (caja gris) conectado a un motor. Una CPU PC-104 a través de una tarjeta comercial CAN (ESD 1998) configura tanto la red como los nodos microcontroladores, además de coordinar y supervisar el sistema global. El objetivo es controlar los movimientos del robot conforme a cuatro conductas de comportamiento: ‘explorar el entorno’, ‘evitar obstáculos’, ‘seguir línea’ y ‘control remoto’. Como se sugiere en el trabajo de Brooks (1989), el conjunto de habilidades del robot puede verse como el resultado de algún tipo de evolución, como en el caso de los animales. Una vez que el robot sea capaz de realizar una conducta básica, puede ir adquiriendo nuevas conductas. El conjunto global de habilidades deseadas para el robot no tiene que ser descrito ni desarrollado desde cero, sino con un enfoque donde la complejidad crece poco a poco. Esta filosofía conduce a definir el control del robot como la suma de cuatro conductas, cada una de ellas con un nivel de activación específico en cada momento, Activation Level (AL). Por tanto, todas las conductas están siempre presentes pero con diferentes intensidades. El movimiento final del robot es el resultado de la suma ponderada de las conductas. Los niveles de activación serán los pesos o factores de ponderación para las diferentes conductas.

Fig. 13. Robot móvil autónomo.

Un motor controla cada rueda del robot. Los motores están conectados a los nodos rtfCANopen a través de tarjetas auxiliares que proporcionan la potencia necesaria (fig. 14). El movimiento del robot puede definirse utilizando velocidades individuales de cada

rueda (Vleft, Vright), sin embargo, se han seleccionado otras dos variables: velocidad lineal (V) y velocidad de giro (ω). La fig. 15 muestra estas componentes y sus relaciones con las velocidades de las ruedas.

21

21

ALAL

AL2

AL1

out 222V2VV

+⋅+⋅

=

21

21

ALAL

AL2

AL1

out 2222

+⋅ω+⋅ω

=ω

ALout = max (AL1, AL2)

Por tanto, los bloques de ponderación consiguen mantener altos los niveles de activación para las conductas dominantes mientras que se inhiben las conductas menos importantes. Al mismo tiempo, se calculan los valores de las velocidades medias ponderadas (Vout y ωout). RTF se utiliza para especificar el sistema distribuido y generar el código de la aplicación. En el nivel superior se define la arquitectura de la red, constando de un nodo de la CPU, el controlador, y seis nodos rtfCANopen, correspondiente a los sensores y actuadores (ver fig. 16). La CPU trabaja bajo el sistema operativo VxWorks e incluye una tarjeta CAN del fabricante ESD (ESD 1998). Realiza el control del sistema y durante la puesta en marcha configura los nodos de entrada / salida.

Fig. 14. Nodo RtfCANopen para controlar uno de los

motores. La fig. 17 muestra el modelo de las conductas para el nodo de la CPU, en otras palabras, aquellas tareas concurrentes que van a ejecutarse en la CPU PC-104. Las cuatro conductas (‘explorar el entorno’, ‘evitar obstáculos’, ‘seguir línea’ y ‘control remoto’) se implementan como tareas concurrentes y un conjunto de tareas de ponderación realiza la compensación para obtener la consigna de velocidad.

V ω

ωϖ

−+

=⋅

−+

=

11

11

211

11

VameterPlatformDiVVrightVleft

En la fig. 18 se observa la especificación en Simulink de las tareas de ponderación, mientras que en las figuras 19 y 20 se observa la especificación de las conductas ‘exploración del entorno’ y ‘seguir línea’.

Fig. 15. Componentes de velocidad del robot.

Como consecuencia, V y ω serán las consignas generadas por el algoritmo de control. Estas consignas, junto con el nivel de activación (AL), serán generadas de manera concurrente conforme a cada una de las cuatro conductas. El procesado de los valores de salida (V y ω) y de los niveles de activación (AL) para cada conducta genera las referencias para los motores. En Olarra 2001 se resume la descripción detallada de este proceso.

SONAR

REMOTE CONTROLLER

ENGINES

PATH TRACKER

INFRARED 2

INFRARED 1

PC-104 CPU

Los bloques de ponderación calcularán valores medios a partir de los valores de las consignas obtenidas de una pareja de conductas. Así, el ponderador toma dos consignas de velocidad (V1, V2 y ω1, ω2) y los niveles de activación asociados (AL1 y AL2) y genera una consigna de velocidad ponderada de salida (Vout, ωout) y un nivel de activación de salida ALout.

Fig. 16. Arquitectura de red.

V, W Vrigh t, V le ft

2 Servo inPath Tracker

1Vrigh t, V le ft

sendCAN

sendCAN

rece iveCANrece iveCANrece iveCANrece iveCANrece iveCAN

SPEED VARIABLESCONVERSION

REMOTECONTROLLING

PONDERATIONTASK 3

PONDERATIONTASK 2

PONDERATIONTASK 1

PATHTRACKING OBSTACLE

AVOIDANCE

ENVIRONMENTEXPLORING

CONFIGURATION

5MMI4In fra red

23In fra red12Sonar

1In fra red inPath Tracker

Fig. 17. Modelo de tareas para el nodo CPU.

V1, W1

AL1

V2, W2

AL2

1Vout, Wout, ALout

max

1

u

uv

uv

m

m

2

2

2V2, W2, AL2

1V1, W1, AL1

Fig. 18. Implementación de la ponderación en Simulink.

A L

A L

V

W1

V, W, AL

U n i f o r m R a n do m

N u mberV

w

R A N D O M S P E E D

S E T P O I N T G E N E R A T I O N

N E W A C T I V A T I O N

L E V E L G E N E R A T I O N

H i t

C r o s s i n g

m1V, W, AL

Fig. 19. Especificación de la tarea ‘Explorar el entorno’ en Simulink.

W

V

Activa tionLeve l

2SERVO IN

PATH TRACKER

1V, W, AL

Satura tion

Product

IRleft

IRright

SERVO

STATE

PATH TRACKING CONTROL

Look-UpTable1

Look-UpTable

-1

Gain

ExternCode

ExternCode1

ExternCode

ExternCode

m

127

1INFRARED IN

PATH TRACKER

Fig. 20. Especificación de la conducta ‘Seguir línea’ en Simulink. . Código para programar las tareas de coordinación y supervisión

La conducta ‘evitar obstáculos’ generará un valor nulo para V y ω, y un nivel de activación tanto más alto cuando más cercano detecte un objeto frente al robot. Como resultado, esta conducta no se tiene en cuenta cuando los obstáculos están lejos, pero sí se vuelve muy importante (incluso el robot se para) cuando están muy próximos.

Código para controlar la tarjeta CAN (ESD 1998), incluyendo las librerías comerciales de CANopen (código objeto) Código para la puesta en marcha de la red y descarga de todos los módulos APP a las tarjetas.

La conducta ‘explorar el entorno’ añade otra

característica al aprendizaje del robot. Esta conducta es la dominante sólo si no hay ningún usuario que lo dirija (control remoto) y no está siguiendo ninguna línea, esta es la razón para considerar como entradas el nivel de activación de aquellas conductas. El nivel de activación de ‘explorar el entorno’ será alto cuando el resto de las conductas tengan un nivel de activación bajo. En este caso, el robot genera una consigna de movimiento aleatorio para explorar el entorno (ver fig. 19).

9 CONCLUSIONES En este trabajo se presenta el desarrollo de una red económica CANopen que es adecuada para su uso en aplicaciones distribuidas empotradas, que sean compatibles con CANopen. Su diseño modular (módulos de comunicación y aplicación) y su económico desarrollo hacen que rtfCANopen sea apropiado para los ingenieros de control que pueden centrarse en los aspectos de control, dejando la resolución de la comunicación a una librería ya desarrollada. De cualquier forma, cuando el protocolo de comunicaciones debe modificarse por motivos del control, rtfCANopen lo permite.

La conducta ‘seguir línea’ (ver fig. 20) genera otra salida, además de V y ω, ya que el vástago debe ser movido (por medio de un servo) para que siga el camino. Una máquina de estados finitos descrita con StateFlow gobierna esta tarea. La conducta ‘control remoto’ se diseña para seguir los movimientos dirigidos por un usuario desde una interfaz remota. Solamente esta conducta y la de ‘evitar obstáculos’ pueden tener el máximo AL, mientras que el resto de conductas nunca pueden alcanzar los valores más altos.

Se ha probado la compatibilidad de los nodos implementados y dispositivos comerciales CANopen con nodos de entrada / salida (Selectron 1997) y con la tarjeta del controlador CAN PC-104 (ESD 1998). Además, se ha desarrollado un prototipo para mostrar los beneficios logrados con rtfCANopen:

Finalmente, el código para la CPU PC-104 se genera automáticamente desde RTF. Este código incluye:

• Comunicación entre nodos propios (rtfCANopen) y nodos comerciales (tarjeta CANopen en PC-104 CPU)

• Control total en la generación de código desde el entorno RTF

• Distinción clara entre el código de la comunicación y de la aplicación

• Características de auto-configuración y descarga

• Construcción de un prototipo económico. Este trabajo se convierte en un adecuado banco de pruebas para RTF, lo que permite unificar la teoría y el desarrollo práctico. El trabajo futuro incluye modificaciones de rtfCANopen que mejoren los requisitos de tiempo real (aunque manteniendo la compatibilidad con CANopen) y midan el tiempo de cómputo de peor caso (WCET). El código fuente de rtfCANopen y la documentación correspondiente está disponible en la dirección www.disa.bi.ehu.es/rtfCANopen. Agradecimientos Este trabajo se ha realizado gracias a la ayuda otorgada por el Ministerio de Ciencia y Tecnología dentro del marco del Proyecto TAP 98-0585-C03-02, por la UPV/EHU 146-345-TB196/98 y GV PI-1998-42.

Referencias Brooks R. A. (1989). A Robot that Walks; Emergent

Behaviors from a Carefully Evolved Network. MIT Press.

CAN (1991). Bosch CAN specification, V 2.0 PartA. R. Bosch Gmbh, Germany.

CiA (CAN in Automation) (1996a). CANopen Communication profile for Industrial Systems. CiA Draft Standard 301. CiA, Germany.

CiA (CAN in Automation) (1996b). NMT service specification. CiA Draft Standard 203-1.CiA, Germany.

ESD gmbh (1998). CAN-PC104/331 software manual. Electronic System Design gmbh. Hannover (Germany).

Marcos, M. M., Portillo, J. (2000). Basic Environment for Real Time Systems Analysis using CAN bus. Proceeding of the Workshop on Real Time Programming. Palma de Mallorca (Spain), May 2000.

Marcos, M. M., Portillo, J., Bass J.M. (2000). Matlab-based real-time framework for distributed control systems. Proceeding of the Workshop on Algorithms and Architectures for Real-Time Control. Palma de Mallorca (Spain), May 2000.

Mathworks (1999a). Using Matlab version 5.3.

Mathworks (1999b). Simulink: Dynamic System Simulation for Matlab V2.1

Mathworks (1999c). Stateflow: For use with Simulink. User’s Guide

Mathworks (1999d). Real Time Workshop: For use with Simulink. User’s Guide

Microchip (1998a). PIC16F87X 28/40 pin 8-bit CMOS FLASH microcontrollers. Microchip, USA.

Microchip (1998b). MPLAB ide, simulator, editor user´s guide. Microchip, USA.

Microchip (1999). MCP2510 Stand-Alone CAN controller with SPI interface. Microchip, USA.

Olarra A. (2002). Diseño e implementación de nodos de comunicación basados en el bus CAN y su aplicación a un móvil autónomo. Systems Engineering and Automatics Department (Faculty of Engineering), Internal report, Bilbao 2002. www.disa.bi.ehu.es/rtfCANopen

Philips semiconductors (1997). PCA82C250 CAN controller interface. Philips Semiconductors, The Netherlands.

Portillo, J., Marcos, M. (2001). Contributions to the design of real time distributed control systems. Proceedings of the European Control Conference, September, 2001. Porto, Portugal.

Selectron (1997). Selecontrol MAS. System manual CANopen. Selectron Systems AG, Lyss (Switzerland).

Tindell, K. and A. Burns (1994). Guaranteeing Message Latencies on Controller Area Network (CAN). Proceedings 1st International CAN Conference, Mainz (Germany), September 1994.