1 / 10

FS20 Integration

FS20 Integration. Peter Wolf, FZI. Bundles and Layers. Access Layer. Integration Layer. Abstraction Layer. I put the network interfaces into a different bundle, so that different implementations for different FS20 network access devices can be pluged in. org.universAAL.fs20.networkinterce.

enya
Download Presentation

FS20 Integration

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. FS20 Integration Peter Wolf, FZI

  2. Bundles and Layers Access Layer Integration Layer Abstraction Layer I put the network interfaces into a different bundle, so that different implementations for different FS20 network access devices can be pluged in. org.universAAL.fs20.networkinterce org.universAAL.fs20.fs20foruaal There are several different devices to connect to a FS20 network. The FHZ1000PCManager is one of those. Other devices need different implementations. org.universAAL.fs20.fhz1000pc One bundle combines functionality of both layers. It could be seperated into two bundles if needed. org.universAAL.fs20.fs20forosgi Uses configuration information to register one osgi-service for each device in the network.

  3. The confAdmin delivers configuration information as strings. These configuration objects can be build from such a string to simplify access to the config information. FS20Sensor or FS20Actuator objects are registered as OSGi services. Implementing classes are not included in diagramm. The builder objects can be used to create a config string. Uses the configuration data provided by the confAdmin to register one FS20Actuator or one FS20Sensor Osgi service for each device in the network. Light-blue means taken from OSGi. Provides the implementation for the fhz1000pcmanager device. This is the device that can access the network. FS20NetworkGate is registered as OSGi service. This one service represents the gateway to the fs20 network.

  4. Uses the registerd actuators and instantiates the convenient interfaces for different actuator types. Uses the registerd sensors and instantiates the convenient listener interfaces for different sensors types. Abstraction / Integration Layer Convenient interfaces for Abstraction Layer and uAAL integration. Green means taken from Access Layer. Methods are called when sensor events occur. Method calls to actuators are translated into fs20 commands. Is a ServiceCallee. Registers as a PowerPlugService providing turnOff and turnOn functionality. Incoming service calls are translated into fs20 commands. turnedOn and turnedOff calls are translated into context events are published on context bus. The service class for the power plug actuator service. Blue means taken from uAAL middleware.

  5. Sequence Diagram If it is needed, I could generate one. But it would take some while.

  6. Configuration Configuration is handled by the ConfigurationAdmin from OSGi The FS20NetworkDriver is the managed service It does receive the configuration of the whole network as a string (see updated method and Dictionary object) The key for that string is FS20NetworkConfiguration.FS20_NETWORK_CONFIG The format for the string looks currently like this: „device_id_1:[generic _device_type _1, specific_device_type_1] ;device_id_2:[generic _device_type _2, specific_device_type_2];…“ "111122221111:[actuator,power_plug_actuator];442212421111:[sensor,power_plug_sensor];„ For more information on the configuration, please have a look at the test bundle. It uses the Builder classes to create one configuration corresponding to my test environment here at FZI.

  7. Open Issues I getthesystem.out.println(), but no log fromthebus. Publishing of context events does not work. Is it a bug?

  8. Open Issues III Registration of semantic uAAL services The current design would require the registration of one semantic service for each actuator device Is this possible? Do I then need one service class for each service? Alvaro, Saied, Vadim (or whoever thinks he can help), can you please have a look at the PowerPlugService class and the PowerPlugActuatorImpl and provide feedback?

  9. Open Issues IV • No bundle has been mavenized so far • Not tested thoroughly; tests will be done when we start using it at FZI • Does currently not comply to Device Access Specification of OSGi, but I tried to design it in a way that makes later adaptation possible • FHZ1000PCManager implementation is a bit buggy. • Every now and then an exception occurs • If device is not connected an exception occurs and bundle is not started • FS20 is an unreliable protocol, sometimes messages might not be received properly and there is no sophisticated mechanism to deal with this

  10. For Questions please contact wolf@fzi.de

More Related