Composition Engineering and Human Profiles and Fingerprint Authentication of Runtime Applications

Abstract

To provide a system which allows for validating a write command to a device in a process control system.SOLUTION: When a write command to a process control device is intercepted in a process control system, a two user validation process uses biometric inputs of two users to authenticate the two users and to query for associated profiles to determine whether the two users have a relationship required to release an intercepted write command to the device to validate the write command.SELECTED DRAWING: Figure 7

Description

Technical Field

[0001] The present disclosure generally relates to process control systems, and more particularly, to process control systems that verify write commands to devices of a process control system.

Background Art

[0002] A process control system used in an industrial process can include at least one host or operator workstation communicatively coupled to one or more process controllers via one or more input / output (I / O) interface devices. The process controller can communicate with one or more field devices via an analog, digital, or combination of analog / digital buses. For example, field devices such as valves, valve positioners, switches, and transmitters / sensors (e.g., temperature, pressure, and flow sensors) can perform functions such as opening and closing valves and measuring process parameters within a process plant. The process controller receives signals indicative of process measurements generated by the field device and / or other information regarding the field device, uses this information to implement control routines, and then generates control signals that are transmitted to the field device via the bus to control the operation of the process. As described herein, other plant devices such as field devices, controllers, and input / output interfaces are generally referred to as "process control devices" or "plant devices."

[0003] The security protocols of existing plant operator programs may impose restrictions on access to critical control devices or parameters of control devices. These protocols may require confirmation that the changes are intended and that they are entered correctly. In some systems, critical parameters or devices may be marked as protected, and additional security processing may be required. Generally, existing process control systems may use standard username and password credentials for authentication and verification. These types of authentication and verification protocols tend to be exploited by staff due to laxity or attacked by interference. For example, usernames are generally detected via network directories, and passwords can be guessed or hacked. Depending on the situation, even if the sharing of credentials violates the organization's rules, users may intentionally share their credentials among colleagues to quickly process change requests.

[0004] In some systems, a second user verification may be used for changes to certain critical parameters. Generally, in these systems, a second user from a different user group or role (e.g., with different permissions) may be required as the first user to initiate the parameter change before the change is permitted. This additional verification or confirmation step may enhance the security of some changes, but there may be vulnerabilities in how the additional verification step is implemented. For example, anyone with the password of a higher role (e.g., including many permissions) may be able to approve the change. These systems may still be vulnerable to lax operating practices, external hacking, or attacks, combined with the weaknesses of standard username and password credentials. SUMMARY OF THE INVENTION

[0005] The present disclosure describes a process control system including at least one controller and one field device in which a write command for a process control device is intercepted for a verification process. The verification process can include determining a relationship between a first user who initiates the write command and a second user who verifies the write command. The second user can be prompted to verify the write command of the first user by submitting a biometric input that can be authenticated based on the second user's user profile. If the second user is biometrically authenticated, the write command can be released for execution by the process control device.

[0006] In an embodiment, when a write command is intercepted, biometric inputs of the first and second users can be received. The user profiles of the first and second users can be queried based on the biometric inputs of the first and second users. If user profiles are found, the method and system can search for a relationship between the first user and the second user based on those profiles. If a relationship exists or is valid, the write command can be released.

Brief Description of the Drawings

[0007]

Figure 1

Figure 2

Figure 3

Figure 4A

Figure 4B

Figure 4C

Figure 5A

Figure 5B

Figure 5C

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Best Mode for Carrying Out the Invention

[0008] FIG. 1 shows a process control system 12 within a process plant 10. More specifically, the process control system 12 can represent a distributed process control system or DCS. The process plant 10 also includes one or more host workstations, computers, or user interfaces 16 (which can be any type of personal computer, workstation, etc.) that can be accessed by plant personnel such as process control operators, maintenance personnel, configuration engineers, etc. In the example shown in FIG. 1, the user interface 16 is shown as being connected to the process control nodes 18 and the configuration database 21 via a common communication line or bus 22. The communication network 22 can be implemented using any desired bus-based or non-bus-based hardware, using any desired hardwired or wireless communication structure, and using any desired or suitable communication protocol such as the Ethernet protocol.

[0009] Generally speaking, the nodes 18 of the process plant 10 include process control system devices integrally connected via a bus structure that can be provided on a backplane 76 to which different devices are connected. The nodes 18 (which can represent multiple nodes) are shown in FIG. 1 as including process controllers 24 (which can represent multiple controllers) as well as one or more process control system input / output (I / O) devices 28, 30, and 32. Each of the process control system I / O devices 28, 30, and 32 is communicatively connected to a set of process control-related field devices shown in FIG. 1 as field devices 40 and 42. The workstation 16, the process controllers 24, the I / O devices 28 - 32, and the controller field devices 40 and 42 generally constitute the distributed process control system (DCS) 12 of FIG. 1.

[0010] As a mere example, process controller 24, which can be a DeltaV™ controller sold by Emerson Process Management or any other desired type of process controller, is programmed to provide process control functions (using what are generally referred to as control modules) using I / O devices 28, 30, and 32, and field devices 40 and 42. In particular, controller 24 implements or monitors one or more process control routines 75 (also referred to as control modules) stored in or otherwise associated with it, and communicates with field devices 40 and 42 and workstation 16 to control process 10 or a portion of process 10 in any desired manner. Field devices 40 and 42 can be any desired type of field device such as sensors, valves, transmitters, positioners, etc., and can comply with any desired open, proprietary, or other communication or programming protocol, including, for example, HART or 4 - 20ma protocol (as shown for field device 40), Foundation™ Fieldbus protocol (as shown for field device 42), or CAN, Profibus, AS interface protocol. Similarly, I / O devices 28 - 32 can be any known type of process control I / O device using any appropriate communication protocol. A common backplane 76 (shown by the dotted line passing through controller 24 and I / O devices 28 - 36) is used at each of nodes 18 to connect controller 24 to process control I / O cards 28, 30, and 32. Controller 24 is also communicatively coupled to bus 22 and operates as a bus arbiter of the bus to enable each of I / O devices 28 - 32 to communicate with any of workstations 16 via bus 22.

[0011] Figure 1 shows that a plurality of workstations 16 can be coupled to the DCS. The workstations can be programmed to execute standard operator control applications 77, 78 for running the plant. Since these standard operator control applications may be required to control and operate the plant process using field devices, they can be regarded as part of the DCS 12. For example, the control applications 77, 78 can be used to read from, write to, or otherwise access process control devices such as controllers or field devices. The operator can be responsible for monitoring process variables by reading parameter values and adjusting the parameters of the controller or field device accordingly. Depending on the situation, when various process variables indicate certain conditions, the operator can adjust the setpoint of the controller. Standard operator control applications can be used to perform these procedures.

[0012] FIG. 2 shows a dashboard view of a portion of the processes within a plant, and shows a graphical user interface (GUI) 900 of a possible operator control application with an overlay of a distributed control system. FIG. 2 shows a graphical display of a portion of a process plant 910 managed by a DCS application, and shows one or more field devices 940 arranged around the activities within the plant. This GUI 900 can represent aspects of a DCS operator control application such as DeltaV (trademark) Operate sold by Emerson Process Management, which is executed on any one or more of the workstations 16 of FIG. 1. Generally, an operator can use the GUI 900 to monitor the plant process and adjust and schedule plant devices (e.g., controllers and field devices) through communication via a series of input / output I / O devices or interfaces. The GUI 900 can show a plant and process dashboard view or a bird's-eye view, and the operator can monitor the major parameters 956 around and surrounding the plant 910 with the ability to obtain more detailed information regarding specific sections or devices. During normal operation of the plant, this screen can be interrupted with an alert message or prompt if the user attempts to change the parameters of a process control device, as shown in FIG. 4A (described further below).

[0013] Figure 3 shows the security process of an operator control application that can be executed on a distributed process control system (DCS) as shown in Figure 2. In some workstation applications, the authentication service 310 of the operating system 312 of a computing device can be used in combination with the authentication function 320 of the application 330. For example, a user can first log in to a computing device by entering a username 314 and a password 316. In a process control system that executes an operator control application 330, the operator control application 330 can utilize the login credentials 314, 316 of the operating system and simultaneously log in to the operator control application authentication function 320 by using the same credentials 314, 316. As an example, it can be a login to a process control system workstation that is running a Windows operating system. The login to the workstation's window environment 312 can also be used for logging in to the operator control application 330. In this situation, a network directory service such as Microsoft's Active Directory (AD) 313 can be used to manage the user's credentials (further described below). When an operator logs in to both the local workstation operating system 312 and the operator control program 330, the operator can access a GUI 332 similar to that shown in Figure 2 as the main portal to the operator's duties and job functions.

[0014] As described above, an operator can monitor the processes within a plant using the GUI of FIG. 2. At a particular time, the operator can click on a process indicated by the GUI 900 and decide to access a process control device such as the controller 24 or the field device 40, for example, by changing the setpoint 988. In some systems, change or write commands to process control devices such as the process controller 24 or the field device 40 can have security restrictions in place. Some of these restrictions can be implemented to ensure the accuracy of the change. For example, a plant operator can be prompted to reconfirm the input regarding the parameter change before executing a write command to change a process control device. Some process control system programs can display a warning prompt to the user requesting the user's credentials after the user attempts to initiate, send, or execute a write command to a process control device. FIG. 4A shows an exemplary warning screen 410 that can be displayed when an operator application intercepts an attempt to change a process control device. The warning screen 410 can display a warning 412 about the possible adverse effects of the change to the device and request the user to sign in with a username 414 and password 416 to confirm the change. In this situation, the user credentials 414 and 416 can be used to verify the identity of the user issuing the write command. In systems that utilize a network directory service such as Active Directory, the login credentials 414 and 416 can generally be the same as those used by the user to sign in to the workstation 16.

[0015] In an embodiment, the warning prompt can display a simple question or statement 418 that requests the user to confirm that the parameter change is accurate. The user qualification information 414 and 416 can also be used to check whether the user has the authority to make changes to the process control device. This can apply to more important parameters of the process control device. For example, to change the set value of a process controller that has been commissioned and is online, a security check can be required to determine whether the user is permitted to make changes to the process controller. In some systems, important parameters or devices can be marked as protected and additional security can be required. For example, in a process control system, user authentication can be required to confirm that the user using the qualification information for changing the process control device is actually that user.

[0016] In some existing systems, a single warning prompt as shown in FIG. 4A can be the only check required before executing a change to a device parameter. In this case, a write attempt to a process control device to change a process parameter can simply request the user to confirm that the change command is intended and correctly sent by entering or re-entering user authentication information such as the username 414 and password 416. The first user to initiate the change command can be called the confirmor.

[0017] In some systems, a two-user verification system may be implemented. In this case, for the confirmation and verification by the verifier, it is insufficient to release and execute the write command. In these systems, the write command can require additional authentication from a second user, such as a user belonging to a specific group or role. For example, in a process plant where an operator may be a verifier, a user in the supervisor group (the supervisor has a higher rank than the operator and, as a result, a larger set of permissions) may need to authenticate themselves in addition to the verifier before the write command is permitted to change the process control device. FIG. 4B shows a second login prompt 430 for the verifier to confirm the changes made by the verifier. The verifier prompt 430 can include the identifier of the verifier or the first user who initiates the write command 432, a list 434 of the device parameters to be changed, and a statement or prompt for signing in to verify the write command 435. Input boxes for the username 437 and password 439 can be provided so that the user can enter the qualification information. In an embodiment, while the supervisor is the verifier of the write command, the operator can be the confirmator or initiator of the command. As described above, sharing the login qualification information can be one way to invalidate this verification and security process. FIG. 4C shows a security or warning prompt 450 that shows an intercepted write command for changing the set point 451 with input boxes for both the confirmator username 453 and password 454 and the verifier username 456 and password 457 on one screen.

[0018] In some process control device networks, network directory services such as Microsoft's Active Directory (AD) can be used to control access to a wide range of applications and systems within an organization's network. In particular, in the case of a process control plant running Microsoft Windows as the primary operating system on network workstations, AD can serve as a user directory that has the authority to manage access to most services such as email, file sharing, and in some process control networks, operator control applications and engineering applications that have access to plant devices.

[0019] Figure 5A shows an organizational structure 500 captured by a network directory service such as Microsoft's Active Directory. In a model like Active Directory, a system administrator can set up user accounts and assign roles or sets of privileges to users. Since multiple people with the same role can have the same set of privileges or permissions to access resources such as machines and other computing devices (e.g., process control devices) and to perform activities on resources such as read or write functions of a machine, the roles in this model can also be called groups. As shown in Figure 5A, three roles or groups are defined: operator 510, supervisor 520, and project manager 530. Each group has a set of privileges or permissions 512, 522, 532. In this particular example, supervisor 520 has a higher rank than operator 510, and project manager 530 has a higher rank than supervisor 520. The higher-level users in this model have more sets of permissions. For example, the set of permissions 522 is larger than the set of permissions 512 (e.g., has more permissions), and the set of permissions 532 is larger than the set of permissions 522.

[0020] In some systems that manage user qualification information using AD, two user validations can include an operator control application that determines that a first user does not have permission to execute a write command based on a group of users in the active directory. For example, in Figure 5A, operator 510 can start a write command based on those permissions 512, but only the supervisor and manager 530 have write permissions 522 and 532. If the application determines that a role (e.g., operator) does not have write permission, it can require a role that has write command permission (e.g., supervisor or manager). As a result, the operator control application can display a warning prompt for a second user to verify the write command, as shown in Figure 4B or Figure 4C. This second warning or authentication prompt 430 or 450 can be for a user who has a role with the write permission required by the process control device. In existing systems, the operator workstation application may simply require that any of the signed-in users have write permission to the process control device. If both the first user and the second user have write permission, the security process can become redundant. This can apply when the first user and the second user are the same user, but the system requires two user validations by default. This potential security problem is the case where neither the first user nor the second user is currently monitoring the specific process using the process control device, but for models such as AD, both users have the privilege to write to the device.

[0021] As described above, when applied to the operator control application of a process control system, there may be problems with the Active Directory model for managing user qualification information. The configuration of FIG. 5A may be suitable for general computing resources where an Active Directory might be designed, but may not be particularly suitable for process control devices of a process control system that require more specific monitoring activities by and between specific users. Also, modeling the rights and privileges for the roles of the Active Directory model may not be suitable for capturing the important direct operator relationships for managing the equipment of a process plant and providing appropriate security.

[0022] In the process control industry, relationships between users such as supervisors and operators can be important elements in monitoring and managing activities or processes. Users may have the same general set of privileges as defined in an Active Directory model similar to that shown in FIG. 5A, but have different responsibilities based on processes or subprocesses within the plant that are not captured in the general role descriptions. For example, a group of supervisors may all have the same rights to process control devices, but the responsibilities of a supervisor for a process control device can be distinguished based on the subordinates who report directly to the supervisor and the processes assigned to the subordinates. Depending on the situation, a supervisor may not be interested in a particular device outside of the supervisor's area of responsibility, but may be part of an AD group that has the right to verify write commands to the device. As a result, there is a risk in giving blanket write permission to supervisors based only on their role. Although the use of AD is described herein, it should be noted that other network directory services may operate in a similar manner using a user organization model that is not identical but similar based on privileges or rights. The same deficiencies described for AD may apply to these other systems as well.

[0023] As described above with respect to FIG. 5A, the Active Directory model shows that the supervisor 520 can have similar access and permissions for approving write commands in an AD-based system. The role 520, which includes multiple supervisors, will permit the same set of write permissions to all supervisors within the group 520. However, in a process plant, verifying a specific write command for a specific device may require a user with knowledge of the circumstances specific to the device's process, and the verifying user may be directly related to the user initiating the change. This direct relationship may not be capturable by existing security protocols that rely on AD-based user roles. The problem is further exacerbated in a Distributed Control System (DCS) where multiple different areas or subprocesses are assigned to different teams, each of which may have different direct subordinates. Based on the AD model, the role of supervisor can permit access to multiple supervisors for the same set of devices, even if different supervisors are responsible for different sets of people working on different aspects (processes) of the device.

[0024] Figure 5B shows a possible direct relationship configuration. The supervisor group 540 includes supervisor A and supervisor B. The operator group 545 includes operator 1, operator 2, operator 3, and operator 4. Operator 1 and operator 2 can report directly to supervisor A and form a first team. Operator 3 and operator 4 can report directly to supervisor B and form a second team. Some of the process control devices in the plant can be changed at different times or in different aspects of the process based on which team is changing the parameters of the device. In an AD implementation, all supervisors in the supervisor group 545 can have the same set of privileges or permissions to verify or validate write commands, even if a supervisor belongs to a different team and can verify write commands for issues not related to the team of another supervisor. For example, operator 2, being responsible for the first team, can initiate a write command based on a situation that supervisor A needs to be aware of. In the current AD implementation, any supervisor 540 can use their credentials to permit a write command of any operator 545. In some situations, the theft of a supervisor password can be used in a malicious way and potentially affect the entire plant as defined in the Active Directory privilege list. Since the Active Directory system's group / role and privilege-based system does not consider the definition of relationships, the AD model may be limited to checking group membership and privileges based on group membership. Therefore, some existing systems use two-factor authentication, but there may be specific problems (e.g., redundancy and password sharing) in providing access to process control devices.

[0025] In FIG. 5B, the links 51-54 represent relationships between users that are not captured by the Active Directory model. These relationships 51-54 can be between a supervisor and a subordinate (operator). Even within a group defined by rank, individual direct relationships can be captured. For the set of operators 1-4 and supervisors A and B, this relationship graph can directly connect two individual users, regardless of role or rank. FIG. 5C shows a broader relationship graph 560 that shows the set of direct connections between the users of FIG. 5B. FIG. 5C also shows that interconnections at three or more levels are possible. In some embodiments, the third role 580 can be a project manager (PM). The project manager 580 can have a higher rank than the supervisor 540 and can have a corresponding larger set of permissions. In an embodiment, the direct relationship can be implemented using relationship identifiers within the profile set. Further, to address and reduce the loopholes associated with the configuration of common usernames and passwords, biometric input of the user can be used for authentication. In combination with the profile containing relationship information, the authentication of the user can also include authentication of the attributes of the user profile, including the user profile and the relationship link. The key 581 shown in FIG. 5C can indicate that the relationship is biometrically authenticated.

[0026] Figure 6 shows a system 600 for implementing a security protocol that takes into account direct assignments and verifies relationships that support those assignments using biometric identifiers. The user manager component 610 can manage a set of profiles 612 for DCS workstation applications 620 such as operator control application 622 or engineering application 624 that configure and install control modules. Note that the DCS workstation application 620 can have different components such as an operator control application, an engineer application, or a system administrator application. Although Figure 6 is described with respect to the operator application 622, note that many different DCS-related applications can be executed on the same or different machines.

[0027] The user manager component 610 can manage a set of user profiles 612. In an embodiment, the user manager component can be adapted to store and retrieve a set of user profiles. The user profile 612 can include the following attributes: a user identifier 613, a group identifier 614, a set of permissions 615, a biometric identifier 616, and at least one relationship identifier within a set of relationships 617. In an embodiment, the user manager component 610 can include a database 615, a spreadsheet, or an equivalent data storage component adapted to store and / or retrieve a set of user profiles 612. The user manager 610 can be adapted to receive requests for profiles 612 based on any of the attributes and return the corresponding profiles. In an embodiment, the user manager component 610 can be a relational database management system.

[0028] Security and Verification Component (SVC) 630 can be communicatively coupled to user manager component 610 to implement a process for verifying and / or authorizing write commands to process control devices, as described herein. In an embodiment, any of DCS applications 620 can be communicatively coupled to user manager component 610 and security and verification component 630 to implement a security protocol. Security and verification component 630 can intercept write commands or attempts to change from one or more workstation applications, such as an operator control application. The write commands can be directed to one or more process control devices. The write commands can be intercepted in several ways, as further described below. Next, security and verification component 630 can apply a security process before releasing an intercepted write command if the security and verification process is successful, or terminate the write command if the security and verification process fails. In an embodiment, security and verification component 630 can be part of DCS operator control application 622. In an embodiment, security and verification component 630 can be an application that runs independently on a network server device or a workstation. For example, SVC 630 can monitor network traffic for write commands at the server and intercept those commands before they reach the process control devices for commitment or execution. In an embodiment, SVC 630 can be executed on a gateway computing device through which commands from an operator workstation must pass before being routed to a communication bus that connects an I / O interface to the controller and field devices.In a DCS where multiple workstations are arranged in different physical areas within a plant, SVC630 can be executed on a server that is communicatively coupled to the workstations and provides security protocols described for all the workstations.

[0029] In embodiments, mobile computing devices 641 and 642 such as tablets and mobile phones can be connected via a wide area network 645 or via an external Internet connection where SVC630 can provide a security protocol for write commands before any write commands can further communicate at the protocol level of the control device. In embodiments, an operator application executed on a workstation using a computer operating system 650 and utilizing AD650 can be modified to use SVC630. In embodiments, user information of AD651 can be integrated into a user manager table of database 615 and can include biometric parameters and relationship identifiers. In embodiments, user manager database 615 can be created by combining a table within AD database 651 with additional parameter information as described herein. In embodiments, general security measures already implemented by AD for workstation window login 651 can be maintained while SVC630 provides additional protocols in addition to general AD-provided security.

[0030] Generally, the system described in FIG. 6 can be used to implement relationship definitions in user profile 612, enforce more stringent compliance to direct assignments, and enhance security through the use of biometric identifiers for validating relationships. Relationships can be defined using relationship identifiers within a relationship set. In embodiments, a relationship identifier can be a user identifier of another user. In embodiments, a relationship identifier can be a biometric identifier of another user.

[0031] As further described below, the authentication and verification procedures for two users can be performed and initiated by the SVC630 as needed. Using biometric input, it is possible to authenticate a user and profile parameters associated with the user that include at least one relationship indicated by a relationship identifier attribute of the profile. Next, after the first user authentication to confirm the write command, a second user authentication request based on the relationship identifier of the first user can follow so as to be included in the profile of the first user. In some embodiments, the authentication of the first user can include two-factor authentication where the user is required to enter an identifier of the user's direct supervisor.

[0032] Figure 7 shows a process of making security measures relevant to an organization by using relationship definitions and biometric signatures to enhance the accuracy of user authentication and obtain responsibility assignment. In block 701, write commands to the process control device can be intercepted. The write commands can target important process control devices that are protected. Specific important processes of the process control system can be selected for a higher level of protection and security. These processes can include a series of process control devices involved in the management of important processes. Important devices or equipment can be given protection attributes indicating that additional security, approval, and / or verification processes may be required to write to, read from, or otherwise access the process control device. In some embodiments, individual parameters or sets of parameters of the process control device can be protected, but some sets of parameters may not need to be protected. In these embodiments, the device itself is not protected, but the parameters of the device can be protected. In some embodiments, the protected attribute can identify that a certain type of relationship is required to access or write to the protected parameters. For example, the protected attribute can require two-user authentication / verification having an operator and supervisor relationship between two users.

[0033] In block 701, the intercepted write command can be a command initiated by a first user, for example, by clicking on one of the devices shown in FIG. 2 to which a protected attribute is assigned. FIG. 8 shows a possible prompt 810 according to an embodiment showing an intercepted write command or an attempt to make a change. Note that the methods described are not limited to change commands, write commands, or GUI-based initiation of change commands. In some embodiments, various methods can be used to initiate a change to a device parameter value, including a command prompt screen where the user enters a change command or a write command. Block 701 can intercept a write command when checking whether the device is protected or whether the device parameter is protected. The process of checking device protection can be performed by an operator control program when querying the device status in memory or when querying a live device. If it is determined that a command has been initiated or issued by a user for a protected device or a protected parameter, the DCS operator control program can be adapted to automatically intercept the write command. In an embodiment, the write command can be intercepted by a server that monitors write commands sent to a process control device on a network. Block 01 can intercept the write command, for example, by holding or pausing these commands that are in an approval or verification process. To hold or pause an intercepted command, it can include placing the command in a cache or a waiting queue until a determination is made from the security process.

[0034] Block 701 can also determine whether a relationship security protocol is being implemented for a protected process or a set of protected parameters. Some protected devices or device parameters can indicate that a write to the device is required. This can indicate that at least two user authentication and verification processes are required. In some embodiments, a user can have multiple direct relationships with differently ranked users, and a protected attribute can include information regarding the type of relationship between two users for a write command to be released. In an embodiment, the required relationships can be managed by SVC 630 based on information provided by the user manager component 610. Since relationship identifiers can be used to indicate multiple direct relationships, a protected attribute can indicate the type of relationship (such as an operator and supervisor relationship) required for verification of a write command.

[0035] Block 702 can determine a second user having a relationship with the first user as defined by the relationship identifier of the first user. In an embodiment, block 702 can query the profile of the second user based on the relationship identifier of the first user who initiated the write command. In an embodiment, the first user can have a profile that includes a relationship identifier where one of the attributes indicates a relationship with another user. A user can have one or more relationship identifiers. The number of relationship identifiers can be based on the type of relationship captured by the security protocol or on the organization's hierarchy or structure.

[0036] In an embodiment, determining the second user can include querying a user manager component that provides user profiles based on the input relationship identifier. In an embodiment, the relationship identifier of the profile of the first user can be the user identifier of the second user as included in the user profile of the second user. In an embodiment, the relationship identifier can be an index that references the user profile of the second user. As described, the user manager component 610 can include a database 615, an electronic table, or equivalent data storage adapted to store and retrieve a set of user profiles. In an embodiment, the database 615 can be adapted to provide the functions described herein for the SVC 610. In an embodiment, the user manager database 615 or the user manager component / module 610 can be adapted to receive a query for a user profile based on the listed attributes and search for the user profile. Biometric identifiers can include, but are not limited to, information such as fingerprints, faces, retinas, etc. that identify a user.

[0037] Block 703 can prompt the user to verify the intercepted write command. In an embodiment, when a second user is determined in block 702, block 703 can send a prompt to the second user. In an embodiment, the second user may be away from the first user and may be using a different workstation or other computing device than the first user. The location information of the second user can be provided by the security and verification components. In an embodiment, the location information can be queried from a separate application running on the server. The current location of the second user can be stored as an attribute by the user manager component. In an embodiment, block 703 can simply cause the operator workstation program to display a prompt on the same computing device that the first user is using for the second user to verify the write command. FIG. 8 can show an embodiment of a prompt 810 for two-user verification. In an embodiment, the identity of the second user may not be indicated by the prompt. This can be done to maintain a security level where relationship information is not displayed and to further prevent unauthorized users from attempting access. In an embodiment, the prompt can simply request verification of the write command and can show an input field for receiving user credential information such as biometric fingerprints or other biometric inputs. In an embodiment, the prompt can request verification of the write command issued on the same computing device or machine along with a request to input biometric credential information from the first user.

[0038] Block 704 can authenticate a second user using biometric authentication or input. Biometric input can include, but is not limited to, information such as fingerprints, faces, retinas, etc. that identify a user. In embodiments where biometric input is used to authenticate a second user, the biometric input can represent a higher level of authentication integrity than user login and passwords. In particular, in biometric authentication, physical identification markers of a human user can be used to increase the level of identification accuracy. Biometric authentication can also be used to authenticate the relationship with a second user.

[0039] In embodiments, a single user, such as a second user, can provide biometric input for authentication. This can be suitable, for example, when the first user is already somewhat authenticated by accessing a computer using a username and password, or when a higher-level user, such as a supervisor, is ultimately responsible for the verification process. This can also be suitable when the first user (e.g., an operator) and the second user (e.g., a supervisor) are located proximal to each other (e.g., in the same room) or are arranged using the same workstation. It should be noted that in embodiments, authenticating a user includes authenticating the user's relationship such that it is captured by the user's relationship identifier and stored by the user manager component. In this situation, trust is based on the integrity of the relationship information provided by the user manager component. The system administrator can be responsible for the task of inputting this relationship information. In embodiments, values can be assigned to the user's relationship identifier parameter during activation or creation of a user count, including creation of a user profile. The SVC can automatically assign this value, or the system administrator can assign the value.

[0040] In an embodiment, the relationship between a first user and a second user can be authenticated through one or both of the users, and two-user authentication can be more accurate and reliable than single-user authentication of the relationship. In particular, the integrity of relationship verification can depend on whether one or both of the users provide biometric input. In an embodiment, a higher level of relationship integrity can be achieved when the identities of the first and second users are displayed to both users. In this situation, after verifying the identity of the other user, continuing the authentication process implies knowledge about the relationship with the other user.

[0041] Note that the rank does not necessarily participate in the verification process of the two users for which the relationship is defined. In an embodiment, the first and second users in the relationship can have the same or similar rank with respect to responsibilities and privileges. In the embodiment further described below with respect to FIG. 11, the process to be described can simply require two authenticated biometrics or signatures from the associated first and second users to release the intercepted write command. In this way, the security process described can maintain integrity because the two users can be accurately identified in the relationship where the signature verified the write command (through biometrics). Note that even between similarly ranked operators, the biometric signature requirement can be a mechanism that encourages both operators to check and be responsible for changes to write commands or processes.

[0042] Block 705 can release the write command for execution by the process control device if there is a match between the biometric input of the second user and the biometric identifier in the second user's profile. If the verification process fails or, otherwise, in an unsuccessful situation (such as a system malfunction), the write command can be terminated.

[0043] FIG. 8 shows a GUI 810 for a two-user verification system as described above. FIG. 8 shows an operator control application interface 900 similar to that of FIG. 2, but uses two user prompts 810 that request biometric information. The prompts indicate two-user authentication for an approver 825 for set point changes 821 and a verifier 822. In this embodiment, when the approver 825 authenticates himself as the name 831 John Appleseed, the approver name 831 is displayed to the verifier 822. In this example, the verifier 822 can see the approver name 831 and understand that the approver has been authenticated and that the write command is to change the set point of the device 821. If the verifier 822 agrees, the verifier 822 can submit a biometric input. When the verifier completes authentication, the name of the verifier 832 is shown in the prompt and the names of both signers are displayed.

[0044] Figure 9 shows the mobile system interfaces 901 and 902 for verifiers such as supervisors. These interfaces can be displayed, for example, on the mobile devices 641 - 642 of FIG. 6. In situations where the supervisor is located away from the process plant, the described system can enable a remote supervisor to biometrically verify operator write commands, for example, by using a biometric fingerprint scan. FIG. 901 shows a GUI that requests the verifier to send a fingerprint scan. Next, the scanned fingerprint can be sent to the plant's SVC for authentication, and if successful, as shown in 902, the operator application can be opened for access. The remote supervisor can be connected to the process control system via the cloud service 645 and to the SVC 630, as shown in FIG. 6. The intercepted write commands can cause the above-described prompts to be displayed on the mobile interface (not shown in the figure). Through the supervisor's biometric fingerprint authentication, the user can provide signatures for various write commands from the operators of the supervisor's team based on the relationship identifier.

[0045] In an embodiment, the biometric authentication process can be recorded in a runtime change database. This database may be referred to as an event record that captures changes made to plant devices such as field devices and includes resulting operational changes. The event record can include records that contain at least some of the following fields: a first user ID, a second user ID, a device ID, a parameter name, a change in parameter value, and the impact of the change in parameter value. To trace changes to devices or device parameters that affect the plant process in a particular way, biometric authentication inputs by one or more persons can be recorded in such a database (e.g., via the first and second user ID parameters). By recording the identifiers of both the approver and the verifier, the responsible person can be identified and interviewed for additional information. Further, in an embodiment, the event record can be used to provide information to the verifier when prompted to verify a write command. Previous changes to device or process parameters can be queried to be presented to the verifier in a prompt to assist in determining whether the verifier should permit the write command.

[0046] In an embodiment, another configuration database called an audit trail can record non-runtime changes to process control devices, including records of the identities of the approver and verifier for write changes. This audit trail database can be tasked to record configuration changes to the device and have parameters similar to the event record. This change may be useful in identifying the responsible person if the configuration change needs to be rolled back or withdrawn after an adverse effect is seen on the operation of the device.

[0047] Figure 10 shows a specific process flow that includes determining whether to implement single-user verification or two-user verification in a security process. At block 1001, a write command can be intercepted by the system. The write command can target a specific device or device parameter. Block 1002 can check the target device or device parameter to determine whether it is protected or, if not, whether it has security attributes. If the device or device parameter is not protected, the write command can be released at block 1004. If the device or device parameter is protected, a check can be made at block 1005 to determine whether to execute a relational security process (e.g., a two-user verification process). If the protected parameter does not require enhanced security and verification, a single user confirmation and authentication prompt can be displayed at block 1006. If the confirmation is successful at block 1007, the write command can be released at block 1008, and if not, the write command can be terminated at block 1009.

[0048] If an enhanced security and verification process is determined at 1005, block 1020 can determine a second user based on the relationship information of the first user who initiated the write command. The system can prompt the second user to verify the write command in block 1021. In an embodiment, the system can also query a historical database such as an event record or an audit trail database as described above and present information about previous changes to the user in block 1021. In an embodiment, the historical information can include the identities of the previous users or user pairs involved in those previous device or device parameter changes. The system can receive, in block 1022, a biometric input that functions as a user signature for verifying the write command. If the biometric input matches the biometric identifier of the second user profile in block 1023 (e.g., the second user is authenticated), the write command can be released in block 1024; otherwise, the system can terminate the write command in block 1025.

[0049] Figure 11 shows an alternative two - user biometric authentication process that includes relationship determination. In block 1101, a write command can be intercepted. In block 1102, as shown in Figure 4C, a two - user verification prompt can be displayed. The two - user verification prompt can be created without a first search or query to determine the second user. In block 1103, biometric authentication inputs from the first and second users can be received. In block 1104, the first and second user profiles can be queried based on the biometric authentication inputs provided in block 1103. If a profile can be found based on the biometric authentication input, user authentication can be achieved. If the first user is the user who initiated the write command, the system may already have the user profile of the first user. In this case, the biometric authentication input of the first user further confirms the identity of the first user. Block 1105 can determine whether the two users are authenticated based on whether their biometric authentication inputs match, for example, the user profiles provided by SVC. If the two users are not biometrically authenticated in block 1105, the intercepted write command can end in block 1106.

[0050] If both the first user and the second user are biometrically authenticated in block 1105, block 1107 can analyze the relationship information of the two authenticated users. In an embodiment, if the relationship identifier of the first user references the second user, or vice versa, the relationship can be determined between the two users. In an embodiment, a valid relationship can be based on whether the protected attributes specify a matching relationship between the first user and the second user, such as an operator - supervisor relationship. If a valid relationship is found in block 1108, the system and method can release the write command in block 1109; otherwise, the write command can end in block 1110.

[0051] In some of the above-described embodiments, the relationship identifier can be fixed. For example, the relationship can describe a specific link between a supervisor and a subordinate and remain unchanged during the operation of a group or team. In an embodiment, the relationship information included in the user profile can be changed or modified based on approval settings. The approval settings or attributes can indicate a user or group that can change the relationship information or relationship identifier within the user profile. In one example, while a supervisor can change the relationship attribute to point to or reference another supervisor, an operator may not have the approval ability. This can apply when the supervisor is on vacation or otherwise unavailable. In some embodiments, only a project manager has approval settings that allow the project manager to change the relationship attribute so that the project manager points to other users. In some process plants, depending on how the plant organizes teams around tasks or processes, the relationship attributes of the user profile may be changed frequently. In an embodiment, the relationship identifier of each user profile can be directed in only one direction to a user having a higher rank and a higher set of permissions.

[0052] In an embodiment, the two-user verification process can include a third user, and the third user can provide verification of the write command. In situations where the second user is unavailable, the method and system can determine the third user based on the relationship identifier of the second user. In a system where the first user is an operator and the second user is a direct subordinate of a supervisor, the relationship identifier of the second user can result in a project manager who has a higher rank than both the operator and the supervisor. Next, this project manager can be prompted to verify and / or validate the write command.

[0053] Referring again to FIG. 6, the Security and Verification Component (SVC) 630 can serve an engineering application as a workstation application 620 and can be adapted to have a user interface 624. The engineering application generally constitutes a programmed control module and can be used to install on one or more process controllers or smart field devices (field devices with computing capabilities). The control module can implement various control loop programs for managing process variables using control loops (e.g., a controller and one or more field devices). In some existing systems, security protocols are applied to individual control modules to lock the control modules to prevent unauthorized access and changes. These security protocols are specific to the control modules and can be made not to be directly controlled by a network directory service or a third-party service. In these systems, an engineer can lock a control module using a common username and password. A problem that can arise from the independent lock control of discrete control modules is that the control module may be permanently locked. This situation can occur when an engineer forgets the username or password. Depending on the situation, an engineer may leave the employment of a process plant without unlocking the control module or leaving the username and password with other engineers or officers of the plant. In this case, the control module is permanently locked and a new control module needs to be programmed from scratch, which can result in a significant loss of time and effort.

[0054] In an embodiment, the process control module of the engineering application 620 can be specified as a resource such as a process control device, and the above methods can be similarly applied. The control module can be specified or marked as protected, such that at least the above verifier security process is required if an engineer needs to authenticate themselves for changes to the control module. In an embodiment, the engineer's relationship identifier can be used to determine a higher-level user, such as a direct supervisor, who can access and / or unlock the control module. In yet another embodiment, if neither the engineer nor the supervisor is available, a third user (e.g., a project manager) identified by the supervisor's relationship identifier can access and modify the control module or otherwise unlock the control module.

[0055] The following additional considerations apply to the above discussion. Throughout this specification, actions described as being performed by any device or routine generally refer to actions or processes of a processor that manipulates or transforms data according to machine-readable instructions. The machine-readable instructions can be stored on and retrieved from a memory device communicatively coupled to the processor. In other words, the methods described herein can be embodied by a series 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 user interface device, etc.), cause the processor to execute the method. When the terms "stored" and "saved" are referred to herein in the context of instructions, routines, modules, processes, services, programs, and / or applications being stored or saved on a computer-readable memory or a computer-readable medium, the terms are intended to exclude transient signals.

[0056] Further, the terms "operator", "personnel", "person", "user", "technician", and similar other terms are used to describe a person within the process plant environment who may use or interact with the systems, devices, and methods described herein, but these terms are not intended to be limiting. When a particular term is used in the description, the term is used in part for traditional activities performed by plant operators, but is not intended to limit the operators who may perform a particular activity.

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

[0058] Specifically, unless otherwise described, the discourse in this specification using words such as "process", "compute", "calculate", "determine", "identify", "present", "cause to be presented", "cause to be displayed", "display" may mean an action or process of a machine (e.g., a computer) that manipulates or transforms data represented as a physical (e.g., electrical, magnetic, ecological, or optical) quantity within 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.

[0059] When implemented in software, any of the applications, services, and engines described herein can be stored in any tangible non-transitory computer-readable memory, such as a magnetic disk, a laser disk, a solid-state memory device, a molecular memory storage device, or other storage media in the RAM or ROM of a computer or processor. The exemplary systems disclosed herein are disclosed as including software and / or firmware executed on hardware, among other components, but it should be noted that such systems are merely exemplary and should not be considered limiting. For example, any or all of these hardware, software, and firmware components may be embedded solely in hardware, solely in software, or in any combination of hardware and software. Accordingly, those skilled in the art will readily understand that the provided examples are not the only way to implement such systems.

[0060] Accordingly, while the invention has been described with reference to specific examples, these examples are merely illustrative and are not intended to be limiting of the invention, and it will be apparent to those skilled in the art that changes, additions, or deletions can be made to the disclosed embodiments without departing from the spirit and scope of the invention.

[0061] Unless a term is explicitly defined within the patent using a statement such as "As used herein, the term '______' is defined to mean... in this specification" or a similar statement, there is no intent to limit the meaning of the term beyond its plain or ordinary meaning, either expressly or by implication, and it should also be understood that such term should not be construed to be limited within the scope of any description made in any section of this patent (other than the words of the claims). If any term recited within the last claim of this patent is referred to within the patent in a manner that does not conflict with a single meaning, it is done merely for clarity so as not to confuse the reader, and such claim terms are not intended to be limited to that single meaning by implication or otherwise. Finally, unless an element of a claim is defined by reciting the word "means" and a function without reciting any structure, the scope of any element of a claim is not intended to be construed based on the application of 35 U.S.C. § 112(f) and / or 35 U.S.C. § 112, paragraph 6, prior to the AIA.

[0062] Moreover, while the above passage describes detailed explanations of many different embodiments, it should be understood that the scope of this patent is defined by the language of the claims recited at the end of this patent. The detailed explanations should be construed as merely illustrative, and it is not possible, nor realistic even if not impossible, to describe all possible embodiments, so it does not describe all possible embodiments. Many alternative embodiments may be implemented using either current technology or technology developed after the filing date of this patent, and these will still fall within the scope of the claims.

Claims

Claim 1 A method for permitting a write command to a process control device within a distributed process control system (DCS), wherein the DCS includes at least one controller, one field device, and a workstation communicatively coupled to the at least one controller and the one field device, the process control device being the at least one controller or the one field device, the method comprising: intercepting, by one or more processors, a write command to the process control device issued by a first user; determining, by the one or more processors, a second user based on a relationship identifier of the first user, wherein the relationship identifier identifies a type of relationship between the first user and the second user necessary for the second user to verify the write command; prompting, by the one or more processors, the second user to verify the write command; verifying, by the one or more processors, the write command based on a biometric input of the second user, and verifying the write command includes authenticating the second user by determining a match between the biometric input of the second user and a biometric identifier within a profile of the second user; releasing, by the one or more processors, the write command for execution on the process control device upon determining the match between the biometric input of the second user and the biometric identifier within the profile of the second user. A method comprising. Claim 2 The method of claim 1, wherein determining the second user based on the relationship identifier of the first user includes querying a user manager component for a second user profile based on the relationship identifier of the first user. Claim 3 Further, querying, by the one or more processors, the user manager component to determine whether the first user has a set of permissions that enable the first user to generate the write command to the process control device. Receiving, by the one or more processors, a biometric input of the first user, and determining a match between the biometric input of the first user and a biometric identifier in a profile of the first user in a user manager database, the method according to claim 2.

4. Further, determining, by the one or more processors, whether the write command is for a critical process parameter, and intercepting the write command when it is determined that the write command is for the critical process parameter, the method according to any one of claims 1 to 3.

5. Authenticating the second user includes receiving, at a first workstation, a biometric input of the second user and transmitting the biometric input of the second user to a second workstation, wherein the biometric input of the second user is checked against a biometric input of a user profile of the second user at the second workstation, and the first workstation is remote from the second workstation, the method according to any one of claims 1 to 4.

6. Further, authenticating, by the one or more processors, the first user based on a biometric input of the first user, wherein the biometric identifier of the user profile of the first user is checked against the biometric input of the first user, the method according to claim 5.

7. Further, creating, by the one or more processors, a user manager table of user profiles, each user profile including a user identifier, a group identifier, a set of permissions, at least one relationship identifier, and a biometric identifier, the method according to any one of claims 1 to 6.

8. Furthermore, querying, by the one or more processors, the user management table for a profile of a third user based on the relationship identifier of the second user; and releasing the write command for execution on the process control device when a match is determined between the biometric input of the third user and a biometric identifier within the profile of the third user in the user management table. The method according to claim 7.

9. Creating the user management table includes merging a set of user parameters from an Active Directory database, the set of user parameters from the Active Directory database including a user identifier, a group identifier, and a set of permissions associated with the group identifier. The method according to claim 7 or claim 8.

10. The profile of the second user includes a group identifier indicating membership in a group having a larger set of permissions than the first user with respect to the process control device. The method according to claim 9.

11. Furthermore, determining, by the one or more processors, whether the intercepted write command is for a protected device parameter that requires a certain relationship between the first user and the second user. The method according to any one of claims 1 to 10.

12. Furthermore, changing, by the one or more processors, the relationship identifier of the first user to reference a third user different from the second user, the second user and the third user belonging to a group having the same set of privileges. The method according to claim 1.

13. Furthermore, storing, by the one or more processors, a transaction of the released write command in a history database, the transaction including at least the biometric inputs of the first and second users received for verification of the write command and the date and time of the executed write command. The method according to any one of claims 1 to 12.

14. Furthermore, checking the history database by the one or more processors for transactions prior to the involvement of the first user or the second user, and displaying the previous transaction to the second user prior to authenticating the second user. The method according to claim 13.

15. Intercepting a write command to a process control device issued by a first user, including intercepting a write command to a process control module of the process control device. The method according to any one of claims 1 to 14.

16. A system for permitting a write command to a process control device within a process control system, the process control system including at least one controller, one field device, and a workstation communicatively coupled to the at least one controller and the one field device. Communicatively coupled to a user manager database, adapted to receive a request for profile information based on an identifier, and respond with a user profile including a user identifier, a group identifier, a set of permissions, a biometric identifier, and at least one relationship identifier. Here, the relationship identifier is a user manager component that identifies the type of relationship between a first user and a second user for the second user to verify a write command. A workstation adapted to receive data from the process control device and display it to a user, and transmit a write command to the process control device based on an input received from the user, executing a control application of the process control system. A security component communicatively coupled to the workstation and the user manager component. Intercepting the write command initiated from the workstation before the write command can be executed by the process control device. Transmitting a request for the profile of the second user to the user manager component based on the relationship identifier of the first user. Prompting the second user to verify the write command. Receiving a biometric input of the second user. Verifying the write command by determining whether the biometric input of the second user matches the biometric identifier of the second user profile, A security component adapted to release the write command for execution on the process control device when a match is determined between the biometric input of the second user and the biometric identifier within the profile of the second user, a system comprising.

17. The security component of claim 16, further adapted to determine the current device of the second user and transmit a prompt to the current device of the second user, wherein the current device of the second user is different from and remote from the workstation. The described system.

18. The system of claim 17, wherein the user manager component is further adapted to store information about the current user device.

19. Further comprising an active directory database communicatively coupled to the workstation, the user manager database being adapted to combine fields from the active directory database to form a user manager table including at least relationship identifiers. The system according to any one of claims 16 to 18.

20. The user manager component is adapted to assign at least one relationship identifier value to each user upon activation of the user's account, the at least one relationship identifier value referring to another existing user profile within the user manager database. The system according to any one of claims 16 to 19.

21. The system according to any one of claims 16 to 20, wherein the relationship identifier of the user profile is the biometric identifier of the second user.

22. Further comprising an event recording database communicatively coupled to the security component and adapted to store the biometric input of the first user, the biometric input of the second user, and the parameters of the write command. The system according to any one of claims 16 to 21.

23. The system according to any one of claims 16 to 22, wherein the control application is one of an operator control program adapted to make runtime changes to a process control device or an engineering configuration program adapted to change a control module of a process controller of the process control system.

24. A method for permitting a write command to a process control device within a distributed process control system (DCS), the DCS including at least one controller, one field device, and a workstation communicatively coupled to the at least one controller and the one field device, the process control device being the at least one controller or the one field device, the method comprising: intercepting, by one or more processors, a write command to the process control device initiated by a first user of a first workstation; receiving, by the one or more processors, a biometric input of the first user; receiving, by the one or more processors, a biometric input of a second user; authenticating, by the one or more processors, the first and second users based on the biometric inputs of the first and second users respectively; determining, by the one or more processors, whether the biometric input of the second user matches a relationship identifier of a user profile of the first user, wherein the relationship identifier identifies a type of relationship required for the second user to verify the write command; releasing, by the one or more processors, the intercepted write command for execution by the process control device when the first and second users are authenticated and the biometric input of the second user matches the relationship identifier of the user profile of the first user.

25. Further comprising querying, by the one or more processors, a user manager database for the user profile of the second user based on a relationship identifier of the user profile of the first user, wherein each user profile in the user manager database includes at least a user identifier, a group identifier, a set of permissions, at least one relationship identifier, and a biometric identifier, the method of claim 24.

26. Further comprising displaying, by the one or more processors, a prompt for verifying the write command to both the first user and the second user without displaying the identifier of the first user or the second user, wherein verifying the write command includes authenticating the first and second users based on the biometric inputs of the first and second users, the method of claim 24 or claim 25.

Images