はじめに
前回、Simulink APIに触れつつ「Simulinkってシミュレーション実行できる」という非常に重要な事をしれっと記載しました。今回はもう少し深堀りしてみます。
軽く前回の復習
Simulinkブロックには様々なプロパティ設定があります。
一例としてInportブロックの設定ダイアログを記載します。
ブロックによってはタブが幾つもあり、設定自体に四苦八苦するものもあります。
しかし、Simulinkブロックは前回説明したように、シミュレーション時にプロパティ値がResolveされるコンパイル型と、そうでない静的なプロパティに分類できます。そこで今回は設定ダイアログ上の設定値からどの様に反映されるのか？を見ていきたいと思います。
継承とは
ブロックプロパティ値には 「inherit ・・・」とか「-1」という値を設定できるものがあります。これは、Simulinkのような信号・ブロック線図の幾何的・循環的特徴を活かした設定と言えると思います。これらの設定はモデルのコンパイル時に各々の属性がResolveされます。
端的に言うと、次のようなステップを繰り返しながら、入力信号を処理しながら出力信号を生成するモデリングで利用します。(信号ドリブンモデルという方もいます)
非継承(明示的なプロパティ設定)
とはいえ、信号源は明示的にプロパティ値を設定しなければなりませんし、ブロックの演算種別によっては、ブロックの入出力で属性を変化させる必要となる場合もあります。
信号伝播を担保するには
実際のモデリングでは継承設定と非継承設定を組合せて、どの様に正しい信号伝播を担保するか?ということを踏まえる必要があります。これが守られないと正しいシミュレーション結果を得られない場合が出てきてしまうからです。
それって、具体的に何をすればいいの??
Aさん 「ブロックの設定なんて、一つに決めておけばよくね??」
Bさん 「設計者が要求を理解して、一つ一つ明示的に設定しないと駄目なのでは??」
Cさん 「Aさんや、Bさんみたいに意見が分かれるので、レビューで回収するしかないね。。」
Aさん、Bさん、Cさんも以下の様に読み替えると正解だと思いますし、この様な意見を集約し、形式的な文章としたものが「モデリングガイドライン」として世に出回っているものだと思います。
Aさん : プリセット
Bさん : ポストセット
Cさん : 設計後の自動チェック
何れもSimulink APIで自動的に処理が可能です。
モデリングガイドラインルール例
では、試しに「信号伝播を担保する」ルールを一つ紹介します。
このルールの骨子は、制御ロジックと数値演算は分割してモデル化しましょう。その際、データ型を混在させるような処理は避けることが望ましい。ということを形式的にチェックプログラム化しています。(ツールで機械的に検査できます)
まとめ
他の人が描いたモデルにおいて、ブロック設定が何故inheritや-1になっているのか?何故、明示的な設定値となっているのか?を読み解きその成否判断のスキルと、
逆に自分が描いたモデルにおいて、何故このブロックはinheritとしたのか? 何故明示的に設定しなければならなかったのか?を説明出来ることがモデリングスキルに大事な一つだと思います。
余談
MathWorksさんのWebサイトにMATLAB Anser というユーザー同士のコミュニティがあります。ここでは、ユーザー同士でMathWorks製品のQ&Aを行ったりすることができます。
Simulinkのエラー関連の質問を見ていると、継承設定になっているプロパティ値と明示的に設定したプロパティ値が整合しないためにエラーとなっているケースをよく見かけます。
例えば「次元が一致しません」「データ型の不整合が・・・」のような感じのものです。
既定値のinheritや-1が何をしているのか? 一方自分はそのブロックをどう動かしたいのか?を考えながらモデリングの実施を心がけていればその様なエラーには遭遇しなくなります。
あー文章力上げたい。。。