Building a virtual fob with Amazon Key for Business and AWS IoT

For many people, getting a package delivered from Amazon is painless. However, problems can arise in access-controlled properties such as apartment complexes, condominiums, and businesses. This post tells how an Amazon team developed Amazon Key for Business to address this issue.

Overview

Amazon strives to make its package delivery process quick and easy for customers. However, sometimes an Amazon delivery associate can’t access a building for several reasons:

• The mail room is on a floor accessible only to authorized residents.
• The leasing office or business reception area is closed.
• Elevator access is restricted.

In these scenarios, customers must “buzz” drivers into the building and meet them in the lobby or even outside, which takes coordination on both ends. If the customer is not available, the delivery is even more difficult.

If there’s no safe location to leave the package, the delivery associate tries a re-delivery on a different day. This leads to delivery delays, calls to customer support, reorders, and sometimes many re-attempts before a successful delivery. Ultimately, it results in a poor customer experience.

Solution

To solve this problem, an Amazon team created the Key for Business service, which integrates with a building’s existing access system to grant authorized people temporary access to complete deliveries. This solution doesn’t disrupt tenant access, so residents and business owners can continue to use their existing access method (access card or remote control). Amazon is also looking into creating standalone units.

The Key for Business service consists of two parts:

• An Amazon proprietary smart fob unit, shown as follows

• The Amazon Flex delivery app, with the Deliver page shown as follows

The service involves four steps:

1. A delivery associate uses the Amazon Flex app to request access to a building.
2. The service verifies the delivery associate’s details, along with the building location and time of day.
3. The service grants the delivery associate time-bounded temporary access.
4. The delivery associate delivers the package to the relevant location (such as the lobby or mail room).

Architecture

To build a solution that millions of delivery drivers around the world can use to access buildings, the team used the following AWS services:

• Amazon FreeRTOS
• AWS IoT Core
• Amazon DynamoDB
• AWS Lambda
• Amazon API Gateway

Amazon FreeRTOS

First, the team selected an appropriate microcontroller unit (MCU) for this smart building use case. Rather than spending hours scouring the web for pre-built hardware kits, they went directly to the AWS Partner Device catalog. This resource contains a list of hardware qualified to work with AWS IoT services, so they could rapidly prototype a proof-of-concept (POC).

For hardware, the team chose a Curiosity PIC32MZ EF modularized hardware development kit. With this kit, they could easily add customized peripherals such as a building-access controller protocol chip, cellular connectivity, Bluetooth, and so on. Most of these peripherals came with vendor or community drivers and firmware, which further accelerated application development.

For software, the team used Amazon FreeRTOS as the software stack for their MCU. This operating system extends the popular FreeRTOS kernel with security and connectivity libraries to make it fast and easy to connect MCU-based devices to AWS IoT.

Because Amazon FreeRTOS operates under an open source MIT license, it’s free to download and deploy. The FreeRTOS kernel has a low 6–15 KB–memory footprint, making it the de facto, real-time operating system for MCUs. Its main features include:

• Local and cloud connectivity libraries to connect to AWS IoT Greengrass and AWS IoT Core.
• Secure cryptography through certificate authentication, key management, and code signing.
• Over-the-air (OTA) updates via a single TLS-secured connection.

For more information, see Amazon FreeRTOS features.

Because the devices are offsite, the team added a dedicated cryptography chip to store AWS credentials on the physical device itself. They enabled TLS1.2 so that MQTT messages between the device and the AWS Cloud can be exchanged securely. For remote updates, they used the OTA functionality, which allowed them to easily update the device’s software on an impromptu or scheduled basis.

Another benefit of choosing that particular MCU is that the vendor provided an integrated development environment (IDE) out of the box. This allowed the team to develop the application quickly on top of the Amazon FreeRTOS baseline and even to verify it with the kit.

After the POC phase, the team iterated the prototype device into a production version that reduced costs more than if they had used off-the-shelf hardware.

AWS IoT Core

With prototyping and POCs, you usually start with one device, then scale up to 10 or 100. However, the team needed something to help manage tens of thousands of devices. They chose AWS IoT Core, as it allowed them to manage devices at scale and paired well with Amazon FreeRTOS.

First, they used the AWS command line interface (CLI) to create unique AWS IoT credentials and then pushed them to the device. Next, they created a unique thing for each device and onboarded each to AWS IoT Core.

AWS IoT Core acts as an entry point for all the IoT devices and as a bridge to connect the devices to other AWS services. For example, MQTT messages are sent from AWS Lambda to every device and receive/validate a response. Devices also periodically send their status to AWS IoT Core, which kicks off an IoT rule to route them to AWS IoT Analytics for generating business metrics.

DynamoDB

The team needed a place to store data—in this case, device configurations. Due to their low-response-time needs, they used Amazon DynamoDB. This NoSQL offering provides single-digit millisecond performance at any scale, enabling the team to provide a low latency user experience.

Because their deployment occurs in phases, they opted for the on-demand capacity mode provided by DynamoDB so that they could start small and quickly scale out. This choice ended up giving the team the best balance between performance and cost. They also used the DynamoDB backup and restore feature to periodically back up their tables and recover immediately from disruptions.

For those readers wondering, “What about business metrics?,” the team set up an AWS Data Pipeline pipeline to convert the DynamoDB data into Amazon Redshift tables. That way, they could run any SQL query against these tables to generate business metrics.

Lambda and API Gateway

Because the team decided to use a serverless approach for their computing needs, all business logic was written as Lambda functions. There’s no need to manage server infrastructure because Lambda functions are written once, then called only when needed.

When a delivery associate uses the mobile app to request temporary access to a property, the calls are passed on to Amazon API Gateway. API Gateway then provides a RESTful API endpoint for the calls’ backend Lambda functions. API Gateway authenticates the calls from the mobile app, and, after authorization, routes messages to Lambda accordingly.

By pairing Lambda and API Gateway, the team could perform upfront authentication, which allowed them to authorize application access to AWS IoT Core. Lambda automatically scaled up to meet their demand by only running functions in response to each trigger from API Gateway. With no servers to manage, the user is not billed for unused capacity. Instead, they are charged only when the functions are invoked.

The following diagram shows the complete solution architecture described in this post.

Results

A pilot using this smart fob solution launched in 2018 in five buildings that had a relatively high volume of re-deliveries because of an unsuccessful first-delivery attempt (known as a high defect rate). The results showed that:

• Delivery associates accessed buildings to make a delivery without bothering residents or businesses.
• The first-delivery-attempt success rate increased from 96% to 98.1%.
• The building defect rate decreased from 2.4% to 0.8%.

After the pilot, production devices were rolled out to hundreds of buildings, with more scheduled for the future.

Summary

The team successfully used AWS IoT offerings to reduce the rate of undelivered packages. These services provided the following capabilities:

• Onboarding of devices to AWS IoT Core using the AWS CLI.
• Secure boot and OTA updates of devices with Amazon FreeRTOS.
• Management of devices as things through AWS IoT Core.
• Secure messaging with TLS 1.2 encryption between devices and AWS IoT Core.
• Routing of metrics and stats to AWS IoT Analytics through the IoT rules engine.
• The Amazon FreeRTOS abstracted IoT platform allowed the team to focus on creating the application and getting it to market as quickly as possible.

Want to experience the benefits of this successful delivery solution for yourself? To sign up for your own residential or business delivery, see Amazon Key for Business.

But wait, there’s more…

If you enjoyed reading about the development of Key for Business, check out our video walkthrough on an episode of IoT all the Things program. In the episode Connecting Buildings to New Opportunities with IoT, we talk about this solution—and even demonstrate the application and smart fob! Hope you enjoy the show!

About the authors

Frank Li is a senior embedded engineer at Last Mile IoT. He supports Amazon Last Mile customers by using IoT as both a technology and problem-solving approach to improve and reinvent deliveries.

Rudy Chetty is a senior solutions architect and hails from Cape Town, South Africa. He supports customers that fall under the Amazon umbrella, including Amazon Robotics, Fulfillment Technology, and Amazon.com. When not working, he yearns for a good Nando’s burger meal in his hometown along with enjoying the view from the top of Table Mountain. Howzit Kaapstad!