An apparatus and method for IoT communication and a processor-readable storage medium
By storing twin devices on IoT support services and utilizing their metadata to invoke methods, the inefficiencies and security deficiencies between IoT devices and third-party cloud services are resolved, achieving efficient and secure coordination and data synchronization between devices and cloud services.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2018-10-12
- Publication Date
- 2026-03-13
AI Technical Summary
The existing mapping and coordination between Internet of Things (IoT) devices and third-party cloud services suffers from inefficiency and insecurity, especially in terms of data synchronization and operation invocation between devices and cloud services.
By storing twin devices on the IoT support service, a mapping is established between IoT devices and a first third-party cloud service. The metadata of the twin devices is used to call associated methods, and the IoT support service coordinates operations with the third-party cloud service to achieve secure connection and efficient communication between the devices and the cloud service.
It improves the efficiency of data synchronization and operation invocation between IoT devices and third-party cloud services, enhances the security and flexibility of the system, and supports information exchange and device management in a multi-tenant environment.
Smart Images

Figure CN115550191B_ABST
Abstract
Description
[0001] Related patent applications
[0002] This application is a divisional application of the invention patent application with international application number PCT / US2018 / 055530, international application date of October 12, 2018, priority date of October 19, 2017, entry into the Chinese national phase on April 13, 2020, and Chinese application number 201880066774.0. Technical Field
[0003] This disclosure generally relates to the Internet of Things (IoT) field, and more particularly to IoT cloud-to-cloud architecture technologies. Background Technology
[0004] The Internet of Things (“IoT”) generally refers to a system of devices that can communicate via a network. These devices can include everyday items such as toasters, coffee makers, thermostat systems, washing machines, dryers, lights, and cars. The devices can also include industrial equipment in buildings and factory machinery, typically equipped with sensors and actuators. Network communication can be used for equipment automation, data capture, providing alerts, personalization, and many other applications. Summary of the Invention
[0005] This "Summary" is provided to introduce some concepts in a simplified form, which will be further described in the "Detailed Description" below. This "Summary" is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter.
[0006] In short, the disclosed technologies generally involve IoT technology.
[0007] In one example of this technology, a mapping is established between IoT devices (tenants of an IoT support service) and tenants of a first third-party cloud service. Twin devices are stored on the IoT support service, such that each twin device corresponds to a corresponding IoT device, and each twin device includes at least a first part and a second part. The first part includes attributes of the corresponding IoT device, and the second part includes attributes associated with the first third-party cloud service. The IoT support service is used to invoke a first method associated with at least one IoT device based on metadata in at least one corresponding twin device. The first method is associated with the first third-party cloud service.
[0008] After reading and understanding the accompanying drawings and specifications, one will be able to understand other aspects and applications of the disclosed technology. Attached Figure Description
[0009] Non-limiting and non-exhaustive examples of this disclosure are described with reference to the accompanying drawings. In the drawings, unless otherwise stated, the same reference numerals refer to the same parts in each drawing. These drawings are not necessarily drawn to scale.
[0010] To better understand this disclosure, reference will be made to the following "Detailed Description," which should be read in conjunction with the accompanying drawings, in which:
[0011] Figure 1 This is a block diagram illustrating an example of a suitable environment in which various aspects of this technology can be employed;
[0012] Figure 2 It is a block diagram illustrating an example of a suitable computing device according to aspects of the disclosed technology;
[0013] Figure 3 It is a block diagram illustrating an example of the system;
[0014] Figure 4 The diagram shows what can be used as Figure 3 A block diagram illustrating an example of a subset of the system; and
[0015] Figure 5 This is a flowchart illustrating an example process for IoT technology according to various aspects of this disclosure. Detailed Implementation
[0016] The following description provides specific details of the description of various examples for a thorough understanding and implementation of the technology. Those skilled in the art will understand that the technology can be implemented without many of these details. In some cases, known structures and functions have not been shown or described in detail to avoid unnecessarily obscuring the description of examples of the technology. The terminology used in this disclosure is intended to be interpreted in its broadest and most reasonable manner, even when used in conjunction with detailed descriptions of some examples of the technology. Although certain terms may be emphasized below, any term intended to be interpreted in any limiting manner will be explicitly and specifically defined in the “Detailed Description” section. Throughout the specification and claims, unless the context otherwise indicates, the following terms will have at least the meaning explicitly relevant herein. The meanings determined below are not necessarily limiting of the terms, but merely provide illustrative examples of the terms. For example, each of the terms “based on” and “based upon” is not exclusive and is equivalent to the term “based, at least in part, on”, and includes the option of being based on other factors, some of which may not be described herein. As another example, the term “via” is not exclusive and is equivalent to the term “at least partially via”, and includes the selection of additional factors, some of which may not be described herein. The meaning of “in” includes both “in” and “on”. The phrases “in one embodiment” or “in one example” as used herein may, but do not necessarily, refer to the same embodiment or example. The use of a specific textual numeric indicator does not imply the existence of a numeric indicator with a lower value. For example, the statement “a widget selected from the group including the third foo and the fourth bar” does not by itself imply the existence of at least three foos or at least four bar elements. Singular references are included solely for clarity of reading unless explicitly excluded. Unless otherwise explicitly stated, the term “or” is an inclusive “or” operator. For example, the phrase “A or B” means “A, B, or A and B”. As used herein, the terms “component” and “system” are intended to encompass hardware, software, or various combinations of hardware and software. Thus, for example, a system or component can be a process, a process performed on a computing device, a computing device, or a portion thereof. In short, the disclosed technology generally relates to IoT technology. In one example of this technology, a mapping is established between IoT devices belonging to a tenant of an IoT support service and tenants of a first third-party cloud service. Twin devices are stored on the IoT support service such that each twin device corresponds to a corresponding IoT device, and each twin device includes at least a first part and a second part, the first part including attributes of the corresponding IoT device, and the second part including attributes associated with the first third-party cloud service.The IoT support service invokes a first method associated with at least one IoT device based on metadata from at least one corresponding twin device. The first method is associated with a first third-party cloud service.
[0017] IoT devices can communicate with the IoT Support Service to receive IoT services, either directly or indirectly via one or more intermediary devices such as gateway devices. In some examples, the IoT Support Service can also coordinate third-party cloud services for use by IoT devices. In other examples, devices that typically cannot connect directly to the IoT Support Service can be enabled as IoT devices through coordination between the IoT Support Service and the third-party cloud service. For example, in some examples, devices can use a third-party cloud service as an intermediary to communicate with the IoT Support Service. In other examples, the IoT Support Service can use a third-party cloud service to reconfigure IoT devices and enable direct connections from IoT devices to the IoT Support Service while maintaining their ability to connect to the third-party cloud service.
[0018] Partners who can provide third-party cloud services for IoT devices can join the IoT Support Service by registering their third-party cloud services with the service. During the partner onboarding process, the security of the connection between the third-party cloud service and the IoT Support Service can be ensured.
[0019] Following partner onboarding, customer onboarding can occur. Customers can utilize the partner's services and have accounts and credentials associated with that partner. When a customer initially activates a third-party cloud service along with the IoT support service, a mapping can be established between the tenant in the third-party cloud service and the tenant in the IoT support service.
[0020] The device can then be supplied with IoT support services. After supply, communication can occur between the device and the IoT support services.
[0021] In some examples, the IoT Support Service stores twin devices. More specifically, the IoT Support Service may store a corresponding twin device for each IoT device. In some examples, each twin device is a collection of secure isolation primitives, including communication and state synchronization primitives. In some examples, each twin device includes metadata about the corresponding device, such as what type of device it is, various information about the device, and relevant information about the device it belongs to (e.g., the type, capabilities, location, etc. of the device associated with it). In some examples, at least a portion of each twin device is synchronized with the corresponding IoT device.
[0022] A twin device can include device attributes, some of which can be synchronized with the device. For example, in the case of a smart lock, the twin device can include attributes indicating whether the corresponding smart lock is locked or unlocked. In some examples, the twin device for each device includes portions associated with attributes used for third-party cloud services. In this way, IoT services can synchronize some of these attributes with the third-party cloud service, and the twin device can provide an overview of the device, including the attributes associated with the third-party cloud service. The twin device can expose methods that can be invoked through IoT support services corresponding to operations in the device. In some examples, if there are more than one third-party cloud service associated with the device corresponding to the twin device, the twin device has separate portions for each third-party cloud service.
[0023] Some methods can trigger actions to be performed by the IoT device through direct communication between the IoT support service and the IoT device. Other methods, associated with a third-party cloud service, can trigger actions to be performed by the third-party cloud service, in which case the IoT support service can communicate with the third-party cloud service (rather than directly with the IoT device). In some cases, methods associated with a third-party cloud service can cause the operation to be performed by the third-party cloud service on behalf of the device. For example, in the case of a device with a SIM card, a method can be invoked to change the device's rate plan, which may result in an operation performed by the third-party cloud service.
[0024] Descriptive equipment / operating environment
[0025] Figure 1 This is a diagram of an environment 100 that enables various aspects of this technology. As shown, environment 100 includes computing devices 110 and network nodes 120 connected via network 130. Even Figure 1 The diagram illustrates specific components of environment 100, but in other examples, environment 100 may also include additional and / or different components. For example, in some examples, environment 100 may also include network storage devices, a maintenance manager, and / or other suitable components (not shown). Figure 1 The computing device 110 shown can be located in various places, including indoors, in the cloud, etc. For example, the computing device 110 can be on the client side, the server side, etc.
[0026] like Figure 1As shown, network 130 may include one or more network nodes 120 that interconnect multiple computing devices 110 and connect the computing devices 110 to an external network 140 (e.g., the Internet or an intranet). For example, network node 120 may include a switch, router, hub, network controller, or other network element. In some examples, computing devices 110 may be organized into racks, operational areas, groups, sets, or other suitable partitions. For example, in the example shown, computing devices 110 are grouped into three host sets, identified as a first host set, a second host set, and a third host set 112a-112c, respectively. In the example shown, each host set 112a-112c is operatively coupled to a corresponding network node 120a-120c, which is typically referred to as a “top rack” or “TOR” network node. TOR network nodes 120a-120c may then be operatively coupled to additional network nodes 120 to form a hierarchical, planar, mesh, or other suitable type of topology computer network that allows communication between computing devices 110 and the external network 140. In other examples, multiple host groups 112a-112c may share a single network node 120. The computing device 110 can be virtually any type of general-purpose or special-purpose computing device. For example, these computing devices can be user devices such as desktop computers, laptop computers, tablet computers, display devices, cameras, printers, IoT devices, or smartphones. However, in a data center environment, these computing devices can be server devices such as application server computers, virtual computing host computers, or file server computers. Furthermore, the computing device 110 can be individually configured to provide computing, storage, and / or other suitable computing services.
[0027] In some examples, one or more of the computing devices 110 are IoT devices, gateway devices, devices that include some or all IoT support services, devices that include some or all application backends, etc., as discussed in more detail below.
[0028] Explanatory computing devices
[0029] Figure 2 This diagram illustrates an example of a computing device 200 in which aspects of the present technology can be practiced. The computing device 200 can, in fact, be any type of general-purpose or special-purpose computing device. For example, the computing device 200 can be a user device, such as a desktop computer, laptop computer, tablet computer, display device, camera, printer, or smartphone. Similarly, the computing device 200 can also be a server device, such as an application server computer, virtual computing host computer, or file server computer. For example, the computing device 200 can be… Figure 1Examples of computing device 110 or network node 120. Computing device 200 can also be an IoT device connected to the network to receive IoT services. Similarly, computer device 200 can be... Figures 3-5 Examples of any devices shown or referenced herein are discussed in more detail below. Figure 2 As shown, computing device 200 includes processing circuitry 210, operating memory 220, memory controller 230, data storage memory 250, input interface 260, output interface 270, and network adapter 280. Each of these components listed above in the computing device 200 includes at least one hardware element.
[0030] Computing device 200 includes at least one processing circuitry 210 configured to execute instructions, such as instructions for implementing the workloads, processes, or techniques described herein. Processing circuitry 210 may include a microprocessor, microcontroller, graphics processor, coprocessor, field-programmable gate array, programmable logic device, signal processor, or any other circuitry suitable for processing data. Processing circuitry 210 is an example of a kernel. The aforementioned instructions, along with other data (e.g., datasets, metadata, operating system instructions, etc.), may be stored in operational memory 220 during runtime of computing device 200. Operational memory 220 may also include any of a variety of data storage devices / components, such as volatile memory, semi-volatile memory, random access memory, static memory, cache, buffer, or other media for storing runtime information. In one example, operational memory 220 does not retain information when computing device 200 is powered off. Instead, as part of a boot or other loading process, computing device 200 may be configured to transfer instructions from a non-volatile data storage component (e.g., data storage component 250) to operational memory 220. In some examples, other forms of execution may be employed, such as execution directly from the data storage memory 250, for example, execution in the field (XIP).
[0031] Operational memory 220 may include fourth-generation double data rate (DDR4) memory, third-generation double data rate (DDR3) memory, other dynamic random access memory (DRAM), high-bandwidth memory (HBM), hybrid memory cube memory, 3D stacked memory, static random access memory (SRAM), magnetoresistive random access memory (MRAM), pseudo static random access memory (PSRAM), or other memory. Such memory may include integration into DIMMs, SIMMs, SODIMMs, known-qualified wafers (KGD), or other memories, and may include one or more memory circuits integrated onto DIMMs, SIMMs, SODIMMs, or other packages. Such operational memory modules or devices can be organized according to channels, ranks, and libraries. For example, an operational memory device may be coupled to processing circuitry 210 via a memory controller 230 in a channel. An example of computing device 200 may include one or two DIMMs per channel, with each channel having one or two ranks. Operational memory within a rank may operate with a shared clock, shared address, and command bus. Furthermore, operational memory devices can be organized into several banks, where banks can be considered as arrays addressed by rows and columns. Based on this operational memory organization, physical addresses within operational memory can be referenced via tuples of channels, levels, banks, rows, and columns.
[0032] Despite the above discussion, the operational memory 220 specifically does not include or includes a communication medium, any communication medium or any signal itself.
[0033] Memory controller 230 is configured to interface processing circuitry 210 to operational memory 220. For example, memory controller 230 may be configured to interface commands, addresses, and data between operational memory 220 and processing circuitry 210. Memory controller 230 may also be configured to abstract or otherwise manage certain aspects of memory management of processing circuitry 210. Although memory controller 230 is shown as a single memory controller separate from processing circuitry 210, in other examples, multiple memory controllers may be employed, memory controllers may be integrated with operational memory 220, and so on. Furthermore, memory controllers may be integrated into processing circuitry 210. These and other variations are possible.
[0034] In computing device 200, data storage memory 250, input interface 260, output interface 270, and network adapter 280 are interfaced to processing circuitry 210 via bus 240. Although Figure 2Bus 240 is shown as a single passive bus, but other configurations (such as bus sets, sets of point-to-point links, input / output controllers, bridges, other interface circuitry, or any set thereof) may also be suitably employed to interface data storage memory 250, input interface 260, output interface 270, or network adapter 280 to processing circuitry 210.
[0035] In computing device 200, data storage memory 250 is employed for long-term non-volatile data storage. Data storage memory 250 may include any of a variety of non-volatile data storage devices / components, such as non-volatile memory, disk, disk drive, hard disk drive, solid-state drive, or any other medium that can be used for non-volatile storage of information. However, data storage memory 250 specifically does not include or includes communication media, any communication media, or any signal itself. Unlike operational memory 220, data storage memory 250 is employed by computing device 200 for long-term non-volatile data storage, not for runtime data storage.
[0036] Furthermore, computing device 200 may include or be coupled to any type of processor-readable medium, such as processor-readable storage medium (e.g., operational memory 220 and data storage memory 250) and communication medium (e.g., communication signals and radio waves). While the term "processor-readable storage medium" includes operational memory 220 and data storage memory 250, whether used in the singular or plural form, the term "processor-readable storage medium" throughout the specification and claims is defined herein to specifically exclude and not include communication media, any communication medium, or any signal itself. However, the term "processor-readable storage medium" does include processor cache, random access memory (RAM), register memory, etc.
[0037] The computing device 200 also includes an input interface 260 that can be configured to support the computing device 200 receiving input from a user or from other devices. Additionally, the computing device 200 includes an output interface 270 that can be configured to provide output from the computing device 200. In one example, the output interface 270 includes a frame buffer, a graphics processor, a graphics processing unit, or an accelerator, and is configured to draw a display for presentation on a separate visual display device, such as a monitor, projector, virtual computing client computer, etc. In another example, the output interface 270 includes a visual display device and is configured to draw and present a display for viewing. In yet another example, the input interface 260 and / or the output interface 270 can include a universal asynchronous receiver / transmitter (“UART”), a serial peripheral interface (“SPI”), an internal integrated circuit (“I2C”), a general purpose input / output (GPIO) device, etc. Furthermore, the input interface 260 and / or the output interface 270 can include or interface to any number or type of peripheral devices.
[0038] In the illustrated example, computing device 200 is configured to communicate with other computing devices or entities via network adapter 280. Network adapter 280 may include a wired network adapter, such as an Ethernet adapter, a Token Ring adapter, or a Digital Subscriber Line (DSL) adapter. Network adapter 280 may also include a wireless network adapter, such as a Wi-Fi adapter, a Bluetooth adapter, a ZigBee adapter, a Long Term Evolution (LTE) adapter, a SigFox adapter, a LoRa adapter, a powerline adapter, or a 5G adapter.
[0039] Although computing device 200 is shown as having certain components configured in a particular arrangement, these components and arrangements are merely one example of computing devices that can employ this technology. In other examples, data storage memory 250, input interface 260, output interface 270, or network adapter 280 may be directly coupled to processing circuitry 210, or coupled to processing circuitry 210 via input / output controllers, bridges, or other interfaces. Other variations of this technology are possible.
[0040] Some examples of computing device 200 include at least one memory (e.g., operational memory 220) adapted to store runtime data and at least one processor (e.g., processing unit 210) adapted to execute processor-executable code, which in some examples enables computing device 200 to perform actions in response to execution.
[0041] Explanatory System
[0042] Figure 3This is a block diagram illustrating an example of system (300). System 300 may include network 330, as well as IoT support services 351, IoT devices 341-343, gateway edge devices 311 and 312, provisioning service device 315, application backend 313, and third-party cloud service 314, all connected to network 330. The term "IoT device" refers to a device designed to utilize IoT services. IoT devices can actually include any device connected to the cloud to use IoT services, including for telemetry collection or any other purpose. IoT devices include any device that can connect to a network to utilize IoT services. IoT devices can include everyday items such as toasters, coffee makers, thermostat systems, washing machines, dryers, lights, cars, etc. IoT devices can also include, for example, various devices, including industrial equipment, equipped with sensors or actuators. For example, a "smart" building may include lights, temperature sensors, thermostats, humidity sensors, occupancy sensors, door locks, HVAC control modules, etc. The IoT services of IoT devices can be used for device automation, data capture, providing alarms, performing operations / actions on the device via their actuators, and / or personalized settings. However, the above list only includes some of the many possible users of IoT services. Regardless of whether such applications are discussed in this article, these services can be used in or combined with numerous other applications. Some examples allow devices not operating as IoT devices (such as legacy devices) to be enabled as IoT devices through other devices. For example, some IoT devices 341-343 could be mobile devices, various devices with SIM cards (such as vending machines with SIM cards), etc., which can be activated to operate as IoT devices. In some examples, IoT devices 341-343, as well as gateway devices 311 and 312, are edge devices. In some examples, although not listed in... Figure 3 As shown in the diagram, network 330 may also include cloud-side gateway devices.
[0043] Application backend 313 refers to one or more devices, such as a distributed system, that perform actions to collect and store data, and / or actions based on IoT data, including user access and control, data analysis, data display, data storage control, and automated actions based on IoT data. For example, application backend 313 may include one or more devices that perform backend functions to support IoT services. In some examples, at least some actions performed by the application backend may be performed by services and applications running in application backend 313, while other actions may be performed by IoT devices or third-party cloud services.
[0044] Third-party cloud service 314 refers to one or more devices that perform actions to provide third-party cloud services. Examples of third-party cloud services may include update management services, mobile network management services, etc.
[0045] The term "IoT support service" refers to one or more devices, such as a distributed system, where, in some examples, IoT devices connect to a network for IoT services. In some examples, the IoT support service is an IoT hub. In some examples, the IoT hub is excluded, and the IoT devices communicate directly with the application backend, either directly or through one or more intermediaries, without the IoT hub, and software components in the application backend operate as the IoT support service. IoT devices receive IoT services via communication with the IoT support service.
[0046] In some examples, gateway devices 311 and 312 are each one or more devices, such as a distributed system. In some examples, a gateway device may be an edge device that acts as a network intermediary between one or more IoT devices and IoT support services.
[0047] In some examples, Device Provisioning Service 315 refers to one or more devices, such as distributed systems, that perform actions when providing edge devices to IoT support services.
[0048] Each of the IoT devices 341-343, and / or devices including IoT support services 351 and / or application backends 313 and / or gateway devices 311 and 312 and / or provisioning service devices 315 may include Figure 2 Examples of computing devices 200. The term "IoT support service" is not limited to a specific type of IoT service, but refers to a device with which an IoT device communicates with at least one IoT application, IoT solution, or IoT service after provision. That is, the term "IoT support service" as used throughout the specification and claims is generic for any IoT solution. The term "IoT support service" refers only to a portion of the IoT solution / IoT service / IoT application with which the supplied IoT device communicates. In some examples, communication between the IoT device and one or more application backends occurs through an IoT support service as an intermediary. The IoT support service is in the cloud, while the IoT device is an edge device. Figure 3 and the instructions Figure 3 The corresponding description illustrates an example system for illustrative purposes, which does not limit the scope of this disclosure.
[0049] Network 330 may include one or more computer networks, including wired and / or wireless networks, where each network may be, for example, a wireless network, a local area network (LAN), a wide area network (WAN), and / or a global network such as the Internet. On a set of interconnected LANs, including LANs based on different architectures and protocols, routers serve as links between LANs to enable messages to be sent from one LAN to another. Furthermore, communication links within a LAN typically include twisted-pair or coaxial cable, while communication links between networks may utilize analog telephone lines, all or part of dedicated digital lines (including T1, T2, T3, and T4), Integrated Services Digital Network (ISDN), Digital Subscriber Line (DSL), wireless links (including cellular and satellite links), or other communication links known to those skilled in the art. Additionally, remote computers and other associated electronic devices may be remotely connected to the LAN or WAN via modems and temporary telephone links. Essentially, network 330 includes any communication method through which information can travel between IoT support services 351, IoT devices 341-343, and / or application backend 313. Although each device or service is shown as connected to network 330, this does not mean that each device communicates with every other device shown. In some examples, some of the devices / services shown communicate only with some other devices / services shown via one or more intermediate devices. Furthermore, while network 330 is shown as a single network, in some examples, network 330 may instead comprise multiple networks that may or may not be connected to each other, with some devices shown communicating with each other through one of these networks, while other devices are shown communicating with each other through different networks.
[0050] As an example, IoT devices 341-343 are devices designed to utilize IoT services provided by an IoT support service. In some examples, the IoT support service includes one or more IoT support services, such as IoT support service 351. IoT devices 341-343 may be coupled to IoT support service 351 directly, via network 330, via gateway devices (e.g., gateway device 312), via multiple gateway devices, via third-party services, etc.
[0051] System 300 may include more than those shown by way of example only. Figure 3 The number of devices shown may be more or less.
[0052] Figure 4 This is a diagram illustrating an example of system 400. In some examples, system 400 can be used as... Figure 3 A subset of system 300. Figure 4 and the instruction manual Figure 4The corresponding description illustrates an example system for illustrative purposes, which does not limit the scope of this disclosure.
[0053] In some examples, system 400 includes IoT device 441, IoT device 442, IoT support service 451, application backend 413, provisioning service device 415, and third-party cloud service 414. Some examples of IoT support service 451 include twin device DT1, twin device DT2, and scheduler 457.
[0054] In some examples, scheduler 457 performs functions such as scheduling communications, coordinating telemetry traffic, synchronizing twin device attributes, and performing operations between IoT support services and IoT devices or third-party cloud services.
[0055] In some examples, IoT support service 451 stores a corresponding twin device (e.g., DT1, DT2) for each IoT device (e.g., 441, 442) supplied with IoT support service 451. In some examples, each twin device is a set of securely isolated primitives, including communication and state synchronization primitives. In some examples, each twin device includes metadata about the corresponding device, such as what type of device it is, various information about the device, and information about the device (or equipment) it is associated with (e.g., the type, capabilities, location, etc. of the associated equipment). Twin devices may also include metadata describing operations associated with supported third-party cloud services, including expected parameters and valid ranges. In some examples, at least a portion of each twin device is synchronized with the corresponding device.
[0056] Each twin device can include device attributes, some of which can be synchronized with the device. For example, in the case of a smart lock, the twin device can include attributes indicating whether the corresponding smart lock is locked or unlocked. In some examples, the twin device for each device includes a portion associated with attributes of a third-party cloud service. In this way, the twin device can provide an aggregated view of the device across IoT device attributes and attributes associated with third-party cloud services. In some examples, if there are more than one third-party cloud service associated with the device corresponding to the twin device, the twin device has a separate portion for each third-party cloud service. The twin device can be used to synchronize device status and configuration. Furthermore, the twin device can expose metadata information related to the operations supported by the device, including operations associated with third-party cloud services. The application backend 413 can use the twin device to query supported operations and desired parameters for execution.
[0057] For example, applications such as those in the application backend can query the twin device for a list of available operations (i.e., methods) and possible parameter values, present this information to the end user to select the desired operation and possible parameter values, and enable the user to trigger the execution of the operation via an IoT support service. As discussed in more detail below, the twin device can also make functionality provided by a third-party cloud service available to the application backend 413. In this way, in some examples, when an application queries the twin device for a list of available methods and possible parameter values, presents this information to the end user to select the desired operation and possible parameter values, and enables the user to trigger the execution of the operation via an IoT support service, the response to the query may also include making the method available via a third-party cloud service, and the user is also enabled to trigger the execution of the method associated with the third-party cloud service, wherein the IoT support service can communicate with the corresponding third-party cloud service to execute the method.
[0058] Jobs can be used to update twin devices on a large scale and / or invoke methods on a large scale across many devices. In some examples, a method is an interactive request-response pattern used to invoke capabilities (or operations) on the device, such as locking or unlocking a door, turning a light on or off, etc. Jobs can be used to update twin devices or invoke methods on a schedule and track the execution progress of a large number of devices. Jobs can be initiated by scheduling job instructions received from the application backend 413 by the method of IoT support service 451 and job execution component 455. In some examples, scheduler 457 is configured to schedule communication to third-party cloud service 414, for example, as part of invoking a method associated with third-party cloud service 414.
[0059] In some examples, partner onboarding can be used to associate one or more third-party cloud services as providers associated with IoT services provided by IoT Support Service 451. During partner onboarding, in some examples, one or more connections between IoT Support Service 451 and third-party cloud service 414 are protected. In some examples, during the partner onboarding phase, one or more secure connections are pre-established before a specific tenant can be connected and before that tenant begins exchanging information via a secure connection in a later phase. In some examples, multi-tenant access and integration are configured during partner onboarding. In some examples, a registration process is used to register one or more third-party cloud services with IoT Support Service 451 using a provider registry that can be stored in IoT Support Service 451.
[0060] In some examples, the provider registry stores information about connections to third-party cloud services. In some examples, the provider registry also stores information about the third-party cloud services, including metadata descriptions of what the third-party cloud services can do, such as what telemetry the third-party cloud services can emit, and which operations the third-party cloud services support, including expected parameters and valid parameter values. The provider registry may also store provider configuration information for each provider. In some examples, the provider registry contains all providers that are configured and available to customers for use with the IoT Support Service. In some examples, as part of provider registration, account and tenant information is exchanged, along with the necessary customer ID (or tenant ID) and secret. In some examples, IoT Support Service 451 manages the joining of providers for third-party cloud services.
[0061] In some examples, customer onboarding is performed after a partner joins. To perform third-party cloud services for devices associated with a specific customer, the customer may need to have an account and credentials with the provider of the third-party cloud service, and the customer's device may already be a tenant in the third-party cloud service. During customer onboarding, tenant configuration can be performed, which may vary based on the provider. In some examples, a mapping is established between tenants in the third-party cloud service and tenants in the IoT support service. For example, in some examples, such as multi-tenant integration between the IoT support service and the third-party cloud service, a mapping is established between tenants in both systems: the customer is represented as a tenant in both the multi-tenant IoT support service and the third-party cloud service, and a mapping is established between these tenants to enable the exchange of information about the customer's IoT devices (represented as different tenants in both systems). Multiple mappings can allow the exchange of information and data between the IoT support service 451 and the third-party cloud service 414 for secure multi-tenant connections for specific tenants. In some examples, provider metadata and configuration are stored for each registered provider for each tenant.
[0062] In some examples, device provisioning is performed after a customer joins. In some examples where a new customer joins, this happens next. In some examples, an existing IoT support service customer can add a third-party cloud service, in which case the device has already been provisioned. In some examples, the customer is a new customer, and the device associated with the new customer is provisioned after the customer joins. In some examples, the new device provided is an IoT device that can be directly connected to the device provisioning service 415 for provisioning. In this case, the device provisioning service 415 can coordinate the provisioning of the new device with the IoT support service and the third-party cloud service. In other examples, the new device may already be connected to a third-party cloud service, and the third-party cloud service can perform the provisioning of the device to the IoT support service through the device provisioning service 415.
[0063] In some examples, the new device may be an IoT device that has not yet been supplied with IoT Support Services. In some examples, the new device may already be connected to a third-party cloud service, and the third-party cloud service can supply the device to the IoT Support Services through Device Provisioning Service 415. In other examples, the device typically cannot operate as an IoT device through the IoT Support Services. For example, the new device may connect via a mobile network (e.g., via a SIM card) but is not configured as an IoT device. However, in some examples, the mobile network device is then able to operate as an IoT device after device provisioning. In this way, in some examples, a mobile network device that typically does not operate as an IoT device through the IoT Support Services can be supplied as an IoT device during device provisioning, including, for example, mobile devices, automobiles, or vending machines with SIM cards, other devices with SIM cards, etc.
[0064] In different examples, equipment provisioning can be accomplished in different ways. In some examples, during physical equipment installation, field technicians pair the equipment with the backend system in application backend 413 using handheld / mobile devices. In other examples, equipment provisioning is accomplished manually by entering the provisioning information on the equipment itself.
[0065] In other examples, automated device provisioning can be used. In some examples of automated device provisioning, connectivity endpoints for provisioning the device can be etched into the device silicon. In some examples, secrets can also be etched into the device silicon. In some examples of automated provisioning, when the device is first powered on, it connects to a predefined connectivity endpoint for provisioning the device (e.g., this could be an endpoint of device provisioning service 415 or a third-party cloud service 414). In some examples, a provisioning service such as device provisioning service 415 resides at a predefined endpoint, and after the device is first powered on and contacts the predefined endpoint, device provisioning service 415 can coordinate the provisioning of the device. In other examples, the device can connect to a third-party cloud service for provisioning, and the third-party cloud service can then use the device provisioning service to automatically provision the device via an IoT support service.
[0066] In some examples, regardless of the method used for device provisioning, from a cloud-to-cloud perspective, provisioning is integrated into a single workflow. The device provisioning service can feed information to a third-party cloud service, or information can be fed from a third-party cloud service to the device provisioning service 415, so that the device is provisioned in the IoT support service 451 while information is being fed from the third-party cloud service to the IoT support service 451.
[0067] In the example of a device with a SIM card, the SIM card ID can be used as the device ID, or the SIM card ID can be mapped to a device ID. In the case of some devices, such as automobiles, a device ID may already exist, such as the Electronic Serial Number (ESN) of a vehicle component. The ESN of the vehicle component can be used as the device ID, or it can be mapped to another device ID. A car can have a SIM card with another ID, which, whether that device ID is an ESN or some other device ID, can also be mapped to that device ID. In some technologies, the SIM card ID is an Integrated Circuit Card Identifier (ICCID).
[0068] In some examples, during provisioning, a communication channel is also established between the device (e.g., IoT device 441 or 442), the third-party cloud service 414, and the IoT support service 451. In some examples, the communication channel is configured so that high-capacity, high-speed telemetry goes directly to the IoT support service 451, while in others, command and control and / or device management communication can be established through the third-party cloud service 414. In some examples, during device provisioning, code can be deployed on some IoT devices to enable the IoT devices to communicate with the IoT support service 451.
[0069] During device provisioning, in some examples, certain twin properties can be established, including provider ID and provider tenant ID. In some examples, provider-specific device commands (methods) can be configured in the IoT device registry and / or twin device of the IoT Support Services during device provisioning.
[0070] In some examples, when device provisioning occurs after a new customer joins, the third-party cloud can push new devices to IoT Support Service 451, where devices are imported in bulk via Provisioning Service 415. The third-party ID can be verified against the third-party cloud service 414 as part of the provisioning process. In some examples, the third-party cloud service 414 can be used as an attestation point for devices provisioned to IoT Support Service 451. In some examples, provisioning to IoT Support Service can be performed "on-demand" when a device attempts to connect to IoT Support Service for the first time by verifying its identity against the third-party cloud service and immediately performing provisioning.
[0071] Third-party specific device attributes can be established with the corresponding twin device during device provisioning, where the third-party provider is responsible for these attributes. IoT Service 451 allows some third-party twin device attributes to be synchronized with third-party cloud services. In some examples, third-party specific device attributes can be queried from other sources, but changes to some third-party specific device attributes may be limited to those initiated by the corresponding third-party cloud service. Actions for secure communication to and from the provisioned device and for authentication of the provisioned device can also be performed during device provisioning based on the configuration established during customer onboarding.
[0072] In some examples, after an IoT device is supplied, it has a corresponding twin device stored in an IoT support service. In some examples, the root of the twin device includes read-only attributes from the corresponding device identity stored in an identity register. The twin device may also include the following: attributes and third-party cloud service attributes. Attributes can have different types, including, in some examples, synchronized attributes and attributes that include unsynchronized metadata. In some examples, attributes may include reported attributes and expected attributes.
[0073] As described above, in some examples, devices connected via a mobile network that typically do not operate as IoT devices through the IoT Support Service can be supplied as IoT devices during device provisioning. These include, for example, mobile devices, automobiles, or vending machines with SIM cards, and other devices with SIM cards. During customer onboarding, in some examples, a mapping is established between tenants in the third-party cloud service and tenants in the IoT Support Service. In some examples, the IoT Support Service 451 does not directly perform actions such as activating the SIM card, but such actions can be initiated within the IoT Support Service 451 through invoked methods, allowing the third-party cloud service to ultimately activate the SIM card through communication and coordination with the IoT Support Service 451.
[0074] Attributes can be used to synchronize device configurations or status. Examples of attributes may include, for instance, whether the light is on or off in the case of a smart light, and whether the lock is locked or unlocked in the case of a smart lock. In some examples, third-party attributes are device attributes associated with a third-party cloud service. For example, if the third-party cloud service is a mobile network management service, third-party attributes may include data usage for the current billing period, maximum data allowance, and the attributes of the corresponding device's SIM card, etc.
[0075] Therefore, in some examples, a twin device may have separate sections, including an attribute section for storing attributes, a third-party cloud service section for storing attributes associated with third-party cloud services, and a section including the root of the twin device, which includes read-only attributes from the corresponding device identity stored in an identity register. The device may be associated with multiple third-party cloud services; in this case, the twin device may have multiple third-party cloud service sections, one for each third-party cloud service associated with the device. The twin's third-party cloud service sections may also include some or all of the provider information corresponding to the third-party cloud service stored in a provider registry. In some examples, if there is more than one third-party cloud service associated with the corresponding IoT device, the twin device has a separate section for each third-party cloud service.
[0076] As described above, a job can be initiated by creating or scheduling job instructions received from the application backend 413 by the methods of the IoT support service 451 and the job execution component 455. In some examples, the methods include not only those directly associated with the IoT device but also those associated with third-party cloud services. For example, in the case of a device with a SIM card, a method can be invoked to change the rate plan on the device, activate the SIM card, deactivate the SIM card, and so on.
[0077] Many other actions can be performed as invoking methods based on third-party cloud services. For example, for troubleshooting purposes, IoT support service 451 can reset, for example, cellular or other mobile network connections via an invoked method. In some examples, IoT support service 451 does not communicate directly with the device to reset the mobile network connection, but instead invokes a method that ultimately involves scheduler 457 sending communication to third-party cloud service 414, causing third-party cloud service 415 to cause the connected device to reset its mobile network connection. Metadata, including information such as where specific commands should be sent (e.g., to the device or the third-party cloud service) and where messages associated with the device should be sent (e.g., where telemetry data from the device should be sent), can be stored in a digital twin corresponding to the provider's device and / or metadata description in the provider's registry. Even when the third-party cloud service communicates with the device, method and job execution component 455 can orchestrate methods associated with the third-party cloud service.
[0078] When a method is invoked on an IoT device, IoT Support Service 451 determines whether to execute the method directly on the device or via a third-party cloud service. This determination is based on how the IoT device that invoked the method was registered with IoT Support Service 451 during provisioning. During provisioning, the device was already registered with IoT Support Service, and this registration also includes information about which third-party cloud service providers were enabled for the device. The twin device exposes methods implemented using third-party cloud services (as well as methods implemented directly using the corresponding IoT device), allowing the twin device to be queried to determine which methods are available for invocation and which parameters are valid for executing the method.
[0079] As an example, for a software update, IoT support service 451 can receive a command from application backend 413 to receive a software update for a device, where the software update for that device is performed by a third-party cloud service. IoT support service 451 can then initiate the software update by calling a method and communicating with the corresponding third-party cloud service. IoT support service 451 can also track the progress of the update via communication with the third-party cloud service and can provide this status to application backend 413 in response to queries from application backend 413. After determining that the update is complete based on communication with the third-party cloud service, IoT support service 451 can report the update completion to application backend 413. Various other steps coordinated by IoT support service 451 can also be performed during the update process.
[0080] Various third-party cloud services can be used in different examples. Some examples of third-party cloud services are mobile network management services as described above. In other examples, third-party cloud services may be device management services for updating firmware and / or software, etc. In other examples, device management services may include configuration management, remote diagnostics, and troubleshooting, etc. In some examples, third-party cloud services may be device management and / or update services for specific types of devices such as automobiles.
[0081] After the device is supplied, communication to / from the device can occur as configured. In some examples, some communication to / from the device may occur using a third-party cloud service, while in other examples, some communication to / from the device may occur directly from the device to the IoT support service 451. For example, in an example where the third-party cloud service performs device management for the vehicle, in some examples, the vehicle sends telemetry messages to the IoT support service, including information such as GPS location, battery level, fuel level, and oil temperature. In some examples, the vehicle may also receive commands directly from the IoT support service. However, updates can be triggered via the third-party cloud service and delivered from the third-party cloud service to the device being updated.
[0082] The supplied IoT devices can be integrated with both IoT services controlled by the IoT Support Service and one or more integrated third-party cloud services. IoT applications (e.g., in the application backend) can read telemetry data from the IoT Support Service, regardless of whether the telemetry data originates directly from the IoT device or via a third-party cloud service.
[0083] Figure 5 The diagram illustrates what can be made from, for example Figure 3 and / or Figure 4 A flowchart (580) of an example process of IoT technology performed by IoT support services such as IoT support services.
[0084] In the illustrated example, step 581 occurs first. In step 581, in some examples, a mapping is established between multiple IoT devices of a tenant acting as an IoT support service and a tenant of the first third-party cloud service. For this tenant mapping, in some examples, a mapping is established between each tenant's tenant in the IoT support service (representing a customer) and a tenant in the first third-party cloud service (representing the same customer). In some examples, each customer has an identifier that identifies the customer in the IoT support system and another identifier that represents the customer in the first third-party cloud service. In some examples, for each customer who is a tenant in both the IoT support service and the first third-party cloud service, the tenant mapping is a mapping between the identifier of the customer in the IoT support service and the identifier of the customer in the first third-party cloud service.
[0085] As shown in the figure, in some examples, step 582 occurs next. In step 582, in some examples, multiple twin devices are stored on the IoT support service such that each of the multiple twin devices corresponds to a corresponding IoT device, and each of the multiple twin devices includes at least a first part and a second part, the first part including attributes of the corresponding IoT device, and the second part including attributes associated with a first third-party cloud service.
[0086] As shown in the figure, in some examples, step 583 occurs next. In step 583, in some examples, on the twin device, some device attributes in the device attributes are synchronized between the third-party cloud service and the IoT support service. In some examples, step 583 applies the attribute changes in both directions (device attributes associated with the third-party cloud service to attributes associated with the IoT support service, and vice versa). As shown in the figure, in some examples, step 584 occurs next.
[0087] In step 584, in some examples, device telemetry is received. This telemetry may come directly from the device, from a third-party cloud service, or from both. In some examples, different information comes from the device and the third-party cloud service. For example, in some examples, the device may be sending a set of environmental properties, such as temperature, pressure, etc., while the third-party cloud service may be sending information related to subcomponents or operational metrics, such as quality of service metrics (e.g., cellular service or software management service).
[0088] As shown in the figure, in some examples, step 585 occurs next. In step 585, in some examples, reading and writing of attributes on the twin device occurs. This includes both device attributes of the third-party cloud service and device attributes associated with the IoT-enabled device. In some examples, some attributes can be written to be changed, while others are only changed when a corresponding change in that attribute is reported from the corresponding device. In some examples, read and / or write requests can be received from the application in the application backend that initiated the request. In response to a write command, such as a write command received from the application backend, attributes associated with the third-party cloud service in the second part of the twin device and attributes associated with at least one of the device configuration or device status of the corresponding IoT device in the first part of the twin device can be changed (depending on security permissions and control over each part, as described above). In some examples, changes to attributes associated with the third-party cloud service will be propagated to the twin device according to step 583, and the application from the application backend will always be able to query the latest value stored in the twin device. The same applies to queries for multiple devices or all devices.
[0089] As shown in the figure, in some examples, step 586 occurs next. In step 586, in some examples, an IoT support service is used to invoke a first method associated with at least one IoT device based on metadata in at least one corresponding twin device among a plurality of twin devices. In some examples, the first method is associated with a first third-party cloud service.
[0090] Then, the process can proceed to the return box, where other processing can resume.
[0091] in conclusion
[0092] While the foregoing “Detailed Description” describes some examples of the technology and outlines the expected best mode, the technology can be implemented in a variety of ways, regardless of how detailed it is described above. Details may vary in implementation while still being included in the technology described herein. As noted above, specific terms used in describing certain features or aspects of the technology should not be construed as implying that such terms are redefined herein as limited to any particular feature, characteristic, or aspect associated with that term. Generally, the terms used in the following claims should not be construed as limiting the technology to the specific examples disclosed herein, unless such terms are expressly defined in the “Detailed Description”. Therefore, the actual scope of the technology includes not only the disclosed examples but also all equivalent ways of practicing or implementing the technology.
Claims
1. An apparatus for Internet of Things (IoT) communication, comprising: an IoT support service comprising one or more devices, the devices comprising at least one memory adapted to store runtime data and at least one processor adapted to execute processor-executable code that, in response to execution, enables the IoT support service to perform actions comprising: establishing a mapping between a plurality of IoT devices that are tenants of the IoT support service and a tenant of a third-party cloud service; storing, on the IoT support service, a plurality of twin devices such that each of the plurality of twin devices corresponds to a corresponding IoT device and such that each of the plurality of twin devices is adapted to store telemetry data received from the corresponding IoT device, wherein each of the plurality of twin devices is further adapted to store attribute data for indicating operations associated with the third-party cloud service; and serving, by the IoT support service, a query for telemetry associated with one or more of the plurality of IoT devices using the telemetry data and the attribute data stored by one or more of the corresponding twin devices of the plurality of twin devices.
2. The apparatus of claim 1, wherein at least one of the twin devices is adapted to synchronize the telemetry data with the corresponding IoT device.
3. The apparatus of claim 1, wherein a twin device of the plurality of twin devices is further adapted to receive additional telemetry data from the third-party cloud service.
4. The apparatus of claim 1, wherein the plurality of IoT devices comprises mobile network connected devices provisioned as IoT devices.
5. The apparatus of claim 1, wherein the attribute data comprises at least one of an expected value or an expected range of values for the received telemetry data.
6. The apparatus of claim 1, wherein each of the twin devices of the plurality of twin devices further comprises metadata regarding at least one of telemetry available from the third-party cloud service or where the received telemetry data is to be sent.
7. A method for Internet of Things (IoT) communication, comprising: mapping a plurality of IoT devices that are tenants of an IoT support service to a tenant of a third-party cloud service; storing, on the IoT support service, a plurality of twin devices such that each of the plurality of twin devices corresponds to a corresponding IoT device and such that each of the plurality of twin devices stores telemetry data received from the corresponding IoT device and further stores attribute data for indicating operations associated with the third-party cloud service; and serving, by the IoT support service, a query for telemetry associated with one or more of the plurality of IoT devices using the telemetry data and the attribute data stored by one or more of the corresponding twin devices of the plurality of twin devices.
8. The method of claim 7, wherein at least one of the twin devices is adapted to synchronize the telemetry data with a corresponding IoT device.
9. The method of claim 7, wherein a twin device of the plurality of twin devices is further adapted to receive additional telemetry data from the third party cloud service.
10. The method of claim 7, further comprising synchronizing the telemetry data received from the corresponding IoT device with the third party cloud service.
11. The method of claim 7, wherein the attribute data comprises at least one of an expected value or an expected range of values for the received telemetry data.
12. The method of claim 7, wherein each of the twin devices of the plurality of twin devices further comprises metadata regarding at least one of telemetry available from the third party cloud service or where the received telemetry data is to be sent.
13. The method of claim 7, wherein the third party cloud service is associated with at least one of device management, mobile network connectivity management, or software update management.
14. The method of claim 7, wherein each twin device further comprises attributes of a corresponding IoT device associated with another third party cloud service.
15. The method of claim 7, wherein at least one of the plurality of IoT devices is at least one of a mobile network connected device, a vehicle, or a vending machine.
16. The method of claim 7, further comprising: using the IoT support service to automatically provision a plurality of devices associated with the third party cloud service.
17. The method of claim 7, further comprising: receiving an instruction from an application in an application backend to write an attribute; adjusting attributes in the twin devices of the plurality of twin devices based on the received instruction, including adjusting at least one of: attributes in the twin devices of the plurality of twin devices associated with the third party cloud service; attributes in the twin devices of the plurality of twin devices associated with at least one of a device configuration or a device status of a corresponding IoT device.
18. A processor-readable storage medium having stored thereon processor-executable code for causing a computing device to perform operations comprising: storing associations between a plurality of IoT devices that are tenants of an IoT support service and tenants of a third party cloud service; maintaining, on the IoT support service, a plurality of twin devices corresponding to corresponding IoT devices, wherein each of the plurality of twin devices stores telemetry data received from the corresponding IoT device and further stores attribute data for indicating operations associated with the third party cloud service; and processing, by the IoT support service, a query for telemetry associated with one or more IoT devices of the plurality of IoT devices using the telemetry data and the attribute data stored by one or more corresponding twin devices of the plurality of twin devices.
19. The processor-readable storage medium of claim 18, wherein at least one twin device of the twin devices is adapted to synchronize the telemetry data with a corresponding IoT device.
20. The processor-readable storage medium of claim 18, wherein a twin device of the plurality of twin devices is further adapted to receive additional telemetry data from the third-party cloud service.
21. The processor-readable storage medium of claim 18, wherein the attribute data includes storing at least one of an expected value or an expected range of values for the received telemetry data.
Citation Information
Patent Citations
Digital twins for energy efficient asset maintenance
US20160247129A1