Building a Proof of Concept for IoT Architecture

Published:03/04/2016   Last Updated:03/04/2016

In our two previous blog entries, we introduced concepts in developing IoT architecture. Most notably, we laid out a process for development that specified a complete project plan;

  1. Define a Problem
  2. Identify/Design Solutions

  3. Build Proof of Concept

  4. Scaling up to Prototype

  5. Add Features/Evaluate

  6. Scaling to Production

If you have been following along, and perhaps preparing your project step by step, you should have a firm grasp of your problem that you seek to solve by now.  Additionally, you should have identified several solutions, and have potential designs for those solutions. The goal of these initial steps is to study the problem, and potential solutions to evaluate with an eye towards creating a viable product. Having choices, approaches, and a plan of attack is important at this stage. If you were instead focused on a single method of solution, you may become disappointed in the process when you are trying to overcome issues or dead ends in a stand alone design. This is why we are exploring multiple ideas.

Proof of Concept

Why a proof of concept (POC)? Why not a prototype? Let’s first start with distinguishing the difference.  A POC is a product not ready for market. The purpose is to explore technologies that might be used to create a prototype. A prototype is a general term that works on form, finish and functionality to deliver a product. The prototype is a marketable product process where a POC focuses on demonstrating that an idea is possible.

When you consider the grand scheme of things, many developers try to jump ahead and focus on a product. Essentially, they start running before they can walk. We strongly advocate the POC so that you can demonstrate the viability, as well as understand the needs and steps necessary to attempt creating a marketable product. This exploration is necessary feedback in the design phase.

Goals of a POC

Let’s break down the POC into three distinct parts: Hardware, Software, and Connectivity. The goal is to demonstrate on multiple levels that a design has potential to work and solve the problem at hand. Evaluating the POC with perhaps only one or two parts could help bring clarity, the reality is that we should have the most complete view possible to evaluate from.

The hardware aspect may not be store ready. A POC is not about creating a polished product. Many an IoT project started with placing a board inside a cardboard box with wires hanging out. The goal here is to demonstrate functionality, not beauty, that comes a bit later.

The main idea behind software at this step, is to demonstrate functionality of the sensors. IoT is also about data. Since you have shown that the sensors work, capturing accurate data is your next programming step.

So why use the term connectivity as the last of the parts? Connectivity here is about the physical and the software connection. Here is why this is so important, without connectivity, there is no IoT, it is just an electronic component. Remember IoT is about data, connectivity pushes that data to usable locations.


Testing and protocols for testing is a whole job within itself and can be complex. We can attempt to simplify this. You have a problem statement, and hopefully some parameters that indicate what a successful solution to the problem is, and what might not meet your standards. This can be the beginning of your testing.

If you were lucky to have specific parameters, you are on the right track to be testing with them in mind. However, there are many things that can be added that will produce valuable information. Many products built with Intel's tools will operate under a variety of conditions, such as different power levels, temperature ranges, enclosure types, with device shields, network solutions, and the list goes on. To include testing your POC at various power levels could be very useful. To assume that no matter where you plug the device in will give the same power level is not a great foundation for reasoning.

Testing of your software is just as important as the hardware. Again, software can run into issues if you are running on very low power. Make sure that you get repeatable results at a variety of power levels just to start. Again, your data is beyond important, so you must be sure that you can capture it correctly, for extended periods, the data can reach a destination and is usable.  It is one thing to capture what could be raw data, but if that data cannot be manipulated to a desired result, you have to redesign.

Lastly, look to make sure that you can consistently receive data at the destination.  Having the solution work temporarily is one thing, but to get a good data stream over time without errors, corruption, or data loss is far more important.


The recording of results is your next step.  Creating tables, spreadsheets, documentation, or even websites to retrieve your results are all within the realm of possibilities. While the recording of any results in testing is a step in the right direction, you should aim for a more scientific approach. Anyone that takes your approach should be able to repeat your process and achieve similar results and findings. Ideally, you should be able to hand your protocol over to someone, with either build instructions or the device that you made, and they should be able to repeat what you have accomplished with the same results.

Some small scale developers may look to bypass the study of a POC and the adjoining results. However, if you intend to take your project further, can you afford to not study the design as well as the performance? We really need to have the habit of quantifying what we have completed so that not only do we have proof that something worked as intended, we also have the data as back up. The result ends up being that you can repeatedly follow your protocol and achieve your results time and again, which is worth quite a bit. If you have errors, or malfunctions, since you have data, you can more easily trace where the errors are occurring.  

Many people confuse the POC with just an assembly process. A true proof of concept goes much further, and is integral in a well thought out design process. An assembled device, with software that is functional, that also connects and transmits data is key. Adding to this are quantifiable results that further demonstrate the device’s capabilities and now you have the entire package. A proof of concept is a strong tool that should be a part of all IoT projects.

Find out how others created from scratch: IoT projects.

Learn more of our IOT background

Login to leave a comment below. If you are not registered go to the Intel® Developer Zone to sign up.

Product and Performance Information


Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice.

Notice revision #20110804