Daniel’s XMI validator has found 3 issues (1 in each of 3 separate files) where the outdated/old references to UML standard were used.

Fix in FTALib.xmi, STPA.xmi, and FHALib.xmi

Fix editorial errors identified from Architecture Board Review conducted by Harlen Dean.

• Front page has: http://www.omg.org/spec/RAAML/, I believe now everything should be https and not http. The above link does get redirected to https, so not a major issue.

• From the official page one and all subsequent pages (page 13 of PDF) the footer is incorrect. It still says: Risk Analysis and Assessment Modeling Langauge (RAAML), v1.0 should be ‘v1.2 Beta’. Also, ‘Language’ is spelled incorrectly.

• Multiple spelling errors were found:
Incorrect Correct
reliabiltiy reliability
avaliability availability
probablity probability
probablity desnity probability density
distribtuion distribution
distirbution distribution
propbability probability
compelement complement
paraemter / parameer parameter
shapre shape
equiavlent equivalent
resteoration restoration
locatrion location
ro to
norestorable non-restorable
ResteorabailitySystemReliabilitySituation  RestorableSystemReliabilitySituation
RestorableComponentReliabilitySituationSituation  RestorableComponentReliabilitySituation
Resetorable Restorable
oir or
RestorablSystemReliabilitySituation  RestorableSystemReliabilitySituation
Speciaalization Specialization

• In section HomogeneousKofNCalculation, below the figure, it says: k ou tof n system reliability or availability, should be k out of n system reliability or availability

• Section 7.3.1 and 7.3.2 has Highway Driving Straight as Speed mentioned 3 times, should ‘at speed’.

• RAAML12-2 – Assumption image in SVG zip file looks incorrect.
Zip file compared to Image in documents ptc-26-04-1

• RAAML12-11 – ProcessModelFlaw is still mentioned in section 10.6.1, page 184 (page 196 of pdf).

Revise the STPA example documentation to include usages for STPA-sec and to reflect errors corrected in the latest specification.

The issue is that Vulnerability is not currently stereotyped as Vulnerability, and is not marked as Abstract, which puts it out of alignment with the other RAAML library elements. To resolve this, the ticket calls for stereotyping it as Vulnerability and marking it as abstract. This change should help ensure consistency with Factors and Limitations in the STPA Loss Scenario

The issue is that Weakness is not currently stereotyped as Weakness, and is not marked as Abstract, which puts it out of alignment with the other RAAML library elements. To resolve this, the ticket calls for stereotyping it as Weakness and marking it as abstract. This change should help ensure consistency with Factors and Limitations in the STPA Loss Scenario.

ProcessModelFlaw is not marked as Abstract. It must be abstract consistent with the other RAAML library elements. In addition the name ProcessModelFlaw is causing confusion and should be called ControlFlaw to be consistent with the Undesired Control Action and Control Structure.

ProcessModelFlaw is not marked as Abstract. It must be abstract consistent with the other RAAML library elements. In addition the name ProcessModelFlaw is causing confusion and should be called ControlFlaw to be consistent with the Undesired Control Action and Control Structure.

Add an example for how the elements relevant to security can be modeled by the end user for a security analysis.

RAAML contains the ISO 26262 method to support the analysis and requirement specification aspects of Functional Safety. However, ISO 26262 focuses on the automotive industry. To also cover the aerospace sector, the Functional Hazard Assessment (FHA) method according to ARP 4761A should be brought as a method to RAAML and should be properly linked to Core, General, FMEA and ISO 26262 packages.

The examples document should reflect this change.

RAAML contains the ISO 26262 method to support the analysis and requirement specification aspects of Functional Safety. However, ISO 26262 focuses on the automotive industry. To also cover the aerospace sector, the Functional Hazard Assessment (FHA) method according to ARP 4761A should be brought as a method to RAAML and should be properly linked to Core, General, FMEA and ISO 26262 packages.

The Vulnerability element is stereotyped by a generic <<Situation>> stereotype and there is no dedicated <<Vulnerability>> stereotype. To resolve this add a stereotype for Vulnerability. This change should help ensure consistency with Factors and Limitations in the STPA Loss Scenario

The Weakness element is stereotyped by a generic <<Situation>> stereotype and there is no dedicated <<Weakness>> stereotype. To resolve this, the ticket calls for adding a stereotype for Weakness. This change should help ensure consistency with Factors and Limitations in the STPA Loss Scenario.

The issue is that ProcessModel and ControlAlgorithm are not currently stereotypes in the STPA profile, but is required to accurately model a STPA Control Structure.

The issue is that Threat is not currently considered as a Limitation-Factor, which is necessary in creating STPA Loss Scenarios. To resolve this, the ticket calls for making Threat a subtype of Limitation.

The issue is that Threat is not currently stereotyped as Threat, which puts it out of alignment with the other RAAML profile elements. To resolve this, the ticket calls for stereotyping it as Threat.

Revise the associated RAAML .xmi files to represent the changes made in the specification to add the new FHA method

I suspect that this is a typo. I don't think that ARP4751 exists BUT ARP4761 exists. Review and make sure we are referencing the correct standard.

Sometimes the transition from one situation to another situation needs additional properties which cannot be captured by a simple association. The common solution for that is to use an association class to express causality allowing for additional properties to be added to the transition. This pattern is already used in the STPA method. The proposal is to create a general pattern so other methods can access this capability. This would include creating an association class on the common core Situation.

In Enterprise Architect 15.2 the CoreRAAML.xmi is not loaded completely. The generalization relation from Situation to SysML Block is not loaded. It seems to me that the xmi export has tool-specific content.

RAAML claims to implement STPA, but some important elements are missing.

For example,

In Step-1 of the STPA process (in the 2018 Leveson/Thomas STPA Handbook – Figure 2.3) it calls out the need to derive “Safety Constraints” from the Losses. I can find no reference to Safety Constraints in the RAAML.

Furthermore the RAAML does not provide any linkage from Losses to Hazards, which is expected in the Handbook.