I have similar experiences of things that weren't as redundant as claimed. One other point to consider is that you will need to set up a PROCESS to check this redundancy at least once per year. Otherwise some maintenance will occur which "optimises the service" - reduces cost for the operator by rerouting on a cheaper connection. This will very likely end up in the same duct, if not on the same power and router kit as the primary. First you'll know is when the digging machine down the street takes the whole site out.
Another concern - for those of us in Toronto last year when the lights went out - is the frequency with which UPS fail. Again - test regularly, rehearse regularly...
Made by ESA (The European Space Agency); Due for release on Christmas day IIRC; Will enter Titan's atmosphere about 21 days later; Will live for less than 4 hours while (hopefully) parachuting down to the surface; Should give us "ground truth" to compare with all the Cassini remote sensing.
On the plus side Huygens was engineered very differently to Beagle, and has a lot more redundancy. Also the atmosphere of Titan is a lot denser than Mars. On the minus side Huygens has been in deep space a lot longer (launched well before Beagle), and there are uncertainties about the atmosphere of Titan. One common factor is that Beagle did inherit some code (or at least code design) from Huygens. Unfortunately neither Huygens nor Beagle designs support telemetry during entry phase. The USA learnt this lesson from the Galileo probe to Jupiter and managed to get SOME telemetry for Spirit and Opportunity
Sad not to see...
Modern Art
Seastrike
DBM
Stars!
Personally if a list like this introduces me to 1 or 2 previously unknown good games - then I for one will value it!
I have written software that is on-board spacecraft at present.
A large part of the failures are to do with Mission Frequency. I did an analysis of all Space Science missions. Historically the original missions had 50% success rate, then the engineers learnt from their mistakes and the rate went up to more like 80%, but as missions got more expensive and money tighter the rate of missions went down, and we returned to the state where everyone actually DOING THE WORK (the guys coding and bending metal and the like) were on their first mission again. The rate is now back to 50%. Of course science missions are - by their nature - unique. That means that software re-use is more difficult, and the environment (SEU etc) and the hard-real time nature also mean that coding and testing require special skills. But part of the problem is that you cannot sustain a team, or a software product on one mission every 10 years (which is what a module like IR astonomy, outer planet imaging or planetary geology gets from any one team). Keeping teams together is impossible, career progression is impossible, and money is tigher each time round. In the end I had to leave the industry - with great sadness. I'd like to contribute to the human race's exploration, but my family have needs as well.
Slashdot Mirror
I have similar experiences of things that weren't as redundant as claimed. One other point to consider is that you will need to set up a PROCESS to check this redundancy at least once per year. Otherwise some maintenance will occur which "optimises the service" - reduces cost for the operator by rerouting on a cheaper connection. This will very likely end up in the same duct, if not on the same power and router kit as the primary. First you'll know is when the digging machine down the street takes the whole site out.
Another concern - for those of us in Toronto last year when the lights went out - is the frequency with which UPS fail. Again - test regularly, rehearse regularly...
The Huygens probe is:
Made by ESA (The European Space Agency);
Due for release on Christmas day IIRC;
Will enter Titan's atmosphere about 21 days later;
Will live for less than 4 hours while (hopefully) parachuting down to the surface;
Should give us "ground truth" to compare with all the Cassini remote sensing.
I recommend "the soul of a new machine" for anyone who thinks this is a new phenomenon
On the plus side Huygens was engineered very differently to Beagle, and has a lot more redundancy. Also the atmosphere of Titan is a lot denser than Mars. On the minus side Huygens has been in deep space a lot longer (launched well before Beagle), and there are uncertainties about the atmosphere of Titan. One common factor is that Beagle did inherit some code (or at least code design) from Huygens. Unfortunately neither Huygens nor Beagle designs support telemetry during entry phase. The USA learnt this lesson from the Galileo probe to Jupiter and managed to get SOME telemetry for Spirit and Opportunity
NASA's Cassini orbiter is carrying ESA's Huygens probe as far as Saturn, and then releasing it to drop down through Titan's atmosphere.
Huygens should give us the "ground truth" to help interpretation of all the remote sensing.
Not long now - the code is nearly 10 years old...
Regards
(PM - Huygens on-board software)
Sad not to see... Modern Art Seastrike DBM Stars! Personally if a list like this introduces me to 1 or 2 previously unknown good games - then I for one will value it!
It's important - but not the whole story. My stuff is in Ada 83 and Assembler, and memory is measured in K not M....
I have written software that is on-board spacecraft at present.
A large part of the failures are to do with Mission Frequency. I did an analysis of all Space Science missions. Historically the original missions had 50% success rate, then the engineers learnt from their mistakes and the rate went up to more like 80%, but as missions got more expensive and money tighter the rate of missions went down, and we returned to the state where everyone actually DOING THE WORK (the guys coding and bending metal and the like) were on their first mission again. The rate is now back to 50%. Of course science missions are - by their nature - unique. That means that software re-use is more difficult, and the environment (SEU etc) and the hard-real time nature also mean that coding and testing require special skills. But part of the problem is that you cannot sustain a team, or a software product on one mission every 10 years (which is what a module like IR astonomy, outer planet imaging or planetary geology gets from any one team). Keeping teams together is impossible, career progression is impossible, and money is tigher each time round. In the end I had to leave the industry - with great sadness. I'd like to contribute to the human race's exploration, but my family have needs as well.