PROCEED Engine Network Abstraction

Physical Communication Abstraction

Requirements

• to connect to/from all kinds of IoT systems, it should be possible to communicate in different physical networks, e.g. Ethernet, WiFi, Bluetooth, NFC, Z-Wave, ZigBee, LTE, UMTS, 5G, etc.

Open questions

1. Can a Machine be connected to multiple WiFi or Bluetooth networks at the same time? (if no, why not? does it depend on the physical hardware chip and is it maybe possible on other chips?

   • Do you connect to a network or to separate machines?

2. Since not every Machine has the same hardware and supports the same communications: how is the PROCEED engine deployed without errors if some communication mechanism is not available?

3. What information needs the User (the Universal Part)?

• the different networks have different address types (not always IPv4 or IPv6): how does a consistent machine identification looks like?

1. Where in the PROCEED Engines components is the functionality implemented? What information needs the dispatcher from the native part? and how is the abstract API?

Possible Solutions (with Open questions)

1. needs to be tested and researched

   • Ethernet, WiFi: Networks
   • Bluetooth, ZigBee, Z-Wave?
   • IEEE 1905.1 as an abstraction standard for multiple physical comm. layers

2. how are the functionalities integrated into the Engine without throwing errors at runtime?

   • consider the different native platforms (Linux, Mac, Android, iOS, ...)
   • Wrong for Node.js: the Engine has dependencies to native modules (native modules are usually only useable on one specific platform and not on every supported system of Node.js)
   • be inspired by other JS solutions: Node-Red, ioBroker
   • maybe reuse some of the already existing solutions
   • Multiple Solutions:
     1. Separate installed software component on the same system, which directly translates to a PROCEED API. E.g. Bluetooth software that communicates with a PROCEED HTTP API (Negative: Not every device has a HTTP interface, e.g Espruino Puck)
     2. additional software installed for PROCEED Engine (preferred for Node.js Implementation -> how is this possible with the current Engine-Dispatcher architecture?)
     3. Different versions for the different native Implementations

3. Important for the User

   • usually the physical layer is not important for the user
   • but it should be requestable, if needed
     • From Roman's thesis: "A possible approach is Unified Resource Identifiers (URIs). They are a set of characters that identify a resource. For example, a resource can be a device that communicates via Bluetooth. This device is identified through an ID provided by the native implementation (e.g., Espruino-Puck, Espruino-WiFi). Additionally, the devices communication preference needs to be considered. A possible solution is URIs naming scheme (e.g., http for the internet). PROCEED can leverage this scheme and establish communication-based on the type provided by the native implementation. In this case, a URI for an Espruino Puck may look like bluetooth://Espruino-Puck. Thus, this URI can be used by the universal engine part for establishing communication in a unified way."

4. Where in the Engine architecture:

   • environment profiles should be able to exclude specific communications -> universal part (only there the config can be considered
   • as much logic as possible in the universal part
   • also influences the discovery -> different on every system
   • maybe reuse some of the already existing solutions: ioBroker, Node-Red, Eclipse Hono (Network Abstraction)
   1. Engine Architecture and components:
   2. Dispatcher API: type, scan( timeout ), connect( machineId|network ), send( machineId, payload), ...

Backup: Bluetooth and WiFi in Node.js from Roman Thesis

The `noble` library for Node.js offers the described functionally and is available to Node.js version 10. `noble` is a Bluetooth Low Energy central module, meaning it offers functionality for an implementation that distributes and manages connections. Its sibling library `bleno` offers functionality for devices advertising their services. Because PROCEED is trying to establish connections between devices in a process, `noble` is a better fit. However, `bleno` can find application in PROCEED’s capability-based approach for devices - effectively allowing devices to broadcast their capabilities via Bluetooth.

const noble = require(’noble’);

class BluetoothLE {
 constructor() {
   this.devices = [];
   // register discover handler
   const discoverHandler = (p) => this.devices.push(p);
   noble.on(DISCOVER, discoverHandler)
 }

 // scan 5 seconds by default
 scan(time = 5000) {
   return new Promise((resolve, reject) => {
     // register state change handler
     const stateChangeHandler = (state) => {
       state === POWERED_ON ? noble.startScanning() : noble.stopScanning();
     }
     noble.on(STATE_CHANGE, stateChangeHandler);
     setTimeout(() => resolve(), time);
   })
 }

 connect(devicesId) {
   return new Promise((resolve, reject) => {
     const p = this.devices.find(p => p.id === devicesId);
     const errorCallback = (err) => reject(err) p ? resolve(p.connect(errorCallback)) : reject(‘Device ${devicesId} not found.‘);
   })
 }
}

module.exports = BluetoothLE;

// scan for devices
 const bt = new Distribution.BluetoothLE();
 await bt.scan();

 // connect to a device
 const deviceId = ’cb4f6f76715e’;
 bt.connect(deviceId);

It is possible to support Wi-Fi connections in PROCEED. The abstraction of Wi-Fi can be implemented with the node-wifi library. The library was chosen because of its active development and support of multiple platforms. The implementation built on top of this library supports a number of operating systems. It does so by using the respective network APIs of the underlying operating system. The supported operating systems are Linux, Mac, and Windows, with Linux being fully supported and Mac and Windows lacking support for disconnecting and deletion of connection information respectively.

const wifi = require(’node-wifi’);

class WiFiNode {
  constructor() {
    this.networks = [];
    wifi.init({ iface: null });
 }

 getNetworks() {
   return this.networks;
 }

 scan(time = 300) {
   return new Promise((resolve, reject) => {
     setTimeout(() => {
       wifi.scan((err, networks) => {
         if (err) { reject(err) }
         this.networks = networks;
         resolve(networks);
       });
     }, time)
   })
 }

 connect(ssid, password) {
   return new Promise((resolve, reject) => {
     wifi.connect({ ssid, password }, (err) => {
       if (err) { throw err }
       resolve();
     });
   })
 }
}

module.exports = WiFiNode;

 // scan for networks
 const wifi = new Distribution.WiFi();
 await wifi.scan()

 // connect to a network
 const ssid = ’admin’;
 const password = ’admin’;
 await wifi.connect(ssid, password);

Protocol Abstraction

Requirements

• to connect to/from all kinds of IoT systems, it should be possible to communicate over different application level protocols, e.g. HTTP, CoAP, MQTT, WebRTC

Open questions

1. is it possible to transfer every protocol over every physical communication layer? (or e.g. does bluetooth/z-wave/zigbee already offer specific application level protocols?)
2. how can the functionalities be abstracted?
3. with the abstraction: how can the specific properties of the protocol still be maintained?
4. how much/what is implemented inside the universal part and how much in the native part? should every engine contain all protocols?

Solutions (with open questions)