8 Ways to Improve Control System Projects

KEY WORDS

Process control systems

Human-machine interface software

Control software

Operator interface software

Productivity, management, and control

Sidebars: Follow These Steps to Control System Project Success

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.

1 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.

2 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 fatigue and irritation. Avoid the temptation to cram too much information onto a display.

3 Test software intelligently

Try to break the software: exception handling is key. For example, when testing dialog boxes, try to enter nonsense symbols instead of valve tags or setpoints. Open more windows than recommended. The operating environment is different than the programming environment; take into account that multiple keys will be hit faster than expected at exactly the wrong time.

Real results are best. If testing a control system and recording results, use actual tag numbers, verbatim messages, and detailed descriptions. This approach makes testing traceable and repeatable, and is required in some industries.

Consider customer requirements. For example, before testing a PID controller, agree whether a template, a single instance, or every instance needs to be tested. Some customers may not want templates of PID controllers tested. They may view this activity as a waste of project monies. A review of standard QA procedures should answer this question.

Remember that a process control software project is not just about the software. Per customer agreement, some stage of testing should involve a small team that checks each input and output terminal and simulates and measures results. Loop checking after installation is much easier, because most problems will be isolated to the field. 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. Open both FO and FC valves. Check screen entities against the I/O list.

4 Let customers own the documents

Turnkey projects have certain advantages, but can cost the end customer more if not managed properly. Without customer ownership, the control system programmer must interact with multiple points of contact to try to resolve changes and clarify questions. The end customer, with knowledge of all aspects of the project, acts as a filter.

For example, screen graphics are often drawn from P&IDs. These documents undergo several revisions during the course of plant engineering and construction, usually in tandem with control system engineering. 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. Keeping the customer in control can ensure higher quality. Software development is highly nonlinear, and involving multiple parties slows a software project considerably.

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. Developers should periodically check schedules with the operating company to ensure that engineering requirements do not conflict with their operating requirements. It is acutely embarrassing to hold up production when your supposedly simple change will not compile and a product shipment is delayed. If facsimile terminals and control systems are to be used for testing, the end customer should be made aware of it.

6 Link with Customer Service

Sometimes a user’s complaint call is actually a favor for the software developer. Respect the fact that just by operating, the control system owner performs testing that is expensive for them and cheap for the configurer. Operations staff sits at the control system constantly and functions as a real-time bug-catcher. 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.

7 Get participants to ‘buy in’

If the software upgrade is small and has few effects, a simple memo to those involved (IT, Operations, Engineering) may be all that is required before the change is made. Consider degree: no one likes being surprised with a totally new environment. 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. In a batch process, an upgrade or change can be performed quietly; in a continuous process, extra precautions must be taken.

8 Wait for upgrades, service packs

Engineering a control system is not a trivial project. It will typically occupy many months. Operating system upgrades and vendor upgrades will certainly occur during the project scope. Wait until after important milestones to perform upgrades. Such planning makes it easier to isolate problems associated with an upgrade.

Comments? E-mail jkatzel@reedbusiness.com

Author Information

Robert A. Dunlap is an MBA candidate at University of Texas (Austin).

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. Here are eight steps to take:

Set expectations before traveling to or visiting a site.

Emphasize the system’s graphic interface; operators spend much of their time in front of a screen.

Test software intelligently; if it can happen, it probably will.

Remember the end customer should own the I/O lists, P&IDs, and other documents; keep the customer in control.

If the actual machine needs to be tested, be sure it is available and accessible.

Connect with the customer service staff; they can be a wealth of information.

Encourage all involved to buy into the project by keeping them informed and soliciting their input.

Wait until after critical milestones to perform upgrades.

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our WTWH Media editorial team and getting the recognition you and your company deserve. Click here to start this process.