Critical Design Review - cubesat-project/CubeSat GitHub Wiki
Preparation for CDR As the name suggests, critical design review (CDR) expects that the final design of all subsystem of the CubeSat, ready for manufacturing, will be presented. In general, changes after CDR are only allowed to address mission critical issues such as a design flaw. Non-essential changes must be avoided because they will impact on schedule and cost.
- The purpose of the CDR is to demonstrate that the final detailed design will meet all requirements and is feasible within the cost and schedule constraints, and that the project is ready to proceed with the Manufacturing, and Assembly, Integration and Test (AIT) Phase.
- The objectives of the CDR are to confirm that:
- All system and operations requirements have been allocated to lower level subsystems, and the flow-down and traceability are complete.
- The final detailed design meets the system, operational, environmental, design, interface, safety and Product Assurance (PA) requirements within allocated resources and constraints;
- The detailed design has been proven and is final, and the project can proceed with Manufacturing and AIT;
- External and internal interfaces designs have been finalized, formalized and agreed with all parties involved in the system design and implementation;
- The detailed design, including interfaces, has been validated, and the verification and compliance approaches are viable and will confirm compliance with all requirements;
- The technical, cost, schedule and programmatic risks have been appropriately identified and mitigated or are on track for timely mitigation;
- The cost and schedule estimates indicate that the mission will be ready to launch and operate on time and within budget and that the control processes are adequate to ensure remaining within allocated resources; and
- Government Policies, Security and international laws Requirements are on track to be met (RF and RSSSA licensing).
| Items | Key elements for CDR |
|---|---|
| General | Documentation, especially design, analysis and ICDs are complete and have reached a high degree of stability and details; Subsystem requirements are complete and contain no TBCs and TBDs. |
| All CDR documentation need to be sent to reviewers at least 3 weeks in advance of CDR. | |
| RF and RSSSA licensing status | |
| Payload | Detailed payload design including interface definition, packaging, and test plan and any test results. |
| Systems Engineering | Final systems requirement document up to the subsystems level and unit level |
| Identification and assessment of single-point failure modes | |
| Final CubeSat Interface Control Document (ICD) that includes the power, mechanical, communications, ACS, and on-board processing subsystems | |
| The final design of all harnesses | |
| Power | The final design of the power subsystems including the inhibits, 30-minute timer, Remove Before Flight (RBF) pin, grounding diagram. |
| The power generation subsystems detailed design, including the solar cell layout and assembly procedure | |
| The power budget that demonstrates at least 20% margin for a new design, 15 % for a modified design and 7 % for an existing design | |
| The interconnect diagrams of all circuit boards | |
| Test plan and test specifications of the electrical subsystems, and any test results. | |
| Mechanical | CubeSat configuration (format, layout of subsystems, switches, antennas, deployable) is complete and demonstrate through CAD drawings |
| The final design for the deployables for the antennas and payload including dimensions, mass and test plan | |
| A mass budget that demonstrates at least 15 % margin for a new design, 12 % for a modified design and 1 % for an existing design | |
| The Bill of Material. Although metallic material is not required to be included in BOM for CubeSat of less than 5 kg, it is recommended that they are also listed. | |
| Design of MGSE (mechanical ground support equipment) | |
| Communications | The data volume for TT&C and payload operation with a 10 % margin |
| The communications protocol for uplink/downlink | |
| The link budget that demonstrates a minimum positive margin of 3 dB | |
| The ground segment design | |
| Antenna radiation pattern simulation results | |
| Communication subsystem test plan and any test results | |
| On-Board Processing | OBC final hardware configuration |
| Software development and test plan (requirements, design, structure, logic flow, language) | |
| Software development status | |
| Estimated processing load and margin (60 % margin recommended for processing, RAM and data storage capacities) | |
| Attitude Control Systems | Final ACS subsystem design, including ACS hardware suite (actuators and sensors) |
| Assessment of the performance of the proposed attitude control strategy | |
| ACS test plan | |
| Operations | The modes of operations |
| The ground operation plan of the CubeSat | |
| AIT | Design of EGSE (Electrical Ground Support Equipment) |
| Design of the flatsat that will aid in the development of flight software and the verification of operations | |
| AIT test plan | |
| Management | Delivery of second iteration of Safety Data Template and BOM to CSA/NanoRacks |
| Project status updates (Budget, schedule, HR, risks, outreach) | |
| Plan for phase D (spacecraft assembly, testing and validation) |