In Part 1 of this series, we discussed applying some of the techniques of DevOps to the practice of MBSE and the particular importance of this during times of remote telework and social distancing when the usual formal and informal meetings are not occurring. In a distributed and asynchronous development environment, we need an ability to view the workflow as a whole, rather than as disconnected and uncoordinated tasks. In particular, a digital platform (or platforms) is required to deliver a variety of services:

• Connect data in different models
• Access data through those connections
• Transform data between modeling domains
• Store connection data in a configuration-managed repository
• Supply connection data for documentation, analysis and visualization
• Validate connected data in the system model for consistency and completeness
• Verify system performance through simulation, test and analysis
• Detect and publish changes in connected data
• Update connected data

In Parts 2a/b and 3, we demonstrated how Syndeia, the MBSE interoperability platform from Intercax, was able to create, store and visualize connection data to build the Digital Thread. In this final section, we will illustrate how graph analysis of the Digital Thread can validate connected data in the system model for consistency and completeness.

Dashboards

Figure 1 Syndeia Cloud dashboard system metrics

The web interface introduced for Syndeia Cloud in Release 3.3 opens with  bar charts describing the connection database contents. In Figure 1, we see the current contents broken down by the generic node and edge elements within the graph. The largest categories are artifacts, which include blocks, requirements, parts, files, issues and many other model elements across the range of connected models, and relations, the connections between them that define the model structure. A second bar chart breaks this down further by the repository types, i.e. tools, that are part of the Digital Thread. These views allow the project manager real-time monitoring of the progress of the development effort and its incorporation into the integrated workflow.

Completeness

During ongoing system development, project managers must monitor completeness, the extent to which model elements in different domains have been created and linked into the Digital Thread. From a graph analysis perspective, this means searching for a particular pattern required by the design environment rules. To achieve this, we can

• Compare partial pattern fragments relative to the complete pattern, or
• Search for patterns that explicitly violate the complete pattern.

Figure 2 Gremlin query – Jama requirement – SysML requirement, displayed as list of SysML requirements (partial)

As an example, we will again use our ventilator model and look at the pattern described in Figure 3 from Part 3 of this series, Jama requirement – SysML requirement – SysML activity – TestRail Testcase. In Figure 2, we display the results of a query for the pattern fragment Jama requirement – SysML requirement. In this example, we query specifically for all SysML requirements that are contained in matches to this pattern and display the results as a table.

This captures all instances of the Jama requirements which have been transfered to SysML by Syndeia model transform, independent of whether they have been further linked to test cases. By adding a count() command to the end of the query, we get a value of 20 instances of this pattern.

Figure 3 Gremlin query – Jama requirement – SysML requirement – SysML activity – TestRail Testcase, displayed as list of TestRail test cases (partial)

We compare this to a list of instances of the complete pattern, as shown in Figure 3. Here the count is 7 of the complete pattern.  Therefore, of the 20 requirements in our Digital Thread, only 7 have been fully completed in the allocation of SysML and TestRail verification test cases.

Figure 4 Gremlin query – Jama requirement – SysML requirement – SysML activity – NOT(TestRail Testcase), displayed as list of SysML activities

If we practice management-by-exception, we may prefer to generate a list of elements that are not complete. In Figure 4, our query looks for the pattern Jama requirement – SysML requirement – SysML activity – NOT(TestRail Testcase), patterns where a SysML activity has been allocated to the SysML requirement potentially as a test case placeholder, but a further link to TestRail has not yet been created. In this case, there are only two instances of this, activities where we may want to investigate further to see if the full test case in TestRail has not been created or, alternatively, exists but is not linked into the Digital Thread.

Consistency

A second important aspect of model validation is checking for consistency. Where the same data exists in different parts of the Digital Thread, do its values remain the same as the separate domain models evolve over time? When that data is shared by Syndeia model transforms, Syndeia provides mechanisms to compare and update the data. When the data is updated, Syndeia Cloud records that update, retaining both the old and new relationships within the graph database.

To illustrate how this might be used, we start by editing some of the original requirements in the Jama repository. Specifically, we edit the Description field in the Plateau Pressure requirement by reducing the maximum plateau pressure from 35 to 30 cm H₂O and the same field in Peak Pressure by increasing the peak-above-plateau from 2 to 5.  In our scenario, we assume that Jama Connect is the master requirements repository and that the changes have followed the organization’s standard procedure within that domain.

Figure 5 Syndeia difference table, Jama vs. SysML requirements under Inspiritory Airway Pressure (partial)

Now we have an inconsistency between Jama and the SysML requirements in our SysML Ventilator model.  Using the Syndeia dashboard from the SysML modeling tool plug-in, we periodically perform a comparison over a range of requirements and generate a difference table as shown in Figure 5.  The description/text field in the two modified requirements are highlighted as changed, as well as the fact that new versions of the Jama requirements are available in the Jama configuration-managed repository.

Through the same Syndeia dashboard, we request an update across the connections from Jama to SysML.  This updates the text field in the SysML requirements and creates a connection from the SysML requirement to the new version of the Jama requirement. This new connection is pushed to Syndeia Cloud, but the original connection is not deleted from the graph database. A property (_isLatest) in the metadata associated with the original connection is changed from TRUE to FALSE.

Figure 6 Gremlin query – Jama requirement – SysML requirement, _isLatest = FALSE

In Figure 6, we have used a Gremlin query to show SysML-Jama intermodel connections where the connection has been updated since creation, that is, an older connection with _isLatest = FALSE exists within the graph. In combination, Figure 5 and Figure 6 show that an inconsistency was detected for two connections and that it was resolved by updating the connection. Because the connection metadata in Syndeia Cloud includes creation and update timestamps, these analyses can be narrowed to particular timepoints or intervals to track the processes more finely (such comparative queries have not been implemented in the Tinkerpop standard used in Syndeia Release 3.3, but will be available in future releases).

Using these Syndeia capabilities, detection and resolution of Digital Thread inconsistencies can become a rapid, systematic part of system development, done real-time at frequent intervals with minimum human effort.

Future Directions

In our discussion of systems engineering in a time of social distancing, we have looked at the intersection of integrated MBSE with DevOps practices, focusing on three objectives:

• The individual team members need to be able to share their work and find the information they need in other domains, even when working in a distributed and asynchronous environment.
• The project managers need to have a holistic, real-time view of the entire system development in that same environment.
• Whenever possible, the workflow should be facilitated by automation to overcome the greater difficulties in close collaboration and coordination.

In this series, we have not discussed this last area in depth. Rather than an application with a limited set of commands and reports, Syndeia is evolving into a set of microservices that expose the capabilities we have demonstrated through a RESTful API with well-documented endpoints. Customers can apply third-party automation and documentation platforms, e.g. Jenkins, OpenMBEE, Tom Sawyer, to support their workflow and reporting requirements.

We all look forward to the return of more “normal” times, particularly with regard to the safety of our family, friends and co-workers, but we also understand this period has only highlighted the need for systems engineering to break down the barriers between disciplines and organizations, close or distant. Developing both the technology and culture to make this possible will continue to be one of our highest priorities.

Related posts:

• Systems Engineering in a Time of Social Distancing | Part 1
• Systems Engineering in a Time of Social Distancing | Part 2a
• Systems Engineering in a Time of Social Distancing | Part 2b
• Systems Engineering in a Time of Social Distancing | Part 3
• Systems Engineering in a Time of Social Distancing | Part 4 (this post)