はじめに
因果推論の勉強(記事)をしようと思っていたのですが、自分が取り組んでいる事で記事にしていない事があったので、記事にしたいと思います。
データ解析を行う時に、数字に向き合うことが多くなると思いますが、前提（システムの状態や目的）を間違えてしまうと、数学的には正しくても、運用上無意味な解析になってしまう事があるかと思います。
そこで、衛星開発や自動車開発で用いられている、システムズエンジニアリングを用いて、システムを定義する事によって、状況を整理し役に立たないかと思っています。
講座を少しづつ受けながら、独学で勉強しているので独自な部分もあるかともいますが、データセンタの異常検知を例にとって説明していきたいと思います。
今回は、データセンタの異常検知を例にとって、MBSE(Model Based Systems Engineering)を使って、説明していきたいと思います。
MBSEの手法と取り入れることによって
- 余計な異常検知を減らす
- 対応策まで考えた異常検知
- 入力データ選定の参考
などの利点があると考えています。
MBSEの流れ(データセンタの異常検知を例にとって)
ここでは、SysMLといった具体的な記法ではなく、考え方について記載します。
MBSEでは、完全に決まった順序がある訳ではなく、決めるべき視点を持って考えます。
視点を持ちシステムを定義する事によって、対象をしっかりと捉え抜け漏れなく、事象を考えていきます。
以下の物を定義します。
- ライフサイクルの定義
- コンテキスト（構造）の定義
- ユースケース（振る舞い）の定義
- 機能の定義
- パラメトリック制約の定義
上記を、データセンタ運用システムを例にながら紹介していきたいと思います。
ライフサイクルの定義
以下はISO/IEC/IEEE 15288:2015で定められたソフトウェアやシステムのライフサイクルの一例です。
このように、企画や開発、運用といった製品のライフサイクルを考えます。
異常検知は、この中でUtilization(運用)、support(保守、改善)といったフェーズで機能するものです。
その中でもフェーズを分けて考える事が可能です。
データセンタで例えるならば、
- 運用：正常時
- 運用：地震時
- 運用：断水時
- 運用：停電時
など細かく分けて考えていく事が可能です。
コンテキストの定義
利害関係者の整理を行います。
システムの登場人物が誰かを定義する事によって、構造を定義します。
フェーズ、運用：地震時のコンテキスト図の例
ユースケース
システムの振る舞いの整理を行います。
つまりシステムが何をするのかを図で示したいと思います。
今回は、フェーズ、運用：地震時のユースケース図を示したいと思います。
地震時の振る舞いが連結しているので、特殊な書き方になっています。
また、ユースケース図だけでなく、ユースケース記述など、形式の乗っ取り文章化する事も可能です。
※ 本図は厳密な UML ユースケース図ではなく、
運用時の相互作用を示す概念図として記載しています。
機能の定義
機能の定義を行います。
コンテキストとユースケースから機能の抽出を行い何をしているのか
今回は、FFBD(Functional Flow Block Diagram)を使って、機能の流れを整理した図を書きたいと思います。
今回はフェーズ、運用：地震時の異常検知の大まかなFFBDを記載したいと思います。
パラメトリック制約
パラメトリック制約は、システムが動作する時のパラメータがどのようになっているか定義します。
今回は、機能の定義で使用した、FFBDからパラメータを決めてきます
例えば、
- 地震時は、センサ取得から通知までを10秒以内に行う
- 通常時は、センサ取得から通知までを1分以内に行う
などといったパラメータ設定となります。
システムを定義しないと何が起きるのか
同じデータでも状況によって違う意味を持つことがある。
| 項目 | 値 |
|---|---|
| 温度 | 32℃ |
| 消費電力 | 低 |
| CPU使用率 | 低 |
例えば上記のようなデータがあった時
- 運用時：正常時
- 運用時：地震時
では、データの捉え方が変わります。
自動で検出したい場合は、センサの追加などが必要となってきます。
また、正常な状態とは何かよくわかっていないと、異常検知もしっかりと定義できません。
データ解析方法がいくら進歩しても、事前に考えておかなければ、高度なデータ解析を用いても、現場で使えない異常検知になってしまいます。
まとめ
データ解析にシステムズエンジニアリングを用いる流れを、例を用いながら説明を行った。
高度なAIを用いる前に、システムズエンジニアリングを用いた検討を行う事によって、正常な状態や異常な状態がどのような状態か定義を行うことにより、適切な異常検知が設計できる可能性を示した。
さいごに
あまり実践事例でてきませんが、こんな取り組みをしていますという紹介でした。
何かあれば気軽にコメントしてください。