Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
IEC 61713: Software Dependability Through the Life Cycle
Tip: IEC 61713 provides a comprehensive framework for managing software dependability across the entire system life cycle, from concept through development, operation, and decommissioning. It bridges the gap between general dependability concepts (IEC 60300 series) and software-specific engineering practices.
1. Scope and Dependability Framework
IEC 61713 addresses the critical challenge of achieving dependable software in systems where software failure could have safety, economic, or environmental consequences. The standard applies to all types of software-based systems, including embedded software in industrial control systems, safety-critical applications in transportation and medical devices, enterprise information systems, and infrastructure management platforms. Rather than prescribing a single methodology, IEC 61713 provides a framework of dependability principles and practices that can be tailored to the specific criticality level, development context, and organisational capability of each project.
The standard defines dependability as a composite property encompassing four key attributes: availability (readiness for correct service), reliability (continuity of correct service), safety (absence of catastrophic consequences), and maintainability (ability to undergo modifications and repairs). For software specifically, IEC 61713 extends this to include integrity (absence of improper system alterations) and, where relevant, security (protection against intentional faults). This holistic view recognises that dependability cannot be achieved by focusing on reliability alone — a highly reliable system that is insecure or unsafe is not truly dependable.
Warning: A common misconception addressed by IEC 61713 is that software dependability can be “tested in” at the end of development. The standard emphasises that dependability must be designed in from the earliest concept phase, with each life cycle stage contributing specific dependability activities and producing verifiable dependability evidence.
The standard structures the dependability life cycle into six primary phases: concept and definition, requirements specification, design and development, integration and testing, installation and operation, and decommissioning. For each phase, IEC 61713 specifies the dependability objectives, required inputs, recommended activities, and expected outputs. This phase-by-phase approach enables project managers and quality assurance teams to integrate dependability activities into existing development processes, whether using waterfall, iterative, or agile methodologies.
2. Dependability Techniques and Their Life Cycle Application
IEC 61713 organises dependability techniques into four fundamental strategies: fault prevention, fault tolerance, fault removal, and fault forecasting. These four strategies are applied throughout the software life cycle, with different emphasis at different stages.
| Strategy | Life Cycle Focus | Key Techniques | Measurable Outcome |
|---|---|---|---|
| Fault Prevention | Concept through Design | Structured methods, formal specification, design reviews, coding standards, configuration management | Reduced fault density at unit level |
| Fault Tolerance | Architecture through Implementation | Redundancy (N-version, recovery blocks), exception handling, watchdogs, graceful degradation | Continued service despite faults |
| Fault Removal | Integration through Maintenance | Static analysis, dynamic testing, formal verification, code inspections, regression testing | Fault detection and correction rate |
| Fault Forecasting | Testing through Operation | Reliability growth models (per IEC 61710), fault density estimation, operational profile testing | Remaining fault prediction, MTTF/S estimations |
Fault prevention receives the greatest emphasis in the early life cycle phases. The standard highlights that the cost of preventing a requirements fault during the concept phase is typically 10 to 100 times less than correcting the same fault during operation. Key prevention techniques include formal methods for requirements specification, systematic design reviews using checklists derived from historical failure data, and the use of coding standards such as MISRA C/C++ for safety-critical embedded software. Configuration management and rigorous change control are identified as essential prevention mechanisms that continue throughout the life cycle.
Best Practice: For safety-critical software projects, IEC 61713 recommends combining independent fault prevention techniques. For example, using formal specification (Z or B-method) alongside structured design reviews has been shown to detect over 85% of requirements defects before any code is written, compared to approximately 40-50% for either technique alone.
Fault tolerance addresses the reality that despite the best prevention and removal efforts, residual faults will remain in deployed software. The standard describes several architectural patterns for fault tolerance. N-version programming (independent implementation of the same specification by different teams) provides tolerance against design faults, while recovery block techniques (acceptance test with alternate routine) are more suitable for algorithmic faults. For real-time control systems, watchdog timers and exception handling frameworks are mandatory minimal fault tolerance mechanisms. The standard notes that fault tolerance techniques should be validated through fault injection testing, where known faults are deliberately introduced to verify that tolerance mechanisms behave as expected.
3. Engineering Design Insights for Dependable Software
A key engineering insight from IEC 61713 is the concept of dependability case — a documented body of evidence that provides a convincing and valid argument that a system is dependable for a given application in a given environment. The dependability case is analogous to the safety case required by standards such as IEC 61508 and DO-178C, but covers all dependability attributes, not just safety. The standard recommends that the dependability case be developed incrementally throughout the life cycle, starting with the dependability strategy in the concept phase and maturing through evidence collection in subsequent phases.
The standard provides detailed guidance on selecting dependability techniques based on the criticality level of the software. Four criticality levels are defined, ranging from Level 1 (minor economic or convenience consequences of failure) to Level 4 (catastrophic safety or environmental consequences). Each level requires a progressively more rigorous set of dependability activities and evidence. This risk-based approach allows organisations to allocate dependability engineering resources proportionally, avoiding both under-engineering of critical functions and over-engineering of non-critical functions.
| Criticality Level | Consequence of Failure | Minimum Dependability Requirements |
|---|---|---|
| Level 1 | Minor inconvenience, no safety impact | Coding standards, unit testing, basic configuration management |
| Level 2 | Moderate economic loss, minor injury possible | Level 1 + design reviews, integration testing, fault forecasting |
| Level 3 | Major economic loss, potential serious injury | Level 2 + formal specification, independent V&V, fault tolerance |
| Level 4 | Catastrophic, loss of life, severe environmental damage | Level 3 + formal verification, diverse redundancy, independent safety case |
Critical: IEC 61713 warns against the “dependability plateau” effect — after a certain point, increasing testing effort yields diminishing returns in fault detection. The standard recommends using fault forecasting (reliability growth models) during system testing to estimate remaining fault density objectively. When the fault detection rate approaches the plateau, effort should shift from fault removal to fault tolerance and operational monitoring.
For engineers implementing IEC 61713 in practice, the standard emphasises the importance of the operational profile — a quantitative characterisation of how the system will be used in its intended environment. The operational profile drives test case selection for reliability testing, informs the allocation of fault tolerance mechanisms to critical functions, and provides the context for interpreting dependability metrics. Without a representative operational profile, reliability growth models may produce optimistic projections that do not reflect field experience. The standard recommends updating the operational profile throughout the life cycle as more usage data becomes available from early deployment and beta testing phases.
Integration with existing software engineering standards is another strength of IEC 61713. The standard provides mapping guidance to ISO/IEC 12207 (software life cycle processes), IEC 61508 (functional safety), ISO 26262 (automotive safety), and IEC 62304 (medical device software). For projects operating under multiple standards, IEC 61713 can serve as the overarching dependability framework, with domain-specific standards addressing specialised safety and regulatory requirements. This harmonisation approach reduces duplication of effort and ensures consistent dependability management across the entire system life cycle.
Frequently Asked Questions
Q1: Is IEC 61713 applicable to agile software development projects?
Yes. IEC 61713 is methodology-neutral and can be adapted to agile approaches. The key is to map the dependability activities defined by the standard to agile ceremonies and artefacts. For example, fault prevention activities align with sprint planning and definition of done; fault removal maps to continuous integration testing and sprint reviews; and the dependability case can be maintained as a living document updated each sprint. The standard explicitly acknowledges that iterative development can be compatible with rigorous dependability management.
Q2: How does IEC 61713 relate to IEC 61508 (functional safety)?
IEC 61713 and IEC 61508 are complementary. IEC 61508 focuses specifically on functional safety (the absence of unacceptable risk due to hazards caused by malfunctioning behaviour), while IEC 61713 addresses the broader dependability attributes including reliability, availability, and maintainability. In practice, a project compliant with IEC 61508 for safety functions will have already addressed many of the IEC 61713 requirements for those functions. IEC 61713 fills the gaps for non-safety-related dependability aspects and provides a unified framework.
Q3: What metrics should be tracked to demonstrate software dependability?
IEC 61713 recommends a balanced set of metrics: fault density (faults per thousand lines of code during development), defect detection effectiveness (percentage of faults found before release), mean time to restore service (maintainability), operational failure intensity (reliability), and requirement stability (process quality). No single metric is sufficient — the standard emphasises that dependability must be assessed through multiple complementary measures tracked over time.
Q4: Can open-source software components be used in systems requiring IEC 61713 compliance?
Yes, but with additional qualification activities. IEC 61713 requires that all software components, regardless of origin, undergo dependability assessment commensurate with their criticality. For open-source components, this typically means: verifying the component’s development process against the standard’s requirements, performing independent vulnerability assessment, and establishing a monitoring process for newly discovered faults in the open-source community. The standard provides specific guidance on assessing “software of unknown pedigree” (SOUP).
