Navigating ERCOT Planning and Dynamic Model Requirements

Welcome back. In the previous lesson, you learned to choose power flow, short-circuit, RMS dynamics, or EMT analysis from the engineering decision and physical phenomenon. That choice only becomes useful in interconnection work when it is tied to the current governing documents.

This lesson develops a practical navigation method for ERCOT documentation. We will use a representative project: a transmission-connected $250$ MW solar plant with a $100$ MW BESS, entering ERCOT as a new resource. Your job is not to memorize every requirement. It is to reliably find the applicable source, identify its revision and authority, follow its cross-references, and extract only what the project actually needs.

By the end, you should be able to navigate among the ERCOT Planning Guide, the Dynamics Working Group (DWG) Procedure Manual, and the Dynamic Model Submittal Guideline or its current hosting package without treating any one document as a black box.

---

“Current” is a controlled-document question

In an industrial ETAP study, you may receive a client design basis, equipment data sheets, and a short list of governing standards. ERCOT interconnection work adds a more layered document environment: a live rules website, procedural manuals, submission guides, templates, project instructions, and potentially an executed agreement.

A document is not “current” merely because it was the first search result. Before extracting a requirement, capture a small document-control header:

Record	What to capture
Document title	Exact title shown in the document
Revision or version	Revision number, effective date, approval date, or publication date
Access date	The date you retrieved it
Source location	ERCOT controlled webpage or project data room
Authority stated in document	Requirement, procedure, guide, template, or reference
Project connection	Why this document may apply to this project

This is not yet a full applicability register; you will build that later. For now, it protects you from a common and expensive error: applying a superseded requirement or relying on a guidance document where the Planning Guide or a project-specific instruction controls.

For the sample solar-plus-BESS project, begin with three narrow questions:

1. Does the ERCOT generation interconnection or change process apply?
2. What does ERCOT require for dynamic-model and model-quality submission?
3. What DWG procedures or model-review expectations affect the dynamic study and model package?

Notice that these are different questions. They should not all be answered from one document.

---

Start from the ERCOT Resource Integration portal

The ERCOT Resource Integration page is a useful controlled starting point because it directs resource developers to the Planning Guide, model-quality materials, templates, and the RIOO-IS interconnection process. It is an index, however—not a substitute for reading the linked governing document.

The page establishes several important navigation anchors:

• Planning Guide Section 5.1.1 is the starting point for determining whether a new or modified generation resource must use the GINR process.
• Planning Guide Section 5 contains the broader Generation Resource Interconnection or Change Request process.
• Planning Guide Section 6.2 is identified by ERCOT’s portal as the basis for stability-model submissions and Model Quality Testing materials.
• Planning Guide Section 6.9 is identified as the provision governing addition of proposed generation to planning models.
• The Model Quality Guide and Dynamic Model Templates are operationally linked to the model-submittal process.

That is a map, not a conclusion. Your next task is to enter the actual Planning Guide and extract the project-specific requirements.

---

Navigate the Planning Guide from applicability to deliverables

For the sample project, open the current Planning Guide from the Resource Integration page and confirm its revision information in the document itself. Then work from the outside inward: applicability first, procedural pathway second, technical-model requirements third.

1. Begin at Section 5.1.1: applicability

Do not begin by searching “solar,” “battery,” or “PSCAD.” Begin with Section 5.1.1, Applicability, because it determines whether the proposed resource or modification belongs in the Generation Resource Interconnection or Change Request process.

As you read, answer these questions in your notes:

• Is the project a new generation resource, a modification to an existing resource, or a combined project with more than one relevant classification?
• Is it transmission-connected?
• Does its configuration create a special question, such as a self-limiting facility, DC-coupled battery, co-located load, or modification of an already registered facility?
• What definition, threshold, or condition makes the process applicable or inapplicable?

For the sample project, do not write “GINR applies” simply because it is a solar-plus-BESS project. Write the exact applicability basis, including the cited section and the factual project condition that satisfies it.

A defensible note has this form:

Question: Does the proposed transmission-connected solar-plus-BESS facility require the GINR process?
Source: ERCOT Planning Guide, current controlled revision, Section 5.1.1.
Project fact evaluated: New transmission-connected generation and energy-storage configuration at the proposed POI.
Finding: [Quote or concise paraphrase of the controlling condition.]
Open item: Confirm whether project configuration invokes any additional treatment for self-limiting or DC-coupled facilities.

The bracketed finding must come from the actual text you read, not from a remembered training slide.

2. Continue to Section 5: process requirements

Once applicability is established, stay in Section 5 and use its table of contents, subsections, and cross-references to identify the project pathway. Your goal is to locate requirements concerning:

• the interconnection request and information required;
• study stages, reviews, and milestones;
• technical data or supporting documents;
• responsible entities and submission mechanisms;
• modifications after the original request;
• project-specific studies or requests for information.

At this point, distinguish carefully between:

• a process requirement — for example, a required submission or review step;
• a technical assumption — such as plant rating, POI voltage, collector representation, or controller mode;
• a deliverable — a report, template, model, drawing, or data file;
• a study conclusion — whether the project passes, requires mitigation, or must be revised.

A process section may tell you when a model is required. It will often point elsewhere for how that model must be built, tested, and submitted.

3. Use Sections 6.2 and 6.9 as separate destinations

The Resource Integration portal specifically points to two later Planning Guide anchors. Treat them as separate questions:

Planning Guide anchor	Navigation question
Section 6.2	What Planning Guide obligation causes the resource to submit stability models, MQT material, or related model information?
Section 6.9	What must occur before proposed generation is added to ERCOT planning models?

Read the full subsection around each relevant sentence. A keyword hit alone is unsafe because the requirement may include exceptions, timing conditions, responsible-party language, or a reference to a separate guide.

For example, if Section 6.2 points you to a Model Quality Guide or a particular report, capture both locations:

Planning Guide Section 6.2 establishes the controlling obligation; the linked model-quality document supplies the required method, package, or format.

This two-part citation is much stronger than citing a template without identifying the rule that makes the template necessary.

---

The DWG Procedure Manual: understand its role before extracting a rule

The Dynamics Working Group is the ERCOT technical group associated with dynamic-stability studies and dynamic-model review. Its webpage explains why a DWG procedure document matters: it belongs to the part of ERCOT governance concerned with dynamic representation and stability analysis, rather than the administrative front end of an interconnection request.

The DWG webpage currently presents both earlier and later procedure-manual revisions. That is exactly why document control matters. A live page may contain historical documents, a newly approved document, and supporting material at the same time.

A repeatable DWG Manual navigation sequence

After downloading the current applicable DWG Procedure Manual, follow this sequence.

1. Read the cover, revision history, and stated scope.
   Confirm who approved the manual, whether it has an effective date, and whether it supersedes an earlier revision.

2. Read the table of contents before searching.
   This tells you the manual’s structure and reduces the temptation to treat the first search hit as the full answer.

3. Search exact cross-references from the Planning Guide.
   If the Planning Guide cites a DWG process, data requirement, or dynamic-model expectation, search the cited phrase, section number, or defined term in the Procedure Manual.

4. Search by project function, not just technology.
   Useful terms include “dynamic model,” “stability,” “resource,” “model data,” “validation,” “database,” “interconnection,” “change,” and “study.” For the BESS component, search both “energy storage” and the broader terms; documents may classify the facility functionally rather than by marketing label.

5. Read the entire operative subsection.
   Find the condition that triggers the provision, the action it requires, any exception, and the party responsible.

6. Follow cross-references back to the source document.
   If the Procedure Manual cites the Planning Guide, a protocol, a template, or another ERCOT document, open that source. A cross-reference is an instruction to verify context, not a substitute for it.

The DWG Manual may help you understand study and model-review procedure, but you must still identify its authority in the text. Some language may state a required process; other language may be explanatory or administrative. Do not label every DWG statement as an interconnection requirement unless the document, Planning Guide, or project instruction establishes that status.

---

Finding the Dynamic Model Submittal Guideline without confusing it with a template

The third document family is often where teams lose traceability. A dynamic model package can contain several related items:

• a governing Planning Guide obligation;
• a dynamic model submittal guide or instruction;
• a model-quality or MQT guide;
• dynamic model templates;
• an OEM or user-defined model package;
• PSS®E and possibly PSCAD model files;
• a completed test report and supporting plots.

These documents do not do the same job.

The ERCOT Resource Integration page identifies the Model Quality Guide as a downloadable archive supporting stability-model submission under Planning Guide Section 6.2 and Model Quality Testing. It also identifies a separate Dynamic Model Templates archive intended to facilitate collection of resource dynamic data and to accompany the Model Quality Test report.

Use this navigation sequence:

1. On the Resource Integration page, open and download the Model Quality Guide archive from the “Guides” section.
2. Extract the archive into a controlled project reference folder. Preserve the original downloaded file and do not rename over it.
3. Inventory the files: document title, revision, date, and whether it addresses PSS®E, user-defined models, PSCAD, MQT, or model-submittal instructions.
4. Locate the document titled Dynamic Model Submittal Guideline, if that is the name used in the package for your project cycle.
5. If the exact title is not present, do not silently substitute another document. Determine whether the relevant instruction has been renamed, incorporated into the Model Quality Guide, superseded, or provided through the project’s RIOO-IS materials.
6. Open the separate Dynamic Model Templates archive and identify which templates the submittal guide or Planning Guide requires.
7. Record the relationship between the Planning Guide requirement, the submittal instruction, the required template, and the expected report or model file.

This prevents a frequent mistake: treating a spreadsheet template as though it defines the engineering acceptance basis. A template usually specifies how data are organized. The Planning Guide and associated controlled guidance determine why it is required, what it must represent, and how it will be reviewed.

What to extract from the submittal guide

Once you have verified the applicable Dynamic Model Submittal Guideline, search it for the following categories. The exact headings will depend on the current revision, so use the document’s table of contents rather than assuming a fixed layout.

Extraction category	What you need to find
Applicability	Which resource types, project stages, modifications, or models fall within scope
Required model types	PSS®E, user-defined model, PSCAD, or other specified representations
Package contents	Data files, libraries, templates, single-line diagrams, reports, parameter lists, and supporting evidence
Software compatibility	Required software release, compiler, library, or model-version declarations
Naming and identification	Bus number, machine identifier, project name, file names, and revision labeling
MQT relationship	Which tests, plots, test conditions, and reports must accompany the model
Submission route and timing	Responsible entity, submission location, deadlines, resubmittal process
Acceptance and corrections	Error resolution, revisions, model updates, review comments, and validation expectations

For the solar-plus-BESS sample project, the key professional habit is to ask: Does this requirement apply to the inverter blocks, the PPC, the BESS charging mode, the solar operating mode, protection settings, or the entire plant representation at the POI?

Later in the course, you will build the PSS®E model chain in detail: converter model, electrical controller, plant controller, protection, and interfaces. At this stage, you are locating the authoritative submittal expectations so those technical models can be assembled and tested against the right basis.

---

Build a three-document navigation sheet

For each project, create a concise working sheet while you read. It is not a compliance conclusion; it is a map of what you have verified and what remains open.

Project question	Primary document to navigate	Evidence to record	Typical follow-up
Does the interconnection process apply?	Planning Guide Section 5.1.1	Applicability condition, project fact, exact section	Confirm GINR pathway and responsible entity
What process and data milestones apply?	Planning Guide Section 5	Required action, timing, deliverable, cross-reference	Identify RIOO-IS submission items
Why are dynamic models and MQT materials required?	Planning Guide Section 6.2	Controlling obligation and referenced guidance	Open model-quality and submittal materials
When does proposed generation enter planning models?	Planning Guide Section 6.9	Milestone condition and responsible party	Coordinate project model and planning-case readiness
How are dynamic studies and models handled procedurally?	Current DWG Procedure Manual	Current revision, applicable subsection, stated procedure	Check linked study or model-review references
What must be included in the model package?	Current Dynamic Model Submittal Guideline	Required files, formats, tests, versions, and naming	Assemble templates, models, libraries, and MQT evidence

A useful drafting convention is to separate three labels in your notes:

• Verified: You found the controlling provision and its project connection.
• Interpretation needed: The text is clear, but project facts or a technical assumption must be confirmed.
• Escalate: The source conflicts with another document, lacks a clear applicability statement, or requires ERCOT, the TSP, OEM, or senior engineering interpretation.

For example, an unclear question about whether a particular grid-forming BESS mode requires a particular EMT package should not be resolved by guessing from a generic guidance sentence. Mark it for escalation and cite the exact source text that created the ambiguity.

---

Common navigation failures

Searching by technology alone

Searching only “BESS,” “solar,” or “grid-forming” can miss requirements written in broader terms such as “Resource,” “Generating Facility,” “dynamic model,” or “Interconnecting Entity.” Start from the applicability and process sections, then search technology-specific language.

Stopping at a portal description

ERCOT’s Resource Integration page tells you where to go. It does not replace the Planning Guide, Procedure Manual, or the contents of the downloaded Model Quality Guide archive.

Using a link date as the governing revision

A page can host multiple revisions. Record the revision and status shown inside the actual document, along with your access date.

Separating model submission from model quality

A PSS®E dynamic model file alone is not necessarily a complete submittal. Conversely, an MQT plot package without traceable model files, parameter information, and software-version details may not be reproducible. Navigate the required package as a connected set.

Losing the controlling cross-reference

If a guidance document says “per Planning Guide Section 6.2,” read Section 6.2. If the Planning Guide directs you to a DWG procedure or model guideline, read that document too. The project requirement often exists across both documents.

---

Key takeaways

• Use the ERCOT Resource Integration portal as the controlled entry point, but extract requirements from the linked source documents.
• Begin with Planning Guide Section 5.1.1 to establish applicability, then use Section 5 for the interconnection process.
• Treat Planning Guide Sections 6.2 and 6.9 as separate navigation destinations: one concerns stability-model and MQT obligations, while the other concerns addition of proposed generation to planning models.
• Use the current approved DWG Procedure Manual to understand applicable dynamic-study and dynamic-model procedures, after verifying its revision and status.
• Find the Dynamic Model Submittal Guideline within the current ERCOT model-quality materials or through the applicable project process; do not confuse it with a template or assume a historical file name remains current.
• Record the source, revision, applicable section, project fact, and open question every time you extract a requirement.

Next, you will extend this document-navigation discipline beyond ERCOT by locating the current WECC, NERC, and transmission-provider materials that apply to a western-region interconnection task.