　2003年7月に公式に設立されたAUTOSAR（Automotive Open System Architecture）は、自動車業界全体における車載ソフトウェアの再利用や授受の促進により、自動車の電気電子（E／E）システムで増大し続ける複雑さへの対処を改善することを目的とした開発パートナーシップ（development partnership）である。約200の会員企業および団体から構成されている。

AUTOSARのWebサイト（クリックでジャンプ）

　AUTOSAR登場以前にも、OSEK/VDX（Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug / Vehicle Distributed eXecutive、公式Webサイト）やHIS（Herstellerinitiative Software、公式Webサイト）などにおいて、車載ソフトウェア標準化の取り組みが行われてきた。しかし、その適用範囲はさまざまな意味で限定的であり、実際には、自動車メーカーごとに異なる指定または推奨のプラットフォームや、ECUサプライヤ独自のプラットフォームが利用されてきた。ハードウェアなどの抽象化の方法もまちまちであった^※2）。

　ここであえて具体的な数字を述べるまでもなく、自動車の制御ソフトウェアの開発規模は爆発的な増大を続けている。再利用はそれに対する有力な対処方策の1つであるが、過去に行われてきたような企業単位あるいはプログラムコードレベルの取り組みよりもさらに一歩先のもの、例えば、コードよりも抽象度の高い概念の再利用への取り組みや、業界全体にわたる再利用なども求められている。最近注目度が特に高い、さまざまな形態／方式でのモデルベース開発もその1つである。また、検証などのプロセスにおけるさまざまなレベルでの自動化も、広い意味での再利用である。

　業界全体にわたる再利用については、効率向上のための作業分担の見直しや、共通の枠組みの定義も必要となる。例えば、アプリケーション部分の振る舞いを制御モデルとして記述し自動コード生成したとしても、それを動作させるための土台部分とのインタフェースが異なれば、モデルと土台部分のインテグレーションや検証は個別対応となる。また、各種自動化においては、まずその対象の作業モデルを規定することが必要となるが、成果物の形態や開発の流れの定義などが異なれば、やはり個別対応となってしまう。

　業界全体を長期的に見渡して考えてみると、個別対応が必要な場合には、再利用や自動化における費用対効果を相対的に押し下げてしまい、また再利用可能な機会も狭めることとになる。さまざまなことを可能とするために、土台、インタフェース方式、成果物の形態や開発の流れに関する共通の定義の存在が果たす役割は大きい^※3）。

　AUTOSARでは、ソフトウェアの再利用性向上に加え、バリアント対応の改善など多数の関連項目^※4）を対象として、以下の3つの分野において標準化活動を行っている。

（Software）Architecture^※5）
Methodology
Application Interface

　なお上記3項目については、次回、その概要を説明する。

　規格書は、AUTOSAR Premium Partner以上の会員企業が参加するWork Package（ワークパッケージ）における議論を経て作成／改訂される。議論は、メールや各種形態の会議（電話会議なども含む）で行われる。そして、その規格書および関連文書／データは一般公開されており、公式webサイトから入手できる。R（Release）4.2 Rev.1におけるファイル数は218個である^※6）。

　なお、AUTOSARでは実装面の標準化は行っていない（COMASSO^※7）では行っている）。また、「誰が何をするか」「どの部分について責任を負うか」といった、自動車メーカーとECUサプライヤが共同で開発を進める上で議論となりがちな部分（役割／責任分担など）についての具体的な規定は行わないが、その議論に役立つもの（例：開発の流れなどにおける共通理解）は提供されている。

注釈

※2）これは、車載以外の分野から参入された方々にとっては、前時代的なものと見えるようである。「本当ですか？」と口にされる方も多いが、現在もそのような形態の方がむしろ多いので注意すべきである。

※3）個別対応が最終製品における差別化や魅力の向上につながらないのであれば、個別対応から業界標準に積極的に移行することにはより大きな価値がある。もちろんこの議論は単純ではない。特に既存の対処により一部の問題が解決済みの場合には、得られる効果の変化分は少なくなってしまう。その時点では満足できるレベルまで問題が解決されてしまっているかもしれない。しかし、それでも将来について考える価値はある。少なくとも、将来いずれ移行することが確実なのであれば、移行まで個別対応を継続するための今後の累積投資（市場からの調達コストの差分を含む）も、移行の際の費用対効果の算定時には考慮すべきであろう。

※4）AUTOSARより配布されているRS Project Objective（Main Requirements）を参照。R4.2 Rev.1の場合、ファイル名は「AUTOSAR_RS_ProjectObjectives.pdf」である。

※5）AUTOSAR発行の文書中では単に「Architecture」と書かれており、Softwareの文言はない。

※6）ただし一部は圧縮済みのZIPファイルであり、展開すると総数はさらに増える。

※7）COMASSO（COMmon Autosar Standard SOftware） Association（公式Webサイト）。なお年会費は初年度500ユーロ、2年目以降2500ユーロ。