35.23Schedule D – Market-to-Market Coordination Process – Version 1.0

NYISO & PJM
Market-to-Market Coordination Schedule
Table of Contents

1Overview of the Market-to-Market Coordination Processes

2Flowgates

3Flowgate Studies 

4Removal of Flowgates from M2M Coordination Processes

5Market Flow Determination

5.1Determine Shift Factors for M2M Redispatch Flowgates and Other Coordinated Flowgates

5.2Compute RTO Load Served by RTO Generation

5.3Compute RTO Generation Serving RTO Load

5.4Compute the RTO GTL for all Flowgates

5.5Compute the RTO Interchange Scheduling Impacts for all Flowgates

5.6Compute the PAR Effects for all Flowgates

5.7Compute the RTO Aggregate Market Flow for all Flowgates

6M2M Entitlement Determination Method

6.1M2M Entitlement Topology Model and Impact Calculation

6.2M2M Entitlement Calculation 

7Real-Time Energy Market Coordination

7.1Real-Time Redispatch Coordination Procedures

7.2Real-Time NY-NJ PAR Coordination

8Real-Time Energy Market Settlements

8.1Information Used to Calculate M2M Settlements

8.2Real-Time Redispatch Settlement

8.3NY-NJ PAR Settlements

8.4Calculating a Combined M2M Settlement

9When One of the RTOs Does Not Have Sufficient Redispatch

10Appropriate Use of the M2M Coordination Process

10.1Qualifying Conditions for M2M Settlement

10.2After-the-Fact Review to Determine M2M Settlement

10.3 Access to Data to Verify Market Flow Calculations

11M2M Change Management Process

11.1Notice

11.2Opportunity to Request Additional Information 

11.3Objection to Change 

11.4Implementation of Change 

1Overview of the Market-to-Market Coordination Processes

The purpose of the M2M coordination processes are to set forth the rules that apply to M2M coordination between PJM and NYISO and the associated settlements processes.

The fundamental philosophy of the PJM/NYISO M2M coordination processes are to set up procedures to allow any transmission constraints that are significantly impacted by generation dispatch changes and/or Phase Angle Regulator (“PAR”) control actions in both markets to be jointly managed in the security-constrained economic dispatch models of both RTOs. This joint management of transmission constraints near the market borders will provide the more efficient and lower cost transmission congestion management solution, while providing coordinated pricing at the market boundaries.

The M2M coordination processes focuses on real-time market coordination to manage transmission limitations that occur on the Flowgates in a more cost effective manner. Coordination between NYISO and PJM will include not only joint redispatch, but will also incorporate coordinated operation of the NY-NJ PARs that are located at the NYISO – PJM interface.  This real-time coordination will result in a more efficient economic dispatch solution across both markets to manage the real-time transmission constraints that impact both markets, focusing on the actual flows in real-time to manage constraints.  Under this approach, the flow entitlements on the M2M Redispatch Flowgates do not impact the physical dispatch; the flow entitlements are used in market settlements to ensure appropriate compensation based on comparison of the actual Market Flows to the flow entitlements.

2Flowgates

Only a subset of all transmission constraints that exist in either market will require coordinated congestion management.  This subset of transmission constraints will be identified as Flowgates.  For the purposes of the M2M coordination process (in addition to the studies described in Section 3 of this Schedule D) the following will be used in determining Flowgates. 

2.1NYISO and PJM will only be performing redispatch or NY-NJ PAR coordination on Flowgates that are under the operational control of NYISO or PJM.  NYISO and PJM will not be performing redispatch or NY-NJ PAR coordination on Flowgates that are owned and controlled by third party entities.

2.2The Parties will make reasonable efforts to lower their generator binding threshold to match the lower generator binding threshold utilized by the other Party.  The generator and NY-NJ PAR binding thresholds (the shift factor thresholds used to identify the resource(s) available to relieve a transmission constraint), will not be set below 3%, except by mutual consent.  This requirement is not an additional criterion for determination of Flowgates.

2.3For the purpose of determining whether a monitored element Flowgate is eligible for redispatch or NY-NJ PAR coordination, a threshold for determining a significant GLDF or NY-NJ PARs PSF will take into account the number of monitored elements.  Implementation of Flowgates will ordinarily occur through mutual agreement.

2.4M2M Redispatch Flowgates and Other Coordinated Flowgates that are eligible for redispatch coordination are also eligible for coordinated operation of the NY-NJ PARs.  Flowgates that are eligible for coordinated operation of the NY-NJ PARs are not necessarily also eligible for redispatch coordination.

2.5The NYISO shall post a list of all of the Flowgates located in the New York Control Area (“NYCA”) on its web site.  PJM shall post a list of all of the Flowgates located in its Control Area on its web site. 

3Flowgate Studies 

To identify Flowgates the Parties will perform an off-line study to determine if there is a significant GLDF for at least one generator within the Non-Monitoring RTO, or significant PSF for at least one NY-NJ PAR, on a potential Flowgate within the Monitoring RTO that is greater than or equal to the thresholds as described below.  The study shall be based on an up-to-date power flow model representation of the Eastern Interconnection, with all normally closed Transmission Facilities in-service.  The transmission modeling assumptions used in the Flowgate studies will be based on the same assumptions used for determining M2M Entitlements in Section 6 of this Schedule D.

3.1Either Party may propose that a new Flowgate be added at any time.  The Parties will work together to perform the necessary studies within a reasonable timeframe.

3.2The GLDF thresholds for a Other Coordinated Flowgate with one or more monitored elements are defined as:

i.Single monitored element, 5% GLDF on any resource;

ii.Two monitored elements, 7.5% GLDF on any resource; and

iii.Three or more monitored elements, 10% GLDF on any resource.

For potential Other Coordinated Flowgates that pass the above GLDF criteria, the Parties must still mutually agree to add each Flowgate for NY-NJ PAR and redispatch coordination. 

3.3The GLDF thresholds for a M2M Redispatch Flowgate with one or more monitored elements are defined as:

i.Single monitored element, 5% GLDF on any Qualified Resource;

ii.Two monitored elements, 7.5% GLDF on any Qualified Resource; and

iii.Three or more monitored elements, 10% GLDF on any Qualified Resource.

For potential M2M Redispatch Flowgates that pass the above GLDF criteria, the Parties must still mutually agree to add each Flowgate for NY-NJ PAR and redispatch coordination.

3.4The NY-NJ PARs PSF thresholds for NY-NJ PAR Coordinated Flowgates with one or more monitored elements are defined as:

1.Single monitored element, 5% NY-NJ PARs PSF;

2.Two monitored elements, 7.5% NY-NJ PARs PSF; and

3.Three or more monitored elements, 10% NY-NJ PARs PSF.

For potential Flowgates that pass the above NY-NJ PARs PSF criteria, the Parties must still mutually agree to add each Flowgate for coordinated operation of the NY-NJ PARs.

3.5The Parties can also mutually agree to add a Flowgate that does not satisfy the above GLDF or PSF criteria.

4Removal of Flowgates from M2M Coordination Processes

Removal of Flowgates from the systems may be necessary under certain conditions including the following:

4.1A Flowgate is no longer valid when (a) a change is implemented that affects either Party’s generation impacts causing the Flowgate to no longer pass the Flowgate Studies, or (b) a change is implemented that affects the impacts from coordinated operation of the NY-NJ PARs causing the Flowgate to no longer pass the Flowgate Studies.  The Parties must still mutually agree to remove a Flowgate, such agreement not to be unreasonably withheld.  Once a Flowgate has been removed, it will no longer be eligible for M2M settlement. 

4.2A M2M Redispatch Flowgate that does not satisfy the criteria set forth in Section 3.3 above, but that is created based on the mutual agreement of the Parties pursuant to Section 3.5 above, shall be removed two weeks after either Party provides a Notice to the other Party that it withdraws its agreement to the M2M Redispatch Flowgate, or at a later or earlier date that the Parties mutually agree upon.  The Notice must include an explanation of the reason(s) why the agreement to the M2M Redispatch Flowgate was withdrawn.

4.3A Other Coordinated Flowgate shall be removed two weeks after either Party provides a Notice to the other party that it withdraws its agreement to the Other Coordinated Flowgate, or at a later or earlier date that the Parties mutually agree upon. The Notice must include an explanation of the reason(s) why the agreement to the Other Coordinated Flowgate was withdrawn.

4.4The Parties can mutually agree to remove a Flowgate whether or not it passes the coordination tests.  A Flowgate should be removed when the Parties agree that the relevant coordination processes are not, or will not be, an effective mechanism to manage congestion on that Flowgate.

5Market Flow Determination

Each RTO will independently calculate its Market Flow for all M2M Redispatch Flowgates and Other Coordinated Flowgates using the equations set forth in this Section.  The Market Flow calculation is broken down into the following steps:

• Determine Shift Factors for M2M Redispatch Flowgates and Other Coordinated Flowgates
• Compute RTO Load and Losses (less imports)
• Compute RTO Generation (less exports)
• Compute RTO Generation to Load impacts on the Market Flow
• Compute RTO interchange scheduling impacts on the Market Flow
• Compute PAR impacts on the Market Flow
• Compute Market Flow

5.1Determine Shift Factors for M2M Redispatch Flowgates and Other Coordinated Flowgates

The first step to determining the Market Flow on a Flowgate is to calculate generator, load and PAR shift factors for the each of the Flowgates.  For real-time coordination, the shift factors will be based on the real-time transmission system topology. 

5.2Compute RTO Load Served by RTO Generation

Using area load and losses for each load zone, compute the RTO Load, in MWs, by summing the load and losses for each load zone to determine the total zonal load for each RTO load zone.  Twenty percent of RECo load shall be included in the Market Flow calculation as PJM load.  See Section 6.2, of this Schedule D.

, for each RTO load zone

Where:

zone =the relevant RTO load zone;

Zonal_Total_Loadzone =the sum of the RTO’s load and transmission losses for the zone;

Loadzone =the load within the zone; and

Losseszone =the transmission losses for transfers through the zone.

Next, reduce the Zonal Loads by the scheduled line real-time import transaction schedules that sink in that particular load zone:

Where:

zone =the relevant RTO load zone;

scheduled_line =each of the Transmission Facilities identified in Table 1 below;

Zonal_Reduced_Loadzone =the sum of the RTO’s load and transmission losses in a zone reduced by the sum of import schedules over scheduled lines to the zone;

Zonal_Total_Loadzone =the sum of the RTO’s load and transmission losses for the zone; and

Import_Schedulesscheduled_line,zone =import schedules over a scheduled line to a zone.

The real-time import schedules over scheduled lines will only reduce the load in the sink load zones identified in Table 1 below:

Table 1.  List of Scheduled Lines

Once import schedules over scheduled lines have been accounted for, it is then appropriate to reduce the net RTO Load by the remaining real-time import schedules at the proxies identified in Table 2 below:

Table 2.  List of Proxies*

*Scheduled lines and proxies are mutually exclusive.  Transmission Facilities that are components of a scheduled line are not also components of a proxy (and vice-versa).

Where:

zone =the relevant RTO load zone;

RTO_Net_Load =the sum of load and transmission losses for the entire RTO footprint reduced by the sum of import schedules over all scheduled lines; and

Zonal_Reduced_Loadzone =the sum of the RTO’s load and transmission losses in a zone reduced by the sum of import schedules over scheduled lines to the zone.

Where:

proxy =representations of defined sets of Transmission Facilities that (i) interconnect neighboring Balancing Authorities, (ii) are collectively scheduled, and (iii) are identified in Table 2 above;

RTO_Final_Load =the sum of the RTO’s load and transmission losses for the entire RTO footprint, sequentially reduced by (i) the sum of import schedules over all scheduled lines, and (ii) the sum of all proxy import schedules;

RTO_Net_Load =the sum of load and transmission losses for the entire RTO footprint reduced by the sum of import schedules over all scheduled lines; and

Import_Schedulesproxy =the sum of import schedules at a given proxy.

Next, calculate the Zonal Load weighting factor for each RTO load zone:

Where:

zone =the relevant RTO load zone;

Zonal_Weightingzone =the percentage of the RTO’s load contained within the zone;

RTO_Net_Load =the sum of load and transmission losses for the entire RTO footprint reduced by the sum of import schedules over all scheduled lines; and

Zonal_Reduced_Loadzone =the sum of the RTO’s load and transmission losses in a zone reduced by the sum of import schedules over scheduled lines to the zone.

Using the Zonal Weighting Factor compute the zonal load reduced by RTO imports for each load zone:

Where:

zone =the relevant RTO load zone;

Zonal_Final_Loadzone =the final RTO load served by internal RTO generation in the zone;

Zonal_Weightingzone =the percentage of the RTO’s load contained within the zone; and

RTO_Final_Load =the sum of the RTO’s load and transmission losses for the entire RTO footprint, sequentially reduced by (i) the sum of import schedules over all scheduled lines, and (ii) the sum of all proxy import schedules.

Using the Load Shift Factors (“LSFs”) calculated above, compute the weighted RTOLSF for each Flowgate as:

Where:

Flowgate-m =the relevant flowgate;

zone =the relevant RTO load zone;

RTO_LSFFlowgate-m =the load shift factor for the entire RTO footprint on Flowgate m;

LSF(zone,Flowgate-m) =the load shift factor for the RTO zone on Flowgate m;

Zonal_Final_Loadzone =the final RTO load served by internal RTO generation in the zone; and

RTO_Final_Load =the sum of the RTO’s load and transmission losses for the entire RTO footprint, sequentially reduced by (i) the sum of import schedules over all scheduled lines, and (ii) the sum of all proxy import schedules.

5.3Compute RTO Generation Serving RTO Load

Using the real-time generation output in MWs, compute the Generation serving RTO Load.  Sum the output of RTO generation within each load zone:

, for each RTO load zone

Where:

zone =the relevant RTO load zone;

unit =the relevant generator;

RTO_Genzone =the sum of the RTO’s generation in a zone; and

Genunit,zone =the real-time output of the unit in a given zone.

Next, reduce the RTO generation located within a load zone by the scheduled line real-time export transaction schedules that source from that particular load zone:

Where:

zone =the relevant RTO load zone;

scheduled_line =each of the Transmission Facilities identified in Table 1 above;

RTO_Reduced_Genzone =the sum of the RTO’s generation in a zone reduced by the sum of export schedules over scheduled lines from the zone;

RTO_Genzone =the sum of the RTO’s generation in a zone; and

Export_Schedulesscheduled_line,zone =export schedules from a zone over a scheduled line.

The real-time export schedules over scheduled lines will only reduce the generation in the source zones identified in Table 1 above.  The resulting generator output based on this reduction is defined below.

Where:

unit =the relevant generator;

zone =the relevant RTO load zone;

Genunit,zone =the real-time output of the unit in a given zone;

Reduced Genunit =each unit’s real-time output after reducing the RTO_Net_Gen by the real-time export schedules over scheduled lines;

RTO_Reduced_Genzone =the sum of the RTO’s generation in a zone reduced by the sum of export schedules over scheduled lines from the zone; and

RTO_Genzone =the sum of the RTO’s generation in a zone.

Once export schedules over scheduled lines are accounted for, it is then appropriate to reduce the net RTO generation by the remaining real-time export schedules at the proxies identified in Table 2 above.

Where:

zone =the relevant RTO load zone;

RTO_Net_Gen =the sum of the RTO’s generation reduced by the sum of export schedules over all scheduled lines; and

RTO_Reduced_Genzone =the sum of the RTO’s generation in a zone reduced by the sum of export schedules over scheduled lines from the zone.

Where:

proxy =representation of defined sets of Transmission Facilities that (i) interconnect neighboring Balancing Authorities, (ii) are collectively scheduled, and (iii) are identified in Table 2 above;

RTO_Final_Gen =the sum of the RTO’s generation output for the entire RTO footprint, sequentially reduced by (i) the sum of export schedules over all scheduled lines, and (ii) the sum of all proxy export schedules;

RTO_Net_Gen =the sum of the RTO’s generation reduced by the sum of export schedules over all scheduled lines; and

Export_Schedulesproxy =the sum of export schedules at a given proxy.

Finally, weight each generator’s output by the reduced RTO generation:

Where:

unit =the relevant generator;

Gen_Finalunit =the portion of each unit’s output that is serving the RTO Net Load;

Reduced Genunit =each unit’s real-time output after reducing the RTO_Net_Gen by the real-time export schedules over scheduled lines;

RTO_Final_Gen =the sum of the RTO’s generation output for the entire RTO footprint, sequentially reduced by (i) the sum of export schedules over all scheduled lines, and (ii) the sum of all proxy export schedules; and

RTO_Net_Gen =the sum of the RTO’s generation reduced by the sum of export schedules over all scheduled lines.

5.4Compute the RTO GTL for all Flowgates

The generation-to-load flow for a particular Flowgate, in MWs, will be determined as:

Where:

Flowgate-m =the relevant flowgate;

unit =the relevant generator;

RTO_GTLFlowgate-m =the generation to load flow for the entire RTO footprint on Flowgate m;

Gen_Finalunit =the portion of each unit’s output that is serving RTO Net Load;

GSF(unit,Flowgate-m) =the generator shift factor for each unit on Flowgate m; and

RTO_LSFFlowgate-m =the load shift factor for the entire RTO footprint on Flowgate m.

5.5Compute the RTO Interchange Scheduling Impacts for all Flowgates

For each scheduling point that the participating RTO is responsible for, determine the net interchange schedule in MWs.  Table 3 below identifies both the participating RTO that is responsible for each listed scheduling point, and the “type” assigned to each listed scheduling point.

Table 3.  List of Scheduling Points

Where:

sched_pt =the relevant scheduling point.  A scheduling point can be either a proxy or a scheduled line;

RTO_Transferssched_pt =the net interchange schedule at a scheduling point;

Importssched_pt =the import component of the interchange schedule at a scheduling point;

WheelsInsched_pt =the injection of wheels-through component of the interchange schedule at a scheduling point;

Exportssched_pt =the export component of the interchange schedule at a scheduling point; and

WheelsOutsched_pt =the withdrawal of wheels-through component of the interchange schedule at a scheduling point.

The equation below applies to all non-common scheduling points that only one of the participating RTOs is responsible for.  Parallel_Transfers are applied to the Market Flow of the responsible participating RTO.  For example, the Parallel_Transfers computed for the IESO-NYISO non-common scheduling point are applied to the NYISO Market Flow.

Where:

Flowgate-m =the relevant flowgate;

nc_sched_pt =the relevant non-common scheduling point.  A non-common scheduling point can be either a proxy or a scheduled line.  Non-common scheduling points are identified in Table 3, above;

Parallel_TransfersFlowgate-m =the flow on Flowgate m due to the net interchange schedule at the non-common scheduling point;

RTO_Transfersnc_sched_pt =the net interchange schedule at the non-common scheduling point, where a positive number indicates the import direction; and

PTDF(nc_sched_pt, Flowgate-m) =the power transfer distribution factor of the non-common scheduling point on Flowgate m.  For NYISO, the PTDF will equal the generator shift factor of the non-common scheduling point.

The equation below applies to common scheduling points that directly interconnect the participating RTOs.  Shared_Transfers are applied to the Monitoring RTO’s Market Flow only.  NYISO to PJM transfers would be considered part of NYISO’s Market Flow for NYISO-monitored Flowgates and part of PJM’s Market Flow for PJM-monitored Flowgates.

Where:

Flowgate-m =the relevant flowgate;

cmn_sched_pt =the relevant common scheduling point.  A common scheduling point can be either a proxy or a scheduled line.  Common scheduling points are identified in Table 3, above;

Shared_TransfersFlowgate-m =the flow on Flowgate m due to interchange schedules on the common scheduling point;

RTO_Transferscmn_sched_pt =the net interchange schedule at a common scheduling point, where a positive number indicates the import direction; and

PTDF(cmn_sched_pt,Flowgate-m) =the generation shift factor of the common scheduling point on Flowgate m.  For NYISO, the PTDF will equal the generator shift factor of the common scheduling point.

5.6Compute the PAR Effects for all Flowgates

For the PARs listed in Table 4 below, the RTOs will determine the generation-to-load flows and interchange schedules, in MWs, that each PAR is impacting.

Table 4.  List of Phase Angle Regulators

*Pursuant to the rules for implementing the M2M coordination process over the NY-NJ PARs that are set forth in this M2M Schedule.

Compute the PAR control as the actual flow less the target flow across each PAR:

Where:

par =each of the phase angle regulators listed in Table 4, above;

PAR_Controlpar =the flow deviation on each of the PARs;

Actual_MWpar =the actual flow on each of the PARs, determined consistent with Table 4 above; and

Target_MWpar =the target flow that each of the PARs should be achieving, determined in accordance with Table 4 above.

When the Actual_MW and Target_MW are both set to “From telemetry” in Table 4 above, the PAR_Control­ will equal zero.

Common PARs

In the equations below, the Non-Monitoring RTO is credited for or responsible for PAR_Impact resulting from the common PAR effect on the Monitoring RTO’s Flowgates.  The common PAR impact calculation only applies to the common PARs identified in Table 4 above. 

Compute control deviation for all common PARs on Flowgate m based on the PAR_Controlpar MWs calculated above:

Where:

Flowgate-m =the relevant flowgate;

cmn_par =each of the common phase angle regulators, modeled as Flowgates, identified in Table 4, above;

Cmn_PAR_ControlFlowgate-m =the sum of flow on Flowgate m after accounting for the operation of common PARs;

PSF(cmn_par,Flowgate-m) =the PSF of each of the common PARs on Flowgate m; and

PAR_Controlcmn_par =the flow deviation on each of the common PARs.

Compute the impact of generation-to-load and interchange schedules across all common PARs on Flowgate m as the Market Flow across each common PAR multiplied by that PAR’s shift factor on Flowgate m:

Where:

Flowgate-m =the relevant flowgate;

cmn_par =the set of common phase angle regulators, modeled as Flowgates, identified in Table 4 above;

Cmn_PAR_MFFlowgate-m =the sum of flow on Flowgate m due to the generation to load flows and interchange schedules on the common PARs;

PSF(cmn_par,Flowgate-m) =the PSF of each of the common PARs on Flowgate m;

RTO_GTLcmn_par =the generation to load flow for each common par, computed in the same manner as the generation to load flow is computed for Flowgates in Section 5.4 above; and

Parallel_Transferscmn_par =the flow on each of the common PARs caused by interchange schedules at non-common scheduling points.

Next, compute the impact of the common PAR effect for Flowgate m as:

Where:

Flowgate-m =the relevant flowgate;

Cmn_PAR_ImpactFlowgate-m =potential flow on Flowgate m that is affected by the operation of the common PARs;

Cmn_PAR_MFFlowgate-m =the sum of flow on Flowgate m due to the generation to load and interchange schedules on the common PARs; and

Cmn_PAR_ControlFlowgate-m =the flow deviation on each of the common PARs.

Non-Common PARs

For the equations below, the NYISO will be credited or responsible for PAR_Impact on all Flowgates because the NYISO is the participating RTO that has input into the operation of these devices.  The non-common PAR impact calculation only applies to the non-common PARs identified in Table 4 above. 

Compute control deviation for all non-common PARs on Flowgate m based on the PAR control MW above:

Where:

Flowgate-m =the relevant flowgate;

nc_par =each of the non-common phase angle regulators, modeled as Flowgates, identified in Table 4 above;

NC_PAR_ControlFlowgate-m =the sum of flow on Flowgate m after accounting for the operation of non-common PARs;

PSF(nc_par,Flowgate-m) =the PSF of each of the non-common PARs on Flowgate m; and

PAR_Controlnc_par =the flow deviation on each of the non-common PARs.

Compute the impact of generation-to-load and interchange schedules across all non-common PARs on Flowgate m as the Market Flow across each PAR multiplied by that PAR’s shift factor on Flowgate m:

Where:

Flowgate-m =the relevant flowgate;

nc_par =the set of non-common phase angle regulators, modeled as Flowgates, identified in Table 4 above;

NC_PAR_MFFlowgate-m =the sum of flow on Flowgate m due to the generation to load flows and interchange schedules on the non-common PARs;

PSF(nc_par,Flowgate-m) =the outage transfer distribution factor of each of the non-common PARs on Flowgate m;

RTO_GTLnc_par =the generation to load flow for each non-common par, computed in the same manner as the generation to load flow is computed for Flowgates in Section 5.4 above; and

Parallel_Transfersnc_par =the flow, as computed above where the Flowgate m is one of the non-common PARs, on each of the non-common PARs caused by interchange schedules at non-common scheduling points.

Next, compute the non-common PAR impact for Flowgate m as:

Where:

Flowgate-m =the relevant flowgate;

NC_PAR_ImpactFlowgate-m =the potential flow on Flowgate m that is affected by the operation of non-common PARs;

NC_PAR_MFFlowgate-m =the sum of flow on Flowgate m due to the generation to load and interchange schedules on the non-common PARs; and

NC_PAR_ControlFlowgate-m =the sum of flow on Flowgate m after accounting for the operation of non-common PARs.

Aggregate all PAR Effects for Each Flowgate

The total impacts from the PAR effects for Flowgate m is:

Where:

Flowgate-m =the relevant flowgate;

PAR_ImpactFlowgate-m =the flow on Flowgate m that is affected after accounting for the operation of both common and non-common PARs;

Cmn_PAR_ImpactFlowgate-m =potential flow on Flowgate m that is affected by the operation of the common PARs; and

NC_PAR_ImpactFlowgate-m =the potential flow on Flowgate m that is affected by the operation of non-common PARs.

5.7Compute the RTO Aggregate Market Flow for all Flowgates

With the RTO_GTL and PAR_IMPACT known, we can now compute the RTO_MF for all Flowgates as:

Where:

Flowgate-m =the relevant flowgate;

RTO_MFFlowgate-m = the Market Flow caused by RTO generation dispatch and

transaction scheduling on Flowgate m after accounting for the operation of both the common and non-common PARs;

RTO_GTLFlowgate-m =the generation to load flow for the entire RTO footprint on Flowgate m;

Parallel_TransfersFlowgate-m =the flow on Flowgate m caused by interchange schedules that are not jointly scheduled by the participating RTOs;

Shared_TransfersFlowgate-m =the flow on Flowgate m caused by interchange schedules that are jointly scheduled by the participating RTOs; and

PAR_ImpactFlowgate-m =the flow on Flowgate m that is affected after accounting for the operation of both the common and non-common PARs.

6M2M Entitlement Determination Method

M2M Entitlements are the equivalent of financial rights for the Non-Monitoring RTO to use the Monitoring RTO’s transmission system within the confines of the M2M redispatch process.  The Parties worked together to develop the M2M Entitlement determination method set forth below. 

Each Party shall calculate a M2M Entitlement on each M2M Redispatch Flowgate and compare the results at least once a year on a mutually agreed upon schedule.  This frequency ensures that the impact of upgrades on both parties systems are incorporated into the M2M Entitlement calculation.  The parties may mutually agree to not recalculate M2M Entitlements in a given year.

6.1M2M Entitlement Topology Model and Impact Calculation

The M2M Entitlement calculation shall use both RTOs’ static topological models to determine the Non-Monitoring RTO’s mutually agreed upon share of a M2M Redispatch Flowgate’s total capacity based on historic dispatch patterns.  Both RTOs’ models must include the following items:

1. a static transmission and generation model;
2. generator, load, and PAR shift factors;
3. generator output, load, and interchange schedules from the most recently completed three calendar years;
4. a PAR impact assumption that the PAR control is perfect for all PARs within the  transmission models except the PARs at the Michigan-Ontario border;
5. new or upgraded Transmission Facilities; and
6. Transmission Facility retirements.

Each Party shall calculate the GLDFs using a transmission model that contains a mutually agreed upon set of: (1) transmission lines that are modeled as in-service; (2) generators; and (3) loads.  Using these GLDFs, generator output data from the three year period agreed to by the Parties, and load data from the three year period agreed to by the Parties, the Parties shall calculate each Party’s MW impact on each M2M Redispatch Flowgate for each hour in the three year period agreed to by the Parties.    

Using these impacts, the Parties shall create a reference year consisting of twelve periods (“M2M Entitlement Periods”) for each M2M Redispatch Flowgate.  The M2M Entitlement Periods are as follows:

1. M2M Entitlement Period 1: January;
2. M2M Entitlement Period 2: February;
3. M2M Entitlement Period 3: March;
4. M2M Entitlement Period 4: April;
5. M2M Entitlement Period 5: May;
6. M2M Entitlement Period 6: June;
7. M2M Entitlement Period 7: July;
8. M2M Entitlement Period 8: August;
9. M2M Entitlement Period 9: September;
10. M2M Entitlement Period 10: October;
11. M2M Entitlement Period 11: November;
12. M2M Entitlement Period 12: December;

For each of the M2M Entitlement Periods listed above the Non-Monitoring RTO will calculate its M2M Entitlement on each M2M Redispatch Flowgate for four groups of hours, the grouping is described below.

1. M2M Entitlement Group 1: Hour beginning 0 through hour beginning 5;
2. M2M Entitlement Group 2: Hour beginning 9 through hour beginning 14;
3. M2M Entitlement Group 3: Hour beginning 15 through hour beginning 20 and;
4. M2M Entitlement Group 4: Hour beginning 6 through hour beginning 8 and hour beginning 21 through hour beginning 23.

The M2M Entitlement for each period/group, for each M2M Redispatch Flowgate will be calculated by averaging the Non-Monitoring RTO’s Market Flow on an M2M Redispatch Flowgate for each particular period/group.  The Non-Monitoring RTO shall use the Market Flow data for all of the like period/groups, in each year contained within the three year period to calculate the Non-Monitoring RTO’s average Market Flow on each M2M Redispatch Flowgate.  The data within the three year period will be weighted as follows: most recent year 20%, middle year 30%, and oldest year 50%.  In addition, the M2M Entitlement values should never extend beyond a facility’s rating. If the calculation derives an entitlement that is above the facility’s rating the parties will cap the entitlement value to remain within the facility’s rating.

If either of the below upgrade scenarios occur the Parties may mutually agree to adjust the M2M Entitlement calculation method to account for the impacts of the upgrade(s):

1. If the Non-Monitoring RTO upgrades the Monitoring RTO’s system resulting in a rating increase; or
2. If the Non-Monitoring RTO’s market flow on the Monitoring RTO’s system decreases due to a Non-Monitoring RTO upgrade on the Non-Monitoring RTO’s system.

6.2M2M Entitlement Calculation

Each Party shall independently calculate the Non-Monitoring RTO’s M2M Entitlement for all M2M Redispatch Flowgates using the equations set forth in this Section.  The Parties shall mutually agree upon M2M Entitlement calculations.  Any disputes that arise in the M2M Entitlement calculations will be resolved in accordance with the dispute resolution procedures set forth in Section 35.15 of this Agreement. 

Eighty percent of the RECo load shall be excluded from the calculation of Market Flows and M2M Entitlements, and shall instead be reflected as a PJM obligation over the Ramapo PARs in accordance with Sections 7.2.1 and 8.3 of this Schedule D.  The remaining twenty percent of RECo load shall be included in the M2M Entitlement and Market Flow calculations as PJM load. 

The following assumptions apply to the M2M Entitlement calculation:

1. the Parties shall calculate the values in this Section using the M2M Entitlement Topology Model discussed in Section 6.1 above, unless otherwise stated;
2. the impacts from the Parallel_Transfers and Shared_Transfers terms of the Market Flow calculation (see Section 5.5) are excluded from the Market Flow that is used to calculate M2M Entitlements;
3. perfect PAR Control exists for all PARs within the transmission models except the PARs at the Ontario/Michigan border; and
4. External Capacity Resources may be included in the calculation of M2M Entitlements consistent with Section 6.2.1.1 of this Schedule D.

Once the Reference Year Market Flows have been calculated for each interval to determine the integrated hourly Market Flow for each hour of the relevant three year period agreed to by the Parties, the new M2M Entitlement will be determined for all M2M Entitlement Groups in each M2M Entitlement Period using the method established in Section 6.1 above.

6.2.1Treatment of Out-of-Area Capacity Resources and Representation of Ontario/Michigan PARs in the M2M Entitlement Calculation Process

6.2.1.1Modeling of External Capacity Resources

External Capacity Resources may be included in the M2M Entitlement calculation to the extent the Parties mutually agree to their inclusion. 

For the initial implementation of this M2M coordination process that will use 2009 through 2011 data to develop M2M Entitlements, PJM will be permitted to include its External Capacity Resources in the M2M Entitlement calculation.  NYISO has not requested inclusion of any External Capacity Resources in the M2M Entitlement calculation for the initial implementation of M2M.  When the Parties decide to update the data used to determine M2M Entitlements:

a.PJM will be permitted to include External Capacity Resources that have an equivalent net M2M Entitlement impact to the net M2M Entitlement impact of the PJM External Capacity Resources that were used for the initial implementation of the M2M coordination process.  Inclusion of PJM External Capacity Resources that exceed the net M2M Entitlement impact of the PJM External Capacity Resources that were used for the initial implementation of the M2M coordination process must be mutually agreed to by the Parties.

b.The Parties may mutually agree to permit the NYISO to include External Capacity Resources in the M2M Entitlement calculation.

6.2.1.2Modeling of the Ontario/Michigan PARs

The Ontario/Michigan PARs will be modeled as not controlling power flows in the M2M Entitlement calculation process.  The Parties agree that this modeling treatment is only appropriate when it is paired with the rules for calculating Market Flows and M2M settlements that are set forth in Sections 5 and 8 of this Agreement.  Section 7.1 specifies how the RTOs will adjust Market Flows to account for the impact of the operation of the Ontario/Michigan PARs when the PARs are in service.  The referenced Market Flow and M2M settlement rules are necessary because they are designed to ensure that M2M settlement obligations based on M2M Entitlements and Market Flows will not result in compensation for M2M redispatch when no actual M2M redispatch occurs.

7Real-Time Energy Market Coordination

Operation of the NY-NJ PARs and redispatch are used by the Parties in real-time operations to effectuate this M2M coordination process.  Operation of the NY-NJ PARs will permit the Parties to redirect energy to reduce the overall cost of managing transmission congestion and to converge the participating RTOs’ cost of managing transmission congestion.    Operation of the NY-NJ PARs to manage transmission congestion requires cooperation between the NYISO and PJM.  Operation of the NY-NJ PARs shall be coordinated by the RTOs.

When a M2M Redispatch Flowgate or Other Coordinated Flowgate begins binding in the Monitoring RTOs real-time security constrained economic dispatch, the Monitoring RTO will notify the Non-Monitoring RTO of the transmission constraint and will identify the appropriate Flowgate that requires redispatch assistance. The Monitoring and Non-Monitoring RTOs will provide the economic value of the Flowgate constraint (i.e., the Shadow Price) as calculated by their respective dispatch models. Using this information, the security-constrained economic dispatch of the Non-Monitoring RTO will include the Flowgate constraint; the Monitoring RTO will evaluate the actual loading of the Flowgate constraint and request that the Non-Monitoring RTO modify its Market Flow via redispatch if it can do so more efficiently than the Monitoring RTO (i.e., if the Non-Monitoring RTO has a lower Shadow Price for that Flowgate than the Monitoring RTO).

An iterative coordination process will be supported by automated data exchanges in order to ensure the process is manageable in a real-time environment.  The process of evaluating the Shadow Prices between the RTOs will continue until the Shadow Prices converge and an efficient redispatch solution is achieved.  The continual interactive process over the following dispatch cycles will allow the transmission congestion to be managed in a coordinated, cost-effective manner by the RTOs. A more detailed description of this iterative procedure is discussed in Section 7.1 and the appropriate use of this iterative procedure is described in Section 10.

7.1Real-Time Redispatch Coordination Procedures

The following procedure will apply for managing redispatch for M2M Redispatch Flowgates and Other Coordinated Flowgates in the real-time Energy market:

7.1.1Flowgates shall be monitored per each RTO’s internal procedures.

1. When (i) a Flowgate is constrained to a defined limit (actual or contingency flow) by a non-transient constraint, and (ii) Market Flows are such that the Non-Monitoring RTO may be able to provide an appreciable amount of redispatch relief to the Monitoring RTO for a M2M Redispatch Flowgate, or (iii) the Non-Monitoring RTO agrees to initiate and to continue coordination for a M2M Redispatch Flowgate or Other Coordinated Flowgate, then the Monitoring RTO shall reflect the monitored Flowgate as constrained.

2. Flowgate limits shall be periodically verified and updated.

7.1.2Testing for an Appreciable Amount of Redispatch Relief and Determining the Settlement Market Flow for M2M Redispatch Flowgates:

When the PARs at the Michigan-Ontario border are not in-service, the ability of the Non-Monitoring RTO to provide an appreciable amount of redispatch relief will be determined by comparing the Non-Monitoring RTO’s Market Flow to the Non-Monitoring RTO M2M Entitlement for the constrained M2M Redispatch Flowgate.  When the Non-Monitoring RTO Market Flow (also the Market Flow used for settlement) is greater than the Non-Monitoring RTO M2M Entitlement for the constrained M2M Redispatch Flowgate, the Monitoring RTO will assume that an appreciable amount of redispatch relief is available from the Non-Monitoring RTO and will engage the redispatch coordination process for the constrained M2M Redispatch Flowgate.

When any of the PARs at the Michigan-Ontario border are in-service, the ability of the Non-Monitoring RTO to provide an appreciable amount of redispatch relief will be determined by comparing either (i) the Non-Monitoring RTO’s unadjusted Market Flow, or (ii) the Non-Monitoring RTO Market Flow adjusted to reflect the expected impact of the PARs at the Michigan-Ontario border (“LEC Adjusted Market Flow”), to the Non-Monitoring RTO M2M Entitlement for the constrained M2M Redispatch Flowgate.  The rules for determining which Market Flow (unadjusted or adjusted) to compare to the Non-Monitoring RTO M2M Entitlement when any of the PARs at the Michigan-Ontario border are in-service are set forth below.

a.Calculating the Expected Impact of the PARs at the Michigan-Ontario Border on Market Flows

The Non-Monitoring RTO’s unadjusted Market Flow is determined as RTO_MF in accordance with the calculation set forth in Section 5 above.  The expected impact of the PARs at the Michigan-Ontario border is determined as follows:

Where:

Flowgate-m =the relevant Flowgate;

MICH-OH Path =each of the four PAR paths connecting Michigan to Ontario, Canada;

MICH-OH_PAR_ImpactFlowgate-m =the expected impact of the operation of the PARs at the Michigan-Ontario border on the flow on Flowgate m;

PSF(MICH-OH Path,Flowgate-m) =the PSF of each of the four Michigan-Ontario PAR paths on Flowgate m;

RTO_MFMICH-OH Path =the Market Flow for each of the four Michigan-Ontario PAR paths, computed in the same manner as the Market Flow is computed for Flowgates in Section 5 above; and

LEC = Actual circulation around Lake Erie as measured by each RTO.

The Non-Monitoring RTO’s LEC Adjusted Market Flow, reflecting the expected impact of the PARs on the Michigan-Ontario border, can be determined by adjusting the RTO_MF from Section 5 to incorporate the MICH-OH_PAR_Impact calculated above.

Where:

Flowgate-m =the relevant flowgate;

MICH-OH Path =each of the four PAR paths connecting Michigan to Ontario, Canada;

MICH-OH_PAR_ImpactFlowgate-m =the expected impact of the operation of the PARs at the Michigan-Ontario border on the flow on Flowgate m;

RTO_MFFlowgate-m = the Market Flow caused by RTO generation dispatch and transaction scheduling on Flowgate m after accounting for the operation of both the common and non-common PARs; and

LEC Adjusted Market FlowFlowgate-m = the Market Flow caused by RTO generation dispatch and transaction scheduling on Flowgate m after accounting for the operation of the common PARs, the non-common PARs, and the PARs at the Michigan-Ontario border.

b.Determining Whether to Use Unadjusted Market Flow or LEC Adjusted Market Flow; Determining if Appreciable Redispatch Relief is Available

1)     When the Non-Monitoring RTO’s LEC Adjusted Market Flow equals the Non-Monitoring RTO’s unadjusted Market Flow and the Non-Monitoring RTO’s Market Flow (also the Market Flow used for settlement) is greater than the Non-Monitoring RTO M2M Entitlement for the constrained M2M Redispatch Flowgate, the Monitoring RTO will assume that an appreciable amount of redispatch relief is available from the Non-Monitoring RTO and will engage the M2M coordination process for the constrained M2M Flowgate.

2)     When the Non-Monitoring RTO’s unadjusted Market Flow is greater than the Non-Monitoring RTO’s LEC Adjusted Market Flow, then the following calculation shall be performed to determine if an appreciable amount of redispatch relief is expected to be available:

1. Determine the minimum of (a) the Non-Monitoring RTO’s unadjusted Market Flow, and (b) the Non-Monitoring RTO’s M2M Entitlement, for the constrained M2M Redispatch Flowgate; and

2. Determine the maximum of (x) the value from step A above, and (y) the Non-Monitoring RTO’s LEC Adjusted Market Flow

When the value from B above (the Market Flow used for settlement), is greater than the Non-Monitoring RTO’s M2M Entitlement for the constrained M2M Redispatch Flowgate, the Monitoring RTO will assume that an appreciable amount of redispatch relief is available from the Non-Monitoring RTO and will engage the coordination process for the constrained M2M Redispatch Flowgate.

3)     When the Non-Monitoring RTO’s unadjusted Market Flow is less than the Non-Monitoring RTO LEC Adjusted Market Flow, the following calculation shall be performed to determine if an appreciable amount of redispatch relief is expected to be available:

1. Determine the maximum of (a) the Non-Monitoring RTO’s unadjusted Market Flow, and (b) the Non-Monitoring RTO M2M Entitlement, for the constrained M2M Redispatch Flowgate; and

2. Determine the minimum of (x) the value from A above, and (y) the Non-Monitoring RTO’s LEC Adjusted Market Flow

When the value from B above (the Market Flow used for settlement), is greater than the Non-Monitoring RTO’s M2M Entitlement for the constrained M2M Redispatch Flowgate, the Monitoring RTO will assume that an appreciable amount of redispatch relief is available from the Non-Monitoring RTO and will engage the coordination process for the constrained M2M Redispatch Flowgate.

7.1.3The Monitoring RTO initiates redispatch coordination, notifies the Non-Monitoring RTO of the M2M Redispatch Flowgates or Other Coordinated Flowgates that are subject to coordination and updates required information.

7.1.4The Non-Monitoring RTO shall acknowledge receipt of the notification and one of the following shall occur: 

1. The Non-Monitoring RTO refuses to activate redispatch coordination:
   1. The Non-Monitoring RTO notifies the Monitoring RTO of the reason for refusal; and
   2. The M2M State is set to “Refused”; or
2. The Non-Monitoring RTO agrees to activate redispatch coordination:
   1. Such an agreement shall be considered an initiation of the redispatch process; and
   2. The M2M State is set to “Activated”.
   3. If the Non-Monitoring RTO later withdraws its agreement to activate redispatch coordination at a Flowgate, then the Non-Monitoring RTO notifies the Monitoring RTO of the reason for its decision and the Monitoring RTO shall terminate the redispatch coordination process and set the M2M State to “Refused”.

7.1.5The Parties have agreed to transmit information required for the administration of this procedure, as per Section 35.7.1 of this Agreement.

7.1.6As Shadow Prices converge and approach zero or the Non-Monitoring RTO’s Market Flows and Shadow Prices are such that an appreciable amount of redispatch relief can no longer be provided to the Monitoring RTO, the Monitoring RTO shall be responsible for the continuation or termination of the redispatch process.  Current and forecasted future system conditions shall be considered. Termination of redispatch coordination may be requested by either RTO in the event of a system emergency.

When the Monitoring RTO’s Shadow Price is not approaching zero the Monitoring RTO can (1) use the procedure called Testing for an Appreciable Amount of Relief and Determining the Settlement Market Flow from step 2b above, and (2) compare the Non-Monitoring RTO’s Shadow Price to the Monitoring RTO’s Shadow Price, to determine whether there is an appreciable amount of market flow relief being provided.

When the Testing for an Appreciable Amount of Relief and Determining the Settlement Market Flow procedure indicates there is not an appreciable amount of relief being provided, and the Non-Monitoring RTO Shadow Price is not less than the Monitoring RTO Shadow Price, then the Monitoring RTO may terminate the M2M coordination process.

7.1.7Upon termination of redispatch coordination, the Monitoring RTO shall

1. Notify the Non-Monitoring RTO; and

2. Transmit data to the Non-Monitoring RTO with the M2M State set to “Closed”.  The timestamp with this transmission shall be considered termination of the redispatch process for operational and, where applicable, settlement purposes.

7.2Real-Time NY-NJ PAR Coordination

The NY-NJ PARs will be operated to facilitate interchange schedules while minimizing regional congestion costs.  When congestion is not present, the NY-NJ PARs will be operated to achieve the target flows as established below in Section 7.2.1. 

PJM and the NYISO have operational control of the NY-NJ PARs and direct the operation of the NY-NJ PARs, while Public Service Electric and Gas Company (“PSE&G”) and Consolidated Edison Company of New York (“Con Edison”) have physical control of the NY-NJ PARs.  The Con Edison dispatcher sets the PAR taps for the ABC PARs and Ramapo PARs at the direction of the NYISO.  The PSE&G dispatchers set the PAR taps for the Waldwick PARs at the direction of PJM.

PJM and the NYISO have the responsibility to direct the operation of the NY-NJ PARs to maintain compliance with the requirements of this Agreement.  PJM and the NYISO shall make reasonable efforts to minimize movement of the NY-NJ PARs while implementing the NY-NJ PAR target flows and the NY-NJ PAR coordination process.  PJM and the NYISO will employ a +/- 50 MW operational bandwidth around each NY-NJ PAR’s target flow to limit tap movements and to maintain actual flows at acceptable levels.  This operational bandwidth shall not impact or change the NY-NJ PAR Settlement rules in Section 8.3 of this Agreement.  The operational bandwidth provides a guideline to assist the RTOs’ efforts to avoid unnecessary NY-NJ PAR tap movements.

In order to preserve the long-term availability of the NY-NJ PARs, a maximum number of 20 PAR  tap changes per NY-NJ PAR per day, and a maximum number of 400 PAR tap changes per NY_NJ PAR per calendar month will normally be observed.  If the number of PAR tap changes exceed these limits, then the operational bandwidth shall be increased in 50 MW increments until the total number of PAR tap changes no longer exceed 400 PAR tap changes per NY-NJ PAR per month, unless PJM and the NYISO mutually agree otherwise.

In order to implement the NY-NJ PAR coordination process, including the establishment and continuation of the initial and any future OBF as defined in this Section and Section 35.2 of this Agreement, on the ABC PARs and the Waldwick PARs, the facilities comprising the ABC Interface and JK Interface shall be functional and operational at all times, consistent with Good Utility Practice, except when they are taken out-of-service to perform maintenance or are subject to a forced outage.

7.2.1NY-NJ PAR Target Values

A Target Value for flow between the NYISO and PJM shall be determined for each NY-NJ PAR  based on the net interchange schedule between the Parties.  These Target Values  shall be used for settlement purposes as:

Where: 

Calculated Target Value for the flow on each NY-NJ PAR For purposes of this equation, a positive value* indicates a flow from PJM to the NYISO.

*  The sign conventions apply to the formulas used in this Agreement.  The Parties may utilize different sign conventions in their market software so long as the software produces results that are consistent with the rules set forth in this Agreement.

  The MW value of the net interchange schedule between PJM and NYISO over the AC tie lines distributed across each in-service NY-NJ PAR calculated as net interchange schedule times the interchange percentage.  The interchange percentage for each NY-NJ PAR is listed in Table 5.

If a NY-NJ PAR is out-of-service or is bypassed, or if the RTOs mutually agree that a NY-NJ PAR is incapable of facilitating interchange, the percentage of net interchange normally assigned to that NY-NJ PAR will be transferred over the western AC tie lines between the NYISO and PJM.  The remaining in-service NY-NJ PARs will continue to be assigned the interchange percentages specified in Table 5. 

  The MW value of OBF distributed across each of the in-service ABC PARs and Waldwick PARs. 

Either Party may establish a temporary OBF to address a reliability issue until a long-term solution to the identified reliability issue can be implemented.  Any temporary OBF that is established shall be at a level that both Parties can reliably support.  The Party that establishes the OBF shall: (1) explain the reliability need to the other Party; (2) describe how the OBF addresses the identified reliability need; and (3) identify the expected long-term solution to address the reliability need.

The initial 400 MW OBF, effective on May 1, 2017, is expected to be reduced to zero MW by June 1, 2021. 

The Parties may mutually agree to modify an established OBF value that normally applies when all of the ABC PARs and Waldwick PARs are in service.  Modification of the normally applied OBF value will be implemented no sooner than two years after mutual agreement on such modification has been reached, unless NYISO and PJM mutually agree to an earlier implementation date.

The NYISO and PJM shall post the OBF values, in MW, normally applied to each ABC PAR  and Waldwick PAR when all of the ABC PARs and Waldwick PARs are in service, on their respective websites.  The NYISO and PJM shall also post the methodology used to reduce the OBF under certain outage conditions on their respective websites.  The NYISO and PJM shall review the OBF MW value at least annually.

The MW value of the telemetered real-time Rockland Electric Company Load to be delivered over a NY-NJ PAR shall be calculated as real-time RECo Load times the RECo Load percentage listed in Table 5.  RECo Load is the portion of Orange and Rockland load that is part of PJM.  The primary objective of the NY-NJ PARs is the delivery of scheduled interchange.  Deliveries to serve RECo Load over the Ramapo PARs will only be permitted to the extent there is unused transfer capability on the Ramapo PARs after accounting for interchange. Subject to the foregoing limitation, when one of the Ramapo PARs is out of service the full RECo Load percentage (80%) will be applied to the in-service Ramapo PAR.  The RECo Load percentage ordinarily used for each NY-NJ PAR is listed in Table 5:

Table 5

^ Subject to the foregoing limitation, when one of the Ramapo PARs is out of service the full RECo Load Percentage (80%) will be applied to the in-service Ramapo PAR. 

7.2.2Determination of the Cost of Congestion at each NY-NJ PAR

The incremental cost of congestion relief provided by each NY-NJ PAR shall be determined by each of the Parties.  These costs shall be determined by multiplying each Party’s Shadow Price on each of its NY-NJ PAR Coordinated Flowgates by the PSF for each NY-NJ PAR for the relevant NY-NJ PAR Coordinated Flowgates.

The incremental cost of congestion relief provided by each NY-NJ PAR shall be determined by the following formula:

Where:

Cost of congestion at each NY-NJ PAR for the relevant participating RTO, where a negative cost of congestion indicates taps in the direction of the relevant participating RTO would alleviate that RTO’s congestion;

Set of NY-NJ PAR Coordinated Flowgates for the relevant participating RTO;

              The PSF for each NY-NJ PAR on NY-NJ PAR Coordinated  Flowgate–m; and

The Shadow Price on the relevant participating RTO’s NY-NJ PAR Coordinated Flowgate m.

7.2.3Desired PAR Changes

Consistent with the congestion cost calculation established in Section 7.2.2 above, if the NYISO congestion costs associated with a NY-NJ PAR are less than the PJM congestion costs associated with the same NY-NJ PAR, then hold or take taps into NYISO.

Similarly, if the PJM congestion costs associated with a NY-NJ PAR are less than NYISO congestion costs associated with the same NY-NJ PAR, then hold or take taps into PJM.

Any action on the NY-NJ PARs will be coordinated between the Parties and taken into consideration other PAR actions.

8Real-Time Energy Market Settlements

8.1Information Used to Calculate M2M Settlements

For each Flowgate there are two components of the M2M settlement, a redispatch component and a NY-NJ PAR coordination component.  Both M2M settlement components are defined below.

For the redispatch component, market settlements under this M2M Schedule will be calculated based on the following:

1. the Non-Monitoring RTO’s real-time Market Flow, determined in accordance with Section 7.1 above, on each M2M Redispatch Flowgate compared to its M2M Entitlement for M2M Redispatch Flowgates eligible for redispatch on each M2M Redispatch Flowgate; and
2. the ex-ante Shadow Price at each M2M Redispatch Flowgate.

When determining M2M settlements for a M2M Redispatch Flowgate, each Party will use the M2M Entitlement that corresponds to the period/group for which the real-time Market Flow is being calculated except for the following scenarios:

1. When the Non-Monitoring RTO’s M2M Entitlement is negative and the net market flow of the Non-Monitoring RTO is greater than or equal to zero the M2M Entitlement will be set to zero.
2. When the Non-Monitoring RTO’s M2M Entitlement is negative and the net market flow of the Non-Monitoring RTO is also negative, but exceeds the M2M Entitlement, both the M2M Entitlement and market flow will be set to zero.

Redispatch coordination for Other Coordinated Flowgates is not subject to redispatch settlement under Section 8.2 of this Schedule D.  NY-NJ PAR coordination for Other Coordinated Flowgates is subject to NY-NJ PAR coordination settlement under Section 8.3 of this Schedule D .
 

For the NY-NJ PARs coordination component, Market settlements under this M2M Schedule will be calculated based on the following:

1. actual real-time flow on each of the NY-NJ PARs compared to its target flow (TargetPARx);
2. PSF for each NY-NJ PAR onto each M2M Flowgate; and
3. the ex-ante Shadow Price at each M2M Flowgate.

Either or both of the Parties shall be excused from paying an M2MPARSettlement (described in Section 8.3 of this Schedule D) to the other Party at times when a Storm Watch is in effect in New York and the operating requirements and other criteria set forth in Section 8.3.1 below are satisfied. 

8.2Real-Time Redispatch Settlement

For each M2M Redispatch Flowgate compute the real-time redispatch settlement for each interval as specified below.

When ,

When ,

Where:

M2M redispatch settlement, in the form of a payment to the Non-Monitoring RTO from the Monitoring RTO, for M2M Redispatch Flowgate m and interval i;

M2M redispatch settlement, in the form of a payment to the Monitoring RTO from the Non-Monitoring RTO, for M2M Redispatch Flowgate m and interval i;

real-time RTO_MF, determined for settlement in accordance with Section 7.1 above, for M2M Redispatch Flowgate m and interval i;

Non-Monitoring RTO M2M Entitlement for M2M Redispatch Flowgate m and interval i;

Monitoring RTO’s Shadow Price for M2M Redispatch Flowgate m and interval i;

Non-Monitoring RTO’s Shadow Price for M2M Redispatch Flowgate m and interval i; and

number of seconds in interval i.

8.3NY-NJ PARs Settlements

Compute the real-time NY-NJ PARs settlement for each interval as specified below.

When

,

When

,

Where:

Measured real-time actual flow on each of the NY-NJ PARs for interval i.  For purposes of this equation, a positive value indicates a flow from PJM to the NYISO;

Calculated Target Value for the flow on each NY-NJ PAR as described in Section 7.2.1 above for interval i.  For purposes of this equation, a positive value indicates a flow from PJM to the NYISO;

  PJM Impact, defined as the impact that the current NY-NJ PAR flow relative to target flow is having on PJM’s system congestion for interval i.  For purposes of this equation, a positive value indicates that the PAR flow relative to target flow is reducing PJM’s system congestion, whereas a negative value indicates that the PAR flow relative to target flow is increasing PJM’s system congestion. 

NYISO Impact, defined as the impact that the current NY-NJ PAR flow relative to target flow is having on NYISO’s system congestion for interval i.  For purposes of this equation, a positive value indicates that the PAR flow relative to target flow is reducing NYISO’s system congestion, whereas a negative value indicates that the PAR flow relative to the target flow is increasing NYISO’s system congestion system.

Cost of congestion at each NY-NJ PAR for PJM, calculated in accordance with Section 7.2.2 above for interval i;

Cost of congestion at each NY-NJ PAR for NYISO, calculated in accordance with Section 7.2.2 above for interval i, and

M2M PAR Settlement across all NY-NJ PARs, defined as a payment from NYISO to PJM when the value is positive, and a payment from PJM to NYISO when the value is negative for interval i.

number of seconds in interval i.

8.3.1NY-NJ PAR Settlements During Storm Watch Events

PJM shall not be required to pay a  M2MPARSettlement (calculated in accordance with Section 8.3 of this Schedule D) to NYISO when a Storm Watch is in effect and PJM has taken the actions required below to assist the NYISO, or when NYISO has not taken the actions required below to address power flows resulting from the redispatch of generation to address the Storm Watch. 

NYISO shall not be required to pay a  M2MPARSettlement to PJM when a Storm Watch is in effect and NYISO has taken the actions required of it below to address power flows resulting from the redispatch of generation to address the Storm Watch.

When a Storm Watch is in effect, the RTOs will determine whether PJM and/or NYISO are required to pay a  M2MPARSettlement to the other RTO based on three Storm Watch compliance requirements that address the operation of (a) the JK transmission lines and associated Waldwick PARs, (b) the ABC transmission lines and associated ABC PARs, and (c) the 5018 transmission line and associated Ramapo PARs.  Compliance shall be determined as follows:

1. JK Storm Watch compliance:  Subject to the exceptions that follow, PJM will be “Compliant” at the JK interface when either of the following two conditions are satisfied, otherwise it will be “Non-compliant”:

1. Flow on the JK interface was at or above the sum of the Target flows for each Available Waldwick PAR at any point in the trailing (rolling) 15-minutes[1]; or

2. PJM took at least two taps on each Available Waldwick PAR in the direction to reduce flow into PJM at any point in the trailing (rolling) 15-minutes.

If NYISO denies PJM’s request to take one or more taps at a Waldwick PAR to reduce flow into PJM and achieve compliance at the JK interface, then PJM shall be considered “Compliant” at the JK interface.

If PJM cannot take a required tap at a Waldwick PAR because the change will result in an overload on PJM’s system unless NYISO first takes a tap at an ABC PAR increasing flow into New York, and flow on the ABC interface is not at or above the sum of the Target flows for each Available ABC PAR, then PJM may request that NYISO take a tap at an ABC PAR increasing flow into New York.  PJM will be “Compliant” at the JK interface if NYISO does not take the requested tap within five minutes of receiving PJM’s request.  “Compliant” status achieved pursuant to this paragraph shall continue until NYISO takes the requested PAR tap, or the Parties agree that NYISO not taking the requested PAR tap is no longer preventing PJM from taking the PAR tap(s) (if any) PJM needs to achieve compliance at the JK interface. 

If PJM cannot take a required tap at a Waldwick PAR because the change will result in an overload on PJM’s system unless NYISO first takes a tap at a Ramapo PAR increasing flow into New York, and flow on the 5018 interface is not at or above the sum of the Target flows for each Available Ramapo PAR, then PJM may request that NYISO take a tap at a Ramapo PAR increasing flow into New York.  PJM will be “Compliant” at the JK interface if NYISO does not either (i) take the requested tap within five minutes of receiving PJM’s request, or (ii) inform PJM that NYISO is unable to take the requested tap at Ramapo because the change would result in an actual or post-contingency overload on the 5018 lines, or on either of the Ramapo PARs (NYISO will be responsible for demonstrating both the occurrence and duration of the condition).  “Compliant” status achieved pursuant to this paragraph shall continue until NYISO takes the requested PAR tap, or the Parties agree that NYISO not taking the requested PAR tap is no longer preventing PJM from taking the PAR tap(s) (if any) PJM needs to achieve compliance at the JK interface.

If PJM cannot take a required tap at a Waldwick PAR because the change would result in an actual or post-contingency overload on either or both of the JK lines, or on any of the Waldwick PARs, and the overload cannot be addressed through NYISO taking taps at ABC or Ramapo, then PJM will be considered “Compliant” at the JK interface until the condition is resolved.  PJM will be responsible for demonstrating both the occurrence and duration of the condition.

2. ABC Storm Watch compliance: Subject to the exceptions that follow, NYISO will be “Compliant” at the ABC interface when either of the following two conditions are satisfied, otherwise it will be “Non-compliant”:

1. Flow on the ABC interface was at or above the sum of the Target values for each Available ABC PAR at any point in the trailing (rolling) 15-minutes[2]; or

2. NYISO took at least two taps on each Available ABC PAR in the direction to increase flow into New York at any point in the trailing (rolling) 15-minutes.

If PJM denies NYISO’s request to take one or more taps at an ABC PAR to increase flow into New York and achieve compliance at the ABC interface, then NYISO shall be considered “Compliant” at the ABC interface.

If NYISO cannot take a required tap at an ABC PAR because the change will result in an overload on NYISO’s system unless PJM first takes a tap at a Waldwick PAR reducing flow into PJM, and flow on the JK interface is not at or below the sum of the Target values for each Available Waldwick PAR, then NYISO may request that PJM take a tap at a Waldwick PAR reducing flow into PJM.  NYISO will be “Compliant” at the ABC interface if PJM does not take the requested tap within five minutes of receiving NYISO’s request.  “Compliant” status achieved pursuant to this paragraph shall continue until PJM takes the requested PAR tap, or the Parties agree that PJM not taking the requested PAR tap is no longer preventing NYISO from taking the PAR tap(s) (if any) NYISO needs to achieve compliance at the ABC interface.

If NYISO cannot take a required tap at an ABC PAR because the change would result in an actual or post-contingency overload on one or more of the ABC lines, or on any of the ABC PARs, and the overload cannot be addressed through NYISO taking taps at Ramapo or PJM taking taps at Waldwick, then NYISO will be considered “Compliant” at the ABC interface until the condition is resolved.  NYISO will be responsible for demonstrating both the occurrence and duration of the condition.

3. 5018 Storm Watch compliance:  Subject to the exceptions that follow, NYISO will be “Compliant” at the 5018 interface when either of the following two conditions are satisfied, otherwise it will be “Non-compliant”:

1. Flow on the 5018 interface was at or above the sum of the Target values for each Available Ramapo PAR described in Section 7.2.1 of this Schedule D at any point in the trailing (rolling) 15-minutes; or

2. NYISO took at least two taps on each Available Ramapo PAR in the direction to increase flow into New York at any point in the trailing (rolling) 15-minutes.

If PJM denies NYISO’s request to take one or more taps at a Ramapo PAR to increase flow into New York and achieve compliance at the 5018 interface, then NYISO shall be considered “Compliant” at the 5018 interface.

If NYISO cannot take a required tap at a Ramapo PAR because it will result in an overload on NYISO’s system unless PJM first takes a tap at a Waldwick PAR reducing flow into PJM, and flow on the JK interface is not at or below the sum of the Target values for each Available Waldwick PAR, then NYISO may request that PJM take a tap at a Waldwick PAR reducing flow into PJM.  NYISO will be “Compliant” at the 5018 interface if PJM does not take the requested tap within five minutes of receiving NYISO’s request.  “Compliant” status achieved pursuant to this paragraph shall continue until PJM takes the requested PAR tap, or the Parties agree that PJM not taking the requested PAR tap is no longer preventing NYISO from taking the PAR tap(s) (if any) NYISO needs to achieve compliance at the Ramapo interface.

If NYISO cannot take a required tap at a Ramapo PAR because the change would result in an actual or post-contingency overload on the 5018 line, or on either of the Ramapo PARs, and the overload cannot be addressed through NYISO taking taps at ABC or PJM taking taps at Waldwick, then NYISO will be considered “Compliant” at the 5018 interface until the condition is resolved.  NYISO will be responsible for demonstrating both the occurrence and duration of the condition.

When a Storm Watch is in effect in New York, PJM shall only be required to pay a M2MPARSettlement to NYISO when PJM is “Non-compliant” at the JK interface, while NYISO is “Compliant” at both the ABC and 5018 interfaces.  Otherwise, PJM shall not be required to pay a M2MPARSettlement to NYISO at times when a Storm Watch is in effect in New York.

When a Storm Watch is in effect in New York, NYISO shall only be required to pay a M2MPARSettlement to PJM when NYISO is “Non-compliant” at the ABC interface or the 5018 interface, or both of those interfaces.  When NYISO is “Compliant” at both the ABC and 5018 interfaces, NYISO shall not be required to pay a M2MPARSettlement to PJM at times when a Storm Watch is in effect in New York.

When all three interfaces (JK, ABC, 5018) are “Compliant,” or during the first 15-minutes in which a Storm Watch is in effect, this Section 8.3.1 excuses the Parties from paying a M2MPARSettlement to each other at times when a Storm Watch is in effect in New York.

Compliance and Non-compliance shall be determined for each interval of the NYISO settlement cycle (normally, every 5-minutes) that a Storm Watch is in effect. 

8.4Calculating a Combined M2M Settlement

The M2M settlement shall be the sum of the real-time redispatch settlement for each M2M Flowgate and M2MPARSettlement for each interval

Where:

         M2M NYISO settlement, defined as a payment from PJM to NYISO when the value is positive, and a payment from the NYISO to PJM when the value is negative for interval i;

      M2M PJM settlement, defined as a payment from NYISO to PJM when the value is positive, and a payment from the PJM to NYISO when the value is negative for interval i;

Monitoring RTO payment to Non-Monitoring RTO for congestion on M2M Redispatch Flowgate m for interval i; and

Non-Monitoring RTO payment to Monitoring RTO for congestion on M2M Redispatch Flowgate m for interval i.

Where:

M2M settlement, defined as a payment from the NYISO to PJM when the value is positive, and a payment from PJM to the NYISO when the value is negative for interval i;

         M2M NYISO settlement, defined as a payment from PJM to NYISO when the value is positive, and a payment from the NYISO to PJM when the value is negative for interval i;

      M2M PJM settlement, defined as a payment from NYISO to PJM when the value is positive, and a payment from the PJM to NYISO when the value is negative for interval i;

M2M PAR Settlement across all NY-NJ PARs, defined as a payment from NYISO to PJM when the value is positive, and a payment from PJM to NYISO when the value is negative for interval i.

For the purpose of settlements calculations, each interval will be calculated separately and then integrated to an hourly value:

Where:

M2M settlement for hour h; and

n = Number of intervals in hour h.

Section 10.1 of this Schedule D sets forth circumstances under which the M2M coordination process and M2M settlements may be temporarily suspended.

9When One of the RTOs Does Not Have Sufficient Redispatch

It is possible that sufficient redispatch for a M2M Redispatch Flowgate or Other Coordinated Flowgate may not be available to the Monitoring RTO. In these scenarios, the Monitoring RTO will price the flowgate using rules specific to that RTO’s Tariff language.

However, subject to Section 10.1.2 of this Schedule D, if the Non-Monitoring RTO cannot provide sufficient relief to reach the shadow price of the Monitoring RTO, any constraint relaxation logic will be deactivated. The Non-Monitoring RTO will then be able to use the Monitoring RTO’s shadow price without limiting the shadow price to the maximum shadow price associated with a physical control action inside the Non-Monitoring RTO. With the M2M Redispatch Flowgate shadow prices being the same in both RTOs, their resulting bus LMPs will converge in a consistent price profile.

10Appropriate Use of the M2M Coordination Process

Under normal operating conditions, the Parties will model all M2M Flowgates in their respective real-time EMSs. M2M Flowgates will be controlled using M2M tools for coordinated redispatch and coordinated operation of the NY-NJ PARs, and will be eligible for M2M settlements.

10.1Qualifying Conditions for M2M Settlement

10.1.1              Purpose of M2M.  M2M was established to address regional, not local issues. The intent is to implement the M2M coordination process and settle on such coordination where both Parties have significant impact.

10.1.2              Minimizing Less than Optimal Dispatch.  The Parties agree that, as a general matter, they should minimize financial harm to one RTO that results from the M2M coordination process initiated by the other RTO that produces less than optimal dispatch.

10.1.3              Use M2M Whenever Binding a M2M Flowgate. During normal operating conditions, the M2M redispatch process will be initiated by the Monitoring RTO whenever an M2M Flowgate that is eligible for redispatch is constrained and therefore binding in its dispatch.  Coordinated operation of the NY-NJ PARs is the default condition and does not require initiation by either Party to occur.

10.1.4              Most Limiting Flowgate.  Generally, controlling to the most limiting Flowgate provides the preferable operational and financial outcome.  In principle and as much as practicable, the M2M coordination process will take place on the most limiting Flowgate, and to that Flowgate’s actual limit (thermal, reactive, stability).

10.1.5              Abnormal Operating Conditions. 

1. A Party that is experiencing system conditions that require the system operators’ immediate attention may temporarily delay implementation of the M2M redispatch process or cease an active M2M redispatch event until a reasonable time after the system condition that required the system operators’ immediate attention is resolved.

2. Either Party may temporarily suspend an active M2M coordination process or delay implementation of the M2M coordination process if a Party is experiencing, or acting in good faith suspects it may be experiencing, (1) a failure or outage of the data link between the Parties prevents the exchange of accurate or timely real-time data necessary to implement the M2M coordination process; or (2) a failure or outage of any  computational or data systems preventing the actual or accurate calculation of data necessary to implement the M2M coordination process.  The Parties shall resolve the issue causing the failure or outage of the data link, computational systems, or data systems as soon as possible in accordance with Good Utility Practice.  The Parties shall resume implementation of the M2M coordination process following the successful testing of the data link or relevant system(s) after the failure or outage condition is resolved.

10.1.6              Transient System Conditions. A Party that is experiencing intermittent congestion due to transient system conditions including, but not limited to, interchange ramping or transmission switching, is not required to implement the M2M redispatch process unless the congestion continues after the transient condition(s) have concluded.

10.1.7              Temporary Cessation of M2M Coordination Process Pending Review.

If the net charges to a Party resulting from implementation of the M2M coordination process for a market-day exceed five hundred thousand dollars, then the Party that is responsible for paying the charges may (but is not required to) suspend implementation of this M2M coordination process (for a particular M2M Flowgate, or of the entire M2M coordination process) until the Parties are able to complete a review to ensure that both the process and the calculation of settlements resulting from the M2M coordination process are occurring in a manner that is both (a) consistent with this M2M Coordination Schedule, and (b) producing a just and reasonable result.  The Party requesting suspension must identify specific concerns that require investigation within one business day of requesting suspension of the M2M coordination process.  If, following their investigation, the Parties mutually agree that the M2M coordination process is (i) being implemented in a manner that is consistent with this M2M Coordination Schedule and (ii) producing a just and reasonable result, then the M2M coordination process shall be re-initiated as quickly as practicable.  If the Parties are unable to mutually agree that the M2M coordination process was being implemented appropriately, or of the Parties are unable to mutually agree that the M2M coordination process was producing a just and reasonable result, the suspension (for a particular M2M Flowgate, or of the entire M2M coordination process) shall continue while the Parties engage in dispute resolution in accordance with Section 35.15 of this Agreement.

10.1.8              Suspension of M2M Settlement when a Request for Taps on NY-NJ PARs to Prevent Overuse is Refused.  If a Party requests that taps be taken on any NY-NJ PAR to reduce the requesting Party’s overuse of the other Party’s transmission system, refusal by the other Party or its Transmission Owner(s) to permit taps to be taken to reduce overuse shall result in the NY-NJ PAR settlement component of M2M (see Section 8.3 above) being suspended until the tap request is granted.

10.1.9Suspension of NY-NJ PAR Settlement due to Transmission Facility Outage(s).  The Parties shall suspend PAR settlements for a NY-NJ PAR when that NY-NJ PAR is out of service, is bypassed, or the RTOs mutually agree that a NY-NJ PAR is incapable of facilitating interchange.

No other Transmission Facility outage(s) will trigger suspension ofNY-NJ PAR settlements under this Section 10.1.9.

10.1.10Suspension of NY-NJ PAR Settlement due to a Stuck PAR

The Parties shall suspend PAR settlements for a NY-NJ PAR when the NY-NJ PAR cannot be adjusted due to physical or SCADA failure and either of the following two conditions occur:

1.The failure is on one of the A, B, C, 3500, or 4500 PARs, the flow on the PAR is below the Target flow for that PAR, or

2.The failure is on one of the E, F or O PARs, the flow on the PAR is above the Target flow for that PAR.

10.2After-the-Fact Review to Determine M2M Settlement

Based on the communication and data exchange that has occurred in real-time between the Parties, there will be an opportunity to review the use of the M2M coordination process to verify it was an appropriate use of the M2M coordination process and subject to M2M settlement.  The Parties will initiate the review as necessary to apply these conditions and settlements adjustments.  The Parties will cooperate to review the data exchanged and used to determine M2M settlements and will mutually identify and resolve errors and anomalies in the calculations that determine the M2M settlements.

If the data exchanged for the M2M redispatch process was relied on by the Non-Monitoring RTO’s dispatch to determine the shadow cost the Non-Monitoring RTO was dispatching to when providing relief at an M2M Flowgate, the data transmitted by the Monitoring RTO that was used to determine the Non-Monitoring RTO’s shadow cost shall not be modified except by mutual agreement prior to calculating M2M settlements.  Any necessary corrections to the data exchange shall be made for future M2M coordination.

10.3 Access to Data to Verify Market Flow Calculations

Each Party shall provide the other Party with data to enable the other Party independently to verify the results of the calculations that determine the M2M settlements under this M2M Coordination Schedule.  A Party supplying data shall retain that data for two years from the date of the settlement invoice to which the data relates, unless there is a legal or regulatory requirement for a longer retention period.  The method of exchange and the type of information to be exchanged pursuant to Section 35.7.1 of this Agreement shall be specified in writing.  The Parties will cooperate to review the data and mutually identify or resolve errors and anomalies in the calculations that determine the M2M settlements.  If one Party determines that it is required to self report a potential violation to the Commission’s Office of Enforcement regarding its compliance with this M2M Coordination Schedule, the reporting Party shall inform, and provide a copy of the self report to, the other Party.  Any such report provided by one Party to the other shall be Confidential Information.

11M2M Change Management Process

11.1Notice

Prior to changing any process that implements this M2M Schedule, the Party desiring the change shall notify the other Party in writing or via email of the proposed change.  The notice shall include a complete and detailed description of the proposed change, the reason for the proposed change, and the impacts the proposed change is expected to have on the implementation of the M2M coordination process, including M2M settlements under this M2M Schedule.

11.2Opportunity to Request Additional Information

Following receipt of the Notice described in Section 11.1, the receiving Party may make reasonable requests for additional information/documentation from the other Party.  Absent mutual agreement of the Parties, the submission of a request for additional information under this Section shall not delay the obligation to timely note any objection pursuant to Section 11.3, below.

11.3Objection to Change

Within ten business days after receipt of the Notice described in Section 11.1 (or within such longer period of time as the Parties mutually agree), the receiving Party may notify in writing or via email the other Party of its disagreement with the proposed change.  Any such notice must specifically identify and describe the concern(s) that required the receiving Party to object to the described change.

11.4Implementation of Change

The Party proposing a change to its implementation of the M2M coordination process shall not implement such change until (a) it receives written or email notification from the other Party that the other Party concurs with the change, or (b) the ten business day notice period specified in Section 11.3 expires, or (c) completion of any dispute resolution process initiated pursuant to this Agreement.

[1] For example, if the sum of the Target flows for Available Waldwick PARs is +200 MW, then PJM will be “Compliant” if flow into PJM on JK was at or above +200 MW during any six second measurement interval over the trailing (rolling) 15 minutes.

[2] For example, if the sum of the Target values for each Available ABC PAR is +200 MW, then NYISO will be “Compliant” if flow into New York on ABC was at or above +200 MW during any six second measurement interval over the trailing (rolling) 15 minutes.