Even if IT professionals know the building blocks of IoT and how they want to use it, many still grapple with developing skills in a new area of focus, which can be nuanced.
Programming a full stack IoT implementation 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 professor of Cyber-Physical Systems at Northeastern University – Explains how to develop an integrated IoT system and address IoT implementation challenges. IT professionals building on your skill setStudents (and students just starting out) can follow the programming journey from the edge, where the device physically interacts with the world, to the cloud, where the data is processed. Executives can also understand team and configuration skill set requirements and change management challenges. The book delves into the design and implementation of internet of things systems and how to use protocols to connect devices and platforms. Each exercise builds on the previous one. King also includes additional resources and built-in links for further guidance on IoT-specific aspects, such as security.
It can be easy for programmers to jump right into the technical components of connecting IoT, but King begins his book with the piece that drives all aspects 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 an IT professional wants to solve will guide the construction of the IoT implementation from end to end. other.
Defining your system
Creating a problem statement is probably the most important part of this puzzle. Let’s start by writing something that is reasonably simple but enough to cover a variety of interesting IoT challenges:
I want to understand my home environment, how it changes over time, and make adjustments to improve comfort and save money.
It seems simple enough, but this is a very broad goal. We can reduce it by defining the key actions and objects in our problem statement. Our goal is to isolate the what, whyY What. Let’s see first the what and the why and then identify any action(s) that the design should consider as part of this process.
break 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 he will want to know what is going on inside your house (within reason) and take some sort of action if warranted (for example, turning on the air conditioner if the temperature is too high).
This part of your design approach considers three key activities:
Measure: collect data
Let’s define this in terms of what can be felt, like temperature, humidity, etc. It focuses on capturing and transmitting telemetry (data measurement). The action, or rather the category of action, will be called data collection and will include the following data elements (you can add more later):
- Barometric pressure
- System performance (CPU usage metrics, memory, storage)
Model: Determine relevant changes from a given baseline
To decide what data is relevant and whether or not a change in value is important, we not only need to collect data, but also store and trend time-series data on the elements we can detect (such as temperature, humidity, etc., etc.). as indicated in the definition above). This is typically known as data conversion → information. I will refer to this category as data management.
Manage: take action
We’ll lay down some ground rules for determining if we’ve crossed some important threshold, which simply means that we’ll send a signal to something if a threshold is crossed that requires some kind of action (for example, raising or lowering a thermostat). This is typically known as information → knowledge conversion. I will refer to this category as system triggers.
In my college IoT course, I often talk about Measure, Model, and Manage. To me, they represent the core aspects of any IoT design that ultimately drive the achievement of the system’s specific business goals or outcomes.
Definition of relevant results
Now that we know what steps we need to take, let’s explore the why part of our problem statement. We can summarize this using the following two points:
- Increase comfort: Ideally, we would like to maintain a constant temperature and humidity in our living environment. Things get a bit more complicated when we consider the number of rooms, how they are used, etc. I refer to this category of action as configuration managementand goes hand in hand with data management and system triggers.
- Save money: This gets a bit tricky. The most obvious way to save money is not to spend it! Since we will 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 may have some complexity to deal with here, including utility costs, seasonal changes, etc., as well as everything related to configuration management, we probably need some more advanced analytics to handle these concerns. . I will call this category of action analytics.
You have probably noticed that each step in the what Y why sections has an action category name which will help with the design of the solution once we get to the What. As a reminder, these categories are Data Collection, Data Management, System Triggers, Configuration Management, and Analytics. We will delve into each of these as part of our implementation approach.
Although the problem statement seems pretty banal on the surface, it turns out that the things you’ll need to do to address the problem are pretty common in many IoT systems. There is a need to collect data at its source, store and analyze that data, and take action if any indicators suggest that doing so would be beneficial. Once you define your IoT architecture and start building the components that implement it, although it will be specific to this problem, you will see how it can be applied to many other problem areas.
Let’s take a quick look at a simple data stream that represents this decision process; In the data flow diagram depicted in Figure 1-1, each category of action is highlighted.
Most IoT systems will require at least some of the five categories of action I’ve mentioned. This means that we can define an architecture that maps them onto a systems diagram and then start creating software components that implement part of the system.