ソフトウェアの部品表 その1

「ソフトウェアの部品表」という言葉がネット上に時々現れているようです。どうしてこんなことが話題になるかと言うと、Software Defined Vehicle(SDV)といった車が現れたからなんです。まあ、スマホが車になったような物です。

ここでちょっとした問題があって、ソフトウェアなので当然色々なバグがあって更新と言うことが必要になってくるのです。Over The Air(OTA)と言って、スマホのようにインターネットから車のソフトが更新されるんです。Naviの地図くらいなら良いんですが、自動運転とか燃費とかと言った、型式認定というレギュレーションに関わるものが出てきたからです。

ソフトウェアの部品って、ソースコードだったり、ビルドした実行可能コードだったりします。ソースコードの話は別途説明するとして、まずはOTAが話題なので実行可能コードを部品としましょう。

まずは、ブレーキSWがあったとして、Ver 1.0 と Ver 2.0をモデルとして、OVM/BoMで作ってみましょう。

OVM/BoMは、部品をMaster Item と Affected Itemのペアで表見します。よくあるのが、ブレーキSWには、SW機能としての番号(例えば "SW100")と付け、個々のSW部品には"SW100-01"とか"SW100-02"とかの追い番を付けて管理しています。

どうしてふたつのモデル要素として図に表しているかは、追々説明しますが、まずは分けておきます。

最初の例は、「バリアント」と関係を持たせることです。ブレーキSW仕様には「標準」と「寒冷地」の2種類があります。これを具体的に実現しているものが、ブレーキSWのVer 1.0 と 2.0 です。その関係を「具現化(Realize)」という関係で表現しています。

この関係を表にすると、JP向けのSWは「標準仕様」で「Ver 1.0」で、US向けは、「標準仕様」と「寒冷地仕様」の2種類が構成として得られます。

よくある部品表システムでは、以下のように実際に作った組み合わせしか持っていないことがあります。

この表だけを持っていると、USに標準仕様の SWを入れて良いかどうかはこの表からは読み取れません。(もし、この表が全ての組み合わせを意味しているならば、USには標準仕様のSWを許していないことになります。)