AUTOSAR Classic Platformの概要と導入初期にありがちな問題点：AUTOSAR Classic Platform導入の手引き（1/3 ページ）

[磯崎寿治（イーソル株式会社），EDN Japan]

　筆者はAUTOSAR 入門コーストレーニングの講師を担当している。本稿では、AUTOSARを扱ったことがない方に、AUTOSARとは何か、どのような構造になっているのか、またAUTOSAR 導入初期によくある問題点について解説する。

AUTOSARとは

　AUTOSARは、自動車業界におけるソフトウェア開発の効率化を図るために作られた車載ソフトウェア開発の標準である。その中には、Classic Platform（CP）、Adaptive Platform（AP）および、Foundation（FO）の3つの文書群が定義されている。

　かつては、走る／曲がる／止まるなど、制御系を処理する電子制御ユニット（ECU）を主な対象にするClassic Platformのみが定義されていた。自動運転（AD）や先進運転支援システム（ADAS）などハイパフォーマンスコンピューティングを必要とするECUをターゲットとしてAdaptive Platformが後に定義された。CPとAPのそれぞれをベースにしたECU間を接続することもあり、それらの相互連携のための共通規格がFoundationである。

　自動車用ソフトウェアに対する要求、開発規模、複雑さが年々増大していくなか、AUTOSARがそれらに対処するために開発の効率化を実現する方法の1つとしているのがソフトウェアの再利用である。AUTOSARでは再利用を推進するために必要な標準を定義している。

　一般にソフトウェアの標準といえば、ソフトウェアアーキテクチャを思い浮かべる方が多いと思われる。しかしAUTOSARは、ソフトウェアアーキテクチャの標準化だけではなく、メソドロジ（ソフトウェア開発作業の流れと入出力の形式の定義）および、アプリケーションインタフェース（API）の標準化も行っている。

　この定められた流れ、入出力形式、APIを用いることが再利用の推進につながる。本稿では、現在での量産開発の中心であるAUTOSAR Classic Platformを取り上げる。まずその開発作業の流れについて説明する。

AUTOSAR CPで標準化されているソフトウェア開発の流れ ―― メソドロジ

　さまざまな開発関係者やツールの間で設計情報を授受するためには、開発の流れ、つまりステップと、各ステップで行うこと、そして、それらのステップ間のつながり、各ステップで使用する設計情報の形態を標準化する必要がある。AUTOSARではこれらのことをメソドロジと呼ぶ。これらにより過去の開発成果物を再利用した開発が容易になる。

　AUTOSARでは、論理設計→システム設計→個別ECU設計の流れで設計を詳細化する。

　論理設計では、クルマの全体の機能を論理モデルとして表現する。その論理モデルを構成するソフトウェア要素をアプリケーションソフトウェアコンポーネント（SW-C）と呼ぶ。これらの論理設計を行った結果のイメージを図1に示す。

図1：論理設計のイメージ　出典：eSOL（イーソル）

　SW-Cからの入力／出力を行うアクセスAPI（AUTOSAR Interface／詳しくは後述）は標準化されている。またSW-CがどのECUに置かれても、SW-Cの内容を変更せずに済むような構成になっている。

　次に、AUTOSAR CPで定義されているソフトウェアアーキテクチャについて説明する。