US 20070129820 A1
A new and improved control system architecture with a single server interface for application software that eliminates manual intervention by providing online, immediate access to information needed for plant/enterprise optimization, operation, configuration, maintenance and diagnostic application software. The control system architecture provides a method of dynamically creating a server directory to enable automatic access in an integrated control system. The method includes accessing a live list of fieldbus devices, building/updating a browse tree structure, the browse tree structure defining a branch and leaf node organization and naming for and data from the fieldbus devices, copying AP directories and FF objects from active fieldbus devices into a FF directory and mapping the FF Directory into the server directory.
1. A method of dynamically creating a server directory to enable automatic access in an integrated control system, comprising the steps of:
(a) accessing a live list of fieldbus devices, wherein the live list represents active fieldbus devices in the integrated control system;
(b) building/updating a browse tree structure, wherein the browse tree structure defines a branch and leaf node organization, naming for the fieldbus devices and data from the fieldbus devices;
(c) copying Application Process (“AP”) directories and Foundation Fieldbus (“FF”) objects from active fieldbus devices into a FF directory so that the FF directory has object semantics corresponding to the active fieldbus devices; and
(d) mapping the FF Directory into the server directory, wherein the object semantics in the FF directory are mapped into the server directory in a standardized format that is automatically accessible by client application software running on a server.
This application is a continuation-in-part (CIP) application of U.S. patent application Ser. No. 10/160,094, entitled “A Block-Oriented Control System” and filed Jun. 4, 2002, which is a continuation of U.S. Pat. No. 6,424,892 (hereinafter the “'892 patent”), also entitled “A Block-Oriented Control System” and filed Aug. 21, 1997, which claims the priority of U.S. Provisional Application No. 60/024,346, filed Aug. 23, 1996. This application is also a CIP of U.S. patent application Ser. No. 09/598,697 (hereinafter the “'697 application”), entitled “Block-Oriented Control System On High Speed Ethernet” and filed Jun. 21, 2000, which claims the priority of U.S. Provisional Application No. 60/139,814, filed Jun. 21, 1998. This application also claims priority of U.S. Provisional Application No. 60/314,093, filed Aug. 23, 2001, and U.S. Provisional Application No. 60/315,067 filed Aug. 28, 2001. All of the above-mentioned applications and patent are hereby incorporated by reference in their entirety.
The present invention relates to automatic control system architecture. More particularly, the present invention relates to how plant and enterprise application software accesses control system data including fieldbus data, needed for plant and enterprise management, operation, configuration, maintenance, and diagnostic functions of the control system.
Automatic control systems are critical to all sectors of industry such as process control, discrete control, batch control (process and discrete combined), machine tool control, motion control, and robotics. One of the strongest needs in modern control systems is development and use of “open” and “interoperable” systems. Open, interoperable systems allow control devices made by different manufacturers to communicate and work together in the same system without the need for custom programming.
The movement toward open, interoperable control systems is driven by plant and enterprise management, application software suppliers, control device manufacturers, and end users. Plant and enterprise management want open, interoperable control systems because they need access to all of the control system information in order to provide the analysis needed to optimize the operation of the plant and enterprise. Client Application Software suppliers want open, interoperable control systems so that their software can access the control system data using standard computer platforms running standard operating systems, and interconnected by standard communication systems. Control device manufacturers want open, interoperable control systems because such systems allow them to sell their products to more end users while reducing development costs. End users want open, interoperable control systems so that they can select the best application software and control devices for their system regardless of the manufacturer.
In order for control systems to be truly open and interoperable, communications systems between devices, the user layer (above the communication system layers) in the devices, and the computer/application software integration architecture must be specified and made open. “Fieldbus” is the common term used to describe these types of automatic control systems.
One of the truly open and interoperable fieldbus control systems is the FOUNDATION™ fieldbus (“FF”) system provided by the Fieldbus Foundation (Austin, Tex.). The FF user layer and a lower speed 31.25 kilobits/second fieldbus (H1) is described in the above-mentioned '892 patent. A High Speed Ethernet (HSE) fieldbus, running at 100 megabit/second or higher speeds, is described in the above-mentioned '697 application. The '892 patent and the '697 application are assigned to the assignee of the present application.
H1 provides the open and interoperable solution for field level control capability and integration, and HSE provides the open and interoperable solution for distributed control on a very high performance communication system typically called a fieldbus control “backbone” network. The HSE control backbone aggregates information from lower speed control devices, e.g., the H1 devices and other control devices, which is used in supervisory and advanced control applications. The HSE control backbone aggregates data from high-speed control devices, e.g., HSE devices and other subsystems, and provides access/change of H1 and HSE control information by control system computers.
The plant/enterprise application software operates at the “client” and “server” levels in the control system hierarchy. An open and interoperable integrated fieldbus data server architecture (meaning client and server) is needed that will provide a framework and common specification for the “semantics” (how the application software understands the control system data) of fieldbus data, whether it is H1 or HSE data, or other control data. Prior to the present invention, client application software on the plant/enterprise computers had to be manually customize and adapt data received from each server that provided access to fieldbus or other control device data because each server identified and represented the same semantic information differently. A requirement for modern servers is to eliminate the need to manually customize or adapt client application software; the present application addresses this requirement.
Existing server specifications provide for automatic adaptation of very limited subsets of runtime data because this data can be understood through syntax only, e.g. message structure. For example, the OLE for Process Control (OPC) Specification from the OPC Foundation (Boca Raton, Fla.) provides for the limited adaptation through standardization of the basic access mechanism and syntax for runtime data, e.g. simple process variables (PV) and setpoints (SP). The OPC Specifications are general enough to allow extra information, called “properties” to define “class” attributes of the runtime data. Class attributes include “Device Description” (DD) information for the runtime data, e.g. help strings, engineering units, and parameter labels. Some DD information is complex, for example containing conditionals, menus, and methods (which are C programs). Additional class attributes are provided by “Capability Files” (CF) that describe the range of capability of the fieldbus device or other control device, e.g. maximum number of parameters, initial values of parameters, and maximum number of communication sessions. However, although OPC allow servers to define class attributes, there is no standardized definition for class attributes, thus limiting interoperability with, and automatic adaptation by, client application software
Further, even if class attributes could be standardized for server data, the client application software also needs to know which “instance” of the runtime data is being described by the class attributes. That is, the class attributes can tell the client application software what type of runtime data is being accessed, but they cannot identify the specific data that is being accessed. Instance information can be provided by accessing application directories (which locate the runtime data) in the fieldbus devices, but like class attributes, there is no standardized definition of the application directory information making interoperability and automatic adaptation of the client application software impossible.
Advanced Human/Machine Interface (“HMI”), trending, asset management, configuration, maintenance, diagnostic and plant/enterprise management application software must have access to runtime data and the class attributes and application directory semantic information that allows the software to automatically identify, interpret, and process the runtime data without manual intervention. Finally, to be efficient, the client application software must be able to access the runtime data and the semantic information through a single interface.
The OPC Specification is unable to automatically and efficiently support these advanced applications because there is no open and interoperable framework or specification for providing the above described semantic information to the client software applications through the same interface that is currently used to access runtime data.
What is needed is a framework and a common specification for an integrated fieldbus data server architecture that can provide semantics of runtime data, both simple and complex, to the client application software.
What is needed is a framework and a common specification for an integrated fieldbus data server architecture that migrates support for existing plant/enterprise client application software, e.g., HMI and other OPC software applications, while standardizing and integrating the semantics needed for automatic identification, interpretation, and processing of runtime data by advanced client application software, e.g., plant/enterprise management, configuration, maintenance, and diagnostics application software.
What is needed is an integrated fieldbus data server architecture that complements H1, HSE and other fieldbus architectures so the plant/enterprise application software can automatically interpret the runtime data using corresponding semantic information.
What is needed is an integrated fieldbus data server architecture provides a single interface for access of the runtime data and corresponding semantic information by the plant/enterprise application software.
Embodiments of the present invention overcome the shortcomings described above and otherwise. Embodiments of the present invention satisfy the above-described needs. Embodiments of the present invention provide a new and improved control system architecture with a single server interface for Client Application Software that eliminates manual intervention by providing online, immediate electronic access to the runtime data and semantic information by advanced plant/enterprise management, operation, configuration, maintenance and diagnostic application software.
The embodiments of the present invention are collectively referred to herein as the “Integrated Fieldbus Data Server Architecture” (IFDSA). IFDSA provides the framework and specification for mapping the semantic information of runtime data such as H1 and HSE fieldbus device data described in the '892 patent and '697 application, respectively, and further defines a single interface for client application software. The IFDSA framework enables automatic adaptation to FF and other control device types.
The elimination of manual intervention for setup of advanced application packages is achieved by providing a method and apparatus for accessing the runtime “live list” of active FF devices and building/updating a Standardized Browse Tree Structure formatted to be compatible OPC Specifications available from the OPC Foundation and mapping FF Directory information (which provides the semantic information for all FF fieldbus and other control device runtime data) into a new Server Directory. The Server Directory contains the same semantic information as the FF Directory, but is formatted to be compatible OPC Specifications available from the OPC Foundation. The OPC-compatible browse tree and semantic information is then provided to the client application software transparently by the servers.
The IFSDA achieves a single interface because the Client Application Software at the client no longer has to use separate interfaces to access semantic information and runtime data. Since the mapping of FF semantic and runtime data to OPC Specifications is above the communication layers, this solution remains valid as implementations evolve to newer technologies, e.g., web services.
Features and advantages of the present invention will become apparent to those skilled in the art from the following description with reference to the drawings, in which like numerals refer to like items and:
For simplicity and illustrative purposes, the present invention is described by referring mainly to exemplary embodiments, particularly, with a specific exemplary implementation of a control system using H1, HSE, OPC (meaning both client and server operations), and Client Application Software. However, one of ordinary skill in the art would readily recognize that the same principles are equally applicable to, and can be implemented in, other implementations and designs using any other integrated architecture, and that any such variation would be within such modifications that do not depart from the true spirit and scope of the present invention. Specifically, one of ordinary skill in the art would readily recognize that principles applying to OPC in the exemplary implantation are equally applicable to non-OPC implementations.
I IFDSA Overview
IFDSA components in accordance with an embodiment of the principles of the present invention are shown in
The various protocols and standards referenced in the following disclosure are described in detail in the manuals and specifications listed in Appendix I herein, which are publicly available from the Fieldbus Foundation, a not-for-profit organization headquartered in Austin, Tex. The specifications and manuals may be ordered by calling 512-794-8890 or online at www.fieldbus.org. The respective current versions of each of these manuals and specifications are hereby incorporated by reference in their entirety. Each of the architecture components of IFDSA (shown in
II. IFDSA Components
In the embodiment shown, OPC 160 preferably includes Client Application Software 180 and an OPC Client 210. Client Application Software 180 uses OPC Client 210 to access information in an OPC Server 220. OPC Client 210 and OPC Server 220 can reside in a single computer or they may be in separate computers on a communication network (the communication network between the client and server is not shown in
The Client Application Software 180 running in OPC 160 may include a variety of software (e.g., as separate programs or separate modules of the same software). For example, the Client Application Software 180 may include Human/Machine Interface Application Software 181, Maintenance/Diagnostics Application Software 182, Configuration Application Software 183, and Other Plant/Enterprise Application Software 184. The preferred embodiment defines existing client application software to be included in Other Plant/Enterprise Application Software 184.
Referring again to the embodiment shown in
III. IFDSA Directory Mapping
With continued reference to the embodiment illustrated in
The runtime objects are preferably defined as FF Objects by the FF Specifications referenced in Appendix I, although a vendor can define additional runtime objects. In either case, DD and CF technology mentioned above and described in the '892 application (and the FF Specifications listed in Appendix I) are preferably used to describe the runtime objects. DD and CF files extend the descriptions of each object in a device that is needed for a control system to interpret the meaning of the data in the fieldbus device, including the human interface functions, such as calibration and diagnostics.
The DD/CF files can be written in ASCII text or any standardized programming language, such as C, C++, or SmallTalk. In the preferred embodiment, DD files are written in the DD Language (DDL) and CF files are ASCII text files as described by the FF Specification listed in Appendix I and available from the Fieldbus Foundation.
The FF Directory 240 is preferably composed of the list of all Fieldbus Devices 280, called the Live List, and the AP directories contained in each FF device. The Live List may be constructed by listening to FF network traffic, or it may be read from Fieldbus Devices 280 that contain it. AP directories are read by the FF Server Module 230 from the Fieldbus Devices Fieldbus Devices 280 via the Fieldbus Networks 290, or the AP Directories can be obtained locally by reading the CF file (The DD and CF files are provided with every FF fieldbus device).
The OD Index is used as a key attribute in FF protocol services to access the runtime objects. Consequently, Client Application Software 180 can access runtime data in the Fieldbus Devices 280 by obtaining their corresponding OD indexes from the FF Directory 240.
OPC 160 models runtime objects as “OPC Items”. OPC Items are identified by “Item IDs” that contain vendor-specific names. OPC Items in the OPC Server 220 are presented to the OPC Clients 210 via a Server Browse Function 270. The Server Browse Function 270 allows the OPC Server 220 to locate OPC Items in a tree structure that is constructed per the OPC specifications. The OPC Client 210 uses the Server Browse Function 270 to locate items of interest.
Currently, there is no standardization of branch and leaf node organization or ID naming used in the Server Browse Function 270 and, therefore, the OPC Client 210 cannot locate OPC Items of interest without manual interpretation of the browse tree and each OPC Item in it. This precludes OPC Clients 210 from automatically accessing and processing OPC Items in the OPC Server 220.
To solve this problem, the IFDSA 50 provides a standard Server Directory 260 that is created to represent the FF Directory 240. The Server Directory contains the same object semantic information as the FF Directory 240, but is mapped to be compatible with OPC objects. The Standardized Browse Tree Structure 261 in the Server Directory 260 defines the branch and leaf node organization and naming for the Fieldbus Devices 160 so that the Server Browse Function 270 can locate its representation of Fieldbus Devices 280 and their data through the OPC compatible semantic information in Server Directory 260. Once located, the OPC compatible semantic information and data values (if any) are provided to the Client Application Software 180 transparently using via the Server Browse Function 270 and related OPC 160 services.
The Mapping Function 250 maps the Fieldbus Devices 280 Live List 400 and Application Process (AP) Directory information to the Server Directory 260 with an automatically generated OPC Access Path Name and/or a Fully Qualified Item ID, referred to below as the OPC Item Reference. The AP Directory is written in accordance with the manuals or specifications listed in Appendix I and available from the Fieldbus Foundation. The OPC Access Path name defines the server-specific path through the Server Browse Function 270 to the FF Directory 240. The OPC Fully Qualified Item ID is a handle to the item representing a corresponding Runtime Object in the FF Directory 240. The OPC Access Path, OPC Fully Qualified Item ID and Server Browse Function are written in accordance with OPC Specifications and available from the OPC Foundation.
The access step 320 preferably is performed using protocol services defined in the FF Specifications in Appendix I and available from the Fieldbus Foundation. The building/updating step 330 initially builds the Standardized Browse Tree Structure 261 with Live List 400 Device Identification information read from Fieldbus Devices 280.
The reading of information in step 330 preferably is performed using protocol services defined in the FF Specifications in Appendix I and available from the Fieldbus Foundation. (Please see
With continued reference to
As shown in
Mapping Option 2, mapping the Live List Entry 242 to a single structured OPC Item accessed by the OPC Value Read service. OPC Item 262 b includes Device Identification information and the device's mapped Device Directory information or a reference to it, formatted and mapped to an OPC Value per OPC Specifications. Accordingly, the Device Directory or a reference to it is included in the value of the Browse Tree item that represents the device, and
As shown in
As shown in
IV. IFDSA Single Client Application Software Interface
Referring now to
OPC Client 210 can obtain the runtime value data from the Server Data Access Function 271 in OPC Server 220. FF Server Module 230 accesses Fieldbus Devices 280 runtime value data using protocol services defined in the FF Specifications in Appendix I and available from the Fieldbus Foundation. The mapping of Fieldbus Devices 280 runtime value data accessed by FF Server Module 230 to the Server Data Access Function 271 is defined by OPC Specifications available from the OPC Foundation.
A preferred embodiment of the new IFDSA 50 supports migration of existing application software, which is included in Other Plant/Enterprise Application Software 184 because existing application software only uses Server Data Access Function 271 and this function is unchanged by IFDSA 50. This invention includes the migration and coexistence of existing application software with new Client Application Software 180 in the IFDSA 50.