The stereotype GRM::SchedulableResource should have an attribute describing its activation parameters (arrival pattern and parameters). This is useful in multi-rate systems, where, in addition to the activations defined at application level (activation events triggering action/event chains), OS tasks/threads can be defined with a given activation rate. For instance, almost all automotive systems are multi-rate systems. Even if the functional application appears as a single rate system, multiplexing mechanisms both in the communication or in data sampling mechanisms can induce to more complicated timing behaviors, which are a characteristics of multi-rate systems.

The activation pattern is a characteristic of the application, not of the platform. In
fact it is usually different in each execution scenario. The concept of task, as
used in languages and formalisms is for all of them a way to create an
application, not a description of the platform. A modeling element that may serve
for this purpose would be much closer in meaning to an RTUnit than to a
SchedulableReource. So the extension requested is not in the scope of GRM. A
task is clearly a design modeling element and if not in HLAM it may probably fit in
SRM.

The metamodel can not be executed/implemented since their is no root
element in the metamodel. It would be useful to introduce the
packageableElement, Model (A model owns * PackageableElements). This
addition has several consequences on other parts of the metamodel in
order for this latter to be used for instance to create MARTE model
conforms to the MARTE metamodel.

Actually there is a root element it is “ModeElement”, and it has the “ownedElement”
reflective relationship so all elements in MARTE may be (hopefully) derived from and
contained in it. I suggest Close No Change.
Disposition: Closed, no change

The example in Figure 10.21 makes use of directed arrows to represent connectors in a composite structure. Moreover, it seems that the element inside the composite structure look more like classes than parts.

The example is not a composite structure; the caption text of the figure may have
mislead the reader. It shows just a class diagram with dependencies among
them.
Resolution:
Closed the issue with no change to the specification

The notation section of 11.3.2.7 makes use of stereotypes that are inconsistent with the profile diagram. Proposed resolution: align the notation section of 11.3.2.7 to the profile diagram.

This issue was related to MARTE beta 1 and is no longer relevant to MARTE v1.
Disposition: Closed, no change

On fig. 7.6 three association between Instance and ModelElement (subclasses) have properties subsetted "type", but the "type" property only appear between Instance and Classifier (not ModelElement) fig. 7.3.

THIS IS A slightly OLD ISSUE, THE FIGURE NUMBERS HAD CHANGE SINCE
LAST VERSIONS. AND THIS HAS BEEN ALREADY SOLVED BY SUBTYPING
THE ROLE IN ONE OF THE LAST VERSIONS. SEE FIGURE 7.7 We can close with
no change the issue.
Disposition: Closed, no change

A simplification of GRM should be envisaged.
GRM defines too many detailled concepts (for instance the Scheduler which seems more
appropriate in the SRM package), these concepts could be defined in
SRM or HRM package or even in SAM package.

The way to define different types of services need to be aligned between GRM, SRM
and HRM.

With respect to the status of the FTF, the resolution of this issue would need too
much time to be resolved in an efficient and satisfying form. So, I (Sébastien
Gérard from CEA LIST) propose to defer it.
Disposition: Deferred This issue has been resolved by resolutions to issues 11411 and 11412. A brief
modification is necessary in the introduction of GRM to comprise it as generic for
also analysis and design. A brief text is to be added to the Introduction of GRM to emphasize its a role of
foundation for the analysis packages (GQAM, SAM and PAM) and the DRM
(SRM and HRM).

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

No Data Available

There should be a section to describe the different possible notations for the allocation

See issue 13126 for disposition

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

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

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)

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)

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.

The correct prefix is Pa or Ga, instead of pa or ga.

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.

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.

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.

Move from section F.4.6 to F.4.7 the additional attributes stated in resolution to 11835.

In B.3.3.16, jitter(t1,t2) should be clarified (description of the t2 term). Should be jitter(t2-t1)??

See issue 13408 for disposition

In B.3.3.16, namespace must be replaced by (or removed because the rule already exists): namespace ::= <body-text> ['.' namespace]

See issue 13408 for disposition

In B.3.3.15, if-false-expr should be optional. Also, the metamodel in page 402: must be updated.

See issue 13408 for disposition

In B.3.3.14, first rule, parentheses are not optional… (already solved in other Issue number!).

See issue 13408 for disposition

We should define a context for property call expression, or define some keywords for making difference.

See issue 13408 for disposition

In Section B.3.3.12, second rule, it is missing the ":' symbol in variable declaration.

See issue 13408 for disposition

In B.3.3.15, the parentheses in the rules: if-true-expr and if-false-expr are not required.

See issue 13408 for disposition

In B.3.3.13, namespace must be replaced by: <namespace> ::= <body-text> ['.' <namespace>]

See issue 13408 for disposition

In Section B.3.3.8, remove the 'unlimited-natural' term (not longer valid).

See issue 13408 for disposition

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>

See issue 13408 for disposition

In B.3.3.7, literal-interval-bound should be separated in two interval bounds: number-interval-bound and a datetime-interval-bound.

See issue 13408 for disposition

In Section B.3.3.12, in the last line, the examples should refer to variable call expr, and not property call expr.

See issue 13408 for disposition

Properties of TupleType and ChoiceType should be constrained to be DataType only.

See issue 13408 for disposition

Section B.3.3.3 is duplicated.

See issue 13408 for disposition

A variables begins by a "direction" and not by a "$" symbol. Yet, the direction is optional, and so a default value must be defined.

See issue 13408 for disposition

Literals terminal rule has not been defined for its elements, in Section B.3.3.1 in p. 412

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.

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.

See issue 13408 for disposition

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?

see ptc/2009-05-12 pages 348 - 351

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.

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.

The ARINC 653 Annex of MARTE is not strictly compliant with the ARINC 653 resolution: Update the API with the ARINC 653 Ada API

New ARINC 653 API model has been provided and complementary text to
explain ARINC 653 Service API

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

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

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

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

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.

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

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.

See issue 13125 for disposition

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.

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

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.

MultiplicityElement has been modified in the context of the issue 13089.
Consequently, this issue becomes no more valid.
Disposition: See issue 13089 for disposition

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.

No Data Available

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.

It is not clear if that would be really useful. If some need appears in the future, reraise
the issue.
Disposition: Closed, no change

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.

See issue 11838 for disposition

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.

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.

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 ?

This issue points two mistakes and additionally requests for some description
enhancements. This resolution proposes to revise the text as described below

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

See issue 13125 for disposition

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

No Data Available

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

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.

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.

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.

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

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.

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.

Ok for items 1, 2, 4 and 5. Item 3 has no meaning. See following revised text.

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

See issue 11820 for disposition

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

See issue 11820 for disposition

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

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

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

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

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?

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

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.

This resolution proposes to remove Figure 13.13, page 156. The RteConnector
stereotype doesn’t exist anymore.

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

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

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.

Add the

quality to the subUsages association depicted in Figure 10.18

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.

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

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.

This issue requires an important restructuring of MARTE. We propose to defer it
to the RTF
Disposition: Deferred

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.

Modifications should be done to delete this redundancy (see next proposition of revised text).

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

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

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

Add an example of these two stereotypes in action at the end of the chapter.

why is it called a “FlowBFeature” at all – what does it have to with Flows?

See issue 11820 for disposition

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

See issue 11820 for disposition

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

This resolution provides a revised text that completes Annex 3.

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

Substitution done.

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.

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.

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.

Yes, the text should refer to chapter 7 to chapter 17 and Annex F. see next proposed resolution.

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

This issue is a duplicate of issue #11338.

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

duplicate of issue # 11664, closed issue

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.

withdrawn by submitter

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.

withdrawn by submitter

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

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.

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

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.

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

In the proposed way

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.

See issue 11850 for disposition

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

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.

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

see ptc/2009-05-12 pages 89 - 94

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?

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.

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

No Data Available

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.

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)

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

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

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

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.

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.

Rephrase the paragraph conveniently.

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

I agree on the redundancy, but I propose to keep the table instead of the text.

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.

Agree on the suggestion, see proposed resolution

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

Agree on the suggestion, see proposed resolution

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

Strike the phrase "Business Management Perspective" Change it by "system perspective"

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.

Disposition: See issue 11854 for disposition

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

This issue is duplicated of Issue 11764. Both propose a mechanism to annotate
multiple value annotations for different situations in a model.
Disposition: Duplicated