In our first blog of the series we introduced a defined process that provides the necessary ground work for success in IoT development. In the second blog, we introduced concepts like brainstorming and developing a proper problem definition for IoT architecture.
Ideally each step of the process provides significant input into your potential product. Skipping over sections may work, however, you may find yourself stepping back to improve the groundwork necessary to move forward efficiently. To refresh, our process for development entails the following:
- Define a Problem
Here is our chicken and egg dilemma. In designing solutions, do you consider hardware or software in your first steps? Some would argue hardware comes first since primarily we are looking to build something physical. Others would contemplate software first since integrating a solution and the myriad of programming languages can be a significant problem to solve.
So here is the easy answer. You have a problem to solve from the previous step and you need to research the best ways to solve that problem, and how to implement them. Thus, if you have a system to integrate into, you can then get the parameters of how you will send and receive data, as well as how to physically integrate. In other words, focus on the problem at first. Look at all the angles from that direction: physical issues, software integration, network connectivity, and other aspects as presented in your environment.
Once you understand the problem, you will have a variety of parameters that usually will spell out how a solution can be identified and designed. For instance, if you were measuring water temperature, you would have to implement a sensor, provide power, and then communicate with the sensor. Environmentally we have identified potentially the type of sensor, and perhaps where the IoT device could be placed. If it were salt water for instance, the devices and sensors would need to be designed differently.
Study the System
Before we go further, a key aspect that most people overlook is what are you going to integrate into? Our salt water temperature problem doesn’t seem like it needs to integrate into anything. However, what if you were trying to monitor water quality in a manufacturing or power plant? Perhaps there is an existing system that needs the data. In a production environment, adding data inputs can easily improve the output quality.
So if we take our salt water temperature problem further, we need to look at a variety of aspects in our design. How do we protect our wiring? Where are we going to get power in what could be a remote design? How will we get a network connection? How will we protect the IoT device from corrosive conditions? These are just a few of the questions for the physical side, but also a good exercise in studying the system and the environment the hardware would reside within.
From the software side, consider how to talk to the sensor(s), and how to transmit data. What programming languages should be used to make this happen and run with maximum uptime? How will we interface with devices?
So far we have looked at solutions as if we were designing something fresh and new. A large number of IoT implementations are to solve problems within currently functional equipment. A causal approach searches to identify the causes of a problem, then looks to design solutions to the root causes.
There are many causes to a problem. From people, to resources - to - the environment, to policies and procedures or just to plain understanding the system. Ideally, an IoT solution - supplements a system with increased data. In turn, that can address many causes to a problem. If people are not following policies and procedures appropriately, supplementing the system with increased data that improves accuracy can then provide the basis to a decision system that has fewer errors.
A SWOT analysis looks at Strengths, Weaknesses, Opportunities and Threats in the evaluation of problems and solutions. Look to this regimented approach to best evaluate all of the factors that have been identified. Also, step out of the box, and redefine aspects of this analysis. Consider threats, for example. Traditionally we look at threats as being human in nature. However, in a physical sense, a threat can be caused by corrosion, weather damage, or even animals.
Looking at the problem, there are several solutions. Physically we might be able to build an enclosure that houses both the sensor, wiring and IOT device, seal it properly, run it on batteries and solve our physical problem. We could wire a sensor remotely to a shielded and protected IoT device as another solution. We could use a wireless sensor, to an IoT device running a network to capture data. From a software standpoint, we could capture data locally and then have a human login to the device periodically to gather data and upload. If there was a network nearby, we could transmit data to a host. If cellular were an option, we could have a constantly connected IoT device, which could provide a different type of solution.
As you can see in what should be a simple design, there is much to consider, and likely try as a proof of concept. Immediately discounting a solution at this point is not the best policy. Trying a lesser solution-with a favored solution could improve both solutions and leverage points from each to make a stronger solution. Simply put, try everything. You never know when - a lesser design could end- up being more favorable due to simplicity, cost, or other features.
How others looked at IOT creation: IOT Projects
Where to buy IOT products for your design: Where to buy
Login to leave a comment below. If you are not registered go to the Intel® Developer Zone to sign up.