　機能の実現のためのアーキテクチャを設計／検討する方法はいろいろありますが、例えば、まず｛入力、演算、出力｝の3つについて考えるようにすれば、そこにインタフェースも見えてきます（授受内容とタイミングも）。また、インタフェースまで含めた4つそれぞれについてどのようなバリアントが存在するのかを考えていけば、Variant Handlingも含めて一通りの検討ができますね。

　入出力や演算の内容はアプリケーションごとに異なりますので（車種、ECU、グレードなど）、標準化できるような部分ばかりではありません。当然個別に決めていくことが必要になる部分が出てきます。しかし、入出力で使用するインタフェース方式については、後述のようにAUTOSARでは標準化されたものが提供されていますので、それを利用できます。まずは、「他の処理」とつながるための手段である、インタフェース部分から見ていきましょう。

2.1 機能、それを実現する処理実行単位と、インタフェース

　ところで、「他の処理」とは何でしょうか。

　「他」という相対的なキーワードを見れば、その同列の対になるものとして「自」があると気付けるでしょう。つまり、「切り分けるか、まとめるか」の問題の形に書き直すことができることが見えてきます。まずはその切り口で進めてみましょう。

　何らかの「機能」を実現する際には、細分化（ブレークダウン）や、逆にまとめること（グループ化）がしばしば行われます。

　「機能」をどのような単位（粒度）で区切り、まとめるべきかについてはさまざまな考え方がありますが、その際に考慮すべき要因は、以下のようにいくらでもあります（以下の例の他にも、マクロ／ミクロ問わず、さまざまなところで他にいくらでも！）。

a）再利用／再配置のため

想定されているマッピング制約（意図や単位、境界、依存性）
- ECU群へのService／機能mapping（機能面での論理的な分離）
- ECUへのサブ機能マッピングの単位
- 実行コンテキスト分割の単位（例：Core／Machine／Taskへのソフトウェアマッピング、同期／非同期動作の切り分けなど）
既存のものから「変えられない」（レガシー問題／仕方なく再利用）^※2）
Variant handling
- 使用するもの（例：ハードウェア）に対する依存性の有無と、再利用頻度の差
提供するサービス面での差別化（例：グレード区分）、etc.

b）Safety Goal／ASILの差異（とセキュリティ）

c）開発者／委託先の作業分担の単位

開発作業の並列化
SW-Cの振る舞いの実装方法の相違：ハンドコードvs．MBD
資格単位（例：必要な技能証明、機密情報取り扱い区分）
コストセンター単位^※3）

※2）レガシー問題: 単純に「変えられない」という場合は、後付けでもいいので「変えられない理由」を考えるとともに、「いつ変えられるのか」「計画を立てられないか」と考えてみることで、「変えられない」の永久ループから抜け出せるかもしれません。また、「変えられない理由」が見えてくれば、「変えるきっかけ」も見えてくるかもしれません。

※3）コストセンター単位：効率的なソフトウェア開発単位とは整合しない場合があるため、要注意！（例：コンウェイの法則）

　ですから、AUTOSARでは、1つのSW-Cに複数の処理（RE）を持つことができるようになっています。

　こうしてみると、SW-C間、SW-C内（RE間）にそれぞれインタフェースが登場します。

1）SW-C間のインタフェース ※相手方の「他の処理」＝他SW-C（内のRE）
2）SW-C内のRE間インタフェース ※相手方の「他の処理」＝自SW-C内のRE

　AUTOSARのような標準規格を使わない場合には一般的に、登場したインタフェースのそれぞれについて、実装する側で都度、例えば以下のようなことへの対処を決めなければなりません（図2）。しかし、AUTOSAR CPを使うのであれば、文字通りSW-C開発者は、後述のインタフェースを「使うだけ」で解決します。