Douglas Albright – President
Actuation Test Equipment Company
3393 Eddie Road
Winnebago, Illinois 61088
September 4 2009
Mr. Mike Roll Deputy Director
Hydroelectric Design Center (HDC)
United States Army Corps of Engineers (USACE)
Portland District
P.O. box 2945
Portland, Oregon, 97208-2946
Subject: ATECo response to HDC supporting documentation to the Marginal rating of Contract W9127N-04-D-0009.
Dear Mr. Roll,
Your response documentation of August 21, 2009 (hereinafter referred to as “HDC Response”) that outlines the basis on which a “Marginal” performance rating was assigned to my contract is no more than a collection of falsehoods, distortions and obfuscations. That document made no response whatsoever to the points in my non-concurrence memo that was incorporated into the original HDC Contract evaluation’s performance rating. To the contrary, my rating of your “technical office responsible” for derailing this project is “unethical, deceptive and bullying.”
My penultimate complaint is that initial contract negotiations established the price for my pre-developed Copyrighted software, negotiated and agreed to with your Contracting Officer’s Representative (David Ebner), at $750,000. Thereafter, for the entire course of the project HDC personnel (Ed Miska) attempted to get this software source code and the underlying Index Test Box technology away from me by fraud without making this fairly agreed-upon payment; we call that theft out here in the private sector.
I vehemently do not concur with the HDC Response document received from you, in that it altogether misconstrues the events and facts at hand. In the following web pages and accompanying video clips I will readdress the key points of my non-compliance memo by parsing the comments in the HDC Response memorandum and responding in turn to each point with specific, detailed, conflictive information and elaborate as necessary to fully explain the circumstances.
I look forward to communicating with your district Commander. However, in order to avoid the expense and time of traveling from Illinois to Oregon, I’d prefer emails and videoconferencing using one of the many commercially available products designed for this purpose, such as WebEx, GoToMeeting or Skype. These are all currently available and well suited to facilitating communication such as this.
At this point I see the entire matter as an unprofitable exercise for me, but I do still want to deal properly with these issues. You are my Government, and need to be taken to task on this matter. The only way to correct the “culture of corruption” that exists in HDC is to bring all of this to the attention of USACE’s upper management and/or other agencies of the Government, then hopefully corrective action will be taken.
Note: I prefer to work with HTML and emails, because embedded links make access to reference documents a snap and widespread distribution a breeze. Therefore, this is a web-based letter. The letter itself and all of the referenced support documents are available in electronic format over the Internet. If the reader is getting this in a printed, hardcopy form, please find an Internet terminal and download the file:
“http://actuationtestequipment.com/ATECo_Response.htm”
For the convenience of the
reader, all of the reference documents are on-line, accessible via the embedded
links. Additional internal links will jump to specific subject headings within
this document.
For background reading, here are links to:
- The HDC Contract evaluation the original contract evaluation from HDC, (scroll down to item 20, “Remarks”).
- A Letter to Steven Wright explaining to BPA what happened to the Index Test Box they bought in 1985 and 2004.
- The current HDC Response Memorandum that is the subject of this letter.
I. Comments on Documentation in Support of DD Form 2631
1. My Background
2. The Big Picture
3. My Response
4. Problems at McNary
5. Kaplan Blade to Gate Parallelogram Spiral
6. Two Prior Successful Demonstrations
7. Experience at McNary and Ice Harbor
8. What is an Index Test?
9. Data_Analysis
10. Live Action Display
11. Documentation
II. Comments on Source Code and GDACS Security
1. First Field Test: “Zero-problem” thwarted on Unit 5
2. Contract Tampering Specifics
3. Blade Perturbation and Zero Problem
4. Zero Problem Explained*
5. Second Field Test: Mislabeled Winter Kennedy Taps on Unit 5
6. 3-D Cam blade controller problem*
7. Test Conditions
8. How the GDACS 3-D cam works
9. McNary_Skew
10. The Cover-Up
11. Broad Brush Index Test Box Unit Checkout Fundamentals
12. Gate and Blade Actuator Design and Functional Checkout
13. 3-D Cam and Blade Positioner Checkout
14. Governor Robustness, Accuracy and Stability
15. Blade Positioner Robustness, Accuracy and Stability
16. Who’s Zoomin’ Who?
17. Government Plagiarism
18. Substantiation of allegations
19. What is Co-Developed Code?
20. Lunch_Date
III. Comments on HDC Response References
1. Government violation of Section J Provisions
2. Purpose of Pre-Developed Code Modules
3. Contract Negotiations Interrupted
4. Software Security
5. Monitoring Adjacent Units and Velocity Head
IV. Comments on Reference Documentation
Abuse of software
security
I. Comments on Documentation in Support of DD Form 2631
My Background
As a demonstration of my background in this, please Google the phrase “index testing Kaplan turbines” by clicking the link, or just enter the phrase “index testing Kaplan turbines” into Google (http://www.google.com/) yourself if you have a doubt. The first few items in the Google listing will include links to my company website, www.actuationtestequipment.com and my expired U.S. Patent #4794544.
If you doubt my links and the copy of the patent
from my website, this link will take you to the United States Patent Office http://uspto.gov/, then use the
patent search utility to find it there, or just click this link to get to the
official U.S. Government Patent for my instrument: Click here: United States Patent: 4794544. My patent has been the #1 item on the Google search
engine in response to entering the phrase, “index testing Kaplan turbines” for
over two years now. Those are the vanguard of my claim to and knowledge of this
topic -these, and my ability to create an automatic Index Test Box for Kaplan
turbines that really works - are the reasons why HDC contacted me in the
first place.
I will also state that my background was not in hydro; my expertise in instrumentation, data acquisition, computer programming, physics and control systems stems from 20 years of working with dynamic analysis of aircraft engine fuel system components for F-4, F-15, F-16, F-29, A-10, B1 etc., and a variety of commercial aircraft fuel controls at the Woodward Governor Company. My hydro interests stem from for George Mittendorf at Woodward’s hydro division in 1985, where he hired me away from the aircraft division to create his Index Test Box for the hydro division by adapting the computer programming, data manipulation & analysis techniques that I developed for mapping fuel ratio and Variable Stator Vane cams for LM2500 gas turbine engine fuel controls (used in U.S. Navy frigates and destroyers) to cam mapping (blades to head and gates) for Kaplan hydroelectric turbines. George is a past chairman of the ASME PTC-18 committee, currently an emeritus ASME board member, and still a mentor to this project.
When engaging with HDC on this project, it was understood that what I “brought to the table” was this expertise in data acquisition, computer software and data analysis - and my name on the expired U.S. Patent for the only existing successful automatic Index Test Box for Kaplan turbines because I created it, and the certainty that I could produce another one for USACE. I had a big head start on this effort because I had already been working on the ITB computer programming within my Actuation Test Equipment Company for several years in preparation for Woodward’s patent to expire. Any shortcomings I may have had in the area of hydropower were to be compensated for by the presence of Lee Sheldon and Rod Wittinger on this project. To criticize me now in this way is not in keeping with our original associations.
Truth be known, aircraft control systems work exactly like hydroelectric control systems, except they are two or three orders of magnitude faster. Where hydro control theory works in the realm of seconds and tenths of seconds, aircraft systems work in milliseconds and microseconds; making aircraft controls much more difficult to instrument and analyze because they are so much faster - but the underlying control theory fundamentals are identical.
In every case – the HDC Response document is over-stating the minor problems we experienced from my equipment while overlooking USACE HDC’s much larger, self-inflicted problems resulting from the sub-standard GDACS 3-D cam and blade control equipment procured under dubious “captive supplier” sole-source contracts and task-orders on the Government side, and with few exceptions I resent the open hostility and contempt received from Government personnel while working on this project; I’m glad it’s over.
The Big Picture
I am aware of the facts that throughout FCRPS, excessive misalignment of Kaplan runner blades away from the optimum position exists, creating greater turbulence and shear forces in the water that flows through these 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.
During a pre-test walk-through of Unit 5’s
turbine pit with Rod, I saw him at first puzzled, then angered, and then
trying not to let me know that there was a problem with this unit – but
“the cat was out of the bag.” Apparently, when the GDACS gate sensors were
installed, gate and blade calibrations had been disturbed by people who didn’t
know what they were doing taking the machine apart and putting it back together
with the new GDACS sensors on them. Rod was upset that his expertise had not
been utilized when the machines were dismantled and reassembled, and his angst
made sense to me. As the “Senior Mechanical Engineer” at the Hydro Design
Center, he most certainly should have been involved when the mechanical
components of these units were dismantled and reassembled, but he was not
even aware of it.
Figure 1 Excerpt from USACE Power Point 0423_3DCAM_TMT_Apr08.ppt
This slide #5 came from a Power Point that popped-up by Googling “USACE
GDACS”.
http://www.nwd-wc.usace.army.mil/tmt/agendas/2008/0423_3DCAM_TMT_Apr08.ppt
It was hoped that my Index Test Box could be used to index test every single turbine, instead of the paltry 1-of each family that the conventional methods are limited to. My original 1985 index test box (built for Woodward) was designed to work with the 18 3-D cams that Woodward installed at Bonneville in 1980. This one would too, I know, I made them both.
Instead of the short-sighted goal of index testing “one of every family,” the Corps of Engineers should be index testing and optimizing every single Kaplan turbine at least once every 5-years. In accordance with the Endangered Species Act’s requirement that the best available science be used, it seems prudent to at least do the work to apply a modicum of science to all of the turbines.
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 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 predictions and fish mortality rates 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 other tests 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 at McNary dam derived many fish mortality models. When an author of this paper was contacted to inquire, he had presumed the turbines and control systems were perfect for all of his studies.
I am also aware that the Federal plants are the only hydropower facilities in the Columbia River Basin that have been identified as trouble-areas for fish-passage and that the Court and the Congress are now moving to breach at least four of USACE’s hydroelectric powerplants because of it. It is also known that the five non-Federal powerplants that are interspersed among the Federal plants have not been targeted by the Endangered Species Act lawsuit, apparently because they do not pose a threat to these fish.
A pointed study of this situation must consider differences in the control systems for the Kaplan turbines in these two classes (Federal and non-Federal) of powerplants. From communications with the non-Federal plants, we also know that they acquire their control system equipment exclusively from legitimate, competent, reputable suppliers instead of designing their own control equipment and then setting up “captive suppliers” and “shell companies” to provide the equipment - as HDC has done. As a result, the non-Federal plants do not have the excessive blade misalignment problems like we saw at McNary and Ice Harbor, and furthermore, the non-Federal plants routinely index test and optimize all of their turbines, while USACE does not. Operating in concert, these factors would undoubtedly lead to higher turbulence and shear forces in the water flowing through the Federal (your) turbines, and the result would be increased hazard to downstream migrant fish.
For a historical reference, the blade misalignment problem in USACE powerplants is not new. The Government first saw the successful electronic 3-D cams provided by Woodward Governor at Bonneville Dam in 1980. Ever since then, HDC has been trying to reverse-engineer and replicate this technology using in-house engineering and local subcontractors to design, mass-produce and deploy it instead of buying this equipment from the competent, reputable supplier that created it in the first place - with disastrous results.
The first attempt at this was the Seawell 3-D cams that preceded (and were even worse than) the GDACS 3-D cams that are in place now. Seawell 3-D cams had a problem that if a walkie-talkie radio were keyed-on near the signal wire trough, the signal lines to the 3-D cams would pick-up the radio signal - the blades would jump, power output of the generator would jump, and then the gates would jump, and then it would take several minutes for the units to settle out again. This problem was so bad that the powerplant personnel just switched the Seawell 3-D cams off and never used them, making the “skew” problem shown in figs 37, 38 & 39 (below) permanent and continuous. A “tongue in cheek” corollary to the effect of this blade-misalignment on the fish that must run this gauntlet on their way to the ocean is the “Bass-O-Matic” skit that ran in the first season of Saturday Night Live.
Common Sense dictates that all of these things are connected. It was the stated hope in 2004 that by acquiring and incorporating my proven ITB into the Federal plants that a simple, inexpensive means to initially index test all 113 of USACE’s Kaplan turbines could be implemented to identify the existing blade misalignments so that corrective actions could be undertaken. Furthermore, ITB monitoring & retesting all of these turbines periodically thereafter in order to trend performance and then optimize (or tune-up) the 3-D cam surfaces would maintain peak operating efficiencies. This would yield greater revenue to the Federal Treasury and decreased hazard to downstream migrant juvenile fish.
But it was not to be; with HDC personnel’s desire to seize and co-opt the ITB technology, and my tenacity to keep it away from HDC until the agreed-upon payment was received - in the resulting struggle everyone lost out. The biggest problem with execution of Contract W9127N-04-D-0009 was that HDC personnel continually attempted to thwart progress; to protect the status quo, to purloin my ITB technology without paying for it - and then, failing to get it away from me - just co-opting and claiming credit for creating the ITB without knowing how it really worked or possessing the technology. All this was done with plans to give it to another, more favored (“captive supplier”) contractor to mass-produce, deploy and profit from it.
By a continuing struggle I was able to prevent HDC personnel from manipulating the ITB technology away from me by their deceptive, bullying tactics. Further investigation into what HDC had been and were doing and then presenting this information to several Inspectors General prompted investigative actions that, “kept the lights on,” and had a temporarily effect of suppressing this blatant, ongoing corruption. It is my belief that when this corrupt and unsavory situation was made known to Bonneville Power Administration, this was the reason that the HOT meetings have been discontinued.
This continual struggle over the intellectual
property that I brought to the table was a determent to everything we were
trying to accomplish.
I’m pleased to state that the ATECo ITB project is still moving forward. I am currently working with a private sector power company in Canada to simultaneously index test 3-bulb-type Kaplan turbines in a “run of the river” situation, and have started the preliminary setup to index test a vertical Kaplan turbine located on a reservoir on the Montreal River. Status of both jobs is purchase order in hand and money has been received. I’m moving forward with my Index Test Box (ITB) project, now.
====================================
The HDC Response avoided the key elements of my non-compliance statement, and misrepresents many of the facts at issue. Have you seen the email letter that I sent to you c/o your Rowena Musser on 29 June 2009 with the attachment:
“What it was like to work with USACE HDC?”
In this document I listed specific overt and covert events that attempted to thwart success of Contract W9127N-04-D-0009, and several items that indicate conflict of interest problems within HDC. These allegations went altogether unanswered in the HDC Response document.
Please ask the “technical office responsible” for my contract to address the following topics (after reading this entire letter and attachments before answering).
- 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 under retainer to the U.S. House of Representatives whose opined that it was not – the only reason 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 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?
- 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 the fact by changing the name to Gate Blade Optimizer (GBO) - and was that project ultimately successful?
- 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 Gate Blade Optimizer?
- 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?
- Is there a 35-second deadtime programmed into the GDACS 3-D cam and blade controllers at McNary?
- Do the 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 to these nominal, industry-accepted standards?
These things are all true and connected, as I shall show herein.
==============================
My Specific Reply to the HDC Response Document
I agree that the page excerpted from the contract shown in fig 2 (below) describes what we were after. We haggled over this contract for over a year and a half so that the terms specifically identified the goals, protected both parties’ interests and were mutually agreeable to both sides. I disagree completely with the conclusions and supportive documentation to HDC’s position in the HDC Response document, however.
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 everyone else involved that pressured 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 been negotiated and 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 2 Excerpt from HDC Response, description of project goals & deliverables from the Contract
Indeed, the ITB does do (and have) all of these things, as will be delineated in this web-letter and demonstrated by on-line documentation and video clips.
Problems at McNary
Let me start out by stating unequivocally that the most insurmountable problem we confronted at McNary was caused by the sub-standard governor dynamics of HDC’s self-inflicted, sub-standard GDACS 3-D cam and blade control system. This problem prevented the successful execution of the Index Test Box’s preferred “Constant Power” testing method.
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 job 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 only answers I could get at the time were that, “Many in the
Government were not convinced it was possible to automatically index test a
Kaplan turbine with a computer, so a proof of concept test was necessary” – and “It’s our money, and that’s the way we
want it.”
Looking back now, I believe that 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 me.
The denial of access to the MockUp that I was supposed to use for the “bench test” specified in the Contract was documented in Lee’s original comprehensive memo. Here is an excerpt from that 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 to write another report in the same vein for general dissemination (to BPA HOT), 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.
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
Figure 6 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 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. 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 7 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 7 below is the Power Point slide from BPA that shows these comments.
Figure 7 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). Other problems inherent with the
GDACS 3-D cam were the reason we could not perform the “unattended index test.”
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).
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 29 degrees and remove the oil from the hub, thus
rendering these Kaplan turbines into “fixed-blade” propeller turbines.
Dan’s
explanation of the GDACS 3-D cam behavior went like this (ref fig 8, below):
When a large upward SetPoint change is
made in power,
1.)
Starting at (a.) on 8, the governor’s
speed motor is activated to raise the SetPoint by the GDACS control system,
2.)
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.
3.)
Power output is sensed by the GDACS
control system, which continues opening the gates until the generation SetPoint
demand is satisfied at (b).
4.)
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.
5.)
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).
6.)
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.
7.)
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.
8.)
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 © 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.
9.)
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 8 Parallelogram spiral motion of Kaplan blades with GDACS 3-D cam
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 timing 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. 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.
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.
To
minimize the consequences of this problem, the operators change the generation
SetPoint very slowly on these units so 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. Add this 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%, which all other hydroturbine 3-D
cam and blade control equipment suppliers conform to. 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 specify in the acquisition documents for this control system
equipment. It is up to the Contracting Officers to mandate that the equipment
be in compliance with the industry-accepted industry 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 USACE 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 get 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 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 saw 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 that now he was a believer.
Now I see that HDC personnel’s hidden agenda
in contacting me and via this Contract was always 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 ` (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 such products with their own money, is. Who paid for MK’s plane ticket to Sault Ste Marie? And what role did RK’s (wife of MK – an official USACE liaison to ACSI) ACS-Automated Control Systems Incorporated - a company that RK (and MK) ran out of their home from 1996 until 2005 – play in this?
RK and 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. Looking at them individually, the name “Kxxxxxxd” jumped out at me because MK had been a nemesis to me when I was working with HDC in Portland. After the incident with the MockUp (described above), his name was anathema to me and caught my eye when I saw it again. The Beaverton white page show M and R K’s home address is the same as the address of ACS-Automated Control Systems Incorporated, and the local college records showed that RK teaches technical math classes there. It is doubtful that a full-time college-level tech-math instructor whose students rate her teaching abilities on the school’s website with “smiley faces” would have the background and time to run a real controls company - something else is going on here.
The Google is a wonderful tool, which was not available in 1996 when RK’s company was incorporated, which was just 14 months after HDC setup their “captive supplier,” Automated Control Systems Incorporated and hired Dan Perrier to run for them. It was also interesting that RK’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 showed 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, page 4, paragraph 3)
Figure 9 Excerpt from Rod's memo, page 4 pp3 citing 1.0 to 0.5 degree deadband reduction
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 that instead of using the ITB’s labor-saving Constant Power method to automatically index test the unit, in order to demonstrate the natural Constant Power lines in the turbine operating envelope and the ITB’s ability to detect “SteadyState” operating conditions, we would manually control the unit by positioning the blades with the ITB perturbation feature, and then position the gates by bringing down the Woodward Governor’s gate-limit to clamp the gates in position, and stop the machine’s incessant dithering.
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.
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, 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 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 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 cam, 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 10 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 11 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 12 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 13 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 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.
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; now with two additional successful index tests performed at McNary and Ice Harbor and 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 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 14 Excerpt from Dan Ramirez's email to Rod Wittinger reporting on Ice Harbor ITB testing
And:
Figure 15 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 indicated that the governor dynamics are 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 16 Power Point slides from HDC presentation to BPA HOT Sept 12, 2006
In this excerpt from the accompanying HOT Meeting minutes:
Figure 17 Excerpt from Sept 12 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.”
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 payment of the $750,000 price that was
negotiated with Dave Ebner. I resisted every effort to have it 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 blade perturbation is installed - then an automatic, unattended Constant Power index test can be run, which due to the labor savings, and no large swings in power and flow that result - would be preferable to any other methods.
The Index Test Box could not do an index test using the new “Constant Power” method at McNary Dam, but the fault was 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 18 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 18 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.
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 18 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, 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 contract
was a “zero sum game,” in that if something is 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, get access to a unit to test, protect my
Intellectual Property and 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. The 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.
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 at any time, but always chose not to, and tried repeatedly to get it 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, and Ed is a liar, cheat and thief. I am ashamed that my Government would behave in such a way and employ such a person.
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 use the 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 19 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 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 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.
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 an 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 – “Sour Grapes.”
II. Comments on Item 17
Attributes
First Field Test: “Zero-problem” thwarted on Unit 5
Figure_20 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 because nobody from my company was allowed to participate in this field test of my product. 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 had added text to the contract that would compel me to give my Copyrighted source code to HDC without the proper compensation. Ed was allowed by the USACE Contracting Officer 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 opined 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 21 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 Technical Lead for this project; he was the HDC Senior Mechanical Engineer and highly skilled and experienced at turbine index testing. Lee Sheldon was (and is) a hydro-turbine index-testing expert, and had worked with my ITB in 1985-1987 at PGE-PHP-2. It was the expertise, judgments and efforts of these two men that got this project started.
Figure 21 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 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 it was painfully obvious to me that his sole purpose from the beginning of his involvement with this project was to disrupt any progress to protect the status quo, and to take the ITB technology away from me to give it to ACSI.
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 is shown in figure 22, 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 text so as to make it more noticeable to another person reading it. 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 his tampering in a quick read of the Contract and not catch it, and then it could be used later as a “gotcha!” to seize my intellectual property without compensation. It was outrageous for HDC to make this unilateral change to my contract, in secret, and then to bully and coerce me to sign it for 2 ½ months in repeated attempts to force me to give HDC the copyrighted source code without the agreed-upon compensation by this deception.
This is Government misconduct of the basest kind.
Figure 22 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.
Figure 23 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 23 Excerpt from Contract W9127N-04-D-0009 showing original text
Ed’s secret
alterations to this paragraph are shown in figure 24. These secret alterations
to the modified contract were crafted so as to give me paragraph 3.4.2.9a 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 (yellow highlighted) that were secreted
into the original paragraph 3.4.2.9 that were not indicated in the Change
Record, nor were they highlighted or bolded to indicate that they had been
changed. This was a clever ruse, but it didn’t work. I read every word of
the Contract carefully and caught it.
Figure 24 Excerpt from Modified Contract W9127N-04-D-0009 page5, showing text secreted in by Ed Miska
Figure 25 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 contact 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 into 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 was 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
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 – 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.
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 26 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 - 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, 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),
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. It seems now that my suspicions were not unfounded. 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 22 to August 8 - Dave Ebner’s vacation.
- 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.
- 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 still figuring out what the deal was with 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, and was explaining it 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 and change the subject. Ed was silent for the remainder of the meeting and I completed the explanation of the “zero-problem” to the group.
- 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 prepared 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.
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 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 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 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 Ed invited a more “favored contractor” in to
sabotage my equipment* while I was barred from working on it - 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 allow Ed and Dan (ACSI) to devise a way
to sabotage the ITB. 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. 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 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 month of struggling with Ed and Dan’s (ACSI) contrived “zero-problem” that was preventing any field-testing, Ed said that this problem - that had barred any and all field testing - had miraculously just “gone-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 when Rod reassumed the Program Manager & Technical Lead positions after the contract was restored to the agreed upon terms, and I had signed it.
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 at revision ITBRev1.br16.exe. The revision level at the December field test was ITBRev1v31.exe. No other version of the program should have been 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.” 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). 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 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
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 27 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 they 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 Perrier (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 to the GDACS blade perturbation input. (This 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 use 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 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 was going on and explained it to the “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 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. As a result, Dan Ramirez was puzzled why he couldn’t set the blade
perturbation to zero-degrees of offset. I explained that it was the
zero-snatcher that Ed and Dan 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 dubious plot to purloin my software source code.
Figure 28 Excerpt from Rod Wittinger's report makes reference to the “zero snatcher" issue, page 2
Figure_29 Excerpt from HDC Response, a diversion of fault of second failed field-test.
Second Field Test: Mislabeled Winter Kennedy Taps on Unit 5
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 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 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 30 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 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 to 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 before the GDACS was installed in December 2000, the vibration & rumbling in the floor, rattling of the stairway guard rails and general noise level in the powerplant when the units were running had been much less - but due to USACE 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 an authority of blade perturbation 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 ate up (+/-) 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 31 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) 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, I wonder?
Figure 32 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 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 33 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 we were allowed, we couldn’t move them far enough to locate the efficiency peak. The error seen is all offset - 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 appreciate the impact of this problem; one must understand how the GDACS 3-D cam works. *
Figure 34 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
Figure 35 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 taper (very similar to the original Woodward 2-D cam configuration). To trim the blade position above or below the linear taper on this 2-D cam to get that 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 to prevent damaging anything.
This resulted in the default condition of the blades tracking only the “linear taper” portion of the cam (between 30 and 54 degrees of rotation in fig 36) 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 result of this 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.
When the 3-D cam 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 37, 38 & 39.
Figure 36 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 cam-follower roller riding along the top of this cam is lifted by the linear taper of the cam, moving the blades from full flat to full steep between 30 to 54 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 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 37, 38 & 39 (below).
McNary_Skew
Figure 37 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. We couldn’t get any index test data for this unit due to the mislabeled “leaking” Winter Kennedy taps, but we did get some 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 38 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 38 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 standards 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 18 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:
1.
3-D
cam
2.
Data
graphing
3.
Test
simulation
4.
Turbine
modeling
5.
Ability
to select AIn, OPC or Dig input.
6.
Gate
and blade servo pressure channels
Leaving
just the
7.
Raw
data measurement and display
8.
Steady
state analysis and display
9.
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, 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 told Ed to give Greg the data. When this data was subsequently analyzed with the ITB, the result was the skewed data shown in fig 37, 38 & 39 (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 cover-up. When compared with
1.The blade positioning accuracy data from USACE’s 2007 blade survey (part 1 & part 2),
2.The information in the October 3, 2005 HOT meeting minutes,
3.The design of the mechanism of the GDACS 3-D cam actuator (shown above) and
4.Dan Perrier’s informative dissertation (detailed above) on the parallelogram spiral motion of the Kaplan blades with the GDACS 3-D cams.
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 37, 38 & 39 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, 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 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 their
own 3-D cam mechanism instead of buying more of Woodward’s 3-D cam product that
has 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 that were installed at Bonneville in 1980, and then bring this device to Woodward for assistance with making it work properly!
The “off the record” comments 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 this happened (Fig 34, An
excerpt from an HDC blade-survey results presentation to the HOT meeting says
65 trip-outs a month at McNary), 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 linear taper’s 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
37, 38 & 39. 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 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 39 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 39 has exactly the same information as Figure 38, 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 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 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 37, 38 & 39 has been prepared and uploaded to ATECo website. To see this movie, click this icon:
http://actuationtestequipment.com/McNary_Skew.wmv
(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.)
Figure_40 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 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 are 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 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 data. The GBO 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 “off-line”
PostProcessing of data captured in the field by the Index Test Box. This video
clip shows how the Index Test Box can analyze the Gate Blade Optimizer data
collected 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)
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 and show that I’ve got 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. The StripChart below and XY Plots of the “McNary skew” in
figures 37, 38 & 39 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 41 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 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 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 runner 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 spot on
the gate. This spot is 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 some cases this force is
greater than the gate servomotor force and the unit cannot be shut down by the
governor. These gate
operator torques are usually measured as part of a turbine model test
to size the wicket gate servomotors and gate linkages.
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 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. 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 42 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 43 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 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, 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 44 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 45 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
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 - 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 about the time frame that the GDACS 3-D Cams were going in at
McNary. Dan was apparently a “first-timer” on this job.
And why would
he call it a "multi-turn" application? And how could
the design end up with string pots? Apparently
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 ACSI had never 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 designs don’t use potentiometers; they use
non-contacting sensors - Resolvers, RVDTs or optical encoders that
never wear out. Potentiometers are known 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 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 – they 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 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. He 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. 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 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
late 1990’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,08,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 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 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. As the story went - HDC and
ACSI were going to gather these technologies, and then build, test and demonstrate
a new Kaplan turbine control system by selecting the best of the best
of these technologies to arrive at the best hydroturbine
control system possible, then all suppliers whose equipment was selected would
then sell their equipment to the Government for the large number of hydroturbine control systems that the Government needed for
FCRPS and elsewhere. Everyone saw through this scam.
They
all 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 to the 113 Kaplans in FCRPS to more favored companies. Those
companies that did enter bids placed legal caveats in the 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
leaving the way open to buy 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, all of 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 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. You 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 46
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 has 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 my 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 when HDC tried to setup ACSI to make a copy of my ITB by diverting the funding at BPA 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” 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 manufacturers. The GDACS 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 51 & 52 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 52) to BPA HOT as their own work-product (fig 51) 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 47 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.
Government Plagiarism
The McNary graph of fig 52 (left) was the final page of my report on the McNary field test, and the Ice Harbor graph of fig 52 (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 not to claim them as HDC personnel’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, purported
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.
Unfortunately, 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 (the Gate Blade Optimizer) to replicate
the successful Index Test Box by Ed Miska, Clay Fouts
and Dennis Erickson at HDC instead of purchasing more of the successfully proof
of concept tested instrument that HDC (Rod Wittinger and Lee Sheldon) purchased
from ATECo, and wanted to buy two more of.
Figure 48 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 solicitations advertised for this 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 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 49 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 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 49 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 50 below is the Power Point slide from BPA that shows these comments.
Figure 50 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. This funding was 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 51, below) to the HOT as the work-product of HDC’s Gate Blade Optimizer (GBO) project.
These two graphs are most certainly copies of the two graphs that I created with my Index Test Box from data it collected at McNary and Ice Harbor Dams, shown below in fig 52.
Indeed, it has been said that, “imitation is the
sincerest form of flattery.”
But I would add, “Plagiarism is a close second.”
Figure 51 Graphs presented to HOT as output of Gate Blade Optimizer (GBO)
Figure 52 December 2005 McNary and February 2006 Ice Harbor graphs created with ITB
HDC was incapable of producing the graphs submitted to BPA to get the funding they wanted, so they just plagiarized the output graphs from my ITB – by falsely misrepresenting them 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 test and February 2005 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 51 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. They failed in this deception.
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 51 & 52 (above) came from, and then the project failed to produce a suitable replica of my ITB because even using LabView, it’s still not a trivial exercise.
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 for what happened 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 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 an excerpt showing the claim of ownership. The “production version” they are speaking of would need to be designed “from scratch.”
Figure 53 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 54) 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 assembly of personnel as an “appropriate in-house/hired contractor team.”
Figure 54 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 always designated the T1 optimizer by HDC) due to enforcement’s investigations into allegations of procurement favoritism towards ACSI.
Figure 55 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 attended 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 - as if they had anything to do with its creation. 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 56 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 find 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 - That mine was the only index-testing contract that HDC had engaged in.
This excerpt shows my specific question and HDC’s response:
Figure 57 Excerpt from FOIA response from HDC, Janice Sorensen and Tim Anderson
After this, in order to stop my FOIA requests HDC’s FOIA people 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 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. I sent a letter regarding this information to Tom Murphy of BPA
and 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 are done.
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_58 Excerpt from HDC Response, a critique of ITB’s ATE-150 signal conditioner.
The ATE-150 was an experimental prototype signal conditioner amplifier intended to normalize (by scale and offset) a pressure transducer output voltage signal to fully utilize the input resolution and span of the A/D converter input to the ITB, and provide the 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 scaling 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 offsets
hard-wired into the amplifier modules with hand-selected resistors to match the
10-turn pot settings to make a permanent signal conditioner for the particular
transducer being used. Ed Miska objected to any such custom hardware,
insisting on all “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 from 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
because so much time had been expended with the 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. I was working for the Government for free.
Ed Miska was HDC’s point man at trying to cheat me with
this illegally altered contract that they were all trying to compel 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 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 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 didn’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 go in under an hour.
Later that day, in 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, 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 the 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 him. 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 59 Excerpt from HOT Response, a redundant ATE-150 complaint.
This is redundant; I’ve already explained this fully at fig 58, above.
Figure 60 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 it to me.
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 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 61 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 62 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 63 Excerpt from Dan’s Ice Harbor email to Rod, reporting setup detail for data collection.
Page 2:
Figure 64 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 65 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 66 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 directive 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 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 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 and then send it 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 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 all would pressure me that the only way to get the perturbation routine done in a timely manner was 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 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 (hereinafter 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.
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, there at HDC. I refused to send it until it was paid for, 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.
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 the 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, it had expired – that’s why Rod called me 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 it.
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 took 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 67 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 yet. 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 68 Excerpt from HDC Response criticizing documentation. This was never a problem.
Goto comments on documentation.
Figure 69 Excerpt from HDC Response. This comment is redundant and false.
Goto comments on documentation.
Figure 70 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 be cheated by Government personnel in this way.
This is blatantly false deflection of the fault of this failure and obfuscation of the facts.
Goto comments on 1st field demonstration.
Figure 71 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 on 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).
Go
to comments on Documentation.
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 main 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 72 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.
Go to comments on Documentation.
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.
Figure 73 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.
Goto Section J, comments on
Software Special License Agreement
Figure 74 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 the
blade perturbation programming for it could be 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 75 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 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 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 made 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 76 Excerpt from HDC Response, This statement is false. Documentation packages were submitted twice.
Click here to go to the discussion on Documentation.
Figure 77 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.”
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 in the contract.
The Government chose not to buy this software source or
the linkable modules, that’s why the Government didn’t get it.
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 78 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 “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_79 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 80 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 server 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 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 81 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 because I needed to establish and make known my rights, complaints and protections. It was 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 property. Dave is a fair and decent guy and a “crisis of conscience” caused him to depart from the USACE Contracting office.
Figure 82 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 there.
- Ryan Sollars (a COE engineer) took some pictures of unit 5 for us while he was at McNary on another job. When Rod saw these pictures, he recognized that that the new GDACS 3-D cam (fig 83, right) had been removed, supplanted by the installation of an obsolete Seawell 3-D cam (fig 83, 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 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 83 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 for a kick-off meeting and a walk-through at McNary Dam from August 23-28, 2004. 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).
- 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 engineering department credit card. I had to but them for weeks before this 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.
- 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 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 complained 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 84 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 keeps anyone from ever buying Rockwell’s RS-Linx for Visual Basic, and they 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 by the RS-Linx service bulletins. These bulletins warned that the new
security protocols in Windows XP prohibited the file structure method that ACSI
had sold me for $1,000. Arguably, as the “expert,” Dan (ACSI) should have read in
these service bulletins about these 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. 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 my invoices to HDC had already 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 so as 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 test it without anyone from 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 wasted the field trip and was in no way 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” 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.”
- 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 85 Excerpt from HDC Response. This comment is repetitive nonsense and fully addressed in the whole of this letter.
Figure 86 Excerpt from HDC Response. Another false claim, the two “without fish screens” field tests failed due to the contract tampering denying anyone from ATECo to participate in the first test, and the second “without fish screens” field test failed due to the mislabeled Winter Kennedy Taps on Unit 5 at McNary.
This statement is absolutely false; there were two attempts to field-test the ITB without fish screens, both of which failed due to USACE problems, one in September and the other in August of 2005. Both of these tests failed due to faults of USACE personnel at McNary and HDC, not due to any problems or shortcoming of ATECo or ITB.
The first field 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.
Goto zero-problem discussion
For the second test, I sent Greg Luna to 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 mislabeling and erroneous blueprints, which is 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 87 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 it was wrong - 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, 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 88 Excerpt from HDC Response. This is another blatantly false statement that is addressed throughout this letter.
Goto discussion on ITB and index testing
Figure 89 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 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 90 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 WASN’T SUPPOSED TO BE.
THE PRE-DEVELOPED SOURCE CODE WAS NOT DELIVERED
BECAUSE THE $750,000 PAYMENT WAS NOT MADE, AS REQUIRED.
Figure 91 Excerpt from HDC Response. This is a completely subjective comment with which I absolutely disagree for all of the reasons cited herein.
Figure 92 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_93 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.
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 that 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 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 94, 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 the ones being complained about; they 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 94 were 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.”
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 94 ITB GDACS Interface showing Unit Under Test and 4 adjacent unit-monitoring panels.
Figure 95 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.