Having initiated the requirements management process, the systems engineering team frequently moves on to a functional architecture of the system.  For our AV, the top-level “classifier” behavior has been captured in the simple state machine in Figure 1. The Initiation state involves the passenger entering a destination and the AV calculating an optimal route, before the AV enters the Transit state.

Figure 1 SysML (IBM Rhapsody) state machine diagram, AV classifier behavior

The Drive behavior represents the great challenge of vehicular autonomy. The AV must perceive its dynamic physical environment and react appropriately to reach its destination safely in a reasonable amount of time. There are a number of potential sources of data, including video, radar, GPS, and radio signals, and a number of control outputs, including engine power, brakes, and steering.

functional-steps

Figure 2 Functional Steps in Autonomous Vehicle Operation

The critical steps between (as outlined by Lipson and Kurman, “Driverless: Intelligent Cars and the Road Ahead”, (The MIT Press, 2017) are illustrated in Figure 2.

  • Map the Occupancy Grid requires the AV to build a high-resolution real time 3-D map of its surroundings
  • Identify Objects requires the AV to recognize the identity of objects in the grid, e.g. the roadway, building, other vehicles, pedestrians, etc.
  • Predict Uncertainty Cones requires the AV to estimate the possible near-future movements of these objects.
  • Plan Obstacle Avoidance defines the future movement of the AV to avoid obstacles, stay in the roadway and move toward the destination.

The ability to do all these things with sub-second reaction times and high reliability, under a wide variety of lighting and weather conditions, is the grand challenge of the field and is absorbing the attention of a generation of computer scientists, especially in the fields of artificial intelligence and deep learning. MBSE can support this effort by providing a structure in which these developments can be applied.

Figure 3 SysML (MagicDraw) Activity diagram, AV Drive behavior

Figure 3 shows a portion of one activity diagram describing one variant of the Drive behavior. The available inputs are shown on the left border. The initial activities generally involve pre-processing inputs locally to avoid over-loading the main vehicular databus, with the first of the mid-level control algorithms on the right.  The complete model with full diagrams will be made available for download.

Figure 4 Alternative Requirements connection methods supported by Syndeia

As the functional architecture is defined, other software tools come into play for software development and project management. In Figure 4, we use Syndeia to create reference connections from the SysML functions to issues in JIRA and configuration-managed software files in GitHub. These connections provide easy access between tools for their users in different domains, as well as the ability to recognize changes in JIRA or GitHub that potentially impact the function.

In Part 8 of this series, we will look at options for developing and executing test plans in a specialized test management tool and linking these elements to SysML, JIRA and GitHub models. Part 9 will look at system 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 Rhapsody will be made available for download with Part 10.

Related Posts:

Dirk Zwemer

Dr. Dirk Zwemer (dirk.zwemer@intercax.com) is COO and Co-founder of Intercax LLC (Atlanta, GA), a supplier of MBE engineering software platforms like Syndeia and ParaMagic. He is an active teacher and consultant in the field and holds Level 4 Model Builder-Advanced certification as an OMG System Modeling Professional.