2. Dummy model architecture in MADYMO
A MADYMO crash test dummy is not a single rigid body with a few springs attached. It is a hybrid model: a multibody (MB) skeleton carries the gross kinematics, while finite element (FE) parts supply deformable geometry wherever local deformation, contact pressure, or injury-relevant strain must be resolved. Understanding how these two worlds are stitched together — through joints, contact definitions, and a disciplined model tree — is the prerequisite for any credible validation work. If the architecture is wrong, no amount of tuning will produce a physically defensible response.
Multibody and FE: division of labour
In the MB portion, each segment (head, thorax, pelvis, upper and lower extremities) is represented by a rigid body with six degrees of freedom, reduced by kinematic constraints at the joints. Inertia is lumped at body centres of gravity, and the mass distribution is taken from the dummy hardware documentation. The FE portion typically covers the face, chest, abdomen, and sometimes the knee and lower leg, where a rigid representation would hide exactly the response the test is meant to measure.
The coupling between the two is the critical design decision. MADYMO supports several coupling strategies, and the choice determines both accuracy and cost:
- Rigid body to FE surface — the FE mesh is attached to a parent rigid body and inherits its motion; used for a deformable chest skin over a rigid thoracic spine box.
- Point-to-surface contact — MB contact points (ellipsoids, planes, facets) interact with FE surfaces; the standard mechanism for belt-to-chest and airbag-to-face loading.
- Surface-to-surface contact — FE outer surfaces interact directly, required when both bodies deform, e.g. abdomen against a belt.
- Kinematic attachment — an FE node set is tied to a rigid body reference point, transferring forces and moments through a defined attachment.
A common error is to attach an FE chest to the wrong parent body, so that the mesh follows the pelvis instead of the thorax. The symptom is a chest deflection trace that looks plausible in a frontal sled test but collapses in an oblique one. Always verify the parent body of every FE part before running anything.
Joint definitions
Joints define the kinematic chain and, just as importantly, the restraint torques that resist motion. Each joint in MADYMO is characterised by its type (spherical, revolute, translational, universal, bracket), its two connected bodies, its location and orientation in the parent body frame, and its stiffness/damping characteristics.
For a Hybrid III 50th percentile model, the typical chain is:
| Joint | Type | Primary function |
|---|---|---|
| Neck | Spherical + bracket | Head rotation with flexion/extension torque |
| Thorax–lumbar | Revolute | Spine bending, chest deflection coupling |
| Lumbar–pelvis | Spherical | Lower spine articulation |
| Hip | Revolute | Thigh swing, femur load path |
| Knee | Revolute + translational | Knee slider, tibia load transfer |
| Shoulder / elbow | Revolute | Arm positioning for belt routing |
Joint stiffness is not a free parameter. It must reproduce the certification-level torque-angle corridors from the dummy hardware specification. When you define a joint, you specify the characteristic curve as a function of relative rotation or translation, plus damping. A frequent pitfall is sign convention: MADYMO joint output is expressed in the joint coordinate system, which may not align with the global axes. Define your positive direction once, document it, and keep it consistent across the model and all post-processing scripts.
Contact interactions
Contacts are where the dummy meets the environment — belt, airbag, seat, steering wheel, and its own body segments. MADYMO contact is defined by a master surface and a slave surface (or point set), a contact stiffness, a friction coefficient, and a penetration limit. For MB-MB contact, ellipsoids and planes are the workhorses; for MB-FE and FE-FE, the FE surface nodes act as the slave set.
Two parameters dominate behaviour. First, contact stiffness: too soft and the belt sinks into the chest, producing excessive deflection; too stiff and the solution becomes unstable with high-frequency noise. A practical starting point is to set the stiffness so that maximum penetration stays below roughly 10% of the local characteristic length, then verify against the certification test. Second, friction: belt-to-clothing friction is typically 0.3–0.5, but the value must match the test setup, because a change from 0.3 to 0.5 can shift chest deflection by several millimetres.
Model tree organisation
A MADYMO input deck is hierarchical. The top-level SYSTEM contains BODY definitions, each with its own JOINT, GEOMETRY, INERTIA, and FE_MODEL entries. Contacts are declared at system level and reference bodies by name. A clean tree makes debugging tractable:
SYSTEM dummy
BODY head
INERTIA mass=4.54 Ixx=... Iyy=... Izz=...
GEOMETRY ellipsoid ...
JOINT neck type=spherical parent=thorax
BODY thorax
INERTIA mass=17.2 ...
FE_MODEL chest_skin file=chest.fem parent=thorax
JOINT lumbar type=revolute parent=pelvis
BODY pelvis
INERTIA mass=...
CONTACT belt_chest master=belt slave=chest_skin mu=0.4
CONTACT head_airbag master=airbag slave=head mu=0.3
Name every body and contact explicitly. Anonymous indices are impossible to audit six months later, and a validation report that cannot be traced back to a named contact is not a validation report.
Verifying the architecture before validation
Before comparing any response to test data, run a structural audit. Check that every FE part has a valid parent body and that the parent matches the physical dummy segment. Confirm that joint locations and orientations reproduce the hardware drawing within a few millimetres. Verify that contact definitions reference the intended surfaces and that friction and stiffness values are documented, not defaulted. A quick sanity run — gravity settling, then a slow belt pull — will reveal mis-parented FE parts, inverted joint axes, and contacts that never engage.
Once the tree is clean, the model becomes auditable: every response can be traced to a named body, a named joint, and a named contact. That traceability is what separates a validated dummy model from a plausible-looking animation.