Model-Based Systems Engineering for Autonomous Vehicles | Part 10

In Parts 5 – 9 of this blog series, we have built an expanded model of an autonomous vehicle while demonstrating how a federation of models in different software tools can become a unified specification of the system. Figure 1 shows the types of model elements and the types of connections that Syndeia has used to weave the Total System Model (TSM).

Figure 1 Total System Model architecture supported by Syndeia

The expanding set of connected models increases the options for users working in one domain to access or share information in another. However, the larger size also means greater challenges in finding the information each user needs quickly and efficiently. The power of modern graph database technology provides an approach to meeting these challenges.

Figure 2 Query on Neo4j Graph database, “Show all DOORS specifications connected to TestRail Test Cases”

Earlier (in Part 4, January 2018), we described a flexible approach that has Syndeia collecting all connectors, both intra-model (SysML) and inter-model, in a Neo4j database and using a standard query language, Cypher, to ask detailed questions of the TSM. In this post, we will show some additional examples of such pattern-matching queries applied to our new larger model (438 nodes, 481 edges). In Figure 2, the query asks for all DOORS NG requirements that are verified by TestRail test cases. Three requirements (purple circles) are linked to four test cases (blue circles). A very similar query identifies those technical requirements where not test case is assigned.

Figure 3 Query on Neo4j Graph database, “Show all Jama Stakeholder requirements used to derive DOORS NG Requirement “Obstacle Avoidance Requirements” “

In Figure 3, we look upstream from a specific DOORS NG requirements spec and ask for all Jama stakeholder requirements from which it is derived, three in all. Finally, in Figure 4, we ask for all Teamcenter PLM items linked to a specific DOORS NG requirement, “Object ID Requirements”. The extended chain of four connections follows a path from the DOORS requirement (purple) to a SysML requirement (yellow), satisfied by a SysML function (green), allocated to a SysML block (red), linked to a PLM item (gray).

Figure 4 Query on Neo4j Graph database, “Show all Teamcenter items connected to DOORS spec “Object ID Requirements””

In our new blog series, we have extended the model from the earlier series into additional domains, including the physical structure, simulation and testing. Note that with three simple queries to a single database, a user concerned with DOORS NG requirements can determine:

• What stakeholder requirements affect my technical requirement?
• What test cases have been created for my technical requirement?
• What PLM items could be directly impacted by changes in my requirement?

and the same equivalent capabilities are available to users in any of the other domains. Note also that they may not have (or need) full access to all those other repositories and all the information stored about those related elements. The graph holds only the existence of those elements, plus whatever sparse set of properties are associated with them within the graph database. With such techniques, generating and documenting targeted traceability across large models with thousands or millions of elements becomes practical.

We have also demonstrated some new features available in Syndeia 3.2 or the upcoming 3.3

• New software tool interfaces (e.g. TestRail for Test Management)
• Direct connections between non-SysML model elements (e.g. GitHub-TestRail, JIRA-TestRail)
• Syndeia Cloud, a server-based scaleable architecture for enterprise deployments

The SysML models in MagicDraw and IBM Rational Rhapsody used in this discussion can be downloaded below. 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 MBSE.

SysML Models: MagicDraw | Rhapsody

Related Posts:

• Model-Based Systems Engineering for Autonomous Vehicles | Part 1
• Model-Based Systems Engineering for Autonomous Vehicles | Part 2 
• Model-Based Systems Engineering for Autonomous Vehicles | Part 3
• Model-Based Systems Engineering for Autonomous Vehicles | Part 4
• Model-Based Systems Engineering for Autonomous Vehicles | Part 5
• Model-Based Systems Engineering for Autonomous Vehicles | Part 6
• Model-Based Systems Engineering for Autonomous Vehicles | Part 7
• Model-Based Systems Engineering for Autonomous Vehicles | Part 8
• Model-Based Systems Engineering for Autonomous Vehicles | Part 9
• Model-Based Systems Engineering for Autonomous Vehicles | Part 10 (this post)