software components developmentrobotics.unibg.it/teaching/srt/pdf/16_distributedcomponents.pdfa...

Embedded Real Time SystemsProf. Davide Brugali

Università degli Studi di Bergamo

Software Components Development

Slides from the course of Real Time Systems by Giusepe Lipari, SSSA

Development time

Development time

Sofware design

We need to see the system at 3 different levels of abstractions:

User level (requests and services)

Functional level (modules and functionality)

Tasks level (concurrent tasks and resources)

Sofware design : user level

Sofware design : functional level

Module specifications

Sofware design : task level

A software component is an independent, executable entity that packages data, functionalities, and tasks in a reusable and composable module.

Software components design

Szyperski:A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third-parties.

Software components

Thread

State

Procedure

Messages

Thread

State

Procedure

Thread

State

Procedure

Messages

A simple control system

10

Mapping control functionality to components

11

Odometry

Trajectory

(x, v)

Twist

Vsx, Vdx

Esx, Edx

ThreadState

Procedure

ThreadState

Procedure

ThreadState

Procedure

Mapping control functionality to components

12

Navigator

Odometry

Trajectory

(x, v)

T1 (1 ms)T2 (20 ms)Twist

TrajectoryPlanning

Vsx, Vdx

Esx, Edx

Rover Driver

Component interfaces

Provides interfaceRequires interface

ComponentDefines the servicesfrom the component’senvironment that ituses

Defines the servicesthat are providedby the componentto other components

Provides interfaceRequires interface

Data collector

addSensorremoveSensorstartSensor

stopSensor

testSensor

listAllreport

initialise

sensorManagement

sensorData

Basic architectural elements

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

component component component

connector connector

interfaces interfaces

• Shared memory• Distributed middleware


Arduino Robot

Robot BART

SONARsensors

Line color sensorRadio module

Motors with

Encoders

Robot BART

Motor shield MD25

MOTOR 1E1

MOTOR 2E2

Speed control

x

y

y

x

OdometryY

OdometryX

Twist

WLWR

V

{V

Software components

RoverDriver

Twist Odometry

Navigator

USB left_encoderright_encoder

left_speedright_speed

Target

Periodic activity T= 100 ms

Periodic activity T= 1000 ms

class RoverDriver

class RoverDriver {

public:

RoverDriver();

void setTwist(long v, long w);

void getOdometry(double &x, double &y, double &t);

// update odometry and regulate wheels speed

void periodicTask();

};

encoder_datamotor_speed

USB

class Navigator

class Navigator {

public:

RoverDriver();

void setTarget(double x, double y, double t);

// get odometry and generate twist to regulate robot position

void periodicTask();

private:

void getTwist(long &v, long &w);

void setOdometry(double x, double y, double t);

};

encoder_datamotor_speed

USB




connector connector




Component-based system

<<component>>Navigator

motor command

<<component>>Rover Driver

Twist

Odometry

Trajectory

encoder data

shared memory

shared memory

Component-based system

RoverDriver

Component

Navigator

Component

TwistOdometry

Shared Memoryread

readwrite

write

Main Process

Thread Thread

Main processpthread_mutex_t mutexOnSharedResource; //Mutex declarationRoverDriver rover;Navigator navigator;Twist shared_twist; Shared variables to be protected Odometry shared_odometry;

int main (int argc, char *argv[]){ // Set the Target and init the shared variables navigator.setTarget(100, 230, 180); //[cm] [cm] [gradi] shared_twist.linear = 0; shared_twist.angular = 0;

// Init mutex ...

// Thread variables pthread_t driver_thread; pthread_t navigator_thread;

// Create and start the threads pthread_create(driver_thread, driverTask, NULL); pthread_create(navigator_thread, navigatorTask, NULL)}

Rover Driver Taskvoid *driverTask(void *null) { double v, w; double ox, oy, ot;

while(alive){ rover.getOdometry(ox, oy, ot) // read USB

pthread_mutex_lock (&mutexOnSharedResource);shared_odometry.x = ox; // write shared memoryshared_odometry.y = oy;shared_odometry.t = ot;

v = shared_twist.linear; // read shared memoryw = shared_twist.angular; pthread_mutex_unlock (&mutexOnSharedResource);

rover.setTwist(v, w); // write USBsleep(100);

}

pthread_exit((void *) 0);}

Navigator Taskvoid *navigatorTask(void *null) { double v, w, px, py, pt;

while(alive){ navigator.getTwist(v, w);

pthread_mutex_lock (&mutexOnSharedResource); shared_twist.linear = v; // write shared memory

shared_twist.angular = w;px = shared_odometry.x; // read shared memorypy = shared_odometry.y;pt = shared_odometry.t;pthread_mutex_unlock (&mutexOnSharedResource);

navigator.setOdometry(px, py, pt);

sleep(1000); } pthread_exit((void *) 0);}

Distributed Component-based System

RoverDriver

Task

TwistOdometry

Network

Main Process Main Process

Middleware

Middleware

Navigator

Task

Distributed Component-based System

UNIBG - Robotica - Brugali30

RoverDriver

TwistOdometry

Network

Main Process Main Process

Middleware

Middleware

Twist

OdometryNavigat

or

TaskTask




connector connector




Distributed middlewares

33

Distributed ApplicationsDistributed Applications

Operating System CommsOperating System Comms

NetworkNetwork

Distributed Middlewares• What is Middleware?

• Layer between OS and distributed applications• Hides complexity and heterogeneity of distributed system • Bridges gap between low-level OS communications and

programming language abstractions• Provides common programming abstraction and

infrastructure for distributed applications

Distributed Applications

Middleware

Operating System Comms

(packets, bits…)

(remote calls, object invocation, messages, …)

(sockets, IP, TCP, UDP, …)

Network

Types of middlewares

• Remote Procedure Call (RPC)• Historic interest

• Object-Oriented Middleware (OOM)• Java RMI• CORBA• Reflective Middleware

• Message-Oriented Middleware (MOM)• Java Message Service• IBM MQSeries• Web Services

• Event-Based Middleware• Cambridge Event Architecture• Hermes

research

research

Remote Procedure Call (RPC)• Masks remote function calls as being local

• Client/server model

• Request/reply paradigm• Marshalling of function parameters and return value

Caller RPC Service RPC Service RemoteFunction

call(…)

1) Marshal args2) Generate ID3) Start timer 4) Unmarshal

5) Record ID

6) Marshal7) Set timer

8) Unmarshal9) Acknowledge

fun(…)

message

Properties of RPC

Language-level pattern of function call• easy to understand for programmer

Synchronous request/reply interaction• natural from a programming language point-of-

view• matches replies to requests• built in synchronisation of requests and replies

Distribution transparency (in the no-failure case)

• hides the complexity of a distributed system

Disadvantages of RPC Synchronous request/reply interaction

• tight coupling between client and server• client may block for a long time if server loaded leads to multi-threaded programming at client• slow/failed clients may delay servers when

replying • multi-threading essential at servers

Distribution Transparency• Not possible to mask all problems

RPC paradigm is not object-oriented• invoke functions on servers as opposed to methods on objects

fork(…)

join(…)

remote call

Message passing paradigm• Another approach is to exchange data through a

message passing paradigm:• Every task operates on a private memory space;• Data are exchanged by messages through a channel.

Distributed Component-based Systems

Client Server

PublisherSubscriber

SS

SS

Global Data Space

Request

Reply

Invoke Service or FunctionCORBA

DDS

Subscriber

S sample

Span of Middleware Technologies for DRE Systems

Soft Real-time (Display and

decision support)

Non-real-time (Business Systems)

Hard Real-time (sensor and

actuator control)

Extreme Real-time (signal processing)

MicroSoft .NET

Java / RMI

CORBA (GPP)

Message Passing Interface (MPI )

Market Share

OMG Data Distribution Service (DDS)

Source: OACE Tech. & Stds. Sept. 2003

RT CORBA (DSP) RT CORBA (FPGA)

Data Distribution Service (DDS)

Platform Independent

DomainParticipantPublisher

DataWriter

Subscriber

DataReader

DDS-DCPS Entities

• DomainParticipant ~ Represents participation of the application in the communication collective

• DataWriter ~ Accessor to write typed data on a particular Topic

• Publisher ~ Aggregation of DataWriter objects. Responsible for disseminating information.

• DataReader ~ Accessor to read typed data regarding a specific Topic

• Subscriber ~ Aggregation of DataReader objects. Responsible for receiving information

Topic

Topic

• Topics can be defined as Singleton or can have multiple Instances• Topic Instances are identified by means of the topic key • A Topic Key is identified by a tuple of attributes -- like in databases• Remarks:

• A Singleton topic has a single domain-wide instance• A “regular” Topic can have as many instances as the number of different key values, e.g., if

the key is an 8-bit character then the topic can have 256 different instances

QoS: Durability

Topic

Publisher

Domain Participant

DataWriter

# saved in Transient affected by QoS: History and QoS: Resource_Limits

Publisher

Domain Participant

DataWriter

LocalMemory

Durability = Transient

Durability = Volatile

Durability Kind:VOLATILE – No Instance History SavedTRANSIENT – History Saved in Local MemoryPERSISTENT – History Saved in Permanent storage

Perm.Storage

Durability = Persistent

Durability determines if/how instances of a topic are saved.

QoS: Reliability

DataWriter

R

BEST_EFFORT• Sample delivery is

not guaranteed

TopicBE

DataReader

BE

SubscriberPublisher

DataWriter

BE

Publisher

TopicR

DataReader

R

SS S S

Missed samples

S7 S5S6 S4 S3S2 S1

RELIABLE• Sample delivery is guaranteed

S7

S5S6

S4S3S2S1

history

QoS Contract “Request / Offered”

QoS Request / Offered: Ensure that the compatible QoS parameters are set.

Topic

DataWriter

Publisher

QoS:DurabilityQoS:PresentationQoS:DeadlineQoS:Latency_BudgetQoS:OwnershipQoS:LivelinessQoS:Reliability

OfferedQoS

Topic

DataReader

Subscriber

RequestedQoS

X

QoS not compatible

Communication not established

DDS example

Simple control system based on DDS

subscriberpublisher

Data Distribution Service

Operating System

odometry

Publisher Componentint main (int argc, char* argv[]) {

dds::domain::DomainParticipant dp =

dds::domain::DomainParticipant(org::opensplice::domain::default_id());

dds::topic::qos::TopicQos topicQos = dp.default_topic_qos()

<< dds::core::policy::Durability::Transient() << dds::core::policy::Reliability::Reliable();

dds::topic::Topic<star::nav_msgs::Odometry> topic(dp, "RoverOdometry", topicQos);

dds::pub::qos::PublisherQos pubQos = dp.default_publisher_qos()

<< dds::core::policy::Partition("Tutorial");

dds::pub::Publisher pub(dp, pubQos);

dds::pub::qos::DataWriterQos dwqos = topic.qos()

<< dds::core::policy::WriterDataLifecycle::ManuallyDisposeUnregisteredInstances();

dds::pub::DataWriter<star::nav_msgs::Odometry> dw(pub, topic, dwqos);

while(1) {

star::nav_msgs::Odometry odometry; odometry = ….

dw << odometry;

sleep(1000);

}

}













while(1) {


dw << odometry;

sleep(1000);

}

}

Durability::Transient policy

This policy guarantees that, even if the subscriber does not join until after the sample is written then the DDS will still retain the sample for it.

Reliability::Reliable

This policy is specified to guarantee delivery.













while(1) {


dw << odometry;

sleep(1000);

}

}

WriterDataLifecycle::ManuallyDisposeUnregisteredInstances

This policy guarantees that the publisher can optionally be run (andexit) before the subscriber. It prevents the middleware default 'clean up' ofthe topic instance after the writer deletion. This deletion implicitly performsDataWriter::unregister_instance

Subscriber Componentint main (int argc, char* argv[]) {




<< dds::core::policy::Durability::Transient() <<dds::core::policy::Reliability::Reliable();


dds::sub::qos::SubscriberQos subQos = dp.default_subscriber_qos()


dds::sub::Subscriber sub(dp, subQos);

dds::sub::qos::DataReaderQos drqos = topic.qos();

dds::sub::DataReader<star::nav_msgs::Odometry> dr(pub, topic, drqos);

star::nav_msgs::Odometry odometry;

while(1) {

dds::sub::LoanedSamples<star::nav_msgs::Odometry> samples = dr.take()

for (dds::sub::LoanedSamples<star::nav_msgs::Odometry>::const_iterator

odometry = samples.begin(); odometry < samples.end(); ++odometry)

}

}

More QoS parameters

54

DCPS Subscription Objects (MultiTopic)

DataReader

Domain Participant

Topic Topic Topic Topic

Subscriber

Domain Participant

SubscriberSubscriber

DataReader

DataReader Data

ReaderListener

(optional)

MultiTopics can combine, filter and rearrange data from multiple topics

** Listeners Wait-Set or conditions available

MultiTopic

Optional

QoS: History: Last x or All

DataWriter

Keep All

KEEP_LAST: “depth” integer for the number of samples to keep at any one time

DataReaderKeep all

Publisher Subscriber

Topic

S5S7 S2S4 S1

KEEP_ALL:Publisher: keep all until deliveredSubscriber: keep each sample until the application processes that instance

S7

S5S6

S4S3S2S1

S7

S5S6

S4S3 Data

ReaderKeepLast4

Subscriber

S7

S5S6

S4

S3S6

DataWriter

KeepLast 2

Publisher

S7S6

Topic

S7 S6 S5 S4 S3

QoS: Deadline

Topic

Publisher

DataWriter

Subscriber

DataReader

DEADLINE “deadline period”

deadline

Commits to provide data each deadline period. Expects data every

deadline period.

S X S S S S S

Listener

Failed to get data

QoS: Liveliness – Type, Duration

Domain Participant

DataWriter

Topic

Publisher

LP S LP LP

lease_duration

X

DataReader

Subscriber

Listener

Liveliness Message

Domain Participant

Type:AUTOMATIC = Infrastructure ManagedMANUAL = Application Managed

Failed to

renew lease

QoS: Time_Based_Filter

Domain Participant

DataWriter

Topic

Publisher

SS S S S

minimum separation

DataReader

Subscriber

Data Samples

“minimum_separation”: Data Reader does not want to receive data faster than the min_separation time

SS

Discardedsamples

QoS: Ownership

DataWriter

Ownership = EXCLUSIVE• Only highest-strength data writer can update data-instance

DataWriter

DataWriter

Ownership = SHARED• All data-writers can update data-instance

Ownership: Specifies whether more than one Data Writer can update the same instance of a data-object

Data-Instance

DataWriter

DataWriter

DataWriter

Data-Instance

QoS: Ownership_Strength

DataWriter

OWNERSHIP_STRENGTH• Integer to specify the strength of an instance

Topic

DataReader

Subscriber

Domain Participant

Publisher

DataWriter

Publisher

S=1 S=4 S=4

Note: Only applies to Topics with Ownership=Exclusive

Ownership Strength: Specifies which writer is allowed to update the values of data-objects

QoS: Destination_Order

DataWriter

BY_RECEPTION_TIMESTAMP• Order is determined by the DR timestamp

DataReader

PublisherSubscriberSource TS

Topic

T2S4 S2S3 S1

BY_SOURCE_TIMESTAMP• Consistent order for delivery is guaranteed

S7

S5S6

S4S3S2S1

history

S4

S3T3

T2S2T1S1 Data

Reader

SubscriberRec TS S4

T2T3

S3T1S2S1

T1T3

Order of updates as received by subscribers

DataWriter

PublisherT7

T5T6

T4T3T2T1

history

S3S4 T1T2 S1S2T3Absolute order of writes

QoS: Latency_Budget

Physical I/F

Transport

DDS

Application

Publication

t1

t2

Physical I/F

Transport

DDS

Application

Subscription

t3

Latency = t1 + t2 + t3

• Intended to provide time-critical information to the publisher for framework tuning where possible.

• Will not prevent data transmission and receipt.

QoS: Resource_Limits• Specifies the resources that the Service can consume to

meet requested QoS

Domain Participant

Topic

123

12

4

123

DataReader

Subscriber

max_samples: max # data samples for a single DW or DR, across all instances

max_instances: max # instances for a single DW or DR

max_samples_per_instance: max # data samples per instance

……

QoS: USER_DATA

Entity:

Domain Participant (user_data)DataReader (user_data)DataWriter (user_data)

DDS Node

ignore_participant()ignore_publication()ignore_subscription()ignore_topic()

User data can be used to authenticate an origination entity.

Remote Application

Authenticate Origin

DDS Node

Accept Entities

yes

no

Note: USER_DATA is contained within the DDS metadata.

Definition: User-defined portion of Topic metadata

Example: Security Authentication

Domains and Partitions

DDS Domain

QoS: Partition

Domain Participant

TopicA

TopicB

SubscriberPublisher

DataWriter

DataWriter

DataReader

DataReader

TopicC

DataWriter

DataReader

PartitionU,W Partition

U,Z

DataReader

Partition: Logical “namespace” for topics

** Partition string namesmust match between publisher and subscriber

Subscriber

PartitionX,Y

QoS: Quality of Service

QoS Policy Concerns Changeable

USER_DATA DP,DR,DW NO

DURABILITY T,DR,DW NO

PRESENTATION P,S NO

DEADLINE T,DR,DW YES

LATENCY_BUDGET T,DR,DW YES

OWNERSHIP T NO

OWNERSHIP_STRENGTH DW YES

LIVELINESS T,DR,DW NO

TIME_BASED_FILTER DR YES

PARTITION P,S YES

RELIABILITY T,DR,DW NO

TRANSPORT_PRIORITY T,DW YES

DESTINATION_ORDER T,DR NO

HISTORY T,DR,DW NO

RESOURCE_LIMITS T,DR,DW NO

software components developmentrobotics.unibg.it/teaching/srt/pdf/16_distributedcomponents.pdfa...

Documents