I have observed a discrepancy between hardware and software development practices. For hardware, the design phase is a given. Schematics always precede the soldering of circuits. Block diagrams and CAD drawings precede the fabrication of mechanical assemblies, fixtures, and equipment racks. Design documentation is essential for hardware. Why should software be any different?

Many developers are tempted to skip straight from the requirements specification to software coding. The more overall planning there is, however, the better the coding will be.

Start with a search for resources that will expedite design and development while positively influencing style. Search online for products, references, examples, drivers, toolkits, colleagues, and consultants. Many software-tool vendors provide online forums for developers to help each other, sharing articles, example code, and support.

Do not overlook the many available offline resources and media as well. The LabView software-development environment, for example, contains hundreds of example virtual instruments (VIs) that developers can use as a starting point for their application modules.

Next, develop a proof of concept to evaluate each specific instrument, hardware component, or software module. Design a test that will simulate the critical acquisition and analysis algorithms, and benchmark the execution speed. Then use the results to validate your design; seek alternatives, such as higher-performing instrumentation or faster data processing algorithms; or relax the requirements in your specification as necessary. When the proof of concept is complete, make sure you save it. You might be able to reuse all or portions of it in the final application.

Alternatively, you might find that the performance of your completed application differs from the proof of concept. In this case you should return to your proof of concept as a troubleshooting tool. If it still functions properly, you can begin to isolate performance issues to other areas. If the proof of concept suddenly stops working, the hardware, system configuration, or other conditions might have changed since the last successful run.

When the design phase is complete and the critical requirements have been evaluated via proof of concept, revisit the specification. Changes are inevitable. Conflicts might exist between several of the requirements, and tradeoffs and adjustments might be necessary. The specification is a living document. Be sure to revisit the specification on a periodic basis, and make any revisions needed.

Finally, code reuse is an essential technique in all modern programming environments. It can save the developer days of time versus starting each application from scratch. Every developer should maintain a software reuse library containing useful code modules. Moreover, every organization that employs multiple developers should maintain a reuse library in a networked repository under source control. The potential benefits include faster development time, greater commonality, and higher-quality applications.

There are several reasons to avoid “black box” or proprietary hardware or software packages. Most importantly it comes down to service and support issues. Utilizing proprietary hardware and software typically locks you into a single supplier for support and upgrades.

Most major control-hardware manufacturers support modular, open architecture packages that are capable of the speeds and advanced motion functions required by today’s most demanding applications. With larger manufacturers, you inherit a larger support network. This provides wider options for support and upgrade needs.

In today’s automation landscape, there are fewer and fewer applications that require any type of specialty controller. As an automation customer, you should demand an open-architecture system that can be locally supported. Similarly, your customers should be asking for copies of the source code, allowing them to maintain and troubleshoot their own systems. Suppliers can protect their code with software licenses while not impacting the customer’s ability to view, maintain, and troubleshoot the systems they purchase.

We get involved in many servo retrofits every year that involve replacing proprietary hardware and/or software that is no longer supported, is difficult to maintain, or is obsolete. These proprietary systems put tremendous pressure on the maintenance department. Just finding parts becomes difficult, let alone finding people with the ability to troubleshoot these legacy systems.

Users become precariously handcuffed by these systems In many cases, just losing a single individual means the entire support network is gone. In addition, if someone is available to support the system, the user often ends up paying an exorbitant amount for “specialty” knowledge.

In every such case, we have been able to replace these proprietary systems with open-architecture alternatives that are globally supported. Often these replacement systems are programmed via ladder logic, which is well known to maintenance personnel. The result is a modular system with built in flexibility, that can be supported locally via a variety of channels.