Intercax - Blog

Model-Based Systems Engineering for Autonomous Vehicles | Part 5

Written by Dirk Zwemer | Sep 20, 2018

Few other systems have the potential for significant social impact as autonomous or driverless vehicles. They are expected to change

  • Employment opportunities, as truck, bus and taxi drivers take other roles
  • Urban land use patterns, as parking garages and roadways are reconfigured and repurposed
  • Health and safety, as traffic accidents due to distracted and impaired drivers are reduced.

New transportation options for everyone from children to the elderly will emerge. There is little wonder that both automotive and tech companies are pouring investment into this area and thousands of engineers are seeking solutions to the many remaining technical problems.

Last January, we published a series of blog posts on Autonomous Vehicles (AV). Our object was, and still is, to show how AV development can benefit from MBSE (Model-Based Systems Engineering) approaches. In this continuation of that series, we expand our AV model to dive deeper into the design, particularly in the functional architecture, simulation and testing.

Figure 1 SysML (IBM Rhapsody) Block Definition Diagram of Autonomous Vehicle Domain

The current domain model is presented in the SysML block definition diagram in Figure 1. A few aspects of this model may be worth noting

  • There is no Driver, only (0..*, zero-to-many) Passengers. This vehicle will not allow a human to take control directly. How the field will move from current driver-assist features to full autonomy is the subject of much debate, but in our example, we have leapt straight to the endpoint.
  • The AV is in regular communication with a remote digital Cloud Platform, which provides high-resolution maps and other traffic information, infotainment for the passengers, and regularly updated and tested artificial intelligence (AI) algorithms for the AV software.
  • The Physical Environment includes both Conditions, which must be considered in the test plan, and Features, where Smart Features, including roadway infrastructure and other vehicles, can communicate directly with the system of interest. Such communications are called V2I (vehicle to infrastructure) and V2V (vehicle to vehicle), respectively.

Multiple engineering software tools will be used in the development of this system. Figure 2 shows the architecture of our MBSE structure. Syndeia, the MBSE platform from Intercax, is used to create, maintain and visualize the Total System Model (TSM). Our toolset for this example includes

Figure 2 shows the types of model elements and the types of connections that Syndeia uses to weave the TSM. While both Reference and Model Transform connections to the SysML model predominate, there are also direct Reference connections from JIRA to TestRail and from GitHub to TestRail that will be described in future posts in this series.

Figure 2 Total System Model architecture supported by Syndeia

No proprietary knowledge from Intercax customers or others was used in the development of this model.  Ideas from multiple open sources were incorporated, especially “Creating Autonomous Vehicle Systems”, by Liu, Li, Tang, Wu and Gaudiot (Morgan & Claypool, 2018) and “Driverless: Intelligent Cars and the Road Ahead”, by Lipson and Kurman (The MIT Press, 2017).

In Part 6 of this series, we will look at options for connecting requirements in two separate requirements repositories using Syndeia and SysML. The following posts will look at modeling and federating functional architecture, test plans, structure and simulation. The final part will demonstrate how graphs and pattern matching query languages provide efficient access to even very large system models. The SysML models in MagicDraw and IBM Rational Rhapsody will be made available for download with Part 10.

Related Posts:
View full post