TQL and IoT Application Topology

Owned by Alok Batra
Last updated: Jan 12, 2017 by Baseer Khan
4 min read

IoT Application Layers

In IoT World, we are starting from analog world and connecting to digital cloud and hence multiple layers play the role in the middle.

In general, an IoT application (solution) can be divided into three segments:

  1. The sensors and actuators
  2. The micro-controllers (MCUs)
  3. Gateways - "Edge is the inital step of Internet of Things"
  4. Cloud


Sensors or Actuators

Sensors and actuators are the physical touch points to the physical world.  They come in two categories - Analog and Digital. Analog sensors need electronics to convert analog signals to digital output. Digital Sensors have this electronics as part of the sensor.

https://learn.sparkfun.com/tutorials/analog-vs-digital

MCUs

Signal or data coming from sensors and actuators often cannot be interpreted and utilized directly by the operating systems (Windows, Mac, Linux) running on modern general purpose computers. Most modern computers's operating systems support serial interfaces such as Bluetooth, USB, DB9, but not low level patterns used by sensors and actuators, such as SPI, I2C, and UART.

A software program needs to be written to translate the signal or data from low level interaction patterns to the serial or other high level protocols accepted by our computers before they can be utilized by your application. These programs are frequently written in C/C++.

With the current technology capabilities, it often makes sense to run such programs on a very small processor called a micro-controller (MCU). These MCUs run different operating systems from the ones on your computer.

The MCU then will be connecting to the sensors and actuators on one side ("south-bound") and communicating with your computer/server on the other side ("north-bound"). Analog Sensors can connect to analog pins and digital sensors are connected to digital pins on the MCU. The north bound communication often takes a serial protocol. It can be wired serial or wireless serial. Newer generation of MCU's may directly support IP protocols.

You can find out more about the general information on MCUs here ____________.

When we write C/C++ code on MCUs for IoT solutions, they usually perform the following functions:

a. assignment of MCU pins to the sensor

b. send/receive voltage signals from the pins

c. convert voltage signals to digital values, with calibration formula

d. send the digital value through the (serial) port

e. control frequency of these actions

On Arduino these programs are called sketches.

https://www.sparkfun.com/tutorials/93

Devices and Machines

However, as discussed in Thing Categories, many devices and machines have their own controller built inside. These controllers perform similar functions to the MCUs. Therefore, devices and machines are often able to communicate at a higher level protocol accepted by your operating system. When you have an IoT solution with such devices and machines, you may not need separate MCUs. 

Gateways

The applications starts from programs that run on general purpose computing devices. They don't have to be your computer. They can be a gateway, a laptop, or a server. For that matter, the Raspberry Pi is also a general purpose computer and is where the IoT application can start. In general, we call the general purpose computers that are deployed "locally" (i.e. close to the sensors, devices and machines) "gateways". Gateways are often used to take advantage of range-limited protocols such as ZigBee, Lora, WiFi, Bluetooth, and Serial. 

Usually, gateways are more lightweight, small foot-print, and small-sized computers. For example, the Raspberry Pi, the Intel Stick and Cisco IoT Gateways.  Some "gateways" get bigger and more powerful, and we call them "appliances". 

Gateway Functions Include:

  • On-board Processing
  • Data Aggregation
  • Real-time Analytics
  • Data Transfer


Clouds

We call the computers that gets the IoT data only from IP protocols (and hence whose physical location does not matter) the "clouds". Cloud can be private (in enterprise datacenter) or public (AWS).

Your IoT application may run only on the cloud without a gateway. Likewise, you may have an application that only run on a gateway, without cloud. The division between gateways and clouds is often by design, not rigid.


How TQL runs in IoT Solutions

The power of IoT is in the applications. However, moving all of that collected data around is also important. That's why middleware frameworks like A-Stack offers flexibility to run in cloud as a platform or condensed into intelligent gateway to close the gap between devices in the field and the cloud.

The A-Stack is a peer-to-peer enabled middleware and application container. Because of its small footprint, it can run on any range of computers starting from most gateway type of devices to large clouds. For example, RaspberryPi, your laptop, servers, and on public/private clouds. IoT applications written in TQL can often be distributed across gateways and clouds. However, because A-Stack requires JVM to run, it does not run on MCUs.

Here are a few options:

  1. 1 instance of A-Stack running on a laptop, communicating with MCUs, or devices/machines
  2. Multiple instances of A-Stack running on multiple gateways (each gateway has 1). Another instance of A-Stack running in the cloud. They communicate with each other.
  3. All instances of A-Stacks are running on local gateways, without a cloud instance. 

The flexibility of the A-Stack requires many variations of the application topology. So you can choose per your design and project requirement.

How can Data be collected?


  1. Direct collection: A common industrial scenario is when data is transmitted directly from the machine to the cloud platform when A-Stack is hosted is by using its own internal connectivity for example, WiFi, ethernet or 3G/4G.
  2. Mobile App Bridge:  Most often used for applications for consumer products or retail spaces where dedicated connectivity equipment is impractical or cost prohibitive. In these circumstances, the data exchange between objects and the cloud hosted A-Stack is typically managed through mobile phones, via WiFi or Bluetooth.
  3. Intelligent gateway: This is the best solution in terms of performance optimization and flexibility of protocols. In these circumstances, the gateway collects data from machines or equipment through a series of possible protocols - most frequently field protocols such as Modbus - and submits them to the platform, while optimizing a number of processes at the edge.