Model-Based Systems Engineering for Autonomous Vehicles

In Part 1 of this series, we introduced some ideas about Model-Based Systems Engineering (MBSE) approaches to the development of Autonomous Vehicles (AVs). Our specific interest in this series is the modeling of requirements in combination with functional architecture, software configuration repositories and project management.

With Syndeia, the system engineer has two general approaches by which those requirements can be connected to the other elements of the system model that satisfy, verify, refine or otherwise trace back to it. On the left side of Figure 1, we create a Reference Connection, which creates a traceable link between the model elements but does not assume any common system information.

Figure 1 Alternative Requirements connection methods supported by Syndeia

An alternative approach on the right side of Figure 1 is a Model Transform Connection, which transforms the requirement in Jama or DOORS NG into an equivalent SysML requirement and maintains a connection between the two so that the common information between the two elements, including both structure and attributes, can be compared and updated as one or both change over time.

Figure 2 SysML sequence diagram, scenario for visually impaired passenger

The choice of approach depends on the user’s MBSE methodology. A Reference Connection is simpler because information is not duplicated. In Syndeia, such a connection can check whether a later version of the Jama requirement has been committed, which still requires some user vigilance. A Model Transform Connection may offer more modeling flexibility, where the SysML requirement can be linked to multiple other SysML elements by standard relationships such as Satisfy, Verify and Refine dependencies. For example, Figure 2 shows a SysML behavior diagram describing a desired scenario for a visually impaired passenger using an AV. Figure 3 shows that the SysML model uses this scenario to refine or clarify a requirement using the standard Refine dependency. Other tasks involving verification and decomposition of requirements can be simplified if the SysML model includes the requirement explicitly.

Figure 3 Scenario used to Refine Requirement

We will assume that requirements will initially be generated in a requirements management tool. Figure 4 shows a partial list of requirements created for this example from the US DoT report, “Automated Driving System 2.0: A Vision for Safety” (September 2017), captured as a multi-level requirements model in Jama. Each requirement is captured in Jama with a Name, ID, Description and other attributes depending on user needs. Figure 5 shows an example of one requirement in the Jama web browser. (Note: The DoT report is a set of suggested guidelines, not mandated requirements. The author’s use of them as requirements are purely for the purpose of illustration.)

Figure 4 ADS Requirements model, Jama Software

Figure 5 Requirement “Collision Compatibility” in Jama web browser

In our AV example, we have used Model Transform connections to generate a SysML requirements structure. Using Syndeia, we can carry this out in a single step, dragging and dropping the top-level requirement specification, DoT ADS Guidelines, from the Jama repository to the MagicDraw model. The full four level, sixty-four requirement structure is transformed and each pair of requirements connected for possible compare and sync functions later.

Figure 6 JIRA Task attributes linked to a SysML requirement using Syndeia

Using Syndeia again, we use the SysML requirement structure to generate a set of JIRA issues, one for each requirement. An example is shown in Figure 6 for a mid-level requirement specification. The JIRA issue for each requirement can be used for project management purposes, to track status, schedule and assigned personnel. In this case, a Reference Connection is used, with no common attributes between the SysML requirement and the JIRA issue. However, the connection does allow the system engineer to open the JIRA issue in the web browser directly from an element or element symbol in the SysML model and provides an indirect linkage back to the Jama repository. Using these connections, we have completed the left side of the TSM architecture shown in Part 1 of this series.

Part 3 will introduce functional architecture modeling with connection to requirements, project management and software configuration repositories. Visualization and search of the resulting connection network or graph is considered in Part 4. The SysML model, in MagicDraw and IBM Rational Rhapsody, will be made available for download with Part 4.

Related Posts:

Tags:

Blog

Model-Based Systems Engineering for Autonomous Vehicles | Part 2