1. OMG Mailing List
  2. UML Profile for MARTE 1.3 Revision Task Force

Open Issues

  • Issues not resolved
  • Name: marte-rtf
  • Issues Count: 16

Issues Descriptions

Need a reference to a softwareSchedulable resource for Periodic, Aperiodic and sporadic pattern

  • Key: MARTE13-15
  • Status: open  
  • Source: THALES ( Laurent Rioux)
  • Summary:

    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

  • Reported: MARTE 1.1 — Thu, 12 Apr 2018 13:41 GMT
  • Updated: Tue, 8 Jan 2019 19:22 GMT

Missing a property to PeriodicServerParameters

  • Key: MARTE13-16
  • Status: open  
  • Source: THALES ( Laurent Rioux)
  • Summary:

    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.

  • Reported: MARTE 1.1 — Thu, 12 Apr 2018 13:04 GMT
  • Updated: Tue, 8 Jan 2019 19:22 GMT

MARTE issue: Observation does not allow specification of time value

  • Key: MARTE13-14
  • Legacy Issue Number: 18657
  • Status: open  
  • 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
  • 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

  • Key: MARTE13-13
  • Legacy Issue Number: 15275
  • Status: open  
  • 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
  • Updated: Tue, 8 Jan 2019 19:22 GMT

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

  • Key: MARTE13-12
  • Legacy Issue Number: 15659
  • Status: open  
  • 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
  • Updated: Tue, 8 Jan 2019 19:22 GMT

Annotation of Criticalities of NFP constraints

  • Key: MARTE13-11
  • Status: open  
  • 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
  • Updated: Tue, 8 Jan 2019 19:22 GMT

Annotation of Criticalities of NFP values

  • Key: MARTE13-10
  • Status: open  
  • 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
  • Updated: Tue, 8 Jan 2019 19:22 GMT

[Time: Examples]

  • Key: MARTE13-9
  • Legacy Issue Number: 11767
  • Status: open  
  • 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
  • Updated: Tue, 8 Jan 2019 19:22 GMT

Missing mappings between analysis duration, arrival patterns and clock constraints

  • Key: MARTE13-8
  • Legacy Issue Number: 13654
  • Status: open  
  • 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
  • Updated: Tue, 8 Jan 2019 19:22 GMT

Missing mappings between analysis duration, arrival patterns and clock constraints

  • Key: MARTE13-7
  • Legacy Issue Number: 14899
  • Status: open  
  • 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
  • Updated: Tue, 8 Jan 2019 19:22 GMT

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

  • Key: MARTE13-6
  • Legacy Issue Number: 14893
  • Status: open  
  • 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
  • Updated: Tue, 8 Jan 2019 19:22 GMT

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

  • Key: MARTE13-5
  • Legacy Issue Number: 14898
  • Status: open  
  • 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
  • Updated: Tue, 8 Jan 2019 19:22 GMT

Refinement issue from GQAM to SAM

  • Key: MARTE13-4
  • Legacy Issue Number: 18565
  • Status: open  
  • 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
  • Updated: Tue, 8 Jan 2019 19:22 GMT

Questions on observators within GQAM and SAM

  • Key: MARTE13-3
  • Legacy Issue Number: 18567
  • Status: open  
  • 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
  • Updated: Tue, 8 Jan 2019 19:22 GMT

«GaWorkloadGenerator» and its pop attribute

  • Key: MARTE13-2
  • Legacy Issue Number: 18576
  • Status: open  
  • 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
  • Updated: Tue, 8 Jan 2019 19:22 GMT

About Gacenario::

  • Key: MARTE13-1
  • Legacy Issue Number: 18581
  • Status: open  
  • 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
  • Updated: Tue, 8 Jan 2019 19:22 GMT