Patent Application
20210105183
Various embodiments of the present disclosure relate generally to Industrial Internet of Things (IIoT) systems and networks. More specifically, this disclosure relates to autonomous assembly and configuration of a domain specific gateway for use in an IIoT system or network.
Industrial process control and automation systems are routinely used to automate large or complex industrial processes. These systems have evolved from closed proprietary systems in the early 1990s to more convenient, connected, and open systems now. The current trend involves (i) moving these systems to cloud computing environments and (ii) using Industrial Internet of things (IIoT) devices within these systems.
In today's IIoT world, lloT providers direct their focus towards connecting devices, extracting data from those devices, and sending the data to the cloud for analytics. In conventional systems, IIoT gateways involve manual assembly and configuration. For example, human effort is involved to understand which services are required on the gateway and when they are required. A consultation from an IIoT architect is then performed in order to pick the correct set of physical components to be deployed in the node. As such, manual selection of such nodal components might be inaccurate. Furthermore, a user typically manually builds the components to generate the runtime image of the IIoT node gateway that could be redundant and time consuming. A review is also performed by a security expert in order to select, install, and configure the correct set of security subsystems. As such, this can lead to inefficiency, substantial manual effort, and high configuration costs.
The present disclosure is directed to overcoming one or more of these above-referenced challenges.
According to certain aspects of the disclosure, systems and methods are disclosed for assembling and configuring an Industrial Internet of Things (IIoT) gateway in an IIoT network to perform one or more functions.
In one embodiment, a computer-implemented method is disclosed for executing a conversational interface for autonomous assembly and configuration of an Industrial Internet of Things (IIoT) gateway. The computer-implemented method includes: generating and transmitting, to a user over an electronic network, a plurality of questions regarding hardware and/or software assembly and configuration of an IIoT gateway; receiving, from the user over the electronic network, responses to the plurality of questions; generating a service specification in a domain specific language based on the received responses, the service specification identifying a plurality of services to be assembled on the IIoT gateway; generating, for each identified service of the generated service specification, a configuration specification in the domain specific language, each configuration specification defining a protocol of the respective identified service; and transmitting the configuration specification, to the user over the network, to enable the user to read, access, and download components listed in the configuration specification for installation on the IIoT gateway.
In accordance with another embodiment, a computer system is disclosed for executing a conversational interface for autonomous assembly and configuration of an Industrial Internet of Things (IIoT) gateway. The computer system comprises: a memory having processor-readable instructions stored therein; and at least one processor configured to access the memory and execute the processor-readable instructions, which when executed by the processor configures the processor to perform a plurality of functions, including functions for: generating and transmitting, to a user over an electronic network, a plurality of questions regarding hardware and/or software assembly and configuration of an IIoT gateway; receiving, from the user over the electronic network, responses to the plurality of questions; generating a service specification in a domain specific language based on the received responses, the service specification identifying a plurality of services to be assembled on the IIoT gateway; generating, for each identified service of the generated service specification, a configuration specification in the domain specific language, each configuration specification defining a protocol of the respective identified service; and transmitting the configuration specification, to the user over the network, to enable the user to read, access, and download components listed in the configuration specification for installation on the IIoT gateway.
In accordance with another embodiment, a non-transitory computer-readable medium is disclosed for executing a conversational interface for autonomous assembly and configuration of an Industrial Internet of Things (IIoT) gateway. The non-transitory computer-readable medium having instructions stored thereon that, in response to instructions by a computer-based system, cause the computer-based system to perform operations comprising: generating and transmitting, to a user over an electronic network, a plurality of questions regarding hardware and/or software assembly and configuration of an IIoT gateway; receiving, from the user over the electronic network, responses to the plurality of questions; generating a service specification in a domain specific language based on the received responses, the service specification identifying a plurality of services to be assembled on the IIoT gateway; generating, for each identified service of the generated service specification, a configuration specification in the domain specific language, each configuration specification defining a protocol of the respective identified service; and transmitting the configuration specification, to the user over the network, to enable the user to read, access, and download components listed in the configuration specification for installation on the IIoT gateway.
Additional objects and advantages of the disclosed embodiments will be set forth in part in the description that follows, and in part will be apparent from the description, or may be learned by practice of the disclosed embodiments. The objects and advantages of the disclosed embodiments will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosed embodiments, as claimed.
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various exemplary embodiments and together with the description, serve to explain the principles of the disclosed embodiments.
While principles of the present disclosure are described herein with reference to illustrative embodiments for particular applications, it should be understood that the disclosure is not limited thereto. Those having ordinary skill in the art and access to the teachings provided herein, will recognize that the features illustrated or described with respect to one embodiment, may be combined with the features of another embodiment. Therefore, additional modifications, applications, embodiments, and substitution of equivalents, all fall within the scope of the embodiments described herein. Accordingly, the invention is not to be considered as limited by the foregoing description.
As described above, there is a need in the field of industrial processes for systems and methods for assembling and configuring an Industrial Internet of Things (IIoT) gateway in an lloT network via the cloud. The following systems and methods provide more precise insight into processes and components that aid in the execution of a conversational interface for autonomous assembly and configuration of an lloT gateway.
In
At least one network 104 is coupled to the sensors 102a and actuators 102b. The network 104 facilitates interaction with the sensors 102a and actuators 102b. For example, the network 104 could transport measurement data from the sensors 102a and provide control signals to the actuators 102b. The network 104 could represent any suitable network or combination of networks. As particular examples, the network 104 could represent at least one Ethernet network (such as one supporting a FOUNDATION FIELDBUS protocol), electrical signal network (such as a HART network), pneumatic control signal network, or any other or additional type(s) of network(s). In accordance with this disclosure, the network 104 could represent all or a portion of a network of Industrial Internet of Things (IIoT) devices.
The system 100 also includes various controllers 106. The controllers 106 can be used in the system 100 to perform various functions in order to control one or more industrial processes. For example, a first set of controllers 106 may use measurements from one or more sensors 102a to control the operation of one or more actuators 102b. A second set of controllers 106 could be used to optimize the control logic or other operations performed by the first set of controllers. A third set of controllers 106 could be used to perform additional functions. The controllers 106 could therefore support a combination of approaches, such as regulatory control, advanced regulatory control, supervisory control, and advanced process control.
Each controller 106 includes any suitable structure for controlling one or more aspects of an industrial process. At least some of the controllers 106 could, for example, represent proportional-integral-derivative (PID) controllers or multivariable controllers, such as controllers implementing model predictive control (MPC) or other advanced predictive control (APC). As a particular example, each controller 106 could represent a computing device running a real-time operating system, a WINDOWS operating system, or other operating system.
In one embodiment, at least one network 108 couples the controllers 106 and other devices in the system 100. The network 108 facilitates the transport of information between components. The network 108 could represent any suitable network or combination of networks. As particular examples, the network 108 could represent at least one Ethernet network. In accordance with this disclosure, the network 108 could represent all or a portion of a network of IIoT devices. In one embodiment, network 104 and/or network 108 form part of the same network, such as network 120, which may be referred to as “the cloud,” which may or may not form part of and/or be in communication with the Internet.
Operator access to and interaction with the controllers 106 and other components of the system 100 can occur via various operator consoles 110. Each operator console 110 could be used to provide information to an operator and receive information from an operator. For example, each operator console 110 could provide information identifying a current state of an industrial process to the operator, such as values of various process variables and warnings, alarms, or other states associated with the industrial process. Each operator console 110 could request information affecting how the industrial process is controlled, such as by requesting setpoints or control modes for process variables controlled by the controllers 106 or other information that alters or affects how the controllers 106 control the industrial process. This could include requesting this information from the controllers 106 or from other devices such as historian 114 or servers 116. In response to such requests, each operator console 110 could receive the requested information. Each operator console 110 includes any suitable structure for displaying information to and interacting with an operator. For example, each operator console 110 could represent a computing device running a WINDOWS operating system or other operating system.
Multiple operator consoles 110 can be grouped together and used in one or more control rooms 112. Each control room 112 could include any number of operator consoles 110 in any suitable arrangement. In some embodiments, multiple control rooms 112 can be used to control an industrial plant, such as when each control room 112 contains operator consoles 110 used to manage a discrete part of the industrial plant.
The control and automation system 100 here also includes at least one historian 114 and one or more servers 116. The historian 114 represents a component that stores various information about the system 100. The historian 114 could, for instance, store information that is generated by the various controllers 106 during the control of one or more industrial processes. The historian 114 includes any suitable structure for storing and facilitating retrieval of information. Although shown as a single component here, the historian 114 could be located elsewhere in the system 100, or multiple historians could be distributed in different locations in the system 100.
Each server 116 denotes a computing device that executes applications for users of the operator consoles 110 or other applications. The applications could be used to support various functions for the operator consoles 110, the controllers 106, or other components of the system 100. Each server 116 could represent a computing device running a WINDOWS operating system or other operating system. Note that while shown as being local within the control and automation system 100, the functionality of the server 116 could be remote from the control and automation system 100. For instance, the functionality of the server 116 could be implemented in a computing cloud or a remote server communicatively coupled to the control and automation system 100.
Although
As shown in
As shown in
In one embodiment, the edge node software may include an operating system 330, a data storage and management platform, application support, a security and encryption module 360, a communications module 310, and interfaces 340 for one or more connected devices. The edge node may contain a pre-determined set of applications 320, such as analytics, alarm management, and backup/recovery. Typically, a configuration of which devices will connect to the node may be planned before deploying an edge node. Devices may connect to the edge node using protocols such as ZigBee, Z-Wave, BLE, OPC UA, BACNet, and the like.
As shown in
In existing systems, behavioral aspects of these modules, such as those listed below, may be totally static. That is, the physical organization and bindings of the modules, the interaction between the modules, data communication between the modules, resource consumption of the modules, etc., may not be available for modification after deployment of the edge node. In other words, the modules may typically be tightly coupled and packaged for a common deployment scenario.
According to one or more embodiments, the edge layer may receive incoming data streams from a plurality of devices such as, sensors 102a and gateways 116. From a machine learning perspective, the process of receiving data packets from those components, can be interpreted as a function of time, which is exponentially distributed as explained below.
In one embodiment, data inter arrival time s=IID (Independent and Identically Distributed Random Variables) and exponentially distributed, where the number of data arrivals n over a given interval (t, t+1,t+2) has a Poisson distribution. Incoming Data arrival is a Poisson process or a Poisson stream.
If the arrival of data stream to a single gateway with exponential service time are Poisson with mean rate λ, the departures are also Poisson with the same rate λ provided λ<μ
μ=Mean service rate per gateway
λ=Mean arrival rate of data stream
According to queueing theory, and as per the representation in the above-mentioned diagram the service times for the incoming Poisson events will also be independently and identically distributed (IIDs) random variables. Hence it becomes complex to pre define the systems behavior over various circumstances since the arrival rate and service rate cannot be predicted accurately.
From the IIoT edge context the demand response can be defined as, dynamic scaling or modification of the application behavior based upon certain events. These events can be:
Incoming Sensor data
Device Flow control rate
Resource Utilization
Performance implications and so on
Since the data arrival rate is highly stochastic in nature it may be difficult to define a static behavior model for these attributes. Currently there is very limited intelligence available at the edge to understand the demand response of the system and create the applications according to that.
The ISDP 505a may be responsible for processing human input. Specifically, ISDP 505a may be an intelligent component built using cognitive technology, such as a BOT service, and natural language understanding (NLU) that can recognize what the user means based on input that may not always be sufficient or complete. Based upon the user query, the ISDP 505a refines the following aspects from the conversation:
Intent (e.g. need to fabricate the IIoT gateway image)
Entities (e.g. embedded device, C++ environment)
Factors (e.g., BACnet support, OTA, Yocto Linux)
Conditions (e.g. maximum space complexity of 1 GB)
ISDP 505a may then create a service specification in an IoT domain language (e.g., Sentience Domain Language). The service specification identifies the services required (e.g., how devices will be connected and controlled, what kind of field bus protocol(s) will be used, which machine learning models will be used, what model will be used for predictive analysis, etc.) in the node. The ISDP 505a also advises the user of the CPU, memory, and storage required.
The ISCP 505b may be an intelligent component that helps the user configure each service identified by the ISDP 505a. The ISCP 505b may be specific to each service and may create a configuration specification in an IIoT domain language (e.g., Sentience Domain Language). For example, if MQTT is the communication protocol identified to communicate to the devices, then ISCE 505b may identify the number of MQTT channels to be supported, the bandwidth requirement for each MQTT channel, etc.
The metadata that is used to fabricate or create the IIoT gateway components can be maintained in an index-based repository within a service registry 530, as “recipes.” The recipes may be reused for the fabrication of the IIoT gateway requests with similar factors or requirements.
The intelligent component selection may use principle component analysis (PCA) techniques to refine the required components from a catalog of recipes in the edge or cloud. In some embodiments, any desired IIoT platform may be used to select a component using the following process:
Use weighted sum of parameters to classify the components.
Let xij denote the ith parameter for the jth component.
loT platform assigns weights wi's such that yj's provide the maximum discrimination among the components.
The quantity yj is called the principal factor.
The factors are ordered. The first factor explains the highest percentage of the variance. Statistically:
Here, ajj is called the loading of variable xj on factor yi.
This is equivalent to stating that y′s are uncorrelated to each other.
A typical PCA executed by the ISCP 505b in order to pick the right components for the user's gateway requirements can look similar to the following Table 1:
1. A user 501 engages in a conversation with one or more processors 505 via text or voice. In the exemplary embodiment, the user 501 is a deployment engineer and the user 501 first converses with Intelligent Service Design Processor (ISDP) 505a. As described above, ISDP 505a may refine the intent, factors, entity, and condition from the user's conversation and determines the types of services desired by the user 501. In one embodiment, the one or more processors 505 may be BOTs with cognitive capabilities. The one or more processors 505 may work with the help of a knowledge base that is configured to contain:
2. ISDP 505a may produce a services specification, as part of the gateway service design and configuration 510, in an IoT domain specific language (e.g., Sentience Domain Specific Language). The specification may identify all the services desired in the gateway.
3. A service configuration engine (SCE) 520 may consult the service registry 530 through the cloud 120 and identify the service details, such as dependencies, CPU, memory, and storage requirements.
4. The user 501 again converses with the one or more processors 505. In the exemplary embodiment, the user 501 now converses with the Intelligent Services Configuration Processor (ISCP) 505b. The ISCP 505b asks questions to the user 501 and then creates the configuration information, as part of the gateway service design and configuration 510, in an IoT domain specific language (e.g., Sentience Domain Specific Language).
5. Service configuration engine (“SCE”) 520 produces a services manifest 525 (i.e., a list of services that should be installed in the gateway based upon the PCA, described above). For example, the manifest could contain a list of services, such as:
6. SCE 520 may also produce an infrastructure sizing recommendation 526 for the gateway infrastructure including CPU, memory, and storage requirements. Both the services manifest 525 and the infrastructure sizing recommendation 526 may be available for the user 501 to review. A sample recommendation 526 for the IIoT gateway could be as follows:
7. Based on the prepared manifest 525, SCE 520 may prepare a deployment object list (“DOL”) 527. For instance, one service may contain multiple docker containers. The DOL 527 may contain the list of objects (e.g., containers) to be downloaded from the service registry 530. A sample DOL 527 can be as follows:
8. Based upon the input by the user 501, SCE 520 may prepare a services configuration 528. The services configuration 528 may be a configuration file or a fabricated image file with all the binaries packaged together in the form of an .img file. The services configuration 528 can be downloaded to the node, so that each service receives the configuration data it needs.
The user 501 then provisions the recommended hardware and software configuration for the IIoT gateway. The installer software running on the IIoT gateway accesses the configuration management server 210 through the network 120 and downloads the DOL 527 and the services configuration file 528. The installer software then accesses the service registry 530 and downloads all the components listed in the DOL 527. Each component in the DOL 527 is started and reads the configuration file 528 at the time of initialization. The process of installing and starting the node is now complete.
A sample dialog between the user 501 and the ISDP 505a is as follows:
A sample dialog between the user 501 and the ISCP 505b is as follows:
Connected buildings domain aspects
Connected workers domain aspects
Connected freight
Connected aero domain aspects
Connected homes domain aspects
Based upon the context object that has been derived from the above-mentioned parameters, a three-step process can be performed towards refining the IoT domain language (e.g., SDL) expression.
Some aspects of the loT domain language (e.g., SDL) expression include:
Lambda-based notations to carry the payload of more than one or group of metadata information. Typically, a lambda expression is an anonymous function that can be used to create delegates or expression tree types.
Encoded/cryptic in a form that only a service configuration engine can decode the expression.
IoT domain language (e.g., SDL) expressions are translative, i.e., arithmetic operations can be performed between them.
IoT domain language (e.g., SDL) expressions can be given as input factors for a training set to generate a hypothesis based thereupon. This training can happen either in the edge or in the cloud.
In the method 700, a computer generates and transmits, to a user over an electronic network, a plurality of questions regarding hardware and/or software assembly and configuration of an IIoT gateway (Step 705). The computer then receives responses to the plurality of questions from the user (Step 710). A service specification is then generated in a domain specific language based on the received responses (Step 715). The service specification identifies a plurality of services to be assembled on the IIoT gateway. For each identified service of the generated service specification, the computer generates a configuration specification in the domain specific language (Step 720). Each configuration specification defines a protocol of the respective identified service. Lastly, the computer transmits the configuration specification to the user over the network to enable the user to read, access, and download components listed in the configuration specification for installation on the IIoT gateway (Step 725).
The following table summarizes some issues that occur in typical IIoT gateways and how each issue is addressed by the disclosed systems and methods.
Example: An IIoT gateway is set up on the manufacturing shop floor to run simple stream analytics for handling real-time data that is generated by a machine. The solution deployment architect needs to consider the types of machines the node will connect to, how each machine will send data, the types of analytical models that are required to process the data, how the node will connect to the cloud, etc. The solution deployment architect has to manually identify all the services required, configure the services, and make sure the node functions correctly. The disclosed systems and methods utilize a BOT which will ask the user (in this case, the solution deployment architect) questions about which devices the node will read/write data from/to, which protocol(s) will be used, which types of analytics are desired, and which type of data will go to the cloud. Based on the user's answers to the questions, the BOT will create a specification for the services to be configured using a domain specific language (DSL). A service configuration engine will interpret the specified configuration and create instructions for the correct software services to be loaded in the gateway. Thus, the desired gateway software will be created and composed automatically.
Below are some potential advantages of the conversational approach for automatic creation of a domain specific gateway:
Autonomous way of creating a script that downloads all the software components needed in a domain specific gateway.
A resource recommendation is created by asking the deployment engineer questions about the IIoT gateway functionality. The recommendation informs the deployment engineer about CPU, memory, and storage resources needed.
A configuration file for the IIoT gateway is created conversationally (i.e. by asking specific questions about the functions and features needed).
Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 16033280 | Jul 2018 | US |
| Child | 17123661 | US |
