Protocolo de Redes CAN

Proyecto 4: Proyecto de investigación
Tema: Protocolo de Redes CAN (Controller Area Network)
ALONSO, Dionisio Enrique
e-mail: [email protected]
CARRASCOSA, Rafael
e-mail: [email protected]
OLIVA BRUNO, Horacio Alberto
e-mail: [email protected]
Junio 2005
Índice
1. Introduccion
2
2. Un poquito de Historia
3
2.1.
Línea cronológica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3. Especicacion light
3
4
3.1.
Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
3.2.
Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
3.3.
3.2.1.
DATA FRAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
3.2.2.
REMOTE FRAME
4
3.2.3.
ERROR FRAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3.2.4.
OVERLOAD FRAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
Errores y estados de error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4. Capas de aplicación
4.0.1.
5
CAN Kingdom: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
4.1.
CANOpen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
4.2.
J1939
7
4.3.
DeviceNEt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
4.4.
Comparaciones
7
4.5.
Comparación entre SDS, DeviceNet and CAN Kingdom
. . . . . . . . . . . . . . . . . . .
7
4.6.
Diferencias entre CAN Kingdom y CANOpen . . . . . . . . . . . . . . . . . . . . . . . . .
8
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5. Campo de aplicación
8
5.1.
Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.
CAN en el control de motores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
5.3.
CAN en vehículos no destinados al transporte de pasajeros
. . . . . . . . . . . . . . . . .
8
5.4.
CAN en aplicaciones marítimas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
5.5.
CAN redes de tecnología de aviación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
5.6.
CAN en producción y control industrial
9
5.7.
CAN en ascensores y puertas automáticas . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
5.8.
CAN en equipamiento médico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
6. Ejemplo de aplicación
8
10
1
1. Introduccion
CAN es un acronimo que denota Controller Area Network, se trata de de un protocolo de capa de
enlace de datos para redes en la cuales la conabilidad y el entregar a tiempo un frame es mucho mas
importante que el ancho de banda. Las redes que funcionan con CAN pueden trabajar hasta un ancho
de banda maximo de 1 Mbit/seg con longitudes de cable de no mas de 40 Mts. De ese ancho de banda
para abajo la longitud del cable puede aumentar, por ejemplo, a 250 Kbit/seg la maxima longitud de
cable es de 250 Mts. Es usado principalmete para hacer redes en ambientes muy hostiles para equipos
electricos o con altas posibilidades de fallas criticas donde se destaca por ser muy robusto y seguro. Desde
la publicacion original de su especicacion por Bosch se han hecho muchos otras estandarizaciones sobre
los aspectos que no se especicaron en la publicacion original, como por ejemplo, la capa de aplicacion y
la capa sica.
2
2. Un poquito de Historia
Robert Bosch introdujo el sistema de bus serial CAN en el congreso de la Sociedad de Ingenieros
Automotores (SAE) en 1986. Fue llamado Automotive Serial Controller Area Network´´ porque los
sistemas CAN fueron desarrollados para la industria automotriz. Llegó a ser rápidamente obvio, que el
protocolo se comportaría extremadamente bien en una gran variedad de sistemas de aplicaciones. En
1990 la tecnología CAN fue introducida en maquinas textiles, y hoy en día esta industria realiza un gran
uso de los sistemas CAN. Los chips CAN se pueden encontrar en sistemas de elevación de edicios altos,
naves de todo tipo, trenes, y aviones, en máquinas de rayos X y en otros equipamientos médicos, etc. En
estos días la mayoría de los autos desarrollados en Europa tienen por lo menos un sistema CAN en su
interior, y CAN se ha convertido en un Standard dentro de los sistemas de comunicación de los vehículos.
Los líderes de industria cuentan con un crecimiento constante para los sistemas CAN en todos los tipos
de equipamiento y maquinaria.
Intel entregó el primer chip CAN en 1987, y los semiconductores Phillips respondieron con un chip
CAN propio poco después de eso. Motorota y NEC lo siguieron; hoy en día unos quince vendedores de
semiconductores construyen chips CAN. La organización de estándares internacionales (ISO), localizada
en Geneva, Suiza, es una red de institutos de estándares que a partir de 147 países dene los estándares
para la cooperación internacional en tecnología. ISO publico el estándar 11898 en noviembre de 1993
para denir CAN en el uso de la industria en general. El grupo de usuarios de CAN en Automatización
fue fundado en marzo de 1992. Ahora en el vigésimo año, el protocolo CAN todavía se está realzando.
A principios del 2000 un destacamento de fuerzas de la ISO denió un protocolo para la planicación
de transmisión de mensajes CAN llamados Tiempo Accionado CAN (TTCAN). El grupo de usuarios de
CAN estima que la extensión TTCAN le permitirá a la red de área controlada (CAN) continuar su rápido
crecimiento por otros diez a quince años dentro de una gran variedad de sistemas de aplicaciones. En
los próximos años, los sistemas CAN pueden estar funcionando en cada tipo de maquina o proceso que
exista.
2.1.
Línea cronológica
1983 Comienzo del proyecto interno de Bosch para el desarrollo dentro de una red vehicular.
1986 Introducción ocial del protocolo CAN.
1987 El primer chip CAN de Intel y Semiconductores Phillips.
1991 Especicacion de Can 2.0 publicada por Bosch.
1991 Protocolo de Capa Alta CAN Kingdom CAN-based introducido por Kvaser.
1992 Establecimiento de usuarios internacionales y grupo de manufactureros de CAN en Automatización.
1992 Protocolo de Capa de Aplicación Can publicado por CiA.
1992 Primero automoviles de Mercedez-Benz usando red CAN.
1993 Publicacion del estándar ISO 11898.
1994 Primera conferencia internacional de CAN (iCC) organizada por CiA.
1994 Introduccion al protocolo de Dispositivo de Red por Allen-Bradley.
1995 Publicacion de La enmienda de la ISO 11898 (formato extendido del marco).
1995 Protocolo CANOpen publicado por CiA.
2000 Desarrollo del protocolo de comunicación tiempo-accionado para CAN (TTCAN).
3
3. Especicacion light
3.1.
Generalidades
CAN es basicamente una red de comunicacion serial multimaster con CSMA/CD que usa la tecnica
de Binary Countdown para arbitrar el uso del canal. Esta basado fuertemente en el modelo ISO/OSI
de la capa de enlace de datos. La especicacion no dice mucho sobre la capa sica, solo que debe tener
la capacidad de enviar bits dominantes y rececivos, es decir si se envian simultaneamente dos bits
distintos(ie, 0 y 1) por el mismo canal entonces solo uno de ellos prevalece(su señal opaca al otro bit) y se
le llama bit dominante. Al que no es dominante se le llama rececivo. Tampoco se dice mucho de la capa
de LLC sino que se concentra en la capa MAC.
A la secuencia de bits usada para hacer la arbitración se le llama indenticador, este no es exactamente una direccion MAC(como en Binary Countdown) sino que es un numero que identica al contenido
del frame, por ejemplo, si un nodo envia un frame por el canal, este(el frame) no lleva en ninguno de
sus campos el nodo destino sino que todos los otros nodos escuchan el canal y en base al identicador
podrian o no aceptar el frame y pasarlo a las capas superiores. Entoces, dependiendo del identicador
varios nodos podrian aceptar el mismo frame.
Estos indenticadores deben ser asignados por el usuario de CAN segun lo crea conveniente, la unica
regla que deben cumplir es que dos nodos no deben transmitir simultaneamente con el mismo identicador
porque de hacerlo la arbitración del canal fallaria. Los identicadores tienen 11 bits de longitud en CAN
estandart y 29 bits en la version extendida.
Para la codicación el la capa sica se usa bit stung de forma que no pueda haber mas de 5 bits
identicos consecutivos, es decir, cuando un transmisor detecta 5 bits identicos consecutivos le stu ea
un sexto bit con el valor contrario al de los 5 anteriores. El destu eo se realiza automaticamente en
el lado del receptor. Con contadas excepciones se saltea la regla del stu eo, como por ejemplo para
deliveradamente provocar un error en los otros receptores. Estos ultimo sera explicado mas adelante.
3.2.
Frames
Existen cuatro tipos de frames: DATA, REMOTE, ERROR y OVERLOAD.
DATA: El tipico frame de datos multiproposito.
REMOTE: Se usa para pedir la transmicion de un DATA frame con el mismo numero de identicacion que el REMOTE.
ERROR: Se envia cuando un nodo(cualquiera) detecta un error en la transmicion.
OVERLOAD: Se usa para demorar la transmicion siguiente luego de un DATA o un REMOTE con
exito.
3.2.1. DATA FRAME
Un DATA frame puede llevar hasta 8 bytes de datos de usuario y es conrmado(acknowlodge) durante
su transmicion aprovechando un espacio dejado con ese proposito en el frame, es decir, si un nodo recivio
con exito el frame entoces escribe un dominante en ese espacio, si lo no lo recivio con exito escribe un
recesivo. Si ninguno hace un ACK positivo el transmisor va a notar que ese bit quedo en recesivo y va
a enviar un ERROR frame. Este frame lleva un CRC checksum para vericar la correcta recepcion del
mensaje.
3.2.2. REMOTE FRAME
Estos frames tienen una estructura similar a la de un DATA FRAME pero no se les esta permitido
llevar una carga util. Sirve para pedir la transmicion de algun dato con el mismo identicador que tiene el
remote frame enviado. Este frame tambien lleva un CRC checksum para vericar su correcta recepcion.
4
3.2.3. ERROR FRAME
Cuando algun nodo detecta una condicion de error transmite inmediatamente o con una demora de
unos pocos bits un ERROR FRAME para indicarlo. Estos frames tienen una forma ilegal que viola el
bit stung que deberian tener los mensajes y de esta forma el error es detectado por los otros nodos
que a su vez mandan sus propios ERROR FRAME por que encontraron un error en el stung, esto
desencadena una lluvia de mensajes de error que sirve para que todos noten que algo salio mal.
3.2.4. OVERLOAD FRAME
Este frame tiene una forma muy similar a la de ERROR FRAME y se usa para demorar una transmiccion porque un nodo necesita mas tiempo. La demora que se obtiene es la duracion de la transmicion
de este frame. Solo puede haber dos de estos frames consecutivos limitando de esa forma la cantidad de
tiempo maximo que el canal pasa incativo.
3.3.
Errores y estados de error
Existen varias razones por las cuales un nodo puede detectar un error, todas ellas estan enumeradas
en la especicacion de CAN y no las nombraremos aqui a todas. Lo que si nombraremos es qué hace un
nodo cuando detecta muchos errores consecutivos.
Todos los nodos llevan dos contadores, uno para los errores de transmicion y otro para los errores de
recepcion. Estos contadores se van aumentando a medida que el nodo detecta errores en la transmicion
o la recepcion y decrementan cuando el nodo tiene exito en enviar o recivir mensajes. El proposito de
estos contadores es impedir que un nodo moleste la recepcion de mensajes a los otros nodos, por ejemplo,
supongamos que un nodo tiene problemas localmente, o sea, que recive mal los mensajes por algun
motivo(se lo olvidaron cerca de la estufa), entoces siempre esta mandando ERROR FRAMEs porque
no entiende nada, y en consecuencia, los demas nodos tampoco entienden nada. Usando los contadores,
eventualmente ese nodo problematico se da cuenta que es un problema para los demas y entra en un modo
pasivo, en este modo el nodo puede detectar errores pero no puede hacercelos saber a los demas, de esa
forma el resto puede escuchar. Si el nodo mejora su condicion patologica y los contadores disminullen
entonces vuelve a lo que se llama el modo activo(el estado original) y puede volver a hacer todo lo
que hacia antes. Si en cambio su condicion empeora, los contadores siguen subiendo hasta que en algun
punto el nodo tira la toalla y se desconecta del bus ignorando todo lo que pasa en el hasta que alguien
le diga explicitamente que regrese mediante un frame con un identicador especial para este proposito.
Este ultimo estado se llama bus o .
Esto logra un comportamiento muy robusto por parte de los nodos que implementan CAN, puesto
que son capaces de decidir por si mismos cuando la comunicacion es imposible y auto-desactivarse.
4. Capas de aplicación
El estándar CAN dene el hardware (la capa física´´ - hay varios) y la comunicación sobre un
nivel básico (la capa de trasmisión de datos´´). El protocolo CAN en sí mismo apenas especica cómo
transportar los paquetes pequeños de datos del punto A al punto B usando un medio de comunicaciones
compartido. No contiene nada en asuntos tales como control de ujo, transporte de los datos más grandes
que puede caber en un mensaje de 8-bytes, direcciones del nodo, el establecimiento de la comunicación,
etc.
Para manejar la comunicación dentro de un sistema, se requiere un protocolo de capa de alto nivel
(HLP). El término HLP se deriva del modelo OSI y de sus siete capas. El HLP especica típicamente
cosas como:
El comportamiento de la puesta a punto.
Cómo distribuir identicadores de mensaje entre diversos nodos en un sistema.
Cómo traducir el contenido de datos del frame.
5
Estado que viaja dentro del sistema.
Las puestas en práctica de hardware de CAN cubren las dos capas más bajas del modelo de referencia
OSI mientras que diversas soluciones de software (protocolos de capa de alto nivel) cubren las capas
de transporte, presentacion y aplicacion. Los modelos se utilizan para entender la comunicación, y para
describir objetos de comunicación así como servicios en estos objetos. Los modelos acordados son comunes
en tecnología de comunicación. El modelo de ISO/OSI (interconexión internacional de los sistemas de
la estandardización Organización/Abierta) se utiliza extensamente para describir la funcionalidad de los
sistemas de comunicación en base de un acercamiento jerárquico.
La funcionalidad proporcionada por CAN es similar a las letras latinas en la comunicación humana.
Es la base para escribir una lengua, pero no es bastante a comenzar con la comunicación eciente. Para
especicar una lengua se necesita además una acción de palabras así como la gramática para construir
oraciones. Los usuarios de CAN pueden especicar su propia lengua basada en CAN, (CAN-based) en
términos técnicos que esto es un protocolo de la capa de aplicacion. O el usuario decide utilizar un
protocolo estandardizado de la capa de aplicación de CAN-based. En el mundo de CAN hay diversos
protocolos de capa estandardizados de uso. Algunos son muy especícos y relacionados. Los ejemplos de
protocolos de capa de altos nivel CAN-based son CANopen, DeviceNet, CANKingdom, J1939.
4.0.1. CAN Kingdom:
Este protocolo libera el maximo poder de CAN en su totalidad. Le otorga al diseador del sistema un
grado de libertad considerable para que pueda crear su propio sistema. No esta limitado por el protocolo
multi-master CSMA/AMP de CAN pero puede crear sistemas virtuales usando cualquier tipo de manejo
de bus y topologia. CAn Kingdom otorga la posibilidad a los diseadores de modulos de planicar modulos
generales sin saber previamente en que tipo de sistemas van a a ser utilizados y en que protocolo de capa
de alto nivel tendra. como el diseador del sistema puede permitir solo modulos especicos para ser usados
dentro de su propio sistema, la ventaja de un sistema abierto puede ser combinada con la seguridad de
un sistema con una nalidad especica.
Puesto que el identicador en un mensaje de CAN se identica no sólo el mensaje sino también
controla el acceso al bus,un factor dominante es la enumeración de los mensajes. Otro factor importante
es considerar que la estructura de datos en la zona de informaciones es igual en los módulos que transmiten
y de recepciones. Adoptando algunas reglas simples del diseño estos factores pueden ser completamente
controlados y comunicación optimizados para cualquier sistema. Esto se hace durante una fase corta de
la disposición en la inicialización del sistema.
4.1.
CANOpen
CANopen es un protocolo de capa de alto nivel CAN-based. Fue desarrollado como red encajada
estandardizada con capacidades altamente exibles de conguración. CANopen fue diseñado para redes
movimiento-orientadas de control de máquina, tales como sistemas de tramitación.
CANopen fue pre-desarrollado en un proyecto del Esprit bajo presidencia de Bosch. En 1995, la
especicación de CANopen fue entregada a CAN en el grupo internacional de usuarios y fabricantes de
automatización (Cia). Originalmente, el perl de la comunicación de CANopen fue basado en el protocolo
de la capa de uso de la CAN (CAL). La versión 4 de CANopen (Cia DS 301) se estandardiza como EN
50325-4. Las especicaciones de CANopen cubren la capa de uso y el perl de comunicación (Cia DS
301), tambien como un marco para los dispositivos programables (Cia 302), las recomendaciones para los
cables y los conectadores (Cia 303-1) y las unidades del SI y las representaciones del prejo (Cia 303-2).
La capa de aplicacion así como los perles de CAN-based se pone en ejecucio'n por software.
Los perles estandardizados (los perles del dispositivo, del interfaz y del uso) desarrollados por CiA,
simplican el trabajo del diseñador de sistema de integrar un sistema de red CANopen. Los dispositivos,
las herramientas, y los apilados disponibles del protocolo están extensamente disponibles en los precios
razonables. Para diseñadores de sistema, es muy importante la reutilizacion de software.Esto requiere no
solamente compatibilidad de comunicación, sino también interoperabilidad y la capacidad de intercambio
de dispositivos. En los perles del dispositivo y de la interfaz de CANopen, los objetos denidos del uso
6
existen para alcanzar la capacidad de intercambio de los dispositivos de CANopen. CANopen está exible
y bastante abierto para permitir funcionalidad fabricante-especi'ca en los dispositivos, que se pueden
agregar a la funcionalidad genérica descrita en los perles.
Proporciona los objetos estandardizados de comunicación para datos en tiempo real (objetos de proceso de datos, PDO), los datos de la conguración (objetos de los datos de servicio, SDO), y las funciones
especiales (mensaje del grupo fecha/hora, de la sinc., y mensaje de emergencia) así como los datos de
dirección de red (mensaje del Cargador-para arriba, mensaje de NMT, y control de error).
4.2.
J1939
A principios de los 90, se comenzo el desarrollo de un perl del uso de CAN-based para la comunicación
del interior del vehiculo en camiones. En 1998 el SAE publico el sistema J1939 de especicaciones del
SAE A, B, y C . Una red J1939 conecta las unidades de control electrónico (el ECU) dentro de un sistema
de camion y del acoplado. La especicación J1939 - con su motor, transmisión, y deniciones del mensaje
del freno - se dedica a los usos del motor diesel. Se supone para substituir las redes J1587/J1708.
Otras industrias adoptaron las funciones generales de comunicación J1939, en detalle las deniciones
del protocolo J1939/21 y J1939/31 - se requieren para cualquier sistema J1939-compatible. Agregaron
otras capas físicas y denieron otros parámetros de uso. La ISO estandardizó la comunicación del camion
y del acoplado J1939-based (ISO 11992) y la comunicación J1939-based para los vehículos de agricultura
y de silvicultura (ISO 11783). El NMEA especicó la comunicación J1939-based para los sistemas de
navegación en el uso de la marinas (NMEA 2000). Una razón de la incorporación de las especicaciones
J1939 en otras areas es el hecho que hace sentido de reinventar los servicios básicos de la comunicación.
La Cia ha desarrollado varios perles de interfaz de CANopen para las redes de J1939-based (Cia DSP
413). Las entradas se denen según ISO 11992-2 y ISO 11992-3. Además, la familia del perl de CANopen
incluye un marco para las entradas según SAE J1939/71.
4.3.
DeviceNEt
DeviceNet se utiliza principalmente en entornos industriales, en detalle, en la automatización de
fábrica. Es un puente de comunicaciones barato para conectar los dispositivos industriales (tales como
interruptores de límite, los sensores fotoeléctricos, múltiples de la válvula, arrancadores del motor, sensores
de proceso, lectores de clave de barras, conductoes de frecuencia variable, las exhibiciones del panel
y los interfaces del operador) con una red y para eliminar el cableado duro costoso. La conectividad
directa proporciona la comunicación mejorada entre los dispositivos así como el diagnóstico importante
del dispositivo-nivel poco accesible o los interfaces atados con alambre duro directo disponibles de I/O.
DeviceNet es una solución simple del establecimiento de una red que reduce el coste y la época
de atar con alambre y de instalar los dispositivos de la automatización de fábrica, mientras que proporciona capacidad de intercambio çomoçomponentes de vendedores múltiples. Las especicaciones de
DeviceNet han sido desarrolladas por la asociación abierta del vendedor de DeviceNet (ODVA) e internacionalmente se estandardizan. Los compradores de la especicación de DeviceNet reciben una licencia
ilimitada, derecho-libre de desarrollar los productos de DeviceNet.
4.4.
Comparaciones
A continuación se mencionaran algunas características y comparaciones que merecen su presencia.
4.5.
Comparación entre SDS, DeviceNet and CAN Kingdom
El SDS y DeviceNet han especicado los perles para diversos dispositivos. Se necesita esto pues no
se dene ningún nodo responsable del sistema en cualquier protocolo. En CAN Kingdom hay siempre
un nodo responsable del sistema, por lo menos cuando el sistema se comienza por primera vez. En vez
de especicar cómo los módulos deben nalmente ser diseñados, el CAN Kingdom especica cómo los
módulos se pueden ajustar a las necesidades de los sistemas reales, por ejemplo, por los perles para los
datos del sistema como el índice binario, el número y las prioridades, etc del nodo.
7
4.6.
Diferencias entre CAN Kingdom y CANOpen
CAN Open esta basado en CAL. CAN Kingdom y CAL ambos tratan de resolver sus problemas con
CAN, para asignarle el identicador correcto en el mensaje correcto dentro de un sistema, donde cada
mensaje adquiere la prioridad debida. CAL esta basado en el modelo OSI, CAN Kingdom no. El objetivo
principal con el modeo OSI es conectar a dos clientes el uno al otro y ver que pueden intercambiar
información. El sistema sirve los nodos en un sistema. Entonces cada nodo (cliente) tiene que tener
información del peer sobre cual comunicarse. Cada nodo en un sistema abierto de CAL o CAN tiene que
tener absolutamente mucho conocimiento sobre el sistema. Los nodos solicitan servicios del sistema.
En CAN Kingdom es de la otra manera como se realiza. Los nodos no se asumen para saber cualquier
cosa sobre el sistema. El sistema solicita servicios apropiados de cada nodo. Es por es que las implementaciones de CAN Kingdom son generalmente más pequeñas que las de CANOpen puestas en práctica.
CAN Kingdom es desarrollado para sistemas de máquinas. El sistema es superior sobre los nodos. En
un sistema de máquina, un nodo no tiene ninguna voluntad por si solo. Se coloca en un sistema para
realizar tareas especícas según una voluntad del diseñador de sistema. Se analiza cada situación que
ocurrirá y la máquina se diseña para comportarse de maneras especícas cuando ocurren las situaciones
especícas.
CANOpen se basa en el modelo OSI que se desarrolla para los sistemas de ocina y de telecomunicación
donde el sistema proporcionará los servicios para los nodos´´ (los clientes) que tienen requisitos que
cambian muy a menudo y no puedan ser previstos.
Por lo tanto: CAN Kingdom se diseña solamente para el control de máquina con CAN para dar la
posibilidad que un diseñador de sistema consiga funcionamiento máximo y dependencia por parte de los
diseñadores del nodos para con sistemas especícos.
CANOpen se basa en CAL. CAL se desarrolla en opiniones y reglas comúnmente aceptadas sobre el
establecimiento de una red. Sin embargo, estas opiniones y reglas se derivan de teorías y de experiencias
de redes de comunicaciones para intercambiar la información, no para el control de la máquina.
5. Campo de aplicación
5.1.
Introducción
Muchas industrias han adoptado el
bus estandar CAN y han ganado mucha conabilidad y exibilidad.
Para algunas aplicaciones, el costo y velocidad para distribuir o recongurar una red de comunicaciones
es crítico. Un
bus CAN puede ser situado y luego se le pueden añadir más equipamiento fácilmente gracias
Plug & Play con Protocolos de una Capa Superior.
a su capasidad de
5.2.
CAN en el control de motores
El protocolo CAN es utilizado actualmente en la mayoría de los autos europeos para el control del
motor y el equipamiento electrónico. Los fabricantes de automóviles estadounidenses y asiáticos también
implementan el protocolo.
5.3.
CAN en vehículos no destinados al transporte de pasajeros
CAN es la solución natural para vehículos equipados con instrumentos tales como escaleras o válvulas
en camiones de bomberos, sistemas de control de refrigeración, o conexiones de vagones. En los muchos
ejemplos de vehículos de transporte, el
bus
de comunicaciones es utilizado por el fabricante y por los
múltiples vendedores que proveen equipamiento para la plataforma del vehículo. Eligiendo un estandar
como CAN y protocolos de más alto nivel, son necesarios para asegurar la inter-operabilidad de las
partes. Más aún, si los vendedores desarrolan en conjunto un perl como por ejemplo el Protocolo Dedicado
CANopen, la construcción en línea de ensamble, el testeo y mantenimiento se verían altamente
CANopen y J1839 son ejemplo de protocolos de alto nivel utilizados en aplicaciones de
simplicados.
este tipo.
8
El mismo Razonamiento es aplicable a la construcción de maquinaria de trabajo como pequeños
camiones o ascensores de carga, como así también equipo de agricultura.
Veamos el siguiente caso de estudio: Los fabricantes de un vehículo eléctrico, como por ejemplo el
elevadores de carga, carritos de aeropuerto, o carritos de golf, todos ellos utilizan baterías muy caras,
para funcionar. Por otro lado los fabricantes de cargadores de baterías, tienen que proveer baterías que
carguen rápidamente y de forma segura todos estos tipos de baterías. Deeniendo en conjunto el perl
de la batería y el cargador de baterías
CANopen,
ellos se dan a sí mismos el correcto sistema para
intercambiar las características de carga, monitorear las cargas, y almacenar el estado de las cargas.
Muchas pequeñas industrias contribuyen con estos sistemas, la mayoría de ellas, sin el capital suciente
como para afrontar el costo de especialistas en
CAN HW/SW en el lugar de trabajo. En este caso es
importante que la compañia de semiconductores ofrezca el hardware y un software de protocolo de alto
nivel, más soporte de ayuda de algún otro tipo.
5.4.
CAN en aplicaciones marítimas
CAN es utilizado para conectar diversos subsistemas en navíos. Las características del sistema son de
algún modo parecidas a las de los sistemas de automatización en las fábricas. Algunos sistemas críticos
necesitan de una capa extra más segura basada en redundancia. Esto es otro ejemplo de uso de los ya
mencionados
CANopen y J1839.
Una segunda categoría para la aplicación marítima, es la industria pezquera, como así también la
navegación acionada. En este tipo de aplicaciones podemos encontrar GPS's, radares, sonares, rastreadores de peces, paneles de control, pantallas más una inmensa variedad de sensores de seguridad.
Esto representa un gran volumen de negocios y de feroz competencia, especialmente en lugares donde
la navegación acionada de recreación es muy popular. Todos los equipos anteriormente mencionados,
requieren controladores CAN con bajo consumo, una alta capasidad de reprogramación de micro-partes
digitales y analógicas, y por sobre todo, un costo bajo.
5.5.
CAN redes de tecnología de aviación
Compañias como Airbus, Boeing y la NASA usan CAN como red troncal para la medición del estado
de los sensores y sistemas de navegación. Componentes de grado industrial normal pueden ser usados en
esto tipos de sistemas.
5.6.
CAN en producción y control industrial
Este es el núcleo de las aplicaciones de CAN en la industria no automotriz. Los equipamientos conectados a un
bus industrial son varios. Por listar algunos de ellos: Switches, sensores de proximidad, sensores
fotoeléctricos, drives de motores (como por ejemplo las cintas transportadoras de equipaje), motores de
robots, brazos mecánicos, controles de movimiento, controles de válbulas, Controles Lógicos Programables
(PLC), lectores de códigos de barras, pantallas de Display, paneles de control y por supuesto PC's.
Como muchos dispositivos diferentes de muchos vendedores diferentes van a ser conectados juntos en
el mismo
bus, es imperativo que todos ellos utilicen el mismos software de alto nivel, ya sea directamente
o a través de un convertidor de protocolo. Es por ello que empresas que utilizan el protocolo CAN tanto
en Europa como en Estados Unidos, han logrado gran fama e importancia gracias a la interoperabilidad
de sus productos.
En el sistema base de fabricación, el PLC controlando el sistema crítico, y el dispositivo controlando
la parte del equipamiento que puede herir a algún operario, van a necesitar una capa extra de seguridad
encima del protocolo de alto nivel. y los controladores CAN, tienen el soporte necesario para este tipo de
redundancia.
5.7.
CAN en ascensores y puertas automáticas
Los fabricantes de ascensores, como los fabricantes de puertas eléctricas, tienen que tabajar en conjunto
para desarrollar un perl de CANopen especíco para sus aplicaciones. Esto representa un inmenso
9
volumen de aplicaciones. Por ejemplo, una construcción con 2 ascensores va a tener aproximadamente 10
nodos CAN (2 paneles de botones + 2 paneles de display's por piso + 1 panel de botones y 1 panel de
display en cada ascensor + 40 sensores de proximidad + contol del motor + un panel de mantenimiento).
Los controles usados en en estos sistemas, necesitarán correr un paquete de protocolo full más ofrecer
interacción digital y la posibilidad de entrada analógica y una salida por PWM.
Las puertas eléctricas en la entrada del edicio, como así tambien las de los ascensores van a controlar
motores que necesitan de una signicativa cantidad de
caballos de fuerza MIPS y memoria (códigos +
datos) encima del protocolo de alto nivel. También van a requerir una entrada analógica y un control
PWM de salida más switches de control digitales. Todo esto puede estar rondando cerca de 50 nodos
CAN extra.
5.8.
CAN en equipamiento médico
CAN ha sido usado en redes empotradas en dispositivos médicos desde hace ya varios años. La
automatización en laboratorios no es muy diferente a la automatización en las fábricas; por ello, se dió
un paso signicativo, cuando los fabricantes, repenzaron su relación con las redes, como una red dentro
de la sala de operaciones, en la sala de partos, en la sala de pacientes, o inclusive en sus camas.
Las soluciones propietarias de altos mantenimientos de alto costo existentes que usaban estándares
en desuso como LON fueron comparadas con CAN. La combinación de la lata conabilidad de CAN, los
benecios de un estandar abierto como CANopen y la tolerancia a fallos del
transceiver CAN, pusieron
a CAN encima de la lista de nuevas posibles soluciones.
A esta altura, CAN está situado como el lider en camas de hospitales conectando los paneles de control
y los varios motores. Una cama de hospital de nueva generación, incluye de 5 a 10 nodos CAN.
La lente de una máquina de rayos X, su generador y la mesa del paciente, utilizan CAN.
CAN con CANopen, está dispuesto en salas de operaciones como resultado de SIOS: Siemens Integrated OR System.
6. Ejemplo de aplicación
Un ejemplo de uso de este tipo de redes, se puede ver muy fácilmente en un automovil, donde se
encuentra un procesador que controla montones de dispositivos con redes CAN, aquellos como ventanillas
eléctricas, el aire acondicionado, freno (ABS) y acelerador, entre otros, de manera que todas estas partes
controladas entre sí puedan funcionar sin causar interferencia unas con otras; a pesar de controlar partes
de un automovil que podrían resultar vitales si no fueran tratadas con cuidado, CAN triunfa en este
entorno, por su robustez y por encontrarse en un medio pequeño que no necesita de tanta velocidad para
llegar de un dispositivo a otro.
Un caso particular sería el hecho de que cuando uno maneja un auto y va acelerando, y de repente
enciande el aire acondicionado, no quiere que toda la energía empleada pase a este nuevo dispositivo
dejando sin fuerza al auto; a la vez si uno por descuido, a alta velocidad pisa el freno, sin soltar el
acelerador, el comportamiento esperado es que el auto deje de acelerar, y comience la secuencia de
frenado del vehículo, con dispositivos CAN controlando cada una de estas tareas, y un procesador central
que las mantenga interconectadas entre sí, a pesar de las diferentes características que las partes puedan
tener, es posible comunicarlas.
10