The Brain, Smart Lockers, and IoT Architecture

— by Alok Batra and Jane Ren

Last time when I wrote about India’s traffic and IoT architecture, my compatriots thought I had been so “Americanized” that I became scared by this day-to-day chaotic norm in the country of my birth.

But I’ve also learned good things in America. Of my two co-founders at Atomiton, one is a nuclear physicist from Russia; the other is a physician from China. One keeps telling me software runs on scientific principles; the other keeps telling me machines are just like patients.

So among other things I pick up in physics and biology, I start to see how IoT systems can learn from the human nervous system – another complex and adaptive system. Three amazing features of this system as examples:

1. When you fall asleep and become aware of nothing, you don’t stop breathing
2. Your head suddenly turns, then you realize half second later that it was because of a sudden loud sound coming from that direction
3. When told to “drive to the post office”, you don’t start by writing down a detailed plan of 10 steps how to get your car started

So how do they apply to building an IoT system? Let’s take the example of smart lockers. Think of them as ATM machines that let you deposit and pick up your packages. Below is a simple illustration of how it works.

To make the system work, you need a few things:

• Smart locks on each locker
• A controller at each station controlling the doors/locks
• Infrared sensor inside each locker to determine if there is a package
• Optionally, surveillance cameras at locker locations

Three architecture principles

Online/Offline: The locker station must be able to perform basic functions without assuming it is always connected to the cloud. That is, when in “offline” mode, customers should still be able to open the correct locker door and pick up the package. For three reasons

1. Reliability: you don’t want your customers who have driven to the locker location get frustrated that things do not work due to network issues.
2. Performance: if you plan to have thousands of such lockers in operations, you don’t want the network pipes to be the bottleneck of customer experience.
3. Security: allowing lockers to be operated from the cloud is a bad security practice that opens up unnecessary vulnerabilities (so is the case for many smart home gadgets).

Our nervous system is designed to handle online/offline. The brainstem is the part of the brain that controls vital functions such as breathing, heart rate, and body temperature. Because it has an ancient origin in evolution dated from the brains of reptiles, it’s referred to as the “reptilian brain”. (The other two “layers” of the brain are the limbic system and the neocortex). The reptilian brain does not need consciousness (online) to operate. It ensures that your heart still pumps and your lungs still expand when you fall asleep (offline). It would have been very bad if “online” was required all the time:

• “Be careful not to forget breathing, otherwise you will die!”
• “I cannot focus on my work because I’m distracted by busy keeping the rhythm of my breaths.”

Today, most IoT applications rely solely on cloud connectivity to function. In smart lockers, even though the controller sits locally, the logic has to come from the cloud. In contrast, a local processing unit should provide intelligence per local contexts. Global information is downloaded to the local environment when packages are associated with the specific location. The local unit should function independently while staying in sync with the global system.

Thinking, fast and slow: The term comes from Daniel Kahneman, a psychologist and Nobel prize winner in Economics. In his book “Thinking, Fast and Slow”, Kahneman explains elegantly the two systems in our mind. System 1: operates fast, “automatically” and intuitively, responsible for orienting to the source of a sudden sound, detecting a hostile face and driving a car on an empty road. System 2: operates more slowly, allocating attention to the effortful activities such as complex calculations, responsible for systematically searching something from memory, filling out tax forms, and comparing two washing machines for overall value.

A “system 1” function for the locker system would trigger responses immediately in these situations:

1. A delivery agent opens a locker and is supposed to drop a package. The door was closed again without the package being put in
2. Someone is trying to force open the lockers
3. The surveillance camera got dis-enabled for some reason

A “System 2” function would aggregate data from across locker locations, and try to understand if a certain pattern of locker breaches have been concentrated in the same neighborhood. But by the time “system 2” figures out, the time window for actions have already been missed. Decision would be made for future actions.

In IoT today, there is an over-emphasis on System 2 – the analytics system, but under-appreciation of System 1 – the responsive system. The responsive system needs to be driven by pre-defined models/events and responses, just like our brain has been trained to avoid accidents while driving – complex analytics does not work here.

Proper abstraction: Interestingly, both human cognition and software programming has taken abstraction as a core approach of advancement. Two things are key to abstraction:

First, separate the “what” from the “how”. Having abstracted the concept of a “car”, our brain associates it with the function of transportation, the features like leather seats, and the properties like miles per gallon. It puts the details away such as all the components of the car, how they are assembled and how they work.

Likewise in the locker system, only the local processing unit should deal with how to read infrared sensor data messages, how to detect if the locker door is open, and how to associated such multiple contexts. The business application should be written with concepts such as package deposited, door opened, and package retrieved. A common drawback of today’s IoT applications is that sensor and device level details are not abstracted. They get exposed straight up to the business application developers, who don’t have high-level concepts to work with.

A second, more important part of abstraction is to always abstract actions along with states. Database technologies such as SQL and NoSQL are “read only” when it comes to external sensors and devices. When IoT applications build abstraction based on such technologies, the “write” (action) is left to be dealt with from a separate path, often reverting back to discrete APIs.

If this state-action segregation happens in our cognitive system, you would have trouble with basic actions. For example, you have got the abstracted concept of a car, but now I ask you to drive to the post office. You cannot comprehend the instruction “drive”. Hence I have to write down a long winding list of tasks for you. First, go find a small gadget with a plastic head and a metal stick at the end (the key). Stick the metal end into a slot located below the round wheels. Turn the gadget to make an engine start. Find a stick to your right and shift it to “D” position. Step on one of the pedals at your right feet while putting your hands on the wheels… This long list of sequential instructions have to be followed every single time driving is required, because the action of “driving” was not abstracted when you learned the concept of the car.

Because IoT is still so new, abstraction of interactions with the physical world is rarely achieved, let alone keeping the consistency between the states and actions. Therefore this is one of the main focuses of Atomiton’s Thing Query Language.

I’m sure biological systems have a lot more to offer as lessons for IoT, and I would be very interested to hear your thoughts.