Method for responding to receipt of an identifier and mobile user interface device - Patents.com

Abstract

To provide a method of responding to receiving of a unique identifier.SOLUTION: A mobile user interface device receives a unique identifier sent from an external device of a plant environment. (i) The unique identifier signifies that the mobile user interface device is approaching the external device. (ii) The unique identifier is stored in a database in association with one or plural process entities relating to an area where the external device is disposed. (i) A process control device associated with the unique identifier is discriminated. (ii) The mobile user interface device is allowed to interactively render a user interface in order to alter a parameter using a process controller employed in controlling the process control device associated with the unique identifier. Thus, receiving of the unique identifier is responded.SELECTED DRAWING: Figure 1A

Description

[Technical field]

[0001] The present disclosure relates generally to process plants and process control systems, and more specifically to the use of mobile user interface devices in process plants and process control systems. [Background technology]

[0002] A distributed process control system, such as those used in chemical, petroleum, or other process plants, typically includes one or more process controllers communicatively coupled to one or more field devices via an analog, digital, or combined analog / digital bus, or via a wireless communication link or network. Field devices, such as valves, valve positioners, switches, and transmitters (e.g., temperature, pressure, level, and flow sensors), reside within the process environment and typically perform physical or process control functions, such as opening and closing valves, measuring process parameters, and the like, to control one or more processes running within the process plant or system. Smart field devices, such as field devices conforming to the well-known Fieldbus protocol, may also perform control calculations, alarm functions, and other control functions typically performed within a controller. A process controller, also typically present in a plant environment, receives signals indicative of process measurements and / or other information made by sensors and / or field devices, executes a controller application that executes different control modules that make process control decisions, for example, generates control signals based on the received information, and coordinates with control modules or blocks implemented in field devices such as HART®, Wireless HART®, and FOUNDATION® Fieldbus field devices. The control modules in the controller send the control signals over communication lines or links to the field devices, thereby controlling the operation of at least a portion of the process plant or system.

[0003] Information from the field devices and controllers is typically made available via a data highway to one or more other hardware devices, such as operator workstations, personal computers or computing devices, data historians, report generators, central databases, or other centralized computing devices, which are typically located in a control room or other location away from the harsh plant environment. Each of these hardware devices is typically centralized throughout the process plant or throughout a portion of the process plant. These hardware devices execute applications that may enable, for example, an operator to perform functions related to controlling the process and / or running the process plant, such as changing settings of process control routines, modifying the operation of control modules in a controller or field device, viewing the current state of the process, viewing alarms generated by the field devices and controllers, simulating the operation of the process for purposes of training personnel or testing process control software, maintaining and updating configuration databases, etc. The data highways used by the hardware devices, controllers, and field devices may include wired communication paths, wireless communication paths, or a combination of wired and wireless communication paths.

[0004] As an example, the DeltaV™ control system sold by Emerson Process Management includes multiple applications stored in and executed by different devices located at various locations within a process plant. Each of these applications provides a user interface (UI) to allow a user (e.g., configuration engineers, operators, maintenance personnel, etc.) to view and / or modify aspects of the operation and configuration of the process plant. Throughout this specification, the term “user interface” or “UI” is used to refer to an application or screen that allows a user to view or modify the configuration, operation, or status of the process plant. Similarly, the term “user interface device” or “UI device” is used to refer to the device on which the user interface is running, whether the device is stationary (e.g., a workstation, a wall-mounted display, a process control device display, etc.) or mobile (e.g., a laptop computer, a tablet computer, a smartphone, etc.). Configuration applications resident on one or more operator workstations or computing devices allow users to create or modify process control modules and download these process control modules to dedicated distributed controllers via a data highway. Typically, these control modules are composed of communicatively interconnected function blocks, which are objects in an object oriented programming protocol that perform functions in a control strategy based on inputs to them and provide outputs to other function blocks in the control strategy. The configuration application may also enable the configuration designer to create or modify operator interfaces that are used by the viewing application to display data to an operator and to allow the operator to change settings, such as setpoints, in the process control routines.Each dedicated controller, and in some cases one or more field devices, stores and executes a respective controller application that executes the control modules assigned to and downloaded to it to implement the actual process control functionality. A viewing application, which may run on one or more operator workstations (or on one or more remote computing devices in communicative connection with the operator workstations and the data highway), receives data from the controller applications over the data highway and displays this data to a process control system designer, operator, or user using a UI that may provide any of a number of different views, such as an operator's view, an engineer's view, a technician's view, etc. A data historian application is typically stored in and executed by a data historian device that collects and stores some or all of the data provided across the data highway, while a configuration database application may run on an additional computer attached to the data highway to store the current process control routine configuration and data associated therewith. Alternatively, the configuration database may be located on the same workstation as the configuration application. Summary of the Invention [Problem to be solved by the invention]

[0005] The architecture of process control plants and process control systems has been strongly influenced by limited controller and device memory, communication bandwidth, and controller and device processor capabilities. For example, the use of dynamic and static non-volatile memory in the controller is usually minimized, or at any rate carefully managed. As a result, during system configuration (e.g., a priori), the user must usually choose what data should be archived or stored in the controller, the frequency at which it is stored, and whether compression is used or not, and the controller is therefore configured with this limited set of data rules. As a result, data that may be useful for troubleshooting and process analysis is often not archived, and when it is collected, useful information may be lost due to data compression.

[0006] In addition to minimizing controller memory usage in currently known process control systems, data to be archived or stored is reported to a workstation or computing device for storage, for example, in an appropriate historian or data silo. Current techniques used to report data make poor use of communication resources and create excessive controller load. Additionally, due to time delays in communication and sampling in the historian or silo, data collection and time stamping often become out of sync with the actual process.

[0007] Similarly, in batch process control systems, to minimize controller memory usage, batch recipes and snapshots of controller configurations typically remain stored on a central computing device or in a specific location (e.g., a data silo or historian) and are transmitted to the controller only when needed. Such a strategy introduces significant burst loads to the controller and to the communication channels between the workstation or central computing device and the controller.

[0008] Additionally, the capacity and performance limitations of process control system relational databases combined with the high cost of disk storage have a significant impact on structuring application data into independent entities or silos to meet specific application objectives. For example, within the DeltaV™ system, process models, continuous historical data, and batch and event data are stored and / or archived in three different application databases or data silos. Each silo has a different interface for accessing the data stored therein.

[0009] Structuring the data in this way creates barriers to accessing and using historized data. For example, the root cause of product quality variability may be related to data in one or more of these data files. However, because of the different file structures, it is not possible to provide tools that allow for quick and easy access to this data for analysis. Furthermore, audit or synchronization functions must be performed to ensure that data across different silos is consistent.

[0010] The above-mentioned limitations and other limitations of process plants and process control systems may undesirably manifest themselves in the operation and optimization of a process plant or process control system, for example, during plant operation, troubleshooting, and / or predictive modeling. For example, such limitations impose tedious and lengthy workflows that must be undertaken to obtain data for troubleshooting and to generate updated models. Additionally, the obtained data may be inaccurate due to data compression, insufficient bandwidth, or shifted timestamps.

[0011] The description of the background art provided herein is intended to broadly and generally describe the background of the present disclosure. To the extent that it is described within this background art section, the work of the currently named inventors, as well as aspects of the description that may not specifically be regarded as prior art at the time of filing, are not explicitly or implicitly admitted as prior art against the present disclosure. [Means for solving the problem]

[0012] In a first embodiment, a mobile user interface device for controlling a process plant includes a processor communicatively coupled to a network, a memory communicatively coupled to the processor, and a display communicatively coupled to the processor. The mobile user interface device also includes a communication circuit operable to detect proximity of the mobile user interface device to an external device, and one or more routines stored on the memory device and executable by the processor. The routines cause the processor to transmit a first request for first data over the network and receive the first data over the network in response to the first request. The routines also cause the processor to display the received first data on the display, receive an indication that the mobile user interface device is in proximity to the external device, transmit a second request for second data over the network in accordance with the received indication, and receive the second data over the network in response to the second request.

[0013] In another embodiment, a method performed by a mobile user interface device for a process plant includes transmitting a first request for first data over a network from a data storage area and receiving the first data from the storage area in response to the first request. The method also includes causing the received first data to be displayed on a display of the mobile user interface device, receiving an indication that the mobile user interface device is in proximity to an external device, transmitting a second request for second data in accordance with the received indication, and receiving the second data in response to the second request. [Brief description of the drawings]

[0014] [Figure 1A] FIG. 1 is a block diagram of an example process control network operating in a process control system or process plant. [Figure 1B] FIG. 2 is a block diagram showing the wider control network. [Diagram 2] FIG. 1 is a block diagram illustrating a communications architecture including a mobile control room in accordance with the present description. [Diagram 3] FIG. 2 is a block diagram illustrating an embodiment of a supervisor engine according to the present description. [Figure 4] 24 illustrates an example work item that may be generated by the supervisor engine of FIG. 23. [Diagram 5] 1 is a flow chart illustrating a method for assigning tasks to process plant personnel. [Figure 6] 1 is a flowchart illustrating a method for managing workflow in a process plant. [Figure 7] 1 is a flowchart illustrating a method for facilitating task completion in a process plant. [Figure 8] FIG. 2 is a block diagram of a UI device. [Figure 9A] FIG. 1 illustrates aspects of an exemplary mobile control room. [Figure 9B]FIG. 1 illustrates devices in an exemplary mobile control room. [Figure 10] 1 illustrates an example device display associated with UI synchronization between UI devices. [Figure 11] 1 is a flowchart illustrating an example method for synchronizing UI devices. [Figure 12A] FIG. 2 is a block diagram illustrating example data associated with UI devices in an example mobile control room. [Figure 12B] FIG. 13 is a block diagram illustrating example data associated with UI devices in another example mobile control room. [Figure 13] 1 is a flowchart of an example method for providing session data to a UI device. [Figure 14] 1 is a flowchart of an exemplary method for generating a GUI composition on a UI device. [Figure 15] 1 is a flowchart illustrating an example method for direct state information transfer between two UI devices. [Figure 16] 5 is a flowchart illustrating an example method for communicating state information between two UI devices coupled to a server. [Figure 17] 11 is a flow chart illustrating an additional method for communicating state information between two UI devices. [Figure 18] 10 is a flow chart illustrating yet another exemplary method for controlling a process plant using a UI device associated with a mobile control room. [Figure 19] 1 is a flow chart illustrating a method executed on a server to facilitate mobile control of a process plant using a UI device. [Figure 20] 1 is a flow chart illustrating a method for transmitting a state of a first UI device to a second UI device. [Figure 21] 1 is a flowchart illustrating a method of initiating a UI session on a first UI device. [Figure 22]11 is a flowchart illustrating a second method for instantiating a UI session on a first UI device. [Figure 23] FIG. 1 illustrates a second embodiment of an exemplary mobile control room. [Figure 24] FIG. 1 is a block diagram of an example context-aware UI device. [Diagram 25] FIG. 1 is a block diagram of another embodiment of a mobile control room in a process plant. [Figure 26] FIG. 13 is a diagram of yet another exemplary mobile control room. [Figure 27] 4 is a flowchart illustrating an exemplary method for generating a graphical user interface. [Figure 28] 5 is a flowchart illustrating an example method performed by a UI device. [Figure 29] 1 is a flow chart illustrating a method for facilitating mobile control of a process plant. [Diagram 30] 1 is a flow chart illustrating a method for determining a location of a mobile device within a process plant. [Diagram 31] 1 is a flow chart illustrating a method for contextual operation of a mobile device in a process control environment. [Diagram 32] 1 is a flow chart illustrating a method for analyzing physical phenomena in a process plant. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] The decentralization and mobilization of control and maintenance equipment associated with a process plant brings with it various attendant advantages. For example, mobile user interface devices work in conjunction with stationary user interface devices to free operators, maintenance personnel, and other plant personnel from centralized locations, allowing personnel to move throughout the process plant without sacrificing access to information regarding the operation and status of the process plant. Through the implementation of "big data" concepts, i.e., the collection, storage, organization, and mining of one or more collections of data that are so large or complex that traditional database management tools and / or data processing applications cannot manage the data sets in an acceptable time, in combination with expert systems, monitoring systems, and context-aware mobile user interface devices, a process plant can be advantageously managed and maintained more efficiently (e.g., with less maintenance, higher yields, less downtime, fewer personnel, lower risks to personnel and equipment safety, etc.) as described throughout this disclosure.

[0016] In general, context-aware mobile user interface devices cooperate with expert systems, monitoring systems, and big data systems to facilitate improved operation of a process plant. The improved operation may be implemented using one or more of the concepts described herein, including aspects of collaboration, mobility, workflow management, workforce management, automation, accountability, verification, and diagnostics, among others. For example, the apparatus, systems, and methods described herein may facilitate seamless transitions from one user interface device to another (e.g., from a workstation to a tablet device or from a tablet device to a mobile phone) such that a user may have the same or similar information available regardless of whether they move from one device to another, and / or may facilitate collaboration of multiple personnel in the same or different locations viewing the same or different data, and / or may facilitate initiation or resumption of a user session regardless of the device on which the user happens to operate. Mobile ones of the user interface devices may be device-aware and / or location-aware to automatically display applicable information (e.g., maps, procedures, diagrams, user manuals), launch applications, and the like. In addition, cooperation between the expert system and the monitoring system and the user interface devices may facilitate the automatic generation, assignment, and management of work items related to the activities of operators and / or maintenance personnel. For example, as described in more detail below, the expert system may analyze information stored in a big data system to determine that certain tasks should be performed, and by collaborating with a supervisory system, may create work items, assign the work items to people, create checklists of items required to perform the work item tasks, walk the assignees through the performance of the associated tasks, and track the progress of the tasks. These and other aspects are described throughout.

[0017] Referring first to the overall architecture of an example process plant, FIG. 1A is a block diagram of an example process control network 100 operating in a process control system or process plant 10. The process control network 100 may include a network backbone 105 that provides direct or indirect connectivity between various other devices. Devices coupled to the network backbone 105, in various embodiments, include combinations of access points 72, gateways 75 to other process plants (e.g., via an intranet or enterprise wide area network), gateways 78 to external systems (e.g., to the Internet), UI devices 112, servers 150, big data appliances 102 (including, for example, big data historians), big data expert systems 104, supervisor engines 106, controllers 11, input / output (I / O) cards 26 and 28, wired field devices 15-22, wireless gateways 35, and wireless communication networks 70. The communication network 70 may include wireless devices 40-58, including wireless field devices 40-46, wireless adapters 52a and 52b, access points 55a and 55b, and a router 58. The wireless adapters 52a and 52b may be connected to non-wireless field devices 48 and 50, respectively. The controller 11 may include a processor 30, a memory 32, and one or more control routines 38. Although FIG. 1A depicts only one of some of the devices connected to the network backbone 105, it will be understood that each of the devices may be able to have multiple instances on the network backbone 105, and in fact the process plant 10 may include multiple network backbones 105.

[0018] The UI device 112 may be communicatively connected to the controller 11 and the wireless gateway 35 via the network backbone 105. The controller 11 may be communicatively connected to the wired field devices 15-22 via input / output (I / O) cards 26 and 28, and to the wireless field devices 40-46 via the network backbone 105 and the wireless gateway 35. The controller 11 may operate to implement a batch or continuous process using at least some of the field devices 15-22 and 40-46. The controller 11, which may be a Delta V™ controller sold by Emerson Process management, by way of example only, is communicatively connected to the process control network backbone 105. The controller 11 may also be communicatively connected to the field devices 15-22 and 40-46 using, for example, standard 4-20 mA devices, any desired hardware and software associated with the I / O cards 26, 28, and / or any smart communication protocol such as the FOUNDATION® Fieldbus protocol, the HART® protocol, the wireless HART® protocol, etc. In the embodiment illustrated in Figure 1A, the controller 11, the field devices 15-22, and the I / O cards 26, 28 are wired devices and the field devices 40-46 are wireless field devices.

[0019] During operation of the UI device 112, the UI device 112 may execute a user interface ("UI") that, in some embodiments, enables the UI device 112 to receive input via an input interface and provide output on a display. The UI device 112 may receive data (e.g., process-related data such as process parameters, log data, sensor data, and / or any other data that may be captured and stored in the big data appliance 102) from the server 150. In another embodiment, the UI may be executed in whole or in part on the server 150, in which case the server 150 may transmit display data to the UI device 112. The UI device 112 may receive UI data (which may include display data and process parameter data) from other nodes in the process control network 100, such as the controller 11, the wireless gateway 35, or the server 150, via the backbone 105. Based on the UI data received at the UI device 112, the UI device 112 may provide output (i.e., visual representations or graphics) representative of aspects of a process associated with the process control network 100, enabling a user to monitor the process. A user may also affect control of the process by providing input on the UI device 112. To illustrate, the UI device 112 may provide graphics representing a tank filling process, for example. In such a scenario, a user may read a tank level measurement and determine that the tank needs to be filled. The user may interact with an inlet valve graphic displayed on the UI device 112 and enter a command to open the inlet valve.

[0020] In further operation, the UI device 112 may execute a number of routines, modules, or services in addition to the UI. In one embodiment, the UI device 112 may execute context awareness routines, which may include various routines or subroutines (as shown in FIG. 27) related to, for example, location awareness, equipment awareness, or scheduling awareness. These context routines may enable the UI device 112 to tailor its graphical user interface configuration ("GUI configuration") to the particular environment or context in which the UI device 112 is operating. The UI device 112 may also execute state determination routines that enable the UI device 112 to track and save the state of the UI device 112, including the state of applications running on the UI device 112 (e.g., the UI). By tracking the state of applications on the UI device 112, the UI device 112 may enable a user to, for example, initiate a session on a first UI device 112 and begin using a second UI device 112 to resume the workflow from the user's previous session with minimal interruption.

[0021] The UI device 112 (or a server providing applications or screens to the UI device 112) may also execute routines related to managing plant assets. For example, some routines may be used to install, replace, maintain, calibrate, diagnose, or commission assets in a process plant. Other routines may be used to prepare or complete work orders related to a particular asset and / or to inform plant personnel (e.g., personnel in the vicinity of a particular device) of a work order. The UI device 112 may also execute routines related to monitoring of a process. For example, some routines may be used for field logging equipment data, reporting lab samples, displaying real-time asset parameters, etc. The UI device 112 may also execute routines related to compliance with plant procedures and workflows. For example, some routines may provide information related to standard operating procedures (SOPs), startup procedures, shutdown procedures, lockout procedures, work instructions, or other product / asset documentation. Further additional routines may facilitate immediate delivery of work orders and immediate system availability of offline manually entered data when the UI device 112 is coupled to a network. Communications routines may include email routines, text messaging routines, instant messaging routines, and the like to facilitate communications between plant personnel and / or external parties providing technical or other assistance.

[0022] The UI device 112 (or a server providing applications or screens to the UI device 112) may further include routines to support and / or facilitate one or more audit processes. The audit process may include, for example, a work audit and / or an audit by a regulatory authority. In some embodiments, the routines may enable a user to view data and / or generate reports related to data collected, maintained, and / or collated for purposes of meeting regulatory requirements. To illustrate, if a mobile control room is implemented in a pharmaceutical manufacturing plant, the mobile control room may facilitate viewing or reporting of data collected for purposes of meeting government requirements related to the safety of the plant's product output. In some embodiments, the routines may enable a user to view and / or generate reports related to audits of work orders, maintenance, or other plant processes.

[0023] In certain embodiments, the UI device 112 may implement any type of client, such as a thin client, a web client, or a thick client. For example, the UI device 112 may rely on other nodes, computers, or servers for most of the processing required for the operation of the UI device 112. In such an example, the UI device 112 may communicate with a server 150, which may communicate with one or more other nodes on the process control network 100 and may determine display and / or process data to send to the UI device 112. Additionally, the UI device 112 may pass any data related to received user input to the server 150 so that the server 150 can process the data related to the user input and act accordingly. In other words, the UI device 112 may do little more than render graphics and act as a portal to one or more nodes or servers that store data and execute routines required for the operation of the UI device 112. A thin-client UI device offers the advantage of minimal hardware requirements for the UI device 112.

[0024] In another embodiment, the UI device 112 may be a web client. In such an embodiment, a user of the UI device 112 may interact with the process control system through a browser on the UI device 112. The browser allows the user to access data and resources at another node or server 150 (e.g., server 150) through the backbone 105. For example, the browser may receive UI data from the server 150, such as display data or process parameter data that allows the browser to present graphics for control and / or monitoring of some or all of the process. The browser may also receive user input (e.g., a mouse click on a graphic). The user input may cause the browser to retrieve or access information resources stored on the server 150. For example, a mouse click may cause the browser to retrieve (from the server 150) and display information about the clicked graphic.

[0025] In yet another embodiment, most of the processing for the UI device 112 may occur in the UI device 112. For example, the UI device 112 may execute the UI, state determination routines, and context awareness routines described above. The UI device 112 may store, access, and analyze data locally.

[0026] In operation, a user may interact with the UI device 112 to monitor or control one or more devices in the process control network 100, such as any of the field devices 15-22 or devices 40-48. A user may interact with the UI device 112, for example, to modify or change parameters associated with a control routine stored in the controller 11. The processor 30 of the controller 11 implements or oversees one or more process control routines (stored in the memory 32), which may include a control loop. The processor 30 may communicate with the field devices 15-22 and 40-46, and with other nodes communicatively connected to the backbone 105. It should be noted that any control routine or module described herein (including quality prediction and fault detection modules or function blocks) may have portions thereof implemented or executed by different controllers or other devices, as appropriate. Similarly, the control routines or modules described herein to be implemented within the process control system 10 may take any form, including software, firmware, hardware, etc. The control routines may be implemented in any desired software form, for example using object-oriented programming, ladder logic, sequential function charts, functional block diagrams, or any other software programming language or design paradigm. In particular, the control routines may be executed by a user through the UI device 112. The control routines may be stored in any desired type of memory, such as random access memory (RAM) or read-only memory (ROM). Similarly, the control routines may be hard-coded, for example, in one or more EPROMs, EEPROMs, application specific integrated circuits (ASICs), or any other hardware or firmware elements. Thus, the controller 11 may be configured (in certain embodiments, by a user using the UI device 112) to execute the control strategies or control routines in any desired manner.

[0027] In some embodiments of the UI device 112, a user may interact with the UI device 112 to implement control strategies in the controller 11 using what are commonly referred to as function blocks, where each function block is an object or other portion (e.g., a subroutine) of an overall control routine that operates in conjunction with other function blocks (through communications called links) to implement a process control loop within the process control system 10. A control-based function block typically performs one of the following to perform some physical function within the process control system: an input function, e.g., associated with a transmitter, sensor or other process parameter measurement device; a control function, e.g., associated with a control routine performing PID control, fuzzy logic control, etc.; or an output function, e.g., controlling the operation of some device, such as a valve. Of course, hybrid and other types of function blocks exist. The function blocks may have a graphical representation provided on the UI device 112 to allow a user to easily modify the type of function block, the connections between the function blocks, and the inputs / outputs associated with each of the function blocks implemented in the process control system. The function blocks may be stored in and executed by the controller 11, which is typically the case when these function blocks are used with or associated with some types of smart field devices, such as standard 4-20 mA devices and HART devices, or may be stored in and executed by the field device itself, which may be the case for Fieldbus devices. The controller 11 may include one or more control routines 38 that may implement one or more control loops. Each control loop, typically referred to as a control module, may be performed by executing one or more of the function blocks.

[0028] The UI device 112, in some embodiments, interacts with the big data appliance 102 and / or the expert system 104 and / or the supervisor engine 106. The big data appliance 102 may collect and store all types of process control data from the process plant 10, including sensor data, control parameters, manual data (e.g., data collected by personnel as they move around the process plant 10), personnel locations and command inputs, timestamps associated with all of the data, and any other type of data available to the process plant 10. The expert system 104, communicatively coupled to the big data appliance 102, may operate independently or according to specific user inputs to analyze the process plant data stored in the big data appliance 102. The expert system 104 may generate and / or use models, recognize data trends and / or correlations, alert plant personnel of actual or predicted problems and / or abnormal situations and / or suboptimal conditions that may or will soon affect the process plant 10, etc. In some embodiments, the expert system 104 performs these functions without being specifically programmed to associate a particular data set or trend with a particular problem or condition, but instead recognizes that a current trend or data coincidence occurred before, at, or about a previous condition (which may be a positive / desirable condition or a negative / undesirable condition). From the recognition of a previous occurrence of a trend or data coincidence, the expert system 104 may predict ("prognosticate") the condition. The expert system 104 may also determine, from the data stored in the big data device 102, which process variables, sensor readings, etc. (i.e., which data) are most important to detect, predict, prevent, and / or correct abnormal situations in the process plant 10.For example, the expert system 104 may determine that hydrocarbons are being discharged from the stack and may automatically determine the cause of the hydrocarbon discharge and / or generate a work item (e.g., by the supervisor engine 106) to correct the problem causing the hydrocarbon discharge and / or generate a work item to inspect equipment or observe / record parameters that are not available over a network. As another example, the expert system 104 may determine that a trend indicated by a series of previous data points indicates a predicted abnormal condition, a predicted maintenance concern, a predicted failure, etc.

[0029] As described in more detail below, the supervisor engine 106 may interact with the big data appliance 102 and / or the expert system 104 to automate and / or facilitate various monitoring activities. For example, the supervisor engine 106 may monitor trends identified by the expert system 104 and create work items for plant personnel. As another example, the supervisor engine 106 may monitor the calibration status of process plant resources and create work items for plant personnel. In connection with these functions, the supervisor engine 106 may also manage personnel certifications, access permissions to equipment during scheduled work item performance, and timing of work item performance. The supervisor engine 106 may interact with the UI device 112 to assign and track the performance of work items, as well as follow up after the completion of work items to ensure that statuses or indicators (e.g., identified trends, abnormal situations, etc.) that result in the creation of a work item are resolved. For example, the supervisor engine 106 may determine from the expert engine 104 that a valve is faulty and create a work item. The supervisor engine 106 may later determine that a maintenance worker carrying a UI device 112 is in the vicinity of the malfunctioning valve and may request that the work item be assigned to a maintenance worker who may receive the work item via the UI device 112. The supervisor engine 106 may verify that the maintenance worker has the appropriate skills to perform the work item and may provide the necessary authorization for the maintenance worker to perform the work item. In addition, the supervisor engine 106 may reschedule process control activities so that the work item may be completed. The supervisor engine 106 may provide standard operating procedures, manuals, and other documentation to personnel prior to and / or during performance of the work item. These are just a few examples of the supervisor engine 106, which are described further below.

[0030] 1A, the wireless field devices 40-46 communicate in the wireless network 70 using a wireless protocol, such as the wireless HART protocol. In certain embodiments, the UI device 112 may be able to communicate with the wireless field devices 40-46 using the wireless network 70. Such wireless field devices 40-46 may communicate directly with one or more other nodes of the process control network 100 that are also configured to communicate wirelessly (e.g., using a wireless protocol). To communicate with one or more other nodes that are not configured to communicate wirelessly, the wireless field devices 40-46 may use a wireless gateway 35 connected to the backbone 105. Of course, the field devices 15-22 and 40-46 may be able to conform to any other desired standard or protocol, such as any wired or wireless protocol, including any standard or protocol developed in the future.

[0031] The wireless gateway 35 is one example of a provider device 110 that may provide access to the various wireless devices 40-58 of the wireless communication network 70. In particular, the wireless gateway 35 provides a communicative coupling between the wireless devices 40-58 and other nodes (including the controller 11 of FIG. 1A) of the process control network 100. The wireless gateway 35 provides the communicative coupling by providing routing, buffering, and timing services (e.g., address translation, routing, packet segmentation, prioritization, etc.) to lower layers of the wired and wireless protocol stacks while tunneling through one or more shared layers of the wired and wireless protocol stacks. In other cases, the wireless gateway 35 may translate commands between wired and wireless protocols that do not share any protocol layers. In addition to protocol and command translation, the wireless gateway 35 may provide synchronized clocking used by the time slots and superframes (sets of equally spaced communication time slots) of a scheduling scheme associated with the wireless protocol implemented in the wireless network 30. Additionally, the wireless gateway 35 may provide network management and operational management functions for the wireless network 70, such as resource management, performance tuning, network impairment mitigation, traffic monitoring, and security.

[0032] Similar to the wired field devices 15-22, the wireless field devices 40-46 of the wireless network 70 may perform physical control functions within the process plant 10, such as opening or closing a valve or measuring a process parameter. The wireless field devices 40-46, however, are configured to communicate using the wireless protocol of the network 70. Thus, the wireless field devices 40-46, the wireless gateways, and the other wireless nodes 52-58 of the wireless network 70 are producers and consumers of wireless communication packets.

[0033] In some scenarios, the wireless network 70 may include non-wireless devices. For example, the field device 48 in FIG. 1A may be a legacy 4-20 mA device, and the field device 50 may be a traditional wired HART device. To communicate within the network 30, the field devices 48 and 50 may be connected to the wireless communication network 70 via wireless adapters (WA) 52a or 52b. In addition, the wireless adapters 52a, 52b may support other communication protocols, such as FOUNDATION® Fieldbus, PROFIBUS, DeviceNet, etc. Furthermore, the wireless network 30 may include one or more network access points 55a, 55b, which may be separate physical devices in hardwired communication with the wireless gateway 35, or may be provided as an integrated device together with the wireless gateway 35. The wireless network 70 may also include one or more routers 58 to forward packets from one wireless device to another within the wireless communication network 30. The wireless devices 32 - 46 and 52 - 58 may communicate with each other and with the wireless gateway 35 via wireless links 60 of a wireless communications network 70 .

[0034] 1A thus includes some examples of provider devices that primarily serve to provide network routing functionality and administration for various networks of a process control system. For example, the wireless gateway 35, the access points 55a, 55b, and the router 58 include functionality for routing wireless packets in a wireless communication network 70. The wireless gateway 35 performs traffic management and administration functions for the wireless network 70, as well as routing traffic between the wireless network 70 and a wired network communicatively connected thereto. The wireless network 70 may use a wireless process control protocol that specifically supports process control messages and functions, such as wireless HART.

[0035] In certain embodiments, the process control network 100 may include other nodes connected to the network backbone 105 that communicate using other wireless protocols. For example, the process control network 100 may include one or more wireless access points 72 that use other wireless protocols, such as WiFi or other IEEE 802.11 compliant wireless local area network protocols, mobile communication protocols, such as Worldwide Interoperability for Microwave Access (WiMAX), Long Term Evolution (LTE), or other International Telecommunication Union Radiocommunication Sector (ITU-R) compliant protocols, short wavelength wireless communications, such as Near Field Communication (NFC) and Bluetooth, or other wireless communication protocols. Typically, such wireless access points 72 enable handheld or other portable computing devices to communicate over respective wireless networks that are different from the wireless network 70 and that support different wireless protocols than the wireless network 70. In some embodiments, the UI device 112 communicates over the process control network 100 using the wireless access points 72. In some scenarios, in addition to the portable computing device, one or more process control devices (e.g., controller 11, field devices 15-22, or wireless devices 35, 40-58) may also communicate using a wireless network supported by access point 72.

[0036] Additionally or alternatively, the provider devices may include one or more gateways 75, 78 to systems external to the process control system 10. In such an embodiment, the UI device 112 may be used to control, monitor, or otherwise communicate with such external systems. Typically, such systems are customers or suppliers of information generated or acted upon by the process control system 10. For example, the plant gateway node 75 may communicatively connect the process plant 10 (having its own respective process control data network backbone 105) to another process plant having its own respective network backbone. In one embodiment, a single network backbone 105 may serve multiple process plants or process control environments.

[0037] In another example, the plant gateway node 75 may communicatively connect the process plant to a legacy or prior art process plant that does not include the process control network 100 or backbone 105. In this example, the plant gateway node 75 may convert or translate messages between a protocol used by the process control big data backbone 105 of the plant 10 and a different protocol used by the legacy system (e.g., Ethernet, Profibus, Fieldbus, DeviceNet, etc.). In such an example, the UI device 112 may be used to control, monitor, or otherwise communicate with systems or networks in such legacy or prior art process plant.

[0038] The provider device may include one or more external system gateway nodes 78 to communicatively connect the process control network 100 to a network of external public or private systems, such as a laboratory system (e.g., a laboratory information management system, or LIMS), a personnel rounds database, a material handling system, a maintenance management system, a product inventory control system, a production scheduling system, a weather data system, a shipping and handling system, a packaging system, the Internet, a process control system of another provider, or other external systems. The external system gateway node 78 may, for example, facilitate communication between the process control system and personnel outside the process plant (e.g., personnel at home). In one such case, an operator or maintenance personnel may use the UI device 112 from home connecting to the network backbone 105 via a home network (not shown), the Internet, and the gateway 78. In another case, the operator or maintenance personnel may use the UI device 112 from any location connecting to the network backbone 105 via a mobile telephone communication network (not shown), the Internet, and the gateway 78. The gateway node 78 may also facilitate communications between plant personnel at the process plant and entities or people external to the process plant. For example, a technician performing service on a process control device at the process plant may communicate with a support representative from the manufacturer of the process control device from his UI device 112. In yet another example, the supervisor engine 106 may monitor weather, track incoming supply shipments, track financial data (e.g., commodity futures), etc., to assist the supervisor engine 106 in scheduling work items, managing production schedules, etc. Of course, all connections made through the gateway 78 (or gateway 75, or indeed between any two devices) may be secured connections (e.g., encrypted connections, firewalled connections, etc.).

[0039] 1A illustrates a single controller 11 along with a finite number of field devices 15-22 and 40-46, this is merely an example and not a limiting embodiment. Any number of controllers 11 may be included in the provider devices of the process control network 100, and any of the controllers 11 may communicate with any number of wired or wireless field devices 15-22, 40-46 to control a process in the plant 10. Additionally, the process plant 10 may also include any number of wireless gateways 35, routers 58, access points 55, wireless process control communication networks 70, access points 72, and / or gateways 75, 78.

[0040] FIG. 1B is a block diagram illustrating a broader control system 120 that may include a variety of different systems or system functions. The control system 120 includes a process plant 10, which may be, as a non-limiting example, a crude oil refinery. The system 120 may also be coupled to a subsea system 122, such as a drilling or exploration system. Various safety systems 124 may be included in the system 120, as may a fire and gas system 126, a monitoring system 128, and a transportation system 130 (e.g., for transporting crude oil to a refinery). Although FIG. 1B depicts each of elements 10 and 122-130 as separate aspects, it is noted that various ones of the aspects may be combined. For example, the process plant 10 may include the safety system 124 and / or the fire and gas system 126 in some embodiments. FIG. 1B is intended to illustrate that the present description is not limited in scope to the process plant described with respect to FIG. 1A, but may be applicable to other control systems, monitoring systems, safety systems, and the like. Although the present description describes an embodiment with respect to a process control plant 10, this convention is merely for convenience and is not intended to be limiting.

[0041] The following examples illustrate several scenarios for implementing in a process plant, such as process plant 10, the concepts described herein, and highlight the advantages of such implementation.

[0042] Example 1 A first user assigned to a particular area of ​​the plant may monitor the assigned plant area via a stationary workstation in a control room. The first user monitors and controls the process via a browser or other application running on the workstation, which communicates with routines executing on the server. The first user may decide to go to the process plant floor, for example to inspect the plant. When the user leaves the control room, the user may pick up a touch-sensitive tablet device (i.e., a second mobile user interface device), leave the control room and walk towards the plant. The tablet, such as a workstation, allows the first user to access routines on the server via a browser or application running on the tablet device. The first user may already be authenticated on the tablet or the tablet may be associated with the first user. The tablet communicates with the server to establish a session specific to the first user. The server may store state information associated with the first user at the workstation and provide the first user with a user interface on the tablet according to the stored state information via a browser or application running on the tablet. Thus, the first user can resume the workflow that was initiated at the workstation.

[0043] In some circumstances, a routine running on the mobile device may generate a route for the first user. The routine, perhaps working with an expert system and / or a supervisor system, may identify plant assets that need to be monitored or serviced. In some cases, there may be a priority associated with each asset that needs to be monitored or serviced that indicates the urgency of monitoring or servicing the asset. The routine may determine a route for the first user that enables the user to efficiently visit at least some of the assets that need to be monitored or serviced.

[0044] As the first user moves through the plant, a context awareness routine executing on the tablet receives data from various sensors and receivers in the tablet device (e.g., NFC or RFID transceivers). The sensors and receivers detect devices, equipment, and / or tags in proximity to the tablet. In another embodiment, the tablet may have a GPS receiver for receiving location data, which may be uploaded to a server so that the routine may run with awareness of the user's location. In either case, the routine may identify the tablet's location or proximity to a particular device, and cause the tablet to display for the first user a process plant overview map / graphic that is zoomed in on the first user and the tablet's general location. As the first user moves through the plant, the plant map display may dynamically change to focus on an area of ​​the map that corresponds to the tablet's location.

[0045] In some cases, the plant map may include navigation functionality. For example, a first user may select a particular plant area / device / asset as a destination. A routine may then use location data (e.g., received from a GPS receiver) to provide directions to the particular plant area / device / asset.

[0046] The tablet may also display various process data or alarms as the first user passes through the plant 10. For example, if the first user needs to focus specifically on a pump, the first user may pass by the pump and have the tablet display operational data, graphics, and alarms related to the pump. The tablet may receive a unique identifier, for example, from an NFC or RFID tag on or near the pump. The tablet may transmit the unique identifier to the routine via the server. The routine may receive the unique identifier and access a database that correlates the unique identifier with entities in the process plant. For example, the unique identifier may correlate with pump data, such as display data, parameter data, and alarm data related to the pump. After identifying the pump data, the routine may transmit the pump data to the tablet, which results in the tablet rendering graphics and providing graphics, parameters, and / or alarms related to the pump.

[0047] In a further example, a first user may notice that a pump is malfunctioning. The first user may interact with a pump graphic or menu shown on a tablet display and may touch the tablet display where the graphic represents a shut off command. The tablet may detect the first user input (e.g., capacitive touch input) and generate corresponding input data. The tablet may then transmit the input data to a server, which receives the input data and transmits a shutdown signal to a controller that controls the pump. The controller receives the signal and turns off the pump. The first user may create a task or work item associated with the pump. For example, the work item may request maintenance personnel to inspect and / or repair the pump.

[0048] The routines on the tablet may also facilitate lockout / tagout procedures. For example, the routines may display the proper lockout / tagout procedures for a particular pump. In some cases, a first user wishing to lock out a pump for safety reasons may interact with a task list displayed by the tablet to indicate that certain tasks in the lockout procedure have been completed, for example. In other situations, the first user may interact with the routines to test fail-safe conditions for the pump. For example, simulated signals may be generated to simulate fail-safe conditions that allow the first user to observe the pump's response.

[0049] Example 2 The first user, still carrying the tablet, may begin walking from the process plant toward a control room of the process plant. The first user may walk toward a boiler. As the first user approaches the boiler, the tablet establishes RFID communication with the boiler's context ID device. The tablet may receive a unique identifier from the context ID device and transmit the unique identifier to a server. The server may identify the boiler based on the unique identifier. The server may access the context data to determine that the boiler has an associated work item and compare a skill threshold associated with the work item to a skill level associated with the first user's profile. Upon determining that the first user is not qualified to work on the work item associated with the boiler, the server may proactively change the display of the tablet instead of updating the display with information about the work item.

[0050] The user may continue walking through the plant while still carrying the tablet and may walk towards the valve. As described above, the tablet may establish communication with the context ID device of the valve. The tablet may then receive a unique identifier from the device and transmit the unique identifier to a server. The server may identify the valve based on the unique identifier. The server may then access the context data to determine that the valve has an associated schedule indicating that the valve is currently scheduled to be taken out of service for maintenance. The server transmits the data to the tablet and causes the tablet to provide information to the first user, where the information indicates to the first user that the valve is currently scheduled for maintenance.

[0051] Example 3 The first user continues to walk through the plant, still holding the tablet in hand. A second user, in the control room and now logged into the workstation previously occupied by the first user (or a different workstation), may notice that a critical O2 gas measurement associated with the furnace stack is dropping. The second user creates a work item requesting assistance with the furnace stack. As the first user passes the furnace stack on his way back to the control room, the tablet may automatically establish communication with the furnace stack's context ID device, resulting in the tablet receiving a unique identifier associated with the furnace stack. The tablet may transmit the unique identifier to a server, which may return information associated with the unique identifier (e.g., information about the furnace stack) including a notification graphic that the furnace stack needs attention. The first user may view and select the notification graphic, resulting in a display of information related to the created work item. The first user may select the graphic to indicate receipt of the work item.

[0052] The work item may request that the first user take one or more pictures of the furnace flame (e.g., because the color of the flame may indicate inadequate airflow). The pictures of the flame may be transmitted to a server. An analysis routine running on the server, on the big data device, or as part of the expert system may analyze aspects of the image or may compare the image of the flame to other images captured at other times and / or under other conditions and stored on the big data system or device. The analysis routine may analyze the image (e.g., by comparing the image to a collection of previous flame images and corresponding operational data). The big data analysis routine may indicate that the furnace airflow is low. Based on the analysis, the expert system may instruct the first user to increase the airflow to the furnace. In some embodiments, the first user may use a tablet to search for and display operational instructions for increasing the air to the furnace, and in fact the tablet may automatically display the instructions when the expert system instructs the user to increase the airflow in some embodiments. If desired, the first user may capture additional images of the flame after adjustment and transmit the images to an analysis routine to verify that the furnace stack is operating properly.

[0053] The first user may also use the tablet to capture audio associated with the furnace and transmit the audio to a server, big data device, or expert system. For example, an analysis routine running on the expert system may compare the audio to a sound signature associated with the furnace to determine if the furnace is operating normally. The analysis routine may also compare the captured audio to audio associated with known problems. For example, belt or motor problems may be associated with certain sounds, and the analysis routine may detect such problems by comparing the captured audio to said sounds. Similarly, the first user may place a tablet on or near the furnace to detect vibrations associated with the furnace. The tablet may receive vibration data via a motion sensor and transmit the vibration data to the server or big data device. The analysis routine may compare the detected vibrations to a signature vibration level associated with the furnace (or to a vibration level associated with a known problem) to determine if the furnace is operating normally. In any case, the analysis of the audio / vibration may reveal that there are no other problems associated with the furnace and / or identify that the furnace needs increased airflow.

[0054] With a first user increasing the airflow of the furnace, a second user may run a query on the furnace to see if a previous user has also increased the airflow over the past several shifts. The query verifies what personnel have been doing. The second user may pull up a graph showing the airflow through the furnace along with event information such as each time the airflow was increased, who made the change, etc., all of which are stored in the big data device. The second user may share this information with the first user, for example, by requesting a shared user interface (UI) session. The first user may receive a request for the UI session via the server. When the first user receives the request, the server may populate the status information associated with the UI to be displayed to the second user and may cause the display of the tablet being used by the first user to display data according to the status information from the second user. The first and second users may together review the data regarding the furnace and may determine that the furnace frequently experiences similar problems. The second user may then query the big data system for low O2 gas metering events at the furnace. The big data system may provide multiple events, devices, users, times, and other factors that correlate with a low O2 gas measurement event at the furnace. For example, big data analysis may reveal that a low O2 gas measurement is strongly correlated with an event at an associated process unit, where the correlated event frequently precedes the low O2 gas measurement. In another example, the analysis may reveal that a particular user is strongly correlated with a low O2 gas measurement event. In other words, the analysis may reveal that a particular user is controlling the furnace in a manner that causes a low O2 gas measurement. Note that while this example shows a user using a UI device to request an analysis and display the results of the analysis, the big data system may also use data collected from and by the UI device (a tablet in this scenario) for use in other analyses that may or may not be related to the UI device.In any event, the second user may flag the work item for further review and create a maintenance ticket to have someone check the furnace at a particular time in the near future.

[0055] Example 4 Maintenance personnel may then inspect the furnace and find that it has been operating improperly due to the point at which the fuel input is coupled to the furnace, and may create a work item to correct the problem. The work item may specify the target equipment (i.e., the furnace) indicating that a fuel input pipe should be welded to the fuel input of the furnace, and may have an associated task indicating the skill required to perform the task (i.e., welding skills). The work item may optionally specify a deadline for the completion of the work item.

[0056] The supervisor module may schedule the performance of the work item. For example, the supervisor module may schedule the performance of the work item for a day when the plant (or the area of ​​the plant in which the furnace resides) is scheduled to be offline for maintenance. Alternatively or additionally, the supervisor module may schedule this according to the availability of personnel with the required skills. Upon identifying a welding operator as having the appropriate skills, the supervisor module may assign the work item to the welding operator and wait for the welding operator to receive the assigned work item. When the welding operator receives the work item, the supervisor module creates an authorization token that grants the welding operator access to the required plant functions and equipment at the time the work item is to be performed.

[0057] At the designated time, the welding worker may arrive at the equipment room with his / her assigned mobile user interface device, which may remind the welding worker that he / she is scheduled to perform a work item (i.e., to weld a furnace connection). Upon acknowledging receipt of the reminder, the UI device may display a checklist generated by the supervisor module that pertains to the work item. The checklist may remind the welding worker that he / she needs to carry safety gear (e.g., welding mask and gloves), welding tools (e.g., welding power supply, electrodes, filler material, etc.), and other items (e.g., replacement parts) required to perform the task. The checklist may also specify certain tasks to be performed before moving to the target equipment. Once the welding worker confirms (e.g., via the user interface device) to the supervisor module that he / she has all of the tools on the checklist and has performed the tasks specified on the checklist, the welding worker may leave the equipment room.

[0058] When the UI device senses that the welder has left the equipment room, the UI device switches to a map or guidance mode and displays information about the welder's location in the process plant, as well as information guiding the welder to the target equipment (in this case, the furnace). When the UI device senses that the welder has arrived at the furnace, the UI device automatically displays procedures appropriate to the work item task (which may be provided, for example, by a supervisor module). For example, the UI device may first display to the welder safety procedures and information necessary to ensure that the work item task can be performed safely, such as displaying information about what material the fuel pipe being welded to the furnace typically carries, what material was the last material flowing through the pipe, whether the pipe is drained, whether the pipe is currently being used, and whether residue is detected in the pipe. The UI device may also display procedures for cleaning residue from the pipe, step-by-step and / or graphically, to ensure that the welding procedure can be performed safely (e.g., without causing an explosion). The UI device may also provide and facilitate instructions to shut down and / or lock out portions of the system, such as upstream valves that may allow gases to flow through pipes, furnace igniters, and any other equipment that may pose unnecessary risk to the procedure, the welding operator, or the process plant. The welding operator may then, following instructions or other guidance if provided by the UI device, release the lockout and perform the welding procedure before indicating to the supervisor module via the UI device that the procedure is complete, which may then automatically create a work item to have a second person check the weld before returning the plant (or portion of the plant) to operation.

[0059] These examples are illustrative of some of the advantages of the systems, devices and methods described throughout the remainder of this specification.

[0060] The concepts described herein are contemplated for integration with systems already implemented in a process control plant, i.e., in some embodiments, implementation of these concepts does not require an entirely new process control system, but instead may be seamlessly integrated with existing software and hardware elements in the plant.

[0061] Big Data Network In certain embodiments, the disclosed UI devices, servers, and routines may be implemented in a process control network supporting a big data infrastructure (i.e., a big data network). The big data network may support large-scale data mining and data analysis of process data. The big data network or system may also include multiple big data network nodes to collect and store all (or substantially all) data generated, received, and / or observed by devices included in and associated with the process control system or plant 10. The big data network may include big data appliances (e.g., big data appliance 102), which may include modular logical data storage areas configured to store, sometimes using a common format, multiple types of data generated by or related to the process control system, the process plant 10, and one or more processes controlled by the process plant 10. For example, the modular logical data storage areas may store time-stamped configuration data, continuous data, event data, plant data, data indicative of user actions, network management data, and data provided by or to systems external to the process control system or plant. These data may also include personnel-related data, raw material and / or processed material-related data, personnel constraints, qualifications, and certification-related data, calibration and maintenance schedule-related data, and the like. Data collected by the big data network may be, for example, data logs that track personnel and inputs received from these personnel. Such data may be useful in improving plant operations and efficiency. For example, log data may be mined and analyzed by an expert system to provide valuable insights into operator inputs in various situations. The results may be used to improve operator training and / or improve either automated or manual responses in various situations. In any event, such data is required in many instances for regulatory purposes.

[0062] The term "unitary" as used herein when applied to the logical data storage area of ​​the big data appliance 102 is not intended to mean a single storage device. As is commonly known, multiple (even many) storage devices of a first size (or various first sizes) may be communicatively coupled to form a storage area of ​​a second, larger size. These may nevertheless be considered a "unitary" logical data storage for purposes of this description. In general, the big data appliance 102 is configured to receive data (e.g., via streaming and / or via some other protocol) from a big data network node of a big data network and store the received data. Thus, the process control big data appliance 102 may include a unitary logical data storage area for historizing or storing data received from a big data node, multiple device data receivers for receiving data, and multiple device request servicers, as described in U.S. Patent Application No. 13 / 784,041, which is incorporated herein by reference in its entirety for all purposes.

[0063] The process control big data system may automatically collect all data generated, received, or obtained at the node at the rate at which the data is generated, received, or obtained, and distribute the collected data with high fidelity (e.g., without lossy data compression or any other techniques that may cause loss of original information) to the process control system big data device 102 to be stored (and optionally distributed to other nodes of the network). The process control system big data system may also be able to provide sophisticated data analysis and trend analysis on any portion of the stored data. For example, the process control big data system may be able to provide automatic data analysis across process data (contained in different database silos in prior art process control systems) without requiring any pre-configuration and without requiring any translation or conversion. Based on the analysis, the process control system big data system may be able to automatically provide detailed knowledge discovery and may suggest changes or additional entities in the process control system. Additionally or alternatively, the process control system big data system may take action (e.g., prescriptive, predictive, or both) based on the knowledge discovery. Big data systems in process control systems may also enable and assist users in performing manual knowledge discovery and in planning, configuring, operating, maintaining, and optimizing process plants and their associated resources.

[0064] Expert Systems The expert system 104 is a collection of routines and / or modules configured to access and analyze data collected and stored by the big data appliance 102. Although illustrated and described throughout this specification as a separate module from the big data appliance 102, in some embodiments the expert system 104 may be incorporated within the big data appliance 102. In addition, the expert system 104 may include multiple modules or routines that operate on different process areas and / or on different process equipment. For example, the expert system functionality may reside in one or more controllers 11, one or more process control devices 15-22, etc. In any case, the expert system 104 uses the data collected and stored by the big data appliance 102 to identify trends, perform diagnostics, monitor operator inputs, improve modeling of the process plant and / or portions of the process plant, monitor material supply, monitor output quality and quantity, model various aspects of the plant's operation, and myriad other activities. The expert system 104 may use predefined models to perform the analysis of the collected data and / or may actively (or automatically) generate models according to the analysis of the data. The expert system 104 may perform many different types of analysis, some examples are provided below. The examples are not intended to limit the scope of the functionality of the expert system 104, but rather to illustrate some of the possible functionality.

[0065] In one example, the expert system 104 monitors data collected and stored by the big data appliance 102 (either in real time or after collection and storage) and performs analysis of the data related to a particular alarm or alarm type. The expert system 104 may be programmed to analyze the process parameters, process inputs, sensor data, and any other data stored in the big data appliance 102 to determine any common characteristics (trends, values, etc.) related to a particular alarm. The association may be a temporal association, but not necessarily contemporaneous with the alarm. For example, the expert system 104 may analyze the data to determine if a particular operator input occurs with a similar temporal relationship to the alarm. More specifically, the expert system 104 may determine the confluence of multiple factors that precede or are otherwise predictive of an alarm condition, dictating, for example, that the temperature in a particular tank is rising and that when an operator releases a specified amount of a particular catalyst into the tank, the pressure in the tank will rise at a specified rate and an alarm condition will occur.

[0066] In another example, the expert system 104 may be programmed to perform statistical analysis of data collected and stored by the big data appliance 102 to determine the strength of correlations between events and process parameters. For example, an experienced operator may have a "gut feeling" sense about the relationships between various processors, but the operator's intuition may be less reliable than rigorous analysis of the data, causing the operator to respond to a process control situation (e.g., a rising tank temperature, a falling pressure, etc.) by making adjustments to the process that may make the situation worse, or at least may not correct the situation as quickly or to the same extent as other or additional adjustments. Thus, the expert system 104 may improve the overall control, safety, quality, and output of the process by providing operators and other personnel with information that they would not otherwise know or understand.

[0067] In yet another example, the expert system 104 is programmed to make adjustments to a process operating on the process plant 10 according to the analysis (e.g., the analysis described in the paragraph above). The expert system 104 may identify suboptimal or abnormal conditions and act to correct the condition by altering one or more process inputs and / or setpoints. Additionally, the expert system 104 may be integrated with other safety systems in the process plant 10 to contain and / or correct process conditions that may result in a safety hazard to equipment and / or personnel.

[0068] Supervisor Engine The implementation of a mobile control room with the UI devices 112 facilitates the distribution of control, maintenance, and other aspects of a process plant (or other similar environment). That is, operators are no longer tied to workstations to maintain optimal control of the process plant, and thus the line between operators and maintenance personnel who previously typically spent time at the plant rather than in the control room becomes blurred or eliminated. More personnel can be accommodated moving around the plant environment. At the same time, the big data appliance 102 stores more complete data about all aspects of the plant environment, and the expert system 104 provides a more complete analysis of the operation and conditions of the process plant. The expert system 104 and the big data appliance 102 work together to provide information about the state of the processes operating in the plant, the state of the equipment in the plant, the location of personnel in the plant and associated tasks, and myriad other aspects related to plant management, material management, personnel management, optimization, and the like.

[0069] The supervisor engine 106 uses the data and analysis provided by the expert system 104 to manage personnel within the process plant. In particular, the supervisor engine 106 may monitor trends identified by the expert system 104 and may create work items for plant personnel. Although illustrated and described throughout this specification as a separate module from the big data appliance 102 and the expert system 104, in some embodiments the supervisor engine 106 may be incorporated within the big data appliance 102 and / or within the expert system 104. FIG. 2 is a block diagram illustrating a communication architecture between the mobile control room UI device 112, the supervisor engine 106, and the expert system 104, and the big data appliance 102. As described above, the expert system 104 may retrieve and analyze data stored in the big data appliance 102, and in some embodiments, the expert system 104 may store data in the big data appliance 102. For example, the expert system 104 may retrieve data related to aspects of the process control system and perform one or more analyses on the obtained data. The analysis performed by the expert system 104 may be according to a pre-programmed model, or in some embodiments may be model-free (i.e., the expert system 104 may search the data for unknown correlations or relationships). In any case, the expert system 104 may store the analyzed data (e.g., regression data, correlated data, etc.) in the big data appliance 102.

[0070] The supervisor engine 106 may use data received / retrieved from the expert system 104 and / or data received from the big data appliance 102. For example, the supervisor engine 106 may receive data from the expert system 104 indicating that a particular parameter is most closely correlated with a particular abnormal condition or with a particular optimal condition. As another example, the supervisor engine 106 may receive data from the expert system 104 indicating that a particular parameter should be checked or that a particular adjustment to a process control device / routine needs to be made to avoid an abnormal condition. As yet another example, the supervisor engine 106 may receive data from the expert system 104 indicating that the expert system 104 has identified a trend indicating that maintenance is required or will be required at a predicted time. Alternatively or in addition, the supervisor engine 106 may receive or retrieve data from the big data appliance 102. For example, the routines executed by the supervisor engine 106 may relate to periodic scheduled maintenance (i.e., maintenance that occurs at routines, scheduled intervals, or intervals that depend on parameters of the plant). That is, the supervisor engine 106 may monitor parameters of devices at or within the process plant to determine, for example, how long a device has been in use since last maintenance or how long a device (e.g., a valve) has been operating since last maintenance. This type of data may be stored in the big data appliance 102 and retrieved by the supervisor engine 106.

[0071] Create a work item The supervisor engine 106 may use the received data to create work items for plant personnel and / or otherwise cause certain actions to be taken in the process plant. FIG. 3 is a block diagram illustrating an embodiment of the supervisor engine 106. The supervisor engine 106 may include a work item manager 300. The work item manager 300 may be a set of routines and / or instructions stored on a computer-readable medium and executed by a processor and usable to create work items. Each work item may be a task or procedure to be completed by one or more process plant personnel. For example, a work item may include replacing or repairing a device, taking parameter readings, making adjustments to a device or parameters, inspecting equipment or products, performing a calibration procedure, programming a device, or any other action that needs to be completed by personnel. As the work item manager 300 generates a work item, the work item may be stored in a work item list 302 residing in a memory associated with the supervisor engine 106. 4, an example work item 400 may include a variety of information including a work type or function 402 (e.g., check out wiring, replace equipment, calibrate equipment, maintenance (e.g., lubrication, etc.), etc.), a list of equipment required to perform the work item 404, a target equipment field 406 identifying equipment related to the work item, a target start time / day 408, a target completion time / day 410, a priority field 412 (e.g., “immediately,” “within 12 hours,” “within 24 hours,” “after current batch,” “during next shutdown,” “high,” “medium,” “low,” etc.), a required skills field 414 and / or a required qualifications field (not shown), and a target equipment type field 416. Of course, fewer or additional fields may be included in the work item 400.

[0072] 3, the supervisor engine 106 may also include a set 304 of personnel profiles 306. Each of the personnel profiles 306 includes information related to a particular operator, maintenance personnel, or other plant personnel. The information in the personnel profiles 306 may include skills, certifications and / or credentials, duties (e.g., operator, maintenance, security, safety), work hours / schedules, tour schedules (i.e., routine and / or scheduled routes that personnel follow around the plant to record parameter data or visually inspect aspects of the process plant), and / or any other information that may be relevant to the performance of various duties within the process plant.

[0073] Workflow Management The work item scheduler 308 may be stored on a machine-readable medium as a set of instructions. The instructions may be executable by a processor to schedule the work items stored in the work item list 302. The work item scheduler 308 may schedule the work items according to any of a variety of factors. For example, the work item scheduler 308 may schedule the work items according to the priority of each work item, according to personnel scheduled to be at a location (a "target location") adjacent a piece of equipment related to the work item (the "target equipment"), according to personnel currently at the target location adjacent the target equipment, according to current availability of personnel (e.g., personnel who are or will be on shift at the desired work item start / completion times and / or personnel not otherwise assigned at the desired work item start / completion times), according to personnel needed / required / desired skills, duties, certifications, and / or credentials, according to scheduled plant maintenance and / or shutdown schedules, etc. By way of example only, and not by way of limitation, the work item scheduler 308 may track work items in a work item list 302, noting the target location and / or target equipment associated with each work item. The work item scheduler 308 may receive information from a personnel tracking routine 310, which tracks the location of personnel via UI devices 112 carried by personnel. When the personnel tracking routine 310 reports that a mobile operator is located adjacent to a target location or target equipment (e.g., by determining personnel logged into or assigned to a UI device 112 whose location is known), the work item scheduler 308 may consult a personnel profile 306 associated with the mobile operator to determine whether the mobile operator has the necessary skills and / or credentials to perform the task (the "target function") associated with the work item. If the mobile operator has the appropriate skills and / or credentials, the work item scheduler 308 may assign the work item to the mobile operator, and when the operator accepts the work item, the work item scheduler 308 may create any permissions necessary for the operator to perform the target function on the target device.Of course, it will be appreciated that a particular task may require more than one person to complete, and therefore more than one person may be assigned to a single work item.

[0074] In some embodiments, authorizations are created as tokens or entries in a database 312 stored in a memory associated with the supervisor engine 106. Each authorization token defines a target function (e.g., check out wiring), a target equipment, the identity of a worker assigned to the work item, and optionally, an expiration date and time for the token. An authorization token may be required for all work items, for some work items, for a particular equipment or equipment type, for work items associated with a particular target function (i.e., work item task), etc. An authorization token gives a mobile personnel assigned to a work item specific access rights and can be revoked at any time by the system. In some embodiments, authorizations may also depend on external factors. For example, an authorization token may specify that a mobile worker has permission to perform a target function during a particular time period, during a particular plant event (e.g., during a shutdown of an area of ​​the plant), etc.

[0075] In addition, the supervisor engine 106, and in particular the work item scheduler 308, may schedule work items according to external factors that may result in changes in production schedules or significant downtime, among other things (but not exclusively). For example, the supervisor engine 106 may communicate with systems external to the process plant via the network backbone 105 and gateways 78 to obtain data related to weather, delivery of raw materials or other supplies, delivery of parts, tools, or equipment required to perform the work items, product dispatch schedules, and the like. As a non-limiting example, the work item scheduler 308 may delay the scheduling of a work item if the work item would interfere with production and if a shipment of perishable raw materials is scheduled to be received prior to the completion of the work item. As another example, a particular work item at an outdoor location may require dry conditions (i.e., no rain) for the completion of a target function (e.g., checking out wiring), and the work item scheduler 308 may schedule the work item according to a weather forecast.

[0076] A method 500 for assigning tasks to process plant personnel is depicted in a flow chart in FIG. 5. The method 500 may include receiving data from an expert system (block 505) and creating a work item that specifies the task according to the data received from the expert system (block 510). The method may also include selecting a person to perform the task specified in the work item (block 515), sending the work item to a device associated with the selected person (block 520), and receiving an indication that the selected person has received the work item (block 525). Receiving data from the expert system may include receiving data indicative of a predicted problem in the process plant, receiving data indicative of a trend associated with a process parameter, receiving a request to provide a parameter value to an expert system, receiving an instruction to perform a particular action with respect to a process control device, and the like. When receiving data includes receiving a request to provide a parameter value, creating the work item may include creating a work item where the specified task is to observe and record a parameter value that is not automatically transmitted from a device that senses or otherwise receives the parameter. Creating a work item, in some embodiments, may include creating a work item where a specified task is to perform a maintenance task, a calibration task, a replacement task, an inspection task, or a repair task. Creating a work item may also include specifying a target equipment associated with the specified task (e.g., a piece of equipment on which the specified task is to be performed). Selecting a person to perform the task may include selecting a person according to location data received from a device associated with the selected person (e.g., a mobile user interface device, a GPS device, a proximity card device, etc.). The method 500 may also include creating and storing an authorization token associated with the specified task, associated with a process control device associated with the specified task, or both.The authorization token may be required for the selected person to perform the specified task on a process control device associated with the specified task. The authorization token may be an entry in a database, a separate file, or any computer structure implemented for the purpose of creating and / or granting authorization for a person to perform an action on or related to a piece of equipment. Selecting a person to perform a task may also include selecting a person according to a task specified in the work item, a process control device associated with the specified task, or both, and a plurality of personnel profiles accessible to the supervisor module. In some embodiments, selecting a person according to a plurality of personnel profiles includes selecting a person according to skills, duties, certifications, and / or credentials. Selecting a person may also or alternatively include storing a work item in a database to select a work item for the person to perform and / or receiving a request to perform the work item from a device associated with the person, and comparing a profile associated with the person to information stored in the work item to determine whether the person is qualified to perform the work item.

[0077] Receiving data from the expert system may include receiving instructions to perform actions such as observing and recording parameters, inspecting a process control device, calibrating a process control device, recording an audio sample, capturing an image or video, performing maintenance on a process control device, repairing a process control device, replacing a process control device, and / or adjusting a process control parameter. Creating a work item may include specifying tools or equipment essential to perform a specified task, a priority level for the work item, necessary skills essential to perform a specified task, a required start time and / or start date, and / or a required completion time and / or completion date. Method 500 may also include scheduling the execution of the work item according to a scheduled route through the process plant associated with the selected person, scheduled delivery of input materials for a process performed by the process plant, scheduled delivery of products produced by the process plant, forecasted weather conditions, scheduled dispatch time of products produced by the process plant, forecasted or scheduled completion time of a process of the process plant, and / or forecasted or scheduled arrival of tools, equipment, or parts essential to complete the specified task.

[0078] Referring again to FIG. 3, the supervisor engine 106 may also store (or otherwise access) documentation, such as equipment manuals, maintenance manuals, and standard operating procedures (SOPs) 316. The documentation may be provided automatically to the mobile operator via the UI device 112 as the mobile operator performs tasks in the process plant or associated with a particular work item. In some embodiments, the documentation is provided to the mobile operator at appropriate (i.e., useful) points during the performance of a target function associated with the work item. For example, personnel performing a wiring checkout function associated with the work item may be presented with an SOP for performing the wiring checkout. As another example, personnel performing routine maintenance of a valve (e.g., lubricating, cleaning, etc.) may be presented with an SOP for each procedure and / or manual for the target valve. In some embodiments, personnel are provided with the appropriate portion of the documentation at each step in the process of performing the target function. That is, the maintenance personnel may first be presented (via the mobile UI device 112) with an SOP for locking out and taking the valve out of service. The maintenance personnel may then be presented with pages from the valve's operating manual that pertain to cleaning and / or lubricating the valve. Later, the maintenance personnel may be presented with SOPs for returning the valve to operation and removing the device lockout. Of course, these examples are not intended to be limiting, as there are many situations in which personnel may be presented with SOPs and manuals in the course of performing their duties.

[0079] As the mobile operator or technician performs a goal task associated with the work item, the supervisor engine 106, and in particular the work item tracking module 318, may track the progress of the tasks associated with the work item. In some embodiments, the supervisor engine 106 cooperates with the mobile UI device 112 to guide the mobile operator through each step of one or more processes required to perform the work item. The guidance may include lockout procedures, shutdown procedures, device disassembly, device repair, maintenance steps such as calibration, lubrication, checkout and verification procedures, device reassembly, start-up procedures, unlocking procedures, and any other steps of the process. The work item tracking module 318 may communicate with the mobile UI device 112 to receive an indication, for example, when the mobile operator requires a subsequent instruction, step, or guide. As the work item tracking module 318 receives an indication that a subsequent instruction, step, or guide is required, the work item tracking module 318 may consider the previous step to be completed, thereby tracking the progress of the execution of the work item. In some embodiments, the work item tracking module 318 may be operable to communicate with the target equipment (i.e., the equipment that is the subject of the work item) or equipment adjacent to or communicatively coupled to the target equipment to verify that one or more of the steps are completed. In yet another embodiment, two mobile operators may be involved in a collaborative session, and as one mobile operator completes each step of a work item presented to the technician via the mobile UI device 112, the second technician may mark each step as complete on another UI device 112 and send an indication to the work item tracking module 318 that each step is completed. That is, two users collaborating using their respective UI devices 112 do not need to see the same indications of information, or even the same information at all. As another example, a first user may be viewing a standard operating procedure for performing a work item on a first UI device 112, while another user may be viewing live data related to one piece of equipment associated with the work item on a second UI device 112.When a work item is completed, the supervisor module 106, and in some embodiments the work item tracking module 318, may mark the item as completed, remove it from the list of active work items, remove or revoke any permissions associated with the work item, assign another work item, notify personnel that the work item is completed, notify personnel that dependent work items can be started (i.e., work items that are dependent on the previous work item that is completed before it can be started), etc.

[0080] Referring to FIG. 6, a flow chart depicts a method 600 for managing a workflow in a process plant. The method 600 includes creating a work item that specifies a task to be performed in the process plant (block 605), determining a set of procedures for performing the work item from the specified tasks (block 610), generating an associated display for each procedure in the set of procedures (block 615), and sequentially displaying the set of associated displays on the mobile user interface device in the order in which the set of procedures are to be performed (block 620). Creating the work item may include receiving data from an expert system and / or specifying a task according to the data received from the expert system. Receiving data from the expert system may include receiving an instruction to perform a particular action on the process control device. Creating the work item may also or alternatively include specifying a maintenance task, a calibration task, a replacement task, an inspection task, and / or a repair task. Creating the work item may also include specifying a task that requires a safety lockout procedure, a shutdown procedure, and / or a startup procedure, etc. Generating the associated views may include generating a view presenting a set of steps for performing a procedure, generating a view including one or more images depicting performance of a procedure, generating a view including an image of a target piece of equipment in relation to its surroundings to assist a person in locating a target piece of equipment, generating a view including parameter input fields for recording parameters associated with the target piece of equipment, and / or generating a view including a set of standard operating procedures. The method may also include depicting a location of the target piece of equipment in relation to the process plant on a display of the mobile user interface device, which may include providing a user interface control that causes the view to zoom in on the target piece of equipment and / or providing a set of user interface controls to enable a user of the mobile user interface device to navigate among the set of associated views.In some embodiments, a procedure context pane may be displayed indicating which procedure of the set of procedures associated with the specified task is currently being performed. The method may also include providing access to documentation related to a target piece of equipment associated with the specified task. Additionally, the method may include determining a set of tools and equipment required to perform the set of procedures, generating a display of a checklist including a list of the determined set of tools and equipment, and displaying the checklist. Creating a work item may include specifying a manual data collection task. Determining the set of procedures may include determining a route for collecting the manual data.

[0081] The Supervisor Engine 106 may also store data related to the execution of the work items. In particular, the Supervisor Engine 106 may store data captured by the Mobile UI Device 112 related to the execution of the work items, data related to the impact of the execution of the work items on the operation of the process plant (e.g., variations in the performance of the process plant caused by or correlated with the execution of the work items), etc. In some embodiments, the Mobile UI Device 112 may capture video, audio, or vibration data as part of a diagnostic procedure or a repair or maintenance procedure, and the Mobile UI Device 112 may transmit the captured data back to the Supervisor Engine 106, which may store the data when related to a particular work item, or alternatively or additionally store the data in the Big Data appliance 102.

[0082] Checklist Referring again to FIG. 3, the supervisor engine 106 may perform other tasks related to supervising the mobile personnel. By way of example only, the supervisor engine 106 may include a checklist generation routine 314. The checklist generation routine 314 may generate a checklist for the mobile personnel that corresponds to the work items assigned to the mobile personnel. The checklist generated by the routine 314 may include, for example, safety equipment required for an area or procedure (e.g., respirators, harnesses, carabiners, radiation detection devices / dosimeters, etc.), tools essential to perform the procedure, parts required to perform the procedure (e.g., replacement or maintenance parts, such as seals, lubricants, etc.), etc. The checklist generation routine 314 may generate the checklist and, in some embodiments, store the checklist when associated with the work item. Alternatively, the checklist generation routine 314 may generate and display the checklist in real time. In any case, it is contemplated that the checklist is presented to the mobile personnel shortly before the work item is performed. For example, the checklist may be automatically presented to the mobile operator when the mobile operator indicates that he or she is preparing to perform the work item. In another embodiment, the checklist may be manually requested by the mobile operator when the operator is preparing to perform the work item. In some embodiments, the supervisor engine 106 determines that the operator is preparing to perform the work item and automatically presents the checklist to the mobile operator. For example, the supervisor engine 106 may receive an indication that the mobile operator has transmitted the state of the workstation UI device 112 to the mobile UI device 112 at the time the work item is scheduled to be performed. Upon detecting the transmission of the state, the supervisor engine 106 may present the mobile operator with a checklist that prompts the mobile operator to acknowledge that the mobile operator has the appropriate equipment and resources to perform the work item.Alternatively, the Mobile UI device 112 may automatically retrieve the checklist (e.g., from the supervisor engine 106) when the mobile operator opens a work item, preferably before entering the process plant environment. In yet another embodiment, the Mobile UI device 112 may detect when it has entered an equipment or staging room and may automatically present the checklist to the mobile operator so that the mobile operator may gather the necessary tools, equipment, and supplies.

[0083] Referring now to FIG. 7, a flow chart depicts a method 700 for facilitating task completion in a process plant. The method includes receiving a selection of a work item from a plurality of work items stored in a database of work items (block 705), and determining from the selected work item one or more items required for performance of the work item (block 710). A checklist of the one or more items is generated for display to a person performing the work item (block 715), and the checklist is displayed to the person performing the work item (block 720). In one embodiment, determining the one or more work items from the selected work items includes retrieving one or more fields of the work item, which may include retrieving a required equipment field, a required safety gear field, a required tools field, and / or a field indicating a location of a target piece of equipment within the process plant. Retrieving the one or more fields may include retrieving a field specifying a target task to be completed. Retrieving the fields may include retrieving a field specifying a target task to be completed and a target equipment or target equipment type. Additionally, determining the one or more items required for performance of the work item may include determining the task to be completed, the equipment on which the task to be completed is performed, or both. Generating a checklist of one or more items for display to a person performing the work item may include generating a checklist that includes any one or combination of a piece of safety equipment, tools, process control devices, parts for the process control devices, maintenance materials, etc. Generating the checklist may include retrieving information from one or more of equipment manuals associated with the process control devices associated with the work item, equipment manuals associated with tools required to perform the work item, safety documentation, standard operating procedures, and / or documentation associated with the location of the process control devices associated with the work item.Generating the checklist may also include, in some embodiments, determining locations through which personnel associated with or assigned to the work item will have to travel to get to a location associated with the work item and retrieving special safety equipment and / or tools required to access or pass through the locations. Displaying the checklist to a person performing the work item may include receiving an indication that a user assigned to perform the work item has activated a mobile user interface device and displaying the checklist to the user on the activated mobile user interface device. Receiving a selection of the work item may include receiving a selection on a first user interface device, and displaying the checklist to a person performing the work item may include receiving an indication that a state of the first user interface device is being transmitted to a second user interface device and displaying the checklist on the second user interface device. Method 700 may also include receiving, for each of one or more items on the checklist, an indication that a person viewing the displayed checklist has the item.

[0084] UI devices FIG. 8 is a block diagram of a UI device 803 in the context of a mobile control room 800. The mobile control room 800 may enable the UI device 803 to transmit a state of operation to another system or device and / or receive a UI state of operation from another system or device. The mobile control room 800 also includes a UI device 803a, a server 150, and a UI device 803b. Each of the UI devices 803, 803a, 803b may be any one of various UI device types described below with reference to FIG. 9B. The server 150 may include web services or web routines 152 that may be stored in a memory at the server 150 and executed by a processor at the server 150. Each of the UI devices 803a and 803b (as well as any other UI device 803) includes a processor 810, a memory 815, a display 820, a network interface 825, an input interface 830, a system bus 835, and one or more transceivers 850. The UI devices 803a, 803b may also include one or more positioning devices including, for example, a global positioning system (GPS) (or any other satellite navigation system) receiver 832, an inertial positioning system chip 834, individual positioning components such as a compass 836, a gyroscope 838, an accelerometer 840, etc. The memory 815 may include an operating system 880, a user interface ("UI") routines 882, context awareness routines 884, state determination routines 886, a browser routine 888, an image capture routine 890, and a sound capture routine 892, local process control data storage 894, UI state information 896, and other data. In some embodiments, one or more of the operating system 880, the UI routines 882, the context awareness routines 884, and / or the state determination routines 886 may reside in memory external to the UI device 803 and may be executed by a processor external to the UI device 803 (e.g., in a device or system such as the server 150). It should be understood that the mobile control room 800 described herein is merely an example, and other configurations are contemplated.For example, the mobile control room 800 need not include multiple UI devices, and in fact need not include any particular number of UI devices.

[0085] In particular embodiments of the memory 815 of the UI device 803, the memory 815 may include volatile and / or non-volatile memory, and may be removable or non-removable memory. For example, the memory 815 may include computer storage media in the form of random access memory (RAM), read only memory (ROM), EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage device, or any other medium that can be used to store the desired information. The processor 810 is configured to fetch and execute the instructions stored in the memory 815. The memory 815 may store data, such as operating system data or program data.

[0086] The network interface 825 may include or be coupled to one or more antennas for wireless communication, one or more ports for wired connections, or both. In some embodiments, the network interface may be coupled to a GPS receiver 832 that allows the network interface 825 to receive location or coordinate data. The network interface 825 may also, or alternatively, include a Bluetooth transceiver that allows the network interface 825 to establish a personal area network with an external device or system. Additionally or alternatively, the network interface may include a near field communication ("NFC") transceiver, a radio frequency identification ("RFID") transceiver, and / or a local area network transceiver (enabling the network interface 825 to communicate using, for example, an IEEE 802.11 protocol).

[0087] The network interface 825 may communicate with the server 150 and / or one of the UI devices 803 over a network, such as the process control network 100 shown in FIG. 1A. A user may interact with the UI device 803 through an input interface 830. The input interface 830 may receive input through mechanical movement (e.g., a keyboard or mouse). The input interface 830 may alternatively or additionally receive input through detection of an electromagnetic field, signal, or property (e.g., a resistive or capacitive touch screen). Furthermore, the input interface 830 may receive input through detection of sound, light, or motion (e.g., audio input via a microphone 842, an image sensor, or a camera 844, etc.). Furthermore, the input interface 830 may receive input from a Bluetooth device coupled to the network interface 825. The display 820 may provide output in the form of an image or video and may use any type of monitor, projector, or display technology, including CRT, LCD, plasma, LED, and OLED technologies.

[0088] In some embodiments, one or more input sources, such as a microphone 842, an image sensor or camera 844, or other sensors (e.g., oxygen sensors, toxic gas sensors, motion sensors, vibration sensors, RFID sensors), may be located external to the UI device 803 and coupled to the UI device 803 via a wired communication channel (e.g., via a headphone port or USB port) or a wireless communication channel (e.g., wireless USB, Bluetooth, Wi-Fi, or a proprietary protocol). For example, a user carrying the UI device 803 may also carry one or more of the input sources on a utility belt when the UI device 803 is carried.

[0089] Each of the routines 880-896 may be one or more instructions, routines, modules, processes, services, programs, and / or applications and may be stored on a computer-readable medium, such as on the memory 815. The operating system 880 may support basic functions and manage resources of the UI device 803. In particular, the operating system 880 may manage the hardware and software of the UI device 803. The UI routines 882, when executed by the processor, may cause the display 820 to display information to a user and may cause the input interface 830 to receive input from the user or from other external stimuli. The context awareness routines 884 may cause the display 820 to display information in response to context information received at the network interface 825, at the input interface 830, or at one or more sensors. The context awareness routines 884 may additionally or alternatively cause the UI device 803 to identify a context (e.g., a location, a time, or a schedule) and / or receive a context from a system or device external to the UI device 803.

[0090] The state determination routine 886 may collect information about the operation of the UI device 803. For example, the state determination routine 886 may collect UI state information 896 by monitoring processes executed by the processor 810 and data related to the processes. The state determination routine 886 may identify information to be depicted on the display 820 and may identify process entities related to the depicted information. In some embodiments, the state determination routine 886 may transmit the collected UI state information to an external node, such as the server 150 or the UI device 803b. In some embodiments in which the UI device 803 implements a thin client or web client, the state determination routine 886 may be stored in a memory on the server 150 and executed by a processor at the server 150.

[0091] The browser routine 888 may be an application for accessing, presenting, and navigating one or more information resources. The information resources may be web pages, images, videos, documents, or any other content. The browser routine 888 may interact with information resources present on the UI device 803 or with information resources external to the UI device 803. For example, the UI device 803 may access information resources at other systems or devices (e.g., the server 150 or the UI device 803b) via the World Wide Web or via a network such as the process control network 100. In some embodiments, the browser routine 888 may access information related to and / or generated by UI routines executing on the server 150. In particular, the browser routine 888 may access web services 152 at the server 150, which may correspond to UI routines executing on the server 150. For example, the browser routine 888 may receive an address or identifier, such as a unique resource identifier or a uniform resource locator (e.g., from a user via the input interface 830). The address or identifier may direct the browser routine 888 to web services 152. The browser routine 888 may receive UI data, such as display data or process parameter data, from the UI routine 882 via web services 152, allowing the browser routine 888 to render graphics for controlling and / or monitoring some or all of the processes. The browser routine 888 may also receive user input (e.g., a mouse click on a graphic) and transmit data representing the user input to the UI routine 882 via web services 152. In an alternative embodiment, the browser routine 888 may be a plug-in or web client application.

[0092] Although the various routines 880-896 are described as being stored in the memory 815, the UI device 803 may also be operable to request, retrieve, receive, and / or download additional routines (e.g., applications, applets, updates, patches, etc.) as needed via the network interface 825. However, as one of many possible examples, the UI device 112 may request and receive information to facilitate direct (or indirect) communication between the UI device 112 and process control devices in the process plant. In any event, it should be understood that the UI device 112 is not limited to these applications, routines, and modules described herein as resident in the memory 815.

[0093] Image capture routine 890 may operate to capture an image via image sensor or camera 844. In some embodiments, the image may be transmitted via network interface 825 to a node on network 100 where the node may analyze the image to identify process data. For example, in one embodiment, image capture routine 890 may cause image sensor 844 to capture an image of a flame. Image capture routine 890 may transmit the image of the flame to a node (e.g., server 150, expert system 104, etc.) via network 100 where the node may analyze the image to identify the color and corresponding temperature of the flame. Similarly, sound capture routine 892 may be instructions or routines for capturing sound via microphone 842. The captured sound data may be transmitted to a node on network 100 for analysis.

[0094] With regard to capturing sound, the microphone 842 may capture audio associated with the plant asset. The captured audio may be used to identify or diagnose the plant asset. For example, a pump may have an expected sound signature. In such an example, the UI device 803 may capture audio occurring during operation of the plant asset to identify the asset type as, for example, a pump, and may transmit the audio to a node (e.g., server 150, expert system 104, etc.) over the network 100. In some circumstances, the node may cause the UI device 803 to identify the particular pump in question. The UI device 803 may also include a motion sensor (e.g., accelerometer 840) used to detect vibration. For example, a plant asset may have an expected level of vibration during operation. A user may place the UI device 803 on or near the plant asset. The UI device 803 may use data detected by the motion sensor to identify a current vibration level associated with the asset. If the current vibration level exceeds the expected level of vibration, the user may use the UI device 803 to further diagnose the plant asset or request a work order regarding the asset. In some cases, a diagnostic routine may be launched automatically when the UI device 803 is placed on or near the asset to detect vibrations associated with the asset.

[0095] In some embodiments, the UI device 803 may include a peripheral interface (not shown) for establishing a connection with another device. The peripheral interface may be a serial interface, such as a Universal Serial Bus (USB) interface. In another embodiment, the peripheral interface may be a wireless interface for establishing a wireless connection with another device similar to some of the network interface embodiments. For example, in some embodiments, the peripheral interface may be a short-range wireless interface conforming to a standard such as Bluetooth (operating in the 2400-2480 MHz frequency band) or Near Field Communication (operating in the 13.56 MHz frequency band). The peripheral interface may be used to communicate status information to or receive status information from an external device, which will be described later. The peripheral interface may also be used in certain embodiments to interact with an external device, which may provide context awareness to the UI device 803. For example, a context ID device may be detected via the peripheral interface, also as described later. In some embodiments, a user may save status or process information available to the UI device 803 to an external device via the peripheral interface.

[0096] In the general operation of the UI device 803, the processor 810 may access the memory 815 to execute the UI routines 882. As the processor 810 executes the UI routines 882, the processor 810 causes an output to be provided on the display 820, the output representing information about entities (e.g., devices, equipment, network nodes, process data, control data, etc.) in the process plant 10. The output may be based on data stored in the memory 815 (e.g., graphics data, historian data, or any previously received and stored data) or data received via the network interface 825 (e.g., data received from the controller 11 or database 151). Additionally, the input interface 830 may generate input data when an input is received at the input interface 830. The input data may be transmitted to the processor 810 via the system bus 835, where the processor 810 may execute one or more instructions or routines according to the received input. In many instances, the input data may represent a user interaction with a graphical output provided on the display 820. For example, the input data may represent mouse movements, in which case the processor 810 operates to move a cursor displayed on the display 820 according to the mouse movements. The input data may also represent a selection of a UI element displayed on the display 820, such as a window (e.g., a browser window), a device graphic (e.g., a tank, a pump, a valve, a meter, etc.), or an operating system element. Additionally, the input data may represent a control input. For example, a user may use a keyboard, a mouse, or a touch screen to enter a setpoint value for a process device. When the input data represents a control input, the processor 810 may transmit the input data via the system bus 835 to the network interface 825, in which case the network interface 825 transmits the input data to the process control network 100, where it may be received at another node (e.g., the controller 11 or the server 150 shown in FIG. 1A).The processor 810 may also cause any other type of input data to be transmitted to the process control network 100 .

[0097] Status Awareness, Communication, and Collaboration As process control operations, configuration, and maintenance are facilitated by mobile devices, personnel may be expected to move from device to device and, in any event, may want to be able to switch from device to device without having to recreate (and / or re-navigate) on the second device the views the personnel were looking at and / or the processes the personnel were engaged in on the first device. As illustrated in the above example, an operator may want to remotely check the status of the process plant from a mobile phone as the operator heads to work so that the operator is ready for whatever is happening when the operator arrives on-site. When the operator arrives on-site, the operator may want to go to the office and pick up in the same location on the workstation. The operator may then pick up a tablet computer and move to the plant floor to survey areas of the plant or to attend to various tasks. In general, personnel involved in the operation and maintenance of process plants may want the devices they use to include a certain level of status awareness and be able to communicate status between devices to facilitate mobility and / or collaboration.

[0098] In one embodiment of the present disclosure, state information is seamlessly transferred from a first UI device to a second UI device, allowing a user to resume or transfer a session from a first UI device to a second UI device without any interruption in workflow. State transfer may also enable a first user of a first UI device to collaborate with a second user of a second UI device, such that the two users may work on a task or work item in a collaborative manner. In another embodiment, the UI device may provide output according to the context of the operation of the UI device. For example, the UI device may take into account the location of the UI device and the location of the equipment, the type of UI device, or other considerations when determining what information to provide or how to provide information on the UI device display. The UI devices and mobile control rooms disclosed herein provide the advantage of "untethering" operators and users of the UI devices from physical control rooms. Users of such UI devices may move freely around a plant without interruption in workflow and without loss of functionality or capabilities with respect to monitoring and controlling processes.

[0099] 9A illustrates an example mobile control room aspect 900a. The mobile control room 900a includes a UI device 912a, a UI device 912b, and a UI device 912c, which can be used by a user 901 and / or a user 902, respectively.

[0100] The mobile control room 900a may enable the user 901 to synchronize the UI devices 912a and 912b by transmitting the state of the UI device 912a to the UI device 912b. The UI state transfer may cause the UI device 912b to display information similar to that displayed on the UI device 912a. The state transfer may also cause the UI device 912b to execute similar routines or applications as those executed on the UI device 912a. Furthermore, the similar routines or applications on the UI device 912b may execute in the same state as the routines or applications executing on the UI device 92a. By transferring the UI state of an operation from the UI device 912a to the UI device 912b, the user 901 may stop using the UI device 912a and start using the UI device 912b without any loss in workflow.

[0101] Similarly, the control room 900a may enable a secure collaborative session to be established between at least two UI devices. In one embodiment, the secure collaborative session may be automatically established when two devices 912 move into each other's vicinity and recognize each other. Once the session is established, synchronization of data between the UI devices may occur during the collaborative session. More specifically, user 901 may collaborate with user 902, in which case UI device 912b may communicate state information to UI device 912c. By communicating state information from UI device 912b to UI device 912c, UI device 912c may identify the state of operation of UI device 912b. For example, UI device 912c may depict the same or similar information as displayed on UI device 912b. UI devices 912b and 912c may also launch communication routines that enable users 901 and 902 to exchange information (e.g., text, video, and voice over IP) via UI devices 912b and 912c. For example, UI devices 912b and 912c may exchange information regarding work items or tasks to enable users 901 and 902 to work on the items or tasks in a coordinated manner even when users 901 and 902 are not seeing the same view on their respective UI devices 912b and 912c. In one example, a user may be able to check out a device via a UI device so that other users know the device is being addressed.

[0102] In some embodiments, the UI devices 912a-912c may communicate status information directly between each other. The UI devices 912a-912c may use short-range wireless technologies such as near-field communication (ISO / IEC 14443 and 1809 standards) to detect proximity and then use WiFi (IEEE 802.11 standard) or Bluetooth (IEEE 802.15.1 standard) to communicate status information. In another embodiment, the UI devices 912a-912c may communicate status information through a node such as the server 150 shown in FIG. 1A via the network backbone 105. In certain embodiments, the UI devices 912a-912c may be thin clients, in which case the UI devices 912a-912c may render graphics, but the majority of the processing for the UI devices 912a-912c occurs at a node on the process control network 100 (e.g., the server 150 shown in FIG. 1A). In such an embodiment, communicating state between UI devices 912a-912c may include communicating state information between UIs executing on the nodes.

[0103] 9B illustrates the UI devices 112 in an example mobile control room 900c. The mobile control room 900c may enable communication of the state of operations between any of the UI devices 112a-112k to enable UI device synchronization and user collaboration. The mobile control room 900c includes a server 150, a process control network 100, a user 901, and the UI devices 112a-112k. The server 150 may include a database 151, which may include display data, parameter data, historian data, context data, UI state information data, or any other process plant data. The database 151 may be stored in a memory on the server 150, separate from the server 150, or among several devices in the process plant. Each of the UI devices 112a-112k may be any type of process control UI device 112 that provides information about a process or an element associated with a process, and receives user input regarding a process or an element associated with a process. Each of the UI devices 112a-112k may execute a corresponding UI. In alternative embodiments, the UI may execute in whole or in part on the server 150 and be provided to the UI devices 112a-112k, for example, via a web page. Each of the UI devices 112a-112k may communicate with the server 150 via the backbone 105 of the process control network 100. In the embodiment shown in FIG. 9B, a user 901 may interact with the UI device 112a through a display 920 and an input interface 930 (although the user 901 may interact with any of the UI devices 112a-112k).In this embodiment, UI device 112a is a stationary workstation, input interface 930 is a keyboard, display 920 is a monitor, UI device 112b is a mobile device (e.g., a phone or PDA), UI device 112c is a tablet capable of receiving touch input from a user's hand or stylus, UI device 112d is a wearable device (in this case a watch with a touch screen), UI device 112e is a laptop computer, UI device 112f is a wearable device (in this case a headset with a heads-up display), and UI device 112g is a computer that includes a keyboard, mouse, and keyboard. The UI device 112a-112k may be a television that may have an associated input interface (not shown) such as a touch screen (e.g., a capacitive touch screen), a motion sensor, or any other type of device capable of receiving user input, the UI device 112h is a display and user input device (e.g., a touch screen) present in the process plant environment (e.g., mounted on a wall, mounted on or near a process entity, etc.), and the UI device 112j is a mobile device (e.g., a smartphone) with a built-in projector operable to project a UI onto a surface 112k (e.g., a wall within the process plant). The UI projected onto the surface 112k may include a user input method (e.g., tracking of a user's movements via the UI device 112j or an external device (not shown)). Of course, any combination of the UI devices 112a-112k may be employed in various embodiments. Additionally, the mobile control room 900c may include additional UI devices similar to any of the UI devices 112a-112k. It is noted that although particular types of input are described as being associated with each of devices 112a-112k, in various embodiments any of devices 112 may receive input from various input sources, depending at least on the type of use for the UI device 112.By way of example only, it is contemplated that UI device 112 may receive a stylus to facilitate input from a user, i.e., from a user wearing protective gloves, or may be a touch-sensitive device that is not capacitive in nature (e.g., resistive, surface acoustic wave, or any other type of touch screen technology). Voice input may also be used with any of UI devices 112, particularly in environments where external noise is not a factor.

[0104] In the mobile control room 900c, each of the UI devices 112a-112k may enable a user 901 to monitor and / or control processes or elements associated with the process via the process control network 100. In one embodiment, each of the UI devices 112a-112k may implement a web client or a thin client. In such an embodiment, the server 150 may execute the UI and any other routines used for operation of one or more of the UI devices 112a-112k. The UI devices 112a-112k may pass user input data to the server 150, where the server 150 may respond to the user input. The server 150 may transmit display data to the UI devices 112a-112k. Because server 150 may handle most of the processing of the operation of UI devices 112a-112k in this embodiment, server 150 may track the status of operation of each UI device 112a-112k by monitoring the execution of routines on server 150 and by monitoring data being sent to and received from each of UI devices 112a-112k.

[0105] In another embodiment, UI devices 112a-112k act simply as data clients. For example, in some embodiments, each UI device 112 includes a web browser and routines that automatically generate dynamic HTML (or other code) for displaying information on the UI device 112. The routines and / or dynamic web pages generated by the routines retrieve data from server 150 and display the retrieved data (and other data, such as user-entered data) on the display. The routines and / or dynamic web pages may also receive user input and send data back to server 150. In such an embodiment, much of the processing occurs on the UI device 112, with only data being transmitted to and from server 150 over the network.

[0106] In another embodiment, instructions (e.g., JavaScript® instructions) resident on the UI device 112 dynamically generate code (e.g., HTML5 code) that is rendered in an appropriate viewing application (e.g., an HTML5 viewer or web browser). For example, the JavaScript code may open a WebSocket connection used by the WebSocket application messaging protocol to send messages between JavaScript running on the UI device 112 and the server 150.

[0107] Server 150 may store UI state information (e.g., in database 151) periodically or in response to a trigger event. The UI state information may represent the state of the UI device at the time of capture. The UI state information may include information related to a user or operator interacting with the UI device, an application, program, routine, or module executing on the UI device, graphics or sounds being presented on the UI device, a part of the plant to which the displayed data pertains, or any other information related to the operation of the UI device. When server 150 receives a state transfer request, server 150 may access the UI state information stored locally in database 151 and transmit the UI state information to an appropriate UI executing on server 150. The UI may transmit the corresponding display data to the appropriate UI device. For example, UI device 112b may request state information from UI device 112a (where user 901 may, for example, want to switch UI devices from 112a to 112b without interrupting workflow). In some embodiments, UI devices 112a and 112b may each have a UI executing on server 150. Server 150 may access UI state information stored locally in database 151 and may pass the UI state information to the UI of UI device 112b. The UI of UI device 112b may determine what should be displayed on UI device 112b based on the stored UI state information and communicate the display data to UI device 112b.

[0108] In some embodiments, each of UI devices 112a-112k may capture and store UI state information in database 151 as a user interacts with the respective UI device. The UI devices may transmit the UI state information to server 150 over network 100. For example, upon receiving a request from a particular one of UI devices 112a-112k, server 150 may transmit the UI state information to one of UI devices 112a-112k such that the particular UI device may operate in a manner consistent with the received UI state information.

[0109] As an example, a user 901 may begin using the UI device 112a (although the following example may be performed with any of the UI devices 112b-112k as well). As the user 901 interacts with the UI device 112a, the UI device 112a may periodically capture and store UI state information. UI state information may be associated with the user 901, for example, indicative of a user ID or a user's job title / role. The UI state information may also relate to the user's session, including information about the program or routine running on the UI device 112a, the capture time, the session length, the configuration of the graphics displayed on the display 920 of the UI device 112a, the entities (i.e., process areas, devices, equipment, or data) being monitored or controlled by the UI device 112a, and / or the type of UI device being used (in this case, a stationary workstation). After capturing and storing the UI state information, the UI device 112a may transmit the UI state information to the server 150 via the process control network 100 so that the server 150 may store the UI state information in a database 151.

[0110] User 901 may decide to use a mobile UI device, such as any of UI devices 112b-112f or 112i-112k. In one embodiment, user 901 may use UI device 112b, in which case UI device 112b may recognize user 901. UI device 112b may communicate with server 150 to retrieve most recent UI state information related to user 901 (i.e., the most recent UI state information captured in UI device 112a in this case). In some embodiments, the communication may trigger additional capture of state information related to UI device 112a at UI device 112a. UI device 112b may generate a GUI configuration based on the received UI state information such that the display of UI device 112b corresponds at least in part to the display of UI device 112a at the time of capture of the most recent state information. Stated another way, the mobile control room 900c operates to communicate or synchronize state between the UI devices 112a and 112b (see FIG. 10 as an example of what a display may look like in a UI sync or state communication). As a result of the state communication, the user 901 experiences minimal interruption in the workflow.

[0111] In some embodiments, capture of UI state information may occur automatically. For example, the UI device 112a may capture state information at a predetermined periodicity (e.g., capture state information every 5, 10, or 30 minutes). The UI device 112a may also capture state information in response to a triggering event or activity. The triggering event may be related to user input (e.g., capture state information any time a user input is received or on a schedule correlated to receipt of user input) or information provided by the UI device 112a (e.g., capture state information any time an alarm goes off or any time a particular measurement or value reaches a specified threshold). Alternatively or in addition, the UI device 112a may manually capture UI state information in response to a user input representing a command to capture or communicate UI state information. For example, the display 920 may provide a graphic with which the user 901 may interact to cause the capture. The input interface 930 may also have a mechanism (e.g., a button, key, or trackpad) that allows the user 901 to initiate the capture. In certain cases, a request by another UI device (e.g., one of UI devices 112b-k) may also trigger capture at UI device 112a. As another example, UI devices 112a-112k may capture and communicate state information (e.g., via near field communication) when two UI devices are touched (or brought into close proximity of each other, e.g., within 5 cm, 2 cm, 1 cm, etc.).

[0112] In further embodiments, the UI device 112b may automatically recognize the user 901. For example, the user 901 may have a unique tag (e.g., on a badge or card with an RFID chip) that identifies the user 901. In another embodiment, the tag may be any tag or device that can provide identification information, such as an NFC device, a barcode, a Bluetooth device, or any other wireless access point. The UI device 112b may have a tag scanner or reader (e.g., an RFID scanner) that detects the unique tag. The UI device 112b may access a database to identify a user associated with the unique tag that allows the UI device 112b to recognize the user 901. The database may be on the UI device 112b, but in another embodiment, a database 151 on the server 150 may correlate the tag with a user and the UI device 112 may communicate with the server 150 to identify the user 901. In another embodiment, each UI device may be assigned to a specific user such that only one user interacts with the UI device. In such an embodiment, the UI device 112b may be assigned to the user 901 such that the UI device 112b may assume that any user that interacts with the UI device 112b is the user 901. Alternatively, the UI device 112b may have the user 201 enter a user ID and password to log on to the UI device 112b so that the UI device 112b can recognize the user 901.

[0113] In an alternative embodiment, user 901 may use another UI device, such as one of UI devices 112c-112k instead of UI device 112b, which causes state transfer or state synchronization from UI device 112a to one of UI devices 112c-112k. For example, user 901 may synchronize a tablet, such as UI device 112c, with the latest captured state information at UI device 112a. In other cases, user 901 may synchronize a watch, such as UI device 112d, a laptop, such as UI device 112e, a headset, such as UI device 112f, or a television, such as UI device 112g, with the latest captured state information at UI device 112a.

[0114] Additionally, state information of the UI device 112a may be transmitted to the UI device 112a to allow the user 901 to save a session on the UI device 112a and resume the session on the same UI device 112a at a certain later point in time. The UI device 112a may return to a previous UI state by accessing state information saved on the UI device 112a or the server 150. This is in contrast to some prior art systems where resuming a session at a later point in time may be difficult due to multiple users interacting with the same console, even on the same device.

[0115] In further alternative embodiments, user 901 may use any of UI devices 112b-112k instead of UI device 112a. Each UI device used by user 901 may capture state information for the respective UI device. The captured state information may be passed to server 150, where the state information may be stored in database 151 and accessed by the same UI device or another UI device.

[0116] In some cases, server 150 may be a UI device similar to any of UI devices 112a-112k (i.e., server 150 may include a display and an input interface and may be used as a UI device). In such a scenario, state information stored at server 150 may be accessed to provide UI information at server 150 such that a user may use server 150 as a UI device. Similarly, in some embodiments, any of UI devices 112a-112k may operate as server 150 similar to server 150.

[0117] In another embodiment, the UI devices 112a-112k may communicate state information to each other over the network 100 or over some other network or communication, such as a personal area network (e.g., a Bluetooth network) or near field communication. In some embodiments, the receiving UI device may initiate the UI state information communication, while in other embodiments, the transmitting UI device may initiate said communication. In yet another embodiment, the state communication may be performed by storing the UI state information in a memory (e.g., memory on a USB thumb drive) and accessing the memory to retrieve the UI state information at the second UI device.

[0118] In certain embodiments, state transfer may be automatic and transparent to a user of any of the UI devices 112a-112k. For example, state transfer may be initiated automatically when a UI device is brought into proximity of another UI device. The UI devices may include circuitry, such as NFC circuitry, that allows the UI devices to detect each other. Proximity may also be detected by location data received, for example, by a GPS receiver that may be included in one or more of the UI devices. The UI devices may transmit the location data to the server 150, where the server 150 may use the location data to determine proximity and initiate state transfer. In some embodiments, one or more of the UI devices may display an indicator graphic indicating that the respective UI device is receiving or transmitting state information. The indicator graphic may also indicate that the UI device is collaborating with another UI device.

[0119] FIG. 10 illustrates an exemplary device display related to UI synchronization between UI devices 803a and 803b, such as may occur during or after a state transfer. In FIG. 10, UI device 803a may be a stationary workstation and UI device 803b may be a mobile device (e.g., a tablet). UI device 803a includes a display 820a and an input interface 830a. Display 820a may provide a GUI configuration 1010a including a tank graphic 1015a, a level indicator graphic 1016a, a pump graphic 1020a, a valve graphic 1025a, a valve graphic 1030a, a graph 1035a, a graph 1040a, and a graph 1045a. UI device 803b includes a display 820b and an input interface 830b. The display 820b provides a GUI configuration 1010b that includes a tank graphic 1015b, a level indicator graphic 1016b, a pump graphic 1020b, a valve graphic 1030b, and a graph 1040b.

[0120] The UI device 803a may capture the UI state information 896 and transmit the UI state information 896 to another UI device, such as the server 150 or the UI device 803b. When capturing the UI state information 896, the UI device 803a may determine which entities are related to the output provided on the display 820a. For example, the UI device 803a may identify the entities related to the graphics 1016a-1045a (the tank, the pump, the two valves, and the devices related to the graphs 1035a-1045a) and save the entities as the state information 896. In addition to identifying the aforementioned entities, the UI device 803a may also identify coordinate locations related to the graphics provided on the display 820a. As a result, the UI state information 896 may reflect, for example, that the tank graphic is in the center of the screen. The UI device 803a may also identify the locations of various windows or boxes related to any running applications. Additionally, the UI device 803a may identify programs or routines executing on the UI device 803a and may store information indicative of each program state. For example, a browser may be running and the UI device 803a may identify resources (e.g., web pages, images, videos, or some other content) being accessed or used by the browser.

[0121] The UI device 803b may receive UI state information 896 from the UI device 803a (or from the server 150 in another embodiment). The UI device 803b may provide an output based on the received UI state information 896. In particular, the UI device 803b may display a visual representation or graphics on the UI display 830b based on the received UI state information 896. Because the UI device 803b may be a different type of device with a different size display than the UI device 112a, the UI device 112b may provide a different GUI configuration than that provided by the UI device 112a. In particular, the UI device 112b may identify the highest priority entities and programs from the UI state information 96 and generate the GUI configuration 1010b accordingly. In particular, the UI device 803b may identify entities related to the graphics 1015b, 1016b, 1020b, 1030b, and 1040b as high priority. Due to limited screen space, UI device 803b may not generate graphics that correlate to graphics 1025a, 1035a, or 1045a depicted on display 820a of UI device 803a. UI device 803b may also generate graphics in locations of GUI configuration 1010b that correlate to the relative locations of corresponding graphics in GUI configuration 1010a.

[0122] Additionally, due to having a different type of input interface (i.e., based on touch of a screen rather than based on a keyboard), UI device 803b may generate graphics that are a different size and shape than the graphics generated by UI device 803a. For example, UI device 803b may generate larger graphics that are easier to interact with by touch.

[0123] In some embodiments, particularly in some embodiments where UI device 803a and UI device 803b are the same type of device, the GUI configuration 1010b of UI device 803b may be identical to the GUI configuration 1010a of UI device 803a. In yet other embodiments, the GUI configuration 1010b may have very little correlation with the GUI configuration 1010a. In some cases, for example, the output provided on display 830b of UI device 803b may be partially or completely text-based. Even in such embodiments, UI device 803b may still use UI state information 896 to determine the process entity about which UI device 803b should provide information. For example, even if UI device 803b does not display a graphic corresponding to tank graphic 1015a of UI device 803a, UI device 803b may still determine that the tank is a high priority entity and may provide information about the text (e.g., the tank level value in text corresponding to tank level indicator 1016a).

[0124] FIG. 11 is a flow chart illustrating one exemplary method 1100 of synchronizing UI devices 112. Other exemplary methods will be described below, and the method 1100 is not intended to be limiting. As described above, synchronizing UI devices 112 may allow a user to resume a previous session from the same or another device, and may allow two or more users to collaborate by exchanging information. The method 1100 may be implemented, in whole or in part, by one or more devices and systems such as those shown in FIGS. 1-10. The method 1100 may be implemented as a set of instructions, routines, programs, or modules on the memory 815 of the UI device 112, and may be executed by the processor 810 of FIG. 8.

[0125] In the method 1100, the UI device 112 receives a request for UI state information 896 (block 1101). The UI device 112 identifies a UI state of a first UI device 112 (block 1105). Identifying the UI state may include identifying output provided on a display of the first UI device 112. Identifying output provided on the display may include identifying visual representations and graphics provided on the display of the first UI device 112 and identifying entities related to said visual representations and graphics. Identifying output provided on the display may also include identifying process parameters provided on the display, identifying GUI configurations on the display, and identifying a UI type or device type of the UI device 112.

[0126] The first UI device 112 may identify a process entity associated with the output provided on the display. The process entity may include process parameter data, a process plant area, a field device, an executing application, or an application state. For example, the first UI device 112 may identify a tank graphic provided on the display. Based on the identification, the first UI device 112 may identify a tank level measurement, a process plant area associated with the tank (e.g., a boiler area), a field device associated with the tank (e.g., an inlet valve to the tank, a discharge pump for the tank, a temperature sensor for the tank material, etc.), an application executing on the first UI device 112 (e.g., a browser, a historian, an alarm management suite, etc.), and / or a state of the executing application (e.g., a resource being accessed or used by the browser, a parameter being used or displayed by the historian, or an alarm being displayed by the alarm management suite).

[0127] After identifying the UI state of the first UI device 112, the first UI device 112 may transmit data representing the identified UI state to the second UI device 112 (block 1110). More specifically, the first UI device 112 may transmit data representing the identified entities to the second UI device 112. In an alternative embodiment, the first UI device 112 may transmit the entity data to the server 150, in which case the server 150 may then transmit the entity data to the second UI device 112.

[0128] After receiving the UI state information 896 at the second UI device 112, the second UI device 112 may provide an output corresponding to the received UI state, and more specifically, the received entity data. For example, the second UI device 112 may provide the identified process parameter data (i.e., the process parameter data provided at the first UI device 112) on the display. The second UI device 112 may also generate a graphical overview of the identified one or more plant areas (i.e., the areas associated with the output identified at the first UI device 112) on the display. Additionally or alternatively, the second UI device 112 may generate a graphical representation of the one or more identified field devices (i.e., the devices associated with the output provided at the first UI device 112) on the display. The second UI device 112 may also launch an application corresponding to the identified application (i.e., the application running at the first UI device 112). Finally, the second UI device 112 may cause one or more applications to enter the identified state (ie, one or more application states identified on the first UI device 112).

[0129] 11 , the UI device 803 may capture UI state information 896 and transmit the state information to the process control network 100. The UI state information 896 may represent the state of the UI device 112 at the time of capture. The processor 810 may operate to capture the UI state information 896 by causing the memory 815 to store data representing the UI state. The processor 810 may retrieve the UI state information 896 from the memory 815 and transmit the UI state information 896 to the process control network 100 via the network interface 825. The UI state information 896 may ultimately be received by a node on the process control network 100, such as the server 150. In an alternative embodiment, the UI state information 896 may be transmitted via a peripheral interface (e.g., a USB interface, a WiFi interface, a Bluetooth interface, or an NFC interface), where the peripheral interface transmits the UI state information 896 to another UI device 803.

[0130] As described with respect to FIG. 1A and with respect to FIGS. 12A and 12B below, the UI state information 896 may include information or data such as profile data related to a user or operator interacting with the UI device 803. All or some of the profile data may be received at the input interface 830 or the network interface 825. The processor 810 may cause the input interface 830 or the network interface 825 to transmit the profile data to the memory 815 via the system bus 825. In certain embodiments, the processor 810 may generate profile data in response to data received from the input interface 830 or the network interface 825, the data related to a user of the UI device 803 or a similar UI device 803. In other embodiments, the profile data may already exist on the memory 815, in which case the processor 810 may access the profile data or store the profile data under a different data structure (e.g., the processor 810 may access profile data collected during operation of the operating system 880 or another application on the UI device 803, and the profile data may be stored in a specific database used for UI state transfer operations).

[0131] In addition to profile data, UI state information 896 may also include session data related to output (i.e., graphics or sound) provided by UI device 803, and related to applications executing on UI device 803 and the state of each application. Stated differently, in the illustrated embodiment, processor 810 may generate session data based on output provided on display 825 and based on data generated or used during the operation of other applications executed by processor 810. In addition to user profile data and session data, UI state information 896 may include any other data related to the operation or state of UI device 803.

[0132] In another embodiment of the UI device 803, the UI device 803 may receive UI state information 896 from the process control network 100 and may operate to place the UI device 803 in a state corresponding to the UI state information 896. In such an embodiment, the UI state information 896 may represent a previously captured state of operation of another UI device ("previous UI device") (e.g., UI device 803b) or the UI device 803. During operation of such an embodiment of the UI device 803, the UI state information 896 may be received at the network interface 825 via the process control network 100. The network interface 825 may transmit the UI state information 896 to be stored in the memory 815. The processor 810 may access some or all of the UI state information 896 stored in the memory 815 to place the UI device 803 in a state consistent with some or all of the UI state information 896. The UI state information 896 may indicate a UI state of operation in which a previous UI device provided information related to a process or a particular entity in the process control network 100. The processor 810 may cause the display 820 to display information corresponding to the same particular entity. The display 820 may depict the information in the same or similar GUI configuration used by the previous UI device 803b, but may use a different GUI configuration in certain circumstances (e.g., where the UI device 803 is a different type of device than the previous UI device 803b). In some embodiments, the processor 810 may identify a point of interest (e.g., an entity of interest) based on the UI state information 896 and cause the display 820 to provide information on the identified point of interest.

[0133] In addition to or alternatively to indicating the process entities, the UI state information 896 may indicate the state of one or more of the applications that were running on the previous UI device 803b. The processor 810 may launch the one or more applications to operate in the indicated state. For example, the UI state information 896 may indicate that a browser window is open and displaying a particular web page. In such an example, the processor 810 may launch the browser application and cause the same particular web page to open. In another example, the UI state information 896 may indicate that a process history viewing tool was running and that a particular process value was being accessed or displayed by the viewing tool. In such an example, the processor 810 may launch the viewing tool application and cause the same particular process value to be accessed or displayed.

[0134] 12A, a block diagram illustrates example data associated with UI devices 112 in a mobile control room 1200a. The mobile control room 1200a may enable state transfer to one or more UI devices 112 to enable a user of each UI device 112 to resume a workflow from a previously saved state or to enable a user of a UI device 112 to collaborate with users of other UI devices 112. The mobile control room 1200a includes a server 150, a process control network 100, and a UI device 112. In some embodiments, the server 150 may also function as the UI device 112, in which case the server 150 includes a display 820 for displaying GUI configurations and providing process information to an operator or user. In such embodiments, the server 150 may also include an input interface 830 for receiving user input.

[0135] The server 150 includes a processor 1201, a network interface 1202, and a memory 1203. The memory 1203 stores UI state information 1240, which may include profile data 1245 and / or session data 1265. The UI state information 1240 may be stored in a database 151, depicted in FIG. 9B. The server 150 may communicate over the process control network 100 using a wired or wireless communication channel. Similarly, each of the UI devices 112 may communicate over the process control network 100 using a wired or wireless communication channel, and each of the UI devices 112 may communicate with the server 150.

[0136] The memory 1203 of the server 150 may include volatile and / or non-volatile memory, and may be removable or non-removable. For example, the memory 1203 may include computer storage media in the form of random access memory (RAM), read only memory (ROM), EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage device, or any other medium that can be used to store the desired information. The processor 1201 is configured to fetch and execute instructions stored in the memory 1203. The memory 1203 may store data, such as operating system data or program data. The network interface 1202 may include one or more antennas for wireless communication, one or more ports for wired connection, or both. In some embodiments, the network interface 1202 may include one or more GPS receivers, Bluetooth transceivers, NFC transceivers, RFID transceivers, and / or local network transceivers. The network interface 1202 may communicate with the UI device 112 over the process control network 100 .

[0137] Each UI device 112 may include data representing a user ID 1205, a session ID 1210, a client device ID 1215, and / or a UI type 1220. The user ID 1205 may correspond to one user or operator and act as a unique identifier. Similarly, the session ID 1210 may serve as a unique identifier of a particular user session on the UI device 112. A user session is generally considered to be a period of use by a particular user without any extended break. Generally, when a user ceases to use the UI device 112a for an extended period of time and later resumes use of the UI device 112a, the subsequent use represents the start of a new session (unless the session is resumed as described below). The client device ID 1215a may act as a unique identifier of the UI device 112a. Finally, the UI type 1220a may represent the type of GUI implemented on the UI device 112a. The UI type often corresponds to the device type of the UI device. In a preferred embodiment, there are two common UI types: normal UI and mobile UI. Desktops, laptops, and other UI devices with larger screens implement a normal UI. Meanwhile, mobile devices such as phones, PDAs, and tablets often implement a mobile UI, which provides larger graphics and text (relative to the screen size). In many embodiments, the mobile UI may provide different GUI configurations and graphics due to the limited size of many mobile device screens. In alternative embodiments, there may be other UI types, such as a phone UI, a tablet UI, or a headset UI.

[0138] The profile data 1245 may include user profiles 1250a-d. Each of the user profiles 1250a-d may correspond to a unique user or operator. The user profile 1250a may include data representing a user ID 1252, a user role 1254, and user history data 1256. The user profiles 1250b-d may include similar elements. The user ID 1250a may represent a unique identifier for a particular user and may correspond to the user ID 1205a at the client device 112a. The user role 1254 may represent a particular user's responsibilities, position, or role in the process plant. For example, the user role 1254 may limit the areas of the plant that the user has permission to control. The user role 1254 may also limit the scope of control that the user may exercise or the types of programs that the user may access. In some embodiments, user roles 1254 may also limit a user's permission to access and control entities in the process plant based on a schedule. For example, user roles 1254 may only have permission to perform controls during the user's work schedule (e.g., 8 a.m. to 5 p.m.). Finally, user history data 1256 may represent the tendencies, habits, and preferences of a user associated with user profile 1250a. User history data 1256 may reveal, for example, particular areas in the process plant, particular devices, or equipment, or particular process parameters that tend to be emphasized by the user.

[0139] The session data 1265 may include sessions 1270a-1270d. The session 1270a may include data representing a session ID 1272, a user ID 1274, a client device ID 1276, a UI type 1278, application state data 1280, and session time data 1282. Each of the sessions 1270b-1270d may include data representing a similar entity. The session ID 1272 may serve as a unique identifier for a particular session. The user ID 1274 may represent a unique user and may correspond to the user ID 1252 of the user profile 1250a and the user ID 1205a of the UI device 112a. The client device ID 1276 may uniquely identify a particular UI device and may correspond to the UI device ID 1215a. Similarly, the UI type 1278 may correspond to the UI type 1220a at the UI device 112a. Application state data 1280 may represent programs that were running on the UI device when UI state information 1240 was captured, and may represent the state of each particular application at the time of capture. Session time data 1282 may represent temporal data such as the start time of a session, the end time of a session, and the length of a session.

[0140] In operation, the UI device 112a may capture UI state information 1240 (including profile data 1250a and session data 1270a). When a user session is terminated, the UI device 112a may transmit the UI state information 1240 to the server 150 for storage. The network interface 1202 may receive the UI state information 1240 from the process control network 100. The processor 1201 may operate to transmit and store the UI state information 1240 in the memory 1203. In alternative embodiments, the UI device 112a may transmit some or all of the UI state information 1240 to the server 150 periodically or in response to a trigger event. The server 150 may then transmit some or all of the UI state information 896 to a UI device, such as the UI device 112b.

[0141] Similar to FIG. 12A, FIG. 12B is a block diagram illustrating example data associated with UI devices 112 in a mobile control room 1200b. The mobile control room 1200b may enable state transfer from a first UI device 112a to one or more other UI devices 112b, 112c. Similar to the mobile control room 1200a, the mobile control room 1200b enables a user of the UI device 112a to resume and / or continue a workflow on the UI device 112b or to collaborate with another user using the UI device 112b. The mobile control room 1200b includes a server 150, a process control network 100, and UI devices 112a-c. In some embodiments, the server 150 may also function as the UI device 112, in which case the server 150 includes a display 820 for displaying GUI configurations and providing process information to an operator or user. In such embodiments, the server 150 may also include an input interface 830 for receiving user input.

[0142] Mobile control room 1200b differs from mobile control room 1200a in at least one respect. Specifically, in mobile control room 1200b, state and / or session data is communicated directly, for example from UI device 112a to UI device 112b, rather than through server 150. Each of UI devices 112 stores UI state information 1240, which may include session data 1265. The session data 1265 stored by each of UI devices 112 may include user ID 1205, session ID 1210, UI device ID 1215, UI device type 1220, application state data 1280, and session time data 1282.

[0143] 12A may be stored on the server 150 and / or in the memory of the individual UI devices 112. In this manner, any user may use any of the UI devices 112 and the user's profile (including the user's preferences, roles, historical data, etc.) will be available to the UI device 112. In some embodiments, the UI device 112 may download or otherwise access the user profile data 1245 from the server 150 when a particular user logs into the UI device 112. In another embodiment, profiles of all users or of users who have previously used a particular UI device 112 may be present in the memory of the UI device 112.

[0144] In operation, each UI device 112 may store one or more applications in memory 815, such as a display application for viewing information about the process plant. The UI device 112 may periodically store the state of the application in application state data 1280 and / or may store the state of the application upon request to communicate the state to another UI device 112. By way of example only, a user may view process plant data using a viewing application on the UI device 112a. The viewing application may be resident on the UI device 112a and may retrieve and / or receive data (e.g., process data) from the server 150. In some embodiments, the UI device 112a receives both process data and visualization data from the server 150. For example, the UI device 112a may receive trend data related to a particular process parameter from the server 150 and may additionally receive rendering instructions along with the trend data indicating the manner in which the data is to be displayed (e.g., 3D plot information, table information, axis information, etc.). The rendering data may be transmitted as a separate entity, allowing the same data to be transmitted with different rendering (e.g., format) information according to the target device. In any case, the UI device 112a maintains certain information regarding the state of applications executing on the UI device 112a, including information about what data is being displayed, what process plant areas or devices are being displayed, what tasks are being performed, etc.

[0145] A user may wish to switch from UI device 112a to UI device 112b, for example, to transition from a workstation UI device to a tablet UI device. To do so, the user may initiate a state transfer from UI device 112a to UI device 112b. In a first embodiment, the user brings UI device 112b into proximity with UI device 112 so that the NFC devices in each UI device 112 can communicate with each other to establish and set up a connection. The NFC devices may cooperate to set up a connection, for example, via Bluetooth or WiFi, so that session data 1265a can be passed from UI device 112a to UI device 112b, allowing UI device 112b to resume the session in a similar or the same state as it was operating on UI device 112a. In a second embodiment, the user may engage one or more menus on UI device 112b, for example, to select a session number that is displayed on display 820 of UI device 112a. Alternative embodiments for transferring state that may be employed in this or other situations are described throughout this description. The devices may then communicate between them over network 100 (optionally server 150) or directly over Bluetooth or WiFi to convey the session data 1265a from UI device 112a to UI device 112b. Once UI device 112b receives session data 1265a and stores it as session data 1265b, UI device 112b may resume the session that was previously running on UI device 112a.

[0146] In an embodiment, the transfer of state from the first UI device 112 to the second UI device 112 also transfers any control associated with the UI device 112. For example, in some cases, a controller or other process device may receive input from only one input source at a time. In such cases, it is important that the input source is clearly established and that the possibility of conflict is eliminated. If a user switches from the first UI device 112 to the second UI device 112, any such input must be clearly associated with the second UI device 112 after transferring the state to the second UI device. In such cases, the server 150 may maintain tracking data (e.g., UI device ID 1276 associated with a particular session 1265) and may reallocate the UI device ID upon transfer to the second UI device. Even if the transfer is directly between the first UI device 112 and the second UI device 112 according to the most recent request for process control data, the server 150 may be able to establish the transfer to take place. For example, server 150 may determine that UI device 112b has the most recent requested data and therefore may determine that UI device 112b now controls the session. Alternatively, UI device 112a may relinquish or disavow the session once it has been conveyed by sending a message to server 150 indicating that UI device 112a is no longer associated with the session conveyed to UI device 112b, or UI device 112b may positively identify that UI device 112b is now associated with the session and send a similar message to server 150 instructing server 150 that UI device 112a is no longer associated with the session. In yet another embodiment, each session may have a "session token" associated with it that is stored in the memory of the UI device that is passed from device to device.When a device does not have a session token for a particular session, it will not send commands (or will at least cease sending a subset of commands) from the device even if the device otherwise maintains the session. In this manner, data related to a particular session may continue to be displayed on UI device 112a even after state transfer has occurred and the session token has been passed to UI device 112b. The session token may take any form including, by way of example only, a secure file, a hash code, a particular code, or a character sequence, etc.

[0147] Various methodologies related to the concepts described in the above paragraphs will now be described with reference to the associated drawings.

[0148] 13 is a flow chart of an example method 1300 of providing session data to UI device 112. Providing session data may facilitate communication or synchronization of UI state to enable continuous workflow or worker collaboration. Method 1300 may be implemented in whole or in part in one or more devices or systems, such as server 150 shown in FIGS. 1, 9, and 12. The method may be stored on memory 1203 as a set of instructions, routines, programs, or modules and executed by processor 1201.

[0149] The method 1300 begins when the server 150 receives a session request from a UI device 112 (block 1305). The server 150 may determine whether the UI device 112 provides a user ID (block 1310) and may request a user ID when not provided (block 1315). If a user ID is provided, the server 150 may identify data associated with the user ID (block 1320). For example, there may be one or more user profiles, sessions, or UI devices 112 associated with the user ID. In an alternative embodiment, the server 150 may receive a UI device ID and identify data associated with the UI device ID (rather than a user ID).

[0150] After identifying the data associated with the provided user ID, the server 150 may determine whether the UI device 112 is requesting to resume a workflow from a previous session (block 1325). When no such request exists, the server 150 may identify a default session (i.e., data representing a new session or a default session) as the "target session" to be provided to the UI device (block 1330). The default session data may include data such as default GUI configuration data, default process parameter data, or default display data. For example, a default GUI configuration for a new session that does not resume a previous workflow may include an active window with a plant overview graphic. The server 150 may transmit the default session data to the UI device 112 (block 1350).

[0151] When the server 150 receives a request to resume a previous workflow, the server 150 may determine whether a specific session has been identified by the UI device 112 (block 1335). When a specific session has not been identified, the server 150 may identify the most recent saved session associated with the user ID (or in an alternative embodiment, the UI device ID) as the “target session” to be provided to the UI device 112 (block 1340). The server 150 may transmit the recent session data to the UI device 112 (block 1350). When the server 150 receives a specific session associated with the request to resume a workflow, the server 150 may identify stored session data (e.g., stored in the memory 1203 of the server 150 shown in FIG. 12A) related to the specific session as data related to the “target session” to be provided to the UI device 112 (block 1345). The server 150 may transmit the specific session data to the UI device 112 (block 1350).

[0152] In an alternative embodiment, the server 150 may be the second UI device 112, in which case the second UI device 112 receives the session request from the first UI device 112 and provides the session data to the first UI device 112.

[0153] 14 is a flowchart of an example method 1400 for generating a GUI configuration on a UI device 112. The method 1400 may enable the UI device 112 to provide output according to information received in a UI state transmission and according to the environment and context of use of the UI device 112. The method 1400 may be implemented in whole or in part on one or more devices or systems, such as any of the UI devices 112 or 112a-g (FIGS. 1-10 and 12). The method 1400 may be stored on the memory 815 as a set of instructions, routines, programs, or modules and may be executed by the processor 8310.

[0154] The method 1400 begins when the UI device 112 identifies context data (block 1405). The UI device 112 may also identify an entity associated with the context data. The context data may be any context information or item. In one embodiment, the context data may represent any of the elements included in the context awareness data 1540 or work item data 1550 described in connection with FIG. 15. The associated entity may be any area, equipment, device, or parameter associated with the context item.

[0155] The method 1400 may include receiving UI state information 896 (block 14), such as the UI state information 896 shown in FIG. 12. The UI device 112 may receive the UI state information 896 from a device or system that performs the method 1300 shown in FIG. 13. After receiving the UI state information 896, the UI device 112 may identify an entity associated with the received UI state information 896 (block 1420). The entity may be any area, device, system, or parameter in a process. In general, the entity associated with the UI state information 896 also relates to information provided at a previous UI device 112 from which the UI state information 896 was captured.

[0156] The UI device 112 may prioritize the entities (block 1430). An entity may be of higher or lower priority depending on factors such as the importance of the entity to the stable operation of the process, time sensitivity (e.g., if the entity is not addressed quickly, the batch may be disrupted), location (e.g., the UI device 112 is proximate to a location associated with the entity), status (e.g., the entity is malfunctioning or associated with a malfunction), alarm condition (e.g., the entity is associated with a parameter value that is outside of a normal operating range), schedule (e.g., the entity may be associated with offline equipment), or relevance of a work item (e.g., the entity may be related to a work item associated with the user or the UI device 112).

[0157] The UI device 112 may generate a GUI configuration based on the prioritized entities (block 1435). Prioritization of entities may be necessary when the UI device 112 cannot display all of the information applicable to the entities identified in the context data and the received session. For example, in some embodiments, the previous UI device 112 may be a workstation of normal UI type, while the UI device 112 receiving the UI state information 896 is a tablet of mobile UI type. Because mobile UI devices are configured for smaller screens, they often provide less information. Thus, even if the UI device 112 avoids identifying entities related to the context data, the UI device 112 will still prioritize the entities to identify which entities the UI device 112 should provide information to.

[0158] In alternative embodiments, the system or device providing the UI state information 896 may identify the UI type or device type of the UI device 112 receiving the UI state information 896. In such embodiments, the providing system may tailor the UI state information 896 provided to the UI device 112. In other words, the providing system may provide more or less information based on the UI type or device type. The providing system may also provide display data formatted for the UI type or device type.

[0159] 15 is a flow chart illustrating a method 1500 for directly communicating status information between two UI devices 112 in a process control plant 10. The method 1500 may be implemented in whole or in part in one or more devices or systems, such as any of the UI devices 112. The method 1500 may be stored on the memory 815 as a set of instructions, routines, programs, or modules and executed by the processor 810.

[0160] The method 1500 begins with a first UI device 112 that may execute one or more first routines to perform a function (block 1505). The function may be a control function, an operational function, a configuration function, a maintenance function, a data analysis function, an administrative function, a quality control function, or a security function. The first UI device 112 may be coupled via a network to a modular logical data storage area, such as a big data appliance 102. The modular logical data storage area may be configured to store process data corresponding to the process plant using a common format. The process data may include multiple types of process data, including configuration data, continuous data, batch data, measurement data, and event data.

[0161] The first UI device 112 may pass state information to the second UI device 112 (block 1510). The state information may indicate one or more first routines operating on the first UI device 112. In some embodiments, the state information may be passed over an Internet connection. In another embodiment, the state information may be passed over an intermediate network. In yet another embodiment, the state information may be passed from the first UI device 112 to the second UI device 112 over a point-to-point wireless connection. In some cases, the state information may be passed over wireless communication according to a protocol such as the Bluetooth protocol or the NFC protocol. In other cases, the state information may be passed from the first UI device 112 to the second UI device 112 through an intermediate device (which may be the server 150). In some cases, the first UI device 112 may pass the state information to the second UI device 112 when the UI devices 112 mutually detect each other and the same user is logged on to both devices. In some embodiments, the state information may be passed upon receipt of an instruction to pass the state information at the first UI device 112. In particular embodiments, passing state information may facilitate one or more of collaboration between different users on two UI devices 112, mobility of one user across two UI devices 112, device awareness of a user's location within the process plant, or device awareness of a user's proximity to particular process plant equipment.

[0162] The second UI device 112 may receive the state information and execute one or more second routines (block 1515). The display of the second UI device 112 may be configured according to the stored state and according to the device type or UI type of the second UI device 112. The second routines may correspond to one or more of the first routines operating on the first UI device 112. In some embodiments, the second UI device 112 may receive a signal from the location awareness component and may modify execution of the one or more second routines according to the received signal. In certain cases, the location awareness component may receive a signal from the second UI device 112. The signal may be transmitted over a network to cause the second UI device 112 to modify execution of the one or more routines according to the received signal. Modifying the execution of the one or more routines may include one or more of highlighting an area of ​​the process plant in which the second UI device 112 is located, displaying information about particular devices within a predetermined distance of the second UI device 112, displaying alarms applicable to devices in the area of ​​the process plant in which the second UI device 112 is located, or displaying work items related to devices in the area of ​​the process plant in which the second UI device 112 is located.

[0163] In some embodiments, the second UI device 112 may receive a signal from the device awareness component and modify execution of one or more second routines according to the received signal. In particular embodiments, the device awareness component may include a transmitter to transmit a wireless signal to the second UI device 112. The wireless signal may identify a device to which the transmitter is associated.

[0164] In some embodiments, either or both of the first UI device 112 and the second UI device 112 may be a mobile device. In another embodiment, either or both of the first UI device 112 and the second UI device 112 may be a workstation. In some embodiments, one UI device 112 may be a mobile device and the other may be a workstation. In one embodiment, the second UI device 112 may configure the display according to state information received from the first UI device 112 and according to a device type or UI type associated with the second UI device 112.

[0165] 16 is a flow chart illustrating an example method 1600 for communicating status information between two UI devices 112 coupled to a server 150 in a process plant 10. The method 1600 may be implemented in whole or in part in one or more networks or systems, such as the process control network 100. In particular, the method 1600 may be implemented in whole or in part in one or more devices or systems, such as the server 150, or in one or more devices or systems, such as any of the UI devices 112. The method 1600 may be stored on the memory 815 or memory 1203 as a set of instructions, routines, programs, or modules and may be executed by the processor 810 or processor 1201.

[0166] The method 1600 begins with a first UI device 112 that may execute one or more first routines for performing functions in a process plant (block 1605). The first UI device 112 may track a state of the one or more first routines executing on the first UI device 112 (block 1610). In some embodiments, the server 150 may track a state of the one or more first routines executing on the first UI device 112. The first UI device 112 or the server 150 may store the tracked state of the one or more first routines (block 1615).

[0167] The first UI device 112 or the server 150 may communicate the stored state of one or more first routines to the second UI device 112 (block 1620). In some embodiments, the state information may be passed over an Internet connection. In another embodiment, the state information may be passed from the first UI device 112 or the server 150 to the second UI device 112 over a point-to-point wireless connection. The state information may also be communicated from the first UI device 112 to the second UI device 112 through an intermediate device or the server 150. In some cases, the state information may be passed over wireless communication according to a protocol such as the Bluetooth protocol or a near field communication protocol. In certain embodiments, the state may be transmitted to the second UI device 112 upon detection of the first UI device 112 by the second UI device 112 or upon detection of the second UI device 112 by the first UI device 112. Transmitting the stored state to the second UI device 112 may include transmitting the stored state upon receiving an instruction at the first UI device 112, where the instruction instructs the first UI device 112 to pass the stored state to the second UI device 112.

[0168] The second UI device 112 may execute one or more second routines, where the second routines correspond to one or more first routines executed on the first UI device 112 (block 1625). In some embodiments, the second UI device 112 may receive a signal. The signal may indicate the proximity of the second UI device 112 to a particular device or location. After receiving the signal, the second UI device 112 may modify the execution of the one or more second routines according to the received signal. In some embodiments, the second UI device 112 may transmit to the location awareness component a signal indicating the proximity of the second UI device 112 to a particular device or location. In such an embodiment, the second UI device 112 may receive information specific to the particular device or location from the server 150.

[0169] In some embodiments, when the second UI device 112 is in proximity to a particular device or location, the second UI device 112 may take one or more of the following actions: highlighting the area of ​​the process plant in which the second UI device 112 is located; displaying information about a particular device within a predetermined distance of the second UI device 112; displaying alarms applicable to devices in the area of ​​the process plant in which the second UI device 112 is located; displaying work items related to devices in the area of ​​the process plant in which the second UI device 112 is located; highlighting process plant equipment associated with the received signal on the display; displaying information on the second UI device 112 about a particular device associated with the received signal; displaying alarms applicable to a device associated with the received signal; or displaying work items related to a device associated with the received signal.

[0170] In some embodiments, either or both of the first UI device 112 and the second UI device 112 may be a mobile device. In another embodiment, either or both of the first UI device 112 and the second UI device 112 may be a workstation. In some embodiments, one UI device 112 may be a mobile device and the other may be a workstation. In one embodiment, the second UI device 112 may configure the display according to state information received from the first UI device 112 and according to a device type or UI type associated with the second UI device 112.

[0171] 17 is a flow chart depicting an additional method 1700 for communicating status information between two UI devices 112 in a process control plant 10. The method 1700 may be implemented in whole or in part in one or more devices or systems, such as the server 150, or in one or more devices or systems, such as any of the UI devices 112. The method 1700 may be stored on the memory 815 or memory 1203 as a set of instructions, routines, programs, or modules and executed by the processor 810 or the processor 1201 of FIG.

[0172] The method 7500 begins with the server 150, which may provide one or more functions related to process data (block 1705). In some embodiments, the process data may be stored in a modular logical data storage area and may be stored using a common format. The process data may include multiple types of process data including configuration data, continuous data, batch data, measurement data, and event data.

[0173] The server 150 may enable the first UI device 112 to access the process data via the server 150. The server 150 may also enable the first UI device 112 to maintain state information on the server 150 (block 1710). The state information may indicate the state of the UI executing on the first UI device 112.

[0174] The server 150 may enable the second UI device 112 to access the process data and the state information via the server 150 (block 1710). The second UI device 112 may execute the UI according to the state information.

[0175] In some embodiments, either or both of the first UI device 112 and the second UI device 112 may be a mobile device. In another embodiment, either or both of the first UI device 112 and the second UI device 112 may be a workstation. In some embodiments, one UI device 112 may be a mobile device and the other may be a workstation.

[0176] 18 is a flow chart of an example method 1800 for operating a process control plant 10 using a UI device 112 associated with a mobile control room. The method 1800 may be implemented in whole or in part in one or more devices or systems, such as the server 150, or in one or more devices or systems, such as any of the UI devices 112. The method 1800 may be stored on the memory 815 or memory 1203 as a set of instructions, routines, programs, or modules and executed by the processor 810 or processor 1201.

[0177] The method 1800 begins with a first UI device 112 that may access a server 150 (block 1805). The server 150 may be communicatively coupled to a database that stores process data. The first UI device 112 may be associated with a first user profile. The first UI device 112 may perform a function in the process plant (block 1810).

[0178] The second UI device 112 may request access to the server 150 (block 1812). The second UI device 112 may be associated with the first user profile. The server 150 may store state information, where the state information is associated with a state of the first UI device 112 (block 1815).

[0179] The server 150 may provide access to the second UI device 112, where the access may be in accordance with the stored state information (block 1820). The second UI device 112 may perform a function in the process plant (block 1825).

[0180] In some embodiments, either or both of the first UI device 112 and the second UI device 112 may be a mobile device. In another embodiment, either or both of the first UI device 112 and the second UI device 112 may be a workstation. In some embodiments, one UI device 112 may be a mobile device and the other may be a workstation.

[0181] 19 is a flow chart illustrating an example method 1900 executed on a server to facilitate mobile control of the process plant 10. The method 1900 may be implemented in whole or in part on one or more networks or systems, such as the process control network 100. In particular, the method 1900 may be implemented in whole or in part on one or more devices or systems, such as the server 150, or on one or more devices or systems, such as any of the UI devices 112. The method 1900 may be stored on the memory 815 or memory 1203 as a set of instructions, routines, programs, or modules and may be executed by the processor 810 or processor 1201.

[0182] The method 1900 begins with the server 150, which may format process data for display on the first UI device 112 (block 1905). In some cases, the formatted process data may be viewable in a web browser running on the first UI device 112. The server 150 may format the process data according to a device type or UI type of the first UI device 112.

[0183] The server 150 may transmit the formatted process data to the first UI device 112 (block 1910). In particular, the server 150 may transmit to the first UI device 112 the process data that can be viewed in a general-purpose process control application executing on the first UI device 112.

[0184] The server 150 may store state information related to the display of the process data on the first UI device 112 (block 1915). Storing the state information may include storing one or more of a display configuration of the first UI device 112, a portion of the process plant displayed by the first UI device 112, process control device data displayed by the first UI device 112, a function being performed on the first UI device 112, including one or more of a control function, an operational function, a configuration function, a maintenance function, a data analysis function, a quality control function, or a security function, and a user profile that is active on the first UI device 112.

[0185] The server 150 may format the process data for display on the second UI device 112 according to the stored state information (block 1920). The server 150 may transmit the process data to the second UI device 112 (block 1925). In particular, the server 150 may format the process data according to a device type or UI type of the second UI device 112. In some cases, the device type of the second UI device 112 may be different from the device type of the first UI device 112. For example, the first UI device 112 may be a workstation and the second UI device 112 may be a mobile device. Alternatively, the first UI device 112 may be a mobile device and the second UI device 112 may be a workstation. In some embodiments, the server 150 may format the process data for display on the second UI device 112 such that the operating state of the first UI device 112 is replicated on the second UI device 112.

[0186] In some embodiments, the server 150 may receive a request from the second UI device 112 for providing a user interface to the second UI device 112 according to the stored state information. The server 150, together with the second UI device 112, may establish a secure communication channel between the server 150 and the second UI device 112 in response to the request for providing the user interface.

[0187] 20 is a flowchart of an example method 2000 for transmitting a state of a first UI device 112 to a second UI device 112. The method 2000 may be implemented in whole or in part in one or more networks or systems, such as the process control network 100. In particular, the method 2000 may be implemented in whole or in part in one or more devices or systems, such as the server 150, or in one or more devices or systems, such as any of the UI devices 112. The method 2000 may be stored in the memory 815 or memory 1203 as a set of instructions, routines, programs, or modules and may be executed by the processor 810 or processor 1201.

[0188] The method 2000 begins with the first UI device 112 or the server 150 being able to identify graphics to be rendered on a display of the first UI device 112 (block 2005).

[0189] The first UI device 112 or the server 150 may identify (block 2010) process entity data associated with the graphics provided on the display of the first UI device 112. Identifying the process entity data may include identifying one or more of process parameter data associated with the graphics provided on the display of the first UI device 112, a process plant area associated with the graphics provided on the display of the first UI device 112, a field device associated with the graphics provided on the display of the first UI device 112, an application executing on the first UI device 112, or a state of an application executing on the first UI device 112.

[0190] The first UI device 112 or the server 150 may transmit the identified process entity data to the second UI device 112 (block 2020). The first UI device 112 or the server 150 may provide the identified graphics to the second UI device 112 (block 2020).

[0191] 21 is a flow chart illustrating a method 2100 of initiating a UI session on a first UI device 112. The method 2100 may be implemented in whole or in part in one or more networks or systems, such as the process control network 100. In particular, the method 2100 may be implemented in whole or in part in one or more devices or systems, such as the server 150, or in one or more devices or systems, such as any of the UI devices 112. The method 2100 may be stored on the memory 815 or memory 1203 as a set of instructions, routines, programs, or modules and may be executed by the processor 810 or processor 1201.

[0192] The method 2100 begins with the server 150 receiving a session request from the first UI device 112 (block 2105).

[0193] The server 150 may identify a user profile associated with the session request (block 2110). Identifying the user profile associated with the session request may include receiving a user identifier associated with the user profile from the first UI device 112. The user identifier may be currently logged in to the first UI device 112. Identifying the user profile may also include receiving a user identifier associated with the user profile from the first UI device 112, where the user identifier may be currently logged in to the second UI device 112.

[0194] The server 150 may determine whether a previous session exists (block 2115). Making the determination may include requesting a session identifier associated with the previous session from the first UI device 112. In some embodiments, making the determination may include receiving the session identifier in response to a session identifier request from the first UI device 112. In some embodiments, making the determination may include identifying the session identifier received with the session request.

[0195] The server 150 may instantiate a new session according to a previous session when a previous session exists (block 2115). Alternatively, the server 150 may instantiate a new session when no previous session exists, in which case the new session may be instantiated using a default session configuration. Instantiating a new session according to a previous session may include determining whether a session identifier was received with the session request. When a session identifier was received with the session request, the server 150 may instantiate a session associated with the session identifier. When a session identifier was not received with the session request, the server 150 may instantiate a session associated with a recent session, such as a most recent session of a user identifier associated with the first UI device 112.

[0196] In some embodiments, the method 2100 may further include the server 150 transmitting a request to the second UI device 112 for instantiating a session on the first UI device 112 according to the session running on the second UI device 112. The method 2100 may also include the server 150 receiving a confirmation from the second client device.

[0197] 22 is a flowchart of a second method 2200 for instantiating a UI session on the first UI device 112. The method 2200 may be implemented in whole or in part in one or more networks or systems, such as the process control network 100. In particular, the method 2200 may be implemented in whole or in part in one or more devices or systems, such as the server 150, or in one or more devices or systems, such as any of the UI devices 112. The method 2200 may be stored on the memory 815 or memory 1203 as a set of instructions, routines, programs, or modules and may be executed by the processor 810 or processor 1201.

[0198] The method 2200 begins with the server 150, which may receive a session request from the first UI device 112 (block 2205). Receiving the session request may include receiving a target session identifier and a device type.

[0199] The server 150 may determine a device type associated with the session request (block 2210). The server 150 may identify a graphical user interface configuration according to the device type (block 2215). The server 150 may identify a target session associated with the session request (block 2220).

[0200] The server 150 may configure a new session on the first UI device 112 according to the identified graphical user interface configuration and the identified target session. The server 150 may transmit data associated with the new session to the first UI device 112 (block 2225). Configuring the new session may include identifying one or more of a process area, equipment resource, or set of process data to be monitored or controlled in the target session as session data. Configuring the new session may also include configuring the new session according to constraints associated with the identified graphical user interface configuration. Configuring the new session may further include identifying context data associated with the session request.

[0201] Identifying the context data may include identifying a location of the first UI device 112 in the process plant, identifying a user type or user identifier associated with the session request, identifying a user type or user identifier associated with the first UI device 112, identifying one or more process control devices within a predetermined distance from the first UI device 112, identifying a function being performed on a second UI device 112 associated with the target session, or identifying a user identifier associated with a second US device associated with the target session.

[0202] Context Awareness 23 illustrates an example mobile control room 2300, a second aspect of context awareness. The mobile control room 2300 includes a UI device 112 and a process entity 199. The process entity 199 may be a current task, a user, a process area, a device, a piece of equipment, or another UI device. The mobile control room 2300 may respond to one or more contexts in one or a combination, and may respond to one or more contexts in various manners, as described below. In general, the UI device 112 will retrieve information about what data to display and the format in which to display the data, and will retrieve and / or display the data according to the context.

[0203] In some embodiments, information specifying the type and format of data to display is included in an extended device description language (DDL). The DDL is a human readable language that provides a protocol for describing data available from a smart device, meaning data associated with and retrieved from the smart device, methods available for the implementation of the smart device, formats for communicating with the smart device to obtain the data, user interface information about the device (e.g., editing displays and menus), and data necessary to handle or interpret other information about the smart device. The extended DDL may also include, among other things, what information should be displayed to different types of users, how to format the information displayed to different types of users, what information should be displayed on different types of displays, how to format the information displayed on different types of displays, what information should be displayed according to a target function (i.e., what information to display when a user is performing a particular task), how to format the information displayed for a user performing a target function, and how to merge instructions according to various profiles according to some combination of users, target functions, and display types.

[0204] The UI device 112 may download the DDL or extended DDL for a particular device from the server 150 when the UI device 112 is adjacent to a particular process control device and / or when a user requests to display information related to the process control device. In some embodiments, the UI device 112 may cache the DDL or extended DDL (collectively, hereinafter "DDL") for future use once it has been used. By caching the DDL for a device, the UI device 112 may provide display information more quickly when a particular context or display is activated / requested. The UI device 112 may update the DDL information in the background when the DDL is changed. The DDL may change according to user preferences, according to standards for the process plant, according to an expert system's determination of what information is useful in a particular context (e.g., if the expert system determines that a particular parameter or value is important to cause an alarm), etc.

[0205] In one embodiment, the mobile control room 2300, and in particular the UI device 112 carried by the user, may display user information (e.g., status, process variables and / or parameters, etc.) related to a particular process control device adjacent to the user. The UI device 112 may determine a location of the UI device 112 and / or may determine that the UI device 112 is adjacent to a process control device in a manner described below. After determining that the UI device 112 is adjacent to a process control device, the UI device 112 may access or retrieve a DDL that specifies device-specific data to display (e.g., process parameters, status, maintenance information, etc.) and may then download and display the device-specific data according to the DDL. In some embodiments, the data displayed for a particular process control device may include data related to other process control devices, such as data about the operation or status of adjacent devices, data about the operation of a process (e.g., the state of a batch recipe), etc.

[0206] In another embodiment, the UI device 112 may display information according to the user, and in particular the user's span of control, as well as according to the device's location and / or proximity to a particular process control device. In process control, span of control refers to the user's role and the tasks and equipment for which the user is responsible. A user's span of control may affect aspects of the process such as the process parameters the user can view, the process parameters the user can modify, the number of times the user can modify the process parameters, the areas of the process plant and / or equipment the user can view / modify, the alarms / alerts the user can acknowledge, the maintenance tasks the user can perform, the decisions the user may be asked or required to make, etc. Thus, in these embodiments, the UI device 112 may retrieve information about the user's role and / or span of control from a user profile for the user (stored on the UI device 112 or on the server 150) and may display data specific to the user's role and / or span of control. For example, the data displayed may be data that is useful or necessary for the user to make control decisions at particular plant conditions if the user is an operator. Additionally, the information displayed by the UI device 112 may be formatted according to the user's role or span of control. For example, when the UI device 112 is in proximity to a mixing tank, the UI device 112 being used by an operator may display the operational status of the tank, the volume of the tank, the fill level of the tank, the temperature of the material in the tank, the pressure in the tank, the status of any input / output valves that control material flowing into / out of the tank, any alarms or alerts related to the tank, and the status of the batch recipe being executed.When the same UI device 112 is used by maintenance personnel in the vicinity of the same mixing tank, the UI device 112 may display the status of the mixing tank, the calibration date of the sensors in the mixing tank, the date the tank was last inspected and / or cleaned, a list of scheduled maintenance tasks relating to (or affecting) the mixing tank, any alarms indicating needed maintenance, the material in the tank, any lockouts of the tank if the tank is taken out of service, the presence of any residual fumes, etc.

[0207] In yet another embodiment, the UI device 112 may display information according to the target function as well as according to the device's location and / or proximity to a particular process control device. For example, a user may be assigned a work item (e.g., by the supervisor engine 106). The UI device 112 may be aware that the user intends to perform a task related to the work item (e.g., by a time when the work item is scheduled to be performed, by input from the user, etc.). When the user arrives at or near the location of the process control device related to the work item (i.e., the target equipment and target location), the UI device 112 may inform the user of information related to the particular task. Referring again to the example mixing tank above, a maintenance personnel performing a work item related to cleaning or inspection of the tank may be presented by the UI device 112 with the tank's operational status and instructions or commands to disable the tank, take the tank out of service, lock out the tank, or any other procedures necessary to initiate the cleaning or inspection function associated with the work item. The UI device 112 may also pull information from the supervisor engine 104, from the server 150, from the big data appliance 102, or from one or more controllers to perform and / or assist maintenance functions and safety operations. As described in the examples above (e.g., in Example 4), the UI device 112 may pull information / data to facilitate safety during maintenance tasks. Implementations of these concepts are described in the following paragraphs.

[0208] In operation, the mobile control room 2300 may enable the UI device 112 to receive information about the environment and manner in which the UI device 112 is being used. For example, the UI device 112 may identify its location in the process plant by receiving location data from a stationary location device 118, such as a GPS device, or from a node on the process control network 100 shown in FIG. 1A. For example, the UI device 112 may execute a context awareness routine and / or location awareness routine that may track a user's location, schedule, skill, and / or progress of a work item. In another embodiment, the server 150 shown in FIG. 1A may execute the context and / or location awareness routine, which communicates with the UI device 112. Based on the tracking, the location and / or context awareness routine may enable the UI device 112 to automatically determine and / or display plant maps, equipment photos or videos, GPS coordinates, and other information corresponding to the worker's location, or to aid in mobile worker and equipment identification in navigation. Additionally or alternatively, because a user may have certain skills, the context awareness routine or UI device 112 may automatically customize the appearance of the GUI configuration based on the skills and / or the location of the UI device 112. For example, in another scenario, the context awareness routine may notify the user in real time of newly opened work items or alarms related to a piece of equipment in the mobile worker's vicinity and that the mobile worker is qualified to address. In yet another scenario, the context awareness routine may cause one or more applications specifically related to the user's location and / or skills to be automatically launched on the UI device 112.

[0209] The UI device 112 may identify a particular process entity, such as a field device or piece of equipment, in its vicinity. The process entity may automatically identify itself to the UI device 112, for example, by using a wireless communication protocol such as an IEEE 802.11 compliant wireless local area network protocol, a mobile communication protocol such as WiMAX, LTE, or other ITU-R compliant protocol, a short wavelength wireless communication protocol such as Near Field Communication (NFC) or Bluetooth, a process control wireless protocol such as wireless HART, or some other suitable wireless communication protocol. In some embodiments, the UI device 112 may receive schedules or work items that correspond to the identified location, equipment, or field device. In one embodiment, identifying the process entity may cause the UI device 112 to automatically launch one or more applications related to the identified process entity, such as work orders, diagnostics, analysis, or other applications.

[0210] In operation, the UI device 112 may identify the process entity 199, in some embodiments via an image sensor at the UI device 112. In some cases, a user of the UI device 112 may take a picture of the process entity 199, and the UI device 112 may identify the process entity 199 based on the captured image. In some embodiments, the process entity 199 may include or be in proximity to a context ID device 198 that provides a unique tag or identifier (e.g., a barcode). The UI device 112 may capture a unique tag that allows the UI device 112 to identify the process entity 199 or the context ID device 198. The UI device 112 may provide information (e.g., via a display) that corresponds to the process entity 199 or to the context ID device 198. In some embodiments, the UI device 112 may determine the location of the UI device 112 by determining the location of the identified process entity 199 or the context ID device 198. Once the location of the UI device 112 is determined, the UI device 112 may provide context information (e.g., via a display) that corresponds to the determined location. The context information may relate to, for example, an area, a schedule, or other process entity in a work item. In some embodiments, the context ID device 198 may transmit the context information to the UI device 112. In another embodiment, the UI device 112 may receive the context information from the server 150 in response to transmitting its location to the server 150.

[0211] In some implementations, the UI device 112 may identify the process entity 199 via a motion sensor or an audio sensor. For example, an audio sensor may be used to capture audio associated with the process entity 199 (e.g., via a sound capture routine). The audio may be generated by the process entity 199 during normal operation of the process entity. In other implementations, the audio may be generated by a speaker of an audio device associated with the process entity 199. In either case, the captured audio may be used to identify the process entity 199. The UI device 112 may also detect vibrations via a motion sensor to identify the process entity 199. For example, a plant asset may have an expected level of vibration during operation. A user may place the UI device 112 on or near the plant asset. The UI device 112 may use data detected by the motion sensor to identify a current vibration level associated with the asset. The UI device 112 may correlate the current vibration level with a signature vibration associated with the process entity 199 that allows the UI device 112 to identify the process entity 199. In some cases, motion and / or audio sensors may be used in conjunction with other identified images / sounds / vibrations / locations to identify a unique identifier. For example, based on detected vibration levels associated with a plant asset and the location of the UI device 112, the UI device 112 may identify a particular tag associated with the process entity 199 that enables the UI device 112 to identify the process entity 199.

[0212] In further operations, the UI device 112 may identify its own location by receiving location data from one or more GPS satellites 2303. After identifying its location, the UI device 112 may communicate with a database or server to identify process entities at locations proximate the location of the UI device 112. The UI device 112 may transmit its location to the server 150. The server 150 may transmit the context information back to the UI device 112. The context information may relate to one or more process areas, devices, or equipment that are proximate to the UI device 112. The context information may also relate to schedules or work items that are applicable to the location of the UI device 112. FIGS. 24-27 below detail the operation of the context awareness routine in various embodiments of the present disclosure.

[0213] 24 is a block diagram of an example context-aware UI device 112 in a mobile control room 2400. The context-aware mobile control room 2400 may enable the UI device 112 to provide output in response to its environment and manner of use. The context-aware mobile control room 2400 may include a context identification ("context ID") device 2402, a UI device 112, and a server 150. The UI device 112 may interact with the context ID device 2402 to identify context data or context items. In certain embodiments, the context ID device 2402 may communicate with the UI device 112 via a wireless channel or a wired channel. In certain embodiments, the context ID device 2402 may transmit process parameter data and / or display data to the UI device 112. The context ID device 2402 may use image identification technology (e.g., barcode or QR code), voice identification technology (emitting a unique sound signature), or radio frequency technology such as RFID, NFC, Bluetooth, or Wi-Fi (IEEE 802.11 standard) technology. The UI device 112 may communicate with the server 150 over a network such as the process control network 100. In another embodiment, the context ID device 2402 may be located in the UI device 112, and a device (e.g., a plc device) may receive a signal from the context ID device 2402 and report the location of the UI device 112 to the server 150.

[0214] In any event, the server 150 may store context data 2410. The context data may include user profile data 1245 (related to users / operators at the plant), UI device profile data 2414 (related to registered UI devices at the plant), field device profile data 2416 (related to devices installed at the plant), equipment profile data 2418 (related to equipment installed at the plant), schedule data 2420 (related to users and equipment / devices), and work item data 2422 (related to tasks or jobs at the plant). In some embodiments, the field device profile data 2416 may be included in the equipment profile data 2418. The user profile data 1245 may include skill data indicating a skill level or responsibility level associated with a particular user. The work item data 2422 may include data such as a task ID (identifying a particular task), skill thresholds (identifying the minimum skill level or duties / responsibilities required to work on the task), target equipment (equipment associated with the task), and work item progress (identifying how close the task is to completion). Each of the context items 1245 and 2414-2422 may include information such as a location or area (e.g., associated with a user, device, equipment, schedule, or work item), status, related process entity, unique identifier / tag, and / or permission information.

[0215] In operation of the context ID device 2402, the context ID device 2402 may include a unique identifier or tag that can be read, scanned, or otherwise received by the UI device 112 when the UI device 112 comes into range of the context ID device 2402. The range of the context ID device 2402 depends on the particular embodiment of the context ID device 2402, but may be as small as a few centimeters or less, as large as a kilometer or more, or any distance in between. In some embodiments, the context ID device 2402 may transmit the unique identifier to the UI device 112. In other cases, the context ID device 2402 may display or otherwise provide the unique identifier so that it can be received and / or searched by the UI device 112.

[0216] In any case, the UI device 112 may receive the unique identifier and identify the context item, such as an area (i.e., a place, geographic area, or region), equipment, device, work item, or availability schedule in the environment of the UI device 112 by correlating the unique identifier with the context item. For example, the UI device 112 may access a database, table, or data structure that pairs the unique identifier with a particular context item. Such a database or table may reside on the UI device 112, in the context ID 2402, or on the server 150. When the database or table resides on the server 150, the UI device 112 may transmit the unique identifier to the server 150. The server 150 may access the database, table, or some other data structure to identify the context item associated with the unique identifier. The server 150 may transmit data representing the context item to the UI device 112.

[0217] Once the UI device 112 identifies the context item, the UI device 112 may provide output appropriate to the identified context item. For example, the context item may indicate a particular area, device, equipment, or alarm associated with the area. The UI device 112 may generate a visual representation, sound, or other output related to the particular device, equipment, or alarm so that the user may be notified of process conditions in the process area. Similarly, there may be multiple devices or alarms associated with an identified piece of equipment. The UI device 112 may provide information about the device or alarms associated with the device (from field device profile data 2416). Similarly, the context item may cause the UI device 112 to provide information related to the equipment (from equipment profile data 2418), schedules (from schedule data 2420), or work items (from work item data 2422).

[0218] In certain embodiments, one or more process control devices in a process plant may be a context ID device 2402. In another embodiment, one or more process control devices may include a context ID device 2402 or may be associated with a nearby context ID device 2402. For example, one or more of the field devices 15-22 and / or 40-58 shown in FIG. 1A may be, include, or be located near a context ID device 2402 (e.g., a context ID device 2402 may be attached to or near each of the field devices, or the field devices may have internal circuitry that enables the field devices to function as a context ID device). Similarly, the controller 11, gateway 35, UI device 112, I / O cards 26 and 28, and router 58 shown in FIG. 1A may be, include, or be near a context ID device 2402. In such an embodiment, the UI device 112 may receive a unique identifier associated with each of the context ID devices 2402, which enables the UI device 112 to receive a context item (e.g., a location or equipment ID) associated with each of the process control devices.

[0219] In alternative embodiments of the context-aware mobile control room 2400, the UI device 112 may include or provide a unique identifier. For example, the UI device 112 may have a unique scannable image on the device or chip that transmits unique identification data. In another example, the user of the UI device 112 may carry a badge, card, or some other accessory that includes a similar image or chip. In such an embodiment, the context ID device 2402 may read, scan, or otherwise receive the unique identifier. The context ID device 2402 may operate to associate the unique identifier with a particular user or UI device 112. The context ID device 2402 may associate the unique identifier with a particular user or UI device by accessing a data structure stored in the context ID device 2402. Alternatively, the context ID device 2402 may transmit the unique identifier to the server 150, which then associates the unique identifier with the particular user or UI device.

[0220] In any event, once the context ID device 2402 identifies the UI device 112 or the user, the context ID device 2402 may transmit the appropriate context item to the UI device 112. Alternatively, the context ID device 2402 may communicate with one or more nodes on a network, such as the process control network 100, to inform the one or more nodes that the user or UI device 112 has come into range of the context ID device 2402. The one or more nodes may transmit one or more context items, UI data (e.g., display data, process parameter data), or any other data to the UI device 112. The UI device 112 may act or provide output based on the received data. For example, in certain embodiments, the UI device 112 may launch a target application in response to receiving a unique identifier, context item, UI data, or other data from the context ID device 2402 or from the server 150. The target application may be, for example, an application specialized in providing process graphics and information to a user. The target application may be, for example, a mobile application operable on a phone or tablet device. In another embodiment, the target application may be a browser routine 888. In certain cases, the browser routine 888 may be directed to a particular resource or group of resources related to the received unique identifier, context item, UI data, or other data.

[0221] In some embodiments, the context ID device 2402 may be part of a permission system. For example, permission associated with a process entity may depend on the proximity of the UI device 112 to the process entity. In some embodiments, the UI device 112 may receive permission or authorization to modify parameters associated with a process entity when the user or the UI device 112 is in proximity to the process entity. The UI device 112 may also withdraw permission to engage in a work item or modify a parameter when the user's skill level falls below an indicated skill threshold associated with the work item or parameter.

[0222] 25 is a block diagram of another embodiment of a mobile control room 2500 in a process plant 10. The context-aware mobile control room 2500 may enable the UI device 112 to provide output responsive to its environment and manner of use. The mobile control room 2500 may include a UI device 112 communicatively coupled to a process control network 100 including areas 2505-2515 and a tank 2520. The UI device 112 is connected to the process control network 100. Area 2505 includes a context ID device 2402a, area 2510 includes a context ID device 2402b, process area 2515 includes a context ID device 2402c, and tank 2520 includes a context ID device 2402d.

[0223] In one embodiment, the context ID device 2402a is or includes an NFC device. The UI device 112 and the context ID device 2402a may generally operate at 13.56 MHZ and operate according to NFC standards such as ISO / IEC 14443, ISO / IEC 1809, NFCIP-1, NFCIP-2, and JIS:X6319-f. NFC technology enables wireless transactions and data exchange between the UI device 112 and the context ID device 2402a. NFC technology may also be used to automatically bootstrap other communication connections. In such an embodiment, the context ID device 2402a may transmit instructions to the UI device 112. The UI device 112 may receive and execute instructions that cause the UI device 112 to connect to another network. In some embodiments, the other network may be a wide area network such as the process control network 100 that includes other nodes. In certain embodiments, the other network may be a connection between the UI device 112 and the context ID device 2402a. For example, the other network may be a wireless ad-hoc network or a personal area network (e.g., Bluetooth, IEEE 802.15.1 standard). In any case, in addition to the network connection instructions, the context ID device 2402a may transmit authentication information to the UI device 112 that enables the UI device 112 to establish a connection to the network without the user of the UI device 112 having to manually configure the network and enter the authentication information.

[0224] In further operations of the context ID device 2402a, the NFC tag or device in the context ID device 2402a may also store other instructions that may be executed by the UI device 112. For example, the instructions may cause one or more applications to be launched or executed in a particular manner. In the illustrated embodiment, the instructions may cause the UI device 112 to launch a UI (e.g., UI routine 882 of FIG. 8) or a browser (e.g., browser routine 888 of FIG. 8) or to go into a particular state. The instructions may cause the UI device 112 to provide a GUI configuration that provides information about the devices and appliances in the area 2505. For example, the GUI configuration may include a window with a graphical overview of the process area 2505.

[0225] In a further operation of the context ID device 2402a, the UI device 112 may receive a unique identifier from the context ID device 2402a via NFC communication or via a network to which the UI device 112 is connected after receiving authentication information via NFC communication. The unique identifier generally represents the region 2505, but may represent other context items in certain embodiments. The UI device 112 may use the unique identifier to identify the context item (e.g., the region 2505) and act or provide output according to the identified context item (e.g., provide a graphical overview of the region 2505). Alternatively, the context ID device 2402a may receive the unique identifier from the UI device 112 and identify the UI device 112 (or its user) to enable the context ID device 2402a or another node on the process control network 100 to transmit data, such as context data or UI data, to the UI device 112. The UI device 112 may act or provide output based on the received data.

[0226] In one embodiment of the context ID device 2402b, the context ID device 2402b is or includes an RFID tag. In such an embodiment, the UI device 112 includes an RFID scanner and uses the RFID scanner to obtain a unique identifier. The unique identifier generally represents the region 2510, but in certain embodiments may represent other context items (e.g., a particular device, equipment, location, etc.). The UI device 112 may use the unique identifier to identify the context item in a manner consistent with the method described with respect to FIG. 24. In an alternative embodiment, the context ID device 2402b may be an RFID scanner and the UI device 112 may include an RFID tag. In such an embodiment, the context ID device 2402b identifies the UI device 112 when the UI device 112 enters range of the context ID device 2402b (e.g., when the user enters the region 2510). After identifying the UI device 112, the context ID device 2402b may communicate with the UI device 112 (e.g., using the process control network 100, using another network such as a personal area network, or using a display) and transmit the unique identifier to the UI device 112 or to a server 150, which may use the unique identifier to provide context information to the UI device 112. The UI device 112 may identify an area 2510 in a manner consistent with the method described with respect to FIG. 24 and act or provide an output based on the identified area 2510. In another embodiment, the context ID device 2402b may transmit a context item (rather than a unique identifier) ​​to the UI device 112 (e.g., using short-range wireless network communication such as Bluetooth). In yet another embodiment, the user may have an RFID tag instead of or in addition to a UI device 112 having an RFID tag. In any of these embodiments, both the RFID scanner and the RFID tag may be either active or passive. The UI device 112 may act or provide an output based on the received data.

[0227] In operation of an embodiment of the context ID device 2402c, the context ID device 2402c may be a Wi-Fi access point with a range covering the process region 2515. When the UI device 112 enters the process region 2515, the context ID device 2402c may establish communication with the UI device 112. The context ID device 2402c may transmit a unique identifier, such as a MAC address or device tag, to the UI device 112. The unique identifier generally represents the region 2515, but may represent other context items in certain embodiments. The UI device 112 may use the unique identifier to identify the context item (e.g., data representing the region 2515) and to act on the context item or provide an output (e.g., provide a visual representation of the region 2515) in a manner consistent with the method described with respect to FIG. 24. For example, a database pairing MAC addresses or device tags with specific regions may be stored on the UI device 112 that can be accessed by the UI device 112, or may be stored on a node in communication with the UI device 112. Alternatively, the UI device 112 may transmit a unique identifier, such as a MAC address of the UI device 112, to the context ID device 2402c. After receiving the unique identifier, the context ID device 2402c may operate to determine that the UI device 112 is associated with the unique identifier. The UI device 112 may operate or provide output based on the received data.

[0228] In one embodiment of the context ID device 2402d, the context ID device 2402d may include a barcode. The barcode may be a matrix barcode (e.g., a QR code) or a linear barcode (e.g., a UPC barcode). The UI device 112 may include or communicate with an image sensor, which may be a camera or a dedicated barcode scanner. In operation, the UI device 112 may use the image sensor to capture the barcode with the context ID device 2402d. The UI device 112 may decode data encoded in the barcode ("barcode data"). The barcode data generally includes a unique identifier that represents the tank 2520 (or any other process control device or equipment to which it is attached), although the unique identifier may represent other context items in certain embodiments. The UI device 112 may use the unique identifier to identify the context item (e.g., data representing the tank 2520) and to act on the context item or provide an output (e.g., provide a visual representation of the tank 2520) in a manner consistent with the methods described with respect to FIG. 24. In an alternative embodiment, the barcode may include data or instructions that cause the UI device 112 to take a particular action, such as launching a browser or UI so that the browser or UI provides particular information. The particular information may relate to any of a number of process entities, such as process parameter data, graphics of a particular item (e.g., tank 2520), or alarm data for a particular device. In a further embodiment, the UI device 112 or a user of the UI device 112 may alternatively or additionally include a barcode captured by the context ID device 2402d that allows the context ID device 2402d to identify the UI device 112 or the user. The barcode at the UI device 112 may also provide instructions to be executed at the context ID device 2402d. For example, the barcode may cause the context ID device 2402d to provide the appropriate information to the user or UI device 112.

[0229] In some embodiments, the UI device 112 may use other methods to identify the unique identifier. For example, the UI device 112 may use an audio sensor to identify the unique identifier, where the unique identifier is a sound signature (as shown with respect to FIG. 24) associated with the plant area / asset. The sound signature may be associated with a noise that a particular plant area / asset makes during operation. Alternatively, the sound signature may be an audio signal generated by an audio output device associated with the asset. The UI device 112 may also use a motion sensor to identify the unique identifier. The unique identifier may be a particular vibration level associated with the plant asset. For example, a user may place the UI device 112 on the plant asset and enable the UI device 112 to detect the vibration level. In some cases, a motion sensor may be used in conjunction with an identified image / sound / location to identify the unique identifier. For example, based on the detected vibration level associated with the plant asset and the location of the UI device 112, the UI device 112 may identify a particular tag associated with the plant asset.

[0230] In some embodiments, the UI device 112 may identify its location by receiving location data. The location data may be received over a network, such as the process control network 100. Alternatively, the location data may be received via a GPS receiver at a network interface of the UI device 112. The UI device 112 may compare its location to the locations of other process entities to identify process entities that are in proximity to the UI device 112. The UI device 112 may transmit its location to a node on the process network 100, such as the server 150. In some embodiments, the node may respond by transmitting context information to the UI device 112. In another embodiment, the UI device 112 may transmit the location data to the context ID device 2402. The context ID device 2402 may transmit the context data to the UI device 112 according to the received location data.

[0231] The UI device 112 may, in some embodiments, cooperate with the context ID device 2402 to provide real-time location data of the UI device 112. As the mobile operator carries the mobile UI device 112 through a particular environment, the UI device 112 may use location information received from (or resulting from) the context ID device 2402 to determine the current location of the UI device 112 in the process plant and may display a current map of the mobile operator's position in the environment. The map may display the mobile operator's position from an overhead view or in a three-dimensional perspective view. Of course, a desired or predicted route may also be displayed on the mobile UI device 112. Alternatively, the UI device 112 may use one or more accelerometers to determine the device's orientation and position within the environment, and cooperate with an image sensor on the UI device 112 to display an augmented reality view of the environment. For example, a mobile operator may point an image sensor at an area of ​​the process plant, and the UI device 112 may display a diagram of equipment over the image, may display a route to a desired piece of equipment (e.g., equipment associated with the current work item), may display parameters or other process data associated with the area of ​​the process plant, etc.

[0232] 26 is a diagram of an example mobile control room 2600. The mobile control room 2600 may include a first UI device 2602a, a second UI device 2602b, an appliance 2610, and an appliance 2620. The first UI device 2602a may include a display that provides a graphic 2615 representing the appliance 2610 or other data related to the appliance 2610 (e.g., current operating parameters, set points, alarms, errors, scheduled maintenance, calibration data, etc.). The second UI device 2602b may include a display that provides a graphic 2625 representing the appliance 2620 or other data related to the appliance 2620 (e.g., current operating parameters, set points, alarms, errors, scheduled maintenance, calibration data, etc.). The appliance 2610 may include a first context ID device 2604a, and the appliance 2620 may include a second context ID device 2604b.

[0233] In operation, an operator carrying a UI device 2602a may enter an area within range of a context ID device 2604a. The UI device 2602a may communicate with or scan the context ID device 2604a to enable the UI device 2602a to receive data from the context ID device 2604a. The UI device 2602a may act or provide output in response to the received data. In the illustrated embodiment, the UI device 2602a may provide a graphic 2615 representing the equipment 2610. In some embodiments, the UI device 2602a may provide alternative or additional output, such as other graphics, process parameter values, or alarms. An operator carrying a UI device 2602b may enter range of the context ID device 2604b to cause the UI device 2602b to provide a graphic 2625 representing the equipment 2620.

[0234] 27 is a flow chart illustrating an example method 2700 for generating a graphical user interface. The method 2700 may be implemented in whole or in part in one or more devices or systems, such as any of the UI devices 112. The method 2700 may be stored on the memory 815 as a set of instructions, routines, programs, or modules and may be executed by the processor 810.

[0235] The method 2700 begins with the UI device 112 identifying an external device or identifier / tag (block 2705). The identifier may be an image, sound, or barcode. The identifier may alternatively be a unique tag associated with transmission by an NFC system or an RFID system. In some embodiments, the identifier may be associated with a process entity, such as a process area, a device, a piece of equipment, or another UI device 112.

[0236] The UI device 112 may receive the context information based on the identified external device or identifier (block 2710). The UI device 112 may receive the context information from the identified external device or identifier in some embodiments. In another embodiment, the UI device 112 may receive the context information from the server 150 in response to transmitting data representing the identifier to the server 150. The context information may represent a context item such as a location, equipment, schedule, work item, etc.

[0237] The UI device 112 may provide the information on a display of the UI device 112 (block 2715). The information may be provided according to the received context information. For example, the UI device 112 may generate information corresponding to the received location, the identified equipment or device, the received schedule, or the received work item.

[0238] 28, a flowchart depicts an example method 2800 executing on the UI device 112 for controlling the process plant 10 in conjunction with the UI device 112. The method 2800 may be implemented in whole or in part in one or more networks or systems, such as the process control network 100. In particular, the method 2800 may be implemented in whole or in part in one or more devices or systems, such as the server 150, or in one or more devices or systems, such as any of the UI devices 112. The method 2800 may be stored on the memory 815 or memory 1203 as a set of instructions, routines, programs, or modules and executed by the processor 810 or processor 1201.

[0239] The method begins with the UI device 112 transmitting a first request for first data from a data storage area over a network to the server 150 (block 2805). The data storage area may be a modular logical data storage area including one or more devices configured to store process data corresponding to the process plant using a common format. The process data may include multiple types of process data such as configuration data, continuous data, batch data, measurement data, and event data.

[0240] The UI device 112 may receive the first data from the storage area in response to the first request from the server 150 (block 2810). The UI device 112 may display the first data received from the server 150 (block 2815).

[0241] The UI device 112 may receive an indication that the UI device 112 is in proximity to an external device (block 2820). The UI device 112 may include communications circuitry operative to detect the proximity of the external device. The communications circuitry may include near field communication (NFC) circuitry, radio frequency identification (RFID circuitry, Bluetooth circuitry, circuitry operating according to an IEEE 802.11 protocol, or circuitry operating according to a wireless HART protocol. In some cases, the UI device 112 may receive an indication that the UI device 112 is in proximity to an additional UI device 112.

[0242] The UI device 112 may transmit a second request for the second data to the server 150 according to the received indication (block 2825). In some embodiments, transmitting the second request includes transmitting a request to the server 150 for additional UI device 112 state information.

[0243] The UI device 112 may receive second data from the server 150 in response to the second request (block 2830). In some embodiments, the second data may represent the requested state information of the additional UI device 112. In such embodiments, the UI device 112 may also display the process control data from the storage area according to the received state information. Displaying the process control data may include replicating a display of the additional UI device 112 on the display of the UI device 112. Displaying the process control data may include arranging the data displayed on the additional UI device 112 on the display of the UI device 112.

[0244] In another embodiment, receiving an indication of proximity (block 1720) may include receiving an indication that the UI device 112 is in proximity to the process control device. Transmitting the second request (block 2825) may include transmitting to the server 150 an indication that the UI device 112 is in proximity to the process control device. In such an embodiment, receiving the second data may include receiving process control data related to the process control device (block 2830). Receiving process control data related to the process control device may include receiving and displaying one or more of alarms related to the process control device, maintenance tasks related to the process control device, a schematic of an area of ​​the process plant related to the process control device, or a status of an area of ​​the process plant related to the process control device.

[0245] In some embodiments, receiving an indication of proximity (block 2820) may include receiving an indication that the mobile device is in a particular area of ​​the process plant. In such embodiments, transmitting the second request (block 2825) may include transmitting to the server 150 an indication that the UI device 112 is in a particular area of ​​the plant. Additionally, receiving the second data (block 2830) may include receiving second process control data related to the particular area of ​​the process plant. Receiving the process control data related to the particular area may include receiving and displaying one or more of the following data: alarms related to the particular area of ​​the process plant, maintenance tasks related to the particular area of ​​the process plant, a schematic diagram of the particular area of ​​the process plant, or the status of one or more process control devices related to the particular area.

[0246] In certain embodiments, the UI device 112 may not be in communication with the server 150, but may be in communication with equipment in a particular area. For example, the UI device 112 may be in proximity to a particular piece of process equipment in the area of ​​the process plant and may be able to communicate with one or more devices (not the server 150) in the area of ​​the process plant directly or through an intermediate device (e.g., through a router or other access point that is part of a wireless network). This may be the case, for example, if the server 150 is not available or if the area of ​​the process plant is physically or logically separated from the server 150. In either case, the UI device 112 may transmit data or requests directly to devices in the area of ​​the process plant and / or receive data directly. For example, the UI device 112 may transmit a request for data directly to another device (not to the server 150) over a network, may receive data from the device in response to the request, may display the received data, may receive an indication that the UI device 112 is in proximity to an external device, etc.

[0247] A flow chart illustrating a method 2900 for facilitating mobile control of a process plant is provided in FIG. 29. The method 2900 includes implementing a mobile user interface device (block 2905) and providing a location awareness component capable of generating information regarding a location of the mobile device at the mobile user interface device (block 2910). The method 2900 also includes providing a database storing layout information of the process plant (block 2915) and implementing a first routine on the mobile user interface device (block 2920). The first routine may be operable to interpret information generated by the location awareness component according to information stored in the database to determine a relationship between a location of the mobile user interface device and a layout of the process plant. The mobile user interface device may also implement a second routine operable to generate a graphic for rendering on a display according to the determined relationship between the location of the mobile device and the layout of the process plant (block 2925). In some embodiments, providing a database storing layout information may include providing a database storing layout information from an overhead perspective or may include providing a database storing layout information from an eye-level perspective. The layout information may include, for each process device, a device tag, a device visualization (e.g., one or more visualizations, each corresponding to a type of mobile user interface device or a display type of the mobile user interface device), device location, and device connection information.The location aware component may be, for example, a GPS receiver, an RFID reader, an RFID tag, a communication channel between the mobile user interface device and a server that provides data to the mobile user interface device, a number of sensors (e.g., accelerometers and gyroscopes) operable to determine the movement and location of the mobile user interface device relative to an anchor point, etc. Performing the second routine, in some embodiments, includes performing a routine operable to generate a real-time graphic of the location of the mobile user interface device within the process plant as the mobile user interface device moves within the process plant. Generating the real-time graphic of the location of the mobile user interface device may include rendering on the display the location of the mobile user interface device from an overhead perspective or rendering on the display the location of the mobile user interface device in three dimensions from an eye-level perspective.

[0248] As may be apparent by now, the UI devices 112, and in some embodiments the control network 100, may be aware of various contextual information, including, importantly, the location of one or more of the UI devices 112 in the process plant 10. Various methods are described for the control network 100 (including the server 150) or the UI devices 112 to determine the location of the device. For example, the UI devices 112 may cooperate with the context ID device 2402 and / or the server 150 to determine the location of the UI devices 112. The UI devices 112 may also include a GPS receiver 832, which allows the UI devices 112 to determine their location by receiving signals from GPS satellites as is commonly understood. In some embodiments, however, one or more of the UI devices 112 may also include an inertial positioning system (IPS) 834. The IPS 834 may take the form of a discrete component or an integrated circuit. In at least one embodiment, IPS 834 is an integrated circuit that includes a high precision clock circuit, three accelerometers (one for each of the x-axis, y-axis, and z-axis), and three gyroscopes (one for each of the x-axis, y-axis, and z-axis). In some embodiments, IPS 834 also includes a compass or magnetometer.

[0249] In any case, the IPS 834 may operate to detect the movement and orientation of the UI device 112 in which it is present and provide information regarding the distance and direction the device is moving or has moved. Combining information about the detected movement and orientation of the UI device 112 with another information source indicating the initial location of the UI device 112 (an "anchor point") allows the UI device 112 to determine its location independent of any successive information sources. For example, the UI device 112 carried by the operator may have a GPS receiver and may track the location of the UI device 112 as the operator moves through an outdoor environment toward an indoor environment. As the operator crosses the boundary between the outdoor environment and the indoor environment, the UI device 112, and in particular the GPS receiver 832, will likely lose the GPS signal. The UI device 112 may use the last known location of the UI device 112 determined using the GPS receiver 832 as the anchor point. From the anchor point, the UI device 112 may determine the distance and direction the UI device 112 has moved in the indoor environment. Using this information, the UI device 112, routines running on the UI device 112, and potentially other devices (e.g., server 150, supervisor engine 106, etc.) may keep track of the location of the UI device 112. The UI device 112 may keep providing the operator with a depiction of the operator's position in the indoor environment, may provide the operator with navigation directions to a particular plant asset (e.g., a particular piece of equipment), may take or recommend actions based on the operator's location within the plant, etc.

[0250] It is noted that the GPS receiver 832 is not the only information source that can provide an anchor point for use in combination with the IPS 834. Any of the context ID devices 2402 may also cooperate with the UI device 112 to determine the anchor point. For example, as an operator crosses a boundary between an outdoor environment and an indoor environment, the context ID device 2402 at the threshold (e.g., an NFC device on a door frame) may communicate with the UI device 112 to establish the location of the UI device 112 and provide the anchor point. As another example, the operator may use the UI device 112 to scan or otherwise interact with a context ID device 2402 (e.g., an RFID tag, an NFC chip, a barcode, etc.) at any known fixed location in the process plant (e.g., on a process device, near a particular plant area, etc.) to provide the anchor point.

[0251] The UI device 112 may use the anchor points and information provided by the IPS 834 to plot a location of the UI device 112 in the process plant or other environment on a display of the UI device 112. In some embodiments, this includes plotting a location on a floor plan of the process plant, plotting a location on a 3D map of the process plant, plotting a location on a schematic diagram of the process plant, etc. Alternatively or in addition, the UI device 112 may provide navigation information to direct the operator to a desired location in the process plant (e.g., to a location associated with an assigned work item, to a selected location, to a device associated with an error or alarm, etc.). In some embodiments, the UI device 112 may provide navigation or location information to guide the operator to other personnel in the plant environment. This may be useful, for example, when attempting to locate injured personnel or personnel requesting assistance with a task.

[0252] The location of the UI device 112, whether provided by each UI device 112 with location data, GPS data, IPS data, or in collaboration with the context ID device 2402, may be provided to the control system, particularly the server 150 and / or the supervisor engine 106. In some embodiments, the presence of the UI device 112 in a particular area may cause the server 150, the supervisor engine 106, or the UI device 112 to disable one or more features of the UI device 112. For example, the microphone 842 and / or the camera 844 may be disabled when the UI device 112 is in an area where operator privacy may be important (e.g., a washroom) or where security considerations require it.

[0253] Similarly, various control aspects of a process plant may be altered in some embodiments by the presence of personnel in an area. For example, a particular safety system may have a first threshold when no personnel are present in the area, and a second, more conservative threshold when personnel are present in the area. In this manner, personnel safety may be improved.

[0254] FIG. 30 is a flow chart illustrating a method 3000 for determining a location of a mobile device within a process control environment. The method 3000 includes acquiring an anchor location within a process plant (block 3005) and determining the anchor location according to the acquired data (block 3010). The method also includes receiving data indicative of an acceleration and orientation of the mobile device from circuitry of the mobile device (block 3015) and determining a location of the mobile device according to the received data and the anchor location (block 3020). In some embodiments, acquiring the data indicative of the anchor location includes determining a location of the mobile device using a global satellite positioning system, such as GPS, GLONASS, or any other satellite positioning system. Acquiring the data indicative of the anchor location includes acquiring an image (e.g., an image of a bar code, an image of a portion of the process plant, etc.) in some embodiments. When an image of the portion of the process plant is acquired, for example, the captured image may be compared to a database of geolocated images (i.e., images associated with a corresponding physical location). The data indicative of the anchor location may also include data of one or more wireless signals, such as signals conforming to the IEEE 802.11 specification, signals acquiring data from an RFID device, signals establishing a Bluetooth connection, or signals establishing a near field communication session. Acquiring data indicative of the anchor location may also include identifying process control devices in the vicinity of the mobile device and receiving or retrieving information related to the location of the process control devices from a memory (or from a remote database).

[0255] Receiving data indicative of the acceleration and orientation of the mobile device includes receiving data from one or more accelerometers and from one or more gyroscopes, receiving data from a magnetometer, receiving data from an inertial measurement unit, and / or receiving data from a device that includes three accelerometers and three gyroscopes in various embodiments. In some embodiments, the method also includes launching an application on the mobile device based at least in part on the determined position of the mobile device, the application being operable to modify operation of the process plant.

[0256] Referring to FIG. 31 , a flow chart depicts a method 3100 for contextual operation of a mobile device in a process control environment. The method includes acquiring information at the mobile device to identify a process entity in the process control environment (block 3105). The process entity may be any process entity in the process plant, including, but not limited to, an area of ​​the process plant, a process control device, a controller, etc. The method also includes identifying work item data associated with the process entity at the mobile device (block 3110). The work item data includes information regarding a target function associated with the process entity. An event at the mobile device is automatically triggered in response to the acquired information and the identified work item data to facilitate implementation of the target function associated with the process entity (block 3115). The target function may be a scheduled task associated with the process entity. In some embodiments, the triggering event at the mobile device includes at least one of causing the mobile device to provide instructions corresponding to performing the scheduled task, causing the mobile device to display safety information (e.g., materials at the process control device, whether the process control device is deactivated and / or locked out, whether residue is detected, etc.), causing the mobile device to launch an application for performing the scheduled task, or causing the mobile device to provide an interface for performing the scheduled task. The target function may be an authorization verification function associated with the process entity in some embodiments. The automatically triggered event may be identifying a user ID associated with a user operating the mobile device, identifying an authorization token associated with the process entity, determining an authorization level based on the user ID and the authorization token, and providing an interface for modifying a parameter associated with the process entity to an extent indicated by the authorization level.The permission level may indicate the degree to which modification of a parameter associated with the process control entity is permitted. The goal function associated with the process entity may also be an alarm check function, and triggering the event may include identifying an alarm and providing an indication of the alarm. The goal function may also be a location determination function, and the automatically triggered event may be determining a location associated with the process control entity and providing a map graphic displaying the location of the process entity within the process control environment. In some embodiments, acquiring information to identify the process entity includes acquiring one or more data tags from one or more corresponding identification devices having a fixed spatial relationship corresponding to the process entity in the process control environment and comprising a unique identifier. In some embodiments, the context identification device is a barcode, and acquiring tag data includes capturing an image of the barcode and parsing the barcode to identify the tag data. The context identification device may be a wireless transmitter, and acquiring tag data may include detecting a radio frequency signal emitted by the wireless transmitter and carrying the tag data. The wireless transmitter may be an NFC device, an RFID device, or a personal area network device that transmits short wavelength wireless transmissions. Acquiring information to identify a process entity in the process control environment may in some embodiments include uniquely capturing an image associated with the process entity. Acquiring information may also include capturing an audio signal and determining that the audio signal correlates to the process entity. Similarly, acquiring information may include detecting a movement pattern associated with the process entity.

[0257] Analysis of physical phenomena The UI device 112 may cooperate with the expert system 104 and the big data appliance 102 in some embodiments to analyze data related to physical phenomena. Physical phenomena that may be analyzed include, but are not limited to, light-related phenomena in the visible and non-visible spectrum (e.g., flame color in the visible and infrared spectrum) and vibration-related phenomena in the audible, subaudible, and supraaudible ranges (e.g., sound and other vibrations). Personnel-carried UI devices 112 equipped with cameras, accelerometers, microphones, or other instruments may be used to capture and / or record data related to physical phenomena. The cameras may, for example, sense and record images in the visible or, in certain embodiments, infrared or other spectrums. The microphones may sense and / or record audible, subaudible, and / or supraaudible vibrations transmitted by air. The accelerometers may sense and / or record vibrations when the UI device 112 is placed in contact with a piece of equipment. Any and / or all of these types of data may be transmitted from the UI device 112 to the expert system 104 for analyzing and / or comparing the data in the big data appliance 102.

[0258] A method 3200 for analyzing a physical phenomenon in a process plant is depicted in FIG. 32. The method 3200 includes detecting, at a mobile device, a physical phenomenon in the process plant (block 3205). Detecting the physical phenomenon may include detecting a scene, detecting a sound, and / or detecting a vibration in various embodiments. By way of example only and not limitation, detecting the physical phenomenon may include detecting a scene including a flame, a sound associated with a combustion chamber, a sound associated with fluid movement, an image or video of a top of stack, and / or a vibration associated with a rotating element in various embodiments.

[0259] The method 3200 also includes converting the detected physical phenomenon into digital data representative of the physical phenomenon at the mobile device (block 3210). That is, taking the detected physical phenomenon (scene, sound, vibration, etc.) and converting it into digital data in the form of, for example, a digital image, digital video, digital sound file, or digital representation of the detected vibration. The method 3200 further includes transmitting the digital data to an expert system (block 3215) and analyzing the digital data in the expert system to determine a state of one or more process elements (block 3220). By way of example only, if the detected physical phenomenon is a flame scene, analyzing the data may include analyzing a color associated with one or more portions of the flame, analyzing a shape of the flame, and / or analyzing a flame movement; if the detected physical phenomenon is a sound or vibration associated with fluid movement, analyzing the data may include detecting cavitation associated with fluid movement; if the detected physical phenomenon is a top of stack scene, analyzing the data may include analyzing a color or volume of emitted smoke.

[0260] The method 3200 may also include, in various embodiments, detecting an abnormal condition associated with one or more process elements, determining a cause of the abnormal condition from the digital data, automatically initiating a change in one or more process control parameters to correct the abnormal condition, automatically creating a work item to have personnel take action to correct the abnormal condition, providing an indication to an operator that corrective action should be taken to resolve the abnormal condition, and / or determining a fuel composition associated with a flame or combustion chamber.

[0261] The following additional considerations apply to the above description: Throughout this specification, acts described as being performed by the server 150, the UI device 112, or any other device or routine generally refer to acts or processes of a processor that manipulates or transforms data according to machine-readable instructions. The machine-readable instructions may be stored on and retrieved from a memory device communicatively coupled to the processor. That is, the methods described herein may be embodied by a set of machine-executable instructions stored on a computer-readable medium (i.e., on a memory device). The instructions, when executed by one or more processors of a corresponding device (e.g., a server, a mobile device, etc.), cause the processor to perform the method. When instructions, routines, modules, processes, services, programs, and / or applications are referred to herein as being stored or saved on a computer-readable memory or computer-readable medium, the words "stored" and "saved" are intended to exclude transitory signals.

[0262] User interface devices are referred to interchangeably herein as "UI devices" and "mobile UI devices." In most cases, these devices are simply referred to as "UI devices," but in certain descriptions, the term "mobile" is added to indicate this, and in certain exemplary uses, the UI device may be a mobile UI device. The use or absence of the term "mobile" should not be considered limiting, as the concepts described herein may apply to any and all UI devices that may be used in a process plant environment.

[0263] While many of the examples herein refer to a browser to display information, each example contemplates the use of a native application that communicates with a server to provide information. The native application may be designed for any mobile platform, any workstation operating system, or any combination of a mobile platform and / or workstation operating system and / or web browser. For example, a mobile UI device may run on the Android platform, while a cooperating stationary UI device (e.g., a workstation) may run on the Windows 7 platform.

[0264] Additionally, the terms "operator," "personnel," "people," "user," "technician," and other similar terms are used to describe people in a process plant environment who may use or interact with the systems, apparatus, and methods described herein, but these terms are not intended to be limiting. As can be seen from the above description, the systems, apparatus, and methods described herein may have the advantage or effect of freeing plant personnel to a certain degree from the traditional boundaries of a process control system. That is, operators may undertake some activities traditionally engaged in by technicians, technicians may participate in activities traditionally reserved for operators, and so on. When a particular term is used in the description, the term is used in part for the traditional activities engaged in by plant personnel, but is not intended to limit the personnel who may be able to engage in the particular activity.

[0265] Additionally, throughout this specification, plural instances may implement components, operations, or structures that are described as a single instance. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of the individual operations may be performed simultaneously, and the operations need not be performed in the order illustrated. Structures and functionality presented as separate components of an exemplary configuration may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements fall within the scope of the subject matter of this specification.

[0266] Unless otherwise specified, descriptions herein using words such as "processing," "computing," "calculating," "determining," "identifying," "presenting," "displaying," and the like may refer to machine (e.g., computer) acts or processes that manipulate or transform data represented as physical (e.g., electronic, magnetic, or optical) quantities in one or more memories (e.g., volatile memory, non-volatile memory, or a combination thereof), registers, or other machine components that receive, store, transmit, or display information.

[0267] When implemented in software, any of the applications, services, and engines described herein may be stored in any tangible, non-transitory computer-readable memory, such as, for example, on a magnetic disk, laser disk, solid-state memory device, molecular memory storage device, or other storage medium, in the RAM or ROM of a computer or processor, etc. It should be noted that, although the exemplary systems disclosed herein are disclosed as including, among other components, software and / or firmware executing on hardware, such systems should be considered merely illustrative and not limiting. For example, it is contemplated that any or all of these hardware, software, and firmware components may be embodied exclusively in hardware, exclusively in software, or in any combination of hardware and software. Thus, one skilled in the art will readily appreciate that the examples provided are not the only ways to implement such systems.

[0268] Thus, while the present invention has been described with reference to specific examples which are intended to be merely illustrative and not limiting of the invention, it will be apparent to those skilled in the art that modifications, additions, or deletions may be made to the disclosed embodiments without departing from the spirit and scope of the invention.

[0269] Additional notes The following appended sections of the present disclosure are merely illustrative and are not intended to limit the scope of the present disclosure.

[0270] Addendum 1. A mobile user interface device for controlling a process plant, comprising: a processor communicatively coupled to a network; a memory communicatively coupled to the processor; a display communicatively coupled to the processor; a communication circuit operable to detect proximity of the mobile user interface device to an external device; and one or more routines stored on the memory device and executable by the processor to cause the processor to transmit a first request for first data over the network, receive the first data over the network in response to the first request, display the received first data on the display, receive an indication that the mobile user interface device is in proximity to the external device, transmit a second request for second data over the network in accordance with the received indication, and receive the second data over the network in response to the second request.

[0271] Item 2. The mobile user interface device of Item 1, wherein receiving an indication that the mobile user interface device is in proximity to an external device includes receiving an indication that the mobile user interface device is in proximity to an additional user interface device.

[0272] Appendix 3. A mobile user interface device as described in either Appendix 1 or Appendix 2, wherein transmitting a second request for second data in accordance with the received indication includes transmitting a request for state information of the additional user interface device to the server, and receiving the second data includes receiving the requested state information of the additional user interface device from the server.

[0273] Appendix 4. The mobile user interface device of any one of Appendixes 1 to 3, further comprising displaying process control data from the server storage area in accordance with received status information of the additional user interface device, wherein the server is communicatively coupled to a unitary logical data storage area including one or more data storage devices configured to store process data corresponding to the process plant, including multiple types of process data selected from configuration data, measurement data, batch data, continuous data, and event data, using a common format.

[0274] Appendix 5. The mobile user interface device of Appendix 4, wherein displaying process control data from the storage area in accordance with received status information of the additional user interface device includes replicating a display of the additional user interface device on a display of the mobile user interface device.

[0275] Addendum 6. A mobile user interface device as described in either Addendum 4 or Addendum 5, wherein displaying the process control data from the storage area in accordance with the received status information of the additional user interface device includes placing the data displayed on the additional user interface device on a display of the mobile user interface device.

[0276] Appendix 7. A mobile user interface device as described in any one of Appendixes 1 to 6, wherein receiving an indication that the mobile user interface device is in proximity to an external device includes receiving an indication that the mobile user interface device is in proximity to a process control device.

[0277] Appendix 8. A mobile user interface device as described in any one of Appendixes 1 to 7, wherein transmitting a second request for second data in accordance with the received indication includes transmitting an indication that the mobile user interface device is in proximity to a process control device, and receiving the second data includes receiving process control data related to the process control device.

[0278] Appendix 9. The mobile user interface device of any one of Appendixes 1 to 8, wherein receiving process control data related to the process control device includes receiving and displaying one or more of the following data: (a) alarms related to the process control device; (b) maintenance tasks related to the process control device; (c) a schematic diagram of an area of ​​the process plant related to the process control device; or (d) a status of an area of ​​the process plant related to the process control device.

[0279] Appendix 10. The mobile user interface device of any one of Appendixes 1 to 9, wherein receiving an indication that the mobile user interface device is in proximity to an external device includes receiving an indication that the mobile device is in a particular area of ​​the process plant.

[0280] Appendix 11. A mobile user interface device as described in any one of Appendixes 1 to 10, wherein transmitting a second request for second data in accordance with the received indication includes transmitting an indication that the mobile user interface device is in a particular area of ​​the process plant, and receiving the second data includes receiving process control data related to the particular area of ​​the process plant.

[0281] Appendix 12. A mobile user interface device as described in any one of Appendixes 1 to 11, wherein receiving process control data related to the process control device includes receiving and displaying one or more of the following data: (a) alarms related to a particular area of ​​the process plant; (b) maintenance tasks related to a particular area of ​​the process plant; (c) a schematic diagram of a particular area of ​​the process plant; or (d) a status of an area of ​​the process plant related to the process control device.

[0282] Appendix 13. A mobile user interface device according to any one of appendices 1 to 12, wherein the communication circuitry includes a near field communication (NFC) circuitry.

[0283] Addendum 14. A mobile user interface device as described in any one of Addendums 1 to 13, wherein the communication circuitry includes a radio frequency identification (RFID) circuitry.

[0284] Item 15. A mobile user interface device according to any one of items 1 to 14, wherein the communication circuitry includes a Bluetooth circuitry.

[0285] Item 16. A mobile user interface device as described in any one of items 1 to 15, wherein the communications circuitry includes circuitry that operates according to the IEEE 802.11 protocol.

[0286] Item 17. A mobile user interface device as described in any one of items 1 to 16, wherein the communications circuitry includes circuitry that operates according to the wireless HART protocol.

[0287] Clause 18. A method performed by a mobile user interface device for a process plant, the method including: transmitting a first request for first data over a network from a data storage area; receiving the first data from the storage area in response to the first request; displaying the received first data on a display of the mobile user interface device; receiving an indication that the mobile user interface device is in proximity to an external device; transmitting a second request for second data in accordance with the received indication; and receiving the second data in response to the second request.

[0288] Clause 19. The method of clause 18, wherein receiving an indication that the mobile user interface device is in proximity to an external device includes receiving an indication that the mobile user interface device is in proximity to an additional user interface device.

[0289] Addendum 20. The method of any of Addendum 18 or Addendum 19, wherein transmitting a second request for second data in accordance with the received indication includes transmitting a request for state information of the additional user interface device to the server, and receiving the second data includes receiving the requested state information of the additional user interface device from the server.

[0290] Addendum 21. The method of any one of Addendums 18 to 20, further comprising displaying the process control data from the storage area according to the received status information of an additional user interface device.

[0291] Addendum 22. A method according to any one of Addendums 18 to 21, wherein displaying process control data from the storage area in accordance with received status information of the additional user interface device includes replicating a display of the additional user interface device on a display of the mobile user interface control device.

[0292] Addendum 23. A method according to any one of Addendums 18 to 22, wherein displaying process control data from a storage area in accordance with received status information of an additional user interface device includes placing the data displayed on the additional user interface device on a display of the mobile user interface device.

[0293] Addendum 24. A method as described in any one of Addendums 18 to 23, wherein receiving an indication that the mobile user interface device is in proximity to an external device includes receiving an indication that the mobile user interface device is in proximity to a process control device.

[0294] Addendum 25. The method of any one of Addendums 18 to 24, wherein transmitting a second request for second data in accordance with the received indication includes transmitting an indication that the mobile user interface device is in proximity to a process control device, and receiving the second data includes receiving process control data related to the process control device.

[0295] Addendum 26. The method of any one of Addendums 18 to 25, wherein receiving process control data related to the process control device includes receiving and displaying one or more of the following data: (a) alarms related to the process control device; (b) maintenance tasks related to the process control device; (c) a schematic diagram of an area of ​​the process plant related to the process control device; or (d) a status of an area of ​​the process plant related to the process control device.

[0296] Addendum 27. The method of any one of Addendums 18 to 26, wherein receiving an indication that the mobile user interface device is in proximity to an external device includes receiving an indication that the mobile user interface device is in a particular area of ​​the process plant.

[0297] Addendum 28. The method of any one of Addendums 18 to 27, wherein transmitting a second request for second data in accordance with the received indication includes transmitting an indication that the mobile user interface device is in a particular area of ​​the process plant, and receiving the second data includes receiving process control data related to the particular area of ​​the process plant.

[0298] Addendum 29. The method of any one of Addendums 18 to 28, wherein receiving process control data related to the process control device includes receiving and displaying one or more of the following data: (a) alarms related to a particular area of ​​the process plant; (b) maintenance tasks related to a particular area of ​​the process plant; (c) a schematic diagram of a particular area of ​​the process plant; or (d) a status of an area of ​​the process plant associated with the process control device.

[0299] Item 30. The method of any one of items 18 to 29, wherein the communication circuitry includes a near field communication (NFC) circuitry.

[0300] Addendum 31. The method of any one of Addendums 18 to 30, wherein the communication circuitry includes a radio frequency identification (RFID) circuitry.

[0301] Item 32. The method according to any one of items 18 to 31, wherein the communication circuitry includes a Bluetooth circuitry.

[0302] Item 33. The method according to any one of items 18 to 32, wherein the communications circuitry includes circuitry that operates according to the IEEE 802.11 protocol.

[0303] Addendum 34. The method of any one of Addendums 18 to 33, wherein the communication circuitry includes circuitry that operates according to the wireless HART protocol.

[0304] Addendum 35. A computer-readable medium storing instructions executable by a processor in a mobile user interface device for controlling a process plant, the instructions being operable to cause the processor to transmit a first request to a server for first data from a data storage area, receive from the server the first data from the storage area in response to the first request, display the first data received from the server on a display, receive an indication that the mobile user interface device is in proximity to an external device, transmit a second request to the server for second data in accordance with the received indication, and receive from the server the second data in response to the second request.

[0305] Item 36. The computer-readable medium of Item 35, wherein the instructions for causing a processor to receive an indication that the mobile user interface device is in proximity to an external device include instructions for causing the processor to receive an indication that the mobile user interface device is in proximity to an additional user interface device.

[0306] Addendum 37. The computer-readable medium of any of Addendum 35 or Addendum 36, wherein the instructions for causing the processor to transmit a second request for second data to the server in accordance with the received indication include instructions for causing the processor to transmit a request for state information of the additional user interface device, and the instructions for causing the processor to receive the second data from the server include instructions for causing the processor to receive the requested state information of the additional user interface device.

[0307] Addendum 38. A computer-readable medium according to any one of Addendums 35 to 37, further comprising instructions for causing a processor to display process control data from the storage area according to received status information of an additional user interface device.

[0308] Addendum 39. A computer-readable medium according to any one of Addendums 35 to 38, wherein the instructions for causing the processor to display process control data from the storage area in accordance with received status information of the additional user interface device include instructions for causing the processor to replicate a display of the additional user interface device on a display of the mobile user interface device.

[0309] Addendum 40. A computer-readable medium as described in any one of Addendums 35 to 39, wherein the instructions for causing a processor to display process control data from a storage area in accordance with received status information of an additional user interface device include instructions for causing a processor to arrange the data displayed on the additional user interface device on a display of the mobile user interface device.

[0310] Addendum 41. A computer-readable medium as described in any one of Addendums 35 to 40, wherein instructions for causing a processor to receive an indication that a mobile user interface device is in proximity to an external device include instructions for causing a processor to receive an indication that a mobile user interface device is in proximity to a process control device.

[0311] Addendum 42. A computer-readable medium as described in any one of Addendums 35 to 41, wherein the instructions for causing the processor to transmit a second request for second data to the server in accordance with the received indication include instructions for causing the processor to transmit to the server an indication that the mobile user interface device is in proximity to a process control device, and the instructions for causing the processor to receive the second data include instructions for causing the processor to receive process control data related to the process control device.

[0312] Addendum 43. A computer-readable medium as described in any one of Addendums 35 to 42, wherein the instructions for causing a processor to receive process control data related to a process control device include instructions for causing the processor to receive and display one or more of the following data: (a) alarms associated with the process control device; (b) maintenance tasks associated with the process control device; (c) a schematic diagram of an area of ​​the process plant associated with the process control device; or (d) a status of an area of ​​the process plant associated with the process control device.

[0313] Addendum 44. The computer-readable medium of any one of Addendums 35 to 43, wherein the instructions for causing a processor to receive an indication that a mobile user interface device is in proximity to an external device include instructions for causing a processor to receive an indication that the mobile user interface device is in a particular area of ​​a process plant.

[0314] Addendum 45. The computer-readable medium of any one of Addendums 35 to 44, wherein the instructions for causing the processor to transmit a second request for second data to the server in accordance with the received indication include instructions for causing the processor to transmit to the server an indication that the mobile user interface control device is in a particular area of ​​the process plant, and the instructions for causing the processor to receive the second data include instructions for causing the processor to receive process control data related to the particular area of ​​the process plant.

Claims

1. receiving, at the mobile user interface device, the unique identifier transmitted from the device external to the plant environment; The unique identifier is (i) indicating that the mobile user interface device is in proximity to the external device; (ii) stored in a database in association with one or more process entities associated with the area in which the external device is located; (iii) identifying a process control device associated with the unique identifier; (iv) causing the mobile user interface device to interactively render a user interface to change a parameter in a process controller utilized to control the process control device associated with the unique identifier; in response to receiving the unique identifier, the mobile user interface device is a first mobile user interface device; the external device is a second mobile user interface device; method.

2. receiving the unique identifier includes receiving the unique identifier via a near field communication (NFC) circuit; The method of claim 1.

3. receiving the unique identifier includes receiving the unique identifier via a radio frequency identification (RFID) circuit; The method of claim 1.

4. receiving the unique identifier includes receiving the unique identifier via circuitry configured for wireless communication at a frequency between 2400 MHz and 2480 MHz. The method of claim 1.

5. receiving the unique identifier includes receiving the unique identifier via circuitry operating in accordance with an IEEE 802.11 protocol; The method of claim 1.

6. receiving the unique identifier includes receiving the unique identifier via circuitry configured to operate according to a wireless process control protocol. The method of claim 1.

7. replicating, via the user interface displayed on the first mobile user interface device, a display provided via the second mobile user interface device; The method of claim 1 further comprising:

8. (a) an alarm associated with the process control device; (b) a task associated with the process control device; (c) a schematic diagram of an area of ​​a process plant associated with the process control device; (d) a status of the area of ​​the process plant associated with the process control device; and displaying, via the user interface, one or more of: The method of claim 1.

9. 1. A mobile user interface device for controlling a process plant, comprising: one or more processors; a display coupled to one or more of said processors; a communications circuit coupled to one or more of said processors; a memory coupled to one or more of said processors and storing computer readable instructions; Including, The computer readable instructions, when executed, (a) receiving a unique identifier transmitted from a device external to the plant environment via the communication circuit; The unique identifier is (i) indicating that the mobile user interface device is in proximity to the external device; (ii) stored in a database in association with one or more process entities associated with the area in which the external device is located; (b)(iii) identifying a process control device associated with the unique identifier; (iv) interactively rendering a user interface via the display to change parameters in a process controller utilized to control the process control device associated with the unique identifier; responding to receipt of the unique identifier by causing one or more of the processors to: causing one or more of said processors to the mobile user interface device is a first mobile user interface device; the external device is a second mobile user interface device; Mobile user interface devices.

10. the communication circuitry includes a near field communication (NFC) circuitry; receiving the unique identifier includes receiving the unique identifier via the near field communication (NFC) circuitry. The mobile user interface device of claim 9.

11. the communication circuitry includes a radio frequency identification (RFID) circuitry; receiving the unique identifier includes receiving the unique identifier via the radio frequency identification (RFID) circuitry. The mobile user interface device of claim 9.

12. the communication circuit includes specific circuitry configured for wireless communication at frequencies between 2400 MHz and 2480 MHz; receiving the unique identifier includes receiving the unique identifier via the identification circuit; The mobile user interface device of claim 9.

13. the communication circuitry includes specific circuitry configured to operate in accordance with the IEEE 802.11 protocol; receiving the unique identifier includes receiving the unique identifier via the identification circuit; The mobile user interface device of claim 9.

14. the communication circuitry includes a wireless process control circuit configured to operate according to a wireless process control protocol; receiving the unique identifier includes receiving the unique identifier via the wireless process control circuitry. The mobile user interface device of claim 9.

15. The memory, when executed, replicating, via the user interface displayed on the display of the first mobile user interface device, a display provided via the second mobile user interface device; and further comprising computer readable instructions for causing one or more of said processors to: The mobile user interface device of claim 9.

16. The memory, when executed, (a) an alarm associated with the process control device; (b) a task associated with the process control device; (c) a schematic diagram of an area of ​​the process plant associated with the process control device; (d) a status of the area of ​​the process plant associated with the process control device; via the user interface rendered via the display. The mobile user interface device of claim 9.

Images