M.I.T. DEPARTMENT OF EECS

6.033 - Computer System Engineering (Spring 2004)

Design Project 2 - Version History


4/25/04 (1:31 PM):

NASA has made an after-the-contract-was-awarded change in specifications to address complaints from their mission planners, who were concerned that they would have to keep track of the number of rovers that were currently active and limit the size of the mission queue accordingly. Instead, NASA has changed the specification such that only a fixed number of missions (25) will be available at a time; we have updated the design project to reflect this change. The relevant section now reads:
NASA will continue uploading missions as long as there are still unfailed rovers.  At any given time, however, there will be about 25 missions either waiting to be distributed or being executed.
[Link to relevant section of DP.]


4/12/04 (8:27 PM):

The communication subsystem was changed. There is a now a 1500-byte maximum packet size per packet; the relevant section of the design project now reads:
Messages may be up to 1500 bytes in length.  You will need to design a protocol to segment experimental results into packets, and to properly deliver results despite loss. You may use a TCP-like reliable protocol if you wish; be sure to state why such a protocol is or is not appropriate for your design.
[Link to relevant section of DP.]


4/9/04 (5:15 PM):

MTTF was expanded to "mean time to failure".

4/9/04: 

The section on sensor failures was replaced again. The new version is:
Many of the experiments involve sensors that measure, scan, survey, or otherwise acquire information about the environment.  For each sensor, NASA provides a range and accuracy specification, and a probability of sensor failure.  Thus the specification for a thermometer might be:
  range: -55C to +225C
  accuracy: +/- 1.5C
  failure probability: 0.07 per reading

The faults that cause sensor failures are transient, and when they occur the sensor fails by producing a random output value, selected uniformly from that sensor's specified range.  When a sensor failure occurs, there is no direct warning that the sensor result is bad.  The rover continues to function normally, and if it repeats the experiment the probability of failure on next use of the same sensor is completely independent of what happened on the previous use. 

Even complex sensors such as cameras conform to this model.  A camera, for example, might, in addition to the data of the photograph, return a measure of the variance of the picture density, with a range of zero to 1.0, an accuracy of +/- 0.1 and a probability of failure of .15 per photograph taken.  Just as with the thermometer, two photographs of the same scene taken at about the same time would be expected to have the same density variance measure, within the accuracy specification, and if the camera fails, the density variance measure will have a random value within the specified range. 

NASA has asked you to design, as a part of your system, a technique to detect bad sensor readings and thereby assure that no more than 5% of the experimental results returned to Earth are victims of sensor failure.  It may be necessary for a rover to run some experiments more than once to accomplish this goal. 
[Link to relevant section of DP.]

4/8/04: 
  1. The FAQ and this version history were added.
  2. Each rover now has a 100 (Martian solar) day MTTF, rather than a 10% chance of failure per experiment.  Even if rovers are idle, they can still fail. [Link to relevant section of DP.]
  3. A note was added clarifying that when a sensor fails, the value returned by the sensor is a random value, selected uniformly from all possible sensor values.  [Link to relevant section of DP.]
  4. A note was added suggesting that each experiment type includes a function that accepts two experimental results and returns their difference, expressed as a real number. For each type of experiment, a precision bound is also provided that indicates the maximum variance that two readings from the same time at the same location would exhibit.  [Link to relevant section of DP.]

4/1/04:  Initial Version