Landing is only the beginningThe engineering and operational lessons we must learn before building a sustainable presence on the Moonby Robert Kelso
|
| The next evolution in lunar exploration will require us to think beyond the individual landing event. |
But as the space community looks toward larger cargo landers, human-rated vehicles, and eventually a permanent lunar presence, I believe we need to broaden the way we think about lunar landing systems.
We are not simply developing spacecraft that can land on the Moon. We are developing the transportation systems, operational capabilities, and supporting infrastructure that will enable a sustained human presence on the Moon.
That distinction is important. A lander that successfully completes one mission has demonstrated an important capability, but it has not necessarily demonstrated that its design, operational architecture, and supporting infrastructure can accommodate repeated landings, departures, cargo deliveries, and human activities in the same general area.
The next evolution in lunar exploration will require us to think beyond the individual landing event. Having served as a NASA Space Shuttle Flight Director, managed flight safety and mission assurance activities, and subsequently managed commercial lunar lander development, I see several engineering and operational lessons that deserve particular attention.
Design for sensor failures, not just nominal performance
One of the most important engineering challenges during lunar descent is maintaining a sufficiently accurate navigation solution as the vehicle transitions from low lunar orbit through powered descent and touchdown.
A lander's guidance, navigation, and control (GNC) system depends on multiple sensors performing different but complementary functions. These can include inertial measurement units (IMUs), radar or laser altimeters, Doppler LIDAR, optical navigation, terrain relative navigation (TRN), and hazard detection and avoidance (HDA) systems.
The engineering challenge is not simply to install redundant sensors. It is to ensure that the navigation architecture provides overlapping functional coverage throughout the descent profile.
Consider the loss of an individual sensor during a critical phase of descent. Can the vehicle continue to navigate, maintain acceptable landing accuracy, and safely complete the landing? Does another sensor provide the necessary information? Can the flight software recognize the failure, isolate the faulty measurement, and transition to an alternate navigation solution? These questions must be addressed during architecture development, not left to be resolved during flight operations.
I would argue that single-fault tolerance should be a fundamental design objective for critical landing functions, consistent with the mission's risk posture. Redundancy must also account for common-mode failures. Two sensors that share the same vulnerability do not necessarily provide meaningful protection.
The final portion of descent introduces another complication. The lander's own rocket exhaust interacts with the lunar surface, creating a dust and ejecta environment that can degrade optical measurements and other surface-referenced sensors.
| Autonomy should improve landing reliability, not introduce another single point of failure. |
Depending on the vehicle configuration and sensor placement, some measurements may become unreliable during the final tens of meters. The navigation system may have to rely increasingly on inertial propagation and whatever independent measurements remain available.
An IMU can propagate the navigation solution, but it does not eliminate accumulated position and velocity uncertainty. The system must therefore be designed to understand and manage that uncertainty through touchdown.
Autonomous landing capability is essential, particularly when approaching challenging terrain. However, autonomy must be accompanied by robust fault management, sensor independence, and a well-understood degraded operating capability. Autonomy should improve landing reliability, not introduce another single point of failure.
The lunar surface is not just a landing destination
There is another engineering issue that I believe will become increasingly important as we transition from individual lunar missions to sustained surface operations: the effects of rocket exhaust and regolith ejecta on surrounding infrastructure.
When a lander's descent or ascent engines operate near the lunar surface, the exhaust plume interacts with the loosely consolidated lunar regolith. Particles are accelerated outward at extremely high velocities.
Analyses of lunar plume-surface interactions have considered particle velocities approaching 2,000 meters per second. But the velocity is only part of the problem. We must also understand the geometry and distribution of the ejecta.
These tiny particles can be transported in a dense dust sheet that radiates outward at approximately one to three degrees above the horizontal lunar surface, depending on the vehicle and plume conditions.
At engine cutoff, the outer boundary of this dust sheet is defined by the distribution and trajectories of the ejecta. The sheet can continue outward and literally sail over the lunar horizon.
Consider the implications. Any flight hardware or infrastructure within the line of sight of this hazardous dust sheet could be exposed to an extraordinarily destructive environment. The image I often use to describe this phenomenon is that of a high-velocity sandblaster operating across the lunar surface.
Solar arrays, habitats, communications antennas, rovers, scientific equipment, and other exposed hardware could be severely damaged or rendered unusable by the abrasive and impact effects of these particles.
The Apollo 12 landing near Surveyor III provided an early physical demonstration of the effects of lunar module exhaust on previously deployed equipment. The implications become much more significant when we contemplate repeated landings and departures in support of a common lunar base.
During Apollo, each landing was essentially an individual mission event. A future Moon Base will be different. We may have multiple cargo landers, crewed landers, ascent vehicles, habitats, power systems, and surface mobility assets operating within the same general region.
| The space community must distinguish between testing that can be streamlined and testing that is essential to demonstrating mission success. |
We cannot assume that a landing location suitable for one mission will remain suitable for repeated operations without considering its effects on surrounding infrastructure. This suggests that landing-site selection must eventually become part of an integrated lunar surface architecture.
We will need designated landing and ascent zones, adequate separation from critical infrastructure, and an understanding of the effects of repeated plume interactions with the surface. The location of habitats, power systems, communications equipment, and other assets must be considered in relation to where vehicles land and depart.
In other words, we must design not only for where a lander touches down, but also for where its exhaust-driven ejecta goes. This is not simply a lander design issue. It is a lunar infrastructure and operational planning issue.
Mission assurance cannot be traded away casually
Another important lesson concerns the relationship between development cost, schedule pressure, and mission assurance.
Commercial space programs operate under considerable pressure to accelerate development and control costs. That pressure is understandable. However, the space community must distinguish between testing that can be streamlined and testing that is essential to demonstrating mission success.
We cannot fully reproduce the lunar environment on Earth. We cannot simultaneously replicate lunar gravity, vacuum, thermal conditions, surface properties, and the complete interaction between a lander's propulsion system and lunar regolith in an operational test.
However, we can thoroughly test the integrated vehicle, its software, its interfaces, and its mission sequences. Mission sequence testing (MST), end-to-end testing, hardware/software interface (HSI) testing, hardware-in-the-loop testing, and rigorous software verification and validation are essential elements of a disciplined development program.
The Mars Polar Lander failure provides an important historical example. In December 1999, NASA lost the Mars Polar Lander during its attempted landing. The subsequent investigation identified a probable failure sequence involving transient signals generated by the landing-leg deployment system. The flight software interpreted these signals as valid indications of touchdown, ultimately commanding premature shutdown of the descent engines at approximately 40 meters above the surface.
The investigation identified deficiencies in the system design and verification process. In particular, the complete landing-leg deployment test was not repeated after wiring corrections, and the system's immunity to transient touchdown-sensor signals had not been adequately verified.
The lesson is straightforward: testing individual components successfully does not guarantee that the integrated system will operate correctly. A hardware event can generate an unexpected signal. Software can interpret that signal incorrectly. A sequence of individually functioning components can produce a catastrophic system-level failure.
This is precisely why integrated mission sequence testing and hardware/software interface testing matter. From a program management perspective, eliminating essential testing to reduce development costs can become a false economy. The cost of a lost spacecraft, delayed program, or failed mission can be far greater than the cost of conducting the necessary testing before launch.
Mission assurance must be an integral part of the development architecture, not a budget item that is routinely reduced when schedule pressure increases.
Protect the three margins: cost, schedule, and technical performance
Mission success also depends on disciplined program management. I have long believed that program managers must establish and actively protect margin in three fundamental areas: cost, schedule, and technical performance.
| A program that consumes all of its cost, schedule, and technical margins during development has very little flexibility when the inevitable engineering challenges occur. |
First, programs need adequate program management reserve (PMR) and financial contingency reserves. A program that allocates every available dollar to its initial baseline has little flexibility when unforeseen problems arise. Importantly, these unknowns are not limited to engineering and technical challenges. Schedule and workforce costs can create equally significant financial exposure.
Consider a flight program that plans to launch on a particular date but experiences a six-month, one-year, or even longer delay. The spacecraft may be technically ready, but the program must continue carrying a substantial workforce responsible for flight operations preparation, systems engineering, mission assurance, integration, and launch support.
Those personnel costs continue accumulating while the program waits for launch. Meanwhile, the customer revenue associated with successful launch and subsequent mission milestones may not yet be realized.
This can create a substantial financial burden, particularly for commercial companies operating under limited capital and contractual revenue structures. Launch delays and schedule extensions must therefore be recognized as significant program financial risks, not treated as unusual exceptions.
PMR and financial contingency reserves must be established with these high-probability occurrences in mind. They must provide sufficient flexibility to absorb engineering problems, schedule extensions, labor costs, and the continued support of the program workforce.
Second, realistic schedule margin must be established and managed. Integration, testing, software development, and resolution of technical problems rarely proceed exactly as originally planned.
Third, technical margins must be established and protected. These include spacecraft mass, power, propulsion performance, and available delta-V.
Mass management deserves particular attention. Spacecraft programs must establish controlled mass allocations and require engineering teams to operate within those allocations. The mass growth allowance must be managed deliberately rather than treated as additional mass available for routine subsystem consumption. The same discipline applies to power, propulsion, and other critical resources.
Risk management must also begin with a clearly established mission risk posture. The loss of mission (LOM) probability provides an important framework for determining the acceptable balance between mission success probability, technical reliability, redundancy, and program cost.
Crucially, the identification and acceptance of the LOM probability must be established early in the program by ownership and senior leadership. This is a management decision, not simply an engineering calculation.
Senior leadership must establish how much mission risk the organization is willing to accept and what level of investment it is prepared to make to achieve the desired probability of mission success. Engineering must then develop an architecture capable of meeting those objectives. For human-rated vehicles, loss of mission and loss of crew are distinct risk measures, and crew safety must drive additional requirements and architectural considerations.
A program that consumes all of its cost, schedule, and technical margins during development has very little flexibility when the inevitable engineering challenges occur.
Design for operability from the beginning
There is another lesson from the Apollo era that I believe deserves renewed attention as we develop increasingly complex lunar systems.
Apollo senior managers emphasized five essential qualities that should be incorporated into the design and development of a flight system:
- DESIGN-able
- FLEX-able
- TEST-able
- EVALUAT-able
- OPER-able
These five qualities remain relevant today, and their importance increases when we consider the complexity of future lunar surface infrastructure. I would particularly emphasize OPER-ability.
In my experience as a flight director and senior program manager, engineering organizations can sometimes treat operability as something that the operations organization will address later in the program. The assumption is that engineering will develop the vehicle and the operations community will subsequently develop the procedures to operate it.
That approach is fundamentally flawed. Operability must be incorporated into the system architecture from the beginning. It directly influences spacecraft design, system interfaces, crew and ground operator interactions, maintenance concepts, fault management, and contingency procedures.
Operational requirements need to be represented during mission concept review (MCR), carried into preliminary design review (PDR), and maintained throughout development.
| We are not simply developing lunar landers. We are developing the transportation systems, operational capabilities, and supporting infrastructure that will enable a sustained human presence on the Moon. |
This is particularly important for a future Moon Base. We will not simply have individual spacecraft operating independently. We will have multiple landers, habitats, power systems, communications networks, surface mobility vehicles, and scientific facilities that must function together. Their interfaces and operational relationships must be designed into the architecture.
A system that is technically capable but difficult to operate, maintain, evaluate, or recover from failures will create unnecessary operational risk and cost. The Apollo experience demonstrated that operability must be designed into the system, not added at the end of development.
Human-rating and operability cannot be added at the end of development as certification or procedural exercises. Both must influence the architecture and requirements from the beginning.
From individual landings to a lunar transportation system
Looking ahead over the next five to ten years, I believe the greatest opportunity is to change how we approach lunar landing operations. We must transition from viewing each landing as an independent mission to treating lunar landers as recurring transportation systems operating within a shared surface environment.
That transition will require several capabilities. We need reliable autonomous precision landing and hazard avoidance. We need well-characterized landing zones and designated ascent and departure areas. We need to understand plume-surface interactions and protect critical infrastructure. We need common operational interfaces, surface traffic coordination, and procedures that accommodate multiple government and commercial providers.
We also need to consider how landers interact with habitats, power systems, communications infrastructure, surface mobility vehicles, and other elements of the lunar enterprise.
The objective should not necessarily be to require every commercial provider to build identical vehicles. Different vehicle designs and commercial architectures can contribute valuable capabilities. But their operations must be compatible within a common lunar environment.
This will require coordination among NASA, commercial providers, and the organizations responsible for developing and operating lunar surface infrastructure.
It will also require us to think about landing operations as part of the broader logistics architecture: delivering cargo, deploying equipment, supporting crew rotations, and eventually providing recurring transportation between lunar orbit and the surface.
The next challenge is operational sustainability
The lunar industry has made tremendous progress in developing commercial landing capabilities. We are learning important lessons from both successful missions and missions that have encountered difficulties.
However, I believe we need to begin looking at the problem from a broader perspective. We are not simply developing lunar landers. We are developing the transportation systems, operational capabilities, and supporting infrastructure that will enable a sustained human presence on the Moon.
That requires us to think about reliability, mission assurance, autonomous operations, landing-zone protection, and the interaction among multiple vehicles and surface assets.
My experience in NASA flight operations taught me that we must design for the off-nominal case, not just the nominal mission. My experience in commercial lunar lander development reinforced the importance of disciplined systems engineering and program management. And my work on lunar enterprise architecture has convinced me that we must consider the long-term operational consequences of the decisions we make today.
We should celebrate every successful lunar landing. But we should also recognize that landing successfully once is only the beginning.
The next major challenge is making lunar landings not just successful, but reliable, repeatable, and compatible with the larger lunar enterprise.
Note: we are now moderating comments. There will be a delay in posting comments and no guarantee that all submitted comments will be posted.