もしかしたら、「SDVで何が変わるのか」を考える上での材料として、「AUTOSARの導入の背後にある一般的な性質」も役立つかもしれません。
本連載の第3回では、「AUTOSAR導入の背後にある一般的な性質」をご紹介いたしました。
加えて、RTOS(リアルタイムOS)の利用という、特に国内の一部の方々にとっての障壁(第24回を参照)を加えて整理し直したのが以下の18項目です(表1)。
No. | 性質 |
---|---|
A1) | 自動化の効果への依存(の拡大、以下同様) |
A2) | 再利用の効果への依存 ※再利用の対象はプログラムコードだけに限らない |
A3) | 高度な技術的内容のブラックボックス化(による分業/作業並列化の効果への依存の拡大) |
A4) | バイナリ形式のソフトウェアの利用拡大 ※解析への対抗や、「変化なし」という説明の活用 |
A5) | 既存のものとは何らかの性質の異なる「何か」への移行 |
A6) | より頻繁な、異なる立場間(水平/垂直のそれぞれの方向)での、情報/成果物の授受 |
A7) | 形式化された情報の利用への依存 |
A8) | 形式化された情報の授受への依存 |
A9) | 自動生成コードへの依存 |
A10) | 外部調達品への依存 |
A11) | 既製品の利用(COTS:商用オフザシェルフを含む) |
A12) | 多目的/多用途製品(汎用品)の利用 ※多様なコンテキストで利用できるものを、コンテキストを明らかにしながら、そこに当てはめ |
A13) | 設定により振る舞いや構造(例:インタフェース)の変わるソフトウェアの利用 |
A14) | 標準化活動における合意に基づく、標準規格や他の成果とそれらに含まれる知財の利用 |
A15) | 変化し続けるものの利用 ※reusable/updateableの裏返し |
A16) | インタフェースと振る舞いのさらなる分離 ※インタフェースや振る舞いの多階層化も含めて |
A17) | ソフトウェアの配置自由度の向上 ※特に理由がなければ、どこで実行しても良い |
A18) | RTOSの利用 ※一部ではまだ障壁? |
表1 AUTOSAR CP導入の背後にある一般的な性質 |
これらは互いに独立でもなく、また、抽象度の階層が異なるものも混じりあっており整理の余地はありますが(整理しすぎると今度はイメージをつかみにくくなるというお声もいただいていますので、意図的にこれでとどめております)、もしも「SDVの背後にある一般的な性質」を書き出してみたとしたら、これら「AUTOSAR導入の背後にある一般的な性質」の内容の多くが含まれるのではないでしょうか。※4)
※4)これらの性質に該当することが、これまで全く行われてこなかったということでは決してありません。何らかの形で、多かれ少なかれ行われていたことと思います。ただ、AUTOSAR導入によって、さらに広く行われるようになったということは間違いないでしょう。そして、これらの性質がもたらすものには、うれしいこともあれば、うれしくないこともあります。そして、ある立場ではうれしいことも、別の立場ではうれしくない、ということも起こるでしょう。各種制約や価値観(常識を含む)に左右されます。ですから、「AUTOSAR導入によるうれしさ」を、誰にでも分かりやすく、実感の持てる形で一般論としてまとめようと努力すればするほど、結果には必ずモヤモヤ感が付きまとうのです。これは、「SDVの影響やうれしさ」でも同様でしょう。
また、SDVではさらに、例えば以下のような要素が含まれてくるでしょう(表2、ここでは一部のみのご紹介です)。
No. | 性質 |
---|---|
S1) | 「ソフトウェア」の意味合いの変化/範囲の拡大(プログラムコードだけではなくAIデータも) |
S2) | エッジコンピューティングへの依存 |
S3) | リモートアクセシビリティーへの依存(コネクティビティー) |
S4) | System-of-systemsとしてのインテグレーション※5)/検証/保証/補償と不適切な利用の阻止 |
S5) | モノではなくサービス/機能(feature)/性能に対する価値の評価や説明 |
S6) | より頻繁でより広範囲のアップデート(ECU SWのみならず従来HWで実現した機能や、ネットワークの振る舞いなども - SDN: software-defined network)※6) |
S7) | 想定期間のアップデータビリティーを支えることに最適化したHWアーキテクチャ計画 |
S8) | より汎化されたプレイヤー/アクターの集団※7)による、複雑なシステムの取り扱い方や期待の進化(作る側と利用する側双方において) |
S9) | より汎化されたプレイヤー/アクターのそれぞれに対するUXの個別最適化※8) |
S10) | より汎化されたプレイヤー/アクターの巻き込みと相互の存在承認/合意形成手段の確立 |
表2 SDVの背後に現れ得る追加の性質(AUTOSAR CP導入の背後にある一般的な性質への追加) |
※5)インテグレーション完了条件(integration goal)の定義という課題は一層困難になっていくでしょう。Integrationという単語を英語の辞書で引くと「部分を集めて、全体を作り上げる」に類する表現が最初に出てくることが多いのですが、「全体:whole」とは何か、それを定義するのは実は結構大変ですし、それを定義できないままでは「インテグレーション結果の価値の説明」も困難です。
※6)なお、AUTOSAR Classic Platform(CP)では、アップデートはアーキテクチャ要素の対象外でした。
※7)自然人、法人、システムやAI(人格の観点では電子人:Electronic Personという表現もあるようですね)という多様なプレイヤー/アクター同士がつながった広義のネットワーク。
※8)利用者側だけではなく、例えば、開発者それぞれに適した、APIを含む広義の開発環境の提供なども含む。
これらを議論/検討の起点とし、さらに深掘りし整理することで見えてくるものや、その結果得られる「シンプルな原理原則」は多数あるはずです。
例えば、以下のような「見えてきた」内容については、既に書き終えたのですが、ボリュームが大きくなってしまいました。
SDVとAUTOSARの相似性に関する議論はいったんここで止めて、AUTOSAR R22-11の変更内容のご紹介に移りたいと思います。次回以降、あるいは何か別の機会があれば、「見えてきた」内容(+α)につきましてもご紹介いたします。
Copyright © ITmedia, Inc. All Rights Reserved.