An Internet of things (IoT) controller may execute a first IoT application, associated with operating an IoT device, and a second IoT application associated with operating the IoT device. The IoT controller may load an IoT application program interface (API) associated with the first IoT application and the second IoT application, and may identify a first set of functions including a first function, associated with the first IoT application, and a second function associated with the second IoT application. The IoT controller may translate, based on the IoT API, the first set of functions to a second set of functions including a third function, associated with the first IoT application, and a fourth function associated with the second IoT application. The IoT controller may cause the IoT device to operate, based on the second set of functions, during the execution of the first IoT application and the second IoT application.

BACKGROUND

The Internet of things (IoT) refers to the network of physical objects with Internet connectivity, and the communication between such objects and other Internet-enabled devices and systems. The IoT extends Internet connectivity beyond traditional devices (e.g., desktop computers, laptop computers, smart phones etc.) to a range of devices and everyday things that may utilize embedded technology to communicate and interact with an external environment via the Internet.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

An IoT device may operate based on one or more IoT applications installed on the IoT device. For example, a robotics device may operate based on a movement control application, a voice communication application, a dancing application, or the like. As another example, an unmanned aerial vehicle (UAV or “drone”) may operate based on an auto-pilot application, a video processing application, an object analysis application, or the like. Traditionally, a platform (e.g., including hardware and/or software) for the IoT device may be selected and/or designed based on such IoT applications (e.g., such that the platform is selected and/or designed specifically for the IoT device). For example, with respect to a controller in a drone, sensing components, motor control components, or the like, may be selected and/or designed specifically for the drone (i.e., the components may not be used in another type of IoT device).

Additionally, under the traditional design approach, an IoT application may be developed using a hardware dependent programming language, such as C programming language. As such, an IoT application developer may be unable to develop the IoT application using a high-level programming language, such as Java programming language, Python programming language, or the like. As such, the IoT application developer may need specific knowledge of hardware included in the IoT device.

Implementations described herein provide a platform that uses a virtual IoT device API that allows a generic IoT controller to be software-defined for use in different IoT applications and/or different IoT devices. Moreover, in some implementations, the platform may allow an IoT application developer, associated with an IoT application, to develop the IoT application using a high-level programming language (e.g., based on the virtual IoT device API).

FIGS. 1A-1Care diagrams of an overview of an example implementation100described herein. For the purposes of example implementation100, assume that an IoT device developer develops an IoT device that includes a generic IoT controller. Further, assume that the IoT device developer has access to driver API information associated with the generic IoT controller (e.g., provided by a designer of the generic IoT controller). As shown inFIG. 1A, and by reference number105, the IoT device developer may create a virtual IoT device API based on the driver API information associated with the generic IoT controller. As shown by reference number110, the IoT device developer may provide (e.g., via an IoT device developer device) the virtual IoT device API to the generic IoT controller. As shown by reference number115, the generic IoT controller may receive and store the virtual IoT device API (e.g., such that the virtual IoT device API may be loaded at a later time). Notably, in this example, the generic IoT controller may be capable of storing one or more virtual IoT device APIs for multiple IoT devices (e.g., a robotics device, a sensing device, a drone, etc.). As such, the generic IoT controller may be included in different IoT devices, and may be capable of executing applications for the different IoT devices (e.g., based on the corresponding virtual IoT device APIs).

For the purposes ofFIG. 1B, assume that an IoT application developer device, associated with an IoT application developer, stores or has access to the virtual IoT device API associated with the IoT device. As shown inFIG. 1B, and by reference number120, the IoT application developer may develop, based on the virtual IoT device API, the IoT application in a high-level programming language (e.g., Java, Python, etc.). As shown by reference number125, the application developer device may provide the IoT application to the generic IoT controller. As shown by reference number130, the generic IoT controller may store the IoT application (e.g., such that the IoT application may be executed at a later time).

For the purposes ofFIG. 1C, assume that a user device is capable of communicating with the generic IoT controller (e.g., such that the user device may control, operate, manipulate, etc., the IoT device via the IoT application). As shown by reference number135, the user device may provide (e.g., based on user input) an indication to execute the IoT application stored by the generic IoT controller. As shown by reference number140, the generic IoT controller may execute the IoT application and may load the virtual IoT device API for the IoT device.

As shown by reference number145, the user device may provide (e.g., based on user input) a command associated with the IoT application (e.g., for controlling, operating, manipulating, etc., the IoT device). As shown by reference number150, the generic IoT controller may identify a first function corresponding to the command. Here, the first function may be described in the high-level programming language in which the IoT application was created. As shown by reference number155, the generic IoT controller may translate the first function to a second function (e.g., a function in a language that may be used to control hardware of the IoT device) based on the virtual IoT device API. As shown by reference number160, the generic IoT controller may then cause the IoT device to operate based on the second function.

In this way, a virtual IoT device API may allow a generic IoT controller to be software-defined for use in different IoT applications and/or with different IoT devices. Moreover, in some implementations, an IoT application developer, associated with an IoT application, may develop the IoT application using a high-level programming language and based on the virtual IoT device API.

FIG. 2is a diagram of an example environment200in which systems and/or methods, described herein, may be implemented. As shown inFIG. 2, environment200may include an IoT device210, an IoT controller220, a user device230, an IoT app developer device240, an IoT device developer device250, an IoT app store device260, and a network270. Devices of environment200may interconnect via wired connections, wireless connections, or a combination of wired and wireless connections.

IoT device210may include a device that is capable of receiving, processing, generating, determining, and/or providing information via the IoT. For example, IoT device210may include a computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a handheld computer, a camera, an audio recorder, a camcorder, etc.), an appliance (e.g., a refrigerator, a microwave, a stove, etc.), a sensing device (e.g., a temperature sensor, a pressure sensor, an accelerometer, etc.), a processing device, a metering device, a machine-to-machine (M2M) device, a robotics device, a drone, a medical device, an automobile, a light bulb, and/or another type of device. In other words, IoT device210may be any “thing” in the IoT. In some implementations, IoT device210may include IoT controller220.

IoT controller220may include a device capable of controlling, operating, manipulating, communicating with, or the like, IoT device210. For example, IoT controller220may include a computing device (e.g., a single-board computer, a system on a chip, an integrated circuit, etc.) that includes a processing device (e.g., a central processing unit (CPU), a microprocessor, etc.), a memory component, an input/output (I/O) component, and/or one or more other components. In some implementations, IoT controller220may be a generic controller (i.e., IoT controller220may not be designed for a particular IoT device and/or a particular IoT application). Additionally, or alternatively, IoT controller220may be capable of sending and/or receiving information via network270. For example, IoT controller220may include a modem, such as a 3G modem, a 4G modem, or the like. In some implementations, IoT controller220may be capable of storing and/or loading one or more virtual IoT device APIs and/or storing and/or executing one or more IoT applications.

User device230may include one or more devices capable of receiving, generating, storing, processing, and/or providing information related to an application associated with IoT device210. For example, user device230may include a communication and/or computing device, such as a mobile phone (e.g., a smart phone, a radiotelephone, etc.), a laptop computer, a tablet computer, a handheld computer, a gaming device, a wearable communication device (e.g., a smart wristwatch, a pair of smart eyeglasses, etc.), or a similar type of device. In some implementations, user device230may allow a user to control, operate, manipulate, or the like, IoT device210via IoT controller220.

IoT app developer device240may include a device associated with an application developer that develops, creates, generates, produces, and/or designs an application associated with IoT device210. For example, IoT app developer device240may include a server device or a collection of server devices. In some implementations, IoT app developer device240may provide and/or send the application to another device, such as app store device260(e.g., such that the application may be accessed, received, stored, executed, etc., by another device of environment200).

IoT device developer device250may include a device associated with an IoT device developer that develops, creates, generates, produces, and/or designs IoT device210and/or one or more components of IoT device210. For example, Tot device developer device250may include a server device or a collection of server devices. In some implementations, Tot device developer device250may provide and/or send information associated with IoT device210(e.g., a virtual IoT device API) that allows one or more applications to be executed by IoT device210and/or IoT controller220.

IoT app store device260may include a device associated with distributing, providing, and/or selling IoT device210, IoT controller220, and/or one or more IoT applications associated with IoT device210. For example, IoT app store device260may include a server device or a collection of server devices. In some implementations, IoT app store device260may allow a user to (e.g., via user device230) purchase, download, receive, or the like, IoT device210, IoT controller220, and/or the one or more IoT applications.

FIG. 3is a diagram of example components of a device300. Device300may correspond to IoT device210, IoT controller220, user device230, IoT app developer device240, IoT device developer device250, and/or app store device260. In some implementations, IoT device210, IoT controller220, user device230, IoT app developer device240, IoT device developer device250, and/or app store device260may include one or more devices300and/or one or more components of device300. As shown inFIG. 3, device300may include a bus310, a processor320, a memory330, a storage component340, an input component350, an output component360, and a communication interface370.

FIG. 4is a diagram of example functional elements of device400that corresponds to one or more devices ofFIG. 2. In some implementations, device400may correspond to IoT controller220and/or IoT device210. In other implementations, one or more of the example functional elements of device400may be implemented by another device or a collection of devices including or excluding IoT device210and/or IoT controller220, such as by one or more other devices of environment200. As shown inFIG. 4, device400may include an IoT application405, an application resource manager410, a virtual IoT device API415, IoT API manager418, an IoT protocol420, an operating system (OS)425, a communications (COM) port driver430, a driver API435, and an IoT control interface440. In some implementations, functional elements405-440may be implemented using one or more devices300and/or one or more components of device300.

IoT application405may perform operations associated with an IoT application used to control, manage, manipulate, operate, and/or communicate with IoT device210. In some implementations, IoT application405may be developed, created, generated, produced, and/or designed by an IoT application developer associated with IoT app developer device240. In some implementations, IoT application405may be written using a high-level programming language, such as Java programming language, Python programming language, or the like. In some implementations, IoT application405may include a manifest that identifies one or more other functional elements needed to execute IoT application405. For example, IoT application405may include a manifest that includes information (e.g., a name, a version number, etc.) that identifies one or more virtual IoT device APIs415, one or more driver APIs435, or the like, that may be needed to execute IoT application405. In some implementations, IoT application405may receive and/or provide information from and/or to user device230and/or one or more other functional elements of device400.

In some implementations, device400may include multiple IoT applications405. Additionally, or alternatively, device400may receive and store an additional IoT application405(e.g., device400may receive and store a first IoT application405on a first day, a second IoT application405on a thirtieth day, etc.). In some implementations, device400may maintain a collaboration list associated with sharing of resources by the multiple IoT applications405. For example, device400may maintain a collaboration list that describes how a first IoT application405is to (e.g., simultaneously, concurrently, etc.) work in conjunction with a second IoT application405in order to share resources (e.g., one or more virtual IoT device APIs415, one or more driver APIs435, one or more hardware components of IoT device210, etc.) needed to execute the first IoT application405and the second IoT application405.

Application resource manager410may perform operations associated with managing, installing, uninstalling, updating, and/or licensing IoT application405. In some implementations, application resource manager410may be capable of protecting IoT application405(e.g., from software piracy activities). Additionally, or alternatively, application resource manager410may be capable of managing resources (e.g., one or more virtual IoT device APIs415, one or more driver APIs435, one or more hardware components of IoT device210, etc.) to be concurrently used by a first IoT application405and a second IoT application405(e.g., when the first IoT application405and the second IoT application405are being executed at the same time) based on a collaboration list associated with one or more IoT applications405.

Virtual IoT device API415may perform operations associated with translating a first function to a second function (e.g., from a high-level programming language to a hardware dependent programming language) such that IoT device210may be controlled, managed, manipulated, operated, and/or communicated via IoT application405. For example, device400may receive an indication (e.g., provided by user device230) to execute IoT application405, and device400may execute IoT application405and load virtual IoT device API415. Here, IoT application405may receive a command and may identify a first function corresponding to the command. Virtual IoT device API415may translate the first function (e.g., from a high-level programming language) to a second function (e.g., in another language, such as C programming language) such that IoT device210may operate in accordance with the second function. In this way, virtual IoT device API415may isolate IoT application405from directly controlling one or more hardware components of IoT device210.

In some implementations, virtual IoT device API415may be accessed by an IoT application developer of IoT application405, and may allow the IoT application developer to treat IoT device210as a virtual IoT device (e.g., since the application developer need not have particular knowledge of hardware components of IoT device210in order to develop IoT application405in the high-level programming language). In some implementations, virtual IoT device API415may be generated, created, developed, and/or provided by an IoT device developer associated with IoT device developer device250. In some implementations, device400may include one or more virtual IoT device APIs415(e.g., where each of the one or more virtual IoT device APIs415may be associated with one or more IoT applications405and/or one or more driver APIs435).

IoT API manager418may perform operations associated with managing, obtaining, retrieving, and/or storing virtual IoT device API415and/or driver API435that may be needed to execute IoT application405. For example, device400may receive IoT application405including a manifest includes information (e.g., a name, a version number) that identifies one or more virtual IoT device APIs415and/or one or more driver APIs435that may be needed to execute IoT application405. Here, IoT API manager418may determine whether device400stores the one or more virtual IoT device APIs415and/or the one or more driver APIs435and, if not, IoT API manager418may retrieve (e.g., from an online storage device, such as IoT app store device260) and store the one or more virtual IoT device APIs415and/or the one or more driver APIs435(e.g., such that the one or more virtual IoT device APIs415and/or the one or more driver APIs435may be loaded when IoT application405is executed at a later time).

IoT protocol420may perform operations associated with standardizing information formats and/or control formats between IoT application405and one or more other functional elements of device400. In some implementations, IoT protocol420may use an open source protocol, such as constrained application protocol (CoAP), message queue telemetry transport (MQTT) protocol, lightweight M2M (LWM2M) protocol, or the like.

OS425may perform operations associated with managing resources (e.g., hardware resources, software resources, etc.) of device400and/or providing services for one or more functional elements of device400. For example, OS425may include an operating system, such as Android, Red Hat, Ubuntu, iOS, or the like.

COM port driver430may perform operations associated with managing and/or controlling communications ports of device400. For example, COM port driver430may perform operations associated with managing and/or controlling communication via one or more ports, such as an Ethernet port, a RS-485 port, a RS-232 port, a universal asynchronous receiver/transmitter (UART) port, a universal serial bus (USB) port, a port associated with communicating via a cellular network (e.g., a 3G network, an LTE network, etc.).

Driver API435may perform operations associated with managing and/or controlling communication with one or more hardware components of device400. For example, driver API435may perform operations associated with setting, managing, and/or controlling analog I/O pins of device400, digital I/O pins of device400, or the like. In some implementations, driver API435may communicate with other functional elements of device400, such as virtual IoT device API415. In some implementations, device400may include one or more driver APIs435(e.g., where each of the one or more driver APIs435may be associated with one or more IoT applications405and/or one or more virtual IoT device APIs415).

IoT control interface440may perform operations associated with a hardware interface across which one or more functional elements of device400exchange information, such as virtual IoT device API415and driver API435. In some implementations, IoT control interface440may perform operations associated with mapping a (e.g., translated) second function, associated with an IoT application405and translated by virtual IoT device API415, such that driver API435may cause IoT device210to operate based on the translated function.

The number and arrangement of functional elements shown inFIG. 4are provided as an example. In practice, device400may include additional functional elements, fewer functional elements, different functional elements, and/or differently arranged functional elements than those shown inFIG. 4. Additionally, or alternatively, a set of functional elements (e.g., one or more functional elements) of device400may perform one or more functions described as being performed by another set of functional elements of device400.

FIG. 5is a flow chart of an example process500for receiving and storing a virtual IoT device API associated with an IoT device. In some implementations, one or more process blocks ofFIG. 5may be performed by IoT controller220. In some implementations, one or more process blocks ofFIG. 5may be performed by another device or a set of devices separate from or including IoT controller220, such as one or more other components of IoT device210.

As shown inFIG. 5, process500may include receiving a virtual IoT device API associated with an IoT device (block510). For example, IoT controller220may receive virtual IoT device API415associated with IoT device210. In some implementations, IoT controller220may receive virtual IoT device API415when another device provides virtual IoT device API415, such as IoT device developer device250or IoT app store device260. Additionally, or alternatively, IoT controller220may receive virtual IoT device API415during manufacture and/or configuration of IoT device210(e.g., virtual IoT device API415may be provided to IoT controller220when IoT device210is manufactured and/or configured by the IoT device developer). Additionally, or alternatively, IoT controller220may receive virtual IoT device API415at another time (e.g., IoT controller220may download virtual IoT device API415at a later time).

In some implementations, virtual IoT device API415may be created by the IoT device developer in order to allow IoT device210to operate based on one or more IoT applications via virtual IoT device API415. For example, the IoT device developer may obtain (e.g., from an entity associated with designing IoT controller220) information associated with driver API435(e.g., a driver manual that identifies available functions, parameters, pins, ports, serial peripheral interfaces, etc). Here, the IoT device developer may create virtual IoT device API415based on the information associated with driver API435. For example, with respect to a robotics device, the IoT device developer may create virtual IoT device API415such that a movement control is associated with a particular port, and that a first pin (e.g., pin 1) corresponds to a left arm of the robotics device, a second pin (e.g., pin 2) corresponds to a right arm of the robotics device, a first parameter value (e.g., 1) corresponds to a moving an arm in an upward direction, a second parameter value (e.g., 0) corresponds to moving an arm in a downward direction, or the like. Here, virtual IoT device API415may be used to translate a first function, associated with IoT application405, to a second function, in order to cause IoT device210to operate. Continuing with the above example, virtual IoT device API415may be created such that a first function (e.g., written in a high-level programming language) indicating that the left arm of the robotics device is to move in the upward direction translates to a second function (e.g., dio (pin 1, 1)) that may be carried out by driver API435.

In some implementations, virtual IoT device API415may include information that allows multiple IoT applications to be independently developed for IoT device210. For example, with respect to a robotics device, virtual IoT device API415may include information associated with a first port that is to be used for movement control, a second port that is to be used for voice communication, and so on. As such, independent IoT applications developers may develop IoT applications for IoT device210(e.g., since virtual IoT device API415will be identical for each IoT application405) independent of one another. For example, an IoT application developer may develop a movement control application concurrently with another (e.g., independent) IoT application developer developing a voice communication application.

As further shown inFIG. 5, process500may include storing the virtual IoT device API (block520). For example, IoT controller220may store virtual IoT device API415. In some implementations, IoT controller220may store virtual IoT device API415when IoT controller220receives virtual IoT device API415(e.g., after IoT controller220receives virtual IoT device API415). Additionally, or alternatively, IoT controller220may store virtual IoT device API415based on information, indicating that IoT controller220is to store virtual IoT device API415, received from another device, such as user device230. In some implementations, IoT controller220may store virtual IoT device API415in a memory location (e.g., of a flash memory, a RAM, a ROM, a cache, a hard disk, etc.) of IoT controller220.

In some implementations, IoT controller220may store information associated with virtual IoT device API415such that a previous virtual IoT device API415(e.g., virtual IoT device API415received at an earlier time) is overwritten and/or deleted. Additionally, or alternatively, IoT controller220may store virtual IoT device API415such that IoT controller220may load virtual IoT device API415at a later time. In some implementations, IoT controller220may store multiple virtual IoT device APIs415associated with different IoT devices210and/or different IoT applications405.

FIG. 6is a diagram of an example implementation600relating to example process500shown inFIG. 5. For the purposes of example implementation600, assume that a first IoT device developer (e.g., Bot X developer) has created a first virtual IoT device API415(e.g., Bot X API) for a first IoT device210(e.g., Bot X) based on driver information (e.g., associated with driver API435) for IoT controller220. Similarly, assume that a second IoT device developer (e.g., Drone 2000 developer) has created a second virtual IoT device API415(e.g., Drone 2000 API) for a second IoT device210(e.g., Drone 2000) based on the driver information for IoT controller220. In other words, assume that the Bot X developer and the Drone 2000 developer have created the Bot X API and the Drone 2000 API, respectively, based on the same driver information associated with IoT controller220.

As shown in the upper portion ofFIG. 6, and by reference number605, a Bot X developer device may provide, to a first IoT controller220(e.g., IoT controller1), the Bot X API. As shown, the Bot X API may include information (e.g., that identifies functions, parameters, pins, ports, serial peripheral interfaces, etc.) associated with translating movement control functions, vision control functions, and voice communication functions for Bot X. As shown by reference number610, IoT controller1may store the Bot X API. As shown by reference number615, IoT controller1may be installed in Bot X.

Similarly, as shown in the lower portion ofFIG. 6, and by reference number620, a Drone 2000 developer device may provide, to a second IoT controller220(e.g., IoT controller2) the Drone 2000 API. As shown, the Drone 2000 API may include information associated with translating speed sensor functions, pilot control functions, and location identification functions for Drone 2000. As shown by reference number625, IoT controller2may store the Drone 2000 API. As shown by reference number630, IoT controller2may be installed in Drone 2000.

As noted inFIG. 6, IoT controller1may be the same as IoT controller2. In other words, IoT controller1and IoT controller2may be generic IoT controllers220that may operate their respective IoT devices210based on loading corresponding virtual IoT device APIs415(i.e., IoT controller220may be software-defined). As an example, whileFIG. 6describes IoT controller1as being used to carry out functions associated with Bot X applications, IoT controller1may also be capable of receiving the Drone 2000 API, and being installed in Drone 2000 (e.g., such that IoT controller1may carry out functions, associated with Drone 2000 applications, based on the Drone 2000 API). In this way, virtual IoT device APIs415may allow a generic IoT controller220to be software-defined for use in different IoT applications405and/or in different IoT devices210.

As indicated above,FIG. 6is provided merely as an example. Other examples are possible and may differ from what was described with regard toFIG. 6.

FIG. 7is a flow chart of an example process700for causing an IoT device to operate based on translating a function, associated with an IoT application for the IoT device, using a virtual IoT device API. In some implementations, one or more process blocks ofFIG. 7may be performed by IoT controller220. In some implementations, one or more process blocks ofFIG. 7may be performed by another device or a set of devices separate from or including IoT controller220, such as one or more other components of IoT device210.

As shown inFIG. 7, process700may include executing an IoT application associated with an IoT device (block710). For example, IoT controller220may execute IoT application405associated with IoT device210. In some implementations, IoT controller220may execute IoT application405when IoT controller220receives an indication to execute IoT application405.

In some implementations, IoT controller220may execute IoT application405based on information provided by another device, such as user device230. For example, user device230may provide (e.g., based on user input) an indication that IoT controller220is to execute IoT application405, and IoT controller220may execute IoT application405accordingly. As an example, user device230may provide, to IoT controller220included in a web cam device, an indication that IoT controller220is to execute a video capture application associated with the web cam device. Here, IoT controller220may receive the indication, and may execute the video capture application accordingly.

In some implementations, IoT controller220may execute IoT application405based on information stored by IoT controller220. For example, IoT controller220may receive (e.g., from user device230, from app store device260, etc.) information associated with IoT application405, and may store the information associated with IoT application405. Here, IoT controller220may execute IoT application405based on the stored information. In some implementations, IoT controller220may store multiple IoT applications405. For example, IoT controller220may receive and store a first IoT application405at a first time, and may receive and store a second IoT application405at a second time (e.g., a later time). In some implementations, IoT controller220may execute one or more of the multiple IoT applications405(i.e., IoT controller220may concurrently execute the one or more IoT applications405).

As further shown inFIG. 7, process700may include loading a virtual IoT device API associated with the IoT device (block720). For example, IoT controller220may load virtual IoT device API415associated with IoT device210. In some implementations, IoT controller220may load virtual IoT device API415when (e.g., before, after, concurrently with) executing IoT application405. Additionally, or alternatively, IoT controller220may load virtual IoT device API415when IoT controller220receives an indication to load virtual IoT device API415.

In some implementations, IoT controller220may load virtual IoT device API415based on information stored by IoT controller220. For example, IoT controller220may receive and store virtual IoT device API415, as described above, and may load virtual IoT device API415from a memory storage location associated with storing virtual IoT device API415.

In some implementations, IoT controller220may automatically load virtual IoT device API415when IoT controller220receives an indication to execute any IoT application405associated with IoT device210(e.g., such that IoT controller220loads virtual IoT device API415for each IoT application405). In some implementations, IoT controller220may load multiple virtual IoT device APIs415. For example, IoT controller220may load multiple virtual IoT device APIs415when a single IoT application405is configured to use multiple virtual IoT device APIs415. As another example, IoT controller220may load multiple virtual IoT device APIs415when IoT controller220executes multiple IoT applications405(e.g., where each IoT application405is configured to use one or more of the multiple virtual IoT device APIs415).

As further shown inFIG. 7, process700may include receiving a command associated with the IoT application (block730). For example, IoT controller220may receive a command associated with IoT application405. In some implementations, IoT controller220may receive the command after IoT controller220executes IoT application405. Additionally, or alternatively, IoT controller220may receive the command when another device provides the command, such as when user device230provides the command.

A command may include information, associated with IoT application405, that indicates that IoT controller220is to control, manage, manipulate, operate, and/or communicate with IoT device210in a manner corresponding to the command. For example, the command may be associated with controlling movement of a robotics device, performing object analysis using a camera of a drone, recording a measurement (e.g., a speed, a temperature, a pressure) detected by a sensor, and so on.

In some implementations, IoT controller220may receive the command based on information provided by user device230. For example, user device230may provide (e.g., based on a user indication) a command indicating that IoT device210is to operate in a particular manner. Here, IoT controller220may receive the command via network270. As a particular example, a user may indicate (e.g., by selecting a button on a user interface of user device230), that a robotics device is to move a left leg forward. Here, user device230may provide (e.g., via network270) a command to IoT controller220included in the robotics device. In this example, IoT controller220(e.g., IoT application405) may identify a function, corresponding to the command, as described below.

In some implementations, IoT controller220may receive multiple commands associated with IoT application405(e.g., concurrently, in a series, in a sequence, etc.). Additionally, or alternatively, IoT controller220may receive (e.g., concurrently, in a series, in a sequence, etc.) multiple commands associated with multiple IoT applications405(e.g., when IoT controller220is executing multiple IoT applications405at the same time).

As further shown inFIG. 7, process700may include identifying a first function corresponding to the command (block740). For example, IoT controller220may identify a first function corresponding to the command. In some implementations, IoT controller220may identify the first function after IoT controller220receives the command. Additionally, or alternatively, IoT controller220may identify the first function at another time (e.g., when IoT controller220is configured to automatically identify the first function).

A first function, as used herein, may include information, in the form of high-level programming code, that identifies the manner in which IoT controller220is to control, manage, manipulate, operate, and/or communicate with IoT device210. Continuing with the above example, IoT controller220may receive the command associated with moving the left leg of the robotics device forward, and IoT controller220(e.g., IoT application405) may identify a first function corresponding to the command (e.g., move (leg, left, forward)) for virtual IoT device API415(e.g., such that virtual IoT device API415may translate the first function to a second function, as described below). As shown in this example, in some implementations, IoT controller220may identify the function, corresponding to the command based on information associated with IoT application405. In some implementations, IoT controller220may identify multiple first functions associated with one or more commands. For example, IoT controller220may identify a set of first functions corresponding to a set of commands associated with IoT application405being executed by IoT controller220. As another example, IoT controller220may identify a set of first functions corresponding to a set of commands associated with multiple IoT applications405being executed by IoT controller220.

As further shown inFIG. 7, process700may include translating the first function to a second function based on the virtual IoT device API (block750). For example, IoT controller220may translate the first function to a second function based on virtual IoT device API415. In some implementations, IoT controller220may translate the first function after IoT controller220identifies the first function for virtual IoT device API415.

A second function, as used herein, may include information, in the form of a programming code that may be used to control hardware, that identifies the manner in which IoT controller220is to control, manage, manipulate, operate, and/or communicate with IoT device210.

In some implementations, IoT controller220(e.g., virtual IoT device API415) may translate the first function based on information associated with virtual IoT device API415. Continuing with the above example, IoT application405may identify the first function (e.g., move (left, leg, forward)) for virtual IoT device API415, and virtual IoT device API415may translate the first function to a second function based on information associated with virtual IoT device API415. Here, for example, virtual IoT device API415may translate the first function to a second function (e.g., dio (pin 2, 0)) such that the second function may be identified for driver API435in order to control the robotics device. In this way, IoT controller220(e.g., virtual IoT device API415) may isolate IoT application405from directly controlling IoT device210. As such, IoT application405may be developed in a high-level program language (e.g., rather than a hardware dependent programming language).

In some implementations, IoT controller220may translate multiple first functions to multiple second functions. For example, IoT controller220may translate a set of first functions, associated with multiple IoT applications405being concurrently executed by IoT controller220, to a set of second functions associated with controlling IoT device210.

As further shown inFIG. 7, process700may include causing the IoT device to operate based on the second function (block760). For example, IoT controller220may cause IoT device210to operate based on the second function. In some implementations, IoT controller220may cause IoT device210to operate after IoT controller220translates the first function to the second function.

In some implementations, IoT controller220(e.g., virtual IoT device API415) may cause IoT device210to operate, based on the second function, by identifying the second function for driver API435. Continuing with the above example, virtual IoT device API415may identify the second function (e.g., dio (pin 2, 0)) on driver API435, and driver API435may carry out the function (e.g., by setting a second pin to a particular value) such that the left leg of the robotics device moves forward in accordance with the command.

In some implementations, IoT controller220may cause IoT device210to operate based on multiple second functions. For example, IoT controller220may cause IoT device210to operate based on a set of second functions, where each second function, of the set of second functions, may be associated with a different IoT application405of multiple IoT applications405being concurrently executed by IoT controller220. In some implementations, driver API435may carry out the set of second functions based on rules information, stored or accessible by driver API435, associated with resolving a conflict between two or more second functions of the set of second functions (e.g., when the two or more second functions use the same driver API435). Additional details regarding the use of rules information are described below.

AlthoughFIG. 7shows example blocks of process700, in some implementations, process700may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted inFIG. 7. Additionally, or alternatively, two or more of the blocks of process700may be performed in parallel.

FIGS. 8A and 8Bare diagrams of an example implementation800relating to example process700shown inFIG. 7. For the purposes of example implementation800, assume that IoT controller220(e.g., IoT controller1) is included in IoT device210(e.g., Bot X), and that IoT controller1stores or has access to an IoT application405(e.g., Bot X movement control application) associated with Bot X, virtual IoT device API415(e.g., Bot X API) associated with Bot X, and driver API435(e.g., IoT controller1driver API) associated with IoT controller1. Further, assume that user device230(e.g., UD1) is configured to control Bot X via the Bot X movement control application.

As shown inFIG. 8A, and by reference number805, IoT controller1may receive, from UD1(e.g., based on user input), an indication to execute the Bot X movement control application. As shown by reference number810, IoT controller1may execute the Bot X movement control application. As shown by reference number815, IoT controller1may also load (e.g., from a memory location of IoT controller1), the Bot X API. As shown by reference number820, IoT controller1may also load the IoT controller1API (e.g., from a memory location of IoT controller1).

As shown inFIG. 8B, and by reference number825, UD1may provide (e.g., based on user input and via the Bot X movement control application) a command to move a left arm of Bot X in an upward direction. As shown by reference number830, IoT controller1may receive the command, and the Bot X movement control application (e.g., being executed by IoT controller1) may identify a first function (e.g., move (arm, left, up)), corresponding to the command, for the Bot X API. As shown by reference number835, the Bot X may translate, based on information associated with the Bot X API, the first function to a second function (e.g., move (arm, left, up)=dio (pin 3, 1)), and may identify the second function for the IoT controller1driver. As shown by reference number840, the IoT controller1driver may, based on the second function, manipulate Bot X accordingly (e.g., by setting pin 3 to a value of 1). As shown by reference number845, the left arm of Bot X may move in the upward direction based on the manipulation by the IoT controller1driver.

As indicated above,FIGS. 8A and 8Bare provided merely as an example. Other examples are possible and may differ from what was described with regard toFIGS. 8A and 8B.

FIG. 9is a diagram of an example900showing a manner in which multiple IoT applications, multiple virtual IoT device APIs, and/or multiple driver APIs may interact in accordance with implementations described herein. For the purposes ofFIG. 9, assume that IoT controller220included in device210(e.g., Bot X) stores three IoT applications405(e.g., a movement control application, a dancing application, and a verbal conversation application), five virtual IoT device APIs415(e.g., a vision API, a motion API, an emotion API, a music API, and a verbal communication API), and seven driver APIs435(e.g., a camera driver, an arm motor driver, a balance sensor driver, a leg motor driver, a speaker driver, a microphone driver, and a color light emitting diode (LED) driver).

As shown inFIG. 9, a particular IoT application405may use one or more virtual IoT device APIs415. For example, the movement control application may use the vision API and the motion API. As another example, the dancing application may use the motion API, the emotion API, and the music API. As an additional example, the verbal conversation application may use the motion API and the verbal communication API. As such, each virtual IoT device API415may be used and/or shared by one or more (e.g., independently developed) IoT applications405(e.g., where concurrent usage of each virtual IoT device API415may be managed by application resource manager410in accordance with a collaboration list maintained by IoT controller220).

As further shown inFIG. 9, a particular virtual IoT device API415may use one or more driver APIs435. For example, the vision API may use the camera driver. As another example, the motion API may use the arm motor driver, the balance sensor driver, and the leg motor driver. As yet another example, the emotion API may use the arm motor driver, the speaker driver, and the color LED driver. As still another example, the music API may use the speaker driver. As a final example, the verbal communication API may use the speaker driver and the microphone driver. As such, each driver API435may be used and/or shared by one or more virtual IoT device APIs415(e.g., where concurrent usage of each driver API435may be managed by application resource manager410in accordance with a collaboration list maintained by IoT controller220).

In some implementations, each driver API435may store or have access to rules information associated with operating IoT device210. The rules information may include information associated with resolving a conflict between second functions to be carried out driver435. For example, the rules information may include information associated with resolving a conflict based on a preferred scenario associated with IoT device210(e.g., a hardware limitation, etc.), a hardware status associated with IoT device210(e.g. a robot's leg position, etc.), or another type of information. In some implementations, driver API435may resolve a conflict, associated with two or more second functions, based on the rules information. For example, driver API435may receive a first second function (e.g., function A) via a first virtual IoT device API415, and may receive (e.g., simultaneously, in a series, in a sequence, etc.) a second function (e.g., function B) via a second virtual IoT device API415(e.g., before driver API435carries out function A). Here, driver API435may determine, based on the rules information, if driver API435is to carry out function A before carrying out function B, or if driver API435is to carry out function B before carrying out function A, and may act accordingly. In other words, driver API435may use the rules information to determine a priority associated with carrying out multiple functions associated with multiple virtual IoT device APIs415.

In some implementations, IoT controller220may store multiple versions of virtual IoT device API415such that each of the one or more versions may be used in association with IoT application405. As such, two different IoT applications405may call a same virtual IoT device API415, but each of the two different IoT applications405may use a different version of the same virtual IoT device API415. Additionally, or alternatively, IoT controller220may store multiple versions of driver API435such that each of the one or more versions may be used in association with virtual IoT device API415. As such, two different virtual IoT device APIs415may call a same driver API435, but each of the two different virtual IoT device APIs415may use a different version of the same driver API435.

In this way, one or more IoT applications405, one or more virtual IoT device APIs415, and/or one or more driver APIs435may be mixed and matched for (e.g., concurrent) use by IoT controller220to control, manage, manipulate, operate, and/or communicate with IoT device210.

FIG. 10is a diagram of an example IoT app store environment1000associated with implementations described herein. Environment1000shows an example of a manner in which implementations described herein may enable an IoT app store based on using a software-defined (e.g., generic) IoT controller220. For the purposes ofFIG. 10, assume that a group of application developers (e.g., app developer1through app developer5), a group of users (e.g., user1and user2), and a group of vendors (e.g., vendor1, vendor2, and vendor3) have access to an IoT app store (e.g., hosted by IoT app store device260).

As shown, assume that vendor1sells a first IoT device (e.g., Bot X and a Bot X API created for a generic IoT controller) via the IoT app store, vendor2sells a second IoT device (e.g., Drone 2000 and a Drone 2000 API created for the generic IoT controller) via the IoT app store, and vendor3sells the generic IoT controller via the IoT app store.

As further shown, each application developer may independently develop an application for an IoT device. For example, app developer1may purchase Bot X (e.g., including the Bot X API) and a generic IoT controller, and may develop a Bot X movement control application using Java programming language. As another example, app developer2may purchase Bot X (e.g., including the Bot X API) and a generic IoT controller, and may develop a Bot X voice communication application using Python programming language. As still another example, app developer3may purchase Bot X (e.g., including the Bot X API) and a generic IoT controller, and may develop a Bot X vision control application using Java programming language. As yet another example, app developer4may purchase Drone 2000 (e.g., including the Drone 2000 API) and a generic IoT controller, and may develop a Drone 2000 auto pilot application using Java programming language. As a final example, app developer5may purchase Drone 2000 (e.g., including the Drone 2000 API) and a generic IoT controller, and may develop a Drone 2000 video processing application using Python programming language.

As shown, each user may then purchase an IoT device, a generic IoT controller, and one or more applications associated with the purchased IoT device. For example, user1may purchase Bot X, a generic IoT controller, and the Bot X applications (e.g., the movement control application, the voice communication application, and/or the vision control application). As another example, user2may purchase Drone 2000, a generic IoT controller, and the Drone 2000 applications (e.g., the auto pilot application and/or the video processing application). Here, using the generic IoT controller may enable the IoT app store to as described below.

As indicated above,FIG. 10is provided merely as an example. Other examples are possible and may differ from what was described with regard toFIG. 10.

Implementations described herein provide a platform that uses a virtual IoT device API that allows a generic IoT controller to be software-defined for use in different IoT applications and/or different IoT devices. Moreover, in some implementations, the platform may allow an IoT application developer, associated with an IoT application, to develop the IoT application using a high-level programming language (e.g., based on the virtual IoT device API).

In some implementations, the software-defined (e.g., re-configurable by software) generic IoT controller may be described as a multipurpose IoT controller. For example, multiple IoT applications may be stored by the generic IoT controller in the IoT device, and the generic IoT controller may concurrently execute two or more of the multiple IoT applications (e.g., with different purposes). Additionally, or alternatively, the software-defined generic IoT controller may be described as a universal IoT controller. For example, in an implementation associated with a camera application, the generic IoT controller may act as a 4G enabled webcam. As another example, in an implementation associated with a credit card reader application and a vending control application, the generic IoT controller may act as an advanced vending machine controller.