Title of Invention	"A REDIRECTION MANAGEMENT METHOD FOR AN OPC SYSTEM"
Abstract	An OPC redirection manager maintains the information necessary for taking appropriate action when the target OPC server fails and for ensuring that no bad status is returned to the client. Any existing OPC client needing seamless failover between target OPC data access and/or alarm and event servers will connect to a uniquely configured instance of the redirection manager instead of connecting to the primary server. The client application continues to perform OPC related usks as usual. Because each chent connection is unique, the redirection manager itself is not a single point of tailure.  Each configured redirection manager

Title of Invention

"A REDIRECTION MANAGEMENT METHOD FOR AN OPC SYSTEM"

Abstract

An OPC redirection manager maintains the information necessary for taking appropriate action when the target OPC server fails and for ensuring that no bad status is returned to the client. Any existing OPC client needing seamless failover between target OPC data access and/or alarm and event servers will connect to a uniquely configured instance of the redirection manager instead of connecting to the primary server. The client application continues to perform OPC related usks as usual. Because each chent connection is unique, the redirection manager itself is not a single point of tailure.  Each configured redirection manager

Full Text	OPC SERVER REDIRECTION MANAGER CROSS REFERENCE This application claims priority of U.S. Provisional Patent Application Serial No. 60/392493, filed on June 28, 2002, entitled "OPC Server Redirection Manager." BACKGROUND 1. Field of the Invention. The present invention generally relates to an OPC server redirection manager, which is an intermediate OPC server that forwards all OPC calls made by clients to actual OPC servers that communicate with data sources. In particular, the OPC server redirection manager maintains the information necessary to take appropriate action when a target OPC server fails and ensures that no bad status is returned to a client. 2. Description of the Related Art OLE FOR PROCESS CONTROL® (OPC®) is an emerging industry standard that facilitates integration by allowing automation systems to share information and interoperate with other industrial automation, process control, and other business systems for plants or factories. (The letters O-P-C originally stood for Object Linking and Embedding (OLE) for Process Control, but OLE has been restructured from object-orientec to object-based and renamed ActiveX.) The OPC standard is a non-proprietary technical specification that is maintained by the OPC Foundation®. In the past, each'software or application developer needed to write a custom interface (or server/driver) to exchange data with hardware field devices. The OPC standard replaced this practice by providing a common interface that permits this work to be done once, and then easily reused by Human Machine Interface (HMI), Supervisory Control and Data Acquisition (SCADA) control and custom applications. The OPC specification is based upon the Microsoft® OLE (now ActiveX), Component Object Model (COM), and Distributed Component Object Model (DCOM) technologies. OPC defines a standard set of interfaces, properties, and methods for use in process control, manufacturing, and automation applications. These applications include distributed control systems, programmable logic controllers, input/output (10) systems, smart field devices, and other servers of real-time information. The ActiveX/COM technologies define how individual software components interact and share data. By using the Microsoft® Visual Basic object-oriented component, OLE Automation, OPC can provide office applications with plant floor data via local area networks (LANs), remote sites, or the Internet. OPC provides many benefits to end users and hardware and software manufacturers, including open connectivity, high performance, and improved vendor productivity. OPC provides open connectivity giving users a choice among a wider variety of plant floor devices and client software, allowing better utilization of best-in-breed applications. Because OPC is an open standard, software and hardware manufacturers devote less time to connectivity issues and more time to application issues, eliminating significant duplicate effort. OPC fosters greater interoperability between automation and control applications, field devices, and business and office applications. Some redirection systems provide inferior functionality to the redirection manager according to the present invention and they appear to have different architectures. One redirection system is implemented as a Microsoft Windows® service, whereas the redirection manager according to the present invention uses a private connection approach to limit the impact of failure. Redirection systems implement OPC data access, whereas the redirection manager according to the present invention has redirection servers that implement those as well as OPC alarms and events. Redirection systems appear to implement server/node health via a ping mechanism, whereas the redirection manager according to the present invention uses a monitoring approach with less network traffic overhead. Certain OPC servers synchronize the internal OPC server database for performance and consistency reasons. The redirection manager according to the present invention optionally provides this capability. Other redirection systems provide a service to which all clients connect. If that service fails, then all connected clients are impacted. By contrast, clients using the redirection manager according to the present invention have a private connection. If the private connection fails, then only the connected client is impacted. Conventional redirection systems use a ping mechanism for detection. This is less efficient than the redirection manager according to the present invention, which uses notification providers to alert the redirection manager when target nodes or servers fail. The present invention overcomes these problems by maintaining the information necessary for taking appropriate action when the target OPC server fails and for ensuring that no bad status is returned to the client. Any existing OPC client needing seamless failover between target OPC data access and/or alarm and event servers will connect to a uniquely configured instance of the redirection manager instead of connecting to the primary server. The client application continues to perform OPC related tasks as usual. Because each client connection is unique, the redirection manager itself is not a singie point of failure. Each configured redirection manager instance monitors the health of the target server node and the target server itself by subscribing to failure events. Use of subscription rather than polling (via ping) reduces network traffic. The present invention also provides many additional advantages as described below. SUMMARY OF THE INVENTION One embodiment of the present invention is a redirection management method. In response to a first client connection request for a first OPC client, a first private connection is granted from the first OPC client to a first instance of an OPC redirection manager. In response to a second client connection request for a second OPC client, a second private connection is granted from the second OPC client to a second instance of the OPC redirection manager. According to one embodiment, even though the second private connection for the second OPC client is lost when the second instance of the OPC redirection manager fails, the first private connection for the first OPC client is maintained. A connection is made to a first target OPC server. Another connection is made to an OPC server status change provider for the first target OPC server. According to another embodiment, additional connections are made to at least one additional target OPC server, including a second target OPC server configured to backup the first target OPC server. Upon receiving an active-server-failed event from the OPC server status change provider for the first target OPC server, a switchover to the second target OPC server is performed. Notice is received from the OPC server status change provider that the first target OPC server is'now available and a connection is made to the first target OPC server. Assuming no failure had occurred, an OPC add-group request is received from the first OPC client and it is forwarded to the first target OPC server to service. Upon receiving a request-complete event from the first target OPC server, a plurality of add-group interfaces associated with the OPC add-group request are implemented by creating at least one group. The OPC add-group request is forwarded to each of the additional target OPC servers to store the group(s) as inactive. Information is stored that is related to the OPC add-group request, including the group(s). An OPC on-data-change request is received by the redirection manager from the first OPC client and a connection is established between the first target OPC server and a first sink object. The sink objects belong to the redirection manager. Another connection is established between the second target OPC server and a second sink object. Information related to the OPC on-data-change request, including the at least one group is stored. A first on-data-change request is provided to the first OPC client from the redirection manager following the redirection manager's receipt of the on-data-change request from the first target OPC server. Upon receiving an active-server-failed event from the OPC server status change provider for the first target OPC server, a switchover is performed to the second target OPC server. At least one group is activated on the second target OPC server and a second on-data-change request is provided to the first OPC client from the redirection manager following the redirection manager's receipt of the on-data-change request from the second target OPC server. Notice that the first target OPC server is now available is received from the OPC server status change provider, a connection is made to the first target OPC server and previously stored information is used to add the group(s) to the first target OPC server. Another embodiment of the present invention is a method of redirection management. In response to an OPC create-eveni-subscription request from an OPC client, interfaces associated with the OPC create-event-subscription request are implemented. The OPC create-event-subscription request is forwarded to a primary target OPC server for service. It is also forwarded as inactive to at least one additional target OPC server, including a secondary target OPC server configured to backup the primary target OPC server. Information related to the OPC create-event-subscription request is stored, including state information. A connection is made by the redirection manager to the primary target OPC server. Additional connections are made by the redirection manager to an OPC server status change provider for the primary target OPC server and to additional target OPC server(s). If it is determined that the primary target OPC server supports OPC alarms and events, an alarms-and-events module is loaded. At least one on-event request is provided to the OPC client from the primary target OPC server. Upon receiving an active-server-failed event from the OPC server status change provider for the primary target OPC server, a switchover to the secondary target OPC server is performed and the alarms-and-events module is notified of the switchover. A currently active event is synchronized with the secondary target OPC server to prevent loss of data and an OPC on-event request is provided to the OPC client from the secondary target OPC server. When notice from the OPC server status change provider is received that the primary target OPC server is now available, a connection is made to the primary target OPC server and it is established with the state information. Anther embodiment of the present invention is an OPC redirection management system comprising a first OPC server, a second OPC server, and a first redirection manager. The first OPC server is capable of servicing an OPC request. The second OPC server is configured to backup the first OPC server. The first redirection manager is capable of forwarding an OPC request on behalf of a first OPC client to either the first OPC server or the second OPC server. The first OPC client is capable of establishing its own private connection with the first redirection manager. The first redirection manager is capable of connecting to the second OPC server upon failure of the first OPC server to provide seamless service to the first OPC client. The first redirection manager is capable of storing information associated with the OPC request for use upon failure of the first OPC server. The OPC redirection management system may also comprise a third OPC server, a fourth OPC server, and a second redirection manager. The fourth OPC server is configured to backup the third OPC server. A second OPC client is capable of establishing its own private connection with the second redirection manager. The second redirection manager is capable of connecting to the fourth OPC server upon failure of the third OPC server to provide seamless service to the second OPC client. The first OPC server is capable of being configured to backup a third OPC server. The OPC request may be of type data access or alarm and events. The OPC redirection management system may also comprise a primary server node, a secondary server node, and a client node. The primary server node comprises the first OPC server, a primary node status change provider, and a primary OPC status change provider. The secondary server node comprises the second OPC server, a secondary node status change provider, and a secondary OPC status change provider. The client node comprises the first OPC client, the first redirection manager, a client node status change provider, and a client OPC status change provider. The first redirection manager comprises data access and subscription state data and a switchover manager. The first OPC server comprises an item cache and a condition database. The first OPC client is a process control application. The first OPC server communicates with a device to service the OPC request so that the first OPC client receives information about the device as a result of the OPC request. Another embodiment of the present invention is a machine-readable medium storing executable instructions for performing a method. In response to a first client connection request for a first OPC client, a first private connection is granted from the first OPC client to a first instance of an OPC redirection manager. In response to a second client connection request, a second private connection is granted from the second OPC client to a second instance of the OPC redirection manager. A connection is made to a node status change provider for the second OPC client. When the redirection manager fails and the private connection for the second OPC client is lost, the first private connection for the first OPC client is maintained. A connection is made to a first target OPC server. Another connection is made to an OPC server status change provider for the first target OPC server. Another connection is made to a second target OPC server configured to backup the first target OPC server. Upon receiving an active-server-failed event from the OPC server status change provider for the first target OPC server, a switchover to the second target OPC server is performed. These and other features, aspects, and advantages of the present invention will become better understood with reference to the following drawings, description, and appended claims. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a block diagram of a single client connection for a redirection manager system architecture according to the present invention. FIG. 2 is a block diagram of multiple client connections to multiple instances of a redirection manager according to the present invention. FIG. 3 is a sequence diagram of how a client connection is made by a redirection manager, according to the present invention. FIG. 4 is a sequence diagram of how a redirection manager maintains state information related to an OPC add-group request, according to the present invention. FIG. 5 is a sequence diagram of how a redirection manager handles OPC on-data-change requests, according to the present invention. FIG. 6 is a sequence diagram of how a redirection manager handles the failure of the active target OPC server, according to the present invention. FIG. 7 is a sequence diagram of how a redirection manager synchronizes an alternate target OPC server when it becomes available, according to the present invention. FIG. 8 is a sequence diagram of how a redirection manager maintains state information on behalf of a client for an OPC create-event subscription request, according to the present invention. FIG. 9 is a sequence diagram of how a redirection manager handles failure of the active target OPC server when the target servers support OPC alarms and events, according to the present invention. FIG. 10 is a sequence diagram of how a redirection manager synchronizes an alternate target OPC server when it becomes available, according to the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS In the following detailed description, reference is made to the accompanying drawings. These drawings form a part of this specification and show by way of example specific preferred embodiments in which the present invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the present invention. Other embodiments may be used. Structural, logical, and electrical changes may be made without departing from the spirit and scope of the present invention. Therefore, the following detailed description is not to be taken in a limiting sense and the scope of the present invention is defined only by the appended claims. FIG. 1 shows a single client connection for a redirection manager system architecture according to the present invention. Within a client node 100 is an OPC client 101 which is connected to a single instance of a redirection manager 102 that, in turn, communicates with components inside a primary OPC server'node 104 and components inside a backup OPC server node 106. Components inside primary OPC server node 104 and backup OPC server node 106 communicate with a device 108. OPC client 101 connects to redirection manager 102 instead of directly connecting to primary OPC server node 104. Redirection manager 102 is configured for OPC client 101 using a configuration utility. Once configuration is complete, OPC client 101 continues to perform OPC related tasks as usual. Each configured redirection manager 102 is registered so that it points to an installed executable. At the time of client connection, a new instance of redirection manager 102 is created. This new instance executes in a unique process address space. It is identifiable to OPC client 101 by a unique identification for status purposes. In addition to an instance of redirection manager 102, Client node 100 has an OPC server status change provider 110 and a node status change provider 112. Redirection manager 102 is an intermediate OPC server that forwards OPC requests made by OPC client 101 to primary OPC server node 104 that communicates with device 108. Redirection manager 102 maintains the information necessary to take appropriate actions when primary OPC server node 104 fails and ensures that no bad status is returned to OPC client 101. Redirection manager 102 has data access and subscription state data 114 and a switchover manager 116 to change the active server. Primary OPC server node 104 communicates with device 108 and other data sources that OPC client 101 wants access to reading and writing data and is configured to be a primary server for redirection manager 102. In addition, primary OPC server node 104 is configurable as a secondary server for a different redirection manager than redirection manager 102 (see FIG. 2). The active OPC server is either primary OPC server node 104 or the backup OPC server node 106 and is the server that is currently servicing the OPC requests for OPC client 101 through redirection manager 102. Primary OPC server node 104 has an OPC server 118 with* ah item cache 120 and a condition database 122, a node status change provider 124, and an OPC server status change provider 126. Current data values are stored in item cache 120 and alarm states are stored in condition database 122. Secondary or backup OPC server node 106 is the active OPC server when primary OPC server node 104 fails. In addition, backup OPC server node 106 is configurable as a primary server for a different redirection manager (see FIG. 2). Like primary OPC server node 104, backup OPC server node 106 has an OPC server 128 with an item cache 130 and a condition database 132, a node status change provider 134, and an OPC server status change provider 136. Device 108 is a data source that is capable of servicing data access or IO requests as well as pushing alarms and events to OPC servers. Redirection manager 102 according to the present invention is an OPC server that may support OPC Data Access 2.05 and 1.0A, OPC Alarms and Events 1.0 and OPC Security 1.0 interfaces as well as other OPC data access, OPC alarms and events and other OPC interfaces known presently or in the future. It is not a true OPC server in the sense that it does not communicate with real data sources, and instead is used to forward client calls to and from the actual OPC servers and to maintain state information allowing it to switch to a backup server when the primary server fails. Redirection manager 102 is implemented as an out-of-process .exe server (see FIG. 2). There is one .exe server per client connection to redirection manager 102. Those OPC requests that alter the state of the client connection but do not request IO are made to both the primary and backup servers, e.g., primary OPC server node 104 and backup OPC server node 106. IO requests are only made to primary OPC server 118. This puts the secondary in a hot-standby mode. In the event that primary OPC server 118 fails, redirection manager 102 activates the backup OPC server 128 and issues IO requests. Since OPC client 101 is unaware of the switch, it can significantly reduce error handling scenarios in OPC client 101 itself. Redirection manager 102 supports a cold-standby redundancy scheme as well. In this case, state is not replicated to backup OPC server 128. All state is set up at switchover time. Redirection manager 102 also supports optional browsing interfaces. Redirection manager 102 forwards all the calls to either primary OPC server 118 or backup OPC server 128 or to all servers, while maintaining state information related to the calls for redirection purposes. The server that is currently servicing IO requests is referred to as the active server. In the event, the currently active server fails, redirection manager 102, as part of the switchover process, sets one of the backup servers to be the new active server. Redirection manager 102 saves the state of the requests of OPC client 101 to redirect them or reissue them to a backup server when the primary server fails and also for various other scenarios. One approach is to categorize the client calls as IO and non-IO requests. The classification is made as follows. Those OPC requests that alter the state of the client connection but do not request IO are classified as non-IO requests, such as add-group, add-item, create-event-subscription, and set-filter-calls. Client IO calls are classified as IO requests, such as read, write, and ack-condition. Persisting state of these calls is handled differently. Non-IO calls are maintained as long as OPC client 101 is running. One scenario where this information is needed is to sync-up a backup server that comes up after OPC client 101 has made add-group and add-items calls. The IO call information is persisted only until either the primary or backup, server services the call. Once the call successfully completes, the IO information about the call is deleted. Redirection manager 102 examines all the errors returned by the active server. Those errors which indicate a failure along the communication path between redirection manager 102 and the active server will cause redirection manager 102 to initiate a switchover. Those errors which do not indicate a failure along this communication path are forwarded to OPC client 102. OPC client 101 handles these errors the same way as it would if connected to the servers directly. Redirection manager 102 saves the state of all non-IO calls and hence can attempt the re-sync. All OPC calls categorized as non-IO are sent to both the primary and backup servers. The call has to succeed on the active server before the request is issued to the backup server. If the request fails on the backup, the error is logged but not returned to the client. At this point, the backup server is considered out of sync with the active server. The Redirection Manager attempts to re-sync the backup on a switchover. If the re-sync fails, the Redirection Manager does not switchover to the secondary. During initialization, redirection manager 102 establishes a connection with the target servers, e.g., primary OPC server node 104 and backup OPC server node 106. Also, redirection manager 102 establishes connections with status change providers, such as OPC server status change provider 110 to subscribe to events that may trigger switchover manager 116. For node failures, redirection manager 102 connects to node status change provider 112. Node status change provider 112 communicates with peer node status change providers, such as node status change provider 106 to monitor the health of other nodes. Similarly, redirection manager 102 establishes a remote subscription connection to the OPC server status change providers, such as OPC server status change providers 126 and 136 on each target OPC server node, such as primary OPC server node 104 and backup OPC server node 106. Changes in server state are forwarded to redirection manager 102. If primary OPC server node 104's OPC server 118 transitions from a running state, then redirection manager 102 initiates a switchover to backup OPC server node 106 through switchover manager 116. If backup OPC server 128 transitions from the running state and becomes unavailable, subsequent transition to running results in synchronization. Redirection manager 102 reports its status to OPC server status change provider 110.. This enables integration with a hosting system status display component. The health of the connection from OPC client 101 to redirection manager 102 as well as the health of target OPC servers 118, 128 are exposed to the user. OPC client 101 makes OPC requests to redirection server 102 as if it were directly connected to target OPC servers 118, 128. For each client group creation, redirection manager 102 forwards the request to the active and backup OPC servers 118,128. Requests to activate the group collection are only performed on the active OPC server. Group data collection is inactive on the backup servers. Similarly, requests to activate event subscriptions are only performed on the active OPC server. Event subscriptions remain inactive on the backup OPC servers. Requests to collect particular data sources may require conversion to a name within the namespace of device 108. If device 108 is remotely located, this name conversion operation may be costly in terms of performance. Therefore, redirection manager 102 is optimized to synchronize the device namespace handles without requesting multiple conversion operations for device 108. Redirection manager 102 makes all the OPC calls or requests to primary OPC server 118 and backup OPC server 128 on separate threads. This allows OPC calls that fail due to server failure to be reissued to backup OPC server 128. After creating the thread, primary OPC server 118 waits on a request-complete event signaled by the thread issuing the call to backup OPC server 128. Once the event is signaled, primary OPC server 118 returns the results back to OPC client 101. Redirection manager 102 also waits on an active-server-failed event to be signaled when the active server fails. If this event is signaled, redirection manager 102 looks for an alternate server and reissues the failed request to that server. An internal timeout period is added to the waits to take care of those scenarios that notification providers or redirection manager 102 itself may not handle, in this way, if either of the above two events are not signaled, redirection manager 102 is not left hanging forever. The timeout period is provided as a configuration option. There is an approach followed for callbacks both for data access as well as alarm and events. Redirection manager 102 implements all the callbacks of OPC client 101. It intercepts the callbacks of the active OPC server, holds all the sink interfaces of OPC client 101, and issues the callbacks to OPC client 101. This ensures that no bad values are returned to OPC client 101 during switchover. For data access, no asynchronous read or write calls are missed when the active server fails before callback can happen. Redirection manager 102 keeps track of whether the callbacks were completed, and reissues the call again to the backups-when the switchover happens. Redirection manager 102 callback forwards the event to the client on-event callback or forwards the data request to the on-data-change callback. When the active server fails, redirection manager 102 activates the client subscriptions or data access groups on the secondary server. Redirection manager 102 refreshes event subscriptions and starts processing callbacks from the secondary server. FIG. 2 is a block diagram of multiple client connections to multiple instances of a redirection manager according to the present invention. Client node 200 has an installed redirection manager binary executable 202. A configuration tool creates entries for registered redirection managers in a registration table 204 that resides in the Microsoft Windows® registry. Configuring includes identifying the target OPC servers. When a client, such as client one 206, connects to a registered redirection manager, such as redirection manager one 208, a new instance of the installed redirection manager binary executable 202 is created. Each instance executes in its own process space, is independent of any other running instance, and is visible to the native operating system. Clients connect to various multiple registered redirection managers, such as redirection manager one, two, three, and four. If the first instance of redirection manager one 208 fails, then only client one 206 is effected, because client three 216 has its own private connection to the second instance of redirection manager one 218. The registered redirection managers, in turn, communicate with multiple OPC servers, such as OPC server 210. Multiple OPC servers.reside in server nodes, such as server node 212. Multiple server nodes reside in clusters, such as OPC server node cluster 214. There can be any number of clients, redirection managers, OPC servers, server nodes, and OPC server node clusters. FIGS. 3-10 are sequence diagrams for a number of scenarios of how a redirection manager operates according to the present invention. Although the redirection manager is designed to accommodate two or more target OPC servers, the sequence diagrams use only two target OPC servers (i.e., primary and secondary). This is for illustrative purposes only, to make the sequence diagrams simpler and more easily understood. The first target to which the redirection manager successfully connects is referred to as the active server. The remaining target OPC servers are referred to as alternates. The redirection manager according to the present invention supports specifications from both the OPC data access and OPC alarms and events initiatives. In the following scenarios, a particular initiative may be mentioned, but the redirection manager according to the present invention is able to service both data access clients and alarms and events clients simultaneously. Each table below for FIGS. 3-10 summarizes the specific events in the corresponding figure. However, there is not a one-to-one correspondence between the event numbers in the tables and the step numbers in FIGS. 3- 10. FIG. 3 shows how a client connection is made by a redirection manager, according to the present invention. Each of the components identified in the boxes along the top of FIG. 3 run in separate processes. These components are client 101, redirection manager 102, node status change provider 112, primary OPC server 118, primary server status change provider 126, secondary OPC server 128, and secondary server status change provider 136. FIG. 3 assumes some starting conditions. The user or administrator has used a configuration tool to create a named instance of a redirection manager server. This instance includes the identification of target OPC servers. This information is stored by the configuration tool into a registry location known to the redirection manager runtime (see FIG. 2). All target OPC servers are available. Table 1 generally describes the specific events shown in FIG. 3. Each event in Table 1 is implemented in example methods shown in FIG. 3. Table 1. Client Connection (Table Removed) FIG. 4 shows how a redirection manager maintains state information related to an OPC-add-group request, according to the present invention. The components involved in this scenario are client 101, redirection manager 102, a redirection group 400 (in data access and subscription state data 114), a primary add-group thread 402 (created by redirection manager 102), a secondary add-group thread 404 (created by redirection manager 102), primary server 118, and secondary server 128. The scenario assumes that both primary server 118 and secondary server 128 are available. FIG. 4 assumes some starting conditions. The administrator has made the necessary configuration using the redirection manager configuration utility to register redirection manager 102. Also, the OPC client 101 made a connection to redirection manager 102. Table 2 generally describes the specific events shown in FIG. 4. Each event in Table 2 is implemented in example methods shown in FIG. 4. Table 2. OPC Data Access Scenario: AddGroup (Table Removed) FIG. 5 shows how a redirection manager handles OPC on-data-change requests, according to the present invention. The components involved in this scenario are client 101, a redirection group 400 (which is part of data access and subscription state data 114), a redirection manager (RDM) primary sink 502, a redirection manager (RDM) secondary sink 504, a primary group 506 (which is part of primary OPC server 118), and a secondary group 508 (which is part of secondary OPC server 128). This scenario describes how redirection manager 102 handles OPC on-data-change requests and assumes that all the target OPC servers are available. FIG. 5 assumes some starting conditions. The OPC client 101 has connected to the redirection manager and has added groups and items. The groups and items have been added to all the target OPC servers. Table 3 generally describes the specific events shown in FIG. 5. Each event in Table 3 is implemented in example methods shown in FIG. 5. Table 3. OPC Data Access Scenario: OnDataChange (Formula Removed) FIG. 6 shows how a redirection manager handles the failure of the active target OPC server, according to the present invention. The components involved in this scenario are OPC client 101, redirection group 400, redirection manager (RDM) primary sink 502, redirection manager (RDM) secondary sink 504, primary group 506, primary component status provider 126, and secondary group 508. FIG. 6 assumes some starting conditions. OPC client 101 has connected to the redirection manager. OPC client 101 is receiving OnDataChange() calls from the redirection manager via the active target OPC server. The active target OPC server fails. Table 4 generally describes the specific events shown in FIG. 6. Each event in Table 4 is implemented in example methods shown in FIG. 6. Table 4. OPC Data Access Scenario: Active Target OPC Server Fails (Formula Removed) FIG. 7 shows how a redirection manager synchronizes an alternate target OPC server when it becomes available, according to the present invention. The components involved in this scenario are OPC client 101, redirection manager 102, primary OPC server 118, primary server status change provider 126, secondary OPC server 128, and secondary server status change provider 136. FIG. 7 assumes some starting conditions. OPC client'10*1 has connected to redirection manager 102 and is being serviced by the active target OPC server. An alternate target OPC server that was previously not running, starts. Table 5 generally describes the specific events shown in FIG. 7. Each event in Table 5 is implemented in example methods shown in FIG. 7. Table 5. OPC Data Access Scenario: Alternate Target OPC Server Becomes Available (Formula Removed) FIG. 8 shows how a redirection manager maintains state information on behalf of a client for an OPC create-event subscription request, according to the present invention. The components involved in this scenario are OPC alarms and events client 101, redirection event server (redirection manager) 102, a redirection subscription object 804 (which is part of data access and subscription state data 114), a separate thread 806 (created by redirection manager 102), primary event server 118, and secondary event server 128. This scenario describes how the redirection manager maintains state information on behalf of an OPC alarm and events client. Specifically, this is shown for the state information related to an OPC CreateEventSuascription call. This scenario assumes that both the Primary and Secondary servers are available. A switchover event is used in lieu of an active-server-failed event, as in the OPC data access scenarios. Because the redirection manager's OPC alarms and events capabilities are contained within a separate module which is only loaded if alarms and events support is needed by OPC alarms and events client 800, the module itself does not monitor the availability or health of the target servers. Instead,-the redirection manager's alarms and events module relies on those facilities contained within the main redirection manager. These main facilities detect a target server failure or service a request to manually switch to an alternate target server, but in either case the alarms and events module simply receives the more generic switchover event. FIG. 8 assumes some starting conditions. Both primary and secondary servers are available. OPC alarms and events client 800 made a connection to the redirection manager. The redirection manager loaded the alarms and event support module, after detecting that the target OPC servers support OPC alarms and events. OPC alarms and events requests made by the client are being serviced by this module. Table 6 generally describes the specific events shown in FIG. 8. Each event in Table 6 is implemented in example methods shown in FIG. 8. Table 6. OPC Alarms and Events Scenario: Create Event Subscription (Table Removed) FIG. 9 shows how a redirection manager handles failure of the active target OPC server when the target servers support OPC alarms and events, according to the present invention. The components involved in this scenario are OPC alarms and events client 101, redirection event server (redirection manager) 102, a redirection subscription 900 (which is part of data access and subscription state data 114), a thread 902 (created by redirection manager 102), a primary server subscription (primary OPC server) 118, and a secondary server subscription (secondary OPC server) 128. FIG. 9 assumes some starting conditions. The target OPC servers support OPC alarms and events. OPC alarms and events client 101 has connected to the redirection manager. OPC alarms and events client 101 is receiving OnEvent() calls from the redirection manager via the active target OPC event server. The active target OPC event server fails. Table 7 generally describes the specific events shown in FIG. 9. Each event in Table 7 is implemented in example methods shown in FIG. 9. Table 7. OPC Alarms and Events Scenario: Active Target OPC Server Fails FIG. 10 shows how a redirection manager synchronizes an alternate target OPC server when it becomes available, according to the present invention. The components involved in this scenario are node status change provider 112, redirection event server (redirection manager) 102. a redirection subscription 1000 (which is part of data access and subscription state data 114), a thread 1002 (created by redirection manager 102), and secondary event server (secondary OPC server) 128. FIG. 10 assumes some starting conditions. The target OPC servers support OPC alarms and events. The OPC client has connected to the redirection manager and is being serviced by the active target OPC event server. An alternate target OPC event server that was previously not running, starts. Table 8 generally describes the specific events shown in FIG. 10. Each event in Table 8 is implemented in example methods shown in FIG. 10. Table 8. OPC Alarms and Events Scenario: Alternate Target OPC Server Becomes Available (Table Removed) It is to be understood that the above description is intended to be illustrative and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description, such as adaptations of the present invention to revisions to the OPC specification or including the present invention in a larger system so that some components named clients are servers or vice-versa. The present invention has applicability to fields outside process contra! and industrial automation. Therefore, the scope of the present invention should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. WHAT IS CLAIMED IS: 1. A redirection management method, comprising: responding to a first client connection request for a first OPC client by granting said first OPC client a first private connection to a first instance of an OPC redirection manager; and responding to a second client connection request for a second OPC client by granting said second client a second private connection to a second instance of said OPC redirection manager. 2. The method according to claim 1, further comprising: losing said second private connection for said second OPC client when said second instance of said OPC redirection manager fails; and maintaining said first private connection for said first OPC client. 3. The method according to claim 1, further comprising: connecting to a first target OPC server; connecting to an OPC server status change provider for said first target OPC server, and connecting to at least one additional target OPC server, including a second target OPC server configured to backup said first target OPC server. 4. The method according to claim 3, further comprising: upon receiving an active-server-failed event from said OPC server status change provider for said first target OPC server, performing a switchover to said second target OPC server. 5. The method according to claim 4, further comprising: receiving notice from said OPC server status change provider that said first target OPC server is now available; and connecting to said first target OPC server. 6. The method according to claim 3, further comprising: receiving an OPC add-group request from said first OPC client; forwarding said OPC add-group request to said first target OPC server to service said OPC add-group request; upon receiving a request-complete event from said first target OPC server, implementing a plurality of add-group interfaces associated with said OPC add-group request by creating at least one group; forwarding said OPC add-group request to each of said at least one additional target OPC server to store said at least one group as inactive; and storing information related to said OPC add-group request, including said at least one group. 7. The method according to claim 6, further comprising: receiving an OPC on-data-change request from said first OPC client; establishing a connection between said first target OPC server and a first sink object; establishing a connection between said second target OPC server and a second sink object; providing a first on-data-change request to said first OPC client from said first target OPC server, and storing information related to said OPC on-data-change request, including said at least one group. 8. The method according to claim 7, further comprising: upon receiving an active-server-failed event from said OPC server status change provider for said first target OPC server, performing a switchover to said second target OPC server; activating said at least one group on said second target OPC server; and providing a second on-data-change request to said first OPC client from said second target OPC server. 9. The method according to claim 8, further comprising: receiving notice from said OPC server status change provider that said first target OPC server is now available; connecting to said first target OPC server; and using previously stored information to add said at least one group to said first target OPC server. 10. A method of redirection management, comprising: in response to an OPC create-event-subscription request from an OPC client, implementing interfaces associated with said OPC create-event-subscription request; forwarding said OPC create-event-subscription request to a primary target OPC server for service; forwarding said OPC create-event-subscription request to at least one additional target OPC server as inactive, said at least one additional target OPC server including a secondary target OPC server configured to backup said primary target OPC server; and storing information related to said OPC create-event-subscription request, including state information. 11. The method according to claim 10, further comprising: connecting to said primary target OPC server, connecting to an OPC server status change provider for said primary target OPC server, and connecting to said at least one additional target OPC server. 12. The method according to claim 11, further comprising: determining that said primary target OPC server supports OPC alarms and events; and loading an alarms-and-events module, 13. The method according to claim 12, further comprising: providing at least one on-event request to said OPC client from said primary target OPC server, upon receiving an active-server-failed event from said OPC server status change provider for said primary target OPC server, performing a switchover to said secondary target OPC server; and notifying said alarms-and-events module of said switchover. 14. The method according to claim 13, further comprising: retrieving all events from said secondary OPC target server and forwarding said events to said OPC client to prevent loss of events; and providing an OPC on-event request to said OPC client from said secondary target OPC server. 15. The method according to claim 13, further comprising: receiving notice from said OPC server status change provider that said primary target OPC server is now available; connecting to said primary target OPC server, and establishing said primary target OPC server with said state information. 16. An OPC redirection management system, comprising: a first OPC server capable of servicing an OPC request; a second OPC server configured to backup said first OPC server; and- a first redirection manager capable of forwarding an OPC request on behalf of a first OPC client to either said first OPC server or said second OPC server wherein said first OPC client is capable of establishing its own private connection with said first redirection manager; and wherein said first redirection manager is capable of connecting to said second OPC server upon failure of said first OPC server to provide seamless service to said first OPC client. 17. The system according to claim 16, wherein said first redirection manager is capable of storing information associated with said OPC request for use upon failure of said first OPC server. 18. The system according to claim 16, further comprising: a third OPC server; a fourth OPC server configured to backup said third OPC server; and a second redirection manager, wherein a second OPC client is capable of establishing its own private connection with said second redirection manager; and wherein said second redirection manager is capable of connecting to said fourth OPC server upon failure of said third OPC server to provide seamless service to said second OPC client. 19. The system according to claim 16, wherein said first OPC server is capable of being configured to backup a third OPC server. 20. The system according to claim 16, wherein said OPC request is of type data access. 21. The system according to claim 16, wherein said OPC request is of type alarm and events. 22. The system according to claim 16, further comprising: a primary server node comprising said first OPC server, a primary node status change provider, and a primary OPC status change provider, a secondary server node comprising said second OPC server, a secondary node status change provider, and a secondary OPC status change provider; and a client node comprising said first OPC client, said first redirection manager, a client node status change provider, and a client OPC status change provider. 23. The system according to daim 22, wherein said first redirection manager comprises: data access and subscription state data; and a switchover manager. 24. The system according to claim 22, wherein said first OPC server comprises an item cache and a condition database. 25. The system according to claim 16, wherein said first OPC dient is a process control application. 26. The system according to claim 16, wherein said first OPC server communicates with a device to service said OPC request so that said first OPC client receives information about said device as a result of said OPC request. 27. A machine-readable medium storing executable instructions for performing a method, said method comprising: responding to a first client connection request for a first OPC client by granting said first OPC dient a first private connection to a first instance of an OPC redirection manager; responding to a second client connection request for a second OPC client by granting said second OPC client a second private connection to a second instance of said OPC redirection manager; losing said second private connection for said second OPC client when said second instance of said OPC redirection manager fails; and maintaining said first private connection for said first OPC client. 28. The method according to claim 27, further comprising: connecting to a first target OPC server; connecting to an OPC server status change provider for said first target OPC server; connecting to a second target OPC server configured to backup said first target OPC server, and upon receiving an active-server-failed event from said OPC server status change provider for said first target OPC server, performing a switchover to said second target OPC server.

Full Text

OPC SERVER REDIRECTION MANAGER
CROSS REFERENCE
This application claims priority of U.S. Provisional Patent Application Serial No. 60/392493, filed on June 28, 2002, entitled "OPC Server Redirection Manager."
BACKGROUND
1. Field of the Invention.
The present invention generally relates to an OPC server redirection manager, which is an intermediate OPC server that forwards all OPC calls made by clients to actual OPC servers that communicate with data sources. In particular, the OPC server redirection manager maintains the information necessary to take appropriate action when a target OPC server fails and ensures that no bad status is returned to a client.
2. Description of the Related Art
OLE FOR PROCESS CONTROL® (OPC®) is an emerging industry standard that facilitates integration by allowing automation systems to share information and interoperate with other industrial automation, process control, and other business systems for plants or factories. (The letters O-P-C originally stood for Object Linking and Embedding (OLE) for Process Control, but OLE has been restructured from object-orientec to object-based and renamed ActiveX.) The OPC standard is a non-proprietary technical specification that is maintained by the OPC Foundation®.
In the past, each'software or application developer needed to write a custom interface (or server/driver) to exchange data with hardware field devices. The OPC standard replaced this practice by providing a common interface that permits this work to be done once, and then easily reused by Human Machine Interface (HMI), Supervisory Control and Data Acquisition (SCADA) control and custom applications.
The OPC specification is based upon the Microsoft® OLE (now ActiveX), Component Object Model (COM), and Distributed Component Object Model (DCOM) technologies. OPC defines a standard set of interfaces, properties, and methods for use in process control, manufacturing, and automation applications. These applications include distributed control systems, programmable logic controllers, input/output (10) systems, smart field devices, and other servers of real-time information. The ActiveX/COM technologies define how individual software components interact and share data. By using the Microsoft® Visual Basic object-oriented component, OLE Automation, OPC can provide office applications with plant floor data via local area networks (LANs), remote sites, or the Internet.
OPC provides many benefits to end users and hardware and software manufacturers, including open connectivity, high performance, and improved vendor productivity. OPC provides open connectivity giving users a choice among a wider variety of plant floor devices and client software, allowing better utilization of best-in-breed applications. Because OPC is an open standard, software and hardware manufacturers devote less time to connectivity issues and more time to application issues, eliminating significant duplicate effort. OPC fosters greater interoperability between automation and control applications, field devices, and business and office applications.
Some redirection systems provide inferior functionality to the redirection manager according to the present invention and they appear to have different architectures. One redirection system is implemented as a Microsoft Windows® service, whereas the redirection manager according to the present invention uses a private connection approach to limit the impact of failure. Redirection systems implement OPC data access, whereas the redirection manager according to the present invention has redirection servers that implement those as well as OPC alarms and events. Redirection systems appear to implement server/node health via a ping mechanism, whereas the redirection manager according to the present invention uses a monitoring approach with less network traffic overhead. Certain OPC servers synchronize the internal OPC server database for performance and consistency reasons. The redirection manager according to the present invention optionally provides this capability.
Other redirection systems provide a service to which all clients connect. If that service fails, then all connected clients are impacted. By contrast, clients using the redirection manager according to the present invention have a private connection. If the private connection fails, then only the connected client is impacted. Conventional redirection systems use a ping mechanism for detection. This is less efficient than the redirection manager according to the present invention, which uses notification providers to alert the redirection manager when target nodes or servers fail.
The present invention overcomes these problems by maintaining the information necessary for taking appropriate action when the target OPC server fails and for ensuring that no bad status is returned to the client. Any existing OPC client needing seamless failover between target OPC data access and/or alarm and event servers will connect to a uniquely configured instance of the redirection manager instead of connecting to the primary
server. The client application continues to perform OPC related tasks as usual. Because each client connection is unique, the redirection manager itself is not a singie point of failure. Each configured redirection manager instance monitors the health of the target server node and the target server itself by subscribing to failure events. Use of subscription rather than polling (via ping) reduces network traffic. The present invention also provides many additional advantages as described below.
SUMMARY OF THE INVENTION
One embodiment of the present invention is a redirection management method. In response to a first client connection request for a first OPC client, a first private connection is granted from the first OPC client to a first instance of an OPC redirection manager. In response to a second client connection request for a second OPC client, a second private connection is granted from the second OPC client to a second instance of the OPC redirection manager. According to one embodiment, even though the second private connection for the second OPC client is lost when the second instance of the OPC redirection manager fails, the first private connection for the first OPC client is maintained. A connection is made to a first target OPC server. Another connection is made to an OPC server status change provider for the first target OPC server. According to another embodiment, additional connections are made to at least one additional target OPC server, including a second target OPC server configured to backup the first target OPC server.
Upon receiving an active-server-failed event from the OPC server status change provider for the first target OPC server, a switchover to the second target OPC server is performed. Notice is received from the OPC
server status change provider that the first target OPC server is'now available and a connection is made to the first target OPC server.
Assuming no failure had occurred, an OPC add-group request is received from the first OPC client and it is forwarded to the first target OPC server to service. Upon receiving a request-complete event from the first target OPC server, a plurality of add-group interfaces associated with the OPC add-group request are implemented by creating at least one group. The OPC add-group request is forwarded to each of the additional target OPC servers to store the group(s) as inactive. Information is stored that is related to the OPC add-group request, including the group(s).
An OPC on-data-change request is received by the redirection manager from the first OPC client and a connection is established between the first target OPC server and a first sink object. The sink objects belong to the redirection manager. Another connection is established between the second target OPC server and a second sink object. Information related to the OPC on-data-change request, including the at least one group is stored. A first on-data-change request is provided to the first OPC client from the redirection manager following the redirection manager's receipt of the on-data-change request from the first target OPC server. Upon receiving an active-server-failed event from the OPC server status change provider for the first target OPC server, a switchover is performed to the second target OPC server. At least one group is activated on the second target OPC server and a second on-data-change request is provided to the first OPC client from the redirection manager following the redirection manager's receipt of the on-data-change request from the second target OPC server. Notice that the first target OPC server is now available is received from the OPC server status change provider, a connection is made to the first target OPC server and previously stored information is used to add the group(s) to the first target OPC server.
Another embodiment of the present invention is a method of redirection management. In response to an OPC create-eveni-subscription request from an OPC client, interfaces associated with the OPC create-event-subscription request are implemented. The OPC create-event-subscription request is forwarded to a primary target OPC server for service. It is also forwarded as inactive to at least one additional target OPC server, including a secondary target OPC server configured to backup the primary target OPC server. Information related to the OPC create-event-subscription request is stored, including state information.
A connection is made by the redirection manager to the primary target OPC server. Additional connections are made by the redirection manager to an OPC server status change provider for the primary target OPC server and to additional target OPC server(s). If it is determined that the primary target OPC server supports OPC alarms and events, an alarms-and-events module is loaded. At least one on-event request is provided to the OPC client from the primary target OPC server. Upon receiving an active-server-failed event from the OPC server status change provider for the primary target OPC server, a switchover to the secondary target OPC server is performed and the alarms-and-events module is notified of the switchover. A currently active event is synchronized with the secondary target OPC server to prevent loss of data and an OPC on-event request is provided to the OPC client from the secondary target OPC server. When notice from the OPC server status change provider is received that the primary target OPC server is now available, a connection is made to the primary target OPC server and it is established with the state information.
Anther embodiment of the present invention is an OPC redirection management system comprising a first OPC server, a second OPC server, and a first redirection manager. The first OPC server is capable of servicing
an OPC request. The second OPC server is configured to backup the first OPC server. The first redirection manager is capable of forwarding an OPC request on behalf of a first OPC client to either the first OPC server or the second OPC server. The first OPC client is capable of establishing its own private connection with the first redirection manager. The first redirection manager is capable of connecting to the second OPC server upon failure of the first OPC server to provide seamless service to the first OPC client. The first redirection manager is capable of storing information associated with the OPC request for use upon failure of the first OPC server.
The OPC redirection management system may also comprise a third OPC server, a fourth OPC server, and a second redirection manager. The fourth OPC server is configured to backup the third OPC server. A second OPC client is capable of establishing its own private connection with the second redirection manager. The second redirection manager is capable of connecting to the fourth OPC server upon failure of the third OPC server to provide seamless service to the second OPC client. The first OPC server is capable of being configured to backup a third OPC server. The OPC request may be of type data access or alarm and events.
The OPC redirection management system may also comprise a primary server node, a secondary server node, and a client node. The primary server node comprises the first OPC server, a primary node status change provider, and a primary OPC status change provider. The secondary server node comprises the second OPC server, a secondary node status change provider, and a secondary OPC status change provider. The client node comprises the first OPC client, the first redirection manager, a client node status change provider, and a client OPC status change provider. The first redirection manager comprises data access and subscription state data and a switchover manager. The first OPC server comprises an item cache and a condition database. The first OPC client is a process control application.
The first OPC server communicates with a device to service the OPC request so that the first OPC client receives information about the device as a result of the OPC request.
Another embodiment of the present invention is a machine-readable medium storing executable instructions for performing a method. In response to a first client connection request for a first OPC client, a first private connection is granted from the first OPC client to a first instance of an OPC redirection manager. In response to a second client connection request, a second private connection is granted from the second OPC client to a second instance of the OPC redirection manager. A connection is made to a node status change provider for the second OPC client. When the redirection manager fails and the private connection for the second OPC client is lost, the first private connection for the first OPC client is maintained. A connection is made to a first target OPC server. Another connection is made to an OPC server status change provider for the first target OPC server. Another connection is made to a second target OPC server configured to backup the first target OPC server. Upon receiving an active-server-failed event from the OPC server status change provider for the first target OPC server, a switchover to the second target OPC server is performed.
These and other features, aspects, and advantages of the present invention will become better understood with reference to the following drawings, description, and appended claims.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram of a single client connection for a redirection manager system architecture according to the present invention.
FIG. 2 is a block diagram of multiple client connections to multiple instances of a redirection manager according to the present invention.
FIG. 3 is a sequence diagram of how a client connection is made by a redirection manager, according to the present invention.
FIG. 4 is a sequence diagram of how a redirection manager maintains state information related to an OPC add-group request, according to the present invention.
FIG. 5 is a sequence diagram of how a redirection manager handles OPC on-data-change requests, according to the present invention.
FIG. 6 is a sequence diagram of how a redirection manager handles the failure of the active target OPC server, according to the present invention.
FIG. 7 is a sequence diagram of how a redirection manager synchronizes an alternate target OPC server when it becomes available, according to the present invention.
FIG. 8 is a sequence diagram of how a redirection manager maintains state information on behalf of a client for an OPC create-event subscription request, according to the present invention.
FIG. 9 is a sequence diagram of how a redirection manager handles failure of the active target OPC server when the target servers support OPC alarms and events, according to the present invention.
FIG. 10 is a sequence diagram of how a redirection manager synchronizes an alternate target OPC server when it becomes available, according to the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
In the following detailed description, reference is made to the accompanying drawings. These drawings form a part of this specification and show by way of example specific preferred embodiments in which the present invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the present invention. Other embodiments may be used. Structural, logical, and electrical changes may be made without departing from the spirit and scope of the present invention. Therefore, the following detailed description is not to be taken in a limiting sense and the scope of the present invention is defined only by the appended claims.
FIG. 1 shows a single client connection for a redirection manager system architecture according to the present invention. Within a client node 100 is an OPC client 101 which is connected to a single instance of a redirection manager 102 that, in turn, communicates with components inside a primary OPC server'node 104 and components inside a backup OPC server node 106. Components inside primary OPC server node 104 and backup OPC server node 106 communicate with a device 108.
OPC client 101 connects to redirection manager 102 instead of directly connecting to primary OPC server node 104. Redirection manager 102 is configured for OPC client 101 using a configuration utility. Once configuration is complete, OPC client 101 continues to perform OPC related tasks as usual. Each configured redirection manager 102 is registered so
that it points to an installed executable. At the time of client connection, a new instance of redirection manager 102 is created. This new instance executes in a unique process address space. It is identifiable to OPC client 101 by a unique identification for status purposes. In addition to an instance of redirection manager 102, Client node 100 has an OPC server status change provider 110 and a node status change provider 112.
Redirection manager 102 is an intermediate OPC server that forwards OPC requests made by OPC client 101 to primary OPC server node 104 that communicates with device 108. Redirection manager 102 maintains the information necessary to take appropriate actions when primary OPC server node 104 fails and ensures that no bad status is returned to OPC client 101. Redirection manager 102 has data access and subscription state data 114 and a switchover manager 116 to change the active server.
Primary OPC server node 104 communicates with device 108 and other data sources that OPC client 101 wants access to reading and writing data and is configured to be a primary server for redirection manager 102. In addition, primary OPC server node 104 is configurable as a secondary server for a different redirection manager than redirection manager 102 (see FIG. 2). The active OPC server is either primary OPC server node 104 or the backup OPC server node 106 and is the server that is currently servicing the OPC requests for OPC client 101 through redirection manager 102. Primary OPC server node 104 has an OPC server 118 with* ah item cache 120 and a condition database 122, a node status change provider 124, and an OPC server status change provider 126. Current data values are stored in item cache 120 and alarm states are stored in condition database 122.
Secondary or backup OPC server node 106 is the active OPC server when primary OPC server node 104 fails. In addition, backup OPC server node 106 is configurable as a primary server for a different redirection
manager (see FIG. 2). Like primary OPC server node 104, backup OPC server node 106 has an OPC server 128 with an item cache 130 and a condition database 132, a node status change provider 134, and an OPC server status change provider 136.
Device 108 is a data source that is capable of servicing data access or IO requests as well as pushing alarms and events to OPC servers.
Redirection manager 102 according to the present invention is an OPC server that may support OPC Data Access 2.05 and 1.0A, OPC Alarms and Events 1.0 and OPC Security 1.0 interfaces as well as other OPC data access, OPC alarms and events and other OPC interfaces known presently or in the future. It is not a true OPC server in the sense that it does not communicate with real data sources, and instead is used to forward client calls to and from the actual OPC servers and to maintain state information allowing it to switch to a backup server when the primary server fails. Redirection manager 102 is implemented as an out-of-process .exe server (see FIG. 2). There is one .exe server per client connection to redirection manager 102. Those OPC requests that alter the state of the client connection but do not request IO are made to both the primary and backup servers, e.g., primary OPC server node 104 and backup OPC server node 106. IO requests are only made to primary OPC server 118. This puts the secondary in a hot-standby mode. In the event that primary OPC server 118 fails, redirection manager 102 activates the backup OPC server 128 and issues IO requests. Since OPC client 101 is unaware of the switch, it can significantly reduce error handling scenarios in OPC client 101 itself. Redirection manager 102 supports a cold-standby redundancy scheme as well. In this case, state is not replicated to backup OPC server 128. All state is set up at switchover time.
Redirection manager 102 also supports optional browsing interfaces. Redirection manager 102 forwards all the calls to either primary OPC server 118 or backup OPC server 128 or to all servers, while maintaining state information related to the calls for redirection purposes. The server that is currently servicing IO requests is referred to as the active server. In the event, the currently active server fails, redirection manager 102, as part of the switchover process, sets one of the backup servers to be the new active server.
Redirection manager 102 saves the state of the requests of OPC client 101 to redirect them or reissue them to a backup server when the primary server fails and also for various other scenarios. One approach is to categorize the client calls as IO and non-IO requests. The classification is made as follows. Those OPC requests that alter the state of the client connection but do not request IO are classified as non-IO requests, such as add-group, add-item, create-event-subscription, and set-filter-calls. Client IO calls are classified as IO requests, such as read, write, and ack-condition.
Persisting state of these calls is handled differently. Non-IO calls are maintained as long as OPC client 101 is running. One scenario where this information is needed is to sync-up a backup server that comes up after OPC client 101 has made add-group and add-items calls. The IO call information is persisted only until either the primary or backup, server services the call. Once the call successfully completes, the IO information about the call is deleted.
Redirection manager 102 examines all the errors returned by the active server. Those errors which indicate a failure along the communication path between redirection manager 102 and the active server will cause redirection manager 102 to initiate a switchover. Those errors which do not indicate a failure along this communication path are forwarded to OPC client 102. OPC
client 101 handles these errors the same way as it would if connected to the servers directly. Redirection manager 102 saves the state of all non-IO calls and hence can attempt the re-sync. All OPC calls categorized as non-IO are sent to both the primary and backup servers. The call has to succeed on the active server before the request is issued to the backup server. If the request fails on the backup, the error is logged but not returned to the client. At this point, the backup server is considered out of sync with the active server. The Redirection Manager attempts to re-sync the backup on a switchover. If the re-sync fails, the Redirection Manager does not switchover to the secondary.
During initialization, redirection manager 102 establishes a connection with the target servers, e.g., primary OPC server node 104 and backup OPC server node 106. Also, redirection manager 102 establishes connections with status change providers, such as OPC server status change provider 110 to subscribe to events that may trigger switchover manager 116. For node failures, redirection manager 102 connects to node status change provider 112. Node status change provider 112 communicates with peer node status change providers, such as node status change provider 106 to monitor the health of other nodes. Similarly, redirection manager 102 establishes a remote subscription connection to the OPC server status change providers, such as OPC server status change providers 126 and 136 on each target OPC server node, such as primary OPC server node 104 and backup OPC server node 106. Changes in server state are forwarded to redirection manager 102. If primary OPC server node 104's OPC server 118 transitions from a running state, then redirection manager 102 initiates a switchover to backup OPC server node 106 through switchover manager 116. If backup OPC server 128 transitions from the running state and becomes unavailable, subsequent transition to running results in synchronization.
Redirection manager 102 reports its status to OPC server status change provider 110.. This enables integration with a hosting system status display component. The health of the connection from OPC client 101 to redirection manager 102 as well as the health of target OPC servers 118, 128 are exposed to the user.
OPC client 101 makes OPC requests to redirection server 102 as if it were directly connected to target OPC servers 118, 128. For each client group creation, redirection manager 102 forwards the request to the active and backup OPC servers 118,128. Requests to activate the group collection are only performed on the active OPC server. Group data collection is inactive on the backup servers. Similarly, requests to activate event subscriptions are only performed on the active OPC server. Event subscriptions remain inactive on the backup OPC servers.
Requests to collect particular data sources may require conversion to a name within the namespace of device 108. If device 108 is remotely located, this name conversion operation may be costly in terms of performance. Therefore, redirection manager 102 is optimized to synchronize the device namespace handles without requesting multiple conversion operations for device 108.
Redirection manager 102 makes all the OPC calls or requests to primary OPC server 118 and backup OPC server 128 on separate threads. This allows OPC calls that fail due to server failure to be reissued to backup OPC server 128. After creating the thread, primary OPC server 118 waits on a request-complete event signaled by the thread issuing the call to backup OPC server 128. Once the event is signaled, primary OPC server 118 returns the results back to OPC client 101. Redirection manager 102 also waits on an active-server-failed event to be signaled when the active server fails. If this event is signaled, redirection manager 102 looks for an alternate
server and reissues the failed request to that server. An internal timeout period is added to the waits to take care of those scenarios that notification providers or redirection manager 102 itself may not handle, in this way, if either of the above two events are not signaled, redirection manager 102 is not left hanging forever. The timeout period is provided as a configuration option.
There is an approach followed for callbacks both for data access as well as alarm and events. Redirection manager 102 implements all the callbacks of OPC client 101. It intercepts the callbacks of the active OPC server, holds all the sink interfaces of OPC client 101, and issues the callbacks to OPC client 101. This ensures that no bad values are returned to OPC client 101 during switchover. For data access, no asynchronous read or write calls are missed when the active server fails before callback can happen. Redirection manager 102 keeps track of whether the callbacks were completed, and reissues the call again to the backups-when the switchover happens. Redirection manager 102 callback forwards the event to the client on-event callback or forwards the data request to the on-data-change callback. When the active server fails, redirection manager 102 activates the client subscriptions or data access groups on the secondary server. Redirection manager 102 refreshes event subscriptions and starts processing callbacks from the secondary server.
FIG. 2 is a block diagram of multiple client connections to multiple instances of a redirection manager according to the present invention. Client node 200 has an installed redirection manager binary executable 202. A configuration tool creates entries for registered redirection managers in a registration table 204 that resides in the Microsoft Windows® registry. Configuring includes identifying the target OPC servers. When a client, such as client one 206, connects to a registered redirection manager, such as redirection manager one 208, a new instance of the installed redirection
manager binary executable 202 is created. Each instance executes in its own process space, is independent of any other running instance, and is visible to the native operating system. Clients connect to various multiple registered redirection managers, such as redirection manager one, two, three, and four. If the first instance of redirection manager one 208 fails, then only client one 206 is effected, because client three 216 has its own private connection to the second instance of redirection manager one 218. The registered redirection managers, in turn, communicate with multiple OPC servers, such as OPC server 210. Multiple OPC servers.reside in server nodes, such as server node 212. Multiple server nodes reside in clusters, such as OPC server node cluster 214. There can be any number of clients, redirection managers, OPC servers, server nodes, and OPC server node clusters.
FIGS. 3-10 are sequence diagrams for a number of scenarios of how a redirection manager operates according to the present invention. Although the redirection manager is designed to accommodate two or more target OPC servers, the sequence diagrams use only two target OPC servers (i.e., primary and secondary). This is for illustrative purposes only, to make the sequence diagrams simpler and more easily understood. The first target to which the redirection manager successfully connects is referred to as the active server. The remaining target OPC servers are referred to as alternates. The redirection manager according to the present invention supports specifications from both the OPC data access and OPC alarms and events initiatives. In the following scenarios, a particular initiative may be mentioned, but the redirection manager according to the present invention is able to service both data access clients and alarms and events clients simultaneously.
Each table below for FIGS. 3-10 summarizes the specific events in the corresponding figure. However, there is not a one-to-one correspondence
between the event numbers in the tables and the step numbers in FIGS. 3-
10.
FIG. 3 shows how a client connection is made by a redirection manager, according to the present invention. Each of the components identified in the boxes along the top of FIG. 3 run in separate processes. These components are client 101, redirection manager 102, node status change provider 112, primary OPC server 118, primary server status change provider 126, secondary OPC server 128, and secondary server status change provider 136.
FIG. 3 assumes some starting conditions. The user or administrator has used a configuration tool to create a named instance of a redirection manager server. This instance includes the identification of target OPC servers. This information is stored by the configuration tool into a registry location known to the redirection manager runtime (see FIG. 2). All target OPC servers are available.
Table 1 generally describes the specific events shown in FIG. 3. Each event in Table 1 is implemented in example methods shown in FIG. 3.
Table 1. Client Connection
(Table Removed)
FIG. 4 shows how a redirection manager maintains state information related to an OPC-add-group request, according to the present invention. The components involved in this scenario are client 101, redirection manager 102, a redirection group 400 (in data access and subscription state data 114), a primary add-group thread 402 (created by redirection manager 102), a secondary add-group thread 404 (created by redirection manager 102),
primary server 118, and secondary server 128. The scenario assumes that both primary server 118 and secondary server 128 are available.
FIG. 4 assumes some starting conditions. The administrator has made the necessary configuration using the redirection manager configuration utility to register redirection manager 102. Also, the OPC client 101 made a connection to redirection manager 102.
Table 2 generally describes the specific events shown in FIG. 4. Each event in Table 2 is implemented in example methods shown in FIG. 4.
Table 2. OPC Data Access Scenario: AddGroup
(Table Removed)
FIG. 5 shows how a redirection manager handles OPC on-data-change requests, according to the present invention. The components involved in this scenario are client 101, a redirection group 400 (which is part of data access and subscription state data 114), a redirection manager (RDM) primary sink 502, a redirection manager (RDM) secondary sink 504, a primary group 506 (which is part of primary OPC server 118), and a secondary group 508 (which is part of secondary OPC server 128). This scenario describes how redirection manager 102 handles OPC on-data-change requests and assumes that all the target OPC servers are available.
FIG. 5 assumes some starting conditions. The OPC client 101 has connected to the redirection manager and has added groups and items. The groups and items have been added to all the target OPC servers.
Table 3 generally describes the specific events shown in FIG. 5. Each event in Table 3 is implemented in example methods shown in FIG. 5.
Table 3. OPC Data Access Scenario: OnDataChange
(Formula Removed)
FIG. 6 shows how a redirection manager handles the failure of the active target OPC server, according to the present invention. The components involved in this scenario are OPC client 101, redirection group 400, redirection manager (RDM) primary sink 502, redirection manager (RDM) secondary sink 504, primary group 506, primary component status provider 126, and secondary group 508.
FIG. 6 assumes some starting conditions. OPC client 101 has connected to the redirection manager. OPC client 101 is receiving OnDataChange() calls from the redirection manager via the active target OPC server. The active target OPC server fails.
Table 4 generally describes the specific events shown in FIG. 6. Each event in Table 4 is implemented in example methods shown in FIG. 6.
Table 4. OPC Data Access Scenario: Active Target OPC Server Fails
(Formula Removed)
FIG. 7 shows how a redirection manager synchronizes an alternate target OPC server when it becomes available, according to the present invention. The components involved in this scenario are OPC client 101, redirection manager 102, primary OPC server 118, primary server status change provider 126, secondary OPC server 128, and secondary server status change provider 136.
FIG. 7 assumes some starting conditions. OPC client'10*1 has connected to redirection manager 102 and is being serviced by the active target OPC server. An alternate target OPC server that was previously not running, starts.
Table 5 generally describes the specific events shown in FIG. 7. Each event in Table 5 is implemented in example methods shown in FIG. 7.
Table 5. OPC Data Access Scenario: Alternate Target OPC Server Becomes Available
(Formula Removed)
FIG. 8 shows how a redirection manager maintains state information on behalf of a client for an OPC create-event subscription request, according to the present invention. The components involved in this scenario are OPC alarms and events client 101, redirection event server (redirection manager) 102, a redirection subscription object 804 (which is part of data access and subscription state data 114), a separate thread 806 (created by redirection manager 102), primary event server 118, and secondary event server 128.
This scenario describes how the redirection manager maintains state information on behalf of an OPC alarm and events client. Specifically, this is shown for the state information related to an OPC CreateEventSuascription call. This scenario assumes that both the Primary and Secondary servers are available. A switchover event is used in lieu of an active-server-failed event, as in the OPC data access scenarios. Because the redirection manager's OPC alarms and events capabilities are contained within a separate module which is only loaded if alarms and events support is needed by OPC alarms and events client 800, the module itself does not monitor the availability or health of the target servers. Instead,-the redirection manager's alarms and events module relies on those facilities contained within the main redirection manager. These main facilities detect a target server failure or service a request to manually switch to an alternate target server, but in either case the alarms and events module simply receives the more generic switchover event.
FIG. 8 assumes some starting conditions. Both primary and secondary servers are available. OPC alarms and events client 800 made a connection to the redirection manager. The redirection manager loaded the alarms and event support module, after detecting that the target OPC servers support OPC alarms and events. OPC alarms and events requests made by the client are being serviced by this module.
Table 6 generally describes the specific events shown in FIG. 8. Each event in Table 6 is implemented in example methods shown in FIG. 8.
Table 6. OPC Alarms and Events Scenario: Create Event Subscription
(Table Removed)
FIG. 9 shows how a redirection manager handles failure of the active target OPC server when the target servers support OPC alarms and events, according to the present invention. The components involved in this scenario are OPC alarms and events client 101, redirection event server (redirection manager) 102, a redirection subscription 900 (which is part of data access and subscription state data 114), a thread 902 (created by redirection manager 102), a primary server subscription (primary OPC server) 118, and a secondary server subscription (secondary OPC server) 128.
FIG. 9 assumes some starting conditions. The target OPC servers support OPC alarms and events. OPC alarms and events client 101 has connected to the redirection manager. OPC alarms and events client 101 is receiving OnEvent() calls from the redirection manager via the active target OPC event server. The active target OPC event server fails.
Table 7 generally describes the specific events shown in FIG. 9. Each event in Table 7 is implemented in example methods shown in FIG. 9.
Table 7. OPC Alarms and Events Scenario: Active Target OPC Server Fails
FIG. 10 shows how a redirection manager synchronizes an alternate target OPC server when it becomes available, according to the present invention. The components involved in this scenario are node status change provider 112, redirection event server (redirection manager) 102. a redirection subscription 1000 (which is part of data access and subscription
state data 114), a thread 1002 (created by redirection manager 102), and secondary event server (secondary OPC server) 128.
FIG. 10 assumes some starting conditions. The target OPC servers support OPC alarms and events. The OPC client has connected to the redirection manager and is being serviced by the active target OPC event server. An alternate target OPC event server that was previously not running, starts.
Table 8 generally describes the specific events shown in FIG. 10. Each event in Table 8 is implemented in example methods shown in FIG. 10.
Table 8. OPC Alarms and Events Scenario: Alternate Target OPC Server Becomes Available
(Table Removed)
It is to be understood that the above description is intended to be illustrative and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description, such as adaptations of the present invention to revisions to the OPC specification or
including the present invention in a larger system so that some components named clients are servers or vice-versa. The present invention has applicability to fields outside process contra! and industrial automation. Therefore, the scope of the present invention should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

WHAT IS CLAIMED IS:
1. A redirection management method, comprising:
responding to a first client connection request for a first OPC client by granting said first OPC client a first private connection to a first instance of an OPC redirection manager; and
responding to a second client connection request for a second OPC client by granting said second client a second private connection to a second instance of said OPC redirection manager.
2. The method according to claim 1, further comprising:
losing said second private connection for said second OPC client when said second instance of said OPC redirection manager fails; and maintaining said first private connection for said first OPC client.
3. The method according to claim 1, further comprising:
connecting to a first target OPC server;
connecting to an OPC server status change provider for said first target OPC server, and
connecting to at least one additional target OPC server, including a second target OPC server configured to backup said first target OPC server.
4. The method according to claim 3, further comprising:
upon receiving an active-server-failed event from said OPC server status change provider for said first target OPC server, performing a switchover to said second target OPC server.
5. The method according to claim 4, further comprising:
receiving notice from said OPC server status change provider that said first target OPC server is now available; and connecting to said first target OPC server.
6. The method according to claim 3, further comprising:
receiving an OPC add-group request from said first OPC client;
forwarding said OPC add-group request to said first target OPC server
to service said OPC add-group request;
upon receiving a request-complete event from said first target OPC server, implementing a plurality of add-group interfaces associated with said OPC add-group request by creating at least one group;
forwarding said OPC add-group request to each of said at least one additional target OPC server to store said at least one group as inactive; and
storing information related to said OPC add-group request, including said at least one group.
7. The method according to claim 6, further comprising:
receiving an OPC on-data-change request from said first OPC client;
establishing a connection between said first target OPC server and a first sink object;
establishing a connection between said second target OPC server and a second sink object;
providing a first on-data-change request to said first OPC client from said first target OPC server, and
storing information related to said OPC on-data-change request, including said at least one group.
8. The method according to claim 7, further comprising:
upon receiving an active-server-failed event from said OPC server status change provider for said first target OPC server, performing a switchover to said second target OPC server;
activating said at least one group on said second target OPC server; and
providing a second on-data-change request to said first OPC client from said second target OPC server.
9. The method according to claim 8, further comprising:
receiving notice from said OPC server status change provider that said first target OPC server is now available;
connecting to said first target OPC server; and
using previously stored information to add said at least one group to said first target OPC server.
10. A method of redirection management, comprising:
in response to an OPC create-event-subscription request from an OPC client, implementing interfaces associated with said OPC create-event-subscription request;
forwarding said OPC create-event-subscription request to a primary target OPC server for service;
forwarding said OPC create-event-subscription request to at least one additional target OPC server as inactive, said at least one additional target OPC server including a secondary target OPC server configured to backup said primary target OPC server; and
storing information related to said OPC create-event-subscription request, including state information.
11. The method according to claim 10, further comprising:
connecting to said primary target OPC server,
connecting to an OPC server status change provider for said primary target OPC server, and
connecting to said at least one additional target OPC server.
12. The method according to claim 11, further comprising:
determining that said primary target OPC server supports OPC alarms and events; and
loading an alarms-and-events module,
13. The method according to claim 12, further comprising:
providing at least one on-event request to said OPC client from said primary target OPC server,
upon receiving an active-server-failed event from said OPC server status change provider for said primary target OPC server, performing a switchover to said secondary target OPC server; and
notifying said alarms-and-events module of said switchover.
14. The method according to claim 13, further comprising:
retrieving all events from said secondary OPC target server and
forwarding said events to said OPC client to prevent loss of events; and
providing an OPC on-event request to said OPC client from said secondary target OPC server.
15. The method according to claim 13, further comprising:
receiving notice from said OPC server status change provider that said primary target OPC server is now available;
connecting to said primary target OPC server, and
establishing said primary target OPC server with said state information.
16. An OPC redirection management system, comprising:
a first OPC server capable of servicing an OPC request;
a second OPC server configured to backup said first OPC server; and-
a first redirection manager capable of forwarding an OPC request on
behalf of a first OPC client to either said first OPC server or said second
OPC server
wherein said first OPC client is capable of establishing its own private connection with said first redirection manager; and
wherein said first redirection manager is capable of connecting to said second OPC server upon failure of said first OPC server to provide seamless service to said first OPC client.
17. The system according to claim 16, wherein said first redirection
manager is capable of storing information associated with said OPC request
for use upon failure of said first OPC server.
18. The system according to claim 16, further comprising:
a third OPC server;
a fourth OPC server configured to backup said third OPC server; and
a second redirection manager,
wherein a second OPC client is capable of establishing its own private connection with said second redirection manager; and
wherein said second redirection manager is capable of connecting to said fourth OPC server upon failure of said third OPC server to provide seamless service to said second OPC client.
19. The system according to claim 16, wherein said first OPC server is capable of being configured to backup a third OPC server.
20. The system according to claim 16, wherein said OPC request is of type data access.
21. The system according to claim 16, wherein said OPC request is of type alarm and events.
22. The system according to claim 16, further comprising:
a primary server node comprising said first OPC server, a primary node status change provider, and a primary OPC status change provider,
a secondary server node comprising said second OPC server, a secondary node status change provider, and a secondary OPC status change provider; and
a client node comprising said first OPC client, said first redirection manager, a client node status change provider, and a client OPC status change provider.
23. The system according to daim 22, wherein said first redirection
manager comprises:
data access and subscription state data; and a switchover manager.
24. The system according to claim 22, wherein said first OPC server comprises an item cache and a condition database.
25. The system according to claim 16, wherein said first OPC dient is a process control application.
26. The system according to claim 16, wherein said first OPC server communicates with a device to service said OPC request so that said first OPC client receives information about said device as a result of said OPC request.
27. A machine-readable medium storing executable instructions for performing a method, said method comprising:
responding to a first client connection request for a first OPC client by granting said first OPC dient a first private connection to a first instance of an OPC redirection manager;
responding to a second client connection request for a second OPC client by granting said second OPC client a second private connection to a second instance of said OPC redirection manager;
losing said second private connection for said second OPC client when said second instance of said OPC redirection manager fails; and
maintaining said first private connection for said first OPC client.
28. The method according to claim 27, further comprising:
connecting to a first target OPC server;
connecting to an OPC server status change provider for said first target OPC server;
connecting to a second target OPC server configured to backup said first target OPC server, and
upon receiving an active-server-failed event from said OPC server status change provider for said first target OPC server, performing a switchover to said second target OPC server.

Documents:

4194-delnp-2004-Abstract-(19-10-2012).pdf

4194-delnp-2004-abstract.pdf

4194-delnp-2004-Claims-(19-10-2012).pdf

4194-delnp-2004-claims.pdf

4194-delnp-2004-Correspondence-Others-(19-10-2012).pdf

4194-delnp-2004-correspondence-others.pdf

4194-delnp-2004-description (complete).pdf

4194-delnp-2004-Drawings-(19-10-2012).pdf

4194-delnp-2004-drawings.pdf

4194-delnp-2004-form-1.pdf

4194-delnp-2004-form-18.pdf

4194-delnp-2004-Form-2-(19-10-2012).pdf

4194-delnp-2004-form-2.pdf

4194-delnp-2004-Form-3-(19-10-2012).pdf

4194-delnp-2004-form-3.pdf

4194-delnp-2004-form-5.pdf

4194-delnp-2004-GPA-(19-10-2012).pdf

4194-delnp-2004-gpa.pdf

4194-delnp-2004-pct-101.pdf

4194-delnp-2004-pct-102.pdf

4194-delnp-2004-pct-105.pdf

4194-delnp-2004-pct-202.pdf

4194-delnp-2004-pct-210.pdf

4194-delnp-2004-pct-220.pdf

4194-delnp-2004-pct-224.pdf

4194-delnp-2004-pct-301.pdf

4194-delnp-2004-pct-304.pdf

4194-delnp-2004Petition-137-(19-10-2012).pdf

abstract.jpg

« Previous Patent

Next Patent »

Patent Number

257271

Indian Patent Application Number

4194/DELNP/2004

PG Journal Number

38/2013

Publication Date

20-Sep-2013

Grant Date

20-Sep-2013

Date of Filing

31-Dec-2004

Name of Patentee

HONEYWELL INTERNATIONAL INC.

Applicant Address

101 COLUMBIA ROAD, P.O. BOX 2245, MORRISTOWN, NEW JERSEY 07960, UNITED STATES OF AMERICA

Inventors:

#	Inventor's Name	Inventor's Address
1	ANURADHA VIDYASHANKAR	19198 NORTH 68TH AVENUE, GLENDALE, AZ 85308, USA
2	TIMOTHY FORTIN	2624 EAST CORTEZ STREET, PHOENIX, AZ 85028, USA
3	ELLEN B. HAWKINSON	3539 EAST KACHINA DRIVE, PHOENIX, AZ 85044, USA

PCT International Classification Number

H04L 29/06

PCT International Application Number

PCT/US2003/020798

PCT International Filing date

2003-06-30

PCT Conventions:

#	PCT Application Number	Date of Convention	Priority Country
1	10/403,704	2003-03-31	U.S.A.
2	60/392,493	2002-06-28	U.S.A.