DIRECT v3.0 - Thread 1

[Lab Lemming]

In that case, you are sending 2 EDS through TLI with the same propellant, so your performance is that much less.

For a lunar mission, if one J-246 were launched with Orion and another with Altair, could either JUS serve as the EDS?

Modify:  I guess a better question to ask:  Is the amount that a J-246 can launch and still have enough JUS fuel left over to take everything to lunar orbit somewhere between 22 mT and 46 mT?

[fotoguzzi]

What I meant was, send each to earth orbit, and attach, say, Orion to the other JUS/Altair, throw Orion's JUS away, and send the remaining JUS/Altair/Orion stack to lunar orbit.

Modify:  Remove one word.

In that case, you are sending 2 EDS through TLI with the same propellant, so your performance is that much less.

For a lunar mission, if one J-246 were launched with Orion and another with Altair, could either JUS serve as the EDS?

Modify:  I guess a better question to ask:  Is the amount that a J-246 can launch and still have enough JUS fuel left over to take everything to lunar orbit somewhere between 22 mT and 46 mT?

[Mark S]

What I meant was, send each to earth orbit, and attach, say, Orion to the other JUS/Altair, throw Orion's JUS away, and send the remaining JUS/Altair/Orion stack to lunar orbit.

Not without propellant transfer from the (soon to be discarded) JUS to the other JUS/EDS.  And in that case, you could make the JUS larger to accommodate the amount of extra prop to transfer, and the landable mass could be that much more.  Only a depot would be able to deliver better performance.

Mark S.

[MP99]

If I'm reading the baseball cards correctly, the ASE for J246-CLV (1390kg) is almost three times the mass of the EDS version (500kg).  What's up with that?

From Ross at http://forum.nasaspaceflight.com/index.php?topic=16163.msg373469#msg373469 (need to scroll down a fair bit):-

If Altair is lifted by the final stage in the same way as Ares-V then ASE now = 890kg (latest figure is actually 842kg inc. managers reserves).   If Altair needs to transfer from one stage to another, it will carry its cradle with it, but the cradle will require 462kg (we assume 500kg) of additional 'latches' on both its launch vehicle and also its target EDS too in order to connect/disconnect.

500 + 890 = 1390 kg on the CLV / CaLV launch.

500 kg on the EDS launch.


During TLI, both the 500 kg latches from the EDS, and the 890 kg cradle from the CLV / CaLV launch are present.

The 500 kg of latches from CLV / CaLV remain with JUS and burn up as that re-enters.

cheers, Martin

[dougkeenan]

Someone is paying attention.  Thanks Martin!

[Lampyridae]

personal pet peeve---SLOC is a meaningless metric to characterize SW capability or complexity.  It is still used in industry to estimate developer labor costs, which is also meaningless.  Just take any Powerpoint presentation or Word document and 'save as HTML' (one mouse click) and count the lines of code you can generate in 10 seconds. 

Write a contract with SLOC in it and the number of lines of code becomes an equal qualifier with performance.  Code requirements should be written for functionality and ease of maintenance.   All the SLOC metric does is encourage writing of bloated, impossible-to-maintain code, inflated development costs and growing maintenance costs down the road. 

In most cases in my experience managers and contract writers have no idea what a reasonable ratio of SLOC to code functionality complexity is, so they don't even know what to specify.  Look up how many lines of code are in Windows OS.  This is what sits on the typical PC, and it does not count any of the applications.

Sorry about the rant...

I was always amazed by how much code I could strip away and get the same functionality. I'm not sure what would be a good replacement for SLOC - standard possible operations?

[zapkitty]

I'm not sure what would be a good replacement for SLOC - standard possible operations?

Still not a guideline though... no way to compare against intended operations.

[mike robel]

Perhaps we need a seperate thread for software design discussions? 

[kraisee]

If I'm reading the baseball cards correctly, the ASE for J246-CLV (1390kg) is almost three times the mass of the EDS version (500kg).  What's up with that?

The ASE consists of three parts:

1) The Altair rests upon a fairly standard 842kg "Cradle" which supports its mass.

2) The "Cradle" is then attached to the Jupiter Upper Stage by use of a "latching mechanism".   This mechanism allows the Altair/Cradle to detach from the JUS as a single unit.   We have a number of designs for the latching system, but for now haven't settled on a specific design.   So for now, we just have a simple 500kg mass allocation, which appears to be more than enough for all the design options.

3) On top of the EDS, another 500kg "latching mechanism" awaits to allow the Cradle to attach to the final EDS.

Ross.

[kttopdad]

...
  Team Direct can look at this as well.  Maybe a software emulator of the GPCs running in a modern computer.  I think the Orion computers and/or the computers designed for Shuttle Cockpit Avionics Upgrade can run an emulator to run GPC software. 

Danny Deger

all very cool. I asked this question once before, but never saw a reply. would still appreciate being 'educated'. How practical is it to get software help from outside? I'm sure we have some talented SW designers around, some maybe even out of a job, that would be willing to donate some off-time. I dont have any illusions about writing the final product, but I'm sure there are tons of tools, simulators, prototypes, and support software that might fall under the realm of possibilities. or is this completely and obviously out of the question?

As a  member of the Flight Software team for the ISS, I'm of the opinion that the right people can get the job done but market incentives are directly opposed to letting that team do it.  The contracts to build Ares/Direct/Whatever are cost-plus, so the motivation of the contractors is to put as many engineers as they can on the project.  We could have built the software for the ISS with half of the engineers we had, if they were the right half, and it would have been simpler and faster.  However, we were saddled with a lot of barnacles who contributed very little and were hindered by a management focus on billable hours vs. efficient operations.  I work with some of the most amazing engineers I've ever had the pleasure to work with, and most of them are bored to tears, unable to operate at their full potential.  We end up losing so many of the young, hot software engineers to Amazon and tech start-ups because they're not allowed to work at their potential in our team.  If these people were allowed to run full-speed, even with the process burdens of a CMMI Level-5 software organization, I have confidence they could get the job done in the time required.  But maybe I'm biased...  They're my friends. 

[fotoguzzi]

I think the Orion computers and/or the computers designed for Shuttle Cockpit Avionics Upgrade can run an emulator to run GPC software. 

How practical is it to get software help from outside?

If these people were allowed to run full-speed, even with the process burdens of a CMMI Level-5 software organization, I have confidence they could get the job done in the time required.  But maybe I'm biased...  They're my friends.  :)

Great, to DIRECT's propellant depot, lightweight upper stage, and ET repurposing; add:  extreme/pair programming.

Modify: and

[Malderi]

As a  member of the Flight Software team for the ISS, I'm of the opinion that the right people can get the job done but market incentives are directly opposed to letting that team do it.  The contracts to build Ares/Direct/Whatever are cost-plus, so the motivation of the contractors is to put as many engineers as they can on the project.  We could have built the software for the ISS with half of the engineers we had, if they were the right half, and it would have been simpler and faster.  However, we were saddled with a lot of barnacles who contributed very little and were hindered by a management focus on billable hours vs. efficient operations.  I work with some of the most amazing engineers I've ever had the pleasure to work with, and most of them are bored to tears, unable to operate at their full potential.  We end up losing so many of the young, hot software engineers to Amazon and tech start-ups because they're not allowed to work at their potential in our team.  If these people were allowed to run full-speed, even with the process burdens of a CMMI Level-5 software organization, I have confidence they could get the job done in the time required.  But maybe I'm biased...  They're my friends. 

As a member of the flight software team for Orion, and having worked on Shuttle (though not directly on the FSW)... everything you said is the same on our end.

As an aside on some of the earlier discussions, C++ isn't necessarily the problem. And yes, Lockheed used C++ for JSF avionics and is borrowing heavily from that experience. Of course, the JSF software has plenty of problems too, so nobody's quite sure *why* they're using it as a starting point, but whatever. The coding standards include things like no dynamic memory allocation, no diamond inheritance, and lots of other things. Some things aren't prohibited but need a waiver to use - I think recursion falls under this area, but I don't remember.

[Mark S]

As an aside on some of the earlier discussions, C++ isn't necessarily the problem. And yes, Lockheed used C++ for JSF avionics and is borrowing heavily from that experience. Of course, the JSF software has plenty of problems too, so nobody's quite sure *why* they're using it as a starting point, but whatever. The coding standards include things like no dynamic memory allocation, no diamond inheritance, and lots of other things. Some things aren't prohibited but need a waiver to use - I think recursion falls under this area, but I don't remember.

Thanks Malderi!  It's good to know that they are structuring the coding standards to limit some of the most troublesome aspects of the C++ language.

Mark S.

[drdave]

Perhaps we need a seperate thread for software design discussions? 

In 1964 I wrote my first program, solving vibrational and rotational chemical bond constants for the two Chlorine isotopes in HCl.

Over the past 45 years I have written in excess of two million lines of code for a variety of applications including hazardous waste inventory control.

Please create a separate thread for the discussion of software.

With regard to comments so far, I agree that LOC is ($#@*%$) unmentionable.

Functionality is everything.  If you can define a function (method), you can code it.  And if you cannot write a unit test prior to coding, go home and sit in the dark (gui aside).

Having written fortran, basic, visual basic, C# and SQL, I have concluded you can write crap in any language.  And I have seen a lot of that.

If it ain't got that swing, it don't mean a thing.  Beautiful code can be written and understood by modest programmers who have been trained by patient artists.

[MP99]

Someone is paying attention.  Thanks Martin!

 

cheers, Martin

[Steven Pietrobon]

I have to ask Dr. Pietrobon if he thinks it's worth saving a JUS at the price of 2 tonnes on the lunar surface.  (I think that's the trade?)

Both profiles were with J-246/J-130. One with a small Altair with the EDS doing LOI/PC/LLO and the other with a large Altair and the EDS just doing LOI. The latter gives a 2.1 t advantage.

Comparing J-246/J-130 with 2xJ-246, the latter picks up a further 5.5 t with staged TLI or 7.9 t with high Earth orbit rendezvous (HEOR).

The above numbers were using old data and may change.

[Stephan]

John Shannon-"They(Direct) have a viable rocket, but I think they have underestimated their costs". (...)
http://www.flightglobal.com/articles/2009/07/13/329456/return-to-the-moon.html

It's interesting to see that Direct has changed from "magic physic / powerpoint engineering / whatever" to viable. And it's said by an important NASA person.

[Michael Bloxham]

Question: How viable is the 4-seg Ares I light that I have heard about? Would a down-sized Orion still be useful for lunar missions? If so, perhaps a 2.5 launch achitecture could be made to work (1 Jupiter 130 w/ LSAM, 1 Jupiter 236 EDS, 1 Ares I light w/ Orion)?

[SimonFD]

Question: How viable is the 4-seg Ares I light that I have heard about? Would a down-sized Orion still be useful for lunar missions? If so, perhaps a 2.5 launch achitecture could be made to work (1 Jupiter 130 w/ LSAM, 1 Jupiter 236 EDS, 1 Ares I light w/ Orion)?

I would think that if Ares I Lite was built the decision NOT to build Jupiter would also have been made. The development cost for the Lite would preclude spending money on anything else in this current budget environment.
And if you have J-130 you don't need any flavour of Ares......

All IMHO 

[SimonFD]

Once Mr. Shannon realizes that Direct 3 is only slightly more expensive(Ross says about 5%) or slightly less expensive(Ross says about 5%) than the SDHLV(NSC),he may decide to make a public statement supporting the Direct Launcher to the Augustine Committee.

Interesting way to test the "Blood in the water" claim.........