デッド ロジックの一般的原因
モデルでデッド ロジックにつながる一般的なモデル化パターンには次のものがあります。
設計エラー検出解析を実行すると、Simulink® Design Verifier™ により、結果ウィンドウにデッド ロジックの一般的な原因がレポートされます。
解析時の Logical Operator ブロックのショートサーキット
Simulink Design Verifier は、デッド ロジックの解析時にショートサーキットが発生しているかのように論理ブロックを処理します。
たとえば、このモデルでは、In2
が false の場合、ショートサーキットが原因で 3 番目の入力が無視されます。結果ウィンドウにこの端子がデッド ロジックとしてリストされます。論理演算のショートサーキットを参照してください。
ブロックの条件付きの実行
モデルが Switch ブロックまたは Multiport Switch ブロックで構成されていて、[条件付き入力分岐実行] パラメーターが [オン]
に設定されている場合、条件付き実行によって予期しないデッド ロジックが発生することがよくあります。
[条件付き入力分岐実行] パラメーターが [オン]
に設定されている、このモデル例について考えます。AND Logical Operator ブロックは条件付きで実行され、それによってこのブロックにデッド ロジックが発生します。詳細については、Conditional input branch executionを参照してください。
定数として処理されるパラメーター値
モデルにパラメーターが含まれる場合、既定の設定で、Simulink Design Verifier はその値を定数として処理します。これにより、モデルにデッド ロジックが発生する可能性があります。この場合、これらのパラメーターが解析時に調整されるように設定することを検討してください。
たとえば、すべてのパラメーターがゼロに設定された次のモデルについて考えます。この設定により、Less Than ブロックにデッド ロジックが発生します。
上流のブロック
特定のブロックにデッド ロジックがあると、下流のブロックにデッド ロジックが発生し、カスケード効果につながる場合がよくあります。
上記のモデル例について考えます。Less Than ブロックのデッド ロジックにより、対応する下流のブロックでデッド ロジックが発生します。このため、多くの場合、下流のデッド ロジックを確認する前に上流のデッド ロジックを確認すると有効です。
ライブラリにリンクされたブロック
ライブラリ ブロックは、使用される場所によっては、冗長化された防御的条件を伴って書き込まれる可能性があります。場合によっては、このためにデッド ロジックが発生することがあります。設計エラー検出のためのオブジェクティブの除外と正当化を参照してください。
信号の範囲の制限
最小値および最大値を制約としてもつルートレベルの Inport ブロックと、テスト生成の Test Condition ブロックは、デッド ロジックの原因となることがあります。たとえば、2 番目の Inport ブロックの最小値と最大値の範囲がそれぞれ 1 と 100 である ConditionGreaterThan0 Switch ブロックについて考えます。これが原因となって、このサブシステム内の Switch ブロックにデッド ロジックが生じます。