Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
IEC 62741:2015 – Demonstration of Dependability Requirements – The Dependability Case
💡 Key Insight: A dependability case is not just a documentation exercise — it is a strategic tool that progressively reduces uncertainty about whether a system will meet its reliability, availability, maintainability, and supportability requirements.
1. Scope and Purpose
IEC 62741 provides guidance on the content and application of a dependability case and establishes general principles for its preparation. The standard addresses a basic project context where a customer orders a system that meets dependability requirements from a supplier, but the methods can be modified and adapted to other situations. The dependability case serves as the main means of communication on dependability among customers, suppliers, and other stakeholders, promoting cooperation throughout the system life cycle.
Dependability, as defined in this standard, encompasses reliability, availability, maintainability, and supportability (RAMS), as well as other attributes such as usability, testability, and durability. The case includes all aspects of the system — components, processes, hardware, software, and their interfaces.
✅ Business Value: A well-structured dependability case can reduce overall project costs by identifying unnecessary activities, preventing miscommunication, avoiding rework from late-discovered faults, and focusing resources on evidence that genuinely supports dependability claims.
2. Principles of the Dependability Case
2.1 Structure and Claims
The dependability case starts with an initial statement of dependability requirements, which may include customer specifications, internal goals, market strategies, and regulatory requirements. It then makes a top-level claim explicitly stating that the system meets these requirements. This top-level claim is decomposed into a multi-level structure of sub-claims and connecting sub-arguments, ultimately based on evidence and assumptions. Arguments fall into two categories: those that demonstrate all identified risks are eliminated or sufficiently treated, and those that provide sufficient grounds for the claim.
2.2 Evidence Framework
Evidence in the dependability case can be direct (demonstrating that requirements have been met) or indirect (showing that risk treatment activities were successful). The standard emphasizes using a wide range of evidence sources:
| Evidence Source | Application Stage | Example |
|---|---|---|
| Performance in previous usage | All stages | Field failure data from similar systems |
| Design calculations | Design/realization | MTBF predictions, stress analysis |
| Testing/trials data | Realization | Accelerated life test results |
| Simulation results | Design/realization | Monte Carlo reliability simulation |
| Analysis results | All stages | FMECA, FTA, RBD analysis |
| Expert opinion | Concept/design | Domain expert assessment |
| Management processes | All stages | ISO 9001 audit results |
| Operational/maintenance data | Utilization | Mean time to repair records |
2.3 Progressive Assurance
A key concept is progressive assurance — the dependability case provides an expanding body of evidence that progressively decreases uncertainty around the achievement of dependability requirements. Uncertainty is highest at the concept stage and decreases as evidence accumulates through design, realization, and utilization. However, the standard realistically acknowledges that uncertainty may increase during re-design, technology insertion, or when new evidence conflicts with existing evidence.
⚠️ Engineering Note: The progressive assurance model clearly distinguishes between new development (high initial uncertainty, gradual reduction) and modified off-the-shelf (MOTS) solutions (lower initial uncertainty, but requiring careful re-assessment for new applications or environments).
3. Dependability Case Report and Lifecycle Integration
3.1 Report Content
The dependability case report should include: an introduction describing the system and scope, the system context and stakeholder expectations, dependability requirements with acceptance criteria, the argument structure showing how claims are supported by evidence, a summary of evidence, conclusions on whether requirements are met, and recommendations for future activities. The report must be maintained and updated throughout the system life cycle, with particular attention to changes in requirements, environment, design, or actual performance.
3.2 Relationship with Dependability Planning
The dependability case and dependability plan are complementary. The plan defines activities, techniques, and resources to achieve dependability; the case demonstrates that these activities achieve the requirements and treat the risks. Preparing the case assists development of a cost-effective plan because evidence sought for the case can suggest which activities are truly necessary. Conversely, if an activity in the plan does not support any argument in the case, its usefulness should be reviewed.
| Life Cycle Stage | Dependability Case Focus | Key Activities |
|---|---|---|
| Concept | Define requirements, identify risks | Initial claims, evidence framework design |
| Development | Build argument, collect evidence | Analysis, simulation, design reviews |
| Realization | Verify and validate | Testing, qualification, demonstration |
| Utilization | Monitor and update | Field data collection, continuous improvement |
| Retirement | Capture lessons learned | Final assessment, knowledge preservation |
4. Engineering Design Insights
💡 Practical Takeaways for Engineers:
- Start early, iterate often: The dependability case should be initiated at the concept stage, not as an afterthought before delivery. Early identification of critical evidence needs prevents last-minute surprises.
- Claims must be testable: Each claim in the argument hierarchy should be formulated so that it can be objectively verified through evidence. Vague claims like “the system is reliable” should be replaced with specific, quantified statements.
- Assumptions are liabilities: All assumptions must be explicitly stated and plans made to validate them. An unvalidated assumption is a risk to the dependability argument.
- COTS/MOTS reuse requires caution: Prior operational history does not automatically transfer to new environments or applications. A careful re-assessment is required for each new deployment context.
- Cost-benefit alignment: The dependability case is most valuable for high-value, low-quantity systems where direct evidence is expensive to obtain. For simpler systems, a lightweight case may suffice.
5. Frequently Asked Questions
Q1: How does a dependability case differ from a safety case?
A dependability case covers all aspects of dependability (reliability, availability, maintainability, supportability), while a safety case focuses specifically on safety risks and hazards. The two are complementary — a dependability case may reference safety-related evidence, but safety cases have their own regulatory and standards frameworks (e.g., IEC 61508, ISO 26262).
Q2: Who is responsible for creating and maintaining the dependability case?
Typically, the dependability case is produced jointly by the customer and supplier. The customer defines requirements and context; the supplier provides evidence from design, testing, and operational data. Certification bodies and regulators may examine the case to support their decisions. End users may update the case if they use the system for different purposes.
Q3: Can a dependability case be applied to software-only systems?
Yes. The standard covers all aspects of a system including software. Software dependability evidence can come from formal verification, testing coverage analysis, fault injection testing, operational profile testing, and reliability growth modeling. The same claim-evidence-argument structure applies.
Q4: What happens when new evidence contradicts the existing dependability case?
The standard acknowledges this situation — uncertainty may increase rather than decrease when conflicting evidence emerges. The dependability case should be reviewed and revised, with the conflicting evidence analyzed to determine its impact on claims. This might necessitate additional evidence collection, design changes, or revised requirements.
