MARTE, formal/2009-11-02, GRM chapter, pag 96-97, enhancement

GRM:Support for Time table driven schedules.

Having the opaque expression attribute "schedule" in the Scheduler in GRM lead to a very open way of expressing fixed schedules or non-traditional scheduling policies. This is the case of time triggered sets of tasks in particular, but also of any form of table driven schedule. Following a general approach but formalizing the way of expressing schedules as a set of labeled timed windows would make the exchange of information between strict time triggered platforms design intent and its corresponding analysis models easier and in a standardized way.

An alternative to study may be formalizing the attribute “schedule” of a scheduler to include at least the frame_cycle_time, and the list of “windows” or “time_slots” to be managed as schedulable resources. To do this the easiest way may be to make them part of a list inside the schedule indexed by a key that match the scheduling parameters field of the schedulable resources that are attached to the scheduler.

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

The concept of System in Annex A.2 maps to a concept not defined in the MARTE specification (a SysML concept). However the MARTE profile does not import the SysML profile.

An AADL system represents an assembly of interacting application software,
execution platform, and system components.
The chosen mapping shall not only be semantically correct, but shall also have
an intuitive name.
MARTE doesn’t address such a generic aspect, and it would not make sense to
add such a concept to MARTE.
UML generic concept “StructuredClasses class” could be use, but this concept
has already been used to represent AADL data. As mappings have always to be
bijectiv, another representation has to be found.
UML “subsystem” concept could be used to represent an “AADL system”, this
mapping is semantically correct, but the name is confusing.
The best solution is to use the SysML “block” concept: the mapping is
semantically correct and the name is sufficiently different to avoid confusion.
This solution needs to import the SysML profile. A prerequisite will be added in
the introduction précising that the SysML profile needs to be importing when
using MARTE to design AADL applications in order to fully address the MARTE
to AADL mapping.

The term RequestEventStream is still used in GQAM, and in Annexes F and H while the concept has been refurbished as WorkloadEvent and others. Make all of them consistent.

The change from RequestEventStream to WorkloadEvent needs to be completed.
The sections where it appears still in the text are:
annex H, some texts in GQAM and PAM and many sections in Annex F: 10.19, 10.14,
10.21, 11.1, 12.1, 12.3, 12.4

VSL doest not provide a rule for expressing behavior calls (i.e., it only supports call of operations). Since Behaviors are first class citizen of UML2, there is no fundamental reason for preventing this kind of expressions. Integrating a rule for calling behaviors does not require much effort (cf. following proposed resolution).

Proposed resolution:

• Modify text of B2.4 p.431 (p.443 of the pdf)
  Between paragraph starting with “An Operation Call Expression…” and paragraph starting with “This metamodel does not define…”, insert the following paragraph:
  A Behavior Call Expression refers to a behavior defined in a UML Namespace. The expression may contain a list of argument expressions if the behavior is defined to have parameters. In this case, the number and types of the arguments must match the parameters.

• Modify figure B.4 p.432 (p.444 of the pdf) as follows:
  . Add a class BehaviorCallExpression, and a generalization relationship between this class and Expression
  . Add a composition relationship between BehaviorCallExpression and ValueSpecification, identical to the composition relationship between OperationCallExpression and ValueSpecification (this is to capture the arguments of the call)
  . On the diagram, add an abstract class Behavior, with a grey background like classes Property and Operation.
  . Add an association between BehaviorCallExpression and Behavior, identical to the association between PropertyCallExpression and Property, except that the name of the role should : definingBehavior
  . Add the following derived property to BehaviorCallExpression: /behavior:String

• In section B.3.3.13:
  Replace:
  <expression> ::= <variable-call-expr> | <variable-declaration> | <property-callexpr>

  <operation-call-expr>	<conditional-expr> By: <expression> ::= <variable-call-expr>	<variable-declaration>	<property-callexpr>
  <operation-call-expr>	<behavior-call-expr>	<conditional-expr>

• p.453 (p.465 of the pdf), insert the following section (and increment the number of remaining sections):

// Beginning of section
B.3.3.17 Behavior Call Expressions
Behavior calls are particularly used in the MARTE context to call behaviors taking data type values as parameters.

<behavior-call-expr> ::= <behavior-name> '('[ <argument-value> [','<argument-value>]* ]')’
<behavior-name> ::= [<namespace> '.'] <body-text>
<namespace> ::= <body-text>

Expression typing
• The <behavior-call-expr> production rule should be evaluated to the type of the UML::Behavior that is called.
• The <argument-value> production rule must be evaluated to the corresponding to UML::Parameter's type of an existing UML::Parameter owned by the UML::Behavior.

Abstract syntax mapping
• The <behavior-call-expr> production rule maps to the BehaviorCallExpression domain element described in Annex F (Section F.13.XX).

Disambiguating rules
• <behavior-name> should correspond to an existing UML::Behavior name.
//end of section

• In annex F, insert a section F.13.1 as follows (and increment of remaining sections):

// beginning of section
F.13.1 BehaviorCallExpression (from Expressions)

Generalizations
• Expression (from Expressions) on page 560

Associations
• definingBehavior: Causality::CommonBehavior::Behavior [1]
Called Behavior.
• argument: VSL::ValueSpecification [*]

Arguments of the Operation Call.

Attributes
• /behavior: String [1]
String with the qualified name of the called Behavior. This is a derived value obtained from the definingBehavior.

Semantics
A Behavior Call Expression refers to a behavior defined in a UML Namespace. The expression may contain a list of argument expressions if the behavior is defined to have parameters. In this case, the number and types of the arguments must match the parameters.
// end of section

The absence of rules for calling behaviors indeed introduces an artificial limitation to the
applicability of VSL. Concretely, all the available behavior signatures are currently defined
following the object-oriented paradigm, in the form of operations (e.g., String.concat(String)),
belonging to data types of the standard MARTE libraries. These behavior signatures could
alternatively be defined following a procedural style (e.g. concat(String,String)). Designers who
are familiar with procedural languages would probably feel more comfortable with this approach.
Since UML natively offers support for describing behavior signatures in the procedural style, VSL
should not prevent the usage of this kind of behaviors, and a rule should be added to support call
of behaviors. The following figure illustrates the differences between the two paradigms, from
both the perspective of libraries definitions (left hand side of the figure) and the perspective of
usage in VSL (right hand side of the figure).

In rule <namespace>, the element [‘.’ <namespace>] is useless and should be removed.

Proposed resolution:

• Replace:
  <namespace> ::= <body-text> ['.' <namespace>]
  By
  <namespace> ::= <body-text>

No Data Available

The domain view of the Time Chapter provides clocks to achieve two goals. First, Clocks give an explicit time referential for various kinds of elements.
Second, Clocks give an orthogonal mechanism to put temporal information on any events, whereas UML consider TimeEvent as a special case of events.

In the domain view, the second position was made concrete by the attribute "definingEvent" that was denoting the event from which a clock was built (occurrences of the events, where the instants of the clock). All the stereotypes provided in the UML representation address the first objective. None address the second one.

Suggested resolution, the stereotype "Clock" could extend the metaclass "Event" as well. That would allow clock constraints to constrain/specify the occurrences of events.

No Data Available

Figure 11.8 has an element called Memory inside an element named "p:Process[256]" that is labeled as 'app_allocated'. Unfortunately, there is no such stereotype defined in MARTE (this is probably a leftover from an earlier version)

Replace “app_allocated” by “allocated” as suggested. The kind “application”
already has the information about the role (“app_”).

There are some typos and mistakes in the rule <interval-bounds>, concerning the following alternatives:

Proposed resolution:

• Replace:

  <choiceinterval-bound> '..' <tuple-interval-bound> by

  <choice-interval-bound> '..' <choice-interval-bound>

• Replace:

  <expression-interval-bound> '..' <tuple-interval-bound> by

  <expression-interval-bound> '..' <expression-interval-bound>

Follow the proposed resolution

The current version of the MARTE::GCM specification presents a mechanism to model data received and sent via ports. However, receptions are modelled in the higher level as GCMTriggers which extends UML Trigger, applicable in State Machine diagrams; while invocations are modelled using GCMInvocationActions, which extends UML InvocationAction, applicable in Activity diagrams.

For the sake of applicability I would propose to extend the GCM metamodel with extra stereotypes so that invocations can be modelled in STM and receptions can be modelled in Activity diagrams. I this wouldn't be possible I would propose to include some examples showing how this can be modelled in the later cases.

The issue addresses two different problems. The first one regarding receptions in
Activity diagrams and the second one regarding invocations in state machine
diagrams.
The first part of the issue can be closed, since it is possible to model this kind of
receptions using UML AcceptEventActions; which can be associated with a
GCMTrigger. Example 3, on Figure 12.23, illustrates this.
The second part of the issue; however it is not currently covered by MARTE or
UML. The proposed resolution is to add a new stereotype,
GCMInvocatingBehavior, which models the invocations taking place inside a
behavior without having to look at its internals (particularly interesting in the case
of OpaqueBehaviors). This stereotype will allow specifying communications in
the scope of a single component and independently from other components (in
opposition with Interactions, which specify communications between different
components, with a system wide scope).

In rule <conditional-expression>, <if-false-exp> should not be optional. Otherwise, it is not clear what is the result of a ConditionalExpression in the case where <condition-expr> evaluates to false, and there is no specified <if-false-exp>
Proposed resolution:

• Replace:
  <conditional-expression> ::= <condition-expr> '?' <if-true-expr> [':' <if-false-exp>]
  By
  <conditional-expression> ::= <condition-expr> '?' <if-true-expr> ':' <if-false-exp>

The proposed resolution, described in the summary, would indeed avoid ambiguities, and make
the usage of operators ‘?’ ‘:’ more conventional.

Adding an optional keyword ‘Tuple’ may improve readability of tuple expressions, since, depending on the context, an expression of the form ‘(‘ValueSpecification’)’ can resolve to a tuple value or a choice value. Of course, the context is enough to disambiguate the rule. The optional keyword ‘Tuple’ would only provide a mean for making the expressions more readable from a user standpoint (note that the ‘Tuple’ keyword is also used in OCL). For the same reason, an optional keyword ‘Choice’ could also be added in choice expressions.

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

In the analysis subprofiles a step has two relationships to scenarios:

1 Containment... a step is always contained in a scenario
2 Refinement: a step may be optionally be refined by a lower-level scenario

The GQAM chapter defines one association behavior/steps which is defined
as containment from the scenario point of view, and as refinement from
the step point of view. This is navigable and usable, but formally
incorrect.

Suggested resolution: To be formally correct it requires two associations.
One defines a collection of steps as the steps of the scenario, the other
defines a scenario as a refinement of a step.

Suggestion:

Containment: Scenario has association steps, Step has association scenario

Refinement: Scenario has association parentStep, Step has association
childScenario

Alternatively we could explain the overloading in the text and leave the
profile as it is.

Needs discussion.

To be formally correct it requires two associations. One defines a collection of
steps as the steps of the scenario, the other defines a scenario as a refinement
of a step. Suggestion:
Containment: Scenario has association steps, Step has association scenario
Refinement: Scenario has association parentStep, Step has association
childScenario
These changes are needed both in the domain model sec 15.2 and the profile
sec 15.3, and in Appendix F.10 for the encoding of the domain model
Also, some changes in sec. F.10.3 to synchronize it with sec 15.2 were
transferred from issue 14435,
• association Actions renamed steps (consistent with Fig 15.3)
• association usedResources dropped (not in Fig. 15.3)
• association inputStream renamed cause (consistent with fig 15.3)
• association connectors added (consistent with Fig 15.3)
• attribute priority dropped (it occurs on Step)(consistent with chapter 15) (A) Figure 15.3:
• add association parentStep - childScenario
• rename association behavior - steps to scenario - steps
(B) Section 15.2, Text p 290 para 5:
Before:
Steps and BehaviorScenarios have quantitative attributes as shown in Figure 15.3. A Step
can be optional (with a probability less than one of being executed), or repeated (with a
repetition count). It can be refined as another BehaviorScenario (its “behavior”
association). The “isAtomic” property specifies atomicity of execution (default is false).
Revised Text (the one new sentence is in red)
Steps and BehaviorScenarios have quantitative attributes as shown in Figure 15.3. A Step
can be optional (with a probability less than one of being executed), or repeated (with a
repetition count). A BehaviorScenario is a collection of Steps, but also a Step can also be
the parent of a refinement as a more detailed BehaviorScenario (its childScenario). The
“isAtomic” property specifies atomicity of execution (default is false).
(C) Fig 15.7 (the profile) also needs to be updated for the second association
between Step and Scenario:
• add association parentStep - childScenario
• modify association behavior - steps to scenario - steps
(D) Appendix F.10.3 for BehaviorScenario
The five changes transferred from issue 14435 are included, plus the association
change between Step and BehaviorScenario. For clarity the new text is in red.
Original text: Associations
• root: Step [0..1] Root Step to begin the BehaviorScenario.
• Actions: Step [0..1] Set of Steps making up the BehaviorScenario.
• inputStream: RequestEventStream [1..*] RequestEventStream that initiates it.
• usedResources: Resource [0..*]

Set of resources used by the scenario UML
Profile for MARTE, V1.0
Attributes
• hostDemand: NFP_Duration [0..1] CPU demand in time units.
• hostDemandOps: NFP_Real [0..1] CPU demand in operations.
• priority: NFP_Integer [0..1]
• respTime: NFP_Duration [0..1] End-to-end delay of a part of an operation.
• interOccTime: NFP_Duration [0..1] Interval between successive initiations of an
operation.
• throughput: NFP_Rate [0..1] Frequency of initiations of an operation.
• utilization: NFP_Real [0..1] Fraction of time an operation is busy (throughput times
delay). For a resource, the fraction of time each unit is busy, times the number of units.
• utilizationOnHost: NFP_Real [0..1] Fraction of time the host is busy executing this
operation.
Revised text:
Associations
• root: Step [0..1] Root Step to begin the BehaviorScenario.
• steps: Step [0..1] Set of Steps making up the BehaviorScenario.
• cause: RequestEventStream [1..*] RequestEventStream that initiates it.
• parentStep: Step [0..1] Step of which this BehaviorScenario is a refinement (nested
behavior)
• connectors: PrecedenceRelation [*] The set of precedence relationships between the
steps of the scenario
Attributes
• hostDemand: NFP_Duration [0..1] CPU demand in time units.
• hostDemandOps: NFP_Real [0..1] CPU demand in operations.
• respTime: NFP_Duration [0..1] End-to-end delay of a part of an operation.
• interOccTime: NFP_Duration [0..1] Interval between successive initiations of an
operation.
• throughput: NFP_Rate [0..1] Frequency of initiations of an operation.
• utilization: NFP_Real [0..1] Fraction of time an operation is busy (throughput times
delay). For a resource, the fraction of time each unit is busy, times the number of units.
• utilizationOnHost: NFP_Real [0..1] Fraction of time the host is busy executing this
operation.
(E) Section F10.17 for Step
Add the new association between Step and BehaviorScenario Old text:
Associations
• outputRel: PrecedenceRelation [*] Successor relation.
• inputRel: Step[*]:PrecedenceRelation [*] Predecessor relation.
Attributes
• isAtomic: NFP_Boolean [0..1] If true, the step cannot be decomposed any further.
• blockingTime: NFP_Duration [0..1] Delay inserted into the execution of the Step.
• repetitions: NFP_Real [0..1] Actual or average number of repetitions of an operation or
loop.
• probability: NFP_Real [0..1] Probability of the step to be executed (useful for
conditional execution).
• priority: NFP_Interval [0..1] Step priority.
Revised text:
Associations
• outputRel: PrecedenceRelation [*] Successor relation.
• inputRel: Step[*]:PrecedenceRelation [*] Predecessor relation.
• childScenario: Scenario [0..1] An optional refinement of the behavior of this Step
Attributes
• isAtomic: NFP_Boolean [0..1] If true, the step cannot be decomposed any further.
• blockingTime: NFP_Duration [0..1] Delay inserted into the execution of the Step.
• repetitions: NFP_Real [0..1] Actual or average number of repetitions of an operation or
loop.
• probability: NFP_Real [0..1] Probability of the step to be executed (useful for
conditional execution).
• priority: NFP_Interval [0..1] Step priority.
(F) Sec 15.3.2.12, giving the UML definition of GaScenario
Old text:
Associations
• steps: Step [1..*]
The set of steps that make up the Scenario.
New text:
Associations
• steps: GaStep [1..*]
The set of steps that make up the Scenario.
• parentStep: GaStep [1..*]
A GaStep, of which this scenario is a refinement.
(G) Sec 15.3.2.13, giving the UML definition of GaStep
Old text: Associations
• behavior: GaScenario [0..1]
A GaScenario that refines a composite Step.
New text:
Associations
• scenario: GaScenario [0..1]
The GaScenario that that contains this Step.
• childScenario: GaScenario [0..1]
A GaScenario that refines this Step, making it a composite Step.
Disposition: Resolved

In the context of our work for the ADAMS project (http://www.adams-project.org/) we try to align MARTE and AUTOSAR with specific focus on MARTE::GCM and AR::SWC. To do so, we produced the domain models in UML. Unfortunately, we found the following inconsistencies, unclarities or typography issues in the MARTE specifications:

• Issue1:
  AssemblyConnector (F.6.1) in annex F is not used in the domain of MARTE.
  -Resolution1:
  Remove F.6.1 and F6.13 subsections.

• Issue2:
  SendFlowAction (F6.13) in annex F is not used in the domain of MARTE.
  -Resolution2:
  Remove F6.13 subsection.

• Issue3:
  In Figure 12.2 (The bulk of the MARTE GenericComponentModel package), BehavioredClassifer qualified name is wrong.
  -Resolution3:
  Marte::CoreElements::Foundations::BehavioredClassifier should become MARTE::CoreElements::Causality::CommonBehavior::BehavioredClassifier

• Issue4:
  In second paragraph of subsubsection 12.2.1 (The GenericComponentModel Package), "AssemblyConnector" is not appropriate
  -Resolution4:
  … "An interaction port defines an explicit interaction point through which components may be connected (linked) through an AssemblyConnector, and through which they can communicate via message passing."… should be changed to : "An interaction port defines an explicit interaction point through which components may be connected (linked) through an assembly connector, and through which they can communicate via message passing."…

• Issue5:
  BFeatureKind (F.6.3) shouldn't be used anymore and it is replaced by ClientServerKind
  -Resolution5:
  Remove F.6.3. In subsection ClientServerPort (F.6.8) the type for "kind" attribute should be ClientServerKind.

• Issue6:
  DirectionKind (F.6.12 ) shouldn't be used anymore and it is replaced by FlowDirectionKind
  -Resolution6:
  Remove F.6.12. In subsection FlowPort (F.6.15) and FlowProperty (F.6.16) the type for "direction" attribute should be FlowDirectionKind. Update Index.

• Issue7:
  Mutliplicity and defalut value of "direction" attribute in FlowPort (F.6.15) should be respectively [1] and "= inout" in annex F
  -Resolution7:
  In F.6.15, [0..1] multiplicity for direction should be changed to [1] and default value set to "= inout"

• Issue8:
  Default value of "direction" attribute in FlowProperty (F.6.16) should be "= inout" in annex F
  -Resolution8:
  In F.6.15, default value for direction should be set to "= inout"

• Issue9:
  Multiplicity specification association of FlowPort (F.6.15) should be [0..*]. Furthermore this association is not represented in Figure 12.3
  -Resolution9:
  In F.6.15, multiplicity for specification should be changed to [0..*], name should be updated to "specifications" and Figure 12.3 should be updated consequently.

• Issue10:
  In annex F, Attributes paragraph title for InvocationAction (F.6.19) should actually be "Associations"
  -Resolution10:
  In F.6.19, change paragraph title to "Associations" and add a "Attributes" pragraph title with "None" as body.

• Issue11:
  In annex F, generalization to ClientServerFeature is missing for Operation (F.6.21)
  -Resolution11:
  In F.6.21, add ClientServerFeature to Generalizations paragraph

• Issue12:
  In annex F, association to Flowproperty is missing for SendDataAction (F.6.22)
  -Resolution12:
  In F.6.22, add " + targetProperty: FlowProperty [0..1]" to Associations paragraph

• Issue13:
  In annex F, Associations paragraph title (the one containing kind attribute) for ClientServerFeauture (F.6.6) should actually be "Attributes"
  -Resolution13:
  In F6.6 change paragraph title to "Attributes"

• Issue14:
  In Figure 12.3 and Figure 12.4, default values are not represented
  -Resolution14:
  To clarify the specification, default values should be represented too (i.e. "=false" for isAtomic and "=inout" for direction

• Issue15:
  SendSignalAction introduced in Figure 12.5 is not mentioned in annex F
  -Resolution15:
  Add annex F the concept with generalization to InvocationAction and change BoradcastSignalAction (F.6.4) generalization to SendSignalAction

• Issue16:
  In annex F, multiplicity for onPort association of InvocationAction (F.6.19) and the multiplicity represented in Figure 12.5 are inconsistent : [1] and [0..1] respectively.
  -Resolution16:
  Should be set to [1] for both.

• Issue17:
  ClientServerSpeification concept should be added to align with what is done for FlowPort
  -Resolution17:
  In annex F Add ClientServerSpecification concept in annex F. It has " + ownedFeatures: ClientServerFeature [*]" association. Add an association " + specifications: ClientServerSpecification [0..*]" to ClientServerPort (F.6.8)

• Issue18:
  In annex F, isAtomic attribute of ClientServerPort (F.6.8) should be defined as derived
  -Resolution18:
  In F.6.8, add a "/" in front of isAtomic attribut of ClientServerPort

• Issue19:
  Constraints on direction attribute for FlowPort
  -Resolution19:
  Add this constraint in Annex F to FlowPort (F.6.15) : If the FlowPort is not atomic then if direction attribute of all the FlowProperty of all its FlowSpecification are set to in (respectively out) then direction is in (respectively out) otherwise direction is inout.
  If the FlowPort is atomic then direction attribute must be set by designer.

• Issue20:
  Constraints on kind attribute for ClientServerPort
  -Resolution20:
  Add this constraint in Annex F to ClientServerPort (F.6.8) : If the ClientServer is not atomic then if kind attribute of all the ClientServerFeature of all its ClientServerSpecification are set to provided (respectively required) then direction is provided (respectively required) otherwise kind is proreq.
  If the ClientServerPort is atomic then kind attribute must be set by designer.

• Issue21:
  In annex F.6.7, required enum literal paragraph of ClientServerKind is inconsistent
  -Resolution21:
  … "The behavioral feature is provided by the port of the owning entity."… should changed to "The behavioral feature is required by the port of the owning entity."

This issue actually consists of sub-issues, which concerns minor synchronization problems
between diagrams of the domain model, and associated descriptions in Annex F. For each subissue,
the submitter has proposed resolutions. All the resolution (as the described in the section
“summary” above) are reproduced in the section “revised text” below, with complementary
information when needed.

The GQAM chapter defines the stereotype GaTimedObs in both domain and
profile figures, however there are inconsistencies elsewhere

... GQAM sec 15.3.2.12 refers to GaTimingObserver

... SAM chapter refers to it as GaTimingObserver, in the domain figure
16.5
... and also just before Fig 16.8
... and as TimingObs, in the profile figure 16.8

...PA chapter refers to it as GaTimingObserver in profile Fig 17.7

These are due to a last minute effort to shorten the names. THey all need
to be standardized on GaTimedObs.

The domain term in chapters 15 16 17 and appendix F should be
TimedObserver, the profile term in chapters 15 16 17 should be TimedObs

Precise component type and implementation relationship.
"Component realization" concept seems more inline with the AADL semantics than "UML realization" concept.

Disposition: See issue 14871 for disposition

CallConcurrencyKind is an Enumeration but is not marked as such on the Diagram

The issue actually refers to figure 13.8. Indeed, the keyword “enumeration” is missing on
CallConcurrencyKind. The proposed resolution consists in adding the missing keyword.

but is called D.4.6 PoolingParameters (PollingParameters definition does not exist in the spec)

It is indeed a typo: change PoolingParameters into PollingParameters for the
label of section D4.6.

Diagram shows

, it should be

.

New figure 10.18.

<<StereoType>> "SchedulableResource" has a tag of schedParams which is made up of a Class (this is not allowed in UML)

No Data Available

GQAM::BehaviorScenario specializes GRM::ResourceUsage. It seems that GRM::UsageDemand generalizes GQAM::WorkloadEvent. If so, make explicit this generalization relationship and consider the WorkloadEvent.timeEvent, WorkloadEvent.effect and BehaviorScenario.cause as redefined attributes

This is actuially a very good observation. It does not seem dangerous. A
resolution with it is provided.
Note for the editor: Please observe that this resolution must be edited in after
issue 14906, since this add the “redefined” constraint.

Figure 8.5 UML profile diagram for NFPs modeling

StereoType "Unit" has a Tag of convOffset but the xmi import has named it offsetFactor

The right name is convOffset. The xmi must be fixed..

The Step.host attribute is redundant, given that a schedulable resource need to be related to a processor (execution host) for the analysis model to be complete and practically usable. Three alternatives for this stereotype attribute may be discussed: a) remove it, b) make it derived, c) keep it as a duplicate shortcut information. On-going discussion with Dorina and Murray on this topic

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

Clarify the semantics of GQAM::BehaviorScenario duration attribute w.r.t. execTime, respTime and hostDemand, and harmonize their use across analysis chapters of the specification. On-going discussion with Dorina and Murray on this topic.

Clarified, using a reference to the definitions in Table 15.1. Some of the attributes
like execTime occur in the Table but are not used in the domain model, this is
also clarified

• symbol in front of the event property in Figure 10.13, which multiplicity is 0..1

Separate the * from the +event role label, and locate them correctly in figure
10.13.
The figure here shown is the very same as the resolution for issue 14908.

The Time profile is suposed to provide a fundational timing model for MARTE. Time stereotypes are specialized in several of profiles, such as GRM and GQAM. However, while time-related notions in the analysis profiles are typed by NFP_Duration, the Time::TimedProcesssing.duration stereotype attribute is typed by a ValueSpecification. This type inconsitency makes between general and specialized concepts creates usability issues. Indepently of that, note that the TimedProcessing meta-class and stereotype attribute are not consistently typed, as the (normative) TimedProcessing.duration meta-class attribute is typed by the (non-normative) CVS::DurationValueSpecification.

Disposition: See issue 14903 for disposition

GRM::TimingResource inherits from Resource and is then specialized into ClockResource and TimerResource but it does not add any new property. A clarification of the additional semantics of this intermediate stereotype would be needed

This is already explained in its definition in page 93.
Disposition: Closed, no change

NFP_CommonType shall define comparison operators (eg. =, >, <, *, +, -). This currently does not exist, as a consequence two NFP_Duration cannot be compared one another. For instance, the VSL grammar does allow expressions such "(end - start) < (value=10.0, unit=ms)" (where start and stop are TimeObservation

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

In Figure 15.3, Step.concurRes property should be typed by ConcurencyResource instead of SchedulableResource. SchedulableResource limits the domain of possible analysis that are possible with GQAM

No Data Available

ResourceUsage.requiredAmount aggregation kind should be composite

Add the diamond in ResourceUsage.requiredAmount depicted in figure 10.13.
Here it is to be solved also the typo reported in Issue 14916

ResouceUsageAmount has a 'enery' property. Rename into 'energy'

No Data Available

TimedElement.on default value should refer to the ideal clock, by the mean of a default property (e.g. instance value)

The intent was actually to do so. When attribute "on" is not used, then it implicitly
refers to idealClk. However, "idealClk" is defined in "TimeLibrary", which actually
applies the "Time" profile. So what is requested in the issue would actually create
a cyclic dependency.
The resolution proposes to add a sentence to make the intent clear as suggested
by the issue.

In the domain model, TimeProcessing.duration is a simple association, typed by CVS::DurationValueSpecification while in the profile the association is a composition, typed by ValueSpecification. Inconsistency should be corrected

In the domain view, the intent was to refer to a value (a duration value) and a
value exists independently of its specification and therefore cannot be owned. In
the UML representation, in practice, we use a specification to denote the value
and there is no reason for the specification not to be owned by another element.
The resolution proposes to keep the association in the domain view but refer to
the metaclass DurationValue instead of CVS::DurationValueSpecification. This
partly addresses also the issue 14912, stating that
CVS::DurationValueSpecification being non normative should not be used in a
normative part. The composition with a ValueSpecification is maintained in the
profile. This is consistent with the different roles played by a value and one of its
possible specifications.

Annex F defines a CommunicationChannel.msgSize property while the meta-model and the profile defines a packetSize property. Note that the term 'packet' may not generic enough for the concept of CommunicationChannel

For consistency, change the attributes of a CommunicationChannel in Annex F
section F.10.4, and the GaCommChannel stereotype description in section
15.3.2.3 so that they appear as packetSize and utilization, like in Fig 15.5.

Figure 15.3 defines a cause-effect association between WorkloadEvent and WorkloadBehavior, while Figure 16.3 defines an inputSteam-effect association

Change “inputStream” by “cause” in the association between WorkloadEvent and
WorkloadBehavior in Figure 16.3. This implies changing also the description of
the concept in Annex F section F10.3.

Figure 16.3 located in the SAM chapter defines a new property (typed by EndToEndFlow) for a meta-class WorkloadBehavior defined in GQAM. Either move EndToEndFlow to GQAM or create a class that specializes WorkloadBehavior and introduce this new property. Additionally, the 'workload' property name can be renamed into 'flow' to avoid creating confusion.

To avoid this new association for WorkloadBehavior, this resolution proposes to remove the
association itself. It is not really needed since WorkloadBehavior already has the composite
association with the two concepts that are part of an EndToEndFlow (WorkloadEvent and
BehaviorScenario).

Notions of kind and nature are shared between allocation and assignment. Related enumerations AssignmentKind and AssignmentNature describe the same concepts and are redundant. Proposed resolution: remove assignment enumerations and relate the Assign stereotype attributes to AllocationKind and AllocationNature

Disposition: See issue 14841 for disposition

Update the GCM ClientServerPort to take into account evolutions in UML 2.3 (introduction of conjugated port)

The issue refers to the introduction in UML 2.3 of the property “isConjugated” on the metaclass
Port. It means that the property “isConjugated” is no longer needed on the stereotype
“ClientServerPort” from MARTE since ClientServerPort extends Port.
The revised text describes required modifications to the MARTE specification. Note that, even
though the issue does not mention it, FlowPort are also concerned by this evolution of UML ports.
The “revised text” section also describes modifications required by the stereotype FlowPort.

TimedObservation is an abstract stereotype that extends TimedElement without adding new features. It is sublassed by the concrete TimedDurationObservation and TimedInstantObservation. Given that it cannot be directly used, and for the sake of smplicity, removing the stereotype may be considered

Stereotype TimedObservation was created for consistency with the UML
Specification and considering that TimeExpression would refer to
TimedObservation directly without deciding on the actual specialization.
The stereotype can be removed with no harm. TimeExpression will refer to
(untimed) Observation instead. Even though the semantics is weakened, there is
no actual impact since the association between TimeExpression and Observation
is not actually serialized by any tool.
Though, it should be noted that TimedObservation cannot be removed from the
Domain View since it is actually used by DurationPredicate and TimePredicate.

PortGroup concept used in Annex A.2 is not defined in the MARTE profile

Port Group concept has been removed in AADL v2 and a more generic concept
(feature group) has been introduced. The mapping towards MARTE is defined in
issue 14866.

For the sake of simplicity, SecondaryScheduler should be an association of the Scheduler instead of a specialized class. Making this concept relative would provide means to support more than two-level schedulers. Requires changes in the meta-model and the profile

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

In the GQAM domain model, the multiplicity of the AnalysisContext.workloadBehavior is 1. In the profile, the multiplicity of the stereotype attribute is *. Proposed resolution: align on the profile and make it *.

Make it * in Fig 15.2 and Sec F10.2. Also there is a dangling phrase in Sec F10.2

AnalysisContext is the root of the GQAM model. In the first paragraph of the domain model, it is mentioned that an analysis context contains two parts: workload behavior and resource platform. AnalysisContext should specify composition relationships with WorkloadBehavior and ResourcePlatform (Figure 15.2)

Disposition: Closed, no change

The provide a full MARTE AADL alignment, upgrade platform concepts with AADL 1) virtual bus 2) virtual processor concepts

Renumber section 2.4.4 in 2.4.6 Device
Add section 2.4.2 Virtual Processor
A virtual processor represents a logical resource that is capable of scheduling and
executing threads and other virtual processors bound to them. It will be represented as a
MARTE “swSchedulingResource” AND “ProcessingResource” stereotyped UML
Classifier
Add section 2.4.4 Virtual Bus
A virtual bus component represents logical bus abstraction such as a virtual channel or
communication protocol. It will be represented at resource level as a MARTE
“CommunicationMedia” stereotyped UML connection or classifier allocated to the
physical HWBus.
• If the communication media represents a bus, and the clock is the bus speed, "element size" would be the width of the bus, in bits.
• If the communication media represents a layering of protocols, "element size"
would be the frame size of the uppermost protocol.
Disposition: Resolved

The provide a full MARTE AADL alignment, upgrade software concepts with AADL 1) abstract component, 2) prototype, 3) threadgroup, 4)subprogram group concepts

In AADL v2, the concepts of abstract component, prototype, thread group and
subprogram group have been added and have be taken into account by MARTE
to ensure a full AADL v2/MARTE alignment.

AADL v2 has be voted.
Upgrade introduction texte to position MARTE according the new version of the AADL standard

Replace first sentence with
“
AADL is a RTES design and analysis language and standard referenced at the
SAE (standard number XXX). Version 2 has been voted in XXX. This section
presents the correspondence between MARTE 1.0 and AADL 2.0 concepts, with
the aim to clarify which subset of MARTE concepts shall be used to explicit
AADL concepts. The MARTE profile has be adopted as the UML profile for
AADL, so this section presents the MARTE2AADL concepts correspondence.
The section is not a methodology to design AADL applications in UML. “

Upgrade MARTE AADL summery table upgrade according resolved issues

see pages 59 - 62 of ptc/2010-08-30 for resolutoion

Upgrade AADL component declaration relationship to a AADL component implementation (UML Realization -> UML Component Realization)

An AADL component type specifies the external interface of a component that its
implementations satisfy. It contains declarations that represent features of a
component and property associations. An AADL component implementation
represents the realization of a component in terms of subcomponents, their
connections, flow sequences, properties, component modes and mode
transitions. UML 2 “Realization” semantics makes references to a specialized
abstraction relationship between two sets of model elements, one representing a
specification and the other representing an implementation of the latter. The UML
2 “ComponentRealization” concepts refine the “Realization” concepts, reducing
the subset of linked elements to UML Components and Classifiers. This concepts
suits better the the AADL component type/implementation relationship.

The notion of assembly/delegation connectors between ports and subcomponents has to be clarified in the MARTE AADL annexe.

Same issue as 14864
Disposition: Closed, no change

The whole AADL features group concepts can't be represented in MARTE

Precise the mapping perimeter and semantics of "inverse of"

Feature Group is a new aadl v2 concept.
An AADL feature is part of a component type definition that specifies how that
component interfaces with other components of the system. Features represent
ports, subprogram and subprogram group accesses, parameters, and data and
bus accesses.
Feature group represents groups of component features, features group can
contain feature group, and can be use anywhere features can be used. Inside a
component, each feature can be connected individually, outside a component a
feature groups can be connected as a single unit.
A feature group type can be declared to be the inverse of another feature group
type, which specifies that the feature types will remain the same but that the
“direction” will be the opposite: so service provided/ required qualifier, flow
direction, the parameter passing mode will be automatically deduced.
In UML concept, the notion of port group, as group of ports, doesn’t exist. We
use a symmetrical solution, meaning the possibility to refine and compose
interfaces typing ports as alternative to physical connection point assembly.
The MARTE AADL mapping perimeter will be restricted to data access and
subprogram access.
In order to provide a homogeneous representation for designers, align with data
access and subprogram access, feature group will be represented as an UML
interface composed by at least two attributes (representing more than one data
access) or two subprogram access (representing more than one subprogram
access). By default, the interface is provided.
UML delegation/assembly connection represents AADL feature group access. In Threads and Processes subcomponents, constituting the system
subcomponents, internal ports will be typed by interfaces representing the
FeatureGroup subtypes, like unitary or composed data/subprogram access

The AADL flow path implementation semantics is not in line with MARTE mapping proposition.
The AADL flow path declaration and implementation mapping need to be rethink

AADL flow semantics has been introduced to specify information transmission
(data/event) over connection and subcomponent, covering the whole component
and subcomponent hierarchy. This aspect is complementary to the structural
one.
Declaration flow paths links flow sources to flow sinks of components in a black
boxes approach.
Implementation flow paths specify the way this information is convey over
connections and flow paths.
End-to-end flows represent a logical flow of data and control from a source to a
destination through the system instance, meaning a sequence of threads that
process and possibly transform the data. The corresponding end-to-end flow
instance is determined by expanding the flow specifications through their flow
implementations.
As UML/MARTE concepts makes a full distinction between logical and structural
aspects, and while AADL manipulates them jointly, different and not full satisfying
solutions can be provided to represent AADL flows and end-to-end-flows.
• UML sequence diagrams, using message exchanges between instances
and associated ports
• UML activity diagrams, more focusing on actions and their associated
control flow. Flow path declaration representation will stay unmodified, using the UML
“InformationFlow” concept.
Flow path implementation will be represented in a sequence diagram, using UML
“GeneralOrdering” elements to keep order preservation between messages
received and sent over the ports, UML “Messages” will be used to represent
communication between instances. The Name of the GeneralOrdering element
will make reference to the FlowPath declaration; the name of the message will
make reference to the connection conveying it.
To provide a representative distinction and to avoid code generation ambiguity
between end-to-end flow and flow implementation representations, both
represented as sequence diagrams, the first one will be stereotyped “end-to-end
flow”, the second one, will have the suffix: Flowname_flow_impl.
AADL flow sinks and flow sources can’t be represented in UML/MARTE.

The notion of assembly/delegation connectors between ports and subcomponents has to be clarified in the MARTE AADL annexe.

No Data Available

Two ways of modeling Data existe in AADL: the one using the AADL Data annexe modeling features, the other one relying on a pure structural view.
The first solution is currently addressed by the MARTE AADL annexe.
The annexe has to be upgraded to take into account the second way of doing.

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

All examples related to RtFeature in section 13.4.1 are out of date with respect to the definition of RtFeature stereotype that is in Beta 3 associated to a RtSpecification. They have to be updated accordingly.

The issue actually refers to figures 13.14, 13.15, 13.16, 13.17, 13.18, 13.19 and 13.20. Most of
the resolution consists in adding stereotype « rtSpecification » to comments associated with
«rtfeatures». See details in the revised text.

Both stereotypes Assign and Allocate have a properties called impliedConstraint. Do we need this additional attribute because indeed a NfpConstraint being a extension of the UML constraint can be apply on any elements.
Or if we need, could these properties be derived?

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

Both Allocation and Assigne stereotype use their onw enumerations for defining their nature and kind. For simplification, they should use the same enumerations.

Replace AssignmentNature by AllocationNature and remove the definition of
AssignmentNature.
Replace AssignmentKind by AllocationKind and remove the definition of
AssignmentKind

GQAM::RequestedService metaclass has no definition in Annex F.

A subsection must be inserted after F.10.13 with the definition. Also, Fig 15.3 is
missing the attributes of Step which define the requests, and these should be
added.

The description of the Meta class BehaviorScenario is not synchronized with its representation in diagramm shown in FIgure 15.3. As for example, associations called steps in the diagram and called Actions in section F.10.13 (idem issue with assoc labelled inputstream in the section F.10.3 and called cause in diagram 15.3).

No Data Available

The defintnion of the Trigger concept says: "A Trigger specifies the event and conditions that may trigger a behavior execution.". However, there is nothing in its features (associations or attributes) that will support the concept of condition mentioned in the defintion of Trigger.

This is a conceptual entity, there is no stereotype associated. The semantically closer
element that have a stereotype is the …. GQAM::GaWorkloadEvent plus its
GaWorkloadGenerator. They do have the necessary attributes. I suggest Close No
Change.
Disposition: Closed, no change

The description of the semantics of TimedObserver in section F10.18 has to be aligned with its description denoted in the diagram shown in figure 15.4. TimedObserver can refer to several start and end events.

{Fig 15.4 shows multiplicity * for both start and end events. Sec F10.18 shows
multiplicity 0..1 for both... this should be changed to *. Since there may be
several pairs of events, the associations must be ordered to express the
correspondence. Since the is also an attribute laxity for each pair, it must also be
multiple and ordered.
Also there is confusion in the naming of the associations: startObs and endObs
in the text in F10.18 and of Ch 15 for domain and UML, and startEvent and
endEvent in the formal definition of F10.18 and in Fig. 15.4, and in the profile
definition (sec 15.3.2.14). One or the other should be used consistently. Since
startEvent/endEvent is rather generic, and indeed is also used in the Core
domain model in another sense, it is preferred to standardize on startObs and
endObs.

The stereotype NFPConstraint owns a property to denotes in which modes the constaint is attached. The metaclass NFP_Constraint defined in the domain model of MARTE should be updated to reflect that property.

The domain model already showed the Nfp_Constraint’s relationship to a Mode (Fig. 8.3)
Disposition: Closed No Change