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