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