UML Profile for MARTE Avatar
  1. OMG Specification

UML Profile for MARTE — Closed Issues

  • Acronym: MARTE
  • Issues Count: 53
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
MARTE12_-86 MARTE issue: Observation does not allow specification of time value MARTE 1.0 MARTE 1.2 Deferred closed
MARTE12_-69 Precise the shape of an array of ports of an array of parts MARTE 1.0 MARTE 1.2 Deferred closed
MARTE12_-79 The notion of "access connection" needs to be explicited in the AADL annex (A.2) of MARTE MARTE 1.0 MARTE 1.2 Deferred closed
MARTE12_-60 Annotation of Criticalities of NFP constraints MARTE 1.1 MARTE 1.2 Deferred closed
MARTE12_-58 Annotation of Criticalities of NFP values MARTE 1.1 MARTE 1.2 Deferred closed
MARTE12_-23 Missing mappings between analysis duration, arrival patterns and clock constraints MARTE 1.0 MARTE 1.2 Deferred closed
MARTE12_-22 Align the NFP profile and domain model with the QUVD meta-model MARTE 1.0 MARTE 1.2 Deferred closed
MARTE12_-52 Missing mappings between analysis duration, arrival patterns and clock constraints MARTE 1.0b2 MARTE 1.2 Deferred closed
MARTE12_-53 [Time: Examples] MARTE 1.0b1 MARTE 1.2 Deferred closed
MARTE12_-18 SwResource should be a direct specialization of Resource, like its hardware counterpart MARTE 1.0 MARTE 1.2 Deferred closed
MARTE12_-1 About Gacenario:: MARTE 1.0 MARTE 1.2 Deferred closed
MARTE12_-4 «GaWorkloadGenerator» and its pop attribute MARTE 1.0 MARTE 1.2 Deferred closed
MARTE12_-6 Questions on observators within GQAM and SAM MARTE 1.0 MARTE 1.2 Deferred closed
MARTE12_-9 Refinement issue from GQAM to SAM MARTE 1.1 MARTE 1.2 Deferred closed
MARTE12_-35 TIME model: clarification of ClockConstraint properties MARTE 1.1 MARTE 1.2 Resolved closed
MARTE12_-31 Allocations kind and nature MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-84 Flow properties cannot be characterized with an RtSpecification MARTE 1.1 MARTE 1.2 Resolved closed
MARTE12_-75 Page 269: Section 14.2.3.2, Stereotype Descriptions MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-7 Typo in diagram 14.25 for stereotype SwSchedulableResource MARTE 1.1 MARTE 1.2 Resolved closed
MARTE12_-62 Missing HwRouter stereotype to allow modeling of Networks-on-Chips MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-48 The IntervalType attributes are not the same ones in the profil diagram and profil elements description MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-93 Specification of real time properties at "part with port" level MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-63 Section: 14.2 HRM Add an attribute isInterleaved : NFP_Boolean to the MemoryOrganization tuple type MARTE 1.0b2 MARTE 1.2 Resolved closed
MARTE12_-107 Completion of Issue 12-63 MARTE 1.1 MARTE 1.2 Resolved closed
MARTE12_-82 Missing synchronization resource in UML mapping for PpUnit MARTE 1.1 MARTE 1.2 Closed; No Change closed
MARTE12_-76 Update Table of Contents MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-2 Coherency between active resource of MARTE and active class in UML MARTE 1.1 MARTE 1.2 Resolved closed
MARTE12_-54 VSL, Section B.3.3.9. The following attributes are missing (see figure B.7): MARTE 1.0 MARTE 1.2 Closed; No Change closed
MARTE12_-72 ClientServerFeature: possible ambiguity on provided/required status of signal reception MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-71 a verb is missed in last sentence of first § MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-64 The semantics of the Reshape should be precised MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-68 Constraint 6 on the tiler is just "Notation", this should be precised MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-46 The "Mb/s" baseUnit should be "Kb/s". MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-47 The DurationUnitKind doesn't exist any more MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-59 GRM:Support for Time table driven schedules MARTE 1.0 MARTE 1.2 Closed; No Change closed
MARTE12_-30 ImpliesConstraint of Allocate and Assign relationships MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-89 MARTE, sterotype <>, MARTE 1.0 MARTE 1.2 Closed; No Change closed
MARTE12_-80 ConcurrentAccessProtocolKind MARTE 1.0b1 MARTE 1.2 Closed; No Change closed
MARTE12_-91 use the stereotype <> alone MARTE 1.0b1 MARTE 1.2 Closed; No Change closed
MARTE12_-5 Typos issues in GQAM MARTE 1.1 MARTE 1.2 Resolved closed
MARTE12_-87 MARTE: VSL short form for NFP_Real subtypes MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-39 TIME model: examples should be more pedagogical MARTE 1.1 MARTE 1.2 Resolved closed
MARTE12_-38 TIME model: wrong section name MARTE 1.1 MARTE 1.2 Resolved closed
MARTE12_-34 TIME model: name of referred section and name of section differ MARTE 1.1 MARTE 1.2 Resolved closed
MARTE12_-36 TIME model: reference to TimeStructureRelation Library does not exists MARTE 1.1 MARTE 1.2 Resolved closed
MARTE12_-37 TIME model overview: consistency of bullet descriptions MARTE 1.1 MARTE 1.2 Resolved closed
MARTE12_-8 MARTE Clocks MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-20 Relationship between MARTE allocations, UML deployment and analysis profiles need to be clarified MARTE 1.0 MARTE 1.2 Closed; No Change closed
MARTE12_-21 Missing constraint between scheduler and scheduling parameters MARTE 1.0 MARTE 1.2 Resolved closed
MARTE12_-3 NfpConstraint stereotype: rename property mode to modes MARTE 1.0 MARTE 1.2 Closed; No Change closed
MARTE12_-17 Cannot precisely allocate an application to an execution platform described as a series of composite structures. MARTE 1.0b2 MARTE 1.2 Closed; No Change closed
MARTE12_-10 Introduce new chapter in section 6.4 MARTE 1.0b1 MARTE 1.2 Closed; Out Of Scope closed
MARTE12_-19 Runtimes may have multiple stacks MARTE 1.0b1 MARTE 1.2 Closed; No Change closed

Issues Descriptions

MARTE issue: Observation does not allow specification of time value

  • Legacy Issue Number: 18657
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    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.

  • Reported: MARTE 1.0 — Fri, 12 Apr 2013 04:00 GMT
  • Disposition: Deferred — MARTE 1.2
  • Disposition Summary:

    Deferred

    Resolution of this issue is deferred to MARTE 2.0

  • Updated: Tue, 8 Jan 2019 19:22 GMT

Precise the shape of an array of ports of an array of parts

  • Legacy Issue Number: 15659
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Marc-Florian Wendland)
  • Summary:

    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.

  • Reported: MARTE 1.0 — Tue, 28 Sep 2010 04:00 GMT
  • Disposition: Deferred — MARTE 1.2
  • Disposition Summary:

    Deferred

    Defer the handling of this issue to MARTE 2.0

  • Updated: Tue, 8 Jan 2019 19:22 GMT

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

  • Legacy Issue Number: 15275
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

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

  • Reported: MARTE 1.0 — Sat, 5 Jun 2010 04:00 GMT
  • Disposition: Deferred — MARTE 1.2
  • Disposition Summary:

    Deferred

    Defer the handling of this issue to MARTE 2.0

  • Updated: Tue, 8 Jan 2019 19:22 GMT

Annotation of Criticalities of NFP constraints

  • Status: closed  
  • Source: Universidad de Cantabria ( Julio Medina)
  • Summary:

    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.

  • Reported: MARTE 1.1 — Thu, 31 Mar 2016 13:28 GMT
  • Disposition: Deferred — MARTE 1.2
  • Disposition Summary:

    Deferred

    Defer the handling of this issue to MARTE 2.0

  • Updated: Tue, 8 Jan 2019 19:22 GMT

Annotation of Criticalities of NFP values

  • Status: closed  
  • Source: Universidad de Cantabria ( Julio Medina)
  • Summary:

    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.

  • Reported: MARTE 1.1 — Thu, 31 Mar 2016 12:47 GMT
  • Disposition: Deferred — MARTE 1.2
  • Disposition Summary:

    Deferred

    Defer the handling of this issue to MARTE 2.0

  • Updated: Tue, 8 Jan 2019 19:22 GMT

Missing mappings between analysis duration, arrival patterns and clock constraints

  • Legacy Issue Number: 14899
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

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

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Deferred — MARTE 1.2
  • Disposition Summary:

    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.

  • Updated: Tue, 8 Jan 2019 19:22 GMT

Align the NFP profile and domain model with the QUVD meta-model

  • Legacy Issue Number: 14893
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    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)

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Deferred — MARTE 1.2
  • Disposition Summary:

    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.

  • Updated: Tue, 8 Jan 2019 19:22 GMT

Missing mappings between analysis duration, arrival patterns and clock constraints

  • Legacy Issue Number: 13654
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    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.

  • Reported: MARTE 1.0b2 — Tue, 3 Mar 2009 05:00 GMT
  • Disposition: Deferred — MARTE 1.2
  • Disposition Summary:

    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.

  • Updated: Tue, 8 Jan 2019 19:22 GMT

[Time: Examples]

  • Legacy Issue Number: 11767
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    [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

  • Reported: MARTE 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Disposition: Deferred — MARTE 1.2
  • Disposition Summary:

    No consensus

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

  • Updated: Tue, 8 Jan 2019 19:22 GMT

SwResource should be a direct specialization of Resource, like its hardware counterpart

  • Legacy Issue Number: 14898
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    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.

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Deferred — MARTE 1.2
  • Disposition Summary:

    Deferred

    Defer the handling of this issue to MARTE 2.0

  • Updated: Tue, 8 Jan 2019 19:22 GMT

About Gacenario::

  • Key: MARTE12_-1
  • Legacy Issue Number: 18581
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    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?

  • Reported: MARTE 1.0 — Tue, 26 Mar 2013 04:00 GMT
  • Disposition: Deferred — MARTE 1.2
  • Disposition Summary:

    Deferred

    Defer the handling of this issue to MARTE 2.0

  • Updated: Tue, 8 Jan 2019 19:22 GMT

«GaWorkloadGenerator» and its pop attribute

  • Key: MARTE12_-4
  • Legacy Issue Number: 18576
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

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

  • Reported: MARTE 1.0 — Mon, 25 Mar 2013 04:00 GMT
  • Disposition: Deferred — MARTE 1.2
  • Disposition Summary:

    Deferred

    Defer the handling of this issue to MARTE 2.0

  • Updated: Tue, 8 Jan 2019 19:22 GMT

Questions on observators within GQAM and SAM

  • Key: MARTE12_-6
  • Legacy Issue Number: 18567
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    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?

  • Reported: MARTE 1.0 — Tue, 19 Mar 2013 04:00 GMT
  • Disposition: Deferred — MARTE 1.2
  • Disposition Summary:

    Deferred

    Defer the handling of this issue to MARTE 2.0

  • Updated: Tue, 8 Jan 2019 19:22 GMT

Refinement issue from GQAM to SAM

  • Key: MARTE12_-9
  • Legacy Issue Number: 18565
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    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.
  • Reported: MARTE 1.1 — Sat, 16 Mar 2013 04:00 GMT
  • Disposition: Deferred — MARTE 1.2
  • Disposition Summary:

    Deferred

    Defer the handling of this issue to MARTE 2.0

  • Updated: Tue, 8 Jan 2019 19:22 GMT

TIME model: clarification of ClockConstraint properties

  • Legacy Issue Number: 17343
  • Status: closed  
  • Source: UNS / I3S / INRIA ( Julien DeAntoni)
  • Summary:

    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.

  • Reported: MARTE 1.1 — Fri, 27 Apr 2012 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    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.

  • Updated: Wed, 19 Dec 2018 16:37 GMT
  • Attachments:

Allocations kind and nature

  • Legacy Issue Number: 16835
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    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.

  • Reported: MARTE 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    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.

  • Updated: Wed, 19 Dec 2018 16:37 GMT

Flow properties cannot be characterized with an RtSpecification

  • Legacy Issue Number: 16583
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Arnaud Cuccuru)
  • Summary:

    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.

  • Reported: MARTE 1.1 — Thu, 6 Oct 2011 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Change text

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

  • Updated: Wed, 19 Dec 2018 16:37 GMT
  • Attachments:

Page 269: Section 14.2.3.2, Stereotype Descriptions

  • Legacy Issue Number: 16248
  • Status: closed  
  • Source: International Business Machines ( Irv Badr)
  • Summary:

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

  • Reported: MARTE 1.0 — Tue, 17 May 2011 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Resolved

    {Summary of how the issue is to be 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.

  • Updated: Wed, 19 Dec 2018 16:37 GMT
  • Attachments:

Typo in diagram 14.25 for stereotype SwSchedulableResource

  • Key: MARTE12_-7
  • Legacy Issue Number: 16229
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

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

  • Reported: MARTE 1.1 — Thu, 12 May 2011 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Update figure

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

  • Updated: Wed, 19 Dec 2018 16:37 GMT
  • Attachments:

Missing HwRouter stereotype to allow modeling of Networks-on-Chips

  • Legacy Issue Number: 16158
  • Status: closed  
  • Source: INRIA ( Pierre Boulet)
  • Summary:

    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

  • Reported: MARTE 1.0 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

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

  • Updated: Wed, 19 Dec 2018 16:37 GMT
  • Attachments:

The IntervalType attributes are not the same ones in the profil diagram and profil elements description

  • Legacy Issue Number: 15433
  • Status: closed  
  • Source: Softeam ( Emilie Houziaux)
  • Summary:

    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.

  • Reported: MARTE 1.0 — Fri, 27 Aug 2010 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    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.
  • Updated: Wed, 19 Dec 2018 16:37 GMT

Specification of real time properties at "part with port" level

  • Legacy Issue Number: 15166
  • Status: closed  
  • Source: Intecs ( Stefano Puri)
  • 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.

  • Reported: MARTE 1.0 — Thu, 8 Apr 2010 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    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.

  • Updated: Wed, 19 Dec 2018 16:37 GMT
  • Attachments:

Section: 14.2 HRM Add an attribute isInterleaved : NFP_Boolean to the MemoryOrganization tuple type

  • Legacy Issue Number: 13668
  • Status: closed  
  • Source: INRIA ( Pierre Boulet)
  • Summary:

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

  • Reported: MARTE 1.0b2 — Tue, 10 Mar 2009 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Modification may be done easily without introducing any compatibility issue.

    N/A

  • Updated: Wed, 19 Dec 2018 16:37 GMT
  • Attachments:

Completion of Issue 12-63

  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    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.

  • Reported: MARTE 1.1 — Wed, 16 May 2018 11:40 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    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.

  • Updated: Wed, 19 Dec 2018 16:37 GMT
  • Attachments:

Missing synchronization resource in UML mapping for PpUnit

  • Legacy Issue Number: 18165
  • Status: closed  
  • Source: Universidad de Cantabria ( Alejandro Péz Ruiz)
  • Summary:

    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.

  • Reported: MARTE 1.1 — Wed, 10 Oct 2012 04:00 GMT
  • Disposition: Closed; No Change — MARTE 1.2
  • Disposition Summary:

    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: Wed, 19 Dec 2018 16:37 GMT

Update Table of Contents

  • Legacy Issue Number: 16247
  • Status: closed  
  • Source: International Business Machines ( Irv Badr)
  • Summary:

    Updated Table of Contents to reflect topics according to updated formatting

  • Reported: MARTE 1.0 — Tue, 17 May 2011 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    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.

  • Updated: Wed, 19 Dec 2018 16:37 GMT

Coherency between active resource of MARTE and active class in UML

  • Key: MARTE12_-2
  • Legacy Issue Number: 16224
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

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

  • Reported: MARTE 1.1 — Wed, 11 May 2011 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    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.

  • Updated: Wed, 19 Dec 2018 16:37 GMT
  • Attachments:

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

  • Legacy Issue Number: 16162
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    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.

  • Reported: MARTE 1.0 — Fri, 29 Apr 2011 04:00 GMT
  • Disposition: Closed; No Change — MARTE 1.2
  • Disposition Summary:

    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.

  • Updated: Wed, 19 Dec 2018 16:37 GMT

ClientServerFeature: possible ambiguity on provided/required status of signal reception

  • Legacy Issue Number: 16012
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Francois Terrier)
  • Summary:

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

  • Reported: MARTE 1.0 — Mon, 7 Feb 2011 05:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

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

    N/A

  • Updated: Wed, 19 Dec 2018 16:37 GMT

a verb is missed in last sentence of first §

  • Legacy Issue Number: 16010
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Francois Terrier)
  • Summary:

    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.

  • Reported: MARTE 1.0 — Mon, 7 Feb 2011 05:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

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

    N/A

  • Updated: Wed, 19 Dec 2018 16:37 GMT

The semantics of the Reshape should be precised

  • Legacy Issue Number: 15727
  • Status: closed  
  • Source: INRIA ( Pierre Boulet)
  • Summary:

    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.

  • Reported: MARTE 1.0 — Thu, 14 Oct 2010 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

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

    Adding new text

  • Updated: Wed, 19 Dec 2018 16:37 GMT

Constraint 6 on the tiler is just "Notation", this should be precised

  • Legacy Issue Number: 15660
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Marc-Florian Wendland)
  • Summary:

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

  • Reported: MARTE 1.0 — Tue, 28 Sep 2010 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Editorial

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

  • Updated: Wed, 19 Dec 2018 16:37 GMT

The "Mb/s" baseUnit should be "Kb/s".

  • Legacy Issue Number: 15434
  • Status: closed  
  • Source: Softeam ( Emilie Houziaux)
  • Summary:

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

  • Reported: MARTE 1.0 — Fri, 27 Aug 2010 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    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.

  • Updated: Wed, 19 Dec 2018 16:37 GMT
  • Attachments:

The DurationUnitKind doesn't exist any more

  • Legacy Issue Number: 15432
  • Status: closed  
  • Source: Softeam ( Emilie Houziaux)
  • Summary:

    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.

  • Reported: MARTE 1.0 — Fri, 27 Aug 2010 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Accept changes

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

  • Updated: Wed, 19 Dec 2018 16:37 GMT

GRM:Support for Time table driven schedules

  • Legacy Issue Number: 15310
  • Status: closed  
  • Source: Universidad de Cantabria ( Julio Medina)
  • Summary:

    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.

  • Reported: MARTE 1.0 — Sat, 26 Jun 2010 04:00 GMT
  • Disposition: Closed; No Change — MARTE 1.2
  • Disposition Summary:

    Duplicate

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

  • Updated: Wed, 19 Dec 2018 16:37 GMT

ImpliesConstraint of Allocate and Assign relationships

  • Legacy Issue Number: 15291
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

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

  • Reported: MARTE 1.0 — Wed, 16 Jun 2010 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Accept changes

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

  • Updated: Wed, 19 Dec 2018 16:37 GMT
  • Attachments:

MARTE, sterotype <>,

  • Legacy Issue Number: 15261
  • Status: closed  
  • Source: Sherpa Engineering ( Daniela Cancila)
  • 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.

  • Reported: MARTE 1.0 — Thu, 20 May 2010 04:00 GMT
  • Disposition: Closed; No Change — MARTE 1.2
  • Disposition Summary:

    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.

  • Updated: Wed, 19 Dec 2018 16:37 GMT

ConcurrentAccessProtocolKind

  • Legacy Issue Number: 12403
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

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

  • Reported: MARTE 1.0b1 — Tue, 22 Apr 2008 04:00 GMT
  • Disposition: Closed; No Change — MARTE 1.2
  • Disposition Summary:

    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.

  • Updated: Wed, 19 Dec 2018 16:37 GMT

use the stereotype <> alone

  • Legacy Issue Number: 11706
  • Status: closed  
  • Source: INRIA ( Frederic Mallet)
  • Summary:

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

  • Reported: MARTE 1.0b1 — Fri, 30 Nov 2007 05:00 GMT
  • Disposition: Closed; No Change — MARTE 1.2
  • Disposition Summary:

    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.

  • Updated: Wed, 19 Dec 2018 16:37 GMT

Typos issues in GQAM

  • Key: MARTE12_-5
  • Legacy Issue Number: 18547
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    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.

  • Reported: MARTE 1.1 — Wed, 13 Mar 2013 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Apply proposed changes

    Apply proposed changes

  • Updated: Wed, 19 Dec 2018 16:37 GMT

MARTE: VSL short form for NFP_Real subtypes

  • Legacy Issue Number: 18249
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    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.

  • Reported: MARTE 1.0 — Tue, 6 Nov 2012 05:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

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

  • Updated: Wed, 19 Dec 2018 16:37 GMT

TIME model: examples should be more pedagogical

  • Legacy Issue Number: 17344
  • Status: closed  
  • Source: UNS / I3S / INRIA ( Julien DeAntoni)
  • Summary:

    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.

  • Reported: MARTE 1.1 — Fri, 27 Apr 2012 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    simplify

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

  • Updated: Wed, 19 Dec 2018 16:37 GMT
  • Attachments:

TIME model: wrong section name

  • Legacy Issue Number: 17342
  • Status: closed  
  • Source: UNS / I3S / INRIA ( Julien DeAntoni)
  • Summary:

    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"

  • Reported: MARTE 1.1 — Fri, 27 Apr 2012 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Accept proposal

    rename section 9.2.4.5.2 as "The TimedEvent Package"

  • Updated: Wed, 19 Dec 2018 16:37 GMT

TIME model: name of referred section and name of section differ

  • Legacy Issue Number: 17341
  • Status: closed  
  • Source: UNS / I3S / INRIA ( Julien DeAntoni)
  • Summary:

    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"

  • Reported: MARTE 1.1 — Fri, 27 Apr 2012 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    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"

  • Updated: Wed, 19 Dec 2018 16:37 GMT

TIME model: reference to TimeStructureRelation Library does not exists

  • Legacy Issue Number: 17340
  • Status: closed  
  • Source: UNS / I3S / INRIA ( Julien DeAntoni)
  • Summary:

    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.

  • Reported: MARTE 1.1 — Fri, 27 Apr 2012 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    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.

  • Updated: Wed, 19 Dec 2018 16:37 GMT
  • Attachments:

TIME model overview: consistency of bullet descriptions

  • Legacy Issue Number: 17339
  • Status: closed  
  • Source: UNS / I3S / INRIA ( Julien DeAntoni)
  • Summary:

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

  • Reported: MARTE 1.1 — Fri, 27 Apr 2012 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    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."
  • Updated: Wed, 19 Dec 2018 16:37 GMT

MARTE Clocks

  • Key: MARTE12_-8
  • Legacy Issue Number: 16609
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    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?

  • Reported: MARTE 1.0 — Sat, 15 Oct 2011 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

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

  • Updated: Wed, 19 Dec 2018 16:37 GMT

Relationship between MARTE allocations, UML deployment and analysis profiles need to be clarified

  • Legacy Issue Number: 14915
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    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.

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Closed; No Change — MARTE 1.2
  • Disposition Summary:

    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.

  • Updated: Wed, 19 Dec 2018 16:37 GMT

Missing constraint between scheduler and scheduling parameters

  • Legacy Issue Number: 14610
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

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

  • Reported: MARTE 1.0 — Mon, 2 Nov 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    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.

  • Updated: Wed, 19 Dec 2018 16:37 GMT

NfpConstraint stereotype: rename property mode to modes

  • Key: MARTE12_-3
  • Legacy Issue Number: 14428
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

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

  • Reported: MARTE 1.0 — Mon, 21 Sep 2009 04:00 GMT
  • Disposition: Closed; No Change — MARTE 1.2
  • Disposition Summary:

    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.

  • Updated: Wed, 19 Dec 2018 16:37 GMT

Cannot precisely allocate an application to an execution platform described as a series of composite structures.

  • Legacy Issue Number: 13842
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    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: Board [3] }

    Board

    { gpp: GPP accelerator: FPGA }

    GPP

    {...} FPGA {...}

    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.

  • Reported: MARTE 1.0b2 — Mon, 30 Mar 2009 04:00 GMT
  • Disposition: Closed; No Change — MARTE 1.2
  • Disposition Summary:

    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.

  • Updated: Wed, 19 Dec 2018 16:37 GMT

Introduce new chapter in section 6.4

  • Legacy Issue Number: 12223
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    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.

  • Reported: MARTE 1.0b1 — Thu, 14 Feb 2008 05:00 GMT
  • Disposition: Closed; Out Of Scope — MARTE 1.2
  • Disposition Summary:

    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.

  • Updated: Wed, 19 Dec 2018 16:37 GMT

Runtimes may have multiple stacks

  • Legacy Issue Number: 11845
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    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.

  • Reported: MARTE 1.0b1 — Thu, 20 Dec 2007 05:00 GMT
  • Disposition: Closed; No Change — MARTE 1.2
  • Disposition Summary:

    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.

  • Updated: Wed, 19 Dec 2018 16:37 GMT