Critical Metrics for Digital Threads, Part 2 – Tools

While this blog series focuses on the general concept of critical metrics for digital threads, we will illustrate these with actual examples. Commercial and open-source tools are available now to put these ideas into practice. For our example, we need a set of Data Sources, a Data Consumer to calculate and display the critical metrics, and a sample digital thread created using Syndeia. This blog post will introduce some key components, with links to more information.

Central to our example is Syndeia, the digital thread platform from Intercax. Syndeia can be considered an intermediary between your data sources, all the engineering model repositories you use, and your data consumers, the many interfaces your team needs to access, analyze and manipulate the data (Figure 1). At the core is Syndeia Cloud, a server-based component hosted by the customer in their servers or their own private cloud. It provides a common configuration-managed database for the inter-model connections that form the large-scale skeleton of the digital thread. It does not store the contents of the underlying repositories in its own database, but it can view the contents of those repositories, pull information out of them and make it part of our digital thread analysis.

A variety of clients communicate with Syndeia Cloud through the Syndeia Cloud REST API. We provide clients such as plugins for SysML modeling tools and a web dashboard, but our example will use direct calls to the REST API that users can incorporate into custom front-ends and dashboards with best-in-class data science, business analytics and visualization tools. This API is open and fully documented, with endpoints that support graph analysis of the Syndeia Cloud database and endpoints that extract detailed data from the underlying repositories when it is not available in the main graph.

To make these API calls and receive the results, we can use an open-source data science platform, Jupyter notebooks. With an interactive cell format, this provides an easy-to-use vehicle to test and debug queries. A wide variety of analysis and visualization libraries are available to process the data and create charts, lists and other figures to display the critical metrics on digital dashboards. Intercax provides the Syndeia Cloud API Cookbook with Syndeia, a series of Jupyter notebook examples for querying different repositories (see Syndeia API for Open Digital Thread, Parts 1 – 8). In Part 8 of this series, we will describe how to automate the execution of these notebooks and manage the results using DevOps tools such as GitHub Actions.

Figure 1 Syndeia architecture

Because many of the critical metrics are derived from graph queries, it is helpful to understand the data model for Syndeia Cloud. While the data model in each of the underlying repositories is different, each is mapped to a common model in the graph comprised of four basic elements: Artifacts, Relations, Containers and Repositories (Figure 2). While the majority of graph elements are artifacts and relations, understanding their types and organization allows more narrowly focused queries to be formulated (see blog series Data Science and the Digital Thread, Parts 1 – 5).

Figure 2 Syndeia Conceptual Data Model

For our example, the system modeled is the Unmanned Ground Vehicle we have used as a demonstration vehicle in other blog posts (see Requirements by Geometry, Parts 1-4), captured in a sample digital thread over approximately two weeks following the schema shown in Figure 3. The schema represents one possible set of inter-model relationships involving, in this example, six different Data Sources (model repositories). Requirements (Jama Connect/Jama Software) are satisfied by Architecture (Teamwork Cloud/CATIA No Magic), which are implemented in GitHub (GitHub, Inc.) and Windchill (PTC) and tested in TestRail (Gurock). JIRA (Atlassian) issues are used to track progress along each of the product component paths. There are also intra-model relations, e.g. from test cases to tests, that are part of the digital thread and may or may not be included in the critical metrics.

Figure 3 Sample Schema

In the next five posts in this blog series, we will discuss the digital thread metrics categories: complexity, activity, completion, consistency and verification, and provide examples of query results that provide insight into each category.  The final two parts describe an approach to automated execution and data management and some thoughts on future development in the area.

For more blogs in the series:

• Critical Metrics for Digital Threads, Part 1 
• Critical Metrics for Digital Threads, Part 2 (This Part)
• 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 
• Critical Metrics for Digital Threads, Part 7
• Critical Metrics for Digital Threads, Part 8 
• Critical Metrics for Digital Threads, Part 9

Tweet