There are several ambiguities and operational issues with this definition.   

SOT:  First, the phrase "available to operate without a status condition or 
fault that would otherwise limit its operation" in SOT is very easily 
misunderstood.  Many owners & I.E.'s think that "System Okay" means the 
turbine should produce power, as per the power curve,  during every second of 
SOT.  This isn't true.    If the turbine is paused offline or manually 
stopped, untwisting cables, resetting, undergoing a load shutdown,  in low 
noise operation, or  in spinning or starting up mode, then the SOT clock is 
incremented even though the turbine can't produce power.  I think the SOT 
description should read something like"not faulted off for turbine 
malfunction or offline for failed turbine systems."  Either that or call this 
counter something other than "System Okay".   

DT:  The phrase "or that is counted as Weather Out Time" may confuse the 
owner.  According to SCADA training if a downtime fault occurs at the same 
time as a "weather out" condition then the turbine fault (DT) will have 
precedence.    This precedence may be hard to explain to owner.  Therefore, I 
recommend you delete the Weather out phrase.  In other words, stop the 
sentance on Majeure Events.

LOT:   Precedence also can cause confusion here.  If a turbine fault occurs 
when the grid is outside of specs we've been told that DT will always take 
precedence whether the grid induced the fault or the fault occurred due to 
turbine malfunction not related to the grid.  How does the controller 
distinguish (and analysts from ten minute SCADA data) whether the fault was 
due to the grid or the grid was driven out of spec by a turbine malfunction?  
I recommend that you replace the phrase "except where line conditions are 
forced out of specs due to Turbine malfunction" with " except when the 
turbine faults offline."  Further, it should be noted that when the turbine 
faults off due to grid variations then it probably is true that EWC is 
penalized for the grid variations.   

MT:  How do we implement the 36 hour limit on MT in the equation?  I assume 
that we compute a value MTexcess that is that portion of MT in excess of the 
36 hour limit.   Then we use MTexcess in the numerator instead of MT to 
penalize EWC for exceeding the MT limit.   Where did 36 hours come from?   
The previous limit in all existing 1.5 contracts is 48 hours and MT, as 
defined by the controller fault listing, includes several other tasks that 
are not on a scheduled maintenance  checklist.   The 48 hours per year was 
intended only to capture those tasks on the maintenance checklist.

WOT:  How does the controller know when the turbine can't be repaired due to 
weather related events or that weather makes access unsafe?   If it can't 
then you are adding an activity that must be tracked by manual log and 
integrated into availability computations by a manual procudure that is not 
value added to the customer and costly to operator.

EOT:  What about icing sensor shutting down turbine?   This isn't due to 
Owner.   

ST:  This definition of ST rarely equals the total number of hours in the  
"survey or measurement" period  due to communication losses and power 
outages.   I recommend you  remove that phrase from the definition OR alter 
the definition of availability to (SURVEY - DT - RT - MT)/(SURVEY - 
MTprorated).    SURVEY is the maximum possible number of hours in the survey 
period and MTprorated is the percent of 36 hours per year in the survey 
period.  I recommend keeping the current availability definition as it uses 
info already in Visupro. 

Availability equation as shown doesn't penalize EWC for MT above the 36 hour 
limit.   See MT above for solution.  



 



From: Ilan Caplan on 04/17/2002 09:14 AM
To: Mark Fisher/EWC/Enron@Enron, Mark V Walker/EWC/Enron@ENRON
cc: Hollis Kimbrough/EWC/Enron@ENRON 

Subject: Proposed Clipper Availability

Mark(s) - 

Please review the attached calculation which Clipper proposes for 
Availability.  I will compare it with the contractual availability which have 
recently proposed, but would prefer your input.

Thanks,
Ilan


---------------------- Forwarded by Ilan Caplan/EWC/Enron on 04/17/2002 09:26 
AM ---------------------------


Mark Eilers
04/17/2002 09:02 AM
To: Ilan Caplan/EWC/Enron@Enron
cc:  

Subject: Availability

Ilan 

Can you please give this a quick read to see if this my work.  This is a take 
on our standard availability that Clipper is proposing.  Let me know your 
thoughts. 

Mark