There are only a few vendors of etagging software, yet they still disagree about what to do under certain circumstances leaving a sometimes-unreliable result. For example, a
DistributeNewTag message came into focus recently where one of the physical path segments used a POD that was registered to serve as a POR only. Apparently it was a registered generator without provisions to accept station service. The errors multiplied until finally a breach of reliability occurred, quite undetected until long after the fact.
The chain or errors is as follows:
- Error 1- A PSE using a tag authoring tool from vendor X was allowed to select a POR-only point to be a POD.
- Error 2- The source (GCA) tag Agent and sink (LCA) tag Authority software accepted the submission without complaint.
- Error 3- An intermediate wheeling company’s tag Authority service software spotted the error, rejected it, and replied with an INVALID message.
- Error 4- The intermediate wheeling company’s Agent system failed to register the invalid tag making it impossible for real-time schedulers to either find nor examine the missing tag.
- Error 5- The LCA’s authority service interpreted the INVALID message as COM FAIL, and since the tag was submitted inside the allowable time frame, the COM FAIL message was judged to be PASSIVE APPROVED at the end of the assessment period.
- Error 6- The intermediate wheeling company has resisted the concept of tag-equals-schedule and therefore still requires all true schedules to be telephoned in - the matching of tag to schedule is a goal, but not a requirement. The called-in-schedule was not properly matched to any etag, so the verbal schedule was denied while the tag was not.
A day after the fact, the case of the missing tag was turned over to a contractor (me) to troubleshoot. I searched for the missing tag using the filtering means supplied by the tag vendor and located the XML communications chain. Calls were made to the appropriate tag system vendors to alert them of this gaping hole, and to my surprise, each claimed that their tagging systems obey the specifications. Indeed, this is what I found: page 13 of the ETAGFS-1.70FINAL.doc states a definition of INVALID as “Delivery state indicating that a party received a request distribution, but felt it was not syntactically or semantically correct.” That seems correct operation to me, but the other vendor cited that an INVALID delivery state is in equal standing as a COMM FAIL, and that such tags are subject to passive approval or denial depending on the time of the event. I submit that this concept is faulty, and any tag that receives an INVALID state should by summarily DENIED.
As bad as the 6 errors noted above were, the most troubling point of this whole affair was in the conversation between the real-time scheduler and myself. He asserted that the energy absolutely
did not flow because he denied the schedule verbally. I know he feels comfortable in that belief, but the etag remained approved and the generator, the generating control area, the load control area, and the sink all thought it flowed and adjusted their controls likewise. The result of this interchange is:
- The schedule was eventually removed by after-the-fact staffers, but
- plus 50MW inadvertent was accumulated by the GCA, and
- minus 50MW inadvertent was accumulated by the LCA, and
- the source generator received payment for the energy, and
- the sink paid all the above.
So, every party to the transaction was paid financially
except the wheeling company that gave the verbal denial. And I have news for them: The schedule actually
did flow, except you were the one party that was not paid! Is there a moral to the story? Yes. I recommend to the NERC tagging rule-wizards to darken the gray areas of the specification so that an INVALID message is treated as if the tag were DENIED, and then require Agent software to enforce the rules of the specification. Having done this, the tag author would have discovered the error, repaired it, and resubmitting it would have enabled a proper schedule.
