AUTOSAR Classic Platformの概要とRenesasのMCALソリューションについて

はじめに(AUTOSARとは)

AUTOSAR（AUTomotive Open System ARchitecture）とは2003年に車載電子システムの標準ソフトウェア基盤策定を目的として発足されたコンソーシアムであり、自動車業界におけるシステム設計方針の標準化を進めることを目標としています。

AUTOSARには欧州自動車メーカ、車載電装部品メーカを中心とした多数のメーカが参画しています。2025年現在では、350社以上の企業がパートナーとなり、各社の連携の上、世界規模でより良い標準化活動を進めることに成功しています。

今回の記事ではAUTOSARの概要から、Premium Partnerの1社でありマクニカが代理店を務めているRenesas Electronicsが提供しているソリューションについて紹介します。

なぜAUTOSARは必要か

昨今、自動車が多種多様な機能を持つようになり、搭載されるECU(Electronic Control Unit)は増加、E/Eアーキテクチャの進化や自動運転など高度な技術の普及に連れてソフトウェアはより複雑なものとなっております。また開発現場においては、OEMではサプライヤ毎の設計思想が異なることや、同じECUでも仕様が不整合になる点、サプライヤ側ではOEM固有の仕様に対応するためにOEM毎にソフトウェアを作り直し、ソフトウェアの開発工数は大幅に増加するなどの課題があります。

また最近ではSDV(Software Defined Vehicle)が普及し始めていることから、ソフトウェアがこれまで以上に重要となる一方で複雑性は激増し、それに伴い開発工数が増加することが課題として挙げられています。

こうした課題を解決するにあたり、開発手法(システム、フロー、インターフェイスなど)やソフトウェア規格を標準化し、ソフトウェアの再利用性を向上、将来的にはソフトウェアや方法論の標準を世界的に確立した上で、インテリジェントモビリティ向けのオープンE/Eシステムアーキテクチャを可能にすることなどをAUTOSARの標準化活動で目指しています。

AUTOSAR導入のメリット

AUTOSARの導入におけるメリットは、標準化されたソフトウェアフレームワークによるソフトウェアの再利用性向上、開発活動の円滑化、開発費用の削減にあります。

特徴的なのはAUTOSARで提唱されるミドルウェア構成です。従来の独自仕様ではアプリケーションの領域がハードウェアに大きく依存するもので複雑性は高く、アプリケーションとハードウェア機能を同時に開発する必要があることから、ソフトウェアの再利用性も低いものでした。

それに比べAUTOSARのミドルウェアはハードウェアとソフトウェアを分離した階層構造を提唱し、各層を分散開発でき開発時間及びコスト削減を実現できるほかに、各層ごとのソフトウェアの入れ替えも容易になる事から再利用性が向上し開発活動が円滑化。更にソフトウェアの再利用率が向上することで利用頻度も上がり、品質向上にも寄与することができます。

なお、この階層構造の詳細については後ほどの章で説明します。

また、各立場におけるAUTOSAR適応のメリットとしては、以下の効果があると提唱しております。
・OEM：同等なソフトウェアアーキテクチャであれば、どのサプライヤの開発物でも差し替えが可能。
・サプライヤ：同じECU/アーキテクチャで開発したソフトウェアを、どのOEMにでも再利用が可能。
階層の一部だけを開発/提供するビジネスが可能。
・ツールベンダ：AUTOSARのソフトウェア開発プロセスを埋め込んだツールを提供可能。
・新規参入者：標準化されたインタフェースを通じて新しいビジネスモデルを実現。
階層構造により、車載ソフトウェアの開発方法を理解しやすい。

なお、AUTOSARの仕様書自体は基本的に誰でも閲覧可能となっていますが、AUTOSARの規格を商用利用するためにはAUTOSARのパートナーへ加入する必要があります。パートナーシップは一部、年会費フリーのプランも存在しますが、基本的には年会費が必要となります。また、Premium Plusなど上位のパートナーになれば、標準規格へ意見を反映することも可能となります。

クラシックAUTOSARのソフトウェア構成について

AUTOSARのソフトウェアフレームワークについては大きく分けて以下の2つに分類され、それぞれが異なる目的や技術要件に対応しています。

その中で今回はクラシックプラットフォームの階層構造に絞って説明をします。

クラシックプラットフォームは、ソフトウェアの再利用性を高めるために、大きく分けて3つのソフトウェアレイヤに区別(抽象化)することができます。

・Application Layer：アプリケーション層
・Runtime Environment（RTE）：アプリケーションとBSWのインタフェース層
・Basic Software（BSW）：OS＋デバイスドライバ＋ミドルウェア層

その中でもAUTOSAR Basic Software（BSW）は以下の層に分割されます。
・Services Layer
・ECU Abstraction Layer
・Microcontroller Abstraction Layer（MCAL）
・Complex Drivers（CDD）

またBSWでは各層でシステムやメモリ、通信系など機能グループが分割されます。これらは1つの機能グループに対して、3つのレイヤを割り振ることで機能を実現していること示しています。

メモリの場合)Memory Services ⇔ Memory Hardware Abstraction ⇔ Memory Drivers

ここからはBSWの各層で何の機能が抽象化されているか、掘り下げて説明します。

Services Layer：サービス層

Services LayerはBSWの中でも最上位に属するレイヤであり、OS機能やネットワーク通信、メモリサービスなど高レベルなサービスを提供します。これらは実装面や上位層とのI/FにおいてマイコンやECUハードウェアには殆ど依存しません。

※I/O機能に関してはECU Abstraction Layerにカバーされています。

ECU Abstraction Layer ：ECU抽象化層

ECU Abstraction LayerはECUに依存する独自の機能を抽象化するレイヤで、上位のレイヤをECUハードウェアレイアウトから独立させる役割を持ちます。また、このレイヤはMCALと繋がりますがマイコンには依存しない為、周辺機器やマイコン内外部への接続(ポート、I/Fの種類)に関係ない周辺機器やデバイスにアクセスするためのAPI を提供します。

Microcontroller Abstraction Layer：マイコン抽象化層（MCAL）

MCALはBSWの中でも最下層に属するレイヤになり、マイコン内臓の周辺機能(レジスタ)に直接アクセス可能なドライバが含まれます。MCALの実装は完全にマイコンに依存するもので、上位のソフトウェアレイヤとマイコンを分離する役割を持ちます。

MCALで提供されるドライバ群の一例については、後ほどRenesasが提供しているドライバを例に説明します。

Complex Drivers（CDD）

CDDは他のBSWの階層構造では対応が難しい機能を実現するレイヤで、RTEからマイコンまでにまたがります。例えばAUTOSARでは規定されていない機能や、タイミング制約が非常に高い機能、マイグレーション目的の機能など特別な目的を持つ機能を統合する可能性を提供しています。そのため実装面、上位層のI/Fにアプリケーション、マイコン、ECUハードウェア全てが依存するレイヤとなっています。

以上の様に、ある機能/役割毎の階層構造を敷く事でソフトウェアの部品化を可能とし再利用性が向上し、BSWの領域の利用頻度が上がれば、それに伴い品質向上に貢献できます。

ただし、この階層構造に沿って、ソフトウェアを単に組み合わせるのではなく、ユーザ側が実際に再利用やソフトウェア開発の自動化など応用的に生かせなければ、真の効果は発揮されません。また、AUTOSARの標準化領域は1年に1度各領域に対して規格の更新が行われるなど、より良い標準化活動を進める上では階層構造の仕様も変動する可能性はあります。このことからAUTOSARを効果的に適応するためには一標準化活動者としてどのようにプラットフォームを生かして、より大きな恩恵を受けることができるかというマインドを持つことが必要であり、そうすることでAUTOSARの標準化活動はより活発なものとなります。

AUTOSARに対するRenesasのサポート領域について

Renesasは2004年7月からAUTOSARパートナーシップのプレミアムメンバーとして登録されており、標準化活動にも深く関与しているデバイスメーカです。

以下の赤枠では、実際にRenesasが提供を実施しているレイヤであり、マイコンはもちろんですが、それと共にMCALを提供していることを示しています。

このMCALは主要なAUTOSARリリースプラットフォームバージョン3.xおよび4.xに基づいて、車載MCU向けに生産準備の整ったSWコンポーネントを提供していることをRenesasでは謳っております。なお、BSWにおいてRenesasはパートナーベンダとも密な連携を実施しております。

 

以下の図は、提供されるMCAL SWコンポーネントのモジュールの例を示しております。

前述のMCAL機能説明で触れた通り、MCAL上のソフトウェアモジュールによって、マイコン上の周辺機能を動かす流れになります。(例えば、MCUのSPIを動作させる際、SPI Handler DriverによってSPI機能が動作します。)

これらはあくまで一例であり、対象となるマイコンによってモジュール構成やモジュール名は異なります。

なお、それぞれのモジュールの詳細説明につきましては、RenesasのHPよりご確認ください。

まとめ

• RenesasのHPでは車載向けMCU及びSoCのMCALとして無償評価用のソフトウェアドライバを提供しております。
• AUTOSARの導入検討や量産に向けた詳細なサポートをご希望される場合には、開発/量産ライセンスを提供しておりますので、各担当営業までお申し付けください。

 

出典

(1) AUTOSAR (Automotive Open System Architecture)

(2) Renesas MCAL ソフトウェアパッケージ

(3) Renesas MCAL概要