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.