When developing or launching a product, the most important resource is not money or manpower; It’s time. What your team can do with the time they have can make or break a product. But inevitably, there will always come a situation where time is cut short, and a product needs to be launched. For example, a product manager walks to your desk and tells you “Your project timelines have been cut in half”. So what should you do?
Step 1: Don’t Panic! Yes, simulations need to get done to support a product launch, but you can’t control circumstances and there’s only so many hours in a day. You can’t focus on the root problems that you can solve if you are panicking. Though it seems counter-intuitive, taking five minutes to reset your mind and prepare for the task at hand is critical.
Step 2: Triage The Situation. This is what I refer to as “putting a fence around the problem”. Engineers know that an unbounded problem is an unsolvable problem, and your mind often will think the problem is much worse than it actually is. Begin by writing down what simulation activities need to get done. This activity will allow you to both quantify and prioritize an activities list. As an example, maybe your list of simulation projects for a consumer electronic device looks something like this:
1.) Chassis static structural simulations (FEA)
a. Chassis material optimization DOE (4 designs)
b. Screen size and placement
2.) Device drop test simulations (FEA)
a. 4 drop heights
b. 4 environmental conditions (hot, cold, two operating ranges)
3.) PCB board thermal management simulation (CFD)
a. Component placement study
b. Heat sink fin design development
c. Industrial design chassis study (5 designs)
d. Heat sink material DOE
4.) Component transient hot shutdown simulation (CFD)
a. Component placement study
5.) Board Spin support (Electromagnetics)
a. PCB mockups using IcePak
b. High Frequency simulations
Step 3: Redlining The List. For the next step, you need to determine what should get done versus what needs to get done using a framework to objectively assess the value of each simulation. Go through your simulation list and ask the following questions:
· Is this study needed to successfully launch a product?
· Is this a nice-to-have?
· What study is going to have the highest return on investment (ROI)?
o Less design rework
o Lower cost tooling
o Reduced material spend
· Can this prevent a critical failure, stop-ship event, or warranty issues?
· Can I achieve the same outcome with a simplified simulation?
o Do I need a transient model, or can I use a steady-state model?
o Do I need complex physics?
o Can I segment the model into a smaller package?
o How many operating conditions do we really need to validate this product?
· Can I combine simulation requests into a “master model”?
While not a holistic list, this helps create a lens you can look through as you redline your simulation needs list. Using our example in Step #2 above, our new list might look something like this:
1.) Chassis static structural simulations (FEA)
a. Chassis material optimization DOE (2 designs)
2.) Device drop test simulations (FEA)
a. 2 drop heights
b. 3 environmental conditions (hot, cold, average operating temperature)
3.) PCB board thermal management simulation (CFD)
a. Component placement study
b. Industrial design chassis study (2 designs)
4.) Board Spin support (Electromagnetics)
a. PCB mockups using IcePak
b. High Frequency simulations
Some common themes that were used to reduce this list focused on assessing what was the bare minimum need to validate the product. Run counts were reduced in favor of targeted value-adding conditions, nice-to-have design studies were combined or eliminated, and emphasis was placed on worst-case scenarios that were cheaper to simulate (steady-state simulations vs. transient simulations). However, production-critical runs that could directly impact the products success were retained. Drop testing, thermal management, and hardware placement studies are all needed to ensure a robust product launch.
While engineers might not always have enough time (or hardware) to run all the simulations we would like on a product, we always have enough time to problem-solve. Sometimes that means making tough decisions like refocusing priorities, reducing problem complexity, or just saying “no” to the nice-to-haves. At the end of the day, being a successful engineer is about working smarter, not harder.
About the Author
Follow on Linkedin More Content by Krystian Link
