eng3162 year 3 group design project student handout 2013-14

ENG3162 Year 3 Group Design Project 26/09/2013

Year 3 Group Design Project (ENG3162)

Student Handout

Overview of the Year 3 Group Design Project

The year 3 group design project (module ENG3162) is a 30 credit module for the Mechanical, Medical and Aerospace Engineering BEng and MEng students. It is timetabled from week 1 to 11 of semester 1 and from week 1 to 8 of semester 2. During the 19 weeks, each student is expected to spend 300 hours on the project, which is approximately 16 hours per week. ENG3162 is a group based design project. Each group is a team of 6 to 8 students for a Mechanical and Medical project and 10 to 12 student for an Aerospace project.

At the start of the year 3 group design project, each team will be allocated a project and assigned an academic staff as a supervisor. The design project and the number of students allocated to each team may not be the same but the amount of work required from each student is expected to be the same. The working load of each team and individual student will be monitored by the supervisor. In the case where there is a (are) student(s) who drop(s) out after the design team is formed, the supervisor will adjust the working load accordingly to make sure both the team and individuals are not overloaded.

The year 3 group design project is a team based project. It requires effort and contribution from all team members. The marking scheme of this module has been designed to prevent any individual to take advantages from other students’ hard work and to pass the module without acceptable amount of work and contribution.

All students should be aware that the year 3 group design project is not the only module of the year. Therefore, balancing the workload and time between modules is an important personal management skill that students should learn. Should team be under unbearable workload that might affect individual performance of the other modules, the team or individual student should communicate with the team supervisor at the earliest point. This allows the team supervisor to make an appropriate adjustment on the team’s workload.

Road-map of the Year 3 Group Design Project

1. Start of the project

In the first week, each team will be issued a “Customer Design Brief” (CDB) which can be obtained either from the team supervisor or downloaded from SurreyLearn. After receiving the CDB, a meeting will be arranged for each team with its project customer who will provide more background information and details of the project. Throughout the project, each team should maintain good communication with the customer. If necessary, further meetings could be arranged with the customer at various stages of the design process. A brief guide of design can be found in Appendix I.

2. Three main stages and submissions

Throughout the design project, each design team takes full responsibility to produce the most appropriate design to meet the requirement laid down by the CDB and other requirements specified by the customer, relevant industrial, national and international standards and other regulations if applicable.

The design project can be normally divided into three stages: 1) producing Product Design Specification (PDS) and 2) preparation of the Preliminary Design Review data pack (PDR) in semester 1, and 3) preparation of the Critical Design Review data pack (CDR) in semester 2. At the end of each stage, the design team is required to submit appropriate documents. The submission deadlines depend on the project assigned to you. They can be found in the Appendix II.


In general, the PDR and CDR should demonstrate that sound engineering approaches are implemented and the proposed solution must be feasible and fully justified in terms of engineering sciences. The format of the PDR and CDR depends on the project assigned to you. Its detail can be found in the Appendix III, IV and V.

After each submission, there will be a technical review and assessment meeting. The team supervisor will go through the submitted document with the team or each individual team member to provide comments and feedback, and carry out assessment.

Each team member is recommended to keep a logbook which is used to track the project work during the review meetings and to record information gathered during project.

3. Project meetings

According to the timetable, the design team holds a formal meeting each week. The formal meetings are attended by the team supervisor who will be monitoring the progress of the project and provide academic advice. In addition, the design team should hold one or more informal meeting(s) each week. The time and location need to be arranged by the team.

As part of the teaching and learning practice, each team member has an opportunity to take the role of chairing the meeting or acting as the secretary of the meetings. The chair-person should prepare and distribute the meeting agenda before the meeting. The secretary is responsible for producing and distributing the minutes after each meeting in a timescale indicated by the chair-person.

Over a period of two semesters, all the team members should be able to take the roles at least once. The design team is responsible for making a plan of who does what and when on the first project meeting. The recommended format of Agenda and Minutes for the project meeting can be found in the Appendix VI and VII.

4. Oral presentation of the project

In addition to the submission of the data packs, each team is required to make an oral presentation to students and academic staff at the end of the project in semester 2. The oral presentation is PowerPoint based one with maximum 20 minutes being allocated to an Aerospace team and 15 minutes being allocated to the other team. There is a 10 minute discussion after each presentation.

The aim of the presentation is to convince the audience that the proposed solution is the best available design from the design team. Each team member is required to make a visible contribution to the presentation. A PC and data projector will be available for the oral presentation. The PowerPoint file(s) must be saved on an USB memory stick. The presentation time and room location will be issued with the semester 2 timetable. The presentation slot for each team will be sent to you and uploaded to SurreyLearn before the end of week 6 (semester 2).

Assessment and Marking Scheme

The assessment of the year 3 group design project is carried out continuously from the design specification to the oral presentation. The mark awarded to each student is divided into two parts: individual mark and group mark. 20% group mark is awarded for the PDS submission and oral presentation. 80% individual mark is awarded for the PDR and CDR data pack submissions. The Marking Guidelines can be found in Appendix VIII. The percentage of each part is shown below:

Design Specifications (PDS) is awarded to the group

Presentation format and clarity 5marks Engineering contents 5marks Engineering methodology 5marks Total PDS mark 15 marks Late submission penalty up to 15 marks


PDR and CDR are awarded to an individual student

Project management skill PDR 7 marks / CDR 9marks Communications and team work PDR 7 marks / CDR 9marks Comprehension PDR 7 marks / CDR 9marks Creativity PDR 7 marks / CDR 9marks Technical achievement PDR 7 marks / CDR 9marks Total marks PDR 35marks / CDR 45marks Late submission penalty up to full marks each data pack

Oral Presentation is awarded to the group

Clarity and quality of oral and visual presentation 1 marks Quality of the engineering solution presented 2 marks Response to questions 2 marks Total 5 marks

The PDS and oral presentation will be marked in terms of the whole team performance. The PDS mark will be awarded by the supervisor and the oral presentation mark will be taken from average mark awarded by the academics attending the oral presentation.

The PDR and CDR marks are awarded individual student by the supervisor. The individual student marks are based on the observations of the supervisor during the team meetings, data pack review meeting and the peer assessment form submitted by the team members.

It should be note that the peer assessment form is an indicative instrument of measuring the performance of an individual student. The team supervisor can normally apply up to +/- 2% moderation marks to an individual student, provided the peer assessment form from the team reflected the true performance of each individual student appropriately.

A second marker scheme is implemented for the assessment of the PDR and CDR. This is to make sure that the marks awarded by the supervisor meet the academic standard. The second marker will only assess the PDR and CDR as a whole. If there is more than 5% difference between the mark awarded by the second marker and the average individual mark (awarded by the team supervisor) of the whole team, moderation will be carried out.

The assessment of the engineering contribution focuses on the student’s innovation and creativity, ability and skill at applying engineering science, and thoroughness of exploration of engineering problems during the course of the project. The assessment of the project management includes performance such as acting as a chairperson and secretary of the formal and informal meetings, punctuality and quality of the agreed deliverables, general team working skills, communication and engagement.

All the timetabled project meetings must be treated with the same importance as a written exam. The attendance should be recorded by the chairperson of the meeting and reported to the supervisor. It will be used as part of the individual performance assessment. The university late submission rules apply to all unjustified late submissions.

Reporting an issue during the project

From time to time, there are various issues may arise during the project. The team and/or an individual student are advised to report any issue concerning the performance of the group as early as possible to their supervisor(s).


For example, if a team member does not attend the team activities for more than a week, it should be reported to the team supervisor who will be finding out the reasons. If necessary, the team supervisor will adjust the working load accordingly in a case of there is a potential of student drop-out.

Reporting an issue can be done orally during the group formal meeting (in this case, it should be recorded by the Minutes of the meeting) or individually to the group supervisor via email. For email communications with group supervisors, the team or individual student may copy the email to the module coordinator for information or further action if it is necessary.

If a student wishes to report a personal issue, such as extenuating circumstances, he or she should also inform his/her personal tutor and program director and submit a form to the TSO if the circumstances effect assessment.

If you need further help please contact the module coordinator (Dr W Xu, 01483 682368, 14AA03,

[email protected]).


Appendix I: A brief guide of design

Introduction

Probably the most important thing to remember about design is that each decision has consequences

and if the design team does not understand what the consequences will be you could be heading for

trouble. So get informed. Try to understand the design problem. From the very start, the team should

try to gather as much relevant information as possible from the various available resources and by

doing calculations. Another thing to remember is that the whole process is continuous and iterative.

The design team generally starts by trying to understand the need. In doing so the team learns about

the limitations of the current systems, which help team to understand the problem and the issues. The

team may write a preliminary specification and test whether it is feasible by doing some ball park

calculations. These help the design team understand the problem better and enable the team to refine

the specification. So the design process goes on. To this continuous process the team has to try and

impose a structure to make it manageable. The design team does this by using fixed time scale

milestones, by which the team commits ourselves to certain decisions and change the focus of our

activities. The three most important milestones are product design specification (PDS), preliminary

design review (PDR) and critical design review (CDR).

There is a lot of work leading up to the delivery of the PDS. The specification will have gone through

a number of revisions and a series of traded studies may have been undertaken (the most common of

which would be cost vs. performance). By the time the PDS is finalised the team should feel

confident about committing ourselves to a minimum specification and setting a series of targets,

which the team will probably meet. Often the team may have an outline of a solution at this stage

which appears to meet the specification the team is proposing.

At the preliminary design review the "best" feasible design is presented. At this point there is still

much detail design work to do but the design is defined sufficiently for all of the teams that are

involve with the product throughout is life (manufacturing, sales, the customer etc.) to comment and

raise issues of importance. This is the stage that should be reached by the end of the design project.

At the critical design review a fully specified design is presented (subject to the generation of

manufacturing drawings and non important component selection). Hopefully this is accepted with

only minor modifications and then there is a design freeze.

Below are a few notes, which might help you successfully complete the design project. Remember

this is meant to be a learning experience. If you want advice, ask.

Meetings

Team meetings consume a lot of man hours, make them productive. Come to meetings prepared and

get them over quickly. It may be relevant to set up working teams to deal with particular issues. In

that way the number of people involved can be reduced and valuable man hours can be saved. These

working teams can then report back at the main design meetings as necessary.

Being creative

Brain storming sessions are a good way of generating ideas but they are time consuming. To make

them work efficiently it is important that a lot of ideas are brought to the meeting and that the

meeting is allowed to flow. Try not to discuss the pros and cons of the ideas until no more ideas are


forthcoming. Then review the ideas and see if any of them can be combined to produce better ones.

Always make good notes at these sessions.

There are a number of approaches that can help individual creativity. Three of the most important are

Analogy: Drawing comparisons between dissimilar areas. i.e. I need to stop something that

is falling. What things stop things? What things stop things falling? How do they work etc.

Inversion: Changing the order of operations within a system or changing the spatial

orientation of the parts of a system. A jack is an inverted hoist etc.

Morphological analysis. Dividing a system into subsystems, generating ideas for each

subsystem then combining them to generate several solutions.

Choosing between ideas

Ranking charts of various forms helps the team weigh up the pros and cons of our various options. However, since the design process is continuous and iterative there is rarely a point where the team can put all of our options into a table and get an answer. Nevertheless these charts are useful all the way through the process to help a better understand the problem and to allow the team to make considered choices over the directions in which the team should focus our attention. Remember the highest scored design in the chart may not be an acceptable reason to make it a proposed design.

Some useful resources

British Standards: British Standards are available on-line. They can be accessed via university library homepage (Athens user name and password are required). The University library help desk provides full technical support to its online data base services.

Patents: There are a number of online searches of US and world-wide patents.

Component catalogues: Most manufacturers’ catalogues are now available online.


Appendix II: Submission deadlines

There are two submission deadline schemes, one is for Formula student car projects and the other one is for the non Formula student car projects. The details are listed below.

Formula Student Project deadlines:

PDS: Tue week 3 semester 1

PDR and first peer assessment form: Tue week 11 semester 1

CDR and second peer assessment form: Tue week 7 semester 2

Other Project deadlines:

PDS: Tue week 4 semester 1

PDR and first peer assessment form: Tue week 11 semester 1

CDR and second peer assessment form: Tue week 7 semester 2


Appendix III: Format of a generic report

(Data packs for PDR and CDR)

The report should be prepared as an engineering design data pack for preliminary or critical design review by the senior project managers. The recommended generic structure for the project data pack is given below.

Title page: the title page should contain the title of the project, the design team reference, the supervisor’s name and the date of completion.

Abstract: a maximum 80 words condensed version of the main body of the report (not an abbreviated introduction).

Acknowledgements, Table of contents, List of figures, List of tables, Nomenclature

For all of the above, the pages should be numbered in roman numerals. The page number restarts from the introduction. The pages of the Appendix should be numbered using A plus a Roman numeral and an Arabic page number, e.g. AI-1, AII-2.

Introduction: this should be two to four pages long and discuss the need for this work, the brief and the design drivers (the key aspects of the artefact that limit or direct the design). Clear objectives of the project should be given in this part of report. It should also outline the structure of the report.

Background: this should have a review (around five pages) of existing similar products, patents and scientific publications in the relevant area of the product design. The theories, simulation and/or analytical methods used to conduct the project should also be discussed in this part of the report

Product Design specification: The design specification is normally two to three pages long.

Review of potential solutions: this should be approximately 15 pages long with brief description of the potential solutions, discussion of the advantages and disadvantages of each potential solution and evaluation and justification of why the proposed solution is selected.

Proposed solution (for CDR only): this should be approximately 15 pages long with a detailed description of the proposed solution, including layout drawings. Important technical details should be discussed and any relevant analyses undertaken should be summarised (detailed versions of these analyses can be included in an appendix). All issues that are unresolved must be clearly identified. Tables and graphs can be used to present the results of the analysis. Engineering drawings are required to present the operational principle of the proposed design. In some cases, a full set of engineering drawings and CAD model may be required as an appendix (to conform with team customer’s/supervisor’s instructions as to what extent the engineering drawings are required).

Discussion and conclusions: This should have three to five pages to summarise the key achievements against the design specification/customer requirement and objectives given in the introduction.

Appendices: There is no page restriction on the appendices. However an appendix must include a statement from each student to indicate the detail contributions made to both the design process and the final report of the project. It may also include the following contents: detailed calculations, more details on alternative concepts design, the data used in concept evaluation, engineering drawings, British Standard or relevant regulation (or part of them) used by the design, anything else you feel is needed to support the text in the main body of the report.

The project report should be written in third person past tense, printed using a font size of 11 or 12, with single or 1.5 line space and in soft binding. In the case where a full set of engineering drawings is required, drawings larger than A3 should be put in plastic envelopes which are bound into the report.

Prepared by Dr W Xu for year 3 Group Design Project


Appendix IV: Format of Aerospace Data Packs (report)

The guidance given here is derived from that provided by NASA in support of the SAE AeroDesign® undergraduate student competition. They have been adapted locally to meet the needs of the design element of the University of Surrey Year 3 Group Design Projects. The best practices are a subset of NASA Systems Engineering principles. The NASA competition includes key decision points as outlined in two written documents, a systems engineering document and an 'as built' report. The first document, the Systems Engineering Report, consists of a requirements analysis, design description, test plan, work breakdown structure, schedule, configuration management list, interface list, risk analysis, and "lessons learned" summary. These documents detail the systematic tracking, control, and integration of the project’s design, construction, and implementation. The format of the Systems Engineering Report, as described here, is required for submission of data packs into the Preliminary Design Review (PDR) and Critical Design Review (CDR) stages of the Year 3 Group Design Projects. Note also that the format of the Specification should use the relevant elements of the document structure. As the Year 3 Group Design Projects will, with the exception of Formula Student, not proceed beyond CDR, the subsequent 'as built' report will not be needed.

The purpose of the NASA award is to engage students in the systems engineering process. Although not always taught in traditional engineering programmes, systems engineering is integral to industry and research in the real world. Because many students lack the level of systems engineering experience necessary, engineering firms and research institutions invest vast resources in systems engineering training and courses to bring early-career employees up to speed. NASA wants to expose more of today’s engineering students to systems engineering concepts and practice. This approach has been adopted at the University of Surrey to ensure that Group Design Projects are representative of current practice in industry.

Overview of Systems Engineering

Systems engineering is a logical set of grouped processes performed by multidisciplinary teams to engineer and integrate systems to ensure that products meet customers’ needs. The logical set of grouped processes forms a systems approach to meeting an organization’s development goals. The emphasis of systems engineering is on safely meeting functional, physical, and operational performance requirements in the intended-use environments over the system’s planned life within cost and schedule constraints.

Implementation of this systems approach will enhance an organization’s core engineering, management, and scientific capabilities and processes to ensure safety and mission success, increase performance, and reduce cost. This systems approach is applied to all elements of a system and all hierarchical levels of a system over the complete project life cycle.

A systems engineering plan implements a core set of common technical processes and requirements needed to define, develop, realize, and integrate the quality of the system products created and acquired by or for an organization. Systems engineering processes build on and apply best practices and lessons learned from government agencies, academia, trade associations, and industry, to clearly delineate a successful approach to complete comprehensive technical work, reduce programme and technical risk, and improve mission success. The set of common processes may be supplemented and tailored to achieve specific project requirements.


The rules for the NASA Systems Engineering Award represent a simplified application of the systems engineering process developed and used by NASA to manage space exploration and other large-scale efforts, as described in the NASA Systems Engineering Handbook. While the NASA Systems Engineering Handbook is specifically orientated towards aerospace projects. The processes are suitable for generic use. As an alternative approach, the US Department of Defence publication “Systems Engineering Fundamentals” represents a much broader and more concise guide to the terminology and processes involved.

Document Format

This format has been modified in detail from the original NASA version, but should be used for written report submissions as part of the Data Pack.

Electronic Report Format

The PDR and CDR reports should be submitted electronically in PDF format and in paper form. Supporting documentation (images, graphs, CAD drawings, etc.) may be submitted in PDF or JPG format only.

Font The minimum size type is 12-point proportional or a 10-character-per-inch non-proportional font.

Margins 2.5 cm left; 0.5 cm right, top, and bottom

Page Size

All report pages will be ISO A4 (210mm by 297mm) page format.

Cover Page

All documents must feature a cover page that states the Design Team’s number and members. Data Pack Report Format

Page Limit

The Report must be submitted in single-spaced typewritten pages, along with supporting documentation (images, graphs, CAD drawings), as a single document. There is no page count limit, but the report should respond concisely to the topics discussed below. Note that the winning submissions for the NASA competitions in 2010 had 26 pages in total. Conciseness is a necessary feature of engineering publications and this should be borne in mind by the Design Teams.

Content Outline

The Report should address the topics and follow the outline below. Tabular or graphic formats should be used as appropriate.

I. Requirements Analysis

What are the requirements to which the team is responding?

There are generally two types of requirements. The first type comprises the design, performance, schedule, and other requirements specified in the Customer Statement of Requirements (SOR). The second type is the requirements that the team sets for itself as a means of meeting top-level requirements.

What is the top-level approach the team is taking to meet the requirements?


Description of the top-level relationships involved in meeting the SOR. Include your top-level strategy in designing and building your entry: what approach is your team taking to field a successful design? The team’s activities should follow from this top-level approach.

II. Design Options Considered

What alternative design approaches were considered? Paragraph, sketch, or drawing that describes the design approaches considered: vehicle configuration, materials, structures, shapes, trade-offs, etc., and the rationale for the design approach selected by the team.

III. Project Risk Management

What are the top 5 to 10 project risks?

A list of risks that the team identified in designing, production and testing through to verification of the product. It should be ranked from first being the highest risk to the last being the lowest risk. The Project Risk Definitions and the Project Risk Management Matrix in a separate section below illustrate the format for presenting the identification and assessment of risks. Note that there are two aspects of risk: likelihood of occurrence, and consequences if a risk occurs.

How are these risks being handled or overcome?

A description of the tests, design methods, safety factors, or other techniques applied to manage the most severe risks. Also discuss unexpected risks and how they were or were not abated.

IV. Tests Conducted/Planned

What tests were or are being planned, and how are they related to the identified risks?

Paragraph, sketches, or notes that discuss what kind of tests your team conducted or plans to do: wind tunnels, loads, form and fit tests, mock-ups, etc. Since testing is one major method of risk abatement, the selection of tests should address the major risks identified in the risk assessment described in section III, above.

V. Algorithms/Formulae/Constraints Considered/Used

What constraints and formulae were applied to arrive at the design?

Indication of the types of constraints being incorporated, such as size, weight, power, etc., other than what the rules specify; examples may include items such as costs or availability of materials. Also indicate if your team is using any formulae or analysis tools to derive shapes, sizes, forms, etc., in design.

VI. Current Design Concepts and Preliminary System Characteristics What is the current design concept? A section consisting of annotated sketches or drawings of the current design. Use the list below as a guide to the elements that should be described. Note that this is not a prescriptive example set.

a. Weight b. Structure Details c. Materials d. Propulsion e. Power f. Avionics g. Landing Gear


h. Control Systems i. Navigation j. Communications

VII. Work Breakdown Structure (WBS): Project Tasks and Personnel Assignments What are the major project tasks, and who is responsible for each?

This section lists the major parts of the vehicle and support activities, together with the names of team members responsible for significant tasks. The structure of a WBS is discussed in a separate section below.

VIII. Schedule: Top-level Planned Schedule

What are the key events in the schedule?

A simple set of milestones indicating when the major activities of WBS items are planned to be completed. Examples of major activities for elements of the vehicle might be design, fabrication, and integration into the vehicle.

IX. Project Costs: Current Estimates

What are the projected costs of purchased items?

An estimate for the hardware, software, and services required to be purchased, listed by the elements of the WBS.

X. Interface List What are the characteristics of the key interfaces between system components? A list of the interfaces (physical, mechanical, electrical) between major components (e.g., landing gear and fuselage) and description of each interface as follows:

a. Component 1: Name of part/entity b. Component 2: Name of part/entity c. Interface Type: Mechanical, structural, electrical, software module, etc. d. Implementation Approach: Bolt and washer, adhesives, coupler, etc. e. Constraints or Issues: Manufacturing, responsibilities, schedule, etc.

Note that interface management is key to an effective design process and to avoiding rework or redesign during assembly and integration of the vehicle and its associated systems.

XI. Configuration Management List and Changes Since Initial Design What has been the impact and disposition of each requested change to the original design? A list of change requests since the original design, describing the following for each change request:

a. Change Request (CR) Title Short descriptive name/title of request (Example: Wing Performance Shortfall)

b. Change Request Item Process, organization, or components affected (Example: wing design)

c. Reason for Change Why the items require a change (Example: insufficient lift generated)

d. Recommended Action/Change Provide specific course of action to be approved (Example: redesign wing by increasing length)

e. Impact to Other Systems (WBS components) Describe the impact to other systems or processes if CR is implemented


(Example: weight increase and sufficient structure strength) f. Cost and Schedule Impact g. Impact if CR Not Approved h. Status Owner

Project Risk Management

The first chart to the right (top), Project Risk Definitions, is intended to provide an illustration and definitions related to risk management. The chart is based on a risk assessment of the NASA SOFIA aircraft. This process will help your team define and evaluate your risks.

The second chart to the right (bottom), Project Risk Management Matrix, is an example of what your team should create and submit as part of item IX in the Report.

Work Breakdown Structure (WBS)

A work breakdown structure is a hierarchical breakdown of the work necessary to complete a project. The WBS should be a product-based, hierarchical division, with the specified prime product(s) at the top and the systems, segments, subsystems, etc., at successive lower levels, as illustrated below. The elements of the WBS should correspond to identifiable elements of the product or programme, and the WBS should include all elements necessary to produce the vehicle and support any subsequent testing and evaluation.

Examples of product elements might include controls, propulsion, and airframe; examples of programme elements could include project management, systems engineering, system testing, and logistics. The WBS organizes these elements into tiers, or levels, to organize the flow of work. For example, the airframe may be broken down into fuselage, wings, landing gear, and tail surfaces.


Example Work Breakdown Structure

This breakdown is used to generate a WBS listing, such as the one shown below. The names of team member(s) responsible for any significant tasks (design, fabrication, testing) should appear next to each item on the WBS listing.

Team XX Work Breakdown Structure

Number Description Person(s) Responsible

1 First element (e.g., Airframe) Name

1.1 - First subelement (e.g., Fuselage) Name

1.2 - Second subelement Name

2 Second element Name

3 Third element Name

3.1 - Subelement Name

etc. Name

The schedule should flow from the WBS. For example, major milestones could be the start and end dates for design, fabrication, testing, and integration of each element or sub-element.

Prepared by Mr Steve McParlin for year 3 Aero Group Design Project


Appendix V: Format of a FS report (Data Pack)

Systems Engineering Documentation Guide

The guidance given here is derived from that provided by NASA in support of the SAE AeroDesign® undergraduate student competition. They have been adapted locally to meet the needs of the design element of the University of Surrey Year 3 Group Design Projects.

The purpose of the NASA award is to engage students in the systems engineering process. Although not always taught in traditional engineering programmes, systems engineering is integral to industry and research in the real world. Because many students lack the level of systems engineering experience necessary, engineering firms and research institutions invest vast resources in systems engineering training and courses to bring early-career employees up to speed. NASA wants to expose more of today’s engineering students to systems engineering concepts and practice. This approach has been adopted at the University of Surrey to ensure that Team Design Projects are representative of current practice in industry.

Overview of Systems Engineering

Systems engineering is a logical set of grouped processes performed by multidisciplinary teams to engineer and integrate systems to ensure that products meet customers’ needs. The logical set of grouped processes forms a systems approach to meeting an organization’s development goals. The emphasis of systems engineering is on safely meeting functional, physical and operational performance requirements in the intended-use environments over the system’s planned life within cost and schedule constraints.

Implementation of this systems approach will enhance an organization’s core engineering, management and scientific capabilities and processes to ensure safety and mission success, increase performance and reduce cost. This systems approach is applied to all elements of a system and all hierarchical levels of a system over the complete project life cycle.

A systems engineering plan implements a core set of common technical processes and requirements needed to define, develop, realise and integrate the quality of the system products created and acquired by or for an organization. Systems engineering processes build on and apply best practices and lessons learned from government agencies, academia, trade associations and industry, to clearly delineate a successful approach to complete comprehensive technical work, reduce programme and technical risk and improve mission success. The set of common processes may be supplemented and tailored to achieve specific project requirements.

The rules for the NASA Systems Engineering Award represent a simplified application of the systems engineering process developed and used by NASA to manage space exploration and other large-scale efforts, as described in the NASA Systems Engineering Handbook. While the NASA Systems Engineering Handbook is specifically orientated towards aerospace projects, the processes are suitable for generic use. As an alternative approach, the US Department of Defense publication “Systems Engineering Fundamentals” represents a much broader and more concise guide to the

terminology and processes involved.

Overview of Data Packs

Three Data Packs will have to be submitted. Together the documents detail the systematic tracking, control and integration of the project’s design, construction and implementation. The Data Packs are:

1) Product Design Specification (PDS), including design goals and work breakdown structure

The purpose of the PDS is to:

• document all relevant functional requirements for the particular system or component. It shall provide sufficient guidance, constraints and system requirements to execute the design.

• ensure achievable design goals are set;


• ensure tasks are distributed evenly amongst the team.

2) Preliminary Design Review (PDR), including timing plan for manufacturing stage

The purpose of the PDR is to:

• review the conceptual design to ensure that the planned technical approach will meet the requirements;

• select components/subsystems that will be taken to the detail design and build phases;

• ensure realistic timing objectives and milestones that align with the overall project timing.

3) Critical Design Review (CDR) and Test Readiness Review (TRR)

• The purpose of the CDR is to review the detailed design to ensure that the design implementation has met the requirements.

• The purpose of the TRR is to review preparations and readiness for testing of manufactured components (selected at the PDR stage).

Data Pack Format

The Data Pack reports should be submitted as a soft-bound hard copy and in electronic format (PDF format). Supporting documentation (images, graphs, CAD files and drawings, spreadsheets etc.) shall be submitted in their original format on a CD.

Paper size will be A4 (210 mm by 297 mm) and the minimum margin in all directions is 2 cm. In case engineering drawings on A3 page format are required, the drawings should be folded and bound into the report. The project report should be written in third person past tense, printed using a minimum font size of 11 and with single or 1.5 line spacing. All documents must feature a cover page that states the Design Team’s number and members.

A page count limit of the Data Packs is provided as shown in Table 1 below. There is no page restriction on the appendices, but the report should respond concisely to the topics discussed. Conciseness is a necessary feature of engineering publications and this should be borne in mind by the Design Teams.

Data Pack Content

In combination, all submitted reports should address the topics and follow the outline further below. Tabular or graphic formats should be used as appropriate. Please note that some sections may have to be revised and updated during the design process. The revised sections should be resubmitted with the following Data Pack. For each Data Pack the content as shown in Table V1 should be provided.

Table V1: Breakdown of content of individual Data Packs

Data Pack 1) PDS 2) PDR 3) CDR & TRR

Content* I III III

II IV IV

III V V

IV VI VI

VII VII VII

VIII VIII

IX

X

Page limit 15 50 60

*See content outline for detailed information on the specific topics.

Content outline


Each Data Pack shall start with a short introduction outlining the aims and structure of the report. A

list of references, i.e. all the sources of information which are directly referenced within the body of the text shall be included at the end of the main body of the report (and before the appendix). Also, a bibliography should be include, i.e. books, papers, websites that were used during the design project, but are not directly mentioned within the body of the text. Please note that web pages alone are not sufficient as references – please use textbooks and research papers as your main sources of information. In detail, the individual topics of the Data Packs are:

I. Requirements Analysis and Design Goals

What are the requirements to which the team is responding?

Description of the design, performance, schedule and other requirements specified in the FS competition regulations and the Customer Design Brief (CDB).

What are the design goals of the team?

Explanation of the requirements that the team sets for itself – i.e., design goals – as a means of meeting/exceeding top-level goals of the entire FS team.

II. Benchmark Analysis

What design solutions exist in industry?

A brief review of technical solutions employed by professional race teams and/or major car manufactures. Advantages and disadvantages of the presented solutions industry should be highlighted.

How was the design task solved by former Surrey FS teams and other FS teams?

Critical review of the technical solutions found on former Surtes FS cars. Include advantages and disadvantages of the design solutions and state all relevant technical information such as material, weight, manufacturing processes etc. Also, provide a critical review of the technical solutions employed by other FS teams and give as much technical information as possible (contact other teams if necessary).

III. Design Options Considered

What alternative design solutions were considered?

Paragraph, sketch or drawing that describes the technical solutions considered: configurations, materials, structures, shapes, trade-offs etc.

Why was the final design selected?

Discuss specific design criteria that are used to select the optimum design. Explain the chosen process to select the optimum design (e.g., comparison table/matrix) and discuss the reasons for the final design selected by the team.

IV. Tests Conducted/Planned

What tests were or are being planned to ensure working design solutions?

Paragraph, sketches or notes that discuss what kind of tests your team conducted or plans to do: vehicle, loads, form and fit tests, mock-ups, etc. Include descriptions of test equipment and procedures.

V. Algorithms/Formulae/Constraints Considered/Used

What constraints and formulae were applied to arrive at the design?

Explanation of the types of constraints being incorporated, such as size, weight, power etc., other than what the rules specify; examples may include items such as costs or availability of materials. Also describe if your team is using any formulae or analysis tools to derive shapes, sizes, forms, etc., in design.

VI. Current Design Concepts and Preliminary System Characteristics

What is the current design concept?


Present and explain the current design by providing annotated sketches or drawings. Outline all technical details, including the manufacturing, assembly and/or maintenance processes involved with the design solution.

How does the current design compare to the solutions develop by former Surtes teams?

Critical review of the improvements/enhancements achieved relative to the solution found on former FS cars. Compare and explain technical data/performance parameters, e.g., weight, dimensions etc.

VII. Project management

What are the major project tasks and who is responsible for each?

This section lists the major parts of the design and manufacturing activities, together with the names of team members responsible for significant tasks.

What are the key events in the schedule?

A simple set of milestones stating when the major activities are planned to be completed. Examples of major activities might be concept design, detail design, manufacture and integration into the vehicle.

How will the progress of the team be monitored and what contingency plans are considered?

Outline the process of monitoring the progress of the team, together with names who are responsible for this process and publishes it to all team members on an ongoing basis. Explain the contingency plans in place to ensure that the FS car will be completed in time.

VIII. Project Costs

What are the (projected) costs of items to be purchased and manufactured?

A detailed bill of materials and an estimate for the hardware, software and services required to be purchased. A list of all suppliers and manufacturers shall be included.

IX. Configuration Management List and Changes Since Initial Design

What has been the impact and disposition of each change to the original design?

A list of changes since the original design and a brief summary of the reasons of the changes and their implications on the final design.

X. Conclusions and Further Improvements

What did the team learn about the design and the development process?

A detailed description of the lessons learned throughout the design and development process. This information should be a summation of value added by the design exercise.

How can the design be improved?

Highlight areas that would allow further improvement of the performance of the individual system/component. Recommendations for further design improvements may also extend to other areas of the car.

Prepared by Dr Patrick Gruber for year 3 FS Group Design Project


Appendix VI: Format of a group design agenda

Title of the meeting

Agenda

Date - location - time

Apologies

1. Minutes of previous meeting

2. Matters arising

3 Chairman's Business

4. Items of business

5. Any other business

6. Date of next meeting

7. etc ….


Appendix VI: Format of a group design minutes

Title of the minutes

Held on Date in location at time

Chairman: Name

Secretary: Name

Present

List of people present

Absent

List of absences

Action

Apologies of Absence

Apologies were received from list of names

1. Minutes of the meeting held on the date of previous meeting

The minutes of the meeting held on the date of previous meeting were accepted as an accurate record (change if appropriate).

2. Matters arising

Minute num: Title of minute Summary of information presented or discussed.

Minute num: Title of minute Summary of information presented or discussed.

etc.

3. Chairman's Business

Summary of the information presented by the chairman to the board.

4. Title of item of business

Summary of the information presented and the conclusions reached. Statement of actions to be taken and by whom.

Initials of actioned person(s)

Other information presented and the conclusions reached. Statement of actions to be taken and by whom.

Initials of actioned person(s)

etc.

5. Title of next item of business


6. etc.

num. Any other business

summary of matters raised

num. Date of next meeting

Date of next meeting


Appendix VIII: Marking Guidelines

Guidance Notes

The University requires the students’ performance in the above areas to be given marks percentages

within the Honours Classification system. The following table gives the equivalence and the

corresponding typical percentage bands.

Mark ranges Performance

80-100 Exceptional

70-79 Well above average

60-69 Above Average

50-59 Average

40-49 Satisfactory but weak

0-39 Unsatisfactory

The following is a list of sample comments in the various areas, which may help in allocating the most appropriate marks.

Product Design Specifications

* Marks are awarded to the group. Everyone in the group receives the same mark.

Outstanding, faultless and meet the professional requirements of the PDS.

80-100

Faultless and meet the basic requirements of the PDS. 70-80

Not faultless but meet the basic requirements of the PDS with occasional minor corrections (which can be justified by the team).

60-69

Not faultless and modifications are required to meet the basic requirements of the PDS.

50-59

There are significant faults and major modification is required to meet the basic requirements of the PDS.

40-49

Work is unsatisfactory and resubmission is required to meet the basic requirements of the PDS.

0-39


PDR and CDR data packs

* Marks are awarded to the individual student in following five areas which are equally weighted

i.e. 7 and 9 marks for each area of the PDR and CDR data packs respectively.

Project management Skills

Exceptional ability to organise and plan work schedules, to progress more than one task at a time and to meet all the assigned task on time

80-100

Above average ability to organise and plan work schedules and to meet all the assigned task on time very satisfactory

70-80

Average ability to organise and plan work schedules and to meet all the assigned task on time satisfactory

60-69

Limited ability to organise and plan work schedules and needs prompting to produce acceptable work

50-59

Very limited ability to organise and plan work schedules and unable to produce satisfactory work without regular prompting on what needs to be done next

40-49

Unable to organise and plan work schedules (has to be told what to do next)

0-39

Comprehension

Exceptionally quick to grasp new ideas and concepts and to understand and interpret instructions

80-100

Quick to understand and interpret instructions and does not normally require additional information or explanation

70-80

No particular problems in understanding instructions but may sometimes require additional information or explanation

60-69

Frequently requires additional explanation or explanation before grasping new ideas/concepts and understanding instructions

50-59

Has significant difficulty in understanding any but the simplest instructions and ideas

40-49

Has extreme difficulty in understanding any but the most basic instructions and ideas

0-39

Creativity

Outstanding innovator and problem solver 80-100

Has many good ideas and can solve problems on his/her own 70-80

Has some good ideas and can solve problems where most of the technology and procedures are well established

60-69

Will function satisfactorily with familiar or well-established procedures and has the occasional useful idea

50-59

Will function adequately only when using familiar and well-established procedures

40-49

Is not prepared to think - resists change 0-39


Technical Achievement

Exceptional achievement in translating ideas, concepts and scientific knowledge into solutions to actual engineering problems, while requiring minimum supervision

80-100

Professional competence in solving engineering problems, with little supervision

70-80

Achieves good results provided objectives are well defined and relevant information is readily available

60-69

Achieves reasonable results provided objectives are spelt out and assistance is given when required

50-59

Only able to complete straightforward tasks and requires regular supervision and/or assistance

40-49

Requires constant supervision and assistance to complete even the simplest tasks

0-39

Communication and team work

Outstanding ability to communicate in both orally and writing and excellent team working skill

80-100

Very competent in oral and written communications and team work 70-80

No problems in communicating ideas in oral or written communications and team work

60-69

Has minor difficulties in conveying information accurately and/or concisely, or team working but able to make him/herself understood by the team

50-59

Has a significant difficulty in conveying information or ideas adequately in oral or written communications or to make him/herself understood by the team

40-49

Fails to communicate adequately or unable to make him/herself understood by the team

0-39


Appendix IX

ENG3162 Year 3 Group Design Peer Assessment Form

Group Number:_____________________

Management and Communications

Comprehension and Creativity

Team work & Technical achievement

-4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4

-4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4

-4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4

-4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4

-4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4

-4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4

-4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4

-4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4

-4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4

-4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4

-4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4

-4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4

-4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4

-4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4

-4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4

-4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4

-4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4 -4 -3 -2 -1 0 +1 +2 +3 +4

Notes:

1) Ring only one score in each section.

2) All marks should be relative to the average contribution of the group. So if three people are marked high the rest must be marked low.

3) Management and Communications: Assessment of each group member’s contribution in organizing the design activities and communication with other member of the team, project customer and external individual and institutes.

4) Comprehension and Creativity: Assessment of each group member’s contribution to the understanding of the engineering problems encountered and the application of engineering science innovatively in the design process.

5) Team work & Technical achievement: Assessment of each group member’s contribution to the project in terms of team work toward to the technical achievement. This including effective task allocation and working load distribution between team members as well as over the entire period of the design project.

eng3162 year 3 group design project student handout 2013-14

Documents