Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
IEC 62628: Guidance on Software Aspects of Dependability
IEC 62628:2012 provides comprehensive guidance on managing dependability aspects throughout the software life cycle. It addresses reliability, availability, maintainability, and integrity (RAMI) for software-intensive systems, bridging the gap between traditional hardware reliability engineering and software quality management practices.
Core Purpose: Establish a unified framework for software dependability that integrates with system-level dependability programmes across industries such as industrial automation, transportation, energy, and medical systems.
1. Software Dependability Framework
The standard defines dependability as the collective term describing the availability performance and its influencing factors: reliability performance, maintainability performance, and maintenance support performance. For software specifically, integrity — the property of preventing unauthorized access or modification — is added as a critical attribute.
| Dependability Attribute | Software-Specific Definition | Key Metrics |
|---|---|---|
| Reliability | Probability of failure-free operation for a given time under stated conditions | MTTF, failure intensity, reliability growth |
| Availability | Probability that software is operational and accessible when required | Availability ratio, downtime percentage |
| Maintainability | Ease with which software can be modified to correct faults or improve performance | Mean time to repair (MTTR), change impact |
| Integrity | Prevention of improper modification or destruction of software and data | Security incident rate, data corruption rate |
2. Dependability Engineering Process
2.1 Life Cycle Integration
The standard recommends embedding dependability activities into each phase of the software life cycle, from concept through retirement. Key activities include:
- Requirements phase: Establish dependability objectives, identify critical failure modes
- Design phase: Apply fault avoidance, fault tolerance, and fault removal techniques
- Implementation phase: Coding standards, static analysis, peer reviews
- Testing phase: Reliability growth testing, stress testing, fault injection
- Operations phase: Failure data collection, root cause analysis, corrective action
Best Practice: Early investment in dependability activities during requirements and design phases yields 5-10x cost savings compared to addressing faults during testing or operations.
2.2 Fault Classification and Strategy
IEC 62628 classifies software faults into three categories:
- Fault avoidance: Preventing fault introduction through rigorous development processes, formal methods, and verified toolchains
- Fault control: Detecting and removing faults through inspection, analysis, and testing
- Fault tolerance: Designing software to maintain functionality despite the presence of faults
3. Dependability Assessment and Improvement
3.1 Assessment Methods
The standard describes several complementary assessment approaches:
- Software reliability growth models: Using failure data to predict future reliability (e.g., Goel-Okumoto, Musa-Okumoto models)
- Operational profile testing: Structuring tests based on expected usage patterns to estimate field reliability
- Fault injection: Deliberately introducing faults to evaluate fault tolerance mechanisms
- Dependability case: Structured argument linking evidence to dependability claims
3.2 Improvement Techniques
| Technique | Description | Dependability Impact |
|---|---|---|
| Complexity simplification | Reducing module size, eliminating dead code | Reduces fault density by 30-50% |
| N-version programming | Independent implementations of same specification | Masks design faults |
| Recovery blocks | Alternate routines on failure detection | Improves availability |
| Structured documentation | Traceable requirements-to-code mapping | Enables maintainability |
Engineering Insight: Software complexity is the single largest contributor to dependability risk. IEC 62628 strongly emphasizes complexity reduction as a primary fault avoidance strategy — far more effective than any testing-based approach.
Engineering Design Insights
- Operational profiles are essential — without understanding how software is actually used, dependability testing is statistically meaningless
- Track both defect density and failure intensity — they measure different things; low defect density does not guarantee high reliability if defects cluster in frequently executed paths
- Hardware-software interaction matters — many system failures arise from the boundary between software and hardware, particularly in timing and resource contention
- Dependability data feedback loops — field failure data should systematically feed back into design and testing processes to close the dependability improvement cycle
- Tailor rigour to criticality — not all software needs the same level of dependability; a risk-based approach using the standard’s tailoring guidelines optimizes cost vs. assurance
FAQs
Q: How does IEC 62628 relate to IEC 61508 (functional safety)?
A: While IEC 61508 focuses on safety-related systems, IEC 62628 covers broader dependability attributes (reliability, availability, maintainability, integrity) for all software-intensive systems. The two standards complement each other — safety is a subset of dependability.
Q: What is the difference between software reliability and hardware reliability?
A: Hardware reliability typically follows a bathtub curve with wear-out failures, while software reliability improves over time as faults are detected and removed. Software does not wear out — its failures are design faults that exist from the beginning.
Q: Can agile development be compatible with IEC 62628 dependability requirements?
A: Yes. The standard is life-cycle-neutral. Agile teams can implement dependability activities within sprints — e.g., continuous integration for fault detection, automated regression testing for reliability assurance, and retrospectives for process improvement.
