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

2.4  Conversely, if a failure to meet a software safety requirement can have an impact on a number of different accidents then assessing the AEL solely on the basis of the worst credible event in the wider system is likely to result in an unduly low AEL for the software safety requirement.
2.5  Architectural and operational defences may be accounted for in one of two ways. First, by considering, the tolerable failure rate of the software safety requirement which when combined with other failures will cause the worst-case credible consequence. Second, by considering the number and strength of defences to be penetrated before causing the worst-case credible consequence.

3  Calculation of AEL
3.1  An AEL should be assigned using Tables 1 and 2 'AEL Safety Criticality' and 'AEL safety criticality modification due to Architectural and operational defences'.
3.2  The provisional assignment of AEL can be found from Table 1 by relating the worst credible consequence of the failure to meet the requirement (the hazard) to one of the columns in the table. Three sets of guidewords are given: ATS severity categories (based on EC Regulation 2096/2005, Mandatory occurrence reporting categories (CAP 382) and UK Airprox risk categories). These may help in understanding the hazard.
NOTE:  When using Table 1 the AEL should be adjusted to accommodate the cumulative risk of a failure to meet the software safety requirement. For example if the worst credible consequence of a failure to meet the software safety requirement represents a very large proportion of the risk, then this consequence alone can be used to assign the AEL. However if the risk of the worst credible event only represents a small proportion of the risk of failing to meet the software safety requirement then the AEL should be raised appropriately.
3.3  The assessment of the worst-case consequence may already be documented in the system hazard analysis. When this is not the case, a hazard analysis should be undertaken to assess how the software requirements might lead to one of these system level hazards.
Table 1 AEL safety criticality
AEL  1  2  3  4  5 
Characteristic 
(EC) 2096/  No  Significant  Major  Serious  Accident 
2005 Severity  immediate  incident  incident  Incident 
Classification  effect on  indicating  associated 
Scheme  safety  that an Accident, Serious incident or Major Incident could have occurred  with the operation of the aircraft 
Relationship to the Mandatory Occurrence Reporting Scheme (CAP 382)  No effect on ATC workload  Increased ATC workload  Loss of separation Significant ATC overload Significant degradation of ground based system  Serious loss of separation Serious ATC overload Serious degradation of ground based system  A UK reportable accident Actual risk of collision 
Relationship to the UK Airprox Board, Risk categories  N/A  C - no risk of collision  B - Safety not assured  A - Risk of collision  N/A 

3.4  If it can be argued that defences in other parts of the system (including other parts of the software) mitigate against the consequences of the failure to meet the software safety requirement then the provisional assignment of AEL can be reduced by using table 2.
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, Def Stan 00-56.
Table 2 AEL safety criticality modification due to Architectural and operational defences
Reduction of AEL  -1  -2  -3  -4 
　
中國航空網(wǎng) m.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：CAP 670 Air Traffic Services Safety Requirements 1(82)