1 / 95

Baltimore SIGAda

Explore the design concepts of real-time systems using UML & Capsules, covering concurrency, modeling techniques, finite state machines, and component views. Enhance your understanding through diagrams and critical sections!

wandahayden
Download Presentation

Baltimore SIGAda

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 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.

  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 < 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 • // of the Choice Point

More Related