Estructura Jerárquica de Buses para Control de un Vehículo

ESTRUCTURA JERARQUICA DE BUSES PARA CONTROL DE UN VEHICULO AUTONOMO
M.Modesti, L.Canali, E. Destefanis
Universidad Tecnológica Nacional FRC GIII
Grupo de investigaciones en informática para la Ingeniería
Universidad Tecnológica Nacional
Facultad Regional Córdoba
CC 36 Sucursal 16, 5016 Córdoba Argentina
Fax : 0054-351-4681823
email : [email protected]
Palabras clave : buses industriales, Vehículo autónomo (AGV ), Red Local (LAN),
Protocolo Control de Transmisión (TCP) / Protocolo de Internet (IP), Protocolo de
datagrama de usuario (UDP ), Controlador de acceso de bus (CAN ), Interconexión de
sistemas abiertos (OSI )
Resumen : Ante la necesidad de teleoperar procesos que requieren de movilidad,
fundamentalmente referida a vehículos de transporte, se propone una estructura capaz
de insertarse en una red existente como un usuario de la misma y controlado por medio
de los protocolos standard disponibles en la red existente
1
Introducción
Inscripto en el proyecto de desarrollo de un vehículo autoguiado, se propone una estructura
de mando aplicando el concepto moderno de internetworking, se plantea una estrategia de control
para la gestión autónoma y remota, considerando al vehículo como una celda de proceso no como
una máquina individual y que el estado del arte en telecontrol hace cada vez más necesario utilizar
medios telemáticos en particular internet y sus protocolos asociados [1], contribuyendo además de
esta manera a acceder de una forma ordenada a los recursos instalados en el vehículo desde
puestos de operación remota haciendo posible una construcción más simple y fácil de crecer
cuanto de mantener.
Las posibilidades de esta concepción hacen que el AGV se incorpore a un sistema
jerárquico de control capaz de comunicarse por medio de distintos protocolos con otros niveles de
gestión inscripto en una topología abierta OSI (Open System Interconnect). Se plantea la
estructura sobre un modelo comunicado por medio de buses y protocolos standard, la arquitectura
que vincula los medios disponibles puede apreciarse en la figura 1.
Figura 1
Estructura de mando para vehículo autónomo ( AGV )
En la figura 1 se muestran los recursos instalados y la topología de la red propuesta, la
misma se desarrolla en tres niveles jerárquicos a continuación detallados.
Nivel de campo : gestión de sensores y actuadores del sistema.
Nivel de control : Para la gestión de navegación por medio de telecámara y joystick
Nivel de supervisión : para el monitoreo del sistema desde estaciones remotas
Se considera una contribución importante al estado del arte en tecnología de guiado, el
hecho que todos los dispositivos del sistema se puedan acceder desde diferentes puntos de
acceso permitiendo la posibilidad de adoptar decisiones de mando en forma distribuida, La
incorporación de esta estructura en una red existente lo hace aún más importante visto que una
red de área local se dispone en cualquier medio fabril actual.
Desde el punto de vista de conexión física se proponen los siguientes standard de comunicaciones a continuación detallados.
2
Nivel de campo : Bus CAN ( Control Area Network )[2]
Este Nivel de Sensores / Actuadores es el más bajo y debe proveer las capacidades de
comunicación para todos los recursos, tanto en velocidad de transmisión cuanto en volumen de
datos a transferir. Este protocolo provee funcionalidad multimaster y capacidad de tiempo real.
El mecanismo de acceso de CAN esta implementado como un arbitro bidireccional no
destructivo, esto último significa que el vencedor del arbitraje ( mensaje de más alta prioridad ) no
debe restablecer el mensaje desde el principio.
El método de acceso es CSMA/CD+AMP (Carrier Sense Multiple Access with Collision
Detection and Arbitration on Message Priority. Acorde con este algoritmo, ambos nodos de red que
establecen una comunicación esperarán hasta que el bus este libre ( Carrier Sense ).
Cuando esto ocurra, ambos nodos transmitirán su bit de start ( Multiple Access ). En la
figura 2, a continuación se observa el esquema de hardware utilizado para el bus detallado.
Figura 2
Estructura de hardware de CAN
En las unidades del vehículo los nodos están controlados por una unidad gestionada por
PIC con interfase CAN MCP2510 y como tranceptores físicos MCP82C250 para obtener los
niveles eléctricos normalizados. del RS485 modificado
En el mando constituido por un PC Pentium standard la interfase CAN es una tarjeta
comercial Advantech PCL-841.
3
Nivel de Control : LAN wireless spread spectrum IEEE 802.11
Debido a las características móviles de la máquina obligan a un enlace radial de red. La
interface es capaz de proveer servicios a través de Ethernet por medio de un enlace wireless
spread spectrum, con diversos protocolos, en este caso particular será TCP/ IP.
Este nivel de control estará trazado sobre una plataforma Ethernet que responde a las
recomendaciones IEEE para redes locales y metropolitanas, 802.3 para CSMA/CD y 802.11 para
comunicación inalámbrica.
En este nivel se resuelven las estrategias de guiado por medio de la transmisión de
consignas de joystick así como las imágenes provenientes del vehículo permitirán la información
remota de realimentación de posicionamiento, se hace uso de un algoritmo de compresión de
imágenes capaz de reducir el volumen de datos hasta un 75% por medio de la transformada de
Haar, de manera de no congestionar la red con paquetes de datos voluminosos
4
Nivel de supervisión : Internet / Intranet ( Ethernet )
Las estaciones de supervisión remota a través de intranet / internet del sistema serán
comunicadas por medio de protocolo UDP para evitar todos los mecanismos de garantía de
comunicación que dispone TCP haciendo la comunicación del sistema más lenta.
Los protocolos a utilizar de acuerdo al standard de red de cada nivel serán
Nivel de campo
: CSMA / CA
Nivel de Control
: TCP / IP
Nivel de supervisión : UDP
Las experiencias demostraron que el empleo de protocolos seguros para el manejo de toda
la información hace el sistema lento ya que se deben esperar las confirmaciones de arribo y
secuencia, no obstante una comunicación ¨híbrida¨ del tipo TCP/UDP es una solución aceptable,
adjudicando la jerarquía correspondiente a los datos a transmitir. Las aplicaciones fueron
realizadas en Builder C++
5
Arquitectura del software de aplicación
La aplicación del nivel de control se encuentra en el mando del vehículo conformando un
nodo entre la red CAN del vehículo mismo y la red local por medio de una unidad Ethernet
inalámbrica.
La estructura predominante para este tipo de aplicación sea en CAN o TCP/IP es del tipo
mailbox [2] ( casilleros de correo ), lo que significa que los datos compartidos serán tomados de un
casillero de arribo de los diferentes niveles de red y depositados en casillas de correo pertinentes a
cada nivel de aplicación, este tipo de recurso permite desvincular los dos niveles de red diferentes
para que cada uno trabaje a la velocidad que requiera, independientemente de las solicitudes del
proceso en cada caso.
Es evidente por otra parte que no todos los datos de cada nivel deben ser transferidos al
otro nivel por lo que existirá una sub-aplicación capaz de discernir el reenvío de los datos a uno u
otro nivel cambiando los paquetes de casillero. El casillero oficiará de cola de espera donde los
datos luego de ser enmarcados con el header correspondiente al protocolo serán depositados en
el casillero destino para luego ser enviados al medio físico.
El enmarcado de los datagramas no es un problema a resolver debido que en el caso de
CAN se dispone de una interfase inteligente (MCP2510) que se ocupa de la incorporación de los
atributos correspondientes para la confección del datagrama a nivel de microcontrolador en las
unidades esclavas y por medio del driver de la tarjeta en el PC, en la fig. 3 puede apreciarse la
estructura interna de un nodo CAN, Para el enmarcado de los datagramas TCP, se utilizan
funciones de alto nivel de Builder.
Visto que el intercambio de datos se producirá a nivel de link de datos, ver fig 4, la
aplicación oficiará de puente entre ambos protocolos. Los puentes son el vínculo entre diferentes
buses con diferentes tipos de acceso, no es un dispositivo inteligente . Interpreta tanto nivel 1
como nivel 2 de la estructura OSI [3], y en este caso, esta aplicación está resuelta por medio de
software.
La aplicación tendrá injerencia solamente en los niveles 1, 2, y 7 de OSI, que puede
apreciarse en la Fig. 4 con los dispositivos de asistencia en la comunicación.
A nivel de controlador en las unidades del vehículo la aplicación estará conformada de
casilleros de correo entre la aplicación resuelta por el control del dispositivo y la red que conforma
el nodo mismo.
Figura 3
Estructura para comunicaciones CAN
Figura 4
Estructura OSI y dispositivos de asistencia
La aplicación en la estación remota de control y estaciones de supervisión están corriendo
sobre Windows NT y los programas utilizan los servicios TCP/IP del compilador Builder C++. La
comunicación será realizada por medio del acceso a través del socket API de windows NT [4]
haciendo uso de las librerías a tal efecto disponibles en Builder C++.
6
Trabajo a futuro
En la actualidad el standard CAN utilizado es el básico que permite un datagrama de 11 bits,
y a los efectos de incorporar un mayor performance de comunicaciones se implementará el CAN
extendido que dispone de un datagrama de 29 bits, con el objeto de poder explotar al máximo las
prestaciones de este bus.
Visto que el enlace de datos consiste en una plataforma de comunicaciones multiprotocolo,
sea en el lazo directo como de retroalimentación del sistema interactuado por la estación remota,
se procederá al modelado de la estructura de redes a los efectos de poder simular el control sea
en movimientos cuanto operación de los dispositivos a bordo del vehículo.
A los efectos de aumentar la seguridad en la comunicación, se prevé en el futuro incorporar
un reloj de secuencia que permita determinar si los enlaces CAN y TCP/IP se encuentran
operativos para tal efecto se puede enviar sistemáticamente una señal de sincronismo que
permita adoptar decisiones en caso de no existir, como por ejemplo inhibir los accionamientos
hasta disponer de un enlace confiable de comunicaciones, visto que se trata de un proceso de
características móviles.
7
Referencias
[1]
Performance evaluation of control networks: Ethernet, ControlNet and deviceNet
IEEE Control Systems Magazine Vol 21 N°1 pp 66-83 ( 2001 )
[2]
CAN Specification Ver 2.0, 1991, Robert Bosch GmbH, Postfach 50, D-7000 Stuttgart 1
CAN System Engineering, Wolfhard Lawrenz, ISBN 0-387-94939-9, 1997 Springer - Verlag
[3]
OSI / ISO Model
http://www.uleth.ca/~yo0unk/osirefm.htm
[4]
Internetworking with TCP/IP, Client server Programming and applications Vol III
Windows Socket version, Douglas Comer, David stevens
ISBN 0-13-848714-6
2997 Prentice Hall