Skip Ribbon Commands
Skip to main content
Notes - IOP Call 11 March 2013, 16:00h-17:00h CET

Mainly 2 issues were discussed:
  • changes on the PhaseTapChanger model because: the current model of the tap changer does not allow describing an assymetrical PhaseTapChanger (ratio and angle changes per tap) in a tabular way. To fix this a “ratio” attribute (Float) should be added to PhaseTapChangerTabularPoint as it is RatioTapChangerTabularPoint
  • issue on RegulatingControl.targetRange: We need to clarify the unit that should be used. It is dependent on what is regulated, but the profile should clarify this. Do we have something in 452? The description “This is the case input target range.   This performs the same function as the value2 attribute on the regulation schedule in the case that schedules are not used.   The units of those appropriate for the mode.” should be clarified. Are there any dependencies with RegulatingControl.discrete? We are often getting in the exchanges RegulatingControl.discrete = true and   RegulatingControl.targetRange=0. Is this possible and how it should be interpreted?
WG13 discussed these issues and there are some suggestions for fixes. These fixes were discussed in the IOP call:
- the proposal for PhaseTapChanger looks OK for IOP participants. 
- On RegulatingControl - the following recommendations were made - to be considered by WG13:

  • Replace targetRange by a min and max value.
  • Replace RegulatingControlModeKind.fixed with a Boolean RegulatingControl.regulationOn. This will reduce the number of mode changes. A tap changer built as fix will not regulate so RegulatingControl isn’t needed. Question is if adjusting the tap pos with a wrench still need a RegulationSchedule? E.g. if going there with the wrench on seasonal basis?
  •   A type change is rare (or does not exist) except for the SynchronousMachine that change between voltage and reactive. Other type changes than this was believed not exist.
  • A type change can then be avoided by having a RegulatingControl instance per subtype, e.g. voltage and reactive. The target and min/max will be different and stay constant per subtype.

In addition it was agreed that OperationalHypothesis profile is a priority and HVDC model should be understood.
In the next call Lars-Ola is invited to give some explanation on what is currently in the DC package in the UML and give a guidance how to read and get oriented.

Participants:

1 Parma, Ferdinando
2 Osterlund, Lars-Ol…
3 Britton, Jay
4 Stanescu, Oana
5 Zhu, Jun
6 Bozukov, Georgi
7 Olsen, Svein
8 Tomic, Dragan
9 Schmid, Christoph
10 Nagarkar, Rashmi
11 Gillerman, John
12 Martinovic, Lajos
13 Akel, Youssef
14 MILIN, Emilie
15 Kravljaca, Gordana…
16 Lopez, Rafael
17 Cott, Giatgen
18 Rogowski, Tomasz
19 Falk, Herb
20 Wiernowolski, Mich…
21 Milic, Vladimir


Members Supporting CIM