Savannah River shifts from manual to automation
One reason it’s hard to make big changes is they often come with a big scoop of self-consciousness. So, while everyone else seems to be implementing more sophisticated automation and controls, it can feel embarrassing to move some processes from manual to automation for the first time.
No worries. The trick is to be brave, focus on what’s best for each process, organization and its end users, and remember that everyone else has made difficult transitions. For instance, 40-year-old Savannah River Mission Completion’s main job is converting “radioactive soup” into glass for long-term storage, and Jim Coleman, advisory engineer at Savannah River Mission Completion (SRMC), reported at Emerson Exchange that his organization’s been migrating from some of the manual and paper-based practices it uses to manage the water and wastewater applications that supports its environmental cleanup.
Soup to glass needs water
SRMC is processing 36 million gallons of this radioactive waste, located in 51 tanks that each holds more than 1 million gallons. This tank farm is located at the U.S. Dept. of Energy’s Savannah River Site (SRS) near Aiken, South Carolina. The original mission of the 70-year-old, 310-square-mile facility was producing and replenishing material for nuclear weapons, but its assignment in recent years has been supporting SRS’s legacy cleanup project that’s expected to take another 15 years.
To render the soup inert, SRMC moves it to a production canyon in a building with 1-foot-thick walls and no on-site operators. The waste is mixed with sand, melted into glass and put into 10-foot-tall cylinders that each weigh 5,000 lb. This conversion process requires SRMC to:
- operate floor drains, catch tanks, steam condensers and washers
- complete about 800 manual transfers between tanks and other devices
- clear strainers on the drains that can get clogged with gook from multiple locations.
The “doing stuff” actions carried out by its agitators, valves, pumps, tanks and the DeltaV distributed control system (DCS) that controls them are bookended by paper permissions before they can operate and more paper reports to document their performance.
Aid from a simpler HMI
Coleman reported that SRMC recently began automating some of the water/wastewater applications that support its nuclear-waste conversion process due to increasing error and loss of expertise.
“We were seeing more boo-boos in our processes and decided we needed to remove some from manual and automate them to help our operators,” said Coleman. “All of the original, veteran operators had long since retired, and we wanted to develop a transfer assistant (TA) that could work with DeltaV, which we’ve been working with for 21 years. We started with Version 5, and now we’re using Version 14, which is the latest.”
SRMC’s new digital, automated transfer assistant would concentrate mainly on the “doing stuff” and documentation sections of its water/wastewater processes. The new TA and its functions were developed in Emerson’s Operations Graphics package software.
“We also wanted to clean up our HMI graphics, and have one graphic screen per transfer operation, instead of the multiple transfers per graphic we had previously,” explained Coleman. “This would help our operators understand what was going on in a snap.”
Coleman added that he and SRMC wanted a one-stop-shop of basic components for the transfer assistant, including signal and parameters characterized by how far, how much and other essential questions. It would also need to calculate mass balances, list what to resolve before hitting the go button and automatically generate required reports. “We needed it to inform users what must be true to proceed with their operations and have a reasonable chance of success,” said Coleman.
Preserve and automate best practices
To get its staff to accept its automated TA, Coleman reported it would have to maintain the same look and feel as the existing HMIs and use the familiar faceplates and details as much as possible. These include faceplates with standard selectors, such as stop/go buttons. The details are similar to earlier counterparts, but they’ve also added two new elements for landing point help and ListView funcions. In general, ListView displays lists to users and is part of the Visual Basic for Applications (VBA) software in all Microsoft Office products.
“Many of our operators have been using the same on-screen displays for 20 years, and they don’t want to change,” said Coleman. “There had to be something in it for them. Likewise, the new assistant’s underlying code also had to be enough like existing code, so it wouldn’t throw our developers for a loop. The magic of our new TA is it shows detailed data via ListView on the displays, enables one transfer per graphic, generates printed reports and can’t start a process without an assurance of success. The best part is anyone can do this.”
To formulate the code for its TA or another type of display-based assistant tool, Coleman used Control Studio software for SRMC’s highly documented code for items, such as level parameters and logs of changes. Its developers use standard selection logic to pick two to eight items for functions they want to perform, and they decide which chunk of code to run, such as a command-driven module or a bookkeeping function. “Instead of writing code to a screen, our software writes it to a parameter and then the screen reads that parameter,” explained Coleman. “These lists of parameters are the link between performance modules and ListView on the graphic.”
SRMC’s developers can also check pre-starts before interlocks during transfers, as well as compare contemplated actions to what’s been done before, decide what to do and use standard code to populate the parameters. They can even address sequential function chart (SFC) data that can’t fit onto typical displays and fill out the parameters for getting that data onto displays and reports. Also, Emerson has a ListView function that can move parameters from modules to ListView, which allows Microsoft to move it to DeltaV or elsewhere.
To generate reports, Coleman advised users to maintain their data in the Module/Report/Data/ParameterName format, generate their reports from data and then display, print, store and retrieve it as needed. He added that SRMC’s operators and managers don’t want reports displayed as Microsoft Word or Excel files or as Adobe PDF files, and he recommended using an HTML viewer and opening files with Notepad software.
“This has been a big help because all our files look the same now,” added Coleman. “All this code is in the user.fxs file and lets us use one piece of it for all our reports. We can also add a trend button to the screen and employ a VBA script that uses an Emerson function to make a chart.”
Coleman added that SRMC will likely add similar automated assistants to about 50 other transfer processes. “Where our old graphics had multiple transfers per screen and were cluttered with unused items that contributed to operator errors, we now have one transfer per screen,” concluded Coleman. “The benefits of implementing our TA is we’ve reduced errors in our transfers, freed our operators and achieved more consistent documentation—and again, anyone can do it.
