1 / 53

OSGi-Based Architecture for IoT Gateways

OSGi-Based Architecture for IoT Gateways. 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

sharla
Télécharger la présentation

OSGi-Based Architecture for IoT Gateways

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. mBS OSGi-Based Gateway Middleware mBS SDK Software Development Kit for IoT Solutions mPRM Remote Device Management & Software Provisioning System

  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 Availability of standard services Device abstraction Automation engine Event history and data logging User Interface • 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

  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 etc. SMS 3rd Party (Service) Applications ProSyst mBS OSGi Applications ProSyst mPRM Other Applications Automation Layer Data Collection User and Role Management Device Protocols Management Agent Device Abstraction Layer Device & Software Management System Services Software Repository IoT Backend OSGi Framework Others IoT Gateway

  14. Impact of Java Evolution on OSGi • Java SE Embedded 8 is anideal platform for running OSGi that can scale using introducednew 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 • …

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

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

  28. Abstraction Layer Concepts (HGI Reference) RP7 • 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! Remote Access Middleware RP4 HOME GATEWAY Remote Access Agent App 1 App N … Abstraction Layer RP2 RP1 D1 D2 D3 Dx

  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 Instantiates SDT with their respective device characteristics Any unification effort needs to accommodate the end to end value chain of Smart Home services to gain maximum impact 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 • 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

  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 Events / Web Sockets JSON RPC or REST RP4(s) RP2 JSON Remote Handler RP1 Device Abstraction Layer SPI get, invoke update DAL Adapter get, invoke update Methods Events ProtocolAPI events methods ProtocolImpl RS232/RS485 TCP/IP

  38. Providing Automation Rules and Actions

  39. Automation Manager Architecture 3rd Party Extenders Condition Provider Command Provider Build-in Modules Your Application Conditions 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 Find & Download Manage Monitor Single IoT Gateway Simple, Efficient, Cost-effective Solution Edge Devices

  42. APIs for Application Development OSGi IoT Solution Stack Local Logic (OSGi Apps) Web Apps (HTML5) iOS/Android Apps 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

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

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

  45. IoT Backend Integration

  46. OSGi-Based IoT End-to-End Solution End-User Devices Cloud Services etc. SMS 3rd Party (Service) Applications ProSyst mBS OSGi Applications ProSyst mPRM Other Applications Automation Layer Data Collection User and Role Management Device Protocols Management Agent Device Abstraction Layer Device & Software Management System Services Software Repository IoT Backend OSGi Framework 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 JSON-RPC Java, JMS Groovy REST 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 SW Dependency Management Rmt Diagnostic & Troubleshooting Remote Network Access Backup & Recovery SW Compatibility Management Rule-based Automation Scripting Event/Audit & Data Logging Alert/Alarm Management Core Platform Performance Statistics Security/Access Control mPRM Messaging HTTP(S) Tunnel MQTT TR069 Device Connectivity CoAP OMA DM OMA Download LWM2M XMPP

More Related