COVESA VSSによる車両データモデルの標準化とAWS IoT FleetWiseの活用

Transcript

2. 現代の車からはさまざまなデータが取得できます 取得可能なデータの例 速度情報: 車速、エンジン回転数 環境情報: 外気温、燃料残量 状態情報: ドア開閉、ライト点灯 位置情報: GPS 座標 車両データ 2
3. データの豊富さ エンジン情報 車両状態 走行データ 環境データ 診断情報 高い価値 安全性向上 予知保全 新サービス創出 利用状況分析・改善 扱いの難しさ メーカー・車種・年式ごとの違い 複雑な信号形式 車両データの特徴 3
4. 通信プロトコルの例 CAN LIN FlexRay Ethernet CANの特徴 業界の標準：デファクトスタンダード 高い信頼性：ノイズに強く、エラー検出・再送機能も持つ 確実なリアルタイム性：優先度に基づき通信を制御 車両データ(信号)はどのように通信されるか 4
5. CAN バイナリデータを信号名と値に変換 BU_: ECU1 ECU2 BO_ 100 ExampleMessage: 8 ECU1 SG_ ExampleSignal : 0|8@1+ (1,0) [0|255] "" ECU2 CAN DBC ファイルによるデコード 5
6. 同じ車速データでも信号名がバラバラ メーカー 1: WHEEL_SPEED_FL メーカー 2: XMISSION_SPEED メーカー 3: Veh_V_ActlBrk メーカー 4: SPEED_KMH 課題 6
7. アプリケーション開発が車種に縛られる 同じ機能でも車種ごとに個別開発 移植性・拡張性がない 開発コストが大幅に増加 スケールしないエコシステム 統一されたサービス開発が困難 イノベーションの阻害要因 信号名がバラバラなことによる影響 7
8. VSS 8
9. VehSpd → Vehicle.Speed 誰もが理解できる標準名への対応付け 真の相互運用性を実現 VSS が解決する「意味の標準化」 9
10. https://covesa.github.io/vehicle_signal_specification/introduction/index.html ツリー構造でさまざまな車両データを表現 10
11. VSS カタログ 事前定義済み信号の集合 Vehicle.Speed, Vehicle.Engine.RPM 等 データ型、単位、説明が標準定義 GitHub 上でオープンソースとして公開 ルールセット データ定義のルール 階層構造の記述方法を定義 データ型など文法 拡張・カスタマイズの仕組み VSS の構成要素 11
12. VSS を支える関連技術 12
13. YAML と Protobuf での相互変換などさまざまなフォーマット同士の変換 複数の VSS ファイルの合成(オーバーレイ) vspec export json --vspec spec/VehicleSignalSpecification.vspec --output vss.json [16:40:03] INFO Added 29 quantities from __init__.py:895 /Users/Foo/workspace/vehicle_signal_specification/spec/quantities. yaml INFO Added 62 units from __init__.py:923 /Users/Bar/workspace/vehicle_signal_specification/spec/units.yaml INFO Loading vspec from spec/VehicleSignalSpecification.vspec... utils.py:81 [16:40:04] INFO Check type usage __init__.py:117 INFO Generating JSON output... json.py:142 INFO Serializing compact JSON... json.py:148 https://github.com/COVESA/vss-tools/blob/master/docs/vspec.md 開発ツール: VSS Tools 13
14. Core 仕様 Get: データの取得 Set: データの設定 Subscribe: 収集条件に基づく継続的 な車両データの取得 認証・認可: セキュアなアクセス制御 Payload Encoding JSON スキーマ: OpenAPI などで活用 可能なスキーマ定義 Protobuf: Protobuf でのエンコー ド/デコード Transport WebSocket HTTP/REST MQTT gRPC API 仕様: VISS 14
15. AWS IoT FleetWise VSS をサポートする AWS サービス 15
16. VSS ファイルを元に車両モデルを定義可能 信号と車両モデルをマッピングするデコーダーマニフェストにより車輌信号を抽象化して扱う クラウド側で定義した条件に基づいた車両データを収集 https://aws.amazon.com/jp/iot-fleetwise/ AWS IoT FleetWise 16
17. 制約 2025 年 9 月現在、東京リージョンでは利用不可 課題 17
18. 制約 2025 年 9 月現在、東京リージョンでは利用不可 解決策 FleetWise の優れた機能を参考に AWS IoT Core を中心とした構成を考えてみる 課題 18
19. COVESA VSS による車両データモデルの標準化と AWS IoT FleetWise の活用 19
20. COVESA VSS による車両データモデルの標準化と AWS IoT FleetWise のアーキテクチャとしての活用 20
21. アーキテクチャ 21
22. 車両ごとの VSS ベースの車両モデルの管理 DBC などと車両モデルとのマッピング情報の管理 データ収集条件の管理 IoT Core 経由で各車両に送信 1. 信号のマッピングと収集条件の管理 22
23. 1. 受信: クラウドからの定義情報 2. マッピング: CAN などの信号 → VSS データモデル 3. フィルタリング: 収集条件に合致したデータのみ 4. 送信: AWS IoT Core へデータ送信 2. 車両側エージェントの処理 23
24. Firehose → S3 や S3 Tables で蓄積し、Athena で分析 バッチ分析処理などでも活用可能 必要に応じて、時系列 DB などのストアやストリーム分析などコンポーネントを追加 3. 車両データの蓄積 24
25. 車両サービスを介したリモートコマンドや車両データの取得 車両の状態変更イベントなどの配信 その他 25
26. 再掲 26
27. まとめ
28. 課題解決 VSSの『ルールセットと標準カタログ』で意味の統一・相互運用性を実現 実現手段 AWS IoT FleetWise を参考に、IoT Core を中心とした柔軟な代替アーキテクチャ 車両モデルとデータ収集条件を管理。車両側でデータモデルに各信号をマッピングし、収集条件を 元にデータを収集 未来 VSS などによる車両データの標準化でデータ活用の可能性が拡大 まとめ 28