SDV (Software Defined Vehicle) を支えるアーキテクチャとして提唱されているセントラル/ゾーン型アーキテクチャは、ソフトウェアで実現する継続的な機能拡張や、スマートフォンと同じサービスを実現できる均一なアプリケーション動作空間の提供、さらには車の深部のコントロールとアプリケーションを繋げる新次元のサービス等を可能にする基盤になります。
しかし、それらを実現しようとすると、安全/セキュリティレベルの低いソフトウェアと高いソフトウェアがフラットなHPC (High Performance Computer) 上に混在し、お互いがお互いを干渉し得るという、新たな課題に直面することになります。
一方、HPCのハードウェアの進化としては、シングルコアCPUからマルチコア、さらには特性・速度の異なるマルチコアCPUが複数組み合わさったヘテロジニアスマルチコアへと進んでいます。
先述したソフトウェア混在の課題は、異種のコアが別々に配置されたヘテロジニアスマルチコアを素直に使い、本質的な分離/隔離を実現することで解決の糸口が見えてきています。
今回のBlogシリーズでは、概念検証を終え量産開発段階に入っていくSDVの主要アーキテクチャ要求の1つである、「Decoupling (ソフトウェア/ハードウェアの分離、安全/セキュリティレベルの異なるソフトウェア同士の分離)」に焦点を当て、以下について解説します。
- 半導体ベンダ各社からリリースされているヘテロジニアスマルチコアSoC上でそれをどう実現するのか
- SDV Systemのアジャイルな継続的進化とASIL安全要件をどう両立させるのか
- Decouplingを実現する、SDV開発に最適なリアルタイムOS「eMCOS®」の機能紹介
全3回に分けて本テーマを解説予定ですので、ぜひ最後までご覧ください。
第1回となる本記事では、まず「SDVとは何か」、という点について詳しく解説します。
目次
SDVの定義:ハードウェア、ソフトウェアの進化
まずSDVの定義について、ハードウェアの進化という点から、携帯電話/スマートフォンを例に挙げて考えていきます。
携帯電話(スマートフォンが台頭する前の、いわゆるガラパゴス携帯)が普及したのは1990年代後半で、2000年代にスマートフォンが登場しました。
携帯電話がスマートフォンに入れ替わったのが2010年代後半です。
携帯電話/スマートフォンで使われるハードウェアは、20年をかけて進化しました。
定量的なデータで見ると、1990年代後半に存在していたスーパーコンピュータの実行性能をFLOPS で表すと2テラFLOPS[*]であるのに対し、2022年のスマートフォンの実行性能を表すと同じく2テラFLOPS、つまり約20年前のスーパーコンピュータを今では個人が持ち歩く時代になったと言うことがハードウェアの進化として読み取れます。
[*]コンピューターの計算性能を表す単位。Floating Point Operations Per Second; 1秒間に浮動小数点演算を何回行うことができるか
ここではスマートフォンの例を挙げていますが、私達に身近な車や電気機器等も同じ様にハードウェアの進化が行われてきたということが、容易に想像できるかと思います。
次に、ソフトウェアの進化という点から見ていきます。
現在の車載ソフトウェアは1億行を超えるソースコードが使われています。
これも歴史的に見ると、1980年代は数千行で始まり、まずはエンジン制御の電動化が始まったのですが、そこから40年をかけてソフトウェアのコード規模は10万倍になっています。
ハードウェアの進化に伴ってソフトウェアも進化していく形で10万倍と言う数字になっています。
この様に考えると、ハードウェアとソフトウェアが進化した車両、それがSDVと言えないことも
ありませんが、SDVと言う語が出てきた際のコンセプトには、このハードウェアとソフトウェアの進化だけではなく、違う意味も含まれます。
SDVの業界知見者の意見をまとめてみます。車載関連企業各社がWebサイトに載せているSDVを紹介する文章を抜き出してみると、「アップグレードカー」「ソフトウェアセントリック (ソフトウェア中心)」「ハードウェアとソフトウェアの分離」「アップデート/アップグレード」「(本Blogシリーズのテーマである)デカップリング」等と言った単語が並んでいます。
これらをまとめると、SDVには2つの観点があると言えます。
1つ目がビジネス、2つ目が技術です。
まずビジネスの観点では、ソフトウェアを通して新しい価値を提供でき、さらに市場投入後もアジャイル開発を継続することで価値を新たに与えていくことが可能であり、サービスベースのビジネスモデルに対応できるもの、という捉え方ができます。
次に技術の観点では、ソフトウェア中心で、ハードウェアとソフトウェアの分離、アップデートとアップグレード、自律学習、環境との相互作用を可能にするものであると捉えられます。
これらをまとめてSDVを定義してみると、
ソフトウェア中心となる技術を用いて、サービスベースの新しいビジネス価値を提供できる車両がSDVと言えると考えます。
言葉だけではわかり辛いため、ここで2つ実例を挙げます。
まずは、マイクロサービスアーキテクチャ(下図右側)です。
これは2010年代後半にサーバーサイドでバズワード的に現れたアーキテクチャです。
このアーキテクチャ登場前のものはモノリシックアーキテクチャ(下図左側)と言われます。
SDVの定義:実例を挙げて考察
この2つのアーキテクチャの何が違うのかと言うと、左側のモノリシックアーキテクチャはUI, ビジネスロジック, データアクセスレイヤがひとまとまりになっていて、この単位でコンピューターにデプロイされる形なっています。
一方、右側のマイクロサービスアーキテクチャを見ると、マイクロサービスと言う小さなサービスの単位でコンピューターにデプロイする形になっていて、ビジネスロジックやUIはそれらのサービスを組み合わせることによって提供する形になっています。
こうすることによってマイクロサービスと言う独立したモジュールを素早く置き換えることができる形になっており、SDVにおける「アップデートとアップグレード」とかなり似ています。SDVは、この流れを汲んでいると考えます。
次に、SDV (Software Defined Vehicle)と言う言葉が出てくる以前の車両を”HDV (Hardware Defined Vehicle)”と定義し、HDVとSDVを比較してみます。
上図左側がHDV (Hardware Defined Vehicle)、右側がSDV (Software Defined Vehicle)の図です。
左側のHDVは車両システムの下位であるHardwareを起点としたボトムアップでのシステムモデリングになります。
つまり、どういうハードウェアからどういうソフトウェア/システムを作ろうかと言う風に考える、ハードウェアありきのシステム想定と言う形になります。
そのため、ハードウェア最適化を行うことで、ハードウェアの使用効率を高め、コストを低下させることができます。
一方右側のSDVは、まったく逆の視点で、車両システムの上位であるアプリケーション側を起点としたトップダウンでのシステムモデリングになります。
つまり、アプリケーションにとっては下のPlatformやHardwareはどの様なものでもよく、PlatformがI/F (上図右側のAbstraction I/F)を提供してくれればアプリケーションは作れると言う形になります。
アプリケーションとI/Fとの組み合わせによって容易にビジネス価値を提供できる点は、前述のマイクロサービスアーキテクチャと類似した形になります。
ここまでで、SDVと言うものがソフトウェア中心で、ハードウェアを意識せずに早くビジネス価値を提供できるものだと言うことがご理解いただけたと思います。
最後に
第1回の内容はここまでとなります。
次回は、本Blogシリーズの本筋となる、「SDVにおけるデカップリングとは何か」という点を中心に解説していきますのでぜひご覧ください。
またイーソルは、SDV開発を加速させるソリューションを幅広く提供しています。
- SDVを構成するHPCの能力を最大限に引き出すリアルタイムOSプラットフォーム「eMCOS®」
- AUTOSAR準拠の車載プラットフォームソフトウェア「AUBIST」
- 車載ソフトウェア エンジニアリングサービス
ご興味がございましたら、お気軽にお問い合わせください。
OS開発部 A.K