SDV化時代における機能安全対応の落とし穴

車両の各ECUが統合化され、HPC（High Per- formance Computer）上の機能がソフトウェアにより実現するようになる、さらにOTA（Over the Air）によるソフトウェアのUpdateにより車両の機能や性能向上を図ることができるようになってくる。

そして、従来のソフトウェアに対して、指数関数的な規模に増大する。また、SDV時代には、「ソフトウェアを迅速に進化させる能力を持つもの」が勝ち残るようになってくる。図1にハードウェアからソフトウェアへシフトするイメージを示す。

HPC/SDV 化時代の車載システムの変化の流れについて説明する。
車載システムの変化には、大きく3つの流れがある。

・従来：Many-ECU（70-200 ECU）…（2 階建て）
・現在：Zone-ECU（3-5 ECU） …（10 階建て）
・未来：HPC（1-2 ECU） …（101 階建て）

HPC/SDV化が進むにつれて、以下に示す課題が発生する。

1. 小規模組込みソフトウェアが、超大規模ソフトウェアに変化する。
2. ECU数が激減しECUの製造会社がソフト開発会社化する。

建築物に例えると、2階建ての家の集合体が10階建てのビルの集まりに変化し、さらに101階建ての超高層ビルに変化するイメージに例えると、わかりやすくなる。（下記図2参照）

Tier1：ハードウェアを含むECUの受注からソフトウェアのみの受注への変化
製造業として工場を稼働し、ECUのハードウェアを納品していたが、ソフト開発会社になると工場がなくなる。

OEM：カーOEMによるECUのシステムアーキテクチャ設計及び、ソフトウェア開発の内製化
従来はサプライヤーが開発していた部分を OEMが開発する事になるため、ノウハウ不足となる。

例）システムアーキテクチャ設計、機能安全/サイバー ・セキュリティ設計、SoC/MCU/OS選定、共通基盤ソフトの設計・実装、ソフトウェアコンポーネントの結合テスト、システム性能の担保、システムリソース（CPU/GPU/NPU、メモリ、 Storage）のコントロール

OEM側の課題に対しては、OEMとTier1が一緒になって開発を進めていくことにより解決できるが、OEMが中心になり動く必要があるため、組織づくりを含めた課題を解決していく必要がある。

従来の個別ECU開発は、MCUや周辺ハードウェアとOSを含む、PF部分も含めて、各Tier1が開発していた。
分かり易くするために、これを建築に例えると、町の大工さんによる2階建て家のイメージになる。
図3の左側に個別ECU開発の場合のイメージ図を示す。

「App1」と「App2」の緑枠で囲まれた部分が個別ECU開発会社の差別化技術とすると、それ以外のOS等のソフトウェアは、Tier1として準備すべき家のインフラ相当になる。従来Tier1は、非競争領域であるインフラ部の開発に苦労していることになる。

HPC化した時のソフトウェアは、超大規模化する。ビルに例えると101階建ての超高層ビルのイメージになる。図3の右側に超高層ビルのイメージ図を示す。

図3の右側の超高層ビルのインフラである（耐震設備、超高速エレベータ、水回り、空調システム）にあたる部分（図3右の青枠）をOEM側が基盤ソフトウェアとして提供することが必要になる。

1. 基盤ソフトウェアの例
OS間通信の仕組み、OS内のプロセス間通信の仕組み、不揮発メモリのアクセス及び寿命の担保設計、不具合解析に必要となるダイアグ情報を保存する為の仕組み、性能解析の為の仕組み、システムのエラーリカバリー処理、OTAの仕組み、Security担保、FFI（パーティション分離）、システムのライフサイクル管理等

2. 基盤インフラの例
また、 基盤インフラとして重要な、大規模SoC、MCU、Hypervisor、各機能に必要なOSの選定もインフラとして準備すべきものとなる。対策案については、次のADASとCockpit統合化時の課題の中で説明をする。

図4に示す通り、 大規模SoCを使っ て、ADAS部とCockpit部を統合すると、機能安全対象のADAS部とQMのIVI部が一つのSoCに混在することになり、FFI（Freedom From Inter-ference）の課題が発生する。

ADAS部の機能安全対象部分が、QMの機能と完全に分離し、QM部がASIL部に影響を与えないように分離することが求められるが、本内容を実現するためには、複数ある技術課題を解決しないと乗り越える事が出来ない。

具体的には、以下の課題を解決していく必要がある。

1. パーティショニングが可能なSoC（車載用システムLSI）の選定
2. OSの影響を受けないHypervisor（仮想化ソフトウェア）の選定
3. Hypervisorとの組合せで動作するOSの選定
4. 安全目標（SG）毎のハードウェアメトリクス（*7）の達成設計
5. Safety Manualに準拠したシステム設計

自分達が開発する機能の安全目標（SG）に対応できるようにするためには、SoC/MCU、Hypervisor、OSのSafety Manualに記載されている使用の前提条件（Assumption Of Use）に従った設計・実装をすることが必要となり、高度なスキルが求められる。

対策としては、 各SoC等のハードウェアやHypervisorやOS等の高難易度ソフトに対して見識のあるメンバーを集めることが必要となる。

さらに、機能安全、Cyber Securityのシステム設計も同時進行で行う必要があるため、上記の技術スキルだけでなく、機能安全とCyber Securityのスキルを併せ持った人材が必要となる。

"統合化によるソフトウェアの超大規模化"で挙げた様に、ソフトウェアが超大規模化すると開発するシステムの規模によるが、開発者の数が1,000～10,000人に増え、さらに開発はグローバルで行われるため、世界中に開発者が分散することになる。（日本、アジア、欧州、北米）

その時に発生する課題が、1,000人以上の開発者全員に開発環境のボードを提供し、開発中はボードのメンテナンス（開発のサンプル時期によりハードウェアの Update）が必要になることである。

1. 開発ボード数を減らす。（1 万人居ても300台程度）
2. 上記を行うため、Cloud上でのソフト開発環境が必要
3. ターゲットとCloudのどちらで開発しても、性能や機能安全対応を可能にするためのツールや仕組み化が必要
4. 車両のHPCに接続されるECUが車載LAN（CAN, LIN, Ethernet）経由で接続されており、その部分をどのようにすべきか検討が必要

図5にターゲットとCloud開発環境の共通化のイメージを記載する。

1. ターゲット開発環境は、システムテスト担当及びSW-PF部実装部隊（OS/ デバドラ開発者）、グラフィック部の性能部の開発者、ADASの実機評価者等、最低限ターゲット開発環境が必要な人達に限定する。
2. Cloud上に、ターゲットと同等に見える仮想環境を構築し、Cloudでもターゲットでも同じソフトウェアが動作するしくみを構築する。
3. Cloudとターゲットで同一バイナリが動作するようにするため、ARM搭載Cloud上に Hypervisorを搭載し、疑似的にRTOS部、Linux部、 Android部が動作する仕組みを構築する。Hypervisorも、ターゲットSoCとCloudで同等の動作をさせることができるものを選択する必要がある。
4. SoC内蔵のCPUの中でリアルタイムCPU（Cortex R52等）の場合は、Cloud上でCPUの動作をSimulationして動作させる。
ARM社の場合は、ARMのCP 用のSimulatorを準備しているため、CPU Simulatorの活用が可能となる。図5の”CPU Simulator 部”を参照
5. 機能安全に必要となるエビデンスについては、ターゲット環境とCloud環境のどちらでテストを実行しても結果に差がないことを説明することが可能なツールの選定が必要となる。
6. 車載LAN接続ECUについては、疑似的な評価用デバイスを準備して、特定のユースケーの通信シーケンスを通すことができる環境を構築することが必要である。

実際に、ADAS/Central-GW/Cockpit機能を統合したHPC化が進むと、他にも多くの課題が発生すると想定でき、従来の延長線上の開発の進め方では対応が困難になる。
また、HPC内の機能安全Safety Goal（SG）の設計及び、各SG毎のハードウェアメトリクスの達成についても、機能が集約しSoC等のハードウェアが大規模化することにより益々困難になる。

今後は、関係するOEM/Tier1が集結した開発が行われる事が期待され、開発スタイルも車両全体のTOPダウン型での開発に変わってくると考えられる。
是非、日本の車載システムの新たな開発スタイルとして定着できるように進めていきたい。

※水山 正重：「SDV の潮流とキーテクノロジー」Edge Tech 2022
※安田 威彦：「SDV 化時代の機能安全対応の落とし穴」機能安全カンファレンス 2024