Development Assurance Level misclassification is not a rare edge case in aerospace safety assessments. It appears with sufficient regularity in PSSA reviews that experienced certification engineers treat it as a default assumption, asking not whether a PSSA contains DAL errors, but where they are and how many.
Understanding the patterns in which DAL misclassification occurs is the first step toward catching errors before they propagate into architecture decisions and certification submissions.
What DAL means and where it comes from
The Development Assurance Level is a measure of the rigour required in the development process for a system or item, not a measure of how likely it is to fail. A DAL-A item is not necessarily less likely to fail than a DAL-D item in isolation; it is subject to more demanding development, verification, and process assurance requirements, which makes its failure probability more predictable and controllable.
DAL is derived from the severity classification of the failure condition that the item's failure would contribute to. The derivation is defined in ARP4754A §5 and referenced in ARP4761A:
- Catastrophic failure condition: DAL-A
- Hazardous failure condition: DAL-B
- Major failure condition: DAL-C
- Minor failure condition: DAL-D
- No Safety Effect: DAL-E
The critical word is "contribute to". A single item may contribute to multiple failure conditions of different severities. ARP4754A requires that it be assigned the highest applicable DAL, the one corresponding to the most severe failure condition it can affect.
Pattern 1: Independence criterion violations
The most frequently cited DAL misclassification in PSSA review involves the independence requirements for dissimilar redundant architectures.
ARP4754A §5.3.2 specifies that when a failure condition is allocated across two independent channels, the combined probability requirement applies to the joint failure of both channels. Each channel must be independent, meaning a common cause failure cannot affect both. If independence cannot be demonstrated, the combined architecture cannot achieve the intended probability target and the DAL allocation is invalid.
In practice, the error appears as follows: a Catastrophic failure condition (10⁻⁹ requirement) is allocated to two channels, each targeted at 10⁻⁵ (DAL-C), on the assumption that 10⁻⁵ × 10⁻⁵ = 10⁻¹⁰, which meets the target. This arithmetic is correct only if the channels are truly independent. If a common power supply, a common software baseline, or a shared physical environment (thermal, vibration) exists, independence is broken, the multiplication does not apply, and the DAL-C allocation is insufficient for a Catastrophic failure condition.
The PSSA must explicitly demonstrate independence. Asserting it without the supporting analysis is not sufficient, and the error is difficult to catch from the DAL allocation table alone; it requires cross-referencing the allocation against the architecture description in the SDD.
Pattern 2: Latent failure mode omission
A latent failure is one that is not detectable by the crew or by onboard monitoring during normal operation. ARP4761A requires that latent failures be included in the fault tree analysis and that their assumed exposure time, specifically the interval between maintenance checks that would reveal the failure, be explicitly stated and justified.
The error pattern is omission: latent failure modes that are present in the architecture are not represented in the fault tree, and the resulting probability calculation is optimistic. The top-level target appears to be met, but the unmodelled latent failure would, if included, push the calculated probability above the target.
This pattern is particularly common in systems with long maintenance intervals. A hydraulic component with a 3,000-hour check interval and a latent failure rate of 10⁻⁶ per flight hour contributes a 3 × 10⁻³ exposure probability, a number that can meaningfully affect fault tree results and that is frequently omitted from PSSA analyses of this class of system.
Pattern 3: Incorrect failure condition aggregation
Complex systems can fail in multiple ways that affect the same aircraft function. ARP4761A requires that where multiple failure modes contribute to the same failure condition, the combined probability of all contributing failure modes must meet the target, not each individual failure mode independently.
The misclassification error occurs when the PSSA analyses failure modes individually rather than in combination. Each individual failure mode meets its allocated budget. The sum of all failure modes contributing to the same failure condition does not meet the top-level target. The allocation is invalid, but the error is invisible if the analysis is structured so that individual fault trees do not converge.
This pattern is common in systems with multiple independent failure paths to the same top-level event, especially when different failure paths are analysed by different engineering teams working from separate sections of the SDD.
Pattern 4: Phase-of-flight probability errors
Failure condition probability requirements apply per flight hour. The probability calculation in the fault tree must use failure rates that are consistent with the phase of flight in which the failure condition is most severe.
A failure condition classified as Catastrophic during approach, where the aircraft is at low altitude with limited recovery margin, must use failure rates that reflect approach-phase operational conditions. Using cruise-phase failure rates for components that are under higher stress during approach (hydraulic actuators at high deflection rates, for example) produces an optimistic probability calculation.
This error is difficult to catch because it is invisible in the fault tree structure itself. The logic is correct; the numbers are wrong. It requires cross-referencing the failure rates used in the fault tree against the operational profile of each component in the relevant flight phase.
Pattern 5: DAL assignment for shared items
Items that are shared between multiple systems present a consistent DAL assignment challenge. The item must be assigned the highest DAL required by any failure condition it can affect, including failure conditions that belong to systems other than the one being assessed.
The error appears when PSSA authors assign DAL based only on failure conditions within the scope of their own system assessment, without considering the failure conditions of other systems that share the item. An avionics bus shared between a DAL-B flight control function and a DAL-D cabin management function must be assigned DAL-B. If the PSSA for the cabin management system assigns it DAL-D without reference to the flight control system's requirements, the allocation is incorrect.
This pattern is structurally difficult to catch within a single PSSA because the relevant information, namely the flight control system's DAL requirement for the shared item, is in a different document. Cross-document checking is required.
Why these errors persist
All five patterns have one property in common: they cannot be reliably detected by reviewing a single document in isolation. They require cross-referencing the PSSA against the FHA that drove the classification, the SDD that describes the architecture, the ICD that defines the interfaces, and in some cases the PSSAs of adjacent systems.
Manual cross-referencing at this scale is slow, error-prone, and, in practical terms, rarely completed comprehensively before design freeze. The result is that DAL misclassifications survive into certification submissions and are caught during regulatory review, at the point when correcting them is most expensive.
Systematic cross-document analysis is the only reliable way to catch these errors early. The five patterns above are a direct description of what such analysis needs to check.
evidion's multi-document check identifies DAL misclassifications, independence violations, and cross-document inconsistencies automatically. Join the pilot programme to see it on your project documents.