送電系統安定化の為のデータ分析プラットフォームにおける...
TRANSCRIPT
DEIM Forum 2015 E7-2
送電系統安定化の為のデータ分析プラットフォームにおける
蓄積系データ処理技術と評価
西川 記史† 高田 実佳† 清水 晃†† 茂木 和彦† 藤原 真二†††
河原大一郎††††
†（株）日立製作所横浜研究所〒 244–0817神奈川県横浜市戸塚区吉田町 292番
††（株）日立製作所中央研究所〒 244–0817神奈川県横浜市戸塚区吉田町 292番
†††（株）日立製作所情報通信システム社 ITプラットフォーム事業本部〒 244–0817神奈川県横浜市戸塚区吉田町 292番
††††（株）日立製作所エネルギーソリューション事業統括本部〒 100–8280東京都千代田区丸の内一丁目 6番 6号（日本生命丸の内ビル）
E-mail: †{norifumi.nishikawa.mn,mika.takata.nc,kazuhiko.mogi.uv}@hitachi.com,††[email protected],
† † †[email protected],† † ††[email protected]
あらまし 大規模停電が深刻な問題である諸外国では，送電系統の安定化が求められている．その為，オペレータに
停電の予兆を気づかせる必要がある．本研究では，高頻度で生成される大量の PMU(Phasor Measurement Unit)デー
タの蓄積とそれを用いた分析を支援するデータ分析プラットフォームを提案する．本稿では，本データ分析プラット
フォームの概要，及び数秒間隔で到着する大量のセンサデータを蓄積しかつ短時間で検索するためのデータ蓄積・検
索技術について述べる．評価の結果，毎秒 100万件のデータ蓄積と数秒でのデータ検索が可能であることを確認した．
これにより大量データの蓄積・分析を実現する．
キーワード 送電系統，安定化，データ分析プラットフォーム
1. は じ め に
近年，諸外国では大規模な停電が深刻な問題となっている [1]．
特に，2003年 8月に米国及びカナダで発生した大停電以降，大
規模障害の回避は送電系統安定化における最重要課題の一つ
である．また、大規模停電は，経済的にも大きな損失をもた
らす．Electricity Consumers Resource Councilにより報告された
2004年に発生した大規模停電のレポートでは，経済的損失は
100億ドルにも達したことが報告されている [2]．このような
大規模停電が発生した理由の一つに，送電系統の状況理解・把
握（Situational Awareness)が不十分であったことが挙げられて
いる [3]．このため，送電系統の制御システムでは，オペレータ
の Situational Awarenessを改善する新たな手法の導入が進んで
いる [2]．
オペレータの Situational Awarenessを改善するツールとして，
北米を中心に非常に細粒度の情報の収集が可能な位相計測装
置 (Phasor Measurement Unit; PMU）[4] [5] と呼ばれる新たなセ
ンサーが注目されている [6] [7] [8]．米国エネルギー省によれ
ば，米国における PMUの導入数は 2010年ではわずか 166台
であったものが 2013年 3月の時点で 1,126台になるなど，劇
的に増加していることが分かる [3]．PMUは，電圧，電流，周
波数の大きさと位相差を毎秒 30回から 60回の周期で計測する
センサーである [9]．PMUは，従来から使われていた SCADA
(Supervisory Control And Data Acquisitions)と比較して数百倍詳
細な情報を収集することが可能であり，このことは電力システ
ムにおける時系列データ分析の可能性を広げるものであると考
えられる．
実際，PMUデータを使用した様々なアプリケーションが注
目がされている．文献 [10]によれば，広域系統の監視・可視化，
発電機の監視・統合，Situational Awarenessツールのための警告
システム，系統状態予測，広域動揺監視，過密状態分析等，様々
なアプリケーションが開発されている．Situational Awarenessで
は，送電系統のオペレータは，コントロールセンタにおいて送
電系統を監視することにより重大な障害につながる予兆を検知
し，即座に回避策をとる必要がある．大規模障害の回避のため
のオペレータの意思決定は非常に重要であり，重大な局面で数
秒以内の判断を求められることもある．一方，重大な障害に至
る過程は規則性がある，即ち何らかの波形のパターンや状態を
経由して大規模障害に至ることが知られている [8]．すなわち，
過去に発生した大規模障害とその予兆に基づき，現在観測され
ている予兆が大規模障害に至るか否かを判断することは非常に
有用である．このことは，オペレータの Situational Awareness
の支援のために過去の PMUデータと現在観測されているデー
タを組み合わせて予兆検知を行うことが非常に有効な手段であ
ること考えられる．
しかし，前述のような，過去の PMUデータを用いた送電系
統の監視・可視化の実現においては，PMUが生成するデータ
の量がしばしば問題となる．実際，500台の PMUから毎秒 30
回の周期でデータを収集した場合，そのデータ量は 1年間で約
40TBにも達する [11]．過去の PMUデータを活用した送電系統
の監視を行うためには，このような膨大な量のデータをリアル
タイムで処理するとともに確実に蓄積し，かつ膨大な量のデー
タから必要な部分を短時間で取り出すことが可能な IT プラッ
トフォームが求められる．
本稿では，高頻度で生成される大量の PMUデータの蓄積と
それを用いた分析を支援するための ITプラットフォームである
データ分析プラットフォームを提案する．本データ分析プラッ
トフォームの概要，及び数秒間隔で到着する大量のセンサデー
タを蓄積しかつ短時間で検索するためのデータ蓄積・検索技術
について述べるとともに，擬似的に生成した数日間分の PMU
データを用いた，本データ分析プラットフォーム評価結果につ
いても報告する．
2. 関 連 研 究
これまで，大量のセンサデータを収集・蓄積し，それらの分
析を支援するための IT プラットフォームが多数提案されてい
る [12] [13] [14] [15] [16]．
文献 [12]に示されている HadoopDBは，並列 DBMSの高速
性・効率と MapReduceのスケーラビリティ及び信頼性の両方
を備えたデータ管理基盤を目指している．また，文献 [13]に示
されているように Hadoopは，データを高速に蓄積することが
可能であるが，検索，特にジョインを含む検索に弱点があるこ
とが指摘されている．
また，センサが生成する大量のデータの収集・蓄積・検索に
特化したリアルタイムヒストリアンとして PI System [14]があ
る．文献 [17]には，PI Systemデータ蓄積及びヒストリアンか
らのデータ取得が非常に高速であることが示されている．
センサデータの収集・蓄積・検索のために，データベース
管理システムを用いた IT プラットフォームも提案されてい
る [15] [16]．文献 [15]では，1,000万台のセンサが生成するデー
タをリアルタイムに蓄積するために，48コアラックのクラス
タが必要であることが示されている．また，文献 [16]では，大
量のセンサデータを短時間で蓄積するため時系列データを圧縮
して蓄積する機構，及び SQLインタフェースを通して時系列
データベースにアクセスするための機構を提案している．
3. 電力システムの監視・制御と IT システム
3. 1 電力システムの監視・制御
電力システムは，近代社会を支える重要な社会インフラであ
り，火力や水力などの発電所，電力を送る送電，電圧・電流の
変換等を行う変電所，電力を消費する需要家に電力を配る配電
網から構成されている [18]．これらの電力システムは，図 1に
示すようにコントロールセンタに設置された計算機システムに
より監視・制御されている．
電力システムの監視を行う機器の構成例を図 2に示す．変電
計算機室通信制御装置火力発電所
超高圧変電所配電用変電所一般需要家 特高需要家100V～200V
水力発電所
送電線154kV～66kV配電線6.6kV 送電線22kV～6.6kV 一次変電所
送電線500kV～275kV 情報情報コントロールセンタ
計算機室計算機システム指令制御室
図 1 電力系統監視制御システム
Substation PDC
PMUs
Super PDCs
Substations
SCADA: Supervisory Control and Data Acquisition, EMS: Energy Management System, RTU: Remote Terminal Unit, PMU: Phasor Measurement Unit, PDC: Phasor Data Concentrator, WASA: Wide Area Situational Awareness,
Communication network
SCADA
RTUs
Protections
Controls Meters
Power Stations
RTUs
Generator
RTUs
データ解析
プラットフォーム
SynchorophasorArchive
WASA
Power System Control Center
EMS
図 2 監視システム機器構成
所（Substation）や発電所（Power Station）には遠方監視制御装
置（RTU）が配置され，装置から得た電気信号の SCADAへの
送信や SCADAから受け取った信号に基づき装置の制御を行う．
PMUは，変電所内に配置され，電圧，電流，周波数の大きさと
位相差を毎秒 30回から 60回の周期で計測しその情報をネット
ワーク経由で変電所内のフェーザデータ収集装置（Phasor Data
Concentrator; PDC），コントロールセンタ内の Super PDCに送
信する．データ分析プラットフォームは Super PDCより PMU
センサ情報を受け取る．
3. 2 TSDAデータモデル
我々が提案するデータ分析プラットフォームは，系統制御に
限らず，広くセンサデータを収集・蓄積し，その分析を行うため
のプラットフォームを目指している．そのため，PMUのデータ
形式 [9] に見られるような系統制御固有のデータ形式ではなく，
時系列の蓄積されるデータに適した TSDAデータモデル [19]を
採用した．
TSDAデータモデルの概要を図 3に示す．TSDAデータモデ
ルの構成要素は，変電所やそれに付与されたセンサ情報を管
理する Master Data（Asset Info）（図 3左側）と，時系列デー
Itemitem_idpathname node_idproperty_idNodenode_idlabel pathname type_idparent_id…Propertyprpperty_idlabeldata_typetype_idtypecode
Typetype_idlabel
ItemValueitem_idtime_stampvaluequalityAnnotationentry_timeuser_nameitem_idtime_stamptextModifiedItemValuemodifycation_timeuser_nameitem_idtime_stampvaluequality
Master Data (Asset Info)Master Data (Asset Info)Master Data (Asset Info)Master Data (Asset Info) Historical DataHistorical DataHistorical DataHistorical Data
ER diagram of IEC61970-407 Data Model (main table only)
SubstationInformation SensorInformation Sensor Data
図 3 TSDAデータモデル
10 minutes PMU Conform Sensor Data for 4
substations
10 min x 60 x 30 x 4 sensor
x 4 substation = 288K data
All PMU Sensor Data for substations
at a specific time
Query Query Query Query #1: Trend search query#1: Trend search query#1: Trend search query#1: Trend search query
Access DataAccess DataAccess DataAccess Data
Query #Query #Query #Query #2: 2: 2: 2: SSSSnapshot querynapshot querynapshot querynapshot query
Access DataAccess DataAccess DataAccess Data4536 sensors x 5 snapshot = 23 K data
図 4 データ分析プラットフォームにおける典型的なクエリ
タを管理する Historical Data（図 3右側）である．Master Data
中の Node型は変電所の情報を，Itemは PMUが収集するデー
タ項目にそれぞれ対応している．Histrical Dataには ItemValue,
ModifiedItemValue, Annotationがあり，それぞれ PMUが収集し
た生データ，生データを更新した場合の更新値，及び生データ
に付与される注釈を保持する．
3. 3 送電系統監視・制御アプリケーションにおけるクエリ
送電系統の監視・制御のためのアプリケーションは大きくオ
ンラインアプリケーションとオフラインアプリケーションに大
別される [3]．本論文では，データの蓄積・検索に対する性能要
件が高いオフラインアプリケーションにフォーカスし，そのク
エリについて述べる．
オフラインアプリケーションのクエリは，図 4に示すような
2種類のクエリに集約される．最初のクエリ（クエリ#1;図 4
左）はトレンド検索と呼ばれるものであり，いくつかのセンサ
の値の履歴をデータベースより取得する．図 4左の例では，4
つの変電所にそれぞれ 4台取り付けられた PMUの，過去 10分
間のデータを検索している．もう一つのクエリ（クエリ#2;図
4右）は断面検索と呼ばれるものであり，ある一時点の全 PMU
の値をデータベースより取得する．図 4右の例では，5つの時
刻について，4,536台のセンサ値を検索している．
4. データ分析プラットフォーム
4. 1 データ分析プラットフォームの全体像
3. 1節で述べたように，送電系統監視・制御アプリケーショ
PDCPDCPDCPDCPMUPMUPMUPMUPMUPMUPMUPMU PDCPDCPDCPDCPMUPMUPMUPMUPMUPMUPMUPMUSuperPDC
Stream DataProcessingIn-memoryData Cache
AnalysisApplicationsSend
Sensor Data(every a few sec) Online Power Online Power Online Power Online Power SystemSystemSystemSystem AnalysisAnalysisAnalysisAnalysis
LoadSensor Data(every 5 to10 min)
ModelDBMSArchivedFiles AccessHistorical Data(in 2 to 3 sec)
Real-Time Data Processing
Historical Data Analysis
OffOffOffOff----line Analysisline Analysisline Analysisline AnalysisModel updates
図 5 データ分析プラットフォーム
ンは，オンラインアプリケーションとオフラインアプリケー
ションに大別できる．このため，データ分析プラットフォーム
はオンラインアプリケーション向けのデータを収集・提供する
リアルタイムデータ処理（Real Time Data Processing）部とオフ
ラインアプリケーション向けデータを収集・蓄積・提供する履
歴データ分析（Historical Data Analysis）部を持つ．
PMU数を 500とし，各 PMUのデータ収集周期が毎秒 30回，
Super PDCからデータ分析プラットフォームへのデータ転送間
隔をほぼリアルタイムとみなせる 2秒とした場合，Super PDC
は，毎回約 27.2万件のデータをデータ分析プラットフォームに
転送する．リアルタイムデータ処理部は，ストリームデータ処
理（Stream Data Processing）部により転送されたデータを処理
し，後段の分析アプリケーション（オンラインアプリケーショ
ン）（Analysis Application）にデータを渡す．そして，オペレー
タがこれらのアプリケーションを用いて系統の監視や予兆検知
等の業務を行う．
前述の例では，Super PDCは 2秒間隔で約 27.2万件のデータ
を送信するが，これは DBMSにとっては非常に負荷が高い処
理となる．一般に，DBMSはデータを一括して蓄積する方が短
時間でデータを蓄積できる．このため，履歴データ処理部は，
ライトキャッシュ（In-memory Data Cache）に一旦データを蓄積
し，ある程度データが蓄積されるとそのデータをまとめて（例
えば数分間隔で）DBMSに蓄積する．オペレータは，モデル評
価などのオフライン業務を実施するために，オフラインアプリ
ケーションを用いて履歴データベースを検索する．そして，必
要に応じてオンラインアプリケーションが保持するモデルの更
新を行う．我々が提案するデータ分析プラットフォームを図 5
に示す．
4. 2 データ蓄積
数分間隔で DBMSに到着するデータを遅滞無く Historical
Dataの履歴表としてデータベースにロードし，蓄積し続ける
ためには，データロード毎の索引全体の再作成を避ける必要が
ある．従来のデータロードでは，データのロードごとに履歴表
に定義された B-tree索引全体を再構築する必要がある．このた
め，蓄積されたデータ量が増加するにつれ，データロードに要
する時間が長くなり，周期的なデータのロードに支障をきたす
可能性があった．
Write
Cache
HADB
Index Construction for
Load Objective Data Each
5 min.
Store
PMU
Data
Bulk Data
Load
Sub-Index
図 6 データ蓄積方式
HADB
Sub-Index
00:00:00 – 00:04:59
00:10:00 – 00:14:59
SELECT ～
FROM ～
WHERE TIME BETWEEN 00:06 AND 00:08
Sub-
table
00:05:00 – 00:09:59
Sub-index Management Table
図 7 データ検索方式
そのため，我々はデータが周期的に追加ロードされることに
着目し，ロードされるデータごとに B-tree索引を構築する方式
を提案する．提案手法は，新しくロードされたデータについて
のみ B-tree索引（部分 B-tree索引と呼ぶ）を構築すればよい．
このため蓄積されているデータ量に関係なく索引構築時間を一
定にでき（注1），周期的なデータのロードを可能とすることがで
きる．この様子を図 6に示す．
4. 3 データ検索
我々が提案するデータ蓄積方法では，履歴表に対する部分
B-tree索引の数がデータロードの回数に比例して増加する．そ
のため，データロード回数が多くなるとデータの検索時に探索
しなければならない部分 B-tree索引の数が増加し，検索性能に
影響を与える可能性がある．
そこで我々は，部分 B-tree索引に格納された値の範囲をメモ
リ中に部分索引管理表として管理し，クエリが当該索引を利用
する場合にクエリの検索条件と部分索引管理表とを突き合わせ，
データが含まれている可能性がある部分 B-tree索引のみを探索
する，データ検索方式を提案する．
3. 3節で述べたように，オフラインアプリケーションのクエ
リは大きく，トレンド検索と断面検索に分類される．トレンド
検索は複数のセンサについて，比較的短い時間のセンサ値の履
歴を検索する．また，断面検索はある一時点のセンサ値を検索
する．一方で，センサデータは時間ごとにロードされるため，
両クエリとも一つまたはごく少数の部分 B-tree索引のみを探索
すればよいため，全ての部分 B-tree索引を探索する場合と比較
して大幅な検索性能向上が期待できる．
データ検索方式の例を図 7に示す．図 7では，TIME列に部分
B-tree索引が定義されている想定である．ここで，TIME列に対
（注1）：1回当りのロードでロードされるデータ量が一定の場合．
時刻,計測点ID,値00:00:00, 1, …00:00:00, 2, …：00:00:00, 100000, …00:00:02, 1, …00:00:02, 2, …：00:00:00, 100000, …：時刻,計測点ID,値00:00:00, 1, …00:00:00, 2, …：00:00:00, 100000, …00:00:02, 1, …00:00:02, 2, …：00:00:00, 100000, …：
時刻,計測点ID,値00:00:00, 1, …00:00:00, 2, …：00:00:00, 100000, …00:00:02, 1, …00:00:02, 2, …：00:00:00, 100000, …：時刻,計測点ID,値00:00:00, 1, …00:00:00, 2, …：00:00:00, 100000, …00:00:02, 1, …00:00:02, 2, …：00:00:00, 100000, …：
時刻,計測点ID,値00:00:00, 1, …00:00:00, 2, …：00:00:00, 100000, …00:00:02, 1, …00:00:02, 2, …：00:00:00, 100000, …：時刻,計測点ID,値00:00:00, 1, …00:00:02, 1, …：00:04:58, 1, …00:00:00, 2, …00:00:02, 2, …：00:04:58, 2, …：
入力データファイル
入力データファイル
時刻、計測点ID順にデータが並んでいる（PMU/PDCから得られるデータ）
計測点ID、時刻順にデータを並び替え
00:00:00,1,…00:00:00,2,… 00:00:02,1,…00:00:02,2,……00:00:04,1,…00:00:04,2,… 00:00:06,1,…00:00:06,2,……
蓄積
…
…蓄積
Query#1 条件：時刻: 00:00:00-00:00:06、計測点ID: 2
Query#1 条件：時刻: 00:00:00-00:00:06、計測点ID: 2
全てのデータページのreadが必要データページ
データページ
00:00:00,3,…00:00:00,4,… 00:00:02,3,…00:00:02,4,…00:00:04,3,…00:00:04,4,… 00:00:06,3,…00:00:06,4,…00:00:00,1,…00:00:02,1,…00:00:00,2,…00:00:02,2,…00:00:04,1,…00:00:06,1,…00:00:04,2,…00:00:06,2,…
00:00:00,3,…00:00:02,3,…00:00:00,4,…00:00:02,4,…00:00:04,3,…00:00:06,3,…00:00:04,4,…00:00:06,4,…少数のデータページのreadのみで良い
図 8 クラスタリング方式
する絞り込み条件 (TIME BETWEEN 0006 AND 00:08）を持つ
クエリが投入されると，部分索引管理テーブルを用いて検索条
件に合致する部分 B-tree索引を特定する．この場合，00:05:00
- 00:09:00を値に持つ行が条件に合致し，その行が指している
部分 B-tree索引のみを検索する・
4. 4 クラスタリング
データ分析プラットフォームは，Super PDCから定期的に
データを受け取る．このため，データは時刻，センサ ID の順
でソートされた状態でデータ分析プラットフォームに到着する．
データをこの状態のままロードすると，同一時刻でセンサ ID
が異なるデータが同一ページに格納される．この状態でトレン
ド検索を行うと，指定時刻内の全てのデータページにアクセス
する必要がありデータ検索時の入出力回数が増加する．
そこで，我々はデータをセンサ ID，時刻の順にソートしな
おしデータをロードすることにより，同一センサの異なる時刻
のデータができるだけ一つのデータページに格納されるように
した．これによりトレンド検索時のデータページへ入出力回数
を削減でき，検索性能の向上が期待できる．この様子を図 8に
示す．
5. 評 価
次に我々は，提案したデータ分析プラットフォームを実装し，
その性能評価を行った．本章では評価方法及び結果について述
べるとともに，結果についての考察を行う．
5. 1 評 価 方 法
機器構成 性能評価に用いたハードウェアを図 9に示す．サー
バは（株）日立製作所製の HA8000 RS220 (物理 CPU数 12個,
論理 CPU数 24個，主記憶容量 96GB）である．ストレージは
同じく（株）日立製作所製の Hitachi Adaptive Modular Storage
2500 (AMS2500)（600GB SAS 15000rpm× 64台）である．こ
れらを 8Gbpsのファイバ 2本で接続した．ストレージは，HDD
64台を用いて 1つのストレージプールを作成し，16個の LU
を作成した．サーバ側はこれら 16個の LU に対応したデバイ
スをを用いて LVM を構築し，そこから DB用の LV を切り出
Storage：：：： AMS2500
HDP PoolLU LU LU LU LU LU LUHDD HDD・・・ HDD×64HDD： SAS 15,000 rpm 600GBFC: 8Gbps×2
HDD HDD
Server：：：： HA8000/RS220• CPU： Intel® Xeon® X5690 3.47GHz × 24cores
• Memory： 96GB
OS：：：： Red Hat Enterprise Linux 6.2
Conventional DB
(Open Source DB)
LVMPV PV PV PV PV PV PV・・・
・・・１6LU１6PV
(MySQL 5.1.73)
Imported Data:
# of Records: 47B
Database Size: 1.7TB
HA8000/RS220
AMS2500
64 HDDs
FC: 8Gbps×2HADB
図 9 評価用機器構成
82.7
22.9
0
10
20
30
40
50
60
70
80
90
Conv. DB HADB
x 3.6
Seconds
図 10 データ蓄積性能
している．DBMSソフトウェアとして，（株）日立製作所製の
Hitachi Advanced Data Binder (HADB)を用いている．また，比
較対象としてオープンソースの RDBMSを用いた．
データ 我々は，評価用に 4日分，500PMU（データ収集間隔
33ms）に相当するデータを用いた．Item数は 4,536，レコード
数は 5分間当たり 4,082万件（csv形式で約 2.4GB），4日間で
約 470億行，約 2.8TBである．
データロードの評価方法 本評価では，性能上厳しいと想像で
きる，ライトキャッシュから DBMSへのデータ取り込み性能を
評価した．データの取り込み間隔は 5分である．HADB を用い
た場合と，オープンソース DBMSを用いた場合のそれぞれの
データロード性能を比較した．
検索の評価方法 我々は，4日分のデータを蓄積したデータベー
スを対象に，トレンド検索，断面検索の双方について，HADB
を用いた場合の検索性能とオープンソース DBMSを用いた場
合の検索性能を比較した．評価に用いたクエリの条件は，図 4
に示したものと同一の条件である．
5. 2 評 価 結 果
データ蓄積性能 データ蓄積性能の比較結果を図 10に示す．5
分間分のデータ（4,082万行，約 2.4GB）の蓄積に要した時間
は，従来 DBが約 82.7秒であるのに対し，HADB は約 22.9秒
と，データ蓄積性能が約 3.6倍向上した．HADB のデータ蓄積
性能は約 178.3件/秒である．
110.0
134.3
2.0 3.7
0
20
40
60
80
100
120
140
Query #1 Query #2
Conv. DB
HADB
x 55 x 36
Seconds
図 11 データ検索性能
データ検索性能 データ検索性能の比較結果を図 11に示す．図
から分かるように Query#1（トレンド検索）は従来 DBMSが
約 110.0秒であるのに対し HADB は 2.0秒と約 55倍の性能向
上を達成した．また Query#2（断面検索）は従来 DBMSが約
134.3秒であるのに対し，HADB は約 3.7秒と，約 36倍の性能
向上を達成した．
5. 3 考 察
5. 3. 1 データ分析プラットフォームの汎用性
3. 3節において，送電系統の監視・制御のためのアプリケー
ションは大きくオンラインアプリケーションとオフラインアプ
リケーションに分類されることを述べた．送電系統の監視・制
御では，PMUから毎秒 30回～60回の頻度でデータが渡され，
SuperPDCがそれらをマージしたのち数秒毎にデータ分析プラッ
トフォームに投入する．このような高頻度で到着するデータを
遅滞無く DBMSに蓄積するために，我々はライトキャッシュを
DBMSの前段に設け，数分毎にデータを DBMSにロードする
とともに，B-tree索引全体の再作成を避ける部分 B-tree索引を
提案し，500PMU程度の規模の送電系統のデータを遅滞無く蓄
積できることを確認した．
一方で，文献 [16]では，IoTにおけるデータの到着の仕方と
して，数十ミリ秒間隔でごく少量のデータが到着する場合の他
に，例えばスマートメータのデータなど数分～1日 1回程度の
間隔で大量のデータが到着しそれを DBMSに追加する場合が
あることが述べられている．このようなケースでは，データは
既にまとめられているため，ライトキャッシュを用いてデータ
分析システムに到着するデータをまとめる処理は不要である．
しかし，到着したデータを DBMSに追加する処理では，DBMS
に蓄積されたデータ量が増加するにつれ B-tree索引の再構築に
時間を要することが想定できる．我々が提案した部分 B-tree方
式は，大量のデータを一括追加する場合においても B-tree索引
全体の再構築をさけることができる．このため，提案方式は少
量のデータが高頻度で到着する場合，及び大量のデータを一括
して到着する場合双方に有効であると考えられる．
5. 3. 2 部分 B-tree索引の運用
本論文で提案した部分 B-tree索引は，高頻度で到着するデー
タの DBMSへの取り込みに有効である．その一方で，データが
データ分析システムに到着してからそのデータに DBMS経由で
アクセスできるようになるまでの時間を短くするために，デー
タを数分毎にまとめて DBMSにロードする場合，部分 B-tree
索引の数が非常に多くなるという問題がある．例えば，データ
を 5分毎にまとめて取り込み，2年間蓄積する場合，部分 B-tree
索引の数は約 21万個にもなる．
図 7に示したように，提案方式ではデータ検索時の部分B-tree
索引絞込みのため，部分 B-tree索引管理テーブルを用いて部
分 B-tree索引を管理するが，検索時の性能向上のためには，本
テーブルをメモリ上に常駐させておくことが望ましい．部分
B-tree索引の数が多くなると部分 B-tree索引管理テーブルのサ
イズが増大しメモリを圧迫する．そのため，例えば一定期間ご
とにいくつかの部分 B-tree索引をマージし部分 B-tree索引の数
を削減するような運用が必要である．
6. ま と め
本論文では，高頻度で生成される大量の PMUデータの蓄積
とそれを用いた分析を支援するデータ分析プラットフォームを
提案し，その評価を行った．評価の結果，毎秒約 178万件の
データ蓄積性能と数秒でのトレンド検索，断面検索時間が達成
できることを確認した．これにより，送電系統安定化のための
データ分析プラットフォームに求められる性能要件が達成でき
ることを確認した．
文 献[1] 電気学会 電気広報特別委員会. 過去の大規模停電事
例. http://www2.iee.or.jp/ver2/honbu/16-committee/epress/data/12-jirei.pdf, 2011.
[2] Zhaoyang Dong and Pei Zhang.Emerging Techniques in Power Sys-tem Analysis. Springer, 2009.
[3] U.S. Department of Energy. Synchrophasor Technologies andtheir Deployment in the Recovery Act Smart Grid Programs.https://www.smartgrid.gov/sites/default/files/doc/files/SynchrophasorReport 08 09 2013 DOE (2) version0.pdf, 2013.
[4] Arun Phadke. Synchronized phasor measurements in power system.IEEE Computer Applications in Power, Vol. 6, No. 2, pp. 10–15,1993.
[5] Aleksandar Radovanovic. Using the internet in networking of syn-chronized phasor measurement units.International Journal of Elec-trical Power & Energy System, Vol. 23, No. 3, pp. 245–250, 2001.
[6] J. De La Ree, V. Centeno, J. S. Thorp, and Arun Phadke. Synchro-nized Phasor Measurement Applications in Power Systems.IEEETransactions on Smart Grid, Vol. 1, No. 1, pp. 20–27, 2010.
[7] Reynaldo Nuqui and Arun Phadke. Phasor measurement unit place-ment techniques for complete and incomplete observability.IEEETransaction on Power Delivery, Vol. 20, No. 4, pp. 2381–2388, 2005.
[8] Gerald Heydt, Chen-Ching Liu, Arun Phadke, and Vijay Vittal. So-lution for the crisis in electric power supply. InIEEE Computer Ap-plication in Power, pp. 22–30, 2001.
[9] IEEE-SA Standards Borad. C37.118.2-2011 - IEEE Standard forSynchrophasor Data Transfer for Power Systems, 2011.
[10] Actual and potential phasor data applications. https://www.naspi.org/File.aspx?fileID=537, 2009.
[11] Power System Relaying Society: IEEE and Power Engineering.C37.118-2005 - IEEE Standard for Synchrophasors for Power Sys-tem, 2006.
[12] Azza Abouzeid and Kamil Bajda-pawlikowski. HadoopDB : An Ar-chitectural Hybrid of MapReduce and DBMS Technologies for An-
alytical Workloads.Journal Proceedings of the VLDB Endowment,Vol. 2, No. 1, pp. 922–933, 2009.
[13] Andrew Pavlo, Erik Paulson, Alexander Rasin, Daniel J Abadi,Samuel Madden, Michael Stonebraker, and David J Dewitt. A Com-parison of Approaches to Large-Scale Data Analysis. InProceedingof the 2009 ACM SIGMOD International Conference on Manage-ment of Data, pp. 165–178, 2009.
[14] PI System. http://www.osisoft.com/.[15] Meter-To-Cash Performance Using Oracle Utilities Applications on
Oracle Exadata and Oracle Exalogic. http://www.oracle.com/us/industries/utilities/ultilities-exadata-exalogic-wp-1499854.pdf, 2012.
[16] Sheng Huang, Yaoliang Chen, Xiaoyan Chen, Kai Liu, Xiaomin Xu,Chen Wang, Kevin Brown, and Inge Halilovic. The Next GenerationOperational Data Historian for IoT Based on Informix. InProceed-ings of the 2014 ACM SIGMOD International Conference on Man-agement of Data, pp. 169–176, 2014.
[17] Matt Rivett, Jim Kleitsch, Rick Reeder, Ann Moore, and JayLakumb. PI Server 2012 Webinar Series: WAMS/Synchrophasor,PI Server 2012 and OSIsoft/Dell collaboration at Dell So-lution Centers. http://cdn.osisoft.com/corp/en/media/webinars/PIServer2012WAMS 12052012.pdf, 2012.
[18] 大久保仁. 電力システム工学. オーム社, 2008.[19] Energy management system application promgram interface (EMS-
API) Part 407: Time Series Data Access (TSDA). International Elec-trotechnical Commission, 2007.