Public safety power shutoff (PSPS) scoping

Industry Sector: Utilities

Business Function: Operations

An electric utility may perform Public Safety Power Shutoff (PSPS) in the event of a severe risk of wildfire ignitions due to high wind speeds. PSPS represents a race against the clock with zero tolerance for inaccuracies to ingest data, process it, enable user inaction and write it to an external system. Foundry is used to plan and execute these PSPS events from start to finish, delivering accuracy, timeliness, auditable traces, and providing a learning loop to improve future operations.

Challenge

An electric utility is exposed to locally severe weather events posing the risk of wildfire ignitions due to high winds. In a hot, dry environment, this can lead to rapidly spreading fires, catastrophic environmental consequences and deaths. As a measure of last resort, the electric utility will perform Public Safety Power Shutoff (PSPS) events where they will turn off the power (de-energize) on selected "monitored circuits" for a given "period of concern".

This process represents a race against the clock with zero tolerance for inaccuracies to ingest data, process it, enable user inaction and write it to an external system. Required collaboration of multiple teams, large number of integrations at every step from both internal and external systems posed further challenges to this use case.

Solution

Foundry is used to plan and execute these PSPS events from start to finish. It is critical that they operate these emergency events with high accuracy, speed, auditability, and transparency as they need to report out to their local regulator who will evaluate the compliance with public safety.

Once a PSPS event is foreseen, the utility will trigger a series of communications to its customers warning them about possible de-energization. This series starts 72 hours before the event and ends 8 hours after power is restored. As the event approaches, weather forecasts sharpen and the scope of circuits affected changes so customers need to be added/removed to the notification series at a moment's notice. In this use case, Foundry operates the whole process with customer service reps never needing to leave Foundry.

Impact

• Time to generate notifications: For notifications informing of imminent de-energization, the utility has only a few minutes to inform customers before they lose power.
• Notification accuracy: Delivering the correct message at the correct time to affected customers -- this metric is scrutinized by the regulator to represent the consumer's interest.
• Notification deliveries and successful contact escalations.
• Development of a PSPS knowledge base to improve future operations.
• Ability to correct inaccurate source data, e.g. customers mapped to circuits incorrectly.
• Transparency and auditability of decision-making process.

How it's made

Foundry uses multiple triggers to generate notification flows:

• A monitored circuit list forecasted to be de-energized in advance.
• Last-minute de-energizations due to a weather threshold breach observed live.
• Manual triggers for non-programmatic needs.

Foundry processes these triggers and queries the Distribution Management System (DMS) to pull a list of customers attached to scoped circuits in the grid's currently operated state (the grid's configuration -- such as switches -- will change which circuit customers are getting their power from).

Foundry compiles the affected customers into pre-templated campaigns and applies a set of business rules (defined in Foundry Rules) to exclude customers that were possibly incorrectly included.

• If an authorization is not required, Foundry sends the campaigns and notification payload directly to a customer notification and messaging system (through SFTP) to be broadcasted to customers immediately.
• If an authorization is required, Customer Service reps will authorize the release of campaigns. Upon approval, Foundry will process the notification payload and send it to the customer messaging system for immediate broadcasting.

Customer Service reps will review the list of programmatically excluded customers and mark them to be force included/exclude throughout the rest of the notifications for a given event. Once sent, Foundry receives the notification results returned by the broadcast (e.g., delivered, undelivered). Foundry reports are updated on high-priority customers that were unsuccessfully contacted so that Customer Service reps can attempt contact again. If contacts remain unsuccessful, Customer Service reps will mark specific customers for escalation to the Consumer Affairs team, which will deploy a team to knock on the door of critical customers who haven't been contacted.

Consumer Affairs users record the escalation process in Foundry and Customer Service reps monitor the whole notification process during an event, including:

• The number of customers affected and their nature,
• The success of campaigns (delivered, undelivered, etc.) marking the approach of an event (h-72, h-48, h-24, etc.),
• The exclusion process, and
• The escalation process.

Implement a similar use case

This use case implements the following Patterns. Follow the links below to read more about a particular Pattern and learn how it is implemented within Foundry.

• Alerting workflow (used for 7 other use cases)
• Operational process coordination (used for 8 other use cases)

Want more information on this use case? Looking to implement something similar? Get started with Palantir. ↗