TELE-002 Esquema típico de un sistema de adquisición de datos

Introducción:

Seguimos con los conceptos básicos, evidentemente necesitamos tener unos conceptos mínimos antes de afrontar temas más complejos.

En este post vamos a ver el esquema típico de una sistema de adquisición de datos y profundizar un poco más en los conceptos que hemos ido introduciendo en el post anterior. Llegados a este punto vamos a seguir necesitando la ayuda de la adquisición de datos basada en hermanos como ilustración simpática de la realidad.

Esquema típico de adquisición de datos.

 

esquemaAD(Pulsa sobre la imagen para ampliarla)

Este es un diagrama ilustrativo, no debes tomarlo como una realidad absoluta, solo pretendo con este ejemplo introducir los distintos componentes que intervienen en la adquisición de datos y la relación entre ellos.

Sensores:

En una definición casera son los dispositivos que se encargan de medir las variaciones de los distintos componentes del vehículo ( RPM, VELOCIDAD, TEMPERATURA,PRESIÓN, etc ) , como vimos en el post anterior la medición se realiza mediante la variación de señales eléctricas que luego deben ser transformadas en señales digitales para que sean entendidas por el ojo humano.

ECU:

LA ECU (Engine Control Unit) o Unidad de Control de Motor… vamos la centralita de toda la vida o como dicen los italianos «La centralina», será la encargada de leer el valor de los sensores y transformar ese valor eléctrico en un valor digital que luego será enviado por la Bus Can, para que pueda ser utilizado por los distintos dispositivos que están unidos a la misma, en este ejemplo simplificado estaría el Dashboard  (tablero de abordo o cuadro) y la adquisición de datos o datalogger.

1390149827JPG

(Pulsa en la imagen para ampliar )

Bus Can:

Para definir la Can necesitaríamos todo un curso de electrónica avanzada, pero simplificando es el canal de comunicación por el que se transmiten los valores normalizados de los sensores. Es decir, si simplificamos mucho, muchísimo y a nivel conceptual no real, por el bus can viajan los datos que se han transformado en la ECU y se han convertido en un paquete que tiene siempre el mismo formato. Aunque en post venideros veremos como la ECU construye ese paquete y como podemos ver la posición exacta en la que viajan los datos aquí podemos introducción un concepto nuevo para que os vaya sonando denominado Datagrama Can que es el paquete de información que viaja por el bus can.

Supongamos ( no es exactamente así ) que el datagrama can, tiene la siguiente estructura.

DatagramaCAN

(Pulsa en la imagen para ampliar )

Cronológicamente funcionaría así.

    1. Los sensores continuamente están representando valores eléctricos en función del estado de lo que están midiendo (es decir tenemos voltios u ohmios en función del sensor y del canal que estemos leyendo).
    2. Estos sensores están conectados mediante un cable a un pin de la centralita.
    3. X veces por segundo la centralita revisa cada pin suyo e identifica los valores de entrada (es decir el valor que está leyendo el sensor).
    4. La centralita transforma ese valor eléctrico en un valor digital (supongamos que lee 3,5 ohmios por el pin 23 y que este corresponde a la temperatura de agua, y que se ha establecido que ese valor de ohmios es en realidad 39 grados centígrados).
    5. La centralita crea el datagrama, siempre igual y lo envía a la línea Can para que pueda ser leído por los demás dispositivos.

La importancia del bus can ha sido enorme porque antes de existir, tenías que duplicar todos los sensores, imaginaos la situación siguiente, tengo un vehículo en el que quiero meter en la adquisición de datos la temperatura de agua, pues necesitaría dos sensores ( típico de los vehículos de los 80 ) donde uno es para la inyección y otro para la adquisición. Otra solución es utilizar un hermano con un blog de notas pero esta ya la habíamos descartado.

Insisto que esta definición debe tomarse solo a nivel conceptual ya que no es exactamente así, ya llegaremos al punto donde esta definición la haremos correcta e incluso veremos como algunas marelli construyen el fichero de datagrama, esto será útil cuando tenemos una adquisición de datos de distinto marca que la ECU y nos permitirá identificar en el datalogger los canales que llegan por la can, lo que entenderemos como BLVDC es decir (Búscate La Vida Destripando la Can)

Con algún coche he trabajado así y no os imagináis la enorme maraña de cables que existe, y por lo tanto lo complejo que es tanto la instrumentación de diferentes canales como la identificación de un fallo. Cuantas más canas tenga el ingeniero más cables sueltos hay en el coche en el que está trabajando …

Dashboard:

El dasboard  (cuadro) puede estar controlado por la ECU o por el DATALOGGER o puede tener autonomía para leer por si mismo el Canal Can. Cada ingeniero construye su sistema de adquisición en función de la experiencia y/o herramientas que pueda tener en cada momento. Por esto es de suma importancia documentar los proyectos en los que se trabaja, para que con el paso del tiempo no haya que tirar de memoria (en mi caso nula) o si el vehículo lo tiene que mantener otro ingeniero que toca hacer ingeniería inversa o el típico (¿pero esto quien te lo ha hecho?, hay que tirarlo todo !!!) con lo que se pierde mucho tiempo dinero y muuuchos mosqueos.

Evidentemente existen muchos tipos de dashboard, ya veremos y estudiaremos algunos, y la forma en la que leen los datos y se configuran pueden ser, como ya dijimos a través del DATALOGGER o la ECU o tienen la posibilidad de ser entidades propias.

images

Datalogger:

 Aquí tenemos al protagonista de esta sección, es el encargado de grabar e interpretar los datos que queremos analizar en el futuro. Los datalogger, acceden a la Can para leer todos los parámetros que llegan desde la centralita, además suelen tener entradas propias para leer otros canales que no están contemplados en la ECU o que por problemas de espacio no los podemos instrumentar desde la ECU, canales como el desplazamiento de la suspensión, desplazamiento del pedal de freno y todo lo que podamos imaginar, si son medibles las podremos instrumentar. Aunque en su momento hablaremos extensamente de este dispositivo debemos ir dándonos cuenta que al igual que en la adquisición de datos basada en hermanos (ver post anterior) la memoria es finita, en el caso de la primera es la capacidad de la libreta y en este caso es la memoria interna, así que vamos a tener que hacer un trabajo de configuración importante para poder sacar los datos sin que se nos agote la memoria y aquí comienza el trabajo del telemetrista, que debe analizar exactamente que es lo que necesita en cada momento creando lo que se denominan tablas de adquisición que contienen  los canales concretos que necesitan en cada momento. Lo habitual es que se utilicen unas tablas de adquisición distintas entre los rallyes y los test.

Como adelanto, tenemos que hacernos las siguientes preguntas.

    1. ¿Varía a la misma velocidad la revolución del motor que la temperatura de agua?
    2. ¿Necesito todos los canales de adquisición para un rallye?
    3. ¿En un rallye necesito grabar la información todo el tiempo?

Estás preguntas y sus respectivas respuestas son las que van a definir que tabla de adquisición vamos a generar.

Introduzco las siguientes definiciones no formales necesarias en este punto.

Canal: Cada uno de las magnitudes que vamos a analizar ( RPM, PAP, VEL, PH2O, etc.)

Frecuencia de adquisición:  Es la cantidad de veces por segundo que voy a revisar y grabar en el datalogger un canal, se mide en Hercios Hz. ( 1 hercio implica 1 ciclo por segundo).

Os propongo el siguiente ejercicio para que vayáis viendo la importancia y la forma de pensar que tienen los ingenieros a la hora de construir sus tablas de adquisición.

Ejercicio 1: Si utilizo solo 3 tipos de frecuencias ( 10Hz, 5 Hz y 1 Hz) ¿qué frecuencia de adquisición aplicarías a los siguientes canales?

    1. RMP ( Revoluciones ) =
    2. PAP ( Mariposa de acelerador ) =
    3. GEAR ( Cambio de marcha ) =
    4. TH2O ( Temperatura de agua ) =
    5. TOIL ( Temperatura de aceite ) =

Podéis responder como comentarios al post o simplemente plantearlo para vosotros mismos, lo único que pretendo con esto es que veáis que la variación de cada canal es distinta en función del tiempo.

Conclusiones:

Hemos visto un ejemplo bastante básico de un esquema de adquisición de datos, en la actualidad la mayoría de las ECU vienen incorporadas módulos de datalogger con lo que funcionan de forma conjunta, aún así he preferido hacer un esquema heterogéneo que permita, desde mi punto de vista, dar una imagen más global del funcionamiento.

Hay que observar también que cada uno de los componentes ( ECU, DASHBOARD, DATALOGGER) tiene un software que es el que nos permite definir y configura los parámetros, las frecuencias, los trigger, etc

Bueno y hasta aquí este segundo post que espero haya sido de vuestro interés, os invito a sugerir temas o realizar observaciones en relación a la evolución de este portal.

Agradecimiento

Evidentemente llegado a este punto no me queda más que agradecer vuestro seguimiento, he recibido 39 correos de lectores del post anterior agradeciendo y aportando posibles temas, que estoy clasificando para ver cuando y como ir dando mi humilde aportación.

Muchas gracias a tod*s

Isaac R.H.R.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *