Surrey Satellite Technology Ltd. is a world leader in spacecraft design. They regularly sell to the US Air Force, and have a number of American companies running scared (it's not uncommon to hear US companies state that they "aim to be the Surrey of the US" at trade shows and conferences).
I don't particularly lke GWB, but the lay-offs have little to do with his "vision for space", and more to do with poor budget management at NASA. AFAIK the primary reason they just laid off at JPL was that they ramped up staffing tremendously during the crunch to get the Spirit and Opportunity rovers finished on time (MER was completed on an incredibly short timescale for a planetary exploration mission - 3 years from start to finish). Unfortunately, the work on MER not only caused a staffing spike, it also went pretty heavily over budget, so several missions were pushed back to free up near-term money to finance MER. Now that MER has wound down there's nothing for a lot of the engineers that were hired during the staffing spike to do: NASA's near-term Mars budget was committed to paying for MER (already done), and the next big projects won't really ramp up for a few years yet.
The current replacement rate is designed to slowly phase out existing satellites before they hit their (statistical) expected end-of-life. It's not intended to cope with unexpected (i.e. low probability, such as 4 or 5 satellites dying at once) failures. Nor does it have to. The GPS constellation includes a number of "on-orbit spares" (i.e. spare satellites already in the GPS orbits), which can be used to ensure continuous availability in the face of an unexpected failure. AFAIK the typical scenario is something like:
GPS satellite fails
On-orbit spare is activated
New satellite launched some months later becomes a spare
However, in the case of the radiation therapy controller I think it's pretty safe to assume that the folks doing the implementation were extremely careful to ensure that the implementation matched the spec, and, in cases where there was a deviation from the original spec, to incorporate that deviation back into a revised spec and check that the overall system logic was maintained. So yeah, I'm pretty confident the spec exactly decribes the functionality.
In the case of the TCP/IP formalization, the spec was carefully reverse engineered from existing TCP/IP implementations, and extensively tested to ensure that it accurately captured corner-cases. As you would know had you bothered to actually look at the paper in question. So, again, I feel confident that the spec accurately represents the functionality.
On a more philosophical note, I find the notion of "code as spec" repugnant at best. Essentially what you're saying is that "the purpose of the software is what it does". Which has two problems IMHO: (a) by definition there's no such thing as a bug in such software (which isn't really an acceptable notion in the real world), since "bug" is simply another name for "deviation from spec"; and (b) anyone who wants to really understand the behavior of the software has to do the same kind of intense reverse engineering that the folks in the TCP/IP paper did. Personally, I'd rather see real specs that describe what a piece of software is supposed to do, which the implementation is programmed against, and which are revised to reflect any changes that occur during implementation (with the added advantage that these changes can be analyzed to ensure that the don't break the system in some subtle way). I'm not talking about hand-wavy "architecture diagrams" and the like. I'm talking about precise behavior specifications that permit real understanding and analysis.
I realize that you're kidding around. But I wanted to point out that the existence of a "bug" presupposes some kind of "specification" which delineates what the "correct" behavior of a program is. With no definition of correctness (either explicitly on paper, or implicitly in your head) there is no way to recognize "incorrect" behavior, aka bugs.
A spec says exactly what the product does. When I ever see a spec that does that, I might change my mind about specs being necessary.
Try this example, for a radiation therapy machine. You might also try this paper on formal specification of TCP/IP and parts of C.
The problem isn't that specification itself is bad. It's that most "specifications" are written by people who don't know what they're doing, and end up being vague and wishy-washy.
Which explains a lot about why the software development process is so broken. In most engineering disciplines, the ultimate customer does not write the spec. They don't have the technical knowledge to do so. Yes, some companies will provide components "to spec". But those specs are developed by whoever is acting as the technical intermediary for the ultimate customer.
Consider an office building. Would you expect the company that will occupy the office building to write the specs? No. Would they even write the "requirements"? Unlikely. They would hire an architect to determine their requirements, and to spec out a design (blueprints, engineering drawings, materials specifications, etc.) that meets the requirements (probably through several iterations with the customer, showing them different drawings and plans). That spec will get handed off to contractors and engineers, who will then build based on the spec. Note the phrase "based on". In many cases the spec and design will develop in the course of building. (Disclaimer: I have no experience in architecture, but that's my understanding of how the process works)
The same kind of thing happens in spacecraft design. A scientist will come up with an idea for a mission to collect certain science data using some instrument (I'll assume that the instrument is already defined). Does the scientist spec the spacecraft? No. Do they have some preliminary "requirements"? Maybe, of they've worked on a mission before. But those requirements aren't likely to be final - they may not be technically feasible. So, what happens? The scientist gets a spacecraft system engineer to perform preliminary analysis and design work to refine their requirements, and to spec out a high-level design. The spec and design is then iteratively refined and fleshed-out by a team of engineers, and finally built and tested. (Disclaimer: I have experience on spacecraft development projects. This is exactly how it works. Is it a cut-and-dried, clinical process? No. Nothing involving design is. But the essentials are pretty much the way I just described.
As an aside: I think that XP and agile development do a nice job of the iterative part of the design process. A really nice job. And iteration is critical to giving the customer what they want. I just don't buy into the myth that upfront design is a bad idea. Upfront specification design, done well, is invaluable for figuring out what to code, and eliminating errors in understanding early in the process. That's particularly crucial for properties which are hard to "refactor" in as you go - stuff like real-time performance, or system-level security.
No company has ever demonstrated a methodology that is guaranteed (or even very likely) to deliver high quality, maintainable software in a predictable amount of time.
Really? And yet these guys seem to do a pretty good job of consistently delivering on-time, on-budget, and with an order of magnitude less defects than the rest of the industry. Is their methodology "guaranteed"? Of course not. Neither are development projects in other engineering domains. There's always risk involved in a new development. But the approach used by Praxis (careful requirements elicitation; risk-driven planning; formal specification where necessary; design by contract; etc. etc.) has been consistently demonstrated to increase the likelihood that the product you get is the product you wanted.
There is nothing inherent in software that makes it impossible to engineer. In fact, in many ways it's easier to engineer - you don't have to account for material failures, interactions between physical laws, or any of the million-and-one other things that make designing a physical product hard. All you need to do is develop a logical construct. Software development will only remain "an art" if the practitioners of software development continue to treat it as one. And that will only be tenable for as long as people are willing to accept software that is buggy and often malfunctions. The reason that every other engineering discipline emerged was that regular failure of the products in that domain could not be tolerated. It will be no different with software.
Huh? There's no way to stop that now. If you make an inaccurate map, then its not a copy of the original map, is it? So copyright wouldn't necessarily apply (depending on how the map was generated). It'd probably be better to deal with your concerns about accuracy under trademark law - only genuine maps could carry an MTA trademark.
Interestingly enough, this kind of thing is apparently exactly what the 9/11 group used. And, as the OP quote correctly pointed out, it's the sort of thing that works regardless of encryption.
It wasn't God who brought the destruction to the people...
And yet I've heard several Christian groups claim that the hurricane was a direct result of God's anger about (one or more of):
America's moral decline
Gay marriage
Abortion
Gay conventions in New Orleans
Mardi Gras beads
HillaryClinton
Ok, maybe not that last one. But I'm pretty sure I've heard the others, as well as several others I can't remember right now. I guess all the Christians in the hurricane zone were just collateral damage...
Apparently, KOffice supports Open Document. And, according to this Abiword and Gnumeric soon will. Presumably other minority (i.e. no MS) products will jump on the bandwagon as well, once it becomes obvious that Open Document has a decent mindshare.
The SSME may be the "best" using your murky figure of merit. But the SSME is, from what I have heard, a nightmare when it comes to operability and reusability. Mostly due to the excessive complexity that you alluded to. What kind of "reusable" engine requires a complete strip-down, overhaul, and burn-in between each flight? I'm trying to imagine how well commercial aviation would work if every turbofan required that kind of care and maintenance, and frankly, the picture isn't pretty.
As I recall, EngSoc was so good at putting together a decent beer-fest that a good chunk (~30% IIRC) of its members were actually Law and Arts students looking for a good time...
As others have said, the problem is not languages. However, rather than offering vague suggestions about "motivation" or "picking a goal", I have some concrete advice: try taking a look at How to Design Programs. It's textbook by some of the best minds in CS education, and its goal is to teach you how to break down and structure problems, and create programs which solve those problems - not just to teach you a language. It'll teach you to think like a programmer. Which, quite frankly, sounds like what you need. Better yet, it's freely available online (so you can easily give it a testdrive), although I'd recommend picking up the print version if you decide you like what they have to say (for the sake of readability if nothing else).
IMHO it comes down to 3 things (one of which you've already captured):
It takes a long time to get a satellite up, and chasing new technology will just make it take longer.
It is not a given that a new technology will provide benefits for a given mission. There are interactions between different elements of the design that may mean that a certain technology is not appropriate for the mission in question (the demands of EP on solar arrays being a prime example of this kind of negative interaction).
The temptation is always to cram as much capability as possible into the satellite, instead of providing the minimum capability required. This is especially true of government satellites since the requirements are typically ill-defined to begin with (at least in my experience).
These reasons apply to US government space programs. For an alternative approach, you might look at Surrey Satellite Technologies Ltd in the UK. They build and launch things quickly, have a well-defined strategy for integrating new technologies into spacecraft in a low-risk fashion and getting rapid flight-test information on them, make good use of the technologies appropriate to a mission instead of getting wedded to any one tech, and are extremely good at nailing down their requirements and building only what is needed. IMHO they are the best, and most innovative satellite manufacturer in the world today (and no, I don't work for them - although I'd do so in a heartbeat if I ever moved to the UK).
To being things slighly back on-topic, it's probably worth noting that SSTL has the contract to develop a testbed satellite for the Galileo system (the European competitor to GPS).
What you say is true. In particular, the "hot new" rad-hardened processor is the RAD750, a hardened PowerPC 750. And yet...
When the GPSIIR-M started the design process the RAD750 was nonexistent - major USAF satellites can take on the order of a decade to design and deploy.
As I've said elsewhere in this thread, electronics are not necessarily that large a contributor to spacecraft mass.
More capable processors may suck down more power, which tends to make other parts of your spacecarft (e.g. the solar arrays) larger.
Li-Ion batteries are still considered relatively unproven in a spacecraft context. They've only been used on a few missions, and the performance and lifetime data we have on them is limited. They are unlikely to be selected for a critical system like GPS at this point.
Li-Ion batteries were speculative "future technology" at the time the IIR-M was being designed. I'm pretty certain they aren't being used in the next-gen GPSIIF satellites. I'd be surprised if they made it into the GPSIII (which isn't due to deploy for another 6-8 years).
Arcjets and other forms of electric propulsion have indeed proved themselves. They are in regular use on GEO comm satellites. However, whether or not EP makes sense for a given mission depends on many things. One key issue is solar array size. Using EP for an orbit transfer makes sense on a GEO comm bird because they have huge solar arrays that won't be used during the transfer - that spare power can be used to run an ion engine. In the case of GPS it's not clear that the arrays are large enough that you wouldn't need to add extra array area just to support an EP transfer - you'd end up saving propellant but making a more massive spacecraft. EP for stationkeeping is another question. But again, there are many tardeoffs involved.
Satellite structures are still mostly made from aerospace-grade aluminum. There's been some work on using composites, but there are issues with outgassing in a vacuum environment, and ease of manufacture.
There's been little in the way of advancements in spacecraft thermal control technology in the past couple of decades.
Spacecraft antenna and RF technology hasn't changed a whole lot. Especially for precision applications like navigation signalling. Where it has changed, it's been used to add more capability rather than lower mass.
Solar array technology has advanced quite a bit. But again, that just provides scope for higher-power applications (greater comm bandwidth, more processing power).
None of this means that the IIR-M couldn't be smaller and lighter (I personally believe it could be). But doing so requires careful design and assessment of the tradeoffs involved. Just throwing technology at the problem is not the answer. In fact, it's often the cause of the massive cost and schedule overruns that happne in DoD space programs.
The thing is making a satellite slightly lighter doesn't buy you much. You need a substantial drop in mass in order to get down to a cheaper launch vehicle. So given that you're already constrained to launch on a particular LV, why not pack in as much capability as possible? The Air Force in particular has a habot of keeping upgraded satellite designs at the same (or similar) mass as their predecessors, but adding lots of extra functionality.
The other thing to keep in mind is that there are many things that contribute to the total spacecraft mass in addition to the electronics. Not all of them have undergone the same kind of Moore's law reductions in mass (or improvements in capability) that electronics have.
On another note, the picture makes it look like the design hasn't changed much from the original NAVSTAR configuration. I assume that these satellites are merely sharing the same chassis, and have very different internals?
No, they're substantially different designs. Different manufacturers even (Rockwell vs Lockheed). But if you have a spacecraft performing the same mission, odds are it's going to have a similar configuration. The thing that makes them look most similar is the navigation signal antenna array (the "Willy Wonka Chocolate Factory"). Even those are slightly different between the two models. But since they're fundamentally performing the same function, thye look very similar ("form follows function").
Amusingly enough, this story is most likely simply an attempt by the submitter to significantly boost their Google pagerank by getting links to their website inserted into Slashdot. Both this story and the immediately preceding one were submitted by "wellington_map", with the submitter name linking to "http://wellington.iclod.com/". Just yesterday there was a submission by "christchurch_map", which linked to "http://christchurch.iclod.com/". Both websites appear to provide maps and business directories for their respective cities (Wellington, on New Zealand's North Island, and Christchurch on the South Island).
I see. Socialism a "good thing" when we can get someone else to pay for something we want (but that they don't necessarily care about). It's a "bad thing" when we're made to pay for something someone else wants but we don't care about. Is that how it works?
Slashdot Mirror
Surrey Satellite Technology Ltd. is a world leader in spacecraft design. They regularly sell to the US Air Force, and have a number of American companies running scared (it's not uncommon to hear US companies state that they "aim to be the Surrey of the US" at trade shows and conferences).
I don't particularly lke GWB, but the lay-offs have little to do with his "vision for space", and more to do with poor budget management at NASA. AFAIK the primary reason they just laid off at JPL was that they ramped up staffing tremendously during the crunch to get the Spirit and Opportunity rovers finished on time (MER was completed on an incredibly short timescale for a planetary exploration mission - 3 years from start to finish). Unfortunately, the work on MER not only caused a staffing spike, it also went pretty heavily over budget, so several missions were pushed back to free up near-term money to finance MER. Now that MER has wound down there's nothing for a lot of the engineers that were hired during the staffing spike to do: NASA's near-term Mars budget was committed to paying for MER (already done), and the next big projects won't really ramp up for a few years yet.
As for non-supported languages, I haven't seen a plugin for occam or occam-pi yet...
However, in the case of the radiation therapy controller I think it's pretty safe to assume that the folks doing the implementation were extremely careful to ensure that the implementation matched the spec, and, in cases where there was a deviation from the original spec, to incorporate that deviation back into a revised spec and check that the overall system logic was maintained. So yeah, I'm pretty confident the spec exactly decribes the functionality.
In the case of the TCP/IP formalization, the spec was carefully reverse engineered from existing TCP/IP implementations, and extensively tested to ensure that it accurately captured corner-cases. As you would know had you bothered to actually look at the paper in question. So, again, I feel confident that the spec accurately represents the functionality.
On a more philosophical note, I find the notion of "code as spec" repugnant at best. Essentially what you're saying is that "the purpose of the software is what it does". Which has two problems IMHO: (a) by definition there's no such thing as a bug in such software (which isn't really an acceptable notion in the real world), since "bug" is simply another name for "deviation from spec"; and (b) anyone who wants to really understand the behavior of the software has to do the same kind of intense reverse engineering that the folks in the TCP/IP paper did. Personally, I'd rather see real specs that describe what a piece of software is supposed to do, which the implementation is programmed against, and which are revised to reflect any changes that occur during implementation (with the added advantage that these changes can be analyzed to ensure that the don't break the system in some subtle way). I'm not talking about hand-wavy "architecture diagrams" and the like. I'm talking about precise behavior specifications that permit real understanding and analysis.
I realize that you're kidding around. But I wanted to point out that the existence of a "bug" presupposes some kind of "specification" which delineates what the "correct" behavior of a program is. With no definition of correctness (either explicitly on paper, or implicitly in your head) there is no way to recognize "incorrect" behavior, aka bugs.
Try this example, for a radiation therapy machine. You might also try this paper on formal specification of TCP/IP and parts of C.
The problem isn't that specification itself is bad. It's that most "specifications" are written by people who don't know what they're doing, and end up being vague and wishy-washy.
Consider an office building. Would you expect the company that will occupy the office building to write the specs? No. Would they even write the "requirements"? Unlikely. They would hire an architect to determine their requirements, and to spec out a design (blueprints, engineering drawings, materials specifications, etc.) that meets the requirements (probably through several iterations with the customer, showing them different drawings and plans). That spec will get handed off to contractors and engineers, who will then build based on the spec. Note the phrase "based on". In many cases the spec and design will develop in the course of building. (Disclaimer: I have no experience in architecture, but that's my understanding of how the process works)
The same kind of thing happens in spacecraft design. A scientist will come up with an idea for a mission to collect certain science data using some instrument (I'll assume that the instrument is already defined). Does the scientist spec the spacecraft? No. Do they have some preliminary "requirements"? Maybe, of they've worked on a mission before. But those requirements aren't likely to be final - they may not be technically feasible. So, what happens? The scientist gets a spacecraft system engineer to perform preliminary analysis and design work to refine their requirements, and to spec out a high-level design. The spec and design is then iteratively refined and fleshed-out by a team of engineers, and finally built and tested. (Disclaimer: I have experience on spacecraft development projects. This is exactly how it works. Is it a cut-and-dried, clinical process? No. Nothing involving design is. But the essentials are pretty much the way I just described.
As an aside: I think that XP and agile development do a nice job of the iterative part of the design process. A really nice job. And iteration is critical to giving the customer what they want. I just don't buy into the myth that upfront design is a bad idea. Upfront specification design, done well, is invaluable for figuring out what to code, and eliminating errors in understanding early in the process. That's particularly crucial for properties which are hard to "refactor" in as you go - stuff like real-time performance, or system-level security.
Really? And yet these guys seem to do a pretty good job of consistently delivering on-time, on-budget, and with an order of magnitude less defects than the rest of the industry. Is their methodology "guaranteed"? Of course not. Neither are development projects in other engineering domains. There's always risk involved in a new development. But the approach used by Praxis (careful requirements elicitation; risk-driven planning; formal specification where necessary; design by contract; etc. etc.) has been consistently demonstrated to increase the likelihood that the product you get is the product you wanted.
There is nothing inherent in software that makes it impossible to engineer. In fact, in many ways it's easier to engineer - you don't have to account for material failures, interactions between physical laws, or any of the million-and-one other things that make designing a physical product hard. All you need to do is develop a logical construct. Software development will only remain "an art" if the practitioners of software development continue to treat it as one. And that will only be tenable for as long as people are willing to accept software that is buggy and often malfunctions. The reason that every other engineering discipline emerged was that regular failure of the products in that domain could not be tolerated. It will be no different with software.
Huh? There's no way to stop that now. If you make an inaccurate map, then its not a copy of the original map, is it? So copyright wouldn't necessarily apply (depending on how the map was generated). It'd probably be better to deal with your concerns about accuracy under trademark law - only genuine maps could carry an MTA trademark.
Interestingly enough, this kind of thing is apparently exactly what the 9/11 group used. And, as the OP quote correctly pointed out, it's the sort of thing that works regardless of encryption.
And yet I've heard several Christian groups claim that the hurricane was a direct result of God's anger about (one or more of):
Ok, maybe not that last one. But I'm pretty sure I've heard the others, as well as several others I can't remember right now. I guess all the Christians in the hurricane zone were just collateral damage...
Apparently, KOffice supports Open Document. And, according to this Abiword and Gnumeric soon will. Presumably other minority (i.e. no MS) products will jump on the bandwagon as well, once it becomes obvious that Open Document has a decent mindshare.
And yes, I miss New Zealand too :-(
The SSME may be the "best" using your murky figure of merit. But the SSME is, from what I have heard, a nightmare when it comes to operability and reusability. Mostly due to the excessive complexity that you alluded to. What kind of "reusable" engine requires a complete strip-down, overhaul, and burn-in between each flight? I'm trying to imagine how well commercial aviation would work if every turbofan required that kind of care and maintenance, and frankly, the picture isn't pretty.
As I recall, EngSoc was so good at putting together a decent beer-fest that a good chunk (~30% IIRC) of its members were actually Law and Arts students looking for a good time...
As others have said, the problem is not languages. However, rather than offering vague suggestions about "motivation" or "picking a goal", I have some concrete advice: try taking a look at How to Design Programs. It's textbook by some of the best minds in CS education, and its goal is to teach you how to break down and structure problems, and create programs which solve those problems - not just to teach you a language. It'll teach you to think like a programmer. Which, quite frankly, sounds like what you need. Better yet, it's freely available online (so you can easily give it a testdrive), although I'd recommend picking up the print version if you decide you like what they have to say (for the sake of readability if nothing else).
These reasons apply to US government space programs. For an alternative approach, you might look at Surrey Satellite Technologies Ltd in the UK. They build and launch things quickly, have a well-defined strategy for integrating new technologies into spacecraft in a low-risk fashion and getting rapid flight-test information on them, make good use of the technologies appropriate to a mission instead of getting wedded to any one tech, and are extremely good at nailing down their requirements and building only what is needed. IMHO they are the best, and most innovative satellite manufacturer in the world today (and no, I don't work for them - although I'd do so in a heartbeat if I ever moved to the UK).
To being things slighly back on-topic, it's probably worth noting that SSTL has the contract to develop a testbed satellite for the Galileo system (the European competitor to GPS).
None of this means that the IIR-M couldn't be smaller and lighter (I personally believe it could be). But doing so requires careful design and assessment of the tradeoffs involved. Just throwing technology at the problem is not the answer. In fact, it's often the cause of the massive cost and schedule overruns that happne in DoD space programs.
You mean like a microkernel system? I bet Andrew Tanenbaum would just love to see Linux move to that model ;-)
The other thing to keep in mind is that there are many things that contribute to the total spacecraft mass in addition to the electronics. Not all of them have undergone the same kind of Moore's law reductions in mass (or improvements in capability) that electronics have.
No, they're substantially different designs. Different manufacturers even (Rockwell vs Lockheed). But if you have a spacecraft performing the same mission, odds are it's going to have a similar configuration. The thing that makes them look most similar is the navigation signal antenna array (the "Willy Wonka Chocolate Factory"). Even those are slightly different between the two models. But since they're fundamentally performing the same function, thye look very similar ("form follows function").
Amusingly enough, this story is most likely simply an attempt by the submitter to significantly boost their Google pagerank by getting links to their website inserted into Slashdot. Both this story and the immediately preceding one were submitted by "wellington_map", with the submitter name linking to "http://wellington.iclod.com/". Just yesterday there was a submission by "christchurch_map", which linked to "http://christchurch.iclod.com/". Both websites appear to provide maps and business directories for their respective cities (Wellington, on New Zealand's North Island, and Christchurch on the South Island).
"The Wild Wild West" made the list...
I see. Socialism a "good thing" when we can get someone else to pay for something we want (but that they don't necessarily care about). It's a "bad thing" when we're made to pay for something someone else wants but we don't care about. Is that how it works?