/public/

Project Readiness Package

Table of Contents 1 Administrative Information 1.1 Change Control 1.2 Project Continuation 1.3 Project Overview 1.4 Staffing Requirements 1.5 Continuation, Platform, or Building Block Project Information 1.6 Principle Sponsor or Sponsoring Organization 2 Detailed Description 2.1 Customer Needs 2.2 Customer Deliverables 2.3 Customer and Sponsor Involvement 2.4 Regulatory Requirements 2.5 Project Budget and Special Procurement Processes 2.6 Intellectual Property Considerations 2.7 Engineering Specifications 2.8 Safety Constraints 3 Detailed Course Deliverables 3.1 Overall Deliverables 3.2 Deliverables Breakdown 4 Preliminary Work Breakdown 5 Grading and Assessment Scheme 6 Three-Week SDI Schedule 7 Required Resources

This document describes and serves as a template for preparation of a Project Readiness Package.

The objective of the Project Readiness Package is to document:

• Customer needs and expectations
• Project deliverables (including time frame)
• Budget
• Personnel / organizations affiliated with the project

It will serve as the primary source of information for students necessary during Phase 0 (Planning) to develop a SD I plan and schedule including specific deliverables and due dates. The Project Readiness Package will also support Faculty evaluation of project suitability in terms of depth, scope, and student / faculty resources by discipline.

Administrative Information

Proposal Number

Project Name: Vehicle Data Acquisition (DAQ) Subsystem

Project Number: P07301

Track: Systems and Controls

Start Term: Fall 2006-1

End Term: Per Team's availability Winter 2006-2 or Spring 2006-3

Faculty Guide: Reddy (pvreee@rit.edu)

Faculty Consultant: Slack (gbseee@rit.edu)

Customer organization: KGCOE

Customer contact information: Dr. Hensel 475-7684, echeme@rit.edu.

Principal sponsor: Harris

Change Control

Page #	Date	Change Description	Individual
2 of 7	10/02/2006	Change Analog Outputs from 24 to 8.	George Slack

Project Continuation

Project Overview

The Data Acquisition (DAQ) subsystem is one of a family of subsystems to support planned and future vehicular and robotic platforms, specifically P07201, P07202 and P07203 Senior Design projects for current projects. The goal of the Data Acquisition Subsystem Team is to design, build and test Electronics and associated Code to support missions from various KGCOE faculty and student vehicular and robotic clubs and events in the future without the need to redesign. This project shall be sufficient robust to enable scalability, programmability, reusability and reliability.

Staffing Requirements

Discipline	Number of Students	Skills Required
EE	4	Analog and Digital data acquisition control, Signal Conditioning Daughter Boards, Power Circuitry and Performance Architecture, Interface between Vehicle PC 104 DAQ and PC104 Processor.
CE	2	Linux O/S (or similar) & DAQ Functions Software, Client Network Driver interface (PC104 Processor PCB to external PC)

Continuation, Platform, or Building Block Project Information

N/A

Principle Sponsor or Sponsoring Organization

KGCOE departments: Mechanical, Electrical and Software Engineering.

Detailed Description

To design and develop a robust and reusable PC104 DAQ PCB and software to support Analog and Digital sensors for future vehicles and robots. The project design will be scalable to support to support 10 Kg and 100 Kg weight vehicles. The PC104 DAQ should be designed to support the eventual use from 1000 Kg weight vehicles but can not be thoroughly tested since these motors and associated sensors will not be available. Also, the DAQ PCB will monitor down to 1kg robots. (Current and future platform categories are 1000 kg, 100 kg, 10 kg, 1kg weights.) The DAQ PCB is one of a family of subsystems to support planned and future vehicular and robotic platforms. The goal of the DAQ Subsystem is to design, build and test I/O Circuits, Sensor interface and associated Diver Code. In order to support a wide range of vehicle platforms, this project shall be scalable, programmable, reusable and reliable. The driver code shall form the foundation for future projects that are specific to software applications and future actuator devices.

Customer Needs

PC104 Platform Architecture

• PC104 form factor Processor PCB shall be defined and supplied to this project team.
• The DAQ PCB to be designed shall be a family member along with Motor Controller Subsystem, future Vehicle Function and future Communications Subsystems.
• DAQ Subsystem circuitry shall be on PC104 form factor circuit board(s).
• Every effort should be made to place all circuits on one form factor board unless there is a circuit space issue or there is a logical reason to separate (i.e. future upgrades).
• Daughter PCB architecture will aid in scalability and compatibility.

DAQ Controls

• The module will acquire, condition and then communicate data to the PC104 Processor board. Data will be buffered on PC104 Processor PCB or communicated to a PC depending upon the final team architecture. Optional requirement to be defined is to analyze and present data.
• DAQ I/O channel types

Function	Channels	Range	Performance	Resolution	Notes
Analog Voltage	24	0-12 v	20 K sps/ch	12 bit
Analog Voltage Outputs	8	0-5, +/-15V	100hz/ ch	12 bit	Sink and source 10ma/ch.
Analog Current Outputs	8	4-20 ma	100hz/ ch	8 bit	Current Loop and Voltage compliance
Digital Outputs	16 (min)	TTL/CMOS	100hz/ ch	na	Sink and Source 10ma/ch. Footnote
Digital Inputs	16 (min)	TTL/CMOS	100hz/ ch	na	Presumed to interface to external conditioning circuitry.

Footnote = devices may be Solid State Relay, Optical Isolator or other vehicle control devices.

Temperature Signal Conditioning

• To add flexibility to the Data Acquisition board, the two daughter board types for signal conditioning listed below. The Data Acquisition board will have two daughter board connectors.

1. Each daughter board will have 8 channels.

2. Two temperature daughter types are:

• T & K , Thermistor
• T/C Thermocouple Cold Junction Compensation

3. Load Cell daughter board for 4 pressure sensor types. Contact Customer for ranges.

Board Performance

• Given the PC104 processor performance, the Vehicle Data Acquisition PC 104 PCB shall not require more than 25% of the total processing capability.

Power Requirements:

• 12V rechargeable with 1 hr run time.

Client Interface

• Via a given software application running on or interfaced through PC104 Processor PCB (supplied), DAQ PCB shall communicate in a timely manner with no loss of data. The DAQ Controls will enable data export that PC 104 or external PC can use without data manipulation (i.e. spreadsheet, performance graphing).

Other actuator functions

• Depending upon Customer meetings with Dr. Hensel (and potentially faculty he recommends you contacting), other DAQ ports may be needed.

Customer Deliverables

SDI: Proposed concepts and planned final design for customer review and approval, final detailed design concept for customer approval. At a minimum, PC-104 based system should be created that conditions and gathers various vehicle sensory devices and demonstrates proposed functionality. Software and hardware architectures should be defined and documented and necessary development systems specified including cost and availability. Preliminary test plan to be conducted and approved by Customer at time of final delivery will be completed and approved.

SDII: Prototype that has been tested with final user, requirements met and verified as per documented test plan. Design Manual that future teams can apply to their project without the need to rethink this Controller.

Customer and Sponsor Involvement

Sponsor: provide funding. Customer: provide input on his own needs and capabilities regarding the project, provide access to sensors and devices for team to apply to their design. Very involved in the day to day activities from both a customer needs to design to final debugging and demonstration.

Regulatory Requirements

At Customer's direction, team may need to research club or event rules.

Project Budget and Special Procurement Processes

All expenditures will be paid by KGCOE.

Intellectual Property Considerations

None. Project design will be open sourced on RIT website.

Engineering Specifications

NA

Safety Constraints

NA

Detailed Course Deliverables

SDI

Objective: Following the product development process, develop customer needs and engineering specifications, evaluate concepts, resolve major technical hurdles, and employ rigorous engineering principles to design an alpha prototype. Develop a design verification plan and fully document design.

1. Phase 0 Planning: SDI project plan / schedule including specific deliverables and due dates (wks 1-3)

2. Phase 1 Concept Development: Detailed, quantitative target specifications mapped to customer needs. (wks 1-3)

• EE / CE: Power, voltages, current, cost, size, environmental conditions, noise, cost, safety, detailed performance specifications. All functionality should be defined with quantitative specifications.

3. Phase 1 Concept development: Develop multiple concepts (on paper) and select most feasible. Update specifications. Customer Feedback. (wk 4)

• EE / CE: High level block diagrams, rough schematics, power budget, space budget, critical component requirements, serviceability & maintainability Design.

4. Phase 2 System-Level Design: System design including architecture, sub-system definition, interface definition, and more detailed specifications. Appropriate engineering analysis including hand calculations and simulation / modeling. Determine greatest challenges / risks to project (wk 5)

• EE / CE: More detailed block diagrams, schematics, SPICE simulations, matlab modeling (if applicable), memory requirements, processor speed calculations.

5. Phase 2 System-Level Design: Proof of concept breadboard, brassboard, or simulation of high risk technologies defined in 4. Use appropriate discipline specific methods to demonstrate confidence in selected architecture / design approach. Design review including risk assessment for technology / cost / schedule. (wks 6-7)

• EE / CE: Physical hardware of key / high risk sub-systems, development board evaluation of DSP algorithms, sketch of connectors and harnessing.

6. Phase 3 Detail Design: Detailed design to meet all customer needs. All long lead items should be identified for ordering. Design review. (wks 8-9).

• EE / CE: Final ORCAD schematics, BOM, detailed SPICE, Matlab (if applicable), etc. simulations coupled with implementation plans, particularly project schedules and risk assessments.

7. Phase 3 Detail Design: Detailed test plan with linkage to engineering specifications and customer needs. The results of this plan should demonstrate the design meets all customer needs and translated engineering specifications (both high level specifications and cascaded sub-system specifications). (wk 10)

• EE / CE: Step by step plan to fully characterize developed electronic system against all specifications and customer needs.

8. Phase 3 Detail Design: Project plan for SDII (wk 10).

9. Phase 3 Detail Design: Project review (wk 10).

SDII

Objective: Following the product development process, build an alpha prototype and demonstrate performance meets specifications. Fully document alpha design and verification testing.

1. Phase 3 Detail Design: Finalize full system design. Design review. (wks1-2)

• EE / CE: PCB layouts, thermal management, cabling, packaging

2. Phase 4 Testing and Refinement: Full feature / function alpha prototype (wks 3-6)

• EE / CE: Assembled PCBs, PC interfaces, etc. Prototyped system

3. Phase 4 Testing and Refinement: Design Verification testing. Execution of detailed test plan with results documented. Design Review and prototype demo. (wks 7-8)

4. Phase 4 Testing and Refinement: Design History File completion (EDGE web site). Generation of conference paper and poster that cover customer needs, specifications, highlights of design, results of design verification testing, and future work. (wk 9)

5. Phase 4 Testing and Refinement: Project review (wk 10)

6. Phase 4 Documentation: Product Manual.

Overall Deliverables

Deliverables Breakdown

Preliminary Work Breakdown

EE - Analog and Digital data acquisition control

EE - Signal Conditioning Daughter Boards

EE - Power Circuitry and Performance Architecture

EE/ CE - Interface between Vehicle PC 104 DAQ and PC104 Processor

CE - Linux O/S (or similar) & DAQ Functions Software

CE- Client Network Driver interface (PC104 Processor PCB to external PC)

Grading and Assessment Scheme

For general guidelines, see https://edge.rit.edu/content/Senior%20Design%20I/public/Grading.

Grading will be as indicated on the standard grade form. Additional graded deliverables specific to this project include a complete Product Manual. These will be included in the Deliverables category for SDII.

SD I

Average expectations ( C ) System functional specifications, software and hardware engineering specifications, software and hardware architecture development, proposed selection of hardware and software development materials and tools, completed test and verification document.

Above average expectations ( B ) Average expectations plus PC 104 control software and hardware designs (flowcharts, software specifications, schematics) feasibility assessment documenting the optimal design based sound engineering and prototype empirical data and power/lifetime estimates, baseline software that demonstrates interaction with sensors and devices, completed bill of materials suitable for ordering necessary development materials and tools.

Excellent ( A ) Above average expectations plus demonstration of Client PC and/or PC 104 Application Software that will not only control but will also monitor and log sensor functions. Design warning indicators or messages that indicate input devices are running outside its control parameters (i.e. temperature, speed and so on). DAQ functions will be designed to be sufficiently flexible to monitor expected larger vehicles that are proposed for future use. Apply or test using a commonly available Graphic User Interface Application running on an external PC (or PC104) that can analyze and present data.

SD II Average expectations ( C ) Prototype system that meets functional requirements according to relevant test specifications that demonstrates proof of concept.

Above average expectations ( B ) Average expectations plus implement design functions from the ( B ) description above SD I.

Excellent ( A ) Above average expectations plus implement design functions from the ( A ) description above SD I.

Three-Week SDI Schedule

• A general plan to learn PC104 architecture and functions.
• Gathering Customer Needs.
• Cross project team discussions and plan with other Fall Senior Design projects had may have parallel Customer Needs.
• Course Deliverables Phase 0.
• Recommendation of DAQ I/O signals to be designed.
• Basic project architecture assumptions and associated preliminary assessment as to the do ability (verbal or written buy-in with Customer, Consultant(s), and Guide).

Required Resources

Faculty/Consultants

Source	Description	Available
RIT	will be the principal contact person for the Team, will meet with the team weekly, will meet with individual members as needed, will be actively engaged in the design and review processes. G. Slack	Yes
RIT	will meet with the team weekly, will meet with individual members as requested by student, will be actively engaged in the design and review processes. Dr. Reddy, Consultant.	Yes

Customer

Source	Description	Available
RIT	will clarify requirements, interpret and consider trade-offs. Dr. Hensel	Yes