SysML Block Structure → Teamcenter
Generating a Teamcenter Product Structure from SysML
- The object of this tutorial is to generate a product structure in a Teamcenter repository from a block structure in a MagicDraw SysML model. We will use the sample model Syndeia Tutorial Testbed. An identical tutorial for a Windchill repository is provided here.
- Create an empty product in a Teamcenter repository to which you have access. In this example, it will be UAV-Demo in the repository Tc-newuav. (It is outside the scope of this tutorial to describe how to use the PLM tools, but in Teamcenter, it is necessary to open an interface to your Teamcenter repository and go to File→New→Folder. Appendix 1 provides a more detailed description of working directly in Teamcenter repositories.)
- Open the MagicDraw model Syndeia Tutorial Testbed. Right-click on package Tutorial_2_04, launch the Syndeia dashboard, and click on the Connection Manager tab. Click on Repository at the top of the right panel and select the Tc-newuav repository. The dashboard should appear as in Figure 8. The left panel shows the SysML model element. The right panel shows the contents of the Teamcenter repository Tc-newuav.
Figure 29 Syndeia Dashboard, Connection Manager tab
- To generate the UAV part structure in the empty product UAV_Demo, choose Model Transform as Connection Type in the center of the dashboard, then drag-and-drop the UAV block from the left panel onto the UAV_Demo product in the right panel. A window will appear as in Figure 9. Click Yes.
Figure 30 Syndeia Dashboard, Connection Manager tab - A series of messages will scroll in the bottom section of the dashboard. As shown in Figure 10, the UAV_Demo product on the PLM side now reflects the product structure imported from the SysML model.
Figure 31 Syndeia Dashboard, Connection Manager tab, after generation of part structure in the PLM repository - To view the persistent connection that has been created between the UAV block in the SysML model and the UAV part under the UAV_Demo PLM product, click on the Connection Browser tab of the Syndeia Dashboard and expand the UAV block on the left. Note the connection in Figure 11 below; the connection label (C3) assigned by Syndeia and/or the UAV version number (A.3) may be different in your case.
Figure 32 Syndeia Dashboard, Connection Browser tab, showing the connection between SatelliteSystem in the two domains
- To view all the connections to elements in the Tutorial_2_04 SysML model, click on the Connection Summary tab (Figure 12) of the Syndeia Dashboard and click the Refresh button on the upper right. Note that connections were created between all of the blocks that are used as parts of UAV, e.g. Body, and the corresponding parts created in the PLM product.
Figure 33 Syndeia Dashboard, Connection Summary tab, showing all the connections owned by the Tutorial_2_04 SysML package.
Syncing SysML Changes to Teamcenter
Currently, Syndeia supports updating of names and part structures from the SysML model to the PLM repository (and in reverse). Additional capabilities will be added in the future. In this exercise, we will continue with the models from the last section, adding an additional block, Payload, to the SysML model and using it as a part of the UAV. The resulting SysML model BDD looks like Figure 34.
Figure 34 Modified UAV SysML model
Refresh the Syndeia dashboard by right-clicking the Tutorial_2_04 package on the left side and choosing Refresh. It will appear similar to Figure 14.
Figure 35 Syndeia dashboard, Connection Manager tab, after modifying SysML model, before updating PLM repository
The corresponding Connection Browser tab appears as in Figure 36. For this screenshot, we (1) right-clicked on the Tutorial_2_04 package (top row) and selected Expand All, and (2) filtered the Connection column by clicking on the downward arrow icon in the column header, selecting (Custom…), and choosing "is not empty" criterion. This reduces the number of empty rows displayed.
Figure 36 Syndeia dashboard, Connection Browser tab, after modifying SysML model, before updating PLM repository
Use the Comparison Manager to display the current differences between the two models. Right-click on the Tutorial_2_04 package and choose Compare SysML & Target, as shown in Figure 37.
Figure 37 Launching comparison
The Comparison Result tab will be displayed, as in Figure 38. Note that the row are shown in red represents the new part property of UAV that has no corresponding element on the PLM side. Note that the new block, Payload, does not appear in the table, because it does not have an existing connection to a PLM object to compare against.
Figure 38 Syndeia dashboard, Comparison result tab, after modifying SysML model, before updating PLM repository.
To update the PLM model from the revised SysML model, right-click on the Tutorial_2_04 package and select Sync SysML → Target. The results of this operation are shown for the Connection Manager (Figure 39), Connection Browser (Figure 40), and Comparison Result (Figure 41) tabs after syncing. It may be necessary to refresh each display. For the Comparison Result, you will need to perform the Comparison again to check that everything is in-sync, as shown in Figure 41.
Note that the version of the UAV part in Teamcenter has changed from A;1to B;1 (since 2 new part occurrences have been added), as shown in Figure 39. The connection between the UAV block in SysML and the UAV part in Teamcenter has been updated to point to this new revision (B;1), as shown in Figure 40.
The same updating result would have been achieved if we had synced the UAV block across connection C12 (Figure 36). By syncing across the Tutorial_2_04 package, we synced simultaneously across all 3 connections held by blocks in that package.
If we had updated in the opposite direction, PLM to SysML, the result would have been different. The part property pyld would have been deleted from the UAV block, although the Payload block would not have been affected.
Close the Syndeia dashboard when the exercise is completed.
Figure 39 Connection Manager after syncing
Figure 40 Connection Browser after syncing
Figure 41 Comparison Result after syncing
SysML Requirements Structure → Teamcenter
Syndeia allows requirements to be generated, compared and synchronized bidirectionally between MagicDraw and Teamcenter. Exchange is complicated by the different approaches to requirements hierarchies in the two tools.
Generating Teamcenter Requirements from SysML
The object of this tutorial is to generate requirements in Teamcenter from requirements in a MagicDraw SysML model. In this exercise, we will start from the Tutorial_2_11 package in the Syndeia Tutorial Testbed.mdzip model provided with this tutorial. The user also needs an active repository link to Teamcenter, which can be the same as that used in Section 2.4, plus at least one empty folder within the Teamcenter repository in which the new requirements structure can be created.
Figure 94 SysML Requirements diagram
- The initial requirements structure in MagicDraw looks like Figure 94. We will add two new stereotypes from the Syndeia profile to identify the top two requirements as special Teamcenter requirements elements.
- In the MagicDraw containment browser, right-click on UAV Specification, select Stereotype, check the box next to TC_RequirementSpec _Revision, and click Apply.
- Similarly right-click on Engine Specification, select Stereotype, check the box next to TC_Paragraph _Revision, and click Apply.
The additional stereotypes on these two elements will appear on the requirements diagram. It is beyond the scope of this tutorial to describe the significance of Paragraphs and Requirement Specifications in Teamcenter repositories, but these elements obey certain rules in building requirements hierarchies and applying the stereotypes at the SysML level is necessary for Syndeia to recognize the need to create these elements in the next step.
Figure 95 MagicDraw Project Options Menu
- To avoid problems between the auto-numbering functions on MagicDraw and Teamcenter, it may be necessary to turn off MagicDraw's auto-numbering feature, as shown in Figure 95.
- In the MagicDraw menu bar, select Option→Project and choose General Project Options.
- Scroll down to the Numbering section and uncheck Use Element Auto-numbering.
- MagicDraw requires that this setting be made for each individual project. It cannot be set as default for all projects.
- Without this setting, MagicDraw will tend to renumber the Teamcenter requirements whenever the two models are connected, which may not be desirable for the user.
Launch the Syndeia dashboard from the Tutorial_2_11 package. In the Connection Manager tab, select the appropriate Teamcenter link for access to the empty Teamcenter folder. In Figure 95, the tc-newuav Teamcenter repository contains an empty folder Demo3.
Figure 94 Connection Manager showing SysML Tutorial 2_11 package and empty Demo3 folder in Teamcenter
- Drag the UAV Specification requirement from SysML onto the Demo3 folder. Confirm the generation of Teamcenter requirements as in Figure 96. The dashboard shows the final requirements structure in Teamcenter at completion in Figure 97. The connections created are shown in Figure 98.
Figure 96 Confirmation window
Connection Manager showing final Teamcenter requirements structure
Figure 98 Connection Summary showing connections between SysML and Teamcenter requirements
Syncing Requirements from SysML to Teamcenter
Syndeia is able to compare and sync requirements across existing connections.
Figure 99 Compare Requirements
- Change the text of the Max Power requirement in MagicDraw to "The UAV engine shall generate at least 75 horsepower."
- In the Syndeia dashboard, Connection Browser, right-click on the Requirements folder and select Compare SysML & Target, as shown in Figure 99.
Figure 100 Comparison of requirements across connections - Figure 100 shows the results of the comparison. The Max Power requirement is identified as having changed in Name, ID or Description, although the specific change is not identified.
- The requirements may be synchronized in either direction, by choosing Sync SysML → Target or Sync Target → SysML, as shown in Figure 99.
Dependencies from SysML to Teamcenter
Syndeia is able to generate, compare and sync dependencies between SysML and Teamcenter. In SysML, dependencies include <<satisfy>>, <<trace>>, <<verify>>, <<allocate>> and other relationships that are dependencies with additional stereotypes attached. In Teamcenter, dependencies take the form of Trace Links, which do not differentiate between different types of SysML dependencies.
Figure 101 SysML Requirements diagram showing dependencies
- The SysML model in Tutorial 2_11 contains both requirements and blocks, with <<satisfy>> relationships between them, as shown in Figure 101.
- Launch the Syndeia dashboard from the Tutorial 2_11 package in MagicDraw.
Figure 102Syndeia Settings tab - Set Syndeia options so dependencies are carried across the connectors. In the Syndeia dashboard, Settings tab, check the three boxes marked "Generate SysML Dependencies and Trace Links", "Generate SysML Dependencies and Trace Links Recursively", and "Generate Other End of SysML Dependencies and Trace Links", as shown in Figure 102.
- The Connection Browser should appear similar to Figure 104.
Figure 103 Teamcenter model viewed in Syndeia Connection Manager, trace links highlighted
Figure 104Connection Browser - Set Connection Type to Model Transform. Drag the UAV block from the SysML model onto the Demo3 folder on the Teamcenter side. The final state of the Teamcenter model, partially expanded, is shown in Figure 103. The trace links corresponding to the <<satisfy>> relationship between UAV and UAV specification are shown as associated with both elements in Teamcenter. The two <<satisfy>> relationships originating from the Engine block appear next to the Engine item version, as well as the Efficiency and Max Power requirements.
- Other dependencies, including <<allocate>>, <<verify>> and <<trace>>, can be transferred as trace links in the same way.
Teamcenter Product Structure → SysML
Generating a SysML Product Structure from Teamcenter
The object of this tutorial is to generate a block structure in a MagicDraw SysML model from a product structure in Teamcenter. In this exercise, we will continue from the work created in the previous tutorial. An identical tutorial for a Windchill repository is provided here.
The package Tutorial_2_05 in the SysML model is empty. Launch the Syndeia dashboard from this package (close it first if it is still open from the previous exercise). Using the Connection Manager on the Syndeia dashboard, as shown in Figure 42, set the Connection Type to Model Transform and drag the UAV (B;1) item version from the repository side onto the empty SysML package on the left. Click Yes on the dialog box window that appears to confirm (Figure 43)
Figure 42Syndeia dashboard with empty package New_Satellite and Satellite_User PLM part Structurein Teamcenter
Figure 43 Confirmation window
After the part generation is complete, the Syndeia dashboard should appear as in Figure 44.
Figure 44Syndeia Dashboard after generation of SysML part structure in Tutorial_2_05
Confirm that MagicDraw displays the same new part structure in the previously empty package Tutorial_2_05. Save the revised SysML model.
Syncing Teamcenter Changes to SysML
In general, updating the SysML model from the PLM part structure is the simple inverse of the procedure described in Section 2.4.2: Right-click on the connection or connections to be updated and select Synch Target -> SysML. However, we will consider a more complex scenario where both models have been changed individually and we want to combine the changes.
Figure 45 MagicDraw model has been revised by adding two parts to Body block.
- In MagicDraw, delete the Payload block and add two new blocks, Fuselage and Wings, and use them as parts of the Body block. Figure 45 shows the revised structure. Note that the diagram had to be created by the MagicDraw user; it is not created automatically by either MagicDraw or Syndeia.
- Using the Syndeia dashboard, delete the existing connection between the Payload item in Teamcenter and the Payload block (now deleted) in the SysML Tutorial_2_05 package. Currently, Syndeia does not automatically remove connections when an element at either end of the connection is deleted, so this must b done manually. Leaving the "orphaned" connector in the model will create problems later during synch.
- After these changes, the Connection Manager tab in the Syndeia dashboard should look like Figure 46. If we right-click on Tutorial_2_05 in the Connection Browser and select Compare SysML & Target, the Comparison Result tab will look similar to Figure 47. The differences are (connection and revision IDs may differ in your exercise)
- Under C14, the Latest Target has a part pyld:Payload (A;1) that does not appear in SysML.
- Under C16, the Body block in SysML has two new parts, fsl:Fuselage and wng:Wings.
Figure 46 Syndeia dashboard after changes to both SysML and PLM part structures
Figure 47 Syndeia dashboard, Comparison Result tab, after changes to both SysML and PLM part structures
- In this exercise, we wish to update the PLM model changes to the SysML side without overwriting the changes made to the SysML model. If we chose to update from PLM to SysML across all the connections simultaneously (i.e. at the Tutorial_2_05 package level), the result would be to delete the new part properties fsl:Fuselage and wng:Wings on the SysML side, because these parts do not exist on the PLM side. Instead, we will update the SysML model across individual connections.
- In the Connection Browser tab, on the UAV block row or on the connection C14 row beneath it, right-click and select Sync Target -> SysML.
Do a new comparison across all connections. The Comparison Result tab should look like Figure 48. Note that the mismatch across C14 has been resolved, but the mismatch across C16 has not. The original changes to the SysML have not been pushed over to the PLM side.
Figure 48 Syndeia dashboard, Comparison Result tab, after changes to both SysML and PLM part structures
To fully harmonize the two models, it would be necessary to push the SysML changes in Body over to the PLM side, syncing SysML -> Target across C16 or across all connections.
Teamcenter Requirements Structure → SysML
The reverse process from Section 2.11, generating requirements in MagicDraw from the Teamcenter repository, is very similar, including the features of comparing and synching. Exchange is complicated by the different approaches to requirements hierarchies in the two tools.
Generating SysML Requirements from Teamcenter
- The object of this tutorial is to generate a requirement in a MagicDraw SysML model from a requirement in Teamcenter. In this exercise, we can start with any empty SysML package in a MagicDraw model containing the Syndeia profile. We will use the same Teamcenter repository populated in the previous exercise. Launching the Syndeia dashboard from the empty Tutorial_2_12 package, we see REQ-0002308/A;1-UAV Specification, (Figure 105).
Figure 105 Syndeia Dashboard showing empty SysML package and requirements structures in Teamcenter repository - Set Connection Type to Model Transform. Drag and drop REQ-0002308/A;1-UAV Specification onto the Tutorial_2_12 package. Click Yes in the confirmation dialog box shown at the bottom of Figure 106.
Figure 106 Confirmation window - The final state of the Connection Manager is shown in Figure 107.
Figure 107 Connection Manager after dragging UAV Specification into MagicDraw
- The SysML model created from this single action is complex and requires some explanation.
Teamcenter, unlike SysML, allows a requirement to be owned by more than one other requirement or requirement specification. Therefore, a Teamcenter requirement can exist as both an independent requirement and as an "owned" requirement. No corresponding structure is available in SysML, so the "owned" Teamcenter requirement is represented by a SysML requirement that is a <<copy>> of an independent requirement. In Figure 108, this relationship appears three times, for Engine Specification, Max Power, and Efficiency.
Figure 108 SysML model showing transferred requirements structure