IoT Project Planning – Profiting from the Folly of Others

I recently was introduced to a white paper written by John Stabenow, Director at Mentor, a Siemens Business, that gave an excellent overview of things to consider before launching into the design of an IoT edge project. John starts the paper with a quote from Pliny the Elder (A.D.23-A.D.79) who said, “The best plan is, as the common proverb has it, to profit from the folly of others”. This reminded me of a saying from one of my past supervisors who told me that “common things happen commonly”. Most mistakes have already been made by others and rather than repeat them we would all be wise to learn from their folly.

With that wisdom in mind, this is a white paper you will want to keep close at hand as the checklists contained in it can be used as a quick reference the next time you start a project. John breaks the planning task down into several areas including:

• Planning documents,
• Requirements specification, tracking and analysis,
• Scheduling
• Standards
• Defining infrastructure
• Outlining design composition
• Selecting IC technology
• Establishing the tool flow
• Automation
• Releasing and archiving the project

Each of these areas have multiple sub-areas to be considered and John does a good job of walking the reader through them. I’m going to highlight a few because these always seem to be the ones in my experience that ended up biting the teams with which I have worked.

The first thing that I’ve seen is that teams get confused about the purpose of the planning process. The idea is not to generate a bunch of documents because someone says you must. The planning process is meant to make you really think through what it is you are going to do and how you are going to go about doing it. If you must write something down, that will force you to start thinking through the alternatives to bring clarity to the documents.

The second thing that usually gets lost until much further into the project is the concept of a test plan. Done correctly, the test plan is part of the specification process. Not only do you specify what the system should be doing but you must also specify how you will test that the specifications have been met. If you address both these documents at the same time, you’ll usually find that your specifications aren’t nearly as clear as you thought them to first be. This is especially important if you are working on a design that has some safety implications and John does a good job of discussing some ways in which requirements can be captured and tracked across the design process using tools like Mentor’s ReqTracer.

A third thing that tends to get short shift in smaller companies is infrastructure and automation. An ounce of prevention here is worth a pound of cure later. Simple things like standardizing on project directory structures and file naming conventions can make things a lot simpler when it comes time to automate steps and archive the design when complete. I would lump into this category the use of version control or version management software. Ideally version management should be used for any files that are used by the design, including design data, test benches, documentation, automation scripts and even meta data about versions of CAD tools that are being used for any part of the design. It may seem silly to use version management software for automation scripts, but when you are deep into the design and a script change breaks everything, you will be wishing you had the previous version of that script that you knew worked correctly.

The last thing I pulled out from John’s white paper was the idea of defect tracking and how it relates to requirements management. As already mentioned, if you are working under a safety standard, you often need to prove how you track and manage defects. If you are designing in a modular fashion, testing of design blocks should be happening as each design block is implemented and bugs found during that process should be tracked against their associated requirements, specifications and versions of the block’s implementation. The last thing you want to do is fix a bug and then not have the fix get merged in with the rest of the design.

There is so much information in the white paper I can’t begin to cover all of it in this article. Hopefully I’ve given you enough of a feel that you’ll pull a copy for yourself and give it a read. I think you’ll agree with me that it’s a keeper. The next time you start a project, pull this white paper out and give it a quick read. It will really make you think about your next steps.

See Also:
White Paper: Preparing for an IoT Edge Project
ReqTracer web page
Tanner Tools web page
eBook – Custom SoCs for IoT: Simplified – Available for Free Download