本記事は、2024年11月14日に掲載した『AUTOSAR導入で「Code Generatorのしもべ」に?』の続編です。

AUTOSAR XMLの利活用やAUTOSAR導入で目指すべきところについて、弊社のSafety/AUTOSAR Senior ExpertでありAUTOSARの仕様策定にも参画している櫻井から紹介します。

前回のおさらい：「Code Generatorのしもべ」

前回の記事 "AUTOSAR導入で「Code Generatorのしもべ」に?"の続きです。

前回は、Classic Platform (CP) でのBasic Software (BSW) やSoftware Component (SW-C) を、さまざまな場面にあてはめつつ再利用 (reuse) しやすくするようにするために、AUTOSARでどのような対処・メカニズムが用意されているのか、そして、「場面」を表現する手段としてのAUTOSAR XML (ARXML) について解説し、併せて、ARXMLのような設定データが、「再利用可能なものに期待する振る舞い」や「それが投入されるコンテキストの情報」を多数含んでいるにもかかわらず、コード生成で使われるだけにとどまっていて、検証など他の場面での自動化にはまだあまり利用されていないという、大変残念な運用実態についてご紹介いたしました。

このような運用実態は、「AUTOSAR CPのSWアーキテクチャを取り入れただけ」「もともと持っていた基本SW機能を、AUTOSAR CP BSWに置き換えて実現しただけ」にほぼ等しいでしょう。BSWやRTEの設定にはかなりの手間がかかりますし、それはコストに直結しますから、すぐに「AUTOSAR導入にはメリットがない」と言われるようになりますが、「そもそも目指すところ」を設定した時点で、この結果・評価に行き着くことはシステマチックに確定しています。

実際、AUTOSAR CPに関する研修のQ&Aセッションでほぼ毎回 (驚異の90%超です) いただく質問は、「どこまでAUTOSARに対応したら、準拠したといえるのか?」です。この問いも同様に、いわゆる「やらされAUTOSAR」の発想が起点であり、「AUTOSARを利用してどのような効果を得るのか」という発想に切り替えなければ、同じ結末となることは不可避です (図1)。

AUTOSARの導入による効果としては、以下の2つがしばしば取り上げられます。

1. 再利用 reuse　
   ※SW-C再利用が中心ですが、再利用対象を「コード再利用」に限定する必要はない
   
   
2. 自動化 automation　
   ※ARXML活用 (→ 前倒し frontloading / 仮想化 virtualization にも)

1つ目の再利用 (reuse) については、「BSWを使っていれば、再利用はできている」という主張もありうるとは思います。
それで納得・満足する方を相手にする場合であれば、それで通用するでしょう (この発想はあまりにも旧世紀の「員数合わせ」的ではありますが)。

しかし、SW-Cやその設計情報の再利用、そして、

1. 再利用できるものを作る
2. 既存のものを再利用することで、特定場面での要件を達成する
3. 合理的ではない新規開発を阻止し、再利用を促す

の3つの観点で、まだやり残していることはないでしょうか? (図2)

「開発現場では実際には再利用なんてやっていない。再利用できるものはないんだよ」という声も時折耳にしますが^(※1)、上記の3観点がうまく回っていなければ、「再利用が機能しない」ことはやはり当然の帰結でしょう。再利用を機能させることができていない理由がどこにあるのか、そこに目を向ける必要があるでしょう。

また、2つ目の自動化 (automation) については、前回申し上げた「Code Generatorのしもべ」にとどまり続けたい、というわけではないのでしたら、まずは、機械的に処理可能 (machine readable) なデータ形式のインプット情報と、後続プロセスに着目するべきでしょう。

ARXMLはそのインプット情報の一形態ですが、それだけに限る必要はありません。
また、後続プロセスでは、典型的には各種検証 (特に回帰検証 regression verification) がありますが、文書化や変更の影響分析などを、インプット情報に基づき機械的に処理できる部分は、いくらでもあるはずです。ただし、「既存の汎用ツールでできること」だけにしか目を向けなかったとしたら、できることは極端に限られるでしょう。それはそのはずです。後続プロセスは企業ごと / プロジェクトごとに大きく異なる部分も多いのですから、「汎化と特化」を適切に使い分ける必要があります。「QCD」のような結果指標だけに目を向け、それを得るまでの過程を他人任せにしてしまうのではなく、過程に目を向ける必要もあります (特に自己開示なしで / 内情も明かさずに、「提案を」と求めるような姿勢では、カモにされる確率が高まるだけです)。

そして、ARXMLを特定の場面で徹底的に活用しようとするのなら、AUTOSAR Methodology and Template (M&T) に対する本質的な理解や、「何がモデリングされているのか」を見抜く力も不可欠です^(※2)。
AUTOSARを「単なる機能ライブラリ群」としてしかとらえようとなさらない方も時折お見かけしますが、そのような頑なな姿勢では、AUTOSARの利活用はより困難になるでしょうし、それでは、自動化の恩恵を得やすい「前倒し (frontloading)」や、自動化の加速手段の一形態でもある「仮想化 (virtualization)」のような効果を手にするのは難しいでしょう。
ましてや、上記などの効果をさらに得やすくするような各種実現戦略の継続的改善 (KAIZEN) や、「自分が欲しいものの、標準化コミュニティの力を借りた開発・保守」のようなものには手が届くはずもありません。

Software-defined vehicle (SDV) というキーワードが注目を浴びている今だからこそ、「再利用」や「自動化」などから恩恵を得るという、基本的・基礎的なことについて、本気で取り組む必要があるのです。もしかしたら、こういった見直しの予算が確保できる最後の機会かもしれませんね (1990年代後半のアセンブラからC言語への移行、2000年頃のCAN通信導入、2005年から2010年頃のAUTOSAR / Automotive SPICE / ISO 26262対応ときて、近年のサイバーセキュリティ対応とSDVというバズワードによる機会を逃したら、次は何があるでしょうか?)。
目の前のプロジェクトを片付け、そこでの近視眼的な収支だけ見て満足してしまい、気が付いたら世の中の進歩に置いて行かれてしまいます。
そんなことを繰り返す余裕は、もうそんなに残されていないはずです。

DevOpsやVirtualizationのようなキーワードを口にするだけして、結局のところは組織が分断されたまま連携しておらず個別プロジェクトと再利用・自動化がつながらないなんていう状況では、経産省・国交省による2024年5月発表のモビリティDX戦略での「SDVのグローバル販売台数における「日系シェア３割」の実現（2030年及び2035年）」は絵空事になるでしょう。「まずは目の前のプロジェクトを片付ける」という近視眼的な考え方だけではなく、「中長期的な課題に対して経営層の目を向けさせ、計画に落とし込ませること (自分事として扱い、単に指示待ちになってしまわないこと)」が不可欠です。

2025年もAUTOSAR日本事務局 (Japan Hub) としての活動は続けてまいりますが、特に今年は、これらについての啓蒙活動にも取り組んでいく予定です。

イーソル株式会社 ビジネスマネジメント本部
Solution Architect, Safety/AUTOSAR Senior Expert
櫻井 剛

【櫻井のMONOist連載はこちら】
AUTOSARを使いこなす（MONOist）

櫻井が講師を務めるAUTOSAR CPの入門トレーニング

以上、本記事では『AUTOSAR導入で「Code Generatorのしもべ」に?』の続編を櫻井よりご紹介しました。

イーソルでは、櫻井が講師を務める「AUTOSAR Classic Platform (CP) 入門トレーニング」を提供しています。
本トレーニングでは、AUTOSARというソフトウェアプラットフォームの技術面の解説をするだけではなく、その運用に役立つ上記のようなヒント・解説も含んでおり、オプションでQ&A時間枠をご用意することも可能です。

AUTOSARは導入の意図や理由を明確にしつつ効果を余すことなく得ることで、SDVの時代への備えにもつながります。
すでにAUTOSARを用いた開発のご経験をお持ちの方も、ぜひご受講ください。

• AUTOSAR CP入門トレーニング 詳細

コーポレートコミュニケーション室　Ｎ.Ｍ