3. Baltimore SIGAda
• Characteristics of Real-Time Systems
– Responsiveness
– Timeliness
– Concurrency
– Dynamic structure and behaviour
– Distribution
– Reliability
4. Baltimore SIGAda
• Hard Real-Time Systems
– Deterministic system behaviour
• Soft Real-Time Systems
• System combinations of Soft and Hard
Real-Time Systems
5. Baltimore SIGAda
• Hard Real-Time Systems are often designed
with an additional component that is not
part of the UML Standard – Timing
Diagrams.
Hard Real-Time Systems are often designed
to interact with sensors and activators on the
equipment that the system is
communicating with.
6. Baltimore SIGAda
• Hard real-time systems that are safety-critical may
contain within the architecture a watchdog timer
implementation.
• Watchdog timers may be built into a
microprocessor card and are typically driven by a
periodic reset signal from the primary processor.
If the reset signal fails to reset the watchdog timer
within that time, the watchdog timer restarts the
main processor.
7. Baltimore SIGAda
• Real-time systems may make use of a
technique called “interrupts”.
Interrupts may be disabled and the result is
a portion of code that is “atomic”. Some
portions of a real-time system to operate
correctly are labelled “critical sections” are
must be atomic for the system to operate
properly.
9. Baltimore SIGAda
• Concurrency support from operating
systems and programming languages is
limited.
• Many complex real-time systems are state-
based. The behaviour of these systems may
be difficult to design and understand.
10. Baltimore SIGAda
• In order to model states with concurrency
one needs a notation, a process and a tool.
• This pyramid of building blocks is
represented by the Unified Modeling
Language, the Rational Unified Process and
the Rational Rose Real-Time Modeling tool.
11. Baltimore SIGAda
• UML and Rose Realtime handle concurrency with
the capsule. The capsule provides this capability
to model concurrency.
• To support concurrency a passive object must
exercise control over “critical” or “atomic”
sections of code where variable could be accessed
simultaneously. An example of the problem is the
Shared Data Bug.
12. Baltimore SIGAda
• Active Objects and Finite State Machines
– State – condition in which an active object
persists and behaves in a predetermined way for
some time
– Transition -- path connecting two states
– Trigger – an event which fires a transition
– Action – work performed by action code when
transition is fired by the triggering event
13. Baltimore SIGAda
• Capsule enforce the O-O concept of
encapsulation.
• Capsules interact via asynchronous message
passing.
• Capsules encapsulate the finite state
machine behaviour, an execution thread,
and the properties of the capsule.
14. Baltimore SIGAda
• Capsules may be concurrent or distributed.
• Capsules may be tested independently.
• Demonstrate use of a capsule in a concurrent
architecture.
• In a Class Diagram identify the UML notation for
a capsule.
– Attributes
– Operations
– Ports
– Finite State Machine
– Structure Diagram
15. Baltimore SIGAda
• UML Models
– Use Case Model – similar to requirements
– Design Model – realized by class diagrams
– Implementation Model – collection of
components
– Test Model – test cases and procedures
16. Baltimore SIGAda
• Rose Real-Time Views
– Use-Case View – use-case diagrams; interaction
diagrams – sequence and collaboration diagrams;
– Logical View – class diagrams; structure diagrams;
state diagrams; collaboration diagrams; sequence
diagrams;
– Implementation (Component) View – executables, C++
Libraries; C++ External Libraries
– Deployment View – software components are mapped
to hardware deployment configuration
– See Rational Training Course DEV160 Modeling
Behaviour with UML
– Demonstrate the views to the working group.
17. Baltimore SIGAda
• Use-Case View diagrams consist of use-
case and interaction diagrams
• Use Case Diagrams consist of actors and
use cases
• Actors are outside of the system and interact
with the system
• Use cases are actions performed by the
system
19. Baltimore SIGAda
• Sequence Diagrams are
interactions between elements
as a time ordered set of
messages.
• Contain instances of
capsules.
20. Baltimore SIGAda
• Logical View contains Class
Diagrams, Structure Diagrams,
State Diagrams, Collaboration
Diagrams and Sequence
Diagrams.
21. Baltimore SIGAda
• Class Diagrams depict static
view of Packages, Capsules,
Classes, Protocols and
Relationships
22. Baltimore SIGAda
• Structure Diagrams are a
specialized Collaboration
Diagram.
• Contain Capsule roles, Ports
and Connectors.
• Structure diagrams are
contained within a capsule.
23. Baltimore SIGAda
• State Diagrams depict high
level behaviour of a capsule
in a finite state machine
• Contain States, substates and
transitions
24. Baltimore SIGAda
• Component View describes
organization of static
software modules
• The software is built in this
view (i.e. compiled)
• Contains executables and C
and C++ Libraries
25. Baltimore SIGAda
• Deployment View is where software
components are mapped onto hardware
• Contains processors and component
instances
– Processors describe on what processor the built
component is run on
– Component instances are executable
components
26. Baltimore SIGAda
• Socket Interface Presentation
• The purpose of this
presentation is to describe
how a Socket Interface may be
implemented using Rational
Rose.
28. Baltimore SIGAda
• This is the Class Diagram for the
server (ReceiverSameThread) and
client (SenderSameThread)
capsules. They represent the top-
level capsules for the ping/pong
example. The IPC and TCP capsules
are incarnated by the top-level
capsules onto a physical thread
configured with the
RTCustomController implementation
class.
29. Baltimore SIGAda
• The Class Diagram depicts a
composition relationship
between the top-level
capsules and the IPC and TCP
capsules. The next two
slides describe a composition
relationship.
31. Baltimore SIGAda
• The IPCReceiver capsule is incarnated
by the top-level capsules onto a
physical thread configured with the
RTCustomController implementation
class i.e. a RTCustomController thread.
• The frame service in Rose Real-Time is
used to incarnate an IPCReceiver
capsule role.
32. Baltimore SIGAda
• An example of how the frame
service is used below to
incarnate (i.e. create or
instanstiate) capsule roles,
destroy capsule roles, plug
in capsule roles (i.e.
import) or unplug capsule
roles (i.e. deport)
• id =
frame.incarnate(iPCReceiver,
33. Baltimore SIGAda
The frame service call is action
code contained within the
transition Labelled initialize.
This is a state diagram for the
capsule ReceiverSameThread.
35. Baltimore SIGAda
• Here is structure diagram
which contains a capsule role
labelled iPCReceiver.
36. Baltimore SIGAda
• The previous slides shows a structure
diagram for ReceiverSameThread
which contains a capsule role labelled
IPCReceiver. This capsule role has a
symbol in the lower right corner that
indicates that there is a nested capsule
role within this capsule role.
37. Baltimore SIGAda
• The structure diagram for IPCReceiver
capsule contains a capsule role labelled
customIPCLayer of class TCPServer.
38. Baltimore SIGAda
• iPCReceiver refers to the
optional Capsule Role
• IPCReceiver is the address to
myData
• EmptyObject is an optional
piece of data that is
delivered to the capsule in
its initial transition.
• CustomIPCThread refers to the
logical thread in which the
39. Baltimore SIGAda
• The IPCReceiver capsule controls the
number of messages exchanged with
the TCPclient capsule through the
contained optional capsule
'customIPCLayer'.
40. Baltimore SIGAda
• The capsule role labelled
customIPCLayer of class TCPServer is
connected via a connector to a port
labelled talkRemote.
• The talkRemote port is a conjugated,
wired, protected, end port in the
structure diagram for IPCReceiver.
41. Baltimore SIGAda
• In the previous slide, the rounded rectangle
attached to the end port refers to the state
machine of the associated capsule. So
messages coming in on this port are
delivered to, and are processed by the
associated capsule’s state machine. The
connected boxes inside the rounded
rectangle refer to a connection. Ports that
have the connected boxes in it are wired
ports.
43. Baltimore SIGAda
• The following slide depicts
how action code contained
within the transition
labelled Initialize will
incarnate a TCPServer.
44. Baltimore SIGAda
• An example of how the frame
service is used below to
incarnate (i.e. create or
instanstiate) capsule roles,
destroy capsule roles, plug
in capsule roles (i.e.
import) or unplug capsule
roles (i.e. deport)
• id =
frame.incarnate(customIPCLaye
r,
45. Baltimore SIGAda
• The action code in the transition
labelled ping uses the talkRemote
port to send the pong signal. The
format for sending data in Rose
Real-Time is
port_name.signal(data).send();
• The pong signal is defined in a
protocol class and optionally may
have data associated with them.
Action code is below.
• talkRemote.pong().send();
47. Baltimore SIGAda
• The transition for internalSetup
sets a variable called internalFd
which will be used by 'wakeup'
calls to unblock the
RTCustomController.
• internalFD is a internal UDP
socket descriptor.
• UDP sockets are connectionless and
have no protocol. There are
suitable to use for the purpose of
local host (board) communication.
• internalFd = makeUdpConnection();
48. Baltimore SIGAda
• A connectionless service is
one in which transmissions
take place without a pre-
established path between the
source and destination.
Because packets may arrive by
different paths and in random
sequences, there is no way to
guarantee delivery of a
message in a connectionless
service. Because it can not
guarantee delivery, a
49. Baltimore SIGAda
• The Action Code for the
choice point labelled
internalOK checks the value
of internalFd [which is an
internal socket descriptor]
to see if if it has been set
to a value other than -1
which it was initialized to.
• Action code is on next slide.
50. Baltimore SIGAda
• if( internalFd < 0 )
• return 0; // not OK
• // Follow the
FALSE path
• // of the
Choice Point
• ioMonitor.add( internalFd,
RTIOMonitor::CanRead );
• return 1; // OK
• // Follow
the TRUE path
51. Baltimore SIGAda
• TCPServer side transition
action code for externalSetUp
on next three slides
• create an variable labelled
listener of type RTTcpSocket
class
• RTTcpSocket listener;
52. Baltimore SIGAda
• use the RoseRT log service to
output a message
without a carriage return
and the integer value of the
listening port.
• LISTENING_PORT is a constant
in the TCPIP_Proxies package
and its value is set to 31736
• log.show("Listening to: ");
log.log( (int)LISTENING_PORT
);
53. Baltimore SIGAda
• ioMonitor of class
RTIOmonitor is used to
monitor the external socket
channel 'c_socket'
• registerWith is a public
function which returns a void
which is contained within
header file RTTcpSocket.h
• c_socket.registerWith(
&ioMonitor );
54. Baltimore SIGAda
• Action Code for Choice Point
labelled external OK
• The function int
RTTcpSocket::state() returns
'Established‘ if the socket
file descriptor is usable
• return ( c_socket.state() ==
RTTcpSocket::Established );
55. Baltimore SIGAda
• if the state() function
returns Established then the
socket file descriptor is
usable then take the TRUE
path of the choice point
which in this case is
registerWithController
• if the state() function does
not return Established then
the socket file descriptor is
56. Baltimore SIGAda
• Action Code for transition
labelled giveUp
• Use the Rational Rose RT
System Service called the Log
Service to output a message
without a carriage return
• log.show("IPC channel
initialization failedn");
• Close the external socket
channel c_socket
• c_socket.close();
57. Baltimore SIGAda
• Action Code for transition
labelled registerWithController
• The macro REGISTER_LAYER takes
three arguments which are pointers
to the 'waitfunc', 'wakeupFunc',
and 'processFunc‘ functions to be
called by the RTCustomController.
• If any of these are null pointers
the default values are used.
• The waitForEvents function is
called when the when the
RTCustomController does not have
any messages left to deliver.
58. Baltimore SIGAda
• REGISTER_LAYER( waitForEvents,
wakeup, 0);
• Use the Rational Rose RT System
Service called the Log Service to
output a message with a carriage
return
• log.log("Connected");
• set the length of the buffer to
the integer value of the constant
BUFFLEN which is in this 100
• buffLen = (int)BUFF_LEN;
60. Baltimore SIGAda
• Action Code for transition
labelled ‘pong’
• int RTTcpSocket::write() -
writes on a socket file
descriptor using the system
call write
• The incoming buffer needs to
be of size buffLen which is
100
• if( c_socket.write(
incomingBuffer, buffLen ) !=
61. Baltimore SIGAda
Use the Rational Rose RT
System Servic called the Log
Service to output a message
without a carriage return
• log.show( "TCPServer:
incomplete writen" );
• the incoming Buffer was not
of length buffLen
66. Baltimore SIGAda
• The IPCSender capsule is incarnated
by the top-level capsules onto a
physical thread configured with the
RTCustomController implementation
class i.e. a RTCustomController thread.
• The frame service in Rose Real-Time is
used to incarnate an IPCSender
capsule role.
67. Baltimore SIGAda
• An example of how the frame
service is used below to
incarnate (i.e. create or
instanstiate) capsule roles,
destroy capsule roles, plug
in capsule roles (i.e.
import) or unplug capsule
roles (i.e. deport)
• id =
frame.incarnate(iPCSender,
IPCSender,
68. Baltimore SIGAda
The frame service call is action
code contained within the
transition Labelled initialize.
69. Baltimore SIGAda
• Here is a structure diagram
which contains a capsule role
labelled iPCSender.
70. Baltimore SIGAda
• The previous slides shows a structure
diagram for SenderSameThread which
contains a capsule role labelled
IPCSender. This capsule role has a
symbol in the lower right corner that
indicates that there is a nested capsule
role within this capsule role.
71. Baltimore SIGAda
• The structure diagram for IPCSender
capsule contains a capsule role labelled
customIPCLayer of class TCPClient.
72. Baltimore SIGAda
• iPCSender refers to the
optional Capsule Role
• IPCSender is the address to
myData
• EmptyObject is an optional
piece of data that is
delivered to the capsule in
its initial transition.
• CustomIPCThread refers to the
logical thread in which the
73. Baltimore SIGAda
• The IPCSender capsule controls the
number of messages exchanged with
the TCPServer capsule through the
contained optional capsule
'customIPCLayer'.
74. Baltimore SIGAda
• The capsule role labelled
customIPCLayer of class TCPServer is
connected via a connector to a port
labelled talkRemote.
• The talkRemote port is an
unconjugated, wired, protected, end
port in the structure diagram for
IPCSender.
75. Baltimore SIGAda
• In the previous slide, the rounded rectangle
attached to the end port refers to the state
machine of the associated capsule. So
messages coming in on this port are
delivered to, and are processed by the
associated capsule’s state machine. The
connected boxes inside the rounded
rectangle refer to a connection. Ports that
have the connected boxes in it are wired
ports.
77. Baltimore SIGAda
• The following slide depicts
how action code contained
within the transition
labelled Initialize will
incarnate a TCPClient.
78. Baltimore SIGAda
• An example of how the frame
service is used below to
incarnate (i.e. create or
instanstiate) capsule roles,
destroy capsule roles, plug
in capsule roles (i.e.
import) or unplug capsule
roles (i.e. deport)
• id =
frame.incarnate(customIPCLaye
r,
79. Baltimore SIGAda
• The action code in the transition
labelled pong uses the talkRemote
port to send the ping signal. The
format for sending data in Rose
Real-Time is
port_name.signal(data).send();
• The ping signal is defined in a
protocol class and optionally may
have data associated with them.
Action code is below.
• talkRemote.ping().send();
81. Baltimore SIGAda
• The transition for internalSetup
sets a variable called internalFd
which will be used by 'wakeup'
calls to unblock the
RTCustomController.
• internalFD is a internal UDP
socket descriptor.
• UDP sockets are connectionless and
have no protocol. There are
suitable to use for the purpose of
local host (board) communication.
• internalFd = makeUdpConnection();
82. Baltimore SIGAda
• A connectionless service is
one in which transmissions
take place without a pre-
established path between the
source and destination.
Because packets may arrive by
different paths and in random
sequences, there is no way to
guarantee delivery of a
message in a connectionless
service. Because it can not
guarantee delivery, a
83. Baltimore SIGAda
• The Action Code for the
choice point labelled
internalOK checks the value
of internalFd [which is an
internal socket descriptor]
to see if if it has been set
to a value other than -1
which it was initialized to.
• Action code is on next slide.
84. Baltimore SIGAda
• if( internalFd < 0 )
• return 0; // not OK
• // Follow the
FALSE path
• // of the
Choice Point
• ioMonitor.add( internalFd,
RTIOMonitor::CanRead );
• return 1; // OK
• // Follow
the TRUE path
85. Baltimore SIGAda
• TCPClient side transition
action code for externalSetUp
on next three slides
• The client will form
connections actively to the
TCPServer.
• The value of listening port
has been set to 31736. This
is the port number value of
the NASAServer on this
86. Baltimore SIGAda
• The RoseRT call to the log
service will display the
• port number of the NASAServer
• log.show("Connecting to: ");
log.show( (int)LISTENING_PORT
);
87. Baltimore SIGAda
If running on an embedded target,
run either the server or client
down on the embedded board. Run
the other on your host machine.
Modify the ip address defined in
the TCPIP_Proxies::CONSTANTS to
that of either the host or target.
If both the server and client run
on the same workstation the ip
address can remain at 127.0.0.1.
• For the purposes of this demo
MASTER_HOST is set to 127.0.0.1
because the client and server are
89. Baltimore SIGAda
• Action Code for Choice Point
labelled external OK
• The function int
RTTcpSocket::state() returns
'Established‘ if the socket
file descriptor is usable
• return ( c_socket.state() ==
RTTcpSocket::Established );
90. Baltimore SIGAda
• if the state() function
returns Established then the
socket file descriptor is
usable then take the TRUE
path of the choice point
which in this case is
registerWithController
• if the state() function does
not return Established then
the socket file descriptor is
91. Baltimore SIGAda
• Action Code for transition
labelled giveUp
• Use the Rational Rose RT
System Service called the Log
Service to output a message
without a carriage return
• log.show("IPC channel
initialization failedn");
• Close the external socket
channel c_socket
• c_socket.close();
92. Baltimore SIGAda
• Action Code for transition labeled
registerWithController
• The macro REGISTER_LAYER takes
three arguments which are pointers
to the 'waitfunc', 'wakeupFunc',
and 'processFunc‘ functions to be
called by the RTCustomController.
• If any of these are null pointers
the default values are used.
• The waitForEvents function is
called when the when the
RTCustomController does not have
any messages left to deliver.
93. Baltimore SIGAda
• REGISTER_LAYER( waitForEvents,
wakeup, 0);
• Use the Rational Rose RT System
Service called the Log Service to
output a message with a carriage
return
• log.log("Connected");
• set the length of the buffer to
the integer value of the constant
BUFFLEN which is in this 100
• buffLen = (int)BUFF_LEN;
95. Baltimore SIGAda
• The port labeled talkRemote
is an public, conjugated,
wired end port.
• Rational RoseReal-Time is a
product of IBM Rational
Software Corp.