Mississippi River Corporation (MRC) operates a 400 ton/day repulping and de-inking facility in
Figure 1: Making Wet Lap
Recycled paper is re-pulped, de-inked
and sold again as "wet lap."
Over time, MRC’s distributed control system underwent numerous hardware and software additions and modifications to bring more areas of the plant under the scope of the distributed control system (DCS). All of these projects were based on expanding or developing the original HMI on its Windows 95 platform. Although it withstood almost a decade of continual upgrades, eventually the pulp processor’s control system could not meet the company’s performance requirements. During that period, the original HMI software vender also went out of business and failed to transfer the intellectual property and support for the HMI MRC had relied on for so many years.
It was high time for an upgrade. After all due diligence, MRC decided to migrate the old system to Siemens’ PCS 7 OS. Besides delivering contemporary levels of process control, the new HMI technology had the ability to communicate with the MRC’s legacy APACS+ control hardware without modifiaction (Figure 2).
Figure 2: New Into Old
MRC's decade-old hardware forms the
backbone of the new Siemens system.
A Phased Approach, Naturally
To help spread capital outlay over a longer period, MRC tasked RSH Engineering Inc., a control systems integrator based in
Another road block soon presented itself. The existing configuration contained no HMI comments, which are used to automatically create the HMI tag database from the controller configuration. Every sheet in the controller configuration would need to be modified to add the appropriate HMI comments in order for database automation to work. In addition, there was no system documentation, and the PC hardware platform was unstable.
Phase 1 focused on auditing of the system to thoroughly document it and identify a workable path forward. RSH approached the migration from two directions: from the HMI side, and the APACS+ configuration side. The existing HMI had to be completely documented to assure that nothing was missed in the conversion process. First on the conversion list was the "com unit" followed by the APACS+ controller paths. RSH also dumped the HMI’s database in a text format to generate more easily manipulated Excel databases.
The MRC plant configuration contained three distinct operational databases connected to seven non-redundant APACS+ controllers. Each database was completely independent of the others, though some information from specific controllers was available in more than one database. The existing HMI databases were broken down into 10 separate Excel databases: three multi point, three single point, two calculation point, and two constant point.
Using the data extracted from the existing HMI’s multiple components, RSH built a complete spreadsheet mapping the connection between the HMI and its respective controllers. The information included connection path details, point descriptions, point ranges, HMI resident alarms, point-attribute level connections, and HMI faceplate-to-controller type mapping.
The point-attribute level mapping was especially important information, as the existing HMI needed to be kept operational through the checkout stage for each process area. Based upon the initial review of the APACS+ configuration, RSH determined that the old HMI’s point-attribute mapping would also require modification to match the APACS+ nub-name modifications required by PCS 7 OS. The integrator used the Excel databases to develop the format for the required HMI comments.
Every configuration component needed to be modified, all derived blocks needed to be brought up to the current version (rev. 4.5) of Siemens 4-mation software and the nub-naming convention problem needed to be addressed. It was not economically practical to bring everything back to a standard "as shipped" convention, so RSH adopted a hybrid approach to move the configuration toward the standard while minimizing re-engineering of the controller configuration. This approach took advantage of the new system’s ability to create custom-defined type templates to match the "nearly" standard controller configuration.
Complication Times Eight
Complicating this issue was the existence of eight different versions of the External-set PID controller, all of which differed from the standard. This required eight different levels of modification to bring these controllers close enough to one another to allow a "single" custom-defined type to be developed for new HMI’s OS. There were also custom motor controllers for reversing motors, and several versions of block valve controllers, including a controller for automated valves with no limit-switch feedback.
In all, the numerous custom components were reduced to seven new custom-derived types, and their matching block icons, and faceplates. Several existing HMI’s custom faceplates were determined to be unnecessary, and their functionality was integrated into the appropriate PCS 7 OS process graphic.
When Phase 1 concluded, RSH conducted further cost analysis and recommended completing the balance of the conversion in a single phase with a single checkout and startup. This phase constituted the addition of HMI comments to the existing controller configurations, developing custom OS components and project database, and recreating the process graphics.
Seven for PCS 7
Because the APACS+ system was customized, RSH needed to develop seven custom-defined type templates, block icons, and faceplates. Fortunately, RSH was able to create the custom components by modifying standard components.
RSH prepared a test APACS+ configuration containing a set of the custom-derived blocks and matching OS components. Each block was updated to rev. 4.5. Next, RSH determined which data from the controller was going to be brought up to the HMI.
Note that this path mapping information is specified in the defined-type templates, and due to its design, there was considerable flexibility in deciding where to make the required modifications. In some cases, RSH renamed the derived block nubs in the controller to match the standards, and in others they revised the path information in the defined-type template to point to a different parameter. Wherever possible, the "standard" OS tag naming convention was retained in order to minimize the amount of modification required to the block icon and faceplate components.
RSH created a test controller configuration in an APACS+ control simulator environment, along with an OS project to run on the engineering station for testing and debugging. This allowed a step-by-step development of individual components while assuring that each step was functional before moving on to the next. Siemens shipped its APDIAG a debugging tool with the new HMI’s OS to identify problems with the custom faceplates.
From the beginning RSH understood that the bulk of the work would take place in the APACS+ controllers, and decided to modify and import the controller configurations one at a time. Due to another process addition occurring parallel to the HMI upgrade project, the first controller to be modified was a unit located where the new process was being added.
RSH modified the controller’s configuration, and imported it into the HMI’s OS using the database automation tool, and then returned the offline configuration to MRC so the new process configuration could be added. This controller would be reviewed again after the other six controllers were completed, and its additions brought into the new system’s OS.
RSH modified the APACS+ controller configurations using the Excel databases as formal checklists for each step, and various reports available from within 4-mation detailing derived block types, locations, and softlist parameters for user-defined function blocks (UDFBs).
A large number of the blocks requiring nub-name modification were UDFBs. Because modifying a UDFB structure requires deleting every instance of the UDFB type, RSH needed to recreate every UDFB instance along with its softlist parameters after modification.
In addition, the blocks required significant internal modification. The rev. 4.5 standard makes extensive use of hold blocks for engineering units, process descriptions, start and stop times for motor control blocks, and valve travel times. These blocks only had to be added once to each UDFB type, but required the specific values to be configured for every instance of the UDFB.
Another challenge was finding enough space in the configuration to locate the large number of HMI comments required for local variables. These comments needed to be located on the sheet where they were defined, and in many cases there was no room for the quantity required. RSH used non-boolean actions as a holder for the HMI comments, which worked very well.
Best Practices
MRC purchased standard, off-the-shelf PC hardware. The integration of the OS software proceeded smoothly after the software installation was complete, and all computers were imaged to CD-ROMs to facilitate any required software repair during project implementation. A separate partition was created on each machine for the OS software keys so that they would be safe from damage by utility software.
The database automation tool examines an offline APACS+ controller configuration for HMI comments and populates a list with the tags. The appropriate block icon is automatically added to the process graphic by directly assigning derived block types to a specific process graphic. As each APACS+ controller modification was completed, the database automation tool was run to build that portion of the OS database, which enabled RSH to find and repair mistakes in small steps.
From Text Dump to Database
The existing HMI software permitted a text dump from each graphic. As mentioned, this text was imported into Excel and massaged into a data set that was used to load the appropriate APACS+ controller tags into the correct OS graphic in the database automation setup. RSH reviewed all existing HMI graphics for connections to other graphics, and developed a process graphic navigation structure. To document the functionality of the existing graphics and recreate the images/graphics in the new OS, RSH used the Excel databases and a running copy of the old OS. This part of the effort that took the project team eight weeks to complete.
MRC performed thorough reviews of the existing graphics to update them and eliminate unnecessary components. As the graphics reviews progressed, MRC determined that several contained too much information and recommended splitting those displays. By the time the OS implementation was finished, the number of graphics grew from 70 to 75.
Changing the alarming methodology from HMI-based alarming to controller-based alarming proved to be a major challenge. They had to move the alarm determination from the HMI, back down to the controller, implementing all discrete, analog, motor failure, and Block Valve failure alarms within the APACS+ configuration. They documented all existing HMI alarms using Excel spreadsheets, before re-creating them in the APACS+ controllers. The alarm indications were subsequently brought back up to the OS from the APACS+ controllers, assigned priorities, and annunciated in the HMI’s OS.
In addition to recreating the alarms, RSH found numerous alarms in the existing configuration that were no longer required. They performed a sheet-by-sheet examination of the entire configuration to enable and configure the desired alarms and disable unnecessary alarms. In addition, some alarm blocks were used for interlocking, but not desired as operator alarms, which required the addition of alarm blocks specifically for interlocking. Once the required alarms had been located and properly configured, they assigned the priorities in DBA, and propagated the database again.
RSH installed the DCS network and HMI hardware on site during a normal two-day maintenance outagethe first day, hardware was set up and verified network functionality, and the second day they reloaded all of the APACS+ controllers with the modified configuration and connected the new servers to the existing MBUS network.
The last step required was to modify the existing HMI OS point-attribute mapping to match the nub-name modifications made in the controller configurations. Prompting this step was the need to bring the plant back online with the existing HMI, and then perform the checkout of the new OS while the plant was in production.
Once the plant was operational, RSH checked the database and the OS pictures/graphics. The plant operators became highly motivated when they saw the new graphics and began to immediately operate from the new HMI, reverting to the old system only when problems needding debugging surfaced. No formal training outside the control room was needed. The operators quickly became familiar with the new system, and RSH was able to find and fix the problems much faster.
MRC’s system migration was completed in approximately 11 months, with a three-month delay between phases 1 and 2. The conversion did not halt production, and anything project related that did require downtime was accomplished during scheduled maintenance outages.
Olan Atherton is control systems engineer for RSH Engineering, Inc., based in Monroe, La. He has more than 20 years of experience in various process control industries, including pulp and paper, chemical, metals and mining, petrochemical and aerospace. He has worked for both operating companies and consulting engineering firms implementing control systems for green field applications and retrofit/upgrades of existing operating facilities using DCSs and PLCs.
