|
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.
Part 2 details how a model-driven development process is integrated with a DFSS methodology to provide a more efficient way to ensure that customer critical-to-quality (CTQ) requirements are met in the final product.
Imagine all the variables that can affect the performance of your design—from part tolerances to process variations and environmental conditions. Testing a physical prototype for even a fraction of these factors can be expensive, time-consuming, and error-prone. However, you can significantly cut the costs of testing by simulating with virtual prototypes.
A model-driven Design for Six Sigma (DFSS) approach provides an effective structure for managing a complex development process while reducing costs through virtual prototyping. DFSS methodologies typically start by defining a project and then analyzing customer needs—producing a set of customer critical to quality (CTQ) specifications. Incorporating a model-driven development process into the DFSS methodology can help ensure that these CTQs are met in the final product.
Design example
In the steps below, a vehicle electronic throttle control system is used to demonstrate a model-driven process using virtual prototyping. The example is implemented using the Mentor Graphics tool, SystemVision system modeling solution, and Minitab statistical tools. SystemVision provides a virtual lab for design and analysis of distributed mechatronic systems, while a Minitab add-in integrates Minitab tools with SystemVision's virtual prototyping capabilities.
Step 1: Set up measures in SystemVision corresponding to CTQs.
First, you need to associate each CTQ with one or more measurable responses to a well-defined test condition. For instance, for the electronic throttle, the test condition can be specified as a step input to the throttle system (corresponding to "stepping on the gas").
Measurements are then made of the angle of the throttle plate over time. The measured responses are rise time and overshoot. (In Part 2 of this series, a rise time of 25 ms or less and an overshoot of 12 milliradians (mrad) or less (0.6875 degrees or less) were determined to indicate that the response is within an acceptable range.)
Step 2: Create an executable mathematical model of the design.
The figure below shows the top-level schematic of the electronic throttle control system created in SystemVision. Each symbol represents a mathematical model that has been implemented using the VHDL-AMS modeling language.
For example, the block labeled Actuator/Load (upper right) represents an electromechanical device used to control airflow in an internal combustion engine. The Transducer block models a sensor that provides a continuous feedback signal indicating the measured angle of the throttle plate. The block labeled Gas Pedal represents the electromechanical device used by the vehicle operator to control the vehicle speed.
The remaining blocks represent the feedback and control functionality of the system. These blocks may be modeled at a functional or behavioral level or include full implementation details.
The figure below shows how these blocks can be modeled hierarchically with schematics in the SystemVision environment. The lowest level blocks in the hierarchy represent mathematical descriptions of elemental building blocks. The "controller" block, for example, is a transfer function model for a classic proportional-integral-derivative (PID) controller. This PID model provides a mechanism to easily change the corresponding controller gains (kp, ki, and kd). These constants profoundly affect the resulting response of the system (and the corresponding response rise time and overshoot).
View a full-size image
The response (throttle plate angle) of the electronic control model shown below resulted from controller gain settings of kp = 0.5, ki = 30 and kd = 0.014.
Step 3: Define and run experiments to populate a DOE data table in Minitab.
The Minitab add-in for SystemVision lets you remotely modify controllable parameters in a SystemVision model and automatically execute waveform measurements. Options are provided in Minitab for selecting a specific SystemVision project, defining factors (controllable parameters of the design) and responses (measurements of CTQs), and then automatically executing a series of simulations over a range of defined input values.
The table below shows an example of a Design of Experiments (DOE) trial for the electronic throttle controller in Minitab. The input values are the PID controller gains (kp, ki, and kd). These gains were chosen by first completing a screening analysis (not shown) over a wider range of the available design parameters. The output data points are the CTQ measures (rise time and overshoot).
View a full-size image
Design of Experiments facilities in Minitab were used to create the series of experiments shown in the table. These experiments map the system response surface to changes in the design parameter values over the range of values provided by the Six Sigma experiment designer. A series of experiment trials automatically populated the "risetime" and "overshoot" data columns in this Minitab table.
With automate data collection, once a set of experiments is defined, you can push a button, leave, and come back to a set of fully-populated tables in Minitab.
|
