-
#60
by
Jim
on 29 Jan, 2010 02:19
-
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.
-
#61
by
Lee Jay
on 29 Jan, 2010 02:22
-
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.
-
#62
by
Downix
on 29 Jan, 2010 02:24
-
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.
-
#63
by
mmeijeri
on 29 Jan, 2010 02:36
-
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.
-
#64
by
TOG
on 29 Jan, 2010 03:59
-
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.
-
#65
by
A_M_Swallow
on 29 Jan, 2010 05:41
-
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?
-
#66
by
mmeijeri
on 29 Jan, 2010 11:08
-
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.
-
#67
by
Jim
on 29 Jan, 2010 11:16
-
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
-
#68
by
Jim
on 29 Jan, 2010 11:18
-
PayPal can be used from both PCs and Apples.
Not applicable, it is web based
-
#69
by
Downix
on 29 Jan, 2010 12:11
-
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.
-
#70
by
JohnFornaro
on 29 Jan, 2010 13:57
-
Gimme a call, Nate. There's nothing wrong with that trailing edge technology. It was built right, and it was built to be used.
-
#71
by
JohnFornaro
on 29 Jan, 2010 14:19
-
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.
-
#72
by
Takalok
on 29 Jan, 2010 16:24
-
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).
-
#73
by
Robotbeat
on 29 Jan, 2010 16:28
-
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?
-
#74
by
Takalok
on 29 Jan, 2010 16:37
-
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.
-
#75
by
MarsInMyLifetime
on 29 Jan, 2010 16:55
-
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.
-
#76
by
Jim
on 29 Jan, 2010 17:02
-
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.
-
#77
by
Robotbeat
on 29 Jan, 2010 17:05
-
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.
-
#78
by
Bernie Roehl
on 29 Jan, 2010 17:06
-
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.
-
#79
by
Jim
on 29 Jan, 2010 17:08
-
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