Why MBD
Is simulation leading your design, or merely validating it?
Multi-body dynamics (MBD) simulation predicts how a machine performs, and what loads every part carries, before you build it. Done right, it leads design decisions and takes guesswork and risk out of the program. Done wrong, it stalls, delivers too late to matter, and sours a company on simulation. Here is the honest case, from three decades of building MBD models for teams at Joy Global, Genie, and Oshkosh.
Typically responds within 24 hours.
What MBD buys a program
Multi-body dynamics simulation is a physics-based model of a complete machine, its masses, joints, springs, dampers, and actuators, used to predict how the system moves and what loads every part carries before hardware exists. There is nothing mysterious about it. The formulations come from classical mechanics (Newton, Euler, Lagrange), and a solver such as MSC Adams integrates the equations of motion. It is simply following the physics of all the interconnected parts, at a scale no spreadsheet can hold.
In practice, MBD buys a program three things. Less guesswork and risk, because the first prototype is built to a design the model has already exercised. Earlier confidence, because performance questions get answered while the design can still change. And loads you cannot get any other way: the forces and torques at every joint, in every maneuver, at every instant. That system-level prediction of performance and loads is the core value of multi-body dynamics simulation, and it feeds directly into structural analysis and durability: the realistic load histories that stress and fatigue work depend on come straight from the model, and DSIM carries that structural work through as well. It sizes components, drives design decisions, and keeps a program from going down the wrong path.
Hardware is the truth. You just cannot see most of it.
How the physical product actually performs is the truth, and nothing replaces test. But instrumenting every part and every interaction for every force, torque, position, velocity, and acceleration is impractical on real hardware. On most programs you get a handful of measurements and a lot of inference. In the model, all of it is available at low cost.
This matters most for loads. The loads on any single part depend on the dynamics of the whole machine. Study a part in isolation with loads someone cooked up in a spreadsheet and you can miss the failure mode that actually shows up in the field. A system model catches it, because the load path comes from the physics of the full machine, not from someone's guess.
And unlike a physical test, the model is repeatable and controlled. Test tells you what happened. A model that has been checked against that test tells you why, and what will happen under conditions you have not run yet.
The model also makes what-if questions cheap. Change a design parameter and the effect, and its sensitivity, shows up in hours. Asking the same question of the physical product means modifying hardware and retesting, at a time and cost that shuts most what-ifs down before they are ever asked.
Why MBD programs fail
I will tell you what the software vendors will not: many MBD programs fail, and I have watched it happen at small, medium, and large companies alike. The most common cause is overcomplication. The quest to simulate reality is not practical; time and budget almost never allow a trustworthy model at that level of detail. The effort stalls, results arrive too late to matter or get questioned to death, and simulation ends up lagging the design, merely validating decisions already made.
What happens next is predictable. The team retreats to simple assumptions, hand calculations, or stacked hand calculations in a spreadsheet, and the downward spiral starts: lack of confidence leads to improper use, improper use leads to missed deadlines, leadership loses faith in simulation, and the risk lands on the end product. The company concludes simulation does not work, when what failed was the approach.
After a meltdown like that, rebuilding credibility inside a company is a process measured in programs, not meetings. Avoiding it in the first place is much cheaper. That is the point of this page.
Right-size the model to the decision
The fix is discipline about scope: match the complexity of the model to the study or insight you are actually after, nothing more. The value sits just beyond the back of the envelope. A model with the mass properties, kinematics (how the parts connect and move), and dimensioning right, plus reasonable stiffness and damping, will typically get you 80 percent accuracy or better on the quantities that drive design decisions.
Damping, the property that governs how quickly motion in a system settles out, deserves the most care. Good damping data is hard to acquire, and the engineer has to make sound assumptions so the system is neither overdamped nor underdamped. That is judgment, and it is exactly the judgment that separates a useful model from a misleading one.
The standard I hold to is simple: reasonable results with the assumptions clearly stated beat no results at all. They especially beat perfect results delivered after the design is frozen, when nothing can change.
Start small, check against test, build
MBD earns a permanent place in a company the same way a new engineer does: by being right about small things first. The first model is right-sized to one decision the program actually needs. Its results get compared against what the hardware physically does in test, the gaps teach you where the model needs work, and those lessons, and the model itself, carry into the next project.
Each iteration builds knowledge and modeling technique. The models grow more capable because the team has earned that complexity, with test comparison backing every step up in detail. Small wins first: a load prediction that keeps a design off the wrong path, a motion study that settles a design argument before hardware is committed. Then the wins compound, and within a few programs MBD stops being an experiment and becomes an integral part of how the company gains insight, with prediction leading design instead of trailing it.
Most teams stop too early
Here is a pattern I see constantly: a serious effort goes into building the model, it gets run through a scenario or two, the results make it into a report, and everyone moves on. The investment was in building and checking the model. The runs that follow are nearly free. Stopping after two of them is like buying a machine tool and using it for one afternoon.
A built, trusted model opens the door to much more. Sensitivity studies find which inputs the outputs actually respond to, so design effort goes where it matters. Design of experiments, a structured sweep of runs covering the combinations that matter, maps the whole design space instead of poking at it. Optimization lets the computer search that space for the best design. None of this needs an engineer at the keyboard: it is set up once and runs overnight or over the weekend.
The team that comes in Monday morning to a mapped design space is getting a multiple of the return on the same modeling investment. That is the difference between a model that answered a question and a model that leads the design.
Proof from real programs
Two examples of right-sized simulation doing real program work. For Joy Global Surface Mining, simulation supported the engineering of an innovative hybrid mining shovel, validating new design and controls concepts in the model rather than spending excess money on tests; their engineering team says so in their own words on this site. For Stratom, an MBD model validated an autonomous tracked vehicle before the prototype was built, including transient stress (the momentary peak stresses in the structure as the machine operates), and the vehicle came in on time and under budget.
The judgment behind them comes from MBD work in MSC Adams stretching back to 1996, including work for Joy Global, Genie, Crown, Bosch, Oshkosh, Toro, Ricardo, Achates Power, Knapheide, and Caterpillar.
Read the tracked vehicle case study → • Read the skid steer case study →
Two Paths to the Capability
If the case for MBD holds for your program, the next decision is build versus outsource. Both paths work, and I support both. The trap is the third way: buy the software license, hand it to whoever has spare time, and figure it out alone. The license is not where the risk lives. The risk is in the judgment applied through it: what to model, what to leave out, what to assume, and when to trust the answer. That is where the failures above begin.
Build the capability in-house
Your engineers do the modeling and the capability stays with your company. My role is to keep the effort off the failure path: train the team, right-size the first models, audit models before results go to program leadership, and set up the process for checking models against test and carrying lessons forward so each project builds on the last. Choose this when simulation will be part of how you engineer for the next decade and you can commit engineers to it. Some teams start here on day one; others have me run the first program while their people ramp alongside. Over time you need me less. That is the goal.
Have DSIM run the simulation work
I build the models, make and state the assumptions, check them against your test data, and deliver loads and answers on your program schedule. You get senior-practitioner work without hiring for it or licensing anything, and everything is documented so the model keeps its value after the project ends. Choose this when you need results on the current program, when there is no headcount for a simulation group, or when an in-house effort has stalled and the schedule cannot wait for it to recover.
Common Questions
What is multi-body dynamics (MBD) simulation?
Multi-body dynamics simulation is a physics-based model of a complete machine, its masses, joints, and connections, that predicts how the system moves and what loads every part carries before hardware exists. The formulations come from classical mechanics, and a solver such as MSC Adams integrates the equations of motion. It is not mysterious; it is simply following physics.
Why use MBD simulation instead of hand calculations?
Hand calculations handle parts in isolation, but the loads on a part depend on the dynamics of the whole machine, so isolated calculations can miss the failure mode that actually occurs. MBD simulation predicts system-level performance and loads that cannot be measured or hand-calculated any other way, early enough to change the design. A right-sized model typically reaches 80 percent accuracy or better when mass properties, kinematics, and dimensioning are right and stiffness and damping assumptions are reasonable.
Should we build simulation capability in-house or outsource it?
Build in-house when simulation will be core to how you engineer for years to come and you can commit engineers to it; outsource when you need answers on the current program without hiring. The two paths combine well, with a consultant running early programs while your team ramps. The one approach that reliably fails is buying the software and figuring it out alone.
Why does DSIM use MSC Adams?
I have worked in most of the major multibody tools, Simpack, Simcenter 3D Motion, RecurDyn, MotionView, Project Chrono, and MATLAB Simscape among them, and I still use them when a program calls for it. In-house, DSIM standardizes on MSC Adams because it is the original and most widely used multibody dynamics code: its roots go back to a 1973 University of Michigan thesis, it has been commercial since the early 1980s, and it has been validated across decades of programs in every industry that builds machines. It can model and analyze virtually any mechanical system, and it has the largest user base in the field, which matters if you plan to build in-house capability later: Adams analysts are the easiest to hire.
Can we pilot MBD before committing to it?
Yes, and a pilot project is the right way to test the waters: a small, bounded engagement scoped to one real question your program needs answered. I do the work, so you buy no software and add no headcount, and the investment stays low. Run it results-only if you just need the answer, or open-book if you want to see what the multibody simulation workflow actually entails: your engineers follow the modeling and simulation process as it happens, which is more transparency than a typical black-box project and doubles as a first step toward building capability in-house. Either way, you end the pilot with a real answer and a clear read on what MBD can do for your programs.
When should we hire an MBD consultant?
Before the first model is built, or before a struggling effort hardens into a meltdown, because most failed simulation programs fail on approach rather than on software. A consultant who has seen the failure modes can right-size the models, set up comparison against physical test, and keep simulation leading the design instead of validating it after the fact.
Does MBD simulation replace physical testing?
No. How the physical product performs is the truth, and a good model is always compared to test and improved from it. What the model adds is everything you cannot practically instrument: every force, torque, and motion in the system, available at low cost, before the hardware exists.
Talk It Through Before You Commit
Deciding whether MBD belongs in your next program, or how to get a stalled effort back on track? Tell me about the machine and the decision you are trying to make, and I will give you a straight read on whether MBD will pay off, which path fits, and what a right-sized first model would look like.
Typically responds within 24 hours. Darren Simoni, DSIM.
info@dsimtech.com • Post Falls, Idaho, USA