**Transcript of the Questions and Answers from the briefing held on June
6, 2008, at the US Chamber of Commerce briefing center in Washington,
D.C.**

**To the extent there are any inconsistencies between this transcript
and the solicitation, the solicitation governs.**

**Topic 1: Alternative Packaging Options**

**[Question]{.underline}:** Will you provide a sample packing problem in
the BAA? IE: Can you give mass, volume, and sizing information on the
GPS Antenna example? This will be important to determine % gains of some
innovative concepts.

[**Answer:**]{.underline} I can try and get the details of the example I
presented. I assume we can post that on the website eventually and any
other similar information I can get. I don't have that information at
hand right now. What I can tell you is -- and there is a little fuzz on
this in my mind too -- but, in researching this and talking with some of
our Stowage Integration folks at JSC I was told the historical average
for our packing has been on the on the order of 12.4 pounds per cubic
foot. Now, the fuzz in my mind is, does that include the clothing and
food -- which I said earlier -- doesn't require packing material. So is
that an across the board average, or is that for items that -- like
examples I showed, that include the packing material. I'm not sure which
-- how that number was derived, so I would have to research that a
little bit more. But, that is the number I have right now and that you
can use to start thinking about and it works out to 12.4 pounds per
cubic foot. That's the best answer I can give you right now. What I can
add to that - extrapolate from what was just said; is that in our
architecture work so far, we have already made assumptions without the
backing of technology, without the penalties associated with packing
weight. So, whatever the traditional norms are for spaceflight hardware
packing masses, in the hardware architecture we've done so far, we're
actually assuming a lower level penalty than traditional averages. Under
the assumption that there will be some clever ideas brought to the table
at some point in time that help us reduce those penalties.

**[Question:]{.underline}** Focus was on packing material. Are we to
propose bag/locker design? If not, can you provide content (concepts)
for bag designs?

**[Answer:]{.underline}** The simple answer is that we use bags today
but we are not necessarily expecting bags as a part of the answer. If
you come up with an approach which doesn't require bags -- in addition
to reducing or eliminating the packing material -- if you also don't
need a bag, that would be very attractive.

NASA Comment: I have one thing, correct me if I'm wrong,. The
presentation kind of focused on smaller type items. Well, think about
anything that goes to the surface from a packaging standpoint. Don't
limit it to, "I'm thinking of a little antenna or how do I package
shirts or food". Think of anything that would come to the lunar surface.
How would you package it to be more efficient?

Additional NASA Comment: Tools

Additional NASA Comment: Tools, anything. We want to keep that wide open
rather than giving specific examples.

Additional NASA Comment: And there is no requirement that it is going
end up being in a bag.

Additional NASA Comment: Right

Additional NASA Comment: That was just the example.

Additional NASA Comment: It would be secured with some sort of equipment
as an interface between the item itself and the carrier vehicle. It
would be flight support equipment. I'm not really considering that in
the scope of this BAA. I'm thinking more in terms of loose equipment
that would not be secured via flight support. And, I think one thing
that's real important with the packing materials is the reusability.
It's something that just because we use it for packing, once we get it
there we want to be able to use it for some other activity.

**[Question:]{.underline}** What are (the) current methods of testing
load and vibration attenuation for packing materials?

**[Answer:]{.underline}** A vibration table is what we use right now for
the Shuttle and Station.

Additional NASA Comment: Does that answer, let me -- I meant to say this
before -- if you needed to do a follow-up on the question you have
asked, please just raise your hand or something and somebody will come
with a mike to help with the follow-ups so we address it fully.

Additional NASA Comment: I was just going to add, that I didn't get a
chance to talk with the folks who are doing the testing currently at JSC
that I mentioned in my presentation, but I can do that -- I intend to do
that -- and we could also post -- I would presume -- just a description
of the current testing they are performing.

Additional NASA Comment: Or, if they have another way of testing, it's
fine. We don't want to provide so much information that we ruin your
innovative thinking. I think people are all pretty open to the concepts
for how you would do it. .

**[Question:]{.underline}** Presentation focused on packing...what about
moving objects across surface -- is that to be addressed?

**[Answer:]{.underline}** I think for the purposes of this specific BAA,
moving wasn't really a priority, though there are likely to be aspects
of movement that require some packaging projection. I think at this
point, we are more focused on the launch and landing load type
discussion than a moving discussion.

Unknown: I would just add to that - your right, but I think it's a good
question in that whatever solution would be proposed needs to be
compatible with movement so it can be easily offloaded, whether it's on
a pallet for example or if it's all hand -- moved by crew members -- or
whatever. I think it's important that some consideration be given to
that as well.

**Topic 2: Minimum Functionality Habitat Element**

**[Question:]{.underline}** Safety measures usually are specifically for
contingency, even without any redundancy. How are you defining the
"basic required safety features" if there is to be no contingency
consideration? That's some of what we're looking for.

**[Answer:]{.underline}** We're open to discussion as to what basic
safety should encompass. Start with contingency. The contingency was not
meant to be a requirement placed on you or a constraint. It was just an
identification that in the definition of the element capabilities, we
have to account for the fact that there is a certain length of stay
defined, a plan; plus the potential for contingency. The amount of
contingency or the nature of the contingency -- don't view that as a
constraint or limitation of what you want to propose. Nor are the times
themselves necessarily critical. It was meant to give you a feel for the
numbers that we're dealing with; and in terms of what basic safety
means, I think we're open to discussion about what is relevant to that.
We get some mixed signals from within the community as to how much
safety needs to be imbedded into our early design stages. And, we're
open to some discussion on how to improve that methodology or how to --
or where we might be too rigid on its application.

Additional NASA Comment: I would like to follow-up with an example \...
in the core element, if something should go down -- a system go down --
we need keep the crew safe, but it doesn't mean full functionality. So,
unlike Station, if something goes wrong, the outpost isn't going to fall
off the moon. So, you have recovery time. So, think about innovative
ways if you go into a degraded mode, even a single string with some of
our satellites, what would that look like ...just as another example.

Additional NASA Comment: Just to emphasize with this design, this is
probably not something that would end up being the final element design.
This is for us to get the basics of what that element has to have. We
use the term "construction shack", so if you're going to the surface and
you had to have an element, what are the basic things that it has to
have. We'll add back in the safety features and the redundancy as we go
along with the design, but this is just the core functionality that the
element has to have.

Additional NASA Comment: And, make the additional requirements fight
their way in.

**[Question:]{.underline}** 8 psia drives other things ... what is the
history of 8 psia?

**[Answer:]{.underline}** Additional NASA Comment: Yeah, there was a
study done actually before the LAT activity was even initiated by a
group known as the Exploration Atmosphere Working Group. It's a
reference-able document; it was lead by a diverse team. They came up
with recommendations for atmospheres and make up of internal
environments across all elements. The core element was just one. So, it
went across Lander at the time CEV or Orion. So the recommendation from
that aster study group was 8.0 psia. So, we intentionally use that as
our going in assumption. Additional NASA Comment -- I mean at all levels
of the activity -- it was agreed to that we would use that as our
reference because there was so much work done in doing it.

Unknown: We can follow-up and I think it would be very good to go ahead
and have that as a reference at this point. I just didn't have the JSC
-- I think it's at JSC -- the JSC document number is JSC 63309, but it
is a reference-able document.

Additional NASA Comment: We'll post the document or provide a link to it
with all of the other information.

**[Question:]{.underline}** Please briefly discuss power assumptions for
a habitat element. Is power provided to the element, if so, what are the
projections? Or, is the element to be self-sufficient concerning power
generation/storage, or, is this to be determined as a result of the BAA
concept studies?

**[Answer:]{.underline}** I can deal with that one. The idea is - I
think you should assume, for the purpose of the BAA, that power is
provided to the element -- that there will be a separate power system
providing power to the element for, I believe the number we're using for
some of our designs is along the range of 8 kilowatts.

Additional NASA Comment: Right

Additional NASA Comment: That's peaked. 8 kilowatts peaked

Additional NASA Comment: Yeah, that's peaked. But, don't consider that a
constraint in that if your design requires more or less that's certainly
appropriate to put that in. About the only power system function that
would typically be handled by a core-element of some kind is the power
management and distribution type activities. The power generation and
storage will be outside the bounds of the element itself.

**[Attendee Question]{.underline}**: The power system, I'm assuming,
you're taking out of the habitat discussion for the portion of the BAA,
that's what you're saying. But, how do you integrate the coolant of the
power system with the habitat -- or, if you want to take that out of the
discussion also.

**[Answer:]{.underline}** I don't think we intend -- that ought be part
of your habitat discussion that could be integral to the way you lay out
and create a hab-element. So, thermal management should be considered.

Attendee: It's tough to integrate the cooling if you don't -- or are you
saying just assume khw efficiency type of cooling.

Attendee: So you're saying to assume the kwh -- efficiency type of
cooling

Unknown: That would be reasonable.

Unknown: Yeah, we would hope that you would factor in some type of
thermal control or some type of thermal system.

**[Question]{.underline}**: How does the surface habitat develop, grow,
or expand with increasing mission duration and crew size?

**[Answer:]{.underline}** I would say, you tell us. One of the things --
and I'm not sure if this is one of the questions or not about the land
cert or not -- on the habitation element, we said 7,000kg is the size.
That's per element. So, if you're looking at to get to 180-day stay --
multiple modules that's OK -- so one of the options for growth could be
additional elements, we're looking for inputs, but then again the
7,000kg would be per element, not the entire system.

Additional NASA Comment: any kind of an architecture that allows for the
potential for growth is appropriate. If that effects what you consider
minimum functionality, then we would expect you to address it to the
extent necessary as part of your discussion.

Additional NASA Comment: One of the sensitivities within our hab-team
that we have been having to deal with for the past few years with all
this, is that you really do not have the capability to deliver the
entire amount of volume or even mass that's required for the full-up
outpost with one delivery. So, strategies in terms of how you do that
incrementally are part of the challenge with this topic area. So, that's
all I wanted to add to it.

**[Part B of the question]{.underline}**: Torus Inflatable: Is it a
trans-hab type "tire" around a hard core, or a true doughnut-type torus?

**[Answer:]{.underline}** Yes, or no. Your call.

Additional NASA Comment: The picture you saw obviously looked like a
trans-hab-type element. But, there is certainly no reason to be
restricted to that.

Unknown: And, the thing to note with that again with that notional
picture -- it just shows you one of the -- I guess you'd say --
challenges that we face -- we have a payload shroud that we are
restrained to again, I think we alluded to a 10-meter shroud for our
transportation system to get these "elements" that are going to be on
top of landers down to the surface. So any kind of innovative technique
or, technology at doing that -- again that was a notional picture of an
inflatable, but it can be anything. It doesn't have to be limited to
that. Just -- the thing to remember there is the figure of merit is that
how much resultant volume can you get to the surface utilizing the mass
constraint, as well as the package volume constraint of the element
getting to the surface -- mass to volume ratio.

Unknown: We gave a mass constraint in the 10-meter as the shroud, but
the real volume is the 8.8 meters -- I believe -- is that right?

Unknown: The inner mold line of the shroud is more than 8

Unknown: Yeah, so the real constraint is the 8.8-meters

Unknown: No package can be wider than roughly 8 and a half meters.
Height is still open to some discussions, so there is probably some room
for discussion about height. But, the shroud size that everything has to
fit in -- in the inner mold line -- is around 8 and a half meters.

**[Question:]{.underline}** It was stated that water will be scavenged
from landers. How much water is anticipated to be scavenged? Is there a
conceptual system to do this?

**[Answer:]{.underline}** I can answer that. Again, it is in the range
of -- again this is all very rough number -- not based on any
fundamental design. The design question is basically, no. There is not a
design. Conceptually, roughly 400kg of water might be available after
the lander has landed -- depending on the landing profile and the how
trajectories have gone. There is a variety of ways you can consider to
scavenge that and put that to use, and I think we're open to any
interesting idea about the best ways to make use of that. Now, note, it
will be in the lander and how you move it to where you want and how you
convert it to what you want -- will be an open discussion. But, there is
no canned system planned at this point.

**[Question:]{.underline}** It was mentioned that "too many features"
have crept into habitat designs. Is it still a desire to have extra
features (i.e.: redundancy, multi-functionality, safety, reusability) if
these features add no mass? And....is there a priority for added
features?

**[Answer:]{.underline}** Well, for this particular design, I would say
no we do not want to do those, because we want to go ahead and start
with the very minimum. We're going to use this as a building block, and
as we build things back in, certainly if it's a safety feature that
doesn't cause us any other complications -- we want to add it back in.
But, for the beginning we want to start with the - what the very minimum
functionality is.

Additional NASA Comment: Just because it's no mass, doesn't mean it's no
cost.

Additional NASA Comment: And no volume.

Additional NASA Comment: It adds complexity to the design.

Additional NASA Comment: It also includes, it says reusability and
multi-functionality so, that aspect of it -- and I'm not contradicting
what was just said -- one of the features is that for the same amount of
mass -- if you can show or demonstrate a multi-functionality based upon
what that is, and I'm not going to put any thoughts into anyone's head
-- because we've looked at some things -- but, if you can show that you
can introduce multi -functionality into the design concept, I think
that's a plus.

Additional NASA Comment: And I want to take of some of what you were
saying, also -- is from a minimum functionality standpoint -- and I'm
just going to pick on avionics, but it could be anything in there, as a
-- I'll just make a wild example because this could never be the case,
let's say for a minimum functionality inside a hab-element, you needed a
10 processors for some reason -- could be single string to do the
minimum \-\-\-- If you had an innovative concept that said, well -- from
a safety standpoint, if in a degraded mode you could double up those
ten, and put 3 of those processors as a core function as a fail-safe, we
would like those type of ideas because it's still the minimum function
full-on. But, if you went into a degraded mode, are there benefits you
could get from a safety standpoint? So, being open and innovative to
that -- more than just being completely minimum, minimum, minimum about
safety, be innovative if you had that minimum, single string thing, what
could you do with that from a safety standpoint in a degraded mode.

Additional NASA Comment: Ok, we have a couple questions that challenge
us on our sense of contingencies. And minimum functionality.

**[Question:]{.underline}** The ground rules for the minimum function
habitat is that it must support a 30-day contingency extended stay, does
the minimum functionality approach include contingencies or not.

**[Answer]{.underline}:** Ok, so I mentioned before that we provided the
contingency information on more to give you a feel for what has to be
dealt with....I don't....if you started with a 28-day stay -- it's not
likely that contingencies are 30-days on top of 28-day stay. I think if
your idea addresses the concept of contingency, but not necessarily
specifically 30-days, we would still be interested in hearing what that
means. We're not trying to pin-down the details of contingency right
now. And, to some extent, contingency depends on the nature of the
mission overall; which isn't well enough defined to make that a
comfortable discussion.

**[Question:]{.underline}** The 30-day extended contingency stay -- is
that for emergencies or for decisions to extend because things are going
to well? If for emergencies, doesn't that double the consumables storage
requirement?

**[Answer:]{.underline}** Well, we certainly used it both ways in the
Shuttle-era, haven't we? We define a contingency period sometimes we use
that contingency period and really because we've got the resources and
stay a little longer and get more work done. I don't think I'd want to
eliminate either possibility at this point. Contingency in the early
planning tends to deal with more the safety considerations than it does
for extension for activity. But, the nature of the contingency -- how
the contingency period is used is open to whatever you think it should
be used for.

**[Question:]{.underline}** Is this topic only limited to the habitat
element, or can other outpost habitation elements, such as greenhouse,
airlocks, "mud" rooms, etc. be addressed?

**[Answer:]{.underline}** I guess what I would say, is that core element
is what we're looking at and that core element capability.

Additional NASA Comment: ....the basic functionality that you have
doesn't probably have a greenhouse, but probably has an airlock because
you're going to go EVA. We're not looking at core elements and an
airlock; we're looking at core element that provides the basic functions
that you're looking for. So, then I wouldn't take that and say "take
that minimum functionality and apply it to an airlock element also"
because, I would say in that core element, you've got that function. As
it grows, as the outpost grows, the minimum functionality increases,
you're going to get an airlock element and a lab element that may or may
not have a greenhouse. But, I don't think we're going to say then the
greenhouse has the same minimum functionality.

Additional NASA Comment: Right, I think what you need to keep in mind,
again, is that again, as was alluded to -- I call it core capability --
element is used just as a -- it's not an implementation -- I keep
telling these guys that -- telling the B-Team -- it's an element. The
core capability has to provide all those things we went through. Now, if
you can demonstrate that your concept that you're providing evolves to
that growth capability where the concept accommodates things in the
future, such as greenhouses, airlocks, other types of IVA habit-able
volumes that are needed -- so much the better.

Additional NASA Comment: This isn't the design that we'll finally
implement -- it's just the way we're thinking about our design
philosophy so we think we can do a much better job of defending in the
future when those other capabilities come along and we add them back
in...we can say that's why we had to add that capability back in.

Additional NASA Comment: Specifically, greenhouses are not things we're
looking at right now. We want to make sure we're focused on just the
core capability. I think it's primary. Because, without that you can't
evolve to those things.

Additional NASA Comment: Let's just make sure - we're back to the core
greenhouse as an item. We want the core outpost -- or the core habitat
element -- the core we've talked about -- with looking to how you do
evolve-ability. So, evolve-ability would be if you have an airlock
concept -- or the ability to do habitation greenhouse stuff from a
science standpoint later on -- how could your element support evolving
into something like that. So, we don't want to restrict that you have a
concept that is easily adaptable to other elements plugging in -- don't
rule that out.

Additional NASA Comment: Right, but don't make that the emphasis of what
you bring.

Additional NASA Comment: Exactly

**[Question:]{.underline}** What did you mean by accommodate EVA
systems? Suit storage? Suit, well, something else (Don/Duff)? Airlock?
Equipment storage? Other?

**[Answer:]{.underline}** Yes, any core habitation capability is going
to have to have the ability to support EVAs from within that habitation
element or an element -- whatever you call it. So, suit storage at least
ought to be discussed. You might propose a concept that might put suits
storage outside your habit-able volume and that's OK, but you have to -
but, you have to \-- recognizing the fact that crew members will have to
do EVA on a routine basis and facilitate -- you know, your hab element
has to support that what ever way it makes sense and is certainly
appropriate.

Additional NASA Comment: As in -- don't forget about suit maintenance to
a certain extent. A small extent. It was left very generic. Because,
again during the CAT and LAT activity we've looked at sort of specific
implementations for providing EVA capability. So the idea here is that
to not have to structure it too much so that you mimic what we've
already come up with.

**[Question:]{.underline}** What infrastructure/operations should we
assumed? Volumes on the landing vehicle, surface location, means of
transport?

**[Answer:]{.underline}** Ok, basics, right now it's probably safe to -
as NASA mentioned -- one of the architecture team has recommended a
polar location, so assuming a polar location is reasonable -- we gave
you at least the beginnings of an outline of the shroud -- which is the
primary determinator of max volume. Heights are actually not settled in
terms of the height of the shroud. But, the combination of lander and
the payloads on top of it will probably be at least 30-meters tall -- is
what I think we're hearing. So, that gives you a feel for the volumes.
What else was on that list?

**[Question:]{.underline}** Preparation of surface location, means of
transport from lander to the site?

**[Answer:]{.underline}** Ok, in terms of assumptions of preparation --
tell us if you need preparation on the surface. We won't give you any
constraints if that would be important to a concept to bring (inaudible)
forward, something in site preparation ahead of time; we'd like to know
about that. Certainly won't rule it out. Means of transport, assume that
there will be mobility systems of some kind provided to move your core
element. In other words, you don't have to build mobility into the
element itself. That will be a provided characteristic.

**[Question:]{.underline}** Should we assume a standard shirtsleeve
access to rovers?

**[Answer:]{.underline}** Yes, I think that should be something you plan
for. It is fundamental to the EVA concepts that the crew wants to enable
to have the ability to go from your core element to a pressurized rover
in a shirtsleeve environment is something you assume. How you do that --
doesn't necessarily mean they have to be docked together. Tunnels or
other mechanisms could be applied if that made sense.

**[Question:]{.underline}** Do we make decisions on required volume or
area for crew habitability?

**[Answer]{.underline}**: Yes, please do.

Additional NASA Comment: Actually, one of the things we hope to get out
of this is hopefully some useful feedback from the outside community in
terms of resultant volume is and what your rationale is on that volume.
I'll leave it at that.

**[Question:]{.underline}** Here's another good one...How many years
does the core module have to operate before replacement? Total life span
for the initial deployed element. And, is this lifespan number also
applicable to the avionics or does that have a different total life span
number?

**[Answer:]{.underline}** I should have mentioned it myself in the early
part -- we mentioned 10-15 year life span. I think that's a good number
for all the systems to consider. Once we deploy these systems we don't
want - can't replace them quickly or easily. So, a 10-15 year assumption
on life is a reasonable one.

**[Question:]{.underline}** Is mass limit just the shell or does it
include all its stuffing?

**[Answer:]{.underline}** Yes. All the stuffing. It's the entire turkey
at Thanksgiving. It's the element - the structure -- the element
includes the structure itself, the secondary structure, and the
sub-systems that are basically enclosed. Everything inside the package.
Although, subsequent missions can bring up other pieces to outfit it.
But the package comes up on the lander would be the 7,000 kg.

**[Topic 3:]{.underline} Innovative Avionics Architecture and Sparing
Strategies.**

**[Question:]{.underline}** What assumptions should be made re: Earth --
Lunar communications architecture, (which would affect lunar surface
avionics, power, etc.).

**[Answer:]{.underline}** So what we've been trying to do with the
paradigm with operations, is that the lunar base -- since we're going
with a Mars-forward architecture is going -- we're going to move toward
an autonomous operations. So, what should be assumed is the basic
repairs you want to do -- you have the capability and the technology
onboard the surface systems to do that -- that it doesn't require a call
to Earth to ask them how to do the repair. That you've got the
instruction manual there with you and you understand -- and you've got
enough training materials there on the surface to go ahead and do it
autonomously is what the assumptions we've been making in operations so
far.

Additional NASA Comment: Not quite sure where that question was going
...

Additional NASA Comment: The other part of that is, of course it would
affect the lunar surface avionics power needs?

Ok, slightly different direction. So, in terms of bandwidth, for
example, we don't have a defined set of requirements for bandwidth. It
is likely that the bandwidth capability -- the bandwidth requirement
when humans are not there is significantly less than when humans are
there. We haven't defined those in any rational way right now. So, if
you have specific needs, you should define that in your response about
avionics itself.

Additional NASA Comment: And, I think, too, that this is probably the
right time to bring this up, Jim. Might as well bring this up now, is
the potential RFI that will be coming out on common-nav which will be
focusing more on the common-nav aspects. What we're looking here from an
avionics -- again -- what are the core -- assume, and I think this is a
good assumption -- that for the basic comm, you're looking at basic
survival-stuff, more lower bandwidth, operations. It's the higher
bandwidth public engagement-type stuff; I think would be more of an
add-on approach. So, for this, start with the core -- keep the crew safe
-- we're out on roving excavations or expeditions. We could send photos
back to the outpost for additional analysis, but not necessarily having
to put high bandwidth information back to the Earth as part of this BAA.
I think, correct me if I'm wrong, Jim, the RFI will address more the
higher bandwidth, the true bigger picture for comm and nav.

**[Question:]{.underline}** Regarding one-fault-tolerant systems, at
what level of granularity is a system? For example, is a "system" ECLSS
or a whole habitat? Or, does it refer to the outpost as a whole?

**[Answer:]{.underline}** More the first. More like the ECLSS system is
a fault-tolerant. Avionics box might be a fault-tolerant device. We
didn't really mean the whole habitat or the whole outpost as a
one-fault-tolerant. We felt more the sub-system element as a good
answer. Ok, is that reasonable?

Additional NASA Comment: I guess the way I would put it is -- we're
looking for systems and architectures that are fault-tolerant. If you
can demonstrate that you can provide a robust infrastructure to meet the
mission needs without having to go down to -- you know -- triplicating
every last component on a board, that's something that is definitely of
interest. The objective is to minimize the mass, the power, the real
estate taken up -- to be able to do all the stuff we want to do -- so we
can have robust systems -- and there's different ways of doing that --
heterogeneous fault-tolerance systems can do shared resources.
(Inaudible.) We just want to hear what you guys are going to bring to
the table.

**[Topic 4:]{.underline} Long-Term Lunar Energy Storage System
Concepts**.

**[Question:]{.underline}** Will there be any power requirement less
than 2kw?

**[Answer:]{.underline}** For this particular topic, what we're looking
for is energy storage devices that doesn't really address the - that
would be more the scientific instruments and that sort of thing -- we're
not really addressing those. These are more for operational power
requirements.

**[Question:]{.underline}** In additional to energy storage, are
continuous energy generation concepts such as aneutronic fusion also of
interest?

**[Answer:]{.underline}** The answer is yes, certainly, yes. In fact,
we're going to go through a series of nuclear questions in there. So, I
may answer a bunch of these with a statement. We are not ruling out
nuclear. Nuclear power is a viable option -- we hope it is. Now, go look
for nuclear solutions. But, for this topic, we weren't looking for
nuclear responses.

Additional NASA Comment: This is more about how you store the energy
after you generated it, not how you generated the energy.

Additional NASA Comment: The LAT2 is the only one to look at nuclear and
I think that was close to being available, I'm not sure where that is.

Additional NASA Comment: From a detailed standpoint, to summarize a
little bit, what we looked at for the outpost is the nuclear option,
nuclear fission, is what we looked at specifically. Being able to look
at how to produce, roughly 45kw of power and then whether it was a
nuclear system on the outpost or solar didn't matter -- it was a connect
here and then go. So, that's the extent of LAT.

Additional NASA Comment: Clearly, then you've got a nuclear reactor
producing 45kw of power continuously, your need for energy storage is
radically changed. We weren't going to try and address that part of
discussion in this particular BAA. We were under the assumption that we
do need energy storage -- what are interesting ways of providing it.

**[Question:]{.underline}** Have you eliminated nuclear power as a lunar
power option? If so, why? Also do you envision a future nuclear option?

**[Answer:]{.underline}** The answer is yes. We do envision it.

**[Question:]{.underline}** Will a nuclear option be acceptable for
consideration?

**[Answer:]{.underline}** Not for this topic. But, for discussion in
general, eventually, yes.

**[Question:]{.underline}** Does the energy storage concept include
power generation concepts, i.e.: array deployment and configuration? If
not, what are assumptions about bus voltage?

**[Answer:]{.underline}** We haven't made any assumptions so far about
bus voltage. That's something that's open for debate. Topic does not
include deployments or other aspects of that, just the storage.

**[Question:]{.underline}** Power generation is external to the energy
storage system?

**[Answer:]{.underline}** Yes

**[Question:]{.underline}** Please elaborate on net power definition.

**[Answer:]{.underline}** I think what we meant by that is -- there are
potentially things on the energy storage system that require power:
pumps and heaters and stuff like that. We want to have -- if you can
imagine -- a kind of plug going into the energy storage system that
provides power that's available to the external habitat. And, it's that
power that we're talking about. Beyond ancillary, beyond auxiliary
power, just the power that's available to the rest of the outpost.

**[Question:]{.underline}** You might need this one too, depth of
battery discharge. Isn't 100% controlled discharge better to minimize
memory effects that reduce capacity?

**[Answer:]{.underline}** This is goes back to the life of the battery.
And, what it's going to be. This is up to you to tell us if 100%
discharge gives a longer life on the battery than clearly, that's a good
thing. Going to 80% or some lower level number doesn't increase the
memory so much that we degrade the life of the battery, then that's OK
also. And, we're not necessarily assuming its batteries. Energy storage
could be something that doesn't care about discharge levels.

**[Question:]{.underline}** The energy requirement for 400-hours without
sunlight were less than for 120- hours without sunlight. This seems
counter intuitive.

**[Answer:]{.underline}** Yes, that's actually an error on our slide 36.
Yeah, energy storage 2-5kw net discharge electrical power, then the
second line energy storage 100-2,000kw hours -- that's the requirement
in the BAA. I tried to show some power levels for different durations of
energy storage needs and those aren't necessarily requirements there.
What we were really looking at was the first line is the total power
that you -- you're storing. Then the other two are just mathematical
derivations that you have that much power, how much time do you get with
that amount of power. That was my fault; it's a confusing chart. The
real requirement, which is what's in the BAA, is just the energy storage
amount.

Additional NASA Comment: Can you say that again please?

Additional NASA Comment: Since you're on this chart, you said power
generation is not to be considered. Energy storage is totally separate.
Are these not kw hours electric then, or kw electric?

Additional NASA Comment: Yeah, this system might be a little bit
confusing here, but when we think of power storage and generation as
separate, but the energy storage can provide electrical power to the
outpost. So, again, it might be an issue in terms of wording, and that
sort of thing, but essentially what we want to do is look at the energy
storage system that provides power to the nighttime or the times without
sunlight. So, it would still provide power, but the power needed to
recharge the energy storage system, or to refill, or whatever you want
to think about that, the power needed for that is external to that. So,
you don't need to provide a solar array design or some other external
power system to provide power into that energy source to recharge it.
It's just the power -- those power levels are there to provide the
capability during the nighttime period. If that makes sense...

**[Question:]{.underline}** No mention of nuclear electric -- is this
the architecture? If yes, when (initial, later, etc.)

**[Answer:]{.underline}** No decision on when, it wasn't relevant to
this particular topic. We weren't looking for nuclear ...(inaudible)

**[Topic 5:]{.underline} Alternative Software Developments is the next
study topic.**

**[Question:]{.underline}** Does the desire for alternative software
methods necessitate a move away from traditional emphasis on heritage
software?

**[Answer:]{.underline}** Oooh, somebody wants to start a debate! All
right, for the purposes of the BAA, the answer is no. If you feel there
are ways of using heritage approaches or existing software methodologies
that would significantly reduce the cost of traditional life-cycle
models, we'd be happy to hear about that. Probably will want a little
bit more depth in your explanation of why that would work. But, let's
hear about it, I think it would be useful to know.

**[Topic 6:]{.underline} Lunar Regolith Moving Methods & Techniques**.

**[Question:]{.underline}** Is there any preference for evaluation of
Earth-based methods over proposal of entirely new approaches to regolith
handling?

**[Answer:]{.underline}** I guess, for that, entirely new approaches are
great. Earth-based ones obviously carry with them an amount of
experience base that would be helpful. But, we're not entirely against
entirely new approaches either.

**[Question:]{.underline}** How do you see utilizing the Google Lunar X
Prize teams to get early in-situ data on regolith moving and
characterization?

**[Answer:]{.underline}** Obviously, that depends on some extent on what
the Google X Prize participants actually do when they get to the moon.
We would be -- I'll say a generic statement -- we would be very
interested in any type of data that talks to us about the lunar
environment including manipulating that environment in various ways:
wheels turning in the dirt, things pushing dirt around and capturing
measurement information to us would be very, very valuable. That would
all be of high interest to us.

"**[Other" Topics:]{.underline}**

**[Question:]{.underline}** Under which topic does lunar regolith oxygen
production fall? This is ISRU type.

**[Answer:]{.underline}** Actually, we don't have a topic, which is
looking for inputs on how to produce oxygen from the regolith. The topic
we picked for the particular go-around was moving regolith around, which
might be a part of process of generating oxygen. But, we're not
interested in answers today on how to produce oxygen. That might be a
topic for future BAA though.

NASA: And, if there's multi-functionality on the - that is able to move
the regolith around ...

Additional NASA Comment: Yeah, I guess if your tools for moving regolith
around were integrated with a system that could produce oxygen from it
-- that might be of interest to us. We probably be more interested the
tools for moving it around right now.

**[Question:]{.underline}** Will NASA provide an opportunity for outside
entities to contribute concepts and technologies to other surface
systems; particularly rovers, robotics, and EVA support systems?

**[Answer:]{.underline}** Yes, we certainly hope so. Someone mentioned
-- one of you -- somebody mentioned you know this was just the first
go-around of topics for release of interesting proposals. We hope to
continue this BAA activities that was relevantly hard to come up with
--you know we have a much longer list than 6 than we started with -- the
idea of other areas where we could use interesting and new ideas -- we
chose this 6 for this go-around for breadth reason as well as triggering
some areas we would like to see some early thought on. But, all the
topics mentioned -- plus additional topics are probably viable for
future BAAs.

**[Question:]{.underline}** Please discuss communication requirements
from Earth to moon, and on the moon (voice, video, data).

**[Answer:]{.underline}** think in relationship to all 6 BAA topics the
comm from Earth -- from lunar to Earth is probably outside the bounds of
any of these 6 BAAs. Probably just leave it at that. Other than
re-mentioning the RFI or the potential RFI that could be coming out --
would address that. But for the sake of these 6 topics, I don't think
any of them need to address Earth.

Additional NASA Comment: We weren't expecting anybody to address
communication capabilities. If the question was more aimed toward
saying, you need to understand what bandwidth might be available -- if
that was your issue, we could probably get some early estimates. For the
sake of these BAAs is -- one of the requirements for the hab was to be
able to operate on the lunar surface when the crew is not there. What
bandwidth do you need -- from the Earth to be able to communicate --
give the I'm Ok, you're Ok -- those kinds of things -- so what's the
minimum bandwidth - approach it that way for this BAA.

**[Question:]{.underline}** Will NASA publish the results of these
contracts?

**[Answer:]{.underline}** Yes.

**[Question:]{.underline}** Will the slides be available from the
presentation? Where? When?

**[Answer:]{.underline}** Yes, later today on the
www.exploration.nasa.gov site. Where you were able to register for this
meeting.

Additional Question: Will you leave them up for awhile?

Yes, we will leave them up for the duration and maybe find them a new
home after that but we'll make them available.

**[Question:]{.underline}** There seems to be a strong direction toward
"industry" providing the innovation and ideas. Universities have
provided significant innovation in the past exploration endeavors. What
is the vision for how universities should participate over the next few
years and this BAA?

**[Answer:]{.underline}** This BAA -- and all of our activities are
completely open to the community -- we tried not to call this -- and
actually if you go back to all of our communications about this
particular day and this event, and the BAA, it does not say this is an
"industry day". We are at the Chamber of Commerce but it was open to the
community. We want to engage universities in this effort. They are a
source of great ideas and experts so we solicit and encourage your
participation. The Chamber of Commerce provides a great venue and access
to -- industry, traditional, non-traditional, aero-space and others
which we've tried to reach through -- not just through the Space
Enterprise Councils -- but also through the Chamber sending this
information out to all of their members. And, there's not, or at least
I'm not aware of, a particular venue to get something like that for
communicating to all the universities, but the university systems are
being encouraged to participate.

I would follow-on with that, if you know of a venue or think of a way to
get it out there, please let us know. And, we absolutely want to make
sure the universities and academia are engaged in helping us come up
with the innovative ideas.

Additional NASA Comment: That concludes all of your questions. So, we
look forward to your proposals