Baltimore SIGAda

1
Baltimore SIGAda

• Rational Rose Real Time Presentation

2
Baltimore SIGAda

• Real-Time System Design Concepts

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.

8
Baltimore SIGAda

• Modeling Real-Time Systems

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

18
Baltimore SIGAda

• Interaction Diagrams consist of collaboration
  diagrams
• Framework for sequence diagrams

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.

27
Baltimore SIGAda

• This demo uses the following Architecture

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.

30
Baltimore SIGAda

• Server Side Socket Connection
• Description

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,
• IPCReceiver,
• EmptyObject,
• CustomIPCThread )

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.

34
Baltimore SIGAda

• The incarnated TCPServer and TCPClient
  architecture

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 capsule runs on.

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 capsules state
  machine. The connected boxes inside the rounded
  rectangle refer to a connection. Ports that have
  the connected boxes in it are wired ports.

42
Baltimore SIGAda

• This is the state diagram for the IPCReceiver
  capsule.

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(customIPCLayer,
• TCPServer,
• EmptyObject,
• CustomIPCThread )

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()

46
Baltimore SIGAda

• This is the state diagram for the TCPServer
  capsule.

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 connectionless service is
  described as a best effort service.

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 lt 0 )
• return 0 // not OK
• // Follow the FALSE path
• // of the Choice Point
• ioMonitor.add( internalFd, RTIOMonitorCanRead
  )
• return 1 // OK
• // Follow the TRUE path
• // of the Choice Point

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 RTTcpSocketstate() returns
  'Established if the socket file descriptor is
  usable
• return ( c_socket.state() RTTcpSocketEstablis
  hed )

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
  not usable then take the FALSE path of the choice
  point which in this case is giveUP

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 failed\n")
• 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

59
Baltimore SIGAda

• State Diagram for substate labelled Operational

60
Baltimore SIGAda

• Action Code for transition labelled pong
• int RTTcpSocketwrite() - 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 ) !
  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 write\n" )
• the incoming Buffer was not of length buffLen

62
Baltimore SIGAda

• This is the structure diagram for the TCPServer
  capsule.

63
Baltimore SIGAda

• The port labelled talkRemote is an public,
  unconjugated, wired end port.

64
Baltimore SIGAda

• Client Side Socket Description

65
Baltimore SIGAda

• The incarnated TCPServer and TCPClient
  architecture

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,
• EmptyObject,
• CustomIPCThread )

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 capsule runs on.

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 capsules state
  machine. The connected boxes inside the rounded
  rectangle refer to a connection. Ports that have
  the connected boxes in it are wired ports.

76
Baltimore SIGAda

• This is the state diagram for the IPCSender
  capsule.

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(customIPCLayer,
• TCPClient,
• EmptyObject,
• CustomIPCThread )

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()

80
Baltimore SIGAda

• This is the state diagram for the TCPClient
  capsule.

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 connectionless service is
  described as a best effort service.

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 lt 0 )
• return 0 // not OK
• // Follow the FALSE path
• // of the Choice Point
• ioMonitor.add( internalFd, RTIOMonitorCanRead
  )
• return 1 // OK
• // Follow the TRUE path
• // of the Choice Point

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 machine.
• The type of listening port is short int.

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_ProxiesCONSTANTS
  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
  running on the same microprocessor

88
Baltimore SIGAda

• if( c_socket.create()
• c_socket.connect( (const char )MASTER_HOST,
  (int)LISTENING_PORT ) )
• while( c_socket.state() RTTcpSocketSynSent
  )
• ioMonitor.wait( RTTimespeczero )

89
Baltimore SIGAda

• Action Code for Choice Point labelled external OK
• The function int RTTcpSocketstate() returns
  'Established if the socket file descriptor is
  usable
• return ( c_socket.state() RTTcpSocketEstablis
  hed )

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
  not usable then take the FALSE path of the choice
  point which in this case is giveUP

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 failed\n")
• 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
• talkRemote.recall()

94
Baltimore SIGAda

• This is the structure diagram for the TCPClient
  capsule.

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.