車載ソフトウェアの標準仕様AUTOSARとは？基礎説明から導入時のポイントまで

百年に一度の大変革期を迎えている自動車業界において、技術の進歩は目まぐるしい現状となっています。今や自動車は”走るコンピュータ”と言われることもあり、約200個のECU※が搭載されています。そのECUを動かすのに欠かせないものがソフトウェアです。

技術が進歩する一方で、ソフトウェアが複雑化することが大きな課題になっています。この課題を解決すべく、自動車の制御ソフトウェアの標準化活動を実施し、車載電子制御ユニット用の共通標準ソフトウェアアーキテクチャを策定、確立したのがAUTOSARと呼ばれるソフトウェア規格です。今回の記事では、自動車ソフトウェアの標準仕様であるAUTOSARについて説明します。

※Electronic Control Unitの略称。車載に搭載される電子制御をするユニットを指す。

AUTOSARとは

正式名称AUTomotive Open System ARchitecture (以下、AUTOSAR) は、2003年に発足した自動車業界のグローバル開発パートナーシップです。活動の目的は、インフォテインメントを除く領域で、車載電子制御ユニット用の共通標準ソフトウェアアーキテクチャを策定、確立することになります。このAUTOSARが目指す標準化の背景には、自動車業界が直面していた深刻な課題があります。かつて自動車の機能は主にハードウェアによって実現されていましたが、技術の進化に伴い、現代の自動車は「走るコンピュータ」と化しました。1台の車に搭載されるECU（電子制御ユニット）の数は100個を超えることも珍しくなく、ソフトウェアのコード量は爆発的に増大しました。これにより、開発は複雑化し、コストと期間が増大する結果となりました。さらに、開発したソフトウェアを別の車種へ利用することが難しく、非効率的になった課題も顕在化しました。

AUTOSARはこの課題を解決するために生まれました。その核心は、ソフトウェアとハードウェアを切り離す「抽象化」という考え方にあります。AUTOSARの標準化されたプラットフォームを介することで、アプリケーションソフトウェアは特定のハードウェアに依存することなく開発できます。その結果、一度開発したソフトウェアコンポーネントを異なる車種やECUで再利用することが可能になり、開発効率と品質が飛躍的に向上しました。このようにAUTOSARは、複雑化する一方の車載ソフトウェア開発に秩序と効率をもたらすための不可欠な存在となっています。

AUTOSARがもたらす「3つの標準化」という大きなメリット

AUTOSARがもたらす具体的なメリットは、主に以下の「3つの標準化」によって実現されます。これにより、コスト削減や開発効率の向上はもちろん、サプライチェーン全体での連携強化にもつながります。

1. 開発方法の標準化

AUTOSARでは車両全体のアーキテクチャや各ECUの設計を統一された記述形式（方法論）で行います。これにより、開発者は個々のECUのハードウェア仕様の違いを意識することなく、本質的なソフトウェア開発に集中できます。結果として、開発プロセス全体が効率化され、ヒューマンエラーの削減にも貢献します。

2. アプリケーションインターフェースの標準化

アプリケーションを構成する個々の機能（ソフトウェアコンポーネント、SW-C）間の接続ルール、すなわちインターフェースが標準化されます。これまではコンポーネントごとに接続仕様を確認・定義し直す手間が必要でしたが、AUTOSARではその作業が不要になります。これにより、コンポーネントの組み合わせや再利用が格段に容易になり、開発効率を大幅に向上させることが可能です。

3. レイヤードアーキテクチャ（ソフトウェア構造）の標準化

AUTOSARの最大の特徴ともいえる階層化アーキテクチャ（レイヤードアーキテクチャ）により、アプリケーションとハードウェアが明確に分離されます。この標準化されたソフトウェア構造のおかげで、特定のECU向けに開発したアプリケーションを最小限の修正で別のECUへ再配置・再利用することが可能になります。これにより、コスト削減と開発期間の短縮が実現できます。これら3つの標準化は、単に社内の開発効率を高めるだけではありません。メーカーとサプライヤーが「AUTOSAR」という共通言語で対話できるようになるため、グローバルなサプライチェーン全体での協業が円滑になり、最終的には顧客の多様なニーズへ迅速に応えることにも繋がる、非常に大きなメリットです。

では、これらのメリットを実現するAUTOSARの核となるソフトウェアアーキテクチャは、具体的にどのような構造になっているのでしょうか。先ほど挙げた3つの標準化の中でも、特に「レイヤードアーキテクチャ（ソフトウェア構造）の標準化」は、AUTOSARの根幹をなす概念です。このアーキテクチャは、役割が明確に異なる以下の3つの階層で構成されており、この構造こそが、ソフトウェアとハードウェアの分離や部品の再利用を可能にしています。

AUTOSARのソフトウェアアーキテクチャ構造

AUTOSARのアーキテクチャは、次の3つの階層で構成されています。

①Basic SoftWare (以下、BSW)

上層ソフトウェアの機能を動かすための必須サービスを提供する標準ソフトウェアモジュールです。ほとんどの場合、BSWには以下に述べるアプリケーション層のような機能は存在せず、その名の通り、ソフトウェアの基本となる部分です。

②Run Time Environment (以下、RTE)

アプリケーションソフトウェアのECU内、ECU間通信をネットワークトポロジーに依存せず抽象化するための中間層です。BSWと以下に述べるアプリケーション層を仲介する役割をしています。

③アプリケーション層

アプリケーションソフトウェアを構成するコンポーネントをまとめた総称です。RTEから送られてきた情報に従って、制御を実施します。例えば、自動車のライトスイッチを操作するとライトが点灯する。ドアロックボタンを押すとドアがロックされる。この”点灯”や”ロック”を最終的に制御しているのが、このアプリケーション層になります。

AUTOSAR導入方法

AUTOSARの導入方法として最も一般的なものが、ソフトベンダーが提供しているソフトの購入です。安価なもので数万円から規模が大きくなると数千万円するものもあります。ただし、3章で記述したすべてのアーキテクチャ構造を使用する必要はなく、実現したいことに応じたものを抜粋し選択することが重要です。

AUTOSAR導入時の3つのポイント

本章ではAUTOSAR導入時に考慮すべきいくつかのポイントから3つを厳選して紹介します。

①標準「規格」であり、それ自身は強制力を持つものではない

準拠しなければならない規格があるとそれに違反しないように設計しがちですが、法的拘束力はなく、法規制や個別の契約上の指定事項となった場合を除いては、規格単体では強制力を持ちません。あくまで1つの指標という理解で設計していきましょう。

②標準「規格」であり、標準「製品」ではない

AUTOSAR仕様には多数の実装依存部分があります。また、その実装(製品)には、それぞれ仕様に対する拡張が加えられる場合もあります。したがって、同じ規格に基づくものであったとしても、製品における差は存在するものと仮定した上での設計が必要になります。このことから、複数のモジュール供給元からの製品を組み合わせて使用することは、単一の供給元からのものを組み合わせて使用するよりも難しくなる可能性があります(トラブル解析など)。まずは製品要件を理解し、必要最大限活用できるよう設計していきましょう。

③「手段」「道具」であり、「目的」ではない

設計中によく陥りがちですが、AUTOSARを使うことが最終的な目的ではありません。AUTOSARを利用して、最終的な目的を実現するための手段あるいは道具です。当然、AUTOSARでは足らない部分があれば、それに対応するための処置を、AUTOSARで想定された範囲に対する「拡張」として個別に講じていく必要がある。目的を忘れず、柔軟に設計することが求められます。

AUTOSAR設計ツール(AutoCrypt ASL)

AUTOSARに準拠した設計ツールは多くありますが、今回は弊社のAutoCrypt ASLを紹介します。 SDV、自動運転技術の発展により、ECUに組み込まれるソフトウェアの重要性がますます高まっています。AUTOSARの登場でソフトウェア開発にかかる負担は軽減されたものの、セキュリティを実装することは難しく、未だに企業の課題として残っています。Autocrypt ASLはAUTOSARフレームワークベースのソフトウェアに最適化されたセキュリティソリューションです。AUTOSAR Runtime for Adaptive Application(ARA)を提供し、Adaptive AUTOSARの安定的な通信をサポート、Add-on機能を通じて効率的なモジュール制御と強力なセキュリティ機能をサポートします。本ツールは設計時のみでなく、多くの企業課題となっているセキュリティ実装することにも役立ちます。

AutoCrypt ASLの構成

AutoCrypt ASLはAdaptive AUTOSARのFunctional Cluster（FC）と、Add-onで導入できるECUのハードウェアリソースとFunctional Cluster間の円滑な通信をサポートするフラットフォームサービスレイヤーセキュリティとオペレーティングシステムレイヤーセキュリティで構成されています。安全なコミュニケーションをつかさどるARA::COMとARA::IAM、暗号関連演算と鍵管理の機能があるARA::CRYPTO、パケット検査やフィルタリングを行うARA::FW、セキュリティイベント情報を受信・モニタリングするARA::IDSMを構築・提供します。また、AUTOCRYPT独自の技術で開発したAdd-onセキュリティ機能で、より強力なセキュリティ体制を構築することも可能です。製品の詳細についてはAutoCrypt ASLをご覧ください。

さいごに

AUTOSARについて、目指す目標や構成・導入ポイントを記述し、設計の際のツールも紹介しました。まだまだ”コンピューター化”する自動車に携わっていくのであれば、ソフトウェアは切っても切れない関係になると思います。機能の増大や複雑化に負けることなく、AUTOSARのような規格や、今回紹介させて頂いたツールをうまく活用することで効率的かつサステナブルな製品開発を一緒に実現していきましょう。ソフトウェア設計に今から携わる方や行き詰ってしまった方の一助になれば幸いです。