Raytheon Senior Project Critical Design Review

Critical Design Review for Senior ProjectMarch 23, 20121 of 41

Raytheon Senior ProjectCritical Design Review

Jarret Allen Luis Cintron Michael Kubacki Robert Skinner

Department of Computer Science and EngineeringUniversity of South Florida

Tampa, FL 33620

[email protected]@mail.usf.edu

[email protected]@mail.usf.edu


Agenda

• Final System Design Overview

• Detailed Design of System Components

• Risks Associated with System Components

• Brief Outline of Test Plan

• Development Information

• Project Schedule


System ComponentsPower

Adafruit’s Components

2-Port USB Module

FTDI V2DIP2-48

Case Android 2.3.4+ Phone USB Mass Storage Device

Final System Overview


Physical Interfaces CompatibilityFinal System Overview

x

5v vdd input

gnd

Power


Physical Interfaces CompatibilityFinal System Overview

5v

5vgnd5v500ma

V2DIP2-48(USB Host Module)

Android 2.3.4+ Phone

USB Mass Storage Device

Adafruit'sMinty Boost

( + & - terminals connected to vdd & gnd inputs on V2DIP2-48 )

USB Type-A Inputs


Software Libraries/InterfacesFinal System Overview

AndroidOpen Accessory

Protocol

FTDILFAT Driver

Overview


Android Application FlowchartFinal System Overview


Android Application StructureFinal System Overview


Android Application ScreenshotsFinal System Overview


System Communication

AndroidDevice

V2DIP2-48(USB Host Controller)

Mass StorageDevice Memory USB

Port 1USBPort 0

ProductApplication

User

Hardware

Memory

Final System Overview


Very Brief System Communication OverviewFinal System Overview

1. The FAT API on the Vinculum-II device performs a linear scan of the file system and transfers this data (strings of filenames) to the Raytheon Senior Project Application (RSPA) on an Android 2.3.4+ phone

2. Navigating to a new directory in the RSPA requires the file data for the new directory to be streamed from the Vinculum-II device to the RSPA

3. Once a file is selected, it must be transferred from the USB mass storage device through the Vinculum-II device to the RSPA to be emailed


DETAILED DESIGN OF SYSTEM COMPONENTS


V2DIP2-48USB Host ControllerFTDI Vinculum-II Operating System

Overview• Link between Android and Bulk-Only Mass Storage (BOMS) devices.

• Provides power to both USB connected devices. It is powered with a 5v 500ma battery input from MintyBoost power device

• Performs message passing between V2DIP2-48 firmware and the Android application via the Android Open Accessory Protocol to transfer data such as file/directory names and file data.

Capabilities• Built-in drivers to implement Android Open Accessory Protocol and support USB

hosting.

• Support for FAT16, FAT32, and long file names using the FTDI LFAT API.

• Supports a low-power sleep mode to conserve energy.

• Enables significant control over USB data transfer (low-level manipulation)

Detailed System Component Design


V2DIP2-48USB Host Controller


• Dimensions (l x w x h)• 18mm x 69mm x 26mm

• The pins will be removed to reduce volume

• Power• 5v 500ma provided by Minty Boost

• Minty Boost is supplied power from 2 AA batteries

• Unit Cost• $28.76

• Allows development of custom firmware• Provides 2 Type-A USB ports• Easily programmed using external USB programmer/debugger module


V2DIP2-48USB Host ControllerVinculum-II Driver Model


BOMS Driver

USB Host Driver

VOS Kernel

USB Host Hardware

Provides an interface between a file system (FAT) and a USB disk (flash drive or hard drive).

The USB host driver can control both USB ports. When a device is connected it is automatically enumerated by the USB Host Driver.

The Vinculum-II OS. A pre-emptive priority-based multi-tasking OS. Supports priority-based tasks, tasks switching (round-robin), task synchronization, and a device manager.

The V2DIP2-48 module that contains two Type-A USB ports.


V2DIP2-48USB Host ControllerVinculum-II Firmware Model


VOS Kernel

USB Host Hardware

Raytheon Firmware Code

Device Manager

Device Drivers

Android OpenAccessory Protocol

LFATAPI


V2DIP2-48USB Host ControllerCommunication with Android Open Accessory Protocol


Data is matched between the firmware and Android application to ensure compatibility:

Data is written to the Android device using a write function with a handle to the device, a pointer to data to be written, and the number of bytes sent:

Strings match in the Android Java code

Only one line of code to send data

Data transfer in the firmware is fairly simple...


Power (Adafruit’s Mintyboost based)

• MintyBoost schematic and Adafruit's PCB circuit• 5V Output• 500mA • 2 x AA Batteries in series• Uses 5V DC converter

• Originally a USB-based charger, repurposed to provide power to our device’s VDD and GND pins.



Power Module SchematicDetailed System Component Design


CaseDetailed System Component Design

• Manufactured with 3d printing technology• ON/OFF rocker switch and LED power indicator• LEDs to indicate File Copy Activity and Power


Android PhoneDetailed System Component Design

• Android Open Accessory Protocol is backwards compatible to Android 2.3.4 Fully supported in Android 3.1+

• The V2DIP2-48 is an "Android USB Accessory"• Powers the bus and enumerates devices

• Android accessories must provide 500ma at 5v• Performed by MintyBoost power supply

Limitations:• Accessory mode support in Android 2.3.4 is ultimately dependent on the device's

hardware

• Although the majority of devices support Android Open Accessory Protocol


RISKS ASSOCIATED WITH SYSTEM COMPONENTS


Risk

V2DIP2-48• The chip may use too much power while looping continuously

looking for connected devices– This will be determined during testing and a larger power supply may be

needed

Minty Boost• Even with code improvements, the device draws too much

power to meet requirements– MintyBoost can work with C and D batteries as well so moving to a larger

battery would be our best option, including a case redesign

System Component Risks


Risk

Android Device• An Android 2.3.4 phone does not have the Open Accessory

Library installed– Manufacturers can choose whether or not to include this library when the

phone is manufactured and there is no method to install this library as a user.

USB BOMS Device• Device does not use FAT file format

– The V2DIP2-48 can only process FAT formatted BOMS devices. Most are FAT16 or FAT32 devices.

– The LFAT library supports long filenames



Risk

Case• 3D printing does not create a durable enough case to suit our

needs– Purchase a pre-made durable case and add holes for our input/output as

necessary

• The case traps too much heat– Redesign the case with better ventilation



BRIEF OUTLINE OF TEST PLANMore detailed testing procedures are

located in Test Plan v1.01www.cse.usf.edu/raysp

These section is designed to summarize the extensive testing procedures presented in the document.

http://www.cse.usf.edu/raysp


Brief Outline of Test Plan

General Best CaseAnalyzing an overview of system communication, the best case for various scenarios can easily be determined:

• The best case for the USB mass storage device linear scan would be an empty mass storage device or, in the case of complete program operation, one file on the mass storage device.

• The best case for data transfer both to the phone and across the network would be the minimum supported file size of the file system and the maximum speed data network connection supported by the Android 2.3.4+ device.

• Directories with large list of files will take longer to navigate, as more data must be transferred to the user interface on the Android 2.3.4 device.

• Thus, one root directory with no files would be the best case for overall system operation.



General Worst CaseAnalyzing an overview of system communication, the worst case for various scenarios can easily be determined:

• Because the FAT API performs a linear scan of the files in the current directory, the worst case would be the maximum number of files in a directory each of the minimum supported file size.

• The worst case for file transfer to the phone and across the network would be a file of the maximum size supported by the file systems present (on the Android device and the USB mass storage device).

• The speed of the file emailed is dependent upon the data network speed.



General Corner Cases• The Vinculum-II module should be tested to verify it is capable of

operating in various conditions such as varying battery power levels, environment temperatures, durations of time, with various USB devices (not the expected Android phone or mass storage device), and combinations of these configurations.

• The FAT API firmware should be tested with no files present, one file present, and many files present.

• The RSPA should be run without the Vinculum-II module attached, with no data connection, and other limitations on successful program operation to ensure it gracefully exits and accurately reports the problem to the user.



Traceability to RequirementsUnit Testing

1. Volume requirement of at least 621cm3 will be tested by measuring the volume of the completed device.

2. Weight requirement of less than 300g will be done through testing by weighing the device. Requirement of the system being self-powered will be done by inspection by showing that the unit is on without any external wires.

3. The Android application’s ability to send emails can be demonstrated by emailing a file stored on the Android device.

4. The Android application’s ability to send MMS can be demonstrated by sending a file stored on the Android device.

5. The VF2F2’s ability to transfer files from the mass storage device to the Android device can be demonstrated by successfully transferring a file.



Traceability to RequirementsIntegration Testing

6. Compatibility with Android 2.3.4+ will be demonstrated by showing that data transfer can be exchanged between the mass storage device and a version 2.3.4 Android phone.

System Testing

The system processing different media files of different types will be done through demonstration by transferring a diverse group of files.

7. The locating a file on the mass storage device in 5 seconds will be tested by timing of retrieval for several different files and recording elapsed time. Times will be averaged to determine average-case retrieval time.

8. The transfer of a 3Mb file from the mass storage device to the Android phone in 5 seconds will be tested by timing of retrieval for several different files and recording elapsed time. Times will be averaged to determine average-case retrieval time.



Traceability to Requirements9. The sending of a file on the Android phone in 5 seconds by email will be tested by timing of sending for several different files and recording elapsed time. Times will be averaged to determine the average-case retrieval time.

10. The sending of a file on the Android phone in 5 seconds by MMS will be tested by timing of sending for several different files and recording elapsed time. Times will be averaged to determine average-case retrieval time.

11. The ability to transfer files at a distance greater than two meters can be demonstrated using a USB cable measured to greater than two meters to successfully transfer a file from the mass storage device to the Android phone.

System Integration Testing

12. System Integration with multiple mass-storage devices can be demonstrated by testing system functionality when any mass-storage device is being used.

13. System Integration with multiple Android phones can be demonstrated by testing system functionality with any 2.3.4+ Android phone.



Requirements Summarized

1. AssumptionsGEN01 (GEN01a, GEN01b), GEN03, GEN05, SYS19

2. RequirementsThe seven overall requirements for this project are (please note, a specific requirement may fall under two overall requirements):

Project Advancement RequirementsGEN02,GEN04 (GEN04a, GEN04b, GEN04c), TEST06 System Compatibility RequirementsSYS01, SYS02 (SYS02a, SYS02b, SYS02c, SYS02d), SYS03, SYS09 (SYS09a, SYS09b, SYS09c), SYS11 (SYS11a, SYS11b, SYS11c, SYS11d) System Performance RequirementsSYS04, SYS05, SYS06, SYS07, SYS08, SYS09 (SYS09a, SYS09b, SYS09c), SYS10, SYS12, SYS13, SYS18

The requirements presented by Raytheon in Raytheon Project Specification REV20111231 have been organized as follows for simplicity:

http://www.cse.usf.edu/raysp/docs/RaytheonSpecsRev20111231.pdf



Requirements SummarizedSystem Physical RequirementsSYS13, SYS16, SYS17, SYS20 System User Interface RequirementsSYS14, SYS15 Testing RequirementsTEST01, TEST02, TEST03, TEST04, TEST05, TEST06, TEST07, TEST08, TEST10, TEST11 Project Documentation RequirementsGEN06a (GEN06aa, GEN06ab, GEN06ac), GEN06b, TEST01, TEST07



Traceability to Requirements

• The traceability matrix has columns represented by the requirement numbering in the previous "umbrella" requirements

• Some "umbrella" requirements have been removed that are not tested such as Project Advancement Requirements

• The rows specify the tests described previously

Simple Traceability Matrix


DEVELOPMENT INFORMATION


Development Information

How to Find Development ProgressProgress is updated on our project Web site at www.cse.usf.edu/raysp

Bitbucket is used a Distributed Version Control System as our code repository for Android development

A feed from Bitbucket shows live updates to the Android code on the Web site.

A development log is updated on the Web site with firmware development updates.

All documents are available on the project Web site.

http://www.cse.usf.edu/raysp/


Project planProject Plan

Raytheon Senior Project Critical Design Review

Documents

Transcript of Raytheon Senior Project Critical Design Review