The present invention is related to U.S. patent application No. 09/902201, filed on 7/10/2001 and entitled "transaction data communication for a process control system," the entire disclosure of which is hereby incorporated by reference.
Prior Art
Process control systems used in production processes such as chemicals, petroleum, etc. typically contain 1 or more centralized process controllers communicatively coupling at least 1 host or operator workstation to 1 or more field devices via analog, digital or combined analog/digital buses. The field devices may be, for example, valves, valve positioners, switches and transmitters (e.g., temperature, pressure and flow rate sensors) that perform functions within the process such as opening and closing valves and measuring process parameters. The process controller receives signals indicative of process measurements made by the field devices and/or other information pertaining to the devices, uses this information to implement a control routine that generates control signals that are sent over the buses or other communication lines to the field devices to control the operation of the process, and 1 or more applications executed by the operator workstation may obtain the information from the field devices and the controller to enable the operator to perform desired functions on the process, such as observing the current state of the process, modifying the operation of the process, etc.
Process control systems typically operate in an operating enterprise that may contain several control devices, components, and/or service providers and customers distributed over a wide geographic area or around the world. Process control devices, providers, and customers may communicate over various communication media and technologies or platforms, such as the internet, satellite links, terrestrial wireless transmissions, telephone lines, etc. Of course, the internet has become a preferred communication platform for many operating enterprises as the communication infrastructure has been established, the cost of the enterprise in that direction is nearly zero, and the technologies used to transfer the information are well known, stable, reliable, etc.
Each process control device within an enterprise may contain 1 or more process control systems and several other business systems or information technology systems that support the maintenance of the required or complementary process control system operations. Information technology systems within process control devices may include manufacturing execution systems (e.g., maintenance management systems) and may also include enterprise resource planning systems (e.g., height, accounting, and procurement systems). While these information technology systems may be located within or near a device, sometimes some or all of these systems may be located remotely from the device and communicate with the device using other suitable communication links. In any event, to improve or optimize the overall operation of an enterprise, some recent development-intensive efforts have been directed toward facilitating faster and more efficient communication within the enterprise and more complete integration between process control systems and information technology systems.
Each process control device may also include a user-interactive application executing on a server or workstation. The server or workstation is communicatively coupled to 1 or more servers, utility stations, or other computers that coordinate or effectuate the activities of the process control system within the plant. The user interactive application may perform a plan management function, a resume data management function, an asset management function, a batch management function, and the like. Additionally, each process control system within a plant may also include process management applications that may, for example, manage communications, provide information regarding alarms and/or other processing events, provide information or data regarding the status of processes performed by the process control plant, provide information or data regarding the status or performance of equipment associated with the process control plant, etc. In particular, the process management applications may include vibration monitoring applications, real-time optimization applications, expert system applications, predictive maintenance applications, control loop monitoring applications, or any other application related to controlling, monitoring, and/or maintaining a process control system or device. The process control device or enterprise may also include 1 or more communication applications for communicating information from the process control system or device to a user via various communication media and platforms. For example, these communication applications may include email applications, paging applications, voice messaging applications, file-based applications, etc., all of which are adapted to send information to a desktop computer, laptop computer, personal data assistant, cellular telephone or pager, or other type of device or hardware platform via wireless media or hardwired media.
In general, effective integration of information technology systems, user-interactive applications, process management applications, and communication applications is difficult, if not impossible, to achieve because these systems and applications are widely distributed throughout an enterprise, sometimes geographically remote. In addition, these systems and applications often require the development of custom communication interfaces or software drivers that enable the different systems and applications to communicate with each other. Thus, when any system, application, device, or component within an enterprise changes due to, for example, a firmware upgrade, a device replacement, etc., the custom communication driver or interface for that system, device, or component must also be changed. Obviously, the requirement for a large number of custom drivers results in a large time consuming driver maintenance, resulting in a high enterprise maintenance cost. Additionally, adding systems or applications to an enterprise or process control plant often requires a significant amount of programming personnel because many custom communication drivers or interfaces must be developed in order for the new system or application to communicate with other systems and applications within the enterprise. Thus, systems employing such custom communication interfaces are inflexible or inflexible and do not facilitate integration of the process control system with other systems and applications provided by the system manufacturer or 3 rd party manufacturer or developer.
In addition to the difficulties associated with initiating communication between the many different systems, applications and services that make up an enterprise, there is also a general problem in enabling system users or operators to effectively monitor selected enterprise information specific to their intra-enterprise responsibilities and/or their personal preference information. For example, engineers are concerned with the operation of a particular control loop for a particular section of a process plant, while executives are concerned with the overall production output of a particular plant, regardless of the details regarding the control loop, the plant, etc.
Another difficulty with existing systems is the inability of a system user or operator to configure and/or add applications, services or systems to an enterprise or process control device. In contrast, these existing systems typically require skilled programmers to service, configure and/or synthesize previously unconfigured and integrated applications, services and systems. For example, a skilled programmer must have an extensive knowledge of how the application, service, or system to be configured and/or integrated will work, and must also generate a configuration program and 1 or more custom communication drivers or interfaces that enable the system, application, or service to communicate with other systems, applications, or services within the enterprise.
Some recent development efforts have focused on the use of extensible markup languages to facilitate communications between applications, systems, and services that make up an enterprise. It is generally known that extensible markup languages such as XML can be used to enable different systems, applications and/or services to be loosely coupled to one another so that each different system, application and/or service does not have to have an exhaustive knowledge of what other systems, applications and/or services can work with in order to communicate with one another. Some recently developed systems may combine the use of XML with network communication protocols (such as SOAP; simple object access protocol) and network transport protocols (such as HTTP: hypertext transport protocol) to enable these loosely coupled services, applications, and/or systems to communicate over a network such as the internet.
Newly developed products that enable communication between systems, applications and services within an enterprise using XML, SOAP, and/or HTTP, etc., provide only limited information exchange between information technology systems, limited configuration capabilities, limited scalability or flexibility to add services, systems or applications, and limited information viewing capabilities. Lighthammer software development Inc. sells one such commercially available product, the IlluminatorTM. In general, many of these recently developed products are collectively referred to as portal applications (e.g., illuminants)TMAs is the product). The portal application enables selective viewing of information collected and processed centrally by the server from multiple systems, applications and/or services within the enterprise. While these recently developed portal applications, and in particular the Illuminator product, may facilitate communication between systems, applications and services within an enterprise, it does not enable users or system operators to add systems, services or applications to the enterprise. These recently developed portal applications also do not enable system users and operators to selectively display information collected from a plurality of other applications, services and systems within the system based on detailed documentation associated with a particular user or operator. Instead, these portal applications only allow users to select 1 from a few predefined information display configurations that are basic to the organization's responsibility department, such as engineering design, management, manufacturing, etc.
In addition, these known portal applications (e.g., the I11 atom products) typically aggregate large amounts of data from each data provided by the process plants within the enterprise, regardless of whether the user or operator needs to view or utilize the data. For example, these known portal applications can aggregate available data within a database of servers or computers communicatively connected to various data sources. The central based server or other computer system then performs various analyses on the aggregated data, sending some or all of the aggregated data and analysis results to a viewing application that displays information to the user. Unfortunately, the data aggregation approach employed by these known portal applications results in the transfer of large amounts of data that may or may not be needed by a user over a communication network, such as the internet, making the transmission of data in real-time or timely manner difficult, if not impossible, to achieve.
Furthermore, since the server that performs the data aggregation also performs the required aggregated data analysis, the analysis consumes a large amount of processing resources of the server, regardless of whether the user requires the analysis result. Moreover, since it is known that portal applications aggregate data to be displayed or transmitted to users centrally, intra-server communication failures or power failures that accomplish the aggregation function can result in catastrophic failures, completely disabling the exchange of information between systems, applications and/or services within the enterprise until power and/or communications are restored to the central server, all of the data is recollected, and the required analysis is re-performed. In other words, these known portal applications employ a system architecture that uses a central server for data aggregation or analysis, which does not provide a robust environment for the integration of systems, applications, and/or services within an enterprise.
Description of the invention
The web services communication systems and methods described herein may be used with process control systems and devices to facilitate the communication and viewing of information associated with the process control systems or devices. In particular, the web service communication system and method includes a communicator for performing message routing, scheduling and configuration functions for a plurality of clients or web services. In addition, the described web services communication system and method also includes a graphical user interface that enables 1 or more users to configure and/or add web services to the system and to create a highly personal profile that enables the communicator to communicate selected process control information and other information to be displayed to the user via the graphical user interface in a manner desired by the user. The web services, communicators and graphical user interfaces may communicate with each other over a network, such as the internet, using an extensible markup language (e.g., XML) or other similar language that enables applications, services and/or systems to communicate with each other without the need to develop custom communication interfaces or drivers.
In general, the web services may include data services or data sources and data users or data consumers. For example, the data traffic or data sources may be: a process control system or application, an asset management system or application, a device condition monitoring system or application, a diagnostic system or application, or other system or application that retrieves or generates information or data associated with a process control system or device. In another aspect, the data user or data consumer may include user-interactive applications, such as a plan management system or application, a computerized maintenance management system or application, and may also include communication systems or applications, such as a paging system or application, an email system or application, a file generation system or application.
In any event, each data service and data consumer may be an application or system that includes a web service interface. As is well known, the interface may use an extensible markup language such as XML in conjunction with messaging protocols (such as SOAP: simple object Access protocol) and communication transfer protocols (such as HTTP: Hypertext transfer protocol). Because web services are typically of a relatively typical nature (i.e., the nature of the communication through the web server interface is independent of the underlying application or system), data services and data consumers can more easily connect to (i.e., communicate with) communicators without having to establish a custom communication interface as is often the case with existing systems. Furthermore, the communicator may advantageously be adapted to automatically or upon user indication discover web services available for connecting to the communicator. For example, the communicator may specify available web services with a web service discovery tool or service (such as UDDI: Universal discovery description and integration or other type of web service discovery tool or service).
The web services communication system and method also provides a data structure for efficient and robust data aggregation, data analysis, and data communication. And in particular the communicator, may request data from the data service when it is needed. In addition, 1 or more data services may be configured to asynchronously notify the communicator when new data and new information is available. In either case, the system and method can achieve efficient use of communication resources (e.g., communication links, processing capacity within a communication machine). Specifically, as opposed to existing systems where all available data is aggregated from a data source regardless of whether the data is needed, each data service communicates only newly available data and/or data needed by the communicator.
Also, using the web service, the data service can perform complex analysis, and the results of the analysis (plus raw data, if necessary) are transmitted to the communicator, from which they are transmitted to the graphical user interface and/or other data consumers. Thus, the web services communication system and method facilitates efficient utilization of available communication network bandwidth as it is adapted to transmit only requested and/or newly available data, and only analysis results if needed (as opposed to requiring all data to be analyzed at a centralized location, such as a communicator or graphical user interface application).
The web services and methods also provide a high degree of data robustness. Specifically, each web service is responsible for data storage, data history storage, and the like. Thus, a communication failure and/or power failure of the communicator and/or graphical user interface does not result in catastrophic data loss, and system recovery can be accomplished quickly and conveniently when power and/or communication of the communicator and/or graphical user interface is restored. Similarly, a web service failure will not result in catastrophic failure of the entire system, and the failed web service recovery system can easily begin communicating with the service without the need for reconfiguration, rebooting, etc.
Referring now to FIG. 1, a functional block diagram illustrates an example of a web services communication system 100 that may be used with a process control device or system (e.g., FIG. 4). As shown in FIG. 1, the system 100 includes a plurality of data services 102-106, a plurality of data consumers 108-112, an information server 114, a graphical user interface 116, and a discovery service 118, all communicatively coupled to a network 120. The data services 102-106 are generally systems or applications that perform data gathering, generating, and/or analyzing actions. The data services 102-106 may be, for example, process management applications or other types of applications executed by other computers of 1 or more servers in a process control system or plant associated with the system or plant. Of course, the data services 102-06 may correspond to 1 or more than 1 process control system or device. Additionally, if desired, 1 or more of the data services 102-106 may be associated with systems and/or applications other than process control systems or applications.
Each data service 102-106 may include field devices, controllers, workstations, etc. each connected via 1 or more communication networks and/or other types of communication links 102-106 that may perform process control actions (such as executing control loops), diagnostic actions, asset management actions, etc. for a particular process plant or set of devices associated with a portion of a process plant. Each of the data services 102-106 may also perform data logging functions, including redundant devices or failure relief devices, and may perform data analysis operations, all of which are well known in the art and will not be described in further detail herein.
The data services 102-106 preferably each include a communication interface 122-126, such that when the system 100 is connected to the network 120, the data services 102-106 can communicate within the system as web services. The web services communication interfaces 122-126 may be implemented as XML messages formatted with SOAP other desired message protocols and packaged for transmission using, for example, the HTTP web transport protocol. Web services, XML message generation, SOAP and HTTP are well known and will not be described in further detail herein.
The data consumers 108-112 are generally systems or applications that perform actions or functions that consume process control data and/or communicate data or information provided by the data services 102-106 to system users or operators. One or more of the data consumers 108-112 can use a specific communication medium and communication platform to perform basic communication functions that can communicate data or information to the system user or operator. For example, 1 or more data consumers may communicate data using a hardwired or wireless medium and using a desired system or hardware platform, such as a laptop, personal data assistant, email, or the like. Additionally, 1 or more data consumers 108-112 can complete basic user interaction actions (such as lot provisioning and orchestration management actions) and/or can complete other basic business actions, such as contract processing actions, accounting actions, product shipping and management actions, product inventory control actions, quality assurance actions, purchasing actions, and the like. Like the data services 102-106, the data consumers 108-112 may also each include a web service communication interface 128-132, enabling the data consumers 108-112 to communicate as web services within the system 100.
As shown in FIG. 1, the information server 114 includes a dispatcher 134, a router 136, and a database 138 that collectively function as a communicator 140 that performs message routing and dispatching actions and system configuration actions, as described in more detail below. The communicator 140 can establish a plurality of data service connections 142-146 corresponding to 1 data service 102-106, respectively, and can similarly establish a plurality of data consumer connections 148-152 corresponding to data consumers 108-112. The communicators 140 may dynamically establish connections 142-152 as needed to communicate with the data services 102-106 and the data consumers 108-112 via the respective web service interfaces 122-126 and 128-132.
The router 136 generally performs message routing functions, receives messages from one or more web services including the data services 102-106 and the data consumers 108-112 connected to the network 120 via the connections 142-152, and routes the received messages to appropriate destinations, which may be web services connected to the network 120 (e.g., the data services 102-106 and the data messagers 108-112). In particular, the router 136 may operate in a manner similar to an XML transaction server. The processor 136 may use input and output schemes in conjunction with business rules, data management, etc. to send XML messages received from one or more web services connected to the network 120 to another 1 or more web services. The business rules and data management, etc. are stored in the database 138. And retrieved therefrom; or may be provided by another web service to which network 120 is connected.
By way of example, the data service 102 may generate alert information that needs to be communicated to the data consumer 112, which may be a communication system or application (such as an email system or application). When generating the information, the data service 102 uses its web service interface 122 to package the information into XML messages in an XML schema, encapsulates the XML messages with HTTP, and sends them to the network 120. The network 120 sends XML messages to the 1 appropriate data service connections available within the information server 114 in a well-known manner using HTTP encapsulation. The communicator 140 receives the XML message from the 1 data service connection 142-146 on which it was received, and the router 136 decodes the message with the appropriate input scheme (retrieved from the database 138). The router 136 then maps the message content, or portions thereof, to an output scheme associated with the destination (i.e., the data consumer 112), which may also be retrieved from the database 138, based on the content of the decoded message and 1 or more rules and/or data management. The router 136 then encapsulates the mapped alert message (i.e., XML message) with HTTP and sends the encapsulated message to the data consumer 112 over the 1 data consumer connection 148-152 to the data messenger 112 associated with the data consumer 112 and the network 120. The data consumer 112 then receives the alert information via its web services interface 132 and generates an electronic function message that passes the alert information to 1 or more designated users.
Thus, the router 136 is adapted to process messages received from a plurality of web services, such as data services, via a communication network and forward the messages to other web services also connected to the communication network. These messages are preferably expressed in XML or other extensible markup language. Since all of the data generating and data consuming applications or systems comprising system 100 are configured to communicate with web services, information server 114 and particular communicators 140 can dynamically establish communication with the data generating or consuming applications or systems via add-drop connections (e.g., connections 142-152) without having to generate any customized communication interfaces or drivers and without stopping operation of communicators 140 (i.e., connections for applications can be established without interfering with the communication between the connected web services and communicators 140). Conversely, because each of the data services 102-106 and second data consumers 108-112 includes a web services interface and the communicator 140 is adapted to communicate with web services, any web service to which the information server 114 or the network 120 is connected does not require detailed knowledge of the operation of the system or application performed by any other web service for enabling information exchange between web services via the information server 114.
The scheduler 134 generally performs a high level of functionality that enables the communicator 140 to periodically request information from 1 or more of the data services 102-106. Specifically, the scheduler 134 may establish periodic requests for information or data for 1 pair or more of the data services 102-106, particularly requests for information of the type that do not generate events. For example, if 1 of the data consumers 108-112 periodically requires information or data from 1 of the data services 102-106 that would have generated an alarm unconventionally, such as the value of a control loop, the scheduler 136 may be configured to periodically send a message to 1 or more of the data services 102-106 requesting the value or data of the control loop. The 1 or more data services 102-106 receiving the request may then send data to the information server 114 in the form of XML messages encapsulating HTTP, which in turn is sent by the router 136 over the network 120 to the appropriate ones of the data consumers.
The discovery service 118 also includes a web service interface 154 that enables the service 118 to communicate with the information server 114, the data services 102-106, and/or the data consumers 108-112 as needed. The discovery service 118 may be a web services directory registration service, such as UDDI or other similar or different web services directory. As is known, UDDI enables a web service to discover and retrieve interface and/or communication information about another web service, which a master discovery web service or server can use to automatically establish communication with the discovered web service.
The system 100 may use the discovery service 118 to automatically establish communications between the information server 114, the data services 102-106, and the data consumers 108-112 without intervention by system users or operators, programmers, etc. By way of example, when the system causes power to be turned on or powered up, the information server 114 and the particular communicator 140 may communicate with the discovery service 118 to determine what services are connected by the network 120 and what services are available to the system 100. Communicator 140 may store available web services and communication interface information pertaining to the services in database 138. Communicator 140 can then automatically update the information periodically such that web services become unavailable, become available, and/or the information changes, and the information is reflected in database 138 for use by communicator 140 in routing and scheduling communications.
Each web service that is discovered, authorized (if needed), and connected to the information server via network 120 has its associated 1 unique Service Identifier (SID). In this manner, communicator 140 may store communications interface information and other information pertaining to each available web service in a table or other data structure in database 138. Router 136 and scheduler 134 may then use the table or data structure to route messages received from a particular service and schedule requests for information from the particular service.
The graphical user interface (the operation of which is discussed in further detail below in conjunction with fig. 5-20) performs functions that enable a system user or operator to selectively view information provided by the data services 102-106 and/or data consumers 108-112, configure communications (e.g., schedule information requests, establish routes, etc.) within the system 100, and/or substantially interact with applications or services communicatively connected to the network 120 via the information server 114. The type of information provided by the graphical user interface 116 and the manner in which it is provided may vary from user to user depending on the profile specified by the user and stored in the database 138. As an example, a user may first interact with the system 100 via the graphical user interface 116 to specify a profile and information or content to be displayed by the user. A particular user profile may contain information associated with the user's choreography duties (e.g., manager, engineer, administrative staff, etc.), the user's work hours (e.g., the user's shift), the user's personal preferences, the manner and time of exposure to the user on or off duty, etc. The user profile information may be sent by the graphical user interface 116 to the information server 114 for storage in the database 138.
In addition to user profile information, the database 138 may also store configuration information associated with each user. The user may interact with the graphical user interface 116. In a manner establishing how users are to view information from the data services 102-106 and data consumers 108-112, how users are to transfer information between web services connected by the network 120, and so forth.
To store the configuration information for each user, a table is generated in the database 138 to assign 1 unique identifier or User Id (UID) to each user and to store the configuration of each available web service desired by the user along with the UID and the SID of the service.
As an example, a user may be authenticated with their username and password when logged into the graphical user interface 116. This username and password information may, in turn, be used to establish or associate with a security identifier (e.g., UID). Graphical user interface 116 may send the user's UID to information server 114, retrieving the profile and configuration information associated with the UID from database 138. The communicator 140 can then use this information to establish message routing, the manner in which the scheduler 134 requests information from the data services 102-106, the type and manner in which the graphical user interface 116 displays the information, etc., while the user (or at least the user's UID) remains under control of the graphical user interface 116.
Although the graphical user interface 116 (and its associated software applications) is illustrated in FIG. 1 as being performed in a separate system, server, workstation, or computer, the interface 116 may instead be illustrated as being within the information server 114 or other server or computer system to which the network 120 is connected, if desired. Of course, network 120 may connect additional graphical user interfaces similar to graphical interface 116 so that multiple users can interact with system 100 at the same time or at different times. Further, it should be appreciated that while the exemplary system shown in FIG. 1 illustrates network 120 as a single network (such as the Internet) linking all of the components in system 100, a variety of other network configurations may be employed instead. For example, some or all of the data traffic 102-106 may be connected to the information server 114 via Ethernet, while some or all of the data consumers 108-112 may be connected to the information server 114 via another separate network based on Ethernet or other protocols or standards. Of course, web services and other components in communication with the information server 114 (e.g., the graphical user interface 116) may communicate over any combination of desired network types (e.g., Ethernet, Internet, etc.) using any combination of hardwired and wireless communication media.
FIG. 2 is an example block diagram of one manner in which the web services communication system 100 of FIG. 1 may be adapted for use with a process control device or system. The example 200 shown in fig. 2 includes the information server 114, the graphical user interface 116, the discovery service 118, and the network 120 shown in fig. 1. However, the system 200 includes various web services typically associated with process control devices or systems. As shown in FIG. 2, the system 200 may include an asset management web service 202, a look-ahead control and condition monitoring web service 204, and a diagnostics web service 206. Each web service 202-206 may generally correspond to the data services 102-106 shown in FIG. 1. Additionally, each of the services 202-206 may include applications executed by different servers, workstations, or other computer systems within a particular process control plant or system. For example, the asset management web service 202 may comprise a server hosting 1 or more asset management software applications for a particular process control device. These asset management applications can perform process optimization operations based on a variety of information including, for example, process control parameters, maintenance information, business information, etc., in an effort to maximize equipment profitability. The advanced control and condition monitoring web service 204 may perform alarm functions, process condition monitoring functions (such as loop monitoring functions, real-time optimization functions, expert system functions, etc.), and device condition monitoring functions (such as vibration monitoring functions, predictive maintenance functions, etc.). The diagnostic web service 206 may contain various applications for performing device diagnostic functions, such as providing information associated in a blocked impulse line, information associated with a failure in the middle of a communication, and the like. Regardless, the web services 202-206 include some application of data analysis actions that capture data and/or generate analysis result data, and thus are characterized similarly to data services.
The system 200 shown in FIG. 2 also includes a plurality of web services characterized similarly to data consumers, for example, the system 200 includes an email web service 208, a paging web service 210, a Computerized Maintenance Management System (CMMS) web service 212, a personal data assistant web service 214, a file system web service 216, a curation management web service 218, and an business rules web service 220. The email web service 208 is adapted to generate email messages from messages received from 1 or more data services, such as the asset management web service 202, the look-ahead control and condition monitoring web service 204, and the diagnostics web service 208. The email web service 208 may send these email messages to, for example, 1 or more user interfaces of the type with the graphical user interface 116 and/or other computer systems accessible to the user. In a similar manner, paging web service 210 may receive a message containing, for example, alert information from another web service in system 200 via information server 114 and network 120, and may transmit information regarding the alert to 1 or more users (e.g., maintenance personnel, technicians, etc.) or to 1 or more pagers associated with personnel associated with system 200.
Personal data assistant web service 214 can receive messages containing information from data sources such as web services 202-206 and transmit the information contained in the messages to 1 or more personal data assistant computers that are carried or operated by different users or persons, respectively. In this manner, a system user may configure the system 200 to send selected detailed information regarding the operation of the process control device or system, including, for example, diagnostic information, look-ahead control and condition monitoring information, asset management information, or other information, to the personal data assistant computer, if desired.
The file system web service 216 may receive messages containing process control data, diagnostic data from one or more of the web services 202-206 via the information service 114 and the network 120 and store the information contained therein in one or more data files, which may then be accessed, transmitted, printed, displayed, etc.
CMMS web service 212, orchestration management web service 218, and business rules web service 220, which are characterized similarly to user-interactive applications or services. CMMS web service 212 and, for example, enables a user to configure the type and manner in which alert information should be communicated. The CMMS web service 212 may additionally perform functions to generate electronic or paper-based work orders that may be printed or displayed at a central location, such as a maintenance department in a process control equipment installation facility, and transmitted directly to personnel responsible for the corresponding work orders, etc. CMMS web service 212, in turn, generates the component replacement instructions required to service the process control devices associated with system 200. The instructions are in turn sent in the form of an HTTP encapsulated XML message to an administration system, such as a procurement system (not shown), communicatively connected to network 120.
The orchestration management web service 218 may contain the required orchestration management applications for specifying and managing 1 or more batch processes performed in the process control devices. The business rules web service 220 contains 1 or more applications that change the operating parameters of the process control device or system based on data received from the process control application and/or the business application. Both the plan management application and the business rule application are known and will not be described in further detail herein.
It is important to know that data or information typically flows from web services such as asset management web service 202, look-ahead control and condition monitoring web service 204, and diagnostics web service 206 to basic data consuming web services such as email web service 208, addressing web service 210, CMMS web service 212, personal data assistant web service 214, file system web service 216, curation management web service 218, and business rules web service 220; the web services 202-206 generally capture data, analyze the data, and generate analysis result data. However, any of the web services 202-220, the discovery service 118, and the graphical user interface 116 may send messages via the network 120 and the information server 114, or exchange information with 1 or more of the other web services 202-220, the discovery service 118, and the graphical user interface 116.
In operation, the system 200 is initially unaware of any of the web services 202-220, and the information server 114 does not host any user profiles or profiles, and thus does not initially send any messages from any data sources (i.e., web services 202-206) to any data consumers (i.e., web services 208-220). The information server 114 then discovers the various available web services 202-220 connected by the network 120 using the discovery service 118. In particular, the information server 114 may retrieve communication interface information (e.g., schema information, network address information, etc.) from the discovery service 118 and store this information in its database 138 (FIG. 1) along with the SIDs that uniquely identify each web service discovered. Once the information server 114 obtains the communication interface information and other configuration information associated with the discovery web service, the router 136 (FIG. 1) initiates an exchange of messages between the web services 202-220 and the graphical user interface 116.
The user interacts with the graphical user interface 116 to establish user profiles and configurations, which are stored in the database 138 along with the UIDs of the respective users, as will be described in further detail below in conjunction with FIGS. 5-20. The graphical user interface 116 may use the user profile and configuration controls to display the type and manner of data to each user, and the information server 114 may also use the user profile and configuration controls the manner in which messages are forwarded between the web services 202-220. In this manner, when a particular user enters authentication information (e.g., a username and password) into the graphical user interface 116, the information server 114 retrieves the unique security identifier (i.e., UID) associated with that user. The information server 114 may then use the UID to retrieve configuration information associated with the user's UID from the database 138, configure the router 136 and scheduler 134 to operate so that messages are automatically delivered to the graphical user interface 116 in a manner dictated by the user's configuration and/or profile. When the graphical user interface 116 is implemented with an internet browser application, the messages passed by the information server 114 to the graphical user interface 116 are preferably based on hypertext markup language (HTML), rather than XML, so that the information can be displayed to the user in the desired format using a conventional browser application. When a different user logs into the graphical user interface 116, the information server 114 automatically forwards the message in a manner that provides information to the graphical user interface 116 as dictated by the user's configuration. Thus, each user using the interface 116 may automatically change the format and content of the displayed information to suit the user's configuration and/or profile.
Of course, the graphical user interface 116 may contain 1 or more security measures to prevent unauthorized users from obtaining detailed information about the system 200 from the information server 114 and from entering or modifying configurations and/or profiles in the system 200. System 200 may use 1 or more such security measures to determine whether to allow access by personnel to receive system 200 and the access range at which it is allowed. In other words, some users may be allowed more or greater access privileges than others, enabling 1 user to view and/or modify any configuration and/or profile information associated with system 200, while another user is only allowed to view selected information, not to modify any configuration or profile information.
Although the content and format of information displayed in the graphical user interface 116 may vary from user to user logged into or using the interface 116, the message routing configurations associated with data consuming web services (e.g., web services 208-220) remain valid for each user profile stored in the database 138 (FIG. 1). Thus, a user who is not logged into the interface 116 (or any other interface in the system 100) will still continue to receive messages via the email web service 208, the paging web service 210, or other web service specified by their stored profile. For example, a process control system associated with the advanced control and condition monitoring web service 204 may generate an alarm, and the web service 204 may transform the alarm into an XML message, encapsulate the XML with HTTP, and send the message to the information server 114 via the network 120. The information server 114 then processes the received alert message so that the user profile and scheme stored in the database 138 may be used to determine the object and manner of delivery of the alert message. Information server 114 may then cause router 136 (fig. 1) to send the alert message to 1 or more users using 1 or more data consuming web services (e.g., web services 208-220). In particular, the router 136 may send an alert message to 1 user via the email web service 208 and the paging web service 210, an alert message to another user via the paging web service 210 and the personal data assistant 214, and an alert message to the graphical user interface 116 that is to be displayed to a user who has entered a configuration to display the alert when logged into the user interface 116 or other similar user interface in the system 100, based on the user's profile.
Fig. 3 is a more detailed functional block diagram of the look-ahead control and condition monitoring web service 204 shown in fig. 2. As shown in fig. 3, the look-ahead control and condition monitoring web service 204 includes an input/output (I/O) subsystem block 250, a process control subsystem block 252, and an embedded look-ahead control and condition monitoring block 254, which together form a process control system 255. In addition, the web service 204 includes a web service block 256 and a web service interface 258, both of which function to enable the process control system 255 to exchange information and messages with other web services via the network 120 (FIGS. 1 and 2) and the information server 114 (FIGS. 1 and 2). The I/O subsystem block 250 includes the controller, I/O devices and field devices to which they are connected, discussed in further detail below in conjunction with FIG. 4. The control subsystem block 252 is preferably, but not necessarily, implemented as 1 or more software programs or applications executable in 1 or more workstations of other computer systems. By way of example, the process control subsystem block 252 may include process control functions, operator interface functions, alarm and event handling functions, real-time data processing functions, or other desired functions.
The look-ahead control and condition monitoring block 254 may be implemented with a number of software programs or applications that process data or information associated with the operation, condition, etc. of a process control system, such as the process control system 300 shown in FIG. 4. For example, the block 254 may include a vibration monitoring program or application, a real-time optimization or application, an expert system program or application, a pre-test maintenance program or application, a loop monitoring program or application, or other desired data analysis or data processing program or application. The 1 or more programs or applications executed by the look-ahead control and condition monitoring block 254 may be performed on the same computer system used to execute the program or application associated with the process control subsystem block 252 or may be performed on any other workstation or computer system coupled to the process subsystem block.
The web services block 256 may contain an alarms and events and interfaces block 260, a process conditions monitoring block 262 and a device conditions monitoring block 264, all communicatively coupled to web services listeners 266, 268 and 270, respectively. In addition, the web services block 256 also includes a web services listener 272 that is communicatively coupled directly to the process control subsystem block 252 of FIG. 3. In general, the web services block 256 enables information or actual data associated with alarms or events, process conditions, and equipment conditions within the process control system to be transceived to the information server 114 (FIGS. 1 and 2). In particular, because commonly used transport protocols such as HTTP and data languages such as XML and SOAP and formatting protocols may be used to communicate process control information to the information server 114, the web services block 256 provides a partial web services framework or structure that facilitates system internal communications.
The web service listeners 266-272 receive incoming messages containing service requests, respectively, and issue the service requests to the appropriate methods available in the web services block 256. The web service listeners 266-272 preferably receive service requests and also provide service responses, but this is not necessarily the case. The listeners 266-272 can provide contracts and other documents associated with the web service or services with which the listener is communicating. In addition, the web service listeners 266-272 preferably communicate alarm and event data, process status data, and equipment status data using XML.
A web services interface 258 manages communication between the web services block 256 and the web services in the information server 114, and the server 114, such as a web client, may communicate with the process control system via the web services interface block 258. The web services interface block 258 generally provides a host environment or web server environment (i.e., a common interface) that enables a plurality of technically diverse information systems, such as manufacturing execution systems, enterprise resource rule systems, etc., or other systems associated with remotely located process control device clients, suppliers, etc., to send and receive process control information or data to and from the process control subsystem block 252 and the advanced embedded control and condition monitoring block 250. In particular, the web services interface 258 is adapted to listen to incoming HTTP requests, perform security checks involving user authentication/verification, look for connection information and issue an authorized HTTP request to establish a connection with the 1 appropriate web services listener 266-272 available in the web services block 256, facilitate automatic recovery from service failures, host environment and system failures, provide management facilities for deploying, monitoring and controlling services and managing resources, such as processes, dispatch groups and shared status on behalf of each service.
The web services interface 258 may respond to HTTP-based requests to perform authentication of the requesting entity (e.g., another web service) as the correct client of the web services block 256. Client authentication may be based on a user identification (i.e., UID and/or other identifier), the identity of the requesting entity itself, a terminal location, or other suitable identification method. If the entity is authenticated as the correct client. The web services interface 258 establishes a connection with the 1 appropriate web services listener 266272 in the web services block 256. For example, the entity is interested in device alarm information, the web services interface 258 may establish a web services connection associated with the web services getter 266 and the alarm and event interface block 260. Once the connection is established, any type of process control information accessible to the web service may be transmitted between the requesting client and the process control system using HTTP packets containing data in XML format.
When a device within the I/O subsystem block generates a device alert, such as a reminder maintenance alert, the block 250 sends the reminder to the web services block 256 via the alert and event interface 260. The web service associated with the web service listener 266 and the interface 260 converts the received alert into XML format and sends the XML alert message or data to the information server 114 via the network 120. Of course, as noted above, appropriate input and output schemes require appropriate delivery of device alert information from the information server 114 to the appropriate data consuming application or web service.
It should be appreciated that the web services framework or architecture provided by the web services interface 258 and the web services block 256 enables authenticated clients to exchange information or data with the I/O subsystem block 250 and the process control subsystem block 252 using XML-based communications encapsulated in HTTP packets. Thus, any device capable of executing an internet browser application may communicate with the advanced control and condition monitoring web service 204 via the web service interface 258 and the web service block 256. For example, a remote terminal or handheld computer device adapted to execute a browser application may communicate with the advanced control and condition monitoring web service 204 via the Internet or other generally suitable communication link.
Fig. 4 is a schematic block diagram illustrating, by way of example, one manner in which the web service 204 may be implemented. As shown in FIG. 4, the web service 204 generally includes a process control system portion 300 and a web service portion 302 that correspond to the process control system block 255 and the web service block 256, respectively, shown in FIG. 3. The process control system 300 includes controllers 304 and 306 and input/output (I/O) device groups 310 and 312 connected to a host workstation or computer 308 (which may be any type of personal computer or workstation) to which are connected 1 or more field devices 314-328. The controllers 304 and 306 may be, for example, Delta V sold by Fisher-Rosemount systems, IncTMA controller and host computer 308 through, for example, an ethernet connection 330 or other suitable communication link. Likewise, the controllers 304 and 306 connect the field devices 314-328 with the required hardware or software associated with, for example, standard 4-20 mA devices and/or intelligent communication protocols such as the Fieldbus protocol or the HART protocol.
As is known, the controllers 304 and 306 may implement or monitor their stored or associated process control routines and communicate with the field devices 314-328 to control the processes performed by the process control system 300 in a desired manner. The field devices 314-328 may be any type of device such as sensors, valves, transmitters, positioners, etc., while the I/O cards 332-338 in the banks 310 and 312 may be any type of I/O device that conforms to a desired communication or controller protocol such as HART, Fieldbus, Profibus, etc. In the example process control system 300 of FIG. 4, the field devices 314-316 are standard 4-20 mA devices that communicate over analog lines to an I/O card 332, the field devices 317-320 are HART devices that interface to a HART compatible I/O card 336, and the field device 321 is a smart device, such as a Fieldbus field device, that communicates over digital buses 340 and 342 to the I/O cards 334 and 338 using, for example, Fieldbus protocol communications. Of course, the field devices 314-328 and the I/O card sets 310 and 312 may conform to other desired standards or protocols, including standards or protocols developed in the future, in lieu of the 4-20 mA, HART, or Fieldbus protocols.
The workstation or computer 308 also contains software 344 that, when executed by the workstation 308, performs process control functions, such as real-time data collection and analysis, alarm and event handling, operator interface functions, control functions, and the like. In addition, software 344 may also perform proactive control and condition monitoring functions such as vibration monitoring, real-time optimization, dedicated system analysis, predictive maintenance, loop monitoring, and the like. Thus, the I/O device banks 310 and 312, including the controllers 304 and 306 and their attached field devices, generally correspond to the I/O subsystem block 250 shown in FIG. 3. The workstation or computer 308 and its listening software 344 generally correspond to the process control subsystem and the embedded look-ahead control and condition monitoring blocks 252 and 254 shown in FIG. 3. Although fig. 4 shows the functions of blocks 252 and 254 being performed by software 344 in 1 workstation (i.e., workstation 308), the various functions performed by blocks 252 and 254 may be performed by 2 or more workstations or computers connected to network 330, if desired.
As shown in FIG. 4, the web services portion 302 includes a computer and workstation 346 within which software 348 is stored. Workstation 346 communicatively connects network 330 and network 120 (fig. 1 and 2). The workstation, when executing the software 348, performs the functions of the web services and web services interface blocks 256 and 258 shown in fig. 3. However, it should be appreciated that the software 348 could instead be stored in and executed by the workstation 308, if desired, thereby eliminating the need for multiple workstations.
Before describing the functionality of the graphical user interface 116 (fig. 1 and 2) in detail, it is important to note that the interface 116 may be implemented by execution of an internet browser application in a workstation or computer connected to the network 120. The information server 114 then transmits the HTML formatted page or file that can be conveniently displayed by the browser software executed by the interface 116. The HTML page displayed by the interface 116 may contain process control information, analysis results, current user specific configuration information, general information, etc., as discussed in further detail below in conjunction with fig. 5-20. Although the graphical user interface 116 is described herein as being implemented using Internet browser software, and the information server 114 is adapted to generate information in the HTML format used by the interface 116, the implementation of the graphical user interface 116 may instead employ non-browser software (i.e., specially developed graphical user interface software) designed to receive messages from the information server 114 in XML or other data types and formats.
Fig. 5 illustrates an example of a display window 400 that may be displayed when the graphical user interface 116 (fig. 1 and 2) is used by an authorized user. The window 500 includes a title area 402, a tree selection guide 404, and an active display area 406. The header area 402 may contain textual information and/or other graphical information about the software executed by the interface 116. Personal greetings to the user, general messages or other information to which the system the interface 116 is currently communicating is directed, general news or other information, such as weather, date and time, etc.
The tree selection guide 404 contains a hierarchical layout of various features, services and/or functions, which may be accomplished by the graphical user interface 116, the information server 114, and any available web services with which the server can communicate. The active display area 406 displays information to which the user currently selects (e.g., highlighting and selecting with a mouse or keyboard) the feature or function of the interface 116 via the tree selection guide 404 belongs. An internet browser application executable by interface 110 generates window 400, and the content in window 400 (e.g., display 406, tree 404, etc.) is generated by information server 114 and sent as an HTML message over network 120 to the browser application executed by interface 116.
Fig. 6 illustrates an example of a screen 450 displayed in the active display area 406 in response to a user selecting a particular configuration service. In the example shown in fig. 6, the user selects "service 1" for configuration. In this example, service 1 is an application or service that analyzes or examines the performance of the control loop or module and sends selected results back to the user. For example, service 1 may be performed by the advanced control and condition monitoring web service 204 shown in fig. 2 and 3. In any event, as shown in the example screen 450, a report name field 452 and a report description field 454 are provided to enable a user to enter a file name for a report received in connection with service 1. The analysis range specifying section 456 allows the user to select a specific control system to be analyzed and further specifies a function block type to be analyzed. The user may select the drop-down key header numbers 458 and 460 to view the control system menus that may be analyzed and the types of function blocks that may be used for analysis. Error type selection field 462 enables a user to select 1 or more error types for the control system and function block analysis selected by timing section 456. As an example, the user may select error types such as inaccurate states, limited control, unstable input, and large fluctuations. Section 464 enables a user to select some of the modules in the control system to be analyzed. As shown in FIG. 6, the user may specify the maximum number of modules or all of the modules in the selected control system that may be selected for analysis. The report time span part 466 allows the user to select a time period for which the service 1 performs its analysis, and the user may specify the current shift, previous shift, current day, or previous day, as an example. Of course, other time periods may be given as options if desired, and the schedule information portion 468 allows the user to configure the scheduler 134 (FIG. 1) to periodically retrieve the information needed for service 1 as web services from selected control systems that are admitted to a server (such as information server 114) via a network (such as network 120). If the schedule for the selected control system is not specified, the user may select a configure schedule key 470 to configure the schedule, as described below in conjunction with FIG. 7. The destination information section 472 allows the user to select a destination (e.g., a web service) to which the analysis result generated by the service 1 is to be delivered. The user may select the configure destination key 474 to configure the destination, as described below in connection with fig. 8. The user may select page restore key 476 to clear all information entered or selected within page 450, or may select clear key 478 to clear any selections or entries and return to another screen (e.g., home). If the user wishes to accept the information entered and/or selected in page 450, an OK key 480 may be selected.
Fig. 7 is an example of a scheduler configuration screen 500 that may be displayed in the display area 406 of the window 400 when the user selects the configuration piece 470 shown in fig. 6. This screen 500 contains a report name and description area 502 that displays the information entered by the user in the sections 452 and 454 shown in FIG. 6. The screen 500 also includes an analysis start time section 502, a cycle selection section 506, an analysis end time section 508, an OK key 510, and a cancel key 512. In the start time section 504, the user can enter or select the date and time at which the service 1 begins to be analyzed. In the period selection unit 506, the user can select an analysis period of the service 1. For example, the user may specify that every few minutes, hours, days, weeks, months, etc., have service 1 repeat its analysis. In the analysis end time section 508, the user can configure the service 1 so as not to stop the analysis at all times, to stop the analysis after a certain analysis period specified by the period selection section 506, or to stop the analysis at a certain date. If the user selects the OK key, the information entered or selected by the user in screen 500 is saved and screen 450 is again shown in active display area 406. Conversely, if the user selects the cancel key 512, the information entered or selected in the screen 500 is not saved, and the screen 450 is shown in the active display area 406.
Fig. 8 is an example of a destination screen 520 that may be displayed in the existing display area 406 of the window 400 when the user selects the destination key 474 shown in fig. 6. The screen 520 includes a destination selection unit 522. Although the example screen 520 shown in FIG. 8 only shows options for email destinations, the screen may display various other web service-based options. For example, any of the example web services shown in FIG. 2 (e.g., paging, email, personal data assistant, etc.) may be listed for selection by the user at configuration destination screen 520. In addition, the report type section 524 allows the user to specify whether the report to be sent to the selected destination is a detailed report or a summary report, and whether the data format of the report is text-based or HTML or XML-based. Configuration destination screen 520 also includes an OK key 526 that, when selected by the user, saves the information selected or entered by the user and causes active display area 406 to display screen 450 (fig. 6).
After the user has completed selecting and/or entering configuration information for service 1 at screens 450, 500, and/or 520 as described above, the user may select OK key 480 at screen 450 and send configuration information to information server 114 (fig. 1) to perform configuration of router 136 (fig. 1) and scheduler 134 (fig. 1). The configuration information is preferably sent to the information server 114 along with a unique user identifier (such as a UID) and a service identifier (such as a SID) uniquely associated with service 1. Server 114, upon receiving configuration information (along with the UID and SID) entered and/or selected by the user at screen 450 from graphical user interface 116, communicates the configuration information to the web service associated with service 1. Information server 114 may use the SID to retrieve from database 138 the communication interface information related to the web service of service 1, thereby enabling server 114 to properly communicate configuration information for the web service associated with service 1.
After the web service associated with service 1 receives the configuration information from server 114, the web service creates an XML stream containing XML configuration information (such as an XML schema) that can be used to control router 136 and scheduler 134, and sends the stream back to server 114, along with the UID (associated with the current user of graphical user interface 116) and SID (associated with service 1) to database 138. In this manner, the web service associated with service 1 indicates to the information server 114 how the scheduler 134 and router 136 are configured to perform the functions of service 1 as specified by the user at screens 450, 500 and/or 520. For example, scheduler 134 may periodically retrieve data from a web service associated with service 1 and send the retrieved data to the user at a particular destination specified in screens 450, 500, and 520.
Fig. 9 illustrates an example report screen 530 that provides information about reports available to a user. This screen 530 may be displayed in the active display area 406 (FIG. 5) based on the user's selection of the "self report" down-tree selection guide 404 in Business 1. The report screen 530 includes a caption section 532, an available report details section 534, a selected report delete key 536, and a new report add key 538. The caption part 532 may contain information about the current user of the graphical user interface 116 and the particular web service selected (service 1 in this example). The available reports details section 534 may contain a table of all reports the user configured for the selected service (i.e., service 1). As shown in FIG. 9, the table may contain report names, report specifications, destination types and specifications specified by the user for each report, and report status information (i.e., whether the report is enabled or active or not currently enabled or inactive). The user may remove the report for the selected service (i.e., service 1) with the selected report delete key 536 and/or may select the new report key 538 to specify a new report with the screens shown in fig. 6-8, for example.
Fig. 10 illustrates an example of a user profile summary information screen 540 that may be displayed in the active region 406 based on the selection of "self-use profile" in the selection tree 404. As shown in fig. 10, this screen 540 may contain information on the user's name and title or title, status information indicating whether the user is currently prohibited from interacting with the user interface 116, information regarding whether the user can edit his profile, and a submit change key 542 that enables the user to submit his profile changes (assuming that the user is allowed to edit his profile). As shown in FIG. 10, a marker 544-550 may be provided to facilitate guiding a user through the various frames associated with a user profile. In the example shown in fig. 10, total information flag 544 is selected. However, if desired, the user may select the destination tab 546, the group tab 548, or the shift tab 550, invoking the other profile screens described below and shown in connection with FIGS. 11-13.
Fig. 11 illustrates an example of a destination configuration screen 560 that may be displayed in the active region 406 when the destination indicia 546 (fig. 10) is selected. As shown in fig. 11, the screen 560 includes a destination selection unit 562 for enabling the user to select a destination type of the arrangement. As shown by way of example, the available destinations include email web services, paging web services, file system web services, or other types of web services, and the destination configuration screen 560 further includes a configuration section 564 for enabling a user to input configuration information for the destination selected by the destination selection section 562. Since the destination selection unit 562 in the example shown in fig. 11 selects "email", the configuration unit 564 includes an area for the user to input an email address and a text description of the address. Of course, if the destination selection portion 562 selects a paging web service, a file system web service, or other web service, the configuration portion 564 may contain different areas that request appropriate information from the user. The destination configuration screen also includes a submit key 566 which, when selected by the user, submits the information entered by the user for subsequent transmission to the information server 114 for use.
Fig. 12 illustrates a group screen 580 displayed in the active display area 406 when the group mark 548 (fig. 10) is selected. As shown in fig. 12, the group screen 580 displays a list of groups to which the user belongs, and further includes an add key 582 and a remove key 584 that allow the user to add or delete group members, respectively. The group to which the user belongs preferably corresponds to a job, such as a supervisor, manager, etc. As described herein, the group to which the user belongs may affect the type of information that is responsive to which the user has access and/or changes. System security considerations may specify that only the manager may access or change the groups assigned to other employees.
The systems and methods described may also be used with assignment lists other than the groups described above. The allocation table may typically contain, for example, persons from different groups that are common in some way. For example, an allocation list may contain employees that are all within a certain building or facility, etc., that are related to a certain rule. The system may maintain the assignment list as a table or other similar data structure containing the users of the list members and corresponding user identifiers (i.e., UIDs) as well as configuration information and/or profile information including group member information. In this way, when information is to be communicated using the allocation table, the communicator 140 may communicate information to users in the allocation list based on the user profile and/or configuration information. For example, 1 user in the distribution list may receive information via email, while other users in the list may receive information via pager or in other desired or prescribed ways.
FIG. 13 illustrates a shift screen 590 that may be shown in the active display area 406 when the shift flag 550 is selected. As shown in fig. 13, screen 590 contains a list of work shifts associated with the user, and also includes an add key 592 and a remove key 594, which when selected, enable the user to add or remove a shift, respectively.
Fig. 14 shows an email sink service creation screen 600 that can be displayed in the active display area 406 when the user selects the "manage" portion of the right selection guide 404 under "destination creation". As shown in fig. 14, screen 600 may include an enable/disable section 602, an email protocol selection section 604, an email server selection section 606, and a submit key 608. An enable/disable section 602 enables a user to enable or disable all email sinks. The email protocol selection section 604 allows the user to select an email protocol for email web services, such as Microsoft's exchange or SMTP. The email server selection section 606 enables the user to select a server for email web services. The selection section 606 also provides a browse key 610 that allows the user to browse the available servers. The user may also select a submit key 608 to save and implement the information entered and/or selected in screen 600.
FIG. 15 illustrates a group setup screen 620 that may be displayed in the active display area 406 upon selection of "group setup" in the "manage" portion of the selection tree 404. As shown in fig. 15, the screen 620 may include a description table 622 listing the names of the groups that have been arranged and the names thereof, a selective deletion key for allowing the user to delete 1 or more groups displayed in the table 622, and a group addition unit 626 for allowing the user to add groups (i.e., group names and accompanying descriptions) to the table 622.
Fig. 16 shows a user setup screen 630 displayed in the active display area 406 when "user setup" of the "manage" section in the selection tree 404 is selected. As shown in FIG. 16, screen 630 may include a user table 632 listing the names and work descriptions of users who have interacted with system 100 (FIG. 1) via a graphical user interface. An authorized user may select the delete selected user key 634 to delete the user from the table 632, thereby preventing the user from interacting with the graphical user interface 116 and the system 100. The add user portion 636 allows authorized users to enter new user names and job specifications into the table 632.
Fig. 17 shows a shift setup screen 640 that can be displayed in the active display area 406 when the "shift setting" of the "management" section of the option 404 is selected. As shown in fig. 17, the screen 640 may include a screen selection unit 642 for allowing an authorized user to specify the mode of display of the shift information in the table 644. For example, the user may select a weekly shift screen for a certain shift (as shown in FIG. 17), or may select a shift-fraud screen that is displayed simultaneously for 1 or more shifts for different time periods.
Fig. 18 illustrates a part setup screen 650 that may be displayed in the active display area 406 when "part setup" under the "manage" section in the tree selection guide 404 is selected. As shown in fig. 18, the screen 650 may include an additional parts section 652 that displays additional parts available for download. Additional components 652 may list names and descriptions of available applications or web services that the system 100 may add and be configured to communicate with the information server 114, as well as other system components, including the graphical user interface 116. An installation selection key 654 may be selected to initiate the download and/or installation of the selected component in the component section 652. The component setting screen 650 further includes a status unit 656 that displays the status of the component that has been downloaded or mounted. For example, the status information may contain a part name and version status description of the part. In particular, the status specification may indicate whether the latest version of the component has been installed or downloaded, whether a newer version is available, and the like. When a newer version of an installed or downloaded part is available, the user may select the update key 658 to initiate the download or installation of the new version.
Fig. 19 illustrates a curated traffic configuration screen 660 that may be displayed in the active display area 406 when a curated scheduled traffic configuration is selected. As shown in fig. 19, the screen 660 includes configuration name and description segments 662 and 664, from which a user can input a name and a description of a new plan, a directory information section 666 associated with browsing keys 668, 670, and 672, a save policy section 674, an error notification section 676, an access list section 678, a restore key 680, and an raise key 682. The user can enter the source directory, sink directory, and record directory at directory information 666 and can facilitate finding and/or selecting such directories using browse keys 668-672. In the retention policy part 674, the user can specify the degree and size of the obsolescence of the file to be deleted. In the error notification unit 676, the user can specify a transmission method and an object for planning execution of an error. For example, a user may specify that an error notification be sent to some 1 user via email. In access list section 678, a user may specify what types of users may access the information involved in the specified plan. The reset key 680 may be selected to clear the previously entered or selected (but not yet submitted) information in the screen 660. A submit key 682 may be selected to submit a curation provision for delivery to a curation management web service (e.g., web service 218 shown in FIG. 2) for execution.
Fig. 20 shows a service 1 screen 690 displayed in the active display area 406 when "service 1" under the "screen" section in the tree selection guide 404 is selected. As shown in FIG. 20, the screen 690 may contain a tree 692 showing portions of a process plant or control system for which business 1 is analyzing. Screen 690 of business 1 also contains an analysis summary display 694 that provides data or analysis results associated with the control system (or portion of the control system or device) that business 1 is analyzing.
It is important to know that the availability of the screens provided by the graphical user interface 116 (examples of which have been described above in connection with fig. 5-20) is governed by the different levels of access provided to the user. In other words, because the "administration" screen only allows users to enable or disable other users, specify groups, and generally complete functional settings or configurations with limited availability, a very limited number of users have the opportunity to view and interact with the screen. 1 or a few users have a system administrator status and can interact with the graphical user interface 116 in the "manage" screen. On the other hand, all users authorized by the system administrator to interact with the graphical user interface 116 have the right to specify the desired report. However, these users may or may not be authorized to change their own profiles. The permissions of each user may be stored in the database 138 of the information server 114 and retrieved to determine for a particular user whether to allow or deny the user's request to invoke a screen, screen input information, etc. at the graphical user interface 116.
Further, while the selection tree 404 illustrated in fig. 5 shows only 2 available services (i.e., service 1 and service 2), other numbers of available services may be shown in the tree 404. For example, in the example system 200 shown in FIG. 2, the graphical user interface 116 may display a selection tree listing all of the web services 202-220. Also, the screens shown in FIGS. 5-20 are merely examples, and other screens that facilitate configuring information server 114, web services, etc., and/or that facilitate information available in systems 100 and 200 may be used instead.
The screens shown in fig. 5 to 20 are illustrated as being displayed separately or individually, but a plurality of screens may be arranged and displayed together if necessary. Multiple frames may be combined and displayed together to facilitate configuring actions, viewing system data, finding faults, etc. In particular, pictures associated with interworked or interactive web services may be combined and displayed with, for example, a device having a smaller display window.
The web services communication system and method described herein is illustrated as being implemented using an XML-based server, but may be implemented in other suitable transaction data languages on suitable hardware platforms. The information server described here is basically described as being implemented as software, but some or all of these functions may be implemented in hardware, firmware, or the like. Thus, the web services communication system and method described herein may be implemented on a standard multi-purpose processor or using specially designed hardware or firmware, as desired. When implemented in software, the software routines can be stored in any computer readable memory, such as on a magnetic disk, optical disk or other storage medium, or in the RAM or ROM of a computer or processor. Likewise, the software may be delivered to a user or a process control system via well known or desired delivery methods including, for example, delivery on a computer readable disk or other transportable computer storage mechanism or over a communication channel such as a telephone line, the Internet, etc. (which are viewed as being similar to or interchangeable with providing the software via a transportable storage medium).
The present invention has been described with reference to specific examples, but the present invention is only illustrative and not limited thereto. Those of ordinary skill in the art will understand that: the disclosed embodiments may be changed, added, or deleted without departing from the spirit and scope of the invention.