[&] Big Data and Internet of Things Application (Analytics for Enginnered Systems)

parc (A Xerox Company)
--------------------------------------------------
Big Data and Internet of Things Application (Analytics for Enginnered Systems)
Dr. Johan de Kleer (Qualitative Reasoning and Model-Based Diagnosis)

このプレゼンテーションにお越しいただき、ありがとうございます。
一緒に資料を作ったガングリア氏も来ています。

この話しをどうやってすすめていくか、概念的な話しをして、
具体的な例をあげます。商用化に向かっている例です。
技術の話し、機能している話しをします。
まず IoT、センサーやアクチュエーターによって、
ビッグデータ、モデルデータ、これまでに無い機会が生まれています。

parc であつかっている、コンディションベースメンテナンスを説明します。
最初にセンシングが関わっている、モデリングがあり、
障害の発見、障害の診断、全ての段階で parc が関わっています。

診断の後、診断を行った後、問題を検出したり、特定した後で、
予測という段階があり、いつ故障するのかを予想し、それに基づいて交換することで、
サービス寿命を伸ばすことができます。

予測の後の段階は、診断に応じて、最適な対応ができることができ、
ダウンタイムや故障を減らすことができ、それらの全ての段階にたいして parc が技術を持っています。

Machine Learning
Constraint Language
Knowledge Representaion and Reasoning
Statistics
Modeling Language
Optimization
Operations Researh
Control Theory
FDIR
Reliability
System Engineering

30人の研究者が居る。
様々なクライアントとプロジェクトを進めていましたが、
そのばそのばの場当たり的なものではなく、基盤となるものを提供する。
そのやり方としては、一つ目、データが中心となり、シグナル、データを元にするもの。
出て来たデータから、どこがおかしくなるのかを診断します。
動作が中心になっている、モデルベースのアプローチもあります。
システムのモデルを構築することで診断をやっていくものです。
モデルから推論していくものです。

Modeling Process (mutiphysics models)
https://www.modelica.org/
モデリングのプロセス、車のモデルの例、MODELICA という言語でモデリングしています。
既存のライブラリがあって、コンポーネントが無い場合は、自分で式を書くこともできます。
パワートレインの場合、1万もの要素が関わってくるものになります。
こういったアプローチは比較的新しいものです。
モデリング言語が使えるようになったのは最近で、コンピュータ解析できるようになったのも最近です。

使い方は、物理的モデルがあり、物理的モデルに対して現実と比較し、予測と実際のシステムとの比較をし、
現実の物とモデルとの差分が生じます。その場合どこか違うわけです。
その情報をもとに、どこが違うのかを特定していきます。

モデルベースの診断は、parc で開発したもの、アルゴリズムもベストなものを持っていますし、
巨大なモデルにも当てはめることができます。

もう一つの、データからのアプローチを紹介します。
データが中心になったアプローチは、
まず診断、予測、異常の検出です。
このデータが中心になったもの、オフラインとオンラインのものを使います。
まずオフラインは、障害シグナルを取得します。
そして、トレーニングセットの学習が完了しましたら、オンラインデータと比較します。
オンラインデータとして、ニューラルネットワーク、サポートベクターマシン SVM などを使った学習です。
予測の段階では、時系列の解析ツール、ARMA など。
異常検出の場合、オンラインのデータのみ、蓄積していって、何が正常であるのかを学習し、
その学習の場合、Density ベースのメソッドを活用

データドリブンの方法と、モデルベース、
データが沢山とれる場合もとれない場合、モデルにあった場合、合わない場合がある。
モデルベースの場合データそのものの量が沢山必要なわけでは無い。

設計、デザインに関する知識、データ中心の場合は特に関係無いが、
モデルベースの場合、設計知識が重要になる。
必要な労力は、データ主導の場合は、測定に応じて労力が比例する。
モデルベースの場合は、システムの複雑度に対して労力がかかっていく。

その次が、融通性です。他のものへの再利用は、
データ中心の場合は、他には再利用できない。
モデルベースの場合、エンジンのモデルを作れば、他のエンジンにも応用が可能になる。

特徴量の抽出、データ主導の場合たくさん必要、
モデルベースの場合はそれほど必要では無くなる。
アプローチを構築するのがどれだけ大変か？データ主導の場合、非常に労力がかかる。
モデルベースの場合は、特に選択を気にすることなくできる。

さらにどういうところを目指しているか？自己適応していくような機械を目指している。
データ主導の場合に比べて、モデルベースの場合は自己認識マシンにつながっていく。

これを発見するには、非常な大変な想いと経験から導き出したもの。
データも無いし、モデルも無い中で、調べながらここまできました。

例：これまで取り組んできたもの、
軍用車、製造現場、列車のシステム、バッテリー、赤色LED、電力システム
プリンタ、製造現場のフロアレイアウト、車の状態をコントロールするものなど。

リチウムイオン電池のケース
ハードウェア、ソフトウェアの両方が関わっている、
バッテリーに設置するセンサー、光の回折が計れるセンサーが入っていて、
電池内部の歪みと温度を計測することができるもの。
このようなセンサーの利点は、センサーが安価であること、
最高の状態で精度が 5%？？？, さらに充電速度を早くすることも求められている。

充電状態と、バッテリーの劣化状態を確認したい。
どのようなアプローチを取るかは、電池のモデルは存在せず、
メーカーから情報を提供してもらえなかったので、
データを中心とした解析をすることにした。
データを測定、バッテリーの温度と内部歪みの測定データをラベリングしていきます。
動的時間伸縮法を使っていて、
時間を横軸に、波長のシフトを縦軸に、トレーニングデータ、実際のテストデータを取る、
意味のあるデータが導出されるようになる。
この Dynamic Time Warping は、とれるデータが少ない時に役立つ。

実際の充電状態と、エラーの相関、1.4% で、想定していたものよりも遥かに低い。
ハードウェアと、データによる取り組みを組み合わせたもの。

軍用車両は、ドアがよく壊れるので、ドアに関する解析。
産業用アクチュエーターの診断データにかける。
トレーニングデータとして提供されたものは、シグナル、どれがどの障害にあたるのか。
ここではモデルベースを使うこともできたのですが。
このような処理を行うアルゴリズムを作り、納入した。

アルゴリズムのためのデータ、
どういう障害があるのか、どのような状態なのか？
特徴量の作成について。
データ主導のアプローチの場合、必要になる作業。
時間軸でみると、特徴量を定義していきます。
最初に上がったのは、最初に落ちたのは、それをみていくつかのステートに分けていきます。
それぞれのステートに関してまとめを作っていて、
最少、最大、意味、標準偏差、継続時間など
信号を変換し、機械学習を適応していき、
この信号であれば、この状態であるということが特定してくことができます。

機械学習で多くのデータを解析することで、データの中のどのサブセットが故障にかかわっているのかが解ります。
コンド行列に関して、コンディションにおいては欠かせないもの。
理想的であれば、とられたデータをアルゴリズムのより分類が合致する、実際は 90数パーセント
どれだけの場合、正しかったか、間違ったのかをみると、分類精度がわかります。

ライフサイクルコストがどこに関わってくるか？
非常に早い、上流の段階で関わります。
多くのお客様にとって、信頼性が大きなコストに関わってきます。保証など。
これは、国防総省の案件で、信頼性が組み込まれた形で物が出来上がってこなければいけない。
このシステムをまず最初に開発し、それを商用化するために簡略化して開発しました。

はやい段階でモデル作成を行い、障害を組み込んだモデルを考えていきます。
障害がある設計のシミュレーションを行い、
最終的な結果は、障害が発生するリスクを受け入れるためには、どれぐらいの頻度でメンテナンスすれば良いのか？
実際に Web サイトで使えるもののあので、

FAME System Requirement Assessment Tool
http://fame-deploy.parc.com:2040/

エンジンのトランスミッションの例
システムの構成、システム、ミッションを何回、要件、要件の確立を設定。
自動的に成功率を出すための回数がでてきます。
こういったものがあると、設計者に役にたつ。
どのコンポーネントの障害が、全体のパフォーマンスに対して致命的なのか、
どれぐらい使ったらどうなるのか？
そのシステム構成がもっとも信頼性があるのか？どのようなメンテナンス戦略があるのかが判断できる。

もうひとつ良い点は、エンジニアリングをやり過ぎにならなくてすむ。
信頼性が必要だということで、必要以上に頑丈に作る必要が無くなる。

パワートレインの例、3877のコンポーネントがあり、
全ての障害の解析を行うには 17時間かかる。

parc で目指しているもの、
何かが壊れてから対応する。
予防保全。
コンディションベースのメンテナンス
自己対応型、障害が起こった時に、システム自体が自己対応するもの。
ある一つの車両に起こった問題対策があれば、他の車両にも対応できるというもの。

Contact: aki _at_ parc.com