A Space & astronomy forum. SpaceBanter.com

Go Back   Home » SpaceBanter.com forum » Space Science » History
Site Map Home Authors List Search Today's Posts Mark Forums Read Web Partners

PBS's "Nova" and MER



 
 
Thread Tools Display Modes
  #22  
Old January 6th 04, 04:53 AM
Matthew Jessick
external usenet poster
 
Posts: n/a
Default PBS's "Nova" and MER



Pat Flannery wrote:
About the time they started talking about sending the finished landing
software to the spacecraft _after_ they launched, a feeling of deja-vu
hit me;


Perhaps because this isn't all that uncommon for planetary spacecraft.
I believe Magellan did the same thing for one.

- Matt

  #23  
Old January 6th 04, 05:09 AM
Scott Hedrick
external usenet poster
 
Posts: n/a
Default PBS's "Nova" and MER

"Hallerb" wrote in message
...
of course we both have
dogs.


Don't talk about your "gamily" that way!
--
If you have had problems with Illinois Student Assistance Commission (ISAC),
please contact shredder at bellsouth dot net. There may be a class-action
lawsuit
in the works.


  #24  
Old January 6th 04, 01:20 PM
Diane Wilson
external usenet poster
 
Posts: n/a
Default PBS's "Nova" and MER

In article , says...


Henry Spencer wrote:
There's nothing particularly wrong with that, if you think of software
uploads as routine practice rather than as a dire emergency measure.


What happens if you launch them, and then run into some
software-spacecraft compatibility problem that can't be fixed before the
time that the software is needed, due to a compatibility problem that
can't be fixed in-flight; but could have been found via ground testing
of the systems and software on the ground prior to launch? If that had
happened on the two MER flights they would have had no way to get them
ready for landing.


You build a fault-tolerant design that lets the old software keep
running while the new software gets loaded and tested onboard.
You have a separate control, not owned by the software in question,
which can activate either software load, so you have a backout
even if the new software is a steaming heap straight from the
catbox. The two sides can talk to each other and transfer data,
so nothing gets lost in the process. When you're satisfied with
a new load, the alternate side can be synched up to run the same
software with the same data, in lock-step, so that you have a hot
backup incase of a hard failure. And the system bus can be
switched to either processor.

You build software that is self-rebooting, so that
the system restarts itself automatically when there's a failure.
You build a patching system that can apply updates to running
software without taking it down and *without* physically
replacing the old software, so that the patch can be backed
out (again without a restart) if necessary.

None of this is new; fault-tolerance concepts and continuous
operation have been around for a long time. A lot of our
key infrastructure items (think about phone systems, power,
etc.) run this way.

Henry's right; you make it routine, which means it's part of
the design specs and part of the design process. I work for
a major telephone switch manufacturer, and that's the way it
gets done. Patching capability is a check-off point on design,
and an absolute requirement for accepting any fix.

Diane
  #25  
Old January 6th 04, 01:48 PM
bob
external usenet poster
 
Posts: n/a
Default PBS's "Nova" and MER


I don't think it was this kind of software. Software that directly
interfaces with the hardware (like an operating system on your PC) is one
thing, higher level software (that interprets images and makes onboard
decisions etc) is another.

my understanding was that they had the basic hardware interface system, but
the higher level autonomy software was still being developed. I am not sure
it would have been possible for them to to go with the basic hardware
interface undone. Higher level software is much more flexible and can and
will be changed even as the mission is on the planet.

Basically the went up with a loaded beta OS and no programs. In flight they
loaded OS service packs and programs they wanted to run. if the program did
not work with the OS, and therefore the hardware, they just re-wrote the
program.

The comfort level with hardware/software interfaces is such that this was
possible.


In article , says...

What happens if you launch them, and then run into some
software-spacecraft compatibility problem that can't be fixed before the
time that the software is needed, due to a compatibility problem that
can't be fixed in-flight; but could have been found via ground testing
of the systems and software on the ground prior to launch? If that had
happened on the two MER flights they would have had no way to get them
ready for landing.



  #26  
Old January 6th 04, 02:29 PM
JimO
external usenet poster
 
Posts: n/a
Default PBS's "Nova" and MER


"Pat Flannery" wrote in message
...
The only big-budget long-span program semi-flop we have had was Galileo;
and its problems were as much due to a hurried redesign of its launch
method and trajectory as anything else, and it still got a lot of its
job done at Jupiter.
In comparison to this, our lower-cost fast timeline missions are running
around 50% as to success rate.


While agreeing with your main point, I also nominate MO as an expensive
project that wasted money by failing.


  #27  
Old January 6th 04, 02:32 PM
JimO
external usenet poster
 
Posts: n/a
Default PBS's "Nova" and MER


"Diane Wilson" wrote in ...

Diane --

Pearls of wisdom -- heck, an entire necklace of such pearls -- such as yours
is one of the highlights of these discussions. Thanks for sharing your
experiences and insights. It was a keeper!

jim



  #28  
Old January 6th 04, 03:28 PM
Diane Wilson
external usenet poster
 
Posts: n/a
Default PBS's "Nova" and MER

In article m,
com says...

I don't think it was this kind of software. Software that directly
interfaces with the hardware (like an operating system on your PC) is one
thing, higher level software (that interprets images and makes onboard
decisions etc) is another.


For embedded systems, or realtime systems, or systems with
special hardware -- all of which apply in this case -- the
boundaries can be a lot less distinct than in commercial
products such as PC applications.

my understanding was that they had the basic hardware interface system, but
the higher level autonomy software was still being developed. I am not sure
it would have been possible for them to to go with the basic hardware
interface undone. Higher level software is much more flexible and can and
will be changed even as the mission is on the planet.


I'll defer (of course) to direct knowledge of the rover
software, but nothing about what you're saying is
incompatible with a fault-tolerant hardware or software
structure. The operating system, and especially its
loader, need to be designed from the beginning to support
real-time, nondisruptive changes, but that's not a
cutting-edge concept; it's been done for decades now.
The compiler and run-time environment also need to be
tailored to the loading and patching requirements, so
compilers and languages do need to be selected carefully.

Even the programming language may need special features.
It should support exception handling, certainly. It also
makes things easier if you can identify a particular
procedure in each module that needs to get run on every
restart. The operating system should provide a way
for these "restart" entry points to get run by command.
The system should also detect process death, and provide
for automatic restart of processes, which would include
running associated restart procedures.

None of this precludes adding applications after launch.
It just means that the applications have to be designed
for this kind of environment.

Basically the went up with a loaded beta OS and no programs. In flight they
loaded OS service packs and programs they wanted to run. if the program did
not work with the OS, and therefore the hardware, they just re-wrote the
program.


In a well-managed software project, a beta OS should be reasonably
stable. In any case, what we're talking about is the mechanics
of *how* you apply service to a remote, real-time, fault-tolerant,
continuous-operation device.

The comfort level with hardware/software interfaces is such that this was
possible.


From my experience, they'd better be comfortable with it!

Diane

In article ,
says...

What happens if you launch them, and then run into some
software-spacecraft compatibility problem that can't be fixed before the
time that the software is needed, due to a compatibility problem that
can't be fixed in-flight; but could have been found via ground testing
of the systems and software on the ground prior to launch? If that had
happened on the two MER flights they would have had no way to get them
ready for landing.




  #29  
Old January 6th 04, 06:05 PM
Henry Spencer
external usenet poster
 
Posts: n/a
Default PBS's "Nova" and MER

In article ,
Brett Buck wrote:
... The technology and missions are so unforgiving that even tiny
problems have to be addressed, and beaten to death. That takes time and
money - there's no getting around it.


Actually, it's perfectly reasonable to simply accept a modest amount of
risk... especially since you are *always* doing that anyway, because you
can never anticipate all the problems. (At no time did Apollo planning
ever consider the possibility of losing all oxygen and all electrical
power in the CSM; studies of the "LM lifeboat" were confined to using the
LM *engine* to cover for a CSM propulsion failure.) A sense of proportion
is needed; you can waste unlimited amounts of money on unlikely what-ifs.

The need for *adequate* funding does not imply a need for NASA-megaproject
funding levels. (However, it *does* mean that if you don't have
NASA-megaproject funding levels, you can't use the NASA-megaproject
management style.)

...You are correct that cheaping out or funding or schedule, or
simply ignoring this essential fact, is exactly why there are so many
failures in all sorts of aerospace projects.


Nonsense. There have been numerous failures in aerospace projects which
had ample funding and schedule. The evidence is strong that the bulk of
the failures are simply independent of cost and schedule, at least within
broad limits. For every Mars Climate Orbiter there's a Mars Observer.

...Those "dinosaur" aerospace companies actually know some things
about how to conduct projects that lead to their "exorbitant" bids.


Yeah: they know how to run projects so as to maximize effort -- as
opposed to results -- because that's what they get paid for. When Max
Faget, who had more than a little experience dealing with the dinosaurs,
was trying to get his private-venture Industrial Space Facility off the
ground, his major ground rule when looking for an industrial partner was
"no aerospace companies".

...Most of the proposed budgets for
the "stunts" like Roton aren't enough to cover even the contingencies
that will arise, much less the entire program. That's why they fail.


Name three private launcher projects that have failed by overrunning their
budget estimates.

(Hint: to overrun its estimated budget, such a project would first have
to *have* funding somewhere close to the estimated amount.)
--
MOST launched 30 June; science observations running | Henry Spencer
since Oct; first surprises seen; papers pending. |
  #30  
Old January 6th 04, 07:09 PM
Derek Lyons
external usenet poster
 
Posts: n/a
Default PBS's "Nova" and MER

Scott Ferrin wrote:

Even if that is the case (it's been a while since I saw the show about
the construction of the Truman but I'd have sworn they were outdoors
when they bolted the sections together) that is still a far cry from
"the levelest and flattest floor in the world".


Sorry, you are *WRONG*. Don't confuse the assembly of the shaft
segments (which is done on the pier) with the alignment of the shaft
segments and the alignment of the shaft itself, which is done once
installation is complete.

D.
--
The STS-107 Columbia Loss FAQ can be found
at the following URLs:

Text-Only Version:
http://www.io.com/~o_m/columbia_loss_faq.html

Enhanced HTML Version:
http://www.io.com/~o_m/columbia_loss_faq_x.html

Corrections, comments, and additions should be
e-mailed to , as well as posted to
sci.space.history and sci.space.shuttle for
discussion.
 




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 11:57 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.