SUMSの運用は容易ではないことに気付かされる -RXSWINとは-

はじめに

サイバーセキュリティに関してWP29で検討されているWP29 CS Regulations(UN-R155)を見てきたのと同様に、今回はソフトウェアアップデートについてWP29 SU Regulations(UN-R156)の中身を見ていきたいと思います。前回最後に触れた通り、今回もMONOist記事を参照しながら勧めます。

大きくは7.1節 SU Management System(SUMS)への要件、7.2節 SU機能を含む車両型式の要件となるようです。

7.1節 SU Management System(SUMS)への要件

まずは7.1節から見ていきましょう。

f:id:rugbyfp91:20210103172610j:plain

MONOist同記事より

中身に入る前にまた1つ難しそうな用語が出てきます。RXSWIN(Regulation x に対する Software Identification Number)というものです。型式認証を受けた車載システムにインストールされたソフトウェアのバージョン情報を集約し管理する概念として考案された、とのことです。なんだかなあ、という感じもしますが、pwcさんのHPに具体例が書かれていましたので、そちらを見ながら解釈してみます。

f:id:rugbyfp91:20210103180618j:plain

https://www.pwc.com/jp/ja/knowledge/column/awareness-cyber-security/wp2903.html

この例では、とあるRegulation No.Xに該当する車載用ECU(Electronic Control Unit)、例えばUN規則におけるUN 89(速度制限装置)の認可取得が必要となる車間距離制御システムを想像しましょう。(あくまで考え方の事例であり、申し訳ありませんが、実際にUN 89が該当するかどうかは確証がありません。参考までに。)*1

そんな車間距離制御システムが2つのECUからなっていたとし、各ECUが2つのマイコン(MCU)を含んでいるものとします。あくまで車間距離制御システムとしてUN 89の認可取得をしているため、1つのマイコンにソフトウェアアップデートの必要が出た場合でも、改めてシステム全体として認可取得を行う必要がある、そのために前回のバージョンの識別子とアップデート後の最新版の識別子が必要となり、それをSWIN(Software Identification Number)として採番し管理できるようにする、と理解しました。(図ではECU2のマイコン2のバージョンがアップデートされたことによりSWINを新規採番しています。)

そしてこのRXSWINを利用しソフトウェアアップデート前後のバージョンを管理することで、車両一台一台について、実際に搭載されているソフトウェアのバージョンが何なのか確認できることとなり、7.1.1.2節から7.1.1.4節の要件を満たすことができます。

※RXSWINについては下記に詳細を記載してます。

7.1.1.5節から7.1.1.7節では、更新対象のシステムと他のシステムの依存関係や、更新対象車両の特定、更新前後の互換性を確認するプロセスが求められています。

7.1.1.8節と7.1.1.10節は、ソフトウェアアップデートによって変化する機能や性能、パラメータの有無を確認し、車両型式や安全への影響を評価するプロセスが求められています。7.1.1.11節は、車両のユーザーがソフトウェアアップデートについて通知を受けるプロセスが求められています。

概観としては以上で充分だと思いますが、詳細を参考までに記載しておきます。

  • 7.1.1節 認証機関/技術サービスによって検証されるプロセス

    7.1.1.1節 この規則に関連する情報が文書化され、OEMによって安全に管理され、認証機関もしくは技術サービスからの要求によって利用できるプロセス。
    7.1.1.2節 完全性検証データと型式認証済みシステムのHWコンポーネントを含む初期および更新SWのバージョンに関する情報を一意に識別できるプロセス。
    7.1.1.3節 RXSWINに関する情報の参照や更新を行えるようにするプロセス。各RXSWINに関連する全てのSW、SWバージョン、その完全性検証データに関する情報を更新する機能が含まれる。
    7.1.1.4節 システムに搭載されているSWバージョンと、RXSWINとして登録されている情報が一致していることを確認できるプロセス。
    7.1.1.5節 更新されるシステムと他のシステムとの依存関係を識別できるプロセス。
    7.1.1.6節 OEMが、SUの対象となる車両を特定できるプロセス。
    7.1.1.7節 対象車両の更新前後のHW/SW構成の互換性を検証するプロセス。
    7.1.1.8節 認証済みシステムに対して、影響を与えるかを評価し、識別し、記録するプロセス。これはSUにより、影響を与える可能性のあるシステムの特定や、法規に関連するパラメータの変更を伴うかなどに配慮する。
    7.1.1.9節 SUによって追加、変更、有効化される機能、または法令で規定されているパラメータもしくは機能の変更、無効化を評価、識別、記録するプロセス。評価は、次の事項を考慮すること。(a)関連する情報の更新(b)テスト結果が更新後の車両をカバーしなくなるのか(c)車両の機能変更は、車両型式認証に影響を及ぼすのか
    7.1.1.10節 SUが車両の安全性に関わる他のシステムに影響を及ぼすか、または車両への機能追加や変更があるかなどを評価し、識別し、記録するプロセス。
    7.1.1.11節 車両ユーザーがSUについて通知を受けることができるプロセス。
    7.1.1.12節 認証機関もしくは技術サービスが、7.1.2.3節および7.1.2.4節に記される情報を利用できるようにするプロセス。

7.1節の残り部分の詳細はアプリオリかつ若干煩雑な内容でもあるので、MONOist記事を参照いただくとして、概観のみ触れることとします。

7.1.2節はソフトウェアアップデートに関する情報の記録を求めています。7.1.2.1節から7.1.2.4節は、7.1.1節のプロセス活動を通じて生成される情報を文書化するよう求めています。主にソフトウェアアップデートプロセスの説明、型式認証を受けるシステム構成の説明、ソフトウェアアップデート前後のRXSWINに関連するドキュメント、ソフトウェアアップデートバージョンと完全性検証データ、車両の構成情報や互換性検証の結果です。7.1.2.5節では、車両型式の認可取得のためにソフトウェアアップデートに関わる文書に求められる要件が述べられています。特に(h)において、ソフトウェアアップデートがセキュアに行われていることを確認できる文書が求められています。

7.1.3節では、ソフトウェアアップデートへの不正操作の防止、ソフトウェアアップデートプロセスの危殆化阻止、更新ソフトウェアの機能と有効性の検証といった、ソフトウェアアップデートを実行するにあたってのセキュリティ対策を求めています。

7.1.4節では、運転中にOTAによるソフトウェアアップデートを実行する場合の安全性と、OTAによるソフトウェアアップデートが完了するまで担当の整備士が携わっていることが確認できるようなプロセスについての説明を求めています。

7.2節 SU機能を含む車両型式の要件

次に7.2節を簡単に見ていきましょう。こちらもアプリオリに理解できる部分が多いため、各節の詳細はMONOist記事を参照いただくとして進めます。

7.2.1節を見ます。7.2.1.1節は、ソフトウェアアップデートの信頼性と完全性を担保することを求めています。7.2.1.2節は、型式認証にRXSWINを用いることとし、車両からRXSWINもしくはソフトウェアバージョンを読み出すことで、車両の状態を確実に把握できることを求めています。当然の内容ですよね。

7.2.2節はOTAのための追加要件が述べられています。7.2.2.1節は、ソフトウェアアップデートのために車両に求められる要件とし、ソフトウェアアップデートを完了するのに十分なパワーを有している場合にのみ実行され、もしソフトウェアアップデートが失敗もしくは中断しても、以前の状態に復元できるか、車両を安全な状態にできることを求めています。また、ソフトウェアアップデートを安全に実行できることの説明と、車両ユーザーによって検証できるプロセスを求めています。このあたりもそりゃそうだよね、といった感ですね。もちろん大変重要な部分ではありますが。

さらに要件が追加されたようで、7.2.2.2節では車両ユーザーへの通知項目、7.2.2.3節では運転中の更新が安全でない場合の対処とし、更新中は運転できなくするか、影響を受ける車両機能を使用できなくすること、そして7.2.2.4節では更新後に車両ユーザーへ更新の成否や変更点について通知することを求めています。ええ、勝手に更新されては困りますからね、通知はしてくれないとですよね。

BOMでソフトウェアアップデートも管理する!?

かなりアプリオリな概念が多かったMONOist記事内でのWP29 SU Regulationsですが、ここでは触れられていない重要な点として、CSMSで考慮されていたフェーズ・工程の概念を上げる必要があります。pwcさんはそこに気付いているようで以下のような図で示しています。

f:id:rugbyfp91:20210103223019j:plain

https://www.pwc.com/jp/ja/knowledge/column/awareness-cyber-security/wp2903.html

前回の記事でたまたま東大の藤本隆宏先生のセミナーに触れましたが、藤本先生の本で学んできた者としては、BOMが常に頭の片隅にありますので、設計・生産・販売といった製品ライフサイクル全体で設計変更同様にソフトウェアアップデートを考えなければいけない、と記事を書きながら考えていました。

特に量産に入った後の管理の仕方は考えものですね。図では製造部門で1台ごとに構成管理とありますが、そこまでデータを持ってしまうとデータボリュームが膨大になってしまうデメリットが発生します。実際にラインオフした実車にインストールされているソフトウェアのバージョンが識別できるよう、ソフトウェアの管理も含めた製造BOMとの確実な紐付けが必要となりますね。

また、視点をソフトウェア開発自体に移しますが、一言にソフトウェアアップデートと言っても仕様変更のような大きな更新もあれば、処理が少しだけ早くなるような小さな更新もあります。それら種々の更新を製造BOMへ反映させるタイミングをどう判断するのか、この基準策定も難しいなあと感じます。部品のリコール同様に重大なソフトウェアの異常がある場合は別として、ユーザがほんの少し快適に使用できる程度の更新をどのような方針の下で適用させていくのか、一歩間違えるとユーザのロイヤルティも失いかねない機微な領域ですね。スマホのアプリのように気付かないうちに毎日のようにアップデートがかかるのもどうかと思いますし、新モデルに搭載されているソフトウェアが旧モデルのハードウェアでも使用できるものであるならば、既存ユーザはもちろんアップデートを求めます。でも実は奥深い所で旧モデルの別システムとの相性が悪く、適用することはできない、みたいなことが起きると思いますし、それを現場では説明しなければならないでしょう。そしてネット上では、ユーザから厳しく追求されることでしょうね。。。

情報を隠すことは最も忌み嫌われることだとは思いますが、どのように開示していくか、またユーザもどのように受け止めるのが適切なのか、車という生命を預けるものであるが故に、自動車業界だけでなくユーザも巻き込んで広く議論されることが必要と考えます。

*1:UN規則の体型はJASICのHPを参照 https://www.jasic.org/j/08_publication/hh/un.htm