Appendix C to SW 01 - Definitions and Abbreviations
The following terms are used in this document in addition to the general glossary of Definitions and Abbreviations.
Definitions
Accuracy  The required precision of the computed results. 
Application  The whole system that provides the overall service to the user. 
Application Software  The software part of the application, including data. 
Assurance Evidence Level (AEL)  Assurance Evidence Levels (AELs) are allocated to software safety requirements to identify the type, depth and strength of evidence that must be made available from the software lifecycle for the equipment approval process. 
Barrier  A barrier is a mechanism that constrains interference to an element. A barrier has scope and strength. 
A barrier constrains rather than eliminates interference. 

Barriers tend to be orientated to protect from inbound interference rather than prevention of outbound interference.
While the concept of protecting a communication path from interference (e.g. corruption) is familiar (parity bit checks, checksums, etc. are all barriers), applying the same concepts to the code is perhaps less familiar. 'Defensive code' would be a partial barrier against interference (e.g. software that checks the format / structure of inbound messages). More complex barriers would typically be available from an Operating System
(e.g. providing protected memory).
Barricade  The set of barriers associated with a Software Architectural Unit that protect the functions of a Software Architectural Unit from interference from other Software Architectural Units.
Behavioural Attributes  Functional properties, Timing properties, Robustness, Reliability, Accuracy, Resource usage, Overload tolerance. The relationship between the Behavioural attributes is illustrated below: 
Reliability (Integrity) 
Accuracy  Integrity 
Timing Properties  Integrity 
Overload Tolerance  Integrity 
Resource Usage  Integrity 
Robustness  Integrity 
Correct  Free from fault. (Note: This does not mean mathematically proven. Where Formal proof of Correctness is required it is stated in the text.) 
Design notation  Any notation that has well understood (although not necessarily a formally specified) semantics, which describes the structure or intended behaviour of some aspect of a software system, either by graphical or textual means, or both. Examples of design notations include data and control flow diagrams, state transition diagrams, MASCOT or HOOD diagrams, and decision tables. A high level programming language is regarded here as a particular kind of design notation, although with the special property that it can be compiled directly into executable code. 
Element  A unit of code. Units of code deliver functionality, which combines to ultimately fulfil requirements. Typically one might think of elements as procedures, tasks, objects etc. 
Elements are grouped together (with a barricade) to form AUs. An element may belong to more than one AU. 
Function  A mode of action or activity by which software fulfils its purpose. 
Functional Properties  The primary functional behaviour of the software. 
Hazard Analysis  A systematic investigation of the hazards posed bysystem, in terms of likely effects of system behaviour.  a 

Interference
Operating System
Overload Tolerance
Pre-existing software
Proof
Reliability
Report Resource Usage
Interference is defined as unintended (therefore un-designed) interaction between elements (either within or between AUs). Interfaces are known as Designed Interactions. Undesigned interactions are synonymous with interference.
　
中國航空網 m.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：CAP 670 Air Traffic Services Safety Requirements 1(86)