More on RDT - PowerPoint PPT Presentation

More on rdt
1 / 31

  • Uploaded on
  • Presentation posted in: General

More on RDT. Robert John Walters. RDT – a reprise. A Graphically based formal modelling language Models represented as diagrams (not text) Communications inspired by π-calculus Drawn in two parts: Behaviour of components (processes) How they are connected together. RDT Processes.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

Download Presentation

More on RDT

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

More on rdt

More on RDT

Robert John Walters

Rdt a reprise

RDT – a reprise

  • A Graphically based formal modelling language

  • Models represented as diagrams (not text)

  • Communications inspired by π-calculus

  • Drawn in two parts:

    • Behaviour of components (processes)

    • How they are connected together

Rdt processes

RDT Processes

  • Inspired by RADs

  • Have named state

  • Three types of event:

    • Send

    • Receive

    • Create

  • *Processes describe a type of behaviour

Rdt models

RDT Models

  • Process instances labelled with a name and their type

  • Channels (names) known to an instance are shown and labelled

  • Connections between channels shown by lines

  • *Concerned with instances

Why target spin

Why target SPIN?

  • Highly regarded and widely available

  • Input language looks like “C”

  • Direct input of property to be checked

  • Natural correspondence between channels in Promela and RDT



  • Several parts to the operation

    • RDT processes converted to Promela processes

    • RDT model conversion - the “init” process

    • Channel allocations

    • Special consideration of features of RDT

Translation processes 1

Translation: Processes (1)

  • Could have used a single “do” loop with process state stored in a variable

    • State would have to be a number (since there is no string type in Promela)

    • Establishing the extent to which a process is exercised is not straightforward

Translation processes 2

Translation: Processes (2)

  • Each RDT process is converted to a process in Promela

  • Label in Promela for each state of the RDT process

  • “if” statement with each label with two statements which

    • Perform the communication

    • Move process to the next state

Translation processes 3

Translation: Processes (3)

proctype Source(chan Out)




:: Out?Out; goto initial;



proctype Sink(chan In, val)




:: In?Val; goto initial;



Translation models 1

Translation: Models (1)

  • Performed (assembled) in the “init” process

  • Required instances of processes are created (run)

  • Actions enclosed in “atomic” statement (So things don’t start happening until we are ready)

  • Connections implemented by appropriate allocation of channels as parameters to process instances

Translation models 2

Translation: Models (2)

chan ch0 = [CHLEN] of {chan};

chan nch0 = [0] of {chan};

/* Process definitions here */



Atomic {

run Source(ch0);

run Sink(ch0, nch0);



Translation models 3

Translation: Models (3)

  • Promela permits the creation of channels which carry channels

  • Length of channels

    • An issue – its not in the diagram

    • Set by user at translation time

  • Each process is given a channel as a parameter for each channel name it knows

Issues unconnected channels

Issues – Unconnected channels

  • Each process has a parameter for each channel name it knows

  • What if the name isn’t connected to anything (at start up)?

  • Omitting parameters to processes is an error

  • Unconnected names given a nil length channel each to avoid problems

Issues the create type event

Issues – the Create type event

  • Permits a process to bring a new channel (value) into existence

  • Translation scheme outlined so far requires all channels to be declared before start of execution

  • Solution adopted is a provide processes with a collection of channels to use

    • In current implementation, when these are exhausted, create events can no longer occur

Issues special case of read

Issues – Special case of Read


:: X?X; goto second;


chan tmp;


:: atomic{X?tmp; X = tmp; }

goto second;


Further work

Further work

  • I already have a tool which performs this translation automatically

  • Solution to the Create problem…

Postscript on the create issue

Postscript on the Create issue

  • A loop could execute a create event an unlimited number of times, creating a new channel each time

  • But:

    • There is a limit to the number of channels the processes in the model can “know”

    • Ultimately each time a new channel is created, one is lost

    • Hence only a finite number needed, if lost channels are re-cycled

Hierarchy problem

Hierarchy Problem

  • What we would like to draw:

Abstract connection

What we usually get

What we usually get

  • Boxes within Boxes

  • With the lines brought out to the edges

The usual problem

The Usual Problem

  • What we would like to draw:

  • What we actually do:

A process for the election algorithm

A process for the election algorithm

Using processes to build a model

Using processes to build a model

And this model only has three processes

Executing the model

Executing the model

Building the same model with connectors

Building the same model with connectors

The connector

The Connector

Issues 1

Issues (1)

  • Need to distinguish which end of a connector is which

Issues 2

Issues (2)

  • Allowing processes to be connected at the higher, “connector” level

    • Want to use the connectors in the model definition (before connectors and processes fully elaborated)

    • Don’t want to add the connectors as a tidying exercise after model is complete

    • Tool draws either view – either showing connectors (plus any individually created channels), or the all of the detail

Issues 3

Issues (3)

  • What about names in the process not in the connector?

  • What about strands in the connector not known to the process?

  • What about strands which connect at just one end: dangling ends?



  • Visual Formal Models can be useful

  • Single level diagrams get cluttered

  • Addressing this requires attention to channels as well as processes

  • This is not as simple as it appears

  • Login