US7730415B2 - State machine function block with a user modifiable state transition configuration database - Google Patents

Abstract

A control system, a safety system, etc., within a process plant may each use one or more state machine function blocks that can be easily integrated into a function block diagram programming environment. Such a state machine function block may include one or more inputs, which may cause a state machine implemented by the state machine function block to change states. The state machine function block may determine a next state to which it is to transition based, at least in part, on data indicative of the next state to which to transition, if any. The configuration data may be retrieved from a database based on the current state of the state machine and at least one of the inputs. The state machine function block may also include one or more outputs that are generated based on the state of the state machine.

Description

CROSS REFERENCES TO RELATED APPLICATIONS

The present application is related to U.S. patent application Ser. No. 10/655,929, entitled “STATE MACHINE FUNCTION BLOCK WITH A USER MODIFIABLE OUTPUT CONFIGURATION DATABASE,” which is commonly-owned, and which is hereby incorporated by reference herein in its entirety for all purposes.

FIELD OF THE DISCLOSURE

The present disclosure generally relates to function blocks for use in process plants, and more particularly to configuring and implementing a state machine associated with a process plant.

BACKGROUND

Process control systems, like those used in chemical, petroleum or other processes, typically include one or more process controllers communicatively coupled to at least one host or operator workstation and to one or more field devices via analog, digital or combined analog/digital buses or lines. The field devices, which may be, for example valves, valve positioners, switches and transmitters (e.g., temperature, pressure and flow rate sensors), perform functions within the process plant such as opening or closing valves and measuring process parameters. The process controllers receive signals indicative of process measurements made by the field devices and/or other information pertaining to the field devices, use this information to implement control routines and then generate control signals which are sent over the buses or lines to the field devices to control the operation of the process. Information from the field devices and the controllers is typically made available to one or more applications executed by the operator workstation to enable an operator to perform any desired function with respect to the process, such as configuring the process, viewing the current state of the process, modifying the operation of the process, etc.

Additionally, in many processes, a separate safety system is provided to detect significant safety related problems within the process plant and to automatically close valves, remove power from devices, switch flows within the plant, etc., when a problem occurs which might result in or lead to a serious hazard in the plant, such as a spill of toxic chemicals, an explosion, etc. These safety systems typically have one or more separate controllers apart from the standard process control controllers, called logic solvers, which are connected to safety field devices via separate buses or communication lines installed within the process plant. The logic solvers use the safety field devices to detect process conditions associated with significant events, such as the position of certain safety switches or shutdown valves, overflows or underflows in the process, the operation of important power generation or control devices, the operation of fault detection devices, etc. to thereby detect “events” within the process plant. When an event (typically called a “cause”) is detected, the safety controller takes some action (typically called an “effect”) to limit the detrimental nature of the event, such as closing valves, turning devices off, removing power from sections of the plant, etc. Generally, these actions or effects include switching safety devices into a tripped or “safe” mode of operation which is designed to prevent a serious or hazardous condition within the process plant.

Systems within a process plant, such as process control systems and safety systems, typically may keep track statuses of various processes and/or the systems themselves. Input signals to a system may cause the status tracked by the system to change, and output signals generated by the system may depend on the current status of the system in addition to input signals to the system. Currently, the status of a system may be tracked using routines written in a programming language. Writing such routines can be tedious, time consuming and fraught with errors. In safety systems, such errors can be serious because a failure of the safety system to operate properly can lead to serious injury or even death on the part of plant personnel and to the destruction of potentially millions of dollars of equipment and material within a plant.

Also, the status of a system can be tracked using a programming technique for programmable controllers standardized by the International Electrotechnical Commission (IEC), commonly referred to as a “sequential function chart” (set forth in the IEC 61131-3 standard). But as is known to those of ordinary skill in the art, using a sequential function chart to keep track of the status of a system can be difficult. Additionally, similar to the routines written in a programming language, creating a sequential function chart can be tedious, time consuming and fraught with errors.

SUMMARY

A control system, a safety system, etc., within a process plant may each use one or more state machine function blocks that can be easily integrated into a function block diagram programming environment. Such a state machine function block may include one or more inputs, which may be used to cause a state machine implemented by the state machine function block to change states. The state machine function block may determine a next state to which it is to transition based on state transition configuration data indicative of the next state, if any. The state transition configuration data may be retrieved from a database based on the current state of the state machine and at least one of the inputs. The state machine function block may also include one or more outputs that are generated based on the state of the state machine. The inputs of the state machine function block may be associated with, for example, a process control system or a safety system, and the outputs may be used, for example, for control of field devices in the process control system or the safety system.

The state machine function block may be configured, at least in part, via a graphical user interface mechanism. The graphical user interface mechanism may include a plurality of graphical elements, wherein at least some of the graphical elements can be used to specify how the state machine should transition between states. In one example, a plurality of cells may be displayed on a display device of a computer, wherein each cell of the first plurality of cells corresponds to one of at least some possible pairings of ones of the at least one input and ones of the states of the plurality of states of the state machine. The plurality of the cells may be arranged in a matrix, for example, where columns of the matrix correspond to the plurality of possible states of the state machine, and rows of the matrix corresponds to inputs to the state machine (or vice versa). In a cell corresponding to a particular state and a particular input, a programmer may enter configuration data indicative of a next state using an input device of the computer. The next state configuration data is indicative of the next state to which the state machine should transition when the state machine is in the state corresponding to the cell and when the input corresponding to the cell is a particular value.

As another example, the graphical user interface may comprise a diagram where objects on the diagram represent states of the state machine. A programmer may, for example, place an arrow from one state to another state and also associate an input with the arrow. This may indicate that the state machine should transfer from the one state to the another state when the specified input is a particular value.

Embodiments of state machine function blocks as claimed herein may be easier to configure as compared to prior art techniques of keeping track of a status related to a control system or a safety system. For instance, some or all of the configuration may be accomplished using a graphical user interface mechanism such as the mechanism described above. Additionally, embodiments of state machine function blocks may be easy to integrate into a controller, a logic solver, field devices, etc., which use function block logic because the state machine function block can be integrated in the same or similar manner as other types of function blocks by interconnecting inputs and outputs of the state machine function block to other functions blocks, elements within a control strategy, an operator interface, etc. Further, the operation of the state machine function may be easily documented because its operation may be illustrated, at least in part, graphically such as in a matrix form. Different embodiments of state machine function blocks or mechanisms for configuring state machine function blocks may provide one or more, or none of the above-described advantages.

BRIEF DESCRIPTION OF THE DRAWINGS

The features and advantages of the methods, apparatus, and systems described herein will be best appreciated upon reference to the following detailed description and the accompanying drawings, in which:

FIG. 1 is a block diagram of an example process plant;

FIG. 2 is a block diagram of an example workstation schematically illustrated inFIG. 1;

FIG. 3 is an example of a display that depicts a control module;

FIG. 4 is an example of a representation of a state machine function block;

FIG. 5 is an example matrix for entering next state configuration data for a state machine function block;

FIG. 6 is the example matrix ofFIG. 5 in which next state configuration data is displayed in the matrix;

FIG. 7 is a flow diagram of an example method of operation of a state machine function block;

FIG. 8 is a block diagram of an example state machine function block;

FIG. 9 is a flow diagram of another example method of operation of a state machine function block;

FIG. 10 is a flow diagram of an example routine for processing data inputs to a state machine function block;

FIG. 11 is a flow diagram of an example routine for processing an enable input to a state machine function block;

FIG. 12 is a flow diagram of an example routine for changing a state and setting outputs of a state machine function block;

FIG. 13 is an example matrix for entering output configuration data for a state machine function block;

FIG. 14 is a block diagram of another example state machine function block;

FIG. 15 is a flow diagram of another example routine for changing a state and setting outputs of a state machine function block;

FIG. 16 is a flow diagram of an example routine for setting appropriate output values of a state machine function block; and

FIG. 17 is an example state transition diagram for entering next state configuration data for a state machine function block.

DETAILED DESCRIPTION

Process Plant Example

FIG. 1 is a block diagram of anexample process plant10 that includes one ormore nodes12,16,18 and20. In theexample process plant10 ofFIG. 1, each of thenodes12 and16 includes aprocess controller12a,16aconnected to one ormore field devices22 and23 via input/output (I/O)devices24 which may be, for example, Foundation Fieldbus interfaces, HART interfaces, etc. Thecontrollers12aand16aare also coupled to one or more host oroperator workstations18aand20ain thenodes18 and20 via anetwork30 which may comprise, for example, one or more of a bus, a wired local area network (LAN) such as an Ethernet LAN, a wireless LAN, a wide area network (WAN), an intranet, etc. While thecontroller nodes12,16 and the I/O devices24 andfield devices22,23 associated therewith are typically located down within and distributed throughout the sometimes harsh plant environment, theoperator workstation nodes18 and20 are usually located in control rooms or other less harsh environments easily assessable by controller personnel.

Generally speaking, theworkstations18aand20aof thenodes18 and20 may be used to store and execute applications used to configure and monitor theprocess plant10, and/or to managedevices22,23,24 andcontrollers12a,16ain theprocess plant10. Further, adatabase32 may be connected to thenetwork30 and operate as a data historian and/or a configuration database that stores the current configuration of theprocess plant10 as downloaded to and/or stored within thenodes12,16,18,20,22,23,24,50, and70.

Each of thecontrollers12aand16a, which may be by way of example, the DeltaV™ controller sold by Emerson Process Management, may store and execute a controller application that implements a control strategy using a number of different, independently executed, control modules or blocks. The control modules may each be made up of what are commonly referred to as function blocks wherein each function block is a part or a subroutine of an overall control routine and operates in conjunction with other function blocks (via communications called links) to implement process control loops within theprocess plant10. As is well known, function blocks typically perform one of an input function (such as that associated with a transmitter, a sensor or other process parameter measurement device), a control function (such as that associated with a control routine that performs PID, fuzzy logic, etc. control), or an output function which controls the operation of some device (such as a valve), to perform some physical function within theprocess plant10. Of course hybrid and other types of function blocks exist and may be utilized. While a fieldbus protocol and the DeltaV™ system protocol may use control modules and function blocks designed and implemented in an object oriented programming protocol, the control modules could be designed using any desired control programming scheme including, for example, sequential function block, ladder logic, etc. and are not limited to being designed using function block or any other particular programming technique. As is typical, the configuration of the control modules as stored within theprocess control nodes12 and16 may be stored in theconfiguration database32 which is accessible to applications executed by theworkstations18aand20a. Function blocks may be stored in and executed by, for example, thecontroller12a,16a, which is typically the case when these function blocks are used for, or are associated with standard 4-20 ma devices and some types of smart field devices such as HART devices, or may be stored in and implemented by the field devices themselves, which can be the case with Fieldbus devices.

In the system illustrated inFIG. 1, thefield devices22 and23 coupled to thecontrollers12aand16amay be standard 4-20 ma devices, or may be smart field devices, such as HART, Profibus, or Foundation Fieldbus field devices, which include a processor and a memory. Some of these devices, such as Foundation Fieldbus field devices (labeled withreference number23 inFIG. 1), may store and execute modules, or sub-modules, such as function blocks, associated with the control strategy implemented in thecontrollers12aand16a. Of course, thefield devices22,23 may be any types of devices, such as sensors, valves, transmitters, positioners, etc. and the I/O devices24 may be any types of I/O devices conforming to any desired communication or controller protocol such as HART, Foundation Fieldbus, Profibus, etc.

Thecontrollers12aand16aeach include a processor that implements or oversees one or more process control routines, stored in a memory, which may include control loops, stored therein or otherwise associated therewith. Thecontrollers12aand16acommunicate with thefield devices22,23, theworkstations18a,20aand thedatabase32 to control a process in any desired manner. Thecontrollers12aand16aeach may be configured to implement a control strategy or control routine in any desired manner.

Theprocess plant10 may also include a safety system14 (indicated by dotted lines) integrated with theprocess control nodes12 and16. Thesafety system14 generally may operate as a Safety Instrumented System (SIS) to monitor and override the control provided by theprocess control nodes12 and16 to maximize the likely safe operation of theprocess plant10.

Each of thenodes12 and16 may include one or more safetysystem logic solvers50. Each of thelogic solvers50 is an I/O device having a processor and a memory, and is configured to execute safety logic modules stored in the memory. Eachlogic solver50 is communicatively coupled to provide control signals to and/or receive signals from safetysystem field devices60 and62. Additionally, each of thenodes12 and16 includes at least one message propagation device (MPD)70, which is communicatively coupled toother MPDs70 via a ring or bus connection74 (only part of which is illustrated inFIG. 1). The safetysystem logic solvers50, the safetysystem field devices60 and62, theMPDs70, and thebus74 generally make up thesafety system14 ofFIG. 1.

Thelogic solvers50 ofFIG. 1 may be any desired type of safety system control devices that include a processor and a memory that stores safety logic modules adapted to be executed on the processor to provide control functionality associated with thesafety system14 using thefield devices60 and62. Of course, thesafety field devices60 and62 may be any desired type of field devices conforming or using any known or desired communication protocol, such as those mentioned above. In particular, thefield devices60 and62 may be safety-related field devices of the type that are conventionally controlled by a separate, dedicated safety-related control system. In theprocess plant10 illustrated inFIG. 1, thesafety field devices60 are depicted as using a dedicated or point-to-point communication protocol, such as the HART or the 4-20 ma protocol, while thesafety field devices62 are illustrated as using a bus communication protocol, such as a Fieldbus protocol. Thesafety field devices60 may perform any desired function, such as that of a shut-down valve, a shut-off switch, etc.

A common backplane (not shown) may be used in each of thenodes12 and16 to communicatively couple thecontrollers12aand16ato the process control I/O cards24, to thesafety logic solvers50, and to theMPDs70. Thecontrollers12aand16aare also communicatively coupled to thenetwork30. Thecontrollers12aand16a, the I/O devices24, thelogic solvers50, theMPDs70 may communicate with thenodes18 and20 via thenetwork30.

As will be understood by those of ordinary skill in the art, the backplane (not shown) in thenode12,16 enables thelogic solvers50 to communicate locally with one another to coordinate safety functions implemented by these devices, to communicate data to one another, and/or to perform other integrated functions. Similarly, the backplane (not shown) in thenode16 enables thelogic solvers50 to communicate locally with one another to coordinate safety functions implemented by these devices, to communicate data to one another, and/or to perform other integrated functions. On the other hand, theMPDs70 operate to enable portions of thesafety system14 that are disposed in vastly different locations of theplant10 to still communicate with one another to provide coordinated safety operation at different nodes of theprocess plant10. In particular, theMPDs70 in conjunction with thebus74 enable thelogic solvers50 associated withdifferent nodes12 and16 of theprocess plant10 to be communicatively cascaded together to allow for the cascading of safety-related functions within theprocess plant10 according to an assigned priority. TheMPDs70 and thebus74 provide the safety system with a communication link that is an alternative to thenetwork30.

Alternatively, two or more safety-related functions at different locations within theprocess plant10 may be interlocked or interconnected without having to run a dedicated line to individual safety field devices within the separate areas or node of theplant10. In other words, the use of theMPDs70 and72 and thebus74 enables a safety engineer to design and configure asafety system14 that is distributed in nature throughout theprocess plant10 but that has different components thereof communicatively interconnected to enable the disparate safety related hardware to communicate with each other as required. This feature also provides scalability of thesafety system14 in that it enables additional safety logic solvers to be added to thesafety system14 as they are needed or as new process control nodes are added to theprocess plant10.

FIG. 2 is a block diagram of anexample workstation18a(workstation20amay comprise the same or similar device). Theworkstation18amay include at least oneprocessor100, avolatile memory104, and anon-volatile memory108. Thevolatile memory104 may include, for example, a random access memory (RAM). In some embodiments, the RAM may be backed up by one or more batteries so that data is not lost in the event of a power failure. Thenon-volatile memory108 may include, for example, one or more of a hard disk, a read-only memory (ROM), a compact disk ROM (CD-ROM), a programmable ROM (PROM), an erasable programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), a digital versatile disk (DVD), a flash memory, etc. Theworkstation18amay also include a workstation I/O device112. Theprocessor100,volatile memory104,non-volatile memory108, and workstation I/O device112 may be interconnected via an address/data bus116. Theworkstation18amay also include at least onedisplay device120 and at least oneuser input device124, which may be, for example, one or more of a keyboard, a keypad, a mouse, a track ball, a touch screen, a light pen, etc. In some embodiments, one or more of thevolatile memory104,non-volatile memory108, and workstation I/O device112 may be coupled to theprocessor100 via a bus separate from the address/data bus116 (not shown), or may be coupled directly to theprocessor100.

Thedisplay device120 and theuser input device124 are coupled with the workstation I/O device112. Additionally, theworkstation18ais coupled to thenetwork30 via the workstation I/O device112. Although the workstation I/O device112 is illustrated inFIG. 2 as one device, it may comprise several devices. Additionally, in some embodiments, one or more of thedisplay device120 and theuser input device124 may be coupled directly to the address/data bus116 or to theprocessor100.

Referring now toFIGS. 1 and 2, a process control configuration application associated with one or more of thecontrol nodes12,16 may be stored on and executed by one or more ofworkstations18aand20a. For example, the process control configuration application could be stored on thenon-volatile memory108 and/or thevolatile memory104, and executed by theprocessor100. However, if desired, this application could be stored and executed in other computers associated with theprocess plant10. Generally speaking, the process control configuration application permits a programmer to create and configure control routines, control modules, function blocks, programs, logic, etc., to be implemented by thecontrollers12a,16a, I/O devices24, and/or thefield devices22,23. These control routines, control modules, function blocks, programs, logic, etc., may then be downloaded to appropriate ones of thecontrollers12a,16a, I/O devices24, and/orfield devices22,23 via thenetwork30.

Similarly, a safety system configuration application associated with thesafety system14 may be stored on and executed by one or more ofworkstations18aand20a. For example, the safety system configuration application could be stored on thenon-volatile memory108 and/or thevolatile memory104, and executed by theprocessor100. However, if desired, this application could be stored and executed in other computers associated with theprocess plant10. Generally speaking, the safety system configuration application permits a programmer to create and configure control routines, control modules, function blocks, programs, logic, etc., to be implemented by thecontrollers12a,16a, thelogic solvers50, and/or thedevices60,62. These control routines, control modules, function blocks, programs, logic, etc., may then be downloaded to appropriate ones of thecontrollers12a,16a, thelogic solvers50, and/or thedevices60,62 via thenetwork30.

State Machine Function Block

A control system or safety system configuration application may permit programming control modules and/or control routines using a function block programming paradigm.FIG. 3 illustrates one example of adisplay150 depicting acontrol module154. Thedisplay150 may be part of a user interface associated with the configuration application, and thedisplay150 may be presented to a programmer, for example, via thedisplay device120 of theworkstation18a. Thedisplay150 depicts thecontrol module154 having a set of communicatively interconnected function blocks that can be created and downloaded to appropriate ones of thecontrollers12a,16a, I/O devices24,logic solvers50, and/ordevices22,23,60,62 via thenetwork30 for implementation during operation of a process plant. As illustrated inFIG. 3, thecontrol module154 includes a state machine function block (SMFB)160, a plurality of analog input (AI) and digital input (DI) function blocks, a plurality of analog output (AO) and digital output (DO) function blocks, and other function blocks (FBs). TheSMFB160 has inputs communicatively interconnected withfunction blocks114, which may be, for example, DI function blocks or other FBs. TheSMFB160 also has outputs connected to functionblocks118 which may be, for example, DO function blocks or other FBs. Thecontrol module154 may control, or may be one of a plurality of control modules that together control, devices such as switches, valves, etc., as part of a control system, safety system, etc. Of course,control module154 is just one example of a control module that employs SMFBs. In general, a control module may be programmed in any desired manner to include any types of function blocks communicatively coupled with any number of SMFBs in any desired manner, and configured in any desired or useful manner to perform any desired functionality. If used in, for example, a Fieldbus network, a control module may include any fieldbus type function blocks.

In some embodiments, one or more of the inputs to theSMFB160 may be received from other than a function block. For example, one or more of the inputs to theSMFB160 may be communicatively coupled to receive inputs from an operator via, for example, an operator interface. For example, an operator, using an operator interface implemented on a node such asnode18 or20, could provide inputs to theSMFB160.

The SMFB may be a function block that implements a state machine. In some embodiments, a state machine may include an entity (e.g., a device, software implemented by a processor, etc.) that can be in one of a plurality of states. The state machine may transition from one state to another state if a particular input to the state machine occurs. The SMFB may provide outputs that are based on the current state of the state machine. As just one example, the SMFB may provide one or more outputs that indicate the current state of the state machine. More generally, a state machine may include an entity (e.g., a device, software implemented by a processor, etc.) that stores a status of the entity, or some other entity (e.g., a process plant, a sub-part of a process plant, a component of a process plant, etc.), at a given time, and that may change the status and/or cause an action or output to take place based on inputs to the state machine.

Using the user interface associated with the configuration application, the programmer may design a control module such as thecontrol module154. As just one example, the user interface may provide a mechanism for a programmer to select desired function blocks from, for example, a stencil or palette that includes a plurality of standard or customized function block stencils. Additionally, the user interface may provide a graphical diagram onto which the programmer may insert or place depictions of function blocks. The programmer may use, for example, a mouse, a track ball, a keyboard, a key pad, a touch screen, etc., to select a function block from the stencil or palette, and then “drag and drop” the function block onto the graphical diagram. The programmer may additionally communicatively couple function blocks by, for example, drawing a line between an output of one function block and an input of another function block using, for example, a mouse, a track ball, a keyboard, a key pad, a touch screen, etc.

Once configured, thecontrol module154 may be implemented, for example, by one or more of thecontrollers12a,14a,16a, I/O devices24,logic solvers50, anddevices22,23,60,62.

FIG. 4 is one example of a representation of aSMFB200 which may be displayed, for example, on a user interface display such as thedisplay150 ofFIG. 3. The representation of theSMFB200 indicates that theSMFB200 includes seven data inputs (IN_D1 through IN_D7) and seven data outputs (STATE and OUT_D1 through OUT_D6). The data inputs generally may be indicative of conditions within the process plant, indicative of operator commands, etc., and that may cause a state machine implemented by aSMFB200 to change states. The data outputs may include one or more indicators of the state of the state machine corresponding to theSMFB200. For example, the STATE output may be an indicator of the state (e.g.,state1,state2,state3, etc.) of the state machine. The output OUT_D1 may be an indicator of whether the state machine is at a state “state1.” Similarly, the outputs OUT_D2, OUT_D3, . . . OUT_D6 may be indicators of whether the state machine is at states “state2”, “state3,” . . . , “state6”, respectively. The SMFB may also include other inputs besides data inputs, such as an ENABLE input, a TRK_VAL input, and a TRK_IN_D input, and may include other outputs besides outputs indicative of the state. The ENABLE, TRK_VAL, and TRK_IN_D inputs will be described in more detail below. Although theSMFB200 is shown inFIG. 4 to have seven data inputs and seven data outputs, other embodiments may include any desired number of data inputs and data outputs. The number of data inputs and the number of data outputs of theSMFB200 may or may not be configurable. In one embodiment, the number of outputs OUT_Dx generally corresponds to the number of possible states of the state machine implemented by the SMFB, and the number of possible states may be configurable. The number of outputs OUT_D1, OUT_D2, etc., however, need not correspond to the number of possible states of the state machine. For example, if there are fewer states than the number of outputs OUT_D1, OUT_D2, etc., the extra outputs can be left unused.

Using the user interface associated with the configuration program, the programmer may configure one or more function blocks such as theSMFB200. With regard to configuring the SMFB, the programmer may specify a number of possible states, and how the inputs cause the state machine to transition between states. To allow a programmer to configure the SMFB, a configuration application may display on the display device120 a user interface mechanism, such as a configuration window, screen, etc., associated with the function block.

FIG. 5 is one example of a user interface mechanism that may be used to configure, at least in part, a SMFB, such as theSMFB200 ofFIG. 4. The user interface mechanism comprises a table or matrix300 (hereinafter referred to as the “matrix 300”) that may be displayed as part of a configuration window, screen, etc., associated with the SMFB. Thematrix300 comprises a plurality ofcells304 arranged in rows and columns. Each column corresponds to one of a plurality of possible states of the state machine, and each row corresponds to an input to the state machine. Thus, eachcell304 corresponds to a state and an input. Although theexample matrix300 includes rows for seven inputs and six states, similar matrices having different numbers of states and outputs may be used for SMFBs having different numbers of inputs and states. The number of inputs and states may be configurable. In other examples, each row may correspond to one of a plurality of possible states of the state machine, and each column may correspond to an input to the state machine.

Referring toFIG. 4, the inputs “1” through “7” ofmatrix300 correspond to the inputs IN_D1 through IN_D7 of theSMFB200, respectively. Similarly, the states “1” through “6” ofmatrix300 correspond to the outputs OUT_D1 through OUT_D6 of theSMFB200, respectively. Additionally, in this example a programmer may be able to label each possible state and/or each of the inputs. For example, inFIG. 5 “state1” is labeled “TRIPPED,” andinput1 is labeled “INITIAL”. Labeling inputs and/or states may help facilitate understanding the operation of the state machine.

A programmer may configure the SMFB by entering configuration information into thecells304. In particular, for aparticular cell304 that corresponds to one of the states and one of the inputs, the programmer can enter configuration data into the cell that indicates the state to which the SMFB should transition.FIG. 6 is an example of thematrix300 having configuration data entered into some of thecells304. For example, thecell304A includes configuration data indicative of the next state to the state machine should transition when the state machine is in the “TRIPPED” state and when the “INITIAL” input is asserted. In particular, the configuration data ofcell304A indicates that the state machine should transition to the “WAITING FOR RESET” state. Similarly,cell304B includes configuration data that indicates when the state machine is in the “WAITING FOR RESET” state and when the “RESET PERMIT” input is asserted, the state machine should transition to the “READY FOR RESET” state. Also,cell304C includes configuration data that indicates when the state machine is in the “WAITING FOR RESET” state and when the “TRIP REQUESTED” input is asserted, the state machine should transition to the “TRIPPED” state.

In this particular example, if the programmer does not enter configuration data into acell304, it may be assumed that for that particular state and input, a state transition should not occur. For example,cell304D does not include configuration data, indicating that when the state machine is in the “TRIPPED” state and when the “START RECOVER” input is asserted, the state machine should remain in the “TRIPPED” state. In other embodiments, the programmer may enter configuration data that indicates that the state machine should not change states for that particular state/input combination.

The programmer may enter configuration data into thematrix300 using any of a variety of techniques, including techniques well known to those of ordinary skill in the art. For example, to enter configuration data into acell304, the programmer may select thecell304 using a mouse, track ball, touch screen, etc. Then, the user could enter configuration data directly into thecell304 via, for example, a keyboard. Alternatively, the programmer could select thecell304 and then select an “edit,” a “modify,” etc., selection from a pull down menu, or select an “edit” button, a “modify” button, etc. Then, the user interface may display to the programmer a list of states via a pull down menu, window, display screen, etc. Optionally, the list of states may include the state to which the cell corresponds or a “NO TRANSITION” selection. Next, the programmer may select one of the states using, for example, a keyboard, a mouse, a trackball, a touch screen, etc. If the programmer selects the state to which the cell corresponds or the “NO TRANSITION” selection, the configuration data would indicate that for the state and input combination, no transition should occur.

Configuring the SMFB using a user interface that includes a matrix such as thematrix300 may make implementing a state machine easier as compared to using, for example, a sequential function chart or a programming language such as C++. For instance, implementing a state machine using a C++ program likely would involve first creating a state transition diagram and then writing a program to implement the diagram. The, the program would have to be tested and debugged. With a SMFB configured using matrix such as thematrix300, however, no writing of a program is required. Rather, “programming” would simply involve filling in the matrix. Additionally, because no software code need be written, debugging and testing of the code is not needed. Rather, testing may simply involve testing the various combinations of states and inputs to verify that the SMFB goes to the correct next states.

Further, the functioning of the SMFB can be easily understood by simply examining thematrix300. Thus, the functioning of a configured SMFB could easily be documented by, for example, printing out a representation of the matrix.

A SMFB configured according to a matrix such as thematrix300 can be used in a safety system or a process control system, for example. As just one example, SMFB configured according to a matrix such as thematrix300 can be used, as part of a safety system, for managing a burner in a process plant. For instance, the SMFB could include states such as “IGNITE”, “SHUT OFF GAS”, and “VENT”. When starting up the burner, the SMFB could first go to the VENT state to cause any gas in the burner to be vented. Then, the SMFB could go to the IGNITE state to ignite the burner. Also, if the flame of the burner goes out, the SMFB could go to the SHUT OFF GAS state to shut off gas to the burner. Then, the SMFB could go to the VENT state.

A SMFB configured according to a matrix such as thematrix300 can be implemented by one or more of thecontrollers12a,16a, I/O devices24,logic solvers50, anddevices22,23,60,62. In some embodiments, the SMFB, may be implemented by a processor configured according to software, by a programmable logic device, e.g., a device including one or more of a gate array, a standard cell, a field programmable gate array (FPGA), a PROM, an EPROM, an EEPROM, a programmable array logic (PAL), a programmable logic array (PLA), etc.

The configuration data associated with a SMFB (for example, data entered into a matrix such as thematrix300 and, optionally, other configuration data) may be stored on a computer readable medium such as a hard disk, a RAM, a ROM, a CD-ROM, an EPROM, an EEPROM, a DVD, a FLASH memory, etc., and/or a memory associated with a processor.

FIG. 7 is a flow diagram of an example method of operation of a configured SMFB. Themethod350 may be implemented periodically and/or in response to a triggering event, for example. At ablock354, the SMFB receives its data inputs. Referring toFIG. 4 for example, the SMFB receives inputs IN_D1 through IN_D7. At ablock358, the SMFB changes a state of its state machine, if necessary, based on the data inputs, the current state of the SMFB, and configuration data stored in a configuration database. The data of the configuration database may include data entered via a matrix such as thematrix300. The state may be changed based on other factors as well. For example, as will be described in more detail below, the SMFB may be configured to ignore one or more of the data inputs. Thus, changing the state may also be based on configuration data that indicates which, if any, of the data inputs are to be ignored. As another example, two or more data inputs may indicate a state change should occur from a current state to two or more next states. Thus, the SMFB may select one of the data inputs to determine to which of the possible next states the SMFB should transition based on priority data that prioritizes the data inputs. As yet another example, in some embodiments inputs to the SMFB may include a status (e.g., GOOD status or BAD status). Thus, changing the state may also be based on, for example, configuration data that indicates how an input having a BAD status should be handled.

Then, at ablock366, the SMFB may set its data outputs based on the current state of the state machine. For example, if the data outputs are to be indicative of the current state, then the data outputs may be set accordingly.

Referring again toFIG. 4, the SMFB may optionally include an “ENABLE” input. In one embodiment, if the ENABLE input is deasserted, the SMFB may be forced into a disabled state (e.g., state0) and should remain in that state until the ENABLE input is asserted. When the ENABLE input is then asserted, the SMFB may be forced into an initial state (e.g., state1), after which the SMFB may transition to other states according to the configuration data entered into a configuration matrix such as thematrix300 ofFIG. 5.

The SMFB may additionally include an input or inputs to force the state machine into a desired state. For example, theSMFB200 includes a TRK_IN_D input and a TRK_VAL input. When the TRK_IN_D input is asserted, the SMFB may be forced into a state specified by the TRK_VAL input. For example, if the TRK_VAL input is “6” and the TRK_IN_D input is asserted, the SMFB may be forced into the state “6.”

The SMFB may optionally be configured in additional ways. For example, the SMFB may include an input (or transition) mask that indicates whether one or more, if any, of the inputs IN_D1, IN_D2, etc., should be ignored. Also, the SMFB may be configured to respond to inputs that may have a plurality of statuses. For instance, one or all of the inputs to the SMFB may have a “good” status or a “bad” status, and the SMFB may be configured to respond differently depending on the status of an input. In one particular example, the SMFB may be configured to ignore an input that is “bad,” use the input even if it is “bad,” or use the last “good” value of the input. Further, the SMFB may include a RESET parameter that, when true, forces the SMFB into the “1” state.

The various configuration data described above and the next state configuration data can be stored on the same computer readable medium or on different computer readable media.

FIG. 8 is a block diagram of one example of a SMFB. TheSMFB400 includeslogic404 that determines a next state based, at least in part, on the inputs IN_D1, IN_D2, etc., and the current state of theSMFB400. In particular, thelogic404 accesses next state configuration data stored in a nextstate configuration database406. Thedatabase406 may be stored on a computer readable medium such as described above. The next state configuration data may comprise configuration data entered into a matrix such as thematrix300 ofFIG. 5.

The output of thelogic404 is provided to switchinglogic408. The switchinglogic408 selects between the output of thelogic404 and the input TRK_VAL based on the TRK_IN_D input. For example, if the TRK_IN_D input is asserted, the switchinglogic408 may select the TRK_VAL input. Otherwise, the switchinglogic408 may select the output of thelogic404.

The output of the switchinglogic408 is provided to switchinglogic412, which selects between the output of the switchinglogic408, thevalue0 and thevalue1 based on the output of enable and resetlogic416. The output of the enable and resetlogic416 is indicative of whether the state should be forced into a disabled state (state0) or an initial state (state1). The enable and resetlogic416 generates this output based on the ENABLE input. For example, if the ENABLE input is deasserted, the output of the enable and resetlogic416 may indicate that the state should be forced to 0. If the ENABLE input changes from deasserted to asserted, the output of the enable and resetlogic416 may indicate that the state should be forced to 1. If the ENABLE is asserted and was previously asserted, the output of the enable and resetlogic416 may indicate that the state should not be forced to 0 or 1.

The output of the switchinglogic412 is the current state of theSMFB400, and may be provided as an output of theSMFB400. The output of the switchinglogic412 may also be provided tologic420 that sets an appropriate output OUT_D1, OUT_D2, etc., that corresponds to the current state of the SMFB.

Each of theblocks404,408,412,416, and420 may be implemented by one or more of hardware, software, and firmware. Additionally, some of the blocks may be combined, reordered, modified, or omitted, and additional blocks may be added. As merely one example blocks408 and412 could be combined into a single block.

FIG. 9 is a flow diagram of a method of operation of theexample SMFB400. Themethod450 ofFIG. 9 may be implemented, for example, periodically and/or upon a triggering event. At ablock454, the data inputs of theSMFB400 are processed. For example, it may be determined if any of the data inputs IN_D1, IN_D2, etc., has been asserted. As another example, if one or more of the data inputs has a “BAD” status, it may be determined how to handle the “BAD” input(s). At ablock458, the ENABLE input of theSMFB400 is processed. For example, it may be determined whether the ENABLE input is asserted and/or whether it has changed since it was previously processed.

At ablock462, a state of theSMFB400 may be changed, if necessary. Additionally, one or more data outputs of theSMFB400 may be changed, if necessary. For example, it may be determined that a change in the data inputs indicates that the state of theSMFB400 should be changed. Additionally, if the state changes, it may be that one or more data outputs of theSMFB400 should be changed.

Several example routines that may be used to implement themethod450, at least in part, will now be described. For instance,FIG. 10 is a flow diagram of anexample routine500 that may be used to process the data inputs IN_D1, IN_D2. etc., to the SMFB. At ablock504, a variable z is set to one. At ablock508, it is determined whether the status of the data input IN_Dz is “BAD”? If the status is not bad, then bit number z of a variable TRANSITIONS is set to the value of the data input IN_Dz. If the status is bad, then it may be determined how the data input is to be handled. In one example, the SMFB may handle “BAD” inputs in one of three ways: the BAD input may be used anyway (ALWAYS_USE), it may be ignored (IGNORE_IF_BAD), or the last “GOOD” input value may be used (USE_LAST_GOOD). Thus, at ablock516, it may be determined if the SMFB is to use the last “GOOD” data input. If the SMFB is to use the last “GOOD” value, then theblock512 may be skipped. Otherwise, it may then be determined atblock520 if the SMFB is to ignore the BAD input value. If the SMFB is not to ignore the BAD value, then the routine may proceed to theblock512. If the SMFB is to ignore the BAD value, then the routine may proceed to ablock524. At theblock524, bit number “x” of the variable TRANSITIONS is set to 0.

At ablock528, the variable z is incremented, and at ablock532, it may be determined if the variable z is greater than the number of data inputs to the SMFB. If z is not greater than the number of data inputs to the SMFB, the routine may proceed back to theblock508 to process the next data input. Otherwise, the routine may end.

FIG. 11 is a flow diagram of anexample routine545 that may be used to process the ENABLE input to the SMFB. At ablock550, it may be determined whether a value of a variable LASTENABLE is the same as the value of the ENABLE input. The LASTENABLE variable is generally indicative of the value of the ENABLE at a previous time (for example, the value of the ENABLE variable during the previous running of the routine545). If the values of LASTENABLE and ENABLE are the same, the routine545 may end. Otherwise, the routine may proceed to ablock554 at which it may be determined if the ENABLE input is asserted. If the ENABLE input is asserted, then at a block558 a variable RESET may be set to TRUE.

If at theblock554 it is determined that the ENABLE input is not asserted, then atblock562, the output OUT_D1, OUT_D2, etc., corresponding to the current value of a STATE variable is deasserted. Then, at ablock566, the STATE variable is set to 0. After theblocks558 and566, the routine may proceed to ablock570, at which the variable LASTENABLE is set to the value of the ENABLE input. After theblock570, the routine may end.

FIG. 12 is a flow diagram of anexample routine600 that may be used to determine a next state of the SMFB and to set an appropriate output OUT_D1, OUT_D2, etc., if necessary. At ablock604, it may be determined if the ENABLE input is asserted. If it is not, the routine may end. If the ENABLE input is asserted, the routine may proceed to ablock608 at which a variable NEWSTATE is set to 0. Next, at ablock612, it may be determined if the input TRK_IN_D is asserted. If it is asserted, the routine may proceed to ablock616 at which the NEWSTATE variable is set to the value of the input TRK_VAL.

If is determined at theblock612 that the TRK_IN_D input is not asserted, the routine may proceed to ablock620. At theblock620, it may be determined if the variable RESET is TRUE. If it is, the routine may proceed to ablock624 at which the NEWSTATE variable may be set to 1. Then, at ablock626, the RESET variable may be set to FALSE.

If it determined at theblock620 that the variable RESET is not TRUE, then the routine may proceed to ablock632. At theblock632, a variable TEMP may be determined by bitwise ANDing a TRANSITION_MASK variable, the TRANSITIONS variable, and an element of an array STATECHANGEMASK pointed to by the variable STATE. The TRANSITION_MASK variable may be a configurable variable that can be used to prevent certain inputs IN_Dx from causing a state change to occur. For example, if a programmer wished to prevent the input IN_D3 from causing the state machine to change state, the programmer could set the third bit of the variable TRANSITION_MASK to 0. If the programmer wished to allow the input D3 to cause the state machine to change state, the programmer could set the third bit of the variable TRANSITION_MASK to 1.

Each element of the STATECHANGEMASK array may be a variable that indicates, for a corresponding one of the states, which inputs IN_D1, IN_D2, etc., will cause a state change. In particular, each element of the array may correspond to one of the states of the state machine. For example, STATECHANGEMASK[1] may correspond tostate1, STATECHANGEMASK[2] may correspond tostate2, etc. Additionally, each bit of each element may correspond to one of the inputs IN_D1, IN_D2, etc. For instance,bit1 may correspond to IN_D1,bit2 may correspond to IN_D2, etc. Referring toFIG. 6 for example, for thematrix300 the STATECHANGEMASK array would have6 elements, and the element STATECHANGEMASK[3] would be 0×44.

After theblock628, the routine may proceed to ablock632 at which it may be determined if the variable TEMP is 0. If it is not 0, the routine may proceed to ablock636 at which a variable z may be set to the number of the first bit (i.e., starting from the least significant bit) in the variable TEMP that is not zero. In effect, this sets priorities of the inputs based on their order such that IN_D1 is the highest priority, IN_D2 is the next highest priority, IN_D3 is the next highest priority, etc. In other embodiments, other prioritization schemes could be used. For example, a programmer could be allowed to assign priorities to the inputs, or a different priority order could be used (e.g., IN_D1 is the lowest priority, IN_D2 is the next lowest priority, etc.). The priorities could be set for the SMFB as a whole or for each state.

Then, at ablock640, the variable NEWSTATE may be set to the value of the state transition matrix at row z and column STATE.

Afterblocks616,626, and640, the routine may proceed to ablock644. If at theblock632, it is determined that the variable TEMP is 0, the routine may also proceed to theblock644. At theblock644, it may be determined if the variable NEWSTATE is 0. If it is 0, the routine may end. If it is not 0, the routine may proceed to ablock648 at which the output OUT_D1, OUT_D2, etc., corresponding to the STATE variable is deasserted. Then, at ablock652, the variable STATE is set to the value of the variable NEWSTATE. At ablock656, the output OUT_D1, OUT_D2, etc., corresponding to the STATE variable is asserted, and the routine may end.

It is to be understood that themethod450 ofFIG. 9 and the routines ofFIGS. 10-12 are merely examples, and that in other examples, blocks may be modified, new blocks may be added, blocks may be reordered, blocks may be omitted, and/or blocks may be combined. Referring toFIG. 10, as just one example, theblocks508,516,520, and524 may be omitted if special handling of inputs having a “BAD” status is not needed or desired.

As another example, theblock636 could be modified so that the variable z is set to the number of the last bit in TEMP that is not 0. As yet another example, theblock636 could be modified to set z to the number corresponding to one of the bits in TEMP that is not 0 based on some priority data.

Referring again toFIG. 4, all of the data outputs need not be indicators of the state of the state machine corresponding to theSMFB200. For example, in one embodiment the values for the outputs OUT_D1, OUT_D2, etc., corresponding to various states of the state machine may be configurable. Thus, for example, for certain states a plurality of the outputs OUT_D1, OUT_D2, etc., may be asserted. To allow a programmer to configure the SMFB, a configuration application may display on the display device120 a user interface mechanism, such as a configuration window, screen, etc., associated with the function block.

FIG. 13 is one example of a user interface mechanism that may be used to configure, at least in part, a SMFB, such as theSMFB200 ofFIG. 4. The user interface mechanism comprises a table or matrix700 (hereinafter referred to as the “matrix700”) that may be displayed as part of a configuration window, screen, etc., associated with the SMFB. Thematrix700 comprises a plurality ofcells704 arranged in rows and columns. Each column corresponds to one of a plurality of outputs OUT_D1, OUT_D2, etc., of the state machine function block, and each row corresponds to one of the possible states of the state machine. Thus, eachcell704 corresponds to a state and an output. In other examples, each column may correspond to one of the plurality of outputs, and each column may correspond to one of the possible states of the state machine.

The outputs “1” through “4” ofmatrix700 may correspond to the outputs OUT_D1 through OUT_D4 of the SMFB, respectively. Similarly, the states “1” through “6” ofmatrix700 may correspond to the possible states of the state machine. Additionally, in this example a user may be able to label each of the outputs. For example, inFIG. 13 “output1” is labeled “OPEN VALVE VLV-101”. Labeling outputs may help facilitate understanding the operation of the state machine and/or interfacing the state machine with the process plant.

A programmer may configure the SMFB by entering configuration information into thecells704. In particular, for aparticular cell704 that corresponds to one of the states and one of the outputs, the programmer can enter configuration data into the cell that indicates that, when the state machine is in that state the output should be asserted. In theexample matrix700, configuration data has been entered into some of thecells704. For example, thecell704A includes configuration data that indicates that when the state machine is in the “TRIPPED” state the output OUT_D3 should be asserted. Similarly, thecell704B includes configuration data that indicates that when the state machine is in the “TRIPPED” state the output OUT_D4 should be asserted.

In this particular example, if the programmer does not enter configuration data into acell704, it may be assumed that for that particular state, the corresponding output should not be asserted. For example,cells704C and704D do not include X's, indicating that when the state machine is in the “TRIPPED” state the outputs OUT_D1 and OUT_D2 should not be asserted. In other embodiments, the programmer may enter configuration data that indicates that the state machine should not assert particular outputs if in a particular state. Similarly, it may be possible to indicate that for a particular state and output, it doesn't matter whether the output is asserted or not asserted.

The programmer may enter configuration data into thematrix700 using any of a variety of techniques, including techniques well known to those of ordinary skill in the art. For example, to enter configuration data into acell704, the programmer may select thecell704 using a mouse, track ball, touch screen, etc. Then, the user could enter configuration data directly into thecell704 via, for example, a keyboard. Alternatively, the programmer could select thecell704 and then select an “edit,” a “modify,” etc., selection from a pull down menu, or select an “edit” button, a “modify” button, etc. Then, the user interface may display to the programmer a list of selections via a pull down menu, window, display screen, etc. For example, the list of selections may include an “assert output” selection, a “deassert output” selection, and, optionally, a “don't care” selection. Next, the programmer may select one of the selections using, for example, a keyboard, a mouse, a trackball, a touch screen, etc. If the programmer selects the “assert output” selection, the configuration data may indicate that for the corresponding state, the corresponding output should be asserted. For example, an “X” may be displayed in the cell, a “1” may be displayed in the cell, the word “TRUE” may be displayed in the cell, the word “ASSERT” may be displayed in the cell, etc. If the programmer selects the “deassert output” selection, the configuration data may indicate that for the corresponding state, the corresponding output should not be asserted. For example, the cell may be left blank, a “0” may be displayed in the cell, the word “FALSE” may be displayed in the cell, the word “DEASSERT” may be displayed in the cell, etc.

Although theexample matrix700 includes rows for six states and four outputs, similar matrices having different numbers of states and outputs may be used for SMFBs having different numbers of states and outputs. The number of states and outputs may be configurable.

Referring again toFIG. 7, and as described previously, after the current state has been determined at the block362, the data outputs of the SMFB may be set based on the current state (block366). For example, the data outputs may be set according to configuration data entered into a matrix such as thematrix700 ofFIG. 13.FIG. 14 is a block diagram of another example of a SMFB. TheSMFB750 is similar to theSMFB400 ofFIG. 8, but includeslogic754 that sets appropriate outputs OUT_D1, OUT_D2, etc., based on the current state of the state machine. In particular, thelogic754 accesses state/output configuration data stored in anoutput configuration database758. Thedatabase758 and thedatabase406 may be stored on a same computer readable medium or on different computer readable media. The output configuration data may comprise configuration data entered into a matrix such as thematrix700 ofFIG. 13.

FIG. 15 is a flow diagram of anexample routine800 that may be used to determine a next state of an SMFB and to assert appropriate outputs OUT_D1, OUT_D2, etc., if necessary. The routine800 is similar to the routine600 ofFIG. 12. After theblock652, however, the flow proceeds to ablock804, at which appropriate outputs OUT_D1, OUT_D2, etc., maybe asserted.

FIG. 16 is a flow diagram of anexample routine850 that may be used to assert appropriate outputs OUT_D1, OUT_D2, etc. At ablock854, a variable z is set to one. At ablock858, the output OUT_Dz is set to the value of bit number z of an element of an array variable OUTPUT pointed to by the variable STATE. Each element of the OUTPUT array may be a variable that indicates, for a corresponding one of the states, the values of the outputs OUT_D1, OUT_D2, etc. For example OUTPUT[1] may correspond tostate1, OUTPUT[2] may correspond tostate2, etc. Additionally, each bit of each element may correspond to one of the outputs OUT_D1, OUT_D2, etc. For instance,bit1 may correspond to OUT_D1,bit2 may correspond to OUT_D2, etc. Referring toFIG. 13 for example, for thematrix700 the OUTPUT array would have 6 elements, and the element OUTPUT[1] may be 0×06.

At ablock862, the variable z is incremented, and at ablock866 it may be determined if the value of z is greater than the number of outputs OUT_D1, OUT_D2, etc.,. If z is not greater than the number of outputs OUT_D1, OUT_D2, etc., the routine may proceed back to theblock858. Otherwise, the routine may end.

Configuration data for the SMFB may be entered via other types of graphical user interfaces in addition to those described above. For example, configuration data may be entered via a graphical user interface that is similar to a state transition diagram.FIG. 17 is an example state transition diagram900 that could be used to configure a SMFB. The diagram900 includes a plurality ofgraphical elements904,908,912,916,920,924,928, and932.Elements904,908, and912 representstates1,2, and3, respectively, of a state machine.Element916 indicates that when the state machine is atstate1, it should transition tostate2 ifINPUT2 is asserted.Element920 indicates that when the state machine is atstate1, it should transition tostate3 ifINPUT3 is asserted.Element924 indicates that when the state machine is atstate2, it should transition tostate1 ifINPUT1 is asserted, andelement928 indicates that when the state machine is atstate3, it should transition tostate1 ifINPUT1 is asserted. Similarly,element932 indicates that when the state machine is atstate3, it should transition tostate2 ifINPUT4 is asserted.

In general, an SMFB may be implemented by software, firmware, or hardware, or some combination of software, firmware, and/or hardware. For example, an SMFB may be implemented by one or more of thecontrollers12a,16a, I/O devices24,logic solvers50, anddevices22,23,60,62. As another example, an SMFB may be implemented by one or more of theworkstations18aand20a. For instance, the SMFB may be implemented by theworkstation18aand/or theworkstation20aas part of a simulation to test operation of the process plant or provide operator training. In some embodiments, the SMFB, may be implemented by a processor configured according to software, by a programmable logic device, e.g., a device including one or more of a gate array, a standard cell, a field programmable gate array (FPGA), a PROM, an EPROM, an EEPROM, a programmable array logic (PAL), a programmable logic array (PLA), etc.

Each of theblocks404,408,412,416, and420 ofFIG. 8 and theblock754 ofFIG. 14 may be implemented by software, firmware, or hardware, or some combination of software, firmware, and/or hardware. Additionally, although the flow diagrams ofFIGS. 10-12,15, and16 were described as routines, these flow diagrams could be implemented by software, hardware, firmware, or a combination of software, firmware, and/or hardware.

Embodiments of a user interface, such as the user interfaces described above, may be implemented, in whole or in part, by a processor, for example, configured according to a software program. For instance, theworkstation18aor20a, or some other computer, may implement, in whole or in part, the above-described user interface. A software program for implementing embodiments of a user interface may be embodied in software stored on a tangible medium such as a hard disk, a RAM, a battery backed-up RAM, a ROM, a CD-ROM, a PROM, an EPROM, an EEPROM, a DVD, a flash memory, etc., or a memory, such as a RAM, associated with the processor, but persons of ordinary skill in the art will readily appreciate that the entire program or parts thereof could alternatively be executed by a device other than a processor, and/or embodied in firmware and/or dedicated hardware in a well known manner.

While the invention is susceptible to various modifications and alternative constructions, certain illustrative embodiments thereof have been shown in the drawings and are described in detail herein. It should be understood, however, that there is no intention to limit the disclosure to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions and equivalents falling within the spirit and scope of the disclosure as defined by the appended claims.

Claims (56)

1. A method for configuring a state machine implemented in a function block associated with a process plant via a computing device having a display device and an input device, wherein the state machine transitions between states based on state machine configuration data and one or more state machine inputs, wherein the state machine inputs are associated with operation of the process plant, the method comprising:

providing a graphical user interface displayed by the display device, the graphical user interface including a plurality of graphical elements, the graphical elements comprising a first plurality of cells associated with the function block arranged in a matrix having a first dimension and a second dimension, wherein positions along the first dimension correspond to state machine states, and positions along the second dimension correspond to state machine inputs, such that cells in the first plurality of cells define input/state pairs corresponding to the position of the cells relative to the first and second dimensions;

receiving state transition data associated with one or more of the plurality of graphical elements via the input device, the state transition data identifying one or more next states to which the state machine transitions following conditions in the process plant corresponding to the input/state pairs defined by one or more of the cells of the first plurality of cells; and

storing the state transition data on the first computer readable medium associated with the function block.

2. A method according toclaim 1, further comprising displaying the first plurality of cells on the display device and displaying indications of the state transition data in the one or more of the first plurality of cells for which state transition data have been received.

3. A method according toclaim 2 wherein displaying the first plurality of cells on the display device comprises displaying the matrix wherein the first dimension comprises at least one row of cells and the second dimension comprises a plurality of columns of cells, such that each of the at least one row of cells is associated with a state machine input, and each column of cells is associated with one of the plurality of states.

4. A method according toclaim 2, wherein displaying the first plurality of cells on the display device comprises displaying the matrix wherein the first dimension comprises at least one column of cells and the second dimension comprises a plurality of rows of cells such that each row of cells is associated with one of the plurality of states, and wherein each of the at least one column of cells is associated with a state machine input.

5. A method according toclaim 4, wherein the particular value of the input is one of a logical one, a logical zero, a logical TRUE or a logical FALSE value.

6. A method according toclaim 1, further comprising:

receiving data, via the input device, indicative of a number of the state machine inputs; and

identifying cells in the first plurality of cells based on the number of state machine inputs.

7. A method according toclaim 6, further comprising:

receiving data, via the input device, indicative of a number of states in the plurality of states;

wherein identifying the cells in the first plurality of cells comprises identifying cells based on the number of inputs and the number of states.

8. A method according toclaim 1, further comprising:

receiving data, via the input device, indicative of a number of states in the plurality of states; and

identifying a number of cells in the first plurality of cells based on the number of states.

9. A method according toclaim 1, wherein the plurality of graphical elements further comprises a second plurality of cells associated with the function block, wherein each cell of the second plurality of cells corresponds to a respective one of a plurality of outputs of the function block and a respective one of the plurality of states of the state machine;

receiving output configuration data associated with one or more cells of the second plurality of cells via the input device, wherein respective output configuration data associated with each of the one or more cells of the second plurality of cells includes data indicative of an output value of the output corresponding to the cell when the state machine is in the state corresponding to the cell; and

storing the output configuration data on a second computer readable medium associated with the function block.

10. A method according toclaim 9, wherein the first computer readable medium comprises the second computer readable medium.

11. A method according toclaim 1, further comprising:

receiving data indicative of how to handle inputs that have a BAD status; and

storing the data indicative of how to handle inputs that have the BAD status.

12. A method according toclaim 1, wherein the one or more state machine inputs comprises a plurality of state machine inputs, the method further comprising:

receiving data, via the graphical user interface, indicative of priorities associated with the plurality of state machine inputs; and

storing the data indicative of how to handle inputs that have a BAD status.

13. A method according toclaim 1, further comprising receiving data indicative of whether one or more, if any, one or more state machine inputs should be ignored by the state machine; and

storing the data indicative of whether one or more, if any, one or more state machine inputs should be ignored by the state machine.

14. A method according toclaim 1, wherein the one or more state machine inputs is to be associated with at least one of a process control system, a simulation of a process control system, a safety system, and a simulation of a safety system.

15. A method according toclaim 1, wherein the one or more state machine inputs is to be received from at least one other function block associated with the process plant.

16. A method according toclaim 1, wherein the one or more state machine inputs is to be received from an operator interface.

17. A tangible medium storing machine readable instructions comprising:

first code to provide a graphical user interface via a display device for configuring state machine transitions among a plurality of states, the graphical user interface including a plurality of graphical elements comprising a first plurality of cells associated with the function block arranged in a matrix having a first dimension and a second dimension, wherein positions along the first dimension correspond to state machine states, and positions along the second dimension correspond to state machine inputs, such that cells in the first plurality of cells define input/state pairs corresponding to the position of the cells relative to the first and second dimensions which can be used to indicate desired transitions between states;

second code to receive state transition data identifying a state machine next state associated with one of the graphical elements via the graphical user interface; and

third code to store the state transition data on a computer readable medium associated with a function block implementing a state machine in a process plant such that the state machine transitions to the next state when conditions in the process plant correspond to the input/state pair associated with the graphical element.

18. A tangible medium according toclaim 17,

wherein the second code comprises fourth code to receive respective data associated with one or more of the first plurality of cells via an input device of the computing device, wherein the respective data is indicative of a next state to which the state machine is to transition when the state machine is in the state corresponding to the cell and when the input corresponding to the cell is a particular value.

19. A tangible medium according toclaim 18, further comprising fifth code to display on the display device indications of the state transition data in appropriate cells of the first plurality of cells.

20. A tangible medium according toclaim 18, wherein the first code comprises fifth code to display the matrix on a display device wherein the first dimension comprises at least one row of cells and the second dimension comprises a plurality of columns of cells, such that each row of the at least one row corresponds to a state machine input, and wherein each column of the plurality of columns is associated with a state machine state.

21. A tangible medium according toclaim 18, wherein the first code comprises fifth code to display the matrix on a display device wherein the first dimension comprises at least one column of cells and the second dimension comprises a plurality of rows of cells such that each row of the plurality of rows corresponds to a state machine state, and wherein each column of the at least one column is associated with a state machine input.

22. A tangible medium according toclaim 18, wherein the particular value is one of a logical one, a logical zero, a logical TRUE value or a logical FALSE value.

23. A tangible medium according toclaim 18, further comprising:

fifth code to receive data, via the input device, indicative of a plurality of state machine inputs; and

sixth code to determine a number of cells in the first plurality of cells based on the number of inputs.

24. A tangible medium according toclaim 23, further comprising:

seventh code to receive data, via the input device, indicative of a number of state machine states;

wherein the sixth code comprises code to determine the number of cells based on the number of state machine inputs and the number of state machine states.

25. A tangible medium according toclaim 18, further comprising:

fifth code to receive data, via the input device, data indicative of a number of state machine states; and

sixth code to determine a number of cells in the first plurality of cells based on the number of state machine states.

26. A tangible medium according toclaim 18, wherein the plurality of graphical elements comprises a second plurality of cells associated with the function block, wherein each cell of the second plurality of cells corresponds to a respective one of a plurality of outputs of the function block and a respective one of the plurality of states of the state machine;

sixth code to receive output configuration data associated with at least some of the second plurality of cells via the input device, wherein respective output configuration data associated with each cell of the at least some of the second plurality of cells includes data indicative of an output value of the output corresponding to the cell when the state machine is in the state corresponding to the cell; and

seventh code to store the output configuration data.

27. A tangible medium according toclaim 17, wherein the state machine inputs comprise a plurality of inputs, the tangible medium further comprising:

fourth code to receive data, via the input device, indicative of priorities associated with the plurality of state machine inputs; and

fifth code to store the data indicative of the priorities.

28. A tangible medium according toclaim 17, further comprising:

fourth code to receive data indicative of how to handle state machine inputs that have a BAD status; and

fifth code to store the data indicative of how to handle state machine inputs that have a BAD status.

29. A tangible medium according toclaim 17, further comprising:

fourth code to receive data indicative of whether to ignore one or more, if any, of the state machine inputs; and

fifth code to store the data indicative of whether to ignore one or more, if any, of the state machine inputs.

30. A tangible medium according toclaim 17, wherein at least one state machine input is to be associated with at least one of a process control system, a simulation of a process control system, a safety system, or a simulation of a safety system.

31. A tangible medium according toclaim 17, wherein at least one state machine input is to be received from at least one other function block associated with the process plant.

32. A tangible medium according toclaim 17, wherein at least one state machine input is to be received from an operator interface.

33. A method of implementing a state machine in a function block for use in controlling, or simulating control of, one or more field devices in a process plant, the method comprising:

providing a graphical user interface displayed by a display device, the graphical user interface including a plurality of graphical elements for configuring state machine transitions between a plurality of state machine states, the graphical elements comprising a first plurality of cells associated with the function block arranged in a matrix having a first dimension and a second dimension, wherein positions along the first dimension correspond to state machine states, and positions along the second dimension correspond to state machine inputs, such that cells in the first plurality of cells define input/state pairs corresponding to the position of the cells relative to the first and second dimensions, wherein one or more state machine inputs are indicative of one or more conditions within the process plant;

receiving state transition data identifying a state machine next state associated with at least one of the first plurality of cells via an interface input associated with the graphical user interface;

storing the state transition data on a first computer readable medium associated with the function block;

receiving at least one state machine input;

determining a state machine next state based on the at least one input, a current state, and the state transition data stored on the first computer readable medium;

setting the current state of the state machine to the state machine next state; and

providing at least one function block output for use in controlling the one or more field devices to at least a second other function block, wherein the at least one function block output is based on the current state of the state machine.

34. A method according toclaim 33, wherein the one or more state machine inputs comprises a plurality of state machine inputs;

wherein determining the state machine next state is further based on priorities associated with the plurality of state machine inputs.

35. A method according toclaim 34, wherein the state machine next state is based on an order determined by the priorities associated with the plurality of state machine inputs.

36. A method according toclaim 33, further comprising:

determining whether a state transition is to occur based on the received at least one state machine input and the state transition data stored on the first computer readable medium;

wherein determining the next state comprises determining the next state if a state transition is to occur; and

wherein setting the current state of the state machine to the next state comprises setting the current state of the state machine to the next state if a state transition is to occur.

37. A method according toclaim 33, wherein determining the next state comprises determining whether one or more, of the received at least one state machine inputs is a particular value.

38. A method according toclaim 37, wherein determining the next state further comprises determining whether one or more, of the one or more of the received at least one state machine inputs that are a particular value and that also correspond to state changes based on the state transition data stored on the first computer readable medium.

39. A method according toclaim 38, further comprising selecting one of the one or more of the received at least one inputs that are a particular value and that correspond to state changes.

40. A method according toclaim 39, wherein the at least one input comprises a plurality of inputs;

wherein selecting one of the one or more of the received at least one inputs that are a particular value and that correspond to state changes comprises selecting one of the one or more of the received at least one inputs that are a particular value based on priorities associated with the plurality of inputs.

41. A method according toclaim 40, wherein selecting one of the one or more of the received at least one inputs that are a particular value and that correspond to state changes comprises selecting one of the one or more of the received at least one inputs that are a particular value based on an order associated with the plurality of inputs.

42. A method according toclaim 33, wherein determining the next state comprises determining one or more of the received at least one inputs associated with potential state changes from the current state based on the state transition data stored on the first computer readable medium.

43. A method according toclaim 42, wherein determining the next state further comprises determining one or more of the one or more of the received at least one inputs associated with potential state changes from the current state that are a particular value.

44. A method according toclaim 33, wherein providing the at least one function block output comprises providing a plurality of function block outputs.

45. A method according toclaim 44, wherein each of at least some of the plurality of function block outputs are indicative of whether the current state of the state machine corresponds to a respective one of a plurality of possible states of the state machine.

46. A method according toclaim 44, wherein providing the plurality of function block outputs comprises:

retrieving, based on at least the current state, data indicative of appropriate values for at least some of the plurality of state machine function block outputs from an output configuration database; and

setting the at least some of the plurality of function block outputs to the appropriate values.

47. A method according toclaim 44, wherein providing the plurality of function block outputs comprises providing one function block output indicative of the current state of the state machine.

48. A method according toclaim 33, wherein the at least one function block output comprises a function block output that is indicative of the current state of the state machine.

49. A method according toclaim 33, further comprising:

receiving an input indicative of whether the state machine function block is to be disabled; and

if the input indicative of whether the state machine function block is to be disabled indicates that the state machine function block is to be disabled, setting the current state of the state machine to a disabled state.

50. A method according toclaim 49, further comprising:

receiving an input indicative of whether the state machine function block is to be forced to an initial state; and

if the input indicative of whether the state machine function block is to be forced to the initial state indicates that the state machine function block should be forced to the initial state, setting the current state of the state machine to the initial state;

wherein the input indicative of whether the state machine function block is to be enabled and the input indicative of whether the state machine function block is to be forced to the initial state comprise a single input.

51. A method according toclaim 33, further comprising:

receiving an input indicative of whether the state machine function block is to forced to an initial state; and

if the input indicative of whether the state machine function block is to be forced to the initial state indicates that the state machine function block should be forced to the initial state, setting the current state of the state machine to the initial state.

52. A method according toclaim 33, wherein receiving at least one state machine input comprises receiving at least one signal associated with at least one of a process control system, a simulation of a process control system, a safety system, and a simulation of a safety system.

53. A method according toclaim 33, wherein the at least one state machine input is to be received from at least one other function block associated with the process plant.

54. A method according toclaim 33, wherein the at least one state machine input is to be received from an operator interface.

55. A method according toclaim 33, wherein providing the at least one function block output comprises providing the at least one function block output to a portion of a process control system, wherein the portion of the process control system controls the one or more field devices based, at least in part, on the at least one function block output.

56. A method according toclaim 33, wherein providing the at least one function block output comprises providing the at least one function block output to a portion of a safety system, wherein the portion of the safety system controls the one or more field devices based, at least in part, on the at least one function block output.

Images