1.4  Thus SW01 provides the basic relationship between software safety and regulatory assurance and it is only necessary to demonstrate achievement of the four assurance objectives to the Authority.
1.5  The guidance in part 3 defines the bounds of arguments and the types of evidence that may be used to support a claim that an objective has been achieved. The service provider needs to provide the actual claim, arguments and supporting evidence. It is likely that sub-claims will be made by the service provider to support the claim that an objective has been achieved. Any argument and evidence must also justify the choice of sub-claims

2  Evidence
2.1  For the purposes of this document, evidence, to support an argument that a safety assurance objective has been met, can take one of two complementary forms, as follows:
a) Direct Evidence – that which is produced by an activity taking place or software behaviour occurring, which is directly related to the claim being made; and
b) Backing Evidence – that which shows that the Direct Evidence is both credible and soundly based.
NOTE 1:Backing is only required for direct evidence actually produced.
NOTE 2:For example:
For a situation where test specifications, test scripts, test harness programs and test results have been submitted as evidence to support claims that the requirements satisfaction objective (part 3 section 5) has been achieved. It would be necessary to make a sub-claim that the configuration consistency objective (part 3 section 9), for that evidence has also been achieved. To do this, requirement 9.1 for direct evidence and requirement 9.2 for backing evidence must be satisfied.
2.2 To substantiate a claim that this is true, the following statement could be made: 'The test specifications, test scripts, test harness programs and test results apply to the version of the source code being assessed because a unique numbering system is used, this is controlled by a configuration management system and has been checked by review.' a) The claim is: 'The test specifications, test scripts, test harness programs and test results apply to a known version of the source code.' b) Direct evidence is: The unique numbers are present on all data submitted as evidence and they are controlled by a configuration management system that has been checked by review. c) Backing evidence is: Audit of numbers and reviews, evidence of CMS pedigree, etc. To be able to claim achievement of the configuration consistency objective in
full it would be necessary to:
.  
Put forward similar sub-claims for all other evidence submitted to support claims of achieving the other objectives;

.  
Argue that the set of sub-claims is complete.

3 Rigour of Arguments
The rigour (depth and strength) required of the arguments, that the assurance objectives have been met, increases with AEL. The increased rigour is introduced by requiring the arguments to be presented to a lower level of design.

4 Arguing Requirements Satisfaction
4.1 Structuring of Arguments
In arguing achievement of Safety Requirements Satisfaction objective at an AEL greater than 3 in particular, a single argument is considered to be insufficient to adequately demonstrate that the objective has been met. The concept of Primary and Secondary arguments has therefore been introduced, as follows.
4.1.1 Primary Arguments
Primary Arguments are, as the name suggests, the main arguments (using the Direct and associated Backing evidence) that the software safety requirement is satisfied.

4.1.2  Secondary Arguments
4.1.2.1  Secondary Arguments provide additional, independent arguments that the safety requirement is satisfied. They compensate for the possible lack of completeness and uncertainty in the Primary Argument.
4.1.2.2  Secondary Arguments need not demonstrate the claim completely, but the result should not contradict the result of the primary argument.
　
中國(guó)航空網(wǎng) m.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：CAP 670 Air Traffic Services Safety Requirements 1(84)