NASA Johnson Space Center Oral History Project
Commercial Crew & Cargo Program Office
Edited Oral History Transcript

Frank DeMauro
Interviewed by Rebecca Hackler
Dulles, Virginia – 4 June 2013

Hackler: Today is June 4th, 2013. This oral history interview is being conducted with Frank DeMauro at the Headquarters of the Orbital Sciences Corporation in Dulles, Virginia, for the Commercial Crew & Cargo Program Office [C3PO] history project. Interviewer is Rebecca Hackler, assisted by Rebecca Wright.

Mr. DeMauro serves as Orbital’s Vice President, and is also the company’s COTS [Commercial Orbital Transportation Systems]/CRS [Commercial Resupply Services] Program Director. Thank you very much for taking the time to talk to us this afternoon, and we’d like to start by asking you to give a brief overview of your background and how that got you to the position you’re in today.

DeMauro: Thank you for talking to me today. I’ve been in the space business about 25 years now. I graduated from Rutgers University [New Brunswick, New Jersey], so I’m proud of that. I originally was a thermal engineer, until the mid-’90s when I moved into systems engineering and did that for a few years. I made my way into business development from that point, in the commercial geo [geosynchronous] communications satellite arena here at Orbital. I’ve been with Orbital 21.5 years at this point.

I did business development and systems engineering in the geosynchronous satellite world for a few years, and then I eventually moved into program management on that side. I managed a couple of development programs. First the Optus Program, which was a development program where we enhanced the capability of our geosynchronous spacecraft bus, the StarBus. Then I started on another program for SES [S.A., satellite company], where I managed the development project of an even larger GeoBus. I’ve managed programs with development before, and that is coming in handy right now. After I left the geo group, I became the Vice President of Engineering for Orbital in our technical operations group. I did that for about a year and a half before they asked me to take over as the Program Manager for COTS and CRS.

I think it was a combination of my background in program management and managing development programs—and this is certainly the biggest development program we’ve done here, on the spacecraft side at least—but also my experience working on the commercial side because this was, even with NASA, a commercial program. That all fed into being asked to take over this particular job, and I’ve been in this position now for three and a half years.

Hackler: With all that background you had in business development and the commercial side, were there any aspects of that in particular you felt like you applied to your work on the COTS program?

DeMauro: For sure. I think the biggest thing for me on the commercial side was we were obviously doing these programs on fixed-price contracts and on relatively short schedules, so it’s important to take the commercial practices, which are about efficiency and about quality—not only my experiences, but the company’s experiences—and then apply those on COTS and CRS.

One of the things I thought long and hard about when I took this job is, “Okay, it’s a commercial program, but it’s with NASA. How is that all going to work?” I will say, quite candidly, that I was pleasantly surprised at how willing NASA was to embrace the commercial aspect of the program. That’s not to say there weren’t hiccups along the way, but I think all in all, both C3PO and the ISS [International Space Station] Program Office recognized that it was a commercial program.

Certainly there were aspects of managing a commercial geo spacecraft for those customers that are different from managing a spacecraft that’s going to rendezvous and berth with the Space Station. There are certainly some significant differences there. In terms of how to manage the program efficiently, how to apply a production mentality to a program to get as many efficiencies as you can, how to manage your suppliers to deliver their hardware on time, to minimize change, which always costs money and costs schedule and adds risk—those types of things are some of the things I really focused on and tried to manage it in as commercial a way as possible.

Clearly I recognized right off the bat that given the safety requirements, the fact that we were dealing with humans here on the Station, we need to make sure, first and foremost, that no harm is done. That’s a different environment than I worked in on the geo communications side. That’s delivering a spacecraft, making sure it’s operating because those customers are paying money for their business plan. This is a different approach. It really took a combination of commercial practices to manage the program, but recognizing that it’s a different type of program, and that those approaches need to be modified to make sure that this customer, NASA, is getting their requirements satisfied.

I will say that one of the things I was also pleasantly surprised about is how willing NASA was to listen to what we said in terms of how we would design and build a spacecraft, and then inject their own experience, and then work together collaboratively to figure out, “What’s the right way forward?” I’ve never had a sense of NASA saying, “This is the way we’ve always done it and this is the way you have to do it.” I think, on the flip side, we had a similar attitude. We didn’t go into it saying, “This is the only way to do it.” I think both sides were good listeners.

Hackler: Can you think of any specific examples you can share with us about some of the issues you had to negotiate with the ISS Program Office visiting vehicle requirements?

DeMauro: Let’s see, examples, let me think about that for a minute. The first example that comes to mind is there are certain electromagnetic requirements on the spacecraft—how it has to operate, what environments it has to be tested to. As we went into the process of testing the spacecraft and writing the test plan and then sharing that with NASA, there were just some disconnects in some interpretations of the requirements.

It was an example of where we had a way of doing it and we interpreted it a certain way, and there were some folks on the NASA side—our interpretation may not have been consistent with the way they meant it to be. Rather than them just saying, “Well, your interpretation doesn’t matter. You have to do it our way,” they were willing to listen to why we interpreted it the way we did, and come up with a way that made sense. They were satisfied, we were satisfied. I think both sides found the right common ground without giving up the technical integrity of what was trying to be achieved.

I think that’s one of the critical things about this whole program, that no shortcuts were taken. It was just finding a way that both parties could be satisfied. There were other examples in the RF [radio frequency] area where maybe there were some requirements that were set forth that we interpreted a certain way, and that may have been different than how it was intended. Our RF team worked very closely with the NASA RF team to figure out what’s really important, that you really have to have, and maybe what’s not so important. “Let’s find a way to use the components we bought, and based on the specs [specifications] that we wrote in the system, that has to fly.”

That does a couple of things. One, it allows you to go buy things in a commercial way that may not be completely off-the-shelf, but aren’t redesigns, which saves money and saves schedule, but also saves risk. We can then take that efficiency and those savings and pass those along to NASA and make this commercial-type venture work.

The one thing I’ll say about the requirements that we’re working to in the program—I think both NASA and Orbital would agree that the IRD, the [Interface] Requirements Document to which we worked, had a bit of evolution to it. It was written in a certain way at a certain time by a certain group, and then as the program moved along I think NASA realized, “Well maybe that’s not exactly what we wanted. Maybe we wanted to be more stringent here, or maybe we should have added more requirements here,” or the vice-versa, “Well, we really don’t need that.”

I wanted to raise that point because that’s another area where NASA recognized—they didn’t just come in and say, “It doesn’t matter how we wrote it before. This is what we need now.” It was, “Okay, we should have had this requirement and we didn’t. How can we get close to what we want?” Again, it was that collaboration. I think it’s important to point out that it wasn’t stake-in-the-ground, no flexibility. I think that’s important.

Hackler: We talked to a couple of the Antares [rocket] folks yesterday, and we were wondering if we could talk to you more in-depth about the development of the Cygnus capsule. Specifically—you talked about buying items commercially—Orbital has an international collaboration, using proven hardware and systems that you were able to incorporate into the Cygnus vehicle. Can you talk a little bit about that philosophy?

DeMauro: Our design philosophy was it’s a commercial venture, we’re on a fixed price, so we need to be able to do it in a cost-efficient way. We need to have very low risk, obviously from a safety point of view, but also from a raw ability standpoint. It doesn’t do NASA any good for us to be so safe that we never deliver cargo, or that we use components that don’t have a lot of heritage and that have a lot of failures. Mission success is right below safety. When we decided who we were going to partner with, we essentially picked companies that had the experience, had the heritage, maybe worked with NASA before, components that had either flown or been fully qualified.

The biggest of our partners was Thales Alenia Space in Italy, who designed the Pressurized Cargo Module [PCM] for us. Thales Alenia Space has a lot of experience with NASA. They designed and built the MPLMs [Space Shuttle Multi-Purpose Logistics Modules], so they knew the NASA requirements, they knew what NASA was sensitive to. They had the heritage, so in designing the PCM they had all their design processes down from their previous contracts, their previous experience. So we felt that they could take that, apply it in a very low-risk way, and build us a piece of hardware that was very reliable and be built on a commercial price. And it came absolutely true. They’re a great partner, their hardware is outstanding, and they’re well ahead of their schedules.

We applied that philosophy other places. Our rendezvous sensors, we selected Jena[-Optronik GmbH, Germany] as a supplier for our first few missions so that we could get our baseline down. We picked the Star Tracker from SODERN in France. That was fully-qualified. The communications system we built on the first few vehicles is from Thales Alenia Space [España] in Spain.

The philosophy was get a design that was high reliability, with a lot of heritage, to keep the risk down. The batteries for instance—we were flying the cells from Japan, and they’re being assembled for us by a subsidiary of the Japanese company, GS Yuasa [Corporation], located in Atlanta [Georgia]. It’s an American company, it’s a small business, but it has that link to their parent company who also provided the cells. We do have small business requirements on the contract, but our approach first and foremost was get the systems in place that will be reliable and safe, and the small business aspect will take a back seat to that. But we do take it seriously.

Hackler: What type of evolution has the Cygnus vehicle seen from the time you signed the COTS agreement to the present? What sort of changes did you make as a result of negotiations and working with NASA?

DeMauro: There are a couple of phases to that, so I’ll hit each phase. I think the first phase of that is just the basic design approach. This was before my time on the program, but as it was originally conceived, there was a certain architecture that we were going to build. In fact, interestingly, the first incarnation of Cygnus was going to be an Unpressurized Cargo Module. That later was changed to a Pressurized Cargo Module.

From an architecture point of view, I think there was a certain approach taken, then as we went to NASA and said, “Here’s our architecture,”—and, more importantly, for the response to the safety community—they looked at it and said, “Not so sure that’s going to work.” I would say for the first 12 months of the program, there was a continual evolution of what that architecture was going to look like, that we thought would satisfy the technical requirements and would also satisfy the safety community.

It really was about nearly two years into the program, maybe a year and a half, where the architecture, the avionics, how we would use all of the components came together. I think that first phase was just learning what was important from a design point of view, and learning what was important from a safety point of view, and then coming up with an architecture that would satisfy all that. I think we came out at the end of the day with an architecture that would work. That’s from a hardware point of view.

The second phase of that was the development of the software, which is absolutely critical. That allows us to autonomously rendezvous with the Station, and has all the fault detection systems in place to keep it safe, that can just run the system. That took a long time to develop. I would say the software development was the hardest part of this job. Hardware development—you can arrange your resistors and capacitors in all sorts of ways and find a way to make it work, but the software makes all that talk and makes all that work together. That, not surprisingly, was the hardest aspect of the development. At this point, the software’s fully qualified, it’s fully tested, it’s on the vehicle, it’s ready to go. If I had to pick a source of pain in the development, it would be the software side.

Then I would look at the third phase of that. Now that we’ve got an architecture that can work, what do we want the Cygnus to look like in, say, the second half of this CRS program? Can we do things more efficiently? Can we make it more mass efficient to enable us to carry more cargo? We embarked on a development program on our own funding to create an enhanced Cygnus vehicle which was lighter, allowed us to carry more cargo, and was more tailored for the mission. What you realize when you get a couple of years into a program, and you’ve learned so much—Antares learned so much, Cygnus learned so much, NASA learned so much—you have a system that you look at and you say, “You know what? We did a good job. That system’s going to work. Now that we’ve learned all that stuff, if we had to do it over again, what would we do differently?”

We funded a program—with NASA fully involved because we wanted them to buy into the changes we were making—and we said, “We’re going to design the structure to be a little bit lighter. We’re going to put on lighter solar arrays. We’re going to integrate different rendezvous sensors and communications systems. All in the name of making us more mass-efficient, more cost-efficient, easier to assemble, so it’s more efficient from the production side.” That’s the third phase: I’ve got my design set, now I’m going to have it be more capable.

Hackler: You talked about Phase 1, putting together the architecture for the hardware and working with the safety community—which individuals and groups did you work with in the development of the vehicle?

DeMauro: Everything was worked with C3PO and the ISS Program Office as our primary interface, but for instance we had a lot of involvement with the RF group, Amin Rezapour and his team, working with our RF team to make sure our RF system was robust enough to fly the mission. We had the mechanical and structures people at NASA working with our mechanical and structures people on whether it was an issue we had to solve or a design issue. We had the avionics software and control teams working with us on the avionics development, what that was going to look like, but primarily on the software side. They had tremendous involvement on the software side.

What I would say is that we’re an experienced aerospace company and we’ve built a lot of spacecraft, and I think NASA recognized that. I think they trusted us, after getting to know us a little bit, that we know how to do this. We have the processes in place to do the right mechanical analyses; we have the processes in place to develop software, test software, configuration control, those types of things. They were very involved and we welcomed that involvement.

We believe in transparency. At the end of the day, it makes our job easier. When we had an issue with the seals for the cargo berthing module [Common Berthing Mechanism], the NASA mechanical engineering folks were very much involved to help us through that process. As we made changes to our software and went through our software qualification process, the software people at NASA were very involved in what does that qualification process look like. At the end of the day they said, “Look, it’s your process to qualify your software and we’re comfortable with it. When you say it’s qualified, it’s qualified.”

To get to that point, we worked to make sure they were comfortable. I say “convince,” not that we had to do much convincing, but that they got comfortable with it. I would say on the safety community side, a lot of involvement by Nathan [J. Vassberg], the Chair of the Safety Review Panel [SRP], and [J.] Mark Childress, great involvement in what does the architecture look like. As you undoubtedly find along the way, little nuances of your design that maybe you didn’t plan for, “How is that going to impact the operation of the vehicle, how’s it going to impact safety?”

We found, and our approach was, that we’re going to be very open and we’re going to be very transparent with the SRP. We want them to know about our anomalies. We just don’t think surprises are a good thing. On a monthly basis we would get together with the SRP and lay out issues we’ve had, whether or not we had resolved them, and then when we came up with a resolution, present the resolution. Let them ask whatever question, so that at the end of the day, when the hardware’s built and it’s fully tested, we can stand up and say, “We’re confident that it meets the requirements, it’s going to work,” and they’re just as confident.

Does that answer your question?

Hackler: Yes, very well, thank you. Cygnus is designed for both unpressurized and pressurized cargo, and Orbital elected not to pursue [COTS] Capability C, the downmass capability. Can you talk about the reasons for those design decisions?

DeMauro: When we originally received the Space Act Agreement, we were going to do a demonstration with our Service Module and an Unpressurized Cargo Module. We started down the path of actually designing that Unpressurized Cargo Module. Then, when we got the CRS contract, the eight missions in that contract only called for pressurized cargo. So we changed course at that point and said, “It doesn’t make sense to do a demo [demonstration] of unpressurized if we’re going to fly pressurized eight times.”

We decided, on our own investment, but with concurrence from NASA, that we were going to change our demonstration mission to have a Pressurized Cargo Module. If NASA does decide at some point they want the unpressurized capability, we can do that. We would have to finish that Unpressurized Cargo Module design, but we can go ahead and do that and then offer that capability.

As far as the return cargo, we decided along the way that given what NASA was looking for in terms of upmass, we were going to tailor the system to be specific for upmass. To have a return cargo capability, it takes mass to do that, so it would essentially take away from our ability to fly as much cargo up to the Station. We decided that rather than invest in that capability, that at least for this first CRS contract, it wouldn’t be used. We decided that was not going to be in the design space. We were going to focus on upmass, maximizing that capability, and then disposal mass. That’s how we came about those decisions.

Hackler: My last question about the Cygnus vehicle itself—more curiosity than anything else—where did the name came from? Was there a particular inspiration for that choice? For Antares as well, if you happen to know.

DeMauro: I think Cygnus came from Dave [David W.] Thompson. I think it had to do with the swan [from Greek mythology], and flying to the Station. I think that was the origin of that. Antares, I honestly am not sure. I’ll have to ask the Antares guys. Originally our Antares was Taurus II, and then as the development was completed and we approached really putting together our first vehicle the decision was, “No, it needs its own name.” But I’m not sure what the origin of that is.

Hackler: Thank you. Just an interesting tidbit I was curious about. Rebecca, did you have any questions you wanted to follow up on?

Wright: Although it wasn’t required, you did have a payload in the [Antares] demo launch, with the Cygnus mass simulator. Talk to us about you decided to do that.

DeMauro: I think you probably know that the test flight was added to the Space Act [Agreement] as part of the risk augmentation funding that NASA gave us, [in fiscal year 2011] and SpaceX [Space Exploration Technologies Corp.] as well. Aside from the obvious benefit of reducing the risk of that rocket and reducing the risk for the following missions, we said, “Well if we’re going to fly a rocket, let’s fly something on it that has some technical significance.”

Working with the Antares folks and the NASA folks, the first idea was we want to fly something with the mass properties that a loaded standard Cygnus would have. We embarked on a plan to design something that had the volume of a Cygnus, had the mass of a Cygnus, had the center of gravity and such of a Cygnus, so that Antares would feel like it’s lifting a Cygnus and have to respond accordingly. Then we said, “If we’re going to do that, since it’s the first-time ever flight of a vehicle, let’s validate the loads that it’s going to put on our spacecraft and instrument it,” so we can measure the vibration loads on lift-off and ascent, we can measure the acoustic loads, which is a big part of the loads, but also, when the fairing separates, measure the thermal loads on the front end of the vehicle.

There was some concern about how high those levels were. We designed to relatively high levels to be conservative, but we weren’t sure. The idea came that says, “We’ll instrument it with microphones, accelerometers, and temperature sensors, and we’ll get that data.” Then we had a mini little program and we embarked on that, we came up with a design for that. The idea was if we’re flying something to orbit, there’s got to be somebody out there that might want to fly these small nanosats [satellites], PicoSats and CubeSats.

We worked with a couple of customers who contracted for the services, and we ended up flying four of these nanosats. There was some integration effort with NASA because it was a NASA mission, but NASA essentially said, “It sounds good to us.” We had the [NASA] Ames [Research Center, Moffett Field, California] payload on there, the PhoneSats, and then we had another one. It was an opportunity to offer this capability, and it just worked so well.

To see those things deploy out, and they were taking some pictures—if you go to phonesat.org—they were named Alexander, Graham, and Bell, and they published on their website a picture taken by the CubeSat of Earth, and it was fantastic.

Hackler: That’s pretty cool.

DeMauro: The simulator really had a lot of technical basis on what we wanted to get out of it. The CubeSats were just an opportunity that we could offer, and it really all worked out.

Wright: It sounds that, from talking to the rest of your team, there were a lot of thought processes—here was the basic requirement, but Orbital wanted to put in some extra pieces along the way so that you could, as you just mentioned, test the levels. Was that part of your overall plan, to learn as much as you could on this first flight?

DeMauro: Exactly. We took it seriously in terms of risk reduction. Other companies have done test flights and we hadn’t had one planned. We thought, “If we’re going to reduce risk, why not reduce risk not only on the launch vehicle side, but on the spacecraft side?” If we could measure the vibration input, let’s say, to the base of the spacecraft, and for whatever reason we find out that it’s much higher than we designed for, we’d know before we ever launched that we had a problem. Of course it didn’t turn out that way, thankfully.

Or if the acoustic environment was much higher than we had planned, what kind of problems would that cause? We hoped, and it did confirm that the levels to which we designed the spacecraft were correct. We all came out with a confident answer, but we wanted to cover ourselves. If the answer was not good, we knew that ahead of time.

When we worked with NASA on the risk augmentation funding, they came and said, “We didn’t know at the time, but we have some money,” probably ranges from here to here, “What would you do with that?” Of course, the test flight was the first thing that came to our mind. We said, “With a little bit more and with some of our own investment, let’s do this mass simulator, let’s instrument it.” Everyone bought in right away. Everyone realized that it was a good idea.

Wright: Did you believe the augmentation was a vital piece of making this a more total success?

DeMauro: I think so, yes. I think so. That was another process, working closely with C3PO and Bruce [A.] Manners and Alan [J.] Lindenmoyer and Kevin [M.] Meehan, and defining how that money would be used. Essentially, what the best bang for the buck would be. Again, test flight was first and foremost on everyone’s mind, but then the other things we did with that money, like the simulator, like additional GSE [ground support equipment] to enhance our ground testing—everything that was done, in my opinion, every penny of that risk augmentation funding, with some additional input from us, all went towards what it was meant for, reducing the risk to the program. It was all well-spent, I think.

Hackler: Tell us about your experience on April 21st [2013], the experience of when you finally got that successful, flawless [Antares] test flight.

DeMauro: We waited for quite some time for this, and obviously, like I said before, no corners were going to get cut so it was going to happen when it was ready to happen. We had the first attempt that previous week, and it didn’t go off. We had that lanyard issue, and then we had the weather issue later that week, and it was going to go off on Saturday, and then it didn’t. Sunday, I drove back down to Wallops [Flight Facility, Virginia, Mid-Atlantic Regional Spaceport], so I’m in the control center and in my chair next to Alan and Bruce.

I don’t recall ever being as nervous as I was—not because I didn’t think it would work, just because all of us knew how important it was. We’re getting close and everything’s going so smoothly, and then you hit the time of liftoff and those engines ignite. For me, given the issues we had had with the one engine that failed during the test, I couldn’t wait to hear the call that we had throttle down to 100 percent. It was just going so smoothly. I can even chronicle in my own head, getting more and more comfortable. And it’s not that long a period of time.

Then the engines throttled down and the engine cut off. In the first stage the engines had worked, and of course there are a lot of pieces to go, but you just felt like we could be on a good track here. Then the second stage ignited. We had the fairing separation, which of course is a big deal for us. As each phase would go, the clapping in the room would get louder and louder. I think when the fairing separated it was the loudest clap, and then Mike [Michael] Dorsch, the chief engineer who was calling the events, said, “Antares is now in orbit.”

Of course I couldn’t wait for my little simulator to get released and see what was going to happen there. The CubeSats went out, and then when the simulator released, we didn’t see that on the video. We had lost the connections, which we knew we would. We didn’t get real-time video for that. But when we heard the payload separate, we knew the mission was successful. It was just elation. I mean, you have people in that room of various ages, all feeling like little kids again, feeling completely renewed.

I tell people who don’t work in this business, “This business is not for the faint of heart. This is a hard business and if you don’t like stress, if you don’t like challenges, it’s not the place to be.” I happen to love it. I can’t imagine doing anything else. In this business—and the people you talked to earlier, the Antares people—we all have the same mentality. So you’re surrounded by those types of people, whether they’re NASA people or Orbital people or SpaceX people. It doesn’t matter, you do this because you love it.

When that was done, I think there was just stunned elation. Not that we didn’t think it would happen, but they did it—and the look on the Antares people’s faces, just phenomenal. Just phenomenal. You knew at the time, this amazingly major milestone is successful. Of course we had to wait for the post-test report, but the fact that we achieved orbit, everything looked good, was tremendous. And you knew, “Next up is my spacecraft.” Now it’s going to be our turn, and we just can’t wait. It was a great day.

One thing I’ll add is that we’ve had such a collaborative effort with NASA on this that they weren’t just a customer, they were part of the celebration and part of the success. I think that’s important.

Hackler: We know you’ve got the final demonstration coming up at the end of August, maybe September, so we’ll look forward to seeing that.

DeMauro: Yes, that’s going to be exciting. We’ve got the Cygnus down at the launch site, fully fueled and ready to go.

Hackler: What’s next for the vehicles after the successful COTS demonstration and CRS? Do you have any other plans for them? Other markets, other customers—how you want to develop them for the future?

DeMauro: I think there’s a couple of different aspects there. One is what do we want Cygnus to look like for the follow-on mission? Do we want to make changes, if any? Are there capabilities we want to add to the system that make it more attractive to NASA? I think that’s one part of it, and we’re certainly looking at that, and also working closely with the ISS Program Office to understand, “What are you looking for? We built this system, it does these things. What would you like to see in the next phase, and what would it take to get there?”

As far as other markets, we think Cygnus, once it flies it will be a really attractive platform. It’s extremely reliable, obviously very maneuverable by its very nature, so we think there are things we can offer both to other areas within NASA, and also other customers, either commercial or not. Go out there and say, “This is what it’s capable of. Is there anything else you’d like it to be capable of?” It’s a very flexible architecture so we think we can make it do a lot of different things. We think the interest will be out there. We’re already getting interest on it, but I think once it flies that will hopefully open the floodgates of the interest.

Hackler: Before we close today’s session, are there any last thoughts you’d like to share with us about your experience on the COTS and CRS programs?

DeMauro: Yes. I think personally—I mentioned before, this is a labor of love. For me it’s about the team and it’s about how hard people work to achieve something. What I said about the Antares folks with the test flight, you just can’t help but feel so good for how hard they’ve worked to get there. On the Cygnus side, I’m so looking forward to those pictures when we’re rendezvousing with the Station. It’ll be tense and there’ll be a lot of nerves, but we’ll eventually get there and they’ll grapple us. I’m looking forward to being able to look around the room, to the mission ops [operations] team and all the engineers, and watch them celebrate that this all worked.

I do think it’s been a collaboration, and it’s been really tremendous for me to be a part of this. Again, I came from the commercial world. These are very important communication spacecraft for all sorts of purposes, but this program has a different sense to it obviously. We’re not just delivering DirecTV [satellite television]. You’re delivering supplies to people who are risking their lives to be up in space.

When I do my all-hands meeting—which I have one tomorrow for my team—I always start off with a picture of the current crew that’s on the Station to remind people, “These are the real customers.” It’s not the ISS Program Office and it’s not C3PO, it’s really the crew that are on the Station. We’ll be delivering whatever they need, so our system has to work. I think it’s amazing how hard people are working to make it work, and that’s really where the joy in this will come. Hopefully soon.

Wright: I do want to ask one more—you talked about this is the largest development project that Orbital’s taken of this kind. It has a customer right now, but there’s no guarantee on the other end of this. Can you share with us why Orbital felt this was important to invest their own money in, and move into a different kind of partnership? Everything was so different, so new—the same, but not really. They took a big risk, so why do you feel that they decided that this is what the plan should be?

DeMauro: I think there are a couple of parts here. If you look at this, there are three major developments. You have a launch pad, a launch vehicle, and a spacecraft. I think there is expectation that the Antares launch vehicle will become a very popular medium-class launch vehicle for the space industry. Right now its main focus is cargo to the Space Station, and that’s currently its only customer, but I think once we actually fly a couple of more times there’ll be a lot of interest in it. That’s certainly a business decision that the company made, to invest in a new rocket with a new launch pad. That will pay dividends in the future, not only in cargo delivery, but other satellite delivery.

On the spacecraft side, our contract is delivering cargo through the 2016 timeframe, but we’ve got a Space Station that’s at least good through 2020 if not beyond. We believe that the Cygnus spacecraft, in its current form and then maybe in some evolved form, will be among the vehicles of choice to bring cargo to the Station for the long term. We think that investment is going to pay off. Once we’re flying and once we show our production capability—which we’re already demonstrating. We’ve got multiple vehicles already done, just waiting for launches. We’ve got others in the pipeline, finishing their integration.

Once we start flying and we show the frequency and the reliability with which we can fly, we think NASA will say, “This company is the company we’re going to stick with to keep going.” Maybe that’s a little editorializing, but it’s what I really believe. I think in a lot of ways it just makes commercial sense that NASA’s going to say, “They’ve done nine missions, they can build vehicles as fast as we want them, if not faster. Antares is reliable, why am I going to start new with somebody else?”

I think that’s part of the reason we did the investment. I think the other part is that there are technologies we’ve developed—with Cygnus we have new avionics, we have new computing technologies, we have new software, and our autonomous rendezvous capability might be able to be used elsewhere. Again, whether it’s with NASA in some exploration mission, or by some other customer, there’ll be dividends and it’ll pay off in the end.

Wright: So you think COTS was a good idea?

DeMauro: I think COTS was a good idea. I think it’s a good idea for both NASA and Orbital.

Hackler: Thank you. We’ll certainly be watching and wishing you the best of luck.

DeMauro: Thank you, I appreciate it.

[End of Interview]

Return to JSC Oral History Website