7.4.7 Specific Requirements for Evidence of Overload Tolerance
Arguments may be made that design features are not required if the overload conditions are impossible.
Such overloads typically include: Excessive input-output data rates, Excessive processor usage, Disk storage overflows, Buffer overflows, and Virtual Storage overflows.
Arguments and evidence should justify that any claims about the impossibility of overload still apply under failure conditions.
It is expected that an appropriate form of direct evidence will be selected from the following table in order to demonstrate that the specified overload tolerance properties have been satisfied.
Acceptable Sources of Evidence: Overload Tolerance (Choose 1 column only from the appropriate row)
AEL 1 TESTING FIELD SERVICE EXPERIENCE & Analysis & Testing ANALYSIS & Testing ANALYSIS & Field Service Experience & Testing
AEL 2 TESTING & Analysis ANALYSIS & Field Service Experience & Testing ANALYSIS & Testing
AEL 3 TESTING & Analysis ANALYSIS & Field Service Experience & Testing ANALYSIS & Testing
AEL 4 ANALYSIS & Testing (Deterministic overload design) TESTING & Analysis (Non deterministic overload design)
AEL 5 ANALYSIS & Testing (Deterministic overload design) TESTING & Analysis (Non deterministic overload design)
7.4.7.1 Direct Evidence from Analysis for Overload Tolerance
Arguments and evidence should be available which show that:
a) The design is capable of degrading gracefully under overload conditions so that software safety requirements are still met.
b) For AEL 4 & 5, the use of rigorous arguments of overload have been made.
NOTE: Where the design does not allow the loading to be determined analytically then at AELs 4 & 5 such evidence of overload tolerance will not be compelling. The arguments presented in this case will support testing by providing analysis of the test cases.
7.4.7.2 Backing Evidence for Analysis of Overload Tolerance
Arguments and evidence should be available which show that the overload analysis is credible under worst-case operational conditions.
8 Guidance on Credible Arguments and Evidence to Demonstrate Requirements Traceability Relating to Objective C
8.1 Direct Evidence for Requirements Traceability
Arguments and direct evidence of software safety requirements traceability should be available that demonstrate:
a) Each requirement introduced at each level in the design has been traced to the same level of design at which its satisfaction is demonstrated.
b) Each requirement introduced at each level in the design has been traced to a system safety requirement.
8.2 Backing Evidence of Requirements Traceability
To give confidence that the traceability records are correct and complete, arguments and backing evidence should be available that demonstrate:
a) The notation for tracing the software safety requirements is unambiguous and has been used consistently.
NOTE: Traceability encompasses all pre-existing software items included in or called from the application.
b) The notation for tracing software safety requirements supports both forward and backward traceability.
c) Any tools used to support traceability did not corrupt the traceability structures and records.
d) Procedures or tools have been used to ensure that any loss of traceability or incorrect traceability is detected and corrected.
e) Any tools used to construct or maintain traceability have been verified and validated to an appropriate level for the impact of the tool on the design.
9 Guidance on Credible Arguments and Evidence to Demonstrate Freedom from Interference by Non Safety Functions Relating to Objective D
中国航空网 www.aero.cn
航空翻译 www.aviation.cn
本文链接地址：CAP 670 Air Traffic Services Safety Requirements 1(79)
