Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

現代の車からはさまざまなデータが取得できます 取得可能なデータの例 速度情報: 車速、エンジン回転数 環境情報: 外気温、燃料残量 状態情報: ドア開閉、ライト点灯 位置情報: GPS 座標 車両データ 2

Slide 3

Slide 3 text

データの豊富さ エンジン情報 車両状態 走行データ 環境データ 診断情報 高い価値 安全性向上 予知保全 新サービス創出 利用状況分析・改善 扱いの難しさ メーカー・車種・年式ごとの違い 複雑な信号形式 車両データの特徴 3

Slide 4

Slide 4 text

通信プロトコルの例 CAN LIN FlexRay Ethernet CANの特徴 業界の標準:デファクトスタンダード 高い信頼性:ノイズに強く、エラー検出・再送機能も持つ 確実なリアルタイム性:優先度に基づき通信を制御 車両データ(信号)はどのように通信されるか 4

Slide 5

Slide 5 text

CAN バイナリデータを信号名と値に変換 BU_: ECU1 ECU2 BO_ 100 ExampleMessage: 8 ECU1 SG_ ExampleSignal : 0|8@1+ (1,0) [0|255] "" ECU2 CAN DBC ファイルによるデコード 5

Slide 6

Slide 6 text

同じ車速データでも信号名がバラバラ メーカー 1: WHEEL_SPEED_FL メーカー 2: XMISSION_SPEED メーカー 3: Veh_V_ActlBrk メーカー 4: SPEED_KMH 課題 6

Slide 7

Slide 7 text

アプリケーション開発が車種に縛られる 同じ機能でも車種ごとに個別開発 移植性・拡張性がない 開発コストが大幅に増加 スケールしないエコシステム 統一されたサービス開発が困難 イノベーションの阻害要因 信号名がバラバラなことによる影響 7

Slide 8

Slide 8 text

VSS 8

Slide 9

Slide 9 text

VehSpd → Vehicle.Speed 誰もが理解できる標準名への対応付け 真の相互運用性を実現 VSS が解決する「意味の標準化」 9

Slide 10

Slide 10 text

https://covesa.github.io/vehicle_signal_specification/introduction/index.html ツリー構造でさまざまな車両データを表現 10

Slide 11

Slide 11 text

VSS カタログ 事前定義済み信号の集合 Vehicle.Speed, Vehicle.Engine.RPM 等 データ型、単位、説明が標準定義 GitHub 上でオープンソースとして公開 ルールセット データ定義のルール 階層構造の記述方法を定義 データ型など文法 拡張・カスタマイズの仕組み VSS の構成要素 11

Slide 12

Slide 12 text

VSS を支える関連技術 12

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

Core 仕様 Get: データの取得 Set: データの設定 Subscribe: 収集条件に基づく継続的 な車両データの取得 認証・認可: セキュアなアクセス制御 Payload Encoding JSON スキーマ: OpenAPI などで活用 可能なスキーマ定義 Protobuf: Protobuf でのエンコー ド/デコード Transport WebSocket HTTP/REST MQTT gRPC API 仕様: VISS 14

Slide 15

Slide 15 text

AWS IoT FleetWise VSS をサポートする AWS サービス 15

Slide 16

Slide 16 text

VSS ファイルを元に車両モデルを定義可能 信号と車両モデルをマッピングするデコーダーマニフェストにより車輌信号を抽象化して扱う クラウド側で定義した条件に基づいた車両データを収集 https://aws.amazon.com/jp/iot-fleetwise/ AWS IoT FleetWise 16

Slide 17

Slide 17 text

制約 2025 年 9 月現在、東京リージョンでは利用不可 課題 17

Slide 18

Slide 18 text

制約 2025 年 9 月現在、東京リージョンでは利用不可 解決策 FleetWise の優れた機能を参考に AWS IoT Core を中心とした構成を考えてみる 課題 18

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

COVESA VSS による車両データモデルの標準化と AWS IoT FleetWise のアーキテクチャとしての活用 20

Slide 21

Slide 21 text

アーキテクチャ 21

Slide 22

Slide 22 text

車両ごとの VSS ベースの車両モデルの管理 DBC などと車両モデルとのマッピング情報の管理 データ収集条件の管理 IoT Core 経由で各車両に送信 1. 信号のマッピングと収集条件の管理 22

Slide 23

Slide 23 text

1. 受信: クラウドからの定義情報 2. マッピング: CAN などの信号 → VSS データモデル 3. フィルタリング: 収集条件に合致したデータのみ 4. 送信: AWS IoT Core へデータ送信 2. 車両側エージェントの処理 23

Slide 24

Slide 24 text

Firehose → S3 や S3 Tables で蓄積し、Athena で分析 バッチ分析処理などでも活用可能 必要に応じて、時系列 DB などのストアやストリーム分析などコンポーネントを追加 3. 車両データの蓄積 24

Slide 25

Slide 25 text

車両サービスを介したリモートコマンドや車両データの取得 車両の状態変更イベントなどの配信 その他 25

Slide 26

Slide 26 text

再掲 26

Slide 27

Slide 27 text

まとめ

Slide 28

Slide 28 text

課題解決 VSSの『ルールセットと標準カタログ』で意味の統一・相互運用性を実現 実現手段 AWS IoT FleetWise を参考に、IoT Core を中心とした柔軟な代替アーキテクチャ 車両モデルとデータ収集条件を管理。車両側でデータモデルに各信号をマッピングし、収集条件を 元にデータを収集 未来 VSS などによる車両データの標準化でデータ活用の可能性が拡大 まとめ 28