ES2294209T3 - Sistema informatico para vehiculos. - Google Patents
Sistema informatico para vehiculos. Download PDFInfo
- Publication number
- ES2294209T3 ES2294209T3 ES03005050T ES03005050T ES2294209T3 ES 2294209 T3 ES2294209 T3 ES 2294209T3 ES 03005050 T ES03005050 T ES 03005050T ES 03005050 T ES03005050 T ES 03005050T ES 2294209 T3 ES2294209 T3 ES 2294209T3
- Authority
- ES
- Spain
- Prior art keywords
- data
- vehicles
- control unit
- computer system
- acts
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B23/00—Testing or monitoring of control systems or parts thereof
- G05B23/02—Electric testing or monitoring
- G05B23/0205—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
- G05B23/0259—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterized by the response to fault detection
- G05B23/0283—Predictive maintenance, e.g. involving the monitoring of a system and, based on the monitoring results, taking decisions on the maintenance schedule of the monitored system; Estimating remaining useful life [RUL]
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
- G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
- G01R31/005—Testing of electric installations on transport means
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
- G06F17/40—Data acquisition and logging
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C5/00—Registering or indicating the working of vehicles
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C5/00—Registering or indicating the working of vehicles
- G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C5/00—Registering or indicating the working of vehicles
- G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
- G07C5/0841—Registering performance data
- G07C5/085—Registering performance data using electronic data carriers
Landscapes
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Databases & Information Systems (AREA)
- Mathematical Physics (AREA)
- Data Mining & Analysis (AREA)
- Computer Hardware Design (AREA)
- Automation & Control Theory (AREA)
- Traffic Control Systems (AREA)
- Train Traffic Observation, Control, And Security (AREA)
- Time Recorders, Dirve Recorders, Access Control (AREA)
- Arrangements For Transmission Of Measured Signals (AREA)
- Testing And Monitoring For Control Systems (AREA)
- Electric Propulsion And Braking For Vehicles (AREA)
- Debugging And Monitoring (AREA)
Abstract
Un sistema informático para vehículos (10) que comprende una unidad de mando (11) y un registro de datos (12); actuando la unidad de mando para guardar los datos del vehículo relativos a un parámetro, dando los siguientes pasos: definición de un histograma (22) recopilados en un número de gamas (23a, 23b, 23c, 23d, 23e, 23f, 23g, 23h) unidas a un valor de recuento; recepción de un número de valor de datos, correspondientes a dichos parámetros, desde un sensor (15, 16, 17); e identificación de una gama (23a, 23b, 23c, 23d, 23e, 23f, 23g, 23h) correspondiente a cada valor de datos, e incrementar el valor de recuento relativo a la gama identificada (23a, 23b, 23c, 23d, 23e, 23f, 23g, 23h); caracterizado porque: el sistema informático para vehículos (10) comprende también un colector (14); la unidad de mando (11) y un registro de datos (12) conectados al colector (14); la unidad de mando (11) también funciona generando un mensaje de suceso en respuesta a un suceso, y transmitiendo el mensaje de suceso al registro de datos (12) por medio del colector (14); el registro de datos (12) actúa para recibir y guardar datos en respuesta al mensaje de suceso; y la unidad de mando (11) actúa transmitiendo al valor de cuenta al registro (12) por medio del colector.
Description
Sistema informático para vehículos.
Esta invención se refiere a un sistema
informático para vehículos.
Para asegurar la suficiente vigilancia y
conservación de los vehículos, en especial vehículos de mercancías,
en cuanto a los parámetros de rendimiento, es deseable que los
valores de datos relativos a los parámetros de rendimiento y
funcionamiento del vehículo estén conservados a disposición del
personal de mantenimiento o de otro personal que se desee. Esa
vigilancia u observación facilita reconocer el momento en que es
probable el vehículo necesita atención o mantenimiento, cuándo hay
que cambiar una pieza, e incluso si el vehículo se ha utilizado
indebidamente. Es necesario que se almacenen los valores de los
parámetros, que se transmitan a los dispositivos convenientes y se
hagan disponibles al personal de mantenimiento con la mayor
facilidad y fiabilidad posibles. Es por supuesto evidente que
cuando los valores correspondientes a varios parámetros están
guardados un tiempo prologado, se habrán acumulado gran cantidad de
datos.
Se sabe, por US 5,781,871, US 4,757,454 y EP
1059508 A registrar los valores de datos de un vehículo en una
unidad de mando en el vehículo, y por US 4,757,454 y EP 1059508 A
reunir los datos capturados en un histograma de recuento de
valores.
Un objeto de la invención es proveer un sistema
informático para vehículos nuevo y mejorado.
Con arreglo a la invención, se facilita el
sistema informático para vehículos como se define en la
reivindicación 1.
Ahora se describirá la invención, sólo a modo de
ejemplo, con referencia a las figuras adjuntas, en las que:
La figura 1 es un diagrama que ilustra el
sistema informático para vehículos,
La figura 2 es un diagrama ilustrativo de un
histograma del sistema de la figura 1,
La figura 3 es una ilustración de la estructura
de un mensaje para aplicación al sistema informático de la figura
1, y
La figura 4 es un diagrama ilustrativo de un
sistema de acceso remoto.
Refiriéndonos a la figura 1, se ilustra en
general un sistema informático para vehículos con la referencia 10,
que comprende una unidad electrónica de mando (UEM) 11, un
registro de datos 12 y un grupo de otros dispositivos 13. La UEM
11, el registro de datos 12 y los demás dispositivos 13 están
conectados al correspondiente colector de datos 14, compuesto en
este ejemplo por un CANbus, pero si se desea se pude poner cualquier
otro colector y protocolo de mensajes adecuado. La UEM 11, el
registro 12 y los otros dispositivos 13 transmiten y/o reciben
mensajes mediante el colector 14, que pueden ser datos o
instrucciones o cualquier contenido que se desee.
La UEM 11 está conectada al número que se desee
de sensores, que en este ejemplo son tres: 15, 16, 17, que actúan
para entregar a la UEM valores de datos de parámetros
seleccionados. Por ejemplos, los sensores 25 y 16 podrían ser de
velocidad de las ruedas y el sensor 17 de la presión de los frenos.
Se observará además que los otros dispositivos 13 pueden comprender
uno o dos sensores más 17 podrían actuar para transmitir a la UEM
valores de datos a través del colector 14. La UEM 11 contiene un
órgano de mando 18, que en este ejemplo es un microordenador RISC
provisto de una memoria de acceso aleatorio (RAM) 19 de a bordo y
una memoria no volátil 20, que en este ejemplo contiene una
EEPROM. El órgano de gobierno 18 y la memoria no volátil 20 están
conectados a un colector apropiado 21, por ejemplo, un colector
I^{2}C. La UEM va también conectada a una fuente de energía
(omitida) que es responsable y capaz de detectar la tensión que
suministra la fuente de energía.
La UEM actúa para recibir valores de datos de
los sensores 15, 16, 17 y de cualesquiera otros sensores, en su
caso, durante un espacio de tiempo prolongado. Se observará que se
generan gran número de valores de datos; en el ejemplo de sensores
de velocidad de las ruedas, se generan datos cada diez
milisegundos.
Para resolver el problema de disponer de memoria
suficiente para guardar los valores de datos, la UEM genera un
histograma por cada parámetro. Primero, un conjunto de histogramas
que comprende un histograma de cada parámetro que se desee vigilar,
definido por el órgano de gobierno 18. Para cada histograma se
define una serie de gamas (límite máximo y mínimo). En este
ejemplo, cada histograma comprende ocho gamas. La serie de
histogramas que comprende un recuento de valores correspondientes a
cada gama de cada histograma, se guardan en la memoria no volátil
20.
Al hacer la instalación, el órgano de mando 18
descarga el conjunto de histogramas de la memoria no volátil en la
RAM de a bordo 19. Si el conjunto de histogramas ha sido borrado,
después de la primera inicialización, la cuenta de cada gama de
cada histograma será cero. Según se vayan recibiendo valores de
datos de los sensores 15, 16, 17, el órgano de mando 18 determina
el parámetro al que corresponde cada valor, y luego identifica la
gama del histograma respectivo en el que cae ese valor de dato.
Entonces, la cuenta de valores de esa gama se incrementa en uno.
Cuando se recibe el valor de dato desde el sensor 15, 16, 17, es
evidente a que parámetro se refiere. Si se recibe el valor de dato
desde los otros dispositivos 13 a través del colector 14, el mensaje
transmitido por ese otro dispositivo 13 puede identificar el
dispositivo que lo ha enviado y/o el parámetro, y el órgano de
mando 18 podrá leer el mensaje y elegir el histograma y la grama
que ha de incrementarse.
Los valores de datos se reciben por la UEM 11
según un régimen seleccionado. En un régimen, se recibe una serie
de valores de datos a intervalos regulares y se actualiza
continuamente la cuenta de valores de las gamas de los histogramas
respectivos.
En otro régimen, los valores de datos se dejan
en la puerta de manera que se reciba periódicamente un número de
datos y se incrementa el recuento de valores correspondiente en
respuesta a la aparición de un valor máximo preseleccionado. Por
ejemplo, si el valor recibido se refiere a la actuación de la
válvula que aplica el freno, el valor guardado puede ser el valor
máximo de la presión suministrada al freno.
Es deseable que se actualice el conjunto de
histogramas guardados en la memoria no volátil 20, pasando los datos
del RAM 19 de abordo a la memoria no volátil 20. El traslado puede
efectuarse periódicamente o en respuesta a un suceso. Por ejemplo,
si no se detecta un suceso, los datos del RAM 20 se pueden guardar
en la memoria no volátil 20 cada dos minutos o a otro intervalo de
tiempo que convenga. La UME 11 puede recibir valores de datos de un
sensor que comprenda el cuentakilómetros del vehículo indicando la
distancia recorrida, y la cuenta de valores del histograma se
traslada cuando se haya llegado a un recorrido predefinido, por
ejemplo, cada diez kilómetros. Se pueden definir otros sucesos,
como por ejemplo, apagado del motor o aplicaciones del freno,
entonces el conjunto de histogramas se traslada, por ejemplo, cada
diez frenadas. Es evidente que se puede efectuar el paso con arreglo
a cualquier otro criterio o suceso que se desee. También se
observará que no es preciso guardar en la memoria no volátil 20 el
recuento de valores registrado por cada gama de cada histograma.
Por ejemplo, si la cuenta de valores conservada se guarda en la
memoria no volátil 20 en respuesta al recorrido de cierta distancia
sin que haya ocurrido ninguna aplicación del freno, sólo es
necesario guardar el recuento de valores de distancia recorrida del
histograma.
El conjunto de histogramas guardado en la
memoria no volátil 20 se puede extraer a voluntad. Por ejemplo, se
puede recibir de un sistema de diagnóstico adecuado, mediante el
colector 14, digamos, el Protocolo de Palabras Clave 2000. 0 se
pueden transmitir los datos conservados al registro 12, a través
del colector 14, en respuesta a un criterio determinado, por
ejemplo, la distancia recorrida o el tiempo transcurrido desde la
última actualización.
En el ejemplo presente, la UEM 11 comprende un
órgano de mando ABS, y por eso recibirá valores correspondientes a
los parámetros de demanda de presión del freno, velocidad de las
ruedas y velocidad del vehículo, y actuación del solenoide del
freno. En este ejemplo, los tipos de parámetros que se pueden
guardar aparecen a continuación con tiempos supuestos, aunque los
parámetros y los tiempos se pueden variar según se desee.
\vskip1.000000\baselineskip
Demanda de frenos contra
tiempo:
Con el sistema encendido, el conjunto de
histogramas guardados se carga en la RAM 19 desde la memoria no
volátil 20.
Cada 10 milisegundos se analizan los datos de
demanda de frenos actual y se actualiza el recuento de valores
correspondiente.
Cada 20 segundos se guarda el histograma en la
memoria no volátil 20.
Así el histograma presenta el tiempo
transcurrido a los diversos niveles de presión.
\vskip1.000000\baselineskip
Entrega de presión contra
tiempo:
Con el sistema encendido, el conjunto de
histogramas guardado se carga desde la memoria no volátil 20.
Cada 10 milisegundos se analizan los valores de
datos de presión entregada y se actualiza el recuento de valores
correspondiente.
Cada 20 segundos se guarda el histograma en la
memoria no volátil 20.
Así, el histograma presenta el tiempo
transcurrido a los diversos niveles de presión.
\vskip1.000000\baselineskip
Entrega de presión contra
tiempo:
Con el sistema encendido, el conjunto de
histogramas guardado se carga desde la memoria no volátil 20.
Cada 10 milisegundos se analizan los valores de
datos de presión entregada y se actualiza el recuento de valores
correspondiente.
Cada 20 segundos se guarda el histograma en la
memoria no volátil 20.
Así, el histograma presenta el tiempo
transcurrido a los diversos niveles de presión.
\vskip1.000000\baselineskip
Velocidad del vehículo contra
tiempo:
Con el sistema encendido, el histograma de
velocidad guardado se carga desde la memoria no volátil 20.
Cada 10 milisegundos, se analizan los valores de
datos actuales de velocidad del vehículo y se incrementa el
recuento de valores correspondiente.
Cada 2,5 km. se guarda el histograma en la
memoria no volátil.
Así, el histograma presenta el tiempo que ha
estado el vehículo en cada gama de velocidad.
\vskip1.000000\baselineskip
Histograma de la demanda punta de
presión por ciclo de aplicación de frenos del
histograma:
Con el sistema encendido, se carga el histograma
guardado de demanda punta desde la memoria no volátil 20.
Cada vez que se efectúa una aplicación de
frenos, se borra una demanda punta de presión del freno.
Cada 10 milisegundos se analiza la demanda de
presión y se guarda el valor máximo de este ciclo de aplicación del
freno.
Cuando deja de aplicarse el freno, se analiza el
valor del dato de demanda punta de presión y se incrementa el
recuento de valores correspondiente.
Cada diez aplicaciones del freno, se guarda el
histograma en la memoria no volátil 20.
Así, los datos presentan la variación de la
aplicación del freno que experimenta el vehículo.
\vskip1.000000\baselineskip
Actuación del
solenoide:
Con el sistema encendido, se carga el histograma
de actuación del solenoide desde la memoria no volátil 20.
Cada 10 milisegundos se analiza el estado de
cada solenoide y el cambio de dicho estado.
Cada 10 aplicaciones del freno se guarda el
histograma de actuación del solenoide.
También se puede guardar el histograma
dependiendo de la aplicación y de los parámetros que se deben
vigilar.
El conjunto de histogramas guardados se puede
descargar en un sistema de proceso adecuado, por ejemplo un PC, que
entonces puede leer el conjunto de histogramas guardados y
convertirlos en datos normalizados. Es evidente que el sistema
procesador debe conocer el parámetro al que se refiere el
histograma y los valores a que se refieren cada gama de cada
histograma. A continuación se muestra, en forma de tabla, un ejemplo
de datos brutos descargados.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
(Tabla pasa a página
siguiente)
\newpage
La primera columna es una marca de tiempo
generada por el sistema receptor. Las dos columnas siguientes
indican el colector que ha actuado, en este caso es el número de
identificación del CANbus. Rx indica que se trata de un mensaje
recibido y d que los números están guardados en forma decimal. El
número 8 indica el número de bites del mensaje y el número 32 de la
columna siguiente indica que es un mensaje de suceso. La siguiente
columna señala el parámetro, así que, en este ejemplo, 0 indica que
el valor es una lectura del cuentakilómetros. 1 indica que el valor
es de demanda de presión del freno, 2 indica que el valor es de
velocidad del vehículo, y así sucesivamente. Este dígito indica
efectivamente el histograma al que se refiere la cuenta de datos. El
siguiente dato muestra la gama de este histograma y las últimas
cuatro columnas representan un número de bites 32 que codifica la
cuenta de valores de la gama del histograma. Entonces el histograma
se puede procesar y generar un histograma como el que presenta el 22
de la figura 2, con la cuenta de valores correspondientes a las
gamas de 23a a 23h.
En el presente ejemplo se ofrece un histograma
que comprende 8 histogramas, cada uno con ocho gamas caracterizados
por un número 32 de bites, que necesitan 132 bites de memoria.
Puesto que la cuenta de valores se guarda como números de bites 32,
en los que los parámetros se vigilan cada 10 milisegundos, si cada
recuento se guarda en la misma gama de histograma, arroja un
espacio de 497 días antes de que el recuento de valores vuelva a
cero. En la práctica, los valores de datos recibidos resultan en
que se incrementan los recuentos de valores de las distintas gamas
del histograma, y es posible, en la práctica, conservar de este
modo por lo menos dos años. Como se espera que un vehículo sea
revisado y mantenido anualmente, en principio, los recuentos de
valores no deberán volver a cero entre intervenciones. Cuando el
vehículo haya sido revisado y se descargue el conjunto de
histogramas, es preferible poner el sistema a cero.
Es preferible actualizar los valores guardados
en la RAM de a bordo 19 y sólo actualizar periódicamente la memoria
no volátil 20, puesto que escribir en la memoria no volátil 20 tarda
considerablemente más que escribir en la RAM de a bordo 19. Si la
memoria no volátil 20 comprende un EEPROM, como en este ejemplo, la
vida útil del EEPROM es tal que sólo permite escribir en la memoria
un número limitado de veces antes de que se colapse. Así,
conservando la cuenta de valores en la RAM y actualizando
periódicamente la memoria no volátil 20, se abrevia el tiempo para
actualizar el histograma al recibir un valor de dato y se reduce el
número de escrituras en la memoria no volátil 20, alargando así la
vida útil de la memoria no volátil 20.
Se hace notar que se puede instalar cualquier
memoria de tipo y tamaño apropiado que se desee, dependiendo de los
números y gamas de valores que se quieran guardar.
En el ejemplo presente, el registro de datos 12
es de un tipo generalmente conocido, conectado a un módulo externo
de salida 24, por ejemplo, un módem radio-telefónico
celular. El registro actúa guardando los datos que recibe de la UEM
11 a través del colector 14, o de otro dispositivo 13, o también
para recibir datos directamente de un sensor conectado al registro
12. El registro puede también responder a un mensaje de suceso y
registrar datos seleccionados, si hiciera falta.
La UEM 11 del ejemplo presente funciona
generando un mensaje de suceso que se transmite al registrador 12 a
través del colector 14, aunque tal suceso pueda ser generado por
cualquiera UEM adecuada, u otro dispositivo 13 si se desea.
Preferiblemente, el registrador 12 funciona para mantener
continuamente almacenados los valores de datos que reciba más
recientemente, por ejemplo, en los últimos 20 segundos. El registro
12, al recibir un mensaje de suceso, retiene los valores de datos
más recientes, por ejemplo, los registrados en un plazo determinado
antes de la recepción del mensaje, desechando los demás, y luego
registra los valores de datos relativos a uno o más parámetros
elegidos en cualquier plazo prefijado o hasta recibir un mensaje de
suceso que mande parar. El plazo puede ser prefijado, tal como cinco
segundos, o puede ser variable de acuerdo con, por ejemplo, la
cantidad de datos que han de guardarse, o según unas condiciones que
desatan un suceso. Los datos guardados se pueden entonces
transmitir, mediante el módulo de salida 24, a un sistema de
diagnóstico apropiado, o a otro. La naturaleza del suceso que
provoca un mensaje de comienzo que transmita el registro 12, se
puede escoger a voluntad.
En el ejemplo en el que la UEM comprende un
mando ABS, se envía un mensaje al registro 12 al ocurrir un suceso
ABS, indicando que ha ocurrido un suceso ABS. El registro 12
retiene los valores de datos guardados en los 5 segundos anteriores
al mensaje de suceso de comienzo, y luego registra los valores de
datos relativos a los parámetros de velocidad de las ruedas y
presión del freno hasta que la UEM 11 genere un mensaje de suceso
de parada y lo envíe al registro 12.
En otro ejemplo, en que la UEM 11 está dotada de
medios para recibir y registrar códigos de error, se puede enviar
al registro 12 un mensaje de suceso de comienzo al recibir dicho
código de error. Se conocen dispositivos que, al ocurrir un error,
funcionan generando códigos de error o códigos de diagnóstico de
anomalías (DTC). Convencionalmente, la UEM 11 comprende un contador
de errores guardado en una memoria no volátil. Al ocurrir el primer
error, se guardan el código de error, las lecturas del
cuentakilómetros y otros valores de datos, y al ocurrir otro fallo
posterior, un contador indicando que se ha incrementado en 1 el
número de ese fallo ocurrido. Si la UEM funciona distinguiendo entre
errores nuevos y la repetición de fallos antiguos, es preferible
generar un mensaje de suceso de comienzo sólo al ocurrir un error
nuevo. De otro modo, podría esperarse que cuando existe un error
recurrente, el registro 12 se llene de datos repetidos en respuesta
al error recurrente. Sin embargo, cuando se detecte un código de
error antiguo a los dos segundos de encender el sistema, en el
ejemplo presente, la UEM 11 reacciona como si fuera un código de
error nuevo y genera un mensaje de suceso de comienzo, como se ha
descrito antes.
En un tercer ejemplo, en el que la UEM 11 actúa
guardando un conjunto de histogramas como se ha explicado, la UEM
11 puede actuar transmitiendo el conjunto de histogramas guardados
al registro 12 en respuesta a un mensaje de suceso de comienzo,
como se ha dicho antes. La UEM 11 genera un mensaje de suceso de
comienzo identificando el suceso como perteneciente a un
histograma, y luego transmite al registro 12 el recuento de valores
que están guardados, seguido de un mensaje de suceso de parada. Los
datos del histograma se pueden entonces descargar fácilmente del
registro 12, a través del módulo de entrada 24, sin necesidad de
conectar un dispositivo al colector 14.
Para asegurar que el colector 14 transmite los
mensajes y que los recibe debidamente el dispositivo receptor
indicado, se puede recurrir a un protocolo de mensajes adecuado.
Convencionalmente, con arreglo a la especificación de CAN 2.0B, se
hacen disponibles 29 bites (dígitos binarios) para proporcionar
información de dirección para un mensaje ilustrado generalmente en
el n° 25 de la figura 3. En la invención presente, los 29 bites de
la información de dirección 25 se asignan como sigue. Los primeros
tres bites contienen un identificador de prioridad. Los siguientes
cuatro bites 27 identifican el tipo de mensaje. Por ejemplo, 0001
correspondería a información de GPS, 0010 a información de
instrumentación, 0011 a información de GSM, 0100 a información de
TOP/IP, y así sucesivamente. Se observará que en esta parte del
mensaje se pueden identificar hasta dieciséis tipos de mensaje. El
siguiente bloque de 8 bites 28 comprende un bitio fuente que sirve
para identificar la UEM u otro dispositivo que genera el mensaje.
Este valor es común a todas la UEM u otros dispositivos del mismo
tipo, y se hace notar que hay 258 valores posibles. El siguiente
bloque de 8 bites 29 comprende un bitio objetivo que identifica la
UEM u otro dispositivo que es el objetivo. Normalmente, este bitio
se pone al mismo valor que el que el bitio fuente 28 de la UEM a la
que se desea enviar el mensaje. No obstante, cuando el CANBus está
dotado de múltiples UEM u otros dispositivos del mismo tipo, el
bitio objetivo de cada UEM o dispositivo se puede fijar como
parámetro no volátil, o asignarse dinámicamente al encendido del
sistema 10 o de otro modo ser una combinación de valores guardados y
asignados dinámicamente, de modo que cada UEM o dispositivo
idéntico sea identificado por un bitio objetivo diferente.
El bloque final 30 de seis bites comprende el
espacio para el mensaje y puede dedicarse, según convenga, a cada
dispositivo. Por ejemplo, en una petición de diagnóstico, se pueden
poner estos bites para identificar si el mensaje es una petición de
diagnóstico o una respuesta de diagnóstico. Si el mensaje comprende
una parte de un mensaje de varias páginas, se identifica la parte
del mensaje. O bien, si se necesita enviar un mensaje corto, por
ejemplo, un mensaje de suceso de comienzo como el ya descrito, la
información relevante se puede codificar en el bloque 30 de seis
bites. Se observará que este protocolo de dirección es apto en
cualquier sistema apropiado que se deseo, y no solamente dentro del
sistema de la figura 1.
Si el sistema informático para vehículos 10
comprende un módulo de comunicaciones que le permite acceso a
distancia al registro 12, es ventajoso dotar de acceso a distancia
al conjunto de histogramas o a los datos guardados. También, o
alternativamente, se puede disponer un módulo de salida 24,
conectado con el colector 14 de manera apropiada, en cuyo caso será
posible establecer una sesión de diagnóstico con el sistema
informático para vehículos 10 como se ve en la figura 1. Un
dispositivo del usuario 41 actúa para enviar y recibir información
del módulo de salida 24, 24', a través del conector a distancia 42.
Un servidor de datos de vehículos, marcado con 44, y provisto de un
almacén de datos 48, puede ser accesible por Internet 45 o recibir
un conjunto de histogramas u otros datos que estén guardados. El
servidor de datos de vehículos 43 puede ser accesible por Internet
45 o mediante una conexión de MODEM, indicada generalmente en 46.
Se puede pensar en un dispositivo del usuario, como el que se ve en
47, que sólo sea capaz de obtener comunicación con el conjunto de
histogramas guardado u otros datos guardados del servidor de datos
de vehículos, posiblemente por Internet 45, y no será capaz de
establecer comunicación directa con el sistema informático para
vehículos 10. También, el sistema 41 puede funcionar sólo para
transmitir una petición al sistema informático de vehículos 10, para
que transmita los datos guardados del vehículo al servidor de datos
de vehículos 43, de modo que se le suministre al servidor de datos
de vehículos 43 el conjunto de histogramas actuales guardados u
otros datos guardados.
Ventajosamente, el servidor de datos de
vehículos comprenderá un almacén de información de subscriptores, de
manera que sólo los sistemas de usuarios que comprendan o
pertenezcan a subscriptores tengan acceso al almacén de datos. Los
dispositivos del usuario 41, 47 pueden mostrar los datos de
vehículos que se desee, por ejemplo, en un sistema de diagnóstico
convencional simulado, o de otro modo. Si se establece un enlace de
comunicación de dos vías entre el dispositivo del usuario 47, el
servidor de datos de vehículos 43 y el sistema informático para
vehículos 10, se puede celebrar una sesión de diagnóstico adecuada
de manera convencional.
Dicho sistema habilita a la dirección de una
empresa de transportes para vigilar a distancia los parámetros de
su parque de vehículos sin necesidad de que los vehículos acudan a
un punto de servicio, ni tener acceso físico a los vehículos.
Claims (10)
1. Un sistema informático para vehículos (10)
que comprende una unidad de mando (11) y un registro de datos
(12); actuando la unidad de mando para guardar los datos del
vehículo relativos a un parámetro, dando los siguientes pasos:
definición de un histograma (22) recopilados en
un número de gamas (23a, 23b, 23c, 23d,
23e, 23f, 23g, 23h) unidas a un valor de
recuento;
recepción de un número de valor de datos,
correspondientes a dichos parámetros, desde un sensor (15, 16, 17);
e
identificación de una gama (23a,
23b, 23c, 23d, 23e, 23f,
23g, 23h) correspondiente a cada valor de datos, e
incrementar el valor de recuento relativo a la gama identificada
(23a, 23b, 23c, 23d, 23e,
23f, 23g, 23h);
caracterizado porque:
el sistema informático para vehículos (10)
comprende también un colector (14);
la unidad de mando (11) y un registro de datos
(12) conectados al colector (14);
la unidad de mando (11) también funciona
generando un mensaje de suceso en respuesta a un suceso, y
trasmitiendo el mensaje de suceso al registro de datos (12) por
medio del colector (14);
el registro de datos (12) actúa para recibir y
guardar datos en respuesta al mensaje de suceso; y
la unidad de mando (11) actúa transmitiendo al
valor de cuenta al registro (12) por medio del colector.
2. Un sistema informático para vehículos (10)
con arreglo a la reivindicación 1 en el que la unidad de mando (11)
actúa definiendo un conjunto de histogramas compuesto por varios
histogramas (22) correspondiente cada uno a un parámetro
seleccionado.
3. Un sistema informático para vehículos (10)
con arreglo a las reivindicaciones 1 o 2, que actúa guardando los
valores de recuento en un medio de almacenamiento no volátil
(20).
4. Un sistema informático para vehículos (10)
con arreglo a la reivindicación 3 en el que la unidad de mando (11)
tiene una memoria volátil (19) y una memoria no volátil (20).
5. Un sistema informático para vehículos (10)
con arreglo a la reivindicación 4 en el que la unidad de mando
actúa para pasar los valores de recuento desde la memoria no
volátil (20) a la memoria volátil (19), actualiza los calores de
cuenta de la memoria volátil (19) y pasa los valores de cuenta a la
memoria no volátil (20).
6. Un sistema informático para vehículos (10)
con arreglo a cualquiera de las reivindicaciones anteriores, que
comprende por lo menos un sensor (15, 16, 17) que actúa
suministrando los valores de datos correspondientes al parámetro, a
la unidad de mando (11).
7. Un sistema informático para vehículos (10)
con arreglo a cualquiera de las reivindicaciones anteriores en el
que la unidad de mando (11) actúa generando un mensaje de parada y
transmitiendo el mensaje de parada al registro de datos (12).
8. Un sistema informático para vehículos (10)
con arreglo a cualquiera de las reivindicaciones anteriores en el
que la unidad de mando (11) actúa para transmitir datos al registro
de datos por medio del colector (14).
9. Un sistema informático para vehículos (10)
con arreglo a cualquiera de las reivindicaciones anteriores en el
que el registro de datos (12) actúa al recibir un mensaje de
suceso y guardar los datos recibidos antes que el mensaje de
suceso.
10. Un sistema informático para vehículos (10)
con arreglo a cualquiera de las reivindicaciones anteriores que
comprende un módulo de salida (24, 24') que está conectado a uno de
los registros de datos y al colector.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB0206113 | 2002-03-15 | ||
| GB0206113A GB2386447B (en) | 2002-03-15 | 2002-03-15 | Vehicle data system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2294209T3 true ES2294209T3 (es) | 2008-04-01 |
Family
ID=9933025
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES03005050T Expired - Lifetime ES2294209T3 (es) | 2002-03-15 | 2003-03-06 | Sistema informatico para vehiculos. |
Country Status (5)
| Country | Link |
|---|---|
| EP (2) | EP1881459A3 (es) |
| AT (1) | ATE374411T1 (es) |
| DE (1) | DE60316490T2 (es) |
| ES (1) | ES2294209T3 (es) |
| GB (1) | GB2386447B (es) |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7894961B2 (en) | 2004-11-12 | 2011-02-22 | Caterpillar Inc | Dump cycle counting and monitoring system |
| JP4297056B2 (ja) * | 2005-01-19 | 2009-07-15 | トヨタ自動車株式会社 | 故障診断データ記録システム及び故障診断データ記録方法 |
| DE102005031666A1 (de) * | 2005-07-05 | 2007-01-11 | Endress + Hauser Wetzer Gmbh + Co Kg | Verfahren zum Betreiben einer Datenspeichereinheit für die Prozessautomatisierungstechnik |
| FR2894695B1 (fr) * | 2005-12-14 | 2008-08-22 | Renault Sas | Procede de memorisation d'informations concernant un defaut de fonctionnement d'un dispositif |
| US8032234B2 (en) | 2006-05-16 | 2011-10-04 | Rosemount Inc. | Diagnostics in process control and monitoring systems |
| EP1860557A1 (en) * | 2006-05-24 | 2007-11-28 | Robert Bosch Gmbh | Method of handling fault codes in a memory |
| FR2903774B1 (fr) * | 2006-07-17 | 2008-09-05 | Renault Sas | Procede de validation d'un diagnostic de fontionnement d'un dispositif. |
| US8229631B2 (en) | 2007-08-09 | 2012-07-24 | Caterpillar Inc. | Wheel tractor scraper production optimization |
| CN105427405A (zh) * | 2015-11-17 | 2016-03-23 | 北京奇虎科技有限公司 | 行车信息还原方法和系统、服务器还原行车信息的方法 |
| EP3619689A1 (de) | 2017-06-02 | 2020-03-11 | Audi AG | Verfahren und vorrichtung zum situationsabhängigen speichern von daten eines systems |
| SE2350756A1 (en) * | 2023-06-20 | 2024-12-21 | Scania Cv Ab | Method of Monitoring Vehicle Related Parameters, Computer Program, Computer-Readable Medium, Data Monitoring Apparatus, and Vehicle |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US452461A (en) * | 1891-05-19 | Bundle-discharger for grain-binders | ||
| US4542461A (en) * | 1982-06-14 | 1985-09-17 | Payhauler Corporation | Apparatus for acquiring dump truck duty cycle data |
| US4757454A (en) * | 1984-08-20 | 1988-07-12 | Caterpillar Mitsubishi Limited | Operation data-recording system for a machine |
| DE4441101B4 (de) * | 1994-11-18 | 2005-01-27 | Robert Bosch Gmbh | Verfahren und Vorrichtung zur Bestimmung von Diagnoseschwellwerten für einen bestimmten Kraftfahrzeugtyp im Feld |
| DE19650863C1 (de) * | 1996-12-07 | 1998-04-16 | Bosch Gmbh Robert | Verfahren und Vorrichtung zur Erkennung einer vertikalen Dejustierung eines Abstandssensors |
| US5941918A (en) * | 1997-07-30 | 1999-08-24 | Engelhard Corporation | Automotive on-board monitoring system for catalytic converter evaluation |
| JP3044025B1 (ja) * | 1998-12-09 | 2000-05-22 | 株式会社データ・テック | 運転傾向性の分析が可能な運行管理システム及びその構成装置 |
| DE10029401A1 (de) * | 2000-06-15 | 2001-12-20 | Pascal Munnix | Verfahren zum ereignisbedingten Abspeichern von Fahrzeugsystemdaten |
-
2002
- 2002-03-15 GB GB0206113A patent/GB2386447B/en not_active Expired - Fee Related
-
2003
- 2003-03-06 EP EP07117201A patent/EP1881459A3/en not_active Withdrawn
- 2003-03-06 EP EP03005050A patent/EP1345182B8/en not_active Expired - Lifetime
- 2003-03-06 AT AT03005050T patent/ATE374411T1/de not_active IP Right Cessation
- 2003-03-06 ES ES03005050T patent/ES2294209T3/es not_active Expired - Lifetime
- 2003-03-06 DE DE60316490T patent/DE60316490T2/de not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| EP1345182A3 (en) | 2003-10-22 |
| GB0206113D0 (en) | 2002-04-24 |
| EP1345182B8 (en) | 2007-11-21 |
| GB2386447A (en) | 2003-09-17 |
| DE60316490T2 (de) | 2008-06-26 |
| EP1345182B1 (en) | 2007-09-26 |
| EP1345182A2 (en) | 2003-09-17 |
| DE60316490D1 (de) | 2007-11-08 |
| ATE374411T1 (de) | 2007-10-15 |
| GB2386447B (en) | 2006-05-24 |
| EP1881459A3 (en) | 2008-04-16 |
| EP1881459A2 (en) | 2008-01-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2294209T3 (es) | Sistema informatico para vehiculos. | |
| US6782313B1 (en) | Diagnostic test device for motor vehicle with programmable control devices | |
| US5825286A (en) | Vehicular data collection and transmission system and method | |
| US8406951B2 (en) | Electronic control system for vehicles | |
| ES2964703T3 (es) | Sistema de adquisición y registro de datos en tiempo real | |
| US20070119326A1 (en) | Remote digital firing system | |
| US4803646A (en) | Electronic odometer | |
| JP2009152922A (ja) | 車両の遠隔診断システムためのデータ通信装置 | |
| EP2096879A2 (en) | Wireless data transmission of a refrigerated container unit | |
| EP1833026A3 (en) | Vehicle diagnostic system capable of easily acquiring data IDs for vehicle diagnosis | |
| BRPI0409215A (pt) | aparelho de segurança para uso com uma unidade de monitoração, sistema de segurança e método de prevenir a violação de um contêiner munido de pelo menos uma tranca | |
| JP2005070028A (ja) | 積算走行距離変造防止システム及び方法 | |
| JPS61502838A (ja) | フイ−ルド用のプリセツト可能な電子ユ−スメ−タ | |
| US20050232781A1 (en) | Permanent low cost radio frequency compressor identification | |
| KR970019727A (ko) | 제어/관리 신호 전달/수신 시스템 | |
| US20100223829A1 (en) | Self calibrating weapon shot counter | |
| US20240138853A1 (en) | Data modules for surgical instruments | |
| US6997286B1 (en) | Method in and device for the manual lubrication of a plurality of lubrication points | |
| US6374161B1 (en) | Automobile control system and method capable of revising control data transmission function | |
| IL280390B1 (en) | Fire extinguisher rolling mechanism | |
| ES2553707T3 (es) | Procedimiento para gestionar datos de herramienta | |
| PT1183657E (pt) | Dispositivo para exibição do tempo de estacionamento de um veículo | |
| US6661343B1 (en) | Adapter for motion detector | |
| ES2398127T3 (es) | Procedimiento para la emisión de un bloque de transmisión de datos y procedimiento y sistema para la transmisión de un bloque de transmisión de datos | |
| ES2302262T3 (es) | Procedimiento y dispositivo para securizar datos de ajuste individuales. |