　そして、ECUの規模が大きくなればなるほど、RTEのコード生成、そして、ECUソフトウェアのビルドに必要な時間は長くなっていきます。この規模のECU向けRTEのコード生成には、多量のメモリを搭載した高速PCを使っていたとしても、現在でも数時間かかりますし、ビルドも同様です（インテグレーター泣かせですね）。

　なお、RTEの設定内容のカギになるものの一つが、インタフェースという「相互関係」です。その解析が必要になることから、コード生成時間の増加ペースは、SW-C数やRunnable数に対してリニアのオーダーを超えることになります。小分けにできれば、RTEコード生成時間もビルド時間もだいぶ減らせる、だからこそ、「モノリシック」なECUソフトウェアを「小分けにできる」ことに価値が生まれるのです。

　……と納得するのはまだ早いです（納得してしまった方、だまされてはいけません！）。

　というのも、コード生成やビルド時間だけなら、PC性能が上がればいずれ時間が解決してくれるかもしれないからです。逆に言えば、手間をかけて仮にコード生成時間を短縮できたとしても、その効果を享受できる期間はさほど長くないでしょう。

　……と納得するのはまだ早いです（再び、だまされてはいけません！）。

　ECUの規模の増大のペースと、PC性能向上のペースの競争という側面もありますね。

　では、「PC性能向上が勝つ！」への一点賭けでいいのでしょうか。その検討のヒントになるのが、「AUTOSARへの期待」です。

　本連載の第2回と第3回のおさらいをしてみましょう。

　AUTOSARの要求群の最上位は「Project Objectives」文書です（表1）。そこには、「効果の寿命の短い最適化」はありません。


ID	説明（英文）	説明（和訳）
[RS_PO_00001]	AUTOSAR shall support the portability of software	ソフトウェアの可搬性の支援（R19-11にて小改定）
[RS_PO_00002]	AUTOSAR shall support the scalability to different architectures and hardware variants	異なるアーキテクチャやハードウェアのバリアントに対するスケーラビリティの確保（R19-11にて小改定）
[RS_PO_00003]	AUTOSAR shall be domain agnostic	広い範囲のドメインへの対応（ドメイン非依存）（R19-11にて小改定）
[RS_PO_00004]	AUTOSAR shall define an open architecture for automotive software	自動車用ソフトウェアにおける、オープンアーキテクチャの1つを定義
[RS_PO_00005]	AUTOSAR shall support the development of dependable systems	ディペンダブルシステムの開発の支援
[RS_PO_00006]	－	（R19-11にて削除: 天然資源の持続可能な利用の支援）
[RS_PO_00007]	AUTOSAR shall enable the collaboration between partners	パートナー間のコラボレーションの実現（R19-11にて小改定）
[RS_PO_00008]	－	（R19-11にて削除: 自動車用ECUの基本ソフトウェア機能の標準化）
[RS_PO_00009]	AUTOSAR shall support applicable international automotive standards and state-of-the-art technologies	適用可能な、自動車関連の国際規格や到達技術状況（state of the art）の技術への対応支援
[RS_PO_00010]	AUTOSAR shall support data exchange with non AUTOSAR systems	Non AUTOSARシステムとのデータ交換への対応（R19-11にて追加）
表1　AUTOSAR R20-11 Project Objectives