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.
中国航空网 www.aero.cn
航空翻译 www.aviation.cn
本文链接地址：CAP 670 Air Traffic Services Safety Requirements 1(86)
