1. OSGi-Based Architecture for IoT Gateways

2. About the Presenter Dr. Dimitar Valtchev – CTO of ProSyst Software
Responsible for the development of embedded middleware and management software at ProSyst for 15 years
Been involved in numerous residential, automotive and industrial engineering projects using the OSGi technology
Participating in standardization activities like those driven by OSGi Alliance and Home Gateway Initiative. Deputy Chair of Smart Home Task Force at Home Gateway Initiative

3. About ProSyst
A software vendor offering middleware and management solution for the Internet of Things. 
We are focused on open standards and open and neutral software platforms for service providers and device manufacturers to deploy applications and services.
OSGi-Based Gateway Middleware
Software Development Kit for IoT Solutions
Remote Device Management & Software Provisioning System
mBS
mBS SDK
mPRM

4. Agenda Gateway centric IoT solutions OSGi runtime for IoT gateways
General architecture
Resource management
Realization of device abstraction
Providing automation rules and actions
OSGi gateways as a service delivery platform
Interaction of the OSGi runtime with IoT integration and management systems

5. Gateway centric IoT architecture

6. Gateway Centric IoT

7. What is an IoT Gateway?
Provides connectivity to the edge devices when they can not be directly connected to Internet
Runs local logic (from simple logic for data collection, filtering and propagation, to complex automation and application logic)
Is manageable

8. Advantages of Using Gateways in IoT
Facilitates the support of heterogeneous protocols for connecting edge devices
Enables the realization of local automation and application logic
Provides autonomy of the solution when needed
Decreases the latency and allows real-time behavior
Allows optimization of the data traffic by applying local data analysis, optimization algorithms and analytics
Improved resource sharing and security

9. Gateway SW Requirements
Support of (heterogeneous) device protocols
Ability to run application logic
Remote management
Modularity
Life cycle management of the SW
Dependency management
Dynamical behavior
Application isolation
Resource management
Availability of standard services
Device abstraction
Automation engine
Event history and data logging
User Interface

10. OSGi based runtime for IoT gateways

11. OSGi - Modular System for Java

12. OSGi Specification Work
OSGi specifies a horizontal service platform which has a wide acceptance in many areas from enterprise to embedded
It defines a set of important and very convenient system services such as user admin, configuration admin, log service, etc.
Recently there was a major progress in the work on IoT relevant services such as Resource Management and Device Abstraction

13. OSGi-Based IoT End-to-End Solution
End-User Devices
Cloud Services
SMS
etc.
3rd Party
(Service)
Applications
ProSyst mBS
OSGi Applications
ProSyst mPRM
Other
Applications
Automation Layer
Data Collection
User and Role Management
Device Protocols
Device Abstraction Layer
Management
Agent
System Services
Device & Software Management
OSGi Framework
Software Repository
IoT Backend
Others
IoT Gateway

14. Impact of Java Evolution on OSGi
Java SE Embedded 8 is an ideal platform for running OSGi that can scale using introduced new concept called, Compact Profiles, which enable reduced memory footprint for applications that do not require the entire Java SE Embedded 8 platform. Currently three profiles are defined.
Integrated script engines like Nashorn (lightweight high-performance JavaScript runtime in Java 8) allows easily development of an automation engine conditions, rules and commands using script languages.

15. Java ME Embedded 8
Not enough to run OSGi but a perfect platform for edge devices. Two options for integration in IoT:
Connected directly to the backend
Connected to the OSGi gateway (reason being security, authentication, automation, data aggregation, control
Java ME 8 is much more powerful then the older Java ME versions keeping the resource usage low
Java ME 8 is fully manageable and recently ProSyst added support for it in its backend system (a management agent of only 30kB)

16. ProSyst‘s IoT Runtime (mBS)
mBS has a lot of non-functional characteristics which are crucial for building reliable solutions!
A low-footprint OSGi-Based IoT Gateway implementation
Enhanced runtime robustness and reliability
Intelligent, extensible native watchdog agent
Support for many JVMs and OS
SDK and tooling available … 16

17. Resource Management

18. Application Isolation
Why is it important in OSGi?
Must be implemented efficiently
Possible solutions
Multiple JVM instances
Java Security in OSGi
Multiple class loaders
Resource management

19. Requirements to Resource Management
Identify critical system resources
Define usage limits (quota)
Track resource creation, destruction
e.g. memory, CPU usage, network sockets, threads, disk space
Act on information available
Objective: Prevent system stall

20. Corrective and Preventive Actions
Warning threshold
Notification mechanism
Corrective
Stop or uninstall the bundles
Kill/disable the associated threads
Forcefully free the taken resources

21. Resource Usage Limits - CPU

22. Resource Usage Limits - Sockets

23. OSGi RFC 200 – Resource Monitoring
Entities:
ResorceMonitoring Service
ResourceContext
ResourceContextListener
ResourceListener
ResourceMonitor
ResourceMonitorFactory

24. OSGi RFC 200 – Resource Monitoring
Specifies:
API for explicit thread mapping
API for configuration
Notifications
Does not specify:
The method for determining the resource ownership
A resource configuration format (policy file)
Actions

25. Connectivity to the edge devices and abstracting the device interface

26. Connecting to Edge Devices OSGi Middleware/Stack
Local Logic & (Web) Apps
OSGi
Gateway
APIs (Java & JSON-RPC / local and remote)
Automation Manager
(Scenes, Rules, Conditions)
Data Collection (Event History)
DLNA / UPnP
Device Abstraction (Devices, Zones)
Security
Remote Management
SW+FW Update
Connected
Devices
EnOcean
IP Cams
ZigBee
Z-Wave
DECT ULE
wMBus
UPnP
BT LE
Managed
Devices

27. IoT Protocol Example: Smart Home
proprietary
non-proprietary
IP-Device(s)
(Discovery)
Wired Protocols
Wireless Protocols
IEEE
mDNS
Bonjour
IEEE 802.3
IEEE
EHS/Konnex
non-IP-based
IP-based
IPv6-capable
IPv4-capable

28. Abstraction Layer Concepts (HGI Reference)
HOME GATEWAY D1 D2 D3 Dx
Abstraction Layer
RP2
Remote Access Agent
App 1
App N …
RP4
Remote Access Middleware
RP7
RP1
RP1 – Abstraction Layer Interface
The local interface that applications on the gateway use
RP2 – Device Driver Interface
The interface to integrate HAN technologies
RP4 – Remote Interface
The interface between an operator cloud platform and the gateway
RP7 – Cloud API
The interface provided to third parties from the operator cloud platform
OSGi deals with RP1!

29. Working together …
HAN technology owners
and vendors
Edit and align a SDT
Liaise SDT to domain specific organizations
Joint work on SDT
Map ontology template to OSGi technology
Jointly approaching domain specific organizations (verticals)
Application and platform
developers
Operators
OEMs and vendors
Semiconductors
Any unification effort needs to accommodate the end to end value chain of Smart Home services to gain maximum impact
Instantiates SDT with their respective device characteristics
Joint work on SDT
Map SDTto BBF TRs (if needed)
Jointly approaching domain specific organizations (verticals)
Instantiates SDT with their respective device characteristics
Joint work on SDT
Map SDT to specific technologies:
ETSI M2M REST APIs
EEBus APIs
Jointly approaching domain specific organizations (verticals)
Application and platform
Developers
OEMs and vendors
Operators
OEMs and vendors
Semiconductors
Application and platform
Developers
OEMs and vendors
This figure is not at all comprehensive; it only shows a possible starting point.

30. Basic functions of a Device Abstraction API
Discovery: Notification mechanism when adding or removing smart appliances
Control and query: Set and retrieve state values of appliances
Eventing: Notification mechanism upon change of state values
Management: Inclusion/exclusion of appliances, key management, firmware upgrades etc.

31. OSGi RFC 196 – DAL
API applicable for all relevant device protocols
General device data model
Device operations
Access control based on user and application permissions
Fine-grained security control
Full flexibility of OSGi security model
A notification mechanism is needed for:
Device state monitoring
Device data model monitoring
Device operations monitoring

32. Device Abstraction Layer – Entities – Device
org.osgi.service.dal.Device
Represents the device in the OSGi service registry
It’s possible to map a few OSGi device services to one physical device
Provides an access to rich set of device properties: status, name, description, types, model, firmware version and vendor, hardware version and vendor, etc.
A set of functions can be assigned to the device
There can be a relationship between the devices

33. Device Abstraction Layer – Online Device Status
Device online status – indicates that the device is currently available for operation. Possible transitions from and to that status are:

34. Device Abstraction Layer – Entities – Function
org.osgi.service.dal.Function
Represent a specific device functionality in the OSGi service registry like MultiLevelSwitch, BooleanSensor, etc.
Can provide a set of properties with:
Access type – eventable, writable and readable
Additional metadata – description, min and max value, measurement unit, etc.
Can provide a set of operations with:
Metadata – description, parameters/return value min and max, parameters/return value measurement unit, etc.
Can be clarified with version, reference functions, type and description

35. Device Abstraction Layer – Function Property
Function property metadata:
access type – represents the access to the function property
eventable – the property value is reported with an event
writable – the property value can be changed
readable – the property value can be read
unit – represents the value unit
min and/or max value – the property value cannot cross a given minimum or maximum value
description – human readable description
values – contains a set of predefined values, which can be assigned to the property
resolution – difference between two values in series

36. Device Abstraction Layer – Function Operation
Function Operation metadata:
parameters – they are using the same metadata as Function property from the previous slide
return value – it’s using the same metadata as Function property from the previous slide
description – human-readable operation description

37. Practical Realization of Device Abstraction
JSON RPC or REST
Events / Web Sockets
RP4(s)
JSON Remote Handler
RP1
Device Abstraction Layer
SPI
RP2
get, invoke
update
DAL Adapter
get, invoke
update
Methods
Events
Protocol API
methods
events
ProtocolImpl
TCP/IP
RS232/RS485

38. Providing Automation Rules and Actions

39. Automation Manager Architecture
3rd Party Extenders
Condition Provider
Command Provider
Build-in Modules
Conditions
Your Application
Commands
Scene Command
Rule
Automation Manager
Event Admin

40. Using OSGi Gateways as a service delivery platform

41. Enabling the Open Ecosystem
Develop
ISVs /
Developers
Publish Apps
App
Store
SDK & Dev
Program
Run
Apps
Distribute
OSGi IoT
Gateway
Many Edge Devices
Many Services
Many Apps
Single IoT Gateway
Simple, Efficient, Cost-effective Solution
Find &
Download
Manage
Monitor
Edge Devices 41

42. APIs for Application Development
OSGi IoT Solution Stack
Local Logic (OSGi Apps)
iOS/Android Apps
Web Apps (HTML5)
APIs (Java & REST for local host, local network and remote access)
Automation Manager
(Scenes, Rules & Conditions for Automation)
Data Collection
(Local Event History and Data Logging)
Device Abstraction Layer
(Devices: Actions, Properties and Zones; User-specific Rights Management)
Security
TLS / X.509
Remote Management
Backend Agent
Software Update
Remote and Local
Diagnostics
Monitoring
EnOcean
IP Cams
. . .
ZigBee
Z-Wave
DECT ULE
wMBus
. . .
UPnP
BT LE 42

43. REST API for Generic Service Access Applications & System Services
IoT User Interfaces
Web & Native Apps
Local
Network
(HTTP)
Internet
(HTTPS)
ProSyst mBS
Gateway
Connection
Tunneling
ProSyst mPRM
REST API for Generic Service Access
Secure
Always-on
Connection
Applications & System Services
OSGi Framework
IoT Gateway

44. OSGi-based HomeKit Bridge Accessory Device Abstraction Layer (DAL)
Apple
iCloud
ProSyst mBS
iCloud
Sync
HAP
Pairing & Security
Bonjour
Discovery
HAP
Device
Events
HAP REST API
Device Protocols
Apple iOS
Device
Local
Network)
Device Abstraction Layer (DAL)
HAP-DAL
Device
Bridge
OSGi HTTP Server
OSGi Framework
etc.
IoT Gateway

45. IoT Backend Integration

46. OSGi-Based IoT End-to-End Solution
End-User Devices
Cloud Services
SMS
etc.
3rd Party
(Service)
Applications
ProSyst mBS
OSGi Applications
ProSyst mPRM
Other
Applications
Automation Layer
Data Collection
User and Role Management
Device Protocols
Device Abstraction Layer
Management
Agent
System Services
Device & Software Management
OSGi Framework
Software Repository
IoT Backend
Others
IoT Gateway

47. Remote Device Management

48. Application Provisioning

49. Infrastructure and Services For Backend IoT Apps

50. ProSyst’s IoT Backend Building Blocks
mPRM API
REST
JSON-RPC
Java, JMS
Groovy
M2M Platform
Device Management
Software Management
Device Inventory
Software/Content Repository
Device Data Collection
Remote Configuration
Application & Lifecycle Management
Real-time Readings
Historical Data
Device Monitoring
Firmware & Application Update
Remote Device Control
Rmt Diagnostic & Troubleshooting
SW Dependency Management
Remote Network Access
Backup & Recovery
SW Compatibility Management
Rule-based Automation
Scripting
Core Platform
Alert/Alarm Management
Event/Audit & Data Logging
Security/Access Control
Performance Statistics
mPRM Messaging
MQTT
TR069
HTTP(S) Tunnel
Device Connectivity
CoAP
OMA DM
OMA Download
LWM2M
XMPP

51. Summary
An architecture based on the usage of IoT gateways is the best approach in a significant number of IoT use cases
Java and OSGi are perfectly suitable to be used as a software runtime in IoT gateways and do not have serious alternatives currently
The software stack of IoT gateways must be designed from the very beginning by taking into account the requirements for interaction with the backend
ProSyst offers a very complete and mature commercial solution for IoT based on OSGi which includes a powerful backed system

52. More Information For more information on our company: www.prosyst.com
For an evaluation of our Cloud IoT Platform:
cloud.prosyst.com
For an evaluation of our gateway and backend stack:
dz.prosyst.com

53. Thank You! Dr. Dimitar Valtchev CTO, ProSyst + 49 221 6604-501