osgi-based architecture for iot gateways. about the presenter dr. dimitar valtchev – cto of...
TRANSCRIPT
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
1. Gateway centric IoT solutions2. 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
3. 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
IoT Backend
3rd Party
Cloud Services
ProSyst mBS
OSGi Framework
Device Abstraction
Layer
ManagementAgent
Automation Layer
OSGi Applications
(Service)Applications
Software Repository
Device & Software Management
Other Applications
Others
etc.SMS
System Services
IoT Gateway
Device P
roto
cols
ProSyst mPRM
End-User Devices
Data Collection
User and Role Management
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)
1616
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• …
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
• Preventive– 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
• https://github.com/osgi/design/blob/master/rfcs/rfc0200/rfc-0200-ResourceMonitoring.pdf
• 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
OSGiGateway
OSGi Middleware/Stack
EnOcean IP Cams
Device Abstraction (Devices, Zones)
Automation Manager(Scenes, Rules, Conditions)
APIs (Java & JSON-RPC / local and remote)
Security
DLNA / UPnP
ConnectedDevices
ManagedDevices
Local Logic & (Web) Apps
Connecting to Edge Devices
Data Collection (Event History)
Remote Management SW+FW Update
ZigBee Z-Wave
DECT ULE wMBus UPnP BT LE
IEEE 802.3 IEEE 802.11
IEEE 802.15.4
Bonjour
Wired Protocols Wireless Protocols
IP-Device(s)(Discovery)
IoT Protocol Example: Smart Home
EHS/Konnex
proprietary non-proprietary
non-IP-based IP-based
IPv6-capableIPv4-capable
mDNS
Abstraction Layer Concepts (HGI Reference)
• 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!
HOME GATEWAY
D1 D2 D3 Dx
Abstraction Layer
RP2
Remote Access Agent
App 1 App N…
RP4
Remote Access
Middleware
RP7
RP1
Working together …
Joint work on SDTMap SDTto BBF TRs (if needed)Jointly approaching domain specific organizations (verticals)
Joint work on SDTMap ontology template to OSGi technologyJointly approaching domain specific organizations (verticals)
Instantiates SDT with their respective device characteristics
Joint work on SDTMap SDT to specific technologies:• ETSI M2M REST APIs• EEBus APIsJointly approaching domain specific organizations (verticals)
Edit and align a SDTLiaise SDT to domain specific organizations
Instantiates SDT with their respective device characteristics
This figure is not at all comprehensive; it only shows a possible starting point.
Any unification effort needs to accommodate the end to end value
chain of Smart Home services to gain maximum impact
Application and platformdevelopers
OperatorsOEMs and vendorsSemiconductors
OperatorsOEMs and vendorsSemiconductors
HAN technology ownersand vendors
Application and platformDevelopersOEMs and vendors
Application and platformDevelopersOEMs and vendors
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
● https://github.com/osgi/design/tree/master/rfcs/rfc0196● 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
OSGi RFC 196 – DAL
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 AbstractionJSON RPC or REST Events / Web Sockets
JSON Remote Handler
Device Abstraction Layer
SPI
DAL Adapter
Protocol API
Methods Events
ProtocolImpl
events
update
updateget, invoke
get, invoke
methods
TCP/IP RS232/RS485
RP4(s)
RP2
RP1
38
Providing Automation Rules and Actions
39
Automation Manager Architecture
Automation Manager Event Admin
Condition Provider
Command Provider
3rd Party Extenders
Build-in Modules
Conditions Commands
RuleScene
Command
Your Application
40
Using OSGi Gateways as a service delivery platform
41
Enabling the Open Ecosystem
OSGi IoTGateway
AppStore
ISVs /Developers
Publish Apps
Distribute
Find &Download
SDK & DevProgram
Develop
RunApps
Manage
Monitor
Edge Devices
Many Edge Devices
Many Services
Many Apps
Single IoT Gateway
Simple, Efficient, Cost-effective Solution
Single IoT Gateway
Simple, Efficient, Cost-effective Solution
42
OSGi IoT Solution Stack
EnOcean IP Cams
Device Abstraction Layer (Devices: Actions, Properties and Zones; User-specific Rights Management)
Automation Manager(Scenes, Rules & Conditions for Automation)
APIs (Java & REST for local host, local network and remote access)
SecurityTLS / X.509
Local Logic (OSGi Apps)
Data Collection (Local Event History and Data Logging)
Remote ManagementBackend Agent
Software UpdateRemote and Local
ZigBee Z-Wave
DECT ULE wMBus UPnP BT LE
iOS/Android Apps Web Apps (HTML5)
DiagnosticsMonitoring
. . .
. . .
APIs for Application Development
43
GatewayConnectionTunneling
ProSyst mPRM
IoT User Interfaces
IoT Gateway
OSGi Framework
Applications & System Services
REST API for Generic Service Access
ProSyst mBS
Web & Native Apps
LocalNetwork(HTTP)
SecureAlways-onConnection
Internet(HTTPS)
44
ProSyst mBS
OSGi Framework
Device Abstraction Layer (DAL)
BonjourDiscovery
etc. IoT Gateway
Device P
roto
cols
OSGi-based HomeKit Bridge Accessory
HAPPairing & Security
HAP REST API
OSGi HTTP Server
HAPDeviceEvents
HAP-DALDeviceBridge
Apple iOSDevice
LocalNetwork)
AppleiCloud
iCloudSync
45
IoT Backend Integration
46
OSGi-Based IoT End-to-End Solution
IoT Backend
3rd Party
Cloud Services
ProSyst mBS
OSGi Framework
Device Abstraction
Layer
ManagementAgent
Automation Layer
OSGi Applications
(Service)Applications
Software Repository
Device & Software Management
Other Applications
Others
etc.SMS
System Services
IoT Gateway
Device P
roto
cols
ProSyst mPRM
End-User Devices
Data Collection
User and Role Management
Remote Device Management
Application Provisioning
Infrastructure and Services For Backend IoT Apps
ProSyst’s IoT Backend Building BlocksmPRM API
M2M Platform Device Management Software Management
REST JSON-RPC Java, JMS Groovy
Co
re P
latf
orm
De
vic
e
Co
nn
ec
tiv
ity
Rule-based Automation
Alert/Alarm Management
Security/Access Control
Scripting
Event/Audit & Data Logging
Performance Statistics
Remote Network Access
Remote Device Control
Backup & Recovery SW Compatibility Management
SW Dependency Management
Firmware & Application Update
Application & Lifecycle Management
Software/Content Repository
Rmt Diagnostic & Troubleshooting
Device Monitoring
Remote Configuration
Device Inventory
Device Data Collection
Real-time Readings
Historical Data
mPRM Messaging
MQTT
CoAP
LWM2M
XMPP
TR069
OMA DM
HTTP(S) Tunnel
OMA Download
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
