Tip:
Highlight text to annotate it
X
>> Okay, the next overview presentation I have for you is
to make you aware of what we call the lean payload
integration process.
And this is fairly new.
It has been in work for probably the past year and a half or so
across all of the OZ payload integration and ops teams.
And so let's move on to the next slide.
And someone alluded earlier to the scheduled time frame
of how long the integration process takes,
and through our experiences we found that we were
in a situation where a lot of payloads we were made aware
of them much closer to an anticipated launch
from the templates you saw earlier today reflect.
And we found we've had to work at integrating payloads
at a much more expedited fashion.
So we though well, we're working this madness,
let's try to put a method to the madness
and actually define a process
that can accommodate payload integration
on a more expedited schedule and we call that lean.
When we set out working this our goal was
to achieve a six month payload integration template.
Please do note that your payload development template
to conduct your research remains as is.
But our payload integration template,
how late can we become aware of you and work all
of the interfaces and integration products
to get your launched in your on orbit operations
and post landing operations adequately planned?
Now why did we choose six months?
Well, that very responsive template,
knowing that our national lab customers may have a more
limited funding and desire a more responsive timeline.
And it does drive out payload developers having
to submit multiple iterations of information over time
as you're maturing your payload design.
That helps you.
That helps us as well, because we only see the data one time
and we know that it's good, valuable data
to integrate into our products.
There were some guidelines established for this.
You'll hear more about the payload safety review process a
little later today.
That remains unchanged so we couldn't do anything
with the safety review process.
We couldn't do anything to change agreements
that are already established
with the crew office regarding crew training,
things along those lines.
Whatever we did we had to maintain overall ISS safety
and payload interface integrity.
So that's what drove us as we looked at doing this.
What has come out of this?
Well, we have characterized a set
of payload operational characteristics
that I'll go over with you.
And we've looked at aspects of hardware and software
for express rack payloads
and for microgravity sciences lock box payloads.
Things about those types of payloads and characteristics
that we could accommodate in a more streamlined fashion
and maybe you'll be able to fit into one of these areas.
Although we have focused initially on express and MSG,
as we get familiar with this lean integration process
over time, we want to expand that to research
that might be hosted in other areas.
So this is our starting point.
And in order to accommodate all of this,
you'll see something that's very different, a gate process
that we have defined to work with lean payloads
as we carry them through the integration process.
One of the primary things we have done is implemented ship
and shoot testing.
Kentucky Space referred to that process yesterday
and I'll give you a little bit more detail about that as well.
Page 30 please.
Okay. First of all I'd like to focus toward the bottom part
of this matrix here, an overview for you,
operational characteristics that really will apply
to any lean payload, whether it's express or MSG.
So if we go through the bottom portion of the matrix there,
if your payload will not have any crew displays
or required any unique skills to get it established,
you can use your standard procedures
for maybe your host facility.
You can qualify as a lean payload.
The crew interaction would be limited to set up, take down
and some sort of sample exchange.
The crew training is minimal.
The ops team and the astronaut office would review your payload
and agree on consensus that your training could be conducted
pretty much on board through self study crew based training.
Your payload would have to be able to fit
within predefined operational characteristics,
which are placed on the mission plan early on.
And you could have standard ground command services
from one ground command site only.
So think of things as operational characteristics,
if they apply to you, you might be able to fit
within the lean payload box.
Now if you're an express right payload,
we have three different types of hardware configurations
that might be applicable to this process.
If we start with the E1 column,
your express rack payload would be a single locker equivalent
in size.
It would be soft stowed with no services required during its
launch or return to earth.
We would capture all of your engineering interface
verification data, which Mike Miller just talked about.
We would capture that via the ship and shoot testing process.
And your resources would generally fall
within this range, about 150 watts average power.
You could be air and or water cooled within the express rack.
You would have Ethernet data transmission only.
And you would not require any of the resources for gas supply
or vacuum interface, which can be made available
for express sub rack payloads,
but it would not apply to a lean payload.
Your software architecture that you put in place, your help
and status, commanding telemetry,
everything I just talked about, would comply
with a pre-built generic C and H data set
that we have established.
And we will have more information available
on the specific characteristics of that.
It's very generic in nature.
It could capture, it's very well bounded to capture most
of the things we have seen needed within a CH data set
so we can provide more information to you.
Okay? So if you meet everything in column E1
in the ops characteristics, you can be a lean express payload
but go on a different integration track.
Similarly, if we look over at E2,
which would be an express payload that's a re-flight,
again, you're single locker equivalent,
you've previously flown,
again you're soft stowed during your launch and your return.
For your verification, there's already a process in place,
a fairly simple process for re-flight payloads.
Or we could capture your interface verification data
using the ship and shoot process.
Up to you.
We could coordinate that.
Regarding your software interface,
if you've flown before we could reuse the C and H data set
that you already have placed in the PDL
with no changes to your data set.
That's another candidate for lean express.
And then the column E3,
you could be a small deployed payload at an express rack
or in front of an express rack and get a power supply fed
to you from the express rack.
Here are envelope bounds of sizing considerations
that would qualify you as a lean deployed express payload.
And again, you would be soft stowed
with no services required.
And you would not have a software interface.
So, if you're a candidate to do your research in an express rack
and you can comply with all of this, we'd like to work
with you using the lean process
and I'll tell you a little more about that.
Okay. If we go to page four, this is a similar matrix
for lean MSG payloads.
Again, down at the bottom,
you'll see that the flight operations characteristics are
the same as they were for express.
If we look at the M1 column and look
at the hardware characteristics, the MSG payload would be smaller
than a locker equivalent in size.
It would not require any resources
to conduct its research.
It would be soft stowed during launch and return.
The toxicity level would be zero, no unique hazards.
The safety reviews would be conducted out of board.
You'll understand that better, I guess,
after the PSRP overview today.
The verification for this lean MSG payload would be
certificates of compliance.
And no EMI testing would be required.
As far as the software for this type of lean MSG payload,
no requirements for commanding or telemetry,
any data of video downlink would be limited
to the normal capabilities the MSG facility provides regularly.
There would be no crew display, so very simple research going
into the microgravity sciences glove box.
Looking over to the right column, column M2,
that could be a little bit larger in size.
Again, soft stowed.
EMI testing could be conducted, but when you show
up around six months prior to launch,
they already want your EMI testing to be completed.
You can require power if you're an M2 lean MSG payload,
as long as you don't require more
than 500 watts in power and cooling.
Here's information about your toxicity level.
Only one level of containment or less is required.
The integrated safety reviews have been conducted out of board
and you will have simple verification testing, the ship
and shoot testing, which I'll overview in a little bit.
As far as software, your M2 lean payload can be operated
from the ground.
All the data transfer commanding is done via the standard MSG
laptop computer server, which is there available to you
and only the standard displays are needed
to conduct your research.
There's no unique crew displays.
Okay? If we move on to slide five.
I've overviewed for you the types of payloads that could get
on the lean integration track.
Now I'm going to overview for you the gate process
that we have established to assess and manage this
and usher a lean payload through the integration process.
Down at the lower portion of this slide, the blue blocks,
you will see key things that the payload developer needs to do
within the lean integration process,
and then the upper level are key items
that the payload integration team, we will be concerned
about within the lean integration process.
You'll notice there's not really any time frames on this chart.
The only time frame is as late as seven month prior to launch,
you could be manifested.
So everything, gate one, gate two and gate three,
the time frame can be conducted as appropriate
with your payload development cycle.
Okay? So let's look at gate one.
This would be when you initially contact NASA regarding your
payload and it would be very good
to provide the two pager information
that Ryan Lofton showed you earlier.
Give us some very initial information
about your lean payload.
NASA becomes aware of it, a strategic PIM will start looking
at that overview information and contacting you.
And what the PIM will do, if the PIM thinks you are a candidate
to be a lean payload, is he'll call a review meeting together
with key people, noted down there at the bottom
of the slide, the host facility lead if you're going
to be integrated into a facility, a representative
from the engineering integration office, software integration,
operations, point of contact
from the payload safety review panel and a crew office rep.
They will meet with you early on,
probably ask you some more questions.
And if you meet the characteristics I went
over on the previous two slides, we're going to say okay,
we're going to integrate you as a lean payload and put you
on that integration track.
You still will establish a program agreement, PIA,
and have to get your export compliance conducted,
but you'll be put on the lean integration track.
Okay. So let's move over to gate two.
You'll notice down in the payload developer world,
you're still developing your payload.
And the blue block above that with the items you'd need
to complete, we call that early work that we require from you.
We tried not to require any work prior to you coming to us
about seven months prior to launch, but these are things
that require some amount of time and you're best to try
to get this early work conducted.
So these are things you would still need to do early on,
even if you're in the lean process.
You're still marching through with your payload safety reviews
as required.
You have heard reference to operation nomenclature, NOM,
that's the official name of your payload
and information about your hardware.
You really want to go ahead and get into that request cycle
of getting all of that ironed out.
As you are going through your payload design, you still want
to have preliminary help from the H fit
and I plat organizations, which Mike Miller alluded to,
your human factors about the labeling,
you're planning for your equipment.
They can look at your design early on,
help you correct things if they're not in line.
Early on you're going to have a sussessment review as well
and meet with representatives that are called together
for an ops training strategy team.
Carmen Price will tell you a little bit more
about that this afternoon.
And again, as I mentioned in the previous presentation,
if you're going to be operating from a new site,
ground site remotely, you want to go ahead and start working
with the integration team to get that put in place,
so very minimal set of early work while you're completing
your payload development.
So when you do complete that early work,
you want to let your PIM know, you want to stay in contact
with your PIM and your PIM can answer questions.
At the end of gate two we're going to look
at this early work, make sure everything's on track.
If something has changed between gate one and gate two
about your payload, your hardware or your software,
we still want to keep you on your lane track.
We might have to, at the end of gate two,
assign some additional information that you're going
to have to get to us so that we can keep you on the lane track.
All righty?
So hopefully you're still in the box.
We move on to gate three
where really you are completing your payload development,
completing your phase three payload safety data package,
and you're developing the lean integration data package.
And we'll go into more detail on that in the following page.
Again, it's an attempt at a minimal set
of integration data you need to feed into the program
and we take that and work
that to get you manifested and operated.
So your PIM, you and your PIM will get your information to us
and we will hold a review then at the end of gate three looking
through all your lean integration data package input
making sure everything's complete.
And we will, at that point,
that review team will target candidate launches.
It could be roughly seven months from that point and time.
And the change evaluation form that George talked about earlier
to officially get you manifested on to a flight.
Okay? That can occur as late as seven months prior to launch.
So yea, you're manifested for flight.
Then what happens?
Gate four pretty much can be six months prior to your launch
where you're going
to be providing final input to ops products.
You'll learn more about that this afternoon.
Your hardware needs to be available
for the ship and shoot testing.
We'll talk a little bit more about that.
And as a PD you're going to support that required testing
and help us feed in appropriate information
about your certification and flight readiness
as we're coming out of your testing.
Our integration team will be conducting ship
and shoot testing with you.
We're going to be completing the standard integration things
that we deliver on our side of the house.
And the ops community will be finalizing all
of the operations product development.
Okay? Let's move on to the next slide.
This is a chart which lists everything you submit at the end
of gate three as part of your lean integration data package.
There is technical data that we'll request from you.
For express sub rack payloads we have a new tool called the lean
integration data sheet asking you information
about your resource uses.
The MSG host facility has an interface requirement sheet
that you will complete at that time.
And that's used by the engineering community
to develop your ICD and to tailor generic ship
and shoot tests for the specific interface resources your
payload has.
As far as hardware in your lean integration data package you
submit your own orbit drawings, you're going
to submit information about your hardware physical
characteristics so that we can put it into the system,
get it into the payload tactical plan, which George talked
about previously, so we can keep track of your manifest
and return requirements, your call stowage data.
Additionally we'll go into the system,
you provide us information about that as well
as if you have any waste, any elements that can be disposed
of after your research is complete.
You'll provide that input to the program.
Let's see, key environmental tests such as off gas testing,
vibration acoustics, EMI and EMC.
You can have those things conducted prior to gate three,
and that's probably a good idea.
But if not, well, if you do have them done prior to gate three,
go ahead and turn in those results.
And if not, I think Annette Sledd will be talking
with you this afternoon about some capabilities at Marshall.
There's capabilities at other centers also
for hosting this environmental testing.
But if you have any test results
from those environmental tests prior to gate three,
turn those results in so
that engineering community can start taking a look at it.
As far as payload operations,
we're going to need your training material turned
in at gate three.
And remember, these are payloads where training can be conducted
on board, so you would want to have a cut
at your ground base crew training material, turn that in.
At that point in time also,
you'll then in preliminary information
about your mission planning, you know,
how much crew time you need, how, what type of resources,
your resource level and durations
so that the mission plan can start to be refined.
And you're going to turn in your preliminary crew
and ground command procedures for the integration team
to pick those up and continue refining those.
Regarding payload safety,
you should have your phase three safety data package conducted,
not conducted, turned in for review at that point in time.
And also, a ground safety checklist, which is going
to flow with your lean payload as you work through ship
and shoot processing through your bench review and arrives
at the launch destination.
Okay? Next slide.
Now I'm going to tell you a little bit more
about ship and shoot testing.
And the purpose of ship and shoot testing is
to get your payload and verify the interfaces your payload has
with express or MSG.
Within the ship and shoot processing you're not having
to submit a bunch of individual verification closure items
to be reviewed by the engineering community.
The benefits of this are is provides a lot of efficiencies
for ship and shoot processing to conduct that verification.
We can also get your crew procedure review performed
during the ship and shoot processing time frame.
We can also get a final look
at your human factors considerations and your labeling
for final review, all within a single activity.
We'll bring everybody together to ship
and shoot process your payload.
As I mentioned it does eliminate the verification submittals
that you as a payload developer have to provide
into the engineering integration organization,
reducing your overall cost and time
to generate that information.
It does, on our side of the house as well,
reduce the PEI workload for tracking
and evaluating each individual verification data package.
And it does support crew procedure validation
with the hardware, as I mentioned.
Okay. Moving on to page eight, this is a general,
high level flow of the ship and shoot process.
We are developing a ship and shoot processing guide book
to have available to you, so if you're a candidate
for this you'll understand how ship
and shoot processing is conducted.
First of all, your lean payload will arrive at Marshall
and will be handed over for ship and shoot testing.
There's some pre-integration tests that we're going to do
to characterize your power characteristics before we
actually integrate you
with express rack flight equivalent unit,
or the MSG ground unit.
We will conduct a test readiness review going over all
of the technical data you've submitted to the program,
and your overall ship and shoot test plan.
We'll integrate you with the express or MSG test set up,
collect your data, execute our tests, collect your data,
and also conduct crew procedure review, if there's interactions
with your hardware and your software at that point in time.
If you're an express, water cooled payload,
then when the ship and shoot data collection is all complete
you'll be processed to have your fluids discharged
and injected properly for the launch environment.
They will do a final verification
of your human factors requirements at that point
in time and you'll be prepackaged into your CTBs,
cargo, not your cargo transfer bags, you'll be pre-packaged
into your bags which will then go into CTBs after you arrive
at JSC and the bench review is performed on your hardware.
We expect this typical flow to be about an eight day process,
eight to 10 day process overall.
Your payload hardware will not be returned back to you
after ship and shoot testing.
Coming out of block five, 1.5, your ship
and shoot data collection, it's not shown here,
but the engineering data will be reviewed
by cross functional teams
to make sure all the data collected meets the require,
meets the ranges that we expected at payload interface.
And hopefully all of that goes smoothly.
And let's see, look at note three there,
it says your off gas, vive, acoustics,
EMI or EMC testing may be conducted
at Marshall at the PD expense.
The PD should coordinate with their PIM as early as possible.
And again, you could get those environmental test conducted
prior to entering the ship and shoot testing flow at Marshall,
or you could have them conducted earlier elsewhere.
Okay? Next slide.
I believe this is my final chart
and please keep it as a reference.
It'll mean more to you
after Carmen Price's discussion this afternoon.
But it pulls together all of the operational aspects
for a lean payload and shows you, reminds you again,
during gate two there's a good bit of early work all related
to ops integration that needs to be conducted.
At gate three, as part of your lean integration data package,
again more ops integration work is requested of you.
And then as far as the green task bars,
the ops integration community pretty much takes your input
and does their standard things that do at that point in time,
which would be roughly six months prior to your launch
and hopefully the start of your on orbit operations.
Next slide.
I was right.
That was my last one.
Okay. Question on this?
[ Silence ]
>> I've got a couple questions about this ship
and shoot testing that you talked about there.
It looks a lot like PRCU testing
that was conducted previously at the Cape.
But there's some components missing,
for example do you do end to end data testing?
>> Yes.
>> As a part of that ship and shoot.
>> Yes.
>> Okay. So it really is just moving PRC testing to Marshall,
which gives you then the ability to conduct some
of these other tests with other facilities that are there.
>> Correct.
>> One question I have then, one last question,
most of the people here are talking
about biological based payloads.
A concern I would have is the statement that you hand
over your hardware at the end of this testing
and that it goes directly to bench review
and you don't see it again.
So I'm wondering are you contemplating some kind
of a hybrid process, because biology can't go months
beforehand in most cases.
>> Yes.
>> And get wrapped up like that, so some component
of the payload is going to have to come late.
>> Exactly.
If you have late load items, you know, things that need
to be environmentally controlled,
I think we would handle those items per the standard process.
>> But it might be possible to still use this lean process,
even though you don't really fit that component.
>> You could use it for your hardware itself, you know,
if you have new hardware going.
But as far as your biological component,
which is time critically controlled, you could send
that up additionally, you know, in the freezers,
work with cold stowage, or work with another.
We could process that through a late load requirement.
>> Okay. Thank you.
>> So, yes, I think we would work that.
[ Silence ]
>> Do any of the soft stowage requirements change depending
on the vehicle you're going up on?
>> I don't believe so.
I believe OZ has developed a standard set
of carrier requirements regardless
of your transportation vehicle.
We could certainly get you
that requirement [inaudible] to make sure.
I don't know, can anybody help me answer that from OZ?
[ Silence ]
>> Yes. We have a requirement set based
on the common interface requirements document the
vehicle uses and it envelopes all the different
launch vehicles.
And so we would just invoke that set of requirements.
>> But as far as soft stowage, do you know offhand
if there's any differences on the vehicle?
>> The different vehicles do have different loads.
Typically for payloads, because it's not critical for crew
or mission, the payloads can choose to take the risk
in the soft stow if they're not safety critical structures.
If they're safety critical structures, then they have
to analyze the loads and there's things like pressure bottles,
glass, things like that.
Or if they're hard mounted, during launch obviously,
you know, powered middeck would be a safety critical structure.
But the other items, they could say I'm
in foam I'm willing to accept the risk.
>> Would you give those loads to the developers
so they know whether to take that risk or not?
>> Yes we would had that set of requirements referenced
in your payload unique ICD.
And the common RID has the envelope of loads.
And then it also has in the appendixes the unique loads just
for reference if you know exactly what vehicle you're
going on.
>> I had a question, like, are you guys double up in something
like OB doubled up on common IRD where they have common set
up storage requirements for [inaudible]?
>> Yeah, rather than developing something new, we just represent
that data and then we tailor it for payloads, you know.
So, instead of something that might need a vehicle process,
we would point to the payload process.
>> Thank you Mike.
Any other questions?
[ Silence ]
[ Applause ]