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:

 

 

Table of Contents

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

 

  1. 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?
  2. Did my Index Test Box (ITB) actually work?
  3. Did Government personnel’s overt and covert actions attempt to prevent success of Contract W9127N-04-D-0009?
  4. 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?
  5. 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.
  6. 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?
  7. 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?
  8. Did the second index test attempt fail due to mislabeled Winter Kennedy taps and incorrect powerplant blueprints?
  9. 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?
  10. 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?
  11. 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?
  12. 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?
  13. 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?
    1. 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?
    2. 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?
    3. Is there a 35-second deadtime programmed into the GDACS 3-D cam and blade controllers at McNary?
    4. Do the industry-accepted standards call for 1.0% deadband limits and 0.2 second deadtime?
  14. 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.

 

To get this issue out of the way, up front - I will admit that some minor software bugs did exist in my program, which any computer programmer will say are normal for a first rollout of any new software work. The McNary field test was my first field-experience with this program since 1989, and some software bugs were to be expected.

 

In my defense: the contract included a debugging exercise/demonstration or, an “independent bench test” utilizing the GDACS “MockUp” that was known to exist within HDC when our contract negotiations commenced. After the contract was signed, we found that the MockUp had been removed from HDC by the GDACS Maintenance Team (GMT), taken to HDC’s “captive supplier,” Automated Control Systems Incorporated (ACSI), stashed in the back storeroom there, dismantled, and the parts scattered about the room - rendering it unusable for the “bench test” specified in the contract. As a result, Rod Wittinger and Lee Sheldon waived the bench-test specified in the contract and created a new plan for me to come up with an ITB software program demonstration by some other means. For this purpose, a SoftPLC computer was borrowed from McNary Dam and such demonstration was created and presented to HDC when the ITB was delivered in May of 2005.

 

It is unreasonable for the HDC Response document to criticize me for not executing this demonstration, when it was the covert action of GMT personnel making the MockUp unavailable for the bench test that made it impossible to conduct the bench test as specified in the contract. Neglecting to acknowledge that this original bench-test had been waived and another demonstration created and executed instead is an obfuscation of the facts at hand.

 

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:

 

A REPORT ON THE RESEARCH, DEVELOPMENT AND ‘PROOF OF CONCEPT’ DEMONSTRATION OF A TYPE 1 GENERATION UNIT OPTIMIZING DEVICE.

 

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:

 

INDEX TEST BOX

A REPORT ON THE PROOF OF CONCEPT DEMONSTRATION

 

In preparation for contract negotiations in 2004, Rod Wittinger and Lee Sheldon had verified the existence and availability of the GDACS MockUp prior to starting Contract negotiations. When I came to Portland in August 2004 for a “kickoff” meeting, the MockUp could not be located. When Lee and I visited ACSI to discuss T1 and T2 optimization with Dan Perrier, the MockUp was discovered in the rear storeroom there, disassembled and scattered about the room, rendering it useless for our purposes. Subsequently, Mark Kingstad (HDC civil service employee and official HDC liaison to ACSI) was directed to reassemble the MockUp so we could use it for the “bench-test” specified in the Contract, but Mark was always able to find ways to be “too busy” to complete this task - so it didn’t get done.

 

Without this debugging exercise, the fourth field test of December 2005 at McNary was the first time that I personally connected the ITB to the GDACS.

 

On the other hand - Ed Miska had had ample opportunity to work with the ITB-to-GDACS communication interface before I got my first opportunity. The first time Ed worked with the ITB to GDACS communication was in the HDC GDACS simulation room when the ITB was first delivered to HDC in May 2005; the ITB did not go to a field test immediately because the blade perturbation interface was not completed when it was delivered to HDC. This delivery of an incomplete ITB without blade perturbation was by Ed’s directives (more on this topic later in this letter).

 

Ed worked extensively with the ITB during our cooperative effort to develop the blade perturbation interface (however, during this checkout Ed was primarily looking for weaknesses that he could exploit in the August 2005 field test, as detailed later in this letter, in the “zero problem” discussion), and then checked-out the ITB again before the failed field test in September 2005. A fourth checkout was described by Rod Wittinger’s (USACE senior mechanical engineer) McNary field-test “memo for the record” which stated (on page 1) that ITB had passed additional HDC bench tests on December 5, 2005.

 

(It is noted here that Rod’s report was only “for the record,” and not for general distribution, i.e. why no copy to me?)

 

By every test that HDC (Ed) conducted, the ITB worked just fine and was cleared for connection to GDACS – Ed had signed off on it four-times prior to the McNary field test in December 2005. If the ITB were as awful as indicated in the HDC Response document, then perhaps Ed should explain why none of these problems were uncovered during his May, August, September and December 2005 ITB bench-checkouts – and how is it that now HDC is saying my instrument was so awful?

 

The following is a detailed description of the software “bug” that was the cause of the software problems described in Rod’s “memo for the record.”

 

The “bug” was a single line of code in the programming for the Winter Kennedy pressure transducer. The cause was that I forgot to take the absolute value of the Winter Kennedy (W.K.) pressure signal before taking the square root of the differential pressure. Whenever the pressure indication went negative (caused by closing the high-pressure W.K. pressure tap bleed valve before closing the low-pressure W.K. pressure line bleed valve), the software program tried to take the square root of a negative number. Simply taking care to always close the low-pressure valve first avoided the problem altogether.

 

With computer software, attempting to take the square root of a negative value creates an error that halts, or “crashes” program execution. This issue could have been easily fixed in less than 1-minute had I been able to edit the program source code in the field when the problem was found. Unfortunately this was prohibited by the GDACS security protocol from the GMT. These security measures were excessive and onerous, and arguably were contrived to put greater hurdles in the way to make the task more arduous. In August 2005, the security checkout period was 3-days, which meant that I had to send the software that was committed to go to test at least 3-days prior to the test day. For the December 2005 security test, GMT extended the security checkout period to 5-days. Later, we learned that the security checkout consisted of simply running Norton Anti-virus® on the executable program that I sent to Ed Miska at HDC. GMT had demanded 5-days to run a 5-minute procedure; the security test setup was observed to sit idle for 3-full days before the December 2005 field test.

 

This ‘bug” was never a showstopper - however. After we got the Winter Kennedy transducer calibrated at the beginning of each data run (one in the morning and another in the afternoon), the software ran OK without any further problems. This software bug has been blown all out of proportion in the HDC Response document to justify your personnel’s “marginal” rating of my contract performance, while overlooking the more egregious sub-standard GDACS 3-D cam problems that made the ITB demonstration much more difficult, and prevented us from employing the preferred “Constant Power” testing mode completely.

 

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 Mark Kingstad (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 Mark Kingstad’s plane ticket to Sault Ste Marie? And what role did Rhonda Kingstad’s (wife of Mark Kingstad – an official USACE liaison to ACSI) ACS-Automated Control Systems Incorporated - a company that Rhonda (and Mark) ran out of their home from 1996 until 2005 – play in this?

 

Rhonda and Mark’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 “Kingstad” jumped out at me because Mark Kingstad 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 Mark and Rhonda Kingstad’s home address is the same as the address of ACS-Automated Control Systems Incorporated, and the local college records showed that Rhonda 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 Rhonda’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 Rhonda’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.

 

  1. Constant blade, swept gate
  2. Constant gate, swept blade
  3. 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:

 

  1. Measures forebay, tailwater, gate, blade, flow and power for 200 scans (or any number from 3 to 5000 that the operator selects),
  2. Computes average value and standard deviation of this collected data,
  3. Perform a linear regression on each data parameter to find the slope of a line drawn through each data set,
  4. Determine SteadyState operation by comparing the standard deviation and slope to pre-set limits,
  5. 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.
  6. The outer loop checks to see if there are 3 or more collected data points,
  7. If less than 3, return to the inner loop to measure another point, if more than 3, proceed to the ‘SecondPass’ SteadyState analysis.
  8. 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.
  9. If the data is SteadyState, then the average values of the measured voltages are converted to engineering units and stored.
  10. Gross head is obtained by subtracting tailwater from forebay - presuming forebay is measured behind the trashrack.
  11. 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.
  12. Flow is computed by:
    1. Measuring the differential pressure across the Winter Kennedy taps,
    2. Scaling the transducer output voltage signal to PSID,
    3. Taking the square root (or approximately so, per ASME PTC-18 –2002, pg 64, section 4G) of this differential pressure, then
    4. Multiplying by a constant to get the raw Cubic Feet per Second (CFS) flow value.
    5. 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

  1. Input power is computed as head * flow * mass (cfs * pounds/cubic foot of water)
  2. Generator Power is corrected for head variations by the ASME PTC-18-2002 (pg 70) affinity law:

P @ Hspec = Qtest(Hspec/Htest)1.5

  1. Efficiency is computed as 100 * (output power/input power)
  2. The ITB then catalogs and store the data, and then
  3. 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.

 

2005-09-15 ITB Manuals

2005-11-27 ITB Manuals

 

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:

Edward.P.Miska@nwp01.usace.army.mil

Reply To:

 

To:

DudleyDevices@aol.com

CC:

David.A.Ebner@nwp01.usace.army.mil, Rodney.J.Wittinger@nwp01.usace.army.mil, Lee.Sheldon@us.army.mil, Wayne.A.Todd@nwp01.usace.army.mil

BCC:

 

Sent on:

 

 

 

 

 

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

 

(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.)

 

 

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 systemthey 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

<<06-03 Optimization.ppt>>

 

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.

Goto McNary skew.

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.

 

Goto data sampling methods.

 

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.

Goto Data Analysis

 

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:

 

  1. 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.
  2. 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

  1. 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.
  2. 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).
  3. 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.
  4. 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.
  5. 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.
  6. 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

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

 

  1. 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.
  2. 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.
  3. Adding the automatic Winter Kennedy flushing manifold (not in original contract), taking it out again and then putting it back in wasted more time.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.”
  10. 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.
  11.  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.

 

Goto McNary Skew discussion

 

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.

 

Figure 96 Excerpt from HDC Response. Another blatant falsehood.

ATECo accepts no responsibility for any fault or problems during the first field test. It was a setup and a scam by Ed Miska and Dan Perrier (ACSI) to purloin my copyrighted source code and take over the project using the tampered, modified Contract and the “zero-problem” bad program ruse. The perturbation did work on this test, the reason for failure of the field test was that the Winter Kennedy pressure transducer signal conditioner box had a broken wire, which caused Rod Wittinger to cancel this test, and it was better for me that it did.

 

The ITB blade perturbation routine did work for the second test, but the Winter Kennedy taps were mislabeled and the powerplant blueprints were in error, so the Winter Kennedy piping was deemed to have a leak and the test was canceled. This was no way the fault of ATECo or ITB.

 

The ITB blade perturbation routine did work for the third test at McNary, but the sub-standard GDACS 3-D cam excessive deadband and deadtime precluded any Constant Power unattended index testing.

 

The ITB blade perturbation routine was functional in the ITB field test at Ice Harbor, but GMT did not install the GDACS perturbation routines in the 3-D cams so there was no perturbation by the ITB.

 

None of these issues are the fault of ATECo or ITB.

 

Figure 97 Excerpt from HDC Response. This is an inaccurate and misleading statement.

This statement is absolutely false. The ITB is designed to perform the Constant Power automatic index testing procedure. Due to the sub-standard governor dynamics of USACE’s McNary governor and GDACS 3-D cam, the ITB was prevented from running the proven, effective, preferred Constant Power testing method that it can definitely run unattended, as shown at Clarence Cannon in 1985 and again at PGE-PHP-2 in 1987.

 

Figure 98 Excerpt from HDC Response document.

This COE comment is deflection of blame - the reason the ITB could not run an Index Test as required was due to the sub-standard GDACS 3-D cam’s excessive deadband and deadtime.

 

Figure 99 Excerpt from HDC response. This is another unreasonable and false statement.

I did the best I could despite the obstacles put in my way by HDC.

 

Figure 100 HDC always had the source code for the adjacent unit monitoring software routines, and it is beneficial to monitor the operating levels of the adjacent units to know the true energy in the water as it enters the unit under test.

Figure 101 HDC Response. This is an inaccurate and misleading statement that incorrectly interprets the Section J. Optimizer Special License Agreement.

The Co-Developed code was given to the Government every time it was required. When originally created, in preparation for every field test, at project completion and whenever requested.

 

Figure 102 Excerpt from HDC Response. Finally – a completely true statement!

 Refer to the exchange with Dave Ebner that resulted in his Stop Work order and every other comment in this ATECo response.

 

My COR (Dave Ebner) saw that there were problems being intentionally created by HDC personnel, so he put a Stop Work order on the project so he could fix them. With the heightened clout Dave got from having a project in Stop Work status, he was able to press people to find out what was going on. Dave’s corrective action was to remove Clay Fouts as the HDC liaison to ACSI because he found that Clay was doing things overtly and covertly to protect the business prospects of ACSI to the detriment of my project.

 

When it started looking like the ITB was going to be successful, Ed Miska was afforded the opportunity to secretly add text into my contract that would have harmed my company, and his actions were fostered, endorsed and protected by Ralph Banse Fay by forbidding Dave Ebner from removing the objectionable text that Ed had secreted into the boilerplate of my Contract - for 2-½ months.

 

During the 2 ½ months that I refused to sign the Contract because of Ed’s unlawful alterations and tampering, Ed invited Dan Perrier, President of ACSI into HDC to help figure a way to sabotage my equipment in a technical, complicated computer-technology based ruse referred to herein as the “zero-problem” which is discussed in full technical detail in the discussion of the First Field test (above).

 

Lunch_Date

But here’s the rest of the story…

 

While I was in Portland for the kick-off meeting with Dave Ebner, Rod Wittinger, Lee Sheldon, Calvin Hshie and myself, I made a presentation to the meeting that showed the sequence of events that would get the ITB interface developed, installed and the ITB Proof of Concept test completed.

 

Dave Ebner commented that, “You sure make it look easy” after my whiteboard presentation.

 

After the meeting, everyone left the room except for Rod and me. I asked him, “you look skeptical; don’t you think I can do this?” Rod quipped, “I have no doubt you can do what you say, but I don’t know if ‘they’ will let you do it.” I asked whom, “they” are. Rod wouldn’t answer me, except to say, let’s go get some lunch.

 

Over lunch, Rod said that I was walking into a treacherous and difficult situation. ACSI was a problem; they had completed their workscope with the GDACS SCADA system and 3-D cams, and needed some new work to do. He told me I should stay away from ACSI because they’ll be trying to figure a way to take my ITB project away from me - the $3,500,000 in my Contract’s budget made it very attractive. He suggested a scenario where I’d get a “bum’s rush” and continual hustle, always kept off balance by diversions, distractions and getting my workscope’s targets moved by an as-of-yet unnamed HDC contact until - when we got to the field test, there’d be contrived problem of some sort with my equipment, and as a result I would be made to look incompetent - and then Dan Perrier and ACSI would swoop in, “save the day” and walk away with my contract, and the money.

 

Looking back, Rod was exactly right with his prediction; the way Ed kept me off balance by misdirects, wild-goose chases, moving the target, and more specifically, once we got into it - delaying the task order to get the GDACS blade perturbation software routines from ACSI in order to get the uncompleted ITB into HDC - with designing and testing of the blade perturbation routines yet to do, specifying repeated changes to this software that made many new revisions of the executable necessary - until Ed and Dan (ACSI) got a version of the program they could use to create a contrived problem - which they found with the “zero-problem” version; (ITBRev1.br16.exe)

 

When they went to McNary on the first field test (Rod, Lee, Ed and Dan (ACSI)), no representative from my company was allowed to go along because I was refusing to sign the contract that Ed had been allowed to change to my detriment, in secret. Rod & Lee were not “computer savvy” enough to see the sleight-of-hand as Ed and Dan (ACSI) shut off the proper ITB program and then started the “bad program” with the zero problem to show that they couldn’t do any testing as long as the ITB kept sending random zeros to the SoftPLC - and then Dan (ACSI) would whip-out his “zero snatcher” routine, and install it in the SoftPLC. After this software “patch” of Dan’s (ACSI) had fixed the zero-problem, the testing could go forward with Dan (ACSI) as the hero - and then my company, my product and me would be discredited, and Dan (ACSI) could walk away with my contract and the money.

 

A brilliant plan; except for the “wily” ATE-150. A broken wire in this signal conditioner box prevented any Winter Kennedy flow measurement, so the first field trip’s index testing was a failure. When we spoke of it later, I explained to Rod that the ATE-150 was a prototype, and prototypes are “humble and don’t travel well.” Rod laughed out loud at that explanation - and the next time we spoke; Ed was gone, Rod was back in charge again, Lee was my HDC contact again, $20,000 was added to the contract and the objectionable text was removed from paragraph 3.4.2.9, and paragraph 3.4.2.9a was removed entirely; a happy ending.  

 

                        Return to Code Changes

 

 

 

III. Comments on HDC Response References

 

Figure_103 Excerpt from HDC Response. This is a vague and inaccurate representation of the meaning and intent of the Section J provisions.

The real problem here all boils down to the Government wanting to get “something for nothing.”

 

Government violation of Section J Provisions

Yes indeed, I was made aware of the Government requirements for source code and security.

 

At the same time, the Government was made aware of my requirement to get paid for my work.

 

The pre-developed Copyrighted software source code had been written prior to the Government approaching me with a solicitation for a sole-source Contract for an Index Test Box. The Government made many overt and covert attempts to get the pre-developed Copyrighted source code away from me without paying for it, in flagrant violation of Section J of the Contract.

 

An agreement for transfer of ownership of the pre-developed Copyrighted source code to the Government was arrived at during contract negotiations (Dave Ebner coordinated negotiations with Rod Wittinger, Lee Sheldon and others in HDC) which priced the Copyrighted source code at $750,000, with a restriction that the Government could only use this software within the Columbia River Basin Federal Columbia River Power System (FCRPS).

 

Once I got this agreement in writing, I wasn’t going to be niggled out of it.

 

HDC personnel violated this agreement many times by attempts to acquire the pre-developed Copyrighted source code without paying for it; a prime example of this behavior is the deceptive and foolish tampering with the contract modification at the end of the performance period when Ed Miska was allowed to secretly sneak extra wording into the boiler plate of the Contract that would have altered our agreement – as if I would be stupid enough to sign a Government contract without first reading every word!

 

Purpose of Pre-Developed Code Modules

The nature of Visual Basic software programming (or any computer programming) is to separate the program’s functional logic into modules (Visual Basic uses forms, or windows), each comprised of both Graphic User Interface (GIU) features and text-based code.

 

Although methods exist to compile these functional blocks into Dynamic Linking Library (DLL) format to distribute them separately, this form of program distribution is not without it’s own pitfalls. This is the programming distribution method being discussed in Fig 103.

 

The modularity discussed in Fig 103 delineates the partitioning that I used in writing the program for the Index Test Box, i.e.:

“SteadyState” procedure

“Parse and Graph procedure

“Autocal” procedure, and

“Registration and Security” procedure

 

This was the logical structure of the Copyrighted source code when I entered negotiations with the government. The software was not going to be sold in this format - these were just the logical partitions used for software program development to enhance understandability of how the program works.

 

It was never my intent to market these modules separately. The purpose of listing these modules in this way was to explain the structure of the logic of the program to help the Government understand how the ITB program works. My intent was always to compile and sell the program only as a single executable “.exe” format program, hence the pricing structure in the Contract’s Line Item 3, “LI0003” pricing and discount structure.

 

In deference to the comment in fig 103, these modules were never paid for, so they were not delivered, but this was not an intended form for the Index Test Box technology. Had I really wanted to sell these modules separately, there would have been separate pricing for them delineated in the Contract.

 

There was not a price for any DLL programming, and the Government never bought any. The contract only described this method as a possibility, not as a deliverable. Without a price it really never existed.

 

The pre-developed code is easily compiled into one, comprehensive executable program. All of the software deployments I’ve made to date (20+ years) have used this technique. I am very comfortable selling the ITB software in this form and this was how I contracted to sell it to the Government.

 

Under pressure from the Government (despite my better judgment) I agreed to consider marketing these modules individually, but not in such a way as would violate the provisions of LI0003, i.e. without getting paid for each and every one of them. My purpose in developing the ITB was, after all, to make money. Whatever form or fashion these modules would be sold in, the cost to the government would be in accordance with the price schedule of LI0003, which was based on the $750,000 price established in Contract negotiations.

 

In any event, every module of code that was delivered to the government would have been protect by the “non reverse compliable” nature of Visual Basic and the hard-coding into each module of the serial numbers of the computer, hard drive and I/O board of the Index Test Box platform it would be going into. Each and every software module would be keyed to a single computer box, all in accordance with the Contract’s provision in Line Item 0003, the price schedule that was ultimately based on a total value of $750,000 for the Copyrighted source code.

 

Unauthorized redistribution such as the Government wanted to do is Software Piracy, and is illegal.

 

A prime example of the continual niggling behavior of HDC is the “big deal” being made now over these individual modules. Note that the pricing structure calls for only the entire executable programs; no mention is made of individual code modules in any pricing schedule.

 

After some research into the Dynamic Linking Library (DLL) option, it was quickly learned that there would be significant “learning curve” and code testing required with creating and validating these individual modules in DLL format before they would be individually usable and sufficiently reliable and robust. Unfortunately, the Government didn’t want to pay for this development effort, and there wasn’t time to unbundled these modules from the Copyrighted source code and comprehensive “.exe” file, so this work did not get done; mainly because the Government didn’t want to pay for it.

 

Contrary to the Government’s claim, even if I had made the DLL’s as described, the Government would not have been able to redistribute them freely. The Registration and Security module would have been linked to each of the other three modules to prohibit widespread distribution in violation of the provisions of LI0003, which is what the Government was seeking and is complaining about now. The Government was never to get the benefit of the pre-developed Copyrighted source code until it was purchased at the full price of $750,000.

 

I had been working on this software since 1984; for Woodward until 1989, then on my own from 1992 to the present after Woodward shelved it and the Patent expired. I quit my job at Woodward to continue working on the ITB in 1992, on and off, as time allowed – and then almost continually after 2002.

 

I have hundreds of hour in this programming effort and was not prepared to give it all away without getting paid for the work that had gone into it. When the Government contacted me in 2003, the program was admittedly still under development - but had the functional SteadyState, data manipulation and display graphing routines working, and the rest of it was fully functional but not completed into a marketable form - hence the low, low price of only $750,000, instead of a much larger figure. Refer to the “Screen Gallery” included with the introductory sales package that was sent to HDC in 2004 to document the state of development attained prior to the initiation of contract negotiation and signing.

 

Buying-in at such a late-date in the development cycle of my instrument did not entitle the Government to full rights to the entire work. Price for the rights to a usable version of the pre-developed Copyrighted source code (as it was in 2004) with geographic restrictions to within FCRPS, was set at $750,000 in negotiations with Dave Ebner for the original Contract. To further illustrate this number the price of $2,300 each for 320 copies of the executable was based on $2,300 * 320 =$736,000; the difference from there up to $750,000 was written off to incidentals, travel and enough computer hardware to make just one ITB.

 

Looking back, the Government actually had a real bargain on their hands, but HDC’s perpetual attempts to take the Copyrighted source code away from me without paying for it instead of working with me - lost the Government a great opportunity. The discounted price for 320 units would have actually been $500,480; but they would probably only have purchased one or two per powerhouse at a much lower total cost - either way the Government would have gotten my full support in perpetuity to get this equipment up and keep it running.

 

I quit Woodward governor in 1992 to start the Actuation Test Equipment Company in order work on this project, with the fall-back plan of designing and building aircraft test equipment as a “bread and butter” line and work on the Index Test Box on the Back burner. Outright threats of litigation for patent infringement were made by Woodward until their Hydro group disbanded, and after that GE Global Systems continued to threaten lawsuits if I brought the ITB to market. After the patent expired (but before I got my marketing efforts off the ground) HDC contacted me in 2003 with overtures of a sole-source Contract. The negotiations took over a year and a half because the Government continually put “grabbers” in the Contract and boilerplate that would transfer ownership of the body of the pre-developed source code to the Government as part of the deal. I struggled to keep the main body of the source code that I had been developing since I left Woodward as personal intellectual property.

 

Contract Negotiations Interrupted

It should also be noted that a 7-month hiatus occurred in the contract negotiation due to a false claim made by another company. At a point where I was close to terms with my first COR, George Williams, the American Governor Company (“AGCo,” the outfit who is currently contracted to provide your new governors on a $10.6 Million contract) made a false claim to HDC (Roger Clark Johnson to HDC’s Courtney) that AGCo’s engineers invented (and, “even came up with the name” for) the Index Test Box in 1985 at Woodward - instead of George Mittendorf and me. Contract negotiations were immediately halted, and were not resumed until 7 months later - after Rod Wittinger got reinvolved. Rod looked at AGCo’s website, and saw that they made no mention of index testing thereupon. Rod reasoned that if AGCo had been involved in the Index Test Box project in 1985, they would have at least mentioned it on their website.

 

Software Security

At the beginning of our negotiations, the ITB wasn’t completely ready, but too far along to be scooped-up by the Government as part of this Contract to purchase only one instrument.

 

The intellectual property in the software is protected in two ways.

 

First, one of the key benefits of Visual Basic 6 (VB6) programming language is that it is impossible to reverse compile executable modules created in VB6.

 

(Computer executable modules programmed in C, C++, Java and most other high-level programming languages can be reverse-compiled to get access to workable source code, leaving the purveyor more vulnerable to software piracy.)

 

Second, each executable code module is hard-coded with the serial numbers of the CPU, hard drive and I/O board that are in the Index Test Box PC that the software goes into. The software won’t run in any computer other than the one that they are keyed into.

 

The Government was never supposed to receive any usable, copyable, redistributable software; modules, copyrighted or otherwise without paying for each of them separately, as delineated in the price list of LI0003, Software Discount Schedule on page 4 of the original contract, or until the body of the program was purchased - if this were not the case, why was Line Item LI0003 in the contract? Ed Miska repeatedly tried to transfer the ITB executable, which he had copied out of the Index Test Box computer that was delivered to HDC, to run in another, different computer. I am glad that he was unable to defeat the ITB software security.

 

The purchase price of $160,000 in the contract only provided for one instance of the IBT software program, which is contained as a complete executable “.exe” software module in the Index Test Box that was delivered in a functional condition to HDC.

 

The Government got everything that was paid for.

 

Restating: additional workable units of the program were never supposed to be replicable and freely distributable by the Government, until after the $750,000 Copyrighted source code was purchased.

 

Additional copies of the program could be purchased individually, as identified in the contract by Line Item LI0003, with pricing discount schedules as indicated. If the Government were able to copy and distribute the program freely - it would defeat the terms of the contract, so this point is moot.

 

The LI003 pricing would remain in effect if and/or until the source code was purchased for the agreed-upon price of $750,000.

 

When we got to the end of the 1-year performance period of the contract, an optional method of distributing segments of the program as “.dll” modules that the Government could link into other programs was discussed and written into the modified contract, but funding to do this work was not forthcoming and the Government never bought any of these “.dll” modules. The specific work to parse out the identified functional modules and test them extensively enough to release them as individual modules was not possible due to time and funding running out.

 

Here’s the rub - the Government was afforded the opportunity to “buy me out” after they saw that the program worked as advertised. Ed Miska’s stated position in a pre-emptive meeting in August 2004 was that after the Government saw how the ITB worked, HDC could simply have ACSI reproduce its functionality, so there was no need to purchase the software outright. It was always the intent of GMT to get my product without paying for it.

 

As TV’s Dr. Phil would ask – “How’d that work out for ya?”

 

Figure 104 HDC Response Document. A misleading and disingenuous claim that the Government didn’t get what they paid for.

This paragraph is misleading. The individual modules were never going to be separately protected by Copyright nor marketed individually - or more importantly, received by the Government - until after they were paid for. The Government didn’t pay for them, so the Government didn’t get them. The primary purpose of the software Copyright was to document that the work to create the main body of the source code pre-dated signing of the Government contract, thus the main body of the software was created at personal expense and could not be claimed by the Government as the product of this Contract’s funding.

 

It was feared that claims would be made at the end of the Contract interval that the entire software program was written at government expense during the contract interval and it would be seized by the Government, so the Copyright was acquired to prove otherwise. As it turned out, such a claim was made by the Government, at which time the Copyright was delivered to the COR to prove the source code predated the contract interval and therefore was created at private expense.

 

The demonstration was not possible because GMT had removed the MockUp that we were to use for that demonstration from HDC in order to make it unavailable to us, stashed it away in the back storeroom at ACSI, and then dismantled it to render it unusable for this demonstration. And now they’re complaining about it? Incredible.

 

Rod Wittinger and Lee Sheldon waived this “bench-test” requirement because the MockUp, which was the intended “bench to test on” for this demonstration, was missing when we needed it. When I was in Portland in August 2004, on a trip to ACSI to discuss details of Lee Sheldon’s Type 2 (T2) optimizer functionality and coordinate the data collection and perturbation interface with Dan Perrier, the MockUp was found in the back storeroom at ACSI, dismantled and scattered about the room, rendered unusable for this demonstration.

 

As a result of the MockUp being made unavailable, a new requirement was placed on ATECo to devise a different means to demonstrate the ITB software functionality. To facilitate this, we wanted to borrow a SoftPLC computer from HDC, but were told that none were available; later it was learned that this was a falsehood. When Greg Luna delivered the ITB to HDC for me, he found that there were 14 SoftPLC computers in a GDACS simulation room configured as an entire GDACS network system; he was told that one could have been had for the asking.

 

Another purpose of our trip to ACSI was to borrow a SoftPLC from them. When we got there, it could be seen that ACSI was for the most part, destitute and closing down. Many empty workbenches and desks, and no spare equipment lying around. It was said that HDC had retrieved all of the computer equipment from ACSI and they were being pressed for documentation on the GDACS and would be shutting down shortly.

 

I spoke on the phone to a retired USAF employee at ACSI before going to Portland in August. My USAF background (and that we had been to the same duty stations) provided common ground for our conversation. He suggested I speak to Roger Hays at McNary, who provided a frank and open description of what it was like to work for USACE, and what kind of abuses and chicanery I could expect, and some insights for how accomplish my stated goals.

 

While I was at McNary, Leroy Richardson was telling me that there were no SoftPLC’s to borrow, but Bob chided him that this was a disingenuous statement, went into a storage area and came back with a SoftPLC computer. He said that it was slated for an expansion of the fish ladder system and would not be needed for months, (if ever). Bob could not provide the software for it; however - we’d have to get that somewhere else.

 

Rod Wittinger and Lee Sheldon carefully coordinated the timing and scheduling of my first trip to Portland. We needed to have a “kick-off” meeting with key players from several areas to assure success with our project. Weeks before, and the very week before my trip to Portland, Lee contacted Clay Fouts (whom Lee trusted because they’d worked together for over 30 years), Joe Fisk and Steve Atkinsen, who all assured Lee that they would be available to attend our kick-off meeting on Monday when I arrived in Portland. When we started our meeting, all three of these men were absent. Lee checked with their duty sections and found that all three of these men were on vacation for the entire week and could not be reached. When Lee asked about alternates, he found that all subordinates had been instructed not to communicate with any non-USACE people (meaning me), ostensibly in hopes that this would thwart the purpose of our meeting.

 

Our meeting was canceled, Dave, Rod and Lee had a private conference, and I was left to my own devices for a while. In search of some information, I went to Steve Atkinsen’s desk, sat in his chair, and waited for someone to come along and question my presence there. Calvin Hshie came by and asked me what I was doing there. Calvin apparently didn’t get the word that I was to be avoided. After a brief conversation, I quickly learned that Calvin had the knowledge and expertise we needed; he was personally working in the powerplants with the GDACS 3-D cams by loading the 3-D cam executable program and cam data tables into the SoftPLCs associated with each turbine, and had copies of the GDACS 3-D cam program and cam tables for McNary that we needed – and was willing to share.

 

I found Lee, told him about Calvin, and our meeting was reconvened.

 

Figure 105 Excerpt from HDC Response, pointing out changes in the software over the course of the project.

This is essentially a true statement. Yes, some changes to the software were made necessary due to COE directed configuration changes to the ITB. These changes were made at the direction of Rod Wittinger, Lee Sheldon and Ed Miska; the changes were all in the “Co-Developed” code. The added code modules were necessitated by the changes from discreet sensors and an analog I/O board for all measured signals to using digital communication to the 3-D cam’s data stream and the change from RS-232 to the OPC communication method. The 4 original software modules (or partitioning) were used to construct and define the functional logic of the software that was copyrighted at the beginning of the project. Additional software created for the OPC interface to the SoftPLC computer, the blade perturbation and the four modules for displaying the adjacent machines (two on each side of the unit under test) were added. Copies of this Co-Developed code were given to HDC upon creation (or purchase from ACSI), during preparation for each field test, at the conclusion of the workscope and every time it was requested.

 

Your Ed Miska, at the recommendation of Dan Perrier of ACSI, mandated the greatest change on this “time and material contract.” This change was that the communication method for the ITB was changed from my original concept for communication with the GDACS control systems using the FREE, readily available RS-232 communication ports that were already on all of the GDACS SoftPLC computers, using the FREE Comm Genie communication software that was available from SoftPLC to the more expensive and unfamiliar OPC method.  The RS-232 method was suggested by SoftPLC’s technical support so it most certainly would have worked.

 

Dan Perrier suggested, and Ed Miska directed that I not use the RS-232 ports for this communication; instead they wanted me to use OPC communication programming method with which I was unfamiliar at that time. This COE directed change was not in the contract requirements so they were just pushed in after the contract was signed. There was no added budget for this time and expense, so something else that was planned in had to get removed; as usual, the documentation was the first thing to suffer.

 

(Cost for OPC programming software from Rockwell that was specified by Dan and Ed was $3,500 for the programming tool, then $950 each for every communication interface; two were required. I had to purchase the OPC Communication setup and “tagname” information from ACSI for another $1,000. These were not budgeted in the contract, but I was forced to buy them anyway. Figuring out that the Rockwell OPC interface wouldn’t work in Visual Basic 6 and Windows XP, and then arguing with Ed about switching away from Rockwell took several weeks. And then switching to Software Toolbox cost another $1,800 and had an associated learning curve and programming time to use this tool. All of this OPC communication work took about 4 months to struggle through, none of which was in the project budget or plan. )

 

In order to add this COE specified OPC communication capability to the Index Test Box programming (while preserving the integrity of the copyrighted Index Test Box core programming) required creating a few new modules. The code for these newly added modules was written at Government expense, and all of the source code for it was given to HDC when it was completed. Due to these COE mandated changes, the module listings do not agree.

 

The situation was that I planned and negotiated a workscope and a time and material Contract, with terms that were Dave Ebner and my best estimates of how the project would go. When Ed Miska came on board as the Technical Lead, he radically changed the direction of the project several times, so naturally the work that got done did not agree with Dave’s and my original estimates and plans, and it took more time and money to chase the constantly moving targets.

 

Figure 106 Excerpt from HDC Response; more falsehoods and misdirection.

This paragraph leads with a false statement. I was not ignoring the Section J bilateral agreement; I was constantly disagreeing with Ed Miska’s interpretation and misapplication of Section J. Dave Ebner arbitrated every disagreement, usually with a slight bias toward the Government (in my opinion), but Dave was always fair.

 

A broad - brush overview of the bilateral agreement was that what I brought to the table was mine until the Government bought it, and what I developed at government expense would be shared with the government. Isolating the pre-existing code from the newly created, Co-Developed OPC communication programming necessitated by HDC’s ITB configuration changes required a few new modules. ATECo meticulously adhered to the bilateral agreement, because it was also intended to protect my intellectual property from the Government.

 

Counsel advised that had I stayed with the exact module structure that existed at the beginning of the project, the modifications at Government expense to change the ITB configuration (changing to digital communication from discreet sensors and the switch to OPC communication) would have been made to the original source code. A clause in the contract boilerplate stated that if the Government paid for any changes to any part of the original Copyrighted source code, the entire Copyrighted source code would become Government property. To prevent this, additional modules were required to be created to contain the new code and program logic for the COE directed changes and additions to the ITB functionality and configuration.

 

Figure_107 An excerpt from HDC Response.  Reference to the four monitors for adjacent units.

Perhaps I got a little too snippy here, but Ed was really frustrating to work with, I do not apologize for this outburst - but allow me to explain myself more fully below.

 

Please recall that the Government engaged me as the Index Test Box expert. My task was to educate the Government how the Index Test Box worked, how the Constant Power testing method works, and what operational concerns of the powerplant would impact the testing results from the Index Test Box. When I realized that some in the Corps saw the ITB and me as a threat to the status quo, I played down my abilities and knowledge to disarm them. It worked - perhaps too well. Ed underestimated me to the point where he thought I wouldn’t read every single word of a Government contract before signing it! And, nobody guessed that I’d have any form of protection on my intellectual property after they learned that the patent had expired. It’s good to be underestimated.

 

Explanation of why Monitoring Adjacent Units and Velocity Head is a Good Idea

It is well known that changing the operating levels of the adjacent units during data collection will disrupt the index test results with noise, but it is lesser understood that the velocity of the water as it approaches the dam also affects the index testing results; even if the adjacent units’ operating levels are held steady during the index test’s measurement intervals. Changes made to operating levels of adjacent machines will affect the kinetic energy in the water approaching the unit and be undetectable by normal powerhouse instrumentation.

 

The energy involved in this “velocity effect” has a magnitude proportional to the square of flow velocity. The conventional thinking of the PTC-18 energy calculations assume that all of the kinetic energy of the water is the result of the grosshead, so the velocity at the intake causes a depression in the water at the inlet. This method ignores the velocity of the water as it approaches the dam.

 

Think of it as the difference between drinking from a bowl - and drinking from a fire hose.

 

A “rule of thumb” benchmark for this - when the velocity of the water in the forebay is approaching at 8.4 feet per second, the inertia in the water is equivalent to 1.0-foot of grosshead. In a unit operating at 75 foot head, this has a roughly 1.3% effect on total efficiency in the water entering the unit. This kinetic energy is unmeasured because it is undetectable by the typical forebay & tailwater head measurement system in most powerplants comprised of floats or static pressure transducers. Water level sensing measurement methods cannot see the momentum (energy) that is already in the water as it approaches the dam. This is why an index test should be recording the operating levels of the adjacent units (four turbines in this case), so that the aggregate flow approaching the dam directly in front of the unit under test can be known. The Index Test Box is the first index-testing tool to make notice of this phenomenon. If I could have measured all 14 turbines at McNary it would have been even better.

 

This is one of the concepts that I wanted the “grasshopper” to learn about. The main problem I had with Ed is he was always trying to “snatch the pebble from my hand” before I opened my palm. Overall, Government personnel seem to believe that because they work for the Government that they are smarter than those of us in the private sector; “it ain’t necessarily so.” It was hoped that when Corps personnel more knowledgeable of index testing and at least vaguely familiar with basic concepts from first-semester physics realized what this feature was for - it would be accepted.

 

I am currently working with the governor manufacturer for the Canadian power company’s equipment to enhance their governor 3-D cam algorithm to measure and accommodate this velocity head. This new algorithm works on the sum of the energies in the water (gross head - trashrack + velocity head) and gate angle. Perhaps I’ve tipped my hand too much here by giving away a trade secret of our new development project, but it is important that the reason for wanting to record the four adjacent units to the unit under test be explained herein so you can appreciate my purpose.

 

The problems I had with Ed was that for some unknown reason, he was always HDC’s “point man.” Ed had no familiarity, knowledge or expertise at index testing turbines, and I found him to be unethical and deceptive in our dealings. His presence was always a hindrance and detriment to progress, yet Dick Nelson kept putting Ed in charge.

 

I must agree that there were some ragged edges to the Index Test Box when we started; it was (and is still) a work in progress when I engaged to sell one to the Government with this contract. However, this should have been a surprise to no one; the Government always knew this.  Note this phrase in the Contract’s Section J:

 

Figure 108 Excerpt from Contract Section J, Optimizer Special License Agreement.

I would have been ready to go to market with the ITB in 2-5 years at the pace I was going. Significant energy must always be spent “keeping a roof over my head,” and the ITB was still a “back-burner project” that only got worked on as time allowed. The Government’s purposes with this contract were to “accelerate development, gain configuration control,” and get an item to test as quickly as possible. My purpose was to retain what I had achieved already and move it forward.

 

Selling an ITB to the Government allowed me to focus more of my energies on the ITB project, and the Government was allowed to dictate some changes to the data collection method by switching from the discreet sensors method I was using to the “integrated data collection” method that Rod Wittinger and Lee Sheldon specified.

 

Rod and Lee would have been happy with using the RS-232 method to achieve this, but when Ed Miska took over, he insisted on switching to the OPC communication method; that’s when the real trouble started.

 

In retrospect, the purpose of this project was purported to facilitate my completion of the ITB so the Government could buy them from me, but soon into the workscope after Ed took over - it became painfully obvious that the true objective of the Government was to take the intellectual property of the Copyrighted source code and underlying technology away from me so it could be given to ACSI, so that company could mass produce and sell ITB’s to the Government; all without paying me the acknowledged, agreed-upon price for the Copyrighted source code or acknowledging where it came from.

 

Figure 109 Excerpt from HDC Response; a misleading and inaccurate interpretation of Section J and security issues.

This paragraph is misleading and inaccurate. There was no “co-mingling” of the software. The software was meticulously segregated to preserve the integrity of the pre-developed Copyrighted source code. Additional modules of code were added by necessity because the pre-developed, copyrighted source code did not have the OPC communication capability that COE wanted.

 

I was advised by counsel that if I made modifications to the copyrighted, pre-developed source code at Government expense, that the Government could then seize the entirety of it. To avoid this eventuality, it became necessary to create additional code modules as containers for this new code that HDC was mandating in order to segregate the Government-funded code development from the Copyrighted, pre-developed code.

 

I never saw any cure letter, so I cannot comment on it. Dave Ebner told me of it, but when I have him a copy of the Copyright, the cure letter was never mentioned again.

 

The FOIA request for GDACS 3-D cam code was wanted for two reasons.

 

1.) I wanted to figure out why the Governments 3-D cam at McNary required a 1.0-degree deadband and 35-second deadtime. These two factors rendered the Government’s 3-D cam sub-standard when evaluated by the ASME & IEEE PTC 29, Std-125 and Std-1207 standards, and made them unsuitable for index testing with the ITB’s preferred Constant Power method.  

 

I believe that as an absolute rule - it is incumbent upon the Corps of Engineers to meet or exceed the accepted industry standards for turbine control system equipment per the Endangered Species Act, particularly so because Corps of Engineers personnel have participated in these Standards Committees for many years.

 

If HDC insists on designing and building their own control systems, then the resulting systems must at least be in compliance with nominal industry-accepted standards that COE personnel helped to create. 

 

2.) There was an inexplicable problem with the OPC communication system, designated the “zero-problem” that is described at length in, “What it was like to work for USACE” and above at Blade Perturbation and zero problem. The GDACS 3-D cam code and zero-snatcher code I was requesting under FOIA would have helped to expose how this ruse worked and document the deceptive actions by Ed Miska and Dan Perrier (ACSI).

 

The denial of this technical information for the GDACS 3-D cam (I learned earlier this year that GDACS was offered for sale by ACSI to Brookfield Power in 1998, which belies the national security argument) places the problems I experienced with unethical conduct by HDC on an organization scale.

 

Figure 110 Excerpt from HDC Response; an incorrect and uneducated complaint.

This is redundant and false.

 

The code to allow the ITB to record the operating levels of the adjacent machines is necessary to properly index test a unit, and there never was any “co-mingled” code. The added code modules were made necessary by COE’s mandate of changing from RS-232 to OPC-communication, and they were always kept separate from the Copyrighted source code for the ITB.

 

The field testing was satisfactory to show that the ITB is “ready for unattended testing’ per your turbine testing supervisor, Dan Ramirez, and it worked well enough that Rod, Dan and Lee petitioned the DOE HOT committee for funds to buy two more to continue field testing. They got over-ruled by Dick Nelson and GMT.

 

To the contrary - the GDACS Maintenance team saw a threat to their status quo, and Dick Nelson’s clout and Ed Miska’s shenanigans were used to thwart our successful project in favor of starting anew with ACSI making a replica of my instrument. Through complaints to DOD IG and DOE IG, this was curtailed, but could not be stopped entirely.

 

Additional communications to DOD IG that exposed the “shell company” that Mark Kingstad and his wife ran out of their house instigated a wider DOD IG investigation, which led to the GDACS blade accuracy survey that exposed the awful blade angle sensors and other blade controlling software problems at McNary and elsewhere. A specific indicator of the problems was the approximately 65 faults per month at McNary. Additional money from BPA was spent to fix these problems.

 

HDC personnel changed their project name from ITB to GBO in order to get it “off the IG’s radar.” Additional investigation and resulting information to IGs and BPA management exposed these deceptive practices by HDC personnel, and then the HOT meetings stopped happening altogether.

 

HDC makes a practice of pirating technology from the private sector and making shoddy, substandard copies of it, and then setting friends and civil service employees up in “captive suppliers” and “shell companies” to defraud the taxpayers.

 

Collateral damage from this substandard equipment (to my knowledge dating back to the first Seawell 3-D cam, and perhaps further back) has caused ever-increasing deterioration of the turbine blade control equipment and resultant turbine trunion bearings (and welding of Kaplan runner blades to a fixed angle) to the detriment of fish populations that must pass through these turbines on their way back down river.

 

In my opinion, the onus for the declining populations and extinction of fish species can be directly traced to the greed and procurement favoritism that Government personnel are inclined to practice. It’s all just shameful.

 

IV. Comments on Reference Documentation

Figure 111 Excerpt from HDC Response, misrepresenting purpose of Copyright and four separate modules used to organize code.

For #1, #2 & #3, no comment necessary.

 

This is a repeating theme in the HDC Response, which entirely misstates the purpose of the Copyright and code modules.

 

Figure 112 Excerpt from HDC Response, a misrepresentation of the purpose of the Section J agreement, Copyright and code modules,

This is a repeating theme in the HDC Response, which misstates the purpose of the Copyright and code modules.

 

Figure 113 Excerpt from HDC Response; a reference to Dave Ebner's not about my frustration with the unethical behavior of HDC personnel.

I don’t have this hand written note so I cannot comment on it directly.

 

However, from the date, I can comment on the situation in the project at that time. Ed Miska had taken over as “Technical Lead” for the project, and unilaterally directed difficult and expensive changes to the workscope, moved performance milestones and provided inaccurate information and instructions that consumed time and material on “wild goose chases.”

 

Ed delayed getting the task-order to ACSI so they could make their part of the perturbation communication interface until after I sent the ITB to HDC Portland. When the ITB was at HDC, Ed invited Dan Perrier in to help him concoct the “zero-problem,” a scheme to discredit ATECo, the ITB and me.

 

Ed Miska was allowed to unilaterally alter my contract in secret to my disadvantage, without the knowledge or consent of Dave Ebner (my COR) or me, in a way that would defraud me out of the negotiated, agreed-upon $750,000 price for my Copyrighted source code.

 

So yes, the contract was in danger of going into default, but the fault would be the Government’s. My position is that it was because of an organizational-level attempt by HDC to defraud me out of my intellectual property that there was a potential “default on the Contract.”

 

I don’t know what Dave put in his “hand written note,” but it should have said something to the effect of, “I’ll see you in Court.”

 

The Government’s position on this was very weak, according to my Congressman and the U.S. House of Representatives’ contract lawyer that was engaged to review the original and tampered-with modified contracts.

 

A Court case where Governmental fraud is proven can be a big, moneymaker for the injured party.

 

Goto Section II. Comments on Item 17 Attributes for full discussion.

 

Figure 114 Excerpt from HDC Response; complaints about first field test. My major complaint was that the contract had been tampered with and HDC refused to fix it.

No Apologies will forthcoming. The even greater unstated problem on this test and at this point in time was the attempt by HDC to defraud me out of the $750,000 negotiated, agreed upon price for my Copyrighted software by allowing Ed Miska to tamper with my contract and then everyone on the Government side bullying me to sign it anyway.

 

The field-test that these Government comments are in reference to was conducted without anyone from my company in attendance. We were barred from this test because I was refusing to sign the illegally altered modified Contract.

 

The modified contract was altered in secret by Ed Miska, who put changes in without the knowledge or consent of my Contracting Officer’s Representative, Dave Ebner or me that would have given my $750,000 software source to the Government without payment.

 

Goto Section II. Comments on Item 17 Attributes for full discussion.

 

Figure 115 Excerpt from HDC Response; this is absolutely true. The contract tampering and zero problem scam were an attempt to steal my Intellectual Property; I was being cheated by the Government and was simply fighting back.

This is absolutely true, and I stand by this complaint and these allegations. The illegal contract tampering by Ed Miska and the support of this sham by Ralph Banse Fay and the complicity of everyone else on the Government side by looking the other way was maddening. And now it is outrageous to have the Government trying to foist the onus for this failed project onto me,

 

                        So, I will repeat, here, now, today  - “ENOUGH ALREADY.”

 

Figure 116 Excerpt from HDC Response. This is an arbitrary and capricious interpretation of the Contract terms.

Because this was a time and material contract, the Government was allowed to put in multiple expensive and time consuming changes for the benefit of the Government, for which I was assured that additional time and money would be provided to accommodate and allow for these changes and additions. This complaint is overlooking the many salient facts of the matter delineated herein.

 

It also overlooks that there were several versions of the modified contract. The added funding in this version was to allow continued work because of unforeseen natural and contrived man-made difficulties that were encountered. A brief listing of the man-made, contrived problems that were encountered is in the web reports, “What it was like to work for USACE” and “Reasons for Delays.”

 

 

Figure 117 Excerpt from HDC Response. Reference to post-first field test conversation.

These emails were sent while the Government was overtly and covertly attempting to defraud me out of the negotiated, agreed-upon $750,000 price for my pre-developed, copyrighted software source code. I was becoming understandably frustrated and angry at the lies, deceptions and bullying by Government personnel and became uncooperative and belligerent about it - I was just pushing back.

Take note that these issues were for the most part, resolved when Ed Miska was removed as Technical Lead and Rod Wittinger was reinstated.

 

 

Figure 118 Excerpt from HDC Response; reference to post second field test conversation.

I don’t have a copy of this letter, but I have the following comments on this test.

 

This test failed to accomplish anything useful due to USACE’s mislabeled Winter Kennedy taps and incorrect blueprints.

 

This test went forward after the contract was restored to the exact wording that Dave Ebner and me had agreed upon, Ed Miska was removed from the project, Rod Wittinger was restored as the Technical Lead, Lee Sheldon was restored as the HDC Contact, Paragraph 3.4.2.9 was returned to it’s proper form and paragraph 3.4.2.9a was removed altogether.

 

The HDC Response is quibbling about a few bugs in a new software program’s first roll-out like they are a really big deal. They all got fixed before the Ice Harbor test. What was really a big deal to me was the Government’s attempts to cheat me out of the negotiated, agreed-upon $750,000 price for my Copyrighted software, now that’s a big deal.

 

So I ask you, dear reader, if you’re still with me here, how would you act if the Government agency you were in contract with, tried to defraud you out of your $750,000 intellectual property (software source code) that you’d been working on for over 20 years?

 

Though we didn’t know it at the time, the failure of this field test was due USACE neglect with the mislabeled Winter Kennedy taps.

 

Figure 119 Excerpt from HDC Response, more distortions and deflections of responsibility away from COE.

As stated above, I didn’t see the draft letter so I cannot comment on it.

 

My position at this point was extreme distrust and disgust with the Government, but agreed to do along with Rod Wittinger and Lee Sheldon on this December field test to get the chance to show that the ITB really works. I had already complained of the problems I was experiencing to DOE IG and DOD IG in mid-November 2005.

 

With everything else that had happened adding some money for the test doesn’t seem so unreasonable.

 

It could be said that this added funding was to reimburse ATECo for the cost of participating in the failed September field test. The September test failed because of mislabeled Winter Kennedy taps and inaccurate powerplant blueprints. ATECo spent $16,000 on this failed test, so adding $16,002 seems fair to me.

 

Figure 120 Excerpt from HDC Response, discussing deliverables and upcoming test.

This is an unabashed misrepresentation of the situation.

 

Due to HDC misdirects, continual attempts to purloin my Copyrighted software source code, COE directed configuration changes to ITB including change from discreet sensors to digital communication with 3-D cam and switch to OPC communication, addition of automatic Winter Kennedy flushing etc, the adjustments to the funding and deliverables list were to compensate for COE’s directed changes to the configuration and workscope.

 

Diagnosing the contrived zero-problem by Ed Miska and Dan Perrier took considerable time and effort.

 

Greg Luna made a wasted trip to McNary that was a failure because the Winter Kennedy taps were mislabeled and the powerplant blueprints were wrong.

 

Much time was spent struggling with the contract modification that was altered in secret by Ed Miska in an attempt to deceive me into signing over the software source code without getting paid the negotiated, agreed-upon $750,000 for it. Was it really such a big surprise to HDC personnel that I would bother to read a Government contract before I signed it, and that I would object to unfavorable text that was snuck into the contract by deception?

 

The Government initially agreed to the adjusted deliverables to make it seem advantageous to me so I’d want to sign the modified contract with the secretly added text of paragraph 3.4.2.9 and the addition of 3.4.2.9a (as described elsewhere in this letter), hoping that I’d be stupid enough to sign the modified contract without reading it. 

 

Figure 121 Excerpt from HDC Response, regarding Rod Wittinger’s field test report.

This is a totally false, inaccurate and misleading passage.

 

Rod’s Report was a detailed listing of how the field test progressed, and identified software bugs that were identified that needed to be addressed. These were corrected before the Ice Harbor testing February.

 

The ITB could not operate independently because it could not do the Constant Power test due to the sub-standard GDACS 3-D cam and blade control system and resulting overall bad dynamic behavior of the turbine and governor system.

 

The ITB performed abundant analysis, as delineated in the Data Analysis section of this letter.

 

The document was weak, the reason for this is explained it the Documentation section of this letter.

 

The source code requirement was complied with to the letter.  There was no requirement to give the Copyrighted source code until the government paid the negotiated, agreed-upon price of $750,000 for it.

 

The claimed threat to GDACS security is nonsense.

 

Figure 122 Excerpt from HDC Response regarding comments regarding McNary testing.

Without these specific documents to refer to, I’m not certain what this one is about.

 

However, I freely admit that some of the areas we were working with were new to me.

 

Figuring out workarounds to make the ITB work with the Sub-standard GDACS 3-D cam and bad governor dynamics was a difficult puzzle.

 

This is new technology and there were certainly things yet to learn for everyone involved.

 

My overall impression from this experience is that HDC personnel wanted to seize the Index Test Box technology away from me in order to give it to Automated Control Systems Incorporated so they could mass-produce and sell this equipment to the government in the place of my Actuation Test Equipment Company. At about 6-months into the project, intellectual property security became a much higher priority for my company than anything else.

 

Figure 123 Excerpt from HDC Response regarding my allegations of sabotage.

Yes, and I stand by this allegation. The Winter-Kennedy transducer manifold cart had been left at McNary after the failed September 2005 field test. When we returned to McNary in December 2005, the pressure transducer in the test rig did not work. Troubleshooting the pressure transducer we found that the screw-on cap had been removed, and one of the signal wires torn out with a pair of pliers in such a way that it could not be repaired in the field. Indentations could clearly be seen in the vinyl jacket of the signal wire where it was grabbed to jerk it out. I showed this to Rod Wittinger who made no comment other than to write in his log. Seeing Rod’s report later, he misreported this, the transducer could not be repaired, but I had a spare transducer so this was not a showstopper, but it could have been had I not been prepared. Transducer cost $795. The “zero-problem” story is told above.

 

Figure 124 Excerpt from HDC Response, regarding price list.

This price list was purchased equipment costs, the software price schedule from the Contract LI0003 and a modest markup. Looking at it now, those prices were much too low. The ATE-150 was not absolutely necessary, but because of the fact that the broken wire in it thwarted Ed Miska and Dan Perrier’s (ACSI) zero problem scheme, I’m glad I used it.

 

Figure 125 Excerpt from HDC Response. More false and inaccurate statements

The test engineer said that all of the problems that he could check were OK, some he could not check due to a lack of perturbation software in the GDACS. None of the comments in this letter express that any problems “were not or could not be addressed by the Contractor.” The HDC Response is inexplicably hostilewhere’s all this negativity coming from?

 

Figure 126 A collection of all comments from the referenced letter.

The above is a compilation of all comments about ITB from Dan’s letter. I don’t see any of the negativity that the HDC Response document claims is in Dan’s letter.

 

The truth in it was that the turbine index testing experts: Dan Ramirez, Rod Wittinger and Lee Sheldon were all happy with the ITB after the Ice Harbor test and said that the test data results from my ITB were:

 

“virtually identical to those obtained using COE data acq system”

 

And that my ITB was:

 

“Ready for ‘unattended, automated’ data collection.”

 

Fig 125 below is the Power Point slide from BPA that shows these comments.

 

Figure 127 HDC Power Point slide from February 26, 2006 HOT Meeting

And they wanted to buy two more Index Test Boxes as a result of that test.

 

Where is all the negativity in the HDC Response coming from?

 

Figure 128 Excerpt from HDC Response citing letter to CO.

I do not have this email so no comment.

 

Figure 129 Excerpt from HDC Response about contract fulfillment.

#22. A true statement; I delivered the equipment, it was accepted, and I got paid.

 

#23. These are all moot points. The issue was that I developed software and a system that was demonstrated to successfully, automatically index test a Kaplan turbine. The logical modules were only used as a construction framework to write the program. I described them in the proposal to help HDC understand what the ITB program was and how it worked.  This proposal was not mandatory nor was it purchased. What was purchased was in Line Item 0001 - one each Index Test Box.

 

HDC did not buy any of the separate software items from Line Item 0002 or LI0002.

 

All of this niggling over software is nonsense; the Government got what was paid for, no more, no less.

 

Make no mistake about it – I’ve been working on this program since 1985, and just because the Government bought one instance of it does not grant the Government the right to make additional copies for widespread distribution - which now I see is what the Government was always after.

 

Further discussion: the modules as described, if purchased would have been in units of “ea.” Each instance would have been enabled to work only in the computer platform that they had been keyed into by having hard-coded serial numbers of the CPU, hard drive and I/O board of the target system they were going into, much like Microsoft or any other software vendor protects their Intellectual Property rights.

 

The big disagreement here is that the Government wanted to pirate my program and make unauthorized distributions and installations of it, and I didn’t want that to happen.

 

Figure 130 Excerpt from HDC Response regarding my contract tampering complaint letter

I don’t know which July 25 2005 letter is being referred to, but from the timeline I can put it into context.

 

At the time that this letter was written, my contract had been unlawfully tampered with by Ed Miska who was allowed to add wording to it that, if I had signed this secretly altered, modified contract, would have compelled me to give the pre-developed software source code to HDC without the negotiated, agreed-upon $750,000 payment. While I was being barred from actively participating in the project, Ed had invited Dan Perrier, of ACSI, HDC’s favored supplier, or “captive supplier” to HDC in to sabotage my equipment by creating the “zero-problem,” a contrived software trick to discredit my company, my equipment and myself. Dan Perrier had created the “zero-snatcher” as a quick-fix, so he could be the “hero” after the zero-problem had been used to show my incompetence. I was and am very disgusted and distrustful of HDC for attempting to take my Intellectual Property by these deceptions, and it probably showed through in my email letters.

 

Goto blade perturbation and zero problem details.

 

Recording the operating level of adjacent units is helpful for index testing, and is still in the Index Test Box program. Right now I’m working with Brookfield power on an index test of three Kaplan bulb units that are situated in parallel. The index test box is collecting data on all three through their SCADA system to simultaneously index test all three units, and we’re learning that the flow rate in the forebay out in front of these units does measurably affect the measured and actual operating efficiencies of these units. I have the data to prove the necessity/benefit of monitoring adjacent units now.

 

On the subject of GDACS security - how stupid would it be for me to do anything to harm your system? Firstly, it would have destroyed any potential for future business, and if misconduct on my part caused a problem, you know where I live; you have my tax number. C’mon, wise up. I’m not the threat here. The greater threat to the Government is rampant procurement favoritism in HDC that has resulted in to sub-standard 3-D cams and blade control equipment in every FCRPS powerplant, increased flow turbulence and shear forces, increased hazard to downstream migrant juvenile fish – all of which has brought about the Endangered Species Act lawsuit, and the fact that the sub-standard equipment and continuing cover-up places the Government position precariously close to, “contempt of court.”

 

Abuse of software security

Ed Miska said GMT wanted 3-days for “security screening” of the index test box program before testing at McNary when first delivered in May 2005. Later, while I was rushing to get everything working before the field test at McNary in December 2005, GMT insisted on 5-days for the security checkout.

 

Later we learned that the security checkout consisted of simply running Norton’s Anti-virus program on the Index Test Box executable program – a 5-minute procedure, and that before this test the Index Test Box and GDACS security setup sat idle for 3-full days.

 

It seems to me that “GDACS software security” was used to put up unnecessary hurdles to a successful ITB field test.

 

Figure 131 Excerpt from HDC Response discussing software marketing strategy.

The situation with this letter; it was one of a series of letters exploring options after the Government chose not to buy the pre-developed Copyrighted software for the Index Test Box but still wanted access to the functionality of the automatic Index Test Box for Kaplan turbines. In these letters I was proposing to Dave Ebner different way to arrive at a compromise, none of which were accepted so none are binding.

 

The government did not purchased any software other than the one copy in the ITB that was delivered and software that was written at Government expense, referred to as Co-Developed code. All of this complaining about modules, source code etc. is pointless, the Government personnel that wrote the HDC Response are complaining because I didn’t deliver software that was never purchased.

 

The Co-Developed code does not include any of the original Copyrighted source code.

 

A full set of the Co-Developed code was sent to HDC when first purchased from ACSI (I bought an example RS Linx OPC Interface setup and GDACS tag-name set for $1,000, and gave a copy of it to Ed) on 4/6/2005, an additional copy was given to HDC each time we were in preparation for a field test, another copy was given at the end of the Contract workscope, and copies of the Co-Developed code were given to HDC whenever it was requested.

 

Ed Miska always complained that the pre-developed Copyrighted source code, the main body of the programming that was comprised of the SteadyState, StripChart and XY-Plotting routines, was not in the software that was delivered - and each time I would explain to him that it had not been purchased, so it was not delivered.

The price schedule for software was in the Contract as Line Item 0002 and Line Item 0003.

 

The Government did not buy any of this additional software; so all of these niggling software discussions are moot.

 

The last sentence is also false. The Government would not be dependant on the Contractor after purchasing the software, and would not have to pay for each use. The Government would only need to buy the software once, but the Government wanted full access to the software source code in order to produce unlimited copies of the program without paying for it at all.

 

After it had been purchased the software would be the property of the Government and could be used at will, within FCRPS per the negotiated agreement with Dave Ebner at the beginning and renegotiated at the end of the contract performance period.

 

In closing, I must say that the Government’s HDC Response is the most disingenuous, manipulative pack of lies I’ve ever had the displeasure of dealing with.

 

As a result of this encounter, my level of respect for Government employees and trust in the Government has reached a new all-time low; I live in Illinois, so that’s sayin’ something.

Sincerely,

Doug Albright

Winnebago Illinois

October 20, 2009