RTCA SC-189/EUROCAE WG-53 Position Paper Air Traffic Services Safety and Interoperability Requirements

(1)

RTCA SC-189/EUROCAE WG-53 Position Paper

Air Traffic Services Safety and Interoperability Requirements

General Information

Position Paper Number: Call 206 227 2763 to get #: Leave fax #

P/SG2/13

Revision: e.g. 3

3

Date: e.g. 11 Nov 94 29 Apr 98

Comments Due: 29 May 98 Author/Address/Fax/Voice/Internet:

Gary Morton

Safety Regulation Group Aviation House

Gatwick Airport South Area West Sussex United Kingdom RH6 0YR Voice: 44-1799-573330 FAX: 44-1799-573974 Internet: [email protected]

Send Comments to (Include Name/Address/Fax/Voice/Internet):

Author

Position Paper Title:

Common safety objectives for ATS Systems using datalink. Abstract:

This position paper has been updated after the SG2 sub group meeting of 21-23 April.

That meeting decided that the term safety objective and requirement should be defined and that the reasons for common safety requirements should be defined.

The elements of this paper will then be moved to paper 21 or others as appropriate.

Action taken: Resolution

Required By:

Key words (Optional):

Status

Individual Proposal Sub-Group Agreement Plenary Agreement

Internal Use Only Closed SC-189 Co-chair prop.

Distribution

Name Org Internet Fax

3FMS Architecture & Design Flight Trials Mathematical Model Operational Concepts Program, Planning, Progress Simulation results Standards and Requirements ADS AFMS AIRSAW ARINC DAG-TM EMERALD EUROCAE FARAWAY FREER Glasgow Uni MAICA NEAN NEAP NLR PETAL RHEA RTCA SafeFlight21 SUPRA TELSACS TORCH TUB

Back to Main TOC

EUROCAE

European Committee for Aviation Equipment

Search GeneralHelp Back to Top TOC pu-22-fina.pdf 23 June, 2000

EUROCAE WG-53 Position Paper: Guidelines for Approval of the Provision and Use of Air Traffic Services

Supported by Data Communications Tom Miller (FAA)

This position paper is used to develop and track the changes of ED/DO-GUID publication, Guidelines for Approval of the Provision and Use of Air Traffic Services Supported by Data Communications. This publication will contain the guidance material being produced by the sub-groups.

Subject Date Filename Keywords VIEW Author(s) wg53.pdf 6 June, 2000

SC 189/ WG 53: Guidance document overview

Aerospatiale Matra Airbus Guidance document overview in Powerpoint

Subject Date Filename Keywords VIEW Author(s) g2-12-06.pdf 18 May, 2000

Application of the Safety Methodology to the South Pacific environment for datalink applications.

MITRE This position paper aims at applying the safety methodology defined by SG2 to the South Pacific environment.

Subject Date Filename Keywords VIEW Author(s) Back to EurocaeTOC

(2)

RTCA SC-189/EUROCAE WG-53 Comment

Position Paper Information

(To be completed by Position Paper Author and attached to position paper)

P/SG2/13

Revision: e.g. 3

2

Date: e.g. 11 Nov 94 29 Apr 98

Comments Due: 29 May 98 Author/Address/Fax/Voice/Internet:

Gary Morton

Author

Generalised safety objectives for ATS Systems using datalink..

Comment Information (To be completed by Comment Author)

Comment Author (Include Name/Address/Fax/Voice/Internet): Comment Date:

e.g., 3 Apr 96

Type of Comment (Check all that apply): Response Requested

Disagreement Clarification Additional Material Comment (Attach pages as necessary):

Proposed Solution (Attach pages as necessary)

Status of Comment/Action Taken (To be completed by position paper author or delegate)

Assigned to: _SG-1 _SG-2 _SG-3 _Staff _CAG _Other Comment Number:

C-Status/Action Taken:

(3)

RTCA SC-189/EUROCAE WG-53 Comment response

Position Paper Information

(To be completed by Position Paper Author and attached to position paper)

P/SG2/13

Revision: e.g. 3

1

Date: e.g. 11 Nov 94 16 Oct 97

Comments Due: 10 Dec 97 Author/Address/Fax/Voice/Internet:

Gary Morton

Author

Generalised safety objectives for ATS Systems using datalink..

Comment Information (To be completed by Comment Author)

Comment Author (Include Name/Address/Fax/Voice/Internet): S Cohen

[email protected]

Comment Date: e.g., 3 Apr 96 22/4/98

Type of Comment (Check all that apply): Response Requested

Disagreement Clarification Additional Material Comment (Attach pages as necessary):

1/Use of word ‘maximise’ is unclear suggest ‘ in each case to ensure the greatest uniformity possible in aircraft equipage to ensure the required safety level in each environment.

2/ replace maximum allowed rate of occurrence with .... availability, reliability, integrity.

Proposed Solution (Attach pages as necessary)

1/ Although this piece of text no longer exists the sentiments are still applicable when talking about common safety objectives. This text used in that context with acceptable risk used in place of safety level for consistence with paper 21.

2/ Although this text no longer occurs the sentiment still applies in defining what form a performance requirement might take. I have therefore proposed a glossary entry to that effect for inclusion in paper 21.

Status of Comment/Action Taken (To be completed by position paper author or delegate)

Assigned to: _SG-1 _SG-2 _SG-3 _Staff _CAG _Other Comment Number:

C-Status/Action Taken:

(4)

Subject: Common Safety Objectives for ATS systems containing datalink.

Author: G Morton

1. Introduction

1.1 Product Definition

This document is a product of the Safety Objectives Group (SG2) of RTCA SC-189/EUROCAE WG-53 Air Traffic Services Safety and Interoperability Committee. Version 1 discussed the various forms that the generalised safety objectives might take in order to discuss whether such objectives meet the needs of the various actors

involved in ATS Systems.

This version defines where the resulting data should be incorporated in other documents.

2. Background

2.1 What is a safety objective?

From the OSA (described in paper 2-21) safety objectives are allocated to the various institutions making up the CNS/ATM System and Procedures developers.

Safety Objective. Mine

ED78

Slightly adapted to remove Target levels and bias on datalinks

A functional or performance requirement to be met by an element of the system in order to achieve acceptable risk of harm.

Note; Generally used at high level system considerations.

Safety objectives are derived from the operational requirements for the systesm and are used as a measure of the

acceptable risk associated with the operational use of the system. Safety requirement.

Mine

ED78

A functional or performance requirement to be met by an element of the system in order to achieve acceptable risk of harm.

Note: Generally used at lower level system considerations than safety objective.

Safety requirements include functional, perfroamnce and other requirements which are introduced to mitigate the effects of a hazard, they are derived from analysis of the operational and fucntional aspects of the system and used

throughtout the design and manufacturing process.

Performance A quantitative or qualitative measure of the ability of a system to carry out a function.

Note: Includes integrity, availability, reliability etc.

(5)

2.2 Common safety objectives

From the various OSA carried out for different environments, it may be possible to identify safety objectives or requirements that apply to more than one environment. In addition it may be possible to fix safety objectives on one institution to make it easier to allow that system element to be reused in other environments; i.e. aircraft can fly in other operational environments without having to reselect or reconfigure

systems. Alternatively to ensure the greatest uniformity possible in aircraft equipage that ensures the acceptable risk is met in each environment.

In order to achieve this, it will be necessary for the various OSA to be undertaken with consideration to other OSA to allow the maximum reuse of material and to aim at common safety objectives were possible.

Common Safety Objective (Requirement).

A Safety Objective that has been identified in a number of OSA as; necessary in more than one operational environment,

or desirable in more than one operational environment to achieve efficient

implementation. 3.0 Conclusion

This paper should be integrated into the following other documents.

First the definitions go in the glossary to paper 21 for eventual incorporation into the glossary for DO-XXX.

Second the para on harmonising / integrating / using other OSA needs to go in some as yet unwritten guidance on OSA production.