|
|
 |
 |
|
| |
|
|
|
| |
|
 |
| |
2013 GUIDELINES and RULES
- Obtain first-hand experience applying NASA's best engineering practices
- Manage SAE Aero Design® entries for best performance, cost, schedule, and risk
- Interact with professional NASA engineers
- Earn the opportunity to win a $750 cash award
Introduction
This is a unique opportunity to professionally interact with NASA engineers!
NASA believes in the value that hands-on engineering challenges provide
to students. NASA is proud to partner with the SAE Aero Design®
competition to offer the NASA Systems Engineering Award.
The NASA Systems Engineering Award gives students participating in the
SAE Aero Design® competition an additional opportunity to compete in
applying best engineering practices to the design and development of
their aircraft. Participation in the NASA competition is optional.
The best practices are a subset of NASA Systems Engineering principles.
The NASA competition includes key decision points as outlined in two
written documents. The documents detail the systematic tracking,
control, and integration of the project’s design, construction, and
implementation.
The first document, the Systems Engineering Report, will consist of a
requirements analysis, design description, test plan, work breakdown
structure, schedule, configuration management list, interface list, risk
analysis, and “lessons learned” summary. Teams will have the opportunity
to consult with NASA experts via on online forum. Participating teams
will be evaluated by NASA personnel. One $750 award will be given to the
winning team at Aero Design East, and another $750 award will be given
to the winning team at Aero Design West.
The second document, the As Built Report, will be submitted during the
onsite inspection of the aircraft at the competition. This report
identifies changes from the final design and justifies the differences.
The purpose of this award is to engage students in the systems
engineering process. Although not always taught in traditional
engineering programs, 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 award is one approach to reaching that
goal.
This award is sponsored and managed by NASA's Aeronautics Research
Mission Directorate (http://www.aeronautics.nasa.gov) in partnership
with SAE International.
Overview of NASA 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 NASA, as well as other
governmental agencies, academia, trade associations, and industry, to
clearly delineate a successful approach to complete comprehensive
technical work, reduce program 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.
Document Format
The NASA Systems Engineering Award requires two separate documents: the
Systems Engineering Report and the As Built Report. Both documents
should follow the following format specifications.
Electronic Report Format
The Systems Engineering Report and Visual Verification: As Built Report
should be submitted in PDF format only. 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
1 inch left; ½ inch right, top, and bottom
Page Size
All report pages will be ANSI A (8 ½ by 11 inches) page format.
Cover Page
All documents must feature a cover page that states the team’s name, school, and team number.
Systems Engineering Report
Page Limit
The Systems Engineering Report must be submitted in double-spaced
typewritten pages, along with supporting documentation (images, graphs,
CAD drawings), as a single document. There is no longer a page count
limit, but the report should respond concisely to the topics discussed
below. (Each of the winning entries in the 2012 competition had a total
of approximately 75 pages, including figures and supporting
documentation.)
Content Outline
The Systems Engineering Report should address the topics and follow the
outline below. Tabular or graphic formats should be used as appropriate.
- 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 for
the SAE competition class that the team is entering. The second type is
the requirements that the team sets for itself as a result of the team’s
strategy for the competition: for example, lift a payload of XXX lbs.
The strategy should address both types of requirements.
What is the top-level approach the team is taking to meet the requirements?
Description of the top-level relationships (power, weight, volume,
etc.). 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.
- 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.
- Project Risk Management
What are the top 5 to 10 project risks?
A list of risks that the team identified in designing, building, flying,
and submitting the aircraft and documents for the competition. 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.
- Tests Conducted/Planned
What tests were or are being conducted, 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,
mockups, 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.
- Algorithms/Formulas/Constraints Considered/Used
What constraints and formulas 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 formulas to derive shapes, sizes, forms, etc.,
in designing and/or building the vehicle.
- Current Design Concepts and Preliminary System Characteristics
What is the current design concept?
A section consisting of annotated sketches or drawings of the current
vehicle design you plan to build. Use the list below as a guide to the
elements that should be described.
- Weight
- Structure Details
- Materials
- Propulsion
- Power
- Avionics
- Landing Gear
- Control Systems
- Navigation
- Communications
- 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.
- 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. Schedules are customarily presented as Gantt charts
(horizontal bar charts with bars representing start and end dates for
each activity).
- 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.
- Lessons Learned
What did the team learn about the design and the development process?
A detailed description of the lessons learned throughout the design and
development of the aircraft for the competition. This information should
be a valuable resource for teams competing in the future.
- 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:
- Component 1: Name of part/entity
- Component 2: Name of part/entity
- Interface Type: Mechanical, structural, electrical, software module, etc.
- Implementation Approach: Bolt and washer, adhesives, coupler, etc.
- Critical Characteristics: Dimensions, fit, strength, etc.
- 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.
- 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:
- Change Request (CR) Title
Short descriptive name/title of request
(Example: Wing Performance Shortfall)
- Change Request Item
Process, organization, or components affected
(Example: wing design)
- Reason for Change
Why the items require a change
(Example: insufficient lift generated)
- Recommended Action/Change
Provide specific course of action to be approved
(Example: redesign wing by increasing length)
- 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)
- Cost and Schedule Impact
- Impact if CR Not Approved
- 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 Systems
Engineering 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 program, and the WBS should
include all elements necessary to produce the vehicle and support the
flight activity.
Examples of product elements might include controls, propulsion, and
airframe; examples of program 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) for the WBS element 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.
Visual Verification: As Built Report
Page Limit
There is no page limit for this report. You may use graphics or
illustrations to support your documentation.
Submission and Content Outline
The As Built Report should be submitted before or during the onsite
inspection of the aircraft at the competition. The systems engineering
judges will be checking “as built” vs. design. The As Built Report
identifies changes from the final design and justifies the differences.
Examples of typical justifications include construction problems, flight
problems, cost, weight, and other issues that were identified
post-design and had to be addressed either during or after construction.
Each item that has been changed from the submission of the Systems
Engineering Report requires the following information to be provided:
- Name and (location if necessary) of the item changed
- Original baseline configuration/design of the item
- New configuration/design of the item
- Rationale for the change of the item from baseline design to the as-built
configuration
Deadlines
Aero Design East
Deadline for Systems Engineering Report: February 9, 2013
Deadline for Visual Verification: As Built Report: March 15, 2013
Aero Design West
Deadline for Systems Engineering Report: March 8, 2013
Deadline for Visual Verification: As Built Report: April 12, 2013
Submission
The Systems Engineering Report documents should be submitted via email:
Aero Design East teams submit to nasa_aero_east_2013@nx.arc.nasa.gov
Aero Design West teams submit to nasa_aero_west_2013@nx.arc.nasa.gov
The Systems Engineering Report should be in PDF format and no larger than 9.0 MB.
Teams must use the following naming convention for their files:
TeamNumber_TeamName_SER.pdf
The As Built Report should be presented as electronic or hard copy at
the competition site. Electronic copies sent by e-mail to the addresses
above must be submitted no later than five days before the deadline
(i.e., by March 10, 2013 for Aero Design East and April 7, 2013 for Aero
Design West).
Feedback
A NASA engineer will provide comments on the Systems Engineering Report
through e-mail by replying to the sender’s e-mail address, or other
e-mail address if requested with submission of the report.
Forum
Teams may post their systems engineering questions and comments to the SAE Aero Design Forum at
http://forums.sae.org/access/dispatch.cgi/aerodesign_pf.
Evaluation
NASA judges will review and provide comments on the Systems Engineering
Reports and the As Built Report. The purpose of the reports is to
provide the teams with meaningful feedback and experience. Both the
Systems Engineering Report and the As Built Report will be scored by
NASA-appointed judges to determine the winning teams.
Each of the 12 items described in the outline for the Systems
Engineering Report will be awarded 0 to 5 points, based on quality of
the material and responsiveness to the requirements. The As Built Report
will be awarded 0 to 10 points, based on the justification for
deviations and evidence of lessons learned. The feedback will include
the scoring for the Systems Engineering Report.
A NASA engineer with be available on-site to discuss each team's feedback.
Award
One $750 award will be given to the winning team at Aero Design East and
one $750 award will be given to the winning team at Aero Design West. In
each case, the award will be given to the entry scoring the most total
points. The $750 award will be split in case of a tie.
The judges may award an Honorable Mention for entries that have not
earned the award but display unusually high quality. In addition,
special NASA commemorative awards will be given to each of the winning
teams. All participating teams that submit the required material will
receive a certificate of completion from NASA Headquarters.
|
|
|
