ERCOT Short Circuit Case Building Procedure Manual v2.0 A Complete Technical Guide Prepared by Keentel Engineering

The System Protection Working Group (SPWG) is a non-voting technical working group that operates under the direction of ERCOT's Reliability and Operations Subcommittee (ROS). Its membership includes representatives from all ERCOT Transmission Service Providers and ERCOT staff. The SPWG's primary responsibilities related to short circuit case building are threefold: producing the Current Year (CY) short circuit base case by approximately April 1st each year, producing the five Future Year (FY) short circuit base cases by approximately July 1st each year, and reviewing and updating the procedural manual at least once every five years. Version 2.0 explicitly states that the procedure manual is intended to demonstrate compliance with applicable NERC Reliability Standards, meaning the SPWG's work is directly linked to ERCOT's NERC compliance obligations. For Keentel Engineering clients subject to NERC MOD standards, participation in the SPWG process and adherence to this manual is part of demonstrating standards compliance.

The Version 2.0 naming convention represents a significant structural overhaul. The most visible change is the introduction of a two-digit build year prefix (BB) in front of the SPWG identifier, replacing the older pattern that embedded the full year only once. For example, a change file in the old convention might read AEP_2012_FY_Pass2.CHF; in the new convention, the same type of file for the 2021 build cycle targeting 2022 reads AEP_21_SPWG_2022_FY_Pass2.CHF. This dual-year encoding (BB for the build year, CCCC for the target case year) makes it unambiguous both when the file was produced and what case year it pertains to. Additionally, consolidated files — a new category in Version 2.0 — have their own naming convention with a _consolidated suffix. Different log types also now carry distinct suffixes: _conversion_log, _change_log, _consolidated_log, and _import_log. These distinctions are essential because multiple similarly-purposed files are generated during a single pass, and without precise naming, files can be confused, overwritten, or misapplied during compilation. ERCOT accepts no alternative naming conventions, so clients should update any automated scripts or submission workflows to reflect the new standard.

Each annual SPWG case building cycle produces six cases: one Current Year (CY) and five Future Year (FY) cases covering CY+1 through CY+5. Each case must reflect the expected network configuration as of June 30th of that case year, meaning all equipment reasonably expected to be in service by June 30th must be included and modeled as in-service. Generators must meet the requirements of ERCOT Planning Guide Section 6 to be included in the appropriate case year. Mutual impedance effects must be reflected per Section 3.5 guidelines. The system base is 100 MVA across all cases. The CY case is typically finalized by end of March, and the FY cases are typically finalized by end of June, though the SPWG and ERCOT set the specific schedule annually. For Keentel Engineering clients planning capital projects, this June 30th cutoff date determines which construction milestones need to be reflected in which case year, making it a critical planning parameter for interconnection studies and protection upgrade projects.

The Future Year Pass0 process is the most architecturally sophisticated part of the case building workflow and was significantly clarified in Version 2.0. The key insight is that each FY Pass0 case is not built from scratch but is derived from the prior year's FY Final Pass case for that same target year, updated with an incremental change file that captures what changed in the most recently completed case year. For example, building the 2022 FY Pass0 during the 2021 case build cycle starts with 20_SPWG_2022_FY_FinalPass (built a year ago) and adds a change file representing the difference between 20_SPWG_2021_FY_FinalPass (2021 as it was modeled last year) and 21_SPWG_2021_CY_FinalPass (2021 as it is now modeled with current-year accuracy). This delta propagation cascades through Y+2, Y+3, Y+4, and Y+5 in a chain, with each year's Pass0 incorporating the delta from its predecessor. The Y+5 Pass0 is simply copied from the Y+4 Pass0. This structure is more complex than the CY process — which straightforwardly takes the prior CY Final Pass and applies incremental updates — but it ensures that future year cases always reflect the latest confirmed information without losing continuity from the prior cycle.

The most notable change in CHF creation procedure between Version 1.6 and Version 2.0 is the correlation method. Version 1.6 specified comparing by Bus Number, noting that bus names may not be unique. Version 2.0 reverses this, specifying that comparison should be performed using "Name and kV" because bus names and kV combinations are now treated as reliably unique within the ERCOT system. This change reflects improvements in ERCOT's bus naming standards over time. All other key settings remain consistent: the "Inside" radio button must be used with the TSP's own area numbers; generator facilities in +900 offset areas must be excluded from the change file; and the "Include ties between selected items and the rest of the network" checkbox must be checked. ASPEN users create their own CHF files and submit them to ERCOT. Non-ASPEN users who submit in PSS/E have their CHF files created by ERCOT on their behalf. All CHF files and their corresponding change logs must be sent to ERCOT for screening before being run in the next pass build.

 This is one of the most operationally significant changes in Version 2.0. Version 1.6 performed fault analysis in PSS/E using the TREE command (to identify and disconnect electrical islands), the FLAT, CL command (to initialize the case for fault calculations), and an IDV scripting file (checkascc_revised_01192010.idv) to generate fault current data files. Version 2.0 replaces this entire PSS/E workflow with ASPEN OneLiner's native Bus Fault Summary tool, accessed via Menu > Faults > Bus Fault Summary. After the case build and PSS/E export are complete, the engineer returns to ASPEN OneLiner, opens the Bus Fault Summary window, unchecks "Exclude tap buses," and runs the analysis. The output is a CSV file. As a validation step, the total bus count should be verified against the known SPWG case count of 12,000+ buses — a significant discrepancy indicates the tap bus exclusion setting was applied incorrectly. This migration to ASPEN-native fault analysis simplifies the workflow, eliminates dependency on PSS/E CLI commands, and provides a directly usable CSV output without the intermediate scripting steps required in the old workflow.

Version 2.0 dedicates a full subsection to renewable generation modeling, reflecting the dramatic growth of wind and solar in ERCOT. Both Type-3 and Type-4 WTGs, as well as solar PV generators, are modeled as current-limited generators rather than conventional synchronous machines, because their inverter-based connection to the grid produces fundamentally different fault behavior. For Type-4 WTGs and solar PV, the zero sequence impedance is set to j999 pu to prevent zero sequence current contribution (these machines are ungrounded). Positive sequence impedance is set to j0.02 pu — notably, this is not the machine's actual impedance but a modeling approximation. ASPEN also recommends setting negative sequence impedance to j999 in most cases. Current Limit A represents instantaneous fault current (approximately 2.5x full load), while Current Limit B represents steady-state fault current at 4+ cycles (approximately 1.1–1.2x full load). For protection studies, Current Limit B is typically more useful. Type-3 WTGs are more complex because they are doubly-fed machines — a hybrid between synchronous and induction designs. During close-in faults, Type-3 machines may activate their crowbar protection, at which point they behave as induction machines. Protection studies must therefore examine Type-3 behavior both with and without current limits. When crowbar is active, Current Limit A should be set to zero to disable it. The zero sequence impedance for Type-3 is also set to j999, but positive sequence impedance should reflect the machine's actual transient or subtransient impedance.

The RARF-to-ASPEN parameter mapping table was expanded in Version 2.0 to include two new entries relevant to current-limited generators. The established parameters remain unchanged: MVA Base maps to Unit Rating (MVA); saturated subtransient reactance X''dv maps to Subtransient (jX); saturated transient reactance X'dv maps to Transient (jX); saturated synchronous reactance Xdv maps to Synchronous (jX); saturated negative sequence reactance X2v maps to negative sequence (jX); saturated zero sequence reactance X0v maps to zero sequence (jX); armature positive sequence resistance R1 maps to the R component of Subtransient, Transient, and Synchronous simultaneously; R2 maps to negative sequence (R); and R0 maps to zero sequence (R). The two new entries are: Instantaneous Controlled Fault Current Magnitude (parameter A, in multiples of full load current) for turbine Types 3 and 4, which maps to Current Limit A in ASPEN; and Controlled Fault Current Magnitude at 4+ cycles after fault (parameter B, also in multiples of full load current) for turbine Types 3 and 4, which maps to Current Limit B. All values use saturated impedances on a per-unit basis at the unit MVA base. For current-limited generators, saturated values are replaced by the current limit values from the RARF.

 Version 2.0's new Transmission Line or Branch Data section specifies that line impedance data must be calculated based on the TSP's own engineering criteria and entered as per-unit values on the nominal kV base. Positive sequence parameters must include both impedance and shunt susceptance where applicable. Negative sequence parameters are assumed equal to positive sequence and are not explicitly entered into the short circuit case. Zero sequence parameters must include both impedance and shunt susceptance where applicable. Zero sequence data is particularly important because it directly governs the magnitude of ground fault currents, which determine ground relay pickup settings and are sensitive to the physical line geometry and grounding configuration. ASPEN OneLiner's line data entry screen captures R, X, B (positive sequence) and R0, X0, B0 (zero sequence), along with circuit miles for mutual impedance calculations. For Keentel Engineering clients with new line projects, ensuring that both positive and zero sequence line constants are accurately calculated from conductor data, tower geometry, and ground wire configuration — and properly entered in per-unit — is essential before submission.

Version 2.0 adds a dedicated tie line coordination section that formalizes the parameters neighboring TSPs must agree on for every shared facility. A tie line is defined as any transmission circuit with multiple owners represented within the associated facility context. The parameters requiring explicit coordination include in-service and out-of-service dates, from bus number, to bus number, circuit identifier, impedance, mutual impedance, LTC transformer adjustment data, branch status, circuit miles, ownership (up to four owners), and the entity responsible for submitting the data. The manual emphasizes that even when no new tie lines are added to the network, existing tie line data can still change due to construction timing changes, modeling refinements, or ownership transitions. Coordination must happen early enough to allow CY and FY work to proceed without delays. For Keentel Engineering clients near TSP boundaries, tie line data discrepancies are among the most common sources of errors in compiled SPWG cases. The correction timeline is limited to the pass cycle, so unresolved tie line issues can persist through multiple passes if not addressed proactively.

Mutual impedance must be modeled in two scenarios, each with two alternative triggering thresholds. For circuits sharing a common physical structure (same towers or poles), mutual impedance must be included if either the coupled length exceeds 10% of the shortest line circuit, or the mutual impedance value exceeds 10% of the smallest zero-sequence impedance. For circuits sharing a common right-of-way narrower than 100 feet (but not necessarily on common structures), the same dual thresholds apply. Either threshold alone is sufficient to require modeling — both conditions do not need to be met simultaneously. TSPs may choose to model certain circuits in greater detail than these minimum thresholds require. When the mutually coupled circuits are owned or operated by different TSPs, those two TSPs must reach a bilateral agreement on which entity will submit the Mutual Pair data in ASPEN OneLiner. The responsible entity must document their identity in the Memo field of the ASPEN Mutual Pair entry. This documentation is important for data governance: if an error is found in the mutual pair data during review, it is immediately clear which TSP is responsible for the correction and resubmission.

 Version 2.0 provides detailed transformer data entry guidelines for both 2-winding and 3-winding configurations. Transformer impedance data must come from manufacturer test reports whenever available; if no test report exists for an older unit, the TSP must document the rationale used to determine parameter values. All windings must be modeled regardless of whether they carry load — this is especially important for tertiary windings, which often carry no load but provide zero sequence current paths critical for ground fault calculations. For 2-winding transformers, the R, X, R0, and X0 values come directly from test report data. The magnetizing susceptances B and B0 are rarely required in short circuit calculations. Tap values must match the actual voltage from which impedance was determined, which may differ from the bus nominal voltage or the in-service tap position. LTC and metered-at fields are not used in short circuit analysis. For 3-winding transformers, the winding-pair impedances Zps, Zpt, Zst, and their zero sequence counterparts must be populated from test data. Grounding impedances Zg1, Zg2, and Zgn apply only when external grounding impedances are physically present. All transformer data must comply with NERC MOD-32-1 Attachment 1. For Keentel Engineering clients with aging transformer fleets lacking test reports, developing defensible parameter estimates consistent with MOD-32-1 is a frequent engineering need.

Appendix A of Version 2.0 introduces a formal aggregation methodology for wind and solar plants, applicable when either a detailed ASPEN model is not available from the generator or when simplification is appropriate. The aggregation approach handles padmount transformers and generating units separately. For padmount transformers, the aggregate complex impedance is calculated as the single-transformer impedance divided by the number of turbines (N), scaled by the ratio of the new MVA base to the transformer's own MVA base. When the new MVA base is set equal to N times the transformer MVA base, the scaling factor becomes 1 and the aggregate impedance equals the single-transformer impedance — a convenient simplification. For generating units, per-unit impedances do not change with aggregation since they are already expressed in per-unit at the unit MVA base. The aggregate model simply uses a Unit Rating equal to the individual unit MVA multiplied by the number of units. MW, MVAR, and limit values scale proportionally. When a generator provides a detailed ASPEN model, it must be cross-validated against the RARF data to ensure consistency — the two data sources should be congruent, and discrepancies must be resolved before submission.

Version 2.0 introduces an explicit pre-fault voltage methodology that was not addressed in prior versions. ASPEN OneLiner uses a linear network solution where pre-fault bus voltages are calculated using a matrix form of Ohm's law that accounts for all network elements simultaneously. Rather than using a flat 1.0 per-unit voltage profile, ERCOT obtains actual generator bus voltages and angles from the SSWG (Steady State Working Group) summer peak case for the relevant case year and enters them into the ref.V (reference voltage) and ref.Ang (reference angle) fields in the SPWG case files. For example, to build the 2021 FY Pass0 case, ERCOT uses generator reference data from the 2021 SSWG summer peak case. Pre-fault voltage affects fault current magnitude because the fault current for a bolted fault is directly proportional to the pre-fault voltage at the fault bus. Using realistic pre-fault voltages rather than flat voltages provides more accurate fault current estimates at buses with significant voltage deviation from nominal, which is particularly relevant near large generation pockets or at the end of heavily loaded transmission paths. For Keentel Engineering protection studies, this means that SPWG cases may show modestly different fault current results at voltage-stressed buses compared to a flat-voltage baseline model.

The Version 2.0 output package is notably expanded compared to Version 1.6, reflecting ERCOT's enhanced data validation and reporting workflows. ASPEN files include the master *.OLR case file (named using the BB_SPWG_CCCC_XX_MMDDYYYY_PassN convention), all member-submitted CHF files with their corresponding import logs, and all CHF files that ERCOT converted from PSS/E submissions. PSS/E files include the *.raw network data file, *.seq sequence data file, and *.sav saved case file. Excel and CSV reports include five distinct files: the Bus Fault Summary CSV (containing raw fault current data for all buses), the Bus Comparison Excel file (which compares current and future year fault levels), the Generation Modeling Excel file (documenting generator data and modeling status), the Nearest Generator Report Excel file (identifying the closest modeled generator to each bus for protection study reference), and the TSP Response Excel file (used for tracking data queries and responses between ERCOT and TSPs). Compared to Version 1.6, which included only a fault comparison Excel spreadsheet and island data file, the Version 2.0 output suite provides substantially more data for verification. Keentel Engineering recommends that TSPs review all five Excel reports carefully after each pass, not only the Bus Fault Summary, as discrepancies often appear in generator modeling or tie line data before they become visible as fault current anomalies.

This technical guide was prepared by Keentel Engineering to support ERCOT TSPs, protection engineers, and grid planners in understanding and implementing the SPWG Short Circuit Case Building Procedure Manual Version 2.0. For questions about case submissions, ASPEN modeling, relay coordination studies, or NERC compliance documentation, contact Keentel Engineering's Power Systems Protection team