Inheritance of Safety & Security Level (SSL) in SOX

Owned by Klaus-Dieter Schulz (Unlicensed)
Last updated: Aug 14, 2023 by Klaus Finsterbusch
4 min read

Concepts / Method

SOX integrates a Calculator to compute the inheritance logic and its outcomes. By default, inheritance is enabled for system elements, requirements, safety goals, functions and malfunctions, as modeled in the context of functions diagrams. There, computed safety levels appear as italicized decorators (feature in SOX 3.3.10 and better). A bold-type decorator indicates a static safety level. The latter scenario refers a) to safety goals; b) to manually overwritten safety levels.

The preset situation is different for actions and parts modeled by activity diagrams and internal block diagrams, respectively. Their default setting is “Not Relevant”, i.e., blocking inheritance. The reason is that in most cases the safety and security level (SSL) is propagated via relations between system elements, functions, malfunctions and requirements. In some cases a manual defined inheritance between parts and actions might be needed.

Overriding Safety Levels

We shall demonstrate the method using the following two elements, where the Requirement inherits safety level ASIL C from the Safety Goal initially:

The option to overwrite a computed safety level is available in most any scenario. To do so:

  1. Right-click an element.

  2. From the cascading context menu, select Override Safety Level. - Outcome: the menu will offer a variety of applicable safety norms.

  3. Select the desired norm (our example uses ASIL A). - Outcome: the decorator will update itself accordingly (replacing the previously computed ASIL C with ASIL A) , and the updated element may propagate its safety level, depending on your overall configuration.

Using the “Override Safety Level” Menu

As demonstrated before, the menu’s first level lists the applicable norms, as well as a “Not Relevant” entry. If a certain norm was previously selected, overwriting the computed value, your choice will also be evident here. In this example the propagated ASIL is overwritten by “ASIL C”:

The second level offers a choice of standards for a given norm, as well as another “Not Relevant” entry, termed ASIL NR. If overwriting was enabled previously, you may revoke this choice here (“Remove Override”).

The first-level “Not Relevant” entry is a marker as to whether a node may have, and propagate, any safety level. I.e., if the safety level is declared to be “Not Relevant”, any safety level definition passed down to this node will not propagate. Choice of this blocker will be signalized by a check mark. By contrast, the second-level “Not Relevant” item names a dedicated safety level, or absence thereof, relevant to certain norm, such as ISO 26262-ASIL. Hence, the “blocking” in terms of inheritance will only become effective for this norm.

 

Propagation between parts and actions

As noted previously, the default behavior is different for connecting entities like ports and pins in internal block diagrams and activity diagrams, respectively. To enable inheritance, you will first need to remove the preset “Not Relevant”:

“Before” situation

“After” situation

 

Example Scenarios

Block Definition And SOX Concept Diagrams

We provide in the following a listing of all model elements and connection types that cause SSL inheritance.

In the diagrams reproduced below, the inheritance “flow” is always left to right, i.e. the element on the right-hand side inherits (receives) what the element shown on the left-hand side propagates (“hands down” to be inherited).

  • System Element / Block inherits from Function via Allocate:

 

  • Lower-level function inherits from higher-level function via Composite Association or Part Association:

 

  • Function inherits from Malfunction via Composite & Part Association:

 

  • System Element inherits from Requirement via Satisfy:

 

  • Function inherits from Requirement via Satisfy:

 

  • Malfunction inherits from Malfunction via Effects (i.e., the inheritance path runs counter to the causation path):

 

  • Requirement inherits from Requirement via Satisfy:

 

  • Requirement inherits from Requirement via DeriveReqt:

 

  • Malfunction inherits from Safety Goal via DeriveReqt:

 

  • Malfunction inherits from Requirement via DeriveReqt:

 

  • Lower-level Requirement inherits from higher-level Requirement via Containment Link: