ES2243765T3 - Procedimiento para el arbitraje de un acceso a un bus de datos. - Google Patents
Procedimiento para el arbitraje de un acceso a un bus de datos.Info
- Publication number
- ES2243765T3 ES2243765T3 ES02774357T ES02774357T ES2243765T3 ES 2243765 T3 ES2243765 T3 ES 2243765T3 ES 02774357 T ES02774357 T ES 02774357T ES 02774357 T ES02774357 T ES 02774357T ES 2243765 T3 ES2243765 T3 ES 2243765T3
- Authority
- ES
- Spain
- Prior art keywords
- user
- ring
- bus
- priority
- arbitration
- 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
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/14—Handling requests for interconnection or transfer
- G06F13/36—Handling requests for interconnection or transfer for access to common bus or bus system
- G06F13/368—Handling requests for interconnection or transfer for access to common bus or bus system with decentralised access control
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Bus Control (AREA)
Abstract
Procedimiento para el arbitraje de un acceso a un bus de datos entre usuarios (Tn1, Tn2, ...), en el que los usuarios están acoplados a través de al menos un anillo de arbitraje (12; 38, 40, 42, 44, 46, 48), con las siguientes etapas: a) solicitud del acceso de uno primero de los usuarios, b) verificación para determinar si una primera señal, para la indicación de que está liberado uno de los anillos de arbitraje, se encuentra en una entrada (16) del primer usuario, c) emisión (18) de una segunda señal a través del primer usuario, cuando está presente la primera señal, d) verificación para determinar si la primera señal se encuentra todavía en la entrada del primer usuario al final de un intervalo de tiempo predeterminado e) acceso del primer usuario cuando la primera señal está presente todavía al final del intervalo de tiempo predeterminado, caracterizado porque los usuarios están acoplados a través de un número de anillos de arbitraje (12, 38, 40, 42, 44, 46, 48), y a cada anillo de arbitraje está asociada una prioridad.
Description
Procedimiento para el arbitraje de un acceso a un
bus de datos.
La invención se refiere a un procedimiento para
el arbitraje de un acceso a un bus de datos, en el que los usuarios
están acoplados a través de al menos un anillo de arbitraje, así
como a un usuario correspondiente y a un sistema de
comunicación.
Por un sistema de comunicación sincronizado,
controlado por pulso de reloj con propiedades de equidistancia se
entiende un sistema constituido por al menos dos usuarios, que están
conectados entre sí a través de una red de datos con objeto del
intercambio mutuo de datos o bien de la transmisión mutua de datos.
En este caso, el intercambio de datos se lleva a cabo de forma
cíclica en ciclos de comunicación equidistantes, que son
predeterminados a través del pulso de reloj de la comunicación
utilizado por el sistema. Los usuarios son, por ejemplo, aparatos
centrales de automatización, aparatos de programación, aparatos de
proyección o aparatos de mando, como por ejemplo grupos
estructurales de entrada y salida, accionamientos, actuadores,
sensores, controles programables con memoria (SPS) u otras unidades
de control, ordenadores, o máquinas, que intercambian datos
electrónicos con otras máquinas, especialmente que procesan datos de
otras máquinas. Los usuarios son designados también como nodos de la
red o nodos. Por unidades de control se entienden a continuación
unidades de regulación o unidades de control de cualquier tipo, pero
también conmutadores y/o controladores de conmutador. Como redes de
datos se utilizan, por ejemplo, sistemas de bus, como por ejemplo
bus de campo, Profibus, Ethernet, Ethernet Industrial, FireWire o
también sistemas de bus internos de PC (PCI), etc., pero
especialmente también Ethernet isocrona en tiempo real.
Las redes de datos posibilitan la comunicación
entre varios usuarios a través de la conexión en red, es decir, la
comunicación de los usuarios individuales entre sí. La comunicación
significa en este caso la transmisión de datos entre los usuarios.
Los datos a transmitir son enviados en este caso como telegramas de
datos, es decir, que los datos son empaquetados en varios paquetes y
son emitidos en esta forma a través de la red de datos al receptor
correspondiente. Por lo tanto, se habla también de paquetes de
datos. El concepto de transmisión de datos se utiliza en este caso
en este documento de una manera totalmente sinónima a la transmisión
mencionada anteriormente de telegramas de datos o paquetes de
datos.
En los sistemas de automatización distribuidos,
por ejemplo en el campo de la técnica de accionamiento, determinados
datos deben entrar en instantes determinados en los usuarios
destinados para ello y deben ser procesados por los receptores. En
este caso se habla de datos críticos en tiempo real o bien de
tráfico de datos, puesto que una entrada de datos no en tiempo real
en el lugar de destino conduce a resultados no deseados en el
usuario, en oposición a la comunicación de datos no críticos en
tiempo real, por ejemplo basada en Internet o bien en Intranet.
Según el documento IEC 61491, EN61491 SERCOS Interface - Descripción
Técnica abreviada
(http://www.sercos.de/deutsch/index_deutsch.
htm) se puede garantizar un tráfico de datos crítico en tiempo real con éxito del tipo mencionado en sistemas de automatización distribuidos.
htm) se puede garantizar un tráfico de datos crítico en tiempo real con éxito del tipo mencionado en sistemas de automatización distribuidos.
Los componentes de automatización (por ejemplo,
controles, accionamientos,...) disponen actualmente, en general, de
una interfaz con un sistema de comunicación sincronizado
cíclicamente. Un plano de salida del componente de automatización
(fast-cycle) (por ejemplo, regulación de los
cojinetes en un control, regulación del par motor de un
accionamiento) está sincronizado al ciclo de la comunicación. De
esta manera se establece un pulso de reloj de la comunicación. Otros
algoritmos de bajo rendimiento (Slow-cycle) (por
ejemplo, regulaciones de la temperatura) del componente de
automatización sólo se pueden comunicar igualmente a través de este
pulso de reloj de la comunicación con otros componentes (por
ejemplo, conmutadores binarios para ventiladores, bombas,...),
aunque sería suficiente un ciclo más lento. A través de la
utilización de un solo pulso de reloj de la comunicación para la
transmisión de todas las informaciones en el sistema se plantean
altos requerimientos a la anchura de banda del trayecto de la
transmisión.
A partir del estado de la técnica se conocen
diferentes procedimientos de arbitraje centralizados y
descentralizados para el acceso a un bus de datos. En el
procedimiento de arbitraje centralizado, un árbitro decide qué
usuario del bus, que ha formulado una solicitud de acceso, obtiene
acceso al bus. Un ejemplo de un procedimiento de arbitraje
centralizado es el algoritmo Round-Robin.
En los procedimientos de arbitraje
descentralizados, el arbitraje del bus se lleva a cabo de forma
descentralizada en cada usuario del bus. Un ejemplo de un
procedimiento de este tipo es el algoritmo
Daisy-Chain.
El documento
US-A-4 730 268 muestra un
procedimiento de arbitraje descentralizado, en el que los usuarios
del bus están acoplados a través de un anillo de arbitraje.
La invención se basa en el cometido de crear un
procedimiento de arbitraje mejorado así como un usuario mejorado y
un sistema de comunicación.
Los cometidos en los que se basa la invención son
solucionados en cada caso con las características de las
reivindicaciones de patente independientes respectivas. Las formas
de realización preferidas de la invención se indican en las
reivindicaciones de patente independientes.
La invención posibilita la creación de un sistema
de comunicación, en el que el número de los anillos de arbitraje es
independiente del número de los usuarios del bus. El procedimiento
de arbitraje correspondiente funciona, por lo tanto, de una manera
independiente del número de los usuarios y, por lo tanto, en
principio se puede escalar de forma discrecional. En este caso, se
puede garantizar un tiempo de retraso máximo para el acceso al bus,
el llamado tiempo de latencia.
De acuerdo con una forma de realización preferida
de la invención, se soportan solicitudes de acceso de diferentes
prioridades, estando previsto un anillo de arbitraje separado para
cada una de las prioridades posibles.
De acuerdo con otra forma de realización
preferida de la invención
- -
- a cada usuario del bus está asociado una unidad de arbitraje,
- -
- cada unidad de arbitraje de un usuario del bus puede soportar, por ejemplo, dos prioridades LP y HP, donde LP identifica la prioridad baja y HP identifica la prioridad alta.
De acuerdo con otra forma de realización
preferida de la invención, las unidades de arbitraje de los usuarios
del bus, en el caso de soporte de dos prioridades, se interconectan
con un anillo de baja prioridad y con un anillo de alta prioridad.
En este caso, es ventajoso que la unidad de arbitraje de un usuario
del bus puede interrumpir el anillo de baja prioridad, para que no
se produzca ningún reacoplamiento de combinación. Este usuario del
bus es el maestro de anillo de baja prioridad.
De acuerdo con otra forma de realización
preferida de la invención
- -
- el maestro de anillo de baja prioridad es siempre el maestro de bus actual, que puede realizar accesos de escritura y de lectura a través del bus,
- -
- cada usuario del bus se puede convertir en el maestro de anillo de baja prioridad y, por lo tanto, en el maestro del bus,
- -
- un maestro del bus se puede convertir en el nuevo maestro del bus de baja prioridad,
- -
- cuando en este usuario del bus está activada la solicitud de bus de baja prioridad, y
- -
- el maestro de bus actual está preparado para ceder su derecho de acceso al bus y
- -
- no está presente ninguna otra solicitud de bus de baja prioridad de un usuario del bus entre el maestro de anillo antiguo y el maestro de anillo nuevo de baja prioridad,
- -
- debe interrumpir siempre la unidad de arbitraje de un usuario del bus el anillo de alta prioridad, para que no se produzca un reacoplamiento de combinación. Este usuario del bus es el maestro del bus de alta prioridad,
- -
- cada usuario del bus se puede convertir en el maestro de anillo de alta prioridad,
- -
- un usuario del bus, que realiza como maestro del bus acceso de escritura y de lectura de alta prioridad, debe ser tanto maestro de anillo de baja prioridad como también maestro de anillo de alta prioridad,
- -
- un usuario del bus, que realiza como maestro del bus acceso de escritura y de lectura de baja prioridad, debe ser el maestro de anillo de baja prioridad,
- -
- un maestro de anillo de alta prioridad está preparado para el cambio de maestro en el anillo de alta prioridad, cuando
- -
- no está presente una solicitud del bus de alta prioridad en este usuario del bus, o
- -
- existe una solicitud del bus de alta prioridad y este usuario del bus es ya maestro de bus.
Si se cumple una de las dos condiciones
mencionadas anteriormente, en la salida de la unidad de arbitraje
del maestro de anillo de alta prioridad, el nivel de la señal para
"anillo HP liberado" partirá del anillo de alta prioridad.
Si el maestro de anillo de alta prioridad recibe
el nivel de la señal "Anillo HP liberado", que ha colocado en
la salida de su unidad de arbitraje en el anillo de alta prioridad,
de nuevo en la entrada de su unidad de arbitraje, entonces ningún
otro usuario del bus ha formulado una solicitud del bus de alta
prioridad. En este caso, no se produce ningún cambio de maestro en
el anillo de alta prioridad.
No se cumple ninguna de las dos condiciones,
cuando el maestro de anillo de alta prioridad no es el maestro del
bus a pesar de una solicitud del bus de alta prioridad activada. En
este caso, en la salida de la unidad de arbitraje del maestro de
anillo de alta prioridad se emite el nivel de la señal para
"anillo HP ocupado" en el anillo de alta prioridad.
De acuerdo con otra forma de realización
preferida de la invención
- -
- un maestro de bus se convierte en nuevo maestro de anillo de alta prioridad a partir del pulso de reloj del bus siguiente, cuando se cumplen las siguientes condiciones:
- -
- la solicitud del bus de alta prioridad debe estar activada,
- -
- en la entrada de su unidad de arbitraje, debe estar presente el nivel de la señal para "anillo HP liberado".
Para que en el pulso del reloj del bus actual no
se cumplan estas condiciones también en otros usuarios del bus y
solamente pueda existir un maestro de anillo de alta prioridad, este
usuario del bus emite en la salida de su unidad de arbitraje el
nivel de la señal para "anillo HP ocupado" en el anillo de alta
prioridad. Este nivel de la señal se mantiene activado hasta que el
nuevo maestro de anillo de alta prioridad esté preparado para el
cambio de maestro en el anillo de alta prioridad y conmuta al nivel
de la señal para "anillo HP liberado" en el anillo de alta
prioridad.
Si después de la inicialización del sistema de
bus, un usuario del bus está preajustado como maestro del bus y como
maestro de anillo de alta prioridad, entonces se puede establecer en
cada unidad de arbitraje el tiempo máximo de acceso al bus.
Está preajustado un pulso de reloj del bus. Un
maestro del bus puede ceder el derecho de acceso al bus en cualquier
momento antes de la expiración del tiempo de acceso máximo. Si otro
usuario del bus ha formulado una solicitud de bus (de alta o baja
prioridad), entonces la unidad de arbitraje del maestro del bus
actual cede el derecho de acceso al bus lo más tarde después de la
expiración del tiempo de acceso máximo. Si el tiempo de acceso
máximo ha expirado, entonces se lleva a cabo este cambio de maestro
también cuando en el maestro del bus actual está colocada todavía la
solicitud del bus. Mientras ningún otro usuario del bus formula una
solicitud del bus (de baja o alta prioridad), el maestro del bus
actual mantiene el derecho de acceso al bus también después de la
expiración del tiempo de acceso máximo.
De acuerdo con otra forma de realización
preferida de la invención, en cada unidad de arbitraje se puede
establecer un tiempo de pausa, que debe expirar, antes de que un
maestro del bus pueda ser de nuevo maestro del bus después de la
cesión de su derecho de acceso al bus. Está preajustado un pulso de
reloj del bus. Este tiempo de pausa se mantiene también cuando el
usuario del bus ha formulado una solicitud del bus de baja prioridad
o de alta prioridad a su unidad de arbitraje.
De acuerdo con otra forma de realización
preferida de la invención, resulta el siguiente ciclo de arbitraje
en el caso de soporte de dos prioridades:
- -
- Mientras el maestro del bus actual mantiene el derecho de acceso al bus, la unidad de arbitraje del maestro del bus activa "bus ocupado" (por ejemplo un 0 lógico) en el anillo de baja prioridad.
- -
- Si el maestro del bus actual está preparado para ceder el derecho de acceso al bus, entonces su unidad de arbitraje activa "liberación del bus" (por ejemplo, un 1 lógico) en el anillo de baja prioridad.
- -
- Para que un usuario del usuario, que ha formulado una solicitud de bus de baja prioridad a su unidad de arbitraje, puede convertirse en el nuevo maestro del bus, deben cumplirse las siguientes condiciones:
- -
- en la entrada de baja prioridad de su unidad de arbitraje debe estar presente el nivel de la señal para "anillo HP liberado",
- -
- en la entrada de baja prioridad de su unidad de arbitraje debe estar presente el nivel de la señal para "liberación del bus",
- -
- debe haber expirado el tiempo de pausa establecido entre la cesión y la nueva obtención del derecho de acceso del bus.
Si se cumplen todas las condiciones, entonces
este usuario del bus se convierte en el nuevo maestro del bus a
partir del siguiente pulso de reloj del bus. Para que en el pulso de
reloj del bus actual no se cumplan estas condiciones también en
otros usuarios del bus y sólo pueda existir un maestro del bus, este
usuario del bus emite en la salida de su unidad de arbitraje el
nivel de la señal para "bus ocupado" en el anillo de baja
prioridad. Este nivel de la señal se mantiene activado hasta que el
nuevo maestro del bus está preparado para ceder de nuevo el derecho
de acceso del bus y conmuta al nivel de la señal para "liberación
del bus" en el anillo de baja prioridad.
Si un maestro del bus recibe el nivel de la señal
"liberación del bus", que ha colocado en la salida de su unidad
de arbitraje en el anillo de baja prioridad, de nuevo en la entrada
de su unidad de arbitraje, entonces no se han cumplido en el pulso
de reloj del bus actual las condiciones para un cambio de maestro en
el bus. En este caso, el maestro del bus actual mantiene el derecho
de acceso al bus y puede realizar de nuevo accesos de escritura y de
lectura a los recursos utilizados en común hasta que otro usuario
del bus formula una solicitud del bus.
Para que un usuario del bus, que ha formulado una
solicitud de bus de alta prioridad en su unidad de arbitraje, pueda
convertirse en el nuevo maestro del bus, deben cumplirse las
siguientes condiciones:
- -
- el usuario del bus debe ser el maestro de anillo de alta prioridad,
- -
- en la entrada de baja prioridad de su unidad de arbitraje debe estar presente el nivel de la señal para "liberación del bus",
- -
- debe haber expirado el tiempo de pausa establecido entre la cesión y la nueva obtención del derecho de acceso del bus.
Si se cumplen todas las condiciones, entonces
este usuario del bus se convierte en el nuevo maestro del bus a
partir del siguiente pulso de reloj del bus. Puesto que las unidades
de arbitraje de los usuarios del bus forman un anillo, con este
método se asegura un tratamiento igual de los usuarios del bus y un
tiempo de retraso máximo desde la solicitud del bus hasta la
asignación del bus.
Si se solicitas otras prioridades, entonces es
necesario otro anillo de prioridad para cada prioridad adicional. De
lo contrario, se aplican en adelante las explicaciones anteriores,
con la siguiente generalización:
Para que un usuario del bus, que ha formulado una
solicitud del bus de una prioridad N dada en su unidad de arbitraje,
pueda convertirse en el nuevo maestro del bus, deben cumplirse las
siguientes condiciones:
- -
- en cada una de las entradas de alta prioridad de su unidad de arbitraje debe estar presente en cada caso el nivel de la señal para "anillo liberado",
- -
- el usuario del bus debe ser el maestro del anillo de este plano de prioridad N,
- -
- en la entrada de baja prioridad de su unidad de arbitraje debe estar presente el nivel de la señal para "liberación del bus",
- -
- debe haber expirado el tiempo de pausa establecido entre la cesión y la nueva obtención del derecho de acceso del bus.
Si se cumplen todas las condiciones, entonces
este usuario del bus se convierte en el nuevo maestro del bus a
partir del siguiente pulso de reloj del bus.
Este procedimiento cumple todos los
requerimientos que se plantean a un procedimiento de arbitraje de
alta capacidad, con un gasto de planificación y de proyección al
mismo tiempo mínimo.
El empleo del procedimiento de arbitraje descrito
es especialmente posible en la comunicación de Ethernet en tiempo
real en la zona del bus de campo.
Además, es especialmente ventajoso que los
procedimientos publicados se emplean o bien se pueden emplear en
sistemas de automatización, especialmente en máquinas de envase,
prensas, máquinas de moldeo por inyección de plástico, máquinas
textiles, máquinas de imprenta, máquinas herramientas, robots,
sistemas de manipulación, máquinas de procesamiento de la madera,
máquinas de procesamiento del vidrio, máquinas de procesamiento de
la cerámica así como en aparatos elevadores.
A continuación se explican en detalle ejemplos de
realización preferidos de la invención con referencia a los dibujos.
En este caso:
La figura 1 muestra el arbitraje con una
prioridad - estado después de la reposición, con el usuario 2 como
maestro del bus.
La figura 2 muestra el diagrama de flujo de una
forma de realización de un procedimiento según la invención con una
prioridad.
La figura 3 muestra el arbitraje con una
prioridad - los usuarios 1 y 4 activan una solicitud del bus, el
usuario 4 se convierte en el maestro del bus, con diagrama de
tiempo.
La figura 4 muestra el arbitraje con una
prioridad - el usuario 4 desactiva la solicitud del bus; el usuario
1 se convierte en el maestro del bus, con diagrama de tiempo.
La figura 5 muestra el arbitraje con una
prioridad -el usuario 1 desactiva la solicitud del bus y permanece
como maestro del bus, con diagrama de tiempo.
La figura 6 muestra el arbitraje con tres
prioridades -estado después de la reposición; el usuario 2 es el
maestro del bus.
La figura 7 muestra una forma de realización de
un procedimiento según la invención con varias prioridades.
La figura 8 muestra el arbitraje con tres
prioridades - los usuarios 3, 4 y 5 activan solicitudes del bus de
diferente prioridad; el usuario 5 se convierte en el maestro del
bus.
La figura 9 muestra el arbitraje con tres
prioridades - el usuario 5 desactiva la solicitud del bus; el
usuario 4 se convierte en el maestro del bus.
La figura 10 muestra el arbitraje con tres
prioridades - el usuario 4 desactiva la solicitud del bus; el
usuario 3 se convierte en el maestro del bus.
La figura 11 muestra el arbitraje con tres
prioridades - los usuarios 4 y 6 activan solicitudes del bus de
diferente prioridad; el usuario 3 desactiva la solicitud del bus; el
usuario 6 se convierte en el maestro del bus.
La figura 12 muestra el arbitraje con tres
prioridades y usuarios virtuales - estado después de la reposición;
el usuario 2 es el maestro del bus.
La figura 13 muestra una forma de realización de
un procedimiento según la invención con una unidad de arbitraje como
usuario virtual.
La figura 14 muestra el arbitraje con tres
prioridades y usuarios virtuales - los usuarios 1, 3 y 4 activan
solicitudes del bus de diferente prioridad; el usuario 3 se
convierte en el maestro del bus.
La figura 15 muestra el arbitraje con tres
prioridades y usuarios virtuales - el usuario 2 activa la solicitud
del bus; el usuario 3 desactiva la solicitud del bus; el usuario 4
se convierte en el maestro del bus.
La figura 16 muestra el arbitraje con tres
prioridades y usuarios virtuales - el usuario 3 activa la solicitud
del bus; el usuario 1 se convierte en el maestro del bus.
La figura 17 muestra el arbitraje con tres
prioridades y usuarios virtuales - el usuario 1 desactiva la
solicitud del bus; el usuario 3 se convierte en el maestro del
bus.
La figura 18 muestra el arbitraje con tres
prioridades y usuarios virtuales - el usuario 3 desactiva la
solicitud del bus; el usuario 2 se convierte en el maestro del
bus.
La figura 19 muestra el arbitraje con tres
prioridades y usuarios virtuales - el usuario 2 desactiva la
solicitud de bus y permanece como maestro del bus.
La figura 1 muestra un diagrama de bloques de un
sistema de comunicación según la invención. El sistema de
comunicación contiene un bus de datos 10, al que pueden acceder los
usuarios Tn 1, Tn 2, Tn 3, Tn 4 y Tn 5 del sistema de comunicación.
Los usuarios Tn 1 a Tn 5 están acoplados a través de un anillo de
arbitraje 12. El anillo de arbitraje 12 tiene una dirección
periférica, que es el sentido de las agujas del reloj, en el ejemplo
de realización considerado aquí.
La figura 1 muestra el estado después de la
reposición: el usuario Tn 2 es el maestro del bus y el maestro de
anillo, mientras no se active ninguna solicitud de acceso, es decir,
una llamada solicitud del bus. Se puede generar una solicitud del
bus, por ejemplo, por una aplicación de un usuario. Por "maestro
del bus" se entiende a continuación aquel usuario, que puede
acceder al bus de datos 10.
Cada uno de los usuarios Tn 1 a Tn 5 tiene un
módulo de arbitraje 14 con una entrada 16 y una salida 18. En la
entrada 16 se puede recibir la señal "Bus / anillo ocupado" o
"Bus / anillo liberado". La señal en la entrada 16 se emite, en
general, sin modificaciones en la salida 18.
Solamente cuando un usuario tiene el papel de un
maestro de anillo para el anillo de arbitraje 12, este usuario, con
la señal "Bus / anillo ocupado" en su entrada 16, puede emitir
en su salida 18 la señal "Bus / anillo liberado". En la
configuración considerada aquí, los maestros del bus y el maestro
del anillo son idénticos, puesto que solamente existe un anillo de
arbitraje 12. En el ejemplo considerado aquí, el usuario Tn 2 es el
maestro del bus y el maestro del anillo.
El diagrama de flujo de la figura 2 ilustra el
modo de trabajo del sistema de comunicación de a figura 1. En la
etapa 20, uno de los usuarios Tn X es el maestro del bus y al mismo
tiempo el maestro del anillo. El usuario Tn X tiene acceso actual
al bus de datos 10, de manera que sobre el anillo de arbitraje 12
circula la señal "Bus / anillo ocupado".
En la etapa 22, el usuario Tn X quiere liberar el
bus de datos 10. El motivo de ello puede ser que el usuario Tn X no
tiene ya ninguna solicitud del bus o que ha expirado un tiempo
máximo predeterminado para la ocupación del bus de datos. Puesto que
el usuario Tn X es el maestro del anillo, puede emitir la señal
"liberar el bus / anillo" en su salida 18, lo que se lleva a
cabo en la etapa 22.
En la etapa 24, otro de los usuarios Tn Y tiene
una solicitud de acceso. Ésta puede proceder de una aplicación del
usuario Tn Y. En la etapa 26, el usuario Tn Y verifica si en su
entrada 16 está presente la señal "Bus / anillo liberado". Si
no es así, entonces el usuario Tn Y debe esperar hasta que esta
señal esté presente en su entrada 16.
Tan pronto como la señal "Bus / anillo
liberado" se encuentra en la entrada 16 del usuario Tn Y, el
usuario Tn Y emite en la etapa 28 en su salida 18 la señal "Bus /
anillo ocupado". Esto se lleva a cabo, por ejemplo, al comienzo
de un pulso de reloj del bus.
En la etapa 300, el usuario Tn Y verifica si la
señal "Bus / anillo liberado" se encuentra todavía en su
entrada 16 al final del pulso de reloj del bus. Cuando éste es el
caso, esto significa que o bien ningún otro usuario ha emitido una
señal "Bus / anillo ocupado" sobre el anillo de arbitraje 12,
después de que estaba presente la señal "Bus / anillo
liberado", o que otro usuario ha emitido, en efecto, una tal
señal "Bus / anillo ocupado", pero este usuario está más
retirado del maestro del anillo actual, en el sentido de la
circulación del anillo de arbitraje 12, que el usuario Tn Y. De una
manera más ventajosa, la longitud del pulso de reloj de usuario se
selecciona esencialmente igual a la longitud para la circulación de
una señal alrededor del anillo de arbitraje 12 o más larga.
Cuando se cumple la condición de la etapa 30, el
usuario Tn Y se convierte en la etapa 32 en el nuevo maestro del bus
y al mismo tiempo en el nuevo maestro del anillo para el anillo de
arbitraje 12. Si no se cumple la condición de la etapa 30, entonces
el control del ciclo del usuario Tn Y retorna de nuevo a la etapa
26.
La figura 3 muestra un diagrama de tiempo
correspondiente. En primer lugar, el usuario Tn 2 se convierte en el
maestro del bus y en el maestro de anillo del anillo de arbitraje
12. La salida del anillo en la salida 18 del usuario Tn 2 está en 1
lógico, es decir, "Bus / anillo liberado". Al comienzo del
pulso de reloj del bus 34, el usuario Tn 1 recibe una solicitud del
acceso al bus de datos 10, es decir, que la señal Busreq_Tn 1 pasa
de 0 lógico a 1 lógico; de la misma manera, el usuario Tn 4 recibe
una solicitud de acceso al bus de datos 10, de manera que también la
señal Busreq_Tn 4 pasa de 0 lógico a 1 lógico.
Puesto que la señal "Bus / anillo liberado"
circula sobre el anillo de arbitraje 12 y el usuario Tn 1 la recibe
en su entrada 16, el usuario Tn 1 emite a continuación en su salida
18, es decir, en su salida de anillo, la señal "Bus / anillo
ocupado". De la misma manera se comporta para el usuario Tn
4.
Las señales "Bus / anillo ocupado", emitidas
por los usuarios Tn 1 y Tn 4 comienzan entonces a propagarse en el
sentido de las agujas del reloj a través del anillo de arbitraje 12
sobre los usuarios individuales. Al final del pulso de reloj del bus
34, los usuarios Tn 1 y Tn 4 verifican en cada caos en sus entradas
16, si la señal en las entradas 16 respectivas es todavía "Bus /
anillo liberado".
Éste es el caso para el usuario Tn 4, puesto que
éste está dispuesto en el sentido de las agujas del reloj más cerca
del maestro del anillo Tn2 actual todavía en el anillo de arbitraje
12. En la entrada 16 del usuario Tn 1 se encuentra, en cambio, ya la
señal "Bus / anillo ocupado". En virtud de ello, el usuario Tn
4 se convierte en el nuevo maestro del bus y al mismo tiempo también
en el nuevo maestro de anillo del anillo de arbitraje 12 y puede
acceder al bus de datos 10.
La figura 4 muestra una situación
correspondiente, en la que el usuario Tn 4 desactiva su solicitud
del bus, es decir, que conmuta en su salida 16 desde "Bus / anillo
ocupado" a "Bus / anillo liberado". Por lo tanto, después
de que el usuario Tn 4 ha procesado su solicitud de acceso o ha
expirado el tiempo máximo de acceso, el usuario Tn 1 retorna ahora
"a la serie" y se convierte en el nuevo maestro del bus y
maestro del anillo.
La figura 5 muestra una situación, en la que el
maestro del anillo y el maestro del bus actual Tn1 desactiva su
solicitud del bus y permanece en primer lugar como maestro del bus y
maestro del anillo, puesto que no está activada ninguna solicitud
del bus de otro usuario.
La figura 6 muestra otra forma de realización
alternativa de un sistema de comunicación según la invención con
varios anillos de arbitraje.
El sistema de comunicación contiene los usuarios
1, 2, 3, 4, 5 y 6 así como el bus de datos 10. Los usuarios 1 a 6
tienen módulos de arbitraje 36, que están acoplados entre sí por
medio de anillos de arbitraje 38, 40 y 42. El anillo de arbitraje 38
sirve en este caso para el procesamiento de solicitudes de acceso al
bus 10 con la máxima prioridad 1. De una manera correspondiente, el
anillo de arbitraje 40 sirve para solicitudes de acceso de la
prioridad 2 y el anillo de arbitraje 42 sirve para solicitudes de
acceso de la prioridad 3.
La figura 6 muestra el estado de este sistema de
comunicación después de una reposición, en la que el usuario 2 es el
maestro del bus y al mismo tiempo es el maestro de anillo de los
anillos de arbitraje 38, 40 y 42.
El diagrama de flujo de la figura 7 ilustra el
modo de trabajo de un sistema de comunicación del tipo, como se
representa en la figura 6, con un número de prioridades N y con un
número de anillos de arbitraje N.
En la etapa 50, un o de los usuarios X del
sistema de comunicación es el maestro de bus y el maestro de anillo
de los anillos de arbitraje. Éste es el estado inicial después de
una reposición. En la etapa 52, el usuario X coloca la señal "Bus
/ anillo liberado" en el anillo de baja prioridad del sistema de
comunicación, es decir, en el ejemplo de la figura 6 en el anillo
de arbitraje 42. Esto corresponde a la etapa 22 de la forma de
realización de la figura 2.
En la etapa 54, el usuario Y del sistema de
comunicación tiene una solicitud de acceso al bus de datos 10 con la
prioridad i, en la que 1 \leq i \leq N. Esta etapa corresponde a
la etapa 24 en la forma de realización de la figura 2.
En la etapa 56, el usuario Y verifica si la señal
"anillo liberado" sobre el anillo de arbitraje, que está
asociado a la prioridad i, se encuentra en la entrada del usuario Y.
Si éste no es el caso, entonces el usuario Y debe esperar hasta que
se cumple esta condición. No obstante, si se cumple esta condición,
entonces el usuario Y emite, por ejemplo al comienzo de un pulso de
reloj de bus, la señal "anillo ocupado" en su salida sobre el
anillo de arbitraje de la
\hbox{prioridad i.}
En la etapa 60, el usuario Y verifica si la señal
"anillo liberado" se encuentra todavía en la entrada del
usuario Y para el anillo de arbitraje de la prioridad i al término
del pulso de reloj del bus. Si éste no es el caso, entonces el
control del ciclo del usuario Y retorna de nuevo a la etapa 56.
Si se cumple la condición, entonces se lleva a
cabo a continuación la etapa 62. Las etapas 56, 58 y 60 corresponden
a las etapas 26, 28 y 30 de la forma de realización de la figura 2,
en la que el anillo de arbitraje, que está asociado a la prioridad
i, entra en el lugar del único anillo de arbitraje 12 (ver la figura
1).
En la etapa 62, el usuario Y se convierte en el
nuevo maestro de anillo del anillo de arbitraje de la prioridad i.
Pero de esta manera el usuario Y no se ha convertido todavía en el
maestro del bus.
A tal fin, debe verificarse en primer lugar en la
etapa 64 por el usuario Y si la señal "anillo ocupado" sobre el
anillo de arbitraje con la prioridad N más baja o sobre un anillo de
arbitraje con una prioridad, que es mayor que la prioridad i, se
encuentra en una de las entradas de anillo de arbitraje del usuario
Y. Cuando éste es el caso, entonces el usuario Y debe esperar hasta
que la señal "anillo ocupado" es sustituida por la señal
"anillo liberado".
Entonces el usuario Y emitirá en la etapa 66 la
señal "anillo ocupado" sobre el anillo de prioridad más baja,
para que se convierta en la etapa 68 en el nuevo maestro de bus y
maestro de anillo del anillo de prioridad más baja.
La figura 8 muestra el estado del sistema de
comunicación de la figura 6 cuando el usuario 2 es en primer lugar
el maestro de bus y el usuario 3 tiene una solicitud de acceso al
bus de datos 10 con la prioridad 3 ("Solicitud - Prio 3") y,
además, el usuario 4 tiene una Solicitud - Prio 2 y el usuario 5
tiene una Solicitud - Prio 1. En esta situación, el usuario 5 se
convierte en el maestro de usuario del anillo de arbitraje 38 de la
prioridad 1; el usuario 4 se convierte en el nuevo maestro de anillo
del anillo de arbitraje 4 de la prioridad 2 y el usuario 5 se
convierte en el nuevo maestro de anillo del anillo de arbitraje 42
de la prioridad 3, aunque en el usuario 3 está activa una Solicitud
- Prio 3.
El usuario 3 solamente podría convertirse en el
nuevo maestro de anillo de la prioridad 3 cuando no está activa
ninguna solicitud de acceso con una prioridad más alta. A
continuación, el usuario se convierte en el maestro del anillo de la
prioridad 3, que ha formulado la solicitud del bus con la máxima
prioridad. Cada maestro del bus de la prioridad 3 es al mismo tiempo
también el maestro del bus de datos. Por lo tanto, el usuario 5 se
convierte en el nuevo maestro del bus.
La figura 9 muestra el estado del sistema de
comunicación a partir del estado de la figura 8, es decir, el punto
de partida, en el que el usuario 5 es el maestro del bus. El usuario
5 desactiva su Solicitud - Prio 1, donde el usuario 3 tiene una
Solicitud - Prio 3 y el usuario 4 tiene una Solicitud - Prio 2. En
este caso, el usuario 5 se mantiene como maestro de anillo del
anillo de arbitraje 38 de la prioridad 1, puesto que ningún otro
usuario ha activado una solicitud de acceso al bus de datos 10 de la
prioridad 1. Además, el usuario 4 permanece como maestro de anillo
del anillo de arbitraje 40 de la prioridad 2 y se convierte en el
nuevo maestro de anillo del anillo de arbitraje 42 de la prioridad
3, aunque en el usuario 3 está activa una Solicitud - Prio 3.
El usuario 3 solamente podría convertirse
entonces en el nuevo maestro de anillo de la prioridad 3 cuando no
está activa ninguna Solicitud de una prioridad más alta. En este
procedimiento, el usuario se convierte siempre en el maestro de
anillo de la prioridad 3, que ha formulado la solicitud del bus con
la máxima prioridad. Cada maestro de anillo de la prioridad 3 es al
mismo tiempo también el maestro del bus de datos. Por lo tanto, el
usuario 4 se convierte ahora en el nuevo maestro del bus.
La figura 10 muestra el estado del sistema de
comunicación, en el que el usuario 4 es el maestro de bus antiguo.
Éste desactiva su Solicitud - Prio 2. El usuario 3 tiene una
Solicitud - Prio 3. En esta situación, el usuario 5 se convierte en
el maestro de anillo del anillo de arbitraje 38 de la prioridad 1,
puesto que ningún otro usuario ha activado una solicitud de la
prioridad 1. El usuario 4 se mantiene como maestro de anillo del
anillo de arbitraje 40 de la prioridad 2, puesto que ningún otro
usuario ha activado una solicitud de la prioridad 2. El usuario se
convierte en el nuevo maestro de usuario del anillo de arbitraje 42
de la prioridad 3, puesto que no está activada ninguna solicitud de
una prioridad más alta.
En este procedimiento, el usuario se convierte
siempre en el maestro de anillo de la prioridad 3, que ha formulado
la solicitud del bus con la máxima prioridad. Cada maestro de anillo
de la prioridad 3 es al mismo tiempo también el maestro del bus de
datos. Por lo tanto, el usuario 3 se convierte ahora en el nuevo
maestro del bus.
La figura 11 muestra el estado del sistema de
comunicación, en el que el usuario 4 activa una Solicitud - Prio 3 y
el usuario 6 activa su Solicitud - Prio 2. En esta situación, el
usuario 6 se convierte de forma inmediata en el nuevo maestro de bus
del anillo de arbitraje de la prioridad 2. Esto es independiente del
instante, en el que el maestro de bus anterior, es decir, el usuario
3 desactiva su solicitud del bus.
No obstante, el usuario 8 se puede convertir en
el maestro de bus lo más pronto cuando el maestro de bus actual, es
decir, el usuario 3, desactiva la solicitud del bus. La prioridad de
la solicitud del bus por el maestro de bus no tiene en este caso
ninguna importancia.
Tan pronto como el maestro de bus actual, el
usuario 3, desactiva la Solicitud- Prio 3, el usuario 6 se convierte
en el nuevo maestro de bus de la prioridad 3 y, por lo tanto, se
convierte en el nuevo maestro de bus.
El usuario 4 no se convierten el maestro de
anillo de la prioridad 3 a pesar de que la Solicitud - Prio 3 está
activada, puesto que está activada una solicitud de una prioridad
más alta. Después de que el maestro de bus actual, el usuario 3, ha
desactivado su solicitud de bus, resulta la situación mostrada en la
figura 11.
En cambio, si el usuario 2 desactiva la Solicitud
- Prio 3, antes de que el maestro de bus actual, el usuario 6, esté
preparado para la cesión del bus (es decir, que desactiva su
solicitud del bus), el usuario 2 se convierte en el nuevo maestro de
anillo de la prioridad 3 y, por lo tanto, en el nuevo maestro del
bus, cuando el usuario 6 desactiva la solicitud del bus y en este
instante no está activada ninguna solicitud de prioridad más alta de
otro usuario. El usuario 4 ha activado, en efecto, la Solicitud del
bus - Prio 3 antes que el usuario 2, pero se ha saltado durante el
cambio del maestro del bus desde el usuario 3 hacia el usuario
6.
Por ejemplo, si el usuario 5 activa la Solicitud
del bus - Prio 1 o la Solicitud del bus - Prio 2 antes de que el
maestro de bus actual, el usuario 2, esté preparado para la cesión
del bus, no se tiene en cuenta de nuevo el usuario 3 en el siguiente
cambio de maestro de bus. El motivo por el que durante el cambio de
maestro de bus, no se tiene en cuenta el usuario, que activa la
solicitud de bus de baja prioridad, es porque el maestro de anillo
de esta prioridad más baja es siempre también el maestro de bus en
este procedimiento.
Para evitar este inconveniente, es decir, la no
consideración de un usuario durante el cambio de maestro de bus, hay
que modificar el procedimiento descrito anteriormente para que
adicionalmente a los N anillos de prioridad, sea insertado un anillo
maestro de bus. Por lo tanto, en el caso de 3 prioridades son
necesarios cuatro anillos: 3 anillos de prioridad y 1 anillo de
maestro de bus. En oposición al procedimiento descrito
anteriormente, el anillo de prioridad más baja se comporta de una
manera similar a los anillos de prioridad más alta. El maestro del
bus es en este procedimiento el maestro de anillo del anillo de
maestro de bus.
La ventaja de los dos procedimientos presentados
anteriormente es la reducción al mínimo del tiempo de espera de un
usuario, que la formulado una solicitud de bus de alta prioridad,
para la asignación del bus. El inconveniente de ambos procedimientos
es la posibilidad de tiempos de espera largos en usuarios, que han
formulado una solicitud de bus de baja prioridad, cuando al mismo
tiempo existen muchas solicitudes de bus de alta prioridad por otros
usuarios.
Otro procedimiento de arbitraje, que se basa en
la estructura de anillo, posee las ventajas de los dos
procedimientos anteriores, con una reducción simultánea de sus
inconvenientes.
Este procedimiento de arbitraje se caracteriza
por
- -
- N anillos de prioridad, que funcionan de una manera similar a los descritos anteriormente, donde N \geq 2,
- -
- un usuario virtual en el anillo de prioridad (N-1), que representa a los usuarios en el anillo de prioridad de la prioridad N. N es la prioridad más baja,
- -
- un usuario virtual en el anillo de prioridad (N-2), que representa a los usuarios en el anillo de prioridad de la prioridad (N-1),
- -
- un usuario virtual en el anillo de prioridad (N-3), que representa a los usuarios en el anillo de prioridad de la prioridad (N-2),
- -
- etc.
- -
- un usuario virtual en el anillo de prioridad 1, que representa a los usuarios en el anillo de prioridad de la prioridad 2,
- -
- cada usuario virtual de un anillo de arbitraje debe ceder el derecho de acceso al bus a un usuario de su plano de prioridad o de un plano de prioridad más alto siempre que un usuario del anillo representado esté preparado para la cesión del bus,
- -
- el maestro del bus de datos es siempre el maestro de anillo del anillo de arbitraje con la máxima prioridad.
La figura 12 muestra un diagrama de bloques de un
ejemplo de realización de un sistema de comunicación de este tipo
con un procedimiento de arbitraje con N = 3, es decir, para tres
prioridades y tres anillos de arbitraje.
El anillo de arbitraje 44 está asociado a la
prioridad 1 y conecta los módulos de arbitraje 14 de la prioridad 1
de los usuarios entre sí así como el módulo de arbitraje 50 de una
unidad de arbitraje, que se designa, por lo demás, como usuario
virtual. El módulo de arbitraje 50 representa los módulos de
arbitraje 14 de la prioridad 2 en el anillo de arbitraje 44 de la
prioridad 1. Cuando está presente una solicitud de acceso al bus de
datos con la prioridad 2 en uno de los usuarios, entonces esto es
representado por el módulo de arbitraje 50 en el anillo de arbitraje
44 de la prioridad 1 por una solicitud de acceso con la prioridad
1.
De una manera correspondiente se comporta con el
módulo de arbitraje 52 en el anillo de arbitraje 46, que representa
solicitudes de acceso de los usuarios con la prioridad 3 en el
anillo de arbitraje 46 de la prioridad 2.
El maestro de bus de datos es siempre el maestro
de anillo del anillo de arbitraje con la máxima prioridad. En el
caso de un cambio de maestro de anillo se aplican para cada anillo
de arbitraje, además, los diagramas de tiempo correspondientes de
las figuras 3 a 5.
La figura 12 muestra el estado después de la
reposición: el usuario 2 es el maestro de bus, con tal que no se
active ninguna solicitud del bus.
La figura 13 ilustra con la ayuda de un diagrama
de flujo el modo de trabajo de un sistema de comunicación del tipo
de la figura 12. En la etapa 60, uno de los usuarios Y tiene una
solicitud de acceso al bus de datos con la prioridad i. En la etapa
62, esta solicitud de acceso del usuario virtual de la prioridad
i-1 en el anillo de arbitraje de la prioridad
i-1 está representada por una solicitud de acceso
correspondiente de la prioridad i-1.
En la etapa 64, el usuario virtual de la
prioridad i-1 se ha convertido en el maestro de
anillo en el anillo de arbitraje de la prioridad
i-1. Además, el usuario virtual se convierte también
en el maestro de bus (etapa 66), de manera que el usuario Y puede
acceder al bus en la etapa 66.
La figura 14 muestra el estado del sistema de
comunicación cuando en primer lugar el usuario 2 es el maestro de
bus antiguo. En el mismo pulso de reloj del bus, el usuario 3 activa
una Solicitud - Prio 3, el usuario 1 una Solicitud - Prio 2 y el
usuario 4 una Solicitud - Prio 1. A continuación, el usuario 3 se
convierte en el nuevo maestro de anillo del anillo de arbitraje 48
de la prioridad 3; el usuario virtual con el módulo de arbitraje 52
se convierte en el nuevo maestro de anillo del anillo de arbitraje
46 de la prioridad 2, el usuario virtual con el módulo de arbitraje
50 se convierte en el nuevo maestro de anillo del anillo de
arbitraje 44 de la prioridad 1 y el usuario 3 recibe finalmente el
acceso al bus de datos 10.
En la figura 15 el usuario 3 es el maestro de bus
actual. El usuario 2 activa la Solicitud Prio 3.
De esta manera, están activas las siguientes
solicitudes de bus cuando el maestro de bus actual, el usuario 3,
está preparado para el cambio de maestro de bus:
- Usuario 2: Solicitud Prio 3 está activa;
- Usuario 1: Solicitud Prio 2 está activa;
- Usuario 4: Solicitud Prio 1 está activa;
- \Rightarrow
- El usuario 2 se convierte en el nuevo maestro de anillo del anillo de arbitraje de la prioridad 3;
- \Rightarrow
- El usuario 1 se convierte en el nuevo maestro de anillo del anillo de arbitraje de la prioridad 2;
- \Rightarrow
- El usuario 4 se convierte en el nuevo maestro de anillo del anillo de arbitraje de la prioridad 1;
- \Rightarrow
- El usuario 4 se convierte en el nuevo maestro de bus de datos.
En la figura 16, el usuario 4 es el maestro de
bus actual; el usuario 3 activa la Solicitud Prio 1. De esta manera,
están activas las siguientes solicitudes de bus cuando el maestro de
bus actual, el usuario 4, está preparado para el cambio de maestro
de bus:
- Usuario 2: Solicitud Prio 3 está activa;
- Usuario 1: Solicitud Prio 2 está activa;
- Usuario 3: Solicitud Prio 1 está activa;
- \Rightarrow
- El usuario 2 permanece como maestro de anillo del anillo de arbitraje de la prioridad 3;
- \Rightarrow
- El usuario 1 permanece como maestro de anillo del anillo de arbitraje de la prioridad 2;
- \Rightarrow
- El usuario virtual P2 se convierte en el nuevo maestro de anillo del anillo de arbitraje de la prioridad 1;
- \Rightarrow
- El usuario 1 se convierte en el nuevo maestro de bus de datos.
En la figura 17, el usuario 1 es el maestro de
bus activo.
De esta manera, están activas las siguientes
solicitudes de bus cuando el maestro de bus actual, el usuario 1,
está preparado para el cambio de maestro de bus:
- Usuario 2: Solicitud Prio 3 está activa;
- Usuario 3: Solicitud Prio 1 está activa;
- \Rightarrow
- El usuario 2 permanece como maestro de anillo del anillo de arbitraje de la prioridad 3;
- \Rightarrow
- El usuario virtual P3 se convierte en el nuevo maestro de anillo del anillo de arbitraje de la prioridad 2;
- \Rightarrow
- El usuario 3 se convierte en el nuevo maestro de anillo del anillo de arbitraje de la prioridad 1;
- \Rightarrow
- El usuario 3 se convierte en el nuevo maestro de bus de datos
En la figura 18, el usuario 3 es el maestro de
bus actual:
De esta manera, están activas las siguientes
solicitudes de bus cuando el maestro de bus actual, el usuario 3,
está preparado para el cambio de maestro de bus:
- Usuario 2: Solicitud Prio 3 está activa;
- \Rightarrow
- El usuario 2 permanece como maestro de anillo del anillo de arbitraje de la prioridad 3;
- \Rightarrow
- El usuario virtual P3 permanece como maestro de anillo del anillo de arbitraje de la prioridad 2;
- \Rightarrow
- El usuario virtual P2 se convierte en el nuevo maestro de anillo del anillo de arbitraje de la prioridad 1;
- \Rightarrow
- El usuario 2 se convierte en el nuevo maestro de bus de datos.
En la figura 19, el usuario 2 es el maestro de
bus actual: De esta manera, están activas las siguientes solicitudes
de bus cuando el maestro de bus actual, el usuario 3, está preparado
para el cambio de maestro de bus:
- \Rightarrow
- El usuario 2 permanece como maestro de anillo del anillo de arbitraje de la prioridad 3;
- \Rightarrow
- El usuario virtual P3 permanece como maestro de anillo del anillo de arbitraje de la prioridad 2;
- \Rightarrow
- El usuario virtual P2 permanece como maestro de anillo del anillo de arbitraje de la prioridad 1;
- \Rightarrow
- El usuario 2 permanece como maestro de bus de datos, hasta que otro usuario activa una solicitud de bus.
Claims (9)
1. Procedimiento para el arbitraje de un acceso a
un bus de datos entre usuarios (Tn1, Tn2, ...), en el que los
usuarios están acoplados a través de al menos un anillo de arbitraje
(12; 38, 40, 42, 44, 46, 48), con las siguientes etapas:
- a)
- solicitud del acceso de uno primero de los usuarios,
- b)
- verificación para determinar si una primera señal, para la indicación de que está liberado uno de los anillos de arbitraje, se encuentra en una entrada (16) del primer usuario,
- c)
- emisión (18) de una segunda señal a través del primer usuario, cuando está presente la primera señal,
- d)
- verificación para determinar si la primera señal se encuentra todavía en la entrada del primer usuario al final de un intervalo de tiempo predeterminado,
- e)
- acceso del primer usuario cuando la primera señal está presente todavía al final del intervalo de tiempo predeterminado,
caracterizado porque los
usuarios están acoplados a través de un número de anillos de
arbitraje (12, 38, 40, 42, 44, 46, 48), y a cada anillo de arbitraje
está asociada una
prioridad.
2. Procedimiento según la reivindicación 1, en el
que la solicitud del acceso de uno primero de los usuarios se lleva
a cabo con una primera prioridad y se realiza la verificación para
determinar si una primera señal, para la indicación de que está
liberado el anillo de arbitraje asociado a la primera prioridad, se
encuentra en la entrada (16) del primer usuario, siendo realizada la
emisión (18) de la segunda señal sobre el anillo de arbitraje
asociado a la primera prioridad, y con las otras etapas:
- -
- verificación para determinar si la segunda señal se encuentra en una entrada del usuario para el anillo de arbitraje de prioridad más baja o en una entrada del usuario para un anillo de arbitraje, que está asociado a una prioridad más alta que la primera prioridad,
- -
- emisión de la segunda señal sobre el anillo de prioridad más baja,
- -
- acceso del primer usuario.
3. Procedimiento según la reivindicación 2, con
un usuario virtual (50, 52) para la representación de solicitudes de
acceso de los usuarios de una segunda prioridad en un anillo de
arbitraje, que está asociado a una tercera prioridad más alta.
4. Procedimiento según la reivindicación 1, 2 ó
3, en el que en el intervalo de tiempo predeterminado se trata de un
pulso de reloj del bus de datos.
5. Usuario para el acceso a un bus de datos (10),
con
- a)
- medios para la solicitud de un acceso,
- b)
- medios para la verificación de si una primera señal para la indicación de que uno de los anillos de arbitraje está liberado, se encuentra en una entrada (16) del primer usuario,
- c)
- medios para la emisión (18) de una segunda señal a través del primer usuario, cuando está presente la primera señal,
- d)
- medios para la verificación de si la primera señal está presente todavía en la entrada del primer usuario al final de un intervalo de tiempo predeterminado,
- e)
- medios para el acceso del primer usuario, cuando la primera señal está presente todavía al final del intervalo de tiempo predeterminado,
caracterizado porque los
usuarios están acoplados a través de un número de anillos de
arbitraje (12; 38, 40, 42, 44, 46, 48), y a cada anillo de arbitraje
está asociada una
prioridad.
6. Usuario según la reivindicación 5 para el
acoplamiento, en el que los medios para la solicitud de un acceso de
uno primero de los usuarios están configurados con una primera
prioridad, los medios para la verificación están configurados de
esta manera para verificar si la primera señal para la indicación de
que se ha liberado el anillo de arbitraje que está asociado a la
primera prioridad, está presente en la entrada, los medios para la
emisión de la segunda señal sobre el anillo de arbitraje que está
asociado a la primera prioridad están configurados a través del
usuario y con:
- -
- medios para verificar si la segunda señal se encuentra en una entrada del usuario para el anillo de arbitraje de la prioridad más baja o en una entrada del usuario para un anillo de arbitraje, que está asociado a una prioridad más alta que la primera prioridad,
- -
- medios para la emisión de la segunda señal sobre el anillo de prioridad más baja.
7. Usuario según la reivindicación 5 con medios
(50, 52) para la representación de solicitudes de acceso de los
usuarios de una segunda prioridad en un anillo de arbitraje, que
está asociado a una tercera prioridad más elevada.
8. Usuario según una de las reivindicaciones
anteriores 5, 6 ó 7, en el que en el intervalo de tiempo
predeterminado se trata de un ciclo de bus (34).
9. Sistema de comunicación con varios usuarios,
en el que cada usuario está configurado según una de las
reivindicaciones 5 a 8 anteriores, y con uno o varios de los anillos
de arbitraje (38, 40, 42, 44, 46, 48) para el acoplamiento de los
usuarios.
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| DE10147437 | 2001-09-26 | ||
| DE10147437 | 2001-09-26 | ||
| DE10234145A DE10234145A1 (de) | 2001-09-26 | 2002-07-26 | Verfahren zur Arbitrierung eines Zugriffs auf einen Datenbus |
| DE10234145 | 2002-07-26 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2243765T3 true ES2243765T3 (es) | 2005-12-01 |
Family
ID=26010231
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES02774357T Expired - Lifetime ES2243765T3 (es) | 2001-09-26 | 2002-09-13 | Procedimiento para el arbitraje de un acceso a un bus de datos. |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US7360002B2 (es) |
| EP (1) | EP1430406B1 (es) |
| AT (1) | ATE297568T1 (es) |
| ES (1) | ES2243765T3 (es) |
| WO (1) | WO2003027869A2 (es) |
Families Citing this family (53)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7043579B2 (en) * | 2002-12-05 | 2006-05-09 | International Business Machines Corporation | Ring-topology based multiprocessor data access bus |
| JP4748641B2 (ja) * | 2004-12-06 | 2011-08-17 | ルネサスエレクトロニクス株式会社 | 情報処理システム |
| JP4728020B2 (ja) * | 2005-03-17 | 2011-07-20 | 日立オートモティブシステムズ株式会社 | 車両制御用ソフトウェア及び車両制御装置 |
| WO2007079703A1 (de) * | 2006-01-12 | 2007-07-19 | Siemens Aktiengesellschaft | Schutz- oder leittechnikgerät |
| US8014671B1 (en) * | 2006-01-13 | 2011-09-06 | Lockheed Martin Corporation | Wavelength division multiplexed optical channel switching |
| US8437877B2 (en) | 2008-10-27 | 2013-05-07 | Lennox Industries Inc. | System recovery in a heating, ventilation and air conditioning network |
| US8543243B2 (en) | 2008-10-27 | 2013-09-24 | Lennox Industries, Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
| US9261888B2 (en) | 2008-10-27 | 2016-02-16 | Lennox Industries Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
| US8788100B2 (en) | 2008-10-27 | 2014-07-22 | Lennox Industries Inc. | System and method for zoning a distributed-architecture heating, ventilation and air conditioning network |
| US8452456B2 (en) | 2008-10-27 | 2013-05-28 | Lennox Industries Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
| US8874815B2 (en) | 2008-10-27 | 2014-10-28 | Lennox Industries, Inc. | Communication protocol system and method for a distributed architecture heating, ventilation and air conditioning network |
| US8994539B2 (en) | 2008-10-27 | 2015-03-31 | Lennox Industries, Inc. | Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network |
| US8725298B2 (en) | 2008-10-27 | 2014-05-13 | Lennox Industries, Inc. | Alarm and diagnostics system and method for a distributed architecture heating, ventilation and conditioning network |
| US8255086B2 (en) | 2008-10-27 | 2012-08-28 | Lennox Industries Inc. | System recovery in a heating, ventilation and air conditioning network |
| US8655490B2 (en) | 2008-10-27 | 2014-02-18 | Lennox Industries, Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
| US8463442B2 (en) | 2008-10-27 | 2013-06-11 | Lennox Industries, Inc. | Alarm and diagnostics system and method for a distributed architecture heating, ventilation and air conditioning network |
| US8774210B2 (en) | 2008-10-27 | 2014-07-08 | Lennox Industries, Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
| US8437878B2 (en) | 2008-10-27 | 2013-05-07 | Lennox Industries Inc. | Alarm and diagnostics system and method for a distributed architecture heating, ventilation and air conditioning network |
| US8762666B2 (en) | 2008-10-27 | 2014-06-24 | Lennox Industries, Inc. | Backup and restoration of operation control data in a heating, ventilation and air conditioning network |
| US8694164B2 (en) | 2008-10-27 | 2014-04-08 | Lennox Industries, Inc. | Interactive user guidance interface for a heating, ventilation and air conditioning system |
| US9632490B2 (en) | 2008-10-27 | 2017-04-25 | Lennox Industries Inc. | System and method for zoning a distributed architecture heating, ventilation and air conditioning network |
| US8564400B2 (en) | 2008-10-27 | 2013-10-22 | Lennox Industries, Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
| US8452906B2 (en) | 2008-10-27 | 2013-05-28 | Lennox Industries, Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
| US8892797B2 (en) | 2008-10-27 | 2014-11-18 | Lennox Industries Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
| US8600559B2 (en) | 2008-10-27 | 2013-12-03 | Lennox Industries Inc. | Method of controlling equipment in a heating, ventilation and air conditioning network |
| US9152155B2 (en) | 2008-10-27 | 2015-10-06 | Lennox Industries Inc. | Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system |
| US9651925B2 (en) | 2008-10-27 | 2017-05-16 | Lennox Industries Inc. | System and method for zoning a distributed-architecture heating, ventilation and air conditioning network |
| US8661165B2 (en) | 2008-10-27 | 2014-02-25 | Lennox Industries, Inc. | Device abstraction system and method for a distributed architecture heating, ventilation and air conditioning system |
| US9377768B2 (en) | 2008-10-27 | 2016-06-28 | Lennox Industries Inc. | Memory recovery scheme and data structure in a heating, ventilation and air conditioning network |
| US8560125B2 (en) | 2008-10-27 | 2013-10-15 | Lennox Industries | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
| US8855825B2 (en) | 2008-10-27 | 2014-10-07 | Lennox Industries Inc. | Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system |
| US8798796B2 (en) | 2008-10-27 | 2014-08-05 | Lennox Industries Inc. | General control techniques in a heating, ventilation and air conditioning network |
| US8352081B2 (en) | 2008-10-27 | 2013-01-08 | Lennox Industries Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
| US8615326B2 (en) | 2008-10-27 | 2013-12-24 | Lennox Industries Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
| US9678486B2 (en) | 2008-10-27 | 2017-06-13 | Lennox Industries Inc. | Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system |
| US9268345B2 (en) | 2008-10-27 | 2016-02-23 | Lennox Industries Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
| US8802981B2 (en) | 2008-10-27 | 2014-08-12 | Lennox Industries Inc. | Flush wall mount thermostat and in-set mounting plate for a heating, ventilation and air conditioning system |
| US8352080B2 (en) | 2008-10-27 | 2013-01-08 | Lennox Industries Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
| US8744629B2 (en) | 2008-10-27 | 2014-06-03 | Lennox Industries Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
| US8295981B2 (en) | 2008-10-27 | 2012-10-23 | Lennox Industries Inc. | Device commissioning in a heating, ventilation and air conditioning network |
| US8655491B2 (en) | 2008-10-27 | 2014-02-18 | Lennox Industries Inc. | Alarm and diagnostics system and method for a distributed architecture heating, ventilation and air conditioning network |
| US8548630B2 (en) | 2008-10-27 | 2013-10-01 | Lennox Industries, Inc. | Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network |
| US8600558B2 (en) | 2008-10-27 | 2013-12-03 | Lennox Industries Inc. | System recovery in a heating, ventilation and air conditioning network |
| US8433446B2 (en) | 2008-10-27 | 2013-04-30 | Lennox Industries, Inc. | Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network |
| US8463443B2 (en) | 2008-10-27 | 2013-06-11 | Lennox Industries, Inc. | Memory recovery scheme and data structure in a heating, ventilation and air conditioning network |
| US8442693B2 (en) | 2008-10-27 | 2013-05-14 | Lennox Industries, Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
| US8977794B2 (en) | 2008-10-27 | 2015-03-10 | Lennox Industries, Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
| US9432208B2 (en) | 2008-10-27 | 2016-08-30 | Lennox Industries Inc. | Device abstraction system and method for a distributed architecture heating, ventilation and air conditioning system |
| US9325517B2 (en) | 2008-10-27 | 2016-04-26 | Lennox Industries Inc. | Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system |
| US8239066B2 (en) | 2008-10-27 | 2012-08-07 | Lennox Industries Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
| USD648642S1 (en) | 2009-10-21 | 2011-11-15 | Lennox Industries Inc. | Thin cover plate for an electronic system controller |
| USD648641S1 (en) | 2009-10-21 | 2011-11-15 | Lennox Industries Inc. | Thin cover plate for an electronic system controller |
| US8260444B2 (en) | 2010-02-17 | 2012-09-04 | Lennox Industries Inc. | Auxiliary controller of a HVAC system |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US3983540A (en) * | 1975-09-08 | 1976-09-28 | Honeywell Inc. | Rapid bus priority resolution |
| US4395753A (en) * | 1980-06-26 | 1983-07-26 | Gte Automatic Electric Labs Inc. | Allocation controller providing for access of multiple common resources by a plurality of central processing units |
| US4730268A (en) * | 1985-04-30 | 1988-03-08 | Texas Instruments Incorporated | Distributed bus arbitration for a multiprocessor system |
| EP0633532B1 (de) * | 1993-07-09 | 1998-09-23 | Siemens Aktiengesellschaft | Anordnung zur dezentralen Steuerung des Zugriffs von an einen Bus angeschlossenen Einheiten zum Bus |
| US6385678B2 (en) * | 1996-09-19 | 2002-05-07 | Trimedia Technologies, Inc. | Method and apparatus for bus arbitration with weighted bandwidth allocation |
| US5912889A (en) * | 1996-11-21 | 1999-06-15 | Xerox Corporation | ATM switch with output port clustering for dynamically allocating bandwidth between ports |
| US6459704B1 (en) * | 1997-08-12 | 2002-10-01 | Spectrum Tracking Systems, Inc. | Method and system for radio-location determination |
| US5948089A (en) * | 1997-09-05 | 1999-09-07 | Sonics, Inc. | Fully-pipelined fixed-latency communications system with a real time dynamic bandwidth allocation |
| US6272580B1 (en) * | 1999-03-16 | 2001-08-07 | Compaq Computer Corp. | Apparatus and method for dynamically elevating a lower level bus master to an upper level bus master within a multi-level arbitration system |
-
2002
- 2002-09-13 EP EP02774357A patent/EP1430406B1/de not_active Expired - Lifetime
- 2002-09-13 WO PCT/DE2002/003436 patent/WO2003027869A2/de not_active Ceased
- 2002-09-13 ES ES02774357T patent/ES2243765T3/es not_active Expired - Lifetime
- 2002-09-13 AT AT02774357T patent/ATE297568T1/de not_active IP Right Cessation
-
2004
- 2004-03-26 US US10/809,852 patent/US7360002B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| ATE297568T1 (de) | 2005-06-15 |
| US7360002B2 (en) | 2008-04-15 |
| WO2003027869A2 (de) | 2003-04-03 |
| EP1430406B1 (de) | 2005-06-08 |
| EP1430406A2 (de) | 2004-06-23 |
| WO2003027869A3 (de) | 2003-09-18 |
| US20040252682A1 (en) | 2004-12-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7360002B2 (en) | Method of arbitrating access to a data bus | |
| EP0993680B1 (en) | Method and apparatus in a packet routing switch for controlling access at different data rates to a shared memory | |
| US6119196A (en) | System having multiple arbitrating levels for arbitrating access to a shared memory by network ports operating at different data rates | |
| US5511166A (en) | Method and apparatus for receive frame sorting in a media access control/host system interface unit | |
| EP0383475A2 (en) | Shared resource arbitration | |
| ES2265160T3 (es) | Sistema y metodo para controlar un bus. | |
| ES2281564T3 (es) | Procedimiento de transmision de datos, sistema de bus en serie y unidad de conexion para un usuario de bus pasivo. | |
| CN1150460C (zh) | 计算机总线系统、通信系统和通过总线通信的方法 | |
| JP2004318901A (ja) | データ処理モジュール相互間の高速制御およびデータバスシステム | |
| ES2427827T3 (es) | Puerto de procesadores múltiples | |
| EP0327203B1 (en) | NxM arbitrating non-blocking high bandwidth switch | |
| JPS6252344B2 (es) | ||
| CN1993687B (zh) | 用于控制数据访问的消息管理器和方法以及通信组件 | |
| ES2258160T3 (es) | Procedimiento para la transmision de un telegrama de datos entre un dominio en tiempo real y un dominio no en tiempo real y unidad de acoplamiento. | |
| KR20040054721A (ko) | 컴퓨터 시스템의 입력/출력 노드에서 태깅 및 중재 매카니즘 | |
| KR100657256B1 (ko) | 중재기 및 그 중재기를 채용한 버스 시스템 | |
| US8499113B2 (en) | Circuit configurations and method for controlling a data exchange in a circuit configuration | |
| KR890013563A (ko) | 다이렉트 메모리 액세스 제어장치 | |
| CN101283548B (zh) | 在FlexRay通信组件和FlexRay用户之间的用户接口和用于通过这种接口传输消息的方法 | |
| ES2266870T3 (es) | Procedimiento para la transmision de telegramas de datos en un sistema de comunicacion ciclico conmutado. | |
| ES2255625T3 (es) | Procedimiento para el funcionamiento de un sistema de comunicacion ciclico isocrono. | |
| US8285902B2 (en) | Data transfer apparatus and data transfer method | |
| ES2266579T3 (es) | Procedimiento para el acceso a una unidad de instruccion para una red de datos. | |
| JP5815660B2 (ja) | 数値制御システム | |
| ES2240808T3 (es) | Procedimiento para la creacion de una tabla adinamica de direcciones para un nodo de acoplamiento en una red de datos y procedimiento para la transmision de un telegrama de datos. |