Patent Publication Number: US-2023141746-A1

Title: Internet of things solution deployment in hybrid environment

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     The present application is a continuation application under 35 U.S.C. § 120 of U.S. patent application Ser. No. 16/683,269, filed on Nov. 14, 2019, which is incorporated herein by reference in its entirety. 
    
    
     BACKGROUND 
     Unless otherwise indicated herein, the approaches described in this section are not admitted to be prior art by inclusion in this section. 
     The Internet of Things (IoT) is a system including networks of devices and objects, such as sensors, actuators, edge gateways, and data centers, with the purpose of interconnecting all things in such a way as to make the things intelligent, programmable, and more capable of interacting with users and each other. An IoT solution may include hardware components such as sensors, actuators, edge gateways, and data centers and software components running on these hardware components. Data may be collected by sensors and transmitted to edge gateways for edge computing and data centers for cloud computing. Data centers and/or edge gateways may generate and transmit commands to actuators based on the computing so that actuators may perform actions according to the commands. Conventional IoT solutions may not be suitable in hybrid environments which integrate software and/or hardware components in the IoT solution from different vendors. 
    
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         FIG.  1    is a schematic diagram illustrating an example hybrid environment in which one or more IoT solutions are deployed; 
         FIG.  2    is a flowchart of an example virtualized computing environment including an example edge gateway agent to facilitate the deployment of one or more IoT solutions in a hybrid environment; and 
         FIG.  3    is a schematic diagram illustrating an example detailed process to deploy one or more IoT solutions in a hybrid environment. 
     
    
    
     DETAILED DESCRIPTION 
     In the following detailed description, reference is made to the accompanying drawings, which form a part hereof. In the drawings, similar symbols typically identify similar components, unless context dictates otherwise. The illustrative embodiments described in the detailed description, drawings, and claims are not meant to be limiting. Other embodiments may be utilized, and other changes may be made, without departing from the spirit or scope of the subject matter presented here. It will be readily understood that the aspects of the present disclosure, as generally described herein, and illustrated in the drawings, can be arranged, substituted, combined, and designed in a wide variety of different configurations, all of which are explicitly contemplated herein. 
     Challenges relating to an Internet of Things (IoT) solution deployment in a hybrid environment will now be explained in more detail using  FIG.  1   .  FIG.  1    is a schematic diagram illustrating an example hybrid environment  100  in which one or more IoT solutions are deployed. It should be understood that, depending on the desired implementation, hybrid environment  100  may include additional and/or alternative components than that shown in  FIG.  1   . 
     In the example illustrated in  FIG.  1   , a first homogeneous IoT solution  110  and a second homogeneous IoT solution  120  are deployed in hybrid environment  100 . In a homogeneous IoT solution, software and/or hardware components are from a single vendor. Homogeneous IoT solution  110  is provided by a first single vendor, and homogenous IoT solution  120  is provided by a second single vendor. 
     Homogeneous IoT solution  110  may include, but not limited to, data center  111 , edge gateway  112 , sensor  113 , actuator  114 , and connections  115  and  116 . Homogeneous IoT solution  110  may also include IoT service component  117  deployed in data center  111  and IoT service component  118  deployed in edge gateway  112 . 
     Similarly, homogeneous IoT solution  120  may include, but not limited to, data center  121 , edge gateway  122 , sensor  123 , and connections  124  and  125 . Homogeneous IoT solution  120  may also include IoT service component  126  deployed in data center  121  and IoT service components  127  deployed in edge gateway  122 . 
     In some embodiments, edge gateway  112  is disposed close to sensor  113  and actuator  114 , and connection  116  is implemented by a relatively short-ranged connection, such as Bluetooth, Wi-Fi, Zigbee, or Modbus. Data center  111  is distant from edge gateway  112 , sensor  113 , and actuator  114 . Connection  115  is implemented by a relatively long-ranged connection, such as connections implemented by Hypertext Transfer 2 (HTTP 2) or Message Queuing Telemetry Transport (MQTT). Similarly, edge gateway  122  is close to sensor  123 , and data center  121  is distant from edge gateway  122  and sensor  123 . Connection  124  is a relatively long-ranged connection while connection  125  is a relatively short-ranged connection. 
     For illustration only, for example, homogeneous IoT solution  110  is for monitoring and controlling an offshore oil field. Sensor  113  and actuator  114  may be disposed at the offshore oil field. Sensor  113  is configured to detect the pressure of the offshore oil field. Actuator  114  is configured to open a valve to release the pressure. Edge gateway  112  is also disposed at the first offshore oil field. IoT service component  118  is configured to interface and communicate with sensor  113  and actuator  114  through connection  116 . Edge gateway  112  is configured to communicate with data center  111 . Therefore, pressures detected by sensor  113  may be transmitted to onshore data center  111  through connections  116  and  115 . User  150  may access data center  111  through IoT service component  117  to remotely monitor the detected pressure. In response to the detected pressure exceeding a threshold, user  150  may issue a command of opening the valve to release the pressure to cloud  111  through IoT service component  117 . Cloud  111  is configured to send the command to edge gateway  112  through connection  115 . IoT service component  118  on edge gateway  112  is configured to send the command to actuator  114  through connection  116  so that actuator  114  may open the valve to release pressure according to the command. 
     For illustration only, for example, homogeneous IoT solution  120  is for monitoring and controlling a chemistry factory. Sensor  123  may be disposed in a remote pipeline of the factory to detect a temperature. Edge gateway  122  is disposed near the remote pipeline but away from a central control room of the factory. IoT service component  127  is configured to interface and communicate with sensor  123  through connection  125 . IoT service component  128  has machine learning capability. Edge gateway  122  is configured to transmit data collected by sensor  123  back to and receive data from data center  121  at the central control room of the factory through connection  124 . User  150  may access data center  121  through IoT service component  126  to monitor the detected temperature. In response to the detected temperature exceeding a threshold, user  150  may take actions to lower the temperature (e.g., increasing a flow rate of a cooling pipeline sleeved onto the remote pipeline). In some embodiments, based on the machine learning capability, IoT service component  128  is configured to determine a threshold temperature based on detected high temperatures and the corresponding lowered temperatures. 
     In some embodiments, edge computing at edge gateway  112  is important because connection  115  may be unstable in severe weather conditions (e.g., hurricanes or typhoons) and the commands to release the pressure may not be able to transmit to edge gateway  112  in time. In some embodiments, there is a need to deploy IoT service component  128  at edge gateway  112  to determine the threshold pressure and locally issue commands to release the pressure at edge gateway  112 . Conventionally, IoT service component  128  is specifically designed for homogenous IoT solution  120  and may not be compatible with components (e.g., edge gateway  112 ) of another homogeneous IoT solution  110 . 
     In some embodiments, edge gateway  112  is configured as virtualized computing environment to run IoT service components originally designed for other IoT solutions (e.g., IoT service component  128 ). The virtualized computing environment includes edge gateway agent  130 . Details of the edge gateway agents will be further described below. 
     In the example in  FIG.  2   , virtualized computing environment  200  includes multiple hosts (one shown for simplicity, e.g., edge gateway  112  in  FIG.  1   ) that are inter-connected via physical network  205 . Each host  210  includes suitable hardware  212  and virtualization software (e.g., hypervisor  214 ) to support various virtual machines  231 - 232 . In practice, virtualized computing environment  200  may include any number of hosts, where each host may be supporting one or more virtual machines. In addition, these hosts may be disposed at the same premises (e.g., the offshore oil field set forth above). VM 1   231  and VM 2   232  each represents a software implementation of a physical machine. 
     Although examples of the present disclosure refer to virtual machines, it should be understood that a “virtual machine” running on host  210  is merely one example of a “virtualized computing instance” or “workload.” A virtualized computing instance may represent an addressable data compute node or isolated user space instance. In practice, any suitable technology may be used to provide isolated user space instances, not just hardware virtualization. Other virtualized computing instances may include containers (e.g., running within a VM or on top of a host operating system without the need for a hypervisor or separate operating system or implemented as an operating system level virtualization), virtual private servers, client computers, etc. Such container technology is available from, among others, Docker, Inc. The virtual machines may also be complete computational environments, containing virtual equivalents of the hardware and software components of a physical computing system. An application supported by a virtual machine may be a containerized application. The term “hypervisor” may refer generally to a software layer or component that supports the execution of multiple virtualized computing instances, including system-level software in guest virtual machines that supports namespace containers such as Docker, etc. In some embodiments, in conjunction with  FIG.  1   , IoT service component  128  is configured as compiled executable files or container images to run on a virtualized computing instance or workload (e.g., VM 1   231  and VM 2   232 ) in virtualized computing environment  200 . 
     Hypervisor  214  maintains a mapping between underlying hardware  212  and virtual resources allocated to respective virtual machines  231 - 232 . Hardware  212  includes suitable physical components, such as central processing unit(s) or processor(s)  220 ; memory  222 ; physical network interface controllers (NICs)  224 ; and storage disk(s)  228  accessible via storage controller(s)  226 , etc. Virtual resources are allocated to each virtual machine  231 / 232  to support guest operating system (OS)  251 / 252  and IoT application  241 / 242 . Corresponding to hardware  212 , the virtual resources may include virtual CPU, virtual memory, virtual disk, virtual network interface controller (VNIC), etc. In the example in  FIG.  2   , virtual machines  231 - 232  are associated with respective VNICs  271 - 272  (also known as virtual Ethernet cards). Although one-to-one relationships are shown, one virtual machine may be associated with multiple VNICs (each VNIC having its own network address). 
     Hypervisor  214  further implements virtual switch  216  to handle egress packets from, and ingress packets to, respective virtual machines  231 - 232 . The term “packet” may refer generally to a group of bits that can be transported together from a source to a destination, such as a message, frame, segment, datagram, etc. For example in  FIG.  2   , VM 1   231  and VM 2   232  implement respective IoT applications  241 - 242  to interact with some IoT components (e.g., sensor  113 , actuator  114  in  FIG.  1    and other edge gateways  210  at the same premises) in an edge computing level through a short-ranged physical network  205  and other IoT components (e.g., data center  270 ) remotely in a cloud computing level through a long-ranged physical network  205 . Data center  270  may support IoT solution manager  272  to manage and/or deploy IoT applications  241  and  242  in virtualized computing environment  200 . 
     In some embodiments, hypervisor  214  is configured to deploy edge gateway agent  218  to communicate with IoT solution manager  272 . Edge gateway agent  218  collects information  293  associated with host  210  and sends the collected information to IoT solution manager  272 . In response, IoT solution manager  272  may issue a command to deploy IoT applications  241  and  242 . 
       FIG.  3    is a flowchart of example detailed process  300  for deploying IoT application in virtualized computing environment  200 . Example process  300  may include one or more operations, functions, or actions illustrated by one or more blocks, such as  305  to  340 . The various blocks may be combined into fewer blocks, divided into additional blocks, and/or eliminated depending on the desired implementation. As will be described further below, hypervisor  214  on host  210 , hypervisor  214 ′ on host  210 ′ and IoT solution manager  272  may implement example process  300 . 
     In conjunction with  FIG.  2   , at  305  in  FIG.  3   , host  210 , or more particularly hypervisor  214 , deploys edge gateway agent  218  to facilitate IoT solution deployments. In some embodiments, edge gateway agent  218  is supported by the host OS of host  210 . In some embodiments, edge gateway agent  218  is configured to push metadata  293  of host  210 , including hardware and software information of host  210 , to IoT solution manager  272 . Edge gateway agent  218  is also configured to push system usage metrics  293  of host  210 , including usages of hardware  212 , to IoT solution manager  272 . Edge gateway agent  218  is also configured to push location information of host  210  to IoT solution manager  272 . 
     Similarly, at  305 ′ in  FIG.  3   , host  210 ′, or more particularly hypervisor  214 ′, deploys edge gateway agent  218 ′ to facilitate IoT solution deployments. In some embodiments, edge gateway agent  218 ′ is supported by the host OS of host  210 ′. In some embodiments, edge gateway agent  218 ′ is configured to push metadata  293 ′ of host  210 ′, including hardware and software information of host  210 ′, to IoT solution manager  272 . Edge gateway agent  218 ′ is also configured to push system usage metrics  293 ′ of host  210 ′, including usages of hardware  212 ′, to IoT solution manager  272 . Edge gateway agent  218 ′ is also configured to push location information of host  210 ′ to IoT solution manager  272 . 
     In some embodiments, edge gateway agent  218  may use passthrough approaches to collect metadata and system usage metrics  293  of one single host  210  or virtualization approaches to aggregate metadata and system usage metrics  293  and  293 ′ of multiple hosts  210  and  210 ′ disposed in one single premise. 
     At  310  in  FIG.  3   , IoT solution manager  272  is configured to register hosts  210  and  210 ′ based on metadata and/or system usage metrics  293  and  293 ′ as a potential resource to deploy an IoT solution implemented by one or more IoT applications. 
     At  315  in  FIG.  3   , IoT solution manager  272  is configured to receive an IoT solution deployment request. The IoT solution deployment request may include an IoT solution template to deploy the IoT solution. The IoT solution template may specify one or more requirements to deploy the IoT solution. 
     At  320  in  FIG.  3   , IoT solution manager  272  is configured to determine whether hypervisors  214  or  214 ′ fulfils a first requirement specified in the IoT solution template. In response to a determination that hypervisors  214  or  214 ′ does not fulfil the first requirement, at  325  in  FIG.  3   , IoT solution manager  272  is configured to reject the deployment of the IoT solution on hosts  210  or  210 ′. 
     In some embodiments, the first requirement may include, but not limited to, an architecture on which the IoT solution is to be running and a communication protocol that the IoT solution uses. Some example architecture may include x86, arm64, and arm  32 . Some example communication protocols may include HTTP2 and MQTT. 
     In conjunction with  FIG.  1    and  FIG.  2   , hosts  210  or  210 ′ may be edge gateway  112  disposed at a remote place, such as an offshore oil field and hypervisor  214  or  214 ′ may be outdated to support the architecture on which the IoT solution to be running and the communication protocol that the IoT solution uses. In some embodiments, at  305  and  305 ′ in  FIG.  3   , information associated with hypervisors  214  and  214 ′ (e.g., vendor and version number) may be also collected by edge gateway agents  218 / 218 ′ and sent to IoT solution manager  272 . In some other embodiments, in response to a determination that hypervisors  214  or  214 ′ fulfils the first requirement, at  330  in  FIG.  3   , IoT solution manager  272  is configured to determine whether edge gateways  214  or  214 ′ fulfil a second requirement specified in the IoT solution template. 
     More specifically, at  330  in  FIG.  3   , IoT solution manager  272  is configured to determine whether hosts  210  and  210 ′ are disposed in the same premises based on the first location information and the second location information. 
     In some embodiments, in response to the determination that hosts  210  and  210 ′ are disposed in the same premises, IoT solution manager  272  is configured to aggregate system usage metrics  293  and  293 ′ to determine whether aggregated available hardware resources of hosts  210  and  210 ′ fulfil the second requirement. In response to the aggregated available hardware resources of hosts  210  and  210 ′ does not fulfil the second requirement, at  325  in  FIG.  3   , IoT solution manager  272  is configured to reject the deployment of the IoT solution. 
     In response to the aggregated available hardware resources of hosts  210  and  210 ′ fulfil the second requirement, at  335  and  335 ′ in  FIG.  3   , IoT solution manager  272  is configured to push the IoT solution template including compiled executable files or container images to hypervisor  214  and  214 ′. In response to receiving the IoT solution template, at  340  in  FIG.  3   , hypervisor  214  is configured to provision VM 1   231  and VM 2   232  according to the IoT solution template to run the compiled executable files or container images as IoT applications  241  and  242 . Similarly, at  340 ′ in  FIG.  3   , hypervisor  214 ′ is configured to provision VM 1   231 ′ and VM 2   232 ′ according to the IoT solution template to run the compiled executable files or container images as IoT applications  241 ′ and  242 ′. 
     In some other embodiments, in response to the determination that hosts  210  and  210 ′ are disposed in different premises, IoT solution manager  272  is configured to determine whether available hardware resources of host  210  fulfils the second requirement based on system usage metrics  293 . In response to the available hardware resources of host  210  does not fulfil the second requirement, at  325  in  FIG.  3   , IoT solution manager  272  is configured to reject the deployment of the IoT solution on host  210 . Similarly, IoT solution manager  272  is also configured to determine whether available hardware resources of host  210 ′ fulfill the second requirement based on system usage metrics  293 ′. In response to the available hardware resources of host  210 ′ does not fulfil the second requirement, at  325  in  FIG.  3   , IoT solution manager  272  is configured to reject the deployment of the IoT solution on host  210 ′. 
     In response to the available hardware resources of host  210  fulfilling the second requirement, at  335  in  FIG.  3   , IoT solution manager  272  is configured to push the IoT solution template including compiled executable files or container images to hypervisor  214 . In response to receiving the IoT solution template, at  340  in  FIG.  3   , hypervisor  214  is configured to provision VM 1   231  and VM 2   232  according to the IoT solution template to run the compiled executable files or container images as IoT applications  241  and  242 . 
     Similarly, in response to the available hardware resources of host  210 ′ fulfilling the second requirement, at  335 ′ in  FIG.  3   , IoT solution manager  272  is configured to push the IoT solution template including compiled executable files or container images to hypervisor  214 ′. In response to receiving the IoT solution template, at  340 ′ in  FIG.  3   , hypervisor  214 ′ is configured to provision VM 1   231 ′ and VM 2   232 ′ according to the IoT solution template to run the compiled executable files or container images as IoT applications  241 ′ and  242 ′. 
     Computer System 
     The above examples can be implemented by hardware (including hardware logic circuitry), software or firmware or a combination thereof. The above examples may be implemented by any suitable computing device, computer system, etc. The computer system may include processor(s), memory unit(s) and physical NIC(s) that may communicate with each other via a communication bus, etc. The computer system may include a non-transitory computer-readable medium having stored thereon instructions or program code that, when executed by the processor, cause the processor to perform processes described herein with reference to  FIG.  1    to  FIG.  5   . For example, a computer system may be deployed in virtualized computing environment  100  to perform the functionality of host  110  or server  180 . 
     The techniques introduced above can be implemented in special-purpose hardwired circuitry, in software and/or firmware in conjunction with programmable circuitry, or in a combination thereof. Special-purpose hardwired circuitry may be in the form of, for example, one or more application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), and others. The term ‘processor’ is to be interpreted broadly to include a processing unit, ASIC, logic unit, or programmable gate array etc. 
     The foregoing detailed description has set forth various embodiments of the devices and/or processes via the use of block diagrams, flowcharts, and/or examples. Insofar as such block diagrams, flowcharts, and/or examples contain one or more functions and/or operations, it will be understood by those within the art that each function and/or operation within such block diagrams, flowcharts, or examples can be implemented, individually and/or collectively, by a wide range of hardware, software, firmware, or any combination thereof. 
     Those skilled in the art will recognize that some aspects of the embodiments disclosed herein, in whole or in part, can be equivalently implemented in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and/or writing the code for the software and or firmware would be well within the skill of one of skill in the art in light of this disclosure. 
     Software and/or to implement the techniques introduced here may be stored on a non-transitory computer-readable storage medium and may be executed by one or more general-purpose or special-purpose programmable microprocessors. A “computer-readable storage medium”, as the term is used herein, includes any mechanism that provides (i.e., stores and/or transmits) information in a form accessible by a machine (e.g., a computer, network device, personal digital assistant (PDA), mobile device, manufacturing tool, any device with a set of one or more processors, etc.). A computer-readable storage medium may include recordable/non recordable media (e.g., read-only memory (ROM), random access memory (RAM), magnetic disk or optical storage media, flash memory devices, etc.). 
     The drawings are only illustrations of an example, wherein the units or procedure shown in the drawings are not necessarily essential for implementing the present disclosure. Those skilled in the art will understand that the units in the device in the examples can be arranged in the device in the examples as described, or can be alternatively located in one or more devices different from that in the examples. The units in the examples described can be combined into one module or further divided into a plurality of sub-units.