Title: DFIS - Sending both arrival and departure ATIS in a single FIS report

PDR Reference:              		M2010001
Originator Reference:            	
SARPs Document Reference:         	DFIS, Sections 2.4.4.2 and 2.4.4.3
CAMAL Document Reference:		-
P/OICS Document Reference		- 
Status:                       	        FORWARDED
Impact:					A 
PDR Revision Date:              	13/03/02 (PROPOSED -> FORWARDED)
					04/04/02 (ACCEPTED -> PROPOSED)
					23/01/02 (SUBMITTED -> ACCEPTED)
					09/01/02 (SUBMITTED)
Submitting State/Organization:    	OKI
Submitting Author Name:          	Brown, M 
Submitting Author E-mail Address:  	mark667@oki.com
Submitting Author Supplemental 
Contact Information:               	tel. 03-3452-4111 (ext. 43234)
						fax. 03-3798-7040
SARPs Date:                      	Doc 9705 Ed 3 
P/OICS Date:				- 
SARPs Language:                  	English

Summary of Defect:

The OPLINKP Manual "Manual of the ATS data link applications" (DATIS section 6.28) and SARPs section 2.4.7.2.6.2.b) state that the ground system shall be able to send an arrival ATIS AND a departure ATIS when both information are requested but the combined ATIS is not available.

The current ASN.1 allows the ground DFIS system to send a single report containing either an arrival ATIS, or a departure ATIS, or a combined ATIS.

The current ASN.1 should be changed to allow the ground DFIS system to send a block of two ATIS reports (one arrival ATIS and one departure ATIS). 

Note. This feature was present in Edition 1 but was not reproduced in Edtition 2 and 3.

Assigned SME:                    	Sub-Volume II SME

Proposed SARPs amendment: 

1/ Change in 2.4.4.2 from:

FISReportData ::= CHOICE
{
  -- Automatic Terminal Information Service (D-ATIS)
  atis             [0] ATISReport,
  ...
}

to:

FISReportData ::= CHOICE
{
  -- Automatic Terminal Information Service (D-ATIS)
  -- single report (arrival, departure, or combined)
  atis             [0] ATISReport,
  ...,
  -- Automatic Terminal Information Service (D-ATIS)
  -- double report (arrival and departure)
  blockAtis         [1] SEQUENCE SIZE (2) OF ATISReport
}

2/ Change in 2.4.4.3 from:

FISReportData ::= CHOICE
{
  -- Automatic Terminal Information Service (D-ATIS)
  atis             [0] ATISReport,
  ...
  -- Aviation routine Weather Report (D-METAR)
  metar            [1] METARReport
}

to:

FISReportData ::= CHOICE
{
  -- Automatic Terminal Information Service (D-ATIS)
  -- single report (arrival, departure, or combined)
  atis             [0] ATISReport,
  ...,
  -- Aviation routine Weather Report (D-METAR)
  metar            [1] METARReport,
  -- Automatic Terminal Information Service (D-ATIS)
  -- double report (arrival and departure)
  blockAtis         [1] SEQUENCE SIZE (2) OF ATISReport
}

Proposed CAMAL amendment:

Proposed POICS amendment:

Impact on interoperability: 		There is no impact on technical interoperability. The ASN.1 extensibility feature makes that implementations with or without this new field can interoperate. 

Operationally, the implementation of this new field is conditional in the aircraft and optional in the ground system.  The P/OICS will specify the nature of the condition : if the feature is mandatory or optional on the ground, then it is mandatory in the aircraft ; if the feature is excluded on the ground, then it is optional in the aircraft).

PDR Validation Status:			ASN.1 compilation

Discussion:

3 options are investigated: 

* Option A ("new requirement" approach) proposes to add in version 3 as an extension field a double DFIS report containing both departure and arrival ATIS reports, version 1&2 / version 3 interoperability would be guaranteed by the ASN.1 extensibility feature and chapter 8 user requirements. 

* Option B ("do nothing" approach) proposes to solve the problem by local means and procedures with no impact on the SARPs. The pilot can be requested to always ask for a specific type of ATIS. This can be easily achieved through HMI by forcing the pilot to select the type of the requested ATIS or the avionics to select a default value ('departure' before take-off, 'arrival' after take-off) if not explicit value is suppliued b the pilot. If no such automatism is implemented on-board, and if a ground receives a request it cannot comply with, the SARPs already instruct the ground to respond negatively with value "cannot comply" or "error detected in the FIS request" (current SARPs section 2.4.7.3.4).  

* Option C ("now requirement" approach) proposes to include the double DFIS report in the current specification of both versions 1 and 2. This Class A PDR would have to be implemented by all implementations. No backward compatibility is provided.

ATN SARPs are complex enough without having to make unnecessary changes. As Option B proposes an efficient "go-around" solution with no modification to the SARPs, it is proposed that the PDR status is moved to RESOLVED with Options A and B.


SME Recommendation to CCB: 		FORWARDED with

CCB Decision:                    	atnp_ccb_chair (09/01/02): SUBMITTED
						ATNP SGA2-03 (Laurel - 21/01/02): ACCEPTED
						atnp_ccb_chair (04/03/02): PROPOSED