MTTFd, DCavg and CCF Explained: Evidence for ISO 13849
MTTFd estimates dangerous-failure reliability, DCavg measures how effectively relevant dangerous faults are detected, and CCF tests whether one shared cause can defeat multiple channels. All three support an ISO 13849 Performance Level assessment, but none proves the safety of a component, circuit or machine by itself.
What do MTTFd, DCavg and CCF each measure?
Do not choose the largest number and stop. Begin with the hazard and required PLr, define the complete safety function, then use each parameter for the question it actually answers.
Will a dangerous failure occur over time?
Mean time to dangerous failure describes the dangerous-failure reliability contribution of a channel or element under stated conditions. It is not warranty life, MTBF or a replacement date.
Will the diagnostics detect relevant dangerous faults?
Average diagnostic coverage reflects the effectiveness of the selected fault-detection measures. It is not controller uptime and it is not normally a simple average of device percentages.
Could one shared cause defeat redundant channels?
Common-cause failure analysis examines shared wiring, power, environment, design, configuration and maintenance influences. Two channels on a drawing are not automatically independent.
| Current condition | Recommended action | Evidence required | Stop boundary |
|---|---|---|---|
| B10d is available but annual operations are unknown | Define what counts as one operation, then calculate or measure the real yearly demand. | Production calendar, cycle rate, operations per cycle, test operations and product conditions. | Do not calculate application MTTFd from a guessed duty cycle. |
| A device advertises high diagnostic coverage | Map each claimed diagnostic to the dangerous fault it detects, its detection time and its fault reaction. | Safety manual, diagnostic boundary, timing, wiring and validation test. | Do not transfer a device percentage directly to subsystem DCavg. |
| The schematic shows two channels | Inspect shared routes, supply, environment, configuration and maintenance exposure. | CCF checklist plus drawings, as-built inspection and lifecycle controls. | Channel count alone is not proof of independence. |
| The calculation achieves the required PL | Compare the model with the built machine and execute the approved validation plan. | SRS, controlled calculation, software and parameter records, inspection and test results. | Do not release a function that differs from its model or fails any acceptance criterion. |
Fast rule: PLr comes from the risk assessment. Achieved PL comes from the complete implemented safety function. Category, MTTFd, DCavg and CCF are important inputs, but software, systematic-failure controls, mission time, fault behavior and validation still matter.
Where do these parameters fit in a complete safety function?
ISO 13849-1:2023 provides a methodology for designing and integrating safety-related parts of control systems in high-demand and continuous operation. It does not decide which safety function or PLr a particular machine needs. That decision begins with risk assessment and any applicable Type C machinery standard.
No single parameter produces the final PL. The calculation model also needs the designated architecture/category and must reflect the real input, logic, output, feedback, connections, power dependencies and safety-related software. ISO 13849-2:2012 addresses validation by analysis and testing of the specified safety functions, achieved category and achieved PL; ISO currently lists a replacement draft under development.
Which reliability and safety terms must engineers keep separate?
Most calculation mistakes begin before a number is entered. The following terms belong to different levels of the safety argument.
| Term | Plain-English meaning | Practical use | Do not confuse it with |
|---|---|---|---|
| PLr | Required Performance Level for the defined safety function. | Sets the required risk reduction before design verification. | A supplier's product claim or the PL already achieved. |
| MTTFd | Mean time to dangerous failure for a channel or element under stated assumptions. | Quantifies dangerous-failure reliability in an ISO 13849 assessment. | MTBF, warranty, replacement interval or total machine life. |
| B10d | Number of cycles at which 10% of a population can be expected to fail dangerously under defined conditions. | Supports application-specific MTTFd calculation for wearing elements. | Ordinary B10 endurance or a value independent of load and duty. |
| nop | Number of relevant operations per year in the actual application. | Connects cycle-based data to real annual use. | PLC scan count, powered hours alone or guessed nameplate speed. |
| DC / DCavg | Coverage of dangerous failures by diagnostics, including the average for the defined subsystem. | Shows whether relevant dangerous faults are detected in time. | Availability, alarm count or an arithmetic average of arbitrary percentages. |
| CCF | Failure of multiple channels from one shared cause. | Tests whether redundant paths resist shared influences. | Any two unrelated failures or proof that redundancy is automatically independent. |
| PFH / PFHd | Average frequency of dangerous failure per hour; terminology varies by standard edition and product data. | Forms part of the probabilistic result for a safety function or subsystem. | MTTFd written in another unit. |
| Mission time | The stated period for which the safety assessment is claimed. | Connects data, service planning and lifecycle controls. | Permission to exceed product limits or ignore wear-related replacement. |
| Fault exclusion | A justified decision that a failure mode need not be considered under defined conditions. | Used only when physical design and evidence support the exclusion. | A convenient way to remove a difficult failure from the model. |
MTTFd is not MTBF. General reliability data can include safe failures, nuisance failures and repair events. MTTFd is narrowed to dangerous failures in the safety context. Good uptime does not prove suitability for a specific safety function.
How is MTTFd obtained from B10d and actual machine use?
For an electronic or non-wearing element, the manufacturer may publish MTTFd, PFH/PFHd or the data needed for the applicable calculation. For a wearing contactor, relay, mechanical switch or valve, B10d is often supplied under specific load and test conditions. That cycle value becomes application-specific only after the real operating demand is known.
A safety function can include several channels and many elements. Evaluate them according to the real architecture instead of averaging attractive values into one unsupported system number. A high MTTFd cannot compensate for an incorrect safe state, missing diagnostics, weak category behavior or a shared failure path.
These simplified relationships are for a wearing element when their assumptions apply. Use the exact manufacturer's operation definition, load conditions, current standard method, relevant limits and mission-time rules.
Siemens' official B10d guidance likewise connects MTTFd to B10d and a realistic operating frequency. That product-family example supports the calculation method; it does not authorize using Siemens data for another component.
This calculator demonstrates the simplified relationship for one fictional wearing element. It does not determine Category, DCavg, CCF, PFH/PFHd, PL or component suitability.
| Input | What to verify | Common error | Consequence |
|---|---|---|---|
| Exact product data | Model code, revision, safety manual, safety data, load, environment and mission-time conditions. | Using a family marketing figure for a different output, contact set or firmware. | The model represents the wrong product or operating mode. |
| B10d or direct MTTFd | Authorized source, dangerous-failure basis and restrictions. | Treating B10 and B10d as interchangeable or inventing B10d from ordinary endurance. | Dangerous-failure reliability is overstated. |
| Actual nop | Schedule, cycle time, operations per cycle, testing and abnormal production cycles. | Using nominal line rate while ignoring short products, multiple starts or 24/7 operation. | Calculated MTTFd looks higher than actual use supports. |
| Load and environment | Voltage, current, inrush, switching class, pressure, temperature, contamination, vibration and EMC. | Assuming published B10d is unchanged under a harder load or environment. | Actual wear and failure mechanisms can differ. |
| Lifecycle controls | Mission time, T10d, service plan, spares control and reassessment triggers. | Calling a large MTTFd result an unlimited service interval. | The safety claim can outlive its evidence. |
What evidence supports a DCavg claim?
A diagnostic feature only contributes when it addresses a relevant dangerous failure within the needed time and leads to the specified fault reaction. LEDs, alarms and controller health messages do not automatically create diagnostic coverage for external sensors, wiring or final energy-control elements.
The second expression shows why DCavg is not normally an arithmetic average. An element that contributes more dangerous failure rate has more weight. Use the current standard or controlled tool method for the defined subsystem.
Map the failure
State the dangerous failure mode: welded contact, channel short, sensor output stuck, feedback mismatch, valve failure or another defined condition.
Map the detection
Identify the test, discrepancy check, OSSD pulse evaluation, cross-monitoring, EDM feedback or functional test that can detect it.
Map timing and response
Confirm when detection occurs, how the system reacts, whether restart is blocked and what evidence proves the installed behavior.
| Diagnostic measure | Can help detect | Does not automatically prove | Verify in the application |
|---|---|---|---|
| Dual-channel discrepancy monitoring | Specified channel sequence, timing and disagreement faults. | Every guard mechanical failure, defeat, shared cable fault or final-output fault. | Expected sequence, time limit, short detection, cable routing and fault state. |
| OSSD or input test pulses | Specified shorts, cross faults or output-line faults when devices are compatible. | Correct physical stopping, safe load switching or compatibility with every input. | Pulse timing, capacitance, wiring, source/sink requirements and diagnostics. |
| EDM / output feedback | A final switching device state inconsistent with the command. | That all stored energy is absent, a brake is holding or all motion has stopped. | Feedback relationship, timing, every relevant final element and fault response. |
| Controller self-test | Internal faults within the certified product's specified scope. | Correct field wiring, sensor mechanics, requirements or external dependencies. | Safety manual, configured blocks, firmware control and diagnostic boundary. |
| Functional test before demand | Some latent faults before the next hazardous operation. | Faults outside the test scope or faults arising after a test. | Test rate versus demand rate, coverage, safe test behavior and records. |
DCavg classes are a result, not a design target by themselves. Current applicable methods commonly group diagnostic coverage as none, low, medium or high. A high class cannot rescue an unsuitable architecture, slow test, incomplete output monitoring or incorrect safe state.
How should common-cause failures be evaluated?
Two guard contacts, two input channels or two contactors may look independent on a schematic while sharing a cable route, connector, supply, enclosure, contaminant, heat source, mechanical mounting, software assumption or maintenance error. One event can then disable both paths.
Common-cause failure analysis is not simply a score entered into software. It is a physical and organizational review of the real machine. Useful measures can include separation, environmental protection, EMC-aware design, suitable component loading, failure analysis, competence, controlled procedures and justified diversity.
ISO 13849 implementation tools commonly require at least 65 CCF points for Category 2, 3 and 4 subsystems. The ABB Functional Safety Design Tool user manual documents this threshold and the related category conditions.
Still required: confirm the category conditions, MTTFd, DCavg, systematic measures and the behavior of the installed machine, then validate the complete safety function.
Shared-cause risk
Both channels use one unprotected route. One crush, cut, connector-ingress event or installation error affects both.
Both devices face the same uncontrolled stress. Heat, washdown, vibration, oil, corrosion or EMC can degrade both paths together.
Both channels repeat one design error. A shared configuration, software requirement or maintenance bypass defeats the apparent redundancy.
Countermeasure evidence
As-built separation and protection. Drawings, photographs, routing records, enclosure details and inspection evidence match the claim.
Environment and electrical design. Ratings, load protection, grounding, bonding, EMC measures and supply dependencies are controlled.
Lifecycle controls. Independent review, version control, training, bypass authorization, maintenance and change approval are documented.
| Potential common cause | Why redundancy can fail | Countermeasure direction | Evidence to retain |
|---|---|---|---|
| Shared physical route | One pinch, cut, ingress event or installation error affects both channels. | Separate or protect routes and connectors where the analysis requires it. | Electrical drawings, as-built photos, inspection and fault-test records. |
| Environment | Heat, coolant, washdown, dust, corrosion, vibration or shock degrades both. | Select suitable devices and enclosures; improve location, sealing and maintenance. | Environment specification, ratings, enclosure details and maintenance plan. |
| EMC / electrical disturbance | Surge, induced voltage, reference or wiring problems influence both paths. | Apply controlled separation, grounding, bonding and protective measures. | EMC design records, drawings, commissioning evidence and instructions. |
| Shared power or energy path | A common supply, output stage, valve manifold or mechanical link defeats both. | Analyze shared elements explicitly and design the required fault reaction. | Block diagram, FMEA, power/energy drawing and feedback test results. |
| Configuration / procedure | The same wrong parameter, software logic or maintenance action affects both. | Use independent review, version control, competence and controlled bypass. | Requirements, review records, version history, training and authorization. |
How do Category, MTTFd, DCavg and CCF combine?
The table below is a reading aid for the common simplified ISO 13849 approach. It is not a recipe for selecting a category. Current ISO 13849-1 requirements, applicable Type C standards and every qualitative category condition govern the real design.
| Category | Simplified structural idea | Typical MTTFd / DCavg pattern | CCF role | Critical boundary |
|---|---|---|---|---|
| B | Basic single-channel safety-related architecture. | MTTFd commonly low to medium; DCavg none. | Not generally a multi-channel CCF evaluation. | A fault can lead to loss of the safety function. |
| 1 | Single channel using well-tried components and safety principles. | MTTFd high; DCavg none. | Not generally a multi-channel CCF evaluation. | A single fault can still cause loss; attainable PL is limited. |
| 2 | Functional channel plus a test function. | MTTFd low to high; DCavg low to medium in the simplified model. | CCF measures required. | Test rate, test coverage and behavior after a detected fault are decisive. |
| 3 | Redundant functional channels with monitoring. | MTTFd low to high; DCavg low to medium in the simplified model. | CCF measures required. | A single fault must not cause loss; not every fault must be detected immediately. |
| 4 | Redundant channels with stronger fault detection and fault behavior. | MTTFd high; DCavg high in the simplified model. | CCF measures required. | Single and accumulated undetected faults must meet the Category 4 behavior. |
Category 3 does not automatically mean PL d. The achieved PL also depends on MTTFd, DCavg, CCF and the complete safety-function design. Nor does a product marked PL e make the complete machine PL e; its use, configuration, interfaces and downstream energy-control elements remain part of the assessment.
What can a worked example prove—and not prove?
Assume a risk assessment has already defined the PLr for a guard-opening safety function. The system contains two guard-switch channels, safety logic, two final energy-control paths, feedback monitoring and all interconnections. This is a reasoning example, not a calculation for a real cell.
- MTTFd: obtain exact switch, controller and final-element data. Use published B10d under the actual load and documented operations per year for wearing parts.
- DCavg: list what discrepancy monitoring, controller tests and output feedback really detect, including timing and fault response.
- CCF: inspect shared cable paths, mounting, panel environment, vibration, washdown, EMC, supply, software and maintenance practices.
- Validation: test guard opening, channel faults where specified and safely feasible, final-element feedback, reset, restart prevention, stop behavior and final safe state.
A model with high MTTFd and a 65-point CCF entry remains incomplete if it omits shared mechanical coupling, coast-down, a blind access route or an output that cannot remove hazardous energy.
Which mistakes should stop a Performance Level calculation?
| Mistake | Why it fails | Better practice |
|---|---|---|
| Starting with a desired PL | Components are chosen before the safety function and required risk reduction are defined. | Complete the risk assessment and safety-requirements specification first. |
| Using one component's PL claim | Product capability depends on application, configuration, interfaces and the full chain. | Model every input, logic, output and connection within the defined function. |
| Using B10 instead of B10d | General endurance does not identify the dangerous-failure portion. | Request authorized B10d or other appropriate safety data. |
| Guessing nop | Real starts, short products, test actions and shift patterns may differ greatly. | Document actual annual safety-related operations and what counts as one operation. |
| Averaging DC by eye | A highly diagnosed controller does not cancel a weakly diagnosed final element. | Use the applicable weighted DCavg method and failure-data rationale. |
| Calling every alarm a diagnostic | An alarm may not detect the dangerous fault in time or produce the required safe response. | Map failure mode, detection, timing, response and validation evidence. |
| Treating redundancy as CCF proof | Both channels can share wiring, supply, environment, design and maintenance errors. | Complete the CCF review against the actual installed machine. |
| Scoring planned measures | The numerical assessment no longer matches the as-built machine. | Verify routes, enclosures, EMC controls, competence and procedures at validation. |
| Using fault exclusion casually | A dangerous failure is removed without proving the conditions that make exclusion credible. | Retain the physical and standards-based justification for every exclusion. |
| Ignoring mission time and changes | The calculation remains in a file while components, speed, software or environment change. | Set service assumptions and reassess after relevant modification. |
What can SISTEMA support—and what cannot it validate?
DGUV IFA's SISTEMA supports developers and testers in modeling designated architectures and calculating reliability values for ISO 13849. The current official page states that version 3.x is assigned to ISO 13849-1:2023 and that PLr, Category, CCF, MTTFd and DCavg are entered step by step.
What the tool can support
- Structure safety functions, subsystems, blocks and elements.
- Calculate from controlled MTTFd, DCavg, Category and CCF inputs.
- Show the effect of parameter changes on the modeled function.
- Produce a report that records entered data and calculated results.
- Help manage manufacturer libraries and project documentation.
What the tool cannot prove
- That the risk assessment or PLr is correct.
- That the model includes every energy path and connection.
- That field wiring, mechanical installation or software matches the file.
- That claimed CCF measures exist on the machine.
- That diagnostics work, stopping is adequate or validation passed.
Version control matters. IFA states that each SISTEMA main version is assigned to a specific ISO 13849-1 revision rather than covering multiple revisions. Record the software version, standard basis, libraries and project file used for the assessment.
How should the completed safety function be assessed and validated?
- Define the hazard and safety function. State the initiating event, safe state, controlled energy, response time, modes and reset behavior.
- Determine PLr. Use the documented risk assessment, target market and applicable machinery standard.
- Map the full SRP/CS. Include input, logic, output, feedback, connections, power, software and mechanical, pneumatic or hydraulic paths.
- Justify Category and fault behavior. Verify every condition instead of naming a drawing by its channel count.
- Collect controlled component data. Record exact model, revision, MTTFd, PFH/PFHd or B10d basis, load, environment and mission time.
- Calculate MTTFd and DCavg. Use actual nop and map diagnostics to dangerous failures, timing and fault response.
- Evaluate CCF and systematic measures. Retain physical, electrical, environmental and organizational evidence.
- Verify, validate and control change. Compare achieved PL with PLr, test the installed function and review relevant modifications.
What should buyers request from a supplier or integrator?
A statement such as "safety rated" is not enough. Use the following list when requesting component data, reviewing an integrator proposal or accepting a finished machine.
- Hazard, task, initiating event and PLr or SIL target
- Defined safe state and all controlled energy paths
- Response time, stopping behavior and restart strategy
- Complete safety-function block diagram and I/O list
- Category rationale and single-fault behavior
- Exact product codes, revisions and safety manuals
- Authorized MTTFd, PFH/PFHd, B10d and mission-time data
- Load, switching duty, environment and annual nop
- Diagnostic-to-failure mapping and test intervals
- EDM or final-element feedback design where applicable
- CCF checklist plus as-built physical evidence
- Validation plan, test results and open deviations
- Software, firmware and safety-parameter backups
- SISTEMA or equivalent controlled calculation files
- Inspection, replacement and proof-test schedule
- Spare-parts, bypass and change-control procedure
Please provide the defined safety function and PLr; complete input–logic–output chain; exact manufacturer, model, suffix, revision and firmware; authorized MTTFd, PFH/PFHd or B10d data; load and annual operating duty; diagnostic-to-failure mapping; CCF evidence; mission time; calculation-file version; and the planned as-built validation tests. Identify every assumption or unavailable item.
Standards and technical references
- ISO 13849-1:2023 — official scope for design and integration of safety-related parts of control systems.
- ISO 13849-2:2012 — official validation scope for safety functions, achieved category and achieved PL.
- DGUV IFA SISTEMA — current official tool description, parameter scope and standard-version mapping.
- IFA Report 2/2017e — detailed application guidance for machine-control functional safety; confirm current-edition requirements.
- Siemens SIRIUS coupling relays — official B10d, operating-frequency and MTTFd explanation for the referenced product family.
- Siemens Contactors in Safety Applications — application-specific B10d, nop, MTTFd and T10d discussion.
- ABB Functional Safety Design Tool User Manual — category checks, CCF threshold and required reliability inputs.
Checked September 5, 2026. ISO 13849-1:2023 remains the published fourth edition. ISO 13849-2:2012 remains published while ISO/DIS 13849-2 is under development. Reconfirm the applicable edition, national adoption, tool version and exact manufacturer data before design release.
Send the safety function, not only a desired PL label.
Include the hazard and PLr, input-logic-output chain, exact part numbers, B10d or MTTFd data, actual duty, diagnostics, CCF evidence, drawings and existing calculation files. xsz sensor can help organize light-curtain and interface questions before product selection, while machine-level design and validation remain the responsibility of competent safety professionals.