Documentos de Académico
Documentos de Profesional
Documentos de Cultura
2. Fundamentos teóricos
En este capítulo se realizará un marco teórico con los fundamentos y los aspectos más
importantes del proyecto. Por un lado, se van a describir los dos protocolos de comunicación
presentes en el diseño: CAN y OBDII. Por otro lado se profundizará en el tema de los
microcontroladores, con los que construiremos las unidades encargadas de gestionar los
sensores/actuadores y los buses de comunicación.
3
2.1 Protocolos de Comunicación
Como ya se indicó en el capítulo anterior el objetivo de este proyecto es crear un prototipo
de red de comunicaciones interna basada en un bus de comunicaciones que permita el flujo de
datos entre el ordenador de a bordo y la ECU a través de un nodo interfaz que adaptará el
ordenador de a bordo a la red CAN. Este prototipo se ha diseñado y desarrollado con la idea de
ser la base de las comunicaciones internas de un vehículo eléctrico.
La tecnología elegida para la implementación del bus es CAN, el cual es un bus serie creado
para la transmisión de mensajes en entornos distribuidos. Se ha elegido este protocolo porque
está presente en la industria automovilística desde 1992.
El otro protocolo que se usará en el proyecto es OBDII. Este sistema de diagnosis permite
localizar los errores producidos en el vehículo, ahorrando tiempo en la localización y
reparación de averías. En caso de fallo, este protocolo es el encargado de almacenar toda la
información referida a dicho fallo, así como avisar al conductor del mal funcionamiento. Como
4
medio físico, utiliza el bus CAN y se comunica con el exterior mediante un conector
estandarizado J1962. Desde 2008 todos los vehículos llevan incorporado un sistema OBDII.
En la siguiente figura se puede ver una arquitectura típica del bus de comunicaciones
internas de un vehículo.
5
Existen varios buses CAN de diferentes velocidades, destinados a distintos grupos de
elementos del vehículo:
Motor (ECU)
ABS
TRACCIÓN Alta (1Mbps) Dirección
Cambio
Airbag
Cierre centralizado
CONFORT Baja (125Kbps) Alarma
Climatizador
Radio
INFOTENIMIENTO Baja (125Kbps)
Pantalla
CUADRO DE
Baja (125Kbps) Cuadro de instrumentos
INSTRUMENTOS
Media (500Kbps) Motor (ECU)
DIAGNOSIS
Baja (125Kbps) Cambio automático
Tabla 1: Velocidades del bus CAN en un vehículo
Todos estos buses van a parar a una unidad central que será la encargada de gestionarlos
además de hacer de pasarela entre buses.
En los siguientes apartados se va a describir en profundidad éstos dos protocolos.
2.2.1 Historia
El sistema de bus serie CAN, siglas cuyo significado en castellano es Control de Área de
Red, nació en febrero de 1986, cuando el grupo Robert Bosch GmbH (más conocido como
6
“Bosch”) lo presentó en el congreso de la Sociedad de Ingeniería de la Automoción. Desde
entonces, CAN se ha convertido en uno de los protocolos líderes en la utilización del bus serie.
El profesor Wolfhard Lawrenz de la Universidad de ciencias aplicadas de Brunswick-
Wolfenbüttel, Alemania, fue quién dio al nuevo protocolo de red el nombre de Controller Area
Network (CAN).
A comienzos de los 80, los ingenieros de Bosch evaluaron el posible uso de los sistemas de
bus serie existentes en los coches de pasajeros, pero ninguno de los protocolos de red
disponibles satisfacía los requisitos necesarios. Es por tanto que este protocolo de bus serie se
ideó principalmente para aportar mayor funcionalidad, seguridad y fiabilidad, junto a una
mayor eficiencia en el gasto del combustible, ya que la reducción del peso y la complejidad de
los automóviles a través de la reducción del cableado iban a favorecer este hecho. Pronto,
ingenieros de Mercedes-Benz se involucraron en las primeras fases de creación del nuevo
sistema, al que también se unió Intel como potencial vendedor de semiconductores.
A mediados de 1987, Intel presentó el primer chip de controlador CAN: el 82526. Poco
tiempo después, Semiconductores Philips presentaría el 82C200. Estos dos antepasados
primigenios de los controladores CAN actuales eran completamente distintos en cuanto a
filtros de aceptación y control de mensajes: Intel adoptó el concepto de FullCAN; este requería
menos carga de la CPU del microcontrolador que la implementación BasicCAN elegida por
Philips. Pero por otra parte, el dispositivo de FullCAN era limitado con respecto al número de
los mensajes que podían ser recibidos. Además, el controlador de BasicCAN requería menos
silicio, lo que abarataba aún más su coste. Actualmente, los términos BasicCAN y FullCAN han
quedado obsoletos.
A pesar de que CAN surgió con la idea de ser utilizado en coches de pasajeros, un gran
número de las primeras aplicaciones llegarían desde otros segmentos de mercado distintos:
El fabricante finlandés de ascensores Kone, fue uno de los primeros en
aprovecharse de sus ventajas.
La oficina de ingeniería suiza Kyaser lo introdujo a los fabricantes de maquinaria
textil del país, que acabaron fundando el Grupo de usuarios textiles CAN.
En Holanda, Sistemas médicos Philips lo utilizó para las redes internas de sus
máquinas de Rayos X. La especificación para mensajes de Philips, representó la
primera capa de aplicación para redes CAN.
También se sucedieron todo tipo de propuestas académicas, como por ejemplo, la
creación a finales de los 80 de un sistema de bus basado en CAN, para vehículos
agrícolas.
7
Ya en 1992, Mercedes-Benz implantó CAN en sus automóviles de clase alta. El sistema
estaba compuesto por dos redes CAN, una red de alta velocidad, en la que se comunicaban las
ECUs del motor, la unidad de control de la caja de cambios y el tablero de instrumentos; y una
red de baja velocidad, para el control del aire acondicionado y de los dispositivos electrónicos
internos, conectando ambas redes CAN mediante gateways (pasarelas). La implementación
realizada por Mercedes-Benz propició que otros fabricantes de automóviles comenzaran a
utilizar redes CAN en sus modelos de lujo, por ejemplo BMW, Jaguar, Volvo, Saab y
Volskwagen, más tarde se agregaron a la lista Fiat y Renault.
En Marzo de ese mismo año, usuarios internacionales y grupos de fabricantes fundaron
oficialmente la organización CiA (CAN in Automation). La primera publicación técnica, que
trataba acerca de la capa física, fue emitida sólo unas semanas después: CiA recomendaba
utilizar solamente transceptores CAN que cumplieran la normativa ISO 11898. Otra de las
primeras tareas de la CiA fue la especificación de la capa de aplicación CAN, CAL (CAN
Application Layer), que se desarrolló a partir del material existente de los sistemas médicos de
Philips PMS (Philips Medical Systems).
Las implementaciones hardware de CAN cubren de forma estandarizada las capas físicas y
de enlace del modelo de comunicaciones OSI (Open Systems Interconnection), mientras
diversas soluciones de software no estandarizadas cubren otras capas superiores como la capa
de aplicación.
Las estandarizaciones ISO (International Standard Organization), a diferencia de las
normas BOSCH, especifican también el medio de comunicación. Por lo tanto una
implementación CAN a partir de las especificaciones de BOSCH no siempre será compatible
con las normas ISO.
La capa física de CAN, es responsable de la transferencia de bits entre los distintos nodos
que componen la red. Define aspectos como niveles de señal, codificación, sincronización y
tiempos en que los bits se transfieren al bus.
En la especificación original de CAN, la capa física no fue definida, permitiendo diferentes
opciones para la elección del medio y niveles eléctricos de transmisión. Las características de
las señales eléctricas en el bus, fueron establecidas más tarde por el estándar ISO 11898 para
las aplicaciones de alta velocidad (hasta 1Mbps) destinadas para controlar el motor e
interconectar las unidades de control electrónico, y por el estándar ISO 11519 para las
aplicaciones de baja velocidad (hasta 125 Kbps) tolerante a fallos dedicada a la comunicación
de los dispositivos electrónicos internos como son control de puertas, techo corredizo, luces y
asientos.
9
Estándar ISO 11519 (baja velocidad)
Los nodos conectados en este bus interpretan dos niveles lógicos denominados
dominante y recesivo:
o Dominante: la tensión diferencial (CAN_H - CAN_L) es del orden de 2V,
con CAN_H = 3.5V y CAN_L = 1.5V (nominales).
o Recesivo: la tensión diferencial (CAN_H - CAN_L) es del orden de 5V, con
CAN_H = 0V y CAN_L = 5V (nominales).
A diferencia del bus de alta velocidad, el bus de baja velocidad requiere dos
resistencias en cada transceptor: RTH para la señal CAN_H y RTL para la señal CAN_L.
Esta configuración permite al transceptor de bus de baja velocidad (fault-tolerant)
detectar fallos en la red. La suma de todas las resistencias en paralelo, debe estar en el
rango de 100-500Ω.
10
Estándar ISO 11898 (alta velocidad)
Los nodos conectados en este bus interpretan los siguientes niveles lógicos:
o Dominante: la tensión diferencial (CAN_H - CAN_L) es del orden de 2V,
con CAN_H = 3.5V y CAN_L = 1.5V (nominales).
o Recesivo: la tensión diferencial (CAN_H - CAN_L) es del orden de 0V, con
CAN_H = CAN_L = 2.5V (nominales).
El par de cables trenzados (CAN_H y CAN_L) constituyen una transmisión de línea.
Si dicha transmisión de línea no está configurada con los valores correctos, cada trama
transferida causa una reflexión que puede originar fallos de comunicación. Como la
comunicación en el bus CAN fluye en ambos sentidos, ambos extremos de red deben
de estar cerrados mediante una resistencia de 120Ω. Ambas resistencias deberían
poder disipar 0.25W de potencia.
11
Formato de codificación y sincronización de datos
Esta capa es la responsable de controlar el flujo de información entre los nodos de la red.
Es decir, se encarga de la transmisión de los bits en frames o tramas de información, se ocupa
de que los mensajes lleguen al destino sin errores, controla las secuencias de transmisión, los
acuses de recibo y si en determinado caso no se recibe un mensaje correctamente se encarga
de retransmitirlo. Se puede dividir esta capa en dos subcapas que se ocupan de diferentes
tareas:
Esta subcapa representa el núcleo del protocolo CAN. Por un lado presenta los mensajes
recibidos a la subcapa LLC y acepta los mensajes para ser transmitidos a dicha subcapa y por
otro lado es responsable del mecanismo de arbitraje de acceso al medio.
Unas de las características que distingue a CAN con respecto a otras normas, es su técnica
de acceso al medio denominada como CSMA/CD+CR o Carrier Sense Multiple Access/Collision
Detection + Collision Resolution (Acceso Múltiple con detección de portadora, detección de
12
colisión más resolución de colisión). Cada nodo debe vigilar el bus en un periodo sin actividad
antes de enviar un mensaje (Carrier Sense) y además, una vez que ocurre el periodo sin
actividad cada nodo tiene la misma oportunidad de enviar un mensaje (Multiple Access). En
caso de que dos nodos comiencen a transmitir al unísono se detectará la colisión.
El método de acceso al medio utilizado en bus CAN añade una característica adicional: la
resolución de colisión. En la técnica CSMA/CD utilizada en redes Ethernet ante colisión de
varias tramas, todas se pierden. CAN resuelve la colisión con la supervivencia de una de las
tramas que chocan en el bus. Además la trama superviviente es aquella a la que se ha
identificado como de mayor prioridad. La resolución de colisión se basa en una topología
eléctrica que aplica una función lógica determinista a cada bit, que se resuelve con la prioridad
del nivel definido como bit de tipo dominante. Definiendo el bit dominante como equivalente
al valor lógico '0' y bit recesivo al nivel lógico '1' se trata de una función AND de todos los bits
transmitidos simultáneamente. Cada transmisor escucha continuamente el valor presente en
el bus, y se retira cuando ese valor no coincide con el que dicho transmisor ha forzado.
Mientras hay coincidencia la transmisión continua, finalmente el mensaje con identificador de
máxima prioridad sobrevive. Los demás nodos reintentarán la transmisión lo antes posible.
Se ha de tener en cuenta que la especificación CAN de Bosch no establece cómo se ha de
traducir cada nivel de bit (dominante o recesivo) a variable física. Cuando se utiliza par
trenzado según ISO 11898 el nivel dominante es una tensión diferencial positiva en el bus, el
nivel recesivo es ausencia de tensión, o cierto valor negativo, (los transceptores no generan
corriente sobre las resistencias de carga del bus). Esta técnica aporta la combinación de dos
factores muy deseados en aplicaciones industriales distribuidas: la posibilidad de fijar con
determinismo la latencia en la transmisión de mensajes entre nodos y el funcionamiento en
modo multimaestro sin necesidad de gestión del arbitraje, es decir control de acceso al medio,
desde las capas de software de protocolo. La prioridad queda así determinada por el contenido
del mensaje que en CAN es un campo determinado, el identificador de mensaje, el que
determina la prioridad.
En un bus único, un identificador de mensaje ha de ser asignado a un solo nodo concreto,
es decir, se ha de evitar que dos nodos puedan iniciar la transmisión simultánea de mensajes
con el mismo identificador y datos diferentes. El protocolo CAN establece que cada mensaje es
único en el sistema, de manera que por ejemplo, si en un automóvil existe la variable “presión
de aceite”, esta variable ha de ser transmitida por un nodo concreto, con un identificador
concreto, con una longitud fija concreta y coherente con la codificación de la información en el
campo de datos.
En la siguiente figura se ve un ejemplo de arbitraje en un bus CAN.
13
Figura 7: Arbitraje del Bus CAN
La subcapa LLC describe la parte alta de la capa de enlace de datos y define las tareas
independientes del método de acceso al medio, asimismo proporciona dos tipos de servicios
de transmisión sin conexión al usuario de la capa LLC (LLC user):
Servicio de transmisión de datos sin reconocimiento: proporciona, al usuario LLC,
los medios para intercambiar unidades de datos de servicio de enlace LSDU (Link
Service Data Unit) sin establecer una conexión de enlace de datos. La transmisión
de datos puede ser punto a punto, multidifusión o difusión.
Servicio de petición de datos remota sin reconocimiento: proporciona, al usuario
LLC, los medios para solicitar que un nodo remoto transmita sus LDSUs sin
establecer una conexión de enlace de datos.
De acuerdo con los tipos de servicios, se definen dos formatos de tramas, de datos LLC y
remota LLC. Ambos formatos definen identificadores de 11 bits (estándar) y de 29 bits
(extendida).
Las funciones de la subcapa LLC son las siguientes:
• Filtrar mensajes (frame acceptance filtering): el identificador de una trama no indica
la dirección destino pero define el contenido del mensaje, y mediante esta función todo
receptor activo en la red determina si el mensaje es relevante o no para sus propósitos.
14
• Notificar sobrecarga (overload notification): si las condiciones internas de un
receptor requieren un retraso en la transmisión de la siguiente trama de datos o remota, la
subcapa LLC transmite una trama de sobrecarga. Una trama de sobrecarga puede ser
generada por cualquier módulo que debido a sus condiciones internas no está en
condiciones de iniciar la recepción de un nuevo mensaje. De esta forma retrasa el inicio de
transmisión de un nuevo mensaje. Un módulo puede generar como máximo 2 tramas de
sobrecarga consecutivas para retrasar el mensaje.
• Proceso de recuperación (recovery management): la subcapa LLC proporciona la
capacidad de retransmisión automática de tramas cuando una trama pierde el arbitraje o
presenta errores durante su transmisión, dicho servicio se confirma al usuario hasta que la
transmisión se completa con éxito.
Tramas
El protocolo CAN está basado en mensajes, no en direcciones. El nodo emisor transmite el
mensaje a todos los nodos de la red sin especificar un destino y todos ellos escuchan el
mensaje para luego filtrarlo según le interese o no.
Existen distintos tipos de tramas predefinidas por CAN para la gestión de la transferencia
de mensajes:
Trama de datos: se utiliza normalmente para poner información en el bus y la
pueden recibir algunos o todos los nodos.
Trama de información remota: puede ser utilizada por un nodo para solicitar
la transmisión de una trama de datos con la información asociada a un
identificador dado. El nodo que disponga de la información definida por el
identificador la transmitirá en una trama de datos.
Trama de error: se generan cuando algún nodo detecta algún error definido.
Trama de sobrecarga: se generan cuando algún nodo necesita más tiempo
para procesar los mensajes recibidos.
Espaciado entre tramas: las tramas de datos (y de interrogación remota) se
separan entre sí por una secuencia predefinida que se denomina espaciado
inter-trama.
Bus en reposo: En los intervalos de inactividad se mantiene constantemente el
nivel recesivo del bus.
En un bus CAN los nodos transmiten la información espontáneamente con tramas de
datos, bien sea por un proceso cíclico o activado ante eventos en el nodo. La trama de
15
interrogación remota sólo se suele utilizar para detección de presencia de nodos o para puesta
al día de información en un nodo recién incorporado a la red. Los mensajes pueden entrar en
colisión en el bus, el de identificador de mayor prioridad (el identificador con menor número
binario) sobrevivirá y los demás son retransmitidos lo antes posible.
A continuación se describen con mayor detalle cada una de las tramas antes mencionadas:
Trama de datos
Es la utilizada por un nodo normalmente para poner información en el bus. Puede incluir
entre 0 y 8 bytes de información útil.
Los mensajes de datos consisten en celdas que envían datos y añaden información definida
por las especificaciones CAN:
16
Figura 9: Formatos de la celda de arbitraje
o Celda de control (Control Field): el campo de control está formado por dos
bits reservados para uso futuro y cuatro bits adicionales que indican el número
de bytes de datos. En realidad el primero de estos bits, el bit IDE (Identifier
Extension) se utiliza para indicar si la trama es CAN Estándar (IDE dominante) o
CAN Extendido (IDE recesivo). El segundo bit r0 (reservado para uso futuro) es
siempre recesivo. Los cuatro bits de código de longitud DLC (Data Length
Code) indican en binario el número de bytes de datos en el mensaje (de 0 a 8).
o Celda de Datos (Data Field): es el campo de datos y su longitud en octetos
está indicada en el DLC (de 0 a 8 bytes).
o CRC (Cyclic Redundancy Check): es un código de redundancia cíclico. Tras
comprobar este código se podrá determinar si se han producido errores en la
transmisión de la trama.
o Celda de reconocimiento (ACK, Acknowledgment): es un campo de 2 bits que
indica si el mensaje ha sido recibido correctamente. El nodo transmisor pone
este bit como recesivo y cualquier nodo que reciba el mensaje lo pone como
dominante para indicar que el mensaje ha sido recibido.
o Fin de trama (EOF, End Of Frame): consiste en 7 bits recesivos sucesivos e
indica el final de la trama.
o Espaciado entre tramas (IFS, Inter-Frame Space): consta de un mínimo de 3
bits recesivos.
Trama remota
Los nodos tienen habilidad para requerir información a otros nodos. Un nodo pide una
información a los otros y el nodo que tiene dicha información envía una comunicación con la
respuesta que puede ser recibida además por otros nodos si están interesados.
17
Figura 10: Formato de la trama remota
En este tipo de mensajes se envía una trama con el identificador del nodo requerido, a
diferencia con los mensajes de datos, el bit RTR toma valor recesivo y no hay campo de datos.
En caso de que se envíe un mensaje de datos y de petición remota con el mismo identificador,
el de datos ganará el acceso al bus puesto que el RTR lleva valor dominante.
Trama de error
Las tramas de error son generadas por cualquier nodo que detecta un error. Consiste en
dos campos:
o Indicador de error (Error Flag): es distinto según el estado de error del nodo
que detecta el error.
o Delimitador de error (Error Delimeter): consta de 8 bits recesivos
consecutivos y permite a los nodos reiniciar la comunicación limpiamente tras
el error.
Trama de sobrecarga
Una trama de sobrecarga tiene el mismo formato que una trama de error activo. Sin
embargo, la trama de sobrecarga sólo puede generarse durante el espacio entre tramas. De
esta forma se diferencia de una trama de error, que sólo puede ser transmitida durante la
transmisión de un mensaje.
19
Figura 13: Formato de la trama de sobrecarga
A continuación se van a presentar las características técnicas básicas de CAN para tener
una visión general de este protocolo. Más adelante, en los siguientes apartados, se
profundizará en dichas características para obtener una visión más concreta:
20
Económico y sencillo: dos de las razones que motivaron su desarrollo fueron
precisamente la necesidad de economizar el coste monetario y el de minimizar la
complejidad del cableado, por parte del sector automovilístico.
Estandarizado: se trata de un estándar definido en las normas ISO, concretamente la
ISO 11898, que se divide a su vez en varias partes, cada una de las cuales aborda
diferentes aspectos de CAN.
Medio de transmisión adaptable: el cableado es muy reducido en comparación con
otros sistemas. Además, a pesar de que por diversas razones el estándar de hardware
de transmisión sea un par trenzado de cables, el sistema de bus CAN también es capaz
de trabajar con un solo cable. Esta particularidad es empleada en diversos tipos de
enlaces, como los enlaces ópticos o los enlaces de radio.
Estructura definida: la información que circula entre las unidades a través de los dos
cables (bus) son paquetes de bits (0’s y 1’s) con una longitud limitada y con una
estructura definida de campos que conforman el mensaje.
Programación sencilla: basada en la escritura de registros de los dispositivos CAN.
Número de nodos: el número máximo de módulos no está limitado por la
especificación básica y depende de las características de los controladores CAN. Las
especificaciones de buses de campo lo limitan a un máximo de 64 nodos.
Garantía de tiempos de latencia: CAN aporta la seguridad de que se transmitirá cierta
cantidad de datos en un tiempo concreto, es decir, que la latencia de extremo a
extremo no excederá un nivel específico de tiempo. Además, la transmisión siempre
será en tiempo real.
Optimización del ancho de banda: los métodos utilizados para distribuir los mensajes
en la red, como el envío de estos según su prioridad, contribuyen a un mejor empleo
del ancho de banda disponible.
Desconexión autónoma de nodos defectuosos: si un nodo de red cae, sea cual sea la
causa, la red puede seguir funcionado, ya que es capaz de desconectarlo o aislarlo del
resto. De forma contraria, también se pueden añadir nodos al bus sin afectar al resto
del sistema, y sin necesidad de reprogramación.
Velocidad flexible: ISO define dos tipos de redes CAN: una red de alta velocidad (de
hasta 1 Mbps) definida por la ISO 11898-2, y una red de baja velocidad tolerante a
fallos (menor o igual a 125 Kbps) definida por la ISO 11898-3.
Relación velocidad-distancia: al punto anterior habría que añadir que la velocidad
21
también depende de la distancia hasta un máximo de 1000 metros (aunque se puede
aumentar la distancia con bridges o repetidores), como indica la siguiente tabla
comparativa:
Se observa que el protocolo LIN (Local Interconnect Network) tiene gran presencia en la
industria. Es una opción más económica, pero realmente esta tecnología no es competidora de
CAN debido a que cada una va a ser útil en un ámbito distinto, ya que sus características son
distintas. Por lo tanto podemos decir que más que competidoras ésta tecnología es
complementaria. La diferencia principal, además de la económica, va a resultar ser la
velocidad.
En la siguiente tabla, se exponen las diferentes características de LIN, I2C (Inter-Integrated
Circuit) de Philips y CAN, para detallar las similitudes y diferencias entre ellas:
23
CARACTERÍSTICA CAN LIN I2C
24
Figura 15: Arquitectura de buses CAN y LIN en un mismo vehículo
El 80% de las aplicaciones modernas del bus CAN se pueden encontrar en la ingeniería del
automóvil y otro tipo de vehículos como autobuses, trenes y aviones. En el caso de los
automóviles por ejemplo, CAN es el encargado de la comunicación y automatización del
sistema de freno, los faros, el ABS, o el ordenador de a bordo, del cual vemos su esquema en el
siguiente gráfico:
25
Figura 16: Arquitectura clásica de Bus CAN en un automóvil
Sin embargo, también se puede encontrar el bus CAN en aplicaciones de diversa índole
debido a su naturaleza, que le aporta robustez, economía y un altísimo grado de seguridad y
fiabilidad. Entre las más comunes destacan:
Control y automatización industrial:
◦ Redes entre diversas máquinas y elementos de las mismas.
◦ Redes de supervisión.
◦ Redes de seguridad.
Control y automatización de edificios:
◦ Control de ascensores, puertas mecánicas, aspersores y diversos elementos
mecánicos.
◦ Control de iluminación.
Aplicaciones específicas:
◦ Control de máquinas expendedoras (en Inglaterra está muy extendido su uso).
◦ Control de equipamiento médico.
◦ Control de sistemas automáticos de almacenaje.
◦ Control de electrodomésticos.
26
A día de hoy, el futuro de CAN se prevé esperanzador, ya que incluso las estimaciones más
conservadoras coinciden en que la presencia de CAN en el mercado y en diversos campos de la
industria, va a seguir en aumento durante los próximos diez o quince años.
Todos los vehículos actuales, disponen de una o varias ECUs (Engine Control Units), que se
encargan de gestionar los distintos sistemas eléctricos, electrónicos y mecánicos que
contienen. En concreto, la ECU gestiona ciertos parámetros del motor del vehículo para
asegurar su correcto funcionamiento. Las relaciones entre estos parámetros deben
mantenerse acotadas, dependiendo de las condiciones externas estos parámetros tendrán un
rango de variación determinado, en caso contrario es que se está produciendo algún mal
funcionamiento en el vehículo.
Los parámetros principales que dictan como debe estar funcionando el motor, y que
verifican si todo funcionando correctamente son:
Velocidad.
Carga.
Temperatura del motor.
Consumo de combustible.
Temperatura ambiente.
Caudal de aire.
Emisiones.
Para conocerlos, los automóviles actuales, incorporan una gran cantidad de sensores, que
permiten a la ECU conocer cuáles son las condiciones externas, y decidir cómo actuar sobre el
motor. En caso de que alguno de los parámetros se salga de los rangos marcados, el sistema
OBDII es el encargado de almacenar esta información y de avisar al conductor de que existe un
mal funcionamiento en el motor, señalizando con un indicador luminoso que es recomendable
ir al taller a revisar que error se ha producido.
Una vez el vehículo llega al taller, el equipo de mecánicos puede acceder a la información
almacenada por el OBDII, ver que error era el que se ha producido, y arreglarlo en caso de
necesidad sin tener que hacer múltiples pruebas para descubrir la procedencia del error.
Algunas de las funciones específicas de control que puede desempeñar OBDII según el tipo
de motor son las siguientes:
Control en los motores de gasolina
◦ Vigilancia del rendimiento del catalizador.
◦ Diagnóstico de envejecimiento de sondas lambda.
◦ Prueba de tensión de sondas lambda.
28
◦ Sistema de aire secundario (si el vehículo lo incorpora).
◦ Sistema de recuperación de vapores de combustible.
◦ Prueba de diagnóstico de fugas.
◦ Sistema de alimentación de combustible.
◦ Fallos de la combustión.
◦ Control del sistema de gestión electrónica.
◦ Sensores y actuadores del sistema electrónico que intervienen en la gestión del
motor o están relacionados con las emisiones de escape.
Control en los motores diésel
◦ Fallos de la combustión.
◦ Regulación del comienzo de la inyección.
◦ Regulación de la presión de sobrealimentación.
◦ Recirculación de gases de escape.
◦ Funcionamiento del sistema de comunicación entre unidades de mando, por
ejemplo el bus CAN.
◦ Control del sistema de gestión electrónica.
◦ Sensores y actuadores del sistema electrónico que intervienen en la gestión del
motor o están relacionados con las emisiones de escape.
◦ Control de la contaminación.
Uno de los aspectos más importantes que permite controlar OBDII es la contaminación
que produce el vehículo. El estado actual de la técnica no permite, o sería muy caro, realizar la
medida directa de los gases CO (monóxido de carbono), HC (hidrocarburos) y NOx (óxidos
nítricos), por lo que este control lo realiza la ECU de manera indirecta, detectando los niveles
de contaminación a partir del análisis del funcionamiento de los componentes adecuados y del
correcto desarrollo de las diversas funciones del equipo de inyección que intervengan en la
combustión.
En los vehículos con OBDII se incorpora una segunda sonda lambda que se instala detrás
del catalizador para verificar el funcionamiento del mismo y de la sonda lambda anterior al
catalizador. En el caso de que ésta presente envejecimiento o esté defectuosa, no es posible la
corrección de la mezcla con precisión, lo que deriva en un aumento de la contaminación y
afecta al rendimiento del motor. Para verificar el estado de funcionamiento del sistema de
regulación lambda, el OBDII analiza el estado de envejecimiento de la sonda, la tensión que
generan y el estado de funcionamiento de los elementos calefactores. El envejecimiento de la
29
sonda se determina en función de la velocidad de reacción de la misma, que es mayor cuanto
más deteriorada se encuentre.
Cuando el sistema almacena alguna información de error, indica, generalmente con una
señal luminosa, que algo está funcionando incorrectamente y por tanto es aconsejable que se
acuda a un taller para que revisen el automóvil. Una vez en el taller, el equipo de mecánicos
conectará el automóvil a un escáner o lector del sistema OBDII que le facilitara la información
almacenada.
A principios de los 80, cuando se extendió el uso de este sistema de diagnosis, cada
fabricante era libre de incorporar su propio conector y utilizar los códigos de error que
quisiera. Esto dificultaba mucho la utilización de este sistema para las reparaciones, ya que la
inversión que requería en los talleres mecánicos era altísima y poco practica (debían disponer
de muchos lectores y de muchas tablas de códigos). Para que el uso de este sistema fuera
practico y viable, en 1996, se llegó a un consenso entre los fabricantes y se estandarizaron los
códigos y el conector. Así con un único lector de códigos y una tabla de errores, se puede
diagnosticar un error en cualquier coche, independientemente del fabricante.
2.3.4.1 El conector
El conector del sistema OBDII tiene que cumplir las siguientes especificaciones según la
normativa, ISO 15031-3:2004
31
Figura 17: Pines del conector OBDII
32
2.3.4.2 Modos de medición
Los modos de prueba de diagnóstico OBDII han sido creados de forma que sean comunes a
todos los vehículos de distintos fabricantes. De esta forma es indistinto tanto el vehículo que
se esté analizando como el equipo de diagnosis que se emplee, las pruebas se realizarán
siempre de la misma forma.
El conector de diagnosis normalizado, deber ser accesible y situarse en la zona del
conductor. Los modos de medición son comunes a todos los vehículos y permiten desde
registrar datos para su verificación, extraer códigos de averías, borrarlos y realizar pruebas
dinámicas de actuadores. El software del equipo de diagnosis se encargará de presentar los
datos y facilitar la comunicación. Los modos en que se presentan la información se hallan
estandarizados y son los siguientes:
Modo 1: Identificación de Parámetro (PID, Parameter ID), es el acceso a datos en vivo
de valores analógicos o digitales de salidas y entradas a la ECU. Este modo es también
llamado flujo de datos. Aquí es posible ver, por ejemplo, la temperatura de motor o el
voltaje generado por una sonda lambda en tiempo real.
Modo 2: Acceso a Cuadro de Datos Congelados. Esta es una función muy útil de OBDII
porque la ECU toma una muestra de todos los valores relacionados con las emisiones,
en el momento exacto de ocurrir un fallo. De esta manera, al recuperar estos datos, se
pueden conocer las condiciones exactas en las que ocurrió dicho fallo. Solo existe un
cuadro de datos que corresponde al primer fallo detectado.
Modo 3: permite extraer de la memoria de la ECU todos los códigos de fallo DTC (Data
Trouble Code) almacenados.
Modo 4: con este modo se pueden borrar todos los códigos almacenados en la ECU,
incluyendo los DTCs y el cuadro de datos grabados.
Modo 5: este modo devuelve los resultados de las pruebas realizadas a los sensores
de oxígeno para determinar el funcionamiento de los mismos y la eficiencia del
convertidor catalítico.
Modo 6: permite obtener los resultados de todas las pruebas de abordo.
Modo 7: permite leer de la memoria de la ECU todos los DTCs pendientes.
Modo 8: permite realizar la prueba de actuadores. Con esta función, el mecánico
puede activar y desactivar actuadores como bombas de combustible, válvula de
ralentí, etcétera.
33
2.3.4.3 Códigos de error
Por supuesto, existe una tabla con todos los códigos estandarizados, pero eso no impide
que cada fabricante, añada sus propios códigos para el control de parámetros o errores que no
están tabulados en los códigos estándares.
Una vez conectado el OBDII del vehículo con el PC, es necesario disponer del software
capaz de leer la información que proviene del vehículo. Por supuesto que existen muchas
opciones y a continuación se detallan algunos de los softwares disponibles actualmente para la
lectura de dicha información:
Scantool.net 1.13
EasyOBD II 2.1.1
34
OBD 2007
VitalScan 1.3
Existen otras posibilidades a la hora de leer los códigos, algo más simplificadas, y que
pueden ser adquiridas fácilmente. Se trata de instrumentos de lectura de códigos, que
disponen de capacidad de lectura OBDII sin necesidad de ningún PC. Estos sistemas realizan el
tratamiento de la información del OBDII del vehículo y muestran en su pantalla los códigos de
error.
35
2.4 Microcontroladores
Los microcontroladores van a desempeñar un papel muy importante en este proyecto. Con
estos dispositivos se van a construir las unidades de control encargadas de la gestión de los
sensores y actuadores que se instalen en el vehículo, además de ser las encargadas de
gestionar los diferentes buses y actuar como pasarela entre ellos.
Existen infinidad de posibilidades a la hora de elegir qué microcontroladores emplear, por
lo que se deberá hacer un profundo análisis a fin de elegir los que más se adecuen a las
necesidades del diseño, tanto en aspectos técnico como económicos.
Un microcontrolador es un circuito integrado o chip que incluye en su interior las tres
unidades funcionales de una computadora: CPU (Central Processing Unit), Memoria y
Unidades de E/S, es decir, se trata de un computador completo en un solo circuito integrado,
aunque de limitadas prestaciones. Se destina a gobernar una sola tarea con el programa que
reside en su memoria. Sus líneas de entrada/salida soportan el conexionado de los sensores y
actuadores del dispositivo a controlar.
Son diseñados para disminuir el coste económico y el consumo de energía de un sistema
en particular. Por eso el tamaño de la CPU, la cantidad de memoria y los periféricos incluidos
dependerán de la aplicación, por ejemplo: el control de un electrodoméstico sencillo utilizará
un procesador muy pequeño (4 u 8 bit) por que sustituirá a un autómata finito. En cambio un
reproductor de música y/o vídeo digital (mp3 o mp4) requerirá de un procesador de 32 bit o
de 64 bit.
Un microcontrolador típico tendrá un generador de reloj integrado y una pequeña
cantidad de memoria RAM y ROM/EPROM/EEPROM/FLASH, significando que para hacerlo
funcionar, todo lo que se necesita son unos pocos programas de control y un cristal de
sincronización. Los microcontroladores disponen generalmente también de una gran variedad
de dispositivos de entrada/salida, como convertidores de analógico a digital, temporizadores,
UARTs y buses de interfaz serie especializados, como CAN, SPI (Serial Peripheral Interface),
Ethernet, etcétera.
36
Figura 21: Esquema básico de un microcontrolador
37
Figura 22: Esquema de un microprocesador
38
2.4.2 Campos de aplicación de los
microcontroladores
39
2.4.3 El mercado de los microcontroladores
Industria
Automovilística
10%
Industria
Aplicaciones Informática
Industriales 30%
15%
Comunicaciones
20%
Aplicaciones de
consumo
25%
40
Los modernos microcontroladores de 32 bits van afianzando sus posiciones en el mercado,
siendo las áreas de más interés el procesamiento de imágenes, las comunicaciones, las
aplicaciones militares, los procesos industriales y el control de los dispositivos de
almacenamiento masivo de datos.
41
2.4.5 Componentes de un microcontrolador
42
2.4.5.2 La memoria
La principal utilidad de las líneas de E/S es comunicar al computador interno con los
periféricos exteriores. Según los controladores de periféricos que posea cada modelo de
microcontrolador, las líneas de E/S se destinan a proporcionar el soporte a las señales de
entrada, salida y control.
Algunos modelos disponen de recursos que permiten directamente esta tarea, entre los
que destacan:
UART (Universal Asynchronous Receiver Transmitter): adaptador de comunicación
serie asíncrona.
USART (Universal Synchronous/Asynchronous Receiver Transmitter): adaptador de
comunicación serie síncrona y asíncrona.
Puerta paralela esclava: para poder conectarse con los buses de otros
microprocesadores.
USB (Universal Serial Bus): bus moderno serie para los PC.
Bus I2C: interfaz serie de dos hilos desarrollado por Philips.
CAN: para permitir la adaptación con redes de conexionado multiplexado desarrollado
conjuntamente por Bosch e Intel para el cableado de dispositivos en automóviles.
Todos los microcontroladores disponen de un circuito oscilador que sincroniza todas las
operaciones del sistema. Generalmente, el circuito de reloj está incorporado en el
microcontrolador y sólo se necesitan unos pocos componentes exteriores para seleccionar y
estabilizar la frecuencia de trabajo.
46
de un byte. Los microcontroladores de 16 y 32 bits, debido a su elevado coste,
deben reservarse para aplicaciones que requieran altas prestaciones
(Entrada/Salida potente o espacio de direccionamiento muy elevado).
◦ Diseño de la placa: la selección de un microcontrolador concreto condicionará el
diseño de la placa de circuitos. Deberá tenerse en cuenta el encapsulado del
mismo, de los cuales podemos encontrar el encapsulado DIP o DIL. Este puede ser
cerámico (marrón) o de plástico (negro). Un dato importante en todos los
componentes es la distancia entre patillas que poseen, en los circuitos integrados
es de vital importancia este dato, así en este tipo el estándar se establece en 0,1
pulgadas (2,54mm). Se suelen fabricar a partir de 4, 6, 8, 14, 16, 22, 24, 28, 32, 40,
48, 64 patillas; estos son los que más se utilizan.
2.4.7.1 Implementaciones
47
2.4.7.2 Estructura de un nodo CAN
Dentro de un nodo CAN, se pueden distinguir una serie de módulos interconectados entre
ellos: un bus de direcciones, datos y un control (paralelo) enlazando el controlador central, la
memoria de los datos y el programa (donde está almacenado el software de aplicación y el
controlador de red de alto nivel), los dispositivos de entrada/salida y la interfaz de
comunicación.
Desde el punto de vista del controlador, la interfaz de comunicación se puede ver como un
conjunto de buzones, donde cada uno de estos sirve como registro lógico de interfaz entre el
controlador local y los nodos remotos. Si un nodo quiere comunicarse, tiene que dar de alta los
correspondientes buzones de recepción y transmisión antes de hacer ninguna operación.
48
estado de la transferencia se puede comprobar en el estatus de estado de
cada buzón.
Una vez hecha la configuración inicial a partir del software de la capa de aplicación de esta
manera, los nodos CAN funcionarán de forma autónoma.
Una de las características más importantes y útiles de CAN es su alta fiabilidad, incluso en
entornos de ruido extremos, el protocolo CAN proporciona una gran variedad de mecanismos
para detectar errores en las tramas. Esta detección de error es utilizada para retransmitir la
trama hasta que sea recibida con éxito.
Otro tipo de error es el de aislamiento, y se produce cuando un dispositivo no funciona
correctamente y un alto por ciento de sus tramas son erróneas. La detección de este error de
aislamiento impide que el mal funcionamiento de un dispositivo condicione el funcionamiento
del resto de nodos implicados en la red.
En el momento en que un dispositivo detecta un error en una trama, este dispositivo
transmite una secuencia especial de bits, el error flag. Cuando el dispositivo que ha
transmitido la trama errónea detecta el error flag, transmite la trama de nuevo.
Los dispositivos CAN detectan los errores siguientes:
Error de bit: durante la transmisión de una trama, el nodo que transmite monitoriza el
bus. Cualquier bit que reciba con polaridad inversa a la que ha transmitido se
considera un error de bit, excepto cuando se recibe durante el campo de arbitraje o en
el bit de reconocimiento. Además, no se considera error de bit la detección de bit
dominante por un nodo en estado de error pasivo que retransmite una trama de error
pasivo.
Error de relleno (Stuff Error): se considera error de relleno la detección de 6 bits
consecutivos del mismo signo, en cualquier campo que siga la técnica de relleno de
bits, donde por cada 5 bits iguales se añade uno diferente.
Error de CRC: se produce cuando el cálculo de CRC realizado por un receptor no
coincide con el recibido en la trama. El campo CRC contiene 15 bits y una distancia de
Hamming de 6, lo que asegura la detección de 5 bits erróneos por mensaje. Estas
medidas sirven para detectar errores de transmisión debido a posibles incidencias en
el medio físico como por ejemplo el ruido.
Error de forma (Form Error): se produce cuando un campo de formato fijo se recibe
49
alterado como bit.
Error de reconocimiento (Acknowledgement Error): se produce cuando ningún nodo
cambia a dominante el bit de reconocimiento.
Si un nodo advierte alguno de los fallos mencionados, iniciará la transmisión de una trama
de error. El protocolo CAN especifica diversos fallos en la línea física de comunicación, como
por ejemplo línea desconectada, problemas con la terminación de los cables o líneas
cortocircuitadas. Sin embargo, no especificará cómo reaccionar en caso de que se produzca
alguno de estos errores.
Para evitar que un nodo en problemas condicione el funcionamiento del resto de la red, se
han incorporado a la especificación CAN medidas de aislamiento de nodos defectuosos que
son gestionadas por los controladores. Un nodo puede encontrarse en uno de los tres estados
siguientes en relación a la gestión de errores:
Error Activo (Error Active): es el estado normal de un nodo. Participa en la
comunicación y en caso de detección de error envía una trama de error activa.
Error pasivo (Error Passive): un nodo en estado de error pasivo participa en la
comunicación, sin embargo ha de esperar una secuencia adicional de bits recesivos
antes de transmitir y sólo puede señalar errores con una trama de error pasiva.
Anulado (Bus Off): en este estado, deshabilitará su transceptor y no participará en la
comunicación.
La evolución entre estos estados se basa en dos contadores incluidos en el controlador de
comunicaciones, el Contador de Errores de Transmisión (TEC, Transmission Error Counter) y el
Contador de Errores de Recepción (REC, Reception Error Counter).
50
Figura 28 Diagrama de estados para el aislamiento de nodos defectuosos
51