Capítulo IIbibing.us.es/proyectos/abreproy/12219/fichero/Capítulo+2... · sensores/actuadores y...
49
3 Capítulo II Fundamentos teóricos 2. 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.
Transcript of Capítulo IIbibing.us.es/proyectos/abreproy/12219/fichero/Capítulo+2... · sensores/actuadores y...
3
Capítulo II
Fundamentos teóricos 2.
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.
4
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
Figura 1: Esquema típico de una red CAN
5
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.
Figura 2: Esquema de comunicaciones internas de SEAT Altea basado en Bus CAN
6
Existen varios buses CAN de diferentes velocidades, destinados a distintos grupos de
elementos del vehículo:
BUS VELOCIDAD MÁXIMA NODOS
TRACCIÓN
Alta (1Mbps)
Motor (ECU)
ABS
Dirección
Cambio
Airbag
CONFORT
Baja (125Kbps)
Cierre centralizado
Alarma
Climatizador
INFOTENIMIENTO Baja (125Kbps) Radio
Pantalla
CUADRO DE
INSTRUMENTOS Baja (125Kbps) Cuadro de instrumentos
DIAGNOSIS Media (500Kbps)
Baja (125Kbps)
Motor (ECU)
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 Protocolo CAN
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
7
“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.
8
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).
2.2.2 Estándar CAN 2.0
La especificación CAN (versión 2.0) de Bosch fue sometida a la estandarización
internacional a comienzos de los 90. Concretamente en Noviembre de 1993, después de
diversos conflictos políticos, se publicó el estándar ISO 11898, que definía además una capa
física para velocidades de hasta 1 Mbps. Paralelamente, un formato de CAN tolerante a fallos
se incluyó en la ISO 11519-2. En 1995, el estándar se amplió con la descripción del
identificador CAN de 29 bits.
Desafortunadamente, todas las especificaciones y estandarizaciones publicadas acerca de
CAN contenían errores o estaban incompletas. Para evitar incompatibilidades, Bosch se
cercioró, y sigue haciéndolo, de que todos los microcontroladores CAN cumplen con el modelo
de referencia que ellos definieron.
De todas formas, las especificaciones CAN han sido revisadas y estandarizadas con el
tiempo en diferentes secciones:
La norma ISO 11898-1 describe la capa de transmisión de datos CAN, la ISO 11898-2 la
capa física CAN no tolerante a fallos.
La ISO 11898-3 la capa física CAN tolerante a fallos.
Los estándares de ISO 11992 (referente a la interfaz para camiones y remolques).
9
ISO 11783 (referente a la maquinaria agrícola y forestal) definen los perfiles del uso de
CAN basados en el US-protocol J1939.
2.2.2.1 Arquitectura de capas
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.
2.2.2.1.1 Capa física
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.
10
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Ω.
Figura 3: Niveles de los buses en modo baja velocidad
Figura 4: Configuración del bus en baja velocidad
11
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.
Figura 5: Niveles de los buses en modo alta velocidad
Figura 6: Configuración del bus en alta velocidad
12
Formato de codificación y sincronización de datos
La codificación de bits se realiza por el método NRZ (Non-Return-to Zero) que se
caracteriza por que el nivel de señal puede permanecer constante durante largos periodos de
tiempo y habrá que tomar medidas para asegurarse de que el intervalo máximo permitido
entre dos señales no es superado. Esto es importante para la sincronización (Bit Timing).
Este tipo de codificación requiere poco ancho de banda para transmitir, pero en cambio,
no puede garantizar la sincronización de la trama transmitida. Para resolver esta falta de
sincronismo se emplea la técnica del bit stuffing: cada 5 bits consecutivos con el mismo estado
lógico en una trama (excepto del delimitador de final de trama y el espacio entre tramas), se
inserta un bit de diferente polaridad, no perdiéndose así la sincronización. Por otro lado este
bit extra debe ser eliminado por el receptor de la trama, que sólo lo utilizará para sincronizar la
transmisión.
No hay flanco de subida ni de bajada para cada bit, durante el tiempo de bit hay bits
dominantes (“0”) y recesivos (“1”) y disminuye la frecuencia de señal respecto a otras
codificaciones.
2.2.2.1.2 Capa de enlace 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:
Subcapa MAC (Medium Access Channel)
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
13
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.
14
Subcapa LLC (Logical Link Control)
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.
Figura 7: Arbitraje del Bus CAN
15
• 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
16
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:
o Inicio de trama (SOF, Start Of Frame): el inicio de trama es una celda de un
sólo bit siempre dominante que indica el inicio del mensaje, sirve para la
sincronización con otros nodos.
o Celda de Arbitraje (Arbitration Field): es la celda que contiene el identificador
del mensaje por lo que concede prioridad a unos mensajes o a otros:
En formato estándar tendrá 11 bits seguidos del bit RTR (Remote
Transmisión Request) que en este caso será dominante.
En formato extendido serán 11 bits de identificador base y 18 de
extendido. El bit SRR (Substitute Remote Request) substituye al RTR y será
recesivo. La trama en formato estándar prevalece sobre la extendida.
Figura 8: Formato de la trama de datos
17
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.
Figura 9: Formatos de la celda de arbitraje
18
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.
Si un nodo en estado de error "Activo" detecta un error en el bus interrumpe la
comunicación del mensaje en proceso generando un "Indicador de error activo" que consiste
en una secuencia de 6 bits dominantes sucesivos. Esta secuencia rompe la regla de relleno de
bits y provocará la generación de tramas de error en otros nodos. Por tanto el indicador de
Figura 10: Formato de la trama remota
Figura 11: Formato de la trama de error
19
error puede extenderse entre 6 y 12 bits dominantes sucesivos. Finalmente se recibe el campo
de delimitación de error formado por los 8 bits recesivos. Entonces la comunicación se reinicia
y el nodo que había sido interrumpido reintenta la transmisión del mensaje.
Si un nodo en estado de error "Pasivo" detecta un error, el nodo transmite un "Indicador
de error pasivo" seguido, de nuevo, por el campo delimitador de error. El indicador de error de
tipo pasivo consiste en 6 bits recesivos seguidos y, por tanto, la trama de error para un nodo
pasivo es una secuencia de 14 bits recesivos. De aquí se deduce que la transmisión de una
trama de error de tipo pasivo no afectará a ningún nodo en la red, excepto cuando el error es
detectado por el propio nodo que está transmitiendo. En ese caso los demás nodos detectarán
una violación de las reglas de relleno y transmitirán a su vez tramas de error.
Tras señalar un error por medio de la trama de error apropiada cada nodo transmite bits
recesivos hasta que recibe un bit también recesivo, luego transmite 7 bits recesivos
consecutivos antes de finalizar el tratamiento de error.
La regla de relleno de bits, consiste en que cada cinco bits de igual valor se introduce uno
de valor inverso tal y como se ve en la figura siguiente:
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.
Figura 12: Relleno de bits
20
La trama de sobrecarga consta de dos campos:
El indicador de sobrecarga (Overload Flag): consta de 6 bits dominantes que pueden
ser seguidos por los generados por otros nodos, dando lugar a un máximo de 12 bits
dominantes.
El delimitador de sobrecarga (Overload Delimiter): es de 8 bits recesivos y marca el
final de la trama de sobrecarga.
Espacio entre tramas
El espacio entre tramas separa una trama (de cualquier tipo) de la siguiente trama de
datos o interrogación remota. El espacio entre tramas ha de constar de, al menos, 3 bits
recesivos. Esta secuencia de bits se denomina intermission. Una vez transcurrida esta
secuencia un nodo en estado de error activo puede iniciar una nueva transmisión o el bus
permanecerá en reposo (manteniendo constante el nivel recesivo del bus).
Para un nodo en estado error pasivo la situación es diferente, deberá esperar una
secuencia adicional de 8 bits recesivos antes de poder iniciar una transmisión. De esta forma
se asegura una ventaja en inicio de transmisión a los nodos en estado activo frente a los nodos
en estado pasivo.
2.2.3 Características básicas del bus CAN
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:
Figura 13: Formato de la trama de sobrecarga
21
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
22
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:
Velocidad (Kbps) Tiempo de bit (µS) Longitud máxima Bus (m)
1000 1 30
800 1.25 50
500 2 100
250 4 250
125 8 500
50 20 1000
20 50 2500
10 100 5000
Tabla 2: Relación entre velocidad, tiempo de bit y longitud máxima del Bus CAN
Orientado a mensajes: se trata de un protocolo orientado a mensajes, y no a
direcciones, es decir, la información que se va a intercambiar se descompone en
mensajes, a los cuales se les asigna un identificador y son encapsulados en tramas para
su transmisión. Cada mensaje tiene un identificador único dentro de la red, a partir del
cual los nodos deciden aceptar o no dicho mensaje. Además están priorizados.
Multidifusión (multicast): permite que todos los nodos puedan acceder al bus de
forma simultánea con sincronización de tiempos.
Medio compartido (broadcasting): la información es enviada en la red a todos los
destinos de forma simultánea. Así que los destinos habrán de saber si la información
les concierne o deben rechazarla.
Detección y señalización de errores: CAN posee una gran capacidad de detección de
errores, tanto temporales, como permanentes, lograda a través de cinco mecanismos
de detección, 3 al nivel de mensaje y 2 a nivel de bit. Los errores además pueden ser
señalizados.
Retransmisión automática de tramas erróneas: junto a la detección y señalización de
errores la retransmisión automática de tramas erróneas aporta la integridad de los
datos. Además ambos procesos son transparentes al usuario.
Jerarquía multimaestro: CAN es un sistema multimaestro en el cual puede haber más
de un maestro (master) al mismo tiempo y sobre la misma red, es decir, todos los
23
nodos son capaces de transmitir, hecho que permite construir sistemas inteligentes y
redundantes.
2.2.4 Otras Tecnologías
Realmente CAN se encuentra en una posición privilegiada en el mercado. El siguiente
gráfico traza una comparativa entre diferentes tecnologías respecto al coste por nodo:
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:
Figura 14: Comparativa de tecnologías respecto al coste por nodo
24
CARACTERÍSTICA CAN LIN I2C
COMPAÑÍA
DESARROLLADORA
Bosch Open Source Phillips
VELOCIDAD
MÁXIMA
1Mbps 20Kbps 0.1Mbps /
0.4Mbps
TAMAÑO DE
DATOS
64 bits 8 bits 8 bits
PRIORIDAD DE
MENSAJES
Sí No No
GARANTÍA DE
LATENCIA
Sí No No
FLEXIBILIDAD EN
LA CONFIGURACIÓN
Sí No Sí
SISTEMA
MULTIMAESTRO
Sí No Sí
DETECCIÓN Y
SEÑALIZACIÓN DE
ERRORES
Sí
Sí
Sí
RETRANSMISIÓN
DE TRAMAS
Automática No Programable
Tabla 3: Comparativa entre Bus CAN, I2C y LIN
Dentro de la industria automovilística por ejemplo, CAN es empleado como bus de
comunicaciones para los elementos más importantes de este, que van a requerir una
seguridad y velocidad mayores. Para otro tipo de vicisitudes, como los elevalunas eléctricos
por ejemplo, que tienen mucha menos importancia que la que puedan tener los frenos o el
estado del motor, se emplea el bus LIN.
Vemos en la siguiente figura una posible configuración en la que conviven CAN y LIN en un
mismo vehículo:
25
2.2.5 Campos de aplicación y futuro
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:
Figura 15: Arquitectura de buses CAN y LIN en un mismo vehículo
26
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.
Figura 16: Arquitectura clásica de Bus CAN en un automóvil
27
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.
2.3 Protocolo OBDII
Durante los años 70 y principios de los 80 algunos fabricantes empezaron a usar
componentes electrónicos de control y diagnóstico de errores en sus automóviles. Al principio
fue solo para conocer y controlar las emisiones del vehículo y adaptarlas a los estándares
exigidos, pero con el paso del tiempo estos sistemas fueron volviéndose cada vez más
sofisticados.
Para reducir la contaminación del aire, la CARB (California Air Resources Board) determinó
en 1988 que todos los automóviles a gasolina contaran con OBD, para controlar los límites
máximos de emisiones.
Medidas más estrictas en los límites de emisiones en 1996 llevó a la creación del estándar
OBDII. Este sistema permite diagnosticar los errores que se producen en el vehículo sin
necesidad de desmontar partes para descubrir la procedencia de dicho error. A diferencia de
otros sistemas desarrollados antes de 1996, OBDII se caracteriza por ser un sistema
estandarizado, que permite, de manera fácil, ver qué errores se han producido en un vehículo
cualquiera utilizando una única codificación y claro está, un conector estandarizado.
En Europa se introdujo el OBD ajustándose al OBDII americano. Desde 1996 el estándar
OBDII es un requisito legal para automóviles nuevos en Estados Unidos. En base a esta regla
americana se impuso en los noventa la inclusión de sistemas de diagnóstico también para los
automóviles destinados al mercado europeo. Según la Directiva 98/69EG, creada por la Unión
Europea, los automóviles a gasolina del año 2000 en adelante, los diésel de 2003 en adelante,
y los camiones de 2005 en adelante tienen que estar provistos de un sistema OBD.
La siguiente etapa planeada es el OBDIII, en el que los propios automóviles se comunican
con las autoridades si se produce un empeoramiento de las emisiones de gases nocivos
mientras está en marcha. Si esto sucede, se pedirá a través de una tarjeta indicativa, que se
corrijan los defectos.
Actualmente se emplean los estándares que se emplean son:
OBDII en Estados Unidos.
EOBD en Europa.
JOBD en Japón.
28
2.3.1 Funciones de OBDII
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.
29
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
30
sonda se determina en función de la velocidad de reacción de la misma, que es mayor cuanto
más deteriorada se encuentre.
2.3.2 OBDII y CAN
El estándar OBDII implementa 5 posibles protocolos en su capa física:
SAE J1850 PWM: protocolo de diagnóstico usado mayormente en vehículos Ford.
Usa señales diferenciales y tiene una velocidad de transferencia de 41,6kB/s.
ISO 9141/14230: antiguo protocolo usado en vehículos europeos entre 2000 y
2004.
SAE J1850 VPW: protocolo de diagnóstico usado en los vehículos de General
Motors. Tiene una velocidad de comunicación de 10,4kB/s.
ISO14230-4 (KWP2000): protocolo muy común en vehículos a partir de 2003.
Básicamente se utiliza para la diagnosis off-board de centralitas electrónicas de
vehículos y para cargar en las mismas versiones nuevas de software, lo que se
conoce como reprogramar o "flashear" También funciona a una velocidad de
10,4kB/s.
ISO 15765 (CAN): el protocolo CAN para el bus de diagnóstico comenzó a estar
presente en vehículos desde 2003. A partir de 2008 es obligatorio en los vehículos
estadounidenses. Se pueden usar cuatro variantes de este protocolo, entre ellas
difieren en la longitud de los datos y la velocidad de transmisión:
ISO 15765-4 CAN (11 bit ID, 500 Kbps).
ISO 15765-4 CAN (29 bit ID, 500 Kbps).
ISO 15765-4 CAN (11 bit ID, 250 Kbps).
ISO 15765-4 CAN (29 bit ID, 250 Kbps).
2.3.3 Detección de errores con OBDII
Como ya se ha comentado el sistema OBDII, es el encargado de almacenar los códigos de
los errores que se generan en el vehículo, pero no solo almacena el error, sino que lo almacena
de tal manera, que su lectura, indique donde se ha producido el error y facilite el trabajo de
reparación.
31
Las decenas de unidades de control que hay repartidas en el vehículo, son las encargadas
de interpretar todas las informaciones que generan los sensores, velocidades, caudales,
presiones, etcétera, y gracias a estas informaciones, actúan sobre los componentes del
vehículo que regularan el funcionamiento de este.
La cantidad de información con la que se trabaja, y la situación de dichas unidades de
control en el vehículo, hace imposible escanear uno por uno las diferentes unidades de control
para buscar el origen del error de funcionamiento. Para ello se usa OBDII, cuando alguna
unidad de control, recibe una señal anómala, informa al resto del sistema, y OBDII es el
encargado de avisar al conductor de que se ha producido un error y almacenarlo.
Por tanto, se ha de dejar claro que no es el sistema OBDII el encargado de detectar los
errores, sino, simplemente es el encargado de informar y almacenar los errores detectados por
el resto de unidades de control y facilitar el acceso a estos.
2.3.4 Acceso a la información del sistema OBDII
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
32
La comunicación entre la Unidad de Control (ECU) y equipo de diagnosis se establece
mediante un protocolo. Como se puede apreciar en la figura hay tres protocolos, cada uno con
variaciones de pequeña importancia en el patrón de la comunicación con la unidad de mando
y con el equipo de diagnosis, Bus CAN, ISO 9141 y SAE J1850.
Figura 17: Pines del conector OBDII
Figura 18: Cable OBDII
33
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.
34
2.3.4.3 Códigos de error
Los códigos también están estandarizados y deben seguir el esquema siguiente.
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.
2.3.4.4 Software necesario
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
Figura 19: Códigos de diagnóstico en OBDII
35
OBD 2007
VitalScan 1.3
2.3.4.5 Otros sistemas de lectura
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.
Figura 20: Sistemas de lectura de códigos OBDII
36
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.
37
2.4.1 Diferencias entre microprocesador y microcontrolador
El microprocesador es un dispositivo integrado digital capaz de interpretar y ejecutar un
conjunto secuencial de instrucciones (programa). Básicamente contiene circuitos electrónicos
que realizan operaciones aritméticas, lógicas y de control. Los microprocesadores no trabajan
solos, sino que forman parte de un sistema mayor. Los pines de un microprocesador sacan al
exterior las líneas de sus buses de direcciones, datos y control, para permitir conectarle con la
Memoria y los Módulos de E/S y configurar un computador implementado por varios circuitos
integrados. Se dice que un microprocesador es un sistema abierto porque su configuración es
variable de acuerdo con la aplicación a la que se destine.
Figura 21: Esquema básico de un microcontrolador
38
La disponibilidad de los buses en el exterior permite que se configure a la medida de la
aplicación. Si sólo se dispusiese de un modelo de microcontrolador, éste debería tener muy
potenciados todos sus recursos para poderse adaptar a las exigencias de las diferentes
aplicaciones. En la práctica cada fabricante de microcontroladores oferta un elevado número
de modelos diferentes, desde los más sencillos hasta los más poderosos. Es posible seleccionar
la capacidad de las memorias, el número de líneas de E/S, la cantidad y potencia de los
elementos auxiliares, la velocidad de funcionamiento, etc. Por todo ello, un aspecto muy
destacado del diseño es la selección del microcontrolador a utilizar.
El microcontrolador es un sistema cerrado. Todas las partes del computador están
contenidas en su interior y sólo salen al exterior las líneas que gobiernan los periféricos.
Figura 22: Esquema de un microprocesador
Figura 23: Esquema de un microcontrolador
39
2.4.2 Campos de aplicación de los microcontroladores
Las áreas de aplicación de los microcontroladores se pueden considerar ilimitadas, los
podemos encontrar en:
Electrodomésticos: microondas, refrigeradores, hornos, televisores, equipos de
sonido, teléfonos, etcétera.
Equipos informáticos: impresoras, módems, unidades de disco, ratones, teclados,
etcétera.
Domótica: sistemas antirrobo, climatizadores, ascensores, alarmas, etcétera.
Instrumentación: aparatos de medida y representación.
Automóviles: ABS, sistemas de inyección y encendido, climatizador, etcétera.
Un ejemplo de aplicación de un microcontrolador en un automóvil es el siguiente:
Figura 24: Microcontrolador en el automóvil
40
Industria Informática
30%
Aplicaciones de consumo
25%
Comunicaciones 20%
Aplicaciones Industriales
15%
Industria Automovilística
10%
2.4.3 El mercado de los microcontroladores
Existe gran variedad de microcontroladores, de 4, 8, 16 o 32 bits. Aunque cabría pensar
que los microcontroladores de 16 y 32 bits copan el mercado debido a que sus prestaciones
son superiores a los de 4 y 8 bits, la realidad es que los microcontroladores de 8 bits dominan
el mercado y los de 4 bits aún están muy presentes. La razón de esta tendencia es que los
microcontroladores de 4 y 8 bits son apropiados para la gran mayoría de las aplicaciones, lo
que hace absurdo emplear microcontroladores más potentes y consecuentemente más caros.
Uno de los sectores que más hace uso del microcontrolador es el mercado automovilístico. De
hecho, algunas de las familias de microcontroladores actuales se desarrollaron pensando en
este sector, siendo modificadas posteriormente para adaptarse a sistemas más genéricos. El
mercado del automóvil es además uno de los más exigentes en cuanto a fiabilidad, los
componentes electrónicos deben operar bajo condiciones extremas de vibraciones,
temperatura, ruido, etcétera. En cuanto a las técnicas de fabricación, cabe decir que
prácticamente la totalidad de los microcontroladores actuales se fabrican con tecnología
CMOS 4 (Complementary Metal Oxide Semiconductor). Esta tecnología supera a las técnicas
anteriores por su bajo consumo y alta inmunidad al ruido. La distribución de las ventas de
microcontroladores según su aplicación es la siguiente:
Tabla 4: Ventas de microcontroladores según su aplicación
41
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.
2.4.4 Arquitectura básica
Inicialmente todos los microcontroladores adoptaron la arquitectura clásica de Von
Neumann. Esta arquitectura se caracteriza por disponer de una sola memoria principal donde
se almacenan datos e instrucciones de forma indistinta. A dicha memoria se accede a través de
un sistema de buses único (direcciones, datos y control).
Hoy en día los microcontroladores se diseñan, por lo general, de acuerdo a la arquitectura
Harvard. Esta arquitectura dispone de dos memorias independientes una, que contiene sólo
instrucciones y otra, sólo datos. Ambas disponen de sus respectivos sistemas de buses y es
posible realizar operaciones de acceso (lectura o escritura) simultáneamente en ambas
memorias.
Figura 25: Arquitectura de Von Neumann
Figura 26: Arquitectura Harvard
42
2.4.5 Componentes de un microcontrolador
2.4.5.1 El procesador o CPU
Es el elemento más importante del microcontrolador y determina sus principales
características, tanto a nivel hardware como software. Se encarga de direccionar la memoria
de instrucciones, recibir la instrucción en curso, su decodificación y la ejecución de la
operación que implica dicha instrucción, así como la búsqueda de los operandos y el
almacenamiento del resultado.
Existen tres orientaciones en cuanto a la arquitectura y funcionalidad de los procesadores
actuales:
CISC (Complex Instruction Set Computer): Un gran número de procesadores usados en
los microcontroladores están basados en la filosofía CISC. Disponen de más de 80
instrucciones máquina en su repertorio, algunas de las cuales son muy sofisticadas y
potentes, requiriendo muchos ciclos para su ejecución. Una ventaja de los
procesadores CISC es que ofrecen al programador instrucciones complejas que actúan
como macros.
RISC (Reduced Instruction Set Computer): Tanto la industria de los computadores
comerciales como la de los microcontroladores están decantándose hacia la filosofía
RISC. En estos procesadores el repertorio de instrucciones máquina es muy reducido y
las instrucciones son simples y, generalmente, se ejecutan en un ciclo. La sencillez y
rapidez de las instrucciones permiten optimizar el hardware y el software del
procesador.
SISC (Simple Instruction Set Computing): En los microcontroladores destinados a
aplicaciones muy concretas, el juego de instrucciones, además de ser reducido, es
específico, es decir, las instrucciones se adaptan a las necesidades de la aplicación
prevista.
43
2.4.5.2 La memoria
En los microcontroladores la memoria de instrucciones y datos está integrada en el propio
chip. Una parte debe ser no volátil, tipo ROM (Read-Only Memory), y se destina a contener el
conjunto de instrucciones que ejecuta la aplicación. Otra parte de memoria es del tipo RAM
(Random Access Memory), volátil, y se destina a guardar las variables y los datos. Según el tipo
de memoria ROM que dispongan los microcontroladores, la aplicación y utilización de los
mismos es diferente. Las cinco versiones de memoria no volátil que se pueden encontrar en
los microcontroladores del mercado son:
ROM con máscara: es una memoria no volátil de sólo lectura cuyo contenido se graba
durante la fabricación del chip. El elevado coste del diseño de la máscara sólo hace
aconsejable el empleo de los microcontroladores con este tipo de memoria cuando se
precisan grandes cantidades de los mismos.
OTP (One Time Programmable): es una memoria no volátil de sólo lectura
programable una sola vez por el usuario. La versión OTP es recomendable cuando la
tirada del producto es baja, o bien, en la construcción de prototipos y series muy
pequeñas.
EPROM (Erasable Programmable Read OnIy Memory): los microcontroladores que
disponen de memoria EPROM pueden borrarse y grabarse muchas veces. Si se desea
borrar el contenido, disponen de una ventana de cristal en su superficie por la que se
somete a la EPROM a rayos ultravioleta durante varios minutos. Las cápsulas son de
material cerámico y son más caros que los microcontroladores con memoria OTP que
están hechos generalmente con plástico.
EEPROM (Electrical Erasable Programmable Read OnIy Memory): se trata de
memorias de sólo lectura, programables y borrables eléctricamente. No disponen de
ventana de cristal en la superficie. Los microcontroladores dotados de memoria
EEPROM una vez instalados en el circuito, pueden grabarse y borrarse cuantas veces
se quiera sin ser retirados de dicho circuito. Para ello se usan grabadores en circuito,
que confieren una gran flexibilidad y rapidez a la hora de realizar modificaciones en el
programa de trabajo. El número de veces que puede grabarse y borrarse una memoria
EEPROM es finito, por lo que no es recomendable una a reprogramación continua. Este
tipo de memoria es relativamente lenta.
FLASH: se trata de una memoria no volátil, de bajo consumo, que se puede escribir y
borrar, es programable en el circuito, es más rápida que la EEPROM y tolera más ciclos
de escritura/borrado.
44
2.4.5.3 Puertos de Entrada/Salida
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.
2.4.5.4 Reloj principal
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.
2.4.5.5 Recursos auxiliares
Cada fabricante oferta numerosas versiones de una arquitectura básica de
microcontrolador. En algunas amplía las capacidades de las memorias, en otras incorpora
nuevos recursos, en otras reduce las prestaciones al mínimo para aplicaciones muy simples,
etcétera. La labor del diseñador es encontrar el modelo mínimo que satisfaga todos los
requerimientos de su aplicación. De esta forma, minimizará el coste, el hardware y el software.
45
Los principales recursos específicos que incorporan los microcontroladores son:
Temporizadores (Timers): se emplean para controlar periodos de tiempo
(temporizadores) y para llevar la cuenta de acontecimientos que suceden en el
exterior (contadores).
Perro guardián (Watchdog): temporizador que cuando se bloquea el sistema, provoca
un reset automáticamente.
Protección ante fallo de alimentación (Brownout): se trata de un circuito que resetea
al microcontrolador cuando el voltaje de alimentación (VDD) es inferior a un voltaje
mínimo.
Estado de reposo o de bajo consumo: para ahorrar energía cuando el
microcontrolador no está funcionando, éstos disponen de una instrucción especial que
les pasa al estado de reposo o de bajo consumo, en el cual los requerimientos de
potencia son mínimos. Al activarse una interrupción ocasionada por el acontecimiento
esperado, el microcontrolador se despierta y reanuda su trabajo.
Conversor A/D (CAD): los microcontroladores que incorporan un conversor A/D
pueden procesar señales analógicas.
Conversor D/A (CDA): transforma los datos digitales obtenidos del procesamiento del
computador en su correspondiente señal analógica.
Comparador analógico: algunos modelos de microcontroladores disponen
internamente de un Amplificador Operacional que actúa como comparador entre una
señal fija de referencia y otra variable. La salida del comparador proporciona un nivel
lógico 1 ó 0 según una señal sea mayor o menor que la otra.
Modulador de anchura de impulsos PWM (Pulse-Width Modulation): son circuitos
que proporcionan en su salida impulsos de anchura variable y se utilizan en diversas
aplicaciones como por ejemplo el control de motores eléctricos o generadores.
2.4.6 Consideraciones en la elección del microcontrolador
A la hora de escoger el microcontrolador a emplear hay que tener en cuenta multitud de
factores, como la documentación y herramientas de desarrollo disponibles, su precio, la
cantidad de fabricantes que lo producen y por supuesto las características del
microcontrolador (tipo de memoria de programa, número de temporizadores, interrupciones,
etc.):
46
Costes: Para el fabricante que usa el microcontrolador en su producto una diferencia
de precio en el microcontrolador de algunos céntimos es importante (el consumidor
deberá pagar además el coste del empaquetado, el de los otros componentes, el
diseño del hardware y el desarrollo del software). Si el fabricante desea reducir costes
debe tener en cuenta las herramientas de apoyo con que va a contar: emuladores,
simuladores, ensambladores, compiladores, etcétera. Es habitual que muchos de ellos
siempre se decanten por microcontroladores pertenecientes a una única familia.
Aplicación: Antes de seleccionar un microcontrolador es imprescindible analizar los
requisitos de la aplicación:
Procesamiento de datos: puede ser necesario que el microcontrolador realice
cálculos críticos en un tiempo limitado. En ese caso debemos asegurarnos de
seleccionar un dispositivo suficientemente rápido para ello. Por otro lado, habrá
que tener en cuenta la precisión de los datos a manejar: si no es suficiente con un
microcontrolador de 8 bits, puede ser necesario acudir a microcontroladores de 16
o 32 bits, o incluso a hardware de coma flotante.
Entrada/Salida: para determinar las necesidades de Entrada/Salida del sistema es
conveniente conocer el diagrama de bloques del mismo, de tal forma que sea
sencillo identificar la cantidad y tipo de señales a controlar. Una vez realizado este
análisis puede ser necesario añadir periféricos externos o cambiar a otro
microcontrolador más adecuado a ese sistema.
Consumo: algunos productos que incorporan microcontroladores están
alimentados con baterías. Lo más conveniente en un caso como éste puede ser
que el microcontrolador esté en estado de bajo consumo pero que despierte ante
la activación de una señal (una interrupción) y ejecute el programa adecuado para
procesarla.
Memoria: El tipo de memoria a emplear vendrá determinado por el volumen de
ventas previsto del producto: de menor a mayor volumen será conveniente
emplear EPROM, OTP y ROM. En cuanto a la cantidad de memoria necesaria
deberemos hacer una estimación de cuánta memoria volátil y no volátil es
necesaria y si es conveniente disponer de memoria no volátil modificable.
Ancho de palabra: el criterio de diseño debe ser seleccionar el microcontrolador
de menor ancho de palabra que satisface los requerimientos de la aplicación. Usar
un microcontrolador de 4 bits supondrá una reducción en los costes importante,
mientras que uno de 8 bits puede ser el más adecuado si el ancho de los datos es
47
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 Microcontroladores CAN
2.4.7.1 Implementaciones
Existen tres tipos de arquitecturas en microcontroladores: Stand-Alone CAN controller,
Integrated CAN Controller y Single-Chip CAN Node.
Stand-Alone CAN Controller: es la arquitectura más simple, para llevar a cabo una
comunicación en una red CAN, será necesario:
a) Un microcontrolador.
b) Un controlador CAN que introduzca el protocolo CAN, filtro de mensajes,… y
todo el interface necesario para las comunicaciones.
c) Un transceiver o transceptor CAN, esto es, un transmisor/receptor CAN.
Integrated CAN Controller: este tipo de arquitectura consiste en un microcontrolador
que incluya, no sólo sus características propias sino además un módulo CAN con las
características de un microcontrolador CAN. El transceiver se sitúa de manera
separada. El módulo del transceptor actúa como un controlador de línea, balanceando
la señal, esto es, adecuando los niveles de tensión de esta al exterior.
Single-chip CAN Node: se trata de un chip que incluye en su interior los tres elementos
necesarios para llevar a cabo las comunicaciones en un entorno CAN.
48
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.
Teniendo en cuenta esta arquitectura, el funcionamiento sigue los siguientes pasos:
1. Para inicializar, el programador especifica los parámetros de los registros de
control de interfaz de comunicación, como las características del controlador
de red o la velocidad de transmisión.
2. A continuación, se actualizan todos los buzones. En cada buzón se especifica si
es receptor o transmisor y su estado inicial, inicializando su parte de datos del
búfer.
3. Posteriormente, para transmitir un mensaje es necesario poner los datos en el
búfer de datos correspondiente al buzón de transmisión y activar el flanco de
transmisión.
4. Por último, la interfaz de red intenta comunicar los datos a través de la red. El
Figura 27: Arquitectura básica de un nodo CAN
49
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.
2.4.7.3 Detección de Errores
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
50
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.
2.4.7.4 Aislamiento de nodos defectuosos
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).
51
Figura 28 Diagrama de estados para el aislamiento de nodos defectuosos
