El servicio 0x09 del protocolo OBD2 en el toyobaru

O como saber que versión de software tenemos instalada, entre otras cosas ...

Vimos en una entrada pasada del blog como acceder al bus CAN para escribir datos en él. Esto nos permite acceder a los distintos servicios OBD2 que soporte la centralita.

De hecho, en esa misma entrada accedíamos al PID 0x02 del servicio 0x09 para obtener el identificador del vehículo (VIN). 

Vamos en esta entrada a revisar todas las posibilidades que nos ofrece la centralita del toyobaru (un GT86 en mi caso) bajo este servicio 0x09. Empezaremos por arrancar un proceso que nos monitorice las respuestas del bus CAN que nos envía la centralita, para lo cual, desde un terminal ejecutaremos:

$ candump can0,7DF:7FF,7E0:7E0

A continuación enviáremos el PID 0x00. Este PID, en el servicio 0x09 y en otros servicios 0BD2 (que veremos más adelante) indica a la centralita que responda con los primeros 32 PIDS soportados por el servicio. Para ello, en otro terminal lanzaremos la siguiente orden;

$ cansend can0, 7df#0209000000000000

donde:

  • 0x02, es la longitud del mensaje que vamos a enviar a la centralita (2 bytes)
  • 0x09, es el servicio OBD2 con el que queremos trabajar
  • 0x00, es el PID que enviamos

y el resto de 0x00 son bytes de relleno.

En el terminal donde estamos monitorizando las respuestas aparecerá el mensaje de respuesta de la ECU;

7E8: 06 49 00 55 00 00 00 00

La interpretación de esta respuesta se realiza mediante el protocolo SAE J1979, e indica;

  • 0x06, es la longitud de la respuesta (6 bytes)
  • 0x49, indica una respuesta al servicio 0x09.
  • 0x00, indica una respuesta al PID 0x00
  • 0x55000000, son los 4 bytes de respuesta (que junto con el PID y el indicador de servicio completan los 6 bytes que nos envía la ECU)

El último 0x00 es un byte relleno que no aporta información.

Con lo cual, la respuesta ha sido 0x55000000. Según la norma, la respuesta que se envía identifica los PIDS del 0x01 al 0x20 por cada bit de la respuesta.

Así, si pasamos la respuesta recibida a binario, obtenemos:

01010101 00000000 00000000 00000000

Lo que indica que se soportan los PIDs: 0x02, 0x04, 0x06 y 0x08, que son los que tienen su correspondiente bit a 1.

Veamos que nos ofrecen ...

Servicio 0x09 PID 0x02 - Vehicle Identification Number

Como ya vimos en la entrada citada anteriormente, enviando el PID 0x02 del servicio 0x09 la centralita responde con el número de identificación del vehículo (VIN).

Para ello, basta mandar:

$ cansend can0, 7df#0209020000000000

y en el terminal donde estamos monitorizando las respuestas aparecerá:

7E8: 10 14 49 02 01 4A 46 31

Como ya vimos, una trama iniciada por 0x10 indica una primera trama de un grupo de tramas para completar más de 7 bytes (que es lo máximo que cabe en una trama CAN). En este caso 0x14 bytes (segundo byte de la trama). Y en estos casos el protocolo requiere un control de flujo que se asegure de que el receptor está preparado para recibir más de una trama, para lo cual, una vez listos hay que mandar:

$ cansend can0,7E0#3000000000000000

Y será entonces cuando la ECU remita el resto de información en tramas consecutivas (que se caracterizan por empezar por tener el primer nibble (medio byte) a 0x2, y en el segundo nibble llevar la cuenta de la secuencia. Recibiremos:

7E8: 21 5A 4E 36 4C 38 31 44

7E8: 22 47 30 30 32 39 30 37

Por lo que en total, los datos recibidos son;

  • 0x49 0x02 0x01 0x4A 0x46 0x31, (6 bytes) en la primera trama, pues el primer 0x10 es el indicador de primera trama y el 0x14 es la longitud total de los datos.
  • 0x5A 0x4E 0x36 0x4C 0x38 0x31 0x44, (7 bytes) en la segunda trama, pues el primer 0x21 indica que es la primera trama de una secuencia.
  • 0x47 0x30 0x30 0x320x39 0x30 0x37, (7 bytes) en la tercera trama, pues el primer 0x22 indica que es la segunda trama de una secuencia.

Y no recibimos más, pues 6 + 7+ 7 = 20 bytes que en hexadecimal son los 0x14 que nos había llegado como longitud de datos a recibir.

Si descodificamos los datos atendiendo al protocolo, nos encontramos con:

  • 0x49, que indica la respuesta al servicio 0x09.
  • 0x02, que indica la respuesta al PID 0x02
  • 0x01, que indica que a continuación viene una instancia de datos (no se cuando se puede mandar más de un VIN, pero la norma lo recoge)
  • Y una ristra de 14 bytes, que si los representamos en ASCII obtenemos: JF1ZN6L81DG002907, el número de bastidor de mi coche.

Servicio 0x09 PID 0x04 - Calibration ID

Para obtener la identificación de los parámetros de la ROM instalada en el coche hay que hacer uso del PID 0x04. Para ello

$ cansend can0, 7df#0209040000000000

Para recibir

7E8: 10 13 49 04 01 5A 41 31

De nuevo, se requiere control de flujo, por lo que tras enviar:

$ cansend can0,7E0#3000000000000000

obtenemos el resto de la respuesta:

7E8: 21 4A 37 30 30 47 00 00

7E8: 22 00 00 00 00 00 00 00

No entro ya en los detalles de la decodificación. Un lector avezado, siguiendo los pasos comentados anteriormente, pronto averiguará que lo que manda la ECU es ZA1J700G, el código de la ROM que tengo instalada en la ECU.

Y una rápida búsqueda con este dato por internet te indica que es una versión muy obsoleta y se te recomiendan una actualización por la versión oficial ZA1JA02G (mucho más actual) y compatible con la ROM del vehículo (o por una reprogramación a medida ... claro)

Servicio 0x09 PID 0x06 - Calibration Verification Numbers (CVN)

Este es el código de verificación (checksum) de que la ROM está bien grabada. Para obtenerlo:

$ cansend can0, 7df#0209060000000000

Y en este caso recibimos una respuesta de 7 bytes que cabe en una sola trama:

7E8: 07 49 06 01 4E 0C C5 7F

La descodificación:

  • 0x07, es la longitud de los datos
  • 0x49, indica la respuesta al servicio obd2 0x09.
  • 0x06, indica la respuesta al PID 0x06
  • 0x01, indica una única ocurrencia de CVN.
  • 0x4E0CC57F, es el CVN en si. En este caso es un número, no requiere conversión adicional.

Servicio 0x09 PID 0x08 - In-Use Performance Tracking

La implementación de OBD2 en los vehículos se les exigió a los fabricante, principalmente, para poder revisar el comportamiento del vehículo de cara a las emisiones contaminantes que produce. Y entre otras cosas, la norma exige que se implementen algoritmos de software que rastreen el rendimiento en uso para los componentes de los sistemas anticontaminación: Catalizadores, sondas lambda, EGR, etc.

Esto se realiza mediante unos contadores de uso que se puede monitorizar con el PID 0x08 del servicio OBD2 0x09 (Nótese que cuando un valor no está implementado se muestra como 0x0000). Así, si interrogamos a nuestro Toyobaru:

$ cansend can0, 7df#0209080000000000

obtenemos:

7E8: 10 2B 49 08 14 00 55 01

Que indica que se nos van a enviar 0x2B bytes (43), por lo que se requiere de nuevo control de flujo, por lo que enviando;

$ cansend can0,7E0#3000000000000000

y obtenemos el resto de la respuesta:

7E8: 21 06 00 5E 00 55 00 00

7E8: 22 00 00 00 6B 00 55 00

7E8: 23 00 00 00 00 B3 00 55

7E8: 24 00 00 00 00 00 00 00

7E8: 25 00 00 75 00 55 00 00

7E8: 26 00 00 00 00 00 00 00

donde;

  • 0x2B, es la longitud (43 bytes)
  • 0x49, es el indicador a una respuesta al servicio 0x09.
  • 0x08, es el indicador del PID 0x08
  • 0x14, es el número de contadores que se envían (20 contadores de 2 bytes cada uno).

Contadores:

  1. OBDCOND: 0x0055 = 85. (Condiciones de Monitorización OBD encontradas)
  2. IGNCNTR: 0x0106 = 262 (Número de veces que se ha arrancado el motor)
  3. CATCOMP1: 0x005E = 94 ( Número veces que se han encontrado las condiciones necesarias para detectar un fallo del sistema de catalizador del banco 1)
  4. CATCOND1: 0x0055 = 85 (Número de veces que el vehículo se ha utilizado en las condiciones especificadas de control del catalizador)
  5. CATCOMP2: 0x0000 = No implementado (igual que CATCOMP1, pero para el banco 2)
  6. CATCOND2; 0x0000 = No implementado (igual que CATCOND1, pero para el banco 2)
  7. O2SCOMP1: 0x006B = 107 (Número veces que se han encontrado las condiciones necesarias para detectar un fallo del sensor de oxígeno del banco 1)
  8. O2SCOND1: 0x0055 = 85  (Número de veces que el vehículo se ha utilizado en las condiciones especificadas de control del sensor de oxígeno)
  9. O2SCOMP2: 0x0000 = No implementado (igual que O2SCOMP1, pero para el banco 2)
  10. O2SCOND20x0000 = No implementado (igual que O2SCOND2, pero para el banco 2)
  11. EGRCONP: 0x00B3 = 179 (Número veces que se han encontrado las condiciones necesarias para detectar un fallo en el sistema VVT)
  12. EGRCOND: 0x0055 = 85 (Número de veces que el vehículo se ha utilizado en las condiciones especificadas de control del sistema VVT)
  13. AIRCOMP: 0x0000 = No implementado
  14. AIRCOND: 0x0000 = No implementado
  15. EVAPCOMP: 0x0000 = No implementado
  16. EVAPCOND: 0x0000 = No implementado
  17. SO2SCOMP1: 0x0075 = 117 (Número veces que se han encontrado las condiciones necesarias para detectar un fallo del sensor de oxígeno secundario del banco 1)
  18. SO2COND1: 0x0055 = 85 (Número de veces que el vehículo se ha utilizado en las condiciones especificadas de control del sensor de oxígeno)
  19. SO2SCOMP2: 0x0000 = No implemenatado
  20. SO2COND10x0000 = No implementado
Los valores que presenta mi ECU son muy bajos, pero eso es debido a que hace un par de meses que pasé la llamada a revisión por el tema de los muelles de las válvulas y la ECU se 'reseteó'.

Añadir un comentario

El código HTML se muestra como texto y las direcciones web se transforman automáticamente.

Page top