週刊アスキー

  • Facebookアイコン
  • Xアイコン
  • RSSフィード

「不良品ゼロ」と「水冷NG」の狭間で。ルネサスが明かした車載チップレットSoCのリアル

2026年05月25日 12時00分更新

車載ECUに課される「欠陥ゼロ(Zero Defect)」の厳しい現実

 これまでのことを踏まえると、ECUに求められる仕様はかなり厳しい。下の画像がそのまとめであるが、温度範囲やOperation Life Timeはともかく、Failure Rateが"Zero Defect"(不良品ゼロ)を目指しているというのはそれなりにわけがある。

ECUに求められる仕様。PPMは百万分率、PPBは10億分率である。つまり1PPMは10-6、あるいは0.0001%で、1PPBは10-9、あるいは0.0000001%である

 ECUはSoC単体で実現されるわけではなく、さまざまな部品から構成される。例えば1個のECUに250個の半導体部品が搭載され(パッシブデバイスまで含めればそのくらいの数はすぐにいく)、1つの車にECUが50個(さすがにこれは高級車グレードだろう)搭載されるとすると、例えば部品の故障率がすべて1%だとしても、トータルすると「どこかのECUが壊れる確率」は1%を超える計算になる。

 これが1PPBだとすれば、0.001%程度とまだ許容されるわけだが、1PPBというのは10億分の1なので10億個部品を作って、そのうち1個が故障していても許される(=9億9999万9999個は正常でないといけない)わけで、10億個も部品を作るのが実際にはレア(コンデンサーならそのくらいの数はいくかもしれないが、SoCが10億個も製造されることはない)である以上、要するに欠陥ゼロが必須だ。

開発コストを抑えつつ多品種展開を可能にするチップレットの必然性

 ここまでが車載ECUに求められる基本的な特徴で、ここからが今後の話である。車載ECUといっても、その用途に応じて求められる性能が変わってくる。また大きなダイサイズは歩留まり悪化につながるので、必然的にチップレットにならざるを得ないとし、実際に機能別の作り分けをすることで開発コストを抑えながら用途別SoCを作り出せるとしている。

これまでは特に機械的強度やBOMコスト削減などの観点からモノリシックなダイで構成するのが一般的だった自動車向けSoCだが、ついに岐路に達した

開発コストを抑えながら用途別SoCを作り出せるが、これはあくまでもコンセプトである。実際にはこれをやろうとすると結構大変ではある

 チップレット構成で考えるべきことはなにか? というのがここからの話だ。物理的に、振動・温度などの自動車環境に耐えられるチップレットを「物理的に」どう構築するかという話は別にして、その上で動くチップはどうあるべきかという話である。これはセキュリティというよりも安全性(機能安全)の話である。

チップレット構成で考えるべきこと。自動車向けの場合、セキュリティ要件が非常に厳しい。それもあって、新たにRegion IDを導入するとしている

 車載システムといっても、用途別にさまざまなものがあり、ところが実際にはこれを1つのSoCの上に載せようとしている。ここで例えばIVIに属するカーナビのプログラムがVCPに影響をおよぼして機能を止めたりしたら絶対にまずい。そこでそれぞれの間にきちんと障壁を設け、それぞれが独自に動く(壊れても他に影響を与えない)構成が求められる。

IVIはIn-Vehicle Infotainment、要するにカーナビやオーディオ類。Serviceはクラウド連携、ADASはAdvanced Driver-Assistance Systemsで運転支援、Clusterは計器パネル表示、VCPはVehicle Control Processorで車体制御を担う部分。右に行くほど、重要性が高い(壊れると運転どころか生命に関わる)

 といっても、実際にはまったく無縁では問題がある。例えばカーナビもADASも車速の取得が絶対に必要になるが、それはVCPに属するところからデータをもらうしかない。したがって内部で障壁を超えてのデータ交換は当然発生する。この際にRegion IDというIDを付けて管理することで、そのデータを受け取って良いものか、あるいはそのデータを送り出してよいものかを判断しようとしている。

実際にはRegion IDに紐づく形でACL(Access Control List)的なものがあり、これに沿ってどんなアクセス/行動が可能なのかをきちんと定義している。詳細は後述

 これをチップレットにも適用しよう、というのが今回の提案である。実際のアプリケーションでのアクセスのイメージが下の画像だ。それぞれのドメインごとにMaster IPが配され、これがユニークなMaster Region IDを持ちアクセスの主体となる。

ACLの保持にはSMMU(System MMU)を使う形でSoCとチップレットのACLの同一性を担保する仕組みの模様

 一方で周辺機器やメモリーなどはそれぞれSlave Region IDを持ち、ここでRegion IDに併せてR/Wの制御ができるとする。その仕組みが下の画像だ。

もう少し細かい制御が必要では? という気もするが、模式図だからこんなものなのだろう

あくまで模式図なのだが、どうもそれぞれのアドレスを利用してIDの識別に使っている模様。楽かもしれないが……

この記事をシェアしよう

週刊アスキーの最新情報を購読しよう

本記事はアフィリエイトプログラムによる収益を得ている場合があります

この連載の記事