IoT - Managers' snapshot
This is my third “blog” of 2023. The goal for this blog is to create a “Balcony view” of IoT, keeping in mind the Software Development Managers. .
Before I proceed, a disclaimer – the article relies heavily on internet research and borrows pictures, diagrams, or texts available on internet, all for a non-commercial purpose – pure community learning. Wherever possible – I have tried to give credit to the source. If credits are missing for sections or pictures or diagrams or texts – it is simply a matter of oversight. The objective is to provide a useful summary for managers and business leaders who don’t have time to get their hands dirty with details and yet seek to have a grasp of the subject matter which is more than just a cursory level understanding.
With that, let's walk-in.
First things first – what is IoT?
?As with my previous blogs, the goal here is to make an attempt to live the saying: “If you can't explain it simply, you don't understand it well enough”. The goal, therefore, in this article is to paint a picture that traces the history only a bit to understand the genesis, makes an attempt to draw the list of catalysts – technical, business aspects or anything else that may be ?shaping the whole emergence and growth of IoT. But not to the level that would enable you to get your hands dirty with the nitty-gritties. This is for fun-reading that is useful. With that, let’s start our journey!
?
?Let's start with a T-shirt poster definition:
Now, if that is a very formal and boring definition, here is my own twist to make it for intuitive, personable and easy to remember way of defining it:
IoT has “things”. And IoT has “Internet”.
First, let us deal with “things”. In IoT, the things are powered by electricity and this “thing” could be an independent “thing” by itself or it could be “thing” attached to a larger electrical / mechanical device. These “things” would typically have three key pieces – sensors, a silicon semiconductor & actuators.
Sensors - Sensors could be temperature sensors, motion sensors, moisture sensors, air quality sensors, light sensors, you name it. In the Internet of Things, all the “things”, powered by these sensors, can make sense of their world in the way of collecting information from their immediate ecosystem or environment and send the information over to some kind of control center/server/hub that could be on Internet or on premise. That is the fundamental table stake.
The semiconductor chip– The semiconductor is the communication conduit. The semiconductor is the footprint on the “thing” that has the capability to run some code enabling that “thing” to join/participate a digital communication network and work through the usual communication protocol layers all the way up to application layer. ??
And then, you have the actuators – going by the strict definition of actuator is not desired here. Actuators could be electro-mechanical aspect of things or purely electrical/electronic. Essentially, actuators are aspect of the things that at lend “things” (or the larger host, the “thing” is attached to) to be remotely controlled, activated/deactivated so that things can happen – i.e. getting things done remotely. Could be switching the lights on/off or modulating the water sprinkler speed.
To bring home the point, in case you wonder if your ubiquitous smartphone is an IOT device – the answer is, sure, yes. Mobile phones are typically equipped with various sensors, such as GPS, accelerometer, gyroscope, and proximity sensors, actuators like speakers, display etc along with internet connectivity & compute footprint, which helps them fit nicely into the profiling of IoT above.
Here is a small excerpt from a medium.com blog.
“The most popular examples of IoT devices are wearable activity trackers, you can think of Jawbone and Fitbit, as well as smart home devices, like Hue and Nest. Jawbone and Fitbit are sensors that generate data about steps; the Hue is an actuator that emits light; and, Nest has both, it senses temperature and motion, and also actuates (turns on and off) the furnace” – link.
?
So, in some sense, we are talking about devices that can join a communication network, lend themselves to be open for remotely gathering information and optionally, to be remotely controlled to do stuffs.
The next two immediate questions are: why IoT explosion now? What is accelerating this? Did we develop some new technology now that didn’t exist earlier? Did we develop some algorithm that didn’t exist earlier?
First, a formal summary from Oracle:
What technologies have made IoT possible?
While the idea of IoT has been in existence for a long time, a collection of recent advances in a number of different technologies has made it practical.
Here is a more informal look at various accelerators:
Affordable high speed connectivity – Communication is at the heart of the IoT. We would want the “things” to be remotely monitored (or we would want the “things” to monitor their environment/ecosystem) and controlled /activated /responsive to achieve practical, real-time outcomes. This needs the “things” to be in lock-step with their network/hub/command-center and that works on the backbone of high-speed reliable communication. And we know how internet connectivity speed has been growing exponentially over the years. Please take a look:
?
Falling cost and rising density of integration of semiconductor chip: “Cramming more components onto integrated circuits “ – the famous paper by Gordon Moore in 1965 remained the mantra till date leading to continued decrease in cost of semiconductor chip. The key point that he made was that the rate of integration per square millimeter will continue to increase exponentially on an annual basis. At it remained so up until now. “One transistor, about as wide as a cotton fiber, cost roughly $8 in today’s dollars in the early 1960s; Intel was founded in 1968. Today, billions of transistors can be squeezed onto a chip the size of a fingernail, and transistor costs have fallen to a tiny fraction of a cent” – says a New York times article. So, what does all of these means? It just means, for our context, that the semiconductor chips are better and yet cheaper.? It also means the sensors and the actuators are cheaper. And that essentially means that the commoditized devices could be armed with this “things” in a commercially viable manner.
Cloud and virtualization technologies - The elastic power of the Cloud (you can spin on or off compute resources at will and at the drop of hat) and commoditization & democratization of compute power (these compute resources on Cloud are cheap and affordable @unit of 1 level) at scale at disposal of everyone – all powered by the technology developments in the world of virtualization, containerization and high speed affordable connectivity. Remember what we discussed in the beginning - the IoT ecosystem would require a compute hub (a command center that would work with the IoT devices) that can be scaled out in an affordable manner. And that is where Cloud comes as a blessing.
The hunger for data – the advancement in the world of AI and ML: Devices (or “things”) can now throw tons of data and there is a perfect storm in the sense that there is a whole world of technology, namely AI, deep learning, ML, Bigdata that is now hungry for petabytes of data to produce better outcomes in terms of predictions, trends and so on.
So, net of it – we have low cost of integration of semiconductor chips, cheaper and faster communication and consumers for petabytes of data produced by the “things” and supported by elastic and on-demand affordable compute power ?– all driving the evolution and explosion of IoT.
The emergence and maturation of IoT friendly protocols:
We have studied the accelerators so far. We saw how some key factors accentuated the emergence of conducive ecosystem for millions and billions of devices to participate in the “internet” as “things”. But there was still one more aspect – finding light-weight protocols that can match the needs of the promising new application of this technology. Let’s first see what are these needs that needed to be solved:
Now that we have discussed briefly the challenges that needed to be addressed for the promise of IoT to be actualized, namely, asynchronous communication, the scale, latency, power consumption and compute resource constraints and real-time response, let’s see how the world responded through providing right protocols and communication models:
The simplest scenario is one where the "things" want to either inform some entity or be informed by some entity. Let’s build on a use case: Let’s think of thousands of sprinklers in a field that are reading, let’s say, the moisture content of the soil in which they are immersed. Let’s imagine a scenario where they keep feeding some central location about the moisture content of the soils. And they are always open to turning on the actuator for sprinkling water on the field whenever being “told” to do so. Let’s further assume that this centralized location is aware of the weather updates and keeps on analyzing the moisture content and the weather forecast for next few hours to decide and instruct the sprinklers if they need to be turned-on.
Let’s think of another scenario: you have porch lights that only get turned on when movements are detected in the porch area by the motion sensors. There are multiple lights in the sprawling porch that are turned-off until the strategically located sensor detects motion and asks the porch lights to turn themselves on. Similarly, when the sensor stops detecting motion for a while, it asks the porch lights to turn themselves off.
Let’s think of a third scenario: we have fleet of medical devices that need to be kept at the desired state of configuration that can be customized/managed centrally by the admin. Anytime the admin changes the configuration profile, the respective devices need to know and update themselves.
?
Another scenario: A smart watch, when worn by the user, is continuously collecting the pulse rate and blood glucose level & sending the data over internet to a centralized server. The server, depending upon the data coming-in, could be triggering alarm, trigger emergency medical SOS or just do nothing.
领英推荐
?
Yet another scenario: Picture that you are getting back home from a vacation trip. What would cheer you up after a long road? A cup of freshly brewed coffee! And you can have it ready and waiting for you as soon as you open your entrance door. For this, you only need to launch your coffee maker using your smart home app. It will take just a few clicks to make it happen and get a cup of a tasty drink right up to your arrival. The smartphone can tell a centralized location to start the coffee maker and make a nice cup of cappuccino. The coffee maker, when informed by the centralized location, can trigger itself into action!
?
If we now try to visualize and build the communication patterns inherent in these scenarios and list them, they could look like the following:
Request-Response pattern: ?The motion sensor could request the porch lights to turn them on/off. The smart watch could request an upload of the data to the centralized server. The server could use request-response to send messages to the smart-watch. These could be thought-of as use cases of request-response. The sprinklers could be sending data to the centralized location using request-response.
Publish-subscribe pattern: The fleet of sprinklers could be made to subscribe to the centralized server for decision on turning on/off. Weather stations could publish their inputs on the centralized server. The fleet of medical devices could be made to subscribe to the centralized server for decisions on change in configuration. The admin could be made to publish whenever there is a new configuration that needs to be enforced on the fleet of devices. Anytime there is a change, the devices need to be “informed” so that they can configure themselves accordingly. ?The coffeemaker could be made to subscribe to the centralized hub. The smartphone app can leave a message for the coffee maker with the centralized hub. The coffee maker, since subscribed to it, gets the message and gets into action.
Now, let’s see the constructs that were available to us in the normal world prior to IOT.
Request-Response pattern: The Request/Response communication pattern is one of the most basic communication patterns. It allows a “client” to request information from a “server” in real-time. The words “client” and “server” are here used purely to illustrate the roles of the participants in the pattern, not to describe the hierarchy in the network. HTTP, which is based on REST architectural style is a good example of Request-response pattern. ?
Problem: As discussed earlier, in the world of IoT, we needed to solve this same age-old request-response scenario in a way that consumes less power / resource /compute cycle and yet in real-time manner.
Approach: So, here comes an approach that borrows heavily from HTTP, uses REST style but uses UDP instead of TCP. That gives some genesis to protocol like CoAP (Constrained Application Protocol). ?Let me explain. UDP makes it asynchronous and so, the lengthy CPU cycles waiting for the response is addressed. Remember that UDP is based on best-effort delivery services,? provides no acknowledgment mechanism which means that the receiver does not send the acknowledgment for the received packet, and the sender also does not wait for the acknowledgment for the packet that it has sent. Now we are making some progress, right? But you still want the essence of synchronous communication in the sense that you want to send a message and get an acknowledgement, for example. Well, how about building a communication model that uses intelligence at the message level to achieve a request/response within the framework of UDP. ?In the CoAP protocol, a reliable message is obtained using a Confirmable message (CON).
Finally, how about optimizing on the packet sizes to achieve more resilience and reliability against the odds mentioned above. To recap, all message exchanges in CoAP are like those for HTTP. With CoAP, all interchanges are asynchronous and datagram-based. ?Packets are light-weight. Additional reliability is brought-in with confirmable messages, when needed. As already highlighted, HTTP would not have sufficed because of the overhead, the long wait-cycle, higher power consumption and so on. A protocol like CoAP helped accelerate and address this problem. ?
That, BTW, is the whole point of this section. The point is not to go deep into the protocols. That, purely, is out of scope for this discussion. The point here is to demonstrate that the development, formalization, standardization and adoption of relevant protocols that addressed the IoT related challenges were also essential part of the factors that accentuated and accelerated IoT adoption in massive scale.
Some specific cases where CoAP is extensively used:
?
Publish-Subscribe pattern: The Publish/Subscribe pattern allows for mass distribution of information to interested parties in an efficient manner. It reduces network traffic by up to half, by allowing the publisher of information to send its information only once to a publish/subscribe server, who then retransmits it to subscribers. The Publish/Subscribe pattern is more efficient than other patterns, such as Request/Response or Asynchronous Messaging if the following conditions are met: a)Information does not have to be updated in real-time for continuous values (non-discrete values). b) Information does not have to be updated on demand. c) Published information is actually used.
?
Problem: We could have used traditional approach where the sprinklers could have reached out to the weather sensors/forecasters to get the information, the medical devices could have reached out to the configuration services to enquire about any configuration changes and respond based on the outcomes of these synchronous queries. I have already given away the hint – a traditional approach could have relied on http based synchronous queries between publishers and consumers (aka subscribers) leveraging web service architecture to solve the communication scenarios described ?so far. However, there are some significant challenges in taking that approach
And this is where a protocol that was developed originally by IBM in 1990’s for a different scenario emerged as an attractive approach to solve the issues with a traditional approach of HTTP based request-response in constrained environment of IoT.
A protocol like MQTT first of all decouples the publishers from subscribers.
The MQTT protocol defines two types of entities in the network: a message broker and a number of clients. The broker is a server that receives all messages from the clients and then routes those messages to relevant destination clients. A client is anything that can interact with the broker to send and receive messages. A client could be an IoT sensor in the field or an application in a data center that processes IoT data.
?
?
Now, you might be wondering how in such an environment/communication model, the issue of so called passively receiving command/inputs would work out. Well, consider a telephone call – if you call up someone and keep the line open, you can “passively receive communications”. Right? In MQTT, they figured something similar – if you want to passively receive inputs/commands/instructions, you need to have a way to do it. And more importantly, you need to have a way to do it with less resource, better scale and real-time. And the way MQTT solves this is where the IoT gets a nice help, once again. The “things” that subscribe to the “hub” (broker) makes use of a keep-alive construct at a configurable interval to ensure that the connection is alive and neither side has hung-up.
The “things” that want to be subscribed, once they are subscribed, can remain idle for a specified interval, but then they must notify the broker that they are still alive with a PING request (PINGREQ) message. This will let the MQTT broker keep them connected. If the client fails to send any message for any reason, it will be disconnected.
What is worth noting here is that the whole drill of subscribing, keeping the TCP connection open and using keepalive is extremely light on CPU cycle consumption and therefore, not same as polling. That connection to CPU cycle and resource consumption is important particularly in the context of this topic of things that helped IoT grow that has to operate in a constrained environment.
?
Ok. So, what is the point in all of these: The point with both of these example is that protocols were developed/customized/adopted making it yet another accelerator or facilitator for growth and explosion of IoT.
Here is a quick view of various popular protocols in use in IoT environment. You might see HTTP also in use and if that surprises you, be mindful that the choice of protocol depends upon the constraints of the environments, resources, scale etc. The discussion above attempted to clarify how particularly some protocols emerged or got developed or got customized and acted as a facilitator when the costs of using the existing protocols acted as inhibitor. That certainly doesn’t make other protocols bad. They may not just help in environments where cost is a big factor.
?
Finally, the business models:
I will begin with an use case picked up from one of the Oracle article. Here is what Oracle cites as a good example business model for IoT (link):
The connected car allows car manufacturers or dealers to turn the car ownership model on its head. Previously, manufacturers have had an arms-length relationship with individual buyers (or none at all). Essentially, the manufacturer’s relationship with the car ended once it was sent to the dealer. With connected cars, automobile makers or dealers can have a continuous relationship with their customers. Instead of selling cars, they can charge drivers usage fees, offering a “transportation-as-a-service” using autonomous cars. IoT allows manufacturers to upgrade their cars continuously with new software, a sea-change difference from the traditional model of car ownership in which vehicles immediately depreciate in performance and value.
?
Delloit’s article here describes in detail about vehicle subscription, describing the journey as “Vehicle-as-a-Service - From vehicle ownership to usage-based subscription models”. It goes on to describe the model available in Europe - ?“Vehicle subscriptions work similarly to other well-known subscription models, e.g., from the music industry: customers pay a flat monthly fee that grants them access to a vehicle (or music) that they can use as they please (within the terms of the contract). Once customers no longer need the vehicle (or music), they have the flexibility to terminate the contract or to upgrade or downgrade to a different vehicle category/ type (or account type) that better suits their needs. This gives customers the advantages of leasing/buying (i.e., their own personal vehicle for a certain period) combined with those of car-sharing/ride-hailing (i.e., flexible mobility without a prolonged financial commitment or the hassle of vehicle maintenance) in a single convenient product". As a result, subscriptions offer a “happy medium” within the vehicle-based mobility product portfolio. All powered by IoT.
?
Here are some interesting analysis and trends on vehicle subscription, an emerging business model in Europe.
Another use case:
Metromile, a San Francisco-based insurance company has a "pay-per-mile car insurance" business model. Here is what their website says: "You’ll pay a low monthly rate, plus a few cents for each mile you drive". They further say: "Traditional auto insurance is unfair to most consumers leaving 65% of drivers overpaying for auto insurance". They claim: "Pay Per Mile Insurance - With Metromile, your rate is based on your actual driving habits. Our customers save 47% on average compared to what they were paying their previous auto insurer”.? A “Pay-Per-Usage” business model powered by IoT. Link
?
Here is a quick recap:
The explosion of IoT has been a culmination of several things: Affordable high speed connectivity, Falling cost and rising density of integration of semiconductor chip, Cloud and virtualization technologies, The hunger for data - driven by accelerated development in AI/ML, Emergence, convergence and adaptation of suitable protocols and to cap it all, economy of scale, Digital transformation & the rise of the wave of Subscription and other usage-based business models. I hope the article above makes a reasonable attempt to explain in simple terms these catalysts and provides a balcony view of IoT.?
?
?
Other references: