機能安全アプリケーションにおけるコンパイラ課題の克服

業界を問わず、機能安全は開発者に厳格な要件を課します：メモリ破損や宇宙線干渉などの予期せぬ事象に対して、コードを防御的に設計しなければなりません。CやC++などの高級言語には、言語仕様で完全に定義されていない振る舞いを持つ機能が含まれます。これらの未定義動作は、安全クリティカルシステムにおいて驚くべき、潜在的に破滅的な結果を招く可能性があります。したがって、標準規格は防御的コーディング、厳格なテスト容易性、包括的なコードカバレッジ、要求からアプリケーションコードへのトレーサビリティを義務付け、安全機能の完全かつ一意な実装を保証します。

特に自動車などの安全クリティカル分野では、高度な外部診断、較正、開発ツールが要求されることが多々あります。防御的コーディングと外部データアクセスは、コンパイラが本質的に理解する概念ではありません。CもC++もメモリ破損を想定していないため、防御策がコード内で明示的に到達可能でない場合、コンパイラはそれらを最適化で削除してしまう可能性があります。したがって、防御策は構文的・意味的に到達可能なまま残す必要があります。

未定義動作を見つけるのは非常に困難です。特定できても、コンパイル済みバイナリが意図通りに振る舞う保証はありません。デバッグツールで使用される「バックドア」データアクセスも、コンパイラが考慮しない言語構造の一例であり、予期せぬ副作用を招きます。

コンパイラ最適化は、到達不能パス（どの入力でも実行されないパス）上にある見かけ上妥当な防御コードを削除することがあります。ユニットテストでカバーされているコードでも、最終ビルド時に除去されることがあります。したがって、高いソースレベルカバレッジが、実行ファイルに意図した安全チェックが含まれることを保証するものではありません。

したがって、失敗が深刻な結果を招くシステムでは、オブジェクトコード検証（OCV）がベストプラクティスです。OCVは、コンパイル済みオブジェクトが開発者の意図と一致することを確認します。これは、コンパイラが安全前提に違反する形でコードを変換する可能性がある場合に不可欠な要件です。

コンパイル前後

機能安全、セキュリティ、コーディング標準（IEC 61508、ISO 26262、IEC 62304、MISRA C/C++）は、要求ベーステスト中にソースコードのどの程度が実行されたかを示す必要性を強調します。高カバレッジはフィールド故障確率を低減しますが、コンパイラがソースレベルの振る舞いを忠実に再現するという前提に依存しており、最もクリティカルなアプリケーションではこの前提を正当化できません。

生成されたオブジェクトコードの制御フローとデータフローは、ソースコードと完全には一致しません。オブジェクトコードとアセンブリの1対1マッピングで相違が明らかになります。例えば図1は、TIコンパイラで最適化無効時にソーススニペットから生成されたアセンブリを示します。最適化を有効にすると、コンパイラが未定義動作の不在を前提に数学的変換を適用するため、フローグラフが劇的に変化します。

図1：ソースとアセンブリの比較。最適化が制御フローをどう変えるかを示す。

コンパイラは、関連分岐が到達不能と判断した場合、防御的呼び出しを最適化で削除することがあります。図2は、CLANGコンパイルで状態変数が2値しか取らないと推論され、エラーハンドラ呼び出しが削除される例です。この最適化は効率的ですが、防御的コーディングの安全意図に違反します。

図2：CLANGが到達不能分岐のため防御的エラー呼び出しを削除。

周囲のコンテキストを変更すると、コンパイラの最適化判断が変わることがあります。図3では、状態変数にアクセスする新関数を追加することで、コンパイラが分岐を潜在的に実行可能と判断し、防御的呼び出しを保持します。さらに、状態へのポインタを返すなどの変更で、コンパイラはアセンブリで明示的な値を保持せざるを得なくなります（図4）。

図3：コンテキスト変更で防御的分岐が保持される。

図4：ポインタエイリアシングで防御コードの最適化が防止される。

ユニットテストハーネスでは、ポインタ経由で状態を操作すると防御コードが最適化で削除されなくなりますが、この振る舞いは本番ビルドでは持続しません。したがって、ユニットテストカバレッジだけでは、欠落した安全チェックがマスクされる可能性があります。

オブジェクトコード検証

OCVは、ソースとアセンブリを比較することで安全網を提供します。図6は、単一テスト呼び出しで実行すると100%のソースレベルカバレッジを達成する簡単な関数を示します。しかし、アセンブル済みフローグラフ（図8）は、ユニットテストが見逃した未実行パスを露見させます。すべてのアセンブラパスをカバーするようテストを強制することで、OCVはソースレベルテストが見落とすギャップを発見します。

図6：ユニットテストで100%カバレッジを達成するソースコード。

図7：ソースの基本ブロックフローグラフ。

図8：アセンブル済みフローグラフ。未テストパスが露見。

OCVはコンパイラの最適化ルール適用を防止できませんが、開発者意図と実行ファイル振る舞いの不一致を浮き彫りにし、製品展開前に是正措置を講じることを可能にします。

すべてのドメインにおけるベストプラクティス

多くのシステムでは、ソースレベルユニットテストカバレッジで認証機関を満足させられます。しかし、航空宇宙、自動車、医療、産業など、最もクリティカルな安全クリティカルアプリケーションでは、ソースカバレッジにOCVを補完することが不可欠です。OCVは、コンパイル済み製品を標準規格が要求する厳格な安全要件と整合させ、実行ファイルが意図通りに振る舞う最高の信頼性を提供します。