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

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 14435: Meta class BehaviorScenario not synchronized with its representation (marte-rtf)

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

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)

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)

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