3

2oo3 投票を実装する必要がある安全システムに取り組んでいます。関数ポインターを使用してステートマシンを使用してこれを実装するというアイデアを大まかに持っています。AB・Cの3系統があるとします。 Aに対してはCが左系統、Bが右系統 Bに対してはAが左系統、Cが右系統 Cに対してはBが左系統、Cが右系統システム

システムが行う決定ごとに、関数ポインタが「左側のシステムとのデータ交換」関数を指すようにします。データが Left システムに送信された後、それはダミー関数を指し、Left システムが応答するのを待ちます。

左システムが応答し、その決定 (左システム) もシステム (私のシステム) の決定と一致した場合、次の状態に進みます。同意しない場合は、「正しいシステムとデータを交換する」と同じことを繰り返して続行します。

ここでの私の疑問は、状態遷移制御にフラグを使用して実装したくないためです。関数ポインターを使用した実装は、MISRA 2004 以降、関数ポインターを使用しないとはどこにも言いませんか??

上記の 2oo3 実装へのアプローチは問題ありませんか、それとも他に注意すべき点がありますか?

2oo3アーキテクチャを実装するための他のアプローチはありますか(各システムによって行われた決定のための外部コンパレータはありません。つまり、各uCは決定自体を形成し、その決定を他のuCと相談する必要があります。 (例: 共有メモリ、fpga ベースのコンパレータなど) 他の 2 つのシステムによるアクセスと比較用)??

間違った方法でアプローチした場合は、ご容赦ください。私はこれに初心者です。

(注:3つのシステムにはマイクロコントローラのみがあります)

更新: ここに @Lundin によっていくつかの便利なポイントが追加されました -関数ポインターのないステート マシンの設計

4

1 に答える 1

2

ここでの私の疑問は、状態遷移制御にフラグを使用して実装したくないためです。関数ポインターを使用した実装は問題ありません。MISRA 2004 以降、関数ポインターを使用しないとは言いませんか??

そのアイデアはどこから得たのですか?関数ポインターの使用を禁止する MISRA-C 標準はありません。MISRA-C では、関数ポインタについてはほとんど言及されていません。MISRA-C で唯一許可されていないのは、関数ポインターと通常のポインターの間のワイルド キャストです。これは未定義の動作を引き起こすためです。

ステート マシンを実装する事実上の標準的な方法は、通常、関数ポインタの配列内のインデックスを指す列挙型などの状態変数を使用することです。これは典型的な例で、一見すると 100% MISRA に準拠しているように見えます。

上記の 2oo3 実装へのアプローチは問題ありませんか、それとも他に注意すべき点がありますか?

あなたの要件を知らずに、誰も言うことはできません。通常、そのような安全性が重要なシステム (過半数の投票者) を設計する場合、実際の「投票」を CPU の外側のハードウェアに配置する必要があります。これは、サブシステム/CPU の誤動作から保護することが目的であるためです。(「投票者」ハードウェア自体が順番に監視される場合があります。)したがって、アプローチにはいくつかの問題があります。

  • 主な問題: A が B をポーリングしたが、A 自体が混乱した場合、B が投じた投票について「嘘」をつくことになります。基本的に、破損したノード A は 2 票を獲得し、システム全体の安全性が失われます。冗長システムの全体的な目的は、プロセッサ/プログラムが混乱するのを防ぐことです。関与する CPU/サブシステムがどれも混乱することがないのなら、なぜ最初から多数決が必要なのですか? あなたが自分を守ろうとしている失敗は何ですか?

  • A が B に何らかの投票を求めて投票し、B が応答しない場合、またはナンセンスな応答をした場合はどうなりますか? このシナリオは、仕様に記載する必要があります。タイムアウト、エラー検出、エラー時の動作など

また、考慮してください。「多数決者」は、80 年代の流行語テクニックです。それは理にかなっているかもしれませんし、そうでないかもしれません: それは安全性を改善するかもしれませんし、まったくナンセンスかもしれません. 誤った安全性の設計に注意し、システムの詳細を知らずに多数決を使用するよう説教することを盲目的にする危険な「安全」基準に注意してください。

「SIL」61508/26262 規格は、「多数決」を推奨する根拠や最新の情報源がないため、ここで盲目的に信頼するのは特に危険です。たとえば、IEC 61508-7 A.1.4 を参照してください。これは完全にナンセンスです。ソースは、80 年代からドイツ語でのみ入手可能な技術論文です。笑うか泣くか?

それらの基準の内容よりも、常識を適用することがはるかに重要です。

安全性が重要なシステムで 3 つのうち 2 つを使用する必要があるのはなぜですか? これは、システムの 33% が故障しているということです。なぜ、そのようなシナリオでシステムが稼働し続けることを望むのでしょうか? 多くのシステムでは、システム障害の 33% はかなり壊滅的です... 同様に、66% の「診断範囲」は、多くのシステムで非常に貧弱であると見なされます。

安全システムの設計全体は、安全な状態と見なされるものと、重大な障害が発生した場合の対処方法に大きく依存します。安全な状態は「すべてを停止する」(典型的な産業用アプリケーション) か、それとも「可能な限り走り続ける/足を引きずる」(典型的な自動車/医療用アプリケーション) か?

繰り返しになりますが、これらはすべて、この種のシステムに適したものにするために非常に重要な仕様を指しています。

于 2016-01-12T09:23:15.427 に答える