SW Asset based servicedevelopment with LoRaconnectivity

Erkki Häkkinen

RAMP project in Etteplan

• The main goal was to develop IoT platform for accelerating the IoT system development

• The second goal to test and developcommunication technology on LoRa

• Technology development project Results applicable in all similar IoT applications

Considerations with health technology

SW Asset development

CLOUD

IoT System in scope

3G/4G/InternetLocal connection

(e.g. modbus)

LoRAWAN

”point-to-point”

Gateway

WiFi / sub-giga

Transparent

Gateway

MQTT/TLS

IoT System Architecture with LoRa

WATSON

IOT

platform

3G/4G/Internet

LoRAWAN

Application logic

- Device / Fleet mngt

- User mngt

- Data / Event processing

- App specific logic

User interface

- REST API

- WEB server

- HTML5 client

- Mobile apps

Storage

- Device data,

- Device fleet data

- Measurement/time serie

- Event

- Unstructured data

External integrations

AnalyticsMQTT/TLS

MQTT/TLS

LoRAWAN

LoRAWAN

Asset development for cloud

• SW Platform → SW Asset

• Common design pattern in IoT systems

• ”Only those what are missing”

• A set of loosely integrated components in the sameframework, integration through internal APIs

• As generic node.js and Java based software applicable to any Linux platforms

• Bluemix mostly used in applications

IoT - Local System in Gateway

WATSON

IOT

platform

3G/4G/Internet

LoRAWAN

https / LAN/ WLAN

Application logic

- Device / Fleet mngt

- User mngt

- Data / Event processing

- App specific logic

User interface

- REST API

- WEB server

- HTML5 client

- Mobile apps

Storage

- Device data,

- Device fleet data

- Measurement/time serie

- Event

- Unstructured data

Analytics

External integrations

MQTT/TLS

Application logic

- Device mngt

- Data / Event processing

- LoRa comm. logic

- App specific logic

Storage

- Device data,

- Device fleet data

- Measurement/time serie

WEB UI

Shared asset in local gateways and cloud

• Local management functions without cloud connection• No network

• Local configuration devices over LoRa or other wireless channel

• Local device monitoring

• In principle the same functions as in cloud with a smaller set of features

• The same technology basis enables the shared assetin cloud and local systems

• Question: how far the same software baseline could bedeveloped for both platforms ?

Comparison of cloud and local assetsLocal gateway

• Restricted resources which leads to monolithic SW architecture

• Platform components tied with GW version

• Conflicts in software versions e.g. node.js

• Single user

Cloud

• Microservice architecture vs. monolithic system

• More versatile set of 3rd party components available

• Rather late versions and upgradesavailable

• Multi user

As conclusion

• Practically only framework and internal interfaces shared

• Only few basic interface components applicable in both platforms

• Platform specific adapters for both as separate

• The most significant benefit is a similar way of work

LoRa technology for wireless communication

LoRa technology

• LoRa stack• LoRa – physical layer for radio technology

• LoRaWAN – communication protocol stack

• Long range radio (up to few kilometers)

• Low energy consuming technology

• Good range inside buildings and similarbarriers

• Very restricted throughput

• Some limitations in two way communication

LoRa – Target application domains

• Simple sensoring with low cost

• Wireless communication in challenging environment

• Limited amount of data with lowfrequency

• Simple device control without realtimerequirements

LoRa – software asset

• LoRa gateway isolates the wireless communicationfrom cloud application

• LoRa gateway – secure communication with cloud

• Application protocol over LoRa always specific for each application to optimize the payload Shared function is routing messages through gateway between

devices and cloud

• LoRaWAN – device identity and key management Still work to do in order to provide asset for application to manage

Asset utilization inapplication development

Nature of development in IoT projects

• New development with full stack• Device (mechanics, electronics, embedded SW)

• Connectivity

• Cloud application

New domain allows asset usage

• Retrofitting• New instrumentation to existing system

• Data integration with existing data source

Based on existing domain, LoRa as new comm tech

• Integrating old data source to cloud• Existing local system and local data storage

• Data gathering / connectivity solution

Typically strong domain knowledge, asset less helpful

Sig

nific

ancy

of a

sse

tan

d n

ew

de

ve

lopm

ent

Asset development as continuous process

• Manual snapshots from the baseline

• Correspondlingly manual mergeback

• Not yet solid process

• In practise the applicationprojects do not have space for returning features back

MaintainingAsset Baseline

Snapshot fromthe common code base

Project specificdevelopment

Selection of common features

Merge back to baseline

Example publicapplication references

Ex1: Fault analysis using vibration data

• Time serie analysis from high resolution vibration data• Moveable measurement device with remote connection

• Based on NI cRIO

• Connectivity over 3G/4G through WATSON IOT

• Unique devices – no automated production process

• Service• End user interface for browsing raw data

• Managing measurement events

• Asset utilization• Basic device management

• Very simple fleet management

• Basic data collection

• Plenty of application specific extensions

Ex2: HSY water metering

• Communication solution to existing metering device• LoRa module to push data up to cloud

• LoRa communication either through gateway network

• Service• Simple data storage for history data, basic data management

• Large set of devices: tens of thousands

• WEBUI for monitoring and browsing devices, quality inspection

• Long term history: data archiving system

• Integration with billing system to push metering data

• Asset utilization• Device and fleet management

• Data storage and archieving

• Monitoring data quality (device health and data content) – new feature candidate

In this context …

In health technology

• Security and privacy even more important Anynomous data as far as possible

Focus to applications where data gathering in focus

• Most potential applications which follows ”standard” sensor network

• Two features of LoRa highlighted Low battery consumption

Good range inside building

• No public references

Last words

Summary

Engineering with a difference

• Asset – acceleration of the application development

• LoRa – as one technology among others with itsstrenghts

• Ongoing improvements according to project needs

• Still plenty of open areas, such as support of production and installation process

• Integrating features with other Soikea asset