　「AUTOSARの導入の背後にある一般的な性質」についておさらいです。次節以降でもそれらの要素が登場しますので、前回の連載第30回に掲載した表1を今回の表3として、表2を今回の表4として、一部改訂増補し再掲いたします。改めての解説は行いません（おさらいのみ）。必要でしたら前回記事の内容をご覧いただくか、筆者にお声がけください。


No.	性質
A1）	自動化の効果への依存（の拡大、以下同様） ※）例：SW-CのI/Fや内部の振る舞い定義は、RTEコード生成だけではなく、テスト自動化やそのVariant Handling対応などにも利用可能
A2）	再利用の効果への依存 ※再利用の対象はプログラムコードだけに限らない
A3）	高度な技術的内容のブラックボックス化（による分業／作業並列化の効果への依存の拡大）
A4）	バイナリ形式のソフトウェアの利用拡大 ※解析への対抗や、「変化なし」という説明の活用
A5）	既存のものとは何らかの性質の異なる「何か」への移行
A6）	より頻繁な、異なる立場間（水平／垂直のそれぞれの方向）での、情報／成果物の授受
A7）	形式化された情報の利用への依存
A8）	形式化された情報の授受への依存
A9）	自動生成コードへの依存
A10）	外部調達品への依存
A11）	既製品の利用（COTS：商用オフザシェルフを含む）
A12）	多目的／多用途製品（汎用品）の利用 ※多様なコンテキストで利用できるものを、コンテキストを明らかにしながら、そこに当てはめ
A13）	設定により振る舞いや構造（例：インタフェース）の変わるソフトウェアの利用
A14）	標準化活動における合意に基づく、標準規格や他の成果とそれらに含まれる知財の利用
A15）	変化し続けるものの利用 ※reusable／updateableの裏返し
A16）	インタフェースと振る舞いのさらなる分離 ※インタフェースや振る舞いの多階層化も含めて
A17）	ソフトウェアの配置自由度の向上 ※特に理由がなければ、どこで実行しても良い
A18）	リアルタイムOS（RTOS）の利用 ※）一部ではまだ障壁？（そうでしたら、本連載第24回にGo！）
表3　AUTOSAR CP導入の背後にある一般的な性質


No.	性質
S1）	「ソフトウェア」の意味合いの変化／範囲の拡大（プログラムコードだけではなく、プロセス、AI学習データなども）
S2）	エッジコンピューティングへの依存
S3）	リモートアクセシビリティーへの依存（コネクティビティー）
S4）	System-of-systemsとしてのインテグレーション^※9）、各種「ホショウ」（検証、保証、補償）と不適切な利用の阻止
S5）	モノではなくサービス／機能（feature）／性能に対する価値の評価や説明
S6）	より頻繁でより広範囲のアップデート（ECU SWのみならず従来HWで実現した機能や、ネットワークの振る舞いなども - SDN: software-defined network）^※10）
S7）	想定期間のアップデータビリティーを支えることに最適化したHWアーキテクチャ計画
S8）	より汎化されたプレイヤー／アクターの集団^※11）による、複雑なシステムの取り扱い方や期待の進化（作る側と利用する側双方において）
S9）	より汎化されたプレイヤー／アクターのそれぞれに対するUXの個別最適化^※12）
S10）	より汎化されたプレイヤー／アクターの巻き込みと相互の存在承認／合意形成手段の確立
表4　SDVの背後に現れ得る追加の性質（AUTOSAR CP導入の背後にある一般的な性質への追加）

※9）インテグレーション完了条件（integration goal）の定義という課題は一層困難になっていくでしょう。Integrationという単語を英語の辞書で引くと「部分を集めて、全体を作り上げる」に類する表現が最初に出てくることが多いのですが、「全体 whole」とは何か、それを定義するのは実は結構大変ですし、それを定義できないままでは「インテグレーション結果の価値の説明」も困難です。

※10）なお、AUTOSAR Classic Platform（CP）では、updateはアーキテクチャ要素の対象外でした。

※11）自然人、法人、システムやAI（人格の観点では電子人（Electronic Person）という表現もあるようですね）という多様なプレイヤー／アクター同士がつながった広義のネットワーク。

※12）利用者側だけではなく、例えば、開発者それぞれに適した、APIを含む広義の開発環境の提供なども含む。

3.2 壁を作るだけではなく、内側／外側との連携手段を確立してこその「ブラックボックス化」

　ここでは、表3の「A3）高度な技術的内容のブラックボックス化（による分業／作業並列化の効果への依存の拡大）」を例にとって見ていきましょう。

　AUTOSARやCOVESAなどで標準化の議論が進められているVehicle API／Automotive APIと呼ばれるものは、そのAPIによりさまざまな要素を捨象（あるいは抽象化）することで、それら捨象された内容（＝ブラックボックスの中身）に関する深い知見を持たなくとも、さまざまな機能やサービスを開発できるようにしてくれます。ブラックボックスの蓋を開くことなくブラックボックスのままで手軽に利用できる、というわけです。

　ただし、それは順調に進んでいる時だけに限られます。

　順調でなくなれば、APIというブラックボックスの蓋を開け、中に手を突っ込み対処していくことが必要になります。

　「自分の関心領域はここだけだ」としていて、中に手を突っ込み対処しなければならない場合の備えがなければ、手詰まりになってしまいますし、ブラックボックスのuser／外側とprovider／内側の間に従来の「master-slave」のような主従関係を持ち込んでも、助けてくれる保証はありません。第一、この語自体が、今や業界から追放されかかっています^※13）。トラブルが起きたときに対処できる自信が持てなかったり、あてにできる人がいなかったりというのであれば、その仕事に安心して携わることできないのは誰にとっても当然ですし、リスクマネジメントの観点でも大問題です。

　また、サービス提供側／開発側にいちいち蓋を開けさせなければならないようなものであれば、使いにくいだけです。必ずしもサービス提供側／開発側が触れる必要のないところまで触れることを強いるようなインタフェース（ユーザーインタフェース（UI）、API、データ交換形式など）が、よりよいインタフェース（あるいは、もっと汎化して、サービス提供側／開発側をもuserに含めたuser experience、UX）に淘汰されるのは当然のことでしょう。

　表4の「S9）より汎化されたプレイヤー／アクターのそれぞれに対するUXの個別最適化」は、ブラックボックス化の方向性を決める、無視できない要素になるはずです。

　ですから、APIを「壁」として扱う姿勢ではなく、積極的に「中の対処をできる人ともつながれるように、あらかじめ準備しておく」という姿勢が求められることが、見えてくるはずです。より抽象度の高いところで扱えるようにするAPIであれ、また、同列の周囲のものとつながるためのAPIであれ同様でしょう。そして、こういった考え方は、だいぶ上位の要件に位置付けられることになるでしょうが、表4の「S10）より汎化されたプレイヤー／アクターの巻き込みと相互の存在承認／合意形成手段の確立」にもつながってくることは明らかだと思います。

　モビリティを利用して各種サービスを提供する側や、それを開発する側とうまく「つながる」^※14）ことができなければ、「サービスプロバイダーに見向きもされないモビリティサービスプラットフォーム」にしかなりえないかもしれません。他に同等の代替選択肢がなくとも安泰ではないでしょう。全体の階層構造の中で、異なる階層に使いやすいものがあれば、そちらに移ればいいだけのことだからです。

※13）SAEのLIN関連規格SAE J2602の2021年の改訂では、master/slaveをcommander/responderに置き換えました。また、AUTOSARでもR20-11より表現見直しを行っていることを、Release Overview sec. 1.2.1で明記しています。一方、実際の文字通りの「master-slave」という不適切な関係は、国内では形を変えつつも根強く残りそうな雰囲気も感じられ（まさに内と外）、不安を抱いています。これは筆者だけでしょうか……。

※14）Connectivityではなく、より広義の「連携」の意味。

開発者だけではなく利用者もプレイヤー

前のページへ 1|2|3|4|5 次のページへ