India’s Traffic and IoT Architecture Strategy

— by Alok Batra

Earlier this month I was in India, as Atomiton is working on a Smart City project for Bangalore (what Modi calls “Electronic City”). This was my first visit to Bangalore after 5 years. Countries like India and China always surprise you with their pace of change whenever you look away for a few years. This was no exception.

Here in the “Silicon Valley of India”, you can now find almost every global technology company you know. HP, Cisco, Intel and IBM are the early settlers. But Google, Samsung, LG, Vodafone, Siemens, Bosch, Hitachi – you name it – have all moved in. Almost every piece of available land has been turned into large technology parks and office complexes. The population has grown from 6.5 million to 9.6 million in ten years.

The Bangalore challenge

But this is no Shanghai or Seattle – not yet. The road infrastructure has stayed pretty much the same as 5 – 10 years ago: the busiest main streets have 2-3 lanes, and 40% of roads are still unpaved.

What amazed me was how efficiently the commuters (still manage to) get around from point A to point B. Only 286 square miles in size, Bangalore roughly doubles the population density of San Francisco or NYC. Public transit only consists of buses – there is no subway or Muni. Most of the transportation is via private vehicles. If the New Yorkers or the San Franciscans were left to this challenge, I have no doubt the whole city would be locked down with traffic jams.

As I sat in the cab that drove me around the city, sweating over the dangerous maneuvers, I understood why such a system is more robust than its more “civilized” counterparts. Moreover, I see the IoT systems we are building will face the same challenges as the Bangalore city, primarily in three aspects:

1. Volume explosion: 26 billion connected devices by 2020, a 30-fold increase from today. If everyone “talks” to everyone, the actual “traffic” volume increase would be 900 times.
2. Infrastructure constraints: even if all infrastructure capacity follows Moore’s law, the efficiency gain would be only 32 times. It is doubtful that network capacity would actually get to 32 times greater.
3. Disorder: IoT is an interconnected system, not boxed solutions. All connected devices will behave in different paces, based on their local physical constraints, and often have different goals.

Three architectural strategies

So how does Bangalore cope and what is the learning for IoT architecture? Three things:

Distributed and peer-to-peer, not centralized. In the cacophony of moving cars, scooters, three wheelers, pedestrians, cows, mules and carts on the Bangalore street, lanes are for guidance only, there is no such thing as “yield” rules,
there is no “right of way” for pedestrians, or anyone else. But surprisingly accidents are very rare – by some magic everyone manages to move along just OK without collision.

Instead of all following a set of common instructions, navigation decisions are made second-by-second at each local interacting point, peer-to-peer. If two drivers are both trying to occupy a lane, or a pedestrian is trying to cross the street in front of running cars, the contextual information to reach local decisions are multi-fold: distance, speed, who honks more loudly, the posture of the pedestrian, or even the facial expression of the drivers. The decision of who lets who go first is reached on the fly. When such thousands of micro-decisions are made simultaneously and independently on local context, the streets become a living system and can be bent and stretched to accommodate large volumes.

In IoT, when we connect factories, hospitals and cities, the same applies. With thousands of tools, machines and people operating in numerous processes, the dangerous overheating of a particular tool on a particular floor unit should be determined and dealt with locally, instantaneously, instead of reported all the way up to the central cloud, waiting for response.

Event-centric and asynchronous, not sequential. Request-response based sequential systems cannot scale with volume or complexity. In the U.S., traffic intersections operate in a sequential fashion. You may have all experienced frustration in a left-turn lane waiting for the light. It seems unbearably long since all other directions of traffic have to take turns to go before it is finally your turn. More maddening, the signal is so short and the car in front of you is so slow, and you end up stuck behind having to wait for another round.

Well, in India you don’t wait. Most intersections do not have traffic signals anyway. Whoever can take the road first takes the road. My cab driver also took me in double or triple U-turns – two or three cars making the same U-turns simultaneously – and amidst running traffic. I admit this was where I missed several heartbeats.

Sequential systems don’t run well when exceptions happen. If one task takes longer all following ones are stuck. American drivers operate sequentially when they get to all-way stops. From time to time, one guy who is over polite would be waiting for the car which is waiting for him. And for a while all four cars go into a standstill.

The physical world that IoT connects will be as vast and “messy” as the Bangalore streets, if not more. Some connected devices may take longer to respond back, others may get unplugged from power unexpectedly. Synchronous processing for an interconnected, diverse system would get into deadlocks too often to be practically useful.

Time aware. The concept of time-awareness is tricky. One could argue against the claims that conventional software is not time aware. Don’t we have the concept of response time? Don’t we have scheduling software that deal with “time”? But in the first example, time is used as a performance metric, not a functional metric. In the second example, time is treated as data, not as constraints or modifiers of software processes.

Because traditional programming languages don’t have the concept of time, process execution are assumed to take zero time. In practice, the timing of traditional application processes depend on the hardware platform, not software specifications, making it further difficult to synchronize on multiple, distributed tasks and achieve determinism. This illustration from Patricia Derler explains succinctly.

Indian drivers are highly time-aware. They are probably calculating with distance and speed continuously in their heads. The constant question is, what is the time it takes me to get to that spot, and what is the time it takes the other driver to get to the same spot, and if I accelerate, can I get there first and miss a collision with the other car. They are acutely aware that processes take time, and if they are wrong on the sequence of events, bad things will happen.

American drivers rely on traffic lights – letting external constraints take care of sequencing issues. I follow the traffic light and do the best I can. Or they drive on pre-determined sequence of processes, for example at all-way stops.

In IoT systems, without time being a first class concept, the synchronization of processes connecting numerous diverse and autonomous devices would be almost impossible, let along the determinism to support mission critical systems.

IoT has a lot to learn. A system like the Bangalore streets is only one of the many complex adaptive systems offering such lessons.

Image credit: top 10 pics of India's insane infrastructure.