NH3FC_Project_Propos..

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

3.3 Schedules

Gantt chart

23

Pert Chart

25

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


Like

lihoo

d

5 high

4

3 T S C med

2

1 low

1 2 3 4 5


-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


-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


Like

lihoo

d

5 high

4 S T

3 med

2

1 low

1 2 3 4 5


-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


-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


Like

lihoo

d

5 high

4

3 med

2 S T

1 low

1 2 3 4 5


-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

http://fr.wikipedia.org/wiki/Image:Fuell_cell.jpg

http://www.bp.com/subsection.do?categoryId=9009525&contentId=7018033

NH3FC_Project_Propos..

Documents

Transcript of NH3FC_Project_Propos..