In previous blog posts, I’ve spent a lot of time sharing info about precision agriculture. This month and in the months to come, I’ll be focusing on design patterns relevant to IoT. When it comes to solving problems in new domains or with new technologies, one often benefits by framing the problem in the context of problems already solved. Mathematicians are notorious for taking a seemingly new and challenging problem and applying a well-known technique to solve it. For example, going through integral calculus will lead a student to be exposed to both u-substitution and trig substitution. In both cases, we are taking what appears to be a hard problem and turning it into an easier problem we’ve previously solved. We are also using a type of design pattern - substitution in this case - to tackle hard problems. This exact same approach happens in software engineering as we apply well established design patterns when we work with new technologies, languages, and domains.
The design pattern that we see applied to many IoT applications is the popular Publish-Subscribe (or PubSub) design pattern. To briefly introduce this concept, consider a system which has a component that keeps track of the power state. Power could be on (full power), shutting down, or off. As the system transitions from on, to shutdown, to off, some other components in the system – but not all – will need to be aware of this so they can save data and be in a safe state. If a component wants to know the current power state, it could periodically poll for this information and react accordingly. However, since this state rarely changes and the only event of interest is the transition, this leads to a lot of wasted effort. This is where PubSub comes in. The power manager is the publisher of data, the components that need it are the subscribers, and a message broker is created to manage the publishers, subscribers, and notifications. On startup, the message broker gathers a list of publishers and subscribers. Whenever a publisher kicks out an update, the message broker notifies all those who have subscribed.
Now as we think about IoT, consider the below image from chipdesignmag.com.
While there are dozens of examples to consider in the above image, focus in on the Medical & Healthcare section. Imagine a hospital with dozens of patients who wear glucose monitors keeping track of blood sugars related to diabetes. Provided their blood sugar levels remain in a healthy range, there is no cause for concern, but once a patient’s levels leave this range action may need to be taken. To detect this condition, you could either continuously poll across all patients – which would be expensive and time consuming – or you could simply be notified in the event that a patient enters a range that is concerning. A more advanced system could even allow for the creation of custom ranges on a per patient basis to create more tailored notifications.
With a bit of background in PubSub established, in my next blog post we will explore the communication infrastructure seen in the center and get a better understanding of MQTT and why it’s important for IoT.