Thinkstock
Engineering the IoT: Business as Usual, or Something Much Different?
The terms Big Data, Cloud, and the Internet of Things (IoT) are bandied about freely, but not well understood—at least in the engineering sense. What is easily grasped, though, is that larger returns can be expected when the system is designed properly.
The potential of the IoT is breathtaking: Imagine a sea of sensors, put out in the field by multiple vendors (complying with specifications only in an informal sense), sending out terabytes of data available to anyone. Also envision applications (that can be written by anyone) filtering out the “nuggets” of valuable information for decision makers.
Dr. Dennis Curry, of Konica/Minolta, even hinted that “cognition” at the IoT level would be possible in his white paper Genius of Things: “The real promise of the IoT [is] its potential to deliver such a leap of insight about the world around us. Only when this becomes a reality will we understand the true genius made possible by connecting many things together.”
Sounds like a kind of nirvana, doesn’t it? But don’t forget that technology doesn’t just happen, somebody somewhere has to create it. And when it comes to the IoT, that means the ability to navigate the countless choices and tradeoffs inherent in any complex system and manage the consequences of the decisions made. Take data.
Every day, data gets delayed while traveling through the network without catastrophic consequences. Tomorrow, though, a stock trade “trigger” could be delayed—costing billions. Key economic indicators could be lost, setting off large economic movements. As with today’s Internet, tomorrow’s IoT developers will need to ensure that the right data gets to its destination in a timely fashion.
Want to move terabytes of data around a network? Recognize it ain’t all free. Engineers also must be concerned with things like whether all of the high-priority data will get through. Will any data be lost? How will you know? If a piezoelectric sensor detects a crack in the drill pipe, will you get the notification, or will it get out-prioritized by the ambient air temperature-reading made every ten minutes?
While the promise of the IoT is that the right data is out there waiting only to be collected to help us make better decisions, a little design rigor will help to ensure it.
At the risk of “being the hammer that thinks everything is a nail,” I think that Systems Engineering—an interdisciplinary field of engineering that focuses on how to design and manage complex engineering systems over their life cycles—concepts apply equally well to the IoT as they do in the design of any complex system.
Allow me to relate a lesson from early on in my career. If you remember the big move from 7400-series logic and PLDs to Field Programmable Gate Arrays (FPGAs) in the early 1980s, you know that the first designs were just “tossed in” and the FPGA software worked its magic.
Yes, we tossed the working design into the FPGA, and—guess what? It no longer worked. Only after weeks of painstaking simulations and re-routing signals to “clock spines” were we able to get a functional design. A bit of rigor on the front end of the design would have pointed out the critical setup/hold time areas of the circuitry and reduced design rework.
Systems Engineering has many different aspects to it, but it all starts with the basic question, “What do I really want to know?” From this basic question, requirements are derived and analyzed against a target architecture, an iterative process that may require changes to both, many times.
Once a project is underway, methods of Integration are planned in order to provide Validation (did we build the right system?) and Verification (did we build the system right?) of the Requirements.
Other systems engineering principles include: Peer Review, studying Defects (which are a fact of work), processes for Quality, and compliance with Standards.
You know the more I think about it, the more I realize that engineering for the IoT is the same as it’s always been for any complex system: Add structure to the design process to ensure success.
Article was originally published on Electronic Design.
