曝光臺 注意防騙 網(wǎng)曝天貓店富美金盛家居專營店坑蒙拐騙欺詐消費者

b) To assist Systems Integrators and/or Equipment Manufacturers in providing assurances, for the behaviour of software in their products, that are appropriate for demonstrating compliance to the safety objectives mandated by this regulation.
4.2  Service Providers and/or Equipment Manufacturers are free to propose and use alternative methods of evaluation with the agreement of the Civil Aviation Authority. This guidance is only provided for those Service Providers and/or Equipment Manufacturers that do not wish to propose their own methodology for demonstrating compliance with the safety objectives mandated by this regulation.

5  Guidance on Presenting Arguments and Evidence that the Assurance Objectives have been met
5.1  Credible arguments and evidence should be available to demonstrate the achievement of each of the five assurance sub-objectives defined in section 3. The credible limits and bounds of which are provided in sections 5 to 9 of this document.
5.2  To demonstrate the validity of the arguments and evidence it should be possible to show that:
a) A coherent and convincing argument with adequate supporting evidence is available to claim the achievement of each of the five assurance objectives defined in section 3.
b) For all claims, Direct and Backing evidence are combined into an argument that provides justification for the claim.
5.3  Appendix B defines the terms Direct Evidence and Backing Evidence and the principals and concepts upon which the arguments and evidence should be based.
5.4  This guidance uses the concept of Assurance Evidence Levels (AELs) to relate the criticality of the software safety requirement to the depth and strength (rigour) of evidence required for the assurance of its correct implementation. AELs are explained in detail in Appendix A.

6  Guidance on Credible Arguments and Evidence to Demonstrate Requirements Validity Relating to Objective A
6.1  Direct Evidence of Requirements Validity
To demonstrate the validity of software safety requirements, arguments and evidence should be available that show:
a) The software safety requirements are a valid sub-set of the system-level safety requirements.
b) The software safety requirements adequately specify the required safety behaviour of the software.
c) Each software safety requirement includes either:
i)  A specification for each of the Behavioural Attributes (see Appendix C), or
ii) A valid argument that the attribute is not applicable
d) All hazardous failure modes of the software have been identified at the Software requirements (AELs 1,2,3,4 & 5), Software internal design (AELs 2,3,4 & 5) and Software source code levels (AELs 4 & 5).
e) All hazardous failure modes identified at each level in the software design or in the software implementation are traceable to a defence (i.e. to a safety requirement for software, hardware or operation) or to a justification that no defence is necessary.
f)  The software safety requirements should be specified explicitly and should be set out in such a way as to be easily distinguishable from other requirements.
g) The software safety requirements should be specified in sufficient detail and clarity to allow the design and implementation to achieve the required level of safety.

6.2  Backing Evidence of Requirements Validity
To give confidence that the requirements are correct and complete, arguments and backing evidence should be available that demonstrate:
a) The specification notations are capable of supporting the identification of all modes of software failure that cause a system level hazard.
b) The analytic methods and techniques used are appropriate for the attributes of the software safety requirements.
c) The analysis notations are appropriate to the problem domain and representation and allow an adequate analysis of the design.
　
中國航空網(wǎng) m.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：CAP 670 Air Traffic Services Safety Requirements 1(70)