The Connection Manager tab in the Syndeia Dashboard provides an easy-to-use, drag-n-drop interface for creating connections between SysML model elements and repository elements, and generating SysML models from repository models, and vice versa. 

The Connection Manager tab has four elements, as shown in Figure 61.

1. The System Model Panel, which displays the SysML element from which the Syndeia Dashboard was launched, and its sub-elements. To select a different element, such as a different package, right click on any SysML element in the System Model Panel and select Go to.
2. The Connection Type Panel, which displays the available connection types.
3. The Repository Panel, which displays the repository to which connections can be made. The repository shown can be changed by clicking on the panel title bar.
4. The Message Panel at the bottom, which displays status and error messages during operation.

Users can swap repositories by clicking on the title bar of the Repository Panel and selecting a different repository (Figure 61) that has already been added using the Repository Manager (section 4.3.1).

The normal operation of the Connection Manager involves the following main steps:

1. Select a type of connection in the Connection Panel (middle)
2. Drag and drop a SysML element to a repository element, or vice versa, to create a connection, or generate a model (which also creates connections).

The four main types of connection supported by this version of Syndeia are as follows:

1. Reference Connection – This is the most basic type of connection between a SysML model element and a repository element. It establishes a traceability link between the two elements.
2. Function Wrap Connection – This type of connection is used to wrap an external executable model (or code) with a SysML model element, such that when the SysML model element is executed, Syndeia can invoke the external model and bring back execution results to the SysML model for verification. For example, connections between SysML constraint blocks and external MATAB or Mathematica scripts and functions fall into this category.
3. Data Map Connection – This type of connection is used to map the attributes/properties of a SysML model element with those of a repository element such that Syndeia can compare and bi-directionally sync the property values on-demand. For example, the connection between the value properties of a SysML block and the cells (or entries) in an Excel table row (or MySQL table row) are of this type.
4. Model Transform Connection – This type of connection is used to map the structure of a SysML model element with that of a repository element such that Syndeia can compare and bi-directionally sync the structure on-demand. For example, the connection between a SysML block to a Windchill / Teamcenter part is an example of this type. The compare operation can show the differences in the structures by comparing the part properties of the SysML block with part BOM in Windchill / Teamcenter, and the bi-directional sync operations can be used to update the part properties of the SysML block or part BOM in Windchill / Teamcenter.

Each connection type has a specific purpose. Syndeia users must decide the purpose of connecting / integrating the SysML model elements with the repository elements, and then pick up a connection type that serves their needs. For guidance, refer to the tutorials in the Tutorials document. Not all types of connections are supported for all types of SysML model elements and repository elements. The tables in sections 4.5.1- 4.5.6 show the specific connection types that are supported for elements in each repository and the drag-n-drop operations to achieve the same. The Syndeia Tutorials provide step-by-step guide for these operations.

Additional Notes for Rhapsody

Rhapsody: Rhapsody 8.0.x does not allow SysML elements with spaces in names by default. Users should modify a property in their project to allow spaces in names on model elements. See the following link from the IBM website on how to do this: http://goo.gl/cvhBSk (short link). Users are requested to change this setting since it may cause issues in generating SysML model elements from other repositories (such as Windchill, Teamcenter, and MySQL) that allow for spaces in model element names.

Drag-n-drop operations for Creo

See the Creo section in the table in section 4.5.5. To learn more, refer to the Syndeia Tutorials document (section 3.2).

Drag-n-drop operations for DOORS-NG Repositories

In DOORS-NG, requirement and requirement collection are the base resource types. Different types of artifacts are defined in a DOORS-NG project based on these basic resource types. For example, System Requirement, Hardware Requirement, and Software Requirement may be three artifact types which have the same base type as requirement. When generating requirements or collections in DOORS-NG from SysML (operations D2 and D3 in the table above), you can set the specific type of artifact that needs to be generated in DOORS-NG, e.g. generate a System Requirement versus a basic requirement in DOORS-NG. Follow the steps below to do this:

1. Go to Syndeia > Utils > DOORS-NG Utils menu by right clicking on any SysML element in the model tree. This will launch the DOORS-NG Utils window as shown below. Select your DOORS-NG repository, project, resource type, and press OK. Syndeia will query the DOORS-NG server and output all artifact types available for the given resource type in the specified DOORS-NG project.

   Figure 63: Query available artifact types in a DOORS-NG project for requirement or requirement collection resource

2. For a given SysML requirement, apply the DOORS-NG module, requirement collection, or requirement stereotype, and set the value of the _artifact_type tag to one of the artifact type values obtained in the previous step, as shown below.

Drag-n-drop operations for JIRA Repositories

Syndeia also provides the ability to view the status of a project in JIRA, directly from the SysML model. If you have SysML elements connected to JIRA issues (any connection type), then you can right click at the SysML project or package level in the SysML model tree and select Syndeia > Summarize Connected Artifacts. This will launch the JIRA Connected Issues Summary window, as shown in Figure 65. The top part of the table shows a list of all JIRA issues that are connected to SysML elements (recursively) in the package. The bottom part of the table shows overall issue analytics, such as total number of connected issues, number of open issues, number of issues reported by a user, or the number of issues assigned to a user. This can be very useful in tracking the status of a project in JIRA directly from the SysML model.

Drag-n-drop operations for GitHub Repositories

Drag-n-drop operations for Local File System Repositories

This section presents a summary of drag-and-drop operations for models managed in local file system repositories. To learn more, refer to the step-by-step instructions for each model type in the Syndeia Tutorials document (see section 3.2 for details).

Creating connections between existing model elements

The drag-n-drop operations listed in the table above generate models. Starting with this release, Syndeia can also create model transform and data map connections between existing model elements without generation. You can then perform a compare and sync operation on these connections to sync the models. The following drag-n-drop operations are available between existing model elements:

• SysML Block < – > Excel table (Model Transform)
• SysML Block < – > Excel table row (Data Map)
• SysML Block Instance < – > Excel table row (Data Map)
• SysML Block < – > NX CAD model (Model Transform)
• SysML Block < – > Creo model (Model Transform)
• SysML Block < – > Simulink model (Model Transform)
• SysML Activity < – > Simulink model (Model Transform)

Additional Notes on SysML and Excel drag-n-drop operations

1. Column names in the Excel table (header row) must be alpha numeric (white spaces and underscores are allowed) so that they can be used to generate block value properties.

2. When generating SysML block / instances from Excel data, or when synchronizing Excel > SysML, the following data mapping rules are followed.
   
   

   Excel data type	SysML value type
   String	String
   Numeric	Real
   Boolean	Boolean

3. When generating Excel tables and rows from SysML elements, or when synchronizing SysML > Excel, the following data mapping rules are followed.
   
   

   Note: Excel does not distinguish between integers and real numbers, so they are both mapped to Numeric type. 

   SysML value type	Excel data type
   String value type	String
   Real value type	Numeric
   Integer value type	Numeric
   Boolean	Boolean

4. Ensure that the Excel file is closed before any drag-n-drop or sync operations from SysML to Excel. If not, the information will not be written to Excel.
5. Rhapsody stores the default values of values properties of a block as a String object, even if the value is a number, and hence when the value is written to an Excel table row, it is written as a String and not a Numeric object.
6. The Syndeia profile for Rhapsody provides the following additional value types—String, Integer, and Boolean. These value types are not available with the default SysML profile in Rhapsody.

Drag-n-drop operations for MySQL Repositories

This section presents a summary of drag-and-drop operations for models managed in MySQL repository. Refer to the step-by-step instructions in the Syndeia Tutorials document (see section 3.2 for details).

Creating connections between existing model elements
The drag-n-drop operations listed in the table above generate models. Starting with this release, Syndeia can also create model transform connections between existing model elements without generation. You can then perform a compare and sync operation on these connections to sync the models. The following drag-n-drop operations are available between existing model elements:

• SysML Block < – > MySQL Table (Model Transform)
• SysML Block < – > MySQL Table Row (Data Map)
• SysML Block Instance < – > MySQL Table Row (Data Map)

Additional Notes on SysML and MySQL drag-n-drop operations

1. Column names in the MySQL table must be alpha numeric (white spaces and underscores are allowed) so that they can be used to generate block value properties.

2. When generating SysML block / instances from MySQL data, or when synchronizing MySQL > SysML, the following data mapping rules are followed.
   
   

   MySQL data type	SysML value type
   int / INT	Integer
   dec / DEC	Real
   float / FLOAT	Real
   double / DOUBLE	Real
   char / CHAR	String
   varchar / VARCHAR	String

3. When generating MySQL tables and rows from SysML elements, or when synchronizing SysML > MySQL, the following data mapping rules are followed.

Drag-n-drop operations for NX

See the NX section in the table in section 4.5.5. To learn more, refer to the Syndeia Tutorials document (section 3.2).

Drag-n-drop operations for Simulink

See the Simulink section in the table in section 4.5.5. To learn more, refer to the Syndeia Tutorials document (section 3.2). Additional notes related to Syndeia – Simulink connection are provided below.

Defining a Simulink Library Block in SysML

Follow the general rules below to define a Simulink library block in SysML.

1. Create a SysML block or activity, and assign it the Simulink_Library_Block stereotype available in the Syndeia profile
2. Add a value property (for SysML blocks) or property (for SysML activities) called name and typed by the String value type. The default value of this property must be the exact name of the Simulink library block in the Simulink library. Activity models in Rhapsody are not allowed to have properties. Use local tags instead.
3. Similarly, you may add other properties as required when using the Simulink library blocks, e.g. Add block uses a property Input with value ++ to indicate addition of two input arguments.
4. Define flow with primitive value types (Real, Integer, Boolean) to represent the inputs and output of a Simulink library block.
5. The input and output ports must be numbered in ascending alphanumeric manner, ending with numbers 1, 2, 3, and so on. For example, input ports on a Simulink library block must be named in1, in2, in3, etc. and output ports on a Simulink library block must be named out1, out2, out3, etc.

Rules and Limitations

Syndeia's SysML-Simulink capabilities have the following rules and limitations. Several of these are due to inherent modeling restrictions in Simulink.

1. SysML port types – Syndeia supports full, proxy, and flow ports in SysML. Full ports must be typed by a block with one or more flow properties. Proxy ports must be typed by a block with one or more flow properties. Flow ports must be typed by a value type or a flow specification with one or more flow properties.
2. Direction – The following rules are used to determine the direction of information flow in SysML for generating ports and signals in Simulink.
   1. If the direction of a port / activity parameter node (APN) / pin is IN or OUT, then that direction will be used. If the direction of the flow properties typing that port / APN / pin contradicts the direction of the port / APN / pin, Syndeia will show a warning message in the log window.
   2. If the direction of a port / APN / pin is INOUT or not specified/null, Syndeia will use the flow property direction(s). If port / APN / pin direction is INOUT, Syndeia will show a warning.
   3. If the flow properties are null / mixed directions / INOUT in the case of item 2 above, Syndeia will show a warning AND ignore the port / APN / pin.
3. Value typed for ports and flow properties - The flow properties in blocks, interface blocks, or flow specifications typing full, proxy, and flow ports respectively may be typed by Real, Integer, and Boolean value types which map to double, int32, and boolean types respectively in Simulink. The same is true for value types used for atomic flow ports.
4. Activity parameter node types – Activity parameter nodes must either be typed by Real, Integer, or Boolean value types (as for ports), or blocks with one or more flow properties that are typed by these value types.
5. Assign name and type - All ports and activity parameter nodes must have a name and type. Part properties and call behavior actions must have a name and type.
6. Avoid spaces in names - SysML model elements with spaces in names are not recommended since Simulink does not allow them. However, Syndeia substitutes spaces in names with an underscore when generating Simulink models. Name uniqueness may be violated if two elements are named the same except where one has an underscore and the other has a space, i.e. "Bus 1" and "Bus_1"
7. Simulink Library block caveats – For SysML blocks and activities that are assigned the Simulink_Library_Block stereotype, ensure that the value properties, properties, or tags do not have white spaces in their names. Any model elements referenced in these properties should also not have names with white spaces. Users must verify the names and values of properties/tags corresponding to Simulink library blocks before attempting to generate in Simulink.
8. SysML activity models - Parameters must agree with the corresponding activity parameter nodes in name and type. Input/output pins must agree with corresponding activity parameter nodes in name and type.

Drag-n-drop operations for Teamcenter (TC) Repositories

This section presents a summary of drag-and-drop operations for models managed in Windchill repository. Refer to the step-by-step instructions for each model type at the following locations:

• Teamcenter items/parts- Refer to the Syndeia Tutorials document (see section 3.2 for details).
• Teamcenter requirements and attributes - Refer to the Syndeia Tutorials document (see section 3.2 for details).
• NX – Refer to section 4.3.2.7 on viewing NX models in Teamcenter, and section 4.5.5 for drag-n-drop details

Creating connections between existing model elements (new)

The drag-n-drop operations listed in the table above generate models. Starting with this release, Syndeia can also create model transform connections between existing model elements without generation. You can then perform a compare and sync operation on these connections to sync the models. The following drag-n-drop operations are available between existing model elements:

• SysML Block < – > Teamcenter Item Revision (Model Transform)
• SysML Block < – > Teamcenter Part Revisions (Model Transform)
• SysML Requirement < – > Teamcenter Requirement Revision (Model Transform)
• SysML Requirement < – > Teamcenter Requirement Spec Revision (Model Transform)
• SysML Requirement < – > Teamcenter Paragraph Revision (Model Transform)

Managing Teamcenter attributes (new)

Syndeia makes it possible for system engineers working with SysML to get, compare, sync, and populate attributes on Teamcenter requirements, requirement specs, and paragraphs from/to requirements in the SysML model. This capability will be extended to Teamcenter items / item revisions in general in the next release of Syndeia. The following sections present details of the new capability.
The Syndeia Profile provides stereotypes for Teamcenter requirement, requirement spec, and paragraph that can be used to control the specific attributes for these Teamcenter items that will be obtained from Teamcenter, or populated in Teamcenter, or compared/synchronized between SysML and Teamcenter. Figure 66 show the Teamcenter-specific stereotypes in the Syndeia profile for Rhapsody

The specific attributes of a Teamcenter requirement, requirement spec, or paragraph that Syndeia will get/populate/compare/sync are listed under the corresponding stereotypes and start with the prefix ro_ (indicating read-only attributes) or rw_ (read-write attributes). The stereotype tag names follow the convention: ro_<attribute_name> or rw_<attribute_name> where <attribute_name> is the internal name of the attribute in Teamcenter, as obtained from using BMIDE—Teamcenter's schema modeling environment. For example, the attributes of interest for Teamcenter requirement revisions (TC_Requirement_Revision) for Rhapsody are current_id, owning_user, body_text, and object_desc, as shown in Figure 66.

Attributes with the prefix ro_ are read-only attributes. This implies that their values can be obtained from Teamcenter when generating SysML model elements or synchronizing from Teamcenter -> SysML. Attributes with the prefix rw_ are read-write attributes. This implies that their values can be read from Teamcenter when generating SysML model elements or synchronizing from Teamcenter -> SysML, and their values can be populated in Teamcenter when generating Teamcenter model items or synchronizing SysML -> Teamcenter.

Users can add more or remove existing ro_ and rw_ tags corresponding to Teamcenter requirement-related attributes in any of the three Teamcenter stereotypes in the Syndeia profile. However, if every user in an organization / group selects a different set of Teamcenter attributes and adds tags to the stereotypes, it will result in issues when sharing models among the group members. Also, all users should not be modifying the Syndeia profile. It is highly recommended that the lead modeler (system engineer) in a group/organization updates the Syndeia profile with all the Teamcenter attributes that are relevant for that group/organization. He/She should then make the profile available to all users who can add the profile to their models but not modify it.

Teamcenter requirement / requirement spec / paragraph -> SysML

When a user drags a Teamcenter requirement, requirement spec, or paragraph from the Teamcenter repository to the SysML model in the Connection Manager of the Syndeia Dashboard, Syndeia dynamically looks up the ro_ and rw_ tags in Teamcenter requirement-related stereotypes in the Syndeia profile to collect the specific Teamcenter requirement / requirement spec / paragraph attributes whose values will be brought over to SysML. Teamcenter attribute values will be set as values of the ro_ and rw_ tags on the corresponding SysML requirements.

SysML requirement -> Teamcenter requirement / requirement spec / paragraph

When a user drags a SysML requirement to Teamcenter in the Connection Manager of the Syndeia Dashboard, Syndeia dynamically looks up the rw_ tags in Teamcenter requirement-related stereotypes in the Syndeia profile and their values in the SysML requirement, and then sets those attributes values when generating Teamcenter requirement / requirement spec / paragraph items in Teamcenter. Once the Teamcenter items have been created, Syndeia gets values of their attributes (identified using the ro_ tags) and sets them in the SysML requirements.
Further, users can also create special types of Teamcenter requirements / specs / paragraphs by modifying the values of _item_type and _object_type tag values in the Teamcenter requirement-related stereotypes. The _item_type tag is set to the type of Teamcenter item (as defined using BMIDE) and the _object_type tag is set to the type of the corresponding Teamcenter item revision (as defined using BMIDE). By default, these are set to the base types of Teamcenter requirement / spec / paragraphs, e.g. Requirement and Requirement Revision for basic Teamcenter requirements. However, if an organization has defined special types of requirements using BMIDE, e.g. Business Requirement and Business Requirement Revision, then these values can be set in the _item_type and _object_type tag values in the Teamcenter requirement-related stereotypes. Next time, when a user attempts to generate a Teamcenter requirement from a SysML requirement, Syndeia will generate a Business Requirement and not the base Requirement in Teamcenter.

SysML requirement <-> Teamcenter requirement/requirement spec/paragraph

When a user invokes compare/sync operations on Syndeia connections between SysML requirements and Teamcenter requirements / requirement specs / paragraphs, Syndeia also performs a compare and sync on requirement-related attributes. It dynamically looks up the ro_ and rw_ tags on Teamcenter requirement-related stereotypes in the Syndeia profile and compares/syncs their values between the source end (SysML requirement) and target end (Teamcenter requirement / spec / paragraph) for each connection. For SysML -> Teamcenter sync, the values of rw_ tags are used to update the Teamcenter items. For Teamcenter -> SysML sync, the values of both ro_ and rw_ tags are used to update the SysML requirements.

Drag-n-drop operations for Windchill (WC) Repositories

This section presents a summary of drag-and-drop operations for models managed in Windchill repository. In addition, it provides step-by-step instructions for managing Windchill attributes. Refer to the step-by-step instructions for each model type at the following locations:

• Windchill partsand attributes (new) - Refer to the Syndeia Tutorials document (see section 3.2 for details) and this section (especially for Windchill attributes).
• Creo models (new) – Refer to section 4.3.2.6 on viewing Creo models in Windchill, and and section 4.5.5 for drag-n-drop details.

Creating connections between existing model elements

The drag-n-drop operations listed in the table above generate models. Starting with this release, Syndeia can also create model transform connections between existing model elements without generation. You can then perform a compare and sync operation on these connections to sync the models. The following drag-n-drop operations are available between existing model elements:

• SysML Block < – > Windchill Part Version (Model Transform)
• SysML Block < – > Creo model (Model Transform)

Managing Windchill Attributes

Syndeia makes it possible for system engineers working with SysML to get, compare, sync, and populate attributes on Windchill parts to/from the SysML model. The following sections present details of the new capabilities.
Get attributes of Windchill parts to the SysML model
In the Syndeia Dashboard, when you drag a Windchill part version (or part master) to a SysML package to generate SysML block structure from Windchill part structure, Syndeia brings up the Select Part Attributes window, as shown in Figure 67 below. Select the specific attributes you need and click OK.

This will generate a SysML blocks structure from the Windchill part structure. The part attributes will be generated as value properties on the SysML blocks. The values of Windchill part attributes will be set as default values of the SysML block value properties, as shown in Figure 68 below. The units on Windchill part attributes are also brought over where applicable. The values and units are brought together as a String in the SysML model. This is primarily because Windchill 's web services provides those values as a string with a value and unit together.

Syndeia applies the WC_Part_Attribute stereotype (from the Syndeia Profile) to every value property generated for Windchill part attributes (Figure 69), and sets the _windchill_name tag from the stereotype to the internal name of the Windchill part attribute (Figure 70).

Users can change the name of the block value properties once they are generated from the Windchill part attributes. The internal name set on the value property will make it possible for Syndeia to correlate them with Windchill part attributes during compare/sync operations. This approach also makes it possible for users to add new value properties to the SysML blocks connected to Windchill parts. If the _windchill_name tag is not populated on these value properties, then they will be ignored during compare/sync operations. 

Create parts in Windchill with attribute values from the SysML model
Syndeia also makes it possible for system engineers using SysML to define blocks with value properties and set their values such that when SysML blocks are used for generating Windchill parts, the block value properties can be used to populate corresponding Windchill part attributes. This is especially useful when enterprise Windchill repositories are customized with business rules that mandate certain attributes be populated when creating parts. In those cases, SysML blocks with mandatory value properties can be setup before generating Windchill parts. Syndeia makes it possible to set the mandatory attributes on Windchill parts at the time of part creation. In addition, users can also create different types of Windchill parts by setting the custom part type on the SysML block. This is a very powerful feature of Syndeia. Follow the instructions below to learn about this feature.

1. Right click on any SysML model element and select Syndeia > Utils > Windchill Utils.

   Figure 71: Launch Windchill utils

2. This will launch the Windchill Utils window. Select your Windchill repository, select the base type as Windchill part, and click OK. It may take a few seconds for the results to appear in the window, as shown in Figure 72 below.

The base type of parts in out-of-the-box Windchill PLM system is WTPart. Organizations can develop their extensions of the base type and also add new attributes to those types. The result window above lists the base part type and all its extensions, and lists the attributes (out-of-the-box and custom) for each type. For example, it shows a custom part type (LPart), specifically WCTYPE|wt.part.WTPart|com.intercax.IPart|com.intercax.ipart.LPart that has an attribute with display name Bounding box size which you can see in the Windchill browser client, and internal name com.intercax.lpart.boundingBoxSize which is used for getting and setting its values programmatically. 

The part type and attribute results show the data dictionary for Windchill parts. This information will be used for generating custom Windchill parts and setting their attributes from SysML blocks in the following steps.

1. Create a SysML block (e.g. My New Part) in your SysML model.
   
   
   

   Follow the remainder of the instructions in this step only if you want to set the part number for the Windchill part to be generated, or if you want to create a Windchill part of a specific type that is defined by your organization and which is not the base type (WTPart) defined out-of-the-box with PTC Windchill installation. If you don't follow the remainder of the instructions in this step, then a Windchill part of the base type (WTPart) will be generated and a part number will be automatically assigned by Windchill. 
   Apply the Windchill_Part stereotype, available from the Syndeia Profile, to the SysML block (Figure 73). Set the _part_number tag value to your desired value, and set the _part_type tag value to the type for the custom Windchill part (Figure 72) you want to create, e.g. WCTYPE|wt.part.WTPart|com.intercax.IPart|com.intercax.ipart.LPart, as shown in Figure 74.

   Figure 73: Apply the WC_Part stereotype

   Figure 74: Set the _part_number and _part_type tag values

2. If you want to set one or more Windchill part attributes when generating a Windchill part, especially if these attributes are mandatory attributes, create a value property with a name of your choice typed by String value type in the SysML block for each of those attributes. For example, create 2 value properties (typed by String value type) in the SysML block created in the previous step for each of the 2 Windchill part attributes you want to set. For Rhapsody, use the String value type in the ValueTypes package under the Syndeia Profile.
3. Set the default values of the value properties. This should be in the exact format as the default values set when SysML blocks and value properties are generated from Windchill parts (Figure 68 and Figure 69). For example, set the value of estimated mass as 45 kg (Figure 75).

4. Apply the WC_Part_Attribute stereotype available from the Syndeia Profile to each of the value properties (Figure 75). Set the _windchill_name tag to the internal name of the Windchill attribute, e.g. com.intecax.lpart.mass.estimated (Figure 76). Look up the results in step 2 (Figure 72) to get the internal names of Windchill attributes.

   Figure 75: Apply the WC_Part_Attribute stereotype to the value property

   Figure 76: Set the _windchill_name tag for the value property

5. Drag and drop the SysML block to a Windchill product or folder in the Connection Manager tab of the Syndeia Dashboard. This will generate a new Windchill part from the SysML block, as shown for the My New Part in the Windchill client (web browser) in Figure 77. Note that the name of the Windchill part is the same as SysML block name, the type of the Windchill part is LPart (as set in the stereotype tag), the part number of the Windchill part is MY NEW PART 1 (as set in the stereotype tag), and the value of estimated mass attribute is 45 kg (as set in the stereotype tag).

Compare/Sync SysML block structure with value properties with Windchill part structure with attributes
When a user invokes compare/sync operations on Syndeia connections between SysML blocks and Windchill parts, the Windchill-specific value properties of the SysML blocks and the attributes of the connected Windchill parts are also compared / synchronized. For example, Figure 78 shows the compare results for a Syndeia connection between a SysML block and a Windchill part. It shows that the value property Mass (estimated) in the SysML block is out-of-sync with the corresponding attribute on the Windchill part.