ニュース
車載演算ゲートウェイ・プラットフォームによりソフトウェア定義自動車（Software-defined car）を実現【日本テキサス・インスツルメンツ】
2016年9月27日
自動車分野には3つの明確なトレンドがあります。半自動または自動運転車への移行、データ帯域幅の増加によりクラウドとつながる車、そして車両の電化です。これらのトレンドは、車載アーキテクチャの変化も促しています。現在の車載アーキテクチャでは、増加し続ける多数のエンジン制御ユニット（ECU）が、低速のCAN（Controller Area Network）/LIN（Local Interconnect Network）通信バスでつながっています。しかし、このアーキテクチャには限界がいくつかあります。
例えば、ソフトウェアの開発、保守、検証は複雑です。各ECUのソフトウェアは、別々のサプライヤによって作られます。車載システムが効率的に作動するためには、車のシステム内全体でソフトウェアの整合が取れている必要があります。既存のシステムに機能を追加するのは、複雑で、時間がかかり、エラーが入り込みやすい作業です。車に機能や能力を新たに追加しながら自律性と接続性を実現することは、分散されたECUでは実装が困難か、あるいは不可能です。
半自動運転車や自動運転車には、カメラや、レーダー、LIDARを多数使用する必要があります。車周辺のそのようなローデータすべてをやり取りするには、多数のECUがギガビット・イーサネットを扱えることが必要です。ローデータの処理と結果の表示は、処理要件とコストを押し上げます。現在の車両の電化に必要なバッテリは高価なことがあり、システムの予算内に収めるのが困難になるでしょう。
これらの課題の克服に取り組む最初のステップは、車のある部分またはHEV/EV操作といった車の特定の機能のアクションをサポートする機能ドメインへと機能を集約することです。図1は、機能ドメインを持つ車載演算アーキテクチャの例です。機能ドメインは、他のドメインとの高帯域幅相互接続と、残りのドメインECUの低帯域幅CAN/LIN相互接続との間でゲートウェイとして働きます。ECUの数や、車両の配線量、コネクタの数が減ると、大幅にコストを削減できます。高帯域幅のデータ処理を機能ドメインに限定することで、残ったECUのセンサやアクチュエータが簡素化され、コストが抑えられます。ソフトウェアの機能やアプリケーションを多数のECUやサプライヤに分散させるのではなく、機能ドメインのみに実装することにより、構造化されたソフトウェア開発プロセスが可能になります。
図1：車載用ゲートウェイの車載演算アーキテクチャ
各種機能を内蔵した、1台あたり1～3個の車載演算プラットフォームから成るアーキテクチャによってソフトウェア定義自動車（software-defined car）を作り出すという、新たなトレンドが生まれています。ソフトウェア定義車の実現に不可欠なのが、サービス指向アーキテクチャ（SOA）です。SOAシステムは緩くつながったサービスでできており、これらのサービスがシンプルで相互接続性のあるインターフェイスを通して、通常はネットワーク経由で、それぞれ別個の機能とやり取りします。
SOAの利点には、ハードウェアの独立性、テストの簡素化、迅速な展開、組織横断的なアプリケーション開発などがあります。最後に指摘しておきたいのは、サービスは抽象化されたインターフェイスを持つブラックボックスとして提供されるので、各サービスを実装するのに同じテクノロジを使用する必要がなく、同じサプライヤでなくてもかまわないことです。
SOAは、ウェブサービスや、SaaS（Software as a Service）、PaaS（Platform as a Service）（クラウド・コンピューティングとも呼ばれます）などの他の分野では長い歴史があります。車載機器の例としては、タイヤの空気圧の情報を提供するシンプルなECUが挙げられます。多くのアプリケーションが、例えば、マンマシン・インターフェイスで車両の現在の情報を表示するために、あるいは時速計算機が電気自動車のバッテリ・マネージャにデータを与えるために、タイヤの空気圧データを利用します。別のハードウェア・ベンダを使用するタイヤ空気圧ECUに置き換えたり、大型の多機能ECUにタイヤ空気圧ECUを組み込んだりすることも可能です。というのも、上流のアプリケーションは、抽象化されたインターフェイスを利用してECUのサービスに接続するので、ECUに変更があっても、あるいは別のECUに組み込まれていても、SOAの使用には影響がありません。タイヤの空気圧の例では、タイヤの空気圧データがより小さいECUに集約されるので、タイヤ空気圧センサ・システムをサポートするコンポーネントが別のメーカーのものでも、違うセンシング・テクノロジを利用していてもかまいません。
車載演算ゲートウェイ・プラットフォームでは、プラットフォームごとの演算処理要件が明らかに増加しますが、これには、求められる処理量に応じてシステム・オン・チップ（SoC）を1つまたは複数使うことができます。演算SoCは、これらの間でデータを効率的に共有する必要があります。PCIe（Peripheral Component Interconnect Express）は、演算SoCと大容量記憶装置とを接続する高帯域幅バックボーンです。一方でギガビット・イーサネットは、車載演算プラットフォームから車両の残りの部分までの、高帯域幅通信です。
TIの『『DRA829V 』』アプリケーション・プロセッサは、初めてPCIeスイッチをチップに内蔵し、高帯域幅で演算プロセッサ間のデータ共有を行って、高速・高性能のデータ処理を実現します。『DRA829V』に内蔵されたPCIeスイッチは、SoC間で効率的にデータ転送を行います。中央処理装置が介入する必要も、一時記憶装置の必要もありません。
車載演算プラットフォームは、車両の他の部分とのデータ通信を管理できなければならないため、『DRA829V 』プロセッサには、ボックス外部と通信するための8ポート・ギガビット・イーサネット・スイッチに加え、車両の他の部分との通信用に従来の車載CAN FD（CAN-Flexible Data Rate）/LINインターフェイスが複数備わっています。
機能の一部には、機能安全性要件が存在します。『DRA829』は、機能安全性について20年以上の経験を活かし、重要度が混在した処理をサポートします。ロックステップ方式のArm® CortexTM-R5FはASIL-Dを実現しますが、SoC全体はASIL-B対応です。オンチップの広範なファイアウォールにより、安全性機能と非安全性機能の重大度が混在した状態を同時に管理する作業から解放されます。図2では、標準的な車載演算プラットフォームと、『DRA829V』を使用するプラットフォームを比較しています。『DRA829V 』では必要なパッケージ数が半分になるので、コストや電力、物理的なサイズの削減になります。
図2：車載演算ゲートウェイ・システムの2つの例
業界のトレンドの要求に応じるため、自動運転車のアーキテクチャは発展し続けています。SOAをベースとしてソフトウェア定義自動車を実現する車載アーキテクチャが台頭してきましたが、これは、1台ごとに車載演算プラットフォームが1～3個必要になることを意味します。TIの新しいDRA82xプロセッサ・ファミリは、この要件に特化して作られているので、自動車メーカーやティア1サプライヤ各社は、システムのニーズとシステム・コストの制約に応じた車載演算プラットフォームを効率的に開発できます。
※すべての登録商標および商標はそれぞれの所有者に帰属します。
※上記の記事はこちらの技術記事
（2020年1月7日）より翻訳転載されました。
※ご質問はE2E Support Forum
にお願い致します。
日本テキサス・インスツルメンツ株式会社ホームページはこちら
