ES2258427T3 - Red y procedimiento para el intercambio de mensajes. - Google Patents

Abstract

Procedimiento para el intercambio de mensajes en una red (10) con una multitud de unidades (12 - 30) electrónicas de mando que están unidas entre sí mediante un bus (31), e intercambian mensajes entre sí, cada uno de los cuales presenta un sector con un identificador y datos, con los siguientes pasos realizados por las unidades (12 - 30) electrónicas de mando: Recepción de un mensaje; Conversión del identificador del mensaje en un valor de dirección, efectuándose una operación aritmética; Lectura y extracción de un valor relevante, de una tabla (36) en la que están almacenados valores de relevancia para una multitud de valores indexados, sacándose de la tabla (36) el valor de relevancia del valor indexado, que corresponda al respectivo valor de dirección; Ignorancia del mensaje cuando el valor correspondiente de relevancia indique que el mensaje no es relevante para la unidad (12 - 30) electrónica afectada de mando; Continuación del procesamiento del mensaje cuando el valor correspondientede relevancia indique que el mensaje es relevante para la unidad (12 - 30) electrónica afectada de mando.

Description

Red y procedimiento para el intercambio de mensajes.

La invención se refiere a una red y a un procedimiento para el intercambio de mensajes.

Los modernos vehículos industriales o agrícolas, comprenden por lo regular una red de unidades electrónicas de mando (ECUs, Electronic Control Units), como una unidad de mando del motor, una unidad de mando de la caja de cambios, una unidad de mando de los instrumentos del tablero de instrumentos, etc. La red puede discurrir por todo el vehículo, para hacer posible disponer las distintas unidades electrónicas de mando en la proximidad del subsistema con el que interaccionan. Por la red se envían regularmente una multitud de mensajes de datos, de los que cada mensaje individual sólo puede tener significado para algunas unidades electrónicas de mando. Por ejemplo, la unidad de mando del motor puede preparar para la unidad electrónica de mando de la pantalla, una información sobre la velocidad del motor, aunque una unidad electrónica de mando, que controle el sistema de iluminación del vehículo, no tendrá ninguna necesidad de informaciones sobre la velocidad del motor. Cada unidad electrónica de mando comprende por lo regular un juego de chips electrónicos, que presenta un microprocesador (CPU, Central Processing Unit) y hardware operacional de la red (CAN, Controller Area Network).

Hay normas aplicables para protocolos de red (SAE-J1939 e ISO-11783), que reglamentan la comunicación de mensajes en una red semejante. En la norma J1939 los mensajes presentan un identificador del mensaje. Los identificadotes de mensajes son una sucesión de varios campos, incluyendo: (i) prioridad - 3 bits; (ii) números de grupos de parámetros (PGN) - 16 bits; (iii) dirección de destino (DA, Destination Address) - 8 bits; (iv) dirección de origen (SA, Source Address) - 8 bits; y (v) otros - 2 bits. Por lo tanto estos campos se combinan en un identificador del mensaje con 29 bits.

El campo de prioridad permite a los mensajes con alta prioridad (preferencia), obtener un acceso preferente a la red, antes que mensajes con inferior prioridad. El campo de números de grupos de parámetros (PGN) se utiliza para parámetros individuales, para obtener un transporte eficiente en la red. Un ejemplo es la combinación de la velocidad del motor y del par motor en un mensaje de red. Otro grupo podría comprender el conmutador de señales de cambio de dirección, y otras señales del tipo de "cortesía". A cada grupo está coordinado un número. Además, hay algunos valores de los campos de números de grupos de parámetros, en los que el objetivo es hacer posible una comunicación directa de una unidad electrónica de mando con otra. En este caso, una parte de los campos de números de grupos de parámetros, es la dirección de destino. El campo de direcciones de destino (DA) contiene el número único de destino que está asignado a cada unidad electrónica de mando (ECU) en la red. Puesto que cada unidad electrónica de mando presenta un número único, una unidad electrónica de mando puede comunicar directamente con otra unidad electrónica de mando, utilizando una zona especial de los números de grupos de parámetros, que están asignados a este fin. El campo de direcciones de origen (SA) se utiliza para el número único que está asignado a cada unidad electrónica de mando, de manera que la unidad electrónica de mando (ECU) de procedencia de cada mensaje, pueda ser identificada en la red. Los "otros" campos están reservados para objetivos futuros.

En muchos casos un mensaje tendrá bajo el protocolo J1939, números de grupos de parámetros (PGN) predefinidos que corresponden a parámetros generales como velocidad del motor, presión del aceite, conmutadores de señales de cambio de dirección, etc. Muchas unidades electrónicas nuevas de mando presentan parámetros que no están predefinidos. J1939 permite también una "proprietary messaging" [mensajería del propietario], o sea una transmisión de mensajes, definida para el propietario, en la que para determinados valores de los números de grupos de parámetros, se ha dejado a los productores la especificación de qué datos se transmiten en los respectivos PGN, y no aparecerá en la norma J1939. Cuando se crean nuevos sistemas, es habitual redactar protocolos de estos sistemas utilizando los mensajes definidos para el propietario. Cuando hace falta colocar nuevos parámetros en la red, como por ejemplo, "altura de la antena de radio", no se encontraría en el banco actual de datos de J1939, un número predefinido correspondiente de grupos de parámetros. El sistema se crearía pues con un prototipo en el que se utilicen los mensajes definidos para el propietario, para comunicar el parámetro "altura de la antena de radio". Eventualmente podría definirse un PGN para un parámetro semejante, aunque para ello es necesario un largo plazo de desarrollo de muchos meses, hasta de más de un año.

Para respaldar este protocolo hay que sustentar una gran cantidad de mensajes de red. Cada mensaje recibido por un microprocesador de una unidad electrónica de mando, tiene que poder comprobar su identificador del mensaje, para constatar si este mensaje es relevante para la respectiva unidad electrónica de mando. Para unidades electrónicas de mando que sólo tengan que manejar una pequeña cantidad de mensajes, el hardware para la red, CAN, disponible en general, tiene un filtrado incorporado que puede realizar esta prueba, de manera que aquí se acepten automáticamente mensajes entrantes que sean de interés, mientras se rechazan otros mensajes, sin intervención del microprocesador de la unidad electrónica de mando (ECU). No obstante, una unidad típica electrónica de mando en una red semejante, tiene que procesar una cantidad mayor de mensajes que las que pueden manejar los filtros incorporados en el hardware y, por tanto, la aceptación o rechazo de mensajes ha de llevarse a cabo en el software del sistema
(ECU).

En un sistema complejo nuevo pueden existir varias decenas o incluso centenas de parámetros nuevos. En un sistema semejante estos parámetros están integrados en los PGNs para "proprietary messaging". No obstante, cabría imaginar que este grupo de números de grupos de parámetros, no presente la capacidad para todos los parámetros nuevos. Por consiguiente es práctica relativamente usual, utilizar un byte de datos en el mensaje definido para el propietario, para describir mejor el objeto del mensaje específico. La utilización de un byte de datos requiere 8 bits y, por tanto, facilita 256 combinaciones adicionales únicas que permiten una asociación de cualesquiera parámetros con los correspondientes números de grupos de parámetros.

Cuando la función de aceptación y rechazo de mensajes es realizada por el software del sistema, se aumenta esencialmente la carga de la CPU, posiblemente tanto que existe el peligro de que no se realicen correctamente actividades de inferior prioridad, que no están en relación con la red. Para resolver este problema pueden ser necesarias CPUs esencialmente de mayor capacidad, u otro hardware electrónico adicional. Cada una de estas exigencias aumentaría significativamente los costes del sistema.

Los identificadores de mensajes tienen 29 bits de longitud, y en algunos casos de identificadores de mensajes, puede necesitarse la prueba de uno o barios bytes de datos, para constatar la relevancia del mensaje para una unidad electrónica dada de mando. No es practicable una utilización del método convencional de tablas de consulta, puesto que la tabla puede exigir más de 2^{29} entradas, y cuando adicionalmente es necesario un byte de datos para comprobar la relevancia de un mensaje dado, serían necesarias 2^{37} entradas. Además, identificadores de mensajes relevantes para cada una de las unidades electrónicas de mando, no caben en un espacio de direccionamiento con suficiente frecuencia de repetición, de manera que pudiera utilizarse una fórmula matemática eficiente.

Hay que partir de que las redes típicas de producción actual, aplican un procedimiento con dos pasos, detectándose y descargándose primeramente los mensajes en un proceso de alta prioridad, y a continuación se procesan los mensajes en un proceso con prioridad inferior. La realización de este procedimiento requiere mucho tiempo cuando muchos mensajes no tienen en el sistema relevancia ninguna para una unidad electrónica específica de mando, o para un nudo. Por ejemplo, una rutina del servicio de interrupción (ISR, interrupt service routine) que responde un mensaje nuevo, coloca el mensaje en cola para su comprobación posterior. Cuando el mensaje no sea relevante, se derrocha este tiempo de procesamiento. Los procedimientos convencionales para constatar la relevancia de un mensaje, exigen demasiado tiempo en la rutina del servicio de interrupción. Otro ejemplo de tiempo derrochado de procesamiento es un proceso de inferior prioridad que periódicamente aparta mensajes de la cola y los compara con la lista de los mensajes deseados, partiendo de que los mensajes sean o no relevantes.

En detalle el procedimiento típico para el procesamiento de un mensaje de red, CAN, es como sigue:

Un mensaje de red llega al subsistema CAN de la unidad electrónica de mando. De esta manera la CPU es avisada mediante una interrupción. Se interrumpe el procesamiento normal de datos, y se hace cargo la rutina del servicio de interrupción (ISR) para sacar el mensaje del subsistema CAN, y lo pone en una cola para ulterior procesamiento. Este software está estructurado frecuentemente demasiado riguroso, para minimizar los efectos sobre otras actividades del sistema, y no puede reconocerse cómo hay que filtrar los mensajes en esta rutina del servicio de interrupción (ISR), sin añadir recursos extensivos al sistema. La CPU recupera de nuevo el control de del proceso antes activo. En un momento más favorable, la CPU comprueba la cola, si existen cualesquiera mensajes. Cuando existen uno o varios mensajes, se comprueban individualmente para constatar su relevancia para esta unidad electrónica de mando en la red. Esta comprobación se realiza por lo regular de tal manera que se compara el identificador único de este mensaje, con una lista de identificadores conocidos, que representan los mensajes relevantes. Cuando el mensaje nuevo se ajusta a un mensaje de interés, este mensaje es procesado por el sistema. Cuando el mensaje nuevo no se ajusta, después de que el identificador del mensaje se hubiera comparado exhaustivamente con todos los identificadores relevantes conocidos, se rechazará este mensaje. Este proceso se repite hasta que se haya alcanzado un cierto límite. Este límite puede ser una cola vacía, un intervalo de tiempo, o un número de mensajes. La CPU realiza otras tareas, y repite este procedimiento en un momento futuro determinado.

En un sistema semejante, la rutina del servicio de interrupción (ISR) realiza una cantidad fija de trabajo, que exige unos 60 microsegundos de tiempo de la CPU. El procesador de mensajes rastrea la lista de mensajes evaluados, lo que exige unos 100 microsegundos de tiempo de la CPU, para batir exhaustivamente la lista. A causa de la gran gama de valores para los identificadores de mensajes, no hay ninguna optimización de rápida identificación, que pudiera acelerar la búsqueda, de manera que es por lo regular una búsqueda lineal. Cuando se aumenta la longitud de la lista, crece proporcionalmente el tiempo para el examen de la lista. Cuando se encuentra un mensaje en la lista, entonces se decodifica el mensaje. Una unidad electrónica típica de mando podría encontrar menos del 20% de los mensajes relevantes por sí mismos. Para cada mensaje sin relevancia, la CPU utiliza unos 160 microsegundos.

El documento DE 41 10 372 A describe un sistema multiplexor de transmisión para vehículos, en el que están unidas unas con otras, una multitud de redes mediante un nudo de red. En los aparatos de mando conectados a la red, se intercambian datos mediante la red, reconociéndose en forma no explicada en detalle, de la mano de la información de la identidad de los mensajes individuales, a qué aparato de mando está dirigido un mensaje.

El documento EP 0 581 033 A describe otro sistema de transmisión de datos. De los datos transmitidos por una línea de la red, a una unidad de mando, se extraen los códigos de identidad, y se comparan con cada uno de códigos predeterminados. Desde luego aquí es posible un reconocimiento rápido de los datos coordinados a la unidad de mando, aunque con alto gasto de hardware, y con la problemática de que sólo pueden agregarse problemáticamente otros códigos.

La misión que sirve de base a la invención consiste en facilitar un método más rápido para el procesamiento y comprobación de la relevancia de mensajes de red, que puede utilizarse con CPUs baratas, que rechaza los mensajes sin relevancia, y que trabaja también en condiciones de gran carga de la red con mensajes.

Esta misión se resuelve según la invención mediante la teoría de la reivindicación 1, exponiéndose en las demás reivindicaciones, notas características que perfeccionan la solución en forma ventajosa.

Se realiza una operación matemática rápida con el respectivo identificador (único) del mensaje que se mande por la red. Esta operación devuelve un pequeño valor de dirección, que sirve para consultar en una tabla de consulta, relativamente pequeña, con valores indexados, y que contiene un valor relevante para cada valor indexado. La tabla devuelve un 1 (o un valor no nulo) para valores indexados que correspondan a mensajes relevantes, y un cero para mensajes irrelevantes. Se aceptan los mensajes relevantes y se continúan procesando. Lo último se hace preferentemente colocándolos primeramente en una cola de valores, en una memoria tampón RAM [de acceso aleatorio]. Se rechazan mensajes irrelevantes (es decir se ignoran o se borran). Esta implementación es eficiente y suficientemente rápida para realizarse como parte de una rutina del servicio de interrupción. Como operación matemática se toma en consideración en especial, una operación de restos de una división, a pesar de que también podrían utilizarse cualesquiera otras operaciones, por ejemplo, las que se utilizan para el cálculo de dígitos de comprobación (por ejemplo, para números de cuentas).

Una elección cuidadosa de la función aritmética y del tamaño de la tabla, facilita un sistema que no exige ningún hardware adicional para filtrar los mensajes. Cuando el mensaje no es relevante, no se le pone en la cola, y se termina la rutina del servicio de interrupción, lo cual ahorra un tiempo considerable en la misma rutina del servicio de interrupción. Tan sólo los mensajes que pasen el "filtrado" en la rutina del servicio de interrupción, son almacenados en la cola y, eventualmente, se comparan con una lista de mensajes (relevantes) deseados. Cuando el mensaje haya sido rechazado por la rutina del servicio de interrupción, en este segundo paso del procedimiento no se necesita tiempo ninguno para este mensaje. En comparación con una rutina típica de búsqueda, lineal o binaria, que podría utilizarse en el segundo paso del procedimiento, este procedimiento ahorra una cantidad considerable de tiempo de CPU, que puede utilizarse para otros fines de procesamiento.

La red según la invención puede emplearse en especial en vehículos agrícolas.

En los dibujos está representado un ejemplo de realización de la invención, descrito en detalle a continuación. Se muestran:

Figura 1 Un diagrama esquemático simplificado de bloques, de una red de un vehículo, con una multitud de unidades electrónicas de mando (ECUs).

Figura 2 Un diagrama esquemático en el que se muestra una recepción de mensajes según la presente invención.

Figura 3 Un diagrama lógico de flujo, en el que está representado un sector de recepción de mensajes o de filtros, según la invención; y

Figura 4 Un diagrama lógico de flujo, en el que está representado un sector de procesamiento de mensajes, según la presente invención.

En la figura 1 está representada una red CAN (10) de un vehículo, que comprende una multitud de unidades 12 - 30 electrónicas de mando (ECUs) (se muestran diez, aunque puede utilizarse la presente invención con más o menos ECUs), que están unidas entre sí mediante un bus 31 de CAN.

En la figura 2 el bus 31 transmite el tráfico de mensajes que se compone, por ejemplo, -con relación a una ECU específica- de mensajes relevantes M12, M27 y M89 (sombreados) y de mensajes irrelevantes M73, M43, M15, M96, M87, M78 y M10 (no sombreados). Cada mensaje comprende un sector del identificador y un sector de datos. Puesto que estos mensajes de red se envían periódicamente por otras ECUs, y se reciben por una ECU, se procesan como sigue: Una interfaz 32 de hardware de la red en la ECU, recibe un mensaje, e inicia una rutina 34 del servicio de interrupción (ISR) que interrumpe cualquier otro procesamiento de datos por el software.

La rutina 34 del servicio de interrupción es de naturaleza extremadamente crítica, puesto que interrumpe en la ECU toda actividad de prioridad inferior. Según la presente invención, un algoritmo filtrante de aceptación, calcula un valor de dirección, a partir de una clave de direcciones, es decir, de una sección del identificador del mensaje con 29 bits. El cálculo del valor de dirección se describe mediante el siguiente código ficticio:

Desenmascare la prioridad y los "otros" bits reservados, del identificador.

Desenmascare la dirección de origen (SA).

Cuando sea un mensaje definido para el propietario según J1939, se combinará automáticamente el valor 1 del byte en el lugar de la dirección de origen.

Luego se realiza la función de cálculo de la dirección.

8

El valor de dirección (en el caso del ejemplo, un resto de la división respecto a un número (primo), o sea, el valor de un módulo) se compara con un juego correspondiente de valores indexados de una tabla de direcciones, o de una tabla 36 de consulta, presentando cada valor indexado un valor REL correspondiente de relevancia, que es 0 en caso de que no sea relevante, y 1, en caso de que sea relevante. De preferencia el valor de dirección puede llegar de 0 a N, siendo N preferentemente un número primo que representa el número de valores indexados en la tabla de consulta. Una función creada apropiadamente para el cálculo de direcciones, y una tabla de consultas con un valor apropiado para N, reduce el número de mensajes irrelevantes casi a cero. Mensajes que pasen la prueba (con un valor REL de 1) se desplazan a una memoria 38 tampón RAM, que por lo regular está configurada como tampón de primera entrada primera salida (FIFO). Mensajes sin relevancia (valor REL de 0) son ignorados o eliminados por la respectiva ECU que realiza este procedimiento.

En un momento más apropiado y esencialmente menos crítico, una rutina 40 del servicio de procesamiento de mensajes, procesará los mensajes en la memoria 38 tampón, tomando en primer lugar el mensaje más antiguo. La memoria 38 tampón contendrá muchos menos mensajes para el procesamiento adicional. La rutina 40 del servicio de procesamiento de mensajes, compara los identificadores (M12, M27, etc.) de mensajes con una lista 42 almacenada de mensajes evaluados. Cuando el nuevo mensaje aparece en la lista 42, proseguirá la rutina 40 con la decodificación, y en 44 extrae los datos del mensaje. Cuando la rutina 40 constata que en la lista 42 no aparece el mensaje nuevo, ignorará el mensaje. Luego la rutina 40, o bien puede terminar, o bien puede empezar de nuevo, considerando el mensaje siguiente en la memoria 38 tampón.

En este procedimiento, la rutina del servicio de interrupción (ISR) realiza una cantidad variable de trabajo, que exige unos 60 microsegundos de tiempo de la CPU, cuando se acepta el mensaje, pero tan sólo de 25 a 30 microsegundos de tiempo de la CPU, cuando se rechaza el mensaje. La rutina 40 del servicio de procesamiento de mensajes, rastrea la lista 42 de mensajes evaluados, lo cual exige aproximadamente 100 microsegundos de tiempo de la CPU, para examinar exhaustivamente la lista 42. Los mensajes procesados son principalmente mensajes con valor para este nudo. Una elección adecuada del filtro del cálculo de direcciones, reducirá los mensajes sin interés casi a cero. Cuando se aumente la longitud de la lista 42, se aumentará el tiempo para examinar la lista.

Cuando se encuentra un mensaje en la lista 42, a continuación se decodifica el mensaje. En un sistema típico aproximadamente un 80% de los mensajes, no será relevante para una unidad electrónica concreta de mando, y un gran porcentaje de ellos será rechazado por la rutina 34 del servicio de interrupción (ISR), de manera que se ahorre una cantidad considerable de tiempo de procesamiento de la CPU, que entonces puede utilizarse para la realización de otras funciones.

Con referencia a la figura 2 y en especial, a la tabla 36 de direcciones, hay que hacer notar que la tabla 36 de direcciones permite poder procesar mediante el sistema todos los identificadores de interés, mientras que se rechazan casi todos los identificadores que no sean de interés. Como resultado de la invención, la capacidad de rendimiento global está dominada por la calidad de la tabla utilizada de direcciones. Una tabla muy grande de direcciones, que esté compuesta de 2^{29} entradas, permitirá un rechazo de todos los identificadores no relevantes para una CPU dada. Puesto que, no obstante, una memoria de tal magnitud no es económica, una tabla de direcciones más asequible, podría presentar un tamaño de 256 a 2048 entradas.

Cuando el tamaño de la tabla de direcciones se reduce (menor de 2^{29} entradas), un cierto porcentaje de los identificadores se conducirá para una función dada de cálculo de direcciones, al cálculo del propio valor de dirección. Mensajes con esta característica tienen el mismo valor de relevancia, y cuando cualquiera de estos mensajes es relevante, se identificarán, por tanto, todos como relevantes por la rutina del servicio de interrupción. A pesar de ello, los verdaderamente no relevantes se procesan, y son rechazados por la rutina 40 de procesamiento de mensajes, cuando no se encuentra en la lista 42 ningún identificador ajustado. Por consiguiente, la elección de una tabla de direcciones, apropiadamente dimensionada, y de una transformación aritmética apropiada (en este ejemplo: elección del divisor para el resto de la división) tendrá como resultado un sistema que mantenga todos los mensajes de interés, y rechace un porcentaje muy alto de mensajes sin interés. El divisor para el resto de la división puede comprobarse empíricamente en este ejemplo, mediante un proceso iterativo que aplique una operación de restos de división (operación del módulo) a los identificadores, produciendo la operación de restos de la división, valores indexados para la tabla de direcciones. Por ejemplo, un divisor de restos de división, de 251, producirá una tabla de direcciones con 251 valores indexados únicos.

La producción de una buena tabla de direcciones y de buenos divisores de restos de división, exige un análisis de la cantidad de mensajes que existen en el sistema. Es importante reconocer que para un intervalo dado de tiempo (un intervalo de prueba), existen en la red, I mensajes que son relevantes para la unidad electrónica elegida de mando (ECU), y que T será el número total de mensajes en la red. Existirá una cantidad de mensajes -J- que procesa la unidad electrónica de mando, pero que no son relevantes. Utilizando estas cantidades de mensajes, es posible iterar mediante distintos candidatos del divisor de los restos de la división, para comprobar la calidad del candidato a la solución. Una buena solución producirá la menor cantidad para J. Una prueba durante 60 segundos es en general un buen intervalo de prueba durante el cual puede calcularse esta información.

Una tabla apropiada de direcciones, puede generarse de la forma siguiente:

a.

Haga una lista de todos los mensajes que haya de recibir la unidad electrónica elegida de mando.

b.

Para cada mensaje haga una lista del identificador y de la tasa normal de repetición de este mensaje.

c.

Calcule la cantidad de apariciones de este mensaje durante un tiempo de prueba (60 segundos). Cuando el mensaje no se envíe normalmente, el resultado puede reducirse a cero. Cuando es este el caso, ponga la cantidad de apariciones en 1. Esta lista representa la cantidad de mensajes, que se identifica con X.

d.

Deduzca otra lista de todos los mensajes que queden que no tenga que recibir la unidad electrónica elegida de mando. Calcule de nuevo la cantidad de apariciones como de ha descrito más arriba. Esta lista representa la cantidad de mensajes identificados como Y.

e.

Deduzca la cantidad Z de mensajes, mediante la combinación de las cantidades X e Y. (Esta es la cantidad de todos los mensajes, que podría aparecer en la red en el tiempo de prueba).

El cálculo iterativo procede como sigue:

a.

Para cada candidato del divisor para el resto de la división

b.

Produzca una tabla de direcciones con un tamaño que corresponda al divisor para restos de la división, e inicialice todas las entradas al valor 0.

c.

Calcule el valor de la dirección para cada identificador en la cantidad X. Señale esta entrada en la tabla con un 1, para indicar que se reciba todo identificador que tenga en el resultado este valor de dirección.

d.

Cuando se hubieran procesado todos los mensajes en la cantidad X, se ha compuesto completamente la tabla de direcciones.

Para evaluar la calidad de esta tabla, procese las cantidades X y Z del modo siguiente:

a.

Inicialice un contador para los mensajes de interés, de cero - I.

b.

Inicialice un contador para los mensajes que pasen el filtro de restos de la división, pero que no se deseen, de cero - J.

c.

Inicialice un contador para todos los mensajes en la red, de cero - T.

d.

Para cada identificador en la cantidad X,

agregue la aparición en I,

agregue la aparición en T.

e.

Para cada identificador en la cantidad Y,

calcule el resto de la división (= valor de dirección), vea según el valor de relevancia, y

cuando el valor de relevancia no sea cero (el mensaje pasa el filtro), agregue la aparición en J,

agregue la aparición en T.

I + J reproduce ahora la cantidad total de los mensajes recibidos, y J/(I + J) reproduce como porcentaje, la cantidad de "ruido" en la red ¾ trabajo innecesario como resultado de los mensajes que pasan el filtro.

Esto puede expresarse también como porcentaje de la totalidad de los mensajes, como J/T.

Repita este proceso para los siguientes candidatos como divisor para el resto de la división, y después de que se hubiera realizado el proceso para todos los divisores propuestos para el resto de la división, elija el divisor para el resto de la división y, por tanto, la tabla de direcciones que rechace el mayor número de mensajes no relevantes.

Remítase a la figura 3 en la que la rutina del servicio de interrupción (ISR) comienza en el paso 100. El paso 102 constata si existen o no cualesquiera mensajes a procesar. Cuando no, se abandona la rutina en el paso 104, Cuando sí, el paso 106 calcula un valor del resto de la división, como valor de dirección. En el paso 108 se compara el valor del resto de la división, con el valor indexado en la tabla 36 de consulta. Cuando la tabla 36 de consulta indica que el mensaje no es relevante, el paso 116 inicializa para la recepción de un mensaje nuevo, y la rutina regresa al paso 102.

Cuando la tabla 36 de consulta indica que el mensaje es relevante, el paso 110 saca el mensaje del bus 31, y el paso 112 pone el mensaje en una cola (en la memoria 38 tampón), y actualiza la cola. Luego el paso 114 inicializa para la recepción de un mensaje nuevo, y la rutina regresa al paso 102.

Remítase a la figura 4 en la que la rutina 40 de procesamiento de mensajes comienza en el paso 200. El paso 202 constata si existen o no cualesquiera mensajes para procesar. Cuando no, se abandona la rutina en 204. Cuando sí, el paso 206 saca el mensaje de la cola (en la memoria 38 tampón). En el paso 208 se pone un valor indexado de la lista, de tal manera que represente el primer valor en la lista 42 almacenada de identificadores. Cuando después en el paso 210, el identificador del mensaje sacado de la cola, se ajusta al primer valor en la lista 42 almacenada, se procesa normalmente el mensaje en el paso 212. Cuando el identificador del mensaje sacado de la cola, no se ajusta al primer valor en la lista 42 almacenada, el paso 214 eleva el valor indexado de la lista, de manera que represente el valor siguiente en la lista 42. Cuando después el valor indexado de la lista exceda del último registro en la lista 42, el paso 216 retorna la rutina al paso 202. En otro caso, el paso 216 retorna la rutina al paso 210, para constatar si el identificador del mensaje extraído se ajusta al valor siguiente en la lista 42 almacenada.

La rutina 34 del servicio de interrupción es la rutina crítica en el tiempo, y lleva a cabo de preferencia los menos procesamientos posibles. Cuando la rutina 34 del servicio de interrupción coloca un mensaje en la cola, la rutina 40 de procesamiento de mensajes, procesará después los mensajes en esta cola.

Lo que sigue es el código fuente del programa (código ficticio) para las rutinas de las figuras 3 y 4.

1

2

3

Una parte de la publicación presente contiene material que es objeto de una reivindicación a la protección de la propiedad intelectual. El titular de la propiedad intelectual no tiene inconvenientes contra copias por terceros, de este documento de la oficina de patentes, pero se reserva todos los demás derechos.

Claims (7)

1. Procedimiento para el intercambio de mensajes en una red (10) con una multitud de unidades (12 - 30) electrónicas de mando que están unidas entre sí mediante un bus (31), e intercambian mensajes entre sí, cada uno de los cuales presenta un sector con un identificador y datos, con los siguientes pasos realizados por las unidades (12 - 30) electrónicas de mando:

Recepción de un mensaje;

Conversión del identificador del mensaje en un valor de dirección, efectuándose una operación aritmética;

Lectura y extracción de un valor relevante, de una tabla (36) en la que están almacenados valores de relevancia para una multitud de valores indexados, sacándose de la tabla (36) el valor de relevancia del valor indexado, que corresponda al respectivo valor de dirección;

Ignorancia del mensaje cuando el valor correspondiente de relevancia indique que el mensaje no es relevante para la unidad (12 - 30) electrónica afectada de mando;

Continuación del procesamiento del mensaje cuando el valor correspondiente de relevancia indique que el mensaje es relevante para la unidad (12 - 30) electrónica afectada de mando.

2. Procedimiento según la reivindicación 1, almacenándose el mensaje en una memoria (38) tampón, cuando el correspondiente valor de relevancia indica que el mensaje es relevante para la unidad (12 - 30) electrónica afectada de mando, y por lo regular se continúa procesando más tarde.

3. Procedimiento según la reivindicación 1, continuándose procesando solamente mensajes procedentes de la memoria (38) tampón.

4. Procedimiento según alguna de las reivindicaciones 1 a 3, presentando el valor de dirección menos bits de datos que el identificador del mensaje.

5. Procedimiento según alguna de las reivindicaciones precedentes, coincidiendo una cantidad de valores únicos de dirección con una cantidad de valores indexados.

6. Red (10) que está diseñada para la realización de un procedimiento según alguna de las reivindicaciones 1 a 5.

7. Vehículo agrícola con una red según la reivindicación 6.