ソフトウェアの世界では、開発規模が大きくなる場合、再利用性や開発効率を向上するため、ソフトウェアプラットフォーム（SPF）を使用することが一般的です。WindowsやLinux、iOS、Androidに代表されるように、CPUなどのハードウェア資源を抽象化したSPF（※1）があれば、ハードウェアを意識することなく、SPF上で動作するアプリケーションだけを開発することが可能となります。さらに、ハードウェアに依存しないアプリケーションやライブラリを再利用することで、開発効率を向上できます。

※1 　オペレーティングシステム（OS）と呼ばれることが多いですが、AUTOSARのようにSPFの一部分をOSと位置づけることもあるため、本稿ではSPFと表記します。

一方、自動車に搭載される電子制御ユニット（ECU）は、自動車の中という特別な条件（温度や振動など）で使用されるコンピュータのため、使用されるマイコン（一般に車載マイコンと呼ばれます）が特別なものになります。車載マイコンは、耐久性や信頼性を向上させる必要があることから、一般的なコンピュータに比べて、搭載されるメモリや処理能力といった性能が低いです。そのため、SPFを搭載するほどの余裕がないことが多く、ECUの機能に応じて、C言語やアセンブリ言語を用いて、いわゆる「すり合わせ開発」が行われていました。しかし近年、自動車の安全性や利便性向上のため、急速にECUの高度化、複雑化が進み、車載マイコンの性能も上がってきました。これに伴い、車載ソフトウェアの開発コストも急増しています。
そこで、ECUの世界においてもSPFの導入が求められはじめ、2003年に設立されたAUTOSARという欧州を中心とした団体によって、車載ソフトウェア向けのSPFの標準仕様が策定、公開されました。AUTOSARは、“Cooperate on standards,compete on implementation（標準化で協調し、実装で競争すべし）”というスローガンを掲げ仕様のみを公開し、実装は各ソフトウェアベンダが行っています。
15年以上の活動と仕様のバージョンアップを経て、現在、AUTOSARは大きく分けて、制御システム向けのClassic Platform（CP）仕様と、自動運転システム向けのAdaptive Platform（AP）仕様の標準化を推進しています（本稿ではCPのみを対象としています）。AUTOSARの概要については、既にWeb上に多くの情報（※2）があるのでここでは割愛しますが、AUTOSAR導入により、マイコンを意識せずにアプリケーションの開発が可能となり、再利用性を向上した「組み合わせ開発」を可能としています。


※2
EDN Japan 　AUTOSARで変わる車載ソフトウエア開発
Tech Village　AUTOSARの目的とアーキテクチャ ―― 自動車業界に見る組み込みソフト開発効率化の取り組み
など

国内では、AUTOSARがすぐに浸透したわけではありませんでした。
一般にSPFを導入すると再利用性や開発効率を向上できますが、トレードオフとして、SPFを入れたことによるオーバーヘッドが生じます。例えば、従来のすり合わせ開発では、他のECUにデータを送信したいとき、マイコンが持つネットワーク機能CAN（Controller Area Network）を使って、アプリケーションから直接CANのレジスタを操作し、送信することができました。しかし、AUTOSARでは、CANに対する機能はすべて、BSW（Basic SoftWare）側に用意されており、アプリケーションからはCANを使用することさえ、隠蔽される構造となっています。まず、アプリケーションが、RTE（RunTime Environment）というアプリケーションとBSWを繋ぐためのインターフェースを呼び出すことでデータを送信し、BSW内でいくつかのモジュールを経由してCANバスに送信されます。そのため、アプリケーションが直接レジスタを操作していた実装と比較すると、処理速度やメモリ使用量といったオーバーヘッドは数倍になるとも言われています。

日本車は、欧州車に比べて安く多く売るビジネルモデルが多く、1台当たりの製造コストをいかに安くするかが重要となります。例えば、AUTOSARを導入するために、マイコンのスペックを1ランク上げる必要があり、ECUの原価が100円上がったとします。AUTOSARを導入しても、ECUの機能的な差が出るわけではなく価格に転嫁できないため、仮にそのECUを100万台出荷した場合、単純に1億円利益に差が出てしまうわけです。もちろん、再利用性や開発効率の向上によって、ソフトウェア開発コスト自体を下げることはできるかもしれませんが、大量生産品の場合、開発コストより製造コストの重みの方が大きいため、AUTOSAR導入の恩恵を受けにくいわけです。一方、欧州の自動車（特に高級車ブランド）の場合、製造コストを抑えることの必要性が比較的低いこともあり、AUTOSARは浸透し易く、デファクトスタンダードとなっていきました。

こういった状況により、AUTOSARが設立されてからしばらくの間は、国内でのAUTOSAR利用はあまり進みませんでした。しかし、ここ数年、欧州カーメーカー向けにECUを製造しているサプライヤでは、「AUTOSARで開発すること」をカーメーカーから指定されるケースが増えてきたことで、徐々に、国内でもAUTOSAR開発が取り入れられてきました。また、機能安全規格ISO26262の発行により、SPFを活用した機能安全対応のニーズが高まったことも、AUTOSAR普及の要因の1つと考えられます。

今後、自動車が持つ機能はますます高度化、複雑化が進むことが予想され、ソフトウェア開発コスト削減のため、AUTOSARの導入は避けられない状況になると思われます。次回は、当社のAUTOSARへの取り込み、AUTOSAR SPF開発の難しさなどについて紹介します。

第2回

:

富士ソフトのAUTOSARビジネスへの取り組み～AUTOSAR開発体験キットはなぜ誕生したか～
＜記事公開：2019年8月20日＞

第3回

:

AUTOSARによる開発～メモリ配置の仕組み　Memory Mapping（メモリ マッピング）～
＜記事公開：2019年10月29日＞

第4回

:

AUTOSARによる開発～Basic Softwareのコンフィギュレーション仕様の仕組み～
＜記事公開：2020年1月24日＞

第5回

:

AUTOSARによる開発～排他エリア（Exclusive Area）～
＜記事公開：2020年6月11日＞

第6回

:

AUTOSAR開発体験キット「メモリ保護編」発売
＜記事公開：2020年11月24日＞

第7回

:

TOPPERSプロジェクトの「athrill」を用いた評価ボードシミュレータ
＜記事公開：2021年4月2日＞

第8回

:

ルネサスエレクトロニクス社製MCALの使用方法
＜記事公開：2021年5月24日＞