筆者はここまでで、物理特性を示す目的でブロックの属性を定義する方法を解説してきた。一連のシステムの属性は独立していない場合が多い。AとBの2つのサブシステムが、それぞれaとbという属性を持っており、{A.a > B.b}が真でなくてはならない制約条件があるとする。SysMLの「ConstraintBlock」は、エンジニアがシステム属性のどのような関係(例:解析的なものなど)でも定義できるようにする。一般的には、これらの制約条件から要件検証などのシミュレーションで活用できる表現網が生まれる。ただし、後述するように、Constraintブロックがランタイムオブジェクトとしてインスタンス化できず、ブロックの特殊なプロパティの分類に使用されることに注意したい。
制約条件とは、サブシステムの中にある「ConstraintProperty」という名前のプロパティ(つまり、ブロック) で、ConstraintBlockで分類される。そして、Constraintブロックはそのパラメータを示す表現と属性を定義している。SysMLでは、どの特定の言語による表現の説明も、それらに対するソルバーの提供も義務付けていない。これらのエレメントは、特定のツールベンダが提供するのが一般的だ。
RSWは一連の解析制約条件を使い、システムが適切に調整されているかどうか検証する。図10に3つの制約条件を示す。
SysML Parametric Diagram(PD)は、「ConstraintProperties」としてのConstraintブロックの使い方を表すために使用される。PDは、文法上は実際にはIBDと同じだ。PDでは、使用方法を示すConstraintブロックの中で定義されたパラメータを通じ、Constraint Propertiesが相互接続されている。そして、保有ブロックに関連付けてほかのプロパティ(ブロックプロパティや分散プロパティなど)に接続する。これらのプロパティは、パラメータの入力にしかなれないため、Constraint Propertiesのパラメータと直接結び付けられる。
図11にPDの例を示す。Constraint Propertiesは、丸い角の四角で示されている。この図では、センサーとフロントガラスの両方のパーツが作動範囲を計算し、これが「compare」プロパティで比較される。これらの値はほかにも、コンフィギュレーションファイルを示すパーツに対して提供される(図11の最下部)。もしセンサーとフロントガラスに互換性がある場合は、IsCalibrated(ポートとして見える)のフラグが真になる。従って、補正要件の検証は、このポートの値のテストだけになる。そのため、システムはフロントガラスやセンサーの特性の変化に素早く対応できるようになる。
要件アロケーションはコンパートメントを使ってPDで示されている。図11には、比較に使う制約条件と、コンフィギュレーションファイルを示すパーツの両方に要件アロケーションのコンパートメントが示されている。この例では、これらのエレメントがSystem Calibration要件を満たしている。
「WindshieldIREffectiveRange」および「SensorEffectiveRange」の両Constraintブロックの使用方法は、付録のダイヤグラムに用意されている。これらは「RainSensor」や「CarWindshield」というパーツごとにネスティングされる。パート1の図5にあるテストケースを部分的にインプリメントする際に図11のダイヤグラムが使われることに注意したい。
Constraintブロックが魅力的なのは、これらが再利用可能なメカニズムを使って制約条件のタイプを定義する点だ。従って、1つのモデルの中で何度も同じ制約条件を使うことができる。制約条件は、どの変数が入力で、どれが出力なのかを明記しないことをぜひ覚えておきたい。値はコンテキストで割り当てられ、数値ソルバーがシステム変数の結果を提供する。SysMLの制約条件については、ぜひともPeak博士などの功績を調べておきたい[注2]。
パート2ではSysMLを使って製品構造を作成し、それに要件をアロケートする方法について解説した。最後となるパート3では、SysMLでシステムの動作特性をモデリングするための機能を概説する。
Copyright © ITmedia, Inc. All Rights Reserved.