Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Battista barlowpmc conference 2012 rev. 2
Ähnlich wie Battista barlowpmc conference 2012 rev. 2 (20)
Mehr von NASAPMC
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Battista barlowpmc conference 2012 rev. 2
- 1. All Subsystems Are Not Created Equal Alternative Scheduling Approaches for Spacecraft Subsystem Development Dewey E. Barlow corina c. k. battista February 2012 Orlando, FL
- 2. All Subsystems Are Not Created Equal Contents • Current NASA Environment • Technology Readiness Level (TRL) Considerations • Technology Race Analogy • AO Process Implications • Potential Solutions • Staggered Starts • MIN TRL6 First • Staggered Finishes • Recommendations • Conclusion
- 3. All Subsystems Are Not Created Equal Current NASA Environment Used by permission.
- 4. All Subsystems Are Not Created Equal Current NASA Environment (7120.5) Figure 3.1 – NASA Project Lifecycle
- 5. All Subsystems Are Not Created Equal TRL Considerations When many subsystems are involved, the fact that the completion of an entire spacecraft is more likely to be delayed due to the slippage in the development of one immature subsystem is supported by historical evidence
- 6. All Subsystems Are Not Created Equal TRL Considerations It is difficult at best to predict the timeframes required for new and emerging technology because: • We have limited relevant historical data • Even when relevant historical data exists, past performance may not be an accurate indicator of future performance since new independent variables are constantly being introduced • Technology development is often an iterative process - We find out what works often by eliminating what does not (Thomas Edison and the light bulb) • Resource units are not highly correlated with duration
- 7. All Subsystems Are Not Created Equal TRL Considerations Since schedule requirements for technology development activities are subject to variation and difficult to predict, how do we expect low TRL hardware to stay on pace with proven technologies?
- 8. All Subsystems Are Not Created Equal TRL Considerations Forcing low TRL subsystems to keep pace with proven technologies can induce inefficiency in execution, create schedule risk, and contribute to cost and schedule overruns
- 9. All Subsystems Are Not Created Equal AO Process Implications Compressing an already critical subsystem or instrument’s critical path may provide an overly optimistic and ultimately unachievable timeframe for development. Subsystems that have the most schedule risk have the least amount of available schedule reserve
- 10. All Subsystems Are Not Created Equal AO Process Implications NASA projects are expected to comply with generally-accepted schedule reserve guidelines so development timeframes for these already compressed low TRL subsystems are reduced even further
- 11. All Subsystems Are Not Created Equal Potential Solution 1 – Staggered Starts (SS) What if we started with an unconstrained environment and allowed the subsystems and instrument teams to define their schedule requirements given known resource constraints and using adequate calculated schedule reserve commensurate with the level of technical and execution risk?
- 12. All Subsystems Are Not Created Equal Potential Solution 1 – Staggered Starts (SS) Staggered Starts allows each subsystem to develop on their own schedule and achieve compliance with 7120.5 through delta mission level reviews and waivers
- 13. All Subsystems Are Not Created Equal Potential Solution 2 – MIN TRL First The subsystems and instruments that are not at TRL 6 would be required to engage in technology development and demonstration activities to achieve TRL 6 prior to engaging all subsystems
- 14. All Subsystems Are Not Created Equal Potential Solution 3 – Staggered Finishes Staggered Finishes allows each subsystem to develop on their own schedule/deliver early and achieve compliance with 7120.5 through delta mission level reviews and waivers
- 15. All Subsystems Are Not Created Equal Potential Solutions – Summary All solutions involve some level of decoupling and decompression of subsystem schedules
- 16. All Subsystems Are Not Created Equal Recommendations 1 – Perform schedule risk assessments at the subsystem level to predict probable range of deliveries
- 17. All Subsystems Are Not Created Equal Recommendations 2 – Analyze data from schedule risk assessments to detect groupings or patterns
- 18. All Subsystems Are Not Created Equal Conclusion 3 – Select the appropriate schedule approach
- 19. All Subsystems Are Not Created Equal Example Low TRL M T O P High TRL M O – Optimistic T M – Most Likely P – Pessimistic O P T – Target (say 70%) The Initial TRL Estimate Influences the Parameters of Probability Distribution on Delivery
- 20. All Subsystems Are Not Created Equal Example OPL FSW PDU PSE RF NMS Late Start Common Start Early Start The Aggregate Probability Distribution Targets May Offer Patterns to Help Plan Subsystem Schedule Development Approaches
Hinweis der Redaktion
- Introduce ourselves and give a little bit background on where we work and what we do.
- Outline the agenda. Note that the term subsystem will be used throughout this presentation to also represent instruments.
- Need I say more? Basically captures that we are in a phase of trying to deliver more product for less $$. We’re not in a time of escalating budgets so we have to find creative ways to deliver more with less.
- This captures the standard mission level reviews and phases for all NASA missions. I imagine that all of you have seen this chart before. The top row shows the NASA Lifecycle Phases. The second row captures project lifecycle phases such as A (Concept), B (Preliminary Design), etc. The Key Decision Points are captured in the third row while all of the mission level reviews are captured in the last row. All missions must pass these gates to make it to the next phase. The current environment promotes the notion of having all subsystems go through these gates at the same time. We will present alternate, different approaches to achieving these gates.
- This graph capturesNASA’s standard definition of the 9 Technology Readiness Levels. We need to recognize that, from a scheduling perspective, significant variation may exist in TRLs at the subsystem level. Where that occurs, historical evidence suggests that the less mature TRL subsystems are likely to cause schedule delays. No mission starts with all subsystems at the same TRL level, and typically the subsystems with lower TRLs lag behind the ones with the higher TRL levels.
- So we recognize that there is a varying TRL issue but here’s the problem. <Read the bullets.> The takeaway here is that it’s not easy to plan for varying TRLs.
- While Dewey and I were debating the details of this TRL issue and potential solutions, we kept coming back to the issue as represented by a race. This is a simple graphic to show the crux of the problem. Effectively, the issue can be represented by a race with 3 participants. One raceris pushing a wheel barrow, one is riding a bike and one is on a motorcycle. These modes of transportation represent the disparity in TRLs that may occur on a mission. The participant on the motorcycle is obviously (barring any major issues like a blown tire) going to cross the finish line first with the wheel barrow pusher coming in last. The point here is that if all of these participants all start at the same time, we can’t realistically believe that they will finish at the same time. But currently, to pass the major mission milestone gates, they all need to be at the finish line ready to go. So the slower moving ones dictate the pace of completing the mission.
- Effectively, subsystems that “get out in front” must either slow or suspend progress to pass the project review and KDP hurdles at the same time as the slowest subsystem. This creates inefficiency for the subsystems with schedule reserve since the project must bear the cost of carrying the subsystem resources (“marching army”) throughout the project or risk losing them to a competing project. This means that the slowest moving participant (often the subsystem with the lowest TRL) becomes the critical path. The other subsystems with higher TRLs tend to have more schedule reserve at the back end because they complete sooner thus giving them greater buffer. The takeaway here is that the subsystems which need the most schedule reserve (the ones with lower TRLs) end up having the least!
- <Reference Andrew Chaikin speaking of not building the shuttle to technology but to cost.> A target launch date and phasing plan is often identified in the Announcement of Opportunity (AO) for major civilian spacecraft missions and bidders are encouraged15 to fit their schedules within the constraints of the launch date, regardless of the level of maturity of the major spacecraft subsystems. We then compound the problem by compressing an already tight critical path duration during the AO process. This compression shrinks the durations of all subsystems but those with sufficient reserve can adjust whereas the subsystems with the lower TRLs (and thus already shortened durations and even the CP) are now crunched even further. This adds risk that the execution of the CP and near-CPs because they become overly optimistic and potentially unachievable. In the end, the subsystems that have the most schedule risk have the least amount of available schedule reserve and the subsystems that have the least schedule risk have the most available schedule reserve. Less available schedule reserve means less cushion for the plethora of technological challenges that must be overcome to advance the technology to the next level and meet the requirements of the mission level review. Reference #15 = “Proposals that do not meet the specified mission level milestones identified in the AO may be considered non-responsive in accordance with Federal Acquisition Regulations (FAR)”.
- NASA projects are expected to comply with generally-accepted schedule reserve guidelines <i.e. state JHU-APL reserve guidelines>.When schedule reserve is added to meet guidelines to show that there is buffer on the CP to cover the risk associated with the lowest TRL subsystem’s development cycle, this causes a compound compression of that already tight timeframe of the low-TRL subsystem. Ultimately, this adds more risk to that development flow. This compound compression can result in development timeframes at the subsystem level that are both unrealistic and unachievable and may ultimately result in cost and schedule overruns.
- Dewey and I asked ourselves how major civilian space missions requiring the integration of complex subsystems can be achieved when the subsystems have varying TRLs. A staggered start approach places all subsystems on a theoretically equal schedule risk platform and would help to ensure that all spacecraft components arrive at the required time. We return to our race analogy. If we start with an unconstrained environment and allow the subsystems to define their schedule requirements given known resource constraints and using adequate calculated schedule reserve (where schedule reserve is commensurate with the technical and schedule risks and not prescribed by a guideline), then we could define a markedly different environment for project execution. From our previous race example, the uncompressed subsystem estimates become estimates based on detailed schedules and an associated risk analysis along the critical path of each schedule.
- Since schedule development timeframes are based on unconstrained activity durations and schedule reserve is calculated based on known risks, our expectation is that this independent/unbiased estimate of development time would be more accurate and have a higher probability of success. With the goal that all subsystems ultimately deliver to a well-planned integration and test sequence in a timely fashion, the start dates for each subsystem would have to be staggered. In the current implementation environment, there is an additional complication by the fact that the distances vary by racer, and the racers are not completely independent of each other; however, it is possible to establish major reviews at the subsystem level (accelerated PDR, accelerated CDR, et al.) for the low TRL subsystems that must start earlier. An accelerated review would essentially be an early delta review that functions as the gate for the subsystem to pass to the next phase. The project level review (PDR, CDR et al.) can then be held based on the aggregate requirements of all other subsystems.
- An alternate solution (a variation of the staggered start approach) is to perform an assessment of TRL near the start of the project for each subsystem. The subsystems whichare not currently at TRL6 would be required to engage in technology development and demonstration activities earlier to develop a functioning prototype in a ground environment (per the definition of TRL6). After all of the subsystems achieve this threshold for technological development, the traditional synchronized approach can be employed. As opposed to the staggered start approach, which morphs over time into the traditional approach, this approach requires that all subsystems pass a gate before full project participation can begin. This approach would be designed to advance the TRL of low TRL subsystems and minimize the variation in TRL prior to applying the traditional project execution approach. If we can minimize the variation in TRL we may be able to minimize the development timeframe at the project level.
- A second alternate potential solution, and one that has been demonstrated on numerous occasions more by chance than forethought, is to allow higher TRL subsystems to finish early and “sit on the shelf” until required for spacecraft integration. This is the converse approach from the staggered start solution. The staggered finish solution allows all of the subsystems to start at the same time but relieves the requirement that they finish just in time for spacecraft integration and test. In an unconstrained schedule environment, we would be able to allow all subsystems to progress at their own rate based on TRL and deliver to “the shelf” when complete.
- <Hand it over to Dewey to talk about benefits and deltas of each solution.>STAGGERED STARTS:There are several benefits to this approach. First, decoupling of the individual subsystem schedules from each other allows each the opportunity to start with an uncompressed schedule including a level of schedule reserve that is commensurate with the technical and schedule risk and significantly increases the likelihood of meeting the delivery date. When delays or potential delays occur in delivery by a subsystem, the project schedule may be impacted and the project must bear the cost of the delay. Next, when the subsystems march in unison to the next project gate they are paced by the slowest subsystem which induces inefficiency and additional costs since the marching army is being slowed by the low TRL subsystem or instrument. Finally, and most importantly, the project would have the benefit of starting out with an achievable cost and schedule baseline. Obviously, there are a significant number of additional factors that would have to be considered before utilizing this approach. For example, Interface Control Documents (ICDs) are developed to define the inputs and outputs of subsystems and to ensure that the designs of all subsystems are compatible. With a staggered start approach the design efforts on higher TRL subsystems may not have started when interface definitions may be required to continue to evolve the design of lower TRL subsystems that have started. Since the individual subsystems are not completely independent of each other, the development of subsystems would have to be monitored closely at the spacecraft level to ensure the orchestration and communication of spacecraft design parameters and interfaces are effectively managed.STAGGERED FINISHES:A major advantage of this approach may lie in our ability to freeze the designs from high heritage subsystems. What if we directed our subsystem lead engineers to build the box based on proven flight designs with as few changes as possible and then put this box aside as a flight ready spare? Based on test results from the flight spare we could then turn our attention to design changes aimed at performance improvement and build our engineering and flight models based on the modified design. If we ran into technical difficulty and lengthy delays in development we would have the flight spare to fall back on if we were unable to deliver the modified design within the projects timeframe. While on the surface this potential solution might eliminate the inefficiencies created by slowing down high TRL subsystems to meet their lower TRL counterparts, there are a number of concerns with this solution that warrant discussion. First, if we start out in a compressed schedule environment as described in paragraph 4, then the opportunity to deliver early is significantly reduced and the focus of our attention is naturally drawn to the low TRL subsystem development timeframe that may be difficult or impossible to compress. Next, there is really no such thing as high heritage. We must recognize that technology evolution is an ongoing process and, even to the extent that we may want to keep the design constant, external advancements in technology, parts, and sponsor requirements change. Even if we are able to escape external design change, we may not be able to resist the pressure for internal design change. We operate in a continuous improvement environment of spiral development (brassboard to breadboard to engineering model to flight model) and as the design matures we implement design changes that ultimately result in improved performance. If we provide engineers with proven tested designs they will evaluate the designs and attempt to improve on them. Finally, if we downsize the subsystem team and place our hardware “on the shelf” there is no guarantee that these personnel will be available for integration at the spacecraft level.