これからのくるまのセキュリティを考えるぶろぐ

もう前回いつ書いたのか思い出すのも億劫ではある今日、2025年度末です。

このブログで最もアクセスされている記事がRSXWIN関連というのは、少し意外に見えて、実はとても自然なことだと思います。
自動車のソフトウェア管理が複雑になるほど、「何が、どの車両に、どの状態で入っているのか」を追う重要性が高まるからです。

以前の記事ではRSXWINを中心に、車両ソフトウェアの識別や更新管理について整理しました。

今回はその続きとして、なぜRSXWIN記事が今も読まれ続けるのか、そして今の時点でどう理解するとよいかを改めてまとめます。

RSXWINとは何か

改めまして、RSXWINは、UN Regulation No.156で扱われるSoftware Identification Numberに関連する考え方です。
車両に搭載されるソフトウェア構成を識別し、更新前後の状態や型式認証との関係を追いやすくするために使われます。

単に「ソフトウェアの番号」を付けるだけではなく、どの車両構成に対するソフトウェアかを明確にする点に意味があります。
そのため、開発だけでなく、認証、品質保証、アフターサービス、セキュリティ対応まで幅広く関係します。

RSXWINの記事が今でもアクセスされるのは、単に用語解説として便利だからではありません。実務で必要になる場面が増えているからだと思います。やっと投稿に現実が追いついてきてくれたかと思うと感慨深いです。

車両ソフトウェアの更新は、OTAを含めて継続的に行われるようになりました。

その結果、更新履歴の記録、影響範囲の特定、監査対応、サプライヤー管理などで、RSXWINのような識別の考え方が必要になります。

また、UN-R156ではソフトウェアアップデートを安全に運用するための管理体制が求められます。RSXWINは、その運用の中で「どのソフトウェア状態を管理しているのか」を示す軸として機能します。

当時自分でパワポで作った図を引用しますが、

f:id:rugbyfp91:20210310162014j:plain

この図は、RSXWINをどう考えるかを、車両に搭載されるソフトウェア構成とUN規則の関係から示したものです。
ここでは、車両XXX-YYYにABSとEPSという2つのECUソフトウェアが搭載されている例を使って、設計上の識別子とRSXWINの関係を整理しています。

たとえば、ABSはブレーキ系の機能なので、ブレーキに関するUN規則と関係します。
一方、EPSは電動パワーステアリングなので、操舵系のUN規則と関係します。
このように、同じ車両の中でも、ソフトウェアごとに対応する規則や管理対象は異なります。

そこで設計側では、ソフトウェア構成を表すSysIDを付けて管理し、それをもとにRSXWINを採番します。
RSXWINは、単にソフトウェア名を表すものではなく、どの車両の、どのシステムに、どの規則上の意味を持つソフトウェアなのかを示すための識別子として使われます。

つまりこの図が示しているのは、
車両構成 → システム構成 → 法規との関係 → RSXWINの採番
という流れです。
この考え方を持っておくと、ソフトウェア更新や影響範囲の確認をするときに、どのECUがどの規則に関係するのかを追いやすくなります。

RSXWINとSBOMは、どちらもソフトウェア管理に関わるため混同されやすいです。
ただし役割は違います。

SBOMは、ソフトウェアを構成するコンポーネントや依存関係を一覧化し、脆弱性管理や透明性向上に役立てるものです。

一方でRSXWINは、車両や型式に紐づくソフトウェア構成を識別するためのものとして捉えると理解しやすいです。

つまり、SBOMが「中身の部品表」だとすれば、RSXWINは「その部品がどの車両構成として扱われるか」を追うための情報です。
両方を組み合わせることで、脆弱性が見つかったときに、影響範囲をより正確に把握しやすくなります。

RSXWINは、採番して終わりではありません。
実際には、アップデート前後で構成がどう変わったか、どのECUが影響を受けたか、変更後の状態をどう記録するかまで含めて考える必要があります。

特に、ソフトウェア更新が増えると、バージョン管理や影響評価、証跡管理の重要性が一気に高まります。
そのためRSXWINは、法規対応のための識別子というだけでなく、開発・品質・セキュリティ・運用をつなぐ共通言語として見ておくと実務に役立ちます。

以前は「RSXWINとは何か」を理解することが入口でした。
いまはそこから一歩進んで、どう運用し、SBOMやOTA、UN-R156対応とどう結びつけるかが本題になっています。

このブログでRSXWIN記事が最も読まれているのも、まさにそこに理由があるのだと思います。RSXWINは単独の用語ではなく、車両ソフトウェア管理全体の中で意味を持つテーマとして、今後も見直す価値があるのかなと改めて考えた次第です。

あまり日経新聞で取り上げられることのない、サイバーセキュリティのマニアックな情報ですが、今回の2022年7月適用開始の件については記事になっていたので、取り上げようと思います。

まずは、わかりやすい図がありましたのでそのまま拝借します。

当ブログを見て下さってる方にはいまさらですが、OTAによるオンラインでのソフトウエア更新機能を備えた新車に対し、CSMS/SUMSの各プロセスに基づいた認証が必要となります。規制車種は少しずつ拡大し、26年には発売済の車も含め全車種が対象となる見通しです。

審査の期間についてまとめてくれていたので、そのまま引用しますが、

審査自体の負担も増す。安全装置などの審査では車種ごとの型式審査に6週間程度かかるのが通例だ。新規制では型式審査の前にメーカーの組織体制が基準に見合うものかの審査に2カ月程度かかる。組織の審査は毎回行う必要は無いが、3年ごとに更新が必要だ。

わたしが普段お世話になっている自動車OEMでも今後新車が出る予定がありますが、OTAを使っているのか定かではなく、今度聞いてみようと思います。ただ、CSMSやSUMSが整備されたとは聞いてないので、まだ適用範囲外かもしれませんが。