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.

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.

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.

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.

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

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

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

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.

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.

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

Completion of Issue 12-63

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

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

Closed no change

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

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

Accept changes

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

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

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

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

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

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

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

problem:

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

proposed resolution:

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

Accept changes

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

problem:

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

proposed resolution:

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

Modify text

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

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

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

proposed resolution:

the bullet should be renamed with:

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

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

Update the paragraph in question according to the proposed resolution.

the bullet should be renamed with:

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

problem:

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

simplify

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

problem:

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

proposed resolution:

rename section 9.2.4.5.2 as "The TimedEvent Package"

Accept proposal

rename section 9.2.4.5.2 as "The TimedEvent Package"

Diagram shown in 15.7 contains a set of inconsistencies:

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

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

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

Apply proposed changes

Apply proposed changes