T.C. Ridgeway, Inc. (TCRI) is not a NDT
company, but is very familiar with the NDT community that services paper
mills. Our primary function is to assist the mill engineer in
understanding what the lab’s UT inspection data is saying about his
Recovery Boilers. A historical review will shed some light on what part
TCRI plays in the overall process.



During the early 1970's when
the UT inspection of Recovery Boilers started ramping up, computers did
not exist in the general public. To inspect a boiler, the UT technicians
operated as a pair or two-man crew. One technician would place the
transducer on the boiler tube and interpret the oscilloscope to get a
thickness reading, which he verbally called out. The assistant
technician would write the UT readings on a pre-printed form that he had
on a clipboard. The form included the paper company name, mill name,
boiler name, inspection date, boiler section and the elevation being
inspected. It had dozens of little blocks where the UT readings were to
be written. By the end of the inspection, there were hundreds if not
thousands of pages of just numbers that came out of the boiler. Those
dirty pages were then given to the NDT lab's secretary who simply typed
the UT readings onto clean forms, all of which went into a three-ring
binder. That was the UT inspection report the NDT labs gave to the mill
engineers back then. It was nothing more than thousands of pages of raw
numbers.



That type of inspection report presented a major
problem for the mill engineer. His goal was to understand what the data
was saying about his boiler. He soon realized that looking through
thousands of number was nearly an impossible task. Therefore he asked
the NDT labs to use a magic marker, and in the printed report, highlight
the UT readings that he needed to be concerned about. Keep in mind that
computers and color printers did not exist at that time in history. It
was a laborious task, but the labs started producing reports that were
prepared on an electric typewriter and where the readings of concern
were manually "flagged" with a magic marker. That was the standard
report the NDT community supplied for years.



When the first
"desk top" computers arrived in the late 1970's, things started to get
exciting in the UT Reporting field. The goal was to eliminate the
electric typewriter and bring in the computer keyboard. The secretary
would use the technician's dirty UT data sheets and would enter the
readings into a crude software package. Using her colorless dot-matrix
printer, she would be able to print the data as many times as necessary.
However, the report was still just raw numbers and manual flagging with
a magic marker was still required. The NDT community was slowly moving
into the digital reporting world for boiler examinations. Before that
time in history, the only time the term "digital examination" was
mention was in the proctologist's office.



By the time the early
1980's arrived, the three-color dot-matrix printers had appeared and the
"Reporting Race" between the NDT labs was on. While using commercially
available software, each lab would use their computer and color printer
to improve their UT reporting capabilities. The printed Boiler Report
itself became a significant marketing tool. Each lab hoped the mill
engineer (who wanted a good UT report) would give them the boiler job
because of the lab's report. The reports became more than just "raw"
data. They started to become "informational" data. Things like multiple
colors and the average UT thickness per elevation were being included in
the ever-encompassing reports. Because of the vast quantity of UT
readings, the labs soon realized the off-the-shelf programs like Lotus
and Excel did not have the capabilities needed to further enhance UT
data reporting. Therefore, programmers were hired and given the task to
create the most capable and most impressive color report the labs could
offer to their clients. The race was on and this played out a numbers of
times by many labs. The resulting programs were all different
internally and written in different software languages. These programs
did specific task very well and produced very good boiler UT inspection
reports. The computer world calls them "Expert Systems". Keep in mind,
these were still just "data reporting" software packages. The
technicians were still writing the data on paper and it was then
manually entered into the program by the office secretary or computer
staff.



The mid, to late 1980's brought in the UT data loggers.
They were supposed to make things simpler and easier. Just the opposite
was true! The level of complexity to conduct the UT inspection went up
dramatically. Because the software that came with the logger was not
satisfactory, the labs modified their own "data reporting" software to
become "data acquisition" software as well. This meant the individual
Expert Systems started talking directly to the loggers. The labs were
then totally in the new digital world and storing data on hard drives
somewhere.



In 1985, I speculated what the mill engineer would
want next and I saw a train wreck in the making. It made sense to do
something analytical with all of the UT data that was being stored on
the lab's hard drives. As specified in Volume 1 of the "American Paper
Institute, Recovery Boiler Reference Manual", the mill engineer would
want to mathematically trend the UT data. Trending gives him a rate of
metal loss and therefore he can forecast the future condition of the
boiler. A mill engineer's dream. Unfortunately, he still had to deal
with the mill's purchasing agent and at times was forced to use
different NDT labs to conduct the boiler inspections. That means the UT
data was going to be coming to the mill engineer from different Expert
Systems over the many years that are needed to accurately trend data. As
previously mentioned, each Expert System had its own file structure and
by design did not talk with a competing system. This was a
real problem for the mill engineer. He had a lot of UT data from
different systems, none of which will work with data from a competing
system. I saw there was a need for a "Standard" file structure. The mill
engineers could ask the labs to modify their software such that it
produces data files that comply with the standard. In order for the labs
to agree, the standard would need to be developed and published by a
third party that was not a competing NDT lab. Thus, TCRI was created.



TCRI
came onto the scene in early 1985 and was not the type of company most
people thought a software company would be. We only did one thing and
that was to be at the boiler shutdown to qualify the UT data as it came
out of the boiler. By doing so, it could immediately be analyzed by our
software, triggering boiler maintenance actions if necessary. Because
analytical software for boiler data did not exist at the time, we had to
develop and write our own from scratch. After establishing a workable
data file structure, we wrote our own Expert System and referred to it
as the "Technical Database System" or the TDS. The file structure became
the "Standard" and was given to the NDT labs so they could produce TDS
type files from their already existing systems. At the request of their
paper mill clients, the labs begrudgingly modified their software to
produce TDS type UT data files. The TDS as well as the lab's software
have evolved over the years.



The TDS does four primary
functions. First, it is a "data acquisition" system. That means it
creates UT work assignments and transfers those assignments to the
logger. After the technician performs the inspection in the boiler, the
assignment that now contains UT data is transferred back to the TDS. The
second function of the TDS is that it is a "data reporting" system.
That means it produces large multi-color prints of the UT data in a
variety of ways. The prints are referred to as "Static Images" and
pertain to a specific inspection date. The third function of the TDS is
that it is a "data analysis" system. That means that hundreds of
thousands of UT readings from many inspections by different labs, all
come together precisely to yield accurate mathematical trending of tube
metal loss. Every individual UT location on the boiler tubes has a rate
of metal loss calculated. Once the data is in the system, the advanced
calculations and projections happen in just seconds. It truly empowers
the mill engineer when it comes to the understanding of his boiler. The
fourth function of the TDS is for it to be a "data archiving" system
that stores all of the data in a manner that enables immediate access by
the end user. That means the engineer does not need to know the details
of how the software works or in which folders the UT data is stored. He
answers several simple questions in boiler terms and he is
automatically taken to the data he is looking for. Once there, he can
slice and dice the data in a variety of ways with different software
routines. These routines are not just bells and whistles, but are real
engineering and analytical tools. The system also deals with the data
that originates from the Mud Drum inspection probes. The probes
automatically capture millions of UT readings. When the lab finishes the
inspection inside the Mud Drum, they give us the data so the TDS can
display 3D images with it. The TDS almost sounds like science fiction.
It is real, and is the results of a 6.4 million dollar and twenty-five
year investment. The labs have also spent vast amounts of money
perfecting their own expert systems. The latest boiler reporting system
being developed by an NDT lab, is the product of five years of software
research and a four million dollar investment. By definition, the
software packages that were designed for UT inspections of recovery
boilers are very expensive to develop and maintain.



So much for
the historical prospective. I wrote it so you have an understanding of
where things are today concerning the computer side of the Recovery
boiler UT inspections. The question now is how does the NDT lab get
their data into the TDS format. That is where the TCRI Compatibility
document comes into play. The document explains the Standard file
structure and what the labs need to do to get the data in the mill's
database.

Tom Ridgeway