presented by Charles Dittmer

Sr. Manager – Wireless Business Unit, ARM

case study: IoT application demo …from Bluetooth® connectivity to IoT cloud services

ARM is everywhere

#1 shipping GPU in

the world is Mali

1000+ Partner ecosystem

> 5Bn People using

ARM-based

mobile phones

100Bn ARM-based

chips shipped to

date

1. Must be a real-world application

2. Uses many of the new Bluetooth 5 and other enhancements/capabilities

3. Must show as much ARM content as possible from end device to the Cloud

What demo illustrates Bluetooth connectivity to the IoT Cloud?

Demo requirements:

Smart parking meters

• Certainly a real world application

• Great use of Bluetooth low energy technology

• IoT cloud connectivity

• Used in conjunction with other wireless technologies

(NB-IoT)

And the winner is…

Source: San Francisco Municipal Transit Agency

before I go too far…

…special thanks to Scott Jenson at

Google for the inspiration and vision for

the Eddystone based parking meter.

…and Yes, there is a market research report on smart parking systems

• Smart meters $53M business in 2017

• CARG of 25% over the next 10 years

• Equates to a $1.78B industry over 10 years

• Real-world benefits

• Huge source of revenue for municipalities and private lots

• Moscow study showed a 25% reduction in traffic

congestion

• Other benefits include: Reduced CO2 / GHG, increased

efficiently/commerce, etc.

• Usual concerns with unit cost, deployment, maintenance

• What we wanted to accomplish?

• How did we put things together? (and in a hurry)

• What real-world issues did we discover?

• How we are evolving the demo to add functionality, be more real-world, solve

design and usability issues which we have discovered

Please enjoy our journey. Let’s have some fun!

Case study: Bluetooth low energy parking meter

8

“gen 1”

prototype

ARM mbed

Connector Bridge

in Watson IoT

6

8

4 Commerce

Mobile Application

3 IoT 5

IBM Blockchain

7 2

2

Physical

Web

ARM

MCU

1 Eddystone

URL

So how does this work?

®

So how did we build this?

Source: www.mbed.com

mbed Developers Forum; mbed.com

• Everything you need to develop IoT

devices and applications

• Full support for over 100 mbed-

enabled boards and more than 400

components

• Free web-based tools for building,

debugging, testing and collaborating

across mbed work flows

• Rich third-party tool support from

industry leaders 1M+ monthly

device

builds

Picking a base platform…..

Selection criteria

• mbed OS compatible

• mbed Connector compatible

• mbed Client API

• Arduino R3 form factor

• Ethernet for Backhaul (Gen 1 & 2)

Source: www.mbed.com

Kinetis MK64FN1M0VLL12 in 100LQFP

• ARM® Cortex™-M4 32-bit core

• 120 MHz max CPU frequency

• 1024 KB program flash memory

• 256 KB RAM

• 1x 10/100 Mbit/s Ethernet MAC controller

• 1x USB 2.0 Full-/Low-Speed Device/Host/OTG controller

• 1x Controller Area Network (CAN) module

• 3x SPI modules

• 3x I2C modules. Support for up to 1 Mbit/s

• 6x UART modules

…so here are the pieces

Arduino Grove Shield NXP FRDM-K64F ARM Cordio®

demo board

mbed Application Shield

with LCD

mbed OS 5

Source: www.mbed.com

• Platform OS with IoT specialized

features - Unified support for key IoT

connectivity standards

• RTOS core based on CMSIS-RTOS

• Cortex-M processors and Cordio

radio IP supported

• Seamless connectivity to mbed

Cloud

• API-based architecture for

customizations

• Secure

• Provides updates, provisioning,

connection

Our fully functional prototype

“Stack-o-Boards” Parking Meter App

Multiple Beacons: How to manage DOZENS , HUNDREDS , THOUSANDS of beacons

Source: The New York Times

• Parking meter only send beacon signal when not in use

• Once time is purchased, GPIO lines shuts down Bluetooth radio

• Simple hack was just to use the radio RESET line

• This will be problematic with future enhancement that use Bluetooth radio for additional

functions

• URL includes parking meter number

First crude attempt to reduce the number of beacons transmitting

“gen 2”

1. Clean up design

• Single motherboard, closer to “productization”

2. Better address multiple beacon issue

• Wrong meter scenario

3. LED status indicators

4. Reset time when car leaves space

• Large source of lost revenue for municipality

5. Automated ticketing

• Like red light cameras, toll rolls

6. Create platform for future enhancements

Gen 2 design goals

• Turn down TX power to reduce range

• Possible but can cause other connectivity issues

Multiple beacon – Possible resolution

Yagi Antenna

Sources: L-COM, VK Logger Forum, www.antenna-theory.com

• Sense when car is present

• Only have beacon on when car is present and meter

payment is required

• Use of directional antennas

• Again better but can have adverse effects

• Selected ranger from mbed.com

development board components

• Downloaded device driver and

code examples from mbed forum

• Greatly reduced multiple beacon

issue

• Only starts beacon when car is

detected. Shut-off when time is

purchased

• Resets time when car leaves

Use of ultrasonic ranger

Source: www.mbed.com

Real-time parking monitoring

Parking status

• Transition (Yellow)

• Paid/Active (Green)

• Expired (Red)

Surface lot example

Enables more accurate parking status and flow

Entrance signage Eddystone beacon based app • Shows available parking as you arrive

• Gives you “Where’s my car” as you return Source: Signal-Tech

Street parking scenario

16

6

1

2

5

10

4

0

4

3

0

1

0

1

0

Source: Google maps, 2017

• Welcome to Austin, Texas

Available spots

per city block

• Selected camera from mbed.com

development board components

• Downloaded device driver and

code examples from mbed forum

• Captures license plate number

for ticketing on expired meters

• Can identify long time offenders,

abandoned cars, stolen cars

• Possible security/safety use

• Future auto-payment recognition

Use of jpeg camera

Source: LinkSprite

Source: www.mbed.com

LED status indicators

Parking status

• RED = expired, unpaid

• YELLOW = transition

• GREEN = paid/active (free parking)

• BLUE = available

Device management

IBM Watson and mbed Connector Service

• Defining and orchestrating parking meter behavior is an IoT device management activity!

• Integration of ARM mbed Connector service to IBM Watson via Watson IoT ARM mbed Connector

extension

• Behavioral/management operations defined in Watson IoT's NodeRED application dashboard

• Additional integration with IBM Blockchain Services and IBM Payment Gateway

mbed Connector dashoard mbed Connector – Watson IoT Bridge NodeRed application console

Data flow decision tree

Allows setting of various conditions

• Parking pricing

• Dynamic Pricing

• Special events

• Free parking

• After hours, Sundays

• Ranging configuration

• Image processing, recognition

• LED control, definition

• Beacon control

Our gen 2 design….

Come see demo

in our booth

Meet the designers!

29

“gen 3”

… what’s next?

• Add mesh support

• Bluetooth mesh support independent of beacons operation

• Flood moving to routable mesh

• Add ARMs new NB-IoT solution as backhaul (replaces Ethernet/Wi-Fi)

• Add solar cells – based on low power ARM processors/Cordio radios

• Lowers installation and maintenance costs

• Still thinking… Send us some ideas!

Gen 3 Goals

Physical

Web

ARM

MCU

ARM mbed

Connector Bridge

in Watson IoT

1

2 7

6

Eddystone

URL

4

5

Mobile Application

3

Commerce

IoT

IBM Blockchain

2

8

Backhaul

NB-IoT

BLE mesh

9

®

Bluetooth 5 + Mesh

Bluetooth 5 Beacon

Us

NB-IoT

Bluetooth 5

NB-IoT Central payment system scenario

Use of Bluetooth still applies

Use of Bluetooth 5 and other Bluetooth low energy enhancements

Advertising Length Extensions

• For longer URLs with specific parking space data

2Mbps

• For transmission of camera (picture) data for

ticketing

• SW/FW upgrades

Mesh support

• Communication across meters to jump to backhaul

Coded PHY (Long range)

• For distant meters

IP/Security support

• For addressing and security

ARM Cordio WPAN IP products

Complete ARM radio IP solution

• ARM Cordio radio front-end

• Support for Bluetooth 5 and/or 802.15.4

Flexible architecture

• Choice of radio standards with software

• Interface to non-ARM radio front-ends

3rd party

2.4 GHz Mixed Signal

Radio Front End (RFE)

NB-IoT: Mistbase + NextG-Com + ARM

Complete pre-verified, carrier approved IP sub-system for NB-

IoT from antenna to L3 software

Secure, power efficient, designed for rapid integration to

SoCs

London, UK

Layer 2 and 3 software

Lund, Sweden

Layer 1 digital and software

Processor and security solution

RF front-end

Send us your ideas!

ARM = IoT

Doug.Anson@arm.com

Charles.Dittmer@arm.com

thank you! The trademarks featured in this presentation are registered and/or unregistered trademarks of ARM

Limited (or its subsidiaries) in the EU and/or elsewhere. All rights reserved. All other marks

featured may be trademarks of their respective owners.

Copyright © 2017 ARM Limited