DINASTIA SOFT
Home Page
NOTAS 
e-mailFormulario de consultasHome Page

 

 

CAN Controller Area Network


El desarrollo de los microcontroladores en la últimas dos décadas y su aplicación a multitud de dispositivos industriales obligó a implementar comunicaciones digitales entre ellos y sus sistemas de control, independientemente de los fabricantes, para aprovechar las ventajas que supone montar una estructura de red. Internacionalmente se denomina genéricamente FIELDBUS a un enlace digital de este tipo. Una característica adicional que define los "Fieldbuses" es la transferencia de bloques complejos de datos entre dispositivos, frente a otros sistemas cuya unidad de intercambio se basa en el byte o el BIT, orientados a gestionar dispositivos simples. En la práctica, hay muchos intentos de estandarizar universalmente el concepto de Fieldbus, y muchas más soluciones industriales, más o menos acordes con cada uno de los estándares. Entre ellos cabe mencionar los siguientes:

* IEC 1158/ISA SP50.02 Generado en los Estados Unidos, pretende ser el futuro estándar universal. WorldFIP (World Factory Instrumentation Protocol) es el protocolo mas cercano a dicha norma y parece ser eficiente para una interconexión simple y económica.


* EN50170/ISA-SP50 Desarrollado en Alemania por Siemens está implementado bajo el nombre de Profibus y es muy utilizado en automatización.

* ISO 11898/ISO 115192 CAN: Controller Area Network especifica solamente el nivel físico y el nivel de enlace, desarrollado en principio por Bosch y Phillips, para reducir cableado en automóviles, tiene múltiples soluciones en función del software que se coloca encima, bajo la forma de High Level Protocol o protocolo de alto nivel como suelen denominarse. Las mas importantes son las de -CAN Aplication layer-CAL/CaNopen desarrollada por CiA (CAN in Automatión). -DeviceNet desarrollada por Allen_Bradley y soportada por la ODVA (Open DeviceNet Association). -SDS :Smart Distribución System desarrollado por Honeywell La página del Fieldbus Forum es una visita obligada para profundizar en las distintas soluciones existentes. Funcionamiento del CAN: Centrándome en lo que es el CAN, como se ha referido anteriormente, solo le compete el nivel físico y el de enlace, sin embargo no define el tipo de acceso al medio, por lo que pueden encontrarse por ejemplo, sistemas que utilizan el estándar RS-485 modificado, y otros que utilizan circuitos específicamente diseñados.


Una de sus características principales es que cada mensaje no contiene una dirección de destino ni de partida, por el contrario, todos los nodos son receptores, pero un identificador en la cabecera del mensaje indica a un nodo si es relevante para él o no. La diferencia entre dirección e identificador parece un tanto arbitraria, pero se hace patente si consideramos que el identificador es utilizado también como arbitrador de acceso. Utiliza para ello dos mecanismos, la arbitración de prioridad a nivel de BIT y la detección de colisión por acceso múltiple (CSMA/CD) . En el bus se define un estado dominante (estado lógico 0) y otro recesivo (e. lógico 1) y un estado dominante fuerza el estado del bus sobre uno recesivo. De esta forma si dos dispositivos comienzan a transmitir simultáneamente un mensaje, aquel que antes tenga un estado dominante en su identificador, es decir un número mas bajo, forzará su mensaje a nivel de BIT frente al otro dispositivo, que al estar también recibiendo interpreta un error y elude la transmisión.

A diferencia de otros procedimientos, de esta forma no hay destrucción de paquetes ni demoras por esperas de turno, lo cual aumenta su eficiencia limitando la velocidad exclusivamente a la capacidad del bus. A estos dos mecanismos hay que añadir la codificación NRZ (Non Return to Zero) asegurando mensajes compactos con alta inmunidad al ruido. Bajo el punto de vista físico, el bus esta formado por un par trenzado, apantallado ó no, y los circuitos de interfase con el deben garantizar el funcionamiento incluso si existe un corto en alguno de ellos con el potencial de tierra o de alimentación o en el caso de que exista una discontinuidad en uno de los hilos.

Para cumplir la norma ISO, los dispositivos deben ser capaces de trabajar a 1 Mbit/s. para distancias de hasta 40 mts para luego descender linealmente hasta 125 Kbits/s. en distancias de hasta 500 mts.
El número máximo de nodos esta limitado en la práctica por los drivers de los buses, pero suele ser normal un tope de 32, 64 y hasta 100 nodos. Formato de mensajes llegados a este punto hay que referir la existencia de dos versiones del protocolo CAN, la estándar (2.0A) y la extendida (2.0B), ligada ésta última a la necesidad de mayores prestaciones.
La diferencia esencial estriba en que la versión estándar utiliza identificadores de 11 bits, mientras que la extendida utiliza identificadores de 11 y 29 bits.

Los controladores diseñados para la V.: 2.0A solo pueden manejar mensajes estándar, mientras que los diseñados para la v .:2.0B pueden manejar ambos. La trama de un mensaje CAN de 2.0A contiene los siguientes campos: StartOfFrame(SOF): comienzo de trama ArbitrationField:contiene el identificador del mensaje y un BIT especial, el RemoteTransmmissionRequest (RTR):para diferenciar una trama de datos y una trama de solicitud de datos ControlField:Campo de control de 6 bits, conteniendo dos bits dominantes (r0 y r1)reservados para uso futuro y cuatro bits que definen la longitud del Campo de datos (DLC).
DataField: Campo datos de 0 a 8 bytes.
CRC: un check de 15 bits y un BIT final recesivo.
ACK: dos bits, el primero es el Slot BIT, que se transmite como recesivo, pero es forzado a dominante por cualquier nodo que reciba el mensaje.
El segundo es el un BIT recesivo utilizado como delimitador. EndOfFrame: fin de trama, consistente en 7 bits recesivos. INTermisionField: son tres bits recesivos a modo de tierra de nadie, tras los cuales el bus se considera libre. La trama de un mensaje 2.0B se considera una extensión del 2.0A con la siguientes diferencias: -El identificador es de 29 bits, conteniendo dos sub-campos, el campo de arbitración que por compatibilidad es de 11 bits, y el de extensión, de 18 bits. -Aparece un BIT de identificador de extensión (IDE) que discrimina ambos formatos. -En el campo de arbitración se añade un BIT denominado SubstituteRemoteRequest (SRR) que se transmite como recesivo para asegurar que en caso de arbitración entre un mensaje estándar y uno extendido, con el mismo identificador, tenga prioridad el estándar.

La aparición del formato extendido, da lugar a dos tipos de controladores de la V.:2.0A, aquellos que emiten un error al recibir mensajes en formato extendido y aquellos que reconocerán la recepción del mensaje pero simplemente los ignoran,. A estos últimos se les denomina 2.0B pasivos, y pueden coexistir con controladores 2.0A en el mismo bus. Implementaciones: Los dispositivos CAN -normalmente puede identificarse el término con un circuito integrado-, están generalmente formados por dos bloques, uno de ellos es el controlador del protocolo propiamente dicho y el segundo es una memoria bufer separado en dos segmentos, uno de control y otro de datos a los que accede normalmente un microcontrolador. En el segmento de control el microcontrolador escribe comandos y lee registros de estado y en el de datos obtiene el contenido del mensaje. El tipo de buffer empleado da lugar a dos implementaciones diferentes.
En la primera, el Basic CAN, el dispositivo suele tener un buffer doble de recepción y uno de transmisión así como registros de máscara que permiten filtrar identificadores en el rango de los 8 bits mas significativos, tras lo cual se interrumpe al microcontrolador asociado, que debe dejar otras tareas para gestionar la llegada de cada mensaje.

En la segunda, los dispositivos Full CAN, tienen capacidad para gestionar varios objetos CAN y otras funciones adicionales como por ejemplo filtrado de mensajes, liberando la carga sobre el microcontrolador. Los objetos CAN están compuestos por un identificador, la longitud de los datos y los datos en si; los circuitos que soportan FullCAN intercambian la información con el microcontrolador a través de una RAM. Existe una tercera solución, los SLIO, son circuitos simples que no requieren la intervención de un microcontrolador, pero deben ser administrados por un bus-master. Su evolución es efímera y no parece muy larga su existencia.

Es posible encontrar un listado de circuitos CAN en las páginas de http://www.can-cia.de CiA y Kvaser El Nivel de Aplicación, los HLP (HighLevelProtocol) El protocolo CAN como hasta aquí lo hemos entendido, es decir refiriéndonos a los niveles físico y de enlace, se ha mostrado como un protocolo estándar, fiable y económico para el intercambio de información entre dispositivos, pero deja abiertos aspectos tan importantes como la asignación de identificadores al criterio de los desarrolladores que lo vayan a utilizar. De esta forma, aparecen varias soluciones para el nivel de Aplicación (denominados HLP) que difieren ampliamente entre si. Las principales tareas que debe realizar un HLP son: - distribución de identificadores a los mensajes - inicialización de conexiones - mecanismos de intercambio para bloques de datos mayores de 8 bits - gestión del estado de la red - gestión de los "modelos" asignados a los distintos dispositivos (Profiles) Es necesario distinguir dos campos de aplicación diferentes, que han orientado el desarrollo de los HLP: por un lado su utilización en automoción y por otro en aplicaciones industriales, en las cuales nos centraremos. En el primer caso, las dos especificaciones mas representativas son OSEK/VDX, cuya aplicación parece extenderse en turismos y SAE J1939, de amplia aceptación en EE.UU. en vehículos pesados. Para aplicaciones industriales, las tres especificaciones más utilizadas son CANopen, promovida por CiA (CAN in Automation),DeviceNet desarrollado por Allen-Bradley y gestionado por la ODVA y SDS (SmartDistributionSistem), desarrollado por Honeywell. El primero es de amplia aceptación en Europa, mientras que los otros dos lo son en EE.UU.
Una amplia discusión sobre los tres protocolos puede encontrarse en un articulo del Prof. Dr.-Ing K.Etschberger en las paginas de STZP.

Sitios de especial interés en Internet Además de los que ya aparecen en el texto, cabe mencionar los siguientes: -Kvaser: Desarrollan productos para CAN y específicamente, una solución HLP propia, el CAN-Kingdom -P. Personal de Mike Schofield: Contiene gran cantidad de información sobre CAN -CAN Solutions Directory Listado de recursos CAN -Lista de correos conocida -IPE_CAN-home

 

Atención: Esta página se distribuye tal cual con fines didácticos. El autor no se hace responsable de las consecuencias que el uso, indebido o no, de la información que contiene, pueda producir.

 

 Dinastia Soft © Copyright 1997-2002 Todos los derechos reservados