Let’s talk complexity. Many modern products are systems of systems, complicated combinations of mechanical parts, electronics and software whose behavior can be difficult to understand in typical and extreme operating conditions. Take windshield wipers. On my first car, they were relatively simple: a motor with wiper arms and blades, either on or off, controlled by a button that flicked up or down. Today, my wipers also have a near-infinite number of swiping speeds, they automatically stop when the car is at a standstill, and I swear they speed up when the rain is heavier, although others in the car tell me I’m crazy to think so.
How do you design this complicated system? A basic windshield wiper is made up of an electric motor, a mechanical linkage to transform the rotating motion from the motor to oscillating motion of the wipers, and the wiper arms and blades. Like most products, you work from the last successful design, add in new features like a rain sensor, simulate and test and, voila, present a bill of materials to manufacturing. Sounds easy, right?
Not so much. The designer needs to understand solid mechanics, kinematics and dynamics to optimize the mechanism, controls design for the on/off/sensors, fluid flow to ensure that the wipers do their job of clearing the windshield and perhaps software for the speedup/slowdown. What if you now need to also factor in cost and weight, and make the appropriate tradeoffs for a wiper system that’s just right?
Understanding via Optimization
You’re entering the world of design optimization and multiphysics. Multiphysics is included because creating efficient, sturdy wipers (and a capable-enough motor) combines an understanding of the structural forces on the wiper arms with the fluid flow of the liquid or ice on the windshield—leading edge, trailing edge, nearly dry vs. very wet and so on. There are lots of possible combinations of positions and loads, shifting over time.
This is also an excellent case for using optimization technology because you likely want to understand the effects of all possible combinations: the material grades available for the wiper blades at their many cost ranges; the motor configurations and costs weighed against their ability to drive different wiper configurations; cost and benefit of the sensors and how their data should affect the motor, and so on. You want to evaluate the performance of each individual component against its criteria and then, of the system as a whole.
There is nothing simple about this either. Multidisciplinary optimization (MDO) technology is improving quickly, becoming more user friendly with every release, but it’s still far from easy to set up a study as complex as this one.
If we set aside the fact that the structural designers now need to work with the team sourcing the motor, with the experts handing the sensors and software—organizational issues that are outside the scope of any software package to fix—users of MDO need to understand the system as a whole and how to define the physics of each discipline. They will use the specific CAE models, inputs and solvers for each discipline and use the MDO software to link them via design variables.
Software can only help so much in getting this right. MDO users need to organize and track the discipline-specific analysis models, note any approximations (and understand how that may affect the overall outcome) and understand how the models are coupled for the simulations. Choosing the right algorithms is hugely important, too. A global optimization might lead to a better study outcome but can be computationally expensive. If the solvers can run in parallel, an answer may be arrived at much more quickly but again at greater computational cost. MDO software can do much, but the human user must understand the design, the algorithms available in the MDO solution, the computing environment and the desired outcome to create the most appropriate study.
All of this is not to discourage you from considering adding MDO to your CAE portfolio. MDO can unearth design alternatives you hadn’t considered, highlight the impact of one design variable over another, and increase understanding of the system as a whole. Perhaps start with shape (structural) optimization to get used to software doing part of the design job and to set the stage for MDO. Have methods engineers or other experts set up wizards and toolkits to enable less experienced users to start playing with MDO. Implement the means to manage parts, input decks, solvers and the other MDO building blocks so they’re ready when you do decide to start on an MDO study path. Above all, consider using MDO early in your design process—the understanding you’ll gain can save valuable time overall, and create a better end product.