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.