Basic concepts and taxonomy of dependable and secure computing¶
Avizienis, Laprie, Randell, & Landwehr. (2004). Basic concepts and taxonomy of dependable and secure computing. IEEE Transactions on Dependable and Secure Computing, 1(1), 11-33.
Cited by¶
11 citations across 11 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Circuit Breaker
- The pattern answers a recurring problem that appears wherever flows can cascade: how does a system stop a fault in one part from cascading into ruin of the whole, when there is no time for deliberation and the safest move is to break the connection first and ask questions later?
This sourceFoundational dependability taxonomy: defines fault prevention/tolerance/removal/forecasting and the error-detection-and-recovery (locate / isolate the error / reconfigure / restart) means of stopping a fault from propagating to system-wide failure.
Supported in partVerified against the work's full text
Avizienis et al. describe error propagation and fault handling that excludes faulty components from service, but not a general break-the-connection-first pattern across flow systems.
“performs physical or logical exclusion of the faulty components from further participation in service”
- The pattern answers a recurring problem that appears wherever flows can cascade: how does a system stop a fault in one part from cascading into ruin of the whole, when there is no time for deliberation and the safest move is to break the connection first and ask questions later?
- Diversification
- Software and security: N-version programming reduces common-mode bugs through independently developed implementations; defence in depth layers controls with uncorrelated failure modes.
This sourceDefines design diversity (N-version programming) and common-mode failure in dependable systems.
Supported in partVerified against the work's full text
Supports design diversity (separate implementations) against solid development faults and defines common-mode failures, but never uses N-version programming as a concept and has no defence-in-depth discussion.
“which necessitates that the channels implement the same function via separate designs and implementations”
- Software and security: N-version programming reduces common-mode bugs through independently developed implementations; defence in depth layers controls with uncorrelated failure modes.
- Fallback Path
- A fallback path is a maintained alternative route that carries a function when the preferred route cannot, entering service on a declared condition and delivering a stated floor rather than the full measure of performance.
This sourceDefines fault handling by reconfiguration onto non-failed components, and separately defines degraded modes of service in which the specification names reduced levels — slow service, limited service, emergency service — that the system signals to its users.
Supported in partVerified against the work's full text
The paper supplies specified degraded service modes signalled to users and reconfiguration onto spares, the parts from which a fallback path is built, but does not define a fallback path.
“the failure of one or more of the services implementing the functions may leave the system in a degraded mode that still offers a subset of needed services to the user. The specification may identify several such modes, e.g., slow service, limited service, emergency service, etc.”
- A fallback path is a maintained alternative route that carries a function when the preferred route cannot, entering service on a declared condition and delivering a stated floor rather than the full measure of performance.
- Fault Tolerance
- A common failure is choosing the wrong boundary (continuing to serve under faults that require shutdown; or shutting down when graceful degradation was acceptable), producing either incorrect behavior or unnecessary downtime
This sourceCanonical dependability taxonomy defining failure-response modes, including fail-safe (halt to a safe state) versus graceful degradation (reduced service), and the design choice between them.
- A common failure is choosing the wrong boundary (continuing to serve under faults that require shutdown; or shutting down when graceful degradation was acceptable), producing either incorrect behavior or unnecessary downtime
- Functional Redundancy (Degeneracy)
- As Avizienis, Laprie, Randell, and Landwehr (2004) make explicit in their dependability taxonomy, common-mode and common-cause failures are the dominant threat to nominally redundant systems: designers shape redundancy by maximizing independence — geographically separated data centers, mechanically and hydraulically diverse control lines, phylogenetically distinct species in an ecological guild.
This sourceAuthoritative dependability taxonomy formalizing common-cause/common-mode failures as the dominant threat to redundant systems; directly supports the failure-mode-decorrelation framing.
Supported in partVerified against the work's full text
Avizienis et al. define common-mode failures, say redundancy relies on independence, and give design diversity as the remedy; they do not call these the dominant threat or give the data-center or species examples.
“the occurrence of common-mode failures when independent ones are assumed, that is a lack of failure independence coverage.”
- As Avizienis, Laprie, Randell, and Landwehr (2004) make explicit in their dependability taxonomy, common-mode and common-cause failures are the dominant threat to nominally redundant systems: designers shape redundancy by maximizing independence — geographically separated data centers, mechanically and hydraulically diverse control lines, phylogenetically distinct species in an ecological guild.
- Redundancy
- Multiple configurations exist, each with distinct failure-coverage and cost trade-offs: active-active (all copies operate, any one suffices); active-standby (primary operates, standby takes over on failure); diverse-redundancy (different implementations of the same function, reducing common-mode failures); voting (majority among copies determines output)
This sourceAuthoritative taxonomy of dependability that formalizes common-cause and common-mode failures as the dominant threat to redundant systems and frames redundancy engineering as failure-mode decorrelation.
Supported in partVerified against the work's full text
The taxonomy places the two notions in different categories. Robustness appears as “a specialized secondary attribute”, dependability with respect to external faults, while redundancy is treated as a structural means, protective redundancy introduced to provide fault tolerance. An attribute of a system and a structural means of achieving dependability are distinct entries in that scheme, which is the distinction the sentence draws. The work nowhere states the contrast in those words; it follows from its separate placement of robustness among attributes and redundancy among the means of fault tolerance.
“An example of a specialized secondary attribute is robustness, i.e., dependability with respect to external fa ults”
- Multiple configurations exist, each with distinct failure-coverage and cost trade-offs: active-active (all copies operate, any one suffices); active-standby (primary operates, standby takes over on failure); diverse-redundancy (different implementations of the same function, reducing common-mode failures); voting (majority among copies determines output)
- Substitutability
- Avizienis, Laprie, Randell, and Landwehr (2004) underscore in their dependability taxonomy that what counts as the "critical function" being preserved under substitution is itself a normative choice—an engineering specification that encodes which failures matter and to whom—rather than a value-free technical property.
Supported in partVerified against the work's full text
The taxonomy says failure severity levels and acceptable failure probabilities are application-related and that failures can be subjective, but it never discusses substitution or calls this normative.
“The number, the labeling and the definition of the severity levels, as well as the acceptable probabilities of occurrence, are application-related”
- Avizienis, Laprie, Randell, and Landwehr (2004) underscore in their dependability taxonomy that what counts as the "critical function" being preserved under substitution is itself a normative choice—an engineering specification that encodes which failures matter and to whom—rather than a value-free technical property.
Mechanisms¶
- Fallback Control Mode
- This is graceful degradation applied to a disabled lever — losing function progressively and safely instead of all at once.
This sourceDefines a degraded mode in which failure of some functions leaves the system providing a subset of needed services rather than losing all service.
- This is graceful degradation applied to a disabled lever — losing function progressively and safely instead of all at once.
- Minimum Viable Service Floor
- Define acceptable degradation. State what "reduced but safe" service looks like for each — the difference between graceful degradation
This sourceExplains that specifications can define degraded modes that continue a stated subset of needed services, such as limited or emergency service.
- Define acceptable degradation. State what "reduced but safe" service looks like for each — the difference between graceful degradation
- Multi-Level Redundancy Design
- And because even separate hydraulics could share a common cause, the architecture adds dissimilar redundancy: an electrically-signalled backup path built on different technology, different suppliers, and different software, so that a systematic flaw in the primary system has no counterpart to exploit in the backup.
This sourceExplains that design diversity uses separately designed implementations of the same function so a shared design fault is less likely to defeat every redundant channel.
- And because even separate hydraulics could share a common cause, the architecture adds dissimilar redundancy: an electrically-signalled backup path built on different technology, different suppliers, and different software, so that a systematic flaw in the primary system has no counterpart to exploit in the backup.
- Reroute and Reentry Protocol
- Because the substitution is governed rather than improvised, the thin-file applicant reaches the same endpoint by a different admissible route — the system degrades gracefully
This sourceDefines partial service failure as a degraded mode that still provides a subset of needed services.
- Because the substitution is governed rather than improvised, the thin-file applicant reaches the same endpoint by a different admissible route — the system degrades gracefully
Verification¶
Does it exist? Confirmed. This work's DOI resolves to a registered record, which fixes its identity. That is all it fixes.
Does it back the claim? Read against the text for 6 of 11 citations: 6 supported in part. Each verdict is shown under its citation below, with what in the work backs the sentence.
Was it audited? Yes. A second, independent pass read the citation against the article text and recorded a verdict.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Registry ID ref:d8cea232568d · see in the full table