The health-status of a circuit breaker is modeled by XCBR.EEHealth:
Green - ok, yellow - warning, red - alarm. Nearly all detailed warnings and alarms of a CB (like SF6-density-warning, SF6-density-alarm,...) can be summerized by EEHealth. That means for the remote operator:
yellow - the CB is still working but needs maintenance as soon as possible,
red - the CB is no longer working, no switching is possible.
But there is another category of alarm, which is somewhere between green an yellow: This is the alarm of the cubicle heating. Most CBs in air insulated switchgear generate this alarm. This alarm means for the remote operator: CB is still working but needs maintenance but NOT as soon as possible - maybe in some weeks. So for the remote operator it is worthwhile to have two main health information:
1. XCBR.EEHealth
2. XCBR. "heating alarm"; currently there is no related data in the model.
Proposal
Add a new data: XCBR.HeatAlm [SPS] (heating alarm)
This data is also worthwhile for other power equipment, e.g.
XSWI.HeatAlm
YPTR.HeatAlm
Discussion
Created
Status
solved and accepted in ed.2
14 Feb 08
In Force (green)
Actually there will be in ED2 a LN STMP (supervision temperature) what can be used for this purpose. Extension of the state of Health can not be supported because it describes a different view of the related object. So we reject to include a new DO and we reject to extent the health.
06 Jun 07
Ballot Period
Adding a TmpAlm is no problem at all. The DATA TmpAlm (not HeatAlm)exists already, and can according to 7-4 extension rules be used in any other LN, as long as it keeps its semantics (an alarm due to a critical temperature condition). I just want to stress, that DATA belonging to a CB do not need to be within XCBR. It is sufficient to allocate the containing LN (e.g. SIMG, GGIO) to the CB in the SCL Substation section.
05 Jun 07
Discussion (red)
I agree with Christoph that adding a fourth Health state might add compatibility problems. Further, from the examples, it seems to me that the 'problem' (failed heater) does not relate to the CB at all,because it does not influence the CB's operating capability (neither short term nor longer term; except possibly in winter?). Although it belongs geographically to the CB resp. CB cubicle, as an alarm it just belongs to the heater - so it should be a separate heater (not heat) alarm. That it belongs to the CB could be shown via the substation section. So, it could be a GGIO.Alm with GGIO allocated to the heater function of the CB.
29 May 07
Discussion (red)
So, as a conclusion form the discussion, we would need to model four level of health:
1. everything is ok (green)
2. there are some warnings that are not critical (the yellow from today)
3. there are some warnings that are critical; currently the equipment can still be used, but sooner or later it will fail. The equipment should be taken out of service as soon as possible (A new state)
4. It is not safe to operate the equipment anymore. It needs to be taken immediatly out of service.
Does this fullfill all requirements?
The problem may be, how to implement this in a way that it is backwards compatible.
An alternate solution could be, to keep the three levels we have today and to add for the yellow state a user configurable severity information, that can have as many levels as wished and that refers to a utility specific guideline for the operator, how to handle the problem. But keep in mind that such a solution adds to the configuration effort required to engineer the substation. So I would prefer a standardized solution.
27 May 07
Discussion (red)
"Red" means, that it is no longer possible to switch that CB. To prevent serious failures, the network operator has to seperate this CB immediatly from the network by use of the surrounding CBs. E.g. in case of a double busbar substation all feeders needs to be switched to the other busbar. Then the "red" CB can be switched of by the busbar coupler and the line disconnector. If there is actually not enough redundance in the network, a "red" CB may cause trouble.
"Yellow" means, that the breaker is still able to switch, but there is a problem. That problem may escalate sooner or later into the "red" state (e.g. in case of a leakage). So the network operator seperates (usually immediatly) the CB from the network. But in comparison to the red state it is much more simple: He switches off the "yellow" CB and then the surrounding disconnectors. So there is no influence to the other feeders on the same busbar. Of course (if there is no transfer busbar) the related line or transformer will be switched off.
That is the reason for another kind of "light-yellow" pre-warning. This is a problem, where the operator is sure, that this alarm will not escalate to a yellow or a red state, so it is not necessary to seperate the CB from the network. The heating alarm is a typical example for that kind of alarm level.
Note, that the network operator is not a CB specialist. In a large network he has to switch thousands of switches and needs simple and clear reports - like red, yellow, green and "light-yellow" that influence his reactions. It is not his job to browse through information details to decide, how to react e.g. on a yellow-report. That kind of operation may work in a small network.
So in addition to my first comment, I recommend
1. to add a new data XCBR.HeatAlm [SPS]
2. to realize a pre-warning level. This may be modelled by a separate data class "PreAlm"[SPS] or by extension of the ENUM values of Health:
4 = pre-warning
(The german committee DKE AK 952.0.2 will make a proposal for new data regarding CB-supervision and CB-monitoring soon.)
25 May 07
Discussion (red)
I do not agree with the interpretation of yellow, that this means to switch off CB and orhganize maintenance for the next day. According to our definition of yellow, this means, that it is still safe to operate the device, so it is not necessarily required to switch it off. But I agree, it is required to organise maintenance.
What would be the difference between yellow and red otherwise? Would it mean, that in the case of red, the CB needs to be disconnected from the network; with yellow, it would be openend, but stay connected to the network?
09 Apr 07
Discussion (red)
I think to include a new Logical Node "heating" is too academic and a little far away from practice. In fact almost every cubicle for outdoor installation has a small heating resistance that prevents the installation from moisture and therefore from corrosion. Often the over-current release of the resistance´s power supply has a contact, that sends an information if the heating is off.
In actual power control systems the heating alarm is merged into the "yellow" warning indication. But I disagree, that this is a good solution. The network operator in a central remote control center must be prevented from information overflow. For that reason he only gets simple information that influence his operation on the network:
CB-alarm (red) means for him to disconnect the CB with the surrounding CBs immediatly from the network.
CB-warning (yellow) means for him to switch off the CB and organize maintenance for the next day. (It is not his job, to find out what´s the detailed reason for the warning, and to decide when to switch off: next day or maybe in some weeks !)
There was the idea to introduce a CB-pre-warning in our control system. CB-pre-warning means for the operator in the network control center not to switch off the CB, but to inform the maintenance stuff to maintain the CB when it is convenient. But in fact the heating alarm is the only alarm, that is merged into the CB-pre-warning. For that reason it is worthwhile to have three simple alarm levels at the network control center: 1. CB-heating-alarm, 2. CB-warning, 3. CB-alarm.
The most simple way with a practical orientation to do that, is to introduce the data HeatAlm.