SOX Concepts in Detail
- Tino Pförtner
In SOX, the same objects can be used in multiple modules and documents. For instance, a system
element "A" can be defined in the System Design module and can then be used in multiple safety
analyses, e.g., multiple FMEA documents FMEA1 and FMEA2. There are no copies of "A": All
documents (System Design, FMEA1, FMEA2) refer to the same object. This means that modifying the
object A within one of these documents automatically results in a modification of all other documents
that contain the same element.
The system design contains all objects to be reused within multiple modules. Those reusable objects
are represented by SOX-specific SysML stereotypes in the system design. (A stereotype represents a
custom variation of a standard SysML/UML element – for instance, the stereotype System Element represents a specific SysML block that is interpreted in SOX as a system element.) The supported reusable objects (represented by stereotypes) are: system element, function (including subtypes such as safety functions, diagnoses and process characteristics), malfunction, requirement, and safety goal.
An exception is project tasks which can also be used in multiple documents but are independent from
the system design and are managed in the “project task” view.
Whenever a new instance of one of these objects is created (e.g. a new system element in an FMEA)
it is automatically added to the system design. All existing system design elements are listed in the
Model Explorer view (see below) and can be reused from there, e.g., by dragging and dropping them
into other documents.
Alternatively, it is possible to open one or more Object List views (see below) to show lists of all
existing elements of a specific type.
The system design always contains all existing reusable objects (listed in the Model Explorer). But a
specific document (e.g., FMEA, FMEDA, FTA document) or diagram (e.g., SysML Block Definition
Diagram) contains only a subset of them. For instance, an FMEA document displays only those system
elements that are relevant in the context of this specific document. Different documents (e.g., FMEAs)
can contain different subsets of elements. As a consequence, creating a new object within an FMEA
document automatically adds this object to the system design, but creating a new object within the
system design does not automatically affect other documents/diagrams (as those contain only subsets).
Analogously, deleting an object in the system design deletes the object also in all other documents/
diagrams, but deleting an object within a document/diagram does not automatically result in deletion
from the system design. SOX provides a refactoring dialog (see below) which prompts information
about the consequences of object deletion whenever an object is referred to by other documents.
An exception is requirement documents (RM documents), as there should never be a requirement
that exists only in the system design but is not contained in a RM document. Hence, the relationship
between requirements in the system design and requirements in RM documents is 1:1, i.e., adding/
deleting a requirement on one side automatically results in addition/deletion on the other side. (By
default, Requirements created in a RM document are added in the system design into a package with
the same name as the RM document, but they can be freely moved within the system design without
effects on the RM documents.) This means that imported requirements (e.g., using ReqIF import)
become directly available in the system design, e.g., to link them with system design elements.
The following table lists the types of objects that can be used over multiple documents/diagrams
(leftmost column) and their representation within a specific document (other columns):
The main relationships between elements are stored in the system design as well and, hence, kept
consistent across all documents: Containment between system elements, assignment of functions to
system elements, assignment of malfunction to functions, assignment of safety goals to functions.
Again, adding such a relationship in one document automatically creates a corresponding relationship
in the system design (but not vice versa) and deleting such a relationship in the system design can
result in appearance of a “Refactoring” dialog that informs the user about the consequences.
The following table lists the relationships that are relevant in multiple types of documents/diagrams
and their meaning within a certain document/diagram type: