Systems Engineering at the Edge: How Commercial Satellite Servicing Is Rewriting the Rules

The satellite servicing industry has a requirements problem that no legacy methodology was designed to solve. When Northrop Grumman’s Mission Extension Vehicle-1 docked with Intelsat 901 in February 2020, it completed the first commercial life extension of a geostationary satellite. What got less coverage than the milestone was what it took to get there: years of systems engineering work against a spacecraft whose publicly available documentation was incomplete, whose hardware had aged in ways that ground testing cannot fully replicate, and whose operators were simultaneously a customer and a source of critical interface data that they themselves were uncertain about.

That is not an edge case in this industry. That is the industry.

Satellite servicing — encompassing life extension, refueling, inspection, active debris removal, and eventual deorbit — is now a real commercial market, not a research program. Northrop Grumman has flown multiple MEV missions. Astroscale has demonstrated magnetic capture technology in orbit. D-Orbit, ClearSpace, and others are advancing toward operational debris removal. The engineering achievements are genuine. So are the systems engineering challenges that produced them, and those challenges are instructive for anyone building complex systems that must interface with hardware they did not design and cannot fully characterize.

The Undefined Interface Problem

Classical systems engineering treats external interfaces as something you negotiate. You write an Interface Control Document, both parties review it, you resolve conflicts, and the interface becomes a defined boundary condition that both systems are designed to satisfy. That process assumes both parties exist, have engineers available, and have incentive to cooperate.

Servicing a satellite launched in 2001 violates all three assumptions simultaneously.

The client spacecraft was designed to interface with its launch vehicle, its ground station network, and its own payloads. Nobody specified an apogee kick motor nozzle geometry for docking because nobody was docking to it. Nobody documented the structural load paths around that nozzle for anything other than nominal propulsion loads. Nobody characterized how the thermal blanket might degrade over twenty years of thermal cycling in GEO.

The servicer’s requirements team therefore faces a category of problem that is poorly handled by document-centric requirements tools: the unknown-unknown interface. You cannot write a complete set of interface requirements when you do not know the full state space of what you are interfacing with. What you can do — and what MEV and Astroscale have demonstrated — is replace completeness with bounding. Instead of specifying the interface precisely, you specify the range of interface conditions your servicer must survive, capture, and operate within.

This sounds straightforward. It is not. Bounding an interface you did not design requires you to:

1. Reconstruct the original design intent from whatever documentation exists, knowing that documentation may have been revised, lost, or never completed to the level you need.
2. Model twenty or more years of on-orbit degradation for materials, mechanisms, and propellant systems, using data that is partially inferred from telemetry, partially from analogous spacecraft, and partially from physics models.
3. Define “worst case” states for an interface where the true worst case may be outside your model’s validity range.
4. Write requirements that are verifiable — meaning your GNC and mechanisms teams can actually test to them — while remaining conservative enough to cover what you do not know.

The MEV program addressed this partly through extensive analysis and partly through hardware designed to tolerate interface uncertainty. The MEV docking system captures the client’s apogee engine nozzle using a probe that can accommodate variation in nozzle geometry, attitude, and structural compliance. The systems engineering expression of that design choice is a requirements document with unusually wide tolerance bands on interface geometry — tolerance bands that were themselves derived from a probabilistic model of how much the nozzle geometry might have varied from nominal across the fleet of candidate client spacecraft.

That is requirements engineering under genuine uncertainty, and most of the tools the industry uses were not built for it.

Proximity Operations Safety Cases: Certifying the Uncertified

Beyond the interface problem, satellite servicing creates a safety case challenge that is arguably more structurally difficult: there is no established regulatory framework for proximity operations in GEO or LEO debris removal.

For a launch vehicle, you have a mature safety approval process. For a geostationary communications satellite, the ITU coordination process, FCC licensing (for US operators), and insurance underwriters’ requirements collectively define a safety envelope, however imperfect. For a spacecraft that intentionally maneuvers to within meters of another spacecraft that it did not launch with, and then physically contacts that spacecraft, none of those frameworks fully apply.

What this means in practice is that servicer operators are not submitting their safety cases to a regulator who will evaluate them against known criteria. They are submitting them to regulators who are, simultaneously, evaluating the mission and developing the criteria for evaluating it. The FAA’s Office of Commercial Space Transportation has been working through this problem for years. The FCC has weighed in on debris removal licensing. But the frameworks are incomplete, and operators know it.

The systems engineering consequence is significant. When your safety case must be convincing to a regulator who does not yet know what they require, you have two choices: build a safety case that is conservative enough to survive any plausible set of criteria, or engage the regulator early enough to shape what the criteria become. The companies doing this well are doing both.

Astroscale’s approach to the ELSA-d demonstration mission is instructive. The mission was structured to generate safety-relevant data — on capture dynamics, on relative navigation accuracy, on abort scenario performance — that could feed directly into the regulatory conversation, not just satisfy an existing checklist. The safety case and the mission design were co-developed, with the mission architecture deliberately including failure scenarios that would build regulator confidence rather than scenarios that only demonstrated nominal success.

That is a sophisticated systems engineering posture: using mission design as a tool for safety case development, rather than treating safety cases as a post-design verification exercise.

The Northrop Grumman MEV Approach: Engineering to a Probabilistic Interface

What Northrop Grumman’s Space Logistics division did with the MEV program deserves more detailed examination, because it represents a coherent systems engineering philosophy for missions with undefined client interfaces.

The MEV captures its client by inserting a probe into the client’s liquid apogee engine nozzle. The probe mechanism was designed to accommodate nozzle cone angles, surface conditions, and structural compliance across the full range present in the Intelsat and other GEO satellite fleets — not just the specific client for MEV-1. The requirements were written to cover a class of clients, not a single spacecraft, because the business model required reuse.

This has a direct requirements implication: the interface requirements document had to capture a probability distribution, not a point specification. The mechanism had to work with nozzle geometries that varied by some characterized amount, with surface oxidation and contamination in some characterized range, with structural stiffness that varied based on propellant load (the target satellite’s tank may be partially or fully depleted) and temperature. Every one of those parameters had to have a bounded range derived from analysis, and every one of those ranges had to be verified through testing that actually covered the extremes.

The GNC requirements for proximity operations followed a similar structure. The relative navigation system had to perform under the full range of client tumble rates that an end-of-life GEO satellite might exhibit — including spacecraft that were nominally operational but degraded, spacecraft that had lost attitude control entirely, and spacecraft in controlled safe mode configurations. Each of those cases generated distinct GNC requirements, and all of them had to be satisfied simultaneously.

The test program for MEV was correspondingly larger than a comparably complex non-servicing mission would require. When your requirements have wide tolerance bands because your interface is uncertain, your verification matrix grows proportionally. You cannot spot-check the middle of the envelope and call it done.

Astroscale and the Interface Standardization Bet

Astroscale’s approach to the interface problem is structurally different from MEV’s, and more forward-looking for the debris removal use case. Rather than engineering a servicer to accommodate an arbitrary interface, Astroscale has been working to standardize the interface before the client spacecraft launches.

The ELSA-d mission used a docking plate — a simple ferromagnetic target — that was attached to the client satellite before launch. The servicer uses magnetic capture to grapple the plate. The systems engineering complexity of the capture is dramatically lower than MEV’s nozzle-probe approach, because the interface is fully specified and the servicer was designed to that specification.

The business model implication: this only works for future satellites that agree to fly the docking plate. For existing debris — the Envisat-class objects that represent the highest debris risk — you still need an uncooperative capture capability. ClearSpace’s ClearSpace-1 mission, targeting an Ariane rocket body, is pursuing that harder problem.

But Astroscale’s approach shows something important about how requirements complexity can be managed across a system boundary. If you have any influence over the interface specification before the client hardware is built, use it. Every requirement you can place on the interface before launch is a requirement you do not have to bound probabilistically after launch. The systems engineering cost of adding a docking plate to a new satellite build is trivial. The systems engineering cost of characterizing a random structural feature on a 20-year-old spacecraft as a docking interface is enormous.

This is a pattern that shows up across complex systems engineering problems: upstream interface definition is always cheaper than downstream interface reconstruction. The satellite servicing industry is discovering this at scale.

What This Demands of Requirements Management

The requirements challenges in satellite servicing — probabilistic interface bounds, co-developed safety cases, wide-tolerance verification matrices — expose the limits of document-centric requirements management. When requirements have statistical properties, a spreadsheet or a flat document does not capture those properties. When requirements are co-developed with regulators over multiple years, the traceability of requirement evolution matters as much as the current requirement state.

Modern graph-based requirements tools handle this better than legacy systems precisely because they can represent requirements as nodes with relationships to the analysis artifacts, test results, and regulatory correspondence that define them. The requirement is not a static sentence in a document; it is a node in a model that links to the probabilistic analysis that established its tolerance band, the test cases that verify it, and the safety case argument that depends on it.

Tools like Flow Engineering, which build traceability as a native graph structure rather than a linked-document overlay, make it tractable to navigate the kind of deep, multi-directional traceability that satellite servicing programs require. When a regulator asks why a particular GNC mode boundary was set where it is, and the answer lives in a chain that runs from system requirement through interface analysis through subsystem requirement through test result through safety case argument, you need a tool that can traverse that chain, not a human who remembers where the documents are.

The broader industry is moving in this direction, but legacy programs still carry enormous document-based requirements debt. New entrants in satellite servicing — companies without twenty-year-old DOORS databases to maintain — are in a position to adopt graph-native approaches from the start, which is a genuine competitive advantage when the requirements problem is as complex as this one.

Honest Assessment: What the Industry Has Not Solved

The satellite servicing industry has demonstrated real engineering capability. MEV proved GEO life extension. Astroscale proved magnetic capture. These are not small achievements.

But the systems engineering maturity of the industry is still developing. Several problems remain genuinely unsolved:

Uncooperative capture at scale. MEV works because the client is cooperative — it maneuvers to meet the servicer, it provides telemetry, its operator is in the loop. Debris removal requires capturing objects that are tumbling, non-cooperative, and have no operator. The GNC and mechanisms requirements for that mission type are harder by an order of magnitude, and no mission to date has fully demonstrated it on a large debris object.

Regulatory framework stability. Safety cases written for missions flying in 2027 are being written against regulatory frameworks that will continue to evolve. That creates requirements volatility that is difficult to manage in any tool.

Liability allocation. If a servicing mission damages the client spacecraft, who is liable? The legal frameworks are underdeveloped, and the systems engineering consequence is that risk margins are conservative in ways that may not be technically necessary, because the programs are self-insuring against legal uncertainty as much as technical uncertainty.

Multi-client reuse. The MEV business model depends on serving multiple clients with the same vehicle. Each new client requires a re-characterization of the interface — not a full redesign, but a non-trivial analysis effort. The scalability of the model depends on reducing that per-client engineering cost over time.

None of these are reasons to be pessimistic about the industry. They are reasons to be clear-eyed about where the hard engineering work still is.

The Broader Lesson

Satellite servicing is an extreme case of a problem that appears wherever complex systems must interface with hardware they did not design: the interface you did not specify will cost you more than the interface you did. The satellite servicing industry is paying that cost at scale, and paying it in the currency of systems engineering complexity.

The companies navigating it best are the ones treating requirements engineering as a first-class engineering discipline — not a documentation exercise, but a modeling problem. They are defining interface bounds probabilistically, co-developing safety cases with regulators, and building traceability structures that can survive the multi-year, multi-stakeholder evolution that missions of this type require.

For the systems engineering community more broadly, satellite servicing is a useful stress test. The tools, methods, and mindsets that work here will work almost anywhere. The ones that do not work here are probably carrying more legacy debt than their users realize.