NASASpaceFlight.com Forum
SLS / Orion / Beyond-LEO HSF - Constellation => Heavy Lift Launch Vehicle (HLV/SLS) => Topic started by: Bernie Roehl on 01/26/2010 10:44 pm
-
I've been reading a bit about the AIO-50 project to rebuild the Gemini spacecraft from the original blueprints, using updated materials and avionics.
That leads me to wonder what's actually involved in a project like that. How much of the construction detail is included in the plans, and how much was in the heads of the engineers and technicians who actually built it? Is such a project even possible?
-
I've been reading a bit about the AIO-50 project to rebuild the Gemini spacecraft from the original blueprints, using updated materials and avionics.
That leads me to wonder what's actually involved in a project like that. How much of the construction detail is included in the plans, and how much was in the heads of the engineers and technicians who actually built it? Is such a project even possible?
It depends. There are two things to consider here.
First, how much information is in the drawings and documentation. That depends on the culture of the company did them and the regulations in place at the time. Ideally, you would think that the drawings are maintained and completed as design changes are made, but in reality, that can be hit and miss and can depend alot on wether or not the person who pays the bills wants to do it. Also, the drawings may be lost to time after the project was completed. I don't know about Gemini, but I have heard stories about boxes of the drawings of the LM being thrown out to make space. Durring the Columbia accident investigation, the board was very disapointed that they were not able to get ahold of design drawings because no one knew where they were stored.
Second, what exactly do they mean by "using updated materials and avionics"? Even if they have all of the original documentation, if they are making changes that would affect material strengths, CG or manufacturing methods, they will have to do a complete reanalysis at the very least and probably have to create all new production drawings.
-
BTW, if you wanted to reuse a capsule after a water landing, and that'd be your primary mode of recovery, it'd make sense to make it with alloys that simply don't corrode on contact with seawater.
-
First, how much information is in the drawings and documentation. That depends on the culture of the company did them and the regulations in place at the time.
That's surprising... I would have thought the companies would be required to maintain those sorts of things.
Also, the drawings may be lost to time after the project was completed. I don't know about Gemini, but I have heard stories about boxes of the drawings of the LM being thrown out to make space.
I imagine maintaining all the data is a lot easier to do these days, since everything is digital.
That's a shame about the LM drawings being lost. It occurs to me that a (relatively) inexpensive lunar lander could be built based on that design, and the total mass would be a lot less than Altair would have been.
Second, what exactly do they mean by "using updated materials and avionics"? Even if they have all of the original documentation, if they are making changes that would affect material strengths, CG or manufacturing methods, they will have to do a complete reanalysis at the very least and probably have to create all new production drawings.
I'm not a mechanical engineer, but I was assuming they'd have to create new production drawings based on the old ones in any case, and that a certain amount of analysis would have to be done since it wouldn't be a 100% perfect copy. I certainly can't imagine them rebuilding 1960's discrete circuits, so the avionics would certainly be different (and therefore the flight control software as well).
-
BTW, if you wanted to reuse a capsule after a water landing, and that'd be your primary mode of recovery, it'd make sense to make it with alloys that simply don't corrode on contact with seawater.
I'm not sure how LiAl reacts with saltwater, but if you had to use a metal that will not corrode (or be less corroded), then it will undoubtably be heavier.
-
I did work as a mechanical engineer for years. I worked on a lot of projects that were "just updates" of existing ones and they always ended up being redesigned from scratch. I wouldn't be surprised that in the end the only thing this project will have in common with the gemini capsule will be its general size and shape.
-
BTW, if you wanted to reuse a capsule after a water landing, and that'd be your primary mode of recovery, it'd make sense to make it with alloys that simply don't corrode on contact with seawater.
I'm not sure how LiAl reacts with saltwater, but if you had to use a metal that will not corrode (or be less corroded), then it will undoubtably be heavier.
No doubt this is quite likely and should be involved in any trade study.
HOWEVER, quick googling points in the opposite direction. I uncovered a patent that uses LiAl alloy particles to actually inhibit corrosion:
http://www.patentstorm.us/patents/6069197/description.html
-
First, how much information is in the drawings and documentation. That depends on the culture of the company did them and the regulations in place at the time.
That's surprising... I would have thought the companies would be required to maintain those sorts of things.
Only for a limited number of years. Once the project librarian/registrar is fired to save money the unread paperwork soon disappears.
Also, the drawings may be lost to time after the project was completed. I don't know about Gemini, but I have heard stories about boxes of the drawings of the LM being thrown out to make space.
I imagine maintaining all the data is a lot easier to do these days, since everything is digital.
{snip}
Things are much easier these days, computers come with delete keys.
Depending on the media used computer files have to be copied to a new disk or magnetic tape every few months. Many organisations only keep back up copies for 6 months.
-
Depending on the media used computer files have to be copied to a new disk or magnetic tape every few months.
Magnetic tape? I would have thought they'd back everything up on DVDs these days.
A related question... who "owns" the designs for a spacecraft like Gemini? Or for that matter, Orion?
I would have thought that since the development was paid for by tax dollars, everything would belong to the US government. Could they not "open source" all the design and manufacturing information if they chose to, and make it available to the public? That would at least ensure its long-term survival.
-
Depending on the media used computer files have to be copied to a new disk or magnetic tape every few months.
Magnetic tape? I would have thought they'd back everything up on DVDs these days.
A related question... who "owns" the designs for a spacecraft like Gemini? Or for that matter, Orion?
I would have thought that since the development was paid for by tax dollars, everything would belong to the US government. Could they not "open source" all the design and manufacturing information if they chose to, and make it available to the public? That would at least ensure its long-term survival.
And if they are open, makes me wonder about other bits. I'd love to see the plans for the S-IC sometime, for example.
-
Could they not "open source" all the design and manufacturing information if they chose to, and make it available to the public? That would at least ensure its long-term survival.
There are company specific processes that are involved that may be hard to duplicate or find.
-
Could they not "open source" all the design and manufacturing information if they chose to, and make it available to the public? That would at least ensure its long-term survival.
There are company specific processes that are involved that may be hard to duplicate or find.
Not fully relevent. While it would prevent duplication of the design, the knowledge would not be lost.
Example, I have a full design for the old Atari Jaguar console, including the custom chips. It was developed with an internal Atari design tool, long lost to history. However, even with the original design being useless for directly manufacturing without this tool (and who'd want to build a Jaguar anyways?) the design can be studied for future work, to learn what worked, and did not work.
-
Not fully relevent. While it would prevent duplication of the design, the knowledge would not be lost.
Not so, it is very relevant. "Processes" are more than design tools. They include things like bonding surface prep, tube bending, etc
-
FYI: the project can b found at:
http://www.aio50.org/UAHproject.php
From the link student are exploring the feasibility of the Rogallo wing for land landings and are currently building a 1/3 size model to test handling characteristics of the wing. If these tests are promising they will go forwards with a full size model but there does not appear to be an plans to have it actually launched into space.
-
FYI: the project can b found at:
http://www.aio50.org/UAHproject.php
[...]
there does not appear to be an plans to have it actually launched into space.
That's what I got from reading it too, but the site also says they're planning to launch the Gemini-IR into orbit on a Falcon 9 on Feb 20, 2012 (just over two years from now).
Are they just blowing smoke, or is it credible that they will be able to pull this off?
-
As has been said, it is impossible that every single mechanical or electronic component from Gemini is avialable today. It is extremely unlikely that _any_ component from 1963 is avilable today. That said, the cost to reproduce a Gemini would be then be significantly higher than the original (even allowing for inflation) because testing & validation regimes are significantly more stringent today than they were in 1963-64 when the Gemini was developed. I'd bet none of the mechanical drawings are available, so every part would have to be designed from scratch. Add to that the need to convert old materials & processes to new ones plus the unbelievably complex & costly need to design the avionics and then test them and you have a recipe for a very costly system. I would bet that it wouldn't cost a whole lot less than Orion, when all was said and done. Most of the cost of something like a Gemini or Orion is in the development of the design, and is pretty much unrelated to the size of the spacecraft involved. The costs are much more related to the functionality of such a capsule as opposed to the basic size or mass.
All that aside, though, I'd love to see full scale deployment testing done on a Gemini/Rogallo wing recovery system. The concept holds some promise for the less costly land landing and reuse of capsule type spacecraft. I've always thought it could provide lifting body capabilities in a capsule shaped re-entry body. Of course, the Rogallos are pretty intolerant of deployment failures...
Paul
-
As has been said, it is impossible that every single mechanical or electronic component from Gemini is avialable today. It is extremely unlikely that _any_ component from 1963 is avilable today. That said, the cost to reproduce a Gemini would be then be significantly higher than the original (even allowing for inflation) because testing & validation regimes are significantly more stringent today than they were in 1963-64 when the Gemini was developed. I'd bet none of the mechanical drawings are available, so every part would have to be designed from scratch. Add to that the need to convert old materials & processes to new ones plus the unbelievably complex & costly need to design the avionics and then test them and you have a recipe for a very costly system. I would bet that it wouldn't cost a whole lot less than Orion, when all was said and done. Most of the cost of something like a Gemini or Orion is in the development of the design, and is pretty much unrelated to the size of the spacecraft involved. The costs are much more related to the functionality of such a capsule as opposed to the basic size or mass.
All that aside, though, I'd love to see full scale deployment testing done on a Gemini/Rogallo wing recovery system. The concept holds some promise for the less costly land landing and reuse of capsule type spacecraft. I've always thought it could provide lifting body capabilities in a capsule shaped re-entry body. Of course, the Rogallos are pretty intolerant of deployment failures...
Paul
Testing and validation expense is almost free using the unlimited "free energy" of grads and undergrads. They won't put men in it, but they could still fly and test it.
I still don't understand how we can say that it's ridiculously expensive to test and validate something today versus 50 years ago, but almost in the same breath say that test-flights are completely unnecessary with modern techniques. What? It sounds to me like if you were doing something like this (which doesn't have a customer in mind, just needs to provide motivating and interesting and marketable experience for students), you could quite easily avoid paralysis by analysis and, after being careful to catch the big mistakes, just fly the thing and see if you've done a good enough job. If it fails, it'd be a very good chance to teach the students how to do an accident investigation and see what you did wrong.
Something is seriously wrong if testing/validation is so much more expensive today than forty or fifty years ago. I don't know how to fix it, but it still seems like a problem to me.
-
As I understood it, the AIO50 version would differentiate from the historical Gemini most noticably in the adaptor module.
There are some items, like the Guidance Computer which should be pretty well understood and are in fact already emulated (I know emulators are slower typically than the descrete components they replace, but in this case that's hard to imagine).
Materials wise, not so certain why AIO50 would be in a rish to change too much to the hardware's composition. True it can't be rebuilt entirely the same way, or from the same components, but due to the reason for the program, and the fact that they are on a shoestring budget, it would seem best to stick as close to the original as possible.
As for rogallos: I hope they avoid it. Rogallo's have been superceded. If they somehow got in a luff with one, that would be horrible.
-
That leads me to wonder what's actually involved in a project like that. How much of the construction detail is included in the plans, and how much was in the heads of the engineers and technicians who actually built it? Is such a project even possible?
Pretty impressive. They've paid for a launch from Space-X and have a launch date (Feb 20,2012). http://www.aio50.org/index.php
It looks like they're going to drop test a 1/3 scale model and make several other "in atmosphere" tests at Redstone Aresenal before moving onto full scale development.
Also of note on the page, is a mention of converting "NASA blueprints" to CAD. So evidently, some significant documentation remains.
http://www.aio50.org/UAHproject.php
It sounds like an exciting, serious project.
-
Testing and validation expense is almost free using the unlimited "free energy" of grads and undergrads. They won't put men in it, but they could still fly and test it.
I still don't understand how we can say that it's ridiculously expensive to test and validate something today versus 50 years ago, but almost in the same breath say that test-flights are completely unnecessary with modern techniques. What? It sounds to me like if you were doing something like this (which doesn't have a customer in mind, just needs to provide motivating and interesting and marketable experience for students), you could quite easily avoid paralysis by analysis and, after being careful to catch the big mistakes, just fly the thing and see if you've done a good enough job. If it fails, it'd be a very good chance to teach the students how to do an accident investigation and see what you did wrong.
Something is seriously wrong if testing/validation is so much more expensive today than forty or fifty years ago. I don't know how to fix it, but it still seems like a problem to me.
OK, let’s get things straightened out here… :)
My comments were based on posters about a “project to rebuild the Gemini spacecraft from the original blueprints, using updated materials and avionics”. My interpretation was that this would be flown and my comments are only relating to men flying to space in the resulting vehicle. Once I found out that no-one was going to space in it, all my comments became moot.
If it’s a university program, nothing _has_ to be tested, no specs _have_ to be met and no rigour _has_ to be achieved. It’s whatever you need to do to educate the students (which is, BTW a very good idea).
If we get to the meat of your comments, though, i.e. “how we can say that it's ridiculously expensive to test and validate something today versus 50 years ago”, I can tell you that, in fact, it is much more expensive to test today than “yesterday”. This is because a) we can and do test much more thoroughly than before, earlier tests simply are not considered adequate today because we look for more information now than then, and b) individual test costs are significantly higher than they were that long ago, even allowing for inflation due to increased data returns and increased analysis time of the increased data.
As to the concept of “testing/validation is so much more expensive today than forty or fifty years ago” being wrong, I don’t think so. Certainly we are more risk adverse now and testing is all about reducing risk. But we also know significantly more about how to optimise designs to specific environments and, once you get to the pointed end of an optimised design, you really have to test it a lot and from a lot of different angles to ensure that you can handle all the environments you are designing for and that you haven’t exceeded the requirements of those environments, because that tends to mean that you could have optimised more. In the “old days” we couldn’t design right to the “bleeding edge” of the capabilities of our materials & processes so there were higher margins on things which also meant that you could get away with less testing and still meet acceptable risk levels. Today we can design right up to the edge of failure, our margins are paper thin and we need to be absolutely sure that it never fails. Therefore we test an awful lot.
Paul
-
I understand how much more advanced our analysis tools are nowadays. Do we NEED paper thin margins, near zero possibility of failure on the first try, while operating right on the edge of failure? Of course, we don't need to do that. There are materials nowadays that are better than before--
not worlds better, but enough to keep the same margins and lower the weight a few percent.
Can't we just operate with larger margins? I know that even the best models are not perfect (and require validation, anyways), and that there's no way to guarantee actual operational success probabilities other than testing the system as a whole in an operational configuration, fixing any issues as they pop up. So, you can buy back some or all of the reliability through operational testing. I think it's still good to test each subsystem beforehand, but extensive computer analysis can eat your lunch.
And another thing: why is avionics so expensive? We can be using all-optical avionics (for data buses) with dual or triple redundancy using many parts that are practically off-the-shelf such that the data bus cables have maybe 10% (or less) of the weight of older cables while being impervious to electromagnetic interference (thus saving much lengthy analysis right there). And we should be reusing avionics software using a refined, modular approach that can decrease errors and costs simultaneously. Even open-source it (maybe only among those with security clearance), if you can. That way, if Orbital, LM, Boeing, etc are using the same software, they can find each other's mistakes while also avoiding having to write it all in-house. If you want, make a standard interface so that two portable avionics packages can be developed independently and in parallel, so if a problem with one package is found, another can be substituted.
I am excited about the future testing possibilities of using reusable and recoverable suborbital VTVL and HTHL craft to easily and quickly test subsystems in actual space conditions at a very low cost. Want to make sure if your 50kg avionics box can handle the space environment without having to launch it? That'll be $12,000. Do you want it launched just after lunch? When do you want it back by? 4pm? Thanks for doing business with us.
-
And we should be reusing avionics software using a refined, modular approach that can decrease errors and costs simultaneously. Even open-source it (maybe only among those with security clearance), if you can. That way, if Orbital, LM, Boeing, etc are using the same software, they can find each other's mistakes while also avoiding having to write it all in-house. If you want, make a standard interface so that two portable avionics packages can be developed independently and in parallel, so if a problem with one package is found, another can be substituted.
Robotbeat, that is the best idea I've heard in a very long time.
I'm a software engineer, and when I heard (from friends in the space industry) that each new FCS package is written pretty much from scratch, I was shocked. That's not only crazy expensive, it also vastly increases the risk of errors. And of course, it explains why avionics is often the "long pole" item in new launch vehicle development.
One would think that after 50 years of spaceflight, we'd have a standard open-source FCS library that could be adapted to different launch vehicles and mission profiles.
-
And we should be reusing avionics software using a refined, modular approach that can decrease errors and costs simultaneously. Even open-source it (maybe only among those with security clearance), if you can. That way, if Orbital, LM, Boeing, etc are using the same software, they can find each other's mistakes while also avoiding having to write it all in-house. If you want, make a standard interface so that two portable avionics packages can be developed independently and in parallel, so if a problem with one package is found, another can be substituted.
Robotbeat, that is the best idea I've heard in a very long time.
I'm a software engineer, and when I heard (from friends in the space industry) that each new FCS package is written pretty much from scratch, I was shocked. That's not only crazy expensive, it also vastly increases the risk of errors. And of course, it explains why avionics is often the "long pole" item in new launch vehicle development.
One would think that after 50 years of spaceflight, we'd have a standard open-source FCS library that could be adapted to different launch vehicles and mission profiles.
Hmm... I smell opportunity!
-
No, it is a bad idea. Do Airbus and Boeing use the same avionics? No. Avionics are supplied by competitors, with computers and architectures and hence different software and coding.
-
No, it is a bad idea. Do Airbus and Boeing use the same avionics? No. Avionics are supplied by competitors, with computers and architectures and hence different software and coding.
Reluctant as I am to disagree with you on technical issues, as a software guy myself I have to agree with Robotbeat and Bernie here. Have you worked on flight software yourself? What are some things that would make reuse difficult? I read somewhere that the flight software for X-38 was very portable (across computer hardware and operating systems, not necessarily across vehicles) and that ESA/DLR were very proud of that. I know the shuttle FSW uses hardware dependent tricks, but even so I'd be really surprised if some use couldn't be made of it. I've done massive restructuring on complicated numerical software and it isn't necessarily easy, but certainly possible.
-
There are some items, like the Guidance Computer which should be pretty well understood and are in fact already emulated (I know emulators are slower typically than the descrete components they replace, but in this case that's hard to imagine).
In fact there is an Orbiter add-on that uses real Apollo binaries running on a simulated guidance computer in realtime!
-
Do Airbus and Boeing use the same avionics? No. Avionics are supplied by competitors, with computers and architectures and hence different software and coding.
Airbus and Boeing are competing with each other for the sale of commercial jetliners. Companies building launch vehicles under contract to the United States Government are ultimately working for the taxpayers.
If NASA were to specify in its contracts that all avionics developed for future launch vehicles and spacecraft will be based on a standard, flight-proven open-source FCS library, then that's the way it will be done.
And the days of software being tied to a particular hardware platform are long gone. Flight control software can (and should) be written in a portable, modular form that can be adapted to different avionics hardware. At its core will be some sort of RTX, along with the flight-control algorithms themselves. Inputs and outputs would be handled by custom code, but those pieces are very small and can be debugged on the ground (basically reading accelerometers, rate gyros, star sensors, possibly GPS inputs etc and providing control signals for thrust gimbals, RCS systems and so on).
-
No, it is a bad idea. Do Airbus and Boeing use the same avionics? No. Avionics are supplied by competitors, with computers and architectures and hence different software and coding.
Actually, Boeing does use the same Avionics in some of it's craft as you'd find in it's competition. Honeywell, for instance, has it's avionics packages in multiple airplanes, and yes, both Boeing and Airbus do use the same avionics.
-
The algorithms for guidance and trajectory are easy. The issue is the vehicle specific stuff
-
The algorithms for guidance and trajectory are easy. The issue is the vehicle specific stuff
But even there you would expect similarities. It would be very surprising if you couldn't abstract out reusable components there. This is common in many domains across very different applications.
-
The algorithms for guidance and trajectory are easy. The issue is the vehicle specific stuff
Right, but that can be minimized through a commodity control interface system. You make a central control computer, a commodity interface, and by doing so you minimize the vehicle specific stuff to the end-chain of the control system. This is how airplanes work nowadays, have since the 1990's.
-
Airbus and Boeing are competing with each other for the sale of commercial jetliners. Companies building launch vehicles under contract to the United States Government are ultimately working for the taxpayers.
If NASA were to specify in its contracts that all avionics developed for future launch vehicles and spacecraft will be based on a standard, flight-proven open-source FCS library, then that's the way it will be done.
wrong. NASA doesn't buy rockets*, it buys commerical# launch services and will be buying crew launch services. It doesn't buy hardware, it buys a service, i.e. place this spacecraft in this orbit. It doesn't tell the contractor how to design the solution. So Atlas, Delta, Falcon, Pegasus, Taurus, etc have their own solutions for this. They have their own avionics and software and how they do it is how it suits them and how they see to be competitive.
* this is no applicable to Ares
# get it? commercial airplane, commercial rocket
-
The algorithms for guidance and trajectory are easy. The issue is the vehicle specific stuff
Quite right -- the guidance and trajectory algorithms are nothing new, but they are essential. And combined with a solid real-time kernel, that's the bulk of the FCS, and certainly the most complex part.
The vehicle-specific stuff can be thought of as a collection of drivers, roughly analogous to a printer driver on your computer. You don't need to buy a new copy of Microsoft Word just because you buy a new printer -- Word just talks to the printer driver over a standard API, and the driver provided by the manufacturer handles everything that's device-specific.
Right now, the space industry is creating a new version of Word for every printer, which is one reason why avionics takes so long to develop.
-
Right now, the space industry is creating a new version of Word for every printer, which is one reason why avionics takes so long to develop.
No, it is creating a new computer with new OS.
-
New computers don't require a wholly new operating system.
-
The algorithms for guidance and trajectory are easy. The issue is the vehicle specific stuff
Quite right -- the guidance and trajectory algorithms are nothing new, but they are essential. And combined with a solid real-time kernel, that's the bulk of the FCS, and certainly the most complex part.
The vehicle-specific stuff can be thought of as a collection of drivers, roughly analogous to a printer driver on your computer. You don't need to buy a new copy of Microsoft Word just because you buy a new printer -- Word just talks to the printer driver over a standard API, and the driver provided by the manufacturer handles everything that's device-specific.
Right now, the space industry is creating a new version of Word for every printer, which is one reason why avionics takes so long to develop.
His argument was common 20 years ago... in the automobile world. Every car maker had their own software, their own computer, often times not even the same between models.
The company I used to work for then sold BMW on a commodity control computer, with special sub-control nodes for various subsystems, using a commodity OS.
Guess what? It worked just as well as their expensive custom-per-car solution, *AND* cost them less.
-
Right, but that can be minimized through a commodity control interface system. You make a central control computer, a commodity interface, and by doing so you minimize the vehicle specific stuff to the end-chain of the control system. This is how airplanes work nowadays, have since the 1990's.
the launch vehicles are using older systems. 1995 for Delta
System qualification for environments is the big issues.
-
Right, but that can be minimized through a commodity control interface system. You make a central control computer, a commodity interface, and by doing so you minimize the vehicle specific stuff to the end-chain of the control system. This is how airplanes work nowadays, have since the 1990's.
the launch vehicles are using older systems. 1995 for Delta
System qualification for environments is the big issues.
...and? That goes without saying, but is a straw man argument. You can make commoditized avionics *and* be qualified for the environments as well. Look at French nuclear reactor control systems. Those deal with extremes of environments, but are commoditized between themselves.
-
And the days of software being tied to a particular hardware platform are long gone. Flight control software can (and should) be written in a portable, modular form that can be adapted to different avionics hardware.
not if aircraft don't do it.
-
...and? That goes without saying, but is a straw man argument. You can make commoditized avionics *and* be qualified for the environments as well. Look at French nuclear reactor control systems. Those deal with extremes of environments, but are commoditized between themselves.
LV providers aren't going to change just because there is something newer available. My point was Delta is using 15 year old technology and isn't going to change in the near future
-
not if aircraft don't do it.
Why not? Don't you think it's possible software experts know more about reusable software than you do? Not having seen the software in question I can't know for sure in the case of flight software, but similarly not having seen what Bernie, Downix, Robotbeat and I have seen how could you know for sure?
A lot of improvement regarding reuse is possible in the software world generally, is it obvious the same couldn't be true for flight software? I personally would be amazed if that weren't so.
-
not if aircraft don't do it.
Why not? Don't you think it's possible software experts know more about reusable software than you do? Not having seen the software in question I can't know for sure in the case of flight software, but similarly not having seen what Bernie, Downix, Robotbeat and I have seen how could you know for sure?
Honeywell has different software than Collins.
-
wrong. NASA doesn't buy rockets*, it buys commerical# launch services and will be buying crew launch services.
* this is not applicable to Ares
Your footnote is my entire point.
If we were talking about commercial launch services on existing launch vehicles, this entire discussion wouldn't be necessary. The avionics for those systems have already been built and are in use today.
What we're talking about *is* Ares (or Jupiter...), that is to say new vehicles that are being designed by NASA and not by private industry. When NASA issues those contracts, they can specify exactly how the avionics should be handled, the same way they specify (in exacting detail) everything else.
Now, I believe private industry should be free to use the avionics software as well if it chooses to. I suspect that SpaceX would rather just use an existing software package rather than pay people to re-invent the wheel.
-
Your footnote is my entire point.
Ares will be the last launch vehicle NASA is going to build. The avionics contract was let two years ago.
-
I suspect that SpaceX would rather just use an existing software package rather than pay people to re-invent the wheel.
No, Spacex has shown that they prefer to do everything in house, since they have re-invented the wheel on everything else.
-
Also FCS is an ITAR item
-
Honeywell has different software than Collins.
Of course, but how could you know for sure a fairly large common library couldn't be extracted from the combined software, which the common part being considerably larger than the specific part? It would seem that you would need to be familiar with 1) modern software reuse techniques, 2) the specific software involved and 3) the hardware it is driving and interfacing with. You no doubt are deeply knowledgeable about 3) and perhaps 2), but are you familiar with 1)? All of us together here could no doubt answer this question together given a budget. It is not obvious any of us alone could.
Having said that I'll say that I'd consider it remarkable if flight software were so radically different from the other forms of software I've encountered.
-
Ares I and V both used (or were going to use) VxWorks (a real-time OS). So does SpaceX. So does BMWs. So does both Boeing and Airbus. So does the last 4 or 5 probes NASA has sent to Mars. So does my wireless router.
Increased reuse and modularity of software components is a trend that will continue. It really is the best way to do it.
-
Ares I and V both used (or were going to use) VxWorks (a real-time OS). So does SpaceX. So does BMWs. So does both Boeing and Airbus. So does the last 4 or 5 probes NASA has sent to Mars. So does my wireless router.
OS is not the same as FCS
-
Ares I and V both used (or were going to use) VxWorks (a real-time OS). So does SpaceX. So does BMWs. So does both Boeing and Airbus. So does the last 4 or 5 probes NASA has sent to Mars. So does my wireless router.
OS is not the same as FCS
That's true, but at one point, even using a commodity, commercial-off-the-shelf real-time kernel was not common practice, either. People used the same sort of arguments then.
-
Ares I and V both used (or were going to use) VxWorks (a real-time OS). So does SpaceX. So does BMWs. So does both Boeing and Airbus. So does the last 4 or 5 probes NASA has sent to Mars. So does my wireless router.
And why haven't the commercial aircraft done it?
OS is not the same as FCS
That's true, but at one point, even using a commodity, commercial-off-the-shelf real-time kernel was not common practice, either. People used the same sort of arguments then.
-
OS is not the same as FCS
No, but the FCS is built on top of the OS. So if we adopt a standard OS (sounds like a lot of people have chosen VxWorks) and write standard FCS on top of that, then contractors just have to write the drivers for whatever hardware they're using.
-
Turns out we're not the first people to think of this. :-)
Apparently NASA Goddard has already been working on doing exactly what we've been discussing ere:
http://www.flightsoftware.org/files/FSW08_Wildermann.ppt
http://www.flightsoftware.org/files/FSW08_Cudmore.pdf
-
OS is not the same as FCS
No, but the FCS is built on top of the OS. So if we adopt a standard OS (sounds like a lot of people have chosen VxWorks) and write standard FCS on top of that, then contractors just have to write the drivers for whatever hardware they're using.
No, because there is no standard that is applicable. There isn't one spreadsheet program or financial program.
-
Turns out we're not the first people to think of this. :-)
Apparently NASA Goddard has already been working on doing exactly what we've been discussing ere:
We aren't talking spacecraft. They are different than launch vehicles. They are not as dynamic nor do they have similar systems. Spacecraft are mostly concerned with data handling vs flight control and actually, some spacecraft don't even have flight control onboard. Navigation and guidance are done on the ground.
Also that is inhouse and isn't going to be open source.
Another thing, contractors are not going trust open source software for launch vehicles. Not with the amount of money involved.
-
And why haven't the commercial aircraft done it?
Maybe because they don't know how to do it. As the saying goes: If builders built buildings the way programmers wrote programs, the first woodpecker to come along would destroy civilization.
Pretty much everywhere I've gone I've found crappy code. The same goes for my friends and colleagues. To first approximation everything is crap. Web applications, operating systems, automotive and aerospace systems, scientific software, games, financial software, you name it. Our economy runs on crap. Financial markets run on crap, bridges are designed with crap, washing machine code is crap. And even the stuff that works well is usually a maintenance nightmare. It doesn't matter if you had PhDs and engineers working on it or a bunch of script kiddies, the code is likely a mess. With PhDs and engineers you have a halfway decent chance it will work. But not that it won't be a mess. There are exceptions, but they truly are exceptions, not the rule.
We aren't talking spacecraft. They are different than launch vehicles. They are not as dynamic nor do they have similar systems. Spacecraft are mostly concerned with data handling vs flight control and actually, some spacecraft don't even have flight control onboard. Navigation and guidance are done on the ground.
Are you talking about things like pressurisation of cryogenic tanks?
Also that is inhouse and isn't going to be open source.
That sounds likely enough, but that's an organisational concern not a technical constraint.
Another thing, contractors are not going trust open source software for launch vehicles. Not with the amount of money involved.
I believe you, but note that ESA has released the VHDL for a rad hardened SPARC variant for aerospace applications.
No, because there is no standard that is applicable. There isn't one spreadsheet program or financial program.
There are modular systems that can be configured however. Things like SAP. You always need some custom programming and a lot of configuration but there is a large amount of reuse. If there isn't a standard one could be created. Whether that would be economical for launch vehicles is doubtful because there are relatively few of them. But I'd be really surprised if given the source code to the Atlas and Delta flight software and a budget you and I together couldn't extract a common core.
If you say it isn't technically possible I'll say you probably don't know enough about software reuse to make that call. I know I don't know even 1% of what I'd need to know about launch vehicles to make that call. But it would have to be pretty special to make it immune to the same reuse techniques that work so well elsewhere. Wouldn't it be fun to know for sure?
-
And why haven't the commercial aircraft done it?
Maybe because they don't know how to do it. As the saying goes: If builders built buildings the way programmers wrote programs, the first woodpecker to come along would destroy civilization.
My point is that there are multiple aircraft developments and plenty of opportunity to incorporate this if it was a good idea. LV develop occurs maybe once per decade.
-
LV develop occurs maybe once per decade.
And each time, they re-write the FCS from scratch. Not just for launch vehicles, either -- the Orion has its own FCS, and the Altair would have as well. They're done by separate contractors, so each of them re-invents the wheel, wasting time and money and running the risk of introducing bugs that could potentially cripple a spacecraft during a mission.
Every unmanned Mars lander has an FCS. Sample return missions will probably have two (one for the ascent stage). When we eventually build a lunar lander, there's another one (or two). Manned Mars landers will need an FCS or two as well.
Why not write most of the code just once, invest the time and manpower to make sure it's robust, make it open-source and then re-use it whenever it's needed? Make improvements along the way, if needed, and that way everything that follows shares those improvements as well.
-
My point is that there are multiple aircraft developments and plenty of opportunity to incorporate this if it was a good idea. LV develop occurs maybe once per decade.
Well, my point was more that it was more likely to be either because of a lack of expertise with software reuse techniques (very common) or because it doesn't make economic sense and not because it would be technically impossible.
The economics could account for the fact that it's done for spacecraft and not for launch vehicles, not just because they are technically simpler but also because there are many more of them. I wouldn't be surprised if economics turned out to be the explanation even for aircraft. How many aircraft development projects are there at any given time? Probably not nearly as many as automotive projects. Tens to hundreds might be the minimum number for a middleware company to be viable.
Within a single organisation it might be different. Upgrading the flight software along with the launch vehicle could be a good idea. This is the argument Shannon made and I believe he may well be right. Not that I'd want him to be successful of course.
-
LV develop occurs maybe once per decade.
And each time, they re-write the FCS from scratch. Not just for launch vehicles, either -- the Orion has its own FCS, and the Altair would have as well. They're done by separate contractors, so each of them re-invents the wheel, wasting time and money and running the risk of introducing bugs that could potentially cripple a spacecraft during a mission.
Every unmanned Mars lander has an FCS. Sample return missions will probably have two (one for the ascent stage). When we eventually build a lunar lander, there's another one (or two). Manned Mars landers will need an FCS or two as well.
Why not write most of the code just once, invest the time and manpower to make sure it's robust, make it open-source and then re-use it whenever it's needed? Make improvements along the way, if needed, and that way everything that follows shares those improvements as well.
ITAR is a good reason.
Because LV's, orbiters and landers do not have the same requirements for FCS. generic software is worse than unique software. The actual flight control part for spacecraft is very small, it is most data management. Orion being an exception, most spacecraft don't need flight control
Word processing software is not good for spread sheets.
-
And each time, they re-write the FCS from scratch. Not just for launch vehicles, either -- the Orion has its own FCS, and the Altair would have as well. They're done by separate contractors, so each of them re-invents the wheel, wasting time and money and running the risk of introducing bugs that could potentially cripple a spacecraft during a mission.
Hasn't happened.
-
And each time, they re-write the FCS from scratch.
This is how it is in commercial aircraft and commercial aircraft propulsion as well. There, each manufacturer uses their own hardware as well as software.
-
And each time, they re-write the FCS from scratch.
This is how it is in commercial aircraft and commercial aircraft propulsion as well. There, each manufacturer uses their own hardware as well as software.
No, it is not. Boeing, Airbus, Lockheed, Learjet, all utilize components built by other manufacturers for these, with these components being standardized and re-using code, OS, hardware, between them all.
-
generic software is worse than unique software.
This is too broad a statement. For software development in general the choice isn't between unique or generic, it's about levels of reuse and more importantly about separating the code into very fine-grained layers and modules. That itself facilitates reuse. I'd expect meaningful amounts of potential reuse between the Altair and Orion software. Crossing organisational boundaries is very difficult and expensive however and that could easily wipe out the technical gains, unless you have many clients for a shared library. However if Altair and Orion were going to be done by the same organisation it would have made enormous sense to share code. It would also have made sense to share and rotate team members.
Also consider the impact of cross training, sharing development tools, procedures and standards, simulators etc.
Word processing software is not good for spread sheets.
Yet the various programs that make up a package like MS Office or OpenOffice can and do share meaningful amounts of code. Again, it's a matter of degree of reuse. This is really an important point in software design and it's overlooked in many organisations, even in organisations whose main products are software. It's possible things are different for aerospace applications but it seems unlikely.
-
Why not write most of the code just once, invest the time and manpower to make sure it's robust, make it open-source and then re-use it whenever it's needed? Make improvements along the way, if needed, and that way everything that follows shares those improvements as well.
It'll never work. Makes too much sense.
-
not if aircraft don't do it.
Why not? Don't you think it's possible software experts know more about reusable software than you do? Not having seen the software in question I can't know for sure in the case of flight software, but similarly not having seen what Bernie, Downix, Robotbeat and I have seen how could you know for sure?
A lot of improvement regarding reuse is possible in the software world generally, is it obvious the same couldn't be true for flight software? I personally would be amazed if that weren't so.
PayPal can be used from both PCs and Apples.
Did SpaceX find any commonality between the Falcon 1, Falcon 9 and Dragon software?
-
I'd hope so. But I can't see there would be much of a market for generic launch vehicle flight software. Limited reuse of certain key libraries might be different, but probably only to the degree they apply to more than just launch vehicles.
But here's a related but very different market: the range from high-end amateur rocketry to the sort of thing Masten is doing. Things like the sugar shot to space.
-
Did SpaceX find any commonality between the Falcon 1, Falcon 9 ?
Of course, they are the same, they use the same avionics. Just like Delta II, III & IV and Atlas II, III & V
-
PayPal can be used from both PCs and Apples.
Not applicable, it is web based
-
I'd hope so. But I can't see there would be much of a market for generic launch vehicle flight software. Limited reuse of certain key libraries might be different, but probably only to the degree they apply to more than just launch vehicles.
But here's a related but very different market: the range from high-end amateur rocketry to the sort of thing Masten is doing. Things like the sugar shot to space.
Well, there is a compromize in there, rather than develop a whole system, instead develop key components which can then be adapted to the specific system. That is how the commoditization of airplane Avionics occured, after all.
So, if you all are on the same page, rather than go "why doesn't someone make it" we should be going "let us make it." I'm game.
-
Gimme a call, Nate. There's nothing wrong with that trailing edge technology. It was built right, and it was built to be used.
-
About generics.
A Swiss army knife has many uses. A damascus steel, cocobolo handled knife will prove to be an expensive screwdriver.
There's times, places, and usages for generic products and special built products. A blanket statement cannot cover all eventualities.
I liked that comment about the woodpecker, because it really rings true.
And another observation about code: My HP12C calculator will readily compute F=ma. Clearly it is limited in its abilities by the amount of time required to program much beyond that. However, the physics never changes. There can be commonality in the code based on certain principles, and it is not as widespread as it could be. There are principles of Flight Control Software, for example.
I think that the problem is more about copyrights, cookies, and such, however. There's a lot of effort spent in proprietary systems that must be duplicated between contractors. This won't change if we are to continue to have a free marketplace. There's also a lot of effort in sneaky pete backdoors into code, which could be eliminated. In addition, there's too much overhead built into the code; data structures, for example. Further there are imperfect implementations of faulty code specifications. Then there are flat out errors; bugs in the code for one, but worse things, such as database implementations with duplicate keys.
Code is a big problem. Just had to vent a bit.
Web based code is code, nevertheless. It speaks to Apples and PC's.
-
Wow, long way from the beginning of this thread.
Regarding FCS software, comparing Class based OOC (object oriented code - ie. reusable code) to monolithic code is like comparing a word processor to a cuniform tablet, or comparing the stone age to the space age.
So why is FCS still being written on "stone tablets?" I suspect it's just a matter of cost. If you're going to write a one-off program for one piece of hardware that's going to be around, largely unchanged, for ten, fifteen, thirty? years, what's the point?
OOC works great in the commercial world where RAD and portability are paramount. But really, look at the history of space exploration. Rapid Application Development? (hardee har har).
-
Wow, long way from the beginning of this thread.
Regarding FCS software, comparing Class based OOC (object oriented code - ie. reusable code) to monolithic code is like comparing a word processor to a cuniform tablet, or comparing the stone age to the space age.
So why is FCS still being written on "stone tablets?" I suspect it's just a matter of cost. If you're going to write a one-off program for one piece of hardware that's going to be around, largely unchanged, for ten, fifteen, thirty? years, what's the point?
OOC works great in the commercial world where RAD and portability are paramount. But really, look at the history of space exploration. Rapid Application Development? (hardee har har).
Which is why it'd be a good idea to implement reusable code. Math doesn't change, so code could be reused for decades, continually being refined. How much of the standard FORTRAN libraries are still being used for scientific computing on supercomputers, although in a greatly modified form?
The question we should ask is: do we LIKE having avionics being the long-pole of spacecraft/launch vehicle development?
-
Wow, long way from the beginning of this thread.
Regarding FCS software, comparing Class based OOC (object oriented code - ie. reusable code) to monolithic code is like comparing a word processor to a cuniform tablet, or comparing the stone age to the space age.
So why is FCS still being written on "stone tablets?" I suspect it's just a matter of cost. If you're going to write a one-off program for one piece of hardware that's going to be around, largely unchanged, for ten, fifteen, thirty? years, what's the point?
OOC works great in the commercial world where RAD and portability are paramount. But really, look at the history of space exploration. Rapid Application Development? (hardee har har).
Which is why it'd be a good idea to implement reusable code. Math doesn't change, so code could be reused for decades, continually being refined. How much of the standard FORTRAN libraries are still being used for scientific computing on supercomputers, although in a greatly modified form?
The question we should ask is: do we LIKE having avionics be the long-pole of spacecraft/launch vehicle development?
Actually, you made me think of the history of COBOL in the banking industry, which started out as mono code and is now OOC, but the routines are largely unchanged.
-
The references to FORTRAN and COBOL reify the importance of programming standards as the basis for any demonstrated reuse of code. I'm not certain what has become of Ada in the defense industry, but that seems to be the level of interchangeable source standard that can then be compiled as needed for even proprietary processors.
And since I work in documentation standards (particularly the XML-based Darwin Information Typing Architecture, or DITA), I have the same concern for documentation reuse at the enterprise. When a code or document architecture like DITA has been specifically designed for reuse, it can accompany the hardware for easier integration into the "deliverable," whether it be a PC or an instrumentation adapter. The reuse strategy should ideally include all project artifacts including protocols, code, documentation, message formats, etc., with a design aim for maximum interchangeabilty.
-
Math doesn't change, so code could be reused for decades
Yes, it does. There are different ways to skin the cat. Atlas and Delta codes are vastly different, they use different algorithms.
-
Math doesn't change, so code could be reused for decades
Yes, it does. There are different ways to skin the cat. Atlas and Delta codes are vastly different, different algorithms.
I agree that algorithms change, but why develop new algorithms each time if it's not required? You could add it as a reusable module, so that the next time a similar problem pops up, you have a solution right there that's already certified and debugged.
-
Math doesn't change
Yes, it does.
Okay, at this point it's getting silly.
Jim, are you being contrary just for the fun of it?
If so, that's fine, I can respect that. I just want to know if it's worth my continuing the discussion.
-
Math doesn't change
Yes, it does.
Okay, at this point it's getting silly.
Jim, are you being contrary just for the fun of it?
If so, that's fine, I can respect that. I just want to know if it's worth my continuing the discussion.
see the rest of the post
-
I agree that algorithms change, but why develop new algorithms each time if it's not required?
Because the vehicles are different. Like I said, LV, spacecraft and landers have different requirements. A comsat doesn't need FCS, only simple attitude control. A scientific spacecraft worries about data handling and not trajectory optimization. A manned spacecraft only worries about orbit modification and rendezvous.
The only thing common is equations of motion.
-
The only thing common is equations of motion.
Surely you jest: basic linear algebra, quaternions, ODE solvers, Kalman filters, telemetry, encryption...
-
The only thing common is equations of motion.
Surely you jest: basic linear algebra, quaternions, ODE solvers, Kalman filters, telemetry, encryption...
telemetry and encryption are not part of the question. FCS doesn't handle telemetry.
As for the others, that is just math and is not the algorithms
-
telemetry and encryption are not part of the question. FCS doesn't handle telemetry.
So what's the correct term for the software that does that?
As for the others, that is just math and is not the algorithms
But they could be part of a reusable library. When you say algorithms are you speaking specifically of control laws? Because the math routines themselves are of course also algorithms...
-
The only thing common is equations of motion.
Surely you jest: basic linear algebra, quaternions, ODE solvers, Kalman filters, telemetry, encryption...
telemetry and encryption are not part of the question. FCS doesn't handle telemetry.
As for the others, that is just math and is not the algorithms
Algorithms ARE math.
And actually, there are is weird FCS (for unmanned helicopters, for instance) that is non-algorithmic (using a neural network, for instance).
EDIT: And there is no reason you couldn't have algorithms (or a neural net implementation) developed for reusability and portability.
EDIT AGAIN: Don't use neural nets for a launch vehicle FCS. Don't.
-
So what's the correct term for the software that does that?
no real name. On launch vehicles, completely separate systems.
-
no real name. On launch vehicles, completely separate systems.
And are these reused or developed from scratch for new launch vehicles? How different if at all are they from the ones used on spacecraft?
-
And are these reused or developed from scratch for new launch vehicles? How different if at all are they from the ones used on spacecraft?
New. There is no commanding of launch vehicles, so the telemetry is gathered and transmitted on a dedicated system. LV FCS use very little data (telemetry) of the vehicle. For example, the guidance system knows that an engine is burning by the sensed acceleration vs thrust chamber pressure or turbo pump speed.
Simplistically
For comsats, it is part of the TT&C system. For science, it is part of the C&DH system.
-
There is no commanding of launch vehicles
Didn't you state a while ago that Centaur could be retargeted in flight? Or does commanding refer to something else?
-
There is no commanding of launch vehicles
Didn't you state a while ago that Centaur could be retargeted in flight?
It does that itself
-
PayPal can be used from both PCs and Apples.
Not applicable, it is web based
It is applicable, the same man is in charge. We are talking about his skill set.
I did notice that you had edited out the Dragon from what I wrote.
-
PayPal can be used from both PCs and Apples.
Not applicable, it is web based
It is applicable, the same man is in charge. We are talking about his skill set.
I did notice that you had edited out the Dragon from what I wrote.
Aren't the Dragon cockpit computers based on Boeing 787 cockpit computers?
cheers, Martin
-
PayPal can be used from both PCs and Apples.
Not applicable, it is web based
It is applicable, the same man is in charge. We are talking about his skill set.
I did notice that you had edited out the Dragon from what I wrote.
Aren't the Dragon cockpit computers based on Boeing 787 cockpit computers?
cheers, Martin
Orions is based on the FA-18.
-
It is applicable, the same man is in charge. We are talking about his skill set.
I did notice that you had edited out the Dragon from what I wrote.
Wrong that is just other ludicrous statement and again shows again that you don't what you are talking about. It is not the same skill set. Also, he is not writing the code for Falcon 1 & 9. I left out dragon because I don't know what its software legacy it is.
Just don't bother posting
-
PayPal can be used from both PCs and Apples.
Not applicable, it is web based
It is applicable, the same man is in charge. We are talking about his skill set.
I did notice that you had edited out the Dragon from what I wrote.
Aren't the Dragon cockpit computers based on Boeing 787 cockpit computers?
cheers, Martin
Orions is based on the FA-18.
Orion is 787
-
Just a point : robotics industry actually shows trends in modularizing and unifying parts of the code.
Every piece of robotics HW is different, sure. Every CPU arch is different, not to speak of the actual chip itself, sure. I have been working with >10 different ones on my table daily now and then. Messaging methods and buses, types of sensors, actuators, the actual problems being solved, be it localization or forward kinematics, filtering or whatever are vastly different.
Nevertheless, the architectures and design principles are roughly the same, things tend to move to a componentized and service-based architectures, and there is a big pile of actual code bits to be reused.
Note that this does not mean "one size fits all". I am aware of at least four relatively well run robotics software frameworks that are open, there are probably a bunch more documented in Japanese or Korean, and definitely another pile that is proprietary.
However, the better and more universal the architecture implemented by the framework is, obviously the more popular it becomes, and hence more eyes go over the code, and the code will get a shakeout in bigger array of implementations.
I do not see why the approach that has benefited the field of robotics would not benefit the field of avionics and flight control.