Modularity, Flexibility, Interchangeability

On the cutting edge of technology and exploration, there are no certainties. All the planning and simulations cannot safeguard against uncertainty. Anomalies and unforeseen circumstances have the potential to throw a wrench into even the most well-planned mission. It is for this reason that the degree to which a habitat can adapt to the needs of the users and the mission becomes valuable unto itself. This adaptation takes many forms, but I’ll focus on those of modularity, flexibility, and interchangeability.


Modularity

When considering space station architecture, a module is simply a singular section of habitat that “plugs into” the rest of the station. These modules are not however modular in that they are based on no recognized module for size or dimensions and are only able to dock/berth together because of either standardized docking mechanisms or docking/berthing adapters. Modularity should be interpreted as follows:

degree to which a system's components may be separated and recombined, often with the benefit of flexibility and variety in use

A module then can be interpreted as a finite unit of construction that can exist independently or be used in combination with other units to form a modular conglomerate.

Modules are important from an economical perspective. It is easier to design one unit that can work with nine other versions of itself than design ten unique units at different times by different teams that also must work with all nine other units each designed by other teams. Once a module is designed and tested, it can be reproduced multiple times with decreasing costs and increased reliability. Imagine for instance the immense expense and unreliability that would result from each launch mission having a purpose-built launch vehicle designed from the ground up.

Even in an endeavor to build a larger structure, a modular method is still superior at this time given the current costs and intervals between launches. It is important from an economic perspective that the mass sent up becomes instantly usable, and not simply mass waiting to be assembled later. A self-sufficient module that can work with other instances of itself as well as current space technology is the ideal target if launch frequency is relatively low and experience in space construction is limited.


Flexibility

It is expensive and time consuming to get matter into space. There are no hardware stores or parts warehouses at an altitude of 400km. All the tools that are needed must already be in space, and astronauts need to make the most out of the objects that are already in space. It is for these reasons that the more flexible the chosen objects are, the better.

Flexibility comes in many forms and carries just as many benefits. One metric of flexibility is the ability to use an object in more than one way or in more than one configuration. In this sense, a purpose-built part that only works for its’ intended function is less flexible than a part that is standardized and compatible with many applications. An example of inflexible design would be the CO2 scrubbers in the LM (Lunar Module) and SM (Service Module) during the Apollo missions (made infamous by the Apollo 13 mission). These lithium hydroxide CO2 scrubbers used the same scrubbing technology but the connection interfaces were different shapes¹. If these filters were interchangeable, the astronauts would have had a much easier time solving the issue of CO2 saturation.

Another metric of flexibility is the ability of a component to be easily repurposed and/or reoriented when the circumstances call for the initial plan to be modified or the long term plan calls for the component to be repurposed once its initial use has become obsolete or less valuable. Once again using the Apollo 13 mission as an example, the purpose of the LM was to land on and launch from the surface of the moon, but it was able to be repurposed as an auxiliary source of propulsion and life support; the LM was able to be used in this way despite not being designed to do so.


Interchangeability

Redundancy is important for any sort of mission where resupply is infrequent and/or unreliable and where critical failure is a looming threat in a hostile environment. An old military adage may do more to describe this succinctly:

three is two, two is one, one is none

The wisdom conveyed here is that when there are uncertainties in both service life and replacement timeframe, you should have at least a backup for your backup. In practice this may be something like a certain critical component that needs to be replaced when it fails unexpectedly. If replaced with its sole backup component the whole operation hinges on that one component for the duration until the replacement backup arrives. In this line of reasoning, it is sometimes recognized that a mission should retain two backups for all critical components (ie: three total). In practice, this can become quite daunting as there may be many critical components that are unique to their function and location. Should space habitats maintain storage for double redundancies for all these components?

Imagine instead that the architecture/engineering of the habitat itself was standardized insomuch as the components for each section were interchangeable in the event of the failure of any given component. Instead of having hundreds of double-redundant backup components for the scores of critical components required by a fair-sized space habitat, the backup components of a space habitat designed with interchangeability in mind can number much more modestly. In addition, in the unlikely event that a critical area achieves a high variance and uses up its backup components, the operational component for a less critical area can be used as an emergency backup component.

From an end-of-use perspective, components designed to be installed in a variety of orientations/locations have greater utility as they can take on a new purpose once their previous function has been rendered obsolete. Why send a new component when an existing component (on which so many resources were already spent) will do?

Previous
Previous

Morphology of Polyhedral Space Habitat Modules

Next
Next

Codification & Future Time Periods