SDVに向け改めてAUTOSARを「ひとごと」ではなく「自分事」にすべし：AUTOSARを使いこなす（38）（3/3 ページ）

車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載第38回は、2025年7月の「AUTOSAR & JASPAR Japan Day」について報告するとともに、SDVの開発を国内自動車業界が推進していくためにAUTOSARをどのように活用すべきかについて提言する。

[櫻井剛，MONOist]

AUTOSARを「効果を生むために導入／利用する」という考え方が重要

　AUTOSARは、共通化という意味での標準化だけではなく、その先の再利用や自動化を意図したものです。また、それらの効果を得やすくするためのさらなる継続的改善によって、より大きな効果が得られる可能性があるものです。

　繰り返し申し上げていますが、自動車のソフトウェア開発規模は指数関数的に増大しています。前回もご紹介しましたが、SDVで今後必須となる対処としては、以下のようなものがあります。

• 1）機能する「標準化／協働／再利用」とその徹底：「廃品利用の再利用」や「使えたら使う」ではなく。また、Variant Managementは必須
• 2）自動化と、その先の徹底的な実施（CI／CD［継続的インテグレーション／継続的デリバリー］、DevOps）：例えば、以下のようなもの
  • 文書化、分析、コード生成、検証など：機械的に処理できるようにするための形式化と、それと整合するプロセス構築が不可欠
  • 仮想化：自動化の恩恵をさらに得るために、仮想化環境を活用し、また、N増し＆加速
  • 前倒し：できるだけ高い抽象度の活動で論証できるようにし、また、具象化された活動が大量に発生する場合は極力自動化

　AUTOSARを使うということを、キャッチアップ、欧州勢に追い付くだけで十分だという考え方では、そもそも「導入の効果」を引き出すことは難しいでしょう。AUTOSARに振り回されることになるだけです。AUTOSARを「効果を生むために導入／利用する」という考え方が非常に重要なのです。

　図4の交点、そしてブレークイーブン、投資回収を目指そうとするのなら、再利用や自動化による効果が不可欠です。

図4　AUTOSAR導入のフェーズ［クリックで拡大］ 出所：筆者作成のAUTOSAR研修資料

　もしもそれをせずにいたとしたら、BSWなどのコード自動生成をしてもらうためだけにコードジェネレータに仕えるようなものです。実際にBSWの設定パラメータは非常に数が多く苦労なさっている方が多数おいでですが、そんな苦労をしてコードを自動生成させるだけでは、ある意味、連載第33回でご紹介した「コードジェネレータのしもべ」状態です。

　もちろん、各社／各プロジェクトのプロセスはみな違いますから、「製品を買ってきて導入したらそれだけで再利用や自動化の効果が得られる」というわけではありません。この時点から、効果を生み出すための、ユーザー側での個別の取り組みも必要になるのです。

　ところで、BSWが持つ各種そして多数の設定用パラメータは、そのBSWがどうふるまってほしいのか、そして、周りとどのようなインタフェースでつながるのかを表したもの、マシンリーダブル（機械可読）な形、機械的に処理可能な形でモデリングしたもの、モデルなのです。

　BSW以外の情報についても同様です。AUTOSAR XMLで表現されたBSW設定情報だけに限る必要はありません。ただ、BSW設定としてコード生成だけに使うのではなく、その後の各種テストの自動化、テスト仕様書やテストケース、テストスイートの自動生成と自動実行、そして文書化などの形（これらはSDVでも特に重要視されるCI／CDの重要な要素群です）で活用しない手はないでしょう。もちろん、先ほど申し上げたように、既製品のツールなどを買ってきただけでは、その効果は限定的です。業務改善、現場への合わせ込みのためには、各種スクリプトやプラグイン開発なども不可欠でしょう。

　さらにそれら、再利用や自動化などの恩恵をより得やすくするために、仕事のやり方自体を変え、改善していく。もちろん、仕事のやり方、プロセスは、人が回すものである以上、人財育成も絡めながらです。

　こうすることで、指数関数的に増大する規模に立ち向かえるようにする。

　このように考えていくことで、開発においてAUTOSARを活用できるようになるものだと考えますし、欧州ではこのような考え方で既に長年取り組んでいる一部の自動車メーカーやサプライヤーなどの企業が存在します。2015年頃まではそういった事例紹介も、AUTOSAR Open Conferenceなどでよく見かけましたが、もはやある意味当たり前になってしまって、最近は見かけません。

　ですが、一部ではそのくらい当たり前のことになっているということは、強調したいと思います。

　これらによって、車両システムに加え、その開発活動を幅広くモデリングし、プラットフォームやソリューション全体のライフサイクルおよびサプライチェーン全体を俯瞰（ふかん）した形での自動化、（さまざまな抽象度での）再利用、境界の見直しによる活動の最適化と、「規模」に対する制御の機会を拡大することを目指す、と、そのように考えてよいかと思います。

　AUTOSARは変えられないもので、ただ従うことしかできないというものとお感じになっているかもしれませんが、それは実はそうではありません。

　そのような見方はまるで「黒船」扱いで、従うか対抗するかなんて極端な議論に誘導されかねないものです（オープンソースvs.プロプライエタリ／AUTOSARという、どちらかしか使わないという単純な選択肢しかないように誘導する議論には、しばしばその中間の選択肢に関する「だまし」が潜んでいます）。

　AUTOSARは、自分たちで使い続けるプラットフォームの規格です。

　使いやすい形に持っていきたいとお考えなら、標準化活動に参加することもできますし、安心して使い続けようとするなら標準化活動への参加はむしろ不可欠だとも考えます。

　例えば、参加せず「規格のユーザー」と割り切るのもありですが、その場合には、皆さんがお使いになっている機能が突然変更／削除されて困るということも起き得ますので、そういったことを防ぐように働きかけることや、また最低限のこととして、継続的に状況を確認することはできます。

　しかし、そのような活動への参加の決定は所属する組織がその組織として行うのであって、組織に所属する人間は従うだけ、という考え方もあるでしょう。一見正しいと思えますが、そう決めつけるのはまだ早いです。

　皆さんはその組織の一部です。組織の上の方々は以下のように考えているかもしれません。

「現場からは、参加が必要だという打ち上げはなされていない」

　そう考えるとしたら、理由は何でしょうか？　組織の中で、声を上げないことで、自らを分断し、また組織の中での出来事を「ひとごと」にしてしまっていませんか？

　「自分事」にしてみませんか？　標準化などのコミュニティー活動についても同様です。

　そうすることで、自動車業界での皆さんの活動の価値、もちろん、コミュニティーベースの活動に対する価値や、皆さんが生み出したソフトウェアに対する価値と同様に、「評価する側」と「評価される側」の一方が勝手に決めるのではなく、健全な形に見直されていくのではないかと考えます。

　いかがでしょうか？

次回に続く

　次回は2025年9月末ごろの予定です。AUTOSAR Japan HubやUG-ETの活動に関するアップデート、今回ご紹介した講演に関するご報告などをと考えています

　なお、UG-ETの国内活動を立ち上げ準備中です、ご興味ある方は筆者の櫻井宛（メールアドレス：[e-mail]、＠は大文字になっているので小文字に変更してください）までご連絡ください。

筆者プロフィール

櫻井 剛（さくらい つよし）イーソル株式会社 ビジネスマネジメント本部 Solution Architect & Safety/AUTOSAR Senior Expert／AUTOSAR日本事務局（Japan Hub）

自動車分野のECU開発やそのソフトウェアプラットフォーム開発／導入支援に20年以上従事。現在は、システム安全（機能安全、サイバーセキュリティ含む）とAUTOSARを柱とした現場支援活動や研修サービス提供が中心（導入から量産開発、プロセス改善、理論面まで幅広く）。標準化活動にも積極的に参加（JASPAR AUTOSAR標準化WG副主査、AUTOSAR文書執筆責任者の一人）。2024年よりAUTOSAR日本事務局（Japan Hub）も担当。