Accediendo a bus CAN para escribir en él.

Una puerta abierta para dialogar con la ECU del toyobaru

El pasado mes de marzo ya vimos como podíamos acceder al bus CAN del toyobaru (y en general de cualquier coche cuyo bus CAN tenga una velocidad de 500.000 bits/s.), pero lo hacíamos en modo de sólo lectura (listen-only on)

# ip link set can0 type can bitrate 500000 listen-only on

que nos permitía, tras levantar el dispositivo:

# ip link set can0 up

acceder a los datos del bus CAN, mediante el uso, por ejemplo, del programa candump o de un analizador de protocolos como wireshark.

Si además de escuchar, queremos escribir, basta eliminar el parámetro listen-only on de la primera orden ip. De este modo:

# ip link set can0 type can bitrate 500000
# ip link set can0 up

levantamos el dispositivo con privilegios de lectura y escritura y ya estamos en condiciones de escribir en el bus.

Una forma sencilla es mediante el programa cansend, que nos permite enviar una ristra de datos al bus CAN.

Pero ¿ que enviamos ?

Si no queremos perturbar el buen funcionamiento del coche, hay que seguir la norma OBD. En particular, del conjunto de protocolos que conforman la norma OBD, hay que seguir el recogido en la norma ISO 15765-2. Y entonces podremos establecer un diálogo con nuestra ECU y acceder a toda aquella información disponible bajo dicha norma.

Vamos a probarlo. Para ello, lanzamos en un terminar un comando candump que nos guardará las tramas del protocolo OBD. Para ello:

candump can0,7DF:7FF,7E0:7E0 > /tmp/obd.log

Y desde otro terminal vamos a lanzar las ordenes con cansend.

Si os fijáis en la norma OBD, en el modo 09, con el PID 02, la ECU nos devuelve el VIN (el identificador del vehículo, lo que normalmente conocemos como el número de bastidor).

Para ello tenemos que enviar, bajo el identificador 0x7DF (mensaje broadcast), la secuencia de datos 0x02 0x09 0x02, que significa:

  • 0x02 -> 2 bytes de longitud
  • 0x09 -> modo 09
  • 0x02 -> Número de identificador del vehículo.

Las tramas CAN tienen 8 bytes de longitud como máximo, sin embargo el numero VIN es mayor de 8 caracteres, por lo que necesitamos recibir más de una trama en la respuesta. Eso lo complica un poco, pues tras enviar la primera trama, la ECU se queda esperando que le reclamemos los siguientes datos para asegurarse de que estamos preparados. Eso se hace con el identificador 0x7E0 y el byte de datos a 0x30.

Por tanto, la secuencia de órdenes que usaremos será:

cansend can0 7df#0209020000000000  # OBD modo 09 PID = 02 -> VIN
sleep 0.05 # Damos tiempo a la ECU a que mande la primera trama
cansend can0 7e0#3000000000000000 # solicitamos el resto de las tramas.

Una vez lanzadas estas órdenes, paramos el candump que teníamos corriendo y accedemos al fichero /tmp/obd.log que se ha generado, y nos encontramos con:

can0  7DF   [8]  02 09 02 00 00 00 00 00
can0  7E8   [8]  10 14 49 02 01 4A 46 31 
can0  7E0   [8]  30 00 00 00 00 00 00 00
can0  7E8   [8]  21 5A 4E 36 4C 38 31 44
can0  7E8   [8]  22 47 30 30 32 39 30 37

Podemos ver, la orden que hemos mandado (0x7DF) y la contestación de la ECU (0x7E8), que vemos que empieza por 0x1014. Eso quiere decir que es una trama extendida (no le cabe en 8 bytes) con una longitud de 0x14 bytes (20 caracteres). Luego viene un 0x49 que significa que es una respuesta al servicio 9, y luego un 0x02, que es el PID que le hemos requerido. Y luego ya empiezan a venir los datos que conforman la respuesta.

Como es una trama extendida, se queda esperando la conformidad y entonces llega la 0x7E0 que hemos mandado 5 centésimas de segundo después. Y nos llegan dos nuevas tramas 0x7E8. Como veis, una tiene como primer byte 0x21 y la otra 0x22. El primer 2 significa que es una trama de tipo 'consecutivo', y el siguiente carácter (1 o 2) es el número de secuencia de la trama en el conjunto de los datos. El resto de la trama, son los bytes de datos.

Y si ... si pasáis esos datos de hexadecimal a ASCII sabréis cual es el número de bastidor de mi toyobaru ...

Como veis, hablar con la ECU es un tanto enrevesado, especialmente si no estáis habituados a trabajar con protocolos de comunicaciones. Exige unos conocimientos mínimos de la norma ISO 15765-2, pero abre la puerta a obtener un amplio abanico de datos del coche, que iremos desgranando en próximas publicaciones del blog.

Si queréis jugar con esto, sed prudentes con lo que mandáis, especialmente si no tenéis experiencia. Echadle un vistazo antes a el OBDII completo y a la norma ISO 15765-2, y entended lo que mandáis y para qué. Y entrareis en las entrañas del coche ...

Añadir un comentario

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

Page top