AUTOSARの“AR”はアーキテクチャに由来、アーキテクチャ設計にどう使うのか：AUTOSARを使いこなす（40）（3/4 ページ）

[櫻井剛，MONOist]

アーキテクチャ設計で「AUTOSARを使う」ということ

　さて、もう少し細かく見ていきましょう（図4）。

図4　アーキテクチャ設計の詳細（Automotive SPICE観点）［クリックで拡大］

　アーキテクチャ設計で、ブレークダウンされた要件や振る舞いをある構成要素に割り当てる際には、それを、新規開発するのか、あるいは、既存成果物を使うのかの判断を行うことになります。

　この判断を、私はMake or （Re）Use判断（make or use／reuse判断）と表現しています。

　既存成果物を使うという（Re）Useは、以下に分けられます。

• Reuse：既存の要素（既に持っているもの）の再利用
• Use：持ってはいなくても調達可能なものの利用／採用

　もちろん、既存のものを使う上で何らかの制約が課せられることも少なくありませんので、アーキテクチャ設計や要件自体の見直しが行われることもあるかもしれません。

　そして、小分けにした要件を割り当てられた要素間には何らかのコミュニケーションがあり、インタフェースと接続の定義が必要になります。

　上位のアーキ階層で定義したI/Fを、このアーキ階層のどのI/Fに割り当てるのか、そして、このアーキ階層内の要素間のI/Fをどのようにするのか、これを決めていくことになるでしょう。

　もちろん、I/Fを用いた振る舞いという動的側面と、API定義のようなI/F静的構造定義、そして、I/F間の接続／経路設定も必要です。

　ここまで、「狭義のアーキテクチャ設計」（あるいは、アーキテクチャ設計という言葉は、より汎化して「実現戦略立案」でもいいと思います）について解説してきました。

　そして、「既存成果物を使う（Re）Use」の一部を占めるのが、「AUTOSARを使う」ということになります。

　AUTOSARの標準化範囲が「実現戦略立案」の中でどの位置を占めるのかを簡単に整理したのが、図5です。

図5　アーキテクチャ設計における、AUTOSAR Classic Platform（CP）での標準化範囲［クリックで拡大］

　AUTOSARで標準化されたソフトウェア部品群は、要件や振る舞いの実現の一部を担ってくれます。

　そして、同じく標準化されたECU間通信プロトコルは、ECU間のI/Fの一部を担ってくれます。

　E/E（電気／電子）システムの構成要素の面だけではありません。

　人や組織の活動／作業についても、ひな型のようなものとしてAUTOSAR Methodologyで定義／標準化された活動／作業を基に組み立てていくことができ、またその活動の一部を自動化したものを、ツールとして利用することができるのです。