Distributed Events, State and Commands

Ope

nSpl

ice

DD

S

Angelo CORSARO, Ph.D.Chief Technology Officer OMG DDS Sig [email protected]

Distributed State,Events and Commands:: with OpenSplice DDS

Page 2: Distributed Events, State and Commands

Ope

nSpl

ice

DD

S

Foundations

Page 3: Distributed Events, State and Commands

Copyrig

ht 2010, PrismTech – A

ll Rights Reserved.

Ope

nSpl

ice

DD

S

Defining a System

¨ A set of interacting or interdependent parts forming an integrated whole

Cyber/Physical.World.

s"mulus&(events/commands)&&

Input& Output&!  State&!  Transi"ons&

System.

Page 4: Distributed Events, State and Commands

Copyrig

ht 2010, PrismTech – A

ll Rights Reserved.

Ope

nSpl

ice

DD

S

Defining a Distributed System

¨ A Distributed System is a System whose parts can only interact by communicating over a network

Cyber/Physical.World.

s"mulus&(events/commands)&&

Input& Output&!  State&!  Transi"ons&

Distributed.System.

Page 5: Distributed Events, State and Commands

Copyrig

ht 2010, PrismTech – A

ll Rights Reserved.

Ope

nSpl

ice

DD

S

State in a Distributed System¨ The State of a distributed system

is the collection of the states of its parts plus the stimulus currently propagating through the system

¨ As Distributed Systems don’t share memory, one problem to address is how to access arbitrary subsets of its state (or of its parts)

¨ The other problem is the consistency of this state...

Cyber/Physical.World.

s"mulus&(events/commands)&&

Input& Output&!  State&!  Transi"ons&

Distributed.System.

Page 6: Distributed Events, State and Commands

Copyrig

ht 2010, PrismTech – A

ll Rights Reserved.

Ope

nSpl

ice

DD

S

Stimulus in a Distributed System

¨ Internal and Environmental Stimuli in a distributed system are used to¨ evolve the system state

(commands, i.e. do something)¨ notify particular condition on the

state (events, i.e. something happened)

Cyber/Physical.World.

s"mulus&(events/commands)&&

Input& Output&!  State&!  Transi"ons&

Distributed.System.

Page 7: Distributed Events, State and Commands

Copyrig

ht 2010, PrismTech – A

ll Rights Reserved.

Ope

nSpl

ice

DD

S

State vs Stimulus

¨ The state of a system is always defined to have a value

¨ A Stimulus only exists at a particular point in time

time

Temp

OverheatAlarm

time

State%

S&mulus%

Copyrig

ht 2010, PrismTech – A

ll Rights Reserved.

Ope

nSpl

ice

DD

S

Are Commands Different?¨ Commands are a kind of stimulus

that express the need for the system to do something

¨ As commands have the “do something” connotation, it is often useful to synchronously be informed that the “command” has been executed

¨ However systems can be built with both synchronous as well as asynchronous commands

Cyber/Phisycal World

System

Do Something

Done

Asynchronous*

Cyber/Phisycal World

System

DoSomething

Done

Synchronous*

Page 9: Distributed Events, State and Commands

Ope

nSpl

ice

DD

S

State Events and Commands in DDS

Page 10: Distributed Events, State and Commands

Ope

nSpl

ice

DD

S State in DDS

Page 11: Distributed Events, State and Commands

Copyrig

ht 2010, PrismTech – A

ll Rights Reserved.

Ope

nSpl

ice

DD

S

Distributed State with DDS¨ The “public” state of the elements making the

distributed system can easily be captured via topic definitions

¨ Representing state with topics is more a matter of discipline w.r.t. to the QoS being used and the way in which it is accessed

Page 12: Distributed Events, State and Commands

Copyrig

ht 2010, PrismTech – A

ll Rights Reserved.

Ope

nSpl

ice

DD

S

State’s DDS QoSTopics representing state should have the following QoS Settings

¨ RELIABILITY = RELIABLE

¨ HISTORY = KEEP_LAST(1)

¨ DURABILITY = (TRANSIENT |PERSISTENT)

¨ OWNERSHIP = EXCLUSIVE

¨ DESTINATION_ORDER = SOURCE_TIMESTAMP

Page 13: Distributed Events, State and Commands

Copyrig

ht 2010, PrismTech – A

ll Rights Reserved.

Ope

nSpl

ice

DD

S

Soft-State’s DDS QoSTopics representing soft-state, meaning state that is periodically updated, should have the following QoS Settings

¨ RELIABILITY = BEST_EFFORT

¨ HISTORY = KEEP_LAST(1)

¨ DURABILITY = VOLATILE

¨ OWNERSHIP = EXCLUSIVE

¨ DESTINATION_ORDER = SOURCE_TIMESTAMP

Page 14: Distributed Events, State and Commands

Copyrig

ht 2010, PrismTech – A

ll Rights Reserved.

Ope

nSpl

ice

DD

S

Accessing State in DDS¨ The DataReader.read operation should be used to

access topics representing state¨ This ensures that the last value for the state will be kept in DDS and will

be readable again and again

¨ The DataReader data should be accessed with the following flags:¨ ANY_SAMPLE_STATE¨ ALIVE_INSTANCE_STATE¨ ANY_VIEW_STATE

Page 15: Distributed Events, State and Commands

Copyrig

ht 2010, PrismTech – A

ll Rights Reserved.

Ope

nSpl

ice

DD

S

Example

¨ A Robot Position in 2D is an example of state

¨ Let’s assume that the Robot only update position when it moves

¨ Topic Type:struct RobotPosition { @key long rid; long x; long y;};

[1/3]

Page 16: Distributed Events, State and Commands

Copyrig

ht 2010, PrismTech – A

ll Rights Reserved.

Ope

nSpl

ice

DD

S

Example¨ The Topic and DataReader would be constructed as

follows// Create Topic Qosval tQos =

TopicQos() <= KeepLastHistory(1) <= Reliable() <= TransientDurability() <= ExclusiveOwnership() <= SourceTimestamp();

// Create Topicval rpt = Topic[RobotPosition](“RobotPosition”,topicQos)

// Create DataReaderval rpdr = DataReader[RobotPosition](rpt, DataReaderQos(tqos))

[2/3]

Page 17: Distributed Events, State and Commands

Copyrig

ht 2010, PrismTech – A

ll Rights Reserved.

Ope

nSpl

ice

DD

S

Example¨ Data can be read as follows

// Read dataval data = rpdr.read(ReadState.AllData) // Or specific to Escalierval data = rpdr.history

[3/3]

Page 18: Distributed Events, State and Commands

Ope

nSpl

ice

DD

S Events in DDS

Page 19: Distributed Events, State and Commands

Copyrig

ht 2010, PrismTech – A

ll Rights Reserved.

Ope

nSpl

ice

DD

S

Distributed Events with DDS¨ Events raised by a distributed system can be easily

captured via topic definitions

¨ Representing events with topics is more a matter of discipline w.r.t. to the QoS being used and the way in which it is accessed

¨ Event topics are often keyless

Page 20: Distributed Events, State and Commands

Copyrig

ht 2010, PrismTech – A

ll Rights Reserved.

Ope

nSpl

ice

DD

S

Events’ DDS QoSEvents should have the following QoS Settings

¨ RELIABILITY = RELIABLE

¨ HISTORY = KEEP_ALL

¨ DURABILITY = VOLATILE

¨ OWNERSHIP = SHARED

¨ DESTINATION_ORDER = SOURCE_TIMESTAMP

Page 21: Distributed Events, State and Commands

Copyrig

ht 2010, PrismTech – A

ll Rights Reserved.

Ope

nSpl

ice

DD

S

Events’ DDS QoSEvents should have the following QoS Settings

¨ RELIABILITY = RELIABLE

¨ HISTORY = KEEP_ALL

¨ DURABILITY = VOLATILE

¨ OWNERSHIP = SHARED

¨ DESTINATION_ORDER = SOURCE_TIMESTAMP

Page 22: Distributed Events, State and Commands

Copyrig

ht 2010, PrismTech – A

ll Rights Reserved.

Ope

nSpl

ice

DD

S

Accessing Events in DDS¨ The DataReader.take operation should be used to

access topics representing events¨ This ensures that the DDS cache is always freed by available events

¨ The DataReader data should be accessed with the following flags:¨ NEW_SAMPLE_STATE¨ ALIVE_INSTANCE_STATE¨ ANY_VIEW_STATE

Page 23: Distributed Events, State and Commands

Copyrig

ht 2010, PrismTech – A

ll Rights Reserved.

Ope

nSpl

ice

DD

S

Example

¨ A CollisionEvent could be raised by a Robot when it is colliding (or about to collide) with something

¨ Topic Type:struct CollisionEvent { long detectingRobotId; long collidingRobotId; long xe; long ye;};

[1/3]

Page 24: Distributed Events, State and Commands

Copyrig

ht 2010, PrismTech – A

ll Rights Reserved.

Ope

nSpl

ice

DD

S

Example¨ The Topic and DataReader would be constructed as

follows// Create Topic Qosval tQos =

TopicQos() <= KeepAll() <= Reliable() <= VolatileDurability() <= SharedOwnership() <= SourceTimestamp();

// Create Topicval cet = Topic[CollisionEvent](“CollisionEvent”,topicQos)

// Create DataReaderval cedr = DataReader[CollisionEvent](cet, DataReaderQos(tqos))

[2/3]

Page 25: Distributed Events, State and Commands

Copyrig

ht 2010, PrismTech – A

ll Rights Reserved.

Ope

nSpl

ice

DD

S

Example¨ Data can be read as follows

// Take dataval data = cedr.take()

[3/3]

Page 26: Distributed Events, State and Commands

Ope

nSpl

ice

DD

S Commands in DDS

Page 27: Distributed Events, State and Commands

Copyrig

ht 2010, PrismTech – A

ll Rights Reserved.

Ope

nSpl

ice

DD

S

Commands in DDS¨ As explained earlier commands are just a kind of

stimulus

¨ As such could be represented as pairs of events one for the “command request” and the other for the “command reply”

¨ However many people like to deal with commands synchronously, this is why OpenSplice provides now an RMI Framework!

Page 28: Distributed Events, State and Commands

Copyrig

ht 2010, PrismTech – A

ll Rights Reserved.

Ope

nSpl

ice

DD

S

OpenSplice RMI¨ Enhances OpenSplice with the ability of defining distributed

Services implementing a well defined service interface

¨ Interfaces are specified in IDL and are fully interoperable with DDS types

¨ Uses DDS mechanism to invoke services

¨ Takes advantage of DDS mechanism for discovery, fault tolerance, one-to-many invocations, etc.

Page 29: Distributed Events, State and Commands

Copyrig

ht 2010, PrismTech – A

ll Rights Reserved.

Ope

nSpl

ice

DD

S

Example¨ Suppose our System is composed

by a set of cooperating Robots that are inspecting some assigned region for surveillance, or detecting chemicals, radioactivity, etc.

¨ DDS RMI gives us a way of defining the set of interfaces that constitute the relevant commands and invoke them as traditional RMI

struct Region { long x0; long y0; long width; long height;};

local interface RobotCommands : ::DDS_RMI::Services { void start(); void stop(); void setSpeed(in long s); long getSpeed(); void setSize(in long s); long getSize(); void setRegion(in Region r); Region getRegion(); string getColor(); string getShape();};

[1/2]

Page 30: Distributed Events, State and Commands

Copyrig

ht 2010, PrismTech – A

ll Rights Reserved.

Ope

nSpl

ice

DD

S

Example

¨ Under the hood, appropriate topics are generated by the infrastructure

¨ QoS can be associated to individual methods via an XML file so to further control the semantics of methods invocation

struct Region { long x0; long y0; long width; long height;};

local interface RobotCommands : ::DDS_RMI::Services { void start(); void stop(); void setSpeed(in long s); long getSpeed(); void setSize(in long s); long getSize(); void setRegion(in Region r); Region getRegion(); string getColor(); string getShape();};

[2/2]