HarmRealization should be in General instead of STPA
need Generalization to Causality... and need to and from from Causality
UndesiredControlActionHarmPotential diagram wrong.... it needs to have a Generalization of UndesiredStateHarmPotential
and redefine harmPotential and undesiredState (by undesiredControlAction) instead of from and to
harmPotential in AbstractFMEAItem... does not need subset scenarioStep
Assumption is in the profile but not in Fig. 10.3
Hazard is different in the Profile than the fig. 10.3
AbstractCause figure should show generalization of Factor
I am not sure why the attributes all over the standard were made private... e.g. Verified has an attirbute result which is private... so one could not read it out of the Verified
AnyVehicleUse should be AnyVehicleUsage to be consistent
Severity should be severity
standard model practice is to use 'Kind' after a word to indicate an Enumeration.. like ASILKind
Standard modeling practice is to have all usages singular and let multiplicities define if you have more than one... so a usage conditions (plural) would be changed to condition
Exposure says a Rationale must be attached... Rationale is SysML... and this is not necessarily SysML... so perhaps an attribute should be created instead to hold the Rationale
to keep the convention... exposure should be lowercase as a usage
HarmRealization should be a Specialization of AbstractRisk and Causality ... there are two redefines so harm and harmPotential is ok... but the other redefine should be to and from .... from Causality,,, look at Fig. 10.3 ... there are many conflicts... also could show Specialiation of AbstractRisk and Causality on Fig. 10.3
Association called UndesiredStateHarmPotential not described anywhere except on Fig. 10.3
the Opposite from scenarioStep between AnySituation and Scenario should be 0..*
HarmRealization is shown in General Concepts in Fig. 10.3 but is described in the standard in STPA on page 86
and is not described in the General Concepts section...
the Opposite from scenarioStep between AnySituation and Scenario should be 0..*
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).
*Fix Editorial Errors *
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-11 – change ProcessModelFlaw to ControlFlaw.
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 XMI validator issues
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
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.
This is a duplicate of RAAML 12-11
This is an exact duplicate of 12-11 which has been resolved and pushed to voting.
Revise the STPA example documentation to include usages for STPA-sec and to reflect errors corrected in the latest specification.
*Add revised STPA example *
Add revised STPA example to the Risk Analysis and Assessment Modeling Language (RAAML) Examples (Informative) file.
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
*Partial resolution to make Vulnerability abstract for 1.2 *
Per the RAAML RTF 1.2 working meeting it was decided to partially resolve this issue by updating the Vulnerability to be abstract for 1.2 and defer the addition of the Vulnerability stereotype to 1.3. A new issue will be created for the Vulnerability stereotype addition.
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.
*Partial resolution to make Weakness abstract for 1.2 *
Per the RAAML RTF 1.2 working meeting it was decided to partially resolve this issue by updating the Weakness to be abstract for 1.2 and defer the addition of the Weakness stereotype to 1.3. A new issue will be created for the Weakness stereotype addition.
Add an example for how the elements relevant to security can be modeled by the end user for a security analysis.
Added Security Example
Add the attached example to demonstrate the application of SysML4Sec using RAAML.
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.
Update name to ControlFlaw and make abstract
Change name of ProcessModelFlaw to ControlFlaw and any relations and supporting documentation. Update the element to be marked as abstract.
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.
Modify Examples document to include Functional Hazard Assessment (FHA) method
Add FHA subsection to examples document. See the attached .docx files for content of these new sections.
The Functional Hazard Assessment (FHA), as described in the ARP 4761A, is a systematic, comprehensive evaluation of the functional decomposition of a system or platform, performed at early stages of the V development process. This assessment identifies and classifies the failure conditions associated with each function. The goal in conducting an FHA is to clearly identify each failure condition along with the rationale for its severity classification. The classification of these failure conditions establishes the safety objectives to be met.
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.
Define and propose modifications to RAAML 1.2 to include Functional Hazard Assessment (FHA) method.
Minor changes in front matter (chapters 1 through 6), add a new section on FHA in chapter 9 (profile and library), add a new section on FHA in chapter 10 (Views), and addition of subsection to examples document. See the attached .docx files for content of these new sections.
The Functional Hazard Assessment (FHA), as described in the ARP 4761A, is a systematic, comprehensive evaluation of the functional decomposition of a system or platform, performed at early stages of the V development process. This assessment identifies and classifies the failure conditions associated with each function. The goal in conducting an FHA is to clearly identify each failure condition along with the rationale for its severity classification. The classification of these failure conditions establishes the safety objectives to be met.
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.
Fix typo to address this issue
In the examples document, there are multiple typos of ARP4761. This proposal addresses these issues.
Revise the associated RAAML .xmi files to represent the changes made in the specification to add the new FHA method
Revise .xmi files to include FHA method
Add FHA.xmi, Add FHALib.xmi, Revise GeneralRAAML.xmi, Revise GeneralRAAMLLib.xmi, Revise ISO26262Lib.xmi, Revise STPALib.xmi to include changes for FHA method
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.
