もがきながらもRXSWINの真髄に迫る

RXSWINの情報が無い・・・

今日現在、当ブログのアクセス先を見てみますと、下記が最も多く40%程度を占めています。

勝手な推測にはなりますが、おそらくRXSWINに関して検索された方が訪れて下さっているのかな、と考えます。それくらい、RXSWINについては情報が少ないようですね。わたしも上記を書いた際に初めてRXSWINなるものを知ったわけですが、今回改めて幾つか英語資料も見つかりましたので、RXSWINを深堀りしてみたいと思います。出処が確かな情報かと言うとそこまで自信は無いのですが、RXSWINなどというマニアックなものをいい加減に記載する物好きも居ないのではという仮定のもと、これからの話を始めます。尚、ネットで「Report of Japanese Test Phase <Software Update>」を検索してもらえれば同様の資料に行き当たることができると思います。

改めてRXSWINとは

上記記事で参考にしたpwc社さんのサイトを改めて見ましょう。

安全なソフトウェアアップデートの要件と共に、構成管理を行う上でRXSWINと呼ばれる識別子を使うことも、本法規基準の要件におけるポイントとなります。

RXSWIN(Rx Software Identification Number)とは、自動車の構造および装置に関する規則(UN規則)におけるRegulation No.ごとに関連するシステムのソフトウェアバージョンを管理するための識別子です。

WP29 SU Regulations(UN-R156)で求められる、車両に搭載されるECUのソフトウェアを安全にアップデートするため、またUN規則毎の構成管理を可能とするため、このRXSWINを使用しましょう、ということですね。先の記事において、pwc社さんのコンテンツを読み砕いて具体的な事例を示しておきましたので、イメージがつかない場合はそちらもご参照ください。部品構成表BOMの要領と同じです。

今回はイメージというよりは、RXSWINの定義をしっかり理解していきたいと思います。上記で触れた英語資料を参考にしますが、

  • RXSWINは、最大50文字のアルファベット/数字で構成されます。(各メーカーは独自の番号付けルールを定義できます。)

  • RXSWINは、電子インターフェースまたは標準インターフェース(OBDポート)を介して読み取ることができる必要があります。

  • コンポーネントで使われているソフトウェアバージョンと、それらとRXSWINとの関連付けが記録されている必要があります。
  • RXSWINとの関連付け情報を当局に提出する必要があります。
  • RXSWINは、車両登録後も管理する必要があります。

一部省略しましたが、上記のような定義が記載されていました。最大50文字で各社毎に採番ルールを定義できるんですね。たしかにBOMは各社の最重要機密情報の一つでしょうから、それに関連してくるRXSWINの定義の仕方を共通化することは現実的ではないのでしょう。

いまさらですがOBDって・・・

定義の2番目ではOBDポートを介しての読み取りについて触れられていますが、このOBDポートなるものを改めて見ていきましょう。このようなブログに辿り着く方はほとんどがご存知なのかもしれませんが、わたしのように車いじりがほとんどできない者もおりますので、ご容赦願います。

今ではOBD2(On Board Diagnosis second generation)にバージョンアップされており、車の異常を車自身が感知する自己診断機能として、2010年9月以降から販売されている輸入車を含む全ての新車に取り付けが義務付けられているとのことです。OBD2には異常データだけではなく、車体に付いているセンサー類から様々な情報が集められます。車速やGPS、燃費といったデータも。これらを読み取るための接続先がOBDポート、OBD2コネクタなどと呼ばれており、実際には下図のようなものが運転席のハンドル下やアクセルペダル付近などにあるとのこと。わたしも愛車で確認してみようと思います。

f:id:rugbyfp91:20210310144823j:plain

https://carcareplus.jp/article/2018/01/01/3372.html

自身ではもちろん行ったことはありませんが、おそらく点検等でディーラーへ持っていった際には下図のようにOBD2コネクタに接続して、異常がないかどうか見てくれているのでしょうね。

f:id:rugbyfp91:20210310145040j:plain

https://carcareplus.jp/article/2018/01/01/3372.html

UN規則とECUソフトウェアとの関連付け

RXSWINの核心となる、定義の3番目以降に話を移します。今回参考にしている英語資料を読み進めた結果ですが、RXSWINはUN規則が大きな採番単位となるわけですが、ECUソフトウェアとの関連を考えるとわたしの理解は下図のようになりました。

※ここでSysIDなるものが出てきますが、参考資料内では、これは設計サイドの管理番号との位置付けとなっていました。あくまでRXSWINは当局とやり取りをする認証部門内で採番されるものであり、設計時には別のIDで管理されている、という前提があるようです。確かにそれはそうだろうなあ、と個人的には納得しておりますが、ご注意を。

f:id:rugbyfp91:20210310162014j:plain

例えば車両XXX-YYYなるものがあり、UN13-H(M1区分*1のブレーキ)に該当するECUソフトウェアとして、ABS(Anti-lock Braking System: アンチロック・ブレーキ・システム)とEPS(Electric Power Steering: 電動パワーステアリング)が搭載されており、それぞれのソフトウェアのバージョンが管理されています。この関連を設計サイドでSysID「BR-Sys02」と採番していたとして、RXSWINとしては「XXX-YYY-UN13H-Sys02」と採番してみました、という例です。UN39の場合はABSが、UN79の場合はEPSがそれぞれ関係することとなり、対応するRXSWINを採番します。

既に自明のことではありますが、この図からわかることはABSのソフトウェアにアップデートがあった場合はUN13-HとUN39に影響があるため、2つのRXSWINを改めて採番し、当局とやり取りする必要が生じる、ということですね。UN79には影響が無いことから「XXX-YYY-UN79-Sys01」については改めて採番する必要は無い、ということになります。

あるECUに設計変更が生じた際には、最終的には対応するRXSWINを改めて採番し当局へ通知することが必要となってきます。このプロセスを円滑に行うためにも、

  • 各車両の各モデルに搭載されている各ECUソフトウェアのバージョン
  • UN規則
  • RXSWIN(また、採番元となるSysID)

これら3つについて上図のような関連付けが正しく記録され、管理されている必要があることがわかります。

設計変更プロセスが変わる!?

さらに付け加えるならば、関連付けをデータベースで蓄積・管理するだけでは不十分であることがわかります。設計変更の起案からRXSWIN採番・通知までの一連のプロセスが適切に行われるためには、ワークフローのような仕組みも必要となってきます。

設計変更のIDをキーとし、対象となるECUソフトウェアとそのバージョン、影響を受けるUN規則を採番済みのRXSWINとともに明らかにし、当局とやり取りする認証部門へ情報連携する、といった感じの業務になるでしょうか。E-BOMの変更内容がM-BOMへ反映されるまでがこれまでの設計変更プロセスであったわけですが、RXSWINの採番そして当局への通知までがスコープに追加されるため、設計変更自体の管理も複雑さが増すことは自明です。

いやはや、各自動車会社はどのように対応するのでしょうか。RXSWINを採番できるようBOMを改修するのか、BOMには手を付けず外付けで管理システムを構築するのか、いずれにせよ大変なシステムを開発する必要がありそうですね~。各社各様の世界でもあるので、容易に外付けできるようなパッケージシステムも期待できないですね。わたしも自分のお客様へどのような提案をすべきか、じっくりと考えたいと思います。。。

*1:わたしは全く知りませんでしたが、日本で言う乗用車のことを欧州ではM1という区分で呼ぶようで、UN13-HではM1車両に搭載されているブレーキが対象となります

そしてTARAとASILに触れるときが来る

前回はISO/SAE 21434をおさらい

テュフ社の連載記事を読み進めているところですが、前回はISO/SAE 21434を改めておさらいしてみました。

章立てから各章の概要、UN-R155(CSMS要求)との関連を見てきました。

コンセプトフェーズの進め方

当記事にはいまいち内容に一貫性がないと前回書きましたが、コンテンツとしては活用できると思いますので、勉強してみたいと思います。まずはコンセプトフェーズの深堀りから。

繰り返しになりますが、コンセプトフェーズでは、コンセプトレベルでのリスクアセスメント(脅威分析)を行い、対応すべきリスクを洗い出し、以降の活動の起点となるサイバーセキュリティの目標(サイバーセキュリティゴール)を定義します。

サイバーセキュリティ目標を決めるために、以下2つの成果物が必要となるとのことです。

これらの作成ステップが掲載されていますので、まずは見てみましょう。

f:id:rugbyfp91:20210307111231p:plain

https://insights.tuv.com/jpblog/iso21434

ステップ1から5で脅威分析を、ステップ6でリスクアセスメントを行い、ステップ7で脅威に対するリスク低減策を決定し、サイバーセキュリティ目標を設定する、という流れのようです。この一連のステップを各アセットごとに繰り返し、評価、対策を決定していきます。

尚、この7ステップのことをTARA(Threat Analysis and Risk Assessment)と呼び、ISO/SAE 21434の8章で詳細に説明されているもののようです。当連載記事ではさらっと流していますが、改めてTARAについては各ステップ毎に理解を深める必要がありそうですね。

今回は記事で特筆されている、リスク値の算出方法について見てみます。

f:id:rugbyfp91:20210307114351p:plain

https://insights.tuv.com/jpblog/iso21434

「安全性」に関わるリスク値の算出は、ISO 26262のASIL(Automotive Safety Integrity Level: 安全​性​要求​レベル)に基づいた評価基準で設定することがお勧めとあり、直接安全にかかわるリスク値は高く、財務・運用・プライバシーに関わるリスク値は低くなるのが一般的とのこと。う~ん、前提知識がある人向けに書かれているのでしょうが、なんとも煮え切らない表現、、、まずは概要からということで今回は読み進めましょう。

少なくとも、TARAやASILについてもっと勉強しなければならないことがはっきりしたので、その点を収穫と捉えることとします。

リユース分析の活用

当連載記事最後にリユース分析なるものが書かれています。

同一システムやパーツを複数の車両で利用する場合や、後継車両に再利用する場合にも、担当者は新規開発と同様に、上記コンセプトフェーズに基づく対応を毎回実施しなくてはいけないのでしょうか

という質問に対し、変更レベルに応じたプロセステーラリング(どのステップを省略するか、どのステップと統合するか等の分析)を行うべき、と回答しています。またリユース分析は開発費用・期間を抑制でき効率的な開発を可能にする一方で、リユース分析を誤ってしまうと排除すべきでないプロセスを排除してしまうこともあり、脆弱性につながるリスクがある、とも言っています。

テュフ社ではリユース分析ガイドラインとテンプレートを用意しているようで、サイトからその一部がダウンロードできます。

f:id:rugbyfp91:20210307121027j:plain

https://insights.tuv.com/hubfs/JP-Images/Cybersecurity-for-Mobility/

以前の記事でも書きましたが、テュフ社の良いところはこのように成果物イメージを既に持っており、実際にサンプルを閲覧できるようにしてくれている点です。

確かに同じECUを同じプラットフォームを使っている他の車両や後継車両で利用する際、改めてリスクアセスメントやリスク低減策を考えていては、開発期間が延びるばかりですので、テーラリングは重要ですね。ただし、最近も様々な業界のニュースで見かけますが、こういった品質管理プロセスは、手を抜こうと思えばいくらでも抜ける点でもあり、監査する側も含めて、適正に行われているかをチェックする仕組みを自動車業界として構築すべきと考えます。

 

さて今回でテュフ社の連載記事を見るのは最後となります。一貫性がなくわかりづらい点も多かった記事ではありますが、次の調査ポイントを見つけさせてくれた点は感謝しています。次回以降はTARAの各ステップ、ISO 26262、ASILなど、まだまだ読み砕いていきたいと思います。

改めてISO/SAE 21434に思いを巡らせる

最近はテュフ社の連載を見ています

前々回からテュフ ラインランド ジャパン株式会社のサービスや連載記事について見てきました。

今回もテュフ社の連載記事を基にしつつ考えていきたいと思います。というわけで今回はこちら↓。

前回記事の流れを受けて、ISO/SAE 21434とCSMS要件との相違点の深堀りやそれに向けた対策が書かれていると期待したのですが、連載としてはいまいち内容に一貫性がなく、前回からの流れは受けず主に以下3点について書かれていました。

  • ISO/SAE 21434とは
  • サイバーセキュリティ目標 - コンセプトフェーズの重要性
  • マネジメントシステム(仕組み・手法)体制構築とプロセス

おさらいになってしまう部分もありますが、当ブログはゆっくりと論理的に数学の証明のような1ステップずつ進めていくことをモットーにしているので、これまでの記事との重複は気にしません。

改めてISO/SAE 21434を考える

さっそくISO/SAE 21434からおさらいしましょう。当ブログで初めて記載したのは下記だったと思います。

その際も説明を端折ってきた部分がありましたので、ちょうど良い機会です。わたしが調べた限りでは最もわかりやすく説明されていた、ニュートンコンサルティング株式会社のコラムから引用します。

ISO/SAE21434は、近年増加傾向にあるコネクテッドカーなど、外部ネットワークに接続されることによりサイバー攻撃の脅威にさらされることになった、車両のサイバーセキュリティに関する国際標準規格です。

章立てについても見てみましょう。

ISO/SAE21434は15章構成となっており、大きく分けて7つのフェーズに分かれています。 ここで1章から4章は、本国際標準規格のスコープ、参考文献、用語の定義、考慮事項が記載されており、5章から15章がサイバーセキュリティに関する内容となります。

f:id:rugbyfp91:20210301152505j:plain

以下、参考までに各フェーズについて詳述してみます。ニュートンコンサルティング社のHPに加え、pwc社のHP*1も参考にさせていただきました。

フェーズ1(5章、6章)では、車両のサイバーセキュリティ確保を目的とした組織体制、ガバナンス、ポリシー策定、監査、教育・文化醸成、情報共有体制の整備、品質管理システムといった全社的なサイバーセキュリティ活動基盤が求められます。またそれらを開発プロジェクトレベルで具体化し、サイバーセキュリティ計画として実施すべき工程と成果物を定義します。

フェーズ2(7章)では、車両のサイバーセキュリティに影響を与え得る情報を継続的に収集/トリアージ/分析/対応することを定義します。開発時において収集した情報を適切に設計へフィードバックするためのプロセスも求められています。

フェーズ3(8章)では、車両のサイバーセキュリティリスクを評価する方法を定義します。

フェーズ4(9章)では、コンセプトレベルでのリスクアセスメント(脅威分析)を行い、対応すべきリスクを洗い出し、以降の活動の起点となるサイバーセキュリティの目標(サイバーセキュリティゴール)を定義します。

フェーズ5(10章、11章)では、コンセプトフェーズの成果をもとに、特定の設計/実装内容、また設計/実装を通じて顕在化する脆弱性にも考慮したリスクアセスメントを通し、リスクおよびセキュリティ要求を具体化します。10章「製品開発」は、サイバーセキュリティの仕様を定義し、アイテムまたはコンポーネントに固有のサイバーセキュリティ要件を検証し実装します。11章「サイバーセキュリティの検証」は、各種セキュリティテストの手法によりセキュリティ要件が満たされていることを確認し、合わせてセキュリティ要件そのものが適切に設定されていることの妥当性を確認します。

フェーズ6(12章、13章、14章)では、車両の製造から販売後の運用と保守、そして廃棄までのフェーズについて記載しています。製造フェーズにおいては、工場全体のセキュリティ確保が求められます。運用/保守フェーズにおいては、サイバーセキュリティ発生時のインシデント対応とソフトウェアアップデートに関連する活動について説明しています。廃棄フェーズでは、車載器に登録されたセキュリティや利用者に関する情報の適切な削除ができることが求められます。こうした生産/運用・保守/廃棄時に求められるセキュリティ機能や運用については、後から追加・変更することが難しいため、製品開発フェーズからセキュリティ要件として考慮される必要があります。

フェーズ7(15章)では、サプライチェーンの観点から、Tier1やTier2等のサプライヤーに求められるサイバーセキュリティの対応、見積もりを依頼する際のサイバーセキュリティに関する要件、責任範囲、活動等について定義されています。OEM観点からはサプライヤーの能力評価や受け入れ基準の定義、選定プロセスの整備、サプライヤー観点ではOEMのセキュリティ要求を理解・整合し、自社のサイバーセキュリティ能力を実証することが求められます。

とまあ、細々としてきてしまいましたが、アプリオリに理解できる部分が多いですし、章立てや各項目の内容は必要時に参照する程度で良いのかと思います。

同じ対象を見ているとしても、見る人によって表現の仕方は変わってくるもので、当ブログにおいては様々な会社様の言い方・描き方を紹介してきていますが、ここで連載記事に戻ってテュフ社の表現も見てみましょう。

f:id:rugbyfp91:20210301163103p:plain

https://insights.tuv.com/jpblog/iso21434

これまでフェーズと呼んでいたものをテュフ社では要求領域としているようです。またこの表においては、ISO/SAE 21434の要求領域とUN-R155の主要成果物、そしてCSMS要求との関連を示しています。当ブログでは何度も触れてきていますが、ISO/SAE 21434がCSMS認証取得対策のガイドラインとして有益である、という点をテュフ社としてもここで言いたいようです。

記事で紹介されていた3点の内、今回は1点目のISO/SAE 21434のおさらいに特化してみました。次回は残り2点を見ていきたいと思います。フェーズ4 コンセプトフェーズのアウトプット導出方法が記載されているようです。

果たしてISO/SAE 21434とUN-R155(CSMS要件)は相容れるのか

前回はテュフ社のサービスを見ました

前回、テュフ ラインランド ジャパン社が提供している自動車のサイバーセキュリティ認証に関わる支援サービスを見てきました。

今回は、前回の最後にも書きましたがテュフ社の連載記事を眺めつつも、他の会社様の考え方と比較してみようと思います。比較すべきはタイトル通り、ISO/SAE 21434とUN-R155(CSMS要件)は相容れるのかという点です。同内容について触れているpwc社さんの考え方と一緒に見ていきたいと思います。

テュフ社のお考え

まずは前回からの流れを受けテュフ社の考え方から見ていきましょう。

ずばりこちらに記載されてますが、

ISO/SAE 21434適合だけでは、UN-R155/R156のサイバーセキュリティ要求に適合できない

というのがテュフ社の意見のようです。理由付けとしてもう少し記載されているのが、

UN-R155付則5ではリスク軽減策について、最小限の要求が定義されています。すべての車両は、この最小限の要求を明確化し、実装しなければなりません。一方ISO/SAE 21434は、車両の開発初期から廃棄までのライフサイクル全般に関わるリスクを対象としており、最小限のリスク軽減策の要求に関して定義されていません。

という点です。CSMS要件は最低限のことしか求められていないので、それだけを実装した状態で型式認証が通るのか、という問題提起ですね。ちなみにちなみに、CSMS要件を振り返る際はこちらの2つをどうぞ。

ただし、テュフ社も大前提として、ISO/SAE 21434がCSMS要件を満たすためのガイドラインとして活用できるものである、とも考えており、どう補っていくかを論じています。そこで適用範囲が異なる部分を取り上げています。

ISO/SAE DIS 21434の適用範囲は、インターフェイスコンポーネントを含む量産型自動車の電気/電子システムと規定されており、外部のインフラに対する要求事項などは規定されていません。一方UN-R155の適用範囲は、車両以外の外部インフラ(例:バックエンドサーバー)も含まれて規定されています(附則5、パートC 車両外部の脅威への低減策)。

これまでの記事の中で、CSMS要件では組織論も展開されていることを記載してきました。車両システムそのもののセキュリティだけでなく、ハードウェアやソフトウェアを設計・開発する開発部門、それらの品質を管理する品質管理部門、脆弱性を監視し対応するPSIRTにも要求事項があるわけですから、自動車の電気/電子システムを適用範囲としているISO/SAE 21434では不足してしまいますね。

じゃあ不足している部分はどうしましょうか、という話になるわけですが、

現時点ではUN-R155の解釈に関する明確なガイドラインや基準もないので、求められる要求の対応策案を作成し、都度、認可当局への確認が必要

といったようにテュフ社としては結論付けています。

pwc社のお考え

次にpwc社の考え方についても見てみましょう。

サイバーセキュリティ法規基準との対応性に関しても、WP29内でしばしば議論されている通り、一定の十分性を有すると考えられています。

のように、ISO/SAE 21434とCSMS要件には親和性があると述べています。また、下記の記載を見ると、

UNECE WP29 GRVA サイバーセキュリティ法規基準およびISO/SAE 21434における要求事項は多くの組織に適用できるよう抽象化されており、それゆえ一部、解釈の余地を残しています。法規基準と国際標準規格の要求への対応をどのように具体化し、自組織や自社製品に落とし込むか(テーラリング)は各組織に委ねられます。客観的かつ十分な論拠と証跡をもって、論証を成立させることが求められます。

実質的な主張内容としてはテュフ社とそれほど違いは無いと考えますが、相容れないので不足点を補おうというテュフ社に対し、最初からテーラリングをしていきましょう、という姿勢がちょっと違うかなと思いました。ちなみにテーラリングですが、

テーラリングとは、(洋服の)仕立て、仕立て直し、という意味の英単語。ITの分野では、業務プロセスやシステム開発プロセスなどについて、規格や全社的な標準などを元に、個別の部署やプロジェクトに合った具体的な標準を策定することをこのように呼ぶ。

e-Wordsに記載されています。初めから標準的なものでしかないと位置付けた上で、それを柔軟に活用していこう、という発想をpwc社はされているようです。テーラリングとかって言葉をさらっと使えるようになると、なんかカッコいいですね。さすがコンサルティングファーム様。

いったい何が違うのか

記載内容だけを見るとテュフ社とpwc社の考え方に本質的な違いは無いのかもしれません。ただ実際にCSMS要件対応プロジェクトをやるぞーとなった際には、アプローチに大きな違いがでるかもしれません。

例えばあまりリソースをかけたくない中小企業で考えるならば、テュフ社のようなきっちりと自分たちの考えを提示してくれる方が、楽ちんかもしれませんね。丸投げとは言いませんが、実際前回の記事でもご紹介したようにテンプレートも用意されているようなので、ナビ通りに当てはめていくという進め方ができると思われます。

一方、OEMやTier1サプライヤーのように自分たちできちんと理解した上で運用が求められるような大企業で考えるならば、共にCSMS要件をきちんと理解しISO/SAE 21434をテーラリングしてくれるpwc社さんのような会社をパートナーとした方が進めやすいかもしれません。

わたしのように実務に携わる可能性がある者からすると、こういった点に思いを馳せる必要があるわけです。単に規約を理解すれば良いだけでなく、社内に浸透させ長く運用管理していくことはとても難しいからです。それぞれの企業体に適したアプローチを選択すべきと考えます。

CSMS/SUMS支援サービスをドイツに学ぶ -テュフ ラインランド ジャパン社-

ドイツの会社です

今回注目した記事はテュフ ラインランド ジャパン社の、サイバーセキュリティ認証にかかわる支援サービスです。Responseの記事から。

初めて知る会社様でしたが、テュフ ラインランド ジャパン株式会社は、ドイツに本社をおくテュフ ラインランド グループの日本法人とのことです。ドイツでは運転免許試験の実施、車検サービスなども実施している第三者検査機関で、日本には1978年に事務所を開設し、現在の日本法人は横浜にあり、従業員は約400人とのことです。 

f:id:rugbyfp91:20210212140734j:plain

https://www.tuv.com/world/en/about-us/t%C3%BCv-rheinland-at-a-glance/

写真はおそらくケルンにあるドイツ本社かなと思います。たぶん。。。

「自動車のサイバーセキュリティ認証にかかわる支援サービス」とは

ではサービス内容を見ていきましょう。Responseの記事には当たり障りのない程度しか書かれていませんでしたので、テュフ社のHPを読んでみます。

サービス内容に入る前に、わかりやすい図が掲載されていたので、やさーしく読み砕いていくことをモットーにしている当ブログ、少しだけ脱線します。ちょうどこのページに型式認証やCSMS認証のスケジュールがまとまっていました。

f:id:rugbyfp91:20210212144719p:plain

https://www.tuv.com/japan/jp/lp/cybersecurity-for-mobility/

日本やEU諸国では2022年7月から新型車両(新電気・電子プラットフォーム)への適合が、さらに2024年7月からは全ての新車両への適合が義務付けられていることがわかります。(CSMSについては他サイトも含めもう少し調査してみます)

またISO/SAE 21434には当ブログで触れてきましたが、それとともに関連する規格が紹介されています。

f:id:rugbyfp91:20210212144709p:plain

https://www.tuv.com/japan/jp/lp/cybersecurity-for-mobility/

ISO 26262ならびにISO/PAS 21448については別の機会に触れることとします。
というわけで、目的のサービス内容の詳細ですが、

  1. サイバーセキュリティ適合ギャップ分析
  2. 検証(verification)、監査、アセスメントの実施
  3. 各種技術的な対策の適合評価 (UN-R155 附則5のリスク軽減策の評価など)
  4. サイバーセキュリティ 作業成果物の評価
  5. CSMS/SUMS認証につながる事前審査など
  6. 要求事項の当局解釈についての確認および説明
  7. CSトレーニング~基礎編、CSワークショップ、CSエンジニア認定コース

のように、現状のギャップ分析、アセスメントに始まり、成果物が要件に合致するかどうか、認証前の準備、そして関係者へのトレーニングといったパッケージになっている模様です。同じページに型式認証の際に利用できる成果物サンプルも掲載されており、サービスのイメージがつきますね。

f:id:rugbyfp91:20210212154344j:plain

https://www.tuv.com/japan/jp/lp/cybersecurity-for-mobility/

ISO/SAE 21434の要求に対する最低限の成果物を記載しているとのことで、実践的なものとなってることがわかります。

テュフ社に今後も注目か

これまで幾つかのコンサルティング会社様の考え方やサービスも見てきましたが、このResponse記事を読むまで会社すら知らなかったテュフ社のものが最も網羅性があり、信頼できそうな印象を受けています。自動車のセキュリティに関する連載記事もHPに掲載されていたので、今後読み砕いていきたいと思います。

ともかくAreneて名前は今っぽくていい -ウーブン・プラネット・グループ-

さて今回はこちらのMONOist記事から。

これまでTRI-AD(Toyota Research Institute Advanced Development)として車載ソフトウェアを開発してきた会社が、2021年1月、新体制ウーブン・プラネット・グループとして動き出したとのこと。企業名やロゴが今っぽいですね。

f:id:rugbyfp91:20210203143458j:plain

https://www.woven-planet.global/jp/company-information

持株会社となるウーブン・プラネット・ホールディングスの下、事業会社として自動運転技術を手掛けるウーブン・コア、新領域の事業機会の探索に取り組むウーブン・アルファ投資ファンドウーブン・キャピタルの3社となります。

セキュリティを考える当ブログにおいては、ウーブン・アルファが気になりますね。トヨタ自動車東日本の東富士工場跡地で2021年2月23日に着工するコネクテッドシティ「Woven City(ウーブンシティ)」や、自動運転車向け高精度地図の普及を促進するために車両から得られるセンサーデータをオープンに共有する「Automated Mapping Platform(AMP)」、車載ソフトウェアの開発プラットフォーム「Arene(アリーン)」などが事業領域のようです。Woven Cityについては今後の進捗を見ていきたいですね。きっとセキュリティ絡みの課題も見えてくることでしょう。

今回注目は、やはり車載ソフトウェアの開発プラットフォーム、Areneでしょう。

f:id:rugbyfp91:20210203144815j:plain

https://www.woven-planet.global/jp/woven-alpha/arene

クルマのAPIや安全性のための基本的な要素を包括する、最先端のプラットフォーム

とHPに記載されている通り、車載OSを目指して開発されているもののようです。PCやスマホのように、アプリケーションが定期的にアップデートされるのが、自動車でも当たり前になる時代がやってくるのでしょうね。カーナビの地図を更新するのにひどい出費を強いられていた時代は終わりますね。。。

具体的に触ったわけではないので、Areneの詳細はわかりませんが、ツール・サービス群となっているとのこと。

  • アプリケーションSDK:シミュレーションや実車両でのアプリケーションの開発・テスト・運用ができるツールやAPI。UIやセンサー、アクチュエータなど車両の特定した部分にアクセスできます。

  • シミュレーションとテスト:さまざまな車両モデルの仮想シナリオを作成し、Areneの継続的なインテグレーションおよびテスト用パイプラインを使うことで、SILS(software-in-the-loop)およびHILS(hardware-in-the-loop)のシミュレーションができます。

  • インフラサービス:AWSサンドボックスの作成を自動化するAnsibleとTerraformのテンプレートを使い、クラウドベースのデータパイプラインでデータ処理およびインデックス化ができます。

このような開発プラットフォームにおいてデファクトスタンダードを構築することがトヨタの狙いかと考えますが、AppleGoogleのような新興勢力とは競合となるのか、パートナーとなっていくのか、今後に注目したいです。先日記載した藤本先生のセミナーにおいても特にハードを長年やってきているAppleは要注意と仰っていましたが、日本車ではともかく、グローバルでのデファクトとなるのは容易ではないでしょうね。

また、EyeSightやProPILOTなど、今は各社が自動運転システムを開発しているかと思いますが、このAreneをトヨタの仲間たち、SUBARUMazdaはきっとプラットフォームとして活用するのでしょうが、HONDAやNISSANはどうするのでしょうか。

尚このArene、現時点では残念ながらセキュリティ面については全く触れられていないので、今後エンジニアに広まっていくようであれば、その際に様々な記載が出てくることを待ちます。ただAreneを活用することで、ソフトウェアアップデートがセキュアに実施でき、SUMSへの対応が容易になる、ということであれば、トヨタ系列の中小サプライヤーが活用することで、広く普及することも夢ではないと考えます。WindowsAndroidのように果たしてなれるのか、今後もウーブン・プラネット・グループやその各事業についてウォッチしていきたいと思います。

内容はともかく本になってるとなんかカッコいい -デロイト社の続・モビリティー革命2030を読む-

なかなか新しいインプットが無い、くるまのサイバーセキュリティ。去年の本ではありましたが何か新しい視点を得られるかと思い、下記を読んでみました。

当ブログではpwc社さんやKPMG社さんの記事等も参考にさせていただいてきましたが、今回はデロイトトーマツコンサルティング社さんの書籍となります。内容はと言うと・・・サイバーセキュリティについては、残念ながら薄っい。

pwcさんはCSMSやSUMSを独自に解釈し、その構築のアプローチを彼らなりにストーリー立ててくれていました。下記参照。

KPMGさんもescrypt社の製品を具体的なソリューションとすることでCSMS構築の道筋を示していましたね。下記参照。

それに比較するとデロイトさんのご本はちょっと物足りなく感じるものでしたが、ECUの増加に対する考察だけは、言われてみればそうだなあと感じるものの、これまで思いつかなかった視点ではありました。

自動運転など車の機能増加に伴いECUが増加していくに際し、パソコンのように中央演算処理の方向に向かうのではないか、という示唆でした。車載OSが開発され、ECU自体の数は減っていくのではないか、ただしそのような場合、標準化されたプラットフォームOSが外部とネットワークで繋がることにより、逆に外部からは攻撃がしやすくなる、ということへの警鐘を鳴らすものでした。

さて今回は以上とさせていただきますが、ちょっとセキュリティ絡みのUPDATEが乏しい反面、EV、電気自動車に関するものはわんさか溢れてきていますね。セキュリティを考えるのがこのブログの目的ではあるのですが、ガソリン車と比較してよりセキュリティを考えねばならないEVについて、少し昨今の状況を整理してみるのも良いかなと思っています。次回以降、興味深い下記あたりから考えてみたいと思います。