${taskforce.name} Avatar
  1. OMG Task Force

Risk Analysis and Assessment Modeling Language (RAAML) 1.1 RTF — All Issues

Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
RAAML11-28 Augment RAAML risk analysis with foundational security analysis concepts RAAML 1.0 RAAML 1.1 Resolved closed
RAAML11-1 Elements Should Have Unique Names to Improve Clarity and Implementation RAAML 1.0b1 RAAML 1.1 Closed; No Change closed
RAAML11-5 Lack of consideration of Cut Sets RAAML 1.0b1 RAAML 1.1 Closed; No Change closed
RAAML11-4 The treatment of GSN in RAAML RAAML 1.0b1 RAAML 1.1 Closed; No Change closed
RAAML11-6 Use Action Priority Number instead of Risk Priority Number for the FMEA analysis RAAML 1.0b1 RAAML 1.1 Deferred closed
RAAML11-7 Explanation of what previousRPNValues attribute means RAAML 1.0b1 RAAML 1.1 Closed; No Change closed
RAAML11-17 Include Reliability Block Diagrams in RAAML RAAML 1.0 RAAML 1.1 Resolved closed
RAAML11-14 Unclear whether a part of a composite can be reused in another composite RAAML 1.0 RAAML 1.1 Deferred closed
RAAML11-11 Is ControllingMeasure the same as ControllingAction? RAAML 1.0 RAAML 1.1 Resolved closed
RAAML11-8 ISO 26262 is Reference is Outdated RAAML 1.0 RAAML 1.1 Resolved closed
RAAML11-18 Add Method::ISO 14971 (Application of risk management to medical devices) RAAML 1.0b1 RAAML 1.1 Deferred closed
RAAML11-35 Supplementary data for RBDs RAAML 1.0 RAAML 1.1 Resolved closed
RAAML11-10 Situation is defined ambiguously, 'situation occurrence' is not defined RAAML 1.0 RAAML 1.1 Deferred closed
RAAML11-2 Support for Risk Matrices RAAML 1.0b1 RAAML 1.1 Deferred closed
RAAML11-3 Issue/task tracking RAAML 1.0b1 RAAML 1.1 Closed; Out Of Scope closed
RAAML11-29 Add a Causality association class which extends simple Causality association RAAML 1.0 open
RAAML11-16 Generalization relation from Situation to SysML Block is not loaded in EA RAAML 1.0b2 open
RAAML11-15 STPA is not properly implemented RAAML 1.0b2 open

Issues Descriptions

Augment RAAML risk analysis with foundational security analysis concepts

  • Key: RAAML11-28
  • Status: closed  
  • Source: Ford Motor Company ( Mr. Kyle Post)
  • Summary:

    There is a need to augment the RAAML existing concepts with a set of extensions and refinements to accommodate security related information as it impacts the measures that RAAML seeks to model (e.g., safety, reliability).
    There is coordination with the UAF team, by Mary Tolbert (UAF Lead on Security Viewpoints), to ensure there is not any overlap with security concepts. Mary has attended all RAAML technical meetings along with providing support for STPA support for security consistent with SAE J3187 extensions for security.
    In addition, Bob Martin (SAACM Chair), has been involved in the RAAML RTF meeting with the following comments on inclusion of security concepts.
    “The first was the June 2022 meeting in Orlando where we discussed the underlying security concepts - mainly of weaknesses and vulnerabilities - and how weaknesses at the design, architecture, code, or deployment levels can lead to undesired behaviors. These may be undesirable from many perspectives - from a reliability one, a safety one, or a security perspective. The same concept of weaknesses and vulnerabilities underlies the quality work that has come from the Architecture Driven Modernization Task Force and was recently republished by ISO/IEC as ISO/IEC 5055 but is also the underpinnings of the Systems Assurance Task Force's work in the Software Fault Pattern Meta-model.
    This vulnerability and weakness model was created by MITRE in our development of the Common Vulnerabilities and Exposures (CVE) effort which is now captured in ITU-T's X.1520 standard and our creations of the Common Weakness Enumeration (CWE) which is captured in ITU-T's X.1524. I have led MITRE's work in these efforts and their publishing as international standards but also in getting them consistently and compatibly into OMG's work described above and in RAAML.
    The second in-depth meeting I participated in was the one in Chicago where the result of formulating additions to RAAML for security analysis extensions to safety and reliability were presented and approved for adding to the specification resulting in Jira issue RAAML11-31 and the change that resolved it.”

  • Reported: RAAML 1.0 — Mon, 25 Sep 2023 20:03 GMT
  • Disposition: Resolved — RAAML 1.1
  • Disposition Summary:

    Augment RAAML risk analysis with foundational security analysis concepts

    Add foundational concepts to support security risk analysis methods by adding a security library and profile along with tieing them into the existing STPA method.

    Add "Weakness", "Vulnerability", and "Threat" to a general security concept library to support security risk analysis and assessment methods which builds upon the RAAML common core.

    Add "Limitation" to the general concept library to bridge between "Weakness" and "Vulnerability". Add "Threat", "PresentedBy", "Impacts", "Asset", "SecurityActor", and "Valuates" stereotypes to the general security profile.

    Revise STPA method to move common elements to the general library/profile for use by other security methods and update STPA to include STPA-Sec.

  • Updated: Mon, 17 Jun 2024 13:38 GMT
  • Attachments:

Elements Should Have Unique Names to Improve Clarity and Implementation

  • Key: RAAML11-1
  • Status: closed  
  • Source: Gaphor Project ( Dan Yeaw)
  • Summary:

    Many parts of RAAML are broken in to a Library and Profile. The Profile contains the Stereotypes, for example the definition of the <<AND>> stereotype for an AND gate. The Library contains a definition, for example that an AND Block with the <<AND>> stereotype is a type of Gate. In other words, RAAML often has two elements in the model in different namespaces but with the same name.

    In the Gaphor tool, we autocode the model in to a Python datamodel. So far while implementing UML and SysML, we didn't have to name each Python class with the full namespace because the element names were always unique. With RAAML this is no longer the case, there are often two elements with the same name.

    I think this can also cause confusion for users by duplicating names. For example, if someone is talking about the AND element, are they referring to the the stereotype or the block?

    SysML v2 is starting to use two similar names for the definition and the usage, but the definition includes "def" in the name. For example, the definition of a part is a "part def" and the usage is a "part". I would recommend we use something similar for RAAML. the definition of the AND gate could be "AND_Def", and the stereotype could be "AND".

    The duplicated names include:
    Gate, AND, BasicEvent, Cause, ConditionalEvent, DormantEvent, Early, FMEAItem, FailureMode, HouseEvent, INHIBIT, Late, MAJORITY_VOTE, NOT, OR, SEQ, TopEvent, UnsafeControlAction, XOR, ZeroEvent.

  • Reported: RAAML 1.0b1 — Sun, 28 Feb 2021 17:30 GMT
  • Disposition: Closed; No Change — RAAML 1.1
  • Disposition Summary:

    Generator implementation should ensure element name uniqueness in python

    Generator implementation should ensure element name uniqueness in python or any other language. Lumping two UML namespaces (Profile and Library) into a single python namespace causes element name uniqueness problems. This can be solved by adding prefixes or postfixes to generated python names or by separating generated content into separate packages/files.

  • Updated: Mon, 17 Jun 2024 13:38 GMT

Lack of consideration of Cut Sets

  • Key: RAAML11-5
  • Status: closed  
  • Source: Engineer for Safety Limited ( Phil Williams)
  • Summary:

    The section focusses on probability as an attribute from FTA elements.
    This is arguably the least important attribute from FTA, particularly in system modeling and given the simplistic treatment of probability in this section.
    A far more valuable attribute from FTA is the cut set, or minimal cut set at any gate within the FTA hierarchy.
    This is a major shortfall that I believes renders the use of these profiles within system modeling very limited, particularly in early system work before the base event probabilities can be known. Even in later lifecycle phases, the simplistic treatment of probabilities that ignores real world interdependence renders the results from such modeling misleading at best.

  • Reported: RAAML 1.0b1 — Fri, 30 Apr 2021 10:41 GMT
  • Disposition: Closed; No Change — RAAML 1.1
  • Disposition Summary:

    Cut set calculation is tool vendor responsibility

    The goal of the RAAML specification is to provide data structures that are sufficient to support FTA so that cut sets can be calculated. RAAML does not provide algorithms or implementations for cut set calculations. This is to be done by tool vendors implementing the RAAML specification.

  • Updated: Mon, 17 Jun 2024 13:38 GMT

The treatment of GSN in RAAML

  • Key: RAAML11-4
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The GSN Community standard and metamodel, as of version 2 of GSN, are based on extending OMG’s Structured Assurance Case Metamodel (SACM) version 2. In a sense, all GSN elements are sub-classes of elements defined in SACM so that tools supporting GSN can leverage the SACM metamodel for exchanging GSN content. The material in RAAML that discusses GSN and define RAAML GSN constructs does not reflect this approach and appears at odds to the GSN community standard and its use and leveraging of OMG’s SACM standard.

  • Reported: RAAML 1.0b1 — Thu, 29 Apr 2021 21:40 GMT
  • Disposition: Closed; No Change — RAAML 1.1
  • Disposition Summary:

    *RAAML provides a translation to SCSC GSN *

    RAAML provides a translation from GSN notation on top of custom metamodel of SACM to SCSC GSN notation on top of UML metamodel plus profile. The RAAML group believes that this translation faithfully represents the GSN core part of SACM. In the future if the SCSC GSN and/or SACM changes then it can be reflected in RAAML.

  • Updated: Mon, 17 Jun 2024 13:38 GMT

Use Action Priority Number instead of Risk Priority Number for the FMEA analysis

  • Key: RAAML11-6
  • Status: closed  
  • Source: Method Park ( Hendrik Dahmke)
  • Summary:

    The Automotive Industry Action Group and the "Verband der deutschen Automobilindustrie" published a FMEA handbook in 2019 where they discourage the use of the Risk Priority Number (RPN) and instead suggest the use of an Action Priority to determine order and importance of identified failure modes and their effects.

  • Reported: RAAML 1.0b1 — Tue, 28 Sep 2021 05:54 GMT
  • Disposition: Deferred — RAAML 1.1
  • Disposition Summary:

    Deferred to the next version of RAAML

    The support for AIAG & VDA FMEA is not within the scope of RAAML 1.1. However, we will consider incorporating it in the future if there is a significant amount of interest from the industry.

  • Updated: Mon, 17 Jun 2024 13:38 GMT

Explanation of what previousRPNValues attribute means

  • Key: RAAML11-7
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Armonas)
  • Summary:

    There should be an explanation of what the previousRPNValues attribute means.

  • Reported: RAAML 1.0b1 — Thu, 30 Sep 2021 13:06 GMT
  • Disposition: Closed; No Change — RAAML 1.1
  • Disposition Summary:

    previousRPNValues attribute documented in AbstractFMEAItem

    Current specification describes previousRPNValues attribute in AbstractFMEAItem. FMEAItem inherits from AbstractFMEAItem and redefines previousRPNValues attribute by specifying its type as Real by keeping the definition unchanged. This is why an additional definition is not necessary and would duplicate an already existing definition.

  • Updated: Mon, 17 Jun 2024 13:38 GMT
  • Attachments:

Include Reliability Block Diagrams in RAAML

  • Key: RAAML11-17
  • Status: closed  
  • Source: Aerospace Corporation ( Mr. Myron Hecht)
  • Summary:

    Define and propose modidfications to RAAML 1.1 to include reliability block diagrams

  • Reported: RAAML 1.0 — Sun, 4 Dec 2022 17:29 GMT
  • Disposition: Resolved — RAAML 1.1
  • Disposition Summary:

    Define and propose modidfications to RAAML 1.1 to include reliability block diagrams

    Minor changes in front matter (Chapters 1 through 7), add a new section on RBDs at the end of Chapter 9 (profile and library) and a new section on RBDs at the end of Chapter 10 (Views). See the attached .docx files for content of these new sections.
    A Reliability Block Diagram (RBD) is a graphical representation used in reliability engineering to analyze the reliability and availability of complex systems. It is a method for assessing the performance of systems composed of multiple components, sub-systems, or processes. In an RBD, system elements (components or groups of components defined as an assemblies, subsystems, or other system architectural elements) are depicted as blocks, and these blocks are connected by lines to represent how they are interconnected or dependent on each other. The goal is to evaluate the overall reliability and availability of the entire system by considering the reliability characteristics of each component and their interconnections

  • Updated: Mon, 17 Jun 2024 13:38 GMT
  • Attachments:

Unclear whether a part of a composite can be reused in another composite

  • Key: RAAML11-14
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    An instance of a part can be part of exactly one composite instance, but there could be many options for the composite. For example the same ScenarioStep could be part of many Scenarios. Of course, each instance of the ScenarioStep will occur only in one Scenario instance.

    In order to allow this, the multiplicity on the whole side of the composite relationship in figure 9.22 must be 0..1.

    In this figure this multiplicity is not shown. This leads to two possible interpretations. According to UML the default is 1, but according to SysML the default is 0..1. Now, the General Concepts Library is a SysML model, hence we could assume that it is 0..1.

    However, this default is just a notational thing: "SysML: These multiplicities may be assumed if not shown on a diagram.". In order to make it into the xmi-file the multiplicities must be set explicitely. And in the current xmi-file the multiplicity is not defined. When it is opened by Cameo, it sets the value explicitely to 1. You might consider this a bug in Cameo, but I guess this behavior is within the specification.

    So my question is: What was the intention? Should a scenario step only be part of one scenario? Then the multiplicity must be 1 and this should be made clear in the diagrams. Or can it be part of many scenarios? Then the multiplicity must be 0..1 and this should also be shown in the diagrams. And it should be defined in the xmi-file.

    The same question needs to be answered for all composite associations in the libraries, e.g. Risk to Effect, Event and HarmPotential. ScenarioStep is just one example for the issue.

  • Reported: RAAML 1.0 — Tue, 30 Aug 2022 13:03 GMT
  • Disposition: Deferred — RAAML 1.1
  • Disposition Summary:

    Composite relationships should have 0..1 multiplicity at the composite end

    Most of composite relationships should have 0..1 multiplicity at the composite ends. This is a larger effort for the working group with almost no impact to end users. Thus the working group will focus on it in the next release.

  • Updated: Mon, 17 Jun 2024 13:38 GMT

Is ControllingMeasure the same as ControllingAction?

  • Key: RAAML11-11
  • Status: closed  
  • Source: Coventry University ( Mr. Stephen Powley)
  • Summary:

    o Table 9.1 lists «ControllingAction» as “A stereotyped UML dependency” and states in the preceding text that “Situations can be mitigated, detected, and prevented via the ControllingAction. The use of this relationship introduces new safety requirements.” This term does not appear anywhere else.
    o The Core Profile does, however, describe «ControllingMeasure» as “A measure taken to address (mitigate severity, reduce probability of occurrence, increase probability of detection) a potential or real adverse situation.” which is similar, but not identical to «ControllingAction»

  • Reported: RAAML 1.0 — Tue, 21 Jun 2022 17:03 GMT
  • Disposition: Resolved — RAAML 1.1
  • Disposition Summary:

    *Update Controlling Action with Controlling Measure *

    Replace controlling action with controlling measure in domain model and corresponding text.

  • Updated: Mon, 17 Jun 2024 13:38 GMT

ISO 26262 is Reference is Outdated

  • Key: RAAML11-8
  • Status: closed  
  • Source: Gaphor Project ( Dan Yeaw)
  • Summary:

    The current version of ISO 26262 is version 2018, the RAAML specification is referencing version 2011.

  • Reported: RAAML 1.0 — Sat, 23 Apr 2022 19:13 GMT
  • Disposition: Resolved — RAAML 1.1
  • Disposition Summary:

    Update references to ISO 26262:2018

    The current version of ISO 26262 is ISO 26262:2018 and the version referenced in RAAML 1.0 is ISO 26262:2011. Need to revise reference to latest version and check for any additional changes with the new version.

  • Updated: Mon, 17 Jun 2024 13:38 GMT

Add Method::ISO 14971 (Application of risk management to medical devices)

  • Key: RAAML11-18
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    We suggest to add a new method for risk management for medical devices according to ISO 14971.

    In the context of the medicussy project we have created a profile and a library. These could be used as a starting point. The files can be found in a github-repository: https://github.com/oose/medicussy. There you also find further example models that illustrate the application of the method.

    We invite everybody to contribute to the github repository.

  • Reported: RAAML 1.0b1 — Mon, 12 Dec 2022 16:21 GMT
  • Disposition: Deferred — RAAML 1.1
  • Disposition Summary:

    Out of scope of RAAML 1.1

    ISO 14971 is out of scope of RAAML 1.1. We will consider supporting it in the future if there enough interest from the industry.

  • Updated: Mon, 17 Jun 2024 13:38 GMT

Supplementary data for RBDs

  • Key: RAAML11-35
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Armonas)
  • Summary:

    Additional files to enhance RBD method proposal are necessary (XMI files and examples).

  • Reported: RAAML 1.0 — Mon, 5 Feb 2024 17:25 GMT
  • Disposition: Resolved — RAAML 1.1
  • Disposition Summary:

    *Add XMI files and an example for RBDs *

    Add XMI files for RBDs (see RBD.zip).
    Add section 2.6 to illustrate RBD library and profile usage with an example (see RAAML 11 examples - omg jira.docx).

  • Updated: Mon, 17 Jun 2024 13:38 GMT
  • Attachments:

Situation is defined ambiguously, 'situation occurrence' is not defined

  • Key: RAAML11-10
  • Status: closed  
  • Source: Coventry University ( Mr. Stephen Powley)
  • Summary:

    Considering its significance, Situation is defined rather ambiguously in Table 5.1: “A situation describes a set of situation occurrences of some type. The system, place, time and state parameters are described by classifiers rather than individual descriptions. A situation occurrence is a system being in a given place at given time and in a given state.” Section 9.1 adds that “The system, place, time and state parameters are described by classifiers rather than individual descriptions.” This prompts a number of questions, which are unanswered by the specification:

    • Why is there no formal definition of ‘situation occurrence’ in the Core Profile? (it is only informally defined as part of the definition of ‘situation’) The lack of a formal definition seems to be something of an oversight, given their central importance, especially considering that the stated aim of RAAML to “avoid inconsistent model-based solutions [that] prohibit direct model sharing between organizations and across the various tools”.
    o My recommendation would be to add this to the Core Concepts e.g. “Figure 9.1 – Core concepts domain model”, a definition in Section 9.1.x and an entry in the 5.1 definitions table.

    • In the absence of the above definition of ‘situation occurrence’, the RAAML user is left to guess how ‘situation occurrences’ should be represented in the model?
    o One might initially assume that a ‘situation occurrence’ is intended to be an instances of ‘situation’, but this assumption would appear to contradict the definition of ‘situation’, which states it is a set of ‘situation occurrences’. In other words, every instance of ‘situation’ must be associated with a set corresponding instances of ‘situation occurrence’
    o What ‘types’ of ‘situation occurrence’ exist (definition of ‘situation’ states “…situation occurrences of some type”)
    o What is the nature of the set of ‘situation occurrences’ that are described by a ‘situation’?
     Should this be represented in UML with shared or composite aggregation from whatever represents ‘situation occurrence’ to ‘situation’ – maybe not, because ‘situation’ only “describes a set”, so perhaps this should be a plain association labelled ‘describes’?
     If the relationship is aggregation, should/could a ‘situation’ comprise anything else alongside the set (such as a description of the relationships between the members of the set)?
    o Regardless of whether ‘situation’ aggregates ‘situation occurrences’ or merely describes them, what range of multiplicities is valid (e.g. can a ‘situation’ be an empty set, have only a single constituent ‘situation occurrence’, or must it be comprise two or more)?

    • RAAML deliberately relies on UML classifiers to represent “system, place, time and state”.
    o State is a UML type and RAAML shows e.g. «FailureState» extending the «State» metaclass, but which classifiers are intended to be used for ‘system’, ‘time’, and ‘place’?
    o I am also left wondering why RAAML relies on classifiers for this purpose, rather than making them explicit in the Core Concepts – no rationale for this decision is provided. This seems almost certain to result in various interpretations in different organizations' tools, thus violating the stated aim "avoid inconsistent model-based solutions"

  • Reported: RAAML 1.0 — Tue, 21 Jun 2022 16:59 GMT
  • Disposition: Deferred — RAAML 1.1
  • Disposition Summary:

    Situation occurence is defined in the body text

    The situation occurence is defined in the body text of the section describing the domain model. It is not a specific defined element and situation occurrences could be modeled using instances although none of the provided methods leverage this capability and it is therefore not specifically defined. If the need for instances is necessary for any future added methods, the definitions will be revisted at that time.

  • Updated: Mon, 17 Jun 2024 13:38 GMT

Support for Risk Matrices

  • Key: RAAML11-2
  • Status: closed  
  • Source: KnowGravity Inc. ( Mr. Markus Schacher)
  • Summary:

    How are risk matrices supported that visually relate risks to the probability and severity of their occurrence as well as to the defined risk acceptance criteria levels (e.g. acceptable/tolerable/intolerable)?

  • Reported: RAAML 1.0b1 — Sun, 25 Apr 2021 08:59 GMT
  • Disposition: Deferred — RAAML 1.1
  • Disposition Summary:

    Out of scope of RAAML 1.1

    Risk matrices is a useful capability in S&R domain however support for them is out of scope for RAAML 1.1. We will consider adding support for risk matrices in upcoming versions of the specification.

  • Updated: Mon, 17 Jun 2024 13:38 GMT

Issue/task tracking

  • Key: RAAML11-3
  • Status: closed  
  • Source: KnowGravity Inc. ( Mr. Markus Schacher)
  • Summary:

    How is issue/task/responsibility tracking supported for an (unsatisfied) ISO 26262 safety case?

  • Reported: RAAML 1.0b1 — Sun, 25 Apr 2021 09:08 GMT
  • Disposition: Closed; Out Of Scope — RAAML 1.1
  • Disposition Summary:

    The RAAML specification does not cover issue tracking

    Issue tracking is out of scope for the RAAML specification. There are tools existing which track issues and would be expected to be used for ISO 26262.

  • Updated: Mon, 17 Jun 2024 13:38 GMT

Add a Causality association class which extends simple Causality association

  • Key: RAAML11-29
  • Status: open  
  • Source: Ford Motor Company ( Mr. Kyle Post)
  • Summary:

    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.

  • Reported: RAAML 1.0 — Mon, 25 Sep 2023 20:15 GMT
  • Updated: Mon, 30 Oct 2023 12:53 GMT

Generalization relation from Situation to SysML Block is not loaded in EA

  • Key: RAAML11-16
  • Status: open  
  • Source: msg Plaut Austria ( Florian Wagner)
  • Summary:

    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.

  • Reported: RAAML 1.0b2 — Tue, 15 Nov 2022 12:14 GMT
  • Updated: Wed, 30 Nov 2022 20:44 GMT

STPA is not properly implemented

  • Key: RAAML11-15
  • Status: open  
  • Source: Blue Origin LLC ( Charles F Radley)
  • Summary:

    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.

  • Reported: RAAML 1.0b2 — Thu, 3 Nov 2022 13:46 GMT
  • Updated: Thu, 3 Nov 2022 17:37 GMT