LH2 is definitely lighter per unit energy, but when you take into account the increased mass of the larger tanks, the total mass of an LH2 propulsion system is not necessarily all that much less than that of an RP-1 system.  I'm currently working on using data from all the kerosene/LOX rocket stages on Encylopedia Astronautica to get a power law relating propellant mass and tank mass.  I already have a similer function for the LH2 case from a paper I've posted links to before.  With both of these I'll be able to give a better idea of how much difference there is between the two approaches.  It may even be worth while using RP-1 for the TLI stage too!

According to Encyclopedia Astronautica, RP-1 freezes at -73 C.  It may be the case that we need to invest some effort in making sure the fuel doesn't freeze, but I'm willing to bet that keeping kerosene hotter than -73 C is much less of an engineering challenge than keeping liquid hydrogen colder than -253 C!  I am confident it can be done because kerosene and LOX were the propellants used in most of the Soviet moonshot's rockets.  The LK lander used hypergolics like the Apollo LM, but the TLI, LOI, DOI and TEI burns were all done with kerosene.

Hence my proposal is an agile software development approach: we split up "the software" into modules that are as small as possible, and use a slightly modified waterfall model to solve all these sub-problems. Each module is maintained by its own small team, which is responsible for everything that has to do with the module, including all the different design phases. If the final outcome doesn't satisfy our needs, we iterate. Besides, we don't use the traditional waterfall model, but the Sashimi model, where phases are allowed to overlap.

Hallo Philip,

I am a little less busy now so have finally made the time to read the Wikipedia article on the waterfall model, so I think I now have a good handle on your proposal.  The biggest question I have right now is the following: to what extent does splitting a project up into modules and applying a modified waterfall model (like sashimi) to each module save us from all the downsides of the BDUF approach?  It seems to me like you can't do a really good job of splitting things up into modules and, even more so, writing perfect requirements up front (or "nearly upfront" in the sashimi case) for those modules, unless you have some kind of big picture design of the entire system at the time of modularisation.  Is this true?  And if so does this mean we need a sort of "master waterfall" to get that first big picture clear (so that step 3 onward of the master waterfall is the beginning of all the "sub waterfalls")?  Sorry if I've got completely the wrong idea here, but this kind of hierarchical waterfall structure seems at least somewhat necessary to me.

Sorry for a slightly later reply than usual this time.  I am unfortunately very busy at the moment.  I just have time for one quick comment now, although I will definitely read the Wikipedia articles you suggested in the near future and try to play a greater role in this discussion.

On the topic of operating systems.  No choice has been made as yet, but it is possible to answer some of your questions on the basis of existing CSTART policy.

First of all, part of the CSTART Design Philosophy is:

Use off the shelf solutions wherever possible

The only reasons to build a solution ourselves are:

• Nothing on the shelf is appropriate for the job. Usually this
  will happen with things that need to work in harsh environments
  (vacuum, extreme temperatures, radiation exposure, etc.). In this
  event, we should consider modifying an off the shelf solution before
  building from scratch.
• We can do it considerably cheaper/lighter/more reliably than anything on the shelf.

I think this pretty much rules out writing our own operating system from scratch.  I can think of no compelling reason to do this, so we will almost certainly take an existing operating system.

Also, part of the CSTART Social Contract is:

All computers onboard CSTART rockets and spacecraft which run operating
systems will run operating systems whose kernel and basic userland
utilities satisfy the Free Software Foundation's Free Software Definition.

So this means the spacecraft OS will almost certainly be some variety of GNU/Linux or *BSD.  Obviously the actual choice will be for something which is light on resource utilisation, responsive and reliable: not a regular desktop OS but probably something designed for embedded systems or real-time applications, that sort of thing.  It will almost certainly be multitasking, which should make it easier to divide our software needs into separate programs.

I am really unsure how we will go about actually choosing an OS.  Everybody has their own favourite and people tend to get very passionate about this issue: choosing an OS could easily devolve into a holy war if we don't approach it carefully.

What considerations did you have in mind in asking about the OS?

if you're interested in learning about software engineering and particularly design philosophies, I recommend reading about the waterfall model (which is often referred to as the "traditional" design methodology) and then about Extreme Programming (which is considered to be the other end of the spectrum). While reading about those two, you may eventually find useful pointers to other design strategies. Agile software development, as proposed by me, bridges the gap between the traditionalist approach and the radical newer ones. The Wikipedia articles are a good starting point, and I may have some scripts from lectures about the topic in general. The C2 wiki (whose founder is also the inventor of wikis in general)
used to be a well of information about design strategies (and, mainly, design patterns).

By the way, I've been reading the stuff on your website, and noticed that you are in the process of learning German. Incidentally, I'm a German native speaker, so if you need someone to further your abilities, I'd be happy to help out. I'm from Saarbrücken and found your site by googling for Dennis, so maybe this is not so incidental.

Regarding your question whether CSTART needs different design processes for different parts of the software, I do not know. Maybe there are completely non-critical parts where reliability is not a concern, but that doesn't affect the choice of the design strategy. Reliability is a main concern of every (sane) design strategy available (see "Cowboy coding" for counter-examples).

Maybe I will have to make something clear: the design strategy doesn't necessarily influence the way the final product looks like. Given a large piece of source code, you probably can't decide whether it has been built using waterfall, XP, agile, whatever. The design strategy merely defines how to get from the idea to the final software, and these processes may look and feel entirely different.

Furthermore, the agile software development approach is not "heavy-weight". It's not "light-weight" either. It's a heavy-weight process made light-weight. Maybe one could call it "middle-weight" or better "adjustable-weight". In order to achieve a higher software quality, the whole process is simply repeated, thereby adjusting the previous outcome (and increasing the weight).

This has some advantages. First of all, if the outcome doesn't look satisfying, you simply iterate. But in contrast to other iterating design strategies, you'll have documentation available right from the beginning. You can omit writing unit tests or having code reviews, but if it later turns out to be useful, you start another iteration and add those. It is completely adjustable; for a small project like the scripts you wrote, it would suffice to come up with a preliminary manual and then write down the code, adjusting the manual as needed. For larger projects, you add whatever you need.

The problem right now is that with a more light-weight approach, we don't get documentation until someone reads the code and writes some manual. The agile approach, in its simplest form, merely reverses the order. Write some docs first, then write the code. Iterate as needed. This way, the software can "grow" in a controlled manner, documentation and code both keep up-to-date, and more advanced techniques can be added easily as needed.

I wouldn't recommend two different design strategies, but merely several levels of "how accurately do we want to mimic the look and feel of waterfall per iteration". Small projects may be done in one iteration (and one day), larger projects may need 50 iterations and two years.

By the way, what exactly are we talking about when we're referring to "the software"? The whole collection of applications and libraries related to CSTART? Everything the users will eventually come to see and work with? Everything that is not "the hardware"?

And I have another question: which operating system will run on the spacecraft? Because thus far, I think all we have been talking about is applications and maybe libraries. But it may be important to know something about the operating system before any serious application design can start. Do you intend to take an existing operating system? Modify it to suit your needs? Or build it on your own completely from scratch? Will there be a difference between the operating system and the applications that run on top of it? Is it a multitasking operating system?

Just wanted to say a really big thank you for your long and well-thought out contributions to this important question.  I can't comment on your specific suggestsions just yet, as I'd have to read up on some things first, particularly the waterfall approach.  I have a lot of programming experience but relatively little knoweldge of software engineering (not that I'm not interested in that, I just haven't yet got around to it).

One thing that strikes me as worth considering is that CSTART's software problems are basically going to come in two forms.  There is software like USOFS and AESAT which is used early, on the ground, to plan and design stuff, and there is software that runs on computers on rockets, spacecraft, etc., i.e. avionics software, which is used only after a long process.  Aside from the difference in how long we have to wait before we can really use these two kinds of software, they obviously also differ significantly in how important reliability is.  A bug in USOFS is not going to kill anybody the first time it shows up.  We can always fix a bug when it is found and adjust our plans slightly if needed.  On the other hand, a bug in avionics software could be really serious, potentially fatal, and is not necessarily going to be easy to fix if it turns up in the middle of a long mission.  Basically, one set of software needs to be "bulletproof", the other set not so much (although, of course, it would be better if it was).

Do you think this warrants two slightly separate processes?  My thoughts are that avionics software is going to need a lot of prior plannig, extensive documentation, unit tests on every little thing, frequent code reviews, etc., etc., pretty much everything software engineering has to offer when it comes to making bulletproof software.  Things like USOFS don't really need that, and if we try to force such a heavyweigh approach on such "small" software, it's just going to discourage people from getting involved.  To me it makes sense to have a "heavy duty" and "light duty" software engineering process to fit the different cases.  Is this sensible?

Hi antinode,

the waterfall model is what first came to my mind when I wrote my initial posting. I didn't want to talk about something as important as the overall design strategy, but now I'm glad you asked.

Before I'm going deeper into the issue, I'd like to mention that it's generally a bad idea to adhere to a certain software development methodology only because it has proven to be acceptable in hardware development environment. I once had to build a simple (but complete) CPU from scratch, and the waterfall model surely was the best choice, but it also has huge disadvantages under certain circumstances. That being said, the waterfall model is still a good choice in this particular case, although I will propose something inherently different, yet deeply related to the waterfall model.

So, why is the waterfall model a good choice? "Big Design Up Front" design strategies make the assumption that software development can be split into subtasks such as requirements phase, design phase, implementation phase and so on, and that each phase can be completely finished before any work on the next phase has begun. This assumption is usually wrong, but in the case of CSTART, this might be the case: we don't build a software that nobody has ever seen yet, we don't have a customer that adds new requirements 3 months before the final release, and quite a bit of the stuff we will be implementing is pure math/physics anyway. Furthermore, the waterfall model ensures that their will be documentation available, which is especially valuable in an environment where developers leave and join on a frequent basis. And of course, the waterfall model is easy to understand. If anyone asks "where are we right now?", he can be answered by e.g. "the end of the design phase, here are the docs". Compared to, say, Extreme Programming, this is a huge advantage.

Their are some downsides, too. The waterfall model requires a very high level of discipline among designers and developers. It takes months, in our case years, before the first line of code is written - and this makes it boring for most programmers. Who wants to talk and talk with physicists/engineers over the course of years without ever producing something that... works. In the short run, there's no payoff. I doubt that we will be able to keep designers and programmers motivated throughout the duration of the whole project. In my opinion, this is the main disadvantage. In the worst (yet still highly probable) case, the design people will have left the project before the programmers get to implement the software. Now, imagine what happens if there occurs an error during the final mission. Who's to blame? "Oh, that's Steve's fault. He left the project about two years ago." Furthermore, with the waterfall model, every individual who leaves the project before it's finished takes highly valuable knowledge with him that can't be replaced without some guy reading the docs for half a year.

So. In my opinion, the waterfall model would be a good idea if we had $10.000.000 at our disposal to keep people motivated. It's a bad idea for teams with a member fluctuation greater than zero.

Hence my proposal is an agile software development approach: we split up "the software" into modules that are as small as possible, and use a slightly modified waterfall model to solve all these sub-problems. Each module is maintained by its own small team, which is responsible for everything that has to do with the module, including all the different design phases. If the final outcome doesn't satisfy our needs, we iterate. Besides, we don't use the traditional waterfall model, but the Sashimi model, where phases are allowed to overlap.

Features:

• one iteration of the waterfall model for a sub-problem probably takes 4 weeks instead of 4 years
• hence high motivation by defining goals that can be accomplished in a
  reasonable amount of time
• still the same benefits: lots of documentation, unit tests, validation, ...
• small teams that interact with each other, not one large team that drowns in chaos
• easy to maintain high disicpline among team members
• teams are able to respond to changing requirements / new insights quickly
• we can learn from mistakes without throwing away everything we did thus far
• small, independent teams
• maybe even some kind of competition among different teams (fewest bugs, shortest implementation time, highest efficiency)
• easy to maintain high communication volumes among team members
• and many more

This approach is, in my opinion, most suitable for an environment like this, without sacrificing the substantial benefits of the traditional waterfall model. I might have forgotten something, but I'm eager to discuss the issue in more detail anyway.

What are your thoughts about this?

Your English is perfect by the way, so no need to apologize.

That page includes an excellent summary of the strengths of this approach:

The fundamental concept of the General Electric
design could easily be summarized as obtaining minimum overall vehicle
mass for the mission. This was accomplished by minimizing the mass of
the re-entry vehicle. There were two major design elements to achieve
this:

• Put all systems and space not necessary
  for re-entry and recovery outside of the re-entry vehicle, into a
  separate jettisonable 'mission module', joined to the re-entry vehicle
  by a hatch. Every gram saved in this way saved two or more grams in
  overall spacecraft mass - for it did not need to be protected by heat
  shields, supported by parachutes, or braked on landing.
• Use a re-entry vehicle of the highest possible
  volumetric efficiency (internal volume divided by hull area).
  Theoretically this would be a sphere. But re-entry from lunar distances
  required that the capsule be able to bank a little, to generate lift
  and 'fly' a bit. This was needed to reduce the G forces on the crew to
  tolerable levels. Such a maneuver was impossible with a spherical
  capsule. After considerable study, the optimum shape was found to be
  the 'headlight' shape - a hemispherical forward area joined by a barely
  angled cone (7 degrees) to a classic spherical section heat shield.

This design concept meant splitting the living area
into two modules - the re-entry vehicle, with just enough space,
equipment, and supplies to sustain the crew during re-entry; and a
mission module. As a bonus the mission module provided an airlock for
exit into space and a mounting area for rendezvous electronics.

The end result of this design approach was
remarkable. The Apollo capsule designed by NASA had a mass of 5,000 kg
and provided the crew with six cubic meters of living space. A service
module, providing propulsion, electricity, radio, and other equipment
would add at least 1,800 kg to this mass for the circumlunar mission.
The General Electric D-2 provided the same crew with 9 cubic meters of
living space, an airlock, and the service module for the mass of the
Apollo capsule alone!

The modular concept was also inherently adaptable.
By changing the fuel load in the service module, and the type of
equipment in the mission module, a wide variety of missions could be
performed.

software engineering is indeed something I'm enthusiastic about, and although I consider myself to be somewhat knowledgable in this area, I certainly lack the years of experience necessary for making informed decisions. I do know about all the major software design models with their respective pros and cons, and I know a fair bit about the process of developing software, i.e. coding, testing, debugging, profiling, optimizing, distributed environments. I'm an acceptable programmer (in descending order: C, Python, SQL, C#, C++, Perl, Pascal, Go, Brainf*ck, Scheme, SML, ...), though I prefer thinking about algorithms rather than writing specific code, although I consider myself to be a good reviewer.

So this is me. As you may have already guessed, I'm pretty bad at physics and English. Anyway, I'd be glad if I can be of any help, though I don't know how much time I will be able to devote to CSTART.

Do you already have specific questions regarding software engineering processes, design models, or code development in general?

1. By making the DM so small and light compared to most reentry vehicles, are we risking making it aerodynamically unstable?  E.g. might bad turbulance during reentry easily flip the thing over?
2. How close to the mark is 200 kg for the LM Langley Lightest lander's frame, seat, and avionics?  This feels like it should not be too hard to estimate, we did something very similar for the original CLLARE LL by finding the linear density of extruded aluminium tubing and getting the length of all the beams.

First of all, some quick concept diagrams of the overall mission architecture:

Nothing here is necessarily to scale, the use of two stages, one for TLI and one for LOI/TEI is not necessarily an inherent part of the "new two module idea", and the colours are only to make it easy to tell things apart.  The small blue headlamp shaped module is the descent module, the large green cylinder is the orbital module.  I made the orbital module cylindrical as per Soyuz rather than roughly spherical like Soyuz purely because I think it looks a little nicer: if there ends up being a good reason to prefer one approach over the other I won't hesitate to make the best choice.

Now, onto some more realistic things:

As part of the big mass analysis I've been working on (which has been temporarily shelved as I have a tonne of uni work to do), one propulsion architecture I am considering involves a LH2/LOX stage purely for TLI and an RP1/LOX stage that handles LOI and TEI, i.e. this is a two-stage architecture like that shown above.  Using RP1 (kerosene) instead of LH2 isn't something we've considered much before, but I'm starting to prefer it because I think it's not anywhere near as worse than LH2/LOX as one would think.  I think we have understimated how inconvenient using LH2, which is deeply cryogenic, for burns which occur days after the initial launch will be (we have never included in our mass analyses an allowance for LH2 boiloff, which is pretty much inevitable, and when considering the impact of RP1's lower Isp we have neglected the counterbalancing fact that RP1 tanks are much, much lighter than LH2 tanks, due to RP1's much higher density and the need for less insulation.  A "bad" LH2 tank can have a mass of around 15-20% of the propellant it holds, whereas really good RP1 tanks can have a mass of just 1% of their capacity.  That's a big difference.

Long story short: I currently believe that if we use LH2/LOX for TLI and RP1/LOX for everything else (including the lander), then with a lander structural mass of 200 kg (this is not including engine, propellant or propellant tanks - it is frame, seat, and avionics) we can have a total DM-OM mass of 1132 kg.

Knowing all the masses of propellant and oxidiser required for this arrangement, I have spent some time thinking about how to physically arrange stuff, and making sure everything fits in the Falcon 9 payload fairing.  To this end, I have prepared some scale diagrams:

The first diagram shows the situation where each lot of fuel and oxidiser gets its own spherical tank.  This leaves very little room for the lunar lander, so I don't think it's workable.

The second diagram shows the situation where the TLI propellants have been collapsed into a single spherical tank with a dividing bulkhead.  This frees up what looks like enough room, but there's little room for error, so I'm not too comfortable with it.

The third diagram shows the situation with all TLI propellants in a single spherical tank and the LOI/TEI propellants put in a cylindrical tank.  The cylindrical tank is much more efficient from a space point of view, but also much less efficient from a mass point of view - however, as mentioned, RP1 tanks can be so light that making that sacrifice on this particular tank is not that big a deal.  This arrangement has room for the LL and plenty of room for error.  I also feel like this arrangement has the benefit of minimising the total number of spherical tanks: while these are the most mass efficient, they're also the hardest to manufacture.

A quick note on engine dimensions: originally, when I drew these diagrams, for the engines I used the measurements of the RL-10 engine (as used on Saturn and Centaur) for the LH2/LOX stage, and SpaceX's Kestrel engine for the RP1/LOX stage.  However, they just looked comically huge.  The truth of the matter is that the propellant and payload masses we are considering here are so far below what is normal in astronautics that standard engines are generally overkill.  So for now in these diagrams I have just drawn engines which "look about right".  This is obviously very imprecise which is why I am concerned about leaving room for error.

All feedback super welcome.

Thanks a lot for your comment!  I am the author of USOFS (and also of AESAT, which is fairly new and I guess you hadn't seen yet).

Far from taking offence, I agree that everything you have said in this post is completely true!  Not only that, but in general CSTART's biggest currently stumbling block is not a lack of feasible ideas or of people willing to work on them, but rather a distinct lack of consistent, reliable organisation and procedure to keep things running smoothly.

This is actually something we are very aware of and, at least in principle, it's what we are currently working on fixing.  We're also aware of the particular shortcoming with regards to software.  If you look at the Wiki article on the CSTART Engineering Process, which is supposed to allow people to do work in an organised fashion, right down the bottom is a short stub on the "Software Engineering Process".  There's very little there at the moment because as it stands nobody in the community has good software engineering knowledge or experience: we just recognise the need for it.

If this is something you are somewhat knowledgable and enthusiastic about, we would very strongly welcome and assist you if you wanted to take a role in helping us define a proper Software Engineering Process to help ensure that, as we go forward, our software becomes more and more maintainable and reliable.

There are certainly lots of shortcomings in USOFS and AESAT (in fact, I think there is even an "actual" bug in USOFS, in that the maths is slightly wrong), but unfortunately I just do not have the time right now to maintain them like they should be maintained.  In a few weeks I'll have some time off and will try to tidy things up then.  If we have any kind of requirements or guidelines in place for software by that time I will do my utmost to make sure that both USOFS and AESAT abide by them.

As a quick final aside: the function "rho" computes atmospheric density as a function of altitude above sea level.  Rho is the standard symbol for any kind of density in physics/maths/engineering - but I know that's no excuse for not documenting this.

Thanks again for your valuable feedback, and if you decide you'd like to help out I look forward to working with you in the future on defining some better software procedures for CSTART.

while reading the CSTART website, wiki and software source, I noticed that although you have a software wishlist, there's no information available on how to actually implement the desired functionality. Good programmers don't necessarily know much about physics. As I can tell from the source of usofs.py, there is a clear need for some kind of design principles and a philosophy of communication between experts in different areas.

Here are my suggestions:

1. Think about software design principles
2. Write libraries instead of programs
3. Make engineers/physicists write specifications of the desired software

Here's why:

1. Software design principles enable programmers to assure the maintainability of the code. Ten years from now, e.g. Python might be a completely different language (or might have died), and programmers then might not be able to understand what we're doing today. A general set of rules such as "don't write functions without at least a single line comment describing their purpose" or "use meaningful descriptors" greatly improves the overall code quality. Point in case: what is the purpose of the function rho() in usofs.py? Can you tell without looking at the source? Without asking the author? Without understanding physics?
2. The naive approach of writing large software systems is to start writing applications, realizing that they share common subtasks, and extract those components, collecting them in one or more libraries. You'll need both, programs and libraries. It's easier to start with the libraries. "If what you need is a car, you don't start by building a car."
3. By having a specification of what the software is supposed to do, it is easy for non-physicists to actually write the software. Prepare papers with formulas and explanations, such that ordinary programmers can easily learn what they're supposed to do. It's better to have the software built by experienced programmers who have heard about physics, than by experienced physicists who have heard about programming. Also, comparing specification and code enables programmers to verify and even prove that the software works correctly. The current approach might work for software systems with, say, 10.000 lines of code. It will fail for 2 million lines of code.

I'd like to end with an excerpt from usofs.py, which neatly shows the relevant deficiencies in the areas of design principles, code documentation and user interface design:

def usage():

        usagestr = """Foo"""

        print usagestr

Greets,

Philip

PS: if you are the author of usofs.py, this is by no means meant to be an offense. It's just that there isn't yet any other source to take examples from.

There are a number of conflicting requirements and desirable options involved in CLLARE:

• We would like to use composite materials and/or inflatable structures to keep our mass down as much as possible, but...
• ...we need to use metals to provide decent shielding from van Allen radiation and to provide the structure for the module which undergoes atmospheric reentry.
• We would like to keep the CM as small as possible to minimise mass, but...
• ...we need as much free space as possible to facilitate things like putting on/taking off a lunar EVA suit and going to the toilet.

Using a single habitable module for the non-lunar part of trip forces us into a fairly undesirable compromise of making a relativle large single module out of metal.  What if we had two modules, joined together with a transfer tunnel inbetween them?  I'll call these the descent module (DM) and orbital module (OM) in this post, using the standard English terms for Soyuz modules.

Our DM would be absolutely as small as possible, I mean really minimalist.  Basically a chair with walls around it, a bare minimum of electronics, and a heat shield.  It would be the smallest manned space capsule in history, even smaller than a Mercury capsule (since it would need to hold less stuff).  It is made primarily out of metal: it can withstand reentry and provides enough radiation shielding that a short passage through the van Allen belts is not too dangerous.

Our OM would be considerably larger, with enough room to comfortably manipulate a lunar EVA suit, etc.  Crucially, the OM is as light as possible: made out of carbon fibre and/or inflatable spaces.  It contains the main avionics etc., long range communication stuff: everything not necessary for reentry.

The usage of these modules is fairly straightforward.  They are joined together from the beginning of the flight.  The astronaut is seated in the DM during launch, where the seat protects them from launch g's.  After orbital insertion, they transfer to the relatively spacious OM through the hatch and inhabit the OM for most of the trans-lunar cruise.  During passage through the van Allen belts, they temporarily transition back into the metal DM to take advantage of the higher radiation shielding provided by an aluminium shell compared to carbon fibre or whatever multi-layered foil/plastic/fabric stuff might be used for an inflatable OM, returning to the OM after radiation levels are back down to normal.

Transfer to the lunar lander and back (should have made it clear at the beginning: this idea is based on a separate orbiter/lander architecture like Apollo, not the "single craft" architecture I have also proposed, although it could be adapted in that direction) would be through a second hatch in the OM, which leads out into space (the LL could be, but would not necessarily have to be, docked to the OM).  In this way, the OM acts like a sort of airlock.  Some advantages of this arrangement compared to previous plans are:

• After docking the LL with the orbiter, the astronaut does not then have to squeeze themself, while suited up, into a tiny CM and then close the EVA hatch (and if you read anything about early EVAs in the Gemini and Voskhod programs, you'll find that this is actually an extremely difficult thing to do and almost ended in disaster on numerous occasions).  Instead they can enter a relatively spacious OM fairly easily and "suit down" before having to return to the DM (one might argue it prudent to wear a suit during reentry - even if we do end up doing this, this could be a significantly lighter and more mobile suit than the lunar EVA suit).
• There is minimal opportunity for lunar dust to get tracked into the DM, because the OM represents a kind of dusting down chamber. If the dust situation in the OM was especially bad, the astronaut could seclude themself in the DM while filtering systems did their work.

Before reentry at Earth, the OM and DM separate, with the DM reentring and the OM burning up.  This is a significant down side to the approach: only the bare bones DM survives and the OM, including all the equipment inside it, is lost.  There's not a lot of reusability possible.

Obviously there are some logistics to figure out with regards to what goes in the DM vs OM, with regards to life support, avionics, etc., but this could be a fairly beneficial arrangement on the whole.  It could let us provide the spacious environment we really need to deal with suit and toilet related issues without requiring a large metal capsule.