Pushing the Limits

Maximize Implementation Success With Standards-Based, Object-Oriented Design

By Rick Slaugenhaupt

Share Print Related RSS

The successful implementation of process control systems starts with good design. The best design should blend appropriate quantities of tried-and-true methods with value-adding modern technologies. Object-orientation is arguably the dominant methodology for software design. This straightforward technique promotes and defines the concept of bundling code into individual software objects, resulting in many benefits:

Modularity: The source code for an object can be written and maintained independently of the source code for other objects. Once created, an object is easily duplicated, enhancing consistency and simplifying understanding.

Abstraction: Objects interact through interfaces consisting of methods and attributes. By exposing only its public interface, the inner workings of an object remain hidden from the outside world. After all, once an object is coded and tested, it doesn't matter how it works. It just does.

Re-Use: If an object already exists which performs a needed function, you can simply re-use it. If a library of these objects is developed and maintained, chances are good that most of the functionality of a new control system can be constructed from existing components. How much effort could that eliminate?

Interchangeability: If a particular object turns out to be problematic, you can simply remove it and plug in a different object as its replacement. So long as the interfaces are consistent, the replacement should work without modification to the rest of the system.

Tools for object-oriented design are ubiquitous, but not for process control platforms. Until recently, implementing an object-oriented control design was tedious and difficult. Thankfully, that's all changing, as hardware vendors are now offering development tools that are designed with object-orientation in mind.

Successful Results Start with Worthy Goals

Object orientation by itself is a powerful tool, but when combined with time-tested project implementation methods and solid goals, successful results can and should be expected. A logical starting place is with goal-setting.

  • Build the right thing the first time. When a solution's architecture takes future needs into account, a proper foundation can be created that accommodates those needs without costly rework. Thus, a little extra work at the outset can pay sizeable dividends down the road.
  • Strive for an "agile" methodology. The term agility implies a lightweight process that can change direction quickly. This weight analogy has direct application to staffing of the development team, which should incorporate fewer, cross-trained individuals with broad experience in the many facets of process control design and implementation.
  • 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, a reduction of 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. When searching for examples of best practices, a good place to start is within well-established standards. For control system design, the most applicable standards are ISA88 (US) and IEC-61499 (Europe). Both are guidelines for applying object-oriented principals to process control. Given the time and effort committed to these standards, it's very unlikely that many needs, details or aspects of integration have been overlooked. Quite the contrary, they contain a thorough explanation and breakdown of techniques which are considered the best practices in the industry.

Also important are standards related to safety functionality and business integration. Safety standards, such as ISA84 (US) and IEC 61508 (Europe), and business integration standards, such as ISA95 (US) and IEC 62264 (Europe), provide guidance for the integration of process control with other systems.

  • Provide support for frequent software verification. Provisions for testing and verification are essential and are easily accomplished by adding simulation capabilities to each class 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. Creation of documentation for object functionality is easy and requires less total effort, because it's only created once—when the object class is first created. Likewise, it's easy to integrate that documentation into online help, as part of the HMI template used for each instance of the object. The result is documentation that is part of the solution and subsequently is frequently used and understood.

Sustainable Implementation Through Well-Organized, Properly Orchestrated Components

Lasting automation solutions are the result of careful planning and the use of well-formed, holistic design strategies promoted by published standards. Application of these standardized strategies produces solutions with continual relevance, adaptability to change, ease of management, and simplicity of use. Some of those strategies are highlighted below.

  • 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. This hierarchy is dictated by the process and/or operating requirements, and once known, it makes sense to structure the code objects in a similar hierarchy. ISA88 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 inter-dependency 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. ISA88 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. 

Share Print Reprints Permissions

What are your comments?

You cannot post comments until you have logged in. Login Here.

Comments

No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments