Kalimucho Research Project, OW2con11, Nov 24-25, Paris

Kalimucho - OW2 annual conference 1
KALIMUCHO1
Marc Dalmau, Philippe Roose
IUT of Bayonne
LIUPPA / University of Pau - France
• Paris
• Bayonne
1 Kalitatea means « Quality » in Basque language, Mucho means « a lot » en Spanish language

Objectives of Kalimucho
• Kalimucho is a platform that allows development of applications distributed on several
kind of devices:
• PC
• Smartphones
• Tablets
• Sensors
• …
• Application are made of components
• The components of these applications exchange flows of data
• Components can be added/removed/migrated while the application is running:
• On users requests
• Because of context changes (mobility …)
• According to available resources (network, energy, CPU, memory …)

Why a platform ?
• Classical solutions:
• Embedded = ad hoc application (=> can be heavy)
• Self or no adaptation
• Our solution:
• Components of the application are downloaded when needed and removed
when not yet used (=> light and evolutive)
• Components can be created / stopped / moved at any time without stopping
the running application
• Communications between components are transparent to the designer:
they send / receive data and the platform decides from/to where

Applications
• Made of services
• (an application = a set of services)
• Services are assemblies of components
• (a service = an assembly of components with connectors)
• Components are simple
• (a component = a function)
• Dynamic deployment and reconfiguration of applications
• Add a new user / Remove a user
• Add/Remove a service
• Modify the constitution of a service
• Dynamic adaptation of the application
• To the context
• To the users
• To the usage

Application model
• Distributed components linked by connectors
• A component has 0 to N inputs
• A component has 0 or 1 output that can be duplicated

Example of application
• An organism taking care of environment sends an agent
(with a smartphone) to the scene of an environmental
accident
1. At his arrival he films the scene he and sends the video (in streaming mode)
to the organism's center.
2. The center wants this video to be sent to an expert who is not actually in the
center but has a smartphone.
3. The expert decides that it is necessary to get pictures in order to constitute a
file. These pictures will be sent simultaneously to the him and to the center.
4. In order to complete the information in the file the center wants these pictures
to be tagged by their GPS position.
5. Etc .

Scene
Center
Act #1: Arriving on the scene
• Video captured by the agent’s smartphone is sent to the center
Kalimucho
Kalimucho
Video capture
Video display
Deployment :
Commands executed by the platforms
Agent : CreateComponent video application.video.VideoAcquisition [null] [vid]
Agent : CreateConnector vid internal Center
Center : CreateComponent videodisplay application.videodisplay.VideoDisplay [vid] [null]

Act #2: The expert
• Video is now received by the expert
Kalimucho
Kalimucho
Video capture
Kalimucho
Center
Scene Expert
Center : SendComponent videodisplay Expert
Video display
Kalimucho
Scene
Center
Scene

Act #3: Taking pictures
• Video is replaced by pictures
Kalimucho
Kalimucho
Video capture
Video display
Kalimucho
Centre
Scene
Expert
Agent : RemoveComponent video
Expert : RemoveComponent videodisplay
Expert : RemoveConnector vid

Kalimucho
Centre
Pictures display
Kalimucho
Expert
Act #3: Taking pictures
• Video is replaced by pictures
Kalimucho
Picture capture
Scene
Agent : RemoveComponent video
Expert : RemoveComponent videodisplay
Expert : RemoveConnector vid
Agent : CreateComponent pictures application.camera.PictureAcquisition [null] [tocenter]
Center : CreateConnector tocenter Agent internal
Center : CreateComponent picturesdisplay application.camera.PictureDisplay [tocenter not_used] [null]
Expert : CreateComponent picturesdisplay application.images.PictureDisplay [toexpert not_used] [null]
Agent : CreateConnector toexpert internal Expert
Agent : DuplicateOutputComponent photo toexpert
Pictures display

Act #4: Adding GPS tags
• Pictures sent to center are tagged by their GPS position
Kalimucho
Kalimucho
Picture capture
Picture display
Kalimucho
Centre
Scene
Expert
Picture display
GPS capture
Agent : CreateComponent position application.GPS.GPSAcquisition [null] [tag]
Agent : CreateConnector tag internal Center
Center: ReconnectInputComponent picturesdisplay 1 tag

Unpredictable context changes
• In this example all the decisions were taken because of utility
• but ..
• If, when sending the video to the expert, the platform detects that the
quality is bad (network throughput too low). It can decide by itself to send
pictures rather than video: the video capture and video display
components will be replaced by a picture capture and a picture display
component.
• Later, if the expert moves and get a better reception, the platform can
choose to come back to the video mode as initially.
• ….

Center
How the platform works
• Video captured by the agent’s smartphone is sent to the center
Kalimucho
Kalimucho
Video capture
Video display
Scene
Deployment :
Agent : CreateComponent video application.video.VideoAcquisition [null] [vid]
Agent : CreateConnector vid internal Center
Center : CreateComponent videodisplay application.videodisplay.VideoDisplay [vid] [null]

What happens ?
1. The platform on the agent’s smatphone receives the command:
• CreateComponent video application.video.VideoAcquisition [null] [vid]
1. It sends a broadcast message in order to find a platform holding the code of the video capture
component
2. One of the platforms sends it this code (it manages a repository of components)
Kalimucho
Kalimucho
Looking forVideoAcquisition
LookingforVideoAcquisition
Looking forVideoAcquisitionKalimucho
Code forVideoAcquisition
Code repository

What happens ?
1. The platform on the agent’s smatphone goes on executing the command:
• CreateComponent video application.video.VideoAcquisition [null] [vid]
3. The platform on the agent’s smatphone download and installs this component then it waits until its
input and output connections are established (here there is only an output)
Kalimucho
KalimuchoVideo capture

What happens ?
2. The platform on the agent’s smatphone receives the command:
• CreateConnector vid internal Center
1. It looks for a route to the Center
Kalimucho
Kalimucho
Ping message
Video capture

What happens ?
2. If this route is direct, the Center replies to the PING message
Kalimucho
Kalimucho
Ping reply
Video capture

What happens ?
3. The platform on the agent’s smatphone sends to the platform on the Center a command in order to
create a connector
Kalimucho
Kalimucho
Create connector
Video capture

What happens ?
4. The connector is created as output of the component of video capture
Kalimucho
Kalimucho
connector
Video capture

What happens ?
2. If there is no route to the Center there is no reply to the PING message
Kalimucho
Kalimucho
Ping message
Video capture X
No reply

What happens ?
3. The platform on the agent’s smatphone try to find a relay (broadcast message)
Kalimucho
Kalimucho
Find Center
Video capture
FindCenter
Find Center
Kalimucho

What happens ?
4. Each device tries to reach the Center by a PING message
Kalimucho
PING message
Kalimucho

What happens ?
5. Some devices gets a reply from the Center
Kalimucho
PING reply
Kalimucho

What happens ?
6. These devices indicates to the smatphone that they can act as a relay
Kalimucho
Can do relay to Center
Kalimucho

What happens ?
7. The platform on the agent’s smatphone choose one of these devices and send it a command in
order to create a connector with it
Kalimucho
Create connector
Kalimucho

What happens ?
8. The device creayes the connector and sends to the Center a command in order to create the other
part of this connector
Kalimucho
Create a connector
Kalimucho

What happens ?
CreateConnector vid internal Center
9. The connector is created as output of the component
Kalimucho
Kalimucho

What happens ?
3. The platform on the Center receives the command:
• CreateComponent affichagevideo application.videodisplay.VideoDisplay
[vid] [null]
1. The platform on the Center create the component (as seen) and link it to the established connection
• The application can run
Kalimucho
Kalimucho
connector
Video capture
Video Displsy

Act #2: The expert
Kalimucho
Kalimucho
Video capture
Kalimucho
Center
scene Expert
Center : SendComponent videodisplay Expert
Video display
Kalimucho

1. The platform on the Center receives the command:
• SendComponent videodisplay Expert
1. It stops the video capture component
2. It gets its state
3. It looks for a route to reach the expert’s smatphone (Expert)
4. It sends to the platform on the Expert a migration command including the state of the
component (serialization)
Kalimucho
KalimuchoSerialized component
Kalimucho
Video display
Component is stopped
Video captureVideo capture

3. The platform on the Center goes on executing the command:
• SendComponent videodisplay Expert
5. The Center remove the component and its code
6. The Expert broadcast message in order to find a platform holding the code of this
component (excepted if it already has it)
7. One of the platforms sends it this code (from a repository)
8. The Expert installs this component, set it in the state it had on the Center and waits for
its connections to be established
Kalimucho
Kalimucho
Kalimucho
Component is removed
Video display
Video capture

• SendComponent affichagevideo Expert
9. The Center sends a command to the Agent in order it redirects the connector by witch it
sends the video to go to the Expert
Kalimucho
Kalimucho
Kalimucho
Video display
Video capture
Redirect connector to Expert

• SendComponent affichagevideo Expert
10. The platform on the agent’s smartphone find a route to the expert’s smartphone (as seen)
11. The Expert now has its connections and can run the component
• The video is now reveived by the expert’s smatphone
Kalimucho
Kalimucho
Kalimucho
Video display
Video capture

Command language
• Components
• CreateComponent name class [input1 input2 …] [output1 output2 …]
• Input and/or Output lists can be empty: [null]
• An input can be marked as "not_used" to be used later
• RemoveComponent name
• SendComponent name to
• DisconnectInputComponent name number
• ReconnectInputComponent name number new_input
• DuplicateOutputComponent name new_output

Command language
• Connectors
• CreateConnector name from to
• from and to can be "internal"
• RemoveConnector name
• RedirectInputOfConnector name to
• RedirectOutputOfConnector name to
• Context
• ReadState
• ReadContainerState name
• ReadQoS name
• name is the name of a component or a connector

Platform Architecture
Decision
Hardware infrastructure
Local part of the application
Others Platforms DecisionDecision
Supervision Context capture
Reconfigurations States and Events
States and EventsThe Decision
module is not yet
implemented (work
in progress)

Prototype Platform Architecture
Hardware infrastructure
Local part of application
Others Platforms Decision
Supervision Context capture
Reconfigurations States and Events
States and EventsTest Module
Configurations
file

Platform Kernel
Supervisor
Services
Register
Network Communication Independent
Layer
Network Communication Dependent
Layer
Plugins
Manager
Class
Manager
Context
Manager
Host Context
Sensors
Component
Container
Connector
Container
Plugins
Hardware
Access
services for
Applications
Route Finder
Code Loader
DNS
Plugins
configuration file
Repository
Manager

Platform Kernel
• Network
Supervisor
Services
Register
Layer
Layer
Plugins
Manager
Class
Manager
Context
Manager
Host Context
Sensors
Component
Container
Connector
Container
Plugins
Hardware
Access
services for
Applications
Route Finder
Code Loader
DNS
Plugins
configuration file
Repository
Manager

Platform Kernel
• Network
• Command execution
Supervisor
Services
Register
Layer
Layer
Plugins
Manager
Class
Manager
Context
Manager
Host Context
Sensors
Component
Container
Connector
Container
Plugins
Hardware
Access
services for
Applications
Route Finder
Code Loader
DNS
Plugins
configuration file
Repository
Manager

Platform Kernel
• Network
• Context management
Supervisor
Services
Register
Layer
Layer
Plugins
Manager
Class
Manager
Context
Manager
Host Context
Sensors
Component
Container
Connector
Container
Plugins
Hardware
Access
services for
Applications
Route Finder
Code Loader
DNS
Plugins
configuration file
Repository
Manager

Platform Kernel
• Network
• Code management
Supervisor
Services
Register
Layer
Layer
Plugins
Manager
Class
Manager
Context
Manager
Host Context
Sensors
Component
Container
Connector
Container
Plugins
Hardware
Access
services for
Applications
Route Finder
Code Loader
DNS
Plugins
configuration file
Repository
Manager

Platform Kernel
• Network
• Code management
• Services for applications
Supervisor
Services
Register
Layer
Layer
Plugins
Manager
Class
Manager
Context
Manager
Host Context
Sensors
Component
Container
Connector
Container
Plugins
Hardware
Access
services for
Applications
Route Finder
Code Loader
DNS
Plugins
configuration file
Repository
Manager

Platform Kernel
• Network
• Code management
• Services for applications
• Services management
Supervisor
Services
Register
Layer
Layer
Plugins
Manager
Class
Manager
Context
Manager
Host Context
Sensors
Component
Container
Connector
Container
Plugins
Hardware
Access
services for
Applications
Route Finder
Code Loader
DNS
Plugins
configuration file
Repository
Manager

Context serveillance
• The context manager:
• Controls the hardware
• CPU load
• Memory free
• Battery level
• Controls the network
• Platform traffic
• Application traffic
• Controls the BCs
• State (live cycle)
• Level of QoS
• The platform:
• Get states from the context manager
• Receives alarms from the context manager
for:
• Low levels (quality downgrade)
• Up levels (quality upgrade)
• Receives context information from others
platforms

Application model (components)
• The Business Component (BC) is encapsulated into a container
(Osagaia)
• The container
• Manages the life cycle of the BC (CU)
• Control the state of the BC (CU)
• Allows platform supervision (CU)
• Offers input and output accesses (IUs, Listeners manager and OU)
• Send states and alarms to the platform (CU)
BC Container
Connector
Input stream Output stream
Duplicated
Input
Unit
(I U) Output
Unit
(OU)
Business
Component
(BC)
Control Unit
(CU)
Supervision States and Alarms
Connector
Input stream
Input
Unit
(I U)
.... .... ....
Connector
Connector
....Listeners
Manager

Application model (connectors)
• The data flow is encapsulated into a container (Korrontea)
• Allows data transfer politics (BC)
• Ensure no lost of data (Buffers)
• Allows platform supervision (CU)
• Control the data flow (IU and OU)
• Internal connector
• Links two BCs in the same host
Input
stream
Output
stream
Input
Unit
(I U)
Output
Unit
(OU)Control Unit
(CU)
BC
Connector
buffer buffer

• Distributed connector
• Links two BCs in two hosts with a direct network connection
Client
Thread
Server
Thread
network
Host A Host B
Input
stream
Output
stream
Input
Unit
(I U)
Output
Unit
(OU)Control Unit
(CU)
BC
Connector
buffer buffer
Input
stream
Output
stream
Input
Unit
(I U)
Output
Unit
(OU)Control Unit
(CU)
BC
Connector
buffer buffer

• Distributed connector with relay
• Links two BCs in two hosts with no direct network connection
Client
Thread
Server
Thread
network
Host A Host B
Client
Thread
Server
Thread
network
Host C
Input
stream
Output
stream
Input
Unit
(I U)
Output
Unit
(OU)Control Unit
(CU)
BC
Connector
buffer buffer
Input
stream
Output
stream
Input
Unit
(I U)
Output
Unit
(OU)Control Unit
(CU)
BC
Connector
buffer buffer
Input
stream
Output
stream
Input
Unit
(I U)
Output
Unit
(OU)Control Unit
(CU)
BC
Connector
buffer buffer
The two networks may be different (for exampleWifi and 3G)

Developing applications
• Only BCs and classes of exchanged data are to be developed
• BC inherits from an abstract class (BCModel)
• Life cycle is controlled by:
• init executed only the first time (not after a migration)
• destroy executed when stopped (either before a migration)
• run_BC BC activity
• Inputs can be read by
• Direct blocking method
• Listeners
• Output is written by
• Direct method

Developing applications
• Kalimucho offers services to the BCs for:
• Resources access (resources loaded with the code)
• User interface definition and management (on Android)
• Hardware access (GPS, SMS, GoogleMaps, sensors, camera)
• Sending commands to a local or a distant platform and receiving replies
• BCs exchange data of user defined classes
• Data classes inherits from a Kalimucho’s class (Sample)
• Data classes code availability is managed by the platform
• Data is time stamped when created and the date is adjusted to local time
when received (DNS)

Example: The BC for GPS acquisition
public void destroy() throws StopBCException, InterruptedException {
localGPS.stopGPS(); // stop the GPS for this BC
}
public float levelStateQoS() {
return 0.9f; // actual QoS of this BC
}
}
public class GPSAcquisition extends BCModel {
private static final long serialVersionUID = 64240010100000001L;
private transient GPSAccess localGPS; // not sent by migration
private double latitude, longitude, altitude; // sent by migration
public void init() throws StopBCException, InterruptedException {}
public void run_BC() throws StopBCException, InterruptedException {
localGPS =
(GPSAccess)ServicesRegister.waitForService("GPS_ACCESS");
localGPS.startGPS(); // start the GPS for this BC
while (isRunning()) {
Location loc = localGPS.getGPSLocation();
latitude = loc.getLatitude();
longitude = loc.getLongitude();
altitude = loc.getAltitude();
writeSample(new GPSCoordinates(latitude, longitude, altitude));
Thread.sleep(10000); // send location every 10s
}
}

Exchanged data: the class GPSCoordinates
public class GPSCoordinates extends Sample {
private static final long serialVersionUID = 64240010100000001L;
private double latitude, longitude, altitude;
public GPSCoordinates() {
latitude = 0;
longitude = 0;
altitude = 0;
}
public GPSCoordinates(double lat, double longt, double alt) {
latitude = lat;
longitude = longt;
altitude = alt;
}
public double getLatitude() { return latitude; }
public double getLongitude() { return longitude; }
public double getAltitude() { return altitude; }
}

Platform performance
• Size of the platforms
• On PC: 366 KB
• On Android: 356 KB
• Command execution time (on an Android Nexus One)
• Create a component: 2 to 20 ms
• Remove a component: 15 ms to the time for the component to stop (limited to 1
second)
• Create an internal connector: 3 to 15 ms
• Create a distributed connector: 10 to 100 ms
• Remove an internal connector: 3 to 15 ms
• Remove a distributed connector: 3 to 25 ms
• Disconnect/reconnect an input: 2 to 7 ms
• Duplicate an output: 2 to 7 ms

Platform performance
• Total migration time for a component with one input connector
and one output connector
Migration time
0
100
200
300
400
500
0 5 10 15 20 25
Test #
ms
Average value: 311 ms
Standard deviation: 100

Conclusion
• Kalimucho is now available on OW2 forge
• http://forge.ow2.org/projects/kalimucho/
• Work in progress:
• User oriented heuristic of decision (simulation with Labview - PhD 2006)
• Heuristic of deployment (simulation with java - PhD 2010)
• PhD student working on Context evaluation and decision taking

KALIMUCHO
• dalmau@iutbayonne.univ-pau.fr
THANKYOU

Kalimucho Research Project, OW2con11, Nov 24-25, Paris

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (20)

Similar a Kalimucho Research Project, OW2con11, Nov 24-25, Paris

Similar a Kalimucho Research Project, OW2con11, Nov 24-25, Paris (20)

Más de OW2

Más de OW2 (20)

Último

Último (20)

Kalimucho Research Project, OW2con11, Nov 24-25, Paris