Project

General

Profile

CIM Issues #5309

Support on FACTS device modeling

Added by Yang Feng about 3 years ago. Updated about 1 month ago.

Status:
Closed
Priority:
High
Author/Contact Info:
Yang Feng
Base Release:
CIM17
Solution to be Applied To:
CIM18v16
Solution Version:
CIM18v16
Solution Applied By:
Chavdar Ivanov
Completion Date:
04/06/2025
CIM Keywords:
61970-Dynamics, 61970-Wires
Breaking Change:
Yes
Breaking Change Description:
Old StaticVarCompensator attribute will require remapping to the new FACTSEquipment and related classes.
CIM Impacted Groups:
WG13
Requestor:
Yang Feng
Standard(s):
Version:
Clause:
Sub-Clause:
Paragraph:
Table:
Originally Closed in Version:
Origination Date:
Origination ID:
Originally Assigned To:

Description

Generic FACTS device modeling is currently not available and need to be supported, while only its specialty SVC is supported. It contains, e.g., Static Synchronous Series Compensator (SSSC), Unified Power Flow Controller (UPFC), Thyristor-Controlled Series Capacitor (TCSC), Static Synchronous Compensator (STATCOM), and etc.

Wiki Reference: https://www.sciencedirect.com/topics/engineering/flexible-ac-transmission-systems#:~:text=FACTS%20devices%20are%20static%20power,congestion%20management%20and%20loss%20optimization.

Proposed Solution

Initial Step: Review the FACTS device models and work out the draft UML for modeling them.
Note: ENTSO-E & Statnett has already worked on this and made good progress. Can become the basis for standardization.

The task is to present FACTS and control model and eventually add it in CIM18v04. The proposal is using the concepts discussed in Tom Berry's group/control discussions

Decision

Discussed during the 15-Feb-2023 meeting and the Action Items identified in the comments for this date must be executed first to determine a final proposal.

19-Sep-2024 Joint TF Hybrid Meetings - Minneapolis:
Revisited this one. Decided to delete the old and create a mapping script.

Release Notes

The following model changes were made for this issue:
  • The SVCControlMode enumeration was deleted from the canonical model.
  • The description of the existing StaticVarCompensator class was updated to align it with the new FACTS modelling.
  • The inheritance hierarchy for StaticVarCompensator was changed from RegulatingCondEq to now inherit from the new FACTSEquipment class.
  • All the existing attributes that were defined within the StaticVarCompensator class were deleted.
The attributes that were deleted are now replaced/mapped to the following new attributes/classes:
  • StaticVarCompensator.capacitiveRating -> FACTSEquipment.ratedC
  • StaticVarCompensator.inductiveRating -> FACTSEquipment.ratedL
  • StaticVarCompensator.q -> FACTSEquipment.q
  • StaticVarCompensator.slope -> FACTSEquipment.slope
  • StaticVarCompensator.voltageSetPoint -> VoltageControlFunction.targetValue
The following enumeration literals deleted with the removal of the SVCControlMode enumeration now map to:
  • StaticVarCompensator.sVCControlMode.reactivePower -> ReactivePowerControlFunction
  • StaticVarCompensator.sVCControlMode.voltage-> VoltageControlFunction
Profile impacts due to these model changes include:
  • Deleted the SVCControlMode enumeration from 452 EQ Core profile.
  • Deleted the StaticVarCompensator class from the SSH profile
#1

Updated by Chavdar Ivanov about 2 years ago

  • Status changed from New to Open
  • Solution to be Applied To changed from CIM18 to CIM18v04
#2

Updated by Chavdar Ivanov about 2 years ago

  • Status changed from Open to Review
  • Proposed Solution updated (diff)
#3

Updated by Todd Viegut about 2 years ago

  • Decision updated (diff)

Chuck noted that FACTS devices is a general term. Two schools of thought to run with. Either they are purely electronic or alternatively a combination of high speed parts of the devices along with static capacitors and reactors portion (but all are under one control system). Can deal with that as either a single device or treat the two separately. Chuck has thought on these two quite a bit. He has landed that this should really be a single machine. Chuck's comments here are to sound off on what his opinion is as to his thoughts on which of the two directions to go (as a single device).

Eric's argument is that we need to consult Svein to determine if his existing use cases validate if the use cases go against what Chuck's thinking is (?)

Action Items:
Step 1: Chuck to suggest UML modelling for the physical device
Step 2: Then we need a model for the control. Can the existing regulating control fit the bill? If not we need a recommendation as part of this proposal.

Chuck and Jay provided two IEC use case that should be reviewed. They are in the folder on SharePoint for this weeks in-person meetings:

http://iectc57.ucaiug.org/WG13/Shared%20Documents/Forms/AllItems.aspx?RootFolder=%2fWG13%2fShared%20Documents%2fMeeting%20Agendas%20and%20Minutes%2f23%2d02%20Richland%2fFACTS%20Devices%20%2d%20Use%20Cases&FolderCTID=&View=%7b52C45526%2d18A5%2d4E9A%2d951E%2d118A791DBC9E%7d

#4

Updated by Todd Viegut about 2 years ago

  • Status changed from Review to In Progress
#5

Updated by Todd Viegut 8 months ago

  • Decision updated (diff)
#6

Updated by Todd Viegut about 1 month ago

  • Base Release set to CIM17
  • Solution to be Applied To changed from CIM18v04 to CIM18v16
  • Solution Version set to CIM18v16
  • Solution Applied By set to Chavdar Ivanov
  • Breaking Change changed from No to Yes
  • Breaking Change Description set to Old StaticVarCompensator attribute will require remapping to the new FACTSEquipment and related classes.
  • Release Notes updated (diff)
#7

Updated by Todd Viegut about 1 month ago

  • Decision updated (diff)
  • Release Notes updated (diff)
#8

Updated by Todd Viegut about 1 month ago

  • Status changed from In Progress to Closed
  • Completion Date set to 04/06/2025

Also available in: Atom PDF