This is the second in a series of newsletters that present seven principles to help guide your own processes and best practices in hardware/firmware interface design. This month’s principle focuses on establishing and applying standards for embedded systems development.

Standards need to be set and followed within the organization. I group standards into industry standards and internal standards.

Industry standards exist in many areas, such as ANSI C, POSIX, PCI Express, and JTAG. Stay true to industry standards. Don’t change them. Changing a standard will break the protocol, interoperability, and any off-the-shelf components, such as IP, device drivers, and test suites. For example, USB is widely known and used for connecting devices to computers. If this standard is adhered to, any USB-enabled device can plug into any computer and a well-defined behavior will occur (even if it is “unknown USB device installed”).

Industry standards evolve but still behave in a well-defined manner. USB has evolved, from 1.1, to 2.0, and now 3.0, but it still has a well-defined behavior when plugging one version into another.

By internal standards, I mean that you have set standards, rules, and guidelines that everybody must follow within your organization. Modules are written in a certain fashion, specific quality checks are performed, and documentation is written in a specified format. Common practices and methods are defined to promote reuse and avoid the complexity of multiple, redundant ways of doing the same thing.

In the same way that industry standards allow many companies to produce similar products, following internal standards allows many engineers to work together and encourages them to make refinements to the design. It provides consistency among modules, creation of common test suites and debugging tools, and it spreads expertise among all the engineers.

Look at the standards within your organization. Look for best practices that are being used and formalize them to make them into standards that everybody abides by. There are many methods and techniques in the industry that help with this, such as CMMI (capability maturity model integration, an approach for improving processes; cmmiinstitute.com), ISO (International Organization for Standardization, international standards for business, government, and society; iso.org), and Agile (software development methods promoting regular inspection and adaptation; agilealliance.org). Adapt and change your internal standards as necessary. If a change needs to be made, it needs to go through a review and approval process by all interested parties. Once such a change has been approved, make sure that it is published within your organization. Apply version numbers if necessary.

There is no such thing as a “customized standard.” Something is either a standard or customized, but not both. If you break away from a standard, be sure you have a good reason.

• Principle 2: Set and Adhere to Standards.

Until my next standard newsletter…