ES2371064T3 - Método y sistema de gestión de eventos. - Google Patents

Método y sistema de gestión de eventos. Download PDF

Info

Publication number
ES2371064T3
ES2371064T3 ES03291397T ES03291397T ES2371064T3 ES 2371064 T3 ES2371064 T3 ES 2371064T3 ES 03291397 T ES03291397 T ES 03291397T ES 03291397 T ES03291397 T ES 03291397T ES 2371064 T3 ES2371064 T3 ES 2371064T3
Authority
ES
Spain
Prior art keywords
management
memory
management unit
event
events
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
Application number
ES03291397T
Other languages
English (en)
Inventor
Philippe Vazeille
Jean-Pierre Bourgoin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
MBDA France SAS
Original Assignee
MBDA France SAS
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by MBDA France SAS filed Critical MBDA France SAS
Application granted granted Critical
Publication of ES2371064T3 publication Critical patent/ES2371064T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/54—Indexing scheme relating to G06F9/54
    • G06F2209/543—Local

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Multimedia (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Multi Processors (AREA)
  • Selective Calling Equipment (AREA)
  • Programmable Controllers (AREA)

Abstract

Procedimiento de gestión de los eventos, en un sistema informático estándar que incluye una unidad central de proceso (10) conectada a unas unidades de memoria (20) y unos periféricos (30, 40) mediante un bus de información (50) que permite un montaje multimaestro, que comprende las siguientes etapas: - recibir los eventos, - fechar y almacenar esos eventos, - asignar a cada evento recibido al menos una acción apropiada, - ejecutar esa acción como respuesta al evento recibido, caracterizado porque las antedichas etapas de gestión se realizan en tiempo real sin acceder a la unidad central de proceso (10), mediante una unidad de gestión (70) comprendida en un módulo de gestión (60) independiente enlazado con el bus de información (50) e implantado en el sistema informático estándar, fechándose cada evento recibido por medio de un reloj de fechado (71) comprendido en la unidad de gestión (70) y almacenándose éste, por una parte, en una primera memoria (73) asociada a la unidad de gestión (70) y, por otra parte, en una segunda memoria (74) asociada a la unidad de gestión (70) con su fecha de llegada, siendo procesados los eventos almacenados en dicha primera memoria (73) de una manera síncrona y siendo leída dicha acción asignada al evento recibido de una tabla de las acciones en una memoria RAM (61) asociada a la unidad de gestión (70) y preprogramada a través del bus de información (50).

Description

Metodo y sistema de gesti6n de eventos.
Antecedentes de la invenci6n
La presente invenci6n concierne a la gesti6n de los eventos en un sistema informatico estandar que incluye una unidad central de proceso conectada a unas unidades de memoria y unos perifericos mediante un bus de informaci6n que permite un montaje multimaestro.
La gesti6n de determinados procesos precisa tomar en cuenta la detecci6n de parametros y el envio de las apropiadas instrucciones de mando en tiempo real o en un tiempo extremadamente corto del orden del microsegundo (Is). Se da con este tipo de aplicaci6n en el ambito aeronautico o espacial o en la gesti6n de determinados procesos industriales.
Existen sistemas de gesti6n en tiempo real basados en controladores l6gicos programables. El inconveniente de estos controladores l6gicos es sus escasas potencias de procesamiento y, sobre todo, sus incompatibilidades con las redes informaticas convencionales. En efecto, la condici6n especifica de los sistemas basados en los controladores l6gicos no permite conectar estos sistemas a una red informatica de arquitectura estandar.
Por otro lado, en un sistema informatico estandar, por ejemplo basado en un microordenador, equipado con canales de comunicaci6n o buses rapidos de informaci6n (por ejemplo, el bus PCI) y pilotado por un sistema operativo multitarea (por ejemplo Windows NT), no es posible la gesti6n en tiempo real entre diferentes unidades del sistema informatico.
La figura 13 muestra de una forma muy esquematica un sistema informatico estandar que incluye una unidad central de proceso 10 pilotada mediante un reloj, por ejemplo a 10 MHz (no representado), una unidad de memoria 20 y unos perifericos 30, 40, a los que se anade un entorno de soporte l6gico o sistema operativo necesario para el procesamiento de la informaci6n. La unidad central de proceso 10 es la encargada del gobierno y las operaciones aritmeticas y l6gicas. La unidad de memoria 20 comprende tanto memoria RAM 21 como memoria ROM 23, en tanto que los perifericos comprenden interfaces de entrada y de salida. Los intercambios de datos, de direcciones, de senales de control y de sincronizaci6n entre las diferentes unidades del sistema informatico se operan en virtud de un bus de informaci6n 50.
En un sistema informatico estandar de este tipo, equipado con un sistema operativo llamado «de tiempo real», no se ha previsto nada para procesar de forma precisa y rapida la llegada de senales discretas o de datos por el bus de informaci6n 50. Esta clase de sistema operativo tan s6lo permite un dialogo entre la unidad central de proceso y otra unidad y con tiempos de respuesta del orden del milisegundo (ms), que son inadaptados para procesos que incluyen parametros importantes y muy sensibles como en el ambito aeronautico y espacial.
Se conocen otros ejemplos referentes a la gesti6n de los eventos en un sistema informatico por el documento de Halang y col., titulado «High accuracy concurrent event processing in hard real time systems», Real Time Systems, vol. 12, nO. 1, paginas 77 94 (1197), asi como por el documento US5010482.
Objeto y resumen de la invenci6n
La invenci6n tiene por finalidad subsanar estos inconvenientes y a tal efecto propone un procedimiento de gesti6n de los eventos, en un sistema informatico estandar que incluye una unidad central de proceso conectada a unidades de memoria y perifericos mediante un bus de informaci6n que permite un montaje multimaestro.
El procedimiento comprende las siguientes etapas:
recibir los eventos,
fechar y almacenar esos eventos,
asignar a cada evento recibido al menos una acci6n apropiada,
ejecutar esa acci6n como respuesta al evento recibido,
de modo que las antedichas etapas de gesti6n se realizan en tiempo real sin acceder a la unidad central de proceso, mediante una unidad de gesti6n comprendida en un m6dulo de gesti6n independiente enlazado con el bus de informaci6n e implantado en el sistema informatico estandar, fechandose cada evento recibido por medio de un reloj de fechado comprendido en la unidad de gesti6n y almacenandose este, por una parte, en una primera memoria asociada a la unidad de gesti6n y, por otra parte, en una segunda memoria asociada a la unidad de gesti6n con su fecha de llegada, siendo procesados los eventos almacenados en dicha primera memoria de una manera sincrona y siendo leida dicha acci6n asignada al evento recibido de una tabla de las acciones en una memoria RAM asociada a la unidad de gesti6n y preprogramada a traves del bus de informaci6n.
Asi, un sistema informatico estandar se transforma en un sistema de tiempo real mediante la implantaci6n de un unico m6dulo de gesti6n adicional.
La llegada de un evento, su fechado y su memorizaci6n son del orden de dos ciclos de reloj de fechado a 10 MHz, la busqueda de la acci6n en la memoria RAM es del orden de diez ciclos de reloj de sincronizaci6n a 33 MHz, la preparaci6n del procesamiento es del orden de dos ciclos de reloj de sincronizaci6n a 33 MHz y la ejecuci6n de la acci6n es del orden de 5 ciclos de reloj de sincronizaci6n a 33 MHz, de modo que la gesti6n en tiempo real es del orden de un microsegundo.
Preferentemente, el m6dulo de gesti6n independiente esta aislado de la unidad central de proceso mediante un puente.
La acci6n que ha de ejecutarse se lee de una tabla de las acciones asociada a la unidad de gesti6n y es preprogramada a traves del bus de informaci6n.
Los eventos recibidos por la unidad de gesti6n pueden ser generados por un registro de reloj interno al m6dulo de gesti6n, por una unidad adyacente al m6dulo de gesti6n o por un equipo exterior al sistema informatico.
Los eventos recibidos por la unidad de gesti6n son sincronizados a una frecuencia correspondiente a la de un reloj interno al sistema informatico.
Segun un modo particular de la invenci6n, los eventos recibidos del equipo exterior se filtran con el fin de eliminar ocasionales parasitos.
Ventajosamente, se genera una interrupci6n mediante la unidad de gesti6n cuando no se puede asociar un evento a una acci6n.
La invenci6n tiene tambien por finalidad proveer un m6dulo de gesti6n de los eventos implantado en un sistema informatico estandar que incluye una unidad central de proceso conectada a unidades de memoria y perifericos mediante un bus de informaci6n que permite un montaje multimaestro, dicho m6dulo comprende:
una unidad de gesti6n independiente, enlazada a traves de una interfaz con la unidad central de proceso por intermedio del bus de informaci6n, estando destinada dicha unidad de gesti6n a recibir y a procesar esos eventos en tiempo real sin la mediaci6n de la unidad central de proceso,
un reloj de fechado destinado a fechar esos eventos antes de almacenarlos, por una parte, en una primera memoria interna a la unidad de gesti6n y, por otra parte, en una segunda memoria (74) interna a la unidad de gesti6n (70) con su fecha de llegada, siendo procesados por la unidad de gesti6n (70) de una manera sincrona los eventos almacenados en dicha primera memoria (73), y
una memoria RAM que comprende una tabla de las acciones preprogramada, asociada a la unidad de gesti6n, destinada a asignar acciones apropiadas a los eventos recibidos por esta ultima.
El bus de informaci6n es un bus estandarizado del tipo elegido de entre un bus PCI, un bus VME, un bus compacto PCI, un bus USB.
Ventajosamente, las memorias primera y segunda son del tipo FIFO y la memoria RAM que comprende la tabla de las acciones es una memoria RAM de doble puerto.
Breve descripci6n de los dibujos
Otras particularidades y ventajas del procedimiento y del sistema segun la invenci6n se desprenderan de la lectura de la descripci6n que a continuaci6n se hace, a titulo indicativo pero no limitativo, haciendo referencia a los dibujos que se acompanan, en los que:
La figura 1 es una vista muy esquematica de un m6dulo de gesti6n de los eventos, segun la invenci6n, implantado en un sistema informatico estandar;
la figura 2 es una vista muy esquematica de un m6dulo de gesti6n de los eventos, segun la invenci6n, implantado en un sistema informatico estandar de una arquitectura basada en un bus de informaci6n de tipo PCI;
la figura 3 es un esquema detallado de un m6dulo de gesti6n de los eventos de las figuras 1 y 2;
la figura 4 muestra las diferentes zonas de una palabra almacenada en una tabla de las acciones segun la invenci6n;
la figura 5 es un organigrama que muestra el desarrollo general de un proceso de gesti6n de los eventos segun la invenci6n;
la figura 6 es un organigrama que muestra un proceso de detecci6n de los eventos segun la figura 5;
E03291397 03-11-2011
la figura 7 es una variante de la figura 6;
la figura 8 es un organigrama que muestra un proceso de procesamiento de los eventos segun la figura 5;
la figura 9 ilustra un ejemplo de gesti6n de un evento procedente de un registro de reloj interno segun la invenci6n;
la figura 10 muestra unas palabras almacenadas en una tabla de las acciones segun el ejemplo de la figura 9;
la figura 11 ilustra un ejemplo de gesti6n de un evento externo segun la invenci6n;
la figura 12 muestra unas palabras almacenadas en una tabla de las acciones segun el ejemplo de la figura 11; y
la figura 13 es una vista muy esquematica de un sistema informatico estandar segun la tecnica anterior.
Descripci6n detallada de las formas de realizaci6n
La figura 1 muestra de forma muy esquematica la implantaci6n de un m6dulo de gesti6n 60 de los eventos, segun la invenci6n, en un sistema informatico estandar. El m6dulo de gesti6n 60 esta enlazado con la unidad central de proceso 10 a traves de un bus de informaci6n 50 que admite un montaje multimaestro o multiprocesador que permite asi, al m6dulo de gesti6n 60, operar por separado y de una manera independiente de la unidad central de proceso
10. En esta ocasi6n, el bus de informaci6n 50 es un bus estandarizado del tipo PCI, VME, compacto PCI o USB. Asi, la implantaci6n del m6dulo de gesti6n 60 transforma el sistema informatico estandar en un sistema informatico de tiempo real.
La figura 2 es, en efecto, un ejemplo de un m6dulo de gesti6n 60 de los eventos, implantado en un sistema informatico estandar de una arquitectura basada en un bus de informaci6n 50 de tipo PCI. El bus PCI es un bus sincrono que soporta una multiplexaci6n de datos, de direcciones y de senales y que permite un montaje multimaestro. Ademas, las especificaciones del bus PCI capacitan la interconexi6n y el empleo de pasarelas o puentes. Esta figura muestra que las unidades de memoria 20, perifericos 30, 40 asi como el m6dulo de gesti6n 60 estan instalados en cascada, respectivamente a traves de los puentes 55, 56, 57. Los puentes desempenan la funci6n de filtros para las unidades a las que no concierne el dialogo de la unidad central de proceso. Asi, el puente 57 permite aislar mejor el m6dulo de gesti6n 60 de la unidad central de proceso 10 cuando el primero esta en dialogo con otras unidades electr6nicas.
La figura 3 muestra de manera mas detallada el m6dulo de gesti6n 60 de los eventos de las figuras 1 y 2. Este m6dulo comprende una unidad de gesti6n 70, pilotada por un reloj de sincronizaci6n, por ejemplo a una frecuencia de 33 MHz. Esta unidad de gesti6n 70 esta destinada a recibir eventos 80 y a ejecutar correspondientes acciones 90 en tiempo real y sin la mediaci6n de la unidad central de proceso. A cada evento recibido se le asigna al menos una acci6n apropiada. Para ello, la unidad de gesti6n 70 esta en enlace con una memoria RAM 61, por ejemplo de tipo RAM doble puerto, accesible en lectura y en escritura. Por supuesto, la unidad de gesti6n 70 se halla conectada al bus de informaci6n 50 a traves de una interfaz estandar 63 que facilita el intercambio de datos con este bus de informaci6n 50. Por otro lado, el m6dulo de gesti6n 60 incluye una pluralidad de registros de reloj o contadores internos, no representados en la figura y que pueden encontrarse en la unidad de gesti6n 70 o en la interfaz 63. A titulo de ejemplo, el m6dulo de gesti6n 60 incluye dieciseis registros de reloj de 20 bits temporizados al milisegundo.
Con caracter general, un evento 80 esta definido por una senal de disparo que identifica el evento y eventualmente por un vector o puntero que indica a la unidad de gesti6n 70 la direcci6n de la acci6n o de las acciones correspondientes que han de ejecutarse.
Por otro lado, la unidad de gesti6n 70 incluye un reloj de fechado 71, por ejemplo de una frecuencia de 10 MHz que permite asi fechar un evento 80 con una precisi6n de la centena de nanosegundo.
Este reloj de fechado 71 puede estar constituido a partir de un primer registro de 16 bits y de un segundo registro de 32 bits. El primer registro realiza una base de tiempos intermedia a 1 milisegundo y a continuaci6n pilota el segundo registro con esta base de tiempos, de modo que un evento 80 puede ser fechado durante 232.10�3 = 4,3.106 segundos.
Ademas, la unidad de gesti6n 70 esta asociada a una primera memoria 73 y a una segunda memoria 74 destinadas a almacenar los eventos 80 recibidos. Preferentemente, las memorias primera 73 y segunda 74 son internas a la unidad de gesti6n 70.
A titulo de ejemplo, la primera memoria 73 es del tipo «primero en entrar, primero en salir o FIFO» de 256 palabras de 16 bits que guarda los eventos que quedan por procesar por orden cronol6gico.
La segunda memoria 74 puede estar constituida a partir de dos zonas de memoria de tipo FIFO accesibles independientemente. Una primera zona de memoria esta destinada a almacenar fechas en milisegundos y una segunda zona de memoria esta destinada a almacenar los eventos.
E03291397 03-11-2011
La primera zona de memoria de los milisegundos se compone, por ejemplo, de 256 palabras de 32 bits que representan la fecha, en milisegundos, de la llegada del evento. La segunda zona de memoria de los eventos se compone, por ejemplo, de 256 palabras de 32 bits, de modo que los ocho bits mas significativos permiten conocer el origen del evento, representando los siguientes ocho bits el numero del vector que ha producido el evento y representando los dieciseis bits menos significativos el tiempo en centenas de nanosegundo.
De conformidad con la invenci6n, la memoria RAM 61 comprende una tabla de las acciones que memoriza palabras que definen la acci6n en funci6n del evento. La figura 4 es un ejemplo que muestra las diferentes zonas de una palabra 610 de 32 bits de la tabla de acci6n. Los ocho bits mas significativos corresponden a un vector de entrada 611 asociado al evento, los siguientes tres bits representan la acci6n 612 correspondiente, los siguientes ocho bits representan un vector de salida 613 asociado a la acci6n seguida de un complemento 614 de cinco bits, los siguientes cuatro bits representan una senal de salida 615 y, por ultimo, los cuatro bits menos significativos representan el numero 616 de un registro de reloj.
Se hace notar que la tabla de las acciones se inicializa o escribe antes de la puesta en marcha del procesamiento de los eventos, a traves del bus de informaci6n 50, y puede ser leida en todo momento a traves del mismo bus.
Se describira a continuaci6n un procedimiento de gesti6n de los eventos, segun la invenci6n, haciendo referencia a las figuras 5 a 8 ademas de a la figura 3.
La figura 5 es un organigrama que muestra el desarrollo general del proceso de gesti6n de los eventos que comprende fases de detecci6n, de procesamiento y de observaci6n de esos eventos.
En la etapa 100, se senala un evento 80 mediante una senal de disparo que puede provenir ya sea del exterior del sistema informatico, ya sea a traves del bus de informaci6n 50 mediante la escritura de un dato procedente de una unidad adyacente a la unidad de gesti6n 70, o bien de un registro de reloj interno al m6dulo de gesti6n 60.
En la etapa 200, el evento es detectado por la unidad de gesti6n 70 y es fechado con una precisi6n del orden de 100 nanosegundos, en virtud del reloj de fechado 71. El evento recibido se almacena, por una parte, en la primera memoria 73 (etapa 260) y, por otra parte, en la segunda memoria 74 con su fecha de llegada (etapa 270).
En la etapa 300, se procesan de una manera sincrona los eventos almacenados en la primera memoria interna 73. A continuaci6n, en la etapa 340, se ejecuta la acci6n despues de una lectura de la tabla de las acciones de la memoria RAM 61. La acci6n puede estar destinada a un registro de reloj, al bus de informaci6n, a un generador de senales o a una interfaz de entrada salida.
En general, la gesti6n en tiempo real del evento es menor o igual que aproximadamente un microsegundo. A titulo de ejemplo, la llegada de un evento, su fechado y su memorizaci6n corresponden a 2 ciclos de reloj de fechado a 10 MHz, es decir, a 200 nanosegundos. La busqueda de la acci6n en la memoria RAM 61 de doble puerto corresponde a 10 ciclos de reloj de sincronizaci6n a 33 MHz, es decir, a 303 nanosegundos. La preparaci6n del procesamiento corresponde a 2 ciclos de reloj de sincronizaci6n a 33 MHz, es decir, a 60,6 nanosegundos. Y la ejecuci6n de la acci6n, en el caso de una arquitectura de bus PCI en modo maestro, corresponde a 5 ciclos de reloj de sincronizaci6n a 33 MHz, es decir, a 151,5 nanosegundos. Asi, en este ejemplo, el tiempo global de respuesta es de 715,1 nanosegundos y, por tanto, inferior a 1 microsegundo.
En la etapa 400, los eventos almacenados en la segunda memoria interna 74 pueden ser observados a traves del bus de informaci6n 50 (etapa 450) de una manera en si conocida, por mediaci6n del entorno de soporte l6gico del sistema informatico estandar. Asi, es posible controlar y remontarse en el historial de esos eventos.
La figura 6 muestra de forma mas detallada el proceso de detecci6n de los eventos. De manera independiente, la naturaleza del evento recibido puede estar constituida a partir de una senal de disparo interna (etapa 110), de una senal de disparo externa (etapa 120), de una senal de disparo con un vector asociado procedente del bus de informaci6n (etapa 130) o de una senal de disparo externa con un vector asociado (etapa 140). Se hace notar que se eliminan, por ejemplo de forma aleatoria, ocasionales conflictos entre diferentes eventos simultaneos.
La senal de disparo interna (etapa 110) puede resultar de un registro de reloj interno al m6dulo de gesti6n 60 y que desencadena senales a intervalos de tiempo preprogramados. Estos intervalos de tiempo pueden ser regulares, con el fin de permitir que la unidad de gesti6n 70 emita una orden de emisi6n de datos de forma ciclica y determinista. La unidad de gesti6n puede decidir la puesta en marcha o la parada de estos registros. Por otro lado, los registros de reloj pueden tener un funcionamiento automatico.
Se hace notar que, al estar ya sincronizada la senal procedente de un registro de reloj interno, entonces se pasa directamente una etapa 250 despues de la recepci6n de esta senal.
Ademas, los eventos recibidos en las etapas 120, 130 y 140 se sincronizan nuevamente a la frecuencia del reloj interno del sistema informatico, respectivamente en las etapas 221, 231 y 241 antes de ir a la etapa 250. Esta frecuencia de nueva sincronizaci6n es, por ejemplo, del orden de 10 MHz.
E03291397 03-11-2011
En la siguiente etapa 250, a cada evento recibido por el reloj de fechado 71 se le asigna una fecha de llegada, con la precisi6n de la centena de nanosegundo.
En la etapa 255, los eventos son identificados por la unidad de gesti6n 70 y, en su caso, autovectorizados, es decir, se reservan vectores para ser asociados, por una parte, a las senales externas que no incluyen vectores y, por otra parte, a las senales procedentes de los registros de reloj interno. A continuaci6n, en las etapas 260 y 270, se almacenan los registros.
En la etapa 260, el evento que incluye un dato correspondiente a la senal de disparo o de identificaci6n 261 asi como un dato correspondiente al vector asociado 262 se almacena en la primera memoria interna 73.
En la etapa 270, el evento que incluye un dato correspondiente a la senal de disparo o de identificaci6n 271, un dato correspondiente al vector asociado 272 asi como un dato correspondiente a la fecha de llegada 273 se almacena en la segunda memoria interna 74.
Se hace notar que, cuando la primera memoria 73 y/o la segunda memoria 74 estan llenas, se genera una interrupci6n por parte de la unidad de gesti6n 70 hacia la unidad central de proceso 10, a traves del bus de informaci6n 50, con el fin de senalar una ocasional perdida de uno o varios eventos detectados. Es de destacar que esta interrupci6n es el unico enlace, en tiempo real, con la unidad central de proceso.
Como variante, mediante la figura 7 se ilustra otro proceso de detecci6n. Se distingue este de aquel de la figura 6 en que, despues de las nuevas sincronizaciones de las etapas 221 y 241, los eventos externos son filtrados respectivamente en las etapas 222 y 242 antes de ir a la etapa 250. Asi, para una mejor seguridad, los eventos externos son filtrados, mediante filtros en si conocidos, con el fin de eliminar los ocasionales parasitos procedentes de los perifericos vecinos. En cambio, el filtrado conlleva una perdida de algunos microsegundos y, consecuentemente, un aumento del tiempo de respuesta.
La figura 8 muestra de forma mas detallada el proceso de procesamiento de los eventos.
En caso de estar presentes uno o varios eventos en la primera memoria interna 73, el proceso de procesamiento se desencadena en la etapa 310.
En la etapa 320, los vectores o los autovectores asociados a los eventos que estan almacenados en la primera memoria interna 73 se leen de manera secuencial.
A continuaci6n, en la etapa 330, se busca en la tabla de las acciones el vector asociado al evento recibido en primer lugar. Si el vector indica que ya no quedan mas acciones por ejecutar, entonces se regresa a la etapa 310 de inicio. Por otro lado, si no se encuentra el vector en la tabla de las acciones, una interrupci6n es generada y tambien se regresa a la etapa 310 de inicio. En cambio, si se encuentra el vector, la acci6n o las acciones asociadas se ejecutan en la etapa 340.
Asi, en funcionamiento normal, es decir, a excepci6n de en una eventual interrupci6n, la unidad central de proceso no interviene en el proceso de detecci6n y de procesamiento del evento. Por consecuencia, una acci6n se ejecuta como respuesta a un evento en un tiempo de respuesta muy rapido del orden de un microsegundo.
Por otro lado, la unidad central de proceso sirve por ejemplo para inicializar los registros de reloj o para iniciar la unidad de gesti6n. Una vez que se terminan las inicializaciones, la unidad central de proceso deja de intervenir en el proceso de gesti6n de los eventos y, asi, puede ser empleada en cualesquiera otras tareas.
Las figuras 9 y 10 ilustran un ejemplo de gesti6n de un evento procedente de un registro de reloj interno.
En efecto, la figura 9 ilustra de forma muy esquematica un sistema informatico segun la invenci6n, que incluye una unidad central de proceso 10 enlazada a traves de un bus de informaci6n 50 con un m6dulo de gesti6n 60 y con una unidad de interfaz digital 85, por ejemplo una tarjeta de tipo 1553, relacionada digitalmente con un equipo externo
87. Por otro lado, dos registros de reloj 64 y 65 numerados «0» y «1» forman parte del m6dulo de gesti6n 60. Por supuesto, el numero de registros de reloj no se limita a dos.
Al principio, la unidad central de proceso 10 inicializa los registros de reloj 64 y 65 («0» y «1») a 100 milisegundos, inicia la unidad de gesti6n 70 del m6dulo de gesti6n 60 e inicializa la unidad de interfaz digital 85, a traves del bus de informaci6n 50.
Cuando el registro de reloj 64 numero «0» llega al termino de su conteo, genera un evento «E0» que primero pone en parada el registro «0» y que a continuaci6n arranca un segundo registro de reloj 65 numero «1». A continuaci6n, la unidad de gesti6n 70 escribe por ejemplo el dato «55», a traves del bus de informaci6n 50, en la unidad de interfaz digital 85, que provoca la emisi6n de datos hacia el equipo externo 87.
El procedimiento antes descrito puede estar codificado de la forma ilustrada mediante la tabla de las acciones representada en la figura 10.
E03291397 03-11-2011
La primera linea indica que, a la recepci6n del vector de entrada 611 «E0 = 11100000», la acci6n 612 «010» detiene el registro de reloj 64 numero «0».
La segunda linea indica que la acci6n 612 «011» arranca el registro de reloj 65 numero «1».
En la tercera linea, la acci6n 612 «000», indicativa de una escritura a traves del bus de informaci6n 50, se ejecuta escribiendo el vector de salida 613 «55» con un complemento 614 «00000», en la direcci6n contenida en un registro «direcci6n 1», de la unidad de interfaz digital 85, indicado por la senal de salida 615 «0000».
La siguiente linea que contiene el vector de entrada 611 «FF = 11111111» indica a la unidad de gesti6n 70 que ya no quedan mas acciones por ejecutar para el vector de entrada 611 «E0 ».
Las figuras 11 y 12 ilustran un ejemplo de gesti6n de un evento externo. Este ejemplo concierne a una supervisi6n de un determinado umbral de tensi6n predeterminado de un equipo externo.
En efecto, la figura 11 ilustra de forma muy esquematica un m6dulo informatico segun la invenci6n, que incluye una unidad central de proceso 10, un sistema de gesti6n 60, una unidad de adquisici6n anal6gica 89 y una unidad de interfaz digital 85, por ejemplo una tarjeta del tipo 1553. Estas distintas unidades se hallan enlazadas entre si a traves del bus de informaci6n 50. Las unidades de adquisici6n anal6gica 89 y de interfaz digital 85 estan relacionadas con un equipo externo 87. La unidad de adquisici6n anal6gica 89 supervisa el nivel de tensi6n del equipo externo 87, cuyo unico enlace con el m6dulo de gesti6n 60 es un enlace digital a traves de la unidad de interfaz digital 85.
La unidad central de proceso 10 inicia la unidad de gesti6n 70 del m6dulo de gesti6n 60, solicita a la unidad de interfaz digital 85 que envie al equipo 87 un mensaje de inicio de generaci6n y, por ultimo, solicita a la unidad de adquisici6n anal6gica 89 que empiece una supervisi6n (flecha 88) de la tensi6n del equipo externo 87. A partir de ese momento, la unidad central de proceso 10 deja de intervenir en la gesti6n de los eventos.
Cuando la tensi6n del equipo 87 sobrepasa el umbral fijado, la unidad de adquisici6n anal6gica 89 genera (flecha 82) una senal de disparo y un vector asociado, por ejemplo el vector «11», a la unidad de gesti6n 70. A su vez, la unidad de gesti6n 70 va a sondear la tabla de las acciones y a escribir un dato, por ejemplo «22», en la unidad de interfaz digital 85. Como consecuencia de la recepci6n del vector «22», la unidad de interfaz digital 85 va a emitir (flecha 92) una orden al equipo externo 87 para estabilizar la tensi6n.
El procedimiento antes descrito puede estar codificado de la forma ilustrada mediante la tabla de las acciones representada en la figura 12.
A la recepci6n del evento en el vector de entrada 611 «11», la acci6n 612 «000», indicativa de una escritura a traves del bus de informaci6n 50, se ejecuta escribiendo el vector de salida 613 «22» con un complemento 614 «00000», en la direcci6n contenida en el registro «direcci6n 1», de la unidad de interfaz digital 85, indicado por la senal de salida 615 «0000».
La siguiente linea que contiene el vector de entrada 611 «FF» indica a la unidad de gesti6n 70 que ya no quedan mas acciones por ejecutar para el vector de entrada «E0».
E03291397 03-11-2011

Claims (13)

  1. REIVINDICACIONES
    1. Procedimiento de gesti6n de los eventos, en un sistema informatico estandar que incluye una unidad central de proceso (10) conectada a unas unidades de memoria (20) y unos perifericos (30, 40) mediante un bus de informaci6n (50) que permite un montaje multimaestro, que comprende las siguientes etapas:
    recibir los eventos,
    fechar y almacenar esos eventos,
    asignar a cada evento recibido al menos una acci6n apropiada,
    ejecutar esa acci6n como respuesta al evento recibido,
    caracterizado porque las antedichas etapas de gesti6n se realizan en tiempo real sin acceder a la unidad central de proceso (10), mediante una unidad de gesti6n (70) comprendida en un m6dulo de gesti6n (60) independiente enlazado con el bus de informaci6n (50) e implantado en el sistema informatico estandar, fechandose cada evento recibido por medio de un reloj de fechado (71) comprendido en la unidad de gesti6n (70) y almacenandose este, por una parte, en una primera memoria (73) asociada a la unidad de gesti6n (70) y, por otra parte, en una segunda memoria (74) asociada a la unidad de gesti6n (70) con su fecha de llegada, siendo procesados los eventos almacenados en dicha primera memoria (73) de una manera sincrona y siendo leida dicha acci6n asignada al evento recibido de una tabla de las acciones en una memoria RAM (61) asociada a la unidad de gesti6n (70) y preprogramada a traves del bus de informaci6n (50).
  2. 2.
    Procedimiento de gesti6n segun la reivindicaci6n 1, caracterizado porque la llegada de un evento, su fechado y su memorizaci6n son del orden de dos ciclos de reloj de fechado a 10 MHz, la busqueda de la acci6n en la memoria RAM (61) es del orden de diez ciclos de reloj de sincronizaci6n a 33 MHz, la preparaci6n del procesamiento es del orden de dos ciclos de reloj de sincronizaci6n a 33 MHz y la ejecuci6n de la acci6n es del orden de 5 ciclos de reloj de sincronizaci6n a 33 MHz, de modo que la gesti6n en tiempo real es del orden de un microsegundo.
  3. 3.
    Procedimiento de gesti6n segun una cualquiera de las reivindicaciones 1 y 2, caracterizado porque el m6dulo de gesti6n (60) independiente esta aislado de la unidad central de proceso (10) mediante un puente (57).
  4. 4.
    Procedimiento de gesti6n segun una cualquiera de las reivindicaciones 1 a 3, caracterizado porque los eventos recibidos por la unidad de gesti6n (70) son generados por un registro de reloj (64, 65) interno al m6dulo de gesti6n (60).
  5. 5.
    Procedimiento de gesti6n segun una cualquiera de las reivindicaciones 1 a 3, caracterizado porque los eventos recibidos por la unidad de gesti6n (70) provienen de una unidad adyacente (89) al m6dulo de gesti6n (60).
  6. 6.
    Procedimiento de gesti6n segun una cualquiera de las reivindicaciones 1 a 3, caracterizado porque los eventos recibidos por la unidad de gesti6n (70) provienen de un equipo (87) exterior al sistema informatico.
  7. 7.
    Procedimiento de gesti6n segun una cualquiera de las reivindicaciones 5 y 6, caracterizado porque los eventos recibidos por la unidad de gesti6n (70) son sincronizados a una frecuencia correspondiente a la de un reloj interno al sistema informatico.
  8. 8.
    Procedimiento de gesti6n segun una cualquiera de las reivindicaciones 6 y 7, caracterizado porque los eventos recibidos del equipo exterior (87) se filtran con el fin de eliminar ocasionales parasitos.
  9. 9.
    Procedimiento de gesti6n segun una cualquiera de las reivindicaciones 1 a 8, caracterizado porque se genera una interrupci6n mediante la unidad de gesti6n (70) cuando no se puede asociar un evento a una acci6n.
  10. 10.
    M6dulo de gesti6n de los eventos, implantado en un sistema informatico estandar que incluye una unidad central de proceso (10) conectada a unas unidades de memoria (20) y unos perifericos (30, 40) mediante un bus de informaci6n (50) que permite un montaje multimaestro, caracterizado porque comprende:
    una unidad de gesti6n (70) independiente, enlazada a traves de una interfaz (63) con la unidad central de proceso (10) por intermedio del bus de informaci6n (50), estando destinada dicha unidad de gesti6n (70) a recibir y a procesar esos eventos en tiempo real sin la mediaci6n de la unidad central de proceso (10),
    un reloj de fechado (71) destinado a fechar esos eventos antes de almacenarlos, por una parte, en una primera memoria (73) interna a la unidad de gesti6n y, por otra parte, en una segunda memoria (74) interna a la unidad de gesti6n (70) con su fecha de llegada, siendo procesados por la unidad de gesti6n (70) de una manera sincrona los eventos almacenados en dicha primera memoria (73), y
    una memoria RAM (61) que comprende una tabla de las acciones preprogramada a traves del bus de informaci6n (50), asociada a la unidad de gesti6n (70), destinada a asignar acciones apropiadas a los eventos recibidos por esta ultima.
  11. 11.
    M6dulo de gesti6n segun la reivindicaci6n 11, caracterizado porque el bus de informaci6n (50) es un bus estandarizado del tipo elegido de entre un bus PCI, un bus VME, un bus compacto PCI, un bus USB.
  12. 12.
    M6dulo de gesti6n segun una cualquiera de las reivindicaciones 10 y 11, caracterizado porque las memorias primera (73) y segunda (74) son del tipo FIFO.
  13. 13.
    M6dulo de gesti6n segun la reivindicaci6n 10, caracterizado porque la memoria RAM (61) que comprende la tabla de las acciones es una memoria RAM de doble puerto.
ES03291397T 2002-06-12 2003-06-12 Método y sistema de gestión de eventos. Expired - Lifetime ES2371064T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0207188 2002-06-12
FR0207188A FR2841013B1 (fr) 2002-06-12 2002-06-12 Procede et systeme de gestion des evenements

Publications (1)

Publication Number Publication Date
ES2371064T3 true ES2371064T3 (es) 2011-12-27

Family

ID=29559143

Family Applications (1)

Application Number Title Priority Date Filing Date
ES03291397T Expired - Lifetime ES2371064T3 (es) 2002-06-12 2003-06-12 Método y sistema de gestión de eventos.

Country Status (8)

Country Link
US (1) US7788680B2 (es)
EP (1) EP1372074B1 (es)
JP (1) JP2005529429A (es)
AT (1) ATE520078T1 (es)
ES (1) ES2371064T3 (es)
FR (1) FR2841013B1 (es)
IL (1) IL165702A (es)
WO (1) WO2003107185A1 (es)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2906881B1 (fr) * 2006-10-05 2009-01-30 Mbda France Sa Procede de controle fonctionnel d'une centrale inertielle d'un mobile.
DE102008013075A1 (de) * 2008-03-06 2009-09-24 Hilscher Gesellschaft für Systemautomation mbH Speicherprogrammierbare Steuerung mit flexibler Kommunikations- und Steuerungsstruktur und Verfahren zu deren Konfiguration
JP5319375B2 (ja) * 2009-04-14 2013-10-16 オリンパス株式会社 無線通信端末および無線ネットワークの接続設定方法
US9665973B2 (en) * 2012-11-20 2017-05-30 Intel Corporation Depth buffering
CN103885376A (zh) * 2012-12-19 2014-06-25 施耐德电器工业公司 可编程逻辑控制器及其事件驱动编程方法
US9542347B2 (en) 2013-03-16 2017-01-10 Intel Corporation Host interface crossbar for sensor hub
US9430414B2 (en) 2013-03-16 2016-08-30 Intel Corporation Bus independent platform for sensor hub peripherals to provide coalescing of multiple reports
US9639432B2 (en) * 2014-12-01 2017-05-02 Citrix Systems, Inc. Live rollback for a computing environment

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4538235A (en) * 1982-08-19 1985-08-27 Rockwell International Corporation Microcomputer retriggerable interval counter
US5010482A (en) * 1987-07-02 1991-04-23 Unisys Corp. Multi-event mechanism for queuing happened events for a large data processing system
US5321837A (en) * 1991-10-11 1994-06-14 International Business Machines Corporation Event handling mechanism having a process and an action association process
US5522058A (en) * 1992-08-11 1996-05-28 Kabushiki Kaisha Toshiba Distributed shared-memory multiprocessor system with reduced traffic on shared bus
JPH06208460A (ja) * 1993-01-11 1994-07-26 Hitachi Ltd マイクロプログラムメモリ制御方式
IL112660A (en) * 1994-03-31 1998-01-04 Minnesota Mining & Mfg System integrating active and simulated decision- making processes
US5666514A (en) * 1994-07-01 1997-09-09 Board Of Trustees Of The Leland Stanford Junior University Cache memory containing extra status bits to indicate memory regions where logging of data should occur
US5737240A (en) * 1996-01-25 1998-04-07 International Business Machines Corporation Programmable hardware mailbox message technique and system
EP0942367A2 (en) * 1998-03-10 1999-09-15 Lucent Technologies Inc. Context controller having context-specific event selection mechanism and processor employing the same
US20020152185A1 (en) * 2001-01-03 2002-10-17 Sasken Communication Technologies Limited Method of network modeling and predictive event-correlation in a communication system by the use of contextual fuzzy cognitive maps
US7185078B2 (en) * 2001-06-28 2007-02-27 Microsoft Corporation Event manager for a control management system
JP2003067201A (ja) * 2001-08-30 2003-03-07 Hitachi Ltd コントローラとオペレーティングシステム
AU2003219504A1 (en) * 2002-04-10 2003-10-27 System Development & Industries Ltd. System on chip for digital control of electronic power devices
US6639538B1 (en) * 2002-05-14 2003-10-28 Sri International Real-time transient pulse monitoring system and method

Also Published As

Publication number Publication date
IL165702A (en) 2011-03-31
US7788680B2 (en) 2010-08-31
JP2005529429A (ja) 2005-09-29
EP1372074B1 (fr) 2011-08-10
EP1372074A1 (fr) 2003-12-17
WO2003107185A1 (fr) 2003-12-24
FR2841013A1 (fr) 2003-12-19
FR2841013B1 (fr) 2004-09-03
ATE520078T1 (de) 2011-08-15
IL165702A0 (en) 2006-01-15
US20050229181A1 (en) 2005-10-13

Similar Documents

Publication Publication Date Title
US4698753A (en) Multiprocessor interface device
ES2371064T3 (es) Método y sistema de gestión de eventos.
EP0840953A1 (en) Configurable integrated circuit pins
US10078568B1 (en) Debugging a computing device
US20180275990A1 (en) Control module for multiple mixed-signal resources management
CN107710179A (zh) 具有多个sdio单元的多址单sdio接口
CN107771330A (zh) 具有多个sdio单元的单个sdio接口
EP0377455B1 (en) Test mode switching system for LSI
KR937000906A (ko) 프로그램 가능 신호 처리기 아키텍쳐
JPH0628528A (ja) Ｉｃカード用インターフェース回路
CN107771328A (zh) 具有多个sdio单元的单中继sdio接口
KR0177197B1 (ko) 시스템 상호접속을 위한 주사 프로그램가능한 검사 행렬
US6483753B1 (en) Endianess independent memory interface
US6141775A (en) Status information collection/control arrangement for communication system
KR100261154B1 (ko) 직접 메모리 액세스 제어 장치
KR100368333B1 (ko) 회로제품의이력정보관리방법
WO1996029656A1 (en) Interprocessor communications system
SU1654826A1 (ru) Устройство дл контрол последовательностей сигналов
SU682900A1 (ru) Устройство дл сопр жени каналов ввода-вывода с оперативной пам тью
SU1615719A1 (ru) Устройство дл обслуживани запросов
RU2032214C1 (ru) Контроллер обмена
SU1179434A1 (ru) Буферное запоминающее устройство
SU1068711A1 (ru) Устройство дл регистрации и контрол измер емых параметров
ES2251881B2 (es) Lector-recuperador de muñequeras, para control de accesos.
SU1513440A1 (ru) Настраиваемое логическое устройство