Risk Analysis and Assessment Modeling Language Avatar
  1. OMG Specification

Risk Analysis and Assessment Modeling Language — All Issues

  • Acronym: RAAML
  • Issues Count: 61
  • Description: All Issues
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
RAAML-54 misleading/ambiguous term of abstract stereotype RAAML 1.0b1 RAAML 1.0 Resolved closed
RAAML-51 correct referencing of the GSN standard RAAML 1.0b1 RAAML 1.0 Resolved closed
RAAML-57 Inconsistent/incompatible term for element RAAML 1.0b1 RAAML 1.0 Resolved closed
RAAML-1 Gate.sourceEvent type needs to be widened to FTAElement RAAML 1.0b1 RAAML 1.0 Resolved closed
RAAML-29 Add property metatype to FTA profile Event and Gate Stereotypes RAAML 1.0b1 RAAML 1.0 Resolved closed
RAAML-8 Diagram name has no spaces, but package name does RAAML 1.0b1 RAAML 1.0 Resolved closed
RAAML-7 Spelling: Encompassing RAAML 1.0b1 RAAML 1.0 Resolved closed
RAAML-4 S&R is Safety & Reliability? Should this be updated? RAAML 1.0b1 RAAML 1.0 Resolved closed
RAAML-5 RAAML instead of S&R? RAAML 1.0b1 RAAML 1.0 Resolved closed
RAAML-40 use of the term 'probability' RAAML 1.0b1 RAAML 1.0 Resolved closed
RAAML-9 STPA Inadequate Process Model Situations Have Spaces in Their Names RAAML 1.0b1 RAAML 1.0 Resolved closed
RAAML-25 Need identifiers (IDs) for all <> Elements RAAML 1.0b1 RAAML 1.0 Resolved closed
RAAML-95 UnsafeControlAction should inherit from Situation Stereotype RAAML 1.0b1 RAAML 1.0 Resolved closed
RAAML-92 File FMEALib.xmi is not working RAAML 1.0b1 RAAML 1.0 Resolved closed
RAAML-102 Majority Vote Gate calculation error RAAML 1.0b1 RAAML 1.0 Resolved closed
RAAML-93 INHIBITConstraintBlock Javascript the same as for the ANDConstraintBlock RAAML 1.0b1 RAAML 1.0 Closed; No Change closed
RAAML-97 Text in spec specifies only one cause is allowed where the model allows many RAAML 1.0b1 RAAML 1.0 Resolved closed
RAAML-53 Choice of allocation of GSN fields to UML attributes RAAML 1.0b1 RAAML 1.0 Closed; No Change closed
RAAML-52 correct attribution of the GSN standard and derived material RAAML 1.0b1 RAAML 1.0 Resolved closed
RAAML-56 Scope of GSN covered by RAAML RAAML 1.0b1 RAAML 1.0 Resolved closed
RAAML-55 Inappropriate notes in figure RAAML 1.0b1 RAAML 1.0 Resolved closed
RAAML-50 UML profile cf. Metamodel RAAML 1.0b1 RAAML 1.0 Duplicate or Merged closed
RAAML-32 Tool to Tool exchange of safety and reliability aspects of a system RAAML 1.0b1 RAAML 1.0 Closed; No Change closed
RAAML-33 RAAML UML library use and functionality RAAML 1.0b1 RAAML 1.0 Closed; No Change closed
RAAML-28 Add STPA LossScenario stereotype RAAML 1.0b1 RAAML 1.0 Resolved closed
RAAML-6 The diagram name has no space between ISO and 26262, but the package name does. RAAML 1.0b1 RAAML 1.0 Resolved closed
RAAML-45 misleading diagram for Inhibit gate RAAML 1.0b1 RAAML 1.0 Closed; No Change closed
RAAML-42 Inappropriate location of 'Undeveloped' in general section RAAML 1.0b1 RAAML 1.0 Resolved closed
RAAML-43 FMEA described is suitable for Functional FMEA only RAAML 1.0b1 RAAML 1.0 Resolved closed
RAAML-49 Use of GSN without reference to SACM RAAML 1.0b1 RAAML 1.0 Resolved closed
RAAML-36 GSN concrete syntax definitions RAAML 1.0b1 RAAML 1.0 Resolved closed
RAAML-46 Simplistic treatment of probability RAAML 1.0b1 RAAML 1.0 Closed; No Change closed
RAAML-30 Support for Risk Matrices RAAML 1.0b1 RAAML 1.0 Deferred closed
RAAML-11 Inability to import xmi profiles into Rhapsody RAAML 1.0b1 RAAML 1.0 Closed; No Change closed
RAAML-31 Issue/task tracking RAAML 1.0b1 RAAML 1.0 Deferred closed
RAAML-3 There is a lot on the diagram, why was everything merged? RAAML 1.0b1 RAAML 1.0 Closed; No Change closed
RAAML-2 Why repeat AnySituation here from Figure 9.122? RAAML 1.0b1 RAAML 1.0 Closed; No Change closed
RAAML-44 Lack of consideration of Cut Sets RAAML 1.0b1 RAAML 1.0 Deferred closed
RAAML-41 Relationship between Fault and Error RAAML 1.0b1 RAAML 1.0 Closed; No Change closed
RAAML-39 Clarity of concept of 'Event' RAAML 1.0b1 RAAML 1.0 Closed; No Change closed
RAAML-10 Elements Should Have Unique Names to Improve Clarity and Implementation RAAML 1.0b1 RAAML 1.0 Deferred closed
RAAML-34 The treatment of GSN in RAAML RAAML 1.0b1 RAAML 1.0 Deferred closed
RAAML-37 The ISO 26262 ASIL Definition RAAML 1.0b1 RAAML 1.0 Closed; No Change closed
RAAML-38 The ISO 26262 ASIL Decomposition RAAML 1.0b1 RAAML 1.0 Closed; No Change closed
RAAML-35 Concrete syntax definitions RAAML 1.0b1 RAAML 1.0 Closed; No Change closed
RAAML-19 Descriptions Says SysML IBD Instead of BDD RAAML 1.0b1 RAAML 1.0 Resolved closed

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

misleading/ambiguous term of abstract stereotype

  • Key: RAAML-54
  • Status: closed  
  • Source: Object Management Group ( Mr. Juergen Boldt)
  • Summary:

    An abstract stereotype ‘SupportingInformation’ is used to cover ContextStatement, Assumption and Justification. This is an odd choice since these 3 elements cannot be connected to the argument by the ‘SupportedBy’ relationship. This is therefore confusing and potentially misleading. Perhaps ‘ContextualInformation’ would be a better phrase (the GSN standard refers to Context, Assumption and Justification elements collectively as ‘contextual elements’

  • Reported: RAAML 1.0b1 — Tue, 11 May 2021 18:31 GMT
  • Disposition: Resolved — RAAML 1.0
  • Disposition Summary:

    Rename SupportingInformation abstract stereotype

    Rename the abstract stereotype ‘SupportingInformation’ to prevent confusion or misunderstandings.

  • Updated: Thu, 31 Mar 2022 19:32 GMT
  • Attachments:

correct referencing of the GSN standard

  • Key: RAAML-51
  • Status: closed  
  • Source: Object Management Group ( Mr. Juergen Boldt)
  • Summary:

    Section 3.3 cites www.goalstructuringnotation.info as the source of the GSN specification. In fact this location has not been the formal source of the GSN standard since Version 1 was superseded in January 2018. The formal source for version 2 is https://scsc.uk/scsc-141B. It should also be noted that this will be replaced by version 3 imminently (due to be released on 3rd May 2021, and available at https://scsc.uk/scsc-141C). A new information site for GSN is available at https://scsc.uk/gsn and the goalstructuringnotation.info domain will be remapped shortly to point to this new location

  • Reported: RAAML 1.0b1 — Tue, 11 May 2021 18:28 GMT
  • Disposition: Resolved — RAAML 1.0
  • Disposition Summary:

    Reference is out of date for SCSC standard

    Update reference to the latest version of SCSC standard

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Inconsistent/incompatible term for element

  • Key: RAAML-57
  • Status: closed  
  • Source: Object Management Group ( Mr. Juergen Boldt)
  • Summary:

    ContextStatement has been used as an element name which is an odd choice given that the GSN standard uses <context statement> as the term for the <element statement> of a GSN context element. ‘Context’ would be more consistent with the selection of terms for other GSN elements

  • Reported: RAAML 1.0b1 — Tue, 11 May 2021 18:40 GMT
  • Disposition: Resolved — RAAML 1.0
  • Disposition Summary:

    *Rename ContextStatement abstract stereotype *

    Rename the abstract stereotype ‘ContextStatement’ to avoid confusion and misunderstandings.

  • Updated: Thu, 31 Mar 2022 19:32 GMT
  • Attachments:

Gate.sourceEvent type needs to be widened to FTAElement

  • Key: RAAML-1
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Tomas Juknevicius)
  • Summary:

    At the moment it is not possible to connect the transfer in to a gate with a connector properly-typed-by-association, because
    TransferIn type is FTATree, not the Event
    and gate source association currently connects Gate and Event;

    To address this, Gate.sourceEvent type needs to be widened to FTAElement (which allows both Event and FTATree)

  • Reported: RAAML 1.0b1 — Wed, 17 Feb 2021 13:55 GMT
  • Disposition: Resolved — RAAML 1.0
  • Disposition Summary:

    Gate.sourceEvent type needs to be widened to FTAElement

    At the moment it is not possible to connect the transfer in to a gate with a connector properly-typed-by-association, because
    TransferIn type is FTATree, not the Event
    and gate source association currently connects Gate and Event;

  • Updated: Thu, 31 Mar 2022 19:32 GMT
  • Attachments:

Add property metatype to FTA profile Event and Gate Stereotypes

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

    There is a user need to model FTA's in the IBD view directly, which may be covered by tool vendor implementation, but in addition there is the need to take elements from other analyses and tie them to elements in the FTA directly. RAAML allows this but the icons are lost from the initial FTA element when they are typed by other elements (for example: Failure Mode). This has been demonstrated in the FTA and FMEA cross analysis use case where FTA IBD elements are typed by FMEA elements.

  • Reported: RAAML 1.0b1 — Thu, 15 Apr 2021 15:08 GMT
  • Disposition: Resolved — RAAML 1.0
  • Disposition Summary:

    Add a Property meta class to FTA Event stereotype

    To be able to create fault trees that are using situation from other methodologies as events like FMEA failure modes.

    Therefore, constraints in the fault trees need to be updated.

  • Updated: Thu, 31 Mar 2022 19:32 GMT
  • Attachments:

Diagram name has no spaces, but package name does

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

    Comment from Gaphor UML/SysML implementation reported by Dan Yeaw. Editorial comment: The figure name does not have a space after ISO. The following "Figure 10.16 - ISO26262 Profile" should be changed to "Figure 10.16 - ISO 26262 Profile".

  • Reported: RAAML 1.0b1 — Thu, 25 Feb 2021 13:11 GMT
  • Disposition: Resolved — RAAML 1.0
  • Disposition Summary:

    *The Figure 10.16 name is missing a space after "ISO" *

    The figure name does not have a space after ISO. The following "Figure 10.16 - ISO26262 Profile" should be changed to "Figure 10.16 - ISO 26262 Profile".

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Spelling: Encompassing

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

    Comment from Gaphor UML/SysML implementation reported by Dan Yeaw. Editorial comment: Misspelled encompassing in figure title "Figure 10.14 - All-Encompasing Operational Situations"

  • Reported: RAAML 1.0b1 — Thu, 25 Feb 2021 13:09 GMT
  • Disposition: Resolved — RAAML 1.0
  • Disposition Summary:

    Fix spelling for Figure 10.14

    Editorial comment: Misspelled encompassing in figure title "Figure 10.14 - All-Encompasing Operational Situations"

  • Updated: Thu, 31 Mar 2022 19:32 GMT

S&R is Safety & Reliability? Should this be updated?

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

    Comment received from Gaphor UML/SysML implementation reported by Dan Yeaw. Figure 10.4 - General Concepts Profile. Editorial comment on note that the note should say "From RAAML Core" instead of "From S&R Core".

  • Reported: RAAML 1.0b1 — Thu, 25 Feb 2021 13:01 GMT
  • Disposition: Resolved — RAAML 1.0
  • Disposition Summary:

    Figure 10.4 Note text update

    Figure 10.4 - General Concepts Profile. Editorial comment on note that the note should say "From RAAML Core" instead of "From S&R Core".

  • Updated: Thu, 31 Mar 2022 19:32 GMT
  • Attachments:

RAAML instead of S&R?

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

    Comment received from Gaphor UML/SysML implementation reported by Dan Yeaw. Editorial comment. The note should read "From RAAML core" instead of "From S&R core".

  • Reported: RAAML 1.0b1 — Thu, 25 Feb 2021 13:03 GMT
  • Disposition: Resolved — RAAML 1.0
  • Disposition Summary:

    FTA Profile Note text update

    The note in figure 10.9 should read "From RAAML core" instead of "From S&R core".

  • Updated: Thu, 31 Mar 2022 19:32 GMT
  • Attachments:

use of the term 'probability'

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

    AbstractEvent uses the attribute 'probability' as a placeholder. The term 'probability' will intuitively be associated with a number between 0 and 1. ISO/IEC guide 73 uses the term 'likelihood' with the following note:
    "NOTE 2 The English term “likelihood” does not have a direct equivalent in some languages; instead, the equivalent of the term “probability” is often used. However, in English, “probability” is often narrowly interpreted as a mathematical term. Therefore, in risk management terminology, “likelihood” is used with the intent that it should have the same broad interpretation as the term “probability” has in many languages other than English"
    Given the abstract definition of AbstractEvent, and the attribute statement that method developers can derive more specialized ways to characterize probability, it may be helpful to use the subtlety of the difference in terms here to allow more clarity between the concept (likelihood) and its utilization (probability)

  • Reported: RAAML 1.0b1 — Fri, 30 Apr 2021 10:23 GMT
  • Disposition: Resolved — RAAML 1.0
  • Disposition Summary:

    Rename to likelihood

    The working group agrees to rename the probability property to "likelihood". In addition to that, the probability property in FTAElement shall redefine the likelihood property and AbstractOperationalSituation shall inherit from AbstractEvent and also redefine the likelihood property.

  • Updated: Thu, 31 Mar 2022 19:32 GMT
  • Attachments:

STPA Inadequate Process Model Situations Have Spaces in Their Names

  • Key: RAAML-9
  • Status: closed  
  • Source: Gaphor Project ( Dan Yeaw)
  • Summary:

    The following Process Model situations have spaces in their names:
    Inadequate Controller Decisions
    Inadequate Control Execution
    Inadequate Process Behavior
    Inadequate Feedback and Inputs

    They should be in upper camel case / Pascal case for consistency with the other elements in the specification.

  • Reported: RAAML 1.0b1 — Sun, 28 Feb 2021 17:10 GMT
  • Disposition: Resolved — RAAML 1.0
  • Disposition Summary:

    Spaces in classifiers for process models

    Unnecessary spaces in the classifier names.

  • Updated: Thu, 31 Mar 2022 19:32 GMT
  • Attachments:

Need identifiers (IDs) for all <> Elements

  • Key: RAAML-25
  • Status: closed   Implementation work Blocked
  • Source: Ford Motor Company ( Mr. Kyle Post)
  • Summary:

    The current specification only provides an ID property for GSN elements. Hazard Analysis methods typically use the element names or unique identifiers and not having an explicit property in the specification will lead to inconsistencies across tools. The proposal is to add an ID property to the core <<Situation>> which would be inherited by all the RAAML method elements.

  • Reported: RAAML 1.0b1 — Fri, 26 Mar 2021 13:45 GMT
  • Disposition: Resolved — RAAML 1.0
  • Disposition Summary:

    Add ID carrier to Core Profile

    There is not an ID property that is consistent across the specification for elements. This leaves the implementer to adding an ID which will be inconsistent from implementation to implementation.

  • Updated: Thu, 31 Mar 2022 19:32 GMT
  • Attachments:

UnsafeControlAction should inherit from Situation Stereotype

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

    UnsafeControlAction should inherit from Situation Stereotype. It is currently inheriting from the FailureMode stereotype.

  • Reported: RAAML 1.0b1 — Mon, 27 Sep 2021 16:48 GMT
  • Disposition: Resolved — RAAML 1.0
  • Disposition Summary:

    Inherit from Situation Stereotype

    Inherit UnsafetControlAction from Situation Stereotype

  • Updated: Thu, 31 Mar 2022 19:32 GMT
  • Attachments:

File FMEALib.xmi is not working

  • Key: RAAML-92
  • Status: closed   Implementation work Blocked
  • Source: CCASS Hochschule Darmstadt ( Nick Berezowski)
  • Summary:

    For some reasons, the Library of the FMEA Profile is not working. It's not possible to open it with and XMI-Viewer, with Magic Draw or any other tool.
    You can prove it with opening the file in the explorer.

    I try to implement the RAAML-Profiles in Papyrus, and it would be great if I can use this file, too.

    Best Regards

  • Reported: RAAML 1.0b1 — Fri, 23 Jul 2021 09:25 GMT
  • Disposition: Resolved — RAAML 1.0
  • Disposition Summary:

    *Fix syntactic errors on .xmi file *

    RAAML file in question (the ad/20-07-12, FMEALib.xmi) has two simple XML problems
    at line #107 and line #150
    namely – missing the closing slash in the <type> element

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Majority Vote Gate calculation error

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

    The FTA Majority Vote Gate does not calculate as expected which was identified from usage of the imported FTA .xmi.

  • Reported: RAAML 1.0b1 — Wed, 20 Oct 2021 13:44 GMT
  • Disposition: Resolved — RAAML 1.0
  • Disposition Summary:

    Error in .xmi calculation for Majority Vote

    The Majority Vote calculation in the FTA.xmi is not calculating correctly.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

INHIBITConstraintBlock Javascript the same as for the ANDConstraintBlock

  • Key: RAAML-93
  • Status: closed   Implementation work Blocked
  • Source: KARL STORZ SE & Co. KG ( Marting Bohring)
  • Summary:

    It looks like a copy & paste error me.
    The Javascript used for the inihibit gate constraint block is the same as the Jvascript used for the AND constraint block.

    The control value input is not even used in the Javascript which triggered me to look more closely

  • Reported: RAAML 1.0b1 — Mon, 9 Aug 2021 06:41 GMT
  • Disposition: Closed; No Change — RAAML 1.0
  • Disposition Summary:

    Question on Inhibit constraint calculation

    Question if the Inhibit Gate probability calculation should be similar to the And Gate. According to the underlying FTA standard the probability is calculated the same for the Inhibit Gate and the And Gate with some differences on the inputs. The calculation was checked and performs as expected.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Text in spec specifies only one cause is allowed where the model allows many

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

    The spec has an inconsistency in it - the text says there is one (a) cause - but the graphic shows 1..*. Text:

    "An AbstractFMEAItem is a scenario (more specifically - AbstractRisk scenario) composed of a failure mode, a cause and
    (potentially multiple) effect(s). It stores assessed and mitigated risk priority numbers."

    Figure: 9.32

  • Reported: RAAML 1.0b1 — Thu, 30 Sep 2021 13:02 GMT
  • Disposition: Resolved — RAAML 1.0
  • Disposition Summary:

    Update text description to match plural causes in FMEA library diagram

    Update singular "cause" to "causes" in FMEA Library Item text 9.3.1.

  • Updated: Thu, 31 Mar 2022 19:32 GMT
  • Attachments:

Choice of allocation of GSN fields to UML attributes

  • Key: RAAML-53
  • Status: closed  
  • Source: Object Management Group ( Mr. Juergen Boldt)
  • Summary:

    Under ‘GSNNode’ it is stated that the ‘short phrase’ (referred to in the GSN standard as the <element statement>) shall be captured as the UML model element name, whilst the Human-readable identifier (referred to in the GSN standard as the <element identifier>) shall be stored as a separate tag. This appears an odd choice since the <element identifier> is assured to be unique, whilst the <element statement> is not. It may be appropriate to swap these allocations.

  • Reported: RAAML 1.0b1 — Tue, 11 May 2021 18:30 GMT
  • Disposition: Closed; No Change — RAAML 1.0
  • Disposition Summary:

    GSN Statement Text and Identifier

    The uniqueness or non-uniqueness of the field was not a primary reason for the mapping choice.
    The reason for mapping the GSN statement text to a UML element name is to make it easier for the end user to see/find/manipulate the element in the tool UI. UML tools primarily expose the model element names everywhere in the GUI (element visualization in the diagrams, various tables, containment trees),
    while tag information is secondary.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

correct attribution of the GSN standard and derived material

  • Key: RAAML-52
  • Status: closed  
  • Source: Object Management Group ( Mr. Juergen Boldt)
  • Summary:

    The GSN standard is made available under creative commons licence version 4. This allows free use but requires appropriate attribution, which could be accommodated in the reference in section 3.3, or in section 4.
    “GSN Standard V2 License: This work is licensed under the Creative Commons Attribution 4.0 International License.
    To view a copy of this license, visit http://creativecommons.org/licenses/by/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.
    You are free to share the material in any form and adapt the material for any purpose providing you attribute the material to the SCSC ACWG, include the license details above and indicate if any changes were made. See the license for full details.”

  • Reported: RAAML 1.0b1 — Tue, 11 May 2021 18:29 GMT
  • Disposition: Resolved — RAAML 1.0
  • Disposition Summary:

    Reference creative commons license

    Add creative commons acknowledgement for GSN standard.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Scope of GSN covered by RAAML

  • Key: RAAML-56
  • Status: closed  
  • Source: Object Management Group ( Mr. Juergen Boldt)
  • Summary:

    It is noted that the GSN profile only addresses the core GSN notation (e.g. it does not address patter or modular extensions). A note to this effect in 9.6.1 would be worthwhile for clarity

  • Reported: RAAML 1.0b1 — Tue, 11 May 2021 18:39 GMT
  • Disposition: Resolved — RAAML 1.0
  • Disposition Summary:

    Initial support for core elements comment

    Add note to the GSN section’s introduction that the GSN UML profile only covers the GSN core notation in this release/edition. Also add that same note to the Related Documents section.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Inappropriate notes in figure

  • Key: RAAML-55
  • Status: closed  
  • Source: Object Management Group ( Mr. Juergen Boldt)
  • Summary:

    In figure 10.12 there is a note against ‘solution’ that states a solution could also be some artefact of the system. The GSN standard is clear that a solution presents a reference to evidence. It is not understood how this can be an artefact of the system. Similarly a statement in the note attached to ‘contexturalStatement’ states that context can be either context statement or some artifact of the system; this distorts the definition in the GSN standard which states that the <context statement> can be either an a reference to contextual information, or a statement. This implies that there is not a direct relationship between the modelling in RAAML and the GSN standard.

  • Reported: RAAML 1.0b1 — Tue, 11 May 2021 18:32 GMT
  • Disposition: Resolved — RAAML 1.0
  • Disposition Summary:

    *Remove note from figure 10.12 solution *

    We should remove the ability to directly substitute a GSN solution with a SysML element because the result is not a valid GSN model. However, what we should allow is for GSN solution to be able to reference a SysML element. We need to decide whether that is by a tag reference property, or by a «trace» relationship, or a dedicated relationship.

  • Updated: Thu, 31 Mar 2022 19:32 GMT
  • Attachments:

UML profile cf. Metamodel

  • Key: RAAML-50
  • Status: closed  
  • Source: Object Management Group ( Mr. Juergen Boldt)
  • Summary:

    A relationship of GSN to the SACM metamodel has been developed and is publicly available. It is not clear why the GSN UML profile is required separately to this metamodel, what relationship or utility is intended

  • Reported: RAAML 1.0b1 — Tue, 11 May 2021 18:27 GMT
  • Disposition: Duplicate or Merged — RAAML 1.0
  • Disposition Summary:

    Merge with RAAML-49

    Same solution as RAAML-49. "Add a statement to the introduction of the GSN UML profile section to explain that whilst GSN is an extension of the OMG SACM 2.1 standard, which has a defined meta-model based on the OMG MOF standard, the objectives of RAAML to integrate with SysML 1.5 & 1.6 necessitate the use of a UML profile interpretation of the GSN standard. In doing this there are certain design choices born out of the constraints of conforming to UML that may be considered imperfect from a pure GSN implementation point of view."

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Tool to Tool exchange of safety and reliability aspects of a system

  • Key: RAAML-32
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    While a UML profile can provide a mechanism for establishing the primitives and components for capturing the safety and reliability aspects of a system within a MBSE tool, the real goal would appear to be the exchange of MBSE models that include safety and reliability aspects. A metamodel would seem to be a more appropriate mechanism for capturing/conveying the details of what is to be exchanged. Any UML profile necessary could be derived from that metamodel when needed. How does RAAML support the exchange of safety and reliability aspects of a system?

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

    UML XMI used as an exchange format

    RAAML WG took a lightweight approach to base RAAML on UML+profiles+libraries to promote exchange of S&R information between tools. This approach has two advantages over having separate metamodel approach. First, any UML-compliant tool (including SysML tools) can load and store these models. A separate metamodel would necessitate a special tool that would need to know how to load and store these models. Second advantage is that connectivity between safety and reliability information and the systems model is easy to achieve for tool vendors that already support UML.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

RAAML UML library use and functionality

  • Key: RAAML-33
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    What is the envisioned use and utility of the RAAML UML libraries with respect to exchanging safety and reliability aspects of a system from one MBSE modelling tool to another?

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

    RAAML is extending SysML to support interchange via XMI

    RAAML is extending SysML thus exchange between different MBSE tools is expected to happen via XMI.
    Section "2. Conformance" is more explicit about that:

    "Type 1 Conformance: RAAML model interchange conformance. A tool demonstrating model interchange conformance can import and export conformant XMI for all valid RAAML models."

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Add STPA LossScenario stereotype

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

    Currently the LossScenario is only defined in the STPA library and does not include a defining stereotype. The LossScenario is similar in purpose to the FMEAItem where it is typically the focus of a line item in an analysis table. The proposal is to add a LossScenario stereotype to the STPA Profile to be consistent with the FMEA and give a handle for table generation.

  • Reported: RAAML 1.0b1 — Thu, 15 Apr 2021 14:54 GMT
  • Disposition: Resolved — RAAML 1.0
  • Disposition Summary:

    Introduce LossScenario Stereotype in STPA Profile

    Add stereotype to be consistent with which stereotypes are defined for other methods. This is similar to FMEAItem Stereotype

  • Updated: Thu, 31 Mar 2022 19:32 GMT

The diagram name has no space between ISO and 26262, but the package name does.

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

    Comment received from Gaphor UML/SysML implementation reported by Dan Yeaw. Editorial comment:
    The figure name "Figure 10.13 - ISO26262 Library" should have a space after ISO as the following "Figure 10.13 - ISO 26262 Library".

  • Reported: RAAML 1.0b1 — Thu, 25 Feb 2021 13:06 GMT
  • Disposition: Resolved — RAAML 1.0
  • Disposition Summary:

    *Add Space in Figure 10.13 name after "ISO" *

    The figure name "Figure 10.13 - ISO26262 Library" should have a space after ISO. Change the Figure name to include a space after ISO to "Figure 10.13 - ISO 26262 Library".

  • Updated: Thu, 31 Mar 2022 19:32 GMT

misleading diagram for Inhibit gate

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

    The representation of Figure 9.59 could be taken to imply the conditioning event connects to the bottom of the gate. By convention the conditioning event connects to the side connector with the bottom connection used for the enabling condition.
    This confusion is also conveyed in Figure 10.8 (page 111)

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

    Connect the condition association to the right of the INHIBIT gate

    Connect the condition association to the right of the INHIBIT gate for clarity (figure 9.59 and 10.8).

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Inappropriate location of 'Undeveloped' in general section

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

    'Undeveloped' seems to be defined for the exclusive use with the GSN profile, so it seems more appropriate to define it in 9.6.1.
    There are also some typographical corrections that should be considered ...express the fact that the goal or strategy is not fully developer... should be replaced with ...express the fact that support for the goal or strategy is not fully developed...

  • Reported: RAAML 1.0b1 — Fri, 30 Apr 2021 10:30 GMT
  • Disposition: Resolved — RAAML 1.0
  • Disposition Summary:

    Change wording to be relevant in FTA and GSN context

    Wording needs to be changed to be relevant in FTA and GSN context.

    Updated model, Updated stereotype description text, Update .xmi

  • Updated: Thu, 31 Mar 2022 19:32 GMT

FMEA described is suitable for Functional FMEA only

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

    The failure modes covered by this section are exclusively Functional failure modes, they are one of a number of taxonomies of functional failure and would not be suitable for component level FMEA, or FMEA integration to higher level items.
    This should be acknowledged in the introduction to this section.

  • Reported: RAAML 1.0b1 — Fri, 30 Apr 2021 10:33 GMT
  • Disposition: Resolved — RAAML 1.0
  • Disposition Summary:

    RAAML is not restricted to functional or component FMEAs only

    The RAAML working group will elaborate in the specification text that RAAML supports both functional and component FMEA. The target of the RelevantTo relationship can be any element, the source needs to be connected to a situation.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Use of GSN without reference to SACM

  • Key: RAAML-49
  • Status: closed  
  • Source: Object Management Group ( Mr. Juergen Boldt)
  • Summary:

    Use of GSN without reference to SACM
    Issue Description: We believe that it would be appropriate for an OMG standard to be referencing the definitive work on assurance modeling language published by OMG, and therefore suggest that SACM should be included.

  • Reported: RAAML 1.0b1 — Tue, 11 May 2021 18:26 GMT
  • Disposition: Resolved — RAAML 1.0
  • Disposition Summary:

    Reference to SACM

    Add text to explain use of GSN UML profile in RAAML is based on extension of SACM.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

GSN concrete syntax definitions

  • Key: RAAML-36
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    In Figures 9.104 and 9.105 the RAAML specification makes suggestions on the concrete syntax (in this case the graphical notation) of GSN elements in which the metamodels (sets of abstract syntax) are defined. Defining concrete syntax for GSN elements would seem to be out of the scope, where SACM and GSN itself should be leveraged for these definitions rather than defining them in RAAML.

  • Reported: RAAML 1.0b1 — Thu, 29 Apr 2021 21:41 GMT
  • Disposition: Resolved — RAAML 1.0
  • Disposition Summary:

    Revise the text so that it is clear that SCSC/GSN defines the graphical notation.

  • Updated: Thu, 31 Mar 2022 19:32 GMT
  • Attachments:

Simplistic treatment of probability

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

    The acknowledged simplistic treatment of probability can easily be replaced with a more correct definition that addresses independence [P(a.b) = (P(a) - P(cc)) x (P(b) - P(cc)) + P(cc)] where cc represents the common/non-independent failure & [P(a+b) = P(a) + P(b) - P(a.b)]

    Any simplification should be taken by the modeler not by the profile.

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

    Current specification supports common cause probabilities

    A common cause event can be addressed by combining the independent probabilities of the events and adding a OR gate to include the common cause component.

    The RAAML spec allows for changing the math for any gate.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Support for Risk Matrices

  • Key: RAAML-30
  • 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.0
  • Disposition Summary:

    Adding support for risk matrices

    Risk matrices are important in RAAML context. However, the focus of RAAML 1.0 is to provide the foundation for modeling safety and reliability aspects of systems. We will be adding support for risk matrices in the upcoming versions of RAAML.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Inability to import xmi profiles into Rhapsody

  • Key: RAAML-11
  • Status: closed  
  • Source: Stellantis ( Jerry Hendler)
  • Summary:

    Hi folks, I am part of the Society of Automotive Engineers STPA workgroup with Kyle Post and others. I did reach out to Kyle and he didn't have a solution for my issue, thought I'd ask the group. I am using Rhapsody v8.4 developing SysML models (using their SysML profile) and trying to import these RAAML profiles, but the Rhapsody xmi importer doesn't get past the first step, saying 'Cannot determine uml version'. Wondered if this is an issue others have run into and whether there might be a simple solution, Thanks, Jerry

  • Reported: RAAML 1.0b1 — Tue, 16 Mar 2021 14:01 GMT
  • Disposition: Closed; No Change — RAAML 1.0
  • Disposition Summary:

    Current .xmi's are correct and standard compliant

    Was an issue with using an older tool version.

    Data that the xmi is correct:
    -Correct from MagicDraw's test
    -Correct from Enterprise Architect's test
    -Correct by comparison to other OMG normative documents:
    For example, UML 2.5.1 (e.g. StandardProfile.xmi)
    namespaces, used for UML models are:
    xmlns:xmi="http://www.omg.org/spec/XMI/20131001"
    xmlns:uml="http://www.omg.org/spec/UML/20161101"
    and those are exactly the namespaces that we used across the *.xmi documents in RAAML

    Additionally, the Rhapsody version used was an older version and if the UML version is manually changed to an older version it imported into Rhapsody.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Issue/task tracking

  • Key: RAAML-31
  • 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: Deferred — RAAML 1.0
  • Disposition Summary:

    Out of scope for current version of the RAAML specification

    The current version of the RAAML specification does not specify a way to link to issues in issue tracking systems. That may either be described in another specification or may be a focus area in upcoming versions of the RAAML specification.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

There is a lot on the diagram, why was everything merged?

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

    Comment received from Gaphor UML/SysML implementation reported by Dan Yeaw. Figure 10.3 - General Concepts Library. Editorial comment. There is a lot on the diagram, why was everything merged?

  • Reported: RAAML 1.0b1 — Thu, 25 Feb 2021 12:59 GMT
  • Disposition: Closed; No Change — RAAML 1.0
  • Disposition Summary:

    Concerns on general concepts library image

    It is an overview on all concepts included in the general library and providing a summary on releations among concepts. Without this overview you don't get the big picture.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Why repeat AnySituation here from Figure 9.122?

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

    Issue reported from Gaphor UML/SysML tool implementation notes by Dan Yeaw. Editorial comment is on Figure 9.122 referring to showing the AnySituation line on the document asking why the line is repeated here.

  • Reported: RAAML 1.0b1 — Thu, 25 Feb 2021 12:55 GMT
  • Disposition: Closed; No Change — RAAML 1.0
  • Disposition Summary:

    Why repeat AnySituation

    It is a visualization of the text above the image. The OperationalSituiation is inherited from AnySituation.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Lack of consideration of Cut Sets

  • Key: RAAML-44
  • 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: Deferred — RAAML 1.0
  • Disposition Summary:

    RAAML provides sufficient information to calculate cut sets

    Operations such as calculation of cut sets are meant to be implemented by tool vendors. The RAAML specification needs to provide enough data for these operations to be able to return results. Current version of the RAAML specification provides enough data for that. That was demonstrated in the pilot implementation by export to the R fault tree package contained in CRAN R repository by means of the generic tables provided in Cameo Systems Modeler.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Relationship between Fault and Error

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

    ErrorRealization is used to define the relationship between Error and Failure, however no such relationship between fault and error or failure appear to be described, leaving the concept unclear.

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

    The Activation relationship connects error and fault

    The Activation relationship is defined in that same diagram and it connects to AbstractCause and DysfunctionalEvent which play the fault and error roles respectively in that association.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Clarity of concept of 'Event'

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

    AbstractEvent is introduced as a derivative of AnySituation. 9.1 defines the situation concept based on state. It is not obvious how an event can be a state when interpreted from the perspective of the fault modeling techniques in scope of this document.

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

    Current description is sufficient

    The word "state" as used in the definition of Situation can apply not only to the system under analysis but also to its environment. The states of the environment can be used as events triggering changes in system states.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Elements Should Have Unique Names to Improve Clarity and Implementation

  • Key: RAAML-10
  • 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: Deferred — RAAML 1.0
  • Disposition Summary:

    Deficiency in Gaphor tool

    The AND Stereotype in the Profile and the AND block in the Library are distinguishable because of id, type and namespace are different.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

The treatment of GSN in RAAML

  • Key: RAAML-34
  • 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: Deferred — RAAML 1.0
  • Disposition Summary:

    SACM mapping RAAML 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: Thu, 31 Mar 2022 19:32 GMT

The ISO 26262 ASIL Definition

  • Key: RAAML-37
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    In Figure 9.127 of the ISO-26262 part of RAAML the concept of ASIL was misread from the ISO-26262 2018 standard. In ISO-26262 Clause 1, it states that QM is not an ASIL. Therefore, it suggests that Figure 9.127 should be reviewed/revised to align with Clause 1 of ISO-26262.

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

    Consistent with the use in the industry and ISO 26262 standard

    As per Table 4 - ASIL determination in the ISO 26262 chapter 3, QM is classified under ASIL. RAAML is consistent with what is specified in ISO 26262 specification even if QM does not have ASIL requirements.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

The ISO 26262 ASIL Decomposition

  • Key: RAAML-38
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    ASIL decomposition levels should not be included in the ASIL stereotype. Maybe ASIL decomposition belongs to a sub-type of ASIL in RAAML.

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

    ASIL decomposition levels

    The ASIL decomposition levels are included as they are commonly used when specifying the safety integrity levels for requirements and elements. This is referred to as the ASIL in industry and breaking it into a separate or subtype does not seem to have a specific use case for the added complexity.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Concrete syntax definitions

  • Key: RAAML-35
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Does RAAML include the definition for concrete syntax?

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

    RAAML of concrete syntax

    RAAML uses UML and SysML for the concrete syntax. The reference to UML is made on page 3 and page 5 of the proposal.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Descriptions Says SysML IBD Instead of BDD

  • Key: RAAML-19
  • Status: closed  
  • Source: Gaphor Project ( Dan Yeaw)
  • Summary:

    There are 5 instances in the informative description that says the Functional Safety can be represented in a SysML IBD, but the diagrams are SysML BDDs.

    • Page 24: The conditions library can either be specified using a SysML IBD diagram (Figure 2.23)
    • Page 26: They can be represented using SysML IBD diagrams (see Figure 2.25)
    • Page 27: They can be represented using SysML IBD diagrams (see Figure 2.27 – Accident scenario in a SysML BDD diagram)
    • Page 28: Effects and hazards are either represented using SysML IBD diagrams (see Figure 2.29)
    • Page 30: HazardousEvents are specified either in SysML IBD diagrams (see Figure 2.32)

    I recommend changing the text to SysML BDD.

  • Reported: RAAML 1.0b1 — Sun, 21 Mar 2021 17:57 GMT
  • Disposition: Resolved — RAAML 1.0
  • Disposition Summary:

    Update RAAML Informative Example document Editorial Errors

    Example text refers to IBD where the diagram is a BDD in 5 places in the document. Need to change text from IBD to BDD.

  • Updated: Thu, 31 Mar 2022 19:32 GMT