| BlueSky Business Aviation News | |||||||||||||||||||||||||||||||||||||||||||
| . | |||||||||||||||||||||||||||||||||||||||||||
The last time I saw this sort of potential to revitalize civilian space flight was back in the 1990s. Remember Teledesic? That was Bill Gates' visionary plan to put over 800 satellites into low earth orbit, providing total global coverage for broadband services. Imagine! There would be no place on earth that you couldn't have net access. For some, this is a horror story come true - geeks watching YouTube clips in the Amazonian jungle; for others, a miracle where natives of the Amazon gain access to the world through the net (thereby destroying their traditional culture - back to the nightmare; which is going to happen anyway, but with net access, they get to choose how - back to the miracle).
Nothing impressive until Rutan Since the failure of Teledesic, there really hasn't been anything impressive until Rutan's collaboration with Paul Allen to create SpaceShipOne. Sure, Boeing did Sea Launch, but really, it was a bunch of defense contractors doing what they do best. Seriously. Registering their launch ships in Liberia? Come on. Clearly, not on-board with what I'll call the democratization of space. A failure of Teledesic The failure of Teledesic, well, one of the big failures, and the failure of Sea Launch is that neither did much to reduce the systemic cost of putting a pound of stuff into orbit. And really, Teledesic's almost-deal with the Russians to use their ICBM motors as launchers made a great deal more sense than Sea Launch, financially speaking. That said, both were and are chock full of one-time-use hardware. This is not the way forward.
Cost structure Looking at an overview of the costs of civilian spaceships, we get pretty much the same categories we use for aircraft. In cash direct operating costs (cash DOC), we have fuel, crew, and maintenance as the big swingers, plus landing fees, navigation charges, and ground handling. Stepping back a notch, in total direct operating costs (total DOC, or just DOC), we add cost of ownership - depreciation, interest, and insurance.
Cash DOC: Crew Cost of the crew is going to be in line with current pay scales and we aren't likely to have a crew of fewer than two for certified commercial operation. Initially, because of the size of the spacecraft and the implied performance margins, we might get away with one pilot. However, as the technology improves, spacecraft grow larger, and performance margins increase—all quite safe bets—then we will see the regulatory mandate for redundant crew, i.e., for a two-pilot crew. Seriously, we have had at least one pilot incapacitated with a heart attack on approach (South African Airways Flight 406, 1967). It did not end well. Virgin Galactic is going with a two-person crew in SpaceShipTwo; good call. DOC: Cost of ownership The cost of ownership is going to change radically over time (almost certainly going up), but it will do so along with greater capability, improved margins, and higher reliability. We can expect that because it is exactly what the market is going to demand. It is what the market has always demanded. I don't know which company will build the next operational civilian spaceship--there were half a dozen or so last I checked who were still in the running for #2--but Rutan's Spaceship Factory has a huge first-mover advantage at this point.
The reason I think the data standards for maintenance should get attention now is because I would like to avoid the QWERTY syndrome, where we somehow end up with an accidental standard. In my opinion, we as an industry would be well served going forward by thinking through the obvious stuff now, and implementing a standards board to handle the non-obvious stuff that happens later. The IT folks have a number of standards boards that do exactly that in their industry. Surely we in aviation are at least as thoughtful and forward thinking as those in the computer industry. MRO software Let us look at some history. The airlines have custom software designed up from scratch to handle their maintenance needs, and have since the age of mainframes (roughly parallel with the introduction of jet-powered commercial aircraft). Judging by the prices they charge for the use of that software, they are quite proud of it. There are a number of big software houses, including Oracle and SAP, if memory serves, who have ventured into the MRO IT space. Michael Denis of Aviation Wikinomics is the real expert on all that software. What is an MRO? MRO, by the way, means Maintenance, Repair, and Overhaul. In industry jargon, an MRO is a third-party maintenance provider like a garage for car repair (the other two parties being the manufacturer and the operator). They can be small shops or divisions of huge multinational corporations; some are spin-offs from airlines, others were built from the ground up to do nothing but maintenance. I feel pretty sure we will eventually have a thriving MRO sector on the spaceship side of the industry. What I want to avoid is duplicating dumb stuff that costs time and money. As sure as the sun will rise tomorrow morning, someone is going to try to port over an airline maintenance tracking program and use it to track spaceship maintenance. It may even work for a time. However, the current generation of maintenance software isn't all that. The new stuff just coming into the marketplace is, by all accounts, much better, though insanely expensive. But it still isn't designed for spacecraft. Different how? At this point, no one that I know is even looking into the differences, and there are some pretty major differences. For example, we don't worry too much about the effects of cosmic radiation on aircraft components, nor do we replace components for excessive exposure to radiation, which can be quite serious once we get out of the atmosphere. Nor do we worry about prepping something for operation in a vacuum (normal lubrication process for aircraft will not work). If we share components with aircraft (think avionics and actuators), we need to know if that component will be adversely affected by either radiation or vacuum or both. And when we have an MRO in orbit, we will want to know if the component was replaced or the repair was completed in the atmosphere or in a vacuum. This is just the low-hanging fruit; I'm certain that there are many, many other issues of which I am utterly ignorant. The impact of PLM Part Lifecycle Management, or PLM, is a major engineering innovation. We can now create a data structure that follows a particular part from cradle to grave (or cradle to cradle, if you read William McDonough as you should). There ought to be a data standard for cradle-to-cradle part history. I don't know what that structure should look like—this isn't my field—but there are people who do. Beating my usual dead horse like a drum, if we had an industry think tank, those people could sort it out and maintain that structure over time, saving everyone a great deal of time, effort, and money. This is the tip of an iceberg of information that will continue to reveal itself over time. We should plan for it. We used to be good at that sort of thing. I think we can be good again. Commander Bud Slabbaert is hosting a session on think tanks in the upcoming BA Meetup. I think this sort of thing should be in the discussion mix. Open software Creating published data standards will allow us to have open-source, open-architecture software. I know. Quelle horreur. Still, you are reading these words courtesy of free, highly reliable, open-source software like Linux, Apache, Mozilla, and Open Office (which is what I use). No one is required to use open-source software, of course. There is nothing stopping us from asking Microsoft to create the ultimate MRO software for our company. Send me an email and let me know how it turned out. How it impacts the actual maintenance There are software packages out there currently that track who is doing what job (and their relevant certifications), using what tool, noting the tool's most recent calibration (if it is out of calibration, the tool room can't issue it), and who signed it off as complete. This provides enormous value in preventing mistakes and providing traceability of maintenance actions. There is no reason in the world why we can't have systems at least this comprehensive for spaceship maintenance. Nor is there any reason the entire system has to purchased at one time. Modular software Modularity, I believe, is the key to making software capital expenditures reasonable. Buy only what you need. Predefined data structures mean we will be able to add on other modules later with no loss in functionality, and for minimal cost. For our purposes, there is no downside to modular design using standard data structures. Tracking maintenance Every aircraft has scheduled and unscheduled maintenance. Tracking the scheduled stuff is very important, and there are companies out there who already do that sort of thing. It's a huge job, no mistake, and a decent data standard might make their job a bit easier, though it's a bit late in the game for aircraft. Still, aircraft aren't going away, and the sooner the proper data standards are implemented, the sooner we can all take advantage and reduce our costs. Spacecraft, too, will have scheduled and unscheduled maintenance. It's the nature of the beast. Tracking their scheduled maintenance is just as critical as for aircraft, and just as big a job. It is NOT too late to get the data standards in place for them. I think now is a great time, actually. Maintenance is key to a successful spacecraft It may sound odd, but all the performance in the world won't make a spacecraft great if it is unreliable, or too expensive to maintain for what it provides. Notice there is no line forming at the door to operate the US Space Shuttle now that NASA is getting rid of it. So, while great performance is very important, there are other essential elements, including affordability, obtainability, operability, and maintainability. I believe, based on past experience, that Burt Rutan understands these issues. I hope the other manufacturers that follow in his footsteps do, too. Terry Drinkard is currently consulting on an aviation start-up. His interests and desire are being involved in cool developments around airplanes and in the aviation industry. Usually working as a contract heavy structures engineer, he has held positions with Boeing and Gulfstream Aerospace and has years of experience in the MRO world. Terry’s areas of specialty are aircraft design, development, manufacturing, maintenance, and modification; lean manufacturing; Six-sigma; worker-directed teams; project management; organization development and start-ups. Terry welcomes your comments, questions or feedback. You may contact him via terry.drinkard@blueskynews.aero Other recent articles by Terry Drinkard:
|
|||||||||||||||||||||||||||||||||||||||||||
