Design Review Flow

Description of Proposal

Probably the most important things to read are the bullet points under each design review labelled “How this might look for us specifically”

This proposal contains my thoughts for the “flow” of design reviews might be, along the road to spaceshot. I think we need to carefully consider tradeoffs related to these design reviews. Hosting a design review can be a very useful tool to check our work with external parties, to get advice, and to make sure we aren’t heading in the wrong direction. Consider our High Mach ‘PDR’: we didn’t really have external reviewers, and as a result, we kept working in the wrong direction, wasting a lot of time and effort. On the other hand, preparing for a design review takes time away from working on the vehicle itself. Also, we ask external reviewers to dedicate time to our project, so we need to make sure we’re valuing their time.

The takeaway from this is that design reviews are an incredibly useful tool we have in our design process, but if we want to hold one, we need to make sure we’re taking advantage of it, and not wasting our time or the time of the reviewers. With this in mind, here is my conception of how we might incorporate design reviews into our process.

Each design review will have external reviewers, and we’ll need to make a slide deck and accompanying report for it. Very roughly speaking, these might occur semesterly. Finally, particularly with the reviews further in the future, these specific guidelines should and will change as we learn more.

System Requirements Review and Conceptual Design Review (SRR/ConDR)

This is two reviews combined into one, though this pair is a pretty typical one to do that. In a sentence, the SRR ensures that our requirements for the project are reasonable, appropriate, and achievable, while the ConDR explains our preliminary design, and shows that it is capable of satisfying the requirements.

Typical objectives for this stage:

• examines the functional requirements and performance requirements defined for the system and the project plan

• ensures that the requirements and the selected concept will satisfy the mission

• examines the proposed requirements, the mission architecture, and the flow down to all functional elements of the mission to ensure that the overall concept is complete, feasible, and consistent with available resources

• examines the proposed system architecture and design and the flow down to all functional elements of the system

How this might look for us specifically:

• Have requirements to the level of each subsystem, traceable from stakeholder requirements

  • I’m not sure what level of detail here is most appropriate; this is a good point to discuss

  • In the SRR I was a part of this summer, we went through each stakeholder requirement in detail, and how each of them flowed down to the top level requirements, but no deeper

  • We can also distribute a packet with more requirements than we’d have in the slide deck, so attendees and dig deeper if they want

• Preliminary subsystem feasibility and performance analyses; ‘first-order'-ish

• Have a sized rocket, including approximate dimensions and materials. Possibly two or three candidate designs?

  • Justification and methodology for sizing

• Have subsystem implementations approximately defined, though unmade decisions are allowable at this point

  • Bring each candidate we considered, along with what we think is most optimal, and the process by which we reached that conclusion

  • Some sort of technology readiness rating would be a nice addition for each subsystem, so reviewers can understand how confident we are in each area and focus on ones that we need tips on

• Should have research comparing our vehicle to others (collegiate teams and professional sounding rockets); meaningful differences and information gleaned, with subsystem-level resolution

• Need a CONOPS for the vehicle as a whole, plus relevant subsystems, like avionics

  • How exactly would this look (in the slides, in the report)?

• Have a plan for the launch site, transportation, waivers, insurance, etc.

Preliminary Design Review (PDR)

Typical objectives for this stage:

• demonstrates that the preliminary design meets all system requirements with acceptable risk and within the cost and schedule constraints

• shows that the correct design options have been selected, interfaces have been identified, and verification methods have been described

• ensures that all system requirements have been validated, allocated, the requirements are complete, and the flowdown is adequate to verify system performance

• shows that the proposed design is expected to meet the functional and performance requirements

• shows sufficient maturity in the proposed design approach to proceed to detailed design

• shows that the design is verifiable and that the risks have been identified, characterized, and mitigated where appropriate

How this might look for us specifically:

• Any highly complex, difficult, or unconventional manufacturing methods need to have been trialed

• Shouldn’t have any large design questions remaining; small design questions are fine

  • What qualifies as a “large” or “small” design question should be discussed, but my opinion is that the threshold is whether or not the outcome of the decision meaningfully affects other subsystems. For example:

    • Say payload has not chosen the model of camera, or the way that power will be distributed to them in the payload bay, but that doesn’t affect anyone else, so it’d be a “small” design question (and, in this plan, acceptable to have unanswered at PDR).

    • However, if it hasn’t been decided how we’re going to spin up the rocket (either canted fins or a helical rail), that affects structures, manufacturing, and sims at least, so that’d be a “large” design question, and again, in this plan, one we should have nailed down by PDR.

• Verify proper and complete flow-down of requirements from subsystem level (from SRR) to components

• Higher-fidelity analyses that show the system will meet requirements; identify deficiencies

• Need full CAD for every subsystem, and integrated into full rocket CAD

• Identify highest-risk areas (especially technical, but also budget and timeline); discuss risk mitigation

• Should discuss schedule

• Address manufacturability and raw material acquisition (cost and time), plus acquisition timelines for e.g. the avionics boards

• Verify action items from SRR/ConDR have been addressed

Critical Design Review (CDR)

Typical objectives for this stage:

• demonstrates that the maturity of the design is appropriate to support proceeding with full-scale fabrication, assembly, integration, and test

• determines that the technical effort is on track to complete the flight and ground system development and mission operations, meeting mission performance requirements within the identified cost and schedule constraints

• ensures that the "build-to" baseline contains detailed hardware and software specifications that can meet functional and performance requirements

• ensures that the design has been satisfactorily audited by production, verification, operations, and other specialty engineering organizations

• ensures that the production processes and controls are sufficient to proceed to the fabrication stage

• establishes that planned Quality Assurance (QA) activities will establish perceptive verification and screening processes for producing a quality product

• verifies that the final design fulfills the specifications established at PDR

How this might look for us specifically:

• Should be held before purchase of any particularly expensive raw materials to be manufactured

• Verify each subsystem meets requirements, and whole rocket system does as well; discuss changes in requirements since PDR (should be minor)

• Higher-fidelity analyses that show the system will meet requirements; identify deficiencies

• Identify highest-risk areas (especially technical, but also budget and timeline); discuss risk mitigation

• Discuss regulatory, launch site, transportation, legal, etc. concerns. Are we on track? What have we completed so far, and what’s the plan for getting everything done on time?

• Verify action items from PDR have been addressed

Flight Readiness Review (FRR)

I see this as being held before flights out to the launch site need to be booked, but when exactly this is best to be held obviously doesn’t need to be decided now.

Typical objectives for this stage:

• verifies the completeness of the specific end products in relation to their expected maturity level and assesses compliance to stakeholder expectations

• examines the system, its end products and documentation, and test data and analyses that support verification

• examines the actual system characteristics and the procedures used in the system or end product's operation

• confirms that the system is operationally and logistically supported in a satisfactory manner considering all modes of operation and support (normal, contingency, and unplanned)

• establishes that the training function is in place and has demonstrated capability to support all aspects of system preparation, operation, and recovery

• examines tests, demonstrations, analyses, and audits that determine the system's readiness for a safe and successful flight

• ensures that all flight and ground hardware, software, personnel, procedures, and documentation represent the system configuration and its planned modes of operation, and are operationally ready

• receives certification that flight operations can safely proceed with acceptable risk

• confirms that the system and support elements are properly configured and ready for launch

• establishes that all interfaces are compatible and function as expected

• establishes that the system state supports a launch "go" decision based on go/no-go criteria

How this might look like for us specifically:

• Failure mode analysis: highest-fidelity analysis from simulations giving likelihood of e.g. mission success, recovery downrange distance, successful abort, loss of vehicle, etc.

  • Supplemented by analyses from other subteams, such as recovery, avionics, etc.

• Review test data (motor test fires, subscale flights, AV/REC testing, etc.); discuss implications for the launch

• Discuss Go/No Go criteria; we must have mechanisms in place whereby at multiple points in the process, there are hard criteria that must be met to continue; i.e. at launch day, if the wind is greater than X mph, we cannot launch, and that decision cannot be overruled. Examples of points in time where these criteria might be evaluated include the day/hour of launch, the day we leave for the launch site from Purdue, etc.

• Review checklists/procedures for launch, including contingencies

• Verify action items from CDR have been addressed

Pros and Cons of Implementing the Proposal

Purpose of Proposal

To maximize each design review we hold, and to make sure they’re worth the time and effort we invest into them, we should make the objectives for each design review clear to the entire team.

Plan for Action

Leads should read this proposal, especially the SRR/ConDR section, and the sections labelled “How this might look like for us specifically”. We will discuss this at a leads meeting, likely on 10/23, and vote. Once the objectives for SRR/ConDR are established, leads can consider how they’ll accomplish what they need to by the design review, and they can communicate the objectives to the members of their teams.