Technical Information

SDVとは何か
~課題と期待~

maas10_hero.jpg

このところ「SDV(Software Defined Vehicle)」という言葉を目にすることが多くなっています。しかし、SDVが本来意味するもの、またそれがユーザーにどのような価値をもたらすかについては明確になっていません。ここでは、SDVへの期待や課題についてビジネス面と技術面から解説します。さらにSDVの実現に不可欠となる「ハードウェアとソフトウェアの分離」やビークルOSの必要性についても説明していきます。

※この記事は、『Veriserve Mobility Initiative 2023』の講演内容を基にした内容です。

高田 広章

名古屋大学未来社会創造機構
モビリティ社会研究所所長・教授
名古屋大学大学院情報学研究科教授 付属組込みシステム研究センター
センター長
高田 広章 氏 

CASEが車載組込みシステムに及ぼす影響

近年、自動車産業は「CASE(Connected、Autonomous、Shared & Service、Electric)」というキーワードと共に大きな変革期を迎えています。車自体が大きく変わる中で、車載組み込みシステムもさまざまな影響を受けます。例えばサイバーセキュリティへの対応はますます重要になる一方で、AIや新しいプロセッサ技術の取り込みが求められるようになり、さらにセーフティクリティカルシステムは従来になく複雑化していきます。このようにCASEが車載組み込みシステムに及ぼす影響の中から、大きく分けて「システムのアーキテクチャーの変化」と「ソフトウェア更新(OTA※)の必要性・意義」という2つの共通課題が浮上してきます(図表1)。

※OTA(Over The Air=オーバー・ジ・エア)とは、無線通信を経由してデータを送受信すること。

CASEが車載組み込みシステムに及ぼす影響

図表1:CASEの時代には車がネットワークにつながることが当たり前になり、これに伴って車載組み込みシステムの開発や運用も大きく変化する

■共通課題1 システムのアーキテクチャーの変化

車載組み込みシステムのアーキテクチャーの変化についてはいくつかの側面がありますが、最も大きな変化は「自律分散型から中央集権型システムへの転換」です。

自動運転以前の車載システムは、例えばエンジンを制御するコンピューター、ステアリングを制御するコンピュータ―など、メカやシステムが独立・分散して動いており、全体を統合して動かしていたのはドライバー(人)でした。これに対して自動運転になると人に代わってECUが車全体を制御することになり、自ずと中央集権型のシステムになります。この自動運転用のコンピューターにはAIをはじめとした最新技術が多数使われることになるので、従来に比べ飛躍的な演算能力が求められるようになります。高性能コンピューターを車に搭載するのであれば、さまざまな演算処理をそこに集中した方がコスト的にも有利です。こうした流れから現在では、ビークルコンピューター(セントラルECU)といった大きなコンピューターを中央に置き、そこから全体を制御するようなアーキテクチャーへと変化しつつあります。

■共通課題2 ソフトウェア更新(OTA)の必要性・意義

これはSDVにも深く関わる課題ですが、ソフトウェアの機動的な更新=OTAの必要性も高まってきます。例えばセキュリティ上の脆弱性が見つかった場合には迅速な修正が求められることから、OTAでのソフトウェアアップデートは非常に有効です。ただし、危険なソフトウェアが浸入するなど「両刃の剣」になる可能性もあるため、OTAはかなり高いレベルで作り込まなくてはなりません。また、車載ソフトウェアがどんどん複雑化する中で、ソフトウェアの完成を待っていると市場投入の時期を逃してしまう懸念がありますが、OTAを活用すればソフトウェアは製品を販売した後に改善することができるため、より早い市場投入が可能になります。

この他にも、IT業界やゲーム業界といった自動車業界以外のサードパーティーを活用し、ゲームやエンターテイメント系のアプリケーションをOTAでインストールし、これをアップデートしながら自動車の魅力を高めていくことも考えられます。このようにOTAが重視されているのは、まさに自動車が持つ機能・価値の中で、ソフトウェアで実現されるものが増加してきたからです。最近の「Software Centric」や「ソフトウェアファースト」という言葉も、この自動車がソフトウェア中心になっていく流れの中で生まれてきたキーワードであり、今回のテーマである「SDV」もその一つです。

SDVとは何か

ではSDVとは何でしょうか。Software Defined Vehicleを直訳すると「ソフトウェアによって定義される車」となります。言い換えれば、「ソフトウェアを変更することで価値や機能が変えられる車」、さらには「APIによって動かせる自動車」と表現できるかもしれません(図表2)。

Software Defined Vehicleとは?

図表2:ユーザーにとって、これまでの車は「購入した瞬間」に最高の価値があったのに対し、SDVの時代は「購入してから」もソフトウェアによって価値を高められる

SDVについて期待される成果やメリットには次のようなものがあります。

■OTAによってアプリを後から追加できる

これは購入後に車の価値が上がる可能性を示しています。また車が一定時間を経ても「陳腐化しない」という言い方もできます。

■パーソナライズできる

スマホが自分好みのアプリを入れることで「自分仕様」になるのと同じように、車も同様に自分が求めるアプリを入れることで「自分仕様」になります。まさに「車のスマホ化」です。カーシェアが進んでいくと、この機能は大きなメリットになっていくと考えられます。

■継続的に収益が上がる

スマホではアプリ販売やアプリ内課金、サブスクモデルが一般的で、これによってハードウェアを販売した後も継続的に収益を上げられます。自動車でもソフトウェア更新やアプリの販売などによってこれと同様の収益構造を構築できる可能性があります。

SDVはうまくいくのか?(ビジネス面)

上記のSDVのメリットはあくまで理論上の話です。では、実際問題としてSDVビジネスは将来本当にうまくいくのでしょうか。いくつか課題を挙げながら考えてみます(図表3)。

ビジネス面のポイントと課題

図表3:スマホのように「ソフトウェアやサービスに対価を払う」という考え方を、車についてもユーザーに持ってもらうことがSDVのビジネスの成否を分けるポイントとなる

■ユーザーに買ってもらえるアプリとは

まずビジネスとしての可能性を持つアプリとしては「自動運転」が考えられます。これはすでに実例があり、テスラが「FSD(Full Self driving)」として月額199ドルで販売を開始しています。また、HMI=インパネや操作性を自分好みにカスタマイズするアプリ、ナビやビデオ&オーディオエンターテインメントといったIVI(In-Vehicle Infotainment)系アプリなども有力だと考えられます。アプリがビジネスとして成功するかどうかはやはりアイデアによるところが大きく、今後に期待がかかります。

■余裕を持ったハードウェアを準備できるか

販売後に多様なアプリを入れようとするとハードウェアにあらかじめ余裕が求められ、当然のことながら車両価格が高くなります。従来、自動車メーカーは必要な機能をぎりぎりのコストで実現するというマインドで車作りをしてきましたが、今後はこうしたマインドから変えていかなければいけません。車両価格は高くなりますが、それに見合った価値を提供し、ユーザーに納得してもらうだけの魅力作りが重要になっていきます。

■アプリで価値を出すためのヒント

一方、車というハードウェア資源を活用した新しいサービスの可能性もあります。プローブカーと言われるものがその一例で、これは車を動く交通観測モニターとして活用し、交通状況や周辺情報を取得するシステムです。これをうまく使えば、例えばリアルタイム版ストリートビューのような面白いサービスが作れるのではないかと考えています。

SDVはうまくいくのか?(技術面)

もう一つは技術面ですが、こちらもいくつかの課題があります(図表4)。

技術面のポイントと課題

図表4:開発工数や安全性といった、コンピューターソフトウェア業界が抱えているものと同じ課題に、自動車メーカーも直面することになる

■開発工数の爆発

SDV開発で最も心配されるのはソフトウェア開発工数の爆発です。現状は、1つの車に1つのバージョンのソフトを作るだけでも手いっぱいの状況です。これが何度もバージョンアップを繰り返すことになれば車の種類×ソフトのバージョン数の開発が必要になり、工数は爆発的に増加します。当然ながら開発スタイルから変えていかなければなりません。

■安全性は担保されるのか

頻繁にソフトウェアをアップデートした時に安全性は担保されるのかという課題。ここはやはり慎重な安全性の検証が求められます。そして無難な方法としては、安全性に影響しないところから「Software Defined」していくことです。また、安全性に関わる部分をなるべく小さく限定して切り分けることも大切です。

■ソフトウェアアップデートの難しさ

OTAにも難しい面があります。特に車の場合、何十個もあるECUをバージョンの整合性を維持したままアップデートするのは容易ではありません。ただし、前述した中央集権型システムでは、OTAをするECUの数が減るためソフトウェアアップデートの負担は軽減されます。こうした意味からも中央集権型への移行は望ましいと言えそうです。

求められる開発スタイルの革新

ソフトウェア開発工数を爆発させないためには、やはり開発スタイルの革新が不可欠です。そこで、今後求められるであろうポイントをいくつか挙げてみます。

■仮想環境での開発(クラウド上での開発)

実物ではなく、仮想環境=シミュレーション環境を構築してCI(継続的インテグレーション)/CT(継続的テスト)を適用し、ソフトウェアを連続的に発展させていく手法が、車の世界にも導入されていくと考えられます。

■DevOpsの採用

こちらはCD(継続的デリバリー)の適用といったもので、ソフトウェアをリリースしながらユーザーが求めているものを見極め、本当にニーズに合ったものだけを作っていく(=無駄な製品は作らない)というDevOpsのような開発スタイルを取っていくことが重要になります。

■ソフトウェアとハードウェアの分離

この他、私が最も重要だと思うのは「ソフトウェアとハードウェアの分離」です。従来の車の開発では車両(ハードウェア)を作る途中にソフトウェア開発プロセスが埋め込まれていました。それを転換して、ソフトウェアはソフトウェアとして連続的に開発していく、つまりハードウェアとは別の軸で開発していくことになります。

しかし、このソフトウェアとハードウェアの分離が非常に難しいところです。先ほど、ソフトウェアを繰り返しアップデートしていくと、車の種類×バージョン数のソフトウェア開発が必要になると指摘しましたが、このような「掛け算」では工数が膨大になるので、これを「足し算」にするのが理想です。車の車種+バージョン数(またはアプリの数)とすることでソフトの開発規模を抑えることができます。

また、そのためにはSDVを制御するためのAPIが重要になります。というのは、同じソフトウェアでいろいろなハードウェアを制御で可能にするためには、あるAPIをたたく(APIに要求を出して処理を実行する)と、ハードウェアの違いを吸収して動くプラットフォームがどうしても必要になります。このAPIを実現するソフトウェアが「ビークルOS」と呼ばれるものです。

「ビークルOS」の役割と今後

そもそもOSの役割の一つに「ハードウェア資源を仮想化して管理すること」があります。例えばパソコンのOSに入っているファイルシステムにはストレージというハードウェアを仮想化する機能があり、これによって「ストレージの違い」を覆い隠しています。私たちがHDやSSD、USBメモリーといった異なるメディアを同じAPIで操作できるのは、OSがハードウェアを抽象化することによって可能になっているわけです。

ビークルOSは「車両のハードウェア資源を管理」するもので、その役割は、車両のハードウェア資源を抽象化して、一つのソフトウェアで複数の種類の車両を制御できるようにすることです。しかし、車両のハードウェアを抽象化するのは容易ではありません。まず、車両のどの部分を抽象化するのか、どの階層で抽象化するのか、どのように抽象化するのかなど、さまざまな問題があります。APIは仕事の分かれ目で定義する必要があり、つまり「どこの階層でAPIを切るか」は、自動車業界のビジネスモデルをどのように位置付けるかに大きく関係することになります。

今後の展望ですが、ソフトウェアプラットフォーム/OSが普及するには「APIの標準化」が極めて重要です。OS開発における勝ち組が市場を寡占または独占することも予想されます。またAPIの標準化だけで十分な互換性を確保するのは困難で、市場を獲ろうとするなら自らのAPIをオープンソースで公開してマーケットにおけるシェア拡大をしていく必要があると思います(図表5)。

ビークルOSのチャレンジ

図表5:SDVの成否はビークルOSにかかっており、またビークルOSの普及のカギは「APIの標準化」にある

ソフトウェアとハードウェアの分離の難しさ

先に、開発方法の革新していく上でソフトウェアとハードウェアの分離が重要だと述べました。しかし、これはMOT=技術経営の議論から見ても難しく、特に日本にとっては不得意領域なのではないかと考えられます。

MOTの議論でしばしば指摘されることですが、製品のアーキテクチャーには「組み合わせ型(モジュラー)」と「すり合わせ型(インテグラル)」があり、日本は自動車のようなすり合わせ型が得意な一方で、パソコンのような組み合わせ型は得意ではありません。

SDVにおいてソフトとハードを分離することは、まさにすり合わせ型から組み合わせ型への転換していくことに他なりません。今まではソフトとハードを「掛け算」で全部すり合わせて最適解を探していたわけですが、これを「足し算」にしていくことになります。その結果、「かゆいところに手が届かない」という不満が起きないとも限らない。しかし、だからと言って組み合わせ型を否定するのではなく、今後はトータルなトレードオフで新たな最適解を考えていく必要があると思います(図表6)。

すり合わせ型から組み合わせ型へ

出典:藤本 隆宏『日本のもの造り哲学』(一部修正)
図表6:日本のものづくりが得意としてきたのはすり合わせ型、すなわち「掛け算」の開発手法。SDVの時代にはこれを「足し算」に変えないと勝てない可能性がある

また、すり合わせ型の方が組み合わせ型より品質の良いものが作れるとされていますが、実はどちらも技術が進んでいけば品質は向上します。この品質向上がユーザー要求を超えると「過剰品質」となりかねません(図表7)。コストとユーザー要求のバランスを考えればやはりどこかで組み合わせ型への切替が必要になってくるだろうと考えます。

SDV時代の品質の考え方

出典:クリステンセン・レイナー『イノベーションへの解』(一部修正)
図表7:ものづくりが組み合わせ型にシフトするに伴い、製品の品質に対する考え方も変わってくると考えられる

おわりに

SDVトレンドは今後も着実に進んでいき、自動車メーカー各社はSDVの価値を生み出すために知恵を絞り、かつ開発スタイルを革新・効率化していく必要に迫られます。我々もソフトウェア業界に携わる者として、ソフトウェアの開発効率を上げるため継続的な努力が求められる中、SDVはその流れをさらに加速させることになります。我が国の組み込みシステム業界は、品質の高いものづくりに強みがありますが、今後は「最高品質」ではなく「適正品質」というものを念頭に、新しい技術に積極的に挑戦していくことが大事になっていくでしょう。

この記事をシェアする

Facebook  Twiter