JP7396674B2 - Method and system for providing role-based user interface and non-transitory computer-readable medium - Google Patents

Description

TECHNICAL FIELD This disclosure relates generally to process control systems, and more particularly to methods and apparatus for providing role-based user interfaces.

Generally, process control systems, such as those used in chemical processing, petroleum refining, or other processing operations, include one or more process control devices and input/output (I/O) devices, and include one or more process control devices and input/output (I/O) devices. and input/output devices are communicatively connected to at least one host or operator workstation and one or more field devices via an analog bus, a digital bus, or a combined analog/digital bus. Field devices can be, for example, valves, valve positioners, switches, and transmitters (e.g., temperature, pressure, and flow sensors) that perform process control functions within a process, such as opening or closing a valve or measuring process control parameters. conduct. Process controllers receive signals indicative of process measurements made by field devices and process this information to perform control routines, make other process control decisions, and sound process control system alarms. Create a signal. In this method, the process controller coordinates the execution of a control strategy using the field devices via a bus and/or other communication links communicatively connecting the field devices.

Process information from field devices and controllers may be made available to a system comprising one or more applications (i.e., software routines, programs, etc.) running on an operator workstation (e.g., a processor-based system). It allows operators to, for example, visually confirm the current state of the process (e.g., through a graphical user interface), change process control routine settings, evaluate the process, change process operations (e.g., through visual object diagrams), use field devices and Desired functions related to the process can be performed, such as visual confirmation of alarms generated by the process control device, process operation simulation for the purpose of human resource development and/or process evaluation. Many process control systems also include one or more application stations. Typically, these application stations include personal computers, workstations, etc. that are communicatively connected to controllers, operator workstations, and other systems within a process control system via a local area network (LAN). used and implemented.

In some known process control systems, one or more operating terminals and/or application stations provide campaign management functions, maintenance management functions, virtual control functions, diagnostic functions, real-time monitoring functions, safety-related functions, configuration within the process control system. One or more software applications may be executed to accomplish the functionality, etc. Additionally, certain known process control systems include process control systems that include alarms, process variable values, process-related quality parameter values, process fault detection information, and/or process status information generated by controllers or devices within the process. One or more operating terminals and/or application stations are provided with a graphical user interface for displaying control information.

In some known process control systems, one or more process control-related applications include user interface functionality, such as an operating system (e.g., Windows) on an operator station or terminal that provides a graphical interface to the process control system. based operating system). In such systems, various applications, especially graphical user interface sections, interact directly and independently (eg, independently of other applications) with the operating system of the operator station. Managing these relatively independent graphical interfaces (e.g. displays and windows) is complex because each display provides different types of information (e.g. diagrams, text, trends, alarms, etc.) at different times. be. Furthermore, different people place different values on information displayed through a graphical interface. For example, graphical interfaces for diagnostic management applications display information that is not available to the user, resulting in a very complex display.

Typically, software systems that develop, monitor, operate, and interact with a process control environment provide a role-dependent view of the user interface to a variety of users. More specifically, the software system filters and organizes engineering tools and information according to the user's role in the corresponding organization (“organizational role” or simply “role”). Organizational roles include, by way of example only, production manager, maintenance manager, control systems engineer, or electrical instrumentation engineer. More generally, an organizational role is any combination of responsibilities, access rights and other privileges, security tolerances, skills expected of a user, etc. The software system provides filtered information and tool selections to the user in a view that includes, for example, a predetermined user interface screen, a series of user interface screens, a set of related user interface screens displayed simultaneously, etc. Good too. Thus, two users in different organizational roles may be presented with different options and/or arrangements of software applications, libraries, assets, data trees, etc. after logging in. Additionally, as these users select and invoke functions within their respective views, the computing environment may continually filter and organize information according to the user's role. As a result, users can find relevant information faster and easily take appropriate corrective actions, analyze, and distinguish between information that is relevant to their work role/tasks and unimportant data. Potential human errors associated with cognitive overload (or pressure) of having to do things can be reduced. In the fabrication plant environment, this time savings and reduction in human error often saves customers millions of dollars in production losses due to mistakes that lead to plant shutdowns and production losses due to products that do not meet specifications. can be eliminated. In extreme cases, human error can result in death or injury to plant personnel or damage to expensive process equipment.

Role-dependent views include, for example, (1) visualizations that include process displays, dashboards, various faceplates, machine views, etc.; (2) logic displays that represent control modules, phases, recipes, operations, functions, etc.; (3) Instructions or “knowledge” displays including standard operating procedures, device manuals, material handling nodes, loop diagrams, etc.; (4) business information displays showing orders, equipment tracking, material consumption, power consumption, etc.; (5) equipment. any suitable number of user interfaces containing information such as system health displays, including status data, device alerts, vibration data, etc.; and (6) input/output (I/O) displays showing I/O devices and signals. It may also include a screen. As an example, when a control systems engineer logs in, the software system displays process displays and dashboards as part of the visualization, control modules, phases, operations and functions as part of the logic display, and loop diagrams as part of the knowledge display. etc. may be created. Also, when an electrical instrumentation engineer logs in, the software system may create a device dashboard as part of the visualization, calculations as part of the logic, and a device manual as part of the knowledge display. Inter-screen navigation may be role-dependent if the role-dependent view comprises multiple screens, e.g., if the computer environment displays equipment status to both process control engineers and electrical instrumentation engineers, the software system provides electrical instrumentation engineers with a link (e.g., a button on a toolbar, a choice in a pull-down menu, an icon next to a single piece of equipment) to navigate directly to equipment tracking; It does not need to be presented.

To create role-dependent views, software systems organize functionality and data into layers, each layer containing information gathered from a variety of sources (databases, devices that output real-time signals, operator input, etc.). , may be mapped to user roles. The mapping of layers to user-dependent views may be specific to each component of the software system or to each software system operating as a whole. In an embodiment, the software system retrieves the user's role from the database and uses each configuration file to identify the information layer mapped to the user's role for the selected software application and create a role-dependent view. . Because any desired number of levels of roles within an organization can be defined, the software system may layer multiple layers of functionality and data to create a given view. For example, the role of a maintenance manager may correspond to multiple sub-roles depending on the technical scope for which the maintenance manager is responsible. In general, roles are multi-tiered in any number. Users can also configure their own views, possibly overriding layer mappings in their own role-dependent views.

Disclosed herein are example embodiments of techniques that include methods and systems for providing role-based user interfaces. An example system includes a display device that displays a user interface and one or more processors. The one or more processors receive object information regarding objects of the process control system during a session, determine a user role based on the session, determine whether the object information is authorized information based on the user role; If the object information is certification information, display the object information through the user interface.

Another exemplary embodiment is a method, the method comprising displaying a user interface, receiving object information associated with an object of a process control system during a session, and determining a role of a user based on the session. . The method also determines whether the object information is authorization information based on the user's role, and if the object information is authorization information, displays the object information through the user interface.

FIG. 1 is a diagram of an exemplary process control system and workstation in which role-based users are part of a software system that develops, monitors, operates, and exchanges information with the process control system. An interface may be implemented. FIG. 2 illustrates an exemplary method of implementing the workstation of FIG. FIG. 3 illustrates an exemplary role-based display interface implemented on the workstation of FIG. FIG. 4 illustrates another example role-based display interface. FIG. 5 illustrates another example role-based display interface. FIG. 6 illustrates another example role-based display interface. FIG. 7 illustrates another example role-based display interface. FIG. 8 is a flowchart of an example process implementing the example workstations of FIGS. 1 and 2. FIG. 9 is a diagram of an exemplary processor platform used and/or programmed for execution of the exemplary process of FIG. 8, and more generally for implementation of the exemplary workstations of FIGS. 1 and 2. It is. FIG. 10 is an illustration of an example hierarchical menu organized according to an asset-centric perspective that may be displayed on the workstation of FIG. FIG. 11 is an illustration of an example hierarchical menu organized according to a logic-centric perspective that may be displayed on the workstation of FIG. FIG. 12 is an illustration of an example mapping of cluster information related to a process control system to multiple organizational roles. 13 is an illustration of example role-specific navigation paths between cluster information associated with the process control system of FIG. 1. FIG.

Although example methods and apparatus with, among other things, software and/or firmware implemented in hardware are described below, these examples are merely illustrative and should not be considered limiting. For example, it is contemplated that some or all of the hardware, software, and firmware components may be implemented exclusively in hardware, exclusively in software, or in any combination of hardware and software. Thus, while the following description describes exemplary methods and apparatus, those skilled in the art will readily appreciate that the examples presented are not the only ways to implement such methods and apparatus. .
Examples of information types related to process control systems/environments

In known systems, there are many ways to present information related to process control systems across applications and environments. For example, in an application running in an engineering environment, diagnostic information may be presented in an overlay or visually customized status display for each node type of the physical network. A node is an object or device that communicates wired and/or wirelessly with other devices. For example, field devices, switches, firewalls, etc. may all be considered nodes. In another second application running in an engineering environment, control integrity diagnostic information may be shown in the form of status icons in the module diagram. Engineering environment refers to a software environment that presents information through standard software interfaces. Additionally, each of the different applications described above may include varying levels of information that may or may not be useful to a particular user. For example, a maintenance engineer responsible for maintaining an asset within a plant (eg, a high-performance device such as a valve) may be interested in very detailed information about that asset (eg, diagnostic parameters, maintenance history, etc.). An operator's concern will primarily be whether the asset (eg, a valve) is opening or closing and how much product is passing through the valve. A control system engineer may indirectly monitor the valve and determine whether the asset is negatively impacting the engineer's control strategy or logic through signals from the asset. For example, a control system engineer may choose to hide valve information but still be notified of changes in valve status.

The software system in this disclosure can present information about objects corresponding to aspects of a process that can be presented to a user, among other types of information. Additionally, an object may include one or more facets that describe certain characteristics of the object. An object may have any number of facets that describe the object. For example, process control object facets include object identification information (e.g., object name, tag, nickname, etc.), physical information about the object (e.g., tank construction material, high-performance device size, etc.), and logical information about the object. graphical information about the object (e.g., process representation using icons rather than logic); input/output information about the object (e.g., information received from an asset); information about the object (e.g., associated actions the user can perform with the object), user task information regarding the object (e.g., related actions the user can perform with the object), etc. Object facets allow you to filter the information presented to users through the user interface to target specific users (e.g., maintenance technicians, operators, reliability engineers, supervisors, control systems engineers, control room operators, etc.). You can customize the user interface to display relevant information.

The software system also provides information related to tasks, which are a series of tasks performed by the user. Task sequences can be made as simple as possible to perform functions such as filling out forms or changing values on a process control system. More complex tasks may include starting or starting units or adjusting process loops. In some embodiments, a user may create and/or modify tasks to better meet plant needs.

In the embodiments disclosed herein, each facet may have three sets of default tasks. A configuration task allows a user to configure features of an object. For example, configuration tasks may include downloading software or information, exporting information, updating information, inspecting objects, operating instrumentation assets (eg, control devices), running methods on instrumentation assets, and the like. A runtime editing task allows a user to edit the contents of an object at runtime. For example, if the object is a graph, a runtime editing task may provide a way to change the lines depicted in the graph. Example runtime editing tasks include filtering columns, resizing the interface, hiding or showing facets, changing context (e.g., specifying or selecting another object), changing views, and/or trend tracing. Including the addition of Runtime write/execute tasks allow the user to change runtime values. For example, graphical blocks that can be used to visualize connections provide an interface that allows connections to be disabled. Exemplary runtime write/execute tasks are changing operating modes, changing object setpoints, changing alarm ranges, removing or disabling services, skipping connections, posting alarms, adjusting objects or processes, and changing values. Includes enforcement, analyzing alarms, and/or responding to system prompts.

Additionally, the user may create (customize) additional tasks tailored to a particular person or user role. Exemplary user-defined tasks include requesting input by a user, opening a display, dashboard, and/or faceplate, starting another task, and the like.

However, not all tasks are equally valuable to users. For example, a software application that performs diagnostic functions can be used to assess the health of software code (or logical components) running on a control device (e.g., control device loading, control module health, etc.) to the digital control system hardware (e.g., control module health, etc.). Any range of diagnostic information can be provided, ranging from the physical health of network switches, workstations, etc.), process equipment (e.g., heat exchangers, etc.), or single instruments such as temperature transmitters. For example, process control operators, systems engineers, configuration engineers, maintenance personnel, technical support, and others may use various aspects of the example integrated graphical user interfaces described herein to perform their duties. good. Accordingly, the information or tasks presented to users through the embodiments described herein may take into account differences in the responsibilities of users or individuals, such as, for example, operators, configuration engineers, maintenance personnel, and/or technical support. good. Unlike conventional systems, the software system disclosed herein organizes (e.g., customizes) the user interface by performing role-based filtering to provide the user with the best fit for the user's responsibilities or job duties. . That is, the information or tasks presented to the user may depend on the user's organizational role or responsibilities, the context or state of objects in the system, and/or the organized arrangement of the default desktop, dedicated visualizations in the user interface, or It may also be filtered based on display layout.

Additionally, process diagrams may be created using objects that include graphical components and interfaces to one or more physical devices that update the graphical components in real time. The object may be specific to a control strategy (eg, a PID loop object) or specific to a device (eg, a temperature sensor object). The user interface filters data that the object receives from the process plant and displays information related to the user's organizational role. Additionally, process diagrams can be created using hard-coded references to devices. When creating a supplementary display, the software system of the present disclosure searches for configuration data that specifies the relationship between a control strategy and a device from one or more configuration databases, and uses the searched information to create a supplementary display for an operator, a supplementary display for maintenance, etc. Displays or other supplementary displays specific to the user's role may be automatically created.

In addition to filtering information based on the user's organizational role or responsibilities, the software system of the present disclosure may filter the information displayed to the user based on the user's preferences. Examples of filtering information displayed to a user include presenting default settings for a software application based on the user's organizational role or responsibilities, showing or hiding certain information in a software application (e.g., displaying or hiding certain information in a software application) change the display name, title, or description of an object; view the interface connections of process physical components from another perspective; filter the tasks presented to the user; determine which object facets to display; This includes filtering what alert types and alarm types are available to the user and/or determining which alert types and alarm types to display to the user. In some embodiments, the system may use multiple filters to customize the user interface of the user display. In such embodiments, the system may filter in multiple layers, levels, or stages. For example, a first tier filter filters facets based on a user's organizational role and/or responsibilities, a second tier filter filters facets based on a particular asset (e.g., a valve), A three-tier filter may filter facets based on priority (eg, does the alarm meet a threshold for display?), and a fourth-tier filter may filter facets based on user preferences.

As discussed in detail below, the software system of the present disclosure organizes functions and data from multiple sources into role-specific layers, such as a maintenance layer, an operator layer, a control system engineering layer, and filters the information. It is also possible to facilitate
Example of a process control environment

FIG. 1 is a block diagram illustrating an example process control environment 100 that includes an example role-based processor 102 and a process control system 104. The example role-based processor 102 may be implemented and/or provided within the workstation 106. In other embodiments, role-based processor 102 may be included within a server, distributed computer network, and/or other computing device communicatively coupled to workstation 106.

In one embodiment, role-based processor 102 implements a software system that creates views based on a user's organizational role as described above. For clarity, exemplary functionality of the software system described above is described below with reference to role-based processor 102.

Exemplary process control system 104 may include any manufacturing equipment, process equipment, automation equipment, safety instrumented equipment, and/or other process control configurations or systems. In some embodiments, process control system 104 may include multiple facilities located at different locations. Additionally, the example process control environment 100 may include other process control systems (not shown) located within the same facility and/or located at different facilities.

The example process control environment 100 depicts one type of system that advantageously employs the example methods and software systems described in more detail below. However, the example methods and software systems described herein may be implemented, if desired, in other systems that are more complex or simpler than the example process control environment 100 and/or process control system 104 shown in FIG. and/or systems for use in connection with process control activities, business management activities, communication activities, etc.

The example process control system 104 of FIG. 1 includes a controller 108 communicatively coupled to a workstation 106. Process control system 104 also includes field devices 112 (eg, input and/or output devices). Field device 112 may include any type of process control component capable of receiving input, producing output, and/or controlling a process. Field devices 112 may include controls such as, for example, valves, pumps, fans, heaters, coolers, and/or mixers to control processes. Additionally, field devices 112 may include measurement or monitoring devices, such as temperature sensors, pressure gauges, concentration meters, level gauges, flow meters, and/or steam sensors to measure parts of the process. The control device may receive instructions from the controller 108 through the input 114 to execute specified commands and modify processes performed and/or controlled by the field device 112 . Furthermore, the measurement device measures process data, environmental data and/or input device data and transmits the measured data to the controller 108 through the output 116 as process data. This process data may include variable values that are measured outputs from each field device 112.

In the example illustrated in FIG. 1, example controller 108 may communicate with field devices 112 within process control system 104 via inputs 114 and/or outputs 116. Input 114 and output 116 may be implemented by a data bus. This data bus may be connected to intermediate communication components within process control system 104 . These communication components may include field connection boxes that communicatively connect the command area field devices 112 to the data bus. Additionally, the communication component may include a marshalling cabinet that organizes communication paths to the field devices 112 and/or field connection boxes. Still further, the communication component includes an I/O device 118 (e.g., an I/O card) that receives data from the field device 112 and converts the data into communication data receivable by the example controller 108. Good too. In addition, these I/O devices 118 may convert data or communications from controller 108 into a data format that a corresponding field device 112 can process. For example, the data bus may be implemented using a fieldbus protocol or other wired (eg, Profibus, DeviceNet, Foundation Fieldbus) and/or wireless communication protocols (eg, Wireless HART protocol, etc.).

The example controller 108 of FIG. 1 manages one or more control routines (eg, process control algorithms, functions, and/or instructions) that control field devices 112 within the process control system 104. Control routines include process monitoring applications, alarm management applications, process trending and/or history applications, diagnostic applications, batch processing and/or campaign management applications, statistical applications, streaming video applications, advanced control applications, safety instrumented applications, etc. But that's fine. The control routine may ensure that the process control system 104 produces a specified number of desired products whose quality is within a predetermined threshold. For example, process control system 104 may be configured as a batch system that produces products as a result and/or during a batch process. In other embodiments, the process control system 104 may include a continuous process manufacturing system that continuously produces products. Still further, controller 108 may send process data used within the control routine to example role-based processor 102.

In the example process control environment 100 of FIG. 1, a workstation 106 may be communicatively coupled to a controller 108 via a local area network (LAN) 110. Exemplary workstations 106 may include computing devices including personal computers, laptop computers, servers, controllers, smart phones, personal digital assistants (PDAs), microcomputers, and the like. Additionally, workstation 106 may be implemented using any suitable computer or processing system (eg, processor platform 900 shown in FIG. 9). For example, workstation 106 may be implemented using a single processor personal computer, a single or multiprocessor workstation, or the like.

The example of FIG. 1 depicts an exemplary workstation 106 that is external to process control system 104. In another example, workstation 106 may be included within process control system 104 and may be communicatively connected directly to controller 108. Additionally, process control environment 100 may include a router (not shown) to communicatively connect other workstations (not shown) to controller 108 and/or connect workstation 106 to other workstations (not shown). It may also be communicatively connected to other control devices (not shown) within the process control system. Process control environment 100 may also include a firewall (not shown) that provides remote workstations (e.g., workstations external to process control environment 100) with access to resources within process control environment 100. good.

Exemplary LAN 110 may be implemented using any desired communication medium and protocol. For example, the LAN 110 may be a wired or wireless Ethernet communication system. However, other communication media and protocols can also be used if suitable. Additionally, although a single LAN 110 is illustrated, overlapping communication paths between workstation 106 and each similar workstation (not shown) may be provided using multiple LANs and suitable communication hardware within workstation 106. may be provided.

The example workstation 106 and/or other workstations that access the process control system 104 may be configured to visually review, change, or modify one or more processes within the process control system 104. good. The exemplary workstation 106 allows a user to view and/or manipulate one or more user display screens and/or applications that allow the user to change variables of a role-based process control system. visually confirm the status of the role-based process control system; visually confirm the status of the role-based process control system; visually confirm the alarms of the role-based process control system; and/or Allows you to change process control system settings (e.g., set points, operating conditions, clear alarms, silent alarms, etc.). An example method of implementing example workstation 106 is described below with reference to FIG. An exemplary user display application for use in implementing exemplary workstation 106 is described below with reference to FIGS. 3-7.

The exemplary workstation 106 includes and/or implements a role-based processor 102 that monitors process control routines and/or process control information transmitted by the controller 108 to identify and/or determine status issues. . The process control information may be generated at a process control device, including, for example, field device 112, controller 108, components, etc., in process control system 104. Alternatively, process control information and/or status information may be generated by the application. Applications may utilize process control information from field device 112 and/or controller 108 to calculate and/or determine status information and/or other process control information. For example, the Delta V software suite sold by Emerson Process Management includes applications that collect adjustments, status conditions, diagnostics, and/or performance parameters or metrics by field devices 112. Using the collected parameters, the application may display system-wide status information, or more granular specialized role-based visualization information, through a user interface.
Examples of role-based processor functionality

In some embodiments, the role-based processor 102 dynamically customizes the information presented to the user through a role-based presentation interface (e.g., the example role-based presentation interface of FIGS. 3-7) to match the user's role. Display information to the user based on the assigned criteria. Thereby, the role-based presentation interface can display qualifying information to the user while excluding (eg, not displaying) information that cannot be qualified by the criteria assigned to the user's role. In some embodiments, the predetermined criteria may be expressed as a threshold value. In some embodiments, role-based processor 102 may gradually disclose information to users. That is, the role-based processor 102 may not initially disclose information to the user, but may later allow the user to access some of the information. For example, a user may select visual confirmation of alarm information that did not initially meet a priority threshold and was therefore initially filtered out by role-based processor 102. In such embodiments, the user may expand hidden portions of the (alarm) information on the user interface to obtain additional information regarding the alarm. In some embodiments, the role-based processor 102 displays the certification information in an item form (tab form) such that one or more items are expanded by default and one or more items are collapsed by default. It's okay. For example, depending on a user's organizational role and/or responsibilities, role-based processor 102 may initially restrict which items a user can expand or visually review. In such embodiments, role-based processor 102 determines what information (e.g., collapsed) is appropriate to add based on the assignment criteria for the user's role before presenting the next information. You can make a second decision. In this manner, the role-based processor 102 gradually discloses information to the user, e.g., by filtering initial (default) partial information about a given task, or when the user requests such information. and enable users to determine which credentials are important to accomplishing a given task.

In some embodiments, role-based processor 102 compares the user's role against a list of credentials stored in a data structure, such as a lookup table, to determine what information is credentials. In such embodiments, information is determined to be authorized if it matches the authorized information listed in the lookup table. For example, the role-based processor 102 may display physical and graphical facets of process control system objects (e.g., nodes or entities) to a maintenance technician based on a list of qualification information stored in a lookup table. logical facets may be excluded.

In some embodiments, role-based processor 102 may employ user-controlled filters. In such embodiments, the user-controlled filter may take precedence over visual forms of certification information and preferences. For example, a user may prefer information displayed in a table rather than a pie chart, or may prefer to visually see objects or facets that are not normally relevant to the user's role. In such cases, for example, certification information based on the user's organizational role or responsibilities may be further filtered with the user's personal preferences (eg, user-controlled filters).

The role-based processor 102 may also organize functions and data from one or more information sources into role-specific layers, such as a maintenance layer, an operator layer, and a control system engineering layer to facilitate filtering of information. It is. Each layer can support data collection from one or more sources. For example, role-based processor 102 may create a maintenance layer that includes diagnostic parameters reported by field devices, maintenance history retrieved from a maintenance database, opinions regarding field devices submitted by technicians, and the like, as examples. The role-based processor 102 displays information on the maintenance layer if the user's organizational role is, for example, a maintenance manager, and does not display information on the maintenance layer if the user's role is a control system engineer. I can do it. The manner in which role-based processor 102 is implemented allows a user to enable and disable role-specific layers with a few commands, sometimes as little as one command. Additionally, depending on the implementation, a role-specific layer may specify the layout of information associated with the layer.

Further, role-based processor 102 can facilitate navigation between information screens based on a user's organizational role. For example, if the role-based processor 102 displays equipment status information to both an instrumentation engineer and a configuration engineer, the role-based processor 102 provides controls for the instrumentation engineer to navigate directly to the equipment tracking screen, but Not provided to configuration engineers. The control may be, for example, a button on a toolbar, a choice in a pull-down menu, an icon displayed next to a device description, or other suitable interactive prompt indicating a direct link. In this manner, role-based processor 102 allows a user to “walk the path” of relationships between functions and/or entities, and how information in process control environment 100 is logically linked. You can better understand what is going on.

Still further, the role-based processor 102 may form links to various information within hierarchical menus and "pivots" or highlight subset links within the menu depending on the user's organizational role. and can form a particular point of view. Exemplary menus may include a selectable asset list, an I/O point list, a logical entity list, a visualization list, and the like. Depending on the user's organizational role, role-based processor 102 may create menus, for example, in an asset-centric view or a logic-centric view.

More generally, role processor 102 can provide role-dependent views to anyone responsible for configuring, operating, managing, etc. a process control environment. These roles include managing process parameters such as flow rates, levels, temperatures, and pressures, monitoring events related to the process control loop, and generally ensuring the accuracy of the control logic implemented within the process plant. There may be an operator role responsible for the There may also be a separate role for maintenance technicians who are responsible for the monitoring and calibration of individual field devices and the general management of equipment used within the process control plant. There is also a separate role for the network administrator, who is responsible for network connectivity between workstations, control equipment, data servers, databases, and other network devices, securing the plant network, and installing the latest software versions. There may be. As a more specific example, the operator interface of role-based processor 102 allows an operator to supervise the operation of a process plant in which a plurality of field devices perform process control functions that define a control strategy. Rather than providing a general operator view at an operator workstation, role-based processor 102 may create views with information specific to the operator's role. To do so, role-based processor 102 may require the operator to log in or identify a role. In addition to providing control and information to the role-specific layer to the operator, the role-based processor 102 may persist (ie, maintain between login sessions) user-specific configurations.

Role-dependent operator views may graphically depict the process plant (a "process diagram") and display additional information about selected portions of the process plant depending on the operator's role. Process diagrams include, for example, the field devices (e.g. valves, pumps, sensors, transmitters) associated with the corresponding process control function, the equipment on which these field devices operate (e.g. tanks, mixers), the field devices and equipment (e.g. Diagrams or schematic representations of connections (e.g., pipes) that conduct process fluids between (e.g., pipes) and electrical connections (e.g., wiring, wireless links) between field devices may be included. The role-based processor 102 may provide additional information by providing supplementary text and/or graphical displays, such as in one or more separate windows, a graphical layer overlaid on the process diagram, or a banner placed at the bottom, top, or side of the process diagram. May be displayed.

Briefly, an operator may select a location on a process diagram, actuate a control, such as a button, on a user interface, and request additional display from the user interface. Further, the role-based processor 102 may automatically perform supplementary display according to a predetermined schedule or based on another event in response to detection of an abnormal condition. Role-based processor 102 may interpret the location selected by the user according to the user's organizational role. Clicking on or near a diagram depicting a flow sensor will cause an operator to select the control loop in which the flow sensor operates, or a maintenance technician to select the physical device (i.e., the flow sensor). Dew.

For the operator, the supplemental display (or "supplemental operator display") may include, for example, a configuration display representing the control logic implemented by a given portion of the process plant as interconnected logic blocks. The logic block may be a Foundation ^TM fieldbus functional block. Supplemental operator displays may include parameter history displays representing the history of certain process parameters (eg, input flow rates to certain process steps). Additionally, supplemental operator displays may include knowledge-based displays that list links to internal and external materials available on a portion of the process plant, provide access to an operator logbook, list help topics, and the like. Still further, the supplementary operator display may include a device-dependent display that lists identifiers of field devices used in the portion of the process plant to which the process diagram corresponds. Device-dependent displays may retrieve device-specific diagrams from the configuration database and display them next to each identifier of a field device. Supplementary operator displays may additionally indicate, if necessary, the devices used in the part of the process plant to which the process diagram corresponds, the coupling devices associated with these devices and the corresponding coupling status, some alarms for the process plant, A detailed display presenting detailed information related to adjustment parameters, etc. may also be included.

As another example, if the user is a maintenance technician or is affiliated with a maintenance worker, the supplemental display (or "maintenance supplemental display") may be used to determine the control strategy (e.g., control loop ) may include a control-dependent indication for the selected device. The supplementary maintenance display may include knowledge-based displays that are substantially the same as the knowledge-based displays created for the operator. In particular, the knowledge-based display may list links to internal and external materials available on the device, as well as links to operator logbooks, help topics, etc. In addition, supplemental maintenance displays provide diagnostic displays that assist maintenance technicians in locating physical devices within a process plant, identifying alarm sources, and determining relationships between devices and other equipment. You may prepare. The diagnostic display may, for example, display the fieldbus segment together with the devices connected to it, highlight the corresponding diagram, display an exclamation mark or other visual indicator next to the device, or any other suitable method. The device that generated the alarm may be identified by any suitable method. Still further, the maintenance supplemental display may include a device description display that includes Extended Device Description Language (EDDL) compliant device identification, device configuration and setup data, and device diagnostic data, depending on the implementation. Optionally, the device descriptive display may include a so-called device faceplate, a photo or diagram of the actual physical appearance of the device together with dials and gauges, if necessary, as well as a photo or diagram similar to the device, and device-specific process data (e.g. , pressure setpoint, pressure measurement, valve movement rate). If the device is a high-performance valve that runs in conjunction with valve software (e.g., the AMS ValveLink application provided by Emerson Process Management ^TM as part of the PlantWeb® suite), maintenance supplemental displays may be It may additionally include a valve software display that is updated with the output data.

Role-based processor 102 may have the ability to create supplemental views and may also have the ability to create primary views. The primary display may include, for example, a process display defined by a configuration engineer, and the role-based processor 102 may provide additional information through supplemental displays in response to detecting events within the process plant or receiving commands from a user interface. Can be automatically selected and displayed. To create the primary and/or secondary representations, the role-based processor 102 uses (1) real-time process data from the process control system 104 and (2) control logic from a configuration database (simply not shown). (3) application data from one or more specialized applications; (4) process or device parameters from history; Historical data of executions within one or more databases (not shown), (5) reference information from knowledge-based databases (not shown), etc. can be obtained.

In some cases, role-based processor 102 uses a display structure that defines multiple layers, such as an operator layer, a maintenance layer, a network layer, and so on. Role-based processor 102 uses real-time process data to update information related to each tier, regardless of the user's organizational role, but currently relevant/selected views (e.g., for operators, for maintenance) Depending on the situation, only one or more selected layers may be displayed.

The supplemental display may be in a user-configurable display format such that each user can specify what information is included in the corresponding supplemental display. In some embodiments, role-based processor 102 automatically switches operator supplementary displays to maintenance supplemental displays, or vice versa, in response to commands received from a user interface.
Although the embodiments disclosed herein relate to filtering process control information based on user role and object, other filtering methods are possible. For example, role-based processor 102 may filter information based on permissions or security tolerance contrasts, tags or metadata associated with process control facet information, or context of objects within the control system.
Example of a workstation providing role-based views

FIG. 2 illustrates an exemplary method of implementing workstation 106 of FIG. Workstation 106 of FIG. 2 includes at least one programmable processor 200. Workstation 106 of FIG. The example processor 200 of FIG. 2 executes coded instructions residing within main memory 202 of processor 200 (eg, within random access memory (RAM) and/or read only memory (ROM)). Processor 200 may be any processing device such as a processor core, a processor, and/or a microcontroller. Processor 200 may execute an operating system 204, role-based processor 102, workstation applications 208, and role-based presentation interface 210, among other things. Exemplary operating system 204 is the Microsoft® operating system. The example main memory 202 of FIG. 2 may be implemented by and/or within the processor 200 and/or one or more memories and/or memory devices operably connected to the processor 200. It may be. Although the embodiments disclosed herein are described in connection with a processor, the disclosed technology may be used in conjunction with a rules engine, distributed processing system, or the like.

To enable a user to exchange information with the example processor 200, the example workstation 106 of FIG. 2 includes an input device 214 and an output device 216. User input may be communicated to processor 200 by one or more input devices 214, such as a keyboard, stylus, voice recognition system, mouse, and/or touch screen. Output from processor 200 is provided by one or more output devices 216, such as, for example, a display device capable of displaying a user interface and/or application implemented by processor 200 and/or more generally by example workstation 106. , may be communicated to the user. Exemplary output devices 216 include, but are not limited to, a computer monitor, a computer screen, a television, a mobile device (eg, a smartphone, a Blackberry ^™ , an iPad ^™ , and/or an iPhone ^™ ), and the like.

The example operating system 204 of FIG. 2 executes and/or facilitates the display of the role-based presentation interface 210 by and/or at the example output device 216. To facilitate the exchange of information between people and applications implemented by the example workstation 106, the example operating system 204 implements an application programming interface (API). Thereby, the example role-based processor 102 can define and/or select a role-based presentation interface 210 via the workstation application 208 and cause the operating system 204 to display the defined and/or selected role-based presentation interface 210. , and/or can be commanded to be displayed. An exemplary role-based presentation interface 210 is described below with reference to FIGS. 3-7.

For presenting process control system displays and/or applications, the example workstation 106 of FIG. 2 includes an example role-based processor 102. The example role-based processor 102 of FIG. 2 filters facets (e.g., tasks, information, etc.) based on predetermined criteria, dynamically creates a role-based presentation interface 210 via a workstation application 208, and / or define. For example, depending on the person accessing workstation 106 (e.g., the user's organizational role or responsibilities), certain tasks or information may be displayed through role-based presentation interface 210 and other information facets may be hidden (e.g., non-users). display). In other embodiments, role-based processor 102 organizes what is displayed to the user through a default desktop arrangement and display layout (FIG. 5). For example, depending on the number of monitors connected to workstation 106 and the person accessing workstation 106, role-based processor 102 may automatically display different information on one or more monitors by default. In such embodiments, a user may modify or override role-based defaults according to his or her preferences for desktop placement and display layout.

In some embodiments, the information facets filtered by role-based processor 102 include a task and one or more subtasks for the user to perform. For example, the task may include a diagnosis of the cause of a display element (for example, main task) not being able to be updated. The execution of the main task may include determining which components are associated with display elements (e.g., the first subtask), verifying the integrity of the input/output connections of that component (e.g., the second subtask), etc. good.

In the illustrated embodiment, the information is filtered based on criteria related to the user's role. A role may be defined with one or more tasks or responsibilities that a person typically performs. An example role is control room operator. Responsibilities and/or tasks associated with such operators may include detecting problems (e.g. status problems) that may affect safety, environment or equipment in and near the plant, plant equipment performance and safety. start/stop production equipment on schedule, monitor and control processes to ensure optimal performance, and/or monitor significant trends and take corrective action to identify potential process problems. may be included. Another example role is Control Systems Engineer. The control system engineer has associated responsibilities and/or tasks that include production support from a control system perspective (e.g., ensuring processes are running correctly) and/or control of system configuration, designing the configuration, implementing and testing, determining if problems are related to the control system, resolving production problems, determining alarm notifications (eg, conditional alarms, limits, etc.), and/or maintaining control strategies. Responsibilities, goals, and/or tasks may be assigned to roles in advance and later modified (eg, added, deleted, adjusted, etc.), eg, by a user manager, eg, in a user manager software application.

For example, role-based processor 102 may specify a number of roles with each role having a set of responsibilities, goals, and/or tasks that are pre-assigned. For example, example role-based processors 102 include batch operator, control room operator lead, production manager, reliability manager, control system engineer, process engineer, instrumentation engineer, instrumentation technician, reliability maintenance technician, and technical support. Engineers, equipment maintenance technicians, control system managers, control room operators, etc. may be pre-assigned different responsibilities, goals and tasks. Although the plant has people who perform the responsibilities, goals, and/or tasks associated with each role, the plant may not be staffed so that each person can have different roles. That is, in a given plant, a person may be preassigned multiple roles to perform their responsibilities, goals, and/or tasks. Also, the same role may have different responsibilities, goals and/or tasks in different plants. To this end, a user manager software application may be used to customize the assignment of responsibilities, goals, and/or tasks for each role or person. For example, if one person in a plant has the role of fabrication manager, that person may perform the tasks of fabrication manager, process engineer, and instrumentation engineer. In such cases, the user manager may customize the responsibilities, goals, and/or tasks assigned to that person to include preassigned tasks for production managers, process engineers, and instrumentation engineers. As a result, the person does not have to perform role change work in the system because the information displayed is different from the information desired by the person. Conversely, all of the information available to production managers, process engineers, and instrumentation engineers is already available to the user without the user having to go through the trouble of filtering (eg, mouse clicks).

In some embodiments, role-based processor 102 provides security by making tasks permission-based. Users are granted permissions and tasks have various permission levels attached to them. Permission levels may be specified for each task, module, module parameter, parameter field, instrumentation asset, digital control system hardware, and/or plant equipment. In some embodiments, the main task's permission level does not take precedence over the subtask's permission level.

In some embodiments, spans of control may be assigned to each person. The span covers all tasks that the user can perform. A span of control may be geographically allocated or location-based (eg, an entire site, a plant area, a room in a plant, a unit in a process). In some embodiments, spans of control may be allocated on an object basis (e.g., limited by a given object or information facets about the object). For example, the span of control for a user may be limited to the user's calibration of control and instrumentation assets. In another example, the control span may be location-based or a combination of geography-based and object-based (eg, allowing a user to calibrate control instrumentation assets located near a nuclear reactor in a plant). In some embodiments, the span of control may be application-based (eg, allowing a user to configure aspects of the software application that perform safety functions). In another embodiment, the administrative span may span workstations. For example, certain workstations in a process control environment (eg, process control environment 100 of FIG. 1) may function only in certain modes of operation. In some embodiments, the span of management may be a span of management that is common to the user and the workstation. For example, even a user who is in charge of the entire site management span may be limited to operations related to the nuclear reactor area due to the workstation that the user accesses. In some embodiments, the span of control may be context-based. For example, the span of control may limit the object information displayed to the user after confirming whether the object information is privileged or proprietary information.

An example method for implementing the example workstation 106 of FIG. 1 is illustrated in FIG. and/or may be performed in other ways. Further, an example processor 200, an example main memory 202, an example operating system 204, an example role-based processor 102, an example workstation application 208, an example role-based presentation interface 210, and/or , and more generally, the example workstation 106 of FIG. 2 may be implemented in hardware, software, firmware, and/or a combination of hardware, software, and/or firmware. Still further, the example workstation 106 may include additional components, processes and/or devices instead of or in addition to those illustrated in FIG. A plurality of structures, components, processes, and/or devices may be provided.
Example of presentation interface

FIG. 3 illustrates an example role-based presentation interface 300 that may be used to implement displays and/or applications and/or more generally the example workstation 106 of FIGS. 1 and 2. The example role-based presentation interface 300 may be displayed as a stand-alone interface or in combination with one or more other components or interfaces of the role-based interface (not shown). In the example illustrated in FIG. 3, role-based presentation interface 300 displays a role-based interface for a control system engineer running a software application that performs diagnostic functions. Role-based display interface 300 includes a navigation frame 302, a content frame 304, and a task frame 306. Navigation frame 302 includes an exemplary hierarchical tree 308 that navigates between nodes connected to a physical network. Content frame 304 includes an example node descriptor 310 that displays additional information about the selected node in hierarchical tree 308, for example. The current status of the selected node may be graphically indicated by an icon, such as the exemplary status icon 312 located at the far right of the content frame 304, for example. Content frame 304 also includes an exemplary diagnostic parameter list 314 that includes a diagnostic parameter list for the selected node along with an explanation column 316 and a value column 318. The explanation column 316 and value column 318 contain pertinent information corresponding to each diagnostic parameter listed in the diagnostic parameter list 314. Task frame 306 includes a diagnostic task list 320 that includes a diagnostic task list for a selected node that is accessible to the user, along with subtasks 322 that provide additional choices and/or information to the user.

In some embodiments, the diagnostic tasks displayed in task list 320 vary by person (eg, the user's organizational role and/or responsibilities). For example, the Verbose Log and Application Log tasks listed in task list 320 are associated with a software application to be debugged (e.g., an exemplary software application that performs diagnostic functions), and role-based processor 102 is a control systems engineer. When creating the role-based presentation interface 300 for the application, the Verbose Log task and/or the Application Log task may be excluded.

FIG. 4 depicts another example role-based presentation interface 400. Role-based presentation interface 400 shows an example navigation frame 402 and an example content frame 404 in a collapsed state. In the illustrated example, a user searches using, for example, an exemplary search bar 412 and the search results are listed in an exemplary results list 406 that includes exemplary result listings 408 and 410. . As shown in FIG. 4, the results section 408 includes an example status display 418, an example node descriptor 414, and an example task button 416. On the other hand, the results description section 410 includes an exemplary status display 420 and a node descriptor 422. In the illustrated embodiment, the colors of status indicators 418 and 420 represent the status of the nodes in the results section. For example, a red status display may indicate that the corresponding node has a problem, and a green status display may indicate that the corresponding node is functioning normally. Other methods may be used to represent node state. Node descriptors 414, 422 present information about the node, such as node name, node location, and/or problem description. Additionally, task buttons 416 allow the user to obtain additional information regarding the corresponding node. For example, a user may be able to solve a problem via task button 416.

In some embodiments, the information displayed in role-based presentation interface 400 is different for each person (eg, the user's organizational role and/or responsibilities). For example, role-based processor 102 of FIGS. 1 and 2 may exclude task buttons (eg, selectable interface objects) for certain people. In some embodiments, selecting a task button (eg, exemplary task button 416) may gradually reveal additional information. For example, the task button 416 may not be shown, and an instruction to repair the problem may be displayed in the result entry section 408 for a predetermined person. By selecting task button 416, the user may obtain information for remediating problems previously excluded from role-based presentation interface 400. In another embodiment, the result entries in results list 406 may include nodes with problems (eg, result entry 408) and exclude nodes with no known problems (eg, result entry 410). Other combinations of displaying and excluding information on role-based presentation interface 400 are also possible.

In some embodiments, the desktop placement and/or display layout may be determined by role-based processor 102 based on the user's organizational role and/or responsibilities. For example, if you specify that workstation 106 be configured with four monitors, role-based processor 102 automatically creates a role-based presentation interface 210 that is different for each monitor based on the four common software applications used by the user's role. and/or may be defined.

FIG. 5 is another example role-based presentation interface 500. Role-based presentation interface 500 is a four-monitor display desktop arrangement with multiple applications running together through multiple monitors on the same workstation. In the illustrated example, each exemplary monitor 502, 504, 506, 508 displays a graphical user interface corresponding to a different software application. For example, monitor 502 displays an example role-based presentation interface 510 for a software application that performs diagnostic functions and displays system-wide diagnostics for that process. Monitor 504 displays an exemplary role-based presentation interface 512 for software applications that perform control logic functions, displaying selected functional blocks including inputs and outputs. The monitor 506 displays an exemplary role-based presentation interface 514 for a software application that performs interfacing of the physical components of a process, and displays a connectivity map of the physical components of the process. Monitor 508 displays an exemplary role-based presentation interface 516 for a software application that performs node management functions and displays detailed information for the selected node.

In some embodiments, role-based presentation interface 500 includes other combinations and/or arrangements of monitors. For example, two, three, or more monitor displays may be arranged. In some embodiments, the role-based presentation interface 510, 512, 514, 516 for each monitor 502, 504, 506, 508 is responsive to any changes or selections made to the information displayed in another role-based presentation interface. Refresh or reload. For example, if a user selects a valve control module on role-based presentation interface 510, role-based presentation interface 512 displays a functional block that includes input/output point criteria for the valve control module, and role-based presentation interface 514 displays: Highlighting the valve and displaying the primary control display for the valve control module, the role-based presentation interface 516 displays detailed information about the valve. In some embodiments, one or more role-based presentation interfaces may determine whether to reload or update based on changes or selections, if any, on another role-based presentation interface on a per-user role and/or user basis. It may be set by

FIG. 6 is another example role-based presentation interface 600. Role-based presentation interface 600 includes an example navigation frame 602 and an example content frame 604. In the illustrated example, navigation frame 602 displays a portion of a connectivity map of process control system 104. A connectivity map is a topology map that represents the interface connections between input/output subsystems of physical components. On the other hand, a configuration map is a topology map that represents connections between physical components of a process as configured. For example, a configuration map displays connections based on how the user wants physical components to be connected, whereas a connectivity map displays interface connections as they are actually connected.

FIG. 7 is another example role-based presentation interface 700 showing relevant key performance metrics and system capacity. Role-based presentation interface 700 includes an example resource tab 702 and a corresponding example graph 704. In the illustrated example, resource tab 702 is in a collapsed state. In contrast, the example resource tab 706 (eg, the "Learn More" tab) of the role-based presentation interface 700 is in an expanded state.

The example role-based presentation interface 700 also includes an example resource tab 708 that is also collapsed. Resource tab 708 provides information regarding the system capacity of the selected object (eg, control device). The resource tab 708, when expanded, displays information to the user about the system hardware/configuration that violates the document-based system fence. System fences limit the number of resources that can be attributed to an object. For example, the system fence for a control device allocates the maximum number of modules that can configure the control device. In such embodiments, system capacity information for a controller may be displayed in terms of the number of modules that the controller is currently configured with. In some embodiments, the resource tab 708 may display a data graph (eg, a bar graph) to provide a visual representation of capacity utilization. In some embodiments, system capacity information may be displayed color-coded by capacity level. For example, if the number of modules is less than 75% of the system fence (for example, the maximum number of modules that can be configured into an object), it is displayed in green. Further, if the number of modules exceeds 90% of the system fence, it may be displayed in orange.

Further, the system capacity information displayed in role-based presentation interface 700 may be different for each user. For example, the role-based processor 102 of FIGS. 1 and 2 may exclude system capacity information for objects that are, for example, less than 75 percent of the default capacity.
Exemplary process and platform for creating role-based views

FIG. 8 is an exemplary flowchart of an example process implementing the example workstation 106 of FIGS. 1 and/or 2. The example process of FIG. 8 may be performed on one or more processors, one or more controllers, and/or one or more other suitable processing devices. For example, the process of FIG. 8 may include flash memory (e.g., a "thumb drive"), ROM, and/or random access memory RAM, etc. associated with a processor (e.g., example processor 902, discussed below with reference to FIG. 9). may be embodied in coded instructions (eg, computer-readable instructions) stored on a non-transitory machine/computer-accessible or readable medium. As used herein, the term non-transitory computer-readable medium is defined as a medium that includes any non-transitory computer-readable storage device (and that carries a propagated signal). or other storage media on which information may be stored for any amount of time (eg, for extended periods of time, permanently, for short periods of time, temporary storage, and/or caching of information).

Alternatively, some or all of the example operations of FIG. It may be implemented in combination. Also, one or more of the operations illustrated in FIG. 8 may be performed manually or with any combination of the aforementioned techniques, such as, for example, firmware, software, discrete logic, and/or hardware. Additionally, although the exemplary process of FIG. 8 is described with reference to the flowchart of FIG. 8, those skilled in the art will readily appreciate that there are many alternative ways to implement the exemplary process of FIG. It will be possible. For example, the order of execution of the blocks may be changed, and/or some of the described blocks may be changed, deleted, separated, or combined. Additionally, some or all of the example operations of FIG. 8 may be performed sequentially and/or in parallel, eg, on separate processing threads, processors, devices, separate logic, circuits, etc.

The process of FIG. 8 begins at block 800 at a workstation (e.g., example workstation 106 of FIG. 2) running a role-based processor (e.g., example role-based processor 102 of FIG. 2), and begins at block 802. A role-based presentation interface (eg, example role-based presentation interface 210 of FIG. 2) is displayed at . At block 804, role-based processor 102 receives process control information and/or status information.

At block 806, role-based processor 102 receives user criteria to determine whether to display or exclude information. For example, user criteria may be based on the user's organizational role or responsibilities. In another example, the user criteria may correspond to a given object type, information facets about the object, and/or relationships between objects. For example, a node's assets or node descriptor information may be displayed in the role-based presentation interface, and logic information about the node may be excluded by the role-based processor 102. In some embodiments, when a user accesses workstation 106, the user logs into an account and begins a session that is related to the user's role (e.g., as defined by a user manager software application). ). In such embodiments, role-based processor 102 receives default user criteria based on the logged-in user's organizational role and/or responsibilities.

At block 808, role-based processor 102 determines whether the information meets user criteria. For example, role-based processor 102 utilizes the user's role and matches that information against a list of credentials associated with the user's role. In some embodiments, the qualification information list is stored in a data structure (eg, a lookup table) in memory (eg, the example main memory 202 of FIG. 2). If the information is not suitable, control proceeds to block 810 where the information is filtered out by the role-based processor 102. Further, role-based processor 102 creates and/or updates role-based presentation interface 210 based on the determination at block 808. Control processing then returns to block 802 and displays the updated role-based presentation interface 210.

Alternatively, if the role-based processor 102 determines at block 808 that the information is suitable, control proceeds to block 812 where the role-based processor 102 sets user preferences above the certification information. For example, a user may prefer certain visualizations (eg, displaying information in a table rather than a pie chart). In some embodiments, user preferences may take precedence over certification information display. For example, a production manager who prefers indirect asset (eg, valve) monitoring may set user preferences to hide valve information by default. In such embodiments, user preferences for hiding (or not displaying) certain information take precedence over displaying certification information regarding the valve. At block 814, role-based processor 102 displays information. Additionally, role-based processor 102 creates and/or updates role-based presentation interface 210 based on the determinations at blocks 808 and 812. Control then returns to block 802 to display the updated role-based presentation interface 210.

FIG. 9 illustrates an exemplary process used and/or programmed to perform the exemplary process of FIG. 8 and/or more generally to execute the exemplary workstation 106 of FIGS. 1 and 2. 9 is a schematic diagram of a processor platform 900. FIG. For example, processor platform 900 can be implemented with one or more general purpose processors, processor cores, microcontrollers, and the like.

The example processor platform 900 of FIG. 9 includes at least one general purpose programmable processor 902. The processor platform 900 of FIG. Processor 902 executes coded instructions 904 and/or 908 that reside within main memory (eg, RAM 906 and/or ROM 910) of processor 902. Processor 902 may be any processing device such as a processor core, a processor, and/or a microcontroller. Processor 902 may, among other things, execute the example process of FIG. 8 and implement the example operator station 104 described below. Processor 902 communicates with main memory (comprising ROM 910 and/or RAM 906) via bus 912. RAM 906 may be implemented with DRAM, SDRAM, and/or any other RAM device, and ROM 910 may be implemented with flash memory and/or any other desired memory device. Access to memories 906 and 910 may be controlled by a memory controller (not shown).

Processor platform 900 also includes interface circuitry 914. Interface circuit 914 may be implemented with any interface standard, such as a USB interface, Bluetooth interface, external memory interface, serial port, general purpose input/output, etc. One or more input devices 916 and one or more output devices 918 are connected to interface circuit 914. Input device 916 and/or output device 918 are used, for example, to provide role-based presentation interface 210 to exemplary output device 216 of FIG.
Example of pivoting menu according to role-based perspective

FIG. 10 is an illustration of an example hierarchical menu 1000 in which the role-based processor 102 or another suitable software component provides an asset-centric view of a predetermined distillation scope (e.g., part of a process control system 104). is created. Specifically, role-based processor 102 creates an interactive display of a combinatorial hierarchy that includes assets such as process equipment, I/O points, logic, visualization resources, and the like. The interactive display may be "pivoted" to show the perspective of, for example, a maintenance technician or another user who is particularly interested in the assets available in the process control system 104. As can be seen by comparing the menu 1000 with the menu 1100 shown in FIG. 11, the menu 1000 presents the distillation range from a different perspective.

In general, pivoting a menu around a given selection category for an item or resource organizes the items around the selection category, selects a specific level of detail for which the menu is branched into one or more ways, and separates the different items in the menu. Visual emphasis may be given to different items with different colors or differently styled parameters. Role-based processor 102 can use categorical items in multiple views. For example, role-based processor 102 may use plant areas, units, and process cells in both asset-centric and logic-centric presentation menus.

In menu 1000, items 1002-1014 correspond to assets, items 1020-1024 correspond to logic items, items 1040-1048 correspond to I/O points, item 1060 corresponds to graphical resources, and item 1080 corresponds to key performance evaluations. Corresponds to index (KPI). When menu 1000 is pivoted by assets, items 1002-1014 become the main components of menu 1000, and the remaining items are represented as subcomponents or associated with each asset.

Although a role defaults to a primary perspective, such as the asset-centric perspective of FIG. 10, in some embodiments a user can independently change the perspective for each case of associated applications/views provided by the role-based processor 102. . For example, a maintenance technician may change the default (asset-centric) perspective of the selection screen to, for example, a logic-centric view. To this end, role-based processor 102 may include any controls such as buttons, pull-down menus, etc.

FIG. 11 is a schematic diagram of an exemplary hierarchical menu 1110 that role-based processor 102 displays from a logic-centric perspective with the same scope of distillation as the asset-centric perspective in menu 1100. It was created for the purpose of In menu 1100, items 1102 and 1104 correspond to assets, items 1120-1128 correspond to logic items, items 1140-1148 correspond to I/O points, and item 1160 corresponds to resource diagrams. Unlike the menu 1000, the menu 1110 has fewer assets and more logic items, and shows a hierarchy with more logic item names than other items.

Interactive menus can be organized primarily by assets (Figure 10), logic items (Figure 11), or other items, with the same settings as items related to the various facets of a process control system as described above. .
Further diagram representing role-based filtering

As an additional illustration of role-based filtering, diagram 1200 of FIG. 12 depicts a mapping of cluster information associated with a process control system to multiple organizational roles. Specifically, the information that role-based processor 102 may present to the user includes, for example, visualizations, business data, logic, health data, knowledge, and I/O devices. For each type of information, role-based processor 102 may indicate capabilities, resources, various entities, and so on.

Role-based processor 102 may select a predetermined data type from each of these categories as the data most relevant to a predetermined role. For example, the role-based processor 102 may select, at least as a default option, which process displays to display to the control system engineer (in at least some embodiments, additional process displays may be requested and viewed by users in other roles). ). The role-based processor 102 can select a dashboard for each of a control system engineer, an electrical instrumentation engineer, and a production manager. As also shown in FIG. 12, role-based processor 102 allows only control system engineers to select a machine view for default display.

Additionally, role-based processor 102 can assist users in "walking the path" of relationships between data types. Referring to FIG. 13, a user can specify a context such as a predetermined heat exchanger by first selecting a heat exchanger visualization process display. The role-based processor 102 can automatically suggest transitions to control modules, device lists, device alerts, etc., as shown in the schematic diagram of FIG. Specifically, the role-based processor 102 provides interactive controls that link directly to the visualization process display on display screens such as control modules, device lists, device alerts, etc., so that a user viewing the heat exchanger visualization process display can: It is possible to immediately see which data is relevant to the current context of the heat exchanger. That is, for example, the user is presented with a short list of items in the current context automatically created by the role-based processor 102 without having to explicitly select a device alert from among the equipment status, device alert, and vibration data items in the health category. can. Additionally, even if the user does not specify that a device alert is potentially relevant to the current context (heat exchanger), the role-based processor 102 can direct the user to potentially relevant information.

Generally, role-based processor 102 provides a user's organizational role-specific path navigation for moving between information screens and/or controls. In this manner, the role-based processor 102 can help the user understand the "big picture" and related information available in the system.

Although certain exemplary methods, apparatus, and articles of manufacture have been described herein, the scope of the invention is not limited thereto. Such examples are intended to be non-limiting examples. The present invention is also directed to all methods, apparatus, and articles of manufacture fairly falling within the scope of the appended claims either literally or under the doctrine of equivalents.

Claims (11)

a display device for displaying a user interface for accessing information in a process control system;
A system comprising one or more processors,
The one or more processors are:
establishing a login session for the user;
determining the user's organizational role, including a combination of responsibilities and privileges within an organization associated with the process control system;
The user login session receives object information of an object related to the process control system, and object information specifying a context regarding process equipment for presenting further object information related to the process control system. ,
determining whether the object information is authorization information based on the organizational role of the user;
When the object information is certification information, the object information is displayed through the user interface via a first screen; however, when the object information is not certification information, the object information is not displayed through the user interface. ,
Based on the organizational role and relevance to the context, a navigation path is selected to sequentially navigate through the first screen, the second screen, and at least one other screen each displaying pieces of cluster information. , the cluster information includes visualization, business data, logic, health, knowledge, and I/O device information related to the process control system ;
a link that navigates directly from the first screen to the second screen so that the user viewing the first screen can see what data is relevant to the context; Via a first screen, the context is specified by selecting one of the cluster information, and the link is provided to a user with an organizational role other than the determined organizational role. not provided,
Shifting to the second screen depending on the user activating the link ;
A system configured to perform . The one or more processors are:
creating multiple role-specific layers, each layer containing different information gathered from multiple sources;
2. The method of claim 1, further comprising: selecting one of the plurality of role-specific layers based on the organizational role of the user, the selected role-specific layer including the object information. system described in. 5. The organizational role is selected from a list including: (1) production manager, (2) maintenance manager, (3) control system engineer, (4) electrical instrumentation engineer, and (5) control room operator. 3. The system according to claim 1 or claim 2. The one or more processors determine whether the object information is authorization information,
According to any one of claims 1 to 3, the method is configured to perform the step of determining certification information of each of a plurality of organizational roles by comparing the organizational role to a list including each of the organizational roles. system. 5. The system of any one of claims 1 to 4, wherein the one or more processors are configured to perform the step of excluding the object information if the object information is not certification information. 6. The system of any preceding claim, wherein the one or more processors are configured to organize the certification information based on the organizational role of the user. The system according to any one of claims 1 to 6, wherein the object information corresponds to a part of the constituent capacity of the object. A system according to any one of claims 1 to 7, wherein the processor is configured to perform the step of displaying a portion of the configured volume in color. A system according to any preceding claim, wherein the processor is configured to perform the step of visually customizing the display of the object information. A method comprising steps performed by the one or more processors of any one of claims 1 to 9. 10. A non-transitory computer-readable medium for storing instructions, the instructions, when executed by one or more processors in a machine, causing the machine to perform the steps of any one of claims 1-9. A non-transitory computer-readable medium that stores instructions for executing.