When systems are built from objects, documentation becomes more granular and organized. Creation of a thorough description of object functionality is not only easy, but requires less total effort because it's only created once – when the object class is first created. Likewise, it requires little effort to integrate that documentation into online help, which can be included as part of the HMI template used for each instance of the object. The result is documentation that doesn't have a separate identity from the system itself. It's part of the solution, and because it's easily accessed, it is frequently used and understood.
One further enhancement relating to documentation is to extend the concept of object-oriented design beyond the typical realm of software development. If the organizational benefits of this methodology are so useful to the controls engineer, why wouldn't they be useful to other disciplines as well? Process control projects are typically a subset of a larger-scale plant design project. When this is true, the amount of information gathered and generated can go up by an order of magnitude. How is all that information organized and managed? Defining object classes for physical components (e.g. a pump) with their associated methods and attributes (e.g. mounting, piping interface, pump curves, etc.) is a means to organize information and descriptive documents. Once an organization strategy is established, it's not much of a step further to implement a storage/retrieval mechanism – such as a relational database - to manage the mountain of information.
Managing project design information using this type of structure opens up the possibility of design re-use between projects. Just think how much time could be saved if physical design elements could be easily shared between multiple design efforts. The key enabler of this time-saving capability is the consistent organization of design information according to object-oriented principles, coupled with an appropriately designed relational database schema. That schema could then be applied to a SQL database of the user's choosing, followed by a simple user interface to assist with the storage and retrieval of project information. How useful would that be?
Standards-Based Implementation of Object-Oriented Design Maximizes Success and Sustainability
The successful implementation of a control system may start with good design, but it's the details of the execution phase that will ultimately determine the timeless viability of a solution based on that design. Hopefully, the previous discussion has made the case for object-orientation as the basis for quality design. While there are many possible ways to realize an object-oriented design, the most sustainable solution relies on a thoroughly detailed, standardized approach.
Standardization, when done well, reduces variability of solutions and maximizes the use of best practices. As mentioned above, two dominant standards exist for the design of process control solutions – ISA-88 (US) and IEC 61499 (Europe). These internationally accepted standards are the culmination of many years of effort and the collective input of a horde of experienced engineers. As a result, the guidelines promoted in these standards represent the best knowledge of process control experts relating to nearly all aspects of design and implementation.
Well-Organized, Properly Orchestrated Components Are Key to Sustainability
The standards mentioned above differ somewhat in their implementation details, but nonetheless have many core similarities and share a common purpose of promoting the use of object-oriented techniques in process control systems. The common elements of these standard methodologies form a solid foundation on which to build an efficient, adaptable, long-lasting control solution. Some desirable core attributes of these solutions are itemized in the inset to the right. These attributes result from careful planning and the use of well-formed, holistic design strategies like those described below.
Keep Procedural Logic Separate. Much of the code running in legacy systems these days freely mingles direct control (the how) with sequential or procedural logic (the when and why). This can seem like a more efficient style of coding, since all of the relative aspects of a particular function are kept together in the same place. However, a nasty side effect of this approach is a close inter-dependency of all 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. Moreover, this often happens in a less-than-obvious way, resulting in buggy code segments that act like hidden time-bombs, waiting for the right condition to blow up, perhaps weeks or months later, and after programming resources have been assigned elsewhere.
A better approach is to separate the part of the code that typically doesn't change from that which might. Code which mimics and supports the attributes and actions of real devices (i.e., direct control) can be debugged during commissioning and then shouldn't need touched again until the associated device is changed. The same cannot be said of the 'automatic' portion of control. This form of code dictates when and under what process conditions the device needs to operate. As this aspect of control can often experience flux, it makes sense to separate it from the more rigid, unchanging direct control. The result of this strategy is bullet-proof direct control that is indirectly manipulated by separate automatic logic that is more concise, easier to understand, and is simpler to modify and re-validate.
Use state-driven execution. In object-oriented terms, methods are the means by which objects carry out their prescribed actions. The various methods (i.e., actions and algorithms) pertaining to process and equipment objects are best coded using state-based, event-driven logic. This technique simplifies the initiating, executing, concluding and exception-handling aspects of method accomplishment, and as a by-product creates a convenient, highly organized framework for differentiating how code should respond to varying circumstances.