本記事は、2023年9月4日に掲載した「SDVの時代を踏まえ、「AUTOSARの使いこなし」を見直してみませんか?」の続編です。

SDV（software-defined vehicle）で何が変わるのか？また、それに関連するAUTOSAR導入の背後にある一般的な性質について、弊社のSafety/Security シニアエキスパートでありAUTOSARの仕様策定にも参画している櫻井から紹介します。

前回も述べましたが、最近の自動車分野でのバズワードといえば、SDV (software-defined vehicle) でしょう。ただ、SDVで何が変わるのでしょうか? もしかしたら、それを考える上での材料として、「AUTOSARの導入の背後にある一般的な性質」もお役に立てるかもしれません。
前回に引き続き、少し掘り下げていきたいと思います。

1) SDVと、AUTOSAR導入の共通点

「AUTOSARの導入の背後にある一般的な性質」についておさらいです。次節以降でもそれらの要素が登場しますので、前回内容のうち、表1, 表2を一部改訂増補し再掲いたしますが、改めての解説は行いません (必要でしたら前回内容をご覧いただくか、弊社にお声がけください)。

表1: AUTOSAR CP導入の背後にある一般的な性質

表2: SDVの背後に表れうる追加の性質 (AUTOSAR CP導入の背後にある一般的な性質への追加)

^(※1) インテグレーション完了条件 (integration goal) の定義という課題は一層困難になっていくでしょう。Integrationという単語を英語の辞書で引くと「部分を集めて、全体を作り上げる」に類する表現が最初に出てくることが多いのですが、「全体 whole」とは何か、それを定義するのは実は結構大変ですし、それを定義できないままでは「インテグレーション結果の価値の説明」も困難です。
^(※2) なお、AUTOSAR Classic Platform (CP) では、updateはアーキテクチャ要素の対象外でした。
^(※3) 自然人, 法人, システムやAI (人格の観点では電子人 (Electronic Person) という表現もあるようですね) という多様なプレイヤー・アクター同士がつながった広義のネットワーク。
^(※4) 利用者側だけではなく、例えば、開発者それぞれに適した、APIを含む広義の開発環境の提供なども含む。

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

こちらもおさらいからです。ここでは、表1の「A3) 高度な技術的内容のブラックボックス化 (による分業・作業並列化の効果への依存の拡大)」を例にとってみていきましょう。

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

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

前回はここまで申し上げましたが、まだまだあります。

サービス提供側・開発側にいちいち蓋を開けさせなければならないようなものであれば、使いにくいだけです。必ずしもサービス提供・開発側が触れる必要のないところまで触れることを強いるようなインタフェース (ユーザーインタフェース (UI), API, データ交換形式など) が、よりよいインタフェース (あるいは、もっと汎化して、サービス提供・開発側をもuserに含めたuser experience, UX) に淘汰されるのは当然のことでしょう。
S9「より汎化されたプレイヤー・アクターのそれぞれに対するUXの個別最適化」は、ブラックボックス化の方向性を決める、無視できない要素になるはずです。

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

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

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

3) 必然以外を決め急がず、必然の種類も区別する / 開発者だけではなく利用者もプレイヤー

さて、ここからは少々抽象度の高い内容になりますので、読みにくいかもしれませんが、実は、アーキテクチャ設計の一般的な内容を述べているだけですので、我慢してしばしお付き合いいただければと思います。

ある意図の実現手段は、その下の階層ではさらにさまざまな実現手段にブレークダウンされていきます。手段間は、必要があれば互いに連携しますし、各手段はさらに必要に応じてブレークダウンされ、下の階層に伸びていきます。逆に、下から上の方にたどっていけば、最後にはサービス利用者の意図 (あるいはサービス提供側の想定に対する、それを利用すると決めた利用者の想定に対する肯定の意思決定) にたどり着きます。

この一連のブレークダウン構造の一部分を開発する際、その「開発対象の領域」の中では、「周囲から与えられた要求・制約」を完全または限定的に満たしていくこととなります。何らかの限定をつければ、それは、他の階層や周囲のものに対する制約 (周囲から見たら、使用上の指示) を付け加えることになります。周囲から見たら、「周囲から与えられた要求・制約と、その実現上の限定 (制約)」が「サービス提供側の想定」となります。これは、「開発対象の領域」が、a) 全体の階層構造の中のある階層の中で下位階層をブラックボックス化して開発する場合でも、また、b) 同列の周囲のものとつながるものをブラックボックス化して開発する場合のいずれでも、同様です。

また、パッケージング・リリース時 (deployment時) には、そのパッケージのリリース先の都合 (context) に合わせて、何らかの「限定」がさらに付加されます。使用するプロセッサやコンパイラ、プログラミング言語の決定などはそれらの「限定」の典型でしょう。
しかし、それらの「限定」は、「開発対象の領域」の開発で必然の「限定」ではありません。パッケージング・リリース時に付加された「限定」です。それら2種類の限定を混同して「開発対象の領域」での「必然の限定」としてしまえば、そこでの成果物を「out-of-context」な汎用品として利用する場合に、利用可能な範囲が狭められてしまいます。

さて、SDVが進めば、従来よりもさらに多くのプレイヤーが開発者として関係してくることになりますし、それぞれの成果物がcontextとは独立に開発される、つまり、「out-of-context」な汎用品として独立のサイクルを回しながら開発される、そんな部分の比率が圧倒的に多くなることは、すでに皆様もご承知でしょう。
ですから、「何かを決める」という場合には、その必然性が「開発対象の領域」の成果物固有のものなのか、それともそうではなくdeploymentで付加されたものなのかを見極めることが、これまで以上に求められるようになると言えます。また、必然性のない無思慮な決め急ぎは、もってのほかでしょう ^(※7)。

^(※7) 「今決める必要はないけれど、一見すると簡単に決められそうだから、決めてしまえ」という姿勢を、筆者はしばしば「決めたガリ」と呼んでいます。以前、とある大学で講演の機会をいただいた際、Q&Aで話が「必要もないのに決め急がない」につながったとき、「はぁっ? 何を言っているんだ、君は!」と、ある聴講者の方からお叱りをいただいたことがあります。「決めるということは、絶対的にpositiveなものであり、{能力・勇気・やる気} などの証」という価値観以外の根拠が見えてこない言葉をぶつけられるだけのやり取りに終始したのですが、「out-of-context」の開発の中では、「決めなくていいことを決めてしまうこと (特に範囲を狭めてしまう決定)」は、ここで述べているように、プラスに作用するとは限りません。その姿勢は、ISO 26262-8:2018 clause 6.4.2.4で示される、安全要件に関する「h) implementation free」という原則にも、結果的には反してしまうことになるでしょう。ましてや、「決めたいところは決めたので満足したよ、あとはよろしくね」なんてのは一番困ります (「決定」という権利を行使することに伴う義務や、権限移譲に伴う資源の引き渡しなどはどこに行ったのでしょう?)。残念ながら、integration現場では今でもしばしばあると各所でお聞きしていますし、昨今の不祥事の報告書での「上の決めたことは絶対」に類する風土問題がしばしば現れることは、「master-slave」という不適切な関係が、表現だけを変えて生き続けてしまうのではないか、と懸念せざるを得ない原因の1つなのです。言葉狩りだけでは意味がなく、根本的な姿勢の変化が求められるのです。

もちろん、パッケージング・リリース時のcontextに合わせて作られる部分もあるでしょうし、contextに合わせた最適化もゼロにはならないでしょう。しかし、毎回、筆者がAUTOSAR CP研修を行う際には申し上げていることですが、「contextあわせ」(個別最適化) の手間をかけても、異なるcontextではその結果を再利用できませんし、そこで必要となる検証などの手間は、全体としてのパッケージング・リリース (deployment) のボトルネックとなり、deploymentのサイクルを回すスピードを律速してしまいます。

このように、S10の中の「より汎化されたプレイヤー・アクターの巻き込みと相互の存在承認」を踏まえた (つまり、周囲に影響を与える部分をより改めてシステマチックに考慮した)、S8「より汎化されたプレイヤー・アクターの集団 (前節の ※3) による、複雑なシステムの取り扱い方や期待の進化 (作る側と利用する側双方において)」が、さまざまなところで登場することとなります。

なお、本節の冒頭では、以下2つを申し上げました。

1. ある意図の実現手段は、その下の階層ではさらにさまざまな実現手段にブレークダウンされていきます。手段間は必要があれば互いに連携しますし、各手段はさらに必要に応じてブレークダウンされ、下の階層が伸びていきます。逆に、下から上の方にたどっていけば、最後にはサービス利用者の意図 (あるいはサービス提供側の想定に対する、それを利用すると決めた利用者の想定に対する肯定の意思決定) にたどり着きます。
2. 「周囲から与えられた要求・制約と、その実現上の限定 (制約)」が「サービス提供側の想定」となります
   

そこからは、一つ面白いことが見えてくるかもしれません。それは、「設計・開発での各種意思決定」と「サービス利用者の意図 (あるいはサービス提供側の想定に対する、それを利用すると決めた利用者の想定に対する肯定の意思決定)」の間に、根本的な違いは見当たらない、ということです。そうすると、開発者とサービス利用者をまるっきり区別して考える必要はないというわけです。安全やセキュリティも含む、広義の「品質保証」やその他各種の意味での「ホショウ」の存在を考えれば、暴論に聞こえるかもしれませんが、一方、「ホショウ」などの具体的な内容は、提供・利用する「ミクロなサービス」のそれぞれで具体化されると考えればいかがでしょうか。多階層のサービスプラットフォームというインフラの性質を考えたら、もともと、userとproviderは、その中でのプレイヤーあるいはアクターの間の受け渡しの相対関係を表すだけのものですから、これまた自然なことと考えることもできます。

AI倫理など、これまでは考慮の範囲外だった要素にも今後直面することになります。「普遍の原則などを根拠としない、気分次第のアドホックな意思決定」を繰り返していては、「必要な変化」にすら気づくことすら難しくなるでしょう。もちろん、もはやそれでどうにかなったのはすでに過去の話ですが、さらに進めて、「AUTOSARを使いこなす」に限らず、多義性への考慮と、抽象化 (捨象と具象化の行き来) を交えて見直し続けることは、SDVというキーワードの意味ですらまだ変わっていくこの100年に一度の変化の中を歩むなかでも、矛盾の少ない一貫した戦略立案とその継続的改善に寄与することでしょう。

図1: 「視点」が高くなれば、広い範囲が見えてくる

現在提供している「AUTOSAR Classic Platform (CP) 入門トレーニング」では、AUTOSARというソフトウェアプラットフォームの技術面の解説をするだけではなく、その運用に役立つ上記のようなヒント・解説も含んでおります。コースにもよりますが、Q&A時間枠をご用意することも可能ですし、さらに踏み込んだコンサルティングサービスもご提供しております。

「AUTOSARを使いこなす」ことについて、その多義性を踏まえた見直しを行うことは、SDVの時代への備えにもつながります。
すでにAUTOSARを用いた開発のご経験をお持ちの方も、さらなる「使いこなし」のために、これを機にご受講いただいてはいかがでしょうか?