【ITニュース解説】How to Validate FFI Between QM and ASIL-D in Zero-Heap AUTOSAR + HSM

このニュース記事は、自動車の安全に関わるシステムを開発する上で非常に重要な「FFI（Freedom from Interference：干渉からの自由）」という概念について、その検証方法と結果を説明している。自動車のような厳格な安全基準が求められる分野では、一つのシステムの不具合が他の部分に悪影響を与え、甚大な事故につながることを防がなければならない。FFIとは、まさにシステム内の異なる部分が互いに干渉し合わないことを保証する考え方だ。

記事では、特に安全性レベルの異なる二つの領域、「QM（Quality Management：品質管理）」と「ASIL-D（Automotive Safety Integrity Level D）」の間で、FFIがどのように確保されているかを示している。QMは一般的な品質管理レベルであり、ASIL-Dは自動車機能安全規格ISO 26262で定められた最高レベルの安全性要求だ。例えば、カーナビのような情報表示系はQMレベル、ブレーキやステアリングのような生命に関わる制御系はASIL-Dレベルに分類されることが多い。ASIL-Dのシステムに不具合が発生すると、命に関わる重大な結果を招く可能性があるため、QMの領域からの予期せぬ影響を絶対に防ぐ必要がある。

このシステムは「Classic AUTOSAR R22-11」という自動車向けの標準ソフトウェアアーキテクチャに基づいている。AUTOSARは、自動車に搭載されるECU（電子制御ユニット）のソフトウェア開発を効率化し、信頼性を高めるための共通基盤だ。このシステム設計の大きな特徴は、「Zero-Heap（ゼロヒープ）」であること。これは、プログラムの実行中に動的にメモリを確保する「ヒープ」という領域を使わず、すべてのメモリをあらかじめ静的に割り当てることを意味する。動的なメモリ割り当ては、メモリ不足や解放忘れといったバグの原因になりやすく、予測不可能な挙動を引き起こす可能性があるため、安全性が最優先されるシステムでは避けるべきとされている。これは「MISRA Rule 21.3」という、組み込みシステム向けのコーディングガイドラインにも準拠している。

FFIを確保するために、このアーキテクチャでは主に二つの分離技術が用いられている。一つは「空間的分離」だ。これは、「MPU（Memory Protection Unit）」というハードウェア機能を使って、異なる「OS-Application」ごとにメモリ領域を厳密に区切り、互いに相手のメモリに勝手にアクセスできないようにする仕組みだ。例えば、QMのプログラムがASIL-Dのメモリ領域に誤って書き込みを行おうとしても、MPUがそれを検知して阻止する。もう一つは「時間的分離」だ。これは、「OsTaskExecutionBudget」や「タイミング保護」といった機能により、各タスク（プログラムの実行単位）が使用できるCPU時間や実行時間を厳しく管理し、あるタスクが無限にCPUを占有して他のタスクの実行を妨げたり、重要な処理のタイミングを狂わせたりすることを防ぐ。

異なるOSアプリケーション間の通信には、「IOC（Inter-OS-Application Communication）」が使われている。さらに、この通信には「E2E Profile P11（End-to-End Profile P11）」というプロファイルが適用されている。これは、データの送信元から受信元まで、データが途中で破損したり改ざんされたりしていないかを確実に検証するための仕組みであり、通信の信頼性を高める。

システムのセキュリティと安全性をさらに強化しているのが「HSM（Hardware Security Module）」の存在だ。記事では「Evita Full HSM, FW 3.1」が採用されていると記載されている。HSMは、暗号化キーの安全な保管や、セキュアブート（安全な起動）の検証、暗号処理の実行などを行う専用のハードウェアモジュールだ。このシステムでは、HSMが単なる暗号化の高速化装置としてではなく、「安全の番人（safety guardian）」として非常に重要な役割を担っている。

具体的には、QMドメイン（領域）からはASIL-Dレベルの重要なデータ、例えば「NVM（Non-Volatile Memory：不揮発性メモリ）」に保存された設定や、「キー（暗号キー）」、あるいは機密性の高い「セキュアRAM」に物理的にアクセスできないように設計されている。すべての暗号サービスは、「CSM（Crypto Service Manager）」というAUTOSARの暗号サービス管理レイヤーを介して、「Crypto Driver」を経由し、最終的にHSMで処理される。これにより、HSMが持つ「SHE+ key isolation」（キーの分離保護）や「secure boot verification chain」（セキュアブート検証チェーン）、そして「hardware firewall」（ハードウェアファイアウォール）といった機能が最大限に活用され、ASIL-D領域のデータや処理が不正なアクセスから厳重に保護されている。

このような厳密な設計が本当にFFIを保証できているかを確認するために、「HIL Validation（Hardware-in-the-Loop Validation）」という検証手法が用いられた。これは「dSPACE SCALEXIO HIL」というシステムを使って、実際のハードウェア（ECU）とシミュレーション環境を組み合わせてテストを行う方法だ。実機に近い環境で検証することで、机上の設計では見つけにくい潜在的な問題を発見できる。

検証では、非常にアグレッシブな「故障注入キャンペーン」が実施された。これは、意図的にシステムに故障やエラーを発生させ、それがシステム全体の安全性にどのような影響を与えるかを評価するテストだ。具体的には、QMタスクから「ポインタ破壊」（メモリのアドレスを不正に操作すること）、「スタックオーバーフロー」（プログラムが使用するメモリ領域であるスタックを使い切ってしまうこと）、そして「MPU違反」（MPUで保護されたメモリ領域への不正アクセス）といった、ソフトウェアの脆弱性を狙った1000以上のテストが試みられた。

その結果は、「100% containment（完全に隔離）」という素晴らしいものだった。つまり、QM領域からどんなに意地悪な攻撃やエラーを注入しても、ASIL-D領域のデータが破損することなく、ASIL-Dタスクの実行タイミングが狂うことも一切なかったのだ。さらに、万が一システムに異常が発生した場合に、安全な状態へ移行するまでの時間（safe-state transition）も測定され、「8.7µs（マイクロ秒）」という非常に短い時間で完了することが確認された。これは、安全状態への移行にかかる時間の上限として定められている「FTTI（Fault Tolerant Time Interval）Requirement：10µs以下」という厳しい要件を十分に満たしていることを示している。

結論として、このアーキテクチャはISO 26262-6 Annex D（自動車機能安全規格のソフトウェアに関する部分でFFIの検証ガイドラインを定めている）に完全に準拠したFFIを達成している。メモリ、タイミング、データ交換のいずれにおいても、ASIL-D領域への干渉は一切確認されなかった。この結果は、設計されたアーキテクチャがASIL-D製品としての監査を受ける準備が完全に整っていることを意味している。つまり、この自動車システムは最高レベルの安全性を保証できると評価されたのだ。