The digital thread is dynamic. Many of the federated data repositories are configuration-managed, and it is critical for the inter-model connections to be version-sensitive. Consistency of a digital thread implies that the version of a connected data element is the same now as when the connections to it were created or most recently updated. If a connection is not consistent or “out-of-sync,” the potential exists that an engineer working in one domain may have an outdated and erroneous understanding of relevant information in another domain. As such, the number or proportion of out-of-sync connections is a direct metric of the current risk in the project and indirectly a measure of the time (schedule) and effort (cost) required to resolve the inconsistency.

Figure 1 Schema for Digital Thread Project UGV02

The schema for our digital thread example (Figure 1) has been shared before. Most of the individual data repositories are explicitly configuration-managed; JIRA is a special case that will be discussed later. A connection may be inconsistent if either ends have been changed or deleted. It is generally important to know which end has been updated. For example, a system architect working in Teamwork Cloud may be more concerned with a change in a linked Jama requirement than the requirement engineer is with a change in the system architecture.

Remembering that each repository may contain versioned and non-versioned data elements is also important. For example, in PTC Windchill PLM, we can track both Part Master, the version-independent component in an assembly, and the Part, a particular version of that component. Syndeia, in many cases, may allow you to connect to either. Syndeia stores metadata about the ends of each inter-model connection, distinguishing between the External Key, version-independent identifier, and the External ID, version-specific identifier. If a link in the digital thread is created to a version-independent element, the link is automatically updated to the latest version of that element when you navigate to that element. However, this may be a drawback because you cannot detect when that element changes.

Figure 2 Out-of-Sync Connections ending in Jama Requirements in Digital Thread Project UGV02 (the URL of the Jama repository has been partially obscured for security)

Figure 2 shows a pie chart and table describing consistency with respect to the inter-model connections to the Jama repository contained in the Syndeia project UGV02. There are 54 inter-model relations ending on Jama elements; this is determined from a single graph query to the Syndeia Cloud database and does not distinguish between incoming and outgoing directions. This query returns a list of connections, including the Jama requirement Key and Version for the connected Jama element. For each item on that list, a separate query is made via the Syndeia Cloud REST API to the Jama repository based on the requirement Key, asking for the latest Version with that Key. If the latest version is not the same as the version associated with the connection, then that connection is considered Out of Sync. If versions match, the connection is In Sync. The results are plotted as a pie chart, and an Out of Sync connections table is displayed.

Figure 3 Out-of-Sync Connections ending in JIRA Issues in Digital Thread Project UGV02

Figure 3 offers a similar analysis for inter-model relations ending in a JIRA issue. Unlike Jama, Teamwork Cloud, and some of the other repositories, JIRA is not explicitly configuration-managed. Still, Syndeia

uses the timestamp on the JIRA issue at the time the connection was created and the timestamp of the latest modification of the issue for comparison. In this project, 9 out of 100 relations are Out of Sync.

While these examples demonstrate how consistency information may be derived for the digital thread, there are alternate (and possibly more useful) ways in which the information might be presented. A single pie chart showing all inter-model connections in a project and the percentage Out of Sync could be generated by executing the analysis in Figures 2 and 3 for all repositories and accounting for each connection having two ends. On the other hand, a particular domain engineer might wish to query all connections beginning in her domain repository for changes at the far end, whatever the repository. A report could be generated periodically. If Out of Sync, such connections should be navigated and the change at the far end evaluated for impact on her domain. Syndeia can facilitate such investigations.

Automatic updating of the connections to point to the latest version of the connected elements can be done easily, either by creating the connection initially to the version-independent Key of the element or by periodically performing the kinds of analyses shown and using Syndeia to update the connections individually. However, this may not be desirable. An Out of Sync connection is evidence of change in a related system element and it may require human engineering judgement to evaluate the impact before consistency is restored.

In our examples, we have only determined consistency by comparison of versions, which is sometimes referred to as currency. Consistency could also be based on comparison of shared attribute values of the connected elements where there are shared attribute values.  This is a common situation in Syndeia-created digital threads where inter-model connections are created by model transformation from one domain to another. Comparisons can also look for orphaned connections, where a connected element in one repository is completely deleted rather than updated.

In Part 7, we address Verification. Unlike Consistency, which looks at the internal validity of the model, Verification matches model requirements against system performance, whether determined by simulation, test, observation or other means.

For more blogs in the series:

• Critical Metrics for Digital Threads, Part 1
• Critical Metrics for Digital Threads, Part 2
• Critical Metrics for Digital Threads, Part 3
• Critical Metrics for Digital Threads, Part 4
• Critical Metrics for Digital Threads, Part 5 
• Critical Metrics for Digital Threads, Part 6 (This Part)
• Critical Metrics for Digital Threads, Part 7
• Critical Metrics for Digital Threads, Part 8
• Critical Metrics for Digital Threads, Part 9