ok, here's what i managed to produce in the last hour...feel free to edit
-sarah

i attatched the word document, but if you can't access that, here's the 
plain text of it:

The Mars Rover project can most easily be split into two components: 
communication protocol and mission distribution and execution. The problems 
associated with communication protocol are relatively straightforward and 
include message authentication and error detection and correction. Mission 
distribution and execution encompasses a wider range of issues; apart from 
a basic distribution algorithm, we must be able to deal with rover failure, 
unreliable sensors, amendments, and the scheduling of data upload.

             Communication protocol further breaks down into two 
categories: communication on Mars (between two rovers or between the rovers 
and central command) and communication to Earth (from central command). 
Communication to Earth need only worry about transmission errors and 
messages that are not received. The first issue can be dealt with by 
including a hash with each message sent, so errors can be detected.  Also, 
transmission errors can be reduced using error correcting codes.  The 
second issue is addressed by verification messages. Since it takes so long 
to communicate between Earth and Mars, the central command cannot wait for 
verification messages between packets, but it can resend a packet if its 
verification message is not received after a certain period of time. The 
message hashes can also be implemented in communications between the rovers 
and the central command. Additionally, message authentication on Mars, to 
prevent confusion between NASA and Poodle rovers, can be implemented by 
signing each message with a shared secret key known to all rovers and the 
command center. Since there are no malicious entities on Mars, no 
encryption or sealing is needed. Naming is trivial, because each of the 
fifty rovers can be programmed with a unique number. Finally, in order to 
determine whether there are other NASA devices within communication 
distance, the rover or command center can broadcast a predefined "who's 
here?" message. Any device which hears this message will broadcast a 
message containing its identifier.

             To help ensure that experiment data makes its way back to the 
central computer, whenever two rovers come into transmission range, they 
will exchange their current mission data.  Then, that data will have two 
ways to make it back to base.  Of course, they will only store the other 
rovers data if they do not yet have data for that mission, and they have 
extra room to store the data.

             The second major aspect of the design is the way in which 
missions are distributed to and executed by the rovers.  For the basic 
algorithm to decide what mission to send out next, we will prioritize 
missions by how long they are estimated to take.  This greedy algorithm is 
only appropriate based on the assumption that all missions are equally 
important to the scientists.  Given that the scientists provide us with no 
ranking for missions, this assumption seems valid.

             For scattered or scattered-cluster missions, each clustered 
portion of the mission will be treated separately.  A rover will be sent 
out to take care of the first cluster, and when data returns for that 
portion the second part of the mission will be added to the queue of 
missions waiting to be sent out.

             Sensor failure, we have been told, is also an issue that our 
design faces.  The rover, when taking measurements, should take enough so 
that the probability that its reading is wrong is less than 5%.  For 
example, with the thermometer with 7%, you would need 2 matching readings 
to have a good probability that you were right.  So, take 2 readings, and 
if they match, good, and if they dont match, try again until they 
do.  Granted, this could put you in an infinite loop if that sensor is bad, 
but we are assuming in this world that if the sensor dies, the whole rover 
dies.  Therefore, this should not be a problem.

             When the central command receives amendments to experiments, 
the mission must be updated.  The cases where the mission has already been 
performed or has not been sent out at all are trivial.  The mission as a 
whole is amended, and placed back into the mission queue.  However, if some 
rover a is currently out performing the mission, the situation is slightly 
more complicated.  In this case, we will send another rover to try and find 
rover a and give it the updated mission description, so that rover a can 
then perform the revised versions of the experiments.  If rover b does not 
find a immediately, it will return to base, and the central computer will 
just treat the revision as one for a mission that has already been 
completed.  Of course, it will have to wait until rover a returns before 
adding the rest of the mission to the queue.

             A potential problem that has not yet been addressed is rover 
failure.  The central computer will calculate a reasonable timeout interval 
based on the estimated time to complete the mission.  If the rover does not 
return before the timeout time, it will be presumed dead.  In this case, 
the mission that the rover did not return from will be added to the mission 
queue.  If the rover comes back after having been presumed dead, treat this 
as an amendment to cancel the repeated mission.

             The central computer will keep track of missions and their 
data in a mission table.  This table will contain the mission id, its 
revision number, and the data, if any, for that mission.  Likewise, there 
will be a table for the rovers that contains the rover id, whether it is 
presumed dead or alive, what its current mission is, and the time at which 
it is expected to return by.

             This design should be one in which amendments, sensor and 
rover failure, and poor communications are dealt with in a reasonable 
manner, and in a way such that valid scientific data will still be 
collected.  Some of the design choices we have made depend on assumptions 
that are valid in the world as this project has been presented to us, but 
which would not be valid in the real world.  However, we have not been told 
to deal with the real world, so this should not be a big issue.