アーカイブ動画

クルマを取り巻く環境とSoC開発部設立の背景

株式会社デンソー
SoC開発部 ソフト基盤開発室
室長
丸目 佳（まるめ・けい）氏

最初に登壇した丸目氏は新卒で東芝に入社し、19年間SoCハード設計に従事した後、2017年にデンソーに転職。RISC-Vアクセラレータの並列プログラミング環境構築に従事した後、現在はSoC(※1)開発部ソフト基盤開発室長として、AD/ADAS向けオリジナルSoCのソフト開発効率の改善に注力している。「SoC開発において、ソフトウェアとハードウェアの双方を経験しています」（丸目氏）

(※1)SoC（System on a Chip）：集積回路の1個のチップ上に、プロセッサコアをはじめ一般的なマイクロコントローラーが持つような機能の他、応用目的の機能なども集積し、連携してシステムとして機能するよう設計されている、集積回路製品

丸目氏のセッションテーマは「自動運転を支えるSoC- 高性能と安全性の両立へ向けた挑戦」。

最初に丸目氏はクルマを取り巻く環境について紹介した。「現在、ソフトウェアの規模は指数関数的に大きくなっています」と丸目氏。例えば現在は1億行規模のソフトウェアが、2030年には6億行に増加すると推定されている。「もはやこのような規模を人手だけで扱うのは困難です」（丸目氏）

ソフトウェアだけではない。ハードウェアも変化している。これまではいろいろな部品でシステムを構成していたが、今はSoCへの機能集約が進み、SoCが複雑化している。「これまでの市場にあるSoCを選んで、ソフトウェアを適合させていくやり方では、使いこなしに限界がある。ソフトウェア主導でソフトとハードの競争を促し、顧客ニーズと社会課題を解決する形に変えていかなければならないと私たちは認識しているのです」（丸目氏）

それを実現するために設立されたのが、デンソーのSoC開発部である。「お客さまのやりたいことをかみ砕いたECU製品部門のソフトウェア主導のSoCレシピを具現化し、SoCメーカーと共創して車載に最適なSoCを作っていくことをミッションにしています」（丸目氏）

車載SoCが守るべき“掟”とは

SoCはサーバー、モバイル、車載へと進化し、守備範囲を広げてきた。サーバーのSoCは、性能をスケールすることが正義だった。モバイルのSoCは、電力効率と体感性能が求められる。電力効率を達成するために、異種プロセッサによる並列処理を採用している。では車載SoCはどうか。「モバイルの電力効率を継承しつつ、確実に時間内に動かし切るという掟を課せられているのが、車載SoCです」（丸目氏）

ではその掟を守るために何が必要になるのか。「干渉させない設計で規律ある実行ができること」と丸目氏は説明する。干渉させない設計をするために、時間と空間を分離している。そしてもう一つ重要になるのが、「正確に答え合わせをすること、正確な観測です」と丸目氏。だがシステムが複雑化・極大化しているため、このプロセスを人手で回すのは難しい。「つまり巨大化したパズルを解くようなもの。職人芸だけでは解けません。そこが車載SoC開発の難しいところ」（丸目氏）

この課題を解決する糸口として、丸目氏たちが考えているのが、「Data-driven Deterministic Design」。データに基づく決め打ち設計の自動化だという。それを実現するための3つのキーとなるデータがある。1つ目はデンソーが長年、ECU(※2)開発によって蓄積してきた豊富なシステム知見。「だがそれだけでは規律ある設計はできません」と丸目氏は言う。2つ目がSoC構造データ。このSoCがどういう構造なのか、どう動くのかを把握してそのデータを活用することである。3つ目が実行時の詳細なふるまいデータである。「システム知見とSoC構造、ふるまいデータを対応付け、干渉のない世界をアルゴリズムで解こうと取り組んでいます」

(※2)ECU：電子回路を用いてシステムを制御する装置（ユニット）の総称。主に自動車に搭載されるものを指す

デンソーがSoC開発に挑戦するのは、規律あるソフトウェア実行に必須のデータである「SoC構造」と「実行時の詳細なふるまい」を手に入れるため。そして同社がこれまで蓄積してきたシステム知見を生かし切るためである。「シリコンの規律を制するモノが、ソフトウェアの自由を制する。だからどうしてもシリコン・ディープダイブが必要でした」と丸目氏。

規律あるソフトウェア実行の実現には、モバイルの性能と車載の掟（確実性）を両立させることだという。この難題を解決することこそ、「きっと日本の勝ち筋になるはず」と丸目氏は力強く語り、セッションを締めた。

---

組み込みシステムの課題とデンソーSoC開発部が目指すモノ

株式会社デンソー
SoC開発部 SoCアーキ開発室
課長
片野 智明（かたの・ともあき）氏

2番目に登壇したのは、SoC開発部SoCアーキ開発室の片野氏。片野氏は家電メーカーの半導体部門でEDA技術開発やシステム検証、新規事業開拓のマーケティングなど半導体ビジネスの様々な職能を担当した後、2016年にデンソーに入社。現在はSoCのアーキテクチャ評価や技術マーケティング活動に従事している。

最初に片野氏は歴史的な変遷や組み込みシステムの課題について紹介。昭和の垂直統合の時代は、日本企業が半導体企業の上位ランキングを独占していた。片野氏が社会人になった頃から、水平分業がスタートしたという。「日本では業務としての水平分業だったが、世界では事業レベルで水平分業が進んでおり、ファンドリーやファブレスという専門企業が台頭。それらの企業をうまく活用してサービスやアプリケーションを提供する欧米企業の力が増し、SDA（Software-Defined Architecture）の時代へと入っていった。そしてAIの活用が当たり前の世界になるにつれ、サービスとSDAをさらに加速する状況になっている。

一方、車載組み込みシステムは、電力効率やリアルタイム性、時間管理に加え、安全性や信頼性が求められる。「これを垂直統合でやりきっているプレイヤーはまだいません」(片野氏)

一般的なSDAの開発はハードに依存せず開発し、ソフトでサービスを実現し、危険を伴わないことが多い。一方、SDVの開発では、安全性やハードウェア、ソフトウェア両輪でのサービスを成立させる必要があり、理想と現実のギャップが大きいという。それをどう埋めていくかはフィジカルAI時代への挑戦だという。

「デンソーとしては車載システムに最適なSoCを作ることを目指していますが、私個人としては日本半導体産業の復権、組み込みシステムのデファクト化を意識して活動しています」(片野氏)

車載システムに最適なSoCを作る

ありがちなシステム開発は、V字型で表される。SoCを作るところでは、RFQ（見積依頼書）の項目ベースで要求仕様を確認し、過去の知見やノウハウで開発が行われていくのだが、実際にコンポーネントを組み上げて全体を動かそうとすると動かなかったり、期待した性能が出なかったりして、実現したかった機能を一部諦めるところもあった。そこでデンソーはシステム知見を生かし切るために、ふるまいを意識しながらSoC構造を作り上げるというチャレンジをすることになった。

従来のSoC開発よりも仕様設計の期間は伸びたとしても、「トータルの開発期間の短縮も目指している」と片野氏は話す。

では具体的にどのような取り組みをしているのか。1つは定量的な仕様評価の実施。「シナリオ定義から機能作成、指標評価という段階を経て、実際にシミュレーションを行い、仕様の妥当性を定量的に確認しています」（片野氏）

もう一つはSoC上で動くソフト開発をバーチャルプラットフォームでシフトレフトすることである。その際に土台になるのが、「どう使うかを意識したバーチャルプラットフォームを作ることです」と片野氏。使うポイントの明確化や用途に合わせた精度と速度のバランシング、全機能をモデル化せず、ドライバ制御も想定してモデル化をしているという。

「現在、まだゴールにはたどり着いていないので、今の取り組みが本当に正解かどうか答えは出ていません。ですが、少なくとも先進的でやりたいことができていると思います。SoCを作ることだけではなく、その先を見据えて私たちは活動をしています。ぜひ、皆さんと一緒に夢を語る日が来ればいいなと思っています」（片野氏）

---

SoCをホワイトボックス化するために、SoC開発に踏み出す

株式会社デンソー
SoC開発部 SoC開発室
課長
杉田 憲彦（すぎた・のりひこ）氏

3番目に登壇したのは、SoC開発部SoC開発室の杉田氏。杉田氏は2016年にデンソーに入社。それまでは家電メーカーと通信機器メーカーで半導体を作る側/使う側の両面から、SoCおよびSiP（System in Package）の企画から選定、システム設計、ハードウェア設計、量産立ち上げなどに携わっていた。デンソー入社後はRISC-Vアクセラレータのハードウェア開発に従事。24年より、AD/ADAS向けのオリジナルSoCのハードウェア開発に注力している。杉田氏は「AIを“クルマで動かす”ための車載SoC設計― SoCシステム視点で解き明かすリアルタイム性と安全性―」というテーマでセッションを行った。

「本題に入る前に、なぜ、デンソーはSoC開発に踏み出したのか。それを整理することから始めたい」と杉田氏。ECU機能実現手段はこれまでの機械的な部品の組み合わせからSoC上で動くソフトウェアへ移行している。つまりECUの競争力の源泉もSoCに移行している。SoCをブラックボックスにすると、ECU競争力もブラックボックスになるという問題が発生する。「そこでデンソーは半導体ベンダーと共創し、SoC開発に踏み込むことで、SoCの中身をホワイトボックス化しながら、車載システムに最適なSoCを作っていくことに取り組んでいるのです」（杉田氏）

こうすることで、普及帯の車両まで搭載可能な高度運転支援技術を提供し、全ての人が安心して快適に移動できる社会の実現に貢献していくという。

性能、電力、コストを最適化する難しさ

自動運転は車両外部のセンサーから入力された情報を認知して、判断して、操作するという工程に分けられる。「実際には安全性を確保するために複数の様々なセンサーを使って、冗長性を持たせる必要があります」（杉田氏）

例えば図のように前方カメラや遠方カメラ、後方カメラ、周辺カメラ、レーダー、ソナー、GNSS（全球測位衛星システム）などのセンサーからのデータをSoCが取得して処理を行う。その処理の場面では、AI推論だけではなく、処理量や内容の異なる前処理、認識、判断、制御という処理を、特性の異なるハードウェア機能に配置し、最終的に決められた制御時間に間に合うように完了させる。「ハードリアルタイムシステムを成立させることが必要になってきています」（杉田氏）

したがってNPU（Neural Processing Unit）自体の演算性能が良くても、多種多様なセンサーデータを制限時間内にNPUに届けて、SoCシステムとして安定動作させることが課題となってくるのだ。

続いて杉田氏は、ハードリアルタイムシステムを成立させるために、SoC設計でどこをどう作り込めばよいのかを具体的に紹介した。車載SoC設計で重要なのは、ユースケースから逆算してアーキテクチャを決めることである。車載SoCは単純に性能を上げれば良いわけではない。性能（自動運転の機能ターゲット）、電力（空冷や水冷などの冷却機構、電費）、コスト（搭載車両グレード）のバランスを取りながら、ECUに最適なSoCアーキテクチャを設計することが求められる。

例えば図のような特定用途プロセッサと高性能なアプリケーションコア、高信頼性のリアルタイムコア、これらを接続するバス、データを格納するDRAMから構成されるSoCを想定した場合、具体的な設計パラメータとしては、SoCに搭載するIPの搭載数や構成（専用IP開発を含む）、動作周波数、バスアーキテクチャ／帯域設計、そして帯域競合を抑えるQoS（調停）方式が挙げられる。

「これらを机上で検討するだけではなく、モデルの検証やさらに踏み込んでSoCの実回路を使ってトレードオフの検証を行い、確実に動く設計に落とし込んでいます」（杉田氏）

さらに杉田氏はユースケースから逆算してSoCアーキテクチャを最適化する事例も紹介。

よく見ればわかるが、左右のSoCはNPUの個数はいずれも同じ。カタログスペック上のAI性能も同じである。だが、実際に車両のユースケースを実行すると、最適化前のSoC（左）は前処理を担うISPやVPUの処理性能が低く、CPUなどの既存プロセッサでは時間がかかる処理もある。その上、ベストエフォートで良い処理とハードリアルタイムでやらないといけないNPUの処理のバス競合が発生すると、NPU側の処理時間が長くなるなど、求められる性能時間内に処理が完了できず、電力、面積も目標値を達成できないという状況になっていた。それに対して最適後のSoC（右）では、ユースケース起点で設計パラメータを調整している。「具体的にはIP搭載数の見直しをしています」（杉田氏）ISP・VPUの数を2倍に増やして処理を早め、時間がかかっている処理に対して専用IPを搭載することで、一気に時間を短縮。さらにバスアーキの分離で競合の元を構造的に減らしたり、動作周波数やQoSの優先度をユースケースに合わせて設定したりして、性能、電力、面積のバランスを取りつつ、制御期間内に処理が完了するというハードリアルタイムシステムの安定した成立条件に落とし込む設計を行っている。

「このようにデンソーは自分たちが持つ豊富な車両のユースケースを活用して、ユースケース起点でSoCアーキテクチャを設計することで、性能、電力、コストを最適化することに取り組んでいます」（杉田氏）

---

車載NPUの特徴

株式会社デンソー
SoC開発部 AI-IP開発室
担当係長
和田 健太朗（わだ・けんたろう）氏

最後に登壇したのはSoC開発部 AI-IP開発室の和田氏。AI-IP開発室ではAIやディープラーニングモデルを動かすためのNPUを開発している。和田氏はNPUを開発しているスタートアップでコンパイラの開発、AIエンジニアとしてディープラーニングモデルの開発やエッジデバイスへの実装、さらには量子計算SDKの開発などに従事した後、2025年にデンソーに入社。「自動車業界に携わるのは初めて。こうした経歴でもデンソーの中で車載NPU開発に貢献できることを感じてほしい」と前置きし、「車載NPUという挑戦-ディープラーニングモデルとNPUの共進化」というテーマでセッションを開始した。

今やNPUは様々なデバイスに搭載されているが、中でも車載NPUの特徴は、「要求される水準が非常に厳しいこと」と和田氏は語る。

例えばプロセッサの回路面積は製造コストや製品価格競争力に直結するため、省面積が要求される。また消費電力についても同様だ。限られた電力で、幅広い温度環境、限定された冷却能力の中で、長時間にわたって安定して稼働を続け無ければならない。演算性能についても、決められた時間内にリアルタイムに処理を実行できなければならないという強い制約がある。しかももう一つ車載SoCの特徴は、開発期間が年単位でかかること。「しかもリリース後の運用期間も長いという特徴もあります」（和田氏）

製品リリース以降の未来の自動運転モデルを高効率に推論できなければならない。このように車載NPUは「本当に難しいところを攻める開発です」（和田氏）

ディープラーニングモデルとNPUはお互いに影響を与えながら進化しながら、適用領域を拡大してきた。

現在のディープラーニングブームは、2010年頃に登場したCNN（畳み込みニューラルネットワーク）から始まっているという。その代表例「AlexNet」は、CUDA（Compute Unified Device Architecture）のカーネルコードで実装されており、NVIDIAのGPGPUで学習や推論が行われていた。その後、CNNから「Attention is All You Need」という論文でトランスフォーマーモデルが登場。大規模なトランスフォーマーモデルであるLLM（大規模言語モデル）は、モデルのパラメータ数や学習のデータ量、演算量を大きくすれば性能が向上することがわかった。

そしてこの進化を支えるNPUも同様に進化している。2016年に登場した「Google TPU」は、シストリックアレイ型という行列同士の掛け算を効率的に行える専用の演算器を搭載していた。これはデータセンター向けのNPUだったが、その後、NPUはスマートフォンやPCにも搭載され、さらには車載のSoCにも搭載されるようになり、「適応領域をどんどん拡大してきました」と和田氏は説明する。

このようにディープラーニングモデルの進歩は、それを支える計算資源の進歩と共にあり、GPGPUやNPUも共に進化しているのだ。

続いて和田氏は自動運転のためのディープラーニングモデルの特徴を紹介。

例として挙げたのは今年初めに公開されたオープンなモデルのNVIDIA「Alpamayo」と、プロプライエタリモデルのWayve「LINGO」。これらはいずれもビジョンランゲージアクションモデル（VLA）と呼ばれ、視覚情報と言語情報、制御情報を一体として処理できるモデルである。「自動運転のためのディープラーニングモデルは、E2E（センサー入力から軌道や制御コマンドの出力までを単一のモデルで処理する方式）や、さらにその先にあるVLAモデルが主流になりつつあります」（和田氏）

VLAモデルは、ロングテールの安全性や言語による理由の説明を重視して開発されている。そのため、パラメータ数もレイテンシも大きくなる。「このまま現在のNPUで動かすのは非常に難しいと思う」と和田氏は指摘する。軽量化や小型化をすることも考えられるが、制御はリアルタイム性にすぐれる軽量なE2Eモデルを頻繁に回し、難しい局面でVLAをゆっくり回すなど、「2つのモデルを活用してシステムを処理させることも考えられています」と和田氏は説明する。

車載NPUに求められる性能とその実現方法

NPUに求められる性能面についても解説。それを視覚的にわかりやすく表現したのがルーフラインモデルである。図を見ればわかるように、ある点で演算器の性能が折れ曲がる。これは演算器とメモリ帯域が100％使われる状態になっていることを表している。「演算器の性能とメモリ帯域がちょうど折れ曲がる点にはまるように設計すれば、演算器もメモリ帯域も無駄になることはありません」（和田氏）

ディープラーニングモデルではNPUが得意とする演算強度の高い問題が主要な部分を占めている。だが一方で、演算強度が低くてメモリ転送が問題になりやすい処理もある。「NPUの設計においては、解こうとしている問題の性質に応じて、メモリ帯域と演算器性能のバランスが重要です」（和田氏）

トランスフォーマーモデルの演算強度の特性についても解説。処理はレイヤーの上から下へと進んでいくのだが、その中には演算強度の低い処理と高い処理が入り交じっている。NPUの処理において、和田氏は3つの重要なキーワードも紹介。1つ目のKV Cacheは過去に計算したキーとバリューをメモリにキャッシュしておき、それを再利用することで計算コストを削減する技術。「処理時間は削減できますが、演算強度は低下し、メモリ帯域の要求が上昇します」（和田氏）

2つ目のFlash Attentionは、Attention計算の際にメモリ階層の特性に応じて演算の分割とデータ移動を設計することで、メモリ転送量を削減し、演算強度を向上することができる技術である。

3つ目のReductionとは、SoftmaxやLayerNormのような、演算強度の低い、ボトルネックになりやすい処理。こうした処理に対しては、専用演算器を搭載したり、パイプライン化、レイヤー融合によってレイテンシの隠蔽を図れるようにするという。

「こうした最適化はディープラーニングモデルの演算特性を理解した上で、まずはソフトウェア的に行いますが、中には、ハードウェアの設計に反映して初めて効果が出るものもあります。つまり、ソフト・ハード両面からNPUを設計している会社だから、攻めた開発ができる。エンジニアとしても本当にいろんなことが経験できるので、ぜひ、興味のある方は私たちのチームに参加してほしいと思います」（和田氏）

---

質疑応答

SoC開発の現状が開かされた今回のイベント。参加者から多くの質問が寄せられた。

Q. どれくらいの精度のデータを取得する必要があるのでしょうか。

丸目氏：規律ある運用を実現するためには、厳密な設計が不可欠であり、スマートフォンに比してより高度な、具体的にはミリ秒単位の精度を有するデータの取得が求められます。さらに重要となるのは、資産の利用状況や相互干渉を可視化することです。これが不十分だと問題の所在特定が困難になります。

車載SoC開発では、プロセスが順調に進行する事例は少なく、特に性能面で多様な課題に直面します。これらを迅速に解決するには、根拠となるデータを詳細かつ正確に把握することが必須です。このため、高精度なデータが不可欠となります。

Q. E2Eモデルについて、今後NPUではどのような対応が求められるのでしょうか。

和田氏：E2Eモデルを処理できるようにする必要があると考えています。そのため、製品リリース時の主流となるAD向けモデルを予測し、演算特性を十分理解した上でNPU設計に反映させることが重要だと認識しています。

Q. 処理のボトルネックを解消するために部品を追加するという方針は、スループットを重視するミッションクリティカルな環境ではとても合理的だと思います。一方で、SDVなどソフトウェアが継続的にアップデートされる場合、ハードウェア側を先に固めてしまうとソフトウェアの進化に対応しづらくなるというジレンマも生じます。この課題は多くの人が直面しているはずですが、どのように解決していくお考えでしょうか。

杉田氏：処理性能の観点から、SoC設計時には設計マージンを十分に確保することで対応しています。さらに、処理内容の変化が少ない領域については専用ハードウェアへの割り当てを検討し、今後も柔軟な対応が求められる部分についてはプログラマブルハードウェアへ割り当てる方針です。また、特定要素のみをハードウェア化し、複合的な処理はソフトウェア実装とする手法も有効です。いずれの場合も、総合的な評価を基に設計判断を行っています。

丸目氏：半導体製造プロセスの進化と市場動向は必ずしも一致しないため、そのギャップの大小に応じて、専用ハードウェアの導入またはソフトウェアによる実装を選択する必要があります。

Q. AIの進化は日進月歩です。車載SoCの設計時に、市場に出る1～ 2年先のAIモデルを予測できるのでしょうか。

和田氏：まずある程度の汎用性を持たせて変化に対応する考え方が一つ。次に、過去の進化の流れを振り返りながら、5年後や10年後のモデルをより正確に予測することも重要です。さらに、私たち自身がそのモデルを開発し定義していくというアプローチも考えられると思います。

Q. カスタムアプローチを前提としてのご説明と思いますが、汎用品のメリットもあると思うのですが。

丸目氏：汎用品が利用可能な場合には積極的に導入すべきと考えます。しかしながら、私見としては、AIの処理においては垂直統合型アプローチが最も高い効率性を発揮すると認識しています。すなわち、用途に応じてソフトウェアやアルゴリズムを設計し、それに最適化されたハードウェアを開発することが重要です。このような垂直統合を通じて、設計から実装まで一貫して手掛ける必要があり、その両輪を同時に推進する体制が不可欠であると考えております。

Q. 世の中でSDVと騒がれている中で、ソフトウェアエンジニアの必要性が高まっていると思いますが、その中でも、ソフトウェアとハードウェアの架け橋となるエンジニアに求められているスキルや特徴は何だと思いますか。

丸目氏：最適なものをつくるためには、ソフトとハードのどちらも分かることが重要だと思います。というのもソフトもハードも目的を達成するための手段でしかないからです。ソフトやハードだという専門性に固執せずに、壁を取っ払って、自由に会話できるような環境をつくることが大事だと思います。

杉田氏：ハードエンジニアとして仕事をする場合でも、そのハードウェアがどのように使われるかをきちんと理解して開発しなければ、期待した性能を発揮できないことがあります。ですので、両方の側面を把握することが大切だと思います。

片野氏：ハードをやるにしてもソフトをやるにしても、両方を分かっている人はエンジニアとして強いと思います。

株式会社デンソー
https://www.denso.com/jp/ja/

株式会社デンソー　ソフトウェア特設ページ
https://careers.denso.com/software/