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コネクタなどと呼ばれており、実際には下図のようなものが運転席のハンドル下やアクセルペダル付近などにあるとのこと。わたしも愛車で確認してみようと思います。
自身ではもちろん行ったことはありませんが、おそらく点検等でディーラーへ持っていった際には下図のようにOBD2コネクタに接続して、異常がないかどうか見てくれているのでしょうね。
UN規則とECUソフトウェアとの関連付け
RXSWINの核心となる、定義の3番目以降に話を移します。今回参考にしている英語資料を読み進めた結果ですが、RXSWINはUN規則が大きな採番単位となるわけですが、ECUソフトウェアとの関連を考えるとわたしの理解は下図のようになりました。
※ここでSysIDなるものが出てきますが、参考資料内では、これは設計サイドの管理番号との位置付けとなっていました。あくまでRXSWINは当局とやり取りをする認証部門内で採番されるものであり、設計時には別のIDで管理されている、という前提があるようです。確かにそれはそうだろうなあ、と個人的には納得しておりますが、ご注意を。
例えば車両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車両に搭載されているブレーキが対象となります
