With assistance from those who use the system every day, Mueller and his team established the following nine criteria and then asked those who use and maintain the system to rank the criteria in order of importance. Heres the list (not in order of importance).
(Click here to see figure 2)
- Batch recipe capabilities
- Installed base presence within National Starch
- Legacy control platform hardware utilization
- Open communications standard
- Operator friendliness
- Overall capability
- Program conversion/reuse
- Programmer friendliness.
Following this effort, three major PAS manufactures were invited to make presentations to address the nine focus points specifically. Following a thorough review of each suppliers offering, the team unanimously agreed that Siemens Simatic PCS 7 (https://pcs.khe.siemens.com/index.aspx?nr=1075) was the most appropriate solution supplier for their processes.
Mueller adds, We are systematically continuing to implement our modernization plan and are quite pleased with the operational improvements we have achieved with the new system. When we compare our past operational performance to what we are achieving now, we have improved our production time by 50 percent.
Though each of these projects involved different processes and different PAS solutions, each shares a common theme: Each company each invested the resources necessary to define, prioritize, evaluate, select, plan and execute a robust PAS retirement and modernization plan.
Wisdom from the Experts
During the past twenty-or-so years, every major PAS manufacturer has introduced at least one new system that resulted in making at least one old system obsolete, which means that manufacturers have been involved in hundreds, perhaps thousands, of PAS modernization projects, and they have learned a lot.
When asked about the lessons learned as a result of retirement/modernization projects, manufacturers were quite candid and indicated that with few exceptions, there is not much difference between modernizing systems from the same manufacturer verses modernizing systems from different manufacturers.
Ken Keiser, a migration specialist with Siemens Energy & Automation (www.sea.siemens.com), shared a relevant lesson about why it is important to understand user needs and expectations. Keiser explained that despite all the new features available in a recent modernization project, the operators insisted the graphics should not be changed.
The old system had numbers embedded in the graphics that corresponded to specific keyboard numbers, and the operators really liked that. Following a few meetings and prototypes, we were able to provide the operators with a look and feel they were comfortable with. What we learned is that, even though an old generation of graphics can be automatically converted to work on the new system, that,does not always mean it still makes sense. You should always include time and schedule to re-engineer converted entities, explains Keiser.
Yokogawa (www.yokogawa.com/us/) migration engineer, Lisa Faught, adds, Never underestimate the value of having the operators involved early in the project. Having the operators on board and familiar with the new graphics can go a long way toward reducing startup stress.
Following along with Keisers sage advice, during discussions with PAS manufacturers, users will be told how the manufacturer has developed entire libraries of conversion tools that they can use to save time and reduce errors. While that sounds good, savvy users will ask two very important questions: 1) Specifically, how was the conversion tool its self validated? and 2) Is the conversion tool under strict change control procedures?
Remember, control systems are programmed, often using high-level languages. This frequently equates to having ten different programmers implement the same control strategy ten different ways. If the project schedule is based on spot checks of the converted software, you will want some serious assurances that the manufacturers conversion software tools are fully capable of ensuring that the control strategy that goes into the tool is the same control strategy that comes out. Otherwise you may be debugging your control strategies at start-up.
To illustrate the point, Faught shares, I had one project where one system used structures and pointers, like C language, and the replacement system did not. The conversion tool could not handle the differences, so we had to completely restructure the batch logic and variables.
And lest you think these sorts of snafus are confined to complex control strategies, think again. Ken Keiser confided how a database conversion tool failed to take into account that early database configurations included an optional field that later became a required field. Before the software conversion tool would work, entries had to be included in each missing field. The lesson learned, says Keiser, is just because the old and new system come from the same vendor, dont assume that the databases are compatible or easily converted.
Echoing Keisers thoughts is Graham Bennett, senior migration consultant with Invensys Process Systems (http://ips.invensys.com/), who adds a few caveats of his own. Also consider the vendors ability to convert another vendors database information into the required structure. You will want assurances that they have proven automated software conversion tools and in-house experience with this specific conversion (i.e., system A to system D). Bennett suggests.