Even if IT professionals know the essential components of IoT and how they want to use it, many must still contend with developing skills in a new focus area, which can be highly nuanced.
Programming a full-stack IoT deployment requires at least a basic understanding of software engineering, but the main challenge comes from integrating IoT devices with the rest of the organization’s platforms and services.
In Programming the Internet of Things, author Andy King — also an adjunct lecturer of cyber-physical systems at Northeastern University — explains how to develop an integrated IoT system and tackle IoT deployment challenges. IT professionals building on their skill sets (and students just getting started) can follow the programming journey from the edge, where the device physically interacts with the world, to the cloud, where data gets processed. Executives can also understand the setup and team skill set requirements and change management challenges. The book digs into the design and implementation of IoT systems and how to use protocols to connect devices and platforms. Each exercise builds on the one before it. King also includes additional resources and embedded links for further instruction on specific aspects of IoT, such as security.
It might be easy for programmers to jump right into the technical components of connecting IoT, but King starts his book with the piece that drives every aspect of the IoT system: the problem statement. In this excerpt from Chapter 1, “Getting Started: IoT Basics and Development Environment Setup,” King explains how defining and breaking down the problem that an IT professional wants to solve will guide the construction of the end-to-end IoT deployment.
Defining Your System
Creating a problem statement is probably the most important part of this puzzle. Let’s start by drafting something that is reasonably straightforward but is enough to encompass a variety of interesting IoT challenges:
I want to understand the environment in my home, how it changes over time, and make adjustments to enhance comfort while saving money.
Seems simple enough, but this is a very broad goal. We can narrow it down by defining the key actions and objects in our problem statement. Our goal is to isolate the what, why, and how. Let’s first look at the what and the why and then identify any action(s) that the design should consider as part of this process.
Breaking Down the Problem
The exercises in this book will focus on building an IoT solution that can help you understand your home environment and respond appropriately. The assumption is that you’ll want to know what’s going on within your house (within reason) and take some sort of action if it’s warranted (for example, turn on the air conditioning if the temperature is too hot).
This part of your design approach considers three key activities:
Measure: Collect data
Let’s define this in terms of what can be sensed, like temperature, humidity, and so on. This is centered on the capture and transmission of telemetry (measurement data). The action — or rather, the action category — will be named data collection and will include the following data items (you can add more later):
- Relative Humidity
- Barometric Pressure
- System Performance (utilization metrics for CPU, memory, storage)
Model: Determine relevant changes from a given baseline
To decide which data is relevant and whether or not a change in value is important, we need not only to collect data but also to store and trend time-series data on the items we can sense (like temperature, humidity, etc., as indicated in the preceding definition). This is typically known as data → information conversion. I’ll refer to this category as data management.
Manage: Take action
We’ll establish some basic rules to determine whether we’ve crossed any important thresholds, which simply means we’ll send a signal to something if a threshold is crossed that requires some type of action (for instance, turning a thermostat up or down). This is typically known as information → knowledge conversion. I’ll refer to this category as system triggers.
In my university IoT course, I talk about Measure, Model, and Manage often. To me, they represent the core aspects of any IoT design that ultimately drive toward achieving the system’s specified business objectives, or outcomes.
Defining Relevant Outcomes
Now that we know what steps we need to take, let’s explore the why portion of our problem statement. We can summarize this using the following two points:
- Increase comfort: Ideally, we’d like to maintain a consistent temperature and humidity in our living environment. Things get a bit more complicated when we consider the number of rooms, how they’re used, and so forth. I refer to this action category as configuration management, and it goes hand in hand with both data management and system triggers.
- Save money: This gets a bit tricky. The most obvious way to save money is to not spend it! Since we’ll likely need to allocate financial resources to heat, cool, or humidify a given area, we want to optimize — not too much (wasteful), and not too little (we could end up with frozen water pipes in the winter). Since we might have some complexity to deal with here — including utility costs, seasonal changes, and so on, as well as anything related to configuration management — we’ll probably need some more advanced analytics to handle these concerns. I’ll call this action category analytics.
You’ve likely noticed that each step in the what and why sections has an action category name that will help with the solution design once we move on to the how. As a reminder, these categories are data collection, data management, system triggers, configuration management, and analytics. We’ll dig further into each of these as part of our implementation approach.
Although the problem statement seems rather banal on the surface, it turns out that the things you’ll need to do to address the problem are actually quite common within many IoT systems. There’s a need to collect data at its source, to store and analyze that data, and to take action if some indicator suggests doing so would be beneficial. Once you define your IoT architecture and start building the components that implement it — even though it will be specific to this problem — you’ll see how it can be applied to many other problem areas.
Let’s take a quick look at a simple data flow that represents this decision process; in the data flow diagram depicted in Figure 1-1, each action category is highlighted.
Figure 1-1. Simple IoT data flow
Most IoT systems will require at least some of the five action categories I’ve called out. This means we can define an architecture that maps these into a systems diagram and then start creating software components that implement part of the system.