Christine’s Status Report for 3/1

Progress

  • Design Report Completed: Finalized and refined the system design after conducting additional AWS research. Key architectural changes were made based on our findings (see the team status report for details).
  • Updated Central Server Block Diagram: The design now reflects the latest refinements, ensuring clarity in system architecture. 
  • CI/CD Pipeline Implemented: Initially, I was manually setting up AWS services, but as the project grew, it became unsustainable. To streamline deployment, I set up a repository (Github Repo) with CI/CD (PR), which now automates testing and deployment. The folder structure is modular and designed for maintainability.
  • Watchlist Query Layer Implemented: A basic version (PR1 + PR2) is now complete and fully tested with manual tests + jest tests, though it currently operates without message queuing. The system generates and returns a pre-signed URL for secure data access.

In Progress

  • Web App Access Layer (Watchlist Management): Currently working on implementing this to allow the web app backend to post updates to the global watchlist. I’ve completed a basic implementation and tested it manually (draft PR).  I plan to add a Jest test suite for automated testing. My goal is to wrap this up as soon as possible so the web app can begin integrating with it.

Next Steps

  • Set Up Web App Backend Architecture: Set up a basic backend folder structure (controller, model, db, env) and implement a basic authentication endpoint to enable user login. Once completed, Andy will be able to take over further web app backend tasks.

Overall Status

  • The project remains on track. While the workload is demanding, the transition from manual AWS setup to automated CI/CD has significantly improved efficiency. Now, my focus is on completing the web app integration to ensure smooth interaction with the backend.

Christine’s Status Report for 2/22

🟢 Progress This Week

Design Presentation Preparation

    • Finalized slides for the Design Review Presentation and helped Vicky prepare.

Database Design

  •  Designed the database schema for both the central server (DynamoDB + RDS) and web app backend.
  • Defined table structures for:
    • Global watchlist (DynamoDB)
    • Match history & notifications (RDS)
    • Officer authentication & access logs (RDS)
    • Personal watchlists (DynamoDB)

Central Server Implementation

  •  Set up API Gateway endpoint for /detections, forwarding plate detections to an SQS message queue.
  • Configured DynamoDB tables (global watchlist).
  • Set up RDS tables for match history & notifications.
  • Added Lambda function to listen to SQS, process messages, and query the global watchlist for matches.
    • Notification back to dash cam will be integrated in the future after we know more about Blues.

🔜 Next Steps

  • Design Report (⏳ Priority)

    • The big focus for next week.
  • Web App Backend – Authentication
    • Set up backend folder structure (microservices-based, MVC pattern).
    • Implement authentication (Auth controllers, models, DAO layer).
    • Ensure REST endpoints for authentication are accessible for the frontend.
  • Continue Implementation for Central Server
    • Test end-to-end for POST /detections.
    • Start implementing the match upload layer.

📌 Overall Status

Currently on track.
Making good progress, but next week will be heavy on implementation and documentation.

Team Status Report for 2/15

Risks

  • Power supply: RPi 5 needs 5V5A to function with peripherals and RPi 4 needs 5V3A. In-car usb ports can only provide 5V2A max. In-car cigarette lighter ports can provide 12V10A on average, but the supply is not stable and there can be current spikes. Market voltage regulators seem to be able to provide 5V5A max and 5V3A when at load. Our mitigation plan is to test if the power supply is enough for RPi 5. If not, we will switch to RPi 4.
  • Proper RPi shutdown: If we directly connect the in-car power source to the RPi board, each time the ignition turns off, the board will be forced to shut down, which damages the board in the long run. Our mitigation plan is to research the capacitor and circuitry so that RPi begins the shutdown process when the ignition turns off.
  • Edge computing: We updated our ML flow to do all the work on edge, and this means higher computational demands on dash cams, requiring optimization to ensure real-time processing. Our plan is to use lightweight models optimized for edge devices.
  • Legal compliance & privacy risks: The system involves license plate recognition, law enforcement access, and data storage. Unauthorized access and misuse can lead to legal issues and breaches of privacy laws. We researched legal considerations but need to define the project scope—we cannot implement everything.
    • What we will support:
      • Controlled officer access with authentication & audit logs
      • Watchlist justification (officers must provide a case number to track plates)
      • Data retention policy (match records auto-expire after 90 days)
    • What is out of scope:
      • Full identity verification system for officers
      • Integration with external law enforcement databases
      • System-wide hacking/data abuse protections (beyond standard security measures)
  • System scalability: The system needs to handle 314k concurrent requests, which can overwhelm the infrastructure if not optimized. For the central server design, instead of using a traditional EC2-based architecture, we’re leveraging API Gateway with Lambda and DynamoDB for scalability. To validate the system’s ability to handle high loads, we will conduct AWS-based load testing to optimize performance and identify potential bottlenecks before deployment.

Changes

  • User requirement: We modified our processing speed requirement to capturing 2 frames of each legible license plate, given that these frames tend to capture similar results in field testing. This reduces the load on edge devices.
  • To improve network connectivity and GPS tracking, we switched to using Blues Notecarrier and Notecard instead of other modules. Reasons for Change: 
    • Seamless cellular connectivity for real-time data transfer
    • Built-in GPS module for accurate location tracking
    • Lower power consumption compared to traditional LTE modules
  • Based on faculty and TA feedback, we moved OCR processing from the central server to onboard dash cams to improve system efficiency, effectively reducing the number of frames that need to be transferred. This change reduces server load by distributing computation to edge devices but introduces an increased processing burden on the dash cams.

Schedule

Special Questions

A was written by Christine, B was written by Andy and C was written by Vicky.

  • Public Health, Safety or Welfare Factors: PlatePatrol aims to improve public safety by providing law enforcement with real-time alerts on vehicles linked to crimes, enabling faster response times and aiding investigations. By leveraging a crowdsourced ALPR (Automatic License Plate Recognition) network, the system extends vehicle tracking beyond fixed cameras and dedicated patrol units. This has the potential to enhance law enforcement coverage, making it easier to locate stolen vehicles, track suspects, and respond to incidents more efficiently. However, it also introduces risks to public welfare. Without strict access controls, officers could misuse the system for unauthorized tracking. Additionally, if not properly secured, the system could be vulnerable to hacking, exposing sensitive vehicle and officer data. To mitigate this, we enforce JWT-based authentication with short expiration times, require officers to provide justification for adding plates to their watchlists, and implement data retention policies that automatically remove records after 90 days. These measures help prevent misuse, but the system still depends on law enforcement agencies to uphold ethical standards and enforce oversight. For real-world deployment, additional safeguards would be needed, but for the sake of prototyping, we would focus on the core functionalities of an end-to-end system.
  • Social Factors: PlatePatrol will primarily target law enforcement officers and public safety agencies responsible for trying to prevent crimes taking advantage of track vehicles. PlatePatrol is designed to offer an affordable solution to take advantage of crowdsourcing to fix the gap in the modern day automatic license plate recognition system that plays a role in protecting community safety. Being able to be placed on normal vehicles can help with license plate detection in urban environments which are less covered by existing solutions and have a high vehicle density. PlatePatrol also provides regulations and options to promote responsible technology use and protect data security and user privacy. Overall, our system prioritizes public safety and responsible technology deployment, ensuring that law enforcement officers can effectively serve their communities while maintaining transparency and ethical data practices.
  • Economic Factors: PlatePatrol addresses the economic inefficiencies and coverage limitations of traditional ALPR solutions by leveraging affordable dash cams and a decentralized data collection model. Current ALPR systems rely on specialized, high-cost cameras installed on law enforcement vehicles or fixed infrastructure. PlatePatrol reduces the dependency on government-funded installations while expanding coverage to a broader geographic area, including roads and regions that were previously uneconomical to monitor. From a production and distribution perspective, PlatePatrol (~$300) is significantly cheaper than traditional ALPR systems (~$50k), leading to a more distributed and economically viable model. On the consumption side, law enforcement agencies can access license plate data at a lower cost, improving operational efficiency and public safety without requiring significant infrastructure.

Christine’s Status Report for 2/15

🟢 Progress This Week

Central Server Architecture Refinement

  • Shifted OCR processing from central server to onboard dash cam after faculty & TA feedback.
  • Refined layered architecture with API Gateway, Lambda, S3, and DynamoDB for scalability.
  • Updated central server design to reflect this change.
    • Before: OCR was centralized.
    • After: ALPR & OCR runs on the dash cam; the central server focuses on match verification & notifications.

API Design & System Components

  • Defined RESTful resource structure for plates, matches, and notifications and esigned API endpoints for central server:
    • Detection upload
    • Match storage & retrieval
    • Police portal access
  • Researched AWS-based load testing approaches for handling 314K concurrent requests.

Web Application Enhancements

  • Drafted design document outlining:
    • Vision & Key Features: Watchlist management, real-time alerts, match history search.
    • Use Cases: Detailed core flows for authentication, watchlist updates, and search.
    • Database Considerations: Decided on DynamoDB (watchlists) & RDS (match history).
  • Defined the interactions between web app backend and central backend.

Presentation Preparation

  • Began preparing slides for the upcoming design review presentation.
  • Drafted content covering architecture, security, scalability, and use case breakdown.

🔜 Next Steps

  • Design Report  🫠

  • API Gateway Setup & Testing
    • Configure routes for core API endpoints.
    • Manual testing to make sure API Gateway is properly set up.
  • Database Schema Design & Setup
    • Implement schema for DynamoDB (watchlist storage) and RDS (match history).
    • Ensure indexing and query optimization.
  • Lambda Integration for Message Queueing
    • Implement Lambda function to process incoming detections asynchronously.

⚠️ Challenges & Open Questions

Legal Compliance & Scope Definition

We researched legal considerations but need to define the project scope—we cannot implement everything.

  • What we will support:
    • Controlled officer access with authentication & audit logs.
    • Watchlist justification (officers must provide a case number to track plates).
    • Data retention policy (match records auto-expire after 90 days).
  • What is out of scope:
    • Full identity verification system for officers.
    • Integration with external law enforcement databases.
    • System-wide hacking/data abuse protections (beyond standard security measures).

Privacy & Data Security

  • Encrypt all stored & transmitted data (end-to-end encryption).
  • Require officers to justify searches (case number, reason) to prevent misuse.

📌 Overall Status

Currently on track.
The project has been demanding, especially since we aim to design a distributed, scalable system that can efficiently handle high loads. However, we have made a lot of progress on the design side, and we feel confident to start the implementation phase.

Christine’s Status Report for 2/8

🟢 Progress This Week

Cloud Computing & Central Server Architecture

  • Researched AWS services (API Gateway, S3, SQS, EC2, Lambda, DynamoDB, RDS, SNS) and their interactions.
  • Designed a layered architecture with AWS services for image uploads, ALPR processing, and watchlist queries.
  • Explored SQS for asynchronous processing and caching strategies to handle high loads and avoid bottlenecks.
  • Documented the complete system flow for implementation.

    Web Application Design

  • Finalized the tech stack with Andy:
    • Backend: Node.js with Express.js
    • Frontend: React with Ant Design
    • Storage: DynamoDB (real-time watchlist), RDS (structured match history)
  • Designed core use cases:
    • Authentication (JWT-based login system)
    • Watchlist management (add, remove, view plates)
    • Notification center (email alerts via SNS, UI-based alerts)
  • Designed REST APIs with interfaces

🖊️ Progress

I’m currently on track.

▶️ Next Steps

API Design & Review

  • Design API endpoints for the central server, focusing on data ingestion, ALPR processing, and watchlist matching.
  • Review API endpoints for the web portal based on team feedback and refine where needed. Know issues:
    • Each user should have their own watchlist –> update /watchlist to support look-up by user ID

Database Design

  • Decide between DynamoDB vs RDS for different use cases.
  • Design database schema for central server watchlist storage & web portal authentication.

Use Case Design

  • Finalize Use Case Details
  • Define the full flow for each core use case (authentication, watchlist management, notifications).
  • Add alternative flows to ensure edge cases are accounted for.
  • Send finalized use case flows to Andy for UI design adjustments.

System Architecture Documentation

  • Create a block diagram for the central server.

    🚧 Challenges & Open Questions

  • Potential performance trade-offs in database selection (DynamoDB vs RDS) for different use cases. 
  • EC2 vs Lambda for ALPR layer.