Aerospace Multi-Level Assemblies: Scheduling Sub-Assemblies That Feed the Line

Aerospace multi-level assembly scheduling expands each sub-assembly into its own routing, links it into the parent's dependency graph, and rolls its hours up through every level, so EDGEBIC by User Solutions schedules the whole build tree as one connected plan. For an aerospace program, the assembly line is the tip of a pyramid of feeders, and a plan that only sees the top level is blind to the sub-assembly that will make the whole thing late. This post is about scheduling the pyramid, and reading its true hours.

The dependency machinery this rests on is described in what is production scheduling, and the everyday difficulty of coordinating many interdependent jobs is job shop scheduling challenges. Aerospace just stacks those dependencies several levels deep.

The problem with scheduling only the final line

A complex airframe or engine component is not one routing. It is a top-level assembly that consumes sub-assemblies, each of which is its own product with its own routing, sometimes three or four levels down. The top-level line cannot start joining until its feeders exist, and each feeder cannot start until its own children exist.

A plan that only models the final assembly treats those feeders as material that magically appears. It cannot tell you that the bracket sub-assembly is two weeks behind, or that a base plate feeding two different sub-assemblies is the real constraint. So the line looks fine on the board right up until it goes idle waiting for a part nobody was tracking. In a program that runs for months, that surprise is expensive, and it is entirely avoidable if the schedule sees every level.

Expanding sub-assemblies into one connected plan

The routing model handles this directly. A routing step can point at a work center, as usual, or it can point at another product, marking it as a sub-assembly rather than an operation. When the scheduler meets that reference, it expands the sub-assembly into its own routing steps, re-keys them so they stay distinct even when several sub-assemblies share the same work centers, and wires them into the parent's dependency graph.

That graph is the heart of it. Each step declares its successor through a next-in-sequence link, and the scheduler builds a directed graph of "this cannot start until that finishes." A genuine topological sort orders the whole tree so that every step is scheduled after the steps it depends on, regardless of what order they were entered in. The top-level assembly step lands only after every feeding step it depends on has completed.

The assembly waits for the slowest feeder

The join logic is where multi-level plans earn their keep. When two feeder paths point at the same assembly step, each writes its finishing time under that step's key, and the later time wins. So the assembly waits for whichever feeder finishes last, not the first, and not an average.

Take two preparation paths joining at one assembly step: one path runs 40 hours on one machine, the other runs 60 hours on a second machine, both starting Monday.

The assembly correctly waits for the 60-hour path. Neither the planner nor a spreadsheet had to reason about which feeder was critical; the graph did it. Shared feeders that fan out to several parents are handled the same way, with unique per-step keys so one sub-assembly's finish is never mistaken for another's.

Reading the true hours of a deep assembly

There is a quieter failure that multi-level products cause: the hours come out too low. If an estimate only sums the top-level routing's own steps, a sub-assembly reference contributes its material cost but its work hours vanish. A product whose entire effort lives in its feeders reads near zero hours, and any quote built on that number underprices the job badly.

The rollup fixes it by recursing. It walks up through every sub-assembly, summing hours, labor, and material at each level, respecting how many of each child go into each parent, and guarding against a data-error loop so it always terminates. A worked case from the regression suite resolves a product through a bracket assembly to a base plate at 22.5 hours per unit, which becomes 225 hours at a quantity of ten. Every level counts, nested references included and repeated references counted once per use.

That single source feeds both the estimate on a quote and the order cost analysis, so a deep aerospace assembly shows its real manufacturing effort before the first part is cut. The mechanics of turning that effort into a lead time and price are covered in quote simulation, which applies the same finite-capacity model to a full build tree.

Rescheduling a partly-built tree

Aerospace programs run long, and by the time you reschedule, part of the tree is already built. The engine handles this by freezing completed work. Any step with a recorded actual end date is not re-opened; its end time seeds the plan directly, and only the remaining steps are re-placed on the calendar. A sub-assembly that is finished stays finished, and the top-level assembly resumes from where the real work left off rather than from the job's original start.

Completed work is never moved by a reschedule. That guarantee matters most exactly here, on a multi-month build where a hot order or a design change forces a replan and you cannot afford to have the plan pretend that a finished sub-assembly is available to move. It is the same actuals discipline that underpins routing snapshots for aerospace, which preserve the exact routing each job was built to.

Where multi-level scheduling meets TOC and certification

The build tree does not schedule in isolation. When a bottleneck work center sits inside the tree, aerospace shops anchor the whole plan around it, scheduling feeders backward to feed the constraint on time and downstream steps forward from it. That anchor logic, covered in theory of constraints scheduling for aerospace, sits directly on top of the dependency graph described here. And the operators who build the sub-assemblies carry certifications the plan respects, so a feeder that needs a qualified inspector waits for one, the same labor constraint that shapes every aerospace line.

This is the multi-level discipline User Solutions has brought to complex, regulated production since 1991, in programs sequencing tens of thousands of interdependent tasks for defense and aerospace customers. A plan that sees every level of the build is the difference between managing a program and reacting to it.

See it schedule your deepest assembly. Bring a multi-level routing to a demo and watch the whole tree land as one connected plan, with the top-level line waiting on exactly the feeder that constrains it. The EDGEBIC by industry guide puts this in context with the rest of an aerospace shop's needs.