P17005: Assistive Tablet Case
/public/

Detailed Design

Table of Contents

Team Vision for Detailed Design Phase

Progress Report

Finalized Requirements

Based on feedback from our Guide and Customer, Requirements Definitions have been updated to more accurately represent the desires of the customer.

Function Decomposition

The Function Decomposition breaks down the device by increasingly precise levels of "how" a function will be supplied.
Function Decomposition

Function Decomposition

Customer Requirements

Customer Requirements define the end result of the product.
Customer Requirements

Customer Requirements

Quality (Engineering) Requirements

Quality Requirements define how the end result will be confirmed.
Quality Requirements

Quality Requirements

House of Quality

The House of Quality has been updated to reflect the changes in requirements. Again, the HoQ ensures all requirements are covered.
House of Quality

House of Quality

Updated Requirements Spreadsheet can be found here

Prototyping, Engineering Analysis, Simulation

Prototyping was done in the form of foam shapes, 3D printed models, and our new mannequin, Buddy, who helped us develop our Harness system.

Drawings, Schematics, Flow Charts, Simulations

Almost all features of our product have been artfully sketched by our designer, Mick. The first image below shows a total deconstruction of our proposed Harness and Track Design for carrying the device and moving it from the stored position on the back to the use position on the front.
Finalized Harness Drawing

Finalized Harness Drawing

Second, the design for the case has been worked out, including what shape it should be and the layers involved.

Finalized Case Drawing

Finalized Case Drawing

Finally, the crossbar system was developed to integrate the device with the harness and track. The crossbar acts to mount the device to the track, and also acts as a table stand when disconnected.

Finalized Crossbar Drawing

Finalized Crossbar Drawing

Use Cycle

To ensure all aspects of product use are considered, a user cycle was developed. This visually lays out the operations that the user must perform and the positions that the tablet will be in.
Use Cycle

Use Cycle

System Design

As more details are added to our concepts, the overall architecture of the system is becoming more specific. The system architecture shows all components and how they fit together.
System Architecture

System Architecture

Input and Source

  1. Selected Concepts
  2. Feasibility Models
  3. System design and interface definitions

Output and Destination

  1. Complete hierarchy of design files from system level down to components
  2. Bill of Materials
  3. Software design that specifies coding requirements
  4. Test plans

Bill of Material (BOM)

The BoM was developed from the System Architecture above. This spreadsheet shows all parts and sub-assemblies with their unique part number, and details material selection and manufacturing process.
Bill of Materials

Bill of Materials

The full spreadsheet can be found here

Input and Source

  1. PRP.
  2. Design Files.

Output and Destination

Completed BoM and Budget

Test Plans

Preliminary Testing comprises of computer simulations and engineering analyses to ensure proper and safe function of the device. Human testing will be conducted in three stages, excluding free-form opinion-based feedback.

Stage 1: Testing with neuro-typical college students Stage 2: Testing with adults on the Autism Spectrum Stage 3: Testing with children on the Autism spectrum

Each stage of testing will comprise of similar flow.

Overall Flow of Testing:

  1. Exploration Period (5 minutes)
    • Free play with device
  2. Task Period (10 minutes)
    • Performing a series of tasks
  3. Survey Period (10 minutes)
    • Answering survey questions via tablet

Full text of the Test Plans can be found here

Inputs and Source

  1. Engineering Requirements.
  2. Test standards.
  3. Feasibility Models.

Outputs and Destination

  1. Report that summarized the degree to which Eng Reqs are satisfied.
  2. Assessment of accuracy of feasibility models.

Risk Assessment

The user risks posed in the beginning of this semester can be categorized into design risks and behavioral risks. As a team we have concluded that, as the design progresses and part geometries and dimensions are solidified, the design risks, such as RU01-04 can be mitigated. However, given that the population we are testing with has behavioral difficulties, the behavioral risks cannot be mitigated. For example, RU08, describing meltdowns as a risk, cannot be mitigated because this is based on the mood of the individual child at the time of testing. We can, however, attempt to decrease the severity of the risk by designing a system with these in mind.

Design Review Materials

Presentation for DDR

Agenda for DDR

Plans for end of semester/ winter break

Schedule for Winter Break

Schedule for Winter Break

Plans for next semester

Schedule for MSDII

Schedule for MSDII


Home | Planning & Execution | Imagine RIT

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

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