What is “AUTOSAR”／AUTOSARとは？：AUTOSARとは？（1）（2/2 ページ）

開発の流れの概要

　AUTOSARの仕様書を読んだとしても、開発の流れの具体的なイメージを持つことは難しい。これは、そもそも、いわゆる「標準規格（および「汎用製品」）」は、「ある範囲においては、あんなこととこんなことが可能」という、枠組みとその中における一定の選択肢（明示的であるとは限らない）を提供するものであり、一般には、それを特定の状況に当てはめるための「選択」「このように使うという意思決定」と一体となって利用されるものだからである。もちろん、AUTOSARは「どの立場の人や企業が、どの作業をするべきか」「どの立場の人が使うツールが、どの作業をカバーすべきか」といったことの規定を、標準化範囲に含んでいない。

　とはいえ、具体的なイメージを把握するためには、実例は有用である。ここでは、ベクター製品などを使った場合の、実際のECU開発の流れを一例として紹介する。

　まずは、自動車メーカーとECUサプライヤー間のデータの受け渡しを、図5に示す。

図5　自動車メーカーとECUサプライヤー間のデータの受け渡し
※ベクター・ジャパンの資料を基に作成

　前述のとおり、自動車メーカーとECUサプライヤーの間の設計情報授受の媒体としては、EcuExが使用される。これは、車両システム全体の設計情報が記述されたSystem Descriptionのうち、特定ECUに関係する情報のみを抽出したものである。

　このEcuExの内容は、RTEやBSWの設定情報などを記述したECU Configuration Description（EcuC）に引き継がれる。

　次に、SW-Cの開発の流れを、図6に示す。

図6　SW-C開発
※ベクター・ジャパンの資料を基に作成

　ある機能を実現するために必要なSW-Cを手書きコードとして実装する際には、SW-Cの間をつなぐPortや周期イベントなどの各種イベント発生時に実行される処理であるRunnable Entityの定義および設定が主な作業である。これらを行った後に、Runnable Entityの実際の中身（一般的にはCの関数）の実装を行う。モデルベース開発（MBD）の場合には、コード自動生成のために必要な設定を行うことで、これらの多くが行われる。

　なお、Runnable Entityを起動するイベントやPortなどの情報は、後のRTEの設定の際に必要となるが、Runnable Entityの実際の中身（コード）は、この時点で作成されていなくともよい。

　また、SW-C構造やPortに関する定義が自動車メーカー側から提供される場合や、複数のMBDツールを併用する場合もあるため、この段階でのツール側での作業の流れは、import→実装→exportとなるケースや、最初から実装→exportとなるケースなど、さまざまなパターンが考えられる。

　次は、SW-C、BSWとRTEの統合のための各種設定の段階である（図7）。

図7　BSW／RTE設定
※ベクター・ジャパンの資料を基に作成

　RTEの設定に当たっては、「どのようなSW-CがこのECUに載るのか」という情報が必要となる。

　なお、高い汎用性を実現するために、BSWの設定項目は非常に多くなっている（1万を超える場合もまれではない）。しかし、そのうちの多くは、自動車メーカーからの指示により決まるのが一般的である。その指示の手段は、AUTOSAR XMLの場合もあれば、仕様書などの書面の形式の場合もあるが、当然ながら、後者では、この段階でより多くの作業時間が必要となる。

　また、汎用性の高いものを特定用途の要求に合わせるには、設定内容が適切か否かの判断が不可欠であるため、AUTOSARのみならず、車載組み込みソフトウェア開発全般にわたる広い知識が必要になる。また、ある動作を実現するための設定内容が一意に決まるとは限らないことにも、注意が必要である（例えば、OSのタスクに対するRunnable Entityの割り付けなど）。

　最終的に実装が完了したSW-C、設定が完了したBSWとRTEのコード生成とビルドが行われる（図8）。

図8　コード生成およびビルド
※ベクター・ジャパンの資料を基に作成

　なお、ランタイムのトラブル解析に当たっても、場合によっては、AUTOSARのみならず、車載組み込みソフトウェア開発全般にわたる広い知識が求められることもある。

AUTOSARの導入形態（現状）

　AUTOSARの概要については、公開されている仕様書やいくつかの解説記事、セミナーなどから情報を得ることができる。しかし、量産開発現場でのAUTOSAR導入の実態については、ごく限られた情報しか得られない。

　特に、導入が、「周囲の状況（あるいは、「一般的な使われ方」）」に左右される部分もあることに注意が必要である。このことについては次回以降も触れるが、ここでは、現在のAUTOSARの導入形態の全般的な状況について説明する。

　図2には多数のモジュールが登場しているが、現時点では、どのECUでもBSWやRTEのすべてが利用されているというわけではない。

　いくつかの例を挙げてみよう。

1. 通信スタックのみの利用：他ECUとの通信面の互換性確保のため、通信スタックのみを導入する。RTEを使用せず、従来のOSEK/VDX OSのタスクや、従来のスケジューラ型での開発スタイルを適用。
2. 通信スタックに加えて、OSとRTEを利用：自動車メーカーからのSW-Cの配布に備えて、OSとRTEも導入。
3. 既存モジュールの最大限の流用：他ECUとの通信面の互換性確保や、自動車メーカーからのSW-Cの配布に備えて、通信スタック、OS、RTEなどの最小限のものだけを利用し、ほかは可能な限り、既存モジュールを再利用したComplex Driverにて対応。
4. 最小限のMCALの利用：MCALは、一般的にマイコンメーカーから提供されるものを利用することが多いが、それがまだ存在しないような場合もある。そのような場合には、新規開発量をできるだけ減らすために、最小限のMCAL（またはそのサブセット）のみを利用し、ほかはComplex Driverで対応。

　もちろんこれらがすべてではなく、上記のそれぞれが完全に独立のものでもない。

　また、自動車メーカーからのSW-Cの配布があるのか否か、配布されるSW-CがどのBSWの提供するサービスを利用するのか、という想定に関しても実際にはさまざまである。従って、特に複数の自動車メーカーにECUを供給するような場合、コスト面の制約の下で、配布されるSW-Cの組み込みのためにどのようなBSWを購入することが必要かという判断は容易ではない。

　さらには、自動車メーカーとECUサプライヤーの間の設計情報授受の媒体であるEcuExについても、その中身をどこまで自動車メーカーが記述するのかという点においては、さまざまな運用が行われている。そして、EcuExの代わりに、CAN用DBCファイルなどの従来の形式を利用する場合も多い（「内容が同じであれば変換は可能」という道理である）。

　従って、「AUTOSARの導入」という言葉が意味するものは一意ではなく、「周囲の状況」「一般的な使われ方」などのさまざまな要因によって、「準備するべきこと」「準備しやすいこと」のそれぞれが左右される可能性がある、ということができる。

　さて、ここまでの内容をお読みになった感想は、いかがだろうか？ 特に、「AUTOSARの導入形態（現状）」の部分を読んで、「いったい、AUTOSARを導入するとはどういうことなのか？」と疑問を抱かれた方も少なくないのではないだろうか？ 残念ながら、与えられた紙幅も尽きてしまったため、次回以降に、その点についてもう少し掘り下げてみたい。（次回に続く）