Team bikes research proposal a. P. A. 6th Bikeshare Intended Keyless Encrypted Smartlock Research Proposal



Download 203.7 Kb.
Page3/4
Date19.10.2016
Size203.7 Kb.
#4090
1   2   3   4

Focus Group

The objective of this phase will be to understand why students do or do not use the bikeshare available to them on campus.  The focus group will allow participants to talk about the factors contributing to whether or not they participate in the bikeshare on campus, and it will allow them to elaborate on their concerns and their outlook on the program.

Design of focus group. The team will conduct two different focus groups involving 10 to 14 participants.  The participants will be asked to stay for one hour, and they will be given lunch or dinner depending on what time of day the team conducts the focus group.  For the first portion of the session, the team will direct conversation regarding the student’s current opinion and feelings towards Capital Bikeshare. The team will ask the students to talk about why or why not they choose to use the bikeshare system in place on campus.  After a certain amount of time of letting the students talk about their current opinions, the team will intervene and propose the stationless bikeshare and smartlock that Team BIKES is working towards creating. The students will then be asked to give their input on such an idea, and asked if they have such interest in such a bikeshare.  Students will also be guided to giving their opinions regarding how to improve the design and possible problems with the stationless bikeshare’s smartlock design.

Sampling of focus group. The team will target to find a total of 20 to 28 participants.  Half of these participants will include current users of Capital Bikeshare; while the other half will be composed of people who do not use Capital Bikeshare.  The sampling will allow various opinions to be present in the focus group.  Furthermore, Team BIKES will receive feedback from two different potential consumers of the potential product.  Participants will be selected from the responses to the bikeshare interest survey.  Emails will be sent to anyone who listed their email  in the bikeshare interest survey to invite them to participate in the focus group.

Data collection of focus group. Team Bikes will record the discussions and topics discussed and brought up throughout the two focus groups.  As to not miss anything mentioned, multiple members of the team will be responsible for recording notes.  Also, the team will inform the participants that the audio from the session will be recorded

Data analysis of focus group. After examining the recording and notes from the session, the team will organize to talk about what topics came up from the two sessions.  Common responses will be written on a whiteboard for the team to go over and discuss.  The team will draw conclusions based upon responses regarding improvements regarding the smartlock.  Taking all of these factors and topics from the focus groups, the team will able to better orient the project to better suite the needs and input from students on campus. There are coding techniques that might help you organize your findings. I have a few books in my office that might help.

Expected results of focus group. The team expects that the focus group will yield certain problems with Capital Bikeshare, such as a subscription fee, limited amount of stations, cumbersome bicycle design, and general inconvenience. The team expects a healthy and positive reaction towards the implementation of a stationless bikeshare that implement a smartlock that addresses the students’ concerns regarding Capital Bikeshare.  

Locking Mechanisms

The team will research different methods of securing bicycles based on existing studies and experimentation on existing locks.  This will determine the best material, type, and location of a lock that can withstand most attacks by a thief using readily available hand tools.  The team will attempt to answer the research question, “What is the most effective way of locking a bicycle for a dockless bikeshare system?”  Specifically, the team will look at lock type, material, and location of the lock on the bicycle to determine effectiveness.  The objective is not to prevent every determined thief who brings specialized tools, but to prevent unprofessional thieves from being able to steal the bicycles with any easily accessible devices.

Specifications regarding size, dimensions, weight, price, and durability will be taken into consideration when designing the bicycle lock.  Using the results of the locking survey that will be distributed to bicycle riders on the College Park campus, the team will determine the most common bicycle lock type and location, such as through the frame, wheel, or a combination of items.  The survey will also ask whether a user’s lock has ever malfunctioned or if the user has had a bicycle stolen that was locked on campus before.  This survey will provide valuable information on where it is easiest or most common to lock a bicycle for students and faculty on campus and the correlation between type and location of lock versus theft on campus.  

Using these survey results, the team will decide which of the most popular lock designs such as U-locks, chain locks, and cable locks, will be considered to undergo failure testing.  The team then will decide which materials are the most suitable for each type of lock, such as steel bars for U-locks and titanium cable for cable locks.  To assist with determining what material will be used in the lock, the team must additionally look into existing bicycle lock materials and manufacturing data, and then move on to conducting preliminary testing on no more than five types of materials.  This testing will consist of, but not limited to, angle grinders, bolt cutters, levering16, and striking30 (Horaczek, 2012).  These are some of the most common methods used to break through all types of bicycle locks.  The team will need to design and execute a controlled test for each considered lock material by cutting through each with angle grinders, bolt cutters, prying each apart with the levering technique using a crowbar or other similar type of rod, and striking each lock with hammer and chisel.  All locks will inevitably fail, however, the team’s objective is to make a potential thief work the lock for as long as possible to deter them from stealing more bicyles, and increase the chance that someone will notice their illegal activities.  The testing will be carried out on new materials and at standard conditions within the lab; however, the conditions will be held constant across tests to reduce possible inconsistency with the testing and will be repeated at least three times to minimize the inconsistencies of the locks and materials themselves.  Team BIKES will strive to control as many variables as possible to minimize external influences on testing.  Weather will not be a test variable, but because of the sensitive electronics housed inside of the main body of the lock, there will be a watertight seal which will minimize ice expansion stresses.

The test will consist of at least four quantifiable components, which include shear stress, axial stress/tension, impact stress, and time. These values will reflect a numerical approach to examine each of the most common lock breaking methods corresponding to a different striking technique.  For the shear stress, the team will be testing the applied force of the bolt cutters on the different materials and locks.  Levering techniques will result in axial stresses/tensions, which tests the material’s strength and at the mechanical connection point between the U-lock and locking tumblers.  Striking with hammer and chisel result in impact stress, especially when the lock is resting on the ground.  The team will measure the time it takes for the angle grinder to cut through locks and test materials. From those tests, the team will compare the data for each lock and decide which lock and material would be most appropriate for a stationless bikeshare system.  

With the data obtained from testing, the team will be able to design and manufacture a lock that can provide the flexibility and security needed for a stationless bikesharing system.  The goal is to create a working prototype by retrofitting one bicycle as a proof of concept.  The lock will be integrated into the physical design of the bicycle frame to prevent theft of the lock and make the system more resilient.  From the lock and bicycle dimensions, the team will be able to determine the most secure location for the lock.  In the end, Team BIKES hopes that the innovative bicycle lock will deter theft as well as increase mobility in bicycle locking.



Short-Range Wireless User Identification

In order to create a system that will effectively unlock the smartlock electronically, the team has decided to implement Radio-Frequency Identification (RFID) technology.  Team BIKES will research how to incorporate RFID technology into the lock design and how students will be able to interact with locked bicycles, looking to identify how to use RFID effectively to allow students access to a locked bicycle.  The team will strive to answer the aforementioned research question, “How can an efficient user identification system be implemented so that it can be used to unlock smartlocks?”

Key benchmarks will be installed in product development and testing will occur in small intervals on each component that will become a part of the user identification system.  These benchmarks will serve first and foremost to maximize the efficiency of the system as well as maximize the security functions of the lock.  Then the focus of the RFID component will shift to further minimize the size of the components and lower the cost of the system.  The team will start development of the component system under the following three assumptions: commercially purchased RFID reader and/or RFID tags are both less expensive and more reliable, the tag reading system installed in the smartlock are smaller than 15 cm2 (Mally, 2012), and the system are best implemented using short range RFID communication (Roslee, 2012).  

In order to answer the research questions, the research must be able to compare different RFID systems for the smartlock, accumulating general knowledge of multiple RFID systems through existing literature and technical reviews.  The first benchmark of the RFID component to be complete is choosing between using Bluetooth Arduino shields and using NFC Arduino shields to read the RFID tags.  The two types of communication were selected due to the close proximity communication characteristic and the recent trends in the smart card24 market.  Multiple factors will be considered when making this decision.  The first of these factors is the response time needed to read the RFID tags.  A faster response time will likely increase system satisfaction among student users, which has led the team to set five seconds as the maximum response time.  The RFID range is another important factor to consider because the tag reader needs to be able to read the RFID tag when the user intentionally presses the tag against the reader and not at any other time.  Furthermore, the RFID’s low range adds to the natural security of the system because communications are less susceptible to interference (Wozniaki, 2013).  Among other factors, the cost and power requirements of the RFID need to be minimized.  Additional considerations include memory limits, space requirements, and the durability of the RFID reader.  



In addition to the hardware that will be used, the style and procedure for programming the RFID tags must be determined.  The initial selection process for a system of encoding the tags will not follow the design of a conventional experiment, but will involve extensive research into the properties of each encoding scheme.  For instance, the ability of the encoding to detect errors is a property inherent to the code that can be determined before its implementation (Givonne, 2003).  The second benchmark will be the selection of up to three different styles for encoding the RFID for further testing.  The coding scheme must be able to uniquely encode every user ID (UID) using a relatively small number of bits with a secure algorithm.  The code’s error detecting9 and correcting capabilities will also be taken into consideration.  

As its next benchmark, the team will build a RFID reader using the selected microcontroller and corresponding RFID serial port module27.  In order to make the RFID reader operational in a timely manner, software readily available through open source projects which explain the procedure behind using RFID communication in conjunction with a microprocessor to scan RFID tags, will be modified to better fit the team’s purpose.  Once the RFID reader is complete and working properly, selected encoding styles will each be used to code UIDs onto three RFID tags, for a total of nine encoded tags.  The ability of the RFID system to read the tags quickly and reliably will then be tested by exposing each tag to the reader for a minimum of 10 times and recording the length of time it takes the RFID reader to acknowledge the tag and the frequency10 of errors, such as tag misidentification or the failure of the reader to communicate with the tag.  In order to ensure consistent exposure, each tag will be set on the RFID module during testing.  The direct placement of the RFID tag will eliminate the differences in the induced magnetic fields as a result of inconsistent range.  The removal of the variation in range between trials will yield reliable response times for each encoding scheme that can then be compared.  The time required for the RFID reader to identify the tag is measured beginning from the time the tag is situated on top of the RFID module until the arduino relays the information to the attached computer.  Following this process, the encoding style most successful in maximizing security while minimizing response time and overall error will be chosen and further improved.  The testing will then be repeated using modified versions of the selected code.  This process will continue with periodic user feedback from team member trials.  The team members will use the different encodings to access the system, and their input will be taken into consideration when improving the system.  The testing represents the fifth benchmark, and will begin immediately following the completion of the RFID system and will finish when it is found to be adequate for consumer use.  

To ensure that the tag reader will operate successfully in the smartlock, it will need to be enclosed in a material similar to that of the final protective casing and tested using a patch antennae21 instead of direct contact with the RFID tag.  The influence of a protective case for the RFID reading system will need to be addressed at a further stage of research.



Ultimately, the team hopes to create a functional RFID system that can be integrated in to the designed locking system at low costs, low power requirements, and high reliability.  RFID is one of the world’s most used methods of payment and information sharing because of its convenience and it is beginning to be incorporated into everyday security, such as door locks (Park et. al, 2009).  A smartlock system using RFID technology would be a necessary innovation to add security and convenience necessary for commercially competitive stationless bikeshare28 program.

Geolocation

In order to keep track of the location of each bicycle, Team BIKES must answer two questions: (1) “What is the most effective and expandable way to implement the hardware necessary for wireless communications on a bicycle?” and (2) “How does the team develop, test, and implement a computer software that is capable of communicating with electronic devices on bicycles to collect locational and usage data as well as presenting this information in an easily understandable way?”

To answer the first question, the team must develop a wireless system to enable communication from the bicycles to a website.  To do so, the team will follow three main steps: (1) define what hardware qualities are desired, (2) find the best pieces of hardware based on data sheets found online, and (3) perform a series of small experiments that expand on each other to optimize the design.  Much of the data needed to answer the question depends on what is desired.  The team must first decide what specifications are desired in the hardware by considering factors such as size, function expandability, performance, and cost.  The team will make these decisions by looking at data sheets and analyzing the survey results.  

The team must optimize the system’s characteristics of size, cost, speed, power consumption, and accuracy while making the system agree with the requirements set by the potential users.  After determining the desired characteristics, the team will look into different vendors’ hardware options for microcontrollers, GPS modules, and wireless options, such as a GSM/GPRS board.  Once the team reviews the data sheets, it will order the hardware necessary to begin running experiments.  Some anticipated hardware options include: the Arduino Uno for the microcontrollers, GPS modules and antennas from Parallax, and expansion boards (shields) from Arduino or third party vendors.  The team will conduct independent experiments to ensure that every part of the wireless communications system works before integrating the separate components.  The combinations of components that will be tested separately include the combination of the microcontroller and the wireless component, the combination of the microcontroller and the GPS module, and any other possible add-ons to the microcontroller.  Once each piece is proven to work separately, the team will put all the components together to provide the rest of the team with a working system.  At that point, the team will decide how to best use the time remaining to improve the system.  



To answer the second question, the team will look to develop computer software that continuously communicates with the electronic hardware equipped on the bicycles to closely monitor the bikeshare system.  Once the software is able to accurately pinpoint the bicycles’ location, using the GPS-obtained data sent through a GPRS TCP/IP socket connection29, and retrieve user information as well as bicycle identification number, using RFID data, the team will determine that the software is ready for beta testing.  After obtaining promising results from the hardware testing, the team will determine the software’s performance by comparing the data retrieved by the software to the known real-time location and user information of bicycles operated by the team.  Specifically, the team will operate the test bicycle, equipped with the electronic components listed above, on a predetermined route (e.g. a round trip between McKeldin Library and The Diner).  During the testing, members will establish a phone call between those who are operating the bicycle in the field and those who are testing the software at a remote location.  The phone call will provide the team knowledge of where the bicycle is located in real-time; they can then compare this information with the data received by the software and, therefore, conclude whether or not the wireless data transmission is working as intended.

In order to develop a piece of software with the specifications described above, the team will need to comply with the technical specifications of electronic devices equipped on the bicycles.  Different models of wireless transmission devices work with different formatting and data translation methods; for example, many GPS devices communicate data in CSV format under the standards set by the National Marine Electronics Association18 (NMEA); and the Arduino microcontroller uses a low-level programming language that is structurally and syntactically based on C/C++.   The team can then develop computer algorithms to parse the information obtained from the wireless transmission devices (e.g. GPS coordinates, bicycle number, and user credentials, etc.) into an easily readable string.  The software will incorporate these parsing algorithms and apply them to a variety of programming and data encoding languages.  

Ultimately, the team anticipates that a simple system for both the hardware and software will be completed with enough time allotted to adjust the system to reflect the survey results.  Since the hardware will be commercially obtained at the beginning of the experiments, there are few issues foreseen, aside from troubleshooting the compatibilities between various components.  The software aspect of the system is predicted to provide a satisfactory quality of service; it will function as an easy-to-use platform for both administrators and users.  It will be developed in a flexible fashion, such that future expansion can be easily applied based off user input.

Limitations

Although Team BIKES believes that this research will produce valuable results, the team recognizes that there are considerable limitations to the scope of the project, as well as the ability to effectively apply the data that is gathered through different phases of work.  Due to the team’s focus on multiple research questions, the limits in the degrees to which the team can answer each question have different ramifications for the project as a whole.  The level of confidence that the team has in the survey results determines how widely applicable assumptions about bikeshare opinions are; however, restrictions in the precision of testing for the technical parts of the system may cause the performance of the smartlock to be less than ideal.  Overall, these constraints have compelled Team BIKES to pursue only a proof-of-concept of a stationless bikeshare on the University of Maryland’s campus rather than a fully operational commercial bikeshare.  

The survey responses that the team will collect can only evaluate potential outcomes of the bikeshare system under very specialized conditions, as the primary objective of this research is to provide insight into the opinions held by a specific demographic - students on large college campuses that can benefit from a bikeshare; as a result, it should be noted that the team’s findings cannot automatically be applied to the general public.  In addition, the survey responses will likely be skewed by the bias of the participants, which comes from many potential sources, including self-selection and prior acquaintance with the members of Team BIKES. To prevent this bias, the team has considered taking appropriate measures to decrease its reliance on data collected from individuals who are familiar with the Gemstone program and the team’s goals; methods such as random sampling may be particularly helpful.

Confounding variables also limit the veracity of the survey results.  For instance, factors like income, physical activity level, and/or previous experience with bikeshares could significantly interfere with the data if not properly accounted for. To minimize the effects of these noises on the overall data trend, the team will make every effort to survey a large sample of individuals and obtain demographic information on each participant.  The team will also make use of statistical tools (such as regression) to address these demographic differences.

When testing the different materials that could be used for building the smartlock, the most significant limitations will be the availability of time and equipment.  Extensive wear testing cannot be realistically carried out on the materials due to the high cost associated with the required equipment.  Without this testing, the longevity of the locking material cannot be assured; but for the mere implementation of the lock as part of a proof-of-concept design this is a tolerable oversight. Environmental conditions, such as inclement weather and other unforeseeable natural phenomena, may negatively impact the materials’ durability; however, Team BIKES do not have the resources to conduct testing for different situations past ensuring that all electronics are sealed away from the water in the environment. When performing testing on materials, there will always be some variability in the samples and testing conditions that can interfere with the conclusions that are drawn based on the experiments.  To account for the slight differences in properties between given pieces of material, each type of material will be tested multiple times and average data values will be used to make final decisions regarding the material from which the lock will be constructed.  The environmental conditions and settings of the experiments will be carefully controlled to be consistent across all trials, though temperature and humidity may still vary slightly.  

Investigations of different RFID tags and encodings will face similar obstacles. Specifically, variability in computer processing time and RFID tag quality will impact testing.  Again, these potential confounding variables will be accounted for using multiple trials and averaging the results.

Not only does the team face challenges when ensuring the quality of the tests that will allow the team to make final decisions regarding the design of the bikeshare and smartlock system, but it is also constrained by the properties of commercially available components and the certain ethical ramifications of the proposed system.  As undergraduate researchers, the team appreciates that it will be most effective if it purchases hardware and materials rather than creating its own.  For the design of the RFID, this means that the efficiency and speed of the system will not be optimized because using commercial hardware implies that extra circuitry meant for functionalities not required for this project has been embedded in the technology to be used.  The ability of the lock to withstand brute force attacks is also limited by the materials that the team can procure, though security as a whole could still surpass existing locks by improving users’ ability to operate the lock.  The choices regarding the use of GSM technology will have to take into account the monthly fee that major cellular providers charge and the privacy of bikeshare users.  One possible conflict is that the anonymity of the bikeshare users could be compromised since the location of the bicycle that they are using is known at all times.  Another privacy concern regarding the software application is that the information about the bikeshare users could be compromised if left unprotected, since user specific information is transmitted via RFID.  These factors may hinder the team’s ability to acquire data concerning the bikeshare’s performance after it is introduced.

There are clear limitations to the design of the bikeshare system; by restricting the scale of the project, however, the team can minimize the common bikeshare concerns such as vehicle theft and vandalism.  This will allow the team to focus on compensating for the potential shortcomings in testing accuracy and to produce a design that is feasible.



Download 203.7 Kb.

Share with your friends:
1   2   3   4




The database is protected by copyright ©ininet.org 2024
send message

    Main page