Secure off-site access to process control data by mobile devices

Abstract

A system and method for facilitating secure communication between a process control application executing on a mobile device and a mobile server communicatively coupled to a process control environment includes instantiating a relay connection element in a cloud-based environment. Each of the mobile server and any mobile applications executing on the mobile device authenticate themselves to the relay connection element. Each of the relay connection element, the process control application executing on the mobile device, and the mobile server receive necessary credentials through a series of authenticated requests between various elements in the cloud-based environment, such that the elements in the system must authenticate themselves to one another before any information is provided to another element.

Description

Technical Field

[0001] This disclosure generally relates to mobile monitoring of process control environments, and more specifically, to systems and methods for securely authenticating mobile devices outside of the process plant environment to provide customizable, real-time awareness of process control systems on mobile devices. Background Technology

[0002] Distributed control systems (DCS) are used in a variety of process industries, including chemical, petrochemical, refining, pharmaceutical, food and beverage, power, cement, water and wastewater, oil and gas, pulp and paper, and steel, to control batch, feed-batch, and continuous processes operating in a single location or remotely. A process plant typically includes one or more process controllers that are communicatively coupled to one or more field devices via analog, digital, or combined analog / digital buses, or via wireless communication links or networks. These devices work together to perform monitoring, control, and data collection functions to control processes, safety shutdown systems, fire and gas detection systems, machine health monitoring systems, maintenance systems, decision support, and other systems.

[0003] Field devices can be, for example, valves, valve positioners, switches, and transmitters (e.g., temperature, pressure, level, and flow rate sensors). These field devices are located within the process environment and typically perform physical or process control functions, such as opening or closing valves, measuring process parameters, etc., to control one or more processes executing within a process plant or system. Intelligent field devices, such as those conforming to the well-known Fieldbus protocol, can also perform control calculations, alarm functions, and other control functions typically implemented within a controller. Process controllers, also typically located within the plant environment, receive signals indicating process measurements obtained from field devices and / or other information related to the field devices, and execute controller applications that run, for example, different control modules that make process control decisions, generate control signals based on the received information, and communicate with field devices (such as…). and The control modules or blocks being coordinated in the Fieldbus field device. The control modules in the controller send control signals to the field device via communication lines or links, thereby controlling the operation of at least a part of the process plant or system.

[0004] Information from field devices and controllers is typically made available via high-speed data channels to one or more other hardware devices (e.g., operator workstations, personal computers or computing devices, data history repositories, report generators, centralized databases, or other centralized management computing devices), usually located in a control room or elsewhere away from harsher plant environments. Each of these hardware devices is typically centralized across the entire process plant or a portion thereof. These hardware devices run applications that, for example, enable operators to perform functions related to controlling processes and / or operating the process plant, such as changing the settings of process control routines, modifying the operation of control modules within controllers or field devices, viewing the current status of the process, viewing alarms generated by field devices and controllers, simulating process operation for training personnel or testing process control software, maintaining and updating configuration databases, etc. The high-speed data channels used by hardware devices, controllers, and field devices can include wired communication paths, wireless communication paths, or a combination of wired and wireless communication paths.

[0005] As an example, the DeltaVTM control system sold by Emerson Process Management includes applications stored in and executed by different devices located at different locations within the process plant. Configuration applications residing in one or more workstations or computing devices enable users to create or modify process control modules and download these modules to dedicated distributed controllers via high-speed data channels. Typically, these control modules consist of interconnected function blocks, which are objects in an object-oriented programming protocol. These function blocks perform functions within the control scheme based on inputs to them and provide outputs to other function blocks within the control scheme. Configuration applications also allow configuration engineers to create or modify operator interfaces, which are used by viewing applications to display data to operators and enable operators to change settings within process control routines, such as setpoints. Each dedicated controller, and in some cases, one or more field devices, stores and executes a corresponding controller application that runs the control modules allocated and downloaded to it to achieve the actual process control functions. A viewing application, which can run on one or more operator workstations (or on one or more remote computing devices connected to the operator workstations and the data highway), receives data from the controller application via the data highway and displays that data to the process control system designer, operator, or user using a user interface. It can provide any of several different views, such as an operator's view, an engineer's view, a technician's view, etc. A data history log application is typically stored in and executed by a data history log device that collects and stores some or all of the data provided via the data highway. A configuration database application can run on another computer attached to the data highway to store the current process control routine configuration and associated data. Alternatively, the configuration database can reside on the same workstation as the configuration application.

[0006] In many distributed process control systems, a unique device tag is assigned to each field device in the process plant. This unique device tag provides a simple way to reference the corresponding field device. During the configuration of the process control system, device tags can be used to specify the source or destination of inputs or outputs to function blocks within the control module. Each signal type is associated with a specific format or set of information, and a device tag for a specific device can be associated with a specific signal type so that when a device tag is associated with an input or output of a function block, the function block knows the format and information associated with the signal. In cases where a field device has multiple signals associated with it (e.g., a valve can measure and transmit both pressure and temperature), a device signal tag can be associated with each signal of the field device.

[0007] Traditionally, access to process control system data has been available only in process plant settings and / or when using equipment connected to a high-speed data channel that couples operator workstations, controllers, data history repositories, and other devices. Security is a particular concern with process control systems, and therefore, process control system operators typically physically isolate them from external network environments (e.g., the internet) to limit or prevent external actors from damaging the process control system, affecting product quality or viability, or accessing or stealing proprietary information.

[0008] Recently, mobile solutions have emerged that allow users to view information from process control systems via mobile devices such as smartphones, even when the mobile devices are not directly coupled to the process network and high-speed data channels that make up the process plant. One such mobile solution is DeltaV from Emerson Process Management. TM Mobile applications. While this solution allows users to access various data from the process plant in real time, both inside and outside the process plant, in practice, access to this data from outside the process plant is severely restricted and / or limited to one-way communication from the process plant to mobile devices, at least because a sufficient authentication process has not been implemented in the complex context of the process control environment, in order to prevent malicious attacks and / or command injection into the process control environment. That is, previous systems required a mobile server to receive requests at a publicly available application-layer endpoint, which is undesirable due to the aforementioned security-related reasons. Summary of the Invention

[0009] In one embodiment, a cloud-based authentication method includes instantiating a relay element in a cloud-based server, the relay element being configured to transmit data between a process control application executing on a mobile device and a mobile server communicatively coupled to the process control environment. The relay element is communicatively coupled to the mobile device and the mobile server, for example, via the Internet. The authentication method includes receiving a first authentication key from the process control application executing on the mobile device at the relay element, and comparing the first authentication key with an application authentication key at the relay element. If the first authentication key matches the application authentication key, the relay element authenticates the process control application; and if the first authentication key does not match the application authentication key, the process control application's access to the relay element is denied. The method further includes receiving a second authentication key from the mobile server at the relay element, and authenticating the mobile server at the relay element if the second authentication key is valid. Thereafter, the method includes allowing communication between the process control application executing on the mobile device and the mobile server via the relay element if both the process control application and the mobile server are authenticated.

[0010] In other embodiments, a method for providing process control data to a process control application operating on a mobile device includes sending a command from a mobile server communicatively coupled to the process control environment to an application web service API operating on a cloud-based server to instantiate a relay element in the cloud-based server, the relay element being configured to transmit data between the process control application and the mobile server. The method includes sending an authentication key to the relay element via a relay gateway service, the authentication key being usable to authenticate the mobile server to the relay element, and receiving a username and password associated with a user of the process control application from the process control application via the relay element and the relay gateway service. The method further includes authenticating the user of the process control application, and sending a list of available process control data to the process control application via the relay element and the relay gateway service. Thereafter, the method includes receiving a selection of process control data to be transmitted from the process control application via the relay element and the relay gateway service; and sending the selected process control data to the process control application via the relay element and the relay gateway service.

[0011] In one embodiment, a system for providing secure off-premises access to a process control environment for a process control application includes a mobile server communicatively coupled to the process control environment and configured to (i) receive real-time process control data from the process control environment and (ii) send control commands to a controller in the process control environment. The system also includes a cloud-based server environment communicatively coupled to the mobile server via a relay gateway service. The cloud-based server environment further includes a cloud-based relay element configured to transmit data between the process control application running on the mobile device and the mobile server. A first application programming interface (API) of the cloud-based server environment is configured to receive requests from the mobile server to instantiate and enable the cloud-based relay element. A second API of the cloud-based server environment is configured to receive requests from the process control application to access the cloud-based relay element, authenticate the user of the process control application, and provide the process control application with a first authentication key for accessing the cloud-based relay element. The relay management database of the cloud-based server environment stores configuration information for the cloud-based relay elements. The keystore element of the cloud-based server environment stores authentication keys. The system includes a first network coupling the mobile server to the process control environment, a second network coupling the mobile server to the cloud-based server environment, and a third network coupling the process control application to the cloud-based server environment. Attached Figure Description

[0012] The features and advantages of the methods, apparatus, and systems described herein will be best understood by referring to the following detailed embodiments and accompanying drawings, wherein:

[0013] Figure 1 This is a block diagram of an exemplary process control environment according to this specification;

[0014] Figure 2 A block diagram illustrating the overall architecture of a system for distributing mobile information in a process control environment, as exemplified in this specification, is shown.

[0015] Figure 3 It is a block diagram illustrating the various components and methods involved in a security authentication system, as well as the information flow between these components;

[0016] Figure 4 It is a communication flowchart illustrating a method for allowing a mobile server to create, enable, disable, or modify relay elements;

[0017] Figure 5 This is a communication flowchart illustrating the method of authenticating a mobile server to a relay element;

[0018] Figure 6 This is a communication flowchart illustrating a method for authenticating mobile applications to relay elements; and

[0019] Figure 7 It is shown Figure 6 The communication flowchart of the sub-method of the method for authenticating the mobile server to the relay element. Detailed Implementation

[0020] As described above, known distributed process control systems lack the ability for operators, maintenance personnel, and other personnel associated with the process control system to securely maintain situation awareness when physically located away from operator workstations and / or the process plant. Consequently, plant personnel cannot observe the operation of the process control system and the process plant unless they are physically present, or, due to the lack of robust authentication protocols, they cannot securely send control commands to the process control system when not physically present at the process plant. Since process plants typically operate in multiple shifts, observation and operation of the process plant are often switched multiple times per day. While plant personnel on a particular shift can keep records for those on subsequent shifts, these shift changes lead to discontinuities in the operation and management of processes and equipment, which can have detrimental effects on product quality, plant efficiency, maintenance, environmental safety, regulatory compliance, and other aspects of process plant management. The implementation of the systems, devices, and methods for secure authentication of mobile devices described herein can facilitate secure access to information, secure transmission of control commands, confirmation of alarms or events, and other mobile-to-process communications, the advantages of which will become apparent in the following disclosure.

[0021] Figure 1 An exemplary process plant network 10 is illustrated, including a mobile services infrastructure 12 for supporting multiple mobile devices 14 that do not necessarily reside at the process plant site and can access data associated with the process plant. As will be described in detail herein, the mobile services infrastructure 12 facilitates real-time, secure one-way or two-way communication between the mobile devices 14 and the process plant network 10, including communication of any process plant data available within the process plant network 10, and communication of commands and other data from the mobile devices 14 to the process plant network 10, while maintaining the security of the process plant network 10. Each mobile device 14 includes an application 16 and other components, which can be executed by the mobile device 14 to allow a user to interact with process plant data via a graphical user interface (GUI) 18. As described below, the mobile services infrastructure 12 includes an architecture for secure authentication of mobile devices.

[0022] Typically, plant personnel use one or more applications 20 to monitor or control the operation of process plant 10 and the distributed control system 22 implemented in process plant 10. Viewing or monitoring applications 20 typically include user interface applications that use various different displays to graphically depict the process to each operator and maintenance technician and / or other users at workstations (e.g., workstations 30 and 32).

[0023] Figure 1 The process plant environment also includes a graphical configuration system 34. The graphical configuration system 34 typically facilitates the creation of control and monitoring schemes for controlling the process plant, including graphical displays. The graphical configuration system 34 may include, for example, a configuration editor 35, which can be used for control modules and control module templates, graphical displays and templates, and other aspects of the control system, stored in a library and subsequently used to create instances or uses that are actually executed in the control of the process plant during operation of the plant 10, either by downloading instances of control modules to the controller or by executing instances of graphical displays in user displays presented to, for example, operators and maintenance personnel. Of course, the graphical configuration system 34, the configuration editor 35, and each of the various control modules, templates, and graphical displays can be stored in tangible computer-readable storage or media and executed on one or more processors to perform the functions described herein.

[0024] Typically, Figure 1 The distributed process control system 22 shown has one or more controllers 40, each controller connected to one or more field devices 44 and 46 (which may be smart devices) via input / output (I / O) devices or cards 48, which may be, for example, Fieldbus interfaces, Profibus interfaces, HART interfaces, standard 4-20mA interfaces, etc. Controllers 40 are also coupled to one or more host or operator workstations 30-32 via a high-speed data channel 54 (e.g., an Ethernet link). A process database 58 can be connected to the high-speed data channel 54 and operates to collect and store process variables, process parameters, status, and other data associated with controllers, field devices, and any other devices within the plant 10. During operation of the process plant 10, the process database 58 can receive process data from controllers 40 and indirectly from field devices 44-46 via the high-speed data channel 54.

[0025] Configuration database 60 stores the current configuration of the distributed control system 22 within process plant 10, such as configurations downloaded to controller 40 and field devices 44, 46 and stored within controller 40 and field devices 44, 46. Configuration database 60 stores process control functions defining one or more control strategies for distributed control system 22, configuration parameters of devices 44, 46, allocation of devices 44, 46 to process control functions, and other configuration data related to process plant 10. Configuration database 60 may additionally store graphical objects or user displays and configuration data associated with these objects or displays, as described in more detail herein, to provide various graphical representations of elements within process plant 10. Some stored graphical objects may correspond to process control functions (e.g., process graphics developed for a PID loop), while other graphical objects may be device-specific (e.g., graphics corresponding to pressure sensors).

[0026] Data history repository 62 (another database) stores events, alarms, notes, and actions taken by operators. Events, alarms, and notes may relate to individual devices (e.g., valves, transmitters), communication links (e.g., wired Fieldbus segments, WirelessHART communication links), or process control functions (e.g., PI control loops used to maintain a desired temperature setpoint). Additionally, knowledge base 64 stores references, operator login entries, help topics, or links to these and other documents that operators and maintenance technicians can find useful when supervising process plant 10. Furthermore, user database 66 stores information about users such as operators and maintenance technicians. For each user, user database 66 may store, for example, his or her organizational role, the user's scope of control, the area in process plant 10 associated with the user, workgroup association, safety information, system permissions, shift information, etc.

[0027] Each of the databases 58-66 can be any desired type of storage or collection unit having any desired type of memory for storing data and any desired or known software, hardware, or firmware. Of course, databases 58-66 do not need to reside in a separate physical device. Therefore, in some embodiments, some of the databases 58-66 can be implemented on a shared data processor and memory. Typically, more or fewer databases can also be used to store data... Figure 1 The databases 58-66 in the exemplary system jointly store and manage the data.

[0028] While controllers 40, I / O cards 48, and field devices 44, 46 are typically located in sometimes harsh plant environments and distributed throughout the plant, operator workstations 30 and 32, as well as databases 58-66, are typically located in control rooms or other less harsh environments easily accessible to controllers, maintenance personnel, and various other plant staff. However, in some cases, handheld devices coupled to the high-speed data channel 54 can be used to perform these functions, and these handheld devices are typically carried throughout the plant. Such handheld devices, and in some cases operator workstations and other display devices, can be connected to the DCS 22 via wireless communication. The difference between handheld devices and mobile devices 14 is that mobile devices do not need to be located in the process plant area and do not need to be directly coupled (via wired or wireless means) to the high-speed data channel 54.

[0029] As is known, each controller has 40 units, for example, the DeltaV sold by Emerson Process Management. TM The controller stores and executes controller applications that use any number of different, independently executed control modules or blocks 70 to implement control strategies. Each control module 70 may consist of what are commonly referred to as function blocks, where each function block is a part or subroutine of an overall control routine and operates together with other function blocks (via communication known as a link) to implement a process control loop within the process plant 10. Function blocks, which are known to be objects in object-oriented programming protocols, typically perform one of the following: input functions, such as input functions associated with transmitters, sensors, or other process parameter measuring devices; control functions, such as control functions associated with control routines that perform PID, fuzzy logic, or other control; or output functions, controlling the operation of devices such as valves to perform some physical function within the process plant 10. Of course, there are hybrid and other types of complex function blocks, such as model predictive controllers (MPCs), optimizers, etc. Although the Fieldbus and DeltaV system protocols use control modules and function blocks designed and implemented using object-oriented programming protocols, control modules can be designed using any desired control programming scheme (including sequential function blocks, ladder logic, etc.), and are not limited to using function blocks or any other specific programming techniques. Each controller 40 can also support [products / services] sold by Emerson Process Management. Application groups can use predictive intelligence to improve the availability and performance of production assets, including mechanical equipment, electrical systems, process plants, instruments, non-intelligent and intelligent field devices 44, 46, etc.

[0030] As described, DCS 22 includes one or more controllers 40 communicatively coupled to workstations 30, 32 in the control room. Controllers 40 automate the control of field devices 44, 46 in the process area by executing process control strategies implemented via workstations 30, 32. An exemplary process strategy involves using pressure sensor field devices to measure pressure and automatically sending commands to valve positioners to open or close flow valves based on the pressure measurements. I / O cards 48 convert information received from field devices 44, 46 into a format compatible with controllers 40, and convert information from controllers 40 into a format compatible with field devices 44, 46.

[0031] Through I / O card 48, controller 40 can communicate with field devices 44, 46 based on control module 70 that has been downloaded to controller 40. Control module 70 is programmed using configuration system 34. In configuration system 34, an engineer can create control module 70 by, for example, instantiating one or more function blocks. As an example, a configuration engineer can instantiate an AI function block to receive analog input from one of the field devices 44, 46. The AI ​​function block can receive various values ​​(e.g., signal values, alarm high and low limits, signal status, etc.) associated with the analog output of field device 44, 46. The AI ​​function block can output corresponding signals to another function block (e.g., a proportional-integral-derivative (PID) control function block, a custom function block, a display module, etc.). Once the AI ​​function block is instantiated, associating the function block with a unique device tag associated with field device 44, 46 will cause the function block to cooperate with the appropriate I / O card 48 to process information from the current field device 44, 46 once it is downloaded to controller 40.

[0032] exist Figure 1 In the factory network 10 shown, the field devices 44 and 46 connected to the controller 40 can be standard 4-20mA devices or intelligent field devices (e.g., those including processors and memory). Profibus or Fieldbus field devices), or any other desired type of device. Some of these devices, such as Fieldbus field devices (in...), can be... Figure 1 (Referring to 46 in the accompanying drawings), modules or sub-modules (e.g., function blocks) can store and execute modules or sub-modules associated with the control strategy implemented in controller 40 or performing other actions (e.g., data collection, trend analysis, alarms, calibration, etc.) in the process plant. As is known, in Figure 1The function block 72, shown as being located in two different Fieldbus field devices 46, can be executed in conjunction with the execution of the control module 70 within the controller 40 to achieve process control. Of course, the field devices 44 and 46 can be any type of device (e.g., sensors, valves, transmitters, positioners, etc.), and the I / O device 48 can be any type of I / O device conforming to any desired communication or controller protocol (e.g., HART, Fieldbus, Profibus, etc.).

[0033] Continue to refer to Figure 1 Workstations 30 and 32 can include various applications for different functions performed by personnel within factory 10. Each workstation in workstations 30 and 32 includes a memory 80 for storing various applications, programs, data structures, etc., and a processor 82 for executing any applications stored in the memory 80. Figure 1 In the example shown, in addition to display and view application 20, workstation 30 includes one or more process controller configuration applications 84, which may include, for example, control module creation applications, operator interface applications, and other data structures accessible to any authorized configuration engineer to create control routines or modules (e.g., control modules 70 and 72) and download them to the various controllers 40 and devices 46 of plant 10. Configuration application 84 also includes a display or graphical configuration system 34 with a configuration editor 35, which can be used to create control module 70.

[0034] In a broader sense, the viewing application 20 allows operators to view display modules configured to provide specific information about the operation of specific areas of process plant 10 and to control the operation of process plant 10 based on the information on the display modules. The display modules are presented on workstations 30, 32 and incorporate real-time process data received from controller 40 and field devices 44, 46. As used herein, “real-time” data communication refers to electronic communication of data over an electronic communication network, which has normal latency for processing, routing, and transmission, without intentionally introducing additional, non-negligible latency. In some embodiments, a small latency of less than five seconds (and preferably less than two seconds) may be introduced to reduce network congestion when transmitting data in real time. The display modules can be any type of interface that, for example, enables operators or other users to manipulate data values ​​(e.g., perform reads or writes) to monitor or change the operation of field devices 44, 46, control modules 70 and function blocks 72, and DCS 22, as well as process plant 10 as a whole. The display modules may be stored in the memory 80 of workstations 30, 32 and may also be stored in configuration database 60.

[0035] The control module 70 and, in some embodiments, the display module, may be part of the configuration file 74 in the configuration database 60. That is, the control module 70 may be stored in the configuration file 74 together with or separately from the display module. In any case, the configuration file 74 generally stores the entire configuration of the DCS 22, including devices, device labels, user-friendly names, data formatting information (e.g., scaling information, unit type, etc.), whose variables are associated with each control loop, defined control strategies, etc. As previously noted, the configuration file 74 may also be downloaded to the controller 40 to implement the control strategies defined in the configuration file 74.

[0036] As will be understood, process plant 10 may include hundreds, thousands, or even tens of thousands of signals output from and / or input to hundreds or thousands of field devices 44, 46, from transmitters (i.e., sensors), to cause the field devices 44, 46 to perform control functions according to control strategies programmed into control module 70. Plant 10 may be divided into different zones, multiple zones of which may be controlled by a single controller 40, where each zone may be controlled by a single controller or multiple controllers 40, or some combination thereof. In any case, the field devices 44, 46 that make up process plant 10 may be individually replicated multiple times within process plant 10 (e.g., there may be many valves of any type, many pumps, many heaters, many tanks, etc.). Field devices 44, 46 may also be grouped into functional groups within physical areas (“process areas”), where field devices 44, 46 in the process area perform a specific part of the overall process. For example, a particular process area may have equipment for generating steam for other parts of the process. Within a process area, there may be multiple repeating devices or groups of devices (“process units”) that share similar structures and functions. As an example, a process unit in a steam generation process area may include a boiler and a turbine generator, and the process area may include multiple instances of that process unit.

[0037] System Architecture

[0038] Now go to Figure 2 The block diagram illustrates the overall architecture 152 of a system for mobile information distribution in a process control environment, including an authentication service architecture for authenticating mobile devices 14 and other components of the overall architecture 152 as described herein. Architecture 152 is described for the purpose of contextualizing the authentication service architecture described herein. Architecture 152 is typically divided into three layers: a plant / process layer 154, a data service layer 156, and a mobile service layer 158, which together comprise four to six different networks. The plant / process layer 154 includes a field network that couples the controller 40 to field devices 44, 46. Figure 2(not shown in the image), and the control network that couples controller 40 to workstations 30, 32, databases 58-66, and other components within the process control plant 10 (in... Figure 1 The data highway is shown as channel 54. Plant / process layer 154 may optionally include an intermediate network 160, which couples control network 54 to other business layer applications. Plant / process layer 154 is coupled to data service layer 156 via network 162. Data service layer 156 is coupled to mobile service layer 158 via network 164. Mobile service layer 158 includes one or more other networks, such as the Internet and / or mobile / data networks. Among other security measures, each of layers 154, 156, and 158, and indeed each network in the network, can be isolated from other layers by hardware and / or software firewalls. The layered architecture allows for isolation between various networks 54, 160, 162, 164, etc.

[0039] At the plant / process level 154, the communicator interface 170 provides an interface between the controller 40 and the process plant 10 on one side, and a data service level 156 on the other side. Although Figure 2 The single communicator interface 170 is shown communicating with a single controller 40 (and therefore a single process plant 10), but the communicator interface 170 can communicate with multiple controllers 40 controlling a single process plant, where different areas of the process plant 10 are controlled by separate controllers 40. It is contemplated that, in embodiments, multiple process control systems 10 can be coupled to data service layer 156 and mobile service layer 158 via multiple communicator interfaces 170. In one particular embodiment, the communicator interface 170 is coupled to each process control system 10, and a group of communicator interfaces 170 is coupled to data service layer 156. It is also envisioned that the multiple control systems may be physically located in different locations (e.g., in different chemical plants).

[0040] The communicator interface 170 may be part of a larger portal 171 that provides integrated interfaces to the data service tier 156 and the mobile service tier 158, respectively. Portal 171 may include functions such as facilitating the configuration of user information, device and system information, and software / hardware licenses.

[0041] Also in the plant / process level 154, file interface 172 is used to transfer configuration file 74 to data service level 156. In some embodiments, file interface 172 is part of a dedicated workstation in workstations 30, 32 for configuring process plant 10, and includes a graphical configuration system 34, a configuration editor 35, etc. In other embodiments, file interface 172 may be part of communicator interface 170. In any case, file interface 172 is coupled to data service level 156 and transfers configuration data of the process plant to data service level 156.

[0042] At data service level 156, data server 174 includes multiple different data services 176 that collectively receive data from communication interface 170 and file interface 172 and transmit the received data to mobile service level 158. Data received from plant / process level 154 and transmitted to mobile service level 158 includes alarms, process parameters, diagnostics, historical data, and configuration data. The various data services 176 can also be used to index configuration files 74 received from file interface 172. Indexing operations can include indexing specific information such as module parameters and module levels to support detailed search capabilities, allowing users to search for parameter names, device tags, alarms, or other data within process plant 10.

[0043] Mobile server 178 is the core of mobile service layer 158. Mobile server 178 supports connectivity to mobile device 14, supports the configuration of various lists subscribed to by mobile device 14 (e.g., alert lists, monitoring lists, etc.), provides search capabilities, and manages mobile notifications. Mobile server 178 is also responsible for creating and maintaining subscriptions to various data from data service 176. Mobile server 178 is coupled to mobile device 14 via any of a variety of wireless data technologies, which may include Wi-Fi (i.e., protocols of the IEEE 802.11 protocol suite) and / or mobile (“cellular”) infrastructure using any of a variety of currently or future data services, including but not limited to LTE services, some or all of which may utilize the Internet 180.

[0044] Mobile service layer 158 also includes an authentication service component 183, which will be described in more detail below. Mobile service component 183 includes a sub-architecture that communicates with mobile server 178 to perform various authentication services, including authentication of applications running on mobile device 14, mobile server 178, and other components in the embodiment.

[0045] Mobile device 14 may include mobile devices running the Android mobile operating system developed by Google, mobile devices running the iOS or iPadOS mobile operating systems developed by Apple, or any other operating systems currently known or to be developed in the future. For mobile devices 14 running Android, iOS, and / or iPadOS mobile operating systems, as will be readily understood by those skilled in the art of using such services, notifications can be delivered to mobile devices 14 via Apple or Google notification services 182. Mobile server 178 facilitates the configuration of notification services at the system level and / or the user level.

[0046] Regarding the configuration of mobile information distribution, mobile server 178 provides some configuration services via a mobile device interface inherent to mobile device 14. Mobile server 178 also provides configuration options via a web page (i.e., using a web browser). As will be understood (for example, consider U.S. Patent Application Publication No. 2018 / 0109651, the entire contents of which are incorporated herein by reference), various alarm lists and monitoring lists can be configured via the web interface using search (i.e., searching the index data of configuration file 74) and / or filters, and utilizing system hierarchy information, function classification, alarm priority, alarm category, etc.

[0047] The availability of configuration data at mobile service level 158 can be used to provide end users with a particularly rich mobile environment because the system can access not only the data but also the relationships between the data. Furthermore, in the embodiment implementing the security authentication protocol described herein, the process control system 10 can be controlled or otherwise interacted with in addition to being monitored. As an example, mobile server 178 can access the contextual relationships between data and data types through configuration data from configuration file 74, rather than simply having the state of an alarm (e.g., active) or the state of a parameter value (e.g., normal, high, low, etc.). Therefore, the system can determine that a particular active alarm is a result of a "high" parameter state, and further determine that the parameter state is "high" because the parameter data value exceeds a specific limit. Because mobile server 178 has this rich contextual information, the user interface can present data within this context; for example, alarms can be described using real-time data and history, or process variables can be described using current and historical setpoint values ​​and optionally related module relationships. This allows users to navigate from one piece of data to another related piece of data based on relationships between process control devices, function blocks, etc.

[0048] Furthermore, in a secure, authenticated environment, mobile server 178 can receive data and / or commands from mobile device 14 and can transmit commands and / or data back to data service level 156 and / or plant level 154. This contrasts with existing systems where data transmission back to plant level 154 is prohibited to ensure the security of process plant environment 10. That is, the requirement for one-way communication from plant level 154 to data service level 156 and / or mobile service 158 can be relaxed because mobile device 14 is securely authenticated as a recipient of such communication. Consequently, if control plant 10 is configured to allow such communication, the user of mobile device 14 can have alarm acknowledgments and control commands transmitted back to plant level 154.

[0049] Authentication service

[0050] Figure 2 The authentication service component 183 shown includes a sub-architecture having a component 183A local to the process control plant 10 in the mobile service tier 158 and a component 183B remote from the process control plant 10 and accessible via the Internet. Component 183B includes a graphical user interface (GUI) application (also referred to herein as a process control application) 200 executing on a mobile device 14, and various components that can be hosted on a cloud computing platform such as the Microsoft Azure cloud computing platform, and are referred to herein as “hosted components.” Hosted components, which will be described in more detail below, include a Relay Hybrid Connection (RHC) (also referred to herein as a Relay Element) 202, a Representative State Transition (REST) ​​Application Programming Interface (API) 204, a Relay Management API 206, a Relay Access API 208, a Relay Management Database 210, a Vault 212, and an Application Services Web API 214.

[0051] Component 183A includes a relay gateway service (RGS) 218 ​​communicatively coupled to mobile server 178. RGS 218 may be a software component executing on mobile server 178.

[0052] RHC 202 is responsible for facilitating secure communication via a secure communication channel between mobile application 200 and mobile server 178 using the Internet (including via wired, wireless, and / or cellular communication infrastructure). Specifically, RHC 202 can cooperate with RGS 218 to transfer data (including authentication data and process data) between mobile application 200 and mobile server 178. As described below, RHC 202 uses various authentication processes to create a secure communication channel that ensures proper authentication of each user of mobile server 178 and mobile application 200 to prevent unauthorized access to process control system 10.

[0053] REST API 204 consists of multiple APIs that manage RHC 202 and is responsible for generating and storing keys for both RHC 202 authentication mobile application 200 and mobile server 178. Specifically, REST API 204 generates and stores the sending key for RHC 202 authentication mobile application 200 and the listening key for RHC 202 authentication mobile server 178.

[0054] The Relay Management API 206 is responsible for creating, enabling, and disabling RHC 202 for various client sites. That is, the Relay Management API 206 can be a global component operating on a cloud computing platform; it is not an architecture specific to a particular process plant operator, but rather can alternatively create RHC 202 for various different process plants. The Relay Management API 206 can collaborate with the REST API 204 to manage RHC 202. The Relay Management API 206 is also responsible for providing RHC information and communicating with the Relay Management Database 210 to store RHC information.

[0055] Similarly, Relay Access API 208 is hosted on a cloud computing platform. Relay Access API 208 facilitates the initial access of mobile application 200 to RHC 202 and the establishment of a communication connection between mobile application 200 and mobile server 178. Specifically, Relay Access API 208 receives from mobile application 200 a request for an authentication token (described later in the section on "Sending Keys"), as well as the username and password of the person using mobile application 200. Relay Access API 208 assists in this request to verify that mobile application 200 is valid.

[0056] The relay management database 210 is also hosted on a cloud computing platform. The relay management database 210 is a general-purpose component that uses a secure off-premises architecture to store RHC information (address, connection status, etc.) for various customer sites.

[0057] Keystore 212 stores various access tokens and authentication credentials. These may include credentials for authenticating the application service web API 214 to the relay management database 210, credentials for authenticating the application service web API 214 to the REST API 204, credentials for authenticating the relay access API 208 to the relay management API 206, credentials for authenticating the relay management API 206 to the REST API 204, and so on.

[0058] Application Service Web API 214 is similarly hosted on a cloud computing platform. Application Service Web API 214 facilitates backend communication between Mobile Server 178 and the remaining components of Component 183B, and specifically, facilitates the setup of RHC 202 and Mobile Server 178's access to RHC 202. Application Service Web API 214 receives requests for authentication tokens (described later regarding "listening keys") from Mobile Server 178, and provides Mobile Server 178 with access to modify the operation of RHC 202 by, for example, enabling RHC 202, disabling RHC 202, changing the address of RHC 202, etc.

[0059] Figure 4 This is a communication flowchart illustrating the communication between various components in the system during the method 250 for authenticating mobile server 178 and setting up RHC 202. During operations that create, enable, disable, or otherwise modify RHC 202, mobile server 178 transmits the modification of RHC 202 to application service web API 214 (message 252). Application service web API 214 can respond to mobile server 178 with a request for authentication (message 254), in which case mobile server 178 can transmit system key 256 (message 256). In embodiments, the system key may be a license key or a portion thereof provided to mobile server 178 or associated with software or routines executing on mobile server 178. It should be understood that slight modifications are possible. Figure 4 As with the communication flows shown in other diagrams, some messages are combined. For example, message 252, in which mobile server 178 requests access to application service web API 214, can also include a system key to remove messages 254 and 256. These types of adjustments are well known in the art and can lead to additional efficiency.

[0060] Upon receiving the system key, the application service web API 214 can request credentials from the keystore 212, which grant the application service web API 214 access to the relay management database 210 (message 258). The keystore 212 may have already authenticated the application service web API 214, or in some embodiments, the keystore 212 may use Active Directory-managed identities to authenticate the application service web API 214. For example, managed identities may be enabled and created for the application service web API 214 when it is instantiated in a cloud-based platform, and the keystore 212 may rely on these managed identities to ensure that the application service web API 214 can securely access the keystore 212. In response to the request for credentials (message 258), the keystore 212 may send credentials for accessing the relay management database 210 to the application service web API 214 (message 260).

[0061] After receiving credentials for accessing the relay management database 210 from the keystore 212 (message 260), the application service web API 214 can transmit the credentials to the relay management database 210 (message 262), and in response, can receive a message confirming successful authentication (message 264). The application service web API 214 can then transmit the system key received from the mobile server 178 to the relay management database 210 (message 266), and in response, can receive confirmation from the relay management database 210 that the system key is authorized (message 268). The application service web API 214 can then transmit one or more requests for any actions related to RHC 202, including creating RHC 202 (which has already been set in the relay management database 210), enabling RHC 202, disabling RHC 202, and / or modifying RHC 202 (message 270). In response, the relay management database 210 may send an acknowledgment request and / or a message confirming the successful completion of the requested modification to the application service web API 214 (message 272). The application service web API 214 may forward the acknowledgment of the successful completion of the requested modification (message 274).

[0062] Once RHC 202 is created and executed on a cloud-based platform, Mobile Server 178 needs to be able to authenticate itself to RHC 202. Figure 5This is a communication flowchart illustrating the communication between various components in the system during method 300 for authenticating mobile server 178 to RHC 202. In an embodiment, this is initiated by a request for a listening key from relay gateway service 218 to mobile server 178 (message 302). As described above, the listening key is an authentication credential used to authenticate mobile server 178 to RHC 202 to ensure that mobile server 178 is authorized to access a secure channel to mobile application 200. In response to this request, mobile server 178 sends a request for the listening key to application service web API 2141 (message 304). In response to the request for the listening key (message 304), application service web API 214 sends a request for credentials to access REST API 204 to keystore 212 (message 306). As described above, keystore 212 may have already authenticated application service web API 214, or in an embodiment, keystore 212 may use Active Directory-managed identity to authenticate application service web API 214. For example, a managed identity can be enabled and created for the application service web API 214 when it is instantiated in a cloud-based platform, and the keystore 212 can rely on the managed identity to ensure that the application service web API 214 can securely access the keystore 212. In response to a request for credentials (message 306), the keystore 212 can send credentials for accessing the REST API 204 to the application service web API 214 (message 308).

[0063] Upon receiving credentials for accessing REST API 204, application service web API 214 can send the REST API credentials to REST API 204 (message 310), which can respond to application service web API 214 with a message confirming successful authentication (message 312). Application service web API 214 can then send a request for a listening key to REST API 204 (message 314), in response to which REST API 204 can send the listening key to application service web API 214 (message 316). Of course, certain messages can be combined. For example, application service web API 214 can request the listening key at the same time as it sends the REST API credentials, and REST API 214 can send an authentication confirmation at the same time as, for example, the listening key. Application service web API 214 can send the listening key back to mobile server 178 (message 318), which can then send the listening key to relay gateway service 218 (message 320). Relay gateway service 218 can then send the listening key to RHC 202 (message 322). RHC 202 is programmed using its listening key when it is instantiated / created. Therefore, when RHC 202 receives the correct listening key from mobile server 178 via relay gateway service 218, RHC 202 authenticates mobile server, after which mobile server 178 can communicate with mobile application 200 via relay gateway service 218 and RHC 202 (message 324).

[0064] HTTPS is typically used to transmit the listening key and any other data transmitted between the mobile application 200 and the relay gateway service 218. The listening key may include a request header containing an identity server authentication token and a cloud platform token. The HTTP request and response bodies may include data in JavaScript Object Notation (JSON) format.

[0065] Figure 6This is a communication flowchart illustrating the communication between various components in the system during method 350 for authenticating mobile application 200 to RHC 202. To establish a connection to RHC 202, mobile application 202 sends an access request (message 352) to Relay Access API 208. Relay Access API 208 can request authentication information from mobile application 200 (message 354), in response to which mobile application 200 can send the username and password associated with the user of mobile application 200, and the URL of RHC 202 (message 356), to Relay Access API 208. In an embodiment, the URL of RHC 202 may take the form https: / / {relay namespace}.{cloud platform namespace} / {hybrid connection name}. As an example, the URL referring to a specific RHC 202 could be https: / / Relay-65.servicebus.windows.net / HC100. Relay Access API 208 can send the URL received from mobile application 200 (message 358) to Relay Management API 206, and in response, can receive information about RHC 202 from Relay Management API 206 (message 360).

[0066] After acquiring the information from RHC 202, Relay Access API 208 can transmit the username and password information received from mobile application 200 to RHC 202 (message 362). RHC 202 can then transmit the username and password information to Relay Gateway Service 218 (message 364), which in turn can transmit the username and password information to mobile server 178 (message 366). Mobile server 178 authenticates the username and password and transmits an authentication message to Relay Gateway Service 218 confirming that the username and password are valid (if they are actually true) (message 368). Relay Gateway Service 218 forwards the message to RHC 202 (message 370), which in turn forwards the message to Relay Access API 208 (message 372).

[0067] After verifying the identity of the user of mobile application 200, relay access API 208 can now request a transmission key for mobile application 200. As mentioned above, the transmission key is an authentication credential used by RHC 202 to prove that application 200 is authorized to access the secure channel used to communicate with mobile server 178. (See reference) Figure 7Relay Access API 208 may send a request for a transmission key to Relay Management API 206 (message 374). Relay Management API 206 may request authentication information from Relay Access API 208 (message 376). Relay Access API 208 may send a request for corresponding credentials to Keystore 212 (message 378). Keystore 212 may have already authenticated Relay Access API 208, or in embodiments, Keystore 212 may use Active Directory-managed identities to authenticate Relay Access API 208. For example, managed identities may be enabled and created for Relay Access API 208 when it is instantiated in a cloud-based platform, and Keystore 212 may rely on managed identities to ensure that Relay Access API 208 can securely access Keystore 212. In response to the request for credentials (message 378), Keystore 212 may send the requested credentials to Relay Access API 208 (message 380).

[0068] Upon receiving the requested credentials, Relay Access API 208 can send the credentials to Relay Management API 206 (Message 382), which can verify the authentication (Message 384). Relay Access API 208 can then send the URL of RHC 202, for which it is requesting the sending key, to Relay Management API 206 (Message 386).

[0069] To authenticate using REST API 204, Relay Management API 206 can send a request (message 388) to Keystore 212 for credentials to authenticate Relay Management API 206 to REST API 204. Keystore 212 may have already authenticated Relay Management API 206, or in some embodiments, Keystore 212 may use Active Directory-managed identities to authenticate Relay Management API 206. For example, managed identities may be enabled and created for Relay Management API 206 when it is instantiated in a cloud-based platform, and Keystore 212 may rely on managed identities to ensure that Relay Management API 206 can securely access Keystore 212. In response to the request for credentials (message 388), Keystore 212 can send the requested credentials to Relay Management API 206 (message 390).

[0070] With the requested credentials, Relay Management API 206 can send the credentials to REST API 204 (message 392), and in response, can receive an authentication confirmation message from REST API 204 (message 394). Upon receiving the authentication confirmation, Relay Management API 206 can send a request for a sending key to REST API 204 (message 396), and in response, REST API 204 can send the requested sending key to Relay Management API 206 (message 398). Relay Management API 206 can then forward the sending key to Relay Access API 208 (message 400).

[0071] Refer again Figure 6 Upon receiving the sending key (message 400), the relay access API 208 can send the sending key to the mobile application 200 (message 402). The mobile application 200 can then send the sending key to the RHC 202 (message 404). When instantiated / created in a cloud-based platform, the RHC 202 is programmed with its corresponding sending key, and when the sending key received from the mobile application 200 matches the sending key programmed into the RHC 202, the RHC 202 can authenticate the mobile application 200, and subsequently allow communication between the mobile application 200 and the mobile server 178 via the RHC 202 and the relay gateway service 218 (message 406).

[0072] Sending the key and any other data from the mobile application 200 to the RHC 202 typically uses the HTTPS protocol and may include a request header containing the identity server authentication token and the cloud platform token. The HTTP request and response bodies may include data in JavaScript Object Notation (JSON) format.

[0073] A specific user associated with mobile application 200 can cause a specific message to be allowed or disallowed, acknowledged or ignored by mobile server 178. In an embodiment, RHC 202 can provide mobile server 178 with information about the user (e.g., by associating a transmission key with the user). For example, mobile server 178 can associate mobile application 178 with a specific user and thus enable or disable user-specific actions such as: sending data associated with the user to application 200 (i.e., data streams that the user has previously requested and / or configured mobile server 178 to send to the user via mobile application 202), receiving process control commands from the user, recording commands received from the user, restricting the data sent and / or commands implemented in response to a specific user, etc.

[0074] As should be understood from this specification, a single instance of relay element 202 can facilitate communication between mobile server 178 and multiple or diverse mobile process control applications 200. In one embodiment, a single instance of relay element 202 can facilitate communication between one or more mobile servers 178 serving the entire process control facility and any number of instances of mobile process control applications 200 corresponding to personnel associated with maintaining and / or monitoring the process control facility. In other embodiments, a single instance of relay element 202 can facilitate communication between one or more mobile servers 178 serving a portion of the process control facility and any number of instances of mobile process control applications 200 corresponding to personnel associated with maintaining and / or monitoring the process control facility. Therefore, in various embodiments, relay element 202 can authenticate more than one mobile process control application 200 and / or can authenticate more than one mobile server 318.

Claims

1. A cloud-based authentication method, the method comprising: A relay element is instantiated in a cloud-based server and configured to transmit data between a process control application running on a mobile device and a mobile server communicatively coupled to a process control environment. The process control application running on the mobile device facilitates control of the process control environment, which includes a process controller that controls multiple process control field devices operating in the process control environment to generate products. At the relay element, a first verification key is received from the process control application executed on the mobile device, which is retrieved from a key store by a first intermediate service and provided to the process control application; In the relay element, the first verification key is compared with the application verification key, and (i) if the first verification key matches the application verification key, the process control application executed on the mobile device is authenticated, and (ii) if the first verification key does not match the application verification key, authentication of the process control application executed on the mobile device is rejected. At the relay element, a second authentication key is received from the mobile server and retrieved from the keystore by a second intermediate service and provided to the mobile server. If the second verification key is valid, then the mobile server is authenticated at the relay element; and If both the process control application and the mobile server are authenticated, communication between the process control application, which is executed on the mobile device, and the mobile server is permitted via the relay element.

2. The method according to claim 1, wherein, The first intermediary service includes a relay access API.

3. The method according to claim 1, further comprising: At the relay access API, receive the username and password associated with the user of the process control application executed on the mobile device; Receive the URL associated with the relay element at the relay access API; The user is authenticated at the relay access API based on the username and password; as well as If the user is authenticated, the first verification key is provided to the process control application running on the mobile device.

4. The method according to claim 3, wherein, Authenticating the user based on the username and password includes: The username and password are sent to the mobile server via a relay gateway service; and The user is received from the mobile server via the relay gateway service as an indication that the user has been authenticated.

5. The method according to claim 1, wherein, Communication between the process control application executed on the mobile device via the relay element and the mobile server includes: Receive one or more process control commands from the process control application running on the mobile device; and The one or more process control commands are forwarded to the mobile server via a relay gateway service.

6. The method according to claim 1, wherein, Communication between the process control application executed on the mobile device via the relay element and the mobile server includes: Receive process data from the process control environment from the mobile server via a relay gateway service; and The process data is forwarded to the process control application running on the mobile device.

Images