Virtual Wiring

Virtual Wiring

Prototypes

In this section, we introduce part of our prototypes to demostrate and clarify the virtual wiring concept. In current prototypes ZeroC Ice a object oriented middleware. Virtual wiring and many others applications have been built using IcePick framework.

The universal switch

The universal switch is a virtual wiring based device for switching
on/off every appliances on a distributed system.

Hardware

The following figure shows the components of the switch:


Inside the universal switch

  • Platform: Crossbow MICA2 mote (model IRIS-XM2110)
  • Processor: Atmel ATmega128L
  • Radio interface
  • Powered by 2 AA batteries
  • Simple switch connected to the mote

Software

As application example, we assume the following requirements:

  • The switch should be configurable at run time.
  • The switch may be deactivated, that is, the change on the switch state does not affect to any object.
  • The switch should be easly integrated in the system. We will use ASDF, a service discovery infrastructure.

As we have mentioned, the application inside the switch has been built using IcePick framework. Following interface definition (in Slice language) defines the interface of the switch (Device::Switch):

[code]
#include

module Device { interface Switch extends DUO::IBool::R, DUO::Active::W {};
};
[/code]

This interface extends from DUO::IBool::R and from DUO::Active::W, that is, it provides read-only boolean service and is an active object writable, respectively. An active object notifies its state to a callback when it changes. A writable active object let us modifie the callback object at run time dynamically.

With the interface defined, in IcePick Framework, is to define the distributed scenario:

[code]
uses “switch.ice”;
uses “Hesperia/ASDF.ice”;

object DUO.IBool.W cb;

object Device.Switch switch { callback = cb;
};

object ASD.Listener asda { mode = oneway;
};

object DUO.IBool.W service;

local adapter pico { endpoint = “tcp -h 0.0.0.0 -p 2000”; objects = {SW01, “SERV”:service};
};

remote adapter node1 { endpoint = “udp -h 20.0.1.1 -p 9000”; objects = ASDA.publish;
};

remote adapter node2 { endpoint = “tcp”; objects = {”“:cb};
};

boot { switch.set(false, “”); cb.set(switch.get(), switch.oid);
}

timer(60) { asda.adv(switch);
}

change:
event STATECHANGED do { cb.set(switch.get(), switch.oid);
}

when service.set(v) do { change.enable(v);
}
[/code]

Firstly, every needed Slice file has been imported since the interfaces will be used below. In ASDF.ice is defined all interfaces related with service discovery.

Then, the next objects are defined:

  • switch, represents the universal switch.
  • cb, is the callback for the active switch
  • asda, is a remote object where the switch will advertise itself.
  • service, represents the “switching” service provided by the switch.

These objects may be located inside object adapters. In this application, three adapters has been defined:

  • pico, the local adapter, that is, the node that is the target for the programmer. switch and service objects are installed in this adapter.
  • node1 and node2 are remote from viewpoint of programmer. The advertaisment service and the callback are instantiated there, respectively.

The rest of the IcePick code is the behaviour specification using triggers structures. boot trigger is executed at switch initialization time. In this case, at initialization time the switch is configured as off and this state is notified to the configured callback. For advertisment requiremente, a timer is enough. Every 60 ticks, the switch send a adv message to the service (with its own proxy as argument).

The event trigger means when the internal event STATECHANGED takes effect, the following invocations must be executed. In this case, just inform to callback.

The last trigger is used to implement the activation/deactivation service. when a set invocation is received to the service object with the boolean value v, then activate or deactivate the event trigger. Thus, if service.set(false) is received, it will cause change.enable(false), that is, disable the effects of internal event STATECHANGED.

At this point, we have been specified the interfaces used in the distributed system, the relationships between objects and the behaviour of the target node. However, it does not be presented the implementation code, that is, the native code for the virtual machine which implements the methods. In object-oriented distributed programming, it is called servant.

As IcePick programmers, we only need to know the binary interface with the servant. Final servant implementation should be provided by a third party. The binary interface should be provided in SIS language:

[code]
event STATECHANGED;

remote DUO.IBool.R get(15);
remote DUO.IBool.W set(16);

local DUO.IBool.W status(17) { output = bool;
};
[/code]

In this case, the SIS file contains signatures of the interfaces methods between a low level identifier. This information is required by the compiler to stuck binary implementation with IcePick specification.

Using the universal switch

The following video shows how the universal switch works:

No flash plugin? Download the video here.

The scenario is composed by two lamps conected to a PC (fitPC) by using X10 devices. The PC is conected to network using an ethernet interface. In front of the PC the universal switch is placed. To combinate the relationships between lamps and switch the application Twin Panel is used. Twin Panel is a inspector for object oriented middleware-based systems. It provides special views por active objects.

A deeper description of the video is as follows:

1. Initially, both lamps (x10-a01 and x10-m01) are announcing themselves to be located by the system. Twin Panel advertise itself too. We proceed to switch on the universal switch.

2. In a few seconds, it appears in the advertisement channel (as @SW0S) and Twin Panel register it. We procced to inspect it.

3. Initially, Twin Panel is the callback of the switch. For that reason, when the state is changed Twin Panel shows that change.

4. Also, Twin Panel let us view the switch as a pure active object.

5. Using that view, we “associate” ligth x10-a01 to the switch just drag-and-drop on its callback row.

6.We proceed on the same way as before with the other light.

7. Now, we are going to associate both ligths to switch. For do this, we need to create a event channel for the switch. When the state of the switch change an event will be send to this channel. Ligths are subscribed to the created event channel.

8. Twin Panel let us view a set of distributed objects in the same view. We configure it for viewing the switch and both ligths.