Your SlideShare is downloading. ×
Update OSGi Residential Expert Group
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Update OSGi Residential Expert Group

368
views

Published on

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
368
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. OSGi Alliance Residential Expert GroupCurrent ActivitiesDecember 6, 2012OSGi Users‘-Forum Germany Meeting, Cologne COPYRIGHT © 2009-2010 OSGi Alliance. All Rights Reserved
  • 2. OSGi Alliance Technical Process• Requirements are documented in a Request for Proposal (RFP) • Application Domain • Problem Description • Use Cases • Requirements• Once the RFP is completed there will be a voting in the Requirements Committee• If approved, the EG will work on solution that is documented in Request for Comments (RFC)• The RFC will be the base for the actual specification• Each specification comes with a reference implementation and test cases Page 2 COPYRIGHT © 2009-2010 OSGi Alliance. All Rights Reserved 09.12.12
  • 3. Current Activities• Requirements Collection for the new specification • RFP 142 – ZigBee API (completed and approved) • RFP 147 – Device Abstraction Layer • RFP 149 – USB DeviceCategory • RFP 153 – Resource Monitoring and Management • RFP 154 – Network Interface Information Service Page 3 COPYRIGHT © 2009-2010 OSGi Alliance. All Rights Reserved 09.12.12
  • 4. RFP 142 ZigBee APIPage 4 COPYRIGHT © 2009-2010 OSGi Alliance. All Rights Reserved
  • 5. RFP 142 – ZigBee API• Problem Description • OSGi Applications communicating with ZigBee devices are supposed to call the API of the driver provided by the vendor. This API is vendor proprietary and causes the following problems: • Application developers need to know which vendors ZigBee hardware is used with the target residential gateway in advance before developing their applications • An application which was developed for a certain environment may not work in other environments.• Use Cases • ZigBee Device Control by locally installed OSGi applications • ZigBee Device Control through USB Dongle • ZigBee Device Control through standard ZigBee Device Gateways • ZigBee Gateway with IP networks • Network Refreshment Page 5 COPYRIGHT © 2009-2010 OSGi Alliance. All Rights Reserved 09.12.12
  • 6. RFP 149 USB DeviceCategoryPage 6 COPYRIGHT © 2009-2010 OSGi Alliance. All Rights Reserved
  • 7. RFP 149 – USB DeviceCategory• Problem Description • The Device Access Specification declares that the device category for specific devices must be defined outside of itself. The lack of device category for USB devices causes the following problems: • The developer of a refining driver bundle, which registers a Driver service at its activation, cannot design and implement Driver#attach(ServiceReference) method without knowledge of service properties set to the Device service registered by an USB base driver • The developer of a refining driver bundle, which registers a Driver service at its activation, cannot design and implement Driver#match(ServiceReference) method without knowledge of service properties set to the Device service registered by an USB base driver and without the definition of match values to be returned.• Use Case • Attaching ZigBee USB Dongle to a Home Gateway Page 7 COPYRIGHT © 2009-2010 OSGi Alliance. All Rights Reserved 09.12.12
  • 8. RFP 153Resource Monitoring and ManagementPage 8 COPYRIGHT © 2009-2010 OSGi Alliance. All Rights Reserved
  • 9. RFP 153 – Resource Monitoring and Management (1)• Problem Description • OSGi defines no standardized mechanism to detect and react on failures, shortage of resources and misbehaving services or bundles. A flexible framework is needed that allows dynamic provisioning of modules to: • Collect Information about the normal, intended states of the monitored entities • Monitor arbritary resources and ask services for their health status • Evaluate the serverity of deviations of the currently monitored state from intended state • Take Decisions and perform actions to recover the intended state • Control/monitor the success of the actions taken Page 9 COPYRIGHT © 2009-2010 OSGi Alliance. All Rights Reserved 09.12.12
  • 10. RFP 153 – Resource Monitoring and Management (2)• Use Cases • A management entity wants to be notified if the overall framework consumption of a certain resource reaches a defined level, e.g. memory or threads. • A bundle defines its needs in terms of a special resource (e.g. availability of certain TCP/IP ports) and wants to be notified, as soon as those resources become available. • An accounting component wants to monitor consumption of resources for a bundle (or a set of bundles) as base for billing towards the bundle vendor. • A management entity defines maximum allowed resources for a certain bundle (or set of bundles) and wants to be notified if the limits are exceeded. It then invokes a special interface on the bundle to allow a “self-healing”. The success of this “therapy” itself is monitored and if necessary the cycle starts again. • A premium service should have higher priority when resources are distributed than best- effort-services. • A bundle defines its resource requirements for normal operation and wants to be notified, if those ranges are exceeded, because this indicates some potential error conditions that the bundle needs to be aware of and could handle. • Sets of bundles that make up one application are handled together, i.e. one bundle acts on behalf of all bundles belonging to the application. Page 10 COPYRIGHT © 2009-2010 OSGi Alliance. All Rights Reserved 09.12.12
  • 11. RFP 154 Network Interface Information ServicePage 11 COPYRIGHT © 2009-2010 OSGi Alliance. All Rights Reserved
  • 12. Network Interface Information Service• Problem Description • Obtaining IP network information can be done via standard Java APIs, however • There is no function which sends a notification when the information of network interface (i.e. IP address) changed during runtime • There is no function which can obtain the subnet mask of the network interface. • Bundles need to implement Operating System specific features to obtain IP network information• Use Case 1 • The TR-069 protocol adapter bundle needs to communicate with an Auto Configuration Server (ACS). The ACS needs to know IP address of the Residential Gateway to send UDP packet to protocol adapter bundle for connection request. In this case, the bundle has to send the IP address to ACS when the bundle is started or the IP address is changed.• Use Case 2 • When Http Service bundle is available, at least, one http server is probably run. In case that the http server needs to be assigned to the specific network interface, Http Service bundle has to know the information of network interface. In addition, Http Service bundle needs to know changing IP address of the network interface to manage http servers. Page 12 COPYRIGHT © 2009-2010 OSGi Alliance. All Rights Reserved 09.12.12
  • 13. OSGi Device Abstraction Layer RFP 147 Entry Point to All DevicesPage 13 COPYRIGHT © 2009-2010 OSGi Alliance. All Rights Reserved
  • 14. Device Abstraction Layer – Covers All Device Protocols• API applicable for all relevant device protocols • General device data model • Access to common device properties • Access to the device states • Access to device meta info • Device operations • Management operations • Data operations Page 14 COPYRIGHT © 2009-2010 OSGi Alliance. All Rights Reserved 09.12.12
  • 15. Device Abstraction Layer – Protocol Independent 1/3• API solving common problems with device access • Avoiding protocol specific behavior • Avoiding application workarounds • Avoiding custom device abstractions • Avoiding uncontrolled dependencies Page 15 COPYRIGHT © 2009-2010 OSGi Alliance. All Rights Reserved 09.12.12
  • 16. Device Abstraction Layer – Protocol Independent 2/3Without DAL:Complex implementations, multiple dependencies Page 16 COPYRIGHT © 2009-2010 OSGi Alliance. All Rights Reserved 09.12.12
  • 17. Device Abstraction Layer – Protocol Independent 3/3 Introducing Device Abstraction Layer: Single point of contact, giving protocol independence Page 17 COPYRIGHT © 2009-2010 OSGi Alliance. All Rights Reserved 09.12.12
  • 18. Device Abstraction Layer – Security• Access control based on user and application permissions • Fine-grained security control • Full flexibility of OSGi security model• Security features available in the device protocols Page 18 COPYRIGHT © 2009-2010 OSGi Alliance. All Rights Reserved 09.12.12
  • 19. Device Abstraction Layer – Notification• A notification mechanism is needed for: • Device state monitoring • Device data model monitoring • Device operations monitoring Page 19 COPYRIGHT © 2009-2010 OSGi Alliance. All Rights Reserved 09.12.12
  • 20. Device Abstraction Layer – Extension• Extension points for new protocols • Dynamic extension points • Protocol independent • Available at runtime Page 20 COPYRIGHT © 2009-2010 OSGi Alliance. All Rights Reserved 09.12.12
  • 21. REG Time Plan• Completing Requirements Collection by Dec. 2012• RFCs should be ready by Q2 2013• Initial Specifications ready by Q3 2013• Final Specifications ready by Q4 2013• Specification Release Q1 2014 Page 21 COPYRIGHT © 2009-2010 OSGi Alliance. All Rights Reserved 09.12.12