Systems, methods, and apparatus that enhance process control with a virtual assistant

Abstract

To provide systems, methods, and apparatus to augment process control with a virtual assistant.SOLUTION: An apparatus to augment process control with a virtual assistance 100, upon execution of a command, determines a process control context based on a request for information associated with field devices 116 and 118 of a process control system, identifies a topic included in the request to map the topic to an action to be executed by the field device, generates a command to direct the field device to execute the action based on the mapping, and transmits the command to the field device to execute the action. Upon the execution of the command, a conversation state is established based on the topic.SELECTED DRAWING: Figure 1A

Description

Technical Field

[0001] The present disclosure generally relates to process control systems, and more specifically, to systems, methods, and apparatuses for enhancing process control by a virtual assistant.

Background Art

[0002] In recent years, process control systems, such as those used in chemical, petroleum, and / or other processes, have become increasingly complex with the rapid increase in field devices having enhanced processing capabilities for performing new and / or improved process control functions.

Summary of the Invention

Problems to be Solved by the Invention

[0003] Current generations of process control systems include a greater number of various field devices or field instruments for measuring and / or controlling different aspects of a process control environment. With the increasing automation in the process control environment, additional interaction opportunities via various media are provided to operators to facilitate the operation of the process control system.

Means for Solving the Problems

[0004] An exemplary apparatus disclosed herein for enhancing process control using a virtual assistant includes, at least one processor, memory for storing instructions, and executes instructions for causing at least one processor to determine a process control context based on the configuration of a process control system based on a request for information associated with a field device of the process control system; to identify a topic included in the request and corresponding to a field device based on the process control context; to map the topic to an action performed by the field device; to generate a command instructing the field device to perform an action based on the mapping; and to send the command to the field device to perform the action.

[0005] Exemplary methods disclosed herein for enhancing process control using a virtual assistant include: determining a process control context based on the configuration of a process control system based on a request for information associated with a field device of the process control system; identifying a topic included in the request and corresponding to a field device based on the process control context; mapping the topic to an action to be performed by the field device; generating a command instructing the field device to perform the action based on the mapping; and sending the command to the field device to perform the action.

[0006] An exemplary non-temporary computer-readable storage medium includes instructions that, when executed, cause a machine to determine a process control context based on the configuration of a process control system, based on a request for information associated with a field device of the process control system; identify a topic included in the request and corresponding to a field device based on the process control context; map the topic to an action to be performed by the field device; generate a command instructing the field device to perform an action based on the mapping; and send a command to the field device to perform the action. [Brief explanation of the drawing]

[0007] [Figure 1A] This is a schematic diagram of an exemplary virtual assistant that facilitates the operation of an exemplary process control system. [Figure 1B] This is a schematic diagram of the exemplary virtual assistant in Figure 1A, which is included in an exemplary wearable device that facilitates the operation of the exemplary process control system in Figure 1A. [Figure 2] Figure 1A is a schematic diagram of an exemplary virtual assistant. [Figure 3] Figure 1A shows an exemplary table of exemplary profiles corresponding to the exemplary process tank of the exemplary process control system. [Figure 4] This is a schematic diagram of the first exemplary visualization corresponding to the exemplary profile in Figure 3. [Figure 5] This is a schematic diagram of a second exemplary visualization corresponding to the exemplary profile in Figure 3. [Figure 6] Figures 1A to 2 illustrate an example virtual assistant implementation, and are flowcharts representing machine-readable instructions that may be executed to generate and run scripts based on requests. [Figure 7] Figures 1A to 2 are flowcharts representing machine-readable instructions that may be executed to implement an exemplary virtual assistant and generate and display a visualization based on a request. [Figure 8] This is a block diagram of an exemplary processing platform configured to execute the instructions in Figures 6 and 7 in order to implement the exemplary virtual assistant in Figures 1A and 2.

[0008] The drawings are not to scale. Instead, the thickness of layers or areas may be enlarged in the drawings. Generally, the same reference number is used throughout the drawings and accompanying descriptions to refer to the same or similar parts. [Modes for carrying out the invention]

[0009] Process control systems, such as distributed control systems, are becoming increasingly complex as individual components are developed with improved data acquisition resolution, processing power, and signal conditioning capabilities. Distributed control systems (DCS) are used to monitor and / or control various aspects of operations performed in a process control environment, such as the manufacturing of components or the processing of chemical raw materials. A DCS typically includes multiple controllers (e.g., electronic controllers, programmable controllers, etc.) with attached input / output (I / O) modules, which allow the controllers to acquire signals from various input field devices and / or instruments and control various output field devices and / or instruments. I / O modules include inputs, outputs, and / or combinations thereof.

[0010] As used herein, the terms “field device,” “field instrument,” or “instrument” refer to control devices such as actuators, actuator assemblies, actuator controllers, actuator positioners, sensors, transmitters, valve assemblies, etc., which may be used throughout a process control system to measure and / or control different aspects of the process control system (e.g., other process control devices).

[0011] A typical DCS includes controllers, programmable processors, and / or logic circuits distributed throughout the process control environment, localizing control functions closer to the process control environment to enhance reliability and reduce installation costs, while enabling remote monitoring and supervision control of the process control environment. In some cases, operators, including engineers, maintenance technicians, or other field personnel, monitor the DCS remotely via the process control network or locally by physically interacting with controllers, field devices, etc. For example, an operator may connect to a field device via a wired or wireless connection to view process control data associated with the field device and / or components or devices communicatively coupled to the field device.

[0012] In some known DCS implementations, when interacting locally with a field device, the operator may have limited visibility to the field device and / or components or devices communicatively coupled to the field device. For example, if an operator is connected to a valve controller associated with a valve via a computer-based software application, they may only have access to limited data associated with the valve. In such an example, the operator may only be able to view limited data, such as actuator pressure or valve position. For example, if an operator is in a process control room, they may only be able to view limited data via a human-machine interface that displays limited data. In other examples, an operator may only be able to view limited data via a device communicatively coupled to the valve (such as a laptop computer, smartphone, or tablet), which may require additional expertise (such as establishing a communication connection or troubleshooting an unresponsive communication connection). In such an example, while the first operator is performing maintenance or troubleshooting work on the valve, the first operator may need the assistance of a second operator to view the limited data. For example, the first operator may not have their hands free to operate the device while attempting to perform one or more tasks associated with the valve.

[0013] In some known DCS implementations, operators cannot view associated and / or supplemental data related to valves, components or devices coupled to valves, and / or components associated with the control loop containing the valve. Supplemental data may include alarm data, action or task data (e.g., one or more actions or routines that are being performed or can be performed by the field device), and historical data. Furthermore, when performing maintenance on a field device and / or interacting with a field device, operators cannot obtain supplemental information from the field device, including process control diagrams, maintenance instructions, and wiring diagrams. In such examples, operators may have to leave the process control area to obtain supplemental information before returning to the process control area and complete tasks based on that information, which results in operational inefficiencies.

[0014] Examples disclosed herein include systems, methods, and apparatus that enable a user and / or a computer-based software application (e.g., a user interfaced with a computer-based software application) to initiate a conversation with a virtual assistant or bot (e.g., a process control bot) and assist an operator or user in tasks associated with process control. Examples disclosed herein facilitate user requests for information associated with a field device or process unit by returning corresponding process control values ​​and engaging with the user in a supportive or supplementary role.

[0015] In some disclosed examples, a user interacts with a virtual assistant when installed on an exemplary computing device such as a laptop computer, smartphone, or tablet. In some disclosed examples, a user interacts with a virtual assistant when installed on other exemplary computing devices, such as a wearable device such as a headset, wristband, or glasses, which includes one or more processors, one or more logic circuits, etc., for implementing the virtual assistant. In such disclosed examples, the virtual assistant may interact with field devices within range of a radio beacon, such as a Bluetooth® beacon or a Wi-Fi beacon. For example, a Wi-Fi beacon may be communicably coupled to one or more servers that facilitate requests from the virtual assistant. In such examples, if the virtual assistant is within range of the Wi-Fi beacon, it may request information associated with the field device within range of the Wi-Fi beacon by querying one or more servers via the Wi-Fi beacon. In some examples, in response to input to the Wi-Fi beacon's coverage area, the virtual assistant downloads information associated with the field device to improve the speed at which user requests associated with the field device are processed and communicated to the user.

[0016] In some disclosed examples, the virtual assistant receives a request from the user, parses the request for actionable information, and supports a set of actions or levels of information based on the actionable information. In some disclosed examples, the action includes providing a field device, or a component or device associated with a field device that is communicatively coupled to the field device, parameter values. In other disclosed examples, the action includes providing supplementary information such as the current process or task implemented and / or performed by the field device, step-by-step instructions for performing a task on or by the field device (e.g., a maintenance task, a task associated with a test plan), or the status of a process control task associated with the field device. In some examples, the action includes a process control workflow that comprises one or more process control operations that the user can start, stop, or pause via corresponding commands (e.g., commands via a computer-based application, voice-based commands).

[0017] Figure 1A is a schematic diagram of an exemplary virtual assistant (VA) 100 that facilitates the operation of an exemplary process control system 102. In Figure 1A, VA 100 is the process control virtual assistant. For example, VA 100 may be a computer-based or software agent that performs tasks or services for exemplary users (e.g., operators, maintenance technicians, process control operators, etc.) 104. In some examples, VA 100 interacts with multiple users 104. In some examples, VA 100 is a bot, chatbot, etc., which can be accessed, initialized, and / or otherwise interacted with via a computer-based or software application, voice commands, text-based commands, etc.

[0018] In the example shown in Figure 1A, VA100 searches for and / or retrieves requests from an exemplary host application 106 that operates on and / or runs on a device (e.g., a processor-based device) including a first exemplary device 108, a second exemplary device 110, a third exemplary device 112, and a fourth exemplary device 114. In Figure 1A, the host application 106 includes one or more routines (e.g., software routines) or programs (e.g., software programs) executed by machine-readable instructions. For example, the host application 106 could be a process control-related software application running on a standard operating system (e.g., a Windows®-based operating system, an Apple macOS® operating system, an Apple iOS® operating system, an Android® operating system, a Linux® operating system, etc.). The host application 106 is executed by devices 108, 110, 112, and 114, enabling user 104 to retrieve data or information associated with one or more field devices or corresponding operations included in the process control system 102 via VA100.

[0019] In some examples, host application 106 enables a user 104 to perform desired functions or tasks with respect to a process controlled and / or monitored by process control system 102, such as viewing the current state of the process (e.g., via a graphical user interface), evaluating the process, and modifying the operation of the process (e.g., via a visual object diagram). In some examples, host application 106 searches for one or more available commands from VA 100, selects one of the searched commands, and interacts with field devices included in process control system 102 via VA 100 to perform a desired function based on sending the command to the field device via VA 100. For example, user 104 may request that VA 100 perform a task, VA 100 may process the request, VA 100 may generate an audible message that describes and / or includes one or more available commands based on the processed request, user 104 may select one of the commands via a verbal confirmation or command, and VA 100 may send the command to one or more corresponding field devices.

[0020] In the example shown in Figure 1A, the first device 108 is a process control handheld device such as Emerson® AMS TREX® that can facilitate interaction with the process control system 102 via a host application 106 (e.g., via an integrated display, microphone and / or speaker). Alternatively, the first device 108 may be any other type of process control handheld or mobile device. In Figure 1A, the second device 110 is an internet-enabled tablet that can facilitate interaction with the process control system via a host application 106 (e.g., via an integrated display, microphone and / or speaker). In Figure 1A, the third device 112 is an internet-enabled mobile handset (e.g., a smartphone) that can thus facilitate interaction with the process control system 102 via a host application 106 (e.g., via an integrated display, microphone and / or speaker). In Figure 1A, the fourth device 114 is an internet-enabled laptop computer that can facilitate interaction with the process control system 102 via a host application 106 (e.g., via an integrated display, microphone, and / or speaker). Alternatively, VA100 may facilitate interaction with fewer or more devices of the number and / or types of devices shown in Figure 1A. Although the host application 106 is shown as being the same for each of the devices 108, 110, 112, and 114, alternatively, the host application 106 may be tailored and / or customized based on the platform. For example, the host application 106 running on the first device 108 may be different from the host application 106 running on the second device 110.In such examples, the host application 106 may have different user interfaces and different communication drivers to adapt to the corresponding platform (for example, the first device 108 may have Bluetooth® 5.0 and the second device 110 may have Bluetooth® 4.0). In some examples, the host application 106 may have no interface other than the voice user interface (VUI). For example, the VUI of the host application 106 may completely replace the keyboard, gestures from the user 104, etc.

[0021] In the example shown in FIG. 1A, user 104 and / or host application 106 may interact with VA100 via commands including auditory, audible, computer-based, gesture, or voice commands. Alternatively, any other type of command may be used. In some examples, user 104 issues a verbal request and / or requests data associated with field devices included in process control system 102, including first exemplary field device (field valve (FV) FV-105) 116 and second exemplary field device (field instrument (FI) FI- , from VA100. The first field device 116 of FIG. 1A is a flow control assembly. For example, the first field device 116 may be a valve assembly that operates electrically, hydraulically, and / or pneumatically. For example, the first field device 116 may include at least an actuator, a valve (e.g., butterfly valve, globe valve, etc.), a valve controller (e.g., local single-loop process controller), and the like. For example, user 104 may issue a verbal command to VA100 to request and / or retrieve data associated with the first field device 116, including actuator pressure, valve position, etc. Additionally or alternatively, it may trigger an interaction corresponding to any other type of field device other than those illustrated and / or described in connection with FIG. 1A. Additionally or alternatively, VA100 may request and / or retrieve any other data associated with the first field device 116 (e.g., wiring diagram including the first field device 116, software or communication protocol identifier of the first field device 116, firmware version associated with the controller included in the first field device 116, etc.).

[0022] In the example shown in Figure 1A, the second field device 118 is a sensor. For example, the second field device 118 could be a pressure transmitter, a temperature transmitter, etc. In other examples, the second field device 118 could be a level transmitter, a pH transmitter, a valve positioner, etc. For example, user 104 may issue a verbal command to VA 100 (e.g., "Virtual Assistant, tell me about FI-205") to request data associated with the second field device 118, including sensor measurements (e.g., pressure measurement, flow rate measurement, temperature measurement, etc.) in engineering units (e.g., pounds per square inch (PSI), degrees Celsius, etc.), non-engineering units (e.g., voltage measurement, current measurement, etc.), crude oil units, fluid catalytic cracking (FCC) units, etc., and / or combinations thereof. In other examples, verbal commands may include requests for calibration information (e.g., date of the last calibration, date of the next calibration, user who calibrated the sensor, etc.), configuration (e.g., communication protocol output address, electrical output range, etc.), manufacturer information (e.g., model number, serial number, etc.), version information (e.g., firmware version associated with the second field device 118), etc.

[0023] In some examples, user 104 and / or host application 106 query VA 100 for information associated with an exemplary control loop 120. In Figure 1A, the control loop 120 is a field device control (FIC) loop as specified by FIC-205. The control loop 120 in Figure 1A includes a first field device 116 and a second field device 118. The control loop 120 in Figure 1A corresponds to a controller (e.g., a PLC, processor-based controller, etc.) that takes input from the second field device 118 and / or generates an output signal to the first field device 116. Alternatively, the control loop 120 may include fewer or more field devices. In Figure 1A, the control loop 120 can operate the first field device 116 (e.g., open a valve, close a valve, move a valve to a specific position, etc.). In Figure 1A, the control loop 120 can take and / or take sensor data from the second field device 118 associated with the first field device 116. For example, the control loop 120 may instruct the first field device 116 to open and allow fluid to flow into the first field device 116, and measure flow parameters (e.g., temperature, flow rate, pressure, etc.) based on data acquired from the second field device 118.

[0024] In some examples, VA100 returns information associated with the control loop 120, including MODE parameters (e.g., automatic mode, manual mode, cascade mode, etc.), setpoint (SP) parameters, process variable (PV) parameters, or measured value (MV) parameters, output (OUT) parameters, status parameters, and / or one or more alarms associated with components or field devices included in the control loop 120. For example, SP parameters may correspond to predicted or desired values ​​of MV or PV. In such examples, SP may be input and / or communicated by user 104 via VA100. For example, user 104 may instruct VA100 to assign a 100% open value to the SP parameter for the valve position parameter of the first field device 116. MV or PV parameters may correspond to measured values ​​of process outputs (e.g., flow rate, pressure, temperature of fluid flowing through the first field device 116, etc.). OUT parameters may correspond to outputs of the control loop 120 (e.g., outputs from the controller). The OUT parameter may correspond to an output signal generated by the control loop 120 and transmitted to an actuator (e.g., an actuator included in the first field device 116) to adjust the actuator.

[0025] In some examples, in response to a MODE parameter corresponding to automatic mode, the control loop 120 receives SP and PV, calculates the OUT parameter, and transmits an output signal corresponding to the OUT parameter to the first field device 116. In some examples, in response to a MODE parameter corresponding to manual mode, the control loop 120 is disabled, allowing user 104 to directly transmit an output signal corresponding to the OUT parameter to the actuator. For example, user 104 may instruct VA 100 to adjust the valve position of the first field device 116 by disabling SP stored in the control loop 120.

[0026] In some examples, in response to a MODE parameter corresponding to a cascade mode, the control loop receives SP from an external source, such as another controller associated with another control loop (e.g., FIC-201, FIC-204, etc.), but is not limited to this. For example, control loop FIC-201 may receive a first SP associated with field device FV-101 from control loop FIC-204. In such an example, user 104 may instruct VA100 to generate a flow rate of 2 barrels / min (bpm) of fluid flowing through FV-101. VA100 may process the request from user 104, generate a command, and send the command to FIC-204 to assign a flow rate of 2 bpm to the flow rate SP. FIC-204 may obtain a level measurement of an exemplary process tank 122 from FI-204 and convert the change in level into a flow rate (e.g., a flow rate based on the filling rate of process tank 122). Next, FIC-204 may generate a command corresponding to the valve position SP of FV-101 based on the flow rate SP and send it to FIC-201. Upon receiving the command, FIC-201 opens FV-101 and achieves and / or satisfies the valve position SP that satisfies a flow rate SP of 2 bpm through FV-101. In response to satisfying the valve position SP, FIC-204 may determine whether the 2 bpm flow rate SP through FV-101 has been satisfied. In some examples, VA100 generates an audible message to user 104 indicating that the flow rate through FV-101 associated with the user's request has been satisfied. Additionally or alternatively, VA100 may include information in the audible message such as the fill rate of process tank 122, the value of valve position SP, the valve position associated with FV-101, and / or a combination thereof.

[0027] In some examples, user 104 and / or host application 106 issue commands to VA100 to be executed by one or more components of process control system 102. For example, user 104 may issue verbal commands to VA100 using different communication protocols, etc., to instruct a second field device 118 to use different units of measurement or different output data, to open and close a first field device 116. In other examples, host application 106 may generate commands and send them to VA100 to execute a workflow that involves one or more actions of one or more components of process control system 102. For example, host application 106 may generate and send a command to VA100 to fill process tank 122. In such an example, the VA100 may operate one or more field devices, such as FV-101 and FV-102, to fill the process tank 122, release gas output by opening the first field device 116, and provide feedback to the user 104 and / or host application 106, including the status of operation. For example, the status may be an audible and / or visual message indicating that the process tank 122 is 40% full. In other examples, the message may include the estimated time remaining for operation, the elapsed time since the start of operation, etc. In some examples, the VA100 generates notifications to the user 104, the host application 106, etc., including safety information. For example, the notification may correspond to an FCC gas leak, a liquid leak in the process tank 122, etc. Additionally or alternatively, although a process tank 122 is shown in Figure 1A, VA100 may trigger a conversation with user 104 and / or a host application 106 to facilitate functionality and / or operation by one or more heat exchangers, one or more distillation columns, one or more heating furnaces, and / or a combination thereof.

[0028] In the example shown in Figure 1A, VA100 queries and / or retrieves information from an exemplary database 124 via an exemplary network 126. In some examples, the database 124 contains a configuration of the process control system 102, which may contain one or more profiles, each of which corresponds to a component included in the process control system 102 (e.g., a first profile corresponding to a first profile field device 116, a second profile corresponding to a process tank 122, etc.). In some examples, a profile may correspond to two or more components. For example, a profile may contain information associated with a control loop 120, which may contain information corresponding to a first field device 116, a second field device 118, a controller included in the control loop 120, etc. In some examples, the database 124 contains actions that can be performed by the components of the process control system 102 (e.g., basic actions, compound actions, etc.). In some examples, the database 124 contains scripts that can be executed by VA100 to instruct one or more components of the process control system 102 to perform one or more actions.

[0029] The database 124 in Figure 1A may be implemented by volatile memory (e.g., synchronous dynamic random access memory (SDRAM), dynamic random access memory (DRAM), RAMBUS dynamic random access memory (RDRAM), etc.) and / or non-volatile memory (e.g., flash memory). The database 124 may also be additionally or alternatively implemented by one or more double data rate (DDR) memories such as DDR, DDR2, DDR3, DDR4, and mobile DDR (mDDR). The database 124 may also be additionally or alternatively implemented by one or more mass storage devices such as hard disk drives, compact disk drives, digital versatile disk drives, and solid-state disk drives. In the example shown, the database 124 is shown as a single database, but the database 124 may be implemented by any number and / or types of databases. Furthermore, the data stored in the database 124 may be in any data format, such as binary data, comma-separated data, tab-separated data, or Structured Query Language (SQL) structures.

[0030] Network 126 in Figure 1A is a bus and / or computer network. For example, network 126 could be a process control network. In some examples, network 126 is a network capable of being communicably coupled to the Internet. However, network 126 can be implemented using any suitable wired and / or wireless network, including, for example, one or more data buses, one or more local area networks (LANs), one or more wireless LANs, one or more cellular networks, one or more fiber optic networks, one or more satellite networks, one or more private networks, one or more public networks, etc. Network 126 may enable the exemplary VA 100 to communicate with database 124.

[0031] Figure 1B is a schematic diagram of the exemplary VA100 of Figure 1A, which is contained in and / or runs on exemplary wearable devices 128, 130, 132 to facilitate the operation of the exemplary process control system 102 of Figure 1A. In Figure 1B, the wearable devices 128, 130, 132 include a first exemplary wearable device 128, a second exemplary wearable device 130, and a third exemplary wearable device 132. The first wearable device 128 in Figure 1B is a headset. Additionally or alternatively, the VA100 may be installed and / or configured on any other computing or wearable device, such as a smartwatch or smart goggles.

[0032] The first wearable device 128 in the example shown in Figure 1B may be a headset including a processor-based computer platform that includes one or more processors, one or more memory devices and / or one or more mass storage devices for storing machine-readable instructions, one or more interface circuits for facilitating Bluetooth® and / or Wi-Fi communication, one or more input devices such as buttons and / or microphones, one or more output devices such as speakers, and / or any other hardware components that can implement VA100. In such an example, user 104 may invoke VA100 on the first wearable device 128 by pressing a button or announcing a specific phrase such as "Hello, virtual assistant."

[0033] The second wearable device 130 in the example shown in Figure 1B is a wristband. For example, the second wearable device 130 may be a wristband that includes a processor-based computer platform including one or more processors, one or more memory devices and / or one or more mass storage devices for storing machine-readable instructions, one or more interface circuits for facilitating Bluetooth® and / or Wi-Fi communication, one or more input devices such as buttons and / or microphones, one or more output devices such as speakers, and / or any other hardware components that can implement VA100. In such an example, user 104 may invoke VA100 on the second wearable device 130 by pressing a button or announcing a specific phrase such as "Hello, virtual assistant".

[0034] The third wearable device 132 in the example shown in Figure 1B corresponds to a pair of glasses including two lenses. For example, the third wearable device 132 may be a pair of glasses including a processor-based computer platform including one or more processors, one or more memory devices and / or one or more mass storage devices for storing machine-readable instructions, one or more interface circuits for facilitating Bluetooth® and / or Wi-Fi communication, one or more input devices such as buttons and / or microphones, one or more output devices such as displays and speakers, and / or any other hardware components that can implement VA100. In such an example, user 104 may invoke VA100 on the third wearable device 132 by pressing a button or announcing a specific phrase such as "Hello, virtual assistant" while performing a gesture such as blinking or waving a hand in front of the glasses. In some examples, the third wearable device 132 includes two displays, including a first display integrated into a first lens and a second display integrated into a second lens. In another example, the third wearable device 132 includes one display on either the first or second lens of the eyeglasses.

[0035] In the example shown in Figure 1B, wearable devices 128, 130, and 132 are communicably coupled to network 126 via a wireless connection such as Bluetooth® or Wi-Fi. In some examples, one or more of the wearable devices 128, 130, and 132 may be communicably coupled to network 126 via a direct wireless connection without interleaving devices such as access points, beacons, or gateways. One or more of the wearable devices 128, 130, and 132 may be communicably coupled to network 126 via interleaving devices such as access points, beacons, or gateways.

[0036] In the example shown in Figure 1B, one or more of the wearable devices 128, 130, and 132 may be communicably coupled to the network 126 via one or more of the beacons 134a-g. In Figure 1B, beacons 134a-g are Wi-Fi beacons (e.g., Wi-Fi Direct® beacons). For example, beacons 134a-134g are devices containing one or more processors that can facilitate wireless communication between computing devices (e.g., between a server and a client device, or between an access point and a client device). Alternatively, one or more of the beacons 134a-g may be Bluetooth® beacons or dual Bluetooth® / Wi-Fi beacons. Additionally or alternatively, one or more of the beacons 134a-g may support different wireless communication protocols. Seven of the beacons 134a-g are shown in Figure 1B, but fewer or more beacons than those shown may be used.

[0037] In the example shown in Figure 1B, beacons 134a-g are located at multiple locations throughout the process control system 102. In Figure 1B, each of the beacons 134a-g is located at a position that generates a coverage area containing one or more field devices. The coverage area may correspond to a geographical area to which devices are communicably coupled to the beacon associated with the coverage area. For example, the first of the beacons 134a-134g may have a first coverage area containing FI-205 118 and FIC-207. In some examples, one or more coverage areas of beacons 134a-g may overlap with each other. In other examples, the coverage areas of beacons 134a-b may not overlap with each other.

[0038] In some examples, wearable devices 128, 130, and 132 dynamically connect to beacons 134a-g when they are within the coverage area where they are generated and / or associated with beacons 134a-g. For example, wearable devices 128, 130, and 132 may be communicably coupled to network 126 via the first beacon of beacons 134a-g when they enter the coverage area associated with the first beacon 134a. Once wearable devices 128, 130, and 132 are communicably coupled to the first beacon 134a, user 104 can trigger a conversation with VA 100 corresponding to a field device within the range of the first beacon 134a. For example, user 104 may initiate a conversation with VA 100 on the first wearable device 128 corresponding to FI-205 118. In such an example, user 104 may invoke VA100 by announcing, "Hello virtual assistant, please provide me with information about FI-205." In response to the invoke, VA100 may generate a request to database 124, which is communicably connected to network 126 via the first beacon 134a. VA100 may generate an audible response to user 104 containing information corresponding to FI-205 118.

[0039] In some examples, when VA100 enters a coverage area, it may download information to wearable devices 128, 130, and 132 associated with field devices within the coverage areas of beacons 134a to 134g. For example, when user 104 wearing a third wearable device 132 enters the first coverage area of ​​the first beacon 134a, VA100 may query the first beacon 134a for field devices within the first coverage area. The first beacon 134a may return a list of field devices, including FI-205 118 and FIC-207. VA100 may compare the returned list of field devices with information stored in the third wearable device 132. VA100 may download information not yet stored in the third wearable device 132. For example, the third wearable device 132 may have already stored the first information associated with FI-205 118, but has not yet stored the second information associated with FIC-207. In such an example, VA100 may query the first beacon 134a for the second information. In some examples, VA100 queries the first beacon 134a for the third information associated with FI-205 118 if the third information differs from the first information. In other examples, VA100 may replace the first information with the third information.

[0040] In some examples, VA100 deletes information associated with field devices within the coverage area of ​​beacons 134a-g when the user leaves the coverage area. For example, when user 104 wearing a second wearable device 130 leaves the first coverage area associated with the first beacon 134a, VA100 may instruct the second wearable device 130 to delete information associated with FI-205 118, FIC-207, etc. In other examples, VA100 may instruct the second wearable device 130 to delete information when entering a second coverage area different from the first coverage area. For example, VA100 may instruct the second wearable device 130 to replace previously stored information associated with the first coverage area with second information associated with the second field device within the second coverage area.

[0041] Advantageously, VA100 can slow down the processing speed of requests from user 104 by locally storing information associated with field devices in beacon coverage areas on wearable devices 128, 130, and 132, instead of retrieving information from database 124 via network 126. For example, when user 104 wearing a third wearable device 132 enters a first coverage area associated with the first beacon 134a, VA100 may download the wiring diagram associated with FIC-205 120. In such an example, when user 104 requests VA100 to display the wiring diagram, VA100 may instruct the third wearable device 132 to display the wiring diagram on one or both of the glasses (e.g., on one or both displays built into the glasses). By locally storing the wiring diagram upon entering the first coverage area, VA100 can increase the processing speed of requests from user 104.

[0042] Similarly, VA100 can reduce the amount of computing resources associated with maintaining network 126 by retrieving data from information stored in beacons 134a-g instead of querying database 124. In some examples, beacons 134a-g can reduce network resources associated with network 126 by forming a mesh network. For example, beacons 134a-g may be placed in process control system 102 such that each beacon 134a-g is communicably coupled to at least one of the other beacons 134a-g. In such an example, the first beacon 134a can process requests from the second through seventh beacons 134b-g, and the network 126 can send requests to network 126 instead of processing requests from each of the beacons 134a-g.

[0043] Figure 2 is a schematic diagram of the VA100 in Figures 1A and 1B. In Figure 2, the VA100 is operating in an exemplary process control environment 200 and / or enhancing process control (e.g., process control operation). For example, the process control environment 200 may correspond to a process industry environment or system including a chemical plant, manufacturing facility, oil field environment, plant, etc. For example, the process control environment 200 may correspond to the process control system 102 in Figures 1A and 1B. In the example shown in Figure 2, the VA100 facilitates communication (e.g., receiving commands, sending responses, etc.) with the user 104, host application 106, etc. in Figures 1A and 1B. In some examples, the user 104 and / or host application 106 query the VA100 for data or information of interest via exemplary requests 201a and 201b, including a first exemplary request 201a and a second exemplary request 201b. One or both of requests 201a and 201b may correspond to verbal requests, commands (e.g., verbal commands), selections in and / or inputs to the host application 106. For example, user 104 might ask "What is the status of FIC-205?" in the first request 201a. In such an example, VA100 may return one or more parameters associated with the control loop 120 in Figures 1A and 1B, including MODE, SP, PV, OUT, status, alarms, and / or combinations thereof. In other examples, user 104 may interact with the host application 106 by selecting the second request 201b from a pre-entry list displayed in the user interface, or by generating input by typing a text-based command or request not included in the pre-entry list, such as "Find me FI*" (the asterisk (*), a wildcard character, instructs VA100 to return a list of components or field devices associated with FI, or may include FI in the description of the field device components).For example, VA100 may generate a list containing the names, descriptions, and / or corresponding path information of one or more field devices, control loops, etc., to which a specifier containing FI (e.g., FI-201, FIC-201, FI-202, FIC-202, etc.) is assigned.

[0044] In Figure 2, the host application 106 may be an exemplary mobile application 202. For example, the mobile application 202 may run and / or operate using the first device 108, the second device 110, and / or the third device 112 in Figures 1A and 1B. For example, the mobile application 202 may be an Apple® iOS mobile application, an Android® mobile application, etc. For example, the mobile application 202 may be a process control-based mobile application such as Emerson® DeltaV® Mobile.

[0045] In the example shown in Figure 2, the host application 106 may be an exemplary browser application 204. For example, the browser application 204 may implement a web browser and / or web server in which information sent to, received from, and / or exchanged with VA100 is formatted as HTTP messages. However, any other message format and / or (communication) protocol, such as File Transfer Protocol (FTP), Real-Time Transfer Protocol (RTP), Simple Message Transfer Protocol (SMTP), or HTTP Secure (HTTPS) protocol, may be used additionally or alternatively. For example, the browser application 204 may be a process-controlled browser application built and / or generated using Emerson® DeltaV® Live.

[0046] The host application 106 in Figure 2 may be an exemplary desktop application 206. For example, desktop application 206 may run on and / or execute on Apple® Mac® computers (e.g., MacBook® computers, Mac Pro® computers, etc.), Windows-based desktop and / or laptop computers, Linux®-based desktop and / or laptop computers, etc. For example, desktop application 206 may run and / or execute as a standalone application that does not require a web browser and / or internet connection to function or operate. In other examples, desktop application 206 may run and / or execute as a computer application that can use a web browser and / or internet connection to function or operate.

[0047] In the example shown in Figure 2, the host application 106, which operates and / or runs on the mobile application 202, the browser application 204, and the desktop application 206, includes a user interface for receiving and / or obtaining requests 201a~b from the user 104. For example, VA 100 may send a response to requests 201a~b to the host application 106. In such an example, the host application 106 may display the response via the user interface (e.g., displaying a graphic including parameter values, visualization). things (This includes displaying text-based messages, including responses.) In some examples, the host application 106 may communicate responses from the VA 100 via one or more speakers communicatively coupled to the host application 106. For example, the host application 106 may generate an oral message representing a response from the VA 100 and communicate the oral message via one or more speakers coupled to a computing device running the host application 106.

[0048] In the example shown in Figure 2, the host application 106 includes one or more application programming interfaces (APIs), extensions, plug-ins, and / or combinations thereof that can be used to facilitate communication with VA100 via the example of the host application bot framework 208. Alternatively, the host application 106 may communicate and / or exchange data with VA100 without the host application bot framework 208. In Figure 2, the host application bot framework 208 is included in the host application 106 and queues requests and marshals requests and responses. For example, the host application bot framework 208 may process and / or manage requests for VA100 and responses from VA100 (e.g., buffering requests, prioritizing requests, sorting requests, comparing requests with cached responses, etc.).

[0049] In the example shown in Figure 2, user 104 and / or host application 106 communicate with and / or interact with VA100 via an exemplary serverbot framework 210. VA100 includes the serverbot framework 210 to facilitate communication by receiving and processing commands and / or requests. For example, the serverbot framework 210 may process or manage queries from host application 106 based on request / response, publish / subscribe, or event registration using a callback architecture or schema. In some examples, the serverbot framework 210 is implemented by one or more processor-based servers.

[0050] In some examples, the serverbot framework 210 returns responses synchronously to the user 104, the host application 106, etc., while in other examples, the serverbot framework 210 returns responses asynchronously. For example, asynchronous responses may be returned as alerts, notifications, etc. In such examples, user 104 may request a long-running workflow, such as filling the process tank 122 shown in Figures 1A and 1B. The serverbot framework 210 may asynchronously generate a response when filling the process tank 122 is complete, and / or at any of the various milestones in filling the process tank 122, such as when the process tank 122 is 25%, 50%, and 75%, and send it to user 104 (e.g., via an audible alert or notification), the host application 106 (e.g., via an audible alert and / or visual notification on the user interface of the host application 106), and / or one of the wearable devices 128, 130, and 132. In some examples, the serverbot framework 210 may generate and transmit responses, along with and / or include warnings or notifications, that contain information associated with a long-running workflow, such as the fill rate of the process tank 122, the flow rate through the first field device 116 in Figures 1A and 1B, and the sensor readings of the second field device 118 in Figures 1A and 1B.

[0051] In the example shown in Figure 2, the server bot framework 210 includes an exemplary framework controller 212, an exemplary parser 214, an exemplary analyzer 216, an exemplary generator 218, and an exemplary execution unit 220 for handling and / or managing communication with the host application 106. Alternatively, the server bot framework 210 may include fewer or more components than those shown in Figure 2. Alternatively, the components included in the server bot framework 210 shown in Figure 2 may be combined, divided, rearranged, omitted, removed, and / or implemented in any other way.

[0052] In the example shown in Figure 2, the serverbot framework 210 includes a framework controller 212 to facilitate interaction between (1) one of the following: user 104, host application 106, wearable devices 128, 130, 132, etc., and (2) the serverbot framework 210. In some examples, the framework controller 212 determines the configuration and / or type of request management system to use when managing requests. For example, the framework controller 212 may determine to facilitate communication or data transfer with user 104, host application 106, wearable devices 128, 130, 132, etc., based on requests / responses, publish / subscribe, and event registration, which have callbacks and / or other message processing schemes.

[0053] In some examples, the framework controller 212 determines a response management system that manages responses to requests 201a-b received and / or acquired from user 104, host application 106, and / or wearable devices 128, 130, 132. For example, the framework controller 212 may determine to send and / or return responses to user 104, host application 106, and / or wearable devices 128, 130, 132 asynchronously or synchronously. For example, based on determining that the initial requests 201a-b from user 104 are part of a relatively long-running workflow (e.g., a command to start filling process tank 122 in Figures 1A-1B), the framework controller 212 may determine to return a response to user 104 asynchronously as a notification. In another example, the framework controller 212 may determine to synchronously return a response to the host application 106 based on the determination that the initial request from the host application 106 is a request for information (for example, a request for the firmware version associated with the first field device 116 in Figures 1A and 1B).

[0054] In the example shown in Figure 2, the serverbot framework 210 includes a parser 214 for determining and / or identifying elements (e.g., identifiable elements, distinct components, etc.) contained in requests 201a-b from user 104, host application 106, and / or wearable devices 128, 130, 132. In some examples, the parser 214 includes a tokenizer that performs tokenization, or a process or method for dividing and / or classifying sections of an input string. For example, the parser 214 may divide or segment a stream of words contained in the first request 201a from user 104 into tokens obtained by analyzer 216 for further processing. Additionally or alternatively, the parser 214 may determine the elements of the first request 201a in other ways.

[0055] In some cases, parser 214 performs dimensionality reduction to reduce and / or remove elements in the first request 201a that do not add any substantial recognition value to the serverbot framework 210. For example, parser 214 may filter and / or remove foreign or unidentifiable audible noise from the first request 201a from user 104 to reduce the amount of processing power or time required for the serverbot framework 210 to process the first request 201a. In other cases, parser 214 may reduce the amount of tokens transferred to analyzer 216 for processing. For example, parser 214 may remove tokens associated with non-actionable, filler, or irrelevant words such as "um" or "the" from the first request 201a from user 104 before transferring the determined tokens to analyzer 216.

[0056] In some examples, parser 214 identifies and / or determines expressions (e.g., regular expressions, typical expressions, etc.) based on requests from user 104, host application 106, and / or wearable devices 128, 130, 132. For example, parser 214 may determine that requests 201a-b are based on common questions such as "What state is FIC-201?" and "Where is FV-106?". Parser 214 may determine typical phrases such as "What state is it?" and "Where is it?" and determine a response based on the requested components (e.g., FIC-201, FV-106, etc.) that follow the typical phrases. In some examples, parser 214 includes image recognition hardware (e.g., one or more hardware accelerators) and / or software for identifying elements of gesture-based requests (e.g., waving a hand to acknowledge a response from VA 100, a thumbs-up gesture, etc.).

[0057] In some examples, parser 214 extracts information based on requests 201a and 201b. For example, parser 214 may identify field devices, control loops, etc., associated with requests 201a and 201b based on extracting the name and / or type of the requested field device. In other examples, parser 214 may identify the type of requests 201a and 201b (e.g., command, location request, maintenance step request, etc.) based on extracting information from requests 201a and 201b.

[0058] In the example shown in Figure 2, the serverbot framework 210 includes an analyzer 216 for validating requests 201a-b from users 104, host applications 106, wearable devices 128, 130, 132, etc. The analyzer 216 performs one or more validations or validation checks, including grammar checks, spell checks, and semantic checks, to determine whether the tokenized expression by the parser 214 is a valid expression. For example, the analyzer 216 may determine whether the syntax analyzer 214 has generated one or more tokens that, when assembled to form an expression, can return a valid response from the VA 100.

[0059] In the example shown in Figure 2, the server bot framework 210 includes a generator 218 that compiles, generates, and / or produces a set of actions including one or more searches, responses, scripts, and / or templates. In some examples, the generator 218 performs searches based on requests 201a~b. For example, the generator 218 may perform a search based on the query, "What is the status of FIC-201?", to which the generator 218 searches for the status in one of the exemplary system examples 222 in Figure 2, and based on the search, creates an exemplary response, "The status of FIC-201 is closing FV-101", and sends the exemplary response to user 104, host application 106, wearable devices 128, 130, 132, etc.

[0060] In some examples, the generator 218 may generate at least one of a script or template based on requests 201a-b. In such examples, the generator 218 may send the script or template to the execution unit 220. For example, requests 201a-b from user 104 may correspond to a long-running workflow or a workflow that includes multiple steps or completion points. For example, a long-running workflow requested by user 104 might be, "What is the step to replace the seal on FV-105?" In such an example, the generator 218 may create a template based on at least one of the field device type corresponding to FV-105, the components of the field device type being questioned, or the identification of user 104. For example, the template may include a set of steps organized into individual steps. Each step in the set includes one or more instructions to perform the step, one or more tools to perform the step, and / or one or more validations to ensure that one or more instructions are performed correctly. In such an example, the template may include responses to each step that can be communicated to user 104 when user 104 confirms that the step is complete or when user 104 requests additional information. For example, the responses may be information associated with the next step, or responses to queries made by user 104 (e.g., requests 201a-b) associated with the current step being performed, or tools corresponding to the current step.

[0061] In some examples, the generator 218 creates a response to request additional information from the source of the request. For example, the generator 218 may generate a response to user 104 requesting clarification or additional information, such as when user 104 requests information about a field device not included in the process control system 102, or requests to perform an action on a field device not supported by the field device. In such an example, the generator 218 may request additional information from user 104 to verify the accuracy of the request processed by the serverbot framework 210. In some examples, the generator 218 determines that a request is an incorrect request (e.g., a frequently received incorrect request) and generates a response containing corresponding information describing alternatives to requests 201a~b and / or why the original requests 201a~b are incorrect, and / or why alternatives that could be proposed instead of the original requests 201a~b could be performed.

[0062] In the example shown in Figure 2, the serverbot framework 210 includes an execution unit 220 that facilitates actions or commands based on requests from user 104, host application 106, and / or wearable devices 128, 130, 132. For example, the execution unit 220 may receive scripts, templates, etc., from the generation unit 218. In some examples, the execution unit 220 triggers and / or starts scripts, templates, and / or actions based on requests 201a~b. For example, the execution unit 220 may send a command based on a command structure in JavaScript® Object Notation (JSON) format to an exemplary conversational context engine 224. In response to the transmission, the conversational context engine 224 may generate a command to open the first field device 116 in Figure 1A in response to user 104's request to open the first field device 116. In other examples, the execution unit 220 may trigger a template to fill the process tank 122 shown in Figures 1A and 1B, and generate notifications at one or more steps or completion points of the template. For example, the execution unit 220 may send a script, template, etc., to the conversation context engine 224 to trigger the filling of the process tank 122. In other examples, the execution unit 220 may trigger a script in response to a user 104 requesting information associated with a first field device 116, a second field device 118, etc.

[0063] In some examples, the execution unit 220 updates an exemplary model 243 included in and / or stored in an exemplary conversation context database 244. In some examples, the conversation context database 244 includes multiple models 243. For example, a model 243 may correspond to one or more machine learning models, one or more neural networks (e.g., artificial neural networks), etc. For example, the execution unit 220 may update a model 243 used to process requests from one or more of the following: user 104, host application 106, wearable devices 128, 130, 132, etc. In such examples, the execution unit 220 may trigger an exemplary conversation context engine 224 to trigger a model 243 included in the conversation context database 244 associated with VA 100. In some examples, a model 243 is reconfigured and updated based on a new configuration of the process control system 102 shown in Figures 1A and 1B. For example, the process control system 102 may be modified by removing and / or adding one or more field devices that may affect the response generated by the serverbot framework 210 and / or more generally by the VA100, or by modifying one or more control loops.

[0064] The models 243(or more) stored in the conversation context database 244 may correspond to artificial neural networks. An artificial neural network is a computer system architecture model that learns to perform tasks and / or provide responses based on evaluation or "learning" from examples with known inputs and known outputs. Neural networks such as the models 243(or more) stored in the conversation context database 244 may feature a series of interconnected nodes called "neurons" or nodes. Input nodes are activated by external sources / stimuli (e.g., requests 201a-b from user 104, responses generated by generator 218, etc.), such as inputs from the execution unit 220. Input nodes activate other internal network nodes according to connections between nodes (managed by, for example, machine parameters, prior relationships, etc.). Connections are dynamic and can be changed based on feedback, training, etc. By changing connections, the output of the artificial neural network can be improved or optimized to produce more / most accurate results. For example, a model 243 stored in a conversation context database 244 may be trained using information from one or more sources to map inputs to responses, etc., thereby improving the accuracy of responses and reducing the time required to generate responses, etc., and / or combinations thereof.

[0065] Machine learning techniques such as neural networks, deep learning networks, support vector machines, and / or other experience / observational learning systems can be used to, for example, produce optimal results, find objects in images, understand utterances, convert utterances to text, and improve the relevance of search engine results. Deep learning is a subset of machine learning that uses a set of algorithms to model high levels of abstraction of data using deep graphs with multiple processing layers, including linear and nonlinear transformations. While many machine learning systems are seeded with initial features and / or network weights that are modified through the training and updating of the machine learning network, deep learning networks train themselves to identify "good" features for analysis. Using a multi-layer architecture, machines using deep learning techniques can process raw data better than machines using traditional machine learning techniques. Using different layers of evaluation or abstraction makes it easier to examine data on highly correlated groups of values ​​or specific themes.

[0066] For example, deep learning using convolutional neural networks (CNNs) uses convolutional filters to segment data and identify learnable, observable features within it. Each filter or layer in the CNN architecture transforms the input data to increase its selectivity and invariance. This data abstraction allows the machine to classify irrelevant background information and focus on the data features it chooses to ignore.

[0067] Deep learning operates on the understanding that many datasets contain high-level features that also contain low-level features. For example, it is more efficient to examine an image (e.g., an image for a gesture-based request) and search for edges that form motifs that form parts that make up the object being searched for, rather than searching for an object. These feature hierarchies are contained within different data formats.

[0068] Learned observable features include objects and quantifiable regularities learned by machines in supervised learning. Machines with large sets of well-classified data are better equipped to distinguish and extract features associated with the correct classification of new data. Deep learning machines utilizing transfer learning can appropriately link data features to specific classifications verified by human experts. Conversely, the same machine can update classification parameters when notified of incorrect classifications by human experts. For example, settings and / or other configuration information can be guided by learned use of settings and / or other configuration information, and as the system is used more (e.g., repeatedly and / or by multiple users), many variations and / or other possibilities of settings and / or other configuration information can be reduced for a particular situation.

[0069] For example, a deep learning neural network might be trained on a set of data classified by an expert. This dataset builds the neural network's initial parameters, which constitutes the supervised learning phase. During the supervised learning phase, the neural network can be tested to see if the desired behavior has been achieved. Once the desired behavior of the neural network is achieved (e.g., the machine is trained to operate according to specified thresholds), the machine can be deployed for use (e.g., testing the machine on "real" data). Throughout operation, the neural network's behavior can be continuously improved by confirming or rejecting its classifications (e.g., by expert users, expert systems, reference databases, etc.). The model 243(or more) contained in the conversation context database 244 is now in a transfer learning state, as its classification parameters, which determine the neural network's behavior based on the ongoing dialogue, are updated. In certain cases, an artificial neural network such as Model 243, stored in the conversation context database 244, can provide direct feedback to another process, such as elements parsed by Parser 214 or responses generated by Generator 218. In such cases, Model 243 outputs data that is buffered and validated (e.g., via the cloud) before being provided to another process.

[0070] In some examples, the execution unit 220 updates the objective based on requests 201a~b from users 104, host applications 106, wearable devices 128, 130, 132, etc. For example, the execution unit 220 may update templates, scripts, etc., based on a request from user 104 to cancel an action, process, operation, etc., associated with a previous request. For example, user 104 may, when the first request is made before the second request, request VA 100 to fill the process tank 122 shown in Figures 1A~1B, and request VA 100 to cancel the filling of the process tank 122 in the second request in which the first request is made. In such an example, the execution unit 220 can generate a command to stop filling the process tank 122 by canceling and / or stopping scripts, templates, etc., generated in response to the first request. In some examples, the execution unit 220 generates actions in response to the objective update. For example, the execution unit 220 may generate a command to purge the process tank 122 in response to a user 104 requesting to stop filling the process tank 122. In such an example, the execution unit 220 can communicate information associated with the command to the user 104 to ensure that the user 104 approves the command before the execution unit 220 can facilitate its execution.

[0071] In some examples, the execution unit 220 updates a dialog or response plan. For example, the execution unit 220 may generate a script or template based on requests 201a~b from user 104, host application 106, wearable devices 128, 130, 132, etc. For example, the execution unit 220 may generate a script based on user 104 asking, "What is the status of FV-105?" The execution unit 220 may generate a script to include responses or levels of responses to potential questions that user 104 may ask in relation to FV-105, devices coupled to FV-105, or a control loop including FV-105. In such an example, the execution unit 220 may update the dialog associated with the script when user 104 asks follow-up questions to responses generated and communicated by the generation unit 218, the execution unit 220, etc. For example, the execution unit 220 may determine that user 104 has moved from a first level of questions and corresponding responses to a second level of questions and corresponding responses, based on user 104 requesting more specific information in a follow-up request.

[0072] In the example shown in Figure 2, user 104 may interact with VA 100 via an exemplary DCS controller assembly 226. For example, the DCS controller assembly 226 may be an Emerson® DeltaV® S-series DCS system. For example, the DCS controller assembly 226 may be one or more programmable logic controllers (PLCs) or any other process controller used in industrial or process automation. Alternatively, the DCS controller assembly 226 may be any other type of DCS system. The DCS controller assembly 226 in Figure 2 includes a first controller 228 and a second controller 230. In Figure 2, the first and second controllers 228, 230 are Characterization Modules (CHARM) I / O Cards (CIOCs). Alternatively, any other number or type of electronic controllers may be used. The first and second controllers 228, 230 perform data acquisition and control operations such as acquiring and processing sensor measurements and transmitting sensor measurements to an external controller and / or DCS. For example, the first and second controllers 228 and 230 are included in the process control system 102 of Figure 1A and may control and / or monitor the first field device 116, the second field device 118, and so on.

[0073] The first and second controllers 228, 230 in Figure 2 are electrically coupled to the I / O module 232 via a terminal block 234. The I / O module 232 is detachably coupled to the terminal block 234. The I / O module 232 in Figure 2 is a CHARM. Alternatively, any other type of input and / or output module used for data acquisition and control may be used. Each CHARM is an individual input and / or output channel of the first and second controllers 228, 230. For example, each of the I / O modules 232 may be an analog input or output channel, a digital input or output channel, a relay channel, etc. Each of the I / O modules 232 may include an analog-to-digital (A / D) converter, a signal separator, etc.

[0074] In the example shown in Figure 2, the first I / O module 236 is a VA module. In some examples, the VA module 236 can facilitate interaction between the DCS controller assembly 226 and (1) VA 100 via the network 126, (2) one or more of the beacons 134a-g, and / or (3) one or more of the wearable devices 128, 130, and 132 in Figure 1B. For example, the first wearable device 128 can send a first request 201a to the first beacon 134a, then send a query to the VA module 236, which can then query the VA 100 via the network 126 for information associated with the field device 118 in Figures 1A-1B. In such an example, the VA module 236 can store the information in a mass storage disk or storage device included in the DCS controller assembly 226 and / or communicate the information to the user 104. For example, the VA module 236 may facilitate interaction between the VA 100 and user 104 (e.g., communicating information with user 104 and / or obtaining a first request 201a from user 104). For example, the VA module 236 may include one or more speakers and / or one or more microphones. In such an example, the VA module 236 may use one or more microphones to hear and / or otherwise obtain the first request 201a from user 104. The VA module 236 may use one or more speakers to communicate and / or transmit a response to the first request 201a to user 104.

[0075] In some examples, the VA module 236 converts the first request 201a into one or more digital signals that can be transmitted to the serverbot framework 210 via the network 126 shown in Figures 1A and 1B. In response to the serverbot framework 210 receiving one or more digital signals, the serverbot framework 210 may convert one or more digital signals into tokens via the parser 214 and / or convert them. The serverbot framework 210 may analyze the tokens, determine a response based on the tokens, convert the response into one or more digital signals, and transmit them to the VA module 236 via the network 126, the DCS controller assembly 226, etc. In response to the VA module 236 receiving one or more digital signals, the VA module 236 converts one or more digital signals into sound via one or more speakers included in the VA module 236 to communicate the response to the user 104.

[0076] Alternatively, the functionality of the VA module 236 may be incorporated into and / or integrated with at least one of the first controller 228 or the second controller 230. For example, one or more microphones and / or one or more speakers may be integrated into the DCS controller assembly 226, the first controller 228, and / or the second controller 230. In some examples, the VA module 236 is a standalone device that can be communicably coupled (e.g., via a wired connection, wireless connection, etc.) to at least one of the DCS controller assemblies 226, one or more of the beacons 134a-g, and / or the VA 100.

[0077] In the example shown in Figure 2, VA100 includes a conversation context engine 224 that manages and / or processes requests from user 104, host application 106, wearable devices 128, 130, 132, DCS controller assembly 226, etc., based on the conversation context. For example, user 104 may request information and / or status from VA100 related to the first controller 228, second controller 230, etc., of the DCS controller assembly 226. In such an example, the status may correspond to the health of the first controller 228, the firmware version of the second controller 230, the health of one or more of the I / O modules 236, etc. In some examples, the conversation corresponds to an interaction with VA100. For example, the conversation may correspond to user 104 communicating and / or receiving information orally from VA100 via beacons 134a-g, wearable devices 128, 130, 132, VA module 236, etc. In other examples, a conversation may correspond to the host application 106 sending a request to VA100 and / or receiving a response from VA100. In some examples, the conversation context engine 224 is implemented by one or more processor-based servers. In some examples, the server bot framework 210 and the conversation context engine 224 are implemented by the same one or more processor-based servers. In other examples, the server bot framework 210 is implemented by one or more processor-based servers separate from the one or more processor-based servers that implement the conversation context engine 224.

[0078] In some examples, the conversational context corresponds to requests, responses, etc., associated with process industries, including chemical plants, manufacturing facilities, and oilfield environments. In some examples, the conversational context engine 224 and / or more generally the VA100 may use the conversational context to generate responses based on the system configuration associated with the process control system 102 shown in Figures 1A and 1B. For example, the conversational context engine 224 may generate responses to requests from users 104, host applications 106, wearable devices 128, 130, 132, etc., based on process control device configurations (e.g., DeltaV database configurations), asset management software (AMS) databases, recipes, and / or other process-related information.

[0079] The conversation context engine 224 in Figure 2 includes an exemplary conversation processor 238, an exemplary action processor 240, and an exemplary conversation state handler 242 for processing and / or managing requests processed by the serverbot framework 210. For example, the conversation context engine 224 may establish a context based on the configuration of the process control system 102, identify topics associated with the context (e.g., requests associated with the first field device 116, the second field device 118, etc.), and determine one or more actions associated with the topics. For example, the conversation context engine 224 may determine that the context of requests 201a-b from user 104, host application 106, wearable devices 128, 130, 132, etc. is the process control system 102 in Figures 1A-1B. Based on determining that the context of a request is the process control system 102, the conversation context engine 224 may coordinate and / or generate a process-centric response. The conversation context engine 224 can determine that the context of a request is the process control system 102 by mapping the identified topics included in the request to configurations loaded into the database 124 in Figures 1A and 1B, and the conversation context database 244 in Figure 2. In such an example, the conversation context engine 224 may execute one or more scripts to perform one or more actions, return information associated with the topic, and / or a combination thereof.

[0080] In the example shown in Figure 2, the conversation context engine 224 includes a conversation processor 238 that assembles, compiles, and / or aggregates scripts or other lists of automated tasks, each containing one or more actions. For example, the conversation processor 238 may receive requests 201a~b from user 104 via the serverbot framework 210. Based on the requests, the conversation processor 238 may identify one or more actions, one or more return parameters (e.g., the values ​​of one or more return parameters), and / or combinations thereof. For example, user 104 may issue a request such as, "Show me FV-105." The serverbot framework 210 may process the requests and send the processed requests to the conversation processor 238. The conversation processor 238 may identify the requests as requests for information associated with the field device to which the specifier FV-105 is assigned. In such examples, the conversational processor 238 retrieves parameters associated with the field device, including MODE, OUT, and STATUS, aggregates the retrieved parameters into a response, and sends the response to the user 104 via the server bot framework 210. In some examples, the response is communicated to the user 104 through verbal communication. In some examples, the response is communicated to the user 104 via the host application 106 (e.g., displaying the response on a display, communicating the response with a speaker coupled to the computing device).

[0081] The conversation processor 238 in Figure 2 aggregates scripts based on information retrieved and / or obtained from an exemplary conversation context database 244. In some examples, the conversation processor 238 queries the conversation context database 244 for information based on an exemplary topic 246. For example, the conversation processor 238 may map topic 246 to information contained in the conversation context database 244 based on the name or description of a field device, the type of field device, etc. In such an example, the conversation processor 238 may map topic 246 containing the name or description of a field device (e.g., FV-105, FIC-205, etc.) to an exemplary configuration 248a, an exemplary script 248b, etc. associated with topic 246. For example, in response to the mapping of topic 246 for FV-105 associated with a first field device 116 to the conversation context database 244 for FV-105, the conversation processor 238 may obtain the MODE, OUT, and STATUS parameters of the first field device 116 in Figures 1A-1B.

[0082] In some examples, the conversation processor 238 maps topics 246, which include the type of field device (e.g., valves, pressure transmitters, process tanks, etc.), to configurations, scripts, etc., associated with topic 246. For example, the conversation processor 238 may obtain a list of field devices that match and / or are associated with topic 246. In such an example, the conversation processor 238 may obtain a list of valves, including FV-101, FV-102, FV-103, etc. in Figure 1A, by mapping topic 246 for "valves" (e.g., a request by user 104 such as "Which valves are operating?") to the conversation context database 244, based on the identified context of the process control system 102.

[0083] In some examples, the conversation processor 238 aggregates and / or generates scripts, templates, etc., by retrieving one or more exemplary actions 250 from the conversation context database 244 based on a topic 246. For example, the conversation processor 238 may map a topic 246 (e.g., name, device type, etc.) to the conversation context database 244. Based on the mapping, the conversation processor 238 may retrieve one or more actions 250 from the conversation context database 244 and generate scripts, templates, etc., based on the retrieved actions 250. In some examples, the action 250 is a basic action. For example, a basic action may correspond to a one-to-one request for a request to open a valve and a command-type action as the corresponding command to open the valve. In other examples, a basic action may correspond to a request for information (parameter values, safety information, etc.). For example, a basic action may correspond to a one-to-one information request, such as a request for a current safety alert and a corresponding request containing one or more safety alerts, or confirmation that there are no safety alerts to report.

[0084] In some examples, action 250 is a compound action. For example, a compound action may correspond to a workflow that includes two or more actions, such as a request to fill process tank 122 in Figures 1A and 1B. In such an example, the compound action includes actions to open FV-101 and / or FV-102 in Figures 1A and 1B, while obtaining flow measurements via FI-201 and / or FI-202 and measuring the level of process tank 122 via FI-206, FI-207, and / or FI-208. For example, conversation processor 238 may obtain the compound action associated with the request to fill process tank 122 and generate a script that executes the compound action based on the retrieved compound action, which includes the relevant action 250. In some examples, action 250 includes a script that executes a basic action, a compound action, and so on.

[0085] In the example shown in Figure 2, the conversation context engine 224 includes an action processor 240 that executes and / or facilitates the execution of a script generated by the conversation processor 238. In some examples, the action processor 240 executes a script or a set of commands, instructions, etc., by interacting with one or more of the systems 222 in Figure 2. The systems 222 in Figure 2 include an exemplary process control system 252 and an exemplary process control network system 254. Alternatively, the systems 222 may include fewer or more systems than those shown in Figure 2.

[0086] The process control system 252 in Figure 2 is a system that monitors and / or controls aspects of operation performed in a process environment, such as the manufacture of components or the processing of chemical raw materials. For example, the process control system 252 in Figure 2 may correspond to the process control system 102 in Figures 1A and 1B. The process control system 252 in Figure 2 includes at least one controller (e.g., a first controller 228, a second controller 230, etc.) with inputs and outputs, and the controller(s) may enable the controller(s) to acquire signals from various input field devices and / or instruments and control various output field devices and / or instruments. For example, the process control system 252 in Figure 2 may correspond to an Emerson® DeltaV® distributed control system (DCS) including at least one Emerson® DeltaV® controller.

[0087] In some examples, the action processor 240 facilitates script execution by generating and / or sending commands to the process control system 252 in Figure 2. For example, the action processor 240 may generate a command to open the first field device 116 in Figures 1A and 1B and send the command to the controller managing the control loop 120 to open the first field device 116. In other examples, the action processor 240 may generate a set of commands to be executed simultaneously or sequentially by the process control system 252 in Figure 2. For example, the action processor 240 may generate a set of commands to open FV-101, FV-102, and FV-103 and to fill the process tank 122 in Figures 1A and 1B substantially simultaneously, while disabling fluid pumps (FPs) such as FP-101 shown in Figures 1A and 1B (simultaneously, according to, for example, physical limitations, propagation delays, processing delays, etc., of the commanded field devices).

[0088] In some examples, the action processor 240 facilitates script execution by requesting information from the process control system 252. For example, the action processor 240 may retrieve information associated with a first field device 116, including one or more parameter values. For example, the action processor 240 may query the control loop 120 (for example, the controller controlling the control loop 120) for parameters associated with the first field device 116 and the second field device 118, such as MODE, OUT, and status. In response to the query, the action processor 240 may retrieve one or more parameter values ​​and send them to the conversation processor 238 to package them into a response.

[0089] The process control network system 254 in Figure 2 is a system communicatively coupled to at least one of the process control system 252 or VA100. In some examples, the process control network system 254 is a cloud-based network that monitors and / or controls multiple process control systems. For example, the process control network system 254 may support one or more Open Platform Communications (OPC) servers that translate hardware communication protocols from multiple controllers included in multiple process control systems into the OPC protocol and / or any other communication protocol. In some examples, the process control network system 254 may enable cloud-based data storage, analytics, big data analytics, deep machine learning, etc., to enable scale modeling of multi-process control environments, highly efficient operation and automation of digital process control, prognosis health monitoring, component reliability analysis, process control management, and / or optimization based on information acquired and / or processed by multiple process control systems (e.g., process control system 102 in Figures 1A-1B).

[0090] In some examples, the action processor 240 facilitates script execution by generating commands and / or sending them to the process control network system 254. For example, the action processor 240 may generate a command to perform an emergency shutdown of two or more process control systems included in and / or monitored by the process control network system 254. For example, the action processor 240 may generate and send a set of actions that the process control network system 254 can implement to perform an emergency shutdown.

[0091] In some examples, the action processor 240 facilitates script execution by requesting information from the process control network system 254. For example, the action processor 240 may query the process control network system 254 to determine prognosis health monitoring information associated with the first field device 116. For example, user 104 may request VA 100 to estimate the amount of lifecycle remaining for the first field device 116. In such an example, the action processor 240 may send information to the process control network system 254 associated with the first field device 116, including the serial number, manufacturer part number, device type, number of cycles performed (e.g., number of valve opening and closing operations), and time minutes since the last maintenance event. In response to receiving information, the process control network system 254 may map the information to a previously analyzed field device having substantially similar information (e.g., same manufacturer part number, number of cycles within the acceptable range of 100 cycles, time in minutes such as within 5 days), and determine the failure rate (e.g., mean failure rate, failure rate range, etc.) based on the data associated with the previously analyzed field device. In response to at least the mapping and determination, the process control network system 254 may transmit the failure rate and / or other prognostic health monitoring information to the action processor 240, which may transmit the failure rate and / or other prognostic health monitoring information to the conversation processor 238 for inclusion in the response to the server bot framework 210. For example, the action processor 240 may transmit the failure rate, including the time in minutes until expected failure and the number of cycles until expected failure, to the user 104, the host application 106, and the wearable devices 128, 130, and 132. In such an example, the action processor 240 may send safety alerts based on the failure rate, impending failure, etc.

[0092] In the example shown in Figure 2, the conversation context engine 224 includes a conversation state handler 242 that stores and / or maintains the state of a conversation initiated by a user 104, a host application 106, wearable devices 128, 130, 132, etc. In some examples, the conversation state corresponds to a topic identified on the basis of a request. For example, the conversation state handler 242 may assign a topic such as FV-105 to the conversation state and / or associate it in other ways. In such an example, the conversation state handler 242 may allow the user 104, the host application 106, wearable devices 128, 130, 132, etc. to request additional details or levels of information about the topic FV-105, drill deeper into the topic, or use the topic to branch or transition to another topic of interest (e.g., related topics) such as FIC-205, FI-205, etc. For example, the conversation state handler 242 can reduce the computational power used by the conversation processor 238 to process additional requests by referencing the conversation state, generating responses, and / or packaging them. For example, instead of processing the request without working from a baseline or starting point, the conversation processor 238 may query the conversation state handler 242 for the conversation state, such as providing user 104 with additional actions that can be completed by FV-105, and notifying user 104 of additional components that are communicably coupled to FV-105.

[0093] In some examples, the conversation state corresponds to the status (e.g., completion status) of a script being executed by the action processor 240. For example, the action processor 240 may perform a workflow such as providing user 104 with step-by-step instructions on how to replace the first field device 116 in Figures 1A-1B with a substantially similar field device (e.g., a field device with the same model, manufacturer part number, operating rating, hazardous area classification, etc.). In such an example, the action processor 240 may send information to the conversation state handler 242, including the current or momentary step or action being performed by the action processor 240, subsequent steps or actions to be performed, and the total number of steps or actions to be performed. In response to receiving information from the action processor 240, the conversation state handler 242 may provide the information to the conversation processor 238 to generate a response to user 104. For example, the conversation state handler 242 may send the next step or action to be performed, completion status (e.g., the amount of steps to be completed, the estimated time in minutes to complete the steps, etc.) to the conversation processor 238, and based on the information received from the conversation state handler 242, the conversation processor 238 may generate a response and communicate it to the user 104.

[0094] In some cases, the conversation state handler 242 modifies or updates the conversation state. For example, the conversation state handler 242 may update the conversation state based on a new topic requested by user 104, host application 106, wearable devices 128, 130, 132, DCS controller assembly 226, etc. The conversation state handler 242 may change the conversation state from FV-105 to FV-106 based on user 104 requesting information about FV-106. In some cases, the conversation state handler 242 cancels or deletes the conversation state. For example, the conversation state handler 242 may separate FV-105 from the conversation state and / or cancel the conversation state of FV-105 based on at least one of the users 104 who cancels the conversation with VA100, and request information about another field device such as FV-104, or user 104 who notifies VA100 that no additional information corresponding to FV-105 is needed.

[0095] In some cases, the conversation state handler 242 may infer that it is branching or transitioning to a new topic. For example, the conversation state handler 242 may determine that user 104 has left the first coverage area of ​​the first beacon 134a and entered the second coverage area of ​​the second beacon 134b. In such an example, the conversation state handler 242 may instruct the action processor 240 to query the process control network system 254 based on one or more field devices included in the second coverage area to determine the next topic of interest.

[0096] In some examples, if the conversation state handler 242 determines that user 104, host application 106, etc., has exhausted all possible or potential responses associated with a topic related to filling process tank 122, the conversation state handler 242 presumptively branches to a new topic. In such examples, the conversation state handler 242 may query the process control network system 254 to instruct the action processor 240 to determine what topic is likely to be of interest next. For example, the process control network system 254 may perform and / or execute machine learning algorithms to determine the topic selected after filling the process tank of another process control system (e.g., one or more process control systems outside of process control system 102 in Figures 1A-1B). For example, the process control network system 254 may determine that a topic associated with emptying a process tank was selected a considerable time after filling the process tank (e.g., 40% of the time, 75% of the time, etc.). In such an example, the process control network system 254 may send a presumably identified topic to the conversation state handler 242 via the action processor 240. In such an example, the conversation state handler 242 may instruct the conversation processor 238 to map the new topic to one or more actions, one or more configurations, one or more scripts, etc., contained in the conversation context database 244.

[0097] By predictively fetching new topics, the conversation processor 238 may provide a response to user 104 if user 104 issues a request associated with the new topic. The conversation processor 238 may anticipate the next step and / or attempt to get ahead of user 104, such as during periods when the conversation processor 238 is idle and not processing requests. In some examples, the conversation processor 238 prompts user 104 to perform an action associated with the predictively fetched topic. For example, user 104 may have forgotten to perform an action and is reminded to do so by VA 100 prompting them regarding the predictively fetched topic. If user 104 issues a request associated with a topic different from the predictively fetched topic, the conversation processor 238 may prompt user 104 to determine whether to select the predictively fetched topic. Alternatively, if user 104 refuses to select the predictively fetched topic, the conversation processor 238 may instruct the conversation state handler 242 to replace the predictively fetched topic with the requested topic.

[0098] In the example shown in Figure 2, the conversation context engine 224 may support conversations instantiated on an external computing system, such as an exemplary container repository 256. The container repository 256 contains a container or container image that corresponds to a lightweight, standalone executable package of software, containing everything necessary for the software to run, including code, runtime, system tools, system libraries, and configuration. Containers isolate the software from the software environment, for example, between a development environment and a staging environment.

[0099] In some examples, the conversation context engine 224 queries the container repository 256 to determine if there is a corresponding container capable of executing a topic (e.g., a long-running workflow, a composite topic, etc.). In response to determining that there is a corresponding container for a topic, the conversation context engine 224 may instruct the corresponding container to execute the topic. For example, a container in the container repository 256 may execute software (e.g., machine-readable instructions) to perform actions associated with the topic. The container may send notifications to the user 104, such as commands to the system 222, conversation status to the conversation context engine 224, or via the conversation context engine 224. In such examples, the conversation context engine 224 may delegate and / or offload composite topics to external systems (e.g., containers in the container repository 256, one or more systems 222, etc.) to reduce the processing utilization, memory resources, storage resources, etc. of the conversation context engine 224.

[0100] Figure 2 shows an exemplary method for implementing the VA100 in Figures 1A and 1B, but one or more of the elements, processes, and / or devices shown in Figure 2 may be combined, divided, rearranged, omitted, deleted, and / or implemented in other ways. Furthermore, the exemplary server bot framework 210, exemplary framework controller 212, exemplary parser 214, exemplary analyzer 216, exemplary generator 218, exemplary execution unit 220, exemplary conversation context engine 224, exemplary conversation processor 238, exemplary action processor 240, exemplary conversation state handler 242, exemplary conversation context database 244, exemplary topic 246, exemplary configuration 248a, exemplary script 248b, exemplary action 250, and / or more generally, the exemplary VA100 may be implemented by hardware, software, firmware, and / or any combination of hardware, software, and / or firmware. Therefore, for example, an exemplary serverbot framework 210, an exemplary framework controller 212, an exemplary parser 214, an exemplary analyzer 216, an exemplary generator 218, an exemplary execution unit 220, an exemplary conversation context engine 224, an exemplary conversation processor 238, an exemplary action processor 240, an exemplary conversation state handler 242, an exemplary conversation context database 244, an exemplary topic 246, an exemplary configuration 248a, an exemplary script 248b, an exemplary action 250, and / or more generally, any of the exemplary VA100 may be implemented by one or more analog or digital circuits, logic circuits, programmable processors, programmable controllers, graphics processing units (GPUs), digital signal processors (DSPs), application-specific integrated circuits (ASICs), programmable logic devices (PLDs), and / or field-programmable logic devices (FPLDs).Having read any of the claims of the apparatus or system of this patent, you are expressly certain that a purely software and / or firmware implementation, at least one of the exemplary serverbot frameworks 210, exemplary framework controller 212, exemplary parser 214, exemplary analyzer 216, exemplary generator 218, exemplary execution unit 220, exemplary conversation context engine 224, exemplary conversation processor 238, exemplary action processor 240, exemplary conversation state handler 242, exemplary conversation context database 244, exemplary topic 246, exemplary configuration 248a, exemplary script 248b, and / or exemplary action 250 is expressed herein to include a non-temporary computer-readable storage device or a storage disk such as memory, a digital versatile disk (DVD), a compact disk (CD), or a Blu-ray® disk (including software and / or firmware). Furthermore, the exemplary VA100 in Figures 1A and 1B may include, in addition to or instead of, those shown in Figure 2, one or more elements, processes, and / or devices, and / or two or more of any or all of the elements, processes, and devices described. As used herein, the phrase “communicating” includes, including its variations, direct communication and / or indirect communication via one or more intermediate components, and does not require direct physical (e.g., wired) communication and / or continuous communication, but rather further includes selective communication at periodic intervals, scheduled intervals, aperiodic intervals, and / or one-time events.

[0101] Figure 3 shows an exemplary table of exemplary profiles 300 corresponding to the process tank 122 of the process control system 102 in Figures 1A-1B. Profile 300 may correspond to parts of the configuration of the process control system 102 loaded in databases 124 in Figures 1A-1B, conversation context database 244 in Figure 2, etc. For example, profile 300 may correspond to topics. In such examples, profile 300 corresponds to topics of the process tank 122 in Figures 1A-1B based on the context of the process control system 102. In some examples, VA100 in Figures 1A-2 is initialized by loading the configuration associated with the process control system 102 in Figures 1A-1B into conversation context database 244. The configuration may include information associated with one or more components of the process control system 102. For example, the configuration may include one or more parameters associated with a first field device 116, a second field device 118, etc. The configuration may include information about field devices included in the control loop 120.

[0102] In some examples, the configuration includes associations between field devices, control loops, and / or combinations thereof. For example, the configuration may include associations or relationships between FI-207, FIC-207, and FV-106 as shown in Figures 1A and 1B, which may include descriptions of methods such as physical coupling of FI-207, FIC-207, and FV-106 (e.g., wiring diagrams, cable schedules, termination diagrams, etc.) and communicable coupling (e.g., communication protocol addressing schemes, Internet Protocol (IP) address tables, etc.). In some examples, the configuration may include multiple profiles, including profile 300 in Figure 3, and associations with one of the multiple profiles (e.g., the dependency of one profile on another).

[0103] In some examples, the conversation processor 238 generates a profile 300. For example, the conversation processor 238 may identify topics included in requests 201a-b in Figure 2 from a user 104, a host application 106, etc., where the topics are the first field device 116 and the process tank 122. In such an example, the conversation processor 238 may map the topics of the first field device 116 to a lookup table or other data structure contained in the conversation context database 244. In other words, the conversation processor 238 may map and / or perform the mapping of the first field device 116 to a lookup table or any other data structure contained in the conversation context database 244. In some examples, the lookup table is configuration-based. For example, the lookup table may include associations between the first field device 116 and one or more parameters corresponding to one or more parameters associated with the first field device 116, and one or more actions that can be performed and / or implemented. The conversation processor 238 may retrieve one or more parameters, one or more actions, etc., from the conversation context database 244 and generate a profile (e.g., profile 300 in Figure 3) based on at least one of the one or more parameters and one or more actions, etc. The conversation processor 238 may store profile 300 in the conversation context database 244 for future processing.

[0104] In the example shown in Figure 3, the profile 300 includes fields such as exemplary level 302, exemplary category 304, exemplary parameter 306, exemplary tag 308, and exemplary description 310. The profile 300 in Figure 3 includes level 302, which organizes the information associated with the process tank 122 into a hierarchy or sequence of access by the VA 100. For example, the first level (L1) may correspond to the first layer of information provided to user 104, host application 106, etc., in response to a request in Figures 1A-2. For example, user 104 may issue a request such as "Show me the process tank" via the mobile application 202 in Figure 2. In such an example, the VA 100 may display the information contained in L1 to user 104 via the mobile application (e.g., by displaying the information on the display of the mobile device running the mobile application 202). In another example, the VA 100 may communicate the information contained in L1 (e.g., an oral statement via a speaker connected to the host application 106) to user 104 via the host application 106. In response to a user 104 requesting additional information, such as "Please show me more information about the process tank" or "Please tell me more about the process tank," VA100 may transmit and communicate the information contained in the second level (L2) to user 104 via audible communication, host application 106, etc. Alternatively, profile 300 may include fewer or more levels 302 than those shown in Figure 3.

[0105] In the example shown in Figure 3, profile 300 includes categories 304 that organize information associated with process tank 122 based on the frequency of requested information or at least one of the components of process tank 122. For example, categories 304 may correspond to the frequency with which the information included in profile 300 is requested. For example, categories 304 may have values ​​such as common, standard, non-common, rare, etc., corresponding to the frequency with which information is requested by users 104, host applications 106, wearable devices 128, 130, 132, DSC controller assembly 226, etc. In other examples, categories 304 may correspond to components of process tank 122, such as the surge drum of process tank 122. Alternatively, profile 300 may include fewer or more categories 304 than those shown in Figure 3.

[0106] In the example shown in Figure 3, the profile 300 includes a parameter 306 that represents a value associated with at least one of the corresponding levels 302 or categories 304 of the process tank 122 in Figures 1A and 1B. In the profile 300 of Figure 3, the parameter 306 includes the vessel level, vessel pressure, inflow / outflow, temperature, and vessel temperature. For example, in response to receiving an initial inquiry about the process tank 122, the VA 100 can return information associated with the vessel level parameter to the user 104. For example, the vessel level parameter may correspond to values ​​measured by FI-206, FI-208, etc., in Figures 1A and 1B.

[0107] In the example shown in Figure 3, profile 300 includes a tag 308 representing at least a specifier associated with parameter 306 (e.g., a process control specifier). In some examples, tag 308 is a software specifier. For example, tag 308 may correspond to an address and / or label such as a communication protocol or process control schema assigned to a container-level parameter associated with process tank 122. In some examples, tag 308 is a physical specifier (e.g., a physical tag attached to process tank 122, a label affixed to process tank 122 that contains or depicts the tag). For example, a container-level parameter may be assigned the tag L XX27. In such an example, VA 100 can return at least the tag 308 associated with the container-level parameter in response to a user 104, host application 106, wearable devices 128, 130, 132, etc., requesting information associated with process tank 122.

[0108] In the example shown in Figure 3, profile 300 includes a description 310 representing additional information that may be provided in response to a request. For example, the information contained in description 310 may be packaged in a response to user 104 in response to user 104 requesting additional information associated with at least parameter 306. For example, user 104 may ask VA 100, “What is the level of the process tank?” In response to the request, VA 100 may verbally respond, “The container level with the L XX27 tag is 80% full.” User 104 may issue a follow-up request, “Please provide more information about the level.” VA 100 may respond, “The container level is the most important parameter of the knockout pot.” Additionally or alternatively, the information contained in description 310, and / or more generally, profile 300 in Figure 3 may be displayed on the host application 106. In another example, user 104 may issue a request, “Tell me about the surge drum.” In response to a request, VA100 may verbally respond with the values ​​of the inflow / inflow / outflow parameters and / or corresponding tags. VA100 may not return temperature parameters and / or temperature tags based on the corresponding "if requested" description. For example, VA100 may not return information associated with the surge drum temperature unless requested by user 104.

[0109] Figure 4 shows the first exemplary visualization corresponding to the exemplary profile 300 in Figure 3. things This is a schematic diagram of 400. Figure 4 is the first visualization. things 400 is the first level visualization associated with L1 of profile 300 in Figure 3. things This corresponds to the first visualization. things 400 may correspond to different levels. First visualization things 400 may be displayed via the host application 106 in Figures 1A-2 in response to requests 201a-b in Figure 2 from users 104, host application 106, wearable devices 128, 130, 132, etc. First visualization things400 includes a schematic diagram of the process tank 122 in Figures 1A and 1B. First visualization things 400 includes tag 308 associated with L1 of profile 300 in Figure 3. For example, the first visualization things 400 includes tags 308 associated with the container level parameter (L XX27), container pressure parameter (P XX27), and inflow / outflow parameter (F XX27). In some examples, based on the request for additional information, VA100 performs a first visualization. things 400 can be updated. For example, tag 308 associated with temperature parameter (T XX27) may be updated in response to a request for additional information on process tank 122. things It can be displayed above 400.

[0110] Figure 5 shows a second exemplary visualization corresponding to the exemplary profile 300 in Figure 3. things This is a schematic diagram of 500. Figure 5 is the second visualization. things 500 is the second level visualization associated with L2 of profile 300 in Figure 3. things This corresponds to the second visualization in Figure 5. things 500 contains information associated with the first and second levels of profile 300. Alternatively, the second visualization things 500 may describe information associated only with the second level of profile 300.

[0111] Second visualization things 500 can be displayed via the host application 106 in Figures 1A and 2 in response to requests from users 104, host applications 106, etc. Second visualization things 500 includes the diagram of process tank 122 in Figures 1A and 1B. Second visualization things 500 includes tags 308 associated with the first and second levels of profile 300 in Figure 3. For example, the second visualization things500 includes tags 308 associated with the container level parameter (L XX27), container pressure parameter (P XX27), inflow / outflow parameter (F XX27), temperature parameter (T XX27), and container temperature parameter (T XX27). For example, user 104 may request information associated with process tank 122 from VA100. VA100 is shown in the first visualization in Figure 4. things A first response may be generated that includes the tag 308 shown in 400. For example, based on the first response, the host application 106 generates a first visualization that includes the tag 308 shown in Figure 4. things 400 may be displayed. User 104 may request additional information corresponding to process tank 122 from VA100. In response to the request, VA100 displays the second visualization in Figure 5. things A second response may be generated that includes the tag 308 shown in 500. For example, the host application 106 may generate a second visualization that includes the tag 308 shown in Figure 5 based on the second response. things 500 can be displayed. For example, the host application 106 displays the first visualization things 400 as a second visualization things It can be replaced with 500. Alternatively, the host application 106 adds the additional tag 308 in Figure 5 to the first visualization. things It can be added to 400.

[0112] Figures 6 and 7 show flowcharts representing exemplary hardware logic, machine-readable instructions, hardware implementation state, and / or any combination thereof for implementing the VA100 shown in Figures 1A and 2. The machine-readable instructions may be an executable program or part of an executable program for execution by a computer processor, such as the processor 812 shown in the exemplary processor platform 800 described below in relation to Figure 8. The program may be embodied as software stored on a non-temporary computer-readable storage medium such as a CD-ROM, floppy disk, hard drive, DVD, Blu-ray® disc, or memory associated with the processor 812, but the entire program and / or part thereof may alternatively be executed by a device other than the processor 812 and / or embodied in firmware or dedicated hardware. Furthermore, while exemplary programs are described with reference to the flowcharts shown in Figures 6 and 7, many other methods for implementing exemplary VA100 may be used alternatively. For example, the execution order of blocks may be changed, and / or some of the described blocks may be modified, deleted, or combined. Additionally or alternatively, any or all of the blocks may be implemented by one or more hardware circuits (e.g., separate and / or integrated analog and / or digital circuits, FPGAs, ASICs, comparators, operational amplifiers (op-amps), logic circuits, etc.) configured to perform the corresponding operations without running software or firmware.

[0113] As described above, the exemplary processes in Figures 6 and 7 may be implemented using executable instructions (e.g., computer and / or machine-readable instructions) stored in non-temporary computer and / or machine-readable media, such as hard disk drives, flash memory, read-only memory, compact disks, digital multipurpose disks, caches, random access memory, and / or any other storage device or storage disk where information is stored for any period of time (e.g., for temporary buffering and / or information caching, for long-term, persistent, or short-term instances). The term “non-temporary computer-readable media” as used herein is explicitly defined to include any type of computer-readable storage device and / or storage disk, excluding propagating signals and excluding transmission media.

[0114] The terms “include” and “complement” (and all their forms and tenses) are used herein as open-form terms. Therefore, when a patent claim uses either “include” or “complement” as a preamble or within any kind of claim description (e.g., provide, include, provide, include, have, etc.), it should be understood that additional elements, terms, etc., may exist without falling outside the scope of the corresponding claim or description. The phrase “at least” is open-form in the same manner as the terms “complement” and “include” are open-form when used as a transitional term, for example, in the preamble of a patent claim. For example, the term “and / or” when used in the form A, B, and / or C refers to any combination or subset of A, B, and C, such as (1) A only, (2) B only, (3) C only, (4) A and B, (5) A and C, (6) B and C, and (7) a combination of A, B, and C. As used herein in contexts describing structures, components, items, objects, and / or things, the phrase “at least one of A and B” is intended to refer to an implementation comprising (1) at least one A, (2) at least one B, and (3) either at least one A or at least one B. Similarly, as used herein in contexts describing structures, components, items, objects, and / or things, the phrase “at least one of A or B” is intended to refer to an implementation comprising (1) at least one A, (2) at least one B, and (3) either at least one A or at least one B. As used herein in contexts describing the execution or performance of processes, instructions, actions, activities, and / or steps, the phrase “at least one of A and B” is intended to refer to an implementation comprising (1) at least one A, (2) at least one B, and (3) either at least one A or at least one B.Similarly, as used herein in contexts describing the implementation or execution of a process, instruction, action, activity, and / or step, the phrase “at least one of A or B” is intended to refer to implementations comprising (1) at least one A, (2) at least one B, and (3) either at least one A and at least one B.

[0115] Figure 6 is a flowchart representing an exemplary machine-readable instruction 600 that may be executed to implement VA100 in Figures 1A-2 to generate and execute a script based on a request. The machine-readable instruction 600 begins in block 602, in which VA100 determines whether a request has been received. For example, the framework controller 212 in Figure 2 may determine that user 104 has issued the first request 201a in Figure 2 to VA100 via one of the wearable devices 128, 130, or 132, the DCS controller assembly 226, etc., to open the first field device 116 in Figure 1A. In another example, the framework controller 212 may determine that host application 106 has generated a second request 201b to VA100 to open the first field device 116.

[0116] If VA100 determines in block 602 that no request has been received, VA100 continues to wait for a request. If VA100 determines in block 602 that a request has been received, VA100 parses the request in block 604. For example, the parser 214 in Figure 2 may parse requests 201a~b into one or more tokens. In response to the parsing of the request in block 604, VA100 verifies the request in block 606. For example, the analyzer 216 in Figure 2 may compare one or more tokens with valid tokens.

[0117] In block 608, VA100 is requested validThe analyzer determines whether or not. For example, based on a comparison of the analyzed tokens with valid tokens, the analyzer 216 may determine that requests 201a and 201b are invalid by determining that one or more tokens are invalid, or that the order of the tokens is not in a valid order. In another example, the analyzer 216 may determine that requests 201a and 201b are valid based on one or more of the analyzed tokens that have been identified as valid tokens. In other words, the analyzer 216 may determine that requests 201a and 201b are valid based on the identification of the verified tokens.

[0118] In block 608, the request is Ineffective If VA100 determines that this is the case, control proceeds to block 610 to generate and send a clarification request. For example, the generator 218 in Figure 2 may generate a clarification request and send it to user 104, host application 106, wearable device 128, 130, 132, etc. In such an example, the clarification request may include prompts such as repeating the request, rephrasing the request, or providing another request. In response to generating and sending the clarification request, control returns to block 602 to determine whether to receive another request.

[0119] In block 608, the request is EffectiveIf VA100 determines that this is the case, then in block 612, VA100 determines whether the conversation state is available. For example, the conversation processor 238 may query the conversation state handler 242 in Figure 2 to determine whether the conversation has been instantiated and / or initialized. In such an example, the conversation processor 238 may determine that the conversation state is not available on the basis that the conversation state has not been instantiated and the corresponding conversation state is not stored and / or managed by the conversation state handler 242. In another example, the conversation processor 238 may determine that the conversation state is available on the basis that the conversation has been instantiated and the corresponding conversation state is stored and / or managed by the conversation state handler 242. For example, the conversation state handler 242 may send conversation state such as the topic, the completion status of the script, and the actions being performed by the action processor 240 to the conversation processor 238.

[0120] In block 612, if VA100 determines that a conversation state is available, control proceeds to block 616 to identify a topic. In block 612, if VA100 determines that a conversation state is not available, in block 614, VA100 establishes a conversation state. For example, the conversation processor 238 may initialize a conversation and send the corresponding conversation state to the conversation state handler 242. In response to the establishment of the conversation state, VA100 identifies a topic in block 616. For example, the conversation processor 238 may identify a topic for the first field device 116 based on a processed request obtained from the serverbot framework 210 in Figure 2.

[0121] In block 618, VA100 generates a script. For example, conversation processor 238 may map topic 246 in Figure 2 to one or more configurations 248a, one or more scripts 248b, one or more actions 250, and / or combinations thereof in conversation context database 244 in Figure 2. In such an example, conversation processor 238 may package the script based on the mapping. For example, conversation processor 238 may generate a script that includes one or more configurations 248a, one or more scripts 248b, one or more actions 250, and / or combinations thereof in which topic 246 is mapped in conversation context database 244.

[0122] In response to script generation, VA100 executes the script in block 620. For example, the action processor 240 in Figure 2 can send a command to one of the systems 222 in Figure 2 to facilitate the execution of the script generated by the conversation processor 238. For example, the action processor 240 can generate a command to the process control system 102 in Figures 1A-1B to open the first field device 116.

[0123] In block 622, VA100 updates the conversation state. For example, the conversation state handler 242 may update the conversation state to complete in response to opening the first field device 116. In another example, the conversation state handler 242 may update the conversation state from opening the first field device 116 to opening the first field device 116, to opening the first field device 95%, and so on.

[0124] In response to an update in the conversation state, VA100 generates a response in block 624 and sends it to the requester. For example, conversation processor 238 may package the response, indicating that the first field device 116 is open and / or the valve position of the first field device 116, and send the response to user 104, host application 106, one of wearable devices 128, 130, 132, DCS controller assembly 226 in Figure 2, etc.

[0125] In block 626, VA100 determines whether the script is complete. For example, the conversation state handler 242 may determine that a script associated with a request from user 104, host application 106, etc. is complete based on the action processor 240 completing all actions contained in the script. In another example, the conversation state handler 242 may determine that a script is not complete based on one or more actions that should be completed by the action processor 240 and / or user 104, host application 106, etc., without issuing a confirmation that the script is complete.

[0126] In block 626, if VA100 determines that the script is complete, control proceeds to block 630 to determine whether to continue monitoring the request. In block 626, if VA100 determines that the script is not complete, in block 628, VA100 determines whether the requester has ended the conversation. For example, the conversation processor 238 may determine whether user 104, host application 106, etc., have generated a command to VA100 to end the conversation.

[0127] In block 630, VA100 determines whether to continue monitoring the request. If VA100 determines in block 630 to continue monitoring the request, control returns, and it waits for another request, and in block 602 it determines whether another request is received. If VA100 determines in block 630 not to continue monitoring the request, the machine-readable instruction 600 in Figure 6 terminates.

[0128] Figure 7 shows the visualization based on the requirements. things This flowchart represents an exemplary machine-readable instruction 700 that may be executed to implement VA100 in Figures 1A and 2 in order to generate and display the following. The machine-readable instruction 700 begins with block 702, where VA100 determines whether a request has been received. For example, the framework controller 212 in Figure 2 may determine that user 104 has issued a verbal request to VA100 via host application 106, "Show me the process tank." In another example, the framework controller 212 may determine that host application 106 has generated a request to VA100 to retrieve information about process tank 122 in Figures 1A and 1B.

[0129] If VA100 determines in block 702 that no request has been received, VA100 continues to wait for the request. If VA100 determines in block 702 that a request has been received, VA100 parses the request in block 704. For example, the parser 214 in Figure 2 may parse requests 201a~b in Figure 2 into one or more tokens. In response to the parsing of the request in block 704, VA100 verifies the request in block 706. For example, the analyzer 216 in Figure 2 may compare one or more tokens with valid tokens.

[0130] In block 708, VA100 is requested validThe analyzer determines whether or not. For example, the analyzer 216 may determine that a request is invalid by comparing the analyzed tokens with valid tokens and determining that one or more tokens are invalid, or that the order of the tokens is not in a valid order. In another example, the analyzer 216 may determine that requests 201a~b are valid based on one or more of the analyzed tokens that have been identified as valid tokens.

[0131] In block 708, the request is Ineffective If VA100 determines that this is the case, control proceeds to block 710, where it generates and sends a clarification request. For example, the generator 218 in Figure 2 may generate a clarification request and send it to user 104, host application 106, etc. In such an example, the clarification request may include prompts such as repeating requests 201a~b, paraphrasing requests 201a~b, and providing the other of requests 201a~b. In response to the generation and transmission of the clarification request, control returns and determines in block 702 whether to receive another request.

[0132] In block 708, the request is Effective If VA100 determines that this is the case, in block 712, VA100 determines whether the conversation state is available. For example, the conversation processor 238 may query the conversation state handler 242 in Figure 2 to determine whether the conversation has been instantiated and / or initialized. In such an example, the conversation processor 238 may determine that the conversation state is not available based on the fact that the conversation has been instantiated and the corresponding conversation state has been saved and / or managed by the conversation state handler 242. In other examples, the conversation processor 238 may determine that the conversation state is available based on the fact that the conversation has been instantiated and the corresponding conversation state has been saved and / or managed by the conversation state handler 242. For example, the conversation state handler 242 may send conversation state such as the topic, the completion status of the script, and the actions being performed by the action processor 240 to the conversation processor 238.

[0133] In block 712, if VA100 determines that a conversation state is available, control proceeds to block 716 to identify a topic. In block 712, if VA100 determines that a conversation state is not available, in block 714, VA100 establishes a conversation state. For example, the conversation processor 238 may initialize a conversation and send the corresponding conversation state to the conversation state handler 242. In response to the establishment of the conversation state, VA100 identifies a topic in block 716. For example, the conversation processor 238 may identify a topic in process tank 122 based on a processed request obtained from the server bot framework 210 in Figure 2.

[0134] In response to topic identification, VA100 maps the topic to a profile in block 718. For example, conversation processor 238 may map the topic of process tank 122 to profile 300 in Figure 3 within conversation context database 244 in Figure 2. In such an example, conversation processor 238 may determine, based on the mapping, that identified topics included in requests from user 104, host application 106, etc., correspond to process tank 122. Conversation processor 238 may determine information associated with process tank 122 based on the mapping, including which field devices of process control system 102 in Figures 1A-1B are coupled to process tank 122, and which field devices of process control system 102 monitor or perform measurements associated with process tank 122, etc. Additionally or alternatively, conversation processor 238 may determine information contained in profile 300, including parameters 306, tags 308, descriptions 310, etc.

[0135] In block 720, VA100 generates a response corresponding to the profile level. For example, conversation processor 238 may package a response containing information associated with L1 of profile 300. In such an example, the response may include information corresponding to at least one of the common categories or surge drum categories in Figure 3. For example, the response may include at least one of the following: container level parameters, container pressure parameters, corresponding tag 308, corresponding description 310, etc.

[0136] In block 722, VA100 sends a response to the host application. For example, the conversation processor 238 may send a response to the host application 106 via at least one of the host application bot framework 208 or the server bot framework 210. In such an example, the host application 106 is the first visualization in Figure 4. things 400 is generated and first visualizations are provided via the third wearable device 132 in Figure 1B, mobile application 202, browser application 204, desktop application 206, etc., such as a graphical user interface (GUI) and human-machine interface (HMI). things 400 can be displayed. For example, the host application 106 displays the first visualization on a lens, a mobile device, a desktop computer, a laptop computer display, or any other display communicatively coupled to a computing device. things 400 may be displayed. In another example, the conversation processor 238 may operate on and / or run on a host application 106 that is communicatively coupled to the DCS controller assembly 226 in Figure 2.

[0137] In block 724, VA100 updates the conversation state. For example, the conversation processor 238 may instruct the conversation state handler 242 to update the conversation state based on the response. For example, the conversation state handler 242 may assign L1 to a conversation state indicating that the information associated with L1 has been communicated to a requester such as user 104, host application 106, etc. In another example, the conversation state handler 242 may assign the topic of process tank 122 and / or L1 and / or the information sent to user 104, host application 106, etc., to the conversation state.

[0138] In block 726, VA100 visualizes the response on the host application. things For example, the serverbot framework 210 sends a response to the host application 106 to display a first visualization such as a GUI, HMI, etc. on the device running the host application 106. things It may be possible to instruct it to display 400.

[0139] Visualization things In response to the display, VA100 determines whether there are any displayable levels in block 728. For example, conversation processor 238 may determine that L2 has not been communicated to host application 106. In another example, conversation processor 238 may determine that parameters associated with L1, such as container pressure parameters, have not been communicated because user 104, host application 106, etc., have only requested container level parameters. In yet another example, conversation processor 238 may determine that one of the categories 304 has not been communicated based on requests for different categories of 304. In such an example, conversation processor 238 may determine to provide information that has not yet been requested or provided to user 104, host application 106, etc., in response to a request for additional information associated with process tank 122.

[0140] If VA100 determines in block 728 that there are no displayable levels, control proceeds to block 734 to determine whether to continue monitoring the request. If VA100 determines in block 728 that there are displayable levels, then in block 730, VA100 determines whether a request for further information about the topic has been received. For example, the framework controller 212 may determine whether the request was received from user 104, host application 106, etc. In response to the determination that a request has been received, the conversation processor 238 may determine whether the request is associated with a topic in process tank 122. If the conversation processor 238 determines that the request corresponds to a query for further information about process tank 122, the conversation processor 238 may obtain the conversation state from the conversation state handler 242, determine the information contained in profile 300, and package it into a response to the request. For example, the conversation processor 238 may obtain the conversation state in L1 from the conversation state handler 242, decide to package the information associated with L2 in the response, and send that response to the user 104, the host application 106, etc.

[0141] In block 730, if VA100 determines that the received request is for further information about the topic, control returns to block 720 to generate a response corresponding to the profile level. For example, conversation processor 238 may package information associated with L2 of profile 300 in the response, such as container temperature parameters, tag T XX27, and / or a combination thereof. In other examples, conversation processor 238 may package information associated with surge categories, other parameters, tags, or descriptions associated with common categories, as shown in Figure 3. In response to generating a response, VA100 proceeds to sending the response to the host application in block 722, updating the conversation state in block 724 (e.g., updating the conversation state to information associated with L2, L1, and / or L2), and visualization. thingsBased on the response, the visualization is displayed on the host application 106 to at least one of the third wearable device 132 or the host application 106. things It may be instructed to display the second visualization in Figure 5. For example, VA100 may instruct the host application 106 to display the second visualization in Figure 5. things The host application 106 may be executed, instructing it to display 500 on a mobile device, desktop computer, etc.

[0142] In block 730, if VA100 determines that the received request does not contain further information about the topic, then in block 732, VA100 determines whether a request timeout has occurred. For example, the framework controller 212 may determine that requests from user 104, host application 106, etc., were not received within a threshold time (e.g., 1 minute, 10 minutes, 60 minutes, etc.). In another example, the conversation processor 238 may determine that a request was received but is not directed to a topic in process tank 122. In such an example, the conversation processor 238 may instruct the conversation state handler 242 to update the conversation state and replace the conversation state with a new topic, or to separate the topic of process tank 122 from the conversation state. In yet another example, the conversation processor 238 may instruct the conversation state handler 242 to instantiate another conversation state so that it coexists with the conversation state associated with process tank 122.

[0143] If no request timeout occurs in block 732, control returns to block 730 and waits for another request. If a request timeout occurs in block 732, in block 734, VA100 determines whether to continue monitoring the request. For example, the framework controller 212 may decide to shut down VA100, or to transition VA100 to operate in low-power mode or hibernation mode.

[0144] In block 734, if VA100 determines to continue monitoring the request, control returns to block 702 and waits for another request. In block 734, if VA100 determines not to continue monitoring the request, the machine-readable instruction 700 in Figure 7 terminates.

[0145] Figure 8 is a block diagram of an exemplary processor platform 800 configured to execute the instructions in Figures 6 and 7 in order to implement the VA100 in Figures 1A and 2. The processor platform 800 could be, for example, a server, a personal computer, a workstation, a DCS controller assembly (e.g., DCS controller assembly 226 in Figure 2), a self-learning machine (e.g., a neural network), a mobile device (e.g., a mobile phone, a smartphone, a tablet such as iPad®), a personal digital assistant (PDA), an internet device, a headset or other wearable device (e.g., wearable devices 128, 130, and 132 in Figure 1), or any other type of computing device.

[0146] The processor platform 800 in the example shown includes a processor 812. The processor 812 in the example shown is hardware. For example, the processor 812 may be implemented by one or more integrated circuits, logic circuits, microprocessors, GPUs, DSPs, or controllers from any desired family or manufacturer. The hardware processor may be a semiconductor-based (e.g., silicon-based) device. In this example, the processor 812 implements the serverbot framework 210, the framework controller 212, the parser 214, the analyzer 216, the generator 218, the execution unit 220, the conversation context engine 224, the conversation processor 238, the action processor 240, the conversation state handler 242, and / or more generally, the VA100.

[0147] The processor 812 in the shown example includes local memory 813 (e.g., cache). The processor 812 in the shown example communicates with main memory, which includes volatile memory 814 and non-volatile memory 816, via bus 818. The volatile memory 814 may be implemented by synchronous dynamic random access memory (SDRAM), dynamic random access memory (DRAM), RAMBUS® dynamic random access memory (RDRAM®), and / or any other type of random access memory device. The non-volatile memory 816 may be implemented by flash memory and / or any other desired type of memory device. Access to main memory 814, 816 is controlled by a memory controller.

[0148] The example processor platform 800 also includes an interface circuit 820. The interface circuit 820 may be implemented by any type of interface standard, such as an Ethernet® interface, a Universal Serial Bus (USB), a Bluetooth® interface, a Near Field Communication (NFC) interface, and / or a PCI Express interface.

[0149] In the example shown, one or more input devices 822 are connected to the interface circuit 820. The input devices 822(or more) allow the user to input data and / or commands to the processor 812. The input devices 822(or more) can be implemented, for example, by a voice sensor, microphone, camera (still image or video), keyboard, button, mouse, touchscreen, trackpad, trackball, isopoint device, and / or voice recognition system.

[0150] One or more output devices 824 are also connected to the interface circuit 820 in the example shown. The output devices 824 may be implemented by, for example, display devices (e.g., light-emitting diodes (LEDs), organic light-emitting diodes (OLEDs), liquid crystal displays (LCDs), cathode ray tube displays (CRTs), in-place switching (IPS) displays, touchscreens, etc.), haptic output devices, printers, speakers, etc. Thus, the interface circuit 820 in the example shown typically includes a graphics driver card, a graphics driver chip, and / or a graphics driver processor.

[0151] The interface circuit 820 in the example shown also includes communication devices such as transmitters, receivers, transceivers, modems, home gateways, wireless access points, and / or network interfaces, facilitating data exchange with external machines (e.g., any kind of computing device) via the network 826. Communication may be via, for example, Ethernet® connections, digital subscriber line (DSL) connections, telephone line connections, coaxial cable systems, satellite systems, site wireless systems, mobile phone systems, etc.

[0152] The processor platform 800 in the example shown also includes one or more mass storage devices 828 for storing software and / or data. Examples of such mass storage devices 828 include floppy disk drives, hard drive disks, compact disk drives, Blu-ray® disk drives, redundant array (RAID) systems of independent disks, and digital versatile disk (DVD) drives. In this example, the mass storage devices 828 implement the conversation context database 244 in Figure 2, including model 243(or more) in Figure 2.

[0153] The machine-executable instructions 832 shown in Figures 6 and 7 may be stored in a mass storage device 828, volatile memory 814, non-volatile memory 816, and / or a removable, non-temporary computer-readable storage medium such as a CD or DVD.

[0154] From the above, it will be understood that exemplary systems, methods, apparatus, and articles of manufacture are disclosed that enhance process control using a process control virtual assistant. The process control virtual assistant disclosed herein corresponds to a system that enables applications such as process control mobile applications, browser applications, and desktop applications to initiate a conversation with a bot or bot framework that assists the user in the process control environment for tasks associated with process control. The disclosed process control virtual assistant may return parameters, historical data, alarms, or other information specific to process control components such as equipment, field devices, control strategies, or batches. In some disclosed examples, a basic script may return information including parameters, while a more complex script may further create a workflow and then execute additional automated scripts that guide the user through a more complex series of process control tasks or commands.

[0155] The examples disclosed herein provide a process-centric virtual assistant framework that can be used to support roles specific to process operation, including engineers, environmental specialists, operators, maintenance personnel, and supervisors. The examples disclosed herein identify process control components, actions, tasks, etc., in response to requests from a user and / or a host application running on a computing device. The examples disclosed herein enable triggering a set of actions in process components, returning a profile of information in process components, and / or enabling the user to visualize the returned information. thingsThis makes it possible to display the following. The examples disclosed herein support multiple users and / or multiple platforms. The examples disclosed herein include a DCS controller assembly that implements a disclosed process control virtual assistant which can be deployed in one or more locations in a process control environment that can be connected via a process control network to facilitate and / or enhance process control.

[0156] While certain exemplary systems, methods, apparatus, and articles have been disclosed herein, the scope of this patent is not limited thereto. Rather, this patent covers all systems, methods, apparatus, and articles that fall within the scope of the claims of this patent.

Claims

1. A device that enhances process control using a virtual assistant, At least one processor, A memory for storing instructions, wherein when the instructions are executed, the at least one processor, Determining the context of a request for information associated with a field device in a process control system, Identifying the topic associated with the request, wherein the topic corresponds to the field device based on the context. Identifying the action associated with the request, wherein the action is associated with a function performed by the field device, Mapping the aforementioned topic to the aforementioned action, Based on the mapping, generate a command that instructs the field device to perform the action, A device comprising a memory and a function that causes the field device to send the command to perform the aforementioned action.

2. The apparatus according to claim 1, wherein the request is an oral request communicated by a user via an application to an input / output module of a programmable logic controller communicably coupled to the at least one processor and the memory, and at least one of the input / output module or the programmable logic controller includes at least one of a microphone or a speaker.

3. The apparatus according to claim 1, wherein the request is an oral request communicated by a user via an application to a wearable device including at least one of a display, a microphone, or a speaker, and the wearable device is communicably coupled to the at least one processor and the memory.

4. When the instruction is executed, at least one processor is instructed to To establish a conversational state based on the aforementioned topic, To generate a response that includes the aforementioned conversation state, Sending the aforementioned response to a computing device, The apparatus according to any one of claims 1 to 3, further comprising displaying a visualization on a display associated with the computing device based on the response.

5. When the instruction is executed, at least one processor: To generate a profile based on at least one parameter associated with the action or request, wherein the parameter is associated with a process control value associated with the field device, and the profile includes at least a first level and a second level. Mapping the aforementioned topic to the first level, To generate a response that includes information associated with the first level, Sending the aforementioned response to a computing device, The apparatus according to claim 1, further comprising displaying a visualization on a display associated with the computing device based on the first level.

6. The aforementioned request is the first request, the visualized is the first visualized, and the instruction, when executed, is performed on at least one processor. Receiving a second request associated with the aforementioned topic, Mapping the second requirement to the second level, To generate a second response that includes information associated with the second level, Sending the second response to the computing device, The apparatus according to claim 5, further comprising replacing the first visualization with a second visualization on the display associated with the computing device based on the second level.

7. A method for enhancing process control using a virtual assistant, At least one processor determines the context of a request for information associated with a field device of a process control system, The at least one processor identifies the topic associated with the request, and identifies that the topic corresponds to the field device based on the context. The at least one processor identifies an action associated with the request, the action being associated with a function performed by the field device, and identifies the action. The at least one processor maps the topic to the action, The at least one processor generates a command instructing the field device to perform the action based on the mapping, A method comprising sending the command to the field device so that the at least one processor performs the action.

8. The method according to claim 7, wherein the request is an oral request communicated by a user via an application to a programmable logic controller communicably coupled to the at least one processor.

9. The request is an oral request communicated by a user via an application to a wearable device corresponding to eyeglasses, a headset, or a wristband, and the wearable device is communicably coupled to the at least one processor. The method according to claim 7.

10. To establish a conversational state based on the aforementioned topic, To generate a response that includes the aforementioned conversation state, Sending the aforementioned response to a computing device, The method according to any one of claims 7 to 9, further comprising displaying a visualization on a display associated with the computing device based on the response.

11. Generating a profile based on at least one parameter associated with the action or the request, wherein the parameter is associated with a process control value associated with the field device, and the profile comprises at least a first level and a second level. Mapping the aforementioned topic to the first level, To generate a response that includes information associated with the first level, Sending the aforementioned response to a computing device, The method according to claim 7, further comprising displaying a visualization on a display associated with the computing device based on the first level.

12. The aforementioned requirement is the first requirement, and the aforementioned visualization is the first visualization. Receiving a second request associated with the aforementioned topic, Mapping the second requirement to the second level, To generate a second response that includes information associated with the second level, Sending the second response to the computing device, The method according to claim 11, further comprising replacing the first visualization with a second visualization on the display associated with the computing device, based on the second level.

13. Determining the aforementioned context The above request is to be analyzed and converted into one or more tokens, including the first token. The request is verified by mapping the first token to a verified token, The method according to any one of claims 7 to 12, comprising generating a script including the action in response to verifying the request based on the mapping.

14. The aforementioned requirement is the first requirement, If it is determined that the first request is invalid based on the mapping, Sending a clarification request to the user, Receiving a second request from the aforementioned user, To verify the second requirement, The method according to claim 13, further comprising generating the script based on the second requirement.

15. A non-temporary computer-readable storage medium containing instructions, wherein when the instructions are executed, the machine has at least: Determining the context of a request for information associated with a field device in a process control system, Identifying the topic associated with the request, wherein the topic corresponds to the field device based on the context. Identifying the action associated with the request, wherein the action is associated with a function performed by the field device, Mapping the aforementioned topic to the aforementioned action, Based on the mapping, generate a command that instructs the field device to perform the action, A non-temporary computer-readable storage medium that causes the field device to send the command to perform the aforementioned action.

16. The non-temporary computer-readable storage medium according to claim 15, wherein the request is an oral request communicated by a user via an application to a programmable logic controller communicably coupled to the non-temporary computer-readable storage medium.

17. The non-temporary computer-readable storage medium according to claim 15, wherein the request is an oral request communicated by a user via an application to a wearable device communicably coupled to the non-temporary computer-readable storage medium.

18. When executed, the machine shall have at least, To establish a conversational state based on the aforementioned topic, To generate a response that includes the aforementioned conversation state, Sending the aforementioned response to a computing device, A non-temporary computer-readable storage medium according to any one of claims 15 to 17, further comprising an instruction to cause the computer to display a visualization on a display associated with the computing device based on the response.

19. When executed, the machine provides at least: To generate a profile based on at least one parameter associated with the action or request, wherein the parameter is associated with a process control value associated with the field device, and the profile includes at least a first level and a second level. Mapping the aforementioned topic to the first level, To generate a response that includes information associated with the first level, Sending the aforementioned response to a computing device, A non-temporary computer-readable storage medium according to claim 15, further comprising instructions to cause the first level to be displayed on a display associated with the computing device.

20. The aforementioned request is the first request, the visualized thing is the first visualized thing, and when it is executed, the machine has at least, Receiving a second request associated with the aforementioned topic, Mapping the second requirement to the second level, To generate a second response that includes information associated with the second level, Sending the second response to the computing device, A non-temporary computer-readable storage medium according to claim 19, further comprising an instruction to cause the first visualization to be replaced with a second visualization on a display associated with the computing device, based on the second level.

21. When executed, the machine shall have at least, The above request is to be analyzed and converted into one or more tokens, including the first token. The request is verified by mapping the first token to a verified token, A non-temporary computer-readable storage medium according to any one of claims 15 to 20, further comprising an instruction to generate a script containing the action when the request is verified based on the mapping.

22. The aforementioned request is the first request, and when it is performed, the machine will have at least the following: If the first request is determined to be invalid based on the mapping, a clarification request is sent to the user. Receiving a second request from the aforementioned user, To verify the second requirement, A non-temporary computer-readable storage medium according to claim 21, further comprising an instruction to generate the script based on the second requirement and to perform the following.

Images