IEC 61508、パート 3、付属書 F によるソフトウェア要素の独立性を正当化して、安全関連コンポーネントを SIL 2 と評価し、非安全コンポーネント (UI、通信など) を評価しないままにすることは可能ですか? SIL 2 と評価された全体的な結果がまだありますか?
特に、安全要素と非安全要素がすべて単一のプロセッサで実行されており、プロセッサがハードウェア メモリ保護の形式を実装していない場合の見解に関心があります。ソフトウェア要素が干渉しないようにするためにできることはたくさんあります。たとえば、データの整合性を確保する、データの受け渡しが厳密に制御および検証される、タスクのスケジューリングが決定論的である (安全でないタスクの終了が保証される)、およびすぐ。
そのような技術を厳密に適用するだけで十分でしょうか?
これは明確な答えがない質問です。答えは単に意見に基づいているか、特定の条件に依存しています。
評価または認証を行う会社/組織がある場合は、そのアプローチに問題がないかどうかを尋ねる必要があります (明確にするために編集: )。私が理解する限り、安全性が重要なデバイスの開発に関する基準を理解している限り、考えられるすべてのリスクを考慮したこと、および考えられる障害をどのように検出または防止するかを文書化する必要があります。
同様の規格に準拠することが認定されるプロジェクトでは、すべての安全関連データとコードを特定のメモリ セクションに配置し、安全関連機能を終了した後に CRC を計算して安全関連データ セクションを「ロック」し、CRC をチェックします。再び入る前に。
さらに、データを「ロック」する関数が安全関連のコード セクションから呼び出されていることを、戻りアドレスをチェックすることによってのみチェックします。安全関連データの予期しない変更が検出され、デバイスは安全な状態になります。
私たちの場合、このアプローチは、ソフトウェア開発をチェックする責任者を納得させるのに十分でした。
編集(コメントに回答するため)
もちろん、影響を受けるデバイスで説明されている目的には、このソリューションで十分であると確信しています。
このメカニズムは、デバイスの安全コンセプトの一部にすぎません。
ここで説明するCRCメカニズムは、非安全機能からの安全関連機能の独立性を確保するために、非安全機能による不要な変更からRAM 内の安全関連データを保護するために使用されます。(フラッシュ メモリ内のバイナリ プログラムを変更から保護することとは関係ありません。もちろん、ECC フラッシュと CRC を使用してこれを行います。)
別の編集: また、安全関連のペリフェラル レジスタが予期せず変更されていないことも定期的にチェックします。
ハードウェアとソフトウェアには他にも多くの安全対策がありますが、これらはMPUなしでソフトウェア部分の独立性をどのように正当化するかという問題とは関係ありません.
ここで説明する技術を使用するデバイスは、安全レベルが約 2 の別の規格に準拠しています。SIL 1 と SIL 2 の間。
もちろん、すべてのユーザーは、このソリューションが特定のデバイスに十分かどうかを確認する必要があります。