Skip to content

Validation

Formal validation for achieved integrity levels is often performed through processes mapped to applicable domain standards.

The purposes of Safety Integrity Levels (SILs, as defined in IEC 61508), as well as other abstraction labels that express integrity or assurance levels in these standards, include:

  • Expressing integrity levels and expected risk reduction from components, subsystems, or systems
  • Highlighting differences in required integrity at interfaces (with freedom from interference claims) in mixed-criticality systems

To optimise high-integrity systems, mixed criticality uses abstraction labels for components, subsystems, and processes (through requirements) to guide partitioning (architectural design), selection, and prioritisation. Yet, as noted in "Engineering a safer world: Systems thinking applied to safety" by Nancy G. Leveson, unintended emergent properties still arise at the system level despite the use of high-integrity components. Emergent behaviour in complex, evolving systems requires a holistic systems engineering approach, such as that provided by the TSF.

Trustable does not require SILs to be assigned during design, architecture, or requirements stages. Instead, the project defines which levels have been achieved at the system level based on project-specific claims and evidence, continuously presented through the TSF graph (including for certification). TSF guidance is thus agnostic to traditional integrity requirements expressed in domain-specific classification schemes (e.g., SIL, ASIL, DAL, Class, EAL), leaving assignment of such levels to systems (and subsystems) applying TSF.

The Trustable Tenets (TTs) are designed to be pragmatic and to avoid prescribed breakdowns, keeping them independent of any specific process (specifying the What, not the How). This document therefore applies an abstraction-level structure covering aspects often tied to integrity-level assignments, aligning them with the TTs. The TSF, in turn, allows projects to define alternative approaches consistent with the TTs. An initial in-context review ensures the completeness and applicability of the TTs:

  • System-level integrity (TT-EXPECTATIONS, TT-RESULTS)
  • Module-level integrity (TT-PROVENANCE)
  • Process-level integrity (TT-CONSTRUCTION, TT-CHANGES, TT-CONFIDENCE)

System-level integrity

Top-level product claims must be tracked as Statements (Expectations, Assertions, Evidence). Expectations require supporting Evidence (e.g., test and analysis results) with reviewed confidence measures.

For instance, in safety-related systems, RAFIA guidance describes the structure of analysis and testing required to justify these claims. The RAFIA verification-driven workflow ensures safety-analysis-led traceability, linking STPA-driven analysis of features, mitigations, and their decomposition to design specifications and test results (primarily under TT-EXPECTATIONS). This workflow applies equally to bespoke elements and to managed selections of pre-existing elements. Results are reviewed against the analysis to establish failure rates for both system functions and interacting subsystems, using statistical methods such as FTA (primarily under TT-RESULTS).

Any failure to achieve the required failure rates is exposed and triggers further RAFIA processes until integrity targets are met, driving continuous improvement.

Module-level integrity

At the module level, TSF analyses inputs (components, tools, data) to identify risks, treating all inputs as untrustworthy by default (prevalent for TT-PROVENANCE). Module-level assessments, alongside system-level testing and analysis results, are linked to system-level objectives to address all critical misbehaviour mitigations with appropriate confidence measurements.

If a low score remains, the project may increase analysis or apply remedial measures to meet objectives. Possible actions include:

  • Strengthening weak parts of the system
  • Replacing components with higher-scoring alternatives
  • Increasing redundancy
  • Enhancing diagnostics
  • Redesigning the system

Note, a module or subsystem may map its claims to TSF for reuse, but downstream projects must decide how to consume externally managed Statements. Reusing upstream scores as-is is invalid, as they require contextualisation through additional reasoning, data, and reviews.

Process-level integrity

At the process level in TSF, Evidence is mapped to objectives, which address not only system behaviours, but also robustness (primarily covered by TT-CONSTRUCTION, TT-CHANGES, TT-CONFIDENCE). Confidence measurements at this level are applied consistently across projects to ensure transparency, confirming that system- and module-level Statements are supported by appropriate (in-context) Evidence.

The TSF graph combines these measurements into confidence scores that show overall integrity across the system, processes, and data, while highlighting gaps. Scores and their prioritisation are refined using project-specific context (e.g., links to losses in STPA), weightings, and evidence from both development and production.

In conclusion, component or subsystem SILs are not directly applied within Trustable processes. The focus is on concrete system features, with design considerations and gaps documented transparently, regardless of prior subsystem claims. The system's performance level can then be derived from presented Evidence.