How to Keep Safety Reasoning Connected to System Design

Safety reasoning and system design often live in different worlds

In many engineering programs, system design and safety reasoning are not simply stored in different tools. They are produced by different teams, at different times, in different processes. The system model describes the components, interfaces, requirements, states, and behavior. The safety analysis describes the hazards, failure modes, unsafe control actions, and constraints. Each develops its own language, artifacts, and review cycle, even though both describe the same system.

The connection between those views may depend on copied names, manually maintained links, custom integrations, or knowledge held by a few experienced engineers.

When safety and design drift apart, it gets easier to miss hazards and make bad decisions

When design and safety evolve separately, they can stop describing the same system. A safety analysis may still point to an old component name, an earlier interface, or a behavior the design no longer has. Both bodies of work can look internally complete while describing different versions of the system.

Teams then make decisions from an incomplete picture. They may miss a hazard, keep a safety assumption that the design has invalidated, or choose an architecture without seeing how it changes the safety argument.

Design changes make this drift particularly difficult to manage. A new interface, operating mode, or control path may require an existing hazard analysis to be reviewed, but the affected safety work can be hard to find.

The problem is not limited to keeping two versions aligned. Many system-level hazards arise from interactions recorded in the design model. A component can behave exactly as designed and the system can still become unsafe because the wrong command was issued, feedback arrived too late, or two individually correct behaviors interacted in an unexpected way. Finding these hazards requires engineers to examine the components, control actions, and feedback together. When design and safety live apart, those relationships must be reconstructed before they can be analyzed.

Keeping system design and safety reasoning in one connected model makes those relationships explicit. An architecture change can point to the safety work that may need review, and a safety claim can point back to the exact part of the design it is about.

RAAML: a modeling language that brings safety reasoning into the system model

RAAML stands for Risk Analysis and Assessment Modeling Language. It extends SysML, the Systems Modeling Language, with structured concepts for safety and reliability analysis.

SysML describes the system's components, interfaces, requirements, states, and behavior. RAAML connects hazards, failure modes, unsafe control actions, fault trees, and assurance claims directly to those design elements. The design and the safety reasoning can therefore remain part of one connected model.

RAAML also supports methods such as System-Theoretic Process Analysis (STPA), which examines hazards created by interactions and inadequate control, including cases where every component works as intended.

As system models move to SysML v2, their safety work needs to move with them

For many existing programs, there is no immediate reason to leave SysML v1. It is widely used, long-running programs depend on it, and moving a validated engineering process merely because a newer standard exists would create cost and risk.

The problem begins when new programs, suppliers, or tools adopt SysML v2. If the system model moves to v2 while its RAAML safety analysis remains in a separate v1 tool, design and safety become separated again. Their links then depend on duplicate data, custom integrations, or incompatible translations invented by different organizations.

SysML v2 also provides a standard textual notation, making models easier to inspect, compare, generate, and version. Teams can review a model change, run automated checks, and tie a safety analysis to an exact model version.

RAAML 1.1 was designed for SysML v1. SysML v2 is built differently and cannot directly load the old RAAML definitions. Translation is therefore unavoidable when a model moves forward, and a careless translation can discard safety information. The purpose of this proposal is not to make every organization migrate now. It is to ensure that when a system model moves to SysML v2, its safety meaning can move with it.

We built an open-source translator from RAAML 1.1 to SysML v2 and back

The translator moves the official RAAML 1.1 definitions into SysML v2 and can then rebuild them in SysML v1 without changing the safety information they contain.

The goal is not to invent a new version of RAAML. It is to make the translation visible and testable instead of hiding its decisions inside one vendor's tool. Teams, tool vendors, and standards contributors can inspect, test, and improve those decisions in the open.

The source proposal, implementations, tests, and signed candidate are public on GitHub. The current evidence baseline is the v0.9.0-rc.3 pre-release.

The project preserves existing RAAML definitions rather than redesigning the language

A future OMG effort to define RAAML directly for SysML v2 should be free to choose the v2 elements, notation, libraries, and analysis behavior that best express its meaning. Those choices belong in an open standards process.

This proposal has a narrower job. It asks whether the 17 official RAAML 1.1 definition files, consisting of nine profiles and eight libraries, can pass through SysML v2 while retaining a written, testable list of v1 facts. Here, “official” means that the file is part of the machine-readable material published by the OMG.

Those facts include:

• stereotype names, inheritance, whether a stereotype is abstract, the kinds of UML elements it extends, and its extension ends;
• stereotype properties, types, multiplicities, defaults, subset/redefinition links, comments, and icons;
• OCL bodies and their owning and constrained elements;
• library classes, enumerations, AssociationClasses, and plain associations;
• Ports, connectors, connector ends, imports, profile applications, and namespace metadata;
• stereotype applications that occur inside the official library files.

The proposal does not cover RAAML models created by users. At signed candidate tag v0.9.0-rc.3, the Python reference implementation and native TypeScript implementation passed the defined round-trip test for all 17 official files with zero differences in the specified fact set. That is a result within a deliberately narrow boundary, not proof that arbitrary RAAML models can be converted safely.

A direct rewrite would lose information needed for the return to SysML v1

Many RAAML definitions do not have one obvious v2 replacement.

For example, the STPA ControlAction stereotype can be applied to three different kinds of UML element: Signal, Class, and DataType. In this proposal it remains one metadata definition. The preservation record must keep all three permitted UML bases and their extension relationships so that the reverse mapper can rebuild the source definition.

FTA adds a different problem. Concrete gate and event stereotypes inherit their base_* properties rather than declaring them again. Adding those bases to every subtype during reconstruction would create declarations that are not present in the official profile.

Other details look unimportant until the tool tries to rebuild the v1 definition:

• an ExtensionEnd name that differs from the stereotype name;
• an older UML URI used by one declaration;
• SVG icon data and locations;
• a UML AssociationClass that must remain distinguishable from a plain association;
• 65 library Ports and 94 owned connectors;
• two distinct OCL constraints in CoreRAAML that share the name ClientIsSituation but have different owners.

The v2 representation therefore needs two parts: a useful v2 element and a record of the v1 details that element cannot express by itself.

The translator stores what SysML v2 cannot express directly

Each official RAAML stereotype becomes a SysML v2 metadata definition. The metadata records the v1 facts that the chosen v2 form does not express clearly enough on its own.

Conceptually:

RAAML 1.1 stereotype
    ↓
SysML v2 metadata definition
    + original base-metaclass set
    + original generalizations
    + properties and multiplicities
    + extension-end identities
    + icon and OCL references
    + other preservation fields

Information that belongs to the whole source file, including its profile name, URI, comments, imports, profile applications, namespace values, and OCL records, is stored once in a JSON manifest beside the v2 model. It is not copied onto every definition.

The generated full-corpus SysML v2 text is accepted by the mandatory pinned SysML v2 implementation with zero errors in all five validation categories. The reverse mapper also reconstructed all 17 v1 files with zero canonical fact differences. After the candidate was signed, Sensmetry Syside Editor 0.10.3 also reported no problems for the exact generated text in a manual maintainer-operated check. No outside team has yet reproduced the result.

The translated elements remain usable in SysML v2

The proposal separates stereotype definitions from library elements.

Every RAAML stereotype becomes a SysML v2 MetadataDefinition. The kinds of UML element it may annotate remain part of the preserved source facts; they do not turn the stereotype itself into an item, part, or occurrence definition. A tool may derive domain-oriented views, but those views are not the authoritative preservation carrier.

Library elements use the native structural form selected by the source:

The native carrier makes the element usable in v2. The preservation record lets the tool rebuild and test the original v1 facts.

Original safety constraints stay intact until equivalent SysML v2 checks can be proven

The official RAAML profiles contain OCL constraints that inspect UML-specific features such as base_* properties and all instances of a type. A SysML v2 constraint def does not automatically perform the same check.

Version 0.1 therefore preserves:

• the original OCL text and language/body representation;
• its owner and constrained elements;
• comments and an owner-qualified identity;
• names referenced by the expression, extracted and resolved by a pinned OCL 2.4 parser.

Parsing and name resolution are required; evaluating the constraint is outside the version 0.1 conformance claim. A v2 constraint may later be generated as an additional view. It cannot replace the original OCL until tests show that both constraints mean and do the same thing.

Round-trip tests check that no listed safety fact changes

The rebuilt XMI does not need the source file's spacing, XML element order, or MagicDraw-assigned IDs. It must contain the same facts listed by the proposal.

The test is:

official RAAML XMI
    ↓ extract facts
standard source fact list
    ↓ forward map
SysML v2 definitions + preservation manifests
    ↓ reverse map
reconstructed RAAML XMI
    ↓ extract facts
standard reconstructed fact list
    ↓ compare
no listed fact is missing, added, unresolved, or changed

The signed candidate reports:

Stable generated IDs make links repeatable, but stable IDs do not make the surrounding XML byte-for-byte identical. The validation report records the current evidence and identifies the exact signed commit, containers, CI runs, and verification command.

Preserving safety links supports the wider digital-engineering transition

The proposal is intentionally narrow, but the underlying problem is broader.

CASCaRA is working on a common way to connect engineering information held in different specialized tools. Digital-certification initiatives such as EUROCAE WG-136 are examining how people can navigate regulations, evidence, and certification work electronically. RAAML provides typed links between safety analyses and the system being analyzed.

Our proposal does not solve these larger problems. But it provides one small, necessary foundation: a tested way to carry RAAML's official safety concepts into SysML v2. This gives tools and teams a basis for moving system models forward without leaving their safety reasoning behind.

Our approach can support:

• tool vendors experimenting with RAAML-aware SysML v2 workflows;
• standards contributors checking migration choices against the existing official files;
• engineering organizations that cannot switch every tool and partner simultaneously;
• future regulator or assurance views that must show where a fact came from and which element it refers to.

References

• Object Management Group, Risk Analysis and Assessment Modeling Language 1.1, December 2025.
• Object Management Group, Systems Modeling Language 2.0, September 2025.
• Object Management Group, Kernel Modeling Language 1.0, September 2025.
• Object Management Group, Object Constraint Language 2.4, February 2014.
• GfSE and project partners, CASCaRA.
• EUROCAE, WG-136: Digital Regulations and Certification Framework.
• Source repository and signed candidate, RAAML SysML v2 preservation.
• Reference implementations, validation report for v0.9.0-rc.3.