BMS today models one kind of bridge: girders dropped span-by-span onto ordinary piers. The client has sent a GAD for a bridge that does not work that way — tall pylons at four of its piers, with fans of stay cables holding up the deck. This brief covers what we add, where it goes, and what not to touch.
Four things in this drawing have no equivalent anywhere in BMS today.
A tower rising from the pier, far taller than any pier wall, cast in lifts. Split into a lower pylon (pile cap → deck) and an upper pylon / mast (deck → top). Structurally it behaves like a very tall pier wall — so the height-based partial-progress logic we already have is directly reusable.
High-strength cables from the pylon head down to the deck, installed and stressed in sequence. Each cable passes through four stages, exactly like the existing Girder cast → stress → launch model, just with one more step.
P2–P5 carry pylons. P1, P6, P7, P8 are ordinary piers. BMS has never had to say "this component applies only at these locations." This is the single biggest modelling change and is solved on page 1.
The GAD specifies Ø1500 bored piles at pylon piers versus Ø1200 at ordinary piers, with much denser pile clusters. No new component — but confirms pylon supports are configured separately.
Exactly which section gains which field, which dropdown gets which new value — and what to leave alone.
Component master, plan generation, progress entry, roll-ups, weightage, reports, mobile — plus the traps.
Live, working SVG examples with the actual coordinate maths. Switch between fan / semi-fan / harp and see the difference.
Each shape in three views, with a real Indian reference bridge — including Sudarshan Setu in Gujarat.
How spans, supports, decks and girders are counted when the two are mixed on one bridge, with a live quantity roll-up showing exactly what plan generation must produce. Contains two defects in the current quantity logic — Pier Wall counting pylons, and Cross Girder hardcoded to one per span.
Everything in this brief is designed on assumptions because the client has not yet answered the questions raised on 25-09-2026. Each assumption is flagged where it appears. These are the ones that could change the design if answered differently.