Integrity Modeler Static Simulation
This section explains Integrity Modeler Static Simulation with Phoenix ModelCenter 2.0.
General System Structure
The System (henceforth referred as S) that we shall refer to here is a SysML block and has a few mandatory and optional components.
The mandatory components are:
◦ Block properties: Block properties provide an input to an analysis or get assigned with a result of an analysis. Block properties can appear in the system at any level of nesting. In other words, the system S can contain a part s1 (block property) typed by Block A. Block A contains two parts (a1, a2) typed by block coordinates. The block coordinates contains two parts (x, y) typed by real. In this scenario, x and y can be used in the analysis (as inputs or outputs).
◦ Constraint properties: Constraint properties represent calculations performed by ModelCenter. Each involved Constraint Property must be typed by a Constraint Block stereotyped with <<MC Analysis>>, where the tag “MC Path” is set to the URI of the calculation to perform. The format of the URI is described in the Phoenix documentation for the Analysis Server, for example, aserv://localhost/MyAnalyses/ThisAnalysis. The Constraint Block need not belong directly/indirectly to the system. The same Constraint Block can be used to type multiple Constraint Properties of the system. The static simulation algorithm takes into consideration only Constraint Properties that are directly owned by the system.
The optional components are:
Requirements: Requirements can be part of the static simulation and can receive two values each, that indicate whether the requirement fulfils the simulation result or not, and the margin.
For a requirement to be part of the static simulation, the following must ensured:
◦ The Requirement shall be stereotyped with <<MC Requirement>>..
◦ The Requirement shall be connected with a <<satisfy>> dependency to one of the system Block Properties that receive a value during the static simulation. Note the Requirement can be connected to one Block Property only.
◦ On the Requirement, the tags related to stereotype <<MC Requirement>> shall be configured in a way that enables the algorithm to determine whether the Requirement is satisfied by the analysis or not:
▪ “MC ComparisonOp” shall be set to the desired comparison method. The method can involve a minimum value, a maximum value, or both. Only numerical values are supported.
▪ “MC ValueMin” and/or “MC ValueMax” shall be set to the minimum value/maximum value for which the Requirement is considered to be met. Minimum and Maximum values should be set whenever required by the selected “MC ComparisonOp” (both can be required).
At the end of a static simulation, relevant Requirements are evaluated. For each Requirement setup as above, its “MC IsSatisfied” tag is set to True if the comparison was met between the Min/Max values set into the requirement and the value of the connected Block Property at the end of the simulation. The Requirement’s “MC Margin” tag is set to the difference between the value of the connected Block Property and the Requirement’s Min/Max limits. This is explained as follows:
• When only Min limit is supplied, Margin = Actual Value — ValueMin
• When only Max limit is supplied, Margin = ValueMax — Actual Value
• When both Min and Max limits are supplied:
◦ if ValueMin is closest to Actual Value, Margin = Actual Value — ValueMin
◦ Otherwise, Margin = ValueMax — ActualValue
Therefore, when Margin is negative, the Requirement is not met.
Constraint Property
Each Constraint Property involved in the system must be properly connected on its Constraint Parameters.
Each Constraint Parameter must conform to the following rules:
• The Constraint Parameter is connected with one or more connectors directed either to a Block Property or to another Constraint Parameter, or
The Constraint Parameter is connected with a single connector directed to the Constraint Parameter itself, and such a connector is connected on the other side to either a Block Property or another Constraint Parameter, or
The Constraint Parameter is not connected, and has an (input) default value specified by applying the stereotype <<MC DefaultParameter>>, setting the direction of the parameter into tag “MC Direction”, and setting the optional default value into the regular default value property (you can disregard the <<MC Value>> tag as this may be removed in future releases).
• All connectors must be Directed.
• Constraint Parameter types must match the types of the objects connected to them.
• The result of the binding of Constraint Parameters and Block Properties cannot contain loops (that is, starting from an arbitrary object and recursively traversing the connectors).
• The Static Analysis algorithm identifies the direction of each Constraint Parameter by its incoming or outgoing connectors:
◦ (xx) — If there is no connector, and no <<MC DefaultParameter>> stereotype, this is an error.
◦ (yy) — If there is no connector and the Constraint Parameter is stereotyped with <<MC DefaultParameter>>, the Constraint Parameter is either an Input or Output depending on “MC Direction”.
◦ (ww) — If there is one incoming connector, the Constraint Parameter is an Input (the possible default value applied through <<MC DefaultParameter>> stereotype, which is is disregarded; although the “MC Direction” stereotype, when present, should be consistent as per good modeling practice, which is also disregarded by the algorithm)
◦ (ee) — If there are multiple incoming connectors, this is an error.
◦ (zz) — If there are one or more outgoing connectors, the Constraint Parameter is an Output.
Block Property
Each Block Property must conform to the following rules:
• The Block Property is not connected (it is simply disregarded)
• The Block Property is connected with one incoming connector and 0 or multiple outgoing connectors (it receives a value at a certain stage of the computation, then the value is distributed through the outgoing flows to other clients. If there are no outgoing flows, the Block Property is the place for the final result of a computation).
• The Block Property only has one or more outgoing connectors. In this case, the Block Property must have a Default Value set. The Block Property is one such entity where you set initial values for the computation (another such entity is Constraint Parameters in which the default value is applied through the <<MC DefaultParameter>> stereotype).
System and System Parts Analysis
Before you begin, ensure that Phoenix Analysis server is up and running.
You can analyze the system S with the following steps:
1. Right-click on the system and select Perform Static Analysis. Model Center MBSE opens and the Static Analysis algorithm checks for the correctness of the system model.
If the algorithm encounters any errors, the analysis is aborted and the errors are displayed.
2. Once ModelCenter MBSE is open, you can select the Execution Plan located at the top left, possibly change input values displayed in the top center, and then click Run to execute the computation.
3. After the computation finishes, Model Center MBSE displays the Execution Plan Result tab that contains a set of results for the computation. You can perform the following:
◦ View the results, but close Model Center MBSE without saving. The Modeler model remains unchanged.
◦ Change the parameters in the Execution Plan tab and click Run. Another Execution Plan Result is displayed with the new values.
◦ Save the Execution Result Plan into the Modeler model. This stores the values associated to each Block Property into the corresponding Default Value field of each Block Property in the model. To view the results in Modeler, press F5 and expand the system in the Part Browser until the relevant Block Properties are reached.
 |
You cannot save the Execution Plan. In our semantics, the Execution Plan is always given by the System in the model and cannot be changed externally
|
You can also analyze part (P) typed by a system (S).
Typically, the user defines another SysML Block, for example "SystemInstances", and within that Block, several parts typed by S are created. They are essentially multiple instances of the same system S. The purpose of this operation is to evaluate the computation for each of these parts using different inputs for each and collecting different computation results and storing them individually.
To analyze such a part, follow the same instructions given above for a system, with the following differences:
• You must right-click the Part instead of right-clicking the System.
• Saving the “Execution Plan Result” saves the values in the hierarchy of the part P, instead of the hierarchy of the system. To view the result in Modeler, you can press F5 and by expanding the part P in the Parts Browser until you reach the relevant Block Properties.