A Space & astronomy forum. SpaceBanter.com

Go Back   Home » SpaceBanter.com forum » Astronomy and Astrophysics » Amateur Astronomy
Site Map Home Authors List Search Today's Posts Mark Forums Read Web Partners

Huygens A-channel images will never be seen??



 
 
Thread Tools Display Modes
  #11  
Old January 17th 05, 03:47 PM
Michael McCulloch
external usenet poster
 
Posts: n/a
Default

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  
Old January 17th 05, 03:51 PM
richard schumacher
external usenet poster
 
Posts: n/a
Default

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  
Old January 17th 05, 07:33 PM
md
external usenet poster
 
Posts: n/a
Default


"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  
Old January 18th 05, 11:31 AM
Victor
external usenet poster
 
Posts: n/a
Default

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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 04:50 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 SpaceBanter.com.
The comments are property of their posters.