Tip:
Highlight text to annotate it
X
>> Michael Miller: Good morning.
I'm Michael Miller.
I'm here to present the OZ3 payload engineering
integration overview.
Next chart, please.
So I'll apologize ahead of time.
I've seen a lot of beautiful pictures of payload science
and my charts have only words and no pictures, so bear with me
and hopefully you'll stay awake until the end.
So basically our activity starts out,
we have ICD engineering assigned
after the payload becomes a serious payload, and they work
with a payload developer on ICD development.
We tend to support the design reviews, provide comments,
hopefully keep the payload out of trouble in the design,
perform analysis for stage analysis,
identify any guidelines and constraints that come out of
that stage analysis or any of the exceptions.
We process requirements exceptions.
Verification products are tracked, reviewed and approved.
We support the human factors integration team
and the ISS payload label approval team supports
the payloads.
And we provide support for the acoustics evaluation
of your payload and some design guidance there.
And we also manage cold stowage assets
that I'll list on the last page.
Next chart please.
Okay. So early on in the payload development,
we assign an ICD engineer.
And their job is to work
with the payload developer to develop an ICD.
We typically try to do that at the PDR.
You have a good draft for the preliminary design review
and a final baseline version
around the critical design review.
The ICD documents payload interface to the space station.
It doesn't document any
of the internal interfaces the payload has.
And track that with all the other payloads to closure.
As the data comes in, the PEI team is assigned
to disciplined experts to review the data.
And our goal is, you know, that your data comes in, it's good,
it's clean and it gets approved as is.
Sometimes the discipline engineer may go back
and say hey, I think you missed a point here,
can you clarify this or you didn't really address this part
of the verification, can you go back and do that?
It may also be rejected.
Say you sent in the wrong verification
for the wrong requirement, that'll get rejected
and you'll have to bring that back in.
PIRNs, any PIRNs, which are changes
to the applicable requirements since the ICD was approved,
must also be assessed via the RCAR process.
That's a requirements compliance assessment report.
And so basically you're going to look and see did any
of these new requirements affect my design,
affect my verification?
If not, you just send in a memo that says no, we've assessed
that and it's no problem.
Or, if it did, then you say yes, we've assessed that,
here's the changes to my verification
and we close that out.
We include the PIRNs that needs to be assessed
in our OZ CoFR letters.
Those come out about five months prior to flight.
Next chart please.
H fit and I plat support.
The human factors integration team basically helps
out your payload development team
by performing the verification for human factors interfaces.
They use a team of astronaut and crew representative,
Boeing and NASA human factors experts,
they complete all the paperwork necessary to close
out those verification requirements.
And we found that, you know, this is a valuable service
because a lot of the payload developers are not familiar
with these kind of requirements.
And so these guys come in, they work with you on your design,
they make sure it's all good, and then they close
out your paper so you can close out a big chunk
of your requirements with that process.
And they can also support early development and give guidance.
You know, your design reviews or if you have questions.
The ISS payload label approval team also provides a service
to payloads.
They review the payload drawings and photos
of the payload hardware.
They help you with your payload label requirements.
They verify that you meet those requirements.
And they assist in the ordering
of the labels from the decal lab.
Next chart please.
Oh, this is my last chart, I think.
So, the other thing that OZ3 does in addition
to the requirements and ICDs things,
we manage the cold stowage assets that NASA owns.
That includes the cold bags and ice brick,
and we've got several different temperatures
of those ice bricks listed.
The Merlin refrigerator freezer, and it's also an incubator
and the Merlin currently is on board.
The crew is using that in their galley for their vegetables
and cold drinks right now.
The Glacier freeze can get as low as minus 160.
I think we, right now, are planning
to operate around minus 130.
We had some payloads having some difficulty verifying
through the extreme temperatures,
so we backed off to minus 130.
But it has the capability to go lower if we need to.
The Melty, the minus 80 lab freezer for ISS,
it's got several different temperature ranges.
On orbit we have several units of that.
And that's really where we store a lot
of the payload science ware we bring home
with glaciers and cold bags.
The Melty is our on orbit storage of this ice.
The cold stowage team works with payload developers.
They plan the assets needed for ascent, on orbit and descent.
They also provide some testing support fit check
and the assets selected.
And I guess I do have a few pictures
of my cold stowage assets here.
Now I went through that pretty quick.
I'm trying to keep you awake
since I didn't have any pictures.
Did you have any questions or thoughts,
especially easy ones I like?
Nobody? Yes, go ahead.
>> You mentioned a list
of the ICD type documents earlier in your presentation.
Are they available online to look at?
Because I could imagine knowing what's
in them could dictate what research
or science you could or would want to do.
>> Michael Miller: Yes.
We have them on our NASA website.
I'm not sure that all of you can get to that.
What we probably ought to do is we probably ought
to make a CD and distribute that.
We have to worry about export control and things like that,
so we can't just make it on a public website.
But if you could indicate that you're a U.S. Citizen,
I think we could probably build a CD and send that to you.
>> Thank you.
>> Michael Miller:
That's probably something we ought to do [inaudible].
Thank you.
>> One of the other presentations talked
about an experiment [inaudible] where you can do algorithm data,
but I didn't see it on your ICDs.
How do you interface with that?
And I think AIMS is the one that said they own that.
>> Michael Miller: Right.
So we have an ICD with spheres
and they have documented their applicable requirements.
So if you were using spheres, you would probably,
in a new hardware, you would add to that ICD that we manage,
so the list of books I gave you really was the requirements
books that are used in the ICDs.
But we have another really big list of ICDs
with the different payload developers.
And so spheres has an ICD.
If you are just using the spheres
and just doing algorithm development probably there would
be no affect in your ICD.
You would work with that team and they would set
up your algorithms, but we've already approved spheres.
We already have verification data.
If you're bringing new hardware, we've had some payloads proposed
to attach hardware to the spheres, then we'd have
to *** that, we'd have to add that hardware
to that ICD and evaluate that.
And you know, for the launch requirements,
we'd have to put those in there too for that hardware.
>> Thank you.
>> Michael Miller: Okay.
Thank you.
[ Applause ]