P20005: Liftbridge
/public/

Systems Design

Table of Contents

Your website should document your journey through MSD, so include work-in-progress as well as latest results. Use pdf's for display whenever possible so that information is easily viewable without the need to download files and open applications. (Your EDGE file repository should still contain original editable files).

Content linked here should go in the Systems Level Design Documents directory. This directory is pre-populated with a variety of templates that are designed to help you through this phase of the design.

All template text must be removed from this page prior to your System Level Design Review

Team Vision for System-Level Design Phase

Summarize:

Functional Decomposition

Purpose

Define the total list of functions and subfunctions, based on the Customer and Engineering Requirements, that must be delivered by the final design. This will establish the need for specific concepts necessary to deliver the overall objectives of the project

Instructions

  1. Instructions and EXAMPLE must be deleted before the System-Level Design Review AND Identify an owner for this document.
  2. This document will be inspected at all project reviews during MSD1.
  3. Begin with the Project Problem Statement and identify the functions and constraints necessary to adequately address that problem.
  4. Identify the subfunctions necessary to deliver all of the stated functions. Repeat with sub-sub functions as needed until the team agrees that they know how they can be delivered. Note that you may have to revisit this step if the team assessment proves inaccurate.
  5. Benchmarking will provide existing elements that can satisfy many of the needed functions.
  6. Capture potential concepts that might deliver the required functionality for evaluation later.
  7. Considering the purpose, the team should anticipate potential failure modes associated with construction and use of this document.

Inputs and Source

  1. Template and Example.
  2. Project Objectives.
  3. Engineering Requirements.
  4. Benchmarking Data.

Outputs and Destination

  1. Complete list of functions that must be provided in order to satisfy the functional requirements of the entire project.
  2. Engineering Requirements are written to measure how well the functions are performed.
  3. Concepts are generated around functions identified here.

Benchmarking

Purpose

Avoid redundant work by identifying already available solutions and concept options

Instructions

  1. Instructions and EXAMPLE must be deleted before the System-Level Design Review AND Identify an owner for this document.
  2. Begin with the customer's objective or problem statement and identify the best available solution that the customer could access. How will you determine what is the""best available solution""? These are often earlier projects or commercially available systems that do not fully address the customer's needs. Sometimes these are a mix of elements plus manual tasks that are integrated to approximate a full customer solution.
  3. Use the Function Decomposition to set concept requirements that must be satisfied by concepts found via benchmarking.
  4. Consider analogous functions in nature and evaluate how evolution has addressed the need.
  5. Considering the purpose, the team should anticipate potential failure modes associated with construction and use of this document.

Inputs and Source

  1. PRP.
  2. Project Objective.
  3. Function Decomposition.
  4. Prior MSD EDGE sites.
  5. Customers.
  6. Vendors and users of existing or similar solutions.
  7. Literature search.
  8. Friends and associates.

Output and Destination

  1. List of best available concepts and embodiments.
  2. Criteria used for selection of best.

Concept Development

Purpose

Generate new concept options or combinations that can potentially exceed the benchmark concepts

Instructions

  1. Instructions and EXAMPLE must be deleted before the System-Level Design Review.
  2. Begin with the Function Decomposition and capture multiple concepts to provide each function.
  3. Select most promising options from benchmarking, then generate concepts that improve their weaknesses and extend their advantages. Brainstorming is a useful technique.
  4. Explore concepts that address subsets of the required function as well as those that encompass multiple functions.
  5. High level (e.g. free body) analyses often lead to improvement options.
  6. Crude concept prototyping also provides insights into improvement options.
  7. Assess the strengths and weaknesses of each concept considering their likelihood to satisfy the functions, violate constraints or present delivery/demonstration difficulties.
  8. Do the best job you can within the time allowed but remember that the team may have to revisit this work when the system interfaces are better understood.

Input and Source

  1. Function Decomposition.
  2. Results of Benchmarking.
  3. Analysis and prototyping.

Outputs and Destination

List of multiple viable concept options to provide each function.

Feasibility: Prototyping, Analysis, Simulation

Purpose

  1. Confirm that the selected concepts can deliver functionality defined by the System Architecture.
  2. Define the optimal values of the most sensitive design parameters.
  3. Support the evaluation of your team's concepts with quantitative information.

Instructions

  1. Instructions and EXAMPLE must be deleted before the System-Level Design Review AND Identify an owner for this document.
  2. This document will be inspected at all project reviews during MSD1.
  3. At the system design level, feasibility analysis and prototyping will be relatively coarse. First order analysis, estimation, and rough physical mockups are to be expected.
  4. Select the concepts that are expected to be most sensitive and/or problematic. These are usually concepts that will not be satisfied by COTS components.
  5. Define the transfer function that converts the concept/subsystem inputs into the desired outputs as a function of specific design parameters. This can be done via theoretical analysis or empirical prototyping. it is often useful for two or more team members to work together so that the work is checked and a clear understanding of these models is captured. Get help here from SMEs who should be able to alert your team to potential difficulties and possible solutions.
  6. Use the models to quantitatively specify the design parameter targets and acceptable ranges.
  7. Confirm that the concepts selected and the designs anticipated will generate the desired performance.
  8. Considering the purpose, the team should anticipate potential failure modes associated with construction and use of this document.

Inputs and Source

  1. Engineering Requirements
  2. Concept Selection

Outputs and Destination

  1. A list of Design Parameters, Quantified Targets, and acceptable tolerances
  2. Sensitivity analysis
  3. Concept Selection

Morphological Chart and Concept Selection

Purpose

  1. Develop multiple concept options to deliver the required list of functions.
  2. Ensure that concepts (means) are available to deliver every required function.
  3. Select the optimal set of concepts that can be integrated to meet the project objectives.

Instructions

  1. Instructions and EXAMPLE must be deleted before the System-Level Design Review AND Identify an owner for this document.
  2. This document will be inspected at all project reviews during MSD1.
  3. Begin with the Function Decomposition and identify concepts that can deliver the function and are expected to comply with the project constraints.
  4. Identify the best available solution that the customer could access. These are often earlier projects or commercially available systems that do not fully address the customer's needs. Sometimes these are a mix of elements plus manual that integrate and complete them to approximate a full customer solution.This best existing system will become the datum.
  5. Generate new concepts as well. The team should be considering at least 50 different concepts to cover all of the required functionality. In many cases, 100 is a better target. Try to avoid redundant efforts by teammates BUT don't leave gaps.
  6. Consider the Engineering Requirements and overall project objectives to construct a list of selection criteria. Remember that the concepts must be integrated by the team within the expected system envelope, the project constraints, the available schedule and budget.
  7. Use a systematic selection process, e.g.Pugh, to evaluate, recombine and add new concepts, by comparing them to the datum. Select the best combination of concepts.
  8. Considering the purpose, the team should anticipate potential failure modes associated with construction and use of this document.

Inputs and Source

  1. Project Objectives.
  2. Engineering Requirements.
  3. Function Decomposition.
  4. Concept Development.
  5. Benchmarking criteria.
  6. System Architecture.

Outputs and Destination

  1. A complete set of concepts that provide all of the functionality required.
  2. Fall back options to substitute for the most risky concepts.

Concept Selection

This consists of two elements:

The real value in this step of the process is not the comparison matrix you generate to compare your concepts, but the analysis and discussion you do to support your evaluation.

Systems Architecture

Purpose

  1. Ensure flow of energy, info, material and structural forces as intended.
  2. Define subsystem functions, envelopes and interfaces.

Instructions

  1. Instructions and EXAMPLE must be deleted before the System-Level Design Review Identify an owner for this document.
  2. This document will be inspected at all project reviews during MSD1.
  3. Begin with the Function Decomposition. The top level function is provided by the total system. The next level of functionality is generally provided by subsystems. Lower levels of functionality are delivered by sub-subsystems, assemblies and sub assemblies on down to individual parts. System Architecture generally addresses subsystems.
  4. Define the functional system architecture by assessing how material, energy, information and forces are transmitted from the total system inputs to the outputs. Define the condition and timing of these at the subsystem interfaces.
  5. Next describe the physical system by considering how envelopes of the various subsystems (the concepts and expected designs that embody these) and how they will interface with each other.
  6. Considering the purpose, the team should anticipate potential failure modes associated with construction and use of this document.

Inputs and Source

  1. Engineering Requirements.
  2. Functional Decomposition.
  3. Concept Development.

Outputs and Destination

  1. High level description of the total system that support concept selection.
  2. Interface definition for subsystem design.

Designs and Flowcharts

Purpose

Define a high-level view of the elements required to build and operate the entire system

Instructions

  1. Instructions and EXAMPLE must be deleted before the next Project Review AND Identify an owner for this document.
  2. This document will be inspected at all project reviews until the system is assembled and debugged.
  3. Identify subsystem interfaces.
  4. Define projected system operation.
  5. Considering the purpose, the team should anticipate potential failure modes associated with construction and use of this document.
  6. Reference: http://edge.rit.edu/edge/P15571/public/Detailed%20Design%20Documents/Data_Flow_Chart_Rev_2_0.pdf
  7. Note: This section should be started during systems design, and continued through detailed design.

Risk Assessment

Have you updated your risk list (started during Problem Definition) to include new items specific to your chosen concept?

Design Review Materials

Include links to:

It is appropriate for you to send your customer and guide a link to this page in preparation for the review. This will ensure that they know what you will be presenting and how to view all of your work. Any EDGE link should start with http://edge.rit.edu/edge/P1xxxx..... Using "http" instead of "https" will ensure that non-RIT stakeholders can view the content without being prompted for a DCE login and password.

Plans for next phase

Home | Planning & Execution | Imagine RIT

Problem Definition | Systems Design | Preliminary Detailed Design | Detailed Design

Build & Test Prep | Subsystem Build & Test | Integrated System Build & Test | Customer Handoff & Final Project Documentation