Inventory Control in Stores



Inventory Control in Stores

Fall 2005 Final Report

Team:

Dec05-09

Client:

Senior Design Program

Faculty Advisor:

Dr. Degang Chen

Team Members:

Jeff Benson

Frederick Brown

Christopher Reed

Brian Wagner

REPORT DISCLAIMER NOTICE

DISCLAIMER: This document was developed as a part of the requirements of an electrical and computer engineering course at Iowa State University, Ames, Iowa. This document does not constitute a professional engineering design or a professional land-surveying document. Although the information is intended to be accurate, the associated students, faculty, and Iowa State University make no claims, promises, or guarantees about the accuracy, completeness, quality, or adequacy of the information. The user of this document shall ensure that any such use does not violate any laws with regard to professional licensing and certification requirements. This use includes any work resulting from this student-prepared document that is required to be under the responsible charge of a licensed engineer or surveyor. This document is copyrighted by the students who produced this document and the associated faculty advisors. No part may be reproduced without the written permission of the senior design course coordinator.

December 14, 2005

Table of Contents

1 Introductory Materials 1

1.1 Executive Summary 1

1.2 Acknowledgement 1

1.3 Problem Statement 1

1.3.1 General Problem Statement 1

1.3.2 Solution Approach 1

1.4 Operating Environment 2

1.5 Intended Users/Uses 2

1.5.1 Intended Users 2

1.5.2 Intended Uses 2

1.6 Initial Assumptions and Limitations 2

1.6.1 Current Assumptions 3

1.6.2 Current Limitations 3

1.7 Expected End-Product and Other Deliverables 4

1.7.1 Deliverables 4

2 End-Product Design 6

2.1 Project Approach and Results 6

2.1.1 Functional Requirements 6

2.1.2 Design Requirements 6

2.1.3 Design Constraints 7

2.1.4 Approach Considerations and Results 8

2.1.4.1 Technology Consideration 8

2.1.4.2 RFID Connection 9

2.1.4.3 RFID Power Source 9

2.1.4.4 Software 9

2.1.4.5 RFID Tag Type 10

2.1.4.6 RFID Frequency Range 10

2.1.4.7 RFID Antenna 11

2.2 Detailed Design and Implementation Process 12

2.2.1 Project Design 12

2.2.2 Software Design 16

2.2.2.1 Classes 16

Program Screenshots 18

2.2.3 Problems Encountered 29

2.2.4 Testing of End Product and Results 29

3 Resources and Schedules 31

3.1 Resource Requirements 31

3.1.1 Personnel Effort Requirements 31

3.1.2 Other Resource Requirements 32

3.1.3 Financial Requirements 34

3.2 Schedules 35

3.2.1 Project Schedule 35

3.2.2 Deliverable Schedule 39

4 Closure Materials 41

4.1 Project Evaluation 41

4.2 Commercialization 41

4.3 Project Continuation Recommendations 41

4.4 Lessons Learned 42

4.5 Risk Management 43

4.6 Contact Information 43

4.6.1 Client Contact Information 43

4.6.2 Faculty Advisor Contact Information 43

4.6.3 Student Team Contact Information 44

4.7 Closing Summary 44

List of Figures

Figure 2.2.1—1: System Flowchart 13

Figure 2.2.1—2: Inventory Flowchart 14

Figure 2.2.1—3: Customer Flowchart 15

Figure 2.2.2—1: Screenshot of Main Inventory Window 18

Figure 2.2.2—2: Add To Inventory Manually Screenshot 19

Figure 2.2.2—3: Remove From Inventory Screenshot 20

Figure 2.2.2—4: Update Item Screenshot 21

Figure 2.2.2—5: Check Out Inventory Manually Screenshot 22

Figure 2.2.2—6: Return Item Screenshot 23

Figure 2.2.2—7: Screenshot of Main Customer Window 24

Figure 2.2.2—8: Add New Customer Screenshot 25

Figure 2.2.2—9: Delete Customer Screenshot 26

Figure 2.2.2—10: Update Customer Info Screenshot 27

Figure 2.2.2—11: View Customer History Screenshot 28

Figure 3.2.1—1: Original Project Tasks Schedule 36

Figure 3.2.1—2: Revised Project Tasks Schedule 37

Figure 3.2.2—1: Original Project Deliverable Schedule 39

Figure 3.2.2—2: Revised Project Deliverable Schedule 39

List of Tables

Table 2.1.4-1: Bar-code Versus RFID 8

Table 2.1.4-2: Active Tag Versus Passive Tag 10

Table 2.1.4-3: RFID Frequency Ranges 11

Table 2.2.2-1: DVD Class Info 16

Table 2.2.2-2: Customer Class 17

Table 3.1.1-1: Original Estimated Personal Effort Resource Requirement 31

Table 3.1.1-2: Revised Estimated Personal Effort Resource Requirement 31

Table 3.1.2-1: Original Estimated Required Resources 32

Table 3.1.2-2: Revised Estimate Required Resources 32

Table 3.1.2-3: Final Required Resources 33

Table 3.1.3-1: Original Estimated Project Costs 34

Table 3.1.3-2: Revised Estimated Project Costs 34

Table 3.1.3-3: Final Estimated Project Costs 35

List of Acronyms/Definitions

GUI – Graphical user interface

RFID – Radio frequency identification

RFID scanner/reader – A device used to communicate with the RFID tags.

RFID tag – A small object that can be attached to, or incorporated into a product that is used to store and retrieve data.

RS232 – Recommended Standard IEEE 232 [computer serial interface].

SQL – Standard computer language for accessing and manipulating databases.

Introductory Materials

The following introductory material is required to develop a general idea of the project and express how the solution shall come about.

1 Executive Summary

This report shall explain all of the components of the inventory control system. It shall explain what needs to work and how it works to be considered a success. The report shall show individuals the different ways that they can use the system. Along with the report a CD with the code shall also be attached, so that it can be verified that the system is just as it is described. There shall also be other code that can be used to populate the databases, so that the system can be tested with some slight modification.

2 Acknowledgement

The team would like to thank Professor John Lamont, Professor Ralph Patterson III, and Professor Degang Chen for their assistance in defining the project and support through its completion. The team would also like to thank Adam Mishler and Jason Warschauer for their efforts in helping the team obtain a reader as well as the software components.

3 Problem Statement

This section defines the problem and states the problem solution.

1 General Problem Statement

Barcode technology is the leader in inventory control at the present time. However, there are flaws in the technology that limit its effectiveness. The amount of data that can be stored in a barcode, the need for human intervention, and the necessity for line-of-site to transfer data, are a few issues that can be negated using other technology.

2 Solution Approach

The use of RFID can, in many cases, enhance the effectiveness of inventory control. The team shall research the possibilities of RFID technology, using the Internet and textbooks, and examine some of the improvements it has on the current barcode system. The team shall identify issues that can be resolved with the use of RFID and demonstrate its effectiveness. This shall be done by, first, analyzing the limitations of barcode technology, and then applying the new possibilities of RFID technology to propose solutions to correct some of the current issues. This shall be demonstrated through the creation of a mock DVD rental store. Through this store, the team shall show how a tag is scanned and how the data from that tag is added to the database.

4 Operating Environment

The operating environment for this RFID system shall be a DVD rental store. Since there are so many different types of businesses with inventory needs, there are many possible scanners and tags that are available. In many cases, the equipment must be able to operate in high traffic areas. The readability of the reader is affected by moisture and temperatures outside the range of 0( to 50(C, so the operating environment must be dry and within that range. Thus, the DVD rental store provides a great location for the RFID system.

5 Intended Users/Uses

This section describes the intended users and uses of the final project.

1 Intended Users

The intended user of the team’s RFID inventory control system is the DVD rental store. This system shall be setup to be mostly self-operated, but shall require a trained staff member, or inventory control manager, for troubleshooting and linkage of the system to the specific company software. The user also has the option to manually check-in or checkout customers or items if necessary. In order for simplicity, the system shall be developed for relatively easy setup and mild human interference, but shall require overseeing. It is assumed that the system user shall not apply moisture to the system or attempt to use the system outside of the temperature range.

2 Intended Uses

The RFID inventory control system is used to track inventory, sales, and customers. It shall be designed for a DVD rental store that holds inventory and customer information. The system shall be able to manage and track inventory and sales, collect data, and can be linked to a security system. The system shall be able to scan in new items, display information about the item, write new information to the item tag, manage in and out of stock inventory, manage customers, and subtract items from inventory.

6 Initial Assumptions and Limitations

The design team shall proceed with the project based on the assumptions and limitations listed within this section.

1 Current Assumptions

Listed below are the current assumptions for the project.

RFID reader – The team shall obtain an RFID reader that shall perform all of the necessary tasks.

Interface – The GUI shall be able to interface with the RFID reader and the SQL database.

RFID tags – The tags shall be readable.

Data – The data taken from the tags shall be read to the setup database.

Software – The software shall be Windows compatible.

System – The system shall only track inventory going in/out of DVD rental business. The system shall not be standalone, it shall require some human interaction.

2 Current Limitations

Listed below are the current limitations for the project.

Cost – The project budget is $150 and the cost of RFID readers and tags is, in most cases, more than this.

Size – Although the size of the RFID system is not a significant restraint as it shall be inside a retail store, this group has set a boundary of less than one cubic foot. This volume shall contain the reader hardware, but the external antenna shall not be included in this restraint.

Weight – Much like the size, this restraint is even less important to the overall product design, but a loose product weight limit has been set at five pounds. Once again, this includes only the main RFID hardware and excludes the antenna and PC that is running the inventory system.

Power – It is assumed that the power for the RFID unit shall be constant, and this team also therefore assumes that power loss is not a concern. Because of this, an alternate form of power shall not be necessary in the design of the RFID system.

RFID tag size – A size constraint is needed for the individual RFID tags, as they are required to fit inside DVD cases and other small items that a retailer may carry.

Standards – There is no set of standards established at the present time.

Temperature – The temperature range for this system to operate effectively is between 0( and 50(C.

Liquid and metals – Radio frequency signal quality can be compromised in the presence of materials like metals and liquids.

Distance to read tag – Due to cost constraints the distance to read tag may be smaller than hoped.

RFID reader – Only a single reader must be used for this system.

7 Expected End-Product and Other Deliverables

The end product of this project shall be contingent upon available funding and design time requirements.

1 Deliverables

Listed below are the deliverables the team expects to complete by the end of the project.

Demonstration – The demonstration shall include a working model of a sample inventory control system using RFID technology. The system shall be linked to the team’s made-up DVD rental store. The team shall show how a tag is scanned, the information that can be collected, and how that information can be linked to a database. Initial research shall also be included.

Documentation – The documentation shall assist the user during operation of the inventory system.

Weekly e-mails – These shall update the instructors, advisors, and clients involved with the project on the work completed the previous week and ask recipients about any issues that have arisen during the previous week. They shall also serve as a plan for the upcoming week.

Project plan – The project plan outlined the basic objective of the project and included information about design restrictions, estimation of work, supplies necessary, and the process being used to develop the product.

Project poster – The project poster is a large, graphical description of the basic components, operation, and design of the project.

Oral presentation of the design results – The team shall give an oral presentation describing the progress achieved and the final design.

Design report – Describes progress made during the first semester and outlines the project plan for the second semester.

Final design report – A final report due at the end of the year detailing all aspects of the design process.

End-Product Design

The end-project section of this report gives the client a brief description of all of the design constraints the inventory control system is designed around as well as the deliverables in this project.

1 Project Approach and Results

The approach used section of this report examines each of the components that the group considered in the design of this project.

1 Functional Requirements

The design objectives lead to the functional requirements of the inventory control system of the rental store, which are as follows:

Scanning capability- The system shall scan the RFID tags located on items and membership cards using an RFID scanner.

Data storage/management- The design shall collect and store data from the RFID reader or scanner on a computer using a R232 serial connection.

Software- Software shall be used to collect and process the retail information for the data.

Data control-The system shall allow manual entry into the database for adding membership and items.

2 Design Requirements

Based on the problem statement, there are several necessary objectives that the system must meet. These objectives include the following:

Easy to use – The system shall need to be easy to use once it has been setup. It shall be a stand-alone system and shall require minimum human interface with the system itself in order to perform its functions.

Low maintenance – Once setup, the system shall be able to function with little input from an operator. The database shall be updated automatically and shall only require an employee to oversee the process. The software shall be equipped with an override feature that would allow the employee to take control.

Utilize RFID capabilities – The system shall display some of the nice features that RFID technology has to offer. These features shall demonstrate some of the benefits of using RFID over barcode technology.

3 Design Constraints

Listed below are the constraints the team intends on following throughout the design.

Cost – The overall cost for the RFID hardware necessary to complete the project shall not exceed $150.

Size – Although the size of the RFID system is not a significant restraint as it shall be inside a retail store, this group has set a boundary of less than one cubic foot. This volume shall contain the reader hardware, but the external antenna shall not be included in this restraint.

Weight – Much like the size, this restraint is even less important to the overall product design, but a loose product weight limit has been set at five pounds. Once again, this includes only the main RFID hardware and excludes the antenna and PC that is running the inventory system.

Power – It is assumed that the power for the RFID unit shall be constant, and this team also therefore assumes that power loss is not a concern. Because of this, an alternate form of power shall not be necessary in the design of the RFID system.

DVD – Tag shall not be able to be removed from DVD.

Customer

– Only one customer can walk by reader at a time.

– Each customer must have membership card with RFID tag on it.

– Customers must be at least three seconds apart.

– Each customer must hold membership card and items being rented within reader’s reading distance.

– Each customer must walk slowly by reader to allow enough time to read in membership card and items.

– Each customer won’t walk by scanner again with items just rented.

System user – A trained employee of the business is the only one who can add inventory into system.

4 Approach Considerations and Results

This section describes the different types of technology and approach used to design the team’s inventory system.

1 Technology Consideration

For a system solution, there are two possible inventory control scanning techniques that were considered. The technologies that were considered were bar coding, and RFID. The advantage of having bar code is that it is inexpensive, and has the potential to scan items from 40 feet away with 100 percent of accuracy. The disadvantages to having bar code are that it can only scan and read one bar code at a time, and requires line of sight to scan the bar code. The advantages for using RFID scanning techniques are the user can scan many RFID tags simultaneously, does not require line of sight to read each tag, and has a unique identification number with more data. The disadvantages to having RFID are that it can scan only items within a few feet, and scanning accuracy is less than 100 percent. Table 2.1.4—1 explains the advantages and disadvantages of bar code versus RFID. The technology chosen is to use RFID over bar coding because it is designed more for an inventory control environment and already has all the features needed in one convenient package. Depending on the type of product there are some advantages of RFID over bar coding. RFID is well suited for high-value products and also for high volume distribution centers where RFID can speed the velocity of the goods through the receiving and shipping process. RFID is a much better technology in "track and trace" applications where the user wants to be able to track goods through the supply chain.

Table 2.1.4-1: Bar-code Versus RFID

|Bar Codes |RFID Tags |

|Require line of sight to scan bar codes |Don't require line of site to read each tag |

|Can only scan and read one bar code at a time |Can scan many RFID tags simultaneously |

|Can be scanned from 30 or 40 feet away from label |Scan/read distance limited to a few feet for low-cost, passive tags |

|Scan accuracy nearly 100% |Scan accuracy of 100% can be achieved, but difficult |

|Can scan several hundred scans per minute with no reduction |Dwell time required to scan all tags on a pallet or a tag on a case |

|in throughput or line speeds |traveling on a conveyor can reduce line speed and throughput |

|Cannot scan an entire pallet of case labels without breaking|Can scan all cases on a pallet with single pass through a portal |

|down the pallet and rebuilding |reader |

|If a specific license plate label (a reusable tote) is lost,|Can read and locate a specific RFID tag (attached to that same tote)|

|you must visually inspect all labels to find the correct one|more quickly |

Source:

2 RFID Connection

As far as the physical connection between the PC and the RFID system is concerned, only two main options are currently offered. Most systems contain RS232, or serial, for an interface, but some are also becoming available with USB as well. Usually, the main concern in deciding which of these two connections to go with would be determined by the speed necessary for transfer. Serial is much slower than USB, but works fine for applications in which high speed isn’t necessarily required. Serial is also much more prominent among RFID systems today, as well as being a common occurrence on most PCs. For this reason, the team has decided to go with a serial RS232 connection between the PC and the RFID unit.

3 RFID Power Source

Both 120 volts AC power and DC power from 9 volt batteries are found in RFID systems today. AC power technology is beneficial over battery power because no charging is needed. Power outages are a concern for this technology, though, as a battery backup would be required if the RFID system were to continue working in these power loss conditions. Battery power from a 9 volt battery eliminates this concern, but introduces the concern of loss of power due to a dead battery. Because power outages are not a concern for this group, and a constant power supply is assumed to be achieved from AC power via a 120 volt power socket, this group has decided to go with AC power over battery power. The options, though, are thus narrowed down in terms of choices for RFID systems available with AC power. If this becomes a problem, the team shall adapt an AC to DC power converter to their RFID system which shall enable them to use 120 volt AC power.

4 Software

The choices for software on this inventory control system are almost limitless. For a back-end, software to run the actual RFID system, the current options can be anywhere from C#, BASIC, to assembly language. As C# is probably one of the most common languages still used today, the team has decided to write any back-end software with this language. Options for the software in which the user shall interact with the database were chosen to be C#, Java, Perl/Tk, or some form of dynamic web language such as PHP. Benefits of using any of these languages would be the possibility of making a user friendly GUI that the user would be able to interact with. Since it is assumed that the software and database is to run on one machine and a network of machines isn’t necessary, dynamic web pages were no longer needed. C#, then, was chosen for a front-end software language because of the ease of programming GUI applications and the fact that it is already being used for back-end applications.

For the database the team decided on MySQL. MySQL database was chosen because it is compatible with the reader and the GUI. A few of the benefits of going with MySQL are that it has simple search queries, it is easy to upgrade, and it is open source.

5 RFID Tag Type

There are four different types of RFID tags, which include: read only, read and write, active and passive tags. Read only tags allow the RFID scanner to read to the tag. Read and write tags let the RFID scanner read and write different information to the tags. As a result, the team has chosen the reading and writing capabilities because of the different options of changing the information of the tags. These options shall benefit the team when creating a database for the inventory control system.

The other types of tags that an RFID scanner can read are active and passive tags. Active tags have continuous power available, requires a lower signal from the reader and can read 1000’s of tags up to 100 meters. Active tags also are very expensive and require a battery. Passive tags can read a few hundred tags, doesn’t require a battery and are very cheap. Passive Active tags also require being very close to the RFID reader while scanning. The advantages and disadvantages of having active tags versus passive are shown in Table 2.1.4—2. For the inventory control system, the team has chosen passive tags. The reason for this selection is that passive tags are inexpensive and do not require a battery. Because of budget constraints, the passive tags that were chosen shall have the capability to read up to approximately 10 tags at a time.

Table 2.1.4-2: Active Tag Versus Passive Tag

| |Active Tag |Passive Tag |

|Tag power source |Internal to tag |Energy transferred using RF from reader |

|Tag battery |Yes |No |

|Availability of power |Continuous |Only in field of reader |

|Required signal strength to tag |Very Low |Very High |

|Range |Up to 100m |Up to 3-5m |

|Multi-tag reading |1000’s of tags up to 100 mph |Few hundred within 3m of reader |

|Data storage |128Kb or read/write with search and access |128Kb of read/write |



6 RFID Frequency Range

For an RFID scanner/reader there are 4 different type of frequency ranges used. The frequency ranges used are low, high, ultra high and microwave frequency. The low frequency range is at a frequency of 125k hertz at a read range of less than 10 centimeters. The high frequency range is at a frequency of 13.56k hertz at a read range of 1 meter. The ultrahigh frequency range is at a frequency of 900M hertz at a read range of less than 7 meters. The microwave frequency range is at a frequency of 2.4Ghertz at a read range of less than 10 meters. Each frequency is used for different applications. For the inventory control system the team has chosen 13.56k hertz reader. Most RFID reader and tags are at the 13.56k hertz range in the US. Table 2.1.4—3 lists the different types of frequency ranges and the applications of each frequency range.

Table 2.1.4-3: RFID Frequency Ranges

| |Frequency |Read Range |Example Application |

|LF |125kHz |Less than 10cm |Smart Card technology, animal |

| | | |tagging, security access |

|HF |13.56kHz |≈1m |Small item management, supply |

| | | |chain, anti-theft, library |

|UHF |900Mhz |≈7m |Large item management, supply |

| | | |chain, transportation vehicle ID|

|Microwave |2.4Ghz |10m+ |Large item management, supply |

| | | |chain, transportation vehicle ID|



7 RFID Antenna

As far as the connection between the RFID reader and the RFID tags is concerned, only two main options are currently offered. Most systems contain internal antenna for an interface, but some are also becoming available with external antenna. Usually, the main concern in deciding which of these two connections to go with would be determined by the distance a reader can scan an RFID tag. An internal antenna reading range is much lower than external antenna, but works fine for applications in which reading range is not necessarily required. Internal antennas are built into most RFID readers. External antennas are expensive and most connect to a certain reader. For this reason, the team has decided to go with an internal antenna as a connection between the RFID reader and the RFID tags.

2 Detailed Design and Implementation Process

The detailed design section of the report shall discuss the features that shall be implemented into the inventory control system. First it shall focus on the software and how it shall be put together to create an inventory control system. Next it shall tell the information that shall be stored in the databases. Finally it shall show some of the screenshots from the program and what each of them does for the overall program.

1 Project Design

This section shall list and show how the project is put together. It shall highlight what parts of the project shall communicate with the other parts.

Listed below is a list of parts that are used to implement the project.

RFID reader – The device used to interface with RFID tags.

PC computer – The computer shall run the software necessary to run the inventory control system. It shall store all of the data to track the inventory.

RFID tags – A component that is used to track individual inventory items.

RS232 serial cable – A component used to connect the RFID reader to the PC computer.

[pic]

Figure 2.2.1—1: System Flowchart

Figure 2.2.1—1 shows how the main components of the system shall communicate with one another. The keyboard/mouse shall interface directly with the inventory control system through the GUI. As the user clicks on buttons and tabs the GUI shall change corresponding to the selection. Tags that are read in by the RFID reader shall go first through the control system and then on to the database to be added or removed. The results of both shall change the database to satisfy the situation and update the GUI to show the change.

[pic]

Figure 2.2.1—2: Inventory Flowchart

Figure 2.2.1—2 shows the flowchart of the inventory through the GUI. The program shall start out and retrieve data from the “Inventory Database.” The data retrieved from the database shall be displayed on the computer screen. Now the user can click on any of the following to change data in the databases:

• Add to inventory manually – User enters product data into the database

• Remove from inventory – User deletes product data from the database

• Update item – User updates product data

• Check out inventory manually – User checks out items from inventory

• Return item – User adds item back into database

After modifying any of the databases the main GUI shall be updated to correspond to the change.

[pic]

Figure 2.2.1—3: Customer Flowchart

Figure 2.2.1—3 shows the flowchart of the customers through the GUI. The program shall start out the same way as mentioned in Figure 2.2.1—2. Instead of following inventory data, the user shall select the customer GUI to begin the retrieval of customer data. The data retrieved from the database shall be displayed on the computer screen. Now the user can click on any of the following to change data in the databases:

• Add new customer – User enters a new customer into the database

• Delete customer – User deletes a customer from the database

• Update customer info – User updates a customer’s information

• View customer history – User views the customer’s information

After modifying any of the databases the main GUI shall be updated to correspond to the change.

2 Software Design

The software design section shall explain the components that shall work together to create the inventory control software. First it shall explain the classes that shall be used in the software. Then it shall show screenshots of the program and give details as to how the GUI shall work together to create a system that manages to control inventory.

1 Classes

This section shall discuss the classes that are going to be used for the inventory control software. The two main classes that shall be used to store data are Customer and DVD. These shall hold all of the information necessary to identify each customer and DVD.

DVD

The DVD class shall store all information about a DVD into a database. It shall create a convenient way to obtain all information stored on a DVD.

Table 2.2.2-1: DVD Class Info

|Type |Name |Information it Stores About the DVD |

|string |Name |Name of DVD |

|string |Genre |Type of movie |

|integer |DVDIdentificationNumber |Unique identification number for DVD |

|integer |YearMade |Year movie was made |

|boolean |CheckedOut |Is movie checked out? |

|date |DueBack |Date movie is to be returned if checked out |

|date |CheckOut |Date the movie was checked out if it’s currently checked |

| | |out |

|integer |CustomerIdentification |Unique identification number for Customer |

|float |Price |Price of DVD |

Table 2.2.2—1 shows all of the data that shall be stored inside of the DVD class. This shall be used to identify and track each DVD that is rented.

Customer

The Customer class shall be used to store information about customers into a database. It shall create a convenient way to obtain all information stored on a customer.

Table 2.2.2-2: Customer Class

|Type |Name |Information it Stores About the |

| | |Customer |

|string |FirstName |first name |

|string |LastName |last name |

|string |MiddleName |middle name |

|string |StreetAddress |street address |

|integer |CustomerIdentification |unique identification number |

|string |City |city |

|integer |ZipCode |zip code |

|integer |PhoneNumber |phone number |

|string |Email |email address |

|integer |CreditCard |credit card number |

|vector of DVD class |MoviesCurrentlyCheckedOut |DVDs currently checked out |

|vector of DVD class |MoviesAlreadyRented |DVDs already rented |

|integer |CreditCardMonth |expiration month of credit card |

|integer |CreditCardYear |expiration year of credit card |

|string |CreditCardType |type of credit card |

|string |DriverLicense |driver’s license number |

Table 2.2.2—2 shows all of the data that shall be stored inside of the customer class. This shall be used to identify and track each DVD that each customer rents.

Program Screenshots

The following figures relate to how a user shall interface with the inventory. The user should be able to filter the inventory to view, add to the inventory, remove from inventory, update items, check out inventory manually, and return items manually.

[pic]

Figure 2.2.2—1: Screenshot of Main Inventory Window

Figure 2.2.2—1 is the first screenshot of the inventory control software. This shall open up once the program has been executed. It shall retrieve all of the attributes from the DVD class and display them in a table in the center of the screen. Initially the table shall display the entire inventory. Near the top there shall be a dropdown menu to choose if the user wants to see the entire inventory, in stock items, checked out items, items added since last time program was ran, and overdue items.

The RFID reader shall constantly be trying to read tags while the user is working with the GUI. To add something to the inventory with the reader that is not in the database, the user must put the item beside the reader and a message should pop up on the screen that gives all of the information on the item and adds it to the inventory once the reader reads the tag.

[pic]

Figure 2.2.2—2: Add To Inventory Manually Screenshot

Figure 2.2.2—2 is a screenshot of a window that would pop up if the user clicked on the button “Add to Inventory Manually” from Figure 2.2.2—1. This is included in case there happen to be technical difficulties with the RFID reader. The user shall still be able to add items to the database. This prompts the user to enter the name of the movie. The user shall select from a list the genre that the movie falls under. The user must also create a unique identification number that shall identify this DVD. The user shall also enter the year that the movie was created to help identify the movie. When the user has filled out all of the fields the user can click on the “Add” button. This shall add it to the DVD inventory if all of the fields are filled out. If the fields aren’t filled out, the program shall prompt the user to fill them out and try adding it again.

[pic]

Figure 2.2.2—3: Remove From Inventory Screenshot

Figure 2.2.2—3 is a screenshot of a window that shall pop up if the user clicks on the button “Remove From Inventory” from Figure 2.2.2—1. The user shall select the method that he/she wishes to search through the database to find the inventory item that he/she wants to delete. Then the user shall fill in the textbox to satisfy the corresponding search. Next the user should be able to hit the “Search” button to look up the item in the database. The results shall be displayed inside of the “Results” box seen in Figure 2.2.2—3. The user shall then select which one he/she wants to delete by selecting a checkbox next to the item. This shall ensure that the user does want to delete the selected item and make sure it is the right item since the search may likely return numerous results. Clicking the “Delete” button shall remove the item that is selected from the database.

[pic]

Figure 2.2.2—4: Update Item Screenshot

Figure 2.2.2—4 is a screenshot of a window that shall pop up if the user clicks on the button “Update Item” from Figure 2.2.2—1. First, the user shall select the type of search he/she wishes to make from the dropdown menu. Next, the user fills out the corresponding textbox beside the dropdown menu and clicks the “Search” button. This shall update the results in the “Results” section of the screenshot. The “Movie Name” shall have a dropdown menu to select which movie he/she is searching for in case there is more than one movie in the same search. For each movie he/she selects in the dropdown menu the information shall update all of the related fields. If the movie is checked out, the field beside “Checked Out:” shall say “Yes” and show the corresponding dates that is was checked out and due to be returned. The “Customer Information” shall display any information that is needed to identify the customer such as name, phone number, and identification number.

[pic]

Figure 2.2.2—5: Check Out Inventory Manually Screenshot

Figure 2.2.2—5 is a screenshot of a window that shall pop up if the user clicks on the button “Check out Inventory Manually” from Figure 2.2.2—1. This shall allow a user to check out an individual if there is a malfunction with the RFID reader. In order to do this, the software shall need to know the DVD’s identification number which shall be located on/beside the RFID tag. The customer’s identification number must also be known, this shall be printed on a card that has an RFID tag on it. This shall identify the customer by a unique number given to each customer. The user must enter both identification umbers into the text fields and click the corresponding buttons. The program shall then display the information necessary to verify that the number was entered correctly. This shall consist of a name, genre, and year for the DVD and name, phone number, and address of the customer. The user must then be able to select the date that the DVD is due back. The default time shall be two days after the DVD was checked out. In order to complete the rental, the user must click on “Check Out.” This shall save any necessary data to the database.

[pic]

Figure 2.2.2—6: Return Item Screenshot

Figure 2.2.2—6 is a screenshot of a window that shall pop up if the user clicks on the button “Return Item” from Figure 2.2.2—1. This shall allow the user to return an item if the RFID reader isn’t functioning. The user shall enter in the DVD identification number next to or on the RFID tag. The user shall then click the “Search” button to find the movie’s name and the customer who checked it out. The user should make sure that the name of the movie is correct and click the “OK” button. The database shall then update the movie information as being returned.

The following figures relate to the customer information that is stored in the database and different ways that it can be shown, added to, removed from, updated, and viewed customer history.

[pic]

Figure 2.2.2—7: Screenshot of Main Customer Window

Figure 2.2.2—7 is a screenshot of the window that would be shown if the user clicked on the “Customer” tab from Figure 2.2.2—1. This shall show a table that shall initially show all of the customers in the database along with any relevant information to identify each one such as: name, phone number, address, identification number, if they currently have any DVDs rented, and if there are any late DVDs. The user shall be able to select different ways to filter the information from the dropdown menu beside the label “Customer View.” Some choices offered shall be: show all customers, show customers who currently do or don’t have a DVD checked out, and customers who have late DVDs.

[pic]

Figure 2.2.2—8: Add New Customer Screenshot

Figure 2.2.2—8 is a screenshot of the window that shall pop up if the user clicked on the “Add New Customer” button from Figure 2.2.2—7. The user shall have to fill in all of the corresponding fields in order to add the customer. If all of the fields don’t have data in them, it won’t allow the user to add the customer to the database. The account number should be determined by the program, so that there is no overlap in numbers given. The user shall then hold a card that has a writeable tag with no data on it up to the RFID reader. The reader shall be searching for this card until one is found. At this point data shall be written onto the card to identify the reader. Data shall consist of the customer’s name, phone number, address, and account number. Once the tag is written, the reader shall read the tag to verify that the tag is correct and pop up a window that gives all of the information on that card, so the user can determine it was correct. At this point the customer can use the card to rent DVDs.

Each customer shall have to have a driver’s license with them to check out DVDs. This shall be used to verify a customer even if two people have the same name. The driver’s license can also be used to check out a customer.

[pic]

Figure 2.2.2—9: Delete Customer Screenshot

Figure 2.2.2—9 is a screenshot of the window that shall pop up if the user clicked on the “Delete Customer” button from Figure 2.2.2—7. The user shall select the method that he/she wishes to search through the database to find the customer that he/she wants to delete. Then the user shall fill in the textbox to satisfy the corresponding search. Next the user should be able to hit the “Search” button to look up the person in the database. The results shall be displayed inside of the “Results” box seen in Figure 2.2.2—9. The results shall include any information necessary to identify the customer such as: name, phone number, address, and account number. The user shall then select which one he/she wants to delete by selecting a checkbox next to the item. This shall ensure that the user wants to delete the selected person and make sure it is the right person since the search may likely return numerous results. Clicking the “Delete” button shall remove the customers that are selected from the database.

[pic]

Figure 2.2.2—10: Update Customer Info Screenshot

Figure 2.2.2—10 is a screenshot of a window that shall pop up if the user clicks on the button “Update Info” from Figure 2.2.2—7. First the user shall select the type of search he/she wishes to make from the dropdown menu. Next the user shall type the item that he/she is searching for in the textbox beside the dropdown menu and click the “Search” button. This shall update the results in the “Results” section of the screenshot. The “Last Name, First Name” shall have a dropdown menu to select which customer the user is searching for in case there is more than one customer in the same search. The customer’s identification number can’t be changed by the user to ensure that there aren’t two identical numbers. All other information other than the last name and first name can be changed. The only way that the database can be updated is if all of the fields have the appropriate data in them and the customer’s card has the correct identification number on it. This shall ensure that only the owner of the card can change information about themselves. To ensure that the card is correct the user shall click the “Update” button and the RFID reader shall read the card and make sure that the identification number is the same. If it is the same, the reader shall rewrite the tag to update all of the fields stored on it. Then it shall read the card and a pop up window shall display the updated information. Now the database shall be updated with the changed data.

[pic]

Figure 2.2.2—11: View Customer History Screenshot

Figure 2.2.2—11 is a screenshot of a window that shall pop up if the user clicks on the button “View Customer History” from Figure 2.2.2—7. The user shall determine what type of search he/she wants to do at the top of the screen in the dropdown menu. Then put the corresponding information into the textbox and click “Search.” This shall update the “Customer Information” section with the first person to be returned in the search. The user shall be able to select a different person from the search from the dropdown menu beside “Last Name, First Name” if more than one person matches the search. The user shall have to verify the person with either the phone number, address, or identification number. The history of the customer should be printed in a spreadsheet form on the bottom half of the screen. This shall display information such as movie name, genre, date checked out, date to be returned, if DVD is overdue, and DVD identification number. This data can then be filtered from a list of choices found on the dropdown menu beside “History View.” Some of the choices that should be available are view all DVDs rented, view all DVDs customer is currently renting, and view all DVDs that are overdue.

3 Problems Encountered

This section describes the problems that were encountered during the implementation of the project.

There were three main problems that were encountered during the implementation of this project. These include: difficulties obtaining a reader, learning C#, and working through checksum errors. The reader was difficult to obtain because of the team’s initial approach. The team attempted to purchase a reader, which was not feasible due to the budget constraints. To solve this problem, the team approached an industry contact and was able to get a reader donated. Learning C# was challenging because it was a language that the team was unfamiliar with. Luckily, C# is very similar to C programming, a language the team is very familiar with, so the learning curve was small. The next problem encountered dealt with the reader. While reading tags, the reader software calculates a number called the checksum, which is used to confirm the data that is received from the reader. To fix this problem, the team had to add additional code to the software package in order to fit the required application.

4 Testing of End Product and Results

This section describes the testing approach used for the inventory control system and the associated results.

In order to test the validity and accuracy of the inventory control system the team first setup the inventory software and link it to the RFID reader. Once this was done, the team programmed a number of tags, using the reader, and preceded to scan these tags and see how the information communicates with the software. Success was evaluated by verifying that the information on the tag scanned, showed up in the team’s database. Once this was verified, the team performed tests to examine the features of the system, such as scanning multiple tags, scanning tags outside the line-of-site, and automatic updating of the database. These tests were done by scanning more than one tag at a time, scanning tags with an obstruction in between the tag and scanner, and verifying that when tags were scanned in and out of inventory the same occurred within the database.

The testing for the inventory control system took place in the lab with at least two members of the team present. At least two tags were necessary along with a windows-based computer, the team’s software application, the RFID reader, and the RS232 serial connection linking the computer with the reader.

The results and analysis of each test were stored and documented by at least one individual present during the testing, so that the group could have an accurate depiction of the system’s functionality. The system accurately scanned in the information on the tags and automatically stored that data in the SQL database. The team was also able to successfully scan three tags simultaneously into the database successfully. Finally, the team was able to scan a tag that was out of the line of site of the reader using a notebook as a barrier. The information was accurately processed into the database.

Resources and Schedules

The following sections shall be the team’s best estimates of resources and schedules needed to complete the project.

1 Resource Requirements

The following sections shall cover an original, revised, and final estimate of the expected contribution of each team member’s personal effort, other resources, and financial requirements needed to complete the project.

1 Personnel Effort Requirements

A project is successful when each team member contributes the necessary time and effort to each task. Table 3.1.1—1 is an original estimate of the personal effort for each team member for the duration of the project. Table 3.1.1—2 is a revised estimate of the personal effort for each team member for the duration of the project. Table 3.1.1—3 is an final personal effort for each team member for the duration of the project.

Table 3.1.1-1: Original Estimated Personal Effort Resource Requirement

|Team Members |Task 1 |Task 2 |Task 3 |

|Parts and Materials | | | |

|a. Project Poster |15 |0 |$65.00 |

|b. RFID Kit |50 |0 |$210.00 |

|c. Bound Project |2 |0 |$25.00 |

|Plan | | | |

| | | | |

|Total |67 |0 |$300.00 |

Table 3.1.2-2: Revised Estimate Required Resources

|Items |Team Hours |Other Hours |Cost |

|Parts and Materials | | | |

|a. Project Poster |15 |0 |$30.00 |

|b. RFID Kit |55 |0 |$250.00 |

|c. Bound Project |2 |0 |$3.00 |

|Plan | | | |

| | | | |

|Total |72 |0 |$283.00 |

Table 3.1.2-3: Final Required Resources

|Items |Team Hours |Other Hours |Cost |

|Parts and Materials | | | |

|a. Project Poster |15 |0 |$30.00 |

|b. RFID Kit |55 |0 |$0.00 |

|c. Bound Project |2 |0 |$3.00 |

|Plan | | | |

| | | | |

|Total |72 |0 |$33.00 |

2 Financial Requirements

This section covers an estimate the original and revised total financial amount required to contribute to the project. An original estimate of the total cost is shown in Table 3.1.3—1. The revised estimate of the total cost is show in Table 3.1.3—2. The final total cost is show in Table 3.1.3—3.

Table 3.1.3-1: Original Estimated Project Costs

|Item |Without Labor |With Labor |

| | | |

|Parts and Materials: | | |

|Project Poster |$65.00 |$65.00 |

|RFID Kit |$210.00 |$210.00 |

|Bound Project Plan |$25.00 |$25.00 |

|Subtotal |$300.00 |$300.00 |

|Labor ($10.50 per hour) | | |

|Benson, Jeffery |$0.00 |$2079.00 |

|Brown, Frederick |$0.00 |$2100.00 |

|Reed, Christopher |$0.00 |$2026.50 |

|Wagner, Brian |$0.00 |$2068.50 |

|Subtotal |$0.00 |$8274.00 |

| | | |

|Total |$300.00 |$8574.00 |

Table 3.1.3-2: Revised Estimated Project Costs

|Item |Without Labor |With Labor |

| | | |

|Parts and Materials: | | |

|Project Poster |$30.00 |$30.00 |

|RFID Kit |$250.00 |$250.00 |

|Bound Project Plan |$3.00 |$3.00 |

|Subtotal |$283.00 |$283.00 |

|Labor ($10.50 per hour) | | |

|Benson, Jeffery |$0.00 |$2236.50 |

|Brown, Frederick |$0.00 |$2257.50 |

|Reed, Christopher |$0.00 |$2184.00 |

|Wagner, Brian |$0.00 |$2436.00 |

|Subtotal |$0.00 |$9114.00 |

| | | |

|Total |$283.00 |$9397.00 |

Table 3.1.3-3: Final Estimated Project Costs

|Item |Without Labor |With Labor |

| | | |

|Parts and Materials: | | |

|Project Poster |$30.00 |$30.00 |

|RFID Kit |$0.00 |$0.00 |

|Bound Project Plan |$3.00 |$3.00 |

|Subtotal |$33.00 |$33.00 |

|Labor ($10.50 per hour) | | |

|Benson, Jeffery |$0.00 |$2236.50 |

|Brown, Frederick |$0.00 |$2257.50 |

|Reed, Christopher |$0.00 |$2184.00 |

|Wagner, Brian |$0.00 |$2436.00 |

|Subtotal |$0.00 |$9114.00 |

| | | |

|Total |$33.00 |$9147.00 |

2 Schedules

The key to having a successful project is meeting schedules and deadlines. The team has developed the following section to display the schedule for the duration of the project.

1 Project Schedule

During a project it is important to develop a schedule for the tasks that need to be accomplished for the project. Figure 3.2.1—1 on the following page displays the original project tasks and subtasks that shall be completed throughout the proposed project calendar. Figure 3.2.1—2 on the following page displays the revised project tasks and subtasks that shall be completed throughout the proposed project calendar. Figure 3.2.1—3 on the following page displays the revised project tasks and subtasks that shall be completed throughout the proposed project calendar.

[pic]

Figure 3.2.1—1: Original Project Tasks Schedule

[pic]

Figure 3.2.1—2: Revised Project Tasks Schedule

[pic]

Figure 3.2.1—3: Final Project Tasks Schedule

2 Deliverable Schedule

Figure 3.2.2 displays what date the original project deliverables are due. Figure 3.2.3 displays what date the revised project deliverables are due. Figure 3.2.3 displays what date the final project deliverables were due. These schedules cover both semesters of the project. The schedule shall be used as a guidance tool for approaching deadlines.

[pic]

Figure 3.2.2—1: Original Project Deliverable Schedule

[pic]

Figure 3.2.2—2: Revised Project Deliverable Schedule

[pic]

Figure 3.2.2—3: Final Project Deliverable Schedule

Closure Materials

This section contains contact info of the whole team including the faculty advisor and student team members.

1 Project Evaluation

This section evaluates the degree of success of the project.

The team’s milestones consisted of research, obtaining a reader, creating a database, interfacing the inventory control system, testing, and documentation. The research was fully met and that accounted for about 15% of the total project. Obtaining the RFID reader was another milestone that was achieved. This milestone was another 15% of the project. Creating the database was challenging but achieved and accounted for 20% of the project. The interfacing portion was 40% of the project and was fully met by the team. The documentation and final testing accounted for a total of 10% and were fully met. Overall, the project was successful with all team goals being met.

The system must successfully read cards with the RFID reader. It must also use each cards unique identification number to look up all corresponding information from the databases. The information must be shown on the screen to verify that all of that took place. The system must also allow users to add, update cards into the system, whether it is to the inventory or customer databases. Finally, the system must be able to successfully check-out and return inventory. This is the main evaluation criteria that must be met.

2 Commercialization

This section would discuss potential considerations for commercialization of the end product.

At this time the team isn’t pursuing commercialization. The potential for commercialization is feasible if the team found a client that wanted to implement the system for his/her store. With a few minor changes to meet the client’s needs it could potentially be used for him/her.

3 Project Continuation Recommendations

This section gives the team’s recommendation for the continuation of this project. The recommendation includes work that could be added for future projects.

Once the team has successfully completed this project, there are other considerations for continuation beyond next semester. Other directions for this project to move in could be to apply the current team’s system to a client within industry, which would involve a change over of the client’s current system to RFID technology and customizing it to their specific needs. The user can also enhance the security and reliability on features of the current system with the use of multiple readers. Other suggestions include setting up a network with multiple reader and database system. This would help the user communicate with different databases at the same time.

4 Lessons Learned

This section explains what lesson the team learned from the project.

During the project, there were some things that went well. The team had success staying on track with the original schedule. Staying on track was important because there were many challenges involved with the project. Another thing that went well was that the team had great communication. The team was always focused and communicating at a high level.

During the project, there were some things that did not go well. In the beginning of the project, the team had a problem of defining exact what the project required. Defining the project was an important step in starting the project. The team’s concentrate on defining the project caused a major setback in our original plans. Another issue that the team encountered was obtaining a reader. The team spent hours pricing readers to fit the needs of our project. The team learned that all the readers were not in the constraints of the senior design budget. Eventually the team had a reader donated from a company.

During the duration of the project, the team acquired technical knowledge. The team learned about different types of programming languages. C# is the main language that is used in the inventory system. The team did not know much about C#. The team researched C# using books and internet sources. This programming language was essential to learn. Another technical skill acquired was learned MySQL. MySQL is the database that is used to connect the inventory system. The team learned all the special features that MySQL provides for database management. This skill was important in completing the project.

If the team had a chance to redo the project, there are some things that would be done differently. The team would definitely define the project more concretely. This would have save more time for planning the project. The team also would have designed the database and GUI sooner. This would have helped with completing the testing sooner. The team also would have broken the project tasks down differently. The team would have done more of the task simultaneously rather than separately.

5 Risk Management

This section discusses the risk related issues involved with the team’s project.

During the project there are risks that a team can anticipate. The team can encounter the risk of losing a team member. The team solution to losing a team member was to record everything into the log books. This shall help the team split up the work if a team member is lost. Another risk that the team anticipated was losing code. To avoid this risk, the team saves everything on the server and back up disk. This is to avoid computer crashes and viruses. The team didn’t encounter any anticipated risk.

During the project there are also unanticipated risks. One risk that could be encountered would be not obtaining the appropriate hardware to complete the project. This would cause major problems with the inventory system as an RFID reader was necessary to complete the project successfully. The team almost encountered this risk. At one point in time the team didn’t know if a reader was obtainable. The team backup plan was to do a research assignment on RFID technology. The team luckily did not encounter this problem. Another risk that was unanticipated was the reader not communicating with the database. Without communicate from the reader, the inventory system would not function correctly. The team plan was to fix any problems that occur during interfacing. The team has encountered this problem but the reader communicates with the database.

6 Contact Information

Listed below is the contact information for the faculty advisor and student team members.

1 Client Contact Information

The client for this project is the senior design program at Iowa State University.

2 Faculty Advisor Contact Information

Dr. Degang Chen

329 Durham

Ames, IA 50011

Phone: 515-294-6277

Fax: 515-294-8432

E-mail: djchen@iastate.edu

3 Student Team Contact Information

Jeff Benson

CprE

1320 Gateway Hills #502

Ames, IA 50014

Phone: N/A

Cell: 507-398-6801

E-mail: jeffers@iastate.edu

Frederick Brown

EE

2101 Oakwood Rd #304

Ames, IA 50014

Phone: 515-292-4469

Cell: N/A

E-mail: fbrown@iastate.edu

Chris Reed

EE

2420 Martin Boyd

Ames, IA 50012

Phone: 515-572-6061

Cell: 319-651-5522

E-mail: creed@iastate.edu

Brian Wagner

CprE

2717 West Street #4

Ames, IA 50014

Phone: N/A

Cell: 563-380-6351

E-mail: wagnerb@iastate.edu

7 Closing Summary

Inventory control, especially in retail situations, can consist of any number of areas from overall tracking design down to the proprietary software and hardware used. The goal of this team was to develop a functional inventory control system focusing on DVD rental store in order to prove that their tracking methods worked successfully. Since rising technology is always something with which to be experimenting0, the team designed the system and tracked the inventory based on RFID technology, as it is becoming more and more popular and cost effective every day. The team solved this problem by developing a fully functional inventory control system including tracking software vital to its function as well as any hardware needed for completion of the project.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download