Skip to main content

This is a prototype vision of how a future government service could work. It's not a real service yet, but we're exploring what it could look like. Your feedback will help shape the real service.

Step 3: Understand IoT Data Flow - Smart Car Park Walkthrough

Learn how sensor readings become real-time dashboard insights

Walkthrough progress

Step 3 of 4 • 3 minutes

Step 3 3 minutes

Understand the IoT Data Flow

See how sensor readings travel from parking spaces to your dashboard in real-time.

Find your Smart Car Park dashboard URL in CloudFormation Outputs
Live dashboard showing parking space availability across all sites

Expected outcome

  • You understand how IoT sensors detect vehicles
  • You see how AWS IoT Core receives sensor messages
  • You know how Lambda processes and stores data
  • You recognize CloudWatch's role in visualization

From sensor to dashboard: The complete journey

Every parking space in the car park has an ultrasonic sensor that continuously monitors vehicle presence. Let's trace the path of a single sensor reading from detection to dashboard:

AWS services explained

This walkthrough uses several AWS services working together. Here's what each one does:

AWS IoT Core

Role: Message broker for IoT devices

What it does: Receives MQTT messages from 50 sensors, each publishing occupancy state every 2 minutes when state changes. IoT Core can handle millions of messages per second, so 50 sensors is trivial.

Why it's useful: IoT Core manages device authentication, message routing, and topic subscriptions. You don't build a message broker yourself - AWS provides enterprise-grade infrastructure.

Cost: £1.00 per million messages. With 2.16M messages/month (50 sensors × 30 msg/hour × 24h × 30 days), that's just £2.16/month.

AWS Lambda

Role: Process sensor readings

What it does: Every time IoT Core receives a sensor message, it triggers the ProcessSensorData Lambda function. Lambda validates the reading, stores it in DynamoDB, calculates zone metrics, and publishes to CloudWatch.

Why it's useful: Lambda runs your code without servers. You only pay for compute time used (milliseconds per execution). No idle servers, no capacity planning.

Cost: £0.20 per million invocations. Processing 2.16M sensor messages/month costs £0.43/month.

Amazon DynamoDB

Role: Store historical sensor readings

What it does: Stores every sensor reading as a time-series record. Each record includes sensor ID, timestamp, occupancy state, and confidence level. DynamoDB keeps 7 days of history (then auto-deletes via TTL) for trend analysis.

Why it's useful: DynamoDB scales automatically from zero to millions of requests per second. No database servers to manage, no downtime for schema changes.

Cost: With 5 read/write capacity units and 2GB storage, ~£3.50/month. Predictable pricing regardless of traffic spikes.

Amazon CloudWatch

Role: Dashboard visualization and alarms

What it does: Lambda publishes custom metrics (total occupancy, zone occupancy, average duration) to CloudWatch. The dashboard you're viewing queries these metrics and renders charts. Alarms trigger SNS notifications when occupancy thresholds are exceeded or sensors go offline.

Why it's useful: CloudWatch handles all the complexity of time-series metric storage, aggregation, and visualization. You define widgets, CloudWatch does the heavy lifting.

Cost: 10 custom metrics + 1 dashboard + 3 alarms = ~£5/month. Includes 15-month metric retention.

What makes this \"wow\"?

Compare this to manual car park management:

Before: Manual

  • 2 staff walk all 3 floors every 2 hours
  • Count occupied spaces with clickers
  • Write counts on clipboard
  • Back in office, enter into Excel
  • Create charts manually
  • Data is 30-120 minutes old by the time it's visible
  • No after-hours monitoring (staff work 9-5)
  • Cost: 1.5 hours/day × 260 days × £25/hour = £9,750/year

After: IoT + AWS

  • 50 sensors monitor continuously (24/7)
  • Occupancy detected automatically via ultrasonic distance
  • Data published to AWS IoT Core instantly
  • Lambda processes and stores in 2-5 seconds
  • Dashboard auto-generates charts in real-time
  • Data is never more than 15 seconds old
  • Works overnight, weekends, holidays without human intervention
  • Cost: £145/year for AWS services

Impact: What took 1.5 hours of manual work daily now happens automatically in real-time. Staff freed to focus on customer service and complex problems. Data quality improves (no human counting errors). Operational cost drops by £9,750/year.

Something went wrong? Troubleshooting help

I don't see the dashboard updating

Possible solutions:

  • Check auto-refresh is enabled - Look for "Auto refresh" toggle (top-right), ensure ON and set to 10 seconds
  • Verify IoT simulator is running - Lambda console → IoTSimulator function → Recent invocations should show activity
  • Check CloudWatch Logs - Lambda console → ProcessSensorData → Logs tab → Look for "Published metric to CloudWatch" messages

How can I verify data is flowing?

Three checkpoints:

  1. DynamoDB table: Open DynamoDB console, find SmartCarPark-SensorReadings table, click "Explore table items" - should see ~1000 records
  2. Lambda invocations: Open Lambda console, click ProcessSensorData, Monitor tab shows recent invocations graph
  3. CloudWatch metrics: On your dashboard, click any widget's 3-dot menu → "View in metrics" → See raw metric data and timestamps
← Back to Step 2 Continue to Step 4: Explore Trends & ROI

Need help?

If you're stuck, check the troubleshooting section or contact us.