WO2005038544A2 - Integrated electronic signatures for approval of process control and safety system software objects - Google Patents
Integrated electronic signatures for approval of process control and safety system software objects Download PDFInfo
- Publication number
- WO2005038544A2 WO2005038544A2 PCT/US2004/001205 US2004001205W WO2005038544A2 WO 2005038544 A2 WO2005038544 A2 WO 2005038544A2 US 2004001205 W US2004001205 W US 2004001205W WO 2005038544 A2 WO2005038544 A2 WO 2005038544A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- software object
- software
- entities
- approval
- group
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/20—Pc systems
- G05B2219/24—Pc safety
- G05B2219/24008—Safety integrity level, safety integrated systems SIL SIS
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/20—Pc systems
- G05B2219/24—Pc safety
- G05B2219/24166—Permit from several operators to allow access
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
- Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
- Y02P90/02—Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]
Definitions
- Process control software may be implemented in software objects run on the controller (or other computer) to perform any of a variety of control functions.
- software objects may be arranged to implement different phases, which are generically related to various types of process steps.
- a software object that implements a mixing phase may be associated with hardware that carries out a mixing step of a process.
- each software object implementing a phase performs some discrete function and communicates with other objects to implement a more complex control procedure.
- an engineer may start with template software objects having generic control logic therein for implementing a particular function, such as a phase in the batch process. Due to the generic nature of these template software objects, the software objects must be modified or customized based on the particulars of the step that they are to execute before being used in a particular process control environment. For example, a mixing phase, which is generally adapted to operate mixing equipment, must be customized to operate a particular piece of mixing equipment for particular time durations at particular speeds. Recipes are commonly used to customize or modify phases. As the name implies, recipes include sets of instructions downloaded to process control hardware for carrying out specific tasks such as, for example, making cookies, producing pharmaceuticals or controlling other processes.
- a cookie-making recipe may include a mixing step that could be carried out by a mixing phase.
- the cookie making recipe specifies the duration and speed at which mixing should be carried out. Accordingly, the recipe specifies the parameters that define the operation of the mixing phase.
- a safety instrumented system may have one or more safety controllers that are programmed, using safety related software objects, to detect hazardous, dangerous or undesirable conditions Within the process plant and to take some action, such as shutting the process down, diverting flow within the process, removing power, etc. when such a condition is detected.
- recipes for process control systems, as well as other software modules or objects including safety system software objects are written by an engineer or scientist who requests various entities such as, for example, research or production groups, to approve the recipe or the safety system software before it is downloaded to the process control system or the safety system.
- the approval process for process control system software is typically carried out by circulating a memorandum or a request for approval and, in some cases, by requesting input in more informal manners.
- SOPs standard operating procedures
- the draft standard IEC 615511 requires such approval, in addition to defining different approval levels for differing safety integrity levels (SIL).
- SIL safety integrity levels
- the validation plan for a facility may include SOPs requiring safety functions that are to be executed by the safety instrumented system to be approved by a peer in the same department if the SLL is level 2 or below and by a peer in a different department if the SLL is level 3 or above.
- a SLL is a measure defined in the IEC61508 standard which defines the integrity of a system with respect to how well the system can be counted on to do what it is supposed to do when it is supposed to do it. More particularly, the SLL is defined by the average probability of failure on demand (PFDavg).
- the risk reduction factor which is related to the reciprocal of the PFDavg, defines the difference between the process risk before a safety instrumented function is used and the "tolerable level" of risk which much be achieved for that process or piece of equipment. Basically, the risk reduction factor is the "unmitigated risk" without a safety instrumented function divided by the established “tolerable risk". Both the risk reduction factor and the SIL are defined for each different safety instrumented function within a safety system, wherein an individual safety instrumented function is designed to identify a need and then act to bring the system to a safe state for each hazard scenario.
- approvals are typically handled using one of two possible approaches including a manual approach and an electronic approach.
- a printed copy of the software object i.e., a printed copy of the safety function software
- all approval signatures are collected manually in a paper format.
- an electronic document management system is used to route an electronic version of the software object (i.e., a series of screen captures or other text and graphical based documentation that describes the software) to each of the required approvers for review. In this case, all approval signatures are collected in an electronic format.
- a software object approval system is integrated with a process control or safety system environment and, in particular, with a process control or safety system design environment to implement and manage electronic approval of new software objects created within the process control system and safety system environments.
- a system and method for use in a process control system and/or safety system electronically generates identification information representing a group entities whose approval is needed prior to implementing a software object within the process control or safety system.
- the system and method may receive from each entity represented within the identification information an electronic indication regarding approval of the software object and may prevent the process control or safety system from implementing the software object until each entity represented within the identification information approves the software object.
- the system and method selectively enable the process control or safety system to implement the software object based on the electronic indications.
- the software object approval system and method for use in a process control or safety system may also or instead determine that a software object is not approved in response to receiving an electronic indication that at least one of a plurality of entities has not approved the software object or when the software object is changed or altered in some manner.
- the system and method may thereafter . determine that the software object is approved in response to receiving another electronic indication that each one of the plurality of entities has approved the software object and, in response to such approval, the system and method may enable downloading of the software object to the process control or safety system.
- Fig. 1 is a partial block diagram of a process control system that includes an integrated electronic software object approval system therein to approve of one or more control software objects that perform control of process equipment;
- Fig. 2 is a block diagram of an object structure illustrating. a typical logical hierarchy or configuration of the process control system of Fig. 1;
- FIG. 3 is a more detailed block diagram illustrating a portion of the object structure of Fig. 2 in more detail;
- Fig. 4 is a block diagram of an exemplary process plant having a safety system that is integrated with a process control system, wherein the safety system includes an integrated electronic software object approval system therein;
- Figs. 5A and 5B are exemplary flow diagrams of an approval routine
- Fig. 6 is an exemplary flow diagram of a software object editor routine
- Fig. 7 is an exemplary flow diagram of an authorization setup routine
- Fig. 8 is an exemplary user interface associated with the authorization setup routine of Fig. 7;
- Fig. 9 is an exemplary flow diagram of an add routine
- Fig. 10 is an exemplary user interface associated with the add routine of Fig. 9;
- Fig. 11 is an exemplary flow diagram of a delete routine
- Fig. 12 is an exemplary flow diagram of a modify routine
- Fig. 13 is an exemplary user interface associated with the modify routine of Fig. 12;
- Fig. 14 is an exemplary flow diagram of a software object authorization routine
- Fig. 15 is an exemplary user interface associated with the software object authorization routine of Fig. 14;
- Fig. 16 is an exemplary flow diagram of an approve routine
- Fig. 17 is an exemplary user interface associated with the approval routine of Fig. 16; .
- Fig. 18 is an exemplary flow diagram of a reject routine
- Fig. 19 is an exemplary user interface of showing the status of unapproved software objects.
- Fig. 20 is an exemplary flow diagram of a download routine.
- DETAILED DESCRIPTION Methods and systems for electronically controlling the approval and downloading of software objects such as, for example, recipes in process control systems or software routines in safety instrumented systems are described in detail below and may be used to enable an author of a software object to automatically and/or electronically obtain the approval of the persons or groups of reviewers that must authorize a software object before the object is downloaded to or implemented within the process control system or the safety instrumented system. These methods and systems enable the reviewers to review the software object in the environment in which it will be used so that the software object being reviewed is as accurate as possible.
- the approval system is integrated with the process control or safety system design environment, the approval system can provide a mechanism to assure that an unapproved software object cannot be executed until all approvals are in place and that all prior approvals for a software object are revoked (i.e., that the software goes to the unapproved state) if a change is made to the software object. Additionally, the integrated software object approval system makes it possible for the process control or safety system to maintain an accurate record of approvals within the software development audit trail for the software object.
- the reviewers or signers of a software object may be notified by a number of different techniques and, upon notification, may review the software object, and approve or reject the software object. If each of the reviewers approves the software object, the software object may be made available for download to the process control system or to the safety instrumented system. Additional functionality may include enabling various persons or entities (e.g., reviewers, authors, business groups or others) to check the approval status of a software object, automatically removing the authorization if the software object is changed, automatically changing the version of the software object when changes are made, etc.
- persons or entities e.g., reviewers, authors, business groups or others
- the software object approval system and method is described by way of example below as being used for the approval and downloading of recipes within a process control system, or for the approval and downloading of software objects in a safety system environment, the system and method described herein may also be advantageously used for other types of software objects such as, for example, units, phases, graphics, etc. in other process control environments. Further, the software object approval system and method described by way of example herein, may be used to approve and download a single software object at one time and/or groups of related or unrelated software objects at the same or at different times.
- an example process control system 10 includes controllers 12 coupled to a plurality of workstations 14 via an Ethernet connection 15.
- the controllers 12 are also coupled to devices or equipment associated with a process (generally designated by the reference numeral 16) via a set of communication lines or a bus 19.
- the controllers 12, which may be, by way of example only, the DeltaVTM controllers sold by Emerson Process Management are capable of communicating with control elements, such as field devices and function blocks within field devices distributed throughout the process 16 to perform one or more process control routines or software objects, which are preferably implemented using object-oriented programming techniques, to thereby implement desired control of the process 16.
- the workstations 14 may include design software 17 that is used by one or more engineers or other users to design process control routines or software objects to be executed by the controllers 12, to communicate with the controllers 12 to download such process control routines or software objects and to receive and display information pertaining to the process 16 during operation of the process 16.
- approval software 18 may be communicatively connected to and integrated with the design software 17 to provide for the approval of any of the recipes or other process control routines or objects designed or modified using the design software 17.
- Each of the workstations 14 includes a memory 20 for storing applications, such as configuration design applications, and for storing data, such as configuration data pertaining to the configuration of the process 16.
- Each of the workstations 14 also includes a processor 21 that executes the applications 17 and 18 to enable a user to design and/or modify process control routines or software objects and to download these process control routines or software objects to the controllers 12.
- each of the controllers 12 includes a memory 22 for storing configuration data and process control routines to be used to control the process 16 and includes a processor 24 that executes the process control routines to implement a process control strategy.
- controllers 12 are DeltaV controllers, they may provide a graphical depiction of the process control routines within the controllers 12 to a user via one of the workstations 14 illustrating the control elements within the process control routine and the manner in which these control elements are configured to provide control of the process 16.
- the system 10 of Fig. 1 may also include a network 30 to which one or more of the workstations 14 may be connected.
- the network 30 may be implemented using any suitable network such as, for example, the Internet, an intranet, a local area network (LAN), a wide area network (WAN) or any other suitable network.
- LAN local area network
- WAN wide area network
- the network 30 is shown as having hardwired connections, it will be readily appreciated that such a network could be a wireless network or could be a.network including both hardwired and wireless portions.
- a number of terminals 32 may also be connected to the workstations 14 via the network 30.
- Each of the terminals 32 may include a memory 34 coupled to a processor 36 that is adapted to execute instructions stored on the memory 34.
- the terminals 32 may be personal computers or any like processing devices that may include the same or more processing power and memory than is available in conventional personal computers known today.
- Reactor_01 includes a reactor vessel 100, two input valves 101 and 102 connected to control fluid inlet lines that provide fluid to the reactor vessel 100 and an output valve 103 connected to control fluid flow out of the reactor vessel 100 via an outlet fluid line.
- a device 105 which may be a sensor, such as a temperature sensor, a pressure sensor, a fluid level meter, etc. or some other equipment such as an electrical heater or a steam heater, is disposed in or near the reactor vessel 100.
- Reactor_02 includes a reactor vessel 200, two input valves 201 and 202, an output valve 203 and a device 205.
- Reactor_03 includes a reactor vessel 300, two input valves 301 and 302, an output valve 303 and a device 305.
- the controllers 12 are communicatively coupled to the valves 101-103, 201-203 and 301-303 and to the devices 105, 205 and 305 via the bus 19 to control the operation of these elements to perform one or more operations with respect to the reactor units.
- Such operations may include, for example, filling the reactor vessels, heating the material within the reactor vessels, dumping the reactor vessels, cleaning the reactor vessels, etc.
- the valves, sensors and other equipment illustrated in Fig. 1 may be any desired kind or type of equipment including, for example, Fieldbus devices, standard 4-20 mA devices, HART devices, etc. and may communicate with the controllers 12 using any known or desired communication protocol such as the Fieldbus protocol, the HART protocol, the 4-20 mA analog protocol, etc. Still further, other types of devices may be connected to and be controlled by the controllers 12. Also, other controllers may be connected to the controllers 12 and to the workstations 14 via the Ethernet communication link 15 to control other devices or areas associated with the process 16 and the operation of such additional controllers maybe coordinated with the operation of the controllers 12 illustrated in Fig. 1 in any desired manner.
- the process control system 10 of Fig. 1 may be used to implement batch processes in which, for example, one of the workstations 14 or the controllers 12 executes a batch executive routine 40, which is a high-level control routine that directs the operation of one or more of the reactor units (as well as other equipment) to perform a series of different steps (commonly referred to as phases) needed to produce a product, such as a food product, a drug or other pharmaceutical product, etc.
- the steps or phases are typically implemented using software objects that can be downloaded to and instantiated and executed by one of more of the processors 21 and 24 within the system 10.
- the batch executive routine 40 uses what is commonly referred to as a recipe, which is a software object that specifies the steps to be performed, the amounts and times associated with the steps and the sequence of the steps. Steps for one recipe might include, for example, filling a reactor vessel with the appropriate materials or ingredients, mixing the materials within the reactor vessel, heating the materials within the reactor vessel to a certain temperature for a certain amount of time, emptying the reactor vessel and then cleaning the reactor vessel to prepare for the next batch run. Each of the steps defines a phase of the batch run and the batch executive routine 40 will cause the controllers 12 to execute a different control algorithm for each one of these phases. Of course, the specific materials, amounts of materials, heating temperatures and times, etc.
- control routines and • configurations are described herein for batch runs in the reactor units illustrated in Fig. 1, control routines may be used to control other desired devices to perform any other desired batch process runs or to perform continuous process runs, ifdesired.
- a person or entity at one of the workstations 14 may use the design software 17 to create or modify recipes or other software objects and the approval software 18 may electronically request approval from various authorizing entities such as, for example, production, engineering, quality assurance or management.
- the authorizing entities may use the workstations 14 or the terminals 32 to review the recipe and or other software object(s) in question and approve or reject the recipe and/or other software object(s).
- the approval or rejection of the software objects in question may be communicated to the person or entity that requested approval of the objects or back to the approval routine 18 which can track who has and who has not approved of the software object.
- the approval routine 18 may enable the software object to be downloaded to one of the controllers 12 or to the batch executive routine 40 for implementation or execution within the process control system 10.
- the object tree of Fig. 2 illustrates example software objects that may be created and downloaded with the design software 17 acting in conjunction with the approval software 18.
- the software objects of Fig. 2 are provided merely as examples of software objects (in addition to the recipes described above) that maybe created and approved using the integrated electronic approval system described herein, it being understood that other software objects may be created and approved using this system as well.
- the software objects of Fig. 2, which are implemented using software routines, are illustrated with boxes while general categories of objects (or object types) are indicated above the objects in the tree with no box.
- the process control system 10 includes one or more areas that may be, for example, buildings or other geographical area designations within a process control plant.
- the process 16 has three area objects named Building_01, Building_02 and Building_03. Each area object may be divided into process cells, each of which corresponds to a different aspect of the process being performed in the ⁇ area.
- the Building__01 area object of Fig. 2 is illustrated as including two process cell objects designated Cell_01 and Cell__02.
- Cell_01 may, for example, be related to making a component of a product used in Cell_02.
- Each cell object may include zero or more unit classes, which identify different categories or groupings of hardware used in the process cell.
- a unit class is a named object that holds a common configuration of a set of related equipment and, more particularly, is a collection of units that have very similar, if not identical, process instrumentation, each of which performs a very similar, if not identical, function within a process.
- Unit class objects are typically named to describe the types of units within the process control system to which they belong.
- Fig. 2 includes a Mix_Tank unit class, a Reactor unit class and a Feed_Tank unit class.
- many other types of unit classes will be provided or defined including, for example, dryer units, feedheader units, and other individual or logical groupings of hardware.
- each unit class object may have unit module objects and phase class objects associated therewith.
- Unit module objects generally specify certain instances of replicated hardware within the named unit class while phase classes generally specify the phases that can be applied to the unit modules associated with the unit class.
- a unit module object is a named object that holds all of the variables and unit phases (defined hereinafter) for a single process unit and is typically named to identify specific process equipment.
- the Reactor unit class of Fig. 2 has Reactor_01, Reactor_02 and Reactor_03 unit modules, which correspond to Reactor_01, Reactor_02 and Reactor_03 illustrated in Fig. 1, respectively.
- a phase class is a named object that holds the common configuration for a phase that can run on the multiple units belonging to the same unit class and on multiple different unit classes.
- each phase class is a different control routine (or phase) that is created and used by the controllers 12 to control unit modules within the same or different unit classes.
- each phase class is named in accordance with the verb that describes an action performed on, a unit module. For example, as illustrated in Fig.
- the Reactor unit class has a Fill phase class, which is used to fill any one of the reactor vessels 100, 200 or 300 of Fig. 1, a Heat phase class, which is used to heat any one of the reactor vessels 100, 200 or 300 of Fig. 1, a Dump phase class, which is used to empty any one of the reactor vessels 100, 200 or 300 of Fig. 1, and a Clean phase class, which is used to clean any one of the reactor vessels 100, 200 or 300 of Fig. 1.
- the Fill phase class is associated with both the Reactor unit class and the FeedJTank unit class and, thus, can be used to perform fill functions on Reactor unit modules as well as FeedJTank unit modules.
- a phase class may generally be thought of as a software routine or object that may be called by the batch executive routine to perform some function needed in an overall batch process, as defined by the recipe' for that batch process.
- a phase class may include zero or more phase input parameters, which are basically the inputs provided to the phase class software routine or object from the batch executive routine or another phase class; zero or more phase output parameters which are basically the outputs of the phase class routine passed back to the batch executive routine or to another phase class; zero or more phase messages, which may be messages to be displayed to the user regarding the operation of the phase class, information related to other phase classes with which the phase class is associated in some manner; and zero or more phase algorithm parameters, which cause parameters to be created in phase logic modules (PLMs) or unit phases based on this phase class.
- PLMs phase logic modules
- phase algorithm parameters are used as temporary storage locations or variables during the execution of the phase and are not necessarily visible to the user or to the batch executive routine.
- the phase class includes one or more phase algorithm definitions (PADs) that, generally speaking, are the control routines used to implement the phase.
- PADs phase algorithm definitions
- the phase class has a list of associations to zero, one, two or more unit classes, and this list defines the unit classes for which this phase class and, consequently, the PAD of the phase class, can be applied.
- the Fill phase class list of associations includes both the Reactor unit class and the FeedJTank unit class.
- Fig. 3 depicts a more detailed version of some of the objects illustrated in Fig. 2 and the interrelationships between these objects.
- Two unit classes are depicted in Fig. 3, namely, a Reactor unit class 50 and a FeedJTank unit class 52.
- the Reactor unit class 50 has one unit module 54, namely Reactor__01. While others may exist, they are simply not illustrated in Fig. 3.
- the unit module 54 defines some of the reactor parameters associated with the Reactor unit class 50, namely, that the capacity of the Reactor_01 is 300 and that the Reactor_01 does not include an agitator.
- two phase classes are associated with the Reactor unit class 50 including a Fill phase class 56 and a Dump phase class 58.
- the Fill phase class 56 includes a PAD (illustrated as an SFC in graphical form on the right side thereof) that has been designed using two alias names, namely, #TNLET_VALVE# and #LEVEL#. These alias names are actually used in the boxes illustrated in the PAD of the Fill phase class 56 but may, alternatively, be used anywhere else within the logic of the PAD.
- the Fill phase class 56 also includes an input defined as TARGET_LEVEL and an output defined as FLNALJLEVEL. While the alias names are indicated as being delimited or marked by a number sign (#), any other identifier could be used to define an alias name that must be replaced upon instantiation of a phase.
- the Dump phase class 58 includes a PAD, illustrated on the right hand side thereof in graphical form, having alias names of #OUTLET_VALVE# and #LEVEL#, an input defined as RATE, an output defined as FINAL_LEVEL and an algorithm parameter (used by the PAD) defined as ACTUAL_RATE, which may be used as a temporary storage location during execution of the PAD.
- a PAD illustrated on the right hand side thereof in graphical form, having alias names of #OUTLET_VALVE# and #LEVEL#, an input defined as RATE, an output defined as FINAL_LEVEL and an algorithm parameter (used by the PAD) defined as ACTUAL_RATE, which may be used as a temporary storage location during execution of the PAD.
- Figs. 1-3 illustrate a process control system in which software objects may be created and used to perform traditional process control functions
- Fig. 4 illustrates an integrated process control system and safety instrumented system that includes integrated design and approval software that may be used to create, change and approve the same or other software objects within either or both of the process control system and the safety instrumented system.
- a process plant 110 includes a process control system 112 integrated with a safety system 114 (indicated by dotted lines), which generally operates as a Safety Instrumented System (SIS) that monitors and overrides the control provided by the process control system 112 to thereby maximize the likely safe operation of the process plant 110.
- SIS Safety Instrumented System
- the process plant 110 also includes one or more host workstations, computers or user interfaces 116 (which may be any type of personal computers, workstations, PDAs, etc.) which are accessible by plant personnel, such as process control operators, maintenance personnel, safety engineers, etc.
- two user interfaces 116 are shown as being connected to two separate process control/safety control nodes 118 and 120 and to a configuration database 121 via a common communication line or bus 122.
- the communication network 122 may be implemented using any desired bus-based or non-bus based hardware, using any desired hardwired or wireless communication structure and using any desired or suitable communication protocol, such as an Ethernet protocol.
- each of the nodes 118 and 120 of the process plant 110 includes both process control system devices and safety system devices connected together via a bus structure that may be provided on a backplane into which the different devices are attached.
- the node 118 is illustrated in Fig. 4 as including a process controller 124 (which may be a redundant pair of controllers) as well as one or more process control system input/output (I/O) devices 128, 130 and 132 while the node 120 is illustrated as including a process controller 126 (which may be a redundant pair of controllers) as well as one or more process control system I/O devices 134 and 136.
- Each of the process control system I/O devices 128, 130, 132, 134 and 136 is communicatively connected to a set of process control related field devices, illustrated in Fig. 4 as field devices 140 and 142.
- the process controllers 124 and 126, the I/O devices 128-136 and the controller field devices 140 and 142 generally make up the process control system 112 of Fig. 4.
- the node 118 includes one or more safety system logic solvers 150, 152, while the node 120 includes safety system logic solvers 154 and 156.
- Each of the logic solvers 150-156 is an I/O device having a processor 157 that executes safety logic modules 158 stored in a memory 179 and is communicatively connected to provide control signals to and/or receive signals from safety system field devices 160 and 162.
- each of the nodes 118 and 120 includes a message propagation device (MPD) 170 or 172, which are communicatively coupled to each other via a ring type bus connection 174 (only part of which is illustrated in Fig. 4).
- the safety system logic solvers 150-156, the safety system field devices 160 and 162, the MPDs 170 and 172 and the bus 174 generally make up the safety system 114 of Fig. 4.
- the process controllers 124 and 126 which may be, by way of example only, DeltaVTM controllers sold by Emerson Process Management or any other desired type of process controllers, are programmed to provide process control functionality (using what are commonly referred to as control modules) using the I/O devices 128, 130 and 132 (for the controller 124), the I/O devices 134 and 136 (for the controller 126) and the field devices 140 and 142.
- each of the controllers 124 and 126 implements or oversees one or more process control routines (which are software objects and may be made up of a collection of interconnected software objects) stored therein or otherwise associated therewith and communicates with the field devices 140 and 142 and the workstations 114 to control the process 110 or a portion of the process 110 in any desired manner.
- process control routines which are software objects and may be made up of a collection of interconnected software objects
- the field devices 140 and 142 may be any desired types of field devices, such as sensors, valves, transmitters, positioners, etc., and may conform to any desired open, proprietary or other communication or programming protocol including, for example, the HART or the 4- 20 ma protocol (as illustrated for the field devices 140), any fieldbus protocol such as the FOUNDATION ® Fieldbus protocol (as illustrated for the field devices 142), or the CAN, Profibus, the AS-Interface protocols, to name but a few.
- the I/O devices 128-136 may be any known types of process control I/O devices using any appropriate communication protocol(s).
- the safety logic solvers 150-156 of Fig. 4 may be any desired type of safety system control devices that include a processor 157 and a memory that stores safety logic modules 158 adapted to be executed on the processor 157 to provide control functionality associated with the safety system 114 using the field devices 160 and 162.
- the safety field devices 160 and 162 may be any desired type of field devices conforming or using any known or desired communication protocol, such as those mentioned above.
- the field devices 160 and 162 may be safety- related field devices of the type that are conventionally controlled by a separate, dedicated safety-related control system. In the process plant 110 illustrated in Fig.
- the safety field devices 160 are depicted as using a dedicated or poi t-to-point communication protocol, such as the HART or the 4,-20 ma protocol, while the safety' field devices 162 are illustrated as using a bus communication protocol, such as a Fieldbus protocol.
- the safety field devices 160 may perform any desired function, such as that of a shut-down valve, a shut-off switch, etc.
- a common backplane 176 (indicated by a dashed line through the controllers 124, 126, the I/O devices 128-136, the safety logic solvers 150-156 and the MPDs 170 and 172) is used in each of the nodes 118 and 120 to connect the controllers 124 and 126 to the process control I/O cards 128, 130 and 132 or 134 and 136, as well as to the safety logic solvers 150, 152, 154 or 156 and to the MPDs 170 or 172.
- the controllers 124 and 126 are also communicatively coupled to, and operate as a bus arbitrator for the bus 122, to enable each of the I/O devices 128-136, the logic solvers 150-156 and the MPDs 170 and 172 to communicate with any of the workstations 116 via the bus 122.
- each of the workstations 116 includes a processor 177 and a memory 178 and at least one of the workstations stores one or more configuration, approval, diagnostic and/or viewing applications adapted to be executed on the processor 178.
- a configuration application 180, an approval application (or routine) 181 and a viewing application 182 are illustrated in an exploded view in Fig. 4 as being stored in one of the workstations 116 while a diagnostic application 184 is illustrated as being stored in the other one of the workstations 116.
- these and other applications could be stored and executed in different ones of the workstations 116 or in other computers associated with the process plant 110.
- the configuration application 180 provides configuration information to a safety engineer and enables the safety engineer to configure (design) some or all elements of the process plant 110 and to store that configuration in the configuration database 121.
- the safety engineer may create or change control routines or control modules (i.e., software objects) for the process controllers 124 and 126, may create safety logic software modules 158 for any and all of the safety logic solvers 150-156 (including creating and programming input, voter and other function blocks for use in the safety logic solvers 150-156 or even in the controllers 124 and 126) and may download these different control and safety modules, after appropriate authorization to do so has been received via the approval routine 181, to the appropriate ones of the process controllers 124 and 126 and the safety logic solvers 150-156 via the bus 122 and controllers 124 and 126.
- the configuration application 180 may be used to create and download other programs and logic, after appropriate authorization has been received to do so via the approval routine 181, to the I/O devices 128-136, any of the field devices 140, 142, 160 and 162, etc. If desired, a separate set of configuration and approval routines may exist for each of the process control system 112 and the safety system 114 to thereby isolate the design activities of these systems from one another.
- the viewing application 182 may be used to provide one or more displays to a user, such as to a process control operator, a safety operator, etc., which includes information about the state of the process control system 112 and the safety system 114 either in separate views or in the same view, if so desired.
- the viewing application 182 may be an alarm display application that receives and displays indications of alarms to an operator. If desired, such an alarm viewing application may take the form as disclosed in U.S. Patent No. 5,768,119 entitled "Process Control System Including Alarm Priority Adjustment" and U.S. Patent Application No.
- the applications 180, 181, 182 and 184, as well as any other applications may send separate configuration and other signals to and may receive data from each of the process controllers 124 and 126 as well as from each of the safety system logic solvers 150-156.
- These signals may include process control related messages related to controlling the operational parameters of the process field devices 140 and 142, and may include safety-level messages related to controlling the operational parameters of the safety-related field devices 160 and 162.
- the safety logic solvers 150-156 may be programmed to recognize both the process control messages and the safety messages, the safety logic solvers 150-156 are capable of distinguishing between the two types of messages and will not be capable of being programmed or effected by process control related configuration signals.
- the programming messages sent to the process control system devices may include certain fields or addresses which are recognized by the safety system devices and which prevent those signals from being used to program the safety system devices. . - .
- the safety logic solvers 150-156 may use the same or a different hardware or software design as compared to the hardware and software design used for the process control I/O cards 128-136.
- the use of alternate technologies for the devices within the process control system 112 and devices within the safety system 114 may minimize or eliminate common cause hardware or software failures.
- the safety system devices, including the logic solvers 150-156 may use any desired isolation and security techniques to reduce or eliminate the chances of unauthorized changes being made to the safety-related functions implemented thereby.
- the safety logic solvers 150-156 and the configuration application 180 may require a person with a particular authority level or a person located at a particular workstation to make changes to the safety modules within the ' logic solvers 150-156, with this authority level or location being different from the authority or access level or location needed to make changes to the process control functions performed by the controllers 124 and 126 and the I/O devices 128-136.
- this authority level or location being different from the authority or access level or location needed to make changes to the process control functions performed by the controllers 124 and 126 and the I/O devices 128-136.
- only those persons designated within the safety software or located at workstations authorized to make changes to the safety system 114 have authorization to alter safety-related functions, which minimizes the chances of corruption to the operation of the safety system 114.
- the processors within the safety logic solvers 150-156 assess the incoming messages for proper form and security and operate as gatekeepers on changes being made to the safety control modules 158 executed within the safety logic solvers 150- 156
- the approval routine 181 illustrated in Fig. 4 may be implemented to prevent changes from being made to software objects within either or both of the process control system 112 and the safety system 114 without the proper authorization from other individuals (either by name or by job position) from which this authorization is required.
- the approval routine 181 may detect changes being made to software modules within the configuration, display, or viewing applications and prevent the downloading of these modules to the process control system 112 or to the safety system 114 without the appropriate authorization or approval from those needed to do so.
- each of the nodes 118 and 120 enables the safety logic solvers 150 and 152 and the safety logic solvers 154 and 156 to communicate locally with one another to coordinate safety functions implemented by each of these devices, to communicate data to one another, or to perform other integrated functions.
- the MPDs 170 and 172 operate to enable portions of the safety system 114 that are disposed at vastly different locations of the plant 110 to still communicate with one another to provide coordinated safety operation at different nodes of the process plant 110.
- the MPDs 170 and 172 in conjunction with the bus 174 enable the safety logic solvers associated with different nodes 118 and 120 of the process plant 110 to be communicatively cascaded together to allow for the cascading of safety-related functions within the process plant 110 according to an assigned priority.
- two or more safety-related functions at different locations within the process plant 110 may be interlocked or interconnected without having to run a dedicated line to individual safety field devices within the separate areas or nodes of the plant 110.
- the use of the MPDs 170 and 172 and the bus 174 enables a safety engineer to design and configure a safety system 114 that is distributed in nature throughout the process plant 110 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 the safety system 114 in that it enables additional safety logic solvers to be added to the safety system 114 as they are needed or as new process control nodes are added to the process plant 110.
- the logic solvers 150-156 may be programmed to perform control activities with respect to the safety devices 160 and 162, using a function block programming paradigm.
- a safety control module may include a set of communicatively interconnected function blocks (each of which is a software object) that can be created, and downloaded to the logic solver 154 for implementation during operation of the process 110. As illustrated in Fig.
- the control module 158a includes two voter function blocks 192 and 194 having inputs communicatively interconnected with other function blocks 190, which may be, for example, analog input (Al), digital input (DI) function blocks, or other function blocks designed to provide signals to the voter function blocks 192.
- the voter function blocks 192 and 194 have at least one output connected to one or more other function blocks 191 which may be analog output (AO), digital output (DO), cause and effect function blocks which implement cause and effect logic, control and diagnostic function blocks which may receive output signals from the voter function blocks 192 and 194 to control the operation of the safety devices 160 and 162, etc.
- the safety control module 158a may be programmed in any desired manner to include any types of function blocks configured in any desired or useful manner to perform any desired functionality.
- control module 158a and each of the function blocks therein are separate software objects which may be downloaded to the safety system 112 and which may be changed during operation, if so needed. However, before these creation or modification activities may be implemented these software objects may need to receive authorization via the approval routine 181, which will be described in more detail below.
- the approval routine 181 is integrated with or communicatively tied to the configuration application 180 (or other design applications used within the process plant) to assure that the appropriate authority or review takes place for each new or modified software object that is created or changed, before that software object is actually downloaded to or otherwise implemented within the process control system 112 or the safety system 114 in an online manner.
- the software object approval routine 181 is tightly integrated with the safety instrumented system (or the process control system) and, as a result, the approval routine 181 may utilize the safety instrumented system's security. Still further, because the approval routine 181 is in the same environment as the process control or safety system design or configuration software 180, reviewers may use the same tools to review the software object being approved as were used to develop it. As such, there are no issues with respect to the accuracy of the software object being reviewed. Furthermore, the approval routine 181 prevents software objects that require approval from being downloaded to the control or safety environment until all of the required approvals are in place. As such, the process control or the safety instrumented system is able to guarantee that only approved software objects are executed.
- the approval routine 181 may include (e.g., store) a security key that provides the ability for users who have this key to override the enforcement of this requirement and download an unapproved software object.
- the approval routine 181 may detect changes being made to software objects and may cause any modifications that are made to an approved software object to result in the version number of the software object being incremented. Furthermore, when the version number of the software object is incremented, the state of the software object is automatically changed by the approval routine 181 to an unapproved state. As a result, the new version of the software object cannot be downloaded or otherwise implemented in the process control system until all approvals have been re-executed on this new version of the software object.
- the approval routine 181 may log all approvals and/or rejections of a particular software object into a configuration audit trail associated with the software object. As a result of these features, the validation of the software object occurs as an integral part of the process control or the safety instrumented system validation.
- Fig. 5 A illustrates a flowchart 185 showing steps that may be implemented by the approval routine 181 using the same or different software routines to provide approval functions within the process control and/or safety system.
- the approval routine 181 monitors the software design application (e.g., the configuration routine 180) or the configuration database to determine when and if a change is being made to any software objects.
- the block (or routine) 186 may determine that a change is being made to a software object by detecting alterations of an existing software object, the creation of a new software object, or even by receiving a request for the implementation of the approval process by, for example, a software object designer.
- the block 186 may wait to implement the approval process until all changes have been made to the software object as indicated by, for example, the software designer selecting a button in the design application indicating that the changes are complete.
- a block 187 may automatically, or at the prompting of a designer, institute an approval procedure.
- a block 188 may determine a group of entities (which may include one or more persons) and, as part of this process, may determine the number and types (such as job position) of signatures required for the approval based on information provided by a user or otherwise provided during configuration of the process control or the safety system.
- the block 188. may use the risk reduction factor (RRF) entered by a user or configuration engineer (such as the safety system configuration engineer) to determine the types and numbers of approvals needed.
- RRF risk reduction factor
- the user may enter the desired RRF to be achieved for a particular function or software object and the block 188 uses this RRF to determine the required SIL level.
- the block 188 may then, using for example a look-up table, use the SIL level to determine the nature of signatures required (e.g., the number of signatures, whether the signatures must come from the same or from different departments, the level or type of the job or position held by the reviewer, etc.)
- SIL level determines the nature of signatures required (e.g., the number of signatures, whether the signatures must come from the same or from different departments, the level or type of the job or position held by the reviewer, etc.)
- each particular safety instrumented function has a SIL associated therewith and, thus, a particular SIL is specific to a safety instrumented function and may change from safety function to safety function.
- a block 189 next determines the actual persons to whom to actually route the software object for approval. If desired, the names, electronic addresses or other electronic contact information for the reviewers within the selected group may be obtained from a corresponding look-up table. Additionally or alternatively, the group of reviewers and the associated electronic contact information may obtained from the configuration engineer directly, from the person making the change to the software object or from any other appropriate person via a display terminal. As part of this process, the block 189 may assess a stored a list of possible names or offices (and associated electronic addresses, etc.) and select from that list in any desired or predetermined manner, either with or without the aid of the software object designer. Alternatively, the block 189 may prompt some oversight person via a user interface to select the particular person(s) matching the required levels and departments for the approval process.
- a block 190 then electronically routes the created or modified software object to the selected reviewers and waits for the messages back from the reviewers as to whether the created or modified software object is approved or not.
- a block 191 may monitor responses from the reviewers to determine when (and if) all of the approvals have received, and, if all the reviewers (or a predetermined number of reviewers) approve the modified software object, a block 192 may mark the software object as capable of being downloaded. However, if responses from all of the reviewers have not been received, or if one of the reviewers has rejected the software object, the approval routine 181 will not mark the software object for downloading, thereby preventing that software object from being used in the process control or the safety system.
- the approval routine 181 may loop until all responses have been received and provide the responses to the designer or user in any desired manner. If the block 191 determines that a particular number of rejections are received, the block 193 may mark the software object as requiring modification or re-submittal to the approvers to thereby enable the software object to be downloaded.
- any or each of the blocks in the approval routine 181 may log the changes to the software object, the collection of approvals and rejections associated ⁇ with the software object and any other information about the approval process in the configuration database or the audit trail associated with the software object. Still further, the approval routine 185 may track and, if desired, display to the designer (or even to the other reviewers) information pertaining to the state of the reviewing process, such as the identity of the reviewers, which of the reviewers has responded, which have accepted and/or which have rejected the new or modified software module, etc. If desired, the block 191 may send reminders to reviewers that have not responded.
- the approval routine 185 may use the RRF in an on-line manner, i.e., during operation of the process control or the safety system in which the software object resides, to determine whether the safety function or operation associated with the software object is still meeting its design criteria.
- a configurer may determine which element of the safety function needs to be tested periodically, what the test period should be and how this testing impacts the overall RRF for the safety function. These details are typically determined at design time and thus are known to the configurer when implementing the function.
- an on-line monitoring portion 194 of the approval routine includes a block 195 that monitors the testing of the elements.
- a block 197 determines the actual RRF that is being achieved (based on the failure to perform the safety function test) and displays this modified RRF to a user, such as a safety system monitor or operator.
- a block 198 may also compare this modified RRF to the target RRF and generate an alarm when the target RRF is no longer being met.
- a block 199 may use the information in the SLL to automatically generate a work order (specifying, for example, a test to be run) prior to the test interval or after the test interval has been exceeded so as to maintain the RRF at or above its design target value or to return the RRF to its design level as quickly as possible.
- a single approval routine 18 is illustrated in Fig. 1 and a single approval routine 181 is illustrated in Fig. 4, components of these routines may be stored in other computers or workstations so that the reviewers may be located at different workstations than the designer.
- similar or complementary software would be installed in each of a set of reviewer terminals (such as the reviewer terminals 32 illustrated in Fig. 1) communicatively connected to design terminal to enable the reviewers to receive approval messages from the routine 18 or 181 at the design terminal, to invoke software in the process control or safety system for analyzing the software object to be reviewed and for responding with an approval or a rejection and any comments that the reviewer might want to make.
- the approval routines 18 or 181 may have any number of components that perform different functions, such as . selecting reviewers, modifying software objects, etc. While some of these components will be discussed in more detail in conjunction with Figs. 6-20, it will be understood that other routines could be associated with the approval or design routines. instead or in addition. Furthermore, while a number of subroutines are discussed in Figs. 6-20 with respect to the approval of a recipe used in a process control system, it will be understood that these routines could be used for approving other software objects as well, such as software objects in a safety system.
- a recipe editor routine 400 which may be executed by one or more of the processors 21 of the workstations 14, begins execution at block 402, at which a user or operator creates or modifies a recipe, which may include modification of the software objects associated therewith, for use in the process control system 10.
- a user may create or modify recipes or other software objects using techniques described in conjunction with Figs. 1-5 or using any other suitable techniques.
- control passes from block 402 to block 406.
- an authorization setup routine 404 (Fig.
- authorization setup may include, but is not limited to, specifying persons or entities (e.g., signers) from which approval is needed to implement a recipe or other software object, or deleting or modifying signers.
- approval is solicited from each of the signers specified during hail the authorization setup for approving the recipe created or modified at block 402..
- Approval solicitation may include, but is not limited to, sending electronic mail to the signers that are specified to review the recipe in connection with the authorization setup routine 404, running a report that indicates approval status for each of the specified signers, sending an instant message to the signers that are to review the recipe or sending notification to the signers via any other suitable communication method.
- the recipe editor routine 400 ends execution or returns control to another routine that called the recipe editor routine 400.
- FIG. 7 Further detail of the authorization setup routine 404 is provided in conjunction with Figs. 7 and 8, which respectively disclose a flow diagram and a user interface screen for the authorization setup routine 404. While the authorization setup routine 404 is typically executed once at system startup, the authorization setup routine 404 could, instead, be executed more than once if desired. In general, as shown in Fig. 7, once the authorization setup routine 404 has been executed, a user may opt to cancel execution of the routine at cancel/ok block 410. Alternatively, the user may opt to add, delete or modify recipe signers at blocks 412, 414 or 416, respectively.
- a user interface 420 includes a recipe authorization setup tab 422, which allows a user to select interface buttons 424, 426 or 428 to add, modify or delete signers.
- the add, modify and delete interface buttons 424-428 correspond to (and may be selected to invoke the functions performed by) the add, delete and modify blocks 412-416 shown in Fig. 7. Further details on each of the blocks 412-416 and, by implication, the interface buttons 424-428 are provided in conjunction with Figs. 9-13.
- signers are added, modified or deleted, the status of the signers is shown in a text box 430. As illustrated in Fig.
- the text box 430 includes a signer description column 432 that lists the names of the signers, which may be the names of persons or entities, and also includes a function lock column 434 listing the function locks that corresponding signers are required to have, thereby controlling access to an approval.
- the recipe is to be reviewed and signed off on by engineering, production and quality assurance, which correspond to function locks of REC1PE_ APPRO VAL_01.
- Fig. 8 Also shown in Fig. 8 are two check boxes 436 and 438, which correspond to enable recipe authorization and allow approval propagation to contained recipes (i.e., sub-recipes).
- the check box 436 when the check box 436 is checked, the enable recipe authorization features of the system are enabled and the authorization setup process is enabled.
- the checkbox 438 when unchecked, indicates that the user will not have the option to propagate approvals. Conversely, if the checkbox 438 is checked, the user will have the option of propagating approvals for sub-recipes.
- a main recipe may be composed of or may contain two or more sub-recipes to which an approval associated with the main recipe may be automatically propagated.
- such automatic propagation of approvals for recipes may result in a significant time savings, particularly for recipes that include a large number of sub-recipes.
- the user interface 420 also includes cancel and ok interface buttons, which are denoted by reference numerals 440 and 442, respectively.
- the interface buttons 440 and 442 correspond to the cancel/ok block 410 of Fig. 7 and allow a user to exit the authorization setup routine 404. While both interface buttons 440 and 442 enable a user to exit the authorization setup routine 404, the cancel interface button 440 ends the authorization setup routine 404 without including the changes made to the recipe authorization setup. Conversely, the ok interface button 442 allows the user to exit the authorization setup routine 404 and preserves the changes made to the authorization setup while using the user interface 420.
- the add routine 412 begins execution at block 450, which receives the function lock selection provided by the user.
- a graphical user interface or popup window 452 may include an approval function lock box 454 into which a user may input the name of the approval function lock.
- the box 454 may include an indication that the selection approval function lock is RECTPE_APPROVAL_03.
- block 460 receives a signer description provided by the user.
- the user may input a signer description in a block 462.
- the description "Team Leader” is shown in block 462, which indicates that the user desires to add team leader as a signer having an approval function lock of RECffE_APPROVAL_03.
- actuation of the cancel interface button 470 causes the add routine 412 to end its execution without saving changes made during the execution thereof.
- actuation of the ok interface button 472 causes the add routine 412 to end and save changes made during the execution of the add routine 412. If a new approver or signer is added by the add routine 412, any previously approved recipes (i.e., recipes for which all originally required approvals have been received) automatically become unauthorized until approval from the newly added signer is obtained.
- the delete routine 414 begins execution at block 480, which receives the selection of the signer description to be deleted.
- the user may provide such a selection by selecting a signer description shown in the text box 430 of the user interface 420 of Fig. 8.
- the user then actuates the delete interface button 428 to declare his or her intention to delete the selected signer description or signer.
- block 480 completes execution, control passes to block 482, which receives confirmation for the deletion requested by the user.
- the delete routine 414 may request the user to confirm his or her desire to delete the selected signer description via a user interface graphic presented to the user on a display screen.
- a user interface graphic presented to the user on a display screen.
- Such a graphic may include ok or cancel interface buttons, wherein the actuation (e.g., selection via a mouse, keyboard, etc.) of the ok interface button would confirm the user's desire to delete the selected signer description and the cancel interface button would abort the deletion of the selected description.
- the delete routine 414 ends its execution and returns control to the authorization setup routine 404.
- the modify routine 416 begins execution at block 484, which receives from the user a selection of the signer description to modify. For example, the user may select the signer named Quality Assurance in Fig. 8 and may then actuate the modify interface button 426. After actuation of the modify interface button 426, a user interface such as, for example, a user interface 486 shown in Fig. 13, may be presented to the user and may include a signer description box 488 and an approval function lock box 490. The user interface 486 may also include ok and cancel interface buttons 492 and 494.
- the block 496 receives signer description modifications, such as, for example, changes in the signer name, approval lock function or any other suitable changes.
- signer description modifications such as, for example, changes in the signer name, approval lock function or any other suitable changes.
- the user may modify the name of the signer or may modify the approval lock function displayed in block 490 and may select either of the ok or cancel interface buttons 492 and 494.
- actuation of the ok interface button 492 saves the modifications made to the signer description.
- actuation of the cancel interface button 494 ends the modify routine 416 without saving changes made.
- actuation of either of the interface buttons 492 and 494 ends the execution of the modify routine 416 and returns control to the authorization setup routine 404 of Fig. 7.
- modification of a signer or approver automatically results in any previously approved recipe requiring that signer's approval to become unauthorized.
- routines or routines embodying the functionality described in connection with these routines may be implemented within any of the workstations 14 and/or terminals 32 of Fig. 1 or with any of the workstations 116 of Fig. 4.
- Figs. 14-18 pertain to the review, approval or rejection processes that may be carried out by signers.
- the routines and user interfaces shown in Figs. 14-18 may be implemented on the terminals 32 and/or the workstations 14 of Fig. 1 or on any of the workstations 116 of Fig. 4.
- the one or more of the memories 20 and 34 may store instructions that may be executed by one or more of the processors 21 and 36 to carry out operations representative of the blocks in the routines.
- a recipe authorization routine 500 begins execution at block 502, which displays signer and status information pertinent to the recipe being reviewed.
- a user interface 504 of Fig. 15 may include a text box 506 having a number of columns 508-518 that may represent signer identity, status, user type, time, comment and node.
- the signer column 508 lists the signatures required for approval of the recipe and the status column 510 lists the state of the signature for each signer. For example, signature status may be blank or pending, approved or rejected, wherein a blank status or pending status may represent that the signer has not reviewed the recipe.
- the user column 512 lists the user type responsible for the most recent signature change.
- the time column 514 lists the time at which most recent change of the signature was made.
- the comment column 516 lists any comments made by the signer when they approved or rejected the recipe and the node 518 represents the systems node at which the signer approved or rejected the recipe.
- the node may be any one of the terminals 32 and/or the workstations 14 of Fig. 1 or the workstations 116 of Fig. 4.
- the user interface 504 may include close, approve, reject and clear interface buttons 520-526, which will be described in conjunction with the recipe authorization routine 500 of Fig. 14,
- block 530 receives the signer selection, which may be manifest by the user by selecting any of interface . buttons 520-526.
- control of the recipe authorization routine 500 passes from block 530 to block 540, which closes the user interface 504, ends execution of the recipe authorization routine 500 and returns control to any routine that called the recipe authorization routine 500.
- the approve routine 550 begins execution at block 552, which receives a user name and password that are provided by the user.
- a user interface 554, an example of which is shown in Fig. 17, may include user name and password boxes 556 and 558 into which the user may enter their user name and password.
- the user interface 554 of Fig. 17 may include a text box 562 into which comments may be keyed.
- block 561 determines if the user is authorized. The authorization check performed at block 561 may verify that the user name and/or password received at block 552 are valid and/or whether the user associated with that user name and password is authorized to make such an approval. If it is determined at block 561 that the user is authorized, then control passes to block 566. Block 566 updates the status information to reflect approval.
- the text box 562 includes the text comments "This one is ready for production," which is also reflected in Fig. 15 as the comment made by the production signer when approving the recipe after the execution of block 566. If it is determined at block 561 that either or both of the user name and password received at block 552 are not authorized, then the approve routine 550 ends.
- the user interface 554 of Fig. 17 includes ok and cancel interface b ' uttons 568 and 570, which may be used to end execution of the approve routine 550 while either saving or discarding the changes made during the execution of the routine. Additionally, as shown in Fig. 17, a check box 572 may be provided to enable a user to opt to propagate the approval to any contained or sub-recipes.
- Block 580 represents a reject routine, further details of which may be found in Fig. 18.
- execution of the reject routine 580 begins at block 582 where the user inputs a user name and a password before control passes to block 584.
- a signer may input comments made during the process of rejecting the recipe.
- the operations of blocks 582 and 584 are similar to the operations of blocks 552 and 560 of the approve routine 550 shown in Fig. 16, except that blocks 582 and 584 are used in conjunction with rejecting the recipe.
- block 585 performs an authorization check similar to that performed at block 561 shown in Fig. 17. If it is determined that a user is authorized at block 585, then control passes to block 586.
- Block 586 updates status information to reflect rejection of the recipe by the user.
- the update status information block 586 may generate information; that would be reflected on the user interface 504 of Fig. 15 to reflect the fact that a signer has rejected a recipe.
- the reject routine 580 may also employ a graphical user interface similar to the user interface 554 of Fig. 17, which is used to approve recipes.
- the block 590 may be used to clear a. signature.
- one of the signers shown in Fig. 15 may be selected by a user and cleared using the interface button 526.
- the controller 12 (Fig. 1) or the workstation 14 (Fig. 1) the effect of an approval signature cannot be retracted.
- a signature i.e., an approval
- a user interface 600 may be used to report the status of recipes within the process control system 10.
- the user interface 600 may include a number of columns 602-610, which respectively represent recipe name, production, engineering, quality assurance and team leader.
- the recipe name column 602 lists all of the unapproved recipes and columns 604-610 list the status of each recipe with each reviewer or reviewing entity.
- the recipe named "OP_CHARGE” is pending with each of production, engineering, quality assurance and team leader.
- each of production, engineering, quality assurance and team leader have approved the "PRC_PATNT" recipe, but the same has not been approved by quality assurance.
- the user interface 600 may also include close and print interface buttons 612 and 614, which may be used to close the user interface 600 or to print the user interface 600 to show the information contained in the columns 602-610.
- the recipe maybe downloaded to or implemented within one or more of the controllers 12, which are shown in Fig. 1 or the controllers 176 of Fig. 4 or (or other software objects may be downloaded to the safety logic modules 150-156 of Fig. 4 or any of the field devices to which these objects may need to be downloaded).
- a download routine 630 as shown in Fig. 20, is one method by which downloading may be carried out. The download routine 630 begins execution at block 632, which generates a download script.
- Version control software such as the software disclosed in U.S. Patent No. 6,449,624 may be used in connection with the download routine 630. If block 634 determines that the recipe is checked out and the key has not been provided, control passes to block 636, which cancels the download and ends execution of the download routine 630.
- Recipe authorization may include, but is not limited to, insuring that all signers have approved the recipe. If block 638 determines that the recipe is not authorized and the key has not been provided, control passes to block 636, which cancels the download before ending the download routine 630. In the alternative, if block 638 determines that the recipe is authorized or if the key has been provided, control passes to block 640, which sets a download label.
- the download label may be one or more comment statements or other similar textual information appended to the downloaded item(s) that includes the time, date, version and initiator (or user) of the download. Additionally, the download label includes a detailed list of the individual items (e.g., recipes) being downloaded.
- the recipe is then sent to the runtime system, which may be embodied in for example, the controllers 12 of Fig. 1, at block 642. After the execution of block 642, the download routine 630 ends execution and returns control to the routine that called the download routine 630.
- a software object that is currently not approved cannot be downloaded or implemented by the process control or safety system until all signers or approvers associated with that software object have approved the software object.
- a new software object or recipe for example, must be approved by a predetermined list or group of persons and/or other entities (e.g., a list of persons and/or other entities generated by the authorization setup routine 404 (Fig. 7).
- a previously approved software object or recipe that is modified automatically becomes unauthorized and, thus, must be re- approved by all of its corresponding signers or authorizers to download the modified software object or recipe as shown by example at blocks 638 and 640 of Fig. 20.
Abstract
Description
Claims
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE112004001716.5T DE112004001716B4 (en) | 2003-09-19 | 2004-01-16 | Method for releasing software objects for use in a safety-related system and release system for software objects for use in a process control system with a processor |
JP2006526859A JP4672663B2 (en) | 2003-09-19 | 2004-01-16 | Integrated digital signature for process control and safety system software object approval |
GB0604560A GB2421332A (en) | 2003-09-19 | 2004-01-16 | Integrated electronic signatures for approval of process control and safety system software objects |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/666,446 | 2003-09-19 | ||
US10/666,446 US7076312B2 (en) | 2002-08-02 | 2003-09-19 | Integrated electronic signatures for approval of process control and safety system software objects |
Publications (2)
Publication Number | Publication Date |
---|---|
WO2005038544A2 true WO2005038544A2 (en) | 2005-04-28 |
WO2005038544A3 WO2005038544A3 (en) | 2005-09-15 |
Family
ID=34465426
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2004/001205 WO2005038544A2 (en) | 2003-09-19 | 2004-01-16 | Integrated electronic signatures for approval of process control and safety system software objects |
Country Status (6)
Country | Link |
---|---|
US (1) | US7076312B2 (en) |
JP (1) | JP4672663B2 (en) |
CN (1) | CN1846206A (en) |
DE (1) | DE112004001716B4 (en) |
GB (1) | GB2421332A (en) |
WO (1) | WO2005038544A2 (en) |
Families Citing this family (76)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8006280B1 (en) | 2001-12-12 | 2011-08-23 | Hildebrand Hal S | Security system for generating keys from access rules in a decentralized manner and methods therefor |
US7930756B1 (en) | 2001-12-12 | 2011-04-19 | Crocker Steven Toye | Multi-level cryptographic transformations for securing digital assets |
US10033700B2 (en) | 2001-12-12 | 2018-07-24 | Intellectual Ventures I Llc | Dynamic evaluation of access rights |
US7921284B1 (en) | 2001-12-12 | 2011-04-05 | Gary Mark Kinghorn | Method and system for protecting electronic data in enterprise environment |
US7921288B1 (en) | 2001-12-12 | 2011-04-05 | Hildebrand Hal S | System and method for providing different levels of key security for controlling access to secured items |
US7380120B1 (en) | 2001-12-12 | 2008-05-27 | Guardian Data Storage, Llc | Secured data format for access control |
USRE41546E1 (en) | 2001-12-12 | 2010-08-17 | Klimenty Vainstein | Method and system for managing security tiers |
US10360545B2 (en) | 2001-12-12 | 2019-07-23 | Guardian Data Storage, Llc | Method and apparatus for accessing secured electronic data off-line |
US7921450B1 (en) | 2001-12-12 | 2011-04-05 | Klimenty Vainstein | Security system using indirect key generation from access rules and methods therefor |
US7783765B2 (en) | 2001-12-12 | 2010-08-24 | Hildebrand Hal S | System and method for providing distributed access control to secured documents |
US8065713B1 (en) | 2001-12-12 | 2011-11-22 | Klimenty Vainstein | System and method for providing multi-location access management to secured items |
US7260555B2 (en) | 2001-12-12 | 2007-08-21 | Guardian Data Storage, Llc | Method and architecture for providing pervasive security to digital assets |
US7565683B1 (en) | 2001-12-12 | 2009-07-21 | Weiqing Huang | Method and system for implementing changes to security policies in a distributed security system |
US7681034B1 (en) | 2001-12-12 | 2010-03-16 | Chang-Ping Lee | Method and apparatus for securing electronic data |
US7178033B1 (en) | 2001-12-12 | 2007-02-13 | Pss Systems, Inc. | Method and apparatus for securing digital assets |
US7950066B1 (en) | 2001-12-21 | 2011-05-24 | Guardian Data Storage, Llc | Method and system for restricting use of a clipboard application |
US8176334B2 (en) | 2002-09-30 | 2012-05-08 | Guardian Data Storage, Llc | Document security system that permits external users to gain access to secured files |
US8613102B2 (en) | 2004-03-30 | 2013-12-17 | Intellectual Ventures I Llc | Method and system for providing document retention using cryptography |
US7512810B1 (en) | 2002-09-11 | 2009-03-31 | Guardian Data Storage Llc | Method and system for protecting encrypted files transmitted over a network |
US7836310B1 (en) | 2002-11-01 | 2010-11-16 | Yevgeniy Gutnik | Security system that uses indirect password-based encryption |
US7890990B1 (en) | 2002-12-20 | 2011-02-15 | Klimenty Vainstein | Security system with staging capabilities |
US7865251B2 (en) * | 2003-01-28 | 2011-01-04 | Fisher-Rosemount Systems, Inc. | Method for intercontroller communications in a safety instrumented system or a process control system |
US7275062B2 (en) * | 2003-03-10 | 2007-09-25 | Fisher-Rosemount Systems, Inc. | Automatic linkage of process event data to a data historian |
US8707034B1 (en) | 2003-05-30 | 2014-04-22 | Intellectual Ventures I Llc | Method and system for using remote headers to secure electronic files |
US7133727B2 (en) * | 2003-08-01 | 2006-11-07 | Invensys Systems, Inc. | System and method for continuous online safety and reliability monitoring |
US7117119B2 (en) * | 2003-08-01 | 2006-10-03 | Invensys Systems, Inc | System and method for continuous online safety and reliability monitoring |
US8127366B2 (en) | 2003-09-30 | 2012-02-28 | Guardian Data Storage, Llc | Method and apparatus for transitioning between states of security policies used to secure electronic documents |
US7703140B2 (en) | 2003-09-30 | 2010-04-20 | Guardian Data Storage, Llc | Method and system for securing digital assets using process-driven security policies |
US7519826B2 (en) * | 2003-10-01 | 2009-04-14 | Engedi Technologies, Inc. | Near real-time multi-party task authorization access control |
US20050138402A1 (en) * | 2003-12-23 | 2005-06-23 | Yoon Jeonghee M. | Methods and apparatus for hierarchical system validation |
US7444197B2 (en) | 2004-05-06 | 2008-10-28 | Smp Logic Systems Llc | Methods, systems, and software program for validation and monitoring of pharmaceutical manufacturing processes |
US7799273B2 (en) | 2004-05-06 | 2010-09-21 | Smp Logic Systems Llc | Manufacturing execution system for validation, quality and risk assessment and monitoring of pharmaceutical manufacturing processes |
US7707427B1 (en) | 2004-07-19 | 2010-04-27 | Michael Frederick Kenrich | Multi-level file digests |
US20060036412A1 (en) * | 2004-08-15 | 2006-02-16 | Hiromichi Takatsuka | Check indicator for computer-aided drafting (CAD) |
US20060059455A1 (en) * | 2004-09-14 | 2006-03-16 | Roth Steven T | Software development with review enforcement |
US7958360B2 (en) * | 2005-05-12 | 2011-06-07 | Microsoft Corporation | Method and system for performing an electronic signature approval process |
US7720704B2 (en) * | 2005-05-12 | 2010-05-18 | Microsoft Corporation | Enterprise resource planning system and method for managing route transactions |
US7849101B2 (en) * | 2005-05-12 | 2010-12-07 | Microsoft Corporation | Method and system for enabling an electronic signature approval process |
US20060282350A1 (en) * | 2005-05-12 | 2006-12-14 | Microsoft Corporation | Enterprise resource planning system and method for managing bill of material transactions |
US20070179638A1 (en) * | 2006-01-31 | 2007-08-02 | Alexander Dreiling | Process configuration tool |
US8046588B2 (en) * | 2006-02-23 | 2011-10-25 | Rockwell Automation Technologies, Inc. | Audit trail in a programmable safety instrumented system via biometric signature(s) |
EP1855172A1 (en) * | 2006-05-12 | 2007-11-14 | Siemens Aktiengesellschaft | Method for alarm suppression in a plant |
US8392008B2 (en) | 2006-10-20 | 2013-03-05 | Rockwell Automation Technologies, Inc. | Module arbitration and ownership enhancements |
US8601435B2 (en) * | 2006-10-20 | 2013-12-03 | Rockwell Automation Technologies, Inc. | Module class subsets for industrial control |
US7676292B2 (en) | 2006-10-20 | 2010-03-09 | Rockwell Automation Technologies, Inc. | Patterns employed for module design |
US7844349B2 (en) | 2006-10-20 | 2010-11-30 | Rockwell Automation Technologies, Inc. | Standard MES interface for discrete manufacturing |
US7684877B2 (en) | 2006-10-20 | 2010-03-23 | Rockwell Automation Technologies, Inc. | State propagation for modules |
US7725200B2 (en) * | 2006-10-20 | 2010-05-25 | Rockwell Automation Technologies, Inc. | Validation of configuration settings in an industrial process |
US7894917B2 (en) * | 2006-10-20 | 2011-02-22 | Rockwell Automation Technologies, Inc. | Automatic fault tuning |
US7680550B2 (en) | 2006-10-20 | 2010-03-16 | Rockwell Automation Technologies, Inc. | Unit module state processing enhancements |
US8694895B2 (en) * | 2007-02-05 | 2014-04-08 | Microsoft Corporation | Human interaction with application from email client |
US20080263162A1 (en) * | 2007-04-20 | 2008-10-23 | Microsoft Corporation | Modeling User-Initiated Requests and Status Updates Within an Email Message |
US20090012631A1 (en) * | 2007-07-03 | 2009-01-08 | Dale Fuller | Automation safety life cycle |
US8074278B2 (en) * | 2007-09-14 | 2011-12-06 | Fisher-Rosemount Systems, Inc. | Apparatus and methods for intrusion protection in safety instrumented process control systems |
US8825189B2 (en) * | 2007-11-13 | 2014-09-02 | Fisher Rosemount Systems, Inc. | Methods and apparatus to execute an auxiliary recipe and a batch recipe associated with a process control system |
US8463964B2 (en) * | 2009-05-29 | 2013-06-11 | Invensys Systems, Inc. | Methods and apparatus for control configuration with enhanced change-tracking |
US9146735B2 (en) * | 2009-07-23 | 2015-09-29 | International Business Machines Corporation | Associating workflows with code sections in a document control system |
US10164922B2 (en) | 2010-09-27 | 2018-12-25 | International Business Machines Corporation | Secure electronic message conveyance |
US9619779B2 (en) * | 2011-08-26 | 2017-04-11 | Apple Inc. | Client-side policy enforcement of developer API use |
WO2013071117A1 (en) * | 2011-11-10 | 2013-05-16 | Tennessee Valley Authority | Method and automation system for processing information extractable from an engineering drawing file using information modeling and correlations to generate output data |
US9338008B1 (en) | 2012-04-02 | 2016-05-10 | Cloudera, Inc. | System and method for secure release of secret information over a network |
DE102012112835A1 (en) * | 2012-12-21 | 2014-06-26 | Robert Bosch Gmbh | System with a central license management unit and a tool device |
CN110490458A (en) * | 2013-03-20 | 2019-11-22 | 生活时间品牌公司 | A kind of moving mass control inspection system |
US9292263B2 (en) * | 2013-04-15 | 2016-03-22 | Massively Parallel Technologies, Inc. | System and method for embedding symbols within a visual representation of a software design to indicate completeness |
EP2932378A4 (en) * | 2013-04-29 | 2016-08-31 | Hewlett Packard Entpr Dev Lp | Recording unstructured events in context |
US9934382B2 (en) | 2013-10-28 | 2018-04-03 | Cloudera, Inc. | Virtual machine image encryption |
JP6283638B2 (en) * | 2015-09-16 | 2018-02-21 | 横河電機株式会社 | Light measuring device |
US10097557B2 (en) * | 2015-10-01 | 2018-10-09 | Lam Research Corporation | Virtual collaboration systems and methods |
EP3264208B1 (en) * | 2016-06-30 | 2021-01-06 | Siemens Aktiengesellschaft | Method for updating process objects in an engineering system |
HRP20221507T1 (en) * | 2016-11-04 | 2023-02-17 | Thales Management & Services Deutschland Gmbh | Method for enforcing an authorization, method for evaluation of an authorization, use of a component framework for controlling a safety critical process and computer program product |
DE102018103772A1 (en) * | 2018-02-20 | 2019-08-22 | Dekra Exam Gmbh | Monitoring system for a protective device and protective device |
EP3803296A4 (en) | 2018-05-28 | 2022-03-09 | Takeda Pharmaceutical Company Limited | Systems and methods for automated tracking and optimization of global manufacturing and supply based on impacts of post-approval changes |
WO2020158247A1 (en) * | 2019-01-28 | 2020-08-06 | オムロン株式会社 | Safety system and maintenance method |
JP7127585B2 (en) * | 2019-03-12 | 2022-08-30 | オムロン株式会社 | Safety system and maintenance method |
IL297442A (en) | 2020-04-22 | 2022-12-01 | Iovance Biotherapeutics Inc | Systems and methods for coordinating manufacturing of cells for patient-specific immunotherapy |
US11424865B2 (en) | 2020-12-10 | 2022-08-23 | Fisher-Rosemount Systems, Inc. | Variable-level integrity checks for communications in process control environments |
Family Cites Families (31)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4827423A (en) | 1987-01-20 | 1989-05-02 | R. J. Reynolds Tobacco Company | Computer integrated manufacturing system |
JPH01160158A (en) * | 1987-12-17 | 1989-06-23 | Murata Mach Ltd | Mechanical control system at remote location |
SE513182C2 (en) | 1991-06-12 | 2000-07-24 | Icl Systems Ab | Procedure and system for auditing data in a distributed computer system |
JPH0535460A (en) * | 1991-07-31 | 1993-02-12 | Toshiba Corp | Software controller |
US5339430A (en) * | 1992-07-01 | 1994-08-16 | Telefonaktiebolaget L M Ericsson | System for dynamic run-time binding of software modules in a computer system |
US5649200A (en) | 1993-01-08 | 1997-07-15 | Atria Software, Inc. | Dynamic rule-based version control system |
JPH07146787A (en) * | 1993-11-24 | 1995-06-06 | Hitachi Ltd | Method for retrieving influence program |
US6038586A (en) | 1993-12-30 | 2000-03-14 | Frye; Russell | Automated software updating and distribution |
US5546301A (en) | 1994-07-19 | 1996-08-13 | Honeywell Inc. | Advanced equipment control system |
US5940294A (en) | 1996-04-12 | 1999-08-17 | Fisher-Rosemont Systems, Inc. | System for assisting configuring a process control environment |
US5838563A (en) | 1996-04-12 | 1998-11-17 | Fisher-Rosemont Systems, Inc. | System for configuring a process control environment |
US5768119A (en) | 1996-04-12 | 1998-06-16 | Fisher-Rosemount Systems, Inc. | Process control system including alarm priority adjustment |
JP3873365B2 (en) * | 1996-05-15 | 2007-01-24 | 株式会社日立製作所 | Business processing system using bulletin board type database and processing method thereof |
DE19634341A1 (en) | 1996-08-24 | 1998-02-26 | Bosch Gmbh Robert | Method for protecting programmable controllers from overwriting |
US5904294A (en) * | 1996-09-13 | 1999-05-18 | Nordson Corporation | Particle spray apparatus and method |
US6385494B1 (en) | 1996-09-30 | 2002-05-07 | Caterpillar Inc. | System and method for producing production control software |
US5950209A (en) | 1996-10-02 | 1999-09-07 | Alcatel Usa Sourcing, L.P. | Software release control system and method |
US5907705A (en) * | 1996-10-31 | 1999-05-25 | Sun Microsystems, Inc. | Computer implemented request to integrate (RTI) system for managing change control in software release stream |
US5903897A (en) | 1996-12-18 | 1999-05-11 | Alcatel Usa Sourcing, L.P. | Software documentation release control system |
US6381698B1 (en) * | 1997-05-21 | 2002-04-30 | At&T Corp | System and method for providing assurance to a host that a piece of software possesses a particular property |
JPH11272777A (en) * | 1998-03-20 | 1999-10-08 | Nippon Telegr & Teleph Corp <Ntt> | Electronic approving processor and medium for recording electronic approving processing program |
US6385496B1 (en) * | 1999-03-12 | 2002-05-07 | Fisher-Rosemount Systems, Inc. | Indirect referencing in process control routines |
US6584466B1 (en) * | 1999-04-07 | 2003-06-24 | Critical Path, Inc. | Internet document management system and methods |
US6445963B1 (en) | 1999-10-04 | 2002-09-03 | Fisher Rosemount Systems, Inc. | Integrated advanced control blocks in process control systems |
US6449624B1 (en) | 1999-10-18 | 2002-09-10 | Fisher-Rosemount Systems, Inc. | Version control and audit trail in a process control system |
EP1342170A4 (en) * | 1999-11-29 | 2006-01-25 | Interwoven Inc | Method and apparatus for deploying data among data destinations for website development and maintenance |
EP1323258A1 (en) * | 2000-09-14 | 2003-07-02 | Probix, Inc. | System for protecting objects distributed over a network |
US8671460B1 (en) * | 2000-09-25 | 2014-03-11 | Fisher-Rosemount Systems, Inc. | Operator lock-out in batch process control systems |
US6647315B1 (en) | 2000-09-29 | 2003-11-11 | Fisher-Rosemount Systems, Inc. | Use of remote soft phases in a process control system |
WO2003001339A2 (en) * | 2001-06-22 | 2003-01-03 | Wonderware Corporation | A security architecture for a process control platform executing applications |
US6928328B2 (en) * | 2002-08-02 | 2005-08-09 | Fisher-Rosemount Systems, Inc. | Integrated electronic signatures for approval of process control system software objects |
-
2003
- 2003-09-19 US US10/666,446 patent/US7076312B2/en not_active Expired - Lifetime
-
2004
- 2004-01-16 JP JP2006526859A patent/JP4672663B2/en not_active Expired - Lifetime
- 2004-01-16 WO PCT/US2004/001205 patent/WO2005038544A2/en active Application Filing
- 2004-01-16 DE DE112004001716.5T patent/DE112004001716B4/en not_active Expired - Lifetime
- 2004-01-16 GB GB0604560A patent/GB2421332A/en not_active Withdrawn
- 2004-01-16 CN CNA2004800253654A patent/CN1846206A/en active Pending
Non-Patent Citations (3)
Title |
---|
AMES C ET AL: "Applications of Web-based workflow" SYSTEM SCIENCES, 1998., PROCEEDINGS OF THE THIRTY-FIRST HAWAII INTERNATIONAL CONFERENCE ON KOHALA COAST, HI, USA 6-9 JAN. 1998, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, vol. 1, 6 January 1998 (1998-01-06), pages 79-87, XP010262903 ISBN: 0-8186-8255-8 * |
CHAN A K F ET AL: "Software configuration management tools" SOFTWARE TECHNOLOGY AND ENGINEERING PRACTICE, 1997. PROCEEDINGS., EIGHTH IEEE INTERNATIONAL WORKSHOP ON YINCORPORATING COMPUTER AIDED SOFTWARE ENGINEERING LONDON, UK 14-18 JULY 1997, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 14 July 1997 (1997-07-14), pages 238-250, XP010240916 ISBN: 0-8186-7840-2 * |
MERANT: "Change management capabilities" PVCS DIMENSIONS, [Online] 2001, pages 1-20, XP002325233 Retrieved from the Internet: URL:http://nsit.uchicago.edu/rpa/documents /configuration/Merant/change_mgnt_capabili ties.pdf> [retrieved on 2005-04-13] * |
Also Published As
Publication number | Publication date |
---|---|
JP2007518145A (en) | 2007-07-05 |
GB0604560D0 (en) | 2006-04-19 |
US20040243260A1 (en) | 2004-12-02 |
WO2005038544A3 (en) | 2005-09-15 |
DE112004001716B4 (en) | 2021-02-04 |
JP4672663B2 (en) | 2011-04-20 |
CN1846206A (en) | 2006-10-11 |
DE112004001716T5 (en) | 2006-10-19 |
GB2421332A (en) | 2006-06-21 |
US7076312B2 (en) | 2006-07-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7076312B2 (en) | Integrated electronic signatures for approval of process control and safety system software objects | |
US6928328B2 (en) | Integrated electronic signatures for approval of process control system software objects | |
US9164501B2 (en) | Methods and apparatus to manage data uploading in a process control environment | |
JP7389201B2 (en) | Quality review management system | |
EP3564881A1 (en) | Blockchain-enabled industrial devices | |
JP5173324B2 (en) | Monitoring system and monitoring method | |
JP6244083B2 (en) | Process control system, computer readable memory, and method | |
US7526347B2 (en) | Security for objects in a process plant configuration system | |
US6898468B2 (en) | Function block implementation of a cause and effect matrix for use in a process safety system | |
US7729792B2 (en) | Version control for objects in a process plant configuration system | |
JP2016201142A (en) | Method of generating product recipe | |
US10877466B2 (en) | Reconciliation of run-time and configuration discrepancies | |
CN108293074A (en) | For in Internet of Things(IOT)Distributed system architecture is used in edge instrument(DSA)Device and method | |
Summers | Inherently safer automation | |
Noureldin et al. | Using expert system and object technology for abnormal condition management | |
MAHAR et al. | INTERNATIONAL JOURNAL OF PHARMACEUTICAL RESEARCH AND BIO-SCIENCE |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
WWE | Wipo information: entry into national phase |
Ref document number: 200480025365.4 Country of ref document: CN |
|
AK | Designated states |
Kind code of ref document: A2 Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A2 Designated state(s): BW GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
WWE | Wipo information: entry into national phase |
Ref document number: 12006500262 Country of ref document: PH |
|
WWE | Wipo information: entry into national phase |
Ref document number: 0604560.3 Country of ref document: GB Ref document number: 0604560 Country of ref document: GB |
|
WWE | Wipo information: entry into national phase |
Ref document number: 1120040017165 Country of ref document: DE |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2006526859 Country of ref document: JP |
|
32PN | Ep: public notification in the ep bulletin as address of the adressee cannot be established |
Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 69(1) EPC |
|
122 | Ep: pct application non-entry in european phase |