This Guidance for queue depth management shows how you can improve customer experience by monitoring queues using cameras, use computer vision to measure queue depth, and provide alerts about bottlenecks and unreasonable queue depths to customer service managers. Travel & Hospitality organizations can apply this solution to improve employee productivity, streamline lobby management, gain customer insights, reduce walkaways and negative perceptions of wait times.
Architecture Diagram
Step 1
Cameras are placed in important airport or hotel areas to improve customer waiting times.
Step 2
A machine learning model for human heads detection is deployed at the edge.
Step 3
An admin authenticates by using Amazon Cognito into a private dashboard to configure cameras and queues. The dashboard is hosted as a static website using Amazon Simple Storage Service (Amazon S3) and Amazon CloudFront.
Step 4
The admin can generate asynchronous screenshots from cameras and use the UI to highlight areas of interest and the queue threshold.
Step 5
The camera configuration is stored in Amazon DynamoDB and thresholds are propagated into an IoT rule.
Step 6
The edge device runs inference on the live video camera streams and only sends as many aggregated results in the cloud as the number of people in a queue at a specific time.
Step 7
The inference output is stored in Amazon Timestream for future processing and forecasting.
Step 8
When the queue threshold limit is met, an alert is sent into an Amazon Simple Notification Service (Amazon SNS) topic. Events are logged in Amazon CloudWatch for future analysis.
Step 1
Cameras are placed in important airport or hotel areas to improve customer waiting times.
Step 2
A machine learning model for human heads detection is deployed at the edge.
Step 3
An admin authenticates by using Amazon Cognito into a private dashboard to configure cameras and queues. The dashboard is hosted as a static website using Amazon Simple Storage Service (Amazon S3) and Amazon CloudFront.
Step 4
The admin can generate asynchronous screenshots from cameras and use the UI to highlight areas of interest and the queue threshold.
Step 5
The camera configuration is stored in Amazon DynamoDB and thresholds are propagated into an IoT rule.
Step 6
The edge device runs inference on the live video camera streams and only sends as many aggregated results in the cloud as the number of people in a queue at a specific time.
Step 7
The inference output is stored in Amazon Timestream for future processing and forecasting.
Step 8
When the queue threshold limit is met, an alert is sent into an Amazon Simple Notification Service (Amazon SNS) topic. Events are logged in Amazon CloudWatch for future analysis.
Well-Architected Pillars
The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you make when building systems in the cloud. The six pillars of the Framework allow you to learn architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems. Using the AWS Well-Architected Tool, available at no charge in the AWS Management Console, you can review your workloads against these best practices by answering a set of questions for each pillar.
The architecture diagram above is an example of a Solution created with Well-Architected best practices in mind. To be fully Well-Architected, you should follow as many Well-Architected best practices as possible.
-
Operational ExcellenceRead the Operational Excellence whitepaper
This Guidance has been written using the AWS Cloud Development Kit (AWS CDK) for infrastructure as code wherever possible. It can be easily redeployed into new environments with minimal setup. It has also been created with examples of how to route data for analysis purposes, in addition to having IoT rules established for the publishing of metrics and notifications.
-
SecurityRead the Security whitepaper
By default, all AWS IoT data in transit and at rest is encrypted. Data in transit is encrypted using TLS, and data at rest is encrypted using AWS owned keys. In addition, the frontend uses authentication through Amazon Cognito, which helps you control which users are able to access the system.
-
ReliabilityRead the Reliability whitepaper
All communications within the system are handled through AWS IoT Core MQTT messaging protocol, which allows for “At Least Once” delivery of messages. The edge device (simulated by an Amazon Elastic Compute Cloud (Amazon EC2) instance) is managed through the AWS Lambda runtime. Updates to those components are continuously version controlled and managed through deployments within AWS IoT Greengrass.
-
Performance EfficiencyRead the Performance Efficiency whitepaper
The computer vision model is developed to capitalize the resources available on the host system. Where GPU processing is available, it will use that to speed up processing. Images are automatically downscaled to decrease processing time.
-
Cost OptimizationRead the Cost Optimization whitepaper
To ensure that costs are kept low, the Guidance only uses a single EC2 instance to simulate an edge device and illustrate the function of the computer vision model. In addition, only the minimal usage of other AWS services is present within the system. These include a single Amazon S3 bucket for uploading pictures, a single DynamoDB table for storing queue vertices, and a minimal set of examples of using IoT rules to route data to CloudWatch. To further reduce costs, users can remove all of the IoT rules that route incoming data and run the model on their edge device.
-
SustainabilityRead the Sustainability whitepaper
This Guidance focuses on reducing environmental impact by only ever using the minimal set of resources required to make the system operate. There is very little resource usage throughout the system because it does not need to operate frequently or interact with many other services. For most of the time, the system will be inert until it is manually initiated by the user.
Implementation Resources
A detailed guide is provided to experiment and use within your AWS account. Each stage of building the Guidance, including deployment, usage, and cleanup, is examined to prepare it for deployment.
The sample code is a starting point. It is industry validated, prescriptive but not definitive, and a peek under the hood to help you begin.
Related Content
[Title]
Disclaimer
The sample code; software libraries; command line tools; proofs of concept; templates; or other related technology (including any of the foregoing that are provided by our personnel) is provided to you as AWS Content under the AWS Customer Agreement, or the relevant written agreement between you and AWS (whichever applies). You should not use this AWS Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the AWS Content, such as sample code, as appropriate for production grade use based on your specific quality control practices and standards. Deploying AWS Content may incur AWS charges for creating or using AWS chargeable resources, such as running Amazon EC2 instances or using Amazon S3 storage.
References to third-party services or organizations in this Guidance do not imply an endorsement, sponsorship, or affiliation between Amazon or AWS and the third party. Guidance from AWS is a technical starting point, and you can customize your integration with third-party services when you deploy the architecture.