Home
Patent Search
IMT Blog
REGISTER
|
SIGN IN
United States Patent
5812394
Lewis , ; et al.
September 22, 1998
Title
Object-oriented computer program, system, and method for developing control schemes for facilities
Abstract
An object-oriented development system for developing control schemes for facilities includes a device diagramming component for describing a physical description of a facility and a logical definition of a control scheme for the facility. The device diagramming component includes a mode for selecting device symbols representative of equipment or control functions used in facilities. The device symbols are selected from an object-oriented repository containing a plurality of device symbols and device objects. Certain types of device symbols relate to device objects containing logical instructions and configuration information relating to the represented equipment or control functions. The device diagramming component also includes a mode for interrelating in a graphical manner the selected device symbols and their corresponding device objects into a device diagram representing the physical description of the facility and the logical definition of the control scheme for the facility. A device logic developing component defines the logical instructions of the device objects relating to the equipment or control functions. Thus, the development system integrates in a graphical format the physical description of the facility with the logical instructions which define the control scheme for the facility. These logical instructions unify the configuration of analog/regulatory control with the configuration of discrete/sequential/interlocking control.
Inventors:
Lewis; Robert W.
(Dana Point,
CA
)
, Tanner; Matthew A.
(Irvine,
CA
)
, Walker; Timothy K.
(Overland Park,
KS
)
Assignee:
Control Systems International
(Fairway,
KS
)
Appl. No.:
505704
Filed:
July 21, 1995
Current U.S. Class:
700/17
700/83
700/84
700/86
715/846
Field of Search:
364/188,189,146,191,140,130,300,400,513 395/155,500,700,159,326,561
U.S. Patent Documents
4628435
December 1986
Tashiro et al.
4736320
April 1988
Bristol
4885717
December 1989
Beck et al.
4972328
November 1990
Wu et al.
5014208
May 1991
Wolfson
5051898
September 1991
Wright et al.
5485600
January 1996
Joseph et al.
5485620
January 1996
Sadre et al.
5509116
April 1996
Hiraga et al.
5530643
June 1996
Hodorowski
5546301
August 1996
Agrawal et al.
5555385
September 1996
Selby et al.
5576946
November 1996
Bender et al.
5594858
January 1997
Blevins
5603018
February 1997
Terada et al.
5611059
March 1997
Benton et al.
Other References
Bailey, "Introducing Bailey Evolution 90.TM. . . . The Sound Investment Strategy for Process Automation", 1993. .
Bailey, "Wide-Range, Fully Compatible Family of Process Automation and Management Systems", 1993. .
Computer Products, "Unbundling the DCS", approximately 1992. .
Elsag Bailey, "Elsag Bailey Automation", approximately 1993. .
Fisher-Rosemount, "Managing the Process Better", Sep. 1993. .
Fisher-Rosemount, "Managing the Process Better", Dec. 1993. .
Honeywell, "Process Manager Specification and Technical Data", Sep. 1991. .
Honeywell, "TDC 3000 Overview", approximately 1992. .
Honeywell, "TDC 3000 Process Manager", approximately 1992. .
Honeywell, "UDC 6000 Process Controller", Aug. 1992. .
Leeds and Northrup, "Make Your Automation Plan a Reality: MAX 1000", approximately 1990. .
Toshiba, "Toshiba Integrated Control Systems", Nov. 1990. .
Reliance Electric Company, "Multitasking Capability Simplifies Process Control Design", approximately late 1980s, by Angelo J. Notte..~
Primary Examiner:
Elmore; Reba I.
Assistant Examiner:
Patel; Ramesh
Attorney, Agent or Firm:
Hovey, Williams, Timmons & Collins
Claims
Having described the invention, we claim:
1. An object-oriented development system for developing control schemes for facilities, the development system utilizing a graphical user interface environment, the system comprising:
device diagramming means for describing a physical description of a facility and a logical definition of a control scheme for the facility, the device diagramming means including,
means for selecting device symbols representative of equipment or control functions used in facilities, the device symbols being selected from an object-oriented repository containing a plurality of device symbols and device objects, and wherein certain types of device symbols relate to device objects containing logical instructions and configuration information relating to the represented equipment or control functions, and
means for interrelating in a graphical manner the selected device symbols and their corresponding device objects into one or more device diagrams, each of the device diagrams representing both the physical description of the facility or a portion of the facility and the logical definition of the control scheme for the facility or the portion of the facility; and
device logic developing means for defining the logical instructions of the device objects relating to the equipment or control functions;
wherein the development system integrates in a graphical format the physical description of the facility with the logical instructions which define the control scheme for the facility, and wherein the logical instructions unify configuration of analog/regulatory control with configuration of discrete/sequential/interlocking control.
2. The development system as defined in claim 1 wherein the device symbols comprise configurable device symbols relating to device objects containing user modifiable logical instructions and configuration information.
3. The development system as defined in claim 2 wherein the device symbols further comprise static device symbols which illustrate physical aspects of the facility.
4. The development system as defined in claim 2 wherein the device logic developing means includes device definition editing means for creating and modifying the logical instructions and configuration information of the selected configurable device objects, and device template editing means for creating and defining device template objects for configurable device objects.
5. The development system as defined in claim 2 wherein the logical instructions for configurable discrete device objects are organized in a plurality of structured logic categories, with each logic category exhibiting distinct functional characteristics.
6. The development system as defined in claim 5 wherein the structured logic categories include control logic, state logic, mode logic, alarm logic, and fault logic.
7. The development system as defined in claim 5 wherein the device objects comprise new instances of existing device template objects and inherit all of the logical instructions and configuration information of the corresponding device template objects upon instantiation and interrelation into the device diagram.
8. The development system as defined in claim 1 wherein the device diagramming means further comprises means for creating and modifying device symbols to allow the illustration of any desired physical or logical aspect of a facility.
9. The development system as defined in claim 1 wherein the system merges the capabilities of the traditional programming tools of rung ladder logic programming and function block programming in order to unify the configuration of analog/regulatory control with the configuration of discrete/sequential/interlocking control.
10. Method for developing an object-oriented user-configurable control scheme for facilities in a graphical user interface environment, the method comprising:
selecting device symbols from an object-oriented repository containing a plurality of device symbols and device objects which represent equipment or control functions used in facilities, wherein certain types of device symbols relate to device objects containing logical instructions and configuration information relating to the represented equipment or control functions, and
interrelating in a graphical manner the selected device symbols and their corresponding device objects into one or more device diagrams, each of the device diagrams representing both a physical description of the facility or a portion of the facility and a logical definition of the control scheme for the facility or the portion of the facility,
wherein the physical description of the facility is integrated in a single control system with the definition of the logical instructions which comprise the control scheme in a graphical format, the logical instructions unifying configuration of analog/regulatory control with configuration of discrete/sequential/interlocking control.
11. The method as defined in claim 10 wherein the step of interrelating includes:
inserting in a graphical manner the selected device symbols into the device diagram; and
connecting the selected device symbols inserted into the device diagram in a manner to represent the physical nature of the facility and the logical definition of the control scheme.
12. The method as defined in claim 10 wherein the device symbols comprise configurable device symbols relating to device objects containing user modifiable logical instructions and configuration information.
13. The method as defined in claim 12 further comprising the step of defining the logical instructions of the configurable devices in the device diagram.
14. An object-oriented development system for developing control schemes for facilities, the system comprising;
diagramming means for graphically producing one or more device diagrams, each of the device diagrams interrelating a plurality of device objects to provide in a graphical format a physical description of a facility or a portion of the facility integrated with a logical definition of a control scheme for the facility or the portion of the facility, the device objects relating to equipment or control functions used in facilities and including control information relating to control of the equipment or control functions, and
means for defining, creating, and modifying the control information of the device objects;
wherein the logical definition of the control scheme unifies configuration of analog/regulatory control with configuration of discrete/sequential/interlocking control.
15. The development system as defined in claim 14 wherein each of the device objects respectively comprise a physical representation of the corresponding equipment or control functions, a graphical representation of the equipment or control functions, and the control information including logical instructions and configuration information relating to control of the equipment or control functions, the device objects organizing said representations, instructions and information in a consolidated manner to provide unification of the information which defines control and monitoring behavior for the equipment or control functions.
16. The development system as defined in claim 14 wherein the device objects comprise configurable device objects containing user modifiable logical instructions and configuration information.
17. The development system as defined in claim 16 wherein the means for defining includes device definition editing means for creating and modifying the logical instructions and configuration information of the configurable device objects, and device template editing means for creating and defining device template objects for configurable device objects.
18. The development system as defined in claim 16 wherein the logical instructions for configurable discrete device objects are organized in a plurality of structured logic categories, with each logic category exhibiting distinct functional characteristics.
19. The development system as defined in claim 18 wherein the structured logic categories include control logic, state logic, mode logic, alarm logic, and fault logic.
20. The development system as defined in claim 14 wherein the diagramming means further comprises means for creating and modifying device objects to allow the illustration of any desired physical or logical aspect of a facility.
21. In a development system for developing control schemes for facilities, the development system operating in a graphical user interface environment, an object-oriented development tool comprising:
a plurality of device objects relating to equipment or control functions used in facilities, the device objects including physical representations of the equipment or control functions and logical instructions and configuration information relating to the equipment or control functions, the device objects organizing said representations, instructions and information in a consolidated manner to provide unification of the information which defines control for the equipment or control functions; and
diagramming means for graphically producing one or more device diagrams, each of the device diagrams interrelating a plurality of the device objects to provide in a graphical format a physical description of a facility or a portion of the facility integrated with a logical definition of a control scheme for the facility or the portion of the facility, wherein the logical definition of the control scheme unifies configuration of analog/regulatory control with configuration of discrete/sequential/interlocking control.
22. The development tool as defined in claim 21 wherein the device objects further include graphical representations of the equipment or control functions, said graphical representations being included with the unified information to further define monitoring and control behavior for the equipment or control functions during operation of the control scheme.
23. The development tool as defined in claim 21 wherein the diagramming means further comprises means for creating and modifying the device objects to allow the illustration of any desired physical or logical aspect of a facility.
24. The development tool as defined in claim 21 wherein the logical instructions for configurable discrete device objects are organized in a plurality of structured logic categories, with each logic category exhibiting distinct functional characteristics.
25. The development system as defined in claim 24 wherein the structured logic categories include control logic, state logic, mode logic, alarm logic, and fault logic.
26. An object-oriented computer program stored on a computer-readable memory device for directing operation of a computer for developing graphical user interface control schemes for a facility, the computer program comprising:
device diagram creating means for creating one or more device diagrams, each of the device diagrams representing both a physical description of the facility or a portion of the facility and a logical control scheme for the facility or the portion of the facility, the device diagram creating means including
means for selecting a plurality of device symbols each representative of a piece of equipment or a control function used in the facility from an object-oriented repository containing a plurality of device symbols that relate to device objects containing logical instructions and configuration information for the represented equipment or control functions, and
means for graphically interrelating the selected device symbols and their corresponding device objects on each of the device diagrams; and
device logic developing means for defining the logical instructions of the device objects for the device symbols for integrating in each of the device diagrams both the physical description of the facility or the portion of the facility and the logical control scheme for the facility or the portion of the facility.
27. The computer program as set forth in claim 26, wherein the device symbols comprise configurable device symbols relating to device objects containing user modifiable logical instructions and configuration information.
28. The computer program as set forth in claim 26, wherein the device symbols further comprise static device symbols that illustrate physical aspects of the facility.
29. The computer program as set forth in claim 26, wherein the device logic developing means includes device definition editing means for creating and modifying the logical instructions and configuration information of the selected configurable device objects, and device template editing means for creating and defining device template objects for configurable device objects.
30. The computer program as set forth in claim 26, wherein the device diagramming means further comprises means for creating and modifying device symbols to allow the illustration of any desired physical or logical aspect of a facility.
31. The computer program as set forth in claim 26, wherein the logical instructions for configurable discrete device objects are organized in a plurality of structured logic categories, with each logic category exhibiting distinct functional characteristics.
32. The computer program as set forth in claim 26, wherein the structured logic categories include control logic, state logic, mode logic, alarm logic, and fault logic.
Description
FIELD OF THE INVENTION
The present invention relates to control schemes, and more particularly, to a user configurable open system for control of any type of facility.
BACKGROUND OF THE INVENTION
Control systems for various types of facilities, such as manufacturing or processing facilities, employ feedback control to measure, sense, count, time, etc. a parameter's status in a facility and use this status information to direct the operation of the facility. A control system must provide this capability for all pieces of equipment which need control in a given area of a facility.
In traditional control systems, the following steps generally must be performed to create a control system:
1. Select components of the control system architecture including I/O, controllers, networks, operator interface nodes, and engineering development nodes.
2. Select development tools (software utilities and products) to configure or program the components.
3. Write the logic used to control the facility using a special control programming language. This logic typically executes on some type of controller.
4. Draw and define the appearance and run-time behavior of graphic symbols and screens used to represent field devices on an operator interface.
The need for control systems has spawned a wide variety of products designed to facilitate the above steps. These products are typically built using generally available computing and electronic technology. Also, many general purpose computer and networking products, such as commercial computers, are used as control system components.
The products that typically make up the components of a control system include:
Sensing devices (e.g., thermocouples)
Electronic hardware (e.g., Analog to Digital Converters)
Computing hardware (e.g., single-board computers)
Operating systems (e.g., UNIX)
Network communication (e.g., Arcnet)
Software applications (e.g., databases)
General purpose processors (e.g., Intel 80x86)
Because of this availability of products, the first step of creating a control system involves selecting components. The following components are typically selected and used in control systems:
______________________________________ Development Node Typically, a computer where the control system project is configured by an engineer. Operator Interface Typically, a computer where an operator can monitor and, if necessary, interact with the control scheme for the equipment in the facility. Control Network Network that allows computers and controllers to communicate with one another. Controller Hardware containing configuration information and logic processing instructions pertaining to the field sensors and control devices connected to it. Typically, the hardware is a proprietary, programmable computer designed specifically as a controller to control a facility, e.g., a manufacturing plant or process operation. Sensors (e.g. flow Devices that measure physical meter) phenomena and convert those measurements into electrical signals which are sent to the controller. Control Devices (e.g. Devices that operate the valve) facility. Control devices receive their instructions from the controller. I/O Rack A housing which can hold multiple I/O cards. Each I/O card is typically capable of accepting inputs and driving outputs (I/O). Inputs and outputs are electronic signals wired to screw terminals on the card. Therefore, usually each input or output has a physical piece of wire carrying a voltage or current signal which represents the sensed value or output value. I/O or Instrumentation A network that allows the Network controller to communicate with I/O racks. ______________________________________
Based on the capability of these components in the architecture, most control systems provide the following functionality:
1. Measurement, control, and communications: These tasks are performed by groups of modules or devices that are distributed in function and location.
2. Operator interfaces: These are usually located in a centralized control room, although additional operator interfaces may be scattered throughout a facility.
3. Development nodes: These provide access to the logic and graphic screen configuration data.
4. A control network: This provides connections between components.
5. Redundancy: This is implemented in the event a device or module fails. All other devices or modules continue to operate.
These functions can be further summarized by grouping them into development, run-time (operator interface), and controller functions. These are summarized below followed by more detailed descriptions.
Development Functionality
Typical control system installations allow development of a system designed to monitor and control a specific facility. The development environment is a tool with which a control system project is configured. Fundamentally, one must define what happens in the controllers when they receive sensed data from field devices, and what control values the controller might send to a control device in response to the sensed values. An engineer must also define a whole host of additional details including how fast this must happen, how data is presented to an operator, etc.
The typical control system development environment requires a development engineer to fill in forms, draw pictures representing configuration concepts, and/or write specific machine instructions (essentially, a computer program that carries out specific tasks that cannot be defined via other methods). This development environment may be performed using a single product from a single manufacturer composed of either software or software and computer hardware. In other cases, the development environment may be performed by a collection of products from several suppliers. In either case, the result of development activity using these tools is creation of a run-time project from this information. The run-time project must then be transferred to the controller(s) and operator interface(s).
The development may be performed on- or off-site. In either case, the finished control system project is installed on-site. It should be understood that a control system project is a description or definition of the method by which a facility is to be monitored and controlled. In addition to installing the control system project, qualified personnel must perform the manual labor of installing the field sensors and control devices, connecting them to controllers, and connecting the controllers to a network. The development and operator interface computers must also be installed.
Run-Time Functionality
A typical control system run-time environment executes the control system project design configured and programmed during the development phase described above. Typically, the run-time environment consists of a controller programmed with the logic required to evaluate sensed data and send control values to control devices in response to the sensed data. In addition, a run-time environment allows an operator to monitor the status of field sensors and control devices by reading and interpreting data received from the controller and/or by viewing a graphical representation of that data.
Basically, field sensors send sensed data to a controller. The controller has been programmed to evaluate that data and to respond by sending control values back to control devices. At the same time, the controller relays some of that data to a separate computer where an operator monitors the process and, if necessary, performs manual control.
Programming the Controller Logic
The controller is typically programmed at the development node. However, some systems have less capability and require a non-network, direct connection to the controller in order to perform programming.
When a facility is designed, engineers typically produce the following types of documents:
Physical Definition Drawings--illustrate how equipment relates to one another in the field. Such drawings are dependent on the type of facility. For example, a chemical process would likely have an associated Piping and Instrumentation Drawing (P&ID). However, a coal handling conveyor system might have a mechanical flow sheet drawing. A control system for electrical power generation might include electrical one-line drawings.
Sequence of operations or logic schematics--specify in great detail the control logic needed to run the facility described in the physical definition drawings. A sequence of operations uses prose to describe the logic while schematics use graphical symbols and connecting lines to represent the logic.
It should be noted that zero, one, or more of these documents may be produced. For example, many manufacturing operations can be described with only a sequence of operations. On the other hand, most chemical processing plants require P&IDs. Engineers use these paper diagrams as an authority and reference when they program the controller, i.e., the documents specify what the controller should do when it detects certain conditions.
The logic behind the controller's actions is programmed using a special type of program language designed for control applications. Control programming languages are especially suited to receiving sensed values, running those values through standard or custom algorithms, and outputting one or more control values which typically command control devices to do something.
Some of the more common of these control programming languages are described below:
Function Blocks: This is the primary language used to program analog control. A function block processes inputs and provides one or more outputs. Multiple function blocks are connected together to solve the logic for a process, typically, an analog control process. Its paradigm is that of a simple mathematical function, e.g., square root, add, subtract, etc.
Rung Ladder Logic: This is the primary language used to program Programmable Logic Controllers (PLCs). As such, it is used primarily to solve the logic for discrete control. Its paradigm is a series of relays where electric power flows from left to right. This language was designed to mimic the electrical wiring diagram used to design handwired relay control systems.
Sequential Function Chart (SFC): This is the primary language used to solve the logic for batching and similar step-oriented applications. SFC uses a diagram similar to a flowchart to specify a sequence of steps, actions, transitions, and branches.
Textual Control Language: The above languages may be well suited to representing control logic, but they are not well suited to every task that a controller needs to perform. Special textual control languages are similar to conventional programming languages like C, BASIC, or Pascal. They are typically used to augment the other languages to perform initialization procedures or complex calculations, tasks the other languages may not be suited to perform.
Most controller language implementations support more sophisticated functionality than that described above. Some implementations also allow the programmer to save logic and reuse it much as a conventional programmer might create a function or procedure. Additionally, some controllers support other conventional computer science oriented programming languages and methods including C, BASIC, expert systems, flow charting, and others As such, these all represent, with the options described above, a language-based approach to expressing control functionality.
Using these languages, logic is created for each area or operation in a facility associated with a controller. For example, a certain operation might have several sets of logic that define what the controller should do when a certain pump shuts down or starts up. Commands might be sent to other equipment as a result of the pump's current status.
The information contained within a particular operation's logic set may contain minimal or a significant amount of information including tag names that represent originating points for data. The programmer often finds that part or all the logic for one operation is applicable to another operation. In this case, the programmer may copy the appropriate section of logic in order to reuse it. In some cases, the programmer will have to change some of the logic. In all cases, the programmer will have to change all identifiers in order to ensure that the new logic is receiving the correct data. Typically, this involves searching for tag names and replacing them with the appropriate information. The method by which searching and replacing occurs varies from system to system, and in some cases may require significant manual work.
Once the controller logic is programmed, it must be placed into the controller. The method by which the program is placed into the controller varies depending on the capabilities of the controller and other factors. The most common methods involve: (a) downloading the controller logic over a network into the controller's memory, and (b) transporting the controller logic via a removable memory device and copying the controller logic into the controller's memory from that device.
There are two dominant control system options currently available: distributed control systems (DCS) and programmable logic controllers (PLC).
Distributed Control Systems (DCS)
Historically, distributed control systems (DCS) have concentrated on analog control. Discrete control has been the realm of programmable logic controllers (PLC).
The traditional paradigm for an analog control system consists of a field sensor transmitting data to a single-loop controller which provides feedback to a device that has the means to control a measured variable. A single-loop controller implements a generally accepted algorithm--PID or proportional+integral+derivative--which determines what value the controller should send back through the loop to the control device.
In the 1970's, Honeywell introduced what is generally considered to be the first DCS, the TDC-2000. (TDC stands for Total Distributed Control.) The TDC-2000 integrated the functionality of multiple single-loop controllers into a single box. In addition, Honeywell placed the TDC-2000 on a network so that multiple controllers could communicate with one another.
This reduced the space requirements for a controller (for example, one power supply for a single, multi-loop controller rather than one for each single-loop controller). It also allowed the controllers to be distributed and placed closer to their associated field sensors and control devices. This set the paradigm for DCS: the functionality of multiple single-loop controllers in one piece of electronic equipment with many of these tied together on a network.
Today, distributed control systems can contain the functionality of hundreds of controllers executing hundreds of PID algorithms. A specialized I/O network can connect multiple I/O racks to one controller. Each I/O rack can communicate with multiple field sensors and control devices.
In distributed control, individual feedback controllers for each control loop are placed closer to the field devices. This requires a control network that connects individual controllers with operators, computers, consoles, and displays. As a result, the control loops become physically shorter and less vulnerable to noise or damage. Although the communication link might be lost, this represents only a loss of operator intelligence since individual field controllers continue to operate locally. Also the control network is normally equipped with redundant capability in order to prevent loss of control functionality and information.
The typical controller in a DCS system can control hundreds of I/O points. In some cases the points are monitored solely to display the respective sensed values. In other cases, feedback control is executed on the I/O points associated with the controller.
The controller in a DCS system is typically performing the following functions:
Scanning the I/O or instrumentation network
Signal conditioning and conversion
Analog control processing including PID
Logic and interlocking
Communication updates with other controllers or operator interface nodes
DCS controllers have traditionally been strong in PID and other types of analog processing but weak in logic and interlocking.
Most traditional DCS products rely on function block programming to implement the bulk of the logic for the control scheme. To a great extent, this is because function blocks are especially suited for analog control and traditional DCS deals heavily with analog control. However, function block programming does not always provide all the functionality needed to implement the logic for an operation or process. In some cases, DCS programmers seek out and DCS vendors provide other specialized programming languages that augment the capabilities offered by function block programming. Some of the other types of specialized control languages include rung ladder logic, sequential function charts, some type of textual language, etc.
The development node or configuration interface is used to perform system tasks other than those required by operators. Configuration and maintenance functions are performed at this interface, which can be located in a standalone console or within the operator interface.
The development node interface is used to create graphics, displays, control points, passwords, trend displays, interlocks, and sequencing codes. Different configurations are required since every facility is different in terms of equipment and method of operation. Configuration is performed with a variety of tools, including graphical interfaces, relational databases, configuration forms, text files, or combinations of these.
Programmable Logic Controller (PLC) Based Systems
PLC-based control systems are distinguished by their requirement for integration. Typically, someone--either the end user or a company they have hired--must consolidate the PLC and its I/O subsystem with disparate computers and software packages that compose the operator interface and development nodes. It is not uncommon for a PLC-based control system to include products from a dozen or more vendors, including the PLC manufacturer. In contrast, the DCS control system is typically purchased completely from the DCS vendor.
At the controller level, however, the two systems have great similarity. The basic control function and operation described above is equally applicable to both PLC-based and DCS-based systems.
The typical PLC can control hundreds or thousands of I/O points. In some cases the points are monitored solely to display the respective sensed values. In other cases, feedback control is executed on the I/O points associated with the controller.
The PLC is typically performing the following functions:
I/O scanning
Logic processing and interlocking
Communication updates
PLCs have traditionally been strong in logic and interlocking but weak in network redundancy, analog control, and loop (PID) processing. Also, PLCs typically require more attention by control system engineers to set up communication paths which produce a coherent system.
The I/O connected to the PLC monitors sensed values that are sent from field transmitters. The format of the signal sent will vary depending upon the instrumentation used. The controller must collect sensed values from the I/O electronics hardware. Typically, this I/O hardware is located on an I/O network or bus. The I/O hardware converts electrical signals to a digital representation, which must be collected and stored by the controller for logic processing.
Logic refers to a controller's ability to implement a set of rules or conditions. This implementation of logic is related to logic formalisms in language, such as AND, OR, IF/THEN, etc. Often logic must be used to generate these control outputs because an operator could not react quick enough. Interlocking involves specifying with logic the conditions under which it is safe to operate a piece of equipment. The PLC repeatedly works through the logic program as quickly as possible (in the millisecond range). This algorithm varies from PLC manufacturer to PLC manufacturer.
Since the PLC programming environment exposes direct memory locations to the programmer, special attention must be paid by developers to memory maps, accounting for variables, scan order, I/O mapping, and communication updates. Most PLCs can perform communications to other PLC nodes, or to commercial personal computers acting as operator interface nodes. However, significant development time is required to design and implement an effective communications scheme.
Several issues contribute to the difficulty of producing a coherent system throughout the PLC-based architecture.
Because of direct memory addressing, messages sent from PLC to PLC or from PLC to operator interface could become misaligned by even slight configuration changes in the system.
Because of the possibility of misalignment, many rung logic programming software packages implement mnemonic names associated with direct memory addresses. Often these names serve as tags within both the PLC controller and the operator interface.
The mnemonic tag list usually must be manually updated or kept current between the rung logic programming software and the software used to implement the graphic screens on the operator interface.
Most PLC communications are in response to a request for data from an operator interface node. This communication technique is known as polling: repeatedly asking for a block of data so that a current copy is available to the operator interface. Polling wastes network bandwidth and is inefficient. Exception processing techniques are a superior communication mechanism. However, they are difficult to implement in a PLC environment, i.e., the implementation requires significant additional development time and complexity.
Most PLCs rely on the rung ladder logic programming language to implement the bulk of the logic for the control scheme. This is because of the historical development of the PLC as a replacement for relays. The rung ladder logic programming language was designed to mimic the electrical wiring diagram used to design hardwired relay control systems. Some PLC vendors offer other specialized languages for their PLCs, e.g., sequential function charts and structured text.
The operator interface allows operators to view and control the manufacturing facility or process using a graphical interface. The operator interface for PLC-based control systems is distinguished by its variety. Some PLC-based control systems will incorporate an operator interface (graphical monitor) at the I/O network level, directly connected to the controller, or as a node on the control network. In any case, the interface will provide one or more of the following:
Graphic symbols and screens
Trending
Alarm review
Operator log-in and security
Reporting
The development node for a PLC-based control system typically contains several disparate software tools usually from separate vendors:
PLC rung logic programming software
Graphical interface or man machine interface MMI packages
Networking software
Data communications software
and potentially others
These packages must be "integrated" by the control engineer.
Efforts have been made by PLC suppliers to maintain a "rung ladder logic" basis for PLC programming in order to continue to provide a "user-friendly" environment for system developers, maintenance engineers, and technicians. However, the result is that the PLC programming language, while being familiar, places restrictive constraints on memory and resource allocation. These constraints, in turn, can make uncontemplated modification or expansion of existing programs difficult. Unlike its counterparts in the non-real-time computer world, the PLC does not lend itself to shared resources or flexible expansion by simply adding or changing a variable or configuration statement.
In addition to a hardware configuration appropriate to I/O requirements, efficient PLC-based real-time monitoring and control depend on three essential elements:
The PLC processor, which executes the program.
The memory map, or "data file" layout.
The program layout, or the order and frequency of ladder logic execution.
Not only must these PLC integration issues be considered, but also the communications to the operator interface must be carefully considered. Usually, a well-designed layout of PLC data is required to support effective communications between the PLC and the operator interface nodes.
Other Types of Control Systems
While DCS or PLC-based control systems dominate the majority of control system installations, several other types of control systems are briefly described below.
Centralized Industrial Computer-Based Systems
This type of control system is based on an older generation computing model, the centralized architecture. MODCOMP is a vendor who provided a large number of systems during the 1960s based on a centralized computing model. In this model a single computer with a single processor performed all functions: I/O scanning, logic solving, driving operator interfaces, and providing development access. This type of control system closely paralleled the available computing technology of the era. Operator interfaces were typically terminals and logic was normally programmed with FORTRAN or assembler. These systems are essentially extinct for most control applications, although a very tiny number of control applications still require a centralized computing approach.
RTU-Based Systems
RTU stands for Remote Terminal Unit. An RTU can be thought of as a very simple controller. The word "terminal" in RTU refers to their original function: to collect data from remote locations. "Terminal strips" refer to the hardware to which wires are connected. A single wire is connected to a "screw terminal".
Therefore, RTUs were originally used to remotely collect information from geographically dispersed locations. For example, RTUs could be used to collect information at various locations along a 500-mile pipeline. RTUs originally could only sense the valves, perform the signal conditioning and conversion, and transfer the information to a central location. Thus, RTUs included special communications capabilities to transfer data over low bandwidth connections such as telephone lines, microwave links, or via radio. Later, RTUs incorporated very rudimentary logic processing capabilities, programmed either with truth tables or simple rung ladder logic.
An RTU-based control system is often referred to as a "SCADA" system. SCADA stands for "Supervisory Control and Data Acquisition." However, the term SCADA has grown to be loosely applied among control systems. For example, some people call MMI software packages SCADA systems. RTU-based control systems will usually incorporate some type of development node and operator interface nodes in a central location to allow operators to monitor the "wide area" control system.
Personal Computer-Based Systems
Some small control applications are integrating the functionality of the I/O network, the controller, and the operator interface into a single personal computer. These systems typically are only successful for low I/O count applications. The controller functionality is often provided by a software product which will interpret and execute rung ladder logic programs. I/O cards are installed directly into the personal computer, limiting the total amount of I/O by the number of slots in the personal computer.
Background for Understanding Object-Oriented Concepts
The conventional software programming paradigm is the top/down, procedural approach. Reusable code is placed into procedures and functions which are then used by other procedures, functions, or mainline code. Program flow begins at the beginning (top) and proceeds in a straight line to the end (bottom) with "side trips" into procedures and functions along the way. This general approach works well for smaller software applications. However the conventional paradigm is not as efficient for large, complex software applications that rely on graphical user interfaces (GUIs) and require so many side trips that a programmer can get lost in his or her own code. In addition, a procedure or function that works well for one purpose may not be suitable for another very similar purpose. This may require writing another procedure or function with just a slight variation which can lead to code maintenance nightmares in very large applications.
Although object-oriented programming is relatively new, it is rapidly gaining momentum as the programming methodology of choice for developers of large, complex software applications.
Object-oriented techniques integrate top/down programming, procedures, and functions into its paradigm. But it offers additional paradigms that make software code even more reusable, more maintainable, and more extensible than the conventional paradigm can offer. A side benefit is usually shorter coding cycles.
The new paradigm centers around something called an "object." Where conventional programming procedures and functions offer reusable data manipulation, objects offer reusable data manipulation and reusable data (actually, reusable types of data). As a result, so much of the intelligence behind a program is packed inside of objects that the programmer spends less time coding and calling procedures and functions and more time writing code to send, receive, and respond to messages transferred among objects. In many cases, even that code is contained in the object relieving the programmer of even more work.
Encapsulation
This calls for the internal workings and data within an object to be hidden or private but the methods of accessing the internal workings and data to be visible or public. Stated differently, an object can be easily manipulated without accessing or understanding its internal workings, structure, or data. An object's private information is often accessible; however, access is not usually necessary in order to use the object effectively.
The advantage is that the programmer does not have to write code to handle an object's data manipulation requirements. The programmer simply needs to reference the object method that acts on the data.
Inheritance
This allows a programmer to create a new object that uses or inherits the capabilities and attributes of an existing object. The programmer may then add, modify, or delete parts of the new object that differ from the original object, if necessary.
Polymorphism
This word means "to assume many forms." In object-oriented systems, it means that different objects can use the same commands and access methods.
Limitations of Traditional Control Systems
The traditional configuration steps apply equally to both of the major control system architectures in use today: DCS-based systems and PLC-based systems. Essentially, a control system engineer will normally choose to perform a project by selecting one of these types of systems. Also, in many cases a DCS system will be augmented by PLCs using a communications gateway or bridge to link information between the two systems.
In this regard, it is generally recognized that one-third to one-half of all DCS installations are connected to a PLC system via some sort of gateway. This occurs because control engineers are employing separate products to acquire the preferred programming environment for each type of control need. However, it is inefficient and potentially dangerous to have the control for a piece of equipment, such as a large pump skid, spread out among separate systems. It would be preferable to perform both types of control in a single system without giving up the advantages of each separate environment.
Traditional control systems are also limited by the types of hardware and software that can be used, and have limitations on expandability and memory. For example, typically the controller is a closed unit with no expansion slots to add cards in contrast to the way that a personal computer can be expanded. Sometimes minimal expansion is possible by adding other cards in the rack holding the controller. As for memory, a new controller typically must be purchased to gain additional memory to hold new control programs or functionality. Also, because of their specialized nature, most traditional controllers require proprietary firmware. With respect to operating systems, traditional controllers use some form of low-level executive or task manager which does not meet the definition of a true operating system. This translates into reduced flexibility and capability for expansion and custom implementation work. Typically, additional capability, e.g., a real-time expert system, must be achieved by dedicating an additional, specialized node on the network for this task.
In addition to the foregoing disadvantages, the traditional control system development environment suffers from a diversity of tools. This problem is especially acute when developing PLC-based control systems. However, the development environments for traditional systems also suffer from a lack of unification of configuration information. In either the PLC-based or DCS-based system multiple software tools typically produce multiple files of configuration information, often organized by the type of information.
Moreover, in a typical/traditional control system, each part of the configuration information is a separate entity. The logic, tag names, and graphic symbols are all stored either in separate database tables or as separate files. For example, the master control definitions for valves, pumps, and other pieces of equipment may be stored in multiple tables and files with each characteristic of each piece of equipment stored in a separate location The relationships among all these elements are typically established via the tag names, e.g., V1001, PMP3, etc.
Because all control schemes for pieces of equipment are in physically separate tables or files, a developer must tie this information together by building and maintaining an association among tag names, often by a naming convention. Some systems force a part of this name to be the same in order to promote a convention. The traditional model does not exhibit object-oriented characteristics such as encapsulation, inheritance, and polymorphism.
For example, using the traditional model, developers can create control schemes for a new piece of equipment based on an old piece of equipment by copying the original logic and tag definitions and changing the tags to new names, paying great attention to keeping the association/tag naming convention intact. In a traditional control system, this step must be accomplished manually or using an operator-initiated search and replace operation for the control logic associated with each piece of equipment.
To summarize, the traditional control system approach suffers from the following drawbacks:
Because of multiple tools, configuration information has multiple perspectives from which it can be viewed which can make it difficult to manage.
The necessary association between information of various types may need to be maintained manually. If these manual links are not accurately updated then incorrect configuration could result.
It is difficult to retrieve all the information (of all types) for a single piece of equipment or process area.
Multiple types of software tools must be learned. Dissimilar user interfaces may have to be mastered.
The traditional control system configuration cycle is always long, tedious, and requires a significant amount of programming, and laborious prototyping followed by laborious implementation.
SUMMARY OF THE INVENTION
In view of the foregoing, it is a general aim of the present invention to provide a control system that reduces engineering development time for control system configuration, increases intuitiveness of the development tool, and increases structure and unification for the logic comprising the system.
In accomplishing that aim, it is a primary object of the present invention to provide a development system for control systems that allows users to define, in an intuitive fashion, the control scheme for a facility by combining the definition of the physical facility with the definition of the logical instructions which comprise the control scheme.
Another object of the present invention is to provide a development system that integrates the capabilities of analog/regulatory and discrete/sequential/interlocking control programming languages into a single tool.
A related object of this invention is to replace the traditional tools used to accomplish analog/regulatory control and discrete/sequential/interlocking control, that is, to replace function blocks traditionally used to program analog/regulatory control and replace rung ladder logic traditionally used to program discrete/sequential/interlocking control.
A further object of this invention is to provide a structured approach to programming logic instructions for controlling a piece of equipment that fits any controllable piece of equipment and that increases reusability and consistency thus providing a consistent model for building a set of logic instructions to control equipment.
Still another object of the present invention is to provide a unique and advantageous approach to creating, storing, and maintaining a library of control scheme routines compared to the traditional, manual method.
An additional object of this invention is to provide a development system that unifies all the configuration information and other data required to produce a control application such as the control scheme, graphical dynamics, and other attributes of all the devices which comprise a control project.
Yet another object of this invention is to produce a control program in an object-oriented user environment that employs object-oriented techniques at every level in the architecture of the product and at every level in the control system.
A still further object of this invention is to provide a control scheme development tool that graphically expresses the physical nature of a facility, e.g., a process operation or manufacturing plant, and thus emulates traditional design drawings.
These and other important aims and objectives are accomplished with the object-oriented development system for developing control schemes for facilities according to the present invention. The development system includes a device diagramming component for describing a physical description of a facility and a logical definition of a control scheme for the facility. The device diagramming component includes a mode for selecting device symbols representative of equipment or control functions used in facilities. The device symbols are selected from an object-oriented repository containing a plurality of device symbols and device objects. Certain types of device symbols relate to device objects containing logical instructions and configuration information relating to the represented equipment or control functions. The device diagramming component also includes a mode for interrelating in a graphical manner the selected device symbols and their corresponding device objects into a device diagram representing the physical description of the facility and the logical definition of the control scheme for the facility. A device logic developing component defines the logical instructions of the device objects relating to the equipment or control functions. Thus, the development system integrates in a graphical format the physical description of the facility with the logical instructions which define the control scheme for the facility. These logical instructions unify the configuration of analog/regulatory control with the configuration of discrete/sequential control.
BRIEF DESCRIPTION OF THE DRAWINGS
The various aspects of the invention are described in detail below with reference to the drawings, in which:
FIG. 1 is a schematic diagram showing the major subsystems of the User Configurable Open System for Control according to the present invention;
FIG. 2 is a diagram illustrating the device diagram and device definition editors of the present invention;
FIG. 3 is an example device diagram created with the User Configurable Open System for Control of the present invention;
FIG. 4 illustrates the device diagram tool bars organized by tool bar type used in accordance with the present invention;
FIG. 5 is a view similar to FIG. 4 but showing the device diagram tool bars organized by device type;
FIG. 6 illustrates the association between the device diagram according to the present invention and traditional control programming languages;
FIG. 7 is a schematic diagram showing the structured categories of logic for device programming according to the present invention;
FIG. 8 is a screen capture of the device definition editor of the present invention showing the various categories of device logic depicted in FIG. 7;
FIG. 9 is a logic diagram illustrating the logic and tool bars utilized in accordance with the present invention;
FIG. 10 shows several different pages of state logic for a configurable device;
FIG. 11 is a diagram illustrating some of the folder tag definitions used in the present invention;
FIGS. 12A-12D are views similar to FIG. 7, but illustrate in further detail the structured logic approach to programming a device with the present invention;
FIG. 13 is a screen capture of a device diagram window in which a discrete device is being inserted;
FIG. 14 illustrates the conceptual basis of a device object for a discrete device according to the present invention;
FIG. 15 is a view similar to FIG. 14, but showing the conceptual basis of a discrete device template according to the present invention;
FIG. 16 is a view showing a prior art traditional control system development model;
FIG. 17 is a diagram illustrating a representation of configuration information in a typical/traditional control system;
FIG. 18 illustrates the approach to storing configuration information of the User Configurable Open System for Control of the present invention;
FIG. 19 illustrates multiple device objects stored in a unified repository in accordance with the present invention;
FIG. 20 is a screen capture illustrating the object-oriented user interface according to the present invention;
FIG. 21 is a screen capture of the project configuration editor showing major components of a project configured with the User Configurable Open System for Control of the present invention;
FIG. 22 is a schematic diagram illustrating the object-oriented model for the User Configurable Open System for Control of the present invention;
FIG. 23 is a diagram illustrating entry points into the object-oriented repository for the User Configurable Open System for Control of the present invention;
FIG. 24 is a diagram illustrating the relationship between device diagrams and device logic classes in accordance with the User Configurable Open System for Control of the present invention;
FIG. 25 is a view similar to FIG. 1 but showing the process view of each subsystem of the User Configurable Open System for Control of the present invention;
FIGS. 26-46 are a series of screen captures illustrating the step-by-step flow of building an example control application using the User Configurable Open System for Control of the present invention;
FIGS. 47-57 are a series of screen captures illustrating the step-by-step process of modifying discrete device logic of the example project illustrated in FIGS. 26-46 using the device definition editor of the present invention;
FIG. 58 is a screen capture showing the group display configuration for the example control application shown in FIGS. 26-46;
FIGS. 59-62 are screen captures of the graphic screen configuration for the example control application shown in FIGS. 26-46;
FIG. 63 is a run-time screen showing four devices placed on a graphic screen and showing a command window;
FIGS. 64-68 illustrate use of the device template definition editor of the present invention to modify a discrete device template used in connection with the example control application shown in FIGS. 26-46;
FIG. 69 shows the insertion of a new discrete device following modification of the corresponding device template as illustrated in FIGS. 64-68; and
FIG. 70 shows the graphic screen at run-time after the modified discrete device has been inserted into the device diagram in the example control application of FIGS. 26-46.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
FIG. 1 is a schematic diagram illustrating the User Configurable Open System (UCOS) for control according to the present invention. UCOS is a control system that employs object-oriented techniques at every level of its system architecture. As shown in FIG. 1, UCOS 100 includes a number of subsystems which segment the functionality of UCOS. Specifically, UCOS 100 includes an Engineering Workstation Subsystem 102, an Operator Workstation Subsystem 104, and a Field Control Unit (FCU) Controller Subsystem 106. The subsystems communicate via a Control Network 108. As explained in significant detail below, device object configuration and device diagramming is performed at Engineering Workstation Subsystem 102. This configuration information is downloaded into a corresponding controller such as Field Control Unit 110 as illustrated via communication line 112. A plurality of Operator Workstations 114 can be included in the UCOS system each having an Operator Workstation Subsystem, although only one workstation is shown in FIG. 1. Each Operator Workstation receives selected device object updates from Field Control Unit 110 and sends to Field Control Unit 110 operator-initiated commands as illustrated by line 116. The controllers 110 solve the logic for each device object, process I/O for field devices, and update operator workstations as required.
UCOS executes under the Windows NT operating system of Microsoft Corporation which provides a graphical, object-oriented, window-based environment. UCOS takes full advantage of the windows environment thus providing a standardized user interface for both project development and execution. Although this interface is an integral part of UCOS, it is not unique to UCOS and is, therefore, not described herein.
Combining the Physical and Logical Representation
When a control engineer examines a control program built using a traditional development tool such as rung ladder logic or function blocks, the engineer essentially receives a sense of the logical sequence of instructions which operate the facility or piece of equipment. However, minimal information is conveyed about the facility itself or about its physical character. For example, the physical character of a chemical process would include the flow of product or material through the piping and associated tanks. This lack of physical character information arises because the traditional tools are essentially procedural programming languages. As such, they can inherently convey only information about the "logic" which controls a piece of equipment. Other information, such as a description of the equipment and its role in the facility, must be gathered from other sources.
In accordance with the present invention, UCOS introduces a totally new paradigm: allowing the control program for a facility to intuitively convey multiple types of information. By doing this, UCOS allows a control engineer to literally glance at a device diagram and understand both the definition of the physical facility, i.e., what equipment is present and how it is connected, and the logical definition of control instructions which operates this interconnected equipment.
In essence, the UCOS development tool of the present invention conveys more information to a control engineer than simply logical, control instructions information. The "device diagram" of UCOS, discussed below, presents to the developer the big picture, i.e., how the devices to be controlled fit into the facility. More importantly, the device diagram can show how material or product are processed and routed through the facility. The traditional control systems provide graphical ability only when showing process flow via the graphics screens which can be created for operators. While UCOS also has this ability, the development tool in UCOS employs a graphical approach for building a control program. This allows the development tool to convey multiple types of information to the user.
This control program is the UCOS Device Diagram 118 shown in FIG. 2, a collection of device symbols 120 each of which leads to logic that defines the control functionality of the device or equipment represented by the device symbols. The device symbols and the connection lines between device symbols on a device diagram are the underpinning of the combined representation of physical definition and logical definition. Certain device symbols, such as static container devices, contribute primarily to representing the physical facility. Other device symbols, for example controller devices (an anolog device), contribute primarily to representing the logical definition of how control is performed on devices. Still other devices, for example discrete devices, contribute to both representations.
This approach is extended by the Device Diagram's inherent capability for creating/modifying device diagram symbols. In accordance with the present invention, the capability is provided to use an auxiliary editor that is part of Device Diagramming to construct a symbol which can be applied as a device symbol to be placed on the diagram. These user-defined device symbols allow for specification of a symbol which can connotate either physical or logical representations. The connection points and their type can also be specified, heightening the flexibility this method produces.
Discrete Device symbols are especially important for representing the physical and logical definition because they normally have mechanical connections on a device diagram. Double clicking on their symbol brings up the Device Definition Device Logic editor 122 which allows the user to review the logical control instructions associated with that discrete device.
Both the device symbols 120 and the types of connections a user can draw between symbols contribute to the combined representation. The graphical nature of a device diagram supports its ability to convey multiple representations intuitively. This graphical nature is in turn supported by the Windows user interface which acts as a fundamental, enabling technology. Internally, UCOS accounts for all devices with an object model that allows for their differing characteristics, logic capabilities, and symbolic representation.
In the UCOS Device Diagram development tool the combined representation of the physical and logical definition originates with the device symbols 120. These symbols are organized on Windows toolbars 124 which contribute to the intuitive manner in which the development tool allows for selection and placement of devices. When connecting devices, UCOS assigns connection types based on the device types being connected. This also contributes to the intuitive nature of the development tool. These toolbars and connection types are also shown in FIG. 2.
The Device Diagram 118 operates in a graphical manner allowing the device symbols 120 to be moved, rotated, and arranged. This enables the user to decide the proper balance between representing the physical nature of the facility and the definition of the control scheme logic. This control scheme logic could include either the analog/regulatory control capability supported by analog UCOS devices or the underlying logic which is part of a discrete device. The user could develop a device diagram primarily devoted to representing the logical control scheme, or orient the diagram to emphasize the physical facility. If desired, both aims could be accomplished in a single diagram.
In accordance with the present invention, UCOS models equipment and logical control schemes as device objects. A Device Diagram 118 is a collection of these device objects, connected together in a symbolic editor using a graphical approach. Each symbol on a device diagram leads to a type of UCOS device, whether static, analog or discrete. The UCOS device itself contains definition information and logic which describes how it executes in a UCOS field control unit (FCU).
Device diagram 118 represents a unique combination of information which describes the physical facility and also describes the logic which controls the facility. Moreover, this information is synthesized in a graphical, intuitive format that is very familiar and easy to follow for the control system engineer. FIG.3 illustrates in greater detail an example device diagram.
This device diagram contains six control devices: switch LS-1235, transmitter FT-1230, controller FIC-1230, analog end device FCV-1230, PMP-1236 and S.sub.-- PMP-9001. Two static devices, TNK-1235 (a container) and FE-1230 (an element) are also included. The diagram also shows three types of connections: mechanical connection 126; instrument connection 128; and internal connection 130.
The device diagram of FIG. 3 is an excellent example of the ability of UCOS to combine representation of the physical facility and logical definition. By simply glancing at this diagram a control engineer can understand the physical definition and how it is being controlled. The diagram clearly shows the tank feeding two pumps connected in parallel with a control valve regulating the amount of flow--all information about the physical definition of this facility. The control engineer knows he could go to the facility and locate the tank, the two pumps, etc. For the logical representation, the control engineer knows that a transmitter is feeding a PID Controller which sends an output signal to the control valve to regulate flow. To further examine the logical definition, the user need only double click on the switch, transmitter, controller, or pump device symbols to see additional details about their logic.
The use of the Windows user interface supports and augments the device diagram's ability to represent the physical and logical definition of the facility. Additionally, the device diagram editor can be used to produce diagrams which closely resemble traditional design drawings which usually describe the physical facility, e.g., a P&ID or mechanical flow sheet. For process facilities this capability is augmented by the adherence to Instrument Society of America (ISA) standards for many UCOS Device Diagram symbols. However, the user can actually determine the contribution a particular device's diagram symbol makes to either the physical or logical representation with UCOS's inherent capability to customize diagram symbols. The capability is provided to use an auxiliary editor that is part of Device Diagramming to construct a symbol which can be applied as a device symbol to be placed on the diagram. These user-defined device symbols allow for specification of a symbol which can connotate either physical or logical representations. The connection points and their type can also be specified, heightening the flexibility this method produces.
The symbols and connection types on the device diagram hold the key to this combined representation. Table 1 below segments the contribution a device symbol or connection makes to either the physical or logical representation. This segmenting serves to illustrate how the symbolic approach based on graphical concepts serves multiple purposes in conveying information to the user. Some items significantly contribute to understanding both the physical and logical definition and are therefore listed in both columns. For example, a knowledgeable control engineer could glance at a device diagram containing a transmitter, controller, etc. and easily understand both the physical and logical relationship that the switch has with other devices within the process.
TABLE 1 ______________________________________ Connotates The Connotates The Item Physical Facility Logical Control Scheme ______________________________________ Diagram Symbol Switch Symbol Switch Symbol for a Particular Transmitter Symbol Transmitter Symbol Device Type Controller Symbol Computing Device Symbol (s) Analog End Device Analog End Device Symbol(s) Symbol(s) Static Device (Container) Symbol (s) Static Device Static Device (Element) (Element) Symbol(s) Symbol (s) UCOS supplied UCOS supplied Discrete Discrete Device Device Symbol(s) Symbol (s) User Created User Created Device Device Symbol(s) Symbol(s) Connection Type Mechanical Instrument Instrument Internal ______________________________________
The symbolic, graphical approach employed by UCOS is consistent with standards set for Windows-based software packages. The device diagram editor further simplifies configuration by making use of toolbars, an object-oriented Windows mechanism for grouping menu items and functionality. The UCOS Device Diagram editor is inherently symbol-based because the user is always viewing a device through its symbol, the same symbol which the user originally selected to place the device object on the diagram. The UCOS symbols for devices are organized in groups on toolbars. The symbols which UCOS employs to represent some devices are specified by ISA standards. A device object's placement in a device diagram can represent the logic in the control scheme or the physical facility or both depending on the device type.
The User Created Device Symbols particularly heighten the user's ability to closely and accurately represent the physical definitions of the facility. If a new type of equipment requires representation the user need only use the Device Symbol editor to create a representation for the device, and specify its connectable points. By providing flexibility in both symbol design and connection type designation practically any facility can be graphically described. Therefore, a UCOS device diagram could represent with equal effect a chemical process facility, a coal handling conveyor system, or a collection of commercial or industrial buildings. Furthermore, User Created Device Symbols allow for creation of configurable devices which can represent control functions which may include coordinating multiple devices, sequencing and interlocking among several devices, calculations, etc.
Referring to FIG. 3, the significance of the internal connection line 130 is evident when examining the definition of the controller device by double clicking on it. The act of drawing connection line 130 between FT-1230 and FIC-1230 caused an internal association of tags between those devices. Effectively, this dashed line logically linked these two devices. The instrument connection 128 allows the device diagram to expose information about the logical and physical connections of the instrumentation and input/output points of the control I/O hardware. Again, this information co-exists on the same diagram that shows the physical facility, illustrating how the symbolic, graphics based approach conveys multiple types of information in a single entity.
FIG. 4 illustrates the UCOS toolbars available in the device diagram editor. The four toolbars are stacked horizontally to correspond with their names, the four checked items in the pull-down sub-menu. The toolbars provide an accessible, graphical grouping mechanism. UCOS static devices are organized into two groups: containers and elements, which correspond to the bottom two toolbars 132 and 134. The device toolbar 136 organizes devices into three sub-categories: switch/transmitter/controller devices 138, computing devices 140, and analog end devices 142. The toolbar organization can be further understood with reference to FIG. 5. This figure shows the correspondence between the INSERT pull-down menu 144 and the toolbars. Again, the toolbars are stacked horizontally to correspond generally with the items listed on the menu.
Each symbol on each toolbar, when selected, allows the user to place a device object of that type on the diagram. The wide selection of discrete device symbols on discrete device toolbar 146 in particular strengthens the ability of UCOS to represent both the physical nature of the facility and its logical control definition. Further strengthening this capability is the ability to create or customize device diagram symbols. Discrete devices are key because they normally have mechanical connections. However, they harbor significant logical functionality which is accessed by double clicking on the device symbol.
The tremendous power of the representations offered by the UCOS development tools are most apparent when a control engineer can be observed glancing at a diagram like FIG. 3, and then being able to describe the major characteristics of the physical facility and logical control scheme by that simple glance.
The Hybrid Nature of UCOS
In keeping with an important aspect of the invention, the UCOS configuration environment unifies and simplifies the historically disparate DCS vs. PLC configuration environments. Because of this, UCOS does both Analog/Regulatory and Discrete/Sequential/Interlocking control well.
The Device Diagramming step in UCOS represents a unique blend:an environment which unifies the configuration of analog control with the configuration of logic used to implement Discrete and Sequential control. Both of these capabilities are included in the UCOS object-oriented model for control devices.
The reaction of most control engineers to Device Diagramming and underlying logic for configurable devices would be that they have never seen these concepts tied together before. This is due to the fact that most control system engineers are used to programming Discrete/Sequential control with rung ladder logic (a PLC tool) and Analog/Regulatory control with function blocks (a DCS tool).
The hybrid nature of UCOS extends throughout the architecture of the system. It is possible to build a hybrid control system using DCS components and PLC components. However, UCOS is hybrid throughout, in both its configuration environment and its run-time execution environment. The innovation this represents is a new level of coherence and simplicity within a control system architecture. Greater simplicity, including elimination of Gateways and other potential data transfer bottlenecks, results in a more reliable, more robust system.
Hybrid Capabilities at the I/O Level
In the illustrated embodiment, UCOS uses PLC I/O, although not the PLC controller. However, UCOS has the capability, as an open system, to use practically any PLC vendor's or DCS vendor's I/O Subsystem.
It has been mentioned previously that some control system engineers build a hybrid system using some DCS components and some PLC components. What these system engineers do as an ad hoc method of integration, UCOS provides as a standard feature.
UCOS incorporates what is essentially a vendor-independent I/O model. This model relates to the UCOS control device model. However, the UCOS method of representing I/O is its own technology for allowing a single UCOS controller to scan and control I/O from separate vendors, for example Allen-Bradley and GE Fanuc.
The use of I/O subsystems is a hybrid feature because UCOS uses PLC I/O while providing DCS-like configuration of the control schemes which attach to this I/O. Typically, a PLC must be programmed to make use of its I/O, often using direct memory addresses and other hard coded procedural programming structures.
PLC vendor I/O has a larger installed base than DCS I/O because PLC control systems apply to a wider variety of industries. Thus, UCOS allows the DCS engineer to use market leader I/O subsystems without sacrificing the advantages of DCS configuration techniques. At the I/O level, the evidence of a hybrid system is hard and direct: PLC I/O is directly connected to the UCOS controller. The UCOS controller (FCU) meanwhile, provides the logic capabilities of a PLC and the analog control capabilities of a DCS controller.
UCOS can also leverage any redundant capabilities of the PLC I/O subsystem. For example, GE Fanuc I/O provides network media redundancy. UCOS has incorporated this failover ability and has augmented it with redundant FCU's and, more importantly, with redundant network paths between the FCU and OWS nodes. This latter function is difficult if not impossible to achieve in a PLC-based system.
Hybrid Capabilities at the Controller Level
Hybrid capabilities at the controller level, from a software perspective, are closely related to hybrid capabilities at the development node. This is because the control scheme which the UCOS FCU executes is configured with the UCOS EWS software.
Controller hybrid capabilities from a hardware and operating system perspective are closely related to the modern design approach embodied in the UCOS controller. The UCOS FCU is one of the most differentiated components of the architecture in comparison to both DCS and PLC controllers. Many of the competitive advantages of the UCOS controller are derived from the general product flexibility of personal computers. It is the application of a personal computer as the controller that is futuristic and represents a trend in the control industry. UCOS is at the forefront of this trend. How UCOS makes use of the personal computer characterizes the hybrid nature of the system.
Table 2 below outlines the vast differences between the UCOS FCU and traditional controllers. The differences are illustrated and their hybrid nature is discussed in the table.
TABLE 2 ______________________________________ Category UCOS DCS and PLC ______________________________________ Hardware Uses off-the-shelf Each vendor manufactures industrial personal its own controller from computers from a variety of board-level electronic manufacturers. Example: components. Texas Micro Systems, IBM, etc. The fundamental electronic components and technology are often similar to DCS and PLC controllers (and are, therefore, hybrid) but the supplier channels are totally different. Expand- Using the concept of putting Typically, the controller is ability cards in a PC the UCOS a closed unit with no place controller allows for to add cards. Sometimes unprecedented expandability. minimal expansion is possible by adding other cards in the rack holding the controller. Memory Standard PC memory chips Typically a new controller provide low-cost must be purchased to gain expandability. additional memory to hold new control programs or functionality. Firmware Often industrial PC's used Because of their specialized as the UCOS controller nature, most traditional employ industry- standard controllers require BIOS and firmware chip sets. proprietary firmware. Operating The UCOS FCU runs QNX, Traditional controllers use System an industry-leading, real-time some form of proprietary standards-based, open "operating system" (which platform, and open of ten is no more than some architecture operating form of low-level executive system which is available to or task manager) that is the user. This greatly adds typically embedded and not to the hybrid nature of UCOS accessible because of its because virtually any singular purpose: to application can be built execute the proprietary using standard tools for control logic of that deployment on the UCOS vendor's system. This FCU. For example, an expert translates into reduced system could run on flexibility and capability the UCOS FCU interacting for expansion and custom directly with UCOS devices. implementation work. Typically, additional capability, e.g. a real- time expert system, must be achieved by dedicating an additional, specialized node on the network for this task. ______________________________________
In the preferred embodiment of the present invention, the UCOS FCU is a software environment running under QNX on a personal computer. Consequently, UCOS has adapted and merged the analog control capabilities of DCS controllers with the logic processing capabilities of PLCs. Essentially, the UCOS FCU must execute the hybrid control schemes downloaded to it from the OWS 104. These hybrid control schemes are generated as part of the object-oriented device diagram configuration performed at the EWS. As such, these control schemes represent both analog and discrete logic capabilities in a single stream of instructions at the FCU level. In most other DCS or PLC controllers, one sub-task may perform analog processing, another timing and sequencing, another interlocking, and so on. Because UCOS incorporates a unified model for both analog and discrete control, the resulting FCU application logic is unified and executes a hybrid control program delivering the required capabilities of both types of control.
Hybrid Capabilities at the Operator Interface Level
The purpose of an operator interface node in a control system architecture is to provide tools for an operator to visualize the process. As such, most control systems eventually provide similar capability at the operator interface level. However, there may be substantial differences as to how these capabilities are implemented. Some systems might require more or less engineering time to produce the operator interface. Some might require more repetitive steps than others. Some might require the engineer to perform more manual bookkeeping of tag lists, cross reference lists, etc.
The hybrid nature of UCOS greatly minimizes the effort required of the control system engineer to produce the operator interface. Essentially, most of the operator interface is a by-product of the device diagramming step. While this hybrid nature does not directly manifest itself from an operator's perspective, the engineers who develop the system would be aware of it.
Hybrid Capabilities at the Development Node
Hybrid capabilities at the development node relate specifically and directly to the UCOS object model and the merging of analog and discrete control. For many years, the DCS configuration environment has consisted primarily of "function blocks" performing regulatory control. For many years, the PLC programming environment has consisted primarily of "rung ladder logic" performing discrete control. The UCOS Device Diagram, as a control program, merges the capabilities of these traditional environments.
As noted above, one-third to one-half of all DCS installations are connected to a PLC system via some sort of gateway. This occurs because control engineers employ separate products to acquire the preferred programming environment for each type of control need. However, it is inefficient and potentially dangerous to have the control for a piece of equipment, such as a large pump skid, spread out among separate systems. Control engineers would prefer a way to perform both types of control in a single system without giving up the advantages of each separate environment.
Generally, UCOS provides this dual control via the following structure illustrated in FIG. 6. The perspective of Device Diagrams as shown in FIG. 6 allows for their comparison to the traditional control programming languages. A single Device Diagram will contain one or more devices. Each device can be either a configurable analog device 148 (very much like a single function block 150) or a configurable discrete device 152. A configurable discrete device has a device definition which includes multiple pages of logic for the device (analogous to rung logic 154). This logic is not exactly the same as rung logic, but provides similar discrete control capabilities such as sequencing and interlocking. Essentially, the device definition logic is like a piece of rung ladder logic. The UCOS logic, however, resembles the written logic design that engineers typically draw before programming the PLC with the rung ladder logic language. UCOS logic configuration is performed with graphical tools whose results closely represent and mimic the design drawings engineers develop.
Referring again to FIG. 2, actual screen captures of a UCOS device diagram 118 are shown with a portion of the underlying Device Definition Logic 122 for a pump device (PMP-1236). Importantly, the UCOS Device Definition editor 122 emulates diagrams typically drawn when designing the logic to be programmed with the rung ladder logic language. Therefore, the UCOS Device Definition editor 122 shares a goal with the UCOS Device Diagram editor 118, allowing the user to configure logic with a graphical tool that mimics design drawings he/she is familiar with.
From an object-oriented viewpoint, the hybrid nature of a UCOS Device Diagram is enabled by the device object model. Because each device is an object, the objects can have their own unique data, properties, methods, data types, and structures. Therefore, a device diagram can interrelate these device objects. This object orientedness also enables generation of a single device diagram execution scheme or set of instructions for the FCU.
Another significant aspect of the UCOS approach relates to tag definitions. The UCOS FCU and EWS/OWS nodes "see" a single set of configuration information. Specifically, all nodes are aware of the tags for any device object. This is a hybrid characteristic because DCS-based systems typically provide good tag coherence throughout the function block environment.
PLC-based systems typically suffer from two types of deficiencies with respect to tag management. First, the PLC itself does not have tag capability; the PLC only provides direct memory addresses. Therefore, PLC-based systems require the engineer to use "mnemonics" typically available in PLC rung ladder logic programming software as tag names. These pseudo-tags then require user management to keep them "connected" to the proper direct memory addresses. Small changes to this "memory map" can adversely impact an entire PLC program. Second, the engineer must assign pseudo-tags according to a naming convention if he/she desires the DCS style capability of having all the tags associated with a piece of equipment similarly named.
UCOS merges the "tag bookkeeping" capabilities of the DCS into its device object model and, therefore, frees the logic developer from these duties. If the logic was developed separately, outside UCOS, tag bookkeeping would be required.
The UCOS Structured Approach to Device Programming
UCOS is a control system which provides hybrid capabilities in comparison to DCS-based and PLC-based systems. A significant improvement in UCOS, however, is its structured approach to device programming which effectively improves upon and replaces rung ladder logic used in these two traditional systems. Every UCOS discrete device exhibits this logic structure. Additionally, UCOS Device Templates, explained in further detail below, incorporate this structure, since discrete devices are instantiated from these templates. The structure provided is itself unique, and coupled with the event-based logic processing capabilities of the UCOS FCU, provide significant advantages over the rung ladder logic programming and execution environment.
The UCOS structured approach segments logic into five categories: MODE, FAULT, STATE, CONTROL, and ALARM. Each category of logic has slightly different execution characteristics in the UCOS FCU. These characteristics save programming time and complexity in comparison to rung ladder logic. For example, many PLC programs contain code to handle latching bits and enforcing mutual exclusivity among several signals. The UCOS structure for device programming provides FCU execution support which handles these tasks transparently for certain categories of the control logic. This allows the logic to focus on operating the device, and not be cluttered by internal housekeeping.
The logic in each category is essentially the same, produced within a common editor with common toolbars of input/output tags and logical operators. The structure recommends an intended use for each category of logic, which if employed, will maximize the ability of the structure to save programming effort and increase maintainability. The structure is generic in that it can be applied to any piece of equipment which can be controlled with discrete (on/off) outputs. Certain categories of logic are intended to feed others, resulting in a cascade of logic solving which maximizes the benefits of the FCU execution support. This intended order of use is conceptually depicted in FIG. 7.
As shown in FIG. 7, the user could apply the structure by building MODE logic 156 and FAULT logic 158 with the intention of feeding these outputs to the STATE logic 160. Then the output of the STATE logic 160 could be used in CONTROL logic 162
to actuate the device. ALARM logic 164 could be used to produce messages for an operator. No control action would normally be taken in ALARM logic 164. This represents one approach to using the UCOS Device Logic structure which provides particular benefits. Other approaches, however, are possible and might provide similar or different benefits.
The Traditional Programming Tools
A control engineer must describe how a piece of equipment will function or operate using a software tool or control programming language that can cause this operation within the control system. The two major types of control systems, DCS-based and PLC-based, each have developed their own control programming language to meet this need. DCS systems typically rely on Function Blocks, and PLC-based systems typically rely on rung ladder logic. Both languages have the capability to "solve logic." Traditionally, rung ladder logic is viewed as the better tool of the two for discrete/sequential logic, while function blocks are viewed as better for analog/regulatory logic. Also, some DCS systems can also solve rung ladder logic.
As a hybrid system, UCOS exhibits the best capabilities found in both DCS and PLC-based systems. UCOS, therefore, also needed a way for users to describe how a piece of equipment will function or operate.
Rather than simply incorporating rung ladder logic as a component of a discrete device, UCOS provides a totally new method and structure for describing the logic necessary to control a device. This new structure for device programming is the answer of the present invention to rung ladder logic capabilities in traditional control systems. The UCOS device logic structure shares some similar characteristics with rung ladder logic.
Both are primarily designed to produce digital control output signals, i.e., on/off, start/stop, open/close, etc.
Both allow for and incorporate standard logical operations such as AND, OR, NOT, etc. These operations can be arranged in various configurations which effect the "solving" of the logic.
Both require a specialized controller to solve the logic. For rung ladder logic, the control engineer typically writes the logic program with DOS-based software and then compiles and downloads the logic to a PLC for execution. To perform actual control, the rung ladder logic must execute in the PLC. In UCOS the device logic structure is downloaded in a similar fashion to a UCOS FCU for execution.
These similarities, however, are overshadowed by the significant improvements and advances that the UCOS device logic structure provides. By its very nature rung ladder logic allows the programmer to create structured or un-structured logic or anything in between. Also, the "scanning" approach employed by all PLCs requires the programmer to spend considerable energy and effort just to account for "local variables," scan order, memory maps, and real world inputs and outputs.
The UCOS device logic structure removes from the control engineer these burdens and potential pitfalls. This results in time savings to write device control logic and greater reliability, maintainability, and re-usability of that logic.
The UCOS Device Logic Structure
UCOS provides a structure for device logic. The structure itself is unique in that it exposes the base elements required for control of a device. The structure also will fit any controllable piece of equipment. The UCOS innovation is exposing these base elements which are all included in any rung ladder logic program one would write for any device. The UCOS device logic structure is designed to aid the writing of control logic for a piece of equipment which can be controlled with discrete outputs. Further, UCOS analog and discrete devices could be used in combination on a device diagram to perform coordinated regulatory and discrete/sequential control.
UCOS allows the control engineer to draw logic diagrams organized into five fundamental categories: MODE, FAULT, STATE, CONTROL, and ALARM. The logic that can be placed "inside" each category is drawn using the same editor and the same base logic elements. In fact, the logic in the MODE category is no different than the logic in the FAULT logic category. However, the intended use for each category of logic is different. This "intended use" is an underpinning of the UCOS device logic structure. Also, each category of logic is supported by a "graphical folder" defining UCOS tags which will receive the output of the logic in a category. The "intended use" of logic in a category is more than a convention. The logic solver in the UCOS FCU provides slightly different behavior for the logic in each category with respect to the output tags associated with the logic.
Each category of UCOS logic takes one or more UCOS tags as "input tags," solves a network of logic "gates" or operators, and produces on/off values for UCOS tags used as logic outputs.
FIG. 8 shows the UCOS Device Definition Editor 122 displaying the logic for a pump discrete device (PMP-1236). Note the five categories of logic within the common editor. The toolbars 166, 168, and 170 show the logic elements available for placement and connection on any of the five logic categories.
In comparison to rung ladder logic, a premise of the UCOS device logic structure is that any rung ladder logic program has Modes, Faults, States, Controls, and Alarms, but that the programmer may not recognize them as such. The value of these five categories derives from their near-universal applicability to any piece of equipment which needs discrete outputs for actuation and control. By bringing these categories to the surface and effectively forcing the control engineer to define consistent logic organized into these categories, UCOS inherently provides a system which has greater maintainability and integrity. The ability to re-use logic is also greatly heightened because of the device logic structure. Because of the structure, these benefits are more easily achieved regardless of the discipline, education, or skill of the control engineer involved. To say this another way, a few control engineers might be able to write rung logic programs which exhibit a similar structure; however, most would not achieve this goal, resulting in complicated, hard-to-debug and maintain rung ladder logic control programs.
Constructing Discrete Device Logic
Referring to FIG. 9, any page of UCOS logic will be comprised of three types of elements: input tags, logical operators, and output tags. FIG. 9 shows some example logic with these three types of elements. The logic elements are organized in toolbars, with the toolbar 172 containing input/output tag symbols, while the toolbars 174 and 176 contain logical operators.
FIG. 9 shows one page of State logic. This particular UCOS discrete device actually has four pages of state logic defined. For any category of logic, each output tag that appears on a logic page is defined in the device's tag definitions folder for that category of logic. For example, the "PMP-1236.Starting" tag in the logic of FIG. 9 is used as a State output tag. Therefore, it must be defined in the State Tag Definition folder. However, it can also be used as an input in any other appropriate category of logic.
Referring now to FIGS. 10 and 11, the four pages of State logic and the four output tags used are shown in FIG. 10, while the definition of these tags is shown in the States folder of FIG. 11.
FIGS. 10 and 11 also show how tags from other tag definition folders can be used as State logic inputs (Stopcmd, Stoppb, etc.). On State logic pages, however, output tags must be listed in the States folder. All of the UCOS device logic categories exhibit this characteristic: output tags must come from the folder which corresponds to the same category of logic; input tags, however, can come from any folder. By requiring output tags to be listed in the folder for that category of logic, the UCOS device logic structure enforces conformance and consistency in applying the structure. This also ensures that a device tag will not be used incorrectly or for conflicting purposes, e.g., as both a state and as a mode. Furthermore, there are additional folders in the tag definitions dialog which exist primarily to provide input tags not associated with Mode, State, Alarm, Fault, or Control Logic. The Commands folder shown in the FIG. 11 is an example. Input tags can also come from a Setpoints folder, Analog Controls folder, or from other devices via the totally black input tag symbol 178 (FIG. 10).
As noted above, the logic categories primarily provide a structure for organizing the output tags into folders and allowing for slightly different execution properties in the UCOS FCU. The logic itself is fundamentally the same for each category, making use of a common editor and set of input tags and logical operators.
The designation of logic into these categories coupled with each category's distinctive FCU execution properties is an important part of the inventive aspect of the UCOS device logic structure. Proper use of these two properties allows control programs to be developed much more quickly and with much less programming than rung ladder logic-based systems.
Properties of the Logic Categories
Each logic category is detailed in Table 3 below with respect to its properties within the UCOS Device Logic Structure and describes in general terms the interactions of the various logic categories.
TABLE 3 ______________________________________ Logic Category Intended Use FCU Execution Support ______________________________________ Mode Mode logic defines how the The FCU enforces mutual device will transition into exclusivity per mode group. different Modes. These The user designates each tag "modes of operation" (e.g. in the Mode folder as part Local/Remote, Auto/Manual) of a mode group. The FCU are examined during the only allows one tag per mode execution of State logic. group to be set at any given instance. Fault Fault logic describes The first tag listed in the "severe abnormal Fault folder is set by the conditions" associated with FCU as the logical OR of all the devide. These "fault the remaining fault tags. conditions" (e.g. "very This first fault tag will high bearing temperature") normally be named are examined during "ANYFAULT" and will not execution of State logic, be driven by user-defined and are reported as "severe logic. alarms" to the user. State State logic relates to the The FCU enforces mutual observable, controllable exclusivity for all state States of the device. tags. The FCU allows only State logic examines one state tag to be set at "conditions of" Commands, any given instance. Modes, Faults, Setpoints, etc. to determine the current State of the device. The current device State is examined during execution of Control logic. Control Control logic examines "conditions of" States to determine the value of internal and real-world outputs. These "control outputs" operate the device. Alarm Alarm logic describes "less severe abnormal condition" associated with the device. These "alarm conditions" (e.g. bearing approaching high temperature) are not necessarily examined by the other categories of logic, but are reported as Alarms to the user. ______________________________________
In the preferred implementation, the UCOS FCU will solve the categories of logic in a particular order: Alarm, Fault, Mode, State, and Control. This solving order, combined with the FCU's event-based logic processing capability, serves to augment the category-specific FCU execution support. Consider the state logic figures presented earlier in FIG. 10 as an example. Since four state tags are used, the FCU enforces mutual exclusivity on these tags, i.e., only one of the four is ever set at a given instance. The state tag that is "set" will remain set until another state tag becomes set, which causes the FCU to reset all the other state tags. The tags in the state folder can be used as inputs on any of the logic in a device. The event-based processing capability in the FCU sends messages to the other logic "networks" which use a state tag when the tag is set or reset. This event-based or message-based approach guarantees that a state transition is not "lost."
Comparing these ideas to a rung ladder logic based system exposes two critical points. First, a PLC programmer would need to "write code" to enforce any mutually exclusive behavior, whereas in UCOS this capability is inherent. Second, a PLC programmer would need to write code to latch and un-latch bits in memory to achieve the equivalent set/reset functionality of UCOS logic. These two points combined greatly reduce the task of writing control logic in UCOS, and the associated testing, debugging, and re-testing.
Conceptual Summary
FIGS. 12A and 12B are designed to tie together the various concepts described for the UCOS structured approach to programming a device. These figures are intended to show the progression from input information, to solving the control scheme for the device, to control outputs in greater detail than shown in FIG. 7. FIGS. 12A and 12B represent the intended use or recommended use of the UCOS Device Logic Structure, but also implies via dashed lines 180 and 182 that the user could circumvent the intended use.
Fundamentally, the user is expected to use Mode logic 156 and Fault logic 158 to generate outputs which are fed into State logic 160. The result of the State logic 160 should then be used to drive the discrete outputs via Control logic 162. Alarm logic 164 should be used only to generate messages for operators.
UCOS Templates
Most control system engineers will construct a library of starter routines as they complete various projects. This library might be in rung ladder logic, function blocks, or both. Often, the control system engineer is only as good as his toolbox of starter routines. This technique has become so pervasive that books of starter routines are published and sold to engineers.
However, UCOS is the first control system product to incorporate direct support for this tendency of engineers to collect a library of starter routines. UCOS Device Templates allow engineers to build their library within the control scheme development environment. Additionally, UCOS supplies starter routines for control of typical devices. The power of Device Templating is augmented by the ease with which templates can be applied when building a device diagram. FIG. 13 shows how a user places a pump device on a device diagram by instantiating the definition based on a pump device template object.
The left side of the dialog designated by reference 184 shows the names of template definitions for discrete devices. This is the user's list of starter routines. The right side 186 of the dialog allows the user to specify identifying information about the device to be created. Note that the device is targeted to a specific FCU (Simulator) for execution of its logic.
All UCOS devices, when placed (or instantiated) on a device diagram, come from a template. UCOS devices have a template structure which incorporates user-modifiable logic, tag definitions, and graphic symbol dynamics. The underlying device object model utilized by UCOS employs a template approach for both analog and discrete devices.
Tag management is one of the primary advantages of UCOS templates compared to manually building a library of routines. Because UCOS templates are an intrinsic part of the Device Diagram and Device Logic development process, the user does not have to perform traditional search and replace editing functions on the inherited logic. Additionally, UCOS templates provide mechanisms for placeholder tags which can be resolved for external device linkages after instantiation. This placeholder capability further increases the usefulness of device templates.
Essentially, a template acts as a guide to the format of the new device being created. UCOS supports categorization methods so that multiple types of templates for a kind of device can be created. For example, you might have several types of pump templates, several types of valve templates, as well as one-of-a-kind templates. Each template specifies the following information about a device:
The logic which the FCU will execute at run-time
The names and characteristics of tags associated with the device
The symbol to use in representing the device on the device diagram
The dynamic, graphical behavior of a symbol used when representing the device on a graphical project screen that the operator uses to monitor the process
The above information is represented by FIG. 15 which illustrates the relationship of these elements within a template.
Once a template is created, devices based on it can be inserted into device diagrams. The user simply chooses from a toolbar or menu the type of device he/she wants to insert, supplies relevant configuration information, and points in the diagram where that device is to be placed.
FIG. 13 illustrates the type of con