Transmission Planning Study Management: Why You Cannot Reproduce Last Year's Violation List When a Developer Challenges It

Why the study, not the solver, is the thing that breaks

A planning engineer has a network drive open. Inside is a directory called 2026_Summer_Peak, and inside that are 41 saved cases with names like base_final_v3_rev2_USE_THIS and base_final_v3_rev2_afterRetireFix. She is trying to answer a question from an interconnection customer's consultant: why does your study show a thermal violation on a 138kV line that our own model does not show. To answer it she needs to know which base case vintage was used, whether the generator retirement list included the coal unit that was still under evaluation in March, what transfer level was dialed in, and which contingency file version was applied. Two of those four facts exist only in an email thread she has to search.

Nothing here is a simulation problem. PSS/E solved the power flow correctly. PowerWorld would have solved it correctly. TARA would have chewed through the contingency set faster. The engineering is fine. What failed is that a study is a composition of a model version, an assumption set, a contingency definition, a set of parameters and a code path, and the composition lives in a folder name and a person's memory.

The stakes have moved. Interconnection queue reform under FERC Order 2023 pushed the industry into cluster studies with firm deadlines and consequences for missing them, which turns study throughput into a compliance issue rather than a workload issue. FERC Order 1920 pushed long-term regional planning scenarios into the same pipeline. Each RTO's business practice manuals dictate the study process and the reporting format. A planning group that could previously absorb inefficiency with overtime cannot absorb a case count that grew by an order of magnitude.

Problem 1: case lineage is the whole product and no tool provides it

Every violation in your report is the output of a specific composition. Change the load forecast vintage and the violation moves. Change one retirement assumption and it disappears. Six months later, when a developer disputes a network upgrade cost assignment or an intervenor challenges the need for a project, you have to reproduce the exact composition that produced the result. Right now most groups reproduce it approximately, and approximately is not a defensible answer in front of a commission.

The commercial tools do not track this because it is not their job. PSS/E manages a case. PowerWorld manages a case. Neither manages the relationship between forty cases, the assumption set each embodies, the script version that transformed one into another and the results each produced. Version control on the saved case files themselves is little help because they are opaque binaries and the meaningful diff is not byte level, it is a change list: this generator dispatched down, this line added, this load scaled by a factor.

What a custom build does: model the study as a directed graph. A base case is a node. Every transformation is an edge carrying the script, its parameters and who ran it. The resulting case is a derived node that is regenerated rather than stored where storage is a concern. Every results record carries the identifier of the node that produced it. Then reproducing a year-old result becomes replaying a path, and answering a consultant's challenge takes twenty minutes instead of three days of archaeology.

Problem 2: batch orchestration is done with a script and hope

Contingency analysis across a full case set is compute-bound and embarrassingly parallel, and most planning groups run it on a workstation under someone's desk overnight. The pattern is a Python script driving the solver, writing results to a directory, and no supervision. If case 340 of 600 fails to converge, the script may keep going or may stop, and either way nobody finds out until morning. Then the engineer reruns everything because they cannot tell which results are stale.

Licensing shapes this too. Solver licenses are a real constraint on how much you can parallelize, and a naive job runner will either exhaust the license pool and fail loudly or serialize itself into uselessness. Any orchestration layer that ignores license accounting is not usable in production.

What a custom build does: a proper job queue with license-aware concurrency, per-case status, automatic retry on transient failure, and explicit non-convergence handling that flags rather than silently drops. Jobs run on whatever compute you have, whether that is a set of on-premise machines or cloud instances, and the queue knows which runs are still valid because it knows what inputs they depended on. When a base case is corrected, the system marks exactly the downstream results that are now stale rather than making an engineer guess. That single behavior removes most of the wasteful rerunning.

Problem 3: assumptions live in email, spreadsheets and one person

A planning assessment carries a set of decisions that are not in any model file: which load forecast vintage, which retirements are firm versus announced, which interconnection queue positions are assumed in service, DER and behind-the-meter adoption, transfer levels, and what counts as a firm transmission plan from a neighboring system. Those decisions get made in meetings, recorded in a spreadsheet, and applied by hand or by a script whose parameters someone typed.

The recurring failure is silent divergence. Two engineers on two study tracks apply the same assumption slightly differently. A revised load forecast lands in April and gets applied to the summer cases but not the shoulder cases. Nobody notices until the results disagree in a way that requires explanation, and by then the explanation is expensive.

What a custom build does: assumption sets become versioned, named objects with effective dates and an owner, referenced by the study rather than copied into it. Applying an assumption set is a transformation edge in the lineage graph, so it is auditable. When a forecast is revised, the system lists every case and every result that used the prior version. This is unglamorous data modeling and it prevents the class of error that is hardest to find, because a wrong assumption produces perfectly convergent, perfectly plausible, perfectly wrong results.

Problem 4: results are enormous, and the report format is somebody else's decision

A full assessment across seasons, scenarios and contingency sets produces result volumes that Excel cannot hold and that engineers nonetheless try to hold in Excel. Then the reporting requirement arrives from the RTO business practice manual in a defined format, and someone spends two weeks reshaping data by hand into it.

Worse is the deduplication problem. The same physical violation appears across dozens of contingencies, seasons and sensitivity runs, and the useful output is not a list of violations but a list of distinct problems ranked by how often and how badly they appear. Doing that reduction by pivot table is where planning engineers lose their weeks, and it is the part that most benefits from being automated once.

What a custom build does: land results in a columnar store, then compute the reduction as a query rather than as a manual exercise. A violation gets a stable identity across runs based on the monitored element and the limit type, so you can look at one branch across four seasons and eight scenarios and see the pattern immediately. The RTO-format report is then a rendering step off that store, so a format change is a template edit rather than another two weeks. Keep the raw results, because the reduction logic will change and you do not want to rerun 600 cases to change how you group them.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, the shape for study management is consistent. A focused first release covering case lineage, versioned assumption sets, license-aware batch orchestration and a results store with basic reduction runs $80,000 to $170,000 and ships in 12 to 18 weeks. A full platform adding cross-scenario violation identity, RTO-format report generation, sensitivity study management, a reproducible study package for external parties and integration with your model management runs $200,000 to $500,000 phased over 6 to 12 months.

What drives it up: the number of distinct solvers in play, because driving PSS/E through its Python API, PowerWorld through SimAuto and TARA through its own interface are three integrations, not one. EMT work in PSCAD alongside steady state, which is a different data and runtime problem entirely. Multiple RTO footprints with different manuals. And stability work, since dynamic simulation results are far larger and the post-processing question is different from thermal and voltage screening.

What keeps it down: start with one study type, usually the annual thermal and voltage assessment, and one solver. Get lineage and orchestration right on that before extending. Groups that try to model every study the department performs before shipping anything spend a year specifying.

Build versus buy, and when buying is right

Buy the solvers, always. Siemens PSS/E, PowerWorld Simulator, DIgSILENT PowerFactory, PowerGEM TARA and PSCAD represent decades of validated numerical work, and any suggestion that you build your own power flow or dynamics engine should end the conversation. What none of them sell is the workflow around them, because that workflow is shaped by your RTO's manuals and your internal review process.

Do not build at all if your group runs a handful of studies a year on a small footprint with two engineers who genuinely do hold the composition in their heads. Disciplined naming conventions and a shared assumption spreadsheet will carry you further than people expect, and the money is better spent on solver licenses and compute.

Build when two or more of these are true. Cluster study deadlines under the current interconnection process mean your throughput is a compliance exposure. You have been asked to reproduce a result more than a year old and struggled. Your case count per assessment cycle runs into the thousands. More than three engineers touch the same study track. Or a study result of yours has been challenged by a developer or an intervenor, because that is the moment lineage stops being a convenience and becomes evidence.

How to choose a developer for transmission planning tooling

Ask whether they will store derived cases or regenerate them. The right answer is usually regenerate from lineage, storing selectively, and a developer who has not thought about it will propose keeping every binary and quietly hand you a storage problem measured in tens of terabytes.

Ask how they handle solver license limits in the job queue. If they have not considered it, their orchestration will fail the first time it tries to run 30 concurrent jobs against a pool that allows eight.

Ask what they do with a non-convergent case. The answer must include flagging, classification and preserving the failing inputs for an engineer to inspect. Anything that quietly drops non-convergent results is producing a study that understates problems, which is the worst possible failure in this domain.

Ask who owns the code and get it in writing before kickoff, including the right to export the results store in an open format. At Digital Heroes the client owns the code from the first commit. Then give the candidate developer one real past study and ask them to sketch how their model would represent it. A planning engineer in the room will know in fifteen minutes whether the sketch survives contact with your actual process.