Functional Requirements

 

The Badge Tracker System project will cover the development and design of a system to track the locations of cardholders within a building or facility. It will use a modern tracking system to track the locations of people within the facility, using Identity Badges. Embedded in each ID badge will be a tracking device, such as RFID-based technologies, and optionally, security devices to provide instant, automated access to rooms based on the level of security of the cardholder. If implemented, each secure room within the facility will have a reader to detect the security device embedded in the card (such as a RFID tag or a magnetic stripe), connected to mechanisms that will unlock or open the door. Dispersed throughout the facility will be devices to read the tracking information embedded within the badges, collect the information, and send it to a central location to be sorted and otherwise managed.

 

 

The Database

The Badge Tracker System Database will be a central server designed to organize the database and provide an interface for extracting information from it, by both people and electronic peripherals. People must be able to access and modify the database through an easy-to-use graphical interface, explained below. A protocol must be developed for attaching individual peripherals (RFID sensors, card readers, etc.) in an extremely easy fashion, approaching the ease of plug-n-play, yet maintaining the security of the entire system as a whole. The system must also be designed such that new types of peripherals may be integrated into the system in a straightforward manner.

 

A User is considered to be an entry in the primary database. The primary database will be able to distribute and/or modify the following information:

• Each User's name
• A unique identity number corresponding to a single ID badge
• The level of (internal) permissions each User has been given
• A list of all rooms to which each User has access
• The current location of each User, in reasonable real-time
• A history of each User, tracking all rooms the User has entered and exited, each with a time stamp marking the time and date of entry/exit
• A history of changes to the primary database and the information it distributes
• Class and therapy times and locations

 

 

The Interface

Different users will interact with the system in different ways. Some users will likely never see any direct interface with the database, but others will likely use it frequently. Therefore, the interface to the central system must be designed for a broad range of user groups. And as each user group will interact with the database in different ways, the interface must be adaptive for the various uses that will be demanded. All interfaces must be easy to understand and easy to use.

 

Administrators

An administration panel should be available for use by system administrators logged into the database. This panel should include the ability to add, remove, and edit the privileges and other settings of Users of any type, as well as the ability to create and define User Groups (such as Faculty, Student/Patient, Guest, etc.). In addition, Administrators need to be able to add and edit rooms, sensors, and other building information. They also need to be able to add/remove ID badges from the system, and associate them with different Users. Administrators should enjoy all the privileges, options, and interfaces of the other User Groups. It is not necessary, however, for Administrators to be able to access specific data on individual patients, and it may be preferable to separate private user data from system functionality to preserve each individual's privacy, or simply to omit private user data from the database altogether.

 

Faculty

The Faculty group, which will likely include Teachers, Therapists, and/or other similar employees, need access levels similar to the Staff but will likely use their access primarily in different ways. Therefore, Faculty should be given all the privileges, options, and interfaces of Staff, though they will likely not exercise these privileges often. In addition, they should have access to a Faculty panel when logged into the system. This panel will include the ability to view the private and tracking information of any Student under their immediate care, and will allow them to attach automated warnings to Students. The tracking information should be provided in a clear and easy-to-read manner, in several formats. This data will be used for accounting purposes such as accounts receivable and accounts payable. The data will also be used to verify students are receiving the correct treatments and education based on their individual needs.

 

Staff

When Security personnel and other staff log into the system, they should be presented with a graphical display of the entire building/facility with an easy-to-understand layout that will allow them to identify individual members and their locations easily within the building/facility. Staff should have the ability to define new safety protocols (e.g. escape plans) and automated warnings (e.g. child left unattended), as well as edit or remove existing ones, and they must be able to activate predetermined safety protocols in an extremely easy, straightforward, and especially quick manner. Staff will also have the ability to view and edit (but not necessarily create or remove) Student and Guest Users and their information. Staff will be given all the privileges, options, and interfaces given to Students.

 

Students

Users of the Student level and lower will not need to log into the database to use the system, though login privileges may (or may not) be allowed for the student to view his or her information and that of the Faculty and Staff. Instead, these Users will interact primarily with the hardware side of the system. Students will be given complete identity badges, imprinted with a photograph of the owner's face, and may remove these badges from the premises. These badges do not expire automatically, and will provide the Student access to the building. The Student is given all the privileges, options, and interfaces given to Guests.

 

Guests

The lowest level of privileges are given to Guests. Guests do not have any direct access to the database or its information, and by default will only be given access to the facility itself. Any number of Guest badges may be added to the system; each will have its own unique privileges and options, set by a member of the Staff upon distribution of the badge to an individual. When a Guest badge is activated, it will be given a time period during which it will be active. After the active period (and perhaps also if the Guest leaves the premises?), the badge will expire, and will no longer provide access to the facility or its rooms. It will, however, still be tracked within the facility.

 

 

The Hardware

Certain hardware is necessary for the proper functioning of the badge tracking system. This hardware should be easily obtainable through commercial means, and should be reasonably simple to set up.

 

Identity Badges

These contain the tracking and security tags that allow the system to track the movements of the owner throughout the facility. Each person within the facility will be required to wear an ID badge at all times — without a badge, a person will be invisible to the system.

 

Sensors

The building will contain sensors to identify and track people wearing badges. These sensors might include RFID readers, card-swipe readers and so on, and should be hot-swappable. (Ideally, sensors should be hot-swappable even with different types of sensors.) As a person moves around within the building, the sensors will extract the information contained in his or her badge and update the current location of that person as it appears in the database. This behavior will occur in real time, and must behave independently of any handicap(s) a person may have.

 

Some sensors may also be capable of unlocking doors or even triggering a door-opening device when activated by authorized users. If implemented, this system will behave independently from the tracking systems, and may include different, independent sets of sensors accessing separate sections of the database. Again, these sensors must behave independently of any handicap(s) a person may have.

 

Server

The database must be kept in a central location that can be accessed by all necessary hardware. The most obvious place for this would be within the facility itself, connected to an internal LAN, though it may potentially be located off campus. The server should provide a means of connecting securely to the database.

 

Terminals / Access Points

Users of Staff and higher clearance must be able to access and modify the information within the database and issue commands to the system. Ideally, they should be able to do this from any computer with a network connection to the database server, using some type of client-side software. A web-based front end should be given consideration.

 

 

 

Specifications List

 

A list of requirements is provided here to summarize the critical points of the system:

• database to track location, attendance, etc.
  • able to categorize data (e.g. movements and activities) in various useful formats
  • directly connected to and integrated with tracking system
  • accessible via internal website
• tracking system (buildings, rooms)
  • real-time
  • time stamp
  • easy-to-use interface for teachers/therapists/etc to keep track of movements
  • UI for security/administrators to track general people inside building
  • uses identity badges
• common-sense judgements (alarms)
  • multiple locations for the same identity
  • unauthorized admittance to secure locations
  • unattended child or other individual needing assistance
• allows for emergency procedures
  • provide a template for creating emergency scenarios
  • emergency notification system
  • easy to set up, quick to deploy
• authorized people need ability to change/adjust all aspects of system
  • need ability to create guest passes
  • easy way to add locations, rooms, users, etc.
  • create and restore backups
  • modify or adjust any automated tasks
• system backup and restoration
  • automatic and manual
  • off-site and on-site
  • secure
• easily upgradeable

 

 

Some additional features may also be developed for optional deployment:

• depending on user and setup, unlock or open doors automatically
  • automatic identification
  • must be appropriate for handicapped people
    • blind
    • wheelchair
    • low motor abilities
    • missing limbs?
  • close/lock door when appropriate
• display of name(s) upon entering a room