Issues for UML Profile for MARTE Finalization Task Force

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 11112: UML Profile for MARTE acronym list (marte-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

The MARTE spec has a large number of Acronyms.      Some (e.g. MARTE) are not expanded anywhere in the spec.      It would be helpful to the reader to have a common section of the document to fully expand all acronyms used in the spec.      Proposed resolution:  Place a table of acronym expansions in the now empty Symbols section of the spec (perhaps relabeling the section as Symbols and Acronyms)

Resolution:
Revised Text:
Actions taken:
June 26, 2007: received issue
October 16, 2009: closed issue

Discussion:

The beta2 specification already has the requested table of acronyms.  Recommendation is therefore to Close No Change the issue.  Disposition: Closed, no change

Issue 11163: Consider adding a new attribute to �boundedSubtype� (marte-ftf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Consider adding a new attribute to �boundedSubtype� to specify what the default value for the new type is.  Something like <<boundedSubtype>>.defaultValue

Resolution: Resolution: A BoundedSubtype, as other data types, defines a space of valid values. However, it doesn't describe any particular value property. Specifying a default value is to be done at property declaration level, and it's already supported by UML itself. This approach is natural from a pragmatic viewpoint (different properties typed by the proposed BoundedSubtypes could have different default values), and from the general practice in (modeling, programming) languages. For these reasons, we don't add default values for BoundedSubtype, or whatever data types. Disposition: Closed, no change
Revised Text:
Actions taken:
July 19, 2007: received issue
February 17, 2010: closed issue

Issue 11337: Naming conventions and typing errors (marte-ftf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Naming conventions and typing errors: - MARTE::MARTE_Foundations::GRM::GRService -> GrService for coherence - MARTE_Library::GRM_BasicTypes::EDFParameters -> EDF_Parameters or EdfParameters - MARTE::MARTE_AnalysisModel::SAM::SaSchedObs::suspentions -> suspensions

Resolution: The convention of using uppercase for the prefixes would have been more consistent with the English style, but it has been almost consistently used along the spec the capitalization of only the first letter to reduce space, for this reason is probably better to just correct GRService in GRM as well as EDFParameters suspentios is clearly a typo to correct.
Revised Text: Replace GRService by GrService in Figures 10.17, 14.25, 14.66, 14.73 and in sections 10.3.1, 10.3.2.1, 10.3.2.8, 10.3.2.11, 14.1.3.2(pag196), Replace EDFParameters by EDF_Parameters in Figures 10.19, D.9, and in sections 10.3.3.1, 10.3.3.8
Actions taken:
September 10, 2007: received issue
February 17, 2010: closed issue

Issue 11338: MARTE_Library::MeasurementUnits model library (marte-ftf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Chokri Mraidha, chokri.mraidha(at)cea.fr)
Nature: Clarification
Severity: Significant
Summary:

MARTE_Library::MeasurementUnits model library contains following bugs. In FrequencyUnitKind enumeration baseUnit tag value specified is W instead of Hz. In LenghtUnitKind enumeration baseUnit tag value is m for mm literal. In AreaUnitKind enumeration baseUnit tag value is mm2 for um2 litreal. In DataTxRateUnitKind convaFactor is 1024 instead of 1E3.

Resolution: Modify Figures D.3 according to proposed corrections.
Revised Text: see issue resolution in ptc/2008-06-05
Actions taken:
September 10, 2007: received issue
February 17, 2010: closed issue

Issue 11339: Section: Annex B3.3.3 (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

The <value-specification> rule references an <opaque-expression> rule that is not defined in the VSL grammar.

Resolution: VSL expressions are specified in OpaqueExpressions. Adding new opaque expressions within a VSL expression would make VSL expressions complex, and without a real added value. Hence, we do not support in VSL nested expressions written in new languages. Note that this doesn't mean that we do not allow one to extend VSL. VSL can be extended by reusing its metaclasses, as the Clock Constraint Language in MARTE. Hence, the term <opaque-expression> in the VSL grammar is not right. This resolution proposes to remove that term from the VSL grammar.
Revised Text: In section B.3.3, page 397, remove the <opaque-expression> term: The new rule for <value-specification> will be <value-specification> ::= <literal> | <enum-specification> | <interval> | <collection> | <tuple> | <choice> | <expression> | <time-expression> | <obsCallExpression>
Actions taken:
September 11, 2007: received issue
February 17, 2010: closed issue

Issue 11340: Section: Annex B3.3.3 p 397 (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

A circular reference between the <value-specification> -> <time-expression> -> <instant-expr> -> <value-specification> rules prevents a straightforward implementation of the VSL BNF grammar.

Resolution: We modify the grammar for time expressions to prevent the circular reference.
Revised Text: -In Section B.3.3.17, replace the second and third rules by: <instant-expr> ::= ( ( <datetime-literal> | <variable-call-expr> ) ['+' <duration-expr>] ) | ( <instant-obs-expr> [ '+' <duration-expr> ] ) <duration-expr> ::= ( <real-literal> | <variable-call-expr> ) | <duration-obs-expr> | ( '(' <instant-obs-expr> '-' <instant-obs-expr> ')' )
Actions taken:
September 11, 2007: received issue
February 17, 2010: closed issue

Issue 11402: concept of "resource" (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Uncategorized Issue
Severity:
Summary:

The General Resource Model of MARTE seems to define the concept of "resource" both at the instance and classifier levels. For instance, the GRM::Resource stereotype extends both InstanceSpecification and Classifier.    The SwResource stereotype defined in the Software Resource Model of MARTE specializes the GRM::Resource stereotype. However, reading the SRM chapter, it seems that its use is much more focused on description of classifiers (to characterize properties or behavioral features for instance) than instances.    In that context, does it make sense to apply a SRM::SwResource stereotype or one of its subclasses (for instance SRM::SwSchedulableResource) on an instance specification? Note that it seems to be legal given that SRM::SwResource specializes GRM::Resource, which extends InstanceSpecification.      I would be pretty handy to do so, in order to describe a resource platform model provided in input of a scheduling analysis.

Resolution: Complete the paragraph 7.3 with the rules for the default values of attributes of the stereotypes for instance of classifiers also stereotyped.
Revised Text: Add the following paragraph to section 7.3: When a stereotype is applied on an instance, and provided it can be also applied on classifiers, the value of the attributes not explicitly assigned in the annotation of the instance are taken in principle from the defaults in the profile stereotype definition, but they might be overridden by those in its corresponding classifier, if it happens to be annotated with the same stereotype.
Actions taken:
September 13, 2007: received issue
February 17, 2010: closed issue

Issue 11411: Section: GRM / 10.3.1 (marte-ftf)

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

The GRM packages defines a <<SchedulableResource>> stereotype. The SRM package, which is presented as a specialization of GRM to model software resources, defines a stereotype with a similar name: <<SwSchedulableResource>>. However, there is no direct link between these two stereotypes. GRM::SchedulableResource directly specializes GRM::Resource, while SRM::SwSchedulableResource specializes SRM::SwConcurencyResource, which specializes SRM::SwResource, which specializes GRM::Resource. Stereotypes have quite similar name, which may think of related concepts. However, their use and their related stereotype attributes are quite different.

Resolution: Make stereotype SwSchedulableResource inherit from SchedulableResource. Since this inheritance is already present in the domain view, the sections to modify comprise only the UML representation of SRM.
Revised Text: see ptc/2009-05-12 page 12
Actions taken:
September 14, 2007: received issue
October 16, 2009: closed issue

Discussion:

Discussion: The link between both is its semantics...., which is expressed in the domain view. Same thing happens in issue 11412. The stereotypes just happen to be not strongly related (by inheritance i.e.) because they are used for different purposes. SRM is basically attached to its usage to create OS utilitarian model libraries, GRM stuff if used to architect the problem and analysed/verify the problem and the solutions. Hence the links are to be provided when necessary by the semantics-aware transformations among tools that deal with both worlds Resolution: The adequate solution is to make SwSchedulableResource inherit from SchedulableResource, which simplifies the annotations the user needs to do, or simply close the issue. But it has caused some polemics, see issue 11856 (synchronization between GRM, SRM, HRM and Analysis). For this reason, this issue is deferred. The link between both is its semantics...., which is expressed in the domain view. Same thing happens in issue 11412. The stereotypes just happened to be not strongly related (i.e. by inheritance) because they are typically used for different purposes. SW stuff is basically attached to its implementation, GRM stuff if used to architect the problem and analysed/verify the problem and the solutions. Hence the links were to be provided when necessary by the semantics-aware transformations among tools that deal with both worlds. The adequate solution is to make SwSchedulableResource inherit from SchedulableResource, this simplifies the annotations. This has been thoroughly discussed in the December 2008 Technical Meeting, and has been resolved in coordination with issues 11412 and 11856 (synchronization between GRM, SRM, HRM and Analysis

Issue 11412: Section: GRM / 10.3.1 - p 96 (marte-ftf)

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

The GRM package defines a <<MutualExclusionResource>> stereotype. The SRM package, which is presented as a specialization of GRM to model software resources, defines a stereotype with a similar name: <<SwMutualExclusionResource>>. However, there is no direct link between these two stereotypes. GRM::MutualExclusionResource directly specializes GRM::Resource, while SRM::SwMutualExclusionResource specializes SRM::SwSynchronizationResource, which specializes SRM::SwResource, which specializes GRM::Resource. Stereotypes have quite similar names, which may think of related concepts. However, their use and their related stereotype attributes are quite different.

Resolution: Make stereotype SwMutualExclusionResource inherit from MutualExclusionResource. Since this inheritance is not present in the domain view, the sections to modify comprise both, the domain view, and the UML representation of SRM.
Revised Text: see ptc/2009-005-12 pages 14 - 15
Actions taken:
September 14, 2007: received issue
October 16, 2009: closed issue

Discussion:

Discussion: The link between both is its semantics...., which is expressed in the domain view. Same thing happens in issue 11411. The stereotypes just happen to be not strongly related (by inheritance i.e.) because they are used for different purposes. SRM is basically attached to its usage to create OS utilitarian model libraries, GRM stuff if used to architect the problem and analysed/verify the problem and the solutions. Hence the links are to be provided when necessary by the semantics-aware transformations among tools that deal with both worlds Resolution: The adequate solution is to make SwMutualExclusionResource inherit from MutualExclusionResource, which simplifies the annotations the user needs to do, or simply close the issue. But it has caused some polemics, see issue 11856 (synchronization between GRM, SRM, HRM and Analysis). For this reason, this issue is deferred. The link between both is its semantics...., which is expressed in the domain view. Same thing happens in issue 11411. The stereotypes just happened to be not strongly related (i.e. by inheritance) because they are typically used for different purposes. SW stuff is basically attached to its implementation, GRM stuff if used to architect the problem and analysed/verify the problem and the solutions. Hence the links were to be provided when necessary by the semantics-aware transformations among tools that deal with both worlds. The adequate solution is to make SwMutualExclusionResource inherit from MutualExclusionResource, this simplifies the annotations. This has been thoroughly discussed in the December 2008 Technical Meeting, and has been resolved in coordination with issues 11411 and 11856 (synchronization between GRM, SRM, HRM and Analysis).

Issue 11417: rtf stereotype (marte-ftf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

rtf stereotype is the only one which name does not start with an upperCase. Should be Rtf (or RTF). Lack of coherency.

Resolution: The name of the RealTimeFeature stereotype SHALL be "Rtf".
Revised Text: In Figure 13.11, 13,16, 13,17, 13.20, 13.21, and 13.22, replace "rtf" with "Rtf" In Section 13.3.2.9, on page 161, replace "rtf" with "Rtf". In Section 13.4.2, on page 166, replace "rtf" with "Rtf".
Actions taken:
September 18, 2007: received issue
February 17, 2010: closed issue

Issue 11504: Annex D3 MARTE model library for time (marte-ftf)

Click here for this issue's archive.
Source: INRIA (Mr. Charles Andre, Charles.ANDRE(at)unice.fr)
Nature: Uncategorized Issue
Severity:
Summary:

In Annex D3  MARTE model library for time, 2 enumerations (EventKind and TimeStandardKind) have to be moved from the Time library to the TimeTypesLibrary, because these enumerations are used in the profile definition.

Resolution: Proceed with the proposed modifications.
Revised Text: Page 438-440 old text: This section provides model elements related to Time, gathered in two model libraries (Figure D.7). The TimeTypesLibrary library is used in the Time profile, the TimeLibrary is for users. Figure D.6 - Structure of the MARTE time model library TimeTypesLibrary library This package contains enumerations used in the Time profile (Figure D.8). TimeNatureKind is an enumeration type that defines literals used to specify the discrete or dense nature of a time value. TimeInterpretationKind is an enumeration type that defines literals used to specify the way to interpret a time expression: either as a duration or as an instant. Figure D.7 - TimeTypesLibrary library TimeLibrary The TimeLibrary library (Figure D.9) provides enumerations related to time and facilities for using the ideal chronometric time (i.e., the time referenced in physical laws). TimeUnitKind contains the main chronometric time units. s (second) is an SI unit. Other units are derived units. All the enumeration literals are stereotyped by clockUnit. LogicalTimeUnitKind is a special enumeration which contains one enumeration literal only. This literal is tick. TimeStandardKind defines literals used to specify the standard "systems of time". The meaning of the acronyms is given below � GPS General Positioning System, not adjusted for leap seconds � Local Local Time � Sidereal Sidereal Time � TAI International Atomic Time scale, a statistical timescale based on a large number of atomic clocks � TCB Barycentric Coordinate Time � TCG Geocentric Coordinate Time � TDB Barycentric Dynamical Time � TT Terrestrial Time � UT0 Universal Time 0 � UT1 Universal Time 1 � UTC Coordinated Universal Time Figure D.8 -Detailed model library of TimeLibrary The IdealClock and its instance idealClk model the abstract and ideal time which is used in physical laws. It is a dense time. idealClk should be imported in models that refer to chronometric time. TimedValueType is a templated data type. The template parameter is an enumeration which contains time units. The EventKind enumeration contains literals that may characterize events: events related to a behavior execution (start and finish), and events related to a request (send, receive, and consume). Page 438-440 new text: This section provides model elements related to Time, gathered in two model libraries (Figure ). The TimeTypesLibrary library is used in the Time profile, the TimeLibrary is for users. Figure 1 - Structure of the MARTE time model library TimeTypesLibrary Library This package contains enumerations used in the Time profile (Figure ). TimeNatureKind is an enumeration type that defines literals used to specify the discrete or dense nature of a time value. TimeInterpretationKind is an enumeration type that defines literals used to specify the way to interpret a time expression: either as a duration or as an instant. The EventKind enumeration contains literals that may characterize events: events related to a behavior execution (start and finish), and events related to a stimulus (send, receive, and consume). TimeStandardKind defines literals used to specify the standard "systems of time". The meaning of the acronyms is given below � GPS General Positioning System, not adjusted for leap seconds � Local Local Time � Sidereal Sidereal Time � TAI International Atomic Time scale, a statistical timescale based on a large number of atomic clocks � TCB Barycentric Coordinate Time � TCG Geocentric Coordinate Time � TDB Barycentric Dynamical Time � TT Terrestrial Time � UT0 Universal Time 0 � UT1 Universal Time 1 � UTC Coordinated Universal Time Figure 2 - TimeTypesLibrary library TimeLibrary The TimeLibrary library (Figure ) provides enumerations related to time and facilities for using the ideal chronometric time (i.e., the time referenced in physical laws). TimeUnitKind contains the main chronometric time units. s (second) is an SI unit. Other units are derived units. All the enumeration literals are stereotyped by clockUnit. LogicalTimeUnitKind is a special enumeration which contains one enumeration literal only. This literal is tick. The IdealClock and its instance idealClk model the abstract and ideal time which is used in physical laws. It is a dense time. idealClk should be imported in models that refer to chronometric time. TimedValueType is a templated data type. The template parameter is an enumeration which contains time units. Figure 3: Detailed model library of TimeLibrary
Actions taken:
September 20, 2007: received issue
February 17, 2010: closed issue

Issue 11520: the property named "isSynchronous" is misspelled (marte-ftf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Mr. Yann Tanguy, yann.tanguy(at)cea.fr)
Nature: Clarification
Severity: Minor
Summary:

On the stereotype HwBus in the diagram, the property named "isSynchronous" is mispelled ("isSynchrnous")

Resolution: Proceed in both Domain Model and Profile Definition.
Revised Text: see ptc/2008-06-05 for details
Actions taken:
September 26, 2007: received issue
February 17, 2010: closed issue

Issue 11521: Figure 14.70 - HwCommunication package details (marte-ftf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Mr. Yann Tanguy, yann.tanguy(at)cea.fr)
Nature: Clarification
Severity: Minor
Summary:

Lack of homogeneity in the enumeration litterals naming (considering the rest of the document) : - litteral should start with lowercase - "undef" should be used instead of "undefined"

Resolution: Proceed in all the figures affected by this issue.
Revised Text: -Replace Figs. 14-56, 14-57, 14-63, 14-67, 14-68, 14-74, 14-78, 14-81, 14-82 with the following: (Note that the datatypes were replaced with tupletypes to follow Issue 11632) Figure 14.56 - HW_Computing package details Figure 14.57 - HW_Storage package details (HW_Memory) Figure 14.63 - HW_Layout package details Figure 14.67 - HwComputing package details Figure 14.68 - HwMemory package details (HwStorage) Figure 14.74 - HwLayout package details Figure 14.78 - Stereotype application example (SDRAM) Figure 14.81 - SMP physical view Figure 14.82 - SMP merged (logical/physical) view -Modify all the Classes and Stereotype descriptions in Sections 14.2.3.2 Stereotype descriptions, and F.9 DRM::HRM, with enumeration literal starting with lowercase in Enumerations, and "undef" instead of "undefined"
Actions taken:
September 26, 2007: received issue
February 17, 2010: closed issue

Issue 11522: The type NFP_Price does not exist in the document. (marte-ftf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Mr. Yann Tanguy, yann.tanguy(at)cea.fr)
Nature: Clarification
Severity: Minor
Summary:

HwComponent stereotype has a property named "price" typed by "NFP_Price". The type NFP_Price does not exist in the document.

Resolution: To add the nfpType NFP_Price in Annex D.
Revised Text: see ptc/2008-06-05 for details
Actions taken:
September 26, 2007: received issue
February 17, 2010: closed issue

Discussion:

Issue 11526: Section 2/2.2 (marte-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

"The extensionUnits defined in this specification..." should be written as "The Extension Units defined in this specification..."

Resolution: Text to update according to the previous proposal. DDDDDDwxvcx
Revised Text: On page #2, replace the existing text "The extensionUnits defined in this specification..." by "The Extension Units defined in this specification..."
Actions taken:
October 3, 2007: received issue
February 17, 2010: closed issue

Issue 11527: Section 6/6/2/1 (marte-ftf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

In the first paragraph of section 6.2.1 is written "...it is possible to give some general descriptions of four main sub categories included in the RT/E domain category...". However, five domains are described: - Embedded domain - Reactive domain - Control/Command domain - Intensive data flow computation domain - Best-effort service domain Also, only the 'Intensive data flow computation domain' is sub-sectioned as 6.2.1.1 (how about the other domains?)...

Resolution: The resolution of this issue consists in making the required editorial changes as described in the next section.
Revised Text: In the first paragraph of the section 6.2.1, in the fourth lines: change "�descriptions of four main�" into "�descriptions of five main�"Intensive data flow computation domain" as for other as "Embedded domain". Apply same style to the section untitled
Actions taken:
October 3, 2007: received issue
February 17, 2010: closed issue

Issue 11528: Section 6/6.3 (marte-ftf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

In the first paragraph of sub-section 6.3.1 it is written "These are shown by the RTEM package in Figure 6.4, and the cluster of four AnalysisModelling packages, respectively". However, I see only three packages under the MARTE analysis model: GQAM, SAM, and PAM. Also I don't see the TCRM package (by the way, I presume that the RTEM and RTEMoCC are the same packages). Am I wrong at my assumptions?

Resolution: At the beginning, the Analysis package aims including an additional package dedicated to WCET analysis. At the end, this purpose was not achieved. So, this package contains at last only 3 packages => text need to be revised as described in the next section. In general, the figure 6.4 reflects correctly the current architecture of the MARTE extensions but the text put on top of this figure needs to be updated to take into account the final name of the package as described in the figure.
Revised Text: Change the text of the first paragraph of section 6.3.1 (on page12 and 13): Previous text: "The profile is structured around two concerns, one to model the features of real-time and embedded systems and the other to annotate application models so as to support analysis of system properties. These are shown by the RTEM package in Figure 6.4, and the cluster of four "AnalysisModeling" packages, respectively. These two major parts share common concerns with describing time and the use of concurrent resources, which are contained in the shared package TCRM. Finally the "AnalysisModeling" features are broken into a foundational generic part in the package GQAM, and three packages for specific analysis domains, as shown. These first three domains are entirely concerned with time, however the profile structure allows for adding additional analysis domains, such as power consumption, memory use or reliability. It is the intention to encourage modular sub profiles like the three "AnalysisModeling" packages, for such domains." New text: "The profile is structured around two main concerns, one to model the features of real-time and embedded systems and the other to annotate application models so as to support analysis of system properties. These are shown by the RTEM package named "MARTE design model" in Figure 6.4, and the cluster of three packages gathered in the package named "MARTE analysis model", respectively. These two major parts share common concerns with describing time and the use of concurrent resources, which are contained in the shared package named "MARTE foundations". Finally the "AnalysisModeling" features are broken into a foundational generic part in the package GQAM, and two packages for specific analysis domains, as shown. These first two specific analysis domains are entirely concerned with time, however the profile structure allows for adding additional analysis domains, such as power consumption, memory use or reliability. It is the intention to encourage modular sub profiles like the two analysis packages, for such domains."
Actions taken:
October 3, 2007: received issue
February 17, 2010: closed issue

Issue 11529: Section 6/6.4 (marte-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

There a lot of spelling errors in the section 6.4.1: - "...; chapter 0, General Component Model, introdces a general componenet model suitable for RTES." should be rewritten as "...; chapter 11, General Component Model, introduces a general component model suitable for RTES." - "..., chapter 13, RTE Model of Compuation and Communication, ..." should be rewritten as "..., chapter 13, RTE Model of Computation and Communication, ..." - "It does not intend to define new analmysis technologies, but to define the information required for annotation models on whoch external analysis techniques may be applied." should be rewritten as "It does not intend to define new analysis technologies, but to define the information required for annotation models on which external analysis techniques may be applied." - "..., specializes the generic framework for performaing schedulability analysis, whereas ..." should be rewritten as "..., specializes the generic framework for performing schedulability analysis, whereas ..."

Resolution: Do editiorial change as suggested.
Revised Text: In section 6.4.1: - "...; chapter 0, General Component Model, introdces a general componenet model suitable for RTES." should be rewritten as "...; chapter 11, General Component Model, introduces a general component model suitable for RTES." - "..., chapter 13, RTE Model of Compuation and Communication, ..." should be rewritten as "..., chapter 13, RTE Model of Computation and Communication, ..." - "It does not intend to define new analmysis technologies, but to define the information required for annotation models on whoch external analysis techniques may be applied." should be rewritten as "It does not intend to define new analysis technologies, but to define the information required for annotation models on which external analysis techniques may be applied." - "..., specializes the generic framework for performaing schedulability analysis, whereas ..." should be rewritten as "..., specializes the generic framework for performing schedulability analysis, whereas ..."
Actions taken:
October 4, 2007: received issue
February 17, 2010: closed issue

Discussion:

Issue 11530: first sentence of sub-section 6.4.2 (marte-ftf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The first sentence of sub-section 6.4.2 says: "Each extensions proposed by MARTE have been conflated around one main concerns and detailed in separate chapters: chapter 7 to chapter 18 and Annex E." I wonder if you mean "...chapter 7 to chapter 17 and Annex F." since there isn't a chapter 18, and Annex F is cited on the next paragraph.

Resolution: Yes, the text should refer to chapter 7 to chapter 17 and Annex F. see next proposed resolution.
Revised Text: In section 6.4.2, first paragraph, first sentence, replace: "Each extensions proposed by MARTE have been conflated around one main concerns and detailed in separate chapters: chapter 7 to chapter 18 and Annex E." by "Each extensions proposed by MARTE have been conflated around one main concerns and detailed in separate chapters: chapter 7 to chapter 17 and Annex F."
Actions taken:
October 4, 2007: received issue
October 16, 2009: closed issue

Issue 11544: Annex D (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Enhancement
Severity: Minor
Summary:

Operators (e.g., +, -, *, /, =, <, >) are not defined for the types in the MARTE_Library::BasicNFP_Types package. Such operators are required if one wants to define expressions such as "(end - start) < (10, ms)" where "end" and "start" are ObsCallExpression, for instance. Ideally, all the operators defined for the MARTE_Library::MARTE_PrimitiveTypes types should also exist for their MARTE_Library::BasicNFP_Types counterpart

Resolution: One aspect that appears here is that the operations for NFP types like NFP_Real, NFP_String, etc, should be the same as the primitive type counterparts. So, it seems natural to reuse those operation definitions. One mechanism to reuse the operations (e.g., +, -, *, /, =, <, >) is to inherit NFP types from the primitive types. Hence, this resolution proposes to define the operations of Nfp_Types by inheriting from the corresponding MARTE primitive types. In addition, the semantic of such NfpTypes operations (in physical Nfp_Types such as NFP_Duration, NFP_Temperature, etc.) are different than their primitive type counterparts (Real primitive types). Indeed, operations in NfpTypes involve evaluating not only the �value� part but also the measurement �unit� part. This is left out of the scope of this specification, and an implementation supporting measurement unit conversion should take care of this.
Revised Text: see ptc/2009-05-12 pages 16 - 17
Actions taken:
October 8, 2007: received issue
October 16, 2009: closed issue

Discussion:

Issue 11545: grammar defined for conditional expressions (marte-ftf)

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

The grammar defined for conditional expressions does not allow one to use operation call expressions in the condition predicate. The BNF defines only <condition-expr> ::= <variable-declaration> | <variable-call-expr> | <property-call-expr> As a consequence, it is not possible to define predicates based on value comparison. Thus, it is not possible to implement the expression "(clock_rate>5)?(5):(clock_rate)", provided as example page 404.

Resolution: We add a new terminal to the <condition-expr> rule, which is operation call expression. This allows us to specify: "(clock_rate>5)" which is an infix operation call of ">" in clock_rate.
Revised Text: -In Section B.3.3.15, we add a new terminal for the <condition-expr> rule (we additionally add parenthesis to the rule): <condition-expr> ::= '(' <variable-declaration> | <variable-call-expr> | <property-call-expr> | <operation-call-expr> ')' .
Actions taken:
October 4, 2007: received issue
October 8, 2007: received issue
February 17, 2010: closed issue
February 17, 2010: closed issue

Issue 11546: Wrong references in page 397 (marte-ftf)

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

Wrong references in page 397 : "The nature of these mechanisms is described in chapters Model Processing and The Model Configurer on page X-X" and "we use the standard BNF notational convention defined in Annex X". The chapters "Model Processing" and "The Model Configurer" may not exist anymore in the Beta 1 version.

Resolution: I suggest to remove these sentences that contain old (SPT) references.
Revised Text: Page 397 old text: However, these additional mechanisms are necessary for any system that allows values to be expressed through variables and are not a consequence of using VSL. The nature of these mechanisms is described in chapters "Model Processing" and "The Model Configurer" on page X-X. In representing the syntax of these value specifications, we use the standard BNF notational convention defined in Annex X. Page 397 new text: However, these additional mechanisms are necessary for any system that allows values to be expressed through variables and are not a consequence of using VSL.
Actions taken:
October 8, 2007: received issue
February 17, 2010: closed issue

Issue 11547: VSL meta-model (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Enhancement
Severity: Minor
Summary:

The VSL BNF defines a "[ ]" symbol that can be used along with a collection. The specification introduces the example: "{'a', 'b', 'c', 'd'} [2]". However, there is no related concept (access to a collection) in the VSL meta-model.

Resolution: This notation (to get collection elements by using the index), comes from the TVL language in SPT, but the mentioned example was not updated to the current VSL mechanism to define operations in data types. For that, VSL uses the same approach as OCL, so that the operation for finding an element in a given collection should be defined and described at library level, in the operations of the concerned data types (collections in this case). The specification of the function will be allowed by using OperationCallExpression. The resolution is to remove the proposed examples from VSL. If new operations are required for Collections in the MARTE library of data types, this should be solved by posting a separated issue.
Revised Text: In Section B.3.3.8, page 401, remove the last paragraphs: Individual items in a collection can be accessed by indexing. It is achieved by specifying the index of the desired collection element to the right of the collection, with the left-most element at index value 0. For instance, the result of evaluating the following expression: {'a', 'b', 'c', 'd'} [2] is the string 'c', which is in index position 2.
Actions taken:
October 8, 2007: received issue
February 17, 2010: closed issue

Issue 11548: Annex B VSL BNF (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Enhancement
Severity: Minor
Summary:

In the VSL BNF, the use of the "[ ]" symbol should not be limited to collections. One may want to use it along with variable call expressions (e.g. "collec[2]"), property call expressions. Maybe other kinds of value specifications also apply.

Resolution: The current mechanism of defining operations on data types allows one to define a given operation independently of the current value itself. For instance, a property could be typed by a Collection of Integers, and this collection could be specified by a Variable. So, we can apply to this variable, all the operations defined for Collections. This issue is also related to Issue 11547, and do not need any modification in the spec. Disposition: Closed No Change
Revised Text:
Actions taken:
October 8, 2007: received issue
February 17, 2010: closed issue

Issue 11549: The VSL grammar does not define the "( )" symbol (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Enhancement
Severity: Minor
Summary:

The VSL grammar does not define the "( )" symbol that allows one to indicate priorities in the syntax of arithmetical expressions. In the expression, "((1+2) * 3)" for instance.

Resolution: To allow building unambiguous expressions (mainly arithmetical ones), the language should include both proper rules supporting parentheses (i.e., �(� and �)�) as well as precedence rules to specify the order in operations evaluation. In VSL, these aspects concern two different sections of MARTE. Parentheses need to be specified in the VSL grammar section, and precedence rules in the library of primitive types. The latter is because �operations� (e.g., arithmetic operations: +, -, *, /) are defined as operations of MARTE primitive types (Real, Integer, etc.). Hence, this resolution proposes to add/modify VSL as defined below.
Revised Text: Parentheses allow user to specify priorities (precedence rules) in �operation call expressions� (especially for infix operators). In order to allow VSL to specify parentheses where needed, the <operation-call-expr> rule should be revised. Modify Section �B.3.3.14 Operation Call Expressions� (p. 417) with the following rules: ---------start: ----- <operation-call-expr> ::= (<value-specification> '.' <operation-name> '('[ <argument-value> [','<argument-value>]* ]')') | ( <argument-value> <operation-name> <argument-value> | '('<argument-value> <operation-name> <argument-value> ')' ) <argument-value> ::= <value-specification> <operation-name> ::= <body-text> Disambiguating rules - The parentheses in the first case (no infix operator) should be mandatory. - Precedence rules are defined for infix operators that are defined in the standard MARTE library. ---------end ----- In addition, Annex D, Section �D.1 MARTE Library for Primitive Types� should provide a section that defines precedence rules. Add the following precedence rules at the end of Section D.1.: ---------start: ----- Precedence Rules The precedence order for the operations, starting with highest precedence, in VSL is: � unary �not�, unary minus �-� and unary plus �+� � �*� and �/� � binary �+� and �-� � �<�, �>�, �<=�, �>=� � �= =�, �<>� � �and�, �or� and �xor� Parentheses �(� and �)� can be used to change precedence. ---------end ----- Disposition: Resolved
Actions taken:
October 8, 2007: received issue
October 16, 2009: closed issue

Discussion:

Resolution:  Precedence rules to evaluate expressions are missing in VSL. This should be added at the same level where semantic of operations is defined. In this case, operations are defined in the Library annex. However, it's not clear how the grammar should be updated to support these precedence rules.    The resolution proposes to defer this issue to evaluate the VSL grammar more carefully.      Disposition:	Deferred

Issue 11550: non-terminal symbol <namespace> (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Enhancement
Severity: Minor
Summary:

The VSL grammar introduces a non-terminal symbol <namespace> in the syntax definition of property call expression and variable call expression. However, this symbol seems to be missing in the syntax definition of enumeration specification as well as observation call expression. As a consequence, it is not possible to reference without ambiguity two time instant observations with the same name but with different fully qualified names. That prevents from using observations with similar names in different packages.

Resolution: For the case of Enumeration specification, it is not necessary to specify the namespace. Enumerations values are always related to a typed property or tag definition. The type of those properties or tag definitions (an Enumeration data type) defines the scope of the enumeration literal specified. For the case of Observation Call Expression, the namespace is missing. This resolution proposes to add such a namespace.
Revised Text: -In Section B.3.3.15, modify and extend the BNF for <instant-obs-name> and <duration-obs-name>: <instant-obs-name> ::= [<namespace> '.'] <body-text> <duration-obs-name> ::= [<namespace> '.'] <body-text> <namespace> ::= <body-text>
Actions taken:
October 8, 2007: received issue
February 17, 2010: closed issue

Issue 11551: automotive example (marte-ftf)

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

The automotive example still uses stereotypes that have been renamed in the lastest versions of the document (e.g. <<msgPort>> instead of <<messagePort>>, <<serviceSpecification>> and <<signalSpecification>> instead of <<bFeatureSpecification>>). Such inconsistencies appear in diagrams and descriptions.

Resolution: 1) Remove references to the msgPort stereotype and replace by the messagePort stereotype. 2) Remove references to the serviceSpecification and signalSpecification and replace by the bFeatureSpecification stereotype.
Revised Text: Section 11.4.1, page 129, replace sentence: "The RegInterface is a UML2 interface stereotyped with "signalSpecification" and "serviceSpecification" because it specifies respectively that the Start signal may be consumed (This latter has been previously declared within the package SignalDeclarations) and the controlEngine service is required." by "The RegInterface is a UML2 interface stereotyped with "bFeatureSpecification" because it specifies that the Start signal may be consumed (this latter has been previously declared within the package SignalDeclarations) and the controlEngine service is required." Section 11.4.1, page 129, replace sentence: "The ECInterface interface is stereotyped as serviceSpecification (in this case, the graphical representation of this interface shown at top-right side of Figure 11.15 only displays its associated iconographic representation " ")." by "The ECInterface interface is also stereotyped as bFeatureSpecification (in this case, the graphical representation of this interface shown at top-right side of Figure 11.15 only displays its associated iconographic representation " ")." Section 11.4.1, page 129, replace sentence: "This interface defines the controlEngine required service (denoted here by the icon " " placed before the operation name)." by "This interface defines the controlEngine required service (denoted here by the icon " " placed before the operation name)." Section 11.4.1, page 129, replace sentence: "Finally, the SpeedInterface interface is a "signalSpecification" interface that declares a produced signal, Start (in this case, we only used the textual form of the stereotype)." by "Finally, the SpeedInterface interface is also a "bFeatureSpecification" interface that declares a produced signal, Start (in this case, we only used the textual form of the stereotype)." Section 11.4.1, page 129, replace sentence: "The three previous interfaces are examples of applying the stereotypes defined in the general component model (GCM) of MARTE. We have illustrated the usage of stereotypes following the three possibilities offered by UML: textual and iconographic form (e.g., RegInterface), only iconographic form (e.g., ECInterface) and only textual form (e.g., SpeedInterface)." by "These interfaces illustrate the use of stereotypes defined in the general component model of MARTE. The three possibilities offered by UML to represent the stereotypes have been used here: textual and iconographic form (e.g., RegInterface), only iconographic form (e.g., ECInterface) and only textual form (e.g., SpeedInterface)." Replace Figure 11.15, page 130 by the following figure: Section 11.4.1, page 130, replace sentence: "This class has two ports stereotyped with "msgPort": regOn and engineCmd." by "This class has two ports stereotyped with "messagePort": regOn and engineCmd." Section 11.4.1, page 130, replace sentence: "It is a port stereotyped by "msgPort"." by "It is a port stereotyped by "messagePort"." Section 11.4.1, page 130, replace sentence: "The direction property of the stereotype does not apply in this case because the type of the port is an interface stereotyped with "serviceSpecification" (this latter, ECInterface, defines a required service as denoted in Figure 11.15.)." by "The direction property of the stereotype does not apply in this case because the type of the port is an interface stereotyped with "bFeatureSpecification" (this latter, ECInterface, defines a required service as denoted in Figure 11.15.)." Section 11.4.1, page 130, replace sentence: "The second port owned by the rgm part (the rp port) is a message port (stereotype "msgPort" and associated icon " ")." by "The second port owned by the rgm part (the rp port) is a message port (stereotype "messagePort" and associated icon " ")." Replace Figure 11.16, page 131 by the following figure: Replace Figure 11.17, page 131 by the following figure:
Actions taken:
October 8, 2007: received issue
February 17, 2010: closed issue

Issue 11552: GRM::SchedulableResource should not have a property "host:ExecutionHost" (marte-ftf)

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

In the class diagram, the GRM::SchedulableResource should not have a property "host:ExecutionHost" (defined in QGAM). There is no dependency from GRM to GQAM, therefore the "host" property cannot be typed by "ExecutionHost". Moreover, GRM::SchedulableResource already has a property called "host: Scheduler". In that context, I would suggest just removing the "host: ExecutionHost" property from SchedulableResource in Figure 15.5.

Resolution: To add an inheritance from scheduler in figure 15.5 for both executionHost and communicationHost. Then the association between SchedulableResource and executionHost is the same that already exist in GRM to scheduler. The scheduler in communicationHost is easy to justify as the arbitration/protocol that gives to each message access to the media.
Revised Text: New visio file for fig 15.5 and 15.9. Add the inheritance from scheduler in the class descriptions this means editing sections: 15.3.2.4, 15.3.2.7 adding the generalization Scheduler (from MARTE::GRM) Also indicate in the constraints the two self pointing associations processingUnits and mainScheduler
Actions taken:
October 9, 2007: received issue
February 17, 2010: closed issue

Issue 11553: no explicit dependency to QVT concepts (marte-ftf)

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

It is stated that MARTE uses "MOF 2.0 Queries, Views, and Transformation framework to define any model transformation rules...". Additionally, Figure 6.1 shows a <<use>> dependency between MARTE and QVT. However, no explicit dependency to QVT concepts has been used/found in this document.

Resolution: The comment is correct. I suggest then to modify the text of the first paragraph of the section 6.1 and modify the figure 6.1 in order to suppress this reference to MOF QVT.
Revised Text: In section 6.1, first paragraph, delete the fourth sentence, i.e., "In addition, it uses the MOF 2.0 Queries, Views, and Transformation framework to define any model transformation rules (e.g., rules for transforming a MARTE stereotype into a corresponding analysis model element). " In section 6.1, modify figure 6.1 in order to suppress the package named MOF 2.0 QVT and delete the link between this latter package and the MARTE package.
Actions taken:
October 9, 2007: received issue
February 17, 2010: closed issue

Issue 11554: Class descriptions are missing (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Enhancement
Severity: Minor
Summary:

Class descriptions are missing in the MARTE model library for extended datatypes (Annex D2).

Resolution: We describe a subset that requires unambiguous definition. The remaining extended data types are self-explanatory.
Revised Text: -In Section D.2, after the second paragraph, add: "Extended data types that have not been described in the chapters that used them are described below." -In Section D.2, after Fig. D.4, add: D.2.1 TransmModeKind This enumeration defines the kind of transmission mode of messages over a network. Literals � simplex it allows for one-way communication of data through the network. � half-duplex it allows communication in both directions, but only one direction at a time (not simultaneously). Typically, once a party begins receiving a signal, it must wait for the transmitter to stop transmitting, before replying. � full-duplex it allows communication in both directions, and unlike half-duplex, allows this to happen simultaneously. -In Section D.2, after Fig. D.5, add: D.2.2 ArrivalPattern This is a ChoiceType that contains the different kinds of parameters that are necessary to specify the most common arrival patterns of events. Attributes � periodic: PeriodicPattern it describes periodic interarrival patterns, with an optional maximal deviation (jitter). � aperiodic: AperiodicPattern it describes an unbounded pattern that is defined by a distribution function � sporadic: AperiodicPattern it describes a bounded pattern that is defined by a corner case interarrival times and a maximum deviation (jitter) � burst: BurstPattern it describes a bursty interarrival pattern with a number of events that can occur in a bounded period. � irregular: IrregularPattern it describes an aperiodic pattern that is described by a table of successive interarrivals durations measured from a starting phase. � closed: ClosedPattern it describes a workload characterized by a fixed number of active or potential users or jobs that cycle between executing the scenario. � open: OpenPattern it describes a workload that is modeled as a stream of requests that arrive at a given rate in some predetermined pattern (such as Poisson arrivals). D.2.3 PeriodicPattern This is a TupleType that contains the parameters that are necessary to specify a periodic pattern. Attributes � period: NFP_Duration the period as a duration. � jitter: NFP_Duration the maximum deviation of the occurrences � phase: NFP_Duration a delay for the first occurrence of the event. D.2.3 AperiodicPattern This is a TupleType that contains the parameters that are necessary to specify an aperiodic pattern (unbounded pattern). Attributes � distribution: NFP_CommonType a distribution of the arrival pattern that could use one of the patterns described in Section 8.3.3. D.2.3 SporadicPattern This is a TupleType that contains the parameters that are necessary to specify a sporadic pattern (bounded pattern). Generalizations � AperiodicPattern Attributes � minInterarrival: NFP_Duration the minimum interarrival duration between two successive occurrences of an event. � maxInterarrival: NFP_Duration the maximum interarrival duration between two successive occurrences of an event. � jitter: NFP_Duration the maximum deviation of the occurrences regarding to the minimum interarrival time. D.2.3 BurstPattern This is a TupleType that contains the parameters that are necessary to specify a bursty pattern. Generalizations � AperiodicPattern Attributes � minInterarrival: NFP_Duration the minimum interarrival duration between two successive occurrences of an event. � maxInterarrival: NFP_Duration the maximum interarrival duration between two successive occurrences of an event. � minEventInterval: NFP_Duration the minimum interval between two occurrences within a burst. � maxEventInterval: NFP_Duration the maximum interval between two occurrences within a burst. � burstSize: NFP_Integer the number of event occurrences within a burst. � minEventInterval: NFP_Duration the minimum interval between two occurrences within a burst. D.2.3 IrregularPattern This is a TupleType that contains the parameters that are necessary to specify an irregular pattern (list of duration separations between successive event occurrences). This is a fully deterministic arrival pattern. Generalizations � AperiodicPattern Attributes � phase: NFP_Duration a delay for the first occurrence of the event. � interarrivals: NFP_Duration [*] the set of duration separations between successive event occurrences. D.2.3 ClosedPattern This is a TupleType that contains the parameters that are necessary to specify a closed pattern. It is characterized by a fixed number of active or potential users or jobs that cycle between executing the scenario, and spending an external delay period (sometimes called "think time") outside the system, between the end of one response and the next request. Attributes � population: NFP_Integer The size of the workload (number of system users). � extDelay: NFP_Duration The delay between the end of one response and the start of the next for each member of the population of system users D.2.3 OpenPattern A workload that is modeled as a stream of requests that arrive at a given rate in some predetermined pattern (such as Poisson arrivals). Attributes � interArrivalTime: NFP_Duration the time between successive arrivals. For a Poisson process this is exponentially distributed with mean = 1/rate. � arrivalRate: NFP_Frequency the average rate of arrivals. � arrivalProcess: String the name of an arrival process, understood by the analysis tool. Examples (not exhaustive) are Poisson, General, Phase-type, Markov-Modulated Poisson, Correlated, Pareto. If arrivalProcess is defined, normally arrivalRate is also defined, and interArrivalTime is not.
Actions taken:
October 9, 2007: received issue
February 17, 2010: closed issue

Issue 11555: Class descriptions are missing in the MARTE model library for GRM (Annex D4 (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Enhancement
Severity: Minor
Summary:

Class descriptions are missing in the MARTE model library for GRM (Annex D4).

Resolution: These Class descriptions are in section 10.3.3. They can be referenced from the annex or move to the annex and referenced in section 10.3.3
Revised Text: Move all class descriptions in section 10.3.3 to the D4 annex and insert a paragraph in section 10.3.3 making a reference such as: The description of all the elements in the model library for GRM are in annex D4
Actions taken:
October 9, 2007: received issue
February 17, 2010: closed issue

Issue 11619: Section: 14/2 (marte-ftf)

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

In HRM, a stereotype called HwResource is used in the HwLogical subpackage to provide a logical representation of a hardware resource. At the same time, a stereotype with the name is used in the HwPhysical subpackage to provide a physical representation of a hardware resource. Although it is legal in this context, defining two stereotypes with the same names that have different semantics may create confusion in a user's mind. I would suggest renaming HwResource into HwLogicalResource / HwPhysicalResource. The same thing applies for HwLogical::HwResourceService and HwPhysical::HwResourceService.

Resolution:
Revised Text:
Actions taken:
October 16, 2007: received issue
February 17, 2010: closed issue

Discussion:

HwLogical and HwPhysical both address the issue of hardware modeling, proposing two different abstraction levels for hardware modeling. It means that if two stereotypes (one defined in each package) have the same name, they do not fundamentally differ from a semantic view point. They just reflect a level of detail that is consistent with the abstraction level that is addressed by the package. In this context, it is not necessary to define a particular name for each stereotype. This remark concerns both HwResource and HwReso

Issue 11620: Section: 15/3 (marte-ftf)

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

The stereotype <<gaEventTrace>> defines stereotype attributes: content, format, location that are not defined in the domain model (p. 263). I would suggest adding a definition of these attributes in the EventTrace domain class.

Resolution: Add definitions to the text of the domain model
Revised Text: para 3 p 263, before: One of these options is used and the others are undefined. The arrivalPattern alternatives are described elsewhere, but they include PeriodicPattern, often used for schedulability, and Open and Closed patterns often used for performance analysis, and a variety of less regular patterns. after: In practice, one of these options is used and the others are left undefined. The arrivalPattern alternatives are described in Appendix D, but they include the PeriodicPattern, often used for schedulability, the Open and Closed patterns often used for performance analysis, and some less regular patterns. EventTrace has attributes for location (the file location or URL), format (a description of the trace record format) and content (for the trace data itself).
Actions taken:
October 16, 2007: received issue
February 17, 2010: closed issue

Issue 11631: Section: 15.3.1 (marte-ftf)

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

Inconsistency between GCAM profile definition and SAM example In Figure 16.14, the stereotype <<GaResourcesPlatform>> is applied on a part (i.e. a UML property) of the TeleoperatedRobotSAM composite class. Meanwhile, in Figure 15.6, it seems that this stereotype extends only UML::Classifier. Proposed resolution: either we remove the stereotype from the SAM example or we allow the stereotype <<GaResourcesPlatform>> to extend UML::Classifier and UML::Property. The second option would make sense to me.

Resolution: The stereotypes are to be removed from the example.
Revised Text: (1) First sentence of Section 16.3.3.3, change Figure number. Old text: In order to define the analysis context for a given pair of workload behaviour and resources platform models, we illustrate how to use structured classifiers (see Figure 16.13). New text: In order to define the analysis context for a given pair of workload behaviour and resources platform models, we illustrate how to use structured classifiers (see Figure 16.14). (2) In Figure 16.14, remove the stereotypes " gaWorkloadBehavior " and "GaResourcesPlatform"
Actions taken:
October 24, 2007: received issue
February 17, 2010: closed issue

Issue 11632: Section: 14.2.3 (marte-ftf)

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

<< tupleType >> stereotypes would need to be added on HRM datatypes, to enable the use of VSL expressions. The UML representation section of HRM defines several datatypes (Timing, CacheStructure, PLD_Organisation, MemoryOrganisation, Env_Condition) that are not stereotyped as << tupleType >>. As a consequence, it is not possible to edit properties typed by these datatypes as VSL expressions. Proposed resolution: to apply the << tupleType >> stereotype on every datatype defined in HRM.

Resolution: Proceed with the modification of all the datatypes with tupletype in the HRM chapter.
Revised Text: -Figures in Issue 11521 already have the required modifications for datatype into tupletype -Modify all the Classes and Stereotype descriptions in Sections 14.2.3.2 Stereotype descriptions, and F.9 DRM::HRM, by replacing the word "datatype" by "tupletype"
Actions taken:
October 25, 2007: received issue
February 17, 2010: closed issue

Issue 11633: Section: Annex B (marte-ftf)

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

Invalid reference in caption of Figure B.1. The caption of Figure B.1 is currently "Figure B.1 - Structure of the NFP framework" when it should be "Figure B.1 - Structure of the VSL framework".

Resolution: Revise caption of Figure B.1
Revised Text: Change caption of Figure B.1 to: Figure B.1 - Structure of the VSL framework
Actions taken:
October 25, 2007: received issue
February 17, 2010: closed issue

Issue 11644: Section: Annex B.2.4 (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

Inconsistency between the VSL BNF and metamodel (Variable declaration) In the VSL annex, Figure B.4 (VSL::Expressions package) indicates that a Variable has "direction" property: VariableDirectionKind [0..1]. On the other hand, in the BNF, the <variable-direction> term is not between brackets, which means that it is a mandatory term. Proposed resolution: either we update the BNF or we change the multiplicity of the direction property in the metamodel.

Resolution: As far as the variable direction is optional, as described in the metamodel, the grammar should be revised and modified with the brackets for the <variable-direction> term.
Revised Text: Page 402 old text: <variable-declaration> ::= <variable-direction> '$' <variable-name> [<type-name>] ['=' <init-expression>] Page 402 new text: <variable-declaration> ::= [<variable-direction>] '$' <variable-name> [<type-name>] ['=' <init-expression>]
Actions taken:
November 6, 2007: received issue
February 17, 2010: closed issue

Issue 11649: Minor edits to MARTE Chapter 17 (marte-ftf)

Click here for this issue's archive.
Source: Carleton University (Dr. Murray Woodside, cmw(at)sce.carleton.ca)
Nature: Uncategorized Issue
Severity:
Summary:

p 311 Fig 17.2 The name of the package should be PAM_Resources      also on the left halfway down the Fig, troughput --> throughput      p 312 line 2 resources).... end bracket is missing.      p 314 line 2 Figure 17.4      line 14 "a message transmission is defined within the UML model, but if no network is specified it is an external service". Wording clarified.      p 317 Fig 7.6 CommunicationStep inherits from PAM_Workload::PAM_Step. The attributes are inherited and can be eliminated from this figure.      p 322 line 10 "identity of the resource" spelling      p 325 sec 17.4.1 para 2 line 1 "In Figure 17.9 the blockT attribute of the LAN" corrected fig number, attribute name, plus clarification.      p 325 fig 17.10 stereotype on database should be <<PaRunTInstance>>, same as for web      p 326 first line after Fig 17.10: "In Figure 17.10 a simple sequence diagram"...wrong number      second para after Fig 17.10, delete the last sentence, it refers to something in the example that was changed.      third para, replace ExecStep by Step (two occurrences, plus another on p 327 line 1)      Figure 17.13, in the box labelled dbReq, under the label should be "12.4 ms"      p 329 last line, complette the sentence: "The behavior is shown in figure 17.15".      p 330, Fig 17.15, two annotations near the bottom have "$images" which should be just "images"      p 331 first sentence "with that a set" --> with a set" and add at the end "(with 95% probability)"      p 332 para 2 line 1, replace "Process stereotypes" by "RunTInstance stereotypes"      p 332 Fig 17.17 in the attributes of the <<GaWorkloadEvent>> stereotype the cycleTime95 variable should be preceded by "out$" (it is declared here, and it is an analysis output)      lower in Fig 17.17 the $ sign should be removed from variables acquireThreads, frameSize, blocks, storeThreads, DBThreads. (they are declared in the context)      p 333 para 2 delete the paragraph (it refers to aspects of the example that have been changed)      p 335 line 2 Figure 17.21, three instances in the para      p 336 Fig 17.21, the two <<PaProcess>> --> <<RunTInstance>>      also in the context at the top "contextParams=$messageSize"      below the figure, Figure 17.21 --> 17.22 and 17.22 --> 17.23      p 337 Figure 17.22 <<PaProcess>> --> <<RunTInstance>> twice,      also in the attributes, "runTInstance = webserver" --> "instance = webserver" (was not adapted to a change in definitions during profile development)      and similarly "runTInstance = App" --> "instance = application"      below Figure 17.23, increase Fig numbers by 1 (twice)      p 338 bottom ...Figure 17.25      p 339 line 1 Figure 17.25      line 2, add to end of sentence "Figure 17.26."      Figure 17.26 legend ends with "hierarchy of Figure 17.25" (no (b))      p 340 para 2, Figure 17.26 --> 17.27 and 17.14 --> 17.15      p 341 Figure 17.27 top: two instances of @Nusers should be $Nusers the first time, then Nusers.      p 342 para 1, add a sentence for clarification:      "The Markov Chain is solved to provide the steady state probabilities of each state, and thus of each behavior in the combined workload."

Resolution: Editorial changes as follows.
Revised Text: E1: p 311 Fig 17.2 The name of the package is PAM_Resources. New figure is in visio file PAM_cmw-02-13.vsd, sheet PAM_Resources Domain Model, also for E2 and E2a. E2: also on the left in LogicalResource, halfway down the Fig 17.2, troughput should be throughput, spelling correction E2a (added), right side of Fig 17.2, in RunTimeObjectInstance, capitalization and missing colon, Throughput NFP... --> throughput: NFP_Frequency E3: p 312 line 2 BehaviorScenarios).... end bracket is missing. before: by its behaviour (BehaviorScenarios after: by its behaviour (BehaviorScenarios) E4: p 314 line 2 reads Figure 17.3; should be Figure 17.4 E5: line 14 becomes: Before: For instance if the network is defined in the deployment then a message transmission is, but if no deployment is specified it may be an external service. After: For instance if the network is defined in the deployment then a message transmission is defined within the UML model, but if no network is specified it is an external service. E6: p 317 Fig 17.6 CommunicationStep inherits from PAM_Workload::PAM_Step. Figure is in visio file PAM_cmw-02-13.vsd, sheet PAM_Communications Domain Model, also for E7 E7: Figure 17.6, the attributes of CommunicationStep are eliminated from the figure. as E6 E8: p 322 line 10 spelling of "resource" before: o resource: Resource [0..1] the identity of the resurce of which some units are passed. after: o resource: Resource [0..1] the identity of the resource of which some units are passed. E9: p 325 sec 17.4.1 para 2 line 1. Before: In Figure 17.8, the blockingTime attribute represents... After: In Figure 17.9, the blockT attribute of the LAN represents ... E10a: p 325 fig 17.10 the stereotype on database is <<PaRunTInstance>>, Revised Fig 17.10: E10b Fig 17.10 title should be: new caption: Example of interaction performance annotations E11: p 326 first line after Fig 17.10 becomes: "In Figure 17.10 a simple sequence diagram"... Before: In Figure 17.9 a simple After: In Figure 17.10 a simple E12: second para after Fig 17.10, delete the last sentence, it refers to something in the example that was changed. Remove: By default it applies to the entire operation up until the reply, but additional ExecSteps may be added as recursive messages, as is done here just before the reply. E13: Use of the old stereotype name ExecStep Change: Change everywhere to PaStep e.g.: third para after Fig 17.10: Old text: Message 2 is stereotyped both with the message size (in the CommStep stereotype) and the database operation parameters (in the ExecStep). The ExecStep is repeated an average of 1.3 times (from the repetitions attribute), New text: Message 2 is stereotyped both with the message size (in the CommStep stereotype) and the database operation parameters (in the Step). The Step is repeated an average of 1.3 times." E14: covered in E13 E15: Figure 17.13, Under the label dbReq enter the numbers 12.4 ms. New Fig 17.13 E16: p 329 last line: old text: The behavior is shown i new text: The behavior is shown in Figure 17.15. E17: p 330, Fig 17.15, two annotations near the bottom have "$images" which should be just "images" new Fig 17.15 E18: p 331 first sentence: Before: This is a soft real-time embedded system with that a set of cameras that must be scanned at least once every second. After: This is a soft real-time embedded system with a set of cameras that must be scanned at least once every second (with 95% probability). E19: p 332 para 2 line 1: Before: The deployed objects are all artifacts, and it is these artifacts that are referenced by the Process stereotypes in the activity diagram. After: The deployed objects are all artifacts, and it is these artifacts that are referenced by the RunTInstance stereotypes in the activity diagram. E20: p 332 Fig 17.17 The <<GaWorkloadEvent>> stereotype has attribute out$cycleTime95 , see figure below E21: lower in Fig 17.17 the $ sign should be removed from variables acquireThreads, frameSize, blocks, storeThreads, DBThreads. (they are declared in the context, so the $ is not needed here) see figure below Figure 17.17 E22: p 333 Delete para 2 to delete: The cycleInit Action has a hostDemand. Since it is not shown in a swimlane, its process (SchedulableResource) is given directly on the Step stereotype by the attribute "concur" (which determines its deployment and thus its host processor). E23: p 335 line 2, and twice in para 2, "Figure 17.20", becomes "Figure 17.21". E24: p 336 Fig 17.21,stereotypes of Orb and locationService are <<PaRunTInstance>> not <<PaProcess>> see figure below E25: p 336 Fig 17.21, in the context at the top has <<GaAnalysisContext>> {contextParams=in$messageSize} new figure 17.21: E26: below Fig 17.21, two figure number errors: Figure 17.21 --> 17.22 and 17.22 --> 17.23 E27: p 337 Figure 17.22 lifelines webserver and app are stereotyped <<RunTInstance>>. new figure 17.22 E28: p 337 Figure 17.22, in the attributes of webserver it is written "runTInstance = webserver". This was not adapted to a change in definitions, and should read "instance = webserver" . Similarly in App, "runTInstance = App" --> "instance = application" see figure above E29: below Figure 17.23, wrong figure numbers in "In both Figure 17.21 and Figure 17.22," increase Fig numbers by 1 . E30: p 338 last line, written Figure 17.24, should be Figure 17.25 E31: p 339 line 1 written Figure 17.24(b), should be Figure 17.25(b) E32: line 2, incomplete sentence. Add to end of sentence "Figure 17.26." Before: operation counts. After: operation counts, in Figure 17.26 E33: Figure 17.26 caption refers to Figure 17.23(b) . It should end with "hierarchy of Figure 17.25" Before: ...class invocation hierarchy of Figure 17.23(b) after: ...class invocation hierarchy of Figure 17.25 E34: p 340 para 2, Figure number errors. Figure 17.26 --> 17.27 and 17.14 --> 17.15 E35: p 341 Figure 17.27 top: two instances of @Nusers use an inconvenient prefix. They should be $Nusers the first time, then Nusers. New Figure 17.27: E36: p 342 para 1, add a sentence: para before: The analytic performance model will represent the generator as a Markov Chain governing the probabilities of making requests for different behaviours (what is sometimes called the user profile). para after: The analytic performance model will represent the generator as a Markov Chain governing the probabilities of making requests for different behaviours (what is sometimes called the user profile). The Markov Chain is solved to provide the steady state probabilities of each state, and thus of each behavior in the combined workload.
Actions taken:
November 11, 2007: received issue
February 17, 2010: closed issue

Issue 11658: Section: 11.2.1 (marte-ftf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Arnaud Cuccuru, arnaud.cuccuru(at)cea.fr)
Nature: Enhancement
Severity: Minor
Summary:

FlowPort and MessagePort are subclasses of InteractionPort. These two classes have common properties: isConjugated and isAtomatic (there is actually a third one, �direction�, but I think there is an issue with this property). These properties could be directly defined as properties of the common parent class, i.e. InteractionPort.

Resolution:
Revised Text:
Actions taken:
November 20, 2007: received issue
February 17, 2010: closed issue

Discussion:

The design rationale for GCM was to rely on the concept of FlowPort already defined in SysML. MARTE-specific message ports currently sit aside flow ports as a short-hand notation for exiting UML features.  As semantics of message ports are not totally clear (see issue 11820), and in the context of coordination efforts between the MARTE and SysML languages, it is maybe wiser not to create a strong couple between flow ports and message ports.  Note that the semantics of isConjugated for flow ports and message ports are close but not entirely similar. A conjugated flow ports means that the flow is relayed in the opposite direction of the one indicated on the port (in, out, inout). On the other hand a conjugated message port deals with provided/required behavioral features.    Disposition:	Closed, no change

Issue 11659: Section: 11.2.1 (marte-ftf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Arnaud Cuccuru, arnaud.cuccuru(at)cea.fr)
Nature: Enhancement
Severity: Significant
Summary:

The ability to type FlowPorts by Signals (or by FlowSpecifications containing FlowProperties typed by Signals) is confusing. MessagePorts (which are just a light specialization of UML ports) already enable signal-based communications. Things would be clearer if FlowPorts would only enable data-flow communications, and if MessagePorts would be used for service or signal-based communications (just as classical UML ports are). I suppose that this feature is inherited from SysML, but this is however confusing in the context of UML

Resolution:
Revised Text:
Actions taken:
November 20, 2007: received issue
February 17, 2010: closed issue

Discussion:

The design rationale for GCM was to rely on the concept of FlowPort already defined in SysML. The ability to type a flow port by a signal directly comes from SysML. That needs to be leave as unchanged to keep the consistency with the SysML::FlowPort.    Disposition:	Closed, no change

Issue 11660: Section: 11.2.1 figure 11.4 (marte-ftf)

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 figure 11.4, MessagePort is represented as an abstract class (�italic�). According to the description written in the spec, there is no particular reason to do that. This class should be represented as a concrete class

Resolution: Update Figure 11.4 to represent MessagePort as a concrete class (no italic).
Revised Text: Replace Figure 11.4, page 119 by the Figure below:
Actions taken:
November 20, 2007: received issue
February 17, 2010: closed issue

Issue 11661: Section: 11.2.1 (marte-ftf)

In the UML, a �Provided or Required� direction is implicitly associated to Signals that are exposed on the ports of a structured class or component (via the provided or required interfaces of the port). For UML consistency purpose, the �direction� attributes of SignalFeature and MessagePort should be typed by an enumeration like BFeatureKind (which is defined in the UML representation section), only with PROVIDED and REQUIRED enumeration literals. In other words, the DirectionKind enumeration (with enumeration literals IN, OUT and INOUT) should be reserved to FlowPorts, and used only to type �direction� attributes of FlowPort and FlowProperties classes.

Resolution: Proceed with suggested resolution in the profile definition and the domain model. Related issues: 11666, 11551
Revised Text: 1) Domain model � On page 119, replace the current Figure 11.4 by the following one: � On page 120, replace "SignalSpecifications have a set of SignalFeatures defining published (out) and consumed (in) signals, which are specified by the direction attribute. Particularly, atomic message ports (attribute isAtomic to true) cannot require and provide services. If the direction value of an atomic message ports is "in" (resp. "out"), it "consumes" (resp. "produces") one and only one signal. If the value is inout, the atomic message port is able to consume and publish event occurrences of the referenced signal." By "SignalSpecifications have a set of SignalFeatures defining published (required) and consumed (provided) signals, which are specified by the direction attribute. Particularly, atomic message ports (attribute isAtomic to true) cannot require and provide services. If the kind value of an atomic message ports is "provided" (resp. "required"), it "consumes" (resp. "produces") one and only one signal." � On Annex F.5.11, page 535, remove "(or signal specification)" from the DirectionKind description � On Annex F.5.11, page 535, add a description of BFeatureKind (currently missing the Beta 1) : BFeatureKind BFeatureKind is an enumeration, which literals specify the kind of behavioral features related to message ports. Literals - provided: the behavioral feature is provided by the port of the the owning entity. - required: the behavioral feature is provided by the port of the the owning entity. � On Annex F.5.11, page 539 o In the attributes section, replace "direction: DirectionKind [0..1] direction of the port when the later is not atomic." By "kind: BFeatureKind [0..1] kind of the port when the later is not atomic." o In the semantics section, replace "The "direction" attribute indicates whether the port has provided (in), required (out) or both (inout) services." By "The "kind" attribute indicates whether the port has provided or required services or signal receptions". 2) Profile � On page 121, replace the current Figure 11.6 by the following one: � On page 121, section 11.3.2.1 o remove the descriptions of the literals "in", "out", "inout" o replace the description of the literal "required" by "used to model that an operation or a signal reception is required" o replace the description of the literal "provided" by "used to model that an operation or a signal reception is provided" � On page 122, section 11.3.2.2, Notation section, replace "When applying the stereotype using its iconographical or shape forms, following icons are proposed: for BFeatureSpecifcation with kind = in; for BFeatureSpecifcation with kind = out; for BFeatureSpecifcation with kind = inout; for BFeatureSpecifcation with kind = required; for BFeatureSpecifcation with kind = provided; for BFeatureSpecifcation with kind = reqpro. Figure 11.7 describes an example using different graphical forms applying UML stereotypes." By "When applying the stereotype using its iconographical or shape forms, following icons are proposed: for BFeatureSpecification with kind = required, when all the features contained in the interface are signal receptions; for BFeatureSpecification with kind = provided, when all the features contained in the interface are signal receptions; for BFeatureSpecification with kind = required, when all the features contained in the interface are operations; for BFeatureSpecification with kind = provided, when all the features contained in the interface are operations; Figure 11.7 describes an example using different graphical forms applying UML stereotypes." � On page 123, section 11.3.2.4 o replace "If kind is in, out or inout, the BehavioralFeature will be a Reception while if kind is required or provided, it is expected to be an Operation." by "If kind is required it is expected to be a required operation or signal reception while if kind is provided, it is expected to be a provided operation or signal reception" o remove the following constraint from the definition of FlowBFeature "[1] If kind is in, out or inout, the extended BehavioralFeature has to be a Reception." "[2] If kind is required or provided, the extended BehavioralFeature has to be an Operation" � On page 128, section 11.3.2.9, remove constraint "[5] If a port is atomic, valid values for kind are only in, out or inout." � On page 128, section 11.3.2.9, Notation section o replace "When a message port is atomic, the following graphical notation may used: for one port consuming signal occurrences according to its type (i.e. direction value set to in); for one port producing signal occurrences according to its type (i.e. direction value set to out); for one port consuming and producing signal occurrences according to its type (i.e. direction value set to inout)." By "When a message port is atomic, the following graphical notation may used: for one port consuming signal occurrences according to its type (i.e. kind set to provided); for one port producing signal occurrences according to its type (i.e. kind set to required);" o replace Figure 11.13 by the figure below 3) Examples � On page 130, replace "The former port is an atomic port and its direction is set to out" by "The former port is an atomic port and its kind is set to required" (merges with resolution 11551) � Replace Figure 11.16, page 131 by the following figure (merges with resolution 11551): � Replace Figure 11.17, page 131 by the following figure (merges with resolution 11551):
Actions taken:
November 20, 2007: received issue
February 17, 2010: closed issue

Issue 11662: Section: 11.2.1 (data reception) (marte-ftf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Arnaud Cuccuru, arnaud.cuccuru(at)cea.fr)
Nature: Uncategorized Issue
Severity: Significant
Summary:

The FlowSendAction concept is introduced to enable sending of data via a FlowPort. It seems that there is no equivalent concept (action) for data reception. If a given behavior has to be expressed according to data arriving from an input port, how is the behavior �notified� that a data is available on this port (I mean: is there something equivalent to AcceptCallAction used for service oriented communication schemes)? Once that the notification has occurred in one way or another, do we access to this data with something like a ReadStructuralFeatureAction (because ports are structural features)?

Resolution: Disposition: See issue 11840 for disposition
Revised Text:
Actions taken:
November 20, 2007: received issue
February 17, 2010: closed issue

Discussion:

Issue 11663: Section: 11.3.2 (marte-ftf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Arnaud Cuccuru, arnaud.cuccuru(at)cea.fr)
Nature: Enhancement
Severity: Minor
Summary:

FlowPort and MessagePort stereotypes have two common tagged values: isAtomic and isConjugated. These two properties could be inherited from a common ancestor stereotype (for example, an abstract InteractionPort stereotype).

Resolution: Disposition: See issue 11658 for disposition
Revised Text:
Actions taken:
November 20, 2007: received issue
February 17, 2010: closed issue

Discussion:

Issue 11664: Section: 11.3.1 (marte-ftf)

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: Significant
Summary:

In figure 11.6, this stereotype is called SendFlowAction instead of FlowSendAction

Resolution: There is indeed an inconsitency between the domain model where the action is named "FlowSendAction" and the profile definition where it is called "SendFlowAction". In UML, the action that sends an object is named SendObjectAction; the action that sends a signal is named SendSignalAction. The resolution for this issue is to align the the domain model on the profile definition terminology, which is consistent with UML related actions.
Revised Text: � On page 120, replace Figure 11.5 by the figure below: � On page 120, last sentence of section 11.2.1, replace "and FlowSendAction enables a component to send a data flow via ports" by "and SendFlowAction enables a component to send a data flow via ports" � In annex F, page 563 o replace "F.5.5 FlowSendAction" by "F.5.5 SendFlowAction" o replace "A FlowSendAction is an action that sends a flow to other connected components. In that case, connected component ports indicate that they accept this type of flow in input." by "A SendFlowAction is an action that sends a flow to other connected components. In that case, connected component ports indicate that they accept this type of flow in input"
Actions taken:
November 20, 2007: received issue
February 17, 2010: closed issue

Discussion:

Issue 11665: Section: 11.3.1 figure 11.6 (marte-ftf)

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 figure 11.6, the [0..1] multiplicity of the direction tagged value is NOT displayed (whereas the [0..1] multiplicity of the kind tagged value of the MessagePort stereotype is displayed).

Resolution: Correct Figure 11.6 by adding a [0..1] multiplicity to the direction attribute on the FlowPort stereotype.
Revised Text: Replace Figure 11.6 by the following:
Actions taken:
November 20, 2007: received issue
February 17, 2010: closed issue

Discussion:

Issue 11666: Section: 11.3.2.1 (marte-ftf)

It would probably be clearer if the BFeatureKind enumeration only proposes REQUIRED and PROVIDED enumeration literals (that is to say �qualifiers� that are already used and widely accepted in the UML to denote �direction� of signals and operations in message-oriented communications). IN, OUT, INOUT should be reserved to FlowPorts and FlowProperties (that is to say for data-flow communication schemes).

Resolution: Disposition: See issue 11661 for disposition
Revised Text:
Actions taken:
November 20, 2007: received issue
February 17, 2010: closed issue

Issue 11667: Section: 11.4.1 (marte-ftf)

The Automative Example uses stereotypes that are not defined in the specification (namely SignalSpecification and ServiceSpecification

Resolution: Disposition: See issue 11551 for disposition
Revised Text:
Actions taken:
November 20, 2007: received issue
February 17, 2010: closed issue

Issue 11692: Section: 14.2 (marte-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:

In the HwCommunication model of the HwLogical profile, HwMedia should extend UML::Connector inspite of Association. Association in UML is a Classifier and the parent stereotype HwResource already extend it. By extending Connector we will help to use this concept within composite structure diagrams

Resolution: Proceed with proposal.
Revised Text: -Fig. 14-70 should be modified as following: Figure 14.70 - HwCommunication package details -The Stereotype descriptions of HwMedia and HwEndPoint should be modified accordingly.
Actions taken:
November 28, 2007: received issue
February 17, 2010: closed issue

Issue 11693: Section: 14.2 add two stereotypes corresponding to HwSensor and HwActuator (marte-ftf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

After many users feedbacks, we should add two stereotypes corresponding to HwSensor and HwActuator as specializations of the existing stereotype HwI_O from the HwDevice package. Even if we explained in the document that the HwDevice denotes both sensors and actuators, it is better to separate these concepts.

Resolution: Proceed with the proposal.
Revised Text: -Modify Figs. 14-61, 14-72 Figure 14.61 - HW_Device package details Figure 14.72 - HwDevice package details Add Class Description (Section F-9) and Stereotype descriptions (HRM Chapter): F.9.X HW_Actuator Associations o None Attributes o None Semantics Actuators are frequently used as mechanisms to introduce motion, or to clamp an object so as to prevent motion. They are devices which transform an input signal (mainly an electrical signal) into motion. F.9.X HW_Sensor Associations o None Attributes o None Semantics Sensor is a device which measures a physical quantity and converts it into a signal which can be read by an observer or by an instrument. For example, a mercury thermometer converts the measured temperature into expansion and contraction of a liquid which can be read on a calibrated glass tube. A thermocouple converts temperature to an output voltage which can be read by a voltmeter. ______________Stereotype description: HwActuator Actuators are frequently used as mechanisms to introduce motion, or to clamp an object so as to prevent motion. They are devices which transform an input signal (mainly an electrical signal) into motion (section F.9.X). Generalizations o HwI/O HwSensor A sensor is a device that measures a physical quantity and converts it into a signal, which can be read by an observer or by an instrument. (section F.9.X). Generalizations o HwI/O
Actions taken:
November 28, 2007: received issue
February 17, 2010: closed issue

Issue 11694: HwTiming model of the HwLogical profile (marte-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:

in the HwTiming model of the HwLogical profile, HwClock has a property named "frequency" that is already inherited from the HwResource stereotype. We should rename it or better remove it.

Resolution: The HwResource stereotype actually owns a "frequency" property. As there is a (indirect) generalization relationship between HwClock and HwResource, the "frequency" property of HwClock must be removed.
Revised Text: In section 14.2.3.1, fig. 14.71, remove the "frequency" property from the HwClock stereotype.
Actions taken:
November 28, 2007: received issue
February 17, 2010: closed issue

Issue 11696: Suggest to extend ClockConstraints to ClockTypes (marte-ftf)

Click here for this issue's archive.
Source: INRIA (Mr. Charles Andre, Charles.ANDRE(at)unice.fr)
Nature: Enhancement
Severity: Significant
Summary:

in the Time model, ClockConstraint is defined by  "A ClockConstraint is a Constraint that imposes dependency between clocks."      I suggest to extend ClockConstraints to ClockTypes.  => "A ClockConstraint is a Constraint that imposes dependency between clocks or between clock types."      This will allow more general constraints indirectly applied to all the clocks of a given type.

Resolution: I suggest adopting the extension
Revised Text: Para 9.3.1.3 Old: � ClockConstraint imposes dependency between clocks. � New: � ClockConstraint imposes dependency between clocks or between clock types. � Remark: there is no need for change in Fig. 9.28. Para 9.3.2.2 Old: A ClockConstraint is a Constraint that imposes dependency between clocks. A ClockConstraint refers to a set of clocks and possibly to other model elements. The clocks in the constrained elements must belong to the on clock set of this ClockConstraint. New: A ClockConstraint is a Constraint that imposes dependency between clocks or between clock types. A ClockConstraint refers to a set of clocks or clock types, and possibly to other model elements. The clocks in the constrained elements must belong to the on clock set of this ClockConstraint; the constrained clock types must be types of clocks in the on clock set. Remark: Constraint [1] becomes obsolete, and a new constraint must be added to deal with constraints on ClockTypes. Old: [1] The owner of a constraint stereotyped by ClockConstraint must be a Package stereotyped by TimedDomain. base_Constraint.owner.oclIsTypeOf(TimedDomain) [2] The constrained clocks are members of the on clock set of the ClockConstraint self.on->includesAll(self.base_Constraint.constrainedElement->select(c|c.oclIsTypeOf(Clock)) New: [1] The constrained clocks are members of the on clock set of the ClockConstraint self.on->includesAll(self.base_Constraint.constrainedElement->select(c|c.oclIsTypeOf(Clock)) [2] The constrained clock types are types of clock members of the on clock set of the ClockConstraint self.on->includesAll(self.base_Constraint.constrainedElement->select(c|c.oclIsTypeOf(ClockType).type)
Actions taken:
November 29, 2007: received issue
February 17, 2010: closed issue

Issue 11704: Editorial issue (marte-ftf)

Click here for this issue's archive.
Source: INRIA (Dr. Frederic Mallet, Frederic.Mallet(at)inria.fr)
Nature: Uncategorized Issue
Severity:
Summary:

First a typographical issue, there are some question marks (?) appearing here and there. They should be replaced by slashes (/).

Resolution: This editorial issue is resolved by removing the unexpected question marks.
Revised Text: In section 12.3.2.1, page 141, section Associations, change ?impliedConstraint: NFPs::NfpConstraint [*] into impliedConstraint: NFPs::NfpConstraint [*] In section 12.3.2.1, page 141, section Attributes, change ?kind: AllocationKind [1] into kind: AllocationKind [1] In section 12.3.2.6, page 143, section Associations, change ?/allocatedTo: ExecutionPlatformAllocationEnd [*] into /allocatedTo: ExecutionPlatformAllocationEnd [*]
Actions taken:
November 30, 2007: received issue
February 17, 2010: closed issue

Issue 11705: In 12.4, all references to figures are wrong (marte-ftf)

Click here for this issue's archive.
Source: INRIA (Dr. Frederic Mallet, Frederic.Mallet(at)inria.fr)
Nature: Uncategorized Issue
Severity:
Summary:

In 12.4, all references to figures are wrong (e.g., 12.12.8 instead of 12.8).

Resolution: This is an editorial issue. All callouts of the form 12.12.x are replaced by 12.x.
Revised Text: In section 12.3.2.2, page 142, change (Figure 12.12.9) into (Figure 12.9). In section 12.4.1, page 145, change (Figure 12.12.7) Into (Figure 12.7) In section 12.4.2, page 146, change (Figure 12.12.8) Into (Figure 12.8) In section 12.4.2, page 146, change (cf. the upper part of Figure 12.12.8) Into (cf. Figure 12.8, upper part) In section 12.4.2, page 146, change (Figure 12.12.8) Into (Figure 12.8) In section 12.4.2, page 147, change (cf. the lower part of Figure 12.12.8) Into (cf. Figure 12.8, lower part) In section 12.4.2, page 147, change (cf. the right part of Figure 12.12.8) Into (cf. Figure 12.8, right-hand side) In section 12.4.3, page 149, change (Figure 12.12.9) Into (Figure 12.9)
Actions taken:
November 30, 2007: received issue
February 17, 2010: closed issue

Issue 11707: Consider providing a tabular notation (as in SysML) (marte-ftf)

Click here for this issue's archive.
Source: INRIA (Dr. Frederic Mallet, Frederic.Mallet(at)inria.fr)
Nature: Uncategorized Issue
Severity:
Summary:

Consider providing a tabular notation (as in SysML) to easy the setting of allocations and their implied constraints when the source and the target are in diagrams too far apart.

Resolution: Add an example of a possible table that contains NFP constraints relative to an allocation activity groups.
Revised Text: In section 12.4.3, page 148, add the following text after Figure 12.9: The table below illustrates how to complete the allocation information of Figure 12.9 to represent the cost: P1 P2 inpC 4 ms 6 ms oper1 10 ms oper2 10 ms 8 ms outW 4 ms outZ 6 ms We use the standard notation for NFP Constraints, either the simplify version or the full tuple notation. Several constraints can be put in the same cell or a different table can be done for each different constraint. Any kind of NFP contraints can be specified (time, power consumption �).
Actions taken:
November 30, 2007: received issue
February 17, 2010: closed issue

Issue 11764: Section: NFP (marte-ftf)

Click here for this issue's archive.
Source: Fundacion Tecnalia Research and Innovation (Mr. Huascar Espinoza Ph.D., Huascar.Espinoza(at)tecnalia.com)
Nature: Enhancement
Severity: Significant
Summary:

[NFP] A very useful concept for NFP annotations could be the notion of �NFP level�. For instance, a NFP level may identify a group of non-functional values that are valid for a specific system operation mode. More specifically, in a component-based architecture, components can support different working modes, and these working modes may provide different non-functional values or qualities for the same services. In infrastructures supporting dynamic resource management, the resources may offer different non-functional values depending on the system load. From a conceptual viewpoint, a NFP level can identify a level of model refinement. For example, one may define NFP values according to available estimates in early development phases, while further accurate measurement values may be annotated in the same models. A NFP level, in this case, can offer a mechanism to organize non-functional values according to successive refinement stages.

Resolution: In general, this is a problem than might need some especial mechanism in UML, or a trick/cheat annotation mechanism. We recognize that we need the ability to express differing configurations for modal analysis or tradeoff analysis. However, having multiple value annotations for arbitrary cases or situations is clearly beyond the scope of the MARTE Profile and is within the scope of the UML metamodel and modeling generally. For instance, this could be supported by allowing applying a given stereotype multiple times in the same UML model element. We need to raise the issue within the UML Revision Task Force. Also, MARTE offers AnalysisContext and VSL offers variables and the two are intended for multi-case analysis. Finally, modeling of NFP_Constraint annotations for specific operational model is treated in Issue 12797 (HLAM work group). Hence, we propose to close this issue with no change.
Revised Text:
Actions taken:
December 7, 2007: received issue
October 16, 2009: closed issue

Discussion:

Resolution:  This concept is useful but it needs a careful evaluation, not only, from a discussion viewpoint, but also from a tooling viewpoint. This means that we should figure out how a tool would manage these different value versions and make them available for users.  This issue can be considered as an enhancement of the NFP chapter for a more advanced usage, and it may wait for further MARTE versions.  Hence, we propose to defer this issue  Revised Text:    Disposition:	Deferred

Issue 11765: [NFP: Profile]. Fig 8.4 (marte-ftf)

[NFP: Profile]. Fig 8.4 shows a domain model for NFP declaration. In this domain model, the NFP concept has to attributes (statisticalQualifier + direction). However, these two attributes do not appear in the corresponding Stereotype: <<Nfp>> (Fig. 8-5). Section 8.3.2.1 justifies this by saying: �the attributes of NFP, statistical qualifier and direction, are implemented in the library of NFP Types�. However, it could be useful to allow stereotype users to define these two parameters at the NFP declaration stage (and not only at the value specification stage). On the other hand, the current mechanism to define these two parameters at the NFP declaration stage (default values of NFPs), is not strict enough, as users can modify default values. So, I propose to put this two attributes (statisticalQualifier + direction) in the <<Nfp>> stereotype.

Resolution: If we adopt these two attributes for the 'Nfp' stereotype, there may exist some issues regarding to consistency and duplication of information. Indeed, statisticalQualifier and direction would be able to be specified in 'Nfp' and in the value specification too (e.g., maxLatency= (value=5, unit=ms, statQ=max)). Another question that rises is why other qualifiers would not able to be specified in 'Nfp' attributes (e.g., source) in the same way. In order to keep consistency and to avoid confusions between the domain model and profile definition, both 'statisticalQualifier' and 'direction' attributes of the 'NFP' metaclass are removed from the domain model. This means that the proposal to include these two attributes in the stereotype definition is not accepted. However, for comprehensibility, they are removed from the domain model.
Revised Text: -In section 8.2.4, remove the entire second paragraph: "NFP elements enclose two basic attributes: statistical qualifier and direction. Both have�" -In the same section (8.2.4), change the entire sixth paragraph: "Examples of qualifiers are measurement precision and value source (see NFP Types Library in Section 8.3.3.1). Source is�" By a new paragraph: "Examples of qualifiers are statisticalQualifier, direction, value source, measurement precision and (see NFP Types Library in Section 8.3.3.1). A statisticalQualifier indicates the type of statistical measure of a given property (e.g., maximum, minimum, mean, percentile, distribution). The direction attribute (i.e., increasing or decreasing) defines the type of the quality order relation in the allowed value domain of NFPs. Indeed, this allows multiple instances of NFP values to be compared with the relation "higher-quality-than" in order to identify what value represents the higher quality or importance. Source is a peculiarity of non-functional properties associated with the origin of specifications. Precision is the degree of refinement in the instruments and methods used to obtain a result." -Change Fig. 8.4 with this one: Figure 8.4 - Domain Model of NFP Declaration -In Section 8.3.2.1 Nfp (description of the Nfp stereotype), remove the following text from the first paragraph: "..Note, however, that the attributes of NFP, statistical qualifier and direction, are implemented in the library of NFP Types. The goal is to allow users modifying these attributes at value specification level." -In Section 8.3.3.1, page 42, remove the following text from both, the 'statQ' and 'dir' semantic description: "This qualifier is defined in the domain model as an attribute of an NFP. We define it here as an NFP_Type attribute to be able to specify it as a default value in a NFP, as well as a part of the NFP value itself." -In Section F.2.10 (Domain Class Description for NFP), remove the 'Attribute' subsection: "Attributes o direction: DirectionKind [0..1] direction attribute (i.e., increasing or decreasing) defines the type of quality order relation in the allowed value domain of NFPs. This allows multiple instances of NFP values to be compared wit the relation "higher-quality-than" in order to identify what value represents the higher quality or importance. o statisticalQualifier: StatisticalQualifierKind [0..1] statistical qualifier indicates the type of "statistical" measure of a given property (e.g., maximum, minimum, mean, percentile, distribution)."
Actions taken:
December 7, 2007: received issue
February 17, 2010: closed issue

Issue 11766: [Time] Fig. 9.29 (marte-ftf)

[Time] Fig. 9.29 refers to the Enumeration type �EventKind�. The formal definition of EventKind is an annex (Annex D). I�d suggest to show this definition in Fig 9.29 for a faster comprehensibility of the provided stereotypes.

Resolution: This is easy to do, but I guess that this suggestion may apply to many diagrams. In the chapter time (for instance), � Fig. 9.26 refers to TimeStandardKind, � Fig. 9.27 refers to TimeInterpretationKind � Fig. 9.28 refers to TimeInterpretationKind � Fig. 2.29 refers to EventKind My question is: do we systematically include in UML extension diagrams the used enumerations and mention in the associated text that the enumeration is part of a library given in Annex D?
Revised Text: Para 9.3.1.4 Old: TimedObservation is an abstract stereotype of TimedInstantObservation and TimedDurationObservation. It allows time expressions to refer to either in a common way. As a TimedElement, a TimedObservation makes reference to clocks. The optional obsKind attribute may specify the kind of the observed event(s). Figure 9.29 - UML extensions for Time modeling (4) New: TimedObservation is an abstract stereotype of TimedInstantObservation and TimedDurationObservation. It allows time expressions to refer to either in a common way. As a TimedElement, a TimedObservation makes reference to clocks. The optional obsKind attribute may specify the kind of the observed event(s). The Enumeration EventKind is part of the TimeTypesLibrary (Annex D.3.1). Figure 9.29 - UML extensions for Time modeling (4)
Actions taken:
December 7, 2007: received issue
February 17, 2010: closed issue

Issue 11768: GRM: Domain Model (marte-ftf)

[GRM: Domain Model] A number of GRM domain concepts make it hard to understand and use. These mainly relate to its mapping with the UML profile and its refinement in the HRM, SRM and analysis profiles: a) Figures 10.3 and 10.4 illustrate the �resource� concept as two kinds of entities: an instance (ResourceInstance) and a classifier (Resource). This separation is not explained and is not used along the remaining parts of the spec. I.e., all the associated or specialized concepts are related to �Resource�. Also, the profile only defines a �Resource� stereotype. Furthermore, NFPs are only associated with �Resource�. What about NFPs related to ResourceInstances? ? I�d suggest to remove the ResourceInstance concept, as conceptually, has not any relevance, and create confussion. b) Fig. 10-13 introduces the concepts of �ResourceUsage�, �UsageTypedAmount�, which inherits from �ResourceAmount�. However, at UML profile definition level, only <<ResourceUsage>> is provided, by using the attributes of UsageTypedAmount (from the domain model). I�d suggest to harmonize both, domain model and profile. c) A double inheritance of �ComputingResource� from �Resource� has been defined (Fig. 10.6 and, Fig. 10.11 through �ProcessingResource�). I�d suggest to remove one of them. d) GRM attempts to be a generic framework for modelling resources. However, some of the attributes seems too specific and not useful when specializing this package (e.g., HRM & SRM). For instance, �packetSize� in �CommunicationEndPoint� (Fig. 10-8) is related to specific kinds of protocols. �speedFactor� in �ProcessingResource� is an analysis-specific parameters.

Resolution: a) Instances and Classifiers are consubstantial to UML and their role in MARTE are explained in the CoreElements Chapter. The instances are there to illustrate the finite nature of resources. No change. b) UML View is an utilitarian mapping of the domain model, and in this case the harmonization is already included in the constraints that describe the rules for the utilization of resourceUsage. No change. c) Double inheritance is neither conceptually nor practically a problem. No change. d) Very few attributes have been defined, but all of them are optional and do not jeopardize the conceptual and architectural role of the stereotypes in GRM. No change Disposition: Closed, no change
Revised Text:
Actions taken:
December 7, 2007: received issue
October 16, 2009: closed issue

Discussion:

Discussion:  a)	Instances and Classifiers are consubstantial to UML and their role in MARTE are explained in the CoreElements Chapter. The instances are there to illustrate the finite nature of resources. No change.  b)	UML View is a utilitarian mapping of the domain model, and in this case the harmonization is already included in the constraints that describe the rules for the utilization of resourceUsage. No change.  c)	Double inheritance is neither conceptually nor practically a problem. No change.  d)	Very few attributes have been defined, but all of them are optional and do not jeopardize the conceptual and architectural role of the stereotypes in GRM. No change   Considering the interest of the source of the issue in searching for possible enhancements on these topics, it is deferred.   Disposition:	Deferred

Issue 11769: GRM: Examples (marte-ftf)

[GRM: Examples] Fig 10.21 shows a composite diagram, which is not conform to UML: parts are shown with attribute and operation compartments. This should be revised.

Resolution: Instead of using as an example a composite structure, it will be used a class diagram. There are no implications in the text, so the only change is in the diagram shown in Figure 10.21. The diagram is changed by the next one: The usage of the stereotype <<allocate>> in this diagram is simplified to the minimum to avoid cluttering the picture.
Revised Text: (1) Modify Fig.10.21 by the one above.
Actions taken:
December 7, 2007: received issue
February 17, 2010: closed issue

Issue 11770: [Alloc: Profile (marte-ftf)

[Alloc: Profile] The MARTE allocation concept aimed to refine the SysML allocation concept. Furthermore, it seems that the idea was to not be dependent on SysML by re-defining the same concepts in the MARTE context. For this reason, MARTE uses the same names for the generic stereotypes (<<allocated>> and <<allocate>>). However, there is a limitation in the MARTE <<allocated>> stereotype that does not allow modelers to have the same capabilities. More precisely, when using the <<allocated>> stereotype, we cannot refers to the target and source ends. We are forced to use the more specialized stereotypes: <<ApplicationAllocationEnd>> and <<ExecutionPlatformAllocationEnd>>, which is not always practical (the annotation process requires to pollute the target model) or is not always what modelers want to allocate (physical-logical allocation, or others support by SysML). So, I�d suggest to add properties: /allocatedFrom:NamedElement[*] and /allocatedTo:NamedElement[*] for the stereotype: <<Allocated>.

Resolution: Add the proposed property in the stereotype Allocated to maintain compatibility with SysML. Replace Figure 12.3 and the description text accordingly. If the property allocatedTo and allocatedFrom are already defined in the stereotype Allocated, they need not be redefined in the specialized stereotypes (ApplicationAllocationEnd and ExecutionPlatformExecutionEnd). Thus, these two stereotypes can be replaced by a mere attribute of type AllocationEndKind. All figures where either the stereotype ExecutionPlatformExecutionEnd or ApplicationAllocationEnd were displayed have been replaced by a new Figure with the new notation. No concept is introduced or removed. It is just a different lighter way to implement the domain model so as to be consistently compatible with the SysML allocation. The revised text assumes that resolution 12214 will be resolved by referring to sources of an allocation as clients and to targets as suppliers.
Revised Text: In section 12.3.1, page 139, replace Figure 12.3 by: Remove sections 12.3.2.6 and 12.3.2.8. Associations � None By: Associations � /allocatedTo: Allocated [*] The named elements that are suppliers of an "allocate" whose client is extended by this stereotype. This property is the union of all suppliers to which this instance is the client. This association is derived from any "allocate" dependency � /allocatedFrom: Allocated [*] The named elements that are clients of an "allocate" whose supplier is extended by this stereotype. The allocatedFrom elements are not necessarily derived from the same "allocate" dependency. A given element can be the supplier of several application model elements, each of which is allocated using a separate "allocate" dependency. The association is derived from any "allocate" dependency. In page 143, insert a new section (12.3.2.5) between the two sections "AllocationNature" (12.3.2.4) and "AllocationKind" (formerly 12.3.2.5) to describe the newly introduced enumeration AllocationEndKind: 12.3.2.5. AllocationEndKind (from Alloc) AllocationEndKind is an enumeration type that differentiates the application allocation end from the execution platform allocation end. Literals � undef should be used when no differentiation is to be made on the nature of the allocation end. It could be either an application allocation end or an execution allocation end or something else (as in SysML, where no distinction is made). � application identifies an allocation end as being on the application side of the allocation. This allocation end must be the source (the client) of an allocate dependency. � executionPlatform identifies an allocation end as being on the execution platform side of the allocation. This allocation end must be the target (the supplier) of an allocate dependency. � both identifies an allocation end as being both on the application and the execution platform side of the allocation. This allocation must be the source (the client) of an allocate dependency and the target (the supplier) of an (another) allocate dependency. In section 12.4.1, page 146, replace Figure 12.7 by: In section 12.4.2, page 147, replace Figure 12.8 by:
Actions taken:
December 7, 2007: received issue
February 17, 2010: closed issue

Discussion:

see ptc/2008-06-05 for revised text/figures

Issue 11771: MoCC: Examples (marte-ftf)

[MoCC: Examples] Fig. 13-22 misuse time observation declarations when using the occurrence index at declaration level. This should be specified in time expressions.

Resolution: Rather, time observation declarations should be specified in time expressions.
Revised Text: Revise Figure 13.22 to use proper VSL syntax. Replace Figure 13.22 with:
Actions taken:
December 7, 2007: received issue
February 17, 2010: closed issue

Discussion:

see ptc/2008-06-05 for figure in revised text

Issue 11772: HRM: Examples (marte-ftf)

[HRM: Examples] Figure 14-78, 14-82, 14-83, 14-84 specify tagged values with a syntax that does not correspond to VSL (e.g., 166MHz, 64 MB). It should be clarified the syntax used, or align to VSL.

Resolution: Figures 14-78, 14-82, 14-83 and 14-84 are modified in order to be consistent with VSL syntax, and with the syntax which has been allowed in the resolution of issue 11781.
Revised Text: Figure 14-78 is modified as follow: Figure 14-82 is modified as follow: Figure 14-83 is modified as follow: Figure 14-84 is modified as follow:
Actions taken:
December 7, 2007: received issue
February 17, 2010: closed issue

Discussion:

see ptc/2008-06-05 for resolution

Issue 11773: [GQAM: General] (marte-ftf)

[GQAM: General] The references (publications) along the text should be moved to the annex.

Resolution: Replace each reference by suitable words which name the authors of documents, and insert the references in Annex G.
Revised Text: Revisions are given both for gqam and pam. 1. Add to Annex G these references, inserted alphabetically by first author: Jin, Jingwen and Nahrstedt, Klara, : "QoS Specification Languages for Distributed Multimedia Applications: A Survey and Taxonomy", IEEE Multimedia, July/September 2004 (Vol. 11, No. 3) pp. 74-87. Franaszek, P.A. and Nelson, R.D. , "Properties of delay-cost scheduling in time-sharing systems", IBM J. of Research and Development, Volume 39, Number 3, 1995. Skene, James, Lamanna, David and Wolfgang Emmerich, "Precise Service Level Agreements", Proc 26th International Conference on Software Engineering (ICSE'04), pp. 179-188). Cruz, R.L. and Arvind V. Santhanam , "Optimal Routing, Link Scheduling and Power Control in Multi-hop Wireless Networks", Infocom 2003. Smith, C.U. and L. Williams, "Performance Solutions", Addison- Wesley 2000 Lavenberg, S, "Performance Modeling Handbook", Academic Press, 1983). Menasce, Daniel, and Virgilio Almeida, "Capacity Planning for Web Services: metrics, models, and methods", Prentice Hall, 2001 Xu, J, M. Woodside, and D. Petriu, "Performance Analysis of a Software Design using the UML Profile for Schedulability, Performance and Time," Proc. 13th Int. Conf. on Modeling Techniques and Tools for Computer Performance Evaluation (TOOLS 03), Urbana, USA, Sept. 2003. TPC (Transaction Processing Council), "TPC Benchmark W (Web Commerce) Specification", Version 1.8, Feb 19, 2002 2. Complete this reference that is already in Annex G Jain, Raj, The Art of Computer Performance Modeling, Wiley, 1991. 3. Modify the text where the references were made, in 11 places 11773-1 p 259, no change 11773-2 p 260, sec Time-Related NFPs, para 2, sentence 2: original text: A recent survey is given in (Lui Sha, Tarek F. Abdelzaher, Karl-Erik �rz�n, Anton Cervin, Theodore P. Baker, Alan Burns, Giorgio C. Buttazzo, Marco Caccamo, John P. Lehoczky, Aloysius K. Mok, "Real Time Scheduling Theory: A Historical Perspective", Real-Time Systems, Volume 28, Number 2-3, November 2004, pp. 101-155). new text: A recent survey is given by Sha et al. 11773-3 p 260 second-last paragraph original text: Soft deadline: a stated percentage of responses must be complete within this delay. Quality-of-service specifications often are stated in these terms (QoS Specification Languages for Distributed Multimedia Applications: A Survey and Taxonomy, Jingwen Jin Klara Nahrstedt, IEEE Multimedia, July/September 2004 (Vol. 11, No. 3) pp. 74-87, esp Fig 4.). new text: Soft deadline: a stated percentage of responses must be complete within this delay. Quality-of-service specifications often are stated in these terms (see e.g. Jin and Nahrstedt, esp. Fig 4.). 11773-4 p 260 last paragraph original text: Delay cost function: a function of delay should be within a target value, or should be minimized. This is useful for trading off delays of multiple streams of requests that compete for resources. (see e.g. Franaszek and Nelson). new text: Delay cost function: a function of delay should be within a target value, or should be minimized. This is useful for trading off delays of multiple streams of requests that compete for resources. (e.g. P. A. Franaszek and R. D. Nelson , Properties of delay-cost scheduling in time-sharing systems, IBM J. of Research and Development, Volume 39, Number 3, 1995). 11773-5 p 261 para2 original text: The expression of such measures in service level agreements was discussed and surveyed recently in: James Skene, D. Davide Lamanna, Wolfgang Emmerich, "Precise Service Level Agreements", Proc 26th International Conference on Software Engineering (ICSE'04), pp. 179-188). They point out the value of analysis of the execution path of the software. new text: The expression of such measures in service level agreements was discussed and surveyed recently by Skene et al. They point out the value of analysis of the execution path of the software. 11773-6 p 261 last para of Sec 15.1 original text: In wireless networks the power of transmission may be controlled, affecting messaging speed. Optimal policies take into account competition between nodes ("Optimal Routing, Link Scheduling and Power Control in Multi-hop Wireless Networks", R. L. Cruz and Arvind V. Santhanam, Infocom 2003) new text: In wireless networks the power of transmission may be controlled, affecting messaging speed. Optimal policies take into account competition between nodes (see e.g. Cruz and Santhanam). 11773-7 p 264, second last para original text: BehaviorScenarios in similar forms are widely used for timing analysis. In schedulability analysis they are called "task sequences" (Jane Liu, "Real Time Systems", Wiley), and specifications of timing normally refer to certain scenarios. Performance models are also created from scenarios (C.U. Smith and L. Williams, "Performance Solutions", Addison- Wesley 2000).... new text: BehaviorScenarios in similar forms are widely used for timing analysis. In schedulability analysis they are called "task sequences" (Jane Liu, "Real Time Systems"), and specifications of timing normally refer to certain scenarios. Performance models are also created from scenarios (see e.g. Smith and Williams, "Performance Solutions")... 11773-8 p 327, second para after Fig 17.11 original text: The QN model ignores the performance impact of the process thread pool sizes. To represent this we require an extended queueing network or layered network, that models the simultaneous possession of two resources (threads and processor). (S. Lavenberg, "Performance Modeling Handbook, Academic Press, 1983). new text: The QN model ignores the performance impact of the process thread pool sizes. To represent this we require an extended queueing network or layered network, that models the simultaneous possession of two resources (threads and processor). (see, e.g. Lavenberg, "Performance Modeling Handbook"). 11773-9 p 328 para 1 original text: The service time of the logical server is the holding time of the thread. Solution of an EQN is approximate, using various strategies (see eg, Jain or Menasce). new text: The service time of the logical server is the holding time of the thread. Solution of an EQN is approximate, using various strategies (see eg, Jain, or Menasce and Almeida). 11773-10 p 329 , first para after the list: original text: The example is elaborated from the Transaction Processing Council standard scalable benchmark TPC-W for electronic commerce, by putting ... new text: The example is elaborated from the Transaction Processing Council standard scalable benchmark TPC-W for electronic commerce (see TPC for the specification), by putting ... 11773-11 p 331 para 1. original Text: This is a soft real-time embedded system with that a set of cameras that must be scanned at least once every second. new: This is a soft real-time embedded system with that a set of cameras that must be scanned at least once every second, as described by Xu et al.
Actions taken:
December 7, 2007: received issue
February 17, 2010: closed issue

Issue 11774: GQAM: Domain Model & Profile (01) (marte-ftf)

[GQAM: Domain Model & Profile] The PrecedenceRelation concept (fig 15.3) could be used to specify delays due to e.g., queues. However, PrecedenceRelation only exists in the Domain Model. Its implementation is intended to be supported by existing UML concepts (e.g., forks, joints, etc.) I�d suggest to define the corresponding stereotype (<<PrecedenceRelation>>) in order to allow for modelling delays or other precedence patterns like event divisors: a number of event occurrences triggers an execution.

Resolution: This enhancement is not necessary, since everything it would provide can already be done using scenario Steps, and done better. However the method for showing an event divisor using steps should be added to the text. Since a precedence relation always leads to one or more steps, properties such as queueing etc can be attached to the step. The step is a better place for these properties because there may be multiple branches in a precedence relation (a branch or fork), each with its own properties. For example, a fork precedence would have a different waiting on each branch of the fork, which would be complex to describe or specify within the fork, but very easy on the following steps. An event divisor or multiplier can be provided using the CommStep stereotype. We assume that the event is a call invoking a Step. The call can be stereotyped as a CommStep, which has a repetition attribute. If this is set to N, it means the call is repeated N times, giving event multiplication. If it is set to 1/N, it means that every Nth execution of the sender gives a call... an event divisor. If the repetition attribute is specified as a deterministic NFP, it should be defined to be interpreted as 1/N for an integer N, determined by rounding to an integer if necessary. A stochastic division is also possible.
Revised Text: p 264, 3rd-last para, before: A CommunicationStep defines the conveyance of a message between system entities, and has an attribute of the message size. after: A CommunicationStep defines the conveyance of a message between system entities, and has an attribute of the message size. The repetitions attribute of a CommunicationStep Inherited from Step) denotes multiple sendings (event multiplication) if >1, or decimation of sendings (event division) if <1. If repetitions is deterministic and less than 1 it is interpreted as event division by N = 1/repetitions, rounded to the nearest integer. That is, every Nth execution of the sending Step causes on cal to occur. Repetitions may also be a random quantity.
Actions taken:
December 7, 2007: received issue
February 17, 2010: closed issue

Issue 11775: GQAM: Domain Model & Profile (02) (marte-ftf)

[GQAM: Domain Model & Profile] The notions included in the GQAM Observer package (TimingObserver, LatencyObserver) may be used not only for analysis purposes . I�d suggest to move this concepts to a more general package.

Resolution:
Revised Text:
Actions taken:
December 7, 2007: received issue
February 17, 2010: closed issue

Discussion:

Discussion:  This is identical to issue 11776. Also, as discussed in issue resolution 11846, these concepts are analysis-specific concepts. There is no need to put them in a more general package.  Disposition:	Duplicate

Issue 11776: GQAM: Domain Model & Profile (03) (marte-ftf)

GQAM: Domain Model & Profile] The notions included in the GQAM Observer package (TimingObserver, LatencyObserver) may be used not only for analysis purposes . I�d suggest to move this concepts to a more general package

Resolution: This is identical to issue 11775, it was submitted or entered twice Disposition: Closed, no change
Revised Text:
Actions taken:
December 7, 2007: received issue
February 17, 2010: closed issue

Issue 11777: GQAM: Domain Model & Profile (04) (marte-ftf)

[GQAM: Domain Model & Profile] A TimingObserver (Fig. 15-4) refers to 0 or 1 start event occurrence and 0 or 1 end event occurrences, which are modelled by TimedInstantObservation elements. However, more refined TimingObservers can define the synchronization between several events. I�d suggest to change the multiplicity of the start and end observation points to [*].

Resolution: Change the multiplicity of the start and end observation points to [*].
Revised Text: (1) Fig 15.4 p 266, the startObs and endObs associations should both have multiplicity of [*] at the TimedInstantObservation end. (2) Fig 15.8 p 272, the startObs and endObs associations should be replaced: old text: "startObs 0..1" and "endObs 0..1" new text: "startEvent * " and "endEvent * " (3) Sec 15.3.2.14, (a) the stereotype is TimingObs not TimingObserver (b) the StartEvent and EndEvent associations should both have multiplicity of [*]
Actions taken:
December 7, 2007: received issue
February 17, 2010: closed issue

Issue 11778: [SAM: Profile] (marte-ftf)

[SAM: Profile] The SaStep domain concept (Fig. 16-4) has an association to a SharedResource. This is very useful to model execution steps that take a resource along all their execution (alternative to use the AcquireStep and ReleaseStep). However, this association has not been reflected in the UML profile. This should be added in Fig. 16-7.

Resolution: (FTF Group) Strike the phrase "Business Management Perspective" Change it by "system perspective"
Revised Text: In section 2.1, in paragraph 1, in the second sentence, replace: "Though all of them are related from the business management perspective and�" By ""Though all of them are related from the system perspective and�".
Actions taken:
December 7, 2007: received issue
February 17, 2010: closed issue

Discussion:

Noted in Passing: The superclass of SaStep is sometimes named as GQAM_Workload::Step and other times named as GQAM_Workload::GaStep. Such inconsistencies SHOULD be corrected. Resolution: The rationale for the existence of SaStep is that one can use this to model execution steps that use a resource throughout their execution. An alternative approach would be to explicitly acquire and release the resource using the AcquireStep and the ReleaseStep steps. The proposed resolution is to add the existing GRM::Scheduling::MutualExclusionResource metaclass to Figure 16.7 where the SAM Profile is presented, to show the usedResource association from GQAM_Workload::GaStep, and to show the sharedResource association from SaStep to SharedResource. Revised Text: Figure 16.7, a UML metamodel diagram, MUST be remodeled as described. The second paragraph on printed page 290, beginning "In this model, steps�" SHALL conclude with "� network adapters) identified using the sharedResource association of the SaStep instances." The "Associations" paragraph of Section 16.3.2.3, which claims that SaStep has no associations MUST be rewritten to state, "sharedResource : SharedResource [0..1] {subsets GQAM_Workload::GaStep::usedResource}". Review Figure 16.12 for SaStep usage. The "Associations" paragraph of Section F.11.3, which claims that SaStep has a sharedResource association of none-to-many multiplicity, MUST be rewritten to state the same multiplicity of the association as that in Section 16.3.2.3 and in Figures 16.7 and 16.4.

Issue 11779: GRM, GQAM, SAM: DomainModel & Profile (marte-ftf)

[GRM, GQAM, SAM: DomainModel & Profile] A number of non-functional properties for scheduling analysis are specified by a worst-case and a best-case duration value. The MARTE library for NFP types defines a NFP_BoundedDuration data type. This type could be used to type �bounded� durations in SAM. For instance: endToEndTime (fig. 16-7), execTime (fig. 10-18), latency (fig. 15-8), contextSwitchTime, ISRswithTime (fig. 16-9).

Resolution: This two attributes may be not sufficient, it is better to have all the statistical qualifiers over multiple values of NFP_Duration supported. To minimize editorial impact and a deep revision of side effects, the additional attributes provided in NFP_BoundedDuration will be added to NFP_Duration. With the variation that "min" will be represented as "best" and "max" as "worst", this keeps the dual dimension in the utilization of multiple values and the specification of variability in the context in which the value is used. This implies minimal changes to NFP_Duration, eliminating NFP_BoundedDuration, and change the only reference to it (in RealTimeFeature) to NFP_Duration.
Revised Text: (2) Modify Fig.D.5 adding the two attributes "worst: Real" and "best: Real" in the definition of NFP_Duration (3) Modify the definition of the RealTimeFeature element so that the attribute boundDI has type NFP_Duration instead of NFP_BoundedDuration, in Figure 13.5, and sections 13.3.2.9 rtf, and F.7.10 RealTimeFeature. (4) Eliminate the type NFP_BoundedDuration from Fig D.5
Actions taken:
December 7, 2007: received issue
February 17, 2010: closed issue

Issue 11780: SAM: General (marte-ftf)

SAM: General] Time-triggered system modelling are supported in some way by the TimeTableDriven scheduling policy (fig 10-19). However, it is not clear how to specify a table (format) and where (e.g. Scheduler stereotype, schedule: OpaqueExpression attribute?). Some examples for time-triggered system modelling should be provided in MARTE.

Resolution: Schedulers of the other variants of SchedPolicyKind use configuration parameters which are expressed in the SchedulableResource::SchedParameters attributes. To be consistent, when modeling TimeTableDriven scheduling, the SchedParameters stereotype SHALL include a tag definition SchedParameters::tableEntry of type OpaqueExpression which SHALL store the information necessary to schedule the SchedulableResource according to the algorithm of the Scheduler's time-triggered, table-based scheduling. The algorithm of the time-triggered, table-based scheduler SHALL be expressed within the Scheduler::schedule's OpaqueExpression.
Revised Text: In Figure 10.11, on page 93, provide the tag definitions of SchedParameters as stated and revised in Section 10.3.3.8. In Figure 10.14, on page 96, provide the stereotype SchedParameters and enumerate its tag definition attributes as stated and revised in Section 10.3.3.8. Show that SchedParameters extends UML::Classes::Kernel::InstanceSpecification. In Figure 10.19, on page 99, provide the tag definitions of SchedParameters as stated and revised in Section 10.3.3.8. In Section 10.3.3.8, on page 112, add the Attribute tag definition of tableEntry with this definition: o tableEntry: OpaqueExpression [0..*] parameters used for the particular SchedulableResource in a time-triggered, table-based scheduler whose algorithm is expressed in the associated Scheduler::schedule. In Section F.4.31, on page 529, replace the absence of content with appropriate text that relates to the content in Section 10.3.3.8. In Section 10.4, on page 113, provide a simple example which expresses an algorithm (preferably in no specific programming language) for time-triggered, table-based scheduling within an instance of a Scheduler::schedule attribute and which uses per-SchedulableResource scheduling parameters expressed in the tableEntry attributes of a SchedParameters.
Actions taken:
December 7, 2007: received issue
February 17, 2010: closed issue

Issue 11781: NFP: value syntax (marte-ftf)

[NFP: value syntax] It may be useful to have a shorter (graphical) notation for NFP types including the value and unit slots only, e.g., �(55, kHz)�, or still �55 kHz�, instead of the notation �(55, -, kHz, max, -, est, -)� with all the qualifiers. This will enhance the graphical models readability. While this feature may be only a tool-specific mechanism, which could propose a graphical view (short notation) of the repository notation (full notation), it would be useful to standardize this notation in the MARTE spec.

Resolution: We include this syntax (value-unit) only as a tool-specific feature to show NFP values in graphical models. This means that the syntax defined in VSL is still valid for NFP values (tuple notation). The reason is that the model repository needs to keep all the required NFP value information (value, unit, plus other qualifiers).
Revised Text: It is important to note that such a shorter (graphical) textual notation will be normative, in the sense that it is valid. However, it is not mandatory. -Insert a new Section between 8.3.2 and 8.3.3: "8.3.3 Graphical Syntax of NFP Value Specification In this section, we define an alternative graphical syntax for value specifications having NfpType as data type. This syntax consists of a pair of a value and a unit: <nfp-value> ::= <value-specification> [' ' <unit-enumeration>] The following are typical examples: 5 ms # a duration value 50 kHz # a frequency value Note that this notation is for the graphical view of models only. The tuple notation (see Section B.3.3.9) is still valid for NFP values (NfpType inherits from VSL::TupleType), both in graphical models and in the repository as well. For instance, the NFP value: '50 kHz' can be specified in the model repository as: '(50, -, kHz, max, -, est, -)' or '(value=50, expr=null, unit=kHz, statQ=max, dir=null, source=est, precision=null)' The main rationale of the "value-unit" notation is readability of graphical models. Specific tools could provide more flexibility in the graphical notation. For instance, users may be able to customize the elements of a tuple in a NFP value specification that should be displayed. However, because of its common usage in engineering models in general, the "value-unit" notation is normative (although not mandatory) in MARTE." -Change Fig. 8.9 by the following one: Figure 8.9 - Example of user model for analysis with NFP annotations
Actions taken:
December 7, 2007: received issue
February 17, 2010: closed issue

Issue 11810: MARTE PAM Parameters for behaviour demanded by a Step (marte-ftf)

Click here for this issue's archive.
Source: Carleton University (Dr. Murray Woodside, cmw(at)sce.carleton.ca)
Nature: Uncategorized Issue
Severity:
Summary:

A PaStep can make a demand for a behaviour, much like a macro, to be included in the Step. An example of the use of this, is to include a complex handshake protocol for exchanging a message between objects on different nodes.      The profile has      behaviourDemands: list of Scenarios to be included  behaviourCount: corresponding list of number of invocations during the step      It also should support parameters to the Scenario, such as the message size. This requires a way of binding a value in the invocation to a value in the Scenario.      Possible resolution:      Add behaviorParm : a corresponding list of tuples. Each element of a tuple could be expressed as (variable=value), with the variable name corresponding to the variable used in the Scenario      More complex and powerful resolution: Let the context variables decdlared for a Scenario be implicitly regarded as an ordered list of arguments, when the Scenario is invoked. The tuple could then give just the values for the list. A NUL value could be used to mean, do not override the value given within the Scenario.      The same considerations apply to PAM::externalOpDemands. A similar concern applies to GQAM::servDemands, but the resolution may have to be different as Operations already have arguments and the defining scenario is attached indirectly.      A broader version of this issue is parameterizing behaviours in general: it seems to be incomplete in MARTE.

Resolution: withdrawn by submitter
Revised Text:
Actions taken:
December 9, 2007: received issue
March 25, 2008: closed issue

Issue 11811: Movement of some stereotypes and attributes from PA to GA (marte-ftf)

Click here for this issue's archive.
Source: Carleton University (Dr. Murray Woodside, cmw(at)sce.carleton.ca)
Nature: Uncategorized Issue
Severity:
Summary:

Some stereotypes were introduced in PA because they were identified by these authors as being useful... but they might be equally useful to someone in other analyses.      An example is the <<noSync>> stereotype on a branch of a par, to say explicitly that this branch does not synchronize at the end of the par. This provides forks that do not join... a performance optimization in some cases.

Resolution: withdrawn by submitter
Revised Text:
Actions taken:
December 9, 2007: received issue
March 25, 2008: closed issue

Issue 11817: Section: HRM (marte-ftf)

Click here for this issue's archive.
Source: THALES (Dr. Laurent Rioux, laurent.rioux(at)thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

Some stereotype in the HRM profile do not have icons. And the icons proposed in the specification need to be improved to clarify the understanding of the model. possible solution: change icons on HRM and add icons on stereotype do not have yet

Resolution: I (S�bastien G�rard) have asked to the source of the issue what kind of improvement he was requiring or if he had some better proposition of iconographical representation, and he answered he had no proposals of improvement. I decided then without more feedback on graphical improvement to close with no change this issue. Disposition: Closed, no change
Revised Text:
Actions taken:
December 13, 2007: received issue
October 16, 2009: closed issue

Discussion:

Discussion:  The description of the issue concerns an improvement of the spec rather than the resolution of a real issue. I would propose to address the remark as an improvement of MARTE, in a next version of the spec.  Disposition:	Deferred

Issue 11818: Section: 1 MARTE spelling missing in the introduction (marte-ftf)

Click here for this issue's archive.
Source: THALES (Dr. Laurent Rioux, laurent.rioux(at)thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

MARTE spelling missing in the introduction possible resolution: introduce the term MARTE in the introduction of the document MARTE: Modeling and Analysis of Real-Time and Embededd systems

Resolution: Can be added as a subtitle on the cover page.
Revised Text: On Cover page of the document, replace: "A UML Profile for MARTE" by "A UML Profile for MARTE: Modeling and Analysis of Real-Time and Embedded systems" In the introduction section (section1.1), paragraph 1, sentence 2, replace: "�profile for MARTE (in short MARTE),�" by "�profile for MARTE (in short MARTE for Modeling and Analysis of Real-Time and Embedded systems),�"
Actions taken:
December 13, 2007: received issue
February 17, 2010: closed issue

Issue 11820: ports in GCM (marte-ftf)

This issue is about ports in GCM. In UML if a port is typed with an interface, this interface is automatically considered as provided by the port (see port description section 9.3.11 in UML Superstructure). In GCM it is possible to type a MessagePort with an interface (BFeatureSpecification). Moreover if a MessagePort direction is specified to be "required", and if the port is typed with a BFeatureSpecification interface, this interface contents are considered to be provided by the port according to UML. This results in a confusing specification: a MessagePort specifying a required interface provides that interface at the same time.

Resolution: Using message ports may create redundancy and inconsistency with the UML composite structures, as mentioned in the summary of this issue. Indeed, BFeatureSpecification can own FlowBFeatures, where some of the features may have their ��kind�� set to ��provided��, and some others set to ��required��. According to UML interface derivation rules, this may lead to ambiguous cases where a BFeatureSpecifcation (used to type a message port) is considered to be provided by the port, even if some of the behavioral features of the BFeatureSpecification actually represent ��required�� features. A similar problem appears when a message port, with direction set to Required, is typed by an interface (i.e. the default rule in UML is that this interface is supposed to be provided by the port). [Note: More generally, the issue described here also concerns non-atomic flow ports, i.e. flow ports that are typed by a FlowSpecification. According to UML interface derivation rule, the FlowSpecification used to type the port would also be considered as a provided interface.]. The proposed resolution for issue 11820 is designed according to the following guidelines: � it provides a mechanism for specifying provided and required interfaces of standard UML ports, in a way that is more intuitive and direct that the standard UML mechanism (which relies on derivation rules based on the port type, and which is particularly tedious for defining interfaces required by a port. Indeed, it technically implies to define a Classifier with a � use � relationship that targets the set of Interfaces to be required). It was indeed the original motivation for the ClientServerPort stereotype. � it should avoid conflicts with default UML rules concerning interface derivation, based on port type. The general idea behind the proposal is that ClientServerPorts can be used in different ways. The current solution explicitly identifies two usages (c.f. definition of /isAtomic = true or false) whereas in the resolution we identify three potential usages according to designer intent: � atomic usage: the designer wants to directly associate a signal with the port (i.e. the port is typed by the signal), specifying that the component owning the port is either able to send (i.e. ClientServerPort::kind = required) or receive (i.e. ClientServerPort::kind = provided) the signal via this port. � interface-based usage: the designer wants to directly provide and/or require standard UML interfaces on a port. � feature-based usage: the designer wants to associate a ClientServerSpecificaion (i.e. a consistent set of behavioral features, some of which may be provided or required) with the port. Additionally, issues 12802 (difference UML Port and MessagePorts) and 12801 (semantic difference between an atomic FlowPort typed by a signal and a MessagePort typed by a signal) have been stated as duplicate/merge with this issue. We provide a resolution for these issues in the revised text of the GCM chapter, described in this document. For issue 12802: Some text is added to explain that ClientServerPort (formerly MessagePort) is just a kind of syntactic sugar for UML Ports. Concerning issue 12801: we explain that FlowPorts and ClientServerPorts are almost semantically equivalent when signals are used to characterize their potential interactions (i.e. atomic FlowPort typed by a signal S, atomic ClientServerPort typed a signal S, or non-atomic ClientServerPort exposing a Reception for a signal S). Additionally, issue 12579 (that has been stated as duplicate/merge with this issue) concerns the renaming of elements (i.e. FlowBFeature) that are involved in the definition of MessagePort itself. We start this ��merged resolution�� with the resolution of issue 12579. The primary reason of this name was to have a name constructed in a similar way than to the one of the FlowPorperty but dedicated to BehavioralFeature. I (Me, S�bastien G�rard, the original author of that concept) agree that this name is may be not the best one� Moreover as similar concepts exist in AUTOSAR, a very important standard for automotive domain and with which it is expected that MARTE will have strong relationships in near future, I propose to do following renamings: � FlowBFeature => ClientServerBFeature � BFeatureSpecification => ClientServerSpecification � MessagePort => ClientServerPort PS: I propose not only to rename FlowBFeature, but also the other concepts related to MessagePort, for global consistency of the specification.
Revised Text: see ptc/2009-05-12 pages 30 -36
Actions taken:
December 19, 2007: received issue
October 16, 2009: closed issue

Discussion:

Discussion:  While flow ports brings new concepts that are relevant for the real-time and embedded domain (flow-oriented communications), message ports have been introduced in MARTE just as a short-hand notation for existing UML features (provided and required interfaces).  As a consequence, using message ports may create redundancy and inconsistency with the UML composite structures, as mentioned in the summary of this issue.  Providing a clarification on this issue might require starting a discussion on the rationale of message ports in GGM. Unfortunately, this discussion cannot be organized in the time frame of the current FTF.  Disposition:	Deferred

Issue 11822: Giving an attribute a variable name and an expression value (marte-ftf)

Click here for this issue's archive.
Source: Carleton University (Dr. Murray Woodside, cmw(at)sce.carleton.ca)
Nature: Uncategorized Issue
Severity:
Summary:

I am not clear of the status of this, but it seems that to use the profile flexibly one needs to be able to assign a variable name to an NFP, and also a value. Then the variable name can be used to change the value in studies, in a traceable way. The value can be an expression too.      A possible resolution would be to allow expressions to read as variable = expression.

Resolution: Resolution: This is already supported by VSL: A 'variable declaration' expression can have assigned an "initialExpression". Concretely, the following syntax has been adopted in VSL (page 402): <variable-declaration> ::= <variable-direction> '$' <variable-name> [<type-name>] ['=' <init-expression>] This means that you can have NFP values such as (extended notation): myLatency = (value= 5.0, expr= $var1=var2+var3/3, unit=ms) or the short notation: myLatency = (5.0, $var1=var2+var3/3, ms) Hence, this issue is close with no change. Revised Text: Disposition: Closed, no change
Revised Text:
Actions taken:
December 19, 2007: received issue
February 17, 2010: closed issue

Issue 11829: Figure E.6 (p 460) (marte-ftf)

Click here for this issue's archive.
Source: INRIA (Mr. Pierre Boulet, Pierre.Boulet(at)lifl.fr)
Nature: Uncategorized Issue
Severity:
Summary:

the two composition links from the Reshape stereotype to the Tiler Stereotype should be removed

Resolution: Replace figure E.6 by removing the two composition links from Reshape to Tiler.
Revised Text: Replace figure E.6 by Disposition: Resolved
Actions taken:
December 17, 2007: received issue
February 17, 2010: closed issue

Discussion:

see ptc/2008-06-05 for detailed resolution

Issue 11830: Reshape stereotype (pp 463,464) (marte-ftf)

Click here for this issue's archive.
Source: INRIA (Mr. Pierre Boulet, Pierre.Boulet(at)lifl.fr)
Nature: Uncategorized Issue
Severity:
Summary:

the default topology of a link connecting two shaped elements should be specified. Proposal: use a direct element-wise topology when the shapes of both ends are identical, undefined otherwise

Resolution: Proposal: use a direct element-wise topology when the shapes of both ends are identical, undefined otherwise.
Revised Text: Replace in page 463 Reshape This stereotype maps the Reshape concept of page 415 to assembly connectors. It allows specifying a set of potential connector instances between multidimensional arrays of potential port instances. by Reshape This stereotype maps the Reshape concept of page 415 to assembly connectors. It allows specifying a set of potential connector instances between multidimensional arrays of potential port instances. If the shapes of these arrays of port instances are identical and the connection topology is a direct point-to-point topology, the Reshape stereotype can be omitted. If the shapes are different and no Reshape stereotype is specified, the link topology is indeterminate.
Actions taken:
December 17, 2007: received issue
February 17, 2010: closed issue

Issue 11831: Shaped stereotype (pp 464,465): (marte-ftf)

Click here for this issue's archive.
Source: INRIA (Mr. Pierre Boulet, Pierre.Boulet(at)lifl.fr)
Nature: Uncategorized Issue
Severity:
Summary:

a notation to refer to a particular element of a shaped collection by index should be added. Proposal: use ElementName[index].

Resolution: Proposal: use ElementName[index].
Revised Text: At the end of the Shaped stereotype description (page 465), in the section Notation, add To refer to a specific Element that is part of a multidimensional collection specified by a shape, one can use the ElementName[index] notation where index is the index of this element in the collection. The index is a vector of n naturals where n is the number of dimensions of the shape. The indexes are numbered from 0 to the size of the corresponding dimension minus 1. For example if a part is declared as PE: ProcessingElement [{10,10}] one can refer to the specific PE of index {0,6} by PE[{0,6}].
Actions taken:
December 17, 2007: received issue
February 17, 2010: closed issue

Issue 11832: Tiler stereotype (pp 465,466 (marte-ftf)

Click here for this issue's archive.
Source: INRIA (Mr. Pierre Boulet, Pierre.Boulet(at)lifl.fr)
Nature: Uncategorized Issue
Severity:
Summary:

a default value should be specified for the various attributes as it is done for the TilerSpecification data type; the type of the tiler attribute should be TilerSpecification

Resolution: Add various default values in the descriptions of the stereotypes as in the TilerSpecification and modify the type of the tiler attribute to TilerSpecification.
Revised Text: Page 466, replace Attributes o origin: MARTE_Library::MARTE_DataTypes::IntegerVector [0..1] specifies the origin of the reference tile in the array. o fitting: MARTE_Library::MARTE_DataTypes::IntegerMatrix [0..1] specifies how the pattern is mapped to a tile in the array with respect to a reference element. o paving: MARTE_Library::MARTE_DataTypes::IntegerMatrix [0..1] specifies how an index in the repetition space is mapped to the reference point of a tile with respect to the reference tile. o tiler: Tiler [0..1] can be use as an alternative to the three previous attributes to specify the origin, fitting and paving using a Tiler object. by Attributes o origin: MARTE_Library::MARTE_DataTypes::IntegerVector [0..1] specifies the origin of the reference tile in the array. If it is absent, the origin is the zero vector of dimension the dimension of the array. o fitting: MARTE_Library::MARTE_DataTypes::IntegerMatrix [0..1] specifies how the pattern is mapped to a tile in the array with respect to a reference element. If it is not specified, the fitting matrix is the identity matrix. o paving: MARTE_Library::MARTE_DataTypes::IntegerMatrix [0..1] specifies how an index in the repetition space is mapped to the reference point of a tile with respect to the reference tile. o tiler: TilerSpecification [0..1] can be use as an alternative to the three previous attributes to specify the origin, fitting and paving using a Tiler object.
Actions taken:
December 17, 2007: received issue
February 17, 2010: closed issue

Issue 11833: E.4 Examples (pp 467,468): (marte-ftf)

Click here for this issue's archive.
Source: INRIA (Mr. Pierre Boulet, Pierre.Boulet(at)lifl.fr)
Nature: Uncategorized Issue
Severity:
Summary:

put square brackets around the shapes on the diagrams

Resolution: Correct all the diagrams of the examples to add the required brackets.
Revised Text: Replace figure 8 by and replace its caption Figure E.82 - D repetition of a FFT component by Figure E.8 - 2D repetition of a FFT component Replace figure 9 by Replace figure 10 by
Actions taken:
December 17, 2007: received issue
February 17, 2010: closed issue

Discussion:

see ptc/2008-06-05 for resolution

Issue 11834: Figure E.10 (p 468): (marte-ftf)

Click here for this issue's archive.
Source: INRIA (Mr. Pierre Boulet, Pierre.Boulet(at)lifl.fr)
Nature: Uncategorized Issue
Severity:
Summary:

the fitting of the toTiler should be {{0,0}}.

Resolution: Change the fitting as suggested.
Revised Text: Resolved as part of the resolution of issue 11833. The figure E.10 replacement solves both issues. It is repeated below for completeness.
Actions taken:
December 17, 2007: received issue
February 17, 2010: closed issue

Issue 11835: RTEConnector should be removed from RTEMoCC (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Revision
Severity: Significant
Summary:

Subject: RTEConnector should be removed from RTEMoCC The chapter 13 defines a model of computation for active objects and passive objects. It precisely defines the metaclasses involved in this model of computation, building upon the MARTE foundation packages (e.g. GRM). Additionally, chapter 13 introduces the concept of RteConnector, which is basically a specialization of a UML connector with additional NFP. While the definition of active/passive object provide useful features for RTES design. The concept of real-time connector is more discutable. This concept overlaps with GRM::CommunicationMedia. It seems that all that relates to NFP characterics of a communications between entities should be defined in GRM::CommunicationMedia (latency, jitter, bandwith) As a beneficial side effect, removing RTEConnector whould remove the depdendency from RTEMoCC to GCM, which is not usued anywhere else. Proposed resolution: remove RTEConnector metaclass and stereotype and push the related attributes (bandwith, blockT, packetT, transMode) into GRM (e.g., in CommunicationMedia).

Resolution: Remove RTEMoCC::RteConnector and refactor GRM::CommunicationsMedia to gain the attributes of the deleted RteConnector, and update the elements that use similar attributes in the rest of the spec so that they become consistent, that is at least in HwMedia.
Revised Text: Delete Figure 13.7 and the last paragraph of page 154 which continues onto page 155. Delete entirely Section 13.3.2.8 on page 161. Delete entirely Section F.7.11 on page 549. Delete attribute bandwith in the definition of HwMedia in section 14.2.3.2, in section F.9.28, and in Figure 14.70 In Section 10.3.2.4, on page 101, add the following bullet phrases: o bandwidth: NFP_DataTxRate [0..1] capacity of the communication element when applicablelink. o packetT: NFP_Duration [0..1] time to transmit the element used as a communication quantum, usually called a packet, the size in bits of this quantum is described by the attribute elementSize. o blockT: NFP_Duration [0..1] time the communicationMedia is blocked and cannot transmit due to the transmission of one communication quantum. o transmMode: MARTE_Library::MARTE_DataTypes::TransmModeKind [0..1] defines the transmission mode, one of the following values: {simplex, half-duplex, full-duplex}. In Section F.4.7, on page 515, add the following bullet phrases: o bandwidth: NFP_DataTxRate [0..1] capacity of the communication element when applicablelink. o packetT: NFP_Duration [0..1] time to transmit the element used as a communication quantum, usually called a packet, the size in bits of this quantum is described by the attribute elementSize. o blockT: NFP_Duration [0..1] time the communicationMedia is blocked and cannot transmit due to the transmission of one communication quantum. o transmMode: MARTE_Library::MARTE_DataTypes::TransmModeKind [0..1] defines the transmission mode, one of the following values: {simplex, half-duplex, full-duplex}. In Figure 10.8, on page 91, show the attributes for CommunicationMedia as stated in Section 10.3.2.4.
Actions taken:
December 20, 2007: received issue
February 17, 2010: closed issue

Issue 11836: Find a better name of the RTEMoCC profile (marte-ftf)

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

Subject: Find a better name of the RTEMoCC profile. This acronym is long and does not sound pretty fancy. I would suggest looking for a better alternative.

Resolution: Replace RTEMoCC with "High-level Application Modeling" and use the acronym of "HLAM"
Revised Text: Replace all instances of RTEMoCC with HLAM.
Actions taken:
December 20, 2007: received issue
February 17, 2010: closed issue

Issue 11837: chapter 11 (GCM) should be moved in the Part II of the specification (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Revision
Severity: Significant
Summary:

Subject: chapter 11 (GCM) should be moved in the Part II of the specification. Details: The argument to push GCM in Part I of MARTE was that it was used BOTH for modeling and analysis. After having read the whole document, I do not see any dependency from the GQAM to GCM therefore I suggest pushing back GCM in Part II of MARTE (the design part) to make the MARTE foundations thiner. Proposed resolution: move chapter 11 in Part II and update the chapter number accordingly.

Resolution: Proceed according to the proposed resolution.
Revised Text: � Remove the GCM package from the MARTE foundations and add it to the MARTE design model, in Figure 6.4, page 13 � Change the chapter number of GCM from 11 to 12 � Change the chapter number of Alloc from 12 to 11 � Move the GCM chapter to Part II � Remove references to GCM, page 19 � Update the chapter number of Alloc, page 19 � Add a reference to GCM, page 149 � Change the section number of GCM in Annex F from F.5 to F.6 and update the sub-section numbers accordingly � Change the section number of Alloc in Annex F from F.6 to F.5 and update the sub-section numbers accordingly � Update the Table Of Content of the specification
Actions taken:
December 20, 2007: received issue
February 17, 2010: closed issue

Issue 11838: What are semantics of real-time features on provided/required interfaces? (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Enhancement
Severity: Significant
Summary:

Resolution: This resolution proposes general clarifications on the usage of the stereotype �RtFeature� (including its usage and underlying semantics in the context of provided/required interfaces). The stereotype �RtFeature� can be applied to multiple elements Additionnaly, issue 12954 also requires some clarifications. These clarifications require modifications to figures that are modified in this resolution. We therefore propose to resolve problems identified in issue 12954 in this document, and we state resolution to issue 12954 as duplicate/merge with this resolution 11838. More specifically, issue 12954 has identified the following problems: 1- In figure 3.10 the stereotype <<RtFeature>> is displayed as <<Rtf>>. : In the proposed modification of figure 3.10, this inconsistency is removed. 2- In section 13.3.2.8 the stereotype �RtFeature� is said to extend the UML Behavior element; however in section 3.10 this extension is not shown. : In the proposed resolution, �RtFeature� does not apply anymore to behavior. 3- Figure 3.11 does not show all the attributes of the �RtAction� stereotype. The new version of figure 3.11 proposed in this resolution includes all the attributes. 4- The use of the stereotype �RtBehavior� is not clear. An example in 13.4 would be of great help. This stereotype has been deleted. Its attributes are indeed only characterizations of the event pool of an active object. Its attributes have been added to �RtFeature�, and prefixed with �sr� (for Schedulable Resource). (InvocationAction, BehavioralFeature, Message, Signal). In order to clarify to meaning of these multiple extensions, some text is added in the section describing the stereotype �RtFeature� to explain that: the most basic element on which �RtFeature� can be applied is InvocationAction, and that any other places where this stereotype is applied enables to specify a kind of default value in the case where the stereotype �RtFeature� has not been applied on a particular InvocationAction. Additionnaly, the title of this issue suggests that real-time features could be contextual to the usage of interfaces (for example, one may want to specify that a real-time feature concerns an operation of an interface that is provided on a given port). Therefore, we propose the following modifications: The stereotype �RtFeature� is modified so that it now also extends the Port metaclass. The stereotype �RtSpecification� is introduced, and it extends the Comment metaclass. All the attributes of �RtFeature� are removed from �RtFeature�, and they are added to �RtSpecification�. An �RtFeature� can now own multiple �RtSpecification�, and it is possible to specify the behavioral feature that is concerned by this �RtSpecification�. For example, a port can be stereotyped with �RtFeature�. It can then own multiple �RtSpecification�, where each of these �RtSpecification� may concern a behavioral feature of a provided or required interface of this port.
Revised Text: see ptc/2009-05-12 pages 38 - 62
Actions taken:
December 20, 2007: received issue
October 16, 2009: closed issue

Discussion:

Resolution:  An interface is a contract. Today, for software systems, interfaces typically express only a specification for available behaviors (e.g. Operations) or permissible information (e.g. to some extent FlowSpecs). Arguably, though, one ought to be able to express performance, cost, reliability, quality, and other non-functional properties in an interface specification. Therefore, it is not unreasonable to infer that an NFP Constraint on an interface is a constraint also on any realization of that interface. If NFP Constraints on a Provided interface conflict with NFP Constraints on a Required interface, clearly any attempt to pair the two entities should be difficult.  As there currently is no section within Chapter 13 which discusses Interfaces generally or specifically applying NFP Constraints to Interfaces, the topic should be, at this late date, deferred to a subsequent revision of the MARTE specification.  Disposition:	Deferred

Issue 11839: the GCM chapter should define a causality model for flows (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Enhancement
Severity: Significant
Summary:

Subject: the GCM chapter should define a causality model for flows. Details: the GCM chapter introduces the notion of flow port as a structural feature of a structured class. However, the specification does not states what happens when a flow comes into / get out of a flow port. There should be a reference to behaviors owned by this structured class. Proposed resolution: enhance the GCM chapter.

Resolution: This issue concerns the semantics of FlowPorts and indeed its underlying causality model. Indeed, the issue 11840 is also clearly related to this issue. Issue 11840 summary is following: �Subject: Support for flows in activities. Details: The current specification provides a limited support for flow in activity diagrams. The GCM chapter introduces the FlowSendAction stereotype. However, there is no way to indicate the pins used to define the data to send. At the same time, there is no action (such as FlowReceiveAction) to indicate how to receive a flow. It seems that activity parameters are an interesing alternative to specify incoming and outgoing flows in activity diagrams (SysML follows this approach). Proposed resolution: Remove the FlowSendAction stereotype and provide a support for BOTH incoming and outgoing flows through activity parameters (maybe a stereotype would need to be defined here).� Both issues are treated in this document." As stated by Conrad Bock in [Conrad Bock: �UML 2 Activity and Action Models Part 4: Object Nodes�, Journal of Object Technology, vol.3, no.1, pp.27-41], there are traditionally two ways for considering dataflow communications: - a �pull� semantics with the following characteristics: o Passive: the arrival of data in the data store does not trigger behaviors per se. It is indeed additional actions, for example time-triggered actions, that when needed pull the data from the data store. o Non-depleting: the use of data in the store does not remove it from the store - a �push� form of data flow and storage, with the following characteristics: o Active: the arrival of data in the data store triggers execution of some behavior. o Depleting: the data arriving on the port is not store locally. Data is indeed conveyed to the triggered behavior. The objective of this resolution is to enable GCM's users to address both forms of data flow. For that purpose, we are making the following proposal: - Data sending: o The �SendFlowAction� stereotype is removed (NOTE: in this case, one resolves in the same time the issue 12286. This latter was then set to Duplicate/Merged and refer this resolution). Indeed, the standard UML SendObjectAction is already well suited to express a data emission. The execution of a SendObjectAction results in the emission of a message encapsulating the sent object (which can be an instance of any classifier). Note that, SendObjectAction inherits from InvocationAction and as defined in the composite structure package, this action already enables to specify a target port for the action (see, UML2 spec., section 9.3.9 on p. 182). o In addition to specify the flowProperty on which a SendObjectAction is applied (or more generally to specify the feature of a non-atomic FlowPort or ClientServerPort on which an InvocationAction is applied), one introduces the �GCMInvocationAction� stereotype which extends InvocationAction (from InvocationActions). In this case, the stereotyped invocation action targets a nonatomic flow FlowPort or a featureBased ClientServerPort (i.e. a ClientServerPort which have been specified using a ClientServerSpecification. Cf resolution 11820 for a precise definition of these concepts), and one of its features. For example, if a non-atomic output flowport has two flow properties (i.e. it is typed by a FlowSpecification with two out flow properties), the �onPort� property of SendObjectAction enables to specify that this flow port is used as a target of the send. In addition, the �onFeature� property of �GCMInvocationAction� enables to specify which of the two flow properties the target of the send is. - Data reception events: Once we have dealt with data sending, it is also required to be able to deal with data receipt. For that purpose, we introduce the �DataEvent� stereotype. This latter extends the UML's AnyReceiveEvent metaclass. This metaclass is the most generic kind of concrete MessageEvent. DataEvents are raised when data (which have been sent as a consequence of a SendObjectAction) are received on a behavioral FlowPort. In the case of a non-behavioral FlowPort, data are propagated along associated delegation connectors, and no event is raised at all (just as for standard UML Ports). DataEvents raised as a consequence of data receptions on behavioral ports are then stored in the event pool of the owning object just like any other kind of UML events would be. It implies that the UML semantic variation points related to event management also applies to �DataEvent� (and typically concerning the way events are ordered in and extracted from the event pool). This is however fully in line with the philosophy of the GCM which aims to be as generic as possible. Particular semantic interpretation on the way DataEvent are dispatched and consumed would thus require a specialization of the GCM, such as the one proposed in the HLAM subprofile of MARTE. The definition of �DataEvent� mimics the definition of the UML SignalEvent metaclass, in the sense that it is possible to attach a classifier to the event in order to characterize it (just as it is possible to attach a Signal to a SignalEvent). More precisely, the classifier that can be attached to the event must be a classifier that can be used to type flow ports or flow properties (i.e., DataType and Class). In order to avoid confusion with SignalEvent, a constraint imposes that the classifier associated with the DataEvent cannot be a Signal. DataEvents can then be exploited by triggers of transitions within a StateMachine, or by triggers of AcceptEventActions within an Activity. Hence, it is possible to specify reactions to reception of data of a particular type (i.e., data which are typed by a classifier compatible with the classifier associated with the DataEvent). Note that such triggers can natively be related to particular ports i.e., the ports from which the DataEvent have been raised. o UML Triggers can natively be related to a particular port. Additionally, in MARTE, we introduce the possibility to specify more precisely the origin of a trigger. The �GCMTrigger� stereotype is defined for that purpose. It extends the UML Trigger metaclass and it owns a property that enables to specify which feature of the FlowSpecification of a FlowPort or ClientServerSpecification of a ClientServerPort (cf. resolution 11820 for details on ClientServerPort) is the origin of the trigger. It is thus possible to specify reactions that are, for example, related to the occurrence of a given DataEvent on a non-atomic FlowPort, and for a particular FlowProperty. Of course this advanced mechanism is mainly interesting for non-atomic port, because in other cases, there are no possible ambiguities. The concepts denoted below were defined to support the �push� semantic of MARTE's ports (including flow and client-server ports), and they are well aligned with the standard event model. The �active� characteristic of the �push� semantics is covered because the reception of a data on a behavioral FlowPort raises a DataEvent, which can be used as a trigger in a behavior. The �depleting� characteristics of the "push" semantics is covered because, according to the standard UML semantics, once an event has been consumed by a behavior, it is no longer available in the event pool to trigger other behaviors. Concerning the �pull� semantics of MARTE's FlowPorts, no particular extensions are required. A simple modeling pattern (suggested by SysML and Conrad Bock�s article, respectively for the usage of delegation connectors and the usage of properties for persistent data storage and nondepleting data use) is indeed sufficient as explained next. According to the UML 2 superstructure, a non-behavioral port should have delegation connectors, so that incoming requests can be propagated along these connectors to parts of the composite structure owning the port (in other case as said previously and as it is defined in the UML2 specification, messages are lost). Then there are two possibilities for the parts connected to the ports: either they delegate also the requests to some of their parts, or they deal directly with the request triggering the execution of one of their behaviors. This case fits also with the MARTE's client-server port and it is thus reasonable to have a similar mechanism for MARTE's flow ports. At the end of the delegation chain, a non-behavioral input atomic flow port should have at least one delegation connector targeting a part which is type-compatible with the port (if there is no delegation connector, the data is simply lost). When a data is received on such a port and then delegated through the connector, no DataEvent is raised (which is in line with the �passive� aspect of the �pull� form of data flow). In this case, the semantics says that the data is written in the part targeted by the delegation connector, replacing any existing value. The data stored on the targeted properti can then be used when needed by the behavior of the component, typically via a ReadStructuralFeatureAction (which has no depleting effect on the value of the property). For more complex storage policies, we propose to introduce the � DataPool � stereotype. Two default storage and selection policies are defined: LIFO and FIFO. � DataPool � can also be associated with user-defined policies, via its �insertion� and �selection� properties. These properties explicitly reference UML Behaviors, respectively describing how a data is to be inserted in the property, and how a set of data is to be selected from the property. When a data is received on a FlowPort with a delegation connector targeting a property stereotyped with �DataPool�, the semantics says that the data is inserted in the pool following the description provided by �insertion� behavior (Concerning the usage of the �selection� behavior, see the following description concerning the usage of connectors between properties and behavior parameters). This rule can be extended for non-atomic flow ports, where each flow property should be associated with a delegation connector (by convention, when one of the flow properties is not associated with a delegation connector, the FlowPort should be behavioral, and data received on this FlowPort and related to this FlowProperty will raise a DataEvent). Finally, issue 11840 proposes the possibility of an explicit �binding� between flow ports of a component and parameters of the component behaviors. This additional proposition is an alternative solution to the mechanisms described below. Moreover, let's notice that SysML is relying on this mechanism, but SysML is lacking two points: firstly, SysML does not define indeed clearly how that works (i.e., either by name matching between ports and parameters, or (probably) by using a BindingConnector), and secondly SysML does define also it�s the clear meaning of this mechanism. Hence, we provide next a clear semantics for this mechanism aligned (i.e., compatible) with the �pull� and �push� semantics we have considered until now: - �pull� semantics: A standard UML connector is expressed between a property (which used to be the target of a delegation connector, but does not need to be) of the component and an IN or INOUT parameter of a behavior or operation (which would typically belong to the owner of the port, but does not need to be). It means that the values passed to the parameters of the behavior (or operation) when the behavior is called are actually the values of the connected properties. The connectors just prevent from the usage of an explicit ReadStructuralFeatureAction to get the value associated with the properties. Note that this usage of connectors is compatible with the abstract syntax of UML, since both Property and Parameter are ConnectableElements. In the case where the connected property is stereotyped with � DataPool �, its �selection� Behavior is used to compute the values to be selected (from the property) and to be passed to the parameter. - �push� semantics: Connectors are directly expressed between input non-behavioral flow ports (respectively the output flow ports) and input parameters (respectively the output flow ports) of the classifierBehavior Activity of the composite structure owning the ports. The idea is that each incoming data received on a flow port will be propagated to a parameter of the classifier behavior. The data associated with the input message will be handled as a token on an ActivityParameterNode corresponding to the parameter. The token will then enter the chain of computation described by the set of object flows and actions of the activity (with respect to the token propagation semantics of UML activities). At the end of the computation chain, tokens will be propagated to ActivityParameterNodes corresponding to output parameters of the Activity. If a delegation connector is modeled between such a parameter and an output flow port of the composite structure, a message containing the produced data will be emitted through the flow port (just as if SendObjectAction with this value would have been applied on the flow port). The standard semantics of UML activities implies that tokens related to required input parameters must be available for the called activity to start, and that token corresponding to output parameters will be made available on corresponding output pins once the activity is finished. Note that if one wants the activity modeling the classifierbehavior to be able to accept inputs (on its input parameters) and produce outputs (on its output parameters) while it is executing, input and output parameters of the activity should typically be specified as streaming parameters. Examples are provided in the revised text.
Revised Text: see ptc/2009-05-12 pages 68 - 86
Actions taken:
December 20, 2007: received issue
October 16, 2009: closed issue

Discussion:

Discussion:  This issue was accepted in transfer from the GCM working group.  The consensus of the MARTE FTF is that this issue raises a valid point, that the RTEMoCC chapter should describe the causality implications of the MARTE flows, there is some synergy with the Executable UML specifications, and that there is insufficient time available to document this material prior to the voting on Ballot 2. Therefore, it is, for now, to be deferred.  Disposition:	Deferred

Issue 11840: Support for flows in activities (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Revision
Severity: Significant
Summary:

Subject: Support for flows in activities. Details: The current specification provides a limited support for flow in activity diagrams. The GCM chapter introduces the FlowSendAction stereotype. However, there is no way to indicate the pins used to define the data to send. At the same time, there is no action (such as FlowReceiveAction) to indicate how to receive a flow. It seems that activity parameters are an interesing alternative to specify incoming and outgoing flows in activity diagrams (SysML follows this approach). Proposed resolution: Remove the FlowSendAction stereotype and provide a support for BOTH incoming and outgoing flows through activity parameters (maybe a stereotype would need to be defined here).

Resolution: See issue 11839 for disposition
Revised Text: Disposition: See issue 11839 for disposition
Actions taken:
December 20, 2007: received issue
October 16, 2009: closed issue

Discussion:

Discussion:  Defining a complete support for flow in activities can be done with two different approaches.  The first approach is to define actions for sending and receiving flows. GCM currently follows this approach but provides an incomplete support because it defines only a SendFlowAction action and not its accept/receive counterpart.  The second approach is to follow SysML and to extend activity parameters and pins by a specific stereotype. This approach has advantages as it leverages more the capabilities offered by plain UML, for which execution semantics have been already precisely defined.  The FTF as a whole did not have the opportunity to discuss the pros and cons of the two approaches. Therefore, it is better to defer this issue to collect everyone's input on this issue.  Related issue: 11662  Disposition:	Deferred

Issue 11841: How to model the amount of memory occupied by an OS resource (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

Subject: How to model the amount of memory occupied by an OS resource (eg. File, buffer, blackboard, ARINC ports). Details: We would need to know the memory used by OS objects (buffer, sem, blackboard�). This maybe needs further discussion but why not introducing a memorySizeElements attribute on SwResource? It might be also applicable on a GRM::Resource ?

Resolution:
Revised Text:
Actions taken:
December 20, 2007: received issue
February 17, 2010: closed issue

Discussion:

Discussion:  The SwResource stereotype owns a memorySizeFootprint attribute which allows referencing the amount of memory occupied by an OS resource  Disposition:	Closed, no change

Issue 11842: HwMedia.bandwidth attribute may need to be generalized in GRM ancestor clas (marte-ftf)

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

Subject: HwMedia.bandwidth attribute may need to be generalized in a GRM ancestor class. Details: According to another issue, the RTEConnector.bandwidth attribute could be pushed from RTEMoCC::RTEConnector to GRM. If so, it would make sense to factorize the HwMedia.bandwith with a common ancestor (the concept of "bandwith" being SW/HW agnostic). Proposed resolution: remove the bandwidth attribute from HwMedia and push it into a GRM ancestor class.

Resolution: The proposed resolution shall be followed and inserted in the resolution of issue 11835. The bandwidth attribute should be removed from HwMedia and placed in CommunicationMedia in GRM with a more general explanation. This solution unfortunately may impact terminology in future GQAM variations, where different names are used for the same concepts. Now the conflict is not present since there is not direct inheritance. Considering that issue 11835 is in the same ballot all changes should be consistently indicated to vote for them in that issue. Hence this is now in the scope of Issue 11835. Revised Text: See issue 11835, where explanation of attribute GRM:: CommunicationMedia should include a text like : bandwidth: NFP_DataTxRate [0..1] the capacity of the communication element when applicable Disposition: Duplicated
Revised Text:
Actions taken:
December 20, 2007: received issue
February 17, 2010: closed issue

Issue 11843: How to model the size the heap size of an Ada runtime with SRM? (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

How to model the size the heap size of an Ada runtime with SRM?

Resolution: An attribute must be added to the MARTE::SRM::SW_Concurrency::swConcurrentResource. heapSizeElements: UML::Kernel::Classes::TypedElement [0..*]
Revised Text: Figure 14.5 Old: New: Figure 14.25 Old : New : Stereotype Description section to update In the SwConcurrentResource descriptions, an attribute must be added: heapSizeElements : TypedElement [0..*] elements which maps the semantic of the resource heap size in case of dynamic memory allocation. Domain Description section to update heapSizeElements : ModelElement [0..*] elements which maps the semantic of the resource heap size in case of dynamic memory allocation.
Actions taken:
December 20, 2007: received issue
February 17, 2010: closed issue

Discussion:

see ptc/2008-06-05 for revised text

Issue 11844: How to model the size of code occupied in ROM? (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

How to model the size of code occupied in ROM? There seems to be a missing concept here.

Resolution:
Revised Text:
Actions taken:
December 20, 2007: received issue
February 17, 2010: closed issue

Discussion:

Discussion:  The GRM:usageResourceType seems adequate  Disposition:	Closed, no change

Issue 11846: Enhance the concept of Observer in GQAM (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Enhancement
Severity: Significant
Summary:

Subject: Enhance the concept of Observer in GQAM. Details: The concept of observer is definitely useful although limited to timing and latency. There should be a way to support (at least) throughput and capacity observers. Maybe a more generic mechanism would be useful here?

Resolution: After significant discussion it was agreed in a telecon that the existing stereotype has the desired generality. The necessary extensions should be applied to the existing observer by users, as they need them, rather than trying to define something that will satisfy all needs. All that is needed is to describe this process of extension, and to rename the TimingObserver to TimedObserver, signifying an observation over an interval of time.
Revised Text: The revised text is given in issue 12283, which renamed it to TimedObserver. It is repeated here, including the renaming: There are five parts: 1. Old text p 265, at the beginning of Section 15.2.3 Timing Observers (Figure 15.4) are conceptual entities that collect timing requirements and predictions related to a pair of user-defined observed events. In this sense, TimingObserver uses Timed Instant Observations (from the Time subprofile) 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 in the figure. Timing observers are a powerful mechanism to annotate and compare timing constraints against timing predictions provided by analysis tools. Timing observers can be used as predefined and parameterized patterns (e.g., latency, jitter) or by means of more elaborate expressions (e.g., written in OCL or VSL) since TimingObserver inherits all the modeling capabilities from NfpConstraint. LatencyObserver specifies a duration observation between startObs and endObs, with a miss ratio assertion (percentage), a utility function which places a value on the duration, and a jitter constraint. Jitter is the difference between maximum and minimum duration. A timing observer may be attached to the start and end observed events, or to a behavior element such as a Step. In the latter case the start and end events are the start and end events for execution of the behavior element. 1. REvised text: TimedObservers (Figure 15.4) are conceptual entities that define requirements and predictions for measures defined on an interval between a pair of user-defined observed events, named startObs and endObs in the figure. A TimedObserver must be extended to define the measure that it collects. The LatencyObserver makes this extension to collect the duration between the two events, and some properties of that duration. Other extensions can be defined to describe power or energy usage, memory usage, etc., over a partial behavior. A TimedObserver uses Timed Instant Observations (from the Time subprofile) to define the start and end events in a given behavioral model. It may express constraints on the defined measure, for instance on the duration between the two time observations. It can use predefined and parameterized patterns (e.g., latency, jitter) or more elaborate expressions (e.g., written in OCL or VSL) since TimedObserver inherits all the modeling capabilities from NfpConstraint. A TimedObserver may be attached to particular start and end observed events, or to a behavior element such as a Step. In the latter case the start and end events are the start and end events for execution of the behavior element. LatencyObserver specifies a duration observation between startObs and endObs, with a miss ratio assertion (percentage), a utility function which places a value on the duration, and a jitter constraint. Jitter is the difference between the maximum and minimum duration. 2. Fig 15.4 is revised by renaming TimingObserver to TimedObserver. 3. Profile Fig 15.8 is revised by renaming gaTimingObserver to gaTimedObs 4. Sec 15.3.2.14 p 281 Old text: 15.3.2.14 GaTimingObserver The GaTimingObs stereotype maps the TimingObserver domain element (section F.10.18) denoted in Annex F. GaTimingObs is a purely conceptual entity that serves to collect timing requirements and predictions that relates to user-defined observed events. In this sense, GaTimingObs uses UML TimeObservations to define the observed event in a given behavioral model. New Text: 15.3.2.14 GaTimedObs The GaTimingObs stereotype maps the TimedObserver domain element (section F.10.18) denoted in Annex F. 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. 5. Appendix 5 section F.10.18 Replace TimingObserver by TimedObs
Actions taken:
December 20, 2007: received issue
February 17, 2010: closed issue

Issue 11847: description of the Clock stereotype (marte-ftf)

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

In the description of the Clock stereotype, UML::InstanceSpecification should appear as an extension and not a generalization

Resolution: In the proposed way
Revised Text: Para 9.3.2 Old: Extensions � None Generalizations � InstanceSpecification (from UML::Classes::Kernel) New: Extensions � InstanceSpecification (from UML::Classes::Kernel) Generalizations � None
Actions taken:
December 20, 2007: received issue
February 17, 2010: closed issue

Issue 11848: Section: Annex A: AADL-like models with MARTE (marte-ftf)

Click here for this issue's archive.
Source: THALES (Dr. Madeleine Faugere, madeleine.faugere(at)thalesgroup.com)
Nature: Enhancement
Severity: Significant
Summary:

INTRODUCTION (to the following eigth issues) The section �AADL-like models with MARTE� in annex A: �Guidance example for use of MARTE� contains a mapping of UML concepts and stereotypes from MARTE and SysML to AADL metaclasses. The mapping is, in principle, a partial subset that was specified under the following considerations: 1. A UML native concept is used when it is considered expressive enough to represent an AADL concept (e.g., AADL Modes maps to UML State Machines). 2. Else, a MARTE concept is adopted (e.g., MARTE hwBus & hwDevice represents AADL Bus and Device). 3. If neither UML nor MARTE extensions have the corresponding AADL concept, SysML extensions are used (e.g., SysML Block represents AADL System). 4. Otherwise, new stereotypes are proposed in this annex (e.g., subprogram & port-group stereotypes to represents the corresponding AADL concepts). 5. Properties defined in the Predeclared Property Set of the AADL spec. are annotated in a UML Note stereotyped as �properties�. This section also provides some examples illustrating the use of UML (+MARTE+SysML) in order to specify AADL models. Some issues rise from this approach: [MARTE-AADL Issue 1] One general question is the scope of this annex. Either it will keep its �guidance� nature, providing a subset of mapping cases only, or it will provide a more formal mapping covering all AADL concepts and properties. Following a meeting with Peter Feiler (a core AADL author), the goal is to provide a full UML profile for AADL. If the approach turns towards the second option (full support), a more careful exploration of AADL concepts should be done. This means that this annex should guarantee that all the AADL metaclasses are mapped and that, at least, the predeclared AADL property set is supported. The SAE AADL committee supports a full UML profile of AADL. The committee would prefer to have it defined in the context of MARTE rather than a separate UML profile. A draft of a UML profile for AADL exclusively defined in terms of UML exists. This document can be harvested for the MARTE-based profile definition for AADL, e.g., for stereo type names and graphical symbol definitions

Resolution: In agreement with Peter Feiler from the SAE, MARTE will provide a full support to the AADL language, meaning that all AADL concepts and properties will be supported by MARTE. Annex A provides "guidelines" explaining and illustrating the use of MARTE for modeling and analysis of AADL applications. AADL-MARTE Concept alignment will be addressed by this issue; AADL pre-declared property set alignment will be addressed by issue #11582 and property language alignment with issue #11583. A proposed way of using MARTE with different abstraction levels is proposed in issue #11851, differencing design, software platform allocation, and hardware platform allocation phases and concepts. In addition to these refinement processes, analysis views providing specific and reusable analysis information are provided. The following table proposes a mapping between AADL and MARTE concepts, without introducing new MARTE concepts (stereotypes) in the annex.
Revised Text: Following tables will integrally replace section A.3.1 "MARTE for AADL summary Table". AADL concept MARTE/UML concept for design MARTE/UML concept for analysis AADL definition Software component Process MARTE memoryPartition stereotype on UML Classifier NA Represents a protected address space and contains executable code or data. Thread MARTE swSchedulableRessource stereotype on UML Classifier NA Concurrent schedulable unit of sequential execution through source code Thread Group MARTE abstract SwSchedulableResource stereotyped UML classifier composed of swSchedulableResource stereotyped UML classifiers which are not abstract NA Component abstraction for logically organizing thread, data and thread group component within a process Shared Data SwMutualExclusionResource stereotype on UML classifier Marte SwMutualExclusionResource stereotype on UML classifier For analysis purpose, the associated to RealeaseService" and AcquiredServices stereotype attributes will point towards "read" and "write" operations, which could be respectively stereotyped GaAcqStep and GaRelStep for analysis purposes Data access via interface "Resource", "ConcurrencyResource", "ProcessingResource" concepts of GRM depending on the user's precision requirements. Can be refined with SRM equivalent concepts "swConcurrencyResource", etc NA Subprogram UML Operation NA Represents sequentially executable source text Subprogram Calls UML Operation call on sequence diagrams. For software plateform design, can be model as "messageComRessource" "SaStep" Access to a callable method or a server service with a declaration within a subprogram implementation or a thread Server subprogram "entryPoint" stereotype dependency between "SwSchedulable Resource" and called UML Operation NA AADL concept MARTE/UML concept for design MARTE/UML concept for analysis AADL definition Execution platform components Processor hwProcessor stereotype on UML Classifier NA Hardware unit responsible for scheduling and executing threads. Memory hwMemory stereotype on UML Classifier NA Abstract representation which is a storage component for data and executable code Bus HwBus stereotype on UML Classifier NA Hardware unit that enable communication among other execution platform components Device hwDevice stereotype on UML Classifier NA Represents entities that interfaces with the external environment of an application system AADL concept MARTE/UML concept for design MARTE/UML concept for analysis AADL definition System composition System UML systemModel stereotype NA Represents a composite software, execution platform or system components AADL concept MARTE/UML concept for design MARTE/UML concept for analysis AADL definition Features and shared access Port flowPort or msgPort stereotyped UML Port NA Represents a communication interface for the directional exchange of data, event or both between components PortGroup Composite interface stereotyped by both FlowSpecification and BfeatureSpecification stereotypes typing ports stereotyped by MsgPort and FlowPort NA Represents a collection of port group or port Inverse of IsConjugated stereotyped attribute on "FlowPort" and "Msg Port" UML ports Subprogram as Features UML Operation NA Represents sequentially executable source text Subprogram Parameters UML Parameters NA Represents the subprogram parameters SubComponent Access Data or Bus access via specific UML interfaces NA Explicit data or bus access AADL concept MARTE/UML concept for design MARTE/UML concept for analysis AADL definition Connections and flows Port Connections UML delegation connectors between Ports and Parts on composite diagrams NA A connection declaration binds a port from a component to another Parameter Connections ObjectFlow on UML activity diagram NA Used when a subprogram output need to be link with an entry point of an other subprogram Access Connections UML connections between UML ports requiring specific data access to data interface NA Access connections designate access to shared data components Flows specifications UML Object Flow between UML Object Pins in an Activity Diagram NA Specifies the detailed description and analysis of an abstract information path throughout a system End-To-End Flows NA MARTE "End2EndFlow" represented in activity diagram to ensure hierarchical flow path representations Specifies a flow that starts within one subcomponent and ends within another. AADL concept MARTE/UML concept for design MARTE/UML concept for analysis AADL definition Properties AAD property set MARTE stereotypes and associated attributes and user defined Nfp pstereotyped attributes. MARTE stereotypes and associated attributes and user defined Nfp stereotyped attributes. AADL concept MARTE/UML concept for design MARTE/UML concept for analysis AADL definition Operational modes Mode Mode as UML StateMachines; mode specific port connections are described with UML Collaborations. NA Represents a defined configuration of contained components, and connections AADL concept MARTE/UML concept for design MARTE/UML concept for analysis AADL definition Operational system System Binding MARTE allocation stereotyped UML Dependency, with attribute "nature" set to "SpatialDistribution" NA Binds software components to appropriate execution platform components (i.e. hardware components) AADL concept MARTE/UML concept for design MARTE/UML concept for analysis AADL definition Component relationship Component extension UML Generalization NA Component implementation UML Realization NA
Actions taken:
December 21, 2007: received issue
February 17, 2010: closed issue

Discussion:

see ptc/2008-06-05 for revised text

Issue 11849: Section: Annex A: AADL-like models with MARTE -- issue 2 (marte-ftf)

Click here for this issue's archive.
Source: THALES (Dr. Madeleine Faugere, madeleine.faugere(at)thalesgroup.com)
Nature: Enhancement
Severity: Significant
Summary:

The use of UML native concepts for some of the AADL constructs should be revised from a pragmatic viewpoint. For instance: a) The use of pure state machines to model AADL operational modes is sometimes insufficient. In the examples provided in MARTE (p.376; ptc/07-08-04), the relationship between a system configuration (modelled by a Collaboration) and a State specifying a Mode, is reflected by the �Name�. I.e., there is no an explicit association between both. It seems that providing a �Mode� stereotype in MARTE, with an appropriate relationship with other modelling elements could be very useful. This would facilitate model extraction/transformation when different kinds of state machines exist in a UML model. The relation between The AADL concepts of �mode transition� and �mode transition trigger� and UML state machines elements should be clarified. b) AADL Flows and EndToEndFlows are modelled by UML Activity diagrams. However, there is already the EndToEndFlow concept in MARTE (SAM chapter), which encloses the same semantics, and furthermore, provides a set of attributes (stereotype properties) that match with the AADL ones (e.g., end-to-end deadline, end to end time). The use of MARTE EndToEndFlows should be evaluated

Resolution: see ptc/2009-05-12 pages 89 - 94
Revised Text:
Actions taken:
December 21, 2007: received issue
October 16, 2009: closed issue

Discussion:

For AADL Modes, alignment on 12797 resolution: �Mode�, �Mode transition�,  �ModeBehavior� and �Configuration� will be used and illustrate on examples.  Flows and end-to-end flow have been resolved in issue 11854.

Issue 11850: MARTE-AADL Issue 3 (marte-ftf)

Click here for this issue's archive.
Source: THALES (Dr. Madeleine Faugere, madeleine.faugere(at)thalesgroup.com)
Nature: Enhancement
Severity: Significant
Summary:

[MARTE-AADL Issue 3] The set of new stereotypes provided in the AADL annex of MARTE (e.g., port group, subprogram, data type) seems to show that MARTE (and UML) does not support some AADL concepts. However: a) AADL Subprogram clearly maps to an UML Operation. More refined Operations can be modelled by �Requested Service� (GQAM chapter, p.263). b) AADL Data concept clearly maps to MARTE MutualExclusionResource (GRM chapter) or SharedResource (SAM chapter). The latter includes additional stereotype attributes useful for schedulability analysis. It may be a combination of both. This brings up the question of what the overlap and difference is between MutualExclusionResource and SharedResource. One represents the mechanism to achieve mutual exclusion, while the second is the entity that may require mutual exclusion in the context of concurrent access.

Resolution: Summary table, most component and associated features representation and property table have been upgraded and aligned: a) on MARTE issues for ports, b) data representation, c) data and bus access representations, d) new reference on flow and mode sections. Non MARTE stereotypes have been removed.
Revised Text: see ptc/2009-05-12 pages 95 - 117
Actions taken:
December 21, 2007: received issue
October 16, 2009: closed issue

Discussion:

Discussion:  In order to keep the guidance role of the annex A, and the in there defined stereotypes shall be removed.  UML/MARTE construct have been proposed in issue #11848 to express AADL data, AADL System, AADL end-to-end flows, inverse concept, AADL Port Group, Server subprogram, AADL subprogram, Thread group.      Delayed (sampled, immediate) communication types are missing in MARTE.     Disposition:	Deferred

Issue 11851: MARTE-AADL Issue 4 (marte-ftf)

Click here for this issue's archive.
Source: THALES (Dr. Madeleine Faugere, madeleine.faugere(at)thalesgroup.com)
Nature: Enhancement
Severity: Significant
Summary:

MARTE is a profile with multiple abstraction levels. For instance, the concept of �Schedulable Resource� appears in the GRM as a high-level abstraction concept (SchedulableResource stereotype), in SRM as an RTOS API specific concept (swSchedulableResource stereotype). Also, some concepts used in GRM are refined with new attributes in the analysis chapters. The choice of MARTE stereotypes to model AADL concepts should be formalized with a set of rules, specifyingwhen to use GRM, SRM, GQAM, SAM stereotypes. This is not an easy task! This also depends on the required AADL Properties to attach in models. Managing the set of properties is indeed not easy. In AADL we have the property set mechanism through which we can introduce new properties that can be associated with existing AADL concepts. As such they enhance the semantics of those concepts and may introduce new concepts. For example, at the SEI we have defined a set of security related properties and associated them with components (system, process, thread, �), ports, and connections. In doing so we represent security related concepts of subjects, object, roles. To us these properties act as annotations to the base architecture model, and their mapping into a analysis-specific model (meta model for security models) understands the mapping of core AADL concepts into analysis-domain concepts. In some cases the existing core architecture concepts are not sufficient; then new concepts can be introduced through the annex mechanism. For example, the error model annex allows users to introduce additional concepts such as �error events� (faults), which exist as separate entities and are associated with core AADL entities. They themselves can have properties as defined through property sets. MARTE, by doing the same in the context of a meta model, e.g., through GQAM, SAM etc., have an explicit way of identifying these analysis specific concepts by name. At the same time when I have an architecture model and want to associate specific analysis interests, I would have to identify the collection of stereo types, some representing the base architecture model, and some the analysis specific abstractions and annotations to bee attached. When I look at the predeclared properties in the AADL standard, they deal with more than one analysis area. We are attempting to subcategorize them. If you have good insight on how to do some of this better, we are looking for input on doing this better on the AADL side as well.

Resolution: See issue 11850 for disposition
Revised Text:
Actions taken:
December 21, 2007: received issue
October 16, 2009: closed issue

Discussion:

Discussion:  MARTE proposes different views (design, SW/HW platform modeling, and analysis views), enhancing different model and analysis scenarios reuse. AADL is based on a more synthetic process, fixing architectural choices. The end user focus on data/event communication between component.  The best MARTE process and the use of modeling, sw/hw platform, and analysis views shall be study in more details to "better" match the AADL way of thinking.  Disposition:	Deferred

Issue 11852: MARTE-AADL Issue 5 (marte-ftf)

Click here for this issue's archive.
Source: THALES (Dr. Madeleine Faugere, madeleine.faugere(at)thalesgroup.com)
Nature: Enhancement
Severity: Significant
Summary:

The representation of AADL properties with UML Notes, does not provide the AADL capabilities of the Properties language. Annotations in notes are not formal, as users use a free-text zone without any constraints for the annotated elements, and syntax checking. Furthermore, most of the AADL Properties defined in the Predeclared Property Set annex (AADL spec.) are already existing in MARTE stereotype attributes. The more appropriate way is to use these attributes to model AADL properties. However, additional problems rise from this approach: a) Not all the AADL properties exist in MARTE. b) Some enumeration types existing in MARTE do not contain the options supported by AADL. c) Stereotype attributes are not always annotated in the same model elements (according to the mapping MARTE-AADL at the conceptual level). This aspect can be solved in at least two ways: 1) We add the required stereotype attributes in the MARTE spec. 2) New stereotypes are created in this annex only to support AADL. While the first option could not be in the scope of MARTE (we cannot align MARTE to all other language in the domain!), the second one requires to follow a set of formal rules to create the new stereotypes (naming, extended UML metaclasses, etc.) A third option is to create stereotypes for all the AADL concepts, but inheriting from MARTE concepts. An optimal solution should be evaluated with regard to criteria such as: tool reusability, automation of model transformations, timelines, etc. The third option goes along with the question of having an explicit profile for AADL, with AADL stereo type (or at least AADL profile label for MARTE stereo types that are identical to AADL). Do we need to introduce a new stereo type just because we have to add some properties to a MARTE stereo type? AADL allows users to introduce new properties through property sets. In MARTE terminology, users can introduce new stereo types that carry properties specific to an analysis framework. Those we need to be able to associate with the base concepts of describing an embedded architecture (what we call core language). What would be a good approach and guidance for doing so? In that sense there are two issues: 1) describe what mechanisms are available to allow users to extend the base modelling language of AADL/MARTE � in essence meta modelling capabilities). In AADL we have an explicit textual representation in addition to extending the meta model of AADL, while in MARTE it is solely done through meta modelling. 2) capture specific sets of standardized (and not yet standardized sets of properties).

Resolution: According to the implicit MARTE modeling process where modeling and analysis features are modeled by distinct features in separate diagrams, most (80%) of the AADL pre declared properties found their equivalent in MARTE. The complementary part will be explicitly modeled by the end user using the "Nfp" concept. The following table presents the mapping between the AADL pre-declared property set and their equivalent in MARTE.
Revised Text: To be added after the "Component and associated features representation" table concerning the Data component section 3.3.4. AADL data component properties AADL properties Marte Design Marte SW/HW platform Marte Analysis Shared data aspect MutualExclusionRe-source stereotype swMutualExclusionResource stereotype swMutualExclusionResource stereotype Concurrency_Control_Pro-tocol: enumeration NA concurrentAccessProtocol stereotype attribute Priority_Inheritance "PIP" enumeration literal of "ConcurrentAccessProtocol-Kind" enumerate Interrupt_Masking New issue raised Priority_Ceiling "PCP" enumeration literal of "ConcurrentAccessProtocol-Kind" enumerate Maximum_Priority New issue raised Data access via interface Resource, ConcurrencyResource, ProcessingResource of GRM depending on the user's precision requirements Associated SRM equivalent concepts i.e. swConcurrencyResource, etc To be added after the "Component and associated features representation" table concerning the Subprogram component section 3.3.5. AADL subprogram component AADL properties Marte Design Marte Analysis Compute_execution_time: Time_range NA NA "ExecTime: NFPDuration[*]" attribute on SaStep or SaCommStep stereotype Compute_Deadline "Deadline: NFPDuration[]" attribute on SaStep or SaCommStep stereotype Queued_Processing_Protocol enumaration "MessageQueuePolicyKind" attribute FIFO "FIFO" enumeration literal from "QueuePolicyKind" enumerate Other "Other" enumeration literal from "QueuePolicyKind" enumerate To be added after the "Component and associated features representation" table concerning the Thread component section 3.3.2. AADL Thread component AADL properties Marte Design Marte SW/HW platform Marte Analysis Dispatch protocol: enumeration NA NA Specified at the WorkloadEvent concept triggering the SaScenario Periodic "PeriodicPattern" enumeration literal selected for "Pattern" attribute for the WorkloadEvent stereotype Sporadic "SporadicPattern" enumeration literal selected for "Pattern" attribute for the WorkloadEvent stereotype. Aperiodic "AperiodicPattern" enumeration literal selected for "Pattern" attribute for the WorkloadEvent stereotype Background New issue raised Period: Time "Period" attribute from the "PeriodicPattern" attribute specified by the WorkloadEvent stereotype Deadline: Time (inherited from period) At this level, the same as "Period" attribute defined above Compute_execution_time Computed from the different "Steps" concepts supported by the thread; shall be defined in scenarios Compute_deadline Computed from the different "SaSteps" supported by the thread; shall be defined in scenarios Initialize_execution_Time and Initialize_deadline Specific "execTime" and "deadline" attributes from SaStep stereotype corresponding on mode switch operations defined in the SwPlatform model Active_execution_time (specific for mode switch) and Active_deadline (specific for mode switch) Specific "execTime" and "deadline" attributes from SaStep stereotype corresponding on mode switch operations defined in the Swplatform model Deactive_execution_time (specific for mode switch) and Desactive_deadline (specific for mode switch) Specific "execTime" and "deadline" attributes from SaStep stereotype corresponding on mode switch operations defined in the Swplatform model Recover_execution_time (specific for mode fault handling) and Recover_deadline (specific for mode fault handling) Specific "execTime" and "deadline" attributes from SaStep stereotype corresponding on mode switch operations defined in the Swplatform model Finalize_execution_time and Finalize_deadline Specific "execTime" and "deadline" attributes from SaStep stereotype corresponding on mode switch operations defined in the Swplatform model Synchronized_component Nfp stereotyped attribute defined by the end-user Active_thread_handling_proto-col (specific to mode switch): ex abort, complete_one_flush_queue, complete_one_transfer_queue,complete_one_preserve_queue, complete_all Nfp stereotyped attribute with associated end-user defined enumeration To be added after the "Component and associated features representation" table concerning the Process component section 3.3.1. AADL Process component AADL properties Marte Design Marte SW/HW platform Marte Analysis Scheduling_protocol NA NA Specified by the "schedPolicy" attribute of Scheduler stereotype Ex: EDF, RMS, SporadicServer, SlackServer, ARINC653 Scheduler and SchedulableResource stereotypes modeling with associated scheduling policy kinds, and scheduling parameters. load_time and load_deadline Specific "execTime" and "deadline" attributes from SaStep stereotype corresponding to operations defined in the Swplatform model Period and deadline are specified for inheritance Period and deadlines are specified at the thread level on WorkloadEvent and SaSteps. ----------------------------------------------------------------------------------------------------------- To be added after the "Component and associated features representation" table concerning the Processor component section 3.4.1. AADL Processor component AADL properties Marte Design Marte SW/HW platform Marte Anaysis Thread_limit AssociationEnd cardinality between " Scheduler" and "swSchedulingResources" concepts modelized in the sw Platform Assign_time: Time Nfp stereotyped attribute defined by the end-user Assign_byte_Time: Time Nfp stereotyped attribute defined by the end-user Assign_fixed_Time: Time Nfp stereotyped attribute defined by the end-user Clock_Jitter Nfp stereotyped attribute defined by the end-user Clock_period Nfp stereotyped attribute defined by the end-user Clock_Period_Range "Op_frequencies" attribute from HwProcessor stereotype ----------------------------------------------------------------------------------------------------------- To be added after the "Component and associated features representation" table concerning the Memory component section 3.4.2. AADL Memory component AADL properties Marte Design Marte SW/HW platform Marte Analysis MemoryProtocol (R,W,RW) "MemoryBroker" concept allocated on "HwMemory" "AccessPolicy" attribute from "MemoryBroker" stereotype Read_Time:Time[] "ExecTime: NFPDuration[*]" attribute on SaStep or SaCommStep stereotype Write_Time:Time[] "ExecTime: NFPDuration[*]" attribute on SaStep or SaCommStep stereotype ----------------------------------------------------------------------------------------------------------- To be added after the "Component and associated features representation" table concerning the Bus component section 3.4.3. AADL Bus component AADL properties Marte Design Marte SW/HW platform Marte Analysis Propagation_delay Nfp stereotyped attribute defined by the end-user Transmission_Time "ExecTime: NFPDuration[*]" attribute on SaStep or SaCommStep stereotype Allowed_Message_Size "MessageSizeElements" attribute on MessageComResource stereotype ----------------------------------------------------------------------------------------------------------- To be added after the "Component and associated features representation" table concerning the Port component section 3.6.1. AADL Port component AADL properties Marte Design Marte SW/HW platform Marte Analysis Compute_execution_time Time and Deadline are either specified in the associated communication media or component Compute_Deadline Queue_size "MessageQueueCapacityElements" attribute on MessageComResource stereotype Queue_Processing_proto-col "Mechanism" attribute on MessageComResource stereotype available values are "MessageQueue, Pipe, BlackBoard, undef, other) Overflow_handling_proto-col Nfp stereotyped attribute defined by the end-user, typed bt end-user defined enumeration Dequeued_protocol Nfp stereotyped attribute defined by the end-user, typed bt end-user defined enumeration To be added after the "Component and associated features representation" table concerning the Flow component section 3.8. AADL Flow component AADL properties Marte Design Marte SW/HW platform Marte Analysis Latency See end-to-end flow latency Throughput See end-to-end flow throughput To be added after the "Component and associated features representation" table concerning the Flow component section 3.8. AADL End_to_end Flow component AADL properties Marte Design Marte SW/HW platform Marte Analysis Expected_Latency "End2EndD: NFPDuration[*]" attribute on SaEnd2EndFlow stereotype with qualifier attribute "SourceKind" set to "req" Actual_Latency "End2EndT: NFPDuration[*] "attribute on "SaEnd2EndFlow" with qualifier attribute "SourceKind" set to "est" Expected_Throughput "Throughput: NFP_Frequency[*]" attribute on "Sa/GaScenario" with qualifier attribute "Sourcekind" set to "req" Actual_Throughput "Throughput: NFP_Frequency[*]" attribute on "Sa/GaScenario" with qualifier attribute "Sourcekind" set to "est"
Actions taken:
December 21, 2007: received issue
February 17, 2010: closed issue

Discussion:

see ptc/2008-06-05 for revised text

Issue 11853: MARTE-AADL Issue 6 (marte-ftf)

Click here for this issue's archive.
Source: THALES (Dr. Madeleine Faugere, madeleine.faugere(at)thalesgroup.com)
Nature: Enhancement
Severity: Significant
Summary:

MARTE provides a language for expressions (VSL), including mathematical, logical, and time expressions. AADL also provides the ability to specify expressions. A detailed mapping should be provided in order to transform VSL expressions into AADL expressions. AADL is more limited in terms of expressions. We tried to not grow the property expressions into a full constraint language but offer the constraint language through the annex mechanism (construct). In this case we may define an AADL annex that covers the constraint expression capabilities of VSL in MARTE. Also in MARTE properties carry meta information about the property values as attributes. At this time in AADL we do not support a general attribute mechanism on properties (properties on properties � although it turns out the meta model of AADL has that in). Here we need to make some decisions on the AADL side. Input on what we should do better on the AADL side is welcome

Resolution: AADL expression language and VSL language are not based on the same construction mechanism. These language alignments implies de definition of new features on the AADL side, action is not a priority at the moment in the AADL communauty. Disposition: Closed, no change
Revised Text:
Actions taken:
December 21, 2007: received issue
October 16, 2009: closed issue

Discussion:

Discussion:  A detailed mapping should be provided in order to transform VSL expressions into AADL expressions.   Disposition:	Deferred

Issue 11854: MARTE-AADL Issue 7 (marte-ftf)

Click here for this issue's archive.
Source: INRIA (Dr. Frederic Mallet, Frederic.Mallet(at)inria.fr)
Nature: Enhancement
Severity: Significant
Summary:

Examples provided in the AADL annex of MARTE should be enriched: a) An example on how to model the AADL dispatch protocol with MARTE is missing. b) An example on how to model AADL flows with MARTE is missing c) An example on how to model AADL event-data port with queues and data ports without queues with MARTE is missing. If we go with doing a �real� profile for AADL, then we should probably have two part to that annex, one is the specification of the stereo types making up the AADL concepts (incl. their AADL labels and graphical symbol representation in addition to the UML-based box representation), the second a modelling guide to illustrate the use (like the examples mentioned above). We (the SEI) could work with you on additional examples to show.

Resolution: a) An example on how to model the AADL dispatch protocol with MARTE is missing. Two ways of representing dispatch protocol are possible, depending on the abstraction layer and end-user choice. A first representation allows mixing application elements and resources by attaching a Dispatch protocol attribute and applying the stereotype "SwSchedulableResource". For instance, a new property (named "dispatch_type") and stereotyped "rtf" can be created in the user model view. This dispatch property covers the different AADL dispatch protocols: periodic, sporadic, aperiodic, timed, hybrid, background. A second representation is to define a model library for AADL threads. One class can be defined for each dispatch protocol and the classes are used to type parts of a structured classifier. Subprograms can then be represented as actions within an Activity and are allocated to the parts of the structured classifier, which represent the software execution platform. b) An example on how to model AADL flows with MARTE is missing Flow path in component declaration and implementation have been modified. A Flow specification declaration indicates that information logically flows from one of the incoming ports, parameters, or port groups of a component to one of its outgoing ports, parameters, or port group flows. Component implementations must provide a flow implementation for each flow specification. A flow implementation declaration identifies the flow through its subcomponents. Flow sinks and flow sources are implicit, and deduced from flow path implementations. Flow path on parameters will not be processed in this version. Flow specifications are represented by "UML InformationFlows", which represents an abstraction of the communication of an information item from its sources to its targets. End to end flows are represented by interactions or activities. c) An example on how to model AADL event-data port with queues and data ports without queues with MARTE is missing Resolved in issue 11850, with data, event and data-event port semantic clarification and in end-to-end flow definition (activity diagram representation)
Revised Text: see ptc/2009-05-12 pages 121 - 127
Actions taken:
December 21, 2007: received issue
October 16, 2009: closed issue

Discussion:

Discussion:  More discussion need  Disposition:	Deferred

Issue 11855: MARTE-AADL Issue 8 (marte-ftf)

Click here for this issue's archive.
Source: INRIA (Dr. Frederic Mallet, Frederic.Mallet(at)inria.fr)
Nature: Enhancement
Severity: Significant
Summary:

Modeling the AADL dequeue protocol AllItems seems impossible with UML (and therefore MARTE) because the selection of a behavior on an object node in UML takes only one token at once making it impossible to dequeue/read all the tokens from a queue. The OneItem, AllItems and in V2 also MultipleItems values try to abstractly specify three types of queue processing. It defines what happens to the queue content in terms of making it available to the application and having removed from system buffers. OneItem indicates that one element is removed from the system queue of the port. AllItems means all are removed. MultipleItems means that a detailed behaviour model describes (via the NextValue method how (many) are removed from the system queue.

Resolution: Disposition: See issue 11854 for disposition
Revised Text:
Actions taken:
December 21, 2007: received issue
October 16, 2009: closed issue

Discussion:

Discussion:  This resolution needs MARTE concepts evolutions.   Disposition:	Deferred

Issue 11857: Explain 'business management perspective" (marte-ftf)

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

I would suggest explaining what is the "business management perspective".

Resolution: Strike the phrase "Business Management Perspective" Change it by "system perspective"
Revised Text:
Actions taken:
December 21, 2007: received issue
February 17, 2010: closed issue

Issue 11858: Table 2.1 (marte-ftf)

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

In Table 2.1, I would suggest sorting the extensions units according to the table of content of this document.

Resolution: Agree on the suggestion, see proposed resolution
Revised Text: Let's note that the following resolution take into account the renaming resolution as described in the resolution sheet for issue 11859. In the table 2.1, replace the first column as follow: NFP Time GRM (let's notice that GRM should refer section 10 in the 3rd column of the table) GCM Alloc RTEMoCC SRM HRM GQAM SAM PAM VSL CHF RSM
Actions taken:
December 21, 2007: received issue
February 17, 2010: closed issue

Issue 11859: Table 2.1, I would suggest using the profile names (marte-ftf)

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

In Table 2.1, I would suggest using the profile names (e.g. Alloc)in the acronym column instead of defining new ones (e.g. ALM). That would may facilitate reading the document.

Resolution: Agree on the suggestion, see proposed resolution
Revised Text: In Table 2.1 (on page 2) and Table 7.2 (on page 4 and 5), replace: - "ETM" by "Time" - "ECM" by "GCM" - "ALM" by "Alloc" - "RTM" by "RTEMoCC" - "GAM" by "GQAM" Update also section 2.4.2, replace " o Software Modeling o Base: RTM, GRM, NFP, ETM o Full: SRM, ECM, ALM, VSL, CHF o Hardware Modeling o Base: HRM, GRM, NFP, ETM o Full: ECM, ALM, VSL, CHF, RSM o System Architecting o Base: RTM, HRM, GRM, NFP, ETM o Full: SRM, ECM, ALM, VSL, CHF, RSM o Performance Analysis o Base: PAM, GAM, GRM, NFP, ETM o Full: VSL, CHF o Schedulability Analysis o Base: SAM, GAM, GRM, NFP, ETM o Full: VSL, CHF o Infrastructure Providing o Base: SRM, GRM, ETM, NFP, o Full: RTM, VSL, ALM, CHF o Methodologist o Base: : RTM, HRM, GRM, NFP, ETM, GAM o Full: MARTE (ECM, ALM, SRM, PAM, SAM, VSL, CHF, RSM) " By " o Software Modeling o Base: RTEMoCC, GRM, NFP, Time o Full: SRM, ECM, Alloc, VSL, CHF o Hardware Modeling o Base: HRM, GRM, NFP, Time o Full: ECM, Alloc, VSL, CHF, RSM o System Architecting o Base: RTEMoCC, HRM, GRM, NFP, Time o Full: SRM, ECM, Alloc, VSL, CHF, RSM o Performance Analysis o Base: PAM, GQAM, GRM, NFP, Time o Full: VSL, CHF o Schedulability Analysis o Base: SAM, GQAM, GRM, NFP, Time o Full: VSL, CHF o Infrastructure Providing o Base: SRM, GRM, Time, NFP, o Full: RTEMoCC, VSL, Alloc, CHF o Methodologist o Base: RTEMoCC, HRM, GRM, NFP, Time, GQAM o Full: MARTE (ECM, Alloc, SRM, PAM, SAM, VSL, CHF, RSM)
Actions taken:
December 21, 2007: received issue
February 17, 2010: closed issue

Issue 11860: In section 2.4.2, the list of extension units and table 7.2 are redundant (marte-ftf)

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

In section 2.4.2, the list of extension units and the table 7.2 are redundant. I would suggest removing the list of extension units

Resolution: I agree on the redundancy, but I propose to keep the table instead of the text.
Revised Text: In section2.4.2, replace the text: " The Extension Units that must be supported in each Compliance Cases are assigned in the following way: o Software Modeling o Base: RTM, GRM, NFP, ETM o Full: SRM, ECM, ALM, VSL, CHF o Hardware Modeling o Base: HRM, GRM, NFP, ETM o Full: ECM, ALM, VSL, CHF, RSM o System Architecting o Base: RTM, HRM, GRM, NFP, ETM o Full: SRM, ECM, ALM, VSL, CHF, RSM o Performance Analysis o Base: PAM, GAM, GRM, NFP, ETM o Full: VSL, CHF o Schedulability Analysis o Base: SAM, GAM, GRM, NFP, ETM o Full: VSL, CHF o Infrastructure Providing o Base: SRM, GRM, ETM, NFP, o Full: RTM, VSL, ALM, CHF o Methodologist o Base: : RTM, HRM, GRM, NFP, ETM, GAM o Full: MARTE (ECM, ALM, SRM, PAM, SAM, VSL, CHF, RSM) This is summarized in the table below. " By "The Extension Units that must be supported in each Compliance Cases are assigned as depicted in the following table."
Actions taken:
December 21, 2007: received issue
February 17, 2010: closed issue

Issue 11861: Explanation in section 7.3 hard to read (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Clarification
Severity: Significant
Summary:

Section 7.3 is very important to understand how to use of MARTE stereotypes in the following chapter. However, the explanation given here is hard to read. I would suggest rephrasing this specific paragraph.

Resolution: Rephrase the paragraph conveniently.
Revised Text: Replace the paragraph: As stated before, this chapter does not define concrete extensions to UML, but it collects a number of primitive modeling concepts to be use in the domain models of other chapters in this specification. Nevertheless all further concepts defined in this specification may adopt the nature of Classifier or Instance presented here, and this is made according to: their definition, the purpose of the annotation, and the intended semantics. In many cases these concepts are represented in UML by a stereotype annotation on a concrete UML modeling element. When this is the case, the Classifier or Instance intrinsic nature of the UML annotated element may define the corresponding nature, semantics, or concrete variations of the MARTE concept that is intended to be represented with the annotation. As a consequence, explicit different semantics may be defined for each MARTE modeling concept whether it is annotated on an instance or on a classifier; the differentiation is then straightforward, since it is dependent directly on the fundamental nature of the corresponding UML element that is annotated. By: As stated before, this chapter does not define concrete extensions to UML offered as stereotypes to the user. Instead it collects a number of primitive modeling concepts to be use in the domain models of other chapters in this specification. Nevertheless, a certain impact on the representation of modeling elements is envisioned according to their classifier/instance dual nature. The modeling elements defined in this specification may adopt the nature of Classifier or Instance presented here, or both. This quality of being may be of course specifically stated as part of their definition, but it may be also left to the user to be decided according to the purpose of the annotation, and the intended semantics. In most of the cases the concepts defined in the domain view are proposed to be represented in UML by means of a stereotype extending a concrete UML modeling element. When this is the case, the Classifier or Instance intrinsic nature of the UML annotated element may lead to identify the corresponding nature, semantics, or concrete variations of the MARTE concept that is intended to be represented with the annotation. Hence, the explicit different semantics that may be defined for each MARTE modeling concept, when it is considered as an instance or as a classifier, may be inferred directly from the fundamental nature of the corresponding UML element that is annotated.
Actions taken:
December 21, 2007: received issue
February 17, 2010: closed issue

Issue 11862: Add short rationale in section 10.3 (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Enhancement
Severity: Significant
Summary:

In introduction of section 10.3, a short rationale should be given to explain which meta-classes are extended (in relation with section 7.3 on classifiers and instances).

Resolution: Add a paragraph after the one in the introduction of section 10.3 explaining the application of the rule in section 7.3 to the extended metaclasses.
Revised Text: (5) Add the following paragraph in the introduction of section 10.3, just after the one in there. "In order to get the maximum flexibility in the ways of applying the proposed stereotypes, most of the UML elements extended, are extended by the generic stereotype Resource. Then, through inheritance the large majority of stereotypes in GRM may extend elements like Property, InstanceSpecification, Classifier, Lifeline, and ConnectableElement. In particular, they might be applied for example to Classifiers, as well as to InstanceSpecifications of those very same Classifiers. In this case it is worth to consider the rules describe in section 7.3 for the usage of a stereotype in such situation. According to this rule when a stereotype is applied on an instance, the value of the attributes not explicitly assigned in the annotation of the instance are taken in principle from the defaults in the profile stereotype definition, but they might have to be taken from the annotation of the same stereotype on its corresponding classifier, which may have overwrote them, making effective with it the classifier nature of the annotation."
Actions taken:
December 21, 2007: received issue
February 17, 2010: closed issue

Issue 11863: concept of refinement (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

Does the concept of refinement only apply to clock refinement. My first impression is that this concepts may apply to other NFPs. In any case, this needs to be clarified

Resolution: There is agreement to extend the Refinement to any kind of NFP constraints. Issue 11864 required to use the same name in the domain model and in the UML representation so we chose NFPRefine for the name. The resolution replaces every occurrence of ClockRefine by NFPRefine. It also replaces the association to Time::ClockConstraint by an association to NFPs::NfpConstraint. In the domain model, the metaclass Refinement is associated to NFP_Constraint instead of ClockConstraint. The second constraint is removed since it was assuming all constraints were ClockConstraint.
Revised Text: In section 12.2, page 138, change figure 12.2, into: In section 12.2, page 137, change text: Figure 12.1 shows a general view of allocation, while Figure 12.2 shows the refinement relations. Allocations are annotated with NfpConstraints as built from the NFP section of this document and refinement are more precisely annotated with ClockConstraints as defined in the Time Model section (chapter 9). Allocations provide links between independent models, while refinement/abstraction works by changing the focus on an underlying similar structure. Into: Figure 12.1 shows a general view of allocation, while Figure 12.2 shows the refinement relations. Both the Allocations and the refinement are annotated with NFP_Constraints as built from the NFP section. Time constraints can also be associated since the metaclass NFP_Constraints is a generalization of the metaclass ClockConstraint defined in the Time Model section (chapter 9). Allocations provide links between independent models, while refinement/abstraction works by changing the focus on an underlying similar structure. In section 12.2, page 138, change text: Time::ClockConstraint specializes NFP_Annotations::NfpConstraint, using such constraints provides time links between the clients and the suppliers. Into: The refinement process generally involves the definition of additional constraints to precise links between the general element and the refined ones. For instance, one may want to specify how the time bases relates, how the bandwidth (or power consumption �) is spread amongst refined elements. The association with some NFPs::NFP_Annotations::NfpConstraint is a provision for defining such links. In section 12.3.1, page 140, change figure 12.6, into: In section 12.3.1, page 140, change text: Concerning the refinement we also think it is important to emphasize the fact that the refinement process implies some additional constraints that mostly concern clocks as defined in the Time Model package. into: Concerning the refinement we also think it is important to emphasize the fact that the refinement process implies some additional constraints. It could be ClockConstraints to relate clocks at the different abstraction level or any other NfpConstraint. Replace section 12.3.2.7 by: 12.3.2.7 NfpRefine (from Alloc) The stereotype NfpRefine maps the domain element Refinement (section F.6.5) denoted in Annex F. NfpRefine is a dependency based on UML::Dependency. It is a mechanism for associating one abstract model element to refined model elements. It is a provision for grouping elements. The refinement process implies some additional constraints between the abstract element and the refined elements. When several application model elements are to be collectively allocated to execution platform elements they should first be grouped using the dependency NfpRefine. Some NfpConstraints, like for instance ClockConstraint, should be associated with this dependency to specify relations between the general element and the refined ones. Extensions o Dependency (from Dependencies). Associations o constraints: NFPs::NfpConstraint [*] The set of constraints implied by the refinement. Constraints [1] A single dependency NfpRefine shall have only one client (from), but may have one or many suppliers (to). context NfpRefine inv: base_Dependency.from->size()=1 and base_Dependency.to->size()>=1 Notation The relationship NfpRefine is a dashed line with an open arrow head. The arrow points in the direction of the refinement. In other words, the directed line points "from" the element being refined "to" the elements that are the refined elements. In section F.6.5 subsection Associations, page 544, insert the following association at the end of the list: o constraints: NFPs::NFP_Annotation::NFP_Constraint [*] The set of constraints implied by the refinement.
Actions taken:
December 21, 2007: received issue
February 17, 2010: closed issue

Discussion:

see ptc/2008-06-05 for revised text (graphics)

Issue 11864: Names should be identical (marte-ftf)

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

The Refinement metaclass relates to the ClockRefinement stereotype. Names should be identical.

Resolution:
Revised Text:
Actions taken:
December 21, 2007: received issue
February 17, 2010: closed issue

Discussion:

Discussion:  The domain model is supposed to be a description of the concepts required, whereas the UML representation takes into account the existing UML elements.  For the explanation in the domain model part, it would be odd (or even incorrect) to mention ''NfpRefinement'' or ''ClockRefinement'' and even more strange to refer to ''NfpRefine'' because we really speak about the refinement mechanism as being the inverse operation of the abstraction mechanism.   Unfortunately, in the UML representation we can have name conflicts with existing UML model elements. The name ''ClockRefine'' (and not ''ClockRefinement'') has been chosen to recall the stereotype ''Refine'' of the UML standard profile. It is not possible to call it ''refine'' since this is already a keyword of UML. Calling it "refinement", which would be the right naming, may lead to many confusions with "refine".  In that particular case, it is really a matter of adding a new constraint to the existing UML stereotype (only one source, multiple targets) and offering a provision for associations with NFP constraints.  Disposition:	Closed, no change

Issue 11865: RtAction.isAtomic (marte-ftf)

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

The meaning of the RtAction.isAtomic should be precisely state. In chapter 13, isAtomic is used in other contexts (e.g. flow ports) with other semantics.

Resolution: Provide a precise, non-recursive definition: here, isAtomic means indivisible.
Revised Text: On page 548, Section F.7.8, replace Attributes o syncKind: SynchronizationKind [0..1] kind of synchronization used when an action is completed. o isAtomic: Boolean [1] = false indicates whether a real-time action is atomic. o msgSize: NFP_DataSize [0..1] size of a message generated when executing an action. Associations o pRTF: RealTimeFeature [0..1] real-time feature related to a RtAction. Semantics A real-time action can specify a real-time feature such as a deadline or a period. It can also describe the size of the message generated when executing the action, as well as the kind of synchronisation used when the action is completed. Finally, a real-time action may be atomic. With Attributes o syncKind: SynchronizationKind [0..1] kind of synchronization used when the Action executes. o isAtomic: Boolean [1] = false when true, implies that the Action executes as one indivisible unit, non-interleaved with other Actions. o msgSize: NFP_DataSize [0..1] size of a message generated when the Action executes. Associations o pRTF: RealTimeFeature [0..1] real-time feature related to the RtAction. Semantics An RtAction is an Action specialized with the additional aforementioned attributes of "real-time" constraints. On page 550, SectionF.7.12, replace A real-time service can specify real-time features such as a deadline or a period. It can also describe a concurrency policy, an execution policy as well as a synchronization policy. Finally, a real-time service may be atomic. Generalization o Service (from MARTE::GRM::ResourceCore) Attributes o concPolicy: ConcurrencyKind [1] concurrency policy used for the real-time service. o exeKind: ExcutionKind [1] execution policy used for the real-time service. o isAtomic: Boolean [1] = false indicates whether the service execution is considered as atomic. o syncKind: SynchronizationKind [1] synchronization policy used for the real-time service. Associations o pRTF: RealTimeFeature [0..1] real-time feature that can be attached to a real-time service. Semantics A real-time service can specify real-time features such as a deadline or a period (see details of the ArrivalPattern data type introduced in the MARTELib). It can also describe a concurrency policy, an execution policy as well as a synchronization policy. Finally, a real-time service may be atomic. These characteristics are applicable for all the invocations of the service With An RtService can specify the real-time features described by its attributes. Generalization o Service (from MARTE::GRM::ResourceCore) Attributes o concPolicy: ConcurrencyKind [1] concurrency policy used for the real-time service. o exeKind: ExcutionKind [1] execution policy used for the real-time service. o isAtomic: Boolean [1] = false when true, implies that the RtService executes as one indivisible unit, non-interleaved with other RtServices. o syncKind: SynchronizationKind [1] synchronization policy used for the real-time service. Associations o pRTF: RealTimeFeature [0..1] real-time feature that can be attached to a real-time service. Semantics An RtService is a Service specialized with the additional aforementioned attributes of "real-time" constraints. These attributes apply for all the invocations of the RtService. On page 160, Section 13.3.2.6, replace The RtAction stereotype maps the RtAction domain element (section F.7.8, p. 495) denoted in Annex F. Real-time invocation action can specify real-time features such as a deadline or period (see details of the ArrivalPattern data type introduced in the MARTELib). It can also describe the size of the message generated when executing or the kind of synchronization (synchKind attribute). Finally, a real-time action execution may be atomic. Extensions o InvocationAction (from UML::BasicBehaviors). o BehavioralFeature (from UML::Kernel). Attributes o synchKind: SynchronizationKind synchronization mechanism associated to the communication action. o isAtomic: Boolean [1] = false if true, the action execution is atomic. o msgSize: NFP_DataSize size of a message generated when executing an action. With The RtAction stereotype maps the RtAction domain element (section F.7.8, p. 495) denoted in Annex F. InvocationActions and BehavioralFeatures, stereotyped with RtAction, gain the additional following attributes of "real-time" constraints. Extensions o InvocationAction (from UML::BasicBehaviors). o BehavioralFeature (from UML::Kernel). Attributes o synchKind: SynchronizationKind synchronization mechanism associated to the communication action. o isAtomic: Boolean [1] = false when true, implies that the RtAction executes as one indivisible unit, non-interleaved with other RtActions. o msgSize: NFP_DataSize size of a message generated when executing an action. On page 162, Section 13.3.2.10, replace The RtService stereotype maps the RtService domain element (section F.7.12) denoted in Annex F. Real-time service can specify real-time features such as a deadline or period (see details of the ArrivalPattern data type introduced in the MARTE_Library::MARTE_DataTypes). It can also define a concurrency policy as well as an execution policy. Finally, a real-time action execution may be atomic. The RtService stereotype may be applied on one BehavioralFeature independently of the fact that the containing classifier to be either a RtUnit or a PpUnit. Extensions o BehavioralFeature (from UML::Kernel) Attributes o concPolicy: ConcurrencyKind [0..1] concurrency property of the service. o exeKind: ExecutionKind [0..1] execution nature property of the service. o isAtomic: Boolean [1] = false if true, the execution of the service is atomic. o synchKind: SynchronizationKind [0..1] synchronization mechanism of the service. With The RtService stereotype maps the RtService domain element (section F.7.12) denoted in Annex F. BehavioralFeatures, stereotyped with RtService, gain the additional following attributes of "real-time" constraints. The RtService stereotype may be applied on one BehavioralFeature independently of the fact that the containing classifier to be either a RtUnit or a PpUnit. Extensions o BehavioralFeature (from UML::Kernel) Attributes o concPolicy: ConcurrencyKind [0..1] concurrency property of the RtService. o exeKind: ExecutionKind [0..1] execution nature property of the service. o isAtomic: Boolean [1] = false when true, implies that the RtService executes as one indivisible unit, non-interleaved with other RtService. o synchKind: SynchronizationKind [0..1] synchronization mechanism of the RtService.
Actions taken:
December 21, 2007: received issue
February 17, 2010: closed issue

Issue 11866: improve the usability of the RtBehavior stereotype (marte-ftf)

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

To improve the usability of the RtBehavior stereotype, it should also extend the UML::Operation metaclass.

Resolution:
Revised Text:
Actions taken:
December 21, 2007: received issue
February 17, 2010: closed issue

Discussion:

Discussion:  A UML Operation is a BehavioralFeature, not a Behavior, and MARTE's RtService is the intended stereotype for BehavioralFeatures such as Operation.  A vote of Yes on this issue will leave RtBehavior unable to extend UML::Operation. A vote of No on this issue will only leave the issue Open.  Disposition:	Closed, no change

Issue 11867: For the sake of consistency, the rtf stereotype should be renamed (marte-ftf)

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 consistency, the rtf stereotype should be renamed as rtFeature.

Resolution: Rename "rtf" to be "rtFeature".
Revised Text: Replace ALL "rtf" with "rtFeature".
Actions taken:
December 21, 2007: received issue
February 17, 2010: closed issue

Issue 11868: suggest removing the notion of feature in the conformance section (marte-ftf)

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

I whould suggest removing the notion of feature in the conformance section. As this notion is not used in other places of the document

Resolution: Agree on the proposal.
Revised Text: In first paragraph of the section 2.2, replace "In order to properly identify the elements of MARTE that will be required in each compliance case, the following definitions are made:" by "In order to properly identify the elements of MARTE that will be required in each compliance case, the following definition is made:" Delete the paragraph: "FEATURES: There might be a number of specific Features which may or may not be present in a concrete implementation. This variability may come from the concrete UML elements allowed to be used for the extension with stereotypes, their semantic variations, envisioned difficulty for implementation, expected usage, presentation options, etc. Though this is provided here for easier the description of tools compliance, its utilization is discourage in favor of the implementation of complete extensionUnits." And on page 3, last paragraph, replace "�set of extension units and/or features that�" by "�set of extension units that�"
Actions taken:
December 21, 2007: received issue
February 17, 2010: closed issue

Issue 11869: Section 6: Remove the MSWord comment (marte-ftf)

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

Remove the MSWord comment "[N.B. Clearly, this is something..." in the related standard section

Resolution: Ok, see revised text.
Revised Text: In section 6.1, on page 6, replace "The UML profile for Systems Engineering (SysML), which deals with many of the same areas, such as the modeling of platforms and their constituent elements (hardware resources) and the allocation of software to platforms (i.e., deployment). In areas where there is conceptual overlap, MARTE is either reuses the corresponding SysML stereotypes, or defines elements that are conceptually and terminologically aligned with SysML. [NB: Clearly, this is something that we have to agree on as well.]" by "The UML profile for Systems Engineering (SysML), which deals with many of the same areas, such as the modeling of platforms and their constituent elements (hardware resources) and the allocation of software to platforms (i.e., deployment). In areas where there is conceptual overlap, MARTE is either reuses the corresponding SysML stereotypes, or defines elements that are conceptually and terminologically aligned with SysML."
Actions taken:
December 21, 2007: received issue
February 17, 2010: closed issue

Issue 11870: In section 6.1, I would suggest mentioning RTCORBA and CCM (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Enhancement
Severity: Minor
Summary:

In section 6.1, I would suggest mentioning RTCORBA and CCM

Resolution:
Revised Text: The following item could be added in the first enumeration of page 6, section 6.1: - The RTCORBA and CCM specifications address issues related to software execution platforms, real-time constraints, composition mechanisms, etc. i.e. issues that are all in the scope of the MARTE specification. All these computing platforms may be then considered as specific resources for executing MARTE model-based application.
Actions taken:
December 21, 2007: received issue
February 17, 2010: closed issue

Issue 11871: NFP does not introduce the concept of dimension (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Enhancement
Severity: Significant
Summary:

Subject: NFP does not introduce the concept of dimension. Details: NFP defines the notion of unit attached to a type but it does explicitly express the dimension related to this unit. This should be fixed to provide a comprehensive support for modeling quantities in RTES.

Resolution: The Dimension concept, and its possible attributes such as the base dimensions, is required to do dimensional analysis and verify consistency of expressions with quantitative NFPs. The concept of Dimension is not explicitly formalized in the NFP domain model nor in the NFP profile. However, the enumeration which gather the literals that are stereotyped by Unit can be already seen as a Dimension. We make this concept explicit here. The design of the current profile support this clarification with minimal changes. Note that SysML also includes the concept of dimension. As a first result of discussions between SysML and MARTE communities and a first step towards an alignment between both profiles in this domain, we propose to also explicitly support this concept.
Revised Text: see ptc/2009-05-12 pages 130 - 135
Actions taken:
December 21, 2007: received issue
October 16, 2009: closed issue

Discussion:

Resolution:  The Dimension concept, and its possible attributes such as the base dimensions, is required to do dimensional analysis and verify consistency of expressions with quantitative NFPs.  SysML also includes this concept, but a revision is being considered, not only to refine the Dimension concept with the required attributes, but to align the modeling approach for quantities, units and dimensions with the MARTE approach.  In this alignment work, some contributors of MARTE are also participating. So, we propose to wait for some concrete results in SysML (extended metaclass for Dimension and its attributes), in order to adopt a consistent modeling approach.    Disposition:	Deferred

Issue 11872: VSL (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Enhancement
Severity: Significant
Summary:

Subject: VSL should support definition and application of functions, derivatives, sequences and series. Details: In the early stage of a development process, it may be useful to model control laws of a RTES. VSL seems to be a very good fit for that purpose. However, it misses several mathematical concepts to provide a comprehensive support. VSL should support definitions of functions, derivatives, sequences and series.

Resolution: In VSL, functions are supported by means of: a) The definition of UML::Operations in DataTypes, for the declaration of functions in data type libraries. b) VSL::OperationCallExpression, for the specification of functions (reference/call to declared UML::Operations) in VSL expressions. We added a set of minimum operations/functions to MARTE primitive and data types (e.g., arithmetic and logic functions). The number of functions that could be added to VSL, and useful in the real-time and embedded system domain, is very large. In MARTE, we did not attempt to define all these functions. Instead, we proposed only a basic subset useful for general expressions. The initial intent was that further libraries could extend MARTE libraries to support domainspecific functions. However, we should assure that different kinds of functions can be declared with basis on the current VSL abstract and concrete syntaxes (e.g., the functions described in the summary of this issue). In this resolution, we describe how such functions (i.e., functions, derivatives, sequences and series) are added to the MARTE library of primitive types and supported by VSL. From a computer science viewpoint, every function declaration can be expressed as a tuple: <name, parameters/arguments, returning type>. For instance, all the functions supported by Matlab are defined in this way. In Matlab, functions are program routines, usually implemented in M-files that accept input arguments and return output arguments. Every mathematical (or not mathematical) function in Matlab is implemented with this basic principle2 (integrals, derivatives, matrices, potentials, optimization expressions, etc.). If we look at VSL, the �function� notion matches very well with the UML::Operation concept. Thus, VSL is supported in Operations for the declaration and specification (expression specifications) of functions. In VSL, however, our scope is just the language aspects. VSL does not support implementation support on those functions (although they could be implemented as methods �UML::Behavior- of such UML UML::Operations). Instead, VSL describes the semantic of functions in a declarative way.
Revised Text: see ptc/2009-05-12 pages 159 - 164
Actions taken:
December 21, 2007: received issue
October 16, 2009: closed issue

Discussion:

Resolution:  The number of functions that could be added to VSL, and useful in the real-time and embedded system domain, is very large. In MARTE, we do not attempt to define all these functions. Instead, we propose only a basic subset useful for general expressions. Further libraries could extend VSL to support this function.    A further work could be done to define a mathematical library, but this is outside of the MARTE FTF. We propose to defer this issue to evaluate if such mathematical functions would be easily integrated in new libraries.    Disposition:	Deferred

Issue 11873: allocatedTo and allocatedFrom properties should not be derived (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Revision
Severity: Significant
Summary:

Subject: In chapter 12, Details: The concept of allocation in MARTE is quite generic. Any UML::NamedElement can be used as allocation end. That enables the use of allocations in various kind of diagrams, for multiple purposes (e.g., structural, behavioural allocation.) In the current specification, allocations are supported by three stereotypes: Allocate, ApplicationAllocationEnd and ExecutionPlaformAllocationEnd. The allocatedTo and allocatedFrom properties of ApplicationAllocationEnd and ExecutionPlaformAllocationEnd are derived from the UML::Abstraction that is stereotyped as Allocate. However, creating an abstraction (i.e., a dependency) between two elements, implies that these elements belong to the same diagram, which is not always the case. Moreover, it limits the use of allocation to specific diagram types (e.g., not all the UML modeling tools allow the use of dependency on composite structures). Proposed correction: 1) Do not considerer allocatedTo and allocatedFrom as derived properties and allow end users to directly make use of the ApplicationAllocationEnd and ExecutionPlaformAllocationEnd stereoypes to express allocations. 2) Identify mechanisms to allow a characterisation of this allocation (allocation kind, allocation nature) the way its done in the Allocate stereotype.

Resolution:
Revised Text:
Actions taken:
December 21, 2007: received issue
February 17, 2010: closed issue

Discussion:

It has been agreed that this is more a tool vendor issue regarding derived properties since nothing should prevent the user to define the allocate dependency directly on the model elements when this cannot be done on the diagrams themselves (because they do not appear in the same frame).  Tool vendors (Artisan and No Magic) have pronounced themselves in favor of keeping the properties as derived properties and have mechanisms to automatically derive the value of these properties from the model repository.  Additionally, making them not derived has the great disadvantage that there is no guarantee when defining a property "allocatedTo" (for instance) that the allocation has been defined, that a corresponding property "allocatedFrom" has also been defined.  This is making an even harder tooling issue.  Disposition:	Closed, no change

Issue 11874: GRM::SchedulableResource should have a period property (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Enhancement
Severity: Minor
Summary:

Subject: GRM::SchedulableResource should have a period property. Details: After some discussion with F. Thomas, it seems that the GRM::SchedulableResource misses a period property

Resolution: SchedulableResource in GRM represents the capabilities for obtaining processing capacity from a processing resource. The period is not a fundamental quality of the concurrent units represented. The fact that it may be periodically activated or not is a design choice. To annotate this behavior among other alternatives, a workloadEvent with the periodic arrival pattern may be used. Revised Text: Disposition: Close, no change
Revised Text:
Actions taken:
December 21, 2007: received issue
February 17, 2010: closed issue

Issue 11875: Relationship between Alloc::Allocation and SRM::EntryPoint (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Clarification
Severity: Significant
Summary:

Relationship between Alloc::Allocation and SRM::EntryPoint should be clarified (maybe a generalization relationship?)

Resolution: SRM::EntryPoint shloud specialized the Alloc::Allocation stereotype.
Revised Text: Figure 14.5 Old: New: Figure 14.25 Old : New : Stereotype Description section to update : Old : This stereotype matches to the domain concept, EntryPoint, defined on page Erreur ! Signet non d�fini.. Extensions ? Dependency (from UML::Classes::Kernel). ? BehavioralFeature (UML::Classes::Kernel). New : This stereotype matches to the domain concept, EntryPoint, defined on page "To define". Generalizations � Allocate (from Alloc) on page "to define". Class Description section to update : Old : Generalizations ? ModelElement New : Generalizations ? Allocation (from Allocations)
Actions taken:
December 21, 2007: received issue
February 17, 2010: closed issue

Discussion:

see ptc/2008-06-05 for revised text (graphics)

Issue 11876: MARTE primitive types (marte-ftf)

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

MARTE primitive types: Integer, String, UnlimitedNatural and Boolean are redefined in the MARTELib. To facilitate integration, I would suggest making them subclasses of their UML counterpart.

Resolution: There is no reason to have a syntactical link between MARTE primitive types and UML primitive types. The semantics of MARTE primitive types is clearly defined and a set of default operations are provided for each primitive type. Also, the meaning of the inheritance between primitive types is not fully defined, although not forbidden, in UML. Hence, this resolution proposes to close this issue with no change. Disposition: Closed No Change
Revised Text:
Actions taken:
December 21, 2007: received issue
October 16, 2009: closed issue

Discussion:

Resolution:  This issue should be solved together with Issue 11544. Also, some aspect should be evaluated before deciding if an inheritance between primitive types is a good/valid practice, and if this modification adds consistency between UML and VSL.  Hence, we propose to defer this issue.  Disposition:	Deferred

Issue 11877: In Annex D, I would suggest make unit names (e.g. bits, bytes) singular (marte-ftf)

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

In Annex D, I would suggest make unit names (e.g. bits, bytes) singular.

Resolution: Modify Figures D.3 with singular unit names.
Revised Text: Page 435 old figure Figure D.3 - MARTE library of measurement units Page 435 new figure (note that the modification includes Issue 11338) Figure D.3. - MARTE library of measurement units
Actions taken:
December 21, 2007: received issue
February 17, 2010: closed issue

Discussion:

see ptc/2008-06-05 for revised text (graphics)

Issue 11878: Annex B: how VSL constructs shall be typed and evaluated (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Revision
Severity: Significant
Summary:

Subject: Annex B doesn't clearly define how VSL constructs shall be typed and evaluated Details: Our problem: it seems to be missing some information in the current VSL specification that explains how language constructs shall be typed and evaluated. We had a look at other standard programming languages (ANSI C, Java) to see how such information is defined. In the ANSI C language reference, *every* section introducing a language element is organised with the same structure: a subsection that introduces the syntax, a subsection defining the constraints (including type constraints) and finally a subsection regarding the semantics (other type constraints plus explanations regarding the evaluation). For instance, we can have a look at an extract that introduces the function calls: > 6.5.2.2 Function calls > > *Syntax* > > primary-expression: > identifier > constant > string-literal > ( expression ) > > > *Constraints* > 1 The expression that denotes the called function shall have type pointer to function > returning void or returning an object type other than an array type. > > 2 If the expression that denotes the called function has a type that includes a prototype, the > number of arguments shall agree with the number of parameters. Each argument shall > have a type such that its value may be assigned to an object with the unqualified version > of the type of its corresponding parameter. > > *Semantics* > 3 A postfix expression followed by parentheses () containing a possibly empty, commaseparated > list of expressions is a function call. The postfix expression denotes the called > function. The list of expressions specifies the arguments to the function. > > 5 If the expression that denotes the called function has type pointer to function returning an > object type, the function call expression has the same type as that object type, and has the > value determined as specified in 6.8.6.4. Otherwise, the function call has type void. If > an attempt is made to modify the result of a function call or to access it after the next > sequence point, the behavior is undefined. In VSL, we have a definition of the abstract syntax (the meta-model) and the concrete syntax (the BNF) in the Annex B and we have a detailed description of the domain classes (abstract syntax elements) in the Annex F. It seems that the current "constraint" and "semantics" sections of the metaclass descriptions miss some detailed information on the way constructs shall be typed and evaluated. The information does not seem to be systematic and homogeneous. Examples: > F.13.6 ConditionalExpression (from Expressions) > Generalizations > � Expression (from Expressions) on page 560 > Associations > � conditionExpr: VSL::ValueSpecification [1] Boolean expression to be evaluated. > � ifTrueExpr: VSL::ValueSpecification [1] result expression if conditionExpr is evaluated to True. > � ifFalseExpr: VSL::ValueSpecification [1] result expression if conditionExpr is evaluated to false. > Semantics > Conditional Expressions define "if-then-else" statements, which can be used inside an expression. The result of evaluating > this expression will be the result of => Here it is not stated that the consequence (ifTrueExpr) and the alternative (ifFalseExpr) shall have the same type or that the type of such an expression if a boolean. OR > F.13.8 DurationExpression (from TimeExpressions) > Generalizations > � TimeExpression (from TimeExpressions) on page 567 > Semantics > DurationExpression is a time expression that denotes a duration value. => Again, here it may miss more detailed information on the type of the expression. This is the kind of information we missed when implementing the VSL editor and which we need to figure out by ourselves. Sometimes it's obvious but it happens to be definitely tricky. That's why we think that it would be beneficial for MARTE and VSL to complete the Annex F to add this information. In that context, we propose that: 1) every VSL domain class in Annex F shall provide information about its type. 2) if the type cannot be directly known, there shall be an explanation on how it can be computed (this is the case of all the subclasses of Expression and TimeExpression). 3) if information about the evaluation / execution semantics is provided then it shall be distinguished from the type information (because this is something really different). All this information would complete either the "constraint" and/or "semantics" section of Annex F.

Resolution: VSL complements MARTE for improving the UML data type system and the specification of expressions. The approach to define VSL was to balance both its precision and its level of formality in order to provide a very compact specification but still well-formed. MARTE Beta 1 and 2 have provided a good basis to develop a couple of tools supporting VSL parsing and type checking. There are, however, some aspects that need to be improved in the VSL specification to avoid ambiguity in tool implementations. Some of the ambiguity problems were described in the summary of this issue, but we can organize them more formally in the following categories: a) Some of the production rules are syntactically ambiguous because they are based on the UML model to which the VSL expression is attached (e.g., does a data type exist or not). This means that disambiguating rules have to be defined for those rules. b) In order to semantically evaluate VSL expressions, we need to define the type of each expression or value specification. The mapping of expressions to (data) types can be easily identified in many cases, but there are other cases that this requires making it explicit. Moreover, there are some expressions that cannot be evaluated to any existing data type defined in MARTE. For example, duration expressions have not a type counterpart in the library of MARTE primitive types. To solve item (a), we will add a section of �Disambiguating Rules� for each production rule. In addition, one of the suggestions proposed in the summary of this issue is to add a special section for a semantics description. It must be noted, however, that VSL is described in two main parts: abstract syntax and concrete syntax. The semantics of VSL construct is described in plain English as a part of the abstract syntax. More particularly, the semantics of VSL model elements is described in Annex F, section F.13. However, the mapping of abstract syntax constructs to concrete syntax constructs is not explicit. In this resolution, we propose to add this mapping by identifying the abstract syntax counterpart of each production rule explicitly in the concrete syntax section. To solve item (b), we will complete all the required primitive types and describe the types to which VSL expressions should be evaluated. For those expressions that cannot be directly mapped to a concrete type, we will provide rules to help evaluating them. In addition, we will add some clarifications to help VSL implementers to use this specification. The goal is that at the end of all processing every tool implementation should be able to produce the same well-formed instance of abstract syntax tree.
Revised Text: see ptc/2009-05-12 pages 139 - 150
Actions taken:
December 21, 2007: received issue
October 16, 2009: closed issue

Discussion:

Resolution:  This requires a lot of work. We agree that this is a real issue. This relates a fundamental problem of VSL which is to define what is part of the language and is defined in libraries. This requires to define a mechanism to formalize datatype operation semantics at library level. This also requires to revise if we need a primitive type for Time-related values. We should also try to align to OCL, which already define a chapter for the semantics and expression evaluation.  This should be defined with a careful work. So we propose to defer this issue.    Disposition:	Deferred

Issue 11879: HRM::HwMemory stereotype (marte-ftf)

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

In the HRM::HwMemory stereotype, I would suggest removing the Timing datatype and directly pushing the attributes in the HwMemory stereotype, for the sake of usability

Resolution: cf. resolution of issue 11521. Disposition: Duplicate
Revised Text:
Actions taken:
December 21, 2007: received issue
February 17, 2010: closed issue

Issue 11880: HRM::HwMemory (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Enhancement
Severity: Minor
Summary:

In HRM::HwMemory, I would suggest adding a throughput attribute (typed by a NFP_DataTxRate) to specificy the notion of throughput in a memory.

Resolution: A throughput:NFP_DataTxRate attribute is added to the HwMemory, in both domain view and uml representation.
Revised Text: Fig. 14-57 p.215 is modified as follow: Fig 14-68, p.225 is modified as follow:
Actions taken:
December 21, 2007: received issue
February 17, 2010: closed issue

Discussion:

see ptc/2008-06-05 for revised figures

Issue 11881: HRM (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Enhancement
Severity: Minor
Summary:

In HRM, it misses some explanation on how to model mono-port and multi-port memories.

Resolution: For modeling such construction, we do not think it requires additional concepts within MARTE::HRM. It can be solve using a composite structure with two ports, an in flow port and one out flow port for example and modeling a specifying behavior describing the user purpose. So we decided to close with no change this issue. Disposition: Closed, no change
Revised Text:
Actions taken:
December 21, 2007: received issue
October 16, 2009: closed issue

Discussion:

 Discussion:  This issue needs more evaluation. Not sure if the current specification supports it, or need enhancements.  Disposition:	Deferred

Issue 11882: Missing Delay and Offset in SAM (marte-ftf)

Click here for this issue's archive.
Source: Universidad de Cantabria (Dr. Julio Medina, julio.medina(at)unican.es)
Nature: Revision
Severity: Critical
Summary:

The name-definition of the attribute DelayTime leads to confusion, but if it remains, the profile require a mechanism to express the voluntary relinquish of the CPU during a time. This is what is normally called a delay, this is implemented with primitives like sleep, clock_nanosleep in POSIX, mdelay in linux, delay in ADA, etc. The usage of constraints/observers in this case is not desirable, since these are analysis models not specifications, and contraints will be used for verification against analysis results. A special kind of step that includes offsets and delays is suggested fdor inclusion, even at GQAM level.

Resolution: Be explicit and conformant with existing practice: replace the attribute SaStep::delayTime with three new attributes, SaStep::nonpreemptionBlocking, SaStep::selfSuspensionBlocking, and SaStep::numberSelfSuspensions. If an additional specialization of GaStep is needed-and arguably it is-then that SHALL be addressed in a new and separate issue allocated to GQAM.
Revised Text: On page 288, remove SaStep::delayTime in Figure 16.4. On page 288, add SaStep::nonpreemptionBlocking, SaStep::selfSuspensionBlocking, and SaStep::numberSelfSuspensions to Figure 16.4. On page 609, remove entirely the phrase: o delayTime: NFP_Duration [0..1] length of time that an step that is eligible for execution waits while acquiring and releasing resources. On page 609, add these bullet phrases: o nonpreemptionBlocking: NFP_Duration [0..1] maximum length of time within the context of the current SaStep that a ready SaStep is blocked while lower priority schedulable entities are nonpreemptible. o selfSuspensionBlocking: NFP_Duration [0..1] maximum length of time within the context of the current SaStep that a ready SaStep voluntarily yields the Processing Resource. o numberSelfSuspensions: NFP_Integer [0..1] maximum number of times an SaStep self suspends during its execution. (MUST be provided if selfSuspensionBlocking is provided.)
Actions taken:
December 22, 2007: received issue
February 17, 2010: closed issue

Discussion:

Rationale:  In real-time programming, a delay is a voluntary yield and is implemented with primitives like sleep, clock_nanosleep in POSIX, mdelay in linux, and delay in Ada. Note that there are active forms of delay, sometimes called spinning, where a task delays its execution without yielding its Processing Resource.    In one of the definitive texts in the field of Schedulability Analysis, "Real-time Systems", Jane Liu defines the time that a schedulable entity is blocked from execution by lower priority entities that enter into nonpreemptible durations as "nonpreemption blocking". She defines the time that a schedulable entity is blocked from execution due to voluntary self suspension as "self suspension blocking". She further points out that one must also know the number of times a schedulable entity will suspend itself during its execution.    Although nonpreemption blocking typically arises when contending for shared resources, there is no need to restrict applicability of the term "nonpreemption blocking" to only the case where schedulable entities contend for shared resources. Therefore, the MARTE definition will simply state that it is due the nonpreemptibility of lower-priority schedulable entities.

Issue 11883: Support for Views or sets of profile annotations (marte-ftf)

Click here for this issue's archive.
Source: Universidad de Cantabria (Dr. Julio Medina, julio.medina(at)unican.es)
Nature: Enhancement
Severity: Significant
Summary:

Schedulability analysis models are built for each real-time situation of interest, and due to the number of different modes of operation of the system or to the number of different worst case equivalent models used to analyze those situations for which there would be no analitical techniques available, the amount of SA models to be annotated over the same UML base model is significant. The profile mechanism in UML provides a way to apply and de-apply a profile to a UML model, but it does not allow to have different colections or groups of stereotype instances (annotations) in a common frame so that they can be store and retrive in the repository, treated as views or "profile applications" of the same profile. In the case of SAM this will be done with the purpose of having different RT Situations, but the same will be valid for a large number of modelling purposes: the phase in the development process, level of detail, different analysis tool or technique to use, or just to assist the modelling processing paradigm. This may be solved in an ad-hoc manner by tools, but a standard (hence interchangable among tools) mechanism is desireble. The NFP types in MARTE may include an additional tag (property) to tie them together, but this tagging should be extensible to any stereotype

Resolution: This issue is duplicated of Issue 11764. Both propose a mechanism to annotate multiple value annotations for different situations in a model. Disposition: Duplicated
Revised Text:
Actions taken:
December 22, 2007: received issue
October 16, 2009: closed issue

Discussion:

Discussion:  Even though the idea is really interesting, it has not been gotten consensus on the mechanism to do it. NFP chapter has a similar Issue11764 also deferred because of this.  Disposition:	Deferred

Issue 11884: Consistency between RTEMoCC, SAM, and SRM (marte-ftf)

Click here for this issue's archive.
Source: Universidad de Cantabria (Dr. Julio Medina, julio.medina(at)unican.es)
Nature: Enhancement
Severity: Minor
Summary:

As a complement to the explanation of the semantics of RTUnit and PPUnit in RTEMoCC it would be very useful to have a mapping to its corresponding SAM models, and if possible also to its platform independent implementation using SRM, this may be added in an annex specifically dedicated to semantic consistency among these chapters in MARTE.

Resolution: This aspect is definitively out of the scope of the MARTE specification. It concerns methodological definitions. Since these model elements represent different levels of abstraction (HLAM, SAM, RSM), their mapping is complex and can derive in several choices. This could be covered by a further work providing some guidelines to help methodologists in defining their specific mappings, according to different models of computation, development phases, etc. However, this is out of the scope of MARTE standard document. We propose to close this issue with no change. Disposition: Closed No Change
Revised Text:
Actions taken:
December 22, 2007: received issue
October 16, 2009: closed issue

Discussion:

Discussion:  Describing the semantic consistency for these chapters in a dedicated annex is useful. However, it sounds more like an improvement of the spec than a real issue. I would suggest addressing it in a next version of the MARTE spec.  Disposition:	Deferred

Issue 11885: page 271, Fig.15.7 and in Annex D, page 437, Fig.D.5 (marte-ftf)

Click here for this issue's archive.
Source: Carleton University (Dr. Dorina C. Petriu, petriu(at)sce.carleton.ca)
Nature: Uncategorized Issue
Severity:
Summary:

a) Inconsistent definition of dataType ArrivalPattern as follows:  - on page 263, Fig.15.3 and on page 288, Fig.16.3 the definition contains 7 values (the last two are �open� and �close�)  - on page 271, Fig.15.7 and in Annex D, page 437, Fig.D.5, the same definition contains only 6 values ("open" is missing and should be added).  Example of use of different arrival patterns: �open� in Fig.17.17 and �closed� in 17.22.

Resolution: There was a mistake in Figures 15.7 (GQAM) and Fig. D.5 (Annex D). The OpenPattern was not included in the list of Arrival Patterns. These two figures will be corrected.
Revised Text: -Old Figure 15.7 (p. 271): Disposition: See issue 11885 (Annex D WG) for disposition New Figure 15.7 (p. 271): -Old Figure D.5 (p. 437) New Figure D.3:
Actions taken:
December 21, 2007: received issue
February 17, 2010: closed issue

Discussion:

see ptc/2008-06-05 for revised text/graphics

Issue 11886: use of stereotype names in UML model examples is inconsistent (marte-ftf)

Click here for this issue's archive.
Source: Carleton University (Dr. Dorina C. Petriu, petriu(at)sce.carleton.ca)
Nature: Uncategorized Issue
Severity:
Summary:

b) The first letter of a stereotype applied to a UML model element should be lower-case or upper-case (e.g., <<gaScenario>> or <<GaScenario>>) ? The use of stereotype names in UML model examples is inconsistent in different chapters: starting with lower-case in chapters 8, 9, 11, 12, 13, 14, 16, etc. and with upper case in chapters 10 (Figures 10.20 to 10.22), 17.

Resolution: By convention, when a stereotype is applied to a model element, the first letter of the stereotype name must be lower-case. In the examples mentioned in the summary of the issue, the first letter of stereotype names must be set to lower-case.
Revised Text: For the following figures, the first letter of stereotype names must be set to lower-case: - Fig 10.20, p.114 - Fig 10.21, p.115 - Fig 10.22, p.116 - Fig 11.18, p.132 - Fig 17.9, p.325 - Fig 17.10, p.326 - Fig 17.14, p.329 - Fig 17.15, p.330 - Fig 17.16, p.331 - Fig 17.17, p.332 - Fig 17.19, p.334 - Fig 17.21, p.336 - Fig 17.22, p.337 - Fig 17.23, p.337 - Fig 17.24, p.338 - Fig 17.26, p.339 - Fig 17.27, p.341
Actions taken:
December 21, 2007: received issue
February 17, 2010: closed issue

Issue 11887: attribute �resMult� of Resource appears under its old name (marte-ftf)

Click here for this issue's archive.
Source: Carleton University (Dr. Dorina C. Petriu, petriu(at)sce.carleton.ca)
Nature: Uncategorized Issue
Severity:
Summary:

The attribute �resMult� (resource multiplicity) of Resource appears under its old name �maxRI� in the following figures: 17.14, 17.16, 17.17, 17.24

Resolution: Replace the name in the affected Figures.
Revised Text: maxRI is replaced by resMult in these Figures and in Fig 14.3 (revised separately) Figure 17.14 Figure 17.16 Figure 17.17 Figure 17.24
Actions taken:
December 21, 2007: received issue
February 17, 2010: closed issue

Discussion:

see ptc/2008-06-05 for revised text/graphics

Issue 11888: Missing attribute in figure (marte-ftf)

Click here for this issue's archive.
Source: Carleton University (Dr. Dorina C. Petriu, petriu(at)sce.carleton.ca)
Nature: Uncategorized Issue
Severity:
Summary:

d) Missing attribute in figure. On Page 333, the second paragraph says:  �The cycleInit Action has a hostDemand. Since it is not shown in a swimlane, its process (SchedulableResource) is given directly on the Step stereotype by the attribute "concur" (which determines its deployment and thus its host processor).�  However, Fig 17.17 to which this text refers does not show any attribute �concur�.

Resolution: Add the attribute, which is called concurRes not concur.
Revised Text: (1) The second para of p 333, which describes this, has been removed in issue 11649. However it appears to be needed to explain this point. So original text: The cycleInit Action has a hostDemand. Since it is not shown in a swimlane, its process (SchedulableResource) is given directly on the Step stereotype by the attribute "concur" (which determines its deployment and thus its host processor). New text: The cycleInit Action has a hostDemand. Since it is not shown in a swimlane, its process (SchedulableResource) is given directly on the Step stereotype by the attribute "concurRes" (which determines its deployment and thus its host processor). In Fig 17.17, there is a Step stereotype on the trigger for CycleInit. To this, add the attribute: concurRes=Acquire Revised Figure 17.17 (including changes made for issue 11649). Pastable and editable figure in word or frame: {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:
December 21, 2007: received issue
February 17, 2010: closed issue

Discussion:

see ptc/2008-06-05 for revised text/graphics

Issue 11889: Typos: (marte-ftf)

Click here for this issue's archive.
Source: Carleton University (Dr. Dorina C. Petriu, petriu(at)sce.carleton.ca)
Nature: Uncategorized Issue
Severity:
Summary:

- Page 265, the first paragraph: �between the two between�  - Page 280, the second line from the bottom: �sorrespond�  - Page 311, the first paragraph: �ypical performance�  - Page 315, in the middle: �PProcesses�  - Page 325, in the middle: �avalilable�

Resolution: Corrections are described in the revised text.
Revised Text: In section 15.2.2.2, p.265, first paragraph of the Time Intervals section, replace "The inter-occurrence time interval between the two between successive initiations�" by "The inter-occurrence time interval between two successive initiations�". In section 15.3.2.13, p.280, constraint [1], replace "� servDemand and servCount sorrespond, �" by "� servDemand and servCount correspond�". In section 17.2.1, p.311, first paragraph, replace "ypical performance properties include�" by "Typical performance properties include�". In section 17.2.2.6, p.315, second item of the first enumeration, replace "� in different PProcesses�" by "� in different processes�" In section 17.4.1, p.325, second paragraph, replace "�(multiplicity of avalilable resource instances)�" by "�(multiplicity of available instances)�".
Actions taken:
December 21, 2007: received issue
February 17, 2010: closed issue

Issue 11890: Unfinished sentence on Page 313, the sixth paragraph (marte-ftf)

Click here for this issue's archive.
Source: Carleton University (Dr. Dorina C. Petriu, petriu(at)sce.carleton.ca)
Nature: Uncategorized Issue
Severity:
Summary:

�Within a scenario these are lumped together as�

Resolution: Remove the partial sentence.
Revised Text: Remove the sentence
Actions taken:
December 21, 2007: received issue
February 17, 2010: closed issue

Issue 11891: Incorrect cross-reference to chapter number on Page 309, third paragraph (marte-ftf)

Click here for this issue's archive.
Source: Carleton University (Dr. Dorina C. Petriu, petriu(at)sce.carleton.ca)
Nature: Uncategorized Issue
Severity:
Summary:

g) Incorrect cross-reference to chapter number on Page 309, third paragraph:  �The performance domain employs and extends the Generic Quantitative Analysis Modeling (GQAM) domain of Chapter 17.�  GQAM is in chapter 15.

Resolution: {Replace 17 by 15}
Revised Text: Old text p 309 para 3: "The performance domain employs and extends the Generic Quantitative Analysis Modeling (GQAM) domain of Chapter 17." New text: "The performance domain employs and extends the Generic Quantitative Analysis Modeling (GQAM) domain of Chapter 15."
Actions taken:
December 21, 2007: received issue
February 17, 2010: closed issue

Issue 11892: Incorrect cross-reference to Figure numbers (marte-ftf)

Click here for this issue's archive.
Source: Carleton University (Dr. Dorina C. Petriu, petriu(at)sce.carleton.ca)
Nature: Uncategorized Issue
Severity:
Summary:

- Page 325: �In Figure 17.8, the blockingTime ...� - should refer to Figure 17.9.  - Page 326 the first paragraph: �In Figure 17.9 a simple sequence is annotated�- should refer to Figure 17.10  - P331 �Figure 17.15 and Figure 17.16� - should refer to figures 17.16 and 17.17�

Resolution:
Revised Text: (1) Page 325: "In Figure 17.8, the blockingTime ..." - should refer to Figure 17.9. No Change: Already corrected in issue 11649, edit item E9 (2) Page 326 the first paragraph: "In Figure 17.9 a simple sequence is annotated"- should refer to Figure 17.10 No Change: Already corrected in issue 11649, edit item E11 (3)P331 Last paragraph Old text: Figure 17.15 and Figure 17.16 show the deployment... New text: - Figure 17.16 and 17.17 show the deployment...
Actions taken:
December 21, 2007: received issue
February 17, 2010: closed issue

Issue 12185: RTF stereotype (marte-ftf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Revision
Severity: Minor
Summary:

The RTF stereotype should also extend the Behavior Meta-class

Resolution:
Revised Text:
Actions taken:
January 16, 2008: received issue
February 17, 2010: closed issue

Discussion:

See Issue 11867 for the change in name from "rtf" to "rtFeature"�  We risk confusion by allowing wide applicability (extensability) of the various rt* stereotypes and, even without this change, rtFeature already seems to be a collection of too-loosely-related properties. Furthermore, by naming convention, whether appropriate or not, MARTE's RtBehavior is the implied, intended stereotype for Behavior.  A vote of Yes on this issue will leave RtFeature unable to extend UML::Behavior. A vote of No on this issue will only leave the issue Open.  Disposition:	Closed, no change

Issue 12194: stereotype attribute "GaExecHost.throughput" that is not documented (marte-ftf)

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

In GQAM, the profile diagram (Figure 15.6) defines a stereotype attribute "GaExecHost.throughput" that is not documented in section 15.3.2 or introduced in the domain model (Figure 15.5)

Resolution: Add to Domain model and document it. Add to Fig 15.5
Revised Text: (1) In Sec. 15.3.2.7 GaExecHost: add an atttribute throughput: NFP_Frequency [*] the throughput of the host in scheduled initiations/sec. (2) In Sec , p 266, second-last paragraph, old text: In use it will also have an output NFP of resource utilization (for a multiple resource this is defined as the mean number of busy units). new text: In use it will also have an output NFP of resource utilization (for a multiple resource this is defined as the mean number of busy units), and for throughput (the number of requests handled successfully per unit time). (3) Fig 15.5, add attribute throughput: NFP_Frequency [*] to class ExecutionHost.
Actions taken:
January 23, 2008: received issue
February 17, 2010: closed issue

Discussion:

Issue 12196: Section: 8.3.3.1 (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Eric Maes, eric.maes(at)fr.thalesgroup.com)
Nature: Enhancement
Severity: Minor
Summary:

Proposition to extend the probability distributions functions list with (used in AnyLogic) : - geometric (double p) The Geometric distribution is a discrete distribution bounded at 0 and unbounded on the high side. It is a special case of the Negative Binomial distribution. In particular, it is the direct discrete analog for the continuous Exponential distribution. The Geometric distribution has no history dependence, its probability at any value being independent of a shift along the axis. - laplace (double phi, double beta) The Laplace distribution, sometimes called the double exponential distribution, is an unbounded continuous distribution that has a very sharp central peak, located at theta. The distribution scales with phi. - chi squared (double nu, double min) The Chi Squared is a continuous distribution bounded on the lower side. Note that the Chi Squared distribution is a subset of the Gamma distribution with beta=2 and alpha=n�/2. Like the Gamma distribution, it has three distinct regions. For n�=2, the Chi Squared distribution reduces to the Exponential distribution, starting at a finite value at minimum x and decreasing monotonically thereafter. For n�<2, the Chi Squared distribution tends to infinity at minimum x and decreases monotonically for increasing x. For n�>2, the Chi Squared distribution is 0 at minimum x, peaks at a value that depends on n�, decreasing monotonically thereafter. - rayleigh (double sigma) The Rayleigh distribution is a continuous distribution bounded on the lower side. It is a special case of the Weibull distribution with alpha =2 and beta/sqrt(2) =sigma. Because of the fixed shape parameter, the Rayleigh distribution does not change shape although it can be scaled. - weibull (double alpha, double beta, double min) The Weibull distribution is a continuous distribution bounded on the lower side. Because it provides one of the limiting distributions for extreme values, it is also referred to as the Frechet distribution and the Weibull-Gnedenko distribution. - logistic (double beta, double alpha) The Logistic distribution is an unbounded continuous distribution which is symmetrical about its mean [and shift parameter], alpha. The shape of the Logistic distribution is very much like the Normal distribution, except that the Logistic distribution has broader tails. - pareto (doubla alpha, double min) The Pareto distribution is a continuous distribution bounded on the lower side. It has a finite value at the minimum x and decreases monotonically for increasing x. A Pareto random variable is the exponential of an Exponential random variable, and possesses many of the same characteristics. - triangular (double min, double max, double mode) The Triangular distribution is often used when no or little data is available; it is rarely an accurate representation of a data set. However, it is employed as the functional form of regions for fuzzy logic due to its ease of use. - cauchy (doubla lambda, double theta) The Cauchy distribution is an unbounded continuous distribution that has a sharp central peak but significantly broad tails. The tails are much heavier than the tails of the Normal distribution. - beta (double p, double q, double min, double max) The Beta distribution is a continuous distribution that has both upper and lower finite bounds. Because many real situations can be bounded in this way, the Beta distribution can be used empirically to estimate the actual distribution before much data is available. Even when data is available, the Beta distribution should fit most data in a reasonable fashion, although it may not be the best fit. The Uniform distribution is a special case of the Beta distribution with p, q = 1. - lognormal (double mu, double sigma, double min) The Lognormal distribution is a continuous distribution bounded on the lower side. It is always 0 at minimum x, rising to a peak that depends on both mu and sigma, then decreasing monotonically for increasing x. - erlang (double beta, int m, double min) The Erlang distribution is a continuous distribution bounded on the lower side. It is a special case of the Gamma distribution where the parameter, m, is restricted to a positive integer. As such, the Erlang distribution has no region where F(x) tends to infinity at the minimum value of x [m<1], but does have a special case at m=1, where it reduces to the Exponential distribution. - negativeBinomial (double p, double n) The Negative Binomial distribution is a discrete distribution bounded on the low side at 0 and unbounded on the high side. The Negative Binomial distribution reduces to the Geometric Distribution for k = 1. The Negative Binomial distribution gives the total number of trials, x, to get k events (failures...), each with the constant probability, p, of occurring. - logarithmic (double beta) The Logarithmic distribution is a discrete distribution bounded by [1,...]. Theta is related to the sample size and the mean. - hypergeometric (int ss, int dn, int ps) The Hypergeometric distribution is a discrete distribution bounded by [0,s]. It describes the number of defects, x, in a sample of size s from a population of size N which has m total defects. The ratio of m/N = p is sometimes used rather than m to describe the probability of a defect. Note that defects may be interpreted as successes, in which case x is the number of failures until (s-x) successes. The sample is taken without replacement.

Resolution: We need to be sure that the new distributions functions are really necessary in MARTE. Note that we do not attempt in MARTE to define all the existing distribution functions but the required in common practice. After evaluating some performance analysis and simulation tools, we consider that the following one are highly decided, and propose to include them in the MARTE library. geometric (real p). The Geometric distribution is a discrete distribution bounded at 0 and unbounded on the high side. - triangular (real min, real max, real mode). The Triangular distribution is often used when no or little data is available; it is rarely an accurate representation of a data set. - logarithmic (real theta). The Logarithmic distribution is a discrete distribution bounded by [1,...]. Theta is related to the sample size and the mean. Further distribution functions can be added at library level. Issue Dependency Warning: Note that this issue affects Issue 12561, which clarifies the mechanism to specify probability distribution expressions. Issue 12561 depends on this issue, but the reverse case is not true.
Revised Text: In page 45, add the following probability distribution descriptions: � geometric (p: Real) The Geometric distribution is a discrete distribution bounded at 0 and unbounded on the high side. � triangular (min: Real, max: Real, mode: Real) The Triangular distribution is often used when no or little data is available; it is rarely an accurate representation of a data set. � logarithmic (theta: Real) The Logarithmic distribution is a discrete distribution bounded by [1,...]. Theta is related to the sample size and the mean.
Actions taken:
January 24, 2008: received issue
October 16, 2009: closed issue

Discussion:

Resolution:  This feature needs to be discussed more carefully. We need to be sure that the new distributions functions are really necessary in MARTE. Note that we do not attempt in MARTE to define all the existing distribution functions but the required in common practice.  We propose to defer this issue. Note that this is only an enhancement and does not affect the consistency of the specification. Further distribution functions can be added at library level.  Disposition:	Deferred

Issue 12209: using $ in naming variables (marte-ftf)

Click here for this issue's archive.
Source: Carleton University (Dr. Murray Woodside, cmw(at)sce.carleton.ca)
Nature: Uncategorized Issue
Severity:
Summary:

This editing issue affects many chapters.      In VSL sec B.3.3.12 p 402 the declaration of variables requires that $ precede the variable name. Thus the $ sign is not part of the variable name.      Throughout the document  there is inconsistent naming of variables where they are used in context, with and without the $ at the beginning.  Examples are found in NFP (Fig 8.9) and many other chapters.      These are not incorrect... a variable name may still begin with any character. However they give a confusing impression, and consistency within the doc might be an improvement.      In reading examples, I have found it a great help to readability if names denoting quantities (variable names) DO have the $ sign. So I suggest that we use the $ sign on variable names in our examples

Resolution: There are two kinds of VSL expressions related to variables: 'variable declaration' and 'variable call'. In VSL, we use '$' as a prefix only in the declaration notation, and in the 'call' expression, we use only the name. We really need to make difference between both because VSL parsers need to distinguish them. a) Arguments to use 'let' as keyword in variable declarations: The use of '$' is not 'conventional' to declare variables. Other keywords like 'let [variable-name]' would be more appropriate. It is recommended to use 'let ' for variable declaration because having a keyword for declaration is the more natural choice in most of languages. b) Arguments to use '$' as part of the variable name in variable call expressions: The absence of the symbol '$' in variable call expressions ("variable use") would make hard to make the distinction with other 'names' in VSL expressions, such as enumeration literals or PropertyCallExpression. The goal of this symbol in the former SPT profile was to identify easily a variable within an expression. With the current notation, the latter is not possible. . c) Arguments against a modification of variable notation Some reasons would suggest avoiding such a modification: - VSL has an essential difference with other conventional languages: VSL is intended to be used in 'properties values', where compact annotations should be privileged. Also, its use in Constraints tries to mark a difference with OCL, and it's that annotations should be shorter and easier to understand. Having simple and short expressions is a main concern in VSL to embed them in graphical models without charging models, and for easy learning of the language. - The UML Time Observation notation works exactly like VSL variables. A symbol ('@' for time observation and '&' for duration observation) is used for declarations, and only the name (without the symbol) for expressions. Time observations could be considered as a sort of variables, but with a more specific semantics. So, having the notation of both VSL variables and Time Expression aligned is important for comprehensibility of Profile users. -In MARTE, most of VSL variable expressions are used at "declaration" level, because in a regular NFP tuple, the value resulting from the evaluation of an expression or variable is specified in a dedicated slot ("value"). This means that the variables will be easily identified in a model, because they will include the '$' symbol. - VariableCallExpressions are mainly used in Algebraic (math, logical, conditional) expressions, where having a transparent syntax in terms of "parameters" either coming from a UML Property or VSL Variable origin is desirable to avoid complexity in VSL expressions. d) Conclusions The argument for using 'let' is more to follow conventional languages, and not pragmatic concerns. Also, the argument that the current mechanism confuses comprehensibility between variable declaration and variable call expression is not sustainable. VSL variable notation works exactly as UML TimeObservation works, and there were not reported any issue related to confusing language users. For these reasons, we suggest to close this issue with no change. Disposition: Closed, no change
Revised Text:
Actions taken:
February 4, 2008: received issue
February 17, 2010: closed issue

Issue 12214: Section Allocation: Wrong direction of the allocation (marte-ftf)

Source: INRIA (Dr. Frederic Mallet, Frederic.Mallet(at)inria.fr)
Nature: Revision
Severity: Minor
Summary:

Wrong direction of the allocation: The MARTE allocation mechanism is directly inspired from SysML. SysML has chosen a convention contrary to UML and draws the arrow from the suppliers (usually a target) to the clients (usually a source). So as to be compatible MARTE has followed SysML with that convention. Now, the SysML RTF is considering that this triggers too many problems with tool vendors and thus considers using the same convention than UML. An alignment between SysML and MARTE is required as much as possible and MARTE FTF should then think through this issue and adopt the same convention than UML.

Resolution: The only text that was wrong has been removed in the resolution for issue 11770. The new text in this resolution assumed that sources are referred as clients and targets are referred as suppliers. This resolution has no impact on any other section since the wrong "direction" was only in the vocabulary used (clients vs. suppliers) and the graphical notation was already correct.
Revised Text: See resolution for issue 11770 for details.
Actions taken:
February 7, 2008: received issue
February 17, 2010: closed issue

Issue 12220: Section: 15.3 and 17.3 (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Eric Maes, eric.maes(at)fr.thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

Inconsistencies concerning the <<GaStep>> prob stereotype attribute multiplicity: - In figure 15.7 "UML extensions for GQAM stereotypes related to behavior", p 271, it is [0..1], - In <<GaStep>> profile element description (�15.3.2.13), p280, it is [0..*], - In figure 17.7 "Profile diagram of performance extensions for workload, behavior and time observations", p 318, it is [0..1], - In <<PaStep>> profile element description (�17.3.2.15), p323, it is [0..1]. As a consequence, in PAPYRUS, it is [0..1] and in RSA, it is [0..*].

Resolution: [0..1] is correct, so it is changed in sec 15.3.2.13 where it is written [*]. Other attributes in that section: ... blockT ...selfDelay ...rep are also written [*] when they should be [0..1], and these are changed also. They are correct in Annex F.10.17.
Revised Text: see ptc/2009-050-12 pages 165 - 167
Actions taken:
February 13, 2008: received issue
October 16, 2009: closed issue

Issue 12221: Section: 13.3.1 (marte-ftf)

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:

Figure 13.12 needs to be updated to show all properties owned by the <<RtAction>> in order to complete the diagram according to the definition of the stereotype itself.

Resolution: The mentioned attributes of <<RTAction>> are missing in Figure 13.11 (and not 13.12. This resolution proposes to fix Figure 13.11 with the right RtAction attributes, according to the Stereotype description.
Revised Text: see ptc/2009-05-12 pages 168
Actions taken:
February 14, 2008: received issue
October 16, 2009: closed issue

Issue 12225: TimingResource of GRM (marte-ftf)

Click here for this issue's archive.
Source: INRIA (Dr. Frederic Mallet, Frederic.Mallet(at)inria.fr)
Nature: Revision
Severity: Critical
Summary:

My concern is about the TimingResource of GRM. In the domain model (10.2.2, p.89-90 and figure 10.7), TimingResource both refers to a Clock (since it is a Resource) and specializes ChronometricClock. The specialization is not suitable since a TimingResource is not a clock (with the meaning given in the Time profile) but merely refers to a Clock. To make a TimingResource specific to chronometric clocks, it is largely sufficient to refine the association to a Clock by an association to a ChronometricClock. In the UML representation (Figure 10.15) and in 10.3.2.20 I would simply remove the specialization to ClockType. The reference to a Chronometric Clock (idealClock in this precise case) is already implicit by the use of the NFP_Duration type. If you really want to insist on the use of chronometric clock only, a comment in the text should do it.

Resolution: We propose to remove the specialization from TimingResource to ChronometricClock in the domain view. In the UML representation, we remove the specialization from ClockType. This latter specialization is very problematic since Resource extends several metaclasses (Property, InstanceSpecification, Classifier, Lifeline, Connectableelement) and ClockType only extend Class. The specializations are not required since a TimingResource being a resource can already access to information of Clocks (including if required, ChronometricClocks).
Revised Text: see ptc/2009-05-12 pages 171 - 172
Actions taken:
February 15, 2008: received issue
October 16, 2009: closed issue

Issue 12231: expressing requirements (marte-ftf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mr. Lonnie VanZandt, lonniev(at)gmail.com)
Nature: Enhancement
Severity: Minor
Summary:

When expressing requirements that implementations of the MARTE Profile MUST satisfy, the specification SHALL use Requirements Engineering statements which are de facto best current practices. For example, the phrase in the fourth paragraph, of 16.3.1, reads: BEGINQUOTE An "SaEnd2EndFlow" will make reference implicitly to one ore [sic] more GQAM "GaWorkloadEvent" and to one "GaScenario" commonly by means of a containment relationship (owned elements) or allocation stereotypes. ENDQUOTE This is expressing a Business (or Domain) Rule (as expressed in Figure 16.3) which implementations of the Profile must enforce. However, the sentence is too passive and is not sufficiently imperative to communicate this requirement. The recommendation is to replace such ambiguous and passive phrasing with the de facto standard SHOULD, MUST, SHALL phrasing now employed in RFCs and in Requirements Specifications. For example, replace the wording above with: BEGINQUOTE Every implementation of the MARTE Profile SHALL enforce that each 'SaEndToEndFlow' MUST refer to one or more GQAM_Workload::WorkloadEvent(s) and MUST refer to one and one only GQAM_Workload::BehaviorScenario. These references SHALL be achieved directly via Composition or indirectly via the <<allocation>> association. ENDQUOTE While this issue is written specifically for the cited text, the recommendation SHOULD be applied throughout the entire specification whereever the specification is expressing how the Profile MUST be implemented. There is no need for this formalism in the sections of the specification that provide rationale and explanation--that is, within the Domain Modeling sections. The rationales for this formalism are: it greatly reduces ambiguity, profiles are more than collections of individual decorations, domain rules "cut across" sets of domain elements, and a subset of tools extant can enforce such domain rules if those rules are known, expressed, and consistent.

Resolution:
Revised Text:
Actions taken:
February 15, 2008: received issue
October 16, 2009: closed issue

Discussion:

Even if the resolution of this issue would be interesting for improving the clarity of  the specification; it seems not possible to handle it in the context of the FTF.  Indeed, it requires for going trough the whole text of the specification and to  modify where appropriate the text. It will then not possible due to lack of time and  the amount of work needed for doing that rewriting to deal with this issue here.  We think that this issue should be introduced as a requirement in a future RFP  for a new major version MARTE. For these reasons, we propose to close it with  no change.  Disposition: Closed, no change

Issue 12232: Rename every instance of "SaEnd2EndFlow" to "SaEndToEndFlow". (marte-ftf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mr. Lonnie VanZandt, lonniev(at)gmail.com)
Nature: Enhancement
Severity: Minor
Summary:

Rename every instance of "SaEnd2EndFlow" to "SaEndToEndFlow". While this issue is specific to the cited text, it SHOULD be applied throughout the specification whereever attributes are so named. The rationale for the change is that the substitution of numerals such as "1", "2", and "4" for the non-numeric concepts expressed by the truncated words "a", "to", and "for", respectively, lead to needless cognitive dissonance. CamelCase is acceptable but there is no longer any need for variable names which use substitutions and truncations to satisfy machine or language constraints.

Resolution: Proceed with the suggested modification. The only place where a numeral is used as substitute of words is in the stereotype "SaEnd2EndFlow" and in two of their attributes.
Revised Text: -In page 294, replace the last sentence of the fourth paragraph with (the former text had also some minor typos corrected here): A "SaEndToEndFlow" will make reference implicitly to one or more GQAM "GaWorkloadEvent" and to one "GaScenario" commonly by means of a containment relationship (owned elements) or allocation stereotypes. -In page 294, replace Fig. 16-7 with the following figure (note that the shared resource attributed was added to reflect Issue 11778 resolution in Ballot 1). -In page 295, replace the last sentence of the second paragraph by: For instance, "SaEndToEndFlow" has an association (timing) that define a meta-association between this element and UML constraints stereotyped as "GaTimingObserver", or its child stereotypes. -In page 296, replace section 16.3.2.1 by: 16.3.2.1 SaEndToEndFlow -Replace the first sentence of this subsection with: The SaEndToEndFlow stereotype maps the EndToEndFlow domain element (section Error! Reference source not found.Erreur ! Source du renvoi introuvable., p. Erreur ! Signet non d�fini.) denoted in Error! Reference source not found.Erreur ! Source du renvoi introuvable.. -Replace the names of the third and fourth attributes in this subsection with: EndToEndT EndToEndD -In page 304, replace Fig. 16-11 with: -In page 643, Annex H, replace the word 'End2EndFlow' in the fifth row, second column, with 'SaEndToEndFlow'.
Actions taken:
February 15, 2008: received issue
February 17, 2010: closed issue

Discussion:

see ptc/2008-06-05 for revised figures

Issue 12233: Correct the inconsistency between the diagram and the text (marte-ftf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mr. Lonnie VanZandt, lonniev(at)gmail.com)
Nature: Revision
Severity: Minor
Summary:

Sentence 1, paragraph 2, on page 295 begins: BEGINQUOTE "GaTimingObserver" specializes "NfpConstraint", and the latter extends UML Constraints... ENDQUOTE However, Figure 16.8, page 295, expresses that GQAM::GaTimingObs [sic] extends not specializes MARTE::NFPs::NfpConstraint. Several recommendations follow: 1. Correct the inconsistency between the diagram and the text. I suspect that the text should say "extends" rather than "specializes". 2. Consistently name the element GQAM::GaTimingObserver. 3. In text which refers to elements, always use a qualified name--it need not be fully qualified when there is a common parent scope in effect for the context of the text--and never use quoted "nicknames" or, worse, arbitrary alternate, similar names. 4. Replace the cited paragraph entirely with a paragraph which describes the Schedulability Analysis Module's profile and which isn't suspiciously similar to a cut-n-paste from the related GQAM material. 5. If Timing Observers move to a more common subprofile outside of GQAM, then refactor this section appropriately.

Resolution: Revise figures and text according to the following considerations (each numbered point is related to the corresponding numbered item above): 1. Update figures with the Specialization relationship instead of the Extension relationship between NfpConstraint and GaTimedObserver. This has to be done in both Chapters GQAM and SAM, and in both sections Domain View and UML Representation View. Also, in Figure 16.5, the association ends startObs and endObs are not valid anymore. In the FTF1, they have changed by startEvent and endEvent respectively. 2. GQAM::GaTimingObserver is an old name that was changed in FTF1 by the name GQAM::GaTimedObserver. This has to be updated in all figures and text throughout Chapter SAM. 3. Edit all incorrect aliases for GQAM::GaTimedObserver appropriately. Never use quoted "nicknames". The affected section is only Section 16.3.1. 4. The cited paragraph doesn�t exist elsewhere in the MARTE specification. 5. Timed Observers have not been moved to a more common sub-profile. So, no additional modifications are required.
Revised Text: see ptc/2009-05-12 pages 176 - 179
Actions taken:
February 15, 2008: received issue
October 16, 2009: closed issue

Issue 12237: page 64 ClockConstraintSpecification (marte-ftf)

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 page 64 ClockConstraintSpecification is said to be specified in CCS, but if you take a look in CCS (p.420) it is referenced as an element from Time::TimeRelatedEnt ities::ClockConstraints.

Resolution: Change in Figure C.2. ClockConstraintSpecification is now defined in CCS package and no longer refer to Time::TimeRelatedEntities
Revised Text: see ptc/2009-05-12 pages 181 - 183
Actions taken:
February 19, 2008: received issue
October 16, 2009: closed issue

Issue 12238: TimedElements::TimedObservation (fig. 9.18) does not exist (marte-ftf)

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:

TimedElements::TimedObservation (fig. 9.18) does not exist, the correct element is Time::TimeRelatedEntities::TimedObservations::TimedObservation

Resolution: Substitution done.
Revised Text: see ptc/2009-05-12 pages 184 - 185
Actions taken:
February 19, 2008: received issue
October 16, 2009: closed issue

Issue 12240: picture 11.8, ports "loc" and "ftp" (marte-ftf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

On picture 11.8, ports "loc" and "ftp" are typed with the type of the interface they require (instead of a classifier requiring the interfaces). Probably the names "loc" and "ftp" are for the ports, but the type is for the (required) interface.

Resolution: The port "loc" and "fp" are defined in Figure 11.18 and not in Figure 11.8. Still, the issue is totally relevant and the Figure 11.18 is updated according to the proposed resolution.
Revised Text: see p[tc/2008-06-05 for revised figure
Actions taken:
February 20, 2008: received issue
February 17, 2010: closed issue

Issue 12242: VSL variable declaration (inconsistency between the BNF and the metamodel) (marte-ftf)

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

Subject: VSL variable declaration (inconsistency between the BNF and the metamodel) Details: The direction of a VSL variable is refered as optional in the metamodel (multiplicity of 0..1) while it is presented as a mandatory term in the BNF. Proposed resolution: Change to BNF to turn variable declaration into an optional term.

Resolution: Proceed with proposal: change the BNF to do direction of variable declaration an optional term.
Revised Text: -In page 402, change the term 'variable-declaration' into: <variable-declaration> ::= [<variable-direction>] '$' <variable-name> [<type-name>] ['=' <init-expression>]
Actions taken:
February 19, 2008: received issue
February 17, 2010: closed issue

Issue 12245: GQAM-SAM cyclic dependency due to GQAM::WorkloadBehavior (marte-ftf)

[SAM] There is a cyclic dependency between packages GQAM and SAM at Domain Model level due to SAM adds an association (workload: EndToEndFlow) in GQAM::WorkloadBehavior. The model needs to be revised. A simple resolution could be to remove the association as far as the owning relationship already exist between WorkloadBehavior and the owned elements of EndToEndFlow (i.e., WorkloadEvent and BehaviorScenario)

Resolution: We decided to proceed with the proposed resolution by the source
Revised Text: see ptc/2009-05-12 pages 186 - 187
Actions taken:
February 28, 2008: received issue
October 16, 2009: closed issue

Issue 12246: Section 16.2.2 (SAM) (marte-ftf)

The first paragraph of page 289 makes reference to 'isSchedulability', which is wrong. The right name is 'isSchedulable'.

Resolution: revise this mistake
Revised Text: -In page 289, replace in the first paragraph 'isSchedulability' with 'isSchedulable'.
Actions taken:
February 28, 2008: received issue
February 17, 2010: closed issue

Issue 12247: page 288: change explanation (marte-ftf)

When explaining the semantics of the stereotype atributes 'EndToEndDeadline' and 'EndToEndTime' of an EndToEndFlow (page 289), it is clarified that these measures apply "only one input end-to-end stimuli exist". However, an end-to-end flow can have several execution end points (e.g., an activity diagram with more than 'one activity end' node). So, it is necessary to precise better the semantics of these two attributes. A resolution could be to add at the end of the first paragraph of page 289 something like: "...stimuli exist and only one finalization Step exists".

Resolution: Proceed with the proposal to clarify semantics.
Revised Text: -At the end of the first paragraph of page 289, add the following phrase: ...stimuli exist "and only one finalization Step exists".
Actions taken:
February 28, 2008: received issue
February 17, 2010: closed issue

Issue 12248: Section: Annex B (VSL) (marte-ftf)

There are the following mistakes in the VSL grammar: obsCallExpression (section B.3.3), instead of obs-call-expression value_specification (section B.3.3.10), instead of value-specification

Resolution: Fix these typos: -Rename obsCallExpression (section B.3.3), by obs-call-expression -Rename value_specification (section B.3.3.10), by value-specification.
Revised Text:
Actions taken:
February 28, 2008: received issue
February 17, 2010: closed issue

Issue 12249: MARTE name prefixes (marte-ftf)

Click here for this issue's archive.
Source: Carleton University (Dr. Murray Woodside, cmw(at)sce.carleton.ca)
Nature: Uncategorized Issue
Severity:
Summary:

There is no consistent convention followed in the beta document for naming of stereotypes and their attributes, and this has been pointed out in other issues. Some chapters use a prefix for the chapter, such as Pa or pa for performance analysis, Grm or grm for General Resource Model, etc. MOst do not. From the point of view of precision, fully qualified names are sufficient, but from the point of view of usability, the prefixes are very helpful, especially as MARTE is such a big profile and realtime is a cross-cutting concern. THat is (unlike sysml) the profile does not redefine UML or restrict it to the domain of realtime, but adds realtime info to a functional design. MARTE may be used with other profiles, possibly several at once. The usability issues are to identify the realtime stereotypes and attributes, and also to avoid cluttering the namespace. A stereotype attribute may become a property of an object and its name might conflict with a functional property. Users might avoid MARTE just to avoid the risk of this happening. Issue: Consistency in prefixes is desirable, either all stereotypes with prefix, or none. Usability is affected. Realtime concerns are pervasive and crosscutting in software, so flooding of the namespace could be a problem, including conflict with other profiles and with functional property names. Proposed resolution: Apply two or three prefixes to all stereotypes and attributes: mm for MARTE Modeling ma for MARTE Analysis possibly mc for MARTE Core. Where a stereotype is specialized from another one, a third letter could be used. Alternative proposal: Apply prefixes only to the analysis chapters, because these are more likely to be used outside the embedded system domain (e.g. for enterprise system QoS) and thus to be used with other stereotypes. For instance to specify requirements on delay.

Resolution: In order to decide when we need to prefix the name of element, we propose to apply the following algorithm as much as possible: - When we define a stereotype which name may conflict with the UML2 metaclass the stereotype is extending. In this case, we prefix with the name of the sub-profile wherein the stereotype is defined. - When we define a stereotype generalizing an already defined stereotype of MARTE. In this case, we should use the name of the profile wherein the stereotype is defined to prefix this latter. - Finally, we should not use "_" between the prefix and the name of the prefix. This rule should apply also for the name of the concepts of the domain model. However, there is an exception to this rule: we will not rename the predefined NFP type (the one define in the MARTE library such as NFP-Real) because they are used all along the specification and the change will need too much work w.r.t. to the global interest to do it. Let's note that, we consider that that as an editorial issue and we will not provide the complete revised text for the resolution because it would be too big. The editor of the specification (Sebastien Gerard) will do the required modifications directly in the specification when integrating all other resolutions voted within this FTF2
Revised Text:
Actions taken:
February 28, 2008: received issue
October 16, 2009: closed issue

Issue 12264: Section: 11.3.2.7 (marte-ftf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Revision
Severity: Minor
Summary:

The stereotype FlowSendAction enable to define an action for sending a data via port. The given textual syntax defined for the label of the action does support that feature. However, the stereotype itself (for the abstract syntax point of view) does not have any property to model that point. Resolution => add an attribute to the stereotype: viaPort: Port [0..1]

Resolution: Disposition: See issue 11839 for disposition
Revised Text:
Actions taken:
March 5, 2008: received issue
October 16, 2009: closed issue

Issue 12282: no link between GRM::SchedulableResource and SRM::SwSchedulableResource (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Eric Maes, eric.maes(at)fr.thalesgroup.com)
Nature: Revision
Severity: Significant
Summary:

There is no link between GRM::SchedulableResource and SRM::SwSchedulableResource ! When modeling, much of SwSchedulableResource elements are also ScedulableResource elements and then, attributes such as host (GRM::SchedulableResource) and scheduler (SRM::SwSchedulableResource) are redundant. SRM::SwSchedulableResource should derive from GRM::SchedulableResource.

Resolution: This is a duplicated issue, explained in Issue 11411. Revised Text: See resolution of Issues 11411, and 11856. Disposition: Duplicated
Revised Text:
Actions taken:
March 17, 2008: received issue
October 16, 2009: closed issue

Issue 12283: TimingObserver in GQAM should be renamed to TimedObserver (marte-ftf)

Click here for this issue's archive.
Source: Carleton University (Dr. Murray Woodside, cmw(at)sce.carleton.ca)
Nature: Uncategorized Issue
Severity:
Summary:

s discussed in the telecon today, the TimingObserver in GQAM should be renamed to TimedObserver, and the text should show that it can collect any measure, including time intyervals but also energy memory etc, over an interval bounded by two events.    This is a separate issue from 11775 which suggests moving this concept to the Time chapter.

Resolution: {The TimedObserver may be extended to return any statistical measure on any NFP over the interval from the startEvent to the EndEvent}
Revised Text: There are five parts: 1. Old text p 265, at the beginning of Section 15.2.3 Timing Observers (Figure 15.4) are conceptual entities that collect timing requirements and predictions related to a pair of user-defined observed events. In this sense, TimingObserver uses Timed Instant Observations (from the Time subprofile) 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 in the figure. Timing observers are a powerful mechanism to annotate and compare timing constraints against timing predictions provided by analysis tools. Timing observers can be used as predefined and parameterized patterns (e.g., latency, jitter) or by means of more elaborate expressions (e.g., written in OCL or VSL) since TimingObserver inherits all the modeling capabilities from NfpConstraint. LatencyObserver specifies a duration observation between startObs and endObs, with a miss ratio assertion (percentage), a utility function which places a value on the duration, and a jitter constraint. Jitter is the difference between maximum and minimum duration. A timing observer may be attached to the start and end observed events, or to a behavior element such as a Step. In the latter case the start and end events are the start and end events for execution of the behavior element. 1. REvised text: TimedObservers (Figure 15.4) are conceptual entities that define requirements and predictions for measures defined on an interval between a pair of user-defined observed events, named startObs and endObs in the figure. A TimedObserver must be extended to define the measure that it collects. The LatencyObserver makes this extension to collect the duration between the two events, and some properties of that duration. Other extensions can be defined to describe power or energy usage, memory usage, etc., over a partial behavior. A TimedObserver uses Timed Instant Observations (from the Time subprofile) to define the start and end events in a given behavioral model. It may express constraints on the defined measure, for instance on the duration between the two time observations. It can use predefined and parameterized patterns (e.g., latency, jitter) or more elaborate expressions (e.g., written in OCL or VSL) since TimedObserver inherits all the modeling capabilities from NfpConstraint. A TimedObserver may be attached to particular start and end observed events, or to a behavior element such as a Step. In the latter case the start and end events are the start and end events for execution of the behavior element. LatencyObserver specifies a duration observation between startObs and endObs, with a miss ratio assertion (percentage), a utility function which places a value on the duration, and a jitter constraint. Jitter is the difference between the maximum and minimum duration. 2. Fig 15.4 is revised by renaming TimingObserver to TimedObserver. 3. Profile Fig 15.8 is revised by renaming gaTimingObserver to gaTimedObs 4. Sec 15.3.2.14 p 281 Old text: 15.3.2.14 GaTimingObserver The GaTimingObs stereotype maps the TimingObserver domain element (section F.10.18) denoted in Annex F. GaTimingObs is a purely conceptual entity that serves to collect timing requirements and predictions that relates to user-defined observed events. In this sense, GaTimingObs uses UML TimeObservations to define the observed event in a given behavioral model. New Text: 15.3.2.14 GaTimedObs The GaTimingObs stereotype maps the TimedObserver domain element (section F.10.18) denoted in Annex F. 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. 5. Appendix 5 section F.10.18 Replace TimingObserver by TimedObs
Actions taken:
March 18, 2008: received issue
February 17, 2010: closed issue

Issue 12297: Section: Annex A3 (marte-ftf)

This section needs to be completed.

Resolution: See issue 12577 for disposition
Revised Text:
Actions taken:
March 19, 2008: received issue
October 16, 2009: closed issue

Issue 12371: MARTE-GQAM) Kinds of delay in a Step (marte-ftf)

Click here for this issue's archive.
Source: Carleton University (Dr. Murray Woodside, cmw(at)sce.carleton.ca)
Nature: Uncategorized Issue
Severity:
Summary:

Generated, based on extensive discussion, to deal with the issue raised in 11882, whose resolution is only for SAM.      There are two kinds of delay in a step  ... self-initiated delays like sleeping or thinking or some latency included in the step,  ... blocked delay waiting for an event initiated by some other thread of behaviour      The latter is represented by the domain concept Step.blockingTime, which is the profile property gaStep.blockT.      The former is not represented. It should be added.      Proposed resolution:      1. In GQAM, add the domain property Step.selfDelayTime:NFP_Duration and the profile property gaStep.selfDelayT:NFP_Duration.      Add text to the domain model to explain selfDelayTime      Add the definition of selfDelayT to the UML representation.      2. In PAM examples, many Steps have internal delay represented as a value of blockT, all of these should be changed to selfDelayT.

Resolution: 1. In GQAM, add the domain property Step.selfDelay:NFP_Duration and the profile property gaStep.selfDelay:NFP_Duration. Add text to the domain model to explain selfDelayTime Add the definition of selfDelay to the UML representation. 2. In PAM examples, many Steps have internal delay represented as a value of blockT, all of these should be changed to selfDelay.
Revised Text: (1) modify domain text: modify last row and add a row to Table 15.1 which defines common NFP attributes for analysis: old last row: col 1: blockingTime: NFP_Duration[*] col 2: blocking time (N/A) col 3: a pure delay which is part of the behavior of the Step or Scenario col 4: N/A modified row: col 1: blockingTime: NFP_Duration[*] col 2: blocking time (N/A) col 3: a pure delay waiting for passive resources to be available or an event controlled from elsewhere (value is an output variable) col 4: N/A additional row: col1: selfDelay: NFP_Duration[*] col2: delay col3: a pure delay controlled or requested by the Step. (value is an input variable) col4: N/A (2) Fig 15.3, add attribute to GaStep class in domain model: selfDelay:NFP_Duration[*] (3) Fig 15.7, add attributes to GaStep class in profile: selfDelay:NFP_Duration[*] (4) Sec. 15.3.2.13, change the UML definitions: old text: � blockT: NFP_Duration [*]: a delay inserted in the execution of the Step. new text: � blockT: NFP_Duration [*] a delay inserted in the execution of the Step, waiting for an event controlled elsewhere (by another step or scenario), or for a condition such as the availability of passive protected resources nedded by the step but in use by preempted (i.e. lower priority schedulableResources) concurrent steps. � selfDelay: NFP_Duration [*] a delay inserted in a Step, whose duration is controlled or requested by the Step (e.g. a sleep time). {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:
April 1, 2008: received issue
February 17, 2010: closed issue

Issue 12401: SendFlowAction and FlowSendAction (marte-ftf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

Two different terms, SendFlowAction and FlowSendAction, are being used for describing the invocation action related to send a data flow to connected components. Example: see figure 11.5 and 11.6 on pages 120 and 121

Resolution: duplicate of issue # 11664, closed issue
Revised Text:
Actions taken:
April 18, 2008: received issue
April 18, 2008: closed issue; Duplicate or Merged

Issue 12402: Specify a maximum number of period for periodic real-time constraints (marte-ftf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Chokri Mraidha, chokri.mraidha(at)cea.fr)
Nature: Enhancement
Severity: Minor
Summary:

It would be nice to be able to specify a maximum number of period for periodic real-time constraints. Proposed modification: add a property named max of type Integer (multiplicity 0..1) in PeriodicPattern tupleType on page 437.

Resolution: Add a new parameter for the periodic arrival pattern indicating the number of occurrences. This parameter is optional: multiplicity 0..1. So, it doesn't need to be specified in the graphical view.
Revised Text: -Modify the library of basic NFP data types, Fig. D-5 by adding a new parameter 'occurrences: NFP_Integer'. (Note that the following figure also add the missing NFP type NFP_Weight: see Issue 12410) -Add to class descriptions of Annex D (see Issue 11554 in Ballot 1 that adds class descriptions for arrival patterns), in Section D.2.3 PeriodicPattern, the attribute: occurrences: NFP_Integer the number of occurrences of the periodic arrival event.
Actions taken:
April 21, 2008: received issue
February 17, 2010: closed issue

Discussion:

see ptc/2008-06-05 for revised figure

Issue 12404: Dispatch protocols (marte-ftf)

Click here for this issue's archive.
Source: THALES (Dr. Madeleine Faugere, madeleine.faugere(at)thalesgroup.com)
Nature: Uncategorized Issue
Severity:
Summary:

Most common dispatch protocols can be modelized by the  ArrivalPattern like (sporadic, aperiodcc,periodic, burst, irregular) ? The possibility to introduce other one is missing (exemple "Background).

Resolution: There is a misunderstanding here. �Background� is not an arrival pattern. The term background is related to task scheduling aspects. In MARTE, periodic server scheduling parameters are modeled with a set of parameters including background priority. In MARTE, we compiled all the arrival patterns used in real-time and embedded systems, including, periodic, aperiodic, sporadic, bursty, but also more general arrivals like irregular patterns for arbitrary distances between event occurrences, probability distributions, and other used in performance evaluation such as open and closed patterns. Additional patterns can be defined by extending the libraries of arrival patterns (Figure D.5) We propose to close this issue with no change.
Revised Text:
Actions taken:
April 22, 2008: received issue
October 16, 2009: closed issue

Issue 12408: Base unit errors in Figure D.3 (marte-ftf)

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

Base unit errors in Figure D.3 The base unit for "KHz", "MHz", "GHz" and "rpm" is "W" while it is expected to be "Hz". The base unit for "mm" is "bits" while it is expected to be "m". The base unit for "um2" is "bits" while it is expected to be "mm2".

Resolution: This issue is a duplicate of issue #11338.
Revised Text:
Actions taken:
April 24, 2008: received issue
April 24, 2008: closed issue; Duplicate or Merged

Issue 12409: ConstraintKind not documented (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

The enumeration ConstraintKind defined in Figure 8.5 is not document in section 8.3.2

Resolution: The description of the Enumeration ConstraintKind is missing
Revised Text: Add the following description as a new Section 8.3.2.1 (p. 38): 8.3.2.1 ConstraintKind ConstraintKind is an enumeration type that defines literals used to specify the nature of constraint assertions by either required, offered, or contract nature. Literals � required It indicates the minimum quantitative or qualitative level that the constrained elements demand (these elements are usually clients of resources). � offered It establishes the space of values that can support a model element (elements in this case are commonly software or hardware resources). � contract It defines conditional expressions that specify relationships between offered and required non-functional values. Disposition: Resolved
Actions taken:
April 24, 2008: received issue
October 16, 2009: closed issue

Issue 12410: Type NFP_Weight does not exist (marte-ftf)

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

HwComponent stereotype has a property named "weight" typed by "NFP_Weight". The type NFP_Weight does not exist in the document.

Resolution: This NFP type was missing in the MARTE library.
Revised Text: -Modify the library of basic NFP data types, Fig. D-5 by adding NFP_Weight (this figure takes into account Issue 12402 too) -Modify the library of measurement units, Figure D-3 with:
Actions taken:
April 24, 2008: received issue
February 17, 2010: closed issue

Discussion:

see ptc/2008-06-05 for revised figures

Issue 12412: "proreq" / "reqpro" literals do not exist in Beta 1 (marte-ftf)

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

"proreq" / "reqpro" literals do not exist anymore in Beta 1. Details: The example in Figure 11.7 refers to a "reqpro" literal that does not exist anymore. In section 11.3.2.4, the constraint [3] refers to a "proreq" literal that does not exist anymore. Proposed resolution: remove references to these literals.

Resolution: See issue 11820 for disposition
Revised Text:
Actions taken:
April 24, 2008: received issue
October 16, 2009: closed issue

Issue 12413: BFeatureSpecification constraint (marte-ftf)

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

In section 11.3.2.2, the constraint [1] is not applicate to BFeatureSpecification (it applies to FlowSpecification, defined in another section of the chapter). Proposed resolution: revise or delete the constraint.

Resolution: This issue actually refers to section 12.3.2.2 (11.3.2.2 refers to the numbering of an older version). This resolution does apply to FlowSpecification and not to ClientServerSpecification. The constraint has then to be moved. A new constraint is added ClientServerSpecification.
Revised Text: P. 137, in the constraint sub-section of the section 12.3.2.2, let's replace "[1] A flow specification owns only properties, it cannot own operation or reception." By ". None.". � P. 142, section 12.3.2.8, add the following constraint: o "[3] A flow specification owns only FlowProperties, i.e. Properties on which the FlowProperty stereotype has been applied. It cannot own neither operations, nor receptions (of signal)." � In section 12.3.2.2, in the �constraints� clause, a new constraint is added: [1] A ClientServerSpecification can only own ClientServerBFeatures, i.e. Operations and/or Receptions on which the ClientServerBFeature stereotype has been applied. It cannot own properties.
Actions taken:
April 24, 2008: received issue
October 16, 2009: closed issue

Issue 12414: Clock stereotype needs to extend UML::Property (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Enhancement
Severity: Significant
Summary:

The Clock stereotype would need to extend UML::Property along with UML::InstanceSpecification, in order to make use of clocks in composite structures and interactions. This way, the Time chapter would be compliant with the "instance/classifier" pattern defined for resources.

Resolution: Property is added as a base class for Clock
Revised Text: Figure 9.26 Old: New: (it is a visio picture) Para 9.3.2 Old: (after solving issue 11847) Extensions � InstanceSpecification (from UML::Classes::Kernel) Generalizations � None New: Extensions � Property (from UML::Classes::Kernel) � InstanceSpecification (from UML::Classes::Kernel) � Generalizations � None Para 9.3.2.1 Clock Old: A Clock is a model element that represents an instance of ClockType. A Clock gives access to time. A Clock exists in a TimedDomain. A Clock maps to a TimeBase in the semantic domain. The stereotype specifies the unit of the Clock. A Clock is also characterized by its resolution, and optionally by its offset (its initial instant value) and its maximal value. The values of these attributes are contained in the slots of the stereotyped InstanceSpecification. New: Add the sentence: A Clock can also be a stereotyped Property, so that it can be used in composite structure and interactions.
Actions taken:
April 24, 2008: received issue
February 17, 2010: closed issue

Discussion:

see ptc/2008-06-05 for revised figures

Issue 12415: Clarify the nature of DRM (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

What is the nature of DRM in the MARTE specification? Details: There is no DRM profile in the description of the architecture of MARTE (Figure 6.4). On the other hand, looking at the first Figure (14.1) of Chapter 14, one can see a DRM package that includes the HRM and SRM packages. That may create confusion on the nature of DRM. We would need to clarify this at the begining of Chapter 14, or update Figure 14.1

Resolution: Delete the figure 14.1 and consequently modify the introduction of the chapter 14. See revised text in the next section that intents to clarify this point.
Revised Text: see ptc/2009-05-12 pages 200 - 201
Actions taken:
April 24, 2008: received issue
October 16, 2009: closed issue

Issue 12416: MARTE needs naming conventions for stereotype names and tag values. (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Revision
Severity: Significant
Summary:

MARTE needs naming conventions for stereotype names and tag values. As discussed during the FTF meeting in DC, we need to define chapter-wide naming conventions for stereotype names and tag values. Consequently, we need to apply these conventions to the whole document.

Resolution: See issue 12249 for disposition
Revised Text:
Actions taken:
April 24, 2008: received issue
October 16, 2009: closed issue

Issue 12417: GQAM Observers: inconsistency between domain view and UML representation (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Revision
Severity: Significant
Summary:

GQAM Observers: inconsistency between domain view and UML representation Details: In the domain view (Figure 15.4), the Timing/TimedObserver has two properties startObs and endObs, typed by MARTE::Time::TimedInstantObservation. In the UML profile diagram (Figure 15.8), the related GaTiming/TimedObserver has two properties startObs and endObs, typed by UML::TimeObservation. In the UML profile description (p.281), the same GaTiming/TimedObserver has two properties startObs and endObs, typed by MARTE::Time::TimedInstantObservation. We need to choose whether a timed observer relates to a MARTE TimedInstantObservation or UML TimeObservation, and then to align the domain view, profile definition and profile description accordingly.

Resolution: In the conceptual domain model, we rely in MARTE "concepts", independently of whatever UML construct. For that reason we use the concept coming from the Time chapter. However, in the profile view, it is permissible to use the UML corresponding metaclass, because there is no reason to constraint such TimedObservers to Observations stereotyped with the MARTE Time concepts. (The time concepts add the notion of clocked Observation (attribute "clock"), which are not essential here). We agreed with Charles Andre that such a stereotype should not be mandatory when defining a TimedObserver.
Revised Text: see ptc/2009-05-12 pages 203 - 204
Actions taken:
April 24, 2008: received issue
October 16, 2009: closed issue

Issue 12418: GQAM Domain view inheritances (marte-ftf)

Click here for this issue's archive.
Source: Universidad de Cantabria (Dr. Julio Medina, julio.medina(at)unican.es)
Nature: Revision
Severity: Critical
Summary:

In the GQAM Domain view GQAM::GQAM_Resources::CommunicationHost should inherit from GRM::ResourceTypes::CommunicationMedia, and GQAM::GQAM_Resources::ExecutionHost should inherit from GRM::ResourceTypes::ComputingResource. This said from a conceptual point of view, seems to indicate that also the corresponding elements in the profile should keep this inheritance relationship with the corresponding elements in GRM. The names of attributes should be consistent or at least related semantically to those in GRM. This may required some minor structural changes since in GQAM platform elements include semantics form various elements in GRM like for example the scheduler as well as the processing resource.

Resolution: Include in GQAM::GQAM_Resources::CommunicationHost the inheritance from GRM::ResourceTypes::CommunicationMedia. And in GQAM::GQAM_Resources::ExecutionHost inheritance from GRM::ResourceTypes::ComputingResource. Correspondingly update the profile, making GQAM::GaExecHost inherit from GRM::ComputingResource, and GQAM::GaCommHost inherit from GRM::CommunicationMedia. According to issue 11835 already resolved in ballot 2, some attributes in GQAM::GaCommHost are now inherited from GRM::CommunicationMedia, these attributes are: o bandwidth: NFP_DataTxRate [0..1] capacity of the communication element when applicable. o packetT: NFP_Duration [0..1] time to transmit the element used as a communication quantum, usually called a packet, the size in bits of this quantum is described by the attribute elementSize. o blockT: NFP_Duration [0..1] time the communicationMedia is blocked and cannot transmit due to the transmission of one communication quantum. o transmMode: MARTE_Library::MARTE_DataTypes::TransmModeKind [0..1] defines the transmission mode, one of the following values: {simplex, half-duplex, full-duplex}. The only difference is in the name of the attribute "bandwith" which is called "capacity" in GQAM. Since both of them represent the same concept one of the two should prevail; "capacity" is preferred as it is more general. As mentioned, this impact previous resolution of issue 11835, and as a duplicated also issue 11842. Attributes schedPolicy and isPreemptible in SaExecutionHost and SaExecHost are now redundant since they are inherited transitively from Scheduler.
Revised Text: (6) In section 15.3.2.4 add generalization o CommunicationMedia (from MARTE::GRM) (7) In section 15.3.2.4 remove the attributes: o capacity: NFP_DataTxRate [0..1] capacity of the communication element when applicable. o packetT: NFP_Duration [0..1] time to transmit the element used as a communication quantum, usually called a packet, the size in bits of this quantum is described by the attribute elementSize. o blockT: NFP_Duration [0..1] time the communicationMedia is blocked and cannot transmit due to the transmission of one communication quantum. o transmMode: MARTE_Library::MARTE_DataTypes::TransmModeKind [0..1] defines the transmission mode, one of the following values: {simplex, half-duplex, full-duplex}. (8) In section 15.3.2.7 add generalization o ComputingResource (from MARTE::GRM) (9) Change Figure 15.9 to show these inheritances as well as those from scheduler introduced in ballot1, and not to show the removed attributes. Use this: (10) In section F10.5 CommunicationHost add generalization o CommunicationMedia (from MARTE::GRM) (11) In section F.10.5 remove attributes: capacity, packetTime, blockingTime, and transmMode (12) In section F.10.8 ExecutionHost add generalization o ComputingResource (from MARTE::GRM) (13) Change Figure 15.5 to show these inheritances as well as those from scheduler introduced in ballot1, and not to show the removed attributes, use this: (14) Consistently with resolution of Issue 11835 change Figure 10.8 to show the attributes capacity, packetTime, blockingTime, and transmMode in the definition of the CommunicationMedia concept, use this: (15) Consistently with resolution of Issue 11835, in the bulleted paragraph aboveFigure 10.8, add a text presenting the attributes: Old Text: As shown in Figure 10.8, two kinds of CommunicationResources are defined. A communication media has an attribute for defining the size of the elements transmitted; as expected, this definition is related to the resource base clock. For example, 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. A communication endpoint acts as a terminal for connecting to a communication media, and it is characterized by the size of the packet handled by the endpoint. This size may or may not correspond to the media element size. New Text: As shown in Figure 10.8, two kinds of CommunicationResources are defined. A communication media has an attribute for defining the size of the elements transmitted; as expected, this definition is related to the resource base clock. For example, 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. It has also an attribute indicating the capacity of the communication element when it is applicable. For timing evaluations, it holds also the time it takes to transmit the element used as a communication quantum, usually called a packet, the size in bits of this quantum is described by the attribute elementSize. It may have also the specification of the time the communicationMedia is blocked and cannot transmit due to the transmission of one communication quantum, and the transmission mode available (simplex, half-duplex, or full-duplex). A communication endpoint acts as a terminal for connecting to a communication media, and it is characterized by the size of the packet handled by the endpoint. This size may or may not correspond to the media element size. (16) Consistently with resolution of Issue 11835 change Figure 10.14 to show the attributes capacity, packetT, blockT, and transmMode in the stereotype CommunicationMedia, use this: (17) In Section 10.3.2.4, on page 101, use "capacity" in this bullet phrase instead of "bandwith", which is the name used in issue 11835: o capacity: NFP_DataTxRate [0..1] capacity of the communication element when applicablelink. (18) Remove attributes schedPolicy and isPreemptible in section 16.3.2.5 (page 300) and in section F.11.5 (page 611), they are inherited from scheduler. (19) Accordingly change figure 16.6 by this: (20) And change Figure 16.9 by this:
Actions taken:
April 25, 2008: received issue
February 17, 2010: closed issue

Discussion:

see ptc/2008-06-05 for revised figures

Issue 12428: wrong multiplicity in sharedResources required for a SaStep (marte-ftf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Julio Medina, nobody)
Nature: Revision
Severity: Significant
Summary:

This might be an editorial issue since it is correct in section F but not in SAM. In the association sharedResource from SaStep to SAM_Resources::SharedResource (see Figure 16.4, page 289 in SAM)change multiplicity from 0..1 to * , This is correct and well explained in the Domain description in Annex F (Section F.11.3 page 609) but Figure 16.4 and the description in sections 16.3.2.3 and probably 16.3.2.8 must be adjusted.

Resolution: The resolution of this issue makes consistent the domain and UML views of SAM in the aspect of sharedResources linked to steps. It complements resolution of Issue 11778 stating consistently that a SaStep may require multiple passive shared resources to be locked during its execution. First it is necessary to change from 0..1 to * the multiplicity in the association sharedResource that exists between SaStep and SAM_Resources::SharedResource in Figure 16.4, page 289 in the domain view of SAM. Then align the profile correspondingly by correcting the pictures in Figure 16.7 or Figure 16.9, and insert the description of the association as it is in Section F.11.3 page 609 in the description of the stereotype SaStep in page 298. In the GRM domain view it is necessary also to change to 0..* the multiplicity of MARTE::GRM::ResourceUsages::ResourceUsage.usedResources so that it may admit incomplete definitions of usages. For consistency it is convenient also to extend the multiplicity of requiredAmount to 0..*.
Revised Text: (21) Modify Figure 16.4, page 289 consistently with the resolution of issue 11778 so that the multiplicity 0..1 in the association sharedResource becomes *: New Figure: (22) Change Figure16.7 with: (23) Consistently with the resolution of Issue 11778, in the associations of SaStep in section 16.3.2.3 use the text : sharedRes: SaSharedResource [*] {subsets GRM::ResourceUsage.usedResources} set of shared resources that will be locked during the execution of this step. (24) Consistently with the resolution of Issue 11778, in the associations of SaStep in section F.11.3 use the text : sharedResource: SharedResource [*] {subsets GRM::ResourceUsages::ResourceUsage. usedResources} set of shared resources that will be locked during the execution of this step. (25) In section F.4.27 (page 526) change to 0..* the multiplicity of MARTE::GRM::ResourceUsages::ResourceUsage.usedResources and MARTE::GRM::ResourceUsages::ResourceUsage.requiredAmount (26) Change Figure 10.13 by this:
Actions taken:
May 6, 2008: received issue
February 17, 2010: closed issue

Discussion:

see ptc/2008-06-05 for revised figures

Issue 12497: TimedDomain stereotype (marte-ftf)

Click here for this issue's archive.
Source: INRIA (Mr. Charles Andre, Charles.ANDRE(at)unice.fr)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Resolution of issue 12414 introduced two base metaclasses for  stereotype Clock (InstanceSpecification and Property).  The TimedDomain stereotype has to be changed to support the case of   Clock being a Property extension.  The OCL rule number 1 has also to be updated.

Resolution: Change the metaclass of TimedDomain from Package to Namespace in Figure 9.26. Also change Extensions of TimedDomain (9.3.2.5). No need to change OCL rule for this issue because there is no ocl rule associated with TimedDomain, but see issue 12498 for indirect change.
Revised Text: see ptc/2009-05-12 pages 205 - 206
Actions taken:
May 16, 2008: received issue
October 16, 2009: closed issue

Issue 12498: OCL rules for the Clock stereotype (marte-ftf)

Click here for this issue's archive.
Source: INRIA (Mr. Charles Andre, Charles.ANDRE(at)unice.fr)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Resolution of issue 12414 introduced two base metaclasses for  stereotype Clock (InstanceSpecification and Property).  The OCL rules [2] has to be changed to deal with both base metaclasses  (The present rule deals only with InstanceSpecification).

Resolution: Distinction has been done in ocl rules according to the base metaclass of Clock. Rule 1 is no longer valid (because change in issue 12497)
Revised Text: see ptc/2009-05-12 pages 207 - 208
Actions taken:
May 16, 2008: received issue
October 16, 2009: closed issue

Issue 12513: wrong numbering of figures (marte-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

p.316, l.13: "Figure 17.5" should be Figure 17.6 p.325, l.7: "Figure 17.8" should be Figure 17.9 p.326, l.1: "Figure 17.9" should be Figure 17.10 These are a part of my MARTE errata. Since I cannot write them all here, I will send the errata file by E-mail to [email protected].

Resolution: withdrawn by submitter
Revised Text:
Actions taken:
May 28, 2008: received issue
October 8, 2008: closed issue

Issue 12514: The tiler stereotype should be applied on the UML::Port metaclass (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Enhancement
Severity: Significant
Summary:

The tiler stereotype should be applied on the UML::Port metaclass. Tilers are currently applicable on connectors and connector ends, along with instances (parts) of a given class. It would be very useful to make use of the same stereotype at a classifier level, in order to define the expected and produced data format at a classifier level. The UML::Port metaclass is a good candidate to carry this stereotype.

Resolution:
Revised Text:
Actions taken:
May 29, 2008: received issue
October 16, 2009: closed issue

Discussion:

The expected and produced data format of a structured class are identified by  the �shaped� stereotype on its ports. The tilers are used to indicate a link  topology, which is completely different. By the way, they are not applicable to  parts, �shaped� is used in this case.  Disposition: Closed, no change

Issue 12536: Inconsistencies in GQAM (marte-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

A number of inconsistencies have been detected in the GQAM subprofile description. The GaScenario stereotype description changes from the domain description section to the UML stereotype description sections (15.2.2.1, 15.3.1 and 15.3.2.12).

Resolution: The differences are mostly in style of expression rather than substance, particularly in a property being expressed as an attribute in a diagram, because it is geometrically awkward to show an association. Attributes and associations are equivalent properties. There are two differences: (b3) timing is correctly represented in Fig 15.3 by an association (b4) timing is missing from the stereotype on p 283, and should be added. (a) GaWorkloadEvent has five properties: in Fig 15.3 in Fig 15.7 in stereotype p 286 � pattern: attrib attrib attrib � generator: assoc attrib attrib � trace: assoc attrib attrib � timeEvent: assoc assoc attrib � effect assoc attrib assoc (proposed in resolution of issue 12538) The textual stereotype is consistent with the meaning of both diagrams, so no change is necessary. (b) The stereotype GaScenario in Figure 15.7 has attributes �cause� and �timing� which are not correctly represented in Fig 15.3 and in the stereotype on p 283. (b1) cause is represented in Fig 15.3 by the association inputStream. This should be changed to cause (b2) cause is not represented in the stereotype at all, it should be added.
Revised Text: (b1) Figure 15.3 p 265 Change the association label inputStream on BehaviourScenario to cause. (b2 and b4) old text p 283 sec 15.3.2.12 Attributes � hostDemand: NFP_Duration [*] the cpu demand in units of time, if all Steps are on the same host. (list continues, ending with...) � root: GaStep [0..1] the first Step of the scenario. new text adds an item at the beginning and the end of the list of Attributes Feb 27 09, a description added for the timing attribute, shown in red (Woodside) Attributes � cause: GaWorkloadEvent the event stream which triggers the scenario � hostDemand: NFP_Duration [*] the cpu demand in units of time, if all Steps are on the same host. (list items, ending with � root: GaStep [0..1] the first Step of the scenario. � timing: GaTimingObserver[*] timing observers associated with this scenario.
Actions taken:
June 19, 2008: received issue
October 16, 2009: closed issue

Issue 12537: figure 10.18 (marte-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

We have detected a difference between domain analysis "ResorceUsage" concept, the stereotype diagram in figure 10.18 and the stereotype description in 10.3.2.13. The association between ResourceUsage and Resource is unidirectional according to figure 10.13 and sections 10.3.2.12 and 10.3.2.13; however in figure 10.18 this association is shown as bidirectional.

Resolution: The UML representation for resourceUsage maps the domain view in a more practical way. However, the navigability from resource to resourceUsage might be removed in Figure 10.18 to be consistent with the definition of resource (section 10.3.2.12) which is agnostic with respect to its usages.
Revised Text: see ptc/2009-05-12 pages 212 - 213
Actions taken:
June 19, 2008: received issue
October 16, 2009: closed issue

Discussion:

Issue 12538: Errors in definition of GaEventTrace and GaWorkloadEvent (marte-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Errors in definition of GaEventTrace and GaWorkloadEvent. In page 275, the stereotype <<GaEventTrace>> has an association defined as "stream" which does not appera in figure 15.7. Moreover no multipicity is defined for such association. In page 271, in figure 15.7 stereotype <<GaWorkloadEvent>> a property called "effect" can be read; however the semantics behind this property cannot be found anywhere, nor in page 282 nor in the domain description (section 15.2).

Resolution: (a) This association is handled differently in Fig 15.7: GaWorkloadEvent has an attribute trace of type GaEventTrace, with default multiplicity 1. Thus the stream association can be removed from GaEventTrace. (b) There are two problems identified here. (b1) GaWorkloadEvent has an association effect:GaScenario in Fig 15.3, and also in Figure 15.7, with default multiplicity 1. This should be represented in the stereotype on p 286. If it is stated as an association then the constraint among the other four attributes is still correct. (b2) in Figure 15.7, GaWorkloadEvent is lacking the attribute timeEvent:UML::timeEvent[0..1] which is shown in the stereotype on p 286, it should be added to the figure.
Revised Text: see ptc/2009-05-12 pages 214 - 216
Actions taken:
June 20, 2008: received issue
October 16, 2009: closed issue

Issue 12561: Section: Annex D.2 (marte-ftf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

We have found that the current format for modelling probability distributions is not very good is some cases. For example, it is hard to model correctly the probability distribution related to a SporadicPattern. We propose that distributions are modelled as a ProbabilityDistribution <<choice_type>> element, with each probability distribution modelled as a <<tuple_type>> element each with the parameters needed (e.g. Uniform <<tuple_type>> should have 2 parameters: a min:NFP_Real and max:NFP_Real).

Resolution: There is a misunderstanding in the way MARTE deals with probability distribution expressions. This is, in any case, a weak aspect in the description of such specification mechanism in MARTE. This resolution proposes to clarify this aspect, by adding an example in the NFP chapter and by making explicit the list of distributions in Annex D. In addition, this issue proposes to complete the textual description of all the NfpTypes included in the library MARTE_NfpTypes. Issue Dependency Warning: Note that the texts and figures provided in this issue depend on Issue 12196, which proposes new probability distributions. Thus, if Issue 12196 is not accepted, these new probability distributions need to be removed from the texts and figures proposed in this issue.
Revised Text: see ptc/2009-05-12 pages 217 - 222
Actions taken:
July 3, 2008: received issue
October 16, 2009: closed issue

Issue 12577: Annex 3 (marte-ftf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Revision
Severity: Significant
Summary:

This annex is not complete. It needs to be finalized and updated according to the EAST-ADL2 language

Resolution: This resolution provides a revised text that completes Annex 3.
Revised Text: see ptc/2009-05-12 pages 223 - 241
Actions taken:
July 17, 2008: received issue
October 16, 2009: closed issue

Issue 12578: MARTE Beta: 12.3.2.4 FlowBFeature issue # 1 (marte-ftf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:

the description says: �A FlowBFeature specifies the nature of a BehavioralFeature� and it lists BehavioralFeature in the Extensions section, yet in figure 12.6 it is shown extending Property

Resolution: See issue 11820 for disposition
Revised Text:
Actions taken:
July 17, 2008: received issue
October 16, 2009: closed issue

Issue 12579: MARTE Beta: 12.3.2.4 FlowBFeature issue # 2 (marte-ftf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:

why is it called a �FlowBFeature� at all � what does it have to with Flows?

Resolution: See issue 11820 for disposition
Revised Text:
Actions taken:
July 17, 2008: received issue
October 16, 2009: closed issue

Issue 12585: Missing illustration for "Shape" and "reshape" stereotype (marte-ftf)

Click here for this issue's archive.
Source: THALES (Dr. Laurent Rioux, laurent.rioux(at)thalesgroup.com)
Nature: Clarification
Severity: Significant
Summary:

Missing illustration for "Shape" and "reshape" stereotype Need clarification inside the "Shape" and "Reshape" definition explanation

Resolution: Add an example of these two stereotypes in action at the end of the chapter.
Revised Text: see ptc/2009-05-12 pages 244 - 245
Actions taken:
July 23, 2008: received issue
October 16, 2009: closed issue

Issue 12588: typos in section E.3.2 (marte-ftf)

Click here for this issue's archive.
Source: THALES (Dr. Laurent Rioux, laurent.rioux(at)thalesgroup.com)
Nature: Uncategorized Issue
Severity: Minor
Summary:

Typo issues: the links to pages are not good for example: defaultlink is not defined in page 414 (as mentionned) but in page 475 (figure E3). it is the same for all definitions (distribute, inter -repetition ...) in this annexe, please check all pages refered in the text

Resolution: Check all cross references. This editing work has to be done after no page number can change or all the cross references have to be made active (preferred solution).
Revised Text:
Actions taken:
July 25, 2008: received issue
October 16, 2009: closed issue

Issue 12776: HRM, fig 14-70, the stereotype HwMedia extends UML::Connector (marte-ftf)

In HRM, fig 14-70, the stereotype HwMedia extends UML::Connector. This extension is not needed as long as its parent GRM::CommunicationMedia already extends UML::Connector.

Resolution: Modifications should be done to delete this redundancy (see next proposition of revised text).
Revised Text: see ptc/2009-05-12 - pages 247 - 248
Actions taken:
August 18, 2008: received issue
October 16, 2009: closed issue

Issue 12777: MARTE profile-library interdependency should be revised and enhanced (marte-ftf)

MARTE profile-library interdependency should be revised and enhanced to ease implementation. Particularly, the MARTE primitive types packages should be used (imported) by the whole MARTE profile and MARTE Libraries. Currently, this aspect is not clear enough, and some parts use UML primitive types while others MARTE primitive types. In addition, establishing well-defined high level packages would help avoiding circular dependencies. For example, MARTE data types library use NFPs and VSL profiles, but MARTE defines NFPs profile in a high level package called Foundations, which has other internal packages that import the MARTE data types libraries. A better grouping criteria should remove interdependencies when implementing MARTE.

Resolution: This issue requires an important restructuring of MARTE. We propose to defer it to the RTF Disposition: Deferred
Revised Text:
Actions taken:
August 18, 2008: received issue
October 16, 2009: closed issue

Issue 12778: property 'msgSize' in figure 15-7 (marte-ftf)

In Fig 15-7, we notice that GaCommStep has the property 'msgSize'. However, this property already exist in its parent Stereotype 'ResourceUsage'. Hence, the property exists twice in GaCommStep. One of them should be removed.

Resolution: I t should be removed from CommStep. The property concurRes is also inherited from Step and can be removed from CommStep in fig 15.7
Revised Text: see ptc/2009-05-12 pages 250 - 251
Actions taken:
August 18, 2008: received issue
October 16, 2009: closed issue

Issue 12779: ordered association "subUsages" (marte-ftf)

In page 107, ResourceUsage has an ordered association "subUsages", but Fig 10-18 doesn't reflect this feature (ordered). As far as I understand the semantics of the association, the isOrdered meta-attribute is not relevant here.

Resolution: Add the {ordered} quality to the subUsages association depicted in Figure 10.18
Revised Text: see ptc/2009-05-12 page 252
Actions taken:
August 18, 2008: received issue
October 16, 2009: closed issue

Discussion:

The ordered quality of this association is required since, according to the restrictions  written for a usage the order is used to match resources with subUsages.

Issue 12780: Fig 15-7 shows that GaCommStep has the property (marte-ftf)

Fig 15-7 shows that GaCommStep has the property "concurRes: SchedulableResource". However; it is not necessary, as far as its parent GaStep already has the same property

Resolution: This has already been resolved during the resolution of issue 12778 in a previous ballot (the attribute msgSize was also defined unnecessarily) . Disposition: Closed, no change
Revised Text:
Actions taken:
August 18, 2008: received issue
October 16, 2009: closed issue

Issue 12796: rteConnector concept (marte-ftf)

Click here for this issue's archive.
Source: Fundacion Tecnalia Research and Innovation (Mr. Huascar Espinoza Ph.D., Huascar.Espinoza(at)tecnalia.com)
Nature:
Severity:
Summary:

Issue 11835 in the MARTE FTF 1 removed the rteConnector concept from the domain model of HLAM. However, the element (rteConnector) was not removed from the Profile (UML View) part.

Resolution: This resolution proposes to remove Figure 13.13, page 156. The RteConnector stereotype doesn�t exist anymore.
Revised Text: Remove Figure 13.13, page 156.
Actions taken:
August 28, 2008: received issue
October 16, 2009: closed issue

Issue 12797: What about a System Configuration concept having a set of OperationalModes? (marte-ftf)

The operationalModes association end from rtUnit to rtBehavior has a multiplicity 0..1. This is not enough to model the OperationalMode as understood by fault-tolerance theory. An rtUnit should be capable to have many operationalModes. In addition, an OperationlMode would be need to be defined at system level too (not rtUnit level only). It seems that a separated stereotype (not rtBehavior as currently) would be necessary for OperationalMode. What about a System Configuration concept having a set of OperationalModes?

Resolution: The concept of Mode (or Operational Mode) is central in embedded systems and in dependable embedded systems in particular. Having this concept only as an attribute of the RtUnit concept is indeed insufficient to model the behavioural and structural aspects of mode sensitive architectures. An operational mode can represent different things: - An operational system (or subsystem) state that is managed by reconfiguration mechanisms (e.g., fault-tolerance management middleware) according to fault conditions. - A state of system operation with a given level of QoS that can be handled by resource management infrastructures (e.g., middleware that assign resources at run time according to load demand, timing constraints, or resource usage). - A phase of a system operation e.g., starting, stopping, reconfiguring switchers, in a supervisory control system of an electric grid. We propose to adopt a number of minimum concepts to describe operational modes and their dynamics with UML state machines. Please notice that a UML state machine may be used �as is� to model operational modes and their dynamics. However, the need to unambiguously distinguish modal state machines, specifying the kind of above-mentioned macro-states, from other standard state machines, motivated us for explicitly describing these concepts in the MARTE specification. Furthermore, it seems necessary to characterize certain MARTE concepts with �modal� information. For instance, defining which entities are active in a given mode, specifying how entities behave in a mode transition, or determining what NFP values are valid in a given mode, all require means to refer to the entities proposed in this resolution. This resolution proposes to define this set of concepts related to operational modes in the �Core Elements� chapter. A number of updates are also proposed in other MARTE chapters to refer to the concepts added in �Core Elements�.
Revised Text: see ptc/2009-05-12 pages 256 - 272
Actions taken:
August 28, 2008: received issue
October 16, 2009: closed issue

Issue 12798: check UML 2.2 modifications impacts on MARTE Metamodel and definitions (marte-ftf)

Click here for this issue's archive.
Source: THALES (Dr. Laurent Rioux, laurent.rioux(at)thalesgroup.com)
Nature: Clarification
Severity: Significant
Summary:

Aligment of MARTE to UML 2.2 metamodel to solve it: check UML 2.2 modifications impacts on MARTE Metamodel and definitions

Resolution: This is a too much general issue! However, I (S�bastien G�rard) am thinking that a priori everything is ok w.r.t. that alignment issue, i.e. every MARTE construct should be compatible with the UML2.2 metamodel. Disposition: Closed, no change
Revised Text:
Actions taken:
September 2, 2008: received issue
October 16, 2009: closed issue

Discussion:

Issue 12799: MARTE aligment with SYSML 1.1 (marte-ftf)

Click here for this issue's archive.
Source: THALES (Dr. Laurent Rioux, laurent.rioux(at)thalesgroup.com)
Nature: Clarification
Severity: Significant
Summary:

MARTE aligment with SYSML 1.1 SysML has been evolved since the MARTE adoption. MARTE metamodel needs to be align with the SysML metamodel To solve it: check the SysML 1.1 metamodel and MARTE metamodel and align Metamodel / definition according to SysML evolutions

Resolution: This proposal is too general. Moreover, let's notice that there are issues related this subject but focus on specific points (e.g., both issues 11871 and 11872) that have been resolved and that enable to align MARTE and SysML. Disposition: Closed, no change
Revised Text:
Actions taken:
September 2, 2008: received issue
October 16, 2009: closed issue

Issue 12801: Clarification in chapter "General Component Model" needed (marte-ftf)

Click here for this issue's archive.
Source: THALES (Dr. Madeleine Faugere, madeleine.faugere(at)thalesgroup.com)
Nature: Uncategorized Issue
Severity:
Summary:

In chapter "General Component Model", please clarify the semantical difference between an atomic flow port typed by a Signal and an atomic MessagePort typed by a signal

Resolution: See issue 11820 for disposition
Revised Text:
Actions taken:
September 3, 2008: received issue
October 16, 2009: closed issue

Issue 12802: clarify the semantical difference between an UML "Port" and a MARTE "Messag (marte-ftf)

Click here for this issue's archive.
Source: THALES (Dr. Madeleine Faugere, madeleine.faugere(at)thalesgroup.com)
Nature: Uncategorized Issue
Severity:
Summary:

In chapter "Generic Component Model", please clarify the semantical difference between an UML "Port" and a MARTE "MessagePort".

Resolution: See issue 11820 for disposition
Revised Text:
Actions taken:
September 3, 2008: received issue
October 16, 2009: closed issue

Discussion:

Issue 12861: concrete syntax (marte-ftf)

Click here for this issue's archive.
Source: INRIA (Dr. Frederic Mallet, Frederic.Mallet(at)inria.fr)
Nature: Enhancement
Severity: Significant
Summary:

Section 9 proposes some stereotypes to identify clocks and clock constraints. Annex C proposes a non-normative language (CCSL) to describe clock constraints. Even though CCSL is non normative (to give more freedom to tool vendors for implementation), such a constraint language must have some specific characteristics. For instance, it MUST allows description of both synchronous and asynchronous constraints. Hence, the normative part (Section 9) should provide a mechanism to identify the nature (synchronous, asynchronous, mixted) of the constraint even if the concrete syntax remains non-normative and described in Annex C. This would give some kind of consistency between different implementations.

Resolution: The resolution proposes to add three meta-attributes to the stereotype ClockConstraint to reflect the domain view (CoincidenceRelation and PrecedenceRelation described in Figure 9.5) and identify the nature of the constraint.
Revised Text: see ptc/2009-05-12 pages 277 - 278
Actions taken:
September 25, 2008: received issue
October 16, 2009: closed issue

Issue 12862: NFP_Type (marte-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

The priority of a FixedPriorityParameter to attach to a SchedulableResource must be of an NFP_Priority type in order to handle it from tools that deal with VSL and parametric descriptions. This is also the case of the priorityCeiling of a MutualExclusionResource. It is convenient to clarified or indicated how to specify the preemption level of the SchedulableResources by means of its scheduling parameters when the StackBasedProtocol is used. If the priority is used for that it should be stated, If an additional parameter is included, then its type should be also an NFP_Type

Resolution: In order to handle them from tools that deal with VSL and parametric descriptions the most useful type for priority and ceiling is clearly NFP_Integer, it seems that the use of Integer instead has been just a typo, and it is easy to solve with no harmful implications. For simplicity on the one hand, and for the co-existence of both protocols in a combined EDF-FP platform on the other hand, it is convenient to use the Ceiling attribute to hold both, the priorityCeiling and the preemptionLevel of a mutualExclusionResource under the priorityCeiling and StackBased protection protocols respectively. Since both may be handled with an NFP_Integer type, the restriction already stated in the explanation of the ceiling attribute (section 10.3.2.9 page 104) is applicable also. This is the case for some other values using integer types in GRM, so a consistent modification of them is worth doing.
Revised Text: see ptc/2009-05-12 pages 279 - 284
Actions taken:
September 26, 2008: received issue
October 16, 2009: closed issue

Issue 12863: definition of ResourceUsage (F.4.27) in annex F (marte-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Editorial Issues: - The definition of ResourceUsage (F.4.27) in annex F is apparently confused (copy/paste) with the one of UsageDemand. - The definition of timingRes in F.11.5 is not the correct one - Shouldnt it be SourceKind in Anex F. - In F.4.7 the new attributes of CommunicationMedia have been inserted in CommunicationEndpoint - F.10.3 the generalizations are missing.

Resolution: Ok for items 1, 2, 4 and 5. Item 3 has no meaning. See following revised text.
Revised Text: see ptc/2009-05-12 pages 285 - 286
Actions taken:
September 26, 2008: received issue
October 16, 2009: closed issue

Issue 12864: Figure 16.6: multiplicity (marte-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Figure 16.6: multiplicity for the host of a SchedulableResource shoudnt it be 1 - In the example (Figure 16.13), the SchedulableResources associated to SaCommHost, Shouldnt they be CommunicationChannels? - The constraints in 10.3.2.16 (SecondaryScheduler) should be also in its domin concept defined in annex F. - It is not clear the relationship between the clockOverhead of a SaExecutionHost and the TimingResources associated

Resolution: Figure 10.11, �The Scheduling Package� expresses that a SchedulableResource has at most one host. While a resource could be scheduled by two or hosts, management of such distributed scheduling is beyond the original intent. Figure 16.6 should be corrected to show the host role to be of multiplicity 0..1. - We agree that the schedulable entities allocated to the SaCommHost CAN Bus should be CommunicationChannels. - The SecondaryScheduler is described in F.4.33. The mentioned constraint should be added. - clockOverhead is only cited as an Attribute of an ExecutionHost and no explanation is provided. The purpose of the Attribute should be described.
Revised Text: see ptc/2009-05-12 pages 287 - 290
Actions taken:
September 26, 2008: received issue
October 16, 2009: closed issue

Issue 12865: Section: GQAM-SAM-PAM (marte-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:

The attributes CommTxOvh and CommRcvOvh in a GQAM:ExecutionHost (F.10.8) limit comunication of a host to only one network/protocol. In fact the overhead due to communication maight be very dificultly expressed by simply a duration...

Resolution:
Revised Text:
Actions taken:
September 26, 2008: received issue
October 16, 2009: closed issue

Discussion:

This is a misunderstanding. Communications overhead is not included in GQAM,  but is included in PAM (chapter 17)  The CommTxOvh and CommRcvOvh parameters are only a simplified way to  express comunications behaviour and overheads. The alternatives as explained  in Section 17.2.2.6 also include  (1) describing a communications layer separately and invoking it as an �external  operation� (i.e. defined separately). The protocol with its overheads and sources  of delay can be described at any level of detail there.  (2) describing a communications layer, similarly but tied more firmly to the layer  objects and structure  (3) describing the delays by a behaviour scenario  Examples are given in chapter 17.  For SAM, since timing is critical the communications process can be described in  full as a subsystem. SACommStep includes only summary properties of an  abstract view of communications delay, for situations where that is appropriate.  Thus there are facilities for the desired modeling. They may not be perfect but  they provide considerable power.  Disposition: Closed, no change

Issue 12867: Figure12.4 is wrong (marte-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:

Editorial Issues: - Figure12.4 is wrong, association signal in the SignalSpecification should be of type SignalFeature instead of ServiceFeature. - In annex F there are many incomplete definitions, see F.6.16, F.6.18, F.6.19). F.6.15 and F.6.20 are not mapped, is this correct? - Pg 137 it should say Figure 12.7 (it says 12.17) - Pg 144 it should say Figure 12.15 (it says 12.5), in pg 145 the same for Figure 12.6

Resolution: See issue 13125 for disposition
Revised Text:
Actions taken:
September 26, 2008: received issue
October 16, 2009: closed issue

Issue 12868: Section: Annex D (marte-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

D.2.2 (ArrivalPattern), it says sporadic: Aperiodic, should it be sporadic:Sporadic (pg 452). - In BurstPattern (D.2.6)minEventInterval is repeted twice. The difinitions in this class should be more explicit to better understand it. Shouldnt it be minEventInterval: NFP_Duration [0..1] the minimum interval between two occurrences OF a burst? it says within a burst. Isn't it what it is said by minInterarrival ?

Resolution: This issue points two mistakes and additionally requests for some description enhancements. This resolution proposes to revise the text as described below
Revised Text: see ptc/2009-05-12 pages 293 - 294
Actions taken:
September 26, 2008: received issue
October 16, 2009: closed issue

Issue 12869: Figure 13.1 (pg 149) (marte-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Figure 13.1 (pg 149) the dependency of CoreElements is repeated twice. Revise the text: �the HLAM package of MARTE is depending of both GRM and CoreElements packages, but also on the CoreElements package� - figure 13.13 should be removed(since RTConnector has been eliminated) - The references to figures in the example seem wrong.

Resolution: One of the related dependencies in Figure 13.1 should be to the package MARTE::GeneralComponentModel. However, when referring to the HLAM element that depends on this package, we realized that the concrete domain model element from MARTE::GeneralComponentModel used in MARTE::HLAM, �ComponentService�, it doesn�t exist anymore (see Fig. 13.5, page 152,). Hence, this resolution proposes to remove one of the dependencies with MARTE::CoreElements in Figure 13.1, and remove all the references to the ComponentService domain model element in HLAM.
Revised Text: see ptc/2009-05-12 pages 295 - 296
Actions taken:
September 26, 2008: received issue
October 16, 2009: closed issue

Issue 12954: inconsistencies in the HLAM subprofile (marte-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Several inconsistencies in the HLAM subprofile: 1- In figure 3.10 the stereotype <<RtFeature>> is displayed as <<Rtf>>. Later in section 13.3.2.8 is shown again as <<RtFeature>> 2- In section 13.3.2.8 the stereotype <<RtFeature>> is said to extend the UML Behavior element; however in section 3.10 this extension is not shown. 3- Figure 3.11 does not show all the attributes of the <<RtAction>> stereotype. 4- The use of the stereotype <<RtBehavior>> is not clear. An example in 13.4 would be of great help.

Resolution: See issue 11838 for disposition
Revised Text:
Actions taken:
October 13, 2008: received issue
October 16, 2009: closed issue

Issue 13084: MARTE/RSM/generalization of the reshape stereotype (marte-ftf)

Click here for this issue's archive.
Source: INRIA (Mr. Pierre Boulet, Pierre.Boulet(at)lifl.fr)
Nature: Uncategorized Issue
Severity:
Summary:

To be conform to the metamodel and extend the applicability of the  reshape stereotype, it should be possible to apply it to other kinds or  links than just allocations or connectors.

Resolution: It is not clear if that would be really useful. If some need appears in the future, reraise the issue. Disposition: Closed, no change
Revised Text:
Actions taken:
September 26, 2008: received issue
October 16, 2009: closed issue

Issue 13085: MARTE/RSM/repetition index port missing (marte-ftf)

Click here for this issue's archive.
Source: INRIA (Mr. Pierre Boulet, Pierre.Boulet(at)lifl.fr)
Nature: Uncategorized Issue
Severity:
Summary:

In the RSM chapter, the repetition index should be visible by a shaped  component so that its behavior can depend on this index. A possible  solution could be a tagged value referencing a port of this component.

Resolution:
Revised Text:
Actions taken:
September 26, 2008: received issue
October 16, 2009: closed issue

Discussion:

That would certainly be useful but it needs more research to find the best solution  to do that.  Disposition: Closed, no change

Issue 13087: MARTE/annexe E/ "No MultiplicityElement owner in the metamodel" bug (marte-ftf)

Click here for this issue's archive.
Source: INRIA (Mr. Pierre Boulet, Pierre.Boulet(at)lifl.fr)
Nature: Uncategorized Issue
Severity:
Summary:

With the MARTE metamodel it can not be specified to which element a   MultiplicityElement refers. In this context, the multiplicityElement can   not be attached to any element and thus cannot be used.

Resolution: MultiplicityElement has been modified in the context of the issue 13089. Consequently, this issue becomes no more valid. Disposition: See issue 13089 for disposition
Revised Text:
Actions taken:
September 26, 2008: received issue
October 16, 2009: closed issue

Discussion:

Issue 13089: MARTE/section 12.2/ "No assemblyConnectorEnd in the Metamodel" bug (marte-ftf)

Click here for this issue's archive.
Source: INRIA (Mr. Pierre Boulet, Pierre.Boulet(at)lifl.fr)
Nature: Uncategorized Issue
Severity:
Summary:

Assembly connector End can not be manipulated in the metamodel. Wheras   it is important to have the relashionship between the Assembly connector   end and the port and from the Assembly Connector to the Port.

Resolution: The resolution to this issue implies to introduce a ConnectorEnd class in the domain model (cf. #1). To mimic the structure of the UML2 metamodel, the ConnectorEnd domain class must have a generalization relationship with the MultiplicityElement domain class. MultiplicityElement is only defined in the Marte::RSM::Shape (which is basically a uml MultiplicityElement with a Shape). So, issue 13089 hides other fundamental issues: MultiplicityElement should be defined in Marte::CoreElements::Foundations #2 (and extended through package merge in Marte::RSM::Shape #3. Note that in the foundations, Property should also have a generalization relationship with MultiplicityElement #4
Revised Text: see ptc/2009-05-12 pages 301 - 305
Actions taken:
September 26, 2008: received issue
October 16, 2009: closed issue

Issue 13124: GCM Classes Description in Annex should be revised: (marte-ftf)

GCM Classes Description in Annex should be revised: 1) BFeatureSpecification has not been included, although it exists in the Metamodel. 2) The "BfeatureAction" name is used in place of "BFeatureKind". 3) Descriptions of MessagePort attributes are not sufficiently detailed. While the Stereotype description section provides some key semantic description, it is not provided in Domain Class description. Particularly, this is the case for the attribute: "isConjugated". 4)SignalPort does not exist anymore in the domain model, but it is included in the Class Description.

Resolution: See issue 13125 for disposition
Revised Text:
Actions taken:
November 25, 2008: received issue
October 16, 2009: closed issue

Issue 13125: In GCM, domain model and profile do not match in ways that are not fully documented (marte-ftf)

In GCM, domain model and profile does not match in ways that are not fully documented. Although this may be acceptable when domain concepts map directly to UML concepts (no stereotype assigned), or when some syntactic sugar are added at UML profile level. However, it is not clear why the attributes: "direction: DirectionKind" and "kind: BFeatureKind" appear in some domain entities (FlowProperty) and in others not (FlowSpecification, ServiceSpecification, ServiceFeature, SignalSpecificatio, SignalFeature), while in the Profile they are used in all these entities.

Resolution: This issue is related to alignment problems between the UML view and the domain view of the GCM (as well as issues 12867 and 13124, which are set to duplicate/merge because they are treated here). Issues 11820 and 13407 are related to problems with the UML view of the GCM, and they have been treated before this issue 13125. So, the revised text of this resolution is made to be consistent with resolutions 11820 and 13407. However, note that the revised text proposed here does not result in a �one to one� alignment. Indeed, let's remain that the domain view is intended to describe the specification of the specific modeling language, whereas the UML view (the UML profile itself) is a real design model of the domain model. They are not to be considered at the level of abstraction, and then their concepts do not have to map one-per-one. The intend of the GCM domain model, and in fact of all other domain models denoted in the AMRTE specification, are proposed to depict what is essential for the understanding of the GCM, and its underlying causality model (described in section 12.2.2 of the revised text).
Revised Text: see ptc/2009-05-12 pages 307 - 327
Actions taken:
November 25, 2008: received issue
October 16, 2009: closed issue

Issue 13126: using a simple Dependency to model an allocation relationship doesn't match with the allocation concept MARTE defines (marte-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

From my point of view using a simple Dependency to model an allocation relationship doesn't match with the allocation concept MARTE defines in its "Domain view", �11.2, p117. According to this domain view, it's clear that creating an allocation doesn't create any dependency between allocation ends, what is actually what we need in MDA like approaches where applications and plateforms are considered to be independant. However, the official definition of the UML "Dependency" metaclass states that : "A dependency is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation. " (formal/2007-11-02 , �7.3.12, p62, unchanged in v2.2 beta 1) Then, I suggest to change the UML representation of the allocation concept so that it really complies to the domain view, that is : if an element of one end of the allocation is modified only the allocation itself should be impacted and not the elements(s) on the other end. It's can be achieved, for instance, by the specialization of the Classifier metaclass, instead of the Dependency metaclass

Resolution: Allocation is meant to be very general. Application elements are allocated to an execution platform (software or hardware), functionality is allocated to processes, processes are allocated to a virtual machine, and resources may be allocated to resource pools, just for some examples. What allocation is doing in these cases is imposing structure on a less structured system. For generality, alternative allocations should be possible. If only a single allocation is possible then the potential of MDE is thrown away. In particular, allocation does not always imply a dependency. Moreover, when a dependency is created, the client of this dependency is modified to refer to the dependency. This can be a problem when allocating read_only elements. The metaclasses Relationship or DirectedRelationship fit better. However, these metaclasses are abstract and there is currently no concrete specialization in UML that would not induced a specific semantics compatible with the broad acception of allocation intended in MARTE. Consequently, the issue should be solved in UML by introducing a new metaclass. It should be discussed with the SysML community given the relationship explicitly stated in the MARTE specification between the MARTE allocation and its SysML counterpart. However, to have an short term solution, we have decided to propose something that is not entirely satisfactory but would work with read_only elements, be usable in very general cases, require few tool adaptations and would have a minimal impact on SysML, with which we want to maintain compatibilities. This is done by adding the stereotype Assign that extends the metaclass Comment, while preserving the stereotype Allocate to maintain compatibility with the current SysML approach. The Assign stereotype is an alternative UML representation of the Allocation metaclass, defined in the domain model, but without the underlying semantics of the Abstraction metaclass. Note that the optional body property of the Comment meta-class can be used to provide the justification of the assignment
Revised Text: see ptc/2009-05-12 pages 329 - 333
Actions taken:
November 26, 2008: received issue
October 16, 2009: closed issue

Issue 13341: The dependency between NFP and VSL is not necessary (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Revision
Severity: Significant
Summary:

Currently the domain view and the UML representation of NFP rely on VSL constructs which specialize UML ones (ValueSpecification, Datatype). This dependency is a limitation to the modularity of MARTE (e.g. one might be willing to use NFP with another expression language). Proposed resolution: 1) In the domain model, replace references to MARTE::VSL::ValueSpecification by UML::ValueSpecification (starting by page 35). 2) In the domain model, replace references to MARTE::VSL::TupleType by UML::DataType (starting by page 38) 3) In the UML representation, remove the generalization link between TupleType and NFPType (starting by page 38) 4) In the chapter overview, remove the dependency link between NFP and VSL

Resolution: The dependency of Domain Models on the VSL Domain Model does not affect the modularity of MARTE. On contrast, having a cohesive integration of Value Specification concepts from VSL with the other chapters is a must regarding the comprehensibility of MARTE. The only design constraint in MARTE was to do VSL independent of other MARTE specific chapter, because we had in mind to use VSL together with other profiles (e.g., SysML). This level of dependency has been achieved as VSL doesn�t import other MARTE packages. Note that there are many MARTE chapters that reuse VSL concepts: CoreElements, Time, RSM, and having also NFP importing VSL is not a real problem. For these reasons, we propose to close this issue without change. Disposition: Closed No Change
Revised Text:
Actions taken:
January 26, 2009: received issue
October 16, 2009: closed issue

Issue 13349: ARINC 653 Annex of MARTE (marte-ftf)

Click here for this issue's archive.
Source: THALES (Dr. Laurent Rioux, laurent.rioux(at)thalesgroup.com)
Nature: Enhancement
Severity: Significant
Summary:

The ARINC 653 Annex of MARTE is not strictly compliant with the ARINC 653 resolution: Update the API with the ARINC 653 Ada API

Resolution: New ARINC 653 API model has been provided and complementary text to explain ARINC 653 Service API
Revised Text: see ptc/2009-05-12 pages 335 - 342
Actions taken:
January 27, 2009: received issue
October 16, 2009: closed issue

Issue 13400: The notion of value is missing the NFP_Declaration domain model Description (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com)
Nature: Clarification
Severity: Significant
Summary:

The current NFP_Declaration package of the NFP domain model introduces the notion of NFP and NFPType. However, it is missing a relation between these concepts of non-functional property and the concepts of physical quantity and value (expressed in SysML by Value Property / Value Type). One can consider a non-functional property as a kind of physical quantity. These links need to be explicitly stated, which will foster a future alignment with SysML concepts. Proposed resolution: Introduce the meta-classes: ValuePropery and ValueType in NFP_Declaration package and create inheritance links from ValueProperty to NFP and ValueType to NFPType. No impact on the current UML profile.

Resolution: Proceed as suggested in the issue summary: � Introduce two meta-classes ValuePropery and ValueType in the NFP_Declaration package, � Create an inheritance link from ValueProperty to NFP and ValueType to NFP_Type, � Document the meta-classes in Annex F. The introduction of the ValueProperty and ValueType metaclasses will provide intermediate definitions that bridge the notions of non-functional property (NFP) and more general definitions of value and quantity. It is also an opportunity to reference SysML notions of ValueProperty / ValueType as related concepts.
Revised Text: see ptc/2009-05-12 pages 343 - 347
Actions taken:
February 2, 2009: received issue
October 16, 2009: closed issue

Issue 13407: FlowPort stereotype (marte-ftf)

Concerning the FlowPort stereotype, there are some differences between the definition given in SysML and the definition given in MARTE. The differences are: - isConjugated : In MARTE, the multiplicity of this property is [1], whereas in SysML it is [0..1] - direction : In MARTE, the multiplicity of this property is [0..1], whereas in SysML it is [1]. Moreover, a difference also appear concerning the FlowSpecification stereotype: - In MARTE, FlowSpecification has a direction:DirectionKind[0..1] property, whereas in SysML, this property does not exist. Is it just an alignment issue, or is there any fundamental reason motivating these differences?

Resolution: see ptc/2009-05-12 pages 348 - 351
Revised Text: see ptc/2009-05-12 pages 351 - 357
Actions taken:
February 2, 2009: received issue
October 16, 2009: closed issue

Issue 13408: Literals terminal rule has not been defined for its elements, in Section B.3.3.1 in p. 412 (marte-ftf)

Literals terminal rule has not been defined for its elements, in Section B.3.3.1 in p. 412

Resolution: Since Issues 13408 to 13424 are all related to mistakes in the grammar of VSL (Annex B), we merge them all in this issue resolution. For convenience, we copy below the formulation of each issue. This resolution proposes to fix all these issues as proposed by the Issue source.
Revised Text: see ptc/2009-05-12 pages 358 - 364
Actions taken:
February 2, 2009: received issue
October 16, 2009: closed issue

Issue 13409: In Section B.3.3.12 (Variables, p 416), the text is not aligned with the grammar (marte-ftf)

A variables begins by a "direction" and not by a "$" symbol. Yet, the direction is optional, and so a default value must be defined.

Resolution: See issue 13408 for disposition
Revised Text:
Actions taken:
February 2, 2009: received issue
October 16, 2009: closed issue

Issue 13410: Section B.3.3.3 is duplicated. (marte-ftf)

Section B.3.3.3 is duplicated.

Resolution: See issue 13408 for disposition
Revised Text:
Actions taken:
February 2, 2009: received issue
October 16, 2009: closed issue

Issue 13411: In Section B.3.3.4., the DateTimeLiteral rule can be optimized (marte-ftf)

 In Section B.3.3.4., the DateTimeLiteral rule can be optimized by removing the first alternative and letting optional date-string in the third alternative.

Resolution: See issue 13408 for disposition
Revised Text:
Actions taken:
February 2, 2009: received issue
October 16, 2009: closed issue

Issue 13412: In B.3.3.7, literal-interval-bound should be separated in two interval bounds (marte-ftf)

In B.3.3.7, literal-interval-bound should be separated in two interval bounds: number-interval-bound and a datetime-interval-bound.

Resolution: See issue 13408 for disposition
Revised Text:
Actions taken:
February 2, 2009: received issue
October 16, 2009: closed issue

Issue 13413: In B.3.3.7, the first rule allows defining bounds of different type, This should be forbidden (marte-ftf)

In B.3.3.7, the first rule allows defining bounds of different type. This should be forbidden. The first two rules must be changed by: <interval> ::= ('[' | ']') <interval-bounds> ('[' | ']') <interval-bounds> ::= <number-interval-bound> '..' <number-interval-bound> | <datetime-interval-bound> '..' < datetime -interval-bound> | <tuple-interval-bound> '..' <tuple-interval-bound> | <choiceinterval-bound> '..' <tuple-interval-bound> | <expression-interval-bound> '..' <tuple-interval-bound>

Resolution: See issue 13408 for disposition
Revised Text:
Actions taken:
February 2, 2009: received issue
October 16, 2009: closed issue

Issue 13414: In Section B.3.3.8, remove the 'unlimited-natural' term (not longer valid). (marte-ftf)

In Section B.3.3.8, remove the 'unlimited-natural' term (not longer valid).

Resolution: See issue 13408 for disposition
Revised Text:
Actions taken:
February 2, 2009: received issue
October 16, 2009: closed issue

Issue 13415: Properties of TupleType and ChoiceType should be constrained to be DataType only. (marte-ftf)

Properties of TupleType and ChoiceType should be constrained to be DataType only.

Resolution: See issue 13408 for disposition
Revised Text:
Actions taken:
February 2, 2009: received issue
October 16, 2009: closed issue

Issue 13416: In Section B.3.3.12, in the last line, the examples should refer to variable call expr, and not property call expr. (marte-ftf)

In Section B.3.3.12, in the last line, the examples should refer to variable call expr, and not property call expr.

Resolution: See issue 13408 for disposition
Revised Text:
Actions taken:
February 2, 2009: received issue
October 16, 2009: closed issue

Issue 13417: In Section B.3.3.12, second rule, it is missing the ":' symbol in variable declaration. (marte-ftf)

In Section B.3.3.12, second rule, it is missing the ":' symbol in variable declaration.

Resolution: See issue 13408 for disposition
Revised Text:
Actions taken:
February 2, 2009: received issue
October 16, 2009: closed issue

Issue 13418: Variable call expression and property call expression are ambiguous (marte-ftf)

We should define a context for property call expression, or define some keywords for making difference.

Resolution: See issue 13408 for disposition
Revised Text:
Actions taken:
February 2, 2009: received issue
October 16, 2009: closed issue

Issue 13419: In B.3.3.14, first rule, parentheses are not optional (marte-ftf)

In B.3.3.14, first rule, parentheses are not optional� (already solved in other Issue number!).

Resolution: See issue 13408 for disposition
Revised Text:
Actions taken:
February 2, 2009: received issue
October 16, 2009: closed issue

Issue 13420: In B.3.3.13, namespace must be replaced (marte-ftf)

In B.3.3.13, namespace must be replaced by: <namespace> ::= <body-text> ['.' <namespace>]

Resolution: See issue 13408 for disposition
Revised Text:
Actions taken:
February 2, 2009: received issue
October 16, 2009: closed issue

Issue 13421: In B.3.3.15, the parentheses in the rules: if-true-expr and if-false-expr are not required. (marte-ftf)

In B.3.3.15, the parentheses in the rules: if-true-expr and if-false-expr are not required.

Resolution: See issue 13408 for disposition
Revised Text:
Actions taken:
February 2, 2009: received issue
October 16, 2009: closed issue

Issue 13422: In B.3.3.15, if-false-expr should be optional. Also, the metamodel in page 402: must be updated. (marte-ftf)

In B.3.3.15, if-false-expr should be optional. Also, the metamodel in page 402: must be updated.

Resolution: See issue 13408 for disposition
Revised Text:
Actions taken:
February 2, 2009: received issue
October 16, 2009: closed issue

Issue 13423: In B.3.3.16, namespace must be replaced by namespace ::= <body-text> ['.' namespace] (marte-ftf)

In B.3.3.16, namespace must be replaced by (or removed because the rule already exists): namespace ::= <body-text> ['.' namespace]

Resolution: See issue 13408 for disposition
Revised Text:
Actions taken:
February 2, 2009: received issue
October 16, 2009: closed issue

Issue 13424: In B.3.3.16, jitter(t1,t2) should be clarified (description of the t2 term). Should be jitter(t2-t1)?? (marte-ftf)

In B.3.3.16, jitter(t1,t2) should be clarified (description of the t2 term). Should be jitter(t2-t1)??

Resolution: See issue 13408 for disposition
Revised Text:
Actions taken:
February 2, 2009: received issue
October 16, 2009: closed issue

Issue 13445: Missing attributes (marte-ftf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

In page 91 (GRM chapter) of MARTE profile (beta_2)a figure appear with the <<CommunicationMedia>> attributes. But in the corresponding annex those attributes don't appear (just elementSize appears). Those "disappeared" attributtes are included in <<CommunicationEndPoint>> attributes.

Resolution: Move from section F.4.6 to F.4.7 the additional attributes stated in resolution to 11835.
Revised Text: Move attributes: � bandwidth: NFP_DataTxRate [0..1] capacity of the communication element when applicablelink. � packetT: NFP_Duration [0..1] time to transmit the element used as a communication quantum, usually called a packet, the size in bits of this quantum is described by the attribute elementSize. � blockT: NFP_Duration [0..1] time the communicationMedia is blocked and cannot transmit due to the transmission of one communication quantum. � transmMode: MARTE_Library::MARTE_DataTypes::TransmModeKind [0..1] defines the transmission mode, one of the following values: {simplex, halfduplex, full-duplex}. From section F.4.6 CommunicationEndPoint to F.4.7 CommunicationMedia
Actions taken:
February 5, 2009: received issue
October 16, 2009: closed issue

Issue 13534: In HRM, the structure of the subprofile is ill formed (marte-ftf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Sebastien Gerard, sebastien.gerard(at)cea.fr)
Nature: Uncategorized Issue
Severity:
Summary:

In HRM, the structure of the subprofile is ill formed. The HwGeneral package should be direct sub package of the HRM profile and it shold be imported by both HwLogical and HwPhysical sub packages of HRM. And all sub packages of the HRM profile should be sub profiles in order to improve its scalability.

Resolution: The profile architecture of the HRM profile has been updated to factorize the HwGeneral sub profile in order it can be shared by both HwLogical and HwPhysical subprofiles.
Revised Text: see ptc/2009-05-12 pages 382 - 384
Actions taken:
February 20, 2009: received issue
October 16, 2009: closed issue

Issue 13714: Typos in example Figures 17.15/16/17/27 (marte-ftf)

Click here for this issue's archive.
Source: Carleton University (Dr. Murray Woodside, cmw(at)sce.carleton.ca)
Nature: Uncategorized Issue
Severity:
Summary:

These example figures contain a few stereotypes and attributes that were defined in earlier drafts of the profile and need to be updated. These are similar to typos. Examples:      (a) Fig 17.15 the stereotype paRequestEventStream has been replaced by gaWorkloadEvent, and attributes closedPopulation and closedExeternalDelay are replaced by a closed pattern,      (b) respTime should be respT, probability should be prob, repetition shold be rep      (c) In Figure 17.16 the contextValues attribute must be upgraded      (d) In 17.17 the contextValues attribute must be upgraded, and gaReleaseStep is replaced by gaRelStep, gaAcquireStep by gaAcqStep, repetition by rep.      (e) in 17.27 there are three instances of probability --> prob

Resolution: AnalysisContext changes are part of issue 13724. (a) Fig 17.15 the stereotype paRequestEventStream has been replaced by gaWorkloadEvent, and attributes closedPopulation and closedExeternalDelay are replaced by a closed pattern, (b) respTime should be respT, probability should be prob, repetition should be rep (c) In 17.17 gaReleaseStep is replaced by GaRelStep, gaAcquireStep by GaAcqStep, repetition by rep. (d) in Fig 17.24, PaProcess is replaced by PaRunTInstance (e) in Fig 17.26, remove $ signs on variable names (f) in 17.27 there are three instances of probability --> prob
Revised Text: see pc/2009-05-12 pages 385 - 401
Actions taken:
March 11, 2009: received issue
October 16, 2009: closed issue

Discussion:

Issue 13723: Marte: consistent capitalization of stereotypes in Sec 17.4 (marte-ftf)

Click here for this issue's archive.
Source: Carleton University (Dr. Murray Woodside, cmw(at)sce.carleton.ca)
Nature: Uncategorized Issue
Severity:
Summary:

The capitalization of stereotypes in the example in Sec 17.4 needs to be made consistent with the definitions in Sec 17.3. this afffects mostly figures, a few instances in the text also.

Resolution: The correct prefix is Pa or Ga, instead of pa or ga.
Revised Text: see ptc/2009-05-12 pages 402 - 418
Actions taken:
March 16, 2009: received issue
February 17, 2010: closed issue

Issue 13724: Marte: more complete definition of contextParams in GaAnalysisContext (ch 15) (marte-ftf)

Click here for this issue's archive.
Source: Carleton University (Dr. Murray Woodside, cmw(at)sce.carleton.ca)
Nature: Uncategorized Issue
Severity:
Summary:

The attribute contextParams in the domain model (Fig 15.2) is a collection of VSL::Expression::Variable (Variable as defined in Sec B.3.3.12). However in the profile definition of Sec 15.3.2.2 it is just defined as a set of strings.      To make it consistent with the domain model, and useful for defining parameters of contexts, the strings should be defined to conform to the concrete syntax for variable calls or declarations of Sec B.3.3.12.      Three of the examples of Sec 17.4 use these attributes, in a form that is no longer in the document, and need to be updated (see Figs 17.16, 17.17, 17.21, 17.27)

Resolution: To make it consistent with the domain model, and useful for defining parameters of contexts, the strings should be defined to conform to the concrete syntax for variable calls or declarations of Sec B.3.3.12. Three of the examples of Sec 17.4 use these attributes, in a form that is no longer in the document, and need to be updated (see Figs 17.16, 17.17, 17.21, 17.27)
Revised Text: see ptc/2009-05-12 pages 419 - 435
Actions taken:
March 16, 2009: received issue
October 16, 2009: closed issue

Discussion:

Issue 13821: There should be a section to describe the different possible notations for the allocation (marte-ftf)

Click here for this issue's archive.
Source: INRIA (Dr. Frederic Mallet, Frederic.Mallet(at)inria.fr)
Nature: Clarification
Severity: Minor
Summary:

There should be a section to describe the different possible notations for the allocation

Resolution: See issue 13126 for disposition
Revised Text:
Actions taken:
March 30, 2009: received issue
October 16, 2009: closed issue