Client/Server-Systeme werden vielfach zur dezentralen Überwachung und auch zur Steuerung technischer Anlagen, wie beispielsweise Fertigungsanlagen, oder Anlagen der Gebäudeleittechnik, eingesetzt. Die jeweilige technische Anlage ist dabei üblicher- weise mit einer Datenerfassungseinheit ausgestattet, beispielsweise einer speicherpro- grammierbaren Steuerung (SPS), die in der Anlage eintretende Ereignisse und Alarme erfasst und an einen Leitrechner übermittelt. Der Leitrechner befindet sich in der Regel räumlich in der Nähe der Anlage und ist durch ein Bussystem mit der Datenerfassungs- einheit verbunden. Der Leitrechner verfügt unter anderem über eine Datenbank, in der ein aktuelles Abbild des Zustandes der Anlage enthalten ist, und über eine Ereignisliste, in der die von der Datenerfassungseinheit übermittelten Ereignisse, insbesondere Zustandsänderungen, eingetragen und gespeichert werden. Der Leitrechner fungiert als Server, der über eine Kommunikationsverbindung, beispielsweise über das Internet, Daten mit einem oder mehreren Clients austauscht, die sich räumlich getrennt vom Server befinden.

Der Client verfügt über eine Applikation, die als Schnittstelle zum Bediener fungiert, und mit deren Hilfe die technische Anlage überwacht und gesteuert werden kann. Eine wesentliche Aufgabe eines solchen Client/Server-Systems besteht darin, in der Anlage eintretende Ereignisse möglichst schnell zur Applikation des Clients (Client-Anwen- dung) zu übertragen.

In üblichen Kommunikationsnetzwerken, die auf dem Anfrage-Antwort-Modell basieren, wie beispielsweise dem Internet, hat der Server keine Möglichkeit, von sich aus aktiv Nachrichten an den Client zu senden. Deshalb ist er nicht in der Lage, Ereignisse spontan zu einem oder mehreren Clients zu übertragen. Bei herkömmlichen Client/Server-Systemen stellt der jeweilige Client Anfragen zur Ereignisübermittlung an den Server, woraufhin der Server die Ereignisse übermittelt, die seit der letzten Anfrage eingetreten sind. Dieses Verfahren erfüllt nicht die Anforderungen an eine Ereignisüber- tragung, bei welcher der Server aktiv die Clients über eintretende Ereignisse benach- richtigen muss.

Aufgabe der Erfindung ist es, ein Verfahren und ein System zur Verwaltung und Über- tragung von Ereignissen von einem Server zu einem Client zu schaffen, bei dem die Datenübertragung aus Sicht des Clients durch den Server initiiert erfolgt.

Die Aufgabe wird erfindungsgemäß durch ein Verfahren mit den im Anspruch 1 ange- gebenen Merkmalen gelöst. Ein entsprechendes System und vorteilhafte Ausgestal- tungen sind in weiteren Ansprüchen und in der Figurenbeschreibung angegeben.

Das erfindungsgemäße Verfahren sieht vor, dass für jedes Ereignis, das von einem Server über eine Kommunikationsverbindung zu einem Client, beziehungsweise einer Client-Anwendung, zu übertragen ist, eine Registrierung des Ereignisses mittels eines Client-Ereignisdienstes und eines Server-Ereignisdienstes vorgenommen wird. Es werden nur die Ereignisse vom Server zum Client übertragen, für die eine Registrierung vorgenommen wurde. Durch eine solche Ereignisregistrierung findet jeweils eine Aktu- alisierung, beziehungsweise durch die erste Registrierung eine Initialisierung, des Client/Server-Systems statt. Tritt ein Ereignis ein, so wird es zunächst einer Anlagen- schnittstelle des Servers gemeldet. Wurde für das betreffende Ereignis eine Registrie- rung vorgenommen, so wird es von der Anlagenschnittstelle an den Server-Ereignis- dienst übergeben. Der Client-Ereignisdienst stellt, beispielsweise periodisch, über die Kommunikationsverbindung Anfragen zur Ereignisübermittlung an den Server-Ereig- nisdienst. Liegt ein vom Server-Ereignisdienst erfasstes Ereignis vor, so wird es auf- grund der eingegangenen Anfrage über die Kommunikationsverbindung zum Client- Ereignisdienst übertragen. Innerhalb des Clients überträgt der Client-Ereignisdienst empfangene Ereignisse zur Client-Anwendung, wo das Ereignis beispielsweise zur Meldung gebracht wird, indem ein das Ereignis beschreibender Eintrag in einer Ereig- nisliste erzeugt wird. Somit sind zur Übertragung eines eingetretenes Ereignis zur Client-Anwendung keine aktive Anfragen der Client-Anwendung nötig. Da die Client- Anwendung nicht mit dem Server sondern nur mit dem Client-Ereignisdienst konnmuni- ziert, ist sie vom Server unabhängig. Mit Hilfe des Verfahrens geschieht die Ereignis- behandlung aus Sicht der Client-Anwendung wie in einer lokalen Umgebung.

Eine Anwendung des erfindungsgemäßen Verfahrens liegt beispielsweise in der Über- wachung technischer Anlagen. Zu übertragende Ereignisse werden in diesem Fall von der Datenerfassungseinheit einer zu überwachenden technischen Anlage erfasst und an die Anlagenschnittstelle des Servers gemeldet.

In einer vorteilhaften Ausgestaltung der Erfindung registriert die Client-Anwendung für jedes Ereignis, über das sie zu benachrichtigen ist, beim Client-Ereignisdienst eine entsprechende Client-Rückruffunktion. Der Client-Ereignisdienst registriert daraufhin über die Kommunikationsverbindung eine entsprechende Server-Rückruffunktion beim Server-Ereignisdienst. Diese Registrierung wird für jedes Ereignis, über das die Client- Anwendung zu benachrichtigen ist, separat durchgeführt. Auf diese Weise ist es möglich, alle Ereignisse unabhängig voneinander zu behandeln.

Vorteilhafterweise wird verfahrensvorbereitend eine Zuordnung, beispielsweise in Form einer Liste, vorgenommen, so dass anhand dieser Zuordnung jedem in der Anlage möglicherweise auftretenden Ereignis ein eindeutiger Name zugeordnet wird. Diese Zuordnung ist im Client und im Server vorhanden. Somit ist sichergestellt, dass im Client und im Server jedem Ereignis der gleiche Name zugeordnet ist. Zur Registrierung der Rückruffunktionen ruft die Client-Anwendung eine Client-Registrierungsfunktion des Client-Ereignisdienstes auf und übergibt ihr den Namen des betreffenden Ereignisses und einen Zeiger auf die zu registrierende Client-Rückruffunktion. Die Client-Registrie- rungsfunktion generiert daraufhin eine eindeutige Ereigniskennung und übermittelt diese Ereigniskennung zusammen mit dem Ereignisnamen über die Kommunikations- verbindung an eine Server-Registrierungsfunktion des Server-Ereignisdienstes. Die Server-Registrierungsfunktion registriert bei der Anlagenschnittstelle eine Server-Rück- ruffunktion durch Übergabe des Ereignisnamens. Daraufhin speichert die Server-Regi- strierungsfunktion einen Datensatz, der die Ereigniskennung, einen Zeiger auf die zu registrierende Server-Rückruffunktion und gegebenenfalls weitere Daten, wie beispiels- weise den Ereignisnamen, enthält, in einer Server-Ereignistabelle. Anschließend meldet die Server-Registrierungsfunktion die Durchführung der Registrierung über die Kommu- nikationsverbindung zurück an die Client-Registrierungsfunktion des Client-Ereignis- dienstes. Daraufhin registriert die Client-Registrierungsfunktion die Client-Rückruf- funktion, indem sie einen Datensatz, der die Ereigniskennung, einen Zeiger auf die zu registrierende Client-Rückruffunktion und gegebenenfalls weitere Daten, wie beispiels- weise den Ereignisnamen, enthält, in einer Client-Ereignistabelle speichert.

Von Vorteil ist es, wenn die Client-Registrierungsfunktion nach der erstmaligen Regi- strierung einer Client-Rückruffunktion einen Anfragegenerator des Client-Ereignisdien- stes startet. Der Anfragegenerator stellt ab diesem Zeitpunkt Anfragen zur Ereignisüber- mittlung an den Server-Ereignisdienst. Dadurch ist sichergestellt, dass beim Server- Ereignisdienst nur Anfragen von Clients eintreffen, für die auch Ereignisse registriert sind.

Ein weiterer Vorteil ist es, dass der Anfragegenerator die Anfragen zur Ereignisüber- mittlung an den Server-Ereignisdienst zyklisch stellt. Die Zykluszeit ist dabei variabel und kann somit an die jeweiligen Bedingungen angepasst werden.

In einer vorteilhaften Ausgestaltung läuft die Übertragung von Ereignissen in mehreren Schritten ab. Dabei erfasst zunächst die Anlagenschnittstelle das eingetretene Ereignis und ruft die für dieses Ereignis registrierte Server-Rückruffunktion des Server-Ereignis- dienstes auf. Daraufhin erzeugt die Server-Rückruffunktion einen das Ereignis beschrei- benden Eintrag in einer Ereigniswarteschlange. Da für jeden Client, der mit dem Server kommuniziert, eine eigene Ereigniswarteschlange angelegt ist, wird der Eintrag gegebe- nenfalls in mehreren Ereigniswarteschlangen erzeugt, sofern mehrere Clients für dieses Ereignis eine Rückruffunktion registriert haben. Bei der nächsten Anfrage des Client- Ereignisdienstes zur Ereignisübermittlung liest der Server-Ereignisdienst den erzeugten Eintrag aus der dem Client zugeordneten Ereigniswarteschlange aus und übermittelt ihn über die Kommunikationsverbindung an den Client-Ereignisdienst. Der Client-Ereignis- dienst ermittelt aus dem vom Server-Ereignisdienst erhaltenen Eintrag die für dieses Ereignis registrierte Client-Rückruffunktion und ruft diese auf. Die Client-Rückruffunktion führt anschließend in der Client-Anwendung eine Aktion aus, die für das entsprechende.

Ereignis definiert ist, beispielsweise wird ein Eintrag in einer Ereignisliste erzeugt oder es erfolgt eine Anzeige in einer graphischen Darstellung.

In einer vorteilhaften Ausgestaltung der Erfindung wird fakultativ eine Aufräumfunktion des Server-Ereignisdienstes aufgerufen, welche die Kommunikation mit dem Client- Ereignisdienst überwacht. Werden von einem Client-Ereignisdienst über einen vorgebbaren Zeitraum keine Anfragen mehr übermittelt, so erkennt die Aufräumfunk- tion, dass der Client nicht mehr mit dem Server kommuniziert, und löscht daraufhin die Server-Ereignistabelle und die Ereigniswarteschlange. Auf diese Weise wird sicher- gestellt, dass nicht benötigte Ressourcen, insbesondere Speicherplatz, wieder frei- gegeben werden. Im Normalbetrieb meldet der Client-Ereignisdienst alle Ereignis- behandlungen ab bevor er die Kommunikation mit dem Server-Ereignisdienst beendet, wodurch die Ressourcen automatisch freigegeben werden. Aufgabe der Aufräumfunk- tion ist es, Ressourcen freizugeben, wenn keine Abmeldung von Ereignisbehandlungen stattgefunden hat, beispielsweise nach einem Ausfall des Clients oder einem unvorher- gesehenen Verbindungsabbruch. Die Aufräumfunktion kann beispielsweise von einem Benutzer bei Bedarf aufgerufen werden, oder sie kann automatisch zu festlegbaren Zeiten, beispielsweise einmal täglich, aufgerufen werden. Eine effiziente Methode besteht darin, bei Zugriffen auf Funktionen des Server-Ereignisdienstes, beispielsweise der Server-Registrierungsfunktion, zusätzlich automatisch die Aufräumfunktion auf- zurufen.

Des weiteren betrifft die Erfindung ein System zur Verwaltung und Übertragung von Ereignissen von einem Server über eine Kommunikationsverbindung zu einem Client.

Der Client, zu dem die Ereignisse der Anlage übertragen werden, weist zur Registrie- rung möglicher Ereignisse mindestens einen Client-Ereignisdienst auf, der über die Kommunikationsverbindung, beispielsweise das Internet oder ein internes Netzwerk, Anfragen zur Ereignisübermittlung an einen Server-Ereignisdienst stellt. Weiterhin überträgt der Ctient-Ereignisdienst empfangene Ereignisse an eine Client-Anwendung.

Ein Einsatz des erfindungsgemäßen Systems liegt beispielsweise in der Überwachung technischer Anlagen. Zu diesem Zweck steht die Anlagenschnittstelle des Servers mit einer Datenerfassungseinheit einer technischen Anlage in Verbindung, um von der Datenerfassungseinheit erfasste Ereignisse einzulesen.

Gemäß einer vorteilhaften Ausgestaltung verfügt der Server-Ereignisdienst über eine oder mehrere Server-Rückruffunktionen, die jeweils für mindestens ein Ereignis registrierbar sind. Eine Server-Rückruffunktion wird bei Eintritt des Ereignisses, für das sie registriert ist, von der Anlagenschnittstelle aufgerufen.

Gemäß einer vorteilhaften Weiterbildung der Erfindung besitzt der Server-Ereignisdienst mindestens eine Server-Registrierungsfunktion zur Registrierung von Server-Rückruf- funktionen, mindestens eine Server-Ereignistabelle zur Aufnahme von Datensätzen, die jeweils eine Registrierung beschreiben, und mindestens eine Ereigniswarteschlange zur Aufnahme von Einträgen, die jeweils ein Ereignis beschreiben.

Von Vorteil ist auch, dass der Server-Ereignisdienst für jeden Client-Ereignisdienst, mit dem er über die Kommunikationsverbindung kommuniziert, einen separaten Client- Datensatz aufweist, der jeweils mindestens eine Server-Ereignistabelle und eine Ereigniswarteschlange enthält. Das heißt, dass für jeden Client, der mindestens eine Server-Rückruffunktion registriert hat, ein separater Client-Datensatz angelegt ist, in dem die Server-Ereignistabelle und die Ereigniswarteschlange zusammengefasst sind.

In einer vorteilhaften Ausgestaltung der Erfindung weist der Server-Ereignisdienst eine Aufräumfunktion auf, die alle vorhandenen Client-Datensätze und die Kommunikation mit den zugehörigen Client-Ereignisdiensten überwacht. Werden von einem Client- Ereignisdienst über einen vorgebbaren Zeitraum keine Anfragen mehr übermittelt, so erkennt die Aufräumfunktion, dass der zugehörige Client nicht mehr mit dem Server kommuniziert, und löscht daraufhin den zugehörigen Client-Datensatz. Auf diese Weise wird sichergestellt, dass nicht benötigte Ressourcen, insbesondere Speicherplatz, wieder freigegeben werden.

Eine vorteilhafte Ausführungsform der Erfindung sieht vor, dass die in einem Client- Datensatz enthaltene Server-Ereignistabelle als Hash-Tabelle ausgeführt ist. Sie nimmt Datensätze auf, die mindestens eine Ereigniskennung und einen Zeiger auf die zu registrierende Server-Rückruffunktion enthalten. Optional können in den Datensätzen weitere Daten, beispielsweise der Ereignisname, vorhanden sein. Eine Hash-Tabelle bietet den Vorteil, dass beispielsweise mit der Ereigniskennung als Schlüssel ein sehr effizienter Zugriff auf den zugehörigen Datensatz möglich wird, insbesondere bei einer großen Anzahl zu verwaltender Tabelleneinträge. Die Verwendung anderer Daten- strukturen wie Bäume, lineare Listen oder einfache Arrays ist ebenfalls möglich.

Vorteilhafterweise besitzt der Client mindestens eine Client-Rückruffunktion, die für mindestens ein Ereignis registrierbar ist und die bei Eintritt des Ereignisses, für das sie registriert ist, aufgerufen wird. Die Client-Rückruffunktion benachrichtigt die Client- Anwendung über ein in der Anlage eingetretenes Ereignis.

In diesem Zusammenhang ist es auch von Vorteil, dass der Client-Ereignisdienst mindestens eine Client-Registrierungsfunktion zur Registrierung von einer oder mehreren Client-Rückruffunktionen besitzt. Weiterhin besitzt er eine Client-Ereignis- tabelle zur Aufnahme von Datensätzen, welche die Registrierung beschreiben, und einen Anfragegenerator zur Durchführung von zyklischen Anfragen an einen oder mehrere Server-Ereignisdienste zur Ereignisübermittiung.

Eine vorteilhafte Ausführungsform der Erfindung sieht vor, dass auch die Client- Ereignistabelle als Hash-Tabelle ausgeführt ist. Sie nimmt Datensätze auf, die mindestens eine Ereigniskennung und einen Zeiger auf die zu registrierende Client- Rückruffunktion enthalten. Optional können in den Datensätzen weitere Daten, beispielsweise der Ereignisname, vorhanden sein.

Anhand nachfolgender Zeichnungen werden Ausführungsbeispiele und vorteilhafte Ausgestaltungen der Erfindung näher erläutert.

Es zeigen : Fig. 1 ein Verfahren zur An-und Abmeldung einer Ereignisbehandlung und zur Ereignisübertragung anhand eines Sequenzdiagramms, Fig. 2 eine beispielhafte Architektur eines erfindungsgemäßen Client/Server-Systems und Fig. 3 Datenstrukturen zur Speicherung der Daten der Ereignisbehandlung.

In Fig. 1 ist in einem Sequenzdiagramm das Verfahren zur An-und Abmeldung einer Ereignisbehandlung sowie zur Übertragung eingetretener Ereignisse an den Client dargestellt.

Zur Anmeldung einer Ereignisbehandlung ruft eine Client-Anwendung 4 in einem ersten Schritt 101 eine Client-Registrierungsfunktion 61 auf. Diese ruft in einem zweiten Schritt 102 eine Server-Registrierungsfunktion 71 auf, welche daraufhin in einem dritten Schritt 103 eine entsprechende Registrierung in einer Anlagenschnittstelle 10 des Servers veranlasst. Das Ergebnis der Registrierung wird in einem vierten Schritt 104 an die Client-Registrierungsfunktion 61 und von dort in einem fünften Schritt 105 an die Client- Anwendung 4 zurückgesendet. Bei erstmaliger Registrierung eines Ereignisses wird darüber hinaus in einem zusätzlichen Schritt 106 von der Client-Registrierungsfunktion 61 ein Anfragegenerator 63 gestartet.

Der Anfragegenerator 63 läuft parallel zu den anderen clientseitigen Prozessen und sendet zyklisch Anfragen an eine Ereigniswarteschlange 75, beziehungsweise an eine Warteschlangenverwaltung 76. In einem ersten Schritt 107 erfolgt eine solche Anfrage des Anfragegenerators 63, die von der Ereigniswarteschlange 75 in einem zweiten Schritt 108 mit der Übertragung einer Ereignisliste beantwortet wird. Liegt kein zu übertragendes Ereignis vor, so ist diese Ereignisliste leer. Die Frequenz, mit der die zyklischen Anfragen durchgeführt werden, ist vorgebbar. Eine sinnvolle Auslegung muss berücksichtigen, dass die Zyklusdauer entscheidenden Einfluss auf die maximale Verzögerung bei der Benachrichtigung über ein Ereignis hat. Andererseits wird der Server bei kurzen Zyklen durch häufige Anfragen stärker belastet, so dass für die konkrete Situation ein Kompromiss zwischen Server-Belastung und akzeptabler Verzögerungszeit gefunden werden muss. Kommt es zu einem Ereignis, für das eine Registrierung durchgeführt wurde, so ruft die Anlagenschnittstelle 10 in einem dritten Schritt 109 eine registrierte Server-Rückruffunktion 72 auf. Diese erzeugt in einem vierten Schritt 110 einen entsprechenden Eintrag in der Ereigniswarteschlange 75.

Aufgrund der nächsten Anfrage des Anfragegenerators 63 in einem fünften Schritt 111 wird der Eintrag aus der Ereigniswarteschlange 75 ausgelesen und in einem sechsten Schritt 112 an den Anfragegenerator 63 des Clients zurückgeliefert. Der Anfragegenera- tor 63 ruft daraufhin, eventuell über einen Rückrufgenerator 64, in einem siebten Schritt 113 eine registrierte Client-Rückruffunktion 41 der Client-Anwendung 4 auf.

Zur Abmeldung einer Ereignisbehandlung ruft die Client-Anwendung 4 in einem ersten Schritt 114 die Client-Registrierungsfunktion 61 auf. Diese ruft in einem zweiten Schritt 115 die Server-Registrierungsfunktion 71 auf, welche daraufhin in einem dritten Schritt 116 in der Anlagenschnittstelle 10 des Servers eine Entfernung der zuvor erfolgten Registrierung veranlasst. Das Ergebnis der Entfernung der Registrierung wird in einem vierten Schritt 117 an die Client-Registrierungsfunktion 61 und von dort in einem fünften Schritt 118 an die Client-Anwendung 4 zurückgesendet. Wenn für den Client 4 nach Abmeldung einer Ereignisbehandlung keine weiteren Ereignisbehandlungen mehr vorhanden sind, so wird in einem zusätzlichen Schritt 119 der Anfragegenerator 63 gestoppt.

In Fig. 2 ist eine mögliche Architektur des Client/Server-Systems gezeigt.

Das System weist einen Client 1 und einen Server 2 auf, die über eine Kommunika- tionsverbindung 9, beispielsweise das Internet, miteinander kommunizieren.

Der Client 1 weist eine oder mehrere Anwendungen 4, wie beispielsweise Bedienober- flächen oder Anwendungsprogramme zur Anlagensteuerung, auf, welche über die Kommunikationsverbindung 9 mit Server-Applikationen 5 kommunizieren, beispiels- weise um Datenbankabfragen vorzunehmen oder um Steuersignale zu senden.

Gegebenenfalls erfolgt die Kommunikation mit dem Server 2 über einen clientseitigen Stellvertreter (Proxy), so dass die Client-Anwendung 4 nur lokal mit entsprechenden Diensten des Clients 1 kommuniziert. Die Übertragung über das Internet kann beispiels- weise über einen Web-Service oder SOAP-Aufrufe (Simple Object Access Protocol) erfolgen.

Die Client-Anwendung 4 verfügt über mehrere Client-Rückruffunktionen 41, die bei der Anmeldung von Ereignisbehandlungen registrierbar sind und bei Eintritt eines Ereignis- ses aufrufbar sind. Der Client 1 weist weiterhin einen Client-Ereignisdienst 6 auf, der die An-und Abmeldungen von Ereignisbehandlungen für die Client-Anwendung 4 durch- führt, und der von dem Server 2 übermittelte Ereignisse an die Client-Anwendung 4 überträgt.

Der Client-Ereignisdienst 6 verfügt über eine Client-Registrierungsfunktion 61, die von der Client-Anwendung 4 zur Registrierung einer Client-Rückruffunktion 41 aufrufbar ist, und eine Client-Ereignistabelle 62, in welche die Daten der Ereignisbehandlung, wie Ereigniskennung, Ereignisname und Zeiger auf zu registrierende Client-Rückruffunk- tionen 41, eintragbar sind, und-aus welcher diese Daten auslesbar sind. Weiterhin weist der Client-Ereignisdienst 6 einen Anfragegenerator 63 auf, der zyklisch Anfragen zur Ereignisübermittlung an den Server 2 sendet, und der vom Server 2 übermittelte Ereignisse aufnimmt. Zusätzlich verfügt der Client-Ereignisdienst 6 über einen Rück- rufgenerator 64, an den der Anfragegenerator 63 übermittelte Ereignisse weiterleitet, und der die für ein betreffendes Ereignis registrierte Client-Rückruffunktion 41 aufruft.

Der Server 2 verfügt über eine Anlagenschnittstelle 10, die über ein lokales Netzwerk mit einer technischen Anlage 3, beziehungsweise ihrer Datenerfassungseinheit, kommuniziert. Anstelle des lokalen Netzwerkes kann auch eine direkte drahtgebunden Verbindung oder eine Funkverbindung vorhanden sein ; auch eine Kommunikation über ein globales Netzwerk wie das Internet ist möglich. Weiterhin besitzt der Server 2 eine Server-Applikation 5, die beispielsweise als Datenbank aufgebaut ist, und die ein Abbild der zu überwachenden Anlage 3 enthält.

Der Server 2 weist weiterhin einen Server-Ereignisdienst 7 auf, der die An-und Ab- meldungen von Ereignisbehandlungen durchführt, und der von der Anlagenschnittstelle 10 übermittelte Ereignisse über die Kommunikationsverbindung 9 an den Client-Ereig- nisdienst 6 überträgt.

Der Server-Ereignisdienst 7 weist eine Server-Registrierungsfunktion 71 auf, welche über die Kommunikationsverbindung 9 mit der Client-Registrierungsfunktion 61 kommuniziert, und welche die Registrierung von Server-Rückruffunktionen 72 für eintretende Ereignisse sowohl bei der Anlagenschnittstelle 10 als auch bei dem Server- Ereignisdienst 7 durchführt. Zu diesem Zweck weist der Server-Ereignisdienst 7 eine oder mehrere Server-Rückruffunktionen 72 auf, die für eintretende Ereignisse registrier- bar sind, und die bei Eintritt eines Ereignisses aufrufbar sind.

Weiterhin weist der Server-Ereignisdienst 7 für jeden Client, der mit dem Server kom- muniziert, eine Server-Ereignistabelle 74 auf, in welche die Daten der Ereignisbehand- lung, wie Ereignis-Kennung, Ereignisnamen und ein Zeiger auf die zu registrierende Server-Rückruffunktion 72, eintragbar sind. Auch verfügt der Server-Ereignisdienst 7 für jeden Client, der mit dem Server kommuniziert, über eine Ereigniswarteschlange 75, in welche Datensätze,-die eingetretene Ereignisse beschreiben, eintragbar sind.

Die Server-Ereignistabelle 74 und die zugehörige Ereigniswarteschlange 75 bilden je einen Client-Datensatz 73. Alle Client-Datensätze 73 sind in einer Client-Datenbank 78 des Server-Ereignisdienstes 7 zusammengefasst.

Weiterhin besitzt der Server-Ereignisdienst 7 eine Warteschlangenverwaltung 76, welche die Anfragen des Anfragegenerators 63 beantwortet, und welche Einträge aus der Ereigniswarteschlange 75 entnimmt und an den Anfragegenerators 63 übermittelt.

Zusätzlich verfügt der Server-Ereignisdienst 7 über eine Aufräumfunktion 77, welche die Kommunikation mit dem Client-Ereignisdienst 6 überwacht, und welche den Client- Datensatz 73 löscht, wenn der zugehörige Client-Ereignisdienst 6 nicht mehr mit dem Server-Ereignisdienst 7 kommuniziert. Treffen von einem Anfragegenerator 63 über einen vorgebbaren Zeitraum keine Anfragen mehr ein, so erkennt die Aufräumfunktion 77, dass der zugehörige Client 1 nicht mehr mit dem Server 2 kommuniziert, und löscht daraufhin den zugehörigen Client-Datensatz 73. Der besagte Zeitraum ist dabei deutlich größer vorzugeben als die Zykluszeit des Anfragegenerators 63, also der Zeitspanne zwischen zwei Anfragen. Auf diese Weise wird sichergestellt, dass nicht benötigte Ressourcen, insbesondere Speicherplatz, wieder freigegeben werden.

Nachfolgend wird das Verfahren zur Anmeldung einer Ereignisbehandlung anhand des Systems nach Fig. 2 beschrieben. Zur Registrierung einer Client-Rückruffunktion 41 ruft die Client-Anwendung 4 die Client-Registrierungsfunktion 61 des Client-Ereignisdien- stes 6 auf und übergibt einen Zeiger auf die zu registrierende Client-Rückruffunktion 41.

Die Client-Registrierungsfunktion 61 generiert daraufhin eine eindeutige Ereignisken- nung, mit deren Hilfe die Daten der Ereignisbehandlung bei dem Server 2 und dem Client 1 einander zugeordnet werden. Danach leitet die Client-Registrierungsfunktion 61 den Namen des Ereignisses, für das eine Registrierung erfolgen soll, zusammen mit der generierten Ereigniskennung Kommunikationsverbindung 9 an die Server-Registrie- rungsfunktion 71 des Server-Ereignisdienstes 7 weiter. Die Server-Registrierungsfunk- tion 71 registriert eine Server-Rückruffunktion 72 bei der Anlagenschnittstelle 10 durch Übergabe des Ereignisnamens und eines Zeigers auf die Server-Rückruffunktion 72.

Weiterhin speichert die Server-Registrierungsfunktion 71 alle relevanten Daten der Ereignisbehandlung, wie beispielsweise die Ereignis-Kennung, den Ereignisnamen und einen Zeiger auf die Server-Rückruffunktion 72, in der Server-Ereignistabelle 74, die Teil eines für jeden Client in der Client-Datenbank 78 abgelegten Datensatzes 73 ist.

Anschließend sendet die Server-Registrierungsfunktion 71 eine Nachricht über die erfolgreiche Registrierung des Ereignisses an die Client-Registrierungsfunktion 61 zurück. Diese trägt in die Client-Ereignistabelle 62 die Ereigniskennung, den Ereignis- namen und den Zeiger auf die Client-Rückruffunktion 41 ein. Sofern dies nicht bereits zuvor geschehen ist, wird der Anfragegenerator 63 als neuer paralleler Prozess gestartet, der zyklisch Anfragen zur Ereignisübermittlung an die Warteschlangen- verwaltung 76 des Server-Ereignisdienstes 7 sendet. Damit ist die Anmeldung einer Ereignisbehandlung abgeschlossen.

Nachfolgend wird das Verfahren zur Abmeldung einer Ereignisbehandlung anhand des Systems nach Fig. 2 beschrieben. Zum Entfernen einer Ereignisbehandlung ruft die Client-Anwendung 4 die Client-Registrierungsfunktion 61 auf. Die Client-Registrierungs- funktion 61 sendet eine entsprechende Nachricht an die Server-Registrierungsfunktion 71, welche einerseits die Anlagenschnittstelle 10 über die Freigabe der entsprechenden Server-Rückruffunktion 72 benachrichtigt und anschließend den entsprechenden Client- Datensatz 73 aktualisiert. Dazu wird der entsprechende Eintrag aus der Server-Ereig- nistabelle 74 entfernt. Darüber hinaus wird die Ereigniswarteschlange 75 daraufhin überprüft, ob sie noch zu der Ereignisbehandlung gehörige, noch nicht abgefragte Datensätze enthält. Je nach Anwendungsfall ist es dann sinnvoll, die zugehörigen Ereignisdatensätze ebenfalls zu löschen oder sie in der Warteschlange zu belassen, bis sie von dem Anfragegenerator 63 des Client-Ereignisdienstes 6 abgefragt werden. Sind für den Client 1 keine Ereignisbehandlungen mehr in der Server-Ereignistabelle 74 registriert und ist auch die Ereigniswarteschlange 75 leer, so ist es möglich, den gesamten Client-Datensatz 73 zu entfernen. Dies spart einerseits System-Ressourcen, erfordert aber einen höheren Aufwand, um den Datensatz bei Registrierung neuer Ereignisbehandlungen wieder anzulegen. Ist die Entfernung der Ereignisbehandlung im Server-Ereignisdienst 7 abgeschlossen, so sendet die Server-Registrierungsfunktion 71 eine entsprechende Nachricht an die Client-Registrierungsfunktion 61 zurück. Die Client-Registrierungsfunktion 61 entfernt daraufhin den entsprechenden Eintrag aus der Client-Ereignistabelle 62. Ist in der Client-Ereignistabelle 62 kein Ereignis mehr registriert, so ist es sinnvoll, den Anfragegenerator 63 zur zyklischen Anfrage solange zu stoppen, bis wieder neue Ereignisse registriert werden. Um sicherzustellen, dass keine unbehandelten Ereignisse mehr in der Ereigniswarteschlange 75 des Servers 2 vorliegen, wird, bevor der Anfragegenerator 63 gestoppt wird, noch eine letzte Anfrage an die Warteschlangenverwaltung 76 gestellt.

Nachfolgend wird der Ablauf einer Ereignisübermittiung anhand des Systems nach Fig.

2 beschrieben. Von der Datenerfassungseinheit in der Anlage 3 wird ein Ereignis, beispielsweise Überschreiten von Grenzwerten oder Aktivierung von Schaltern oder Sensoren, erfasst, und an die Anlagenschnittstelle 10 gemeldet. Wurde für dieses Ereignis eine Server-Rückruffunktion 72 registriert, so ruft die Anlagenschnittstelle 10 die registrierte Server-Rückruffunktion 72 auf und übergibt als Parameter den Ereignis- namen. Die Server-Rückruffunktion 72 entnimmt den Server-Ereignistabellen 74 der verschiedenen Client-Datensätze 73 die dem betreffenden Ereignisnamen zugeord- neten Ereigniskennungen und schreibt je einen das Ereignis beschreibenden Datensatz in die Ereigniswarteschlangen 75 der zugehörigen Client-Datensätze 73. Damit endet die Ausführung der Server-Rückruffunktion 72.

Alternativ wird bei der Ereignisregistrierung für jedes zu registrierende Ereignis eine separate Instanz der Server-Rückruffunktion 72 angelegt, so dass für jeden Eintrag in einer Server-Ereignistabelle 74 eine eigene Rückruffunktion vorhanden ist. In diesem Fall muss der Ereignisname nicht in den Server-Ereignistabellen 74 abgelegt werden. In der Anlagenschnittstelle 10 ist die Zuordnung zwischen Ereignisnamen und Instanz der Server-Rückruffunktion 72 bekannt. Bei Eintritt des Ereignisses ruft die Anlagenschnitt- stelle 10 die dem Ereignisnamen zugeordnete Instanz der Server-Rückruffunktion 72 auf, ohne den Ereignisnamen als Parameter zu übergeben. Diese Instanz der Server- Rückruffunktion 72 entnimmt den Server-Ereignistabellen 74 die zugehörigen Ereignis- kennungen und schreibt einen das Ereignis beschreibenden Datensatz in die Ereignis- warteschlange 75 des zugehörigen Client-Datensatzes 73.

Das Ereignis wird solange in der Ereigniswarteschlange 75 zwischengespeichert, bis die nächste Anfrage des Anfragegenerators 63 an die Warteschlangenverwaltung 76 übermittelt wird. Ist die dem Client 1 zugeordnete Ereigniswarteschlånge 75 leer, so wird eine leere Ereignisliste an den Anfragegenerators 63 zurückgesendet. ist jedoch zuvor, wie oben beschrieben, ein Ereignis eingetreten, so liefert die Warteschlangen- verwaltung 76 eine Liste der zwischenzeitlich eingetretenen Ereignisse an den Anfragegenerator 63 zurück. Jeder Eintrag der Liste enthält die zu dem Ereignis gehörigen Parameter und die ursprünglich von der Client-Registrierungsfunktion 61 erzeugte Ereigniskennung. Die übertragenen Ereignisse werden aus der Ereigniswarte- schlange 75 entfernt. Beim Client-Ereignisdienst 6 wird das Ergebnis der Anfrage des Anfragegenerators 63 von dem Rückrüfgenerator 64 ausgewertet. Der Rückrufgenera- tor 64 entnimmt der Client-Ereignistabelle 62 die der jeweiligen Ereigniskennung zuge- hörige Client-Rückruffunktion 41 und ruft diese Client-Rückruffunktionen 41 mit den Ereignisdaten als Parameter auf.

In Fig. 3 sind systemgemäße Datenstrukturen zur Speicherung der Daten der Ereignis- behandlung auf dem Client 1 und dem Server 2 gezeigt.

Vom Client-Ereignisdienst 6 werden für jede Ereignisbehandlung Datensätze in einer Client-Ereignistabelle 62 gespeichert. Jeder der Datensätze enthält eine Ereignis- kennung, einen Verweis auf die zugehörige Client-Rückruffunktion 41 und optional einen Ereignisnamen. Die Realisierung des Verweises hängt von der konkreten Implementierung, beziehungsweise der verwendeten Programmiersprache ab.

Beispielsweise werden in C/C++ typischerweise Funktionspointer, auch Zeiger genannt, verwendet. Die Client-Ereignistabelle 62 lässt sich auf günstige Weise als Hash-Tabelle realisieren, bei der die Ereigniskennung als Schlüssel verwendet wird.

Dadurch lässt sich beim Eintreffen eines Ereignisses auf effiziente Weise der zugehörige Datensatz auffinden.

Auf dem Server 2 werden für jeden Client 1, der Ereignisbehandlungen registriert hat, Daten gespeichert. Dies kann effizient in einer als Hash-Tabelle realisierten Client- Datenbank 78 erfolgen, über die mit einer ClientlD als Schlüssel zugegriffen wird. Für jeden Client 1 wird ein eigener Client-Datensatz 73 abgelegt, der neben der-ClientlD eine Server-Ereignistabelle 74 und eine Ereigniswarteschlange 75 enthält. Die Server- Ereignistabelle 74 kann analog zu der Client-Ereignistabelle 62 als Hash-Tabelle realisiert werden und enthält entsprechende Datensätze, wobei jedoch als Rückruffunktion ein Verweis auf die Server-Rückruffunktion 72 gespeichert ist. Die Ereigniswarteschlange 75 wird sinnvollerweise als Warteschlangen- (Queue-) Daten- struktur realisiert, wobei die einzelnen Datensätze mindestens die Ereigniskennung und optional weitere Parameter, die das Ereignis näher beschreiben, enthalten.

Bezugszeichenliste 1 : Client 2 : Server 3 : technische Anlage 4 : Client-Anwendung 5 : Server-Applikation 6 : Client-Ereignisdienst 7 : Server-Ereignisdienst 9 : Kommunikationsverbindung 10 : Anlagenschnittstelle 41 : Client-Rückruffunktion 61 : Client-Registrierungsfunktion 62 : Client-Ereignistabelle 63 : Anfragegenerator 64 : Rückrufgenerator 71 : Server-Registrierungsfunktion 72 : Server-Rückruffunktion 73 : Client-Datensatz 74 : Server-Ereignistabelle 75 : Ereigniswarteschlange 76 : Warteschlangenverwaltung 77 : Aufräumfunktion 78 : Client-Datenbank