MARTE13 — Annotation of Criticalities of NFP values

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.