| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|
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.
...
| Note | ||
|---|---|---|
| ||
In general, an IoT application (solution) can be divided into three segments:
|
|
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-digital2.
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 protocols 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 protocols 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"south-Boundbound") and communicating with your computer/server on the other side (North"north-Boundbound"). 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.
...
When we write C/C++ code on MCUs for IoT solutions, the they usually perform the following functions:
...
e. control frequency of these actions
In 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 controllers 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.
Sensors and Actuators can't be connected as it is to high end computers, who only provide serial interfaces like Bluetooth, USB, DB9, etc. There is intermediary electronics required to take analog or digital signals, compute the information and forward it upstream or vice-versa. Computed information from sensor is passed on a communication channel or forward the message from communication channel to actuator by using embedded software on the MCU.
https://www.sparkfun.com/tutorials/93
Gateway
Most of the MCU's support local protocols and hence any connected solution needs a gateway to take local protocols and expose the interfaces on IP based protocols. Here TQL Engine plays the role and abstracts all sensors and actuators connected through MCU's and/or devices connected on wireless or wired protocols and maps into local domain - like agriculture, parking, traffic, etc.
In some situations, instead of gateway, there may be only appliance where TQLEngine runs and integrates with all connected (wired or unwired) devices.
Cloud
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). TQLEngine runs in the cloud to aggregate all edge TQLEngines and directly connected devices (through IP stack).
Refer to a topology picture for the Greenhouse tutorial (to be created later)
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
Gliffy
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 instance of A-Stack running on a laptop, communicating with MCUs, or devices/machines
- 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.
- 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?
- 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.
- 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.
- 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.