MONOistの記事を参照しつつ、WP29を理解し、そこで決まったUN規則の内、まずはサイバーセキュリティについて概観をさくっと見てきたのが前回まで。
今回はソフトウェアアップデートについて記事の後半を参照しつつ読み砕いていきます。
3. ソフトウェアアップデートと「組織」
サイバーセキュリティとは違い、ソフトウェアアップデートについては、各車両ごとに、設計時や生産時、出荷時の状態、そして今現在の状態を「組織」として管理する必要があることは、アプリオリに理解できますね。
EyeSightのような運転支援システムも、車のマイナーチェンジやフルモデルチェンジの際にソフトウェアが変わってるでしょうし、付随してハードウェアも変わることもあるでしょうね。それは今現在でも管理されているはずです。自動運転やMaaSといった新しいサービスを提供するために必要となる多くのアプリケーションが、今後の車には搭載されていくのでしょうが、スマホのアプリのように、今どのバージョンを使用しているのか、車一台一台を調べずとも、集中的に情報管理し、ユーザーへ適切なフィードバックをすべきですね。
このような管理を実現する ソフトウェアアップデート管理システム(Software Update Management System、SUMS) なるものが必要とのことです。サイバーセキュリティ管理システム(Cyber Security Management System、CSMS)がプロセスに重きを置いていたのに対し、こちらはITを用いた管理システムの方がイメージしやすいかなと個人的には考えます。コロナ禍においてスマホの位置情報が頻繁に利用されていますが、究極的には各自動車がどこを走っており、その一台一台の部品構成表が管理され、それを見れば各ソフトウェアのバージョンも一目瞭然となり、例えば自動運転中に事故が起きた際にはその時のソフトウェアバージョンも重要な情報として提出する必要がある、みたいな未来が容易に想像できますね。アップデートを適切に実施ているユーザは自動車保険料が安くなるなど、このデータを活用した派生も様々考えられます。
調べてみると、既に以下のような保険商品も出ているようです。
自動運転の割合が増えてくれば、運転者と車両の関係で保険が決まるというより、車両そのものに保険が付帯してくる、つまりは自動車メーカーが保険商品も提供する方がしっくりくるような気もしますね。
CSMS同様に詳細な要件は別途考えていきます。
4. ソフトウェアアップデートと「車両」
「車両」の要件は、目の前にあるその車のソフトウェアを適切にアップデートできること、というイメージで良いと思います。ソフトウェアと車とのインタフェース要件、という感じで個人的には理解しています。OTA*1でのアップデート中に途中で処理が止まってしまうような場合にどのように復旧するのか。PCのように電源を切ってみる、みたいな操作で良いのか、その際には運転中でも良いのか、道路脇に止めて行う必要があるのかなど、よりユーザ目線での要件がイメージできますね。自動運転に関わるようなソフトウェアなら、運転中にはアップデートできないような仕組みも必須ですね。
以上で今回取り上げたMONOistの記事は読み砕くことができました。大枠を捉えたところで、次回からは各細目はもちろん、筆者によって記載感が違う部分もあるので、他の記事やサイトにも目を向け、より多角的にUN規則を考えていきます。
最後に、今回のMONOist記事の終わり部分を引用しておきます。「セーフティ」と「セキュリティ」の違いという意味で、簡潔にまとめられていると思います。
自動車の「セーフティ」は、点検整備や車検によって維持することができた。しかし、セキュリティはサイバー攻撃が常に進化することを踏まえて、自動車メーカーが販売後も必要な対策を継続的に講じる必要がある。そのためには、販売後の車両のセキュリティ状態を監視したり、新たな脅威の特定に必要な情報を収集したりしなければならない。自動車ユーザーも、安全に使い続けるために、自動車メーカーが提供するセキュリティパッチなどを確実に車両にインストールする責任が生まれる。
