birmingham smart cities for health preventions3-eu-west-1.amazonaws.com/digitalbirmingham/...2...
TRANSCRIPT
SMART CITIES FOR HEALTH PREVENTION
Nicola Bryant, Birmingham City Council & Phil Crooks, Etive Technologies
Softcom 17 IoT and Smart City Services to Support Independence and Wellbeing of Older People 22/09/2017
BIRMINGHAM
AIM OF SESSION: IoT and Smart City Services to support independence of older people
2
Aim
◘ Context and background
◘ Role of IoT and smart city services - ambition for City4Age
◘ Overview of technical design and system architecture for Birmingham
◘ Technical challenges for data collection and detection
◘ Next steps
INTRODUCTION – The Challenge
3
INTRODUCTION - Ambition for City4Age
4
◘ Use and sharing of citizen data
◘ Interpretation of data (locality & contextual)
◘ Increase digital skills
◘ Accessibility, adoption and use of technology
◘ Stimulate private sector innovation
◘ Deliver new sustainable and cost-effectivce services for the future
New prevention services to promote healthy & active lives
INTRODUCTION - Pilot set-up for data collection and detection
5
◘ 2 phased pilot studies in contrasting neighbourhoods of Birmingham
◘ User centric iterative design
◘ Focus on outdoor environment
◘ Detect changes in daily living patterns
◘ Data collected in unobtrusive way
• Locality ; Motility data
• Other supporting data
◘ User feedback & validation of technology and non-technical aspects
SYSTEM ARCHITECTURE: Overview
6
SYSTEM ARCHITECTURE: Digital Log Book
7
SYSTEM ARCHITECTURE: Estimote Proximity Beacons
8
◘ Designed to attach to fixed points (walls, tables, shelves) to provide apps with location context.
◘ Bluetooth® SoC
◘ ARM® Cortex®-M4 32-bit, 64 MHz
◘ Bluetooth® 4.2 LE standard
◘ iBeacon and Eddystone protocols
◘ Power: -20 to +4 dBm in 4 dB steps
◘ Range: up to 70 meters
◘ 1 x CR2477, 3.0V Lithium cell
◘ Over three years of battery life on default settings (advertising every 300ms at -12dBm).
SYSTEM ARCHITECTURE: Deployed Beacons
9
Ley Hill Surgery, Sutton Coldfield, Birmingham
◘ Beacon Instance: c4a000002760
◘ Advertising interval: 300ms
◘ Transmit Power: -20dBm (range of approx. 3.5m)
SYSTEM ARCHITECTURE: City4Age Birmingham Locator App
10
◘ Very simple – smarts in Local Repository
◘ Runs on Android and iPhone (etc.)
• Cordova/Evothings JavaScript App
• Runs in the WebView
◘ Uses battery saving geolocation to decide when to scan for Eddystone Beacons
• Scanning paused when Beacons out of range or device stationary
◘ User registers using email address
◘ App sends:
• Hourly heartbeat
• Beacon Found and Lost events
◘ Usually runs in background without a UI
SYSTEM ARCHITECTURE: Nokia/Withings Watches
11
Data collected via the Healthmate app and collected on the Nokia server
◘ Activity
• Steps and distance
• Calories
• Rate of Activity Soft, Moderate or Intense
◘ Sleep
• Time to fall asleep
• Time asleep Deep or light sleep
• Times woken
• Time awake in bed
SYSTEM ARCHITECTURE: Local Repository (1)
12
◘ Grails 3 server (Groovy, Java, Spring, Hibernate)
◘ No User Interface needed
◘ Receives heartbeat messages from phones
◘ Receives Beacon Proximity events (Found and Lost events) from phones
◘ Holds information about
• Care Receivers
• Points of Interest and
• Beacon locations
◘ Runs nightly jobs:
• Translate the previous day’s Proximity events into POI events
• Fetch the previous day’s Activity and Sleep data from the Nokia server
• Upload POI events and Activity/Sleep data to the Central Repository
SYSTEM ARCHITECTURE: Local Repository (2)
13
TECHNICAL CHALLENGES: Detecting Beacons Reliably
14
◘ Beacon range set to 3.5m to increase accuracy of location
• Coverage 7m diameter
◘ Assume fast walking Care Receiver covers 4.5km/h or 1.25m/s
• Walk across the diameter in 5.6 seconds
• 9 km/h is fast ”power walking” and would need only 2.8 seconds
• Detection in 1.4 seconds should never miss an important beacon
◘ Beacon advertising
• Every 700ms to guarantee one advert in 1.4 seconds
• Default is every 300ms or four adverts in 1.4 seconds – use this
◘ Beacon detection
• Only detect strong signals: -90dB
• Beacon “found” if still detected 1.4 seconds after first detection
• Take 6x longer (8.4 seconds) to lose a ”found” beacon (trial and error)
TECHNICAL CHALLENGES: Battery Life
15
◘ Bluetooth scanning is power hungry
• 13mA (approx) per scan
• Need to scan constantly when near beacons
◘ Use location to turn on scanning when needed
• GPS is power hungry
• “Battery Saving” mode is not
◘ City4Age needs Lat & Lng for POI location
• Turn on BT scanning when close by
• Can create multi-location “regions”
◘ Turn off BT scanning when phone is stationary
◘ Efficiency could be improved further
• Native App
• Optimise use of location and Bluetooth
TECHNICAL CHALLENGES: Creating POI Events
16
◘ Beacon Proximity Event List is organised into Beacon Event Pairs (BEPs)
• A BEP is a Found event and its corresponding Lost event
• A Lost event followed quickly by a Found event is a Drop-out Drop-outs are ignored
• BEPs are categorised as Walk-by (events <= 60 seconds apart) or
Visit (events > 60 seconds apart)
◘ The BEP list is reversed making the first BEP a POI exit
• A working assumption, the Care Receiver may have walked past
◘ POI exit events (BEPs) are “stacked” to allow POI Locations to be nested
◘ Iterate through the list looking for adjacent BEPs from same location
• If BEP has same location as a stacked exit event generate POI events
• If not, empty stack and add the new BEP
• Visit BEPs can generate POI entry and exit if no other match
TECHNICAL CHALLENGES: iPhones
17
◘ The Birmingham City4Age App runs on iOS
• But only in the foreground!
• Unfortunately the App runs 24x7 and mostly in the background
◘ iOS limits use of system resources in the background to conserve power
• Many common, core Bluetooth tasks are disabled
• App may be terminated to free up resources
◘ Core Bluetooth Background Execution Mode
• Bluetooth-central mode allows device discovery but…
• Can only discover a device once (no way to detect entry and exit)
• The scanning interval increases so will not detect all Beacons
◘ Geolocation has similar limitations
◘ Great battery life but Apple’s rules are too restrictive for research
• Need to be able to take control to explore possibilities
NEXT STEPS
18
◘ User testing and validation
◘ Learning and iterative design to inform development of 2nd pilot study starting October 2017
◘ Implementation of the intervention phase
◘ Refinement and resolution of manageable data detection apsects
◘ Addressing limitations in device capabilities
FOLLOW US!! http://www.city4ageproject.eu/ www.digitalbirmingham.co.uk
City4Age Project Digital Birmingham
@City4AgeProject @digibrum