Syndeia has been developed as an API-first enterprise application, i.e. the full capabilities of the software are exposed through an open REST API with the understanding that the users will develop custom user experiences in addition to those provided by Intercax. In that way, the wide range of stakeholder information needs can be met without waiting for vendor releases. The best open source and commercial platforms for data science, business analytics, and visualization can be applied to the data available to Syndeia.
Figure 1 Syndeia Architecture with Multiple Vendor-provided and User-provided Data Consumers
The previous blog posts in this series have focused on the Intercax-provided UIs, the plug-in and web browser clients shown on the left side of the Data Consumers row in Figure 1. This post and the following ones will demonstrate custom UIs that call the Syndeia Cloud REST API directly. Syndeia licensees have full access to the API with Swagger documentation and data models, including endpoints directed to the Syndeia Cloud graph database layer and to the underlying data sources via Syndeia Cloud.
Figure 2 Project Metrics are related to digital thread queries via intermediary thread metrics
Project and program managers are key beneficiaries of digital thread technology through the ability to monitor project status in near real-time. This implies bridging the concerns of management, typically related to cost, schedule and risk against plan, and the specific queries available through the digital thread platform, such as how many requirements are linked to test cases. One way to bridge the gap is to consider intermediate metrics applicable to the digital thread (or really any digital model) as a whole: complexity, activity, completeness, consistency and verification. Figure 2 shows how we might think about these relationships decomposing the Project Metrics (high level concerns) through Thread Metrics (intermediate level) to individual thread queries.
This in turn implies the need to create custom reports specific to the project, the software tools involved, and the information needs of the project manager. Syndeia’s API allows the easy generation of custom scripts for this purpose. Jupyter notebooks, a widely used open source data science platform, allows these scripts to be written using the Syndeia Python or Java API toolkits and easily organized and validated. Syndeia licenses include a set of sample notebooks (the “API Cookbook”) to provide guidance for users to develop their own.
Figure 3 Cell from Jupyter notebook ”Syndeia_3.6_Jama_SysML_AutoVeh_Rev01.ipynb” identifying Jama requirements that have changed since linkage into the AVDZ01 digital thread project
Figure 3 shows one cell from a Jupyter notebook designed to measure project metrics for one set of relations in the Autonomous Vehicle digital thread project from Jama requirements to the equivalent requirements in Cameo. It compares the version of the Jama requirement that was linked in as part of the project to the current version of that same requirement in the Jama repository. At the bottom, it lists two requirements where the version is not the same, i.e. the Jama requirement has changed since the digital thread link to it was created. This is a measure related to the Consistency metric for the project, since it indicates a potential inconsistency between the Jama and SysML requirements that should be further investigated by a project engineer, an inconsistency that could lead to a verification error farther down the line.
Figure 4 Final Metrics Calculation for the Jama-SysML Connections in the Autonomous Vehicle Project
Figure 4 shows the final two cells of the Jupyter notebook. The first summarizes four key Thread Query results, e.g. the number of Jama requirements linked into the digital thread vs. the number of relevant requirements in the Jama repository. The second calculates and displays four Thread Metrics from these numbers.
This script calculates metrics for only a single type of inter-model connection, but it is relatively simple to duplicate these functions for all nine types in this digital thread project. However, the resulting report takes several minutes to run, making it less convenient for on-demand use. In the next blog post in this series, we will show how the same code, with minimal changes, can be moved from the Jupyter notebook (where it is easy to test and validate) to a Syndeia digital pipeline, where it can be run on a regular schedule (e.g. every morning at 7 am) and the results saved for retrieval. Future posts will focus on custom dashboards where, again, the same Python code can be re-used for new purposes.
Gregory Seeds, Senior Software Engineer at Intercax, is primarily responsible for the Jupyter notebook example.
In the following blog posts in this series, we will offer a few glimpses of the future
Missed the earlier parts? Check them out here.
To evaluate Syndeia with your own toolset, or just to discuss your requirements and use cases, send your questions and requests to www.intercax.com/help and let us help you adopt best practices in Digital Engineering.