OSGi and Echelon’s OSGi ProductsOSGi and Echelon’s OSGi Products…in more technical depth Inside an OSGi Gateway Hardware Platform independent, as long as there are sufficient memory (RAM and flash) enough CPU cycles …to run the service bundles inside the OSGi Framework inside the JVM (Java Virtual Machine) on top of the underlying operating system Drivers Drivers When using the LONWORKS NAB with a custom (integrated) NSI interface, a native operating system and custom Java driver are required Operating System Operating system doesn’t matter as long as it supports a JVM and javax.comm native OS driver Typical examples are QNX Neutrino Microkernel RTOS Wind River Systems VxWorks Linus Torvald’s Linux Windows (for development and possibly some deployments) JVM Sun’s version 1.2 or higher or compatibles from other companies OSGi Framework Version 1.0 released May 2000 Sun’s JES 2.0 is based on OSGi Framework v1.0 Version 1.1 is under development OSGi Framework Why is the OSGi Framework written in Java? Platform independence Dynamic code loading ability Java security model Object model allows a function’s interface to be separate from its implementation OSGi Framework Terms Service The Java classes that perform certain functionality, usually written with interface and its implementation separated Bundle The functional and deployment unit for shipping service(s) OSGi Framework Terms A bundle gets downloaded from the service center and then activated The bundle may register (“publish”) one or more services to the Framework Services may be published and unpublished under control of the bundle over time OSGi Framework Required Services HTTP Service Allows a service to register a servlet with the web server so that dynamic web pages may be generated by the service Log Service Allows information, error and debug messages to be written to a log Device Manager Service Listens for new Device services and attaches drivers on top of devices OSGi System Architecture Operator aggregates services from one or more providers Operator hosts various servers to provide their value-added services OSGi System Architecture User plugs in new device OSGi System Architecture Appropriate device bundle and services are automatically loaded into the services gateway What Happens Behind The Scenes LONWORKS Network Access Bundle (NAB) is downloaded into the Framework from the service center if necessary NAB is started NAB publishes lonworks service to the Framework Homeowner plugs in the new oven Oven sends a service pin message (automatically or under user control) What Happens Behind The Scenes NAB detects the new device and identifies its type based on its program ID Commissions device into the user’s system local network using the remote LNS Server Automatically informs service operator that the new device has been added so that the operator can take whatever additional steps, if any, are needed to start the service from its perspective (e.g., create a billing record) via LNS event mechanism Registers a new Device service to represent the oven by registering a LwDevice instance (which implements the Device interface) What Happens Behind The Scenes What Happens Behind The Scenes Each DriverLocator tries to find a match, which may include contacting a remote bundle repository to ask it to provide matching Driver IDs LwDriverLocator matches based on the device’s program ID For each match provided, the Device Manager Checks to see if the corresponding Driver service has already been registered If not, the Device Manager loads, installs, and starts the bundle An oven monitoring and status service could then interact with the LONMARK services published for each of the LONMARK objects in the oven The oven monitoring and status service may be in contact with the service center, or may produce live web pages that the homeowner would use to monitor or conf