GridCORTEX Live · Flagship Scenario  ·  ← All Demos
On this page What you are watching The business case Run this at your utility Where you see it and how you say yes

Manual Load Shed Synthetic Data · Simulation

The order every distribution operator dreads: "Shed your share. Now." Watch a full EEA-3 firm load shed event, end to end: the ISO calls three times, 10, 20, then 30 MW of obligation, while GridCORTEX computes the sheddable pool (hospitals, water, and pipeline feeders excluded), splits blocks at mid-feeder reclosers for double the rotation depth, dispatches distributed generation and batteries to shrink the shed itself, and rotates outages so no customer sits dark longer than five minutes. Then restoration in ISO-released stages (through a stuck breaker and a fault on pickup) ending with the complete event report, written before the phones stop ringing.

14:00
EEA-2: WATCHING
⏳ DECISION POINT: TIME SLOWED
SYNTHETIC DATA
Energized Shed block (rotating) Just restored Critical, never shed Mid-feeder recloser DER/DG carrying load Failed device / fault

EEA-3 Event Report, auto-generated

Every order, block, rotation, exception, and customer-minute, written by the agent during the event
,
Longest single outage
,
ISO compliance (3 orders)
,
Critical loads interrupted
ISO Order Compliance Log
OrderReceivedObligationMet AtResponseStatus
Exceptions: Blocks Not Restored Normally
ElementIssueAction TakenCustomersOutage
Rotation Performance
WithoutWith GridCORTEXΔ
Event Totals
WithoutWith GridCORTEXΔ
Illustrative simulation on synthetic data; obligations, device behavior, and durations are placeholders. In a GridCORTEX pilot, the shed orchestrator is built from YOUR feeder criticality data, YOUR recloser fleet, and YOUR DER portfolio, and drilled against your last EEA event. See UC 1.10 "Demo and Proof Plan."
0 MW
ISO obligation (net)
0 MW
Shed now · DER offset
0:00
Longest current outage
0
Customers dark now
Event Feed: ISO · control room · human-in-the-loop
Order 1
Order 2
Order 3
Restore
Report
The Validated Use Cases Behind This Scenario
UC 1.10
Rotating Load Shed Orchestration
The whole demo: sheddable pool, rotation cadence, DER offsets, and the compliance clock, computed, not improvised.
UC 1.6
Critical-Load Impact Modeler
Why the water plant never went dark: criticality mapped to every feeder segment, not remembered under pressure.
UC 6.3
DER Flexibility Optimizer
The megawatts that never had to be shed: batteries and DG dispatched to shrink the obligation itself.
187 UCs
One Framework
Manual Load Shed is one of 187 validated use cases across 10 solution areas and 23 utility domains.
Inside the Demo
What you are watching, and what it proves

It is 14:00 in a fictional utility's control room, and the regional grid is one step from emergency blackouts. The regional grid operator (the ISO), the organization that runs the grid and the electricity market, has declared an alert called EEA-2, level 2 of its Energy Emergency Alert scale: record heat, two power plants tripped offline, and no more power left to import. The dreaded next step is EEA-3, when the operator orders utilities to deliberately cut power to paying customers, called firm load shed, because cutting some customers on purpose is the only way to keep the entire grid from collapsing. GridCORTEX set the board an hour earlier. It computed which customers can safely take turns going dark: 29 rotatable blocks totaling 61 megawatts (MW), built around reclosers, automated switches partway down a power line that let just a section be turned off. It locked 10 critical lines out of the pool entirely: the regional hospital, water treatment, a gas compressor, the 911 center, a dialysis cluster, and more. And it verified 6.8 MW of helper resources ready: batteries, a small local generating plant, and businesses paid by contract to cut their use on request. Then the recorded line rings three times. At 14:04 the grid operator orders 10 MW of firm load shed, with 15 minutes to comply; at 14:28 the obligation doubles to 20 MW; at 14:50 a third order takes it to 30 MW. The clock runs from 14:00 to about 16:20, through the shed, the staged restoration, and the automatically written event report.

Each order is a decision point, and a human shift supervisor approves every response, because deliberately turning customers off is the most serious thing a utility does. The response to Order 1 dispatches the helpers first: the Bayshore battery (2.4 MW) plus the Midtown generating plant (1.8 MW), so 4.2 MW never has to be taken from anyone. The remaining 5.8 MW rotates across the pool, where the mid-line switches split 11 lines into half-blocks, doubling the number of groups that can share the burden, on a schedule that keeps no block dark longer than 5 minutes. Order 2's response adds the third helper, 2.6 MW from businesses under cutback contracts (total offset 6.8 MW), and widens the rotation to about 7 blocks dark at a time; the obligation is met in 4 minutes. Order 3's response rotates the full 23.2 MW that remains after the helpers, and is met in 3 minutes with the 5-minute promise still holding: each block spends 38% of the time dark and rests about 9 minutes between turns, the longest outage is 4 minutes 52 seconds, and the water plant and hospital lines are confirmed live on the control room's monitoring screens throughout.

The fourth decision point arrives with the 15:15 release order, when the grid operator starts letting load come back. Restoration has a trap: after an outage, air conditioners and appliances all restart at once, so each restored block briefly draws about 1.35 times its normal load. The approved plan restores the hardest-hit blocks first, spaces the switch closures 90 seconds apart so no transformer is overloaded, and keeps the helper resources running until the obligation falls below 5 MW. Then come the night's two curveballs. At 15:35 the breaker on line FDR-112 refuses its remote close command, a mechanical alarm, so a crew is dispatched and the rotation re-plans around the stuck block until a manual close ends its 31-minute outage, logged as an exception. At 15:48 line FDR-121 fails under the restart surge; its automated switch isolates only the faulted section, so 61% of that line's customers come back anyway while 420 stay out with a crew on the way.

With all four approvals, the emergency ends at 15:58. Every rotation block is back except the two logged exceptions, and every restored block lands inside equipment limits with zero repeat trips. By 16:13 the event is closed: 41,000 customers touched, longest routine outage 4 minutes 52 seconds, zero critical facilities interrupted, and the full event report, covering orders, blocks, exceptions, fairness, and helper output, is already assembled from the automatic decision log. The closing screen shows that report, including the 3-for-3 compliance record, next to the binder-and-spreadsheet version of the same night.

Without GridCORTEX

The binder plan sheds four whole lines from a 2019 spreadsheet, including FDR-108, which feeds the water treatment plant; the city learns that by phone when the plant goes dark. The plan fails because it does not know what is on each line today, cannot turn off anything smaller than a whole line, and has nothing that shrinks the order itself. Manual rotation runs about 30 minutes behind while operators build switching lists by hand, and the third order means eight whole lines dark on a roughly 40-minute cycle with no helper megawatts.

Restoration without staging trips two lines straight back out under the restart surge; they are shed and restored twice. The night ends with a 47-minute maximum outage, a water plant on backup power for 118 minutes, only 1 of the 3 orders met on time, roughly 1.9 million customer-minutes of outage (one customer dark for one minute is one customer-minute), and the record of it all living in nine operators' memories, to be reconstructed over three weeks for the inevitable inquiry.

With GridCORTEX

The software computes the pool of sheddable customers live, block by block down to the switch level, with critical lines excluded segment by segment. It dispatches the helper resources first, so 6.8 MW of the 30 MW order never sheds anyone. Its rotation engine holds every routine block under 5 minutes dark while spreading the burden fairly across neighborhoods. Every step keeps a person in charge: the shift supervisor approves all four recommendations, and operators execute every switching action through the utility's own control system.

The winning numbers: all 3 orders met within minutes, longest routine outage 4:52, zero critical facilities interrupted, zero repeat trips on restoration, roughly 0.6 million customer-minutes instead of 1.9 million, and a regulator-ready event report generated during the event, finished the same night.

The results, side by side
MeasureWithout GridCORTEXWith GridCORTEXThe difference
Longest routine outagethe longest any normally rotated block sat dark, not counting the two logged equipment exceptions47 min4:52the 5-minute promise kept
Rotation cadencehow quickly the dark blocks are swapped so nobody sits out longmanual, ~40 mincomputed, 5 min8× tighter
Rotatable blockshow many separate customer groups can take a turn; more blocks means a shorter turn for each8 whole feeders29 (reclosers split 11)3.6× finer control
Critical loads interruptedhospitals, water plants, and other facilities that must never be shed1; water plant, 118 min0the headline
MW shed at peak orderhow much customer load actually had to be turned off to meet the 30 MW order; DER means distributed energy resources, the batteries, local plant, and contracted cutbacks that covered the rest30 (no offset)23.2 (DER carried 6.8)23% less shed
Blocks cycledwhich customer groups took turns going dark, and whether the burden was shared8, repeatedlythe full pool, equitablyburden spread
Cold-load re-tripslines that fail again under the surge of everything restarting at once after an outage2 feeders0; staged pickupsengineering
Customer-minutes (order-of)the total outage burden: one customer dark for one minute counts as one customer-minute~1.9M~0.6M68% less time dark
Customers touchedhow many customers experienced at least one rotation outage, and how long each turn lasted~52,000, some 3×~41K, max 5 min eachfairness
ISO compliance recordwhether each of the grid operator's three orders was met inside its 15-minute deadline2 of 3 late3 of 3 in minutesno penalty exposure
DER contributionenergy supplied by the batteries, the local plant, and the contracted cutbacks instead of shedding customers; MWh is megawatt-hours, one megawatt sustained for one hour0 MWh~9 MWh carriedshed avoided
Event reportthe full record of orders, actions, and outcomes the regulator will ask for3 weeks, from memorygenerated during eventsame night
Regulatory posturehow well the utility can defend every decision after the eventinquiry defenseevery action logged as it happenedevidence built in
Media storythe headline the public reads the next morning"water plant dark""5-minute rotations held"reputation
The live numbers on the dashboard
ISO obligation (net)The megawatts of customer load the grid operator currently requires the utility to keep switched off. It steps up 10, 20, 30 MW as the orders land, then steps back down through the staged releases. 0 is the reading everyone wants.
Shed now · DER offsetTwo numbers that tell the whole strategy: the megawatts of customers actually dark right now, versus the megawatts covered by batteries, the local plant, and contracted business cutbacks so nobody has to be. The bigger the second number, the better.
Longest current outageThe clock on whichever block has been dark the longest. Staying under 5:00 all night means the rotation promise is being kept; a reading near the old playbook's 40-plus minutes means it is broken.
Customers dark nowHow many customers sit in switched-off blocks at this moment. Smaller, switch-split blocks keep this number low and keep each customer's turn short.

The Business Case: Safety, Hours, and Cost

A utility does not buy a demo. It buys a safety exposure that goes away and a cost that goes down. Below is that case for every use case behind Manual Load Shed, written the way a plant manager, a safety lead, and a CFO each need to read it. Every hour and every dollar is a formula you run with your own rates and volumes. There are no vendor benchmarks in here and no invented percentages. If a number is not yours, it is not a number.
UC 6.3 DER Flexibility and Curtailment Optimizer

What happens today, without this

On a clear shoulder season afternoon, solar output climbs past what a feeder can take. A DER operations engineer, working from a spreadsheet and a phone call to the control room, decides who gets curtailed. In practice that decision is blunt: a fixed export limit applied to the largest resource on the feeder, or a blanket curtailment across the whole feeder, because there is no time to work out a better answer while the constraint is live. Afterward, someone reconciles curtailed megawatt hours by hand for settlement, usually weeks later.

What it replaces or shrinks

  • The phone call and spreadsheet that decide which resource gets curtailed while the constraint is live
  • Blanket feeder wide curtailment applied because a per resource answer takes too long to compute
  • The ad hoc power flow check an engineer runs to confirm a curtailment will actually clear the violation
  • Manual after the fact tallying of curtailed energy for settlement and for developer disputes
  • Shrinks the operator task to reviewing and approving a dispatch plan rather than constructing one

Why it is safer

The safety effect is indirect and worth stating honestly. Managing over generation with dispatch rather than with hardware and switching means fewer manual field actions taken under time pressure on a constrained feeder.

Counted in units you already track:

  • Switching operations performed to reconfigure a feeder during an over generation period
  • Road miles driven for field trips to adjust regulator or inverter settings reactively
  • Energized area entries for equipment work triggered by over voltage conditions

Man-hours it gives back

Event handling hours come back to the DER operations engineer on shift, and settlement hours come back to the back office analyst who reconciles curtailment.

HOURS AVOIDED PER YEAR = over generation days per year x constraint events per day x engineer minutes per event to select, communicate, and confirm a curtailment, plus settlement reconciliation hours per month x twelve, minus the operator review minutes per recommended dispatch plan.

The numbers we need from you to run that formula:

  • Over generation days per year and typical constraint events per day
  • Engineer minutes spent per event today selecting and communicating curtailment
  • Monthly hours spent reconciling curtailed energy for settlement
  • Enrolled flexible capacity by resource type and the compensation terms for each
  • Loaded hourly rate for a DER operations engineer and for a settlement analyst

Where the dollars come from

Cost driverHow it is calculated, from a rate you supply
Avoided curtailment paymentsmegawatt hours of curtailment avoided x your compensation rate per megawatt hour under the applicable interconnection or program agreement
Operations laborevent handling hours avoided x your loaded DER operations engineer rate
Settlement laborreconciliation hours avoided x your loaded settlement analyst rate
Deferred reinforcementyour own cost per feeder or transformer upgrade x the upgrades you judge deferrable because flexibility now manages the constraint
Make whole exposureyour contractual make whole or lost production payment per megawatt hour x megawatt hours no longer curtailed

Reliability and maintenance

Reliability
This holds voltage and thermal limits without switching, so it removes a category of power quality complaint rather than a category of outage. If your over generation periods currently end in a regulator or inverter trip, then it touches SAIFI, the system average interruption frequency index, for the customers downstream of that device.
Maintenance
Managing over generation through dispatch instead of through voltage regulation means fewer tap changer and regulator operations. Operation counters are already how you set maintenance intervals on those devices, so fewer operations directly extends the interval.

What else it moves

CustomerDER owners see curtailment allocated by a rule they can inspect rather than by whoever was easiest to call, which is most of what curtailment disputes are actually about.
ComplianceA per event record of what was curtailed, why, and what the alternative would have cost, which is the record a regulator asks for when curtailment volumes get attention.
WorkforceThe engineer on shift stops improvising under time pressure, which is the part of the job that burns people out.

What it costs you, stated honestly

You pay for the scoped engagement that builds and runs this, for the integration into your DERMS, the distributed energy resource management system, and for telemetry quality work on enrolled resources, because an optimizer is only as good as the measurements it dispatches against. Plan on running it in shadow mode through one shoulder season while your operators build trust, and count that operator time as real cost.

How to build the payback case

Payback is dominated by avoided curtailment payments if you compensate for curtailed energy, and by deferred reinforcement if you do not. Work out which of those two you actually are before you build the case.

This is a planning model built from your event counts, your compensation rates, and your labor rates, not a vendor claim. Re run it against the actuals from your first over generation season.
UC 1.10 Rotating Load Shed Orchestration

What happens today, without this

In a capacity emergency the senior distribution operator builds the rotation from a printed block list and a spreadsheet, tracks by hand which block has been out how long, and checks critical feeder exclusions against memory and a separate list. Notifications go out by phone tree to the customer team, the media team, and the commission. Then, for weeks afterward, staff reconstruct from logs exactly which block went out when, for how long, and who was on it, because that is what the commission will ask for.

What it replaces or shrinks

  • The spreadsheet rotation list and the manual timekeeping of how long each block has been out
  • Manual cross-checking of critical feeder and medical baseline exclusions before each block
  • Hand building the customer and regulator notification list for each rotation block
  • The phone tree to customer care, media relations, and emergency management at each block change
  • Shrinks the after-event reconstruction of the shed record for regulatory filings

Why it is safer

Worker exposure is not the main story here and we will not pretend otherwise. The direct safety mechanism is public: life support customers, water pumping, and emergency communications stay energized because the exclusions are enforced by the plan rather than by an operator's recall under extreme pressure, and no block gets held past its planned duration because a timer was missed.

Counted in units you already track:

  • Switching operations performed per rotation block, and the extra operations caused by ad hoc replanning
  • Road miles driven by field staff repositioning during an emergency rotation
  • Night driving hours for staff mobilized during a multi-day capacity emergency

Man-hours it gives back

Plan building and block tracking hours come back to the operators and support staff working the emergency, and reporting hours come back to the regulatory team afterward.

HOURS AVOIDED PER YEAR = shed events per year x (plan build hours + blocks per event x hours per block x staff involved in tracking and notification), plus post-event regulatory reporting hours per event x events per year, minus the operator verification time per block, which stays, because an operator confirms and executes every block through your own control system.

The numbers we need from you to run that formula:

  • Shed events in your recent history and blocks per event, from your own event records
  • Hours spent building the initial rotation plan and hours per block on tracking and notification
  • Staff involved during an activation, and the overtime or callout premium that applies
  • Post-event regulatory reporting and inquiry hours per event
  • Loaded hourly rate for a senior operator, customer care staff, and a regulatory analyst

Where the dollars come from

Cost driverHow it is calculated, from a rate you supply
Emergency staffingactivation hours avoided x staff involved x your loaded rate at the overtime and callout premiums that apply during an emergency
Regulatory reportingpost-event reporting and data request hours avoided x your loaded regulatory analyst and legal support rate
Customer care volumecalls avoided through accurate, block-specific notification x your own fully loaded cost per contact center call
Over-shed energymegawatt hours shed beyond the required amount x your own value of lost load or your own cost per unserved megawatt hour, a figure you set
Switching device dutyrotation operations avoided x your maintenance cost per operation, since operation counts drive recloser and breaker inspection intervals

Reliability and maintenance

Reliability
This is a load shed tool, so the honest framing is not SAIDI improvement. It touches how much load is shed, for how long, and how evenly it is spread across customer groups, which shows up in customer minutes interrupted and in customers experiencing multiple interruptions. Under most major event day practices the shed itself sits outside your reported indices, and your commission will be looking at the equity of the rotation instead.
Maintenance
Rotation operations get spread across devices rather than concentrated on the same reclosers and breakers block after block, which keeps operation counts, and therefore your condition based inspection and overhaul intervals, from bunching on a handful of assets after a single emergency.

What else it moves

ComplianceThis is the most regulatory exposed manual process in the control center. A timestamped, per-block record showing the required load shed, the exclusions enforced, and the notifications issued is exactly what the post-event proceeding asks for, generated as you go instead of reconstructed later.
CustomerCustomers accept a rolling outage far better when the block, the duration, and the reason are communicated per block and the rotation is visibly fair. Medical baseline and life support customers get handled as a category rather than as exceptions somebody remembers.
Insurance and riskDocumented enforcement of critical load exclusions during an emergency is a defensible control if a facility later claims it should never have been shed.

What it costs you, stated honestly

You pay for the scoped engagement that builds and runs this, for integrations to your ADMS, advanced distribution management system, your customer information system, and your GIS, and for the designation work underneath: somebody on your side has to establish and defend which feeders are critical and which customers are medical baseline, and keep that current. Add drill time, because a tool nobody has practiced with is not going to be trusted during the one hour it matters.

How to build the payback case

Payback here is awkward and you should hear it straight: capacity emergencies are infrequent, so an hours-per-event case built on frequency will not hold up. Build it on the preparation and the post-event regulatory reporting work, which happens whether or not you shed, and treat the emergency day savings as the reason it exists rather than the reason it pays.

This is a planning model built from your own event history, staffing, and rates, not a vendor claim. Re-run it after your first drill and again after the first real activation, because the drill will not tell you everything the real event will.
UC 1.6 Cascading Critical-Load Impact Modeler

What happens today, without this

The list of critical customers, hospitals, dialysis centers, water and wastewater pumping, telecom hubs, data centers, lives in a spreadsheet maintained by the key accounts team and it goes stale between updates. Before planned switching, a planner or customer representative traces the feeder downstream on a map, cross-checks the spreadsheet, and starts making phone calls to ask facilities managers whether their generator works and how long it runs. During a real event the emergency operations center works from a printed list. Afterward somebody reconstructs by hand who was out and for how long.

What it replaces or shrinks

  • Manual downstream tracing from a switch to work out which facilities are affected
  • Reconciling the key accounts critical customer spreadsheet against the current connectivity model
  • Phone calls to facilities managers to ask about backup generation and runtime
  • Building the restoration priority list by hand at the start of an event
  • Shrinks the after-event reconstruction of which critical facilities lost power and for how long

Why it is safer

The exposure this removes is mostly public safety rather than worker safety, and it is worth saying so plainly. The mechanism is that a facility with life support, water pressure, or emergency communications does not discover mid-outage that it was downstream of a switching action nobody modelled. There is a smaller worker benefit: fewer switching jobs get executed and then reversed when the impact is discovered late.

Counted in units you already track:

  • Switching operations performed and then reversed after a downstream impact is discovered
  • Road miles driven by field and customer staff responding to a critical facility after the fact
  • Night driving hours for emergency generator delivery and standby trips

Man-hours it gives back

Tracing and phone call hours come back to the planners and the key accounts team, and list building hours come back to the emergency operations center during events.

HOURS AVOIDED PER YEAR = planned switching jobs per year x hours spent per job identifying and notifying affected critical customers, plus event days per year x emergency operations center staff x hours per day spent building and updating impact lists, plus after-event reconstruction hours per event x events per year, minus the review the customer team still does to confirm contacts and facility status before anyone is called.

The numbers we need from you to run that formula:

  • Planned switching jobs per year that require critical customer notification
  • Hours currently spent per job on tracing, checking the list, and calling
  • Event days per year, emergency operations center staffing on those days, and hours spent on impact lists
  • Count of designated critical facilities and how often the registry is currently refreshed
  • Loaded hourly rate for a planner, a key accounts representative, and emergency operations staff

Where the dollars come from

Cost driverHow it is calculated, from a rate you supply
Planning and notification labortracing and calling hours avoided x your loaded planner and key accounts rate
Emergency operations staffingevent day hours avoided x staff involved x your loaded rate, at the overtime rate that applies during activations
Avoided rework switchingswitching jobs reversed or re-scheduled per year x crew size x hours per reversal x your loaded crew rate
Emergency generationstandby or emergency generator deployments avoided x your own contracted mobilization and daily rate
Reporting and inquiry responsepost-event reconstruction and regulatory inquiry hours avoided x your loaded analyst rate

Reliability and maintenance

Reliability
This does not change SAIDI, the system average interruption duration index, and claiming it does would invite the wrong argument. What it changes is who is out and in what order they come back. The metrics it actually touches are critical facility interruption minutes and your restoration priority sequencing, plus customers experiencing multiple interruptions if resequencing spreads the impact more fairly.
Maintenance
The critical customer registry stops decaying. Because the model reconciles the registry against your connectivity model and customer information system on an ongoing basis, additions, moves, and retired accounts get caught as they happen instead of at the next annual review.

What else it moves

ComplianceMany states now carry explicit obligations around critical facilities, medical baseline customers, and equitable restoration. This produces the documented downstream analysis those obligations expect, per switching action, with a timestamp.
CustomerA hospital or water utility that gets a specific, accurate call before a planned outage is a very different relationship from one that gets a general notice and a surprise.
Insurance and riskDocumented pre-switching impact analysis is exactly the artifact your legal team wants to hold when a critical facility claims it was not warned.

What it costs you, stated honestly

You pay for the scoped engagement that builds and runs this, for integrations to your GIS, your customer information system, and your OMS, and for the registry work. The registry work is the real cost and it is yours: somebody on your side has to validate which accounts are genuinely critical and confirm backup generation attributes, and no model can invent that. Expect the first pass to be a few months of key accounts effort.

How to build the payback case

Payback is driven by planner and key accounts hours plus avoided rework switching, all of which you can count. The avoided consequence, the outage that would have hit a hospital, is the reason people buy it and the number you should keep out of the base case.

This is a planning model built from your job counts, your registry size, and your rates, not a vendor claim. Re-run it after the first planned outage season with the actual hours your team spent.
Each of these opens in full on the use case page, alongside the integration plan, the data ask, the path to production, and the operator console. Open the use case library.
For Your Architects and Data Owners
Run this at your utility

What is this, exactly? It is AI software: intelligent agents and models built and delivered by SoftServe, running on NVIDIA accelerated computing. It is not a hardware appliance and it does not replace the systems you run today. It deploys in your own cloud or on your premises, connects read-only to your existing systems, and recommends; your people approve every action, starting in shadow mode until it earns trust.

An emergency decision-support service that builds and continuously updates a rotating load shed plan: which feeders to rotate, in what order, while protecting critical loads and keeping the rotation fair across customer groups. Operators see a recommended schedule; nothing executes without their action in the existing control system. The demo above uses synthetic data; everything below describes what the real deployment needs from your organization.

Systems it connects to

Your systemTypical productsHow we connect
Advanced Distribution Management System (ADMS)Schneider EcoStruxure ADMS, GE Vernova PowerOn, Oracle NMSread-only API
Customer Information System (CIS) / billingOracle CC&B, SAP IS-Udatabase replica refreshed nightly
Geographic Information System (GIS)Esri ArcGIS Utility Network, GE Smallworldscheduled file export (CSV or CIM XML)
Energy Management System (EMS) / transmission SCADAAspenTech OSI monarch, GE e-terraread-only API
Metering (AMI head-end and meter data management)Itron, Landis+Gyr, Aclararead-only API
Outage Management System (OMS)GE PowerOn, Oracle NMS, ADMS outage moduleread-only API
Document and knowledge storesSharePoint, emergency operations plansdocument upload

Data it needs from you

How it runs on your systems

Because this touches emergency operations and sensitive customer data, it runs in your cloud account or fully on premises, with medical-needs data on need-to-know access. All connections are read-only with no link to control systems; any shed action is taken by an operator in the ADMS, and recommendations are written back only after a person approves, via your existing system's own interface.

Path to production

Weeks 1-5: data access and plan capture
Feeder, customer, and critical-load data are connected and the current shed plan is encoded; customer-data approvals set the pace.
Weeks 6-10: tabletop pilot
The tool replays your last emergency load shed and its recommended rotation is scored against the sequence actually used.
Weeks 11-12: evaluation
Rotation optimality, critical-load protection, and equity metrics drive the go or no-go decision.
Months 4-6: production hardening
Security review, isolated-mode testing, operator training, and drill integration finish.
Months 6-9: in production
During capacity emergencies operators build the rotation from the recommended schedule inside the control room workflow.

What we need from your team

Full integration, data, and timeline detail for each use case in this scenario: UC 1.10 · UC 1.6 · UC 6.3
For Your Operators and Dispatchers
Where you will see it and how you say yes

The Approve button you just clicked in the demo above is the real workflow. This is what it looks like on the screen of the senior distribution operator during a capacity emergency in the GridCORTEX console:

GridCORTEX ConsoleSigned in: the senior distribution operator during a capacity emergency
Notifications
Load shed stage 2 requested by the grid operator: rotation plan ready, 62 feeders, all critical loads excluded
Daily model refresh complete; all connected feeds healthy
Recommendation
Rotation plan: 62 feeders in 30-minute blocks, critical feeders protected
  • Sheds the required 180 MW; all 14 critical-load feeders stay energized
  • No customer group carries more than 2 rotation blocks in 24 hours
  • Customer and regulator notices drafted for each rotation block
✓ Send plan to ADMS queueModifyDecline
After you approve: The schedule loads into the ADMS switching queue where operators execute each block through existing controls, and an audit entry records who approved it and why.
Computed from data as of 17:42:10 local; every card shows the timestamp of the data behind it.

What happens when you hit approve

Approve sends the rotation schedule to your ADMS switching queue as a proposed plan in pending status; your operators execute each block through the ADMS's own controls and confirmations. GridCORTEX never opens a breaker or sheds load itself; it can only update the pending plan.

How you tell it what it cannot see

Declare the load shed event in one click and enter your obligation in MW and the duration; if the instruction also arrives digitally through your EMS or market interface, GridCORTEX picks it up and pre-fills the entry for confirmation.

Live data, not stale data

Rebuilds the rotation continuously from live ADMS and EMS state, telemetry seconds old, AMI load data as received; each schedule update shows its as-of timestamp.

Where it lives day to day

The GridCORTEX console, with the schedule mirrored in the ADMS; mobile and Teams pushes on stage changes and plan updates. The console runs in a browser beside your existing screens on day one; embedding into your own systems is a roadmap step once the read-only phase has earned trust. Approve, Modify, and Decline are all captured in an audit trail your compliance team can pull, and GridCORTEX never blocks or overrides anything in the systems you run today.

The Gap: Why Your Existing Systems Don't Already Do This

The fair question from any operations VP: "We have an ADMS, a load-shed spreadsheet, and operators who've done this, what's new here?" Here's the honest answer, and it's written in the after-action reports of every major shed event of the last decade.

What you own keeps doing its job

  • ADMS / SCADA, executes every breaker and recloser operation you watched. Nothing changes; it remains the hands.
  • UFLS, automatic under-frequency shed stays armed for the seconds-scale events. This demo is the MANUAL, minutes-scale order.
  • The load-shed plan, the regulatory requirement to have one continues; it just stops being a stale spreadsheet.
  • Your operators, every block shed and every restoration you watched was operator-approved.

The gap GridCORTEX fills, above them, not instead of them

  • The spreadsheet doesn't know what's on the feeder TODAY. Critical-load contamination changes as customers connect; the sheddable pool must be computed live, per segment, including which halves of feeders reclosers can isolate. Static plans shed water plants. It has happened.
  • Whole-feeder sheds waste the pool. Mid-feeder reclosers nearly double the rotatable blocks, smaller blocks, shorter outages, fairer rotation. No shed spreadsheet models device-level granularity.
  • Nobody's plan dispatches DER first. Batteries, DG, and demand response shrank tonight's shed by up to 6.8 MW, customers who never went dark because the obligation itself got smaller. That optimization doesn't exist in the binder.
  • Rotation under pressure is where the harm happens. Manual rotation drifts to 30–45 minute outages and repeats the same feeders. The orchestrator's cadence held every block under five minutes and spread the burden measurably; the equity number is IN the report.
  • The report writes itself. Compliance times, every block's outage minutes, exceptions with causes; assembled live (Relay traces). After the last big one, that took utilities weeks, under subpoena.
Accent, don't replace: GridCORTEX reads your criticality data, recloser fleet, DER portfolio, and live SCADA · computes the pool, the cadence, and the offsets above them · and your operators execute every action through the ADMS you already trust. The ISO gets compliance in minutes. Your customers get five-minute outages instead of forty. Your lawyers get the report the same night.
Under the Hood: What GridCORTEX Took Into Account in This Scenario

When someone asks "what did it actually calculate?", this is the list. In the simulation these factors drive the storyline; in a pilot they are computed from your GIS, ADMS, customer systems, and DER registry.

🚫 The Sheddable Pool

  • Critical-load contamination per feeder SEGMENT: hospitals, water/wastewater, gas infrastructure, medical-baseline customers, shelters, mapped to the recloser zone level, not just the feeder level
  • Mid-feeder devices (reclosers, sectionalizers) as block boundaries, which downstream halves can shed while critical upstream halves stay lit
  • Pool depth vs. obligation: 29 blocks / 61 MW available against a 30 MW peak order, rotation duty factor computed before the first breaker opens
  • Block equity history: which neighborhoods carried the last event, weighted so the burden spreads

🔄 The Rotation Engine

  • Cadence solved against the 5-minute target: block size, switching time, and pool depth determine the wheel speed
  • Cooldown constraints, no block shed again within its recovery window; cold-load pickup factor (≈1.35×) budgeted into every restoration
  • Compliance clock per ISO order: obligation met, verified by SCADA telemetry, timestamped for the report
  • Continuous re-optimization as DER output, load, and failures change the board

🔋 Shed Less, Not Just Shed Smart

  • Utility-dispatchable DER as the first resort: BESS discharge, distributed generation, C&I curtailment; every MW they carry is a block that never sheds
  • DER sustainability windows: battery duration and DG run-hour limits scheduled across the event, not burned in hour one
  • Net obligation math shown to the operator: order − DER = blocks actually rotating

🧾 Failures & The Report

  • Restoration exception handling: breaker close-failure detection (trip-coil supervision), crew dispatch, and rotation re-planning around the stuck block
  • Fault-on-pickup response: recloser lockout isolates the faulted section; upstream customers restored anyway
  • The event report assembled live: order log, per-block outage ledger, exception causes, DER contribution, equity distribution, Relay-traced, regulator-ready the same night
  • Runs on the NVIDIA Agent Toolkit: cuOpt for the rotation optimization, OpenShell-governed (recommend-only into the ADMS), always-on before the ISO ever calls

Presenter's one-liner: "The ISO called three times and we answered in minutes every time. The reclosers doubled our rotation depth, the batteries shrank the shed itself, no one sat dark longer than five minutes, the water plant never blinked, and when it ended, the report was already written. That's what a load shed looks like when it's computed instead of improvised."

GridCORTEX Live Scenario Demo · Synthetic data throughout, no ISO, utility, or actual event is depicted · GridCORTEX recommends; operators execute through the ADMS · SoftServe + NVIDIA · Created by Ronnie Mauldin, NVIDIA Solutions Director, Power & Utilities, SoftServe · JUL 2026