鉄道車両の圧縮空気処理装置（APU）：時系列データベースで「説明可能な」状態監視画面を作る

10 時間前

読了時間: 7分

はじめに

予知保全と聞くと、機械学習モデルが故障を予測する場面を思い浮かべることが多いでしょう。しかし、現場の保守担当者が本当に知りたいのは「なぜそう判断したのか」です。スコアを一つ示すだけのシステムでは、信頼を得ることは難しくなります。センサーデータを時間軸に沿って確認し、結果の理由を説明できて初めて、現場で役立つものになります。

本記事では、UCI Machine Learning RepositoryのMetroPT-3データセットをMachbase Neoに取り込み、鉄道車両の圧縮空気処理装置（APU）の状態を対話型ダッシュボードで探索するデモを紹介します。このデモのHealth Score（健全性スコア）とイベントは、学習済みモデルの出力ではなく、プロジェクト内で定義したルールに基づく指標です。計算式を公開しているため、誰でもスコアの算出過程をたどることができます。

MetroPT-3を選んだ理由

MetroPT-3は、2020年2月から8月にかけて鉄道車両のAPUから収集されたテレメトリです。1,516,948時点のデータがあり、圧力、温度、電流、バルブ、スイッチ、パルスなど15種類の元センサーチャネル、合計約2,275万個のセンサー値を含みます。特に、データセットの作成者が公開した空気漏れの故障区間が4つあるため、センサーの変化が実際の故障とどう結び付くのかを目で確認できます。圧縮機、三相モーター、サイクロン式分離フィルター、ドライヤータワー、貯蔵タンク、バルブ、空圧パネルへと続く空気の流れは直感的で、可視化にも適しています。また、CC BY 4.0ライセンスにより、出典を表示して再利用できます。

ただし、注意すべき点もあります。公開資料から分かるのは鉄道車両用圧縮機のAPUであることまでで、メーカー、機種、車両番号は不明です。また、CSVで実際に観測されるデータ間隔は約9～10秒（約0.1 Hz）で、データセットの説明に記載された1 Hzとは異なります。そのため、このデモでは任意のサンプリング周波数を仮定せず、実際の1,516,948時点を基準に表示します。元のタイムゾーンも公開されていないため、時刻は元データのまま保持し、画面には「データセットの現地時刻・タイムゾーン未指定」と表示します。不明な点を不明なまま明示することが、説明可能な分析の出発点だと考えました。

デモで確認できること

ダッシュボードでは、約151万時点の全データを時間軸上で探索しながら、3Dで表現したAPUの空気の流れと装置の状態を確認できます。15種類のセンサーの変化、公開された空気漏れ区間、ルールに基づくHealth Scoreとイベントを同じ時間軸上に重ねて表示します。再生機能でセンサーデータを時系列に沿って確認することもできます。英語と韓国語のUIに対応し、90秒のガイドツアーも用意しています。

ここで重視した設計原則は、情報の出所を区別することです。データセットが提供する正式な故障区間と、プロジェクトで計算した派生イベントは、画面上で明確に区別しています。機械学習の精度を主張するのではなく、元データに基づく事実と、計算による解釈の境界を分かりやすく示します。

Machbase Neoへの保存方法

中心となるテーブルはIIOT_METRO_TIMELINEです。value JSON SUMMARIZED WITH ROLLUPを使用するタグテーブルで、データセットmetropt-3-uci-791とアセットapu-01の下に、telemetry、baseline、eventという3種類のJSON行を保存します。生のテレメトリだけでなく、基準線や派生イベントも同じ時間軸モデルに格納する構成です。

この構造の利点はロールアップにあります。Machbase NeoがJSON値全体を対象にSEC、MIN、HOURのロールアップ階層を自動管理するため、APIは一度のAVG(value)クエリですべての数値フィールドを集計し、その後でユーザーが選択したセンサーだけを取り出せます。センサーが15種類でも30種類でも、センサーごとに集計クエリを書く必要はありません。画面を拡大・縮小すると、表示解像度に合ったロールアップ階層が選択されるため、151万時点のデータも高速に検索できます。行の種類、イベントの種類、イベントの出所、健全性の等級など、頻繁に絞り込む条件にはJSONパスインデックスを設定しました。

CSVの取り込みは、ファイル全体を一度にメモリへ読み込まず、ストリーミングで処理します。約218 MBの元ファイルをJSHのメモリに丸ごと読み込まないよう、ダウンロード用の補助スクリプトもコマンドを表示するだけの設計にしました。

説明可能なHealth Score

健全性スコアの基準期間は、2020年2月の1か月間です。この期間の時間単位の特徴量からp05、p50、p95の分位数を求め、直近1時間の移動窓の値が基準分布からどれだけ外れたかをリスクに換算します。移動窓は実際のタイムスタンプ間隔を使い、少なくとも45分間のデータがなければ有効としません。データの間隔が120秒を超えた場合は窓をリセットします。つまり、センサーの欠測を無理に埋めない方針です。

指標を「値が高いほど危険なもの」と「値が低いほど危険なもの」に分け、それぞれのリスクを0から1の範囲に正規化します。

値が高いほど危険 = clamp((x - p95) / max(3 × (p95 - p50), ε), 0, 1)
値が低いほど危険 = clamp((p05 - x) / max(3 × (p50 - p05), ε), 0, 1)

こうして求めた4つのリスクを重み付きで組み合わせたものが、健全性スコアです。

健全性スコア = 100 × (1
  - 0.40 × 圧力低下リスク
  - 0.25 × 圧力回復リスク
  - 0.20 × 1時間当たりの起動回数リスク
  - 0.15 × 圧縮機の負荷運転率リスク)

主な故障が空気漏れであるため、圧力低下と圧力回復の遅れに最も大きな重みを与えました。残りの2項は、漏れがあると圧縮機の起動頻度が増え、負荷運転時間も長くなることを反映しています。油温は運転状態を説明するため画面に表示しますが、季節変動の影響を避けるため、健全性の計算式からは意図的に除外しました。2月を基準に8月までを見るデータでは、温度を含めると故障ではなく季節を検出してしまう可能性があるためです。

イベントも瞬間値ではなく、条件の継続で定義しました。健全性スコアが60未満で、異常に寄与する要因が2つ以上ある状態が3時間連続した場合を早期警告とします。スコアが30未満で、寄与要因が3つ以上ある状態が1時間続いた場合は危険、スコアが70以上で3時間維持された場合は回復と判断します。一時的な外れ値でアラームが鳴らないようにするためです。これらはあくまで検証可能なデモ用のルールであり、学習済みの故障分類モデルではありません。

結果の根拠まで示すEvidence API

バックエンドは、少数の読み取り専用APIで構成しています。/api/healthと/api/manifestは状態とメタデータを、/api/frameは指定時刻の1時点を返します。seek=next|prevオプションを使えば、テレメトリの空白区間を飛ばし、次または前のデータへ移動できます。/api/windowは期間指定の検索、/api/signalsは選択したセンサーの時系列（例：signals=reservoirs,health_score）、/api/eventsはイベント一覧を提供します。

このデモで特に気に入っているのは、すべてのデータ応答に根拠情報が付くことです。実行したSQL、バインド値、対象テーブル、結果の例、実測クエリ時間、使用したロールアップ間隔まで応答に含まれるため、画面の数値がどのクエリからどう得られたかを追跡できます。センサー名は許可リストで制限し、APIの入力値が任意のSQL式として使われることを防いでいます。「速い」という言葉を信じてもらう代わりに、実測したクエリ時間を応答に含める仕組みです。

実際に動かしてみる

必要なものは、Machbase Neo 8.5.x、git、curl、sha256sum、unzip、およびWebGL対応ブラウザーです。machbase-neo実行ファイルがあるディレクトリで、リポジトリを取得します。

cd <MACHBASE_NEO_INSTALL_DIR>
git clone https://github.com/machbase/neo-train-apu-demo.git
cd neo-train-apu-demo

元データはリポジトリに再配布していないため、自分でダウンロードしてハッシュを検証します。補助スクリプトを実行するとダウンロード用コマンドが表示されるので、そのコマンドをシェルで実行します。

../machbase-neo jsh scripts/download-data.js

curl -L --fail --output 'data/raw/metropt-3/metropt-3-dataset.zip' \
  'https://archive.ics.uci.edu/static/public/791/metropt%2B3%2Bdataset.zip'

printf '%s  %s\n' \
  'aab991a970e58210de853bb8078ce0e63abb4d9412fdc5c79792dae3d8e1721a' \
  'data/raw/metropt-3/metropt-3-dataset.zip' | sha256sum --check

unzip -j -o 'data/raw/metropt-3/metropt-3-dataset.zip' \
  'MetroPT3(AirCompressor).csv' -d 'data/raw/metropt-3'

次に、スキーマを作成してCSV全体を取り込み、サーバーを起動します。既存のテレメトリがある場合、インポーターは上書きを拒否します。再取り込みする場合は--resetを付けてください。

../machbase-neo jsh scripts/ingest.js
../machbase-neo jsh app/server.js --host 127.0.0.1 --port 56802

ブラウザーでhttp://127.0.0.1:56802 を開きます。別のPCから接続する場合は--host 0.0.0.0で起動し、ファイアウォールでポートを開く必要があります。取り込み後はscripts/selftest.jsで、テレメトリが1,516,948行あること、元の時刻範囲が2020-02-01 00:00:00～2020-09-01 03:59:50であること、正式な空気漏れ区間が4つあることを確認できます。データがない場合に合成データを代わりに表示せず、セットアップ案内を表示するのも、意図した動作です。

おわりに

Industrial AIでは、モデルの精度と同じくらい、結果を人が検証し、説明できることが重要です。このデモは、鉄道APUの時系列データが、ロールアップを活用した検索、ルールに基づく健全性指標、根拠を含むAPIを経て、一つの状態監視画面につながる流れを示しています。ソースコード全体はGitHub（machbase/neo-train-apu-demo）で、デモ動画はショーケースページで確認できます。デモや派生資料を配布する際は、MetroPT-3のUCI出典表記を維持してください。