Issues for UML Profile for MARTE 1.2 Revision Task Force 2

To comment on any of these issues, send email to [email protected]. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to [email protected].

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Jira Issues

Issue 11621: Section: 10/3 Jira Issue MARTE_-60
Issue 11706: use the stereotype <<allocated>> alone Jira Issue MARTE11-1
Issue 11767: [Time: Examples] Jira Issue MARTE11-2
Issue 11845: Runtimes may have multiple stacks Jira Issue MARTE11-3
Issue 11856: MARTE Profile : Synchronisation between SRM, GRM, HRM and analysis part Jira Issue MARTE_-61
Issue 12223: Introduce new chapter in section 6.4 Jira Issue MARTE11-4
Issue 12234: associations between Instance and ModelElement (subclasses) Jira Issue MARTE_-62
Issue 12286: align the notation section of 11.3.2.7 to the profile diagram. Jira Issue MARTE_-63
Issue 12403: ConcurrentAccessProtocolKind Jira Issue MARTE11-5
Issue 12411: Example in Figure 10.21 makes use of directed arrows Jira Issue MARTE_-64
Issue 13086: MARTE/section 7.2.1/ "No Metamodel root" bug Jira Issue MARTE_-65
Issue 13654: Having icons and symbols for stereotypes improves models comprehesibility Jira Issue MARTE11-6
Issue 13655: stereotype GRM::SchedulableResource should have an attribute describing its activation parameters Jira Issue MARTE_-66
Issue 13668: Section: 14.2 HRM Add an attribute isInterleaved : NFP_Boolean to the MemoryOrganization tuple type Jira Issue MARTE11-7
Issue 13842: Cannot precisely allocate an application to an execution platform described as a series of composite structures. Jira Issue MARTE11-8
Issue 14221: Semantics description of TimedObserver Jira Issue MARTE11-51
Issue 14348: MARTE domain model: defintion of Trigger Jira Issue MARTE11-52
Issue 14427: NFP_Constraint metaclass syncho with its underlying stereotype Jira Issue MARTE11-53
Issue 14428: NfpConstraint stereotype: rename property mode to modes Jira Issue MARTE11-9
Issue 14435: Meta class BehaviorScenario not synchronized with its representation Jira Issue MARTE11-54
Issue 14610: Missing constraint between scheduler and scheduling parameters Jira Issue MARTE11-10
Issue 14808: GQAM::RequestedService metaclass has no definition Jira Issue MARTE11-55
Issue 14821: Example of RtFeature update required Jira Issue MARTE11-56
Issue 14841: Nature and Kind of Allocation and Assignment Jira Issue MARTE11-57
Issue 14842: Implied NFP constraint on stereotypes Assign and Allocate Jira Issue MARTE11-58
Issue 14864: MARTE AADL annexe Jira Issue MARTE11-59
Issue 14865: FLOW : MARTE and AADL alignment Jira Issue MARTE11-60
Issue 14866: Feature group Jira Issue MARTE11-61
Issue 14867: DATA : MARTE AADL mapping Jira Issue MARTE11-62
Issue 14868: Annexe introduction Jira Issue MARTE11-63
Issue 14870: MARTE-AADL connectors modeling Jira Issue MARTE11-64
Issue 14871: MARTE-AADL component implmentation modeling Jira Issue MARTE11-65
Issue 14872: MARTE-AADL summeray table upgrade Jira Issue MARTE11-66
Issue 14873: MARTE-AADL software concept upgrades Jira Issue MARTE11-67
Issue 14874: MARTE-AADL software concept upgrades Jira Issue MARTE11-68
Issue 14891: Relationship between AnalysisContext, WorkloadBehavior and ResourcePlatform Jira Issue MARTE11-69
Issue 14892: Different multiplicities in the GQAM meta-model and profile Jira Issue MARTE11-70
Issue 14893: Align the NFP profile and domain model with the QUVD meta-model Jira Issue MARTE11-11
Issue 14894: AssigmentKind/AssignmentNature are redundant with AllocationKind/AllocationNature Jira Issue MARTE11-71
Issue 14895: Remove the TimedObservation stereotype Jira Issue MARTE11-72
Issue 14896: Update the GCM ClientServerPort to take into account evolutions in UML 2.3 Jira Issue MARTE11-73
Issue 14897: SecondaryScheduler should be an association of the Scheduler instead of a specialized class Jira Issue MARTE11-74
Issue 14898: SwResource should be a direct specialization of Resource, like its hardware counterpart Jira Issue MARTE11-50
Issue 14899: Missing mappings between analysis duration, arrival patterns and clock constraints Jira Issue MARTE11-12
Issue 14900: PortGroup concept used in Annex A.2 is not defined in the MARTE profile Jira Issue MARTE11-75
Issue 14901: The concept of System in Annex A.2 maps to a SysML concept Jira Issue MARTE11-110
Issue 14902: Inconsistent definition of CommunicationChannel properties Jira Issue MARTE11-76
Issue 14903: Inconsistency between the Time domain model and related profile Jira Issue MARTE11-77
Issue 14904: TimedElement.on default value should refer to the ideal clock Jira Issue MARTE11-78
Issue 14905: SAM Workload Figure defines a new property for GQAM::WorkloadBehavior Jira Issue MARTE11-79
Issue 14906: Figure 16.3 inconsistent with Figure 15.3 Jira Issue MARTE11-80
Issue 14907: Typo in Figure 10.13: enery property Jira Issue MARTE11-81
Issue 14908: ResourceUsage.requiredAmount aggregation kind should be composite Jira Issue MARTE11-82
Issue 14909: In Figure 15.3, Step.concurRes property should be typed by ConcurencyResource instead of SchedulableResource Jira Issue MARTE11-83
Issue 14910: NFP_CommonType shall define comparison operators (eg. =, >, <, *, +, -). Jira Issue MARTE11-84
Issue 14911: Clarify the additional semantics brought by the GRM::TimingResource stereotype Jira Issue MARTE11-85
Issue 14912: Align notions of duration in NFP, Time and GQAM Jira Issue MARTE11-86
Issue 14913: Clarify the semantics of GQAM::BehaviorScenario duration attribute w.r.t. execTime, respTime and hostDemand Jira Issue MARTE11-87
Issue 14914: The Step.host attribute is redundant, Jira Issue MARTE11-88
Issue 14915: Relationship between MARTE allocations, UML deployment and analysis profiles need to be clarified Jira Issue MARTE11-13
Issue 14916: Typo in Figure 10.13: multiplicity of event property Jira Issue MARTE11-89
Issue 14917: Clarify the relationship between GQAM::WorkloadEvent and GRM::UsageDemand Jira Issue MARTE11-90
Issue 15032: Figure 8.5 UML profile diagram for NFPs modeling Jira Issue MARTE11-91
Issue 15033: <<StereoType>> "SchedulableResource" has a tag of schedParams which is made up of a Class (this is not allowed in UML) Jira Issue MARTE11-92
Issue 15034: Diagram shows {ordered usedResouces}, it should be {ordered usedResources}. Jira Issue MARTE11-93
Issue 15035: � polling: PollingParameters [0..1] Jira Issue MARTE11-94
Issue 15036: 13.3 UML Representation Jira Issue MARTE11-95
Issue 15039: MARTE AADL Annexe Jira Issue MARTE11-96
Issue 15048: Timing observer naming Jira Issue MARTE11-97
Issue 15057: Inconsitencies in MARTE::GCM Jira Issue MARTE11-98
Issue 15073: MARTE Issue: Overloaded relationship Scenario to Step in Analysis Jira Issue MARTE11-99
Issue 15081: GCM behavioral representation Jira Issue MARTE11-100
Issue 15096: VSL - B3.3.9 - Typos in rule <interval-bounds> Jira Issue MARTE11-101
Issue 15097: VSL - B.3.3.11 and B.3.3.12 - Introducing optional keywords �Tuple� and �Choice� Jira Issue MARTE11-102
Issue 15098: VSL - B.3.3.17 - In conditional expressions, <if-false-exp> should not be optional Jira Issue MARTE11-103
Issue 15099: VSL - B.3.3.15 - typos in <namespace> rule in the context of Property Call Expression Jira Issue MARTE11-104
Issue 15100: VSL - Absence of rule for calling behaviors Jira Issue MARTE11-105
Issue 15106: MARTE Beta 3: Invalid stereotype label in figure 11.8 Jira Issue MARTE11-106
Issue 15116: Domain concept (definingEvent) not implemented in the UML representation Jira Issue MARTE11-107
Issue 15166: Specification of real time properties at "part with port" level Jira Issue MARTE11-14
Issue 15261: MARTE, sterotype <<assign>>, Jira Issue MARTE11-15
Issue 15275: The notion of "access connection" needs to be explicited in the AADL annex (A.2) of MARTE Jira Issue MARTE11-16
Issue 15291: ImpliesConstraint of Allocate and Assign relationships Jira Issue MARTE11-17
Issue 15292: GRM:Support for Time table driven schedules Jira Issue MARTE11-108
Issue 15310: GRM:Support for Time table driven schedules Jira Issue MARTE11-18
Issue 15377: RequestEventStream changed by WorkloadEvent Jira Issue MARTE11-109
Issue 15432: The DurationUnitKind doesn't exist any more Jira Issue MARTE11-19
Issue 15433: The IntervalType attributes are not the same ones in the profil diagram and profil elements description Jira Issue MARTE11-20
Issue 15434: The "Mb/s" baseUnit should be "Kb/s". Jira Issue MARTE11-21
Issue 15659: Precise the shape of an array of ports of an array of parts Jira Issue MARTE11-22
Issue 15660: Constraint 6 on the tiler is just "Notation", this should be precised Jira Issue MARTE11-23
Issue 15727: The semantics of the Reshape should be precised Jira Issue MARTE11-24
Issue 16010: a verb is missed in last sentence of first � Jira Issue MARTE11-25
Issue 16012: ClientServerFeature: possible ambiguity on provided/required status of signal reception Jira Issue MARTE11-26
Issue 16158: Missing HwRouter stereotype to allow modeling of Networks-on-Chips Jira Issue MARTE11-27
Issue 16162: VSL, Section B.3.3.9. The following attributes are missing (see figure B.7): Jira Issue MARTE11-28
Issue 16224: Coherency between active resource of MARTE and active class in UML Jira Issue MARTE11-29
Issue 16229: Typo in diagram 14.25 for stereotype SwSchedulableResource Jira Issue MARTE11-30
Issue 16247: Update Table of Contents Jira Issue MARTE11-31
Issue 16248: Page 269: Section 14.2.3.2, Stereotype Descriptions Jira Issue MARTE11-32
Issue 16583: Flow properties cannot be characterized with an RtSpecification Jira Issue MARTE11-33
Issue 16609: MARTE Clocks Jira Issue MARTE11-34
Issue 16835: Allocations kind and nature Jira Issue MARTE11-35
Issue 17339: TIME model overview: consistency of bullet descriptions Jira Issue MARTE11-36
Issue 17340: TIME model: reference to TimeStructureRelation Library does not exists Jira Issue MARTE11-37
Issue 17341: TIME model: name of referred section and name of section differ Jira Issue MARTE11-38
Issue 17342: TIME model: wrong section name Jira Issue MARTE11-39
Issue 17343: TIME model: clarification of ClockConstraint properties Jira Issue MARTE11-40
Issue 17344: TIME model: examples should be more pedagogical Jira Issue MARTE11-41
Issue 18165: Missing syncronization resource in UML mapping for PpUnit Jira Issue MARTE11-42
Issue 18249: MARTE: VSL short form for NFP_Real subtypes Jira Issue MARTE11-43
Issue 18547: Typos issues in GQAM Jira Issue MARTE11-44
Issue 18565: Refinement issue from GQAM to SAM Jira Issue MARTE11-45
Issue 18567: Questions on observators within GQAM and SAM Jira Issue MARTE11-46
Issue 18576: �GaWorkloadGenerator� and its pop attribute Jira Issue MARTE11-47
Issue 18581: About Gacenario:: Jira Issue MARTE11-48
Issue 18657: MARTE issue: Observation does not allow specification of time value Jira Issue MARTE11-49

Issue 11621: Section: 10/3 (marte-rtf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Enhancement
Severity: Significant
Summary:
The GRM::Resource stereotype (and its specializations in GRM, SRM, HRM, such as HRM::HwProcessor) extends the following UML metaclasses: Classifier, Property, InstanceSpecification, Lifeline, ConnectableElement. When modeling resources within a composite structure, one has the choice to : 1) apply the stereotype on a UML::Classifier, and then type the parts by this classifier 2) directly apply the stereotype on parts (UML::Property) 3) both 1) and 2) In the case of 3), the relationships between the stereotype attributes defined on the classifer and those defined on the parts need to be clarified. A possible answer would be to formulate the following: "a stereotype applied to an instance (part, instance specification, lifeline, connectable element) allows one to assign values that are instance-specific and which overrive the default values of the stereotype applied to the class".  

Resolution:
Revised Text:
Actions taken:
October 17, 2007: received issue
February 17, 2010: transferred from MARTE FTF
January 14, 2011: closed issue

Discussion:
This is already specified in a general way in the UML representation section of the Core  Elements Chapter, precisely refeering to the dual Classifier/Instance nature of several  modeling elements in MARTE. Please see page 30. We can close with no change the  issue.  Disposition: Closed, no change


Issue 11706: use the stereotype <<allocated>> alone (marte-rtf)

Click
here for this issue's archive.
Source: INRIA (Dr. Frederic Mallet, Frederic.Mallet(at)inria.fr)
Nature: Uncategorized Issue
Severity:
Summary:
 ApplicationAllocationEnd and ExecutionPlatformAllocationEnd differentiate the client and the supplier of the allocation. In case where a model element is both the source of an allocation and the target of another allocation it would be practical to be able to use the stereotype <<allocated>> alone instead of applying the two stereotypes <<app_allocated,ep_allocated>>.  

Resolution:
Revised Text:
Actions taken:
November 30, 2007: received issue
February 17, 2010: Transferred from MARTE FTF

Discussion:
Due to lack of time, ths issue is deferred to next RTF of MARTE


Issue 11767: [Time: Examples] (marte-rtf)

Click
here for this issue's archive.
Source: Fundacion Tecnalia Research and Innovation (Mr. Huascar Espinoza Ph.D., Huascar.Espinoza(at)tecnalia.com)
Nature: Enhancement
Severity: Minor
Summary:
[Time: Examples] One important specification feature in the embedded system domain is the Timing diagram. I propose to include examples to illustrate the use of the MARTE observation concepts and time expressions with Timing Diagrams

Resolution: Deferred to RTF. No consensus has yet been reached on which diagram would be pertinent to insert in the specification itself. Disposition: Transferred to RTF 1.2
Revised Text:
Actions taken:
December 7, 2007: received issue

Discussion:
Discussion:  There are ongoing discussions about the introduction of Timing Diagrams in SysML. MARTE is equipped to annotate UML Timing Diagrams. Giving a precise example in the MARTE specification might anticipate the SysML decision. So I suggest to postpone this issue for the FTF and wait for the evolution of SysML.  Disposition:	Deferred  


Issue 11845: Runtimes may have multiple stacks (marte-rtf)

Click
here for this issue's archive. Click here for this issue's attachments.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:
Runtimes may have multiple stacks. How to reference a specific stack size (e.g., primary or secondary) in SRM? It seems to miss a concept.  

Resolution: Deferred due to lack of time to deal with it. Disposition: Deferred This is already possible to describe multiple stacke because the multiplicty of the staskSizeElement attribute is unlimited (concurrentResource stereotype). It seems that there is a need to describe more precisely several stacks : primiary stack, secondary stack ... One solution leads to describe an explicit "Stack" stereotype. Such solution deeply modifies the SRM chapter. Due to lack of time, this issue is deferred to next RTF of MARTE. Disposition: Deferred
Revised Text:
Actions taken:
December 20, 2007: received issue

Discussion:
Discussion:  This is already possible to describe multiple stacke because the multiplicty of the  staskSizeElement attribute is unlimited (concurrentResource stereotype).  It seems that there is a need to describe more precisely several stacks : primiary stack, secondary stack ...   One solution leads to describe an explicit "Stack" stereotype.     Such solution deeply modifies the SRM chapter.    Disposition:	Deferred  


Issue 11856: MARTE Profile : Synchronisation between SRM, GRM, HRM and analysis part (marte-rtf)

Click
here for this issue's archive.
Source: ESEO (Dr. Jerome Delatour, jerome.delatour(at)eseo.fr)
Nature: Uncategorized Issue
Severity:
Summary:
A simplification of GRM should be envisaged.  GRM defines too many detailled concepts (for instance the Scheduler which seems more  appropriate in the SRM package), these concepts could be defined in  SRM or HRM package or even in SAM package.       The way to define different types of services need to be aligned between GRM, SRM  and HRM.  

Resolution: With respect to the status of the FTF, the resolution of this issue would need too much time to be resolved in an efficient and satisfying form. So, I (S�bastien G�rard from CEA LIST) propose to defer it. Disposition: Deferred This issue has been resolved by resolutions to issues 11411 and 11412. A brief modification is necessary in the introduction of GRM to comprise it as generic for also analysis and design. A brief text is to be added to the Introduction of GRM to emphasize its a role of foundation for the analysis packages (GQAM, SAM and PAM) and the DRM (SRM and HRM).
Revised Text: Section 10.1, page 85, add to the two elements bulleted list a third item with the following text: � Providing foundational modeling constructs that are later refined to support design (SRM & HRM) as well as analysis (GQAM, SAM & PAM) models.
Actions taken:
December 21, 2007: received issue
January 14, 2011: closed issue

Discussion:
Discussion:  There are two different opinions regarding the proposed re-structuring the concepts in the profile.    In the opinion of ESEO:    As mentioned for instance in issues 11411 and 11412, regarding GRM and SRM in particular, redundancy emerges between GRM concepts and packages depending on it (SRM, HRM but also SAM and GQAM). The same concept could be redefined twice, and this redefinition will let the designer express the same idea in different MARTE meta-classes (or stereotypes). In addition to a problem of consistency, there is a problem of readability and understanding for the designer.    Behind this issue, it is the central role given to GRM and the way Analysis models (GQAM and SAM) and XRM (GRM, SRM and HRM) elements are related which could be discussed. It's not certain that a clear consensus or agreement is reached on this central role of GRM. A broader discussion is needed in order to reach a consensus.    Different approaches for resolving this issue are possible. More time is needed  to make a better analysis of the advantages/default and change impacts of each one.    For theses reasons, this issue is deferred.     In the opinion of UC:    As mentioned in Issues 11411 and 11412 regarding GRM and SRM in particular, they may get significant "synchronization" by simply including in the SRM stereotypes the inheritance from the corresponding in GRM, but they do not have to be forced to stay totally "synchronized" since they are meant for different purposes, and use and promote very different modeling styles. GRM goes for architectural models that can provide and be extended to lead easily to analysis of the basic NFPs, while the main concern in the current flavor of SRM is to enable easier platform independence through model transformations.  Even considering these different modeling intents in the two subprofiles, avoiding inheritance at the profile level seems to indicate that it is due to a matter of purism more than to a technical reason.     In response to the issue :    (a)	GRM is not that complex considering that it must provide the minimum additional elements to UML to deal with design at the architectural level, as well as foundations for design and analysis, design for platform and application oriented models, and finally the hardware and software aspects of the platform. The suggestion to reduce it means probably not comprehension of this multifaceted role, or the implicit assumption that all these different aspects have totally nothing in common, which is wrong. They share the absolute necessity to have at the minimum the capability of being able to do evaluations of a system feasibility even at the very basic level against its non functional properties, and at least its timing properties.   (b)	For this reason, there must be aspects like scheduling in GRM. The concept of scheduler is crucial for almost all of the mentioned chapters (exception made of HRM probably). The attributes on it are the very basic ones to get the minimal capabilities to say something of the system feasibility in the context of the large majority of applications. Even particular techniques that model explicitly the behavior of the scheduler require this concept at this level of description.     Along this discussion, one week before the start of the voting period, this issue has been pushed to create a polemic enough to deserve further attention. More even considering that making such a coarse change in the structure of the standard may require a very deep reformulation.    In the opinion of UC this issue should be closed. A better alignment between the different models inside MARTE may be gotten, but restructuring it in the way it seems to be proposed will require a significant number of methodological choices, which may be good for one application or modeling style but not for others. This is a different alternative for standardization, and may lead to a new RFP, in which a concrete number of industrial applications, with their corresponding development styles, analysis techniques, and certification requirements, find precise modeling methodologies and tool support. This may require a per-domain response. Anyway in order to give the community the possibility to elaborate on all these, it has been deferred at this time.    Resolution:  Defer the issue so that a wider discussion may lead to consensus.    Revised Text:    Disposition:	Deferred  


Issue 12223: Introduce new chapter in section 6.4 (marte-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Enhancement
Severity: Minor
Summary:
It would be interested to introduce in the section 6.4 a chapter to explain the diferent design patterns adopted within the specification to use the UML extenssion mechanisms.  

Resolution:
Revised Text:
Actions taken:
February 14, 2008: received issue

Discussion:
Due to lack of time we defer this issue to next RTF.  Disposition: Deferred Due to lack of time, this issue is deferred to next RTF of MARTE.  Disposition: Deferred


Issue 12234: associations between Instance and ModelElement (subclasses) (marte-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Mr. Yann Tanguy, yann.tanguy(at)cea.fr)
Nature: Revision
Severity: Minor
Summary:
On fig. 7.6 three association between Instance and ModelElement (subclasses) have properties subsetted "type", but the "type" property only appear between Instance and Classifier (not ModelElement) fig. 7.3.  

Resolution: THIS IS A slightly OLD ISSUE, THE FIGURE NUMBERS HAD CHANGE SINCE LAST VERSIONS. AND THIS HAS BEEN ALREADY SOLVED BY SUBTYPING THE ROLE IN ONE OF THE LAST VERSIONS. SEE FIGURE 7.7 We can close with no change the issue. Disposition: Closed, no change
Revised Text:
Actions taken:
February 18, 2008: received issue
January 14, 2011: closed issue

Discussion:
Defered due toi lack of time and was not considered as major issue.  Disposition: Deferred


Issue 12286: align the notation section of 11.3.2.7 to the profile diagram. (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:
The notation section of 11.3.2.7 makes use of stereotypes that are inconsistent with the profile diagram. Proposed resolution: align the notation section of 11.3.2.7 to the profile diagram.  

Resolution: This issue was related to MARTE beta 1 and is no longer relevant to MARTE v1. Disposition: Closed, no change
Revised Text:
Actions taken:
March 19, 2008: received issue
February 17, 2010: transferred from MARTE FTF
January 14, 2011: closed issue

Issue 12403: ConcurrentAccessProtocolKind (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Dr. Madeleine Faugere, madeleine.faugere(at)thalesgroup.com)
Nature: Uncategorized Issue
Severity:
Summary:
"ConcurrentAccessProtocolKind"   contains several enumeration literals, one of them is "Other." With this representation, it is possible to represent ONE implicit user define protocol acces but impossible to make the distinction between various protocols defined by the end user like for exemple  (ex: .Interrupt_Masking, Maximum_Priority).    

Resolution: Due to lack of time, this issue is deferred to next RTF of MARTE. Disposition: Deferred
Revised Text:
Actions taken:
April 22, 2008: received issue

Discussion:
This issue is more generally related to the usage of Enumerations for typing  attributes of stereotypes, and the way to extend them. This is a recurrent problem  when designing a profile: The enumeration literals of an Enumeration are used to  capture the most representative interpretations of the aspect under study (e.g.,  for ConcurrentAccessProtocolKind, each enumeration literal represents a usual  protocol for concurrent accesses) but one would let the possibility for users to  define their own interpretations (e.g., for ConcurrentAccessProtocolKind, the  literal �Other� is intended to capture such an alternative interpretation).  As this problem is recurrent, it is worth taking time to have deeper discussions  and propose a systematic modeling pattern to address this profiling issue. We  therefore propose to defer issue 12403.  Disposition: Deferred


Issue 12411: Example in Figure 10.21 makes use of directed arrows (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:
The example in Figure 10.21 makes use of directed arrows to represent connectors in a composite structure. Moreover, it seems that the element inside the composite structure look more like classes than parts.  

Resolution: The example is not a composite structure; the caption text of the figure may have mislead the reader. It shows just a class diagram with dependencies among them. Resolution: Closed the issue with no change to the specification
Revised Text:
Actions taken:
April 24, 2008: received issue
January 14, 2011: closed issue

Discussion:
Deferred to RTF due to lack of time.  Disposition: Deferred


Issue 13086: MARTE/section 7.2.1/ "No Metamodel root" bug (marte-rtf)

Click
here for this issue's archive.
Source: INRIA (Mr. Pierre Boulet, Pierre.Boulet(at)lifl.fr)
Nature: Uncategorized Issue
Severity:
Summary:
The metamodel can not be executed/implemented since their is no root   element in the metamodel. It would be useful to introduce the   packageableElement, Model  (A model owns * PackageableElements). This   addition has several consequences on other parts of the metamodel in   order for this latter to be used for instance to create MARTE model   conforms to the MARTE metamodel.    

Resolution: Actually there is a root element it is �ModeElement�, and it has the �ownedElement� reflective relationship so all elements in MARTE may be (hopefully) derived from and contained in it. I suggest Close No Change. Disposition: Closed, no change
Revised Text:
Actions taken:
September 26, 2008: received issue
February 17, 2010: transferred from MARTE FTF
January 14, 2011: closed issue

Issue 13654: Having icons and symbols for stereotypes improves models comprehesibility (marte-rtf)

Click
here for this issue's archive.
Source: Fundacion Tecnalia Research and Innovation (Mr. Huascar Espinoza Ph.D., Huascar.Espinoza(at)tecnalia.com)
Nature: Enhancement
Severity: Significant
Summary:
Having icons and symbols for stereotypes improves models comprehesibility. For instance, HRM and SRM chapters provide graphical representations for most of the stereotypes. However, the GRM subprofile, which is shared by other chapters (analysis modeling parts of MARTE), has not such graphical representation. We propose to add icons and symbols (likely similar to SRM and HRM's ones) to GRM stereotypes.  

Resolution: In principle I though of using those in SRM and HRM plus some for those not defined. But a detailed review must be done. I suggest deferring this issue for the next version of the standard. Disposition: Deferred
Revised Text:
Actions taken:
March 3, 2009: received issue
February 17, 2010: transferred from MARTE FTF

Issue 13655: stereotype GRM::SchedulableResource should have an attribute describing its activation parameters (marte-rtf)

Click
here for this issue's archive.
Source: Fundacion Tecnalia Research and Innovation (Mr. Huascar Espinoza Ph.D., Huascar.Espinoza(at)tecnalia.com)
Nature: Enhancement
Severity: Critical
Summary:
The stereotype GRM::SchedulableResource should have an attribute describing its activation parameters (arrival pattern and parameters). This is useful in multi-rate systems, where, in addition to the activations defined at application level (activation events triggering action/event chains), OS tasks/threads can be defined with a given activation rate. For instance, almost all automotive systems are multi-rate systems. Even if the functional application appears as a single rate system, multiplexing mechanisms both in the communication or in data sampling mechanisms can induce to more complicated timing behaviors, which are a characteristics of multi-rate systems.   

Resolution: The activation pattern is a characteristic of the application, not of the platform. In fact it is usually different in each execution scenario. The concept of task, as used in languages and formalisms is for all of them a way to create an application, not a description of the platform. A modeling element that may serve for this purpose would be much closer in meaning to an RTUnit than to a SchedulableReource. So the extension requested is not in the scope of GRM. A task is clearly a design modeling element and if not in HLAM it may probably fit in SRM.
Revised Text:
Actions taken:
March 3, 2009: received issue
February 17, 2010: transferred from MARTE FTF
January 14, 2011: closed issue

Discussion:
Closed the issue with no change to the specification


Issue 13668: Section: 14.2 HRM Add an attribute isInterleaved : NFP_Boolean to the MemoryOrganization tuple type (marte-rtf)

Click
here for this issue's archive.
Source: INRIA (Mr. Pierre Boulet, Pierre.Boulet(at)lifl.fr)
Nature: Enhancement
Severity: Significant
Summary:
Add an attribute isInterleaved : NFP_Boolean to the MemoryOrganization tuple type do allow to discriminate between interleaved and non interleaved multi-bank memories

Resolution: Due to lack of time, this issue is deferred to next RTF of MARTE. Disposition: Deferred
Revised Text:
Actions taken:
March 10, 2009: received issue
February 17, 2010: transferred from MARTE FTF

Discussion:
  


Issue 13842: Cannot precisely allocate an application to an execution platform described as a series of composite structures. (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Clarification
Severity: Significant
Summary:
Title: Cannot precisely allocate an application to an execution platform described as a series of composite structures. Description : Consider an execution platform : a rack composed of 3 boards, each boards has a general-purpose processor and an accelerator. The rack and the board are structured classes defined with composite structure diagrams. The pseudo-code below provides an informal description of the platform: Rack { board: Board [3] } Board { gpp: GPP accelerator: FPGA } GPP {...} FPGA {...} How to precisely address the accelerator on the second board of the rack and allocate application elements on it ? The current allocation mechanism allows one to allocate an application on gpp property of the Board class but does not express that the second board is specifically designated.  

Resolution:
Revised Text:
Actions taken:
March 30, 2009: received issue
February 17, 2010: transferred from MARTE FTF

Discussion:
Due to lack of time, this issue is deferred to next RTF of MARTE.  Disposition: Deferred


Issue 14221: Semantics description of TimedObserver (marte-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Clarification
Severity: Minor
Summary:
The description of the semantics of TimedObserver in section F10.18 has to be aligned with its description denoted in the diagram shown in figure 15.4. TimedObserver can refer to several start and end events.

Resolution: {Fig 15.4 shows multiplicity * for both start and end events. Sec F10.18 shows multiplicity 0..1 for both... this should be changed to *. Since there may be several pairs of events, the associations must be ordered to express the correspondence. Since the is also an attribute laxity for each pair, it must also be multiple and ordered. Also there is confusion in the naming of the associations: startObs and endObs in the text in F10.18 and of Ch 15 for domain and UML, and startEvent and endEvent in the formal definition of F10.18 and in Fig. 15.4, and in the profile definition (sec 15.3.2.14). One or the other should be used consistently. Since startEvent/endEvent is rather generic, and indeed is also used in the Core domain model in another sense, it is preferred to standardize on startObs and endObs.
Revised Text: (1) Before the change, sec F10.18 p 680 has TimedObservers are conceptual entities that collect timing requirements and predictions related to a pair of user-defined observed events. In this sense, TimedObserver uses TimedInstantObservations (from the Time sub-profile) to define the observed event in a given behavioral model. Normally the observer expresses constraints on the duration between the two time observations, named startObs and endObs. Generalizations � NFP_Constraint (from NFPs::NFP_Annotation) Associations � endEvent: Time::TimedRelatedEntities::TimedObservations::TimedInstantObservation [0..1] Observed event to which the timing observer apply. � startEvent: Time::TimedRelatedEntities::TimedObservations::TimedInstantObservation [0..1] Reference event. After the changge, it is TimedObservers are conceptual entities that collect timing requirements and predictions related to a pair of user-defined observed events. In this sense, TimedObserver uses TimedInstantObservations (from the Time sub-profile) to define the observed event in a given behavioral model. Normally the observer expresses constraints on the duration between the two time observations, named startObs and endObs. If there are multiple pairs of events the definitions must be ordered to correspond, each with an value of the attribute laxity, also ordered. Generalizations � NFP_Constraint (from NFPs::NFP_Annotation) Associations � endObs: Time::TimedRelatedEntities::TimedObservations::TimedInstantObservation [*]{ordered} Observed event to which the timing observer apply. � startObs: Time::TimedRelatedEntities::TimedObservations::TimedInstantObservation [*](ordered} Reference event. Attributes � laxity: LaxityKind[*]{ordered} Indicates whether required timing constraints are hard or soft. (2) Section 15.3.2.14 Before the change: 15.3.2.14 GaTimedObs The GaTimedObs stereotype maps the TimedObserver domain element denoted in Annex F (Section F.10.18). GaTimedObs is a purely conceptual entity that serves to collect timing requirements and predictions that relates to user-defined observed events. In this sense, GaTimedObs uses UML TimeObservations to define the observed event in a given behavioral model. If there is more than one start/end pair they are ordered correspondingly, along with the laxity property for each pair. Extensions � None Generalizations � NfpConstraint (from NFPs::NFP_Annotation) Associations � endObs: UML::CommonBehaviors::BasicTime::TimeObservation [0..*]{ordered} Observed event to which the timing observer applies. � startObs: UML::CommonBehaviors::BasicTime::TimeObservation [0..*]{ordered} Reference event Attributes � laxity: LaxityKind [0..*]{ordered} Indicates whether required timing constraints are hard or soft (3) Figure 15.4 before after: replace the association labels startEvent and endEvent with startObs and endObs respectively {Precise editing instructions for applying resolution, including exact text, models, diagrams, references to be included or deleted. NOTE: IDL should be shown in Courier font}
Actions taken:
August 26, 2009: received issue
January 14, 2011: closed issue

Issue 14348: MARTE domain model: defintion of Trigger (marte-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Clarification
Severity: Minor
Summary:
The defintnion of the Trigger concept says: "A Trigger specifies the event and conditions that may trigger a behavior execution.". However, there is nothing in its features (associations or attributes) that will support the concept of condition mentioned in the defintion of Trigger.

Resolution: This is a conceptual entity, there is no stereotype associated. The semantically closer element that have a stereotype is the �. GQAM::GaWorkloadEvent plus its GaWorkloadGenerator. They do have the necessary attributes. I suggest Close No Change. Disposition: Closed, no change
Revised Text:
Actions taken:
September 3, 2009: received issue
January 14, 2011: closed issue

Issue 14427: NFP_Constraint metaclass syncho with its underlying stereotype (marte-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Enhancement
Severity: Minor
Summary:
The stereotype NFPConstraint owns a property to denotes in which modes the constaint is attached. The metaclass NFP_Constraint defined in the domain model of MARTE should be updated to reflect that property.

Resolution: The domain model already showed the Nfp_Constraint�s relationship to a Mode (Fig. 8.3) Disposition: Closed No Change
Revised Text:
Actions taken:
September 21, 2009: received issue
January 14, 2011: closed issue

Discussion:
Although there are no rules for naming association ends, it seems that UML uses singular names  for all association ends (independently of the role multiplicity). So, we should try to keep the same  naming convention in MARTE.


Issue 14428: NfpConstraint stereotype: rename property mode to modes (marte-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Clarification
Severity: Minor
Summary:
The property mode of the stereotype NfpCinstaint has a multiplicity [0  ..*]. To reflect that I propose to rename this latter mode to modes.

Resolution:
Revised Text:
Actions taken:
September 21, 2009: received issue

Issue 14435: Meta class BehaviorScenario not synchronized with its representation (marte-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Clarification
Severity: Minor
Summary:
The description of the Meta class BehaviorScenario is not synchronized with its representation in diagramm shown in FIgure 15.3. As for example, associations called steps in the diagram and called Actions in section F.10.13 (idem issue with assoc labelled inputstream in the section F.10.3 and called cause in diagram 15.3).

Resolution:
Revised Text:
Actions taken:
September 28, 2009: received issue
January 14, 2011: closed issue

Discussion:
This issue ovelaps with 15073 which also revises the BehaviourScenario  definition, so the changes were combined there.  The changes in that resolution, prompted by this issue, are:  In Section F10.3:  � association Actions renamed steps (consistent with Fig 15.3)  � association usedResources dropped (not in Fig. 15.3)  � association inputStream renamed cause (consisten with fig 15.3)  � association connectors added (consistent with Fig 15.3)  � attribute priority dropped (it occurs on Step)(consistent with chapter 15)  Disposition: See issue {15073} for disposition


Issue 14610: Missing constraint between scheduler and scheduling parameters (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:
In the GRM domain model (Figure 10.11) and GRM profile (Figure 10.16), there should be a constraint that enforce consistency between scheduling parameters and the related scheduler (e.g. a task brokered by an HPF scheduler cannot have anything else than a priority - integer - as a scheduling parameter).

Resolution:
Revised Text:
Actions taken:
November 2, 2009: received issue

Issue 14808: GQAM::RequestedService metaclass has no definition (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:
GQAM::RequestedService metaclass has no definition in Annex F.

Resolution: A subsection must be inserted after F.10.13 with the definition. Also, Fig 15.3 is missing the attributes of Step which define the requests, and these should be added.
Revised Text: (A) New subsection F.10.14 as follows: 15.3.2.11 RequestedService A RequestedService is an Operation by some class or interface, which is requested during the execution of a Step. This supports invocation of software services by components which are defined in other models. The RequestedService can in turn have details provided through the attributes it inherits from Step. An ordered list of RequestedServices may be specified, with a correspondingly ordered list servCount of mean numbers of requests made during the step. Generalizations � GaStep Associations � None Attributes � None Constraints � None (B) Fig 15.3 In the box for Step, two additional attributes need to be defined: serviceDemand:RequestedService [*] {ordered} serviceCount:NFP_Real [*] {ordered} (C) There is a spelling mistake in Figure 15.7, in the box for Step, servDeman should be replaced by servDemand.
Actions taken:
November 20, 2009: received issue
January 14, 2011: closed issue

Issue 14821: Example of RtFeature update required (marte-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Clarification
Severity: Critical
Summary:
All examples related to RtFeature in section 13.4.1 are out of date with respect to the definition of RtFeature stereotype that is in Beta 3 associated to a RtSpecification. They have to be updated accordingly.

Resolution: The issue actually refers to figures 13.14, 13.15, 13.16, 13.17, 13.18, 13.19 and 13.20. Most of the resolution consists in adding stereotype � rtSpecification � to comments associated with �rtfeatures�. See details in the revised text.
Revised Text: see pages 36 - 39 of ptc/2010-08-30
Actions taken:
November 24, 2009: received issue
January 14, 2011: closed issue

Issue 14841: Nature and Kind of Allocation and Assignment (marte-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Clarification
Severity: Minor
Summary:
Both Allocation and Assigne stereotype use their onw enumerations for defining their nature and kind. For simplification, they should use the same enumerations.

Resolution: Replace AssignmentNature by AllocationNature and remove the definition of AssignmentNature. Replace AssignmentKind by AllocationKind and remove the definition of AssignmentKind
Revised Text: see pages 40 - 41 of ptc/2010-08-30
Actions taken:
December 8, 2009: received issue
January 14, 2011: closed issue

Issue 14842: Implied NFP constraint on stereotypes Assign and Allocate (marte-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Clarification
Severity: Minor
Summary:
Both stereotypes Assign and Allocate have a properties called impliedConstraint. Do we need this additional attribute because indeed a NfpConstraint being a extension of the UML constraint can be apply on any elements.  Or if we need, could these properties be derived?

Resolution: The intent is to emphasize that allocations and assignments always come at price and the costs should be made explicit by some NFP constraints. These NFP constraints will then guide the architecture exploration, for instance. Of course, constraints can be applied to anything but having an explicit association is useful for traceability purpose. If you allocation one element to two execution platforms, the costs may be different and you need to know which constraint is imposed by which allocation. Disposition: Closed, no change
Revised Text:
Actions taken:
December 8, 2009: received issue
January 14, 2011: closed issue

Issue 14864: MARTE AADL annexe (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Dr. Madeleine Faugere, madeleine.faugere(at)thalesgroup.com)
Nature: Uncategorized Issue
Severity:
Summary:
The notion of assembly/delegation connectors between ports and subcomponents has to be clarified in the MARTE AADL annexe.  

Resolution:
Revised Text: Section A2.6.1 Add a sentence at the end of the section (just before A2.6.2): �A UML delegation connectors will be used to link ports to AADL subcomponents, and UML assembly connector to link AADL subcomponents together�.
Actions taken:
December 15, 2009: received issue
January 14, 2011: closed issue

Issue 14865: FLOW : MARTE and AADL alignment (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Dr. Madeleine Faugere, madeleine.faugere(at)thalesgroup.com)
Nature: Clarification
Severity: Significant
Summary:
The AADL flow path  implementation semantics is not in line with MARTE mapping proposition.  The AADL flow path declaration and implementation mapping need to be rethink  

Resolution: AADL flow semantics has been introduced to specify information transmission (data/event) over connection and subcomponent, covering the whole component and subcomponent hierarchy. This aspect is complementary to the structural one. Declaration flow paths links flow sources to flow sinks of components in a black boxes approach. Implementation flow paths specify the way this information is convey over connections and flow paths. End-to-end flows represent a logical flow of data and control from a source to a destination through the system instance, meaning a sequence of threads that process and possibly transform the data. The corresponding end-to-end flow instance is determined by expanding the flow specifications through their flow implementations. As UML/MARTE concepts makes a full distinction between logical and structural aspects, and while AADL manipulates them jointly, different and not full satisfying solutions can be provided to represent AADL flows and end-to-end-flows. � UML sequence diagrams, using message exchanges between instances and associated ports � UML activity diagrams, more focusing on actions and their associated control flow. Flow path declaration representation will stay unmodified, using the UML �InformationFlow� concept. Flow path implementation will be represented in a sequence diagram, using UML �GeneralOrdering� elements to keep order preservation between messages received and sent over the ports, UML �Messages� will be used to represent communication between instances. The Name of the GeneralOrdering element will make reference to the FlowPath declaration; the name of the message will make reference to the connection conveying it. To provide a representative distinction and to avoid code generation ambiguity between end-to-end flow and flow implementation representations, both represented as sequence diagrams, the first one will be stereotyped �end-to-end flow�, the second one, will have the suffix: Flowname_flow_impl. AADL flow sinks and flow sources can�t be represented in UML/MARTE.
Revised Text: Section A.2.8 Flow specification declaration paragraph: The following sentence will be added after the figure �AADL flow sinks and flow sources can�t be explicitly modelized in UML/MARTE� Flow specification implementation paragraph: Flow entire specification implementation paragraph will be replaced by the following: A flow-implementation declaration in a component implementation specifies how a flow specification is realized in this implementation: as a sequence of flows through subsystems (i.e., subcomponents) along connections from the flowspecification inport to the flow specification outport. Since flows are realized when code is executed, processes and threads must be considered. An UML interaction diagram will be used to represent the flow path implementation. The name of the Interaction diagram will make reference to the flow path name completed with the suffixe �flow.impl�. Instances will be represented with input and output ports, UML �GeneralOrdering� elements keeping order preservation in mind will be used to represent flow path declarations inside components, UML �Messages� will be used to represent communication between instances. To be in line with the structural AADL semantics, the name of the GeneralOrdering element will make reference to the flow path declaration; the name of the message will make reference to the connection conveying it. <<<see page 46 of ptc/2010-08-30 for graphic>>>
Actions taken:
December 15, 2009: received issue
January 14, 2011: closed issue

Issue 14866: Feature group (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Dr. Madeleine Faugere, madeleine.faugere(at)thalesgroup.com)
Nature: Clarification
Severity: Significant
Summary:
The whole AADL features group concepts can't be represented in MARTE      Precise the mapping perimeter and semantics of "inverse of"  

Resolution: Feature Group is a new aadl v2 concept. An AADL feature is part of a component type definition that specifies how that component interfaces with other components of the system. Features represent ports, subprogram and subprogram group accesses, parameters, and data and bus accesses. Feature group represents groups of component features, features group can contain feature group, and can be use anywhere features can be used. Inside a component, each feature can be connected individually, outside a component a feature groups can be connected as a single unit. A feature group type can be declared to be the inverse of another feature group type, which specifies that the feature types will remain the same but that the �direction� will be the opposite: so service provided/ required qualifier, flow direction, the parameter passing mode will be automatically deduced. In UML concept, the notion of port group, as group of ports, doesn�t exist. We use a symmetrical solution, meaning the possibility to refine and compose interfaces typing ports as alternative to physical connection point assembly. The MARTE AADL mapping perimeter will be restricted to data access and subprogram access. In order to provide a homogeneous representation for designers, align with data access and subprogram access, feature group will be represented as an UML interface composed by at least two attributes (representing more than one data access) or two subprogram access (representing more than one subprogram access). By default, the interface is provided. UML delegation/assembly connection represents AADL feature group access. In Threads and Processes subcomponents, constituting the system subcomponents, internal ports will be typed by interfaces representing the FeatureGroup subtypes, like unitary or composed data/subprogram access
Revised Text: Rename section 2.6.2 Feature Group Inverse sections 2.6.2 (Feature Group) with section 2.6.3 (Subprogram, data bus accesses) so that Subprogram, data bus accesses will be explain before FeatureGroup. Remplace totally new section 2.6.3 with Feature group represents groups of component features, features group can contain feature group, and can be use anywhere features can be used. Inside a component, each feature can be connected individually, outside a component a feature groups can be connected as a single unit. In MARTE, feature groups will be represented as an UML interfaces composed by at least two attributes (representing more than one data access) or two subprogram access (representing more than one subprogram access). FeatureGroup composition will be represented by data or operation additions to the interface representing the FeatureGroup, or interface refinement, and FeatureGroup decomposition inside the components by smaller interfaces (interface subtypes) specifications. By default, the interface is provided. Inside the components, i.e. in threads or processes constituting the system, internal ports will be typed by interfaces representing the FeatureGroup subtypes, providing FeatureGroup subtypes or unitary data/subprogram access. In MARTE, the FeatureGroup semantical perimenter will be restrict to data and subprogram accesses, providing an homogeneous representation for designers, with data access and subprogram access, UML delegation/assembly connection represents AADL subprogram access connections and UML provided/required interface concept the AADL provides/requires data access <<<see page 49 of ptc/2010-08-30 for image>>>
Actions taken:
December 15, 2009: received issue
January 14, 2011: closed issue

Issue 14867: DATA : MARTE AADL mapping (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Dr. Madeleine Faugere, madeleine.faugere(at)thalesgroup.com)
Nature: Clarification
Severity: Significant
Summary:
Two ways of modeling Data existe in AADL: the one using the AADL Data annexe modeling features, the other one relying on a pure structural view.  The first solution is currently addressed by the MARTE AADL annexe.  The annexe has to be upgraded to take into account the second way of doing.    

Resolution: Replace section A.2.3.4 with There are two ways of modeling AADL components, the first one addressing a pure architectural design, the second one, based on the Data Annex [SAE AS5506 A, Annex Document B: Data Modeling] , will be more dedicated to data modeling. AADL data component are used to represents different concepts � Data component classifier (type and implementation) staying for �data type in the source text�. This source text data type can be modeled by a data component type declaration with relevant properties without providing internal details that will be specified in a data component implementation. � Data subcomponents staying for �static data in the source text�. Data subcomponents are instances of data classifiers. According data classifier features and subcomponent features, the data component can represent: � A simple type (not necessary primitive) � A structured type (when sub component declared) � A class (when subcomponent present and provide subprograms declared) � A shared resource (if data access connection specified) AADL Primitive Types Each AADL primitive type from the AADL data_types packages (i.e. aadlboolean, aadlinteger, aadlreal, aadlstring) will have an UML/MARTE primitive type equivalent, defined in MARTE Model Library for Primitive Types (Annexe D from MARTE). These primitive types are commonly used in properties specification. Do represent them in an architectural view, the data annex based representation style must imperatively be followed. <<< see pages 51 - 53 of ptc/2010-08-30 for images>>>
Revised Text:
Actions taken:
December 15, 2009: received issue
January 14, 2011: closed issue

Issue 14868: Annexe introduction (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Dr. Madeleine Faugere, madeleine.faugere(at)thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:
AADL v2 has be voted.  Upgrade introduction texte to position MARTE according the new version of the AADL standard  

Resolution: Replace first sentence with � AADL is a RTES design and analysis language and standard referenced at the SAE (standard number XXX). Version 2 has been voted in XXX. This section presents the correspondence between MARTE 1.0 and AADL 2.0 concepts, with the aim to clarify which subset of MARTE concepts shall be used to explicit AADL concepts. The MARTE profile has be adopted as the UML profile for AADL, so this section presents the MARTE2AADL concepts correspondence. The section is not a methodology to design AADL applications in UML. �
Revised Text:
Actions taken:
December 15, 2009: received issue
January 14, 2011: closed issue

Issue 14870: MARTE-AADL connectors modeling (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Dr. Madeleine Faugere, madeleine.faugere(at)thalesgroup.com)
Nature: Clarification
Severity: Significant
Summary:
The notion of assembly/delegation connectors between ports and subcomponents has to be clarified in the MARTE AADL annexe.

Resolution: Same issue as 14864 Disposition: Closed, no change
Revised Text:
Actions taken:
December 17, 2009: received issue
January 14, 2011: closed issue

Issue 14871: MARTE-AADL component implmentation modeling (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Dr. Madeleine Faugere, madeleine.faugere(at)thalesgroup.com)
Nature: Clarification
Severity: Significant
Summary:
Upgrade AADL component declaration relationship to a AADL component implementation (UML Realization -> UML Component Realization)

Resolution: An AADL component type specifies the external interface of a component that its implementations satisfy. It contains declarations that represent features of a component and property associations. An AADL component implementation represents the realization of a component in terms of subcomponents, their connections, flow sequences, properties, component modes and mode transitions. UML 2 �Realization� semantics makes references to a specialized abstraction relationship between two sets of model elements, one representing a specification and the other representing an implementation of the latter. The UML 2 �ComponentRealization� concepts refine the �Realization� concepts, reducing the subset of linked elements to UML Components and Classifiers. This concepts suits better the the AADL component type/implementation relationship.
Revised Text: Annex A.2.2.2 Remplace second paragraph with � Component declarations and implementation could be modelized in different packages named Declaration and Implementation as shown Figure A.1 . A Uml �ComponentRealization� will be used to formalize this implementation relationship (�Gps� component can have two different implementations named �Gps.Basic� and �Gps.Handheld�). Component declaration and implementation could also be extended using a UML Generlization link (�Gps.handled� implementation extends �Gps.Basic�implementation) �
Actions taken:
December 17, 2009: received issue
January 14, 2011: closed issue

Issue 14872: MARTE-AADL summeray table upgrade (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Dr. Madeleine Faugere, madeleine.faugere(at)thalesgroup.com)
Nature: Clarification
Severity: Significant
Summary:
Upgrade MARTE AADL summery table upgrade according resolved issues

Resolution: see pages 59 - 62 of ptc/2010-08-30 for resolutoion
Revised Text:
Actions taken:
December 17, 2009: received issue
January 14, 2011: closed issue

Issue 14873: MARTE-AADL software concept upgrades (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Dr. Madeleine Faugere, madeleine.faugere(at)thalesgroup.com)
Nature: Clarification
Severity: Significant
Summary:
The provide a full MARTE AADL alignment, upgrade software concepts with AADL 1) abstract component, 2) prototype, 3) threadgroup, 4)subprogram group concepts

Resolution: In AADL v2, the concepts of abstract component, prototype, thread group and subprogram group have been added and have be taken into account by MARTE to ensure a full AADL v2/MARTE alignment.
Revised Text: see pages 63 - 66 of ptc/2010-08-30 for revised text
Actions taken:
December 17, 2009: received issue
January 14, 2011: closed issue

Issue 14874: MARTE-AADL software concept upgrades (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Dr. Madeleine Faugere, madeleine.faugere(at)thalesgroup.com)
Nature: Clarification
Severity: Significant
Summary:
The provide a full MARTE AADL alignment, upgrade platform concepts with AADL 1) virtual bus 2) virtual processor concepts

Resolution: Renumber section 2.4.4 in 2.4.6 Device Add section 2.4.2 Virtual Processor A virtual processor represents a logical resource that is capable of scheduling and executing threads and other virtual processors bound to them. It will be represented as a MARTE �swSchedulingResource� AND �ProcessingResource� stereotyped UML Classifier Add section 2.4.4 Virtual Bus A virtual bus component represents logical bus abstraction such as a virtual channel or communication protocol. It will be represented at resource level as a MARTE �CommunicationMedia� stereotyped UML connection or classifier allocated to the physical HWBus. � If the communication media represents a bus, and the clock is the bus speed, "element size" would be the width of the bus, in bits. � If the communication media represents a layering of protocols, "element size" would be the frame size of the uppermost protocol. Disposition: Resolved
Revised Text: for image(s) see page 68 of ptc/2010-08-30
Actions taken:
December 17, 2009: received issue
January 14, 2011: closed issue

Issue 14891: Relationship between AnalysisContext, WorkloadBehavior and ResourcePlatform (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:
AnalysisContext is the root of the GQAM model. In the first paragraph of the domain model, it is mentioned that an analysis context contains two parts: workload behavior and resource platform. AnalysisContext should specify composition relationships with WorkloadBehavior and ResourcePlatform (Figure 15.2)

Resolution: {�This issue misreads the text, which is: �The top-level GQAM package shown in Figure 15.2, is organized around the concept of AnalysisContext, which represents the root of the domain model. It contains two parts that address different concerns: �It� refers to the top-level package, not to AnalysisContext. The relationship to WorkloadBehavior and ResourcesPlatform is consistently an association, in chapters 15 16 17. AnalysisContext is the root of a tree of associations. I suggest this be closed with no change. To convert the relationship to a composition would be a major rewrite of all three chapters, with no benefit to the profile. } Disposition: Closed, no change
Revised Text:
Actions taken:
December 31, 2009: received issue
January 14, 2011: closed issue

Issue 14892: Different multiplicities in the GQAM meta-model and profile (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:
In the GQAM domain model, the multiplicity of the AnalysisContext.workloadBehavior is 1. In the profile, the multiplicity of the stereotype attribute is *. Proposed resolution: align on the profile and make it *.

Resolution: Make it * in Fig 15.2 and Sec F10.2. Also there is a dangling phrase in Sec F10.2
Revised Text: see pages 70 - 71 of ptc/2010-08-30 for resolution
Actions taken:
December 31, 2009: received issue
January 14, 2011: closed issue

Issue 14893: Align the NFP profile and domain model with the QUVD meta-model (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Revision
Severity: Significant
Summary:
Previous discussions between the SysML and MARTE communities have allowed relationships between both languages. An important convergence area relates to the notions of quantities, unit and dimensions. The SysML 1.2 RTF and the MARTE FTF work resulted in the definition of the QUVD meta-model (SysML Annex C.5). The MARTE NFP profile has not been yet entirely aligned on the QUVD meta-model. It would need aligned stereotyped when applicable (e.g. dimension vs. quantity type)

Resolution:
Revised Text:
Actions taken:
December 31, 2009: received issue

Discussion:
This issue needs further discussion with the SysML group in order to converge  on the profile design of the QUVD meta-model. For timing reason, we decide to  defer the resolution of this issue in order to get this time and propose a common  resolution with the SysML group.  Disposition: Deferred


Issue 14894: AssigmentKind/AssignmentNature are redundant with AllocationKind/AllocationNature (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:
Notions of kind and nature are shared between allocation and assignment. Related enumerations AssignmentKind and AssignmentNature describe the same concepts and are redundant. Proposed resolution: remove assignment enumerations and relate the Assign stereotype attributes to AllocationKind and AllocationNature

Resolution: Disposition: See issue 14841 for disposition
Revised Text:
Actions taken:
December 31, 2009: received issue
January 14, 2011: closed issue

Issue 14895: Remove the TimedObservation stereotype (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:
TimedObservation is an abstract stereotype that extends TimedElement without adding new features. It is sublassed by the concrete TimedDurationObservation and TimedInstantObservation. Given that it cannot be directly used, and for the sake of smplicity, removing the stereotype may be considered

Resolution: Stereotype TimedObservation was created for consistency with the UML Specification and considering that TimeExpression would refer to TimedObservation directly without deciding on the actual specialization. The stereotype can be removed with no harm. TimeExpression will refer to (untimed) Observation instead. Even though the semantics is weakened, there is no actual impact since the association between TimeExpression and Observation is not actually serialized by any tool. Though, it should be noted that TimedObservation cannot be removed from the Domain View since it is actually used by DurationPredicate and TimePredicate.
Revised Text: see pages 74 and 75 of ptc/2010-08-30 for resolution
Actions taken:
December 31, 2009: received issue
January 14, 2011: closed issue

Issue 14896: Update the GCM ClientServerPort to take into account evolutions in UML 2.3 (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:
Update the GCM ClientServerPort to take into account evolutions in UML 2.3 (introduction of conjugated port)

Resolution: The issue refers to the introduction in UML 2.3 of the property �isConjugated� on the metaclass Port. It means that the property �isConjugated� is no longer needed on the stereotype �ClientServerPort� from MARTE since ClientServerPort extends Port. The revised text describes required modifications to the MARTE specification. Note that, even though the issue does not mention it, FlowPort are also concerned by this evolution of UML ports. The �revised text� section also describes modifications required by the stereotype FlowPort.
Revised Text: see pages 76 - 77 of ptc/2010-08-30 for resolution
Actions taken:
December 31, 2009: received issue
January 14, 2011: closed issue

Issue 14897: SecondaryScheduler should be an association of the Scheduler instead of a specialized class (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:
For the sake of simplicity, SecondaryScheduler should be an association of the Scheduler instead of a specialized class. Making this concept relative would provide means to support more than two-level schedulers. Requires changes in the meta-model and the profile

Resolution: This simplification is not possible since the mechanisms to share the capacity that will be rendered by the primary scheduler to the secondary in order to be brokered by the secondary needs to be expressed, and this is done by the utilization of the intermediate schedulable resource. Simpler models may be made at user model level, so that the association between them can be stereotyped as Schedulable resource, but that is not feasible at the profile or domain view level. Resolution: Closed the issue with no change to the specification.
Revised Text:
Actions taken:
December 31, 2009: received issue
January 14, 2011: closed issue

Discussion:
  


Issue 14898: SwResource should be a direct specialization of Resource, like its hardware counterpart (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:
In the SRM meta-model, the SwResource specializes ResourceManager which makes SwSchedulableResource themselves. SwResource should be a direct specialization of Resource, like its hardware counterpart.

Resolution:
Revised Text:
Actions taken:
December 31, 2009: received issue

Issue 14899: Missing mappings between analysis duration, arrival patterns and clock constraints (marte-rtf)

Click
here for this issue's archive.
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

Issue 14900: PortGroup concept used in Annex A.2 is not defined in the MARTE profile (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Revision
Severity: Significant
Summary:
PortGroup concept used in Annex A.2 is not defined in the MARTE profile

Resolution: Port Group concept has been removed in AADL v2 and a more generic concept (feature group) has been introduced. The mapping towards MARTE is defined in issue 14866.
Revised Text: Replace �A.2.6.2 Port Group� section title with �Feature Group�
Actions taken:
December 31, 2009: received issue
January 14, 2011: closed issue

Issue 14901: The concept of System in Annex A.2 maps to a SysML concept (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Revision
Severity: Significant
Summary:
The concept of System in Annex A.2 maps to a concept not defined in the MARTE specification (a SysML concept). However the MARTE profile does not import the SysML profile.

Resolution: An AADL system represents an assembly of interacting application software, execution platform, and system components. The chosen mapping shall not only be semantically correct, but shall also have an intuitive name. MARTE doesn�t address such a generic aspect, and it would not make sense to add such a concept to MARTE. UML generic concept �StructuredClasses class� could be use, but this concept has already been used to represent AADL data. As mappings have always to be bijectiv, another representation has to be found. UML �subsystem� concept could be used to represent an �AADL system�, this mapping is semantically correct, but the name is confusing. The best solution is to use the SysML �block� concept: the mapping is semantically correct and the name is sufficiently different to avoid confusion. This solution needs to import the SysML profile. A prerequisite will be added in the introduction pr�cising that the SysML profile needs to be importing when using MARTE to design AADL applications in order to fully address the MARTE to AADL mapping.
Revised Text: Section A.2: Add a paragraph at the end of the introduction: Pre-requisit: To fully address MARTE to AADL mapping, the SysML profile is needed, and shall be imported: the �Block� concept is used to represent the AADL system concept.
Actions taken:
December 31, 2009: received issue
January 14, 2011: closed issue

Issue 14902: Inconsistent definition of CommunicationChannel properties (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Revision
Severity: Significant
Summary:
Annex F defines a CommunicationChannel.msgSize property while the meta-model and the profile defines a packetSize property. Note that the term 'packet' may not generic enough for the concept of CommunicationChannel

Resolution: For consistency, change the attributes of a CommunicationChannel in Annex F section F.10.4, and the GaCommChannel stereotype description in section 15.3.2.3 so that they appear as packetSize and utilization, like in Fig 15.5.
Revised Text: In Section F.10.4 CommunicationChannel, page 673, change Attributes from: msgSize: NFP_DataSize [0..1] The size of the message. To: packetSize: NFP_DataSize [0..1] The size of the data unit handled by the channel. utilization: NFP_Real [0..1] The fraction of the Communication Host capacity used by the Channel. This is typically a result of the analysis better than a specification.. In Section 15.3.2.3 GaCommChannel page 300, change Attributes from: � packetSize: NFP_DataSize [0..1] The size of the data unit handled by the channel. To: � packetSize: NFP_DataSize [0..1] The size of the data unit handled by the channel. � utilization: NFP_Real [0..1] The fraction of the Communication Host capacity used by the Channel. This is typically a result of the analysis better than a specification.. Disposition: Resolved
Actions taken:
December 31, 2009: received issue
January 14, 2011: closed issue

Discussion:
The term �packet� is used here to emphasize the �quantum�-based nature of the  channel usage. The term messageSize is more adequate for looking at the  concept from the users/application side while packet seems more adequate for  the platform/resource viewpoint. For consistency I suggest to correct the Annex F  accordingly. Also the attribute utilization that appears in Fig15.5 should be in  both annex F description and the stereotype description.


Issue 14903: Inconsistency between the Time domain model and related profile (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Revision
Severity: Critical
Summary:
In the domain model, TimeProcessing.duration is a simple association, typed by CVS::DurationValueSpecification while in the profile the association is a composition, typed by ValueSpecification. Inconsistency should be corrected

Resolution: In the domain view, the intent was to refer to a value (a duration value) and a value exists independently of its specification and therefore cannot be owned. In the UML representation, in practice, we use a specification to denote the value and there is no reason for the specification not to be owned by another element. The resolution proposes to keep the association in the domain view but refer to the metaclass DurationValue instead of CVS::DurationValueSpecification. This partly addresses also the issue 14912, stating that CVS::DurationValueSpecification being non normative should not be used in a normative part. The composition with a ValueSpecification is maintained in the profile. This is consistent with the different roles played by a value and one of its possible specifications.
Revised Text: see pages 85 - 86 of ptc/2010-08-30 for resolution
Actions taken:
December 31, 2009: received issue
December 31, 2009: received issue
January 14, 2011: closed issue
January 14, 2011: closed issue

Issue 14904: TimedElement.on default value should refer to the ideal clock (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Revision
Severity: Critical
Summary:
TimedElement.on default value should refer to the ideal clock, by the mean of a default property (e.g. instance value)

Resolution: The intent was actually to do so. When attribute "on" is not used, then it implicitly refers to idealClk. However, "idealClk" is defined in "TimeLibrary", which actually applies the "Time" profile. So what is requested in the issue would actually create a cyclic dependency. The resolution proposes to add a sentence to make the intent clear as suggested by the issue.
Revised Text: ----------- begin --------- Page 74, section 9.3.1.1, add the following text at the end of the paragraph: TimedElement is an abstract stereotype that must be used to associate one (or many when dealing with multiple time references) clock(s) to a UML model element. The concrete specializations of TimedElement make it clear which model element can or cannot be associated with clocks. When the property �on� is not specified, it should be understood as being by default, a dense chronometric clock with no flaws that represent the physical time. One possible example of such clock called �idealClk� is available in the library TimeLibrary. (see Annex D.3.2). ----------- end --------- ----------- begin --------- Page 81, section 9.3.2.7.3, Replace: Rreferences a set of Clocks. by References a set of Clocks. When no clock is explicitly specified, a reference to an implicit dense chronometric clock (like idealClk, see Annex D.3.2) is intended. ----------- end --------- Disposition:
Actions taken:
December 31, 2009: received issue
January 14, 2011: closed issue

Issue 14905: SAM Workload Figure defines a new property for GQAM::WorkloadBehavior (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Clarification
Severity: Significant
Summary:
Figure 16.3 located in the SAM chapter defines a new property (typed by EndToEndFlow) for a meta-class WorkloadBehavior defined in GQAM. Either move EndToEndFlow to GQAM or create a class that specializes WorkloadBehavior and introduce this new property. Additionally, the 'workload' property name can be renamed into 'flow' to avoid creating confusion.

Resolution: To avoid this new association for WorkloadBehavior, this resolution proposes to remove the association itself. It is not really needed since WorkloadBehavior already has the composite association with the two concepts that are part of an EndToEndFlow (WorkloadEvent and BehaviorScenario).
Revised Text: see pages 89 - 90 of ptc/2010-08-30 for revised text
Actions taken:
December 31, 2009: received issue
January 14, 2011: closed issue

Issue 14906: Figure 16.3 inconsistent with Figure 15.3 (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:
Figure 15.3 defines a cause-effect association between WorkloadEvent and WorkloadBehavior, while Figure 16.3 defines an inputSteam-effect association

Resolution: Change �inputStream� by �cause� in the association between WorkloadEvent and WorkloadBehavior in Figure 16.3. This implies changing also the description of the concept in Annex F section F10.3.
Revised Text: In Section F.10.3 BehaviorScenario, page 672, change text of association inputStream from: � inputStream: RequestEventStream [1..*] RequestEventStream that initiates it. To: � cause: WorkloadEvent [1..*] The characterization of the events that may initiate this BehaviorScenario. And the text of first constraint from: [1] The same BehaviorScenario may be associated with one or more RequestEventStreams within the same AnalysisContext. To: [1] The same BehaviorScenario may be associated with one or more WorkloadEvent within the same AnalysisContext <<<see page 92 for image>>>
Actions taken:
December 31, 2009: received issue
January 14, 2011: closed issue

Discussion:
In Figure 16.3 �inputStream� must be change by �cause�, also in Annex F  accordingly, including the type, which is now WorkloadEvent but it is still written  as RequestEventStream.


Issue 14907: Typo in Figure 10.13: enery property (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:
ResouceUsageAmount has a 'enery' property. Rename into 'energy'

Resolution:
Revised Text: see page 93 of ptc/2010-08-30 for revised text
Actions taken:
December 31, 2009: received issue
January 14, 2011: closed issue

Issue 14908: ResourceUsage.requiredAmount aggregation kind should be composite (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:
ResourceUsage.requiredAmount aggregation kind should be composite

Resolution: Add the diamond in ResourceUsage.requiredAmount depicted in figure 10.13. Here it is to be solved also the typo reported in Issue 14916
Revised Text: see page 94 of ptc/2010-08-30 for revised text
Actions taken:
December 31, 2009: received issue
January 14, 2011: closed issue

Issue 14909: In Figure 15.3, Step.concurRes property should be typed by ConcurencyResource instead of SchedulableResource (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Revision
Severity: Critical
Summary:
In Figure 15.3, Step.concurRes property should be typed by ConcurencyResource instead of SchedulableResource. SchedulableResource limits the domain of possible analysis that are possible with GQAM

Resolution:
Revised Text:
Actions taken:
December 31, 2009: received issue
January 14, 2011: closed issue

Discussion:
{This is not actually a limitation. This property defines the process or thread in  which the step is executed... this is always a schedulable resource. Other  resources are acquired explicitly by an AcquireStep, and they are general  resources, which can be anything.}  Disposition: Closed, no change


Issue 14910: NFP_CommonType shall define comparison operators (eg. =, >, <, *, +, -). (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Revision
Severity: Critical
Summary:
NFP_CommonType shall define comparison operators (eg. =, >, <, *, +, -). This currently does not exist, as a consequence two NFP_Duration cannot be compared one another. For instance, the VSL grammar does allow expressions such "(end - start) < (value=10.0, unit=ms)" (where start and stop are TimeObservation

Resolution: The issue addresses the absence of operations for the datatype NFP_CommonType (and its children types such as NFP_Duration) capturing predefined operators applying on these types. One of the consequences of this absence is that it is not possible to manipulate values of these in datatypes in VSL infix expressions (such as �"(end - start) < (value=10.0, unit=ms)", which would imply that operator �<� is available for NFP_Duration). As suggested by the issue description, one possible solution would be to modify the existing MARTE libraries, by adding required operations to NFP_CommonType or its children datatypes. The main drawback of this approach is that, each time a user identifies a need for an operator which is not supported by a datatype from the MARTE libraries, the library needs to be modified, by adding the corresponding operation to the datatype. This solution is not flexible. The idea of the resolution described in the section �revised text� is to provide users with a flexible mechanism for stating that a given predefined operator can be used on a particular type (in the context of infix VSL expressions). The core idea behind this resolution is to rely on the new features introduced in the resolution to issue 15100. The resolution to this issue introduces additional syntactic rules to VSL for expressing behavior calls (i.e., BehaviorCallExpression). As described in the resolution to this issue, defining behavior signatures following a procedural style (i.e., capturing signatures by behaviors instead of operations on DataTypes) can help to limit the coupling between type definitions and behavior signature definitions (since signatures are no longer captured as operations of data types). Relying on Behaviors instead of Operations for capturing new operators (e.g., adding predefined operators for NFP_CommonType) would therefore avoid modifications of existing libraries. In order to capture the fact that a given behavior actually represents an operator, a new stereotype, � Operator �, is introduced in this resolution. Some text is also provided regarding how this information can be automatically exploited by a VSL parser, regarding type inference and scoping.
Revised Text: see pages 98 - 104 of ptc/2010-08-30 for revised text
Actions taken:
December 31, 2009: received issue
January 14, 2011: closed issue

Issue 14911: Clarify the additional semantics brought by the GRM::TimingResource stereotype (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Clarification
Severity: Significant
Summary:
GRM::TimingResource inherits from Resource and is then specialized into ClockResource and TimerResource but it does not add any new property. A clarification of the additional semantics of this intermediate stereotype would be needed

Resolution: This is already explained in its definition in page 93. Disposition: Closed, no change
Revised Text:
Actions taken:
December 31, 2009: received issue
January 14, 2011: closed issue

Issue 14912: Align notions of duration in NFP, Time and GQAM (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Revision
Severity: Critical
Summary:
The Time profile is suposed to provide a fundational timing model for MARTE. Time stereotypes are specialized in several of profiles, such as GRM and GQAM. However, while time-related notions in the analysis profiles are typed by NFP_Duration, the Time::TimedProcesssing.duration stereotype attribute is typed by a ValueSpecification. This type inconsitency makes between general and specialized concepts creates usability issues. Indepently of that, note that the TimedProcessing meta-class and stereotype attribute are not consistently typed, as the (normative) TimedProcessing.duration meta-class attribute  is typed by the (non-normative) CVS::DurationValueSpecification.

Resolution: Disposition: See issue 14903 for disposition
Revised Text:
Actions taken:
December 31, 2009: received issue
January 14, 2011: closed issue

Issue 14913: Clarify the semantics of GQAM::BehaviorScenario duration attribute w.r.t. execTime, respTime and hostDemand (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Clarification
Severity: Critical
Summary:
Clarify the semantics of GQAM::BehaviorScenario duration attribute w.r.t. execTime, respTime and hostDemand, and harmonize their use across analysis chapters of the specification. On-going discussion with Dorina and Murray on this topic.

Resolution: Clarified, using a reference to the definitions in Table 15.1. Some of the attributes like execTime occur in the Table but are not used in the domain model, this is also clarified
Revised Text: Replace para 5 on p 290 of sec 15. OLD text: Steps and BehaviorScenarios have quantitative attributes as shown in Figure 15.3. A Step can be optional (with a probability less than one of being executed), or repeated (with a repetition count). It can be refined as another BehaviorScenario (its �behavior� association). The �isAtomic� property specifies atomicity of execution (default is false). Replacement text: Steps and BehaviorScenarios have attributes as shown in Figure 15.3. Most of these are defined in table 15.1 below, which also defines additional result variables which could be included in an extended model, but which are not incorporated in this domain model. In particular, respTime is the end-to-end delay of a BehaviorScenario, and blockingTime is any pure delay which enters the Step in addition to delays related to execution of operations. Priority is the priority of execution of a Step on the host processor, and the isAtomic property specifies atomicity of execution of the entire Step (the default is false). When combined with issue 15073 which also revises this paragraph, the text given in red below is also included. The result is: Steps and BehaviorScenarios have attributes as shown in Figure 15.3. Most of these are defined in table 15.1 below, which also defines additional result variables which could be included in an extended model, but which are not incorporated in this domain model. In particular, respTime is the end-to-end delay of a BehaviorScenario, and blockingTime is any pure delay which enters the Step in addition to delays related to execution of operations. A BehaviorScenario is a collection of Steps, but also a Step can also be the parent of a refinement as a more detailed BehaviorScenario (its childScenario). Priority is the priority of execution of a Step on the host processor, and the isAtomic property specifies atomicity of execution of the entire Step (the default is false).
Actions taken:
December 31, 2009: received issue
January 14, 2011: closed issue

Issue 14914: The Step.host attribute is redundant, (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Revision
Severity: Critical
Summary:
The Step.host attribute is redundant, given that a schedulable resource need to be related to a processor (execution host) for the analysis model to be complete and practically usable. Three alternatives for this stereotype attribute may be discussed: a) remove it, b) make it derived, c) keep it as a duplicate shortcut information. On-going discussion with Dorina and Murray on this topic

Resolution: The host relationship is very important when we need to model an abstract application without an explicit Task Model. The Step should be rich enough to model a piece of code subject to scheduling. For this reason a step has a Host, a Priority (among others). This kind of assumptions is necessary for early scheduling analysis. We propose then to close with no change this resolution. Disposition: Closed, no change
Revised Text:
Actions taken:
December 31, 2009: received issue
January 14, 2011: closed issue

Issue 14915: Relationship between MARTE allocations, UML deployment and analysis profiles need to be clarified (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Clarification
Severity: Critical
Summary:
UML introduce deployment concepts. MARTE introduces a notion of allocation that seem to encompass deployment-related notions (as stated in the specification). How these concepts relate to analysis attributes is left undefined in the specification at the moment. Depending on the examples one can have a look at, MARTE allocations and UML deployments seem to be used in a similar way (see Section 16.3.3 and Section 17.4). However, nothing is formally stated. Clarify whether MARTE allocations / UML deployment have the same semantics w.r.t. analysis, or not. And, if possible, make the connection with the related issue on host stereotype properties.

Resolution:
Revised Text:
Actions taken:
December 31, 2009: received issue

Discussion:
There is already a short discussion on the relationship between MARTE  allocation and UML deployment in the specification. The issuer wanted to go  more by extending the Deployment metaclass. This seems to restrict a bit the  usage of the allocation stereotype and poses compatibility problems with SysML.  This issue needs more discussion to be addressed properly.  Disposition: Transferred to RTF 1.2


Issue 14916: Typo in Figure 10.13: multiplicity of event property (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:
* symbol in front of the event property in Figure 10.13, which multiplicity is 0..1

Resolution: Separate the * from the +event role label, and locate them correctly in figure 10.13. The figure here shown is the very same as the resolution for issue 14908.
Revised Text: see page 111 og ptc/2010-08-30 for revised text
Actions taken:
December 31, 2009: received issue
January 14, 2011: closed issue

Issue 14917: Clarify the relationship between GQAM::WorkloadEvent and GRM::UsageDemand (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Clarification
Severity: Significant
Summary:
GQAM::BehaviorScenario specializes GRM::ResourceUsage. It seems that GRM::UsageDemand generalizes GQAM::WorkloadEvent. If so, make explicit this generalization relationship and consider the WorkloadEvent.timeEvent, WorkloadEvent.effect and BehaviorScenario.cause as redefined attributes

Resolution: This is actuially a very good observation. It does not seem dangerous. A resolution with it is provided. Note for the editor: Please observe that this resolution must be edited in after issue 14906, since this add the �redefined� constraint.
Revised Text: Annex F, Section F.10.3 BehaviorScenario eliminate attribute: inputStream: RequestEventStream [1..*] RequestEventStream that initiates it. And insert association: cause: WorkloadEvent [1..*] {redefines workload} The characterization of the events that may initiate this BehaviorScenario. Annex F, Section F.10.20 WorkloadEvent Add the associations: effect: BehaviorScenario[1] {redefines usage} The behaviorScenario that is launched by the workloadEvent timeEvent: Time::TimedEventModel::TimedEvents::TimedEvent [0..1] {redefines event} Indicates a timed event that generates the workloadEvent Also add the generalization: UsageDemand (from MARTE::GRM::ResourceUsages). Change Fig 15.3 by this: <<< see page 114 for graphics>>>
Actions taken:
December 31, 2009: received issue
January 14, 2011: closed issue

Issue 15032: Figure 8.5 UML profile diagram for NFPs modeling (marte-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
Figure 8.5 UML profile diagram for NFPs modeling      StereoType "Unit" has a Tag of convOffset but the xmi import has named it offsetFactor

Resolution: The right name is convOffset. The xmi must be fixed..
Revised Text: In the XMI file, replace the stereotype attribute offsetFactor with convOffset.
Actions taken:
February 4, 2010: received issue
January 14, 2011: closed issue

Issue 15033: <<StereoType>> "SchedulableResource" has a tag of schedParams which is made up of a Class (this is not allowed in UML) (marte-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
<<StereoType>> "SchedulableResource" has a tag of schedParams which is made up of a Class (this is not allowed in UML)

Resolution:
Revised Text:
Actions taken:
February 4, 2010: received issue
January 14, 2011: closed issue

Discussion:
schedParams is typed by which is a ChoiceType and not a Class. A ChoiceType is an  extension of UML DataType (see Figure B7), so there is no problem. We can close with  no change the issue.  Disposition: Closed, no change


Issue 15034: Diagram shows {ordered usedResouces}, it should be {ordered usedResources}. (marte-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
Diagram shows {ordered usedResouces}, it should be {ordered usedResources}.

Resolution: New figure 10.18.
Revised Text: see page 117 of ptc/2010-08-30 for image/revised text
Actions taken:
February 4, 2010: received issue
January 14, 2011: closed issue

Issue 15035: � polling: PollingParameters [0..1] (marte-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
but is called D.4.6 PoolingParameters (PollingParameters definition does not exist in the spec)

Resolution: It is indeed a typo: change PoolingParameters into PollingParameters for the label of section D4.6.
Revised Text: P. 503, change the label of section D4.6 from " PoolingParameters" into " PollingParameters".
Actions taken:
February 4, 2010: received issue
January 14, 2011: closed issue

Issue 15036: 13.3 UML Representation (marte-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
CallConcurrencyKind is an Enumeration but is not marked as such on the Diagram

Resolution: The issue actually refers to figure 13.8. Indeed, the keyword �enumeration� is missing on CallConcurrencyKind. The proposed resolution consists in adding the missing keyword.
Revised Text: see page 119 of ptc/2010-08-30 for revised text/image
Actions taken:
February 4, 2010: received issue
January 14, 2011: closed issue

Issue 15039: MARTE AADL Annexe (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Dr. Madeleine Faugere, madeleine.faugere(at)thalesgroup.com)
Nature: Uncategorized Issue
Severity:
Summary:
Precise component type and implementation relationship.  "Component realization" concept seems more inline with the  AADL semantics than "UML realization" concept.    

Resolution: Disposition: See issue 14871 for disposition
Revised Text:
Actions taken:
February 5, 2010: received issue
January 14, 2011: closed issue

Issue 15048: Timing observer naming (marte-rtf)

Click
here for this issue's archive.
Source: Carleton University (Dr. Murray Woodside, cmw(at)sce.carleton.ca)
Nature: Uncategorized Issue
Severity:
Summary:
The GQAM chapter defines the stereotype GaTimedObs in both domain and  profile figures, however there are inconsistencies elsewhere      ... GQAM sec 15.3.2.12 refers to GaTimingObserver      ... SAM chapter refers to it as GaTimingObserver, in the domain figure  16.5  ... and also just before Fig 16.8  ... and as TimingObs, in the profile figure 16.8      ...PA chapter refers to it as GaTimingObserver in profile Fig 17.7      These are due to a last minute effort to shorten the names. THey all need  to be standardized on GaTimedObs.  

Resolution: The domain term in chapters 15 16 17 and appendix F should be TimedObserver, the profile term in chapters 15 16 17 should be TimedObs
Revised Text: (A) Sec 15.3.2.12 (profile) Old text: Attributes ..... a long list.... � timing: GaTimingObserver [*] Timing observers associated with this scenario. New text: Attributes ..... a long list.... � timing: GaTimedObs [*] Timing observers associated with this scenario. <<<see page 122 - 124 fo ptc/2010-08-30 for images/graphics
Actions taken:
February 11, 2010: received issue
January 14, 2011: closed issue

Issue 15057: Inconsitencies in MARTE::GCM (marte-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
In the context of our work for the ADAMS project (http://www.adams-project.org/) we try to align MARTE and AUTOSAR with specific focus on MARTE::GCM and AR::SWC. To do so, we produced the domain models in UML. Unfortunately, we found the following inconsistencies, unclarities or typography issues in the MARTE specifications:       - Issue1:   AssemblyConnector (F.6.1) in annex F is not used in the domain of MARTE.   -Resolution1:   Remove F.6.1 and F6.13 subsections.      - Issue2:   SendFlowAction (F6.13) in annex F is not used in the domain of MARTE.   -Resolution2:   Remove F6.13 subsection.       - Issue3:   In Figure 12.2 (The bulk of the MARTE GenericComponentModel package), BehavioredClassifer qualified name is wrong.   -Resolution3:   Marte::CoreElements::Foundations::BehavioredClassifier should become MARTE::CoreElements::Causality::CommonBehavior::BehavioredClassifier      - Issue4:   In second paragraph of subsubsection 12.2.1 (The GenericComponentModel Package), "AssemblyConnector" is not appropriate  -Resolution4:   � "An interaction port defines an explicit interaction point through which components may be connected (linked) through an AssemblyConnector, and through which they can communicate via message passing."� should be changed to : "An interaction port defines an explicit interaction point through which components may be connected (linked) through an assembly connector, and through which they can communicate via message passing."�       - Issue5:   BFeatureKind (F.6.3) shouldn't be used anymore and it is replaced by ClientServerKind  -Resolution5:   Remove F.6.3. In subsection ClientServerPort (F.6.8) the type for "kind" attribute should be ClientServerKind.       - Issue6:   DirectionKind (F.6.12 ) shouldn't be used anymore and it is replaced by FlowDirectionKind  -Resolution6:   Remove F.6.12. In subsection FlowPort (F.6.15) and FlowProperty (F.6.16) the type for "direction" attribute should be FlowDirectionKind. Update Index.       - Issue7:   Mutliplicity and defalut value of "direction" attribute in FlowPort (F.6.15) should be respectively [1] and "= inout" in annex F  -Resolution7:   In F.6.15, [0..1] multiplicity for direction should be changed to [1] and default value set to "= inout"      - Issue8:   Default value of "direction" attribute in FlowProperty (F.6.16) should be "= inout" in annex F  -Resolution8:   In F.6.15, default value for direction should be set to "= inout"      - Issue9:   Multiplicity specification association of FlowPort (F.6.15) should be [0..*]. Furthermore this association is not represented in Figure 12.3   -Resolution9:   In F.6.15, multiplicity for specification should be changed to [0..*], name should be updated to "specifications" and Figure 12.3 should be updated consequently.       - Issue10:   In annex F, Attributes paragraph title for InvocationAction (F.6.19) should actually be "Associations"  -Resolution10:   In F.6.19, change paragraph title to "Associations" and add a "Attributes" pragraph title with "None" as body.       - Issue11:   In annex F, generalization to ClientServerFeature is missing for Operation (F.6.21)  -Resolution11:   In F.6.21, add ClientServerFeature to Generalizations paragraph      - Issue12:   In annex F, association to Flowproperty is missing for SendDataAction (F.6.22)  -Resolution12:   In F.6.22, add " + targetProperty: FlowProperty [0..1]" to Associations paragraph      - Issue13:   In annex F, Associations paragraph title (the one containing kind attribute) for ClientServerFeauture (F.6.6) should actually be "Attributes"  -Resolution13:   In F6.6 change paragraph title to "Attributes"      - Issue14:   In Figure 12.3 and Figure 12.4, default values are not represented  -Resolution14:   To clarify the specification, default values should be represented too (i.e. "=false" for isAtomic and "=inout" for direction      - Issue15:   SendSignalAction introduced in Figure 12.5 is not mentioned in annex F  -Resolution15:   Add annex F the concept with generalization to InvocationAction and change BoradcastSignalAction (F.6.4) generalization to SendSignalAction      - Issue16:   In annex F, multiplicity for onPort association of InvocationAction (F.6.19) and the multiplicity represented in Figure 12.5 are inconsistent : [1] and [0..1] respectively.   -Resolution16:   Should be set to [1] for both.      - Issue17:   ClientServerSpeification concept should be added to align with what is done for FlowPort  -Resolution17:   In annex F Add ClientServerSpecification concept in annex F. It has " + ownedFeatures: ClientServerFeature [*]" association. Add an association " + specifications: ClientServerSpecification [0..*]" to ClientServerPort (F.6.8)      - Issue18:   In annex F, isAtomic attribute of ClientServerPort (F.6.8) should be defined as derived  -Resolution18:   In F.6.8, add a "/" in front of isAtomic attribut of ClientServerPort      - Issue19:   Constraints on direction attribute for FlowPort  -Resolution19:   Add this constraint in Annex F to FlowPort (F.6.15) : If the FlowPort is not atomic then if direction attribute of all the FlowProperty of all its FlowSpecification are set to in (respectively out) then direction is in (respectively out) otherwise direction is inout.   If the FlowPort is atomic then direction attribute must be set by designer.       - Issue20:   Constraints on kind attribute for ClientServerPort  -Resolution20:   Add this constraint in Annex F to ClientServerPort (F.6.8) : If the ClientServer is not atomic then if kind attribute of all the ClientServerFeature of all its ClientServerSpecification are set to provided (respectively required) then direction is provided (respectively required) otherwise kind is proreq.   If the ClientServerPort is atomic then kind attribute must be set by designer.       - Issue21:   In annex F.6.7, required enum literal paragraph of ClientServerKind is inconsistent   -Resolution21:   � "The behavioral feature is provided by the port of the owning entity."� should changed to "The behavioral feature is required by the port of the owning entity."

Resolution: This issue actually consists of sub-issues, which concerns minor synchronization problems between diagrams of the domain model, and associated descriptions in Annex F. For each subissue, the submitter has proposed resolutions. All the resolution (as the described in the section �summary� above) are reproduced in the section �revised text� below, with complementary information when needed.
Revised Text: see pages 127 - 132 of ptc/2010-08-30 for revised text
Actions taken:
February 15, 2010: received issue
January 14, 2011: closed issue

Issue 15073: MARTE Issue: Overloaded relationship Scenario to Step in Analysis (marte-rtf)

Click
here for this issue's archive.
Source: Carleton University (Dr. Murray Woodside, cmw(at)sce.carleton.ca)
Nature: Uncategorized Issue
Severity:
Summary:
In the analysis subprofiles a step has two relationships to scenarios:      1 Containment... a step is always contained in a scenario  2 Refinement: a step may be optionally be refined by a lower-level scenario      The GQAM chapter defines one association behavior/steps which is defined  as  containment from the scenario point of view, and as refinement from  the step point of view. This is navigable and usable, but formally  incorrect.      Suggested resolution: To be formally correct it requires two associations.  One defines a collection of steps as the steps of the scenario, the other  defines a scenario as a refinement of a step.      Suggestion:      Containment: Scenario has association steps, Step has association scenario      Refinement: Scenario has association parentStep, Step has association  childScenario      Alternatively we could explain the overloading in the text and leave the  profile as it is.    Needs discussion.

Resolution: To be formally correct it requires two associations. One defines a collection of steps as the steps of the scenario, the other defines a scenario as a refinement of a step. Suggestion: Containment: Scenario has association steps, Step has association scenario Refinement: Scenario has association parentStep, Step has association childScenario These changes are needed both in the domain model sec 15.2 and the profile sec 15.3, and in Appendix F.10 for the encoding of the domain model Also, some changes in sec. F.10.3 to synchronize it with sec 15.2 were transferred from issue 14435, � association Actions renamed steps (consistent with Fig 15.3) � association usedResources dropped (not in Fig. 15.3) � association inputStream renamed cause (consistent with fig 15.3) � association connectors added (consistent with Fig 15.3) � attribute priority dropped (it occurs on Step)(consistent with chapter 15) (A) Figure 15.3: � add association parentStep - childScenario � rename association behavior - steps to scenario - steps (B) Section 15.2, Text p 290 para 5: Before: Steps and BehaviorScenarios have quantitative attributes as shown in Figure 15.3. A Step can be optional (with a probability less than one of being executed), or repeated (with a repetition count). It can be refined as another BehaviorScenario (its �behavior� association). The �isAtomic� property specifies atomicity of execution (default is false). Revised Text (the one new sentence is in red) Steps and BehaviorScenarios have quantitative attributes as shown in Figure 15.3. A Step can be optional (with a probability less than one of being executed), or repeated (with a repetition count). A BehaviorScenario is a collection of Steps, but also a Step can also be the parent of a refinement as a more detailed BehaviorScenario (its childScenario). The �isAtomic� property specifies atomicity of execution (default is false). (C) Fig 15.7 (the profile) also needs to be updated for the second association between Step and Scenario: � add association parentStep - childScenario � modify association behavior - steps to scenario - steps (D) Appendix F.10.3 for BehaviorScenario The five changes transferred from issue 14435 are included, plus the association change between Step and BehaviorScenario. For clarity the new text is in red. Original text: Associations � root: Step [0..1] Root Step to begin the BehaviorScenario. � Actions: Step [0..1] Set of Steps making up the BehaviorScenario. � inputStream: RequestEventStream [1..*] RequestEventStream that initiates it. � usedResources: Resource [0..*] {ordered} Set of resources used by the scenario UML Profile for MARTE, V1.0 Attributes � hostDemand: NFP_Duration [0..1] CPU demand in time units. � hostDemandOps: NFP_Real [0..1] CPU demand in operations. � priority: NFP_Integer [0..1] � respTime: NFP_Duration [0..1] End-to-end delay of a part of an operation. � interOccTime: NFP_Duration [0..1] Interval between successive initiations of an operation. � throughput: NFP_Rate [0..1] Frequency of initiations of an operation. � utilization: NFP_Real [0..1] Fraction of time an operation is busy (throughput times delay). For a resource, the fraction of time each unit is busy, times the number of units. � utilizationOnHost: NFP_Real [0..1] Fraction of time the host is busy executing this operation. Revised text: Associations � root: Step [0..1] Root Step to begin the BehaviorScenario. � steps: Step [0..1] Set of Steps making up the BehaviorScenario. � cause: RequestEventStream [1..*] RequestEventStream that initiates it. � parentStep: Step [0..1] Step of which this BehaviorScenario is a refinement (nested behavior) � connectors: PrecedenceRelation [*] The set of precedence relationships between the steps of the scenario Attributes � hostDemand: NFP_Duration [0..1] CPU demand in time units. � hostDemandOps: NFP_Real [0..1] CPU demand in operations. � respTime: NFP_Duration [0..1] End-to-end delay of a part of an operation. � interOccTime: NFP_Duration [0..1] Interval between successive initiations of an operation. � throughput: NFP_Rate [0..1] Frequency of initiations of an operation. � utilization: NFP_Real [0..1] Fraction of time an operation is busy (throughput times delay). For a resource, the fraction of time each unit is busy, times the number of units. � utilizationOnHost: NFP_Real [0..1] Fraction of time the host is busy executing this operation. (E) Section F10.17 for Step Add the new association between Step and BehaviorScenario Old text: Associations � outputRel: PrecedenceRelation [*] Successor relation. � inputRel: Step[*]:PrecedenceRelation [*] Predecessor relation. Attributes � isAtomic: NFP_Boolean [0..1] If true, the step cannot be decomposed any further. � blockingTime: NFP_Duration [0..1] Delay inserted into the execution of the Step. � repetitions: NFP_Real [0..1] Actual or average number of repetitions of an operation or loop. � probability: NFP_Real [0..1] Probability of the step to be executed (useful for conditional execution). � priority: NFP_Interval [0..1] Step priority. Revised text: Associations � outputRel: PrecedenceRelation [*] Successor relation. � inputRel: Step[*]:PrecedenceRelation [*] Predecessor relation. � childScenario: Scenario [0..1] An optional refinement of the behavior of this Step Attributes � isAtomic: NFP_Boolean [0..1] If true, the step cannot be decomposed any further. � blockingTime: NFP_Duration [0..1] Delay inserted into the execution of the Step. � repetitions: NFP_Real [0..1] Actual or average number of repetitions of an operation or loop. � probability: NFP_Real [0..1] Probability of the step to be executed (useful for conditional execution). � priority: NFP_Interval [0..1] Step priority. (F) Sec 15.3.2.12, giving the UML definition of GaScenario Old text: Associations � steps: Step [1..*] The set of steps that make up the Scenario. New text: Associations � steps: GaStep [1..*] The set of steps that make up the Scenario. � parentStep: GaStep [1..*] A GaStep, of which this scenario is a refinement. (G) Sec 15.3.2.13, giving the UML definition of GaStep Old text: Associations � behavior: GaScenario [0..1] A GaScenario that refines a composite Step. New text: Associations � scenario: GaScenario [0..1] The GaScenario that that contains this Step. � childScenario: GaScenario [0..1] A GaScenario that refines this Step, making it a composite Step. Disposition: Resolved
Revised Text:
Actions taken:
February 20, 2010: received issue
January 14, 2011: closed issue

Issue 15081: GCM behavioral representation (marte-rtf)

Click
here for this issue's archive.
Source: Fundacion Tecnalia Research and Innovation (Mr Adrian Noguero, adrian.noguero(at)tecnalia.com)
Nature: Enhancement
Severity: Significant
Summary:
The current version of the MARTE::GCM specification presents a mechanism to model data received and sent via ports. However, receptions are modelled in the higher level as GCMTriggers which extends UML Trigger, applicable in State Machine diagrams; while invocations are modelled using GCMInvocationActions, which extends UML InvocationAction, applicable in Activity diagrams.    For the sake of applicability I would propose to extend the GCM metamodel with extra stereotypes so that invocations can be modelled in STM and receptions can be modelled in Activity diagrams. I this wouldn't be possible I would propose to include some examples showing how this can be modelled in the later cases.

Resolution: The issue addresses two different problems. The first one regarding receptions in Activity diagrams and the second one regarding invocations in state machine diagrams. The first part of the issue can be closed, since it is possible to model this kind of receptions using UML AcceptEventActions; which can be associated with a GCMTrigger. Example 3, on Figure 12.23, illustrates this. The second part of the issue; however it is not currently covered by MARTE or UML. The proposed resolution is to add a new stereotype, GCMInvocatingBehavior, which models the invocations taking place inside a behavior without having to look at its internals (particularly interesting in the case of OpaqueBehaviors). This stereotype will allow specifying communications in the scope of a single component and independently from other components (in opposition with Interactions, which specify communications between different components, with a system wide scope).
Revised Text: see pages 138 - 141 of ptc/2010-08-30 for revised text
Actions taken:
February 23, 2010: received issue
January 14, 2011: closed issue

Discussion:
  


Issue 15096: VSL - B3.3.9 - Typos in rule <interval-bounds> (marte-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Arnaud Cuccuru, arnaud.cuccuru(at)cea.fr)
Nature: Clarification
Severity: Minor
Summary:
There are some typos and mistakes in the rule <interval-bounds>, concerning the following alternatives:  | <choiceinterval-bound> '..' <tuple-interval-bound>  | <expression-interval-bound> '..' <tuple-interval-bound>      Proposed resolution:      - Replace:   | <choiceinterval-bound> '..' <tuple-interval-bound>   by  | <choice-interval-bound> '..' <choice-interval-bound>      - Replace:  | <expression-interval-bound> '..' <tuple-interval-bound>   by  | <expression-interval-bound> '..' <expression-interval-bound>

Resolution: Follow the proposed resolution
Revised Text: In section B.3.3.9, in the description of rule <interval-bounds>, replace the erroneous alternatives as follows: - Replace: | <choiceinterval-bound> '..' <tuple-interval-bound> by | <choice-interval-bound> '..' <choice-interval-bound> - Replace: | <expression-interval-bound> '..' <tuple-interval-bound> by | <expression-interval-bound> '..' <expression-interval-bound> Disposition: Resolved
Actions taken:
March 1, 2010: received issue
January 14, 2011: closed issue

Issue 15097: VSL - B.3.3.11 and B.3.3.12 - Introducing optional keywords �Tuple� and �Choice� (marte-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Arnaud Cuccuru, arnaud.cuccuru(at)cea.fr)
Nature: Clarification
Severity: Minor
Summary:
Adding an optional keyword �Tuple� may improve readability of tuple expressions, since, depending on the context, an expression of the form �(�ValueSpecification�)� can resolve to a tuple value or a choice value. Of course, the context is enough to disambiguate the rule. The optional keyword �Tuple� would only provide a mean for making the expressions more readable from a user standpoint (note that the �Tuple� keyword is also used in OCL). For the same reason, an optional keyword �Choice� could also be added in choice expressions.    

Resolution: This issue concerns two aspects of VSL: Introduction of optional keyword for clarifying the syntax, and alignment with OCL. These two points are interesting, but only focus on some very specific aspects on the relationship between VSL and OCL. It would not make sense to address this relationship by only focusing on the keyword Tuple. That�s why this issue must be closed without changes, and a new issue, more generally related to the clarification of the links between VSL and OCL (what parts are shared, how VSL is both a short-hand notation for some OCL statements / an extension of OCL) and the adjustments that may be needed by the VSL syntax should be raised. Disposition: Closed, no change
Revised Text:
Actions taken:
March 1, 2010: received issue
January 14, 2011: closed issue

Issue 15098: VSL - B.3.3.17 - In conditional expressions, <if-false-exp> should not be optional (marte-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Arnaud Cuccuru, arnaud.cuccuru(at)cea.fr)
Nature: Clarification
Severity: Minor
Summary:
In rule <conditional-expression>, <if-false-exp> should not be optional. Otherwise, it is not clear what is the result of a ConditionalExpression in the case where <condition-expr> evaluates to false, and there is no specified <if-false-exp>  Proposed resolution:      - Replace:   <conditional-expression> ::= <condition-expr> '?' <if-true-expr> [':' <if-false-exp>]  By  <conditional-expression> ::= <condition-expr> '?' <if-true-expr> ':' <if-false-exp>

Resolution: The proposed resolution, described in the summary, would indeed avoid ambiguities, and make the usage of operators �?� �:� more conventional.
Revised Text: In section B.3.3.17 : - Replace: <conditional-expression> ::= <condition-expr> '?' <if-true-expr> [':' <if-false-exp>] By <conditional-expression> ::= <condition-expr> '?' <if-true-expr> ':' <if-false-exp> Disposition: Resolved
Actions taken:
March 1, 2010: received issue
January 14, 2011: closed issue

Issue 15099: VSL - B.3.3.15 - typos in <namespace> rule in the context of Property Call Expression (marte-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Arnaud Cuccuru, arnaud.cuccuru(at)cea.fr)
Nature: Clarification
Severity: Minor
Summary:
    In rule <namespace>, the element [�.� <namespace>] is useless and should be removed.      Proposed resolution:  - Replace:  <namespace> ::= <body-text> ['.' <namespace>]  By  <namespace> ::= <body-text>

Resolution:
Revised Text:
Actions taken:
March 1, 2010: received issue
January 14, 2011: closed issue

Discussion:
If the element [�.� <namespace>] is removed, the depth of navigation cannot be  more than 1.  Disposition: Closed, no change


Issue 15100: VSL - Absence of rule for calling behaviors (marte-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Arnaud Cuccuru, arnaud.cuccuru(at)cea.fr)
Nature: Clarification
Severity: Minor
Summary:
VSL doest not provide a rule for expressing behavior calls (i.e., it only supports call of operations). Since Behaviors are first class citizen of UML2, there is no fundamental reason for preventing this kind of expressions. Integrating a rule for calling behaviors does not require much effort (cf. following proposed resolution).      Proposed resolution:      - Modify text of B2.4 p.431 (p.443 of the pdf)  Between paragraph starting with �An Operation Call Expression�� and paragraph starting with �This metamodel does not define��, insert the following paragraph:  A Behavior Call Expression refers to a behavior defined in a UML Namespace. The expression may contain a list of argument expressions if the behavior is defined to have parameters. In this case, the number and types of the arguments must match the parameters.      - Modify figure B.4 p.432 (p.444 of the pdf) as follows:  . Add a class BehaviorCallExpression, and a generalization relationship between this class and Expression  . Add a composition relationship between BehaviorCallExpression and ValueSpecification, identical to the composition relationship between OperationCallExpression and ValueSpecification (this is to capture the arguments of the call)  . On the diagram, add an abstract class Behavior, with a grey background like classes Property and Operation.  . Add an association between BehaviorCallExpression and Behavior, identical to the association between PropertyCallExpression and Property, except that the name of the role should : definingBehavior  . Add the following derived property to BehaviorCallExpression: /behavior:String      - In section B.3.3.13:  Replace:  <expression> ::= <variable-call-expr> | <variable-declaration> | <property-callexpr>  | <operation-call-expr> | <conditional-expr>  By:  <expression> ::= <variable-call-expr> | <variable-declaration> | <property-callexpr>  | <operation-call-expr> | <behavior-call-expr> | <conditional-expr>      - p.453 (p.465 of the pdf), insert the following section (and increment the number of remaining sections):      // Beginning of section  B.3.3.17 Behavior Call Expressions  Behavior calls are particularly used in the MARTE context to call behaviors taking data type values as parameters.      <behavior-call-expr> ::= <behavior-name> '('[ <argument-value> [','<argument-value>]* ]')�  <behavior-name> ::= [<namespace> '.'] <body-text>  <namespace> ::= <body-text>      Expression typing  � The <behavior-call-expr> production rule should be evaluated to the type of the UML::Behavior that is called.  � The <argument-value> production rule must be evaluated to the corresponding to UML::Parameter's type of an existing UML::Parameter owned by the UML::Behavior.      Abstract syntax mapping  � The <behavior-call-expr> production rule maps to the BehaviorCallExpression domain element described in Annex F (Section F.13.XX).      Disambiguating rules  � <behavior-name> should correspond to an existing UML::Behavior name.  //end of section      - In annex F, insert a section F.13.1 as follows (and increment of remaining sections):      // beginning of section  F.13.1 BehaviorCallExpression (from Expressions)      Generalizations  � Expression (from Expressions) on page 560      Associations  � definingBehavior: Causality::CommonBehavior::Behavior [1]   Called Behavior.  � argument: VSL::ValueSpecification [*] {ordered}   Arguments of the Operation Call.      Attributes  � /behavior: String [1]  String with the qualified name of the called Behavior. This is a derived value obtained from the definingBehavior.      Semantics  A Behavior Call Expression refers to a behavior defined in a UML Namespace. The expression may contain a list of argument expressions if the behavior is defined to have parameters. In this case, the number and types of the arguments must match the parameters.  // end of section

Resolution: The absence of rules for calling behaviors indeed introduces an artificial limitation to the applicability of VSL. Concretely, all the available behavior signatures are currently defined following the object-oriented paradigm, in the form of operations (e.g., String.concat(String)), belonging to data types of the standard MARTE libraries. These behavior signatures could alternatively be defined following a procedural style (e.g. concat(String,String)). Designers who are familiar with procedural languages would probably feel more comfortable with this approach. Since UML natively offers support for describing behavior signatures in the procedural style, VSL should not prevent the usage of this kind of behaviors, and a rule should be added to support call of behaviors. The following figure illustrates the differences between the two paradigms, from both the perspective of libraries definitions (left hand side of the figure) and the perspective of usage in VSL (right hand side of the figure).
Revised Text: see pages 148 - 150 of ptc/2010-08-30 for revised text
Actions taken:
March 1, 2010: received issue
January 14, 2011: closed issue

Issue 15106: MARTE Beta 3: Invalid stereotype label in figure 11.8 (marte-rtf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
Figure 11.8 has an element called Memory inside an element named "p:Process[256]" that is labeled as 'app_allocated'. Unfortunately, there is no such stereotype defined in MARTE (this is probably a leftover from an earlier version)   

Resolution: Replace �app_allocated� by �allocated� as suggested. The kind �application� already has the information about the role (�app_�).
Revised Text: see page 151 of ptc/2010-08-30 for revised text
Actions taken:
September 15, 2009: received issue
January 14, 2011: closed issue

Issue 15116: Domain concept (definingEvent) not implemented in the UML representation (marte-rtf)

Click
here for this issue's archive.
Source: INRIA (Dr. Frederic Mallet, Frederic.Mallet(at)inria.fr)
Nature: Revision
Severity: Significant
Summary:
The domain view of the Time Chapter provides clocks to achieve two goals. First, Clocks give an explicit time referential for various kinds of elements.  Second, Clocks give an orthogonal mechanism to put temporal information on any events, whereas UML consider TimeEvent as a special case of events.      In the domain view, the second position was made concrete by the attribute "definingEvent" that was denoting the event from which a clock was built (occurrences of the events, where the instants of the clock). All the stereotypes provided in the UML representation address the first objective. None address the second one.    Suggested resolution, the stereotype "Clock" could extend the metaclass "Event" as well. That would allow clock constraints to constrain/specify the occurrences of events.

Resolution:
Revised Text: see page 153 - 154 of ptc/2010-08-30 for revised text
Actions taken:
March 3, 2010: received issue
January 14, 2011: closed issue

Issue 15166: Specification of real time properties at "part with port" level (marte-rtf)

Click
here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:
Currently HLAM::RtSpecification,RtFeature stereotypes allow modeling of real-time features for operations provided/required through ports at class level, while is not possible to use RtFeature/RtSpecifcation at "part with port" level. It would be useful to have this feature in order to be able differentiating quantitative attributes like deadline, period at part (i.e. instance) level in a composite structure diagram.

Resolution:
Revised Text:
Actions taken:
April 8, 2010: received issue

Issue 15261: MARTE, sterotype <<assign>>, (marte-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
problem:  Informal matching between a safety element and an architectural element.       analysis:  (1) We could introduce a new stereotype from a scratch (e.g. by extending <<trace>>) for the specific need. Its main advantage is to be optimally studied to the problem at hand. The price to pay is a new stereotype (with similar semantics to the standard ones)  � thus potentially increasing the cost for interfacing models.       (2) We could reuse <<assign>> stereotype. The main drawback is a semantic overlapping with the original MARTE stereotype. However, the main advantage is that we reduce the number of concepts that a (safety) designer should manage � thus potentially increasing in usability.  In this solution, stereotype <<assign>> must have:  kind = hybrid and nature = spatialDistribution. In order to do it, we are forced to generalized stereotype <<assign>> with a new stereotype with fixed    values for both ''kind'' and ''nature''       proposed solution (by Bran Selic):  (a) provide additional enumeration literals for these two attributes of <<assign>> or (b) make them optional by changing their multiplicity from [1] to [0..1]. Note that these are not mutually exclusive choices and it might make sense to realize them both. Making these attributes optional will certainly improve on the generality of <<assign>>, so that it can be used to model other types of "allocation" relationships      project:  IMOFIS project of the System@tic  Paris R�egion Cluster. It is sponsored by the �Safe, reliable and adapted transportation�  program (PREDIT) of the �Agence Nationale pour la Recherche�.      Impact on the Industrial Context:  The development of critical systems involves the interplay of many different disciplines and, therefore, becomes particularly complex. In this context, the industrial and academic communities are paying increasing attention to safety issues.  The resolution of the open issue improves the integration of safety analyses in a model-based engineering approach, where MARTE is used to specify a subset of the architecture.

Resolution:
Revised Text:
Actions taken:
May 20, 2010: received issue

Issue 15275: The notion of "access connection" needs to be explicited in the AADL annex (A.2) of MARTE (marte-rtf)

Click
here for this issue's archive.
Source: THALES (Dr. Madeleine Faugere, madeleine.faugere(at)thalesgroup.com)
Nature: Uncategorized Issue
Severity:
Summary:
The notion of "access connection" needs to be explicited in the AADL annex (A.2) of MARTE

Resolution:
Revised Text:
Actions taken:
June 5, 2010: received issue

Issue 15291: ImpliesConstraint of Allocate and Assign relationships (marte-rtf)

Click
here for this issue's archive.
Source: Airbus Group (Mr. Yves Bernard, yves.bernard(at)airbus.com)
Nature: Uncategorized Issue
Severity:
Summary:
According to its definition, the impliesConstraint association of both Allocate and Assign stereotypes should be a composition and not a simple reference

Resolution:
Revised Text:
Actions taken:
June 16, 2010: received issue

Discussion:
  


Issue 15292: GRM:Support for Time table driven schedules (marte-rtf)

Click
here for this issue's archive.
Source: Universidad de Cantabria (Dr. Julio Medina, julio.medina(at)unican.es)
Nature: Uncategorized Issue
Severity:
Summary:
MARTE, formal/2009-11-02, GRM chapter, pag 96-97, enhancement      GRM:Support for Time table driven schedules.      Having the opaque expression attribute "schedule" in the Scheduler in GRM lead to a very open way of expressing fixed schedules or non-traditional scheduling policies. This is the case of time triggered sets of tasks in particular, but also of any form of table driven schedule. Following a general approach but formalizing the way of expressing schedules as a set of labeled timed windows would make the exchange of information between strict time triggered platforms design intent and its corresponding analysis models easier and in a standardized way.      An alternative to study may be formalizing the attribute �schedule� of a scheduler to include at least the frame_cycle_time, and the list of �windows� or �time_slots� to be managed as schedulable resources. To do this the easiest way may be to make them part of a list inside the schedule indexed by a key that match the scheduling parameters field of the schedulable resources that are attached to the scheduler.    

Resolution: The current structure grants the designer the capacity of describing the schedule to use by means of an opaque expression, and the scheduling parameters for the table driven policy in the way of an open format string. In order to facilitate the description of more precise and standardized schedules, a concrete format for these types has been proposed. The necessary attributes are presented. For the scheduler the attribute �schedule� will be formalized to include at least the frame_cycle_time, and the list of �windows� or �time_slots� for the partitions, for doing this there are two alternatives (a) make them part of a list inside the schedule indexed by a key that match the scheduling parameters field of the schedulable resources that are attached to the scheduler, or (b) compose the list by considering the allocated schedulable resources with their corresponding schedulingParameters, changing the current type string used for the TableEntry field into the necessary time_slot data type tuple. Alternative (a) is easier to set into the standard and the models are easier to check for consistency, hence is the one proposed. It comprises the formalization of the opaque expression used for the attribute �schedule� into a structure like the one shown in the next figure:
Revised Text: see pages 156 - 162 of ptc/2010-08-30 for revised text
Actions taken:
June 27, 2010: received issue
January 14, 2011: closed issue

Issue 15310: GRM:Support for Time table driven schedules (marte-rtf)

Click
here for this issue's archive.
Source: Universidad de Cantabria (Dr. Julio Medina, julio.medina(at)unican.es)
Nature: Enhancement
Severity: Significant
Summary:
Having the opaque expresion attribute "schedule" in the Scheduler in GRM lead to a very open way of expressing fixed schedules or non-traditional scheduling policies. This is the case of time triggered sets of tasks in particular, but also of any form of table driven schedule, like IMA platforms. Following a general approach but formalizing the way of expressing schedules as a set of labeled timed windows would make the exchange of information between strict time triggered platforms design intent and its corresponding analysis models easyer and in a standardized way.      An alternative to study may be formalizing the attribute �schedule� of a scheduler to include at least the frame_cycle_time, and the list of �windows� or �time_slots� to be managed as schedulable resources. To do this the easiest way may be to make them part of a list inside the schedule indexed by a key that match the scheduling parameters field of the schedulable resources that are attached to the scheduler.

Resolution:
Revised Text:
Actions taken:
June 26, 2010: received issue

Issue 15377: RequestEventStream changed by WorkloadEvent (marte-rtf)

Click
here for this issue's archive.
Source: Universidad de Cantabria (Dr. Julio Medina, julio.medina(at)unican.es)
Nature: Clarification
Severity: Significant
Summary:
The term RequestEventStream is still used in GQAM, and in Annexes F and H while the concept has been refurbished as WorkloadEvent and others. Make all of them consistent.

Resolution: The change from RequestEventStream to WorkloadEvent needs to be completed. The sections where it appears still in the text are: annex H, some texts in GQAM and PAM and many sections in Annex F: 10.19, 10.14, 10.21, 11.1, 12.1, 12.3, 12.4
Revised Text: Change text: (search for requestEvent) In Section 17.2.2.3 Workload, change the paragraph: �Behavior is initiated by a request event. An open workload is a RequestEventStream in which the events arrive at a given rate in some predetermined pattern (such as clocked or Poisson arrivals), or by a trace.� By �Behavior is initiated by a workload event. An open workload is a WorloadEvent in which the events arrive at a given rate in some predetermined pattern (such as clocked or Poisson arrivals), or by a trace.� Towards the end of section 17.4.6 Example 6: State machine annotations Change text: �A second use of a state machine is to define a sequence of operations, like an interaction diagram. This must be a behavior that terminates, and its start point is driven by a RequestEventStream.� By �A second use of a state machine is to define a sequence of operations, like an interaction diagram. This must be a behavior that terminates, and its start point is driven by a WorkloadEvent.� In section F.10.3 BehaviorScenario Change association: � inputStream: RequestEventStream [1..*] RequestEventStream that initiates it. By � cause: WorkloadEvent [1..*] The requesting event stream that initiates it. Change Constraint [1] The same BehaviorScenario may be associated with one or more RequestEventStreams within the same AnalysisContext. By [1] The same BehaviorScenario may be associated with one or more WorkloadEvent within the same AnalysisContext. In section F.10.7 EventTrace Change its description from: �A trace of events that can be the source for the request event stream.� To �A trace of events that can be the source for the workload event stream.� Change the association: � stream: RequestEventStream [1] Indicates the event stream driven by the trace. To � stream: WorkloadEvent [1] Indicates the workload event stream driven by the trace. In section F.10.14 RequestEventStream Change the name of the section from RequestEventStream to WorkloadEvent Eliminate Attribute � type: EventStreamKind [0..1] One of the following enumeration values: {Generator, Pattern, Trace, Timed} which indicates how the request events are obtained. Change attribute: From: � pattern: ArrivalPattern [0..1] If the type value is Pattern, then this attribute of type ArrivalPattern (which is a dataType imported from the model library of Basic::NFPTypes) describes it. To: � pattern: ArrivalPattern [0..1] If this attribute is present it describes the pattern of events generated. Change the constraint from: �[1] The type attribute determines which source of events defines the stream, and the optional association or attribute for that type must be defined.� To: �[1] Only one among the three associations: generator trace and timedEvent, and the attribute pattern may be present.� Eliminate section F.10.20 WorkloadEvent In section F.10.19 WorkloadBehavior Change associations from: � demand: RequestEventStream [*] Indicates the request event streams that are part of this container. � behavior: BehaviourScenario [*] Indicates the set of system behaviors used for analysis. To: � demand: WorkloadEvent [1..*] Indicates the workload event streams that are part of this container. � behavior: BehaviorScenario [1..*] Indicates the set of system behaviors used for analysis. In section F.10.21 WorkloadGenerator Change association from: � behavior: RequestEventStream [*] To: � behavior: WorkloadEvent [*] Change constraint: [1] One generator may trigger several RequestEventStreams, and one Behavior may be triggered by several generators By: [1] One generator may trigger several WorkloadEvents, and one Behavior may be triggered by several generators In section F.11.1 EndToEndFlow Change association: � endToEndStimuli: RequestEventStream [1..*] Set of request event stream that trigger the processing flow. To � endToEndStimuli: WorkloadEvent [1..*] Set of workload events that trigger the processing flow. In Annex H Change the mapping for element SAtrigger from RequestEventStream to WorkloadEvent In Section F.12PAM there are several concepts previously removed, which are now not related to the text in the PAM section, please delete them as editorial changes.
Actions taken:
July 20, 2010: received issue
January 14, 2011: closed issue

Issue 15432: The DurationUnitKind doesn't exist any more (marte-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:
The DurationUnitKind described in the D.2.10 NFP-Duration section, doesn't exist any more.    "unit" should be a TimeUnitKind as described in the figure 8.6, page 48.

Resolution:
Revised Text:
Actions taken:
August 27, 2010: received issue

Issue 15433: The IntervalType attributes are not the same ones in the profil diagram and profil elements description (marte-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
page 436, the IntervalType has the "intervalAttrib" attribute.      page 451, the IntervalType has both "minAttrib" and "maxAttrib" attributes.    The IntervalType attribute(s) should be the same ones.

Resolution:
Revised Text:
Actions taken:
August 27, 2010: received issue

Issue 15434: The "Mb/s" baseUnit should be "Kb/s". (marte-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:
In the DataTxRateUnitKind dimension, the "Mb/s" baseUnit should be "Kb/s" (and convFactor = 1024) or the convFactor should be 1048576 (and baseUnit = "b/s").

Resolution:
Revised Text:
Actions taken:
August 27, 2010: received issue

Issue 15659: Precise the shape of an array of ports of an array of parts (marte-rtf)

Click
here for this issue's archive.
Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de)
Nature: Clarification
Severity: Significant
Summary:
When a shaped port belongs to a shaped part, one should understand its shape as the product of both shapes as stated in the definition of the tiler. This should be stated here for the case when the reshape stereotype can be ommitted.

Resolution:
Revised Text:
Actions taken:
September 28, 2010: received issue
October 21, 2011: transferred to MARTE 1.1 RTF from UTP 1.1 RTF

Issue 15660: Constraint 6 on the tiler is just "Notation", this should be precised (marte-rtf)

Click
here for this issue's archive.
Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de)
Nature: Clarification
Severity: Minor
Summary:
What does this "Notation" means? Either remove it or precise it.

Resolution:
Revised Text:
Actions taken:
September 28, 2010: received issue

Issue 15727: The semantics of the Reshape should be precised (marte-rtf)

Click
here for this issue's archive.
Source: INRIA (Mr. Pierre Boulet, Pierre.Boulet(at)lifl.fr)
Nature: Clarification
Severity: Significant
Summary:
The current specification is ambiguous and should be refined.    The issue is the way the elements of the tiles are connected from one end to the other. This connection should be point-to-point.

Resolution:
Revised Text:
Actions taken:
October 14, 2010: received issue

Discussion:
  


Issue 16010: a verb is missed in last sentence of first � (marte-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Pr. Dr. Fran�ois Terrier, francois.terrier(at)cea.fr)
Nature: Enhancement
Severity: Minor
Summary:
in the sentence:  -------------  Hence, the idea to associate time structure with events, behaviors, and objects, or more  generally instances of the concrete subtypes of the BehavioredClassifier metaclass.  -------------      it seems that a verb is missed... perhaps this could be reformulated as:  ---------------  Hence, the idea is to associate time structure with events, behaviors, and objects, or more  generally instances of the concrete subtypes of the BehavioredClassifier metaclass.  

Resolution:
Revised Text:
Actions taken:
February 7, 2011: received issue

Issue 16012: ClientServerFeature: possible ambiguity on provided/required status of signal reception (marte-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Pr. Dr. Fran�ois Terrier, francois.terrier(at)cea.fr)
Nature: Clarification
Severity: Minor
Summary:
in the following sentence:  ------------  If kind is required it is expected to be a required operation or signal reception while if kind is provided, it is expected to be a provided operation or signal reception.  ------------      it would be more explicit to precise that signal receptions are respectively also "required" and "provided", e.g.:  ---------------  If kind is required it is expected to be a required operation or a required signal reception while if kind is provided, it is expected to be a provided operation or a provided signal reception.  ---------------   

Resolution:
Revised Text:
Actions taken:
February 7, 2011: received issue

Issue 16158: Missing HwRouter stereotype to allow modeling of Networks-on-Chips (marte-rtf)

Click
here for this issue's archive.
Source: INRIA (Mr. Pierre Boulet, Pierre.Boulet(at)lifl.fr)
Nature: Enhancement
Severity: Significant
Summary:
An extension to the HwMedia stereotype should be added to allow the modeling of Networks-on-Chips in addition to buses as the become more and more the communication media of choice for new generation systems-on-chips.      This HwRouter stereotype could have the following attributes:  + fifoSize: NFP_DataSize  + isRoutingAdaptative: NFP_Boolean  + switchingType: SwitchingType  + isSynchronous: NFP_Boolean  + fifoLocation: FifoLocationSpecification      with the following definition of SwitchingType:  �Enumeration�  SwitchingType  paquetSwitching  circuitSwitching  other  undefined      and of FifoLocationSpecification:  �Enumeration�  FifoLocationSpecification  input  output  both

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Issue 16162: VSL, Section B.3.3.9. The following attributes are missing (see figure B.7): (marte-rtf)

Click
here for this issue's archive.
Source: Fundacion Tecnalia Research and Innovation (Mr. Huascar Espinoza Ph.D., Huascar.Espinoza(at)tecnalia.com)
Nature: Uncategorized Issue
Severity:
Summary:
VSL, Section B.3.3.9. The following attributes are missing (see figure B.7):         baseType : VSL::DataTypes::DataType [1] Designates an ordered DataType.    ..    isMinOpen: Boolean [0..1] Defines if minValue is excluded in the bounded value space.    isMaxOpen: Boolean [0..1] Defines if maxValue is excluded in the bounded value space.        

Resolution:
Revised Text:
Actions taken:
April 29, 2011: received issue

Issue 16224: Coherency between active resource of MARTE and active class in UML (marte-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Clarification
Severity: Minor
Summary:
In GRM, a Resource may be active. MARTE needs to specify the relationship(coherency) between an active resource and and active class.

Resolution:
Revised Text:
Actions taken:
May 11, 2011: received issue

Issue 16229: Typo in diagram 14.25 for stereotype SwSchedulableResource (marte-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Clarification
Severity: Minor
Summary:
Attribute schedulers : NamedElement [1] of SwSchedulableResource should be "scheduler : NamedElement [1]"

Resolution:
Revised Text:
Actions taken:
May 12, 2011: received issue

Issue 16247: Update Table of Contents (marte-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Irv Badr, ibadr(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:
Updated Table of Contents to reflect topics according to updated formatting   

Resolution:
Revised Text:
Actions taken:
May 17, 2011: received issue

Issue 16248: Page 269: Section 14.2.3.2, Stereotype Descriptions (marte-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Irv Badr, ibadr(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:
Add the following :   McProcessor   The McProcessor stereotype maps the McProcessor domain element   Generalizations   HwProcessor   Attributes   Core_Id: NFP_Natural   

Resolution:
Revised Text:
Actions taken:
May 17, 2011: received issue

Issue 16583: Flow properties cannot be characterized with an RtSpecification (marte-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Arnaud Cuccuru, arnaud.cuccuru(at)cea.fr)
Nature: Clarification
Severity: Minor
Summary:
The type of the derived property RtSpecification::context is BehavioralFeature. It can be used to specify that the RtSpecification actually concerns a particular behavioral feature (i.e. Operation or Reception) exposed by a port (the port being identified by the RtFeature owning this RtSpecification).      This works well with ClientServer ports. However, it cannot be used to characterize flow properties of FlowPort, since a FlowProperty is a StructuralFeature, not a BehavioralFeature.    An easy solution to address that is to make the type of /context Feature, instead of BehavioralFeature.

Resolution:
Revised Text:
Actions taken:
October 6, 2011: received issue

Issue 16609: MARTE Clocks (marte-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Uncategorized Issue
Severity:
Summary:
In the time chapter, I was reading the following sentence in clause 9.3.1.1: �When the property "on" is not specified, it should be understood as being by default, a dense chronometric clock with no flaws that represent the physical time.�    However, the lower bound of the multiplicity of the on role from TimedElement to Clock is one, meaning that one value at least has to be specified. May the aforementioned sentence should be repharsed, isn�t?    

Resolution:
Revised Text:
Actions taken:
October 15, 2011: received issue

Issue 16835: Allocations kind and nature (marte-rtf)

Click
here for this issue's archive.
Source: Airbus Group (Mr. Yves Bernard, yves.bernard(at)airbus.com)
Nature: Uncategorized Issue
Severity:
Summary:
There are many possible usages for the Allocation concept which cannot be restricted to those listed in the AllocationKind and AllocationNature enumerations.     The �kind� and �nature� attribute of both <<Allocate>> and <<Assign>> stereotypes should be optional (multiplicity: [0..1]). Alternatively, a literal could be added to the enumerations named above, such as �unspecified� or �other�, to address usages which are not covered by the existing literals.  

Resolution:
Revised Text:
Actions taken:
November 30, 2011: received issue

Issue 17339: TIME model overview: consistency of bullet descriptions (marte-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
problem:  In section Overview of the time model chapter, there are three bullets to describe the time. In these bullet titles, the slash ('/') character has different meaning:         * Causal/temporal --> it should be understood as causal vs temporal    * Clocked/synchronous --> it should be understood as Clocked or synchronous    * Physical/real-time --> it should be understood as Physical or real-time        proposed resolution:      the bullet should be renamed with:              * Causal (untimed):          * Synchronous (partially timed):          * Physical (real-time):      additionally, to keep consistency, the last sentence of the last bullet should be rephrased, for instance with :  "Physical time models refine the partially timed models by adding reference(s) to one or more physical dimensions, for instance to derive the admissible speed of a reaction."

Resolution:
Revised Text:
Actions taken:
April 27, 2012: received issue

Issue 17340: TIME model: reference to TimeStructureRelation Library does not exists (marte-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
problem:      In section 9.2.2.2 (concrete time base relations) of the time model chapter, there is the following sentence: "Predefined time base relations are suggested in the TimeStructureRelation Library of MARTE. The semantics of these relations is given in OCL.". However, the TimeStructureRelation Library does not exist in the specification.       proposed resolution:    There exists a description of predefined time base relations in the annex C. We propose to modify the text as well as the example depicted figure 9.7 to conform with the existing predefined time base relations.

Resolution:
Revised Text:
Actions taken:
April 27, 2012: received issue

Issue 17341: TIME model: name of referred section and name of section differ (marte-rtf)

Click
here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:
problem:      In section 9.2.4.2 (concrete time base relations) of the time model chapter, there is the following sentence: "Clock constraint specifications are special value specifications described in Annex C (Clock Constraint Specification Language)". However, the reference should be to annex C.3 and the named of annex C.3 is "Clock Constraint Specification".       proposed resolution:      change annex C to annex C.3 in the text of chapter 9.2.4.2.  rename the annex C.3 as "Clock Constraint Specification Language"

Resolution:
Revised Text:
Actions taken:
April 27, 2012: received issue

Issue 17342: TIME model: wrong section name (marte-rtf)

Click
here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:
problem:      Section 9.2.4.5.2 is named "The timeEvent Package". It should be named "The TimedEvent Package"      proposed resolution:    rename section 9.2.4.5.2 as "The TimedEvent Package"

Resolution:
Revised Text:
Actions taken:
April 27, 2012: received issue

Issue 17343: TIME model: clarification of ClockConstraint properties (marte-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
problem:      In section 9.3.1.3, on figure 9.28, the ClockConstraint stereotype have three properties named "isCoincidenceBased", "isPrecedenceBased", "isChronometricBased". These three attributes refers to the kind of relation(s) resulting from the constraint enforcement. This kind of relation are described by three named bullets in the time model overview, chapter 9.1. The name of the bullets and the name of the properties should conform. These properties are described in section 9.3.2.2, the names should also refer to the bullet names.      proposed resolution:    rename the properties of the ClockConstraint stereotype to conform with the name of the bullet in section 9.1. The section 9.3.2.2 should be kept consistent with such changes.

Resolution:
Revised Text:
Actions taken:
April 27, 2012: received issue

Issue 17344: TIME model: examples should be more pedagogical (marte-rtf)

Click
here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:
problem:    In section 9.3.3 (Examples) from the time model, the examples describe some complex and pathological cases, which reflect the good expressiveness of the time model. These examples should perhaps be simplified to help the reader understanding classical/intended use of the time model in its design.

Resolution:
Revised Text:
Actions taken:
April 27, 2012: received issue

Issue 18165: Missing syncronization resource in UML mapping for PpUnit (marte-rtf)

Click
here for this issue's archive.
Nature: Enhancement
Severity: Critical
Summary:
We have detected an inconsistency between the semantic description and its mapping to UML for Protected Passive Unit (PpUnit). In figure 13.3 and in the Annex F.7.7, PpUnit inherits from BehavioredClassifier and SynchResource. But when you see the UML Representation (Section 13.3) in Figure 13.8, the PpUnit inheritance from BehavioredClassifier is taken into account by using it as the base elements to be extended with the stereotype. Its nature as synchronization resource is not explicitly mapped to UML.   For these reasons, and considering the need to link a PpUnit with its implementing mutual exclusion resources that we propose a PpUnit to have an additional attribute (with multiplicity 0..n) that includes the MutualExclusionResource that the existence of the PpUnit implies. Being a GRM:: MutualExclusionResource  a specialization of SynchResource, this attribute maps the synchronization resource nature of the PpUnit as it is expressed in its definition in the Annex F.

Resolution:
Revised Text:
Actions taken:
October 10, 2012: received issue

Issue 18249: MARTE: VSL short form for NFP_Real subtypes (marte-rtf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
There are numerous examples in the MARTE spec that show the use of tuple value expressions of the form (v, u), where v is the value and u is the unit (e.g., (50, ms)) to specify the value of a subtype of NFP_Real (e.g., NFP_Duration, NFP_Weight, etc.). However, based on how tuple expressions work, this is not valid, since, without additional information, the parser cannot know which attributes are being assigned these two values. Note that subtypes of NFP_Real can have many attributes (e.g., NFP_Duration has 11 attributes) and most of them have at least two Real-type attributes. Based on that, in an expression such as (50, ms), it is not possible to determine which attribute is being assigned the value 50 (e.g., in case of NFP_Duration, it could be either the "value" attribute, the "precision" attribute, the "worst" attribute, or the "best" attribute).    VSL does allow label-less expressions of this type, but, that can only work if the list of values follows the order in which the attributes appear (which, actually, is not quite clear from the spec), and if the use of the default or null literals is used for entries that are not assigned. For example, for an NFP duration of 50 milliseconds, the proper lable-less expression looks like it should be: (null, null, null,null, null, 50, ms, null, null, null, null), or, alternatively (-, -, -, -, -, 50, ms, -, -, -, -). Clearly, this is far too cumbersome for practical application.     One possible solution is to have VSL recognize the special and most common by far case of subtypes of NFP_Real, allowing a short form in cases where only the value and unit need to be specified (leaving the other attribute values to default). This short form would, naturally, be the (v, u) form. That would make the common form currently used in the spec valid.   

Resolution:
Revised Text:
Actions taken:
November 6, 2012: received issue

Issue 18547: Typos issues in GQAM (marte-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Clarification
Severity: Minor
Summary:
Diagram shown in 15.7 contains a set of inconsistencies:  -       Multiplicity of GaWorkloadEvent::cause is 1 and not [0..1]  -       Change GaWorkloadEvent::timeEvent: timeEvent into �GaWorkloadEvent::timeEvent: TimeEvent�  -       Multiplicity of the GaScenario::cause property is [1..*]. This multiplicity shall be shown on the diagram.  -       Type of GaScenario::timing should be GaTimedObs instead of GaTimingOberver that does not exist anymore.  -       The association between GaWorkloadEvent and TimeEvent should be removed.      p. 300, in the attributes section of the �15.3.2.2 GaAnalysisContext�, ref to B.3.3.12 should be B.3.3.13.      p. 309, as denoted in the diagram shown in Figure 15.7, �effect:GaScenario [1]� should be listed in the attributes section and not in the list of associations.

Resolution:
Revised Text:
Actions taken:
March 13, 2013: received issue

Issue 18565: Refinement issue from GQAM to SAM (marte-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Clarification
Severity: Minor
Summary:
The domain model of SAM defines the concept of EndToEndFLow which is described as being a container for a set of request event streams that trigger processing flows (identified as WorkloadEvent in the figure 16.3) and a set of end-to-end execution scenario (identified as BehaviorScenario in the figure 16.3) as response to a related set of request event stream.      The domain model of GQAM defines the of WorkloadBehavior which is described as being a container for a set of behaviors defined as Scenario and a set of demands defined as WorkloadEvent. WorkloadEvent are defined as the cause of the Scenario. In this context, this latter is considered as being the effect of a WorkloadEvent.      This specification raises both next issues:  -       Firstly, the stereotype �SaEndToEndFLow� introduced to map the SAM domain model element EndToEndFLow does not have properties fitting the endToEndStimuli and endToEndResponse properties of this latter. Consequently, the specification of stimuli and responses of a SaEndToEndFlow has to be done implicitly within the user model using containment relationships of the UML. The issue with such modeling mean is that the relationship between the SaEndToEndFlow and its containment is less formal and relies on specific means/choices to model the link between the SaEndToEndFLow and its stimuli and scenarios.  -       Secondly, the duality between both concepts, EndToEndFLow and WorkloadBehavior, seems to introduce unnecessary complexity. I would like to propose to define EndToEndFlow as a specialization of WorkloadBehavior, where both endToEndStimuli and endToEndResponse would refine respectively demand and behavior properties of the WorkloadBehavior concept.      Miscellaneous:  -       In figure 16.3, EndToEndFLow has an association toward SAM_Obsrever::TimedObserver. A priori, it should be SchedulingObserver instead of TimedObsever.  -       In section �16.3.2.7 SaSchedObs�, SaSchedObs should inherit from GaTimedObs and not TimedObs as shown in figure 16.8.  -       In section �16.3.2.1 SaEndToEndFlow�, the timing attribute should be typed as SaSchedObs and not TimedObs.

Resolution:
Revised Text:
Actions taken:
March 16, 2013: received issue

Issue 18567: Questions on observators within GQAM and SAM (marte-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Uncategorized Issue
Severity:
Summary:
     I was wondering, why two kinds of observators was designed within the GQAM as denoted in the figure shown below:                        Why not gathering both into one single stereotype? I propose to keep the second one, GaLatencyObs.         In addition, I was also wondering why the <<SaSchedObs>> stereotype defined within SAM was not inheriting from <<GaLatencyObs>> instead of <<GaTimedObs>>?         What do you think?    

Resolution:
Revised Text:
Actions taken:
March 19, 2013: received issue

Issue 18576: �GaWorkloadGenerator� and its pop attribute (marte-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Clarification
Severity:
Summary:
Can someone clarify the meaning of the pop attribute of the �GaWorkloadGenerator� stereotype?    

Resolution:
Revised Text:
Actions taken:
March 25, 2013: received issue

Issue 18581: About Gacenario:: (marte-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Uncategorized Issue
Severity:
Summary:
GaScenario has the attribute utilization. Its definition is : �The occupancy of the scenario, computed as the mean number of scenario instances active at any one time.�. What does �occupancy� mean?  

Resolution:
Revised Text:
Actions taken:
March 26, 2013: received issue

Issue 18657: MARTE issue: Observation does not allow specification of time value (marte-rtf)

Click
here for this issue's archive.
Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:
In the current UML metamodel, there is no link from the metaclass Observation to a ValueSpecificaiton that can be used to specify the time value of the Observation. As a result, it is not possible to directly assign time values to TimedInstantObservation or TimedDurationObservation.      This means that it is not possible to refer to the time values of such observations in a time expression.      One easy solution is to create an association from the TimedObservation stereotype to the UML ValueSpecification metaclass (role name "value"). This could then be used to store the time value associated with either kind of time observation.  

Resolution:
Revised Text:
Actions taken:
April 12, 2013: received issue