はじめてのAUTOSAR導入で陥りやすい罠：AUTOSAR～はじめの一歩、そしてその未来（3）（1/3 ページ）

国内企業でAUTOSARを初めて導入する際の典型的パターンは2つある。「AUTOSAR導入準備の初期段階としての試作評価実施」と「量産開発を通じてのAUTOSAR導入」だ。今回は、これら2つのパターンの詳細と、それぞれどういった結末が起こり得るかについての考察を示す。

LINE

Hatena

　前回までは、AUTOSARによる標準化の概要を解説し、またその全般的な運用状況と当面の見通しをざっと述べてきた。今回からは、実際の導入の場面で身近に起こることに視点を移す。

典型的なパターンとそれに対する考察

　新しいことに取り組む場合でも、先行事例が存在するのであれば、その内容を把握しておくことは重要である。そこで、今回はまず“典型的なパターン”を見ていきたい。

※写真はイメージです

　国内企業が「AUTOSARに初めて触れる」という機会の典型的なパターンは、おそらく以下の2つになるだろう。

　以下に、まずこれら2つの典型的パターンの詳細を書き出す。内容についての考察はその後行うが、評価はあえて行わない。そして考察に関しては、今回はできるだけ皆さまにお考えいただきたいと考えている。

　このようなプロジェクトでは、まず予算の確保が行われる。その対象として想定されるものは以下のものであることが多い。

マイコン評価ボード、コンパイラおよびデバッガ：費用を抑えるために、既に所有するものの流用や、低価格な市販評価キットが候補となりやすい。コンパイラとデバッガの評価版ライセンスが付属することが重要視される傾向もある。情報が得やすく整理しやすいことから、比較的短時間で選定が終わることが多い
AUTOSAR組み込みソフトウェア製品（RTE／BSW）：MCALとそれ以外の購入は分けて行われることも少なくない
AUTOSAR開発ツール製品（AUTOSAR Authoring Tool、AAT）：上記組み込みソフトウェア製品のうちMCALを除く部分と同じベンダーが選ばれることが多い
AUTOSAR教育／トレーニング：定型の内容、かつ、ダウンロード型が多い（講師が説明をし続けるタイプのものであり、対話型ではない）

　また、評価期間は一般に数カ月から1年程度に設定される。この期間は、予算年度や各種評価版ライセンスの有効期間に由来していることが多い。そして、プロジェクトにおいて設定される典型的なゴールは、「AUTOSARが量産開発に適用可能かどうかを、小規模なサンプルアプリケーションで試してみる」である。

　このようなプロジェクトでは、試作品の初回納入期限と、量産開始スケジュールの制約が強い（あらかじめスケジュールが決まってしまっており、変えられない）。また、予算の確保が行われる対象として想定されるものは前述のパターンAと同様だが、以下の差異が見られることが多い。

AUTOSAR組み込みソフトウェア製品（RTE／BSW）：受注活動の早期の段階で、使用するマイコンが既に決まっていることも少なくないが、コンパイラの決定や、マイコン依存BSWであるMCALやOsの手配は後回しになりやすい。また、機能安全要求としては「ASIL D対応」という記述のみであることがほとんどである
AUTOSAR開発ツール製品（AAT）：開発チームメンバーの分担が決まっておらず、いつ、どのツールが必要になるのかが分からない。従って、支出面のリスク低減のために最小限のものを選択することが求められるが、同時に予算を確定させることも強く求められる
AUTOSAR教育／トレーニング：開発スケジュール面で余裕がないことから、トレーニングで全員の作業の手を止めてしまうことをためらってしまう。このため一部のメンバーのみに受講させる、あるいは試作スケジュールの後の段階（例えば、AUTOSAR組み込みソフトウェア製品の納品前後）に受講を延期する。場合によっては、受講者が周囲に教える形とする。まれに、「AUTOSAR規格は誰でも閲覧できるのだから自習できるのではないか」と、そもそも受講をしない