Fisher-rosemount Systems, Inc

Sergio Diaz

Gary Keith Law

Deborah R Colclazier

Larry Oscar Jundt

Julian Kevin Naidoo

Kent Allan Burr

Daniel R Strinden

Neil J Peterson

Cristopher Ian S Uy

Godfrey Roland Sherriff

Mark J Nixon

Trevor Duncan Schleiss

Marcos Peluso

Scott Nels Hokeness

Claudio Fayad

Prashant Joshi

Techniques for physically removing and replacing a simplex I/O component include plant personnel placing the component into a 'REPLACEABLE' state via a user interface of the component. In response, the simplex I/O component informs the I/O subsystem thereof. The I/O subsystem stores a record of the component's REPLACEABLE state and begins to hold data values (e.g., field device values) most recently received from the component. When the I/O subsystem detects that the simplex I/O component is uncommunicative (e.g., due to being removed and replaced), based on the stored record of the “REPLACEABLE” state, the I/O subsystem retrieves the most recently received held data value and transmits it to a controller, thereby maintaining controlled (e.g., non-disruptive) execution of a control loop. When the replacement simplex I/O component initializes to an “IN-SERVICE” state, the I/O subsystem updates its state record accordingly, and resumes forwarding live field data values to the controller.

Apparatuses and methods for non-disruptive replacement of simplex I/O components

A two-wire routing device includes an upstream communication interface for communication with a controller, a two-wire communication and power interface configured to convey communication and power to a field device over a two-wire link, and a router electronic controller. The router electronic controller is coupled to the upstream communication interface and the two-wire communication and power interface. The router electronic controller receives, via the upstream communication interface, a safe state command from the controller, and transmits, via the two-wire communication and power interface, the safe state command to a field device over the two-wire link. The router electronic controller further executes a secondary de-energization scheme for the field device to control a power switch to cut power over the two-wire link to the field device.

Secondary control for de-energizing safety field devices with digital protocols

A cybersecurity system for use in a process plant provides whitelisting of device specific and common practice HART read commands in process controllers and safety controllers to perform communications in a process plant that are very secure, but that still enable the implementation of advanced functionality provided in HART devices. A whitelist implementation application applies one or more whitelists in a security gateway device to determine if messages, such as HART messages, should be allowed or processed. A whitelist learning application automatically creates and configures whitelists, and a whitelist configuration application discovers Device Specific and Common Practice HART commands by issuing device description requests to specific devices, parsing the response, and communicating the whitelist configuration information with the parsed command types to the relevant process controllers and safety controllers for use in the whitelists. A user interface enables users to interact with and guide the configuration process.

Whitelisting for HART communications in a process control system

Methods and apparatus to implement safety applications associated with process control systems are disclosed. An apparatus includes a configuration controller to: provide a plurality of available safety applications for implementation by a safety trip device to a user for selection, a first one of the safety applications associated with a first set of I/O signals, a second one of the safety applications associated with a second set of I/O signals, the first safety application implemented based on first pre-programmed instructions stored in memory of the safety trip device, the second safety application implemented based on second pre-programmed instructions stored in the memory; and, in response to a user selection of the first safety application, prompt the user to specify values for configuration settings associated with the first safety application. The apparatus also includes an I/O analyzer to implement the first safety application.

Methods and apparatus to implement safety applications associated with process control systems

A process control input/output (I/O) device provides traditional I/O support with direct physical layers or interfaces associated with traditional process control communication protocols while at the same time supporting an advanced physical layer or other IP based physical layer and the communication protocols that run on top of them. In addition, the new I/O device is able to nest protocols inside of other protocols for use when protocols, such as safety protocols, require additional handshaking, confirmations, etc. Still further, the new I/O device includes hardware configurable capabilities that enable easy configuration of a process control system that uses multiple different physical layers, including those used by traditional process control protocols such as HART and FOUNDATION Fieldbus protocols, and more advanced physical layers, including those that are used by IP-based, Ethernet based, packet based and other types of advanced communication protocols.

Integration of multiple communication physical layers and protocols in a process control input/output device

A system and method for enabling access to information included in a safety requirement specification (SRS) for a process plant, the process plant controlled by a process control system including displaying, in a user interface, a cause and effect matrix (CEM) having a set of elements including a set of causes and a set of effects, wherein each of the set of causes represents a condition within the process plant and each of the set of effects represents an effect to be performed within the process plant, and wherein at least some of the set of causes and the set of effects are related as cause-effect pairs whereby the corresponding effect activates in response to an occurrence of the corresponding condition. The system and method further including receiving, via the user interface, a selection of an element of the set of elements, and, in response to receiving the selection: (i) accessing, from the SRS, a set of information associated with the element of the set of elements, and (ii) displaying the set of information in the user interface.

System and method for providing interlinked user interfaces corresponding to safety logic of a process control system

Apparatus and methods for secure data logging are disclosed. An example method for secure data transfer from a process control system network includes storing information received by a process controller via the process control system network, the process controller including a safety instrumented system controller or a process control system controller, the information transferred uni-directionally from the process control system network to a data logger via a data diode, identifying a trigger event on the process control system network, in response to identifying the trigger event, parsing the stored information for event data, and transferring the event data from the data logger to a data extractor.

Apparatus and methods for secure data logging

A system and method for managing function blocks within a process control system for a process plant includes accessing an initial cause and effect matrix (CEM) having a set of causes and a set of effects. The system and method may then define a set of related groups within the initial CEM including: (i) accessing a set of rules associated with the set of related groups, (ii) identifying a portion of the set of causes that are related to a portion of the set of effects according to the set of rules and based on at least a portion of the corresponding cause-effect pairs, and (iii) rearranging the portion of the set of causes and the portion of the set of effects such that the portion of the corresponding cause-effect pairs are rearranged.

System and method for configuring separated monitor and effect blocks of a process control system

Disclosed herein are techniques for automatically distributing device identification amongst components of a process control loop in a process plant while the loop is communicatively disconnected from the plant's back-end environment or control room. A field device's identification is stored in a memory of a component of the loop (which may be the field device or a proxy) and is used for commissioning the field device. While the loop remains disconnected, the field device's identification is distributed to the memory of another component of the loop and used for commissioning a portion of the loop including the field device and the another component. Additional distribution to other components for commissioning other loop portions is possible. Distribution may be triggered by the completion of certain commissioning activities, the establishment of communicative connections between components, and/or other conditions. Other parameters and/or information descriptive of the field device may be similarly distributed.

Automatic distribution of device parameters for commissioning portions of a disconnected process control loop

An I/O-abstracted configuration is defined for a field device that has not yet been assigned or allocated to communicate via a particular I/O device or I/O network within a plant, and this configuration is stored in a device placeholder object in a back-end environment of the plant. Thereafter other objects, modules, applications, user interfaces, etc., that are to execute in the back-end environment of the plant to communicate with the field device during on-line operation of the plant may be designed, built, configured, and tested using the device placeholder object without any actual communications with the field device and without assigning the device placeholder object to a particular I/O channel or I/O network. A commissioning system which may create and store one or more device placeholder objects in a database within the back-end environment of the plant includes an execution engine that executes one or more other back-end environment objects to be commissioned and tested, and a communication interface that determines, from the device placeholder object if a field device is in an I/O-unallocated device state. If so, the communication interface uses the configuration data stored in the device placeholder object to verify that the form, format, and configuration of the object being tested is correct to properly communicate with the field device. Moreover, a simulation engine can generate simulated device signals to enable further testing of the object.

Configuration in process plant using I/O-abstracted field device configurations

A system tag identifying a device of a process control loop is determined/derived from a unique identifier of the device while the loop is communicatively disconnected from a process plant's back-end environment or control room. The system tag may be stored at the device itself or at a proxy that is disposed in the field of the process plant (e.g., at another component of the loop). One or more commissioning activities that include the device are performed in the field using the device's system tag, and at least some of the field commissioning activities may be automatically triggered based on the derivation of system tag. Upon the loop being communicatively connected to the back-end environment of the plant, the device's system tag known to the loop in the field is synchronized with the device's system tag known to the back-end of the process plant.

Determining device system tags for commissioning portions of a disconnected process control loop

During commissioning activities of a process plant, a device placeholder object that stores an I/O-abstracted configuration of a particular field device within the plant is created and stored in a device in the back-end environment of the plant and a further configuration file is stored in or for the particular field device in the field equipment environment of the plant. The device placeholder object, which will eventually be associated with the particular field device, and the field device configuration file are used to perform separate commissioning activities in each of these plant environments before the field devices are configured to communicate with a process controller via a particular I/O network within the plant. Thereafter, a binding application performs a discovery process to detect the I/O communication path through which each field device is connected to the back-end environment. The discovery process traverses through the I/O network as built, and autosenses the devices within the I/O network until this process discovers a device placeholder object or a configuration file for a particular field device. The binding application then determines if the information within these two device configuration files match, and if so, binds the field device to the back-end by storing the detected communication path for the particular device in a configuration database, such as in the device placeholder object for the particular field device. If the configuration information in the device placeholder object does not match the configuration file for a discovered field device, the binding application may perform a reconciliation procedure to determine the correct configuration information for the particular field device.

Binding of devices in a process plant using I/O-abstracted field device configurations

An I/O-abstracted configuration is defined for a field device that has not yet been assigned or allocated to communicate via a particular I/O device, and the field device (and optionally portions of the process control loop of which the field device is a part) is commissioned based on contents of its I/O-abstracted configuration. The field device's I/O-abstracted configuration is stored in an instance of a device placeholder object, which may be common to multiple types of devices and multiple types of I/O. A property of the device placeholder object may be exposed based on the value entered for another property, and the device placeholder object may store abstracted values as well as explicit or discrete values that are descriptive of the field device and its behavior. Upon I/O-assignment or allocation, values held in the device's I/O-abstracted configuration may be transferred to or otherwise synchronized with the device's as-built configuration.

I/O-abstracted field device configurations

Techniques for automatically testing an entire process control loop, such as after components and portions of the loop have been commissioned separately, or after run-time operation begins, enable the process control loop to be tested without an operator in a back-end environment of a process plant coordinating with an operator in a field environment of the process plant to supply inputs and/or generate various conditions at the loop. Instead, a single operator performs a single operation to initiate an automatic loop test, or in some implementations, no user input is needed to initiate and/or perform the automatic loop test. Automatic loop testing includes automatically causing a field device to operate in a plurality of test states and determining whether resultant loop behaviors are expected behaviors. Multiple loops may be tested concurrently or distinct in time. An automatic loop test result is generated and may be presented via a user interface.

Growing community of inventors

Pflugerville, TX, United States of America

Sergio Diaz