Crossing the DIY barrier: Your path to product
September 22, 2015
Over the last couple of years the Internet of Things (IoT) world has become increasingly easier to navigate. We've seen great attempts at products tha...
Over the last couple of years the Internet of Things (IoT) world has become increasingly easier to navigate. We’ve seen great attempts at products that show much promise, and this ability to innovate, to prototype with ease draws many to the IoT domain. However, a common issue in the IoT community is the process of scaling a great project from prototype to secure, commercial-grade solution.
We have engaged with many DIY enthusiasts who started their journey using an Intel Edison or Galileo board. While prototyping means much more than getting sensors to work, prototyping an IoT solution on one of these boards is easy, as a wide range of sensor libraries, debugging options, and fairly universal Yocto Project and Arduino support make for an extensive development toolbox at this level. For many, Arduino support alone makes for an easy entry into IoT.
What happens when you want to take your prototype to product?
Programming language selection, connectivity architectures, and hardware design are all quite important early on the path to an IoT product, and each can derail the development process. Without careful consideration, these can result in the need to create a 2nd prototype before porting over to commercial equipment.
Programming and portability
If you have been cruising around the Arduino world during your prototyping efforts, moving from prototype to product is where you might run into some issues. Arduino-based code is great for doing proofs of concept, and to a limited effect it can be used commercially. But things become more complex in commercial product design, where security, connectivity, manageability, and hardware all become critical components in the process.
A variety of programming languages and integrated development environments (IDEs) work throughout the Intel product line, but the most important point to understand is that having transferable code will prevent you from reinventing the wheel when moving to the end product stage.
Both the C/C++ and Python languages have advantages in IoT, particularly on the sensor level. A majority of the time, sensors and other base connections are going to be up in running in C/C++ or Python without significant fuss, and Python also works well moving data from the hardware to other destinations, or even pushing to Node.js. Beginning your path to product firmly entrenched in C/C++, Python, or Node.js will pay great dividends when moving to a product phase.
Connectivity contrast
Connectivity is the next major issue in the transition from DIY to commercial, as many DIY solutions have rudimentary connection types. On the DIY level, you will generally experience basic sensors that are hardwired and localized, whereas on the commercial level you will see that going hardwired is more difficult due to proximity and availability. Commercial-level sensors may not function in the same way as a base DIY model because, for instance, a simple temperature sensor can present significant coding, power, connection, and security challenges in a wireless remote model. Furthermore, wiring a home is much easier than a factory, so a sensitivity to where sensors will be deployed is also quite important.
Hardware disparity at scale
Scalability is one of the most important factors in the development process, and a key problem area when trying to move a DIY-based solution to the product level. Therefore, it is important to ensure that your design and hardware are a reasonable match.
On commercial solutions such as an Intel IoT Gateway, hardware is also designed differently. Generally, there are no I/O headers available to pin or solder to, though other connection options may be available for physical hardware. Power requirements may also be higher, as some gateways operate on as many as 24 volts.
Programming a DIY board is usually fairly simple, since you typically run simple code on a single processing thread. What happens when that one thread is not enough? Commercial-level gateways regularly employ four-core processors with the RAM to match for real-time analytics and increased sensor density, as trends continue to show a demand for more data processing performance at the edge.
Cloud(less)
IoT solutions need not follow the external cloud paradigm. By using Intel IoT Gateways and edge devices you may be able to keep your data local without ever touching an external cloud, saving you time and money. Look to pathways that keep your data within the system, can provide web support, and still provide live information in a timely manner.
Completing the path
Now that you have moved to a commercially viable, working prototype, what do you do with all the data? With the right solution there is so much to do. Proper planning from the start will both streamline and simplify your prototyping efforts and hopefully prevent the creation of several prototypes where only one is necessary and cost effective. Understanding the commercial IoT world is important when you are trying to productize your ideas. Choose your solutions wisely for a smooth path to product.
Intel Developer Zone
software.intel.com/en-us/iot
