PROYECTO FIN DE CARRERA

TITCLO: Adq'u'Ísfrión de datos rem.ota medfonte el sistema OBD-II y d'isposfüvo

móvil

AUTOR: David Arroyo Cazarla

TUTOR: David Martín Gómez

EL TRIBUNAL

VOCAL:

SECRETARIO:

Reali7:ado el acto de defensa y lectura del Proyecto Fin de Carrera el día de

de 20~ en Lega.nés, en la. Escuela. Politécnica. Superior de la
Universidad Carlos III de :\fadrid 1 a.cuerda otorgarle la CALIFICACIÓK de

PRESIDENTE SECRETARIO VOCAL

A todos los que rnc han apoyado y en
e.special a ti1 por hacerme mucho más
amena la espera ...
lVinter is wrning
 Resumen

La llegada al mercado de dispositivos de bajo coste capaces de leer

informaci6n del vehfculo a traves del sistema de diagn6stico a bordo (On-board
diagnostics) y reenviarlo mediante Bluetooth a otro dispositivo ofrece la
posibilidad de llevar la adquisici6n de datos del vehfculo al gran publico. De estos
sistemas podemos obtener diversa informaci6n, desde datos provenientes de
sensores de distintos m6dulos del vehfculo hasta c6digos con la indicaci6n de una
averfa detectada. Todo ello unido a la capacidad de procesamiento de los
smartphones y a su conectividad permite hacer llegar a la red la gran cantidad de
datos recogida del vehfculo. El uso del Smartphone, que generalmente cuenta con
una amplia gama de sensores, permite incorporar informaci6n adicional
interesante asf como hacer uso de sus sistemas de posicionamiento tanto con el uso
de satelites como de redes inalambricas. Gracias a esta combinaci6n, podemos
situar en el espacio los datos recogidos.

En la multitud de servicios que se pueden desplegar gracias a la recepci6n

remota de esta informaci6n en tiempo real esta la clave de estos sistemas. Este
proyecto se limita a la creaci6n de un servidor y una aplicaci6n para Android
gracias a la cual se pueden extraer, procesar y enviar todos los datos del vehfculo.
Ademas, debido a que el retardo es un parametro muy importante en el sistema
desarrollado, se ha realizado un estudio junto con diferentes pruebas para evaluar
y optimizar el rendimiento de los dispositivos conectados al vehfculo.
|
|
|
Introducción
|



 |





Estado del arte
|
 |


|


 |


|


 |


|


 |


|


 |


|
 |


|
C~. J-:STA DO D ¡.; L A ll'I' E | 20

dbeiiado para delcdar averías en todos los componentes que pueden afoétar a las
emísionei; .Y ~ní ~u único requi:;ilo, lo:; difore11Lei; fobrica11Les µueden induir el
diagn6,;tico de otroi:; componente,; del vehfrnlo y ntili:.rnr lo,; mem;aje,; del protocolo
de OilD-II parn informar del fallo. Adirio11alme11l,e, pueden implermmLa.r nuevo,;
i<i"tema.i< de cliag11ói<tÍ<'O o de otro tipo lin,c:íendo nso del <'onector de OBD-11 e
inclm:o, pm!deu llevar otro pm!rto diferente y mnpl(•ar 11wi. n•d dif('l'('Tlte.

K,te si1;.tema se <1:vuda de la red incluida en el vehículo (ECLl, bu1;.es,

BCt1$0l'CB. aeltwdorc$ ... ) J>Mf.t recoger la ínf'ornmc:-.ión ncc::csari,,.. i\,;:L el ,;:ís\.cnrn e,;:
capa.\', de rea I i,:,11· u mi. 111 on i I orí ;.:adón c:,on li n ua de ck: rtos 111 ód ulos c:o 111 o el siSl cnrn
de eneemlitlo o ¡;i~Lerm1:; <lcl eomuu~liblc 111Íe11Lrn,; que otro,; requiere11 de
Hitmtcio11ei:; eHpecía.le,; o eventoH periódiC'os para. poder monítod:,;arlos como el
c,1talí:.::ador, el :;em;or de oxígeno o el ,;h;te11m de recircularí6n <le gai;es de escape.
Un di"po:iit.ivo externo <'onecta.do n,l pnerto de OB0-11, c:omo noclo de fa. red,
podr:í. solicitar infonnad(m Hnlmi (!I ('Hta.do de ('Ht.os test a.sí corno sobre\ DTCs
J'(!gistrndo;: u otra infonnacióu a. trnvé:r-: el(! un protocolo dci cmvío/n\Hpmisrn.

En la siguíeme figura puede ver un ejemplo de red del sistema ODD-IL

ge

donde ex bten ECUs de di foren le,;: rc<k$ q uc ,;:e c-orr, un i urn eon el in ter f'a:r. de
dia¡¡;no,;ii; parn el e11vío y reecpció11 <le <laLOs. Ademú:;, dc,;<le la i11Lcrfo.;: i;c µodrú
co11edar con la ECU del cuadro de i11sl.rume11l.os parn enviar dato,; l,ales como la
velocüla.c.l o el a viso de nn fallo <le diagnóstico y a la ve:,: también i:;e poc.lrá
cormmicar <'On nn elemt>nto t'-~tt>rno a t.riwéi< del coned.or.

Unidad d• u-~ir.l an .&

~\Hidro d. in.s-tr~ffllO
nu
ltltetf.z do cn.,...11_..
p.-. 1"1• d9 d•tos
A»

Unid.td: M cont,ul
d• """1• w.
,011dvc;to,
JJII

Figura 2-G lkd ccmt.rnl de diagnó,-ti~o de Audi TT llnac1:'lt.1~r

|


 |


|


 |


|


|
|


|
|
 |


|


 |


|


|
|


 |


|


 |


|
 |


|
 |


|


 |

✓ ✓ ✓ ✓

✓ ✓ ✗ ✓

✓ ✓ ✓ ✓
✓ ✓ ✓ ✓
✓ ✓ ✓ ✓
✓ ✓ ✓ ✗
✓ ✓ ✗ ✓

✓ ✓ ✗ ✗

✓ ✓✓ ✓ ✓✓

✓ ✓✓✓ ✓✓ ✓✓
✓ ✓ ✓ ✓

✓ ✓✓ ✓✓ ✓

✓ ✓✓ ✓✓ ✓✓
✓ ✓ ✗ ✗
✓ ✓ ✗ ✓
|

✓ ✓✓ ✓✓ ✓✓

✓ ✓✓ ✓✓ ✓

✗ ✓ ✓ ✓

✗ ✓ ✗ ✓

✓ ✓✓ ✓✓ ✓✓

✓ ✓ ✓ ✓
Análisis, diseño e implementación
|


 |


|


 |


|
|
53 | C:3. ANALISIS, DISEÑO E UvIPLE1\1ENTACIÓ>T

Estos dos modos condicionarán el diseúo de la aplicación, que ha sido

dividida en diferentes módulos o subsistemas donde cada uno será encargado de
diferentes tareas: conrnnicaci(m con el vehículo, posicionamiento, sensores,
generación de estadísticasi gestión de ficheros, monitorización gráfica en tiempo
real, cornnnicación con el servidor y configuración.

En la figura 3-3 se puede ver el proceso de adquisición en el modo normal

de operación. En primer lugar el usuario debe inLeracLuar con el módulo de
configuración para realizar los ajustes oport1mos, tales corno seleccionar tcl
adaptador utiliL;ado, el intervalo de Loma ele elatos, el modo ele operación o indicar
los datos a adquirir. DespnP.s de los 1-tjnstes, cnando se inicie la iidquisici(m de
dv.tos se arrnncará un proceso que leerá las preferencias y hará los ajustes
oportunos en los diferentes módulos. Posterior a estos ajustes iniciales entrará en
un bucle hasta que el usuario desee suspender la sesión de adquisición. En el bucle
se lleva a cabo la lectura. de los diferentes datos adquiridos de forma a.síncrona que
ya han sido procesados en los diferentes módulos y la difusión ele los mismos a los
medios que el usuario haya configurado. Se añadirá. un temporizador que act.iva.rá
el inicio de este bucle cada cierto tiempo. Las formas de adquirir y enviar datos
descie el proceso principal son nmy diversas y se detallarán cuando se explique el
funcionamiento de cada módulo que compone la aplicación.

Servidor

Fkhem I
Figura :{-:{ Interacción del proeeso de adquisición de datrn.; de la aplicación en su
modo normal de operación
 |


|


 |


57 | C:3. A)l'ÁLISIS, DISE~O E L\:IPLK\IENTACIÚN

Cone:r:ión Bl'Uetooth

Una ve:,; que el usuano n11c1a la conexión se proceden a leer todas las
opciones que haya configurado y se hace un intento para. crear una conexión
Bluetooth. Se creará un socket RFCOMl\I (Radio Frequency Communications)
ntili~ando el CCID (Universally Unique ldentifier) del perfil SPP (Serial Port
Profile), que se corresponde con: 00001101-0000-1000--8000-00805F9B:34FB.
Basándonos en las pruebas reali:,;adas en ocas10nes no se reali:,;a la conexión
correctamente y se puede necesitar más de un intento. Por ello, en caso de fallo se
reali~arían hasta ;3 intentos de conexión, dando por finali~a<lo el proceso si no se
consigne. Se reali~ará 1111 aviso para que se indique que se ha establecido la
conexión en la interfaz de usuario de la aplicación. A su ve:,;, se modifica la
notificación que fue creada para avisar de que hay un servicio en segundo plano,
que será el medio por el que el usuario conocerá si está o no conectado.

Configuración del ELJ\![827

En este punto se configurará el microcontrolador usando el protocolo de

comandos del EL:11327 explicado en el capítulo anterior. Aquí, a diferencia. de la
fase de pruebas, lo que interesa es enviar la menor información posible para
reducir el tiempo entre peticiones de manera que se hará en primer lugar 1111 reset
de software por si existiera una configuración previa no deseada y a continuación
se eliminarán: el eco de las peticiones, la inserción del salto de línea al final de
cada mensaje, los espacios y las cabeceras definidas en OBD-II. Por último, se
seleccionará la opción de escanear todos los protocolos y utifümr el primero
disponible (modo ACTO) empleando el orden más eficiente. Se ajusta además el
timeout de OBD-11 inicialmente a lOOms ya que el establecido por defecto es
excesivamente conservador.

Cornprobadón de modo rápido so portado

Como se explicó en la sección del ELl\I:327 existe un modo que permite

evitar el tiempo de espera propio del protocolo OBD-11 si conoces exactamente el
número de ECUs que contestaran ante una petición. Así, tan pronto corno se
reciban los bytes necesarios del vehículo se podrá iniciar una nueva petición. Para
comprobar si dicho modo está soportado se aprovechará para reali:,;ar una segunda
petición del primer parámetro enviado pero con este modo a ctivado. En caso de
que la respuesta coincida se mantendrá. el modo sin esperas en las siguientes
peticiones hacia el vehículo; en caso contrario, se volverá al funcionamiento
normal.
C:1. AKÁLISIS, DISEKO E L\:IPLK\IENTACIÚN | 58

Comprobac'ión de parámetros d'isponiblcs 'IJ panímetros cleq1:dos por el 'US'iutrfo

En este punto es necesario comprobar si los parámetros que el usuario ha

seleccionado para su adquisición son proporcionados por el sistema OBD-11 del
vehículo. En caso de no ser soportados se descartarán. Para conseguirlo, existen
diferentes PIDs que indican si el parámetro es soportado facilitando la labor al
evitar tener que hacer una petición a cada parámetro. Así, con el PID $00 del
servicio $01 podemos conocer cuáles de los 32 primeros PIDs son soportados. El
proceso completo para conocer los parámetros disponibles se puede ver en el
apéndice C.

A dmds'ición 'i/ prncesado de datos estáticos

Algunos parámetros que podemos obtener del vehículo serán fijos o

generalmente no se producirán cambios durante una sesión. En estos casos solo se
reali~ará una única petición al vehículo cada ve;,: que se inicie la adquisición de
datos. La lista de comandos que se han implementado y los detalles para realizar
su decodificación una vez efectuado el procesado previo están explicados en el
apéndice A. l.

Adquisú;ión 11 procesado de datos dfaámicos:

Si existe la posibilidad de adquirir alguno de los datos dinámicos

seleccionados por el usuario su adquisición se realizará de manera continua
cumpliendo en la medida de lo posible con el tiempo de refresco que el usuario
haya indicado para la adquisición de los datos. Dependiendo de las prestaciones
del conector y del vehículo y del número de parámetros deseados es posible que
no se puedan alcan~ar los objetivos para un tiempo demasiado pequeño. Después
de hacer el procesado previo, se realiza la decodificación de los bytes que aportan
datos del vehículo. En el apéndice A.2 se muestran los parámetros implementados,
donde se incluye el PID, el número de bytes de datos 1 su unidad y como se debe
decodificar el resultado.

Excepcionalmente, si se trabaja con el modo de reenv10 inmediato de

información al servidor se podrá desde este hilo de ejecución añadir una tarea al
hilo de comunicaciones con el servidor para que se envíen los datos tan pronto
corno se decodifique la información.

Esta toma de datos se reali;::ará mientras el usuario no indique

explícitamente la interrupción de la adquisición o se detecten problemas en la
comunicación Bluctooth. Cuando ocurra uno de los casos, se cerrará la conexión
Bluetooth y finalizará el proceso .
|
C3. ANÁLISIS, DISJ--:)10 E JJ\.IPLE\11--:\"TACIÓN | 60

Usuario inicia la Usuario detiene la

Sistema envía un nuevo
adquisición de datos adquisición de datos
dato de un sensor a
componentes registrados

Avisar al sistema para

Lectura del dato del
dejar de recibir datos
sensor recibido

Si

Registrarse para recibir

datos de los sensores Filtrado
Fin del proceso

Fin del proceso

Figura :~-6 Diagrama de flujo del módulo de sensores

I'rerreqn'is itos

Para poder llevar a cabo este proceso será necesario que d us1rn.rio in<liqnc
que desea adquirir da.tos de los sensores en La configuración :,' que el dispositivo los
lleve i11tegra<los.

Us1wrio inicia. la a.dm1ú1irión de da.tos

En este pt mt.o se comprobaní. sí el 11s1 mrío ha selecdona.clo el uso de

scnsorcs y sc tratará de obtcncr los scnsorcs de acclern.ción lineal y orientación por
defecto del móvil. En caso de disponer del sensor hay que hacer un registro para.
que el sü::tema envíe Los datos cuando realice las sucesivas lecturas. Ilay que
indicarle el tipo de rec.1uisito de retardo de la aplicación o bien el tiempo desea.do
entre: ler:t.uras. En este caso) Re ha indicado el tiempo fijado por el usuario para la
tasa de refresco de datos. Esto no significa que se vaya a recibir 1111 elato de cada
sensor regist rado cada cierto t iempo ya que dependerá de rnnchrn, factores.
Algunos, con10 la carga excesiva del sistema, pueden retrasarlo mientras que un
elemento haciendo uso del mismo sensor con una tasa de refresco mayor puede
disminuir el tiempo entre 11ctualiz11dones.
|


 |


 63 | C::L A~ÁLISIS. DISEKO E IMPLE~1E~TACIÓ~

Sistema envía una nueva Usuario detiene la

localización (GPS o adquisición de datos
servicio de Google)

No
Si

Eliminar la subscripción
Actualización de la
de datos de localización
localización
No

Indicar que el sistema

GPS está funcionando

Fin del proceso

No

Si
Si

Almacenar tiempo de
adquisición Indicar que el sistema Indicar que el sistema
GPS está funcionando GPS no está funcionando

Fin del proceso

Figura :1- 7 Diagrama de flujo del módulo de posicionamiento

U.cwario inicia la adq·uisición de datos

Cuando el usuario inicia la adquisición de datos se comprobará. si ha

marcado el uso ele localización a través de redes inalámbricas. En tal caso, será
necesario conectarne al servicio de Google indicando el intervalo de actualización
deseado (se indicará el fijado en las opciones por el usuario aunque si es menor
que el límite no tendrá efecto), la precisión (se ha escogido la máxima posible sin
tener en cuenta el consumo) y la tasa máxim a a la que la aplicación es capaz de
leer datos (fijado el tiempo 1nínirno entre datos a. 100 1ns, aunque no 8e dará el
caso). Por otro lado, si el usuario indica que quiere utilizar GPS y se encuentra
activado en el dispositivo se procede al registro para la recepción de datos GPS
indicando el tiempo deseado entre un dato y otro que de nuevo se corresponderá
con d intervalo fijado en opciones y la distancia mínima que tiene que haber entre
|
|


 |


|
|
69 | C:1. A)l'ÁLISIS, DISE~O E L\:IPLK\IENTACIÚN

Fl'Uio us'1wrio/sisterna irl!icfo la can¡a de la "pantalla·,

Este es un caso particular donde habrá una actividad con vanas

''pa.ntallas" seleccionables mediante pestañas o desplaza.miento lateral. De modo
que la. actividad contendrá. varios fra.gmentos que podrá lanzar /liberar según los
requerimientos del sistema, y se hace para evitar la carga entre pantallas. Por
tanto, se podrá entrar aquí en varias circunstancias y no solo cuando el usuario lo
indique. Cuando se produzca este evento, se inicializarán los componentes gráficos
de la pantalla correspondiente y se realizará. la. subscripción a los datos deseados.
Por ejemplo, en una de las pantallas se ha implementado 1111 dial. Cuando se
quiera instanciar :,:,e indicará el valor mínimo, máximo, las nnidade:,:, ;,' el número
de marcas en las que se incluirá un indicador numérico (podrá ser 2, 3, 5 o 6 por
el diseño realizado). A su vez, será necesario iniciar el puntero que irá asociado al
dial anterior. Para conocer la posición inicial del puntero, se calculan de los grados
de rotación requeridos teniendo en cuenta su estado anterior. En este caso se
trasladará a.utomá.ticamente, mientras que en sucesivas a.ctualizaciones se
realizarán a.nimaciones con la rotación.

Recepción en fraqrnento de JU de ·un nuevo mensa/e de datos

Una vez recibido el mensaje se comprobará, en ca:,:,o de haberse realizado

un registro de varios tipos de datos, a cual pertenece. Posterionnente, dentro de
cada grupo, se hará una búsqueda. de los pa.rámetros requeridos para. actualizar la
interfaz gráfica, descartando el resto. Las actualizaciones variarán en función del
fragmento :l del tipo de datos, puede ir desde un cambio de texto hasta iniciar una
animación o añadir un marcador en el mapa.

Flufo usuario (sistema libera la "pantalla J:

Ya sea porque el sistema necesite recursos o el usuario abandone la

actividad de monitorización. Se elimina.rán toda.s las subscripciones que
previamente se hubieran realizado en la aplicación.

En el ca.so de los mapas existe una excepc10n ya que además de

monitorizar la ruta se podrá consultar un viaje previo. Por tanto, en caso de
utilizar los mapas para ese fin, no se realizará una subscripción a los datos en
tiempo real y simplemente se cargaran los puntos por donde se ha pasado en un
viaje anterior ( coordenada.s, tiempo y velocida.d) que previamente se han
almacenado. Hay que comentar además, que en el caso de lo:,:, mapas Rolo se
almacenará una localización que será preferentemente GPS si está disponible en
detrimento de redes inalámbricas. A su vez, la velocidad prioritaria será la del
sistema OBD-II sobre la. d e GPS.
|
71 | C::L A~ÁLISIS. DISEKO E IMPLE~1E~TACIÓ~

Usuario detiene la
adquisición de datos

Si
Si

Añadir tarea a cola del

Descartar la tarea hilo de comunicación:
(Excepto lista IDs) Cierre de conexión

Procesar la petición
correspondiente
Esperar a la finalización
de tareas pendientes

Fin del proceso

Figura 3-10 Diagrama de flujo del módulo de comunicación con el servidor

Prcrrcqu.isitos

El usuario deberá habilitar el envío de datos al servidor e iderit.ificar al

servidor y puerto correspondiente. Asimismo, habrá que indicar el t iempo de
refresco de los datrn,. Debe haber al menos una conexión activa, bien a través de
redes móviles o mediante "\Vi-Fi.

Fl'Ujo al iniciar la adquisición de datos

Si el usuario desea realizar un envío de los datos al servidor se comprobará

si es posible, es decir, si existe conectividad a través de \Vi-.Fi o redes móviles. En
ese caso se tratará de crear el socket con el servidor y puerto fijado en las
opciones. Para ello, se indicará el deseo de realizar dicha tarea en el hilo
correspondiente. Será ordena.do una. única ve7, y será el primer rnem,aje recibido en
 |


|
 C:i. A~ÁLISIS, DISESO E nvIPLElVIENTACIÓN | 74

Aviso del temporizador Usuano detiene la

cada X milisegundos. adq u1sic1ón de datos

Lectura de va lores
Cerrar fichero
proporcionados por otros
sistemas

Fin del proceso

Si Si
No
Usuario selecciona Usuario inicia borrado
medio de envío de fichero

Crear y/o abrir fichero A lmacenar los datos en

el fichero

Fin del proceso

Figura :3-11 Diagrama <le flujo del módulo de ficheros

Flujo cuando el us1wrio fnicia la adquú;frfón de datos

Si está activado el registro de datos se intent a abrir el fichero con el

nombre especificado. En caso de que no exista se creará uno nuevo, mientras que
si ya existe se comenzarán a añadir datos al final del mismo.

Flufo cada vez mie el temporizador actfoa el proceso proqramado

Se almacenará en el fichero el último valor de todos los parámetros

rlirn'í.micos solicitados siempre q1Le el 11sw1.rio lo indique y se haya podido a.brir el
fichero. La primera vez que se ejecute está sección del código, además, se escribirá.
en primer lugar el conjunto de los parámetros.

Flujo cuando el ·us·uario detiene la adquisición de datos.

Se cierra el fichero abierto anteriormente. Adicionalmente, si el usua rio ha

seleccionado el envío del fichero al finalizar la sesión de adquisición, se presenta al
usuario la pantalla. pa.ra. la. selección del destino.
75 | C:1. A)l'ÁLISIS, DISE~O E L\:IPLK\IENTACIÚN

Afodo (/'lle pcrrrdte borrar el fichero

Desde las opciones de la actividad principal de la aplicación el usuano

podrá indicar el borrado de sesiones anteriores de un vehículo y en caso de existir,
será eliminado.

l\1odo qne perndte compartir el fichero

Otra de las opciones disponibles en el menú de la aplicación será compartir

el fichero que este indicado actualmente corno sesión activa (identificador de
vehículo). El usuario podrá elegir una de la.s opciones que le son presentadas; por
ejemplo: Bluetooth. email, sistema de almacena.miento en la nube, etc ...
 Pruebas y resultados


|








 |

Cliente: ATZ
ELM327: ELM327 v1.5
>
Cliente: ATSP0
ELM327: OK
>
Cliente: 0100
ELM327: Searching…41 00 98 3B 80 13
>
79 | C4. PRUEBAS Y RESULTADOS

La versión de soft-ware indicada en los dos adaptadores es la vl.5 pese a no

corresponderse con la realidad. Se comprobó que en ambos se soportaban los
comandos más básicos: selección de protocolo, activ ación de cabeceras, echo o
espacios... que ya eran soportados en la primera versión libre del EL:\11:327. Sin
embargo, algunas actualizaciones posteriores como el uso de filtros para restringir
los mensajes en función de su cabecera no están incluidas. Es importante advertir
que existe una diferencia significativa entre las características soportadas por los
dos adaptadores ya que aunque básicamente soportan los mismos parámetros, uno
de ellos soporta una de las características incluidas en la versión 1.3 del EUvI :327
que afectará al tiempo de respuesta. En pruebas posteriores. esto será tratado
junto a. otros aspectos relacionados con la optimización de la comunicación.

Asimismo, al margen de los comandos dirigidos al adaptador, se recibieron

los primeros datos del vehículo. El siguiente paso fue la programación de varios
scripts con algunas pruebas que simplemente realiza la petición de varios
comandos espaciados un intervalo prudente para permitir la ejecución completa
del proceso y un posterior análisis de los datos que serán volcados en un fichero.

Una de la.s pruebas fue la comprobación de los buses sobre los que se
produce el intercambio de d atos entre el a da ptador y los vehículos de prueba. A
su v ez, se obtuvieron las cabeceras insertadas por el vehículo en los diferentes
mensajes, que permite conocer las ECUs que responden a cierto tipo de peticiones.

Vehículo Bus Cabeceras # ECUs

83 Fl 10
Toyota A vensis ISO 142:30-4 (10.4kpbs) 84 Fl 10 1
86 Fl 10
7E8
:'-Jissan Note ISO 15765-4 (CAK ID llbits, 500kbps) 2
7E9
Tabla 4-2 Diferencias del sistema OBD-11 de ambos vehículos

Aunque en el protocolo se especifica que las peticiones se deben hacer a un

módulo funcional, conocer estas cabeceras permite realizar peticiones a una ECU
concreta, ya que aunque a un dato respondan dos ECCs diferentes puede que solo
se quiera conocer la respuesta de una específica.. También puede ser útil para
trabajar con pa rámetros definidos por el fabricante para su uso particula r que no
estén incluidos en el estándar, posibilitando realizar peticiones a la dirección física.

El :'-Jissan Kote emplea CAN bus a 500 kbps que permite minimizar el
reta rdo en las respuestas, que será más a cusado en el ISO 142:30-4 de Toyota. En
el caso d el Kissan , podem os ver en la cab ecera los identificadores que en el
|
|


 |


|


C4. PRUEBAS Y RESULTADOS | 84

Timeout Retardo Retardo Retardo Retardo

...
máximo(ms) 1ª ronda (ms) 2ª ronda (ms) 12ª ronda( ms) medio(ms)
200 329.7 269 ... 218 238.3
100 273 262.8 ... 216.6 231.8
72 260 238.5 ... 215.2 228.5
48 222.8 212.3 ... 225.7 217.9

Tabla 4-4 Comparación de rendimiento empleando diferentes timeouts

Se puede ver como mejora el tiempo medio al disminuir el timeout

especialmente por las primeras medidas. pero una vez que se ha estabilizado el
tiempo requerido para. obtener un parámetro dependerá de la.s condiciones del
vehículo y la aleatoriedad. Además, se consigue una rápida convergencia con
timeouts bajos y apenas existe diferencia incluso en las primeras rondas. Por
último, hay que comentar que no se ha perdido ningún parámetro con el tirneout
de 48 ms ya que el timeout adaptativo es conservador pero podría darse el caso de
no recibir algún dato que realmente se estuviera enviando. De hecho, trabajando
con timeouts inferiores a 2.5 ms en este bus, no se ha recibido ningún dato. Est o es
lógico ya que según las especificaciones del protocolo hasta que no pasen 25 ms no
se puede enviar la respuesta .

Sin embargo, a partir de la versión 1.:-3 del EL:VI ;-327 es posible indicar el
número esperado de respuestas de modo que se pueda nnnar una nueva
transmisión tan pronto corno sea posible. evitando este tiempo de espera
innecesario. Además , en este modo puedes utilizar un timeout amplio no
adaptativo que no influirá en el rendimiento garanti:.rnndo a la vez; la recepción del
dato. Aunque los dos adaptadores dicen soportar la versión 1.5 solo uno de ellos
soporta esta funcionalidad, constituyendo la principal diferencia entre a mbos, ya
que los resulta.dos del resto d e pruebas h an sido similares en ambos adaptadores.
De modo que a partir de ahora. se harán distinciones entre adaptador trabajando
con y sin esperas, independientemente del dispositivo utilü:ado.

1fodo Retardo medio (72 peticiones)

Sin esperas (timeout 200rns) 196.1 ms
Timeout 48ms 217.9 ms

Tabla 4-5 Comparativa entre el uso de timeout de 48 ms

y un adaptador sin esperas
|

400
timeout 200 ms
timeout 48 ms
sin espera
350

300
tiempo (ms)

250

200

150
0 10 20 30 40 50 60 70 80
número de petición
|
87 | C4. PRCEBAS Y RESULTADOS

móviles en los que se ha probado, siendo recomendable rea.lúar un filtrado y una

calibración que corrija el offset para obtener datos más precisos, especialmente en
el caso de orientación. Pero, sin embargo, si es útil para el propósito busca.do que
es la detección de eventos producidos. Se detectan aceleraciones en el sentido de la
marcha, que complementa a la velocidad del vehículo y ayuda a distinguir si el
vehículo va marcha atrás ya que OBDII solo da el valor absoluto. Con el resto de
ejes se detectan desplazamient,os laterales y baches con la única pega de que hay
que conocer la posición del dispositivo para identificar los ejes de coordenadas.
Por su parte, el sensor de orientación tiene un desfase en acimut que lo ha.ce poco
útil como brújula pero la linealidad detectada en los giros sobre todos los ejes
permite conocer los earnbios de sentido y dirección de la marcha midiendo la
dife.rencia entre ángulos. El resto de ángulos de los que disponemos nos permite
conocer la inclinación de los dos ejes de la carretera. (para detectar pendientes y
desniveles) y además, no presentan problemas de desfase en los móviles ele prueba.

Figura 4-4 Sistema de referencia para los sensores

Respecto a la.s prnehaR de loca.li,,aeión, se han rea.li,,ado tanto con el uso de

reclei:i inalámbricas como con GPS.

En el caso del ::,ervicio de redes ina.lá.mbricas, se comprobó la. limitación ele

Google en cuanto al tiempo de refre::;co de la localización en torno a 5 segundos
para favorecer el ahorro de batería debido a su falta de preciRión. Se obLienen
valores de precisión muy altos en un entorno urbano sin rnovüniento, pero la
precisión se ve considerablemente reducida en movimiento y en especial en
carreteras rurales. En cambio, cou GPS, la precisión para el u::;o requerido es en
general bastante buena; su refresco dependerá del sensor que lleve integrado el
dispoRit.ivo estando la frecuencia de act.ualización en el caso de pnicbaR en !.orno a
1 valor por segundo, que es la tasa común en la mayoría de dispositivos. El rumbo
obtenido a través de GPS es bast.ant.e preciRo, además tiene en cuenLa el vecLor de
movimiento del vehículo, de modo que permite conocer el sentido y dirección del
vehículo independientemente ele la posición del dispositivo.
C4. Pltu,;KAS Y Rl<;SLLT!\DOS | 88

1,a ¡;iguiente figunt, obtenida del módulo de rnonitorí;1,ación en tiempo real,

permil.e aprw:ia.r como las coordem1.das almacenadas son s11lkion1,cmonte precüms.
Se dü;tingueu las marca8 a:i:iadida8 periódicamente con información gráfica de la
vdocidad (en d ejemplo fueron t.oma.das ca.da segundo) que c1wnl.a.n con tm 1·adio
de 5 rnetro8. Además, es po8ible seleccionar cada uno de los punto8 para conocer
hi. hora c11 la que 1:'C generó y la vclocida.d concrct,a en Ci:'C ini:;tantc.

(9 C) ~ .. - _ 15 :0 l

29-04-2014/16:02:51 .000
79 km/h
e le Real
27

Autopista de Circunvalación

Figura 4-::> ViFmalizadón de rn1.a rna.lizada

Por último, se han comparado los valores de velocidad obtenidos mediante

OBDII y GPS. La diforcnda (:ni.re ambos es peqtieña. y existen desajttstes
principalmente por la falta de sincronía entre ambos y sobre todo en las
a.celcracioncs debido a su bajo muei:;trco. 1\sí, 1:'C lw. ca.lculado la. rncdia y la 111cdia
cuadrática de la diferencia entre ambas. Ilay que tener en cuenta además de la
imprccii:;i(rn de GPS la. baja rc8oluci(rn de la velocidad del vchku lo (que ei:; de 1
km/h) y afocl.a 1,amhitn en d cá.kulo.

Vfuei:;treo de Diferencia inedia :Vfcdia c1.mdrát,ica de Diforc11cia a.l)8olma.

vdoddad OBDII (kmíh) la diforencia {km/h) máxima. {km/h)
100 ms -fUG ;1.18 16.7
1s 0.1284 l.fü) 9.56

Tabla 4-7 Dif'crc11cias (!JJl.rc la velocidad GPS y OBD-JT

|
 |


|
 |


|

✓ ✓

✓ ✓

✓ ✓
✓ ✓
✓ ✓
✓ ✓
✓ ✓
✓
✓ ✓
✓
✓ ✓
✓
✓ ✓
✓ ✓
✓ ✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓

✓
 |

Establec. conexión Bluetooth

Reset de software

Configuración ELM327

Busqueda e inicio de protocolo*

Peticiones a datos estáticos *

0 100 200 300 400 500 600 700

Título del eje
|

≈ ≈

≈ ≈
|
Líneas futuras
 |


|


 |


|
|
Conclusiones
C6. COKCLCSIOKES | 104

de los problemas que se ha encontrado durante el desarrollo del proyecto ha sido

el eleva.do coste para acceder a los diferentes estándares actuales donde se
incluyen documentos qne definen las especificaciones que debe cumplir el
dispositivo externo en OI3D-II o el conjunto de servicios y PIDs estandarü:ados.
A su vez, el acceso a datos propietarios definidos por los fabricantes es totalmente
inasumible con el presupuesto del proyecto. De manera que el uso de OBD-II para
acceder a información del vehículo en el futuro pasa por una regulación que
estandarice y haga obligatoria la inclusión de determinados parámetros comunes
para todos los vehículos que puedan ser útiles en diversas aplicaciones futuras.

Respecto al adaptador utiliza.do para este fin. se puede concluir que las
prestaciones en la toma de datos a través de uno de bajo coste de los muchos que
hay en el mercado son suficientemente satisfactorias para la mayoría de
aplicaciones debido a. que muchas no imponen requisitos exigentes en el refresco de
los datos. El principal obstáculo de estos adaptadores de bajo coste es su baja
capacidad en el enlace Dluetooth+RS-2:-32. Asimismo, la capacidad de enviar
nuevas peticiones si es conocido el número de ECCs del vehículo que contestarán
a una petición aporta una mejora notable y en caso de no soportar está función se
empeora. el tiempo de respuesta., reduciéndose el número de datos por unidad de
tiempo que se pueden a dquirir. Sin embargo, la limitación de pará metros
soportados a travós de OBD-11 que se ha encontrado en los vehículos de prueba
hace que esto no sea tan crítico. Además, la rapidez con la que varían estos
parámetros es muy diversa. Podemos encontrar algunos, como el indicador d e
fallo, que no ocurran a lo largo de la vida del vehículo y por tanto habrá que
hacer espaciar bastante en el tiempo su consulta. En otros casos, se pueden
establecer difórcntes frecuencias para los parámetros en función de su importancia:
por ejemplo, priorizando la. velocidad, donde en algunas aplicaciones pueden ser
necesarias varias tomas por segundo en detrimento de otros parámetros que varían
más lentamente, como la temperatura del refrigerante. Ahora bien, si el número
de parámetros que entran en juego aumenta, ofreciendo una inmensa cantidad de
datos como el giro del volante , parámetros de sistemas ajenos al tren de potencia
como apertura. de puertas, ordenes dentro del sistema de entretenimiento para
conocer su uso, información del ABS, cte ... sería recomendable trabajar con un
conector que ofrezca mayor rendimiento. En el mercado existen dispositivos que
pueden procesar incluso má.s de 100 PIDs/s en algunos vehículos , pero a. cambio el
coste para el cliente es sustancialmente m ayor.

El bus del vehículo empleado tiene también una gran influencia sobre el
rendimiento del sistema y no todos los buses de OBD-11, algunos de ellos muy
antiguos, están preparados p ara leer muchos datos del vehículo en tiempo real.
:tviien tras que con ISO 1576,5-4 se h an alcanzado los 16 parámetros por segundo en
105 | C6. COKCLCSIOKES

ISO 14230-4 no se ha alcan:,;ado m la tercera parte. Así, el uso de este bus ha

supuesto el cuello de botella en uno de los vehículos de prueba., siendo
recomendable incorporar en futuros estándares el uso obligatorio de 1111 protocolo
con mejores prestaciones corno puede ser CAK (ISO 1.576,5-4), al igual que se ha
hecho para OBD-11 en Estados Unidos desde 2008.

Por otra. parte, la. existencia de pasarelas en los vehículos de prueba pa.ra
limitar la información accesible desde el conector de diagnóstico que consideren
comprometida para la seguridad o simplemente no lleven por ra:,;ones de diseño ha
impedido ver un ejemplo práctico de los mensajes intercambiados en el bus. Esto
podría ha.ber permitido la. adquisición de parámetros en modo pasivo, es decir, sin
hacer una solicitud previa y la posibilidad de reali:,;ar un trabajo de ingeniería
inversa para detectar parámetros ocultos y/ o definidos por el fabricante. 1fodiante
esta. práctica se podrían haber provoca.do una. serie de entradas al sistema y
mediante el análisis de la respuesta ante tales estímulos haber tratado de
decodificar parámetros qne el vehículo tuviera implementados. En trabajos futuros
sería interesante conectarse directamente con cualquiera de los buses del vehículo
pa.ra obtener toda la información que pueda ser filtrada a.l puerto OBD-11.

En cuanto al uso del smartphone para adquirir los datos, los mayores
inconvenientes son la necesidad de permitir la carga en el vehículo dado el gran
consumo de batería y que es un dispositivo que comparte recursos con diferentes
aplicaciones, hecho que dificulta la garantía de funcionamiento de la aplicación.
Por ello, la aplicación debe ser diseñada haciendo especial hincapié en optimizar el
consumo de batería, el envío de d atos a la red y el procesamiento, realizando 1111

desarrollo eficiente donde solo se actualicen y activen parámetros cuando sea

necesario y no ha.cer un refresco de da.tos superior a.l requerido por la aplicación
final. Pa.ra facilitar esta labor, al igual que se ha. rea.liza.do en la. aplicación
desarrollada, se debe posibilitar una configuración total.

Además de para enviar la información al servidor, el uso del srnartphone

permite adquirir datos del GPS. pudiendo obtener la. loca.liza.ción del automóvil
con una precisión relativamente buena que abre grandes posibilidades al hacer
corresponder un evento en el espacio y en el tiempo. También permite adquirir
datos de sensores y pese a que estos da.tos no serán muy fía.bles debido a la.
imprecisión d e la mayoría de sensores integrados en est os dispositivos servirán
para reflejar ciertas situaciones del vehículo }r del entorno. Además, permite el
almacenamiento, la monitorización gráfica en tiempo real y la visualización de
rutas que hacen interesante el uso de la aplicación pa.ra el usuario.
C6. COKCLCSIOKES | 106

Pese a realizar todas estas tareas simultáneamente el rendimiento del

smartphone es el adecuado; en el caso de la aplicación diseñada., trabajando con
1111 móvil que cuenta con un procesador y memoria discretos, se ha conseguido
estando activas todas las características implementadas reali;::ar una llamada sin
verse afectada ni la recolección ni la difusión de los datos con un tiempo de
refresco de 50 ms. Quedan elementos pendientes para. mejorar la aplicación en
futuras actua.liza.ciones. desde una. mejora. de la. monitorización gráfica. con la
incorporación de nuevos eventos y gráficas a añadidos para facilitar la
configuración de la aplicación desde el servidor o incluso permitir la petición de
parámetros a distancia.

Por otro lado, estos sistemas cuentan con algunos problemas para su
implantación como los citados anteriormente: seguridad, fiabilidad, robustez y
garantía de recibir todos los datos generados. Esto hace difícil su integración en
sistemas donde estas características sean críticas y será necesario definir con
minuciosidad la arquitectura y los protocolos implicados, y es en lo que se trabaja
actualmente tanto en las compañías como en los grupos de estandarización. Los
grandes proyectos que se han implementa.do, como eCa.11 o sistemas propietarios
de los fabricantes. generalmente va.n integra.dos dentro del vehículo minimizando
así muchos problemas de seguridad: a sn vez, existen acuerdos con operadoras de
telefonía móvil de modo que se consigue evitar el pago del usuario por usar las
redes, eliminando una gran barrera de entrada.

Desde mi punto de vista estos motivos suponen el mayor impedimento

para el despliegue de esta tecnología basada en smartphone y un conector externo;
cuando se produzca la gran explosión de vehículos conectados y sus servicios
asocia.dos, segura.mente vendrán ligados a sistemas integra.dos dentro del vehículo.
Aunque ambos métodos podrían coexistir los primeros años principalmente debido
al gran número de vehículos del mercado que no lo llevan, el uso de esta
tecnología quedará relegado mayoritariamente al uso por parte del cliente para
monitorización. mejora de eficiencia, localización, obtención de DTCs, etc ... o a
servicios donde la garantía y la seguridad no entren en juego, consolidándose en
grandes servicios la opción integrada dentro el vehículo.

Por tanto 1 la definición del método de adquisición y transmisión de los

datos de un vehículo a la red tendrá un papel fundamental, y en una época donde
los datos tienen cada vez más valor, su gestión será de suma importancia para las
empresas que puedan estar dentro del negocio. Con su adquisición, se abre un
abanico de posibilidades y responsabilidades para todas las compañías implica.das
que deben responder al reto adecuada.mente ya que no solo influye en su economía
sino que también involucra a la seguridad dentro d el vehículo.
 |

▪ ▪

▪ ▪

Bit A7 A6 A5 A4 A3 A2 A1 A0 B C D
Función MIL ON? Número DTCs Test Disponibilidad de test Completitud de test


109 | APENDICES

pese a ser tócnicamentc equivalentes se distinguen en cuanto al límite de emisiones

permitido. El valor numérico decodifica.do se corresponde con la descripción del
estándar seguido de acuerdo a la siguiente tabla:

A Descripción
1 OBD-II as defined by the CARB
2 O BD as defined by the EPA
:3 OBD and OBD-II
4 OBD-I
,5 \"ot ODD complíant
6 EODD (Enrope)
7 EOBD aml OBD-II
8 EOBD aml OBD
g EOBD, OBD and OBD II
10 .JOBD (.Tapan)
11 .JOBD and OBD II
12 .JOBD and EOBD
u .JOBD, EOBD, and OBD II
14-16 Reserved
17 Engine :\fannfacturer Diagnostics (El\,fD)
18 Engine :\fannfacturer Diagnostics Enhanced (KVID+)
19 Heavy Dnty On-Doard Diagnostics (Chíld/Partial) (HD ODD-C)
20 Heavy Dnty On-Doard Diagnostics (HD OI3D)
21 \Vorld Wide Harrnoni?:ed OBD (W\VH OBD)
22 Rescrved
23 Heavy Duty Euro OBD Stage I ,vithout Nüx control (HD EOBD-I)
24 Heavy Duty Euro OBD Stage I ,vith Nüx control (HD EOBD-1 N)
25 Heavy Duty Euro OBD Stage II without NOx control (HD EOBD-II)
26 Heavy Duty Euro OBD Stage II with NOx control (HD EOBD-II ~)
27 Reserved
28 Brazil OBD Phase 1 (OBDBr-1)
29 Brazíl OBD Phase 2 (OBDBr-2)
::m Korean ODD (KOI3D)
31 India OBD 1 (IOBD 1)
32 India OBD II (IOBD II)
33 Heavy Duty Euro OBD Stage VI (HD EOBD-IV)
34-250 Reserved
251-255 ~ot available for assignment (SAE .J19:39 special meaning)

Tabla A-2 Correspondencia entre el valor del PID SlC y el estándar seguido
 |


|
 |

≈
|


 |

Hexadecimal 9 8 3 B 8 0 1 3
Binario 1 0 0 1 1 0 0 0 0 0 1 1 1 0 1 1 1 0 0 0 0 0 0 0 0 0 0 1 0 0 1 1
PID 1 2 3 4 5 6 7 8 9 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20
 |

Hexadecimal A 0 1 9 A 0 0 1
Binario 1 0 1 0 0 0 0 0 0 0 0 1 1 0 0 1 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1
PID 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40

Hexadecimal 4 0 D E 0 0 0 0
Binario 0 1 0 0 0 0 0 0 1 1 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
PID 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60
 |


|


|
|


|
|



 |


|
 |


|