desarrollo de una aplicación para el ordenador de a...

Desarrollo de una aplicación para el ordenador de a bordo de un vehículo eléctrico

1

Grado en Ingeniería de las Tecnologías de

Telecomunicación

Autor: Laura Cabezas Bartolomé Tutor: Jesús Sánchez García Ponente: Federico Barrero García

Dep. Ingeniería Electrónica Escuela Técnica Superior de Ingeniería

Universidad de Sevilla Sevilla, 2017

Desarrollo de una aplicación para el ordenador de a bordo de un vehículo eléctrico para la lectura de datos de una ECU


3

Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación

Título del proyecto Desarrollo de una aplicación para el ordenador

de a bordo de un vehículo eléctrico para la lectura de datos de una ECU

Autor:

Laura Cabezas Bartolomé

Tutor: Jesús Sánchez García

Ponente:

Federico Barrero García

Depto. Ingeniería Electrónica Escuela Técnica Superior de Ingeniería

Universidad de Sevilla Sevilla, 2017


5

Trabajo Fin de Grado: Desarrollo de una aplicación para el ordenador de a bordo de un vehículo eléctrico para la lectura de datos de una ECU

El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:

Presidente:

Vocales:

Secretario:

Acuerdan otorgarle la calificación de:

El Secretario del Tribunal

Fecha:

Autor: Laura Cabezas Bartolomé Tutor: Jesús Sánchez García Ponente: Federico Barrero García

6

Sobre el autor

Laura Cabezas Bartolomé [email protected]

Grado en Ingeniería de las Tecnologías de Telecomunicación Universidad de Sevilla


7

AGRADECIMIENTOS La realización de este trabajo no hubiese sido posible sin la ayuda y apoyo de todas las personas que, de una forma u otra, han participado en este proyecto.

Primero agradecer a Federico Barrero por darme la oportunidad de realizar este trabajo. Pero en especial agradecer a Jesús Sánchez por su paciencia conmigo (que no ha sido poca) y por todo el apoyo y ayuda que me ha proporcionado, dándome ánimos y soluciones en los momentos en los que yo no veía las cosas claras.

No querría dejar de agradecer a mis amigos y grandes compañeros, tanto los que se quedaron por el camino como los que sé que mantendré durante muchos años, y en especial a los que siempre están ahí.

Por último, y no menos importante a mi familia, a mis padres Maribel y Javier, que sin su apoyo nada de lo que he conseguido a día de hoy hubiese sido posible, a mis hermanas tanto de sangre como de otra madre, Isabel y Ana, a mi novio Luis, que llegó en el momento más adecuado.

Y aunque en un agradecimiento lo más común es nombrar a las personas más importantes en nuestro día a día, me siento obligada a mencionar a mis dos perros, Thara y Klaus, quienes me han animado con su presencia en los momentos más duros de esta etapa.

8

RESUMEN Debido a la necesidad de conocer el estado del vehículo en tiempo real, a lo largo del tiempo se han ido creando distintos sistemas de diagnóstico. Estos sistemas nos permiten obtener diversa información del vehículo tal y como velocidad, temperatura, nivel de emisión de C02, consumo, batería, etc., además de los códigos de error que se generen.

De esta forma, la finalidad de este Trabajo de Fin de Grado es realizar una aplicación capaz de mostrar al usuario toda esa información que se solicita de un vehículo. Para ello es necesario dedicar un capítulo al estudio teórico, el cual se centra en uno de los sistemas de diagnóstico específicos más importantes, los que están basados en el protocolo OBD-II sobre BUS CAN. Este capítulo proporcionará las nociones teóricas necesarias para comprender la necesidad y desarrollo de la aplicación propuesta.

Este trabajo se apoya en trabajos previos realizados por otros compañeros de la carrera, aportando una interfaz que permite visualizar e interaccionar con el sistema de diagnóstico de un vehículo. Por lo tanto, este proyecto contribuye directamente a un proyecto más grande centrado en el desarrollo de un sistema de comunicaciones completo para un vehículo eléctrico. Uno de estos proyectos anteriores sobre el que se apoya este trabajo es un sistema electrónico simulador de una ECU. La aplicación desarrollada en este trabajo, nombrada como eCo Application, será la encarga de mostrar en una interfaz toda la información del sistema de diagnóstico OBD-II implementado en este simulador de una ECU.

La aplicación ha sido desarrollada sobre el entorno de desarrollo Microsoft Visual Studio 2015, bajo el lenguaje de programación C++, haciendo uso del Framework .NET de Microsoft.


9

ABSTRACT Due to the need to analyze in real-time the state of the vehicle, through the years, different diagnostic systems have been created. Those systems permit us to obtain vehicle’s information such as speed, temperature, C02, battery status, etc., including generated error codes.

In this way, the aimed of this Work Order Degree is developing an application which allows users been showed such information. This requires dedicating a chapter to theoretical study which is focused in one of the most important on-board diagnostic systems based in OBD-II protocol over BUS CAN. This application is based on other previous fellow student’s works. It adds an interface which display information and allows users interacting with on-board diagnostic systems. Thus, this work contributes directly with a bigger project centered on development of an electrical vehicle’s integral communication system. One of this previously projects developed an ECU simulator. Application developed in this work, named as eCo Application, will be responsible of showing on-board diagnostic system information OBD-II implemented in this ECU simulator. Application has been developed within the integrated development environment Microsoft Visual Studio 2015, programming in C++, using Microsoft .NET Framework.

10

INDICE

AGRADECIMIENTOS....................................................................................................................7RESUMEN....................................................................................................................................8ABSTRACT....................................................................................................................................9INDICE........................................................................................................................................10INDICEDEFIGURAS...................................................................................................................12INDICEDETABLAS.....................................................................................................................13NOTACIÓN.................................................................................................................................14

1. IntroducciónyObjetivos..........................................................................................171.1 Introducción.....................................................................................................................181.2 Objetivos..........................................................................................................................18

2. FundamentosTeóricos.............................................................................................192.1 Comunicacionesinternasdelvehículo............................................................................202.2 BusCAN............................................................................................................................20

2.2.1 Historia........................................................................................................................................212.2.2 ElementosdelbusCAN..............................................................................................................222.2.3 Característicasprincipales..........................................................................................................232.2.4 ArquitecturadeCapas................................................................................................................24

2.2.4.1CapaFísica................................................................................................................................252.2.4.2CapadeEnlace.........................................................................................................................29

2.2.5 Tiposdetramas...........................................................................................................................312.2.5.1 Tramadedatos..................................................................................................................312.2.5.2 Tramaremota....................................................................................................................342.2.5.3 Tramadeerror..................................................................................................................352.2.5.4 Espacioentretramas.........................................................................................................362.2.5.5 Tramadesobrecarga........................................................................................................36

2.3 ProtocoloOBD-II..............................................................................................................372.3.1Accesoalainformación...................................................................................................................372.3.2Códigosdeerror..............................................................................................................................382.3.3 ModosyparámetrosOBD-II.......................................................................................................392.3.4 Protocolosdecomunicación......................................................................................................41

2.4 Conectores.......................................................................................................................412.4.1 Adaptadores................................................................................................................................43

2.5 EscánerOBD-II..................................................................................................................442.5.1EscánerOBD-IIdemano..................................................................................................................442.5.2ProgramasinformáticosescánerparaOBD-II................................................................................45

2.5.2.1Aplicacionesmóviles................................................................................................................452.5.2.2ProgramasparaPC...................................................................................................................45

2.6 ChipELM327....................................................................................................................462.6.1 Comunicaciónconelvehículo....................................................................................................47

3. Hardware.................................................................................................................493.1 Arduino.............................................................................................................................503.2 MóduloCAN-BUS.............................................................................................................51

3.2.1 ControladorCANMCP2515........................................................................................................523.2.2 TransceptorMCP2551................................................................................................................52

3.3 EscánerELM327...............................................................................................................533.4 Ordenador........................................................................................................................53


11

3.5 Montaje............................................................................................................................54

4. Software...................................................................................................................574.1 eCoApplication................................................................................................................58

4.1.1 Entornográfico(GUI–Front-end).............................................................................................584.1.1.1 PestañaInicio.....................................................................................................................584.1.1.2 PestañaMedidas...............................................................................................................594.1.1.3 PestañaDatos....................................................................................................................604.1.1.4 VentanaAjustes.................................................................................................................61

4.1.2 Código(Back-end).......................................................................................................................624.1.2.1 FunciónpictureBox_ON_Click(…).....................................................................................644.1.2.2 Funciónbutton_iniciar_Click(…).......................................................................................654.1.2.3 Funciónbutton_detener_Click(…)....................................................................................664.1.2.4 Funciónbutton_suspender_Click(…)................................................................................674.1.2.5 Funciónbutton_errores_Click(…).....................................................................................684.1.2.6 FunciónLoop_lectura().....................................................................................................694.1.2.7 Otrasfunciones.................................................................................................................70

4.2 CódigoArduino................................................................................................................71

5. Conclusionesytrabajosfuturos...............................................................................725.1 Conclusiones....................................................................................................................73

5.1.1 Problemasencontradosysolucionesaportadas.......................................................................735.2 Trabajosfuturos...............................................................................................................74

REFERENCIAS.............................................................................................................................75ANEXO.......................................................................................................................................77

12

INDICE DE FIGURAS FIGURA1.SISTEMASCONBUSCANVSSISTEMASSINBUSCAN..........................................................................................22FIGURA2.ESQUEMADELBUSCAN[16].........................................................................................................................22FIGURA3.CAPASDEPROTOCOLOCAN...........................................................................................................................25FIGURA4.NIVELESDELBUSCANDEALTAVELOCIDAD......................................................................................................27FIGURA5.CONFIGURACIÓNDELBUSCANDEALTAVELOCIDAD..........................................................................................27FIGURA6.NIVELESDELBUSCANDEBAJAVELOCIDAD......................................................................................................28FIGURA7.CONFIGURACIÓNDELBUSCANDEBAJAVELOCIDAD..........................................................................................29FIGURA8.PRIORIDADYMECANISMODECOLISIÓNENELBUSCAN.......................................................................................30FIGURA9.FORMATODEUNATRAMADELBUSCAN..........................................................................................................31FIGURA10.TRAMAESTÁNDARFRENTEATRAMAEXTENDIDA..............................................................................................34FIGURA11.FORMATODEUNATRAMAREMOTA...............................................................................................................34FIGURA12.FORMATODELATRAMADEERROR.................................................................................................................35FIGURA13.CÓDIGOSDEERROR[5]................................................................................................................................39FIGURA14.PINESDELCONECTOROBD-II[4]..................................................................................................................42FIGURA15.ADAPTADORUSB.......................................................................................................................................43FIGURA16.ADAPTADORWIFI.......................................................................................................................................44FIGURA17.ESCÁNEROBD-IIDEMANO..........................................................................................................................44FIGURA18.ELM327[6].............................................................................................................................................46FIGURA19.PLACAARDUINOUNO.................................................................................................................................51FIGURA20.MÓDULOCAN-BUS...................................................................................................................................51FIGURA21.CONTROLADORMCP2515..........................................................................................................................52FIGURA22.TRANSCEPTORMCP2551...........................................................................................................................52FIGURA23.INTERFAZELM327.....................................................................................................................................53FIGURA24.ESQUEMADECONEXIÓNENTREPLACAS..........................................................................................................54FIGURA25.MONTAJE.PLACABREADBOARDYPLACACAN-BUSSOBREPLACAARDUINO.......................................................55FIGURA26.MONTAJECOMPLETO..................................................................................................................................56FIGURA27.ECOAPPLICATION-INICIO............................................................................................................................59FIGURA28.ECOAPPLICATION–MEDIDAS.BOTÓNINICIARPULSADO..................................................................................59FIGURA29.ECOAPPLICATION–MEDIDAS.BOTÓNSUSPENDERPULSADOYMILACTIVO........................................................60FIGURA30.ECOAPPLICATION-DATOS.EJEMPLOENFUNCIONAMIENTO..............................................................................61FIGURA31.ECOAPPLICATION–ARCHIVO“.TXT”GENERADO.............................................................................................61FIGURA32.ECOAPPLICATION-AJUSTES.........................................................................................................................62FIGURA33.RELACIÓNDETÉRMINOSEN.NETFRAMEWORK[14].......................................................................................64FIGURA34.DIAGRAMADEFLUJODELAFUNCIÓNPICTUREBOX_ON_CLICK()........................................................................65FIGURA35.DIAGRAMADEFLUJODELAFUNCIÓNBUTTON_INICIAR_CLICK............................................................................66FIGURA36.DIAGRAMADEFLUJODELAFUNCIÓNBUTTON_DETENER_CLICK().......................................................................67FIGURA37.DIAGRAMADEFLUJODELAFUNCIÓNBUTTON_SUSPENDER_CLICK()...................................................................68FIGURA38.DIAGRAMADEFLUJODELAFUNCIÓNBUTTON_ERRORES_CLICK().......................................................................69FIGURA39.DIAGRAMADEFLUJODELAFUNCIÓNLOOP_LECTURA().....................................................................................70


13

INDICE DE TABLAS TABLA1.MODOSOBD-II.............................................................................................................................................40TABLA2.PIDSOBDIIEINTERPRETACIÓN........................................................................................................................40TABLA3.COMANDOSATELM327................................................................................................................................47

14

NOTACIÓN

ACK Acknowledge Field

AUI Attachment Unit Interface

CAN Controller Area Network

CAN FD CAN Flexible Data-Rate

CLR Common Language Runtime

CRC Cyclic Redundancy Check

CSMA/CD Carrier Sense, Multiple Access / Collision Detection

CSMA/CD+CR CSMA/CD + Collision Resolution

DLC Data Length Code

DTC Diagnostic Trouble Codes

ECU Electronic Control Unit

EOF End of Frame

EPA Environment Protection Agency

GUI Graphical User Interface

ISO International Organization for Standardization

IDE Integrated Transmission Request

IFS Intermission Frame Space

ID Identification

IP Internet Protocol

IPX Internetwork Packet Exchange

LED Light-Emitting Diodes

LLC Logical Link Control

MAC Medium Access Control

MDI Medium Dependent Interface

MIL Malfunction Indicator Light

MSB Most Significant Bit

NIC Network Interface Card

NRZ Non-Return-to-Zero

OBD On Board Diagnosis


15

OSI Open System Interconnection

PC Personal Computer

PID Parameter ID

PMA Physical Medium Attachment

PS Physical Signaling

PWM Pulse Width Modulation

RPM Revolutions Per Minute

RTR Remote Transmission Request

SAE Society of Automotive Engineers

SPI Serial Peripheral Interface

SOF Start Of Frame

TFG Trabajo de Fin de Grado

UART Universal Asynchronous Receiver-Transmitter

USB Universal Serial Bus

VPW Variable Pulse Width


17

1. Introducción y Objetivos

Este capítulo está pensado a modo de introducción, donde se comenta el sentido de la realización de este trabajo, así como los objetivos finales del mismo.

18

1.1 Introducción La seguridad y tranquilidad a la hora de la conducción es, cada día más, un factor importante. Es por ello que la existencia de una aplicación capaz de mostrar, en un ordenador de a bordo, información de utilidad se aprecia importante. Si además esa información es mostrada en tiempo real y recogida directamente de la Unidad de Control (conocida también como Electronic Control Unit o ECU), la experiencia del usuario se verá mejorada, incluyendo el factor seguridad que se hace tan importante a día de hoy. Actualmente, todos los coches cuentan con ordenadores de abordo que muestran la información proveniente de las ECUs del vehículo. La información que se suele mostrar va desde la cantidad de combustible utilizada en la combustión y el control del punto de ignición, hasta las revoluciones y temperatura del motor, entre otras muchas. En ocasiones, existen programas informáticos que, al conectar un ordenador portátil al vehículo, este permite leer la información de las ECUs. A estos programas se les conoce como programas de diagnóstico para vehículos, programas informáticos que están orientados principalmente a vehículos de combustión. Debido al desarrollo de vehículos eléctricos sería interesante disponer de programas informáticos adaptados a los vehículos eléctricos y a sus características específicas. Esto permitiría conocer parámetros específicos del motor eléctrico, carga de las baterías, etc.

1.2 Objetivos El objetivo de este Trabajo de Fin de Grado consiste en el desarrollo de una aplicación informática para un ordenador portátil, que se conectará a un vehículo permitiendo la lectura de datos de una ECU específica del vehículo eléctrico. Esta aplicación, además, mostrará diferentes datos leídos en la pantalla del ordenador.

La comunicación establecida entre el ordenador de a bordo y la ECU se realizará a través del bus de datos del vehículo, sobre la que se implementan los protocolos de comunicaciones CAN (Controller Area Network) y OBD-II (On Board Diagnosis II).

La aplicación descrita anteriormente corresponde a un prototipo de aplicación de diagnóstico de vehículos eléctricos y ha sido el principal objetivo de este proyecto. Esta aplicación se ha desarrollado sobre el sistema operativo Windows, utilizando para ello el lenguaje de programación C++, haciendo uso del Framework .NET de Microsoft. El entorno de desarrollo (IDE) empleado es Microsoft Visual Studio 2015.

Por tanto, los objetivos de este proyecto se pueden resumir en los siguientes apartados:

• Estudio de las características de un sistema de diagnóstico OBD-II basado en el bus CAN.

• Estudio de la comunicación con el chip ELM327 para la conversión del CAN-BUS a USB

• Desarrollo de las funciones de comunicación de la aplicación de visualización (back-end) para intercambiar mensajes con el simulador de una ECU

• Desarrollo de la interfaz gráfica (front-end) de la aplicación de visualización.


19

2. Fundamentos Teóricos

Este capítulo recoge todo el marco teórico necesario para la correcta comprensión del hardware y software desarrollado e implicado en este trabajo. Se hace un repaso de las comunicaciones internas del vehículo y los protocolos necesarios para dicha función, además de introducir brevemente algunos de los elementos hardware que se nombrarán en capítulos posteriores.

20

2.1 Comunicaciones internas del vehículo Las unidades electrónicas de control de un vehículo realizan varias funciones:

• Controlan distintos sistemas del vehículo. • Intercambian información entre ellas. • Envían información al ordenador de abordo o a una aplicación de diagnóstico del

vehículo para la visualización de los datos. Este envío de información se realiza a través de buses de datos internos del vehículo, los cuales implementan los protocolos CAN y OBD-II.

Pero, ¿qué es una ECU? Bajo estas siglas se encuentran las palabras Engine Control Unit. En un principio, era el motor uno de los primeros sistemas que fueron controlados electrónicamente. Sin embargo, con el paso del tiempo, el número de estos sistemas controlados electrónicamente aumentó bastante. Fue entonces cuando el término ECU pasó a entenderse como Electronic Control Unit, recogiendo en su nombre de esta manera a todas las unidades de control capaces de controlar sistemas del vehículo.

Como es lógico, una de las ECUs más importantes es la unidad de control electrónico que regula el motor. En este proyecto nos centraremos en esta, es decir, cuando empleemos el término ECU, estaremos refiriéndonos a Engine Control Unit. Esta ECU es el principal elemento de un complejo sistema electrónico compuesto por actuadores y sensores. Los sensores recogen diferentes medidas del funcionamiento del motor, es decir, diferentes magnitudes mecánicas, químicas, etc., las cuales son medidas y convertidas a señales eléctricas. La ECU procesa estas señales y calcula la respuesta o acción necesaria que debería llevarse a cabo para el correcto funcionamiento del motor. Entonces la ECU envía estas acciones necesarias a los actuadores, los cuales son los encargados de aplicar estas acciones en el tipo de magnitud necesaria para que se lleve a cabo la actuación (e.g. mecánica, química, etc.).

Merece la pena detenernos en uno de los principales avances en el mundo de las ECU, las ECU programables. Éstas pueden ser modificadas mediante el uso de un ordenador portátil y un programa informático adecuado. De esta manera se puede configurar correctamente el funcionamiento y rendimiento de un vehículo, por ejemplo, en caso de un cambio en algún componente de él. Una lista de los parámetros más comúnmente programables en un vehículo iría desde la ignición hasta el sensor de oxígeno, pasando por el límite de revoluciones, modificación de baja presión en combustible, correcta temperatura del agua, etc. [1]

2.2 Bus CAN Una vez se entiende la funcionalidad de las ECU, sensores y actuadores, es necesario conocer cómo se comunican entre ellos y cómo envían la información al ordenador de abordo o a una aplicación de diagnóstico para la visualización de los datos del vehículo.

Del incremento de componentes incorporados en los vehículos, la complejidad de cableado para conectarlos entre sí aumentó considerablemente. Así surgió la idea de


21

conectarlos todos mediante un bus de datos fiable, robusto y que permitiese altas velocidades de transmisión en entornos difíciles. Así se llevó a cabo la creación de un protocolo de comunicación, pensado y diseñado para la comunicación fiable entre centralitas electrónicas basadas en microprocesador, el protocolo CAN.

Un bus de datos es una topología de red de comunicaciones que transmite datos de dos o más dispositivos empleando un único medio de comunicación, tal y como podría ser un cable eléctrico.

Esta situación se da en los vehículos. Se incorpora un único cable que recorre todos los sistemas del vehículo al cual van conectados los diferentes dispositivos que necesitan comunicarse, como es el caso de las ECUs. De esta forma cualquier sistema conectado al bus puede enviar y recibir información de los demás.

El protocolo CAN da soporte además a otros protocolos más específicos como son los usados por las aplicaciones de diagnóstico. Prácticamente todos los vehículos incluyen un conector llamado OBD, el cual permite leer la información que circula por el bus de comunicaciones interno del vehículo, es decir, el bus CAN.

2.2.1 Historia En los comienzos de la automoción, los vehículos no contaban prácticamente con unidades electrónicas incorporadas. Debido a la escasez de estos elementos, si varios sistemas del vehículo necesitaban comunicarse, lo hacían a través de cables que conectaban unos sistemas con otros de manera directa. A medida que se iban desarrollando nuevas funcionalidades, la tecnología avanzaba y se incorporaban mejoras a los vehículos, en su gran mayoría electrónicas. La manera de comunicarse unos elementos con otros se hizo más difícil puesto que se hacía necesario utilizar un cableado demasiado complejo para comunicar todos los elementos. Es en este punto se decidió que era necesario crear un protocolo de comunicaciones adecuado para la automoción.

El protocolo CAN fue ideado y patentado por los ingenieros de Bosch en 1982, usándose a día de hoy en la gran mayoría de automóviles. Aunque en un principio fue ideado como un bus de campo para entornos industriales, rápidamente encontró su hueco en el mundo de la automovilística. Fue a partir de 1993, en Europa, cuando el protocolo CAN se convirtió en un estándar de facto de carácter internacional. El estándar CAN se encuentra definido por normas ISO (ISO-11898).

Este protocolo se trata de una solución económica que permite que las ECUs tengan una única interfaz CAN en lugar de diferentes interfaces de entradas analógicas y digitales para conectarse al resto de unidades electrónicas del vehículo (ver Figura 1). De esta manera se reduce considerablemente el coste, la complejidad y el peso de las ECUs, así como la del conjunto del automóvil.

22

2.2.2 Elementos del bus CAN En este apartado quedan descritos los elementos principales que conforman el bus CAN, los cuales son:

• Cables. El cable que forma el bus CAN es un cable de par trenzado, siendo el

encargado de unir todos los elementos del sistema. Una de las ventajas del par trenzado es que esta configuración anula los campos magnéticos que podrían afectar a las señales eléctricas que transportan la información. La información enviada por el cable se representa por la diferencia de tensión que hay entre los dos cables que forman este par. El valor alto de tensión, que oscila entre los 0V y 2.25V, y viaja por el cable L (Low) o CAN-Low, es representado por un 1. El valor bajo oscila entre 2.75V y 5V, y se transmite por el cable H (High) o CAN-High, es representado por un 0. Es la combinación de estos dos valores los que conforman la información que se transmite. La Figura 2 muestra un esquema del bus con los dos cables que lo componen. Es interesante destacar que, en el caso de que uno de los dos cables

Figura 1. Sistemas con bus CAN vs Sistemas sin Bus CAN

Figura 2. Esquema del bus CAN [16]


23

interrumpiese su correcto funcionamiento, el otro de ellos trabajaría con su señal respecto a tierra. Por ejemplo, si la línea H deja de funcionar, el sistema seguiría trabajando con la señal del cable L, y en caso contrario de igual forma. Esto hace que el sistema pueda trabajar con uno de los dos cables cortados o a tierra, interrumpiendo únicamente su funcionamiento en caso de que ambos cables estén cortados.

• Elemento terminador. Se denominan así a las resistencias conectadas a los extremos finales de los cables L y H. Los valores de éstas varían según la longitud de los cables y el número de unidades de control conectadas, permitiendo así un funcionamiento correcto. La función principal es impedir fenómenos de reflexión, ayudando a eliminar posibles perturbaciones en los mensajes. Podemos encontrar estas resistencias incluidas en algunas unidades de control. De esta forma se ahorra espacio y hace más seguro el funcionamiento.

• Controlador. Este elemento se encarga de la comunicación entre la unidad de control y el transmisor-receptor, acondicionando la información saliente y entrante de ambos dispositivos. Este elemento está incluido en la ECU. En un bus CAN existirán tantos controladores como elementos haya conectados al mismo. El controlador se encarga de determinar la velocidad con la que transmiten los mensajes, variando ésta según el compromiso del sistema. Además, se sincroniza con otras unidades conectadas al bus CAN para la correcta emisión y recepción de mensajes.

• Transmisor/Receptor. Este elemento, como su nombre indica, recibe los datos que una ECU necesita transmitir y genera las señales eléctricas necesarias que viajarán por el bus CAN. A su vez, recibe las señales eléctricas de otras unidades de control y las transforma en datos que pueden ser procesados por la ECU. Concretamente, su trabajo consiste en generar niveles de tensión de manera correcta, amplificando la señal cuando la información es mandada al cable, y disminuyéndola cuando el controlador la recupera del mismo. A este componente se le conoce también como transceiver. Se trata básicamente de un circuito integrado situado en cada ECU del sistema, situándose entre los cables de par trenzados y el controlador.

2.2.3 Características principales Las principales propiedades del protocolo CAN son [2]:

• Económico. Al hacer el sistema de cableado más sencillo, se economiza en el montaje.

• Estandarizado. Es un estándar definido mediante normas ISO; el estándar se divide en varias partes las cuales se centran en los diferentes aspectos del CAN.

• Garantía en los tiempos de retardo. El protocolo CAN asegura la transmisión de una cierta cantidad de datos en un tiempo concreto, es decir, entre extremo y

24

extremo no se excede de un tiempo especificado. • La transmisión del protocolo CAN es siempre en tiempo real. • Distinción entre distintos tipos de errores, como errores temporales y

permanentes, lograda a través de 5 mecanismos de detección (3 a nivel de mensaje y 2 a nivel de bit) permitiendo la desconexión automática de nodos defectuosos.

• Señalización de errores. • Retransmisión automática de mensajes corruptos. • La información que circula son paquetes de bits con una estructura definida de

campos de mensaje. A estos paquetes también se les da el nombre de tramas. • Flexibilidad en la configuración. • Priorización de mensajes. • CAN permite envíos de información tipo multicast, lo cual permite a todos los

elementos de la red acceder al bus de forma simultánea para leer el bus. • CAN dispone de mecanismos de control de congestión del tráfico de datos en el

bus, que sincroniza distintos dispositivos si varios quieren transmitir datos a la vez. Esto permite que en cada instante sólo haya un único dispositivo enviando datos al bus.

• La ISO define dos tipos de redes CAN. Una de alta velocidad (hasta 1Mbps, definida en la ISO 11898-2) y una red de velocidad baja tolerante a fallos (menor o igual a 125Kbps, definida en la ISO 11898-3). Hay que tener en cuenta que la velocidad de transmisión depende de la distancia recorrida hasta un máximo de 1000m.

• CAN cuenta con jerarquía multimaestro, la cual permite que todos los elementos de la red puedan transmitir información. Esto da la posibilidad de crear sistemas inteligentes y redundantes.

2.2.4 Arquitectura de Capas Como todo sistema de red, el protocolo CAN está basado en capas. Como se ha comentado en el apartado 2.2.1, el protocolo CAN pertenece al estándar ISO 11898, concretamente la especificación CAN 2.0. En este estándar se definen las capas del bus CAN según el modelo de referencia OSI.

CAN es un protocolo de bajo nivel, definiendo únicamente las dos capas inferiores del modelo OSI: la capa física y la de enlace, tal y como queda se muestra en la Figura 3. De esta forma, las capas superiores, las cuales no quedan especificadas en este estándar, deben ser definidas por el profesional que modele la aplicación correspondiente.


25

Figura 3. Capas de protocolo CAN

2.2.4.1 Capa Física La Capa Física CAN debe soportar la representación de los estados recesivo y dominante en el medio de transmisión. El medio de transmisión se encontrará el estado recesivo si ningún nodo del bus transmite un bit dominante, y en estado dominante si uno o más nodos transmiten un bit dominante.

Esta capa es la encargada de la transferencia de bits entre los distintos elementos de la red. Es en ella donde se describen aspectos físicos tales como codificación, sincronización, nivel de señal y tiempos en que los bits se transfieren al bus. Además, es esta capa la cual describe el voltaje específico y el tipo de cable que han de ser empleados en los protocolos de transmisión.

Inicialmente, la capa física no estaba definida, permitiendo esto diferentes opciones para la elección del medio y niveles eléctricos de transmisión. Fue también más tarde, en el estándar ISO 11898, cuando las características de las señales eléctricas del bus fueron establecidas: ISO11898-2 para aplicaciones de alta velocidad (hasta 1Mbps) e ISO11989-3 para aplicaciones de baja velocidad (hasta 125Kbps).

Esta capa se puede dividir en tres subcapas. La capa de Señalización Física o Physical Signaling (PS) se implementa en el controlador CAN. En la capa de Acercamiento al Medio Físico o Physical Medium Attachment (PMA) se describen las características del transceptor. Por último, la capa Interfaz de Independencia al Medio o Medium Dependent Interface (MDI) especifica las características de los cables y conectores necesarios en la conexión del bus.

Las capas PMA y MDI son objeto de distintas normas internacionales, nacionales e industriales, siguiendo la norma ISO 11898-2, correspondiente al bus CAN de alta

26

velocidad sobre par de hilos con retorno. Por su parte, la capa PS en la que contempla los bits de codificación y decodificación y sincronización (bit timing). Es aquí donde se implementa la AUI (Attachment Unit Interface) la cual contiene los chips del transceptor.

El protocolo CAN emplea la codificación NRZ (Non-Return-to-Zero), en la cual no todos los bits cuentan con flanco de subida y de bajada. El tiempo de bit indica el tiempo que un bit tarda en ser enviado por una tarjeta de interfaz de red o Network Interface Card (NIC), la cual trabaja a una cierta velocidad. Durante el tiempo de bit la tensión es constante, 0V o 5V (o 3.3V según la versión de implementación). Si los bits transmitidos tienen el mismo valor lógico, el nivel de señal puede permanecer constante durante largos periodos de tiempo, por lo que habrá que tomar medidas para asegurar que no se excede el intervalo máximo admisible entre dos flancos de señal. Esta medida es importante para los propósitos de sincronización. Para garantizar que la secuencia de bits original sea la misma que la secuencia transmitida al controlador, el protocolo CAN emplea la técnica conocida como bit-stuffing. Tras cinco bits del mismo valor lógico, el controlador transmisor CAN incluye automáticamente un bit de valor lógico opuesto (sin contar el delimitador de final de trama y espacio entre tramas). En el otro extremo, este bit añadido debe ser eliminado por el receptor de la trama, empleándose únicamente para la sincronización.

2.2.4.1.1 Estándar ISO 11898-2 Alta Velocidad El estándar ISO 11898-2, también llamada CAN de alta velocidad, permite usar únicamente un bus lineal terminado en cada extremo con sendas resistencias de 120 Ω, debiendo ser ambas capaz de disipar 0.25W de potencia. Este bus no soporta otras topologías de bus como configuraciones en estrella. Es importante que el valor de las resistencias de terminación coincida con la impedancia característica del bus, definida en 120 Ω, para evitar reflexiones en la línea que podrían perturbar la comunicación. Con esta configuración la velocidad del bus es de un máximo de 1 Mbit/s.


27

Figura 4. Niveles del Bus CAN de Alta Velocidad

Los niveles del bus CAN de alta velocidad son:

• Dominante. La tensión diferencial (CAN-High – CAN-Low) es del orden de 2V, siendo CAN-High=3.5V y CAN-Low=1.5V (nominales).

• Recesivo. La tensión diferencial (CAN-High – CAN-Low) en esta ocasión es del orden de 0V, siendo el valor de CAN-High y CAN-Low idénticos, 2.5V nominales.

El par de cables trenzados CAN-High y CAN-Low forma la línea de transmisión, la cual, si no está configurada con los valores correctos, puede ocasionar fallos en la comunicación.

Figura 5. Configuración del Bus CAN de Alta Velocidad

La ISO ha definido unas extensiones opcionales de la capa física del bus CAN de alta velocidad (ISO 11898-2). Dichas extensiones están descritas en sus respectivos estándares y son útiles para sistemas con requisitos específicos:

• ISO 11898-5: especifica la capa física con tasas de transmisión de hasta 1 Mbit/s

28

para sistemas que requieren bajo consumo de energía cuando no hay comunicaciones activas en el bus de datos. El estándar ISO 11898-5 representa una extensión de la norma ISO 11898-2 y aquellas implementaciones que cumplan cualquiera de estas dos normas pueden coexistir en la misma red. Es decir, los nodos CAN de alta velocidad con y sin bajo consumo de energía, son interoperables entre sí.

• ISO 11898-6: es una extensión del estándar ISO 11898-2 y del ISO 11898-5. Esta extensión especifica la capa física de un bus CAN de hasta 1 Mbit/s, proporcionando un método selectivo de activación de nodos (wake-up) usando tramas CAN configurables. Las implementaciones de ISO 11898-6, ISO 11898-2 e ISO 11898-5 son interoperables y se pueden usar en una misma red simultáneamente.

2.2.4.1.2 Estándar ISO 11898-3 Baja Velocidad El estándar ISO 11898-3, también llamado CAN de baja velocidad tolerante a fallos, puede utilizar un bus lineal, un bus en estrella o múltiples buses en estrella conectados por un bus lineal. El bus está terminado en cada nodo por una fracción de la resistencia de terminación total. La resistencia de terminación total debería ser un valor próximo a 100 Ω, pero no inferior a este valor. La suma total de las resistencias en paralelo debe ser del orden de 100-500 Ω. Este estándar permite velocidades de hasta 125 kbit/s.

Figura 6. Niveles del Bus CAN de Baja Velocidad

Los niveles del bus CAN de baja velocidad son:

• Dominante. La tensión diferencial (CAN-High – CAN-Low) es del orden de 2V, siendo CAN-High=3.6V y CAN-Low=1.4V (nominales).

• Recesivo. La tensión diferencial (CAN-High – CAN-Low) en esta ocasión es del orden de 5V, siendo el valor de CAN-High=0V y CAN-Low=5V (nominales).


29

Figura 7. Configuración del Bus CAN de Baja Velocidad

2.2.4.1.2 CAN FD (Flexible Data-Rate) En 2011, Bosch comenzó a trabajar en una evolución del bus CAN. En 2012 lanzó al mercado la nueva versión, CAN FD 1.0, que ofrece un aumento de la tasa de transferencia después del arbitraje, es decir, del control de acceso al medio. De momento, hasta el año 2015, sólo se ha definido la capa de enlace de datos del CAN FD. Con esta nueva versión del bus CAN, la frecuencia de transmisión se puede multiplicar hasta por 8 y el número máximo de bytes por trama aumenta, siendo posible transmitir una mayor cantidad de datos en el mismo tiempo. La especificación del CAN FD 1.0 está recogida en el borrador de norma ISO/DIS 11898-1:2015. [2] [3]

2.2.4.2 Capa de Enlace La Capa de Enlace se divide en dos subcapas, la subcapa de Enlace de Control Lógico o Logical Link Control (LLC) y la subcapa de Control de Acceso al Medio o Medium Access Control (MAC). Debido a que la red CAN da soporte para el procesamiento a tiempo real de todos los sistemas que la integran, el intercambio de mensajes demandado por dicho procesamiento necesita de un sistema de transmisión de frecuencias altas y retrasos mínimos. En redes multimaestro, dicha técnica de acceso al medio es muy importante debido a que todo nodo activo tiene derechos para controlar la red y acaparar los recursos.

Por tanto, la capa de enlace de datos define este método de acceso al medio, así como los tipos de tramas para el envío de mensajes.

30

2.2.4.2.1 Subcapa de Control de Acceso al Medio (MAC)

Esta capa es la encargada de definir las tareas independientes del acceso al medio, denominada CSMA/CD+CR o “Carrier Sense, Multiple Access/Colission Detection + Collision Resolution” (en español Acceso múltiple con detección de portadora, detección de colisión más resolución de colisión). Cada nodo debe vigilar el bus en un período sin actividad antes de enviar un mensaje (Carrier Sense) y, una vez que pasa 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 mismo tiempo, se detectará la colisión.

Inicialmente, el acceso al medio por técnicas de acceso múltiple y detección de conflicto, se hacía mediante el método conocido como ALOHA. Este método evolucionó hasta su consolidación como método de acceso al medio de las redes Ethernet, con técnica CSMA/CD. El método de acceso al medio que emplea el protocolo del bus CAN implementa una nueva característica, la resolución de colisión. Ante una colisión de varias tramas, en la técnica CSMA/CD utilizada en redes Ethernet, todas ellas se pierden. Sin embargo, CAN resuelve esta colisión con la supervivencia de una de las tramas que chocan en el bus. La trama superviviente es aquella que se ha identificado como mayor prioridad.

Para solucionar la colisión, se aplica una función lógica determinista a cada bit, resolviéndose de manera que tienen prioridad los bits definidos como tipo dominante. El valor lógico “0” es el que define que el bit sea dominante, siendo el valor lógico “1” el que indica que el bit sea recesivo, tratándose de una función AND de todos los bits transmitidos simultáneamente. Cada transmisor escucha de manera continua el valor presente en el bus, y deja de hacerlo una vez el valor no coincide con el que dicho transmisor ha forzado. La transmisión continúa siempre y cuando haya coincidencia, haciendo que el mensaje con identificador de máxima prioridad sobreviva. Los demás módulos reintentarán la transmisión lo antes posible. Por lo tanto, la prioridad queda así determinada por el campo Identificador, el cual forma parte del mensaje. En la Figura 8 queda explicado el mecanismo de colisión y prioridad.

Figura 8. Prioridad y mecanismo de colisión en el bus CAN


31

En la especificación CAN de Bosch no se dice cómo se ha de traducir cada nivel de bit (dominante o recesivo) a variable física. Cuando se emplean cables trenzados, 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 aplicación 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, desde las capas de software de protocolo. La prioridad queda así determinada por el contenido del mensaje, en CAN es un campo determinado, el identificador de mensaje, el que determina la prioridad.

2.2.4.2.2 Subcapa de Enlace de Control Lógico (LLC)

El control de enlace lógico (LLC) coloca información en la trama que identifica qué protocolo de capa de red está siendo utilizado por la trama. Esta información permite que varios protocolos de la capa 3, tales como IP e IPX, utilicen la misma interfaz de red y los mismos medios.

Esta subcapa es la encargada de definir la parte alta de la capa de enlace de datos, definiendo las tareas que dependen del método de acceso al medio. [2] [3]

2.2.5 Tipos de tramas CAN es un protocolo basado en mensajes, no en direcciones. Es el nodo emisor el que transmite esta información en forma de mensaje a todos los nodos que conforman la red, pero no se especifica el destino. De este modo, todos los nodos escuchan el mensaje, para posteriormente filtrarlo según sea de interés o no para este nodo. Para la gestión de la transferencia de mensajes, el protocolo CAN cuenta con distintos tipos de tramas predefinidas.

2.2.5.1 Trama de datos La trama de datos se genera en un nodo CAN una vez se transmite la información. Es empleada por dicho nodo para poner la información en el bus, pudiendo incluir entre 0 y 8 bits de información útil. Tal y como se muestra en la Figura 9 , se dividen en:

Figura 9. Formato de una trama del bus CAN

• Inicio de trama o Start of Frame (SOF). El inicio de trama es un campo de un

32

único bit, siempre dominante, que indica el inicio de la transmisión. De esta forma, los nodos receptores se sincronizan con el flanco de bajada de este bit.

• Arbitraje o Arbitration Field. Esta celda concede prioridad a unos mensajes frente a otros. El campo de identificación está formado por el identificador del mensaje (11 bits) y el bit RTR (Remote Tansmission Request), el cual es dominante en una trama de datos. Los bits del campo identificador se transmiten en orden de más significativo a menos.

• Control. Este campo lo conforman dos bits, los cuales están reservados para un uso futuro, y cuatro bits adicionales que señalan el número de bytes de datos. El primer bit, llamado IDE, se emplea para indicar si la trama es de CAN Estándar (IDE dominante) o Extendida (IDE recesivo). El segundo de estos bits, llamado RB0, es siempre recesivo. Los cuatro bits adicionales que determinan la longitud (DLC, Data Length Code), indican en binario el número de bytes de datos en el mensaje (0 a 8).

• Datos. El campo de datos es el lugar donde se colocan los datos del mensaje. Se trata de un campo formado de 0 a 8 bytes de datos, es decir, de 0 a 64 bits en saltos de 8, siendo el MSB (Most Significant Bit) el primero en ser transmitido.

• Código de redundancia cíclica o Cyclic redundancy check (CRC). El campo

CRC es donde se agrega el código de redundancia cíclica. Este código se genera localmente en el nodo emisor y se envía junto con el mensaje. Es más tarde cuando el nodo receptor recalcula el CRC, lo compara, y si existe alguna diferencia, el mensaje es marcado como erróneo. En este campo también se añade el delimitador CRC. Esto es, un bit recesivo que permite que los nodos reaccionen y analicen los bits previos, es decir, en este tiempo el nodo calcula locamente el CRC y lo valida. El valor del CRC se calcula empleando todos los bits que forman la trama. El objetivo de este CRC es facilitar la correcta recepción de los mensajes transmitidos por un canal ruidoso. Para que este objetivo sea alcanzado, el transmisor construye una secuencia de verificación que es función del mensaje. Por otra parte, el receptor emplea esta misma función para calcular la secuencia de verificación del mensaje recibido. Por último, es el receptor el que compara las dos secuencias (la generada por él y la que le llega), determinando así si el mensaje ha sido recibido correctamente. La idea reside en tratar al mensaje como si de un número binario muy grande se tratase, y dividirlo por otro número fijo seleccionado previamente para obtener un residuo. El receptor por su parte realiza la misma división obteniendo su propio residuo. La función con la que se realiza la verificación la genera el transmisor mediante una división módulo 2 de todos los bits precedentes del mensaje, incluyendo los de relleno en caso que existieran, por el polinomio generador X15+ X14+ X8+ X7+ X4+ X3+ X1+ 1. El resto de esta división es el código CRC transmitido, el cual más tarde es comprobado por los receptores. Tras el código CRC se


33

incluye un bit recesivo, el cual delimita el campo CRC (delimitador de CRC).

• Campo de reconocimiento o Acknowledge field (ACK). Se trata de un campo de dos bits, los cuales son puestos como recesivos por el transmisor: el bit ACK Slot y el bit ACK delimiter. El primero de estos bits (ACK Slot) verifica que la trama se ha recibido correctamente. El nodo transmisor envía este bit dándole el valor de recesivo, y si, al menos un nodo lo recibe libre de errores, sobrescribe este bit como dominante. El segundo de ellos (ACK Delimiter) debe ser siempre un bit recesivo. Por ello, cuando un mensaje se recibe correctamente por todos los nodos, el ACK slot (dominante) se encuentra entre dos bits recesivos.

• Fin de trama o End of Frame (EOF). La trama de datos finaliza con una bandera que consiste en una secuencia de 7 bits recesivos (se ha de tener en cuenta que esta trama es 2 bits más grande que la longitud estándar por la inclusión del bit de relleno). Esto se debe a que ése es un campo fijo, por lo que el bit de relleno está deshabilitado durante su duración.

• Espaciado entre tramas o Intermission Frame Space (IFS). Consta de un mínimo de 3 bits recesivos.

2.2.5.1.1 Trama de datos CAN Extendido vs Trama de datos CAN Estándar La trama de datos de CAN Extendido se diferencia de la de CAN Estándar en que un bit dominante fijo (SRR) aparece en la posición del bit RTR de CAN Estándar, se fija el bit IDE como recesivo, a continuación, aparecen los 18 bits adicionales del identificador, seguidos del campo de control con RTR, dos bits reservados, y la longitud de datos. El resto de la trama es igual en ambos tipos de tramas.

Tanto un nodo CAN Estándar como un nodo CAN Extendido pueden convivir en un bus CAN. Para que esta convivencia no resulte problemática, es preciso que el CAN Estándar sea del tipo CAN 2.0B pasivo, ya que estos nodos reaccionan ignorando tramas CAN Extendido, en lugar de identificarlas como erróneas. Así, los nodos CAN 2.0B pueden funcionar tanto en modo Estándar como Extendido indistintamente [2].

34

Figura 10. Trama estándar frente a Trama extendida

2.2.5.2 Trama remota Los nodos de un bus CAN tienen la capacidad de pedir información a otros nodos. Un nodo pide información a los otros mediante una trama remota, 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. El formato de esta trama es análogo a la trama de datos.

Figura 11. Formato de una trama remota

Como se aprecia, la diferencia reside en que el valor del RTR es recesivo. A diferencia de los mensajes de datos, en este tipo de mensajes se envía una trama con el identificador del nodo al que se le solicita información, no existiendo campo de datos, y tomando RTR ese valor recesivo. Si se enviase un mensaje de datos y de petición remota con el mismo identificador, será el de datos el que vencerá el acceso al bus, ya que el RTR lleva valor dominante.

Como se muestra en la Figura 11 la trama remota está formada por 6 partes, en vez de las 7 que componen la trama de datos, las cuales son: inicio de trama, campo de arbitraje, campo de control, campo CRC, campo de reconocimiento y fin de trama. A continuación,


35

se añade una séptima zona llamada espacio entre tramas

• Inicio de trama. Similar a la trama de datos. • Campo de arbitraje. En este campo toma lugar el arbitraje, el cual lo conforman

los bits del identificador (similar a la trama de datos), y el bit inmediato llamado RTR. Este último, a diferencia del de la trama de datos, es recesivo para una trama remota. Por lo tanto, es este bit a través del cual se distingue si se trata de una trama de datos o remota.

• Campo de control. Este campo cuenta con 6 bits de dos tipos. Por un lado, los bits reservados (equivalentes a los de la trama de datos), y la longitud de datos, campo donde se indica el número de datos que serán recibidos.

• Campo CRC, campo de reconocimiento, fin de trama y espacio entre tramas. Estos campos son similares a los especificados en la trama de datos [2].

2.2.5.3 Trama de error Una trama de error la genera cualquier nodo del bus CAN que detecte un error. Esta trama cuenta con dos campos: Indicador de error (Error flag) y delimitador de error.

Figura 12. Formato de la trama de error

• Delimitador de error. Éste cuenta con 8 bits recesivos consecutivos, permitiendo a los nodos reiniciar la comunicación de forma limpia tras detectar el error.

• Indicador de error. Este campo varía según el estado del error del nodo que lo detecte.

o Error Activo. Si un nodo que detecta un error en el bus se encuentra en estado de error activo, se interrumpe la comunicación del mensaje en proceso generando un indicador de error activo formado por una secuencia de 6 bits dominantes sucesivos. Gracias a esta secuencia de bits, se corta la regla de relleno de bits, provocando le generación de tramas de error en otros nodos. Así, el indicador de error activo puede extenderse a un tamaño entre 6 y 12 bits dominantes sucesivos. Por último, se espera al campo de delimitación de error formado por los 8 bits recesivos. Es entonces cuando la comunicación se reinicia y el nodo que había sido interrumpido intenta de nuevo la transmisión del mensaje.

o Error Pasivo. Si por el contrario el nodo que detecta el error en el bus se

36

encuentra en estado de error pasivo, dicho nodo transmite un indicador de error pasivo seguido, de igual forma que antes, por el campo delimitador de error. En este caso, el indicador de error de tipo pasivo está formado por 6 bits recesivos seguidos. Esto hace que la trama de error de un nodo pasivo sea una secuencia de 14 bits recesivos. Es por ello que podemos suponer que la trama de error de tipo pasivo no tendrá ningún tipo de efecto sobre ningún nodo de la red, excepto en el caso de que el error sea detectado por el propio nodo que está transmitiendo. Si es este el 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 a través de una de las tramas de error apropiada en cada caso, será cada nodo el que transmite bits recesivos hasta que se recibe un bit también recesivo. Tras ello, se transmite 7 bits recesivos consecutivos antes de finalizar el tratamiento del error [2].

2.2.5.4 Espacio entre tramas El espacio entre tramas sirve, como su nombre indica claramente, para separar una trama, sea del tipo que sea, de la siguiente trama de datos o interrogación remota. Este espacio, como mínimo, debe contar con tres bits recesivos. A esta secuencia de bits recesivos se la denomina “intermission”. Una vez la secuencia pasa, un nodo en estado de error activo puede iniciar una nueva transmisión o, si no, el bus permanecerá en reposo. Sin embargo, si nos encontramos con un nodo en estado de error pasivo, la situación es diferente. Éste deberá esperar una secuencia adicional de 8 bits recesivos antes de poder iniciar una transmisión. Esto asegura una ventaja de inicio de transmisión a los nodos en estado activo frente a los nodos en estado pasivo [2].

2.2.5.5 Trama de sobrecarga La trama de sobrecarga cuenta con el mismo formato que la trama de error activo. La diferencia reside en que, la trama de sobrecarga, únicamente puede generarse durante el tiempo de espacio entre tramas. Por ello no es difícil diferenciarla de la trama de error, ya que esta sólo puede ser transmitida durante la transmisión de un mensaje.

La trama de sobrecarga cuenta con dos campos, el indicador de sobrecarga, y el delimitador. En el caso del Indicador de sobrecarga, está formado por 6 bits dominantes con la posibilidad de ser seguidos por los generados por otros nodos, dando lugar a un máximo de 6 bits dominantes. Por su parte, el delimitador está formado por 8 bits recesivos.

Un nodo el cual, debido a sus condiciones internas, no esté en condiciones de iniciar la recepción de un nuevo mensaje, puede generar una trama de sobrecarga. Es así como consigue retrasar el inicio de transmisión de un nuevo mensaje. Un nodo puede generar como máximo 2 tramas de sobrecarga consecutivas cuando desee retrasar un mensaje. Otra de las razones para iniciar la transmisión de una trama de sobrecarga, es la detección por cualquier nodo de un bit dominante en los 3 bits de “intermission”. Es por


37

todo esto por lo que una trama de sobrecarga generada por un nodo dará, normalmente, lugar a la generación de tramas de sobrecarga por los demás nodos, generando como máximo 12 bits dominantes de indicador de sobrecarga [2].

2.3 Protocolo OBD-II OBD (On Board Diagnostic) es un protocolo que surge a partir del aumento del control de niveles de contaminación producida por los vehículos a motor. Este protocolo monitoriza el motor casi al completo, además de partes del cuerpo, chasis, accesorios y otros elementos del coche del coche.

Durante los años 70 y comienzos de los 80 los fabricantes, para satisfacer las normas de emisión de gases contaminantes de la Agencia de Protección Ambiental (EPA), comenzaron a usar medios electrónicos orientados a controlar funciones y diagnosticar problemas del motor. Son las muchas unidades de control repartidas por el vehículo las que se encargan de interpretar las informaciones generadas por los sensores (velocidades, caudales, presiones, etc.), actuando sobre el vehículo en función de esta información.

El sistema OBD-II es el encargado de almacenar, de una manera específica, para facilitar más tarde la labor de reparación, los códigos de error generados en nuestro vehículo. Existen tanta cantidad de ECUs generando tanta información, que se hace imposible comprobar una por una cada unidad de control en busca de un mal funcionamiento. Es por ello que se hace importante el uso de OBD-II. Cuando una ECU recibe una señal anómala, ésta avisa al resto del sistema y es el OBD-II el que se encarga de avisar al conductor (en la mayoría de situaciones, encendiendo una señal luminosa) y almacenar de manera correcta la información de este error.

De esta manera queda claro que no es el sistema OBD-II el encargado de detectar los errores, sino únicamente de informar y almacenarlos, facilitando el acceso a esta información de anomalías. El sistema OBD-II realiza comprobaciones de los elementos específicos del vehículo de manera continua. Al detectar un error, este sistema enciende el testigo de aviso de avería (MIL o Malfunction Indicator Light), avisando así al conductor mediante algún tipo de mensaje de error. El sistema almacena la información necesaria a cerca de este error de la manera más precisa posible, facilitando así que el mecánico pueda encontrar y solucionar la avería.

2.3.1 Acceso a la información Cuando el sistema OBD-II almacena información de error y el usuario es avisado mediante, usualmente, señal luminosa, es aconsejable ir al taller, donde el mecánico conectará nuestro automóvil a una máquina de diagnóstico, conocido también como escáner o lector de sistemas OBD-II, el cual le mostrará la información recogida de manera sencilla.

38

En los comienzos de este sistema en los años 80, no existía un consenso entre fabricantes de automóviles a la hora de implementar este sistema en sus vehículos. Esto provocaba que prácticamente cada marca incorporase un conector y códigos de error distintos, lo que dificultaba enormemente la labor de los mecánicos, por no hablar del aumento del presupuesto en los talleres destinado a ello, ya que se necesitaba contar con todos los conectores y tablas de códigos existentes. En 1996 se llegó a un acuerdo entre fabricantes, y fue cuando OBD-I, el sistema usado hasta entonces, se convirtió en un estándar que definía tanto el conector como los códigos dando paso a OBD-II.

2.3.2 Códigos de error En la Figura 13 se incluye una leyenda para la ayuda en la lectura y comprensión de los códigos de error registrados en el sistema OBD-II. Existen tablas que recogen todos los códigos con su correspondiente explicación, aunque cada fabricante puede incluir los suyos propios.

Los códigos de error DTC (Diagnostic Trouble Codes) están regulados por la norma SAE J1979, estándar que a día de hoy usan la mayoría de los fabricantes. Los códigos de error están formados por 5 caracteres: 1 letra + 4 dígitos. El primer carácter indica la función del vehículo a la que pertenece el error, pudiendo ser P para el motor y transmisión (Powertrain), B para el cuerpo (Body), C para el Chasis (Chassis) y U representa indefinido (Undefined).

El segundo carácter es un 0 si el código de ese error es genérico para todas las marcas y definido por la SAE, y un 1 si se trata de un código definido por el fabricante. En este segundo caso, generalmente, los códigos son distintos entre los fabricantes. Así los códigos del X0001 al X0999 son los definidos por la SAE mientras que los códigos del X1000 al X1999 son definidos por el fabricante siguiendo únicamente la norma de la SAE en el formato.

El tercer carácter indica el subsistema del vehículo del que procede el error:

• 0 para todo el sistema electrónico • 1 y 2 para el control de combustión • 3 para el sistema de encendido • 4 para el control de emisión auxiliar • 5 para el control de velocidad y ralentí • 6 para la ECU, las entradas y las salidas • 7, 8 y 9 para la transmisión

En el cuarto y quinto carácter es donde se indica el fallo específico [4].


39

Figura 13. Códigos de error [5]

2.3.3 Modos y parámetros OBD-II Una forma de agrupar la información que el vehículo puede proporcionar es mediante la distinción de modos OBD-II. Mientras que algunos modos son obligatorios, otros son opcionales, y no todos los vehículos los soportan.

Al igual que los códigos de error, los modos OBD-II están regulados por la norma SAE J1979. Esta norma define los 10 modos de operación comentados a continuación.

Modo (hex)

Modo (hex)

01 Muestra los parámetros disponibles.

06 Resultados de las pruebas de monitoreo de componentes/sistema.

02 Muestra los datos almacenados por evento.

07 Muestra los DTC detectados durante el último ciclo de manejo o el actual.

03 Muestra los códigos DTC1. 08 Operación de control de los componentes/sistema a bordo.

04 Borra los datos almacenados, incluyendo los DTC.

09 Solicitud de información del vehículo.

1 Códigos de fallas de diagnóstico o Diagnostic Trouble Codes.

40

05 Resultado de las pruebas de monitoreo de sensores de oxígeno.

0A Códigos DTC permanentes.

Tabla 1. Modos OBD-II

Cada modo de operación contiene una serie de parámetros conocidos como PIDs (Parameters IDs). Todos los PIDs existentes no tienen por qué ser soportados obligatoriamente por todas las marcas de fabricantes.

Debido a que el valor devuelto por el vehículo es un valor hexadecimal sin signo, la mayoría de PIDs requieren de una fórmula para ser interpretados. Para ello, se divide el valor devuelto en 4 bytes, lo cuales son referenciados como A, B, C y D, de izquierda a derecha. Los valores, una vez aplicada la fórmula necesaria para su correcta interpretación, son dados en unidades internacionales (SI).

A continuación, se recoge en una tabla los PIDs más significativos y relevantes para la elaboración de este trabajo. No obstante, puede encontrar una relación completa de ellos en el enlace adjunto a pie de página2.

Descripción Modo PID Bytes Min Max Unidad Fórmula

PIDs soportados

01 00 4 [A7..A0] == [PID

0x01..0x020]

Batería 01 04 1 0 100 % A*100 / 255

Temperatura 01 05 1 -40 215 ºC A – 40

RPM 01 0C 2 0 16,38 rpm ((A*256) + B/4

Velocidad 01 0D 1 0 255 Km/h A

Petición de errores

03 - n*6 - - - -

Reset 04 - 0 - - - -

Tabla 2. PIDs OBDII e interpretación

2 http://www.outilsobdfacile.com/obd-mode-pid.php


41

2.3.4 Protocolos de comunicación Hoy día se pueden diferenciar cuatro protocolos de comunicación para el sistema OBD-II. Son los fabricantes los que escogen qué protocolo emplear, llevando todos los vehículos que salen de su fábrica el mismo protocolo. Esto permite saber con qué protocolo funcionan las comunicaciones de nuestro vehículo.

• ISO 9141. Empleado en la mayoría de vehículos asiáticos y europeos, algunos ejemplos son las marcas comerciales SEAT y Chrysler. El tipo de dato que envía es asíncrono, muy parecido al estándar RS-232, con la diferencia de que este solo envía datos en una sola dirección. Este protocolo permite enviar hasta 12 bytes de información de una única vez incluyendo CRC.

• SAE J1850 VPW. Empleado por marcas europeas menos conocidas. El ancho de pulso en este protocolo siempre es variable, con un ralentí bajo y un voltaje máximo de 7V. Al igual que en el protocolo ISO 9141, la información que permite enviar en una sola vez es como máximo de 12 bytes.

• SAE J1850 PWM. Define el protocolo serial de datos. Empleado, por ejemplo, por la conocida marca Ford. A diferencia del protocolo SAE J1850 VPW, en este se encuentra una modulación de ancho de pulso la cual no es posible variar. Se puede aplicar un voltaje máximo de 5V y, de igual forma que en el resto de protocolos OBD-II, el mensaje de información acerca del vehículo no puede pesar más de 12 bytes.

• CAN-J2284. Define la capa física y de enlace de datos del CAN de 500kbit/s. Empleado hoy día en la mayoría de vehículos europeos modernos. Este protocolo promete ser la base de la conectividad estándar en un futuro cercano.

Cada uno de estos protocolos requiere de un tratamiento diferente de la información previamente a conectar el OBD-II al PC o dispositivo de lectura. Es por ello que se requieren interfaces de conexión diferentes. Sin embargo, existe también la posibilidad de fabricar un interfaz de conexión del OBD-II con el PC que sea capaz de emplear todos los protocolos, e incluso seleccionar automáticamente cuál es el protocolo utilizado por el vehículo al cual se va a conectar.

2.4 Conectores En sus inicios, como se ha explicado al comienzo de esta sección, cada fabricante de automóviles instalaba diferentes conectores, especiales en cada marca y modelo. Desde la aparición de la norma OBD-II, este hecho cambió, estandarizándose un único tipo de conector, independientemente de la marca o modelo del vehículo.

Este conector estandarizado, conocido como “Conector OBD-II”, dispone de una interfaz de 16 pines. Aunque cuente con 16 pines, no todos ellos se emplean para la

42

comunicación con el escáner. Es más, se suelen utilizar únicamente uno o dos pines para transferir datos. Es por esta razón que no todas las hendiduras del conector poseen contactos.

Dependiendo del protocolo de comunicación que implemente, los pines de comunicación varían en su posición. Sin embargo, prácticamente todos los conectores OBD-II normalizados cuentan con 3 pines colocados en el mismo lugar poseyendo la misma función. Estos pines corresponden a las posiciones 4, 5 y 16, tal y como se muestra en la Figura 14 .

Figura 14. Pines del conector OBD-II [4]

El Pin 4 corresponde a la conexión masa al chasis del vehículo. El pin 5 corresponde a Masa o negativo proporcionado por el computador del vehículo. Por último, el pin 16 se corresponde con el positivo (BAT) directo desde la batería.

Por lo general son los pines 4 y 16 los que se emplean para proporcionarle alimentación eléctrica al escáner, haciendo que el dispositivo en cuestión se encienda al conectarlo al conector de diagnóstico. Aunque los escáneres de hoy día suelen incluir alimentación propia, ya sea por medio de batería o pilas, de igual forma suelen utilizar esta energía proporcionada por el vehículo para funciones específicas, como por ejemplo la iluminación de la pantalla.

Los demás pines, al margen del 4, 5 y 16, son considerados pines para activar funciones específicas, como por ejemplo la inducción de un auto diagnóstico.

Como se ha comentado en el apartado anterior, los vehículos OBD-II poseen uno, y solamente uno, de los protocolos explicados. Cada uno de estos cuatro protocolos emplea distintos pines de comunicación con el protocolo OBD-II. De esta forma, aparece una norma general para identificar si un vehículo emplea un protocolo u otro, la cual resumo a


43

continuación.

• ISO 9141. Si el conector OBD-II posee los pines 7 y 15, se comunica a través de este protocolo.

• SAE J1850 VPW. Si el conector OBD-II posee los pines 2 y 15, o en otro caso posee el pin 2 y NO posee el pin 10, se comunica a través de este protocolo.

• SAE J1850 PWM. Si el conector OBD-II posee los pines 2 y 10, se comunica a través de este protocolo.

• CAN-J2284. Si el conector OBD-II posee los pines 6 y 14, se comunica a través d este protocolo.

Además de los pines aquí especificados, es posible que el conector tenga otros pines, aunque estos no influyen en la conectividad [4].

2.4.1 Adaptadores Estos dispositivos se encargan de pasar la información desde el sistema OBD-II al dispositivo que nosotros decidamos, corriendo en él un programa o aplicación que permita traducir y mostrarnos esta información.

Se dividen en dos clases de adaptadores.

• Adaptadores USB. Estos dispositivos se conectan al conector hembra OBD-II del vehículo, y en el otro extremo del cable cuentan con un conector USB.

Figura 15. Adaptador USB

• Adaptadores WiFi y Bluetooth. Estos dispositivos se conectan de igual forma al conector OBD-II del coche. En el otro extremo tiene un emisor WiFi o Bluetooth que envía la información contenida en el sistema OBD-II. Mediante un dispositivo móvil o tableta se recoge dicha información.

44

Figura 16. Adaptador WiFi

2.5 Escáner OBD-II Para acceder a la información de error almacenada por el sistema OBD-II se precisa de un escáner OBD-II o un dispositivo de diagnóstico equivalente, el cual se conectará al conector OBD-II situado en el vehículo.

La forma de obtener esta información ha evolucionado en los últimos años, siendo capaces de conectarnos al sistema OBD-II mediante WiFi, Bluetooth o USB, dejando cada vez más en desuso el antiguo conector RS232. Esto es un avance puesto que actualmente se puede acceder a la información del vehículo mediante el uso de ordenadores portátiles y dispositivos móviles como smartphones o tabletas donde se pueda instalar una máquina de diagnosis.

2.5.1 Escáner OBD-II de mano Los dispositivos específicos de lectura cuentan con un conector macho para el conector del OBD-II hembra del automóvil. Estos dispositivos muestran directamente en su pantalla los posibles errores. Dependiendo de la calidad y precio nos ofrecerán más o menos información, llegando a evitarnos incluso la consulta a la tabla de códigos de errores.

Figura 17. Escáner OBD-II de mano


45

2.5.2 Programas informáticos escáner para OBD-II Si no se hace uso de un dispositivo específico de lectura, en el que es el propio dispositivo el que muestra la información, es necesario contar con un software o programa informático que interprete la información leída del vehículo y la muestre de manera correcta. Estos programas informáticos se pueden ejecutar tanto en ordenadores como en dispositivos móviles (smartphones). Aquí podemos diferenciar programas informáticos para móviles o tabletas, y software para PC.

2.5.2.1 Aplicaciones móviles Actualmente encontramos este tipo de aplicaciones en los principales sistemas operativos, Android e iOS. Estas aplicaciones se pueden encontrar tanto de manera gratuita como de pago. No todas son capaces de ofrecer la misma cantidad de información. Por lo general, los dispositivos Android precisan de adaptadores Bluetooth mientras que los dispositivos iOS suelen emplear la tecnología WiFi para recibir los datos.

Por una parte, en Android la aplicación más conocida y de mayor calidad es Torque Pro3 , y su versión restringida Torque Lite4, siendo la primera de ellas de pago y la segunda gratuita. Esta aplicación necesita de un adaptador Bluetooth. Torque ofrece información tal como las revoluciones por minuto reales del motor (RPMs), velocidad, aceleración, potencia del motor y par motor instantáneos, códigos de error del motor con información detallada, estado del sistema eléctrico y fusibles, seguimiento del mantenimiento del vehículo, lectura de emisiones y temperatura de transmisión. Además, permite la grabación del viaje (mediante la cámara del dispositivo móvil) con superposición de datos OBD-II.

La equivalente a esta aplicación en iOS se llama REV5. Esta aplicación es gratuita y permite detectar los códigos de error, lectura de emisiones, velocidad del vehículo.

2.5.2.2 Programas para PC Por su parte, también podemos encontrar programas informáticos de diagnóstico para PC. Gracias a los adaptadores, podremos hacer llegar la lectura de datos a nuestro computador a través de USB o WiFi, siendo el primero el más común. Existe una amplia variedad de programas de software escáner capaces de interpretar y mostrar la información recogida, tanto gratuitos como de pago.

El programa Scantool.net 1.13 se trata de un software de código libre, por lo tanto, gratuito. De manera oficial, este programa lo encontramos en su versión única para sistemas operativos Windows. Sin embargo, no es el único software que ofrece esta

3 https://play.google.com/store/apps/details?id=org.prowl.torque&hl=es 4 https://play.google.com/store/apps/details?id=org.prowl.torquefree&hl=es 5 https://itunes.apple.com/us/app/r.e.v.-robotic-enhanced-vehicles/id968261465?mt=8

46

marca. De manera no gratuita, Scantool6 nos ofrece otros programas software muchos más profesionales y con funcionalidades más avanzadas, tales como ScanXL Standard o ScanXL Professional, ambos también disponibles únicamente para Windows.

EasyOBD II 7 se trata de un programa software que en su versión Lite es gratuito, con la posibilidad de obtener la versión completa por un precio no muy elevado, en comparación con los programas software de Scantool. En su versión gratuita encontramos funcionalidades tales como convertir a PDF la información recogida, compatibilidad con adaptadores USB y Bluetooth, lectura de errores y MIL, soporte de datos CAN, y cabe destacar que únicamente está disponible para sistemas operativos Windows. La diferencia de versión Lite a la versión completa es la cantidad de elementos de la Lista de PID soportados, siendo mucho mayor en la versión completa.

2.6 Chip ELM327 El chip ELM327, mostrado en la Figura 18, se trata de un microcontrolador programado, producido por ELM Electronics8, que permite la traducción de la interfaz OBD-II.

El microcontrolador ELM327 funciona como un puente entre los puertos OBD-II del vehículo y una interfaz estándar RS232 serial. El ELM327 soporta una gran variedad de protocolos SAE e ISO, siendo capaz de comunicarse con cualquier vehículo OBD-II. Además de poder detectar e interpretar de forma automática nueve protocolos OBD, el ELM327 provee soporte para comunicaciones de alta velocidad, un modo de bajo consumo de energía y el estándar J1939 para vehículos de carga pesada.

Figura 18. ELM327 [6]

Aunque la comunicación esté pensada para RS232, la salida corresponde a UART9 a la

6 https://www.scantool.net 7 http://www.easyobdii.com 8 https://www.elmelectronics.com 9 Siglas en inglés de Universal Asynchronous Receiver-Transmiter, dispositivo que controla los puertos y dispositivos serie.


47

cual se le pueden conectar interfaces tanto RS232 como USB, Bluetooth o similares. Si todo es correcto, el microcontrolador nos devolverá un mensaje donde se recoge su nombre y la versión del software similar a este:

ELM 321 v2.1

>

El símbolo > es el prompt, lo que nos indica que podemos introducir comandos para comenzar la comunicación. Los parámetros del ELM327 pueden ser ajustados para modificar su comportamiento mediante el uso de los comandos AT. En la siguiente tabla queda recogida una relación de los comandos AT que pueden ser empleados para dicha finalidad.

Comando Descripción

AT Repite el último comando

AT E0

AT E1

Eco encendido

Eco apagado

AT Z Reset

AT @1

AT @2

Descripción del componente

Identificación del componente

AT RV Lee el voltaje del vehículo

AT DP Describe el protocolo actual del vehículo

AT SP h Utilizar el protocolo h de la tabla y grabarlo

AT TP Ah Intenta comunicarte con el protocolo h y sigue buscando

AT D Regresa el ELM 327 a sus valores iniciales Tabla 3. Comandos AT ELM327

2.6.1 Comunicación con el vehículo Los comandos OBD-II son enviados embebidos en paquetes de datos al vehículo. La mayoría de estándares de comunicación necesitan que estos mensajes OBD contengan tres bytes de cabecera y un byte de comprobación de error. Sin embargo, la longitud de estos mensajes puede OBD puede variar. Por ello el ELM327 es quien añade ese byte extra o limita el tamaño para ajustarlo a lo necesario. Para el intercambio de datos entre el ELM327 y el OBD-II se emplean dígitos

48

hexadecimales, ya que es el formato estándar usado en OBD-II. Los estándares requieren que cada comando OBD o petición que es enviada al vehículo se ajuste a un formato. El primer byte del comando enviado (conocido como modo10), el cual describe el tipo de dato que se está pidiendo. El segundo byte y, posiblemente, tercer byte o más, especifican la información pedida (conocida como PID10). Como ejemplo de este formato de mensaje, supondremos hacer una petición de la temperatura del vehículo. El mensaje de petición quedaría del siguiente modo: >01 05

El dígito 01 representa el modo OBD-II al que nos referimos11, mientras que 05 indica el PID correspondiente a la temperatura. A continuación, el mensaje de respuesta recibido quedaría similar al siguiente: >41 05 7B

El dígito 41 indica la respuesta al modo 1 (1 + 4012), 05 indica el PID que ha sido pedido. Por último, encontramos un byte en hexadecimal el cual nos indica el dato que estamos pidiendo. En decimal, este dato quedaría 123. Sabiendo que la fórmula11 para obtener la temperatura es A-40, sabemos que el dato que estamos recibiendo como respuesta es 40ºC. El resto de modos y PIDs funcionan de manera similar al ejemplo mostrado [6].

10 Puede dirigirse a la sección 2.3.3 Modos y parámetros OBD-II para más información. 11 Información recogida en la Tabla 2. PIDs OBDII e interpretación. 12 En caso de ser al modo n sería n + 40.


49

3. Hardware

En este capítulo quedan recogidos todos los elementos hardware implicados en la elaboración de este Trabajo Fin de Grado, así como el montaje final. Este montaje permite la simulación de la conexión entre la ECU de un vehículo y PC, y el intercambio de información entre ellos. Gracias a esto, se ha podido llevar a cabo el desarrollo de la aplicación objeto de este TFG de manera simplificada, para, una vez ha sido finalizada, proceder a su instalación en un ordenador de a bordo de un vehículo real.

50

3.1 Arduino Arduino es una plataforma de código abierto usada para la fabricación de proyectos electrónicos. La plataforma Arduino consiste en dos partes. La primera de ellas es una parte física formada por una placa de circuito programable, conocida normalmente como microcontrolador. Por otro lado, una segunda parte software o IDE13, la cual corre sobre el computador. Este entorno de desarrollo se usa tanto para escribir como para cargar el código deseado a la placa física, consiguiendo el funcionamiento deseado del circuito.

El IDE de Arduino está disponible en plataforma Windows, Mac y Linux. Se trata de un entorno de programación empaquetado en forma de aplicación, desde el cual podemos editar código, compilarlo, depurarlo e, incluso, construir una interfaz gráfica (GUI), además de permitir cargar el programa ya compilado sobre la memoria flash de la placa. Este hecho hace que no sea posible acceder al código cargado sobre el hardware.

El lenguaje de programación de Arduino está basado en C++, permitiendo usar comandos básicos de este lenguaje en la elaboración del código. Puede encontrar referencias de uso del lenguaje Arduino en este enlace14.

La estructura básica de un programa Arduino se divide, al menos, en dos partes necesarias, las cuales deben ser incluidas obligatoriamente en el programa, aunque no contengan ninguna declaración.

La primera de ellas es la función setup(), conocida como función de configuración. Se encarga de contener la declaración de las variables. Se ejecuta al comienzo y una única vez, para inicializar las E/S, la comunicación serie y otras.

Por otra parte se encuentra la función loop(), la cual contiene el código que se ejecutará continuamente de forma cíclica, siendo la que función central que realiza la mayor parte del trabajo [7].

Respecto a la placa, la versión de Arduino empleada en este proyecto es Arduino Uno, mostrada en la Figura 19. Arduino Uno utiliza un microcontrolador basado en el ATmega328. Cuenta con 14 pines digitales de entrada/salida de los cuales 6 pueden ser empleados como salidas PWM, 6 entradas analógicas, un puerto USB, un conector Jack y un botón de reseteo, entre otros. Para su funcionamiento basta conectarlo al PC mediante el puerto USB, o alimentarlo con una batería o adaptador AC-DC [8], [9].

13 Del inglés Integrated Development Environment (Entorno de Desarrollo Integrado). 14 https://www.arduino.cc/en/Reference/HomePage


51

Figura 19. Placa Arduino Uno

3.2 Módulo CAN-BUS El módulo CAN-BUS provee de capacidad CAN-BUS a la placa Arduino. Esta placa, mostrada en la Figura 20, dota a la placa Arduino de conectividad CAN, permitiéndole consultar la ECU para obtener la información que se desee del vehículo, además de almacenarla y mostrarla por pantalla.

La placa CAN-BUS usa el controlador CAN MCP2515 (ver Figura 21) con interfaz SPI (Serial Peripheral Interface) y con el transceptor CAN MCP2551(ver Figura 22) [10].

Figura 20. Módulo CAN-BUS

52

3.2.1 Controlador CAN MCP2515 El controlador MCP2515 es un controlador autónomo que implementa la conectividad CAN versión 2.0B. Este controlador es capaz de transmitir y recibir datos tanto de tipo estándar como extendidos, y tramas remotas.

El MCP2515 cuenta con dos máscaras y seis filtros de aceptación utilizados para filtrar mensajes no deseados. Esto reduce la sobrecarga en los microcontroladores [11].

Figura 21. Controlador MCP2515

3.2.2 Transceptor MCP2551 El MCP2551 es un dispositivo CAN de alta velocidad, tolerante a fallos que sirve como interfaz entre un controlador de protocolo CAN y el bus físico. El dispositivo MCP2551 proporciona una capacidad de transmisión y recepción diferencial para el controlador de protocolo CAN y es totalmente compatible con la norma ISO-11898, incluidos los requisitos de 24V. Este dispositivo funciona a velocidades de hasta 1 Mb/s.

Normalmente, cada nodo en un sistema CAN debe contener un dispositivo para convertir las señales digitales generadas por un controlador CAN, en señales adecuadas para la transmisión a través del cableado del bus (salida diferencial). También proporciona un búfer entre el controlador CAN y los picos de alta tensión que pueden generarse en el bus CAN por fuentes externas (EMI, ESD, transitorios eléctricos, etc.) [12].

Figura 22. Transceptor MCP2551


53

3.3 Escáner ELM327 El escáner EML327 se trata de un conector de diagnosis para vehículos. Su funcionamiento se basa en la comunicación mediante USB, soportando todos los protocolos de OBD-II y CAN.

El uso de esta interfaz permite leer los códigos de averías, tanto genéricos como específicos de fabricantes, borrar los códigos de avería apagando la luz de ésta, y mostrar los datos actuales de los datos de los sensores del motor.

Aunque existen varios tipos de interfaces ELM327, como por ejemplo WiFi o Bluetooth, en el caso de este proyecto, nuestro montaje contiene una interfaz con cable USB similar a la mostrada en la Figura 23.

Figura 23. Interfaz ELM327

3.4 Ordenador El último elemento hardware a tener en cuenta en el montaje de este proyecto es el PC. Con él se alimenta la placa Arduino Uno, y la interfaz ELM327 lee y recibe la información.

En el ordenador se aloja la aplicación fruto de este TFG, cuya finalidad, funcionamiento y contenido quedan detallados en el capítulo 4.

En ordenador cuenta con sistema operativo Windows 10 y con, al menos, dos puertos USB libres.

54

3.5 Montaje Una vez explicados todos los elementos que conforman el montaje completo (ver Figura 26 ), se procede a la explicación de la conexión entre ellos.

Primero encontramos el escáner ELM327. El conector USB del propio escáner se conecta a uno de los puertos USB de nuestro PC. El escáner, a su vez, está conectado al módulo CAN-BUS mediante dos cables o jumpers, tal y como se indica en la Figura 24. Esta parte del montaje es la que permite enviar y recibir del PC los datos leídos del bloque CAN-BUS/Arduino, lo que representa la ECU del vehículo simulado.

Figura 24. Esquema de conexión entre placas

El siguiente elemento que encontramos es el CAN-BUS, montado sobre la placa Arduino. Como se ha comentado anteriormente, este bloque de dos elementos es el que permite que la se pueda consultar la ECU para obtener los datos pedidos que llegan desde el OBD-II, además de proporcionar un método de almacenamiento.

Se hará uso de un cable USB tipo A/B para la alimentación de la placa Arduino. Esta, a su vez, será la encargada de alimentar a la placa CAN-BUS y a la placa breadboard o placa de simulación, explicada a continuación.

Por último, se encuentra la placa breadboard. La breadboard es una forma de construir circuitos electrónicos sin tener que soldar. Los componentes son colocados en los agujeros de la breadboard y con cables jumper haremos las conexiones.


55

Figura 25. Montaje. Placa breadboard y placa CAN-BUS sobre placa Arduino

Los elementos que conforman la placa breadboard (ver Figura 25 ) montada son:

• Potenciómetros (1 en Figura 25). Cuenta con dos potenciómetros los cuales simulan la fluctuación de los datos emitidos por la ECU del vehículo simulado mediante señales analógicas. A medida que giramos los potenciómetros, notaremos como esto se traduce en el aumento o disminución de los valores recogido por nuestra aplicación. El potenciómetro número 1 hace acción directa en los valores de la velocidad del vehículo. El potenciómetro 2, actúa sobre los valores de la batería. El resto de parámetros hace uso de la variación de ambos potenciómetros15.

• LED (2 en Figura 25). Este led simula el comportamiento del indicador MIL del vehículo. Se enciende una vez pulsamos el botón incluido en esta placa y se apaga cuando el usuario envía a través de la aplicación la orden de limpiar los códigos de error (Tabla 1. Modos OBD-II).

• Botón (3 en Figura 25). Su única función es encender el LED y mandar a la placa Arduino la orden de enviar un código de error al OBD-II.

• Resistencias y cables. Permiten el correcto funcionamiento e integración de todos los elementos anteriormente comentados.

15 Es la aplicación incluida en la placa Arduino la que se encarga de usar directamente los potenciómetros para, mediante sus propias fórmulas, calcular los valores enviados al OBD-II.

56

Figura 26. Montaje completo


57

4. Software

En este capítulo se detalla el propósito de la aplicación elaborada en este TFG, la cual se ha denominado eCo Application, su contenido y completo funcionamiento, sirviendo de manual para la puesta en marcha y uso normal. También se recogerá una breve explicación del código Arduino incluido en la placa, el cual permite la simulación de la ECU de un vehículo eléctrico, dando sentido al montaje y al uso de la aplicación.

58

4.1 eCo Application El desarrollo de este TFG se centra en la creación de eCo Application. Su nombre ha sido pensado para hacer alusión a la comunicación que se realiza entre las placas que simulan la ECU del vehículo y el PC, además del doble sentido referido a “Ecológico”, ya que el vehículo para el que ha sido pensada la aplicación es un vehículo eléctrico.

La funcionalidad principal de esta aplicación es proporcionar un entorno gráfico desde el cual poder ver por pantalla la información de diagnóstico solicitada a la ECU un vehículo eléctrico, tales como velocidad, temperatura, revoluciones por minuto y batería del coche eléctrico. Además, permite modificar el nombre del puerto por el cual se debe leer y la velocidad de lectura, de cara a una futura modificación de alguno de los componentes de la parte hardware del montaje o configuración del propio ordenador.

La aplicación también permite imprimir en un archivo de texto plano (de extensión “.txt”) los datos enviados y recibidos durante la lectura de información.

La muestra de información por pantalla es posible gracias a la creación y traducción de los mensajes OBD-II y comandos AT que se envían y reciben en la comunicación.

4.1.1 Entorno gráfico (GUI – Front-end) La aplicación se divide en tres pestañas, Inicio, Medidas y Datos, y una ventana de Ajustes. A continuación, se explica el contenido y funcionalidad de cada una de ellas.

4.1.1.1 Pestaña Inicio Es la pestaña que se muestra una vez iniciamos la aplicación. Tal y como se aprecia en la Figura 27, desde aquí podemos acceder a la pestaña de Medidas y de Datos, así como abrir la ventana de Ajustes desde los tres botones mostrados en mitad de la ventana.


59

Figura 27. eCo Application - Inicio

4.1.1.2 Pestaña Medidas La función de esta pestaña es mostrar los datos leídos y traducidos del vehículo. En esta pestaña encontramos los botones que permitirán iniciar, suspender y detener la lectura de datos, un indicador que cambiará su color para avisar de un error (indicador MIL) y la zona de muestra de datos donde aparecerá la velocidad, rpm, batería y temperatura leído del coche.

Figura 28. eCo Application – Medidas. Botón Iniciar pulsado

60

Figura 29. eCo Application – Medidas. Botón Suspender pulsado y MIL activo

A continuación, se indica el nombre y función de cada botón activo en esta pestaña mostrada en la Figura 29.

• Iniciar. Permite, como su nombre indica, iniciar la petición y lectura de datos. Una vez iniciado, es posible tanto suspender la lectura desde el botón Suspender como el botón Detener.

• Suspender. Permite detener momentáneamente la lectura permitiendo reanudarla desde donde se quedó al volver a hacer clic sobre el botón Iniciar.

• Detener. Únicamente activo cuando se ha hecho clic previamente el botón Iniciar. Detiene por completo la conexión. Esta acción cierra los puertos de lectura, siendo necesario establecer de nuevo la conexión para volver a empezar la lectura. A su vez, limpia la ventana de Datos.

• Errores. Únicamente activo cuando la aplicación detecta que se ha activado el indicador MIL del montaje. Al hacer clic este botón se limpiarán los mensajes de error y se apagará la luz del indicador MIL.

4.1.1.3 Pestaña Datos En esta pestaña se muestran todos los mensajes OBD-II y comandos ELM327 intercambiados entre la aplicación y el montaje conectado.

Estos mensajes se muestran en bruto, es decir, sin traducir, tal y como se muestra en la Figura 30. En el lado derecho se alinean los mensajes de petición, y en el lado izquierdo los de respuesta.

Esta pestaña limpia los mensajes mostrados cada vez que detenemos la conexión (Ver 4.1.1.2 en botón Detener, o 4.1.1.4).

Los datos mostrados en esta pestaña son los que se escriben en el archivo .txt (Figura 31) que se crea al iniciar la lectura de datos. En este archivo se almacenan todos los


61

comandos, sin importar si hemos detenido o no la conexión.

Figura 30. eCo Application - Datos. Ejemplo en funcionamiento

Figura 31. eCo Application – Archivo “.txt” generado

4.1.1.4 Ventana Ajustes Esta ventana se abre al hacer clic desde la pestaña de Inicio el botón de Ajustes, y se

62

cierra automáticamente al dirigirnos a cualquiera de las demás pestañas del menú de la aplicación, impidiendo que se puedan modificar datos de la lectura de mensajes mientras la conexión está activa. Puede ver una captura de pantalla en la Figura 32.

Figura 32. eCo Application - Ajustes

Primero encontramos el campo Puerto, por defecto con el valor COM6. Este campo indica el nombre del puerto USB al cual está conectado el cable ELM327, por el cual se establecerá la conexión.

En el segundo campo encontramos la Velocidad de Transmisión, por defecto con el valor 38400. El cable con el que se trabaja en este proyecto necesita de este dato concreto, por lo que no será necesario modificarlo.

Para poder modificar estos valores, primero será necesario detener la conexión.

El botón Comprobar conexión y conectar permite iniciar la comunicación. Esta acción envía el comando ELM327 “AT Z” para comprobar que se puede iniciar satisfactoriamente la conexión. En caso contrario aparecerá un mensaje de error.

4.1.2 Código (Back-end) Como se comentó en la introducción de este documento, esta aplicación ha sido desarrollada haciendo uso de Microsoft Visual Studio 2015. Visual Studio es un entorno de desarrollo integrado (IDE). Este IDE ofrece un conjunto de herramientas de desarrollo para aplicaciones web, Servicios Web, aplicaciones de escritorio y aplicaciones móviles [13]. La aplicación desarrollada en este TFG es una aplicación de escritorio administrada, escrita en el lenguaje de programación C++/CLI (Visual C++). Visual C++ hace uso de las funciones de .NET Framework, compilado por CLR (Common Language Runtime). .NET Framework es una tecnología que soporta la compilación y ejecución de aplicaciones y servicios WEB XML de última generación. Esta tecnología cumple con los


63

siguientes propósitos, entre otros:

• Proporcionar un entorno de programación orientada a objetos, donde el código se almacene y pueda ser ejecutado tanto en modo local como remota.

• Disminuir los conflictos en el despliegue y visionado de software. • Promover la ejecución segura en el entorno de programación.

• Basar toda la comunicación en estándares del sector para asegurar que el código de .NET Framework se puede integrar con otros tipos de código.

• Proporcionar un entorno de ejecución de código que elimine los problemas de rendimiento de los entornos en los que se utilizan scripts o intérpretes de comandos.

Los dos componentes más importantes de .NET Framework son la propia biblioteca de clases de .NET Framework, y CLR. En la Figura 33 se ilustra la relación existente entre todos estos elementos descritos.

CLR es el motor en tiempo de ejecución, el cual se puede considerar como un administrador de código en tiempo de ejecución y proporciona servicios centrales, como la administración de la memoria, la administración de subprocesos y la comunicación remota.

De esta forma, el código destinado al motor en tiempo de ejecución se denomina código administrado, y el resto de código se conoce como código no administrado. Es una diferencia a tener en cuenta a la hora de desarrollar la aplicación, ya que la inclusión y cooperación de código administrado junto a código no administrado hay que tratarla de manera específica. Por su parte, la biblioteca de clases es una colección orientada a objetos, pudiéndose emplear para desarrollar aplicaciones que contienen herramientas de interfaz gráfica de usuario (GUI o front-end), es decir, la base de la aplicación aquí desarrollada [14].

64

Figura 33. Relación de términos en .NET Framework [14]

A grandes rasgos, la aplicación genera las tramas OBD-II para la conexión y petición de datos, y de la traducción de las tramas OBD-II que recibe en la lectura. Para que esto sea posible, ha sido necesario la creación de un único hilo que haga de esta petición y lectura, de manera independiente a la navegación del usuario por la aplicación, funcionando este hilo en segundo plano. El código que genera y usa el hilo es código no administrado. El resto de código empleado en la aplicación es código administrado.

El código puede ser dividido en tres partes bien diferenciadas.

La primera de ellas es la parte de inicialización del entorno gráfico. En esta parte del código se recoge la declaración de los elementos del entorno gráfico, así como la inicialización de cada uno de los elementos que lo componen (ventanas, pestañas, botones, imágenes, fondos, etc.). La inicialización de todo ello se lleva a cabo con la llamada a la función InitializeComponent().

Esta primera parte también recoge las variables globales definidas para hacer uso en todo el programa, tales como banderas, variables para la generación de ficheros y la inicialización de hilos.

La segunda parte recoge las funciones de interacción con el entorno gráfico, lo que se denomina Eventos.

La tercera parte está formada por las funciones propias, las cuales sirven de apoyo a los Eventos para llevar a cabo el cometido final de la aplicación.

4.1.2.1 Función pictureBox_ON_Click(…) Este evento se ejecuta al pulsar sobre el botón Comprobar conexión y conectar de la


65

ventana Ajustes. En la Figura 34 se indica el diagrama de flujo de esta función.

Antes de realizar ninguna acción comprueba si el puerto está abierto o cerrado mediante una bandera.

En caso de estar conectado, detiene la conexión y actúa en consecuencia cambiando las imágenes y botones necesarios que indican que la conexión no está realizada.

En caso contrario, procede abrir el puerto y montar el mensaje ATZ que será enviado para comprobar que la conexión se ha realizado con éxito. Se cambian las imágenes de acuerdo a la conexión y se muestra un mensaje de éxito.

Figura 34. Diagrama de flujo de la función pictureBox_ON_Click()

4.1.2.2 Función button_iniciar_Click(…) Este evento se ejecuta al pulsar sobre el botón Iniciar de la pestaña Medidas. En la Figura 35 se indica el diagrama de flujo de esta función.

En primer lugar, se cierra la pestaña de Ajustes en el caso de que estuviese abierta, evitando posibles modificaciones que interrumpan el correcto funcionamiento. A continuación, se comprueba el estado del hilo encargado de ejecutar en segundo plano el envío y lectura de datos. En caso de estar detenido, este hilo se inicia. En caso de estar iniciado y suspendido temporalmente, se reinicia. En caso de estar iniciado, no se hace nada.

El hilo es el encargado de ejecutar la función Loop_lectura() explicada en el punto 4.1.2.6.

Mientras la lectura está en marcha, es decir, el botón Iniciar haya sido pulsado, el usuario no podrá ni detener la lectura, ni, en caso de que fuera necesario, limpiar los códigos de error. Estas acciones solo están disponibles desde el estado de pausa de la lectura, activado por el botón Suspender de la ventana Medidas comentada en el apartado

66

4.1.2.4.

Figura 35. Diagrama de flujo de la función button_iniciar_Click

4.1.2.3 Función button_detener_Click(…) Este evento se ejecuta al pulsar sobre el botón Detener de la pestaña Medidas. En la Figura 36 se indica el diagrama de flujo de esta función.

A este botón solo se podrá acceder previamente pulsando sobre el botón Suspender de la pestaña Medidas, cuyo funcionamiento se explica en el apartado 4.1.2.4.

Este evento comienza suspendiendo el Hilo, en caso de estar iniciado, y cierra el Puerto Serie, deteniendo así la comunicación por completo con el dispositivo OBD-II. A continuación, se actualizan los iconos mostrados en la ventana Ajustes, acorde a la condición de desconexión, además e ponen los indicadores de datos a valor cero.

Por último, la información mostrada en la pestaña Datos se elimina.

Una vez activado este botón, deja de ser accesible/visible.


67

Figura 36. Diagrama de flujo de la función button_detener_Click()

4.1.2.4 Función button_suspender_Click(…) Este evento se ejecuta al pulsar sobre el botón Suspender de la pestaña Medidas. En la Figura 37 se indica el diagrama de flujo de esta función.

La función comienza comprobando el estado del Hilo, para, en caso de estar activo, suspenderlo.

A continuación, se comprueba el estado del indicador MIL. Si ha sido activado, se hará visible el botón Errores de la pestaña Medidas cuya funcionalidad se explica en el apartado 4.1.2.5.

Finalmente, se muestra el botón Detener haciendo posible su uso.

68

Figura 37. Diagrama de flujo de la función button_suspender_Click()

4.1.2.5 Función button_errores_Click(…) Este evento se ejecuta al pulsar el botón Errores de la pestaña Medidas. En la Figura 38 se indica el diagrama de flujo de esta función.

Para poder limpiar los códigos de errores primero cerramos el puerto para forzar a detener la conexión, y acto seguido se vuelve a abrir.

Se manda el mensaje OBD-II necesario para limpiar los códigos de error (consultar Tabla 1. Modos OBD-II), y se añade la línea al texto mostrado en la pestaña Datos.

Por último, se cambia la imagen de indicador de errores a su modo apagado y se oculta el botón de errores.

Sí

No


69

Figura 38. Diagrama de flujo de la función button_errores_Click()

4.1.2.6 Función Loop_lectura() Esta función es llamada cuando se inicia el hilo encargado de leer y escribir en segundo plano para petición y recepción de los datos enviados en el montaje. En la Figura 39 se indica el diagrama de flujo de esta función.

La función consta de 4 partes o conjunto de sentencias. Cada una de estas partes, las cuales se leen de manera secuencial y repetitiva, se encarga de pedir la información necesaria (velocidad, RPM, temperatura y batería, en ese orden) y leer la trama devuelta.

De esta trama se extraen los caracteres que representan el dato de valor pedido, y se convierte a su unidad correspondiente haciendo uso de la fórmula necesaria (ver Tabla 2. PIDs OBDII e interpretación) y de la función Hex_convert() (ver Otras funciones).

Una vez obtenido el dato, se imprime en la pestaña Datos, junto a su unidad de medida. A su vez, todos los mensajes intercambiados se escriben en la pestaña Medidas.

70

Figura 39. Diagrama de flujo de la función Loop_lectura()

4.1.2.7 Otras funciones

• MyForm_Load(): Este evento se lanza una vez la interfaz gráfica (Form) se ha cargado por completo. Se usa para determinar algunas especificaciones necesarias antes de que el usuario comience con el uso de la aplicación.

• Button1_Click(): Evento lanzado cuando se pulsa sobre el botón de Ajustes de la pestaña Inicio. Este evento, antes de abrir la venta a de Ajustes, comprueba si la conexión del puerto serie esta iniciada y recuerda que para modificar los parámetros de ajustes es necesario detener primero la conexión.

• Button2_Click(): Este evento se lanza cuando se pulsa sobre el botón de Medidas de la pestaña Inicio. Este evento muestra la pestaña Medidas.

• Button3_Click(): Este evento se lanza cuando se pulsa sobre el botón de Datos de la pestaña Inicio. Este evento muestra la pestaña Datos.

• Hex_convert(): Función propia que recibe como parámetro una cadena String^ y devuelve una cadena String^. Una llamada a esta función convierte la cadena de caracteres pasada expresada en hexadecimal a su equivalente cadena expresada en decimal y devuelve esta última.


71

• MyForm_FormClosing(): El evento FormClosing se lanza una vez pulsado el botón de cierre de la aplicación. Antes de cerrar la aplicación, se detiene el hilo por completo y se cierra el puerto para que no haya ningún problema a la hora de iniciar la aplicación de nuevo. Además, se muestra un mensaje de aviso donde se indica que el fichero de datos ha sido generado.

4.2 Código Arduino Como se comentó en el capítulo 3, la placa Arduino junto al módulo CAN son los encargados de simular la ECU del vehículo. Para que esto sea posible, la placa Arduino incluye un código que simula este comportamiento. Gracias a este código se ha conseguido probar y testar el correcto funcionamiento de la aplicación objeto de este TFG.

Este código fue desarrollado por José Beltrán Zambrano en la realización de su TFG “Desarrollo de un simulador electrónico de una ECU y su diagnóstico sobre CAN y OBD-II” [15]. Dicho código se encarga de procesar los mensajes de petición OBD-II y operar de manera correcta para responder a estas peticiones.

Tal y como comenta el autor en su trabajo, el código Arduino cuenta con las siguientes funcionalidades:

• Leer e interpretar mensajes OBD-II, siendo capaz de detectar peticiones en los Modos 01, 03 y 04.

• Contestar a las peticiones OBD-II en Modo 01, leyendo las entradas digitales y analógicas de la placa de que simula señales reales de un vehículo, generando la respuesta OBD-II con los datos obtenidos en tiempo real y enviando dicha respuesta vía CAN.

• Testeo continuo del vehículo simulado, almacenando DTCs en caso de error y encendiendo el indicador luminoso MIL. Además, implementa un contador de kilómetros y de minutos desde que ocurrió un dicho error.

• Contestar a las peticiones OBD-II en Modo 03, comprobando el estado del vehículo simulado y respondiendo con el DTC correspondiente en caso de error.

• Borrar códigos de error cuando sea solicitado mediante el Modo 04 de OBD-II.

72

5. Conclusiones y trabajos futuros

En este último capítulo se recogen presentan las conclusiones recogidas a lo largo del desarrollo del trabajo. Se incluyen, además, las posibles líneas de continuación de este trabajo.


73

5.1 Conclusiones En el desarrollo de este trabajo de fin de grado se ha desarrollado una aplicación para el ordenador de a bordo de un vehículo eléctrico, específicamente para visualizar la información de la ECU del mismo, llamada eCo Application. Para poder comenzar con tal desarrollo, ha sido necesario hacer un repaso teórico de las comunicaciones internas de un vehículo, explicando qué es y cómo funciona un Bus CAN, así como el protocolo de diagnóstico OBD-II.

Todo el marco teórico incluido en este TFG era necesario principalmente para comprender y abordar el problema que ha dado pie al desarrollo de este trabajo: implementar una aplicación para interpretar la lectura de datos del vehículo. Además, sin los conocimientos planteados, resulta imposible la realización y comprensión del montaje software y hardware incluido en este trabajo, parte fundamental para comprobar el correcto funcionamiento de la aplicación desarrollada.

La finalidad de este trabajo ha sido desarrollar una aplicación ajustada a la línea de trabajo que otros compañeros del departamento venían realizando, para dar cierre, en términos generales, a un proyecto que cuenta con diversas partes. Esta aplicación hace posible el visionado mediante una interfaz gráfica intuitiva de los principales datos de interés de un vehículo eléctrico. A su vez está pensada para ser montada sobre cualquier ordenador de a bordo de un vehículo real, o simulado en su caso.

5.1.1 Problemas encontrados y soluciones aportadas Durante el desarrollo de este proyecto han ido surgiendo ciertos problemas, los cuales han ido siendo solventados tomando decisiones de diseño e implementación específicas.

Uno de los primeros problemas que se plantearon fue la comunicación eCo Application-OBDII. Fue necesario la búsqueda exhaustiva de información para determinar los comandos necesarios y la velocidad de lectura que se precisaba en nuestra comunicación, haciendo uso de la interfaz proporcionada por el chip ELM327. No obstante, este problema resultó de rápida resolución.

El siguiente problema fue planteado cuando, durante el desarrollo de la aplicación, se tomó consciencia de que era necesario hacer que la aplicación enviara y recibiera información de la ECU simulada de manera ininterrumpida mientras el usuario pudiera seguir navegando por la aplicación. Para la lectura y escritura, es necesario mantener el puerto abierto y trabajando de forma seguida. La única forma de realizar esto es mediante el uso de hilos. En nuestro caso, con un único hilo ha sido suficiente, ya que solo mantenemos un puerto abierto.

Momentáneamente parecía que la solución era sencilla: la aplicación debía manejar un hilo en segundo plano. Sin embargo, de aquí surgía otro problema. La aplicación ha sido creada a partir de un proyecto CLR/.NET. Este tipo de proyectos usa código no gestionado (unmanaged code), y la creación de hilos se realiza mediante código gestionado (managed code). La principal diferencia entre un tipo y otro es que el código gestionado es el creado directamente por el compilador, ya que el código es gestionado

74

por el compilador CLR. Por ello la creación de un hilo es código no manejado. Esto supuso un problema, principalmente por la necesidad de comprensión en esta diferencia. Una vez entendido, la solución fue realizar la conversión de código no gestionado a código gestionado en la creación y manejo del hilo.

5.2 Trabajos futuros La idea de aplicación desarrollada en este trabajo es compleja y con muchas posibles líneas de mejora. Por ello, se proponen varias opciones para continuar ampliando y mejorando las funciones de esta aplicación.

• Mayor número de sensores. Una de las propuestas ofrecidas es ampliar el número de sensores que la aplicación es capaz de leer. Esto se podría realizar de múltiples maneras, aunque una de ellas sería poder elegir, mediante desplegables, el sensor mostrado en la pestaña Medidas, manteniendo un máximo de 4 o 6 sensores en pantalla. De esta forma, sigue siendo una aplicación visual y sencilla a la hora de obtener de manera rápida la información deseada. Esto parece crucial para una aplicación destinada a instalarse en un vehículo.

• Creación de un instalador y/o ejecutable. Otra propuesta interesante sería la realización de un instalador o ejecutable que permitiese portar la aplicación de un sistema a otro. Además, facilitaría la instalación y puesta en marcha en los dispositivos destinos que se deseen.

• Mejoras en el archivo generado. Actualmente, la aplicación genera un archivo de texto en formato “.txt” que contiene todos los mensajes intercambiados en la comunicación. Una opción de mejora consistiría en incluir en este archivo valores medios de toda la información intercambiada, o, incluso, la generación de gráficas. Además, podría incluir la opción de exportar el documento en otros formatos de texto.

• Gráficas en tiempo de ejecución. Una de las propuestas, quizás más complejas por el lenguaje de programación empleado, sería la de generar, en tiempo de ejecución, gráfica de los datos leídos por la aplicación.


75

REFERENCIAS

[1] E. Zabler, Los sensores en el automóvil, Serie Amarilla ed., Reverté, 2002.

[2] R. Bosch, CAN Specification, Stuttgart: BOSCH, 1991.

[3] CiA (CAN in Automation), «CiA,» [En línea]. Available: https://www.can-cia.org/can-knowledge/.

[4] K. Mucevski, «OBD-II Connector and Fault Codes Explained, Linkedin,» [En línea]. Available: https://www.linkedin.com/pulse/obd-ii-connector-fault-codes-explained-kiril-mucevski.

[5] Areamecánica, «AreaMecánica,» [En línea]. Available: http://automecanica50.blogspot.com.es/2017/02/.

[6] ELM Electronics, «ELM Electronics,» [En línea]. Available: https://www.elmelectronics.com/wp-content/uploads/2016/07/ELM327DS.pdf.

[7] Arduino, «Language Reference,» [En línea]. Available: https://www.arduino.cc/en/Reference/HomePage.

[8] Arduino, «Arduino UNO,» [En línea]. Available: https://www.arduino.cc/en/Main/ArduinoBoardUno.

[9] Sparkfun, «What is an Arduino?,» [En línea]. Available: https://learn.sparkfun.com/tutorials/what-is-an-arduino.

[10] Sparkfun, «CAN_BUS Shield,» [En línea]. Available: https://www.sparkfun.com/products/13262.

[11] Microchip Technology Inc., «MCP2515,» [En línea]. Available: http://ww1.microchip.com/downloads/en/DeviceDoc/21801F.pdf.

[12] Microchip Technology Inc., «MCP2551,» [En línea]. Available: http://ww1.microchip.com/downloads/en/DeviceDoc/21667f.pdf.

[13] Microsoft, «Welcome to Visual Studio 2015,» [En línea]. Available: https://msdn.microsoft.com/en-us/library/dd831853.aspx.

[14] Microsoft, «CLR/.NET Framework,» [En línea]. Available: https://msdn.microsoft.com/es-es/library/zw4w595w(v=vs.110).aspx.

[15] J. B. Zambrano, Desarrollo de un simulador electrónico de una ECU y su diagnóstico sobre CAN y OBD-II.

[16] G. Lara, «Motorpasión Futuro,» [En línea]. Available:

76

https://www.motorpasionfuturo.com/industria/can-bus-como-%20gestionar-toda-la-electronica-del-automovil.


77

ANEXO Este anexo recoge el código principal de la aplicación eCo Application, que ha sido nombrado y detallado en la sección 4.1.2 Código (Back-end). Las librerías y el código generado de manera automática por el IDE al colocar sobre el Formulario (GUI o fron-end) elementos como botones, imágenes o texto, no se incluyen.

78

/*****************************************************************************************************/ /************************************* PESTAÑA INICIO ******************************************/ /****** A continuación las funciones implicadas en las funciones de la pestaña inicio ******/ /*****************************************************************************************************/ /*Esta función permite al usuario dirigirse a la ventana Ajustes al pulsar el botón Ajustes*/ private: System::Void button1_Click(System::Object^ sender, System::EventArgs^ e) { this->tabControl1->Controls->Remove(this->tabPage4); if (flag_usb_connected == false) { pictureBox_USB->Image = Image::FromFile("Images\\USBDisconnected.png"); } else { pictureBox_USB->Image = Image::FromFile("Images\\USBConnected.png"); pictureBox_ON->Image = Image::FromFile("Images\\Shutdown-red.png"); pictureBox11->Image = Image::FromFile("Images\\desconectar.png");

MessageBox::Show("Recuerde detener la conexión antes de modificar cualquier parámetro.",

"eCo App", MessageBoxButtons::OK, MessageBoxIcon::Asterisk); } this->tabControl1->Controls->Add(this->tabPage4); tabControl1->SelectedIndex = 3; } /*Esta función permite al usuario dirigirse a la pestaña Medidas al pulsar el botón Mediciones */ private: System::Void button2_Click(System::Object^ sender, System::EventArgs^ e) { tabControl1->SelectedIndex = 1; this->tabControl1->Controls->Remove(this->tabPage4); } /* Esta función permite al usuario dirigirse a la pestaña Datos al pulsar el botón Datos */ private: System::Void button3_Click(System::Object^ sender, System::EventArgs^ e) { tabControl1->SelectedIndex = 2; this->tabControl1->Controls->Remove(this->tabPage4); } /*****************************************************************************************************/ /************************************* PESTAÑA AJUSTES **************************************/ /**** A continuación las funciones implicadas en las funciones de la pestaña ajustes *****/ /*****************************************************************************************************/ /*Esta función determina el comportamiento al pulsar el botón Comprobar conexióny conectar*/ /*Dependiendo del estado previo de la conexión, o la detiene o la inicia, comprobando que */ /* se ha conectado el sistema correctamente */ private: System::Void pictureBox_ON_Click(System::Object^ sender, System::EventArgs^ e) { try { if (flag_usb_connected) { if (flag_suspend) t_datos->Resume();


79

if (t_datos->IsAlive) { t_datos->Suspend(); flag_suspend = true; } serialPort1->Close(); pictureBox_USB->Image = Image::FromFile("Images\\USBDisconnected.png"); pictureBox_ON->Image = Image::FromFile("Images\\Shutdown_2.png"); pictureBox11->Image = Image::FromFile("Images\\comprobaryconectar.png"); flag_usb_connected = false; } else { String^ puerto = textBox_puerto->Text; String^ v_trans_str = textBox_transmision->Text; serialPort1->PortName = puerto; /*convierte el numero introducido como cadena en int para asignarle el valor al serialPort1*/ std::string v_trans_std = msclr::interop::marshal_as< std::string >(v_trans_str); int value = atoi(v_trans_std.c_str()); serialPort1->BaudRate = value; /*Comprobamos la correcta conexion con el puerto serie*/ serialPort1->Open(); serialPort1->ReadTimeout = 1000; serialPort1->Write("ATZ\r"); datos += "\n" + "User>ATZ "; String^ cadena_r = serialPort1->ReadTo(">"); datos += "Reply> " + cadena_r; textBox_datos->Text = datos; fichero->WriteLine("\n" + "User>ATZ " + "Reply> " + cadena_r);

if (!t_datos->IsAlive) serialPort1->Close(); if (cadena_r->Length != 0) {

pictureBox_USB->Image = Image::FromFile("Images\\USBConnected.png");

flag_usb_connected = true;

if (MessageBox::Show("La conexiÛn se ha realizado con Éxito.", "eCo App", MessageBoxButtons::OK, MessageBoxIcon::Asterisk) == System::Windows::Forms::DialogResult::OK) {

this->tabControl1->Controls->Remove(this->tabPage4); tabControl1->SelectedIndex = 0; } } } }catch (Exception^) { MessageBox::Show("Error en la comunicación con su dispositivo. Revise el puerto conectado.", "eCo App", MessageBoxButtons::OK, MessageBoxIcon::Asterisk);

80

} } /*****************************************************************************************************/ /************************************* PESTAÑA MEDIDAS **************************************/ /**** A continuación las funciones implicadas en las funciones de la pestaña ajustes *****/ /*****************************************************************************************************/ /*Esta función inicia la lectura de datos del sistema cuando el usuario pulsa el botón Iniciar */ private: System::Void button_iniciar_Click(System::Object^ sender, System::EventArgs^ e) { try { if (this->tabControl1->SelectedIndex != 4) this->tabControl1->Controls->Remove(this->tabPage4); if (!(t_datos->IsAlive)) { serialPort1->Open(); t_datos->Start(); } else if (!flag_usb_connected) serialPort1->Open(); flag_usb_connected = true; if (flag_suspend) { t_datos->Resume(); flag_suspend = false; } button_detener->Visible = false; button_errores->Visible = false; } catch (IOException^) {

MessageBox::Show("Ocurrió un error. Pruebe a detener la conexiún y reinténtelo de nuevo.", "eCo App", MessageBoxButtons::OK, MessageBoxIcon::Asterisk);

} catch (InvalidOperationException^) { serialPort1->Close(); } } /*Esta función detiene la lectura de datos cuando el usuario pulsa el botón Detener */ private: System::Void button_detener_Click(System::Object^ sender, System::EventArgs^ e) { try { if (flag_suspend) t_datos->Resume(); if (t_datos->IsAlive) { t_datos->Suspend(); flag_suspend = true; } serialPort1->Close(); pictureBox_USB->Image = Image::FromFile("Images\\USBDisconnected.png"); pictureBox_ON->Image = Image::FromFile("Images\\Shutdown_2.png"); pictureBox11->Image = Image::FromFile("Images\\comprobaryconectar.png");


81

flag_usb_connected = false; label_v->Text = "0.0"; label_t->Text = "0.0"; label_r->Text = "0.0"; label_b->Text = "0.0"; datos = ""; // Reseteo de la cadena que contiene los datos mostrados en Datos textBox_datos->Text = datos; }catch(IOException^){

MessageBox::Show("Ocurrió un error. Pruebe a detener la conexión y reinténtelo de nuevo.", "eCo App", MessageBoxButtons::OK, MessageBoxIcon::Asterisk);

}catch (InvalidOperationException^) { serialPort1->Close(); } } /*Esta función suspende la lectura de datos cuando el usuario pulsa el botón Suspender */ private:System::Void button_suspender_Click(System::Object^ sender,System::EventArgs^ e) { if (t_datos->IsAlive) { try { if (flag_usb_connected) { t_datos->Suspend(); flag_suspend = true; } if (flag_mil) { button_errores->ForeColor = System::Drawing::Color::Firebrick; button_errores->Visible = true; } button_detener->Visible = true; } catch (...) {

MessageBox::Show("Ocurrió un error. Inténtelo de nuevo.", "eCo App", MessageBoxButtons::OK, MessageBoxIcon::Asterisk);

} } } /*Esta función permite borrar los mensajes de error yresetear el indicador MIL cuando el*/ /*usuario pulsa el botón Errores */ private: System::Void button_errores_Click(System::Object^ sender, System::EventArgs^ e) { try { serialPort1->Close(); serialPort1->Open(); serialPort1->Write("04\r"); // Modo 4 para limpiar los códigos de error datos += "\n" + "User>04 "; textBox_datos->Text = datos; fichero->WriteLine("\n" + "User>04 "); pictureBox_MIL->Image = Image::FromFile("Images\\Engine-gris.png");

82

flag_mil = false; button_errores->Visible = false; }catch(...){

MessageBox::Show("Ocurrió un error. Pruebe a detener la conexión y reinténtelo de nuevo.", "eCo App", MessageBoxButtons::OK, MessageBoxIcon::Asterisk);

} } /*********************************************************************************************************/ /*********************************************************************************************************/ /************************************* FUNCIONES PROPIAS ***************************************/ /*********************************************************************************************************/ /*********************************************************************************************************/ private: void Loop_lectura() { flag_usb_connected = true; bool bandera_while = true; while (bandera_while) { try { int posicion = 0; //0 si no ha encontrado coincidencia /*****************************/ /*Lectura de la velocidad*/ /*****************************/ /*El calculo de las RPM se obtiene con A siendo A el byte devuelto*/ serialPort1->Write("010D\r"); datos += "\n" + "User> 010D "; String^ read_v = serialPort1->ReadTo(">"); datos += "Reply> " + read_v; fichero->WriteLine("\n" + "User> 010D " + "Reply> " + read_v); //el contenido siempre empienza 6 elementos despues de esta cadena

posicion = (read_v->IndexOf("41 0D")) + 6; //cojo los caracteres que representan la velocidad indicada con un byte

read_v = read_v->Substring(posicion, 2); read_v = Hex_convert(read_v); label_v->Text = read_v + " km/h"; posicion = 0; /***************************/ /***Lectura de la RPM**/ /**************************/

//El calculo de las RPM se obtiene con ((A*256)+B)/4 siendo A y B los bytes //devueltos

serialPort1->Write("010C\r"); datos += "\n" + "User> 010C "; String^ read_rpm = serialPort1->ReadTo(">"); datos += "Reply> " + read_rpm; textBox_datos->Text = datos;


83

fichero->WriteLine("\n" + "User> 010C " + "Reply> " + read_rpm); String^ read_rpm_A; String^ read_rpm_B; //cadenas por separado para realizar el calculo //el contenido siempre empienza 6 elementos despues de esta cadena posicion = (read_rpm->IndexOf("41 0C")) + 6; read_rpm_A = Hex_convert(read_rpm->Substring(posicion, 2)); //cojo los caracteres que representan la velocidad indicada con un byte read_rpm_B = Hex_convert(read_rpm->Substring(posicion + 3, 2));

INT32 result_rpm_int = ((System::Convert::ToInt32(read_rpm_A) * 256) + (System::Convert::ToInt32(read_rpm_B))) / 4;

label_r->Text = System::Convert::ToString(result_rpm_int) + " rpm"; /************************************/ /***Lectura de la temperatura***/ /***********************************/ /*El calculo de la temperatura se obtiene con A-40 siendo A el byte devuelto*/ serialPort1->Write("0105\r"); datos += "\n" + "User> 0105 "; String^ read_t = serialPort1->ReadTo(">"); datos += "Reply> " + read_t; textBox_datos->Text = datos; fichero->WriteLine("\n" + "User> 0105 " + "Reply> " + read_t); //el contenido siempre empienza 6 elementos despues de esta cadena posicion = (read_t->IndexOf("41 05")) + 6; read_t = Hex_convert(read_t->Substring(posicion, 2)); INT32 result_v_int = (System::Convert::ToInt32(read_t) - 40); label_t->Text = System::Convert::ToString(result_v_int) + "ºC"; /******************************/ /***Lectura de la bateria***/ /*****************************/

//El calculo de la temperatura se obtiene con (A*100)/255 siendo A el byte //devuelto

serialPort1->Write("012F\r"); datos += "\n" + "User> 012F "; String^ read_b = serialPort1->ReadTo(">"); datos += "Reply> " + read_b; textBox_datos->Text = datos; fichero->WriteLine("\n" + "User> 012F " + "Reply> " + read_b);

//el contenido siempre empienza 6 elementos despues de esta cadena posicion = (read_b->IndexOf("41 2F")) + 6; read_b = Hex_convert(read_b->Substring(posicion, 2)); INT32 result_b_int = (((System::Convert::ToInt32(read_b) * 100)) / 255); label_b->Text = System::Convert::ToString(result_b_int) + "%";

84

/*************************************/ /*Comprobación de errores MIL */ /*************************************/ serialPort1->Write("03\r"); datos += "\n" + "User> 03 "; String^ read_mil = serialPort1->ReadTo(">"); datos += "Reply> " + read_mil; textBox_datos->Text = datos; fichero->WriteLine("\n" + "User> 03 " + "Reply> " + read_mil); //el contenido siempre empienza 6 elementos despues de esta cadena

posicion = (read_mil->IndexOf("03 43")) + 7; read_mil = read_mil->Substring(posicion, 8); // bytes recibidos cuando el MIL est· encendido String^ compara = "01 02 17"; if (compara == read_mil) {

pictureBox_MIL->Image = Image::FromFile("Images\\EngineFilled-rojo.png");

flag_mil = true; }; }catch (TimeoutException^) { label_b->Text = "Timeout"; label_r->Text = "Timeout"; label_t->Text = "Timeout"; label_v->Text = "Timeout"; } catch(ThreadAbortException^ e){} catch (...) { bandera_while = false; t_datos->Suspend(); flag_suspend = true; MessageBox::Show("PROBLEMA", "eCo App", MessageBoxButtons::OK, MessageBoxIcon::Asterisk); } } } //Hex_convert convierte una cadena que contiene un hexadecimal, en una cadena que //contiene un decimal public: String^ Hex_convert(String^ cadena) { System::Int32 caracter_i, total_dec, j, tam = 0; String^ cadena_final; //cadena a devolver tam = cadena->Length; for (int i = tam - 1; i >= 0; i--) { switch (cadena[i]) { case '0': caracter_i = 0; break; case '1': caracter_i = 1; break; case '2': caracter_i = 2; break; case '3': caracter_i = 3; break;


85

case '4': caracter_i = 4; break; case '5': caracter_i = 5; break; case '6': caracter_i = 6; break; case '7': caracter_i = 7; break; case '8': caracter_i = 8; break; case '9': caracter_i = 9; break; case 'A': caracter_i = 10; break; case 'B': caracter_i = 11; break; case 'C': caracter_i = 12; break; case 'D': caracter_i = 13; break; case 'E': caracter_i = 14; break; case 'F': caracter_i = 15; default:; } total_dec = total_dec + caracter_i * pow(16, j); j++; } cadena_final = System::Convert::ToString(total_dec); return cadena_final; } //Esta función indica que, antes de cerrar el formulario, se debe generar y cerrar el documento //de texto que contiene los mensajes intercambiados durante la lectura private: System::Void MyForm_FormClosing(System::Object^ sender, System::Windows::Forms::FormClosingEventArgs^ e) { try { fichero->Close(); if (flag_suspend) t_datos->Resume(); if (t_datos->IsAlive) { t_datos->Abort(); flag_suspend = true; } serialPort1->Close();

MessageBox::Show("Los datos recogidos se han guardado en el fichero \"eCo_Datos.txt\" ", "eCo App", MessageBoxButtons::OK, MessageBoxIcon::Asterisk);

Application::Exit(); } //Excepcion generada por el metodo Abort() para detener el hilo catch (ThreadAbortException^ e) {} catch (ThreadStateException^ e) {} } }; }

desarrollo de una aplicación para el ordenador de a...

Documents