Proyecto 4: Proyecto de investigacin

Tema: Protocolo de Redes CAN (Controller Area Network)

ALONSO, Dionisio Enrique

e-mail: alonso@hal.famaf.unc.edu.ar

CARRASCOSA, Rafael
e-mail: rcarrasc@hal.famaf.unc.edu.ar

OLIVA BRUNO, Horacio Alberto

e-mail: oliva@hal.famaf.unc.edu.ar

Junio 2005

ndice
1. Introduccion

2. Un poquito de Historia

2.1.

Lnea cronolgica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3. Especicacion light

3.1.

Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2.

Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3.

3.2.1.

DATA FRAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2.2.

REMOTE FRAME

3.2.3.

ERROR FRAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2.4.

OVERLOAD FRAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Errores y estados de error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4. Capas de aplicacin
4.0.1.

CAN Kingdom: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.1.

CANOpen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2.

J1939

4.3.

DeviceNEt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4.

Comparaciones

4.5.

Comparacin entre SDS, DeviceNet and CAN Kingdom

. . . . . . . . . . . . . . . . . . .

4.6.

Diferencias entre CAN Kingdom y CANOpen . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5. Campo de aplicacin

5.1.

Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.2.

CAN en el control de motores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.3.

CAN en vehculos no destinados al transporte de pasajeros

. . . . . . . . . . . . . . . . .

5.4.

CAN en aplicaciones martimas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.5.

CAN redes de tecnologa de aviacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.6.

CAN en produccin y control industrial

5.7.

CAN en ascensores y puertas automticas . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.8.

CAN en equipamiento mdico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

6. Ejemplo de aplicacin

10

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. 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 rpidamente obvio, que el
protocolo se comportara extremadamente bien en una gran variedad de sistemas de aplicaciones. En
1990 la tecnologa CAN fue introducida en maquinas textiles, y hoy en da esta industria realiza un gran
uso de los sistemas CAN. Los chips CAN se pueden encontrar en sistemas de elevacin de edicios altos,
naves de todo tipo, trenes, y aviones, en mquinas de rayos X y en otros equipamientos mdicos, etc. En
estos das la mayora 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 comunicacin de los vehculos.
Los lderes 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 despus de eso. Motorota y NEC lo siguieron; hoy en da unos quince vendedores de
semiconductores construyen chips CAN. La organizacin de estndares internacionales (ISO), localizada
en Geneva, Suiza, es una red de institutos de estndares que a partir de 147 pases dene los estndares
para la cooperacin internacional en tecnologa. ISO publico el estndar 11898 en noviembre de 1993
para denir CAN en el uso de la industria en general. El grupo de usuarios de CAN en Automatizacin
fue fundado en marzo de 1992. Ahora en el vigsimo ao, el protocolo CAN todava se est realzando.
A principios del 2000 un destacamento de fuerzas de la ISO deni un protocolo para la planicacin
de transmisin de mensajes CAN llamados Tiempo Accionado CAN (TTCAN). El grupo de usuarios de
CAN estima que la extensin TTCAN le permitir a la red de rea controlada (CAN) continuar su rpido
crecimiento por otros diez a quince aos dentro de una gran variedad de sistemas de aplicaciones. En
los prximos aos, los sistemas CAN pueden estar funcionando en cada tipo de maquina o proceso que
exista.

2.1.

Lnea cronolgica
1983 Comienzo del proyecto interno de Bosch para el desarrollo dentro de una red vehicular.
1986 Introduccin 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 Automatizacin.
1992 Protocolo de Capa de Aplicacin Can publicado por CiA.
1992 Primero automoviles de Mercedez-Benz usando red CAN.
1993 Publicacion del estndar 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 comunicacin tiempo-accionado para CAN (TTCAN).

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 seal 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 arbitracin 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 arbitracin del canal fallaria. Los identicadores tienen 11 bits de longitud en CAN
estandart y 29 bits en la version extendida.
Para la codicacin 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.

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 aplicacin
El estndar CAN dene el hardware (la capa fsica - hay varios) y la comunicacin sobre un
nivel bsico (la capa de trasmisin de datos). El protocolo CAN en s mismo apenas especica cmo
transportar los paquetes pequeos 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 ms grandes
que puede caber en un mensaje de 8-bytes, direcciones del nodo, el establecimiento de la comunicacin,
etc.
Para manejar la comunicacin dentro de un sistema, se requiere un protocolo de capa de alto nivel
(HLP). El trmino HLP se deriva del modelo OSI y de sus siete capas. El HLP especica tpicamente
cosas como:
El comportamiento de la puesta a punto.
Cmo distribuir identicadores de mensaje entre diversos nodos en un sistema.
Cmo traducir el contenido de datos del frame.

Estado que viaja dentro del sistema.

Las puestas en prctica de hardware de CAN cubren las dos capas ms 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 comunicacin, y para
describir objetos de comunicacin as como servicios en estos objetos. Los modelos acordados son comunes
en tecnologa de comunicacin. El modelo de ISO/OSI (interconexin internacional de los sistemas de
la estandardizacin Organizacin/Abierta) se utiliza extensamente para describir la funcionalidad de los
sistemas de comunicacin en base de un acercamiento jerrquico.
La funcionalidad proporcionada por CAN es similar a las letras latinas en la comunicacin humana.
Es la base para escribir una lengua, pero no es bastante a comenzar con la comunicacin eciente. Para
especicar una lengua se necesita adems una accin de palabras as como la gramtica para construir
oraciones. Los usuarios de CAN pueden especicar su propia lengua basada en CAN, (CAN-based) en
trminos tcnicos que esto es un protocolo de la capa de aplicacion. O el usuario decide utilizar un
protocolo estandardizado de la capa de aplicacin de CAN-based. En el mundo de CAN hay diversos
protocolos de capa estandardizados de uso. Algunos son muy especcos 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 slo el mensaje sino tambin
controla el acceso al bus,un factor dominante es la enumeracin de los mensajes. Otro factor importante
es considerar que la estructura de datos en la zona de informaciones es igual en los mdulos que transmiten
y de recepciones. Adoptando algunas reglas simples del diseo estos factores pueden ser completamente
controlados y comunicacin optimizados para cualquier sistema. Esto se hace durante una fase corta de
la disposicin en la inicializacin 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 conguracin. CANopen fue diseado para redes
movimiento-orientadas de control de mquina, tales como sistemas de tramitacin.
CANopen fue pre-desarrollado en un proyecto del Esprit bajo presidencia de Bosch. En 1995, la
especicacin de CANopen fue entregada a CAN en el grupo internacional de usuarios y fabricantes de
automatizacin (Cia). Originalmente, el perl de la comunicacin de CANopen fue basado en el protocolo
de la capa de uso de la CAN (CAL). La versin 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 comunicacin (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 diseador de sistema de integrar un sistema de red CANopen. Los dispositivos,
las herramientas, y los apilados disponibles del protocolo estn extensamente disponibles en los precios
razonables. Para diseadores de sistema, es muy importante la reutilizacion de software.Esto requiere no
solamente compatibilidad de comunicacin, sino tambin interoperabilidad y la capacidad de intercambio
de dispositivos. En los perles del dispositivo y de la interfaz de CANopen, los objetos denidos del uso

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 genrica descrita en los perles.
Proporciona los objetos estandardizados de comunicacin para datos en tiempo real (objetos de proceso de datos, PDO), los datos de la conguracin (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
direccin 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 comunicacin
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 electrnico (el ECU) dentro de un sistema
de camion y del acoplado. La especicacin J1939 - con su motor, transmisin, 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 comunicacin J1939, en detalle las deniciones
del protocolo J1939/21 y J1939/31 - se requieren para cualquier sistema J1939-compatible. Agregaron
otras capas fsicas y denieron otros parmetros de uso. La ISO estandardiz la comunicacin del camion
y del acoplado J1939-based (ISO 11992) y la comunicacin J1939-based para los vehculos de agricultura
y de silvicultura (ISO 11783). El NMEA especic la comunicacin J1939-based para los sistemas de
navegacin en el uso de la marinas (NMEA 2000). Una razn de la incorporacin de las especicaciones
J1939 en otras areas es el hecho que hace sentido de reinventar los servicios bsicos de la comunicacin.
La Cia ha desarrollado varios perles de interfaz de CANopen para las redes de J1939-based (Cia DSP
413). Las entradas se denen segn ISO 11992-2 y ISO 11992-3. Adems, la familia del perl de CANopen
incluye un marco para las entradas segn SAE J1939/71.

4.3.

DeviceNEt

DeviceNet se utiliza principalmente en entornos industriales, en detalle, en la automatizacin de

fbrica. Es un puente de comunicaciones barato para conectar los dispositivos industriales (tales como
interruptores de lmite, los sensores fotoelctricos, mltiples de la vlvula, 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 comunicacin mejorada entre los dispositivos as como el diagnstico importante
del dispositivo-nivel poco accesible o los interfaces atados con alambre duro directo disponibles de I/O.
DeviceNet es una solucin simple del establecimiento de una red que reduce el coste y la poca
de atar con alambre y de instalar los dispositivos de la automatizacin de fbrica, mientras que proporciona capacidad de intercambio omoomponentes de vendedores mltiples. Las especicaciones de
DeviceNet han sido desarrolladas por la asociacin abierta del vendedor de DeviceNet (ODVA) e internacionalmente se estandardizan. Los compradores de la especicacin de DeviceNet reciben una licencia
ilimitada, derecho-libre de desarrollar los productos de DeviceNet.

4.4.

Comparaciones

A continuacin se mencionaran algunas caractersticas y comparaciones que merecen su presencia.

4.5.

Comparacin entre SDS, DeviceNet and CAN Kingdom

El SDS y DeviceNet han especicado los perles para diversos dispositivos. Se necesita esto pues no
se dene ningn 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 cmo los mdulos deben nalmente ser diseados, el CAN Kingdom especica cmo los
mdulos 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 nmero y las prioridades, etc del nodo.

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
informacin. El sistema sirve los nodos en un sistema. Entonces cada nodo (cliente) tiene que tener
informacin 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 ms pequeas que las de CANOpen puestas en prctica.
CAN Kingdom es desarrollado para sistemas de mquinas. El sistema es superior sobre los nodos. En
un sistema de mquina, un nodo no tiene ninguna voluntad por si solo. Se coloca en un sistema para
realizar tareas especcas segn una voluntad del diseador de sistema. Se analiza cada situacin que
ocurrir y la mquina se disea para comportarse de maneras especcas cuando ocurren las situaciones
especcas.
CANOpen se basa en el modelo OSI que se desarrolla para los sistemas de ocina y de telecomunicacin
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 disea solamente para el control de mquina con CAN para dar la
posibilidad que un diseador de sistema consiga funcionamiento mximo y dependencia por parte de los
diseadores del nodos para con sistemas especcos.
CANOpen se basa en CAL. CAL se desarrolla en opiniones y reglas comnmente aceptadas sobre el
establecimiento de una red. Sin embargo, estas opiniones y reglas se derivan de teoras y de experiencias
de redes de comunicaciones para intercambiar la informacin, no para el control de la mquina.

5. Campo de aplicacin
5.1.

Introduccin

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 crtico. Un

bus CAN puede ser situado y luego se le pueden aadir ms equipamiento fcilmente 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 mayora de los autos europeos para el control del
motor y el equipamiento electrnico. Los fabricantes de automviles estadounidenses y asiticos tambin
implementan el protocolo.

5.3.

CAN en vehculos no destinados al transporte de pasajeros

CAN es la solucin natural para vehculos equipados con instrumentos tales como escaleras o vlvulas
en camiones de bomberos, sistemas de control de refrigeracin, o conexiones de vagones. En los muchos
ejemplos de vehculos de transporte, el

bus

de comunicaciones es utilizado por el fabricante y por los

mltiples vendedores que proveen equipamiento para la plataforma del vehculo. Eligiendo un estandar
como CAN y protocolos de ms alto nivel, son necesarios para asegurar la inter-operabilidad de las
partes. Ms an, si los vendedores desarrolan en conjunto un perl como por ejemplo el Protocolo Dedicado

CANopen, la construccin en lnea de ensamble, el testeo y mantenimiento se veran altamente

CANopen y J1839 son ejemplo de protocolos de alto nivel utilizados en aplicaciones de

simplicados.
este tipo.

El mismo Razonamiento es aplicable a la construccin de maquinaria de trabajo como pequeos

camiones o ascensores de carga, como as tambin equipo de agricultura.
Veamos el siguiente caso de estudio: Los fabricantes de un vehculo elctrico, como por ejemplo el
elevadores de carga, carritos de aeropuerto, o carritos de golf, todos ellos utilizan bateras muy caras,
para funcionar. Por otro lado los fabricantes de cargadores de bateras, tienen que proveer bateras que
carguen rpidamente y de forma segura todos estos tipos de bateras. Deeniendo en conjunto el perl
de la batera y el cargador de bateras

CANopen,

ellos se dan a s mismos el correcto sistema para

intercambiar las caractersticas de carga, monitorear las cargas, y almacenar el estado de las cargas.
Muchas pequeas industrias contribuyen con estos sistemas, la mayora 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 compaia de semiconductores ofrezca el hardware y un software de protocolo de alto

nivel, ms soporte de ayuda de algn otro tipo.

5.4.

CAN en aplicaciones martimas

CAN es utilizado para conectar diversos subsistemas en navos. Las caractersticas del sistema son de
algn modo parecidas a las de los sistemas de automatizacin en las fbricas. Algunos sistemas crticos
necesitan de una capa extra ms segura basada en redundancia. Esto es otro ejemplo de uso de los ya
mencionados

CANopen y J1839.

Una segunda categora para la aplicacin martima, es la industria pezquera, como as tambin la
navegacin acionada. En este tipo de aplicaciones podemos encontrar GPS's, radares, sonares, rastreadores de peces, paneles de control, pantallas ms una inmensa variedad de sensores de seguridad.
Esto representa un gran volumen de negocios y de feroz competencia, especialmente en lugares donde
la navegacin acionada de recreacin es muy popular. Todos los equipos anteriormente mencionados,
requieren controladores CAN con bajo consumo, una alta capasidad de reprogramacin de micro-partes
digitales y analgicas, y por sobre todo, un costo bajo.

5.5.

CAN redes de tecnologa de aviacin

Compaias como Airbus, Boeing y la NASA usan CAN como red troncal para la medicin del estado
de los sensores y sistemas de navegacin. Componentes de grado industrial normal pueden ser usados en
esto tipos de sistemas.

5.6.

CAN en produccin y control industrial

Este es el ncleo 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

fotoelctricos, drives de motores (como por ejemplo las cintas transportadoras de equipaje), motores de
robots, brazos mecnicos, controles de movimiento, controles de vlbulas, Controles Lgicos Programables
(PLC), lectores de cdigos 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 travs 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 fabricacin, el PLC controlando el sistema crtico, y el dispositivo controlando
la parte del equipamiento que puede herir a algn 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 automticas

Los fabricantes de ascensores, como los fabricantes de puertas elctricas, tienen que tabajar en conjunto
para desarrollar un perl de CANopen especco para sus aplicaciones. Esto representa un inmenso

volumen de aplicaciones. Por ejemplo, una construccin 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, necesitarn correr un paquete de protocolo full ms ofrecer
interaccin digital y la posibilidad de entrada analgica y una salida por PWM.
Las puertas elctricas 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 (cdigos +

datos) encima del protocolo de alto nivel. Tambin van a requerir una entrada analgica y un control
PWM de salida ms switches de control digitales. Todo esto puede estar rondando cerca de 50 nodos
CAN extra.

5.8.

CAN en equipamiento mdico

CAN ha sido usado en redes empotradas en dispositivos mdicos desde hace ya varios aos. La
automatizacin en laboratorios no es muy diferente a la automatizacin en las fbricas; por ello, se di
un paso signicativo, cuando los fabricantes, repenzaron su relacin 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 estndares
en desuso como LON fueron comparadas con CAN. La combinacin 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 generacin, incluye de 5 a 10 nodos CAN.
La lente de una mquina 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 aplicacin
Un ejemplo de uso de este tipo de redes, se puede ver muy fcilmente en un automovil, donde se
encuentra un procesador que controla montones de dispositivos con redes CAN, aquellos como ventanillas
elctricas, 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 podran resultar vitales si no fueran tratadas con cuidado, CAN triunfa en este
entorno, por su robustez y por encontrarse en un medio pequeo que no necesita de tanta velocidad para
llegar de un dispositivo a otro.
Un caso particular sera el hecho de que cuando uno maneja un auto y va acelerando, y de repente
enciande el aire acondicionado, no quiere que toda la energa 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 vehculo, con dispositivos CAN controlando cada una de estas tareas, y un procesador central
que las mantenga interconectadas entre s, a pesar de las diferentes caractersticas que las partes puedan
tener, es posible comunicarlas.

10