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

Characteristic 
Number and strength of defensive layers  Requirement is monitored  Requirement is met independently in a redundant channel  At least two forms of mitigation which are not part of the requirement  Many forms of mitigation such that a failure of the implementation to satisfy the requirement is extremely unlikely to result in the hazard. 
The probability of the failure of all Architectural and operational defences  10-2/hr  10-3/hr  10-5/hr  10-7/hr 

The provisional AEL from Table 1 is then added to the offset provided by Table 2.

4  Software Components
4.1  The smallest software component is an element that can be verified. Software safety requirements may be attached to an element to control its behaviour. A grouping of elements that are protected from external reference is called a Software Architectural Unit. These are described in Appendix E. Within a Software Architectural Unit no argument for the independence of the attributes of software functions from each other can be made, consequently all software safety requirements placed on a Software AU must assume the same AEL.
NOTE 1:Independence may be physical or logical.
NOTE 2:A software component may be a single executable program, a number of programs operating together, or a part of a single program e.g. a concurrent process, depending on the system and software architecture.
NOTE 3:As software components become larger and/or more complex it becomes increasingly difficult to provide arguments and evidence that the ATS system will perform all of its safety related functions without failure. Independence may be used to minimise the size and complexity of software components to ease this difficulty.
4.2  The AEL allocated to the software safety requirements implemented in a Software Architectural Unit should be the highest AEL of the individual software safety requirements of the elements contained within the Software Architectural Unit.
4.3  The evidence required to support arguments of the adequacy of the Software Architectural Unit's barricade is determined by the AEL of the Software Architectural Unit.
4.4  Requirements derived from a software safety requirement cannot be assumed to have the same AEL as the originating requirement. They must be evaluated, as defined in section 3 Appendix A, in order to derive their correct AELs.
4.5  Design decisions must be evaluated at the system level in order to identify any new software safety requirements. These new software safety requirements must then be allocated an AEL, as defined in section 3 Appendix A.
NOTE:  This document assumes that software safety requirements have been derived from a full risk and safety analysis of the system. This will have established the overall safety requirements that have been refined and allocated in the design to software. This is a commonplace system safety process and is described in standards and guidelines such as IEC 61508 Part 1, ARP4754, and Def Stan 00-56.
INTENTIONALLY LEFT BLANK

Appendix B to SW 01 - Argument and Evidence Concepts
1  Safety Arguments
1.1  SW01 Part 3 section 4 guides the service provider in preparing a coherent and convincing argument with adequate supporting evidence to assure the regulator that the prime software safety objective has been achieved:
1.2  To ensure that the risks associated with deploying any software used in a safety related ATS system have been reduced to a tolerable level.
1.3  SW01 provides an argument that assurance of achieving the prime software safety objective may be demonstrated by achieving each of the five assurance objectives elaborated in Part 3, i.e.:
a) Safety Requirements Validity (section 5);
b) Safety Requirements Satisfaction (section 6);
c) Safety Requirements Traceability (section 7);
d) Freedom from Interference by Non Safety Functions (section 8);
　
中國航空網 m.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：CAP 670 Air Traffic Services Safety Requirements 1(83)