From Orchestration to more Collaboration

With the advent of IoT, the Internet has moved to a model where devices connect to other devices, applications or services, in order to implement new types of applications and business processes. However, most of the devices currently used as part of IoT solutions have rather limited capabilities, seeking a balance between price, performance and power consumption. As a consequence, the main part of the – computing intensive – logic that defines IoT applications is implemented and executed today on IoT cloud-based platforms, such as scriptr.io, which provide the required software and hardware infrastructure.

On another hand, Moore’s law and market studies predict that the price of connected devices will continuously drop whereas their performance will proportionally rise. In parallel, computing on the Edge – also called Fog Computing, a term coined by CISCO – fosters the availability of computing capabilities and services at the edge of the networks. Moving computing and services at the edge is expected to offload cloud platforms, prevent unnecessary bandwidth use, and free real-time applications from being subdued to network latency.

Drawing from the preceding points, it makes sense to think that in the near future, part of (but not all) the processes that are currently running on IoT cloud platforms will be moved back to “smarter” devices. This will result in a shift from a centralized, orchestration-only model, to a distributed and multi-agents model, with less centralized orchestration and more collaboration among devices, platforms and third party services, making the vision of building the IoT by assembling smart objects a plausible reality.

IoT infrastructure for collaborative IoT applications

While many collaboration scenarios can be considered, we’ll use the generic model depicted in the following figure, representing collaborations taking place among entities residing at three different levels :

  • The Cloud level, which contain centralized, shareable and/or computing intensive logic. This level exposes services that can be used by lower levels and by logic running on other cloud platforms
  • The Edge level, which contains logic and services that are consumed by groups of devices residing in the environment “supervised” by the edge node, and also by other edge platforms,
  • The device level, that contains parts of a larger application, run by devices.

iot-collaboration

Enabling cooperation based on this model requires the availability of a middleware to provide service lookup, security, communication, interoperability, orchestration and location transparency. Location transparency is complementary to service lookup and means that the details of accessing services should be kept as transparent as possible to the applications and other services that are running on a given layer.

Scriptr.io for IoT collaboration

We have implemented a prototype of the aforementioned middleware based on scriptr.io, which already provides most of the required services. We also created a version of scriptr.io that can be deployed on edge nodes, such as gateways for example. This version has the same functionalities as the cloud version, except for scalability and fail-over. We also extended the capabilities of the platform by defining and implementing “collaboration agents”, of which role is to facilitate the communication of the applications and services residing on different layers of the architecture. We identify two types of agents:

(1) “Cloud/Edge” agents that provide the following services:

  • A directory service that allows applications deployed on a cloud or edge node to find remote services or to register themselves as an available service,
  • A token-based authentication service that allows distributed applications and services to authenticate themselves against each other and acquire permissions,
  • A proxy service that handles the communication with remote agents,
  • A provisioning service for adding new nodes on top of our infrastructure and automatically deploy/update our agents on the corresponding nodes.

(2) “Device” agents that are deployed on devices and offer two services:

  • A proxy service, same as the above,
  • A provisioning service that receives application updates and deploys them on the device.

A cloud node is responsible for the provisioning of edge nodes and is used as an authentication referent and service directory to all edge nodes (and possibly standalone device nodes). Recursively, an edge node is responsible for provisioning devices and is used as an authentication referent and service directory to all its device nodes.

collaborative-nodes

Code sample

In the below we give a simple example to illustrate how to enable collaboration using our prototype. Our example uses two scriptr.io edge nodes (E1 and E2) that refer to the same scriptr.io cloud node (C).

Node E1 hosts an account in which we deployed our Nest connector and exposed its “setTemperature” method as an API. The account also contains a simple script that register the API as a service in the service directory, using the edge agent.

Expose the setTemperature API 

var clientModule = require("nest/nestClient");
var targetTemperature = request.parameters.temperature;
targetTemperature = targetTemperature ? targetTemperature : request.body.temperature;
try {
  var nest = new clientModule.NestClient(true);
  var thermostat = nest.getThermostatByName(request.parameters.room);
  return nest.setTargetTemperature(thermostat.device_id, Number(targetTemperature));
}catch(exception) {
  return exception;
}

For now, our prototype imposes saving the above script as “temp_control/api/setTemperature”.

Register the API as a service in the service directory

var agentModule = require("agent/smartAgent"); // The agent is available as a module
try {
  var agent = new agentModule.SmartAgent(); 
  return agent.registerToDirectory("temp_control"); // register the service as "temp_control"
}catch(exception) {
  return exception;
}

On Node E2, we have another account that contains an IoT application (in our case a simple script) that needs to set the temperature of a given room, using the first available “temp_control” service provider:

var agentModule = require("agent/smartAgent");
try {
  var agent = new agentModule.SmartAgent();
  var providersList = agent.listProvidersForService("temp_control"); // ask for the list of available "temp_control" services
  var dto = { // prepare the parameters of the call
    serviceName: "/api/setTemperature", // specify what API to invoke
    params: {"temperature":20, "room": "master bedroom"}, // prepare the parameters that are expected by the API
    providerName: providersList[0].name // we use the first available service provider on the list
  };
    
  return agent.callService(dto); // invoke the remote API using the agent's callService method. 
}catch(exception) {
  return exception;
}