Managing Simulation Democratization

As the walls separating design engineers and analysts continue to crumble, workflows are evolving to take advantage of new technologies that help make the design process more efficient. However, there’s a perennial problem slowing that evolution to a crawl.

The fact that there are more design engineers than analysts is nothing new. What’s exasperating this bottleneck in the design cycle is widespread access to more advanced computing hardware and software that allows design engineers to consider more “what-if” iterations. All of those promising potential designs from all of those engineers need to be simulated and analyzed — often by a very small team of analysts.

Simulation for All?

The obvious solution would be to provide simulation and analysis tools to more design engineers. What’s not so obvious is how to best do that. Simulation and analysis requires specialized skills not all design engineers have. For example, here are the requirements from a recent job post for a modeling, simulation and analyst intern:

• Knowledge of programming languages: FORTRAN, C/C++;

• Good verbal and written communication skills;

• Knowledge of basic physics and its application to modeling and analysis;

• Knowledge of physics, random variables and its application to modeling and analysis;

• Familiarity and knowledge of system engineering and analysis;

• Experience in software development processes, object oriented design, and real-time applications;

• Debugging/Analysis methodologies in optimizing application performance;

• Understanding of computer architecture and design and digital system modeling and simulation experience;

• Ability to troubleshoot simulations problems and write post processing scripts;

• Shell/Perl/Python scripting.

If that’s what’s expected of an intern, you can imagine what is required of a full-time simulation and analysis expert. Even if a design engineer has some analysis skills, he/she has plenty to do in the design process without taking on more. The key is to find that sweet spot where design engineers can quickly get answers that will help them refine designs without waiting in a queue for analysis, which frees up the analyst to work on the most promising and refined product iterations or the most complicated simulations.

There are a number of approaches being applied, from simulation tools that are integrated in popular CAD packages to software that focuses on particular industries or engineering problems, to user interfaces and templates that can guide design engineers through some common simulation tasks. The problem with many of these approaches is that they’re either too specific to be applied to other designs and industries or too general to be really useful in analyzing specific problems. The ultimate solution — in addition to training more analysts — is to combine all of these approaches into a custom solution for each customer. That’s where apps come in.

Analysts as Developers, Managers

MathWorks, the developer of MATLAB and Simulink, provided a path to specialized application development and deployment. Its MATLAB Central File Exchange allows the company and customers to share custom applications, classes, code examples, drivers, functions, Simulink models, scripts, and videos. A community of users has developed around File Exchange, sharing apps and expertise.

COMSOL is taking a similar tack with its Application Builder, which allows experts to create specialized multiphysics apps that non-experts can use to simulate changes they make to variables defined by the expert analyst. (For more examples of the democratization of simulation, click here.)

The app model has the potential to alter the design workflow. It provides analysts with the tools they need to become software developers, albeit on a small scale. Those apps will no doubt need updated as design engineers request more features. The designs informed by those apps will still need a final analysis, but the potential is there for the analyst to become the management hub of design activity, rather than a bottleneck in the process.