AWS
awsIoT

AWS Connected Vehicle Solution Implementation Guideのイケてないところを指摘する

More than 1 year has passed since last update.


自己紹介

5年ほどAWSを使ってメディア系サービスの開発に携わった後、ConnectedService関連の開発を1年ほどしています。

昨年AWSがAWS Connected Vehicle Solution を発表して自動車業界への興味関心をアピールしたが、読みつつ個人的にイケてないと思った部分をここに記します。


おことわり


指摘1:可用性、拡張性より移植性がほしい

本ガイドの前半、概要部分にはざっくりと以下のようなことが書かれている。


  • このアーキテクチャを活用するとサーバレスでコネクテッドサービス基盤を作成できる

  • AWS-IoTを使って車と接続することでセキュアでローレイテンシーでオーバーヘッドが少なくなる

  • イベントドリブンなアプリケーションを構築できる(ヘルスチェックやメンテナンス、レコメンド)

  • 安全に車両接続ができ、車両内でのローカルコンピューティングができ、データを安全に保管でき、様々なイベント処理ができる

  • このソリューションはフレームワークを提供するもので、やりたいサービスによって拡張できる。例えば音声対話、ナビ、遠隔車両診断、ヘルスチェック、予測分析、メディアストリーミング、セキュリティサービス、ヘッドユニットアプリケーション、モバイルアプリケーションなどの拡張性を備える

  • コストに関しては、扱うデータサイズによって変わる

全体としてAWSの特長を活かした可用性、拡張性に優れたアーキテクチャであることを主張している。

しかし、コネクテッドサービスを実際につくる側の立場にたつと、会社には既にコネクテッドサービス基盤(やそれに近しいWebシステム)が存在しており、移植性や疎結合性について言及していないのは開発者のことを本気で考えていないように感じてしまう。


指摘2:車を既存のThingと同一視している

サンプルとして提供されているCloudFormationTempleteに対しては以下のように説明している。


  • デフォルトのCloudFormationTempleteに従って環境を構築すると、6つのビジネルルールに従ってデータを処理する


    • anomaly detection : Kinesis Firehose でリアルタイムにデータを処理し、Kinesis Analyticsで機械学習で異常を検知し、KinesisStreamでDynamoに異常レコードを保存すると同時にSNS通知のトリガーも行う

    • trip data : トリップデータをトリップが終わるまでDynamoに送り続ける

    • driver safety score : トリップの終了を検知して、運転後にトリップデータから安全度のスコアを算出する

    • diagnostic trouble codes : トラブルコードを検知してSNSで通知

    • location based marketing : 車両の位置を監視して、特定のポイントに近づいたら広告をSNS経由で出す

    • Just in time registration : 車両の証明書の自動登録



  • サードパーティのアプリケーションはCognito、APIGatewayを用いてDynamoにアクセスできる

車両(モノ)単位でデータを扱っているが、車の挙動やそれに伴って出現するデータは運転者に依存するところが大きいことを考慮してほしい。ある人にとっては急ブレーキでもある人にとってはそうでなく、そこに正解/不正解もないのが車だと思う。なので、本アーキテクチャでは(3rd-partyサービス以外は)データを車両単位で考えているが、私は基本的に人単位で考えるべきだと思う。

少なくともそういう拡張性があることを説明してほしい。


指摘3:資料の公開範囲が広すぎる

この資料の最後には以下のように記載されている


  • この文書は情報提供のみを目的として提供されています。これは、このドキュメントの発行日現在のAWSの現在の製品提供および実践を表しており、予告なしに変更されることがあります。お客様は、本書の情報およびAWSの製品またはサービスの使用に関する独自の評価を行う責任を負います。これらの製品またはサービスは、明示または黙示を問わず、いかなる保証もなく現状のまま提供されます。

技術者的に情報提供はありがたいのだが、問題は非技術者にもこれが展開されてしまい、技術者は非技術者(往々にして上司)に対する本資料の説明に追われたことである。(自分だけですかね)

もし本当に情報提供が目的だったのであれば、誰にでも伝わりやすいニュースリリースでなく、Blackbeltのような技術者向けの配信形態をとってほしかった。


まとめ


  • 既存のコネクテッドサービスと共存ないしは移植できるのか。

  • 車は人が乗るものだから人単位で管理したい

  • 技術提供は技術者にしてほしい