Follow this link to go to the text only version of nasa.gov
NASA - National Aeronautics and Space Administration
Follow this link to skip to the main content
+ Contact NASA
    
ABOUT NASA NEWS AND EVENTS MULTIMEDIA MISSIONS POPULAR TOPICS MyNASA

+ Home
AERONAUTICS RESEARCH MISSION DIRECTORATE
ABOUT US
PROGRAMS
ARMD NRA
TECHNICAL EXCELLENCE
PEOPLE
PARTNERSHIPS
REFERENCE MATERIALS
EVENTS AND EXHIBITS
EDUCATION
NEWS MEDIA
MULTIMEDIA

Related Links
+ Higher Education
+ K-12 Students/Teachers
+ Professional/Continuing Education
+ Design Challenges/Competitions
+ NASA Offices of Education
+ General Resources





NASA SYSTEMS ENGINEERING AWARD
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.
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
    1. Weight
    2. Structure Details
    3. Materials
    4. Propulsion
    5. Power
    6. Avionics
    7. Landing Gear
    8. Control Systems
    9. Navigation
    10. Communications
  7. 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.
  8. 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).
  9. 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.
  10. 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.
  11. 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:
    1. Component 1: Name of part/entity
    2. Component 2: Name of part/entity
    3. Interface Type: Mechanical, structural, electrical, software module, etc.
    4. Implementation Approach: Bolt and washer, adhesives, coupler, etc.
    5. Critical Characteristics: Dimensions, fit, strength, etc.
    6. 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.
  12. 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:
    1. Change Request (CR) Title
      Short descriptive name/title of request
      (Example: Wing Performance Shortfall)
    2. Change Request Item
      Process, organization, or components affected
      (Example: wing design)
    3. Reason for Change
      Why the items require a change
      (Example: insufficient lift generated)
    4. Recommended Action/Change
      Provide specific course of action to be approved
      (Example: redesign wing by increasing length)
    5. 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)
    6. Cost and Schedule Impact
    7. Impact if CR Not Approved
    8. Status Owner
Project Risk Management
Org Chart. SAE Aero Design Entry on top. Next row is Airframe with a subcategory of fuselage and etc. Next on the row is Element 2, etc., Project Management, System Engineering, etc. and etc. Airframe to the first etc. are Product Elements that work to produce the individual system components while the other work to integrated the components into the system.
+ Link to view a larger image
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

Org Chart. SAE Aero Design Entry on top. Next row is Airframe with a subcategory of fuselage, wings, landing gear and control surfaces. Next on the row is Propulsion, controls, project management, systems engineering, system test and logistics.

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:
  1. Name and (location if necessary) of the item changed
  2. Original baseline configuration/design of the item
  3. New configuration/design of the item
  4. 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.

+ Back to Top


MORE INFO IN NASA SITE NETWORK

+ USA.gov - The U.S. government's official web portal.
+ Freedom of Information Act
+ Budgets, Strategic Plans and Accountability Reports
+ The President's Management Agenda
+ Privacy Policy and Important Notices
+ Inspector General Hotline
+ Equal Employment Opportunity Data Posted Pursuant
to the No Fear Act

+ Information-Dissemination Priorities and Inventories
NASA - National Aeronautics and Space Administration
Editor: Karen Rugg
NASA Official: Tony Springer
Last Updated: November 06, 2012
+ Contact NASA