Ask a structural engineering student fresh out of building-design coursework to explain a moving load, and you’ll usually get a vague answer about “traffic” or “vehicles.” That vagueness is exactly the gap this article closes. Moving load analysis — sometimes called live load analysis or influence-line analysis, depending on which textbook you learned from — is the single concept that most clearly separates bridge engineering from general structural design, and it’s also the concept that trips up the most capable building-design engineers when they first move into bridge work.
In building design, most of your load analysis deals with loads that sit in fixed positions: a slab’s self-weight, a partition wall, snow sitting on a roof. You calculate the load, apply it where it physically sits, and solve for the structure’s response. The position of the load is a known, fixed input.
A vehicle crossing a bridge is a fundamentally different kind of problem. The same 40-tonne truck produces a different bending moment, a different shear force, and different deflection depending on exactly where it currently sits along the span — right at midspan, near a support, or somewhere in between. Worse, on a multi-span or continuous bridge, a truck’s position can create the worst-case condition for one part of the structure while barely affecting another part at the same instant. A single “load case” the way building engineers think about it doesn’t exist here. You need to analyze the structure’s response as the load’s position sweeps across the entire span, and then design for the worst value that shows up anywhere in that sweep, for every structural element separately.
This is why bridge engineers talk about influence lines and envelopes rather than single load cases. An influence line shows how a response quantity (say, the bending moment at a specific point) changes as a unit load moves across the span. An envelope takes the worst value of that response across every point along the span, for every element you care about. Nothing about this exists in a typical building design workflow, which is exactly why it feels foreign the first time you encounter it.
Rather than trying to model every possible real truck that might ever cross a bridge, bridge codes define a standardized, idealized load model calibrated to produce realistic worst-case effects. The best-known example, and the one most bridge engineering education references even outside the US, is AASHTO’s HL-93 model. It’s worth understanding its actual components, because almost every software workflow you’ll touch is built around a model shaped like this one.
| Component | What It Represents | Key Values |
|---|---|---|
| Design Truck | A notional 3-axle truck configuration | Total weight 72 kips (~32 tonnes); axle spacing and weights fixed by the code |
| Design Tandem | A pair of closely-spaced heavy axles, used instead of the truck on short spans | Two 25-kip axles spaced 4 ft apart |
| Design Lane Load | A uniform load representing the background traffic stream around the critical vehicle | 0.64 kips per linear foot, spread over a 10 ft width |
| Dynamic Load Allowance | An amplification factor applied to the truck/tandem (not the lane load) to account for vehicle bounce and road roughness | 33% — higher than the roughly 25% research suggests for real vehicles, because the model itself is already a simplification |
Two things matter about this model that aren’t obvious from the numbers alone. First, HL-93 is explicitly described in the AASHTO LRFD specification as a notional load — it isn’t meant to represent any specific real truck on the road. It’s a calibrated abstraction, tuned using weigh-in-motion data from actual traffic (the original calibration work referenced the Ontario Ministry of Transportation’s truck weight data), so that the load effects it produces match realistic worst-case scenarios without engineers needing to model every conceivable real vehicle combination.
Second, which part of the model actually governs changes depending on span length. On short spans, the tightly-spaced design tandem tends to produce the worse effect, combined with the lane load. On medium spans, the design truck typically governs instead. On continuous multi-span bridges, engineers also have to check a double-truck case — two design trucks positioned to create the worst negative moment over an interior support, reduced to 90% of their individual effect when combined with 90% of the lane load. None of this is intuitive from first principles; it’s the product of decades of calibration against real bridge behavior, which is exactly why bridge-specific training, rather than general structural engineering intuition, matters here.
Here’s a genuinely important honest point that gets glossed over in a lot of online bridge-engineering content aimed at this region: there isn’t one single, universally mandated bridge load code across the UAE or the wider Gulf. In practice, projects reference either American standards (AASHTO LRFD, built around the HL-93 model above) or British standards (historically BS 5400, with HA and HB load models), depending on the client, the design consultant’s background, and the specific authority overseeing the project. Neither approach is “wrong” — both are internationally recognized, rigorously calibrated codes — but they are not interchangeable, and a bridge design built correctly under one framework cannot simply be re-labeled as compliant with the other.
This distinction matters more than it might seem. Comparative studies looking specifically at UAE-relevant bridge loading have found that British live load models (HA and HB) tend to produce heavier design loads than HL-93, and that British service-load criteria can be more conservative too. Because of that gap, some authorities working under US-style codes in this region have historically applied an increase — commonly cited around 50% above the baseline HL-93 design load — specifically to close the difference with British practice. If you’re a student or early-career engineer in the UAE, the practical lesson isn’t “memorize one code.” It’s: learn to recognize which load framework a given project specifies, understand that the numbers genuinely aren’t interchangeable, and never assume your training on one system automatically transfers its exact numerical results to the other.
Having walked many engineers through their first real bridge load analysis, a handful of mistakes show up again and again:
The single most common error: applying the design truck or tandem at one position (usually midspan, because that’s the building-design instinct) and calling it done. Midspan is often close to the governing position for simple spans, but it is not automatically correct, and on continuous or irregular spans it frequently isn’t the governing position at all.
The 33% dynamic load allowance applies to the truck and tandem components — not to the uniform lane load, which is already meant to represent a steadier background traffic stream. Applying it to the whole combined load overstates the design condition; forgetting it entirely understates a real dynamic effect.
Short-span tandem-governed behavior, medium-span truck-governed behavior, and continuous-span negative-moment double-truck checks are genuinely different calculations with different governing positions. Skipping straight to whichever case feels most familiar, instead of systematically checking which case actually governs for your specific span and element, is a real and recurring source of under-designed details.
As covered above, pulling a load value memorized from AASHTO training and applying it on a British-standard project (or vice versa) produces numbers that look plausible but aren’t actually compliant with either code properly applied.
Once you understand what influence lines and load envelopes actually require — sweeping a load model across every position along a span, for every structural element, under every governing case, sometimes across multiple spans simultaneously — it becomes obvious why hand calculation stops being practical past a textbook example. Purpose-built software like Autodesk Structural Bridge Design automates exactly this: you define the geometry and the load model once, and the software runs the moving-load sweep, builds the envelopes, and flags the governing positions and combinations automatically, across every case the relevant code requires.
This isn’t about the software doing your engineering judgment for you — you still need to understand what HL-93 actually represents, why the dynamic load allowance applies selectively, and which governing case matters for your specific bridge, in order to sanity-check what the software gives you. What the software removes is the impractical manual burden of running that sweep by hand across every position and every case. Engineers who understand the underlying concept get genuinely faster and more reliable results from the software; engineers who treat the software as a black box tend to miss exactly the kind of governing-case mistakes listed above, because the software will faithfully calculate whatever load case you set up — including a wrong one.
One detail that rarely gets enough attention in introductory material: the governing position of a moving load isn’t the same for every element of a bridge. A position that produces the worst bending moment in the main girder at midspan is not necessarily the position that produces the worst shear near a support, and it’s rarely the position that produces the worst local effect on a deck slab or a bearing.
| Bridge Element | What Typically Governs | Why It’s Different From the Girder Moment Case |
|---|---|---|
| Main girder, midspan moment | Design truck or tandem plus lane load, positioned near midspan | This is the case most beginners default to, and it’s the one most bridge-design intuition is built around |
| Main girder, shear near support | The load positioned close to the support itself, not at midspan | Shear and moment are governed by different load positions on the same span — treating one as a proxy for the other is a common error |
| Deck slab (local/punching effects) | A single wheel or axle positioned directly over the slab panel being checked | This is a local effect driven by a wheel load footprint, not the full vehicle or lane load used for the global girder check |
| Bearings | Combination of vertical reaction and any horizontal braking/traction load from the moving vehicle | Bearings see load effects the girder moment check doesn’t directly address at all |
In practice, this means a complete bridge design or rating exercise isn’t one moving-load sweep — it’s several, each targeting a different element and often a different governing position, even though they all derive from the same underlying load model. Software handles running each of these sweeps efficiently, but understanding that they’re genuinely different checks, not the same calculation repeated, is what keeps an engineer from assuming that a safe girder moment result automatically means every other element of the bridge is fine too.
If the influence-line concept still feels abstract, a useful mental exercise is to imagine walking a single point load slowly across a simply-supported span, one position at a time, and asking at each position: what’s the bending moment directly under the load right now? For a simple span, that value starts at zero at one support, rises to a maximum somewhere near midspan (the exact peak position depends on the span’s loading details), and falls back to zero at the far support. That rising-and-falling curve, for one specific response quantity, is an influence line.
Now imagine doing that same exercise for the truck’s individual axles instead of a single point load, all moving together, and asking at each step: what’s the combined moment effect of all the axles at their current positions? The worst value that shows up anywhere during that walk-through is the governing moment for that case. This is conceptually exactly what the software automates — it just does it far more precisely, and for every section along the span simultaneously, rather than you manually stepping a load across one position at a time.
If you’re coming from a building-design background, the honest starting point is to unlearn the instinct that a load case means “apply it here and solve.” Spend real time with influence lines before you touch bridge analysis software at all — understanding conceptually why a load’s position changes the governing response, and why that governing position changes depending on which element you’re checking, is what makes everything the software shows you make sense, rather than feeling like output you have to trust blindly.
Orbit’s Structural Bridge Design course in Dubai is built specifically around this gap — starting from the moving-load concept itself, not just the software’s menus, so you understand why a governing case is governing before you ever rely on an automated envelope to tell you so. For engineers moving from general structural work into bridge-specific roles in the UAE, that conceptual grounding is consistently what separates someone who can run the software from someone who can actually be trusted with the engineering behind it.
The UAE doesn’t mandate a single national bridge load code. Projects commonly reference either AASHTO LRFD (built around HL-93) or British standards, depending on the client and consultant. Always confirm which framework a specific project specifies rather than assuming.
An influence line shows how one specific response (like the moment at one point) changes as a load moves across the span. An envelope takes the worst value of that response across the whole sweep, for a given element — it’s the practical design output; the influence line is the conceptual tool used to understand how you get there.
You don’t need to hand-calculate every case for real projects — that’s genuinely impractical past simple examples — but working through the concept by hand at least once is what makes the software’s output meaningful to you rather than a number you’re trusting on faith.
The lane load represents a steadier, distributed stream of background traffic rather than a single bouncing vehicle, so the bounce-and-roughness amplification that applies to the discrete truck or tandem doesn’t apply to it the same way.
Yes, with a different load model — pedestrian bridges use crowd-loading models rather than HL-93-style vehicle loads, but the same underlying concept (a load whose position changes the governing structural response) still applies, just with different numbers and different governing patterns.
Because the moving load’s governing position is different for each of these — a position that maximizes midspan moment in the girder is not the same position that maximizes shear near a support or local slab effects under a single wheel. Treating one check as a stand-in for the others is a common and risky shortcut.
Not very — the point of a rough manual sanity check (walking through roughly where the governing position should fall and roughly what order of magnitude the result should be) is to catch setup errors, not to replace the software’s precise calculation. If your rough intuition and the software’s output are in the same ballpark and the governing position makes conceptual sense, that’s enough to move forward with reasonable confidence.
