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

今回は、前回お届けした現状の“AUTOSARの導入形態”をさらに掘り下げて、AUTOSAR導入の“現実”について見ていこう

[櫻井 剛 ベクター・ジャパン 組込ソフト部，＠IT MONOist]

前回のおさらい

　前回は、「AUTOSAR」に関して、その背景および課題、技術面や開発の流れの概要、そして、現状の導入形態について述べた。特に、導入形態の部分については、「一体、AUTOSARを導入するとはどういうことなのか？」あるいは、「どこまでを使えば、AUTOSARを導入したことになるのか？」といった疑問を抱かれた方も多いと思う。

　本連載の第2回では、これらの疑問に対していくつかのヒントを提示する。

予想もしていなかったこと

　実際の導入の前に、AUTOSARの膨大な仕様書に目を通したり、公開されている多くの情報を入手したりといったことは、一般的に行われている。

　しかし、それによって得られた「AUTOSARを導入するとは、こういうことではないか？」というイメージと、実際のAUTOSARの導入形態との間には、時として大きなギャップがあるようで、導入検討段階のお客さまからは、しばしば、

現在の導入形態はおかしいのではないか？

AUTOSARは、こうあるべきではないのか？

というような、筆者（ベクター）の立場では何とも返答に困る質問をいただくことがある。

　では、そのギャップはどこから生じるのだろうか？ 慣習や文化などの背景的な違いももちろんあるだろうが、恐らく多くは「実際にAUTOSARを導入してみて、初めて見えてくること」にあるのではないかと考えている。

　その代表的なものから4つを挙げてみよう。

1. すべてを自社で決めることができるとは限らない／自社でやるべきことが分かりにくい：
   例えば、ECUサプライヤーの立場では、自動車メーカーからECU Extract of System Description（EcuEx）が提供されるかどうか、EcuExの内容はどのようなものか、どのパラメーターを自社で決めることができるのか、といった自由にならない部分がある。これらはECUの種類ごと、あるいはプロジェクトごとに異なる可能性が高い。
   また、マイコンの選択も必ずしも自由に行えるわけではなく、AUTOSARベーシックソフトウェア（Basic Software：BSW）の影響を受ける場合がある。使いたいマイコン用で、かつコンパイラや対応機能などの条件が用途に合致したMCAL（Microcontroller AbstractionLayer：ハードウェア依存の各種ドライバBSW）が必要であり、何らかの代替策なしには、そのマイコンを使うことはできない。
   さらに、ソフトウェアコンポーネント（Software Component：SW-C）などを配布することは、AUTOSAR以前に比べて技術的には容易になっている。このことから、従来はそういったことをしなかった自動車メーカーが、方針を変える可能性もある（なお、“自動車メーカーが配布しなければならない”というわけではない）。従って、注意しなければ、同じものを複数の立場でそれぞれ用意してしまい、無駄が生じてしまう可能性もある（なお、ほかの立場や対象など多くの例が考えられるが、紙幅の都合により、ここでは割愛する）。
2. こうすれば確実、という万能の指針があるわけではない：
   例えば、AUTOSAR BSWには多くのパラメーターがあるが、その設定に関して、万能の指針やどのようなユースケースにも適用可能な究極の設定値の組み合わせというものは、存在し得ない。そもそも各種パラメーターは、さまざまなユースケースに対応するために用意されているものである。制約条件は、ユースケースごとに異なる可能性があることから、設定値の組み合わせも異なる可能性が高い。
   従って、あるユースケースでは有効な指針を作ることはできたとしても、それをほかのユースケースでは適用できないということもあり得る。
3. すべてを1人で把握することが難しい：
   一般に、局所的最適解が大域的最適解に等しいとは限らない。そして、規格がカバーする範囲の広さと、高い汎用性（あるいは自由度）により、ある1つの目的の達成手段が複数存在する場合もあり得る。
   これらのことから、できるだけ広い範囲を考慮に入れて判断を行うことが好ましい。しかし、AUTOSAR仕様書の分量という点だけを考えても、1人ですべてを把握することはほぼ不可能である。もちろん、把握といってもその度合いはさまざまであるが、時には仕様書の項目の背景に対する深い理解が必要とされる場合もある。
4. これまでに構築してきた「当たり前に利用できるもの」の存在の大きさ：
   従来の開発の中で当たり前のように利用してきたものが、AUTOSARではそのまま利用できない場合もある（各種運用マニュアルやチーム体制、設計指針、再利用可能なモジュールなど）。
   そして、それらをAUTOSAR用にあらためて再構築しようとしたときに、すでに構築されている“当たり前”が実は予想以上に大きな存在であり、再構築には多大な工数が掛かることに気付かされることも多い。
   また、それらを構築した経験がないような場合には、何もない荒野に放り出されたような印象を受けるかもしれない。事実、やみくもにもがく、あるいは身動きが取れなくなるという段階は、どうやら誰もが一度は通る道のようである。

　なお、これらは「汎用のものを個別のユースケースに当てはめる」という過程で見えてくる共通の課題でもある。前回の「開発の流れの概要」の冒頭で述べたように、特定の状況に当てはめるための「選択」や「このように使うという意思決定」は、個別に必要となる。

AUTOSARジャングル

　以下に、この状況をもう少し簡単にまとめる。

• 突然何に遭遇するかが予想しにくい
  （これまで過ごしてきた世界では想像もしなかったことへの遭遇）
• 現在いる場所からは全体像が見えにくい
• そもそも、全体像どころか自分がどこにいるのかさえ分かりにくい
• さまざまなモノが複雑に絡み合っている
• ところどころに落とし穴もある

　これでは、まるで前人未到のジャングルを探検するようなものであるが、多かれ少なかれそれが実態であり、実はベクターの社内でも、しばしば「AUTOSARジャングル（AUTOSAR Jungle）」という言葉が交わされる。

　数メートル移動するのであれば、地図やコンパスなどは不要であるが、地球の裏に移動しようとするのであれば、何らかの助けがなければすぐに迷子になってしまうだろう。また、ジャングルの中の移動と十分に整備された高速道路を利用した場合とでは、同じ距離でも考慮しなければならない対象が違うのも当然である（注意すべき対象が毒蛇なのか、あるいはスピード違反の取り締まりなのか、など）。

　さらに、ジャングルの中をさまよっていて、目的地に本当にたどり着けるかどうかが定かではないような段階から、高速道路の建設に着手するのは非現実的でもあるし、地球の北極点から南極点に移動するのに、地球を南北に貫くトンネルを造ろうとするような無理な近道は、むしろ遠回りになりやすい。

　開発サイクルを何度か回し（JasPar^［1］でも行われている）、目指すべき方向性と手の届く範囲のゴールをまずは定める（「あなたにとってのAUTOSARとは？」をはっきりさせる、あるいはもっと一般的な表現では「的を絞る」）。手の届く範囲は、必要に応じて、適切な手を借りて広げる（例えば、ベクターなどの持つ「経験」の活用など）。そして、実現したいことのうち、できることから1つ1つやっていき、その中で「個別の、やってみなければ分からないこと」の経験を積み重ねる。こうして、何とか道筋を付けてから、道幅を広げる。また、後に得られる新たな成果についても考慮し、時機を見て新たな道路への切り替えを行う（新たな成果：2011年現在もAUTOSAR仕様自体に新たな機能追加が行われている）。

　このような、一見すると当たり前で遠回りな考え方が、これまでとは異なる部分も多く、規模の大きくなったAUTOSARの導入の過程においては、結果的に最も近道となっている。そして、他人の近道は自分にとっての近道ではない可能性がある――これが、これまでの経験から得られたものである。

［1］Japan Automotive Software Platform and Architecture

http://www.jaspar.jp/（last access：20110218）

　もちろん、さまざまな理由によって、このような十分な準備期間を持つことは、容易ではないかもしれない。

　しかし、専用品よりも汎用品を選択する傾向が強く、その点において多くの経験を持っているといわれる欧州であっても、ベクターの顧客の多くは「AUTOSARの適用」、つまり「汎用のものを、実際の個別のユースケースに当てはめる」ということへの準備に長い時間と手間を掛けてきている。

　「汎用のものを、個別のユースケースに当てはめる」ということは、これまでに述べてきたように、必ずしも容易なことではない。そのため、「効率向上を目的としているAUTOSARなのだから、最初から効率化できるはず」と思い込んで進めてしまうことは大変危険である。特に、AUTOSARそのものに過大な期待を抱いて、通常の開発期間（あるいはそれよりも短い期間）で、準備なしにいきなりAUTOSARを導入しようとした場合には、開発者への大きな負担とプロジェクト進行上の大きなリスクが発生することが容易に予想される。また、いずれにしても、多少なりとも事前に予想しなかった事態は発生するものであるから、現実にはトラブルがあるものと覚悟して進めざるを得ない。

　こういったことを見ていくと、アセンブラからC言語への切り替えや、RTOS導入の際の苦労といった、遠い昔の記憶がよみがえってきた方も、少なくないのではないだろうか？