I was wondering, why two kinds of observators was designed within the GQAM as denoted in the figure shown below:

Why not gathering both into one single stereotype? I propose to keep the second one, GaLatencyObs.

In addition, I was also wondering why the <<SaSchedObs>> stereotype defined within SAM was not inheriting from <<GaLatencyObs>> instead of <<GaTimedObs>>?

What do you think?

Clarification text on possible joint usage of GaLatencyObs and SaSchedObs

GaLatencyObs specializes GaTimedObs to collect duration between two events which can be used in more domains than schedulability, while
SaSchedObs is used to collect schedulability related metrics. The specified specializations are coherent with the intented usages.

The specification misses a high level description introducing the usage of SaSchedObs. This resolution adds this text to the specification and fixes a typo related to GaTimedObs.

Mix-criticality systems have the need to include allocated (or assigned) in the same model, representing either hardware or software platforms, elements with different levels of criticality. Eventually, for different levels of criticality different versions of the modelling element may need to be used. To handle this multiversions of modelling elements as well as to indicate the level of criticality at which a concrete condition expressed in a constraint must hold, there is the need to attach a level of criticality to the NFP_Constraint element in the MARTE profile.

The simplest way to have this available in MARTE is by adding to NFPConstraint an attribute of the type NFP_Integer, called "Criticality".

This would need a change in Figure 8.3 (page 41) , Figure 8.5 (page 44) , and the texts describing the NFPConstraint stereotype in cluse 8.3.2.5 on page 47 and the NFP_Constraint domain element in clause F.2.12 on page 566, by adding the attribute: criticality: NFP_Integer [*] Value(s) that defines the level(s) of criticality at which the NFP constraint must hold.

In a separate issue we express also the need to annotate criticalities for NFP Valuse, but for the sake of easying the resolution of the two issues please consider in this issue only the annotation of criticalities to NFP constraints.

Criticality is a designation of the level of assurance against failure needed for a system component. A mixed criticality system is one that has two or more distinct levels (consider for example safety critical, mission critical and non-critical). Reviewing the standards in the field (IEC 61508, DO-178B, DO-254 and ISO 26262 standards) they propose to use up to five levels. Then, in general an integer value represented with NFP_Integer is sufficient to annotate the criticality level for a value or a constraint.

NFP_Constraint criticality attribute

This proposal adds an attribute criticality to NFP_Constraint and creates a NFP_Type named NFP_Criticality to capture criticality levels.

The current MARTE specification contains 11 composite aggregation Stereotype properties typed by a Stereotype. This is not allowed by UML (Clause 12.3.3.4) : "The type of a composite aggregation Stereotype Property cannot be a Stereotype (since Stereotypes are owned by their
Extensions) or a metaclass (since instances of metaclasses are owned by other instances of metaclasses);".

The type of aggregation shall be changed to "reference". There are 11 changes to be done in HRM subprofile and one in Time subprofile.

Remove composite aggregations types for Stereoypes properties

Change the aggregation types from composite to reference for Stereotypes properties. These changes should be done on figures: 9.29, 9.30, 11.4, 11.5, 14.65, 14.66, 14.67, 14.68, 14.69, 14.72 and 14.73.
These changes have impact on the XMI file.

The Carbon footprint is an interesting property for Hardware resources as well as Software ones. In fact, nowadays it is important to evaluate the CO2 footprint of a system (a laptop, a data center…).
This criteria is depending on the usage of the resources (mainly for the software resources).
We suggest adding a new property « co2Footprint » either in the “ResourceUsage” Stereotype” or in the Resource Stereotype for more general cases.

The unit that measures the carbon Footprint is Kg of carbon dioxide equivalent (KgCO2e) per Year. This implies the addition of a new dimension in the Marte::MeasurementUnits «CarbonUnitKind» with new unit « kgCO2e » as well as a new NFP_Co2footprint that inherits from NFP_Real with unit = kgCO2e.

The value of the CO2Footprint can be proportional to the origin of the energy used to produce the device in kWh eqC02. The proportional factor is country dependent https://app.electricitymaps.com/map

Include a CarbonFootprint property

Include a CarbonFootprint property to ResourceUsage.

In some case, when PeriodicServerParameters are used to model the parameter of a PSS (Posix Sporadic Server). it's happen that in some cases some SoftwareSchedulable resources could have the same background priority. So, to identify which one must be executed we need another parameter : order

it is possible to add a property like this:

order: NFP_Integer to the PeriodicServerParameters DataType.

MARTE 1.2 Specfication already provides this capability

This is already supported by MARTE by the use of hierarchical schedulers.

The mappings between the analysis arrival patterns (periodic, sporatic, …) and Time durations, and clock constraints in CCSL should be defined in the specification.

The two modelling approaches are not converging.

The two modelling approaches are not converging so far and used for different purposes in different contexts.

The MARTE 1.2 profile PDF are released and accessible, but the XMI files are only available by Member login.

MARTE 1.2 XMI files are accessible

The MARTE XMI files are accessible here: https://www.omg.org/spec/MARTE

Mix-criticality systems have the need to host for a concrete magnitude (e.g. WCET) different values, each corresponding to a different level of criticality.

The simplest way to have this available in MARTE is by following the same approach used for the source qualifier, this is by including an attribute of the type NPF_Integer (or even integer), called "CriticalityLevel" in NFP_Common_Type.
This way the currently available versions of the MARTE profile do not need to be updated; only the parsers of VSL values commited to support mixed critical systems would need to be modified to parse the criticality attribute on VSL values if present.

This would need a change in Figure D.5 and the text describing the NFP_Common_Type on page 504, by adding the attribute: criticalityLevel: NFP_Integer [*] Value(s) that defines the level(s) of criticality at which the NFP annotation is valid.

In a separate issue we express also the need to annotate criticalities for NFP_Constraints, but for the sake of easying the resolution of the two issues please consider in this issue only the annotation of criticalities to NFP values.

Criticality is a designation of the level of assurance against failure needed for a system component. A mixed criticality system is one that has two or more distinct levels (consider for example safety critical, mission critical and non-critical). Reviewing the standards in the field (IEC 61508, DO-178B, DO-254 and ISO 26262 standards) they propose to use up to five levels. Then, in general an integer value (better if represented with NFP_Integer) is sufficient to annotate the criticality level for a value or a constraint.

Adding NFP_Criticality in NFP_CommonType

To accommodate for the necessary values to express criticalities for any NFP value, the proposal is to:
Create a new NFT type called NFP_Criticality inheriting from NFP_Integer with its value being the integer number to use for the criticality and two additional optional attributes:
literal: String [0..1]
standard: String [0..1]
Typical values for them would be “ASILA”, “ASILB” or “ASILC” for the attribute denominated literal and “RAAML” or “ISO26262” for the attribute called standard.
An attribute of this type, NFP_Criticality, is to be added under the name of criticality to NFP_CommonType, this is, adding the attribute:
criticality: NFP_Criticality [*]

Concrete changes would be:
Change Figure D.5, in page 500, to this:

In clause D.2.7 NFP_CommonType, in the section of the attributes add:
criticality: NFP_ Criticality [*]

Insert a clause D.2.8 NFP_Criticality between "D.2.7 NFP_CommonType" and current clause "D.2.8 NFP_DataTxRate, NFP_Frequency, NFP_Length, NFP_Area, NFP_Power,
NFP_DataSize, NFP_Energy, NFP_Weight" with the following contents

Generalization
• NFP_Integer
Attributes
• literal: String [0..1]
A string representing the label given to the corresponding level of criticality in the context of the concrete annotated model and the standard used to express it, if given. Typical values to this attribute might be “ASILA”, “ASILB” or “ASILC” for example
• standard: String[0..1]
A string indicating the nominal syntactical frame, usually a safety standard in which the label assigned to the corresponding criticality level is to be considered. Typical values for this attribute would be "IEC 61508/61511", "DO-178C", "DO-254", "RTCA DO-297", “RAAML” or “ISO 26262” to mention just some of which might be used to delimit a domain for which various criticality levels might need to be expressed.

In the current UML metamodel, there is no link from the metaclass Observation to a ValueSpecificaiton that can be used to specify the time value of the Observation. As a result, it is not possible to directly assign time values to TimedInstantObservation or TimedDurationObservation.

This means that it is not possible to refer to the time values of such observations in a time expression.

One easy solution is to create an association from the TimedObservation stereotype to the UML ValueSpecification metaclass (role name "value"). This could then be used to store the time value associated with either kind of time observation.

Add associations to UML ValueSpecification from TimedInstantObservation and TimedDurationObservation stereotypes

Modify the UML representation by:

• adding value role of type ValueSpecification to TimedInstantObservation and TimedDurationObservation stereotype
• no need to modify the domain model because the issue of the missing value placeholder comes from UML

The notion of "access connection" needs to be explicited in the AADL annex (A.2) of MARTE

add notion of access for AADL port

Add new definition of "access property" to a connection in the section 4.2.6.2 page 404

Fix the Issue by adding a "Access property" to the link between two aadl ports

Previous discussions between the SysML and MARTE communities have allowed relationships between both languages. An important convergence area relates to the notions of quantities, unit and dimensions. The SysML 1.2 RTF and the MARTE FTF work resulted in the definition of the QUVD meta-model (SysML Annex C.5). The MARTE NFP profile has not been yet entirely aligned on the QUVD meta-model. It would need aligned stereotyped when applicable (e.g. dimension vs. quantity type)

Out of RTF scope

The MARTE NFP profile and the QUVD meta-model have different scopes, and use different modeling approaches. Some mapping rules between a subset of the NFP profile and the QUVD meta-model (and vice-versa) could be done, but would require changes that are not achievable in the scope of an RTF.

[Time: Examples] One important specification feature in the embedded system domain is the Timing diagram. I propose to include examples to illustrate the use of the MARTE observation concepts and time expressions with Timing Diagrams

MARTE 1.2 Specification already provide this capability

MARTE 1.2 provides Timing examples for the most used UML diagrams including sequence diagrams. Coming to UML Timing diagrams (which are one specialization of UML interactions diagrams), duration observations are used in the same manner as in sequence diagrams, and instant observations are explicitly specified. Constraints refering to those observations are used in the same way for all diagrams.

GaScenario has the attribute utilization. Its definition is : “The occupancy of the scenario, computed as the mean number of scenario instances active at any one time.”. What does “occupancy” mean?

Clarification of the description of Utilization property.

Clarification of the description of Utilization attribute.

In the SRM meta-model, the SwResource specializes ResourceManager which makes SwSchedulableResource themselves. SwResource should be a direct specialization of Resource, like its hardware counterpart.

Misunderstanding of the MARTE specification

Software resource and Hardware resource are of different nature. Software resources gather bith the resource itself and the management of these resources. A detailed explanation of this inheritance is given in section 14.1.2.1 (MARTE 1.2) describing the SW_ResourceCore Package.

When a shaped port belongs to a shaped part, one should understand its shape as the product of both shapes as stated in the definition of the tiler. This should be stated here for the case when the reshape stereotype can be ommitted.

The issue description is not clear.

The issue description is not clear. Due to the long time since its submission, the reporter does not remember anymore what kind of precisions should be provided and proposed to close the issue.

p16 6.4.1 5th bullet

This latter annex described [...] for defining the UML profile for
MARTE itself, but also usefull for user models.

-> MARTE itself while also being useful for user models.

p17 3rd para (last before 6.4.3)

[...] firstly we try to reduce the size of
stereotype names as much as possible, but without scarifying their meaning

-> sacrificing

Globally replace contraint by constraint and Contraint by Constraint.
Occurrences:
p42 1st para (NFP_Contraints)
p56 1st para 2nd line (Contraint)
p56 2nd para 1st line (NFP_Contraints)
p326 16.3.2.6 (Contraints)
p327 16.3.2.7 (Contraints)
p328 16.3.2.8 (Contraints)
p444 B.3.2.1 (Contraints)

Globally replace brokedResource by brokeredResource :
p99 Figure 10.11 association from ResourceBroker to Resource
p99 Figure 10.11 association from Scheduler to ProcessingResource
p243 Figure 14.58 association from HW_Media to HW_Arbiter
p606 F.4.22 Associations 1st bullet
p610 F.4.30 Associations 1st bullet
p653 F.9.8 Associations bullet
p678 F.9.48 Associations bullet

p100 Figure 10.13 upper left corner

Causaility::CommonBehavior::

-> Causality::CommonBehavior::

p104 Figure 10.18 class ResourceUsage last attribute

enery:NFP_Energy

-> energy: NFP_Energy

Globally replace occurence by occurrence and Occurence by Occurrence :
p145 ReceiveOccurence (5x)
p203 Figure 14.13 OccurencePolicyKind (2x), occurenceCountElements

p188 Figure 13.12 statebox with start state

Invation
action

-> Invocation

p230 paragraph below Figure 14.40

Figure 14.41 illustrates [..] (from UML::CompositesStructures::InternalStructures

-> CompositeStructures

p231 paragraph below Figure 14.42

[...] On the right side, the SRM profile is used
to describe the MemoryPartiton

-> MemoryPartition

Globally replace symetricalArray by symmetricalArray :
p240 Figure 14.55 PLD_Class 1st attribute
p250 Figure 14.66 PLD_Class 1st attribute (figure is duplicate of 14.55 ?)
p274 Description 1st bullet
p682 F.9.57 Literals 1st bullet

p266 Attributes 4th bullet

• throughput:NFP_DataTxRate
  Speciifes the throughput in a memory.

-> Specifies

Replace frequeny by frequency :
p269 HwProcessor Constraints

[3] ipc must derive from mips attribute and clock frequeny

p672 F.9.39 Constraints

[3] ipc must derive from mips attribute and clock frequeny

p270 HwResource Associations 4th bullet

• endPoints: HwEndPoint[0..*]
  Specifies the connection points of the HwReource.

-> HwResource

Globally replace adaptative by adaptive and Adaptative by Adaptive :
p243 Figure 14.58 class HW_Router 2nd attribute (isRoutingAdaptative)
p253 Figure 14.69 class HwRouter 2nd attribute (isRoutingAdaptative)
p272 HwROM Attributes 2nd bullet (isRoutingAdaptative)

Specifies whether the HW_Router supports adaptative routing or not.

p677 F.9.46 Attributes 2nd bullet (isRoutingAdaptative)

Specifies whether the HW_Router supports adaptative routing or not.

p306 Attributes 8th bullet

• utilizationOnHost: NFP_Real[*]
  The occupancy of thehost processor, executing Steps [...]

-> the host

p307 15.3.2.13 Attributes 2nd bullet

• blockT: NFP_Duration [0..1]
  A delay inserted in the execution of the Step, waiting for an event [...],
  or for a condition such as the availability of passive protected resources nedded

-> needed

p311 16.1 2rd para 2nd sentence

[...] aids developers to detect potentially
unfeasible real-time architectures

-> infeasible

p321 Figure 16.8 class SaSchedObs 1st attribute

suspentions: NFP_Integer [*]

-> suspensions

p323 3rd bullet from top of page

• timing: TimedObs [*]
  Set of timing requirements or preditions that constrain local fragments

-> preconditions

p325 16.3.2.5 Attributes 2nd bullet

• ISRprioRange: NFP_IntegerInterval [0..1]
  Range of ISR priorities supporte by the platform.

-> supported

p333 16.3.3.4 4th sentence

[...] The software that
hendles this is usually not part of the application

-> handles

p341 17.2.2.6 1st para

3. [...] This may be a
middlware layer (a web services connection,

-> middleware

p376 A.2.1.7 1st para 2nd sentence

If not, they will be added through “NFP” and “NFP constraints”, precising the MARTE
characteristics.

Replace precising by tightening.

p383 A.2.3.2 table cont'd, 1st row left column

Deactive_execution_time (specific for mode switch) and
Deactive_deadline (specific for mode switch)

There is no such word deactive Please clarify.

p383 A.2.3.2 table cont'd, 2nd row right column

[...] “NFP” attributes by the enduser within the different threads

-> end user

p385 table 5th row right column

<<swSchedulableResource>>
hybride_task : my_comp

-> hybrid_task

p386 sentence between diagrams

This model library is then instanciated:

-> instantiated

p393 table AADL Properties right column heading

Marte Anaysis

-> Analysis

p395 table cont'd from p394 right column heading

Marte Anaysis

-> Analysis

p395 A.2.4.6 4th sentence

Alternatively, they may require driver softwares [...]

-> programs

p399 1st table right column AADL View

thorttle_command: out data port

-> throttle_command

p404 A.2.6.3 4th para

In MARTE, the FeatureGroup semantical perimenter will be [...]

-> perimeter

p415 Table A.1 2nd row 4th column (MARTE Stereotype)

refering to an RtSpecification to denote

-> referring

p461 B.3.3.15 2nd para 2nd sentence

When specifiyng values making reference to properties

-> specifying

p484 C.3.1.3 Constraints

definingEvent->None.mpty( ) = defBody->isEmpty( ) }

None.mpty looks incorrect, please clarify.

p514 D.4.9.1 1st sentence

This is a ChoiceType that [...] to express an offline time trable

-> table

p554 F.1.14 Associations 2nd bullet

Instance that starts the invocartion.

-> invocation

p557 F.1.19 Attributes 2nd bullet

* / upper : UnilimitedNatural

-> UnlimitedNatural

Globally replace AccesControlPolicy by AccessControlPolicy :
p595 F.4.1 (2x), F.4.2 (2x)
p601 F.4.14 Generalizations
p612 F.4.32 Generalizations

p604 F.4.20 Associations 4th and 5th bullet

• provided: MARTE::NFP_Modelig::NFP_Declaration::NFP
  [...]
• required: MARTE::NFP_Modelig::NFP_Declaration::NFP

-> NFP_Modeling

p609 F.4.27 Semantics 5th sentence

[...] Two general forms of usage are defined the
StaticUsage and the DinamicUsage,

Two general forms of usage are defined, the
StaticUsage and the DynamicUsage, [...]
(comma after defined and spelling of DynamicUsage)

p609 F.4.29 Generalizations

* ConcurrencyResource (fromMARTE::GRM::ResourceTypes)

-> from MARTE

p610 F.4.29 Associations 2nd bullet

* dependentScheduler: MARTE::GRM::scheduling::SecondarySceduler

-> SecondaryScheduler

p626 F.6.13 Attributes

Drection of the flow property: either incoming (in),

-> Direction

p629 F.6.21 Semantics

This concept matches the CompositeStructures::InternalStructures::StructuredClassier

-> StructuredClassifier

Globally replace Concurency by Concurrency :
p629 F.7.1 CallConcurencyKind (title and text)
p630 F.7.3 ConcurencyKind (title and text)
p632 F.7.7 Attributes CallConcurencyKind

p635 Associations 1st bullet

* behaviors: RtBehaviror [*]

-> RtBehavior

p644 F.8.17 Associations 1st and 2nd bullet

• readServices: BehaviroalFeature
  [...]
• writeServices: BehaviroalFeature

-> BehavioralFeature

p644 F.8.18 Associations

* accessedElement: CoreElements::Foudations::Property

-> Foundations

p665 F.9.29 Semantics 2nd para

refined to a detailed model for [...] or ISS (Instuction Set Simulator)

-> Instruction

p672 F.9.39 Constraints

[3] ipc must derive from mips attribute and clock frequeny.

-> frequency

p674 F.9.42 Associations 1st bullet

• endPoints: HW_Communication::HW_EndPoint [0..*]
  Specifies the connection points of the HW_Reource.

-> HW_Resource

p685 F.9.63 Attributes 3rd bullet

Specifies that the swithcing type is other than packet [...]

-> switching

p693 F.10.15 and F.10.16

Constaints

-> Constraints

p700 F.11.5 Attributes 2nd bullet

Range of ISR priorities supporte by the platform.

-> supported

p705 F.12.6 Attributes 2nd bullet

• behaviorDemand: PBehaviorDemand [*]
  Set of demand sfor a behavior described by a scenario, [...]

-> demands for

p713 F.13.9 DataType (from DataTypes)

DateType matches with the UML concept of [...]

-> DataType

Typo fixes

This issue gathers typos in MARTE 1.2 specification and provides fixes for these issues.

The domain model of SAM defines the concept of EndToEndFLow which is described as being a container for a set of request event streams that trigger processing flows (identified as WorkloadEvent in the figure 16.3) and a set of end-to-end execution scenario (identified as BehaviorScenario in the figure 16.3) as response to a related set of request event stream.

The domain model of GQAM defines the of WorkloadBehavior which is described as being a container for a set of behaviors defined as Scenario and a set of demands defined as WorkloadEvent. WorkloadEvent are defined as the cause of the Scenario. In this context, this latter is considered as being the effect of a WorkloadEvent.

This specification raises both next issues:

• Firstly, the stereotype «SaEndToEndFLow» introduced to map the SAM domain model element EndToEndFLow does not have properties fitting the endToEndStimuli and endToEndResponse properties of this latter. Consequently, the specification of stimuli and responses of a SaEndToEndFlow has to be done implicitly within the user model using containment relationships of the UML. The issue with such modeling mean is that the relationship between the SaEndToEndFlow and its containment is less formal and relies on specific means/choices to model the link between the SaEndToEndFLow and its stimuli and scenarios.
• Secondly, the duality between both concepts, EndToEndFLow and WorkloadBehavior, seems to introduce unnecessary complexity. I would like to propose to define EndToEndFlow as a specialization of WorkloadBehavior, where both endToEndStimuli and endToEndResponse would refine respectively demand and behavior properties of the WorkloadBehavior concept.

Miscellaneous:

• In figure 16.3, EndToEndFLow has an association toward SAM_Obsrever::TimedObserver. A priori, it should be SchedulingObserver instead of TimedObsever.
• In section “16.3.2.7 SaSchedObs”, SaSchedObs should inherit from GaTimedObs and not TimedObs as shown in figure 16.8.
• In section “16.3.2.1 SaEndToEndFlow”, the timing attribute should be typed as SaSchedObs and not TimedObs.

Refine SAM EndToEndFlow definition from GQAM WorkloadBehavior definition

SAM EndToEndFlow concept is defined as a specialization of GQAM WorkloadBehavior, and the SaEndToEndFlow stereotype as a specialization of GaWorkloadBehavior stereotype. The SaEndToEndFlow stereotype provides now the placeholders for the formal specification of the end-to-end flow stimuli and response. This change is implemented with updates of text and figures accordingly in section 16 and Annex F.11.

As explained in section 16.2.3 in SAM there are two kinds of Timed Observer that are used (LatencyObserver and SchedulingObserver). So figures 16.3 and sections 16.3.2.7 and 16.3.2.1 content is correct wr.r.t Timed Observers.

Can someone clarify the meaning of the pop attribute of the «GaWorkloadGenerator» stereotype?

Add semantics description for pop attribute

The description of pop attribute is missing.
Add a semantics description for pop attribute in section 15.4.2.17.
Add the population attribute and its description in section F.10.21 page 697

In the context of ARINC653 (but in other cases as well), we need to specific that a Periodic Pattern or Aperiodic or Sporadic is synchronise with the partition (schedulable Resource). that mean this king of events pattern starting synchronously with the partition (that mean the reference is the partition)

So, could add this feature to MARTE to model Partition synchronised events whatever it is periodic, sporadic or aperiodic

Issue Deferred

Issue Deferred

Having icons and symbols for stereotypes improves models comprehesibility. For instance, HRM and SRM chapters provide graphical representations for most of the stereotypes. However, the GRM subprofile, which is shared by other chapters (analysis modeling parts of MARTE), has not such graphical representation. We propose to add icons and symbols (likely similar to SRM and HRM's ones) to GRM stereotypes.

Deferred to next version of MARTE

The idea is interesting and can be applied to all other MARTE subprofiles.

In the context of ARINC653 (but in other cases as well), we need to specific that a Periodic Pattern or Aperiodic or Sporadic is synchronise with the partition (schedulable Resource). that mean this king of events pattern starting synchronously with the partition (that mean the reference is the partition)

So, could add this feature to MARTE to model Partition synchronised events whatever it is periodic, sporadic or aperiodic

Having icons and symbols for stereotypes improves models comprehesibility. For instance, HRM and SRM chapters provide graphical representations for most of the stereotypes. However, the GRM subprofile, which is shared by other chapters (analysis modeling parts of MARTE), has not such graphical representation. We propose to add icons and symbols (likely similar to SRM and HRM's ones) to GRM stereotypes.

In the current UML metamodel, there is no link from the metaclass Observation to a ValueSpecificaiton that can be used to specify the time value of the Observation. As a result, it is not possible to directly assign time values to TimedInstantObservation or TimedDurationObservation.

This means that it is not possible to refer to the time values of such observations in a time expression.

One easy solution is to create an association from the TimedObservation stereotype to the UML ValueSpecification metaclass (role name "value"). This could then be used to store the time value associated with either kind of time observation.

Deferred

Resolution of this issue is deferred to MARTE 2.0

The notion of "access connection" needs to be explicited in the AADL annex (A.2) of MARTE

Deferred

Defer the handling of this issue to MARTE 2.0

When a shaped port belongs to a shaped part, one should understand its shape as the product of both shapes as stated in the definition of the tiler. This should be stated here for the case when the reshape stereotype can be ommitted.

Deferred

Defer the handling of this issue to MARTE 2.0

Mix-criticality systems have the need to include allocated (or assigned) in the same model, representing either hardware or software platforms, elements with different levels of criticality. Eventually, for different levels of criticality different versions of the modelling element may need to be used. To handle this multiversions of modelling elements as well as to indicate the level of criticality at which a concrete condition expressed in a constraint must hold, there is the need to attach a level of criticality to the NFP_Constraint element in the MARTE profile.

The simplest way to have this available in MARTE is by adding to NFPConstraint an attribute of the type NFP_Integer, called "Criticality".

This would need a change in Figure 8.3 (page 41) , Figure 8.5 (page 44) , and the texts describing the NFPConstraint stereotype in cluse 8.3.2.5 on page 47 and the NFP_Constraint domain element in clause F.2.12 on page 566, by adding the attribute: criticality: NFP_Integer [*] Value(s) that defines the level(s) of criticality at which the NFP constraint must hold.

In a separate issue we express also the need to annotate criticalities for NFP Valuse, but for the sake of easying the resolution of the two issues please consider in this issue only the annotation of criticalities to NFP constraints.

Criticality is a designation of the level of assurance against failure needed for a system component. A mixed criticality system is one that has two or more distinct levels (consider for example safety critical, mission critical and non-critical). Reviewing the standards in the field (IEC 61508, DO-178B, DO-254 and ISO 26262 standards) they propose to use up to five levels. Then, in general an integer value represented with NFP_Integer is sufficient to annotate the criticality level for a value or a constraint.

Deferred

Defer the handling of this issue to MARTE 2.0

Mix-criticality systems have the need to host for a concrete magnitude (e.g. WCET) different values, each corresponding to a different level of criticality.

The simplest way to have this available in MARTE is by following the same approach used for the source qualifier, this is by including an attribute of the type NPF_Integer (or even integer), called "CriticalityLevel" in NFP_Common_Type.
This way the currently available versions of the MARTE profile do not need to be updated; only the parsers of VSL values commited to support mixed critical systems would need to be modified to parse the criticality attribute on VSL values if present.

This would need a change in Figure D.5 and the text describing the NFP_Common_Type on page 504, by adding the attribute: criticalityLevel: NFP_Integer [*] Value(s) that defines the level(s) of criticality at which the NFP annotation is valid.

In a separate issue we express also the need to annotate criticalities for NFP_Constraints, but for the sake of easying the resolution of the two issues please consider in this issue only the annotation of criticalities to NFP values.

Criticality is a designation of the level of assurance against failure needed for a system component. A mixed criticality system is one that has two or more distinct levels (consider for example safety critical, mission critical and non-critical). Reviewing the standards in the field (IEC 61508, DO-178B, DO-254 and ISO 26262 standards) they propose to use up to five levels. Then, in general an integer value (better if represented with NFP_Integer) is sufficient to annotate the criticality level for a value or a constraint.

Deferred

Defer the handling of this issue to MARTE 2.0

The mappings between the analysis arrival patterns (periodic, sporatic, …) and Time durations, and clock constraints in CCSL should be defined in the specification.

Deferred

The kinds of timing specification that can be done with arrival patterns are in an expressive domain (vocabulary, and abstraction intent) different than the one expected for the use of CCSL. But they are compatible in their usage over behaviorSpecifications. It may be good to have this mapping as a Library in the Annex C, but this does not invalidate the current specification. I suggest deferring again this issue for a possible future version of the standard.

Previous discussions between the SysML and MARTE communities have allowed relationships between both languages. An important convergence area relates to the notions of quantities, unit and dimensions. The SysML 1.2 RTF and the MARTE FTF work resulted in the definition of the QUVD meta-model (SysML Annex C.5). The MARTE NFP profile has not been yet entirely aligned on the QUVD meta-model. It would need aligned stereotyped when applicable (e.g. dimension vs. quantity type)

Deferred

This issue needs further discussion with the SysML group in order to converge on the profile design of the QUVD meta-model. For timing reason, we decide to defer the resolution of this issue in order to get this time and propose a common resolution with the SysML group.

Having icons and symbols for stereotypes improves models comprehesibility. For instance, HRM and SRM chapters provide graphical representations for most of the stereotypes. However, the GRM subprofile, which is shared by other chapters (analysis modeling parts of MARTE), has not such graphical representation. We propose to add icons and symbols (likely similar to SRM and HRM's ones) to GRM stereotypes.

Deferred

In principle I though of using those in SRM and HRM plus some for those not defined. But a detailed review must be done. I suggest deferring this issue for the next version of the standard.

[Time: Examples] One important specification feature in the embedded system domain is the Timing diagram. I propose to include examples to illustrate the use of the MARTE observation concepts and time expressions with Timing Diagrams

No consensus

No consensus has yet been reached on which diagram would be pertinent to insert in the specification itself.

The domain model of SAM defines the concept of EndToEndFLow which is described as being a container for a set of request event streams that trigger processing flows (identified as WorkloadEvent in the figure 16.3) and a set of end-to-end execution scenario (identified as BehaviorScenario in the figure 16.3) as response to a related set of request event stream.

The domain model of GQAM defines the of WorkloadBehavior which is described as being a container for a set of behaviors defined as Scenario and a set of demands defined as WorkloadEvent. WorkloadEvent are defined as the cause of the Scenario. In this context, this latter is considered as being the effect of a WorkloadEvent.

This specification raises both next issues:

• Firstly, the stereotype «SaEndToEndFLow» introduced to map the SAM domain model element EndToEndFLow does not have properties fitting the endToEndStimuli and endToEndResponse properties of this latter. Consequently, the specification of stimuli and responses of a SaEndToEndFlow has to be done implicitly within the user model using containment relationships of the UML. The issue with such modeling mean is that the relationship between the SaEndToEndFlow and its containment is less formal and relies on specific means/choices to model the link between the SaEndToEndFLow and its stimuli and scenarios.
• Secondly, the duality between both concepts, EndToEndFLow and WorkloadBehavior, seems to introduce unnecessary complexity. I would like to propose to define EndToEndFlow as a specialization of WorkloadBehavior, where both endToEndStimuli and endToEndResponse would refine respectively demand and behavior properties of the WorkloadBehavior concept.

Miscellaneous:

• In figure 16.3, EndToEndFLow has an association toward SAM_Obsrever::TimedObserver. A priori, it should be SchedulingObserver instead of TimedObsever.
• In section “16.3.2.7 SaSchedObs”, SaSchedObs should inherit from GaTimedObs and not TimedObs as shown in figure 16.8.
• In section “16.3.2.1 SaEndToEndFlow”, the timing attribute should be typed as SaSchedObs and not TimedObs.

Deferred

Defer the handling of this issue to MARTE 2.0

GaScenario has the attribute utilization. Its definition is : “The occupancy of the scenario, computed as the mean number of scenario instances active at any one time.”. What does “occupancy” mean?

Deferred

Defer the handling of this issue to MARTE 2.0

Can someone clarify the meaning of the pop attribute of the «GaWorkloadGenerator» stereotype?

Deferred

Defer the handling of this issue to MARTE 2.0

I was wondering, why two kinds of observators was designed within the GQAM as denoted in the figure shown below:

Why not gathering both into one single stereotype? I propose to keep the second one, GaLatencyObs.

In addition, I was also wondering why the <<SaSchedObs>> stereotype defined within SAM was not inheriting from <<GaLatencyObs>> instead of <<GaTimedObs>>?

What do you think?

Deferred

Defer the handling of this issue to MARTE 2.0

In the SRM meta-model, the SwResource specializes ResourceManager which makes SwSchedulableResource themselves. SwResource should be a direct specialization of Resource, like its hardware counterpart.

Deferred

Defer the handling of this issue to MARTE 2.0

There are many possible usages for the Allocation concept which cannot be restricted to those listed in the AllocationKind and AllocationNature enumerations.

The “kind” and “nature” attribute of both <<Allocate>> and <<Assign>> stereotypes should be optional (multiplicity: [0..1]). Alternatively, a literal could be added to the enumerations named above, such as “unspecified” or “other”, to address usages which are not covered by the existing literals.

Adopt proposal

I propose to adopt the first proposal that do not break anyway the forward compatibility of the MARTE profile. Anyway according to the diagram shown in figure 11.4, multiplicity of both properties kind and nature should be [0..1].
A priori, the same should be done for the assign stereotype.

problem:

In section 9.3.1.3, on figure 9.28, the ClockConstraint stereotype have three properties named "isCoincidenceBased", "isPrecedenceBased", "isChronometricBased". These three attributes refers to the kind of relation(s) resulting from the constraint enforcement. This kind of relation are described by three named bullets in the time model overview, chapter 9.1. The name of the bullets and the name of the properties should conform. These properties are described in section 9.3.2.2, the names should also refer to the bullet names.

proposed resolution:

rename the properties of the ClockConstraint stereotype to conform with the name of the bullet in section 9.1. The section 9.3.2.2 should be kept consistent with such changes.

Rename the properties

rename the properties of the ClockConstraint stereotype to conform with the name of the bullet in section 9.1. The section 9.3.2.2 should be kept consistent with such changes.

The type of the derived property RtSpecification::context is BehavioralFeature. It can be used to specify that the RtSpecification actually concerns a particular behavioral feature (i.e. Operation or Reception) exposed by a port (the port being identified by the RtFeature owning this RtSpecification).

This works well with ClientServer ports. However, it cannot be used to characterize flow properties of FlowPort, since a FlowProperty is a StructuralFeature, not a BehavioralFeature.

An easy solution to address that is to make the type of /context Feature, instead of BehavioralFeature.

Change text

Change RtSpecification::context: BehavioralFeature into RtSpecification::context: Feature.

Add the following :
McProcessor
The McProcessor stereotype maps the McProcessor domain element
Generalizations
HwProcessor
Attributes
Core_Id: NFP_Natural

Resolved

The Intention seems to be having a way to label the specific affinity or identification of all and each of the cores of a multi-core processor. This leads to include a new kind of Processor, called Hw_McProcessor, which inherits from Hw_Processor but add the Core_Id as an attribute.

Attribute schedulers : NamedElement [1] of SwSchedulableResource should be "scheduler : NamedElement [1]"

Update figure

Update the figure in question according to the proposal of the issue summary.

Currently HLAM::RtSpecification,RtFeature stereotypes allow modeling of real-time features for operations provided/required through ports at class level, while is not possible to use RtFeature/RtSpecifcation at "part with port" level. It would be useful to have this feature in order to be able differentiating quantitative attributes like deadline, period at part (i.e. instance) level in a composite structure diagram.

Enable to annotate the connector

If we add the possibility to annotate the parts with RtFeature, it may be ambiguous to distinguish the port of the part the RtFeature is applied on expect of we add an extra property to this stereotype to explicitly specify it when the stereotype is applied on a part. Consequently, we propose to enable to annotate the connector end linked to the port of the part. In that case, there is no ambiguity. Next revised text consists then of a description of all the subsequent changes needed to be done in the specification.

page 436, the IntervalType has the "intervalAttrib" attribute.

page 451, the IntervalType has both "minAttrib" and "maxAttrib" attributes.

The IntervalType attribute(s) should be the same ones.

Resolved

This issue actually refers to the following pages:

• Page 436: In figure B.7, stereotype «IntervalType» is depicted with on single property intervalAttrib
• Page 439: According to section B.3.2.4, sub-section Attributes, interval type carries two attributes, minAttrib and maxAttrib
  As suggested in the summary of the issue, the same attributes should be used in both cases. According to section F.13.18 (description of IntervalType from the domain model) and exemple of Figure B.9, intervalAttrib must be used.
  The proposed resolution consists in updating section B.7. Also, while the “associations” clause of F.13.18 is correct, the “semantics” clause still reference properties minAttribute and maxAttribute. In the proposed resolution, this “semantics” clause is also updated.

An extension to the HwMedia stereotype should be added to allow the modeling of Networks-on-Chips in addition to buses as the become more and more the communication media of choice for new generation systems-on-chips.

This HwRouter stereotype could have the following attributes:
+ fifoSize: NFP_DataSize
+ isRoutingAdaptative: NFP_Boolean
+ switchingType: SwitchingType
+ isSynchronous: NFP_Boolean
+ fifoLocation: FifoLocationSpecification

with the following definition of SwitchingType:
«Enumeration»
SwitchingType
paquetSwitching
circuitSwitching
other
undefined

and of FifoLocationSpecification:
«Enumeration»
FifoLocationSpecification
input
output
both

Accept proposed changes

As proposed in the issue text, a stereotype has to be added to the HwCommunication sub-profile. This impacts the summary of the HRM profile domain view (14.2.2), its UML representation (both the diagrams, 14.2.3.1, and the list of stereotypes, 14.2.3.2) and the description of the corresponding domain elements (F.9).

Add an attribute isInterleaved : NFP_Boolean to the MemoryOrganization tuple type do allow to discriminate between interleaved and non interleaved multi-bank memories

Modification may be done easily without introducing any compatibility issue.

N/A

The issue resolution for 12-63 aims to add an isInterleaved property to the MemoryOrganization stereotype. This resolution is not complete since the MARTE domain model is not updated at the same time than the profile.

Completion of Issue 12-63

Section 14.2.2.2 shall be updated to include new version of Figure 14.56. In this updated version, the Figure 14.56 shall show the property isInterleaved : NFP_Boolean in the MemoryOrganization concept.

We have detected an inconsistency between the semantic description and its mapping to UML for Protected Passive Unit (PpUnit). In figure 13.3 and in the Annex F.7.7, PpUnit inherits from BehavioredClassifier and SynchResource. But when you see the UML Representation (Section 13.3) in Figure 13.8, the PpUnit inheritance from BehavioredClassifier is taken into account by using it as the base elements to be extended with the stereotype. Its nature as synchronization resource is not explicitly mapped to UML.
For these reasons, and considering the need to link a PpUnit with its implementing mutual exclusion resources that we propose a PpUnit to have an additional attribute (with multiplicity 0..n) that includes the MutualExclusionResource that the existence of the PpUnit implies. Being a GRM:: MutualExclusionResource a specialization of SynchResource, this attribute maps the synchronization resource nature of the PpUnit as it is expressed in its definition in the Annex F.

Closed no change

The concept of PpUnit is part of HLAM which provides a set of high level concepts for dealing with real-time, parallel and concurrent modeling concerns without “implementation” flavors. Adding such properties as previously denoted in the issue summary would introduce such dependency with “implementation” concern.

Updated Table of Contents to reflect topics according to updated formatting

Regenerate ToC

Need to regenerate the ToC using Framemaker. It will be done when the issue resolutions will be integrated in the specification and the 1.2 version will be produced.

In GRM, a Resource may be active. MARTE needs to specify the relationship(coherency) between an active resource and and active class.

Accept changes

Before stating the resolution taken, let us have here a summary of the discussion held:
>>Sebastien Gerard:
This issue is about the relationship between UML active class and the concept of active resource as defined in GRM.
An active class is defined in UML (clause 13.3.8) as:
“An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as “the object having its own thread of control.”) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated.”

In GRM, the concept of Resource owns an attribute named isActive which definition is following:
“If true it indicates that the resource has an initial behavior associated that allows it to possibly perform its services autonomously or by the triggering and animation of behaviors on others.”

Semantics seems to be equivalent, but the stereotype Resource extend Classifier and not only class, meaning that any kind of classifier can be active.
Question: are we sure that it make sense for <<resource>> to extend Classifier and not only Class?
What are the other know use cases of using this stereotype on other classifiers than Class?
>>Bran Selic:
Good point. The notion of "isActive" was intentionally restricted to objects (as the definiton states). It seems inappropriate and inconsistent with UML semantics for MARTE to extend that to classifiers in general. Note that, in principle at least, profiles should exist solely within the confines of UML semantics (stretchable as they may be).
>>Julio Medina:
Regarding the consideration of active resources beyond "classes" I recall the fact that very frequently we use the SchedulableResources (threads, processes and so on) as targets of steps not only through allocation relationships or direct association, but also by using directly scenarios (activity diagrams or sequence charts). And a very graphical mean to express this allocation is by using swimlanes (partitions), activities, or lifelines instead of classes. [Schedulable resources are a kind of resources with isActive always true].
This happens because the means schedulability analysis has to cope with complexity is by demanding the designer for depicting worst case scenarios, instead of only behaviors. I understand that we can force the modeler to always define new (utilitarian) objects or classes for this purpose in what we call the platform model (which is good from a methodological point of view), but there is a significant expressiveness in defining this relationships by directly locating the steps in these scenario based diagrams. Also, this easies the expression of dynamic creation/destruction of threads.
I do not see why this extension would conflict with the limited view of active class that was originally in UML. I actually think that profiles are precisely to extend the semantics available through UML though keeping its original design intents working. Of course, as I mentioned, from a methodological point of view this restriction is not that bad and in practical terms (just by chance) the tools we have already made are currently not relying on these capabilities of MARTE, but I think this is an unnecessary limitation, and there might be many other practitioners that use them.

>>Murray Woodside
We use SchedulableResource this way all the time in performance analysis too. However putting isActive on the objects (the instances) works well... conceivably the same class could be passive in some instances and active in others (though I have never seen this).

>>Bran Selic:
Julio, If I understood you correctly, you want to be able to imply the notion of active objects without being forced to actually model the object itself. This is because for some purposes, such as schedulability analysis, it was not necessary to have the explicit object in the model – it saved time and effort. We used this method a lot in the original SPT profile. I think it is useful, but, unless it is properly documented, people will simply not know about it and will not take advantage of the capability – we learned this from the SPT experience.
My suggestion then is to keep things as they are, but that you provide at least an example in the spec for how to use this capability. Without that, the issue may be brought up again.

>>Sébastien Gerard:
I agree with the proposal of Bran. Julio, can you provide this example?

Summary:
So the way of making its use consistent with UML will be let to the user with the assistance of an additional example that is here provided.
The resolution is then to add an example of how to model platform active elements like schedulableResources without defining them as objects or classes, but doing it directly as elements of behavioral models. This example is inserted at the end of the SAM Chapter.

In the DataTxRateUnitKind dimension, the "Mb/s" baseUnit should be "Kb/s" (and convFactor = 1024) or the convFactor should be 1048576 (and baseUnit = "b/s").

Accept proposal

The issue refers to figures 8.6 (p.48) and D.3 (p.488). In these two figures, the “baseUnit” associated with “Mb/s” is “b/s”, while it should be “Kb/s”. The proposed resolution replaces “b/s” by “Kb/s” in the two figures.

The DurationUnitKind described in the D.2.10 NFP-Duration section, doesn't exist any more.

"unit" should be a TimeUnitKind as described in the figure 8.6, page 48.

Accept changes

Indeed, DurationUnitKind does not exist anymore. The proposition described in the summary is followed.

Having the opaque expresion 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, like IMA platforms. 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 easyer 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.

Duplicate

This is a duplicate of issue MARTE11 108 that has been resolved in MARTE 1.1

According to its definition, the impliesConstraint association of both Allocate and Assign stereotypes should be a composition and not a simple reference

Accept changes

Make the changes in the allocation profile of MARTE according to the proposition done in the issue summary.

problem:
Informal matching between a safety element and an architectural element.

analysis:
(1) We could introduce a new stereotype from a scratch (e.g. by extending <<trace>>) for the specific need. Its main advantage is to be optimally studied to the problem at hand. The price to pay is a new stereotype (with similar semantics to the standard ones) ­ thus potentially increasing the cost for interfacing models.

(2) We could reuse <<assign>> stereotype. The main drawback is a semantic overlapping with the original MARTE stereotype. However, the main advantage is that we reduce the number of concepts that a (safety) designer should manage ­ thus potentially increasing in usability.
In this solution, stereotype <<assign>> must have: kind = hybrid and nature = spatialDistribution. In order to do it, we are forced to generalized stereotype <<assign>> with a new stereotype with fixed values for both ''kind'' and ''nature''

proposed solution (by Bran Selic):
(a) provide additional enumeration literals for these two attributes of <<assign>> or (b) make them optional by changing their multiplicity from [1] to [0..1]. Note that these are not mutually exclusive choices and it might make sense to realize them both. Making these attributes optional will certainly improve on the generality of <<assign>>, so that it can be used to model other types of "allocation" relationships

project:
IMOFIS project of the System@tic
Paris R´egion Cluster. It is sponsored by the ”Safe, reliable and adapted transportation”
program (PREDIT) of the “Agence Nationale pour la Recherche”.

Impact on the Industrial Context:
The development of critical systems involves the interplay of many different disciplines and, therefore, becomes particularly complex. In this context, the industrial and academic communities are paying increasing attention to safety issues.
The resolution of the open issue improves the integration of safety analyses in a model-based engineering approach, where MARTE is used to specify a subset of the architecture.

Closed no change

What is requested here is to specialize <<assign>> such that its two attributes, "kind" and "nature", always have the same value. They would like to do this without defining a new stereotype. Of course, this is possible and does not require any change to MARTE, but it does require the addition of a constraint on <<assign>>, which, in turn, requires a new profile (albeit a trivial one, containing just that one constraint). Alternatively, they could include this constraint in their application model – although that would have to be done in every individual model.

VSL, Section B.3.3.9. The following attributes are missing (see figure B.7):

baseType : VSL::DataTypes::DataType [1] Designates an ordered DataType.

..

isMinOpen: Boolean [0..1] Defines if minValue is excluded in the bounded value space.

isMaxOpen: Boolean [0..1] Defines if maxValue is excluded in the bounded value space.

Closed no change

Section B.3.3.9 refers to the VSL grammar rule for the production of interval specifications. There is no clause in this section where it is needed/possible to include such property description.
Note also that, according to figure B.7, these properties belong to BoundedSubtype, and that they are appropriately described in section B.3.2.1.

in the following sentence:
------------
If kind is required it is expected to be a required operation or signal reception while if kind is provided, it is expected to be a provided operation or signal reception.
------------

it would be more explicit to precise that signal receptions are respectively also "required" and "provided", e.g.:
---------------
If kind is required it is expected to be a required operation or a required signal reception while if kind is provided, it is expected to be a provided operation or a provided signal reception.
---------------

Update the paragraph in question according to the proposal of the issue summary.

N/A

in the sentence:
-------------
Hence, the idea to associate time structure with events, behaviors, and objects, or more
generally instances of the concrete subtypes of the BehavioredClassifier metaclass.
-------------

it seems that a verb is missed... perhaps this could be reformulated as:
---------------
Hence, the idea is to associate time structure with events, behaviors, and objects, or more
generally instances of the concrete subtypes of the BehavioredClassifier metaclass.

Update the paragraph in question according to the proposal of the issue summury.

N/A

The current specification is ambiguous and should be refined.

The issue is the way the elements of the tiles are connected from one end to the other. This connection should be point-to-point.

Some text has to be added to the “Semantics” section of the Reshape concept page 534.

Adding new text

What does this "Notation" means? Either remove it or precise it.

Editorial

This is an edition error. Constraint 6 should be a section titled Notation and constraint 7 should be the contents of this section.

"ConcurrentAccessProtocolKind" contains several enumeration literals, one of them is "Other." With this representation, it is possible to represent ONE implicit user define protocol acces but impossible to make the distinction between various protocols defined by the end user like for exemple (ex: .Interrupt_Masking, Maximum_Priority).

This kind of specific concept can be defined within a dedicated profile extended MARTE

This kind of specific concept can be defined within a dedicated profile extended MARTE. You then have to specialize the stereotype owning the property typed as ConccurentAccessProtocolKind, define a new enumeration defining your own concurrent access protocol and then refine the property of interest for you within the new stereotype. As for example, you can define a new stereotype called «MySwMutualExclusionResource» specializing the MARTE stereotype «SwMutualExclusionResource» and then redefine the property mechanism by changing its type with the one new enumeration that will contain the literals that fit your needs.

ApplicationAllocationEnd and ExecutionPlatformAllocationEnd differentiate the client and the supplier of the allocation. In case where a model element is both the source of an allocation and the target of another allocation it would be practical to be able to use the stereotype <<allocated>> alone instead of applying the two stereotypes <<app_allocated,ep_allocated>>.

The property kind of the stereotype «Allocated» specifies the nature of the allocated element

The property kind of the stereotype «Allocated» specifies the nature of the allocated element. The type of the property is the AllocationEndKind enumeration that contains the literal both that enables to specify that an allocated element plays both role in allocation specification, application and platform role.

problem:

In section 9.2.4.2 (concrete time base relations) of the time model chapter, there is the following sentence: "Clock constraint specifications are special value specifications described in Annex C (Clock Constraint Specification Language)". However, the reference should be to annex C.3 and the named of annex C.3 is "Clock Constraint Specification".

proposed resolution:

change annex C to annex C.3 in the text of chapter 9.2.4.2.
rename the annex C.3 as "Clock Constraint Specification Language"

Accept changes

change annex C to annex C.3 in the text of chapter 9.2.4.2.
rename the annex C.3 as "Clock Constraint Specification Language"

problem:

In section 9.2.2.2 (concrete time base relations) of the time model chapter, there is the following sentence: "Predefined time base relations are suggested in the TimeStructureRelation Library of MARTE. The semantics of these relations is given in OCL.". However, the TimeStructureRelation Library does not exist in the specification.

proposed resolution:

There exists a description of predefined time base relations in the annex C. We propose to modify the text as well as the example depicted figure 9.7 to conform with the existing predefined time base relations.

Modify text

There exists a description of predefined time base relations in the annex C. We propose to modify the text as well as the example depicted figure 9.7 to conform with the existing predefined time base relations.

problem:
In section Overview of the time model chapter, there are three bullets to describe the time. In these bullet titles, the slash ('/') character has different meaning:

• Causal/temporal --> it should be understood as causal vs temporal
• Clocked/synchronous --> it should be understood as Clocked or synchronous
• Physical/real-time --> it should be understood as Physical or real-time

proposed resolution:

the bullet should be renamed with:

• Causal (untimed):
• Synchronous (partially timed):
• Physical (real-time):

additionally, to keep consistency, the last sentence of the last bullet should be rephrased, for instance with :
"Physical time models refine the partially timed models by adding reference(s) to one or more physical dimensions, for instance to derive the admissible speed of a reaction."

Update the paragraph in question according to the proposed resolution.

the bullet should be renamed with:

• Causal (untimed):
• Synchronous (partially timed):
• Physical (real-time):
  additionally, to keep consistency, the last sentence of the last bullet should be rephrased, for instance with : "Physical time models refine the partially timed models by adding reference(s) to one or more physical dimensions, for instance to derive the admissible speed of a reaction."

In the time chapter, I was reading the following sentence in clause 9.3.1.1: “When the property "on" is not specified, it should be understood as being by default, a dense chronometric clock with no flaws that represent the physical time.”

However, the lower bound of the multiplicity of the on role from TimedElement to Clock is one, meaning that one value at least has to be specified. May the aforementioned sentence should be repharsed, isn’t?

Update the paragraph in question according to the proposed resolution

The goal here was to ease the creation of the model while always keeping an explicit clock serialized in the model when the designer does not specify it explicitly. We have to specify in the text that a link to the idealClk clock must be set by the modeling tool when the designer does not explicit it (i.e. as a default clock).

problem:

In section 9.3.3 (Examples) from the time model, the examples describe some complex and pathological cases, which reflect the good expressiveness of the time model. These examples should perhaps be simplified to help the reader understanding classical/intended use of the time model in its design.

simplify

simplify the example on chronometric to show a classical use of it.

problem:

Section 9.2.4.5.2 is named "The timeEvent Package". It should be named "The TimedEvent Package"

proposed resolution:

rename section 9.2.4.5.2 as "The TimedEvent Package"

Accept proposal

rename section 9.2.4.5.2 as "The TimedEvent Package"

Diagram shown in 15.7 contains a set of inconsistencies:

• Multiplicity of GaWorkloadEvent::cause is 1 and not [0..1]
• Change GaWorkloadEvent::timeEvent: timeEvent into “GaWorkloadEvent::timeEvent: TimeEvent”
• Multiplicity of the GaScenario::cause property is [1..*]. This multiplicity shall be shown on the diagram.
• Type of GaScenario::timing should be GaTimedObs instead of GaTimingOberver that does not exist anymore.
• The association between GaWorkloadEvent and TimeEvent should be removed.

p. 300, in the attributes section of the “15.3.2.2 GaAnalysisContext”, ref to B.3.3.12 should be B.3.3.13.

p. 309, as denoted in the diagram shown in Figure 15.7, “effect:GaScenario [1]” should be listed in the attributes section and not in the list of associations.

Apply proposed changes

Apply proposed changes

There are numerous examples in the MARTE spec that show the use of tuple value expressions of the form (v, u), where v is the value and u is the unit (e.g., (50, ms)) to specify the value of a subtype of NFP_Real (e.g., NFP_Duration, NFP_Weight, etc.). However, based on how tuple expressions work, this is not valid, since, without additional information, the parser cannot know which attributes are being assigned these two values. Note that subtypes of NFP_Real can have many attributes (e.g., NFP_Duration has 11 attributes) and most of them have at least two Real-type attributes. Based on that, in an expression such as (50, ms), it is not possible to determine which attribute is being assigned the value 50 (e.g., in case of NFP_Duration, it could be either the "value" attribute, the "precision" attribute, the "worst" attribute, or the "best" attribute).

VSL does allow label-less expressions of this type, but, that can only work if the list of values follows the order in which the attributes appear (which, actually, is not quite clear from the spec), and if the use of the default or null literals is used for entries that are not assigned. For example, for an NFP duration of 50 milliseconds, the proper lable-less expression looks like it should be: (null, null, null,null, null, 50, ms, null, null, null, null), or, alternatively (-, -, -, -, -, 50, ms, -, -, -, -). Clearly, this is far too cumbersome for practical application.

One possible solution is to have VSL recognize the special and most common by far case of subtypes of NFP_Real, allowing a short form in cases where only the value and unit need to be specified (leaving the other attribute values to default). This short form would, naturally, be the (v, u) form. That would make the common form currently used in the spec valid.

Resolved

The resolution follows the proposal described in the last paragraph of the issue summary. An additional item is added in subclause B.3.3.11 Tuples/Disambiguating rules, to mention this short form in the case where expected types are NFP Types. An additional item is also added to make more explicit the rules for positional tuples (which is mentioned in the issue description as well).

UML introduce deployment concepts. MARTE introduces a notion of allocation that seem to encompass deployment-related notions (as stated in the specification). How these concepts relate to analysis attributes is left undefined in the specification at the moment. Depending on the examples one can have a look at, MARTE allocations and UML deployments seem to be used in a similar way (see Section 16.3.3 and Section 17.4). However, nothing is formally stated. Clarify whether MARTE allocations / UML deployment have the same semantics w.r.t. analysis, or not. And, if possible, make the connection with the related issue on host stereotype properties.

Closed no change

There is already a short discussion on the relationship between MARTE allocation and UML deployment in the specification. The issuer wanted to go more by extending the Deployment metaclass. This seems to restrict a bit the usage of the allocation stereotype and poses compatibility problems with SysML.
This issue needs more discussion to be addressed properly and may involve changes in the specification that are going outside the scope of a revision task force. It may be included in a future major revision of the standard.

In the GRM domain model (Figure 10.11) and GRM profile (Figure 10.16), there should be a constraint that enforce consistency between scheduling parameters and the related scheduler (e.g. a task brokered by an HPF scheduler cannot have anything else than a priority - integer - as a scheduling parameter).

Resolved

Discussion:
The nature of a scheduler is described by mean of its corresponding Scheduling Policy. It is this policy the one that has to be compatible with the scheduling parameters of the schedulable resources linked to the respective scheduler.

This requires a brief comment in the description of the scheduling package and specific constraints in the description of the schedulable resource element in the explanation of the semantic of the domain model in appendix F and the description of the SchedulableResource stereotype.

The same need for compatibility exist between the Scheduling Policy of a scheduler and the ProtectProtocolKind of the MutualExclussionProtocol of the MutualExclusionResources associated to the scheduler. Also between that ProtectProtocolKind and the corresponding ProtectionParameters of the MutualExclusionResources

Summary:
So the need for these details in the consistency of models will be pointed out in the description of the scheduling package and specific constraints will be inserted in the description of the schedulable resource element; both, in the explanation of the semantic of the domain model in appendix F and in the description of the SchedulableResource stereotype.
Also the definition of MutualExclusionResources indicates this constraints but a precise consistency table needs to be provided.

The property mode of the stereotype NfpCinstaint has a multiplicity [0..*]. To reflect that I propose to rename this latter mode to modes.

Closed No Change

Although there are no rules for naming association ends, it seems that UML uses singular names for all association ends (independently of the role multiplicity). So, we should try to keep the same naming convention in MARTE.

Title: Cannot precisely allocate an application to an execution platform described as a series of composite structures. Description : Consider an execution platform : a rack composed of 3 boards, each boards has a general-purpose processor and an accelerator. The rack and the board are structured classes defined with composite structure diagrams. The pseudo-code below provides an informal description of the platform: Rack

Board

GPP

How to precisely address the accelerator on the second board of the rack and allocate application elements on it ? The current allocation mechanism allows one to allocate an application on gpp property of the Board class but does not express that the second board is specifically designated.

Closed No Change

In order to achieve this purpose, let’s create istancespecification of the Rack and the boards. Let’s call them respectively rack1, board1, board2 and board3 and define rack1.board[0] = board1, rack1.board[1] = board2 and rack1.board[2] = board3. You can also define more precisely the Board instance specifications creating instance specifications of the gpp and accelerator. Then you can address the precisely each created instance specification in the allocation description.

It would be interested to introduce in the section 6.4 a chapter to explain the diferent design patterns adopted within the specification to use the UML extenssion mechanisms.

Out of Scope

Patterns used within MARTE to design its UML extensions is not specific to its domain but are indeed generic design pattern related to UML profiling and should be define in one other document than MARTE itself. The resolution of this issue is then considered as being out of the scope of the MARTE specification itself.

Runtimes may have multiple stacks. How to reference a specific stack size (e.g., primary or secondary) in SRM? It seems to miss a concept.

This is already possible

This is already possible to describe multiple stacks because the multiplicty of the staskSizeElement attribute is unlimited (concurrentResource stereotype). It seems that there is a need to describe more precisely several stacks: primiary stack, secondary stack ... One solution leads to describe an explicit "Stack" stereotype. Such solution deeply modifies the SRM chapter.
This kind of modification is out of the scope of revision task force and should be part of extension of MARTE and included in a request for proposal for a major new version of the specification.

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

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

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

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

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

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