MBSE PAK for Rhapsody USER GUIDE (v.2.3)

Transcription

1 MBSE PAK for Rhapsody USER GUIDE (v.2.3) ModelCenter and Rhapsody SysML Integration Phoenix Integration, Inc Pratt Drive, Suite 2000 Blacksburg, VA (540) Phoenix Integration, Inc. All rights reserved. ModelCenter and MBSE Pak are registered trademarks of Phoenix Integration, Inc. Rhapsody is a registered trademark of IBM. SysML is a registered trademark of Object Management Group.

2 1 Introduction to MBSE Pak MBSE Pak is a suite of software tools that connect SysML tools and Phoenix Integration ModelCenter to provide an integrated modeling and analysis capability. MBSE Pak supports Model Based Systems Engineering (MBSE) by connecting descriptive system models to engineering analysis models. MBSE Pak consists of MBSE Analyzer that is available in SysML tool environment and MBSE Plug-In available in ModelCenter. Engineers can evaluate designs defined in a SysML model through MBSE PAK and check requirements compliance. Since the capabilities are available both in SysML tool environment and in ModelCenter, engineers can work from tool environment they are familiar with. MBSE Analyzer was designed to support perspectives of systems engineers who are interested in system level trade-offs and requirements compliance. MBSE Plug- In supports perspectives of engineering analysts who perform detailed engineering analyses in support of system development. Figure 1: MBSE Analyzer main window. 1.1 MBSE Analyzer MBSE Analyzer allows engineers to: Evaluate system configurations defined in a SysML model using engineering analysis models. Perform trade studies within SysML tool environment to understand the impacts of design changes on performance and cost. Perform requirements compliance analysis using results of engineering analyses. Import existing analysis models to set up SysML models for engineering analysis. 2

3 Connect SysML blocks to parts catalog to perform trade-off studies by selecting parts options 1.2 MBSE Plug-In Features MBSE Plug-In (e.g., Rhapsody Plug-In) in ModelCenter allows engineers to: Automatically construct analysis models in ModelCenter from SysML models. Predict how changes to the system will affect other parts of the system. Update SysML models using new analysis and trade study results. 1.3 Requirements of MBSE Pak for IBM Rational Rhapsody MBSE Pak v.2.3 supports IBM Rational Rhapsody and NoMagic MagicDraw SysML tools. Requirements of MBSE Pak for Rhapsody are: IBM Rational Rhapsody (32 or 64-bit versions) o o o ModelCenter or later Analysis Server or later 3

4 2 Setup for Tutorials This chapter summarizes required configurations for tutorials in section Installation and Files An administrator privilege is required to install following software tools. 1. Make sure that Rhapsody is installed. Once it is installed, run Rhapsody as an admin user for the first time to register it as a COM object. 2. Make sure ModelCenter 11.1 is installed. 3. Run Rhapsody MBSE Pak installer. It will install both MBSE Analyzer and MBSE Plug-In (e.g., Rhapsody Plug-In). 4. Locate the example file that was installed by the MBSE Pak installer. Depending on your Rhapsody installation, it will be one of the following. a. <USER_HOME>\IBM\Rational\Rhapsody\8.1.4\Share\Profiles\MBSEAnalyz er\mbseanalyzerexamples.zip b. <RHAPSODY_INSTALL>\8.1.4\Share\Profiles\MBSEAnalyzer\MBSEAnalyze rexamples.zip 5. Extract the zip file to a location for which you have write permission. In this exercise, we assume that the zip file was extracted to C:\. A folder will be created, "C:\MBSEAnalyzerExamples", and examples will be extracted into it. 2.2 Configure Analysis Server MBSE Pak can execute analysis models that are wrapped through Analysis Server, which is a companion product of ModelCenter. The wrappers are stored in "MBSEAnalyzerExamples\analyses" folder. Configure Analysis Server to include the location of the wrappers. 1. Start Analysis Server and click Configure... button to start the Web-based Analysis Server configuration page. 2. Add the analyses folder (e.g., C:\MBSEAnalyzerExamples\analyses) to Analyses Path in the configuration page (Figure 2). 3. Save the settings and restart Analysis Server. 4

5 Figure 2: Configure Analysis Server to publish example wrappers. 5

6 3 Tutorials This chapter contains examples that illustrate capabilities of MBSE Pak. In the first tutorial, we will use a pre-built SysML model to evaluate SysML parametric diagrams using ModelCenter. The capability will be demonstrated using Rhapsody Plug-In and MBSE Analyzer. In the second tutorial, we will create a SysML model from scratch and set up parametric diagrams and execute them using ModelCenter. 3.1 Tutorial 1: Brake Pad Design The first tutorial will use a SysML model for a car brake design. The goal of the problem is to find the size of the brake pad that will minimize the cost while satisfying critical performance requirements such as stopping distance. The figure below illustrates key design parameters of the problem. Figure 3: Brake pad design example Overview of the SysML Model Open the Rhapsody model stored in MBSEAnalyzerExamples/CarBrakeDemo folder (Figure 4). First, open the block definition diagram "Vehicle Structure" in "Structure" package. The block definition diagram (BDD) shows logical composition of the system. The top level block is "Vehicle", which is made up with "engine", "transmission", and "wheel". "Brake" block has three parts: "rotor", "caliper", and "pad". Each block has properties, some of which are design parameters and some of them are performance metrics and cost. We will use engineering analyses to compute performance and cost of the brake and use the results to check system requirements. 6

7 Figure 4: Block definition diagram (BDD) of the brake example. A SysML requirements diagram was created to define system requirements. Open "Requirements::BrakeRequirements" diagram (Figure 5). We will focus on three performance related requirements including stopping distance, brake heating, and brake pad life. Figure 5: Requirements diagram of the brake example. MBSE Pak provides capabilities to use engineering analyses to automatically verify requirements. Let us examine how requirements are related to system properties. Open Analysis::bdd_RequirementsCheck block definition diagram (Figure 6). The diagram shows three requirements (stopping distance, heat, and projected life of brake pad) that are related to properties of the system. For example, the pad life requirement 7

8 states that the brake pad life shall be greater than 36,000 miles. The system performance properties need to be computed from engineering analyses. Figure 6: Satisfy relationships are used to relate system properties to requirements. Open the requirement specification by double clicking the pad life requirement. The requirement specification contains a textual requirement. To automatically verify requirements, each requirement can be manually interpreted and lower/upper bounds can be defined as tags. For the pad life requirement, a lower bound of 36,000 was defined as a local tag (Figure 7). Alternatively, bounds can be defined using PropertyBasedRequirement stereotype contained in MBSEAnalyzer profile. 8

9 Figure 7: SysML tags are used to automatically verify textual requirements. In SysML, constraint blocks are used to define analytical relationships among system property values. Typically, mathematical equations are used to define such relationships. But this approach is limited to relatively simple analyses. See section for the approach of using simple scripts in constraint blocks. In addition to scripts, MBSE Pak provides an approach of having constraint blocks point to executable analysis models available in Analysis Server, a companion product of ModelCenter. Analysis Server can host any number of wrapped analyses, and ModelCenter can connect to Analysis Server and execute them. Being a Java-based program, Analysis Server can run on virtually any computer platform on network, and ModelCenter users can execute analyses remotely via Analysis Server. Figure 8 shows constraint blocks used in the brake model. There are four constraint blocks in the model, and ExternalAnalysis stereotype is applied to each of them. The location of a corresponding analysis is specified in the url tag of the stereotype. In the case of CostAnalysis constraint block, it is pointing to aserv://localhost/brake/cost analysis, which is a wrapper of an Excel spreadsheet. MBSE Pak uses this information to automatically create an executable model in ModelCenter. In fact, the four constraint blocks were created by importing analyses from Analysis Server. See section to learn more about how to import analyses from Analysis Server. MBSE Analyzer automatically configures necessary stereotypes and tags when creating a constraint block from an analysis. Each constraint parameter of a constraint block is assigned as an input or an output according to how the corresponding variable is defined in the analysis wrapper. For example, CostAnalysis constraint block has three parameters: padcost, surfacearea, and thickness. In the analysis, surfacearea and thickness are inputs and padcost is an output. Open the specification view of the thickness parameter. AnalysisVariable stereotype is applied to the parameter, and direction tag is used to define causality (e.g., input/output) of the parameter (Figure 9). 9

10 Figure 8: Constraint block was customized to point to executable analysis available in Analysis Server. Figure 9: SysML stereotype and tag are used to define causality (e.g., input/output) of parameters of analyses. Parametric diagrams are used to define analytical relationships in SysML models. In the brake model, a parametric diagram was created for the analysis of brake performance and cost. The diagram, par_vehicleanalysis, was created in Structure::Vehicle block (Figure 10). The diagram is using four constraint properties, instances of the constraint blocks mentioned above. In the diagram, binding connectors are used to connect SysML properties to/from parameters defined in constraint blocks. Properties on the left side of the diagram are inputs to the analysis, and properties on the right are outputs of the analysis. In essence, MBSE Pak uses parametric diagrams as blueprints of 10

11 engineering analysis models. The parametric diagram has all necessary information to create a ModelCenter model. MBSE Pak can use one or more parametric diagrams to automatically create a ModelCenter model (See section 5.4 for more details). Figure 10: Parametric diagram for the brake example. 11

12 3.1.2 Use Rhapsody Plug-In to Create ModelCenter Model In this section, we will demonstrate using Rhapsody Plug-In to automatically create a ModelCenter model from the parametric diagram discussed in the previous section. Start ModelCenter 11.1 and create a blank model. Either Process or Data model will be fine. In this exercise, we will use the Process type model. Launch the Rhapsody Plug-In from Tools>Trade Study Plug-Ins>Rhapsody menu. Alternatively, turn on Trade-Study Plug-Ins toolbar, and click on the Rhapsody icon. NOTE: Rhapsody Plug-In runs out of the process of ModelCenter. If you get an error in starting Rhapsody Plug-In, check Rhapsody Plug-In configuration file located in C:\Program Files (x86)\phoenix Integration\Component Plug- Ins\Rhapsody\RhapsodyPlugInConfig.xml and make it sure following settings are properly set. platform o native (default): 64 bit Rhapsody on 64 bit OS or 32 bit Rhapsody on 32 bit OS o x86: 32 bit Rhapsody o x64: 64 bit Rhapsody RHAPSODY_INSTALL: The location of Rhapsody installation javahome: The location of Java Runtime. This can be relative to RHAPSODY_INSTALL. Figure 11: Launch Rhapsody Plug-In. The plug-in will show a dialog. Using Load button, select the Rhapsody model (e.g., C:\MBSEAnalyzerExamples\CarBrakeDemo\CarBrakeDemo.rpy). The plug-in will start Rhapsody in the background and Rhapsody will load the model. NOTE: If you get an error, check ModelCenter log. Open ModelCenter preferences dialog using Tools>Preferences menu. In Logging tab, click on Open Logs Folder and check out the latest log file. If the error is about not being able to start Rhapsody, try to run Rhapsody as an admin user and close it so that Rhapsody be registered as a COM object. Then close ModelCenter and try Rhapsody Plug-In again. 12

13 Figure 12: Rhapsody Plug-In Dialog. In Figure 12, the top left tree in the Plug-In dialog shows the package structure in the SysML model. This tree is used to select a subject to analyze. Expand Structure package and select Vehicle block. The lower left tree will show parametric diagrams relevant for the selected block (Figure 13). In this case, there is only one parametric diagram available, which is defined for Vehicle block. Figure 13: Select a subject to analyze. 13

14 To create a model in ModelCenter, make sure that Analysis Server is running and click Create Components button. Note: If you get a Connection Failure error, make sure Analysis Server is running and Analysis Path is properly set up as discussed in Section 2.2. Figure 14: Connection failure dialog may come up if Analysis Server is not running. Rhapsody Plug-In automatically creates a model in ModelCenter as seen in Figure 15. In addition to creating the four Analysis Server components, the plug-in creates a variable group at the top level assembly. The top level variable group corresponds to parts/properties structure of the selected Vehicle block. This is useful since all key properties can be found in one place. The variables in the group can be used as inputs and outputs for trade studies in ModelCenter. Figure 15: Analysis model is automatically created by Rhapsody Plug-In. The Plug-In also presents a list of SysML properties in a tree table on the right (Figure 16). To see all properties in the tree on the right, use Expand All right click menu. The tree table shows units and original values as defined in the SysML model. Input properties are indicated with an icon with an incoming green arrow and output properties are shown with an icon with an outgoing blue arrow. For SysML properties that are related to requirements, their requirements compliance status will be shown in margin column. 14

15 Figure 16: Rhapsody Plug-In shows list of properties of the selected block. The Plug-In dialog can be used to perform what-if studies. Values of input properties can be changed in New column. For example, increase width of the brake pad from 2.0 to 2.5. As seen in Figure 17, the Plug-In dialog uses an up-arrow to indicate that the width value was increased. And icons of the output properties are overlaid with red X to indicate the values may not be valid any more. Requirements status will be changed to Unknown in the margin column. To see the impact of the change in width property, we need to run the ModelCenter model. Use Run button on the Plug-In dialog to run the ModelCenter model. The model will run quickly and new values will be displayed in the Plug-In dialog (Figure 18). Change of a property value is marked either with a blue up-arrow for increase or red down-arrow for decrease. Requirements compliance status will be updated using the new values. If the user wants, the new values can be used to update the SysML model using Save button. In this tutorial, we skip that part. 15

16 Figure 17: Change of an input value indicates that the model needs to be run. Figure 18: New values are compared with the original values in the SysML model. 16

17 3.1.3 MBSE Analyzer MBSE Analyzer is an add-on to Rhapsody that allows executing engineering analysis models through ModelCenter. This section demonstrates how to use MBSE Analyzer to perform engineering analysis and check requirements compliance Start MBSE Analyzer Start Rhapsody and open the CarBrakeDemo SysML model. Launch MBSE Analyzer using Tools>MBSE Analyzer menu. When MBSE Analyzer runs for the first time, it will ask for a license (The name of the license feature is RhapsodyMBSEAnalyzer ). For a floating license, use Add Server button to specify the location of a license server. For a node lock license, use Add File button to specify the license file. MBSE Analyzer has a number of functional areas organized as tabs. To go to a function area, select a tab or you can use big buttons with icons. Figure 19: MBSE Analyzer main Window Review Requirements To check requirements status, select Review Requirements. The upper left tree shows the package structure in the SysML model. Select Requirements package, and the lower left table shows requirements in the package (Figure 20). Click on a requirement to see its textual specification. 17

18 Figure 20: Review Requirements tab. Figure 21: Apply requirements to Vehicle block. To perform requirements compliance analysis, select a subject to review in the upper left tree. For example, select Structure::Vehicle block. The three performance requirements are evaluated for the block and their compliance status will be reported. Figure 21 shows that Vehicle block satisfies all three requirements. When a block is 18

19 selected, default values of properties of the block will be used to check requirements. Requirements can be applied to a block or an instance specification of a block. In the SysML model, there are a couple of instance specifications of the Vehicle block. For example, select Designs::VehicleB:: vehicleb instance specification in the upper left tree. When requirements are applied to an instance specification, its slot values will be used to check requirements. It turns out that vehicleb does not satisfy the stopping distance requirement (Figure 22). Figure 22: Requirements are applied to an instance specification of the Vehicle block Evaluate Designs Evaluate Designs area can be used to execute parametric diagrams through ModelCenter. Select Evaluate Designs tab. In the upper left tree, select a subject to analyze (Figure 23). For example, select Structure::Vehicle block. The lower left tree will show parametric diagrams that are relevant to the selected block. In this case, there is only one parametric diagram that is applicable. Click Update Variables button to get a list of SysML properties that are used in the selected parametric diagram. To see all properties in the tree table, use Expand All right click menu. This user interface is essentially the same as what we saw in Rhapsody Plug-In in Figure

20 Figure 23: MBSE Analyzer shows a list of SysML properties that are used in parametric diagram. Figure 24: New values are compared to original values in the SysML model. 20

21 The user can evaluate different designs using MBSE Analyzer. For example, change the pad width from 2.0 to 2.5. Requirements status will change to Unknown, which indicates that analysis is required to get new performance values. Now we are ready to run the analysis. The selection of parametric diagrams and input values is called an analysis case in MBSE Analyzer. Once an analysis case is set up, it can be saved using Analysis Case favorites at the top of the tool, so that it can be restored later. Run the analysis case by clicking Run button. MBSE Analyzer will automatically create a ModelCenter model behind the scenes and execute the model. The execution results will be displayed in MBSE Analyzer (Figure 24). New values are compared to the current values in the SysML model, and their changes are indicated by a blue up-arrow (value increased) or a red down-arrow (value decreased). Requirements status is automatically updated using new values. The new design does not satisfy stop distance requirement because the new value is greater than the upper bound of 180 ft. To see more details of the requirement, click the cell with a red X. The Requirements View shows textual requirement along with its bounds (Figure 25). Figure 25: Requirements Viewer shows details of requirement compliance status. When an analysis is performed, new values will be automatically stored in Data Explorer, which pops up from ModelCenter running in the background (Figure 26). Try to run a couple of more cases by increasing width property to 2.6 and 2.7. Each run will be stored in a new column in Data Explorer. Data Explorer provides various plots to visualize and compare analysis results. For example, add Standard Plots>2D Line from the toolbar (Figure 27). Note: This section performed analysis for the Vehicle block using default values of block properties. The same analysis can be performed for instance specifications of Vehicle block. Select an instance specification in the upper left tree (e.g., Designs::VehicleA::vehicleA. If an instance specification is selected, its slot values will be used for analysis. 21

22 Figure 26: Analysis results are automatically stored in Data Explorer. Figure 27: Plots can be used to visualize analysis results. 22

23 Save Values New values from an analysis can be saved in the SysML model. If a block was selected as an analysis subject, new values will be saved in default values of SysML blocks. Alternatively, new values can be saved by creating a new instance specification of the block. After running the analysis with width value of 2.7, click Save As button in the bottom of the dialog. Save Design dialog will come up. Figure 28: Save Design capability allows creating a new instance specification to save new values. First, let s create a new package in Designs package. Select Designs package in the left tree and click New Package button. We will call the package VehicleC (Figure 29). Figure 29: Create a new package. Then give a name for a new instance specification. We will call it vehiclec (Figure 30). 23

24 Figure 30: Create a new instance specification. Click Save button. The new instance specification will be automatically selected in MBSE Analyzer. Note that original values and new values are now the same for the instance specification. From here, new analyses can be performed for the instance specification just like the way analyses can be done for a block. Figure 31: New values were saved as a new design instance. 24

25 Let us examine the instance specification in the SysML model. In the upper left tree of MBSE Analyzer, use a right click menu Locate in SysML Tree on vehiclec instance specification. The instance will be highlighted in Rhapsody model tree. MBSE Analyzer automatically creates slots and instance specifications for parts (Figure 32). Note that a hierarchical package structure was automatically created to store instance specifications of parts. Figure 32: MBSE Analyzer automatically creates slots and instance specifications for parts Perform Trade Studies In section , a trade study was performing by manually changing input values. In this section, trade study tools in MBSE Analyzer will be used to perform trade studies. Open MBSE Analyzer again and click on Evaluate Designs tab. Select Structure::Vehicle block. The lower left tree will show parametric diagrams that are relevant to the selected block. In this case, there is only one parametric diagram that is applicable. Click Update Variables button to get a list of SysML properties that are used in the selected parametric diagram. To see all properties in the tree table, use Expand All right click menu. Click on the Parametric Study button to bring up the Parametric Study tool (Figure 33). (Note: if the Parametric Study tool did not come to the front, click on the red phoenix icon in Windows Task Bar to bring it to front.) Figure 33: Click on trade study tool button. Drag in pad.width as the Design Variable for the Parametric Study. Setup the Parametric Study as shown in Figure

26 Figure 34: Setup the Parametric Study as shown by dragging in properties from MBSE Analyzer. Also click on the + button to add a favorite. Click Run button on Parametric Study window. A Data Explorer window pops up with the run data table (Figure 35). Once data is collected, various plots in Data Explorer can be used to understand the effects of a design variable on response variables. Close the Data Explorer. 26

27 Figure 35: Data Explorer stores the runs from the parametric study. Now we will use Design of Experiments (DOE) Tool to perform multi-variable parameter studies. Click on the DOE tool button on the far right to bring up the Design of Experiments Tool (Figure 36). The DOE Tool can be used to determine the effects of input variables on output variables, and to better understand the overall design space. For example, DOE Tool can be used to identify variables that have the largest impact on responses of the system. DOE tool provides a few design of experiments types. In this example, Latin Hypercube design type will be used to evenly space out designs for analyses. Figure 36: Click on cuboid icon to bring up DOE tool. Setup the DOE tool as shown in Figure 37, then click the Run button on the DOE Tool. 27

28 Figure 37: DOE Tool setup. 28

29 We now have 100 evaluations of the underlying analyses and can now study the interactions between different input and output properties. For instance DV Glyph and DV Parallel Coordinates plots from Data Visualizer can be used to understand the design space and compare designs (Figure 38 and Figure 39) Figure 38: DV Glyph plot with custom Mapping Options set. Figure 39: DV Parallel Coordinates plot shaded based on cost. 29

30 3.1.4 Requirements Change and Design Optimization In previous sections, it was discussed how MBSE Pak can be used to check requirements compliance status using results of engineering analyses. In this section, we will demonstrate how MBSE Pak and ModelCenter can be used together to quickly assess impacts of changes in requirements, and perform design optimization to find a new design that will meet new requirements Requirements Change Impact Analysis In Rhapsody, open a requirements diagram (Requirements::BrakeRequirements). Open specification view of Brake Pad Life requirement. Assume that the requirement was changed from the minimum of 36,000 miles to 72,000 miles. Change its textual requirement and update the lowerbound tag accordingly as shown in Figure 40. Figure 40: Change textual requirement and tag. Now we need to check whether the current design satisfies requirements or not. Open MBSE Analyzer and go to Review Requirements tab. Select Structure::Vehicle block to apply requirements. Figure 41 shows the current design does not meet the pad life requirement anymore. 30

31 Figure 41: Vehicle block does not satisfy the requirement anymore. We could use MBSE Analyzer s Evaluate Design capability and try to find a new design by manually tweaking input parameters. However, a better approach would be using design exploration techniques such as parametric study, design of experiments (DOE), or optimization. In this exercise, we will use ModelCenter s Optimization Tool to find a new design that will meet the new requirement. Save the Rhapsody model and close Rhapsody. We will open the model from Rhapsody Plug-In in ModelCenter Perform Design Optimization Start ModelCenter and create a new model. Since we want to be able to update the SysML model, we will use Rhapsody Plug-In in Component Plug-In mode, rather than in Trade Study Plug-In mode demonstrated in Note: The Trade Study Plug-In mode can be used when the Rhapsody model is the top most entity in ModelCenter. The Component Plug-In embeds Rhapsody Plug-In as a component in the ModelCenter model. The mapping between system properties and ModelCenter variables, which is stored in ModelCenter model, can be restored later. Another use of Component Plug-In mode is when Rhapsody Plug-In is a part of a larger model in ModelCenter. In the example here, the Rhapsody model will be driven by optimization and we need to embed Rhapsody as a component in ModelCenter. Launch Rhapsody Plug-In from Server Browser at the bottom of ModelCenter Window. 31

32 Figure 42: Launch Rhapsody Plug-In. Note: In Server Browser of ModelCenter, there are two flavors of Rhapsody Plug-Ins available. Rhapsody Plug-In uses SysML parametric diagrams to automatically create an executable analysis model. Rhapsody Data Source Plug-In does not use parametric diagrams and simply pulls properties values of a block. When using the Data Source Plug-In, the user will need to manually create analysis models and connect SysML properties to analysis components. See section 5.12 for more details of Rhapsody Data Source Plug-In. In Rhapsody Plug-In Window, select the SysML model. Select Structure::Vehicle block as an analysis subject and click Create Components button. We can see the Vehicle block does not meet the new requirement (Figure 43). The Plug-In automatically created a model in ModelCenter. We can see a Rhapsody component is embedded in the model (Figure 44). Figure 43: Rhapsody Plug-In shows requirements status. 32

33 Figure 44: Model created by Rhapsody Plug-In (Component Plug-In mode). Since we associated lower/upper bounds for requirements, we can use them as constraints in design optimization. Start Optimization Tool of ModelCenter (Tools>Optimization Tool). From ModelCenter s variable tree, drag and drop variables into Optimization Tool to define an objective, constraints, and design variables as shown in Figure 45. The objective is to minimize the cost of the brake pad. For constraints, we use the three properties that are related to performance requirements. Set up lower/upper bounds according to the requirements defined in the SysML model. The design variables are geometric parameters of the brake pad. In the Algorithm drop down list, select OPTLIB Gradient Optimizer. When the setup is ready, start optimization by using Run button on Optimization Tool. It will take a couple of minutes for optimization to complete. The optimization results show that we found a new design that meets all three constraints (Figure 46). 33

34 Figure 45: Design optimization can use requirements as constraints. Figure 46: Optimization results. 34

35 Open the Rhapsody Plug-In Window (if it is closed, double click on the Rhapsody assembly in the main canvas of ModelCenter). Figure 47 shows that the new design has the pad life of 72,000.9 miles, which satisfies the requirement. All three requirements are satisfied. On the other hand, we can see the cost of the brake pad has increased from $3.3 to $ This is because more stringent requirement was applied for brake pad life. This shows impact of requirements change, and trade-off between performance and cost. Figure 47: The new design has higher cost due to more stringent requirements. Since we have a new design that meets all requirements, we can use the new values to update the SysML model. Click Save button. Now the Plug-In Window shows that the values in the SysML model are the same as the new values (Figure 48). Close Rhapsody Plug-In. Close ModelCenter. We do not need to save the ModelCenter model. 35

36 Figure 48: New values are saved into the SysML model Check the New Design in SysML Model Now let s check out the SysML model that was saved from Rhapsody Plug-In. Start Rhapsody and open the SysML model. Open the specification view of Structure::Pad block. We can see default values (e.g., initial values) have been updated. For example, the value of life property is now 72,000.9 (Figure 49). Open MBSE Analyzer and select Vehicle block to review requirements one more time. Figure 50 confirms that the new design satisfies all requirements. This exercise shows how we can flow down requirements changes from a SysML model to analysis model in ModelCenter, perform design optimization to find a new design, and finally update the SysML model. 36

37 Figure 49: Default values of SysML blocks have been updated. Figure 50: The new design satisfies all requirements. This concludes the first tutorial. 37

38 3.2 Tutorial 2: Bicycle Weights Roll Up In this section, we will create a SysML model from scratch and set up parametric diagrams so that they can be executed through ModelCenter. The example is a simple bicycle, for which we want to compute the total weight by rolling up the weights of its parts. A completed SysML model can be found at MBSEAnalyzerExamples\BicycleScript Create a New SysML Project Start a new SysML project in Rhapsody. Select SysML as Project Type. We will create the project under C:\MBSEAnalyzerExamples and call the project MyBicycle. Set up the project as shown in Figure 51, and click OK. Select Yes to create a new folder MyBicycle. Figure 51: Create a new SysML project in Rhapsody Add MBSEAnalyzer Profile MBSE Pak requires MBSEAnalyzer SysML profile. The Tools>MBSE Analyzer menu in Rhapsody will be available only when MBSEAnalyzer profile is loaded. The profile was installed by the MBSE Pak installer and it can be found under Profiles folder of Rhapsody. Add the profile to the model by using File>Add Profile to Model menu of Rhapsody. Click Open to add the profile. Figure 52: Add MBSEAnalyzer profile. 38

39 Rhapsody may pop up a dialog that asks for the location of SysML profile. Click Ignore since SysML profile is already loaded in the model in this case. Figure 53: You can ignore this error since SysML profile is already loaded. The MBSEAnalyzer profile contains a handful of stereotypes that can be applied to SysML constraint blocks, constraint parameters and requirements. See section 5.1 for more details. Figure 54: Stereotypes in MBSEAnalyzer profile Create Blocks Create packages as shown in Figure 55. Use right click menus Add New Package or Add New>General Elements>Package in Rhapsody model tree. 39

40 Figure 55: Create a package structure. Add a block definition diagram in Structure package. Use a right click menu: Add New>Diagrams>Block Definition Diagram. Give a name bdd_bicycle. Create blocks as shown in Figure 56 by following these steps: Create blocks. Add weight property (or attribute) to each block. In the specification view of the property, select its type as SysML::SIDefinitions::BaseSIUnits::Kilogram. See Figure 57. Define a default value to each weight property as shown in Figure 57. Use directed composition relationships to define block/part relationships. For each part, give a name. By default, Rhapsody will give a name based on the name of the block such as itswheel. Double click on each composition relationship and define a name as shown in the BDD. To display part names on BDD, use right click menu Display Options and turn on the name of End1. As an optional step, you may want to hide unnecessary compartment (such as operations in blocks) in BDD. Use right click menu Display Options to configure which compartments to show. 40

41 Figure 56: Block definition diagram for the Bicycle model. Figure 57: Select a type and define an initial value for weight property. 41

42 3.2.4 Define Requirements Let us define a requirement for the total weight of the bike. Create a Requirements Diagram in Requirements package. And give a name BikeRequirements. Add a requirement BikeWeight to the diagram, and define textual requirement. Figure 58: Requirements diagram. Since the requirement specifies the upper limit of the weight, apply PropertyBasedRequirement stereotype of MBSEAnalyzer profile, and specify upperbound tag (Figure 59). Figure 59: Apply PropertyBasedRequirement stereotype and define upperbound tag. The requirements diagram will look like Figure 58. To show tags on the requirement block, use Display Options right click menu and add tags in Compartments view. Now we can relate the weight of Bike to the requirement. Create a block definition diagram (BDD) in Requirements package. Give a name bdd_requirementscheck. From the Rhapsody model tree, drag and drop Bike block into the BDD (Figure 60). Initially the block will be shown in Specification View mode. Select the block and switch it to Structured View mode using a toggle 42

43 icon in the toolbar (Figure 61). Now, we can show the internal structure of Bike block. From the Rhapsody model tree, drag and drop weight property into Bike block on BDD (Figure 62). Drag and drop BikeWeight requirement into the BDD. And define a satisfaction (or satisfy) relationship from the weight property to the requirement (Figure 63). Figure 60: Drag and drop "Bike" block. Figure 61: Switch to "Structured" view. 43

44 Figure 62: Drag and drop weight into Bike block. Figure 63: Define a "satisfy" relationship. Now, the requirements definition is complete. Note: MBSE Pak handles satisfy relationships on block definition diagram, requirements diagram, or parametric diagram Create Constraint Blocks Although it is possible to manually configure constraint blocks for execution through ModelCenter, it is much easier to use MBSE Analyzer to create constraint blocks. In this exercise, we will learn two ways to create constraint blocks using MBSE Analyzer. First, a constraint block is created by importing an analysis from Analysis Server. Second, a constraint block is created by defining scripts. MBSE Analyzer automatically sets up required stereotypes and tags for constraint blocks Import from Analysis Server Start MBSE Analyzer in Rhapsody. Go to Manage Constraint Blocks tab (Figure 64). 44

45 Figure 64: MBSE Analyzer provides a capability to browse available constraint blocks and create new constraint blocks. Click Create>Using Analysis Server button to launch Import Constraint Block dialog. Make sure Analysis Server is running, and specify the location of Analysis Server. Click Connect button. This tool will connect to Analysis Server and get a list of available analyses. This is very much like Server Browser facility in ModelCenter. Note: Analysis Server can wrap a ModelCenter model as a black box analysis, which can be imported as a constraint block. See section 5.14 for more information. Note: If units are defined in variables in analysis wrapper, MBSE Analyzer will try to find corresponding value types in the current SysML model and set the type of constraint parameters accordingly. If corresponding units are not found in SysML model, constraint parameters will be set to primitive types such as real, integer, etc. To set types of parameters automatically, create value types in SysML model before importing an analysis. Select SumThree component in math folder. A list of the variables in the component will be displayed in the tree on the right. Click Next button (Figure 65). 45

46 Figure 65: Connect to Analysis Server and select an analysis to import. In the next step, the user can select variables (from Analyses) that he or she wants to expose as constraint parameters in Rhapsody (Figure 66). The constraint parameters are named after variable names in the analysis component. If desired, the names of the parameters can be edited in the SysML Name column of the table. We will import all four variables in the analysis. Click Next. Figure 66: Select variables to import as constraint parameters. In the next step, select a package to which the new constraint block will be added. In this example, select Analysis::Math package. Use the default name SumThree for the constraint block (Figure 67). Click Import to finish the Wizard. When asked about whether to import another analysis, click No. 46

47 Figure 67: Select a package to create a constraint block Using Scripts We will create another constraint block using scripts. In Manage Constraint Blocks tab, click Create>Using Script button. A dialog will come up to define a constraint block (Figure 68). Add two input variables x1 and x2 and one output variable sum. In the script section, add a simple script to compute the sum of two input variables. JavaScript or VBScript can be used for script language. We will use JavaScript in this exercise. Figure 68: Create a constraint block using scripts. Click Next and save the constraint block in Analysis::Math package as SumTwoScript. When asked about adding another analysis, click No. Now MBSE Analyzer shows the new constraint blocks (Figure 69). 47

48 Figure 69: Browse available constraint blocks. Let us examine the new constraint blocks in the Rhapsody model. SumThree constraint block has ExternalAnalysis stereotype applied, and its url tag is set to the location of the corresponding Analysis Server component. Each of the constraint parameters of the constraint block has AnalysisVariable stereotype applied along with its tag values. Similarly, SumTwoScript constraint block has Script stereotype applied. Note that the scripts are defined in body tag of the stereotype. Now we can use the constraint blocks in parametric diagrams. Figure 70: MBSE Analyzer stereotypes are automatically applied to the constraint block and constraint parameters. 48

49 3.2.6 Create Parametric Diagrams We will create parametric diagrams to compute the total weight of Bike. First, a parametric diagram is defined to compute the total weight by adding weights of the front wheel, the rear wheel and the frame. Second, another parametric diagram is defined to compute the weight of each wheel by adding up weights of the rim and the tire. In general, the front wheel and the rear wheel can have different weights and this parametric diagram needs to be solved twice, first for the front wheel and second for the rear wheel. MBSE Analyzer has a capability to compose a hierarchical analysis model by combining parametric diagrams. Create a parametric diagram in Bike block using a right click menu. Name it as par_bikeweight. First, create a constraint property (not a constraint block!) on the diagram. Initially, the constraint property has no type (Figure 71). Figure 71: Create a generic constraint property. Open the features (specification) dialog of the constraint property (Figure 72). And specify its type as Analysis::SumThree constraint block. And name it as sumthree. Click OK. When warned about loss of current constraint property features, click OK. The diagram will look like Figure 73. The constraint property is an instance of SumThree constraint block. Figure 72: Specify name and type of the constraint property. 49

50 Figure 73: The constraint property is an instance of SumThree constraint block. Now drag and drop parts and properties of the Bike block into the diagram. See Figure 74 for the pattern of the drag and drop operations. First, drag the parts for the frame, front wheel, and rear wheel onto the diagram. Then, drag and drop the weight attributes for the frame and wheel blocks onto the parts to associate the attributes with the parts. Make sure the bounding box for the part is large enough to accommodate dropping the attribute onto it. Otherwise, Rhapsody will not associate the attribute with the part. Figure 74: Drag and drop parts and properties into parametric diagram. Rearrange constraint parameters so that the inputs (x1, x2, and x3) are on the left edge and the output (sum) is on the right edge. Create binding connectors between properties and constraint parameters. The completed parametric diagram for Bike block should look like Figure

51 Figure 75: Parametric diagram created for "Bike" block. Now we need to create a parametric diagram for Wheel block. Right click on Wheel block and create a new parametric diagram called par_wheelweight. Follow the same pattern of the first parametric diagram, and set up the parametric diagram using SumTwoScript constraint block. The diagram should look like Figure 76. Figure 76: Parametric diagram created for Wheel block Evaluate Designs We are ready to evaluate the parametric diagrams. Start MBSE Analyzer and select Evaluate Designs tab. Select Bike block as an analysis subject. The lower left tree shows applicable parametric diagrams according to the part structure of the selected block (Figure 77). Bike block itself has par_bikeweight parametric diagram. par_wheelweight parametric diagram is applicable both to the front wheel and the rear wheel. Therefore, there are three parametric diagrams that need to be evaluated to compute the total weight of Bike. 51

52 Figure 77: For "Bike" block, there are three parametric diagrams that can be evaluated. Click Update Variables button. The properties table shows that weights of the rims and the tires, and weight of the frame are inputs. When the analysis case is evaluated, par_wheelweight will be evaluated for the front and rear wheels to compute their weights. Then, par_bikeweight will be evaluated to compute the weight of Bike. Figure 78 shows the requirement for the total weight is currently satisfied. 52

53 Figure 78: The weight of "Bike" will be computed by rolling up the weights of the wheels and the frame. Let us increase values of input weights and run the analysis case (Figure 79). Verify that output weight values are correct. Now the weight of Bike is 12.5, which exceeds the upper limit specified in the requirement. It is useful to take a look at the ModelCenter model that was created under the hood. Use Export button to save the underlying ModelCenter model. Open the exported model using ModelCenter. After assemblies are rearranged, the model will look like Figure 80. MBSE Analyzer translates each parametric diagram to an assembly in ModelCenter. The model shows how weights roll-up works; weights of wheels are computed first and their values are used as inputs for the computation of the Bike weight. If you are using ModelCenter 11 or later, link warnings may show up because no units were defined for the simple analyses of computing sums. In this example, the warnings can be safely ignored. Click on one of the warning icons to launch Component Warnings dialog. Select all units warnings and ignore them. 53

54 Figure 79: Compute the total weight of Bike using weights roll-up. Figure 80: Underlying ModelCenter model. Note that Save button is disabled in Figure 79. That is because we are using default values when a block (e.g., Bike ) is selected as an analysis subject. Bike block has two wheels but there is only one default value that can be specified for the weight of Wheel in the SysML model. Note MBSE Analyzer automatically created virtual instances of parts in memory, to be able to specify weight values independently for the two wheels. However, it is not possible to save the values to default values in the SysML 54

55 model. In this case, a new instance specification needs to be created. Click Save As button. First, create a package Designs::BikeA, and save new values as a new design (e.g., instance specification) called bikea. Figure 81 shows the new instance specification created. Figure 81: New values are saved as a new design. This concludes the second tutorial. 55

56 4 Overview of Tool Capabilities In this section, tool capabilities available in MBSE Analyze and Rhapsody Plug-In are explained. 4.1 MBSE Analyzer MBSE Analyzer can be launched from Tools>MBSE Analyzer menu. There are five main task areas organized as tabs. The functional areas include: Review Requirements: Check requirements compliance status Manage Constraint Blocks: Browse constraint blocks and import external analyses Manage Parts Catalog: Connect blocks to parts catalog Manage Parametric Diagrams: Browse parametric diagrams Evaluate Design: Evaluate designs and perform trade studies by executing analyses Review Requirements In this tab, the user can browse available system requirements and check requirements compliance status. Figure 82 illustrates functions of the tool. Figure 82: Review requirements task area. 56

57 Select a subject to review: The upper left tree shows SysML package structure and model elements that can be selected as a subject to review. A SysML block or an instance specification can be selected. When a block is selected, default values of its properties will be used to check requirements, whereas slot values will be used when an instance specification is selected. If a package is selected, requirements in the package will be listed in the lower left table, with no compliance analysis. Compliance status: When a subject is selected in the upper left tree, requirements that have satisfy relationships with the subject will be listed. The table has four columns. o Name: Name of the requirement o Property: The name of the property that is related to the requirement through satisfy relationship o Bounds: Lower/upper bound defined in the requirement o Actual: Current value of the property and its compliance status Textual requirement: This shows textual specification of a requirement selected in the lower left table. Test Case: This area shows test case matrix defined for more sophisticated requirements. See section 0 for more details. Bookmark: A current setup of a subject and requirements selections can be saved as a bookmark. More than one bookmark can be created that can be restored at a later time. Bookmarks are saved per Rhapsody model. In Windows 7, bookmarks are saved in <USER_HOME>\AppData\Roaming\Phoenix Integration\MBSE Analyzer Refresh: This button can be used to reload the SysML model into MBSE Analyzer if the SysML model has been changed since MBSE Analyzer started. 57

58 4.1.2 Manage Constraint Blocks In this tab, the user can browse available constraint blocks and create new constraint blocks. Figure 83 illustrates functions of the tool. Figure 83: Manage Constraint Blocks task area. Select a package: The tree on the left shows SysML packages that contain constraint blocks. This can be used as a filter to select constraint blocks the user wants to review. List of constraint blocks: The table on the right shows constraint blocks in the selected package and its sub-packages. The table has three columns. o Constraint Block: name of constraint block o Analysis description: type of the corresponding analysis o Details: Click to see more details of constraint block Refresh: This button can be used to reload the SysML model into MBSE Analyzer if the SysML model has been changed since MBSE Analyzer started. Create: This allows creating a new constraint block either by importing an analysis from Analysis Server or by using scripts. See section for more information. Connect to: This allows connecting a constraint block to an Analysis Server component or scripts. If the constraint block is already connected to Analysis Server or scripts, new connection will overwrite the existing connection. 58

59 Update: Use this to update an existing constraint block. For a constraint block with Analysis Server component, a mapping dialog will be used to add/remove constraint parameters. For a constraint block with script, a script editor dialog will be used. Create Block: This allows creating a SysML block from a constraint block. This is useful when SysML blocks need to be created from constraint blocks that were created from Analysis Server. If parameters and their units are defined in analyses, the information can be translated to SysML blocks Analysis Details Details of constraint block can be examined in Analysis Details dialog that is launched by clicking on Details column in the table. Figure 84: Details view of a constraint block. In the dialog, description of the constraint block can be added. For constraint parameters, bounds and description can be edited. Click Update to save changes to constraint block Analysis Template A constraint block can be exported as a ModelCenter model that can be used as a template that engineering analysts can use to create an analysis model. In Analysis Details dialog of a constraint block, add description of the analysis. Click Export button and save it as a ModelCenter file. The model contains variables in an assembly named after the constraint block. The top level assembly Model contains the description of the constraint block as shown in Figure 85. When a template model is created, MBSE Analyzer generates a HTML README file. Figure 86 shows an example. Engineering analysts can use the README file as a specification for the engineering analysis he or she needs to create. The template model can be implemented by adding analysis components and creating links from/to assembly variables. When analysis model is completed, it can be imported to SysML model to update the constraint block. First, place the ModelCenter model in a folder published by Analysis Server. Then, use 59

60 Connect to capability in Manage Constraint Blocks tab to connect the original constraint block to the ModelCenter model. Figure 85: Exported constraint block can be used as a template for engineering analysis. Figure 86: A HTML readme file created for template model. 60

61 4.1.3 Manage Parts Catalog In this tab, the user can browse blocks that are connected parts catalog. When a block is connected to a parts catalog, parts numbers can be used as design parameters instead of individual properties of the block. See section 5.8 to learn more about parts catalog. Figure 87 illustrates functions of the tool. Figure 87: Manage Parts Catalog task area. Select a package: The tree on the left shows SysML packages that contain blocks. This can be used as a filter to select blocks the user wants to review. List of blocks: The table on the right shows blocks in the selected package and its sub-packages. The table has three columns. o Block: name of block o Parts Catalog Source: type of the parts catalog o Details: Click to see more details of the block Refresh: This button can be used to reload the SysML model into MBSE Analyzer if the SysML model has been changed since MBSE Analyzer started. Connect to: This allows connecting a block to a parts catalog database or to an Analysis Server component that is configured as a look-up table. If the block is already connected, new connection will overwrite the existing connection. Update: Use this to update an existing block. For a block connected to a parts catalog database, a mapping dialog will be used to relate block properties to 61

62 catalog parameters. For a block connected to an analysis, a similar mapping dialog will be used to relate block properties to variables in the analysis. Create: This allows creating a new block either by using a parts catalog database or using an Analysis Server component that is configured as a look-up table. 62

63 4.1.4 Manage Parametric Diagrams In this tab, the user can browse available parametric diagrams. Figure 88 illustrates functions of the tool. Figure 88: Browse parametric diagrams. Select a package: The tree on the left shows SysML packages that contain parametric diagrams. This can be used as a filter to select parametric diagrams the user wants to review. List of parametric diagrams: The table on the right shows parametric diagrams in the selected package and its sub-packages. The table has two columns. o Diagram: name of parametric diagram o Details: Click to see more details of a parametric diagram Refresh: This button can be used to reload the SysML model into MBSE Analyzer if the SysML model has been changed since MBSE Analyzer started. 63

64 4.1.5 Evaluate Designs In this tab, the user can execute parametric diagrams through ModelCenter. Figure 89 illustrates functions of the tool. Figure 89: Evaluate designs by executing analysis models. Select a subject to analyze: The upper left tree shows the SysML package structure and model elements that can be selected as a subject to analyze. A SysML block or an instance specification can be selected. When a block is selected, default values of its properties will be used to perform analysis, whereas slot values will be used when an instance specification is selected. Select parametric diagrams: The lower left tree shows parts structure of the selected subject along with applicable parametric diagrams. The tree can be used to select a subset of parametric diagrams to evaluate. When more than one parametric diagram is selected, MBSE Analyzer will create a ModelCenter model, where each parametric diagram is translated to an assembly in ModelCenter. ModelCenter will run the assemblies in sequence and automate data transfer among the assemblies. o Selection Filter: The tree view in this tab shows packages that contain parametric diagrams. If parametric diagrams are organized in packages, this tree view can be used to quickly select a set of parametric diagrams stored in a package. Selections in this tree view synchronize with those in the main Parametric Diagrams selection tree at the front. 64

65 Properties list: The tree like table on the right shows SysML properties in the selected subject. The table has five columns. o Property: Name of a property in the block or instance specification o Units: Units defined for the property in SysML (if any). o Original: Original values as defined in the SysML model. Default values are used for a block, whereas slot values are used for an instance specification. o New: New values in the selected analysis case. The user can change input values. When an analysis is completed, new output values will be shown here. o Margin: If the property is related to a requirement through satisfy relationship, its compliance status will be shown here in terms of margin of satisfaction. Analysis Case: Current selections of a subject and parametric diagrams can be saved as an analysis case that can be restored at a later time. Each analysis case is saved in Rhapsody model as a custom element. Trade Studies: Parametric study and DOE tool can be launched from MBSE Analyzer. Current set up of a trade study can be saved as a trade study and restored later. Trade study setup is saved in Rhapsody model as a custom element. Refresh: This button can be used to reload the SysML model into MBSE Analyzer if the SysML model has been changed since MBSE Analyzer started. Restore Defaults: This will reset New values to Original values in the SysML model. Save: This will save new values back into the SysML model. When a block is selected as an analysis subject, values will be saved to default values. When an instance specification is selected, values will be saved to slot values. Note that this button may be disabled when o New values are the same as Original values o A block is selected as an analysis subject and there is more than one value for a single property in the analysis case. This may happen 1) when there are more than one parts of the same type, or 2) when there is a multiplicity property. In this case, use Save As to save new values as a new instance specification. Save As: Save new values as a new instance specification. Run: This will start ModelCenter behind the scenes, create a model, execute it, and get results back to MBSE Analyzer. Export: The underlying ModelCenter model can be saved. The saved model can be opened using ModelCenter. Stop: This button will be enabled when an analysis is running. Use this button to halt the execution. 65

66 Menu Items: There are several menu items that can be used in conjunction with Evaluate Designs. o View>Show Distribution Column: This option will show probabilistic distribution information for properties of analysis subject. Probabilistic distributions can be defined in properties of blocks by specifying Normal or Uniform stereotype in MBSE Analyzer profile. o View>Show Margins as Percentages: This will change the way margins are displayed for requirements compliance analysis. Toggle between absolute values and percentage values with respect to bound values. o View>Show Unused Variables: By default, MBSE Analyzer will show properties that are used in selected parametric diagrams. If this option is on, MBSE Analyzer will show all properties in the selected analysis subject. Figure 90: View options. 66

67 4.2 Rhapsody Plug-In Rhapsody Plug-In in ModelCenter can be launched in Trade Study Plug-In mode or Component Plug-In mode. Trade Study Plug-In mode can be used when the Rhapsody model is the top most entity in the ModelCenter model. Component Plug-In mode embeds Rhapsody Plug-In as a component in the ModelCenter model. The mapping between SysML properties and ModelCenter variables can be restored later since it is contained in the ModelCenter model. Another use of Component Plug-In mode is when Rhapsody Plug-In needs to be a part of a larger model in ModelCenter. Rhapsody Plug-In s user interface is very similar to Evaluate Design tab in MBSE Analyzer discussed in section Figure 91 shows an example of the Plug-In interface. Load : Select a Rhapsody SysML model Select a subject to analyze: The upper left tree shows SysML package structure and model elements that can be selected as a subject to analyze. A SysML block or an instance specification can be selected. When a block is selected, default values of its properties will be used to perform analysis, whereas slot values will be used when an instance specification is selected. Select parametric diagrams: The lower left tree shows the part structure of the selected subject along with applicable parametric diagrams. The tree can be used to select a subset of parametric diagrams to evaluate. When more than one parametric diagram is selected, Rhapsody Plug-In will translate each parametric diagram to an assembly in ModelCenter. ModelCenter will run the assemblies in sequence and automate data transfer among the assemblies. o Selection Filter: The tree view in this tab shows packages that contain parametric diagrams. If parametric diagrams are organized in packages, this tree view can be used to quickly select a set of parametric diagrams stored in a package. Selections in this tree view synchronize with those in the main Parametric Diagrams selection tree at the front. Properties list: The tree table on the right shows SysML properties in the selected subject. The table has five columns. o Property: Name of a property in the block or instance specification o Units: Units defined for the property in SysML (if any). o Original: Original values as defined in the SysML model. Default values are used for a block, whereas slot values are used for an instance specification. o New: New values in the selected analysis case. The user can change input values. When an analysis is completed, new output values will be shown here. o Margin: If the property is related to a requirement through a satisfy relationship, its compliance status will be shown here in terms of margin of satisfaction. 67

68 Reset Values: This will reset New values to Original values in the SysML model. Create Components: This button will create a ModelCenter model for the analysis case. Run: This will cause the ModelCenter model to run and get results back to Plug- In. Save: This will save new values back into the SysML model. When a block is selected as an analysis subject, values will be saved to default values. When an instance specification is selected, values will be saved to slot values. The operation will cause Rhapsody, which is running behind the scenes, to save the SysML model file. This button may be disabled when o New values are the same as Original values o A block is selected as an analysis subject and there is more than one value for a single property in the analysis case. This may happen 1) when there are more than one parts of the same type, or 2) when there is a multiplicity property. In this case, use Save As to save new values as a new instance specification. Save As: Save new values as a new instance specification. This will cause Rhapsody to save the SysML model file. Figure 91: Rhapsody Plug-In. 68

69 5 Advanced Topics 5.1 MBSEAnalyzer SysML Profile MBSE Pak uses a few SysML stereotypes to add information that is required to automatically translate parametric diagrams and verify requirements. The stereotypes are contained in MBSEAnalyzer profile that is placed under Rhapsody profiles folder by the MBSE Pak installer. MBSE Analyzer is a part of MBSEAnalyzer profile. Therefore, MBSEAnalyzer profile must be added to a SysML model before MBSE Analyzer can be used for the model. The profile can be added to a model by using File>Add Profile to Model menu of Rhapsody. Figure 92: MBSEAnalyzer profile (partial view). Figure 92 shows some of the stereotypes in MBSEAnalyzer profile. The stereotypes and tags in the profile is described below. ExternalAnalysis: Applied to a constraint block to define a corresponding analysis existing outside SysML model. o url: URL location of the analysis o type: Kind of the external analysis. The tag is AnalysisType enumeration. Currently only Analysis Server type is supported. AnalysisVariable: Applied to a constraint parameter to define mapping between the constraint parameter and the corresponding variable in the analysis. o direction: define whether the parameter is an input or an output for the analysis. The tag is Direction enumeration type. 69

70 o analysisvarname: if the variable name defined in the analysis is different from the SysML parameter name, specify the variable name. o defaultvalue: Default value as defined in the analysis (optional) o lowerbound: lower bound of the variable defined in the analysis (optional) o upperbound: upper bound of the variable defined in the analysis (optional) Script: Applied to a constraint block to define scripts. o body: Associated scripts o language: Kind of the scripting language. The tag is Language enumeration type. Currently, JavaScript and VBScript are supported. PropertyBasedRequirement: Applied to a requirement to associate meta-data that will be used to check requirements. o lowerbound: lower limit of the value o upperbound: upper limit of the value o equalto: the value must be exactly this o units: units of the property value. TestCaseMatrix: This is used to create a custom element to store the definition of test case matrix. See section for more details about test case matrix. o configuration: configuration string of a test case matrix TestCaseMatrixResult: Applied to a dependency relationship to define results of test case matrix evaluation. o result: data of test case matrix evaluation PartCatalogDatabase: Applied to a block to connect to a parts catalog database o connectstring: location of parts catalog database o tablename: name of the table in database PartCatalogExternalAnalysis: Applied to a block to connect to a parts catalog defined as an external analysis such as Analysis Server component o type: Type of external analysis. The tag is AnalysisType enumeration. Currently only Analysis Server type is supported o url: location of external analysis PartCatalogScript: Not used currently CatalogSelection: Applied to dependency to store the current selection of a part catalog option. o partname: part name as defined in parts catalog o partselector: the corresponding SysML property 70

71 Catalog: Applied to dependency to relate a package that contains catalog options to a block Alternative: Applied to a generalization relationship to define a specialized block as an alternative of the parent block in trade studies AnalysisCase: Used to create a custom element to store analysis case configuration. o configuration: analysis case configuration SimulationCase: Not used currently TradeStudy: Used to create a custom element to store trade study configuration. o analysissubjectpath: SysML path to the analysis subject o configuration: trade study configuration Uniform: Applied to property to associate uniform distribution o max: max value of uniform distribution o min: min value of uniform distribution Normal: Applied to property to associate normal distribution o mean: mean value of normal distribution o standard deviation: standard deviation of normal distribution CallMBSEAnalyzerAction: Not used currently. 71

72 5.2 Selection of Analysis Subject In Evaluate Design tab of MBSE Analyzer, the first thing the user needs to do is selecting a subject to analyze. For example, in the bicycle example, the Bike block was selected as an analysis subject (Figure 77 of section 3.2.7). Then the lower left tree showed applicable parametric diagrams for the block and its parts. There are four types of SysML elements that can be selected as an analysis subject: block, part, parametric diagram, and instance specification. For the first three types, MBSE Analyzer will use default values of the corresponding block for analysis. If an instance specification is selected, its slot values will be used Block When a block is selected as an analysis subject, its part structure will be shown in the lower left tree along with applicable parametric diagrams for the block itself and for its parts (Figure 93). Default values of blocks will be used for analysis. Note that Original values in the right table are default values. If a block has parts, default values of the underlying blocks of the parts will be used. Figure 93: A block is selected as an analysis subject. If an analysis subject block has more than one part of the same type (e.g., wheels of a bike are the type of Wheel block), MBSE Analyzer will create virtual instances of the parts so that the parts can have different values. Note that virtual instances are created in memory in MBSE Analyzer and the SysML model is not changed. Original values in MBSE Analyzer will be the same among the parts of the same type since the values are default values, but the user can assign different New values. When virtual instances are used, New values cannot be saved back to the SysML model, because there is only one 72

73 default value for each property of a block. Therefore, Save button will be disabled. In this case, use Save As capability to create a new instance specification using the New values Part If a part is selected as an analysis subject, it is equivalent to selecting the underlying block of the part. Figure 94 shows that frontwheel part of Bike block is selected. The analysis will be based on default values of Wheel block. This means it will have the same effect whether frontwheel or rearwheel is selected. The discussion about virtual instances in the previous section applies equally when a part is selected. Figure 94: A part is selected as an analysis subject Parametric Diagram When a parametric diagram is selected as an analysis subject, the context of the parametric diagram will be automatically determined. In general, the context is a block. If a parametric diagram is created in a block, the block will be the context. If a parametric diagram is created in a package, the top most block in the parametric diagram will be the context (see section 5.3 for more details). Default values of the context block will be used in analysis, and the discussion about virtual instances in the previous sections applies equally here. One limitation when using a parametric diagram as an analysis subject is that requirements compliance analysis will not be performed. A block, part, or instance specification needs to be selected in order for requirements to be applied to the analysis subject. 73

74 Figure 95: A parametric diagram is selected as an analysis subject Instance specification When an instance specification is selected as an analysis subject, applicable parametric diagrams will be identified for the underlying block. Applicable parametric diagrams will be shown in the lower left tree according to the part structure of the underlying block (Figure 96). Slot values of the selected instance specification will be used in analysis. For instance specifications, MBSE Analyzer does not need to create virtual instances because each part will have its own instance specification. For the bicycle example, front and rear wheels have their own instance specifications. Therefore, each wheel can be analyzed individually. Figure 97 shows that "frontwheel instance specification is selected as an analysis subject. When property values are changed for the front wheel, it will be saved in its own instance specification and does not affect the rear wheel. This means par_wheelweight parametric diagram can be solved either for front wheel or rear wheel. Using instance specifications allows evaluating parts independently. 74

75 Figure 96: An instance specification is selected as an analysis subject. Figure 97: An instance specification corresponding to a part is selected as an analysis subject. 75

76 5.3 Context Block of Parametric Diagram A parametric diagram defines analytical relationships among system properties. It is useful to consider a parametric diagram as an integral part of the definition of a block. In other words, each parametric diagram is created for a block to define analytical relationships among its property values. The block is called context of the parametric diagram. Following this approach, a SysML block is a reusable class definition that contains not only property values, but also analytical relationships. When a block is used as a part of another block, the analytical relationships (e.g., the parametric diagram) automatically apply to the part. This is an object oriented approach that allows relating analysis models to a physical entity in a natural way. MBSE Analyzer automatically determines the context block for each parametric diagram. If a parametric diagram is created in a block, the block will be the context block. If a parametric diagram is created in a package, the top most block on the diagram will be the context block Parametric Diagram in a Block In the bicycle tutorial in section 3.2, each parametric diagram was created in a block. Figure 98 is an example from the tutorial. par_wheelweight diagram was created in Wheel block. Note that the frame of the diagram is Wheel block, which is the context of the parametric diagram. MBSE Analyzer considers this parametric diagram as a part of Wheel block. Figure 98: Parametric diagram created in a block Parametric Diagram in a Package Sometimes it is desirable to organize parametric diagrams using packages. It is possible to create a parametric diagram in a package. In MBSEAnalyzerExamples folder, there is another version of the bicycle model (BicycleParametricsInPackage), where parametric diagrams are created under a package. Figure 99 shows an example, where 76

77 par_wheelweight diagram is created in Analysis package. Since the frame of the diagram is the package, we need to use Wheel block in the parametric diagram. MBSE Analyzer automatically detects the top most block and use it as the context of the parametric diagram. Figure 99: Parametric diagram created in a package. In both approaches in Figure 98 and Figure 99, the end result is the same; the parametric diagram is defined for Wheel block. For example, if Bike block is selected as an analysis subject, par_wheelweight diagram will be applied to front and rear wheels and it will be solved twice (See Figure 78). 77

78 5.4 Automatic Composition of Analysis Model When a block, a part, or an instance specification is selected as an analysis subject, MBSE Analyzer will show all applicable parametric diagrams of the subject and its parts. The user can select one or more parametric diagrams and evaluate them together. An example was discussed in 3.2.7, the mass roll-up calculation of a bicycle. Figure 100 shows how MBSE Analyzer composes the model for the mass roll-up problem. For each wheel, its weight is an output of par_wheelweight parametric diagram. The weight of each wheel is an input of par_bikeweight parametric diagram. The weight properties of the wheels are common in the parametric diagrams, and they implicitly connect the parametric diagrams. Figure 100 illustrates that wheel weights are computed first for the front and rear wheels and the results are used to compute the weight of the bike. MBSE Analyzer recognizes such implicit links between properties, but not between constraint parameters. Therefore, it is required to use a property as an intermediary to automatically combine parametric diagrams. Figure 100: MBSE Analyzer combines parametric diagrams to create a composite analysis model. MBSE Analyzer translates each parametric diagram to an assembly in ModelCenter and creates links among them when there are implicit links. The resulting ModelCenter model will be like Figure 80. Note that a property can be an input or an output in an analysis depending on the selection of an analysis subject and parametric diagrams. When all three parametric diagrams are selected for Bike, weights of wheels are considered as outputs because they are computed from par_wheelweights. Considering another scenario where Bike block is the analysis subject and only par_weightbike is selected for analysis, weights of the wheels will be considered as inputs. This may happen when the user wants to perform high level trades, deferring subsystem level designs. 78

79 5.5 Requirements Modeling MBSE Analyzer provides two ways to check requirements. The first approach uses satisfy relationship from a property to a requirement. The second approach uses verify relationship from a test case matrix to a requirement. This section discusses the two approaches Use of Satisfy Relationships Setting up a requirement for automatic verification requires following steps as discussed in section 3.2.4: 1. Apply PropertyBasedRequirement stereotype to a requirement 2. Specify lowerbound, upperbound, or equalto tag depending on the nature of the requirement. 3. Create a block definition diagram (or parametric diagram) and define a satisfy relationship from a property to the requirement. MBSE Analyzer considers the context of satisfy relationships. Consider Figure 101, where three satisfy relationships are defined in a block definition diagram. In particular, compare two satisfy relationships in the middle and in the bottom. The satisfy relationship at the bottom is defined for weight of Wheel block. The context of the satisfy relationship is Wheel and the relationship applies to any wheels. Therefore, the requirement WheelWeight applies to both the front and rear wheels. On the other hand, the satisfy relationship in the middle is defined for weight of the rear wheel of Bike block. The context of the satisfy relationship is the rear wheel of Bike. Therefore, the RearWheelWeight requirement applies only to the rear wheel. 79

80 Figure 101: Example of "satisfy" relationships. Figure 102 shows the results of requirements verification of the three requirements in Figure 101. Note that WheelWeight requirement was applied twice, once to the front wheel and second to the rear wheel. The current value of 2.5 satisfies the requirement for both wheels. RearWheelWeight requirement was applied only to the rear wheel, and the current value does not satisfy the minimum weight requirement. The example model can be found in MBSEAnalyzerExamples/BicycleRequirements. 80

81 Figure 102: Results of requirements verification. 81

82 5.5.2 Test Case Matrix The approach discussed in the previous section uses lower/upper bounds to automatically check requirements. Although it is useful, the approach has a few limitations. First, the relationship between lower/upper bounds and textual requirement is implicit. If textual requirement is changed, lower/upper bounds need to be manually updated. Second, it is not possible to specify input conditions for requirement verification. Often time requirements compliance analysis involves multiple inputs and multiple outputs. Third, it is not possible to specify multiple test conditions for a requirement. One example would be different structural load conditions for flight segments of an aircraft. MBSE Pak 2.0 introduces the concept of test case matrix to address the limitations. The approach takes following steps: Pick values from textual requirement specification. These values will be used as input conditions and test criteria. Define an analysis case by selecting an analysis subject and parametric diagrams. This allows the use of multiple inputs and outputs to check requirements. Define a test case matrix that may have more than one test case. Picked values are used as inputs for test cases, and also used as test criteria. Test case matrix is evaluated by solving parametric diagrams for each test condition. Results of a test case matrix are presented in a tabular form. The requirement is satisfied when all test cases are passed. The results can be saved in SysML model so that they can be reviewed without running analysis again. If textual requirement is changed after evaluating a test case matrix, MBSE Analyzer allows reconciling discrepancies between original requirement and new requirement. MBSE Analyzer will preserve picked values when possible. If structure of textual requirement was changed, it may require re-defining the mapping between textual requirement and picked values Set up Test Case Matrix This section discusses how to set up a test case matrix from textual requirement. The example can be found in MBSEAnalyzerExamples/CarBrakeTestCaseMatrix. Open MBSE Analyzer and go to Review Requirements area. In the upper left tree, select Requirements package. The lower left tree will show requirements and test case matrices in the package. Select Brake Heating requirement in the list and its textual specification will be shown in the upper right area (Figure 103). 82

83 Figure 103: Select a requirement to define a test case matrix. To create a new test case matrix, click Test Cases button. It will launch Edit Test Cases dialog. The upper left pane shows the textual requirement. Pick values that will be used as input or output for test cases. For example, highlight 60 mph and click + icon to add the value to the list on the right. Repeat the step to pick 53 kw, 70 mph, and 63 kw (Figure 104). Figure 104: Pick values from textual requirement. 83

84 Now define an analysis case that will be used to check requirements. Click Select analysis button. In Select Analysis dialog, select Vehicle block and all three parametric diagrams as shown in Figure 105. Click OK. Figure 105: Define analysis case for test case matrix. Now, the lower left tree of MBSE Analyzer will show properties of the analysis case (Figure 106). Figure 106: Analysis case is defined for test case matrix. 84

85 In the next step, we will define a table of test cases. First, select input and output variables by drag and dropping them into the table in the lower right. In this example, there is one input variable, speed, and one output variable, heat. Since the requirement has two test cases, click twice the + icon above the lower right table (Figure 107). Figure 107: Define input and output variables and add blank test cases. The last step in setting up a test case matrix is to complete test cases table by using picked values. Drag and drop each picked value into a corresponding cell in the table (Figure 108). Note that =, <, and > icons will show up when dropping a value. Drop onto an appropriate icon depending on the nature of the value. Click Save. 85

86 Figure 108: Complete the test cases table using picked values. The test case matrix just created is highlighted in the lower left list in MBSE Analyzer. If desired, give a more meaningful name to the element. On the new test case matrix, use the right click menu Locate in SysML tree. Go to the model tree in Rhapsody and change name of the test case matrix to testcasebrakeheating. In MBSE Analyzer click Refresh. The test case matrix is now ready for evaluation (Figure 109). Figure 109: Completed test case matrix setup. 86

87 Evaluate Test Case Matrix Select the new test case matrix for braking heating and click Evaluate. MBSE Analyzer will evaluate the two test cases and their results will be shown in the test cases table (Figure 110). Both test cases satisfy the brake heating criteria and the requirement is thus satisfied. Figure 110: Results of evaluation of test cases. The evaluation results can be saved in SysML model by clicking Save results button. Since results are saved in SysML model, requirement status can be reviewed later without running analysis again. When a test case matrix is evaluated, the requirement will be applied by default to the block used in the analysis case. To select a different analysis subject such as an instance specification, select a subject in the upper left tree. For example, an instance specification of Vehicle block was selected in Figure 111. The lower left table shows requirements and test case matrices that are applicable to the subject. Select the braking heating test case matrix. 87

88 Figure 111: Select an analysis subject and test case matrix. Note that the test case matrix has not been evaluated for the instance. Click Evaluate button to apply the test case to the instance specification. Figure 112 shows that the instance specification meets the two test cases. Figure 112: Results of test cases for an instance specification. 88

89 The model has another test case matrix testcasestopdistance. Select it in the lower left table to see its textual specification and results of test cases (Figure 113). The test case matrix has three inputs and two outputs, and has four test cases with different input conditions. According to its saved results, test cases 3 and 4 were not satisfied. Figure 113: Test case matrix results for stopping distance requirement that involves multiple input and output test conditions Resolve Discrepancies due to Requirements Changes If textual requirement is changed after a test case matrix is set up, MBSE Analyzer will flag the test case matrix with a warning. Until the requirement is reviewed and any discrepancies are resolved, the test case matrix cannot be used. Figure 114 shows an example, where textual requirement specification was changed. For the first test condition, values v1 and v2 were changed. For the second test condition, the structure of sentence was changed, and v4 is ahead of v3. MBSE Analyzer correctly picked v1, v2, and v3 from the new requirement, while it did not pick up v4 automatically as indicated by question marks in the values table. To resolve the issue, pick 63 kw in the new requirement, and drag and drop it onto the cell with question marks in the values table (Figure 115). The discrepancy is now resolved in the test case matrix. Click Accept Changes. When a test case matrix is updated, its saved results are removed since they are not valid anymore. 89

90 Figure 114: When textual requirement is changed, new values may need to be picked. Figure 115: Test case matrix is updated using new requirement. 90

91 5.6 Property Multiplicity and Array Variables In engineering analyses, it is common to use array variables. In SysML models, a property with multiplicity greater than one can be considered as an array variable. Figure 116 shows a parametric diagram that uses array variables (The example file can be found in MBSEAnalyzerExamples/SortArrayExample ). The constraint block SortArray takes an array as an input, sorts its elements and produces an output array. Figure 116: An example of analysis that uses array variables. inputs and outputs properties of System block are properties of multiplicity of 5. Figure 117 shows the specification view of inputs property. Note that only one default value can be specified for a property, regardless of its multiplicity. For the example of inputs property, the default value (e.g., initial value) is 2.0. It means that elements of the property will be initialized to 2.0, when an instance specification is created. Figure 117: A property with multiplicity. 91

92 Since only one default value can be defined for a property, MBSE Analyzer will automatically create virtual instances to specify multiple values for a property with multiplicity, when a block is selected as an analysis subject. Figure 118 shows MBSE Analyzer, where System block is selected as an analysis subject. inputs and outputs properties have five elements respectively, and their values are initialized as the default value, 2.0. Figure 118: MBSE Analyzer uses virtual instances to specify values of properties with multiplicity. Since virtual instances are used, different values can be given to the elements. Figure 119 shows an example, where the analysis generated a sorted array. Figure 119: Perform analysis using arrays. 92

93 Note that Save button is disabled in Figure 119. That is because there is only one default value for each of the properties used here. It is not possible to save multiple values for a property in a block. Instead, use Save As to create a new instance specification. Array values will be saved in a slot of an instance specification. Figure 120 shows an instance specification of System was created using Save As. In the SysML model tree, the values can be examined in specification view of slots (Figure 121). Figure 120: An instance specification is created to save values of properties with multiplicity. Figure 121: Instance specification and slots are used to save values of properties with multiplicity. Note that SortArray constraint block was created by using Import Analysis capability of MBSE Analyzer. The analysis has two array variables. When an analysis with array variables is imported, multiplicity of * will be applied to the constraint parameters. If the analysis handles arrays of varying length, it is possible to feed values of varying length. This can be done by changing the multiplicity of the property through 93

94 the specification view in Rhapsody. Currently MBSE Analyzer does not provide a way to change the length of a property through its GUI. MBSE Analyzer supports only 1- dimensional arrays. 94

95 5.7 Part Multiplicity In the previous section, we discussed how properties with multiplicity can be connected to array variables in analysis. In this section, we discuss how a part with multiplicity may introduce array variables in parametric diagrams Part Multiplicity and Array Figure 122 is another version of the bicycle weights roll-up problem, found in MBSEAnalyzerExamples/BicycleMultiplicity. Instead of having separate parts for the front wheel and rear wheel, Bike block has a wheels part of multiplicity of two. In general, elements of the part may not be identical. If elements of a multiplicity part need to be treated as identical, see section for another modeling approach. In a parametric diagram, the weight of Bike is computed by adding up weights of two wheels and the weight of a frame. Although weight property of Wheel block has multiplicity of one, there are two values of it since the wheels part has multiplicity of two. Therefore, it is possible to connect weight of wheels part to arrayx constraint parameter, which is an array variable. The parametric diagram for Wheel block stays the same (see Figure 76). Figure 122: Part multiplicity may introduce array variables in parametric diagrams. When Bike block is selected as an analysis subject, MBSE Analyzer creates virtual instances of the elements of wheels part so that elements can be shown individually. The lower left tree in Figure 123 shows that wheels part has two elements and each of them has par_wheelweight parametric diagram associated. The properties table on the right shows that wheels part has two elements. Each element of wheels part has an index starting from 0. Using virtual instances of wheels, MBSE Analyzer allows specifying different values to wheels as shown in Figure 123. Note that Save button is disabled in Figure 123. It is because there are two wheels but there is only one default value for each property of Wheel block and it is not possible to save values back to default values in blocks. Instead, use Save As to save new values as a new instance specification. MBSE Analyzer automatically creates instance specifications for multiplicity parts. An example of an instance specification that was created by Save As is shown in Figure 124. The wheels slot of bikea instance specification has two instance specifications of Wheel block. 95

96 Figure 123: MBSE Analyzer uses virtual instances to show elements of a multiplicity part. Figure 124: MBSE Analyzer automatically creates instance specifications for multiplicity parts Identical Multiplicity Parts Assuming that elements of a multiplicity part may not be identical, MBSE Analyzer automatically creates virtual instances as necessary. This section discusses a different modeling approach for cases where elements of a multiplicity part should be treated as identical. An example is found in MBSEAnalyzerExamples/BicycleMultiplicityIdentical. 96

97 The SysML modeling approach is illustrated in Figure 125. Note that the multiplicity of wheels part is 1..*, indicating there can be one or more wheels, and the actual multiplicity number is defined using a property count in Wheel block. A parametric diagram is created to compute the weight of Bike by adding up weights of wheels and a frame. To compute the total weight of wheels, the weight of a wheel is multiplied by count using Multiply constraint block. Then SumTwo constraint block adds the total weight of wheels and frame weight to compute the weight of Bike. Note that this approach is particularly useful when the number of parts is a design parameter for a system. Figure 125: Actual multiplicity can be defined as a property for an identical multiplicity part. Figure 126: There is one element of the identical multiplicity part. 97

98 When Bike block is selected as an analysis subject, MBSE Analyzer will create a minimum number of virtual instances for a multiplicity part. Since wheels part has the multiplicity of 1..*, the minimum number is one. Hence, there is only one element of wheels part (Figure 126) in the lower left tree of MBSE Analyzer. That means par_wheelweight will be solved only once. This makes sense since the wheels are identical. Note: If multiplicity of * is specified for wheels part, the minimum multiplicity number is zero. MBSE Analyzer will not show any element for the part and it is not possible to run parametric diagram for the part. The minimum multiplicity needs to be 1 in order to support the concept of identical multiplicity parts in MBSE Analyzer. Note that Save button is enabled in Figure 126. That is because only one virtual instance was created for Wheel block and there is no ambiguity in terms of saving new values back to default values in blocks. If desired, new values can be saved as a new instance specification using Save As. 98

99 5.8 Parts Catalog Complex systems are seldom created from scratch. Rather, there are many off-the-shelf parts available. A key element of system design process is to choose the best combination of parts from available options. This section discusses how to connect parts catalog to system architecture model and perform trade studies. MBSE Analyzer supports two types of parts catalog. First, external parts catalog uses Excel spreadsheet or database such as MySQL or Postgre. This allows maintaining parts catalog separate from SysML model. When parts catalog is big, this approach prevents system architecture model from being bloated with catalog data. Second, internal parts catalog can be defined directly in SysML model. This may be useful when there are only a handful of parts options are available External Parts Catalog MBSE Analyzer supports two kinds of external parts catalog. First, catalog table defined in Excel or JDBC database can be used. Second, an Analysis Server component configured as a lookup table can be used Using Database Table To demonstrate the use of database table, we will connect MBSEAnalyzerExamples/CarBrake model to an Excel spreadsheet. The Excel spreadsheet is found in MBSEAnalyzerExamples/analyses/brake/ BrakePartsCatalog.xlsx. As shown in Figure 127, the spreadsheet has two catalog tables, one for pad and the other for caliper. Each table has partnumber column that is used as key. The rest are value columns that correspond to properties in a part. We will map SysML properties in blocks to value columns in catalog table. Figure 127: Parts catalog defined in Excel. Open the Rhapsody model. Start MBSE Analyzer and go to Parts Catalog tab. In the upper left tree, select Structure package to see the list of blocks in the package (Figure 128). We will connect Caliper and Pad blocks to parts catalog. First select Caliper block, and click Connect to>connect to Database button. This will open Select Database dialog. Select Excel as database type and browse for the Excel spreadsheet file (Figure 129). 99

100 Figure 128: Parts catalog management. Figure 129: Select database of parts catalog. In the next dialog, select table name as caliper and select key column as partnumber. If needed, a subset of columns can be selected in the lower table. In this example, we will use all columns. Click Next. 100

101 Figure 130: Select columns to use. The next dialog allows defining mappings between columns in catalog table and properties in SysML block (Figure 130). MBSE Analyzer will automatically suggest mappings if names match between SysML and catalog. Figure 131 shows that a new property partnumber will be created for Caliper block to store part number. Four mappings will be created for properties of the block. Note that normalforce property has no mapping because it will be calculated by engineering analysis, rather than determined by parts catalog. Click Finish. Now Caliper block is connected to parts catalog. Figure 131: Define mapping between columns in catalog table and properties of block. Repeat the steps to connect Pad block to pad table in the Excel spreadsheet. MBSE Analyzer will show that Caliper and Pad blocks are connected to parts catalog (Figure 132). 101

102 Figure 132: Blocks are connected to parts catalog. Figure 133: Configure a design by selecting parts catalog options. 102

103 Now we can use the parts catalog when evaluating designs. Go to Evaluate Designs tab in MBSE Analyzer. Select Vehicle as analysis subject and select all three parametric diagrams. Since caliper and pad are connected to parts catalog, part numbers can be used as design parameters instead of individual properties. Select a part option from the drop down list of partnumber for caliper, and also for pad. Note that property values are updated from parts catalog when a new part option is selected (Figure 133). Properties that are connected to parts catalog are output determined by catalog. Thus, their values cannot be changed. If desired, parts catalog can be turned off using the lower left tree, which shows both parametric diagrams and parts catalog. If parts catalog is turned off for a part, properties of the part can be changed individually. Click Run to evaluate the design. Results in Figure 134 show that two requirements are not satisfied for the design configuration. Figure 134: Evaluation results of a design configured by parts catalog. Trade study tools can be used to evaluate combinations of available parts options. Launch DOE tool from Evaluate Designs tab. Use partnumber properties as design variables and add a few performance properties as response variables in DOE setup (Figure 135). Caliper and pad parts have five options each, and the total number of possible combinations is 25. DOE type should be Parameter Scan since part numbers are discrete variables. Run the DOE setup and collect results in Design Explorer. Points cloud visualization tools can be used in Design Explorer to analyze trade space and identify promising designs Figure 136 shows a multi-dimensional glyph plot created for the 25 system configurations evaluated by DOE. 103

104 Figure 135: Design of experiments setup using parts catalog. Figure 136: Results of design of experiments using parts catalog. 104

105 Using Analysis Server Components This section discusses how an Analysis Server component can be used as parts catalog. This approach can be useful when property values of a part need to be calculated by engineering analyses. For example, an Analysis Server wrapper can be created that takes a part name as an input and calculates property values. To illustrate the example, consider a ModelCenter model CaliperPartsCatalog.pxc found in MBSEAnalyzerExamples/analyses/brake. The model has an Excel plugin component that takes partnumber as an input and calculates property values. PXCWrapper was defined for the model to shorten variables names. Although the Excel file is essentially a look-up table, in general the internal logic to determine property values can be anything beyond simple look-up table. Caliper block will be connected to parts catalog based on the PXC wrapper. Go to Manage Parts Catalog tab, select Caliper block, and click Connect to>connect to Analysis Server. Connect to Analysis Server and select brake/caliperpartscatalog component (Figure 137). Click Next. Figure 137: Select an Analysis Server component for parts catalog. The next dialog will show suggested mapping from analysis variables to block properties (Figure 138). 105

106 Figure 138: Suggested mapping from analysis variables to block properties. We need to add mapping for partnumber. There is no property in the block that corresponds to part number and a new property needs to be created. Create a mapping by drag and dropping partnumber variable onto <add new> row in the right table. It will create a new property in the block and create mapping. The dialog will look like Figure 139. Click Finish. Figure 139: Add mapping for partnumber. MBSE Analyzer shows that Caliper block is now connected to parts catalog defined in Analysis Server (Figure 140). 106

107 Figure 140: Block is connected to parts catalog in Analysis Server. The parts catalog can be used in Evaluate Designs tab. partnumber of caliper can be picked from a drop down list. When a part number is selected, property values will be calculated from the analysis and updated in MBSE Analyzer as seen in Figure

108 Figure 141: Use parts catalog defined in Analysis Server. Parts catalog defined in Analysis Server can be used in the same way as parts catalog defined in database. For instance, part numbers can be used in trade study tools as discussed at the end of section

109 5.8.2 Internal Parts Catalog When parts catalog is small, it may be more convenient to define catalog data directly in SysML model. MBSE Analyzer supports a SysML modeling approach of internal parts catalog. An example can be found in MBSEAnalyzerExamples/CarBrakeInternalPartsCatalog. Figure 142 shows a parts catalog defined for Pad block. In this approach, catalog options are defined as instance specifications of the corresponding block. In the example, three instance specifications of Pad are stored in PadCatalog package. A dependency relationship with Catalog stereotype is used to connect a parts catalog to a block. Figure 142: Parts catalog can be defined directly in SysML model. In Evaluate Designs tab, available catalog options will appear under pad part. Drop down list includes Pad block, and three instances in the parts catalog. When Pad block is selected, its default values will be used, whereas slot values will be used when an instance specification is selected. Figure 143 shows an example, where an instance specification was selected for pad part. 109

110 Figure 143: Catalog options can be selected for pad part. 110

111 5.9 Refine Parametric Diagram In SysML modeling, generalization relationships are often used to define specialized child blocks from a parent block. In such a case, analytical relationships defined for the parent block may not be valid for a child block, and they need to be modified accordingly. One modeling approach would be to redefine constraint properties of the parent block. However, it does not support the use of additional properties of a child block that are not in the parent block. An alternative modeling approach is to refine parametric diagram of the parent block. Since a new parametric diagram is created for child block, properties defined for child block can be used with no problem. MBSE Pak supports the approach of refining parametric diagrams. An example is found at MBSEAnalyzerExamples/CarBrakeRefinedParametrics. A block definition diagram shows generic Caliper block and two specialized caliper blocks: MechanicalCaliper and ElectricCaliper. Note that the generalization relationships are stereotyped with Alternative, which indicates that the two specialized blocks can be used as alternatives in design trade-offs in MBSE Analyzer. Each of the caliper blocks has its own constraint property that contains different engineering analysis according to the nature of selected technology (Figure 144). Figure 144: Each of child blocks inheriting from a parent block has its own constraint property. Figure 145 and Figure 146 show parametric diagrams defined for Caliper and ElectricCaliper, respectively. The latter diagram refines the former through refine relationship. Note that a new property, efficiency, was added to ElectricCaliper block when it was specialized from Caliper, and ElectricCaliperAnalysis constraint block takes efficiency as an input. Figure 146 shows that properties of the parent block and the new property of the child block, efficiency, are used in parametric diagram. 111

112 Figure 145: Parametric diagram defined for the parent block. Figure 146: Parametric diagram of a child block. This diagram refines the parametric diagram of the parent block. MBSE Analyzer has a capability of automatically selecting corresponding parametric diagrams based on the selection of part options. In MBSE Analyzer, go to Evaluate Designs tab. Select Vehicle block as an analysis subject (Figure 147). By default, the parametric diagram defined for Caliper block will be used. In the properties table on the right, select ElectricCaliper for caliper part. Note that the parametric diagram for electric caliper is automatically picked up in the lower left tree. This capability allows evaluating different technology options by running analysis models created for specific options. 112

113 Figure 147: When a specialized part option is selected, refined parametric diagram is automatically picked up. 113

114 5.10 Read Only Properties If a SysML model is under configuration management, the user may not have write permission on some of the model elements. MBSE Analyzer will prevent the user from modifying read-only model elements. Figure 148 shows the brake example, where Vehicle block is read only. Properties of the read only block are shown in washed-out color in MBSE Analyzer. Note that the user still can change New values for read only properties in MBSE Analyzer and run analyses. However, MBSE Analyzer does not allow saving new values to read only properties. If values are changed for read only properties, Save button will be disabled as shown in Figure 148. Instead, new values can be saved as a new instance specification using Save As, to a package for which the user has write permission. Figure 148: Cannot save values for read only SysML properties. 114

115 5.11 SysML Model Validation Rhapsody provides a capability to check SysML model for its correctness. Since MBSE Analyzer relies on stereotypes and tags discussed in 5.1, there are additional rules that a SysML model needs to follow for MBSE Pak to work properly. Rhapsody MBSE Analyzer added one model validation rule. If a constraint block is stereotyped by ExternalAnalysis, it url tag must be defined. If a constraint block does not follow the rule, it will be flagged. Run Tools>Check Model>DefaultConfig from Rhapsody menu. Figure 149 shows that a constraint block was flagged that did not have url tag defined. Figure 149: Results of MBSE Analyzer model validation. 115

116 5.12 Data Source Plug-In MBSE Analyzer and Rhapsody Plug-In use SysML parametric diagrams to connect to engineering analyses. This requires someone to set up parametric diagrams. For domain/disciplinary engineers who are not familiar with SysML, creating parametric diagrams can be a challenge. As such, there is a need to lower the barrier for engineers who want to utilize SysML models. One approach is using a SysML model as a data source to set up engineering analyses. This does not require creation of parametric diagrams; it is up to engineers how to set up analytical models in ModelCenter, starting with the imported SysML data. Figure 150: Launch Rhapsody Data Source Plug-In. Rhapsody Data Source Plug-In was created to support this approach. The Data Source Plug-In uses a SysML model as a database of system information. Rhapsody Data Source Plug-In can be launched from Server Browser in ModelCenter (Figure 150). Figure 151 shows an example of the SysML data source plug-in. In the example, Vehicle block was selected as a data source. The lower left tree shows parts and properties of the selected block and the user can select properties to import. Anticipating analysis model that will be created, the user can specify some of the properties as output. The table on the right displays a list of the SysML properties that are selected, along with their current values. The selected SysML properties will be translated to variables in ModelCenter. Figure 152 shows the Rhapsody Data Source plug-in, which contains an assembly called Bike. Note that Rhapsody Data Source plug-in works in the same way as Rhapsody Plug-in except that no analysis components are created so that the user can manually create them. The Bike assembly contains variables structure based on the SysML block as seen in Component Tree of ModelCenter. When analysis components are added to the assembly, links can be created from/to the variables in the assembly. To define a mass roll-up analysis similar to what was done in section 3.2.6, add math/sumtwo and math/sumthree components from Analysis Server. Two instances of SumTwo component need to be created since it needs to be solved for front and rear wheels (Figure 153). 116

117 Figure 151: Rhapsody Data Source Plug-In. Figure 152: Data Source plug-in creates a template for engineering analyses. 117

118 Figure 153: Add analysis components to Data Source Plug-In. To complete the model, create links from/to the assembly variables using Links Editor (Figure 154). Note that units warnings may show up if you are using ModelCenter 11 or later. In this case, units warnings appear because no units are defined for the generic math components such as SumTwo and SumThree. The warnings can be ignored in this example. Here is the list of links: Bike.frontWheel.tire.weight SumTwoFront.x1 Bike.frontWheel.rim.weight Bike.SumTwoFront.x2 SumTwoFront.sum Bike.frontWheel.weight Bike.rearWheel.tire.weight SumTwoRear.x1 Bike.rearWheel.rim.weight SumTwoRear.x2 SumTwoRear.sum Bike.rearWheel.weight Bike.frame.weight SumThree.x1 Bike.frontWheel.weight Bike.SumThree.x2 Bike.rearWheel.weight SumThree.x3 SumThree.sum Bike.weight Analysis model is now complete. The user can perform what-if studies by changing SysML property values and running the analysis model. Open Data Source Plug-in dialog. Change input values and run the analysis. Figure 155 shows that the same results were obtained as when MBSE Analyzer used parametric diagrams. 118

119 Figure 154: SysML properties in Data Source Plug-In can be manually linked to analysis components (units warnings can be ignore in this model). Figure 155: Perform engineering analysis using Data Source Plug-In. 119

120 The SysML data source plug-in provides a simpler way for engineering analysts to access system architecture models. Combined with the formal approach of using parametric diagrams, the toolset provides flexibility in deploying the integrated model framework in diverse engineering teams. 120

121 5.13 Preferences MBSE Analyzer Preferences of MBSE Pak are accessible using Tools>Preferences menu. Figure 156: MBSE Analyzer preferences dialog Evaluate Designs Populate analysis data in Data Explorer: if this is on, when an analysis case is evaluated in Evaluate Designs tab, the results will be added to Data Explorer Trade Studies Save all variables: if this is on, all properties in analysis subject will be added to Data Explorer when performing a trade study from MBSE Analyzer Logging Logging Level: By default, the logging level will be INFO. To see more information, set it to DEBUG. Log messages can be turned off if desired. For MBSE Analyzer, log messages will be sent to Log window in Rhapsody Parts Catalog Auto-Update Parts Catalog Parts: if this is on, property values of a part will be automatically pulled from parts catalog when a new part is selected in Evaluate Designs tab in MBSE Analyzer. Otherwise, part property values will be updated when an analysis is performed. 121

122 Logging for Rhapsody Plug-In For Rhapsody Plug-In, its logging level can be specified in the properties dialog of the plug-in component (Figure 157). Log messages will be sent to ModelCenter log files and optionally to Java Console of ModelCenter. This can be controlled in Tools>Preferences dialog in ModelCenter. To locate ModelCenter log files, use Open Logs Folder button in ModelCenter Preferences Dialog. Figure 157: Specify logging level of the plug-in component in ModelCenter. 122