CIM Issues #5309

Support on FACTS device modeling

Added by Yang Feng over 2 years ago. Updated over 1 year ago.

In Progress
Author/Contact Info:
Yang Feng
Base Release:
Solution to be Applied To:
Solution Version:
Solution Applied By:
Completion Date:
CIM Keywords:
61970-Dynamics, 61970-Wires
Breaking Change:
Breaking Change Description:
CIM Impacted Groups:
Yang Feng
Originally Closed in Version:
Origination Date:
Origination ID:
Originally Assigned To:


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:,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


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.


Updated by Chavdar Ivanov over 1 year ago

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

Updated by Chavdar Ivanov over 1 year ago

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

Updated by Todd Viegut over 1 year 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:


Updated by Todd Viegut over 1 year ago

  • Status changed from Review to In Progress

Also available in: Atom PDF