Document Type

Restricted Campus Only

Publication Date



Current emergency technology for school shootings is very basic, relying largely on faculty training and basic alarm technology. Alarms are usually activated via emergency buttons arranged throughout the school or online programs requiring a log-in. These methods are cheap and easy to install, however running to an emergency button or logging into a computer program takes time and current school alarms provide very little information about the location of the threat. The K- 12 Security System Team proposes the design and implementation of a system to aid school authorities to minimize the risk posed to students and staff in case of gun threats in K-12 schools.

The system must be quick and unobtrusive to activate and should be able to locate and communicate the source of the activation. The system must also have two levels of alarm- a subtle alarm for pre-shooter situations where de-escalation may be possible and a blaring alarm for active shooter situations. The preliminary system design should also be cheap enough for a school to purchase, which our advisor recommended to be a total budget of around $3,200. Since this is a proof of concept, our prototype stayed well under that constraint as well as Trinity’s own $1200 budget cap. The system also needs to be active for the entirety of the school day, so any mobile components should have a battery that lasts at least a semester or a rechargeable battery.

To satisfy the requirements the security team broke the project up into 3 subsystems. These subsystems include the central computing unit (CCU), portal beacon, and handheld fob device. Splitting up the project in this manner allowed for us to better track our progress and ensure that each subsystem can run on its own.

The team experienced time production slowdowns due to the pandemic keeping one of our three members off campus, winter storm delivery delays, and several faulty Arduino systems. Despite these limitations, the K-12 security team was able to build the fob, portal beacon, and CCU subsystems and successfully update a database using signals sent from a phone-sized, handheld fob. The prototype has multiple alarm levels and stores both the alarm level and ID number of the fob.