7.4.2.3 Direct Evidence from Analysis of Timing Properties
Arguments and evidence should be available which show that:
a) The results of a worst-case timing analysis prove that the specified time response for the software safety requirement has been met.
NOTE: For simple software designs (e.g. using fixed loops and cyclic scheduling) design arguments and supporting evidence may be used to demonstrate that response times and throughput are invariant. This evidence may be used in conjunction with explicit timing and throughput measurements to show that the timing constraints are met.
b) For complex software designs, the worst-case timing path through the software has been determined by analysis.
c) For complex scheduling, all safety related components that implement safety requirements meet their timing and throughput requirements (e.g. using queue simulation models).
d) For AEL 3, 4 & 5, all practicable measures have been taken to ensure that no timing anomalies exist.
e) For AEL 4, rigorous arguments were used to ensure timing correctness.
f) For AEL 5, proof was used to ensure timing correctness for the safety properties.
7.4.2.4 Backing for Analysis of Timing Properties
Arguments and evidence should be available which show that the modelling assumptions are applicable and take into account the speed of the hardware on which it will be implemented and any associated input-output devices.
7.4.3 Specific Requirements for Evidence of Robustness
It is expected that an appropriate form of direct evidence will be selected from the following table in order to demonstrate that the specified robustness properties have been satisfied.
Acceptable Sources of Evidence: Robustness (Choose 1 column only from the appropriate row)
AEL 1 TESTING TESTING & Field service experience ANALYSIS & Testing
AEL 2 TESTING TESTING & Field service experience ANALYSIS & Testing
AEL 3 ANALYSIS & Testing ANALYSIS & Testing & Field Service Experience
AEL 4 ANALYSIS & Testing ANALYSIS & Testing & Field Service Experience
AEL 5 ANALYSIS & Testing
7.4.3.1 Direct Evidence from Testing for Robustness
Arguments and evidence should be available which show that all credible modes of failure have been covered, including software failures, interface failures, power-loss and restoration, failures of linked equipment, and breaks in communication links.
7.4.3.2 Backing for Testing of Robustness Arguments and evidence should be available which show that: a) The test cases cover a complete credible set of environmental failure modes. b) Credible sequences of environmental failures are covered by the test cases.
7.4.3.3 Direct Evidence from Analysis for Robustness
Arguments and evidence should be available which show that:
a) The software design has features that make it robust to internal and external failures. The analysis should identify the failure modes considered and the design strategy used to recover from or mitigate the failures.
NOTE: These failures typically include failures of concurrent software processes, the scheduler, input-output interfaces and file storage.
b) Failures of non-safety related components within the same computer do not affect the functioning of safety-related components (i.e. there is adequate segregation of resources).
c) For AEL 3 and above, source code cannot lead to run-time exceptions.
NOTE: This does not imply that exception-handling code should not be provided. Exceptions may still arise from transient or permanent hardware failures, or where errors have been made in the demonstration that the source code cannot raise exceptions.
中国航空网 www.aero.cn
航空翻译 www.aviation.cn
本文链接地址：CAP 670 Air Traffic Services Safety Requirements 1(76)
