8 Ways to Improve Control System Projects

Robert A. Dunlap, University of Texas Control Engineering April 1, 2003

Process control systems are growing more powerful and more complex. And in the future they are expected to integrate into plant- and enterprise-wide systems to an ever-greater degree. The repercussions of these developments are significant: the net benefits a well-engineered process control system can deliver are large. Conversely, startup and operational time lost through ineffective systems can be very expensive to recoup. Poorly engineered or slow systems increase operator fatigue and can be dangerous. Control system engineering should not exist apart from overall project and enterprise business plans. Here are some ways to avoid traps in control system engineering projects.


Communicate before a visit

Develop a visit plan and communicate it to all involved before the visit. For example, does the client expect a demonstration of data passed to SAP modules? Will a list of XML tags be submitted and agreed upon? Include requirements before travel so that the other party has ample time for setup. Is an analog phone line or conference room needed? Is the visit purely technical, or should time be allowed for a project schedule discussion? It is easy for another party to arrange to accommodate a visitor beforehand. In contrast, it is expensive and annoying to make people wait for a crucial but simple request to be fulfilled.


Emphasize operator-friendly graphics

Plant operators spend more time with the control system than anyone else. Apart from shifts outside or in the field, much or all of an operator's time is spent in front of a screen, dealing with faceplates and graphics. Therefore, make sure this aspect of programming is solid and approved/frozen first. The plant will operate without hooks to ERP, but not with dark glass in front of an operator. The unprecedented power of NT terminals allows a lot of visual noise to be programmed into displays. Complex machinery pictures, pipes with multiple colors and blink rates, and indicators that mock physical field devices look good in presentations, but increase operator

and is required in some industries. Keeping the customer in control can ensure higher quality. with knowledge of all aspects of the project. Per customer agreement. because most problems will be isolated to the field. use actual tag numbers. Developers should periodically check schedules with the operating company to ensure that engineering requirements do not conflict with their operating requirements. take into account that multiple keys will be hit faster than expected at exactly the wrong time. a single instance. the control system programmer must interact with multiple points of contact to try to resolve changes and clarify questions. Open both FO and FC valves. when testing dialog boxes. before testing a PID controller. 3 Test software intelligently Try to break the software: exception handling is key. They may view this activity as a waste of project monies. Remember that a process control software project is not just about the software. acts as a filter. 5 Find out if the actual machine is needed Certain procedures and industry-specific requirements state that the machine that will operate the plant be the one actually tested. Avoid the temptation to cram too much information onto a display. usually in tandem with control system engineering. .fatigue and irritation. try to enter nonsense symbols instead of valve tags or setpoints. screen graphics are often drawn from P&IDs. 4 Let customers own the documents Turnkey projects have certain advantages. agree whether a template. Troubleshooting control software beforehand with a small team is much more efficient than having an entire loop-checking team waiting for a programming change to be made. and involving multiple parties slows a software project considerably. verbatim messages. The end customer. Software development is highly nonlinear. For example. and detailed descriptions. A review of standard QA procedures should answer this question. Some customers may not want templates of PID controllers tested. The operating environment is different than the programming environment. It would cost the system vendor a lot of time and money to check each revision and find that only a small piping change had been made. For example. If facsimile terminals and control systems are to be used for testing. For example. some stage of testing should involve a small team that checks each input and output terminal and simulates and measures results. This approach makes testing traceable and repeatable. but can cost the end customer more if not managed properly. Loop checking after installation is much easier. These documents undergo several revisions during the course of plant engineering and construction. Check screen entities against the I/O list. Real results are best. It is acutely embarrassing to hold up production when your supposedly simple change will not compile and a product shipment is delayed. Consider customer requirements. If testing a control system and recording results. Open more windows than recommended. Without customer ownership. or every instance needs to be tested. the end customer should be made aware of it.

3. Ask operators for their input on graphics and meet with IT personnel on how best to connect to the plant's physical layer. Consider timing as well. The control system developer's Tech Service and/or Customer Service departments should be directed to flag a user's calls and copy them to the team performing that user's programming. Such planning makes it easier to isolate problems associated with an upgrade. Set expectations before traveling to or visiting a site. and other documents. Operating system upgrades and vendor upgrades will certainly occur during the project scope.com Author Information Robert A. Remember the end customer should own the I/O lists. an upgrade or change can be performed quietly. service packs Engineering a control system is not a trivial project. 2. Here are eight steps to take: 1. Operations. 7 Get participants to 'buy in' If the software upgrade is small and has few effects. keep the customer in control. Connect with the customer service staff. extra precautions must be taken. 6. . Emphasize the system's graphic interface. 7. the control system owner performs testing that is expensive for them and cheap for the configurer. Encourage all involved to buy into the project by keeping them informed and soliciting their input. they can be a wealth of information. be sure it is available and accessible. 8 Wait for upgrades. Comments? E-mail jkatzel@reedbusiness. Dunlap is an MBA candidate at University of Texas (Austin). if it can happen. Wait until after important milestones to perform upgrades. Engineering) may be all that is required before the change is made. a simple memo to those involved (IT. P&IDs. Test software intelligently. Consider degree: no one likes being surprised with a totally new environment.6 Link with Customer Service Sometimes a user's complaint call is actually a favor for the software developer. Operations staff sits at the control system constantly and functions as a real-time bug-catcher. Respect the fact that just by operating. 4. Follow These Steps to Control System Project Success Taking a few simple precautions in the early stages of project development can go a long way toward ensuring success of the effort. operators spend much of their time in front of a screen. If the actual machine needs to be tested. it probably will. In a batch process. 5. in a continuous process. It will typically occupy many months.

All Rights Reserved. Reed Business Information. .8. c 2003. a division of Reed Elsevier Inc. Wait until after critical milestones to perform upgrades.

Master your semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master your semester with Scribd & The New York Times

Cancel anytime.