FS20 Integration

Peter Wolf, FZI

Bundles and Layers

2

Access Layer Abstraction Layer Integration Layer

org.universAAL.fs20.networkinterce

org.universAAL.fs20.fhz1000pc

org.universAAL.fs20.fs20forosgi

org.universAAL.fs20.fs20foruaal

One bundle combines functionality of both layers. It could be seperated into two bundles if needed.

I put the network interfaces into a different bundle, so that different implementations for different FS20 network access devices can be pluged in.

There are several different devices to connect to a FS20 network. The FHZ1000PCManager is one of those. Other devices need different implementations.

Uses configuration information to register one osgi-service for each device in the network.

3

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.

Uses the configuration data provided by the confAdmin to

register one FS20Actuator or one FS20Sensor Osgi service

for each device in the network.

The confAdmin delivers configuration information as strings. These configuration objects can be build from such a string to simplify access to the config information.

The builder objects can be used to create a config string.

FS20Sensor or FS20Actuator objects are registered as OSGi services. Implementing classes are not included in diagramm.

Abstraction / Integration Layer

4

Blue means taken from uAAL middleware.

Green means taken from Access Layer.

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.

Method calls to actuators are translated into fs20 commands.

Methods are called when sensor events occur.

turnedOn and turnedOff calls are translated into context events are published on context bus.

Is a ServiceCallee. Registers as a PowerPlugService providing turnOff and turnOn functionality. Incoming

service calls are translated into fs20 commands. The service class for

the power plug actuator service.

Convenient interfaces for Abstraction Layer and uAAL integration.

Sequence Diagram

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

5

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.

6

Open Issues

Publishing of context events does not work. Is it a bug?

7

I get the system.out.println(), but no log from the bus.

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?

8

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

9

For Questions please contact wolf@fzi.de

10