Posted on

Christine’s Status Report for 4/26

Progress

  • Implemented support for webhook registration and removal (PR).
  • Currently implementing the wrapper web app (Draft PR).
    • I will implement and test webhook notification after Andy fully deploys the web app.

Status:

  • Currently on track with all planned objectives.
Posted on

Christine’s Status Report for 4/19

Progress

  • Implemented API key for dash cam-related endpoints (PR).
  • Implemented post-assembly cleanup logic (PR).
  • Added chunk upload validations for data integrity (PR).
  • Added tests for edge cases (duplicated chunks, out-of-order uploads, invalid requests) to enhance test coverage (PR).
  • Implemented GET /plates endpoint for dash cam latency benchmark (PR).

Tools & Knowledge Learned

I had to learn AWS from scratch. I used a mix of informal learning strategies: online videos and tutorials helped me get started with AWS services. AWS CDK documentation and online code examples were extremely helpful. Additionally, GitHub Copilot helped me write tests more efficiently, and GPT was invaluable in clarifying any conceptual questions I had about AWS. These resources and tools really helped me navigate the challenges of my project and significantly boosted my understanding of cloud computing.

Status:

  • Currently on track with all planned objectives.
Posted on

Christine’s Status Report for 4/12

Progress

  • Implemented Chunk Upload Protocol (PR): Successfully developed and integrated the chunk upload protocol. For detailed information on the implementation and updated flow, please refer to the PR description.
  • Added Match Log (PR): Developed and added a match log feature to track and record relevant data, enhancing our ability to monitor and analyze system performance and matches.
  • Integration Test with the Team: Collaborated with the team to conduct integration testing.
  • Currently on track ✅

Verification

  • Watchlist Management: Added manual tests and Jest automated integration tests to cover both the happy path and edge cases, such as invalid input and missing API keys.
  • Watchlist Query Requests: Implemented manual tests along with Jest automated unit and integration tests to handle cases involving matched plates, unmatched plates, and invalid inputs.
  • Image Upload: Added Jest integration tests for the end-to-end image upload process to ensure comprehensive coverage and reliability.
  • To-do:
    • Chunked Image Upload: Add Tests for Edge Cases (#14):
      • Develop and execute tests for various edge cases to ensure the robustness of the chunk upload protocol, including:
        • Scenarios where chunks are missing or uploaded out of order.
        • Handling invalid requests, such as those with missing fields in the /uploads API.
        • Managing duplicated chunks to prevent errors and ensure data integrity.

All tests are integrated with our CI/CD pipeline, ensuring continuous verification and validation of the system as changes are made.

What’s Left to Do:

  • Implement API key for dash cam communications
  • Add tests for chunked image upload edge cases
Posted on

Christine’s Status Report for 3/29

✅ What I Did This Week

Chunked Image Upload

  • After discussing with Vicky, we realized that Blues Notehub’s 8KB file size limit requires us to use chunked uploads for images (~45KB).
  • Initially researched S3’s multipart upload, but it requires larger file sizes, so we decided to implement the logic from scratch.

Overview of Chunked Upload Protocol (details in PR description):

  • Splitting: Dashcam splits the image into ≤8KB chunks, each containing metadata (image_id, chunk_id, total_chunks, and data).
  • Uploading: Chunks are uploaded individually to the backend via API Gateway → Lambda → temporary S3 bucket.
  • Tracking: Lambda tracks received chunks in DynamoDB to monitor progress.
  • Assembly: Once all chunks are uploaded, a Lambda function assembles the image and stores it permanently in S3. Temporary chunks are cleaned up afterward.

Progress on Implementation:

  • I’ve set up the skeleton for the entire process: splitting, uploading, tracking, and preparing for assembly.
  • Still need to write the Lambda function for assembling the image and test the full workflow.

Improved Observability

  • Added more logging using CloudWatch X-Ray to monitor API Gateway usage in real time.
    • Tracks failure rates and latency to help identify performance bottlenecks.

🚧 What I’m Working on Next Week

  1. Interim Demo
  2. Finish Implementing Chunked Upload
    • Write and test the Lambda function that assembles image chunks into a complete image.
    • Debug and test the entire process end-to-end.
  3. Integrate Chunked Upload with Dashcam System
    • Work on integrating the chunked upload process with the dashcam system.
    • Coordinate with the team to ensure everything works smoothly.

📌 Overall Status

  • On Track: The chunked image upload is the most complex part of the system, but we have a solid design in place. While there’s still work left to finish and test the implementation, I’m confident we’re moving in the right direction.
Posted on

Christine’s Status Report for 3/22

✅ Progress This Week

  • Finished the initial implementation of the match upload layer (PR Link)
    This layer handles the ingestion, processing, and storage of detected license plate matches. The flow is as follows:

    • Dash cams upload images via pre-signed S3 URLs

    • An S3 event triggers a Lambda function to:

      • Extract GPS and timestamp metadata from image EXIF

      • Store the metadata in the match_logs table in DynamoDB

    • Architecture: S3 → S3 Event → Lambda → DynamoDB (match_logs)

  • Documented the full flow in the PR description, covering:

    • Pre-signed URL generation

    • Upload handling via S3 and Lambda

    • Metadata extraction and logging

    • All changes are fully covered by tests

This gives a scalable and decoupled foundation for matching plates to images and metadata.

🚧 What I’m Working on Next Week

  • Dash Cam Integration

    • Begin integrating the new match upload layer with the dash cam system

    • Revisit existing endpoints (/detections, S3 upload) to determine required changes

    • Prioritize approaches that minimize friction for the dash cam side

    • Coordinate with others for schema consistency across services

  • Observability Improvements

    • Expand CloudWatch logging:

      • Currently tracks S3 and Lambda activity

      • Will add API Gateway request logs, performance metrics, and error tracking

    • Goal: improve visibility into API usage, failure rates, and overall latency

📌 Overall Status

Currently on track. The core functionality for match upload is complete and tested. Integration with the dash cam system will be the main challenge next week.

 

Posted on

Christine’s Status Report for 3/15

Progress This Week

  • Completed Watchlist Management Layer (PR)
    Implemented an AWS Lambda function for managing the global watchlist, integrating DynamoDB for storage and API Gateway for HTTP access. The system now supports adding, retrieving, and removing plates via secure API endpoints. All changes are covered by manual tests and automated Jest tests with CI/CD.

  • Redesigned API Interface Based on Design Report Feedback
    Based on the design report feedback, we adopted the “tip line” approach instead of a full web app. I redesigned the API interface to expose a POST endpoint for law enforcement agencies to add plates. See the team status report for detailed changes.

  • Refactored for API-First Approach (PR)
    Removed the web app dependency (no more officers) and restructured watchlist management endpoints (/plates) to work with API keys. /detections now only checks for plate matches without officer tracking, and /plates requires an API key for modifications. The refactor simplifies external service integrations and is fully covered by automated tests.

In Progress

  • Match Upload Implementation (Draft PR)
    Implemented a Lambda function for extracting metadata, logging matches, and attaching images to S3. Integrated DynamoDB for match tracking. Currently testing and debugging before deployment.

Overall Status

  • The project is on track with API refinements complete and match upload nearing finalization. Here’s a list of API endpoints ready for integration.
Posted on

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.
Posted on

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.

Posted on

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.
Posted on

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.