If you Google
the phrase “index testing Kaplan turbines” into Google, or click this link: https://www.google.com/?gws_rd=ssl#q=Index+Testing+Kaplan+Turbines
The first few items in the Google listing will include
links to my company website, www.actuationtestequipment.com and U.S. Patent #4794544 for the Index Test Box.
Throughout the Federal Columbia River Power System,
excessive misalignment of Kaplan runner blades away from their optimum position
exists. This creates greater turbulence and shear forces in the water that
flows through these turbines. It’s flow turbulence and shear forces that kill
the downstream migrant fish that pass through the turbines.
According to an HDC Power Point presentation found on
the Internet, the Corps of Engineers only index tests and optimizes one out of
every family of turbines. That’s not exactly true, however; I have seen index
test data for McNary Units 5 and 9, Rod Wittinger had prior index testing data
on these two units, which is why he insisted my Index Test Box “proof of concept”
demonstration be done there.
The track-record of engineering projects conducted by
Corps of Engineers Hydro Design Center as detailed herein shows a series of bad
engineering designs and poor decisions that are continually overlooked and
covered-up. It is certain that if these units were all index-tested now it
would show that the gates and blades of all of these units are misaligned from
the optimum position by an unacceptable degree, and that huge increases
in revenue to the Federal Treasury could be gained by fixing them.
Many studies of fish survival at turbine passage have
been conducted. One of the more illustrative of the relationship of flow
turbulence and shear forces to fish survival is a 2002 report about similar
vertical Kaplan turbines at Wanapum dam titled: “Application of Biological Design Criteria and Computational Fluid
Dynamics to Investigate Fish Survival in Kaplan turbines.” An author of this paper was contacted in 2007 to ask
what effect the Corps’ intentional 1.0-degree blade deadband that was observed
at McNary Dam (re: Rod Wittinger,
USACE senior mechanical engineer’s report, page 6) and the 0.5-degree deadband that exists everywhere
else in GDACS blade controllers would do to the mathematical modeling, shear
force and fish mortality rate predictions presented in this report. The answer
was that it would “screw everything up” by exacerbating the flow turbulence and
increasing the shear forces, thus making the gauntlet the fish must traverse at
downstream turbine passage much more hazardous; in every test in Corps powerplants
the assumption had always been that the turbine and control systems were
“perfect” upon assurances by the Corps’ personnel. They then went on to muse,
“Where were you in 2002 when we needed to know this stuff?”
Another study about fish-passage at McNary Dam, “Evaluation of
Blade-Strike Models for Estimating the Biological Performance of Large Kaplan
Hydro Turbines” derived
several fish mortality models. When an author of this paper was contacted to
inquire, he also had presumed the turbines and control systems were perfect for
this study. If the new MGR runner design is not index-tested and optimized
individually, and the blades are not positioned within industry-accepted
nominal standards [(+/-) 1.0% deadband], the fish-mortality situation probably
will not improve. These machines must be “tuned-up” individually for best
results.
- Did the
Contracting Office negotiate and agree to a purchase price of $750,000 for
my pre-developed Copyrighted software source code that is the subject of
this struggle?
- Did my
Index Test Box (ITB) actually work?
- Did
Government personnel’s overt and covert actions attempt to prevent success
of Contract W9127N-04-D-0009?
- Were there
alterations and additions made in secret to a “modified contract” by HDC’s
Ed Miska in attempt to purloin my pre-developed, Copyrighted source code
without paying the negotiated, agreed-upon price for this software?
- And was
that contract even necessary? My Congressman engaged the services of a
lawyer that was under retainer to the U.S. House of Representatives whose
opined that it was not – the only purpose for the “modified contract” was
to create an opportunity to deceive me into signing a contract that would
compel me to give my Intellectual Property to HDC without the agreed-upon
compensation.
- Was I
bullied and my project manipulated by Ed Miska acting in the role of
Technical Lead in attempts to force me sign this altered document?
- Did Ed
Miska and Dan Perrier contrive a “zero-problem” within the ITB to GDACS
interfacing software programming, and then take the ITB to the first field
test at McNary without anyone from my company in attendance?
- Did the
second index test attempt fail due to mislabeled Winter Kennedy taps and
incorrect powerplant blueprints? Did this ever get corrected, to this day?
- Did HDC
attempt to setup another more favored contractor (Automated Control
Systems Incorporated) with a project to replicate the Index Test Box under
the guise of an “in-house/hired contractor” project to be funded by DOE
HOT?
- Was this
“in-house/hired contractor” project stopped by a DOE IG investigation?
- Did HDC
personnel attempt to co-opt the credit for creation of the ITB by claiming
to have developed it under another contract instead of buying it from my
Actuation Test Equipment Company?
- Did HDC
personnel present the output data graphs from my ITB to BPA HOT as the
work-product of HDC personnel, and then hide that fact by changing
the project’s name to Gate Blade Optimizer (GBO)?
- Was the
GBO project ultimately successful? Does it work as well as my ITB?
- Did HDC
engage two “rehired annuitants” (Dennis Erickson and Clay Fouts) and a University
of Portland Computer Science professor (Bart Rylander) to work on
HDC’s GBO?
- Per ASME
and IEEE industry accepted standards, (ASME PTC-29 & IEEE Std-125
& Std-1207) is the GDACS 3-D Cam and blade positioning system
sub-standard?
- Was there
a 1.0-degree deadband (12.9% deadband) programmed into all of the 3-D
Cams at McNary and 0.5 degree deadband (6.5% deadband) everywhere else?
- Was the
deadband at McNary reduced to 0.5 degrees as a result of my DOD IG
complaints and the DOD IG instigated blade accuracy survey in 2007?
- Is there
a 35-second deadtime programmed into the GDACS 3-D cam and blade
controllers at McNary?
- Do these
industry-accepted standards call for 1.0% deadband limits and 0.2 second
deadtime?
- Are there
HDC personnel on the ASME & IEEE committees that created these
standards, and if so, why doesn’t HDC adhere and comply with these
nominal, industry-accepted standards?
These things are all true and connected, as I shall
show herein.
==============================
My penultimate complaint in all of this was the
unilateral alteration of the Contract, in secret, by HDC’s Ed Miska to my
disadvantage during the “modified contract” process at the 1-year point in the
project in an attempt to defraud me out of my Intellectual Property (software
source code) with value placed upon it at $750,000 during Contract negotiations
with Dave Ebner - and the bullying by Ed and everyone else involved to pressure
me to sign this fraudulent document. Had I signed it, I would have forfeited
the intellectual property that I have been developing since 1985 - giving it to
the Government without the compensation that had previously been agreed upon in
the original Contract negotiations.
To my mind, the Government personnel decided they
didn’t like the terms of the original Contract anymore, so they just changed it
without my knowledge and attempted to bully me into signing this altered
document. This was base and deceitful misconduct by Government personnel.
Figure 3 Excerpt from USACE Contract W9127N-04-D-0009 shows Bench Test, Page 8
At the completion of the project, the man-caused
problems we encountered had been so troubling that Lee Sheldon prepared a memo for
the record documenting in detail everything that had happened:
In my opinion, Lee “pulled a lot of punches” to avoid
losing his rehired annuitant gig at HDC.
At many points in the course of this
project, I questioned use of the phrase, “proof of concept.” The “concept”
of automatic, unattended Constant Power index testing of Kaplan turbines
had already been “proven” beyond a doubt by the 1985 and 1987 field
tests at Clarence Cannon and PGE-PHP-2 (described below); so why was HDC
calling this a “proof of concept” test in 2005? The best answer was that, “Many in the
Government are not convinced it is possible to automatically index test a
Kaplan turbine with a computer, so a ‘proof of concept’ test is necessary”
– and “It’s our money, and that’s the way we want it.”
Looking back now, HDC’s “proof of concept” was the
prelude to a charade that would present the Index Test Box to the world as the
“brain-child” and creation of HDC’s engineers instead of something they bought
from the private sector.
Rod Wittinger told me not to publish any magazine
articles or make any presentations on the ITB because HDC manages wanted to
unveil their entire Columbia River optimization program in a grand presentation
at a trade show.
The problems started with denial of access to the
MockUp that I was supposed to use for the “bench test” specified in the
Contract. This and the new simulator constructed at my expense to replace it
the MockUp’s functionality are both documented in Lee’s original comprehensive
memo. Here is an excerpt from his report:
Figure 4 Excerpt from the first July 2006 HDC final report, page 9
Figure 5 MockUp as found in back room at ACSI
Shortly after Lee presented this report to HDC
managers, it was confiscated, impounded, and Lee was directed not to give a
copy of it to anyone (specifically me) and to write another report in
the same vein for general dissemination (to BPA HOT), but this time praising
the Corps. HDC’s lawyers impounded the original report to keep it out of
circulation (i.e. away from me). It took several FOIA requests and the
intervention of DOE IG to finally acquire this factually accurate
report, months later.
The above excerpt and other information unfavorable to
the Corps were deleted to produce the second “whitewashed” memo for
distribution to the HOT:
A REPORT ON THE PROOF OF CONCEPT DEMONSTRATION
This report describes the nature of the Index Test Box
and the Constant Power index testing method, and a brief history of how I came
into contact with HDC for this job.
Figure 6 Excerpts
from Rod Wittinger's "Memo for the Record" showing the HDC Bench
Testing prior to the December 2005 McNary field testing.
Figure 7 Excerpt from HDC Response, overview of contractor performance
This is an untrue and unacceptably harsh evaluation
with which I vehemently do not concur. Let me parse this passage
(and the rest of the HDC Response, in turn) point-by-point, and deal with this
unsavory malignment of my company, my products and myself - one topic at a
time. To identify these points as they are addressed below, yellow highlighter
and 
identify
where I’m presenting the HDC Response document’s text back to you. My comments
are in normal and italics text for emphasis.
==============================
The
statement, “Could not operate independently,” is blatantly false.
The
statement, “Could not operate unattended,” is blatantly false.
These two statements are diametrically opposed
to HDC’s own engineers’ Power Point report to DOE BPA HOT committee that was
made shortly after the Ice Harbor testing was conducted. According to an email from your Dan Ramirez to Rod Wittinger on 21 February 2006 (that was acquired from HDC under FOIA) and the
aforementioned Power Point presented by HDC (Rod, Dan and Lee Sheldon) to the
Bonneville Power Administration (BPA) Hydro Optimization Team (HOT) on 3 March 2006, (acquired from
BPA under FOIA) the problems identified at McNary had been corrected
(as far as Dan was willing and able to check them out) and that the test
data results from my ITB were:
“virtually identical to those obtained using COE data
acq system”
And that my ITB was:
“Ready for ‘unattended, automated’ data collection.”
It seems HDC’s folks said my instrument worked OK when
speaking to BPA HOT about it a few days later, and in that same meeting, they
were asking for additional funding to buy two more ITB’s from me; one with the
OPC communication for working with GDACS at Chief Joseph Dam, and another with
an analog I/O board and discreet sensors for use at Dworshack Dam.
Note: The shortcomings list in Fig 8 is incorrect;
adding transducers and sensors to ITB is actually very easy. The I/O board used
for the Winter Kennedy transducer already had 8-channels of analog input
suitable for connecting more discreet sensors; this was my original ITB
configuration in 2003 when HDC initially contacted me - so the ITB was already
setup for this “discreet sensors” configuration. The bulk of the additional
work in the contract was to add the OPC communication interface per HDC’s
directives.
Fig 8 below is a copy of the Power Point slide from a
BPA FOIA that shows these comments.
Figure 8 HDC Power Point slide from February 26, 2006 HOT Meeting
The
statement, “Could not perform an index test,” is absolutely false.
In the December 2005 field test, the most
vexing problem that prevented us from running the ITB’s preferred “Constant
Power” index testing method (which is the primary testing method that the
ITB is designed to perform) was the hydroelectric unit’s inherent instabilities
that are caused by the excessive deadband and deadtime that are
intentionally programmed into USACE’s sub-standard GDACS 3-D cams and blade
controllers.
The turbine
control equipment was designed by HDC and deployed throughout FCRPS by HDC’s
“captive supplier,” ACSI. In deference to the HDC Response statements, the ITB
perfectly executed the Constant Power testing method in 1985 and again in 1987
while I was developing this technology for Woodward Governor Company for use
with Woodward’s digital electronic 3-D cams (as described below). Systemic
problems inherent with the GDACS 3-D cam were the reason we could not perform
the “unattended index test” mentioned.
Kaplan Blade To
Gate Parallelogram Spiral
During our August 2004
visit to ACSI, after I explained the manner in which the ITB tested a unit
along the Constant Power lines of the turbine’s operating envelope, Dan Perrier
(President of ACSI) explained to Lee Sheldon and me why the Index Test Box’s
Constant Power method couldn’t work with the GDACS control systems.
Dan explained the behavior and mechanism
of the GDACS 3-D cams and how the inherent instability occurs, and why it would
prevent my Constant Power index testing method from working.
From his explanation it seemed that he
felt this was normal behavior for all Kaplan turbine governors, 3-D cams
and blade controls, instead of being a unique problem with HDC’s
self-inflicted, sub-standard GDACS 3-D cams and control systems.
Dan was trying to discourage me from
attempting to use the ITB Constant Power method to define the optimum cam
surface with his descriptions of the GDACS 3-D cam’s odd “parallelogram spiral”
motion (recounted below).
It was Dan’s assertion that the one-degree
deadband and 35-second deadtime programmed in the GDACS 3-D cam blade control
systems (that I witnessed, and Rod Wittinger documented in his McNary field
test memo) are normal for Kaplan hydroelectric turbine control systems, are the
root cause of this problem (I agreed this is a root cause) and would preclude
any Constant Power testing of these units (I also agreed it would prevent
Constant Power testing). I disagree that these deficiencies are “normal” for
hydro-turbine control systems, they are unique to the Corps Of Engineers’ control
systems.
These intentionally added blade control
system deficiencies are meant to mask inherent control system instabilities
that would make the units continuously hunt and wander during normal operation.
This unwanted motion prematurely wears out the blade mechanisms and trunion
bearings. When the trunion bearings wear out, the turbine runners start leaking
oil from the Kaplan hub into the water. It is known to me that in several
instances the USACE corrective action for this problem has been to weld the
runner blades in place at a fixed angle and remove the oil from the hub, thus
rendering these Kaplan turbines into “fixed-blade” propeller turbines. This is
disgraceful.
Dan’s explanation of the GDACS 3-D cam
behavior went like this (ref fig 9, below):
When a large
upward SetPoint change is made in power,
Starting at (a.)
on fig 9, the governor’s speed motor is activated to raise the SetPoint
by the GDACS control system,
Gates open rapidly
to get the power output up to the new SetPoint level at the constant power
curve at (b), with the desired target operating point at (e) on the on-cam
line.
Power output is
sensed by the GDACS control system, which continues opening the gates until the
generation SetPoint demand is satisfied at (b).
During this first
move, the blade to gate motion tracked the linear taper of the mechanical 2-D
cam on the gate restoring shaft of the governor, tracing the line from (a) to
(b) instead of tracking the “on-cam line” from (a) to (e) like a proper
governor and 3-D cam should.
Due to the
35-second deadtime in the blade control system, the stepper motor does not move
during the motion from (a) to (b), so the blades move only along the linear
taper of the metal 2-D cam that is mounted on the gate restoring shaft. This
causes the gates to open farther than they would have had the blade controller
been robust and accurate, and the blade angle been able to track the on-cam
curve from (a) to (e).
The blade
controller wakes-up 35 seconds later, takes note of the change in gate position
and then computes the new Ideal Blade angle, and then moves the stepping motor
to complete the blade motion to the new Ideal Blade position for the existing
gate at 75 ft head at (c) as dictated by the 3-D cam algorithm and the cam-data
surface lookup table.
When the blades
move up to this new, steeper position, power output of the unit increases
significantly, exceeding the deadband set for the power level controller in the
GDACS, so the closed loop on power in the GDACS pulls the gates back to get
power back to the SetPoint at the constant power curve that extends from (b) to
(d), and beyond.
After another
deadtime of the GDACS load feedback, the speed motor is moved again to decrease
power back down to the load SetPoint at (d). Again, the blades do not move in
unison with the gates to track the “on cam line” from (c) to (e) because of the
35-second deadtime, so the blade to gates motion tracks the linear taper of the
metal cam from (c) to (d) on the way down.
This motion
continues until the blades are within the 1.0-degree blade deadband programmed
into the Panel Mate touch screen control panel, then the blade controller stops
making corrections to blade angle.
Figure 9 Parallelogram spiral motion of Kaplan blades with GDACS 3-D cam plotted over McNary WithScreens 3-D cam profile surface.
The cause of this “rectangular spiral,” (or to better characterize the impact this
misalignment would have on flow turbulence & shear forces in the water and
on any fish passing through the turbine during this sequence, we could call it
a “rectangular death
spiral”) is the bad
dynamic behavior of the USACE designed blade actuator in the GDACS 3-D cam. To
mask this problem, the control system was desensitized by adding a 1.0-degree
deadband that prohibits blade motion if the blades are within 1.0-degree of the
Ideal Blade position. This results in a permanent and continuous 6.5% blade
position error away from the Ideal Blade position. (ASME/IEEE standard is 0.5%)
There is also an associated deadband and deadtime on power level in the GDACS
control system. These deadbands and deadtimes are a very crude method of
desensitizing the turbine control systems so the machines’ unwanted motions
don’t wear out the trunion bearings due to the inherent instabilities that the
USACE HDC GDACS 3-D cams introduced.
No commercial customer would
ever put up with such shoddy engineering practices. Only the Government could
come up with such an awful fix for a problem, call it “close enough for
Government work,” and then cover it up for 9+ years in the face of a Federal
Endangered Species lawsuit over a “fish-mortality” problem that is most
definitely negatively affected by this situation. If these were airplanes
or ships, this level of engineering malfeasance would
never be tolerated.
To minimize the consequences of this
problem, the operators change the generation SetPoint very slowly on these
units so that the 3-D cam and blade control systems can keep up. For a direct comparison,
a properly robust and accurate control system on a large Kaplan turbine should
be able to go from speed-no-load to full power in about 10 seconds - these
USACE systems in FCRPS cannot come anywhere near that level of performance.
The 1.0-degree deadband
programmed into the GDACS 3-D cam, when evaluated per the ASME PTC-29 deadband
measurement technique which sums the residual error on both sides of the
optimum cam line, becomes a 12.9% deadband. When this is added to the
anticipated 2.0% deadband from mechanical hysteresis of the blade positioning
system of these 50+ year-old machines; the deadband is about 15%.
IEEE Std-125
quantifies an acceptable deadband at 1.0%, a standard that all other
hydroturbine 3-D cam and blade control equipment suppliers meet or exceed. This
is not a mandate, however, just a guideline indicating what is reasonable and
customary throughout the industry for contracting agents (such as USACE’s
Contracting Office in Portland) to use in specifying hydroturbine control system
equipment in the acquisition documents. It is incumbent upon the Contracting
Officers to mandate that the equipment be in compliance with the
industry-accepted nominal standards.
The failure of the
Contracting Officers to include the applicable industry standards in the
acquisition documents for this equipment does not excuse the extreme
substandard condition of this equipment, especially in light of the Endangered
Species Act lawsuit regarding fish mortality in FCRPS. The Endangered Species
Act requires that only the “Best Available Science” be used – not by any
stretch of the imagination does the above-described GDACS 3-D cam blade control
system fit that description.
If other suppliers
can achieve the industry standard’s level of robustness and accuracy, why is it
that USACE is accepting such an inaccurate and unstable system from HDC and
ACSI? The consequence of this misalignment is exacerbation of the fish
mortality problem that environmentalists, Native Americans, politicians and a
Federal Judge are so upset with USACE about. It doesn’t have to be this way!
I had a professor
in college who described business relationships such as the one between HDC and
ACSI as “industrial incest.” Not a very flattering name, but quite descriptive of
what is going on. This situation was brought to Charlie Allen’s attention in a letter of October 6, 2006. HDC’s position
to me in response to that letter was that the status quo is close enough for
Government work, so I should just let it be.
In abject disagreement with the HDC Response document, my ITB actually does work. As proof of this, note that I was awarded U.S. Patent #4794544 for this new technology in
1988, because it worked, and Woodward would not have spent the $20,000 on legal fees to acquire that
patent if it had not.
After Woodward shelved the ITB in 1989, and then after
Woodward’s hydro division ultimately faltered and failed and was subsequently
sold to GE Global Systems, I quit Woodward to start the Actuation Test
Equipment Company and worked diligently on the ITB while waiting for Woodward’s
(and then GE Global System’s) patent on this instrument to expire so that I
could then take the ITB public myself.
Over dinner and drinks at a Mexican restaurant in
Umatilla, Oregon during our December 2005 Proof of Concept field test, Rod
Wittinger told Tom Murphy, Dan Ramirez, Greg Luna and myself that he had seen
the ITB in 1985 at Woodward, and then had watched the patent quietly expire 17
years later. After it expired Rod and Lee Sheldon pursued this project to
revitalize the effort to employ this viable technology on USACE’s Kaplan
turbines in FCRPS (and elsewhere). I reminded Rod that in 1985 I had recorded
in my journal that when he came to Woodward’s Governor School and saw the ITB,
that he was very skeptical of my new ITB technology - he said my journal was
accurate - and now he was a believer.
Now I see that HDC personnel’s hidden agenda in
contacting me and via this Contract had always been to wrest the ITB technology
away from me, claim it as their own creation, and then subcontract to Automated
Control Systems Incorporated to mass produce and deploy the ITB throughout
FCRPS - and then to market it into the private sector; this pattern of
Government personnel misconduct has been established and seen many times in the
past.
Just because it’s the Government doing it doesn’t make
it right.
In 2006 I learned that HDC and ACSI had been marketing
the GDACS SCADA system to South West Power Administration (SWPA); Ed Miska was
the lead contact in that sales effort. SWPA personnel told me that they chose
not to buy GDACS because they didn’t want to have Government personnel as
the service agents for their turbine control equipment.
While working in Canada earlier this year, I learned
that in the late 1990’s ACSI had been marketing the GDACS SCADA system to
Brookfield Power in Canada, with MK* (HDC liaison to ACSI), Dan Perrier and Joe
Swatosh (Dan is President of ACSI, Joe is in management there) all working in
the sales effort.
Marketing to SWPA (another U.S. Governmental agency
analogous to BPA) is not really a problem, but marketing equipment developed
with Government funding to a Canadian power company, in unfair competition
against private sector companies that must develop and market such products
at private expense, is. Who paid for everyone’s plane tickets to
Sault Ste Marie?
MK*’s company was easily found on the Internet by
“Googling” the four words “automated, control, systems & incorporated,” to
see what came up. High on the list was the Oregon
Secretary of State Business Registry Database, which had four company
names with those
four words in them.
The Google is a wonderful tool, which was not
available in 1996 when MK’s company was incorporated - just 14 months after HDC
setup their “captive supplier,” Automated Control Systems Incorporated
and hired Dan Perrier to run it for them. It was also interesting that MK’s*
company was “administratively dissolved” when I started complaining about HDC
personnel’s unethical misconduct in 2005.
When this cozy arrangement was brought to the
attention of DOD IG, the Hotline contact commented that the IG had seen this
pattern before; this setup is called a “shell company,” and is used to move money
and material around in secret - off the books. This instigated a wider
DOD IG investigation, which prompted the HDC Blade Survey in 2007 that
ultimately exposed the blade positioning inaccuracy problems and poor
“string-pot” design used for blade position feedback in the GDACS.
Please explain to me how my suspicions about HDC’s
plans for my ITB are not true, in light of the above and after reviewing the
facts I’ll be presenting below.
The ITB’s “Constant Power” testing method could not be
used on Unit 9 at McNary Dam in December 2005 because of the hydroelectric
unit’s inherent dynamic instabilities that were caused by the excessive GDACS
3-D Cam blade controller 1.0-degree deadband and the 35-second
blade controller delay, both of which were intentionally programmed
into the GDACS 3-D Cam algorithm to desensitize this control system in order to
prevent wild oscillations and excursions of blades and gates.
This unwanted motion results in premature wearing out
of the turbine blade trunion bearings. For our McNary testing, in order to
allow the ITB to work with the GDACS 3-D Cam, the GDACS 3-D Cam blade
controller deadband was reduced from 1.0 degree to 0.5 degree, but was restored
to 1.0-degree after we left; no change was made to the 35-second deadtime.
(ref: Rod Wittinger’s
“memo for the record”, page 4,
paragraph 3)
Figure 10 Excerpt from Rod's memo, page 4 pp3 citing change of deadband to 0.5 degree
The fault here that prevented the “automatic,
unattended” Constant Power index testing was the GDACS 3-D cam’s
excessive deadband and deadtime, not any problem with the ITB.
As a specialist schooled by 20 years of working
with Woodward Governor’s automatic feedback control systems such as these, it
is undeniably clear to me that USACE’s GDACS digital 3-D cam additions to these
turbine control systems are a hindrance to robust and accurate blade control
and unit stability, and are the root cause of the problems we
experienced; the sub-standard USACE blade control systems were so bad they
made it impossible to use the ITB’s most beneficial feature, the Constant
Power index testing method.
As a workaround for the sub-standard GDACS’ blade
control system, a compromise was made with Rod Wittinger. Instead of using the
ITB’s laborsaving Constant Power method to automatically index test the
unit, we would demonstrate the natural Constant Power lines in the turbine’s
operating envelope and the ITB’s ability to detect “SteadyState” operating
conditions by manually controlling the unit. By positioning the blades with the
ITB’s blade perturbation feature, and then positioning the gates by bringing
down the Woodward Governor’s gate-limit to clamp the gates in position we could
stop the machine’s incessant dithering, observe the Constant Power lines and
collect a SteadyState data point.
The SteadyState routine in the ITB software was then
used to capture the individual data points after the unit stabilized, which
took about 10-minutes at each test point.
Restating here: the problems that prevented the
automatic, unattended index testing by the Constant Power method were
the fault of USACE’s sub-standard self-inflicted GDACS 3-D cam control system,
not the ITB.
Per the IEEE & ASME industry accepted standards
the GDACS 3-D cams are all sub-standard because of the 0.5-degree deadband
programmed into all of them.
An objective evaluation of the performance of USACE’s
GDACS 3-D cam blade control equipment in accordance with these accepted
industry standards* will demonstrate this to be true.
(*ASME PTC-29, IEEE Std-125 & IEEE STD-1207)
To be fair, whether or not the ITB can run an
automatic index test is a subjective question, depending on which type of
“index test” method that you want to use. There are three ways to index test a
Kaplan turbine.
- Constant
blade, swept gate
- Constant
gate, swept blade
- Constant
power, swept gate and blade
The ITB is designed to use the Constant Power
index-testing technique, which it is most certainly capable of conducting in
an unattended manner, the truth of which was proven in the two prior
demonstrations at Clarence Cannon and PGE-PHP-2 (described below).
To make it perfectly clear - the ITB is not intended
to run a constant blade or constant gate index test. Because of
the requirement for the testing crew to constantly be coordinating changes in
flow and power with the dispatcher and water flow controlling agency, unattended
testing cannot be performed. These two methods are much less efficient
- but the ITB can still be used for the SteadyState analysis & detection
and collection of data if used in these two less-advantageous testing modes.
The Constant Power test method does not require
large swings of power or flow during the index testing, so the process of this
index testing method is transparent to normal powerplant operations.
Coordination of each test point with the control room and dispatcher are
unnecessary because the unit’s power output and flow remain constant, within
a few percent. With constant blade and constant gate testing, there are
large swings in both power and flow, so these tests cannot be run in an
unattended, automated manner due to the need for continual coordination with
the control room and dispatcher to accommodate large flow and power changes.
To explain in greater detail what a constant power
index test is - this link will take you to my as-of-yet unpublished article
about using the ITB to index test a Kaplan turbine using the “Constant
Power” index testing method. Marla
Barnes at Hydro Review said it was “too much of an advertisement for my
index test box,” and she wanted me to get the first round of data from the
index testing I’m currently working on in Canada so it can be crafted into a more
technical article presenting that test’s data results, then she’d go with it.
I’d have published with the McNary data in 2006, (using the “unit-turbine”
concept as laid out in agreements with Rod and Lee) but the problems with GDACS
3-D cams, the Government’s uncooperative, duplicitous behavior and the constant
attempts to purloin my technology prevented it. It elicited a hearty laugh when
I quipped to Rod it would be “akin to putting a party dress on a pig.”
The article shows how the Constant Power method works
using the data examples from the 1985 Clarence Cannon index testing. I have
published two articles on the subject, one in 1987 in Hydro Review, “‘Black Box’ Developed For Index Testing of Kaplan
Turbines” after the
Clarence Cannon index test, and the second in International Waterpower and Dam
Construction last year, “Testing Time for Kaplans.”
Two
Prior Successful Demonstrations
The ITB has already been used successfully to
index-test Kaplan turbines using the Constant Power method twice, once
in 1985 on the vertical Kaplan unit at the USACE Clarence Cannon plant in
Missouri and again on the vertical Kaplan unit at the Portland General Electric
PGE-PHP-2 in 1987 (results presented below).
In an April 16, 1986 memo Lee Sheldon
reported on his evaluation of the ITB’s performance in the 1985 Clarence Cannon
test. The analysis and report were undertaken in 1986 while Lee was working at
BPA. His conclusion from this analysis was:
Figure 11 Excerpt from Lee Sheldon's 1986 memo reporting on his analysis of ITB performance.
Based on this evaluation, BPA purchased an ITB in 1986 with intent to demonstrate it at the
Bonneville Dam. This plan
included giving the ITB to USACE after the testing was concluded. The
Corps declined this offer, preferring instead to build their own automatic
index-testing instrument. Data from USACE’s automatic index testing instrument
was given to Lee Sheldon for analysis in 1990. A copy of Lee’s evaluation memo is as this link. (No further information is available about this
instrument, so it is assumed that the effort failed and was abandoned.)
BPA then took the ITB to Portland General Electric’s
(PGE) Portland Hydro Plant (PHP) #2 (or “PGE-PHP-2”) for a demonstration.
According to Lee Sheldon (BPA
hydropower engineer), Terry Bauman (Woodward
Governor controls engineer) and Gary Hackett (Plant
engineer at PGE-PHP-2) the Index Test Box worked perfectly at index
testing this turbine with good correlation between ITB data results and
classical index testing method data results, with greatly reduced manpower
requirements.
An excerpt from Lee’s report shows the purpose of the
manual index test that was run using the classical methods:
Figure 12 Excerpt from Lee Sheldon's test report of Classic Method index test of PGE-PHP-2
Though possibly biased, Terry
Bauman’s conclusion to his ITB test report was very positive:
Figure 13 Excerpt from Terry Bauman's test report of ITB test of PGE-PHP-2.
Gary Hackett’s report conclusion for the ITB
demonstration test was more cut-and-dried, but still quite positive:
Figure 14 Excerpt from Gary Hackett's test report of ITB test of PGE-PHP-2.
At that point in time the ITB program’s data analysis
algorithm used only a two-pass average and standard deviation
computation to determine “SteadyState” turbine operating conditions, and the
data results were only digitized numeric values stored on an EEPROM chip. This
was only a rudimentary starting point compared to where we were in 2004 when
USACE Contract negotiations commenced. Refer to the “Screen Gallery” included with
the Appendix II software status report that was sent to HDC in 2004 to document the state of
development I had attained prior to the initiation of contract negotiation.
Since 1992 the ITB software program had been upgraded
to include a linear regression in the SteadyState algorithm at both
levels that adds the slope of a line drawn through the “center of mass” of the
collected data to the SteadyState detection algorithm, and graphical screen
displays of the index test data to show what’s happening at several steps
in the process.
Today the ITB is 5 years further along; and now
with two additional successful index tests performed at McNary and Ice Harbor
with work underway with Brookfield Power in Canada on two projects; one to
simultaneously index test three Kaplan-type bulb turbines and a single vertical
Kaplan turbine.
Contrary to the HDC Response document’s comment, when
the turbine governor and blade control systems work properly and are robust
& accurate at positioning the blades, my ITB works as intended. It
was the poor governor dynamics of the GDACS 3-D Cam and control system that
were at fault and prevented it.
Experience
at McNary and Ice Harbor
The index test box demonstration at McNary suffered
from poor governor dynamics (excessive 1.0 degree blade deadband
and 35-second blade controller time delays contributed to this problem) so that
we could not use the preferred Constant Power testing method; for the
data collection at McNary the unit could only be manually operated because of
the erratic and unstable dynamic behavior of the unit. At Ice Harbor, the ITB
was setup, turned on and then just left to run, unattended. An excerpt from Dan Ramirez’s
February 21, 2006 test report
states that:
Figure 15 Excerpt from Dan Ramirez's email to Rod Wittinger reporting on Ice Harbor ITB testing
And:
Figure 16 Excerpt from Dan Ramirez's email to Rod Wittinger reporting on Ice Harbor ITB testing
Dan told me on the phone that GMT did not install the
perturbation routine in the SoftPLC’s at Ice Harbor, which is why blade
perturbation could not be used.
It is also probable that the GDACS 3-d cam’s deadband
and deadtime make the governor dynamics at Ice Harbor no better than we saw at
McNary.
Because blade perturbation could not be used, the
unattended Constant Power index testing could not be demonstrated, but
the ITB did run unattended in the background while Dan ran his “COE
data acq” test manually. The shortcoming in this instance was that the GDACS
3-D cams did not have the perturbation interface installed in them, not the
ITB’s inability to run this test.
In support of this argument - USACE’s HOT meeting PowerPoint of September 12-13, 2006 (slide #5) indicated that “Due to governor dynamics,”
the governor dynamic behavior is a problem, and a new method of
analyzing the test data must be developed. If the Corps’ governors had worked
properly, the ITB would have been able to execute the preferred Constant
Power method and a new method of analyzing the test data would not be
necessary. The fault here was GDACS’ bad governor dynamics, not any
shortcoming of the ITB.
Perhaps it would be better and easier to fix
the governors instead.
Figure 17 Power Point slides from HDC presentation to BPA HOT Sept 12, 2006
In this excerpt from the accompanying HOT Meeting
minutes:
Figure 18 Excerpt from Sept 12 2006 HOT Meeting Minutes
Lee said that the ITB proof of concept was successful,
and a new way to develop cam curves for the Constant Power testing method has been developed by the contractor (me) –
but on the other hand - Rod is talking about “contracting difficulties.” Note
that Rod was not saying the ITB did not work properly; the stated problem was
with “contracting.”
In a subsequent HOT meeting (described later in this
letter) Ed Miska presented the graphs in this report (and claimed the method of
developing cam curves) as an HDC development.
The real contracting difficulties were that I
refused to sign-over the pre-developed, Copyrighted source code to my
ITB program to the Government before receiving payment of the $750,000 price that
was negotiated with Dave Ebner. I resisted every effort to have this
software manipulated away from me, and vehemently balked at the contract
tampering by Ed Miska in an attempt to purloin my software by fraud. I would
not call that “contracting difficulties,” I’d just call it “being fair.” Out
here in the private sector, getting paid for our work is not a trivial matter.
The fair prices and deliveries for my equipment had
previously been negotiated with Dave Ebner with the concurrence of Rod
Wittinger, Lee Sheldon and others at HDC. Dave made no secret that he was
effectively just the “middle-man,” communicating between ATECo and these men
behind the scenes at HDC during our negotiations.
What is an Index Test?
A “conventional index test” is a rigorous manual
exercise requiring 2 to 5 men that spans several days. This test procedure
requires seizing control of the turbine’s gates and blades from the governor
and then blocking them in various fixed positions. While holding everything
still, the test personnel will record forebay, tailwater, gate, blade, flow and
power signals every few seconds over several minutes, then average them to get
a single set of values, all the while dutifully watching for disturbances that
will upset the readings (such as starting and stopping adjacent units, or ships
going through the locks), and then compute relative efficiency at a variety of
gate and blade positions to determine the optimum blade to head and gate
profile. If there are any disturbances, the test point must be discarded and
repeated; the ITB does all of this automatically.
Calculating efficiency for each point, and then
plotting these points to determine the efficiency profile for the unit as each
test point is captured allows the test crew to ascertain that the test points
will bracket the optimum efficiency cam line. This will make sure that the
index testing defines the efficiency peak with a high degree of confidence by
getting data points on both sides of the peak efficiency. The live display
of the ITB does all of this automatically.
The entire Index Test Box process is not totally
automatic, however. Human intuition and judgment are still required to
determine the new cam profile from the data that the ITB collects.
To perform an index test of any type, the Index Test
Box is setup to collect data in an unattended manner, and then without any
human intervention, captures ‘SteadyState” points whenever the unit just
happens to be running steady-state during normal operation. The blade
perturbation and methodology for manipulating the machine automatically are
optional, at the discretion of the testing engineer and ATECo.
If the governor and control systems are robust and
accurate, the unit is dynamically stable and the blade perturbation feature is
enabled - then an automatic, unattended Constant Power index test can be
run. This method is preferable to all other turbine optimization methods
because of the labor savings, and because no large swings in power and flow
result, making this test method transparent to normal powerplant operations.
The Index Test Box could not do an index test at
McNary Dam using the new “Constant Power” method, but the fault was with the
USACE sub-standard governor and GDACS 3-D cam system, not any shortcomings of
the Index Test Box.
The
statement, “Could not analyze collected data,” is blatantly false.
Data_Analysis
Analysis at each data point (this process repeats
approximately every 3 seconds) consists of multiple passes of data analysis to
detect SteadyState operation, convert all values to engineering units,
normalize flow and power to a common head by the affinity laws, compute
relative efficiency, create a file name and store the data. Analysis at every
pass of the data collection algorithm as it captures data points consists of
the software program performing the following tasks:
- Measures
forebay, tailwater, gate, blade, flow and power for 200 scans (or any
number from 3 to 5000 that the operator selects),
- Computes
average value and standard deviation of this collected data,
- Perform a
linear regression on each data parameter to find the slope of a line drawn
through each data set,
- Determine
SteadyState operation by comparing the standard deviation and slope to
pre-set limits,
- If all of
the standard deviations and slopes are less than the pre-set limits, then
the point is deemed “SteadyState,” and the ITB program stores the data
point and then proceeds to the outer loop.
- The outer
loop checks to see if there are 3 or more collected data points,
- If less
than 3, return to the inner loop to measure another point, if more than 3,
proceed to the ‘SecondPass’ SteadyState analysis.
- The second
pass analysis computes the standard deviation and slope of the 3 or more
points, using the same computational algorithm (average, standard
deviation and slope) as the inner loop, and compares to a second set of
pre-set limits.
- If the
data is SteadyState, then the average values of the measured voltages are
converted to engineering units and stored.
- Gross head
is obtained by subtracting tailwater from forebay - presuming forebay is
measured behind the trashrack.
- In the
current revision of the ITB, nethead is computed by subtracting
velocity head at the inlet from gross head. If forebay is measured in
front of the trashrack, then the ITB computes the presumed pressure drop
from a loss coefficient for the trashrack that was pre-determined for this
restriction.
- Flow is
computed by:
- Measuring
the differential pressure across the Winter Kennedy taps,
- Scaling
the transducer output voltage signal to PSID,
- Taking
the square root (or approximately so, per ASME PTC-18 –2002, pg 64,
section 4G) of this differential pressure, then
- Multiplying
by a constant to get the raw Cubic Feet per Second (CFS) flow value.
- Raw CFS
flow is corrected for head variations by the ASME PTC-18-2002 (pg 70)
affinity law:
Q @ Hspec = Qtest(Hspec/Htest)0.5
- Input
power is computed as head * flow * mass (cfs * pounds/cubic foot of water)
- Generator
Power is corrected for head variations by the ASME PTC-18-2002 (pg 70)
affinity law:
P @ Hspec = Qtest(Hspec/Htest)1.5
- Efficiency
is computed as 100 * (output power/input power)
- The ITB
then catalogs and store the data, and then
- Updates
the live displays of data on the computer monitor.
Collected SteadyState data is stored on disk,
organized by Head, Gate and blade. Values stored on the hard drive for each
data point include but are not limited to:
Forebay, Tailwater, Grosshead, Nethead, Gate Setpoint,
Gate, ‘Blade Setpoint, Blade offset, Blade, Flow, Power and computed
efficiency.
A unique 4-channel Cartesian coordinates graphing
routine was developed for the ITB and was reported on by your Lee Sheldon in a
document titled:
“A NEW GRAPHICAL METHOD TO REDUCE TURBINE INDEX TEST DATA.doc”
This graphical data presentation is a continuously
updated live display on the ITB monitor. This live display analyzes the data
points, the X & Y axis scale and offset and then plots the points on the
ITB monitor display in real-time.
It should be noted here that when the ITB was first
delivered to HDC in May 2005, Ed Miska directed me to remove the live graphical displays shown in Fig 19 that present the 3-D cam’s blade to
head and gate performance in a clear, easy to see format. When Rod Wittinger
was restored as Technical Lead, these live displays were returned to the ITB
monitor.
Live
Action Display
While the ITB is running an index test, operational
data for the unit is presented in a live-action display on the ITB monitor. Fig
19 is a snapshot of the ITB monitor during the testing at McNary that was
captured using the “screen capture” feature of the IBM PC while the ITB was
collecting, analyzing and storing data for unit 9.
If
the video screen capture software I’m using now would have been employed in the
December 2005 test, it would provide a much better record of how things
transpired. Replaying the GBO field-test data files with the ITB PostProcessor
as seen in videos presented later in this letter makes a satisfactory second
option, however.
The ITB live-display shows a variety of continuously
updated operational data for the unit. There are many other display modes that
are not shown here.
Figure 19 ITB Monitor Live Display during McNary Proof of Concept test
All of these displays are continuously updated every
few seconds.
Suffice it to say, the ITB does plenty of analysis
while the test is running.
Further analysis and the definition of the new 3-D cam
surface are accomplished using the PostProcessor utility in the Index Test Box
software suite, off-line. These capabilities are spelled out and demonstrated
in the McNary test report submitted to
HDC for the December 2005 test data and in a few video files currently being
prepared for distribution over the Internet to advertise this product.
I believe the foregoing could be construed as
“analyzing collected data,” in deference to the false statement in the HDC
Response document.
The
statement, “Did not have adequate documentation” is highly subjective.
Documentation
As stated before, this was a “time and material
with a cap” contract, and by Ed Miska’s directives several items were
pushed into the workscope without any additional compensation or time
allowances in return, despite assurances there would be increases in time and
funding each and every time I protested the changes and additions that
were outside the original Contract’s workscope. This type of a contract was a
“zero sum game,” in that if something was pushed in that was not budgeted for
in the original Contract’s workscope, something else had to get pushed out;
it’s just simple economics - the profit margin can only yield just so much.
Additions included, among other things, the OPC
communication interface and the automatic flushing manifold - neither were
trivial exercises.
Two releases of documentation did get prepared and
were formally transmitted to HDC, and are available for inspection.
It was always my intent to continue
developing the documentation for the USACE variant of the ITB, as time allowed,
and to post such documentation on my website for the Government (and anybody
else) to access. The fact that this documentation was not made ready during the
performance period was due to HDC continually adding items to the contract
workscope and changing the performance milestone targets, which kept me busy
with other things - so the documentation didn’t get enough attention.
I was not as happy with the level of documentation as
I would have liked either, but under the circumstances - with the running daily
battle I had to track the moving project milestone goals, to get access to a
unit to test, to protect my Intellectual Property and to complete all of
the tasks necessary to get the first production unit of ITB completed, into the
field and tested - I’m not really all that much disappointed with how the
documentation turned out.
In a more general sense, development of a new product
or technology does not start with the documentation. It starts with development
of the core technology; goes on to “reduction to practice” and a few
demonstrations of the new technology. Productionization of marketable
implementations and preparation of customer documentation always come last.
Documentation is not a trivial after-thought or simple
matter. The rule of thumb we used in planning sessions at Woodward for new
products was to set-aside 1/3 of the project budget and time for preparation
and testing of customer documentation. With all of the unplanned difficulties
and added workscope on this project, the documentation regrettably did suffer
on this project because all of the time and money got consumed in just getting
everything to work.
The
statement, “Did not comply with the source code requirements,” is nonsense.
The fundamental source code requirement was that all
software code that was written prior to engaging with the Government was mine,
and all source code written at Government expense was to be shared with
the Government.
Anything beyond that is just “Governmental Wishful
Thinking.”
The Government always had the option to buy the
pre-developed Copyrighted source code from me at any time, but always chose not
to, and tried repeatedly to get it away from me for free.
The Government funded source code was referred to as
“Co-Developed” code; all of this Co-Developed code was delivered to
HDC at multiple times as specified in the Contract, as delineated
below.
A reasonable price for the Copyrighted source code
that pre-existed the Contract and thus was written at private expense was
negotiated with Dave Ebner, Rod Wittinger and Lee Sheldon at $750,000 in the
initial contract negotiations. This pre-existing code was copyrighted at the
beginning of the contract interval primarily to document that it preceded Contract
signing, and thereafter was segregated from the subsequent government-funded
Co-Developed software to keep it separate - and to protect it.
The pre-developed Copyrighted source code could have
been purchased by the Government at any time; but instead of making an honest
deal of it - Ed Miska made many attempts to get it away from me without paying
for it.
We call that theft out here in the
private sector.
I learned over dinner and drinks while I was in
Portland in August 2004 that a few weeks earlier (before I made that first trip
to Portland) there had been a meeting at HDC with Dave Ebner, Rod Wittinger,
Lee Sheldon, Ed Miska and other unnamed persons in attendance at which ITB
interfacing and GDACS software security protocols were discussed. The meeting
was at loggerheads because GMT was adamant that the ITB could not be connected
to the GDACS without HDC getting the complete software source code to inspect,
and I was refusing to give over the pre-developed Copyrighted source code until
I got paid for it.
Dave, Rod and Lee felt it would be an acceptable
solution to just buy the source code - I was only asking $750,000 for it –
which was well within the project budget. Ed said spending that money would not
be necessary – after he got one of my instruments and saw how it worked, HDC
could just subcontract to ACSI on a task-order to duplicate it’s
functionality in GDACS and avoid paying ATECo for the Copyrighted source code. That
was the HDC/GMT mindset that I was working against for the entire project.
Procurement favoritism and piracy of intellectual
property is rampant at HDC, I am ashamed that my Government would behave in
such a way.
The following email from Ed to me was particularly
problematic. It came at a time when I was trying to get the OPC communication
system (that Dan Perrier (ACSI) recommended & endorsed and Ed directed
me to add to the ITB) working. I was asking HDC for some explanation about
what setup techniques and tag-names HDC was employing to utilize OPC
communication technology in GDACS. Instead of providing the answers I was
seeking, Ed told me to just give the ITB program source code to him and then
he’d have ACSI rewrite it in another computer language for HDC. My response was
that I was not going to give the source code to HDC until I got paid for
it - after that he could do whatever he wanted with it - as long as it
stayed within FCRPS per the agreements negotiated with Dave Ebner.
Make no mistake - my goal was always to develop a
refined end product - that was my intention when I started this project
in 1985 for Woodward, and was my objective in 1992 when I quit my job at
Woodward to start this project in the Actuation Test Equipment Company - and
is still my purpose now.
|
Subject: |
RE: another snag – ITB |
|||||
|
Date: |
4/13/05 3:41:55 P.M. Central Daylight
Time |
|||||
|
From: |
||||||
|
|
|||||
|
|
|
|
||||
|
Sent from the Internet (Details) |
|
|||||
Doug,
What we
want right now is a system to prove there is more ahead. Lets get
the data collected and analysed so we can see if it is worth more effort.
We want to avoid the time and effort it takes to develop a refined end product
right now. There is a significant danger of running out of funding if we
don't focus on the first things first. We also do not want to delay the
testing any more than absolutely necessary.
What all of
this leads to is that if it works with Windows XP-home that is not a
problem at all! Do it now and side step the
delay.
Also, the
ACSI task order we will execute only has support for the blade pertibation
work. It is not a general support contract for your software work.
If you need more support for your software set up you should directly contract
with ACSI.
As a side
note. I am not expecting to want to use the software configured for
this test system in a final system. In fact I expect it very likely we
will want to make a lot of changes, maybe even eliminate the VB code.
Again that means we are not looking for a refined product for a
proof-of-concept job. Please get to the data collection as soon as possible.
Thanks,
Ed
503-808-4294
===========================================
What I was asking for from Ed was an example of how
the OPC technology was being used in the GDACS system, and a listing of the
tag-names that were being used for the digitized values of Forebay, Tailwater,
Gate, Blade and Power in the GDACS & 3-D cam, and for Ed to put the
task-order in place to get ACSI to prepare the SoftPLC computer’s blade
perturbation software routines for the GDACS. There are many ways to implement
OPC technology, and I wanted to make my OPC interface implementation to be as
much like USACE’s existing software as possible, so I needed an example for
reference.
Ed refused to give me any of this information, telling
me that it was all “operational data” and as such he was prohibited from giving
it to me under the Homeland Security Act. He directed me to get the
information about the OPC techniques and data tag names from ACSI.
I had to pay ACSI $1,000 to purchase this information
– information that in my mind should have been provided to me by the Government
at no charge.
On several occasions I requested a copy of the Task Order to
ACSI for their
support of this project. Ed Miska refused to give it to me, citing a
proprietary relationship with HDC’s “captive supplier.” Dave Ebner
subsequently gave me a copy despite Ed’s objection. It was surprising to see
that there were 8-hours of support time in the Task-Order for ACSI to provide
assistance to me for the OPC communication interface, this after I had been
required to pay ACSI $1,000 for the 8-hours of support separately.
Figure 20 Excerpt from ACSI Task Order showing 8-Hours support to Doug Albright
Instead of receiving this support paid for by
HDC, I was required to pay ACSI $1,000 to get this assistance. Now
I’d like to know if HDC also paid ACSI for this 8-hours of support that was
specified in their Task Order, and when Ed Miska denied me a copy of
the Task Order, was he actually purposefully setting the stage for ACSI
to receive a double-payment for this support? The work that was done by
ACSI was not satisfactory, but it gave enough direction so I could complete the
interfacing without any further assistance from them.
As a small business owner, I am outraged that my
Government behaved in such a disgraceful manner. I was continually pushed
around and hustled in attempts to force me to fumble so that the source code
could be snatched away from me. The patterns of behavior made it obvious that
HDC wanted to get the ITB away from me so that it could be given to the more
favored contractor (ACSI) so that they could rewrite it into another computer
language, which was later proven by a May 8, 2006
email from Tom
Murphy to HDC personnel named therein (the surrounding situation to this email
is described in greater detail later in this letter).
The
statement, “The contractors’ non compliance of the Optimizer Special License
Agreement threatened the regional GDACS security control system.” Is ludicrous.
The Optimizer Special License Agreement was never
violated by me, but was continually violated by Ed Miska; it gave rights
and protections to both parties and I made sure to comply so its protections would
stay in force. The HDC Response document statement has no basis in fact.
The
statement, “Although not specifically addressed in form 2631, system security
was a significant factor considered in the performance evaluation and is
discussed in Reference #1,” Is nonsense.
To the contrary, there was never any threat to
Government security. When I was in USAF (1972 to 1978), I had a Top Secret
Clearance with an Extensive Background Investigation to allow me to work
overseas on aircraft communication gear for the Strategic Air Command. When the
SR-71, B-52 and KC-135 aircraft flew missions in support of the war in Viet
Nam, our radio gear passed the command communication traffic from SAC at Offutt
to these operational combat aircraft.
My efforts have always for the best interests of, and
for the United States to be secure and prosper – to be considered a threat
to your system was insulting, but I understand the drill and didn’t make a
fuss, but let’s get real here.
On the other hand, my product security was repeated
threatened by HDC, who continually tried to purloin my pre-developed
copyrighted source code without paying for it. Apparently Dick Nelson & Ed
Miska believed that I was just some “bumpkin from fly-over country” and could
easily be duped. My highest priority was (and is) protecting my Intellectual
Property and financial position. The shenanigans with the contract tampering
are a prime example of this – as if I’d sign a Government contract without
reading every word of it.
HDC is upset with me now because they were unable to
take the Copyrighted software away from me without paying for it.
The tone of the HDC Response document is like when the
victim gets away from the muggers – and then the muggers disparage the intended
victim – a.k.a. “Sour Grapes.”
II. Comments on Item 17 Attributes
First Field Test: “Zero-problem” thwarted on Unit 5
Figure_21 Excerpt from HDC Response deflecting blame for failed field-test
This is an altogether disingenuous misrepresentation
of events in an attempt to deflect the fault and cause for this failed test
from HDC personnel’s misconduct to ATECo.
This field test failed to “collect any useful data for
evaluation” because nobody from my company was allowed to participate in
this field test of my product.
The statement, “…did not collect any useful data
for evaluation” is also false, as shown by the “McNary Skew” discussions
later in this letter.
As Technical Lead appointed by Dick Nelson, Ed Miska
disallowed any representative of ATECo from attending this field test because I
was refusing to sign the modified contract that Ed had tampered with in
secret. Ed added text to the contract that would compel me to give my
Copyrighted source code to HDC without the proper compensation. The USACE
Contracting Officers allowed Ed to make these changes to the contract’s verbiage
to my disadvantage, without my knowledge, in order to seize my intellectual
property by deceit.
My Congressman was contacted regarding this contract
tampering. He engaged a lawyer that was under retainer to U.S. House of
Representatives to review both the original and modified contracts. This legal
opinion was that the original contract had the necessary verbiage to provide
the needed extensions of time and material (which could have easily been used
to adjust the time and payment schedule as we needed) and the only purpose for
the modified contract was to get my signature on a document that would seize my
Copyrighted source code without paying for it. The lawyer said he had seen this
trick before, and recommended that I should engage an attorney and sue USACE
for Contracting Fraud.
The modified contract had been altered in secret to my
disadvantage, and according to three legal opinions, would
have forced me to give the Copyrighted source code to HDC without getting paid
the negotiated, agreed upon price of $750,000 if I had signed it. Details of
this Contract tampering are explained below.
Contract
Tampering Detailed Specifics
This first excerpt of fig 22 is from the original
USACE Contract W9127N-04-D-0009. This excerpt
shows the personnel involved at the inception of the project. Rod Wittinger was
the perfect Project Manager and Technical Lead for this project; he was the HDC
Senior Mechanical Engineer, highly skilled and experienced at turbine index
testing. Lee Sheldon was (and is) a hydro-turbine index-testing expert, and
familiar with my ITB because he had worked with it for testing in 1985-1987 at
Clarence Cannon Dam in Missouri and again at PGE-PHP-2 in Portland, Oregon. It
was the expertise, judgments and efforts of these two men that got this project
started.
Figure 22 Excerpt from contract W9127N-04-D-0009 showing personnel roster
At about the 6-month point in the project, Dick Nelson
(then the HDC Western Branch Chief) assigned Ed Miska to take over as Technical
Lead for the project. Ed had no knowledge, experience or expertise at index
testing turbines. When I was explaining to him about how the ITB’s Winter
Kennedy flow measurement system worked, Ed acted like he already knew
everything, and then later asked Lee Sheldon if the Winter Kennedy
taps were really used for flow measurement!
Ed’s presence was always a hindrance and an obstacle,
and immediately it became painfully obvious to me that his sole purpose from
the beginning of his involvement with this project was to disrupt any progress
in order to protect the status quo, and to take the ITB technology away from me
to give it to ACSI in the process.
The May 8, 2006 email from Tom
Murphy (when put into context with Ed’s continual chicanery) bears this out.
When I complained of Ed’s unsuitability to head this project to Rod and Lee,
they took my objections to Dick Nelson. Dick’s corrective action in response to
my complaints was to direct Rod and Lee to not talk to me any more – Ed
was to be my only point of contact.
Another disturbing aspect in this is shown by figure
23, an excerpt from the modified Contract. The Change
Record indicates that there is a new paragraph 3.4.2.9a, but makes no
mention of the more problematic words secreted into paragraph 3.4.2.9.
This additional text was not bolded, as Dave Ebner said is normal when
making modifications to a Contract’s text so as to make it more noticeable to
another person reading it later. By sneaking this unheralded (unmentioned
in the Change Record), unbolded, changed text in paragraph 3.4.2.9, it was
obviously Ed’s intent that I would overlook this tampering in a quick read of
the Contract, not catch it and sign - and then it could be used later as a “gotcha!”
to seize my intellectual property without compensation. It was
outrageous for HDC to allow Ed to make this unilateral change to my contract, in
secret, and then to bully and coerce me for 2 ½ months in repeated
attempts to force me to sign it, and thereby give HDC my Copyrighted source
code without receiving the agreed-upon $750,000 payment for it by this
deception.
This was Government misconduct of the basest kind.
Figure 23 Excerpt from modified contract W9127N-04-D-0009 showing Change Record and new personnel roster
I objected to Ed Miska supplanting Rod Wittinger as
the Project Manager and Lee Sheldon as the HDC Contact after my bad experiences
with him in the past. Dave Ebner told me I had no say in who is chosen by the
Government to head a Government project, even if that person is
unknowledgeable about the subject matter (index testing).
Figure 24 shows the original contract’s text of
paragraph 3.4.2.9 that was agreed upon during original negotiations between the
Contracting Officer’s Representative (COR) Dave Ebner and me in May 2004 after
lengthy negotiations to get it just right.
Figure 24 Excerpt from Contract W9127N-04-D-0009 showing original text
Ed’s secret alterations to this paragraph are shown in
figure 25, by adding the text with yellow highlighter.
The tampering was crafted so as to give me paragraph
3.4.2.9a (fig 26) as a “red herring,” that I would have been able to find and
object to, and then after a feigned struggle by the contracting
officer(s), get it removed; while the real problem was the extra words that
were secreted into the original paragraph 3.4.2.9 (fig 25) that were not
indicated in the Change Record, nor were they highlighted or bolded to indicate
that they had been changed, hoping I would not notice them. This was a
clever ruse, but it didn’t work. I read every word of the Contract carefully
and caught it.
Figure 25 Excerpt from Modified Contract W9127N-04-D-0009 page5, showing text secreted in by Ed Miska
Figure 26 Excerpt from Modified Contract W9127N-04-D-0009 showing paragraph 3.4.3.9a
Paragraph 3.4.2.9a was entirely new and
completely changed the terms of the original contract agreement. Had it
included the Contract’s negotiated payment of $750,000 for me to hand-over the
pre-existing Copyrighted software source code, it would have been OK with me,
but Ed forgot the money.
This tampering to my contract was done in secret by
making the above listed additions to the verbiage in the boilerplate, but when
the contract was sent to me for signature, I was assured by the COR that I
wouldn’t need to bother with reading the boilerplate, it was just a formality
and nothing in it had been changed -and then he went home (purportedly
sick with the flu) after sending the modified contract around the “signature
loop” for approvals. This happened 4 days before the end of the “performance
period” in the contract. When it got to Ed on the signature loop*, he
pigeonholed the modified contract on his desk until 10 days after the
performance period had expired, sneaking in the above listed changes while he
had it in his possession - at least, this is what I was told.
This situation meant that I couldn’t work on the
project and couldn’t invoice for my time. After 10 days, I wrote an email
to Dave Ebner, hoping that he had returned to work. He had not; he was still
sick at home. Dave did however monitor his work email from home. He answered my
email right away, and then went in to work while still sick to locate and
expedite the contract. (I joked that he should sneeze on whoever was sitting on
it.)
*It
is still curious to me; what is the exact mechanism for contracting work that
would allow this tampering to happen in the first place? Dave Ebner prepared
the Contract in his personal computer, which was locked up on his desk whenever
he was away. With computer security protocols and procedures in place to
prevent anyone from getting into Dave’s workstation to do any such tampering,
how is it that this tampering could happen? The modified contract’s wording as
it arrived here for my signature should have been the exact same text that Dave
and I had agreed upon in negotiations.
I
believe he would have sent an electronic format copy to everyone on the
“signature loop” at the same time; it would not have been a hardcopy circulated
by inter-office mail. Upon receiving the approvals back by email, Dave would
have then emailed me a copy of the original that had always been locked-up on
his computer, protected by his system password. How is it that Ed was able to
get access to Dave’s electronic format copy of the Contract to do this
tampering without Dave’s knowledge, if computer security in the Contracting
office is such a big deal? My thought was that when the approvals were made, it
would just be by an affirmative email reply to Dave’s email that had sent the
Contract out for everyone to see and approve. HDC has never provided a
plausible explanation, so I believe that the Contracting Office must have been
complicit in the Contract tampering. Please explain how I’m wrong here.
Dave found the contract on Ed’s desk, got Ed to sign
off on it, walked it the rest of the way around the signature loop, and then
left it for a subordinate to send the modified contract to me for a signature
and then went back home because he was still sick.
When it came to me the next day, I found the
unauthorized alterations and protested to Dave via email at home and to Ed over
the phone - and then called to complain about this to the Contracting Officer,
Ralph Banse Fay, who after reviewing the matter insisted that the altered text
of paragraphs 3.4.2.9 and 3.4.2.9a did not change the meaning of the
contract in any way - and that I had no say in who the Government chose as
program manager. I argued that if these alterations didn’t change the meaning,
then why did the government want to change the wording in the first place?
The alterations of paragraphs 3.4.32.9 and 3.4.2.9a were
done in secret by the Government and were fraudulent deception with the
intent to steal my Intellectual Property.
Concurrently, Dave Ebner allowed me to submit an
invoice for the time period up to May 31 (when the performance period expired)
on June 21, 2005 while I was refusing to sign the tampered contract. Up to this
point, my invoices had always been paid within 1 week, but this invoice still
hadn’t been paid 3 weeks later. When I complained to Dave about the late
payment, he found the invoice, which he had again sent around the “signature
loop,” and it was again delayed on Ed’s desk.
All this while I was being pressured by all of the HDC
personnel involved that the testing was urgent, and that we needed to
all get back to work, and I should just sign the contract and get it over
with, but I kept insisting that the contract be restored to the agreed-upon
form by removing the unauthorized added text before I would sign it – all of
this was working to my disadvantage.
Is
there any wonder why I have hard feelings about all of this? It is shameful
that the Government personnel would conspire to steal from a private citizen
like this.
When I recalled to Ralph how rigid the negotiation
rules had been with George Williams and Dave Ebner while we were haggling over
the original Contract; how it was that I could speak to only those two men and
to no others, and how no others could have anything to do with the negotiations
or change the contract in any way, and that only the Contracting Officer could
change the contract and then only in agreement with all parties concerned
– how was it that Ed Miska was allowed to unilaterally alter my contract in
secret during this dubious “modification” that HDC was requiring? Ed was
allowed to tamper with the contract in secret to my disadvantage, without the
knowledge of myself or my COR (Dave Ebner) and this was all OK with Ralph - who
was arguing that I should just sign it because it wouldn’t hurt me.
Ralph brushed off my complaints and stated repeatedly
that the unauthorized changes did not affect the meaning. This was a blatant
falsehood – I refused to sign the contract for over 2 ½ months, until Ed
embarrassed himself during the August 12, 2005 field test – after which the
offending, unauthorized changes were all removed and the modified
contract was restored to the agreed-upon form that Dave Ebner and I had
negotiated.
It
was insulting for Ralph to treat me as if I were such a fool.
The primary reason that the first field test on August
12 2005 failed to get any useful data was because HDC personnel continually
attempted to purloin my project so as to divert the $3,500,000 left on the
Contract to the more favored contractor (ACSI).
It had nothing to do with the ITB functionality or any lack of
documentation.
The
complaints by the “technical office responsible for my contract” are all a diversion
and a smoke-job.
Let me describe in detail the events surrounding the
August 12, 2005 field test to put the HDC Response document’s distortion
of the facts into context.
To keep track of events, I kept daily logs, copious
notes, and to pull it all into focus I prepared a timeline that tracks events,
day by day.
Click here: the entire 1-year performance timeline is at this link.
This is an excerpt from that timeline that shows the
time period of interest from May to August 2005 that will help to explain away this
misrepresentation by putting it into context:
Figure 27 Excerpt from TimeLine of project events
Blade Perturbation and Zero Problem
There were many HDC created delays, misdirects and
added items to the workscope, which combined with Ed’s refusal to process the
task order so that ACSI could do their part of the ITB to GDACS SoftPLC
blade perturbation routine in a timely manner, resulted in the time
required to complete all of the tasks exceeding the allotted 1-year performance
period.
Despite repeated requests to Ed Miska (ever since he
returned from a TDY to BPA on 6 September, 2004) to get the task-order in place
so ACSI could prepare the perturbation routine for GDACS, this task-order
was delayed until after the ITB was delivered to HDC. This preventing me
from completing the software programming for the ITB interface to GDACS before
shipping the ITB to HDC, and also opened a window of opportunity
for Ed and Dan Perrier (President of ACSI) to devise the “Zero Problem” ruse,
which is described in detail below.
Ed insisted that instead of me completing the ITB
blade perturbation interface here before sending the ITB to HDC as a completed
item – that instead I should send the unfinished ITB to HDC in Portland
immediately – saying “We would finish it later, working together.”
Ed’s plan was that I would make the Visual Basic
programming modifications here to implement the blade perturbation as directed
by Ed and Dan (ACSI), I would compile them into executable code modules, here,
and then these executables of the program would be emailed to HDC to be
installed in the ITB and checked out by Ed and Dan (ACSI) at HDC, because
the ITB was in Portland.
Dave Ebner, Rod Wittinger and Ed pressured me to go
ahead with this plan and send the ITB to HDC without completing the blade
perturbation interface because the performance period was about to expire - so
against my better judgment I sent the ITB to Portland without the
perturbation routine completed.
Dave
Ebner forgot about this project manipulation by Ed, and later criticized me for
having HDC personnel working on my instrument, saying I should have done all of
my own work. I had to reconstruct the chain of emails for him to explain what
happened.
Table 1 is a chronological, dated list of events:
Table 1,
chronological listing of events
- May 25,
2005 - Dave Ebner and I completed the contract
modification negotiations.
- May 26
- Dave sent modified contract around the ‘signature
loop’ and then went home sick with the flu, telling me that a subordinate
would forward the contract to me when it came back from going around the
signature loop.
- May 31
- Original contract’s 1-year performance period
expired; I suspended work (and stopped getting paid), and started
waiting for the modified contract to arrive.
- June 7
- I wrote an email letter to Dave, telling him I
still had not received the modified contract, Dave read my email at home
(while still sick), and wrote back telling me he’d take care of it.
- June 8
- Dave went back in to work (while still sick) and
searched the signature loop to find out where the modified contract was
held up; it was found on Ed Miska’s desk. Dave retrieved it, walked it the
rest of the way around the signature loop, gave it to a subordinate to
forward to me, and then went back home (because he was still sick). When I
got the contract and read it, I found that there were several unauthorized
changes and unacceptable additions secreted into the boilerplate to the
contract (as listed with these bullet points).
- Change
Record does not indicate paragraph 3.4.3.9 had been modified
- Ed Miska
supplanted Rod Wittinger as Program Manger (and Technical Lead)
- Ed Miska
supplanted Lee Sheldon as HDC Contact
- Paragraph
3.4.2.9 was secretly altered so as to compel me to give the source code
to the ITB program to HDC before the McNary field test and with every
software modification (without getting paid the agreed upon $750,000
price.)
- Paragraph
3.4.2.9a was added to compel me to give HDC the source code without
compensation with every delivery or software modification (again, without
getting paid the agreed upon price of $750,000.)
(Later
I learned from Jason Loeffler, a CID investigator who looked into this on
behalf of DOD IG in response to a complaint to DOD IG Hotline, that Ed Miska
was the person who admitted to the unauthorized modifications to the contract.)
- I refused
to sign the modified contract (for 2-½ months) and wrote a letter to Dave
Ebner complaining about the unauthorized changes.
- June 19
- Dave sent the modified contract for me to sign
again, but the unauthorized changes to Project Manager; HDC contact and
paragraph 3.4.2.9 & paragraph 3.4.2.9a were still unchanged, so I
still refused to sign it.
- June 21
– Dave allowed me to submit an invoice for all
charges up to the May 31. My invoices usually took about 3-days to go
around the signature loop and get to Vicki Collins for payment. Ed delayed
this invoice until July 11. Dave went around the signature loop again
looking for it, and found my invoice pigeonholed on Ed’s desk, and then
expedited it for me.
- June 22
- Dave sent the modified contract again (after
slightly neutering paragraph 3.4.2.9a), but all else remained the same so
I still refused to sign it.
- June 27
- Had phone conference with Dave and Ralph Banse
Fay. Ralph refused to change the wording of paragraph 3.4.2.9 back to the
agreed upon form and refused to remove paragraph 3.4.2.9a, telling me the
changes wouldn’t hurt me and insisted that I sign it. I still refused to
sign until the Contract was returned to the agreed upon form.
- July 6
- Start of Zero Problem* (see below).
- July 14
– “Good News” Ed says zero problem not in partial program, wanted
me to send the rest of the source code to test because the complete
programs I compile here still send zeros, a problem that I cannot
reproduce here.
- July 22
to August 8 - Dave Ebner’s vacation.
- August
1 – Email that states zero-problem was demonstrated
to Rod, Lee and Dave just before Dave went on vacation. I could not
duplicate it here, but Ed could easily demonstrate it on ITB at HDC.
- August
11 - First “partnering meeting” phone
conference, HDC added $20,000 to entice me to sign, but did not change paragraph
3.2.4.9 back to the original form or removed paragraph 3.4.3.9a, so I
still refused to sign the modified contract. (Had they added the
agreed-upon $750,000 price for the software source code, I’d have signed
it.)
- August
12 - HDC took the ITB to the first failed field test
without anyone from ATECo in attendance because I was refusing to sign the
altered contract. Ed Miska had said in our first “partnering meeting” that
he and Dan Perrier could “handle it,” and it would be unnecessary
to have anyone from my company there. Zero problem still an issue, I can’t
duplicate it, they keep seeing it, so Dan (ACSI) wrote a zero-snatcher
program for SoftPLC to allow testing to continue.
- August
13 – After the field test failed, the ATE-150 arrives
at ATECo the next morning; FedEx overnighted from McNary. I had my
technician, Greg Luna, check it out because I was working on
figuring out the “zero problem” by analyzing the Software Toolbox
TopServer data files that HDC extracted from the ITB and sent to me. Greg found
the ATE-150’s broken wire in 5-minutes, and had it fixed and checked
out within the hour.
- Aug 18
(morning) – At the next “partnering meeting,” I
explained how easily Greg had fixed the ATE-150, and chided all HDC
personnel about the altered contract disallowing anyone from ATECo to
participate in the field test - and that if Greg had been allowed to
participate in the field test he could have easily fixed the ATE-150 in
the field. I had figured out the “zero problem” by this time, The
zeros only came from one revision of the program (ITBRev1.br16.exe), and
had been fixed by the very next revision. While I was explaining this to
the group at HDC’s end of the “partnering meeting” conference call,
Ed kept trying to change the subject and get the conversation away from
this topic. At one point I shouted, “you’re busted, Ed!” as he tried to
“weasel-word” his way out of it by changing the subject. Ed was silent for
the remainder of the meeting and I completed the explanation of the
“zero-problem” to the group. The zero-problem never showed again in ITB,
but the zero-snatcher was still in SoftPLC.
- August
18 (afternoon) - Rod reasserted himself and took back control
of the project as Technical Lead. Ed disappeared and never participated
directly again (though I learned from the BPA FOIA information that Ed
was always on the sidelines sniping at me, and I suspect he had a hand in
preparing the HDC Response).
- August
19 - Contract restored to original form; Ed’s name
removed, Rod returned as the Program Manager & Technical Lead, Lee was
restored as the HDC Contact, the unauthorized addition to paragraph
3.4.2.9 was removed and paragraph 3.4.3.9a was removed altogether and
$20,000 was added.
- August
19 - (late afternoon) I signed it and work on the project resumed. Zero-problem
never seen again.
This sequence of events was all a failed attempt by
HDC to coerce me to sign a Contract with unauthorized modifications that had
been secreted into it, contract tampering that would have forced me to give the
pre-developed, Copyrighted source code to HDC without getting paid the
negotiated, agreed-upon $750,000 price for it.
My
Congressman was contacted regarding this contract tampering. He engaged a lawyer
that was under retainer to U.S. House of Representatives to review both the
original and modified contracts. The legal opinion rendered was that the
original contract already had the necessary verbiage to provide the needed extensions
of time and material that could have easily been used to adjust the time and
payment schedule as we needed; the only purpose for the modified contract was
to get my signature on a document that would seize my pre-developed,
Copyrighted source code without making the negotiated, agreed-upon $750,000
payment for it. The lawyer said he had seen this trick before, and opined that
I should engage an attorney and sue USACE HDC for contracting fraud.
It
is still troubling that Ed Miska was allowed to sneak these modifications into
my contract, without the knowledge of Dave Ebner or me. Dick Nelson had joined
in earlier by putting Ed in Charge, and then disallowing Rod Wittinger and Lee
Sheldon from speaking to me after I complained about Ed’s shenanigans. Ralph
Banse Fay aided in this by preventing Dave Ebner from restoring the contract to
its original form for 2½ months after I objected to having it illegally
tampered with by the Government and then Ed invited a more “favored contractor”
in to sabotage my equipment* while I was barred from working on the project - and
now I’m the bad guy?
Zero Problem Explained*
While ATECo was barred from working on the ITB project
because I was refusing to sign the contract (but still actively
participating without compensation), Ed invited Dan Perrier (ACSI) to HDC -
ostensibly to help with the perturbation setup - but in truth it was a ploy to
provide Ed and Dan (ACSI) an opportunity to devise a way to sabotage the ITB,
make me look incompetent, and then get everyone else on the project to pile
on and compel me to give the ITB program source code to HDC - without
compensation. Fortunately for me, when they took the ITB to the field to
execute their plan - a simple broken wire in the ATE-150 foiled their scheme
(more on this later).
The “zero-problem” was a complex, contrived computer
problem that was difficult and tedious for Ed and Dan (ACSI) to devise and
implement and difficult and tedious for me to diagnose, solve and defeat.
During the 2-½ months that I was refusing to sign the
altered contract and Ed (as the Technical Lead) would not allow anyone from
ATECo to participate in the ITB project or attend the field test (or to get
paid), Ed and Dan (ACSI) contrived the “Zero-Problem” in the OPC communication interface
between the Index Test Box and GDACS SoftPLC. This was a problem that I was
unable to reproduce here with the identical “test-bed” ITB equipment in my
shop. (I couldn’t reproduce the “zero-problem” because it wasn’t real.)
By barring anyone from my company from witnessing the Proof of Concept
field-testing, Ed and Dan (ACSI) had a clear field to carry out their nefarious
plan.
Ed and Dan (ACSI) insisted the only way to solve the
“zero-problem” was for me to give them my Copyrighted software source code so
they could debug the “zero problem” for me at HDC because I could not reproduce
it here.
The
problem I had with this was - they would have been getting the Copyrighted
source code. After they had the source code, they wouldn’t need me anymore.
I refused to send the Copyrighted source code to HDC,
demanding that my proprietary software remain proprietary until after HDC paid
me the negotiated, agreed-upon price of $750,000 for it.
After over a week of struggling with Ed and Dan’s
(ACSI) contrived “zero-problem” that was preventing any field-testing, Ed said
that this problem miraculously
went-away, without any
explanation; yet was easily reproducible
on demand by Ed in
August 2004 for Dave Ebner, Rod Wittinger and Lee Sheldon to witness a week later
to justify the zero-snatcher program in the SoftPLC. I could not reproduce it
here, but it was a continuing problem at HDC so Dan (ACSI) wrote the
zero-snatcher as a fix.
The way the zero-problem worked was that Ed
and Dan (ACSI) had retained an earlier revision of the program, the “Bad
program,” which was revision ITBRev1.br16.exe. (The revision level at the
December field test was ITBRev1v31.exe.) No other version of the program
should have been present, usable, or accessible from the ITB Desktop.
The version 16 of the ITB program had a known “software bug” in it - a bug
that would randomly send a zero to the GDACS blade input as the perturbation
SetPoint signal.
Ed and Dan (ACSI) were able to acquire this program
revision with a bug in it because Ed had withheld the task-order for
ACSI to provide the blade perturbation software routines for the GDACS SoftPLC
for over 8 months, so I could not finish this part of the software programming
for the ITB before the end of the “performance period” and had to send it to
HDC unfinished. Ed directed that the ITB be sent to HDC without the
perturbation routine completed.
Ed’s original plan was for me to make the program
changes to implement the blade perturbation using my test bench here, compile
the code to the executable form, and then email the executables of the
program to HDC for Ed and Dan (ACSI) to install and evaluate in the ITB. As I
sent successive revisions to HDC for Ed and Dan (ACSI) to test – some of them
understandably had problems (that’s just the way it is with Software, “bugs”
happen). When they found a “bad” version of the program with a problem that
they could exploit - the game was on.
If this were not so, then ask Ed,
“Why was there an icon on the ITB desktop in the upper right corner named, “BAD
VERSION Index Test 1.0?”
(I
found this icon on the ITB desktop in December 2005 while we were index-testing
unit 9 at McNary. It was immediately recognized for what it was, and I demanded
to Rod Wittinger that it be removed. Rod refused, saying, “That would have to
go through Ed.”)
What possible other reason could Ed have for retaining a known “bad” version of
my program that was just one of the many that were sent by me to HDC during the
perturbation routine “song and dance” that I had to endure - and then why
would Ed put an icon on the desktop of the ITB that is pointing to this known
bad program?
Figure 28 Screen capture from ITB, acquired by me from the ITB during the McNary field test in December 2005.
This “bad program” was stashed on the hard-drive of
the ITB, with a special “Bad Version Index Test 1.0” icon on the ITB monitor desktop (located in the upper
right corner of this ITB screen-capture, shown above) so that when Ed and Dan (ACSI)
wanted to show the bad program to someone, they could simply shut down the
proper ITB program and click on this icon to run the “bad program” to
demonstrate the “zero-problem.”
To accompany this bad program that would be
sending random, unwanted zeros to the GDACS blade perturbation input and
disrupting the off-cam index testing, Dan (ACSI) wrote a small “Zero-Snatcher”
program to load into the GDACS SoftPLC that would intercept and discard any
zeros that were sent as SetPoints by the ITB’s “bad program” to the
GDACS blade perturbation input. (This “zero-snatcher” program became a
hindrance during our subsequent testing at McNary in December 2005, as detailed
in Rod’s report and below.)
In this way, they planned to show that my software had
technical problems that I was incapable of fixing after weeks of trying, and
then using this ruse to compel others at HDC to pressure me to give my source
code over to Ed and Dan (ACSI) so they could debug this “zero-problem” for me
at HDC.
Because Dave, Rod, Lee were not very “computer
savvy,” they didn’t fully understand what was going on or know who to
believe - and with the politics at HDC being what they were, they didn’t
want to go up against HDC’s computer “expert” (Ed) and the “wizard” from ACSI
(Dan) and lose their jobs over this - so I was battling
against all of them.
With the aid of the technical support from Software
Toolbox (who provided the OPC servers that I used) I acquired the diagnostic
data files that are normally generated by the Software Toolbox TopServer
program, and by deciphering the data in these files was able to figure out what
was going on - and in the end defeated Ed and Dan (ACSI) at this game.
After I diagnosed what had been going on and explained
it to HDC’s T1-team in a “partnering meeting,” the “zero-problem”
mysteriously went away – but it
wasn’t entirely gone; the zero-snatcher rung was still in the relay-ladder
logic programming in the GDACS SoftPLC at McNary. When we were running the
fourth “proof of concept” index test at McNary in December 2005, Rod wanted the
software in the SoftPLC on Unit 9 to be exactly as it had been in August for
the test on Unit 5. Over my objection that the “zero-problem” was gone, the
“zero-snatcher” rung was installed in Unit 9 because it was already in the
software “build” for the SoftPLC that had been established for the August field
test on Unit 5. As a result, Dan Ramirez was puzzled why he couldn’t set the
blade perturbation to zero-degrees of offset.
The explanation was that it was the zero-snatcher that
Ed and Dan (ACSI) had put into the GDACS SoftPLC software in August 2005, why
it was there, and that it was not a problem or fault of the ITB but a
remnant of a nefarious scheme to purloin my software source code.
Figure 29 Excerpt from Rod Wittinger's report makes reference to the “zero snatcher" issue, page 2
Second
Field Test: Mislabeled Winter Kennedy Taps on Unit 5
Figure_30 Excerpt from HDC Response, a diversion of fault of second failed field-test.
This is a non sequitur. Calling out
problems of unattended operation, missing documentation, no source code, errors
and bugs, security issues and ATE-150 etc. are all simply deflection and
obfuscation of the truth of why this field-test failed. The abject failure
of this attempt was not in any way the fault of ATECo or the ITB; it was the
fault of USACE personnel’s neglect.
It was already known to USACE personnel from prior
work with unit 5 at McNary that the labeling of the Winter Kennedy Taps and the
powerplant blueprints for Unit 5 were incorrect - yet these errors did not get
corrected.
ATECo technician Greg Luna went to Portland for this
test. The ITB was not fully demonstrated on this trip due to a perceived leak
in the Winter Kennedy flow signal pressure lines that prevented an accurate
flow measurement - when in fact the pressure taps were OK, the problem was
improperly identified Winter-Kennedy pressure taps which caused the test personnel
to connect to pressure signals from the wrong pressure taps.
Exercising due diligence - before giving
up and leaving the powerplant, Rod Wittinger and Lee Sheldon checked the
Winter-Kennedy pressure signal connections and lines against the powerplant
blueprint drawings. The drawings agreed with the labeling on the pressure taps,
so they assumed a leak in the pipes and went home.
The problem was deemed to be a leak in the
Winter-Kennedy signal pipes, so the test was canceled and everyone went home
without even trying to test the ITB.
(However, some data was collected that showed another
problem with the sub-standard GDACS 3-D cam blade controllers, explained below
as the McNary Skew.)*
When we returned in December 2005 for the ITB field-test
we were scheduled to index test unit 9 instead of unit 5 this time. Unit 5 was
down for maintenance, but was still watered. Rod Wittinger humored me
and let us check the Winter Kennedy taps on Unit 5 while it was not running
before proceeding to unit 9 to begin our scheduled testing. We theorized that
if there were truly a leak, there would be an imbalance in the pressure lines
even if the unit were not running. The pressure signals were perfectly
balanced, so it was decided that that there was no leak, something else
was the problem.
Figure 31 Excerpt from Rod Wittinger's 21 December, 2005 McNary trip report, referring to WK Taps, page 1.
It was later learned in conversation between Lee
Sheldon and Dan Watson that HDC personnel had already known that the pressure
signal lines on Unit 5 were mislabeled because Dan Watson had learned this fact
the “hard-way” himself on an earlier index test.
After that earlier test, Dan Watson’s crew left it up
to the powerplant personnel to correct the Winter Kennedy tap labels and
blueprint drawings, which obviously did not get done - leaving the mislabeled
Winter Kennedy taps incorrectly identified to screw up the next crew that came
out to McNary to try and measure flow on Unit 5.
It just happened to be Rod, Lee, Ed and Greg on
this second ITB field test.
It was not in any way the fault of ATECo or ITB that
the Winter Kennedy taps were mislabeled and the powerplant drawings were in
error. The onus for this failed test is exclusively on
USACE personnel who failed to correct the drawings after the problem had
been found out during previous work on Unit 5 (Dan Watson said).
Unfortunately for all, the drawings and piping labels
had not been corrected prior to September 2005.
I’m curious to learn if the drawings and piping labels
have ever been corrected to this day.
This problem wasted $16,000 of ITB project funds,
several weeks of time, and made another trip to McNary necessary to complete
the ITB field-testing, and cannot be blamed on ATECo or the ITB.
It could be said that the $16,000 added to the project
budget in November 2005 was just a restoration of this money that was wasted
due to Government fault.
3-D Cam blade controller problem*
In all of these field tests we had to make many
compromises because of the sub-standard GDACS 3-D cam control system and severe
misalignment of the gates and blades, presumably caused by incorrect
reassembly of the gate operator mechanism by USACE personnel when the GDACS system
was installed at McNary in December 2000; they didn’t get the gates and blades realigned
properly on reassembly after installing the 3(ea) GDACS gate angle sensors, and
did not subsequently index test the machine, find this problem and correct it.
This was learned in August 2004 on the first
walk-through to see unit 5 at McNary with Rod Wittinger. As we went into the
unit 5 turbine pit, after looking around a bit Rod seemed puzzled; something
was amiss. He asked one of the powerplant mechanics what had happened to
the gate positioning equipment.
The main reason Rod wanted the ITB Proof of Concept
test on unit 5 at McNary was that he had prior index testing data for this unit
to use as a basis of comparison for the ITB test results, and from his
conversation with the mechanic Rod was visibly put-out that the unit’s gate
calibration had been disturbed without his knowledge. His comment was
that this made all prior index testing data for this unit worthless for our
“Proof of Concept” testing.
We
never got any ITB index testing data from unit 5 for analysis, but if unit 5 is
anything like unit 9, it is operating very far away from the optimum efficiency
cam surface.
A severe misalignment shows up in the unit 9 test data
as described below; and in casual conversation with powerplant personnel while
we were there in December 2005, we learned that after the GDACS was installed
in December 2000, there was a
noticeable increase in the vibration & rumbling in the floor, rattling of
the stairway guard rails and general noise level in the powerplant - but due
to USACE internal politics nobody ever talks about it.
Test
Conditions
To evaluate the data from unit 9, let’s consider the
test conditions first. We were allowed a blade perturbation authority of (+/-)
2.0 degrees for this test. Immediately upon starting the ITB blade perturbation
and data collection, we saw that there was a 1.0 degree deadband and 35-second
deadtime in the GDACS 3-D cam, which consumed (+/-) 1.0 degree of our (+/-) 2.0
degree authority and made setting the unit up for successive test points much
more difficult and time consuming.
To help the situation, Rod Wittinger got the plant
personnel to reduce the blade deadband to 0.5 degree.
Figure 32 Excerpt from Rod's December 21 McNary test report, page 4, paragraph 3.
However, this was still sub-standard by the industry
accepted ASME/IEEE PTC-29 & Std-125 industry accepted standards.
The
ASME/IEEE standards allow a 1.0% deadband. This is measured as the sum of the
error on both sides of the “ideal blade” angle, so the industry standard is
actually a (+/-) 0.5% deadband for comparison with the (+/-) 1.0-degree
deadband in the GDACS 3-D cam, Thus the GDACS 3-D cam deadband is actually 2.0
degrees by the ASME/IEEE standards’ definition. To quantify this - a 2.0-degree
deadband out of 15.5 degrees full span blade rotation compared with the
IEEE/ASME standards is:
100
* (2/15.5) = 12.9% deadband, instead of the nominal 1.0% industry standard
tolerance that is met by all other Kaplan blade equipment suppliers. Oops.
It was quickly seen from the unit 9 efficiency
profiles developed by the ITB from the December 2005 index test that because
the constant power sweep’s efficiency profiles don’t roll over to show a crest
(or a distinct efficiency peak) anywhere - because we couldn’t push the blades
“flat-enough” (or down on the graph) with the blade perturbation - that
the actual peak efficiency blade to gate point at 74 feet head was more than
1.5 degrees below the “ideal blade” point in the GDACS 3-D cam’s operating data
surface.
Did USACE ever retest this machine after our December
2005 field test - and fix it?
Figure 33 ATECo test report McNary data graph
In order to demonstrate the Constant Power optimum cam
generation method, HDC’s “T1-team” allowed me to extrapolate beyond the range
of the collected data from our December 2005 index test on Unit 9 at McNary to
extend the curves to a “guesstimated” crest-over to show how my* new cam
surface definition technique works. The actual and extrapolated data are
identified by color. The Blue and Green data are the actual measured data
points, and the aqua curves are the “guesstimates” of where the data would have
gone, had we been able to move the blades farther in the “flatter-blades”
direction.
*I
say “my” because it is what I have in my Index Test Box. The Constant Power
method must be credited to Don Sachs, the turbine engineer from USACE’s Omaha
office who explained this technique to me during the index testing at Clarence
Cannon Dam in 1985 – Thanks Don.
Figure 34 Legend for McNary index test data extrapolation
These extrapolations were used at every power level
because the blade to gate alignment was so far off “everywhere across the
board” that even with the remaining 1.5 degree authority to move the blades
that remained, we still couldn’t move them far enough to identify & locate
the efficiency peaks.
The error seen in this data is all offset – there
was no slope rotation - so the “reassembly error during GDACS installation
theory” fits the data.
My
opinion is that this machine was grossly misaligned due
to improper reassembly by GMT during the December 2000 GDACS installation, and
due to USACE internal politics at HDC, nothing could or would ever get done
about it.
There is another problem that
the 3-D cam’s SoftPLC program trips off-line periodically. The HOT
meeting minutes gave an indication of the severity of this problem; the October 3, 2008 HOT meeting
minutes state that HDC’s blade survey
found there were about 65 faults a month at McNary. This problem has a severe
and profound impact on blade positioning inaccuracy. In order to fully
appreciate the impact of this problem; one must understand how the GDACS 3-D
cam works. *
Figure 35 Excerpt from October 3, 2008 HOT meeting minutes. Blade Survey recorded “about 65 faults per month” of the GDACS 3-D cams at McNary.
*How the GDACS 3-D cam works and the Fault
behavior of the units
Figure 36 GDACS 3-D cam mechanisms in governor cabinets
The mechanical part of the
3-D cam actuator is a 2-D cam on the governor’s gate-restoring shaft with a
linear-rise taper (very similar to the original Woodward 2-D cam configuration).
To trim the blade position above or below the linear taper on this linear
“straight-line” 2-D cam to get the third dimension (head) into the mix, the cam
plate is advanced or retarded by a stepping motor controlled by the GDACS 3-D
cam algorithm in the SoftPLC computer.
A fault occurs when the
SoftPLC computer in the GDACS detects a problem with the blade positioning and
shuts off the driver to the stepping motor in order to prevent damaging
anything.
This resulted in the default condition
of the blades tracking only the “linear taper” portion of the cam (between 30o
and 54o (degrees of rotation shown in fig 37) without the
“slip-plate” of the cam being rotated (relative to the gateshaft) by the
stepper motor to complete the blade motion necessary to track the cam data
surface profile.
The consequence of this fault
condition is that blade position is tracking only the straight-line of the
linear taper on the metal 2-D cam, instead of achieving the ideal blade
position from the data table that delineates the desired Kaplan turbine head
and gate to blade relationship - which is supposed to be articulated by the
combined rotation of the cam with the gateshaft and the added rotation (advance
or retard) of the cam’s “slip-plate” relative to the gateshaft by the GDACS 3-D
cam’s stepper motor.
Whenever the 3-D cam software
program detects that the blade angle feedback signal is out of kilter; in order
to prevent damage the GDACS program in the SoftPLC trips out, which disables
the stepping motor so it quits driving the cam. This results in the
straight-line blade to gate tracking shown in figs 38, 39 & 40.
Figure 37 Drawing of USACE GDACS 3-D Cam gate-shaft cam plate
Positioning of the blades by
this system is a two-stage process. As the gate-shaft rotates, the cam rotates
and the linear taper of the cam lifts the cam-follower roller riding along the
top of the cam, moving the blades from full flat to full steep between 30o
and 54o (degrees of gate-restoring shaft rotation).
To further trim the blade
position to the Ideal Blade position per the 3-D cam data table, the
SoftPLC driven stepping motor then rotates the cam plate relative to the
gate-restoring shaft - advancing or retarding it to get the desired blade angle
relative to existing head and gate position.
When a fault condition
halts the stepping motor, the blades follow only the linear taper, resulting in
the blade to gate tracking error shown in figs 38, 39 & 40 (below).
McNary_Skew
Figure 38 ITB McNary Skew, data collected on September 2005 overnight index test
The data on this graph is
from the ITB overnight data-capturing run during the September 2005 index test.
When the crew left the powerplant, the ITB was set to record data from the unit
overnight, unattended. We couldn’t get any index test data (flow signal)
for this unit due to the mislabeled “leaking” Winter Kennedy taps, but we did
get data to show the terrible blade to head and gate performance of the
unit. This data clearly shows the nature of the blade positioning error that
HDC’s 3-D cam manifests when the stepping motor trips-out.
Figure 39 McNary Skew with On-Cam line for existing 74.2 ft head with ASME/IEEE 1.0% limits drawn for reference
To show just how bad this
problem is, figure 39 places the captured data into context of the desired
“on-cam” line for the existing head at the time (74.2 feet) with the accepted
industry standard deadband limits drawn in for reference. By this analysis, the
GDACS 3-D cam positioning of the blades is “not even close.”
The Cover-Up
When the ITB was first
delivered to HDC in May, 2004, Ed Miska said that GMT wanted the Cartesian
coordinates live data screen display of gate, blade, flow, power and
efficiency (shown in figure 19 above) removed. In an email response to Ed Miska, I detailed these modifications
made per this GMT directive:
The
ITB program has been simplified for the first data collection outing by
removing the:
3-D cam
Data graphing
Test simulation
Turbine modeling
Ability to select
AIn, OPC or Dig input.
Gate and blade servo pressure channels
Leaving just the:
Raw data measurement
and display
Steady state
analysis and display
Data storage
When
I protested this neutering of my instrument by removing these highly
useful features, Dave Ebner said this was what the phrase in the contract,
“configuration control” meant.
When
Rod was restored as the Technical Lead, these features were all restored to the
ITB.
Greg
Luna (the ATECo technician who participated in this failed September 2005 Proof
of Concept index test) stated that when they returned to McNary the next
morning (after the first day of running and this overnight run was captured),
Ed Miska extracted the data files from the ITB onto a “thumb-drive,” and then
copied the thumb-drive contents onto his laptop computer, erased the
thumb-drive, shutdown his laptop and then put the thumb-drive into his
briefcase. Because ATECo (me) was supposed to analyze the data from these tests
in order to demonstrate the new graphical analysis method, Greg asked for a
copy of the ITB data, but Ed refused. Greg asked Rod (at that time still the
Technical Lead) to make Ed give him a copy of the data, and Rod directed Ed to
give Greg the data. When this data was subsequently analyzed with the ITB, the
result was the skewed data shown in figs 38, 39 & 40 (above).
Initially this data and graph
were confusing, I’d never seen anything like this before; and it met with great
scoffing and derision from GMT. However, upon studying this data and
putting it into context with other information, it was deduced that GMT’s
reaction was all a deflection & cover-up.
When viewed in context with:
The system problems and blade positioning accuracy
data from USACE’s 2007 blade survey
The information in the October
3, 2005 HOT meeting minutes,
Two Power Point Presentations found on the HDC server:
a. http://www.nwd-wc.usace.army.mil/tmt/agendas/2008/0423_3DCAM_TMT_Apr08.ppt
b. http://www.nwd-wc.usace.army.mil/tmt/agendas/2009/0225_3D%20Cam%20Update%20Feb%2009.pdf
The design of the mechanism of the GDACS 3-D cam
actuator (detailed above) and
Dan Perrier’s informative dissertation (detailed
above) on the “parallelogram spiral motion” of the Kaplan blades with
the GDACS 3-D cams.
In the light of this
background information, a full understanding of the system that made this data
and how it occurred can be acquired.
It is now clearly obvious
what was going on. This problem is made especially bad in light of HDC HOT
meeting’s presentation blade survey data to the HOT meeting that tells of 65
faults a month at McNary. The data in the graphs of figs 38, 39 &
40 is what the fault condition looks like.
It is absolutely certain
that when the 1% efficiency envelope requirement is on these units from the
BiOp and Court’s ruling in the ongoing Endangered Species Act lawsuit, when
the fault condition is occurring - this unit will always be grossly out of
compliance with the Court order and should not be operated at all. For HDC
personnel to perpetuate this technical abomination and cover it up for 20+
years is blatant Contempt of this Court’s order.
Later-I
learned that this stepper-motor rotating “slip-cam” mechanism had been brought
to Woodward Governor in 1984 to get assistance from Woodward’s hydro turbine
governor design engineers with control issues. Woodard panned the USACE limited
authority digital “slip-cam,” mechanism saying it would be very difficult to
dynamically control this contraption - and then tried to sell Woodward’s own
3-D cam and blade control equipment to the Government instead. There may have
been some angst on the part of Woodward to see that USACE was devising a
different 3-D cam mechanism instead of buying more of Woodward’s 3-D cam
product that had been proven successful at Bonneville Dam in 1980.
How
much unmitigated gall does this show – for HDC to make an obvious replacement
for Woodward’s electronic 3-D cams at Bonneville, and then to bring this device
to Woodward for assistance with making it work properly!
An “off the record”
comment about this from USACE personnel was that these units were tripping out
so frequently at McNary that the operators became exasperated and quit going
out to the unit governor cabinets to reset the blade controller whenever the
blade controller tripped out (approximately 65 times a month Fig 35, an
excerpt from HDC blade-survey results presented to a HOT meeting), so this
misalignment would exist for extended periods of time because the 3-D cam
algorithm that is supposed to be raising and lowering the blades above and
below the cam’s linear taper baseline was disabled - because the unit had
tripped out and was unable to move the stepper motor and blades. As power
generation level made large excursions, the blades would become grossly
misaligned away from the “on-cam” line as shown in figs 38, 39 & 40.
I
suspect the operators liked it better this way, because when the 3-D cams were
tripped out the unpredictable surges and drop-offs of power that occurred 35
seconds after a large gate position change when the blade controller “woke-up”
would not be happening.
When we went to McNary in
December 2005 for the fourth Proof of Concept test, I told Rod I wanted to
leave the ITB running overnight again, collecting data to demonstrate the
automatic, unattended data collection (and to possibly capture another of
these “McNary-Skews” to show it was real). Rod told me that GMT had
preemptively forbidden us to run the ITB overnight; he had been told before
leaving HDC not to permit it – thereby denying an
opportunity to demonstrate that reliable, unattended data collection was
possible by letting the ITB collect data unattended for the 15 hours we’d be
away from the powerplant, and to perpetuate the cover-up of a serious
GDACS 3-D cam equipment problem.
The
operative question to ask GDACS Maintenance Team (Dick Nelson, Ed Miska et al)
from this is, “What did they know about this problem, and when did they know it?”
And, why didn’t they fix it?
If GMT (Dick Nelson, Ed Miska et al) already knew that there was a problem with
the GDACS 3-D cam and they wanted to protect the status-quo by covering it up,
that would provide an explanation and motive for many of the things that
happened: removing the X-Y graphical display from the ITB, why Ed was so
reluctance to give Greg the August 2005 overnight run data, and also explains
why GMT wouldn’t want the ITB to be capturing any overnight data in the
December 2005 testing; any of these would further expose this sub-standard
equipment malfunctions of GMT’s GDACS 3-D cams.
This
equipment was designed by HDC personnel and then mass-produced and deployed by
HDC’s “captive supplier,” Automated Control Systems Incorporated. This
equipment doesn’t meet nominal industry standards, so HDC just broadened the
allowable blade position “deadband” tolerance from the industry standard 1.0%
to an excessive 1.0-degree (or from 1.0% to 12.9%).
Figure 40 McNary Skew with On-Cam line for existing 74.2 ft head with ASME/IEEE 1.0% limits and USACE 1.0-degree McNary limits drawn for reference.
Figure 40 has exactly the
same information as Figure 39, except for the addition of the USACE assigned
1.0-degree deadbands for contrast and comparison.
These
arbitrarily defined Government limits at 1.0-degee are a typical Government
approach to a problem – if the equipment’s performance is out of limits, move
the limits out of the way so the equipment is no longer “out of limits.”
The
USACE Inspector General refused to take any corrective action on this, excusing
this sub-standard equipment because USACE’s Contracting Officer had neglected
to reference the applicable hydroelectric controls industry standards in the
acquisition paperwork (blanket order sole source contract and task orders to
ACSI) for this equipment. (Perhaps the complaint should have been about the
Contracting Officer neglecting to do the paperwork properly.)
The
continual and permanent blade positioning error resulting from misassembled
gate servo linkages, the intentional, programmed excessive deadband in the
GDACS 3-D cam blade control system, and 50+ year of running these machines
without ever index testing and optimizing every single one of them – the
combined effect of this cascade of mismanagement has resulted in
excessive blade misalignment and increased flow turbulence & shear forces
that increase the hazard to and mortality of downstream migrant juvenile fish -
and may ultimately result in removal of at least 4 of these hydroelectric
powerplants. All of this is in violation of the Endangered Species Act’s
directive that only the “best available science” be used; not to mention the
millions and millions of dollars the Federal Treasury has been denied due to
this procurement favoritism and ongoing waste.
Doesn’t anyone in the
Government have a problem with this?
To demonstrate the ITB’s
ability to analyze this data, a short video-capture of the monitor of my ITB
while generating the graphs shown in figures 38, 39 & 40 has been prepared
and uploaded to ATECo website. To see this movie, click this icon:
http://actuationtestequipment.com/McNary_Skew.wmv
This
movie is just the setup and preparation for a running display of all of the
McNary data files.
(I recently acquired this
video production software. A few of the first few videos I’ve made thus far are
linked to in this letter to show some of the data and test features I’m
presenting here. I’m ready to start marketing it and want to make a series of
video movies, the choices were either to teach a production company how to
index test turbines, or learn how to run the Camtasia software to make the
video movies myself. Me learning to run the Camtasia program won out. The video
movies are still a little rough around the edges, but should clearly present
the technical situation I’m trying to describe to you here. The videos will get
a little more polish on them later, after I get the subject material collated
and documented, first. If you come back and view them again in a week or so,
they will be much improved.)
Figure_41 Excerpt from HDC Response, complaint about voluminous data
This is a blatant
misrepresentation; I dispute all of it.
The massive amounts
of data are necessary;
I’m the expert at computer data acquisition, manipulation and analysis, I
created (and was awarded a patent for) the original 1985 Index Test Box
successfully field tested in 1985 & 1987, and the successfully field-tested
“proof of concept” Index Test Box from the 2005 & 2006 Index Test Box
field-tests at McNary and Ice Harbor, and I say that the “massive data points”
have a useful purpose; that’s what I still say - and will demonstrate below.
If
I were not the expert, then why did HDC buy my technology and hire me in the
first place? The prime example of this is shown in the StripChart and
SteadyState analysis video presentations below. Both of these were prepared
using the “massive amount of data” collected with HDC’s own GBO! The GBO took
much more data than the ITB was allowed to, and I think the “massive amounts”
of data that the GBO collected is very good.
With computers, large amounts
of data are easy to manipulate; acquiring “massive amounts” of multiple,
successive readings that repeat exactly provides an elevated degree of
confidence so that the analysis can ascertain that a data point was indeed
“SteadyState,” and not a “snapshot” of a unit that was in transition from one
operating level to another. Achieving “steady state” data is the most
daunting task when index testing, and the ability to detect SteadyState
operation is the single most powerful feature of the Index Test Box.
By repeating the same data
point over and over, and then computing the standard deviation and average
value of that large number of measurements, the ITB provides not only the single-point
average value that HDC personnel were looking for, but also the standard
deviation result provided by the ITB enhances the level of confidence in
the data when the standard deviation is a small number.
The “massive amounts of data”
also
facilitates a “Strip Chart” display so that dynamic performance,
robustness and stability of the governor and blade control system can be
visually evaluated. This playback of data captured by GBO from McNary unit 9 in
October 2007 shows how useful massive amounts of data can be – using
HDC’s own GBO data.
This
movie has a visual jitter in it that is caused by a Camtasia software problem,
the music is too loud and the sound cuts out about 2/3 of the way through. Not
ready for the Cannes film festival yet, but getting better. Kudos if you
recognize the music.
The 2007 GBO field-test data
was acquired from USACE via FOIA in 2008.
Click on the image of
the StripChart or XY-Plot below to see a video movie of how the ITB formats and
displays the GBO data.
The “massive amounts of data”
makes possible the “off-line” PostProcessing of data captured in the field by
the Index Test Box, the Gate Blade Optimizer and Brookfield Power’s SCADA
system in Canada. This video clip shows how the Index Test Box can analyze the
Brookfield Power and Gate Blade Optimizer data collected at Clergue earlier
this year and on Unit 9 at McNary in October 2007. The movie is 26 minutes
long; the first half of it shows index testing of multiple turbines (3) at
Clergue, simultaneously (which is the project I’m working on now). The last
half of the video shows analysis of 5 Gate Blade Optimizer data files to glean
out the SteadyState data points in them.
As
I understand your GBO situation, this is something you need right now. If
HDC were to send me the GBO field data that has been piling up, I’d run a few
samples of it through my Index Test Box PostProcessor to show that I’ve got
just the tool you need.
Click this link to see the
PostProcessor analyze GBO field-test data from October 2007.
ATECo
ITB PostProcessor Analysis of Clergue and GBO data files for QuickTime &
1000 x 768 monitor
This data was “separately
evaluated” by me, and it was by my design that the
ITB took “massive amounts of data” because my vision for the ITB’s
functionality (a complete turbine control system checkout, for one) is
much greater than HDC’s limited vision of its usefulness. The StripChart below
and XY Plots of the “McNary skew” in figures 38, 39 & 40 are two
examples.
As reported by an email
from your Dan Ramirez to Rod Wittinger on 21 February 2006 after the Ice
harbor testing, per HDC’s request I had added a feature to the
Index Test Box that recorded just one data point instead of the
Massive amounts of data that were undesired, and it worked like
they wanted it to. And now they are complaining about it?
Figure 42 Excerpt from Dan Ramirez's Feb 21, 2006 email to Rod reporting on Ice Harbor testing
What HDC is missing here is
the full scope of the Index Test Box functionality. The ITB provides a complete
system checkout for a hydroelectric unit. If the gate and blade actuators are
not robust and accurate in positioning these variable geometries for a Kaplan
turbine, then the unit will be unable to achieve the optimum gate and blade positioning
and the promised benefits of greater efficiency and reduced fish mortality from
index testing will not be realized.
Broad Brush Index Test Box Unit Checkout
Fundamentals
Because index testing is
often done without shutting the unit down, some of these checks cannot be done
- in all cases.
Gate and Blade Actuator Design and
Functional Checkout
1.) The first step in index
testing a Kaplan unit is to check gates and blades to verify they move freely
from stop-to-stop, and have full travel with no binding or excessive hysteresis
anywhere. The ITB (or any other data recording equipment) should be used to
capture servo pressures vs. position data for analysis and to document unit
condition. This check should be performed with the unit both dewatered, and after
a few more design-integrity safety checks, while operating normally.
2.) ITB has an integrated
pressure-gain test to facilitate #1. Two analog inputs for differential
pressure transducers measure gate & blade servo piston rod & head
pressures during the stop-to-stop actuator checks; these pressures are recorded
while the unit’s gates and blades are exercised full-travel to observe the
pressure imbalance necessary to move and hold the gates and blades at various
positions. By looking at the pressures driving the servos and the resulting
motion of gates and blades, much can be learned about the condition of a unit.
Pressure gain, static holding pressures at a number of points - and in the
event of control-system pressure loss, where the gates and blades will drift to
without control input.
3.) It is imperative that the
gate servo force is great enough to shut the machine down under any operating
conditions to prevent unit runaway. On more than one occasion unit runaway has
resulted from up-scaling turbine runners and gates without a corresponding
up-scale replacement for the gate actuator and/or pressure supply system.
Measuring, analyzing and documenting the servo pressures as described above
will provide assurance that this problem does not exist.
4.) Making sure that the rod
and head pressures are always pushing the gates in the opening direction,
instead of holding them back from flopping wide open is another important
safety check to make sure that the gate actuator design is such that in the event
of pressure loss, the unit will drift to a safe “speed no load” condition
instead of a catastrophic “full open” condition. In a properly designed system,
the unit will go to speed-no-load upon a full pressure loss.
More specifically; the sum of all the forces of the water
passing by the wicket gates can be summed to a single vector acting at a
specific point on the gate called the “center of pressure, which is not
stationary, but moves with changes in the flow rate, independent of
head. If the center of pressure is located outside of the gates and
upstream of the gates' axis of rotation, the gates have a closing
tendency. This is desired so that if governor control of the
gates is lost, they will drift in a closing direction. Well-designed
gates will drift to the speed-no-load opening (instead of fully
closed) to avoid creating a pressure transient or “waterhammer.”
At extreme flow conditions, this center of pressure may move downstream of the
gates’ axis of rotation creating an opening force on the gates. In the
problematic cases this force is greater than the gate servomotor force and the
governor cannot shut down the unit. These gate operator torques are
usually measured as part of a turbine model test to size the wicket gate
servomotors and gate linkages, but are often overlooked when runners are
replaced and/or up-scaled.
5.) For robust control and
accuracy, hysteresis (slop) at all points across the full travel of the unit’s
gates and blades must be within industry-accepted standards; the ITB pressure
gain and full-travel actuator tests will verify this easily and quickly.
3-D Cam and Blade
Positioner Checkout
6.) Verifying that the 3-dimensional head
and gate to blade data surface in the machine is correct is essential to optimum
performance. On more than one occasion the ITB’s Cartesian coordinates X-Y plot
features have shown that the data programmed into the 3-D cam was not what
the operators thought it was. The ITB’s visual checkout feature for 3-D cam
data surfaces provides a quick, easy checkout of what’s really in the machine.
Governor Robustness,
Accuracy and Stability
7.) Stable and robust
governor action in controlling the unit’s gates and blades is essential to
satisfactory performance. Industry standards for slew rate and damping ratio
provide guidelines for adequate and proper control system action. Instabilities
and excessive dithering (or wandering of gates and blades) not only introduces
unwanted disturbances into the grid, but also causes premature wear on turbine
mechanisms. When the trunion bearings on Kaplan units wear out, hub oil can
leak into the water, resulting in an adverse environmental impact.
Blade Positioner Robustness, Accuracy and
Stability
8.) Robust and accurate blade
positioning is essential to satisfactory Kaplan unit performance. The rule of
thumb is for the blades’ slew rate to be 1/3 that of the gates’. That is to
say, if the gate maximum slew rate is 30%/second, then the blade maximum slew
rate should be no slower than 10%/second.
The ITB’s StripChart &
X-Y Plot data analysis tools and display features provide a quick and easy way
to identify problem areas and ascertain appropriate unit performance.
Figure 43 StripChart display of GBO data from McNary Unit 9 on 10-09-2007. Click the image to download and play a video movie about the ITB StripChart that uses this data for an example.
The HDC Response document
says the ITB could not operate unattended during the December 2005 McNary field
test, but did not properly identify the cause – it was because of the
sub-standard GDACS 3-D cam’s excessive deadband and deadtime. The ITB is intended to operate using the preferred Constant
Power testing method. In order for this method to work properly, the
governor must be robust, accurate and unit operation must be stable, which
USACE’s Kaplan units are not.
My analysis says that the HDC Response document’s interpretation is
ignoring the underlying, inherent problems with the GDACS 3-D cam control
system (described above) and criticizing the ITB to deflect attention away
from USACE’s self-inflicted GDACS 3-D cam problems. The 1.0-degree deadband and
35-second deadtime designed into this control system are the only reason
why the ITB’s automatic, unattended Constant Power index test could not
be done.
My
opinion is that GMT’s directive to remove the most powerful and useful
diagnostic tools from the ITB demonstrates a COVER-UP, in that GMT knew of the
sub-standard condition of the 3-D cam and blade control equipment and didn’t
want it exposed by my instrument. This sub-standard turbine control system has
resulted from HDC’s practice of designing their own control systems for these
units and then sub-contracting the mass-production and deployment of it to a
“captive-supplier” created by HDC for this purpose. The result of this “industrial
incest” is the deployment of sub-standard control system equipment throughout
FCRPS that has caused excessive blade misalignment, higher turbulence and
greater fish mortality, driving some fish species into extinction, and brought
about a Federal Endangered Species Act lawsuit.
How
long does HDC think they can keep a lid on all of this?
The ITB could not perform
the unattended “Constant Power” index test procedure due to the sub-standard
GDACS 3-D cam.
Who’s Zoomin’ Who?
Figure 44 Excerpt from HDC Response disparaging my capabilities.
To the contrary, HDC engineers do not have a clear understanding or the demonstrated engineering expertise or the moral authority to judge my
work or to make the above statements. I say this based on the known history of
ethical misconduct by HDC personnel and the sub-standard quality of the control
systems that HDC has devised and deployed on turbines throughout FCRPS for over
20 years - and the continuing cover-up of
this awful situation – all with disastrous results.
With successive failures of the Seawell 3-D cams, and now
the sub-standard GDACS 3-D cams; the abject failure of the 3 digital governors
that HDC and ACSI attempted to design and build at Albani Falls, HDC had
demonstrated that they are incapable of creating
a workable dynamic digital governor, 3-D cam or blade control system for a
hydroelectric turbine, and should get
out of the governor business altogether. The December 2005 ITB field test
data from McNary; the analysis of HDC’s own GBO data received under FOIA from
HDC, the intentional 1.0 degree deadband at McNary, the typical
0.5-degree deadband that are instituted everywhere else (as documented in Rod
Wittinger’s December 2006 ITB field-test report); the 35 second deadtime
that is used at McNary (and probably with all other GDACS 3-D cams everywhere
else) are not found in any other hydro turbine control system anywhere else in the world. And now I’m hearing that the
trunion bearing wear problem is so bad that in some instances the runner blades
on USACE Kaplan turbines are simply being welded
in place, converting the Kaplan turbines into fixed-blade propeller
turbines!
HDC makes the world’s
worst dynamic hydroturbine controls.
The level of engineering expertise shown by the 2007 Blade
Survey pictures from McNary Dam is problematic. According to HDC presentations
documented in HOT Meeting minutes and found on HDC’s server, they were having
severe problems with blade control systems controllers “tripping out” due to
binding of the “string-pots” used as blade position sensors used for control
system feedback.
Figure 45 Excerpt from PowerPoint presentation found on-line with Google search
These
pictures are from an HDC Power Point presentation was found on the Internet by
a Google search with input string “USACE GDACS.”
http://www.nwd-wc.usace.army.mil/tmt/agendas/2008/0423_3DCAM_TMT_Apr08.ppt
This
is a level of engineering expertise and craftsmanship one would expect to see
in a high-school science fair, not in the U.S. Governments’ hydroelectric
facilities.
Slide # 11 of http://www.nwd-wc.usace.army.mil/tmt/agendas/2008/0423_3DCAM_TMT_Apr08.ppt
shows these problems still exist in 2008, and the general situation is
unacceptable.
Figure 46 Slide #11 of USACE Power Point
0423_3DCAM_TMT-Apr08.ppt
This
information was also found in HOT Meeting minutes from March 11, 2007. A second
Power Point presentation from February 2009 shows that the situation was still
not compliant with nominal industry-accepted standards two years later, but seems to be getting better.
http://www.nwd-wc.usace.army.mil/tmt/agendas/2009/0225_3D%20Cam%20Update%20Feb%2009.pdf
I
believe that had I not brought this situation to the attention of DOD IG, which
prompted the 2007 Blade Survey, HDC’s GMT would still be covering-up this
sub-standard equipment - and none of the corrective actions detailed in the HOT
meeting minutes and the Power Point presentations would be getting done; and
everyone up and down the river would be wondering why the fish populations are
still in decline. Blade misalignment creates more turbulence and shear forces
in the water flowing through the turbines, resulting in increased hazard to
downstream migrant fish. Why else would the BiOp call for the peak 1%
operating-efficiency envelope? It matters.
Here's another
curiosity - Googling a few phrases and names associated with USACE, HDC, GDACS
and ACSI turned up a lot of curious information on the Internet. Assuming there
is only One “Dan Perrier” working on hydroelectric turbine design engineering
using “ModBus” I/O (hydro is a small community, after all) let me go out on a
limb here…
Dan Perrier is
purported to be a hydroelectric turbine controls expert. If so, then why was he
asking the Control.com bulletin board about rotary sensors for Modbus
RTU to read hydroelectric turbine gate angle in 2001? That’s approximately the
time frame that the GDACS 3-D Cams were going in at McNary. Dan was
apparently a “first-timer” on that job to be looking for this kind of advice.
Figure 47 Web Page from Control.com showing Dan Perrier’s Nov 9, 2001 inquiry about gates at a hydroelectric project.
And why
would he call it a "multi-turn" application? And how
could the design end up with string pots? Apparently HDC’s engineers and
Dan (ACSI) had no prior experience with hydroelectric turbine control systems
when they started working on this job – and it shows. This system was designed
and built by rookies.
Nobody at HDC or
ACSI had ever built a hydro-turbine governor or 3-D cam before, yet they were
allowed to design, mass-produce and deploy the 3-D cams for McNary with no
prior practical experience.
The suggested
method from the bulletin board was to use a “rotary encoder.” (That was good
advice; they should have followed it.) Several Ex-Woodward’s engineers tell
me that USBR specified no contacting feedback position sensors, i.e. USBR
said “no potentiometers” in their RFQs because potentiometer wipers don't
have a long enough life span for hydro applications. Then and now,
competent hydroelectric governor designers don’t use potentiometers; they use
non-contacting sensors - Resolvers, RVDTs or optical encoders that
never wear out. Potentiometers are known throughout the
hydro-industry to be unacceptable, and potentiometers configured as
“string-pots” are an even worse selection for hydroelectric turbine control
system feedback sensors.
Any engineer with the slightest modicum of experience would
never have used string-pots for a Kaplan turbine feedback element. There’s no
beginners luck in hydro, unfortunately.
When this picture (fig 45) is shown to hydroelectric turbine controls engineers across the private sector as an example of the Corps of Engineers’ level of technology and design expertise as employed with GDACS, they just laugh, shake their heads and mumble words to the effect of, “Close enough for government work.” The Corps of Engineers Hydro Design Center and ACSI caused this problem because they simply did not having the knowledge, practical experience, expertise or know-how to make a robust, accurate and reliable Kaplan turbine control system – they are rookies who don’t know what they are doing, and they’ve made a mess of the Kaplan turbine blade control systems all up and down the river – and should be stopped before they do any more damage.
Another Problem with this
During my initial
discussions with Ed Miska in 2004 about how to interface my Index Test Box to
the turbine control system at McNary, he provided disinformation about
the nature of the sensors used for the gate and blade positions. As part of the
“configuration control” that the government wrote into my contract, Rod
Wittinger directed me to tap into the already digitized, pre-existing gate,
blade and power sensors in some way; this was in order to avoid having two
error stackups from two sets of sensors, signal conditioners and analog to
digital conversions between the index testing data stream and the data stream
that was being used to operate the 3-D cam. Restating: Rod wanted the
Index Test Box to get the exact same information that the 3-D cam was using to
avoid this dual-channel error/tolerance stack-up.
Using the Homeland
Security Act security protocols as their justification, the GDACS Maintenance
Team (GMT) prohibited any connection of my computer to their SCADA turbine
control system, so as an alternative we considered tapping into the rotary
optical sensors that Ed Miska said were used on the GDACS control system
for all gates and blades. Ed told me the gate and blade sensors were all
16-bit optical encoders, and attempted to discourage me from connecting my
Index Test Box interfacing to the existing sensors in this way because there
would be so many wires to connect. I persisted by explaining that there
was no way that a software bug could get into the GDACS if I tapped into the
16-line digital signal wires coming from the optical encoders; and by using
printed circuit boards, ribbon cable and electrical connectors, making many
signal connections for these 16-bit encoders would not be too difficult and it
would provide a digital, error-free interface. It seemed an acceptable way to
go, to me.
After several
distracted and halting discussions about how to proceed with this interface,
GMT relented and I was allowed to connect to the GDACS. Now from HOT meeting
minutes and the Internet I find out that HDC and ACSI were not really using
16-bit optical encoders after all - instead they are simple “string-pots.”
This is significant
because 1.) Ed was misleading me about the kind of sensors they were using, and
2.) the cost of these sensors. Rotary optical encoders cost $1,200 to $2,400
each in the early 2000’s when the GDACS was installed at McNary, while the
string pots they actually used cost less than $300 each. There are three
additional rotary transducers on the gates of the units; this same question
applies to them. There are 113 Kaplans, each with 4 rotary sensors. Simple
math shows a potential discrepancy of the $135,600 to buy string-pots and from
$542,400 to $1,084,800 to buy 16 bit rotary optical encoders.
If an investigation
were to look at the bill of materials of the McNary installation and found the
more expensive optical rotary encoders that Ed told me were on the turbines
were listed line-items, but the much cheaper rotary and string pots were
used on the turbines instead, this becomes an even worse situation - the
resulting control system faults and other problems that USACE is suffering can
be traced to contracting fraud.
Somebody should
look into this.
Which brings us to the abject failure of the Albani Falls
digital governor project. This was a blatant (albeit informal) attempt to skim
(a.k.a. pirate) technologies from across the hydroturbine controls industry -
HDC and ACSI approached turbine controls companies across the country with a “song
and dance” about acquiring and merging the best technologies from
the best companies to make the best hydroturbine control system
possible, saying that everyone who participated would reap the rewards - nobody was fooled.
All of the vendors believed that after HDC and ACSI
arrived at the best possible hydroturbine control system, HDC would
simply co-opt the designs, and then everything possible would be subcontracted
locally; pirating these technologies from the companies that originally
developed them – just like we saw with L&S Electric’s pilot valve plates at
Albani Falls. This entire plan was just shameful. What was worse - HDC didn’t think anyone could see through it.
The recent HDC
Solicitation that resulted in a $10.6
million purchase order to American Governor Company (reported in Hydro Review)
is a “formalized” example of this practice. Many hydroturbine control companies
rejected this Solicitation outright because it was worded in such a way a to
specifically open the way for HDC to again co-opt the designs and then
subcontract the mass-production and deployment of the 113 Kaplans in FCRPS to
more favored suppliers. Those companies that did enter bids placed legal
caveats in their bids to protect their intellectual property because the
Solicitation was such an obvious ploy to obtain a workable governor design and
only one demonstration unit, and then
leave the way open to buy the full quantity of the final design from a more
favored contractor, i.e. ACSI.
All of this shows a lack of common decency & ethics,
engineering expertise, functional knowledge of hydroturbine governor systems
and dynamic system control theory, which precludes any judgment of my
work by the engineers at HDC.
I have a uniquely broad spectrum of contacts in the
hydroturbine controls industry. When Woodward’s Hydro engineering group broke
up, all of Woodward’s hydroturbine engineers went to different hydro controls
companies throughout the industry and across the country. Because I make test
equipment for governors, and do not make actual governors (and only
recently started working in hydro), I’m not seen to be a competitor by any of
them and they all still feel free to communicate with me - because I’m not a
threat to their businesses. That’s how I came by these stories; by speaking
to ex-Woodward engineers working across the industry, comparing notes and
finding out what’s happening between their companies and HDC.
The first response I typically get when I tell what
happened to the ITB and me at HDC is, “Welcome to the club.”
In 2006, Dick Hollenbeck of SoftPLC desperately
wanted the digital governors being utilized for the Albani Falls digital governor
project by HDC and ACSI to be successful so that he could sell more of his
SoftPLC computers to the Government. When this project was failing, Dick went
to Wisconsin in an attempt to buy a working governor algorithm after seeing the
North American Hydro (now renamed
North American Phoenix Energy Systems) Transient Enhanced Proportional Integral
Derivative (TEPID) algorithm presentation by Dave Kornegay at a hydro industry
trade show.
Dick was trying to buy a functional hydro-governor
algorithm for HDC and ACSI to use in their digital governor project at Albani
Falls. Dick was quoted while on that
quest as saying that the Corps was giving his computers a “bad name.”
Dick also approached L&S Electric and American
Governor Company, but neither wanted to get their intellectual property stolen
by the Government and then given to ACSI to later see it show up in the
marketplace as a competing product to their own stuff - everyone refused to participate.
Piracy of intellectual property by HDC is commonplace.
Here’s another example: Based on his over 30-years of design and retrofitting
experience, Dave Bishoff at L&S Electric developed a Universal Pilot Valve Plate for adapting
currently available electro-hydraulic transducers and solenoids to older
hydromechanical governor equipment for hydroelectric turbines. When HDC was
working with ACSI to develop and build three digital
governors for Albani Falls, they purchased only two of L&S Electric’s Universal
Pilot Valve Plates for that job. One might ask, “How did that work?”
They put one of them on the development unit they were working on, and sent the
other out to be replicated by a local machine shop - in violation of the
Copyright and intellectual property protections on this item.
Figure 48 L&S Electric Universal Pilot Valve Plate
After HDC and ACSI walked away from the three failed
governors at Albani Falls, Darrlynne Allen, an engineer at Albani Falls needed
to implement a remote-start capability on these units. She found that after HDC
and ACSI were done with the digital governor project, these machines were not restored to their original condition and the documentation had not been updated to reflect the
changes that HDC and ACSI had put into the three turbine control systems.
Dave Ebner related how he had done the contracting work
for this job to get ACSI setup to provide these 3 digital governors, and then
subsequently had to subcontract the creation of “as built” drawings to Steve
Brockschink’s company to document the “after digital governor project”
condition of these machines. Steve was later showing his work-product to a
roundtable discussion at an IEEE meeting, where Terry Bauman (who is now
working at L&S Electric) recognized the universal pilot valve plates that
L&S Electric had supplied two of for HDC and ACSI to use in this project,
and could see that the third one was a
copy of the other two.
When Steve was contacted to compare notes, I learned that
he was a past USACE HDC employee who had retired from the Corps and was working
in the private sector, and that about 5 years earlier Steve had been working at
HDC and was Ed Miska’s boss. As I related my experiences, Steve quipped, “Yep, that’s our Ed.”
And lest we forget, the SCADA
Systems that HDC copied from whoever supplied them originally; renaming it
GDACS to distance it from whatever system they acquired and copied from
the private sector. The 3-D cam that is incorporated into the GDACS was modeled
after the 18 digital 3-D cams that Woodward Governor supplied for Bonneville Dam
in 1980, a USACE HDC project to make an “automatic index testing device” was
undertaken after seeing Woodward’s (my first) Index Test Box in 1987, and the
project to copy my current Index Test Box in 2007 was renamed Gate Blade
Optimizer (GBO) after my complaints to Inspectors’ General after HDC tried to
setup ACSI to make a copy of my ITB by diverting the funding at BPA that was
earmarked for T1 optimization away from my contract to this new endeavor.
The name change was ostensibly to “get it off the IG’s radar” so HDC personnel
could continue on with requests for funding from DOE to pay for HDC’s “in-house
GBO” project to replicate my Index Test Box. HDC is incorrigible in this.
Since the mid 1980’s, HDC has
aggressively pirated technology that was developed in the private sector,
created sub-contractors to build and deploy this equipment within their own
bailiwick (FCRPS) and then they have ventured back out into the private sector
into Canada via ACSI to market this equipment that was developed at government
expense in competition with the very companies they purloined the
technology from. This is very wrong.
Operationally, the GDACS
SCADA system seems to work OK, but it’s mostly just WonderWare and
other canned programs purchased and used as directed by the suppliers. The
GDACS SCADA functions without any of the “real-time,” dynamic functionality
that governors and blade controllers must have.
Where HDC really falls flat
is when it comes to building these automatic, dynamic turbine control systems
from scratch – as examples: The Seawell 3-D cams, GDACS 3-D cams and the
digital governors at Albani Falls - all are sub-standard or abject failures,
but this litany of failure doesn’t slow them down.
In the private
sector, HDC would have been bankrupt and out of business years ago.
It can arguably be said that
HDC’s meddling with the governors and control systems dating back to the
mid 1980’s, and the resulting blade misalignments and increased flow turbulence
in the turbines are a root cause of the fish mortality problem that is
the subject of the ongoing Federal Endangered Species Act lawsuit.
With this history of failure and
piracy of intellectual property, HDC’s personnel have no technical or moral
right to judge anyone else’s products. My purpose in writing this to you is to
vehemently object to the unfair vilification of my company, my products and
myself in the HDC Response document, and to say a few things that always go
unsaid - because despite all of the above - most of the hydroturbine
controls industry still lusts for the lucrative government contracts from HDC; I
however, do not.
I refuse
to subject my reputation to people whose primary objective was to learn how my
instrument worked, co-opt and steal whatever they could from me and then to go
forward claiming to have invented the Index Test Box themselves, and then
employ ACSI to mass produce and distribute it for them.
I feel like the little kid in
“The Emperor’s New Clothes”
who, after all of the pomp and circumstance finally says – “The Emperor
is naked!”
================================
To be sure: a high degree of expertise in data reduction was
required to invent the Index Test Box in the first place, and then to devise
the methodology used to create the graphs prepared from the McNary and Ice
Harbor data (as shown in figs 53 & 54 below). This expertise was also
required to write the Copyrighted software source code that generated these
graphs.
HDC’s personnel have a
lot of nerve to be so critical of me while they have so many failed projects
in their past - and then to present my work-product (fig 54) to BPA HOT as
their own work-product (fig 53) in order to get funding for the GBO project
(which, according to subsequent October 3, 2008 HOT meeting minutes and other
sources, ultimately failed to replicate my instrument and was a waste of time
and money).
Figure 49 Excerpt from October 3, 2008 HOT Abandoning
LabView based GBO
My
information shows that as a result of the failure of the LabView based
Gate Blade Optimizer project, Clay Fouts and Dennis Erickson were fired and Ed
Miska was reassigned to other duties in the Portland Division office. The GBO
LabView project was abandoned as a waste of funds, and due to this chicanery
and other problems the HOT meetings were discontinued by BPA.
Government Plagiarism
The McNary graph of fig 54
(left) was the final page of my report
on the McNary field test, and the Ice Harbor graph of fig 54 (right) was
produced on the ITB by me here, and then informally emailed to Dan
Ramirez to show how the ITB handles constant blade, swept gate index testing
data.
These graphs are my
work-product - but agreed, they are the property of the Government because I
was paid to produce them for the Government, however:
It is OK for the
Government to use them, but it is not OK for the Government to claim them as
HDC personnel or anybody else’s work-product; to claim that someone
other than me produced them is PLAIGARISM.
These graphs were introduced
as HDC personnel’s work product in the September
12, 2006 HOT meeting. They were in a Power
Point presentation put on by Ed Miska to the BPA HOT committee to show that
an automated Index Test Box for Kaplan turbines had been created and a
successful “proof of concept test” had demonstrated that it worked, so that HOT
would release more of the $3,500,000 earmarked for the Type 1 (T1) optimizer
to continue work on HDC’s in-house GBO project. What Ed didn’t say was where
the graphs came from - he credited HDC’s personnel (himself) and the GBO
instead of ATECo and my Index Test Box, and the money was diverted to projects
other than the successful Index Test Box.
The money didn’t go to
continued work on the successfully proof of concept tested Index Test Box,
it was diverted to another in-house project to replicate the successful Index
Test Box. The money was spent on the Gate Blade Optimizer project was worked on
by Ed Miska, Clay Fouts, Dennis Erickson and Professor Bart Rylander at HDC
instead of purchasing more of the successfully proof of concept tested
instruments that HDC (Rod Wittinger and Lee Sheldon) had purchased and
successfully tested one of from ATECo, and wanted to buy two more of.
Figure 50 Excerpt from October 3, 2008 HOT Minutes claiming advertised solicitations for Type 1 optimization equipment.
Here is a curious excerpt
from the October 3, 2008 HOT Meeting minutes. This is a false claim by HDC that
“Procurement was advertised twice and received no bids.” I watch these
things closely as do many of my hydro industry contacts; nobody saw these
solicitations. To inquire further, I contacted Ralph Banse Fay the HDC
Contracting Officer, who told me there had been no such solicitations
advertised from his office. To my mind, the only reason HDC would make this
false statement in a HOT meeting would be to dupe HOT (again) into giving more
of the T1-optimization money to HDC for the GBO project.
If there is another reason,
please tell me why HDC personnel made this false statement to the HOT.
It is incredulous that the
HDC Response document would decry my expertise and ability, yet HDC would
continue on with a project that was initiated by presenting my work-product (in
the form of these output graphs) to DOE BPA HOT as proof of a workable
automatic index Test Box for Kaplan Turbines.
Figure 51 side-by-side comparisons of ITB data to COE data acq data.
Here’s yet another look at
the ITB data results – the Excel spreadsheet* that Dan Ramirez used to
comparatively evaluate the Ice Harbor field testing Index Test Box results to
conventional index-test methods. He ran parallel index tests at Ice Harbor and
then compared the ITB output and “COE data acq” output data - this information
was acquired with another FOIA request.
*2006-02 Excel Spreadsheet of ITB & Ice Harbor data (Dan
Ramirez)
The graph in figure 51 above
is exactly as Dan created it in that spreadsheet. The correlation between the
ITB data and the COE data acquisition system’s data was very good, or “Virtually
identical” per HDC’s evaluation - as stated in the Power Point presented to
BPA HOT on 3 March 2006 (acquired from BPA under FOIA).
In that Power Point, HDC
stated that the results from my ITB were:
“virtually identical to
those obtained using COE data acq system”
And that my ITB was:
“Ready for ‘unattended,
automated’ data collection.”
Fig 51 below is the Power
Point slide from BPA that shows these comments.
Figure 52 PowerPoint slide presented to 3 March 2006 HOT meeting
Rod, Dan and Lee presented
this Power Pointed assessment to the HOT meeting in order to acquire additional
DOE funding on March 3, 2006 to purchase two more of my instruments
after the successful Ice Harbor testing; one unit with the OPC communication
interface to test at Chief Joseph Dam, and a second with an analog I/O board
and discreet sensor inputs to test at Dworshack.
The truth is that those
HDC personnel who working the most closely with my instrument, those with
the most knowledge of index testing fundamentals - deemed my Index Test
Box successful at index testing turbines - and they wanted two more of my
instruments – because they work.
Through FOIA requests to BPA
I learned that in a subsequent September 12, 2006 Power Point presentation, that HDC
personnel (Ed Miska) presented these two graphs (fig 53, below) to the HOT as
the work-product of HDC’s Gate Blade Optimizer (GBO) project.
The two graphs in fig 53 are
most certainly copies of the two graphs that I created with my Index Test Box
from data that it collected at McNary and Ice Harbor Dams, shown below in fig
54.
Indeed,
it has been said that, “imitation is the sincerest form of flattery.”
But
I would add, “Plagiarism is a close second.”
Figure 53 Graphs presented to HOT as output of Gate Blade Optimizer (GBO)
Figure 54 December 2005 McNary and February 2006 Ice Harbor graphs created with ITB
HDC was incapable of
producing these graphs that were submitted to BPA to get the funding they
wanted, so they just plagiarized the output graphs from my ITB – by falsely
misrepresenting these graphs to BPA HOT as output of GBO instead of properly
crediting my ITB for making them.
It was shocking to see the harsh critique of my ITB, my company and
myself in the HDC Response documents supporting a “marginal” rating, when my
work product from my successful instrument had been submitted by HDC to BPA for
more funding as proof of a successful “Proof of Concept” test - in what was
actually a quest for more funding for a different project by someone else.
To get to the truth
in this, ask HDC to
reproduce these graphs with their Gate Blade Optimizer from the data collected
on the December 2005 McNary index test and February 2005 Ice Harbor index test.
I can do it right now with my ITB - can they?
Who’s
the expert here? Snatch the pebble from my hand, grasshopper.
Substantiation of Allegations
The ITB graphs of fig 53 were
presented to BPA, falsely claimed as output of the GBO in order to get
additional funding for the GBO project. The HDC plan was to quickly recreate
the capability to automatically index test a Kaplan turbine and then to
develop the ability to create these graphs, all in a very short time
using the LabView programming language - and hopefully nobody would know the
difference. This deception failed.
This
is not the first time that LabView, advertised as the “programming language for
non programmers,” has led people to believe that there’s an easy way to do this
stuff.
A series of maneuvers in the
HOT Meetings between DOD and DOE personnel from HDC and BPA set the stage for
this fraud. This scheme ultimately defrauded DOE out of all funding
expended for the GBO project (approximately $1,500,000) because the basis for
going with the dubious GBO project instead of the successful ITB project was
the fraudulent misrepresentation of where the successful Proof of
Concept data graphs of fig 53 & 54 (above) came from, and then the GBO
project failed to produce a suitable replica of my ITB because even using
LabView, it’s still not a trivial exercise; I’ve been working on the Index Test
Box for over 20 years.
The ruse was in
HDC’s mischaracterizing of the ITB and the GBO as the same entity. Not so.
They are completely different
devices and totally disassociated. The street language for this scam is “bait
and switch;” the legal term is, “diversion of funds.”
It all started with HDC
acting as if the ITB technology was something they already owned; instead of
something that HDC has purchased one “study model” of, from me.
They didn’t get the ‘know-how” to build another one.
This link is to a copy of the
HDC Job posting where they are looking for someone to make a replica of my
instrument. http://actuationtestequipment.com/Reference_Materials/2007-01-04_HDC_Job_Solicitation.pdf,
and fig 55 is an excerpt showing the claim of ownership. The “production
version” they are speaking of would need to be designed “from scratch,” and
would not be building on the previously developed Index Test Box.
Figure 55 HDC's Job Posting on the Internet Claims that HDC owned the “developed” ITB.
It was said that Professor
Bart Rylander from Portland University got this job.
HDC was always planning to
hire ACSI to mass-produce and deploy my ITB technology (see fig 56) on a new
and different contract. In the May 23, 2006 HOT meeting between HDC and BPA, HDC was
cautious to avoid mentioning ACSI by name in their plans. The presentation on
the record in the HOT meeting from HDC personnel made no mention of ACSI by
name, simply phrasing the desired assemblage of personnel as an “appropriate
in-house/hired contractor team.”
Figure 56 Excerpt from October 3, 2008 HOT meeting minutes
Tom Murphy, the BPA HOT
committee chairman was not aware of the ruse - Tom was not so discreet in his
communications. In a June 8, 2006 email to the HDC personnel involved, Tom
apologized for pulling the plug on their plan to setup ACSI with a contract to
replicate my ITB, (which was designated the T1 optimizer by HDC) due to
enforcement’s investigations into allegations of procurement favoritism towards
ACSI.
Figure 57 Excerpt from Tom Murphy's June 8, 2006 email
With investigators looking
in on what was going on, BPA balked
at HDC’s plans to divert the funding allocated for Type 1 (or T1) optimization
to another contractor (ACSI), so the plan mutated into HDC’s in-house
Gate Blade Optimizer (GBO) project where HDC personnel and (subsequently)
rehired annuitants (Clay Fouts and Dennis Erickson) would make the first pass
at replicating the Index Test Box. Upon success of this instrument in another
“proof of concept” field test, the GBO would then be subcontracted to ACSI for
mass-production and deployment.
I first learned about the GBO
project from several attendees to the 2007 IEEE meeting in Chattanooga
Tennessee who were familiar with my Index Test Box, that I had sold one to
USACE, and that it had been successfully “proof of concept” demonstrated at
McNary and Ice Harbor.
Three men who had been in
attendance called me to report that Ed Miska had announced to an IEEE
roundtable meeting that HDC personnel had developed the automatic Kaplan
turbine index-testing instrument that was successfully demonstrated in FCRPS,
but called it the Gate Blade Optimizer (GBO) to disguise the similarity. A
rose by any other name…
Subsequent FOIA requests to
BPA learned that indeed, the designation for HDC’s T1 optimizer project had
been changed from Index Test Box (ITB) to Gate Blade Optimizer (GBO),
ostensibly to get it “off the radar” of the investigating authorities so HDC could
go forward with their plans.
Shortly after that, an HDC job posting was found on the Internet in which HDC made
the false claim to have developed the Index Test Box on a prior contract.
HDC purchased the
Index Test Box from Actuation Test Equipment Company, but falsely
claimed it as an in-house effort instead of crediting its origin to purchasing
this new technology from my company on Contract W9127N-04-D-0009.
Figure 58 Excerpt from HDC On-Line job posting, showing HDC’s false claim to Index Test Box technology
When this was questioned, Ed
Miska said that HDC had purchased index-testing systems from several vendors,
and HDC had simply gone with another vendor’s equipment, not mine.
This was yet another of
Ed’s falsehood.
It took several FOIA requests
to HDC’s Janice Sorensen to get the truth of it. After several requests I
finally got the February 8 2008 FOIA response signed by your Tim Anderson
that finally stated the truth - which was that mine was the only
index-testing contract that HDC had engaged in.
This excerpt shows my
specific question and HDC’s response:
Figure 59 Excerpt from FOIA response from HDC, Janice Sorensen and Tim Anderson
This “prior contract”
did not develop the Index Test Box; it only bought one of them.
After this FOIA request, in
order to stop my FOIA requests HDC’s FOIA office sent me a ream of scrap paper
in response to the next FOIA request, demanding $714 for this useless paper.
I already had what I needed
from HDC’s FOIA office, so I sent my next FOIA requests to BPA, who sent me a wealth
of information that showed very clearly what HDC had been doing.
This ongoing subterfuge was
all in order to gain DOE funding for the Gate Blade Optimizer project that HDC
personnel (Ed Miska, Clay Fouts and Dennis Erickson, and later Professor Bart
Rylander) were working on.
BPA personnel were unaware of
these deceptions by HDC personnel, but they soon learned of them. In
response to the FOIA request, BPA sent me a large volume of information that
shows how HDC personnel had been misrepresenting the Index Test Box project all
along. A
letter regarding this information was sent to Tom Murphy of BPA and to your
Charlie Allen for his response. None was forthcoming.
Now from the October 3, 2008 HOT meeting minutes (Ref# 6), not only did
the GBO project fail to make anything workable, but a subsequent FOIA response
just last week indicates there have been no subsequent HOT meetings for over
a year now, so it is presumed that they aren’t going to have any more HOT
meetings.
Financial information
acquired under FOIA from BPA show that the total cost of this fraud was the
diversion of over $1,500,000 of the DOE BPA funds earmarked for Type 1
automatic index testing; ostensibly this money was diverted from Contract
W9127N-04-D-0009.
Figure_60 Excerpt from HDC Response, a critique of ITB’s ATE-150 signal conditioner.
The ATE-150 was an
experimental prototype signal conditioning amplifier intended to normalize (by
scale and offset) a pressure transducer output voltage signal in order to fully
utilize the input resolution and span of the A/D converter input to the ITB,
and provide more signal conditioning flexibility so that no matter what
conditions were found in the field, what we brought with us to the test could
be adapted to work.
Using 10-turn calibrated gain
and offset potentiometers; different calibration setups could quickly be
arrived at and easily reproduced on future tests with the ATE-150. Once the
optimum values were dialed in on the ATE-150’s calibrated 10-turn pots,
isolation-amplifier signal conditioner modules could subsequently be setup with
these scale and offset values hard-wired into the amplifier modules with
hand-selected resistors to match the 10-turn pot settings in order to make a
permanent signal conditioner for the particular transducer being used. Ed
Miska objected to any such custom hardware, insisting I use only “off the
shelf” equipment for everything.
The rational for using such a signal conditioner was that if we have a 0 to
10 volt input I/O board, and we are only interested in 5,000 to 16,500 cubic
feet per second flow through the turbine, and we’re measuring the Winter
Kennedy pressure with a 200 inch Water Column (WC), 0 to 5 volt output
transducer, we could exactly match (or “normalize”) the pressure transducer’s
output to the 0 to 10 volt input span of the analog to digital converter board
in the ITB computer to maximize the measurement resolution.
What we did at McNary was
this; Unit 9’s flow constant was
5,818 cfs/(square root of Winter Kennedy differential pressure) from the 1999
USACE Index Test, which works out to the pressure range of interest being 8.8
to 91 inches of water column for the anticipated 5,000 to 16,500 cfs flow
range.
They don’t make a pressure
transducer in this range, and we wanted to be able to use our transducer on
other applications, so we bought a 200 inch water column transducer, which we
then planned to normalize with the ATE-150 by dialing it in to get 0 to 10
volts for the input board in the computer from the 8 to 100 inches of water
column differential pressure seen across the Winter Kennedy taps.
Another benefit of the
ATE-150 is that we weren’t limited to the standardized 4-20 mA output span. We
could setup a higher 10 to 100mA range if so desired; if we design and build
the signal conditioning and transmission equipment, we can have it any way we
want, providing much greater flexibility in our applications.
However - Lee Sheldon said he wanted to retain the zero point
in the calibration of the transducer to stay in his “comfort zone,” and was
willing to discard the unmeasured span under the lowest flow signal pressure
(about 10% of the pressure transducer span) anticipated, so for this reason the
ATE-150 was not really necessary.
Rod Wittinger said if we used
4-20mA transducers, the scaling could be set by selecting the voltage-dropping
resistor value (in Ohms) at the ITB to get the 10 volts for the analog input
board at 20mA, so again, the ATE-150 wasn’t really necessary.
But here’s the rub - the
reason we used voltage output transducers instead of 4-20mA transducers was
that we were rushed to get them.
(Everything about this project
was a rush and a hustle - seemingly to keep me off balance so it would be
easier to dupe me out of the pre-developed, copyrighted software source code.
I’m from northern Illinois, and am quite familiar with the “Chicago street
hustle,” I’ve been cheated by experts - the razzle-dazzle and runaround that I
got from HDC (Ed Miska) with the contract tampering and the continual
rush-to-test had pretty much the same feel to it. When we first met, I told Rod
Wittinger over lunch that, “I’ve been lied to, cheated on and swindled more
times than I can count - I’ve gotten better at keeping my own.” Rod replied,
“Me too…” and, “good luck.”)
The price and delivery of
a voltage output transducer was more attractive, so the ATE-150 and the
intended isolated amplifier modules were planned for use as 0 to 5-volt to
4-20mA-signal converters. A “judgment call” on my part, and I stand by it.
The ATE-150 (as sent to
McNary) was at a prototype stage of development because so much time had been
expended with the HDC-mandated ITB RS-232 to OPC communication conversion
(learning enough about OPC and getting the setup and data tag names from HDC
and ACSI, then learning that RS-Linx servers don’t work with Windows XP and
Visual Basic 6, documenting all of these problems in preparation for arguing
with Ed Miska to change away from RS-Linx to somebody else’s OPC servers, and
then locating, acquiring, learning about and applying the Software Toolbox
TopServer and then the struggle over the unlawful, deceptive, tampering with the
modified contract, all of these were not trivial concerns that consumed a lot
of time) that the completion of the design cycle and productionization of the
ATE-150 isolation/signal conditioner module for this was not completed in time,
so HDC’s “partnering meeting” crew said to just send the prototype anyway – rush,
rush, rush – everything was always a rush - but they wouldn’t fix my
contract so I could sign it and get paid for preparing and sending the
ATE-150 to McNary.
Let me put it all into
time-context for you here.
At the time that the
ATE-150 prototype was sent to McNary Dam (which resulted in the first failed
field-test), I was refusing to sign the modified contract that had been altered
to my disadvantage in secret by Ed Miska, so I wasn’t getting paid for
my work, and actually wasn’t even supposed to be working on the project
because I was refusing to sign the tampered with, modified contract and the
performance period had already expired. At this point I was working for
the Government for free.
Ed Miska was always HDC’s
point man at trying to cheat me with this illegally altered contract that they
were all compelling me to sign, so by using this fraudulently altered
document and a big rush to keep me off balance - HDC barred any ATECo personnel
from participating in the Proof of Concept field-test crew. While nobody
from my company would be there to see - the zero-problem could then be
utilized to discredit my company; my products and myself, leaving the way clear
to transfer the T1 optimizer project (and the $3,500,000 budget remaining on
the contract) to ACSI.
Which brings me to the main
reason I’m glad we used the ATE-150. After Ed got all of the
pieces in place for the zero-problem scheme, and everyone went to McNary Dam
(with no one from my company there) and Ed and Dan (ACSI) were prepared to
spring the trap - the ATE-150’s broken wire thwarted all of these plans.
What ultimately resulted
from this broken wire was Ed was discredited for not being able to fix a simple
broken wire in the ATE-150 after stating in the “partnering meeting” that he
and Dan (ACSI) could “handle it” and wouldn’t need any help from ATECo
personnel for the field test.
When the ATE-150 failed in
that August 12, 2005 index test, the ATE-150 was overnight FedEx’ed to me; it
was on my doorstep the next morning.
When it arrived, I was
busy working on deciphering the zero-problem, so I assigned my technician (Greg
Luna) to check it out. He removed the cover, and found the broken wire in less
than 5-minutes, and had it repaired and checked out & ready to use again in
under an hour.
Later that day, in a
phone-conversation with Rod Wittinger, I told him about the broken wire, how
easily Greg had fixed it, and chided Rod for allowing Ed to deny my sending Greg
to McNary Dam to help with the field-test. The next thing I knew after that -
the altered text of paragraph 3.4.2.9 was restored to its original form,
paragraph 3.4.3.9a was removed, Rod Wittinger was restored as the Project
Manager and Technical Lead, Lee Sheldon was returned as the HDC contact,
$20,000 was added to the bottom line and Ed Miska was removed altogether, which
cleared the way for me to sign the contract so that we could move forward with
the project.
This unexpected benefit of
using the ATE-150 was caused by a broken wire, which foiled Ed Miska and Dan
Perrier’s (ACSI) “zero-problem” scheme, so in this regard it was highly
advantageous to ATECo that the ATE-150 was used; this turn of events
saved my bacon - I like it.
Again, the ATE-150 was only
a prototype signal-scaling amplifier, and in my opinion it had a very, very
useful purpose in the end.
During the second failed
test, which Greg Luna participated in (I did not attend), Rod asked Greg what
had happened to the ATE-150 when we got it back - to double-check the story I
had told Rod on the phone. Greg’s story checked out, Rod was pleased - so this
story ended well, but now it seems HDC personnel don’t want to remember it this
way - I wouldn’t either.
Figure 61 Excerpt from HOT Response, a redundant ATE-150 complaint.
This is redundant; I’ve
already explained this fully at fig 60, above.
Figure 62 HDC Response complaining of bugs that were all fixed prior to Ice Harbor test
This is a subjective and
false statement. The McNary test was the first field-use of the ITB program
that was created from whole cloth, by me, based on my experiences with
this product while working at Woodward in the late 1980’s. To make it more
difficult, at the McNary field test, due to onerous and prohibitive GDACS
security protocols, I could not fix any bugs in the field - so the program had
to work the first time, “right out of the box.”
To put the onus for this
back on GMT: we were denied the
software check-out and debugging exercise the ITB would have received from
working with the “MockUp” that was written into the Contract. This test bench
checkout was denied when GMT took the MockUp away to hide and dismantle it in
the back storeroom at ACSI in order to deny me access to the MockUp.
In retrospect, all things
considered - I feel that there were actually very few bugs in the program
– but that is of no consequence now - Dan Ramirez reported that the bugs
that were found in the McNary test had been fixed by the time we went to the
Ice Harbor field test, so this point is moot.
Dan’s emailed report to Rod
et al, and HDC’s subsequent Power Point presentation to BPA HOT indicated the
ITB data was correct and accurate and the “bugs” had been fixed. This is a
compilation of all of Dan’s comments regarding ITB testing at Ice Harbor and
HDC’s HOT meeting presentation.
From Page 1:
Figure 63 Excerpt from Dan’s Ice Harbor email to Rod, reporting no difficulty calibrating the Winter Kennedy transducer. The square root of negative number issue was fixed.
Figure 64 Excerpt from Dan’s Ice Harbor email to Rod, reporting ITB conducted unattended testing in the background without any operator intervention while he ran the manual test. Blade perturbation was not attempted, but it was not due to any shortcoming of the Index Test Box that it was not used.
Figure 65 Excerpt from Dan’s Ice Harbor email to Rod, reporting setup detail for data collection.
Page 2:
Figure 66 Excerpt from Dan's Ice Harbor email to Rod, reporting setup details for data collection, and that I had provided the single-point data option that was requested.
Despite my disagreement with
HDC’s philosophy regarding whether to capture a single data points or collect massive
data points, preferably streaming continuous data to the hard drive, the ITB
program was modified per HDC’s request to produce a single point.
Figure 67 Excerpt from Dan’s Ice Harbor email to Rod, reporting no problems with ITB.
From this letter, it is
apparent that Dan gave ITB “thumbs-up” for collecting data for
developing cam information. None of the other comments in Dan’s letter are
negative.
Where did the HDC response
document get all the negativity?
The ultimate result from this
testing was that ITB results were presented to HOT after this test:
“virtually identical to
those obtained using COE data acq system”
And that the instrument
itself was ready for unattended testing:
“Ready for ‘unattended,
automated’ data collection.”
It seems that the HDC
Response document’s comments are in error, or an intentional distortion
of the facts to protect the status quo by discrediting my company, my products
and me.
Figure 68 Excerpt from HDC Response, a deflection of blame for this issue from Ed Miska to Me, this was not due to a problem with ITB; it was by Ed’s directives that it went this way.
This was a setup and a
scam by Ed Miska and Dan Perrier
of ACSI. The repeated transmission of program changes was made necessary by
Ed’s manipulations and directives, and now I’m being criticized for it? Incredible.
Here’s how it went down - I started asking Ed in August 2004 to get the task
order in place for ACSI to make the perturbation routine for the GDACS 3-D
cam’s SoftPLC. The ITB blade perturbation communication method required two
pieces of software. One to run in the ITB that I would write - and the other
that would run in the GDACS SoftPLC, that (Dan) ACSI would write.
I needed, and repeatedly
asked Ed to get the task-order in place for ACSI so they could do their part of
this first - so that I could install their perturbation routine in the SoftPLC
computer that I had here (which I had borrowed from McNary in August 2004 as a
development tool for working on the ITB to GDACS communication programming) in
order to develop and test the perturbation routine for the ITB myself,
here.
Instead, Ed wanted me to send
the ITB to HDC without this feature completed, and that I was to write the
perturbation software for the ITB here, compile the program into executable
form (here) and then send the “.exe” executable program to HDC so Ed could
install it in the ITB computer in Portland to test, and then Dan Perrier (ACSI)
could write the SoftPLC perturbation software routines, and then Ed and Dan (ACSI)
could test them both working together in the ITB and GDACS SoftPLC at HDC.
Ed delayed the Task order to
ACSI for 8 months until after the “performance period*” had run out. In this
way he was able to force me to send the ITB to HDC without the perturbation
routine completed when the performance period had run out – thus, in order to
write the perturbation software routines, by Ed’s plan it became necessary for
me to send these repeated program changes to HDC for Ed and Dan (ACSI) to test
them in the ITB that was connected to a SoftPLC with the GDACS 3-D Cam
perturbation routine in it.
*(The performance period was
the first year of the 5-year contract. During this first year, I was supposed to
make any modifications necessary to make ITB work with GDACS and get the data.)
As the Technical Lead, Ed
manipulated the project so I had to send repeated program changes to HDC to
setup and test the blade perturbation routine – it happened this way because
this was the way Ed wanted it.
Ed’s actual intent in this
was to get his hands into the design process of the ITB interface programming, with the purpose of continually moving the target so
everyone at HDC would get frustrated that it was taking too long, and then
everyone would pressure me that the only way to get the perturbation routine
done in a timely manner was for me to just send the Copyrighted source code to
HDC for Ed and Dan (ACSI) to complete the perturbation interface design and testing
there.
During this iterative
software development process, Ed and Dan (ACSI) found one of these revisions
that had a bug in it that randomly sent a zero as the SetPoint to the SoftPLC.
They preserved this version of the program, and contrived a problem (herein
called the “zero-problem”) within the blade perturbation communication
software that they could turn on and off at will – a problem that I could not
fix here because I could not duplicate it on my ITB test bench. By using this
program with a known “bug” in it, they planned show me to be incompetent
and get the ITB project away from me by this treachery.
To give them more of the
program to work with, instead of sending the entire Copyrighted source code
(for which HDC still had not paid the agreed upon $750,000) I sent a sub-set of
the Copyrighted source code with only the GDACS communication interface (not
the whole Index Test Box program) for Ed and Dan (ACSI) to work on. Ed and Dan
said this smaller block of code did not exhibit the zero-problem when they
compiled it at HDC; therefore I must send the entire Copyrighted source code to
HDC so they could debug the zero-problem in it for me. I refused to send it
until I got paid for it, so we continued on with me making program changes and
executables here, and Ed and Dan professing to have the zero-problem with all
of them, when in fact, they were faking-it.
By choreographing this known
bad program into the upcoming field test (with nobody from ATECo there), they
planned to show me as incompetent because I could not fix this problem, and
then they could discredit my company, my products and me. And then, by having a
“quick-fix” (the zero-snatcher) in hand, Dan would be able to be the “hero,” and
get the ITB project “back on track" for ACSI to continue-on working with,
and, as a bonus - in the “cure letter” phase of the
shutdown of my contract the Government’s lawyers would use a legal process to
seize my pre-developed copyrighted source code and give it to ACSI.
Rod Wittinger warned me of
this sort of thing over lunch during my first trip to Portland.
Goto Rod Wittinger’s warning over lunch
From the beginning of the
contact with HDC, it had been unnerving to me - and “switched on my radar” that
HDC personnel kept asking me if I had a patent on the ITB. I
always said, “Yes, but that it provided no protection because it had expired
– that’s why Rod had Lee Sheldon call me in 2004 to make another ITB for HDC - because
the patent had expired.”
This is why it was imperative
to me at the onset of the Contract interval to get some protection for my
intellectual property. In 2004, the Copyright office had recently started
offering copyrights on software, about 6-months prior to this. I took
advantage of this new service, and it “saved my bacon” in the end, so to speak.
I usually didn’t say anything
about the Copyright to anyone, until Dave Ebner told me after the February 2006
Ice Harbor field test that my project had been deemed a failure by Dick
Nelson (but we never could get any explanation of why or how it had failed,
just that it was being judged a failure because my ITB was “incompatible”
with GDACS, by Dick’s assessment) and that the Government was coming after me
with a “cure letter” to take all of the ITB equipment, software and drawings,
everything that was associated with the project; this noticeably upset Dave.
Throughout the project - HDC
had denied me all of the documentation, internal memoranda, test results and
any reports that would show any modicum of success. I didn’t have any
positive information until several FOIA requests to HDC finally got enough
information to be able to see what had happened; and then a few more FOIA
requests to BPA acquired the “rest of the story,” and enabled me to prove
what had happened.
Dick’s only explanation of
why my project was a failure was because it was “incompatible” with
GDACS. This was incredulous; connecting the ITB to GDACS to get data for a
turbine takes about 15 minutes to plug in the Internet Switch (The Internet
Switch is an “off the shelf” Ethernet communication module that allows the ITB
to tap into the GDACS Ethernet communication network.) module and get the
Internet Protocol (IP) address working. From the ITB roll-up to a unit to
logging data from that unit with the ITB took less than half an hour to make
the Ethernet connection and start acquiring data from GDACS.
By every definition I could
find, the ITB was completely compatible with GDACS – but only as a test
instrument to stand alongside the turbine governor cabinet - collecting data
for the index test - but this isn’t what Dick really wanted.
From the FOIA information
received from BPA, I was able to learn how the ITB was deemed “incompatible.”
The GDACS Maintenance Team decided they wanted to incorporate the ITB software
directly into the GDACS SoftPLC computer instead of having a stand-alone
instrument (that they had purchased from me) standing next to the governor
cabinet running the index test - this was not in the contract.
Without making any overtures
to acquire the technology that I had demonstrated at McNary and Ice Harbor, In
March 2006, USACE personnel started passing around a Power Point presentation
that claimed that they already had this technology in their possession, with
the outrageous assertion:
“Index test box code
already running on Walla Walla GDACS integrated platform.”
Figure 69 Power Point Slide from HDC claiming that ITB software is already Government property
This was a blatant
falsehood. “The Index test box code” was not and never has run on anything
other than the IBM PC computer that HDC purchased from my ATECo as the Index
Test Box on Line Item-0001 on page 2 of USACE Contract
W9127N-04-D-0009.
The first place this Power Point surfaced was in an
attachment to an email from Gerald Sauve from Walla Walla District to Tom
Murphy. I had never heard of this guy.
(The attached Power Point link is enabled to show the full
Power Point presentation).
=========================
From: Sauve,
Gerald L NWW [mailto:Gerald.L.Sauve@nww01.usace.army.mil]
Sent: Tuesday, March 07, 2006 8:13 AM
To: Murphy,Thomas R - PGF
Cc: Sauve, Gerald L NWW; Voss, Stephen W NWW; Walker, Larry P NWW
Subject: T1 Optimization with new 3-D Cams
Tom,
We talked recently and you
requested information on the advantages of the Walla Walla District style GDACS
integrated 3-D Cams. Here is a Power Point on the subject. Please
let me know what you think. If you like it, I will share it with the T1
subcommittee of the HOT.
Thanks,
Jerry
Then Tom Murphy forwarded it
to other HOT committee members to setup a meeting.
From: Murphy,Thomas R - PGF-6 [mailto:tmurphy@bpa.gov]
Sent: Monday, April 24, 2006 9:34 AM
To: Miska, Edward P NWP; Wittinger, Rodney J NWP;
Lee.sheldon@us.army.mil; Sauve, Gerald L NWW; Smith, David B NWP
Subject: FW: T1 Optimization with new 3-D Cams
Importance: High
I would like to schedule a meeting in late May to discuss the
attached presentation. Dave is there a way we could meet at Bonneville? Please
reply with the meeting dates that will work for you
It was premature for USACE
personnel to be claiming to have the Index test box code running in GDACS,
when they didn’t even have it. A buggy before the horse situation, it
seems.
The operative question is,
“Who prepared this Power Point that was taking credit for the Index Test Box
code?
A note on programming languages
The fact that I programmed the
ITB in Visual Basic 6 instead of C++ was the argument Dick Nelson made to show
my software incompatible with the GDACS SoftPLC computer, so Dick deemed the
entire project a failure. This was unfair and inappropriate – there was
no stipulation in the Contract for the software in the ITB to be able to run in
the SoftPLC computer in GDACS or specify the language used - the software
programming language was optional and at my discretion, and I chose Visual
Basic 6. For Dick to say that the ITB program not being programmed in C++ was
now a criterion for success or failure of the entire ITB project was just plain
wrong.
It is curious to me now that
when Ed Miska subsequently programmed his Gate Blade Optimizer, he used
LabView, another “incompatible” language that would not be able to run in a
SoftPLC computer – it seems there was a “double-standard” operating here, as
well.
Figure 70 Excerpt from HDC Response criticizing documentation. This was never a problem.
Goto
comments on documentation.
Figure 71 Excerpt from HDC Response. This comment is redundant and false.
Goto
comments on documentation.
Figure 72 Excerpt from HDC Response. This comment is ludicrous, redundant and blatantly false. It is a weak attempt to deflect fault from HDC to me, when the fault was due to Ed’s attempts to steal my software by fraudulently tampering with my contract, and my perception to see through the ruse and refuse to sign it and be cheated by Government personnel in this way.
This is blatantly false
deflection of the fault of this failure and obfuscation of the facts. Ed
Miska, acting as Technical Lead on the project, would not allow anyone from my
company to participate in this test because I refused to sign the illegally
altered contract. Any problems with this test are all the Government’s fault.
Figure 73 Excerpt from HDC Response. This comment is ludicrous, redundant and a collection of false statements.
The fault that caused this
field test to fail was incorrect labeling of the Winter Kennedy taps and the
powerplant blueprints were wrong. In no way can this failed test be blamed on
ATECo.
Goto
comments on second field test.
However, there was
unattended overnight running of the Index Test Box, collecting data on Unit 5
during this field test, which was when we captured the “McNary skew”
data discussed above.
There was documentation (albeit
not as good as I would have liked).
The source code for all of
the Co-Developed software was sent to HDC before this test. The
pre-developed Copyrighted source code for the core ITB program was never
supposed to be given to HDC until the negotiated agreed upon $750,000 price
for it was paid.
No errors or bugs could
have possibly been the problem on this field-test because no index testing
was attempted because the Winter Kennedy taps were deemed to be bad.
Ed Miska had already
addressed all GDACS security issues before the test was allowed to proceed, if
the ITB was such a risk, why did he allow this test to go forward?
Figure 74 Excerpt from HDC Response. These are a bunch of irrelevant and false statements.
The massive amounts of
data were by my design and proper.
The test crew did not ever
try to operate independently or unattended because we could not use the
ITB’s preferred testing method, the Constant Power test due to
the Sub-Standard GDACS 3-D cam’s excessive deadband and deadtime. To workaround
this problem and show the ITB SteadyState sampling routine and parabolic
constant power gate to blade sweep phenomenon, a compromise was made with Rod
Wittinger. The workaround method was to position the turbine’s gates with the
gate-limit and then set the blades with the ITB perturbation feature, all the
ITB was called on to do was monitor unit operation and collect a data point
when it detected SteadyState operation, which was determined by the ANALYSIS
of the data. The ITB worked flawlessly at this.
Contrary to the HDC Response
comments, the ITB did analyze data.
The ITB did have
documentation, though again, not as good as I would have liked.
The source code requirements
were absolutely complied with – TO THE LETTER.
The Co-Developed code was
emailed to HDC 3-days prior to our coming to Portland for the test.
The Copyrighted source
code was never supposed to be given to HDC until the agreed up on price of
$750,000 was paid to BUY IT.
It’s a simple rule of
business – IF YOU DON’T PAY FOR IT, YOU DON’T GET IT.
Figure 75 Excerpt from HDC Response. This complaint is a misinterpretation of the Software Special License Agreement.
This statement is irrelevant.
The Government never
bought this software source code, so I was under no obligation to deliver it.
When the Government
approached me, I had been working on the ITB software and hardware since 1985.
Much of my time, effort and money had already gone into this development, and I
wanted to get paid for it. Initial negotiations with Dave Ebner established the
modest price for this pre-developed software source code at $750,000. Dave said
he had discussed it with Rod Wittinger and Lee Sheldon to make sure that all
were in agreement on the price. When the Government opted not to buy the
pre-developed source code outright, it was deciding instead to establish a “performance
period” to allow me the opportunity to demonstrate the functionality of the
ITB before the Government bought the software.
Dan Ramirez’s letter to
Rod Wittinger shortly after the Ice Harbor Index Test Box field test email
from your Dan Ramirez to Rod Wittinger on 21 February 2006 (that I acquired
from HDC under FOIA) and the Power Point presentation by HDC (Rod, Dan and Lee
Sheldon) to the Bonneville Power Administration (BPA) Hydro Optimization Team
(HOT) on 3 March 2006, (acquired from BPA under FOIA) would
indicate I was successful.
For my protection, at the
beginning of the contract interval a Copyright was acquired to document that
the source code indeed pre-existed the Contract signing.
The Government was never
invoiced for any work on, or any part of, the body of work that is the
pre-developed software source code, so the Government is not entitled to any
part of the ITB pre-developed Copyrighted source code, and did not get the
right to freely distribute copies of any execuitables or partial modules from
it; The government only bought one instance of the executable, in the single
Index Test Box that was delivered by ATECo, and the Co-Developed communication
programming for the ITB to GDACS interface.
Why
should my intellectual property rights be treated any different than
Microsoft’s?
Figure 76 HDC Response comment blaming me for program changes that were made necessary by Ed Miska’s project manipulation and directive that I sent the ITB to HDC in Portland without the perturbation routine completed.
These software changes were
made necessary because Ed Miska insisted that it be done this way.
As the Technical Lead, Ed was able to manipulate the project by delaying the
Task Order to ACSI for their part of the perturbation software so I had to send
the ITB to HDC before I could get the blade perturbation programming completed,
and Ed’s directives necessitated these repetitive revisions. And now I’m
being criticized for this? Incredible.
It was essential that ACSI program the blade perturbation into the
GDACS 3-D cam software program before I could write the corresponding blade
perturbation routines into the ITB, but Ed delayed getting the task order to
ACSI for their part of this work until after the ITB was at HDC.
There was an underlying,
duplicitous reason for this delay, as explained in the “Blade Perturbation” and
“Zero-Problem” sections of this letter, above:
Goto blade perturbation and zero problem
details.
Figure 77 Excerpt from HDC Response. Another complaint about documentation shortcomings.
This statement is true and
the problem it indicates was unavoidable. The documentation was for the most
part created at the last minute because of time shortages resulting from
COE’s misdirects, wild goose chases, moving the targets and additions to the
project workscope as detailed below.
The original ITB
configuration used individual transducers and sensors. This configuration was
already done and ready - and had been tested successfully, twice in 1985 and 1987.
All that was left for this configuration was to productionize my prototype into
a deliverable system, field-test (or demonstrate) it, and then prepare and test
the documentation.
Instead, when HDC contacted
me they wanted the ITB configuration changed to tap into the data stream
already in the governor and 3-D cam. This added considerable work to preparing
the item that HDC had specified. Initially, I agreed to go this route and
planned to use an RS-232 communication system to make the connection to the
GDACS SoftPLC. RS-232 is an “industry-standard,” is fast enough, I was already
familiar with it, and the interface hardware is free (or nearly so at $125 for
an interface board) and the Comm Genie software from SoftPLC Company to setup
the GDACS side of the communication was also free. SoftPLC Company recommended
this method.
Dan Perrier (ACSI) endorsed,
and Ed Miska directed that instead of the free RS-232 method, that I must use
the OPC communication method, which required the purchase of over $5,000 worth
of additional software and a whole new learning curve due to my (then)
unfamiliarity with OPC communication technology. When HDC made these changes,
it increased the expense and body of work dramatically, without increasing the
time or funding allotted for the project, this added things and required other
changes to the workscope that created a lot of extra work and new problems, and
delayed and short-changed the documentation package.
With as much as HDC had to
hide, i.e. the sub-standard 3-D cams and blade controllers that misalign Kaplan
blades all throughout FCRPS, it could arguably be said that GMT didn’t want
the ITB project to succeed because it would have exposed the sub-standard GDACS
3-D cams and blade controlling equipment, and would have shown who was at
fault in creating these problems by putting them there.
Click here to go to discussion on Documentation.
Figure 78 Excerpt from HDC Response, This statement is false. Documentation packages were submitted twice.
Click here to go to the discussion on Documentation.
Figure 79 This statement is False, illogical and in conflict with the terms of the Contract.
These modules were not
supplied to the Government because there was never any obligation to do so. In a
normal business context, the customer should not expect delivery of the product
without making the agreed-upon payment for it.
The Copyright on the software
was acquired at the “on-set of the Contract” to protect my intellectual
property and to prove that this software existed at the “on-set of the
Contract” should this question ever arise.
This intellectual property
was developed at private expense and was offered for sale to the Government as
a separate item (not listed in this contract) for the negotiated and
agreed-upon price of $750,000; amortization of this value across 320 copies of
the ITB executable program for use by the Government was the basis for the
price schedules that are in the contract.
The Government chose
not to buy this software source or the linkable modules, that’s why the
Government didn’t get any of them.
The Government is
misrepresenting the function and purpose of the software code modularity
here; the Government opted not to purchase either the pre-developed Copyrighted
source code or the executable code modules. The Contract terms provided only
for purchases of executable copies of compiled code, which were priced
according to the discount schedule of LI0003 on pages 2 & 4 of Contract W9127N-04-D-0009.
There is no basis in
fact for the Government’s presumption
that I should be giving the Copyrighted Modules or any other configuration of
my pre-developed Copyrighted source code to the Government - for free. A
remuneration schedule had been negotiated into the contract and I simply wanted
to get paid the negotiated, agreed-upon prices for my work.
Figure 80 Excerpt from HDC Response. A blatantly false misinterpretation of the contract terms.
The premise of this
complaint is blatantly false. The
Contract terms clearly spelled out the separation between my property and the
Government’s property. The Copyrighted source code was and is exclusively my
intellectual property. The fact that I may or may not have continued to refine
and improve my property at my own expense does not entitle the
Government to any part of it.
I DID NOT refuse to give the
Co-Developed source code to the Government.
I only refused to give the
Copyrighted “Pre-Developed source code” to the Government. The Co-Developed
code was delivered as specified in the Contract.
This statement incorrectly
mingles the two classes of software. The first class of software
is my Copyrighted source code, developed at private expense. The second
class of software was developed at Government expense, which is called
“Co-Developed” software.
The Co-Developed software was
to be shared between ATECo and the Government. Copies of all Co-Developed
software were given to the Government upon creation, in preparation for every
field test, at the completion of the work-scope and whenever requested.
Per the Contract’s terms -
the Copyrighted source code was not given to the Government because it
was never purchased.
When the Government approached
me, I had been working on the ITB software and hardware at my own expense since
1992, based on my prior experience with this product at Woodward Governor
Company from 1984 to 1989.
Much of my time, effort and
money have gone into this development project, and I simply wanted to get paid
for it.
Initial negotiations with
Dave Ebner established the price for this pre-developed software source code at
$750,000. Dave said he had discussed the price with Rod Wittinger and Lee
Sheldon to make sure all parties were in agreement. When the government opted
not to buy the source code outright, deciding instead to establish a
“performance period” to allow me the opportunity to demonstrate it, a Copyright
was acquired to document that the source code indeed pre-existed the contract
signing. The government was never invoiced for any work on, or any part of, the
Copyrighted source code - so the Government is not entitled to any part
of it.
Figure_81 Excerpt from HDC Response. A blatantly false statement claiming that I ignored Optimizer Special License Agreement.
This is a blatantly false
statement. To the contrary, I always rigorously
adhered to the letter of the terms of this Agreement. It was crafted to protect
both my rights and the Government’s rights. This Agreement was adhered to
judiciously - Dave Ebner saw to it.
It was HDC in the person
of Ed Miska who continually violated the Optimizer Special License Agreement by
trying to get my pre-developed, copyrighted source code without paying for it.
For the sake of clarity, because the HDC Response makes so many references to
the Optimizer Special License Agreement - allow me to ensconce a full copy of this
text herein for immediate reference. Dave Ebner and myself crafted this text to
protect the rights of both the Government and ATECo.
ATECo’s rights include sole ownership of the pre-existing, copyrighted
source code in all of its forms. The Government was not to own any part of this
Copyrighted source code until after it was paid for.
The Government’s rights
include shared ownership of any
software created at Government expense and exclusive rights in any specific
operational data from the turbines.
Here
would be a good place to state that the operational turbine data that I’m using
now in discussions of this topic outside the Government was acquired under FOIA
requests to HDC and BPA, outside of the terms of this Contract, and as such is
not limited by the terms of the Optimizer Special License Agreement.
As stated in the Optimizer
Special License Agreement, the purpose of the Contract and the Government’s
interest in the ITB project was to accelerate the development of the ITB
to make it available for the Government to purchase at the earliest time.
Transfer of ownership
of the Copyrighted source code, modular or otherwise is not included in this
Agreement.
Figure 82 Section J: Optimizer Special License Agreement
What is Co-Developed Code?
The Co-developed programming
was only the part that was necessary to make the OPC communication interface
work. Every portion of the program that had any direct linkage to the TopServer
OPC software (and thereby to GDACS) is included in the Co-Developed code and
was delivered to the Government. This screen-snapshot from the ITB monitor
shows the files that are included in the Co-Developed programming package. This
Co-Developed portion of the software was delivered to HDC each time it was
requested and when the workscope was concluded.
` Listing of Co-Developed code files
The Co-Developed code does not
include any of the original, pre-developed Copyrighted source code. A full set
of the Co-Developed code was sent to HDC when the first program was purchased
from ACSI (I bought an example RS Linx OPC Interface setup and GDACS tag-name
set from ACSI for $1,000, and gave a copy of it to Ed Miska) on 4/6/2005, in
preparation for every field test, at the end of the workscope and whenever it
was requested.
However - whenever Ed Miska
received the Co-Developed code, he always complained that the Copyrighted main
body of the pre-developed ITB program source code was not included.
I repeatedly explained to
him that it wasn’t supposed to be - the Copyrighted code was priced at
$750,000, and until HDC bought it, he couldn’t have it.
Figure 83 Excerpt from HDC Response. This is a totally subjective statement about how much Government interaction was needed. I disagree emphatically with this position.
HDC specified major configuration
changes to the ITB, and I needed considerable information and guidance as to
exactly what configuration changes the Government wanted, how the OPC
communication was supposed to be setup, how the Government utilized OPC
communication in GDACS, and what tag-names and other specific data and
information would be necessary to make it work. I can’t work in a vacuum.
After the Government’s intent
to purloin the ITB and cut me out became obvious, my communication with
the Contracting office increased dramatically because I needed to
establish and make known my rights, complaints and protections. It was an
effective communication. As Dave Ebner became increasingly aware of the
underhanded shenanigans by HDC personnel, he became noticeably upset at being
thrust into an unethical situation by being tasked to bully a contractor and
defraud a private citizen (with the tampered contract) out of personal, private
property. Dave is a fair and decent guy and a “crisis of conscience”
caused him much stress and ultimately to depart from the USACE Contracting
office.
Figure 84 Excerpt from HDC Response. A false statement about delivery dates and product quality.
This
statement is blatantly false and disingenuous. Misdirects and delays from GMT
(mostly Ed Miska) were numerous and vexing. The list below cites a few of them.
For more detailed information, see the web-reports, “What it was like to work for USACE” and “Reasons for Delays.”
Recall
that my original plan was to sell the ITB exactly the way I had developed it - as a stand-alone instrument that used individual
sensors that would be installed for forebay, tailwater, gate, blade & flow,
and by inserting a 1-ohm resistor in series with the Wattmeter current-loop
signal to get a power signal value. It was by HDC’s directive that the ITB was
reconfigured to get these pre-digitized values from the GDACS turbine control
system, and then again later HDC changed the ITB configuration to require these
signals be acquired over the OPC communication interface; these changes
consumed much of the project budget and allotted time; all per COE
directives.
HDC
demanded that I do it this way, and because it was a time and material
contract, I had to comply.
Dave Ebner
repeatedly assured me that if these changes and additions caused overruns of
money and time - if it looked like the project was making progress, more money
and time would be forthcoming. Dan Ramirez’s letter shows the success of the
project to Rod Wittinger and the subsequent HDC presentation to the BPA HOT
committee shows this success to everyone, so what’s the problem with me
getting more time and money?
This is the most disingenuous and false statement in the HDC Response
document.
A
brief list of COE instigated delays and misdirects:
- In the original ITB configuration offered to HDC
the ITB was self-contained and used discreet sensors for all measurements.
HDC’s first configuration change was to connect the ITB to the digitized data
stream in the SoftPLC computer based GDACS 3-D cam that was deployed
throughout FCRPS. Rod Wittinger knew that this new version of the USACE
3-D cam was already on Unit 5 at McNary before the contract was signed, so
that’s why he wanted the field-test to be done on McNary’s Unit 5.
- Ryan Sollars (a COE engineer) took some pictures
of unit 5 for us while he was at McNary working on another job. When Rod
saw these pictures, he recognized that that the new GDACS 3-D cam (fig 85,
right) had been removed, supplanted by the installation of an obsolete
Seawell 3-D cam (fig 85, left). Rod knew this was wrong because the new
GDACS 3-D cams had already replaced all of the obsolete Seawell cams at
McNary. The struggle to get the GDACS SoftPLC 3-D cam returned to Unit
5 so we could conduct the ITB Proof of Concept test as specified in the
contract was time consuming and not budgeted or planned for (see the “Stop
Work Order” and my letter
to Dave Ebner that prompted the Stop Work order).
Figure 85 Seawell 3-D Cam GDACS 3-D Cam
- A bench-test for ITB that was supposed to use the
GDACS MockUp (that was known to be in the HDC building by Rod Wittinger
and Lee Sheldon) was written into the Contract. When I tried to collect
the MockUp as a tool for this bench-test, it was missing; later it was
found in the back storeroom at ACSI, disassembled and scattered about the
room. Rod Wittinger and Lee Sheldon waived the Contract’s bench-test
demonstration, and directed that I should create another means of
bench-testing and demonstrating the ITB software, which also took
additional time and resources that were not budgeted in the Contract.
- After the Contract was signed I went to HDC in
Portland (from August 23-28, 2004) for a kick-off meeting and a walk-through
at McNary Dam. The week before, Lee Sheldon had verified with Clay Fouts,
Steve Atkinsen and Joe Fisk that they would be available to attend our ITB
project kick-off meeting on August 23, the following week. When the
meeting started, these three men were not in attendance. Checking with
their duty-sections, all three men were on vacation for the week and
would be unavailable and unreachable all week - after having left
instructions with all subordinates not to speak to any non-USACE persons
(i.e. me). And this after saying they’d be available for our meeting
the week before.
- Per Ed Miska’s instructions, I was directed to edit the C++ software source
code in the SoftPLC with the TopDoc editor program that HDC wanted to
purchase from SoftPLC on the HDC hydro-engineering department credit card.
I had to “bug” them for weeks before this software finally got ordered,
and then it was supposed to be “drop-shipped” directly to me - but instead
it was sent to Ed at HDC - who then sent it to me.
- After getting the TopDoc editor program and
struggling with the bad documentation in that SoftPLC product, I found
that there never was any editable C++ source code in the SoftPLC
computer in the first place.
- When I complained of this to Ralph Banse Fay as
an intentional “wild goose chase” and waste of time and money, and
that it was incumbent upon Ed Miska (who as the Technical Lead on the
project and such a “big-deal” in GMT) to have at least known where
the GDACS software source code resides - arguing that because this
software is the basis for GDACS, and Ed was purportedly the “expert” on
GDACS, shouldn’t Ed at least know where this code is (or is not)? When
I was complaining of this to Ralph Banse Fay after the contract-tampering
incident, he said it was excusable for Ed to not have known that
there was no editable source code in the SoftPLC. This was outrageous.
- The first plan made with Rod and Lee was for the
ITB to GDACS interface use RS-232 communication. When Lee Sheldon asked GDACS
Maintenance Team (Clay Fouts) about the availability of RS-232 ports on
the SoftPLCs, Clay gave us false information about the unavailability
of RS-232 ports and communication software by saying that there were no
available RS-232 ports and no way to add any more; and no way to
modify the program to make it work this way. Ryan Sollars’ pictures of
unit 5 at McNary showed empty PC-slots in the rear of the SoftPLC computer
that were covered up with blank panels. A phone call to SoftPLC Company
(accompanied by an email with this picture) learned that these panels were
indeed covering blank PC-board slots, and that for $125 a 4-channel RS-232
port PC-board could be purchased from SoftPLC and installed in the SoftPLC
using only a screwdriver. For setting up this communication, SoftPLC
recommended using their Comm Genie program, a free software tool
for the SoftPLC that would have done the job nicely. When Lee pointedly
asked Clay (whom Lee had known for 30+ years) why he had denied the
availability of empty slots and how easily more RS-232 ports could be
added, Clay replied, that’s what GMT wanted him to say.
Figure 86 Picture taken by Ryan Sollars showing Rear View
of SoftPLC and two available PC slots
- The switch to OPC communication was later
recommended and endorsed by Dan Perrier (ACSI) and directed by Ed Miska,
and furthermore Ed demanded that I use only Rockwell OPC products.
After purchasing the Rockwell OPC communication-programming tools (RS-Linx
Pro - $3,500, and two RS-Linx servers - $975 ea), I learned by hard-experience
that the Rockwell RS-Linx OPC software doesn’t work with Visual
Basic 6 and Microsoft Windows XP Pro. Rockwell does not support
Visual Basic and Windows XP Pro in any capacity, despite their advertising
saying specifically that they do. Later, Rockwell tech support told
me that the much lower price of VB compatible servers from their
competitors always keeps anyone from ever buying Rockwell’s RS-Linx for
Visual Basic, and that Rockwell just put it in their advertising as a “me
too” gesture - but I was being directed to buy this stuff by Ed
so price wasn’t a factor for me.
When
I finally found a service rep at Rockwell who didn’t “ditch me” or pass me
along to someone else, she was snotty and rude, and derided me for not
reading the Rockwell service bulletins that clearly state that Visual Basic
and the file structure I was trying to implement (which I had purchased from
ACSI for that $1,000) were forewarned against in the RS-Linx service bulletins.
The service bulletins warned that the new security protocols in Windows XP
prohibited the file structure method I was using (that ACSI had sold me for
$1,000). Arguably, as the “expert,” Dan (ACSI) should have read in these
service bulletins about the incompatibilities with Windows XP, Visual Basic and
Rockwell servers, and not set me up with the OPC communication method that he
did - and if he had read them and knew about it, then I was intentionally
set up for failure.
However,
I was able to get the Rockwell RSLinx OPC server to work in my Laptop computer,
which only has Windows XP Home operating system. The lesser security in
XP Home allowed the method that ACSI provided to work, but the greater security
in XP Pro prevented it.
When
I explained all of this to Ed Miska, he said I should just send my laptop
computer to HDC for them to field test. I refused, telling him that invoices I
had already submitted to HDC said, "new IBM PC," not "beat-up 2-year old Dell laptop,"
and I didn’t want to get tagged for defrauding the Government by not sending
the computer that was purchased with Government funding.
- Documenting Rockwell’s incompatibility with
Visual Basic and Windows XP sufficiently to override Dan’s (ACSI) recommendation
and Ed’s insistence on my using Rockwell RS-Linx for ITB’s OPC
communication interface was tedious and time consuming.
- Ed demanded that the graphical displays in the
ITB be removed, and then I was allowed to return them only after Rod was restored
as Technical Lead.
- Adding the automatic Winter Kennedy flushing
manifold (not in original contract), taking it out again and then putting
it back in wasted more time.
- Ed delayed getting the task-order for ACSI to
make the GDACS side of the OPC communication until after the ITB was
shipped to HDC. Coordinating the blade perturbation routine checkout at
HDC during the development of the perturbation functions here took more
time than it would have taken if Ed had just gotten the task-order to ACSI
in a timely manner. The reason Ed wanted to manipulate the project
this way was in order to control events in an attempt to get the
pre-developed, copyrighted source code without paying for it.
- The unauthorized tampering with my contract by Ed
Miska, that was allowed and fostered by Ralph Banse Fay, caused
delay while we struggled over whether or not the Government was going to
be able to steal my pre-developed Copyrighted software source code by this
ruse.
- While I was refusing to sign the modified
contract, HDC personnel took the ITB to McNary to field-test it without
anyone from my company (ATECo) in attendance. The lost time from this
wasted effort is exclusively the fault of HDC for trying to deceive me
with a secretly altered contract, insisting on continuing with this
ruse for 2 ½ months, and then taking my instrument to the field without
anyone from my company being there to help.
- On the second field test, The Winter Kennedy taps
on unit 5 were mislabeled and the powerplant blueprints were also
inaccurate. These problems caused the wasted field trip and was in no were
the fault of ATECo.
- The zero-problem chicanery took a lot of time for
Ed and Dan (ACSI) to setup, and longer for me to decipher what they were
doing to me – and to get it stopped.
- When I went to HDC in December 2005 for the
final, “all of the marbles” field-test - an anonymous complaint of
“favoritism by Lee Sheldon towards ATECo” to the Inspector General was
cited in denying Lee Sheldon the opportunity to participate in this field
test. At the end of the field test, the complaint was withdrawn, so the IG
ruled, “no harm, no foul” and would take no further action.
- When we got to McNary, we found that the $750
pressure transducer in the Winter Kennedy pressure manifold did not work.
While troubleshooting it, we found that the screw-on cap had been removed,
and a wire inside had been torn out, apparently with a pair of pliers; we
could clearly see impressions in the vinyl jacket of the wire such as a
pair of pliers would have made in seizing the wire and jerking it out. I
showed it to Rod Wittinger; he made no comment, but his initial statements
over lunch at our first meeting were very telling. Rod’s December 2005
field test report says the transducer was repaired. This is in error. The
one that was damaged could not be repaired; fortunately, I had a spare in
my toolbox.
- There are plenty more things I could list
here, but I believe I’ve made my point.
Figure 87 Excerpt from HDC Response. This comment is repetitive nonsense and fully addressed in the whole of this letter.
Figure 88 Excerpt from HDC Response; a deflective and overly simplistic statement.
Barring scheduling issues, two attempted
field-tests that failed due to HDC fault could have been at the no screens
condition; however, due to contract tampering & denying anyone
from ATECo to participate in the first test, and mislabeled Winter Kennedy
Taps on Unit 5 at McNary on the second test, our funding ran out.
More at fault in this was HDC’s attempts to acquire the ITB software source
code and underlying technology without paying for it or acknowledging where it
originated.
(Oct, 28, 2009 - Late correction – Since sending
this letter to HDC on October 19, 2005, additional data
analysis shows that the September 2005 test was “with screens”
instead of “without screens” as earlier thought. My initial comment to
figure 88 was inaccurate.
I was
unaware of the ESA lawsuit in 2005, and the data provided in September 2005 was
not a complete set; it was only the data from the 9th of
September, which consisted of only the “McNary Skew” data, and it looked like
“without screens” configuration at first.
When
considered with the Skew problem manifest by the sub-standard GDACS 3-D Cam and
the rest of the problems experienced with his project- I feel this is a very
minor point.
For a complete
explanation, click here: September
2005 Test Analysis.
Two field tests were failures
due to USACE-caused problems, one in August and the other in September of 2005.
Both of these tests failed due to faults of USACE personnel at HDC and McNary,
not due to any problems or shortcoming of ATECo or ITB. Scheduling problems and
wasted funding resulting from USACE personnel unethical conduct and inaccurate
Winter Kennedy plumbing documentation were more the issues that prevented any
without screens testing.
The first field in August
test failed because Ed Miska was allowed to secretly tamper with my contract
and I refused to sign it, and then Ed and Dan Perrier (ACSI) took the ITB to a
field test without anyone from my company in attendance. They didn’t
want anyone from ATECo to be there because of the planned treachery of the
“zero-problem” as described above. It was better for me that this field-test
failed.
For the second test, I sent
Greg Luna to Portland make sure the ITB worked properly and to fix any problems
that might come up. The field test was canceled when it was decided that there
was a leak in the Winter Kennedy taps. Later, we learned that the taps were
mislabeled, and that USACE personnel had prior knowledge of this problem, but
had neglected to correct this known pressure tap mislabeling and erroneous
blueprints, which were the root-cause of this failure.
Goto mislabeled Winter Kennedy Taps
discussion
However, the ITB did collect
data unattended, overnight, during the second ITB field-test. The data that was
captured exposed the sub-standard GDACS 3-D Cam’s most egregious problem; when
the GDACS 3-D cam’s blade controllers trip out the 3-D cam defaults to a
linear slope of the metal 2-D cam which introduces gross error into the
blade positioning.
Figure 89 Plot of all Blade v. Gate data collected from the August 12, 2005 overnight data run on McNary Unit 5.
When this data was shown to
HDC, they were derisive and told me the data was bogus - there must be
something wrong with my Index Test Box. Now, with Dan Perrier (ACSI)
explanation of the “parallelogram spiral,” the physical nature of the 3-D cam
slip-plate assembly and the FOIA information from HDC and BPA, and Power Point
presentations from HDC’s server, I know that I had the right answer all
along and HDC was in denial about it, trying to cover-up this egregious
problem.
If the ITB didn’t work,
then how was it able to capture data to document this problem with GDACS 3-D
cams?
Figure 90 Excerpt from HDC Response. This is another blatantly false statement that is addressed throughout this letter.
Figure 91 Excerpt from HDC Response. This is an illogical statement.
The ITB was initially offered
in my original configuration with discreet, separate transducers and sensors.
This configuration was not what HDC wanted, so the project was setup on a “time
and material” contract. HDC personnel directed many expensive and time
consuming changes to the configuration of the ITB that were not in the
Contract, so they naturally made the project take longer and cost more.
It simply took more
time and money to accomplish the changes and functions added by COE.
Figure 92 Excerpt from HDC Response. Another blatantly false claim.
Yes, the Co-Developed code
was delivered as required. The
Co-Developed code was delivered when it was originally created, at the onset of
each field test, at the completion of the workscope and whenever requested by
HDC.
IT WAS THE
PRE-DEVELOPED, COPYRIGHTED SOURCE CODE THAT WAS NEVER DELIVERED, AND IT WAS NOT
SUPPOSED TO BE BECAUSE THE $750,000 PAYMENT WAS NOT MADE, AS REQUIRED.
Figure 93 Excerpt from HDC Response. This is a completely subjective comment with which I absolutely disagree for all of the reasons cited herein.
Figure 94 Excerpt from HDC Response. This is a totally false statement.
Dan Ramirez’s email to Rod
Wittinger indicates otherwise, and is addressed elsewhere in this letter.
Figure_95 Excerpt from HDC Response. This is a totally inaccurate statement.
The Co-Developed code was
delivered as indicated above, and the code that embodied the monitoring
of head, tail and power of the four adjacent units to the unit under test was
included in the Co-developed code that was delivered to HDC as indicated. They
always had it.
This statement is
misleading. The Copyrighted source code always was and is for sale,
but GMT just chose not to buy it, and now are complaining because they didn’t
get it.
It is silly to think that I
would do anything malicious with my ITB or software programming. HDC had my
home address, business tax number and social security number on file. Had I
done anything purposefully malicious - I would be permanently barred from
selling to the Government. How foolish would I have to be to do anything
untoward?
The “unknown risk” that HDC
is whining about is demonstrated in fig 96, a screen capture from the
ITB display.
The left group is the Unit
Under Test display with all controls and indicators needed to communicate
with the OPC Server and SoftPLC and run the blade perturbation for the index
test.
The four smaller displays on
the right are what HDC is complained about; these modules are intended to
monitor the four adjacent units’ forebay, tailwater and operating level. This
is valuable information for index testing.
The source code for all of
these features shown in fig 96 was included in the Co-Developed source code
that was sent to HDC on multiple occasions - as it was created, in preparation
for each field test, at the completion of the workscope and whenever requested.
They always had the source code for this “unwarranted access,” and I disagree,
there is a good reason for it.
This complaint is
completely unfounded; the source code for this part was always in the
possession of the Government. What the Government didn’t have was the
Copyrighted portion of the program, which the Government had not paid for.
For a more complete
discussion, Goto Monitoring
Adjacent Units and Velocity Head
|ß-------------- Unit Under Test -----------------------à|ß------------ Adjacent Units ----------à|
Figure 96 ITB GDACS Interface showing Unit Under Test and 4 adjacent unit-monitoring panels.
Figure 97 Excerpt from HDC Response. This is a blatantly false statement.
There is abundant analysis
in the data collection routines and a PostProcessor was supplied with the ITB to
do the 3-D cam surface definition. This is an outright falsehood.
Figure 98 Excerpt from HDC Response. Another blatant falsehood.
ATECo accepts no
responsibility for any fault or problems during the first field test. It was a setup
and a scam by Ed Miska and Dan Perrier (ACSI) in attempt to purloin
my copyrighted source code and take over the project using the tampered, modified
Contract and the “zero-problem” bad program ruse. The perturbation did work on
this test, the reason for failure of the field test was that the Winter Kennedy
pressure transducer signal conditioner box had a broken wire, which caused Rod
Wittinger to cancel this test, and it was better for me that it did.
The ITB blade perturbation
routine did work for the second test, but the Winter Kennedy taps were
mislabeled and the powerplant blueprints were in error, so the Winter Kennedy
piping was deemed to have a leak and the test was canceled. This was no way
the fault of ATECo or ITB.
The ITB blade perturbation
routine did work for the third test at McNary, but the sub-standard GDACS 3-D
cam excessive deadband and deadtime precluded any Constant Power unattended
index testing.
The ITB blade perturbation
routine was functional in the ITB field test at Ice Harbor, but GMT did not
install the GDACS perturbation routines in the 3-D cams so there was no
perturbation by the ITB.
None of these issues
are the fault of ATECo or ITB.
Figure 99 Excerpt from HDC Response. This is an inaccurate and misleading statement.
This statement is absolutely
false. The ITB is designed to perform the Constant Power
automatic index testing procedure. Due to the sub-standard governor dynamics of
USACE’s McNary governor and GDACS 3-D cam, the ITB was prevented from running
the proven, effective, preferred Constant Power testing method that
it can definitely run unattended, as shown at Clarence Cannon in
1985 and again at PGE-PHP-2 in 1987.
Figure 100 Excerpt from HDC Response document.
This COE comment is
deflection of blame - the reason
the ITB could not run an Index Test as required was due to the sub-standard
GDACS 3-D cam’s excessive deadband and deadtime.
Figure 101 Excerpt from HDC response. This is another unreasonable and false statement.
I did the best I could
despite the obstacles put in my way by HDC.
Figure 102 HDC always had the source code for the adjacent unit monitoring software routines, and it is beneficial to monitor the operating levels of the adjacent units to know the true energy in the water as it enters the unit under test.
Figure 103 HDC Response. This is an inaccurate and misleading statement that incorrectly interprets the Section J. Optimizer Special License Agreement.
The Co-Developed code was
given to the Government every time it was required, when originally created, in
preparation for every field test, at project completion and whenever requested.
Figure 104 Excerpt from HDC Response. Finally – a completely true statement!
Refer to my Email to Dave Ebner that resulted in his Stop Work
order and every other comment in this
ATECo response.
My COR (Dave Ebner) saw
that there were problems being intentionally created by HDC personnel, so he put a Stop Work order on the
project so he could fix them. With the heightened clout Dave got from having a
project in Stop Work status, he was able to press people to find out what was
going on. Dave’s corrective action was to remove Clay Fouts as the HDC
liaison to ACSI because he found that Clay was doing things overtly and
covertly to protect the business prospects of ACSI to the detriment of my
project.
When it started looking like
the ITB was going to be successful, Ed Miska was afforded the opportunity to
secretly add text into my contract that would have harmed my company, and his
actions were fostered, endorsed and protected by Ralph Banse Fay by
forbidding Dave Ebner from removing the objectionable text that Ed had secreted
into the boilerplate of my Contract - for 2-½ months.
During the 2 ½ months that I
refused to sign the Contract because of Ed’s unlawful alterations and
tampering, Ed invited Dan Perrier, President of ACSI into HDC to help figure a
way to sabotage my equipment in a technical, complicated computer-technology
based ruse referred to herein as the “zero-problem” which is discussed in full
technical detail in the discussion of the First Field test
(above).
Lunch_Date
But here’s the “rest of the story…”
While I was in Portland
for the kick-off meeting with Dave Ebner, Rod Wittinger, Lee Sheldon, Calvin
Hshie and myself, I made a presentation to the meeting that showed the sequence
of events that would get the ITB interface developed, installed and the ITB
Proof of Concept test completed.
Dave Ebner commented that,
“You sure make it look easy” after my whiteboard presentation.
After the meeting,
everyone left the room except for Rod and me. I asked him, “you look skeptical;
don’t you think I can do this?” Rod quipped, “I have no doubt you can do what
you say, but I don’t know if ‘they’ will let you do it.” I asked whom, “they”
are. Rod wouldn’t answer me, except to say, let’s go get some lunch.
Over lunch, Rod said that
I was walking into a treacherous and difficult situation. ACSI was a problem;
they had completed their workscope with the GDACS SCADA system and 3-D cams,
and needed some new work to do. He told me I should stay away from ACSI because
they’ll be trying to figure a way to take my ITB project away from me - the
$3,500,000 in my Contract’s budget made it very attractive. He suggested a
scenario where I’d get a “bum’s rush” and continual hustle, always kept off
balance by diversions, distractions and getting my workscope’s targets moved by
an as-of-yet unnamed HDC contact until - when we got to the field test, there’d
be contrived problem of some sort with my equipment that I could not fix, and
as a result I would be made to look incompetent - and then Dan Perrier and ACSI
would swoop in, “save the day” by some subterfuge and walk away with my
contract, and the money.
Looking back, Rod was
exactly right with his prediction; the way Ed kept me off balance by
misdirects, wild-goose chases, moving the target, and more specifically, once
we got into it - delaying the task order to get the GDACS blade perturbation
software routines from ACSI in order to get the incomplete ITB into HDC - with
designing and testing of the blade perturbation routines yet to do, specifying
repeated changes to this software that made many new revisions of the
executable necessary - until Ed and Dan (ACSI) got a version of the program
they could use to create a contrived problem - which they found with the “zero-problem”
version; (ITBRev1.br16.exe)
When they went to
McNary on the first field test [Rod, Lee, Ed and Dan (ACSI)], no representative
from my company was allowed to go along because I was refusing to sign the contract that Ed
had been allowed to change to my detriment, in secret. Rod &
Lee were not “computer savvy” enough to see the sleight-of-hand as Ed and Dan
(ACSI) shut off the proper ITB program and then started the “bad program” with
the zero problem to show that they couldn’t do any testing as long as the ITB
kept sending random zeros to the SoftPLC - and then Dan (ACSI) would whip-out
his “zero snatcher” routine, and install it in the SoftPLC. After this software
“patch” of Dan’s (ACSI) had fixed the zero-problem, the testing could go forward
with Dan (ACSI) as the hero - and then my company, my product and me would be
discredited, and Dan (ACSI) could walk away with my contract and the
money.
A brilliant plan; except
for the “wily” ATE-150. A broken wire in this signal conditioner box prevented
any Winter Kennedy flow measurement, so the first field-test’s index testing
was a failure. When we spoke of it later, I explained to Rod that the ATE-150
was a prototype, and prototypes are “humble and don’t travel well.” Rod
laughed out loud at that explanation - and the next time we spoke; Ed was gone,
Rod was back in charge again, Lee was my HDC contact again, $20,000 was added
to the contract and the objectionable text was removed from paragraph 3.4.2.9,
and paragraph 3.4.2.9a was removed entirely; a happy ending.
III. Comments on HDC Response References
Figure_105 Excerpt from HDC Response. This is a vague and inaccurate representation of the meaning and intent of the Section J provisions.
The real problem here all boils down to the Government
wanting to get “something for nothing.”
Government violation of Section J Provisions
Yes indeed, I was made aware
of the Government requirements for source code and security.
At the same time, the
Government was made aware of my requirement to get paid for my work.
The pre-developed Copyrighted
software source code had been written prior to the Government approaching me
with a solicitation for a sole-source Contract for an Index Test Box. The
Government made many overt and covert attempts to get the pre-developed
Copyrighted source code away from me without paying for it, in flagrant
violation of Section J of the Contract.
An agreement for transfer of
ownership of the pre-developed Copyrighted source code to the Government was
arrived at during contract negotiations (Dave Ebner coordinated negotiations
with Rod Wittinger, Lee Sheldon and others in HDC) which priced the Copyrighted
source code at $750,000, with a restriction that the Government could only use
this software within the Columbia River Basin Federal Columbia River Power
System (FCRPS).
Once I got this
agreement in writing, I wasn’t going to be niggled out of it.
HDC personnel violated
this agreement many times by attempts to acquire the pre-developed Copyrighted
source code without paying for it; a prime example of this behavior is the
deceptive and foolish tampering with the contract modification at the end of
the performance period when Ed Miska was allowed to secretly sneak extra
wording into the boiler plate of the Contract that would have altered our
agreement – as if I would be stupid enough to sign a Government contract
without first reading every word!
Purpose of Pre-Developed Code Modules
The nature of Visual Basic
software programming (or any computer programming) is to separate the
program’s functional logic into modules (Visual Basic uses forms, or windows),
each comprised of both Graphic User Interface (GIU) features and text-based
code.
Although methods exist to
compile these functional blocks into Dynamic Linking Library (DLL) format to
distribute them separately, this form of program distribution is not without
it’s own pitfalls. This is the programming distribution method being discussed
in Fig 105.
The modularity discussed in
Fig 105 delineates the partitioning that I used in writing the program for the
Index Test Box, i.e.:
“SteadyState” procedure
“Parse and Graph procedure
“Autocal” procedure, and
“Registration and Security”
procedure
This was the logical
structure of the Copyrighted source code when I entered negotiations with the
government. The software was not going to be sold in this format - these were
just the logical partitions used for software program development to enhance
understandability of how the program works.
It was never my
intent to market these modules separately. The purpose of listing these modules in this way was
to explain the structure of the logic of the program to help the Government
understand how the ITB program works. My intent was always to compile and sell
the program only as a single executable “.exe” format program, hence the
pricing structure in the Contract’s Line Item 3, “LI0003” pricing and discount
structure.
In deference to the comment
in fig 105, these modules were never paid for, so they were not
delivered, but this was never an intended form for the Index Test Box
technology. Had I really wanted to sell these modules separately, there would
have at least been separate pricing for them delineated in the Contract.
There was not a price
for any DLL programming, and the Government never bought any. The contract only described this method as a logical
possibility, not as a deliverable. Without a price it really never existed.
The pre-developed code is
easily compiled into one, comprehensive executable program. All of the software
deployments I’ve made to date (20+ years) have used this technique. I am very
comfortable selling the ITB software in this form and this was how I contracted
to sell it to the Government.
Under pressure from the
Government (despite my better judgment) I agreed to consider
marketing these modules individually, but not in such a way as would violate
the provisions of LI0003, i.e. without getting paid for each and every
one of them. My purpose in developing the ITB was, after all, to
make money. Whatever form or fashion these modules would be sold in,
the cost to the government would be in accordance with the price schedule of
LI0003, which was based on the $750,000 price established in Contract
negotiations.
In any event, every module of
code that was delivered to the government would have been protect by the “non
reverse compliable” nature of Visual Basic and the hard-coding into each
module of the serial numbers of the computer, hard drive and I/O board of
the Index Test Box platform it would be going into. Each and every software
module would be keyed to a single computer box, all in accordance with
the Contract’s provision in Line Item 0003, the price schedule that was
ultimately based on a total value of $750,000 for the Copyrighted source code.
Unauthorized
redistribution such as the Government wanted to do is Software Piracy, and
is illegal, even if it is the Government doing it.
A prime example of the
continual niggling behavior of HDC is the “big deal” being made now over these
individual modules. Note that the pricing structure calls for only the
entire executable programs to be sold; no mention is made of individual
code modules in any pricing schedule.
After some research into the
Dynamic Linking Library (DLL) option, it was quickly learned that there would
be significant “learning curve” and code testing required with creating and
validating these individual modules in DLL format before they would be
individually usable and sufficiently reliable and robust. Unfortunately, the
Government didn’t want to pay for this development effort, there wasn’t time to
unbundled these modules from the Copyrighted source code and comprehensive
“.exe” file, so this work did not get done; mainly because the Government
didn’t want to pay for it.
Contrary to the
Government’s claim, even if I had
made the DLL’s as described, the Government would not have been able to
redistribute them freely. The Registration and Security module would
have been included with each of the other three modules to prohibit widespread
distribution in violation of the Contract provisions of LI0003, which is what
the Government was seeking and is complaining about now. The Government
was never to get the benefit of the pre-developed Copyrighted source code until
it was purchased at the full price of $750,000.
I had been working on this
software since 1984; for Woodward until 1989, then on my own from 1992 to the
present after Woodward shelved it and the Patent expired. I quit my job at
Woodward to continue working on the ITB in 1992, on and off, as time allowed –
and then almost continually after 2002.
I have hundreds of hour in
this programming effort and was not prepared to give it all away without
getting paid for the work that had gone into it. When the Government contacted
me in 2003, the program was admittedly still under development - but had the
functional SteadyState, data manipulation and display graphing routines
working, and the rest of it was fully functional but not completed into a
marketable form - hence the low, low price of only $750,000, instead of a much
larger dollar figure. We both know what this automatic, unattended index
testing capability is worth.
Refer to the “Screen Gallery” included with the introductory sales package that was sent to HDC in 2004 to document the state of
development attained prior to the initiation of contract negotiation and
signing.
Buying-in at such a late-date
in the development cycle of my instrument did not entitle the Government to
complete rights to the entire work. Price for the rights to a usable version of
the pre-developed Copyrighted source code (as it was in 2004) with geographic
restrictions to within FCRPS, was set at $750,000 in negotiations with Dave
Ebner for the original Contract. To further illustrate this number the price of
$2,300 each for 320 copies of the executable was based on
$2,300 * 320 =$736,000; the
difference from there up to $750,000 was written off to incidentals; travel and
enough computer hardware to make just one ITB.
Looking back, the Government
actually had a real bargain on their hands, but HDC’s perpetual attempts
to cover-up the problems with the GDACS 3-D cams and take the Copyrighted
source code away from me without paying for it - instead of working with me -
lost the Government a great opportunity. The discounted price for 320 units
would have actually been $500,480; but they would probably only have purchased
one or two per powerhouse at a much lower total cost - either way the
Government would have gotten my full support in perpetuity to get this
equipment up and keep it running, and I would have kept mum about the GDACS
3-D cam problems and helped get them fixed.
I quit Woodward governor in
1992 to start the Actuation Test Equipment Company in order work on this
project, with the fall-back plan of designing and building aircraft test
equipment as a “bread and butter” line and work on the Index Test Box on the
Back burner. Outright threats of litigation for patent infringement were
made by Woodward until their Hydro group disbanded, and after that GE Global
Systems continued to threaten lawsuits if I brought the ITB to market. After the
patent expired (but before I got my marketing efforts off the ground) HDC
contacted me in 2003 with overtures of a sole-source Contract. The negotiations
took over a year and a half because the Government continually put “grabbers”
in the Contract and boilerplate that would transfer ownership of the body of
the pre-developed source code to the Government as part of the deal.
My struggle was to keep the
main body of the source code that I had been developing since I left Woodward
intact as personal intellectual property.
Contract Negotiations Interrupted
It should also be noted that
a 7-month hiatus occurred in the contract negotiation due to a false claim made
by another company. At a point where I was close to terms with my first COR,
George Williams, the American Governor Company (“AGCo,” the outfit who
is currently contracted to provide your new governors on a $10.6 Million
contract) made a false claim to HDC (AGCo’s Roger Clark Johnson to HDC’s
Courtney) that AGCo’s engineers invented (and, “even came up
with the name” for) the Index Test Box in 1985 at Woodward - instead of
George Mittendorf and me. Contract negotiations were immediately halted, and
were not resumed again until 7 months later - after Rod Wittinger got
reinvolved. Rod looked at AGCo’s website, and saw that they made no mention of
index testing thereupon. Rod reasoned that if AGCo had been involved in the
Index Test Box project in 1985, they would have at least mentioned it on their
website.
Software Security
At the beginning of our
negotiations, the ITB wasn’t completely ready, but too far along to be
scooped-up by the Government as part of this Contract to purchase only one
instrument.
The intellectual property in
the software is protected in two ways.
First, one of the key
benefits of Visual Basic 6 (VB6) programming language is that it is impossible
to reverse compile executable modules created in VB6.
(Computer executable
modules programmed in C, C++, Java and most other high-level programming
languages can be reverse-compiled to get access to workable source code,
leaving the purveyor more vulnerable to software piracy.)
Second, each executable code
module is hard-coded with the serial numbers of the CPU, hard drive and I/O board
that are in the Index Test Box PC that the software goes into. The software
won’t run in any computer other than the one that they are keyed into.
The Government was never
supposed to receive any usable, copyable, redistributable software; modules,
copyrighted or otherwise without paying for each of them separately, as
delineated in the price list of LI0003, Software Discount Schedule
on page 4 of the original contract, or until the body of the program was
purchased - if this were not the case, why was Line Item LI0003 in the
contract? Ed Miska repeatedly tried to transfer the ITB executable, which he
had copied out of the Index Test Box computer that was delivered to HDC, to run
in another, different computer. I am glad that he was unable to defeat the
ITB software security.
The purchase price of
$160,000 in the contract only provided for one instance of the IBT software
program, which is contained as a complete executable “.exe” software module in
the Index Test Box that was delivered in a functional condition to HDC.
The Government got
everything that was paid for.
Restating: additional
workable units of the program were never supposed to be replicable and freely
distributable by the Government, until after the $750,000 Copyrighted source
code was purchased.
Additional copies of the
program could be purchased individually, as identified in the contract by Line
Item LI0003, with pricing discount schedules as indicated. If the Government
were able to copy and distribute the program freely - it would defeat the terms
of the contract, so this point is moot.
The LI003 pricing would
remain in effect if and/or until the source code was purchased for the
agreed-upon price of $750,000.
When we got to the end of the
1-year performance period of the contract, an optional method of distributing
segments of the program as “.dll” modules that the Government could link into
other programs was discussed and written into the modified contract, but
funding to do this work was not forthcoming and the Government never bought any
of these “.dll” modules. The specific work to parse out the identified
functional modules and test them extensively enough to release them as
individual modules was not possible due to time and funding running out.
Here’s the rub - the
Government was afforded the opportunity to “buy me out” after they saw that the
program worked as advertised. Ed Miska’s stated position in a pre-emptive
meeting in August 2004 was that after the Government saw how the ITB worked, HDC
could simply have ACSI reproduce its functionality, so there was no need to
purchase the software outright. It was always the intent of GMT to get my
product without paying for it.
As TV’s Dr. Phil would ask
– “How’s that workin’ out for ya?”
Figure 106 HDC Response Document. A misleading and disingenuous claim that the Government didn’t get what they paid for.
This paragraph is misleading.
The individual modules were never going to be separately protected by Copyright
nor marketed individually - or more importantly, received by the Government
- until after they were paid for. The Government didn’t pay for
them, so the Government didn’t get them. The primary purpose of the software
Copyright was to document that the work to create the main body of the
source code pre-dated signing of the Government contract, thus the main
body of the software was created at personal expense and could not be claimed
by the Government as the product of this Contract’s funding.
It was feared that claims would be made at the end of the
Contract interval that the entire software program was written at
government expense during the contract interval and the Government would
seize it, so the Copyright was acquired to prove otherwise. As it turned
out, such a claim was made by the Government, at which time the
Copyright was delivered to the COR to prove the source code predated the
contract interval and therefore was created at private expense.
The reason the “bench-test” demonstration was not
possible was because GMT had removed the MockUp that we were supposed to
use for the demonstration from HDC in order to make this tool unavailable,
thereby preventing this demonstration. The Mock-up was stashed away in the back
storeroom at ACSI, and then dismantled it to render it unusable for this
demonstration.
And now they’re
complaining about my not doing this demonstration? Incredible.
Rod Wittinger and Lee Sheldon
waived this “bench-test” requirement because the MockUp, which was the intended
“bench to test on” for this demonstration, was missing when we
needed it. When I was in Portland in August 2004, on a trip to ACSI to discuss
details of Lee Sheldon’s Type 2 (T2) optimizer functionality and coordinate the
data collection and perturbation interface with Dan Perrier, the MockUp was
found in the back storeroom at ACSI, dismantled and scattered about the room,
rendered unusable for this demonstration.
As a result of the MockUp
being made unavailable, a new requirement was placed on ATECo to devise a
different means to demonstrate the ITB software functionality. To facilitate
this, we wanted to borrow a SoftPLC computer from HDC, but were told that none
were available; later it was learned that this was a falsehood. When
Greg Luna delivered the ITB to HDC for me, he found that there were 14
SoftPLC computers in a GDACS simulation room configured as an entire GDACS
network system; he was told that one could have been had for the asking.
Another purpose of our trip
to ACSI was to borrow a SoftPLC from them. When we got there, it could be seen
that ACSI was for the most part, destitute and closing down. Many empty
workbenches and desks, and no spare equipment lying around. It was said
that HDC had retrieved all of the computer equipment from ACSI and they were
being pressed for documentation on the GDACS and would be shutting down
shortly.
I spoke on the phone to a
retired USAF employee at ACSI before going to Portland in August. My USAF
background (and that we had previously been to the same duty stations) provided
common ground for our friendly conversation. He suggested I speak to Roger Hays
at McNary, who provided a frank and open description of what it was like to
work for USACE, and what kind of abuses and chicanery I could expect, and some
insights for how accomplish my stated goals.
While I was at McNary, Leroy
Richardson was telling me that there were no SoftPLC’s to borrow, but
Bob chided him that this was a disingenuous statement, went into a storage area
and came back with a SoftPLC computer. He said that it was slated for an
expansion of the fish ladder system and would not be needed for months, (if
ever). Bob could not provide the software for it; however - we’d have to get
that somewhere else.
Rod Wittinger and Lee Sheldon
carefully coordinated the timing and scheduling of my first trip to Portland.
We needed to have a “kick-off” meeting with key players from several areas (A
liaison from HDC to ACSI to coordinate things, someone from powerplant operations
and 3-D cam engineering) to assure success with our project. Weeks before, and
the very week before my trip to Portland, Lee contacted Clay Fouts (whom
Lee trusted because they’d worked together for over 30 years), Joe Fisk and
Steve Atkinsen, who all assured Lee that they would be available to attend our
kick-off meeting on Monday when I arrived in Portland. When we started our
meeting, all three of these men were absent. Lee checked with their duty
sections and found that all three of these men were on vacation for the entire
week and could not be reached. When Lee asked about alternates, he found that
all subordinates had been instructed not to communicate with any non-USACE
people (meaning me), ostensibly in hopes that this would thwart the purpose of
our meeting.
Our meeting was canceled,
Dave, Rod and Lee had a private conference, and I was left to my own devices
for a while. In search of some information, I went to Steve Atkinsen’s desk,
sat in his chair, and waited for someone to come along and question my presence
there. Calvin Hshie came by and asked me what I was doing there. Calvin
apparently didn’t get the word that I was to be avoided. After a brief
conversation, I quickly learned that Calvin had the knowledge and expertise we
needed; he was personally working in the powerplants with the GDACS 3-D cams by
loading the 3-D cam executable programs and cam data tables into the SoftPLCs
associated with each turbine, and had copies of the GDACS 3-D cam program and
cam tables for McNary that we needed – and was willing to share.
I found Lee, told him about
Calvin, and our meeting was reconvened.
Figure 107 Excerpt from HDC Response, pointing out changes in the software over the course of the project.
This is essentially a true
statement. Yes, some changes to the software were made necessary due to COE
directed configuration changes to the ITB. These changes were made at the
direction of Rod Wittinger, Lee Sheldon and Ed Miska; the changes were all
in the “Co-Developed” code. These added code modules were necessitated by
the changes from discreet sensors and an analog I/O board for all measured
signals to using digital communication to the 3-D cam’s data stream and the change
from RS-232 to the OPC communication method. The 4 original software modules
(or partitioning) had been used to construct and define the functional logic of
the software that was copyrighted at the beginning of the project. Additional
software created for the OPC interface to the SoftPLC computer, the blade
perturbation and the four modules for displaying the adjacent machines (two on
each side of the unit under test) were added as part of the Contracted
project’s workscope. Copies of this Co-Developed code were given to HDC upon
creation (or when purchased from ACSI), during preparation for each field test,
at the conclusion of the workscope and every time it was requested.
Your Ed Miska, at the
recommendation of Dan Perrier of ACSI, mandated the greatest change on this
“time and material contract.” This change was that the communication method for
the ITB was changed from my original plan: communication with the GDACS control
systems using the FREE, readily available RS-232 communication ports that were
already on all of the GDACS SoftPLC computers, using the FREE Comm Genie
communication software that was available from SoftPLC, to the more expensive
and unfamiliar (to me) OPC method. The RS-232 method was suggested by
SoftPLC’s technical support so it most certainly would have worked.
Dan Perrier suggested, and Ed
Miska directed that I not use the RS-232 ports for this communication; instead
they wanted me to use OPC communication programming method with which I was
unfamiliar at that time. This COE directed change was not in the contract
requirements so they were just pushed in after the contract was signed. There
was no added budget for this time and expense, so something else that was
planned in had to get removed; as usual, the documentation was the first
thing to suffer.
(Cost for OPC programming
software from Rockwell that was specified by Dan and Ed was $3,500 for the
programming tool, then $950 each for every communication interface; two were
required. I had to purchase the OPC Communication setup and “tagname”
information from ACSI for another $1,000. These were not budgeted in the
contract, but I was forced to buy them anyway. Figuring out that the Rockwell
OPC interface wouldn’t work in Visual Basic 6 and Windows XP, and then
arguing with Ed about switching away from Rockwell took several weeks. And then
switching to Software Toolbox cost another $1,800 and had an associated
learning curve and programming time to use this tool. All of this OPC communication
work took about 4 months to struggle through, none of which was in the project
budget or plan. )
In order to add this COE
specified OPC communication capability to the Index Test Box programming (while
preserving the integrity of the copyrighted Index Test Box core programming) required
creating a few new modules. The code for these newly added modules was
written at Government expense, and all of the source code for it was given to
HDC when it was completed. Due to these COE mandated changes, the module
listings do not agree.
The situation was that I
planned and negotiated a workscope and a time and material Contract, with terms
that were Dave Ebner’s and my best estimates of how the project would go. When
Ed Miska came on board as the Technical Lead, he radically changed the
direction of the project several times, so naturally the work that got done did
not agree with Dave’s and my original estimates and plans, and it took more
time and money to chase the constantly moving targets.
Figure 108 Excerpt from HDC Response; more falsehoods and misdirection.
This paragraph leads with a
false statement. I was not ignoring the Section J bilateral agreement -
I was constantly disagreeing
with Ed Miska’s interpretation and misapplication of Section J.
Dave Ebner arbitrated every disagreement, usually with a slight bias toward the
Government (in my opinion), but by and large - Dave was always fair.
A broad - brush overview of the
bilateral agreement was that what I brought to the table was mine until the
Government bought it, and what I developed at government expense would
be shared with the government. Isolating the pre-existing code from the
newly created, Co-Developed OPC communication programming necessitated by HDC’s
ITB configuration changes required a few new modules. ATECo meticulously
adhered to the bilateral agreement, because it was also intended to protect
my intellectual property from the Government.
Counsel advised that had I stayed with the exact module structure
that existed at the beginning of the project; the modifications that would be
done at Government expense to change the ITB configuration (changing to digital
communication from discreet sensors and the switch to OPC communication) would
have been made to the original source code. A clause in the contract
boilerplate stated that if the Government paid for any changes to
any part of the original Copyrighted source code, the entire
Copyrighted source code would become Government property. To prevent this
eventuality, additional modules were created to contain the new code and
program logic for the COE directed changes and additions to the ITB
functionality and configuration.
Figure_109 An excerpt from HDC Response. Reference to the four monitors for adjacent units.
Perhaps I got a little too
snippy here, but Ed was really frustrating to work with, I do not apologize for
this outburst - but allow me to explain myself more fully below.
Please recall that the
Government engaged me as the Index Test Box expert. My task was to educate the Government how the Index
Test Box worked, how the Constant Power testing method works, and what operational
concerns of the powerplant would impact the testing results from the Index Test
Box. When I realized that some in the Corps saw the ITB and me as a threat to
the status quo, I played down my abilities and knowledge to disarm them. It
worked - perhaps too well. Ed (and others, I’m sure) underestimated me to
the point where it was thought I wouldn’t read every single word of a
Government contract before signing it! And, nobody guessed that I’d have
any form of protection on my intellectual property after they learned that the
patent had expired.
It’s good to be
underestimated.
Explanation of why Monitoring Adjacent Units
and Velocity Head is a Good Idea
It is well known that
changing the operating levels of the adjacent units during data collection will
disrupt the index test results with noise, but it is lesser understood that the
velocity of the water as it approaches the dam also affects the index testing
results; even if the adjacent units’ operating levels are held steady
during the index test’s measurement intervals. Changes made to operating levels
of adjacent machines will affect the kinetic energy in the water approaching
the unit and be undetectable by normal powerhouse instrumentation.
The energy involved in this
“velocity effect” has a magnitude proportional to the square of flow velocity.
The conventional thinking of the PTC-18 energy calculations assume that all of
the kinetic energy of the water is the result of the grosshead, so the velocity
at the intake causes a measurable depression in the water at the inlet. This
method ignores the velocity of the water as it approaches the dam.
Think of it as the
difference between sipping from a bowl and drinking from a fire hose.
A “rule of thumb” benchmark
for this - when the velocity of the water in the forebay is approaching at 8.4
feet per second, the inertia in the water is equivalent to 1.0-foot of
grosshead. In a unit operating at 75 foot head, this has a roughly 1.3% effect
on total energy in the water entering the unit. This kinetic energy is
unmeasured because it is undetectable by the typical forebay & tailwater
head measurement system in most powerplants that are comprised of floats or
static pressure transducers. Water level sensing measurement methods cannot see
the momentum (energy) that is already in the water as it approaches the dam. This
is why an index test should be recording the operating levels (or flow) of the
adjacent units (four turbines in this case), so that the aggregate flow
approaching the dam directly in front of the unit under test can be known. The
Index Test Box is the first index-testing tool to make notice of this
phenomenon. If I could have measured all 14 turbines at McNary it would have
been even better.
This is one of the
concepts that I wanted the “grasshopper” to learn about. The main problem I had
with Ed is he was always trying to “snatch the pebble from my hand” before I
opened my palm. Overall, Government personnel seem to believe that because they
work for the Government that they are smarter than those of us in the private
sector; “it ain’t necessarily so.” It was hoped that when Corps
personnel more knowledgeable of index testing and at least vaguely familiar
with basic concepts from first-semester physics realized what
this feature was for - it would be accepted.
I am currently working with
the governor manufacturer for the Canadian power company’s equipment to enhance
their governor 3-D cam algorithm to measure and accommodate this velocity head.
This new algorithm works on the sum of the energies in the water (gross head -
trashrack + velocity head) and gate angle. Perhaps I’ve tipped my hand too much
here by giving away a trade secret of our new development project, but it is
important that the reason for wanting to record the four adjacent units to the
unit under test be explained herein so you can appreciate my purpose.
The problems I had with Ed
was that for some unknown reason, he was always HDC’s “point man.” Ed had no
familiarity, knowledge or expertise at index testing turbines, and I found him
to be unethical and deceptive in our dealings. His presence was always a
hindrance and detriment to progress, yet Dick Nelson kept putting Ed in charge.
I must agree that there were
some ragged edges to the Index Test Box when we started; it was (and is still)
a work in progress when I engaged to sell one to the Government with this
contract. However, this should have been a surprise to no one; the
Government always knew this.
Note this phrase in the
Contract’s Section J:
Figure 110 Excerpt from Contract Section J, Optimizer Special License Agreement.
I would have been ready to go
to market with the ITB in 2-5 years at the pace I was going. Significant energy
must always be spent “keeping a roof over my head,” and the ITB was still a
“back-burner project” that only got worked on as time allowed. The Government’s
purposes with this contract were to “accelerate development, gain
configuration control,” and get an item to test as quickly as possible.
My purpose was to retain what I had achieved already and move it forward.
Selling an ITB to the
Government allowed me to focus more of my energies on the ITB project, and the Government
was allowed to dictate some changes to the data collection method by switching
from the discreet sensors method I was using to the “integrated data
collection” method that Rod Wittinger and Lee Sheldon specified, and get
exactly what they wanted.
Rod and Lee would have been
happy with using the RS-232 method to achieve this, but when Ed Miska took
over, he insisted on switching to the OPC communication method; that’s when
the real trouble started.
In retrospect, one of the
goals of this project was purported to facilitate my completion of the ITB so
the Government could buy them from me, but soon into the workscope after Ed
took over - it became painfully obvious that the true objective of the
Government was to take the intellectual property of the Copyrighted source code
and underlying technology away from me so it could be given to ACSI, so that
company could mass produce and sell ITB’s to the Government; all without
paying me the acknowledged, agreed-upon price for the Copyrighted source code
or acknowledging where it came from.
Figure 111 Excerpt from HDC Response; a misleading and inaccurate interpretation of Section J and security issues.
This paragraph is misleading
and inaccurate. There was no “co-mingling”
of any software. The software was meticulously segregated to preserve the
integrity of the pre-developed Copyrighted source code. Additional modules of
code were added by necessity because the pre-developed, copyrighted source code
did not have the OPC communication capability that COE wanted.
I was advised by counsel that if I made modifications to the copyrighted,
pre-developed source code at Government expense, that the Government could then
seize the entirety of it. To avoid this eventuality, it became necessary to
create additional code modules as containers for this new code that HDC
was mandating in order to segregate the Government-funded code development from
the Copyrighted, pre-developed code.
I never saw any cure letter,
so I cannot comment on it. Dave Ebner told me of it, but after I presented the
Copyright to Dave Ebner, the cure letter was never mentioned again.
The FOIA request for GDACS
3-D cam code was for two reasons.
1.) I wanted to figure out
why the Governments 3-D cam at McNary required a 1.0-degree deadband and
35-second deadtime. These two factors rendered the Government’s 3-D
cam sub-standard when evaluated by the ASME & IEEE PTC 29, Std-125 and
Std-1207 standards, and made them unsuitable for index testing with
the ITB’s preferred Constant Power method.
I believe that as an
absolute rule - it is incumbent upon the Corps of Engineers to meet or exceed the
accepted industry standards for turbine control system equipment per the
Endangered Species Act, particularly so because Corps of Engineers
personnel have participated in these Standards Committees for many years.
If HDC insists on designing
and building their own control systems, then the resulting systems must at
least be in compliance with nominal industry-accepted standards that COE
personnel helped to create.
2.) There was an inexplicable
problem with the OPC communication system, designated the “zero-problem” that
is described at length in, “What it was like to work for USACE” and above at Blade Perturbation and zero problem. The
GDACS 3-D cam code and zero-snatcher code I was requesting under FOIA would
have helped to expose how this ruse worked and document the deceptive actions
by Ed Miska and Dan Perrier (ACSI).
I
believe that the denial of this technical information for the GDACS 3-D cam (I
learned earlier this year that GDACS was offered for sale by ACSI to Brookfield
Power in 1998, which belies the national security argument) places the
unethical conduct by HDC on an organization scale.
Figure 112 Excerpt from HDC Response; an incorrect and uneducated complaint.
This is redundant and false.
The code to allow the ITB to
record the operating levels of the adjacent machines is necessary to properly
index test a unit, and there never was any “co-mingled” code. The added
code modules were made necessary by COE’s mandate of changing from RS-232 to
OPC-communication, and they were always kept separate from the Copyrighted
source code for the ITB.
The field testing was
satisfactory to show that the ITB is “ready for unattended testing” per your
turbine testing supervisor, Dan Ramirez, and it worked well enough that Rod,
Dan and Lee petitioned the DOE HOT committee for additional funds to buy two
more to continue field testing.
Their request got over-ruled
by Dick Nelson and GMT in favor of an “in-house/hired contractor” arrangement
with ACSI.
To the contrary - the GMT saw
a threat to their status quo, and Dick Nelson’s clout and Ed Miska’s
shenanigans were used to thwart our successful project in favor of starting
anew with ACSI making a knock-off of my instrument. Through complaints to DOD
IG and DOE IG, this was curtailed, but could not be stopped entirely; HDC
started their own in-house GBO project instead.
Additional communications to
DOD IG that exposed the “shell company” that MK and his wife ran out of their
house instigated a wider DOD IG investigation, which led to the GDACS blade
accuracy survey that exposed the awful blade angle sensors and other blade
controlling software problems at McNary and everywhere else. A specific
indicator of the problems was the approximately 65 faults per month at
McNary. Additional money from BPA was spent to fix these problems.
HDC personnel changed their
project name from ITB to GBO in order to get it “off the IG’s radar.”
Additional investigation and resulting information to IGs and BPA management
exposed these deceptive practices by HDC personnel, and then the HOT meetings
stopped happening altogether.
HDC
makes a practice of pirating technology from the private sector and making
shoddy, substandard copies of it, and then setting friends and civil service
employees up in “captive suppliers” and “shell companies” to defraud the
taxpayers.
Collateral
damage from this substandard equipment (to my knowledge dating back to the
first Seawell 3-D cam, and perhaps further back) has caused ever-increasing
deterioration of the turbine blade control equipment, resultant excessive
turbine trunion bearing wear (and welding of Kaplan runner blades to a fixed angle
in some cases) leading to blade misalignment from the optimum - all to the
detriment of fish populations that must pass through these turbines on their
way back down river to the ocean.
In
my opinion, the onus for the declining populations and extinction of fish
species can be directly traced to the greed and procurement favoritism that
Government personnel are inclined to practice. It’s all just shameful.
IV. Comments on Reference
Documentation
Figure 113 Excerpt from HDC Response, misrepresenting purpose of Copyright and four separate modules used to organize code.
For #1, #2 & #3, no
comment necessary.
This is a repeating theme in
the HDC Response, which entirely misstates the purpose of the Copyright and
code modules.
Figure 114 Excerpt from HDC Response, a misrepresentation of the purpose of the Section J agreement, Copyright and code modules.
This is a repeating theme in
the HDC Response, which misstates the purpose of the Copyright and code
modules.
Figure 115 Excerpt from HDC Response; a reference to Dave Ebner's not about my frustration with the unethical behavior of HDC personnel.
I don’t have this hand
written note so I cannot comment on it directly.
However, from the date, I can
comment on the situation in the project at that time. Ed Miska had taken over
as “Technical Lead” for the project, and unilaterally directed difficult and
expensive changes to the workscope, moved performance milestones and provided
inaccurate information and instructions that consumed time and material on
“wild goose chases.”
Ed delayed getting the
task-order to ACSI so they could make their part of the perturbation
communication interface until after I sent the ITB to HDC Portland. When the
ITB was at HDC, Ed invited Dan Perrier in to help him concoct the “zero-problem,”
a scheme to discredit ATECo, the ITB and me.
Ed Miska was allowed to
unilaterally alter my contract in secret to my disadvantage, without the
knowledge or consent of Dave Ebner (my COR) or me, in a way that would defraud
me out of the negotiated, agreed-upon $750,000 price for my Copyrighted source
code.
So yes, the contract was in
danger of going into default, but the fault would be the Government’s.
My position is that it was because of an organizational-level attempt by HDC to
defraud me out of my intellectual property that there was a potential “default
on the Contract.”
I don’t know what Dave put in
his “hand written note,” but it should have said something to the effect
of, “I’ll see you in Court.”
The Government’s position
on this was very weak, according to my Congressman, the U.S. House of
Representatives’ contract lawyer he engaged, my own corporate lawyer and my brother-in-law,
who is also a lawyer, all of whom reviewed the original and tampered-with
modified contracts and said as a lay-person, I did well to catch the attempted
fraud and not sign it.
A Court case where
Governmental fraud is proven can be a big, moneymaker for the injured party.
Figure 116 Excerpt from HDC Response; complaints about first field test. My major complaint was that the contract had been tampered with and HDC refused to fix it.
I agree I was disrespectful -
but no Apologies will forthcoming. The even greater unstated problem on
this test and at this point in time was the attempt by HDC to defraud me out of
the $750,000 negotiated, agreed upon price for my Copyrighted software by
allowing Ed Miska to tamper with my contract and then everyone on the
Government side bullying me to sign it anyway.
The field-test that
these Government comments are in reference to was conducted without anyone from
my company being allowed to attend.
We were barred from this test because I was refusing to sign the illegally
altered modified Contract.
The modified contract was
altered in secret by Ed Miska, who was allowed to put changes in without the
knowledge or consent of my Contracting Officer’s Representative, Dave Ebner or
me that would have given my $750,000 software source to the Government without
payment.
Figure 117 Excerpt from HDC Response; this is absolutely true. The contract tampering and zero problem scam were an attempt to steal my Intellectual Property; I was being cheated and bullied by the Government and was simply fighting back.
This is absolutely
true, and I stand by this complaint and these allegations. The illegal contract tampering by Ed Miska and the
support of this sham by Ralph Banse Fay and the complicity of everyone else on
the Government side by looking the other way was maddening. And now it
is outrageous to have the Government trying to foist the onus for this failed
project onto me,
So, I say again, here, now, today - “ENOUGH ALREADY.”
Figure 118 Excerpt from HDC Response. This is an arbitrary and capricious interpretation of the Contract terms.
Because this was a time and
material contract, the Government was allowed to put in multiple expensive and
time consuming changes for the benefit of the Government, for which I was
assured that additional time and money would be provided to accommodate and
allow for these changes and additions. This complaint is overlooking the many
salient facts of the matter delineated herein.
It also overlooks that there
were several versions of the modified contract. The added funding in this
version was to allow continued work because of unforeseen natural and
contrived man-made difficulties that were encountered. A brief listing
of the man-made, contrived problems that were encountered is in the web
reports, “What it was like to work for USACE” and “Reasons for Delays.”
Figure 119 Excerpt from HDC Response. Reference to post-first field test conversation.
These emails were sent
while the Government was overtly and covertly attempting to defraud me out of
the negotiated, agreed-upon $750,000 price for my pre-developed, copyrighted
software source code. I was becoming understandably frustrated and angry at the
lies, deceptions and bullying by Government personnel and became uncooperative
and belligerent about it - I was just pushing back.
Take note that these
issues were for the most part, resolved when Ed Miska was removed as Technical
Lead and Rod Wittinger was reinstated.
Figure 120 Excerpt from HDC Response; reference to post second field test conversation.
I don’t have a copy of this
letter, but I have the following comments on this test.
This test failed to
accomplish anything useful due to USACE’s mislabeled Winter Kennedy taps and
incorrect blueprints.
This test went forward after
the contract was restored to the exact wording that Dave Ebner and me had
agreed upon, Ed Miska was removed from the project, Rod Wittinger was restored
as the Technical Lead, Lee Sheldon was restored as the HDC Contact, Paragraph
3.4.2.9 was returned to it’s proper form and paragraph 3.4.2.9a was removed
altogether.
The HDC Response is quibbling
about a few bugs in a new software program’s first roll-out like they are a
really big deal. They all got fixed before the Ice Harbor test.
What was really a big deal to me was the Government’s attempts to cheat
me out of the negotiated, agreed-upon $750,000 price for my Copyrighted
software, now that’s a big deal.
So I ask you, dear reader,
if you’re still with me here, how would you act if the Government agency you were
in contract with, tried to defraud you out of your $750,000 intellectual
property (software source code) that you’d been working on for over 20 years?
Though we didn’t know it at
the time, the failure of this field test was due USACE neglect with the
mislabeled Winter Kennedy taps.
Figure 121 Excerpt from HDC Response, more distortions and deflections of responsibility away from COE.
As stated above, I didn’t see
the draft letter so I cannot comment on it.
My position at this point was
extreme distrust and disgust with the Government, but agreed to do along with
Rod Wittinger and Lee Sheldon on this December field test to get the chance to
show that the ITB really works. I had already complained of the problems I was
experiencing to DOE IG and DOD IG in mid-November 2005.
With everything else that had
happened, adding some money for the test doesn’t seem so unreasonable.
It could be said that this
added funding was to reimburse ATECo for the cost of participating in the
failed September field test. The September test failed because of mislabeled
Winter Kennedy taps and inaccurate powerplant blueprints. ATECo spent $16,000
on this failed test, so adding $16,002 seems fair to me.
Figure 122 Excerpt from HDC Response, discussing deliverables and upcoming test.
This is an unabashed
misrepresentation of the situation.
Due to HDC misdirects,
continual attempts to purloin my Copyrighted software source code, COE directed
configuration changes to ITB including change from discreet sensors to digital
communication with 3-D cam and switch to OPC communication, addition of
automatic Winter Kennedy flushing etc, the adjustments to the funding and
deliverables list were to compensate for COE’s directed changes to the
configuration and workscope.
Diagnosing the contrived
zero-problem by Ed Miska and Dan Perrier took considerable time and effort.
Greg Luna made a wasted trip
to McNary that was a failure because the Winter Kennedy taps were mislabeled
and the powerplant blueprints were wrong.
Much time was spent
struggling with the contract modification that was altered in secret by Ed
Miska in an attempt to deceive me into signing over the software source code
without getting paid the negotiated, agreed-upon $750,000 for it. Was it
really such a big surprise to HDC personnel that I would bother to read a
Government contract before I signed it, and that I would object to
unfavorable text that was snuck into the contract by deception?
The Government initially
agreed to the adjusted deliverables to make it seem advantageous to me so I’d
want to sign the modified contract with the secretly added text of paragraph
3.4.2.9 and the addition of 3.4.2.9a (as described elsewhere in this letter),
hoping that I’d be stupid enough to sign the modified contract without reading
it.
Figure 123 Excerpt from HDC Response, regarding Rod Wittinger’s field test report.
This is a totally false,
inaccurate and misleading passage.
Rod’s Report was a detailed
listing of how the field test progressed, and identified software bugs that
were identified that needed to be addressed. These were corrected before the
Ice Harbor testing February.
The ITB could not operate
independently because it could not do the Constant Power test, which was
the fault of the sub-standard GDACS 3-D cam and blade control system and
resulting overall bad dynamic behavior of the turbine and governor system.
The ITB performed abundant
analysis, as delineated in the Data Analysis section
of this letter.
The document was weak, the
reason for this is explained it the Documentation section of this letter.
The source code
requirement was complied with to the letter. There was no requirement to give the Copyrighted
source code until the government paid the negotiated, agreed-upon price of
$750,000 for it.
The claimed threat to GDACS
security is nonsense.
Figure 124 Excerpt from HDC Response regarding comments regarding McNary testing.
Without these specific
documents to refer to, I’m not certain what this one is about.
However, I freely admit that
some of the areas we were working with were new to me.
Figuring out workarounds to
make the ITB work with the Sub-standard GDACS 3-D cam and bad governor dynamics
was a difficult puzzle.
This is new technology and
there were certainly things yet to learn for everyone involved.
My overall impression from
this experience is that HDC personnel wanted to seize the Index Test Box
technology away from me in order to give it to Automated Control Systems Incorporated
so they could mass-produce and sell this equipment to the government in the
place of my Actuation Test Equipment Company. At about 6-months into the
project, intellectual property security became a much higher priority for
my company than anything else.
Figure 125 Excerpt from HDC Response regarding my allegations of sabotage.
Yes, and I stand by
this allegation. The
Winter-Kennedy transducer manifold cart had been left at McNary after the
failed September 2005 field test. When we returned to McNary in December 2005,
the pressure transducer in the test rig did not work. Troubleshooting the
pressure transducer we found that the screw-on cap had been removed, and one of
the signal wires torn out with a pair of pliers in such a way that it
could not be repaired in the field. Indentations could clearly be seen in the
vinyl jacket of the signal wire where it was grabbed to jerk it out. I showed
this to Rod Wittinger who made no comment other than to write in his log.
Seeing Rod’s report later, he misreported this, the transducer could not be
repaired, but I had a spare transducer so this was not a showstopper, but it
could have been had I not been prepared. Transducer cost $795. The
“zero-problem” story is told above.
Figure 126 Excerpt from HDC Response, regarding price list.
This price list was purchased
equipment costs, the software price schedule from the Contract LI0003 and a
modest markup. Looking at it now, those prices were much too low. The
ATE-150 was not absolutely necessary, but because of the fact that the broken
wire in it thwarted Ed Miska and Dan Perrier’s (ACSI) “zero-problem” scheme, I’m
glad I used it.
Figure 127 Excerpt from HDC Response. More false and inaccurate statements
The test engineer said that
all of the problems that he could check were OK, some he could not check due to
a lack of perturbation software in the GDACS. None of the comments in this
letter express that any problems “were not or could not be addressed by the
Contractor.” The HDC Response is inexplicably hostile – where’s all
this negativity coming from?
Figure 128 A collection of all comments from the referenced letter.
The above is a compilation of
all comments about ITB from Dan’s letter. I don’t see any of the negativity
that the HDC Response document claims is in Dan’s letter.
The truth in it was that the
turbine index testing experts: Dan Ramirez, Rod Wittinger and Lee Sheldon were
all happy with the ITB after the Ice Harbor test and said that the test data
results from my ITB were:
“virtually identical to
those obtained using COE data acq system”
And that my ITB was:
“Ready for ‘unattended,
automated’ data collection.”
Fig 129 below is the Power
Point slide from BPA that shows these comments.
Figure 129 HDC Power Point slide from February 26, 2006 HOT Meeting
And they wanted to
buy two more Index Test Boxes as a result of that test.
Where is all the negativity
in the HDC Response coming from?
Figure 130 Excerpt from HDC Response citing letter to CO.
I do not have this email so
no comment.
Figure 131 Excerpt from HDC Response about contract fulfillment.
#22. A true statement; I
delivered the equipment, it was accepted, and I got paid.
#23. These are all moot
points. The issue was that I developed software and a system that was
demonstrated to successfully, automatically index test a Kaplan turbine. The
logical modules were only used as a construction framework to write the
program. I described them in the proposal to help HDC understand what the ITB
program was and how it worked. This proposal was not mandatory nor was it
purchased. What was purchased was in Line Item 0001 - one each Index Test Box.
HDC did not buy any of the
separate software items from Line Item 0002 or LI0002.
All of this niggling over
software is nonsense; the Government got what was paid for, no more, no
less.
Make no mistake about it – I’ve been working on this program since 1985, and just
because the Government bought one instance of it does not grant the Government
the right to make additional copies for widespread distribution - which now
I see is what the Government was always after.
Further discussion: the modules
as described, if purchased would have been in units of “ea.” Each instance
would have been enabled to work only in the computer platform that they had
been keyed into by having hard-coded serial numbers of the CPU, hard drive and
I/O board of the target system they were going into, much like Microsoft or any
other software vendor protects the Intellectual Property rights of their
products.
The big disagreement here is
that the Government wanted to pirate my program and make unauthorized
distributions and installations of it, and I didn’t want that to happen.
Figure 132 Excerpt from HDC Response regarding my contract tampering complaint letter
I don’t know which July 25
2005 letter is being referred to, but from the timeline I can put it into
context.
At the time that this letter
was written, my contract had been unlawfully tampered with by Ed Miska who was
allowed to add wording to it without my knowledge that, if I had signed this secretly
altered, modified contract, would have compelled me to give the
pre-developed software source code to HDC without the negotiated, agreed-upon
$750,000 payment. While I was being barred from actively participating in the
project, Ed had invited Dan Perrier, of ACSI, HDC’s favored supplier, or
“captive supplier” to HDC in to sabotage my equipment by creating the
“zero-problem,” a contrived software trick to discredit my company, my
equipment and myself. Dan Perrier had already created the “zero-snatcher” as a
quick-fix, so he could be the “hero” after the zero-problem was used to show my
incompetence. I was and am very disgusted and distrustful of HDC for
attempting to take my Intellectual Property by these deceptions, and it
probably showed through in my email letters.
Goto blade perturbation and zero problem
details.
Recording the operating level
of adjacent units is helpful for index testing, and is still in the Index Test
Box program. Right now I’m working with Brookfield power on an index test of
three Kaplan bulb units that are situated in parallel. The index test box is
collecting data on all three through their SCADA system to simultaneously index
test all three units, and we’re learning that the flow rate in the forebay out
in front of these units does measurably affect the measured and actual
operating efficiencies of these units. I have the data to prove the
necessity/benefit of monitoring adjacent units now.
On the subject of GDACS
security - how stupid would it be
for me to do anything to harm your system? Firstly, it would have destroyed
any potential for future business, and if misconduct on my part caused a
problem, you know where I live; you have my tax number. C’mon, wise up.
I’m not the threat here. The greater threat to the Government is rampant
procurement favoritism in HDC that has resulted in to sub-standard 3-D
cams and blade control equipment in every FCRPS powerplant, increased flow
turbulence and shear forces in the water flowing through every Kaplan turbine
that increases the hazard to downstream migrant juvenile fish – all of which
has brought about the Endangered Species Act lawsuit, and the fact that the
sub-standard equipment and continuing cover-up places the Government position
precariously close to, “contempt of court.”
Abuse of software security
Ed Miska said GMT wanted
3-days for “security screening” of the index test box program before testing at
McNary when first delivered in May 2005. Later, while I was rushing to get
everything working before the field test at McNary in December 2005, GMT
insisted on 5-days for the security checkout.
Later we learned that the
security checkout consisted of simply running Norton’s Anti-virus program on
the Index Test Box executable program – a 5-minute procedure,
and that before this test the Index Test Box and GDACS security setup sat
idle for 3-full days.
It seems to me that “GDACS
software security” was used to put up unnecessary hurdles to a successful ITB
field test.
Figure 133 Excerpt from HDC Response discussing software marketing strategy.
The situation with this letter;
it was one of a series of letters exploring options after the Government
chose not to buy the pre-developed Copyrighted software for the Index Test Box
but still wanted access to the functionality of the automatic Index Test Box
for Kaplan turbines. In these letters I was proposing to Dave Ebner different
way to arrive at a compromise, none of which were accepted, so none are
binding.
The government did not
purchased any software other than the one copy in the ITB that was delivered
and software that was written at Government expense, referred to as
Co-Developed code. All of this complaining about modules, source code etc. is
pointless, the Government personnel that wrote the HDC Response are complaining
because I didn’t deliver software that was never purchased.
The Co-Developed code does
not include any of the original Copyrighted source code.
A full set of the
Co-Developed code was sent to HDC when first purchased from ACSI (I bought an
example RS Linx OPC Interface setup and GDACS tag-name set for $1,000, and gave
a copy of it to Ed) on 4/6/2005, an additional copy was given to HDC each time
we were in preparation for a field test, another copy was given at the end of
the Contract workscope, and copies of the Co-Developed code were given to HDC
whenever it was requested.
Ed Miska always complained
that the pre-developed Copyrighted source code, the main body of the
programming that was comprised of the SteadyState, StripChart and XY-Plotting
routines, was not in the software that was delivered - and each time I would
explain to him that it had not been purchased, so it was not delivered.
The price schedule for
software was in the Contract as Line Item 0002 and Line Item 0003.
The Government did not buy
any of this additional software; so all of these niggling software discussions
are moot.
The last sentence is also
false. The Government would not be dependant on the Contractor after purchasing
the software, and would not have to pay for each use. The Government would
only need to buy the software once, but instead, the Government wanted full
access to the software source code in order to produce unlimited copies of
the program without paying for it at all.
After it had been purchased
the software would be the property of the Government and could be used at will,
within FCRPS per the negotiated agreement with Dave Ebner at the
beginning, and renegotiated at the end of the contract performance period.
I refuse to subject my reputation and business’ future to
people whose primary objective was to learn how my instrument worked, co-opt
and steal whatever they could from me and then to go forward claiming to have
invented the Index Test Box themselves, and then employ another supplier (ACSI)
to mass produce and distribute it to/for them. Failing at that chicanery these
scoundrels are now using the “bully pulpit” of the United States Army Corps Of Engineers
Hydro Design Center to
disparage my company, my products and me in a fit of “Sour Grapes” because they were unable to steal or replicate my technology.
In closing, I must say that the Government’s HDC Response
that this letter is in reply to is the most disingenuous, manipulative pack of
lies I’ve ever had the displeasure of dealing with. As a result of this
encounter, my level of respect for Government employees and trust in the
Government in general has reached a new all-time low; I live in Illinois, so
that’s sayin’ something.
Sincerely,
Douglas J. Albright
Winnebago Illinois
October 19, 2009
