公共の安全のための電力遮断 (PSPS) の範囲設定

業界セクター: ユーティリティ

ビジネス機能: オペレーション

電力会社は、強風による深刻な火災発生リスクがある場合に公共の安全のための電力遮断 (PSPS) を実施することがあります。PSPSは、データの取り込み、処理、ユーザーの不作為の有効化、および外部システムへの書き込みにおいて、誤りを許さない競争です。Foundryは、これらのPSPSイベントを最初から最後まで計画し、実行するために使用され、正確性、タイムリーさ、監査可能なトレースを提供し、将来のオペレーションを改善するための学習ループを提供します。

課題

電力会社は、強風による火災発生のリスクを伴う局地的な深刻な気象イベントにさらされています。暑く乾燥した環境では、急速に広がる火災、壊滅的な環境への影響、および死亡者を引き起こす可能性があります。最後の手段として、電力会社は特定の「監視回路」の電力を切る（無電力化する）公共の安全のための電力遮断 (PSPS) イベントを実施します。

このプロセスは、データの取り込み、処理、ユーザーの不作為の有効化、および外部システムへの書き込みにおいて、誤りを許さない競争です。複数のチームの共同作業が必要であり、内部および外部システムのすべてのステップでの多数の統合がこのユースケースにさらなる課題を与えました。

解決策

Foundryは、これらのPSPSイベントを最初から最後まで計画し、実行するために使用されます。これらの緊急イベントを高い精度、速度、可監査性、および透明性をもって運営することが重要です。これは、公共の安全に対するコンプライアンスを評価する地元の規制当局に報告する必要があるためです。

PSPSイベントが予見されると、ユーティリティは顧客に対して可能性のある無電力化について警告する一連のコミュニケーションを開始します。この一連の通知はイベントの72時間前に始まり、電力が復旧した8時間後に終了します。イベントが近づくにつれて、天気予報が明確になり、影響を受ける回路の範囲が変更されるため、顧客を通知シリーズに追加/削除する必要があります。このユースケースでは、Foundryがプロセス全体を操作し、カスタマーサービス担当者がFoundryを離れる必要がありません。

影響

• 通知の生成時間: 差し迫った無電力化を知らせる通知の場合、電力会社は顧客が電力を失う前に通知するための数分しかありません。
• 通知の正確性: 影響を受ける顧客に正しいメッセージを正しいタイミングで届けること -- このメトリクスは、消費者の利益を代表するものとして規制当局によって精査されます。
• 通知の配信および成功した連絡のエスカレーション。
• 将来のオペレーションを改善するためのPSPS知識ベースの開発。
• 不正確なソースデータの修正能力、たとえば、回路に誤ってマッピングされた顧客。
• 意思決定プロセスの透明性と可監査性。

作り方

Foundryは、通知フローを生成するために複数のトリガーを使用します:

• 事前に無電力化されると予測された監視回路リスト。
• ライブで観察された気象閾値の突破による直前の無電力化。
• プログラムによらないニーズのための手動トリガー。

Foundryはこれらのトリガーを処理し、配電管理システム (DMS) にクエリを実行して、現在運用されているグリッドの状態において範囲設定された回路に接続されている顧客のリストを取得します（スイッチなどのグリッドの構成により、顧客がどの回路から電力を得ているかが変わります）。

Foundryは、影響を受ける顧客を事前にテンプレート化されたキャンペーンにまとめ、ビジネスルール (Foundry Rulesで定義) を適用して、おそらく誤って含まれた顧客を除外します。

• 認可が不要な場合、Foundryはキャンペーンと通知ペイロードを顧客通知およびメッセージングシステムに直接送信し、顧客に即座に放送されます (SFTPを通じて)。
• 認可が必要な場合、カスタマーサービス担当者がキャンペーンのリリースを認可します。承認後、Foundryは通知ペイロードを処理し、顧客メッセージングシステムに送信して即座に放送されます。

カスタマーサービス担当者はプログラムによって除外された顧客のリストをレビューし、特定のイベントの残りの通知全体で強制的に含める/除外するようにマーキングします。送信されると、Foundryは放送によって返された通知結果 (たとえば、配信済み、未配信) を受け取ります。 Foundry Reports は、連絡が成功しなかった高優先度の顧客について更新され、カスタマーサービス担当者が再度連絡を試みることができます。連絡が成功しない場合、カスタマーサービス担当者は特定の顧客をエスカレーションのために消費者問題チームにマーキングし、連絡が取れなかった重要な顧客のドアをノックするチームを派遣します。

消費者問題ユーザーは、エスカレーションプロセスをFoundryに記録し、カスタマーサービス担当者はイベント中の通知プロセス全体を監視します。

• 影響を受けた顧客数とその性質、
• キャンペーンの成功 (配信済み、未配信など)、イベントの接近 (h-72, h-48, h-24など) を示すマーキング、
• 除外プロセス、および
• エスカレーションプロセス。

同様のユースケースを実装する

このユースケースは、以下のパターンを実装しています。特定のパターンについてさらに詳しく知り、Foundry内での実装方法を学ぶには、以下のリンクを参照してください。

• アラートワークフロー (他の 7 つのユースケースで使用)
• オペレーショナルプロセスの調整 (他の 8 つのユースケースで使用)

このユースケースについてさらに知りたいですか？同様のものを実装したいですか？ Palantirで始めましょう ↗