1University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 1Lecture 12:Requirements AnalysisUniversity of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 2Mars Polar LanderLaunched3 Jan 1999MissionLand near South PoleDig for water ice with arobotic armFate:Arrived 3 Dec 1999No signal received afterinitial phase of descentCause:Several candidate causesMost likely is prematureengine shutdown due tonoise on leg sensors2University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 3What happened?We don’t know for sure:spacecraft not designed to sendtelemetry during descentThis decision severely criticized byreview boardsPossible causes:1. Lander failed to separate fromcruise stage (plausible but unlikely)2. Landing site too steep (plausible)3. Heatshield failed (plausible)4. Loss of control due to dynamic effects(plausible)5. Loss of control due to center-of-massshift (plausible)6. Premature Shutdown of DescentEngines (most likely!)7. Parachute drapes over lander(plausible)8. Backshell hits lander (plausible butunlikely)University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 4Premature Shutdown ScenarioCause of errorMagnetic sensor on each leg senses touchdownLegs unfold at 1500m above surfacesoftware accepts transient signals on touchdown sensors during unfoldingFactorsSystem requirement to ignore the transient signalsBut the software requirements did not describe the effectEngineers present at code inspection didn’t understand the effectNot caught in testing because:Unit testing didn’t include the transientsSensors improperly wired during integration tests (no touchdown detected!)Result of errorEngines shut down before spacecraft has landedestimated at 40m above surface, travelling at 13 m/sestimated impact velocity 22m/s (spacecraft would not survive this)nominal touchdown velocity 2.4m/s3University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 5FLIGHT SOFTWARE REQUIREMENTS3.7.2.2.4.2 Processinga. The lander flight software shall cyclically check thestate of each of the three touchdown sensors (one per leg)at 100 Hz during EDL.b. The lander flight software shall be able to cyclicallycheck the touchdown event state with or withouttouchdown event generation enabled.c. Upon enabling touchdown event generation, the lander flight software shall attempt to detect failed sensors bymarking the sensor as bad when the sensor indicates“touchdown state” on two consecutive reads.d. The lander flight software shall generate the landing event based on two consecutive reads indicatingtouchdown from any one of the“good” touchdownsensors..SYSTEM R EQU IREMENTS1) The touchdown sensors shall be sampled at 100-Hz rate.The sampling process shall be initiated prior to lander entryto keep processor demand constant.However, the use of the touchdown sensor data shall notbegin until 12 meters above the surface.2) Each of the 3 touchdown sensors shall be testedautomatically and independently prior to use of thetouchdown sensor data in the onboard logic.The test shall consist of two (2) sequential sensor readingsshowing the expected sensor status.If a sensor appears failed, it shall not be considered in thedescent engine termination decision.3) Touchdown determination shall be based on twosequential reads of a single sensor indicating touchdown.Figure 7-9. MPL System Requirements Mapping to Flight Software Requi rementsAdapted from the “Report of the Loss of the Mars Polar Landerand Deep Space 2 Missions -- JPL Special Review Board (Casani Report) - March 2000”.See http://www.nasa.gov/newsinfo/marsreports.htmlUniversity of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 6Quality = Fitness for purposeSoftware technology is everywhereAffects nearly all aspects of our livesBut our experience of software technology is often frustrating/disappointingSoftware is designed for a purposeIf it doesn’t work well then either:…the designer didn’t have an adequate understanding of the purpose…or we are using the software for a purpose different from the intended oneRequirements analysis is about identifying this purposeInadequate understanding of the purpose leads to poor quality softwareThe purpose is found in human activitiesE.g. Purpose of a banking system comes from the business activities of banksand the needs of their customersThe purpose is often complex:Many different kinds of people and activitiesConflicting interests among them4University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 7Designing for peopleWhat is the real goal of software design?Creating new programs, components, algorithms, user interfaces,…?Making human activities more effective, efficient, safe, enjoyable,…?How rational is the design process?Hard systems view:Software problems can be decomposed systematicallyThe requirements can be represented formally in a specificationThis specification can be validated to ensure it is correctA correct program is one that satisfies such a specificationSoft systems view:Software development is embedded in a complex organizational contextThere are multiple stakeholders with different values and goalsSoftware design is part of an ongoing learning process by the organizationRequirements can never be adequately captured in a specificationParticipation of users and others throughout development is essentialReconciliation:Hard systems view okay if there is local consensus on the nature of the problemUniversity of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons
View Full Document
Unlocking...