このコラムは無料メールマガジン「アメニティ&サウンド音と快適の空間へ」 vol.36〜vol.64(2003年8/21〜2004年11/18)に音響と開発の関連コラムとして連載していたものを編集掲載したものです。
2003年8月14日の北米の大停電は、いまだに原因は噂の域を出ず、正式には原因不明とされています(2003年8月掲載時)。
以前に、メールマガジンのURLクリップなどで東京の電力危機のことなどにも触れていますが、今回は、この停電の事件に関連した話題にしたいと思います。
ARIは、電力会社でもアメリカの企業でもありませんので、技術といっても電力やアメリカの事情について語るつもりはありませんが、北米の停電の問題は、設備老朽化や、電力自由化などのアメリカの電力事情、人的課題以外に、電力以外の設備などにも通ずるような設計やメンテナンスなどの問題を含んでいるため選びました。
報道などの専門家のコメントによると、原因そのものは不明ながら、大規模、広域に複数の発電所が連鎖的に停止した理由は、おおよそ、次のように語られているかと思います。
1.電力網のどこか一部が停止
2.迂回して送電する機能が不全で機能しなかった
3.過剰電流が送電線に発生
4.過剰電流を停止するため送電停止
5.多くの電力網でつながれた発電所が連鎖的に4と同様の停止
▼事件は連日のニュース(2003年8月掲載時)などでご存知かとは思いますが、一応
Yahoo!ニュース - 海外トピックス - 北米大停電の関連ニュース
http://dailynews.yahoo.co.jp/fc/world/massive_blackouts/
1、2に関しては、設備老朽化や電力自由化による利益追求型の問題などが言われるあたりだと思います。
3、4は、迂回経路が機能しなかった時点で発生しているため2の延長上の問題で、迂回路が機能しなければ、必然的に安全策として機能しているので正常ともいえます(過剰電流で送電線がショートという説もあります。その場合、ショートを防げなかったことは、恐らく想定外となると思います)。
非常に、重大な停電となりましたが、発電、送電設備のオーバーロードによる火災や破壊にはいたっていないようですから、正常に安全機構は機能したともいえます。
大規模な事故などでは2重、3重の異常やミスが重なっていることが多いので、この部分が正常に機能したことは不幸中の幸いと言えるかもしれません。
ここまでは2番目を除いて設計想定範囲といえます。
5の連鎖停止は、迂回路とともに想定範囲外ということになり、また、今回の規模が大きくなった原因でもあります。
この連鎖の可能性は、全く想定されていなかったというわけではないような気もしますが、迂回路の送電が機能不全な状況の上で複数の接続先が停止した状態までは、想定されていなかったかもしれません。
また、複数がダウンしている状態では、連鎖的に安全措置によって送電が停止することは事前に認識されていても「ありえない」状態、もしくは、やむをえない状況と設定されていた可能性はあるかと思います。
複数の装置がお互いをバックアップするタイプのフェイルセーフの場合、1つの装置の異常が想定されているのは当然ですが、本来機能する代替機能も機能不全の上、能力以上のバックアップを必要とする事態、壊滅的なダメージをシステムに受けているような状態での連続運行についての想定は、安全を重視して停止するべきという考え方も十分に受け入れられそうな見解でもあります。
このようなフェイルセーフの連鎖や2重障害時の問題は、電力設備に限った話ではなく各種の設備などでも共通に考えるべき問題といえます。
2003年8月14日の北米の大停電に関連してフェイルセーフに関連した話をしていますが、米エネルギー省の長官のコメントでも、「完全な原因究明へ時間かける」とのことで、原因について現時点(2003年9月掲載時)でも解明、発表されていません。
北米広域停電の例では、根本的な原因は不明ですが、フェイルセーフと、発電所停止時のバックアップによって結果的により規模が拡大したことは確かでしょう。
▼さらに関連続報が続いていますが...
Yahoo!ニュース - 海外トピックス - 北米大停電の関連ニュース
http://dailynews.yahoo.co.jp/fc/world/massive_blackouts/
ネットワークのサーバー負荷分散などでも、失敗して連鎖するケースというのが見られる場合があります。
ネットワーク型の相互に補うタイプのフェイルセーフは、極小な問題がネットワーク全体を破綻させるような現象を生み出すことがあるためフェイルセーフの連鎖が収束できるかを考慮する必要があります。
いまさら言われるまでもない問題ともいえますが、その設計時の考え方には、各種のシステムの異常対策全般に通ずるものがあると考えています。
ある程度以上の規模のシステムでは、クローズドなソフトウェア、システムだけで成立していることは少なく、複数のソフトウェア、ハードウェアが協調してシステムを成立させています。
また、1つの機器の内部のソフトウェアに規模を縮小しても、複雑度がある程度以上になれば、同様に部分的なロジックの集合体となり、協調型のシステムと類似した考え方が必要となります。
マルチタスクで動作している場合などは、その最たる例といえます。
協調型の場合、部分的な論理は局部にとどめるという設計方法が適していますが、この、局部での問題解決の方法や条件によっては、北米広域停電のように連鎖が収束しなくなるような現象に発展します。
発電所のそれぞれの条件、問題解決方法は単純明快です。
この2点は、問題なく正しい対処方法と思えますが、バックアップしたことでバックアップ側が過大負荷になる可能性と、その場合の収束手段がなく安全停止の連鎖と止められない点が問題でしょう。
このような相互補完のパターンや、2重に障害が発生した場合の想定というものは発電所に限ったことではありません。
フェイルセーフに限らず、一般に部分的な論理は局部にとどめるという設計方法が適していますが、局部での問題解決の方法や条件によっては、北米広域停電のように連鎖が収束しなくなるような現象に発展します。
9月12日(2003年9月掲載時)、北米大停電で米エネルギー省が発表した調査報告では、オハイオ、ミシガン両州での電圧低下が原因となった可能性があると発表されましたが、電圧低下した原因までには至っていない(2003年9月掲載時)とのことです。
この根本原因も重要ではありますが、連鎖停止によって、大規模な停電に発展したことは、さらに重要な問題であると思います。
▼Yahoo!ニュース - 海外トピックス - 北米大停電の関連ニュース
http://dailynews.yahoo.co.jp/fc/world/massive_blackouts/
フェイルセーフとして考えた時、発電、変電設備を守るという点では成功しているものの電力供給の役割を可能な限りまっとうさせるというバックアップの観点では完全に失敗しています。
この事故から学ぶべき点は、このような難しい連鎖を断ち切りながら電力ネットワークのフェイルセーフと被害を最小限の規模と時間に限定するためのバックアップを実現する方法はどのような方法が取られるかということではないかと考えています。
表題に「ありえない」としたのは、今回の事故のような条件は、事前の検証では、「ありえない」とされているようなタイプの問題に端を発しているように思うからです。
各種のシステム開発に携わると、条件を検討する上で「ありえない」という意見を耳にすることがあります。
かなりレアなケースであっても、物理的に可能な場合には「ありえない」わけではないですから、ワーストケースを検討する必要がありますが、確率的、条件的に稀なものに対しては、時々「ありえない」ため対策は完全でなくても良いという発想をする人が少なからず存在するように思います。
対象のシステムによっては、バックアップやフェイルセーフにコストをかけるべきではない場合がありますから、難しい判断になりますが、問題を回避しなかった場合の影響の大きなケースや、人命にかかわる場合、ユーザーの時間や資産のロスが伴う可能性がある場合、システムの信頼性の低下による信用低下が重大とされる場合、やはり、複合的な障害時合などのレアケースも十分に考慮されるべきでしょう。
ウィルス進入など「ありえない」はずなのに、ウィルスで住基ネットを停止することになったり(対応の安全策と自治体の迅速さ、判断はすばらしいと思いますが)「ありえない」という想定は何かと問題が多いかと思います。
物理的に「ありえる」場合、想定対応策を考える方がワーストケースでの破綻や被害、最終的なコストを少なくできることは間違いありません。
ARIはハードウェア設計、製造、ファームウェア開発、 Windowsアプリケーションの開発をしています。 実績等に興味をお持ちいただけましたら、会社情報に主な開発実績を 「音響と開発」のコーナーには事例など関連情報を掲載していますのでご覧ください。
ソフト、ハードウェア 技術関連の雑記
このコラムは無料メールマガジン「アメニティ&サウンド 音と快適の空間へ」 vol.36〜vol.64(2003年8/21〜2004年11/18)に 音響と開発の関連コラムとして連載していたものを編集掲載したものです。
ソフトウェア開発と開発ツール関連の雑記
機器組込みのエンベデット・ソフトウェア(ファームウェア)の開発に関連したコラムです。 メールマガジン「アメニティ&サウンド 音と快適の空間へ」に連載していた技術・開発コラムを編集掲載しています。
技術・開発の閑話 : ソフト開発コラムファームウェア開発(組込み)の技術 / |
開発ツールの話 : ソフト開発コラムソフトウェアの分類 / |
プロジェクト初期 ツール評価 : ソフト開発ツールの話プロジェクト初期のツール評価 / プログラムの動作・ソースの作成 / コード生成 アセンブラ、コンパイラ / 型変換を伴う式評価(コード生成) / 暗黙のライブラリ(コンパイラ生成コード) / 組込みCPUのメモリアクセス / コード生成〜デバッガ |
デバッガとICE ツール評価2 : ソフト開発ツールの話CPU,DSPの内部の状態モニター / プロセッサ周辺のモニター(メモリ、I/O) / 実行の停止(ブレーク) / シングルステップ実行 / 任意部分の実行 / ヒストリー - 実行トレースとコマンド / 各種ファイルのロード、セーブ / シンボル化 |