Prototype to production - A hands-on series

Tuesday, May 3, 2016

Building embedded systems is not rocket science, but neither is it usually a nice stroll through the park. Because electronic systems and software are complicated (and with each passing day the complexity is only increasing) developers need methodologies for identifying high risk system features and for rapidly gaining insights into the system in order to properly manage the risk. Prototyping an embedded system is a great way to reduce system risk through experimentation and sometimes even plain old trial and error.

Talking about how to prototype an embedded system is one thing but actually doing it is a totally different story. Over the course of the coming months, I’m going to be putting together a series of hands-on articles demonstrating how to prototype and create a production-intent industrial controller that connects to the internet, i.e., an IoT industrial controller. You’re invited to join me on the journey, beginning with exploring prototyping approaches.

Building embedded systems is not rocket science, but neither is it usually a nice stroll through the park. Because electronic systems and software are complicated (and with each passing day the complexity is only increasing) developers need methodologies for identifying high risk system features and for rapidly gaining insights into the system in order to properly manage the risk. Prototyping an embedded system is a great way to reduce system risk through experimentation and sometimes even plain old trial and error.

Rapid prototyping has other benefits, as well. Humans are optimistic and we often expect success even under the direst of circumstances. But if a project is to fail, as sometimes they do, we want them to fail as quickly as possible. Rapid prototyping can be used as a tool to verify market conditions and test technologies under development. A development kit, some jumpers, and a quick code hack can help quickly verify a flippant time and cost estimate made at the outset of the project so that a real estimate can be provided or the project can be scrapped before nearly putting a company out of business.

The challenge of embedded system design doesn’t end at proving that an idea or time estimate is accurate, though. The challenge is sometimes convincing the manager or business owner that the working proof-of-concept is just that – a concept. The system works, but only under carefully controlled conditions. So in the coming months we’ll not only explore techniques on how we can rapidly prototype our embedded system, we’ll look at how to convert the prototype to a production-intent system as rapidly as possible.