実際にAUTOSARを導入していくためには？：AUTOSARとは？（3）（1/2 ページ）
最終回では、AUTOSAR導入に向けた準備と効果的な導入の進め方について、そのヒントを紹介する。
前回のおさらい
連載第1回「What is “AUTOSAR”／AUTOSARとは？」では、AUTOSARに関して、その背景および課題、技術面や開発の流れの概要、そして、現状の導入形態について述べた。また、前回の連載第2回「Facts on AUTOSAR／AUTOSAR導入の現実」では、一体、AUTOSARを導入するとはどういうことなのか？ に関して、そのヒントを紹介した。
前回、最後に述べたように、AUTOSARの目指すものが実現されるということは、われわれエンジニアにとって、「早く家に帰れるようになる」ということを意味するはずである。しかし、AUTOSARは、このような意味を持ちながらも、本質的には“土台”という地味な存在であるため、導入の結果として、分かりやすい即時の効果を期待することは難しい上に、「適切とは限らない理解や期待」（あえて強くいえば、「誤った理解や過大な期待」）や、それに伴う「準備の不足」「掛かる手間の見積もり誤り」によって、かえって、多くの困難を招いてしまう可能性もある。
実際にどのような準備が必要なのだろうか？ そして、そこではどのようなことが効果的なのだろうか？
本連載の最終回である今回は、これらを考える上でのヒントを述べる。もちろん、“万能な解”は存在せず、具体的な対処は個別の事情を考慮しながら決めていくしかないのだが、本稿を参考にAUTOSAR導入をより効率的に進めていただければ幸いである。
どのような準備が必要か？ ：（1）AUTOSARに対する理解
AUTOSARに対する理解を深める上で、AUTOSARの仕様書に目を通すことは必須である。しかし、必ずしも仕様書の記載内容のすべてが、どの立場でも必要となるわけではない。
例えば、ECUの原価や開発工数の見積もりを行う人にとっては、各BSWのAPI仕様よりも、マイコンの選択において「MCAL（Microcontroller Abstraction Layer：ハードウェア依存の各種ドライバBSW）」が開発期間やソフトウェア関連費用に及ぼす影響の方が、はるかに重要である。
しかし、仕様書を読むだけで、こういったことを自力で理解していくのは容易なことではない。適切なトレーニングが開講されているのであれば、それらをうまく活用することが、近道となる（筆者が所属するベクターでもAUTOSARトレーニングを行っている）。
また、前回「実際にAUTOSARを導入してみて、初めて見えてくること」の1つとして紹介した、「すべてを自社で決めることができるとは限らない／自社でやるべきことが分かりにくい」については、仕様書を読むだけでは解決が難しいため、他社の動向を広く知ることが重要である。なお、その調査の際には、マーケティング面でのアグレッシブさが会社により大きく違うことについても、十分に注意されたい（ベクターは、この面では非常に慎重な立場を取っている）。
どのような準備が必要か？ ：（2）導入の道筋
AUTOSARの導入に当たっては、さまざまな道筋が考えられる。もちろん、これまでに構築してきた「当たり前に利用できるもの（既存の設計資産や開発体系）」の枠組みとはまったく別に、“全面的なAUTOSARの導入”のために、新たに構築し直すような進め方も選択肢の1つであろう。
しかし、その再構築の間、構築の対象を必要とするようなものの開発は、できない、あるいは、開発ができたとしても手戻りが発生しやすくなるなどの不利な点もある。また、前回述べたように、これまで構築してきた「当たり前に利用できるもの」の存在は大きなものであるため、その再構築に要する期間が予想よりも長くなってしまいやすく、関与する開発者を量産開発に投入できない期間も延びてしまう（当然ながら、導入検討作業そのものに対する、社内からの評価への悪影響も予想される）。
さらには、運用開始後に得られる「実際にAUTOSARを導入してみて、初めて見えてくること」も考慮に入れる必要があるため、再構築が完了したとしても、さらなる手直しが必要となる可能性は高い。さらに、仕様そのものの改定は当面続くため、その反映も随時必要となる。
このように、最初から「全面的なAUTOSARの導入の完全な姿」を目指して再構築を行ってしまうと、成果が得られるまでに多大な時間がかかってしまう可能性が高い。しかし、利用できるものは利用し、部分的に再構築していくような進め方であれば、何らかの成果が得られるまでの時間を相対的に短くできる。また、連載第1回で述べたように、現状のAUTOSARの導入形態の主流は、“必ずしもAUTOSARの全面的な導入ではない”という事実もある。
これらのことから、最初から完成度の高いものを新たに構築しようとするよりも、利用できるものは利用して、“部分的にでもまずは運用してみる”ことの方が、現時点（2011年前半の時点）では、より確実に成果を上げられるのではないかと考えられる。
また、部分的な運用といっても、さまざまな可能性がある。ここでも「すべてを自社で決めることができるとは限らない／自社でやるべきことが分かりにくい」ということが重要な鍵の1つとなるため、他社の動向の把握も大変重要である。
詳細はここでは割愛するが、部分的な運用としての代表例を以下に紹介する。
- OSとRTEを利用：
アプリケーションレイヤーを、AUTOSAR形式のソフトウェアコンポーネント（Software Component：SW-C）として実装する。
通信スタックなどは、状況に応じて、AUTOSARのものを併用する場合と、従来のものを併用する場合とに分かれる（従来のものを併用するための方法としては、Wrapperを作成するなどの対処法が考えられる）。
この場合の利点の1つは、“自動車メーカーの動向とは独立して、アプリケーションレイヤーの開発サイクルを多く回すことができるので実装方法のノウハウ蓄積が可能”という点が挙げられる。 - 通信スタックのみの利用：
他のECUとの通信面の互換性の確保のため、通信スタックのみを導入する。RTEを使用せず、OSEK/VDX OSのタスクや、従来のスケジューラ型での開発スタイルを適用する。
なお、他のECUとの通信面の互換性に影響するため、ECU単体でのAUTOSARへの移行を考える場合には、注意が必要となる（特にNMや診断など）。そのため、実際には、自動車メーカー主導での、ネットワーク単位での移行が主となる。 - 既存モジュールの最大限の流用：
他のECUとの通信面の互換性の確保や、自動車メーカーからのSW-Cの配布に備えて、通信スタック、OS、RTEなどの最小限のものだけを利用し、他は可能な限り既存モジュールを再利用したComplex Driverにて対応する。
なお、完全にAUTOSARベースでの開発に移行してしまうのではなく、当面は従来型の開発も平行して行われることを考慮した場合には、既存モジュールの再利用を最重要ポイントにおいたソフトウェアアーキテクチャを構築することも選択肢の1つである（AUTOSARは目的ではなく、あくまで手段であり、いまあるものをAUTOSAR形式に作り直す作業そのものに価値を見いだすことは難しい。そのため、Complex DriverにするためのWrapperを手間をかけずに用意できるようであれば、その方がよいと考えることもできる）。 - 最小限のMCALの利用：
MCALは、一般的にマイコンメーカーから提供されるものを利用することが多いが、それがまだ存在しないような場合もある。そのような場合には、新規開発量をできるだけ減らすために、最小限のMCAL（または、そのサブセット）だけを利用し、他はComplex Driverで対応する。
また、逆に、Complex Driver構成について検討を進めることで、将来的にMCALが開発期間やソフトウェア関連費用に及ぼす影響を小さくできる可能性がある。
なお、本連載の第1回でも述べた通り、「AUTOSARの導入」という言葉が意味するものは一意ではない。適用されるAUTOSAR仕様書のRelease Numberの相違などについても、当面注意が必要である。
また、もしも自社の取り組みを同業他社や関連する企業に知らせて意識合わせを早期に行うことが可能であれば、限られたリソースを効率的に注力すべき領域に集中させることができるかもしれない（水平的および垂直的コミュニケーション）。一部では既に行われているが、こういった情報の開示がもたらす利点は、業界全体で見た場合には想像以上に大きい可能性があるということを、ここではお伝えしておきたい。また、自動車メーカー、ECUサプライヤー、そして、ベクターのようなベンダーによる共同開発のような形も同様な効果が期待できる。
Copyright © ITmedia, Inc. All Rights Reserved.