AUTOSARの“AR”はアーキテクチャに由来、アーキテクチャ設計にどう使うのか：AUTOSARを使いこなす（40）（4/4 ページ）

[櫻井剛，MONOist]

アーキテクチャ設計で「AUTOSARを使えるようになる」ということ

　AUTOSARをどのように学ぶかについては、本連載の第36回（そして、第11回と第12回）で取り上げました。

　AUTOSARにおける「必須知識」は役割というラベルというよりもむしろ「実際に行う活動／作業」によって異なること、「各活動／作業での必須知識」は「その活動／作業の計画書の理解」から導き出せることなどをご紹介してきましたが、「アーキテクチャ設計」ではどうでしょうか？

　もう想像がついた方もいらっしゃると思います。「Make or （Re）Use判断」がカギです。

　BSW群およびRTEについて学ぶのは、多くの方が感じておいでのように、容易ではありません。

　多数のモジュールと、膨大な仕様書がある中で、「何を優先的に学べばよいのか」という問いの答えは、「Make or （Re）Use判断」に必要なことから得られます。

　実際のMake or （Re）Use判断は、以下のようにブレークダウンできるでしょう（図6）。

• a1）マイコンのコアの外、特にECU外につながるための通信プロトコルが、ECUとしての通信関連要件（相互接続性など）を満たせること
• a2）マイコンのコアの外、特にECU内外の各種センサー／アクチュエータや不揮発メモリ（NVRAM）などを利用することができること
• b）SW-C実装時に利用できるRTEサービス（プログラミングのためのAPIが提供するサービス）
  ※SW-Cコード実装者にとっても必須の知識。なお、アーキテクチャ設計者にとってはRTE APIを知ることは必須ではありませんが、SW-Cコード実装者にとっては必須です。
• c）SW-C実装時に利用できるBSWサービス
• d）前述の各項（a〜c）の詳細（ブラックボックスの内側とでも表現すればいいでしょうか）

図6　アーキテクチャ設計でのMake or （Re）Use判断に必要な知識［クリックで拡大］

　上記のa）〜c）の各項は、「さまざまなレベルでのインタフェース」という観点から出てきたものです。

　それら、例えばBSWサービスを利用しないことになったのなら、結果的には不要な知識となりますが、アーキテクチャ設計者は、「Make or （Re）Use判断」の前に「利用しない」という判断ができるわけではありません。

　仮に先に「利用しない」と決めるのであれば、当然ながら「利用するべきだったのにそうしなかったのはなぜ？　それは合理的な判断といえるのか？」という問いを突き付けられることになります。

　ですから、基本的にはa）〜c）の各項は、アーキテクチャ設計者にとっての必須知識となるのです（システムレベルではなくソフトウェアレベルのみを扱うのであれば、a1）やa2）が必須とは限りません）。

　これは必須ではありますが、比較的特定／列挙が容易であり、また、一人でも把握することが可能な範囲と考えます（とはいっても、たくさんありますが）。

　しかし、個別プロジェクトで与えられる要求（自動車メーカーから与えられた要求など）には、インタフェースの背後にあるもの（ブラックボックスの内側）に相当するもの（先ほど挙げたd）に該当するもの）も含まれ、それに対応できるかどうかを判断することも求められます。

　典型例としては、CAN通信でのDLC（Data Length Code）チェックがありますが、DLCチェック方式のような基本的なものであっても世の中には実は数種類のバリアントがあり、AUTOSARで対応できるものは限られ、その判断が必要になります。

　これは実は容易ではありません。なんといっても、いくらでも詳細化できますから。

　突き詰めていけば、AUTOSAR文書全ての理解という無理難題に行き着いてしまいます。

　でも、ご安心ください。もちろん、「対応できるか否か」という判断が求められる頻度には差がありますから、「頻繁に判断が求められるものから学んでいく」、そして「判断に必要な情報にたどり着く方法を学んでいく」ということになります。

　AUTOSAR Adaptive Platform（AP）でもこの考え方は大きく変わるものではありませんし、もはやAUTOSARに限ったことではありませんね。

　……と、「アーキテクチャ設計」あるいは「実現戦略立案」というところを少し深く掘り下げてみるだけでも、実は「学び方」に関しても、こんなところまでたどり着くことができるのです。

　もちろん、「学んだ内容」とその運用結果に対する「確証」に直結するわけではありませんが、このようにして、「学び方」という方向性についてある程度「確証／確信」を得ることもできるのです。

本連載についてぜひご意見をお寄せください

　AUTOSARは、大雪の中の除雪に少し似ています。

　終わりがないように見える作業でも、筋の良い進め方（除雪、学び方、開発、インテグレーションなど）が見つかれば効率よく進められますし（かといって、一足飛びの進捗につながるわけではありません）、見つからなければ、泥臭くともひたすら手を動かすしかありません。泣きたくなることもありますが、そうしたところで状況は変わりません。まずは続けることが大切です。

　冒頭でも触れたように、本連載は開始当初、読者の皆さまからのご意見／ご要望を受けて双方向で進めることを目指していました。あらためて、「こんなことを知りたい」「こういうテーマを掘り下げてほしい」といったご希望があれば、ぜひお知らせください（筆者の櫻井宛のメールアドレス［[e-mail]、＠は大文字になっているので小文字に変更してください］でも、LinkedInでも歓迎です）。

　この連載は「AUTOSARを使いこなす」と銘打っていますが、筆者一人が使いこなせても意味がありません。

　皆さまのニーズというインプットがあってこそ成立する――そんなアーキテクチャに支えられています。

　どんな小さなご要望でも構いません。筆者の個人事業の屋号「particle」には、小さな存在（課題や目標）でも決して切り捨てることなく、つながりを見いだしていく、という思いを込めています。

　例えば、抽象化には、地に足がつかず具象化できないものもあれば、抽象度の上げ下げが自在にできるもの（それを可能にするアーキテクチャに支えられたもの）もあります。もちろん、目指すところは後者です。

　ぜひ、AUTOSARやアーキテクチャに関して、「もっと良い進め方はないだろうか？」と一度立ち止まって考えてみてください。

　「もうやることはない」「成り行きに任せればいい」という思考停止、切り捨て、決め付けではなく、次につながる問いを一緒に見つけられればうれしく思います。

筆者プロフィール

櫻井 剛（さくらい つよし）particle代表（2025年より） 兼 イーソル株式会社 ビジネスマネジメント本部 ソリューションアーキテクト兼Safety/Security シニア・エキスパート

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