AWS IoT FleetWise

解決する課題

• 車両には多数のセンサーやECUがあり、信号の名称や形式が車種・メーカーごとにバラバラで、横断的にデータを扱えない
• すべての信号を常時クラウドへ送ると通信量とコストが膨大になり、現実的に収集しきれない
• 走行データを分析や機械学習に使いたいが、収集・標準化・転送の基盤を自前で構築・運用する負担が大きい

主要概念と用語

• 信号カタログ（Signal Catalog）: 車両から取得できる信号を共通の語彙として定義したもの。車種を横断して標準化の基準になる
• 車両モデル（Vehicle Model / モデルマニフェスト）: 特定の車種が持つ信号の集合を定義したテンプレート。同型の車両に再利用する
• デコーダマニフェスト: 生のバス信号（CAN や OBD-II など）を信号カタログの標準信号へ変換する方法を定義したもの
• 車両（Vehicle）: クラウド上に登録される個々の車両の表現。車両モデルとデコーダマニフェストに紐づく
• キャンペーン（Campaign）: どの信号を、どんな条件で、どこへ収集するかを定義した収集計画。クラウドから車両へ配信される
• エッジエージェント: 車載側で動作するソフトウェア。キャンペーンに従い信号をデコード・収集してクラウドへ送る
• 収集スキーム: 条件成立時に集めるか、一定間隔で集めるかといった収集の方式

仕様・制限・クォータ

• フルマネージドで提供され、信号の標準化定義・収集計画の配信・データ転送をサービス側が担う。利用者は収集基盤の運用を意識しない
• 車両の生信号はデコーダマニフェストで標準信号へ変換され、車種が違っても共通の名前でデータを扱える
• 収集はキャンペーンで制御し、特定の条件が成立したときだけ集める方式や、一定間隔で集める方式を選べる
• 収集したデータの送り先にはAmazon S3 や Amazon Timestream などを指定できる
• 信号カタログの信号数、キャンペーン数、車両数などには上限がある。具体的な数値は変動するため、最新値は公式ドキュメントで確認する
• 対応する車載プロトコルや地域（リージョン）には範囲があるため、利用前に対応状況を確認する

内部の仕組み

AWS IoT FleetWise は、車両側のデータ収集からクラウドでの集約までを一連の流れとして提供します。まずクラウド上で信号カタログを定義し、車両から取得しうる信号を共通の語彙として標準化します。次に車種ごとの車両モデルで、その車種が持つ信号の集合を表現し、デコーダマニフェストで CAN や OBD-II といった生のバス信号を標準信号へ変換する方法を定義します。これにより、メーカーや車種が異なっても、クラウドでは同じ信号名でデータを扱えます。

実際の収集はキャンペーンで制御します。キャンペーンには、どの信号を、どんな条件で集めるかを定義し、クラウドから対象車両のエッジエージェントへ配信します。エージェントは車載側で信号をデコードし、キャンペーンの条件に従って収集します。たとえば、ある値がしきい値を超えたイベント発生時だけ周辺データを集めるといった条件付き収集ができ、常時全信号を送る場合に比べて通信量を大きく抑えられます。収集されたデータはクラウドへ送られ、S3 や Timestream などの指定先へ届けられ、分析・可視化や機械学習の入力として利用されます。

設計パターン / ベストプラクティス

• 信号カタログを全社共通の語彙として設計し、車種ごとの差異はデコーダマニフェスト側で吸収する
• 常時収集は避け、イベント条件付きのキャンペーンで必要な場面のデータに絞って通信量とコストを抑える
• 異常診断やインシデント解析の用途では、トリガー前後の周辺データを含めて収集できるよう条件を設計する
• 送り先は用途で使い分け、長期保存や機械学習の学習データは S3、時系列の参照は Timestream のように振り分ける
• 車両モデルとデコーダマニフェストはバージョンを管理し、車載ソフトの更新と整合させて段階的に展開する

運用・監視

• CloudWatch でデータ収集のスループットやエラー、キャンペーン配信の状況を監視する
• 車両ごとの収集状態やエージェントの稼働を確認し、データ欠落や未配信のキャンペーンを早期に検知する
• デコーダマニフェストや車両モデルの変更が既存車両に与える影響を把握し、変更は段階的に適用する
• 収集先（S3 や Timestream）への書き込み失敗に備え、送り先側の権限や容量、エラーハンドリングを点検する

コスト

• 主なコストは収集対象の車両数、収集するデータ量、データメッセージの件数などの組み合わせで構成される
• 常時全信号を集めるとデータ量と通信が増えるため、条件付きキャンペーンで必要なデータに絞ることがコスト最適化の要になる
• 収集先の S3 や Timestream など、連携する他サービス側のストレージ・処理コストも別途かかる
• 料金は変動するため、最新の単価は公式の料金ページで確認する

セキュリティ

• アクセス制御は IAM で行い、最小権限の原則に従って信号カタログ・車両・キャンペーンへの操作権限を付与する
• 車両とクラウド間の通信は TLS で保護され、保存データは KMS で暗号化される
• 車両の登録や認証は IoT の仕組みと整合させ、不正なデバイスからの収集を防ぐ
• 操作の監査には CloudTrail を利用し、誰がいつ何を操作したかを記録する
• 走行データは位置情報など機微なデータを含みうるため、収集範囲とアクセス権限を慎重に設計する

関連サービス・比較

ハンズオン / CLI例

# 信号カタログを作成（標準信号の語彙を定義）
aws iotfleetwise create-signal-catalog \
  --name "GlobalCatalog" \
  --nodes file://nodes.json

# 車両モデル（モデルマニフェスト）を作成
aws iotfleetwise create-model-manifest \
  --name "SedanModel" \
  --signal-catalog-arn <signal-catalog-arn> \
  --nodes '["Vehicle.Powertrain.EngineSpeed"]'

# 収集計画（キャンペーン）を作成
aws iotfleetwise create-campaign \
  --name "EngineSpeedCampaign" \
  --signal-catalog-arn <signal-catalog-arn> \
  --target-arn <vehicle-or-fleet-arn> \
  --collection-scheme file://collection-scheme.json