Thursday, July 1, 2010

Turn Your Design Process Upside Down

Reading through some industry literature today, I'm finding a trend done by best-in-class companies on techniques they use to remain best in class.  Specifically, I'm looking at the ways they have done their engineering design process.

I like this description of the design cycle (image courtesy of NASA).  But, I'm more interested in the detailed steps between 4. Build the Item and 5. Evaluate.

For example, I envision a team sitting around a conference room table 1. Stating the Problem that needs to be resolved and putting together a mind map during the successive brainstorming sessions to 2. Generate Ideas.  Out of those ideas, a 3. Solution is Selected and then the engineers go to work 4. Building the Item and sending it to the analysis experts to 5. Evaluate.  Of course, the results are presented and if the item does not resolve the problem, the cycle repeats.

What is the Most Efficient Way to Build and Evaluate the Item?

Another way to phrase that question is how to Design and Analyze the item?

The typical way is to take the idea and throw it into the designers' (design engineers') desk and let them build up a concept until they are ready to send it over to an analyst.  After the analysts run their simulations, they provide feedback to the designers to make the needed changes.  That back-and-forth cycle repeats until the resultant solution is acceptable, typically with the analysts time consuming most of the design cycle.

CAx software providers are helping to sway that process by bringing analysis tools to the designer.  By using ease-of-use, dumbed-down, integrated CAD/FEA, the designer can perform first-pass analysis and decrease the development cycle time by not involving the analyst until later in the process while still running multiple "what-if" scenarios.  WHAT IF THAT PROCESS IS WRONG?  We've all heard "blue is good, red is bad" from people who don't understand what accurate simulation requires.  Putting these tools into the hands of the inexperienced is dangerous and does not protect the safety of the public nor create higher quality or less expensive parts.  Having designers run first pass - which eventually leads to skipping the detailed analysis all together - may look good on the books, but that practice will come back to bite you.

The New Design Process

Rather than put analysis tools into the hands of the under-educated or less experienced designer, get the models to the analyst sooner - not later.  Let the analyst create a detailed and accurate simulation of the design and run the first simulation to prove the simulation's accuracy.  Then, turn the entire simulation over to the designer in the form of a template.  The designer is allowed to modify the design within the boundaries of the template.  With each modification, the designer can re-run the accurate simulation - not just a simplified first pass.  If the modifications overstep the boundaries of the template, the analyst will have to review the model and update the parameters of the simulation; run it to verify accuracy; and then hand it back to the designer to continue using the updated template for additional "what if" scenarios.

All Is Not Lost

The entire framework to integrate CAD and FEA is not wasted.  In order to get the new design process to work, a smooth transition between design and analysis still needs to happen.  Data needs to be interchangeable.  But focus needs to be on software features that allow development of a simulation template unique to each design.  The features need to include user-level control so designers can't just override an analyst's template.  The UI needs to allow simplification for the designer yet full control for the analyst.  Processing power needs to continue to increase to allow for complete simulations to run quickly.  Software algorithms need to be adjusted so only modifications (within template limitations) need to be reanalyzed, not the entire model.

The current trend of integrating CAE with CAD is on the right track, but simplification of analysis for the design engineer may be the wrong focus.  Instead, focus on allowing an experienced analyst set up simulation templates for the designer to use.  Keep the simulations complete and accurate while still reducing the development cycle time.  So turn the design process upside down.  Stop moving more FEA features towards the designer while delaying analyst input.  Instead, move the analyst forward in the process and more integral in the design cycle.


  1. Solid article, Scott. When looking at the design engineer, I think we have to see there is a spectrum of capability. Maybe 20% will adopt simple FEA and do it right. 80% will take a stab at it, fail, and (as you say) never do it again.

    That happens because A) these folks wear many hats and don't have time to muck around and B) Engineering Management hasn't made the activity a requirement.

    I like your idea of providing a template based approach overseen by more senior CAE analysts.

    And, the most important thing a company can do with its expert CAE analysts is find a way to inject them upfront before any of the detailed design is done.

    That is sometimes challenging because many analysts don't have a natural appreciation for the speed of business. I think including them in project team meetings will help them get aligned with that and enable them to stop looking at everything from a researchy-academic perspective.

  2. Scott.. good stuff. Not a simple thing. I think the template idea is fantastic! This assumes the organization has vision and an appreciation that design should be simulation driven and not just a nice to have after-thought. You mention above, "send it over to the analyst".. Absolutely valid, but backwards, in my opinion. Why are "analysts" not part of the design team in some respect. Why aren't analysts not performing "upfront" simulation as part of their daily activity? If they aren't providing value on the design upfront- what exactly are they doing?

    Ever think about- "what is the purpose of the "analyst group"?" Hopefully, it is to improve the overall integrity of the designs of the company and/or provide innovative futuristic ideas (R&D) to take the company into new markets or to own a particular market.

    The point in my rant is that the success/failure of simulation within an organization is directly proportional to the vision of those that require it. Has minimal to do with designers, analysts, consultants.

    As you mention, there are ways (templates) to ensure newbies are on the right track. But, suppose that organization doesn't have an analyst to babysit? Should that organization not do simulation?

    I'm biased, for sure, as I think nearly every organization should and could leverage simulation. But, mgmt has to have the correct vision of implementation. Don't stay with status quo out of fear or because "my team can't handle simulation". My response to that is that you need to take a hard look at "your process".. Instead of saying, how can I wedge simulation into my already hectic schedule. Take a step back and say, how can we design smarter, not harder.

    Can we leverage our existing analyst group better? Can we ask our existing designers to rely on simulation better than they do today? Can we partner with a vendor/reseller that can offer the full "process solution" rather than just simply selling me a CD of software.

    Take a step back in time and remember when people said, "we don't really need 3D".. seems silly now, doesn't it.

  3. Analysts being analysts is the only downfall to my vision. As you mention, they don't have a natural appreciation for the speed of business and good managers try to protect them from that aspect so they can focus on the details of the problem. When meshing and boundary controls take 2 weeks of solid man-hours to setup, how can moving the analyst earlier in the design cycle be an improvement and not interfere with the business case? Professional judgement (aka gut instinct) will probably be used to "solve" the problem in a cost-efficient manner before the template could be created.

  4. It appears that you definitely understand my vision. Move the ANALYST earlier in the development cycle, not just the ANALYSIS. Bring the analyst to the design team, program meetings, and get them involved in the business practice. They more they understand, the better choices they can make for a "good enough" simulation. Sharing their insight to the entire project team will also help with understanding and communication.

    Analysis is still too complex to give to every designer. In my opinion, designers are generalists and analysts are specialists. Designers need to have a conceptual understanding of a vast number of disciplines. Analysts need to be very focused and have complete understanding of a few discrete areas. For example, setting up material models for a structural analysis -- definitely need a deep understanding to set up equations of state for visco-elastic materials. And what about bolt preload? An old habit, but I use thermo analysis in my structural model. If you chill the bolt, it shrinks and applies a compressive load. (Yeah, I was doing multi-physics before it was popular.)

    I share your bias and I think simulation will be de facto soon enough. But there needs to be a balance. Much luck napkin sketches and layouts can portray enough information about a design to start cutting chips, so too must an analysis be good enough to start moving forward in the detailed design process.

    Some info on my background.
    My experience is with tool design. I don't need to worry about a few grams of weight savings nor a few pennies of parts cost (when only making 1 or 2 tools). I also deal with larger factors of safety. Therefore, I have learned to make conservative assumptions to simplify the problem for a faster solve yet still be accurate enough to make an informed design decision. Most analysts - pure analysts - I have met do not have that ability. They have an inherit need for a perfectly accurate simulation to the point of being obsessive compulsive. There needs to be a cultural change (business case) and technological change in order to bring the Analyst forward in the design cycle.

  5. Hi Scott:

    I'm a colleague of Derrek's and Jeff's, and editor of a new community site, Would you allow me to publish this post on the site? I'd give full attribution and links on the home page to your blog, of course.

    Regards, Bob

  6. Most certainly you can re-purpose this post. Thanks for asking.

  7. Thanks, Scott. I'll let you know when it posts.