Project Details

Project Description

Our project, developed in collaboration with General Dynamics Mission Systems, focuses on creating a secure and resilient remote door controller system designed to protect critical infrastructure. General Dynamics operates numerous remote facilities across the United States that house sensitive, high-value equipment. This creates a need for reliable access control that protects assets while supporting operations. The challenge is ensuring secure access for authorized personnel even during network disruptions or power outages. Our goal is to create a robust solution that allows administrators to securely monitor and control door access from anywhere in the world, providing real-time logging, intrusion detection, and remote credential management.

Software & Security Requirements

These are the requirements outlined by General Dynamics Mission Systems.

1. The system shall notify operators with a cautionary alert when there is a change in the state of an intrusion detector.
2. The system shall notify operators with a cautionary alert when actions to enter controlled areas are detected.
3. The status panel shall indicate access status to a shelter.
4. The intrusion detector shall support three states: no access, authorized access, and unauthorized access.
5. The system shall report authorized and unauthorized entries to shelters to the Control Center via an IP interface.
6. The system shall use protected mechanisms (e.g., passwords) to authenticate the identity of system operators and administrators.
7. The system shall protect against internal and external unauthorized access. (Did confirm this means within the organization and outside the organization)
8. Fixed facilities shall incorporate intrusion detection capabilities.
9. Intrusion detectors shall monitor and automatically report status changes to the control center.
10. The system shall maintain functionality and reliable communication over high latency (high ping 400ms) network connections.
11. The system shall automatically recover from network outages and resume normal operations without manual intervention.
12. The system shall perform software and firmware upgrades manually initiated and able to complete over high latency (high ping 400ms) network connections. In case of a network outage during the upgrade, the system shall ensure it does not leave the system in an unrecoverable state.
13. The system shall support SNMPv3 for securely reporting intrusion status and system status.
14. The system shall use current industry-standard encryption protocols (e.g., TLS, HTTPS) for secure communication between all parts of the system.
15. The system shall keep a history of intrusion and system events/alarms for auditing and analysis purposes.

These requirements will be expanded and also further classified using the MoSCoW prioritization method. The categories are Must-Have (MHx), Should-Have (SHx), Could-Have (CHx), and Won't-Have (WHx) where the smaller number marks the more important requirement of the classified requirements.

Must-Have Functional Requirements

1. FR1 (MH1) - The system shall notify operators with a cautionary alert when there is a change in the state of an intrusion detector.
2. FR2 (MH2) - The system shall notify operators with a cautionary alert when actions to enter controlled areas are detected.
3. FR3 (MH3) - The status panel shall indicate access status to a shelter.
4. FR4 (MH4) - The intrusion detector shall support three states: no access, authorized access, and unauthorized access.
5. FR6 (MH5) - The system shall use protected mechanisms (e.g., passwords) to authenticate the identity of system operators and administrators.

Should-Have Functional Requirements

1. FR5 (SH1) - The system shall report authorized and unauthorized entries to shelters to the Control Center via an IP interface.
2. FR7 (SH2) - The system shall protect against internal and external unauthorized access.
3. FR8 (SH3) - Intrusion detectors shall monitor and automatically report status changes to the control center.
4. FR9 (SH4) - The system shall support SNMPv3 for securely reporting intrusion status and system status.
5. FR10 (SH5) - The system shall use current industry-standard encryption protocols (e.g., TLS, HTTPS) for secure communication between all parts of the system.
6. FR11 (SH6) - The system shall automatically recover from network outages and resume normal operations without manual intervention.
7. FR12 (SH7) - The system shall keep a history of intrusion and system events/alarms for auditing and analysis purposes.

Performance Requirements

1. PR1 - The system shall maintain functionality and reliable communication over high-latency (400 ms) network connections.
2. PR2 - The system shall perform software and firmware upgrades manually initiated and able to complete over high-latency (400 ms) network connections; in case of outage, the system must remain recoverable.

Environmental Requirements

1. ER1 - Fixed facilities shall incorporate intrusion detection capabilities.

Above all, a critical requirement is the system's resilience; it must ensure continuous operation on high-latency networks and maintain its secure state through power and network outages.

Envisioned Solution

Here is a high-level diagram and summary of our plans to fulfill the requirements.

Each door lock is controlled by a Raspberry Pi that hosts a lightweight server. This server verifies user access when an RFID chip is scanned and communicates securely with the central system. Using Docker ensures consistent deployments and simplifies remote updates without on-site maintenance.

On the server side, the backend is hosted by AWS, which manages all communication, authentication, and data storage. A PostgreSQL database stores user credentials and event logs. The frontend, built in React, provides operators with a realtime dashboard for monitoring lock status managing users, and reviewing system events.

Schedule

Here is our expected development schedule to build this project.

Key Milestones

1. Decemeber 10 (End of Fall 2025 Semester)

   By the end of this semester we want to have our PostgreSQL database and sever developed, being able to handle the basic tasks of this project in a simulated environment.

   Once these have been implemented, we will begin developing the administrator website.

2. January 30 (Early Spring 2026 Semester)

   Soon after the start of the Spring 2026 semester, the administrator portal will be fully developed with a functional admin portal and all API endpoints with the database and server will be set.

3. February 30 (Middle of Spring 2026 Semester)

   About halfway through the semester, we plan to have fully developed the Docker instance that the Raspberry Pi will be hosting. Along with this, AWS will be hosted and connected to the system with all secure lines of communication.

   Once we have the software developed, we will be begin integrating the hardware.

4. April 30 (End of Spring 2026 Senester)

   At the end of next semester and the end of this capstone, we will have a fully developed system. The Raspberry Pi will be hosting the server in a Docker instance and all hardware will be integrated, being able to fulfill all of the requirements of this project.

   Finally, throughout this entire schedule we will be focused on quality assurance and proper integration of all components.