nh3fc_project_propos
Post on 18-Dec-2014
111 Views
Preview:
DESCRIPTION
TRANSCRIPT
Ammonia Fuel Cell CarTeam 5
October 31, 2006Prepared in partial fulfillment of the requirements for EE495A Capstone Senior Design
Faculty Advisor Graduate AdvisorDr. Jim Zhu Tim Delashmutt
______________________________ ______________________________
Undergraduate Team MembersKyle Bray Brian Micochero Chuck Huizenga Tyler Thompson
20
Table of Contents
Section Page
1. Project Description ??
1.1 Background ??
1.2 Need and Goal Statements ??
1.3 Project Scope ??
2. Technical Approach ??
2.1 Statement of Requirements ??
2.2 Detailed Technical Approach ??
3. Management Approach ??
3.1 Team Organization Structure ??
3.2 Work Breakdown Structure ??
3.3 Schedules ??
3.4 Resource Allocation ??
3.5 Risk Mitigation Plan ??
4. Summary ??
5. References ??
2
Section 1 – Project Description
1.1 Background
The petroleum industry is in dire conditions. Based on the current proven
petroleum reserves and rate of petroleum production, the world is expected to run out of
petroleum in less than 50 years. This is show in figure 1.
Figure 1. (BP Statistical Review of World Energy June 2006)
Alternative energy sources will be required to take the place of the petroleum
industry. The current proposed alternative energy sources present new logistical
problems. For instance, a wind turbine generator can not be mounted on an automobile.
Instead, an energy carrier like petroleum will be needed. At first glance, batteries would
be a good solution for transferring the generated energy to automobiles. Unfortunately,
the best battery chemistries do not have enough energy density to allow for a long enough
3
driving time. Also, batteries must be charged, which takes hours, unlike a refuel of
gasoline which take seconds. Furthermore, batteries use elements which can be
hazardous to the operators and the environment. A better energy carrier solution that
many researchers are focusing on is hydrogen. Hydrogen can be converted to electricity
through a device known as a fuel cell. The most basic fuel cell, know as the PEM or
proton exchange membrane fuel cell, figure 2, only has a byproduct of water, making it
safe for the vehicle operators and the environment. This is because the reaction that
drives the process is,
2H2 + O2 → 2H2O
The drawback with hydrogen is its
transportation. Hydrogen gas is explosive
and can lead to disaster, like the
Hindenburg blimp. The solution is to
transport the hydrogen in a liquid or solid
form. Vast amounts of research are
currently going on in this field. A popular method is to use methanol. Unfortunately,
methanol has some drawbacks. It has more dangerous byproducts and requires a more
complicated fuel cell or a reformation stage. In our overall project, we are using a novel
approach of electrolyzing ammonia to create the hydrogen. Ammonia is NH3, which has
the byproducts of nitrogen and water. Both components are safe to the user and the
environment.
The ammonia fuel cell vehicle has several subsystems that will need to be
controlled. These include the AEC or ammonia electrolytic cell, the PEM fuel cell,
Figure 2 (wikipedia.com)
4
battery pack, the motor controller, the motor, and the vehicle. Our main objective is to
produce an onboard computer that is capable of controlling all of these subsystems in
real-time in order to build a functioning vehicle. This requires us to develop the
computer software and the interface to each subsystem. We will be working with an
interdisciplinary team to develop this in a senior capstone design course.
The senior design course focuses on the life of a project. Meaning, we will
virtually see the project go from inception to a final report. This includes a project
proposal; several design iterations, safety procedures, testing, and a final report. These
are important processes in a systems engineering environment.
1.2 Need and Goal Statements
Goal
Develop an onboard computer to interface with each subsystem at the sensor and actuator
level to enable on-demand hydrogen production and vehicle operation.
1.3 Project Scope
Objectives
Develop the computer hardware architecture.
Develop the software architecture
Develop the interface protocols.
Implement control algorithms for each subsystem.
Design and implement user interface.
5
Tasks
1. The computer hardware shall be selected.
2. An interface protocol shall be selected.
3. A real-time operating system shall be selected and installed onto the hardware.
4. Documentation shall be provided in a project binder.
5. The operating system shall be programmed with necessary code.
6. A user interface panel shall be implemented for the vehicle operator.
Constraints
Time – May 15, 2007 deadline
Money – $500 + Customer Funds
Personnel – 4 UG’s + 1 grad student
Volkswagen chassis
Honda Insight battery pack
Ballard PEM fuel cell
10 kW brushless DC motor
Deliverables
Computer to interface and control subsystems
Project binder including notes, meeting minutes, design reports, testing reports,
and review briefings
Operator’s manual with instruction sets and descriptions of computer system.
6
1.3 Statement of Work (SOW)The work will be accomplished by an electrical engineering senior design team
within an interdisciplinary group. The following statements detail the work that shall be
accomplished by the senior design team and their relationship with the interdisciplinary
group.
1. A computer capable of running a real-time operating system and capable of
interfacing with external systems shall be chosen and acquired.
2. A real-time operating system shall be acquired by the senior design team.
3. The real-time operating system shall be imaged onto the computer by the senior
design team.
4. The computer and interface shall be chosen to minimize size, cost, power
consumption, and weight.
5. The senior design team shall perform trade studies to determine the most suitable
computer system and interface providing reliable operation.
6. The senior design team shall provide the necessary software for the real-time
computer.
7. The interface between the computer and the external systems shall be developed
by the senior design team. This interface may include external microcontroller
boards to interface with the systems. The boards shall be developed by the senior
design team.
8. The senior design team shall participate in a preliminary design review, a critical
design review, and a final design review.
7
9. The senior design team shall conduct the following project reviews per the EE495
design schedule: SRR, PDR, CDR, TRR’s, and FDR.
10. The senior design team shall provide full documentation including a users’
manual, computer system documentation, and final report.
11. The senior design team shall perform tests to validate the computer and interface.
12. The interdisciplinary group shall provide the senior design team with the actuators
and sensors the senior design team will interface with. The success of the
computer system is contingent upon this information.
13. The senior design team shall design the computer to allow control algorithms to
be implemented by the customer. The current customer is Tim Delashmutt, a
Graduate student working on this project.
14. The senior design team shall create a user interface. This interface will display
data to the user.
15. The senior design team shall develop the computer system to interface with the
equipment provided by the interdisciplinary group.
8
Section 2 – Technical Approach
2.1 Statement of Requirements
Functional Flow Diagram Levels 1 and 2:
The functional flow diagram shows the operation of the overall system. As seen
from the diagram the team is to implement an operating system capable of controlling the
vehicle. Involved in the control is both the sensing of the subsystems and the response of
the computer to manipulate the actuators that control the subsystems.
All value and subsystems are initiated when the operating system boots up. This
has to be designed to initialize in both hot and cold starts. A cold start is the normal
stationary start and a hot start is a start that occurs while the car is already in operation.
Following the initialization the execution of the software modules will take place. This
execution will execute all of the software modules in real-time.
1.2Execution of
Software Modules
1.1Initialization
1.0 Operating System Level 1
Level 2
The Operating System shall coordinate all tasks.
Program variables shall be initiated during startup and hot reboots.
All software modules shall be executed in real-time.
9
Functional Flow Diagram Level 3
As seen from level 3 of the functional flow diagram each subsystem has its own
software module. The loop represents the continuous cycle that the computer will
accomplish to sense and actuate the different subsystems.
Performance Requirements:
• The prototype car shall run for 30 minutes without refueling.
The vehicle is expected to run for at least 30 minutes without needing to be refueled.
This is necessary to allow enough time to collect a wide range of data from the
subsystems. A shortfall in data collection would not provide enough information to
reliably say in the ammonia fuel vehicle is efficient.
Level 3
1.2.2Fuel Cell Module
1.2.1H2 Production
1.2.3Power Module
1.2.4 Motor Controller Module
1.2.5 Motor
Module
1.2.6Vehicle Module
Software Modules
Computer Initialization
OR
1.1.2Hot
1.1.1Cold
Perform Executions (Ref 1.2)
10
• The prototype car shall be capable of running at a speed of 40km/h.
The vehicle is expected to run at a speed of 40km/h. This is the necessary speed for the
fuel cell vehicle to be considered operating efficiently.
• The prototype car shall be capable of a maximum acceleration of 2 meters per
second squared.
The vehicle should be able to accelerate at this level. This helps prove the feasibility of
the vehicle in a consumer market.
• The on-board computer shall be capable of receiving data from each sensor and
manipulating each actuator within 20 milliseconds sampling time.
The computer is expected to be able to sense and actuate all the subsystems within 20ms.
If too much time goes on without any of the subsystems receiving a response the system
could crash.
Operational requirements:
• Digital display shall be provided for the vehicle operator.
A display will be provided so that the operator of the car can see crucial information.
The display shall display the following items:
Fuel
Mileage
Speed
Critical system parameters, such as
11
o Flow rate
o Temperature
o Pressure
• The on-board computer shall allow reprogramming of the control algorithms for
the vehicle subsystems.
The programs written for the computer and subsystems will be well documented. This
includes descriptive comments in the code as well as explanations of overall algorithm
implementation techniques. This requirement ensures that future users of the system will
be able to read past code in case re-programming needs to be done.
The computer shall have an emergency fail-safe stop procedure.
The computer will need to be able to shut down the vehicle immediately in case of an
emergency. It will need to do this either manually or automatically based on information
it receives from the subsystems. This will be implemented to make sure that no accidents
happen.
2.2 Detailed Technical Approach
The design will be accomplished by the team discussing several
different technical options for the computer system. In conjunction
with the team planning we will also be communicating with our
customer, the faculty advisor, on his specific needs and wants. The
group will work together to analyze the different design options and
12
pick the best approach to solving the problem. Once a specific path of
design is chosen we will then research the specifics for the design.
The group will divide the research topics ensuring each student is
researching an important component of the computer system.
Specifically trade studies will be made on computer types,
various hardware interfaces, real time operating systems, and
programming languages. Select criteria chart for trade studies:
Computer Trade Study Criteria
processor speed memory power consumption Other features
VIA EPIA-M10000 Mini-ITX
600MHz(fan less) Up to 1GBPCI expansion
slot
PCM-9386 Intel® Celeron® M 3.5" SBC
1GHz 128MB-1G 5V @ 2A
12V @ .02APCI, MIO, USB expansion slots
Hardware Interface Trade Study Criteria
I/O protocol speed cost power consumptionease of use
(1-easy, 4-difficult)
PIC16F I2C 20MHz <5W 1
PIC18F CAN 40MHz <5W 1
OS Trade Study Criteriafamiliarity (1-not familiar,
4 - familiar)
unnecessary features (1-little to
none, 4-a lot)disk space
QNX 3 1 7.8MB
LynxOS 1 2 90-100MB
Embedded Linux
2 2 8.2MB
Windows CE
1 3 360MB
Once the desired hardware and software components are
selected the group will be in the implementation stage. Each team
13
member will be assigned different implementation tasks. In addition to
the individual tasks the team will also coordinate to bring the entire
system together. The implementation stage will consist of:
Installing the OS onto selected computer
Designing hardware interfaces for each subsystem
Programming subroutines for each subsystem
Once these are implemented, simulations of the system will be done
ensuring there are no bugs or major problems. Following the
simulations, testing on the vehicle shall be done and data will be
collected on overall performance.
Reliability
Computer system shall perform satisfactorily
0.98 success probability.
Computer boots up
For duration of 30 minute test cycles,
o Computer runs, receives and logs data
o Computer controls and coordinates operational systems of
car.
Operates under normal human living conditions of temperature
and humidity
Athens, Ohio road test conditions
14
Mean time between failure: 50 test cycles, 25 hours running time
15
Maintainability
Preventative maintenance
o Computer operation shall not exceed 80% usage of
available memory.
o Components of control/feedback system shall be easily
accessible.
o All wired connections shall only require visual inspection
for maintenance.
Corrective maintenance
o Software maintenance shall be performed easily via
telnet/wired access.
o All sensors and actuators shall be accessible for
testing/debugging.
Usability (User is researcher)
The user interface shall display the necessary running-time
parameters to the user while not displaying too much data at
once.
All safety precautions associated with driving a car should be
followed.
Due to the high voltage on board the vehicle, users should not
touch any wires.
16
Safety Issues
Hazard – electrical shock
o Cause: high voltage and irresponsibility
o Effect: people die
o category IV hazard – catastrophic
o anticipated probability: very low
o preventative measures:
always have a partner when working,
double check connections,
tape or otherwise insulate exposed wires
Hazard – chemical burn
o Cause: exposure to excess amounts of ammonia
o Effect: skin damage
o category III hazard - critical
o anticipated probability: low
o preventive measures:
stay away from the ammonia
Hazard – pressure compromise
o Cause: leak in a pressurized hydrogen hose
o Effect: possible injury, various nature
o Category II – marginal
o Anticipated probability: low
17
o Preventative measures:
Assure that all couplers and seals in the charge tubing are
secure.
Hazard – exploding/burning chips
o Cause: error in connecting pins of a chip
o Effect: possible injury, various nature and definite loss of part(s)
o Category II – marginal
o Anticipated probability: low
o Preventative measures:
Have two people double check all electrical connections
before powering on a circuit.
Supportability
All inclusive user manual shall be delivered with the system.
Detailed project work summary for future debugging
As this project vehicle is primarily designed as a research tool, economic
produciblity is not a real concern. However, in the design, robustness is a major
deciding factor in searching for components to ensure a long life span for the
vehicle.
18
Section 3 – Management Approach
3.1 Team Organization Structure
The development of the subsystems of the vehicle will be divided into sections
that are composed of the subsystem’s tasks. Each team member will have a main section
they will be working on, as well as assisting the other team members on their sections.
The section leads shall be chosen by the best candidate according to the Team Structure
(see below). When making a decision related to the individuals’ section the section lead
will explain all options and suggest the best option. The team will coordinate to decide
the best course of action. Furthermore, the Team Leader shall be in charge of setting
meeting times, places, and meeting topics, as well as sending updates to the Faculty
Project Lead (Dr. Zhu) and the graduate student (Tim Delashmutt). The Task Manager
shall ensure that the meeting goals are accomplished and that the team stays on schedule.
The Resource Manager shall be in charge of the team’s budget, ordering parts, and
ensuring the team has all necessary equipment. The Secretary shall record all necessary
data and processes employed during the production, meeting times, and all information
needed for the user manual. The Safety Engineer shall ensure all equipment, parts,
chemicals, and processes will not damage property or cause an injury.
Team Structure and Responsibilities
Tyler Thompson – Team Leader, Power Electronics Engineer
Kyle Bray – Computer programmer, Graphical Designer, Resource Manager
Chuck Huizenga – Computer Programmer, Secretary, Computer Engineer
Brian Micochero – Controls Engineer, Task Manager, Safety Engineer
19
The graduate student (Tim) shall provide the team with all original project
documentation and help define the team’s mission, project needs, and constraints. Tim
will also be providing the team with the control algorithms that team will implement for
each sub-system.
The Faculty Project Lead (Dr. Zhu) shall provide the team with the team’s
mission, project needs, and project constraints. Dr. Zhu will also be observing the team’s
progress and consulting/guiding the team through the completion of each task.
The team may also be consulting members of the Ammonia Fuel Car team.
Chris Gregg- Mechanical Engineering graduate student
Dr. Greg Kremer – Mechanical Engineering professor
Dr. Gerardine Botte – Chemical Engineering professor
Madhivan Muthuvel – Post Doctoral Research Associate at the Electrochemical
Engineering Laboratory
Mahesh Biradar – Chemical and Biomolecular Engineering Graduate Student
20
3.2 Work Breakdown Structure
20
22
3.3 Schedules
Gantt chart
23
24
Pert Chart
25
26
27
3.4 Resource Allocation
We shall allocate our resources for optimal use of money, personnel, facilities, and
available equipment. In our budget breakdown, we have included on each level a buffer
of about 10-15% for overcharges, shipping, etc. Also, our personnel allocation figure is
not necessarily known at this time. Since our project is actually part of another larger
project, our facilities are well equipped with most of the necessary equipment needed.
Budget $500
Personnel 4 undergraduates
1.2 FTE per person
The team is currently spending 4 hours in class, 4 hours in meetings, and working about 4
hours a week on individual research and project work. During the winter and spring
quarters when we have less class meetings, we will spend that time in the lab working on
the project.
Facilities
Stocker NH3 fuel car lab (old eBobcat lab)
Stocker project design room
28
Equipment
Oscilloscope
Power Supply
PC
Function Generator
Soldering iron
Micro-controller Programmer
Most of the team’s funds will be spent early in the project schedule. The computer
system is the most expensive piece of hardware that will be bought, and it must be
purchased as early as possible because all other components are controlled through it.
The Microprocessors will also need to be purchased early so they can be programmed
and tested before implementation. Knowing this, the team realizes that any
miscalculations in these purchases will cause problems, in both the finances and the
timetable, later in the production of the vehicle.
29
3.5 Risk Mitigation Plan
1. Potential Risk Description:-CPU will arrive later than needed.
2. Source of Risk:-Lack of inventory-Shipping Problems
3. Consequences if Risk is Realized:-Project gets a late start
4. Risk Rankings:
Likelihood: 1 X 3 4 5Consequences: T 1 2 X 4 5
S 1 2 3 X 5C 1 2 3 4 5 Low ----- High
T=Technical, S=Schedule, C=Cost
Like
lihoo
d
5 high
4
3 med
2 T S
1 low
1 2 3 4 5
Consequences5. Risk Mitigation Steps:
-Purchase CPU as soon as possible-Check shipping progress
1. Potential Risk Description:-Need to purchase Software
2. Source of Risk:-Unable to get license
3. Consequences if Risk is Realized:-Reduction of budget
4. Risk Rankings:
Likelihood: 1 2 X 4 5Consequences: T 1 2 X 4 5
S 1 2 3 X 5C 1 2 3 4 X Low ----- High
T=Technical, S=Schedule, C=Cost
Like
lihoo
d
5 high
4
3 T S C med
2
1 low
1 2 3 4 5
Consequences5. Risk Mitigation Steps:
-Get license as soon as possible-Start considering other software
30
1. Potential Risk Description:-Information and commands are not processed at required speed
2. Source of Risk:-CPU is not capable of handling the desired speed-The I/O interface is too slow
3. Consequences if Risk is Realized:-System won’t function at required levels
5. Risk Rankings:
Likelihood: 1 2 X 4 5Consequences: T 1 2 3 X 5
S 1 2 X 4 5C 1 2 X 4 5 Low ----- High
T=Technical, S=Schedule, C=CostLi
kelih
ood
5 high
4
3 S C
T
med
2
1 low
1 2 3 4 5
Consequences5. Risk Mitigation Steps:
-Double check CPU data sheets-Develop an efficient I/O interface
1. Potential Risk Description:-User interface displays too much/little information
2. Source of Risk:-Too much/little information sent to the display
3. Consequences if Risk is Realized:-Inconvenience the operators and researchers
6. Risk Rankings:
Likelihood: 1 2 3 X 5Consequences: T 1 X 3 4 5
S X 2 3 4 5C 1 2 3 4 5 Low ----- High
T=Technical, S=Schedule, C=Cost
Like
lihoo
d
5 high
4 S T
3 med
2
1 low
1 2 3 4 5
Consequences5. Risk Mitigation Steps:
-Make sure all relevant information is displayed
31
1. Potential Risk Description:-Display difficult to see
2. Source of Risk:-Type of display used
3. Consequences if Risk is Realized:-Difficult for the operator to function
7. Risk Rankings:
Likelihood: 1 2 X 4 5Consequences: T 1 2 X 4 5
S 1 X 3 4 5C 1 2 3 X 5 Low ----- High
T=Technical, S=Schedule, C=CostLi
kelih
ood
5 high
4
3 S T C med
2
1 low
1 2 3 4 5
Consequences5. Risk Mitigation Steps:
-Find and implement the best quality display screen that can be afforded
1. Potential Risk Description:-System can not handle a “hot” reboot
2. Source of Risk:-Software problem
3. Consequences if Risk is Realized:-System will shut down during operation
8. Risk Rankings:
Likelihood: 1 X 3 4 5Consequences: T 1 2 3 X 5
S 1 2 X 4 5C 1 2 3 4 5 Low ----- High
T=Technical, S=Schedule, C=Cost
Like
lihoo
d
5 high
4
3 med
2 S T
1 low
1 2 3 4 5
Consequences5. Risk Mitigation Steps:
-Thorough Testing
Section 4 - Summary
32
SummaryBased on the current situation with petroleum sources the world is expected to run
out of petroleum in less than 50 years and as a result alternative sources of energy are
being studied. Batteries have been looked at as options but they do not provide enough
energy density to allow for a long drive. A better alternative energy source is hydrogen.
Our project specifically looks at converting hydrogen into electricity through a PEM fuel
cell. Current approaches use methanol which has some drawbacks. For our project we
are using the electrolysis of ammonia to create the hydrogen. The ammonia fueled
vehicle has several subsystems that need to be controlled. These include AEC or
ammonia electrolytic cell, the PEM fuel cell, battery pack, the motor controller, the
motor, and the vehicle. Our computer system will be monitoring and controlling these
subsystems.
The objectives for our project are to develop the computer hardware and software
architectures along with the interface protocols. We will also be implementing a user
interface for the vehicle operator. We have time, money, personnel, and equipment
limitations on our project. At the conclusion of the project we will be delivering the
computer itself that controls the subsystems. We will also be providing a project binder
and an operator’s manual with instruction sets and descriptions of the computer system.
Regarding functional requirements, our finished product shall comprise of a
computer that coordinates all subsystems of the vehicle in real time under all normal
operating conditions. Performance-wise, the prototype car shall operate for 30 minutes,
and shall reach a top speed of 40 km/h with an acceleration of 2 m/s2. The computer
system shall operate at a system rate of 50 Hz. The digital display shall display fuel
level, odometer, current speed, and other critical system parameters. The onboard
33
computer shall be versatile enough to allow reprogramming, as well as shut itself down in
an emergency situation.
We have been investigating trade studies on the single board computer and
accessories, hardware interface, and operating system. We have also outlined reliability,
maintainability, usability, and supportability issues. There are also very important safety
issues to be considered when working with dangerous voltage levels and harmful
chemicals.
Our team consists of 4 undergraduate students, Tyler Thomson, group leader and
power engineer, Kyle Bray, programmer and resource manager, Chuck Huizenga,
programmer and computer engineer, and Brian Micochero, controls engineer and task
manager. We also work in conjunction with an Electrical graduate student as well as
teams of mechanical and chemical engineers.
Section 5 – References1. BP Statistical Review of World Energy, June 2006
34
<http://www.bp.com/subsection.do?categoryId=9009525&contentId=7018033>
2. Romary, Utilisateur, Fuel Cell Image, 8 Oct 2004 <http://fr.wikipedia.org/wiki/Image:Fuell_cell.jpg>
35
top related