Maximize the Success of Your Control System Implementation with Standards-Based Object-Oriented Design

Find Out What Are the Benefits of Using Object-Oriented Design Principals in the Design of a Modern Process Control Solution

By Rick Slaugenhaupt

Share Print Related RSS
Page 2 of 6 1 | 2 | 3 | 4 | 5 | 6 View on one page

Strive for an 'agile' methodology. Customers know that the best solutions are executed quickly and readily adapt to changing needs and requirements. Cumbersome development methods, driven by the desire for complete code documentation and rigid change management procedures, produce well-managed software projects – but often at the customer's expense, by limiting adaptability for incorporating new or changing needs. While conventional methods are useful to programmers, they typically limit customer participation to only the beginning and end of the project lifecycle. A better approach would include customer input throughout the development cycle by incrementally reviewing and approving frequently delivered, working portions of software. The frequent feedback from the customer aids in refinement of requirement details and helps the developer understand what functionality provides the best solution for the customer.

The term agility implies a lightweight process that can change direction quickly. This weight analogy has direct application to staffing of the development team. The typical project team of highly specialized individuals is often large in size and slow to understand details that fall outside individual specialties. A better approach to staffing would incorporate fewer, cross-trained individuals with broad experience in the many facets of process control design and implementation. This small and highly capable core of people is more capable of understanding the entire scope of project details, and by virtue of small size can quickly adapt to fluid requirements. This 'skunk-works' approach to project development has far more chance of pleasing the customer than the mainstream alternative – and will do so in a more timely and cost-efficient manner.

Maximize simplicity and maintainability. Few will argue the virtues of the KISS principle, and with good reason. Simplicity of design is often at the heart of a long-lasting success story. Simplicity reduces the 'clutter' and focuses on the most important aspects of a product or solution, making sure these most-satisfying attributes are solid and on target. Proper simplification of design minimizes the quantity and/or variation of details without sacrificing functionality. By its nature, this reduction of unique 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. The result is a solid, well-documented product that can be quickly re-deployed elsewhere with low effort and risk. As a primary tenet of object-oriented design, re-use is a solid expectation of any properly executed project which utilizes its methods.

Optimize the whole rather than the parts. It seems logical that by fully optimizing each part of a system, the system is in turn optimized. This can be true to some extent, but individual optimization ignores the needs of the system as a whole and by definition 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. This explains why use of generic objects produces a better overall solution, even when the generic object may contain common denominator functionality that isn't required by each unique function to which it's applied.

Provide support for frequent software verification. If a system commissioning is part of your recent memory, you don't need to be told about the need to sometimes simulate code functionality without the aid of real process conditions. This is especially true when testing abnormal situations, since creating the abnormal condition could be detrimental to equipment or personnel safety. Simulation functionality, if designed into the code, permits testing the expected response to a condition without having to create the actual condition.

Adding temporary code for the purpose of testing is also an option, since the temporary part can be removed after commissioning. But what if testing is required more often? Safety standards dictate that any change made to a system which could possibly affect safety functionality necessitates re-testing of all safety functions. Object-oriented components simplify this requirement, since adding simulation capabilities to each object in a class library is an easily accomplished task; and since that functionality is hidden behind the object interface, it doesn't add to the visible code that a technician or engineer must search through while troubleshooting.

Support safety integration. In addition to re-testing requirements, safety standards impose the need for reliable mechanisms for manipulating process or equipment actions when adverse conditions are detected. Reliability is key, 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. As before, objects easily facilitate this capability when designed with a configurable override response feature and a simple, consistent and reliable mechanism for triggering it.

Integrate project documentation. Everyone knows how much information is collected during the execution of a process control project. A mound of documentation containing details about equipment and software functionality is collected or generated during design and is used extensively during commissioning, but what happens to it afterward? It is probably shoved into a cabinet and forgotten until some problem arises. When it's needed again, it's likely that important details have faded from memory, and the once-fresh documentation can be less than the efficient reference it was – assuming that it's even still accurate. If design documentation is integrated into the system in the form of an online reference, chances are it will be maintained better and will be accessed with greater ease.

Page 2 of 6 1 | 2 | 3 | 4 | 5 | 6 View on one page
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