RoseRT Introduction

Lucent Technologies – ProprietaryUse pursuant to company instruction

RoseRT Introduction

Zhu,Fei(Georgia), Zhang Jizheng (Justin)

Fab 16, 2006

Lucent Technologies – Proprietary

Use pursuant to company instruction

Agenda

RoseRT General Introduction

RoseRT Modeling Construct

RoseRT User Interface

RoseRT Service Library

RoseRT Architect

RoseRT Detailed Design

Implementation in UMTS NodeB IntOA&M Subsystem



What is RoseRT

Rational Rose RealTime is a developer’s tool to design event-driven and real-time applications.

RoseRT generates code directly from the UML models.

It runs without modification on the RoseRT Virtual Machine (RVM) which is directly portable to many HW platforms and operating systems.



Where I can apply RoseRT

RoseRT is built to support:– Real-time systems

– Concurrency

– Message passing

• Intraprocessor messaging

• Interprocessor messaging

– State models and transitions



Where I can apply RoseRT(page2)

RoseRT provides a Target runtime system for abstracting the hardware and OS of the target.– RoseRT provides an infrastructure

• Task/Process creation/deletion

• Message transport

• Message handling

• Event creation and handling

• Other common infrastructure software and functionalities



Where I can apply RoseRT(page3)

RoseRT supports:– C

– C++

– Java

RoseRT does require a compiler and change control system to “complete” the SDE– Change Control systems

• Clearcase, SourceSafe, RCS, SCCS, PVCS and others can be added.

– Compilers and OSs• Virtually all commercially supported OSs and compilers

(VxWorks, Solaris, Windows, pSOS, etc)



Agenda





RoseRT Architect





Capsules Real-time system design often requires a

common design pattern, called an “Active object”

Construct in Rational Rose RealTime is called a “capsule”– provide a graphical representation of active design elements

– encapsulate behavior and interact using message-based communications passed through interface objects

– hide implementation details and allow the system architecture to be clearly communicated and understood

– are control-independent (do not call other capsules directly)

– can be made concurrent and/or distributed



Capsules are UML Class Stereotypes

Capsules are expressed as UML class stereotypes using the extensibility mechanisms provided in the UML standard

Capsule

<“ports” >

Class

isActive:Boolean

stereotype



Capsules: UML Modeling

Stereotype of Class concept («capsule») with specialized (executable) semantics

Class diagram representation:

«capsule»CapsuleClassX

#counter : int#x : char

+portB : ProtocolA::master#portC : ProtocolB

ports



Capsules: Active Objects

Encapsulationshell

Ports/ProtocolsStimulus

message

Responsemessages



Capsules: Behavior

Optional hierarchical state machine (signal handler with run-to-completion semantics)

S1

S2 S3

S1

S2

S1

transitionS1toS2: {int x; x = 0; p2.send(sig1); p3.send(sig2); … };

Action Code



Protocols: Contractual Behavior Patterns

Interaction contracts between capsules– e.g., operator-assisted call

call

ack

time

number

call

ack

talk

transfer

Caller Operator Callee



Ports: Boundary Objects

Fully isolate a capsule’s implementation from its environment (in both directions), there’re also inner ports.

Environment

Capsule

S1

S2

Port



Combining Capsules

Using connectors

Communication channels between Communication channels between objectsobjects Static typing rules apply (compatible protocols)Static typing rules apply (compatible protocols)

«capsule»sender : Fax

remote : FaxProt«capsule»

receiver : Faxremote : FaxProt

Connector



FaxCall

«capsule»sender:Fax

remote:FaxProt

c : Control

«capsule»receiver:Fax

Remote:FaxProt

c : Control

receiveCtrl : ControlsendCtrl : Control

Relayport

Capsule Composition: Reusable Structural Patterns

The composite is also a first-class object!



Composite Capsule Semantics

Run-time assertion: the complete internal structure of a composite is automatically created (recursively, if necessary) when the capsule is created

f1:FaxCall



f1 := create(FaxCall);

In some systems the code that controls the creation and destruction of objects can be as much as 35% of all code



End Ports: Structure and Behavior Meet

End Ports connect message stream to the state machine


c : Control


c : Control

receiveCtrl : Control~senderCtrl : Control~

c : SystemControl

initial

connected

connecting

capsule state machine

Public End Port

ImplementationEnd Port



Defining Capsule Structure

Capsule Roleto create a new capsule role,and optionally a new capsule

Portto create a new port,and optionally a new protocol

Connectorto create communication paths between ports

To repetitively select any item on the toolbar,right-click within the toolbar and select Lock Selection.



Capsule StructureContained Capsule Roles

Connector

PortsContainer Capsule



Capsules as Pattern Specifications

BehaviorServices Layer

Application Layer

TerminalA TerminalB

Channel1

Channel2

Structure

Capsule definitioncaptures pattern

Telecom System Architecture



Refinement Through Specialization

Channel2

TerminalA TerminalB

Channel1

TerminalA TerminalB

Channel1



PortsOne or more ports per capsule are possible

– capsule presents “views” of itself through ports

– each port represents a specific “role” the capsule plays in a collaboration

Each interface element is defined by the protocol for that port– extension of the traditional concept of interface

IN OUT

start donestop

IN OUT

status ok errorresourceMgr resource

application

ResourceMgmt



Messages

Messages used for information exchange between capsules– asynchronous and synchronous exchanges are possible

– ideal for concurrent, distributed system development

– results in a highly decoupled system• this is critical to component-based development

– contains a signal + (optional) data component + priority

Wakeup

7:00 AM

Tuesday

Signal

Additionalmessage data(optional)

GeneralPriority



Messages - Priority

For real-time systems it is often necessary to base event processing precedence on an assigned priority

– Each message has a priority attached to it• concept is orthogonal to object or task priority

– Priority semantics are application specific. Meaning each project typically must address issues such as:

• latency management

• transaction processing escalation

HighPriority

Fire!

5 Ash St.

Tucson

HighPriority



Messages - Protocol

A protocol is defined by a set of:– Incoming message types

• Who’s There?, Boo Who?

– Outgoing message types• KnockKnock, Boo!, Please Don’t Cry!

Jokester Straight Man

Knock Knock!

Boo!

Please Don’t Cry!

Who’s There?

Boo Who?

Knock-knock Protocol

In Out

Who’s There?Boo Who?

Knock Knock!Boo!Please Don’t Cry!



Protocols

Protocols are:

specifications of valid message exchange sequences between two collaborating capsules

defined from the point-of-view of one of the participants:– incoming/outgoing definitions are dependent on the perspective

• Jokester’s outgoing message is StraightMan’s incoming message

inverted when used by the other collaboration participants– create the inverse protocol by conjugating a port

• StraightMan’s protocol is the inverse of Jokester’s protocol

– single point of change to modify all affected ports



Ports

There are two types of ports:

Relay port

All messages are delivered to a state machine within a capsule

relay ports deliver messages transparently to contained capsules, and incur NO run-time penalty

end ports deliver messages to capsule’s behavior

End port

Internalend port



What’s Really Inside A Capsule

End port

Relay Port

Message

Internal End Port

Behavior



Capsule Behavior - Finite State Machines

Widely used visual formalism for describing the behavior of event-driven systems

I

Ready

WaitForAck

ack

timeout

begin

initial

States

Transitions

Wait forEvent

Wait forEvent

HandleEvent

HandleEventHandleEvent

HandleEvent

Wait forEvent

Wait forEvent



Capsule Behavior - State Diagrams

Use UML state diagrams to capture capsule behavior:

– hierarchical decomposition for dealing with complex behavior

– suitable for efficient automatic code generation

– adapted to capsule paradigm (multiple interfaces, messages)

– run-to-completion event handling model

– can be refined through inheritance

Any capsule with an end port can have an associated state machine to describe its internal behavior



Capsule Behavior - The Toolbar

Stateto create states

State Transitionto create transitions between states

Branchto create conditional transitions

Transition to Selfto create transitions to the same state



Capsule Behavior - State Diagrams (cont’d)StatesStates

TransitionsTransitions

Initial TransitionInitial Transition

Self TransitionsSelf Transitions



Events and Triggers

An event occurs with the arrival of a message at an end port

A transition trigger is a specification of one or more events (“exclusive or”) that will set off the transition

The trigger is based on:– interface element (end port)

– message type (signal)

– optional guard condition• boolean predicate

• can test triggering message fields

• advanced concept for refining triggering specifications



How to Define a Transition TriggerOpen transition specification:Open transition specification:- define trigger event(s)- define trigger event(s)- enter action code to be run- enter action code to be run



Event Handling Model Run to completion: within a single thread, handling of

current event will always complete before the next event is processed– simple, systematic concurrency handling model

• more reliable• less error prone

– after the processing of one event is completed, the highest priority enqueued event is processed next

– low latency: most events require very little event processing time

e5

e1 e2 e3 e4* e5

0 10 20 30 40

Processing: e1 e2 e4* e3

Event Arrival:

Time:

Processing of e2 does not commence until processing of e1 is complete.Event e4* has a higher priority than e3 so it is processed before e3 when e2 has completed.The system rests idle until event e5 arrives. Event e5 is processed immediately.



Agenda





RoseRT Architect





Models and WorkspacesRational Rose RealTime - Models

• view: use case, logical, component, deployment

• model element: capsule, protocol, class, actor, use case

• package: collection of logically related model elements

• diagram: visual representation of model elements and their relationships

Rational Rose RealTime - Workspaces• workspace: all information related to an active Rational

Rose RealTime session (settings, opened model views etc.). The workspace can be

saved in a workspace file.



Rational Rose RealTime - Four Model Views

Use Case View– Used to specify how the system will be used

• Workflow: Requirements

Logical View– Used to design the logical architecture of the system

– Design the classes that will collaborate to satisfy the requirements• Workflow: Analysis, Design, Implementation

Component View– Used to define how the executable component will be generated

• Workflow: Implementation

Deployment View– Used to describe the processor where the component will be deployed

• Workflow: Deployment



Use Case View



Sequence DiagramsInteraction Capsule Instances Interaction Capsule Instances

StatesStates

MessagesMessages

Focus of controlFocus of control



Class Diagrams

Abstract view of classes, their relationships and dependencies

Relationships that apply to all instances of a class

Primary view of inheritance relationships



Capsule The capsule’s encapsulation shell

hides its internal structure preventing internal components from being viewed and accessed from outside its boundary

Capsules communicate with each other through public ports, boundary object on the its encapsulation shell

Ports are objects used by capsules to send and receive messages to and from other capsules instances

Capsules are light weight concurrent objects provided by Rose RealTime. Capsule are:• a special form of class that have their own thread of control (i.e., active class)• design patterns providing light-weight concurrency directly in the model• implemented in Rose RealTime as a stereotype of a class• used to design systems that can handle many simultaneous activities without

incurring the high overhead of multitasking at the operating system level.

Encapsulation Shell Ports

active

wait

<<Capsule stereotype>>

Name

Attributes

Operations

Ports



Structure Diagrams Advantages

– graphical representation of active objects is simple and clear

– shows capsule aggregation and containment associations

– shows communication paths and role-based interface elements

– supports inheritance

Two-Party Call

CallController

Line1 Line2



State Diagrams Advantages

– shows behavioral overview for active objects

– based on finite state machines

– allows system observation and control at abstract level

– hierarchical notation supports complex behavior capture

Waiting to

BeginIn Progress

Completed

Evaluation Process



Agenda





RoseRT Architect





Built-in Real-Time Services Rose RealTime provides the following run-time services:

– Timing generates timeout events

– Log prints to stdout

– Communication messaging (asynchronous or synchronous)

– Frame dynamic creation, destruction of capsules

Communication services are accessed through ports based on the user defined protocols

Timing, Frame and Log services are assessed of these built-by defining a unwired protected port within the capsule using the appropriate built-in class.

Each service has a set of functions which can be called by the capsule using the service



Target Observability



Communication Services The send function allows asynchronous communication

via a specified port:– Transition logic continues executing– Response, if any, triggers a separate transition

The invoke function allows synchronous communication via a specified port:– Sends message and blocks the transition until response is received– Receiver must use a reply statement

The reply function allows asynchronous or synchronous response via the port through which received the stimulus message



Communication Code examples Examples:

– infoP.infoRequest().send();• “infoRequest” is the signal being sent through port “infoP”. • No data is sent.

– clockDisplay.setTime( RTTime(12, 0, 0) ).send()• “setTime” is the signal being sent.• “RTTime(12, 0, 0)” is the data value being sent.

– msg-> info(information).reply();• “info” is the signal being returned.• “information” is the data being returned.• reply is a function on the last message received.

– newInfo = *RTDATA• RTDATA is a macro that allows access to the received data.• RTDATA casts msg->data to the type that is specified in the protocol for the

message being received.



Asynchronous Communication Overview

Asynchronous Communication

In

info

Out

infoRequest

Receiver

infoP

Sender

infoPStructure

infoTransfer Protocol

Sender Action Code:returnCode = infoP.infoRequest().send();

Sender Action Code:newInfo = *RTDATA;

Receiver Action Code:returnCode = msg->info(information).reply();

Waiting ForEvent

Waiting ForReply

Done

Sender

reply

event

Receiver

Waiting ForRequest

Done

request



Synchronous Communication Overview

Synchronous Communication

Receiver

Waiting ForRequest

Donerequest

returnCode = msg->info(information).reply();

Waiting ForEvent

Done

Sender

event

RTMessage replyMsg;replyCount = infoP.infoRequest().invoke(&replyMsg);if (replyCount > 0)

newInfo = * (Myinfo *) replyMsg.data;

Synchronous Communication is seldom if ever necessary. In general, use Asynchronous Communication.

In

info

Out

infoRequest

Receiver

infoP

Sender

infoPStructure

infoTransfer Protocol



Log Service The Log service is accessed through an unwired

port of the Log class. Log service provides the following operations:

– log

– show

– cr

Examples:– log.log(“Hello world”); // log adds carriage return

– log.show(“Hey!”); // show doesn’t add carriage return

– log.cr(); // carriage return

Log output goes to stdout



Timing Service The Timing service is accessed through a protected unwired port

of the Timing class.

Timing ports provide the following functions, plus others:– informIn - one-shot relative timer

– informAt - one-shot absolute timer

– informEvery - periodic timer

Examples:– timerId = timer.informEvery( RTTimespec(1,0) );

• timerId is an attribute of type RTTimerId• timer is a Timing service port defined on the capsule• RTTimespec(1,0) constructs a relative time object with a value of 1 second, 0

nanoseconds

– timer.informAt( RTTime(12, 0, 0) );• RTTime(12,0,0) constructs an absolute time object for 12 hours, 0 minutes, 0

seconds



Frame Service The Frame Service is accessed through an unwired

port of the Frame class.

Frame service provides many operations for creating, destroying, plugging, unplugging capsules and querying information about contained capsules.

Important operations include:– incarnate– destroy– import– deport– me

Example– RTActorId id = frame.incarnate( capsuleRefName,CapsuleClassName,

EmptyObject, ThreadName, index );



Agenda





RoseRT Architect





Frameworks and Patterns

Modeled as composite capsules– e.g., a two-party telephone call

Two-PartyCall

callController

line1 line2



Genericity

Type-based components– allow different phone implementations (capsules) to be

substituted in a decomposition

Two-PartyCall

callController

line1 line2

Substitutable



Inheritance

System design is defined through class specifications, and all classes can be subclassed for reuse and refinement.– capsules

• object frameworks (architectures) can be re-used and subclassed

• complex concurrent behaviors

• easy to add additional functionality through subclassing

– protocols• capture protocol specification

• signals can be added or deleted in a subclass

• easy generation of protocol variations through subclassing

– classes• easy generation of new data types required in the model

• subclassing available to refine or add to class



Inheritance - Capsule StructureSuperclassStructure

SubclassStructure(all inheritedstructure is gray)

partyA partyB

partyA partyB

Supervisor



Inheritance - Capsule Behavior

gopoll

Ready

Process

gopoll

Ready Error

Process

errcodego

poll

Ready

Process

reset

SuperclassBehavior

Subclass 1 Behavior Subclass 2 Behavior



Replicated Capsule Structures

Regular (repeating) structural patterns can be captured through the concept of replicated components– replicated structures are more succinct expression of

complex design

controller n card

n

controller

card-1

card-n

.

.

.=



Multiple instances of a capsule may be required– specify multiplicity at design-time

– capsules are instantiated at run-time according to the specified cardinality of the capsule role

Multiplicity

Shelf Model

shelfController

targetCard

Replicated Shelf Model

shelfController

targetCard n

n



Replicated Shelf Model

Designers can designate optional capsules that are created under the control of an executing application

– By default capsules are ‘fixed’ and are created at program initialization time

– For “optional” capsules, memory is allocated when actually required

• keep initialization time down

• system structure reflects actual need rather than potential

Dynamic Structure

shelfController

targetCard

n

n



Plug-ins Dynamic Relationships

– different capsule incarnations are inserted under control of the executing application

Scenario:terminal at index 12 callsterminal at index 45:

Call

callController

originator terminator

Terminal Manager

Plug-in capsule roles

terminal 45terminal 12

allTerminals



Layering

Layers are used to capture shared implementation-related components– a hierarchical dependency relationship between capsules

serviceA

serviceA

appA

appB

appA appB

serviceA



Layering (cont’d) Each layer is composed of a capsule or set of

capsules with common responsibilities.

Layer interfaces are defined by name using either:– wired ports, connectors

• makes relationships visually explicit

– unwired ports • protected unwired port connects to corresponding public unwired port

• rendered graphically by removing the wired icon

• reduces visual clutter by not showing obvious connectors

serviceA

appA appBprotected

public

protected



ConcurrencyRational Rose RealTime provides systematic solution to the difficult task of building concurrent, reliable, multi-threaded programs

– Simple rules for building thread safe applications

– The service libraries take care of the required synchronization to support cross thread messages sends • whether binding is across threads or not is hidden from the sender and

the receiver

– Logical threads - a potential unit of concurrency• components can be assigned to different logical threads• logical threads mapped to physical operating system threads• Ability to quickly change the thread configuration makes it easy to

explore and optimize the use of concurrent threads within the model



Build

Classes can be grouped into packages for larger system development. Packages can contain other packages.

Model compilation generates code and results in object files.– Incremental changes output only modified classes. Only

modified and affected classes are recompiled.

Easy to integrate Rational Rose RealTime build into a larger project build environment. – Compilation is entirely timestamp based and can be

performed outside the toolset using make.



Compilation Paradigm for Producing C++ Excecutable



Agenda





RoseRT Architect





From State Diagrams to Code Once the capsule’s overall behavior has been defined by a

state machine, behavior details are filled in as action code

Action code is associated with state diagram elements:– transitions– state entry and exit– conditions

• branch point conditions• guard conditions

For classes and capsules, can also define:– attributes– operations



Actions Associated with EventsAction code specifies a capsule’s behavior in response to a received event:

transition action: executed when a transition is triggered

entry action: executed when the state is entered

exit action: executed when the state is exited

Example Actions: sending a message, setting a timer, calling an operation, updating an internal attribute

On receiving a signal, boolean expressions can determine how or if a conditional transition is taken

guard condition: transition taken if given expression TRUE

branch condition: transition whose destination depends on result of evaluating boolean expression



Action Code details:– no declaration or prototype required– no return required– local variable declarations (scope limited to same segment)

Transitions and State Entry/State Exit

Transition Code State Entry Code



A Transition Trigger consists of a list of:– ports through which triggering events are received– specific triggering signal(s) on each port

Transition Triggers

List of Triggers for

this Transition



Branch and Guard Conditions Action Code details:

– return value must be 0 or non-zero (e.g. 1)– when new trigger event created, the event editor allows entering a

guard for the port and signal

Guard Condition



Internal AttributesAttributes:

– store information that must be retained between transitions

• e.g., a count of the number of times an event occurred

– have scope limited to the corresponding capsule instance

• i.e., no shared variables!

– accessed from behavior editor, model browser, class diagram

– can be of any type, including:

• types you define within Rational Rose RealTime

• externally-defined C and C++ types

• standard C and C++ data types, e.g. int, char*, double



OperationsOperations:

– can be defined to group common functionality for use within a capsule

– are available for private use within the capsule behavior

• e.g., transition code, guard conditions, branch code, entry/exit code

– can return results

– can take other actions such as updating attributes, sending messages

– accessed from behavior editor, model browser, class diagram

Operations can also be defined on classes



Operations and Operation PropertiesOperation Specification Parameters

ListReturnType

Same as ‘virtual’

Same as ‘const’

Same as ‘pure virtual’

Code



C++ Language SupportRational Rose RealTime provides C++ support for:

– all standard C and C++ and Rational Rose RealTime data types• e.g. char, double, float, int, long, short, unsigned

– user-defined data types• classes defined within Rose RealTime

• header file inclusions

– “msg” variable• provides access to message contents: signal, data, priority, etc.

• RTDATA extracts msg->data coerced to type specified in protocol: myData[msg->index()] = *RTDATA;

– run-time service libraries• port.send (signal);

• timer.informIn( RTTimespec(1,0) );

– predefined macros• CALLSUPER, RTDATA



Setting the Build Environment

Processor

ComponentModel Browser

Component Instance



Agenda





RoseRT Architect






Models location in VOB

MO Radio model browsing– Logical view

• Capsule specification: Operations, Attributes, Dependencies

• State Diagram

• Struct Diagram

• Unit Test package

– Component View

– Deployment View



Main Tasks in NodeB URC Board

Application level (3)

App (OAM)TimerThread, aSMT 101 (PRI_GENERAL_HIGH)

CP UCP main thread, CdmsIpcThread, GdfServerContext, UCI(UMTS-CP-Initialization)

104 (PRI_UCP_NORMAL)

OAM COAMComThread, MainThread, OamThread, 105 (PRI_OAM_NORMAL)

OAM Corba Agent (TheAgent, AgentRegistration), 106 (PRI_OAM_MEDIUM)

OAM FTPClientThread(FTP handing of MI), ORBexpress (can be started in several instances!) NotificationForwarder (one instance per registration) (Prio o.k.?) OAMLowPrioThread (Name: t.b.d.)

107 (PRI_OAM_LOW)



Documents

RoseRT Introduction