sign in sign up
<<
Home , Sojourner (rover), Sol (day on Mars)

Summary of Results from the Risk Management program for the Microrover Flight Experiment

Robert Shishko, Ph.D. and Jacob R. Matijevic, Ph.D. Jet Propulsion Laboratory, California Institute of Technology 4800 Oak Grov'e Drive, Pasadena CA 91109

volume, mass, and power for both the microrover Abstract. On 4 July 1997, the Mars and its instrument (APXS) payload, microrover Pathfinder landed on the surface of Mars carrying interfaces with the Pathfinder , and use of the first planetary rover, known as the . some commercial and MiI-Spec parts. Operations Formally known as the Microrover Flight risks arose because of an unknown landed Experiment (MFEX), the Sojourner was a low cost, configuration for the , use of new approaches high-risk technology demonstration, in which new to command, control, and communication, and risk management techniques were tried. This paper uncertain environmental conditions. summarizes the activities and results of the effort to conduct a low-cost, yet meaningful risk This paper summarizes the activities and management program for the MFEX. The specific results of the effort to conduct a low-cost, yet activities focused on cost, performance, schedule, meaningful risk management program for the and operations risks. Just as the systems MFEX, which was originally designated as a high- engineering process was iterative and produced risk (Class D) payload. The specific objectives of successive refinements of requirements, designs, the MFEX risk management effort were: etc., so was the risk management process. Qualitative risk assessments were performed first (a) Define and implement a risk to gain some insights for refining the microrover management process tailored to design and operations concept. These then evolved the MFEX; into more quantitative analyses. Risk management (b) Develop risk-based criteria to lessons from the manager's perspective is evaluate the effectiveness of the presented for other low-cost, high-risk space risk management techniques; missions. (c) Develop data to permit evaluation. 1.1 MFEX RISK MANAGEMENT PROCESS The general risk management process The Microrover Flight Experiment followed by the MFEX is described in (NASA, (MFEX) is a small, semi-autonomous robotic 1993) and (NASA. 1995). That process consists of vehicle (better known as the Sojourner) that was four overlapping stages: risk management flown on the (MPF) mission in planning, risk identification and characterization, 1996/97. The microrover was designed to move risk analysis, and risk mitigation and tracking. The onto the surface from ramps deployed process tailored for the MFEX involved from the lander part of the Pathfinder spacecraft. performing specific activities for each of these four On the surface, it was to move away from the stages that are integrated directly into the regular lander, image the lander, place an Atpha Proton X- systems engineering process. The specific ray Spectrometer (APXS) on Martian rocks and activities focused on cost risk, performance risk. soil, and perform a variety of technology schedule risk. and operations risk. Just as the experiments. The MFEX risk management systems engineering process is iterative and activities focused on the tbllowing major risk produces successive refinements of requirements. categories: cost, schedule, performance, and designs, etc.. so is the risk management process. operations. Cost risk was considered important Qualitative risk assessments were performed first because the MFEX had a fixed budget of $25M to gain some iv,sib'hfs for refining the microrover (RY$) over its entire life cycle. Schedule risk design and operations concept. These then evolved arose because the microrover had to be integrated into more quantitative analyses. ]'he qualitative into the Mars Pathfinder spacecraft, which itself and quantitative analyses available at each decision had to meet a 1996 launch date. Performance risks point were considered by the MFEX manager in arose for a variety of reasons: design constraints on allocating MFEX reserves. Figure I shows the process for making Planning tbr risk mitigation included risk management (unshaded boxes in the figure) estimating the costs (and schedule implications) of integral to the MFEX systems engineering effort. risk mitigation actions, as well as the likelihood The following example illustrates this process flow. that the MFEX life-cycle cost would exceed the The Mars Pathfinder project defined its mission cost cap of $25M because of the identified needs for the microrover. These were to (a) deploy technical and schedule risk factors. In some science instruments and (b) image the lande_: to instances, TPM tracking provided an indication of determine its condition. Originally, the science the urgency of implementing risk mitigation plans desire was for the microrover to deploy a and actions. As problems were encountered, these seismometer, and to carry both an Alpha Proton X- assessments were used to allocate MFEX reserves. ray Spectrometer (APXS) and a neutron For example, after testing the APXS deployment spectrometer. A microrover design assessment mechanisms, the likelihood of mechanism failure indicated that a microrover that was capable of to properly position the APXS would be reassessed fitting within the MFEX cost cap was not capable and reserves allocated to cover the costs of of carrying even the lightest seismometer. providing for longer APXS operation times to make up for possible misalignment. Further, the Mars Pathfinder science budget could not support the neutron spectrometer. Timeline analyses, called Landed Mission Therefore, a capabilities assessment eliminated Operations Scenarios, were the primary tool for these two inslzuments. The requirements analysis assessing the impact of various technical risks on led to a requirements agreement between the Mars the technical mission success metric. For Pathfinder project and MFEX for a microrover example, these scenarios were used to evaluate the capable of carrying the APXS and placing it on effect of longer APXS operation times on the rocks and soil. achievement of other mission objectives, so overall technical mission success could be evaluated. With In conjunction with the requirements this information, the team leader could determine agreement, criteria were established to define whether the marginal improvement in technical MFEX technical mission success. These criteria mission success was worth the additional risk were to: (a) perform a complete set of technology mitigation costs. experiments in one soil type, (b) measure one rock with the APXS and image that rock, (c) produce The risk management activities that are one full cross- section image of the lander, and (d) described later in this report map into the unshaded do two more soil types, another APXS rock boxes in Figure I. For example, the cost risk measurement, and three more lander images if analysis box in the figure was accomplished by possible. Ninety percent technical mission success performing the Cost Uncertainty Questionnaire. was assigned to doing (a), (b), and (c), with equal Sometimes. several activities were performed in weight to each; an additional ten percent technical connection with a particular box, as was the case mission success was assigned to the extended for the technical risk assessment. mission tasks in (d). These criteria established a technical mission success metric. 1.2 RISK MANAGEMENT METRICS

The requirements analysis was refined, Throughout the task, a simple risk employing tirneline analysis (Landed Mission management summary was maintained in the form Operations Scenarios) to determine what functional of a time-phased "traffic light" chart--that is, red, and performance capabilities were needed by the yellow, or green---was used to indicate the MFEX microrover in order to achieve a scientifically risk status at each discrete point in time (usually successful mission---4hat is, deploy the APXS and corresponding to significant milestones or major perform the other technology tasks described reviews). The summary, chart is reproduced here as above. As part of the ongoing successive Table I. The metrics in Table I are the classical refinement of the microrover design, technical risk ones--cost, schedule, and performance. Status was •,.assessments were made at increasing levels of determined _ith the help of some of the methods detail, and potential failures were identified. For like Technical Performance Measurement (TPM) each potential failure, risk mitigation actions were and Rec. Del Tracking. To implement these, simple developed. For example, the APXS might not be spreadsheet tools _ere developed. properly placed on the rock. The risk mitigation plan was then amended to include designing and testing prototype APXS deployment mechanisms. Miu_on I I Success Risk Mitigation _ Risk Mitigation Metnc Plans/Action I I Costs

TrackingTPM ___ Re_m_e= I

Figure 1--Process for Integrating Systems Engineering and Risk Management

As of: DICR CDR SIM/FU ATLO LRR (7193) (2/94) (5195) (7/96) (12/96) Life-Cycle Cost G G G G G Schedule N/A N/A Y G G Technical Performance N/A G G G G

System (Rover+LMRE) Mass (kg) N/A Y G G G WEB Electronics Board Volume (cm^3) N/A G G G G Average Driving Power (watts) N/A G G G G

Worst Case Peak Operating Power (watts) N/A G G G G

Array Electrical Energy Consumption/ N/A G G G G (watts/hour) Development + Ops Thermal Cycles N/A G G G G (number of cycles) UHF Data Flow (Mbits/) N/A G G G G

Data Storage - RAM (kbyte) N/A G G G G Control Memory - PROM (kbyte) NIA G G G G Operations N/A N/A N/A N/A N/A BasicMission N/A N/A N/A N/A N/A ExtendedMission N/A N/A N/A N/A N/A

Codes for Table: DICR Design Implementation and Cost Review lip " N/A Not Available CDR Critical Design Review R Red SIM/FU System Integration Model/Flight Unit Y Yellow ATLO Assembly, Test, and Launch Operations G Green LRR Launch Readiness Review Table 1--Microrover Flight Experiment (MFEX) Risk Management Summary The assignment of red-yellow.green status From the workshop material and in Table I was made when appropriate criteria discussion, the landed mission operations cognizant could be devised. For life-cycle cost, the criterion engineer compiled a list of 40 events that pose was risk-based. Using the cost risk analysis potentially significant operability risks. In order to (described in Section 2.2), we were able to determine which of these should be given further determine the risk that the cost at the end-of- attention, the same engineer assembled the Landed mission (EOM) would exceed some value. Life- Mission Risk Assessment Survey, which is cycle cost risk status was green if the probability of documented in (MPFb, [993, Appendix C. I). This remaining within the MFEX cost cap plus five survey was sent to Mars Pathfinder (MPF) and percent was 95 percent (or greater); it was yellow if MFEX personnel, who collectively had experience that probability was between 65 and 95 percent, in operations, engineering design, science and red if it were less than 65 percent. By this instrument development, and project management. criterion, the life-cycle cost risk was always green. The purpose of the survey was to ascertain expert opinion on the relative likelihood and severity of The assignment of red-yellow-green status consequences of the operability risk events. The for schedule was based on schedule variance 40 events were scored by the respondents using a (based on Rec/Dels in Section 2.3) relative to three-point scale (low = l, medium = 2, and high = reserve. 3). For each event, a simple average was calculated for the likelihood and, separately, for the severity The assignment of red-yellow-green status of consequences. To identify the highest risks for TPMs was based on the following criterion: a among the 40, the product of the average TPM was green, if its margin was greater than or probability and severity of consequences scores equal to its margin requirement at the time of was computed for each event. The most significant reporting; it was yellow, if its margin was below its risks had to do with an adverse landing margin requirement, but greater than to equal to the configuration with respect to terrain next rung of the margin requirement "ladder"; it and with local terrain obstacles. In the mission, was red, if it was below that next rung. this did not occur, but detailed rover operation simulations performed after launch confirmed the The assignment of red-yellow-green status importance of the local terrain in accomplishing a for operations was, in fact, never made. Though successful mission. Engineering judgment was the criteria for mission success following rover vindicated by the simulations! deployment were clear, credible metrics for predicting the level of success as a function of A separate, independent technical risk was decisions made during design and development performed by Safety Factors Associates (SFA) and were more difficult to calculate. After MPF documented in (Frank, M.V., et al., 1993). SFA's launch, however, some progress was made in risk assessment approach was based on developing developing a risk-based operations success metric. event sequence diagrams (ESDs), which are This work is reported in Section 2.2. essentially decision trees without probabilities attached to various failure events. The SFA 2.1 RISK IDENTIFICATION AND analysis found the highest risk factor to be the CHARACTERIZATION single point failure of the rover/lander's commercial-grade telecommunications . Other The MFEX risk management effort was concerns were expressed about software formally initiated at a Microrover Risk Assessment complexity and operations contingency Workshop, which was held at JPL. March 23-24, development. It is clear that the 1993. This "'kick-off' meeting was attended by telecommunications link single point failure would MFEX project personnel, other interested JPL have been eventually uncovered, but early personnel, and representatives from NASA HQs identification allowed test plans to be improved (Code Q) and Safety Factors Associates (SFA). and other analysis to be performed earlier in the Cognizant project personnel presented the risk development life-cycle. issues and c_ncems affecting them. The workshop provided an arena t'or open discussion and offered 2.2 RISK ANALYSIS an opportunit_ for MFEX team members to gain an appreciation tbr the risk areas perceived by other Cost Risk Analysis. Cost risk was considered very team members. The workshop also provided a important because the MFEX had a fixed budget of starting point tbr the SFA independent technical $25M over its entire life cycle. Cost risk was assessment and the Landed Mission Risk quantified by treating life-cycle cost as a random Assessment Survey. variable and estimating its probability distribution. This estimation was performed twice, and was future costs only. Fixed (i,e., non-stochastic) level- accomplished using the Microrover Cost of-effort costs as project management and sunk Uncertainty Questionnaire. The questionnaire was cost (all costs expended to daze) are included in first administered to each subsystem cognizant life-cycle cost total. The simulation captures the engineer in July 1993 prior to the Design cost uncertainty at a point in time given the Implementation and Cost Review (DICR) and technical design requirements and schedule. The again in February 1994 just prior to Critical Design imposition of new requirements (such as a major Review (CDR). The information collected each descope) changes the inherent cost uncertainty. time was intended to: (I) determine current cost uncertainty status, and (2) estimate the probability Figure 2 graphically illustrates the of the MFEX's life-cycle cost being less than the cumulative distribution function (cdf) of MFEX's $25M (RY$) budget. [n the second use of the life-cycle cost at the DICK and CDR. The cdf is questionnaire, we also sought to identify changes in also known as the cost S-curve. The cdf derived cost uncertainty since the initial estimate from the February 1994 questionnaire indicates approximately eight months earlier. that the probability of the MFEX's life-cycle cost being less than or equal to its budget of $25M In the questionnaire, each subsystem (RY$) is 74 percent. Equivalently, the probability engineer was asked to estimate cost at five fractile of overrunning is 26 percent. A comparison with values (0, 25, SO, 75, and 100 percent). Monte the cdf derived from the July 1993 questionnaire Carlo simulation was used to aggregate the data indicates that while the expected cost (mean) into cost probability density functions. The increased, overall cost uncertainty was reduced. questionnaire was concerned with uncertainty of

|o0 .....

0.0 $23.00 $24.00 $25.00 $26.00 $27.00 $28.00 SRYM

Figure 2--MFEX Total Life-Cycle Cost Uncertainty Comparison

Timeline Analysis. Timeline analysis was the fixed. The scenarios were used to estimate.how prima_ tool used to devise sensible operations many sols it required to achieve the mission concepts for the microrover. Each timeline success criteria defined in Section I.I. Timeline consisted of ordered events and event durations; analysis was used from the earliest planning these formed what MFEX called Landed Mission meetings of the Mars Pathfinder in 1992. Early Operations Scenarios. These scenarios, which versions or" the Landed Mission Operations were initially captured in Excel spreadsheets, were Scenarios were documented by the time of the deterministic because all event durations were DICR (Design Implementation and Cost Review) in July 1993 (MPFa, 1993), and later updated in complete FMECA was not performed and the (MPF, 1994). Starting in 1995, timelines were MFEX test program may have been an effective captured in one of JPL's in-house mission substitute. One lesson is that the resources to do a scheduling tools, called Plan-It. complete FMECA may be larger than a low-cost project can afford. The Landed Mission Risk Assessment Survey, performed on a one-time basis in August Surface Operations Risk Modeling and 1993 identified the highest risks to MFEX mission Simulation. To assess the microrover's ability to success. For the top risks, the landed mission accomplish its technology objectives, MFEX relied operations cognizant engineer (CogE) developed on the Landed Mission Operations Scenarios. potential operational response/recovery strategies These "models" consisted of both nominal and off- as part of the risk mitigation effort. The same nominal detailed timelines, originally expressed in CogE then analyzed these strategies by inserting spreadsheets. off-nominal conditions into the deterministic scenarios and calculating the effects on the landed These scenarios validated the microrover mission timeline taking into account alternative design and operations concept against MFEX's operational response/recovery strategies. technology requirements by tracking the mission through detailed timelines in order to predict FMECAs. In general terms, a Failure Modes, mission technical accomplishment versus time. Effects and Criticality Analysis (FMECA) is an Since longer exposure to the Mars environment ongoing procedure by which potential system increases the likelihood of failure, mission failures are analyzed to determine the effect on the technical objectives had to be accomplished in less system, and to classify each potential failure mode time than the microrover's design life. However, according to its severity. Typical information the duration of each event in each scenario model collected in a FMECA includes identification of (both nominal and off-nominal) was deterministic. the equipment item, mission phase (e.g., cruise, A mission success metric (or measure of surface operations), failure mode, failure cause, effectiveness) that took into account timeline system or subsystem failure effect, severity or uncertainty and rover reliability would have been criticality and failure detection. Three FMECAs preferred. Developing such a quantitative model to were planned to identify failures affecting the predict the mission success metric, however, would microrover. have been too costly for MFEX, given its budget constraint. The first FMECA reviewed the microrover--APXS electronics interface. A total With the help of the JPL Project Design of nine failure modes and causes were identified and Architecture Support Office and the Mars for each night and day surface operation phase. Exploration Technology Office, a new effort to The second FMECA focused on the Mars quantify mission success using stochastic measures Pathfinder (MPF) entry, descent and landing (EDL) began after launch. Taking advantage of advances subsystem, and identified failures by mission in commercial simulation tools and in reliability sequence and failure mode.The FMECA effort was modeling, this work linked a number of models to expanded to include the entire Mars Pathfinder simulate the Sojourner's movement in a wide Project---that is, all hardware, software, and variety of synthetic Martian environments. The functional failures that could occur during any results of these simulations were then used as portion of the mission. The Mars Pathfinder inputs to a system-level hardware reliability, model. Project FMECA was substantially completed by The federation of models used in this effort October 1994. Only a portion of this FMECA included: (a) rover surface operations simulations, dealt with the microrover directly, but it stimulated (b) Mars environment models, encompassing discussions of risk tradeoffs between EDL and temperature cycling, optical depth, and surface microrover surface operations that led to the terrain, (c) a decision tree to represent these development of the off-nominal sequences for sol l environments and their respective probabilities, (d) operations. The tradeoffs gocused on whether to probabilistic component failure models for each deplo) the microrover as rapidly as possible and failure mode. and (e; a system-level hardware attempt to pertbrm the science and technology reliability model. experiments on sol l, or to proceed more slowly and risk microrover thilure due to extreme One role of the surf:ace operations overnight temperatures. The FMECAs helped the simulations was to provide quantitative values for project team decide on the latter, but was not the failure drivers (e.g., operating time, distance instrumental in that decision. For the MFEX, a driven, on-off cycles) in the individual rover component failure models. The system-level optical depth (very clear), 19.5 degrees N , hardware reliability model aggregates all of these and 143 degrees areocentric (mid-to-late individual component results to create an overall summer). reliability for a particular combination of Martian environmental parameters (including variations in The curve results from the uncertainties in the diurnal temperature cycles). The reliability the Martian environment at the landing site and the results are rolled up over the possible Martian consequent effects the environment has on rover environments and the resultant uncertainty in the operations and reliability. Several risk-based actual travel distance and travel time using the measures of effectiveness (MoEs) could be decision tree model to produce a probabilistic quantified on the basis of Figure 3. One could description of the rover's reliability in traveling choose the distribution's mean, median, or the 100 meters geodesic distance. This is displayed in confidence that rover reliability exceeds some fixed Figure 3 as a cumulative distribution function. The level, say 90 percent. The mean (expected value), simulations, shown in Figure 3, reflect conditions which in this case represents a good choice for risk similar to the actual MPF landing site--high tracking during development, is 0.952.

1.000 0.900 =__'8-0.800 a_ cg 0.700 o 0.600 k. D. 0.500 0 _> 0.400 4.1 _m 0.30O E 0.200 0.100 0.000 0.0 0.2 0.4 0.6 0.8 1.0

Reliability of RDver at 100 Meters Geodesic Travel

Figure 3--Risk-Based Measure of Effectiveness for Sojourner Operations

Operations Contingency Planning. As part of the 2.3 RISK MITIGATION AND TRACKING Landed Mission Operations Scenarios (timeline analysis) described in Section 2.2. 18 potential off- Significant Risk List. A significant risk list, nominal situation operational response/recovery known as the MFEX Risk Management Data Base strategies were identified by the landed mission (MRMDB), was the principal tool throughout the operations cognizant engineer. These were MFEX life-cycle for capturing the identified documented in (MPFa, 1993) in July 1993, and significant risks and associated mitigation later updated in (.MPF. 199,1). These strategies strategies. The MRMDB was created early in the were linked to the 40 operabilit? risk events in the MFEX life-cycle (Jul} 1903), and was initiall,, Landed Mission Risk Assessment Survey. populated with data from the Landed Mission Risk described in Section 2. I, so that each risk event had Assessment Survey. Ultimately, 182 records were one or more response/recovery strategies entered into the MRMDB -- most of which tell associated _,,ith it. If the event were to occur, one into the technical risk categor) and impacted the or more of the response/reco,,ery strategies could operations phase of the mission. be initiated. Lien/ReserveManagement.Sizing MFEX Table 2 lists the TPMs that were actively managed reservesinitially was nearly impossible in spite of using margins. the early effort to identify risks. The total amount of reserves available for MFEX ruined out to be It was very useful to begin tracking TPMs adequate, if not generous, but the phasing of funds early even though there were changes in the TPMs was not matched to the demand. This was included and their allocations. Over the project corrected by an infusion of more funds in Fy94 cycle, the list of TPMs to be tracked changed as than was originally planned. The flexibility new ones were added and others were redefined to demonstrated by NASA Headquarters saved better reflect operational concerns. For example, MFEX. nominal peak operating power was changed to average driving power. The list stabilized around Reserves were released ahead of the paper the SIM/FU milestone (April 1995). cycle so as not to slow down the development process. Generally, this allowed team members to TPM/margin management was one of the buy needed hardware and to supplement the most cost-effective risk management methods for workforce in a timely fashion. A simple, one-page MFEX. A collection of simple graphical displays standard lien report was introduced in FY95 that made it extremely easy to see whether technical captured (I) what was authorized, (2) when the problems were looming. See Figure 4 for the funding was to be spent, and (3) account that was system mass TPM chart. affected. The purpose of this standard report was to enable one person (e.g., the risk manager or task None of the TPMs, except system mass, lead) to rapidly recalculate MFEX's reserve were really ever in jeopardy of not making their position and to verify account accuracy. margin requirement. System mass, defined as microrover mobile mass plus LMRE mass, Technical Performance Measurement (TPM)/ required the most attention because it failed to meet Margin Management. By tracking the its margin requirement at CDR. The system mass microrover's Technical Performance Measures margin of 11% was below the CDR margin (TPMs), the MFEX task manager gained requirement of 15%. At that time, two design into whether the delivered product will meet its responses were identified to lower system mass: (I) performance requirements. There are several use a single deployment ramp and increase risk of methods by which to track TPMs (i.e., system non-deployment or (2) remove one, two, or three technical resources), and the MFEX task manager battery strings limiting APXS to daylight chose the margin management method. In this operation, and thereby increasing the time to method, the task manager and/or system engineer accomplish the mission. Both of these added risk establishes a time-phased margin requirement for to the landed mission (as perceived by the MFEX each TPM, and then compares the actual margin to design team), so neither was done. Instead, there the requirement. The margin is generally defined was an effort to reduce microrovefs mobile mass as the difference between a TPM's demonstrated by shaving mass off of the rockers, bogies, and value and its allocation. The margin requirement is differential. Ultimately, the mircrorover's design usually expressed as a percentage of the TPM's was refined enough by the beginning of ATLO allocation that declines toward zero over the design testing to allow the MFEX task manager to return and development cycle. One of the advantages of 1.605 kg of its system mass allocation to the Mars margin management is that it allows management- Pathfinder Project. The initial allocation of 17.7 kg by-exception--that is. so long as a TPM like mass ultimately became 16.0 kg, accounting for the fall has an actual margin that exceeds the requirement, in the actual mass margin around January, 1996. specific risk management action is usually not Another lesson, then, is that the right number of needed. TPMs to track in low-cost, high-risk interplanetary projects is small, but system mass should be one Prior to the DICR, MFEX established an and others should include key parameters used in initial list of TPMs and their margin requirements any operations simulations. at key project milestones. The baseline, technical design, and current allocation and best estimate for each TPM were published periodically by the MFEX system engineer. TPM, margin report updates were issued quarterly. A spreadsheet tool was developed to record margin requirements and margin data. and to graph these data over time. Table 2--MFEX Technical Performance Measure Values at Launch + 30 Da__S

Microrover System (Rover * LMRF.) A_n • tB.0 kg i _rorov_ Sy_m (Rover÷LMRE)Current_t _ - _S.2k_ i Ml_mver System (Rovm" * LMRE) Mar_ = 0.8 I_ (5.0%) J 3 ..... ,-- L...... 15% Margin Level

Z.S,

...._ ...... cURValu-......

1.S e-

t_ w 0.| =E 1% Margin Lm_ol

0 , ..... , ,,: ;: :,; : ::: :,.:,:. . . : : : : : : : :: : : : : : : :: : ::

-0o$ ° '-) 0 _ ..... < ...... _"...... 0-" _ < '=) ....0 .,. "=) < "_ - 0 ....

Month -1

Figure 4--Technical Performance Measures: Microrover System Mass (kg) environment. The schedule required for this wu Schedule Management. MFEX faced a tight difficult to anticipate. schedule because the microrover had to be integrated into the Mars Pathfinder spacecraft in Under the Rec/Del schedule management time to meet the December 1996 launch date. The method, each cognizant engineer reported hL_cr schedule risk was exacerbated by the fixed budget Rec/Del status monthly to the MFEX task mangler. and the need to modify numerous commercial The MFEX task manager then reported the Rec/Del components. status to the rover team at a meeting held prior to the Pathfinder Monthly Management Review. A In FY93 and early FY94, schedule Rec/Del could not be added or removed without management was based on the use of an integrated the MFEX task manager's approval, and it was the network schedule. This was dropped in April responsibility of each cognizant engineer to 1994, and replaced with a schedule management maintain his/her subsystem schedule and satisfy method based on tracking the subsystem-level Rec/Dei dates. Early in the MFEX project cycle, Receivables and Deliverables (Rec/Dels). The Rec/Dels were tracked using Gantt charts. At fu'st, main reason the integrated schedule could not be separate Gantt charts displayed internal and sustained was that the activities identified in the external Rec/Dels; by FY95, this was changed to network schedules were at too detailed a level to be display Rec/Dels by subsystem. The Gantt charts maintained, given the use of MFEX's rapid were dropped altogether after February 1995 and prototyping development methodology. replaced by a spreadsheet. The Slxe_Le,beet Furthermore, the wide use of commercial parts automatically created a Rec/Del graph like the one required that many components be adapted and in Figure 5. qualified for use in space and in the Mars

RecDel Cumulative Planned Versus Cumulative Actuals

12o

10o

8O

Cum F_nned i- --.ll-- CumActual z

2(1

Month

Figure 5_Schedule Management Using Simple ReclDels

o

engineering risk management process models that 3.0 MICROROVER MANAGER'S MFEX could use. Even the basic mission PERSPECTIVE requirements were not clear at the beginning, and were subject to negotiation with the MPF project As MFEX was not a requirements-driven and the NASA sponsor. Considering that MFEX mission, there were really no integrated systems was supposed to be a technology demonstration of a small planetary rover, the basic question was program. The only pans failure in rover electronics "What would MFEX have to do on Mars that during the test program were an oscillator in a would convince people that this was a useable clock circuit due to overstress sad one 3.3V technology for future Mars missions.'?" The regulator due to workmanship. In fact, one of the immediate second consideration was "What could commercial regulators achieved a mil-spec MFEX afford to do on Mars.'?" standard as a consequence of the test program.

d' With a life-cycle cost cap and a short The commercial modems selected for use schedule, the MFEX team had to adopt new on the rover and lander were cheaper in initial cost implementation approaches and strategies. The than the mil-spec standard alternative, but the fixed price meant that all phases of the telecommunication subsystem experienced the task---definition, development, integration and test, largest cost growth due to the qualification test and operations_had to be considered from the program for the modem. Nonetheless, the modems beginning. Each deliverable, including worked during the mission. downstream items needed for operations, was assigned to a team member who had responsibility "Mission operation is also an experiment." The for it. MFEX team developed a number of tools after launch for telemetry analysis and for commanding Rapid prototyping is not a panacea. Getting the the rover. During operations, the team also rover to work as a system was a major uncertainty developed techniques that reduced rover resource and challenge. The approach taken was one of utilization. "rapid prototyping", with the Rocky 4 vehicle (in all of its configurations) used as a system test vehicle. However, this was not a panacea. MFEX REFERENCES and the MPF project clearly benefited from having Rocky 4 as a testbed for development, but the team Frank, M.V., et al., Microrover Integrated Risk continued to uncover "features" during system tests Assessment, Safety Factor Associates, July 15, and Mars operations. One notable reason was that 1993. the final flight configuration was achieved late in the program leaving little time for test. Mars Pathfinder Project, Mission Operations Specifications, Volume 6, Detailed Scenarios, JPL Have sufficient funding and reserves. The D-10977, July 23, 1993. Cumulative Planned Vs Actual Costs data show a period in FY95 when reserves were committed to Mars Pathfinder Project, Microrover Flight buy hardware and add more people. This period Experiment: Risk Management Progress Report, represented the one of peak labor demand as JPL D- 1118 I- 1, December 21, 1993. technicians and support personnel were needed for assembly and test. MFEX was able to do that Mars Pathfinder Project, Mission Operations because there were sufficient available dollar Specifications, Volume 6, Detailed Scenarios, Rev resources and reserves. Because there was little A, JPL D- 10977, April 1994. rebuild or rework other than that associated with modifications in response to a test failure, reserve NASA Headquarters, Code AD, Management of funds were accumulated and were made available Major System Programs and Projects, NHB to fund post-ATLO operations improvements. The 7120.5, November 8, 1993. SIM was used as a vehicle for tests and training in preparation for mission operations. After nearly a NASA Headquarters, Code FT, NASA Systems year, those tests and training activities resulted in a Engineering Handbook, SP-6105, June 1995. set of flight software updates and an operations team ready to conduct the landed mission. The research described in this paper was carried out by the Jet Propulsion Laboratory, Maintain good dollar reser_,es and invest California Institute of Technology, under a contract them at the first sign of trouble in implementation with the National Aeronautics and Space to allow additional development and testing. Administration. Reference herein to any specific commercial product, process, or service by trade Mixed results from commercial parts strategy. name, trademark, manufacturer, or otherwise, does The commercial power converters and regulators not constitute or imply its endorsement by the used in the rover electronics provided excellent United States Government or the Jet Propulsion pertbrmance during the mission and qualification Laboratory, California Institute of Technology. BIOGRAPHY

Dr. Shishko received his S.B. degrees at M.I.T. and M.Phil and Ph.D. degrees at Yale University. He has been at the Jet Propulsion Laboratory for 16 years, where he has written extensively about systems engineering and analysis issues, including risk management. He received the NASA Exceptional Achievement Medal in 1997 for systems engineering. Dr. Shishko also serves part- time on the faculty of the International Space University.

Dr. Matijevicreceiveda BS inmathematicsfrom IllinoisInstituteof Technologyin 1969and an MS (in1970)and PhD (in1973)inmathematicsfrom theUniversityof Chicago.JacobR. Matijevicwas the manager of the Mars Pathfinder Microrover Flight Experiment (l_ ('Sojourner'), responsible for the implementation, integration, delivery and eventual operation of 'Sojourner' on Mars. As manager, he received a NASA outstanding leadership medal and the project received (among many awards) the Discover Magazine editors' choice award for technological innovation. He has served as a task manager and design engineer on several robotics system design activities including the development of the telerobot testbed at JPL. He currently is leading the system design of the rovers planned for sample return missions which are part of the Mars at JPL. Prior to joining JPL in 1981, he was an assistant professor in mathematics at the University of Southern California and a postdoctoral fellow at the University of Kentucky.