Download Diseño y realización de un sistema On Board Diagnostics

ALUMNO: Oscar Rayo Mansilla
ESPECIALIDAD: Electrónica
DIRECTOR: Jordi Sellarès González
DEPARTAMENTO: Física y Ingeniería Nuclear
1. INTRODUCCIÓN
 Motivación del proyecto
 Antecedentes
 Objetivos
 Descripción general
2. DISEÑOS
 Diseño del modem interface
 Construcción del programador JDM2
 Mejoras del modem interface
 Programas de prueba
 Diseño del software de control
3. RESULTADOS
 Descripción del funcionamiento
 Posibles aplicaciones
4. PRESUPUESTO
5. CONCLUSIONES Y MEJORAS
 Plan de trabajo
 Objetivos logrados
 Conclusiones finales
 Mejoras futuras del sistema
 Diagnóstico
técnico de las averías de un
vehículo a través de su computadora.
 Disponibilidad
coste.
 Evitar
de una solución de bajo
la dependencia de los servicios
oficiales del mantenimiento del automóvil.
OBD II
Equipamiento autodiagnosticable de abordo
 OBD-II (Estados Unidos), EOBD (Europa), y JOBD
(Japón)
 Sus características pueden monitorear prácticamente
todos los componentes que pueden afectar las
emisiones contaminantes
 Informaciones importantes sobre posibles fallas
detectadas

EE.UU.
Europa
1996 (OBD-II)
2001 (EOBD)
 Herramientas
y software disponible en el mercado
basados en el micro ELM327
Interface
con micro
ELM327
Software de control ScanTool.net
Interface
con “Bluetooth“
basada
en el
ELM327

Conseguir una comunicación estable con cualquier
centralita electrónica (ECU) de cualquier vehículo equipado
con OBD-II.

Conseguir desarrollar una aplicación portable a cualquier
sistema operativo y plataforma utilizando lenguaje JAVA y la
estructura de programación “por capas”.

Realizar mejoras en el hardware ya existente en el mercado
a partir del cual se construirá nuestra interface.

Demostrar que con la información disponible en la red, es
posible acceder a los sistemas de control que implementan
los fabricantes de automóviles en sus vehículos.
Modem
interface,
interprete entre la ECU
y el puerto USB.
Protocolos OBD-II:
SAEJ1850PWM
ISO 9141/14230
SAEJ1850VPW
ISO15765 (CAN)
OBD-II 16 PIN(Macho)
DB9 PIN(Hembra)
(J2850 BUS+) 2
(Masa chasis) 4
(Masa señal) 5
(CAN H) 6
(ISO 9141-2 K Line) 7
(J2850 BUS- ) 10
(CAN L) 14
(Linea L ISO 9141-2) 15
(Voltaje batería) 16
7
1+2
1+2
3
4
6
5
8
9
CABLEADO:
Cable
USB tipo A-B
Cable conector J1962
específico OBD-II.
 Gestión
del modem interface atreves del puerto
serie o USB.
 Configuración del
puerto
 Lecturas de
“códigos de error”
 Selección de
protocolos de
comunicación
 Lecturas a tiempo
real de los sensores
del motor
 Exploración del
tráfico de datos
Utilización
de un diseño disponible en la red para realizar mejoras
Interface basada en el microcontrolador PIC18F2550
Compatibilidad con el micro ELM327
Para realizar la placa de circuito impreso se utilizó el siguiente
“layout”:
Pistas de la cara inferior del circuito
Pistas de la cara superior del circuito
Distribución de componentes de la cara
inferior del circuito
Distribución de componentes de la cara
superior del circuito
Cumple con el
estándar ICSP de
Microchip
Montaje en placa de
baquelita para
prototipos
Construcción rápida y
con pocos
componentes

Funcionamiento correcto en varios
vehículos y diferentes protocolos

Problemas de comunicación en el
protocolo “SAEJ1850PWM” a través
de una “ECU” de diseño obsoleto
Pin 2 conector OBD-II(BUS+)
Pin 10 conector OBD-II(Bus-)
Duración del periodo de un bit
Un bit=1
Activo durante 8µs
Un bit=0
Activo durante 16µs
BUS+ activo
5v.
BUS- activo
0v.
24µs
Modificación del circuito por obtener tensiones
incorrectas en el BUS+
 Componentes
que gestionan el
protocolo
SAEJ1850PWM
 Q1(Canal-N)
 Q2(Canal-P)
 Resultado de la
modificación del
circuito
 Q1(NPN)
 Q2(PNP)
Las
especificaciones del protocolo indican que las
tensiones del BUS están dentro de los márgenes
Posibilidad de errores en las tramas enviadas
61 6A F1
01 00
Trama que el modem envía por defecto
0A
Unnable to connect
Respuesta real del modem,
al no responder la ECU
61 F1 6A 41 0C 0B 88 5C
Trama con la que debería responder la ECU
La
cabecera del trama (Header Field) especifica direcciones
de memoria
Solución mediante la modificación de la cabecera
Modificación de la cabecera (Header Field) accediendo
directamente al firmware del microcontrolador
:103C70000350E66EE66A00010028BC6F000E0120CA
:103C8000BD6FBCC0E6FFBDC0E6FF040E0024BE6FE2
:103C9000000E0120BF6FBEC0E6FFBFC0E6FFDDEC37
:103CA0001EF046E90028E96E000E0120EA6E610E59
:103CB000EF6E020E0024E96E000E0120EA6E6A0E26
:103CC000EF6E030E0024E96E000E0120EA6EF10E85
:103CD000EF6E0001030EBC6F00EBE9FF01EBEAFFA2
:103CE000BC51EF2642E9E7CFD9FF1200D9CFE6FF5A
Localización
de la
cabecera
:103C70000350E66EE66A00010028BC6F000E0120CA
:103C8000BD6FBCC0E6FFBDC0E6FF040E0024BE6FE2
:103C9000000E0120BF6FBEC0E6FFBFC0E6FFDDEC37
:103CA0001EF046E90028E96E000E0120EA6EE40EBA
:103CB000EF6E020E0024E96E000E0120EA6E100E77
:103CC000EF6E030E0024E96E000E0120EA6EF10E85
:103CD000EF6E0001030EBC6F00EBE9FF01EBEAFFA2
:103CE000BC51EF2642E9E7CFD9FF1200D9CFE6FF5A
Modificación
de la
cabecera y
del
“checksum”
Respuesta
de la ECU después de la modificación:
E4 10 F1 01 00 0A
C4 F1 10 7F 01 01 00 00 11 41
 7F 01: modo de trabajo no compatible
 Realización de pequeños programas de prueba
 Utilización del código fuente de ScanTool.net
 Mediante la herramienta Dev-C++ se diseñó un pequeño
con la siguiente estructura:







programa
main(): Arranca el hilo de ejecución.
init(): Carga las librerías y abre el puerto.
deinit(): Descarga las librerías y cierra el puerto.
read_comport(): Lee el puerto serie.
open_comport(): Abre el puerto serie.
close_commport(): Cierra el puerto serie.
send_command(): Escribe en el puerto serie
 Programa
de prueba utilizando la plataforma JAVA
public static void main(): Método que inicia la ejecución del programa.
public void Conectar(): Establece la conexión con el puerto serie
indicado.
 public void Enviar(): Escribe la trama de datos a enviar en el puerto serie.
 public void recibir(): Lee la trama de datos recibida del puerto serie.
 Public long timer(): Método que realiza la espera necesaria a la respuesta
del puerto.


Ejemplo del tratamiento de las tramas digitales recibidas y
enviadas:
Comando a enviar: ”01 00”
Código ASCII:” 48,49,48,48”
 Mas retorno de carro“01 00\r”
Código ASCII:”
48,49,48,48,13
 Si el protocolo a utilizar es SAEJ1850PWM:

SOF: Start Of Frame
Header Field: 61 6A F1
Data Field: 01 00
CRC: 0A
EOF: End Of Frame

Respuesta ECU
61 F1 6A 41 00 0B 88 5C

Respuesta Interface

Trama recibida en el puerto serie (Código ASCII)
48,49,48,67,13,10,54,65,70,49,54,49,52,49,48,48,48,66,56,56,53,
67,13,10,62,-1
01 00 6A F1 61 41 00 0B 88 5C



Realización de un software multiplataforma
mediante lenguaje JAVA
Utilización de la programación estructurada
“multihilo”
Diseñado en base a la estructura de programación
“por capas”
CAPA DE
PRESENTACIÓN
Interactúa con el usuario
de la aplicación
CAPA DE DOMINIO
Facilita el acceso entre
capas
CAPA DE DATOS
Gestiona las tramas de
datos procedentes del
modem
Capa de Datos:




Clase Conexión
Clase ControladorConexión
Clase lecturaTXTErrores
Clase MuestraIDs
Capa de Dominio:

Clase ControladorDominioConexión
Capa de Presentación:
Clases ControladorPrincipal y VistaPrincipal
 Clases ControladorErrores y VistaCodigosError
 Clases ControladorMediciones y VistaMediciones
 Clases ControladorProtocolo y VistaProtocolo

Arranque de la aplicación mediante archivos ejecutables
RunLinux.sh
RunWindows.bat
VisualOBD.jar
Uso de la librería “RXTXcomm”
Configuración del puerto serie
Selección del protocolo de comunicación

Labores de manteniendo de cualquier
profesional del sector

Labores de mantenimiento de uso
particular

Herramienta para aficionados a la
mecánica del automóvil
La siguiente tabla especifica el presupuesto detallado en euros:
Referencia
Material montaje interface
Cantidad
1
Precio unitario Precio total
20
20
Material montaje programador
1
5
5
Cable OBD-II a DB9 hembra
1
5
5
Cable USB tipo A-B
1
2
2
Hora trabajo
20
10
200
Total
232
Observamos que nuestro sistema cuesta 232€, frente a los 4000€
que pueden llegar a costar las herramientas que utilizan en
cualquier servicio oficial.











Conseguir todos los componentes y materiales.
Montar la interface y el programador.
Comprobar el correcto funcionamiento de la interface.
Instalación de los sistemas operativos WindowsXP y Linux
Ubuntu 8.04 con la respectiva maquina virtual de JAVA.
Instalar software compatible con la interface para comprobar
su correcto funcionamiento.
Conectar la interface a diferentes vehículos para asegurar su
funcionalidad.
Programar aplicaciones de prueba en C++ y Java.
Programar aplicación con entorno visual.
Verificar el correcto funcionamiento de la aplicación visual.
Verificar el correcto funcionamiento de la aplicación sobre la
centralita electrónica.
Verificar el correcto funcionamiento de la aplicación en
diferentes sistemas operativos, Windows y Linux.







Conseguir que el montaje de la interface funcione
correctamente.
Poder acceder a las centralitas electrónicas (ECU), según
el estándar OBD-II.
Consolidar la comunicación con el modem a través del
puerto serie mediante aplicaciones de software de propio
desarrollo en C++ y JAVA.
Conseguir descifrar las tramas digitales para obtener una
información fácilmente comprensible en pantalla de los
datos enviados por la ECU.
Finalizar el desarrollo de la aplicación visual en JAVA con
todas las opciones previstas.
Estabilizar la aplicación visual en JAVA sin que se
produzca ningún error ya sea de comunicación con la
interface o de manejo respecto al usuario.
Conseguir que la aplicación visual en JAVA funcione
correctamente tanto en Windows como en Linux.





El lenguaje de programación JAVA es una herramienta muy
potente, ya que permite que una misma aplicación pueda
funcionar de igual forma en diferentes sistemas operativos y
plataformas.
Es posible acceder a la centralita electrónica de un vehículo
utilizando montajes sencillos y ordenadores personales. En
realidad está al alcance de cualquier usuario particular.
La ingeniería inversa sobre un “firmware” (desensamblado), tiene
limitaciones y para realizar cambios significativos es necesario
disponer del código fuente, sino estamos limitados a pequeñas
modificaciones.
Los fabricantes de automóviles han implementado el estándar
OBD-II obligados por EE.UU. i U.E de una forma bastante
compatible como lo demuestra el que un pequeño dispositivo
genérico como el que se ha realizado, funcione en un amplio
rango de vehículos.
El hecho de disponer de un microcontrolador programable
disminuye la dependencia en la plataforma, ya que solo es
necesario que disponga de conexión USB, y a partir de aquí el
papel de las plataformas es de gestionar una conexión serie. El
procesado de los protocolos los realiza el micro.





Internacionalizar el software de control con la intención
de que pueda mostrar la información en varios idiomas
ya que en esta primera versión solo se muestran en
ingles.
Implementar todos los modos de trabajo del estándar
OBD-II en el software de control.
Dotar a la interface de una botonera y un pequeño
“display” para poder realizar las funciones más simples
de forma autónoma, como por ejemplo la lectura y
borrado de los códigos de error DTC.
Implementar en el software de control una opción de
autoayuda para poder entender y manejar el sistema
de forma más rápida. Esta mejora sería muy útil porque
los datos que se manejan son bastante abstractos.
Crear un paquete instalador que automáticamente
sitúe los ficheros necesarios del software para acelerar
su puesta en marcha.