AUTOSARとは？／What is AUTOSAR？−2015年版−（後編）：AUTOSAR〜はじめの一歩、そしてその未来（2）（3/4 ページ）
「AUTOSARとは？」という問いにはさまざまな切り口での答えがある。今回は、前回に引き続き、「AUTOSARとは？／What is AUTOSAR？−2015年版−」の後編として、AUTOSARの標準化の対象である「（Software）Architecture」「Methodology」「Application Interface」の3項目の観点から説明する。
Methodologyこぼれ話：ツールによる設定作業は「お絵描き」じゃない！
AUTOSAR XMLの作成は、一般にAUTOSAR Authoring Tool（AAT）に分類されるツールやシステムにより行われる。
なお、コードを書く作業ではなく、これらのツールを使った設定作業に対して、残念なことに「遊んでいる」「お絵描き」などとやゆされたとお聞きすることも多い。
ツールに入力するというその操作の背景には「設計」という概念的な作業が存在しているのであり、単なる「お絵描き」では決してない。そもそもAUTOSARでは、新たに実装するよりも、設定によりさまざまなケースに対応するというアプローチをとっている（Frakes他による分類でのGenerative Approach※4）に相当）。しかも、その設定内容は形式化されたものであり、後の自動化の可能性を秘めている。設定という作業の意味や価値を周囲が理解し認めることは、AUTOSARの導入や高度なソフトウェアの再利用を円滑に進めるには不可欠であると考える。
なお、「AUTOSAR XML」や「ARXML」とだけ表現されている対象のものは、ほぼ何も特定されていないのと同じである。その中に何が含まれるかを示すことが重要であり、例えば「ECU Extract」のように表現すべきである。
また基本的には、Methodologyがはじめから存在していて仕事の分担を決めたのではない。現実の開発の流れや仕事の分担（境界線）というニーズが、Methodologyを作ったのであり、そのニーズによって更新されていく。裏を返せば、この規格を作った会員企業たちは、この開発の流れをおおよそ受け入れているということでもある。自社の開発の流れとAUTOSAR Methodologyが大きく異なるとしても、そこには見直しの良いヒントがあるかもしれない。両者の違いに対して、はじめから批判的な態度で向き合うことで、改善の機会を失うのは少々もったいないように思う。
Application Interface（AI）
いくらAUTOSAR Software Architectureを採用し、SW-Cの、ECUへの配置に対する依存性やハードウェア依存性をなくしたからといっても、「ある機能の実現に必要な情報は何か、そして、それはどのような表現がなされるか」ということに対する依存性は残る。表現については、単純なスケーリング変換で済めば簡単だ。しかし、そもそもの物理量の次元が異なればスケーリング変換では対応のしようがない。
AUTOSAR Application Interfaceは、自動車向けアプリケーションにおける、以下の各ドメインおよび各ドメイン間の典型的なインタフェースを、AUTOSAR Interfaceの形でまとめたものである。
- ボディおよび快適機能
- パワートレイン
- シャシー
- 乗員および歩行者保護
- マルチメディア／テレマティクス／HMI
なお、AUTOSAR Software Architectureを採用したからといって、必ずしもApplication Interfaceを採用しなければならないというものでもない。現時点では、AUTOSARを採用している自動車メーカーであっても、Application Interfaceを採用していない場合も少なくない。AUTOSARは、分け方にもよるが、小分けにして導入することができるものである。
注釈
※4）Frakes他：Metrics and Models, ACM Computing Surveys, Volume 28, Issue 2, pp. 415-435, 1996.http://dl.acm.org/ft_gateway.cfm?id=234531&type=pdf&CFID=65178775&CFTOKEN=89447410
Copyright © ITmedia, Inc. All Rights Reserved.