Internet of Things (IoT) Architecture Formalisms

Scott@KnowledgeShark.me
6 min readFeb 19, 2023
Maggie in search (discovery/binding/dissemination) of smells (or my IoT based remote dog feeder)

Unless you are living off the grid, you are surrounded by smart devices. This will expand to 40–50 Billion in the next decade. Without becoming slaves to our devices, and without giving up (or going off the grid) new automation approaches are needed to simplify life without worrying about these new unbounded complexities. You want use of these devices to be fun and rewarding, and you want the opportunity to finally build those applications you just dreamt of before.

You want the calm feeling that the cable, and by definition, simplicity, is back in your life. Well the truth is that cat’s out of the bag, but putting the cable back, like Gene Wilder in Young Frankenstein putting the “candle” back — is a goal our Software Architectures should strive for:

See my Put the Cable Back writeup: https://medium.com/@knowledgeshark/put-the-cable-candle-back-a313ef74ce68

How will this be accomplished when 40–50 billion devices are active?

Imagine walking down a random isle of a quaint shopping boutique, when your smart phone beeps or vibrates. It’s letting you know that a rare item you have been searching for is nearly. Although you had forgotten about it; now using iBeacons to get you closer, like a geocache, the item is grabbed and you are onto other adventures. This binding flexibility augmented with deployed computers in the environment helps realize this vision.

Entering a room, like a museum or smart house, and now just discovering and absorbing all the available information in actionably form is possible. You might be in front of the Mona Lisa, and the tools maybe on the wall, disseminate interesting and relevant tidbits. It might even relate this painting with the Van Gough you just saw; the tools learned the unique routing you might have taken. This new computing freedom does come with interesting social changes, what might be called stockerish or big-brother.

Communication over a Distance, or Telegraph, was an approach that delivered accurate messages faster than known approaches; be it horse back, runner, carrier pidgin, or smoke signals. Before assuming emperor, General Napoleon saw the vision of the Telegraph’s use for military endeavors and in 1792 helped get funding to complete a new European wide Optical Networking system. Towers were built that could relay a message up and down a path of similar towers; say from the heart of Paris to a battlefield in Italy. A protocol was developed to encode messages and send them by signaling with the tower: configuring the moving arms above the tower into different angles that encoded the alphabet characters. A tower knob was used to pick the characters which moved the arms to match. This accuracy ensured almost perfect message transmission from one location, say Point A, to a destination (Point B).

This accessibility and speed meant that simple messages could travel long distances in hours versus days; with a bonus of delivery confirmation. Now the “attack at daybreak” command from Napoleon could be sent from the comforts of Paris; weighing the political tensions better. A language for remote concurrent command was enabled but was not the end-all solution. What were the security concerns? Could it scale to other routes or could multiple concurrent users overlap their messages in different directions? What about usability at night or in bad weather? Would funds and manpower allow for deploying and eventually maintaining new towers as his empire grew?

Napoleon’s Optical Networking system: Telegraph — or Distance Communication. 1792–1830

These systems all share common concerns and it’s the task of architects and engineers to design and describe solutions. Computer Science is the field that brings these technical concepts together through collaboration between users and various computing devices. This science is entering a new era — the Internet of Things (IoT) era.

Note all the terms in italic in above narrative. They form the basis for a formalized Software Architecture criteria: Discovery, Binding, Scalability, Security, Performance, Language, Concurrency, Maintainability, Deployment, Usability, Routing, Protocols, and Dissemination.

See my Max Headroom meets IoT writeup: https://medium.com/@knowledgeshark/the-internet-of-things-iot-meets-max-headroom-d62629f067b1

Common architecture approach

1830, Morris and others designed a new “electrical” signaling device. If built, it would perform almost identical functions as the existing Telegraph systems. Message transmission was getting very efficient, new lines were showing up all over Europe and run independently by the countries who were often at war. Morris had to convince some US senators that his system had all the potential to be much better. He had a hard time making that case, and it took better selling. He eventually provided a great demo.

A well understood formalism to describe and compare different systems was needed. Morris had to contrast his proposed system to that already understood. An architecture blueprint is a tool to help ease some of these concerns, but usually is a set of defining important features of a system. This might be that wires could be strung long distances, and the electrical current would allow messages to be sent at night — while the existing telegraph couldn’t. Hiding messages to only those with decoding machines stopped eavesdropping by the enemy that can see the same tower and read the “attack at dawn” message.

Selling his idea to congress could have been a litany of these “improvements” — but those stakeholders getting the briefing might be lost and unable to relate to what they know. Providing context relating the previous and new system is needed; one that is concise, formal and visual; one that makes it easy to jump back and forth, comparing as you go. This formalism could provide consistency at different phases, such as estimating, building, maintaining, or using. With a common checklist, an architecture could address these important issues.

An architecture “rubix” could even contrast systems across generations, from 1792 to 1830 — or from 1989 to 2015; or across computing technologies from mainframes, to laptops, to smart phones, to embedded or mobile devices, bluetooth networks, and now the Internet of Things (IoT).

One part of that architecture approach is to provide an Elevator Speech. And example is below.

Follow-on discussions will dive into the architecture “rubix” helping formalize architecutes. These follow many of the known IEEE Views and Perspectives. Next time..

See my My Five (5) Computer Science Genre’s writeup: https://medium.com/@knowledgeshark/my-five-5-computer-science-genres-d7ba52ed1cb4

Also, I’ll show how remote messaging is the lifeblood of these IoT frameworks and describe powerful architecture solutions, including embedded ESP32 based devices (with Bluetooth and WIFI), MQTT and node-red messaging support. Fun stuff.

Elevator Speech (4 parts)

Example of an elevator speech in terms of this architectural rubix.

  1. What is the problem?

Unbounded complexity of new generation of environment sensing devices (IoT).

We are surrounded by an ever expanding litany of smart devices, continually sensing the environment providing feedback and control in our daily life. Be it a heart rate monitor, smart shopping list, home automation, or remotely monitoring animals — a flood of technology, called The Internet of Things (IoT) is a reality. This is becoming an unbounded challenge rivaling the most complex solutions imagined (think of the planet sized “Death Star” from the Starwars movie).

2. What do we provide?

Custom Architecture leveraging IoT devices. “Do what I mean”.

We provide an Architecture customized to leverage your smart devices; a “Do what I mean” solution.

3. How is this approach different?

“Rubix” Matrix Architecture App; Automatic Programming, not brute force.

By looking beyond brute force coding solutions, we provide an approach for automatically programming the dynamic connections between the environment and all the smart IoT devices. This is captured in our “rubix”” Matrix Architecture “app” — comparing and addressing your stakeholders concerns. The result is your custom architecture that adapts to the smart devices you encounter.

4. Why you should care?

Billions of devices; unprecedented application opportunities now possible.

--

--

Scott@KnowledgeShark.me

Computer Scientist and futuristic IoT app developer; KnowledgeShark is my next gen technology navigator; Distributed Computing historian. ACM.org since 1979.