Part 1 of this 3-part series described how a model-driven development process and virtual prototyping tools help address the challenges of implementing a DFSS methodology in a complex automotive electronics development process.

A Design for Six Sigma (DFSS) or Lean DFSS methodology combined with model-driven development can produce significant improvements in both productivity and quality when virtual prototyping, automated data collection, and statistical analyses are used to guide the model-driven development process for automotive electronics systems.

In Part 1 of this series, the typical phases of a DFSS methodology were outlined as follows:

Project Definition: Business goals are established.

Customer Analysis phase: Customer specifications critical to quality (CTQ) are defined for the product.

Concept Analysis phase: Design alternatives are considered and measureable CTQ criteria identified.

Design and Optimization phase: The best design options are selected and optimized to meet CTQ specifications.

Verification or Validation phase: A production run is simulated to assure manufacturability of the design.

These phases are illustrated in the figure below.

View a full-size image

A model-driven development process used in the context of a DFSS methodology can play a vital role in ensuring that the CTQs defined in the Customer Analysis phase are met in the final Verification phase. In the figure above, this approach is implemented using the Mentor Graphics' tool SystemVision with a Minitab statistical application add-in that provides access to SystemVision's virtual prototyping capabilities.

SystemVision is a mixed signal, multi-discipline modeling and simulation environment that enables virtual integration of all the technologies shown below.

View a full-size image

Concept Analysis phase: Throttle control-loop example
At the beginning of the Concept Analysis phase, engineers create functional-level models in SystemVision. These models implement executable specifications that correspond to the measurable CTQs defined for the product in the Customer Analysis phase. The executable specifications define measurable behaviors for each of the CTQs, and these measureable behaviors are then used to help determine if the CTQ specifications are being met.

For example, a CTQ for a new automobile may specify that if the gas pedal is pressed, the car must accelerate smoothly within 50 milliseconds (ms) with no noticeable lag. This CTQ places requirements on various systems in the vehicle, including the drive train and the throttle controller.

The acceleration of the vehicle is likely to be most sensitive to the behavior of the throttle system and its controller. These responses can be represented at the functional level as a behavioral model that includes the throttle pedal sensor, the electronic throttle electromechanical actuator, the throttle position sensor, and the feedback control algorithm. When a step input signal moves the throttle plate in the model to a certain angle, a signal is produced with a measurable risetime and overshoot.

One of the first tasks in the Concept Analysis phase is to determine how the acceleration requirements specified in the CTQ correspond to the measurable behavior of the throttle plate on the engine. Design engineers need to specify how CTQ requirements for "smooth" acceleration "without lag" can be related to the risetime and overshoot of the angle of the throttle plate over time.

A reasonable assumption might be that a risetime of 25 ms (the time for the throttle plate angle to move to a specified value) corresponds to a 50 ms overall acceleration of the vehicle, taking into account losses in the drive train and other systems that aren't included in the throttle controller.

The CTQ requirement for "smooth" acceleration is associated with a specification for the vibration and range of motion of the throttle plate (as measured by the angle of the throttle plate). Specifically, if the angle of the throttle plate overshoots the proper final position and oscillates as it settles to the proper value (as shown below), then the acceleration may not be considered "smooth."

On the other hand, some level of overshoot may be acceptable, especially if it allows the response time to be faster. This specification can be precisely captured by providing a maximum overshoot value for the throttle plate angle in response to a step-function input. The figure above shows an example of such a measurement on a waveform.

Once the relationship between the CTQ and waveform measurements is established, SystemVision waveform measures (in this case, risetime and overshoot) can be used to measure the behaviors of the throttle plate as different design options are explored to determine if the design is meeting CTQ requirements.

When executable specifications have been created that take into account all the CTQs, the functional model is ready to be shared, distributed, and exercised. Screening techniques can be used to determine the impact of various system parameters on the CTQs. Architectural decisions can now be made about how the design will be implemented, and interfaces and control functions can be defined.

Iterations between the Concept Analysis phase and the Customer Analysis phase allow fine tuning of CTQs and enable a clearer understanding of how CTQs map to executable specifications in the functional model. However, once the executable specifications are defined, they will rarely change in subsequent phases—although other measures may be added as the design becomes more detailed to provide a way to further verify that CTQ specifications are being met.

The executable specifications provide the framework for the remaining stages of the model-driven development process, allowing the effect of changes at each stage to be tied back to CTQs and manufacturing robustness be built in at each stage.

Design and Optimization phase
In the early part of the Design and Optimization phase, design alternatives are explored in more detail using the theoretical behavior of the functional models to generate information on which to make architectural decisions. Iteration between the Customer Analysis, Concept Analysis, and the Design and Optimization phases may be needed to find acceptable tradeoffs between conflicting requirements.

As the Design and Optimization phase progresses, a system architecture is defined, components are selected, and a detailed design is implemented. Throughout this segment, developers move up and down the model hierarchy, from more abstract functional models and architectural blocks to more detailed models of specific components of the design, to explore options and refine the design.

Six Sigma practitioners or engineers can optimize critical design parameters for manufacturing variability at any of these levels of abstraction. Design of Experiments (DOE) analyses can be run in Minitab with SystemVision on a statistical model created by populating a data spreadsheet in Minitab with automated measurements taken from a series of simulations of the SystemVision model.

The three DFSS methodology phases (Concept Analysis, Design and Optimization, and Verification or Validation) in which model-driven development can be incorporated using SystemVision and Minitab are described in more detail below.

In the Design and Optimization phase, engineers define an architecture based on information gleaned from simulations of functional-level models in the Concept Analysis phase and then create or refine more detailed mathematical models for elements of the solution.

First, critical design parameters can be determined by performing a screening analysis of all of the parameters that may impact the CTQ's. This task can be accomplished using a full or fractional factorial experiment design, or experiment designs from the Taguchi or Plackett-Burman families. This methodical approach determines the design parameters upon which subsequent analyses will focus.

Next, Six Sigma practitioners can explore the effect of manufacturing variability on these critical design parameters early in the Design and Optimization phase using the automated prototyping capabilities and DOE tools provided by Minitab with SystemVision. A more abstract model with fewer variables means simulations will run quickly, so a number of options can be rapidly examined. The information derived from these virtual experiments allows design decisions to be made early in the design process to reduce the vulnerability of the critical CTQs to manufacturing and operating environment variability.

For instance, if a functional model shows that an executable specification is particularly sensitive to variation in gain, a decision might be made to implement a critical gain block in embedded software to ensure the gain does not vary.

As the development process moves into the implementation stage, engineers use the virtual environment to integrate components across mixed-signal and multi-discipline boundaries in order to identify and resolve integration issues, such as interface mismatches or sign errors, before physical implementation of the design. The engineers then dig into the details of designing components and use SystemVision simulations to fine tune the designs. Six Sigma practitioners can test components or segments of the system using virtual experiments in Minitab with SystemVision to identify manufacturability issues and work with the engineers to resolve them.

Verification or Validation phase
In the Verification or Validation phase, a virtual pilot manufacturing run is used to verify manufacturability of the design before it goes into production. Using a SystemVision Monte Carlo analysis to model full statistical variations of the complete, detailed design provides assurance that all the obvious manufacturability issues have been eliminated. Thus, when physical pilot runs are initiated, only more subtle issues will be left to be resolved.

The result of fully exploiting a DFSS approach using a model-driven design process enables a smoother, quicker transition to full-scale manufacturing—with a high-quality product that meets customer specifications.

Part 3 of this series presents an electronic throttle controller design example to demonstrate using virtual prototyping to define a robust system capable of delivering the high quality at low cost.

Darrell Teegarden manages the System Modeling and Analysis business unit at Mentor Graphics Corporation. He can be reached at darrell_teegarden@mentor.com.