車載エレクトロニクス AUTOSARとMCALについて

2020年9月29日

はじめまして、ソフト設計課の松嶋と申します。

今日は車載エレクトロニクス開発で頻繁に耳にするようになったAUTOSARとMCALについてお話させていただきます。

１．AUTOSARとは

AUTOSAR(オートザー、AUTomotive Open System ARchitecture) はソフトウェアのモジュール化とインタフェースを定義し、自動車に搭載される各システムとそのネットワークから構成される組込みソフトウェアの構成の策定を目的とした自動車業界のグローバル開発パートナーシップです。2003年に発足しました。

従来の車載ソフトウェア開発はハードウェアに依存するため、メーカー毎にソフトウェア実装の変更が必要でした。

これに対しAUTOSARでは、ハード⇔アプリケーションソフト間に標準のレイヤを設け、ハードウェア変更等の影響を抑える構造を定義しました。

例えばパワーウィンドウアプリケーションについて、MCUやユニットなどハードウェアを変更しても、AUTOSARに対応していればソフトウェアを書き換える必要はありません。
これによりメーカーはアプリケーション開発に注力が可能となりました。

このAUTOSARには2つのプラットフォームが存在します

①　Classic Platform

OSEK(Open system together with interfaces for automotive electronics:車載電子機器用の公開インタフェース及びシステム）をベースとした組込みリアルタイムECU向けの標準規格です。

②　Adaptive Platform

上記クラシックプラットフォームに追加する形で新しいユースケースに対応するため開発されました。

１．１　Classic Platformについて

Classic Platformでは、大別してアプリケーション、RTE、BSWの３つの抽象レイヤで構成されます。

(1)　アプリケーション層

最上層のアプリケーションレイヤ(層)は、通常複数のソフトウェアコンポーネント（Software Component：SW-C）から構成されます。アプリケーション開発の視点では、下位層の詳細な知識を要求されてないため、ハードウェア非依存のアプリケーション開発が可能です。

(2)　RTE層

層の二番目はRTE（Runtime Environment）レイヤです。この層には役割が二つあります。1つはSWコンポーネントに手を加えることなく、SWコンポーネント間の接続を繋ぎ換えることです。

車両内で複数のECUを接続して一つのシステムとして見た場合（例えば、センサー、アクチュエータ、演算部）、SWコンポーネント間の接続が必要です。AUTOSAR以前はソフトウェアコンポーネントを書き換える必要がありましたが、この事により、アプリケーションレイヤのトップダウン型開発が、従来よりも容易になりました。

ソフトウェアコンポーネントの処理実行を管理するRunnable Entityというものがあります。これをOSのタスクとして構成するのが、もう一つのRTEの役割です。

またFranca Interface Description Language (IDL)を使うことによってGENIVI等の非AUTOSARのシステムと結合することも可能です。

(3)　BSW層

ベーシックソフトウェア（Basic Software）の略で、全メーカー/サプライヤー共通の基盤を担う、基本ソフトウェアです。OS、通信（CAN、LIN、Ethernet等）、メモリ、診断、入出力、モード管理などの各種機能を提供するソフトウェアモジュール群から構成されます。しかし、BSW／RTE共に実装依存の部分は少なからず存在し、仕様拡張も度々行われているため、同一仕様であっても、相違がある可能性があり注意が必要です。

１．２　Adaptive Platformについて

Classic Platformに追加する形で新しいユースケースに対応するため開発されました。

たとえば、高度自動運転などでは以下の図のような機能が求められると考えられています。

このような機能を実現するため、アプリケーションの動的配置等で演算パワーが必要となります。
AUTOSARは、それらを提供するために、現在AUTOSAR Adaptive Platformの標準化を進めています。これはPOSIX標準を中核としたシステムでPOSIXサブセット経由でアプリケーションから利用できます。

２．MCALについて

MCAL (Microcontroller Abstraction Layer)とは、そのAURTOSAR規格で定義されている、MCU内蔵の周辺機能や、メモリにマッピングされた外部デバイスへ直接アクセスするソフトウェアモジュールで、上位のソフトウェアレイヤをMCUに依存させないようにします。前述の３つの抽象レイヤのうちBSWレイヤの最下層、MCU abstractionがMCALに当たります。

簡単に言ってしまえば、基本ソフトウェアOS、通信等の各種機能を提供するソフトウェアモジュール群のことであり、ドライバー、APIと理解すれば判りやすいと思います。

(1)　大手ベンダーでのMCALサポート

車載MCUの大手ベンダー各社では開発プラットフォームにMCALパッケージをプラスした環境を用意しています。以上から、車載サプライヤーであれば問題なく使用できると考えて間違いありません。

(2)　ツールベンダー

主要自動車関連ツールベンダーでサポートされています。

３．まとめ

国内では、CPUの高性能化に伴うコスト面の課題からAUTOSARの採用は遅れていましたが、欧州市場向けでの対応が求められることや、SPF（ソフトウェアプラットフォーム）を活用した機能安全対応のニーズの高まりから、徐々に普及してきました。

今後、自動車の高機能化、複雑化が進むことは必然であり、ソフトウェアの開発コストダウンのため、AUTOSARの導入は避けて通れないと考えています。

私は現在、車載マイコンのFAE（Field Application Engineer）として仕事をしており、AUTOSAR/MCALを含め、常に車載エレクトロニクスの最新情報を収集して、お客様に最適なソリューションを提供するため邁進しております。車載エレクトロニクス開発案件等でご興味をお持ちなら是非WTIにお問い合わせいただけると幸いです。

【関連リンク】

【関連ブログ】

WTIメールマガジンの配信（無料）

WTIエンジニアが携わる技術内容や日々の業務に関わる情報などを毎週お届けしているブログ記事は、メールマガジンでも購読できます。ブログのサンプル記事はこちら

WTIメールマガジンの登録・メールアドレス変更・配信停止はこちら

WTIの技術、設備、設計/開発会社の使い方、採用関連など、幅広い内容を動画で解説しています。