Facts on AUTOSAR／AUTOSAR導入の現実：AUTOSARとは？（2）（2/2 ページ）

そもそも、AUTOSARとは？
―― もう一度、見直してみよう

　では、なぜ地球を南北に貫くトンネルのような近道には、無理があるのだろうか？ いうまでもなく、地球は手で掘るには硬いという性質があるため、基本的には、掘り進むよりも、表面を進んだ方がはるかに楽である。

　ここで、AUTOSAR導入の適切な準備のために、いま一度、その基本的な性質について見直してみたい。また、多々ある「適切とは限らない理解や期待」のうち、その代表的なものも併せて紹介する（至極当然のものが多いことについてはご容赦願いたい）。

1. あくまで標準「規格」であり、それ自身は絶対的な強制力を持つものではない：
   しばしば、「これは、AUTOSARに対する違反ではないのか？」という質問をいただくことがある。これは、標準と名が付くものには法的拘束力があるのではないか、という不安によるもののようであるが、実際には、法規制や個別の契約上の指定事項となった場合などを除き、絶対的な強制力を規格単体では持たない（ISOなどと同様）。
   むしろ重要なのは、期待されるものが得られるかどうかである。例えば、AUTOSAR仕様書を部分的にしか適用していない場合には、期待した互換性を得られない場合も考えられる。
2. あくまで標準「規格」であり、標準「製品」ではない：
   AUTOSAR仕様書には多数の実装依存部分がある。また、その実装（製品）には、それぞれ仕様に対する拡張が加えられる場合がある。また、実装には品質など各種要因が付け加わる。従って、同じ規格に基づくものであったとしても、製品における差は存在するものと考えるべきである。
   このことから、複数のモジュール供給元からの製品を組み合わせて使用することは、単一の供給元からのものを組み合わせて使用する場合よりも難しくなる可能性がある（トラブルの解析と、その対処に要する時間など）。
   なお、AUTOSARには、いわゆるリファレンス実装（reference implementation）は存在しないが、自動車メーカーごとの実装としては存在することもある。
3. あくまで「手段」「道具」であり、「目的」ではない：
   AUTOSARを使うこと自体は、最終的な目的ではない。それを利用して、目的を実現するための手段あるいは道具である。
   当然、AUTOSARでは足らない部分があれば、それに対応するための処置を、AUTOSARで想定された範囲に対する「拡張」として個別に講じていく必要がある。
4. 汎用性は高いが、個別最適にできるとは限らない：
   さまざまなユースケースに対応できるようにするために、多くのパラメーターが用意されている。
   しかし、設計思想の異なるそれぞれのマイコンに対する、処理性能の限界を引き出すための個別最適化よりも、汎用性を相対的に重視したソフトウェアアーキテクチャとなっている。
   そのため、個別最適化がまったく不可能というわけではないが、専用品と同等の個別最適化が可能とは限らない。マイコンごとに個別最適化された専用品と比較した場合には、汎用品であるBSWは、処理時間やROM／RAM消費量などの面で見劣りする場合もあるが、これを無駄と考えるかどうかは、考え方次第である（汎用性とパフォーマンスのトレードオフ）。
   また、特定のユースケースに合わせ込むためには、多くのパラメーターを設定するための手間が発生する。もちろん、代表的なユースケースごとに、パラメーター設定内容のひな型のようなものを用意することは可能であり、作業効率向上のためにも一定の効果がある。しかし、それが容易あるいは可能な部分と、そうではない部分があること、そして、そのひな型が適用可能なユースケースには限界があることに、注意が必要である。
5. 汎用性は高いが、万能ではない：
   前項で登場した個別最適化された専用品で何とか機能が実現されていたようなものを、AUTOSAR BSW／RTEを利用して実現しようとした場合に成立しない、という場合が十分に考えられる。
   また、世の中のすべてのユースケースが想定されているわけではないので、前述のとおり、AUTOSARでは足らない部分があれば、それに対応するための処置を、AUTOSARで想定された範囲に対する「拡張」として個別に対処していく必要がある。
6. 新しいものであり、従来とは異なる部分がある：
   各種判断において、従来の考え方がそのまま適用可能とは限らない。判断基準そのものにも準備や見直しが必要である。
7. 当面は変化し続ける：
   2011年3月現在、AUTOSAR仕様書そのものの開発は継続されており、当面それは続く。当然、その仕様書に基づき実装された製品も変化することとなる。
   製品そのものも、一般的には新たに登場したものがある程度安定するまでには時間が掛かるうえ、使いやすさの向上などを目的とした機能拡張など、開発が継続的に行われており、進化し続けている（少なくとも、ベクターの組み込みソフトウェア製品である「MICROSAR」や、ツール製品である「DaVinci Developer」「DaVinci Configurator Pro」は、この種のものに該当する）。
   しかし、すべてが変化するわけではない。また、前述のとおり、当然「実際に導入してみて、初めて見えてくること」は経験なしには得られない。そのため、安定するのを待つ、あるいは長期的なベストを選択する、ということにこだわり過ぎてしまうと、足を踏み出すことができなくなってしまうので、ある時期で割り切ることも必要と思われる。
8. 「AUTOSAR対応」という表現は一意ではない：
   例えば、構成要素やRelease Numberなど、さまざまな面での相違が発生し得る。
   どのBSWコンポーネントを使う必要があるのか？ RTEは必須なのか？ どこからが「AUTOSAR対応」なのかという線引きは？ など、本質的には同じ内容の質問を、異なる表現で多数いただくが、AUTOSAR仕様書上ではこれらについては触れられていない。
   むしろ、AUTOSARという枠で考えて立ち止まるよりも、まずはその時点で対応が必要な個別のユースケースごとに、「目的を達成するために、どの構成要素が必要なのか？」ということを考え、判断していく方が現実的である。
   必要な構成要素を決めるための代表的なキーワードとしては、ほかのECUとの通信面の互換性、SW-C授受の面での互換性などが挙げられる（これ以上の詳細はここでは割愛する）。
   なお、「MCALが存在する」という言葉が意味するものも一意ではない。対応コンパイラ、マイコン固有の機能がどの程度サポートされているかなどの点で、意味がまったく異なる場合がある。また、同じEcuExと名の付くものであっても、中に含まれるデータの項目は一意ではない。
   一意に解釈できるものか、あるいはそうではないのかを注意深く見極めなければならない。
9. AUTOSARは不可欠か？：
   実際に、これまではAUTOSARなしで開発を行うことができたのだから、技術的成立性の面で必要不可欠かといえば、必ずしもそうではない。ただし、どの段階でどの程度時間を掛けることができるかという現実の制約の中でその成立性に目を向けた場合に、必要不可欠か否かの見方が分かれてくる。
   もちろん、すぐに狙った効果が得られるわけではない。これは「再利用」の効果を得ようとする場合、全般にいえることだが、必要な初期投資の回収は再利用の準備ができて、かつそれが実際に行われるときまで待たされることになるため、長期的視点が必要である（すぐに回収できないのであれば、必要不可欠ではないと判断されるかもしれない）。
   また、使用権許諾などのライセンス面の運用と、技術的な可能性とは分けて考えなければならない。たとえ、技術的に再利用できたとしても、ライセンス面ではそれが許されないという場合も考えられる。
   もちろん、教育や人材の育成も必要である。単発の投資ではなく継続的な投資の要素も忘れてはならない。

　AUTOSARは、本質的には「土台」という地味な存在であるため、導入の結果として、分かりやすい即時の効果を期待することは難しい。さらに、実際にAUTOSARを導入するに当たっては、今回紹介したように「適切とは限らない理解や期待」（あえて強く書けば、「誤った理解や過大な期待」）や、それに伴う「準備の不足」「掛かる手間の見積もり誤り」によって、多くの困難を招いてしまう可能性もある。

　しかし、適切な対処を取れるのであれば、過剰に恐れる必要はない。そして、何よりも、AUTOSARの目指すものが実現されるということは、われわれエンジニアにとって、「早く家に帰れるようになる」ということを意味するはずである。

　では、実際にどのような準備が必要、あるいは有効なのであろうか？ 次回は、それらの例をいくつか紹介していきたい。（次回に続く）