|
|
|
Thread Tools | Display Modes |
#11
|
|||
|
|||
On Mon, 17 Jan 2005 06:05:14 GMT, "David Nakamoto"
If you're tired of mistakes like this, as I was and am, petition your representatives to fund the space program right. David, I don't think simply throwing more money at the problem is the answer. What is needed, IMO, is to use the funds we have to actually test the hardware/software as a system and quit generating mountains of useless requirements and MIL-SPEC-2167A documents during software development. I would bet you that 50% of the money spent on the software development went into paperwork and probably less than 20% in testing. Generate enough paperwork to reasonably document and then concentrate your money on a engineering test program whereby prototypes can be used to test entire systems. Yes, that is expensive, but it would be money better spent than on reams of paper. Engineering is most successful when it is an iterative process where real-world testing is part of the iteration. --- Michael McCulloch |
#12
|
|||
|
|||
In article uAIGd.5021$HT6.4775@trnddc04,
"David Nakamoto" wrote: True, but in this case, and this is from a former JPLer, it seems inexcusable, since they should at least triple check the software and/or command sequence in order to ferret out these and other bugs. Same thing happened with the Phobos mission many years ago if memory serves, but in that case we lost the link to the spacecraft forever. But with budget cuts, such things are going to be more common. And the need to check, check, and check again is just one of the reason why you CANNOT run a space exploration program like you would a MacDonalds, or even a big defense contractor. You cannot afford mistakes, period. Therefore you need to invest HEAVILY in quality control and safety inspection. THEREFORE you need to spend the money. This simple equation is totally lost, however, on the bean-counting politicians holding the purse strings, and also it seems on at least some of the people posting to this newsgroup. As a former Caltecher now in the commercial computer business, that whole philosophy is wrong. 1. People _always_ make mistakes. Adding more checkers often makes the problem _worse_, because each checker starts to assume that some other checker will find any problems, and they all get slack. Checking is no substitute for realistic testing. Note that automated checks and testing programs can also be flawed, which brings up point 2: 2. One-off programs which cannot be allowed to fail return fewer results than a series of multiple smaller programs, some of which will certainly fail. As Henry Spencer first described it, big one-off projects are examples of "Wiley Coyote" engineering in which there is no opportunity to find mistakes, learn from them, and correct them in the next iteration. |
#13
|
|||
|
|||
"richard schumacher" wrote in message ... In article , "md" not given to avoid spam wrote: "Tim Killian" wrote in message ... The operative word is "complex" I would ask why the software for the data transfer wasn't simplified. But ESA _only_ had seven years to run simulations and debug the encounter code ;-) really? was ESA able to upload bugfixes during flight? A $250MM F-22 crashed last month because the flight software locked up as the pilot rotated on takeoff. Fortunately, the pilot had a couple of seconds before impact and was able to eject. It's a prime example of the terrible state of software tools and processes used in modern systems. or: it shows how hard programming can be. _Everything_ is hard, which is why realistic testing is important. A few bytes of dummy data sent from Huygens to Cassini after separation would have immediately shown the problem. The bug was in software in Cassini (but which had been specified by the ESA) and could easily have been fixed up to the last moment, if only the problem had been known. I would not know, I do not have access to the sourcecode or to the testplans. |
#14
|
|||
|
|||
Ken wrote:
As it turned out, Cassini never listened to channel A because of a software commanding error. The receiver on the orbiter was never commanded to turn on, according to officials with the European Space Agency. I have the highest regard for the engineers who have worked on this complex system. If you read through the CAS-HUY status reports, one gets a feeling of very good QA efforts for the command & control packages. This is such a unfortunate human oversight. From personal experience, every single instruction should be tested but cost/time constraints doesn't always allow for that. A high level walk-through should have caught this oversight, but the saying goes : 'To err is human.' We should be grateful for the data received so far and the data that is yet to come from Cassini for the next 3 years. This might be the last mission to Saturn for a very long time. |
|
Thread Tools | |
Display Modes | |
|
|