Virtual prototyping boosts model-driven Design for Six Sigma methodology: Part 3 of 3 - Design example: Electronic throttle control
By Darrell Teegarden, Mentor Graphics Corporation
Automotive DesignLine (04/24/08, 03:44:00 PM EDT)
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.
E-mail This Article | Printer-Friendly Page |
|
Related Articles
- Virtual prototyping boosts model-driven Design for Six Sigma methodology: Part 1 of 3 - The challenges and tools
- Dealing with automotive software complexity with virtual prototyping - Part 3: Embedded software testing
- Dealing with automotive software complexity with virtual prototyping - Part 2: An AUTOSAR use case
- Dealing with automotive software complexity with virtual prototyping - Part 1: Virtual HIL development basics
- How to make virtual prototyping better than designing with hardware: Part 1