A Model-Based Tool to Assist in the Design of Safety-Critical Systems

The design of critical systems—those used in aircraft, medical devices, etc.—is becoming increasingly challenging as they increase in sophistication and complexity. A recent research project at the SEI aims to improve the way these systems are designed by allowing engineers to evaluate more design options in less time than they do now. The state of the art in critical system design is model-based engineering, but it requires engineers to manually construct a model of their system and then analyze it for various performance and cost characteristics. As this post describes, we prototyped a language extension and software tool—collectively referred to as the Guided Architecture Trade Space Explorer (GATSE)— that partially automates this process so system engineers can rapidly explore combinations of different design options.

A New Paradigm

We are not the first to look at the integration of automation and system design. At first blush, it may seem like an optimization problem, where system designers might simply specify requirements—e.g., “the system shall cost less than $10M” and “the system shall respond to inputs in less than 5ms”—and then, given a supply of components and configuration options, simply find an architecture that satisfies all design constraints. Indeed, this approach has been taken by some researchers in this area. We share the recognition of others, though, that since many of a system’s quality attributes are not easily quantifiable, it is better to use automation to augment engineers’ efforts rather than partially replace them.

Far more common than optimization, however, is the standard guess-and-check style of system design, where engineers first select system components and configuration options based on intuition or familiarity and subsequently check their designs using various analyses. This project was designed to explore a newer paradigm, though, called design by shopping, where engineers first specify component and configuration options, and then valid system designs are automatically generated and analyzed for performance and cost characteristics. Designers can then “shop for” the system design they want by exploring the space of possible system configurations; since these configurations necessarily entail various tradeoffs between their quality attributes (e.g., a more expensive system might have better performance), this gives rise to the term trade space.

Project Tasks

GATSE relies on three modifications to existing technologies to improve the way critical systems are designed.

1. Modeling Language Extensions—First, we extended a modeling language that designers use to describe their systems so that their models can be partially specified. In the status quo, system designers must specify each part of their system before analyzing it. In this effort, we modified a system specification language—the Architecture Analysis and Design Language, or AADL—so that designers can fully specify some design options, but only specify the sets of options they’re considering for other design options. The system elements that are not completely specified—referred to as choicepoints—would instead be specified as a set of valid options, or choices. For example, a system may need a processing unit (the choicepoint), but there might be several different options, each with a different price, computation speed, and required amount of power. Each option is a valid candidate for the processing unit choicepoint.
2. Connecting to a Trade space Visualizer—Second, we connected the SEI’s model-based engineering workbench, called the Open Source AADL Tool Environment (OSATE), to design-by-shopping software called the ARL Trade Space Visualizer (ATSV). ATSV was developed by researchers at Penn State University (in projects unaffiliated with the SEI) to explore the trade space of physical systems that can be described by mathematical models, such as different options for wing-shapes. We modified OSATE to both be able to receive input from ATSV, and to send analysis results back to the program, instead of directly to the user for manual analysis. This way, ATSV will be able to update its internal (genetic/evolutionary) algorithms with the performance and cost characteristics of the system it chose the design options for. This information can then be displayed graphically, and ATSV allows users to specify their preferences to guide which system configurations are selected and analyzed next. ATSV is designed to run in batches—it takes about a second (on my laptop) to select an option for each choicepoint, build the finalized model, analyze it, and then store the results for display. After the batch is complete, the characteristics of each candidate architecture are displayed graphically so a user can see trends emerge in the system’s trade space.
3. Automating System Configuration and Analysis—Finally, we modified OSATE so that after it receives input from ATSV, it can use that input to create a valid system model and run the analyses specified by the user. Given a partial system specification (from the user) and a set of component and configuration choices (from ATSV), OSATE will be able to fill in the gaps to create a complete system specification. It then automatically runs the specified performance, cost, and other analyses and reports its output back to ATSV.