Build it right the first time. Take existing and future infrastructure needs into account to create a proper foundation that accommodates those needs. This will pay sizeable dividends down the road without costly rework.

Strive for an “agile” methodology. The term agility implies a lightweight process that can both accelerate and change direction quickly. To this point, a development team should incorporate a select group of cross-trained individuals who have broad experience in the many facets of process control design and implementation. These individuals will ramp up quickly and adapt to changing requirements with equal aplomb.

Maximize simplicity and maintainability. Few will argue the virtues of the KISS principle (keep it simple, stupid), and simplicity of design is at the heart of many success stories. By its nature, reducing extraneous details enhances maintainability. After all, the easiest system to maintain is the one that is simple to understand.

Minimize engineering effort through re-use. The concept is simple. When components of a system are designed to be re-usable, the fruits of expensive engineering efforts are maximized. Furthermore, when a component will be used over and over, committing resources for adequate testing and documentation is rarely an issue.

Aim for a “best practices” solution. For control system design, the most applicable standards – ANSI/ISA-88.00.01 and IEC-61499 – both provide guidelines for applying object-oriented principals to process control and contain a thorough explanation and breakdown of techniques, which are considered the best practices in the industry. Safety standards – ISA-84 and IEC 61511 – and business integration standards – ISA-95 and IEC 62264 – are also important for guidance when integrating process control with other systems.

Optimize the whole rather than the parts. It seems logical that by fully optimizing each part of a system, the system is also optimized. This can be true to some extent, but when optimizing individual components, the needs of the whole system tend to be ignored, which puts a lower value on overall system functionality. A better approach is to first optimize the system, and then optimize the resulting components – but only to the extent that the effort doesn’t detract from any prior system optimization. An example of this is using a generic object that may contain common denominator functionality that isn’t required for every instance where it’s applied but maintains consistency of the broader control architecture.

Provide support for frequent software verification. Provisions for testing and verification are essential and are easily accomplished by adding simulation capabilities to each object in a library. This feature permits testing of the expected response to a condition without having to actually create it, which is especially useful if that situation might risk equipment damage or personnel safety.

Integrate project documentation. If design documentation is integrated into the system in the form of an online reference, chances are it will be better maintained and will be accessed with greater ease. Creating documentation for object functionality is easy and requires less total effort, because it’s only created once (i.e., when the object class is first created).

Ideally, this documentation should be integrated with the code, but where those tools aren’t provided, it’s also easy to integrate that documentation into online help as part of the human-machine interface (HMI). Regardless of the method used to create it, documentation that is part of the solution will be more frequently used and understood.

Support safety integration. In addition to the regular re-testing of requirements mentioned earlier, safety standards impose the need for reliable mechanisms for manipulating process or equipment actions when adverse conditions are detected. Reliability is the key here, and a simple, consistent and thoroughly tested means of initiating pre-determined actions is critical to the integration of safety systems into the process control system. Properly developed objects can easily facilitate this capability when designed with a configurable override response feature and a simple, consistent and reliable mechanism for triggering it.

Organize objects into a hierarchy. Complex control systems are rarely flat. Direct control is generally at the bottom, organized by group functionality. Those groups are in turn associated with more sophisticated control algorithms that are manipulated by sequential procedures. The process and/or operating requirements dictates this hierarchy, and once known, it makes sense to structure the code objects in a similar hierarchy. The ISA-88 standard provides a thorough set of guidelines for properly sorting out the desired process/equipment hierarchy.

Keep procedural logic separate. Much of the code running in legacy systems freely mingles direct control (the how) with sequential or procedural logic (the when and why). A nasty side effect of this approach is a close interdependency of the code (a.k.a. spaghetti code). As a result, it’s difficult to modify any part of the code without somehow affecting the rest of it.

A better approach is to separate the part of the code that typically doesn’t change from that which might change. ISA-88 defines control and procedural object types as different entities. Control objects mimic the unchanging attributes and actions of real devices, while procedural objects deal with the execution of predefined operations that produce a product with the highest quality or in the greatest quantity.

In contrast to the unchanging nature of direct control, the procedural logic will often experience flux, so it makes sense to separate it from direct control code. The benefit of this strategy is logic that is more concise, easier to understand and simpler to modify and revalidate.