1 / 51

UML and Real Time

UML and Real Time. Fran ç ois Terrier, S é bastien G é rard DRT-LIST/DTSI/SLA/LLSP, CEA/Saclay, F-91191 Gif sur Yvette Cedex France Phone: +33 1 69 08 62 59 ; Fax: +33 1 69 08 83 95 Francois.Terrier@cea.fr ; Sebastien.Gerard@cea.fr. Plan of the presentation. UML2 standardization status

smithjoyce
Download Presentation

UML and Real Time

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. UML and Real Time François Terrier, Sébastien Gérard DRT-LIST/DTSI/SLA/LLSP, CEA/Saclay, F-91191 Gif sur Yvette Cedex FrancePhone: +33 1 69 08 62 59 ; Fax: +33 1 69 08 83 95 Francois.Terrier@cea.fr ; Sebastien.Gerard@cea.fr

  2. Plan of the presentation • UML2 standardization status • Real Time, QoS, SPT profile and UML • Point on current tools for RT with UML (TAU UML Suite, ARTiSAN Studio, Rhapsody ROSE RT, Esterel Studio) • Real Time modeling with ACCORD/UML • Protocol state machine • RT Component Model • MDE through UML profiles

  3. RT in UML 1.4 • Quantitative aspects • TimeEvent in state-machine • Timing mark in Sequence Diagram • Qualitative aspects • Concurrency : Active object, Concurrent state, … • Discrete behavior via state machinesand activity diagrams • Attempts of integrating continuous behavior within activities of state-machines

  4. Status of the UML2 proposals • Two remaining main prop. for Infra/Super • U2 group (www.u2-partners.org )Infrastructure  latest version is v.2.0 beta R2 released 2002/06/02 • 2U group (www.2uworks.org )Infrastructure  latest version is v0.81 released 2002/07/02 • Helsinki meeting (End of September 2002) • 1st revised submission presentation for Superstructure • 2nd revised submission presentation for Infrastructure • UML2 RFP split into 4 parts • UML 2.0 OCL  UML 2.0 Diagram Interchange • UML2 Infrastructure  core language of UML • UML2 Superstructure  state-machine, sequence diag., …

  5. Plan of the presentation • UML2 standardization status • Real Time, QoS, SPT profile and UML • Point on current tools for RT with UML (TAU UML Suite, ARTiSAN Studio, Rhapsody ROSE RT, Esterel Studio) • Real Time modeling with ACCORD/UML • Protocol state machine • RT Component Model • MDE through UML profiles

  6. S2 S1 ResourceB Client ResourceA S1 S2 CPU CPU Physical Processor Scheduling, Performance& Time Profile • Proposers and supporters • ARTiSAN, I-Logix, Rational, Telelogic, TimeSys, Tri-Pacific, CEA-LIST • Main concepts • resources & quality of service (QoS) • uniform basis to attach quantitative information to UML specifications (e.g. required for RT analysis performing)  Not THE Real Time UML profile… !

  7. Genericsub-profiles for real-time applications Specific sub-profilesfor dedicated activitiesaround real-timeapplication development Current architecture of UML SPT profile • Consists of 5 sub-profiles • General Resource Sub-profile(Defines abstract concepts of Resource & QoS) • Resource concept has been developed • QoS concept remains abstract ! • General Time Sub-profile • General Concurrency Sub-profile • Performance Sub-profile • Schedulability Sub-profile

  8. +requiredQoS QoSCharacteristic 0..n 0..n 0..n 0..n +offeredQoS 0..n 0..n ResourceUsage Resource ResourceService 0..n 0..n 1..n 1..n 0..n 0..n /:SRV aDriver/:Driver regOutput/:Display start Offered QoS «RTaction» {RTstart=(10, 'ms')} display display(): «SAAction» {SAWorstCase=(25,'ms'), RTduration=(5,'ms')} Required QoS SPT base concept  QoS (Abstract class !) • Use example of the QoS concept in a model

  9. Issues relating to QoS within SPT prof. • QoS remains an abstract concept • never concretized by other SPT sub-profiles • Specific sub-profiles(Schedulability, Performance, RT-CORBA) • defines implicitly required QoS (eg. TVs SAPriority, SADelay, …) • but no links with the QoScharacteristics concept ! • SPT does not proposes solutions to specify: • domain specific QoS characteristics quantifiables with specific values (e.g. capacity of fligth plan managnt, antenna sign. accuracy) • QoS contracts in subsystems, components and use cases • QoS modes the systems supports: adaptations & QoS levels • monitoring of QoS values and their impact in the architectures

  10. What are you talking about? 1 What happen when ...? 5 What we need totake into account? What can you do? What do you want? 2 3 How can you execute? 4 Architecture of QoS (& Fault Toler.) prof.

  11. 2 Generics for RT domain 1 QoS & Resource 3 Concurrency Time Throughput/Performance Lantency ... ... UML 2 Schedulability Analysis Performance Analysis … RT package Code Generation ? Specific sub-profiles for dedicated activitiesaround real-time application development RT refactoring in UML  3 points:

  12. Plan of the presentation • UML2 standardization status • Real Time, QoS, SPT profile and UML • Point on current tools for RT with UML TAU UML SuiteARTiSAN Studio, Rhapsody, ROSE RT, Esterel Studio • Real Time modeling with ACCORD/UML • Protocol state machine • RT Component Model • MDE through UML profiles

  13. TAUUML/SDL Suite UML modeling is used at the first modeling stage, SDL used for design… Stopped Running pAC 1 C1 ActuatorControl startRegulating stopRegulating RegControl [cmd] updateScreen(OFF) targetSpeed = returnvalue [speed] pAC 1 pRC 1 C2 RegControl RegulatingLaw Stopped Running SensorControl ActuatorControl SensorControl SpeedRegulator_Behavior stopRegulating() / updateScreen(OFF); Newtype RegulatingLaw Operators calculate : Speed, Speed -> TorqueVariation endnewtype:; Off On startRegulating() / targetSpeed = returnValue; Active object declarations  SDL processes Passive objects  Abstract Data Types of SDL

  14. TAU UML/SDL Suite : conclusions  UML/SDL: mapping is under user responsibility … he has to clarify the mapping of • How to ensure independency between model and implementation ? • Timing specifications: only with low level implementation mechanisms (Timers, SDL priorities… ) • UML state machines  SDL specifications • Use of shared passive objects in UML model  SDL • Active object communication  SDL signal exchange

  15. Plan of the presentation • UML2 standardization status • Real Time, QoS, SPT profile and UML • Point on current tools for RT with UML TAU UML Suite,ARTiSAN StudioRhapsody, ROSE RT, Esterel Studio • Real Time modeling with ACCORD/UML • Protocol state machine • RT Component Model • MDE through UML profiles

  16. Speedmeter Control ::Regulator control calculation Channel1 PMH ::RegulatingLaw * stopRegulating() pRegLaw calculate startRegulating() Speedmeter Actuator Motor control Actuator ARTiSAN Real-time Studio two orthogonal models, weak integration Explicit modeling of concurrency features !!! • A logical model in usual class/object diagrams • An explicit task model in a specific diagram  Concurrency diagram

  17. Speedmeter Speedmeter Control Control control control calculation calculation Channel1 Channel1 PMH PMH update() regLaw:Commande Speedmeter Speedmeter read() Actuator Actuator Motor Motor control control Actuator Actuator ARTiSAN Real-time Studio A mapping stage  assignment of objects to tasks Three techniques • wrapping data and functions in object wrappers • making schedulable objects & scheduling them using tasks • encapsulating tasks & their communications behind interf.

  18. ARTiSAN Real-time Studio: conclusions Task model has to be manually implemented Relation between task and object model is weak  Communication between objects of different tasks must be implemented by the user with low level RT concepts Timing constraints must be translated on implement. Concurrent diagram is out of the standard A tool dedicated to high skill real-time developers with a lot of things to be done by hand and at the standard borders.

  19. Plan of the presentation • UML2 standardization status • Real Time, QoS, SPT profile and UML • Point on current tools for RT with UML TAU UML Suite, ARTiSAN Studio,Rhapsody,ROSE RT, Esterel Studio • Real Time modeling with ACCORD/UML • Protocol state machine • RT Component Model • MDE through UML profiles

  20. Identify system task • Populate tasks with objects of analysis and design stages • Inter tasks communication = Synchro. + data exchange Rhapsody (RT-UML) two «orthogonal» but «integrated» models • Explicit modelling of concurrency

  21. pAC 1 ActuatorControl « reactive »RegControl RegControlTask ActControlTask pAC 1 pRC 1 RegulatingLaw SensorControl SpeedRegulator_Behavior SpeedRegulator_Behavior stopRegulating() stopRegulating() / updateScreen(OFF); / updateScreen(OFF); Off Off On On startRegulating() startRegulating() / / targetSpeed = returnValue; targetSpeed = returnValue; Rhapsody (RT-UML) • Behavior specified by state machine of reactive obj. • Reactive objects are assigned to active objects… • Communication by message between reactive obj. ActuatorControl RegControl SensorControl

  22. Rhapsody (RT-UML) : conclusions • Explicit tasking model (described & maintained by hand) • Communication issues • Triggered operation : concept between event & operation • Only return value of operation call can be defined …… but under responsibility of the caller ! (cf. conc. conflict) • Complex semantic diff. between signals & operation calls • Low level of Real Time specifications • Priorities can be assigned to active objects • Timing constraints must be implemented by hand A tool dedicated to high skill real-time developers with animation opportunities but not really “real-time”.

  23. Plan of the presentation • UML2 standardization status • Real Time, QoS, SPT profile and UML • Point on current tools for RT with UML TAU UML Suite, ARTiSAN Studio, RhapsodyROSE RT,Esterel Studio • Real Time modeling with ACCORD/UML • Protocol statemachine • RT Component Model • MDE through UML profiles

  24. « protocol » Protocol infoProto incoming « capsule » « capsule » S 1 anEmitter : Emitter aReceiver : Receiver capsule link State 1 Behaviour portB : infoProto~ Signal sending portA. send (s ) ; 1 portA : infoProto State 2 Communication port Rose Real-Time (UML-RT) attempt to integrate task and object paradigms • «capsule» stereotype identifies active objects • They will be assigned to task at implementation stage  mapping with task & priorities must be managed by hand • They have state automaton but low level timing specification • Communication is performed through « ports » • Sending of signal via port of communication • Defines the set and protocol of the exchanged messages

  25. get / aReg : Regulator / aSpM : Speedometer value (data) t1 Initial Initial + / carSpeed + / carSpeed : SpdAcq : SpdAcq~ t3 Initiated Not to forget « reply » action on server side !  blocked until reply receipt  release by reply receipt Rose Real-Time (UML-RT) • A synchronous communication with return value Initial t1 Off Inter t3 Synchronous call with reply Action: RTMessage retMsg;m carSpeed.get().invoke(&retMsg); int newCarSpeed= *(const int *) retMsg.getData(); Trigger: Signal get on port carSpeed Action: carSpeed->value(data).reply();

  26. Usual object paradigm Entities communicating via operation call. vs. Rose Real-Time (UML-RT): conclusions • A high level concept for concurrency with an implicit logical execution model  Capsule • "Unusual" OO paradigm Capsule paradigm Entities communicating via signal exchange through ports. … but close to an Interface with Protocol State Machine Behavior spec. via limited UML state machine Timing specification through low level mechanisms The concept of “Capsule” is certainly very powerfull but a little bit “exotic” regarding usual OO paradigm (eg. For communication). About RT constraint spec., it is equal to other, i.e. only timing event, because the concept of priority reveals to be not useable!

  27. Plan of the presentation • UML2 standardization status • Real Time, QoS, SPT profile and UML • Point on current tools for RT with UML TAU UML Suite, ARTiSAN Studio, Rhapsody, ROSE RT,Esterel Studio • Real Time modeling with ACCORD/UML • Protocol statemachine • RT Component Model • MDE through UML profiles

  28. Esterel Studio A "graphical form" equivalent to Esterel • S_Capsule (“Synchronized_Capsule”) • Inherited from ROOM’ Capsule • Get ports typed by a “pluget” (~ ROOM Protocol) • Concurrent components inside behavior • SyncChart • A "graphical form" equivalent to Esterel language • Synchronous computation model • The Zero-Delay hypothesis • Absence of event may be a trigger • Possibility of events conjunction

  29. Running transition label suspend parallel component Esterel studio (SyncCharts) normal terminaison macro-state / e initial pseudo-state simple state strong abortion s / e final state weak abortion suspension

  30. Esterel studio (SyncCharts): conclusions • Based on an abstract ideal view of real systems “Synchronous assumption” • Convenient for “hardware-intensive” systems • Difficult to insure in other case • Behavior = SyncChart formalism • Formal view  possibility of formal verification • Out of UML standard (notation + semantics) • Methodology aspect under-development • The tool support only behavior aspect • Prototype of coupling with Rose

  31. Plan of the presentation • UML2 standardization status • Real Time, QoS, SPT profile and UML • Point on current tools for RT with UML (TAU UML Suite, ARTiSAN Studio, Rhapsody ROSE RT, Esterel Studio) • Real Time modeling with ACCORD/UML • Protocol state machine • RT Component Model • MDE through UML profiles

  32. ACCORD/UML methodology • Results of 10 years of OO researches for RT-Syst. of nuclear plant + PhD work with PSA (Peugeot) + AIT-WOODDES IST Eur. proj. + ACOTRIS a Nat. proj. • Provides • Modeling methodology:continuous process, separation of functional spec. and implementation constraints or choices • Tools supporting the process and the method • Model transform., code gen. for rapid prototyping • Model analysis, test generation

  33.  Protocol state machine in UML • expresses legal transit. a classifier can trigger •  defines alifecycle for objectsor an invocation order of its operations • Protocol transitions have the following info.: • a pre condition (guard) • one or several triggering event • a post condition. Every • zero or one operation that belongs to the context classifier of the protocol state machine. • It can be associated to Interfaces and Ports

  34. unObjet operation() « signal » Signal() & Logic Algorithmic ‘Evt’ ‘[’ garde ‘]’ / ‘liste-Actions’ /delta=k1*atan(tgSpeed-cuSpeed); mot->sendCmd(coupleVariation); Signal() initReg[cptVit->getSpeed()=<30] /display("ON"); E2 E1 Regulator On Off tm(100)/tgSpeed = cptVit->getSpeed(); tgSpeed : int Maintainability  initReg() C stopReg/display("OFF"); stopReg() Reusability  [carSpeed=<30]/display("OFF"); Usual way to use the state machine … … UML state machine notations operation() CallEvent SignalEvent ChangeEvent TimeEvent CallEvent

  35. AIT-WOODDES / ACCORD proposal : a more structured way ! Control logic & Algorithms aspects Logic aspect Object behaviour Algorithmic aspect • Separation on concerns to improve behaviour modelling • Reactive View • "what it must do" • Protocol View • "what it can do"

  36. « describe protocol view » Method behavior = Algorithmic parts Regulator Class behavior = Control logic (protocol use) +tgSpeed : integer carSpeed = cptVit->getSpeed() +initReg() +stopReg() & Logic Algorithmic delta=k1*atan(tgSpeed-cuSpeed) +maintainSp() /delta=k1*atan(tgSpeed-cuSpeed); mot->sendCmd(torqueVariation) mot->sendCmd(coupleVariation); Regulator tgSpeed : int initReg() initReg[cptVit->getSpeed()=<30] stopReg() /display("ON"); Protocol-transition maintainSp() Marche Marche Arret Arret tm(100)/tgSpeed = cptVit->getSpeed(); call-event ‘(’params‘)’‘[’ guard ‘]’ initReg() Maintainability  C stopReg/display("OFF"); Off On Reusability  stopReg() [carSpeed=<30]/display("OFF"); Regulator interface

  37. « describe reactive view » Triggering view (ACCORD/UML) Class interface Regulator RegOnOff / initReg() / maintainSp() +tgSpeed : integer On Off RegOnOff / stopReg() +initReg() [carSpeed<50] / stopReg() « Signal » RegOnOff() +stopReg() +maintainSp() Triggering-transition Set of consistent rules between protocol and triggering views ‘evt-name ’ ‘(’param-list‘)’‘[’ guard ‘]’ /<ope-name> ‘(’params‘)’ • ChangeEvent • CompletionEvent • SignalEvent • TimeEvent

  38. S1 S2 Class S m () 1 1 m () 1 S 2 act1 S1 S2 act2 Summary on ACCORD behavior model Class behavior = control logic ‘call-event-name’ ‘(’param-list‘)’ ‘[’ guard ‘]’ Class structure Protocol view (UML ~standard) = “What instances of this class may do” ‘event-name’ ‘(’param-list‘)’ ‘[’ guard ‘]’ / called-operation-name ‘(’param-list‘)’ Method view(~UML standard)= Howprocessingis performed Trigger view (ACCORD/UML) = “What the instances of this class have to do”

  39. Plan of the presentation • UML2 standardization status • Real Time, QoS, SPT profile and UML • Point on current tools for RT with UML (TAU UML Suite, ARTiSAN Studio, Rhapsody ROSE RT, Esterel Studio) • Real Time modeling with ACCORD/UML • Protocol state machine • RT Component Model • MDE through UML profiles

  40. Component Model ER2 ER1 «parts» Initial Model «refine» ACCORD/UML (PAM ou DAM) • Component definition 2 possible views: • “Black box” (= external view) •  set of interfaces • “White box” (= internal view) •  sub-system Sub-system Model C_Sub-Syst_1 C_Sub-Syst_3 Sub-Syst_1 Sub-Syst_2 C_Sub-Syst_2 Sub-Syst_3 Decomposition heuristics & component model ER1 = Heuristics to ease decomposition of a system into a sub-systems model ER2 = Model mappings to transform resulting sub-systems model into component model - required & offered interface - component connexions / association links - …

  41. provided Interface RT_QoS required ACCORD/UML RT-Component Model • Component Model based on • UML2 component Model + RT_QoS Component •  Interface can have both BehavioralFeatures: • operations also with QoS specif. • receptions (signals) with QoS specif.

  42. RT_QoS RT_QoS RT_QoS RT_QoS Component Model ER3 C_Sub-Syst_1 C_Sub-Syst_3 ER2 C_Sub-Syst_2 CCM Sub-system Model RT_QoS RT_QoS RT_QoS Sub-Syst_1 Sub-Syst_2 Sub-Syst_3 ACCORD/UML RT-Component Modelbased on a MDA approach… ER2 = These mappings take into account specified RT features of the sub-system model  PIM-to-PIM ER3 = Mappings from the RT-Comp. Mod. of ACCORD/UML towards a platform model (e.g., RT-CCM model)PIM-to-PSM

  43. Plan of the presentation • UML2 standardization status • Real Time, QoS, SPT profile and UML • Point on current tools for RT with UML (TAU UML Suite, ARTiSAN Studio, Rhapsody ROSE RT, Esterel Studio) • Real Time modeling with ACCORD/UML • Protocol state machine • RT Component Model • MDE through UML profiles

  44. MDA Challenges •  What MDA means:modelling with UMLto develop a systemwith • a clear separation of implementation technology • following a continuous modelling process • using intensively model synthesis • Methods to define well-structured models • Business oriented (versus software techn oriented) • Activity oriented: req/spec/design/impl/proof/test/simul, etc. • Techniques to exploit development expertise • Profile, script, meta-modeling, aspect progr., etc. • Expertise implementation (RT, emb., safety, valid., etc.) • Implementation platform models (CCM, RT-OS, etc.) • Tooling & standards (interf., coop., interact., exch., etc.)  What we need :

  45. Application synthesis Test Synthesis ACCORD/UML methodoology:Models everywhere…

  46. SPE profile SPT profile AL profile Modelling tools OMG’ Standard profiles !!! ! ACCORD/UML Profile ACCORD/UML Methodology defined by user relizes + Structure of ACCORD Methodology

  47. Real-Time QoS Model Behavior Model Communication Model Concurrency Model ACCORD/UML profilefor Embedded Systems • ► Real-time QoS model • The domain viewpoint • Model overview • Model details • The UML viewpoint • Stereotypes and tagged values definition • Tagged Value Types • ► Communication model • ► Behaviour model • ► Concurrency model

  48. SPTprofile::Core Ressource Model QoScharacteristic RTF Priority PriorityRTF Period TimingRTF ReadyTime Deadline Real-time features modeldomain viewpoint overview • Definifion of a Real-Time QoS generic concept of RT QoS Priority-based RT QoS Timing-based RT QoS

  49. RTF itsPr Priority PriorityRTF 1 itsPe +create(In pr:Priority ,In pe:Period ,In peNb:integer) Period 0..1 Real-time features modeldomain viewpoint details • PriorityRTF • Attributes Operations • create ( ref in RTtimeValue, pr in Priority, pe in Period=-1, peNb=-1 in integer ) : It create an instance of priority-based RTF according to values passed as parameters. “pr” is the priority, “pe” is the period and “peNb” is the number of period of the new instance. Associations • itsPr:Priority (1-1): It denotes the priority feature of the current priority RTF. • itsPe:Period (0-1): It denotes the period feature of the current priority RTF if necessary.

  50. Stereotype Tag Name Tag Type BaseClass Multiplicity Parent Tags RTF_value «RTF» RT_QoStype Action [0..1] RTF_value Transition Message From SPT Profile Real-time features model – UML viewpoint • RTF ► RT_QoStype  “(“ <timingQoS> | <priorityQoS> ”) <timingQoS> ::= “(“ <RefDate> “, “ <Deadline> “, “ <ReadyTime> “,“ <Period> “, “ <NoPeriod> ”)” <priorityQoS> ::= “(“ <Priority> “, “ <Period> “, “ <NoPeriod> ”)” <RefDate> ::= “(RefDate, “ <value> “, “ <timeUnitStr> ”)” • <Deadline> ::= “(Deadline, “ <value> “, “ <timeUnitStr> ”)” • <Priority> ::= “(Priority, “ <value> ”)” • <ReadyTime> ::= “(ReadyTime, “ <value> “, “ <timeUnitStr> ”)” • <Period> ::= “(Period, “ <value> “, “ <timeUnitStr> ”)” • <NoPeriod> ::= “(NoPeriod, “ <value> “, “ <timeUnitStr> ”)” • <value> ::= <Integer> | <Real> • <timeUnitStr> ::= “’ns’” | “’us’” | “’ms’” | “’s’” | “’hr’” | “’days’” | “’wks’” | “’mos’” | “’yrs’

More Related