1 / 24

Personal Safety and Alert Device

Personal Safety and Alert Device. CS 410 Blue Group Feasibility Fall 2010 Brittany Dufort, Daniel Cox, Marcus Henry, Braden Gibson, Ray Bland, Jon Szewczak. Societal Need.

ledell
Download Presentation

Personal Safety and Alert Device

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Personal Safetyand Alert Device CS 410 Blue Group Feasibility Fall 2010 Brittany Dufort, Daniel Cox, Marcus Henry, Braden Gibson, Ray Bland, Jon Szewczak

  2. Societal Need • In the event of a personal emergency, security professionals at higher education, business and civil complexes need an effective way to allow individuals to quickly and silently communicate their location to first responders.

  3. Impact • First Responders • Must rely on victims reporting accurate location data after or during a traumatic event. • Victims • Must be aware enough to make a phone call to emergency dispatch personnel. • Larger Populace

  4. Proposed Solution • Individuals would be equipped with a key fob. • Pressing a button or combination of buttons would trigger an alert at a security dispatch center. • The alert would be repeated every 30 seconds until first responders reset the unit.

  5. Benefits of Solution • Cuts response time • First responders do not need location information from victims. • Victims do not have to fumble around for a cell phone and dial a number; a button push is all that is required to summon aid. • If the victim is moving (i.e. on the run), the system will report their movement. • Based on proven technology. • Could act as a deterrent.

  6. Determining Customer • Many possible customers: • Universities or Colleges • Business complexes (i.e. Google, Microsoft, Intel, Trump Tower) • Civil complexes (i.e. the Capitol Building) • Scoping Issues • Due to time constraints the focus will be on Universities. • In particular Old Dominion University

  7. Old Dominion University • Spends approximately a $262,000.00 on security every year. • Personnel, Security Devices, etc. • In 2008* • 10 personal crimes on campus • 2 in residence halls • 4 off campus • 46 in the surrounding neighborhoods • That averages 1 crime per week for the entire year. * Data for 2009 and 2010 has not been collected, but it is reasonable to assume that the statistics are similar.

  8. Old Dominion University • The interest in the concept is very high. • A couple of weeks ago, two team members met with ODU Police officials, and were shocked at the eagerness that was displayed. • There would likely be very little financial return on investment. However, the ability to make students, staff and faculty a little safer could be considered an adequate return.

  9. Technical Aspects • Radio based • Key fob alert units (approx. 100’ range). • Transceivers stationed to give maximum coverage to the most logical areas (approx. 330’ range). • Relay Transceivers • A master receiver which would interface with the GUI at a dispatch station. • A software suite (most likely based on the Google Maps API) to provide a GUI for dispatch stations.

  10. Financial Issues (Hardware) • Each key fob has a nominal price of $20. • Uses Nordic Key Fob (model no. WRL-08602) as a base line • Each transceiver has a nominal price of $16. • Uses Nordic Transceiver (model no. nRF24L01+) as a base line • Does not include a NEMA-3 rated enclosure • Rough order of magnitude for quantities required: • Fobs = 4,500 (approx. # of students living on campus) • Transceivers = 5,000 (to maintain coverage over most important areas)

  11. Financial Issues (Hardware) • $20 (cost of Fob) x 4,500 (# required) = $90,00o • $16 (cost of transceiver) x 5,000 (# required) = $80,000 NOTES: • Cost of Fob could be passed on to students as an extra fee, or incorporated into housing fees. • The price of an adequate NEMA-3 or NEMA-3R enclosure was unavailable at the time this presentation was put together.

  12. Financial Issues (Software) • Two distinct areas of software development: • GUI interface for dispatchers • Firmware interface for hardware • Rough Order of Magnitude Estimates: • 400 – 600 man hours for GUI interface • 300 – 400 man hours for Firmware interface • Use a median value of $100 per hour (loaded) rate • $70,000 – $100, 000 worth of software development costs

  13. Financial Issues (Software) • Costs for initial software development are estimated. • Recurring maintenance and upgrades would be substantially less.

  14. Financial Issues (Miscellaneous) • Installation costs have not been addressed. • Customer will have to provide extra training for dispatch personnel on the use of the monitoring software. • There are equipment maintenance issues (i.e. battery replacement, faulty equipment replacement, etc.)

  15. Financial Issues (Summary) • $100,000 for initial software development • $160,000 for hardware • $260,000 total estimate of initial outlay • Unknown amount for other major line items NOTE: • These figures are not split between the customer and developer. • As previously noted, some costs could be passed on to the students in the form of additional fees.

  16. Project Team • There are 6 members of the Project Team • R. Bland () • D. Cox (Web / Presentation) • B. Dufort (PM / Software) • B. Gibson () • M. Henry (Hardware / Financial) • J. Szewczak (Hardware / Presentation) • Roles are defined by the skills and preferences of the team members.

  17. Project Team • Communication Methods • Team Members meet face-to-face twice a week • Out-of-class meetings utilize Google Chat services • One of the team members takes notes on the topics discussed during the meetings and post them to our project wiki.

  18. Risk Management • Financial • Technical • Legal • Possible Misuse / Deviant Usage

  19. Financial Risks • There is a substantial initial outlay • Potential recovery of costs for customers is marginal • Project puts emphasis on safety and not commercial viability • Unless hardware costs can be controlled, the system may preclude smaller institutions.

  20. Technical Risks • FCC Guidelines / Licenses • Possible interference from other broadcasting devices (i.e. cell phones, baby monitors, etc.) • Mitigated by proven radio technologies

  21. Legal Risks • Device fails to send an alert to the monitoring authority – introduces possible liability issues

  22. Possible Misuse / Deviant Usage • A lost alert device could be used by a criminal element to distract monitoring authorities from a real event. • System is used to pull pranks, instead of alerting first responders to a real emergency.

  23. Scope • Since the project is very large, it will have to be broken down into a more manageable chunk. • Customer – Old Dominion University • Hardware – a working prototype communicating with software • Software – a working GUI interface for mapping the location of the alert

  24. Questions?

More Related