01

運転機能の高度な進歩は、次世代の車両のネットワークアーキ テクチャーやECU間の相互作用を大きく変えることでしょう。 ドライバーアシスタンスシステムが発展を続け、高度な自動運転のレベルに到達すれば、レーダー、LiDAR、各種カメラなどの 先進的なセンサーが必要になります。これらのセンサーは一体化した環境モデルを車両に提供します。それは車載ネットワーク上に膨大なデータが伝送され、それらを短時間で処理しなければ ならないことを意味します。データ転送に関してだけでも、高い データスループットを低遅延で実現できるネットワークアーキ テクチャーが必要です。また、センサーデータを統合するためには、専用ハードウェアを利用して複雑なアルゴリズムを処理できる、高性能の車載コンピューティングシステムが必要になります。センサーとアクチュエーターも含めたプロセスチェーン全体を、車両内で安全に、しかもわずかの遅延もなく統合しなければなりません。

車両アーキテクチャーへの影響

ITバックエンドから提供されるデジタルサービスは、車両アーキ テクチャーに大きな影響を及ぼします。帯域幅の高いモバイル 無線インターフェイスと、低遅延の車車間／路車間通信（V2X） から、天気、交通情報、規制情報といった環境条件に関する情報が提供されると、ECUはそのデータを経路情報や、車載センサーが取得した周囲のデータと併せて集約します。その後、車両内の コンピューティングシステムが、必要となるグラフィック処理を 実行し、ユーザー設定が可能な高解像度ディスプレイクラスターやヘッドアップディスプレイにその結果を表示します。外部との通信はセキュア通信であるため、データ転送も複雑に なっています。このような通信は無線インターフェイスだけに 要求されている訳ではありません。電気自動車では、充電ステーションとの間で電子決済のためにセキュア通信を確立することが求められます。セキュア通信が必要となる充電通信には、車両側のコンピューティング能力の強化も必要です。

自動車のコンピューティングセンターAUTOSAR Adaptive新しいソフトウェア仕様であるAUTOSAR Adaptiveは、より高機能で柔軟性の高い車載E/Eアーキテクチャーの実現を可能にします。 AUTOSAR Adaptiveアーキテクチャーでは、EthernetベースのECUを、セントラルアプリケーションサーバーとして使用できます。そして何よりもAdaptive ECUには、車両の全ライフサイクルを通してアプリケーションを更新し、新しいソフトウェア機能を後から追加できるという大きな利点があります。

02

Technical Article / September 2018

た。これにより、ネットワークの構造が恒久的に変化し、データ スループットも倍増し、バックボーンの役目を負うようになりました。車両外では、WiFi、Bluetooth、5G、V2Xなどの通信インターフェイスも、高いデータスループットを可能にします。また、ギガ ビット範囲の転送レートを持つ、Low Voltage Differential Signaling (LVDS)やAutomotive Pixel Link(APIX)などを介したセンサー やアクチュエーターへのインターフェイスも珍しいものではなくなります。これまでの従来型のバスシステムも引き続き使用されますが、それらが、統合された車両全体の中で中心的な役割を果たすことはもはやありません。データスループットの高いこのようなハードウェアを効率的に 使用するには、柔軟なソフトウェアアーキテクチャーが必要です。一般に、複雑なプロセッサーやその周辺機器を使用するには、POSIXベースのオペレーティングシステムが前提条件となります。そのようなオペレーティングシステムにはLinuxのほか、 安全関連システム用としてPikeOSがあり、それらにはソフト ウェア機能を効率的に開発するための多彩なライブラリーと開発フレームワークが用意されています。中でも、グラフィックや 人工知能のアプリケーション用のライブラリーは注目に値します。

AUTOSAR Adaptive：新たな仕様

これらの新しい要件を満たすために、AUTOSARコンソーシアムは、すでにその座を確立しているClassic Platformに加えて、 もう1つの標準規格を規定しました。それがAUTOSAR Adaptive Platformです。Classic Platformはコスト最適化型のマイクロコントローラーに対応しています。そのようなプロセッサーは 処理能力は劣るものの、Ethernet、セキュリティー、機能安全などの分野の難易度の高いアプリケーションの実装に使用できます。このような従来型のプラットフォームは、主にセンサーやアクチュエーターに直接アクセスし、厳格なリアルタイム要求を満たす 必要のあるECUの実装に使用されます。一方、Adaptive Platform は、高度な自動運転を始めとする、極めて高いパフォーマンス 要求を持つアプリケーションをサポートするよう設計されています。これによって提供される柔軟な統合環境は、更新や拡張が可能という大きな特徴があります。Adaptive Platformも当然、 厳格な時間要求を満たさなければなりません。しかし、発生頻度

これらすべての新機能が、カーエレクトロニクスと車載ソフト ウェアによる付加価値を押し上げ、2025年までにはそれが占める割合は65%に達するとみられています。中でもソフトウェアの 伸びは著しく、同年までにはその割合は約25%に達する勢いです[1]。複雑化の進行に伴い、ECU開発の作業が一層厳格に分け られていく傾向も顕著にみられます。ECUのハードウェア開発はTier 1サプライヤーが行うのが普通ですが、自動車メーカーに とって競争上極めて重要な因子であるソフトウェアの入手先は 多岐に渡ります。自動車メーカーがアルゴリズムを自社開発するケース、またサードパーティーから購入するケースもあります。

高度な要求に対応する新しいシステム

車両量産後、自動車メーカーやエンドユーザーによってECUの 車両機能を拡張する、ECUのソフトウェアを更新する場合があります。しかし、新たな市場体系は、サードパーティープロバイダーからのソフトウェアの調達の可能性によって作られます。これらの状況から、動的なソフトウェアの統合環境が必要となってきます。そしてそれは、今後の車両プラットフォームにとって、いかなる 場合も必須の機能となります。また、これからは集中的な演算 処理が必要なアルゴリズムや機能を実行するために、高機能な 車載ECUが必要になると予想されます。そのようなECUは64 ビットのマルチコアプロセッサーを搭載し、MMU（メモリ管理 ユニット）をサポートします。これらのプロセッサーは、仮想化や外部メモリーとの高速イン ターフェイスをハードウェアでサポートします。また、グラフィック、画像、各種アルゴリズムも、低い消費電力で必要な処理レートを実現できるSoC (System-on-Chip) をハードウェアアクセラレーターとして使用し、処理を行います。さらに、ECU内では、 安全関連機能および不正アクセスに対する防御をするために 追加のマイクロコントローラーやSoCが使用されます。具体的 にはHardware Security Module (HSM)やTrusted Platform Module (TPM) 等になります。 車両内および車両外ネットワークのインターフェイスは重要な役割を果たします。車両内では、EthernetのIEEE 100BASE-T1 (100Mbit/s)または1000BASE-T1(1Gbit/s)が実装されまし

図1:AUTOSAR Classic PlatformとAUTOSAR Adaptive Platformの違い

03

Technical Article / September 2018

AUTOSAR Adaptiveは、AUTOSAR Classicとは異なり、プログラミング言語にC++を使用します。アプリケーションのプログラ マーは、オブジェクト指向のプログラミング言語、動的メモリー 管理、そして既存の標準ライブラリーを組み合わせることで、複雑かつ再利用可能なソフトウェアを効率的に実装できます。サービス指向に特化したアーキテクチャーに移行し、システム 設計の柔軟性を高めている点も、Adaptive Platformの特徴の 1つです。アプリケーションはAdaptive Platformを介し、その 機能をサービスとして提供する一方、他のアプリケーションが 提供しているサービスも使用できます（図2）。Adapt ive Platform上で実行されるECUはEthernetネットワークで相互に 接続されています。サーバーがあらかじめ提供しているサービスをクライアントが要求すると、その情報がEthernetを介し、 SOME/IP (Scalable Service Oriented Middleware over IP) ネットワークプロトコルを使用して転送されます。サーバーは その要求に応答し、該当するデータを送ります。このデータの シリアル化もSOME/IPで定義されています。これに対して Classic Platformは、基本的にはシグナル指向の通信です。ただし、 AUTOSAR Classicでも、複数のECU間の通信にサービス指向通信 を使用することは可能で、これにはAdaptive Platformと同様に、 Ethernet接続とSOME/IPが使用されます。よって、AUTOSAR Adaptive PlatformとClassic Platformは、互いに補完的な特徴を備えているといえます。そのため次世代の車両では、両方の仕様に基づくECUが、異種混合のアーキテクチャーで使用されるようになることでしょう。従来からのClassicの実装に加え、ベクターの「Adaptive MICROSAR」を始めとするAdaptive Platformのソリューションもすでに市場に登場しています。

ドメインコントローラーとゲートウェイ

現在の車両の中には、ドメイン主体のE/Eアーキテクチャーを 持つものがあります。これは車両機能をその論理的な割当てに 基づき、インフォテインメント、ボディー、コントローラー、ドライブ

が高いイベントを処理する場合は、従来通りAUTOSAR Classicの方が適しています。現時点では、AUTOSAR Classic ECUにAdaptive ECUを組み合わせなければ最も厳格な安全要求を 満たすことはできません。それは、AUTOSAR Adaptive仕様に よってコンポーネントとオペレーティングシステムに関する自由度と柔軟性が高まるためで、その鍵を握るのが「POSIX OS」です。現在、Adaptive Platformが今後、あらゆるユースケースで機能安全を妥協なくサポートする唯一のシステムとして使用される ようになるかを判断するための包括的な研究が行われています。AUTOSAR Adaptive仕様は、Classicとの連携によって幅広いECUをサポートします。システム設計者はこれによって、高性能の車両プラットフォームの開発に必要な要素を手にできるように なりましたが、以前はそのようなECUは独自技術によるアプローチで実装されていました。しかし、AUTOSAR Adaptiveはどの ようなコンポーネントで構成されているのでしょうか。そして、 これら2つのプラットフォームには技術的にどのような違いがあるのでしょうか（図1）。Adaptive Platformでは、アプリケーションは「AUTOSAR Run-time for Adaptive Applications」、すなわちARAを利用します。このランタイム環境によって、多様なアプリケーションをシステムに効率よく統合するための標準化されたインターフェイスが ユーザーに与えられます。ARAには、診断やネットワークマネージメントなどの基本的なサービスへのアクセスだけでなく、ECU内部やネットワーク間通信のためのメカニズムも実装されています。さらに、アプリケーションは、「Minimum Real-Time System Profile (PSE51)」と呼ばれる、オペレーティングシステムのサブセットに直接アクセスできます。AdaptiveアプリケーションはPOSIXベースのオペレーティング システムに、少なくとも1つのプロセスとして実装されます。実行時、アプリケーションプロセスは関連付けられた仮想アドレス空間にロードされ、そこで実行されます。これらのプロセスの起動を 協調させる処理は、アプリケーション制御用のモジュール（Exe-cution Management）が行います。Adaptive環境は、ECUをE/Eアーキテクチャーに統合する際に必要となる、診断やネットワークマネージメントなどの基本的な サービスを引き続いて提供します。基本機能を提供するその他のサービスには、データの永続的な提供（Persistency）、プラット フォーム機能のモニタリング（Platform Health Management）、 暗号化処理（Crypto）、測定値のロギング（Logging and Tracing） などがあります。また、Update and Configuration Management (UCM) は、 Adaptive Platformの中心的な機能です。更新を行う際、 Classic PlatformではECUのコード全体を置き換えるのが一般的ですが、Adaptive Platformには、個別のアプリケーションの削除、更新、追加というオプションが用意されています。個々のAdaptiveアプリケーションは、実行可能なプログラムと マニフェストファイルからなるパッケージで定義されます。これによってECU機能の柔軟な処理が可能になります。マニフェスト ファイルは、サービス指向通信に使用されるポートやIPアドレスといったアプリケーションのインターフェイスをモデル化します。 さらに、呼出しパラメーターを使用して、アプリケーションの起動を開始するための前提条件を整えます。

図2：AUTOSAR Adaptiveアプリケーションのインターフェイス

04

Technical Article / September 2018

はレーダー／LIDARセンサー、カメラ、ディスプレイ、その他のECU等が高性能インターフェイスで接続されます。特に、これらの中には、従来のバスシステムとの間でタイムクリティカルな データを高頻度で転送するゲートウェイにアクセスするだけでなく、センサーやアクチュエーターのレベルのアクセスを保証するECUが含まれます。一方、AUTOSAR Adaptiveソフトウェアを搭載した高性能のコンピューターは、車載ネットワークの通信タスクと、集中的な演算 能力が必要なタスクを処理します。こういったシナリオでは、AdaptiveやClassicのECUがどのような形で相互に通信するかが問題になります。最も単純なのは、Ethernetで相互接続されたECUが、SOME/IPを介した サービス指向通信を使用するケースです（図4）。この例では、 AUTOSAR Classic ECU1が複数のバスシステムに接続されており、それらのバスシステムに他のECUが接続されています。 このコンフィギュレーションではECU1はゲートウェイとして動作

トレインなどのドメインに分けるものです。各ドメインは独自の コントローラーを持ちます。これらのドメインコントローラーはEthernetで相互接続されており、それらが各自に割り当てられている他のECUと協調して、センサーやアクチュエーターなどへのアクセスを実現します。CANやLINなどの車両バスは特定の ドメインコントローラーへの接続を確立します。コネクティビ ティーユニットと呼ばれるコントローラーは、オフボード 診断、Bluetooth、モバイル無線を介した外界との接続を可能にします。 AUTOSAR Adaptiveを使用しても、基本的な車両アーキテク チャーが大きく変わることはありません（図3）。最も顕著な変化は車内でのEthernetの汎用的な使用とそれに伴うSwitchの使用で、これによってECU同士をコリジョンなくポイントツーポイント接続できるようになります。これらのSwitchはワイヤーハーネスを最適化するために統合され、個別のECUとして実装されま せん。さらに、高性能のコンピューターが複数搭載され、それらに

図4：EthernetとSOME/IPを介したプラットフォーム間の通信

図3：AUTOSAR AdaptiveとAUTOSAR Classicに対応する車両アーキテクチャー

05

Technical Article / September 2018

し、バス側からのメッセージシグナルをサービスの形に「梱包」し、AUTOSAR Adaptive Platform側がそれらに直接アクセスできるようにする役目を負っています。この通信レイアウトは、 ClassicとAdaptiveのどちらのプラットフォームでも、AUTOSAR ECUの設計においては固定された要素となっています。これら 2つのプラットフォームではコンフィギュレーションの形式がそれぞれ異なるため、サービスのコンフィギュレーションを変換して マッピングすることが必要になります。この状況は、シグナルベースでしか動作しないAUTOSAR Classic ECU との通信ではさらに複雑化します（図5）。このシナリオでは、ECU1はシグナルゲートウェイに設定され、 これがメッセージシグナルをEthernet上のUDPフレームに直接変換します。AUTOSAR Adaptive ECUは、UDPフレームのシグナルを、シグナルからサービスへのマッピングによってECU2が 持つサービスに変換します。このスキーマに基づいた実装には、通信マトリクスによるシグナル記述だけでなく、AUTOSAR Classicのコンフィギュレーションのコンポーネントにサービスをマッピングする規則も必要です。これらのマッピング規則は、 AUTOSAR Adaptive仕様ですでに標準化されています。サー ビスからシグナルへのマッピングはこれらの規則に基づいてコーディングされ、独立したサービスとしてECU内で実行されます。

ソフトウェアの複雑さの管理

自動化と通信の拡大に向けた自動車のパラダイムシフトには、 大量のデータの処理および伝送と、それに起因するソフトウェアの複雑さの管理が欠かせませんが、今日のシステムでは、このような要求を満たすことは非常に困難です。そのためAUTOSAR Adaptive Platformは、高機能なセントラルコンピューターと、 Ethernetベースのサービス指向通信を生かし、これからの車両アーキテクチャーに最適な基盤を提供します。そこでは AUTOSAR AdaptiveとClassicのECUを並行して使用でき ます。柔軟なゲートウェイのシナリオが、この2つの世界を簡単に相互接続できるのです。

Mirko Tischer (Dipl. Ing.)1997年のベクターに入社以来、製品開発とプロダクト管理に携わる。2018年よりAUTOSARベーシックソフトウェアのAdaptive MICROSARのプロダクトマネー ジャーを務める。

本稿はドイツで発行された『Elektronik automotive, special issue “Bordnetz”, September 2018』に掲載された記事内容を和訳 したものです。

画像提供元：Vector Informatik

参考文献：[1] Hansen Report No. 6, 2017, More supplier disruption coming.

■ 本件に関するお問い合わせ先ベクター・ジャパン株式会社 営業部E-Mail: sales@jp.vector.com

図5：AUTOSAR Classicシグナルゲートウェイへの接続