|
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
Huygens A-channel images will never be seen??
from
http://www.spaceflightnow.com/cassin...15science.html 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. "We should remember we're human and we should learn lessons, so I will institute an ESA inquiry on how the command came to be missing," David Southwood, director of science for the European Space Agency, told reporters today. "I'm not going to say any more about that, I'm not going to speculate (about blame)." In an obvious reference to NASA and earlier news reports, he did say "there have been some erroneous messages implicating one of the other space agencies involved. No. It's an ESA responsibility." According to published reports, an ESA official said earlier that the missing command was part of a software load developed by ESA for the Huygens mission and that it was executed by Cassini as delivered. "There isn't any doubt that the command was missing," Southwood said today. "But I'm not going to say any more because the point of an inquiry is to find out. We will certainly have NASA representation on the inquiry, but I don't want to make a big thing about it." |
#2
|
|||
|
|||
On Sat, 15 Jan 2005 19:44:34 -0600, "Ken" wrote:
from http://www.spaceflightnow.com/cassin...15science.html 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. That's a inexcusable error. Sure, anyone can make a mistake, but with the sums of money and man-hours spent on these missions is it not resonable to hold to a higher standard? Unknown conditions that cause unforeseen effects -- ok. But a software error? C'mon. --- Michael McCulloch |
#3
|
|||
|
|||
"Michael McCulloch" wrote in message news On Sat, 15 Jan 2005 19:44:34 -0600, "Ken" wrote: from http://www.spaceflightnow.com/cassin...15science.html 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. That's a inexcusable error. Sure, anyone can make a mistake, but with the sums of money and man-hours spent on these missions is it not resonable to hold to a higher standard? Unknown conditions that cause unforeseen effects -- ok. But a software error? C'mon. why is it so unthinkable to software fails or contains an error? ever done a complex software creation project? -- md 10" LX200GPS-SMT ETX105 www.xs4all.nl/~martlian |
#4
|
|||
|
|||
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 ;-) 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. md wrote: "Michael McCulloch" wrote in message news On Sat, 15 Jan 2005 19:44:34 -0600, "Ken" wrote: from http://www.spaceflightnow.com/cassin...15science.html 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. That's a inexcusable error. Sure, anyone can make a mistake, but with the sums of money and man-hours spent on these missions is it not resonable to hold to a higher standard? Unknown conditions that cause unforeseen effects -- ok. But a software error? C'mon. why is it so unthinkable to software fails or contains an error? ever done a complex software creation project? |
#5
|
|||
|
|||
"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. -- md 10" LX200GPS-SMT ETX105 www.xs4all.nl/~martlian |
#6
|
|||
|
|||
On Sun, 16 Jan 2005 23:46:25 +0100, "md" not given to avoid spam
wrote: why is it so unthinkable to software fails or contains an error? ever done a complex software creation project? Yes, it is my daily job. With the resources they had there is no excuse in my opinion if the error really turns out to be omission of a command for Cassini to listen. In the past I have been through the US government's idea of software development (is the ESA similar?). The philosophy is basically to produce a mountain of useless paperwork and rely on the "system" to make things work. There's no replacement for individual responsibility/ownership and exhaustive testing. --- Michael McCulloch |
#7
|
|||
|
|||
well dont they ....ing test it!?
merci beau****s. Ken wrote: from http://www.spaceflightnow.com/cassin...15science.html 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. "We should remember we're human and we should learn lessons, so I will institute an ESA inquiry on how the command came to be missing," David Southwood, director of science for the European Space Agency, told reporters today. "I'm not going to say any more about that, I'm not going to speculate (about blame)." In an obvious reference to NASA and earlier news reports, he did say "there have been some erroneous messages implicating one of the other space agencies involved. No. It's an ESA responsibility." According to published reports, an ESA official said earlier that the missing command was part of a software load developed by ESA for the Huygens mission and that it was executed by Cassini as delivered. "There isn't any doubt that the command was missing," Southwood said today. "But I'm not going to say any more because the point of an inquiry is to find out. We will certainly have NASA representation on the inquiry, but I don't want to make a big thing about it." |
#8
|
|||
|
|||
No. I just use the stuff. Dont you? (to test it?)
md wrote: "Michael McCulloch" wrote in message news On Sat, 15 Jan 2005 19:44:34 -0600, "Ken" wrote: from http://www.spaceflightnow.com/cassin...15science.html 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. That's a inexcusable error. Sure, anyone can make a mistake, but with the sums of money and man-hours spent on these missions is it not resonable to hold to a higher standard? Unknown conditions that cause unforeseen effects -- ok. But a software error? C'mon. why is it so unthinkable to software fails or contains an error? ever done a complex software creation project? -- md 10" LX200GPS-SMT ETX105 www.xs4all.nl/~martlian |
#9
|
|||
|
|||
md 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? Yes. And they did so to try and overcome an essentially fundamental *hardware* design error that meant that the telemetry link between Huygens and Cassini would not have been able to cope with the large Doppler shift from their 21000km/hour relative motion. See for example: http://www.spacedaily.com/news/cassini-01g1.html It had to be made signifcantly *more* complex and uploaded whilst the mission was in progress to make the science telemetry stand any chance of working. What is sad is that the outcome after applying the fix seems to have been similar to the original expectation (loss of half the data). However, we should still celebrate that it returned real scientific data from such a remote and hostile location. 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. As a software specialist I have to concede that the state of commercial software is still pretty lamentable. Microsoft have copious buffer overrun vulnerabilities in just about everything they have ever made A cynic would say that in software development we are still at the stage of mediaeval cathedral builders. After the event if it is still standing five years on we can say it was a good design, but there are far too many software projects delivered DOA. Consumer software has become gothic - bloated with complex twiddly bits and immense "feature" lists for salemen that convey no useful benefits to the purchaser. But the embedded realtime code in aerospace, automotive, mission and safety critical kit is generally much much better. But nothing is ever perfect. Possibly the sole exception is Donald Kunth's Tex program. Ultimately you are up against human error. The computer will follow it's instructions to the letter. It cares nothing about whether they make any sense. Fence post errors with boolean values are extremely disastrous (and not as rare as they should be). Regards, Martin Brown |
#10
|
|||
|
|||
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. |
|
Thread Tools | |
Display Modes | |
|
|