仮想時刻による過去データ検証基盤

[takaeda]

概要

過去の蓄積データを使って、任意の時刻範囲での運用シナリオを再現・検証できる基盤機能の提案です。

背景・動機

現在のIF-HUBは「新しいデータが取り込まれる」というイベントをトリガーとして動作します。
しかし、パイプライン設計や運用ルールの妥当性を検証するには、過去データを使って
「当時どう動いたか／動くべきだったか」を再現する必要があります。

リアルタイムのイベント駆動を過去に対して再現するのは複雑なため、
発想を転換し「任意の基準時刻を指定して、その時点で見えていたデータを取得・処理する」
というアプローチを提案します。

提案する機能

1. Fetcherの拡張：reference_timeパラメータ

GET /api/fetch?
    reference_time=2024-03-15T14:00:00&
    window=1hour&
    tags=tag1,tag2

「reference_time時点で見えていたデータ」を取得できるようにする。

2. 検証セッション管理

• シナリオ定義（YAML）の読み込み
• イベントタイムライン（モデル構築、追加プロット等）の生成
• 検証ループの実行

3. 仮想時刻→toorPIAマップID対応表の管理

toorPIA側は実時刻でマップを管理するため、IF-HUB側で
「検証上の仮想時刻」と「toorPIA側のマップID」の対応を保持する。

model_timeline:
  - virtual_time: "2024-03-01T02:00:00"
    toorpia_map_id: "map_abc123"
  - virtual_time: "2024-03-02T02:00:00"
    toorpia_map_id: "map_def456"

4. 検証結果の保存

各プロット時刻での逸脱度、使用モデル、既知イベントとの対応を記録。

シナリオ定義例

validation:
  period:
    from: "2024-03-01"
    to: "2024-03-31"
  
  model:
    rebuild_schedule: "daily@02:00"
    training_window: "1month"
  
  plot:
    schedule: "hourly"
    lookback: "1hour"
  
  pipeline:
    steps:
      - moving_average: { window: "10min" }
  
  known_events:
    - time: "2024-03-15T14:30:00"
      label: "ベアリング異常"

[takaeda]

実装上の課題と注意点

1. Fetcher拡張：reference_timeパラメータ

現状の確認事項

• 現在のFetcherのデータ取得ロジック（fetcher/配下）の時刻処理部分
• SQLiteへのクエリで時刻範囲指定がどう実装されているか

実装方針

// 既存
const data = await db.query(
  `SELECT * FROM timeseries WHERE timestamp BETWEEN ? AND ?`,
  [from, to]  // fromとtoは実時刻
);

// 拡張後
// reference_timeが指定された場合、toをreference_timeに固定
const effectiveTo = referenceTime || Date.now();
const effectiveFrom = effectiveTo - windowMs;

注意点

• 既存APIとの後方互換性を維持（reference_time省略時は従来動作）
• タイムゾーン処理の一貫性（UTC統一を推奨）

---

2. 検証セッション管理

データ構造の選択肢

A) SQLiteに新テーブル追加

CREATE TABLE validation_sessions (
  id TEXT PRIMARY KEY,
  scenario_yaml TEXT,
  created_at DATETIME,
  status TEXT  -- 'running', 'completed', 'failed'
);

CREATE TABLE model_timeline (
  session_id TEXT,
  virtual_time DATETIME,
  toorpia_map_id TEXT,
  training_from DATETIME,
  training_to DATETIME,
  FOREIGN KEY (session_id) REFERENCES validation_sessions(id)
);

CREATE TABLE plot_results (
  session_id TEXT,
  virtual_time DATETIME,
  model_map_id TEXT,
  deviation REAL,
  raw_result JSON,
  FOREIGN KEY (session_id) REFERENCES validation_sessions(id)
);

B) JSONファイルベース（シンプルだが検索性が低い）

推奨: SQLiteテーブル追加。既存のDB基盤を活用でき、検索・集計が容易。

---

3. イベントタイムライン生成

実装上の考慮点

function generateEventTimeline(scenario) {
  const events = [];
  let current = scenario.period.from;
  
  while (current <= scenario.period.to) {
    // モデル再構築イベント（例：毎日02:00）
    if (isModelRebuildTime(current, scenario.model.rebuild_schedule)) {
      events.push({ time: current, type: 'model_rebuild' });
    }
    
    // プロットイベント（例：毎時）
    if (isPlotTime(current, scenario.plot.schedule)) {
      events.push({ time: current, type: 'plot' });
    }
    
    current = advanceTime(current, minInterval);
  }
  
  return events.sort((a, b) => a.time - b.time);
}

注意点

• スケジュール表現の解析（cron形式？独自形式？）
• 長期間の検証でイベント数が膨大になる場合のメモリ管理
• イベント順序の保証（同一時刻にmodel_rebuildとplotがある場合、model_rebuildが先）

---

4. toorPIA API連携

検証用マップのメタデータ

await toorpiaAPI.createMap(data, {
  tags: ['validation', sessionId],
  description: `Validation session ${sessionId}, virtual_time: ${virtualTime}`
});

---

5. 実装フェーズ案

Phase 1: 最小構成

• Fetcherへのreference_timeパラメータ追加
• CLIベースの検証実行スクリプト
• 結果のJSON出力

Phase 2: 永続化

• 検証セッションのDB保存
• 結果の検索・比較機能

Phase 3: 統合

• REST APIエンドポイント追加
• Issue パイプライン設計支援機能 #21（パイプライン設計支援）との統合

---

6. テスト戦略

単体テスト

• generateEventTimelineのスケジュール解析
• resolveMapIdの時刻→マップID解決

統合テスト

• 短期間（1日分）のデータを使った検証ループ実行
• toorPIA APIモック使用

受け入れテスト

• 既知の異常イベントを含む過去データで検証実行
• 異常が検出されることを確認