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.

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.

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.

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

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.

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)?

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.

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