Issue 14899: Missing mappings between analysis duration, arrival patterns and clock constraints (marte-rtf) Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com) Nature: Enhancement Severity: Critical Summary: The mappings between the analysis arrival patterns (periodic, sporatic, …) and Time durations, and clock constraints in CCSL should be defined in the specification. Resolution: The kinds of timing specification that can be done with arrival patterns are in an expressive domain (vocabulary, and abstraction intent) different than the one expected for the use of CCSL. But they are compatible in their usage over behaviorSpecifications. It may be good to have this mapping as a Library in the Annex C, but this does not invalidate the current specification. I suggest to defer this issue for a possible future version of the standard. Disposition: Deferred Revised Text: Actions taken: December 31, 2009: received issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 31 Dec 2009 07:39:44 -0500 To: Subject: Issue/Bug Report ******************************************************************************* Name: Séstien Demathieu Company: Thales mailFrom: sebastien.demathieu@thalesgroup.com Notification: Yes Specification: MARTE Section: Time FormalNumber: 09-11-02 Version: 1.0 RevisionDate: 11/2009 Page: 55 Title: Missing mappings between analysis duration, arrival patterns and clock constraints Nature: Enhancement Severity: Critical test: 3qw8 B1: Report Issue Description: Date: Wed, 17 Feb 2010 17:01:49 -0500 Subject: Issue #14899 discussion about arrivals and clocks From: cmw@sce.carleton.ca To: marte-rtf@omg.org User-Agent: SquirrelMail/1.4.19 Issue text: Arrivals: The mappings between the analysis arrival patterns (periodic, sporatic, ?)and Time durations, and clock constraints in CCSL should be defined in the specification. Comment by Murray: I dont understand this issue and would like clarification. The arrival processes are an analysis concept describing something imposed on the system, or even generated by another subsystem. They are not prima facie clocks, although since they are event sequences, they have a relationship to clocks. It would be unnatural in my view to require the definition of arrival processes through definitions of clocks. However it would be natural to allow an arrival process to be generated by a clock, which could then incorporate CCSL constraints in the clock definition. The clock could be a GaWorkloadGenerator (see Fig 15.7). GaWorkloadGenerator is defined in 15.3.2.17 as a specialization of Behavior, so it can define the event streams by a behaviour mechanism. This might need to be modified to allow a clock to be a generator. This needs participation of a clock expert. Subject: RE: Issue #14899 discussion about arrivals and clocks Date: Thu, 18 Feb 2010 10:03:07 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #14899 discussion about arrivals and clocks Thread-Index: AcqwIdX5GlQowtCLRCei/Y47mw1ovQASN+3g From: "GERARD Sebastien 166342" To: , X-OriginalArrivalTime: 18 Feb 2010 09:03:08.0374 (UTC) FILETIME=[30713F60:01CAB079] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o1I8tnTT017851 Hi, My understanding between both concepts is following: - Clocks and CCSL may be used to model, I would say in an imperative way, the timing aspects; - Arrival pattern have been defined to be able to model in a declarative a set of common timing patterns widely used for analysis purpose. I do think both are required and used for different purpose or/and different persons having different knowledge/experience. What could be done to link both facilities in a more formal way, could be to define in MARTE a kind of formalization of these arrival patterns using (Clocks, CCSL) by defining an equivalent (Clocks, CCSL) model for each arrival patterns. What do you think? Best... Séstien. --------------------------------------------------------------------------- Dr. Séstien Gérd Head of MDD for DRES research project CEA, LIST/LISE Boî courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -----Message d'origine----- De : cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] Envoyé mercredi 17 féier 2010 23:02 À: marte-rtf@omg.org Objet : Issue #14899 discussion about arrivals and clocks Issue text: Arrivals: The mappings between the analysis arrival patterns (periodic, sporatic, ?)and Time durations, and clock constraints in CCSL should be defined in the specification. Comment by Murray: I dont understand this issue and would like clarification. The arrival processes are an analysis concept describing something imposed on the system, or even generated by another subsystem. They are not prima facie clocks, although since they are event sequences, they have a relationship to clocks. It would be unnatural in my view to require the definition of arrival processes through definitions of clocks. However it would be natural to allow an arrival process to be generated by a clock, which could then incorporate CCSL constraints in the clock definition. The clock could be a GaWorkloadGenerator (see Fig 15.7). GaWorkloadGenerator is defined in 15.3.2.17 as a specialization of Behavior, so it can define the event streams by a behaviour mechanism. This might need to be modified to allow a clock to be a generator. This needs participation of a clock expert. From: Julien.Deantoni@sophia.inria.fr X-IronPort-AV: E=Sophos;i="4.49,496,1262559600"; d="scan'208";a="45015840" Date: Thu, 18 Feb 2010 12:57:27 +0100 (CET) Subject: RE: Issue #14899 discussion about arrivals and clocks To: "GERARD Sebastien 166342" Cc: cmw@sce.carleton.ca, marte-rtf@omg.org User-Agent: SquirrelMail/1.4.8-5.el5_4.10 Hi Sebastien, > What could be done to link both facilities in a more formal way, could be > to define in MARTE a kind of formalization of these arrival patterns using > (Clocks, CCSL) by defining an equivalent (Clocks, CCSL) model for each > arrival patterns. we (INRIA) are currently working on this way. We propose to provide some usefull construct like periodic, a periodic, sporadic arrival thanks to clocks and CCSL. Do you think we could put them in the TimeLibrary ? However, we do not want to express every arrival pattern since some of them are really specific to queuing theory and are not easily suitable to a description based on clocks and CCSL. On the other hand, we could provide some other classical construct used for real time modeling (deadline, responsive time, etc) We do not know if it is usefull, if it should be in the example subsection of the Time section or in the TimeLibrary. Any idea ? @Murray: you should not make a big distinction between clocks and event... Clock is a misleading word since it can reprensent logical clocks. In this case, clock can be used to represent arrival patterns of event occurrences and each instant of a clock correspond to an event occurrence. Best regards, julien > > What do you think? > > Best... Sébastien. > > --------------------------------------------------------------------------- > Dr. Sébastien Gérard > Head of MDD for DRES research project > CEA, LIST/LISE > Boîte courrier 94, GIF SUR YVETTE > CEDEX, F-91191 France > Phone/fax : +33 1 69 08 58 24 / 83 95 > Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): > www.papyrusuml.org > http://www.eclipse.org/modeling/mdt/?project=papyrus > > Before printing, think about the environment > -----Message d'origine----- > DeÂ: cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] > EnvoyéÂ: mercredi 17 février 2010 23:02 > ÃÂ: marte-rtf@omg.org > ObjetÂ: Issue #14899 discussion about arrivals and clocks > > Issue text: Arrivals: The mappings between the analysis arrival patterns > (periodic, sporatic, ?)and Time durations, and clock constraints in > CCSL should be defined in the specification. > > Comment by Murray: > I dont understand this issue and would like clarification. The arrival > processes are an analysis concept describing something imposed on the > system, or even generated by another subsystem. They are not prima facie > clocks, although since they are event sequences, they have a relationship > to clocks. > > It would be unnatural in my view to require the definition of arrival > processes through definitions of clocks. However it would be natural to > allow an arrival process to be generated by a clock, which could then > incorporate CCSL constraints in the clock definition. The clock could be > a GaWorkloadGenerator (see Fig 15.7). > > GaWorkloadGenerator is defined in 15.3.2.17 as a specialization of > Behavior, so it can define the event streams by a behaviour mechanism. > This might need to be modified to allow a clock to be a generator. This > needs participation of a clock expert. > > > Date: Thu, 18 Feb 2010 16:45:01 -0500 Subject: RE: Issue #14899 discussion about arrivals and clocks From: cmw@sce.carleton.ca To: Julien.Deantoni@sophia.inria.fr Cc: "GERARD Sebastien 166342" , cmw@sce.carleton.ca, marte-rtf@omg.org User-Agent: SquirrelMail/1.4.19 Julien, Sebastien, I have suggested on the GQAM wiki page that a resolution might be to define a clock as a kind of generator of arrivals (generator is already in the prfile). This corresponds to your idea of allowing one to define some kind of clock to generate an arrival pattern. Besides having a library, this would allow a special applicatio specific clock that is part of a system, to be used in an analysis model (this might be a problem to characterize, but it might produce traces). I am not quite sure what haas to be done to the generator concept to allow a clock... I have suggested that the TimeValueSpecification might provide a bridge. Murray > Hi Sebastien, > >> What could be done to link both facilities in a more formal way, could >> be >> to define in MARTE a kind of formalization of these arrival patterns >> using >> (Clocks, CCSL) by defining an equivalent (Clocks, CCSL) model for each >> arrival patterns. > > > we (INRIA) are currently working on this way. We propose to provide some > usefull construct like periodic, a periodic, sporadic arrival thanks to > clocks and CCSL. Do you think we could put them in the TimeLibrary ? > > However, we do not want to express every arrival pattern since some of > them are really specific to queuing theory and are not easily suitable to > a description based on clocks and CCSL. On the other hand, we could > provide some other classical construct used for real time modeling > (deadline, responsive time, etc) We do not know if it is usefull, if it > should be in the example subsection of the Time section or in the > TimeLibrary. > > Any idea ? > > > @Murray: you should not make a big distinction between clocks and event... > Clock is a misleading word since it can reprensent logical clocks. In this > case, clock can be used to represent arrival patterns of event occurrences > and each instant of a clock correspond to an event occurrence. > > > Best regards, > > julien > > > > >> >> What do you think? >> >> Best... Sébastien. >> >> --------------------------------------------------------------------------- >> Dr. Sébastien Gérard >> Head of MDD for DRES research project >> CEA, LIST/LISE >> Boîte courrier 94, GIF SUR YVETTE >> CEDEX, F-91191 France >> Phone/fax : +33 1 69 08 58 24 / 83 95 >> Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): >> www.papyrusuml.org >> http://www.eclipse.org/modeling/mdt/?project=papyrus >> >> Before printing, think about the environment >> -----Message d'origine----- >> DeÂ: cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] >> EnvoyéÂ: mercredi 17 février 2010 23:02 >> ÃÂ: marte-rtf@omg.org >> ObjetÂ: Issue #14899 discussion about arrivals and clocks >> >> Issue text: Arrivals: The mappings between the analysis arrival patterns >> (periodic, sporatic, ?)and Time durations, and clock constraints >> in >> CCSL should be defined in the specification. >> >> Comment by Murray: >> I dont understand this issue and would like clarification. The arrival >> processes are an analysis concept describing something imposed on the >> system, or even generated by another subsystem. They are not prima facie >> clocks, although since they are event sequences, they have a >> relationship >> to clocks. >> >> It would be unnatural in my view to require the definition of arrival >> processes through definitions of clocks. However it would be natural to >> allow an arrival process to be generated by a clock, which could then >> incorporate CCSL constraints in the clock definition. The clock could be >> a GaWorkloadGenerator (see Fig 15.7). >> >> GaWorkloadGenerator is defined in 15.3.2.17 as a specialization of >> Behavior, so it can define the event streams by a behaviour mechanism. >> This might need to be modified to allow a clock to be a generator. This >> needs participation of a clock expert. >> >> >> > >Subject: RE: Issue #14899 discussion about arrivals and clocks Date: Thu, 18 Feb 2010 23:37:26 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #14899 discussion about arrivals and clocks Thread-Index: Acqw46TzYIAfPZDVQWmFMNeOHhy+ZgABvnIw From: "GERARD Sebastien 166342" To: , Cc: X-OriginalArrivalTime: 18 Feb 2010 22:37:26.0757 (UTC) FILETIME=[F24ED950:01CAB0EA] X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id o1IMU22C004666 About that issue, please remind I did not we have to remove the existing arrival patterns as they are currently defined (this kind of action is definitively out of the scope of the RTF). I suggest only completing them by defining for them a kind of formalization using the clock and CCSL. Cheers... Sébastien. Dr. Sébastien Gérard Head of MDD for DRES research project CEA, LIST/LISE Boîte courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -----Message d'origine----- DeÂ: cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] EnvoyéÂ: jeudi 18 février 2010 22:45 ÃÂ: Julien.Deantoni@sophia.inria.fr CcÂ: GERARD Sebastien 166342; cmw@sce.carleton.ca; marte-rtf@omg.org ObjetÂ: RE: Issue #14899 discussion about arrivals and clocks Julien, Sebastien, I have suggested on the GQAM wiki page that a resolution might be to define a clock as a kind of generator of arrivals (generator is already in the prfile). This corresponds to your idea of allowing one to define some kind of clock to generate an arrival pattern. Besides having a library, this would allow a special applicatio specific clock that is part of a system, to be used in an analysis model (this might be a problem to characterize, but it might produce traces). I am not quite sure what haas to be done to the generator concept to allow a clock... I have suggested that the TimeValueSpecification might provide a bridge. Murray > Hi Sebastien, > >> What could be done to link both facilities in a more formal way, could >> be >> to define in MARTE a kind of formalization of these arrival patterns >> using >> (Clocks, CCSL) by defining an equivalent (Clocks, CCSL) model for each >> arrival patterns. > > > we (INRIA) are currently working on this way. We propose to provide some > usefull construct like periodic, a periodic, sporadic arrival thanks to > clocks and CCSL. Do you think we could put them in the TimeLibrary ? > > However, we do not want to express every arrival pattern since some of > them are really specific to queuing theory and are not easily suitable to > a description based on clocks and CCSL. On the other hand, we could > provide some other classical construct used for real time modeling > (deadline, responsive time, etc) We do not know if it is usefull, if it > should be in the example subsection of the Time section or in the > TimeLibrary. > > Any idea ? > > > @Murray: you should not make a big distinction between clocks and event... > Clock is a misleading word since it can reprensent logical clocks. In this > case, clock can be used to represent arrival patterns of event occurrences > and each instant of a clock correspond to an event occurrence. > > > Best regards, > > julien > > > > >> >> What do you think? >> >> Best... Sébastien. >> >> --------------------------------------------------------------------------- >> Dr. Sébastien Gérard >> Head of MDD for DRES research project >> CEA, LIST/LISE >> Boîte courrier 94, GIF SUR YVETTE >> CEDEX, F-91191 France >> Phone/fax : +33 1 69 08 58 24 / 83 95 >> Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): >> www.papyrusuml.org >> http://www.eclipse.org/modeling/mdt/?project=papyrus >> >> Before printing, think about the environment >> -----Message d'origine----- >> DeÃÂ: cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] >> EnvoyéÃÂ: mercredi 17 février 2010 23:02 >> Ã.ÃÂ: marte-rtf@omg.org >> ObjetÃÂ: Issue #14899 discussion about arrivals and clocks >> >> Issue text: Arrivals: The mappings between the analysis arrival patterns >> (periodic, sporatic, ?)and Time durations, and clock constraints >> in >> CCSL should be defined in the specification. >> >> Comment by Murray: >> I dont understand this issue and would like clarification. The arrival >> processes are an analysis concept describing something imposed on the >> system, or even generated by another subsystem. They are not prima facie >> clocks, although since they are event sequences, they have a >> relationship >> to clocks. >> >> It would be unnatural in my view to require the definition of arrival >> processes through definitions of clocks. However it would be natural to >> allow an arrival process to be generated by a clock, which could then >> incorporate CCSL constraints in the clock definition. The clock could be >> a GaWorkloadGenerator (see Fig 15.7). >> >> GaWorkloadGenerator is defined in 15.3.2.17 as a specialization of >> Behavior, so it can define the event streams by a behaviour mechanism. >> This might need to be modified to allow a clock to be a generator. This >> needs participation of a clock expert. >> >> >> > >Date: Fri, 19 Feb 2010 09:31:35 +0100 From: S.©bastien Demathieu Organization: Thales Research & Technology User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: GERARD Sebastien 166342 CC: cmw@sce.carleton.ca, Julien.Deantoni@sophia.inria.fr, marte-rtf@omg.org Subject: Re: Issue #14899 discussion about arrivals and clocks Hi all, Removing the arrival patterns was definitively not the intent of this issue. There two possible usages for GaWorkloadEvent in the analysis profiles: either to define an arrival pattern as a VSL expression, or to relate it to a Time::TimedEvent. The issue asks for defining mappings / providing explanations on how these two ways to express similar concepts relate each other. We discussed this during the MARTE meeting in Long Beach and it looked to reasonsable to complete the spec with these mappings. Thanks, Séstien GERARD Sebastien 166342 a éit : About that issue, please remind I did not we have to remove the existing arrival patterns as they are currently defined (this kind of action is definitively out of the scope of the RTF). I suggest only completing them by defining for them a kind of formalization using the clock and CCSL. Cheers... Séstien. Dr. Séstien Gérd Head of MDD for DRES research project CEA, LIST/LISE Boî courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -----Message d'origine----- De : cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] Envoyé jeudi 18 féier 2010 22:45 À: Julien.Deantoni@sophia.inria.fr Cc : GERARD Sebastien 166342; cmw@sce.carleton.ca; marte-rtf@omg.org Objet : RE: Issue #14899 discussion about arrivals and clocks Julien, Sebastien, I have suggested on the GQAM wiki page that a resolution might be to define a clock as a kind of generator of arrivals (generator is already in the prfile). This corresponds to your idea of allowing one to define some kind of clock to generate an arrival pattern. Besides having a library, this would allow a special applicatio specific clock that is part of a system, to be used in an analysis model (this might be a problem to characterize, but it might produce traces). I am not quite sure what haas to be done to the generator concept to allow a clock... I have suggested that the TimeValueSpecification might provide a bridge. Murray Hi Sebastien, What could be done to link both facilities in a more formal way, could be to define in MARTE a kind of formalization of these arrival patterns using (Clocks, CCSL) by defining an equivalent (Clocks, CCSL) model for each arrival patterns. we (INRIA) are currently working on this way. We propose to provide some usefull construct like periodic, a periodic, sporadic arrival thanks to clocks and CCSL. Do you think we could put them in the TimeLibrary ? However, we do not want to express every arrival pattern since some of them are really specific to queuing theory and are not easily suitable to a description based on clocks and CCSL. On the other hand, we could provide some other classical construct used for real time modeling (deadline, responsive time, etc) We do not know if it is usefull, if it should be in the example subsection of the Time section or in the TimeLibrary. Any idea ? @Murray: you should not make a big distinction between clocks and event... Clock is a misleading word since it can reprensent logical clocks. In this case, clock can be used to represent arrival patterns of event occurrences and each instant of a clock correspond to an event occurrence. Best regards, julien What do you think? Best... Sébastien. --------------------------------------------------------------------------- Dr. Sébastien Gérard Head of MDD for DRES research project CEA, LIST/LISE Boîte courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -----Message d'origine----- DeÂ: cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] EnvoyéÂ: mercredi 17 février 2010 23:02 ÃÂ: marte-rtf@omg.org ObjetÂ: Issue #14899 discussion about arrivals and clocks Issue text: Arrivals: The mappings between the analysis arrival patterns (periodic, sporatic, ?)and Time durations, and clock constraints in CCSL should be defined in the specification. Comment by Murray: I dont understand this issue and would like clarification. The arrival processes are an analysis concept describing something imposed on the system, or even generated by another subsystem. They are not prima facie clocks, although since they are event sequences, they have a relationship to clocks. It would be unnatural in my view to require the definition of arrival processes through definitions of clocks. However it would be natural to allow an arrival process to be generated by a clock, which could then incorporate CCSL constraints in the clock definition. The clock could be a GaWorkloadGenerator (see Fig 15.7). GaWorkloadGenerator is defined in 15.3.2.17 as a specialization of Behavior, so it can define the event streams by a behaviour mechanism. This might need to be modified to allow a clock to be a generator. This needs participation of a clock expert. sebastien_demathieu1.vcf Subject: RE: Issue #14899 discussion about arrivals and clocks Date: Fri, 19 Feb 2010 15:25:27 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #14899 discussion about arrivals and clocks Thread-Index: AcqxPfdgiZTlFyqLT3+faKF2gQVSTAAMVOCg From: "GERARD Sebastien 166342" To: S.©bastien Demathieu Cc: , , X-OriginalArrivalTime: 19 Feb 2010 14:25:28.0325 (UTC) FILETIME=[625D5350:01CAB16F] Julien, Could send me more details on the work you were mentioning in your previous email and related this issue. Thanks, Sé Dr. Séstien Gérd Head of MDD for DRES research project CEA LIST, Laboratoire d.Ingéerie dirigépar les modès pour les Systès Embarqué(LISE) Boî courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -------------------------------------------------------------------------------- De : Séstien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] Envoyé vendredi 19 féier 2010 09:32 À: GERARD Sebastien 166342 Cc : cmw@sce.carleton.ca; Julien.Deantoni@sophia.inria.fr; marte-rtf@omg.org Objet : Re: Issue #14899 discussion about arrivals and clocks Hi all, Removing the arrival patterns was definitively not the intent of this issue. There two possible usages for GaWorkloadEvent in the analysis profiles: either to define an arrival pattern as a VSL expression, or to relate it to a Time::TimedEvent. The issue asks for defining mappings / providing explanations on how these two ways to express similar concepts relate each other. We discussed this during the MARTE meeting in Long Beach and it looked to reasonsable to complete the spec with these mappings. Thanks, Séstien GERARD Sebastien 166342 a éit : About that issue, please remind I did not we have to remove the existing arrival patterns as they are currently defined (this kind of action is definitively out of the scope of the RTF). I suggest only completing them by defining for them a kind of formalization using the clock and CCSL. Cheers... Séstien. Dr. Séstien Gérd Head of MDD for DRES research project CEA, LIST/LISE Boî courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -----Message d'origine----- De : cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] Envoyé jeudi 18 féier 2010 22:45 À: Julien.Deantoni@sophia.inria.fr Cc : GERARD Sebastien 166342; cmw@sce.carleton.ca; marte-rtf@omg.org Objet : RE: Issue #14899 discussion about arrivals and clocks Julien, Sebastien, I have suggested on the GQAM wiki page that a resolution might be to define a clock as a kind of generator of arrivals (generator is already in the prfile). This corresponds to your idea of allowing one to define some kind of clock to generate an arrival pattern. Besides having a library, this would allow a special applicatio specific clock that is part of a system, to be used in an analysis model (this might be a problem to characterize, but it might produce traces). I am not quite sure what haas to be done to the generator concept to allow a clock... I have suggested that the TimeValueSpecification might provide a bridge. Murray Hi Sebastien, What could be done to link both facilities in a more formal way, could be to define in MARTE a kind of formalization of these arrival patterns using (Clocks, CCSL) by defining an equivalent (Clocks, CCSL) model for each arrival patterns. we (INRIA) are currently working on this way. We propose to provide some usefull construct like periodic, a periodic, sporadic arrival thanks to clocks and CCSL. Do you think we could put them in the TimeLibrary ? However, we do not want to express every arrival pattern since some of them are really specific to queuing theory and are not easily suitable to a description based on clocks and CCSL. On the other hand, we could provide some other classical construct used for real time modeling (deadline, responsive time, etc) We do not know if it is usefull, if it should be in the example subsection of the Time section or in the TimeLibrary. Any idea ? @Murray: you should not make a big distinction between clocks and event... Clock is a misleading word since it can reprensent logical clocks. In this case, clock can be used to represent arrival patterns of event occurrences and each instant of a clock correspond to an event occurrence. Best regards, julien What do you think? Best... Sébastien. --------------------------------------------------------------------------- Dr. Sébastien Gérard Head of MDD for DRES research project CEA, LIST/LISE Boîte courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -----Message d'origine----- DeÂ: cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] EnvoyéÂ: mercredi 17 février 2010 23:02 ÃÂ: marte-rtf@omg.org ObjetÂ: Issue #14899 discussion about arrivals and clocks Issue text: Arrivals: The mappings between the analysis arrival patterns (periodic, sporatic, ?)and Time durations, and clock constraints in CCSL should be defined in the specification. Comment by Murray: I dont understand this issue and would like clarification. The arrival processes are an analysis concept describing something imposed on the system, or even generated by another subsystem. They are not prima facie clocks, although since they are event sequences, they have a relationship to clocks. It would be unnatural in my view to require the definition of arrival processes through definitions of clocks. However it would be natural to allow an arrival process to be generated by a clock, which could then incorporate CCSL constraints in the clock definition. The clock could be a GaWorkloadGenerator (see Fig 15.7). GaWorkloadGenerator is defined in 15.3.2.17 as a specialization of Behavior, so it can define the event streams by a behaviour mechanism. This might need to be modified to allow a clock to be a generator. This needs participation of a clock expert. X-IronPort-AV: E=Sophos;i="4.49,503,1262559600"; d="scan'208,217";a="57336511" Date: Fri, 19 Feb 2010 16:30:40 +0100 From: Julien DeAntoni User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100120 Shredder/3.0.1 To: GERARD Sebastien 166342 CC: S.©bastien Demathieu , cmw@sce.carleton.ca, marte-rtf@omg.org Subject: Re: Issue #14899 discussion about arrivals and clocks Séstien, we defined some existing patterns that constraint a clock to behave in a specific manner (for instance sporadic or periodic manner). For example, the definition of the sporadic pattern is def Sporadic(sporadicClock:Clock, timingClock:Clock, dmin:Int){ (sporadicClock delayedFor (dmin) on timingClock) precedes sporadicClock filteredBy 0b0(1); } So it is easily possible to use the sporadic constraint on a clock by binding the parameter of the constraints, for example, in the following c1 is a sporadic clock with a dmin of 3 seconds : Sporadic(c1, idealClk, 3) The idea is to provide such definitions and to show how to use them in examples, in a library or whatever. The way to present this work is still under investigation. The use of template or the UML equivalent of constraint block could perhaps be a solution.. If one of you have any idea.... Séstien, you can have more information on this through the RT-Simex project where we collaborate. julien On 02/19/2010 03:25 PM, GERARD Sebastien 166342 wrote: Julien, Could send me more details on the work you were mentioning in your previous email and related this issue. Thanks, Sé Dr. Séstien Gérd Head of MDD for DRES research project CEA LIST, Laboratoire d.Ingéerie dirigépar les modès pour les Systès Embarqué(LISE) Boî courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -------------------------------------------------------------------------------- De : Séstien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] Envoyé vendredi 19 féier 2010 09:32 À: GERARD Sebastien 166342 Cc : cmw@sce.carleton.ca; Julien.Deantoni@sophia.inria.fr; marte-rtf@omg.org Objet : Re: Issue #14899 discussion about arrivals and clocks Hi all, Removing the arrival patterns was definitively not the intent of this issue. There two possible usages for GaWorkloadEvent in the analysis profiles: either to define an arrival pattern as a VSL expression, or to relate it to a Time::TimedEvent. The issue asks for defining mappings / providing explanations on how these two ways to express similar concepts relate each other. We discussed this during the MARTE meeting in Long Beach and it looked to reasonsable to complete the spec with these mappings. Thanks, Séstien GERARD Sebastien 166342 a éit : About that issue, please remind I did not we have to remove the existing arrival patterns as they are currently defined (this kind of action is definitively out of the scope of the RTF). I suggest only completing them by defining for them a kind of formalization using the clock and CCSL. Cheers... Séstien. Dr. Séstien Gérd Head of MDD for DRES research project CEA, LIST/LISE Boî courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -----Message d'origine----- De : cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] Envoyé jeudi 18 féier 2010 22:45 À: Julien.Deantoni@sophia.inria.fr Cc : GERARD Sebastien 166342; cmw@sce.carleton.ca; marte-rtf@omg.org Objet : RE: Issue #14899 discussion about arrivals and clocks Julien, Sebastien, I have suggested on the GQAM wiki page that a resolution might be to define a clock as a kind of generator of arrivals (generator is already in the prfile). This corresponds to your idea of allowing one to define some kind of clock to generate an arrival pattern. Besides having a library, this would allow a special applicatio specific clock that is part of a system, to be used in an analysis model (this might be a problem to characterize, but it might produce traces). I am not quite sure what haas to be done to the generator concept to allow a clock... I have suggested that the TimeValueSpecification might provide a bridge. Murray Hi Sebastien, What could be done to link both facilities in a more formal way, could be to define in MARTE a kind of formalization of these arrival patterns using (Clocks, CCSL) by defining an equivalent (Clocks, CCSL) model for each arrival patterns. we (INRIA) are currently working on this way. We propose to provide some usefull construct like periodic, a periodic, sporadic arrival thanks to clocks and CCSL. Do you think we could put them in the TimeLibrary ? However, we do not want to express every arrival pattern since some of them are really specific to queuing theory and are not easily suitable to a description based on clocks and CCSL. On the other hand, we could provide some other classical construct used for real time modeling (deadline, responsive time, etc) We do not know if it is usefull, if it should be in the example subsection of the Time section or in the TimeLibrary. Any idea ? @Murray: you should not make a big distinction between clocks and event... Clock is a misleading word since it can reprensent logical clocks. In this case, clock can be used to represent arrival patterns of event occurrences and each instant of a clock correspond to an event occurrence. Best regards, julien What do you think? Best... Sébastien. --------------------------------------------------------------------------- Dr. Sébastien Gérard Head of MDD for DRES research project CEA, LIST/LISE Boîte courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -----Message d'origine----- DeÂ: cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] EnvoyéÂ: mercredi 17 février 2010 23:02 ÃÂ: marte-rtf@omg.org ObjetÂ: Issue #14899 discussion about arrivals and clocks Issue text: Arrivals: The mappings between the analysis arrival patterns (periodic, sporatic, ?)and Time durations, and clock constraints in CCSL should be defined in the specification. Comment by Murray: I dont understand this issue and would like clarification. The arrival processes are an analysis concept describing something imposed on the system, or even generated by another subsystem. They are not prima facie clocks, although since they are event sequences, they have a relationship to clocks. It would be unnatural in my view to require the definition of arrival processes through definitions of clocks. However it would be natural to allow an arrival process to be generated by a clock, which could then incorporate CCSL constraints in the clock definition. The clock could be a GaWorkloadGenerator (see Fig 15.7). GaWorkloadGenerator is defined in 15.3.2.17 as a specialization of Behavior, so it can define the event streams by a behaviour mechanism. This might need to be modified to allow a clock to be a generator. This needs participation of a clock expert. -- Julien DeAntoni Associate Professor INRIA Sophia Antipolis Méterrané2004 rte des Lucioles (Lagrange L-0016) BP93, F-06902 Sophia Antipolis Cedex, France tel: +334 92 38 77 66 http://www-sop.inria.fr/aoste/personnel/Julien.Deantoni/ ----------------------------------- "Nous n'hétons pas de la terre de nos parents, nous l'empruntons àos enfants" - Antoine de Saint Exupé. Date: Fri, 19 Feb 2010 11:57:38 -0500 Subject: Re: Issue #14899 discussion about arrivals and clocks From: cmw@sce.carleton.ca To: Sébastien Demathieu Cc: marte-rtf@omg.org User-Agent: SquirrelMail/1.4.19 Sebastien, I dont see the problem... clearly the pattern description is a higher level of abstraction, giving only a statistical summary of the characteristics of the stream of events, while the TimedEvent description can provide instances of event streams, or generators that can provide instances. On the other hand the pattern description can be used to create a generator (e.g., a random numer generator) which can create samples of TimedEvent event streams. Is this really unclear in the document? Murray > Hi all, > > Removing the arrival patterns was definitively not the intent of this > issue. There two possible usages > for GaWorkloadEvent in the analysis profiles: either to define an > arrival pattern as a VSL expression, > or to relate it to a Time::TimedEvent. > > The issue asks for defining mappings / providing explanations on how > these two ways to express > similar concepts relate each other. > > We discussed this during the MARTE meeting in Long Beach and it looked > to reasonsable to > complete the spec with these mappings. > > Thanks, > > Sébastien > > > > GERARD Sebastien 166342 a écrit : >> About that issue, please remind I did not we have to remove the existing >> arrival patterns as they are currently defined (this kind of action is >> definitively out of the scope of the RTF). I suggest only completing >> them by defining for them a kind of formalization using the clock and >> CCSL. >> >> Cheers... Sébastien. >> >> >> Dr. Sébastien Gérard >> Head of MDD for DRES research project >> CEA, LIST/LISE >> Boîte courrier 94, GIF SUR YVETTE >> CEDEX, F-91191 France >> Phone/fax : +33 1 69 08 58 24 / 83 95 >> Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): >> www.papyrusuml.org >> http://www.eclipse.org/modeling/mdt/?project=papyrus >> >> Before printing, think about the environment >> >> -----Message d'origine----- >> De : cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] >> Envoyé : jeudi 18 février 2010 22:45 >> à : Julien.Deantoni@sophia.inria.fr >> Cc : GERARD Sebastien 166342; cmw@sce.carleton.ca; marte-rtf@omg.org >> Objet : RE: Issue #14899 discussion about arrivals and clocks >> >> >> Julien, Sebastien, >> >> I have suggested on the GQAM wiki page that a resolution might be to >> define a clock as a kind of generator of arrivals (generator is already >> in >> the prfile). This corresponds to your idea of allowing one to define >> some >> kind of clock to generate an arrival pattern. >> >> Besides having a library, this would allow a special applicatio specific >> clock that is part of a system, to be used in an analysis model (this >> might be a problem to characterize, but it might produce traces). >> >> I am not quite sure what haas to be done to the generator concept to >> allow >> a clock... I have suggested that the TimeValueSpecification might >> provide >> a bridge. >> >> Murray >> >> >>> Hi Sebastien, >>> >>> >>>> What could be done to link both facilities in a more formal way, could >>>> be >>>> to define in MARTE a kind of formalization of these arrival patterns >>>> using >>>> (Clocks, CCSL) by defining an equivalent (Clocks, CCSL) model for each >>>> arrival patterns. >>>> >>> we (INRIA) are currently working on this way. We propose to provide >>> some >>> usefull construct like periodic, a periodic, sporadic arrival thanks to >>> clocks and CCSL. Do you think we could put them in the TimeLibrary ? >>> >>> However, we do not want to express every arrival pattern since some of >>> them are really specific to queuing theory and are not easily suitable >>> to >>> a description based on clocks and CCSL. On the other hand, we could >>> provide some other classical construct used for real time modeling >>> (deadline, responsive time, etc) We do not know if it is usefull, if it >>> should be in the example subsection of the Time section or in the >>> TimeLibrary. >>> >>> Any idea ? >>> >>> >>> @Murray: you should not make a big distinction between clocks and >>> event... >>> Clock is a misleading word since it can reprensent logical clocks. In >>> this >>> case, clock can be used to represent arrival patterns of event >>> occurrences >>> and each instant of a clock correspond to an event occurrence. >>> >>> >>> Best regards, >>> >>> julien >>> >>> >>> >>> >>> >>>> What do you think? >>>> >>>> Best... Sébastien. >>>> >>>> --------------------------------------------------------------------------- >>>> Dr. Sébastien Gérard >>>> Head of MDD for DRES research project >>>> CEA, LIST/LISE >>>> Boîte courrier 94, GIF SUR YVETTE >>>> CEDEX, F-91191 France >>>> Phone/fax : +33 1 69 08 58 24 / 83 95 >>>> Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): >>>> www.papyrusuml.org >>>> http://www.eclipse.org/modeling/mdt/?project=papyrus >>>> >>>> Before printing, think about the environment >>>> -----Message d'origine----- >>>> Deà : cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] >>>> Envoyéà : mercredi 17 février 2010 23:02 >>>> Ãâà : marte-rtf@omg.org >>>> Objetà : Issue #14899 discussion about arrivals and clocks >>>> >>>> Issue text: Arrivals: The mappings between the analysis arrival >>>> patterns >>>> (periodic, sporatic, ?)and Time durations, and clock constraints >>>> in >>>> CCSL should be defined in the specification. >>>> >>>> Comment by Murray: >>>> I dont understand this issue and would like clarification. The arrival >>>> processes are an analysis concept describing something imposed on the >>>> system, or even generated by another subsystem. They are not prima >>>> facie >>>> clocks, although since they are event sequences, they have a >>>> relationship >>>> to clocks. >>>> >>>> It would be unnatural in my view to require the definition of arrival >>>> processes through definitions of clocks. However it would be natural >>>> to >>>> allow an arrival process to be generated by a clock, which could then >>>> incorporate CCSL constraints in the clock definition. The clock could >>>> be >>>> a GaWorkloadGenerator (see Fig 15.7). >>>> >>>> GaWorkloadGenerator is defined in 15.3.2.17 as a specialization of >>>> Behavior, so it can define the event streams by a behaviour mechanism. >>>> This might need to be modified to allow a clock to be a generator. >>>> This >>>> needs participation of a clock expert. >>>> >>>> >>>> >>>> >>> >> >> >> >Date: Fri, 19 Feb 2010 12:03:50 -0500 Subject: RE: Issue #14899 discussion about arrivals and clocks From: cmw@sce.carleton.ca To: "GERARD Sebastien 166342" Cc: cmw@sce.carleton.ca, julien.deantoni@sophia.inria.fr, marte-rtf@omg.org User-Agent: SquirrelMail/1.4.19 I think it would be a mistake to formalize for instance a Poisson process (exponential inter-arrival times), as a clock. There are many ways such a process may arise, for instance in the merging of very many independent event streams of any description whatever, there is a kind of central limit showing a convergence to a Poisson process. However there is no one mechanism. A clock for this would have no more information in it than the statistical description of the poisson process in the first place. The arrival process descriptions are at a different level of abstraction from the clocks. One could define a clock that is capable of producing a Poisson process, but it woudl restrict the definition. Murray > About that issue, please remind I did not we have to remove the existing > arrival patterns as they are currently defined (this kind of action is > definitively out of the scope of the RTF). I suggest only completing them > by defining for them a kind of formalization using the clock and CCSL. > > Cheers... Sébastien. > > > Dr. Sébastien Gérard > Head of MDD for DRES research project > CEA, LIST/LISE > Boîte courrier 94, GIF SUR YVETTE > CEDEX, F-91191 France > Phone/fax : +33 1 69 08 58 24 / 83 95 > Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): > www.papyrusuml.org > http://www.eclipse.org/modeling/mdt/?project=papyrus > > Before printing, think about the environment > > -----Message d'origine----- > DeÂ: cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] > EnvoyéÂ: jeudi 18 février 2010 22:45 > ÃÂ: Julien.Deantoni@sophia.inria.fr > CcÂ: GERARD Sebastien 166342; cmw@sce.carleton.ca; marte-rtf@omg.org > ObjetÂ: RE: Issue #14899 discussion about arrivals and clocks > > > Julien, Sebastien, > > I have suggested on the GQAM wiki page that a resolution might be to > define a clock as a kind of generator of arrivals (generator is already > in > the prfile). This corresponds to your idea of allowing one to define some > kind of clock to generate an arrival pattern. > > Besides having a library, this would allow a special applicatio specific > clock that is part of a system, to be used in an analysis model (this > might be a problem to characterize, but it might produce traces). > > I am not quite sure what haas to be done to the generator concept to > allow > a clock... I have suggested that the TimeValueSpecification might provide > a bridge. > > Murray > >> Hi Sebastien, >> >>> What could be done to link both facilities in a more formal way, could >>> be >>> to define in MARTE a kind of formalization of these arrival patterns >>> using >>> (Clocks, CCSL) by defining an equivalent (Clocks, CCSL) model for each >>> arrival patterns. >> >> >> we (INRIA) are currently working on this way. We propose to provide >> some >> usefull construct like periodic, a periodic, sporadic arrival thanks to >> clocks and CCSL. Do you think we could put them in the TimeLibrary ? >> >> However, we do not want to express every arrival pattern since some of >> them are really specific to queuing theory and are not easily suitable >> to >> a description based on clocks and CCSL. On the other hand, we could >> provide some other classical construct used for real time modeling >> (deadline, responsive time, etc) We do not know if it is usefull, if it >> should be in the example subsection of the Time section or in the >> TimeLibrary. >> >> Any idea ? >> >> >> @Murray: you should not make a big distinction between clocks and >> event... >> Clock is a misleading word since it can reprensent logical clocks. In >> this >> case, clock can be used to represent arrival patterns of event >> occurrences >> and each instant of a clock correspond to an event occurrence. >> >> >> Best regards, >> >> julien >> >> >> >> >>> >>> What do you think? >>> >>> Best... Sébastien. >>> >>> --------------------------------------------------------------------------- >>> Dr. Sébastien Gérard >>> Head of MDD for DRES research project >>> CEA, LIST/LISE >>> Boîte courrier 94, GIF SUR YVETTE >>> CEDEX, F-91191 France >>> Phone/fax : +33 1 69 08 58 24 / 83 95 >>> Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): >>> www.papyrusuml.org >>> http://www.eclipse.org/modeling/mdt/?project=papyrus >>> >>> Before printing, think about the environment >>> -----Message d'origine----- >>> DeÃÂ: cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] >>> EnvoyéÃÂ: mercredi 17 février 2010 23:02 >>> ÃâÃÂ: marte-rtf@omg.org >>> ObjetÃÂ: Issue #14899 discussion about arrivals and clocks >>> >>> Issue text: Arrivals: The mappings between the analysis arrival >>> patterns >>> (periodic, sporatic, ?)and Time durations, and clock constraints >>> in >>> CCSL should be defined in the specification. >>> >>> Comment by Murray: >>> I dont understand this issue and would like clarification. The arrival >>> processes are an analysis concept describing something imposed on the >>> system, or even generated by another subsystem. They are not prima >>> facie >>> clocks, although since they are event sequences, they have a >>> relationship >>> to clocks. >>> >>> It would be unnatural in my view to require the definition of arrival >>> processes through definitions of clocks. However it would be natural >>> to >>> allow an arrival process to be generated by a clock, which could then >>> incorporate CCSL constraints in the clock definition. The clock could >>> be >>> a GaWorkloadGenerator (see Fig 15.7). >>> >>> GaWorkloadGenerator is defined in 15.3.2.17 as a specialization of >>> Behavior, so it can define the event streams by a behaviour mechanism. >>> This might need to be modified to allow a clock to be a generator. >>> This >>> needs participation of a clock expert. >>> >>> >>> >> >> > > From: "Peter Kortmann" To: "'GERARD Sebastien 166342'" , , Cc: , Subject: RE: Issue #14899 discussion about arrivals and clocks Date: Fri, 19 Feb 2010 16:15:15 -0800 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqw46TzYIAfPZDVQWmFMNeOHhy+ZgABvnIwADUxcZA= X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o1K07soo030842 Hi All. Mark Gerhardt and I had a few comments described below. We basically agree with Murray as he describes Arrival Patterns. Timing constraints are applied either to a specific event (when an absolute time is specified) or between two events when a duration is specified (such as the characterization of a periodically occurring event). In each case the attribute is a specific value instance of a time-defined type. Whether or not the origination of an event fulfilling the timing attribution specified is implemented by a clock is an implementation issue. We have used the MARTE profile and its arrival patterns to specify the causality for execution of threads. We have used the various occurrence patterns to express the desired causality semantics whether they are periodic or sporadic in nature. In either case, the specific discussion of clock implementation specifics are not necessary to express the desired timing constraints for deadlines, throughput, and execution causality. Formalizing the semantics of absolute time, relative time, duration and their associated units of measure as well as how to associate them with one or more specific events in UML behavior is certainly necessary. It is not necessary that the formalization be in terms of clocks. As a historical example, Ada95 had a package calendar which specified many kinds of timing units without formal reference to clocks. The interpretation of a timer being set to expire after an interval can be treated as the expression of a duration between the set event and the expire event for the timer. Many commercial operating systems bind these actions to clock instances. If the purpose of the timing specification is to express value constraints and to perform relevant timing analysis, the mechanism of clocks is unnecessary. Regards. Peter and Mark -----Original Message----- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Thursday, February 18, 2010 2:37 PM To: cmw@sce.carleton.ca; Julien.Deantoni@sophia.inria.fr Cc: marte-rtf@omg.org Subject: RE: Issue #14899 discussion about arrivals and clocks About that issue, please remind I did not we have to remove the existing arrival patterns as they are currently defined (this kind of action is definitively out of the scope of the RTF). I suggest only completing them by defining for them a kind of formalization using the clock and CCSL. Cheers... Sbastien. Dr. Sbastien Grard Head of MDD for DRES research project CEA, LIST/LISE Bote courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -----Message d'origine----- De: cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] Envoy: jeudi 18 fvrier 2010 22:45 : Julien.Deantoni@sophia.inria.fr Cc: GERARD Sebastien 166342; cmw@sce.carleton.ca; marte-rtf@omg.org Objet: RE: Issue #14899 discussion about arrivals and clocks Julien, Sebastien, I have suggested on the GQAM wiki page that a resolution might be to define a clock as a kind of generator of arrivals (generator is already in the prfile). This corresponds to your idea of allowing one to define some kind of clock to generate an arrival pattern. Besides having a library, this would allow a special applicatio specific clock that is part of a system, to be used in an analysis model (this might be a problem to characterize, but it might produce traces). I am not quite sure what haas to be done to the generator concept to allow a clock... I have suggested that the TimeValueSpecification might provide a bridge. Murray > Hi Sebastien, > >> What could be done to link both facilities in a more formal way, could >> be >> to define in MARTE a kind of formalization of these arrival patterns >> using >> (Clocks, CCSL) by defining an equivalent (Clocks, CCSL) model for each >> arrival patterns. > > > we (INRIA) are currently working on this way. We propose to provide some > usefull construct like periodic, a periodic, sporadic arrival thanks to > clocks and CCSL. Do you think we could put them in the TimeLibrary ? > > However, we do not want to express every arrival pattern since some of > them are really specific to queuing theory and are not easily suitable to > a description based on clocks and CCSL. On the other hand, we could > provide some other classical construct used for real time modeling > (deadline, responsive time, etc) We do not know if it is usefull, if it > should be in the example subsection of the Time section or in the > TimeLibrary. > > Any idea ? > > > @Murray: you should not make a big distinction between clocks and event... > Clock is a misleading word since it can reprensent logical clocks. In this > case, clock can be used to represent arrival patterns of event occurrences > and each instant of a clock correspond to an event occurrence. > > > Best regards, > > julien > > > > >> >> What do you think? >> >> Best... Sébastien. >> >> --------------------------------------------------------------------------- >> Dr. Sébastien Gérard >> Head of MDD for DRES research project >> CEA, LIST/LISE >> Boîte courrier 94, GIF SUR YVETTE >> CEDEX, F-91191 France >> Phone/fax : +33 1 69 08 58 24 / 83 95 >> Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): >> www.papyrusuml.org >> http://www.eclipse.org/modeling/mdt/?project=papyrus >> >> Before printing, think about the environment >> -----Message d'origine----- >> De : cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] >> Envoyé : mercredi 17 février 2010 23:02 >> à : marte-rtf@omg.org >> Objet : Issue #14899 discussion about arrivals and clocks >> >> Issue text: Arrivals: The mappings between the analysis arrival patterns >> (periodic, sporatic, ?)and Time durations, and clock constraints >> in >> CCSL should be defined in the specification. >> >> Comment by Murray: >> I dont understand this issue and would like clarification. The arrival >> processes are an analysis concept describing something imposed on the >> system, or even generated by another subsystem. They are not prima facie >> clocks, although since they are event sequences, they have a >> relationship >> to clocks. >> >> It would be unnatural in my view to require the definition of arrival >> processes through definitions of clocks. However it would be natural to >> allow an arrival process to be generated by a clock, which could then >> incorporate CCSL constraints in the clock definition. The clock could be >> a GaWorkloadGenerator (see Fig 15.7). >> >> GaWorkloadGenerator is defined in 15.3.2.17 as a specialization of >> Behavior, so it can define the event streams by a behaviour mechanism. >> This might need to be modified to allow a clock to be a generator. This >> needs participation of a clock expert. >> >> >> > >Date: Thu, 25 Feb 2010 09:33:35 +0100 From: Séstien Demathieu Organization: Thales Research & Technology User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: cmw@sce.carleton.ca CC: GERARD Sebastien 166342 , julien.deantoni@sophia.inria.fr, marte-rtf@omg.org Subject: Re: Issue #14899 discussion about arrivals and clocks Murray, I agree that not all the arrival patterns can be formalized using the Time model. In the cases that you describe below, it is just not even useful or appropriate. However, if some other arrival patterns (periodic, sporadic) could formalized in such a way, then it would be a useful piece of information and it will enforce consistency between these different parts of the specification. Thanks, Séstien cmw@sce.carleton.ca a éit : I think it would be a mistake to formalize for instance a Poisson process (exponential inter-arrival times), as a clock. There are many ways such a process may arise, for instance in the merging of very many independent event streams of any description whatever, there is a kind of central limit showing a convergence to a Poisson process. However there is no one mechanism. A clock for this would have no more information in it than the statistical description of the poisson process in the first place. The arrival process descriptions are at a different level of abstraction from the clocks. One could define a clock that is capable of producing a Poisson process, but it woudl restrict the definition. Murray About that issue, please remind I did not we have to remove the existing arrival patterns as they are currently defined (this kind of action is definitively out of the scope of the RTF). I suggest only completing them by defining for them a kind of formalization using the clock and CCSL. Cheers... Sébastien. Dr. Sébastien Gérard Head of MDD for DRES research project CEA, LIST/LISE Boîte courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -----Message d'origine----- DeÂ: cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] EnvoyéÂ: jeudi 18 février 2010 22:45 ÃÂ: Julien.Deantoni@sophia.inria.fr CcÂ: GERARD Sebastien 166342; cmw@sce.carleton.ca; marte-rtf@omg.org ObjetÂ: RE: Issue #14899 discussion about arrivals and clocks Julien, Sebastien, I have suggested on the GQAM wiki page that a resolution might be to define a clock as a kind of generator of arrivals (generator is already in the prfile). This corresponds to your idea of allowing one to define some kind of clock to generate an arrival pattern. Besides having a library, this would allow a special applicatio specific clock that is part of a system, to be used in an analysis model (this might be a problem to characterize, but it might produce traces). I am not quite sure what haas to be done to the generator concept to allow a clock... I have suggested that the TimeValueSpecification might provide a bridge. Murray Hi Sebastien, What could be done to link both facilities in a more formal way, could be to define in MARTE a kind of formalization of these arrival patterns using (Clocks, CCSL) by defining an equivalent (Clocks, CCSL) model for each arrival patterns. we (INRIA) are currently working on this way. We propose to provide some usefull construct like periodic, a periodic, sporadic arrival thanks to clocks and CCSL. Do you think we could put them in the TimeLibrary ? However, we do not want to express every arrival pattern since some of them are really specific to queuing theory and are not easily suitable to a description based on clocks and CCSL. On the other hand, we could provide some other classical construct used for real time modeling (deadline, responsive time, etc) We do not know if it is usefull, if it should be in the example subsection of the Time section or in the TimeLibrary. Any idea ? @Murray: you should not make a big distinction between clocks and event... Clock is a misleading word since it can reprensent logical clocks. In this case, clock can be used to represent arrival patterns of event occurrences and each instant of a clock correspond to an event occurrence. Best regards, julien What do you think? Best... Sébastien. --------------------------------------------------------------------------- Dr. Sébastien Gérard Head of MDD for DRES research project CEA, LIST/LISE Boîte courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -----Message d'origine----- DeÃÂ: cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] EnvoyéÃÂ: mercredi 17 février 2010 23:02 ÃâÃÂ: marte-rtf@omg.org ObjetÃÂ: Issue #14899 discussion about arrivals and clocks Issue text: Arrivals: The mappings between the analysis arrival patterns (periodic, sporatic, ?)and Time durations, and clock constraints in CCSL should be defined in the specification. Comment by Murray: I dont understand this issue and would like clarification. The arrival processes are an analysis concept describing something imposed on the system, or even generated by another subsystem. They are not prima facie clocks, although since they are event sequences, they have a relationship to clocks. It would be unnatural in my view to require the definition of arrival processes through definitions of clocks. However it would be natural to allow an arrival process to be generated by a clock, which could then incorporate CCSL constraints in the clock definition. The clock could be a GaWorkloadGenerator (see Fig 15.7). GaWorkloadGenerator is defined in 15.3.2.17 as a specialization of Behavior, so it can define the event streams by a behaviour mechanism. This might need to be modified to allow a clock to be a generator. This needs participation of a clock expert. sebastien_demathieu.vcf X-IronPort-AV: E=Sophos;i="4.49,538,1262559600"; d="scan'208";a="45565321" Date: Thu, 25 Feb 2010 11:43:32 +0100 From: Frederic Mallet User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Séstien Demathieu CC: cmw@sce.carleton.ca, GERARD Sebastien 166342 , julien.deantoni@sophia.inria.fr, marte-rtf@omg.org Subject: Re: Issue #14899 discussion about arrivals and clocks Hi all, I think what Murray and Peter meant is that it should not be described has been *THE* way to formalize the arrival patterns, and therefore it should not be in the analysis part. Arrival Patterns (even Periodic) can be characterized without using clocks and without making explicit a generation mechanism. I am not sure whether it can be in the time chapter either if we want to avoid forward references (or it has to be as several examples). We can probably present this as a library, where we show some typical real-time constraints that can be described with the time model and its clocks: periodic, sporadic, burst, deadline, ... And a reference to the analysis part, saying this is one way to generate the pattern even though in several analysis contexts there is no particular need for making explicit the generation mechanisms while in the design you sometimes want to enforce it. It can serve also to make some links with NFP and VSL by showing how the clocks can model the non-functional aspects covered by NFP but also some functional aspects as advocated by the theory of concurrency. Frederic Séstien Demathieu a éit : Murray, I agree that not all the arrival patterns can be formalized using the Time model. In the cases that you describe below, it is just not even useful or appropriate. However, if some other arrival patterns (periodic, sporadic) could formalized in such a way, then it would be a useful piece of information and it will enforce consistency between these different parts of the specification. Thanks, Séstien cmw@sce.carleton.ca a éit : I think it would be a mistake to formalize for instance a Poisson process (exponential inter-arrival times), as a clock. There are many ways such a process may arise, for instance in the merging of very many independent event streams of any description whatever, there is a kind of central limit showing a convergence to a Poisson process. However there is no one mechanism. A clock for this would have no more information in it than the statistical description of the poisson process in the first place. The arrival process descriptions are at a different level of abstraction from the clocks. One could define a clock that is capable of producing a Poisson process, but it woudl restrict the definition. Murray About that issue, please remind I did not we have to remove the existing arrival patterns as they are currently defined (this kind of action is definitively out of the scope of the RTF). I suggest only completing them by defining for them a kind of formalization using the clock and CCSL. Cheers... Sébastien. Dr. Sébastien Gérard Head of MDD for DRES research project CEA, LIST/LISE Boîte courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -----Message d'origine----- DeÂ: cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] EnvoyéÂ: jeudi 18 février 2010 22:45 ÃÂ: Julien.Deantoni@sophia.inria.fr CcÂ: GERARD Sebastien 166342; cmw@sce.carleton.ca; marte-rtf@omg.org ObjetÂ: RE: Issue #14899 discussion about arrivals and clocks Julien, Sebastien, I have suggested on the GQAM wiki page that a resolution might be to define a clock as a kind of generator of arrivals (generator is already in the prfile). This corresponds to your idea of allowing one to define some kind of clock to generate an arrival pattern. Besides having a library, this would allow a special applicatio specific clock that is part of a system, to be used in an analysis model (this might be a problem to characterize, but it might produce traces). I am not quite sure what haas to be done to the generator concept to allow a clock... I have suggested that the TimeValueSpecification might provide a bridge. Murray Hi Sebastien, What could be done to link both facilities in a more formal way, could be to define in MARTE a kind of formalization of these arrival patterns using (Clocks, CCSL) by defining an equivalent (Clocks, CCSL) model for each arrival patterns. we (INRIA) are currently working on this way. We propose to provide some usefull construct like periodic, a periodic, sporadic arrival thanks to clocks and CCSL. Do you think we could put them in the TimeLibrary ? However, we do not want to express every arrival pattern since some of them are really specific to queuing theory and are not easily suitable to a description based on clocks and CCSL. On the other hand, we could provide some other classical construct used for real time modeling (deadline, responsive time, etc) We do not know if it is usefull, if it should be in the example subsection of the Time section or in the TimeLibrary. Any idea ? @Murray: you should not make a big distinction between clocks and event... Clock is a misleading word since it can reprensent logical clocks. In this case, clock can be used to represent arrival patterns of event occurrences and each instant of a clock correspond to an event occurrence. Best regards, julien What do you think? Best... Sébastien. --------------------------------------------------------------------------- Dr. Sébastien Gérard Head of MDD for DRES research project CEA, LIST/LISE Boîte courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -----Message d'origine----- DeÃÂ: cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] EnvoyéÃÂ: mercredi 17 février 2010 23:02 ÃâÃÂ: marte-rtf@omg.org ObjetÃÂ: Issue #14899 discussion about arrivals and clocks Issue text: Arrivals: The mappings between the analysis arrival patterns (periodic, sporatic, ?)and Time durations, and clock constraints in CCSL should be defined in the specification. Comment by Murray: I dont understand this issue and would like clarification. The arrival processes are an analysis concept describing something imposed on the system, or even generated by another subsystem. They are not prima facie clocks, although since they are event sequences, they have a relationship to clocks. It would be unnatural in my view to require the definition of arrival processes through definitions of clocks. However it would be natural to allow an arrival process to be generated by a clock, which could then incorporate CCSL constraints in the clock definition. The clock could be a GaWorkloadGenerator (see Fig 15.7). GaWorkloadGenerator is defined in 15.3.2.17 as a specialization of Behavior, so it can define the event streams by a behaviour mechanism. This might need to be modified to allow a clock to be a generator. This needs participation of a clock expert. Date: Thu, 25 Feb 2010 10:14:27 -0500 (EST) From: Murray Woodside Reply-To: cmw@sce.carleton.ca To: Frederic Mallet cc: Séstien Demathieu , GERARD Sebastien 166342 , julien.deantoni@sophia.inria.fr, marte-rtf@omg.org Subject: Re: Issue #14899 discussion about arrivals and clocks User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) Frederic, Sebastien, I think maybe the idea to support a clock as a workload generator could be ideal bridge between the two specifications. Perhaps we can think together, how to do this. I think the best appraoch would be to identify the clock output (the event stream) as an event stream input for WorkloadEvent. What stereotype would this be, for best generality? Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Thu, 25 Feb 2010, Frederic Mallet wrote: Hi all, I think what Murray and Peter meant is that it should not be described has been *THE* way to formalize the arrival patterns, and therefore it should not be in the analysis part. Arrival Patterns (even Periodic) can be characterized without using clocks and without making explicit a generation mechanism. I am not sure whether it can be in the time chapter either if we want to avoid forward references (or it has to be as several examples). We can probably present this as a library, where we show some typical real-time constraints that can be described with the time model and its clocks: periodic, sporadic, burst, deadline, ... And a reference to the analysis part, saying this is one way to generate the pattern even though in several analysis contexts there is no particular need for making explicit the generation mechanisms while in the design you sometimes want to enforce it. It can serve also to make some links with NFP and VSL by showing how the clocks can model the non-functional aspects covered by NFP but also some functional aspects as advocated by the theory of concurrency. Frederic Séstien Demathieu a éit : Murray, I agree that not all the arrival patterns can be formalized using the Time model. In the cases that you describe below, it is just not even useful or appropriate. However, if some other arrival patterns (periodic, sporadic) could formalized in such a way, then it would be a useful piece of information and it will enforce consistency between these different parts of the specification. Thanks, Séstien cmw@sce.carleton.ca a éit : I think it would be a mistake to formalize for instance a Poisson process (exponential inter-arrival times), as a clock. There are many ways such a process may arise, for instance in the merging of very many independent event streams of any description whatever, there is a kind of central limit showing a convergence to a Poisson process. However there is no one mechanism. A clock for this would have no more information in it than the statistical description of the poisson process in the first place. The arrival process descriptions are at a different level of abstraction from the clocks. One could define a clock that is capable of producing a Poisson process, but it woudl restrict the definition. Murray About that issue, please remind I did not we have to remove the existing arrival patterns as they are currently defined (this kind of action is definitively out of the scope of the RTF). I suggest only completing them by defining for them a kind of formalization using the clock and CCSL. Cheers... Sébastien. Dr. Sébastien Gérard Head of MDD for DRES research project CEA, LIST/LISE Boîte courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -----Message d'origine----- DeÂ: cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] EnvoyéÂ: jeudi 18 février 2010 22:45 ÃÂ: Julien.Deantoni@sophia.inria.fr CcÂ: GERARD Sebastien 166342; cmw@sce.carleton.ca; marte-rtf@omg.org ObjetÂ: RE: Issue #14899 discussion about arrivals and clocks Julien, Sebastien, I have suggested on the GQAM wiki page that a resolution might be to define a clock as a kind of generator of arrivals (generator is already in the prfile). This corresponds to your idea of allowing one to define some kind of clock to generate an arrival pattern. Besides having a library, this would allow a special applicatio specific clock that is part of a system, to be used in an analysis model (this might be a problem to characterize, but it might produce traces). I am not quite sure what haas to be done to the generator concept to allow a clock... I have suggested that the TimeValueSpecification might provide a bridge. Murray Hi Sebastien, What could be done to link both facilities in a more formal way, could be to define in MARTE a kind of formalization of these arrival patterns using (Clocks, CCSL) by defining an equivalent (Clocks, CCSL) model for each arrival patterns. we (INRIA) are currently working on this way. We propose to provide some usefull construct like periodic, a periodic, sporadic arrival thanks to clocks and CCSL. Do you think we could put them in the TimeLibrary ? However, we do not want to express every arrival pattern since some of them are really specific to queuing theory and are not easily suitable to a description based on clocks and CCSL. On the other hand, we could provide some other classical construct used for real time modeling (deadline, responsive time, etc) We do not know if it is usefull, if it should be in the example subsection of the Time section or in the TimeLibrary. Any idea ? @Murray: you should not make a big distinction between clocks and event... Clock is a misleading word since it can reprensent logical clocks. In this case, clock can be used to represent arrival patterns of event occurrences and each instant of a clock correspond to an event occurrence. Best regards, julien What do you think? Best... Sébastien. --------------------------------------------------------------------------- Dr. Sébastien Gérard Head of MDD for DRES research project CEA, LIST/LISE Boîte courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -----Message d'origine----- DeÃÂ: cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] EnvoyéÃÂ: mercredi 17 février 2010 23:02 ÃâÃÂ: marte-rtf@omg.org ObjetÃÂ: Issue #14899 discussion about arrivals and clocks Issue text: Arrivals: The mappings between the analysis arrival patterns (periodic, sporatic, ?)and Time durations, and clock constraints in CCSL should be defined in the specification. Comment by Murray: I dont understand this issue and would like clarification. The arrival processes are an analysis concept describing something imposed on the system, or even generated by another subsystem. They are not prima facie clocks, although since they are event sequences, they have a relationship to clocks. It would be unnatural in my view to require the definition of arrival processes through definitions of clocks. However it would be natural to allow an arrival process to be generated by a clock, which could then incorporate CCSL constraints in the clock definition. The clock could be a GaWorkloadGenerator (see Fig 15.7). GaWorkloadGenerator is defined in 15.3.2.17 as a specialization of Behavior, so it can define the event streams by a behaviour mechanism. This might need to be modified to allow a clock to be a generator. This needs participation of a clock expert. Subject: RE: Issue #14899 discussion about arrivals and clocks Date: Thu, 25 Feb 2010 16:32:08 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #14899 discussion about arrivals and clocks Thread-Index: Acq2LhXR6OMwyJoCRS6NNv7pGXe/IAAABbXA From: "Huascar Espinoza" To: , "Frederic Mallet" Cc: Sébastien Demathieu , "GERARD Sebastien 166342" , , X-ESI-MailScanner-Information: Please contact the ISP for more information X-ESI-MailScanner: Found to be clean X-ESI-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-2.901, required 3, autolearn=not spam, AWL 0.10, BAYES_00 -3.00) X-MailScanner-From: huascar.espinoza@esi.es X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id o1PFTfk2010409 Hi Murray, I guess that, as Julien said, there is a misunderstanding on the meaning of Clock, as a logical concept being capable of specifying an event pattern, and the clock mechanism. As far as I understand, the issue is looking at mapping the two ways of specifying those event patterns that MARTE supports. One which is more declarative, as Séb said, defined in the Analysis chapters, and the other based on the clock specification formalism supported by the Time chapter and CCSL. >From my perspective, it's just to provide the (semantic) mapping in some place of the MARTE spec. (I would prefer to do it in some section of the Annex). I might be wrong, but I don't see the need to connect the clock output to nothing. This is just my interpretation Huascar -----Original Message----- From: Murray Woodside [mailto:cmw@sce.carleton.ca] Sent: jueves, 25 de febrero de 2010 16:14 To: Frederic Mallet Cc: Sébastien Demathieu; GERARD Sebastien 166342; julien.deantoni@sophia.inria.fr; marte-rtf@omg.org Subject: Re: Issue #14899 discussion about arrivals and clocks Frederic, Sebastien, I think maybe the idea to support a clock as a workload generator could be ideal bridge between the two specifications. Perhaps we can think together, how to do this. I think the best appraoch would be to identify the clock output (the event stream) as an event stream input for WorkloadEvent. What stereotype would this be, for best generality? Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Thu, 25 Feb 2010, Frederic Mallet wrote: > Hi all, > I think what Murray and Peter meant is that it should not be described > has been *THE* way to formalize the arrival patterns, and therefore it > should not be in the analysis part. Arrival Patterns (even Periodic) > can be characterized without using clocks and without making explicit > a generation mechanism. > I am not sure whether it can be in the time chapter either if we want > to avoid forward references (or it has to be as several examples). > > We can probably present this as a library, where we show some typical > real-time constraints that can be described with the time model and > its > clocks: periodic, sporadic, burst, deadline, ... > And a reference to the analysis part, saying this is one way to > generate the pattern even though in several analysis contexts there is > no particular need for making explicit the generation mechanisms while > in the design you sometimes want to enforce it. > It can serve also to make some links with NFP and VSL by showing how > the clocks can model the non-functional aspects covered by NFP but > also some functional aspects as advocated by the theory of concurrency. > > Frederic > > Sébastien Demathieu a écrit : >> Murray, >> >> I agree that not all the arrival patterns can be formalized using the >> Time model. In the cases that you describe below, it is just not even >> useful or appropriate. >> >> However, if some other arrival patterns (periodic, sporadic) could >> formalized in such a way, then it would be a useful piece of >> information and it will enforce consistency between these different >> parts of the specification. >> >> Thanks, >> >> Sébastien >> >> >> cmw@sce.carleton.ca a écrit : >>> I think it would be a mistake to formalize for instance a Poisson >>> process (exponential inter-arrival times), as a clock. There are >>> many ways such a process may arise, for instance in the merging of >>> very many independent event streams of any description whatever, >>> there is a kind of central limit showing a convergence to a Poisson >>> process. However there is no one mechanism. A clock for this would >>> have no more information in it than the statistical description of the poisson process in the first place. >>> >>> The arrival process descriptions are at a different level of >>> abstraction from the clocks. One could define a clock that is >>> capable of producing a Poisson process, but it woudl restrict the definition. >>> >>> Murray >>> >>> >>>> About that issue, please remind I did not we have to remove the >>>> existing arrival patterns as they are currently defined (this kind >>>> of action is definitively out of the scope of the RTF). I suggest >>>> only completing them by defining for them a kind of formalization using the clock and CCSL. >>>> >>>> Cheers... Sébastien. >>>> >>>> >>>> Dr. Sébastien Gérard >>>> Head of MDD for DRES research project CEA, LIST/LISE Boîte >>>> courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 >>>> 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The >>>> UML2 Graphical Modeler): >>>> www.papyrusuml.org >>>> http://www.eclipse.org/modeling/mdt/?project=papyrus >>>> >>>> Before printing, think about the environment >>>> >>>> -----Message d'origine----- >>>> Deà : cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] Envoyéà : >>>> jeudi 18 février 2010 22:45 Ã.à : Julien.Deantoni@sophia.inria.fr >>>> Ccà : GERARD Sebastien 166342; cmw@sce.carleton.ca; >>>> marte-rtf@omg.org Objetà : RE: Issue #14899 discussion about >>>> arrivals and clocks >>>> >>>> >>>> Julien, Sebastien, >>>> >>>> I have suggested on the GQAM wiki page that a resolution might be >>>> to define a clock as a kind of generator of arrivals (generator is >>>> already in the prfile). This corresponds to your idea of allowing >>>> one to define some kind of clock to generate an arrival pattern. >>>> >>>> Besides having a library, this would allow a special applicatio >>>> specific clock that is part of a system, to be used in an analysis >>>> model (this might be a problem to characterize, but it might produce traces). >>>> >>>> I am not quite sure what haas to be done to the generator concept >>>> to allow a clock... I have suggested that the >>>> TimeValueSpecification might provide a bridge. >>>> >>>> Murray >>>> >>>> >>>>> Hi Sebastien, >>>>> >>>>> >>>>>> What could be done to link both facilities in a more formal way, >>>>>> could be to define in MARTE a kind of formalization of these >>>>>> arrival patterns using (Clocks, CCSL) by defining an equivalent >>>>>> (Clocks, CCSL) model for each arrival patterns. >>>>>> >>>>> we (INRIA) are currently working on this way. We propose to >>>>> provide some usefull construct like periodic, a periodic, sporadic >>>>> arrival thanks to clocks and CCSL. Do you think we could put them >>>>> in the TimeLibrary ? >>>>> >>>>> However, we do not want to express every arrival pattern since >>>>> some of them are really specific to queuing theory and are not >>>>> easily suitable to a description based on clocks and CCSL. On the >>>>> other hand, we could provide some other classical construct used >>>>> for real time modeling (deadline, responsive time, etc) We do not >>>>> know if it is usefull, if it should be in the example subsection >>>>> of the Time section or in the TimeLibrary. >>>>> >>>>> Any idea ? >>>>> >>>>> >>>>> @Murray: you should not make a big distinction between clocks and >>>>> event... >>>>> Clock is a misleading word since it can reprensent logical clocks. >>>>> In this case, clock can be used to represent arrival patterns of >>>>> event occurrences and each instant of a clock correspond to an >>>>> event occurrence. >>>>> >>>>> >>>>> Best regards, >>>>> >>>>> julien >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> What do you think? >>>>>> >>>>>> Best... S̮̩bastien. >>>>>> >>>>>> >>>>>> ----------------------------------------------------------------- >>>>>> ---------- >>>>>> Dr. S̮̩bastien G̮̩rard >>>>>> Head of MDD for DRES research project CEA, LIST/LISE Bǫ̮te >>>>>> courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 >>>>>> 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus >>>>>> (The UML2 Graphical Modeler): >>>>>> www.papyrusuml.org >>>>>> http://www.eclipse.org/modeling/mdt/?project=papyrus >>>>>> >>>>>> Before printing, think about the environment -----Message >>>>>> d'origine----- DeÃ.à : cmw@sce.carleton.ca >>>>>> [mailto:cmw@sce.carleton.ca] EnvoyÃÆéÃ.à : mercredi 17 >>>>>> f̮̩vrier 2010 23:02 ÃÆâ.¬Ã.à : marte-rtf@omg.org ObjetÃ.à : : >>>>>> Issue #14899 discussion about arrivals and clocks >>>>>> >>>>>> Issue text: Arrivals: The mappings between the analysis arrival >>>>>> patterns >>>>>> (periodic, sporatic, ?)and Time durations, and clock constraints >>>>>> in >>>>>> CCSL should be defined in the specification. >>>>>> >>>>>> Comment by Murray: >>>>>> I dont understand this issue and would like clarification. The >>>>>> arrival processes are an analysis concept describing something >>>>>> imposed on the system, or even generated by another subsystem. >>>>>> They are not prima facie clocks, although since they are event >>>>>> sequences, they have a relationship to clocks. >>>>>> >>>>>> It would be unnatural in my view to require the definition of >>>>>> arrival processes through definitions of clocks. However it would >>>>>> be natural to allow an arrival process to be generated by a >>>>>> clock, which could then incorporate CCSL constraints in the clock >>>>>> definition. The clock could be a GaWorkloadGenerator (see Fig >>>>>> 15.7). >>>>>> >>>>>> GaWorkloadGenerator is defined in 15.3.2.17 as a specialization >>>>>> of Behavior, so it can define the event streams by a behaviour mechanism. >>>>>> This might need to be modified to allow a clock to be a generator. >>>>>> This >>>>>> needs participation of a clock expert. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >>> >>> > > ********************************** DISCLAIMER ******************************* This message may contain confidential, proprietary or legally privileged information. If you are not the intended recipient of this message, please notify it to the sender and delete without resending or backing it, as it is legally prohibited. ********************************** AVISO LEGAL ****************************** Este mensaje puede contener informacióonfidencial, en propiedad o legalmente protegida. Si usted no es el destinatario, le rogamos lo comunique al remitente y proceda a borrarlo, sin reenviarlo ni conservarlo, ya que su uso no autorizado estárohibido legalmente. ****************************************************************************** X-IronPort-AV: E=Sophos;i="4.49,540,1262559600"; d="scan'208";a="45593569" Date: Thu, 25 Feb 2010 19:24:00 +0100 From: Frederic Mallet User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Huascar Espinoza CC: cmw@sce.carleton.ca, Séstien Demathieu , GERARD Sebastien 166342 , julien.deantoni@sophia.inria.fr, marte-rtf@omg.org Subject: Re: Issue #14899 discussion about arrivals and clocks Clocks have no outputs, they map the occurrences of events to a total order: i.e., they specify when an event occurs relatively to other events. However, I definitely see an interest in saying what is the connection between a WorkloadEvent and clocks. I think that a WorkloadEvent *is* a Clock (in the sense of the Time Chapter), an event being defined as a sequence of occurrences (a set of instants). If a WorkloadEvent always refers to the physical time and workload being a dense property, I would also say that the clock type of a WorkloadEvent is IdealClock. If you consider that the arrival pattern defines when the workload events occur, then a clock constraint is the way to constrain a clock so its instants occur when you want them to occur (relatively to the physical time and therefore to idealClk). Defining an arrival pattern is an abstract way to define a clock constraint that constraints the event to occur at specific moments. Fréric p.s.: CCSL is meant to be declarative and relational. It is definitely not imperative even though we have defined an operational semantics for it so we can have an operational (imperative) way to generate valid executions that satisfy the constraints. Huascar Espinoza a éit : Hi Murray, I guess that, as Julien said, there is a misunderstanding on the meaning of Clock, as a logical concept being capable of specifying an event pattern, and the clock mechanism. As far as I understand, the issue is looking at mapping the two ways of specifying those event patterns that MARTE supports. One which is more declarative, as Sésaid, defined in the Analysis chapters, and the other based on the clock specification formalism supported by the Time chapter and CCSL. From my perspective, it's just to provide the (semantic) mapping in some place of the MARTE spec. (I would prefer to do it in some section of the Annex). I might be wrong, but I don't see the need to connect the clock output to nothing. This is just my interpretation Huascar -----Original Message----- From: Murray Woodside [mailto:cmw@sce.carleton.ca] Sent: jueves, 25 de febrero de 2010 16:14 To: Frederic Mallet Cc: Séstien Demathieu; GERARD Sebastien 166342; julien.deantoni@sophia.inria.fr; marte-rtf@omg.org Subject: Re: Issue #14899 discussion about arrivals and clocks Frederic, Sebastien, I think maybe the idea to support a clock as a workload generator could be ideal bridge between the two specifications. Perhaps we can think together, how to do this. I think the best appraoch would be to identify the clock output (the event stream) as an event stream input for WorkloadEvent. What stereotype would this be, for best generality? Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Thu, 25 Feb 2010, Frederic Mallet wrote: Hi all, I think what Murray and Peter meant is that it should not be described has been *THE* way to formalize the arrival patterns, and therefore it should not be in the analysis part. Arrival Patterns (even Periodic) can be characterized without using clocks and without making explicit a generation mechanism. I am not sure whether it can be in the time chapter either if we want to avoid forward references (or it has to be as several examples). We can probably present this as a library, where we show some typical real-time constraints that can be described with the time model and its clocks: periodic, sporadic, burst, deadline, ... And a reference to the analysis part, saying this is one way to generate the pattern even though in several analysis contexts there is no particular need for making explicit the generation mechanisms while in the design you sometimes want to enforce it. It can serve also to make some links with NFP and VSL by showing how the clocks can model the non-functional aspects covered by NFP but also some functional aspects as advocated by the theory of concurrency. Frederic Séstien Demathieu a éit : Murray, I agree that not all the arrival patterns can be formalized using the Time model. In the cases that you describe below, it is just not even useful or appropriate. However, if some other arrival patterns (periodic, sporadic) could formalized in such a way, then it would be a useful piece of information and it will enforce consistency between these different parts of the specification. Thanks, Séstien cmw@sce.carleton.ca a éit : I think it would be a mistake to formalize for instance a Poisson process (exponential inter-arrival times), as a clock. There are many ways such a process may arise, for instance in the merging of very many independent event streams of any description whatever, there is a kind of central limit showing a convergence to a Poisson process. However there is no one mechanism. A clock for this would have no more information in it than the statistical description of the poisson process in the first place. The arrival process descriptions are at a different level of abstraction from the clocks. One could define a clock that is capable of producing a Poisson process, but it woudl restrict the definition. Murray About that issue, please remind I did not we have to remove the existing arrival patterns as they are currently defined (this kind of action is definitively out of the scope of the RTF). I suggest only completing them by defining for them a kind of formalization using the clock and CCSL. Cheers... Sébastien. Dr. Sébastien Gérard Head of MDD for DRES research project CEA, LIST/LISE Boîte courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -----Message d'origine----- DeÂ: cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] EnvoyéÂ: jeudi 18 février 2010 22:45 ÃÂ: Julien.Deantoni@sophia.inria.fr CcÂ: GERARD Sebastien 166342; cmw@sce.carleton.ca; marte-rtf@omg.org ObjetÂ: RE: Issue #14899 discussion about arrivals and clocks Julien, Sebastien, I have suggested on the GQAM wiki page that a resolution might be to define a clock as a kind of generator of arrivals (generator is already in the prfile). This corresponds to your idea of allowing one to define some kind of clock to generate an arrival pattern. Besides having a library, this would allow a special applicatio specific clock that is part of a system, to be used in an analysis model (this might be a problem to characterize, but it might produce traces). I am not quite sure what haas to be done to the generator concept to allow a clock... I have suggested that the TimeValueSpecification might provide a bridge. Murray Hi Sebastien, What could be done to link both facilities in a more formal way, could be to define in MARTE a kind of formalization of these arrival patterns using (Clocks, CCSL) by defining an equivalent (Clocks, CCSL) model for each arrival patterns. we (INRIA) are currently working on this way. We propose to provide some usefull construct like periodic, a periodic, sporadic arrival thanks to clocks and CCSL. Do you think we could put them in the TimeLibrary ? However, we do not want to express every arrival pattern since some of them are really specific to queuing theory and are not easily suitable to a description based on clocks and CCSL. On the other hand, we could provide some other classical construct used for real time modeling (deadline, responsive time, etc) We do not know if it is usefull, if it should be in the example subsection of the Time section or in the TimeLibrary. Any idea ? @Murray: you should not make a big distinction between clocks and event... Clock is a misleading word since it can reprensent logical clocks. In this case, clock can be used to represent arrival patterns of event occurrences and each instant of a clock correspond to an event occurrence. Best regards, julien What do you think? Best... Sébastien. ----------------------------------------------------------------- ---------- Dr. Sébastien Gérard Head of MDD for DRES research project CEA, LIST/LISE Boîte courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -----Message d'origine----- DeÃÂ: cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] EnvoyéÃÂ: mercredi 17 février 2010 23:02 ÃâÃÂ: marte-rtf@omg.org ObjetÃÂ: Issue #14899 discussion about arrivals and clocks Issue text: Arrivals: The mappings between the analysis arrival patterns (periodic, sporatic, ?)and Time durations, and clock constraints in CCSL should be defined in the specification. Comment by Murray: I dont understand this issue and would like clarification. The arrival processes are an analysis concept describing something imposed on the system, or even generated by another subsystem. They are not prima facie clocks, although since they are event sequences, they have a relationship to clocks. It would be unnatural in my view to require the definition of arrival processes through definitions of clocks. However it would be natural to allow an arrival process to be generated by a clock, which could then incorporate CCSL constraints in the clock definition. The clock could be a GaWorkloadGenerator (see Fig 15.7). GaWorkloadGenerator is defined in 15.3.2.17 as a specialization of Behavior, so it can define the event streams by a behaviour mechanism. This might need to be modified to allow a clock to be a generator. This needs participation of a clock expert. ********************************** DISCLAIMER ******************************* This message may contain confidential, proprietary or legally privileged information. If you are not the intended recipient of this message, please notify it to the sender and delete without resending or backing it, as it is legally prohibited. ********************************** AVISO LEGAL ****************************** Este mensaje puede contener informaci?n confidencial, en propiedad o legalmente protegida. Si usted no es el destinatario, le rogamos lo comunique al remitente y proceda a borrarlo, sin reenviarlo ni conservarlo, ya que su uso no autorizado est? prohibido legalmente. ****************************************************************************** Date: Thu, 25 Feb 2010 20:04:35 -0500 (EST) From: Murray Woodside Reply-To: cmw@sce.carleton.ca To: Frederic Mallet cc: Séstien Demathieu , GERARD Sebastien 166342 , julien.deantoni@sophia.inria.fr, marte-rtf@omg.org Subject: Re: Issue #14899 discussion about arrivals and clocks User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) I suggest a resolution along the following lines: In the clock chapter domain model, perhaps in sec 9.2.4, a paragraph about describing workload patterns by clock constraints. A library of such is a bigger step and perhaps not essential at this time, but it would go in annex C. This need not refer ahead to ch 15, it is self contained. Perhaps Sebastien could write the paragraph I refer to, as a start. In ch 15, sec 15.2.2, a reference to clock constraints and a sentence explaining their relationship to trigger event sequences declared in WorkloadEvent. i would be happy if Sebastien could write that too, or I will give it a try. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Thu, 25 Feb 2010, Frederic Mallet wrote: Hi all, I think what Murray and Peter meant is that it should not be described has been *THE* way to formalize the arrival patterns, and therefore it should not be in the analysis part. Arrival Patterns (even Periodic) can be characterized without using clocks and without making explicit a generation mechanism. I am not sure whether it can be in the time chapter either if we want to avoid forward references (or it has to be as several examples). We can probably present this as a library, where we show some typical real-time constraints that can be described with the time model and its clocks: periodic, sporadic, burst, deadline, ... And a reference to the analysis part, saying this is one way to generate the pattern even though in several analysis contexts there is no particular need for making explicit the generation mechanisms while in the design you sometimes want to enforce it. It can serve also to make some links with NFP and VSL by showing how the clocks can model the non-functional aspects covered by NFP but also some functional aspects as advocated by the theory of concurrency. Frederic Séstien Demathieu a éit : Murray, I agree that not all the arrival patterns can be formalized using the Time model. In the cases that you describe below, it is just not even useful or appropriate. However, if some other arrival patterns (periodic, sporadic) could formalized in such a way, then it would be a useful piece of information and it will enforce consistency between these different parts of the specification. Thanks, Séstien cmw@sce.carleton.ca a éit : I think it would be a mistake to formalize for instance a Poisson process (exponential inter-arrival times), as a clock. There are many ways such a process may arise, for instance in the merging of very many independent event streams of any description whatever, there is a kind of central limit showing a convergence to a Poisson process. However there is no one mechanism. A clock for this would have no more information in it than the statistical description of the poisson process in the first place. The arrival process descriptions are at a different level of abstraction from the clocks. One could define a clock that is capable of producing a Poisson process, but it woudl restrict the definition. Murray About that issue, please remind I did not we have to remove the existing arrival patterns as they are currently defined (this kind of action is definitively out of the scope of the RTF). I suggest only completing them by defining for them a kind of formalization using the clock and CCSL. Cheers... Sébastien. Dr. Sébastien Gérard Head of MDD for DRES research project CEA, LIST/LISE Boîte courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -----Message d'origine----- DeÂ: cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] EnvoyéÂ: jeudi 18 février 2010 22:45 ÃÂ: Julien.Deantoni@sophia.inria.fr CcÂ: GERARD Sebastien 166342; cmw@sce.carleton.ca; marte-rtf@omg.org ObjetÂ: RE: Issue #14899 discussion about arrivals and clocks Julien, Sebastien, I have suggested on the GQAM wiki page that a resolution might be to define a clock as a kind of generator of arrivals (generator is already in the prfile). This corresponds to your idea of allowing one to define some kind of clock to generate an arrival pattern. Besides having a library, this would allow a special applicatio specific clock that is part of a system, to be used in an analysis model (this might be a problem to characterize, but it might produce traces). I am not quite sure what haas to be done to the generator concept to allow a clock... I have suggested that the TimeValueSpecification might provide a bridge. Murray Hi Sebastien, What could be done to link both facilities in a more formal way, could be to define in MARTE a kind of formalization of these arrival patterns using (Clocks, CCSL) by defining an equivalent (Clocks, CCSL) model for each arrival patterns. we (INRIA) are currently working on this way. We propose to provide some usefull construct like periodic, a periodic, sporadic arrival thanks to clocks and CCSL. Do you think we could put them in the TimeLibrary ? However, we do not want to express every arrival pattern since some of them are really specific to queuing theory and are not easily suitable to a description based on clocks and CCSL. On the other hand, we could provide some other classical construct used for real time modeling (deadline, responsive time, etc) We do not know if it is usefull, if it should be in the example subsection of the Time section or in the TimeLibrary. Any idea ? @Murray: you should not make a big distinction between clocks and event... Clock is a misleading word since it can reprensent logical clocks. In this case, clock can be used to represent arrival patterns of event occurrences and each instant of a clock correspond to an event occurrence. Best regards, julien What do you think? Best... Sébastien. --------------------------------------------------------------------------- Dr. Sébastien Gérard Head of MDD for DRES research project CEA, LIST/LISE Boîte courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -----Message d'origine----- DeÃÂ: cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] EnvoyéÃÂ: mercredi 17 février 2010 23:02 ÃâÃÂ: marte-rtf@omg.org ObjetÃÂ: Issue #14899 discussion about arrivals and clocks Issue text: Arrivals: The mappings between the analysis arrival patterns (periodic, sporatic, ?)and Time durations, and clock constraints in CCSL should be defined in the specification. Comment by Murray: I dont understand this issue and would like clarification. The arrival processes are an analysis concept describing something imposed on the system, or even generated by another subsystem. They are not prima facie clocks, although since they are event sequences, they have a relationship to clocks. It would be unnatural in my view to require the definition of arrival processes through definitions of clocks. However it would be natural to allow an arrival process to be generated by a clock, which could then incorporate CCSL constraints in the clock definition. The clock could be a GaWorkloadGenerator (see Fig 15.7). GaWorkloadGenerator is defined in 15.3.2.17 as a specialization of Behavior, so it can define the event streams by a behaviour mechanism. This might need to be modified to allow a clock to be a generator. This needs participation of a clock expert. Subject: RE: Issue #14899 discussion about arrivals and clocks Date: Sat, 27 Feb 2010 19:32:21 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #14899 discussion about arrivals and clocks Thread-Index: Acq2f7Ag1+d5r6UsT+mPA/nI/05TlgBW0dOQ From: "GERARD Sebastien 166342" To: , Sébastien Demathieu Cc: , , "Frederic Mallet" X-OriginalArrivalTime: 27 Feb 2010 18:32:21.0635 (UTC) FILETIME=[33170D30:01CAB7DB] X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id o1RIOX0e009572 Hi all, I guess Murray is meaning Sébastien D. and not me Sébastien D., do you agree to provide the inputs as denoted by Murray, may be with the help of Julien or Fred ? Best... Sébastien. Dr. Sébastien Gérard Head of MDD for DRES research project CEA, LIST/LISE Boîte courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -----Message d'origine----- DeÂ: Murray Woodside [mailto:cmw@sce.carleton.ca] EnvoyéÂ: vendredi 26 février 2010 02:05 ÃÂ: Frederic Mallet CcÂ: Sébastien Demathieu; GERARD Sebastien 166342; julien.deantoni@sophia.inria.fr; marte-rtf@omg.org ObjetÂ: Re: Issue #14899 discussion about arrivals and clocks I suggest a resolution along the following lines: In the clock chapter domain model, perhaps in sec 9.2.4, a paragraph about describing workload patterns by clock constraints. A library of such is a bigger step and perhaps not essential at this time, but it would go in annex C. This need not refer ahead to ch 15, it is self contained. Perhaps Sebastien could write the paragraph I refer to, as a start. In ch 15, sec 15.2.2, a reference to clock constraints and a sentence explaining their relationship to trigger event sequences declared in WorkloadEvent. i would be happy if Sebastien could write that too, or I will give it a try. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Thu, 25 Feb 2010, Frederic Mallet wrote: > Hi all, > I think what Murray and Peter meant is that it should not be described has > been *THE* way to formalize the arrival patterns, and therefore it should not > be in the analysis part. Arrival Patterns (even Periodic) can be > characterized without using clocks and without making explicit a generation > mechanism. > I am not sure whether it can be in the time chapter either if we want to > avoid forward references (or it has to be as several examples). > > We can probably present this as a library, where we show some typical > real-time constraints that can be described with the time model and its > clocks: periodic, sporadic, burst, deadline, ... > And a reference to the analysis part, saying this is one way to generate the > pattern even though in several analysis contexts there is no particular need > for making explicit the generation mechanisms while in the design you > sometimes want to enforce it. > It can serve also to make some links with NFP and VSL by showing how the > clocks can model the non-functional aspects covered by NFP but also some > functional aspects as advocated by the theory of concurrency. > > Frederic > > Sébastien Demathieu a écrit : >> Murray, >> >> I agree that not all the arrival patterns can be formalized using the Time >> model. In the cases that >> you describe below, it is just not even useful or appropriate. >> >> However, if some other arrival patterns (periodic, sporadic) could >> formalized in such a way, then >> it would be a useful piece of information and it will enforce consistency >> between these different >> parts of the specification. >> >> Thanks, >> >> Sébastien >> >> >> cmw@sce.carleton.ca a écrit : >>> I think it would be a mistake to formalize for instance a Poisson process >>> (exponential inter-arrival times), as a clock. There are many ways such a >>> process may arise, for instance in the merging of very many independent >>> event streams of any description whatever, there is a kind of central >>> limit showing a convergence to a Poisson process. However there is no one >>> mechanism. A clock for this would have no more information in it than the >>> statistical description of the poisson process in the first place. >>> >>> The arrival process descriptions are at a different level of abstraction >>> from the clocks. One could define a clock that is capable of producing a >>> Poisson process, but it woudl restrict the definition. >>> >>> Murray >>> >>> >>>> About that issue, please remind I did not we have to remove the existing >>>> arrival patterns as they are currently defined (this kind of action is >>>> definitively out of the scope of the RTF). I suggest only completing them >>>> by defining for them a kind of formalization using the clock and CCSL. >>>> >>>> Cheers... Sébastien. >>>> >>>> >>>> Dr. Sébastien Gérard >>>> Head of MDD for DRES research project >>>> CEA, LIST/LISE >>>> Boîte courrier 94, GIF SUR YVETTE >>>> CEDEX, F-91191 France >>>> Phone/fax : +33 1 69 08 58 24 / 83 95 >>>> Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): >>>> www.papyrusuml.org >>>> http://www.eclipse.org/modeling/mdt/?project=papyrus >>>> >>>> Before printing, think about the environment >>>> >>>> -----Message d'origine----- >>>> Deà : cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] >>>> Envoyéà : jeudi 18 février 2010 22:45 >>>> Ã.à : Julien.Deantoni@sophia.inria.fr >>>> Ccà : GERARD Sebastien 166342; cmw@sce.carleton.ca; marte-rtf@omg.org >>>> Objetà : RE: Issue #14899 discussion about arrivals and clocks >>>> >>>> >>>> Julien, Sebastien, >>>> >>>> I have suggested on the GQAM wiki page that a resolution might be to >>>> define a clock as a kind of generator of arrivals (generator is already >>>> in >>>> the prfile). This corresponds to your idea of allowing one to define some >>>> kind of clock to generate an arrival pattern. >>>> >>>> Besides having a library, this would allow a special applicatio specific >>>> clock that is part of a system, to be used in an analysis model (this >>>> might be a problem to characterize, but it might produce traces). >>>> >>>> I am not quite sure what haas to be done to the generator concept to >>>> allow >>>> a clock... I have suggested that the TimeValueSpecification might provide >>>> a bridge. >>>> >>>> Murray >>>> >>>> >>>>> Hi Sebastien, >>>>> >>>>> >>>>>> What could be done to link both facilities in a more formal way, could >>>>>> be >>>>>> to define in MARTE a kind of formalization of these arrival patterns >>>>>> using >>>>>> (Clocks, CCSL) by defining an equivalent (Clocks, CCSL) model for each >>>>>> arrival patterns. >>>>>> >>>>> we (INRIA) are currently working on this way. We propose to provide >>>>> some >>>>> usefull construct like periodic, a periodic, sporadic arrival thanks to >>>>> clocks and CCSL. Do you think we could put them in the TimeLibrary ? >>>>> >>>>> However, we do not want to express every arrival pattern since some of >>>>> them are really specific to queuing theory and are not easily suitable >>>>> to >>>>> a description based on clocks and CCSL. On the other hand, we could >>>>> provide some other classical construct used for real time modeling >>>>> (deadline, responsive time, etc) We do not know if it is usefull, if it >>>>> should be in the example subsection of the Time section or in the >>>>> TimeLibrary. >>>>> >>>>> Any idea ? >>>>> >>>>> >>>>> @Murray: you should not make a big distinction between clocks and >>>>> event... >>>>> Clock is a misleading word since it can reprensent logical clocks. In >>>>> this >>>>> case, clock can be used to represent arrival patterns of event >>>>> occurrences >>>>> and each instant of a clock correspond to an event occurrence. >>>>> >>>>> >>>>> Best regards, >>>>> >>>>> julien >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> What do you think? >>>>>> >>>>>> Best... S̮̩bastien. >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------------- >>>>>> Dr. S̮̩bastien G̮̩rard >>>>>> Head of MDD for DRES research project >>>>>> CEA, LIST/LISE >>>>>> Bǫ̮te courrier 94, GIF SUR YVETTE >>>>>> CEDEX, F-91191 France >>>>>> Phone/fax : +33 1 69 08 58 24 / 83 95 >>>>>> Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): >>>>>> www.papyrusuml.org >>>>>> http://www.eclipse.org/modeling/mdt/?project=papyrus >>>>>> >>>>>> Before printing, think about the environment >>>>>> -----Message d'origine----- >>>>>> DeÃ.à : cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] >>>>>> EnvoyÃÆéÃ.à : mercredi 17 f̮̩vrier 2010 23:02 >>>>>> ÃÆâ.¬Ã.à : marte-rtf@omg.org g >>>>>> ObjetÃ.à : Issue #14899 discussion about arrivals and clocks >>>>>> >>>>>> Issue text: Arrivals: The mappings between the analysis arrival >>>>>> patterns >>>>>> (periodic, sporatic, ?)and Time durations, and clock constraints >>>>>> in >>>>>> CCSL should be defined in the specification. >>>>>> >>>>>> Comment by Murray: >>>>>> I dont understand this issue and would like clarification. The arrival >>>>>> processes are an analysis concept describing something imposed on the >>>>>> system, or even generated by another subsystem. They are not prima >>>>>> facie >>>>>> clocks, although since they are event sequences, they have a >>>>>> relationship >>>>>> to clocks. >>>>>> >>>>>> It would be unnatural in my view to require the definition of arrival >>>>>> processes through definitions of clocks. However it would be natural >>>>>> to >>>>>> allow an arrival process to be generated by a clock, which could then >>>>>> incorporate CCSL constraints in the clock definition. The clock could >>>>>> be >>>>>> a GaWorkloadGenerator (see Fig 15.7). >>>>>> >>>>>> GaWorkloadGenerator is defined in 15.3.2.17 as a specialization of >>>>>> Behavior, so it can define the event streams by a behaviour mechanism. >>>>>> This might need to be modified to allow a clock to be a generator. >>>>>> This >>>>>> needs participation of a clock expert. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >>> >>> > > Date: Mon, 01 Mar 2010 08:25:53 +0100 From: Sébastien Demathieu Organization: Thales Research & Technology User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: GERARD Sebastien 166342 CC: cmw@sce.carleton.ca, julien.deantoni@sophia.inria.fr, marte-rtf@omg.org, Frederic Mallet Subject: Re: Issue #14899 discussion about arrivals and clocks Murray, Sébastien, Yes, I can prepare something for discussion. Any help from Julien and Fred would most welcome. Thanks, Sébastien GERARD Sebastien 166342 a écrit : Hi all, I guess Murray is meaning Sébastien D. and not me Sébastien D., do you agree to provide the inputs as denoted by Murray, may be with the help of Julien or Fred ? Best... Sébastien. Dr. Sébastien Gérard Head of MDD for DRES research project CEA, LIST/LISE Boîte courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -----Message d'origine----- De : Murray Woodside [mailto:cmw@sce.carleton.ca] Envoyé : vendredi 26 février 2010 02:05 à : Frederic Mallet Cc : Sébastien Demathieu; GERARD Sebastien 166342; julien.deantoni@sophia.inria.fr; marte-rtf@omg.org Objet : Re: Issue #14899 discussion about arrivals and clocks I suggest a resolution along the following lines: In the clock chapter domain model, perhaps in sec 9.2.4, a paragraph about describing workload patterns by clock constraints. A library of such is a bigger step and perhaps not essential at this time, but it would go in annex C. This need not refer ahead to ch 15, it is self contained. Perhaps Sebastien could write the paragraph I refer to, as a start. In ch 15, sec 15.2.2, a reference to clock constraints and a sentence explaining their relationship to trigger event sequences declared in WorkloadEvent. i would be happy if Sebastien could write that too, or I will give it a try. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Thu, 25 Feb 2010, Frederic Mallet wrote: Hi all, I think what Murray and Peter meant is that it should not be described has been *THE* way to formalize the arrival patterns, and therefore it should not be in the analysis part. Arrival Patterns (even Periodic) can be characterized without using clocks and without making explicit a generation mechanism. I am not sure whether it can be in the time chapter either if we want to avoid forward references (or it has to be as several examples). We can probably present this as a library, where we show some typical real-time constraints that can be described with the time model and its clocks: periodic, sporadic, burst, deadline, ... And a reference to the analysis part, saying this is one way to generate the pattern even though in several analysis contexts there is no particular need for making explicit the generation mechanisms while in the design you sometimes want to enforce it. It can serve also to make some links with NFP and VSL by showing how the clocks can model the non-functional aspects covered by NFP but also some functional aspects as advocated by the theory of concurrency. Frederic Sébastien Demathieu a écrit : Murray, I agree that not all the arrival patterns can be formalized using the Time model. In the cases that you describe below, it is just not even useful or appropriate. However, if some other arrival patterns (periodic, sporadic) could formalized in such a way, then it would be a useful piece of information and it will enforce consistency between these different parts of the specification. Thanks, Sébastien cmw@sce.carleton.ca a écrit : I think it would be a mistake to formalize for instance a Poisson process (exponential inter-arrival times), as a clock. There are many ways such a process may arise, for instance in the merging of very many independent event streams of any description whatever, there is a kind of central limit showing a convergence to a Poisson process. However there is no one mechanism. A clock for this would have no more information in it than the statistical description of the poisson process in the first place. The arrival process descriptions are at a different level of abstraction from the clocks. One could define a clock that is capable of producing a Poisson process, but it woudl restrict the definition. Murray About that issue, please remind I did not we have to remove the existing arrival patterns as they are currently defined (this kind of action is definitively out of the scope of the RTF). I suggest only completing them by defining for them a kind of formalization using the clock and CCSL. Cheers... Sébastien. Dr. Sébastien Gérard Head of MDD for DRES research project CEA, LIST/LISE Boîte courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -----Message d'origine----- Deà : cmw@sce.carleton.ca [mailto:cmw@sce.carleton.ca] Envoyéà : jeudi 18 février 2010 22:45 Ã.à : Julien.Deantoni@sophia.inria.fr >>>>> Ccà : GERARD Sebastien 166342; cmw@sce.carleton.ca; marte-rtf@omg.org Objetà : RE: Issue #14899 discussion about arrivals and clocks Julien, Sebastien, I have suggested on the GQAM wiki page that a resolution might be to define a clock as a kind of generator of arrivals (generator is already in the prfile). This corresponds to your idea of allowing one to define some kind of clock to generate an arrival pattern. Besides having a library, this would allow a special applicatio specific clock that is part of a system, to be used in an analysis model (this might be a problem to characterize, but it might produce traces). I am not quite sure what haas to be done to the generator concept to allow a clock... I have suggested that the TimeValueSpecification might provide a bridge. Murray Hi Sebastien, What could be done to link both facilities in a more formal way, could be to define in MARTE a kind of formalization of these arrival patterns using (Clocks, CCSL) by defining an equivalent (Clocks, CCSL) model for each arrival patterns. we (INRIA) are currently working on this way. We propose to provide some usefull construct like periodic, a periodic, sporadic arrival thanks to clocks and CCSL. Do you think we could put them in the TimeLibrary ? However, we do not want to express every arrival pattern since some of them are really specific to queuing theory and are not easily suitable to a description based on clocks and CCSL. On the other hand, we could provide some other classical construct used for real time modeling (deadline, responsive time, etc) We do not know if it is usefull, if it should be in the example subsection of the Time section or in the TimeLibrary. Any idea ? @Murray: you should not make a big distinction between clocks and event... Clock is a misleading word since it can reprensent logical clocks. In this case, clock can be used to represent arrival patterns of event occurrences and each instant of a clock correspond to an event occurrence. Best regards, julien What do you think? Best... S̮̩bastien. --------------------------------------------------------------------------- Dr. S̮̩bastien G̮̩rard Head of MDD for DRES research project CEA, LIST/LISE Bǫ̮te courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -----Message d'origine----- DeÃ.à : cmw@sce.carleton.ca [mailto:cmw@sce.carrleton.ca] EnvoyÃÆéÃ.à : mercredi 17 f̮̩vrier 2010 23:02 ÃÆâ.¬Ã.à : marte-rt-rtf@omg.org ObjetÃ.à : Issue #14899 discussion about arrivaals and clocks Issue text: Arrivals: The mappings between the analysis arrival patterns (periodic, sporatic, ?)and Time durations, and clock constraints in CCSL should be defined in the specification. Comment by Murray: I dont understand this issue and would like clarification. The arrival processes are an analysis concept describing something imposed on the system, or even generated by another subsystem. They are not prima facie clocks, although since they are event sequences, they have a relationship to clocks. It would be unnatural in my view to require the definition of arrival processes through definitions of clocks. However it would be natural to allow an arrival process to be generated by a clock, which could then incorporate CCSL constraints in the clock definition. The clock could be a GaWorkloadGenerator (see Fig 15.7). GaWorkloadGenerator is defined in 15.3.2.17 as a specialization of Behavior, so it can define the event streams by a behaviour mechanism. This might need to be modified to allow a clock to be a generator. This needs participation of a clock expert. sebastien_demathieu1.vcf Date: Wed, 21 Jul 2010 01:15:59 +0200 From: Julio Medina User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) To: Frederic Mallet , Séstien Demathieu CC: marte-rtf@omg.org Subject: Issue 14899: Mapping between Arrival patterns and CCSL (Analysisintent and Design intent) X-OriginalArrivalTime: 20 Jul 2010 23:15:51.0318 (UTC) FILETIME=[7EB8F360:01CB2861] X-imss-version: 2.054 X-imss-result: Passed X-imss-scanInfo: M:P L:E SM:0 X-imss-tmaseResult: TT:0 TS:0.0000 TC:00 TRN:0 TV:6.0.1038(17518.002) X-imss-scores: Clean:81.21073 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:2 S:2 R:2 (0.0000 0.0000) Bonjour Fred, hola Séstien. I suggest to defer this issue for next versions of MARTE.(See http://www.omgwiki.org/marte1.1-rtf/doku.php?id=time_wg) If you have some material prepared and want to push a mapping now please react. Regards, The mappings between the analysis arrival patterns (periodic, sporatic, .) and Time durations, and clock constraints in CCSL should be defined in the specification.