<CRAC_MarketDocument xmlns="urn:iec62325.351:tc57wg16:451-n:CRACdocument:2:3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:iec62325.351:tc57wg16:451-n:CRACdocument:2:3 iec62325-451-n-crac_v2_3.xsd">
  <mRID>CIM_CRAC_DOCUMENT</mRID>
  <revisionNumber>1</revisionNumber>
  <type>B15</type>
  <process.processType>A48</process.processType>
  <sender_MarketParticipant.mRID codingScheme="A01">FAKE</sender_MarketParticipant.mRID>
  <sender_MarketParticipant.marketRole.type>A36</sender_MarketParticipant.marketRole.type>
  <receiver_MarketParticipant.mRID codingScheme="A01">FAKE</receiver_MarketParticipant.mRID>
  <receiver_MarketParticipant.marketRole.type>A04</receiver_MarketParticipant.marketRole.type>
  <createdDateTime>2021-03-31T15:02:00Z</createdDateTime>
  <status>
    <value>A42</value>
  </status>
  <time_Period.timeInterval>
    <start>2021-04-01T22:00Z</start>
    <end>2021-04-02T22:00Z</end>
  </time_Period.timeInterval>
  <domain.mRID codingScheme="A01">10YCB-FR-ES-PT-S</domain.mRID>

  ...
</CRAC_MarketDocument>

A crac market document has a time interval for its validity. Therefore, this document has to be imported for a specific datetime – hourly-precise.

Contingencies

 <Series>
    <mRID>ContingenciesSeries1</mRID>
    <businessType>B55</businessType>
    <name>ContingenciesSeries</name>
    <optimization_MarketObjectStatus.status>A52</optimization_MarketObjectStatus.status>
    <Contingency_Series>
      <mRID>Co-1</mRID>
      <name>Co-1-name</name>
      <RegisteredResource>
        <mRID codingScheme="A02">networkElementId</mRID>
        <name>Co1NetworkElementName</name>
        <in_Domain.mRID codingScheme="A01">1------0</in_Domain.mRID>
        <out_Domain.mRID codingScheme="A01">1------0</out_Domain.mRID>
      </RegisteredResource>
    </Contingency_Series>

  ...
</Series>

Contingencies are listed in Series of business type B55. They are defined in Contingency_Series elements. The associated network elements are defined in the registered resources.

CNECs

FlowCnecs

<Series>
    <mRID>CNECs_after_all_contingencies</mRID>
    <businessType>B57</businessType>
    <name>CNECs_after_all_contingencies</name>
    <optimization_MarketObjectStatus.status>A52</optimization_MarketObjectStatus.status>
    <Contingency_Series> ⚪OPTIONAL
    ...
    </Contingency_Series>
    <Monitored_Series>
     <mRID>CNEC-2</mRID>
     <name>CNEC-2-name</name>
      <RegisteredResource>
       <mRID codingScheme="A02">FAKE_ID</mRID>
         <name>CNEC-2</name>
        <in_Domain.mRID codingScheme="A01">1---W</in_Domain.mRID>
        <out_Domain.mRID codingScheme="A01">1--W</out_Domain.mRID>
        <Measurements>
          <measurementType>A02</measurementType>
           <unitSymbol>P1</unitSymbol>
           <positiveFlowIn>A02</positiveFlowIn>
          <analogValues.value>2.0</analogValues.value>
         </Measurements>
         <Measurements>
          <measurementType>A07</measurementType>
          <unitSymbol>AMP</unitSymbol>
        <positiveFlowIn>A01</positiveFlowIn>
        <analogValues.value>2.0</analogValues.value>
      </Measurements>
     </RegisteredResource>
    </Monitored_Series>

  ...
</Series>

CNECs are defined in Monitored_Series elements. A CNEC has one registered resource that defines its network element via its mrID. The optimization_MarketObjectStatus indicates if the CNEC is monitored or optimized.

As it is defined in the CRAC model, a CNEC is associated to a state. If the Series containing the Monitored_Series has one or many Contingency_Series that have previously been correctly defined in B55 Series, CNECs shall be created after these referenced contingencies. When no Contingency_Series are present in this Series, CNECs shall be created after all the contingencies defined in B55 series. The Measurements tags define the instants on which CNECs are defined via the measurementType tag, and the CNEC’s threshold values.

Finally, a CNEC can be named in the following way : [network element name] - [side (placeholder if the branch is a TieLine)] - [direction in which the CNEC is monitored (placeholder)] - [monitored (placeholder for MNECs)] - [contingency (placeholder for when a contingency is defined.)] - [instant].

AngleCnecs

<Series>
  <mRID>Angle1</mRID>
  <businessType>B56</businessType>
  <name>Angle1-name</name>
  <optimization_MarketObjectStatus.status>A52</optimization_MarketObjectStatus.status>
  <AdditionalConstraint_Series>
    <mRID>AngleCnec1</mRID>
    <businessType>B87</businessType>
    <name>AngleCnec1-name</name>
    <measurement_Unit.name>DD</measurement_Unit.name>
    <quantity.quantity>30</quantity.quantity>
    <RegisteredResource>
      <mRID codingScheme="A02">networkElementId</mRID>
      <name>RegisteredResource1</name>
      <marketObjectStatus.status>A47</marketObjectStatus.status>
    </RegisteredResource>
    <RegisteredResource>
      <mRID codingScheme="A02">networkElementId</mRID>
      <name>RegisteredResource2</name>
      <marketObjectStatus.status>A46</marketObjectStatus.status>
    </RegisteredResource>
  </AdditionalConstraint_Series>
  <Contingency_Series>
    ...
  </Contingency_Series>
  <RemedialAction_Series>
    ...
  </RemedialAction_Series>
</Series>

AngleCnecs are easily distinguishable thanks to the AdditionalConstraint_Series tag. They define an AngleCnec in curative with an importing element, an exporting element (cf. the two registered resources) and with a threshold with a max bound defined by quantity.
In the CIM CRAC, AngleCnecs are actually defined with their corresponding remedial actions in B56 Series (ie Remedial Action series). The Contingency_Series (unique) refers to the contingency after which the AngleCnec is monitored.

VoltageCnecs

VoltageCnecs are defined in the crac creation parameters file. Nevertheless, they are imported via the CimCracCreator because that’s where the information on which contingencies are imported lies. Only voltage cnecs with contingencies correctly defined in B55 Series shall be imported.

Remedial Actions

Remedial actions are listed in Series of business type B56.

<Series>
    <mRID>RA-Series-1</mRID>
    <businessType>B56</businessType>
    <name>RA_SERIES</name>
    <optimization_MarketObjectStatus.status>Z01</optimization_MarketObjectStatus.status>
    <Contingency_Series> ⚪OPTIONAL
    ...
    </Contingency_Series>
    <Monitored_Series> ⚪OPTIONAL
    ...
    </Monitored_Series>
    <RemedialAction_Series>
      <mRID>PRA_1</mRID>
      <name>PRA_1</name>
      <businessType>B59</businessType>
      <applicationMode_MarketObjectStatus.status>A18</applicationMode_MarketObjectStatus.status>
      <availability_MarketObjectStatus.status>A39</availability_MarketObjectStatus.status>
      ...
      <Shared_Domain> ⚪OPTIONAL
        <mRID codingScheme="A01">10YFR-XXX------C</mRID>
    </Shared_Domain>
    </RemedialAction_Series>
    ...
</Series>

BusinessType in B56 series should always be B59. In RemedialAction_Series, the applicationMode_MarketObjectStatus defines the Remedial Action’s instant :

  • Preventive : A18
  • Curative : A19
  • Preventive and curative : A27
  • Auto : A20.

RemedialAction_Series may also contain Contingency_Series, Monitored_Series and Shared_Domain tags. Remedial actions’ usage rules will be defined depending on these tags:

  • RemedialAction_Series that don’t have any Monitored_Series children tags nor any Shared_Domain tags define FreeToUse remedial actions.
  • When Monitored_Series tags exist, they define CNEC Ids for which the remedial action series is available. These CNECs must have been defined previously in a B57 series. When the RemedialAction_Series also contains a Contingency_Series, the only CNECs from the Monitored_Series tags that will be considered are those that list CNECs defined with a contingency from the Contingency_Series. For each remaining CNEC, the remedial action is defined with a OnFlowConstraint on the remedial action’s instant.
  • When the RemedialAction_Series has no Contingency_Series, no Monitored_Series, and a Shared_Domain tag, the Shared_Domain tag must be taken into account. It represents a country. Then, the remedial action is defined with a OnFlowConstraintInCountry on the remedial action’s instant.

Some remedial actions are aligned. When it’s the case, this information is retrieved from the CracCreationParameters file and the remedial actions are defined with a common groupId.

PST Range Actions

<Series>
    <mRID>RA-Series-1</mRID>
    <businessType>B56</businessType>
    <name>RA_AFTER_ALL_CONTINGENCIES</name>
    <optimization_MarketObjectStatus.status>Z01</optimization_MarketObjectStatus.status>
    <RemedialAction_Series>
      <mRID>PRA_1</mRID>
      <name>PRA_1</name>
      <businessType>B59</businessType>
      <applicationMode_MarketObjectStatus.status>A18</applicationMode_MarketObjectStatus.status>
      <availability_MarketObjectStatus.status>A39</availability_MarketObjectStatus.status>
      <RegisteredResource>
        <mRID codingScheme="A02">networkElementId</mRID>
        <name>RA1-name</name>
        <pSRType.psrType>A06</pSRType.psrType>
        <in_Domain.mRID codingScheme="A01">1------0</in_Domain.mRID>
        <out_Domain.mRID codingScheme="A01">1------0</out_Domain.mRID>
        <marketObjectStatus.status>A26</marketObjectStatus.status>
        <resourceCapacity.maximumCapacity>33.0</resourceCapacity.maximumCapacity>
        <resourceCapacity.minimumCapacity>1.0</resourceCapacity.minimumCapacity>
        <resourceCapacity.unitSymbol>C62</resourceCapacity.unitSymbol>
      </RegisteredResource>
    </RemedialAction_Series>
          ...
</Series>

PST Range Actions have a unique RegisteredResource with A06 psrType, that stands for phase shift transformer. They can be defined with a range, rangeType being specified by the marketObjectStatus and min and max range values being defined by resourceCapacity min and max capacities.

Network Actions

Network actions have one or more registered resources, that represent elementary actions. Each elementary action’s type is defined by its psrType :

  • pst set-point elementary actions have a A06 psrType, that stands for phase shift transformer. They differ from range actions as they have a specific set-point instead of an allowed range. That’s why they have a default capacity tag instead of a minimumCapacity and/or a maximumCapacity tag.
<Series>
    <mRID>RA-Series-1</mRID>
    <businessType>B56</businessType>
    <name>RA_1</name>
    <optimization_MarketObjectStatus.status>Z01</optimization_MarketObjectStatus.status>
    <RemedialAction_Series>
      ...
      <RegisteredResource>
        <mRID codingScheme="A02">networkElementId</mRID>
        <name>RA1-name</name>
        <pSRType.psrType>A06</pSRType.psrType>
        <in_Domain.mRID codingScheme="A01">1------0</in_Domain.mRID>
        <out_Domain.mRID codingScheme="A01">1------0</out_Domain.mRID>
        <marketObjectStatus.status>A25</marketObjectStatus.status>
        <resourceCapacity.defaultCapacity>11</resourceCapacity.defaultCapacity>
        <resourceCapacity.unitSymbol>C62</resourceCapacity.unitSymbol>
        </RegisteredResource>
      ...
      </RemedialAction_Series>
        ...
</Series>
  • injection set-point elementary actions have a A04 or a A05 psrType, that respectively stand for generation and load. In a similar way to pst set-points, injection set-points do not have a minimumCapacity nor a maximumCapacity, but they have a defaultCapacity when the marketObjectStatus is A26 (stands for ABSOLUTE) with unitSymbol MAW. The marketObjectStatus may also be A23 for STOP. In that case, no defaultCapacity may be present.
<Series>
    <mRID>RA-Series-1</mRID>
    <businessType>B56</businessType>
    <name>RA_1</name>
    <optimization_MarketObjectStatus.status>Z01</optimization_MarketObjectStatus.status>
    <RemedialAction_Series>
      ...
      <RegisteredResource>
        <mRID codingScheme="A02">networkElementId</mRID>
        <name>RA1-name</name>
       <pSRType.psrType>A04</pSRType.psrType>
        <in_Domain.mRID codingScheme="A01">10YPT-XXX------W</in_Domain.mRID>
        <out_Domain.mRID codingScheme="A01">10YPT-XXX------W</out_Domain.mRID>
        <marketObjectStatus.status>A26</marketObjectStatus.status>
        <resourceCapacity.defaultCapacity>100</resourceCapacity.defaultCapacity>
        <resourceCapacity.unitSymbol>MAW</resourceCapacity.unitSymbol>
        </RegisteredResource>
      ...
      </RemedialAction_Series>
        ...
</Series>
  • topological elementary actions have a A01, AO2, A07 or a B24 psrType, that respectively stand for tie-line, line, circuit breaker and transformer. In a similar way to other elementary actions, topological elementary actions do not have a minimumCapacity nor a maximumCapacity. Since they aren’t defined by a set-point, they don’t have a defaultCapacity either. They are entirely defined by the marketObjectStatus : A21 for OPEN, and A22 for CLOSE.
<Series>
    <mRID>RA-Series-1</mRID>
    <businessType>B56</businessType>
    <name>RA_1</name>
    <optimization_MarketObjectStatus.status>Z01</optimization_MarketObjectStatus.status>
    <RemedialAction_Series>
      ...
      <RegisteredResource>
        <mRID codingScheme="A02">networkElementId</mRID>
        <name>RA1-name</name>
        <pSRType.psrType>A07</pSRType.psrType>
        <in_Domain.mRID codingScheme="A01">10YES-XXX------0</in_Domain.mRID>
        <out_Domain.mRID codingScheme="A01">10YES-XXX------0</out_Domain.mRID>
        <marketObjectStatus.status>A22</marketObjectStatus.status>
        </RegisteredResource>
      ...
      </RemedialAction_Series>
        ...
</Series>

A network action is imported if all of its elementary actions are imported.

HVDC Range Actions

In the CIM CRAC format as it is actually used, the HVDC remedial action is defined in two separate remedial actions, each representing one direction:

  • the first RemedialAction_Series is a range action in the A -> B direction, with 0 to XXX MW available.
  • the second RemedialAction_Series is a range action in the B -> A direction, with 0 to XXX MW available.

Each of these RemedialAction_Series can contain 4 RegisteredResources, allowing to use 2 HVDC lines as a remedial action group (i.e. setting both lines to same set-point):

  • the first RegisteredResource sets the HVDC line #1 to “active power set-point” mode.
  • the second RegisteredResource defines the allowed set-point range on the HVDC line #1.
  • the third RegisteredResource sets the HVDC line #2 to “active power set-point” mode.
  • the fourth RegisteredResource defines the allowed set-point range on the HVDC line #2.

In the end, two HVDC range actions with an absolute range of -XXX MW to XXX MW each are defined, on both HVDC lines. These HVDC range actions are aligned, i.e. they share the same group ID. That means that they must have the same set-point.

Special rules

In order to ensure the imported CRAC is usable in the RAO, FARAO implements the following special rules:

  • Hybrid (range + binary) remedial actions are prohibited.