Capítulo II. Fundamentos teóricos

Transcripción

1 Capítulo II 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 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. Figura 1: Esquema típico de una red CAN 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 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

3 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 5

4 Existen varios buses CAN de diferentes velocidades, destinados a distintos grupos de elementos del vehículo: BUS VELOCIDAD MÁXIMA NODOS Motor (ECU) ABS TRACCIÓN CONFORT INFOTENIMIENTO CUADRO DE INSTRUMENTOS DIAGNOSIS Alta (1Mbps) Baja (125Kbps) Baja (125Kbps) Baja (125Kbps) Media (500Kbps) Baja (125Kbps) Dirección Cambio Airbag Cierre centralizado Alarma Climatizador Radio Pantalla Cuadro de instrumentos 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 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

5 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 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

6 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 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) 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 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 describe la capa de transmisión de datos CAN, la ISO la capa física CAN no tolerante a fallos. La ISO la capa física CAN tolerante a fallos. Los estándares de ISO (referente a la interfaz para camiones y remolques). 8

7 ISO (referente a la maquinaria agrícola y forestal) definen los perfiles del uso de CAN basados en el US-protocol J 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 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 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 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

8 Estándar ISO (baja velocidad) Figura 3: Niveles de los buses en modo 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: R TH para la señal CAN_H y R TL 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 Ω. Figura 4: Configuración del bus en baja velocidad 10

9 Estándar ISO (alta velocidad) Figura 5: Niveles de los buses en modo 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 6: Configuración del bus en alta velocidad 11

10 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 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 12

11 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 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

12 Figura 7: Arbitraje del Bus CAN 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. 14

13 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

14 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: Figura 8: Formato de la trama de datos o 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. 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. 16

15 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

16 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. Figura 11: Formato de la trama de 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 18

17 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: Figura 12: Relleno de bits 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

18 Figura 13: Formato de la trama de sobrecarga 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 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, profundizará en dichas características para obtener una visión más concreta: se 20

19 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 , y una red de baja velocidad tolerante a fallos (menor o igual a 125 Kbps) definida por la ISO Relación velocidad-distancia: al punto anterior habría que añadir que la velocidad 21

20 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) 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 22

21 nodos son capaces de transmitir, hecho que permite construir sistemas inteligentes y redundantes 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: Figura 14: Comparativa de 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: 23

22 CARACTERÍSTICA CAN LIN I2C COMPAÑÍA DESARROLLADORA VELOCIDAD MÁXIMA TAMAÑO DE DATOS PRIORIDAD DE MENSAJES GARANTÍA DE LATENCIA FLEXIBILIDAD EN LA CONFIGURACIÓN SISTEMA MULTIMAESTRO DETECCIÓN Y SEÑALIZACIÓN DE ERRORES RETRANSMISIÓN DE TRAMAS Bosch Open Source Phillips 1Mbps 20Kbps 0.1Mbps / 0.4Mbps 64 bits 8 bits 8 bits Sí No No Sí No No Sí No Sí Sí No Sí Sí Sí Sí 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: 24

23 Figura 15: Arquitectura de buses CAN y LIN en un mismo vehículo 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: 25

24 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

25 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. 27

26 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. 28

27 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

28 sonda se determina en función de la velocidad de reacción de la misma, que es mayor cuanto más deteriorada se encuentre 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 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. ISO (KWP2000): protocolo muy común en vehículos a partir de 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 (CAN): el protocolo CAN para el bus de diagnóstico comenzó a estar presente en vehículos desde 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 CAN (11 bit ID, 500 Kbps). ISO CAN (29 bit ID, 500 Kbps). ISO CAN (11 bit ID, 250 Kbps). ISO CAN (29 bit ID, 250 Kbps) 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. 30

29 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 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 El conector El conector del sistema OBDII tiene que cumplir las siguientes especificaciones según la normativa, ISO :

30 Figura 17: Pines del conector OBDII Figura 18: Cable OBDII 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 J

31 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

32 Códigos de error Los códigos también están estandarizados y deben seguir el esquema siguiente. Figura 19: Códigos de diagnóstico en OBDII 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 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

33 OBD 2007 VitalScan 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 35

34 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

35 Figura 21: Esquema básico de un microcontrolador 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. 37

36 Figura 22: Esquema de un microprocesador 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. Figura 23: Esquema de un microcontrolador 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. 38

37 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 39

38 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: Industria Automovilística 10% Aplicaciones Industriales 15% Industria Informática 30% Comunicaciones 20% Aplicaciones de consumo 25% Tabla 4: Ventas de microcontroladores según su aplicación 40

39 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 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). Figura 25: Arquitectura de Von Neumann 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 26: Arquitectura Harvard 41

40 2.4.5 Componentes de un microcontrolador 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. 42

41 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. 43

42 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 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 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. 44

43 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 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.): 45

44 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 46

45 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 Microcontroladores CAN 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. 47

46 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. Figura 27: Arquitectura básica de un nodo CAN 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 48