US20060224699A1 - Methods and system for event transmission - Google Patents

Methods and system for event transmission Download PDF

Info

Publication number
US20060224699A1
US20060224699A1 US10/562,046 US56204604A US2006224699A1 US 20060224699 A1 US20060224699 A1 US 20060224699A1 US 56204604 A US56204604 A US 56204604A US 2006224699 A1 US2006224699 A1 US 2006224699A1
Authority
US
United States
Prior art keywords
event
client
server
service
function
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.)
Granted
Application number
US10/562,046
Other versions
US8005941B2 (en
Inventor
Eckhard Kruse
Zaijun Hu
Yauheni Veryha
Jens Doppelhamer
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.)
ABB Schweiz AG
Original Assignee
ABB Research Ltd Switzerland
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 ABB Research Ltd Switzerland filed Critical ABB Research Ltd Switzerland
Assigned to ABB RESEARCH LTD. reassignment ABB RESEARCH LTD. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: DOPPELHAMER, JENS, HU, ZAIJUN, VERYHA, YAUHENI, KRUSE, ECKHARD
Publication of US20060224699A1 publication Critical patent/US20060224699A1/en
Application granted granted Critical
Publication of US8005941B2 publication Critical patent/US8005941B2/en
Assigned to ABB SCHWEIZ AG reassignment ABB SCHWEIZ AG MERGER (SEE DOCUMENT FOR DETAILS). Assignors: ABB RESEARCH LTD.
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/069Management of faults, events, alarms or notifications using logs of notifications; Post-processing of notifications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/2866Architectures; Arrangements
    • H04L67/2876Pairs of inter-processing entities at each side of the network, e.g. split proxies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/564Enhancement of application control based on intercepted application data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/568Storing data temporarily at an intermediate stage, e.g. caching
    • H04L67/5682Policies or rules for updating, deleting or replacing the stored data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/59Providing operational support to end devices by off-loading in the network or by emulation, e.g. when they are unavailable

Definitions

  • the invention relates to a method and a system for transmitting events in a web-based client/server environment from a server to a client, particularly for transmitting alarm and event messages from a technical installation which is to be monitored.
  • the transmission of an event is to be understood to mean, in particular, the transmission of information which describes an event.
  • Client/server systems are often used for locally monitoring and also for controlling technical installations, such as production installations, or buildings control engineering installations.
  • the respective technical installation is usually equipped with a data capture unit, for example a programmable logic controller (PLC), which detects events and alarms occurring in the installation and transmits them to a control computer.
  • PLC programmable logic controller
  • the control computer is in physical proximity to the installation and is connected to the data capture unit by a bus system.
  • the control computer has, inter alia, a database, which contains an up-to-date map of the state of the installation, and an event list, which is used to enter and store the events, particularly state changes, which have been transmitted by the data capture unit.
  • the control computer acts as a server which uses a communication link, for example the Internet, to interchange data with one or more clients which is/are physically separate from the server.
  • the client has an application which acts as an interface to the operator and which can be used to monitor and control the technical installation. It is a fundamental task of such a client/server system to transmit events occurring in the installation as quickly as possible to the application on the client (client application).
  • the server In ordinary communication networks based on the request/response model, such as the Internet, the server is not able to send messages to the client actively itself. It is therefore not able to transmit events spontaneously to one or more clients.
  • the respective client makes requests for event transmission to the server, whereupon the server transmits the events which have occurred since the last request. This method does not meet the requirements of event transmission where the server must actively notify the clients about events which occur.
  • the event for every event which needs to be transmitted from a server via a communication link to a client, for example a client application, the event is logged using a client event service and a server event service. Only events for which logging has been performed are transmitted from the server to the client. Such event logging prompts a respective update, or the first logging prompts an initialization, of the client/server system.
  • event logging prompts a respective update, or the first logging prompts an initialization, of the client/server system.
  • an event When an event occurs, it is first reported to an installation interface of the server. If the event in question has been logged, it is transferred from the installation interface to the server event service.
  • the client event service uses the communication link to make requests for event transmission to the server event service, for example periodically.
  • the server event service If there is an event which has been detected by the server event service, it is transmitted via the communication link to the client event service on the basis of the received request.
  • the client event service transmits received events to the client application, where the event is reported, for example, by producing an entry which describes the event in an event list. Transmitting an event which has occurred to the client application therefore requires no active requests from the client application. Since the client application does not communicate with the server but rather only with the client event service, it is independent of the server. When the method is used, the client application sees the event handling operation taking place as in a local environment.
  • One application of the inventive method is monitoring technical installations, for example.
  • events which are to be transmitted are detected by the data capture unit of a technical installation which is to be monitored and are reported to the server's installation interface.
  • the client application logs an appropriate client callback function in the client event service for every event about which it is to be notified.
  • the client event service then uses the communication link to log a corresponding server callback function in the server event service.
  • This logging is carried out separately for every event about which the client application is to be notified.
  • an association is made, for example in the form of a list, in preparation for the method, so that this association is used to assign a unique name to every event possibly occurring in the installation. This association exists in the client and in the server. It is thus ensured that every event has the same associated name in the client and in the server.
  • the client application calls a client logging function from the client event service and provides it with the name of the event in question and with a pointer to the client callback function which is to be logged.
  • the client logging function then generates a unique event identifier and transmits this event identifier together with the event name to a server logging function of the server event service via the communication link.
  • the server logging function logs a server callback function with the installation interface by transferring the event name.
  • the server logging function then stores a data record, which contains the event identifier, a pointer to the server callback function which is to be logged and possibly further data, such as the event name, in a server event table.
  • the server logging function uses the communication link to report back to the client logging function of the client event service that the logging operation has been performed.
  • the client logging function then logs the client callback function by storing a data record, which contains the event identifier, a pointer to the client callback function which is to be logged and possibly further data, such as the event name, in a client event table.
  • the client logging function starts a request generator in the client event service. From this time onward, the request generator makes requests for event transmission to the server event service. This ensures that the server event service receives only requests from clients for which events are also logged.
  • a further advantage is that the request generator makes the requests for event transmission to the server event service cyclically.
  • the cycle time is variable and can thus be matched to the respective conditions.
  • events are transmitted in a plurality of steps.
  • the installation interface first of all detects the event which has occurred and calls the server event service's server callback function which is logged for this event.
  • the server callback function then produces an entry which describes the event in an event queue. Since a separate event queue is created for every client which communicates with the server, the entry is possibly produced in a plurality of event queues, if a plurality of clients have logged a callback function for this event.
  • the server event service reads the entry produced from the event queue associated with the client and transmits it to the client event service via the communication link.
  • the client event service takes the entry received from the server event service and ascertains and calls the client callback function logged for this event.
  • the client callback function then executes a defined action for the corresponding event in the client application, for example an entry is produced in an event list or a display is produced in a graphical representation.
  • a tidying function of the server event service is optionally called which monitors the communication with the client event service. If no more requests are transmitted by a client event service over a prescribable period of time, the tidying function recognizes that the client is no longer communicating with the server, and then deletes the server event table and the event queue. This ensures that unneeded resources, particularly memory space, are released again.
  • the client event service cancels all event handling operations before it terminates communication with the server event service, as a result of which the resources are automatically released. It is the task of the tidying function to release resources when event handling operations have not been cancelled, for example after the client has failed or after unforeseen disconnection.
  • the tidying function can be called by a user as required, for example, or it can be called automatically at stipulatable times, for example once daily.
  • One efficient method involves additionally calling the tidying function automatically when functions of the server event service, for example the server logging function, are accessed.
  • the invention also relates to a system for managing and transmitting events from a server via a communication link to a client.
  • the client to which the events from the installation are transmitted has, for the purpose of logging possible events, at least one client event service which uses the communication link, for example the Internet or an internal network, to make requests for event transmission to a server event service.
  • the client event service transmits received events to a client application.
  • the server's installation interface is connected to a data capture unit of a technical installation in order to read in events detected by the data capture unit.
  • the server event service has one or more server callback functions which can each be logged for at least one event.
  • a server callback function is called by the installation interface when the event for which it is logged occurs.
  • the server event service has at least one server logging function for logging server callback functions, at least one server event table for holding data records which describe a respective log, and at least one event queue for holding entries which describe a respective event.
  • the server event service has, for every client event service with which it communicates via the communication link, a separate client data record which respectively contains at least one server event table and an event queue. That is to say that for every client which has logged at least one server callback function a separate client data record is created in which the server event table and the event queue are combined.
  • the server event service has a tidying function which monitors all the available client data records and the communication with the associated client event services. If a client event service does not transmit any more requests over a prescribable period of time, the tidying function recognizes that the associated client is no longer communicating with the server, and then deletes the associated client data record. This ensures that unneeded resources, particularly memory space, are released again.
  • the server event table contained in a client data record is in the form of a hash table. It holds data records which contain at least one event identifier and a pointer to the server callback function which is to be logged.
  • the data records may contain further data, for example the event name.
  • a hash table affords the advantage that, by way of example, the event identifier can be used as a key for very efficient access to the associated data record, particularly when there are a large number of table entries to be managed. It is likewise possible to use other data structures such as trees, linear lists or simple arrays.
  • the client has at least one client callback function which can be logged for at least one event and which is called when the event for which it is logged occurs.
  • the client callback function notifies the client application about an event which has occurred in the installation.
  • the client event service has at least one client logging function for logging one or more client callback functions.
  • it has a client event table, for holding data records which describe the log, and a request generator for making cyclic requests to one or more server event services for event transmission.
  • the client event table is also in the form of a hash table. It holds data records which contain at least one event identifier and a pointer to the client callback function which is to be logged.
  • the data records may contain further data, for example the event name.
  • FIG. 1 uses a sequence diagram to show a method for registering and cancelling an event handling operation and for event transmission
  • FIG. 2 shows an exemplary architecture for a client/server system based on the invention
  • FIG. 3 shows data structures for storing the data from the event handling operation.
  • FIG. 1 uses a sequence diagram to show the method for registering and cancelling an event handling operation and for transmitting events which have occurred to the client.
  • a client application 4 calls a client logging function 61 .
  • the latter calls a server logging function 71 which, in a third step 103 , then prompts appropriate logging in an installation interface 10 of the server.
  • the result of the logging operation is returned to the client logging function 61 in a fourth step 104 and from there in a fifth step 105 to the client application 4 .
  • the client logging function 61 starts a request generator 63 in an additional step 106 .
  • the request generator 63 runs in parallel with the other processes on the client and cyclically transmits requests to an event queue 75 , or to a queue manager 76 .
  • the request generator 63 makes a request to which the event queue 75 responds in a second step 108 by transmitting an event list. If there is no event to be transmitted, this event list is empty.
  • the frequency with which the cyclic requests are made can be prescribed. An appropriate design needs to take account of the fact that the cycle time has a decisive influence on the maximum delay for notification about an event.
  • the server is loaded to a greater extent by frequent requests when the cycles are short, which means that for the practical situation a compromise needs to be found between server loading and acceptable delay time.
  • the installation interface 10 calls a logged server callback function 72 in a third step 109 .
  • this server callback function produces an appropriate entry in the event queue 75 .
  • the entry is read from the event queue 75 and is returned to the client's request generator 63 in a sixth step 112 .
  • the request generator 63 then calls a logged client callback function 41 from the client application 4 , possibly using a callback generator 64 , in a seventh step 113 .
  • the client application 4 calls the client logging function 61 in a first step 114 .
  • the client logging function 61 calls the server logging function 71 , which then prompts the previous log to be removed from the server's installation interface 10 in a third step 116 .
  • the result of the log being removed is returned to the client logging function 61 in a fourth step 117 and from there to the client application 4 in a fifth step 118 . If there are no further event handling operations for the client 4 after an event handling operation has been cancelled, the request generator 63 is stopped in an additional step 119 .
  • FIG. 2 shows a possible architecture for the client/server system.
  • the system has a client 1 and a server 2 which communicate with one another via a communicate link 9 , for example the Internet.
  • the client 1 has one or more applications 4 , such as user interfaces or application programs for installation control, which use the communication link 9 to communicate with server applications 5 , for example to make database queries or to transmit control signals.
  • applications 4 such as user interfaces or application programs for installation control, which use the communication link 9 to communicate with server applications 5 , for example to make database queries or to transmit control signals.
  • the communication with the server 2 takes place via a representative (proxy) of the client, so that the client application 4 communicates with appropriate services of the client 1 only locally.
  • the transmission via the Internet can take place using a web service or SOAP (Simple Object Access Protocol) calls, for example.
  • SOAP Simple Object Access Protocol
  • the client application 4 has a plurality of client callback functions 41 which can be logged when event handling operations are registered and which can be called when an event occurs.
  • the client 1 also has a client event service 6 which performs the registration and cancellation operations for event handling operations for the client application 4 and which transmits events transmitted by the server 2 to the client application 4 .
  • the client event service 6 has a client logging function 61 , which can be called by the client application 4 in order to log a client callback function 41 , and a client event table 62 into which the data from the event handling operation, such as event identifier, event name and pointer to client callback functions 41 which are to be logged, can be entered and from which these data can be read.
  • the client event service 6 has a request generator 63 which cyclically transmits requests for event transmission to the server 2 and which holds events transmitted by the server 2 .
  • the client event service 6 has a callback generator 64 to which the request generator 63 forwards transmitted events and which calls the client callback function 41 logged for a relevant event.
  • the server 2 has an installation interface 10 which uses a local area network to communicate with a technical installation 3 , for example its data capture unit. Instead of the local area network, there may also be a direct wired link or a radio link; communication via a global network such as the Internet is also possible.
  • the server 2 has a server application 5 which is in the form of a database, for example, and which contains a map of the installation 3 which is to be monitored.
  • the server 2 also has a server event service 7 which performs the registration and cancellation operations for event handing operations and which transmits events transmitted by the installation interface 10 to the client event service 6 via the communication link 9 .
  • the server event service 7 has a server logging function 71 which uses the communication link 9 to communicate with the client logging function 61 and which performs the logging operation for server callback functions 72 for events which occur both for the installation interface 10 and for the server event service 7 .
  • the server event service 7 has one or more server callback functions 72 which can be logged for events which occur and which can be called when an event occurs.
  • the server event service 7 has, for every client which communicates with the server, a server event table 74 into which the data from the event handling operation, such as event identifier, event name and a pointer to the server callback function 72 which is to be logged, can be entered.
  • the server event service 7 also has, for every client which communicates with the server, an event queue 75 into which data records describing events which have occurred can be entered.
  • the server event table 74 and the associated event queue 75 each form a client data record 73 . All the client data records 73 are combined in a client database 78 in the server event service 7 .
  • the server event service 7 also has a queue manager 76 which responds to the requests from the request generator 63 and which takes entries from the event queue 75 and transmits them to the request generator 63 .
  • the server event service 7 has a tidying function 77 which monitors the communication with the client event service 6 and which deletes the client data records 73 if the associated client event service 6 is no longer communicating with the server event service 7 . If no more requests are received from a request generator 63 over a prescribable period of time, the tidying function 77 recognizes that the associated client 1 is no longer communicating with the server 2 , and then deletes the associated client data record 73 . In this case, said period of time can be prescribed to be significantly longer than the cycle time of the request generator 63 , that is to say the period of time between two requests. This ensures that unneeded resources, particularly memory space, are released again.
  • the text below describes the method for registering an event handling operation with reference to the system shown in FIG. 2 .
  • the client application 4 calls the client logging function 61 from the client event service 6 and transfers a pointer to the client callback function 41 which is to be logged.
  • the client logging function 61 then generates a unique event identifier which is used to associate the data from the event handling operation on the server 2 and on the client 1 with one another.
  • the client logging function 61 then forwards the name of the event for which logging is to take place, together with the generated event identifier, to the server logging function 71 of the server event service 7 via the communication link 9 .
  • the server logging function 71 logs a server callback function 72 for the installation interface 10 by transferring the event name and a pointer to the server callback function 72 .
  • the server logging function 71 stores all the relevant data from the event handling operation, such as the event identifier, the event name and a pointer to the server callback function 72 , in the server event table 74 , which is part of a data record 73 stored for every client in the client database 78 .
  • the server logging function 71 returns a message about successful logging of the event to the client logging function 61 .
  • the latter enters the event identifier, the event name and the pointer to the client callback function 41 into the client event table 62 . If this has not already been done beforehand, the request generator 63 is started as a new parallel process which cyclically transmits requests for event transmission to the queue manager 76 of the server event service 7 . This completes the registration of an event handling operation.
  • the text below describes the method for cancelling an event handling operation with reference to the system shown in FIG. 2 .
  • the client application 4 calls the client logging function 61 .
  • the client logging function 61 sends an appropriate message to the server logging function 71 , which firstly notifies the installation interface 10 that the corresponding server callback function 72 has been released and then updates the appropriate client data record 73 .
  • the corresponding entry is removed from the server event table 74 .
  • the event queue 75 is then checked to determine whether it still contains as yet unrequested data records associated with the event handling operation.
  • the server logging function 71 returns an appropriate message to the client logging function 61 .
  • the client logging function 61 then removes the appropriate entry from the client event table 62 .
  • the client event table 62 If the client event table 62 has no more events logged in it, it is appropriate to stop the request generator 63 for cyclic requesting until new evens are logged again. To ensure that there are no more unhandled events in the event queue 75 of the server 2 , a last request to the queue manager 76 is made before the request generator 63 is stopped.
  • the data capture unit in the installation 3 detects an event, for example the exceeding of limit values or the activation of switches or sensors, and reports it to the installation interface 10 . If a server callback function 72 has been logged for this event, the installation interface 10 calls the logged server callback function 72 and transfers the event name as a parameter. From the server event tables 74 for the various client data records 73 , the server callback function 72 takes the event identifiers associated with the relevant event name and writes a respective data record describing the event to the event queues 75 of the associated client data records 73 . This ends execution of the server callback function 72 .
  • an event for example the exceeding of limit values or the activation of switches or sensors
  • a separate instance of the server callback function 72 is created for every event which is to be logged, so that every entry in a server event table 74 has a dedicated callback function.
  • the event, name does not need to be stored in the server event tables 74 .
  • the installation interface 10 the association between event name and instance of the server callback function 72 is known.
  • the installation interface 10 calls that instance of the server callback function 72 which is associated with the event name without transferring the event name as a parameter.
  • This instance of the server callback function 72 takes the associated event identifiers from the server event tables 74 and writes a data record describing the event into the event queue 75 of the associated client data record 73 .
  • the event is buffer-stored in the event queue 75 until the next request from the request generator 63 is transmitted to the queue manager 76 . If the event queue 75 associated with the client 1 is empty, an empty event list is returned to the request generator 63 . If an event has occurred beforehand, as described above, however, the queue manager 76 returns a list of events which have occurred in the meantime to the request generator 63 . Each entry in the list contains the parameters associated with the event and the event identifier originally produced by the client logging function 61 . The transmitted events are removed from the event queue 75 . In the client event service 6 , the result of the request from the request generator 63 is evaluated by the callback generator 64 . The callback generator 64 takes the client callback function 41 associated with the respective event identifier from the client event table 62 and calls these client callback functions 41 using the event data as parameters.
  • FIG. 3 shows system-based data structures for storing the data from the event handling operation on the client 1 and on the server 2 .
  • the client event service 6 stores data records in a client event table 62 for every event handling operation.
  • Each of the data records contains an event identifier, a reference to the associated client callback function 41 and optionally an event name.
  • the realization of the reference is dependent on the specific implementation, or on the programming language used.
  • C/C++ typically uses function pointers.
  • the client event table 62 may advantageously be in the form of a hash table in which the event identifier is used as a key. This means that when an event arrives the associated data record can be found efficiently.
  • the server 2 stores data for every client 1 which has logged event handling operations. This can be done efficiently in a client database 78 which is in the form of a hash table and which is used for access with a client ID as a key.
  • a dedicated client data record 73 is stored which contains a server event table 74 and an event queue 75 in addition to the client ID.
  • the server event table 74 can be in the form of a hash table, in a similar manner to the client event table 62 , and contains appropriate data records, but a reference to the server callback function 72 is stored as a callback function.
  • the event queue 75 is appropriately in the form of a queue data structure, with the individual data records containing at least the event identifier and optionally further parameters which describe the event in more detail.

Abstract

The invention relates to methods and a system for the management and transmission of events from a server to at least one client, by means of a communication connection, whereby the server has at least one server event service, communicating with at least one client, by means of a communication connection and at least one unit interface, communicating with the at least one server event service. The client comprises at least one client event server, communicating with the server, by means of a communication connection. A logging of possible events takes place in both the client event server and the server event service. Incident events are passed from the unit interface to the server event service, the client event service initiates requests to the server event service and, based on a submitted request to the server event service, the recorded events are transmitted to the client event service. Events received from the client event service are transmitted to a client application.

Description

  • The invention relates to a method and a system for transmitting events in a web-based client/server environment from a server to a client, particularly for transmitting alarm and event messages from a technical installation which is to be monitored. In this context and in the text below, the transmission of an event is to be understood to mean, in particular, the transmission of information which describes an event.
  • Client/server systems are often used for locally monitoring and also for controlling technical installations, such as production installations, or buildings control engineering installations. In this context, the respective technical installation is usually equipped with a data capture unit, for example a programmable logic controller (PLC), which detects events and alarms occurring in the installation and transmits them to a control computer. Normally, the control computer is in physical proximity to the installation and is connected to the data capture unit by a bus system. The control computer has, inter alia, a database, which contains an up-to-date map of the state of the installation, and an event list, which is used to enter and store the events, particularly state changes, which have been transmitted by the data capture unit. The control computer acts as a server which uses a communication link, for example the Internet, to interchange data with one or more clients which is/are physically separate from the server.
  • The client has an application which acts as an interface to the operator and which can be used to monitor and control the technical installation. It is a fundamental task of such a client/server system to transmit events occurring in the installation as quickly as possible to the application on the client (client application).
  • In ordinary communication networks based on the request/response model, such as the Internet, the server is not able to send messages to the client actively itself. It is therefore not able to transmit events spontaneously to one or more clients. In conventional client/server systems, the respective client makes requests for event transmission to the server, whereupon the server transmits the events which have occurred since the last request. This method does not meet the requirements of event transmission where the server must actively notify the clients about events which occur.
  • It is an object of the invention to provide a method and a system for managing and transmitting events from a server to a client in which the client sees the data transmission being initiated by the server.
  • The invention achieves the object by means of a method having the features specified in claim 1. A corresponding system and advantageous refinements are specified in further claims and in the description of the figures.
  • In the inventive method, for every event which needs to be transmitted from a server via a communication link to a client, for example a client application, the event is logged using a client event service and a server event service. Only events for which logging has been performed are transmitted from the server to the client. Such event logging prompts a respective update, or the first logging prompts an initialization, of the client/server system. When an event occurs, it is first reported to an installation interface of the server. If the event in question has been logged, it is transferred from the installation interface to the server event service. The client event service uses the communication link to make requests for event transmission to the server event service, for example periodically. If there is an event which has been detected by the server event service, it is transmitted via the communication link to the client event service on the basis of the received request. Within the client, the client event service transmits received events to the client application, where the event is reported, for example, by producing an entry which describes the event in an event list. Transmitting an event which has occurred to the client application therefore requires no active requests from the client application. Since the client application does not communicate with the server but rather only with the client event service, it is independent of the server. When the method is used, the client application sees the event handling operation taking place as in a local environment.
  • One application of the inventive method is monitoring technical installations, for example. In this case, events which are to be transmitted are detected by the data capture unit of a technical installation which is to be monitored and are reported to the server's installation interface.
  • In one advantageous refinement of the invention, the client application logs an appropriate client callback function in the client event service for every event about which it is to be notified. The client event service then uses the communication link to log a corresponding server callback function in the server event service. This logging is carried out separately for every event about which the client application is to be notified. In this way, it is possible to handle all events independently of one another. Advantageously, an association is made, for example in the form of a list, in preparation for the method, so that this association is used to assign a unique name to every event possibly occurring in the installation. This association exists in the client and in the server. It is thus ensured that every event has the same associated name in the client and in the server. To log the callback functions, the client application calls a client logging function from the client event service and provides it with the name of the event in question and with a pointer to the client callback function which is to be logged. The client logging function then generates a unique event identifier and transmits this event identifier together with the event name to a server logging function of the server event service via the communication link. The server logging function logs a server callback function with the installation interface by transferring the event name. The server logging function then stores a data record, which contains the event identifier, a pointer to the server callback function which is to be logged and possibly further data, such as the event name, in a server event table. The server logging function then uses the communication link to report back to the client logging function of the client event service that the logging operation has been performed. The client logging function then logs the client callback function by storing a data record, which contains the event identifier, a pointer to the client callback function which is to be logged and possibly further data, such as the event name, in a client event table.
  • It is advantageous if after a client callback function has been logged for the first time the client logging function starts a request generator in the client event service. From this time onward, the request generator makes requests for event transmission to the server event service. This ensures that the server event service receives only requests from clients for which events are also logged.
  • A further advantage is that the request generator makes the requests for event transmission to the server event service cyclically. In this context, the cycle time is variable and can thus be matched to the respective conditions.
  • In one advantageous refinement, events are transmitted in a plurality of steps. In this case, the installation interface first of all detects the event which has occurred and calls the server event service's server callback function which is logged for this event. The server callback function then produces an entry which describes the event in an event queue. Since a separate event queue is created for every client which communicates with the server, the entry is possibly produced in a plurality of event queues, if a plurality of clients have logged a callback function for this event. When the client event service next requests event transmission, the server event service reads the entry produced from the event queue associated with the client and transmits it to the client event service via the communication link. The client event service takes the entry received from the server event service and ascertains and calls the client callback function logged for this event. The client callback function then executes a defined action for the corresponding event in the client application, for example an entry is produced in an event list or a display is produced in a graphical representation.
  • In one advantageous refinement of the invention, a tidying function of the server event service is optionally called which monitors the communication with the client event service. If no more requests are transmitted by a client event service over a prescribable period of time, the tidying function recognizes that the client is no longer communicating with the server, and then deletes the server event table and the event queue. This ensures that unneeded resources, particularly memory space, are released again. During normal operation, the client event service cancels all event handling operations before it terminates communication with the server event service, as a result of which the resources are automatically released. It is the task of the tidying function to release resources when event handling operations have not been cancelled, for example after the client has failed or after unforeseen disconnection. The tidying function can be called by a user as required, for example, or it can be called automatically at stipulatable times, for example once daily. One efficient method involves additionally calling the tidying function automatically when functions of the server event service, for example the server logging function, are accessed.
  • The invention also relates to a system for managing and transmitting events from a server via a communication link to a client. The client to which the events from the installation are transmitted has, for the purpose of logging possible events, at least one client event service which uses the communication link, for example the Internet or an internal network, to make requests for event transmission to a server event service. In addition, the client event service transmits received events to a client application.
  • One use of the inventive system is monitoring technical installations, for example. To this end, the server's installation interface is connected to a data capture unit of a technical installation in order to read in events detected by the data capture unit.
  • In line with one advantageous refinement, the server event service has one or more server callback functions which can each be logged for at least one event. A server callback function is called by the installation interface when the event for which it is logged occurs.
  • In line with one advantageous development of the invention, the server event service has at least one server logging function for logging server callback functions, at least one server event table for holding data records which describe a respective log, and at least one event queue for holding entries which describe a respective event.
  • Another advantage is that the server event service has, for every client event service with which it communicates via the communication link, a separate client data record which respectively contains at least one server event table and an event queue. That is to say that for every client which has logged at least one server callback function a separate client data record is created in which the server event table and the event queue are combined.
  • In one advantageous refinement of the invention, the server event service has a tidying function which monitors all the available client data records and the communication with the associated client event services. If a client event service does not transmit any more requests over a prescribable period of time, the tidying function recognizes that the associated client is no longer communicating with the server, and then deletes the associated client data record. This ensures that unneeded resources, particularly memory space, are released again.
  • In one advantageous embodiment of the invention, the server event table contained in a client data record is in the form of a hash table. It holds data records which contain at least one event identifier and a pointer to the server callback function which is to be logged. Optionally, the data records may contain further data, for example the event name. A hash table affords the advantage that, by way of example, the event identifier can be used as a key for very efficient access to the associated data record, particularly when there are a large number of table entries to be managed. It is likewise possible to use other data structures such as trees, linear lists or simple arrays.
  • Advantageously, the client has at least one client callback function which can be logged for at least one event and which is called when the event for which it is logged occurs. The client callback function notifies the client application about an event which has occurred in the installation.
  • In this context, it is also advantageous that the client event service has at least one client logging function for logging one or more client callback functions. In addition, it has a client event table, for holding data records which describe the log, and a request generator for making cyclic requests to one or more server event services for event transmission.
  • In one advantageous embodiment of the invention, the client event table is also in the form of a hash table. It holds data records which contain at least one event identifier and a pointer to the client callback function which is to be logged. Optionally, the data records may contain further data, for example the event name.
  • Exemplary embodiments and advantageous refinements of the invention are explained in more detail with reference to the drawings below, in which:
  • FIG. 1 uses a sequence diagram to show a method for registering and cancelling an event handling operation and for event transmission,
  • FIG. 2 shows an exemplary architecture for a client/server system based on the invention, and
  • FIG. 3 shows data structures for storing the data from the event handling operation.
  • FIG. 1 uses a sequence diagram to show the method for registering and cancelling an event handling operation and for transmitting events which have occurred to the client.
  • To register an event handling operation, in a first step 101 a client application 4 calls a client logging function 61. In a second step 102, the latter calls a server logging function 71 which, in a third step 103, then prompts appropriate logging in an installation interface 10 of the server. The result of the logging operation is returned to the client logging function 61 in a fourth step 104 and from there in a fifth step 105 to the client application 4. In addition, the first time that an event is logged, the client logging function 61 starts a request generator 63 in an additional step 106.
  • The request generator 63 runs in parallel with the other processes on the client and cyclically transmits requests to an event queue 75, or to a queue manager 76. In a first step 107, the request generator 63 makes a request to which the event queue 75 responds in a second step 108 by transmitting an event list. If there is no event to be transmitted, this event list is empty. The frequency with which the cyclic requests are made can be prescribed. An appropriate design needs to take account of the fact that the cycle time has a decisive influence on the maximum delay for notification about an event. On the other hand, the server is loaded to a greater extent by frequent requests when the cycles are short, which means that for the practical situation a compromise needs to be found between server loading and acceptable delay time. If an event for which logging has been performed occurs, the installation interface 10 calls a logged server callback function 72 in a third step 109. In a fourth step 110, this server callback function produces an appropriate entry in the event queue 75. On the basis of the next request from the request generator 63 in a fifth step 111, the entry is read from the event queue 75 and is returned to the client's request generator 63 in a sixth step 112. The request generator 63 then calls a logged client callback function 41 from the client application 4, possibly using a callback generator 64, in a seventh step 113.
  • To cancel an event handling operation, the client application 4 calls the client logging function 61 in a first step 114. In a second step 115, the client logging function 61 calls the server logging function 71, which then prompts the previous log to be removed from the server's installation interface 10 in a third step 116. The result of the log being removed is returned to the client logging function 61 in a fourth step 117 and from there to the client application 4 in a fifth step 118. If there are no further event handling operations for the client 4 after an event handling operation has been cancelled, the request generator 63 is stopped in an additional step 119.
  • FIG. 2 shows a possible architecture for the client/server system.
  • The system has a client 1 and a server 2 which communicate with one another via a communicate link 9, for example the Internet.
  • The client 1 has one or more applications 4, such as user interfaces or application programs for installation control, which use the communication link 9 to communicate with server applications 5, for example to make database queries or to transmit control signals. If appropriate, the communication with the server 2 takes place via a representative (proxy) of the client, so that the client application 4 communicates with appropriate services of the client 1 only locally. The transmission via the Internet can take place using a web service or SOAP (Simple Object Access Protocol) calls, for example.
  • The client application 4 has a plurality of client callback functions 41 which can be logged when event handling operations are registered and which can be called when an event occurs. The client 1 also has a client event service 6 which performs the registration and cancellation operations for event handling operations for the client application 4 and which transmits events transmitted by the server 2 to the client application 4.
  • The client event service 6 has a client logging function 61, which can be called by the client application 4 in order to log a client callback function 41, and a client event table 62 into which the data from the event handling operation, such as event identifier, event name and pointer to client callback functions 41 which are to be logged, can be entered and from which these data can be read. In addition, the client event service 6 has a request generator 63 which cyclically transmits requests for event transmission to the server 2 and which holds events transmitted by the server 2. In addition, the client event service 6 has a callback generator 64 to which the request generator 63 forwards transmitted events and which calls the client callback function 41 logged for a relevant event.
  • The server 2 has an installation interface 10 which uses a local area network to communicate with a technical installation 3, for example its data capture unit. Instead of the local area network, there may also be a direct wired link or a radio link; communication via a global network such as the Internet is also possible. In addition, the server 2 has a server application 5 which is in the form of a database, for example, and which contains a map of the installation 3 which is to be monitored.
  • The server 2 also has a server event service 7 which performs the registration and cancellation operations for event handing operations and which transmits events transmitted by the installation interface 10 to the client event service 6 via the communication link 9.
  • The server event service 7 has a server logging function 71 which uses the communication link 9 to communicate with the client logging function 61 and which performs the logging operation for server callback functions 72 for events which occur both for the installation interface 10 and for the server event service 7. For this purpose, the server event service 7 has one or more server callback functions 72 which can be logged for events which occur and which can be called when an event occurs.
  • In addition, the server event service 7 has, for every client which communicates with the server, a server event table 74 into which the data from the event handling operation, such as event identifier, event name and a pointer to the server callback function 72 which is to be logged, can be entered. The server event service 7 also has, for every client which communicates with the server, an event queue 75 into which data records describing events which have occurred can be entered.
  • The server event table 74 and the associated event queue 75 each form a client data record 73. All the client data records 73 are combined in a client database 78 in the server event service 7.
  • The server event service 7 also has a queue manager 76 which responds to the requests from the request generator 63 and which takes entries from the event queue 75 and transmits them to the request generator 63.
  • In addition, the server event service 7 has a tidying function 77 which monitors the communication with the client event service 6 and which deletes the client data records 73 if the associated client event service 6 is no longer communicating with the server event service 7. If no more requests are received from a request generator 63 over a prescribable period of time, the tidying function 77 recognizes that the associated client 1 is no longer communicating with the server 2, and then deletes the associated client data record 73. In this case, said period of time can be prescribed to be significantly longer than the cycle time of the request generator 63, that is to say the period of time between two requests. This ensures that unneeded resources, particularly memory space, are released again.
  • The text below describes the method for registering an event handling operation with reference to the system shown in FIG. 2. To log a client callback function 41, the client application 4 calls the client logging function 61 from the client event service 6 and transfers a pointer to the client callback function 41 which is to be logged. The client logging function 61 then generates a unique event identifier which is used to associate the data from the event handling operation on the server 2 and on the client 1 with one another. The client logging function 61 then forwards the name of the event for which logging is to take place, together with the generated event identifier, to the server logging function 71 of the server event service 7 via the communication link 9. The server logging function 71 logs a server callback function 72 for the installation interface 10 by transferring the event name and a pointer to the server callback function 72.
  • In addition, the server logging function 71 stores all the relevant data from the event handling operation, such as the event identifier, the event name and a pointer to the server callback function 72, in the server event table 74, which is part of a data record 73 stored for every client in the client database 78.
  • Next, the server logging function 71 returns a message about successful logging of the event to the client logging function 61. The latter enters the event identifier, the event name and the pointer to the client callback function 41 into the client event table 62. If this has not already been done beforehand, the request generator 63 is started as a new parallel process which cyclically transmits requests for event transmission to the queue manager 76 of the server event service 7. This completes the registration of an event handling operation.
  • The text below describes the method for cancelling an event handling operation with reference to the system shown in FIG. 2. To remove an event handling operation, the client application 4 calls the client logging function 61. The client logging function 61 sends an appropriate message to the server logging function 71, which firstly notifies the installation interface 10 that the corresponding server callback function 72 has been released and then updates the appropriate client data record 73. To this end, the corresponding entry is removed from the server event table 74. In addition, the event queue 75 is then checked to determine whether it still contains as yet unrequested data records associated with the event handling operation. Depending on the instance of application, it is then appropriate likewise to delete the associated event data records or to leave them in the queue until they are requested by the request generator 63 of the client event service 6. If no more event handling operations are logged in the server event table 74 for the client 1 and if the event queue 75 is also empty, it is possible to remove the entire client data record 73. On the one hand, this saves system resources, but it requires a relatively high level of complexity to create the data record again when new event handling operations are logged. Once the removal of the event handling operation in the server event service 7 is complete, the server logging function 71 returns an appropriate message to the client logging function 61. The client logging function 61 then removes the appropriate entry from the client event table 62. If the client event table 62 has no more events logged in it, it is appropriate to stop the request generator 63 for cyclic requesting until new evens are logged again. To ensure that there are no more unhandled events in the event queue 75 of the server 2, a last request to the queue manager 76 is made before the request generator 63 is stopped.
  • The text below describes the sequence of event transmission with reference to the system shown in
  • FIG. 2. The data capture unit in the installation 3 detects an event, for example the exceeding of limit values or the activation of switches or sensors, and reports it to the installation interface 10. If a server callback function 72 has been logged for this event, the installation interface 10 calls the logged server callback function 72 and transfers the event name as a parameter. From the server event tables 74 for the various client data records 73, the server callback function 72 takes the event identifiers associated with the relevant event name and writes a respective data record describing the event to the event queues 75 of the associated client data records 73. This ends execution of the server callback function 72.
  • Alternatively, during the event logging, a separate instance of the server callback function 72 is created for every event which is to be logged, so that every entry in a server event table 74 has a dedicated callback function. In this case, the event, name does not need to be stored in the server event tables 74. In the installation interface 10, the association between event name and instance of the server callback function 72 is known. When the event occurs, the installation interface 10 calls that instance of the server callback function 72 which is associated with the event name without transferring the event name as a parameter.
  • This instance of the server callback function 72 takes the associated event identifiers from the server event tables 74 and writes a data record describing the event into the event queue 75 of the associated client data record 73.
  • The event is buffer-stored in the event queue 75 until the next request from the request generator 63 is transmitted to the queue manager 76. If the event queue 75 associated with the client 1 is empty, an empty event list is returned to the request generator 63. If an event has occurred beforehand, as described above, however, the queue manager 76 returns a list of events which have occurred in the meantime to the request generator 63. Each entry in the list contains the parameters associated with the event and the event identifier originally produced by the client logging function 61. The transmitted events are removed from the event queue 75. In the client event service 6, the result of the request from the request generator 63 is evaluated by the callback generator 64. The callback generator 64 takes the client callback function 41 associated with the respective event identifier from the client event table 62 and calls these client callback functions 41 using the event data as parameters.
  • FIG. 3 shows system-based data structures for storing the data from the event handling operation on the client 1 and on the server 2.
  • The client event service 6 stores data records in a client event table 62 for every event handling operation. Each of the data records contains an event identifier, a reference to the associated client callback function 41 and optionally an event name. The realization of the reference is dependent on the specific implementation, or on the programming language used. By way of example, C/C++ typically uses function pointers. The client event table 62 may advantageously be in the form of a hash table in which the event identifier is used as a key. This means that when an event arrives the associated data record can be found efficiently.
  • The server 2 stores data for every client 1 which has logged event handling operations. This can be done efficiently in a client database 78 which is in the form of a hash table and which is used for access with a client ID as a key. For every client 1, a dedicated client data record 73 is stored which contains a server event table 74 and an event queue 75 in addition to the client ID. The server event table 74 can be in the form of a hash table, in a similar manner to the client event table 62, and contains appropriate data records, but a reference to the server callback function 72 is stored as a callback function. The event queue 75 is appropriately in the form of a queue data structure, with the individual data records containing at least the event identifier and optionally further parameters which describe the event in more detail.
  • List of Reference Symbols
    • 1 Client
    • 2 Server
    • 3 Technical installation
    • 4 Client application
    • 5 Server application
    • 6 Client event service
    • 7 Server event service
    • 9 Communication link
    • 10 Installation interface
    • 41 Client callback function
    • 61 Client logging function
    • 62 Client event table
    • 63 Request generator
    • 64 Callback generator
    • 71 Server logging function
    • 72 Server callback function
    • 73 Client data record
    • 74 Server event table
    • 75 Event queue
    • 76 Queue manager
    • 77 Tidying function
    • 78 Client database

Claims (20)

1. A method for managing and transmitting events from a server via a communication link to at least one client where
possible events are logged in a client, event service for the purpose of initializing and/or updating the client,
possible events are logged in a server event service for the purpose of initializing and/or updating the server,
detected events which have been logged are transferred from an installation interface to the server event service,
requests initiated by the client event service regarding the detected events are made to the server event service,
on the basis of a request which has been made to the server event service the detected events are transmitted to the client event service and
events received by the client event service, are transmitted to a client application.
2. The method as claimed in claim 1, wherein the events to be transmitted are detected by a data capture unit in a technical installation and are reported to the installation interface of the server.
3. The method as claimed in claim 1, wherein the client application logs a client callback function in the client event service for every event about which it is to be notified, and the client event service uses the communication link to log a corresponding server callback function in the server event service.
4. The method as claimed in claim 3, wherein to log the callback functions for an event with which the same event name is associated with the client and with the server in preparation for the method, the following steps are performed:
the client application calls a client logging function from the client event service and provides said function with the name of the event in question and with a pointer to the client callback function which is to be logged,
the client logging function generates a unique event identifier and transmits the event identifier and the event name via the communication link to a server logging function of the server event service, the server logging function logs a server callback function with the installation interface by transferring the event name,
the server logging function stores a data record, which contains at least the event identifier and a pointer to the server callback function which is to be logged, in a server event table,
the server logging function reports the performance of the logging operation to the client logging function of the client event service via the communication link, and
the client logging function logs the client callback function by storing a data record in a client event table, the data record containing at least the event identifier and a pointer to the client callback function which is to be logged.
5. The method as claimed in claim 1, wherein after a client callback function has been logged for the first time the client logging function starts a request generator which then makes requests for event transmission to the server event service.
6. The method as claimed in claim 5, wherein the request generator of the client event service makes the requests for event transmission to the server event service cyclically.
7. The method as claimed in claim 3, wherein events are transmitted by performing the following steps:
the installation interface detects an event which has occurred and calls the server callback function logged for this event, the server callback function produces an entry describing the event in at
least one event queue, upon the next request from the client event service for event transmission
the server event service reads the entry produced from the event queue and transmits it via the communication link to the client event service the client event service, takes the entry received and ascertains and calls
the client callback function logged for this event, and
the client callback function executes a defined action for the corresponding event in the client application.
8. The method as claimed in claim 7, wherein optionally a tidying function of the server event service is called which deletes the server event table and the event queue if the client event service is no longer communicating with the server event service.
9. A system for managing and transmitting events from a server via a communication link to at least one client, where
for the purpose of logging possible events the client has at least one client event service which uses a communication link to make requests for event transmission to a server event service and to transmit received events to a client application,
for the purpose of logging possible events the server has at least one server event service which uses a communication link to transmit events to a client event service,
the server has at least one installation interface which transfers events which have occurred to the at least one server event service.
10. The system as claimed in claim 9, wherein the installation interface is connected to a data capture unit of a technical installation in order to read in events detected by the data capture unit.
11. The system as claimed in claim 9, wherein the server event service has at least one server callback function which can be logged for at least one event and which is called when an event for which it is logged occurs.
12. The system as claimed in claim 9, wherein the server event service has at least one server logging function for logging server callback functions, at least one server event table for holding data records which describe a respective logging operation, and at least one event queue for holding entries which describe a respective event.
13. The system as claimed in claim 9, the server event service has, for every client event Wherein the service with which it communicates via a communication link, a separate client data record which respectively contains at least one server event table and at least one event queue.
14. The system as claimed in claim 13, wherein the server event service has a tidying function which deletes the client data record if the associated client event service is no longer communicating with the server event service.
15. The system as claimed in claim 12, wherein the server event table is in the form of a hash table and holds data records which contain at least one event identifier and a pointer to a server callback function which is to be logged.
16. The system as claimed in claim 9, wherein the client has at least one client callback function which can be logged for at least one event and which is called when the event for which it is logged occurs.
17. The system as claimed in claim 9, wherein that the client event service has at least one client logging function for logging client callback functions, at least one client event table for holding data records which describe the log, and at least one request generator for making cyclic requests for event transmission.
18. The system as claimed in claim 17, wherein the client event table is in the form of a hash table and holds data records which contain at least one event identifier and a pointer to a client callback function which is to be logged.
19. The method as claimed in claim 2, wherein the client application logs a client callback function in the client event service for every event about which it is to be notified, and the client event service uses the communication link to log a corresponding server callback function in the server event service.
20. The method as claimed in claim 4, wherein events are transmitted by performing the following steps:
the installation interface detects an event which has occurred and calls the server callback function logged for this event,
the server callback function produces an entry describing the event in at least one event queue,
upon the next request from the client event service for event transmission the server event service reads the entry produced from the event queue and transmits it via the communication link to the client event service,
the client event service takes the entry received and ascertains and calls the client callback function logged for this event, and
the client callback function executes a defined action for the corresponding event in the client application.
US10/562,046 2003-07-17 2004-04-10 Method and system for event transmission Active 2025-09-01 US8005941B2 (en)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
DE10332360 2003-07-17
DE10332360.0A DE10332360B4 (en) 2003-07-17 2003-07-17 Method and system for managing and transmitting events from a technical system to be monitored in a web-based client-server environment
DE10332360.0 2003-07-17
PCT/EP2004/003837 WO2005018193A1 (en) 2003-07-17 2004-04-10 Methods and system for event transmission

Publications (2)

Publication Number Publication Date
US20060224699A1 true US20060224699A1 (en) 2006-10-05
US8005941B2 US8005941B2 (en) 2011-08-23

Family

ID=33560164

Family Applications (1)

Application Number Title Priority Date Filing Date
US10/562,046 Active 2025-09-01 US8005941B2 (en) 2003-07-17 2004-04-10 Method and system for event transmission

Country Status (3)

Country Link
US (1) US8005941B2 (en)
DE (1) DE10332360B4 (en)
WO (1) WO2005018193A1 (en)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060235822A1 (en) * 2005-04-15 2006-10-19 Microsoft Corporation Requesting, obtaining, and processing operational event feedback from customer data centers
US20070132589A1 (en) * 2005-12-08 2007-06-14 Electronics & Telecommunications Research Institute System and method for managing postal devices using radio frequency identification
US20080065688A1 (en) * 2006-09-07 2008-03-13 Research In Motion Limited Mediated plug-in registration of client applications and content providers with push content delivery system
US7487201B1 (en) * 2006-06-30 2009-02-03 Sun Microsystems, Inc. Method and system for providing framework for Java based AJAX web applications
US20120005324A1 (en) * 2010-03-05 2012-01-05 Telefonica, S.A. Method and System for Operations Management in a Telecommunications Terminal
CN102722800A (en) * 2012-07-05 2012-10-10 甘肃银光聚银化工有限公司 Event routing management system based on client terminal
US20140351703A1 (en) * 2012-07-02 2014-11-27 Mitsubishi Electric Corporation Communication system, gui apparatus, and service apparatus
US9330234B1 (en) * 2010-04-13 2016-05-03 West Corporation Method, apparatus and computer program to provide access to client records and data resources
US20190235857A1 (en) * 2016-10-28 2019-08-01 Kabushiki Kaisha Toshiba Software update system for mobile body using vehicle-mounted gateway apparatus
US11372685B2 (en) * 2018-02-21 2022-06-28 Rapid7, Inc. Hash-based routing
US11509430B2 (en) 2020-02-04 2022-11-22 Siemens Aktiengesellschaft Method for operating an automation network having packet-based communication between a host and client

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10075425B1 (en) * 2016-08-26 2018-09-11 Amazon Technologies, Inc. Verifiable log service

Citations (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5621892A (en) * 1995-10-10 1997-04-15 Intel Corporation Method and apparatus for managing alerts and events in a networked computer system
US6243746B1 (en) * 1998-12-04 2001-06-05 Sun Microsystems, Inc. Method and implementation for using computer network topology objects
US6298378B1 (en) * 1998-12-04 2001-10-02 Sun Microsystems, Inc. Event distribution system for computer network management architecture
US20020016867A1 (en) * 2000-05-02 2002-02-07 Sun Microsystems, Inc. Cluster event service method and system
US6349333B1 (en) * 1998-12-04 2002-02-19 Sun Microsystems, Inc. Platform independent alarm service for manipulating managed objects in a distributed network management system
US6356282B2 (en) * 1998-12-04 2002-03-12 Sun Microsystems, Inc. Alarm manager system for distributed network management system
US6363421B2 (en) * 1998-05-31 2002-03-26 Lucent Technologies, Inc. Method for computer internet remote management of a telecommunication network element
US6378004B1 (en) * 1998-05-07 2002-04-23 Compaq Computer Corporation Method of communicating asynchronous elements from a mini-port driver
US6430616B1 (en) * 1998-12-04 2002-08-06 Sun Microsystems, Inc. Scalable system method for efficiently logging management information associated with a network
US20020112058A1 (en) * 2000-12-01 2002-08-15 Microsoft Corporation Peer networking host framework and hosting API
US6470388B1 (en) * 1999-06-10 2002-10-22 Cisco Technology, Inc. Coordinated extendable system for logging information from distributed applications
US6664978B1 (en) * 1997-11-17 2003-12-16 Fujitsu Limited Client-server computer network management architecture
US20040030775A1 (en) * 2002-08-08 2004-02-12 International Business Machines Corporation System and method for distributing management events to external processes
US6788315B1 (en) * 1997-11-17 2004-09-07 Fujitsu Limited Platform independent computer network manager
US20040226022A1 (en) * 2003-05-09 2004-11-11 Prabhu Sameer D. Method and apparatus for providing a client-side local proxy object for a distributed object-oriented system
US7010586B1 (en) * 2000-04-21 2006-03-07 Sun Microsystems, Inc. System and method for event subscriptions for CORBA gateway
US7107497B2 (en) * 2002-09-30 2006-09-12 Sun Microsystems, Inc. Method and system for event publication and subscription with an event channel from user level and kernel level
US7152104B2 (en) * 2001-10-17 2006-12-19 Sun Microsystems, Inc. Method and apparatus for notifying administrators of selected events in a distributed computer system
US7552445B2 (en) * 2002-12-13 2009-06-23 Savvis Communications Corporation Systems and methods for monitoring events from multiple brokers

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0825506B1 (en) 1996-08-20 2013-03-06 Invensys Systems, Inc. Methods and apparatus for remote process control
WO1998053581A1 (en) * 1997-05-19 1998-11-26 Coactive Networks, Inc. Server system and method for networking control networks and direct input/output devices with the world wide web
US6473407B1 (en) 1997-09-05 2002-10-29 Worldcom, Inc. Integrated proxy interface for web based alarm management tools
DE69903711T2 (en) 1998-02-26 2003-06-26 Sun Microsystems Inc EXTENDED OBJECT RESTORATION AND REMOTE LOAD FOR NOTIFICATION OF EVENTS IN A DISTRIBUTED SYSTEM
DE19832482A1 (en) * 1998-07-20 2000-01-27 Abb Patent Gmbh Method of information transfer in distributed system involves first process initiating link set-up in permitted direction, enabling second process to transmit spontaneous information in response
US6308205B1 (en) * 1998-10-22 2001-10-23 Canon Kabushiki Kaisha Browser-based network management allowing administrators to use web browser on user's workstation to view and update configuration of network devices
EP1125215A1 (en) * 1999-08-03 2001-08-22 Sony Electronics Inc. System and method for implementing device models in an electronic network
US6763384B1 (en) * 2000-07-10 2004-07-13 International Business Machines Corporation Event-triggered notification over a network
DE10038562B4 (en) * 2000-08-03 2005-12-15 Siemens Ag System and method for transmitting data over data networks with data conversion by a COM car sounder
US7117268B2 (en) 2000-11-30 2006-10-03 Matsushita Electric Works, Ltd. Architecture for communicating with one or more electronic devices through a gateway computer
US20030018705A1 (en) * 2001-03-31 2003-01-23 Mingte Chen Media-independent communication server
DE10132038A1 (en) * 2001-07-03 2003-01-23 Siemens Ag Automation system and process for plant visualization
US20030037102A1 (en) * 2001-08-14 2003-02-20 Philippe Eckert Message broker

Patent Citations (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5621892A (en) * 1995-10-10 1997-04-15 Intel Corporation Method and apparatus for managing alerts and events in a networked computer system
US6788315B1 (en) * 1997-11-17 2004-09-07 Fujitsu Limited Platform independent computer network manager
US6664978B1 (en) * 1997-11-17 2003-12-16 Fujitsu Limited Client-server computer network management architecture
US6378004B1 (en) * 1998-05-07 2002-04-23 Compaq Computer Corporation Method of communicating asynchronous elements from a mini-port driver
US6363421B2 (en) * 1998-05-31 2002-03-26 Lucent Technologies, Inc. Method for computer internet remote management of a telecommunication network element
US6430616B1 (en) * 1998-12-04 2002-08-06 Sun Microsystems, Inc. Scalable system method for efficiently logging management information associated with a network
US6243746B1 (en) * 1998-12-04 2001-06-05 Sun Microsystems, Inc. Method and implementation for using computer network topology objects
US6349333B1 (en) * 1998-12-04 2002-02-19 Sun Microsystems, Inc. Platform independent alarm service for manipulating managed objects in a distributed network management system
US6356282B2 (en) * 1998-12-04 2002-03-12 Sun Microsystems, Inc. Alarm manager system for distributed network management system
US6298378B1 (en) * 1998-12-04 2001-10-02 Sun Microsystems, Inc. Event distribution system for computer network management architecture
US6470388B1 (en) * 1999-06-10 2002-10-22 Cisco Technology, Inc. Coordinated extendable system for logging information from distributed applications
US7010586B1 (en) * 2000-04-21 2006-03-07 Sun Microsystems, Inc. System and method for event subscriptions for CORBA gateway
US20020016867A1 (en) * 2000-05-02 2002-02-07 Sun Microsystems, Inc. Cluster event service method and system
US20020112058A1 (en) * 2000-12-01 2002-08-15 Microsoft Corporation Peer networking host framework and hosting API
US7152104B2 (en) * 2001-10-17 2006-12-19 Sun Microsystems, Inc. Method and apparatus for notifying administrators of selected events in a distributed computer system
US20040030775A1 (en) * 2002-08-08 2004-02-12 International Business Machines Corporation System and method for distributing management events to external processes
US7107497B2 (en) * 2002-09-30 2006-09-12 Sun Microsystems, Inc. Method and system for event publication and subscription with an event channel from user level and kernel level
US7552445B2 (en) * 2002-12-13 2009-06-23 Savvis Communications Corporation Systems and methods for monitoring events from multiple brokers
US20040226022A1 (en) * 2003-05-09 2004-11-11 Prabhu Sameer D. Method and apparatus for providing a client-side local proxy object for a distributed object-oriented system

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060235822A1 (en) * 2005-04-15 2006-10-19 Microsoft Corporation Requesting, obtaining, and processing operational event feedback from customer data centers
US7571150B2 (en) * 2005-04-15 2009-08-04 Microsoft Corporation Requesting, obtaining, and processing operational event feedback from customer data centers
US20070132589A1 (en) * 2005-12-08 2007-06-14 Electronics & Telecommunications Research Institute System and method for managing postal devices using radio frequency identification
US7487201B1 (en) * 2006-06-30 2009-02-03 Sun Microsystems, Inc. Method and system for providing framework for Java based AJAX web applications
US20080065688A1 (en) * 2006-09-07 2008-03-13 Research In Motion Limited Mediated plug-in registration of client applications and content providers with push content delivery system
US20120005324A1 (en) * 2010-03-05 2012-01-05 Telefonica, S.A. Method and System for Operations Management in a Telecommunications Terminal
US9330234B1 (en) * 2010-04-13 2016-05-03 West Corporation Method, apparatus and computer program to provide access to client records and data resources
US9536048B1 (en) * 2010-04-13 2017-01-03 West Corporation Method, apparatus and computer program to provide access to client records and data resources
US20140351703A1 (en) * 2012-07-02 2014-11-27 Mitsubishi Electric Corporation Communication system, gui apparatus, and service apparatus
US9596145B2 (en) * 2012-07-02 2017-03-14 Mitsubishi Electric Corporation Communication system, GUI apparatus, and service apparatus
CN102722800A (en) * 2012-07-05 2012-10-10 甘肃银光聚银化工有限公司 Event routing management system based on client terminal
US20190235857A1 (en) * 2016-10-28 2019-08-01 Kabushiki Kaisha Toshiba Software update system for mobile body using vehicle-mounted gateway apparatus
US10901724B2 (en) * 2016-10-28 2021-01-26 Kabushiki Kaisha Toshiba Software update system for mobile body using vehicle-mounted gateway apparatus
US11372685B2 (en) * 2018-02-21 2022-06-28 Rapid7, Inc. Hash-based routing
US11853804B2 (en) 2018-02-21 2023-12-26 Rapid7, Inc. Routing log-based information
US11509430B2 (en) 2020-02-04 2022-11-22 Siemens Aktiengesellschaft Method for operating an automation network having packet-based communication between a host and client

Also Published As

Publication number Publication date
DE10332360A1 (en) 2005-02-03
DE10332360B4 (en) 2023-06-29
WO2005018193A1 (en) 2005-02-24
US8005941B2 (en) 2011-08-23

Similar Documents

Publication Publication Date Title
US8429654B2 (en) Apparatus and method for guaranteed batch event delivery in a process control system
US8005941B2 (en) Method and system for event transmission
US6999997B2 (en) Method and apparatus for communication of message data using shared queues
CN103888277B (en) A kind of gateway disaster-tolerant backup method, device and system
KR101545626B1 (en) System for interoperation between dds and dbms
CN104135378A (en) Method of management control of Internet of Things gateways and management control entity for Internet of Things gateways
CN108563502A (en) A kind of method for scheduling task and device
CN106612339A (en) Domain name updating method, system and main DNS (Domain Name System) server
CN103812838A (en) Service calling method and device and system
US8326913B2 (en) Method and system for service contract discovery
CN105554142A (en) Method, apparatus and system for pushing messages
WO1999057620A2 (en) Distribution of a service request in a client-server architecture
JP2004030486A (en) Method for controlling distributed object and its execution system
US8077699B2 (en) Independent message stores and message transport agents
EP2038714B1 (en) Method, computer readable medium and system for guaranteed batch event delivery in a process control system
US6137801A (en) Telecommunication switching system administrative and management tools
CN111367853A (en) Data transmission method, device, equipment and computer readable storage medium
US8468121B1 (en) Resolving resource time intervals in a distributed system
JP2000148539A (en) Fault detecting method, computer system, constitutional device, and recording medium
CN113407611B (en) Data integration distribution platform and system
JPH0666983B2 (en) Routing control system
CN113162955B (en) Monitoring method, device, system, server and storage medium for long-distance pipeline
EP1892624B1 (en) System and method for processing operational data associated with a transmission in a data communication system
EP1182892A1 (en) A short message method and system
JPH11110216A (en) Distributed object management system

Legal Events

Date Code Title Description
AS Assignment

Owner name: ABB RESEARCH LTD., SWITZERLAND

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KRUSE, ECKHARD;HU, ZAIJUN;VERYHA, YAUHENI;AND OTHERS;REEL/FRAME:017463/0814;SIGNING DATES FROM 20060118 TO 20060328

Owner name: ABB RESEARCH LTD., SWITZERLAND

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KRUSE, ECKHARD;HU, ZAIJUN;VERYHA, YAUHENI;AND OTHERS;SIGNING DATES FROM 20060118 TO 20060328;REEL/FRAME:017463/0814

FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8

AS Assignment

Owner name: ABB SCHWEIZ AG, SWITZERLAND

Free format text: MERGER;ASSIGNOR:ABB RESEARCH LTD.;REEL/FRAME:051419/0309

Effective date: 20190416

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 12