Detailed Design Of Subsystems With Released Drawings example essay topic

Table of Contents 1. Introduction 2. Teams and Leader Responsibilities 3. Design Components 4. Introductory Project 5.

Project Selection Process 6. Analysis Report 7. Preliminary Design Review 8. Critical Design Review 9. Final Presentation 10.

Conformity Inspection. Introduction The purpose of the detail design class is to provide a design-build-test-operate experience for the student. The requirements for the project that the students select begin with the requirement that the project have a minimum of three subsystems, chosen as a subset of the subsystems used in the project from preliminary design. In addition, it must have more than one sub-assembly; there must be a subset of the requirements that are test-able (with our campus facilities); it must undergo a vibrations test according to the requirements specified by the chosen launch vehicle; and the structure must be tested to failure.

The design component consists of detailed drawings submitted in the context of the configuration management system defined under the Design folder in the Courses drive. More detail of the design component is given in the Design Components section. The students are required to build their design. This enables them to understand the of their paper concept. It also gives them the opportunity to see if their predictions on the performance of their system are good. The build process provides an opportunity for the students to see clearly what the integration issues are in bringing the various subsystems together.

The test component requires the students to write detailed test plans and to perform them with their design prototype. The project should have various subsystem tests as well as tests at the various phases of integration and finally, a fully integrated functionality test, which shows how the system as a whole operates. The entire design must be supported by analysis based on work done in previous courses as well as on any new material they must learn for their specific design. The analysis section describes in more detail the types of specific analyses required. II.

Teams and Leader Responsibilities The teams utilize the entire class and are divided into subsystem teams and an integration team. The integration team is composed of the team leaders from each subsystem team and the project lead is the team leader for this team. Each team must also have a person responsible for all the CAD drawings. The responsibilities of the integration team, project lead, team leads and the CAD person are defined below.

Integration Team: This team is responsible for the system coming together. They must make sure that all integration issues are addressed early and are passed on to the appropriate team for resolution. They are responsible for the overall class budget and schedule (which are compiled based on the individual team budgets and schedules) and for ensuring that the overall budget and schedule are met. The integration team must maintain the class budget and schedule and is responsible for writing and maintaining interface specifications. They are also responsible for determining the absolute dead-in-the-water due dates for project milestones. The integration team and the team leaders will meet with the instructors once per week.

The team lead for integration is the project manager for the class. The integration team is responsible for ensuring that all of the assembly bills of material and drawings are complete. They are also responsible making sure that all of the links work to the drawings or bills of material that they refer to. This team is much more of a management team than a technical team, however, the team members must also be aware of the technical issues for their team. Tools used are: Catia - assembly drawings; Microsoft Project - Class schedule; Excel - Budget, all part drawings, part lists, bills of materials (most of the configuration managed items); Paint - import from Catia into Paint (or Word) and place labels, and any other documentation onto assembly drawings; Microsoft Word - requirements document, test plans, test reports. This team is also the group responsible for ensuring that the presentation comes off as a whole.

Typically, each team will create their part of the presentation, however, the presentation must flow as a single project. The integration team is responsible for making this happen. This usually means that they need the team presentations at least one day in advance of the presentation. In general, they will introduce the presentation and conclude the presentation.

This team is responsible for ensuring that the conformity inspection will go well. They do this by doing their own version of the inspection and getting any issues resolved through the teams. Changes to the design occur frequently through the design process. The integration team ensures that all of these changes are tracked and is the team that is on top of which change is the most current design. They are also responsible for making sure that the impact of any change proposed by one subsystem is understood and accommodated by the other teams. The integration team is responsible for ensuring that all of the design components are correctly documented and submitted.

This includes all test plans, requirements document, bills of material, assembly drawings, drawings, etc. Team Leader Responsibilities The team leader is responsible for maintaining the purpose and direction of the team. They must delegate tasks and maintain both the schedule for the team and negotiate the budget with the integration team. The team leader is responsible for ensuring that all of the bills of material for sub assemblies that the team is responsible for are complete; that all of the drawings are released; and that the bills of material link properly to all relevant drawings. They are also responsible for ensuring that part number requests are made in a timely manner.

This is a much more ominous task than it may sound. It takes a lot of work to be sure that it all works out properly. The team leader should be more of a manager than a designer, although, since the teams are generally small, he / she will also have general team member responsibilities. The team leader needs to assign tasks to team members and negotiate with the integration team if more or less manpower is needed. They are responsible for ensuring that their team's portion of the project is completed well. They are responsible for ensuring that each team member is given appropriate tasks.

Microsoft Project is the tool used to manage the team's schedule - milestone due dates as well as intermediate milestones to track team progress should be included. It is important to save the initial (baseline) schedule so that progress relative to your initial plan can be tracked. CAD person responsibilities: o Create all individual parts. (nuts, bolts, struts, panels, etc) o Name all parts with the corresponding drawing number. o Create assembly drawings according to bills of material and product structure tree. a. Make sub assemblies with names corresponding to the assembly drawing part number. b. Then make the main assembly referencing the sub assemblies you have created (with appropriate names.) (If you do this, Catia will generate the bills of material that you can use to create your Excel version that gets released into the configuration management library.) o To get the parts onto the Excel document drawing page, save the drawing as a pdf file and then copy it from the pdf document into the Excel document. o See Dr. Helbling or the CAD lab monitor for help. o To make the individual part drawings, they must be 2-D drawings. The help menu in Catia can help you do this.

The assembly drawings stay as 3-D drawings in general. o For 3-D models, don't save as a pdf. Instead, use the capture tool in Catia to copy and paste the image. The capture tool gives you the option to change the background to white before you copy and paste the image. This works best if you paste the image into Paint first, then save it as a jpeg file and import it into your excel file or your power point presentation from here. You can just copy and paste from paint into the destination document also.. Design Components: The components of an integrated design are the following: o Product structure tree o Requirements document o Test plans / procedures o Bills of Material (parts list) o Assembly Drawings o Parts Procurement / Fabrication Specs (individual part drawings) o Analysis document so Test reports These are drawings / documents which must be 'released', i.e. placed under configuration management.

Each of these has an important role in the design. Product structure tree: The product structure tree is a tool that shows how the product fits together. It reflects something different than a subsystem design. It represents HOW the product fits together mechanically- how it is built; which sub-assemblies must be built first and which ones can be built and tested separately before coming together to form a higher-level assembly. For example, in the project from fall 03, the product structure tree is shown below. It has two main sub-assemblies, one of which has most of the complex parts and sub-assemblies attached to it.

The assembly can proceed in stages based on this drawing. Requirements document: This is a document that must specify exactly what your product must do and how well it must do it. Each requirement must be verifiable in some way. It must be verified by a test or by analysis.

The test plan is tied to this document. There is no reason to test for anything other than what is in the requirements document. This document is an evolving document as your design becomes more refined. In the beginning, your requirements are very top-level. As you flesh out the details of your design, the top-level requirements place lower-level requirements on sub-systems and ultimately on individual parts.

This is the place where you begin your design. You must know what it has to do before you can begin to design it. Test plans: These relate directly to the requirements document, and each test procedure must relate to some specific requirement in the requirements document. All requirements must be either test-able or verifiable through analysis. Where testing is possible, it is often the preferred way to verify that the requirement is met. A template for a test plan is given below.

The main ideas are that 1) a test procedure leads to the verification of a specific requirement and 2) the test plan is written so that someone unfamiliar with your project could execute it and determine whether or not the requirement was met. In some instances this is very simple and in others, there is much post-processing of test data and analysis that must be done to show that the requirement is met. Frequently, a test procedure is written around specific test apparatus that is used to perform the test. It should have blanks where the expected information from the test will be recorded. Pass / fail criteria must be clearly stated. Bills of material.

These are essentially parts lists, required for each assembly or subassembly in the product. A bill of material (BOM) identifies each part required in the construction of the assembly or subassembly by the part's unique part number, which is the same number as its procurement / fabrication specification drawing (see below). Assembly drawings. This is a pictorial or narrative (or both) description of precisely how all the parts on a bill of material are assembled into the completed assembly.

Part procurement / fabrication specifications. These are either 1) individual part drawings that completely specify how the part is to be fabricated, with all dimensions, tolerances, material specifications, etc. or 2) a part specification used to procure the part from an external source. Each and every part used in the design must have a part procurement / fabrication specification. This leads to each and every part used in the design being assigned a part number, in addition to the document (part specification) created which specifies all relevant specifications of the part. For mechanical parts, the amount of detail required must typically be sufficient to fabricate the part. Procurement specs generated in earlier projects are available for use in later projects, e. g., fasteners, brackets, electrical components, etc.

Analysis document: This is a report that is turned in by each subsystem group and supports the design. This is the analytical base for your design. This is where you show that your design is solid based on the laws of physics and engineering practice. Your design cannot be considered viable until you have the appropriate analysis to support it.

There is a separate document defining the type of analysis required for each subsystem. Test reports: Test reports are simply filled out test procedures with the data from performing the test. The better prepared the test plan, the easier it is to produce the test report. They should indicate whether or not each requirement was met. Configuration Management: The part numbering system is described in detail in document 000-000-000. doc, which is located in the design / active documents/000-099/000 directory. This gives a list of all controlled drawing families.

Each of the "drawings" you create will get a part number from one of these families. Assignment, release, and document change procedures are described in document 000-0010-00. doc For a drawing to be released, it must be essentially complete and usable. Dr. Lyall reviews these for release. Once it is released, a change order must be filed if any change is to be made.

In industry, there is a change board that reviews all changes to be sure that the changes will not adversely affect any other subsystem or subassembly within the complex product (spacecraft). IV. Introductory Project This project is meant to teach the design process on a very simple project. It requires the student to go through all of the design steps discussed in the previous section on a simple project. It should take about two weeks to complete. The assignment statement follows: The project is to design a portion of your structure from last semester.

Your design must include at least 2 sub-assemblies. Since you only have 2 weeks for this entire design process, you must keep it simple. You must identify a load requirement with a safety factor of 2 that you can test to failure. This means you must define what failure is and how you will detect when failure has occurred. It must be made of the sheet metal and / or any other material available in the machine shop and use fasteners and / or any other hardware that is readily available in the machine shop.

You will be in teams of 2 (or 3) people. This will mirror most of the steps that you will do on your spacecraft design. These steps are outlined below. 1.) Develop a preliminary design of the structure (or part thereof). This includes the drawings of the parts of the structure, definition of the sub-assemblies and the product structure tree.

Present this to the class on the second day of class. (10 minute presentation, maximum) This presentation should include the product structure tree, the preliminary drawings and the analysis to support the functionality of the design, for the requirements derived in prelim. 2.) Create a product structure tree. This process helps you to think about how you will build your structure. 3.) Write a requirements document (along the lines of the other 004 documents). The main requirement for this exercise is for your structure to meet the maximum static load requirement from last semester.

You will use your requirements from last semester to guide you in making this document more specific. This document only pertains to the part you are building - not the entire spacecraft. 4.) Write a test plan which (1) rigorously and exhaustively verifies hardware performance against the test plan and (2) provides for load limit tests which allow determination of the loading required to fail the structure and determine the actual factor of safety. 5.) Do all relevant analyses and produce an analysis report (this should be no more than one page.) Do a preliminary analysis to size your parts.

There is a presentation by professor Helbling available in the class folder with information on how to do this. This should be done by the third class period. 6.) Develop a set of detailed CAD drawings for your structure - these should include all separate part drawings (fabrication drawings or procurement specifications), assembly drawings and procedures. You may use any of the fastener drawings that already exist (nuts, bolts, rivets, etc. ).

Assembly instructions should require only simple tools, no machining operations (drilling or cutting). Each individual part must have its own separate drawing and be in a separate file and be assigned its own part number. This should be done for preliminary review by the third class period. 7.) Create all relevant bills of materials. We will talk about part number assignments and bills of materials on the second day of class. 8.) Build your design according to the fabrication specifications, assembly drawings and product structure tree.

9.) We will do a preliminary conformity inspection on the design you built on the fourth class period at the beginning of class. The conformity inspection answers three questions: (1) Has the test article been built according to current released documents? (2) Does the test plan exhaustively verify performance against the requirements? (3) At this time, we should have in hand a folder that contains your design documentation. (See below for detailed deliverable's.) Keep in mind that while for this project, you will turn in paper documentation, on the main project, you will not turn in any paper drawings - they will all be electronic. 10.) After we have completed the preliminary conformity inspection, test the structure you built to failure, using the test plan you created, and write a test report.

From this, determine your actual factor of safety. This is due at the end of class on the fifth class period. This will allow the conformity inspection to be completed with the answer to the third question: Has the test article been subjected to all procedures in the test plan? Final Design Package should consist of the following: Product structure tree Requirements document Test plans Analysis document " Released drawings " Test reports. Project Selection Process This is the process I have used in the past to help the class come to a consensus on the class project. 1) Count off by 3's to create 3 new teams, each containing members from all of the prelim teams.

2) Each team will review all the de-scope designs from last semester and may modify, combine or change anything they like, but will present a de-scope design proposal to the class at the beginning of the following class period (15 minutes per team). 3) Focus on defining: a. Requirements. Subsystems definition and responsibilities c. Integration. Budget.

Preliminary product structure tree. Final demonstration 4) After presentations we will have some discussion of the relative merits if there is time. 5) If a consensus cannot be reached during class, each person must rank the three presentations and e-mail me your ranking by the end of class. 6) On the following class period, we will: a. Present the results of the ranking and the common themes b. Discuss the results.

Come to a consensus on the project. Each person will give the instructors their 1st, 2nd and 3rd choices for subsystems. VI. Analysis Report This document should show in detail all of your analysis that supports your design.

These are the areas of analysis and each individual will be doing some part of what is expressed in the document. The team leader is responsible for ensuring that all of the relevant analyses get done. In most cases, this process will be iterative. These analyses will need to be done several times as your design changes to better meet your system's requirements.

It is often helpful to set up computer tools to easily facilitate changes. Each section outlines the types of analyses required. The list is NOT exhaustive. You will need to do whatever analysis if relevant for your project. 1.1. Structures and Mechanisms It is important to note that this design process is iterative. You often will make some assumptions about the structure, then work to improve an area while keeping the spacecraft from buckling, minimizing weight and keeping the natural frequencies in the acceptable range. 1.1.

1. Placement of subsystems - determine mass properties. i. e., center of mass and the inertia matrix about the center of mass. This should also indicate placement of all parts in the chosen coordinate frame. The principal axes should be determined and the angular offset from nominal should be found. The center of mass offset from the axis of interest should also be shown. 1.1. 2.

Coordinate drawings of the different configurations for all mission phases. Mass properties for the different phases should also be calculated. 1.1. 3. Do preliminary analysis to size your structural elements.

This should include: o Start by assuming a truss structure and estimate the force on each member. You will need to apply a load at points based on where your launch vehicle mates with your structure. o Calculate the buckling load for each member and the static strength. o Compare your estimated loading to the buckling load and to the yield strength to determine preliminary sizes for materials. Your analysis should show that the materials you selected meet the requirements. You should also show margins of safety for ultimate, yield and buckling. Factors of safety should be reasonable for the industry. o Fasteners: Estimate shear and bearing strength of the fastener (and tensile strength if applicable) as well as bearing and shear out of the fastened material. Hand calculations for this will help you with sizing and spacing of fasteners. 1.1.

4. Analysis that shows that the mechanisms and deployment meet the requirements. 1.1. 5. More advanced structural analysis - ANSYS modeling (Static and dynamic modeling) This should include: o Constraining your ANSYS model at the points where your model is attached to the launch vehicle. o Getting the reaction force at each attach point to design for bolt sizing o Applying launch loads in both vertical and lateral directions.

The direction for the load in the lateral direction will have to be chosen to give the worst case stresses o Check all attach point stresses for sizing of fasteners'o Look at effective stress over entire structure and compare to yield conditions (this is a function of your material properties) o Show that the effective stress does not exceed the allowable stress at any point on the structure. Allowable stress should be yield stress / factor of safety. o Calculate the buckling load and compare this to the forces on points on the structure where buckling is a concern Use ANSYS to refine your design to get the minimum weight structure. This most often occurs when the stress is equally distributed throughout the structure. o Determine the natural frequencies of your structure and show that they are outside of the range that the launch vehicle will be driving your structure 1.2. Propulsion 1.2.

1. Given V calculations - size your propulsion system. o Nozzle so Tank size - Your analysis should show that the shape, size, thickness and material are adequate to handle the chosen pressure. o Tank mas so Piping, valves, regulators and any other masses 1.2. 2. Some of the expected calculations: o Mass flow rate Thrust and Isp both on the ground and in space Burn time (expected, min, max, # cycles for engine) o Chamber pressure o Pressurant tank pressure (if applicable) o Propellant tank pressure 1.2. 3.

Other possible information Analysis on how expected thermal variation affect your system Analysis that shows how the launch vehicle's vibration and g-loading will affect your system. This may be done with ANSYS. 1.3. Attitude 1.3. 1. Determine the attitude requirements for each phase of the mission. 1.3. 2.

Determine the nominal attitude for each phase of the mission 1.3. 3. Estimates of all environmental torques during all phases of the mission. 1.3. 4.

Analysis of the pointing error due to the expected disturbance torques. 1.3. 5. Simulate any complex attitude environments that cannot be captured by hand calculations. 1.4. Power 1.4.

1. Tabulate all the power requirements from each element that draws power on the spacecraft, the efficiency of the conversion for each element, and the operating voltage for each element. For each subsystem, you need to identify both peak and average power. In general, you need to describe or define the operation characteristics.

This means that if you have a single time use of power, say for a deployment, then you need to specify this. If you have a load that is operating all the time, that needs to be specified. If you have a load that operates intermittently, its operations characteristics must be defined and described. 1.4. 2.

Size the power system (solar panels / secondary batteries, primary battery or whatever power source you are using). This should include the detailed eclipse analysis that drives your panel and battery sizing. 1.4. 3. Show that the selected battery technology will support the peak power (current) requirements. 1.4. 4.

Maintain a power budget that accounts for information in 1.4. 1 with adequate margin. 1.5. Thermal 1.5. 1. The thermal energy for each energy producing element should be tabulated 1.5. 2.

The operating range for each item on the spacecraft must be tabulated. 1.5. 3. Calculate the steady-state average temperature of the spacecraft during all phases of the mission. 1.5. 4. Where applicable, calculate the temperature gradient through the spacecraft (like we did for the solar panels in Space Systems). 1.5. 5.

Define thermal control devices, fully supported by the above analysis. 1.5. 6. If possible, determine any hot or cold spots on the spacecraft. 1.5. 7.

Do a detailed simulation of the temperature distribution based on all sources and sinks. 1.6. Communications 1.6. 1. Size the antenna - both receive and transmit. Determine the gains and create a link budget. 1.6. 2.

Determine all transmitters and receivers. 1.6. 3. Determine the power requirements for the communications system. 1.7. Orbits 1.7. 1. First order analysis of the vs. necessary for achieving your orbits (Like in the Sellers book) (NOTE: for any secondary payload you will need to get creative to estimate this) 1.7.

2. Run a simulation on all the burns with the thrust level provided by the propulsion person to determine the final velocity vector and trajectory after each burn. Utilize this to come up with a better estimate of the fuel needed. There will be a discrepancy from your initial numbers due to 'gravity loss'. This is done in conjunction with the propulsion specialist. (I think Dr. Sie bold has given you MATLAB practice for this) 1.7.

3. A more detailed analysis will eventually be asked for depending on the type of mission you are choosing (See BMW, Val lado and other texts). 1.7. 4. Landing requires a gross estimate of the vs. and some kind of simulation when you have a propulsion system to make sure you can actually slow yourself with the given thrust. 1.7.

5. For aerobraking or aero capture maneuvers, you will be expected to make a simulation of the event (s) and the forces that occur during those events. The structures must be able to withstand this force. Calculate depth into atmosphere you must go. If this is applicable it will require some extra research. 1.7. 6.

Eclipse time 1.7. 7. Midcourse corrections / maneuvers if that is part of your mission 1.7. 8. Appropriate earth observing and communication geometry and time information 1.7. 9.

Orbit maintenance V estimates and calculations 1.7. 10. Launch window estimation and calculations 1.7. 11. Orbit simulation and ground tracks as appropriate (STK) VII. Preliminary Design Review The purpose of the preliminary design review is to show that the design makes sense and is do-able.

Serious design flaws or issues should be identified at this point. It is meant to be a design review in which your design is critiqued and probed for flaws. This should only make your design stronger. The following outlines the content and format for the review. Each group will have 20 minutes to present. The PDR begins with a presentation described below.

Each presentation group must provide 3 hard copies of the presentation, formatted 6 to a page, with black text on a white background. In addition, each subassembly team must provide a hard copy of the list of deliverable's to the instructor (s) at the beginning of the PDR presentation. The format for the design review follows. The groups presenting will be: 1) the team from prelim whose design was selected; 2) the integration team; 3) each of the individual teams selected for detail. Prelim design team: o Review of the design requirements and solution from prelim o Review of the scope of the project for AE 445 Integration team: o Product structure diagram o Preliminary top-level requirement so Preliminary system test plan so Preliminary sketch of the system, identifying clearly each subassembly o Configuration management procedures (presented by the person in charge of configuration management control) Each individual team will present: o Product structure diagram for your sub assembly o Preliminary subassembly requirement so Preliminary test plan so Preliminary subassembly design, with drawing so Preliminary analysis that supports your design Preliminary interface specification so Schedule and budget for the semester (the schedule should include at the very least the milestones given at the beginning of the semester) o Your contract with us specifying what you will provide by the end of the semester The contract that you will provide by the end of the semester is your contract with the instructors for the class. These items in the list are called DELIVERABLES.

From a work environment point of view, these would be the items a customer would expect to receive by a certain date in the project. Often times these deliverable's correspond with a payment from the customer. In your case, the deliverable corresponds to part of your grade in the course. The deliverable's required are a relevant subset of the following, and should identify any specifics regarding the item that you have to date. The clearer you are on what comprises these deliverable's, the more clear your goals in the class will be and the more likely you will be to achieve them. So be as specific and clear as possible at this stage.

Your list of deliverable's will include all items with an symbol by them. Other items may or may not be required for your design - this is something your team will need to assess. Also, because all designs are different, there may be an item in this list that is lacking. In this case, if it pertains to YOUR design, you will need to include any additional deliverable's that are relevant. o Product specification for the entire system. This will be a multi-tiered specification. o Product specification for each subsystem and sub-subsystems, etc (requirements document). This will fit into the same document containing the system level specifications (as in the example document). o Acceptance Test Procedures - list the tests that comprise these Environmental Tests that would be required for an operational spacecraft.

These would be done to test all of the expected environments your system will encounter - from the original design. They may include thermal, vibration, dust, etc., or whatever else that is part of the environment that may affect your design. - Identify all environmental tests that you think would apply, independent of whether they can be done in this class. Then put an asterisk next to any that you think are feasible for this class. o A Bill of Materials and cost data. o Parts procurement specification. o Assembly procedures and drawings - Identify any of these you can at this stage. o Acceptance / Qualification test report / results. o Engineering prototype so Work schedule (Gantt Chart) o Budget: engineering costs (tracking and projecting of hours) as well as prototype materials costs After the presentation, the design team and the reviewers enter into a discussion wherein agreement is reached with regard to 1.

The feasibility of the technical approach. 2. The viability of the project schedule and budget Any shortcomings in the above (i. e., lack of agreement or something that needs to be further thought through) will be noted and written feedback, in the form of action items, will be given to the appropriate parties. The PDR milestone is not to be considered met until all action items are resolved. The end result of the PDR will be a document containing the final, agreed upon list of deliverable's and the resolution of any Action Items resulting from the discussion following the presentation. Successful completion of the PDR means that you are ready to begin your detailed design.

Integration Review: Tuesday, Jan 28, 2003 The integration group will present the following in the class period following the PDR presentations. This is because after the presentations by all the groups, integration issues will surface. The integration group will have until the next class period to incorporate these issues from the PDR into the system design. Their presentation will consist of: o Refined system level requirement so System integration requirement so Overall budget for the class Identification of common subsystem areas where integration issues must be resolved (a list) Identification of integration committees that will be required to address the above issues V. Critical Design Review This review should take place at a point where approximately 60% of the time allotted has passed. Performance against the published project schedule is evaluated, and a judgment is made as to whether the schedule remains viable or if adjustments must be made. Test plans / procedures are to be reviewed to verify that they are sufficient to determine compliance with the requirement document.

A functional demonstration of any mock-ups created to assist in the design is often appropriate at this juncture. A review of your drawings and analysis that supports your design is also part of this review. In this review, you are showing that you have done all of the analysis that supports your design. Remember, believing your design will work is not adequate - you must show that it will work to the requirements, preferably without over-design. If your CDR is perfect, you will be ready to start to build your prototype according to your released drawings. If your analysis does not support your design, you will be required to resolve any issues before you proceed.

Logical reasoning should support all of your design choices. This reasoning is what you will present in your presentation. Since the objective of the review is to see if your design is ready to enter the build phase, you will be required to resolve any issues that come up during the review prior to beginning the build phase of your project. The type of issues that may arise may be with scheduling, test plans, requirements, documentation, released documents, product structure, analysis, etc. You should have all of your drawings released at this point to enable you to be ready to begin the build phase. If they require changes as a result of the CDR, change orders must be filed.

However, drawings that are ready to go after the CDR can proceed immediately into the build phase. For the CDR, you will present each of the items below. I. Detailed design a. Final subsystem specifications (requirements document) (tied in to your test plan) and test plans. This should clearly show what your project must do and how you will show that it will meet that requirement. You should present these together to show how they are related. b. An overview of your design solution and analyses that support the design. c.

Detailed design of subsystems with released drawings (See Note 1 Below). You should be able to walk the reviewers through your design using the product structure tree, bills of materials, assembly drawings and part drawings that are in the Design folder. This can be done on any networked computer. Because of this, all of the drawings must be pasted into Excel (no Catia documents). i. Bills of material (See Note 2 Below) ii. Procurement / fabrication specifications (part drawings) for all parts appearing on bills of material.

Assembly drawings (made with Catia, but pasted into Excel) and / or assembly instructions d. Identification of special handling and fabrication procedures e. Cost and schedule The items below, if not yet completed, should be shown clearly in your schedule. II.

Design validation a. Completion of build and integration b. Completion of test hardware and software c. Subsystem test and evaluation reports with expected performance value sd. System level test and evaluation reports with expected performance values Any omissions or inconsistencies in the documentation will be noted as Action Items and given in writing to the appropriate party. The CDR milestone is not considered met until all action items are resolved, and essentially all drawings relevant to the construction / production of the product are released.

Note 1: To 'release' a drawing or specification means that it has been signed off by the project engineer as 'Revision Zero' and henceforth comes under configuration management. Implicit in the sign off is the conviction on the part of the project engineer that the drawing is essentially complete, correct, and useable. Any changes made to drawings after release must be accomplished through the Engineering Change Order (ECO) process, and the revision designator increased accordingly. ECO's should be numbered sequentially, dated, reviewed, approved, executed, and filed. A single ECO can implement changes to several drawings / documents. Each change should be described in detail as to the 'before' and 'after' configurations.

Note 2: It is the responsibility of the integration team to 1) present the product structure tree for the entire system, clearly showing the order of assembly of each major subassembly, as well as the final assembly (complete spacecraft), 2) show how each bill of material fits into the product structure tree, clearly identifying the group or individual engineer responsible for each bill of material and (3) present assembly drawings at the system level, and / or at any major sub-assembly level. IX. Final Presentation This is the final presentation for the semester. It should show the culmination of all of your effort throughout the semester. The audience you will be presenting to will be a general audience, however, there will be a panel (just like in Prelim) that will be asking questions when you are through. The presentation should take no more than 45 minutes and there will be an additional 15 minutes of questions from the panel and the audience.

The review should flow in this order: Integration team should present the project by giving the background on where the project came from (prelim) and carefully and clearly transition to how the prelim project was scaled down for detail. Be sure to be very clear about how and why you chose what you chose. The purpose of this is to help the audience see how this simplified project is related to the bigger project and to space. The integration team needs to present the top-level requirements and top-level test plans that validate the requirements. The integration team needs to introduce the product structure tree and the sub-assemblies so that the audience can see how it all fits together. Pictures are critical here.

The integration team will present 1) the product structure tree for the entire system, clearly showing the order of assembly of each major subassembly, as well as the final assembly (complete spacecraft), 2) how each bill of material fits into the product structure tree, clearly identifying the group or individual engineer responsible for each bill of material and (3) assembly drawings at the system level, and / or at any major sub-assembly level. For the presentation, each team will address each of the items below.. Detailed design a. You should present the requirements and test plans together to show how they are related. b. Because of this, all of the drawings must be pasted into Excel (no Catia documents). Show here some important drawings, not all of the drawings, just key ones that the audience can see how the drawing fits into the project. i.

Bills of material ii. Cost and schedule IV. Design validation a. Discussion of build and integration process. Discussion of test hardware and software c. Subsystem test and evaluation reports compared against expected performance value sd.

System level test and evaluation reports compared against expected performance value se. Demonstration of project functionality f. Lessons learned Presentation on Design Process and Analysis: In this part of the presentation, you are showing that you have done all of the analysis that supports your design. This reasoning is what you will present in your presentation. X. Conformity Inspection This represents completion of the project. The following will be examined for conformity: o All deliverable's specified in the PDR Minutes are to be accounted for. o Prototype hardware is to be examined to determine conformity with current revision documentation. This is entirely based on released documentation.

If the drawing is not released, there will be nothing for us to compare to. o Test reports are to be examined to verify equipment performance consistent with the project specification. o Documentation is to be examined for consistency with the established configuration management system. In order to pass the conformity inspection one hundred percent, the inspected hardware must (1) be built according to current revision engineering drawings, (2) be tested according to current revision test procedures, and (3) the test procedures must thoroughly and rigorously verify performance against the project specification. In the event that the hardware did not pass the tests, a recovery plan should be presented to address the deficiencies uncovered.