Minimum Technical Data Request Checklist for Solar, BESS, and Data-Center Projects

Welcome back. In the previous lesson, you built the logic of an applicability register: each requirement needs a source, revision, section, authority path, applicability rationale, and status. That register tells you what must be demonstrated. A technical-data request tells you what information is needed to build and validate the study representation.

For interconnection work, an incomplete request is costly because the missing items usually surface late: a transformer vector group missing during a fault study, a BESS charging limit omitted from a power-flow case, a PPC mode absent from the dynamic model, or an OEM PSCAD package that cannot compile in the available environment. This lesson gives you a reusable minimum checklist for solar, solar-plus-BESS, standalone BESS, and large data-center projects. It is designed for early screening through formal interconnection studies, not as a substitute for the region’s current submission forms or an executed study agreement.

---

Begin with the purpose and boundary of the request

A data request is not a generic request for “all electrical information.” It is a controlled statement of the data needed to represent a project faithfully in one or more study types:

• Steady state: AC power flow, thermal loading, voltage, reactive capability, and contingency assessment.
• Short circuit: three-phase and unbalanced fault duty, grounding behavior, and grid-strength screening.
• RMS dynamics: transient stability, plant-power-controller behavior, voltage ride-through, frequency response, and model-quality testing.
• EMT: fast converter and protection interactions, weak-grid behavior, detailed fault recovery, and phase-angle-jump tests where required.

The model boundary must be clear before requesting numbers. For a renewable plant, the normal boundary is from inverter terminals or the aggregate inverter equivalent through collector system, GSUs, plant substation, and the POI. For a data center, it normally extends from the POI through customer-owned transformers and major load buses to the modeled load blocks, backup generation, and controllable load functions that materially affect the transmission system.

A single-line diagram is necessary, but it is not sufficient. The study model also needs operating states, controls, ratings, protection, grounding, and an unambiguous statement of what is not represented.

Treat every requested item as a controlled technical record

For each item in the checklist, include these administrative fields:

Field	Why it matters
Project name, queue number, POI, and requested in-service year	Connects the data to the correct project configuration and study cycle.
Request item and study purpose	Prevents a vague request such as “provide transformer data.”
Required format and units	Reduces ambiguity between percent impedance, per-unit impedance, ohmic values, and different MVA bases.
Source and responsible party	Identifies whether the value came from the developer, EPC, OEM, equipment vendor, or Transmission Owner.
Revision and issue date	Lets you identify whether a model reflects the current design.
Status	Use values such as preliminary, for study, approved for construction, as-built, or not yet available.
Due stage	Distinguishes early screening assumptions from application, cluster-study, commissioning, or ongoing model-maintenance data.
Confidentiality classification	Keeps OEM models, relay settings, and controlled utility data in authorized storage.

The request should also state a shared convention. A practical minimum is:

Report MW and MVAr at the named measurement point; identify whether capability is gross or net; state the MVA base for every impedance or per-unit parameter; provide normal and emergency ratings separately; and identify whether a BESS charging MW value is represented as negative generation or as load in the intended model.

That convention matters when moving between ETAP, PSS®E, PSCAD, OEM documentation, and a utility’s model package.

---

The common minimum technical-data checklist

SPP’s Model Development Procedure Manual provides a useful model-builder perspective. Its MOD-032 Attachment 1 groups required data into steady-state, dynamics, and short-circuit categories, including buses, demand, generators, transformers, shunts, dynamic equipment, and sequence data. Its treatment is broader than a project-level request, but it is an excellent safeguard against requesting only MW capacity and a one-line diagram.

Use the following checklist as the common core for all four project types.

1. Project definition and electrical boundary

Request:

• Current project description: technology, developer, interconnection entity, POI/POD, requested commercial-operation date, and study stage.
• Geographic coordinates for the proposed POI/substation and major project facilities.
• A revision-controlled single-line diagram showing:
  • utility-owned versus customer-owned equipment;
  • nominal voltages;
  • breakers and normally open points;
  • transformer locations;
  • collector feeders or data-center substations;
  • reactive devices;
  • metering and PPC measurement locations; and
  • the exact proposed POI.
• A model-boundary statement identifying which equipment is explicitly modeled, aggregated, represented as a fixed equivalent, or excluded.
• Equipment status and effective dates: existing, under construction, proposed, retired, normally open, seasonal, or contingency-only.
• Existing project agreements or utility instructions that impose an export limit, import limit, operating restriction, outage restriction, or required study scenario.

The POI is not merely a point on a map. It is the electrical and contractual reference point for limits, measurements, dispatch, and often compliance criteria. A project may have inverter capacity, transformer capacity, collector capacity, and POI injection capacity that are all different.

2. Steady-state network and equipment data

Request enough information to construct a credible PSS®E power-flow model.

Equipment or topic	Minimum requested data
Buses and connection points	Bus names or proposed names, nominal kV, ownership, coordinates if available, voltage-control location, and connection status.
Lines, cables, and collector feeders	From and to locations, circuit identifier, conductor or cable type, length, positive-sequence impedance, line charging where material, normal and emergency ratings, and seasonal rating basis.
Two- and three-winding transformers	Rated MVA, winding kV, impedance and its MVA base, winding connections, phase shift/vector group, tap range, number of taps, neutral position, control mode, regulated bus, setpoint, and normal/emergency ratings.
Shunts and dynamic VAR devices	Capacitor, reactor, SVC, STATCOM, or harmonic-filter ratings; step/block sizes; fixed, switched, or continuous mode; control setpoint/band; limits; expected status by scenario; and regulated bus.
Generation or BESS equivalent	MBASE, real-power maximum/minimum, reactive maximum/minimum, capability curve or tabulated capability versus MW, voltage setpoint, dispatch, and operating status.
Auxiliary and station-service load	MW and MVAr at the actual connection voltage, fixed versus dispatch-dependent portion, expected operating status, and whether it must remain on when the resource is offline.
POI limits and metering	Maximum export, maximum import, net versus gross definition, measurement location, station-service treatment, and any seasonal or contractual constraint.

A capability statement such as “150 MW / 180 MVA BESS” is not enough. It does not tell the modeler the charging limit, reactive capability at partial output, whether 150 MW is measured at inverter terminals or at the POI, or the MW consumed by balance-of-plant equipment.

3. Short-circuit and grounding data

Short-circuit requests often arrive too late because the project team assumes that transformer percent impedance is sufficient. It is not sufficient for a complete fault model.

Request:

• Positive-, negative-, and zero-sequence impedance data for project-owned lines, cables, transformers, reactors, and applicable sources.
• Transformer vector group, winding grounding method, neutral grounding impedance, and zero-sequence transfer characteristics.
• Grounding-transformer and neutral-resistor data, if installed.
• Detailed collector-cable sequence data when its fault contribution or grounding behavior is material.
• Inverter or BESS fault-current behavior, including current limit, sequence-current capability if applicable, control mode, duration, and source documentation.
• Mutual impedance data for materially parallel circuits where available and required by the study scope.
• Interrupting ratings and protection-equipment information if the study includes equipment-duty evaluation.

The SPP manual specifically identifies positive-, negative-, and zero-sequence data as short-circuit inputs and notes that transformer vector group and connection code are important to usable fault cases. A physically correct one-line can still produce misleading ground-fault results if vector group or grounding data are missing.

4. Dynamic-model and control data

For RMS dynamic studies, request the complete model chain, not merely an inverter model name. For an inverter-based facility this normally includes a converter representation, electrical controls, plant controller, protection models, and the network elements needed to connect the modeled device to the POI.

Request:

• The PSS®E dynamic-data file in the required format, normally a .dyr or a clearly identified incremental dynamic-data file.
• PSS®E version compatibility and the required model-library version.
• User-written model source, compiled library/object files, compilation instructions, and dependency list where the model is not entirely in the standard library.
• Model documentation: block diagrams, parameter definitions, bases, limits, initialization assumptions, and known limitations.
• A mapping table linking each model record to its bus number, machine identifier, equipment function, and physical device.
• Inverter operating modes: grid-following or grid-forming capability, active/reactive current priority, voltage-control mode, frequency response, current limits, and transitions between modes.
• PPC settings and logic:
  • measurement point;
  • POI voltage, reactive-power, power-factor, active-power, and frequency-control modes;
  • setpoints and deadbands;
  • filters, droop, gains, delays, and limits;
  • remote-bus or line-drop compensation;
  • coordination with inverter-level controls; and
  • mode-selection and fallback logic.
• Voltage and frequency protection: thresholds, timers, reconnect logic, breaker trip actions, and the specific dynamic-model interface.
• Existing validation, commissioning, or model-quality-test results, including plots and the exact simulation files used to produce them.

ERCOT’s Planning Guide shows why the request must reach beyond a single dynamic file: its FIS material calls for complete Resource Registration data, appropriate dynamic models, model-quality-test results, and associated simulation files. Its dynamics section also requires the Facility owner to provide models that represent the device accurately and to include site-specific dynamic models in model-quality testing.

5. EMT and PSCAD package data, where required

Do not request a PSCAD model automatically for every early-stage screening study. Request it when the applicable requirements, study agreement, utility direction, or technical risk warrants EMT work.

The minimum EMT package request should include:

• PSCAD project or workspace with the primary case clearly identified.
• Source files, compiled libraries, external components, and library-path instructions.
• Required PSCAD version, compiler version, license dependencies, and any OEM-specific prerequisites.
• A readme file with case setup, initialization method, simulation time step, output sampling, and run instructions.
• The inverter, PPC, protection, disturbance, and measurement hierarchy.
• A parameter file and revision record matching the supplied PSS®E representation where comparison is intended.
• Existing benchmark plots, test reports, known warnings, encrypted-component limitations, and a technical contact for model-support questions.

A package that opens but cannot compile is not a usable deliverable. Similarly, a model that compiles but has undocumented measurement polarity or scaling is difficult to compare defensibly with PSS®E results.

---

Project-specific additions: what changes by facility type

The common checklist prevents omissions, but it does not capture each project’s operational identity. Add the following data by project type.

Project type	Additional data required
Solar	DC and AC nameplate ratings; inverter quantity and rating; seasonal output assumptions; clipping assumptions; inverter apparent-power capability; curtailment and ramp-rate limits; plant auxiliary demand; collector layout or aggregate-equivalent calculation; and expected output for peak, light-load, and minimum-generation conditions.
Standalone BESS	Maximum continuous discharge MW; maximum continuous charge MW; MWh energy capacity and duration; SOC limits and starting SOC for each study scenario; round-trip or directional efficiency assumptions; charging source and any grid-charging restriction; charge/discharge availability; auxiliary load; grid-forming versus grid-following modes; and transition logic.
Solar-plus-BESS	All solar and BESS data, plus the electrical arrangement: AC-coupled or DC-coupled, shared inverter or separate inverters, shared collector system, shared GSU, and shared POI. Request explicit dispatch combinations, including solar-only export, BESS-only discharge, simultaneous solar-plus-BESS export, BESS charging with solar output, and BESS grid charging if permitted.
Data center	Maximum demand, initial demand, expansion blocks, MW/MVAr or power-factor range, hourly/seasonal load shapes, ramp rate, energization sequence, block-load pickup, UPS and rectifier behavior, load composition for dynamics, controllable-load capability, backup-generator behavior, and transfer/load-shedding schemes. Also request reliability architecture: utility feeds, substations, transformers, normally open ties, N and N-plus-one arrangements, and restoration assumptions.

For a BESS, do not hide charging inside a generic “load” entry without explaining the operational model. In a planning model, battery charging is often represented as negative generator output, while other studies may represent it through an explicit load convention. Either can be technically workable if the selected regional convention is followed and the sign convention is documented consistently.

For a hybrid plant, request a POI allocation table. For each scenario, it should show solar MW, BESS MW, plant auxiliary MW, reactive target or voltage target, and net POI MW. This is the simplest way to expose a violation of a shared export limit before it becomes a late-stage modeling dispute.

---

Scenario data: turn equipment facts into study conditions

A data package with correct nameplate values can still produce an unrealistic study if it lacks scenarios. Request a scenario table with each operating state described by project facts, not labels such as “high case” or “low case.”

At minimum, ask for the following:

Scenario category	Solar / BESS examples	Data-center examples
Normal maximum condition	Maximum solar export; maximum BESS discharge; combined POI-limited export	Maximum diversified demand at planned build-out
Minimum-load or minimum-generation condition	Solar at zero or low output; BESS charging if permitted; light system-load context	Minimum stable demand and minimum-load operating configuration
Reactive-stress condition	Maximum MW at leading and lagging reactive limits; capacitor/reactor states	High MW with low power factor, transformer reactive demand, and VAR-device states
Transition condition	Charge-to-discharge transition, curtailment, plant energization, inverter-block changes	Energization sequence, block load pickup, feeder transfer, UPS transfer
Contingency condition	Post-contingency dispatch, allowed BESS response, shunt/tap actions	Loss of one supply transformer, feeder, substation, or backup source; permitted restoration actions
Dynamic or EMT condition	Voltage/frequency setpoints, PPC mode, SOC, grid strength, protection state	Dynamic load composition, backup generation status, fast load shed, UPS and generator transition logic

Where an operating value is unknown, record an assumption explicitly. “TBD” is not a study input. A usable early-stage assumption is, for example: “BESS charging modeled at 150 MW at the POI, subject to confirmation of transmission-service rights; treated as a sensitivity, not as the base operating condition.”

---

Quality checks before accepting the package

A request checklist is only useful if it contains acceptance checks. Before modifying an authorized utility or cluster base case, perform a structured review.

Completeness

Confirm that each required item has one of four outcomes:

1. Received and accepted
2. Received but requires clarification
3. Not available yet, with an approved interim assumption
4. Not applicable, with rationale

Avoid treating a blank cell as “not applicable.”

Internal consistency

Check at least the following:

• The single-line diagram, transformer data sheets, and intended model topology agree.
• MW and MVA ratings are reconciled at inverter, transformer, plant, and POI levels.
• BESS $P_{\max }$, charging limit, duration, SOC range, and dispatch scenarios do not contradict one another.
• Reactive capability is stated at a defined MW and voltage, rather than as an unsupported single MVAr number.
• Transformer impedance base, MBASE, and dynamic-model bases are identified.
• GSU vector group and grounding agree with the short-circuit package.
• PPC measurement point and controlled point agree with the one-line diagram and dynamic model documentation.
• Plant auxiliary load is treated consistently in gross versus net capacity and shared-POI calculations.
• Dynamic-model bus numbers and machine IDs match the proposed steady-state model.
• PSCAD, PSS®E, and OEM parameter revisions are traceable to the same equipment configuration.

Engineering credibility

Finally, ask whether the package represents the actual intended operation, not merely an electrically convenient case. A model that holds the POI voltage by an unlocked shunt, ignores a BESS charge mode, or lets a data-center load ramp unrealistically slowly may converge cleanly while obscuring the real interconnection risk.

---

A concise request-package structure

A practical deliverable to send to a developer, EPC, OEM, or data-center design team can use these folders or register tabs:

1. 00_Project_Control
   Cover sheet, contacts, revision log, confidentiality instructions, and applicability-register links.

2. 01_One_Line_and_Topology
   Single-line diagrams, equipment list, ownership boundary, GIS coordinates, and status/effective dates.

3. 02_Steady_State
   Ratings, impedances, capability curves, dispatch, loads, shunts, taps, and POI limits.

4. 03_Short_Circuit
   Sequence data, vector groups, grounding, mutual impedance, and fault-current behavior.

5. 04_RMS_Dynamics
   DYR data, model libraries, manuals, PPC and protection settings, initialization notes, and validation evidence.

6. 05_EMT_PSCAD_If_Applicable
   PSCAD workspace, dependencies, instructions, test cases, and benchmark material.

7. 06_Operating_Scenarios
   Solar, BESS, hybrid, or large-load scenario tables; planned outages; and sensitivity assumptions.

8. 07_Open_Items_and_Assumptions
   Missing information, owner, due date, interim assumption, study impact, and closure evidence.

This structure separates raw technical inputs from assumptions and open issues. It also prepares the same project information for later PSS®E case construction, PSCAD MQT work, and final report traceability.

---

Key takeaways

A minimum technical-data request must do more than collect equipment ratings. It must establish:

• a clear project and model boundary;
• steady-state topology, ratings, limits, and operating data;
• sequence, grounding, and fault-behavior information;
• a complete RMS dynamic-model chain, including PPC and protection;
• a usable PSCAD package when EMT analysis is applicable;
• project-specific operating information for solar, BESS, hybrid plants, or data centers; and
• controlled assumptions, revisions, source ownership, and acceptance checks.

For solar-plus-BESS and standalone BESS projects, keep charging, discharging, SOC, auxiliary load, and POI limits explicit. For data centers, model the demand trajectory and reliability/transfer architecture rather than treating the facility as one static MW value.

In the next module, you will begin hands-on PSS®E work with the WSCC/IEEE 9-bus system, starting by understanding its buses, generation, loads, transmission paths, and its limitations as an interconnection-study model.