機械学習を使用したディーゼル車の状態監視システムのビルド

投稿者:

近藤 稔　氏 - 公益財団法人鉄道総合技術研究所
矢野 達哉 氏 - 株式会社 テス

背景

鉄道総合技術研究所 (RTRI) は、旧日本国有鉄道 (JNR) の研究部門として発足した組織であり、JRグループ設立の際、JNRの分割民営化に続いて設立されました。RTRIは現在、JRグループ所属の鉄道事業者から提起される技術的な問題を含め、幅広いテーマを扱っており、鉄道分野全体をさらに発展させるテクノロジの研究開発 (R&D) を積極的に行っています。

RTRI車両技術研究部の駆動システム研究室では、列車やディーゼル車に取り付けられる駆動コンポーネント (以下、「駆動システム」) に関連する研究活動に取り組んでいます。具体的には、列車の場合、これにはモータ、カップリング、ギア装置などのコンポーネントが含まれ、ディーゼル車の場合には、エンジン、トランスミッション、プロペラシャフト、ギア装置が含まれます。現在、研究室ではディーゼル車に搭載される駆動システムの状態監視に取り組んでいます。

たとえば、車輪、軸受、またレールや架線などの地上設備について、それらの状態監視を対象とした研究をすでに進めています。この研究の目的は、それぞれの状態を継続的に監視して故障を検出し、高確度の修復作業を促進することです。また一方で、これらの情報に基づいて装置の寿命を予測し、それに応じて効果的なメンテナンスを実施できるように、故障につながる可能性のある兆候を早期に検出する必要性もあります。こうした概念は「予知保全」と呼ばれています。 しかし、駆動システムの分野における状態監視のR&Dは、まだそれほど進展しているわけではありません。列車は通常、10両または12両編成の複数の車両で構成されていますが、1両の列車には全体として多数のモータが装備されます。実際にはこうした冗長性が設計に組み込まれているために、モータの1つに軽微な故障が生じたとしても、列車は問題なく走行を続けることができます。また、過去の経験から、駆動システムは容易に壊れることはないと考えられています。ただし、地方の鉄道路線などでは、1両編成のディーゼル車が運行されている場合があります。そのような場合、エンジンが1つでも故障すると、列車の運行が妨げられ、その路線のすべての運行が停止してしまう可能性があります。こうした状況を防ぐために、また安全性と信頼性を高めるための一般的な考慮事項として、駆動システムの状態を監視できる機能が従来から求められています。

RTRIは、ある鉄道事業者の保守部門から、ディーゼル車の状態監視に関する研究開発の依頼を受け、その結果として、この分野のR&Dを進めることを決定しました。

今回の提案で監視対象となったのは、ディーゼルエンジンやトランスミッションなどの駆動システムでした。しかし、これらの駆動システムが予期せずに壊れることはめったにありません。むしろ、時間の経過とともに劣化する傾向があり、特定のしきい値に達したときにのみ破損します。したがって、状態監視システムにはこうした漸次的な劣化を把握できることが求められます。RTRIにR&Dを依頼した鉄道事業者は、管轄下にあるすべてのディーゼル車の状態をリモート監視できる機能を望んでいました。保守部門からの要求ということで、明確な目標の1つとして「予知保全」の達成があったかもしれません。 予知保全の狙いは、時間の経過とともに劣化することがわかっているコンポーネントやユニットについて、その劣化レベルを追跡して余命を予測し、適切なタイミングでメンテナンスを実施することにあります。こうした考え方がもたらすメリットの1つは、保守コストの削減です。しかし、実際の研究目的は予知保全ではなく、むしろ異常の検出でした。その理由は、今回のプロジェクトの焦点となった駆動システムは、通常は劣化しにくく、容易に破損することもないとわかっていたためです。それでも、不測の事態によって故障が発生する可能性はあるため、異常を検知し、故障を検知した場合に迅速な対応が取れるように、状態監視を行います。予知保全は、エラー検出、診断、寿命予測という3つの主要なプロセスが達成された場合にのみ、可能となります。特にこのプロジェクトでは、将来予知保全の開発が行われる可能性を視野に入れたうえで、エラー検出のテクノロジを確立することに焦点を当てていました。

課題

図1の例は、将来予想される状態監視システムの姿を示しています。このシステムは、最初に振動センサを使用して、駆動システムから発生する振動を検知します。取得した振動信号は状態監視デバイスに送られ、アナログ/デジタル (A/D) 変換を行います。次に、状態監視デバイスは、このデジタルデータにオクターブバンド解析を適用します。オクターブバンド解析の手法は騒音や振動を評価する目的でよく使用されます。オクターブバンドとは、上限と下限の周波数比が1オクターブ (2倍) になる周波数帯域幅です。つまり、アナログ/デジタル変換後、データは各オクターブバンドに分割され、それぞれのバンドの振動の力が計算されます (図2)。こうして取得した結果は、次にサーバに転送されます。このデータは、PCを介してサーバにアクセスすることによって取得され、診断プログラムを使用して異常がないか解析されます。診断プログラムには機械学習アルゴリズムが組み込まれており、正常時の状態操作と比較することでエラー検出が行われます (図3)。この診断プログラムの開発が、私たちの研究の中心となりました。プログラムはPythonで記述され、機械学習の「scikit-learn」ライブラリを使用して実現されました。

システムのビルドにあたって遭遇した最大の問題は、使用するセンサと、装置の堅牢性でした。つまり、実際の運転時における車両の振動や温度といった、極端な条件にも耐えられるようなコンポーネントが必要でした。列車のモータやディーゼル車のエンジンが故障することはめったになく、バラスト (線路に撒かれる砂利) の飛散、また氷や雪との衝突にも耐えるほどの堅牢性があります。状態監視システムで使用される装置、センサ、配線などのコンポーネントの方が、駆動システム自体よりも壊れやすいことは明らかです。砂利が飛散する可能性のある場所に状態監視デバイスを設置することはまずありませんが、測定装置を取り付けるうえで望ましくない場所であることは確かです。そのうえ、センサや配線はかなり過酷な条件にさらされます。したがって、選択するコンポーネントは可能な限り堅牢である必要があります。コストの面で見ると、これはデメリットとなります。

ソリューションとメリット

NIのCompactRIOは、このような過酷な環境に耐えられる製品として最適であり、状態監視デバイスに使用した場合に振動や温度変化に耐えうる堅牢な製品として高く評価されました。CompactRIOを選択したことで、NIのグラフィカル開発プラットフォームであるLabVIEWを利用して、必要なすべての機能をプログラミングすることもできました。最終的には、以下に説明するすべての理由から、この組み合わせを選択しました。

第一に、システムを実際の運転車両に取り付ける場合、複雑なスイッチ操作などの作業の必要性を回避できるようにしたいと望んでいました。つまり、測定を自動的に開始/停止できるメカニズムをビルドしたかったのです。CompactRIOならば、LabVIEWを使用してこの種のプロセスを簡単に実現できることに加え、優れた柔軟性もあります。NI製品は、測定デバイスとPCを統合する合理化されたソリューションを提供していると言えるでしょう。PCを使用して、望みの方法で測定デバイスを操作することができます。NI製品に匹敵するものは、まず見当たりません。実際、別のメーカー製のPCベースの産業用自動測定製品を見つけましたが、振動センサやデータ収集コンポーネントへの接続が面倒に思われました。それに対して、CompactRIOではセンサの接続やデータのインポートが非常に簡単です。また、フィールドプログラマブルゲートアレイ (FPGA) を使用して、極めて高速な処理を実現することもできます。以上の理由から、NI製品の使用を選択しました。

図1は、このシステムの実際の使用を示しています。このR&Dの段階ではサーバとの通信機能は必要ではなく、状態監視デバイスを使用してデータを収集できれば十分です。また、振動センサをCompactRIOに接続してセンサからデータを収集し、CompactRIOを使用してオクターブバンド解析を適用しました。その後、解析結果をSDカードに保存しました。一定量のデータが蓄積されたら、SDカードを取り出し、PCの診断プログラムを使用して、故障の発生につながる可能性のある兆候がないか判断しました。なお、CompactRIOは振動や温度の変動に対して高い耐性がありますが、車両の電源環境における電圧変動の範囲が極めて大きく、CompactRIOでも耐えられないほどでした。そのため、鉄道車両専用のパワーモジュールと組み合わせて状態監視デバイスをビルドしました (図4)。

このシステム監視デバイスの設置にあたったのは、株式会社テスです。同社は、RTRIが実施する研究開発を支援する目的で設立されました。テスのスタッフで今回の開発を担当された矢野氏は、これまでプログラミング作業の経験がありませんでした。およそ1年をかけて、eラーニングを利用してLabVIEWでのプログラミング手法を習得した後、状態監視デバイスの開発を担当されました。矢野氏は私たちの設計に基づいて配線などの作業に着手し、CompactRIOやパワーモジュールなどの他のコンポーネントを1つのユニットに収めました。また、プログラミングにLabVIEWを使用して、必要なすべての機能を実現しました。その結果、わずか6週間で状態監視デバイスの最初のモデルを完成させることができました。LabVIEWのグラフィカルな操作によるプログラミングが、開発期間の短縮に貢献したことは間違いありません。たとえば、eラーニングで使用したテキストは取り付け作業の際にたいへん役立ちました。また、サンプルプログラムが多数付属していて、変更を加えなくても利用することができました。さらに、LabVIEWにはオクターブバンド解析用のライブラリも付属しているので、必要な機能をごく簡単に実現できます。実際、サンプルプログラムとライブラリを組み合わせるだけで、さまざまなタスクを実行することができます。LabVIEWを使えば、関数1つ1つにテキストベースのコーディングを行う必要がないので、安心してタスクを開発できます。

最初のモデルの開発が完了してからは、さまざまな改善や変更を加えて、振動の測定だけでなく回転速度や負荷などのデータも取得できるようにしました。その結果、実際の車両に状態監視デバイスを取り付けて振動データを取得し、オクターブバンド解析の結果を蓄積することができました。また、当初の目的に沿った診断プログラムを用いて異常を特定できることも確認しました。特に、駆動システムに組み込まれているさまざまな機械の異常を1つのアルゴリズムで検出できるようになりました。個々の機械のチューニングや故障などの作業を実行する必要はありません。振動の変化を示すタイプの故障であれば、どのようなものでも検出できるはずです。ただし、エラーの有無を検出しただけでは、どこで問題が発生したのかを保守担当の部門に知らせることができず、どう対処すればよいのかわかりません。その対応策として、エラーの内容に応じて異なる周波数帯域幅で変化が生じることを実証することができました。これにより、故障への対処がずっと簡単になります。

一般に、車両の振動を監視する際は以下のような懸念事項が生じることが予想されます。振動の状態は場所によって異なるため、収集したデータから正確な診断を下すことが難しい場合があります。実際そうした理由から、線路の特定の区間における運転時に発生する振動のみを監視し、異常の有無を判断するという手法を取る場合があります。しかし、私たちが開発した状態監視デバイスは、このような動作は行いません。これにはいくつかの理由がありますが、最も重要なのは、機械学習を使用していることです。振動の状態が、車両が走行している線路の区間によって異なる場合でも、線路の各区間で十分な学習データを取り込むように装置を学習させることができれば、通常の運転とは異なる振動が発生した場合に異常の発生を検出できるメカニズムを構築することが可能なはずです。したがって、振動が場所に依存することは今のところ大きな問題にはなっていません。

今後の展開

現在のアプローチでは、機械が完全に故障する前に、故障の兆候をできるだけ早期に特定しています。このことについては、テクノロジの観点から概ねすでに達成しているものと自負しています。しかし、理想的な状況に至るまでにはまだ長い道のりがあることも事実です。したがって、今後は以下の目標を追求していきたいと考えています。

まず、実際の車両データを日常的に測定し続けると、膨大な量のデータが蓄積されます。また、車輪の温度や摩耗状態といった条件の変化に応じて、振動の変化が発生します。こうした多種多様な条件にわたって機械学習を実行するためには、極めて大量のデータを入力して学習させる必要があります。コンピュータがどれほど強力であっても、このデータ量は依然として問題を引き起こすため、現在、すべてのデータの中から必要な特性のみを抽出することのできるアルゴリズムを研究しています。

異常が検出されたら、そのエラーがどの段階で発生したのかも明らかにする必要があります。たとえば、問題のコンポーネントを交換するために列車の運行を緊急に停止しなければならないのか、それとも、そのコンポーネントを引き続き長期にわたって使用することが許容されるのかを判断する必要があります。1日あたりの異常振動の割合を評価することで、特定のコンポーネントの劣化の程度を判断できるかもしれないということが、明らかになりつつあります。

また、振動以外の要素を測定して異常を検出しようという試みも行っています。振動センサは高価であるため、他の安価なセンサを使用したいということも動機の1つとなっています。たとえば、物体の電圧または電流に着目し、放出されたノイズを解析してエラーが発生したかどうかを判断する、という方法を検討しています。解析方法としては、おそらく振動解析と同様のアルゴリズムを使用できると考えています。当然ながら、ディーゼル車だけでなく、列車の駆動システムにも応用範囲を広げていければと考えています。

さらに、状態監視システムはオクターブバンド解析の範囲まで実行しますが、一方で、異常の有無の検知に使用される診断プログラムはPC上で実行されています。しかし、このシステムが実用化されれば保守部門のスタッフが運用することになるので、車両の異常をほぼリアルタイムで検知できるようにしたいと考えています。異常の検知を状態監視システム側で行い、結果としてエラーの重大度の指標を取得できるようにしたいと考えています。この指標は、その後自動的にサーバに送信できます。言い換えれば、異常の程度を計算する機械学習アルゴリズムを状態監視システムに組み込みたい、ということです。機械学習によって生じる膨大な計算負荷は、学習段階でのみ発生します。実際のアプリケーションでは、使用されるモデルは学習後に得られることになるので、計算負荷は最小限に抑えられるでしょう。したがって、CompactRIOを用いた実行も可能となるはずです。

最後になりますが、このシステムを実用化するうえで最大の障害となっているのは、コストです。すでに説明したように、駆動システムは簡単に壊れることはなく、ほとんどの場合、1つの駆動システムが壊れても列車は走行を続けることができます。たとえ1両のディーゼル車が突然運転不能になったとしても、コスト的にはそれほど大きな問題にはならないでしょう。こうした条件に基づいた場合、すべての車両のすべての駆動システムにセンサと状態監視デバイスを設置したとしても、おそらく最大限の費用対効果は得られません。駆動システムは本来、時間の経過とともに劣化するような設計になっていないため、将来のメンテナンスの頻度が高くなる可能性はほとんどありません。したがって、予知保全に通常伴うコスト削減のメリットは限定的なものになるでしょう。とはいえ、情報処理に必要なシステムのコストが劇的に低下していることもあり、状態監視は依然注目を集めています。たとえば、かつてはFFT (高速フーリエ変換) アルゴリズムの実行能力を備えた装置を購入するためだけに数百万円も費やす必要がありました。しかし最近では、FFT機能を内蔵したセンサを5万円程度で購入できるようになりました。状態監視システムによって、不測の事態に対処できるようになり、安全性と信頼性が向上することは疑いのないことであり、こうした構成部品の価格が今後さらに下がることを心から望んでいます。

投稿者​情報:

近藤 稔　氏
公益財団法人鉄道総合技術研究所
国分寺市光町二丁目8番地38
東京都 185-8540
日本