Patent Description:
Many industries have implemented Internet of Things (IOT) technology, which can connect machinery, sensors, control systems, or the like, in an industrial environment, to computers for remote monitoring and control. Many of the machines, sensors, and control systems in the industrial environment can have external interfaces to output information corresponding to their operations to a server via an edge node acting as a protocol translator for transmissions between the industrial environment and the server. For example, specially-programmed edge node can receive the information output from the machines, sensors, and control systems in the industrial environment in one transmission protocol, filter or aggregate the data received from the machines, sensors, and control systems in an attempt to reduce the volume of data uploaded to the server for subsequent processing, and transmit the information to the server with a different transmission protocol.

Each data flow from the external interfaces of the machines, sensors, and control systems in the industrial environment to the server through one or more edge nodes typically include custom configurations. For example the machines, sensors, and control systems in the industrial environment can include custom logic to output data at an external interface using a particular protocol, while the edge nodes can be specially-programmed or hard-coded in static flows, for example, performing data compression, data transformation, such as fast Fourier Transform operations, feature extraction, data combination from various sources, such as data convolution. These customized data flows are hardcoded in the industrial environment to enable the transmission of data from the machines, sensors, and control systems to the server. Hardcoding the data flows into the edge nodes, machines, sensors, and control system is time consuming and renders the overall industrial environment inflexible and difficult to scale.

Document <CIT> discloses a method for a contextual transformation of an analytical model for an industrial internet of things (IIoT) edge node. For instance, the analytical model is received from a cloud service, local data of the IIoT edge node is obtained, and the local data is analyzed to determine a situational context of the IIoT edge node.

Document <CIT> discloses a method to compress, aggregate and archive Internet of Things data originating from sensors can use a point cloud based geometric data model and a distribution and aggregation method based on compressed point cloud representations.

Document <CIT> discloses a framework for dynamic management of analytic functions such as data processors and machine learned ("ML") models for an Internet of Things intelligent edge that addresses management of the lifecycle of the analytic functions from creation to execution, in production. The end user will be seamlessly able to check in an analytic function, version it, deploy it, evaluate model performance and deploy refined versions into the data flows at the edge or core dynamically for existing and new end points. The framework comprises a hypergraph-based model as a foundation, and may use a microservices architecture with the ML infrastructure and models deployed as containerized microservices.

The present invention is defined by the enclosed claims. This application discloses a method, a computer program product and an apparatus, such as a computing system, to generate models of managed devices and applications in an Internet of Things (IOT) system by identifying each endpoint in the managed devices and applications capable of transmitting or receiving the data and defining flows for data from the endpoints in sensors to endpoints of IOT servers via endpoints of the programmable edge device applications. The computing system can develop a data flow map to define a connectivity of the programmable edge device applications to the sensors and the servers in the IOT system for exchanging the data from the sensors to the servers in the IOT system via the programmable edge device applications. The computing system can prompt configuration of the managed devices and applications in the IOT system based on the data flow map, which implements the connectivity of the programmable edge device applications to the sensors and to servers in the IOT system. Embodiments will be described in greater detail below.

Various embodiments may be implemented through the execution of software instructions by a computing device <NUM>, such as a programmable computer. Accordingly, <FIG> shows an illustrative example of a computing device <NUM>. As seen in this figure, the computing device <NUM> includes a computing unit <NUM> with a processing unit <NUM> and a system memory <NUM>. The processing unit <NUM> may be any type of programmable electronic device for executing software instructions, but will conventionally be a microprocessor. The system memory <NUM> may include both a read-only memory (ROM) <NUM> and a random access memory (RAM) <NUM>. As will be appreciated by those of ordinary skill in the art, both the read-only memory (ROM) <NUM> and the random access memory (RAM) <NUM> may store software instructions for execution by the processing unit <NUM>.

The processing unit <NUM> and the system memory <NUM> are connected, either directly or indirectly, through a bus <NUM> or alternate communication structure, to one or more peripheral devices <NUM>-<NUM>. For example, the processing unit <NUM> or the system memory <NUM> may be directly or indirectly connected to one or more additional memory storage devices, such as a hard disk drive <NUM>, which can be magnetic and/or removable, a removable optical disk drive <NUM>, and/or a flash memory card. The processing unit <NUM> and the system memory <NUM> also may be directly or indirectly connected to one or more input devices <NUM> and one or more output devices <NUM>. The input devices <NUM> may include, for example, a keyboard, a pointing device (such as a mouse, touchpad, stylus, trackball, or joystick), a scanner, a camera, and a microphone. The output devices <NUM> may include, for example, a monitor display, a printer and speakers. With various examples of the computing device <NUM>, one or more of the peripheral devices <NUM>-<NUM> may be internally housed with the computing unit <NUM>. Alternately, one or more of the peripheral devices <NUM>-<NUM> may be external to the housing for the computing unit <NUM> and connected to the bus <NUM> through, for example, a Universal Serial Bus (USB) connection.

With some implementations, the computing unit <NUM> may be directly or indirectly connected to a network interface <NUM> for communicating with other devices making up a network. The network interface <NUM> can translate data and control signals from the computing unit <NUM> into network messages according to one or more communication protocols, such as the transmission control protocol (TCP) and the Internet protocol (IP). Also, the network interface <NUM> may employ any suitable connection agent (or combination of agents) for connecting to a network, including, for example, a wireless transceiver, a modem, or an Ethernet connection. Such network interfaces and protocols are well known in the art, and thus will not be discussed here in more detail.

It should be appreciated that the computing device <NUM> is illustrated as an example only, and it not intended to be limiting. Various embodiments may be implemented using one or more computing devices that include the components of the computing device <NUM> illustrated in <FIG>, which include only a subset of the components illustrated in <FIG>, or which include an alternate combination of components, including components that are not shown in <FIG>. For example, various embodiments may be implemented using a multi-processor computer, a plurality of single and/or multiprocessor computers arranged into a network, or some combination of both.

With some implementations, the processor unit <NUM> can have more than one processor core. Accordingly, <FIG> illustrates an example of a multi-core processor unit <NUM> that may be employed with various embodiments. As seen in this figure, the processor unit <NUM> includes a plurality of processor cores 201A and 201B. Each processor core 201A and 201B includes a computing engine 203A and 203B, respectively, and a memory cache 205A and 205B, respectively. As known to those of ordinary skill in the art, a computing engine 203A and 203B can include logic devices for performing various computing functions, such as fetching software instructions and then performing the actions specified in the fetched instructions. These actions may include, for example, adding, subtracting, multiplying, and comparing numbers, performing logical operations such as AND, OR, NOR and XOR, and retrieving data. Each computing engine 203A and 203B may then use its corresponding memory cache 205A and 205B, respectively, to quickly store and retrieve data and/or instructions for execution.

Each processor core 201A and 201B is connected to an interconnect <NUM>. The particular construction of the interconnect <NUM> may vary depending upon the architecture of the processor unit <NUM>. With some processor cores 201A and 201B, such as the Cell microprocessor created by Sony Corporation, Toshiba Corporation and IBM Corporation, the interconnect <NUM> may be implemented as an interconnect bus. With other processor units 201A and 201B, however, such as the Opteron™ and Athlon™ dual-core processors available from Advanced Micro Devices of Sunnyvale, California, the interconnect <NUM> may be implemented as a system request interface device. In any case, the processor cores 201A and 201B communicate through the interconnect <NUM> with an input/output interface <NUM> and a memory controller <NUM>. The input/output interface <NUM> provides a communication interface to the bus <NUM>. Similarly, the memory controller <NUM> controls the exchange of information to the system memory <NUM>. With some implementations, the processor unit <NUM> may include additional components, such as a high-level cache memory accessible shared by the processor cores 201A and 201B. It also should be appreciated that the description of the computer network illustrated in <FIG> and <FIG> is provided as an example only, and it not intended to suggest any limitation as to the scope of use or functionality of alternate embodiments.

<FIG> illustrates an example of an Internet of Things (IOT) system <NUM> implemented in a server environment <NUM> and an on-premises environment <NUM> according to various embodiments. Referring to <FIG>, the on-premises environment <NUM> of the IOT system <NUM> can include multiple sensor systems <NUM>-<NUM> to <NUM>-N, each including one or more sensors or other devices capable of communicating with one or more IOT edge nodes <NUM>-<NUM> to <NUM>-N. In some embodiments, the sensor system <NUM>-<NUM> can communicate with the IOT edge node <NUM>-<NUM>, the sensor system <NUM>-<NUM> can communicate with the IOT edge node <NUM>-<NUM>, and the sensor system <NUM>-N can communicate with the IOT edge node <NUM>-N. In other embodiments, one or more of the sensor systems <NUM>-<NUM> to <NUM>-N can communicate with any of the IOT edge nodes <NUM>-<NUM> to <NUM>-N and, as will be described below in greater detail, be configured (and dynamically reconfigured) by a data flow server <NUM> to communicate with various embedded applications hosted in the IOT edge nodes <NUM>-<NUM> to <NUM>-N.

In a manufacturing environment, such as a factory floor or multiple distributed factories, the sensors in the sensor systems <NUM>-<NUM> to <NUM>-N can gather information corresponding to the manufacturing of a product, for example, by identifying operations or operational states of manufacturing equipment, manufacturing lines, the manufacturing of products, inventory, testing or verification procedures for the products, or the like. The sensors in the sensor systems <NUM>-<NUM> to <NUM>-N can transmit the gathered information towards an IOT server <NUM> via one or more of the IOT edge nodes <NUM>-<NUM> to <NUM>-N.

The TOT edge nodes <NUM>-<NUM> to <NUM>-N can include embedded application systems <NUM>-<NUM> to <NUM>-N, respectively, to process the information received from the sensor systems <NUM>-<NUM> to <NUM>-N. The embedded application systems <NUM>-<NUM> to <NUM>-N can determine states of the machinery, manufacturing lines, equipment, products, inventory, or the like, based on the information received from the sensor system <NUM>-<NUM> to <NUM>-N. The embedded application systems <NUM>-<NUM> to <NUM>-N can generate messages based on the determined states and transmit the messages to the IOT server <NUM>.

In some embodiments, the embedded application systems <NUM>-<NUM> to <NUM>-N, in the IOT edge nodes <NUM>-<NUM> to <NUM>-N, respectively, can be generic or programmable with regard to the data flow from the sensor system <NUM>-<NUM> to <NUM>-N to the IOT server <NUM>. The data flow server <NUM> can deploy a configuration, for example, from a data flow map, to the IOT edge nodes <NUM>-<NUM> to <NUM>-N, which can configure the embedded application system <NUM>-<NUM> to <NUM>-N to implement a data flow from the sensor system <NUM>-<NUM> to <NUM>-N to the IOT server <NUM>. The data flow server <NUM> also can update the configuration of the IOT edge nodes <NUM>-<NUM> to <NUM>-N to implement different data flows from the sensor system <NUM>-<NUM> to <NUM>-N to the IOT server <NUM>, for example, based on a different data flow map. Embodiments will be described below in greater detail.

The IOT edge nodes <NUM>-<NUM> to <NUM>-N can include a processing systems configured to execute instructions corresponding to embedded applications, which can prompt the processing systems to analyze the information received from the sensor systems <NUM>-<NUM> to <NUM>-N, generate the messages, and transmit the messages to the IOT server <NUM>. In some embodiments, the IOT edge nodes <NUM>-<NUM> to <NUM>-N can receive the embedded applications as container images from the IOT server <NUM> located in the server environment <NUM>. The embedded application systems <NUM>-<NUM> to <NUM>-N can implement Docker engines to execute the container images. The container images can be standalone, executable embedded applications, which can include executable code, runtime, system tools, system libraries, settings, or the like, utilized by the Docker engines to implement the embedded applications corresponding to the container images.

The IOT server <NUM> can include an application manager <NUM> to deploy containers having container images to the IOT edge nodes <NUM>-<NUM> to <NUM>-N. In some embodiments, the application manager <NUM> can select an embedded application to implement in one of the IOT edge nodes <NUM>-<NUM> to <NUM>-N, for example, from an application repository <NUM> located in the server environment <NUM>, and generate a container to deploy the selected embedded application to the corresponding IOT edge nodes <NUM>-<NUM> to <NUM>-N. The addition of embedded application systems <NUM>-<NUM> to <NUM>-N to the IOT edge nodes <NUM>-<NUM> to <NUM>-N, respectively, can allow for deployment of the containers and corresponding container images by the application manager <NUM> to the IOT edge nodes <NUM>-<NUM> to <NUM>-N, which can allow the IOT server <NUM> to centrally control a flow of information gathered by the sensor systems <NUM>-<NUM> to <NUM>-N to the IOT server <NUM>.

The application manager <NUM> in the IOT server <NUM> also can orchestrate various operations performed by the embedded application systems <NUM>-<NUM> to <NUM>-N in the IOT edge nodes <NUM>-<NUM> to <NUM>-N, respectively. For example, the application manager <NUM> can utilize the embedded application systems <NUM>-<NUM> to <NUM>-N to off-load processing from the server environment <NUM> to the IOT edge nodes <NUM>-<NUM> to <NUM>-N in the on-premises environment <NUM>. In some embodiments, the application manager <NUM> in the IOT server <NUM> can identify processing and/or memory resources in the IOT edge nodes <NUM>-<NUM> to <NUM>-N that remain after implementing container images for the communication of information gathered by the sensor systems <NUM>-<NUM> to <NUM>-N. The application manager <NUM> can utilize the remaining processing and/or memory resources in the IOT edge nodes <NUM>-<NUM> to <NUM>-N to off-load processing from the server environment <NUM> to the on-premises environment <NUM>. For example, the application manager <NUM> can select an embedded application from the application repository <NUM> corresponding to the operations to be off-loaded to the IOT edge nodes <NUM>-<NUM> to <NUM>-N and deploy a container that includes the embedded application to the corresponding IOT edge nodes <NUM>-<NUM> to <NUM>-N.

In another example, the application manager <NUM> also can orchestrate the import or export of parameters in the embedded application implemented by the embedded application systems <NUM>-<NUM> to <NUM>-N. The parameters in the embedded application can correspond to values coded in the embedded application or values determined by the embedded application during execution. For example, when the embedded application corresponds to a temperature monitoring application that utilizes a temperature reading from a sensor to determine a rate of temperature change over a preset time period and then generates a message when the rate of temperature change exceeds a threshold value, the parameters can correspond to the rate of temperature change and the threshold value. In this example, the application manager <NUM> can send a parameter message to one of the IOT edge nodes <NUM>-<NUM> to <NUM>-N implementing the temperature monitoring application, which can include a parameter for the corresponding embedded application systems <NUM>-<NUM> to <NUM>-N to import into the temperature monitoring application, such as a parameter corresponding to a different threshold value. The application manager <NUM> also can send a parameter message to one of the IOT edge nodes <NUM>-<NUM> to <NUM>-N implementing the temperature monitoring application, which can prompt the corresponding embedded application systems <NUM>-<NUM> to <NUM>-N to export a parameter from the temperature monitoring application, such as a parameter corresponding to a threshold value or the rate of temperature change.

The application manager <NUM> also can orchestrate the import or export of parameters in the embedded application by implementing an avatar of the embedded application running on the embedded application systems <NUM>-<NUM> to <NUM>-N and then transmitting parameter messaging to the embedded application systems <NUM>-<NUM> to <NUM>-N. In some embodiments, the parameter messaging can prompt the embedded application systems <NUM>-<NUM> to <NUM>-N to import a parameter from the IOT server <NUM>, which can allow the application manager <NUM> to modify the embedded application implemented by one or more of embedded application systems <NUM>-<NUM> to <NUM>-N without having to deploy a different embedded application to the IOT edge nodes <NUM>-<NUM> to <NUM>-N.

The parameter messaging also can prompt the embedded application systems <NUM>-<NUM> to <NUM>-N to import or export parameters to other devices, such as other IOT edge nodes <NUM>-<NUM> to <NUM>-N. The application manager <NUM> can orchestrate the sharing of parameters across the distributed IOT edge nodes <NUM>-<NUM> to <NUM>-N with the parameter messaging, which can allow the IOT edge nodes <NUM>-<NUM> to <NUM>-N to operate in conjunction with each other. Embodiments of the application manager and the embedded application system will be described below in greater detail.

<FIG> illustrates an example of an application manager <NUM> in an IOT server according to various embodiments. Referring to <FIG>, the IOT server including the application manager <NUM> can be located in a server environment and be configured to communicate with devices located in an on-premises environment or in a different server environment. The application manager <NUM> can include an embedded application deployment unit <NUM> to select embedded applications for deployment on IOT edge nodes in an on-premises environment. In some embodiments, the application manager <NUM> can select the embedded applications based on input received from a remote user terminal or based on an internal programming. The application manager <NUM> can retrieve a container image corresponding to the selected embedded application from a memory device, such as an application repository located in the server environment or another memory system storing container images accessible by the IOT server.

The embedded application deployment unit <NUM> can include a containerized IOT application unit <NUM> to generate a container <NUM> that includes the container image corresponding to the selected embedded application. The containerized IOT application unit <NUM> can transmit the container <NUM> towards the IOT edge node over a communication network, such as packet-switched network, a circuit-switched network, a combination thereof, or the like. The IOT edge node can extract the container image from the received container <NUM> and execute the container image, for example, with a Docker engine or the like, to implement the embedded application on the IOT edge node.

The implementation of the embedded application can prompt the IOT edge node to generate application messages <NUM>, which the IOT edge node can transmit to the IOT server over the communication network. The application messages <NUM> can include information the IOT edge nodes generated, aggregated, filtered, or the like, in response to the execution of the embedded application corresponding to the container image. For example, when the IOT edge node receives industrial measurement data, the application messaging <NUM> can include a subset of the industrial measurement data, an aggregated report of the industrial measurement data, an indication that the IOT edge node detected an event from industrial measurement data, or the like.

The embedded application deployment unit <NUM> can include an embedded application state unit <NUM> to model states of the embedded applications deployed on IOT edge nodes based, at least in part, on the application messages <NUM> received from the IOT edge nodes. The embedded application state unit <NUM> can model the states of the embedded application by storing instances of container images capable of being deployed by the application manager <NUM>, instances of container images having been deployed, identifiers of IOT edge nodes having been commissioned to receive container images from the application manager <NUM>, parameters supported by the container images, values of the parameters supported by the container images, or the like. The embedded application state unit <NUM> can update the model of the embedded applications on the IOT edge nodes when a new container image has been deployed to or released from an IOT edge node, based on contents of the application messages <NUM> from the IOT edge nodes implementing the embedded applications, or the like. In some embodiments, the model of the embedded application can correspond to an avatar of the deployed container images on the IOT edge nodes, which can mimic the operational states of the deployed container images as implemented on the IOT edge nodes. For example, when an IOT edge node implements a sound classification embedded application, the embedded application state unit <NUM> can generate a model of the sound classification embedded application that identifies the IOT edge node, identifies the sound classification embedded application has been deployed on the IOT edge node, identifies the parameters associated with the sound classification embedded application, identifies the values of the parameters, or the like.

The application manager <NUM> can include a publish-subscribe unit <NUM> to generate parameter messaging <NUM>, which can prompt the IOT edge nodes to import or export parameters associated with embedded applications implemented by the IOT edge nodes. Since the embedded application state unit <NUM> can include a model of the embedded application deployed in the IOT edge node, the publish-subscribe unit <NUM> can generate parameter messaging <NUM> to import or export parameters associated with the embedded application. In some embodiments, the publish-subscribe unit <NUM> can include parameter values in the parameter messaging <NUM> and the IOT edge nodes can import the parameter values into the embedded applications. The ability to import of parameter values into the embedded applications can allow the IOT server to remotely modify a deployed container image without having to release the already deployed container image and deploy a new container <NUM> with a modified container image.

The publish-subscribe unit <NUM> can generate parameter messaging <NUM> that, when provided to the IOT edge node, can prompt the IOT edge node to export a parameter value as application parameters <NUM>. The IOT edge node can transmit the application parameters <NUM> to the application manager <NUM> in the IOT server, which can utilize the parameter values to update the model of the embedded application. In some embodiments, the publish-subscribe unit <NUM> can retransmit the application parameters <NUM> to a different networking device or server platform, for example, to a networking device subscribed to receive the parameter value(s) exported from the IOT edge node in the application parameters <NUM>. In some embodiments, the parameter messaging <NUM> can specify where the IOT edge node should export the application parameters <NUM>, for example, identify a networking device to receive the application parameters <NUM>. The publish-subscribe unit <NUM> may utilize the models of the embedded applications to identify and track which parameter values to export from which embedded applications and which networking devices, such as other IOT edge nodes subscribe to receive the parameter values. The publish-subscribe unit <NUM> can generate the parameter messaging <NUM> to prompt an import of parameters from the embedded applications implemented on the IOT edge nodes, to prompt an export of parameters from the embedded applications implemented on the IOT edge nodes, to prompt the embedded applications implemented on the IOT edge nodes share parameters between themselves, or the like.

The application manager <NUM> can include a distributed resource utilization unit <NUM> to utilize multiple distributed IOT edge nodes to implement complex services, for example, by coordinating the deployment of containers <NUM> to the IOT edge nodes, while utilize the models of the deployed embedded applications along with the publish-subscribe technology to have the embedded applications communicate with each other across the distributed IOT edge nodes. By modeling the states of the embedded applications and coordinating the sharing of parameter values across distributed IOT edge nodes, the application manager <NUM> can direct the distributed IOT edge nodes to implement complex computing tasks or provide complex services, for example, unable to be performed by an individual IOT edge node.

In some embodiments, the distributed resource utilization unit <NUM> can off-load processing from the server environment to one or more of the IOT edge nodes in the on-premises environment. In some embodiments, the application manager <NUM> in the IOT server can identify available processing and/or memory resources in the IOT edge nodes, deploy containers <NUM> having container images that, when executed by the IOT edge nodes having available processing and/or memory resources, can perform the off-loaded processing from the server environment. The distributed resource utilization unit <NUM> can work in conjunction with the embedded application state unit <NUM> and the publish-subscribe unit <NUM> to enable multiple IOT edge nodes implementing the off-loaded processing to communicate parameters with each other. When multiple IOT edge nodes implement the off-loaded processing, the distributed resource utilization unit <NUM> can utilize the embedded application state unit <NUM> to generate models for the embedded applications to implement the off-loaded processing, and utilize the publish-subscribe unit <NUM> to configure parameter messaging <NUM> prompting exchange of parameters between the IOT edge nodes in order to accomplish their processing tasks.

<FIG> illustrates an example of an IOT edge node <NUM> with multiple deployed embedded applications according to various embodiments. Referring to <FIG>, the IOT edge node <NUM> can include a container manager <NUM> to receive containers <NUM> from an IOT server, for example, located in a server environment. The containers <NUM> can include container images corresponding to embedded applications for deployment on the IOT edge node <NUM>. The container manager <NUM> can provide the containers to Docker daemon <NUM> in the IOT edge node <NUM>, which can implement a Docker engine and execute the container images in the containers <NUM> to realize the embedded applications.

In the instant example, the Docker daemon <NUM> can have a Docker engine capable of supporting embedded applications corresponding to multiple containers <NUM>, <NUM>, and <NUM>. The container <NUM>, when implemented by the Docker daemon <NUM>, can execute a container image and implement an application controller <NUM>. The container <NUM> also can include a control agent <NUM> to communicate parameters <NUM> associated with the application controller <NUM> to the IOT server via an application manager <NUM>. In some embodiments, the control agent <NUM> can include a messaging application to communicate with the application manager <NUM> to import and export parameter values associated with the container <NUM> and the application controller <NUM>. The container <NUM>, when implemented by the Docker daemon <NUM>, can execute a container image and implement an application broker <NUM>. The container <NUM> also can include a control agent <NUM> to communicate parameters <NUM> associated with the application broker <NUM> to the IOT server via the application manager <NUM>. In some embodiments, the control agent <NUM> can include a messaging application to communicate with the application manager <NUM> to import and export parameter values associated with the container <NUM> and the application broker <NUM>. The container <NUM>, when implemented by the Docker daemon <NUM>, can execute a container image and implement an embedded application <NUM>. The container <NUM> also can include a control agent <NUM> to communicate parameters <NUM> associated with the embedded application <NUM> to the IOT server via the application manager <NUM>. In some embodiments, the control agent <NUM> can include a messaging application to communicate with the application manager <NUM> to import and export parameter values associated with the container <NUM> and the embedded application <NUM>.

The application manager <NUM> can receive parameter messages from the IOT server, for example, requesting to import or export parameters <NUM> from the containers <NUM>, <NUM>, or <NUM>. The application manager <NUM> can identify which of the containers <NUM>, <NUM>, or <NUM> to send the parameter messages and transmit the parameter messages to the control agents <NUM>, <NUM>, or <NUM> corresponding to the identified containers <NUM>, <NUM>, or <NUM>. In some embodiments, the control agents <NUM>, <NUM>, or <NUM>, in response to the parameter messages, can import a parameter value from the parameter messages. The control agents <NUM>, <NUM>, or <NUM> also can direct an export of a parameter <NUM> in response to the parameter messages. In some embodiments, the control agents <NUM>, <NUM>, or <NUM> can export parameters <NUM> to the application manager <NUM> for transmission to the IOT server in response to the parameter messages, for example, implementing a "commit" logic typically utilized for process control. The control agents <NUM>, <NUM>, or <NUM> also can prompt the corresponding embedded applications, such as application controller <NUM> or embedded application <NUM>, to export parameters <NUM> to a networking device, such as the IOT server, a different IOT edge node, a server environment, or the like.

The IOT edge node <NUM> can include a mote manager <NUM> to communicate with a sensor system, for example, having one or more sensors, actuators, peripheral nodes performing various operations, such as Artificial Intelligence (AI), or the like, located in an industrial environment. The mote manager <NUM> can receive messaging from an IOT server, for example, located in a server environment. In some embodiments, the messaging can include configuration data for the sensor system, and the mote manager <NUM> can forward the messaging to the sensor system or prompt the configuration of the sensor system based on the configuration data. The mote manager <NUM> also can receive information from the sensor system and forward the information to the IOT server, for example, generate messaging that includes the information and transmit the messaging to the IOT server.

The IOT edge node <NUM> executing the container images in the containers <NUM>, <NUM>, and <NUM> can implement a complex system, such as an industrial monitoring system utilizing sensor data <NUM> from the sensor system. The application broker <NUM> can receive the sensor data <NUM> from the sensor system and distribute the sensor data <NUM> to the application controller <NUM> and the embedded application <NUM>. In some embodiments, the application controller <NUM> and the embedded application <NUM> can be provided the messaging parameters of the application broker <NUM> via publish-subscribe operation. For example, the IOT server can request parameters <NUM> associated with the messaging functionality of the application broker <NUM>, which can be provided by the control agent <NUM> to the IOT server. The IOT server can utilize the publish-subscribe functionality to import the messaging parameters of the application broker <NUM> to the application controller <NUM> and the embedded application <NUM>, which can allow the application broker <NUM> to distribute the sensor data <NUM> to the application controller <NUM> and the embedded application <NUM>.

The application controller <NUM> and the embedded application <NUM> can analyze the sensor data <NUM> to monitor an industrial environment. When the application controller <NUM> and/or the embedded application <NUM> detect an event based on the analysis of the sensor data <NUM>, such as a machine malfunction, a temperature change, a detected noise, or the like, the application controller <NUM> and/or the embedded application <NUM> can generate application messaging for transmission to the IOT server or other networking device. The application messaging can include an indication of the detected event, sensor data <NUM> corresponding to the detected event, or the like.

<FIG> and <FIG> illustrate an example IOT system <NUM> including a data flow server <NUM> having a data flow map tool <NUM> according to various embodiments. Referring to <FIG>, the IOT system <NUM> can include a server system <NUM> having one or more IOT servers configured to implement services, such as a storage service <NUM>, a compute service <NUM>, an artificial intelligence (AI) service <NUM>, a business logic service <NUM>, or the like, for managed devices in the IOT system <NUM>.

The managed devices in the IOT system <NUM> can include generic IOT applications <NUM>-<NUM> in an edge system <NUM> and sensors, actuators, or other peripherals in a sensor system <NUM>. In some embodiments, the edge system <NUM> can include one or more IOT edge nodes configured, for example, with a containerized application, to implement the generic IOT applications <NUM>-<NUM>. The sensor system <NUM> can gather or generate information, for example, by monitoring one or more devices, and transmit the information to the server system <NUM> through the edge system <NUM>. In a manufacturing environment, such as a factory floor or multiple distributed factories, the sensor system <NUM> can gather information corresponding to the manufacturing of a product, for example, by identifying operations or operational states of manufacturing equipment, manufacturing lines, the manufacturing of products, inventory, testing or verification procedures for the products, or the like.

The edge system <NUM> can facilitate data communication between the server system <NUM> and the sensor system <NUM> and, in some embodiments, perform data processing or filtering operations on the data received by the sensor system <NUM> or the server system <NUM>. The edge system <NUM> can include multiple generic IOT applications <NUM>-<NUM> capable of exchanging data with the server system <NUM>, the sensor system <NUM>, and each other. In some embodiments, the generic IOT applications <NUM>-<NUM> can include embedded application systems configured, for example, with a containerized application, to implement programmable edge devices capable of being configured to implement data flows between the services <NUM>-<NUM> in the server system <NUM> and the sensors in the sensor system <NUM>.

The IOT system <NUM> can include data flow server <NUM> to define data flows between the sensor system <NUM> and the server system <NUM> through the applications deployed on the edge system <NUM>. The data flow map tool <NUM> in the data flow server <NUM> can generate one or more data flow maps that define paths from data to traverse the IOT system <NUM> along with any data processing or filtering for the edge system <NUM> to perform on the data.

The data flow map tool <NUM> can include an environment configuration unit <NUM> to model the server system <NUM> by separately modeling the IOT servers in the server system <NUM> or the services, such as a storage service <NUM>, a compute service <NUM>, an artificial intelligence (AI) service <NUM>, a business logic service <NUM>, or the like, implemented in the server system <NUM>. In some embodiments, the environment configuration unit <NUM> can identify endpoints for the IOT servers in the server system <NUM> or the services in the server system <NUM>. The endpoints can correspond to portions of the IOT servers in the server system <NUM> or the services capable of exchanging data with the edge system <NUM>.

The environment configuration unit <NUM> can model the edge system <NUM> by separately modeling the generic IOT applications <NUM>-<NUM> by their endpoints and the data processing operations capable of being implemented in the generic IOT applications <NUM>-<NUM>. The endpoints can correspond to portions of the generic IOT applications <NUM>-<NUM> in the edge system <NUM> capable of exchanging data with server system <NUM>, the sensor system <NUM>, or other generic IOT applications in the edge system <NUM>.

The environment configuration unit <NUM> can model the sensor system <NUM> by separately modeling the sensors implemented in the sensor system <NUM> according to a device the sensor monitors, a type of information gathered, or the like. In some embodiments, the environment configuration unit <NUM> can identify endpoints for the sensors in the in the sensor system <NUM>. The endpoints can correspond to portions of the sensors in the sensor system <NUM> capable of exchanging data with the edge system <NUM>.

The data flow map tool <NUM> can include a map unit <NUM> to generate one or more data flow maps based on the models of the server system <NUM>, the edge system <NUM>, the generic IOT applications <NUM>-<NUM>, and the sensor system <NUM>. Each of the data flow maps can describe a configuration for the IOT system <NUM> and define the data flow through the IOT system <NUM>. The data flow maps can utilize the endpoints in the IOT system <NUM> to link the sensors in the sensor system <NUM> to one or more of the generic IOT applications <NUM>-<NUM> in the edge system <NUM>, and link the generic IOT applications <NUM>-<NUM> in the edge system <NUM> to each other or to one or more IOT servers or services in the server system <NUM>. The data flow maps can identify a direction for the flow of data, for example, from a sensor-to-edge node-to-server, along with any active data processing, transformation, manipulation, filtering operations, or the like, to be performed on the data by one or more of generic IOT applications <NUM>-<NUM> in the data flow.

In some embodiments, the map unit <NUM> can generate a data flow map presentation <NUM> that can display the models of the sensors, IOT servers or services, and generic IOT applications <NUM>-<NUM> in the IOT system <NUM>. The data flow server <NUM>, in response to user input, can link the models in the IOT system <NUM>, for example, endpoint-to-endpoint, and define data processing operations to generate the data flow maps.

The data flow map tool <NUM> can include a deployment unit <NUM> to prompt the IOT system <NUM> to implement a configuration corresponding to at least one of the data flow maps. As will be described below in greater detail with reference to <FIG>, the deployment unit <NUM> can configure the generic IOT applications <NUM>-<NUM>, the sensor system <NUM>, and the server system services <NUM>-<NUM> to form an interconnect for the exchange of data between the server system <NUM> and the sensor system <NUM> and, optionally, to process data received in a data flow.

Referring to <FIG>, the IOT system <NUM> is similar to the IOT system <NUM> described in <FIG> except the data flow server <NUM> has deployed an example data flow map into the IOT system <NUM>. The deployment unit <NUM> can generate a configuration deployment <NUM> based on the example data flow map and provide the configuration deployment <NUM> to the edge system <NUM>, the configured IOT applications <NUM>-<NUM>, the sensor system <NUM>, and the server system services <NUM>-<NUM>. The generic IOT applications <NUM>-<NUM> in <FIG> can receive the configuration deployment <NUM> from the data flow map tool <NUM>, which can configure the generic IOT applications <NUM>-<NUM> according to the example data flow map into the configured IOT applications <NUM>-<NUM>. The sensors in the sensor system <NUM> also can receive the configuration deployment <NUM> from the data flow server <NUM>, which can configure the sensors according to the example data flow map. The configuration of the edge system <NUM> and the sensor system <NUM> with the configuration deployment <NUM> can allow the sensor system <NUM> to communicate with the server system <NUM> via the edge system <NUM> and, optionally, for the edge system <NUM> to perform data processing operations on the data exchanged between the sensor system <NUM> and the server system <NUM>.

The data flow server <NUM> can re-configure the IOT system <NUM> by transmitting a new configuration deployment <NUM> corresponding to a different data flow map developed by the map unit <NUM>. In some embodiments, the data flow server <NUM> can store many different data flow maps, which each describe a different configuration of the modeled IOT system <NUM> in <FIG>. This deployment and re-deployment of data flow maps onto the IOT system <NUM> may prompt a fast re-configuration of the IOT system <NUM> relative to a conventional process of stopping application and re-deploying a new set of applications. By including programmable edge devices, such as the generic IOT applications <NUM>-<NUM> described in <FIG>, the data flow server <NUM> can configure and re-configure the IOT system <NUM> to implement multiple different data flows without having to hardcode the data flows into the sensor system <NUM> and the edge system <NUM>.

<FIG> illustrates an example flowchart for implementation of a data flow map to configure an IOT system according to various embodiments. Referring to <FIG>, in a block <NUM>, a computing system implementing a data flow map tool can deploy containerized applications to edge nodes in an edge system. In some embodiments, the edge nodes can include embedded application systems to implement Docker engines for executing container images, for example, standalone, executable embedded applications, which can include executable code, runtime, system tools, system libraries, settings, or the like, utilized by the Docker engines to implement the embedded applications corresponding to the container images. When an edge node receives a container image corresponding to a programmable edge application, the edge node can execute the container image to implement a configurable IOT application capable of further configuration, for example, by a data flow server.

In a block <NUM>, the computing system implementing the data flow map tool can model endpoints of configurable IOT applications in an edge system, sensors, actuators, or other peripherals in a sensor system, and servers in a server environment. In some embodiments, the data flow map tool can model the server system by identifying endpoints for IOT servers or the services in the server system and then separately modeling IOT servers or services, such as a storage service, a compute service, an artificial intelligence (AI) service, a business logic service, or the like, based on their endpoints. The endpoints can correspond to portions of the IOT servers in the server system or the services capable of exchanging data with the edge system.

The data flow map tool can model the edge system by identifying endpoints of the configurable IOT applications hosted by one or more edge nodes in the edge system, identifying data processing capabilities in the configurable IOT applications, and separately modeling the configurable IOT applications by their endpoints and the data processing capabilities. The endpoints can correspond to portions of the configurable IOT applications capable of exchanging data with server system, the sensor system, or other configurable IOT applications hosted by one or more edge nodes in the edge system.

The data flow map tool can model the sensor system by separately modeling the sensors implemented in the sensor system according to a device the sensor monitors, a type of information gathered, or the like. In some embodiments, the environment configuration unit can identify endpoints for the sensors in the in the sensor system. The endpoints can correspond to portions of the sensors in the sensor system capable of exchanging data with the edge system.

In a block <NUM>, the computing system implementing the data flow map tool can develop a data flow map that defines a configuration for the configurable IOT applications and defines connectivity between the modeled endpoints. The data flow map tool can develop the data flows between the server system and the sensor system via the edge system, which can include endpoint-to-endpoint links between the configurable IOT applications and sensors, other configurable IOT applications, and/or servers along with a description of the data processing operations to be performed by the configurable IOT applications. The data flows defined by the data flow map tool can be implemented into a data flow map, which can describe a configuration for the sensors, configurable IOT applications, and servers, which can implement the data flows developed by the data flow map tool.

In a block <NUM>, the computing system implementing the data flow map tool can configure the edge system and the sensor system, which can implement the connectivity in the data flow map. In some embodiments, the data flow map tool can transmit a deployment configuration to the sensor system, which can prompt the sensors to output gathered data at a particular endpoint for transmission to a particular configurable IOT application. The data flow map tool also can transmit a deployment configuration to the edge system, which can prompt the configurable IOT applications to exchange data via particular endpoints with sensors, server, and/or configurable IOT applications. In some embodiments, the deployment configuration also can program the configurable IOT applications to implement one or more data processing algorithms, for example, to filter or manipulate data exchanged between the server system and the sensor system. Once configured with the deployment configuration, the sensor system, the edge system, and the server system can implement the data flows defined in the data flow map.

The system and apparatus described above may use dedicated processor systems, micro controllers, programmable logic devices, microprocessors, or any combination thereof, to perform some or all of the operations described herein. Some of the operations described above may be implemented in software and other operations may be implemented in hardware. Any of the operations, processes, and/or methods described herein may be performed by an apparatus, a device, and/or a system substantially similar to those as described herein and with reference to the illustrated figures.

The processing device may execute instructions or "code" stored in memory. The memory may store data as well. The processing device may include, but may not be limited to, an analog processor, a digital processor, a microprocessor, a multi-core processor, a processor array, a network processor, or the like. The processing device may be part of an integrated control system or system manager, or may be provided as a portable electronic device configured to interface with a networked system either locally or remotely via wireless transmission.

The processor memory may be integrated together with the processing device, for example RAM or FLASH memory disposed within an integrated circuit microprocessor or the like. In other examples, the memory may comprise an independent device, such as an external disk drive, a storage array, a portable FLASH key fob, or the like. The memory and processing device may be operatively coupled together, or in communication with each other, for example by an I/O port, a network connection, or the like, and the processing device may read a file stored on the memory. Associated memory may be "read only" by design (ROM) by virtue of permission settings, or not. Other examples of memory may include, but may not be limited to, WORM, EPROM, EEPROM, FLASH, or the like, which may be implemented in solid state semiconductor devices. Other memories may comprise moving parts, such as a known rotating disk drive. All such memories may be "machine-readable" and may be readable by a processing device.

Operating instructions or commands may be implemented or embodied in tangible forms of stored computer software (also known as "computer program" or "code"). Programs, or code, may be stored in a digital memory and may be read by the processing device. "Computer-readable storage medium" (or alternatively, "machine-readable storage medium") may include all of the foregoing types of memory, as well as new technologies of the future, as long as the memory may be capable of storing digital information in the nature of a computer program or other data, at least temporarily, and as long at the stored information may be "read" by an appropriate processing device. The term "computer-readable" may not be limited to the historical usage of "computer" to imply a complete mainframe, mini-computer, desktop or even laptop computer. Rather, "computer-readable" may comprise storage medium that may be readable by a processor, a processing device, or any computing system. Such media may be any available media that may be locally and/or remotely accessible by a computer or a processor, and may include volatile and non-volatile media, and removable and non-removable media, or any combination thereof.

A program stored in a computer-readable storage medium may comprise a computer program product. For example, a storage medium may be used as a convenient means to store or transport a computer program. For the sake of convenience, the operations may be described as various interconnected or coupled functional blocks or diagrams. However, there may be cases where these functional blocks or diagrams may be equivalently aggregated into a single logic device, program or operation with unclear boundaries.

While the application describes specific examples of carrying out embodiments, those skilled in the art will appreciate that there are numerous variations and permutations of the above described systems and techniques that fall within the scope of the invention as set forth in the appended claims.

One of skill in the art will also recognize that the concepts taught herein can be tailored to a particular application in many other ways. In particular, those skilled in the art will recognize that the illustrated examples are but one of many alternative implementations that will become apparent upon reading this disclosure.

Claim 1:
A method comprising:
generating, by a computing system, models of managed devices in an Internet of Things, IOT, system (<NUM>), wherein the managed devices include one or more edge devices hosting programmable edge device applications and sensors configured to output data towards one or more servers in the IOT system (<NUM>);
developing, by the computing system, a data flow map to define a connectivity of the programmable edge device applications to the sensors and the servers in the IOT system (<NUM>) for exchanging the data from the sensors to the servers in the IOT system (<NUM>) via the programmable edge device applications; and
prompting, by the computing system, configuration of the programmable edge device applications in the IOT system (<NUM>) based on the data flow map, which implements the connectivity of the programmable edge device applications to the sensors and to servers in the IOT system (<NUM>);
wherein generating the models of the managed devices in the IOT system (<NUM>) includes identifying each endpoint in the programmable edge device applications capable of transmitting or receiving the data and defining flows for the data from the endpoints of the sensors to the endpoints of the IOT servers (<NUM>) via the endpoints of the programmable edge device applications.