　今後、機能統合や分散配置の観点だけではなく、安全やセキュリティの観点から機能配置の見直し（ひいては通信路に現れる情報の見直し）が必要になることも予想される。ECU内通信であったものがECU間通信となることもあるだろうから、管理すべき主対象が、通信マトリクスではなくSW-C間インタフェースに移行していくのは自明である（通信マトリクスは従の存在となる）。加えて、再利用性向上やテストなどの自動化推進（前ページの図1の矢印B）、工数増大ペース抑制（同矢印C）のためには、類似インタフェースのバリアント増大の抑制も重要である。それこそがAUTOSAR導入でまず目指さなければならない「共通の目標」である。繰り返しになるが、AUTOSARは、運用の過程でそれらの効果を生み出すことを可能にし支援するもの、つまり「enabler」でしかない。

　これは、ECUサプライヤ側でも同様であろう。自らの設計資産であるSW-Cのインタフェースや実装バリアントの管理体制を整えていかなければならない。

図2　AUTOSAR Methodologyの概要～Workflow（クリックで拡大）出典：AUTOSAR R4.2 Rev.1 TR Methodology、Figure 2.2相当、AUTOSAR_MMOD_MetaModel.eapより作成したものに筆者追記

　また、ECU SWインテグレーション作業（図2：AUTOSAR Methodologyにおける「Integrate Software for ECU」の段階）で行われることを明らかにしなければならない。AUTOSARにおけるインテグレーションは、もともと、「BSWを作りたい人がBSWを作り、システム設計をしたい人がシステム設計を行い、SW-Cを作りたい人がSW-Cを作る」という活動の結果の成果物間の、「つじつま合わせ」の要素が大きい。もちろん、暫定的な成果物からスタートすることも多いので、変更対応すなわち動的なプロジェクトマネジメントやテーラリング能力も必要となる。実際には、テーラリング結果は、ECU開発プロジェクトごとに差が生じるであろう。

　インテグレーターとして一人前になるためには、リアルタイム性保証などのソフトウェア関連技術の他に、プロジェクト管理（受け取った上流成果物の問題点をフィードバックし解決につなげていくことや、仮定を確定に積極的に置き換えていくことも含む）、品質保証、機能安全など、広範囲の技能が必要である。ISO 26262-2：2011 Clause 5.4.3のCompetence Management要求の観点からも、育成し必要な能力があることを立証するためには、必要なスキルを明確にすることが不可欠である。DIAに基づく分担や、責任の所在の明確化のためにもそうである。

　特に、機能安全やセキュリティの側面では、インテグレーションという作業に多くのことを委ねていることだけはご理解いただきたい。例えば、実行順序やタイミング制約の保証、メモリ保護、診断機能などは、インテグレーション作業により振る舞いや特性が確定される。いまだに誤解が少なくないが、ISO 26262でのFreedom from Interference（FfI）も、各要素単体の作り込みで決まるような絶対的／固定的なものではなく、要素の相互関係を考慮したインテグレーション作業を経なければ確定させることができない相対的なものである。

　なお、インテグレーション作業は主にECUサプライヤで行われる作業であるが、自動車メーカー側で行われる場合もある。そうならば、自動車メーカーでも把握しなければならない。また一見すると、BSWベンダーの方がこの作業に向いているように思われるかもしれないが、インテグレーション作業においては、用途やユースケースに応じた「判断」「意思決定」が必要である。もしもBSWそのものをよく知っていたとしても、その用途では何が優先されるべきなのか、などの判断力がないのであれば、作業を完了させることはできない。丸投げは困難であり、共同作業までが限界であろうから、関係する人財の「育成」から逃れることはできない。少なくとも要求や判断基準を提示する能力は必要になるからだ。

　加えて、優秀なインテグレーターの数はまだ非常に少ないことから、貴重な人材の流出の防止策も必要になるだろう。また、特に機能再配置が頻繁に行われるようになれば、いずれはインテグレーション作業に対する対価（あるいは保険料率のようなリスク引き当て）の算定見直しも必要になるだろう。それらの対応においては、最低限、インテグレーターやその作業の価値を正当に評価することも必要となろう。インテグレーションは、決して「くっつけるだけ」という言葉の持つニュアンスから連想されるような、軽い楽な仕事ではない。