The Power of Abstraction in IoT Applications

— by Baseer Khan

The title “Power of Abstraction” had been lingering on my mind ever since I posted the reason for having domain-specific language to combat the challenges faced when building thing-centric applications with ease and scale.

Abstraction and separation of concerns has been cornerstone of good software design methodology for a very long time. 

Abstraction Pattern - The kernel in case of operating system is good example of layer of abstraction between programs and the resources they need access to. The kernel provides abstraction for security, hardware, and internal data structures. Abstract software is intended to solve more than one problem. In majority of the cases abstract layers in software architecture solve non-domain problems: object persistence, multi-threading, distributed transactions.

Separation of Concerns (SoC) is a design principle for separating a computer program into distinct section, such that each section addresses a separate concern. The end goal of SoC is to achieve modular, easy to manage software components. HTML, CSS and Javascript which are complementary languages in developing webpages and websites, historically was not separated. Prior to the introduction of CSS, HTML performed both duties of defining semantics and style.

A sketch is the name that Arduino uses for a program. It's the unit of code that is uploaded to and run on an Arduino board. The main purpose of sketch is to do pin-level programming of the boards. Adding let’s say an Internet connection (although done with one single line of code in sketch likeMyConnection.publish(“hi_internet”); violates the SoC rule. It is similar to mixing HTML with CSS in its earlier days.

I would like to take this opportunity to explain how domain-specific language like TQL (Thing Query Language) that is built from ground up with abstraction and SoC as its fundamental design pattern and model-based approach to implementation gives the power to build thing-centric applications with flexibility and scale.

What is TQL?

A1 – Abstraction at Thing Level, is where we hide device identity and communication two important aspects when dealing with things. This is achieved by giving the developers an ability to write a ThingFacet.

ThingFacet is a reusable TQL component that defines the software interaction with a “thing” and represent the “thing” in the software. A “thing” can be sensors, actuators, devices or a particular aspect or function of a more complex machine.

Device identification and authentication becomes key in preventing malicious man-in-the-middle, key compromise and identity-spoofing attacks. ThingFacet provides hooks to perform device identification and authentication to integrate different key-exchange and Public Key Infrastructure (PKI) standards.

Things can be chatty. Every second that passes, thousands and millions of messages are being exchanged between. These messages pass over a multitude of transports and protocols (Bluetooth, Zigbee, Z-Wave, 6LowPAN, Thread, MQTT etc.) before reaching their destination, and there are no real standards to work with, which makes the development environment much more challenging. ThingFacet provides language construct to perform protocol-specific invocation to handle Device Communication.

A2 – Abstraction at Application Level: An application programmer should not need to know or care about where functionality is actually provided. Abstraction at application level is achieved using models and allowing application developers to write queries against the models. A model is a definition of some kind of entity. At run time, a model can be instantiated into model instances. In general, there are three types of models in TQL -

• ThingModel- representing any entity external to the system that can have interactions with the system (e.g. exchanging messages). These "things" can be sensors, actuators, machines, or other devices. ThingFacets are combined with ThingModel.
• DataModel- representing “pure” data. No interaction with Things.
• AppModel – representing any unit of application logic with possible interaction with external applications.

Queries - Application developers at the end of the day need ability to filter, join and manipulate data (pure or from things). In TQL, empowering developers with Queries achieves this. Like conventional queries, TQL queries can perform CRUD operations on data and eventually on things! For example, issue an Update Query on Camera Thing Model, with rotation angle changed will in reality turn the camera.

A3 – Abstraction at Platform Level - Abstraction in isolation without unified control does not work. It simply results in disconnected subsystems, for example thing interactions abstracted via Python SDKs, while application abstraction is happening through static REST APIs against collected data. We need a more holistic approach to meeting IoT development challenges, in which communications, security and storage are abstracted into flexible components - components that can evolve and change without affecting the core logic of the running software. Having a reliable and unified platform that puts the pieces of the IoT puzzle together will allow developers to focus on logic and functionality.

In TQL, TQLEngine is the runtime middleware engine that pulls ThingFacets, Models and Queries together. You can download and run on any platform of your choice – Raspberry Pi, Laptops or deploy to any public clouds (AWS, Azure, GCP etc.) The same engine that runs on the edge (smaller containers) runs on the cloud giving you the ability to build applications at scale.

Final thoughts

A (nxm) – Finally with this level of flexibility we are ready to build ‘n’ applications interacting with ‘m’ things. Although I am a great fan of uncle Ben’s famous quote - “With power comes responsibility” I must admit adopting abstraction and SoC, these days I am inkling towards - “With abstraction comes the power to build thing-centric applications with flexibility and at scale”.

Enough poking and liking let’s start TQL’ing

If you want to learn more about TQL, and using it for IoT, we offer a class here.