ADAS設計のハードへの移行が自動運転の未来を変える：大規模化するソフト開発（1/2 ページ）

自動運転の実現へ期待が集まるが、自動運転システムの実現にはさらなるソフトウェア開発規模の増大という大きな課題がある。この大きな課題を解決するには、ソフトウェア中心のアプローチからカスタムハードウェア開発へと重心を移すべきではないだろうか。

[Kurt Shuler（Arteris IP），EE Times]

ADASの教訓

　スーパーコンピューティングの複雑さ、リアルタイム性、機能安全という3つのクリティカル領域を同時に統合しなくてはならない自動運転は、システムレベルの設計者たちに今まで経験したことがないような難題を突きつけるでしょう。これを実現するためには、開発者は従来のソフトウェア中心のアプローチからカスタムハードウェアの開発へと重心を移し、車両の安全性、コスト、電力効率における設計上の制約に見合ったシステムを作らなくてはなりません。

　汎用半導体上で動作するソフトウェア中心のシステムからカスタムSoC（System on Chip）に移行したADAS（先進運転支援システム）開発チームは、それに伴う数々の障壁を乗り越え、ゲームチェンジャーとなるようなプラットフォームを構築しています。自動運転システムの開発者はADASに習うことで統合上の課題のいくつかを解決できるかもしれません。

図1：上のブロック図は、主要なハードウェア保護および故障検出メカニズムの実装を示しています。これらのエレメントにより、電子システムはソフトウェアのみのアプローチよりも効率的に機能安全要求を満たすことができます。 （クリックで拡大）

　いくつかのADAS開発チームが学んだことは、それまでソフトウェアで実行されていた多くのタスクをオフロード化しシリコンハードウェアで最適化できるということです。このアプローチでは、SoC通信インフラを介したシステム全体への機能拡張が1つの柱となります。この方法によって生み出される柔軟性が、より実際の運転状況に即したシステムの実現を可能にします。

　ここで、エンジニアたちが初期のADASに採用していたソフトウェア中心のアプローチを振り返ってみましょう。それまでにない安全アプリケーション、ビジュアルプロセッシングアプリケーション、センサーフュージョンアプリケーションに取り組む上で、このアプローチでは開発スケジュールの最初の段階で新しいアルゴリズムを作らなくてはなりませんでした。それらのタスクの多くに何行にもわたる実行コードが必要とされ、このことがスケーラビリティとパフォーマンスの問題を生んでいました。

　自動車メーカーは数十万行あるいは数百万行にも及ぶコードを必要とするようなシステムの採用と継続的サポートに懸念を抱いていることが分かっています。遅延が長くなることに加え、車のライフサイクル期間に数回のアップデートが行われることを考えればなおさらのこと、大規模なコードベースはエラーを招きやすいからです。それらのエラーがシステム障害につながり、責任問題に発展する可能性もあります。OEMとディーラーにとっても、現場で展開される大規模コードベースを保守することは困難です。

SoCのイノベーションが成功の鍵

　そうしたことから、ADAS開発チームはハードウェアアクセラレーションによってより効率的に、かつ低コストで機能を実行する方向に舵を切りました。一例としては、自動車メーカーが自社の車両に搭載されるすべての電子システムに要求している安全メカニズムがあります。このソフトウェア中心からハードウェアアクセラレーションへのADASの進化に、システムレベルでISO 26262準拠を実現するハードウェア製作のヒントを見いだすことができます。性能、安全性、効率性、さらには可能なかぎり低レベルでの安全性向上をサポートするSoCインフラが、この進化において大きな役割を担っています。

　ADASまたは自動運転SoCは、エラーと故障の両方を検知し、場合によっては訂正するスキーム内で全ての自動運転機能を実行しなくてはなりません。このプロセスには別途システムロジックが必要なため、それがソフトウェアベースであれば、なおさらスーパーコンピューティング機能から処理電力を奪う可能性があります。先駆的なADAS開発チームは、多様な故障の危険とリスクに基づいて自分たちのシステムを分析し、ハードウェアベースの故障検出と修復機能を選択的に実装しなくてはならないことに気づきました。さらに彼らは、オンチップハードウェアベースの機能安全メカニズムが、ソフトウェアのみの故障検出または訂正アプローチに比べてソフトウェアの複雑さを大幅に軽減できることを発見しました。最先端を行っているいくつかのADAS開発チームは、エラー検出訂正メカニズムをインターコネクト内に実装してSoC全体に拡張することで、システム全体の診断範囲を広げられることに気づきました。