P18084: Microfluidics - Laminar Flow Mixing
/public/

Problem Definition

Table of Contents

Team Vision for Problem Definition Phase

Plan to do:
  1. Planned a meeting with the customer as well as creating a list of customer requirements.
  2. Planned how to sub-divide over-arching problem statement in manageable pieces.

Phase Accomplishments:

  1. Ensure all team members on the same page for problem definition
  2. Determined use scenarios of the bubble-driven mixer.
  3. Select a defining problem statement and select project goals of creating a viable bubble-driven mixer along with experimental testing of the unit.
  4. Meet with customer to discuss customer requirements for the project.
  5. Establish weighting criteria for deliverable from list of customer requirements. The weighting criteria is used to sub-divide the project into smaller incremental problems to facilitate a step-by-step design process.

Project Summary

Laminar flow is ubiquitous in microfluidic devices due to the defining characteristic lengths. Unlike turbulent flow, a lack of random, statistical eddies and vortices makes mixing difficult in laminar flows. However, macroscopic mixing of fluids in microfluidic devices is vastly important in a number of biological and chemical applications. Current approaches in microfluidics utilize bulky, external pumps to power the flow. An integrated solution using HP inertial micropump technology can potentially offer a compact, scalable solution to address mixing of laminar flows.

The goal of this project is to research the use of HP inertial pumps to mix laminar flows. The placement and number of inertial pumps needs to be optimized in order to mix laminar flows. In addition, a characterization methodology to detect and measure mixing must be established. The desired outcome is a functional microfluidic system incorporating HP inertial pumps to mix laminar flows as well as learnings achieved through the process. This project serves to demonstrate or otherwise evaluate mixing of laminar flows using inertial micro-pumps.

Link to 1-page project summary or project charter

Project Background

Stakeholders

Stakeholder Description
HP Customer
RIT Vested interest in success of project to come in good light with potential Co-op company
Our Team Completing the project in a timely and efficient manner gives us experience as well as insight into research within a large company HP.

Customer Interview

Use Cases

  1. Mixing microfluidic flows for biomedical application
  2. Mixing inks
  3. Material processing used in microfluidic (3D printers)

Project Goals and Key Deliverables

The customer, HP, seeks to demonstrate the ability of their inertial pump technology to mix laminar, microfluidic flows. In order to answer question, we must develop a device to evaluate the applicability of this technology in mixing microfluidic flows. Our extended deliverable, pending time, is to advance knowledge in microfluidic characterization through experimental testing.

Research Questions

  1. Can you use HP inertial pump technology to mix laminar flow?
  2. Can you develop an integrated flow sensor to measure the flow velocity through the microchannel?
  3. This type of device would typically be fabricated in a clean room environment, but this is a time consuming and expensive process. Can supplementary additive manufacturing be used for more rapid prototyping of such a microscale device?

Customer Requirements (Needs)

  1. Fluid type
  2. Scale size
  3. Channel width, height, length
  4. Wafer size
  5. Material composition restrictions
  6. Required heat flux
  7. Use of prior HP patents
  8. Capability of being internally cleaned
  9. Power source
  10. Aesthetics
  11. Durability/reliability (how many tests per device)

Purpose

Decompose the Problem Statement into functions of elements needed to satisfy the customer.

Instructions

  1. Instructions and EXAMPLE must be deleted before the Problem Definition Review.
  2. Identify an owner for this document.
  3. Include this document in all project reviews during MSD1.
  4. Have you sought input from all the relevant stakeholders? How will you confirm this?
  5. Have you converted customer-generated solutions into needs statements?
  6. Describe why each requirement has been requested.
  7. Have you confirmed this list with your customer?
  8. Customer requirements often evolve over the first several weeks of the MSD. Understanding the customer’s overall objective (Problem Statement) and the levels of each requirement needed to achieve that objective will help you get to a final requirements document more quickly.
  9. Functional requirements (e.g. capabilities, performance, robustness, etc.) typically denote the purpose of the project. Constraints (e.g. cost , safety, size & weight , etc.) typically denote conditions for acceptance of the solution.

http://edge.rit.edu/edge/P15001/public/MSDI/Problem%20Definition%20Documents/Edge_Pictures/P15001_Customer_Requirements.png

  1. In addition to a snapshot, include a link to the live document here
  2. Considering the purpose, the team should anticipate potential failure modes associated with construction and use of this document.

Inputs and Source

  1. PRP.
  2. Problem Statement.
  3. Customer Interviews. (Interview guidelines and expected outcomes are available for your reference)
  4. Customer's customer if possible.
  5. Standards, regulations, or other industry guidelines (e.g., ADA, EPA, OSHA, IEEE, ASME; IRB approval; etc.) that your customer or your customer's organization is required to address. The RIT library maintains an infoguide with links to standards databases
  6. Template and Example.
  7. Guide & other stakeholders.

Outputs and Destination

A completed form matching the supplied template to be used as input to define the Engineering Requirements.

Engineering Requirements (Metrics & Specifications)

Purpose

Create a contract between the engineer and the customer where indisputable satisfaction of the engineering requirements equates to customer satisfaction

Instructions

  1. Instructions and EXAMPLE must be deleted before the Problem Definition Review.
  2. Identify an owner for this document.
  3. Include this document in all project reviews during MSD.
  4. The Engineering Requirements (often called Specs.) must; cover all of the Customer Requirements, be as unambiguous as possible, and be confirmed by the customer, with signature if possible.
  5. System-level and function-level engineering requirements define the intended capabilities and performance of your system. Are your engineering requirements measurable and testable? Can they all be traced back to customer requirements?
  6. Constraints are factors, usually system-level, that limit your design space (e.g., cost, total weight, total footprint, total power available). Are your constraints measurable and testable, and can they be traced back to customer requirements? Have you considered economic, environmental, social, political, ethical, health and safety, manufacturability, and sustainability constraints, for example?
Engineering Requirements Template

Engineering Requirements Template

  1. References:

https://edge.rit.edu/edge/PTemplate/public/Establish%20Engineering%20Requirements

  1. Considering the purpose, the team should anticipate potential failure modes associated with construction and use of this document.

Inputs and Source

  1. Customer Requirements
  2. Customer
  3. Phase I benchmarking
  4. Standards, regulations, or other industry guidelines (e.g., ADA, EPA, OSHA, IEEE, ASME, etc.) The RIT library maintains an infoguide with links to standards databases.
  5. Selected concept list
  6. System Design
  7. Template and Example
  8. Guide & other stakeholders

Outputs and Destination

  1. Function Decomposition.
  2. Concept Generation & Development.
  3. HoQ.
  4. System & Detail Design.
  5. Test Plans.
  6. Poster & Final Report.

Constraints

Factors, usually system-level, that limit your design space (e.g., cost, total weight, total footprint, total power available). Are your constraints measurable and testable, and can they be traced back to customer requirements? Have you considered economic, environmental, social, political, ethical, health and safety, manufacturability, and sustainability constraints and engineering standards, for example?

House of Quality

Purpose

  1. Confirm that satisfaction of the Engineering Requirements implies that all of the Customer Requirements are met.
  2. Facilitate design trade off decisions

Instructions

  1. Instructions and EXAMPLE must be deleted before the Problem Definition Review.
  2. Identify an owner for this document.
  3. This document will be inspected at all project reviews during MSD1.
  4. Array customer requirements in the first column and the Engineering Requirements across the top row.
  5. Evaluate the correlations between Customer and Engineering Requirements to ensure all of the Customer Requirements will be satisfied if the Engineering Requirements are satisfied.
  6. Evaluate the potential conflicts between the Engineering Requirements.
  7. Evaluate targets set for Engineering Requirements verses best benchmarking results.
  8. 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. Customer Requirements.
  3. Engineering Requirements.
  4. Benchmarking Data.

Outputs and Destination

Provide input to the risk management process.

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