EUROCONTROL Specification for Surveillance Data Exchange - Part 1

Transcription

1 EUROCONTROL EUROCONTROL Specification for Surveillance Data Exchange - Part 1 All Purpose Structured EUROCONTROL Surveillance Information Exchange (ASTERIX) Edition: 2.4 Edition Date: 24/10/2016 Reference nr: EUROCONTROL-SPEC-0149

2 0149 Specification Surveillance Data Exchange - Part 1 All Purpose Structured EUROCONTROL Surveillance Information Exchange (ASTERIX) EUROCONTROL Specification for Surveillance Data Exchange - Part 1 All Purpose Structured EUROCONTROL Surveillance Information Exchange (ASTERIX) DOCUMENT IDENTIFIER : EUROCONTROL-SPEC-0149 Edition Number : 2.4 Edition Date : 24/10/2016 Status : Released Issue Intended for : General Public Category : EUROCONTROL Specification Edition: 2.4 Released Issue Page 1

3 DOCUMENT CHARACTERISTICS TITLE EUROCONTROL Specification for Surveillance Data Exchange - Part 1 All Purpose Structured EUROCONTROL Surveillance Information Exchange (ASTERIX) Publications Reference: SPEC-0149 ISBN Number: Document Identifier Edition Number: 2.4 EUROCONTROL-SPEC-0149 Edition Date: 19/09/2016 Abstract This document presents the general structure of the ASTERIX format. Keywords Data Exchange Messages SAC SIC Data Category Data Field Data Block Data Item ASTERIX UAP Contact Person(s) Tel Unit Alexander Engel DPS/STAN STATUS, AUDIENCE AND ACCESSIBILITY Status Intended for Accessible via Working Draft General Public Intranet Draft EUROCONTROL Extranet Proposed Issue Restricted Internet ( Released Issue Page 2 Released Issue Edition: 2.4

4

5 DOCUMENT CHANGE RECORD The following table records the complete history of the successive editions of the present document. EDITION NUMBER EDITION DATE REASON FOR CHANGE PAGES AFFECTED Released Ed 1.0 November 1997 Adoption by the EUROCONTROL Permanent Commission Working Draft August 1998 Suppress RFS, units, add migration policy and compound data item structure. Ed 1.1 Draft Ed 1.2 October 1998 Where applicable the term Radar replaced by Surveillance Introduction amended (1) ALL X.121 reference suppressed. (2) Documents referenced in paragraph 2.2 updated (2.2) Definitions, acronyms and abbreviations updated.(3) Characteristics of the data suppressed.(4) Data item symbolic reference changed.(4) UAP unique per Category as a rule.(4) Source Identification must be present in every record.(4) Explicit Length data fields suppressed.(4) Conventions updated to be more general.(5) Annex A redesigned and changed to informative. (A) Annex B replaced by list of SACs affected to USA, Canada & Mexico. (B) Annex C suppressed. (C) Draft Ed 1.21 January reworded Explicit Length data fields re-introduced. (4) ALL Reserved Expansion field added. (4) Migration Policy reworded. (7) Page 4 Released Issue Edition: 2.4

6 EDITION NUMBER EDITION DATE REASON FOR CHANGE PAGES AFFECTED Draft Ed 1.22 March 1999 Editorial corrections ALL Proposed Ed 1.24 September 1999 Editorial corrections ALL Proposed Ed 1.26 November 2000 SAC added for UK and for Ukraine Annex A updated 6.4 A Working Draft Ed 1.27 November 2001 Editorial correction List of SAC removed Annex A updated Annex B removed A B Working Draft Ed 1.28 December 2001 Editorial corrections Annex A removed A Working Draft Ed 1.29 February 2002 Note on Reserved Expansion field added Editorial corrections Released Issue Ed 1.30 November 2007 Document ID-sheet updated Signature Page updated Status: Released Issue Draft Specification Ed 2.00 October 2012 Transposition into an EUROCONTROL Specification. Successor of EUROCONTROL Standard SUR.ET1.ST STD Introduction of the traceability to the relevant provisions of the Commission Implementing Regulation (EU) No 1207/2011 All Annex A Ed 2.1 April 2013 Chapter updated Ed 2.2 October 2014 New Record Structure Annex B Edition: 2.4 Released Issue Page 5

7 EDITION NUMBER EDITION DATE REASON FOR CHANGE PAGES AFFECTED Ed 2.3 Nov Allow virtualisation of ASTERIX Systems List of ASTERIX Categories updated Ed 2.4 Sept Clarification on blocking mechanism Clarification on List of ASTERIX Categories Annex D added Annex B Annex C Annex B Annex C Annex D Publications EUROCONTROL Headquarters 96 Rue de la Fusée B-1130 BRUSSELS Tel: +32 (0) Fax: +32 (0) publications@eurocontrol.int Page 6 Released Issue Edition: 2.4

8 CONTENTS DOCUMENT CHARACTERISTICS... 2 DOCUMENT APPROVAL... 3 DOCUMENT CHANGE RECORD... 4 CONTENTS... 7 LIST OF FIGURES... 9 LIST OF TABLES EXECUTIVE SUMMARY INTRODUCTION General Scope REFERENCES DEFINITIONS, ACRONYMS AND ABBREVIATIONS Definitions Acronyms and Abbreviations DESCRIPTION AND PRINCIPLES OF ASTERIX ASTERIX Management Procedures Maintenance of ASTERIX Documentation Endorsement of ASTERIX Documents Publication of ASTERIX Documents Organisation of the Data Data Categories Data Items and Catalogue of Data Items Data Fields User Application Profile The General Message Structure General The Data Block The Record Standard Data Field Formats Non-Standard Data Fields Reserved Expansion Data Field Field Organisation Edition: 2.4 Released Issue Page 7

9 5. CONVENTIONS Bit Numbering Binary Values Time Management ASTERIX ADDRESSING SCHEME General Syntax Formats System Area Code (SAC) System Identification Code (SIC) Assignment of the Systems Identifiers System Area Codes System Identification Codes ASTERIX MIGRATION POLICY General Description Application Domain Version Management Modifications ANNEX A Traceability between ASTERIX Specifications and Commission Implementing Regulation (EU) No 1207/2011 of 22/11/ A.1 General A.2 Compliance Matrix ANNEX B ASTERIX Categories managed by the AMG ANNEX C ASTERIX Categories coordinated with the AMG Page 8 Released Issue Edition: 2.4

10 LIST OF FIGURES Figure 1 - Organisation of the Data Figure 2 - Data Block Structure until Edition Figure 3 - ASTERIX Record Structure as of Edition Figure 4 - Standard Data Fields Types (except compound) Figure 5 - Compound Data Field Type Figure 6 - Field Sequencing Organisation Figure 7 - Overall Record Structure Edition: 2.4 Released Issue Page 9

11 LIST OF TABLES Table 1 - Compliance matrix Table 2 - ASTERIX Categories managed by the AMG Table 3 - ASTERIX Categories coordinated with the AMG Table 4 - ASTERIX Categories without Blocking Page 10 Released Issue Edition: 2.4

12 EXECUTIVE SUMMARY This EUROCONTROL specification describes the basic rules and procedures to be applied when implementing the ASTERIX data format for the transmission of surveillance related information. It provides information on the way ASTERIX data is organised, defines the structure of ASTERIX messages and specifies the format conventions to be respected when composing ASTERIX records. Finally the ASTERIX addressing scheme is defined as well as the procedure to be followed in the evolution of ASTERIX Category definitions. This EUROCONTROL specification is the successor of the EUROCONTROL Standard SUR.ET1.ST STD Edition: 2.4 Released Issue Page 11

13 1. INTRODUCTION 1.1 General This EUROCONTROL Specification describes the message structure, known by the acronym ASTERIX, originally standing for All Purpose STructured EUROCONTROL Radar Information Exchange, devised by the Study Group on the exchange of surveillance related data between processors of ATC systems. This group was a subgroup of the former Radar Systems Specialist Panel (RSSP), whose responsibilities have been taken over by the Surveillance Team (SURT) as from April ASTERIX was approved by the former RSSP at their 15th Meeting held on 1/4 July The ASTERIX Specification is now under the responsibility of the ASTERIX Maintenance Group (AMG), a working arrangement under the EUROCONTROL SUR SG. The expansion of the application domains of ASTERIX beyond radar led to a modification of the significance of the acronym ASTERIX, now standing for All Purpose STructured EUROCONTROL SuRveillance Information Exchange. Throughout this document the following conventions apply: Requirements using the operative verb "shall" must be implemented to achieve the minimum objectives of this specification. Requirements using the operative verb "should" are recommended to achieve the best possible implementation of this specification. Requirements using the operative verb "may" indicate options Page 12 Released Issue Edition: 2.4

14 1.2 Scope ASTERIX is an application/presentation protocol responsible for data definition and data assembly developed to support the transmission and exchange of surveillance related data. Its purpose is to allow a meaningful transfer of information between two application entities using a mutually agreed representation of the data to be exchanged The ASTERIX Specification (consisting of this Part 1 as well as the category definitions) refers to the Presentation and Application layers (layers six and seven) as defined by the Open Systems Interconnection (OSI) Reference Model (International Standards Organization (ISO) Standard 7498) [Ref. 1] The definition of the lower telecommunication support layers (layers one to five) is out of the scope of the ASTERIX Specification. Transmission of ASTERIX coded surveillance information can make use of any available communication medium, for instance a packet switched Wide Area Network (WAN) as well as a Local Area Network (LAN) The lower telecommunication protocol levels will be agreed between the partners of the data exchange The ASTERIX Specification, as a Presentation protocol, defines the structure of the data to be exchanged over the communication medium, from the encoding of every bit of information up to the organisation of the data within an ASTERIX Record Considering that there is information common to all systems (for instance position, Mode-A Code and Mode-C Code information), ASTERIX specifies minimum requirements at the Application level, so as to ease the data exchange between heterogeneous applications. The communication between two different systems is thus made possible, based on a core of commonly used surveillance related data, transferred in the same way by the ASTERIX Presentation layer In order to achieve the intended level of interoperability the implementation of the individual ASTERIX categories shall be performed exactly like specified in the latest editions of the respective definitions as published on the EUROCONTROL ASTERIX website ( If two users need to exchange specific information beyond the contents of the latest available definition of a category, this information shall be encoded exclusively in the Special Purpose Field as defined in below This edition of Part 1 does not apply to Categories 001, 002 and 008. The implementation of these categories shall follow the rules as described in the corresponding specifications. Edition: 2.4 Released Issue Page 13

15 2. REFERENCES 1. ISO/IEC : 1994 [ITU-Rec.X.200 (1994)] Information Processing Systems - OSI Reference Model - The Basic Model 2. Commission Implementing Regulation (EU) No 1207/2011 of 22/11/2011 laying down requirements for the Performance and the Interoperability of Surveillance for the Single European Sky Page 14 Released Issue Edition: 2.4

16 3. DEFINITIONS, ACRONYMS AND ABBREVIATIONS 3.1 Definitions For the purposes of this EUROCONTROL Specification, the following definitions shall apply: Catalogue of Data Items: List of all the possible Data Items of each Data Category describing the Data Items by their reference, structure, size and units (where applicable) Data Block: Unit of information seen by the application as a discrete entity by its contents. A Data Block contains one or more Record(s) containing data of the same Category. This principle is used until and including edition 2.1 of Part Data Category: Classification of the data in order to permit inter-alia an easy identification Data Field: Physical implementation for the purpose of communication of a Data Item, it is associated with a unique Field Reference Number and is the smallest unit of transmitted information Data Item: The smallest unit of information in each Data Category Record: A collection of transmitted Data Fields of the same Category preceded by a Field Specification field, signalling the presence/absence of the various Data Fields User Application Profile: The mechanism for assigning Data Items to Data Fields, and containing all necessary information which needs to be standardised for the successful encoding and decoding of the messages. Edition: 2.4 Released Issue Page 15

17 3.2 Acronyms and Abbreviations For the purposes of this EUROCONTROL Specification the following shall apply: ASTERIX All Purpose STructured EUROCONTROL surveillance Information EXchange AMG ASTERIX Maintenance Group ATC Air Traffic Control CAT Data Category CNS Communication, Navigation, Surveillance FRN Field Reference Number FSPEC Field Specification FX Field Extension Indicator ISO International Standards Organization LAN Local Area Network LEN Length Indicator LSB Least Significant Bit OSI Open Systems Interconnection RDE-TF Surveillance Data Exchange Task Force RE Reserved Expansion Indicator REP Field Repetition Indicator RSSP Radar Systems Specialist Panel SAC System Area Code SIC System Identification Code SP Special Purpose Indicator SUR SG Surveillance Steering-Group SURT Surveillance Team UAP User Application Profile (see Definitions) UTC Co-ordinated Universal Time WAN Wide Area Network Page 16 Released Issue Edition: 2.4

18 4. DESCRIPTION AND PRINCIPLES OF ASTERIX 4.1 ASTERIX Management Procedures Maintenance of ASTERIX Documentation Maintenance of the existing ASTERIX documents is performed by the EUROCONTROL ASTERIX team in coordination with the ASTERIX Maintenance Group (AMG). Maintenance requests (corrective or enhancive) shall be submitted to EUROCONTROL s ASTERIX Manager (asterix@eurocontrol.int). The maintenance task will be performed using collaborative tools (e.g. OneSky Team, Webex, s). As far as possible, AMG members will be asked to review and agree proposed modifications by correspondence. Stakeholders wishing to participate in the AMG should send a request by to EUROCONTROL s ASTERIX Manager (asterix@eurocontrol.int). Initially the members of the AMG were/are the members of the former surveillance Data Exchange Task Force (RDE-TF) Endorsement of ASTERIX Documents The endorsement of ASTERIX documentation is the responsibility of the AMG. Proposed editions of ASTERIX documents shall be submitted by the EUROCONTROL ASTERIX Manager to the members of the AMG for review. Following the review period the proposed edition of an ASTERIX document shall be updated by the ASTERIX Manager or the drafting group and the members of the AMG will be notified about the update Publication of ASTERIX Documents Once the ASTERIX document has been approved by the members of the AMG following the procedure outlined in above, the new edition of the document shall be published on the EUROCONTROL ASTERIX website ( for official use. Edition: 2.4 Released Issue Page 17

19 4.2 Organisation of the Data The surveillance related data exchanged between the users shall be organised as shown in Figure Data Categories The data exchanged over the communication medium between the different users shall be classified into Data Categories Those categories which define the type of data exchanged shall be standardised and be the same for all users of ASTERIX The purpose of such a classification shall be to: allow easy identification and subsequent processing of the data; facilitate the dispatching of the data to the appropriate application task in the receiving unit; Up to 256 Data Categories can be defined and their usage shall be as follows: Data Categories 000 to 127 for standard civil and military applications; Data Categories 128 to 240 reserved for special civil and military applications; Data Categories 241 to 255 used for both civil and military non-standard applications. NOTE - The up-to-date list of ASTERIX Data Categories (except for special military applications) is published on the EUROCONTROL Web Site ( Allocation of ASTERIX Categories For Data Categories 000 to 127, the allocation of category numbers is the responsibility of the AMG. ANNEX B contains a list of all ASTERIX categories assigned by the AMG at the date of publication of this specification. For all other categories coordination of the category number with the AMG is recommended in order to ensure as far as possible a unique identification of the categories. To request the allocation of a category number for a specific application, the ASTERIX Manager shall be consulted at asterix@eurocontrol.int. Further coordination will then be initiated. The detailed contents of these categories may be defined by the requesting authority following the basic principles laid down in this EUROCONTROL specification. A copy of the respective specification shall be made available to the ASTERIX Manager. ANNEX C shows a list of categories coordinated with the AMG at the date of publication of this specification. Page 18 Released Issue Edition: 2.4

20 SURVEILLANCE RELATED DATA DATA CATEGORY (1) DATA CATEGORY (2) DATA CATEGORY (n) CATALOGUE OF DATA ITEMS FOR THIS CATEGORY DATA ITEM (1) DATA ITEM (2).. DATA ITEM (p) CATALOGUE OF DATA ITEMS FOR THIS CATEGORY DATA ITEM (1) DATA ITEM (2).. DATA ITEM (q) CATALOGUE OF DATA ITEMS FOR THIS CATEGORY DATA ITEM (1) DATA ITEM (2).. DATA ITEM (r) USER APPLICATION PROFILE DATA FIELD DATA FIELD DATA FIELD DATA FIELD DATA FIELD DATA FIELD DATA FIELD DATA FIELD (1) (2) (3) (4) (5) (6) (7) (8) DATA ITEM (1) x DATA ITEM (2) x DATA ITEM (3) x DATA ITEM (4) x DATA ITEM (5)... DATA ITEM (x) x DATA ITEM (x + 1) x... DATA ITEM (q) x Figure 1 - Organisation of the Data Edition: 2.4 Released Issue Page 19

21 4.2.2 Data Items and Catalogue of Data Items A Data Item is the smallest unit of information defined and standardised. For each Data Category, a Catalogue of Data Items shall be standardised Applications involving the exchange of information out of a given Data Category, shall exclusively make use of the Data Items standardised in such Catalogue(s) of Data Items Each Data Item shall be given a unique reference which unambiguously identifies this item in the relevant catalogue The Data Item symbolic reference shall consist of an eight-character reference of the form Innn/AAA, where: I indicates that this represents a Data Item; nnn is a three digit decimal number which indicates the Data Category to which this Data Item belongs (000 to 255); AAA is a three digit decimal number which indicates the data item Where applicable, the system units shall also be standardised Data Fields For the purpose of communication, the various Data Items shall be assigned to Data Fields, each having a length of an integral number of octets and referenced by a Field Reference Number (FRN) The correspondence between Data Items and Data Fields shall be standardised for each relevant application by the User Application Profile (UAP) concerning this application User Application Profile The UAP is the mechanism whereby the correspondence between Data Items and Data Fields shall be standardised for each application making use of the ASTERIX message structure The UAP shall be considered as a control table attached to the message assembly/disassembly programs resident in the relevant processing systems. It essentially defines which of the catalogued Data Items will be used, their length (where applicable), their assignment to the Data Fields and any specific requirements which need to be standardised for the successful transmission and interpretation of the messages. NOTE - With this mechanism, it is easy to optimise the transmission efficiency without program modification by taking into account the frequency of occurrence of specific Data Items. Furthermore, it enables a choice to be made between various representations of the same logical piece of information Spare bits in the UAP shall be set to zero The UAP should be unique per Category. Note: The UAP forms an integral part of a category and is defined within the respective definition. Page 20 Released Issue Edition: 2.4

22 4.3 The General Message Structure General The application data to be transmitted over the communication medium shall consist of either one or a concatenation of consecutive Data Blocks The Data Block Until and including edition 2.1 of Part 1 of the ASTERIX documentation, a blocking mechanism may be used to combine ASTERIX record in a data block before transmission. All categories existing before the release of edition 2.2 of Part 1 (September 2014) shall continue to use the blocking principle as far as deemed appropriate. The list of categories following this procedure is available in Annexes B and C A Data Block shall consist of: a one-octet field Data Category (CAT) indicating to which Category the data transmitted belongs; a two-octet field Length Indicator (LEN) indicating the total length (in octets) of the Data Block, including the CAT and LEN fields; one or more Record(s) containing data of the same Category. NOTE - The Data Block structure is depicted in Figure Each Record is of variable length but aligned on an octet boundary. The length of a Data Block is thus variable but shall always be a multiple of an octet The maximum size of a Data Block shall be mutually agreed between data sources and users As of edition 2.2 of Part 1 of the ASTERIX documentation the principle of blocking of records shall no longer be applied. Instead each ASTERIX record shall be constructed as displayed in Figure 3. All ASTERIX categories that are created as of edition 2.2 of Part 1 of the ASTERIX documentation (October 2014) shall follow this rule when assembling the ASTERIX messages. The ASTERIX categories for which this rule applies will be listed in Annex D. For all ASTERIX categories created prior to October 2014, the blocking mechanism as described in chapter above may still be applied, even for editions of these categories that are released after this date. The list of categories following this principle are listed in Annexes B and C. Edition: 2.4 Released Issue Page 21

23 Figure 2 - Data Block Structure until Edition 2.1 Page 22 Released Issue Edition: 2.4

24 Data Item (p) Data Item (q) Data Item (r) FSPEC Data Field (1) Data Field (2) Data Field (3) Data Record CAT LEN Data Record 1 octet 2 octets ASTERIX Record Length (LEN) Data Item (s) Data Field (4) Figure 3 - ASTERIX Record Structure as of Edition 2.2 Edition: 2.4 Released Issue Page 23

25 4.3.3 The Record A Record shall contain the information of the same Data Category needed by a given application and shall consist of: a one-octet field Data Category (CAT) indicating to which Category the data transmitted belongs; a two-octet field ASTERIX Record Length Indicator (LEN) indicating the total length (in octets) of the ASTERIX Record, including the CAT and LEN fields a Data Record of variable length consisting of: a Field Specification (FSPEC) field of variable length, considered as a table of contents, in the form of a bit sequence, where every individual bit signals the presence (bit set to one) or absence (bit set to zero) of a well defined Data Field assigned to it; a variable number of Data Fields. Each Data Field is associated with one and only one Data Item, as defined by the UAP Encoding Rules For each data item the specification shall contain an Encoding Rule indicating whether a data item is mandatory or optional and the conditions under which it shall be included in the ASTERIX record The length of a Record is implicit from its structure and shall always be a multiple of an octet Standard Data Field Formats The length of Standard Data Fields shall be either fixed or variable, as defined below: Fixed length Data Fields, depicted in Figure 3, shall comprise a fixed number of octets. Extended length Data Fields, depicted in Figure 3, being of a variable length, shall contain a primary part of predetermined length, immediately followed by a number of secondary parts, each of predetermined length. The presence of the next following secondary part shall be indicated by the setting to one of the Least Significant Bit (LSB) of the last octet of the preceding part (either the primary part or a secondary part). This bit which is reserved for that purpose is called the Field Extension Indicator (FX). Explicit length Data Fields shall start with a one-octet length indicator giving the total field length in octets including the length indicator itself. Repetitive Data Fields, depicted in Figure 3, being of a variable length, shall comprise a one-octet Field Repetition Indicator (REP) signalling the presence of N consecutive sub-fields each of the same pre-determined length. Compound Data Fields, depicted in Figure 4, being of a variable length, shall comprise a primary subfield, followed by data subfields. The primary subfield determines the presence or absence of the subsequent data subfields. It comprises a first part of one octet extendible using the Field Extension (FX) mechanism. The definition, structure and format of the data subfields are part of the description of the relevant Compound Data Item. Data subfields shall be either fixed length, extended length, explicit length or repetitive, but not compound. Page 24 Released Issue Edition: 2.4

26 Figure 4 - Standard Data Fields Types (except compound) Edition: 2.4 Released Issue Page 25

27 Primary Subfield Octet No SF1 SF2 SF3 SF4 SF5 SF6 SF7 FX bits-8/2 (SF n) = 0 Absence of Subfield n = 1 Presence of Subfield n bit-1 (FX) = 0 End of Primary Subfield = 1 Extension of Primary Subfield into next octet Data Subfield No 1 Octet No.1 Octet No Item of Information Data Subfield No 7 Octet No Item of Information 7 Figure 5 - Compound Data Field Type Page 26 Released Issue Edition: 2.4

28 4.3.5 Non-Standard Data Fields There is a special feature, called Special Purpose field, allowing a user subgroup to exchange a variable length field which shall be transparent to non-interested users. It completes the ASTERIX Record assembly mechanism and is intended to provide an escape mechanism for the exceptional exchange of non-standard information. When this feature is used, a Special Purpose Indicator, (the SP-bit) shall be reserved in the FSPEC field The first octet shall contain the explicit length of the field expressed in octets and including the length indicator itself. The following Data Field may contain information such as a Data Item not defined, a text string for operator communication, test data, etc The contents of such a Data Field shall be agreed between the users concerned, while those not concerned may skip the data Reserved Expansion Data Field The Reserved Expansion Field is used only until and including Edition 2.1 of Part 1 of the ASTERIX documentation The Reserved Expansion Data field is intended to provide a mechanism to introduce intermediate changes to a given category, as explained in In a way similar to the Special Purpose mechanism, users which are not able to decode the information contained in this data field may skip the data. This feature shall be implemented in all categories referring to this edition of Part 1: at least one Reserved Expansion Indicator (RE-bit) shall be allocated in the FSPEC field The first octet shall contain the explicit length of the field expressed in octets, including the length indicator itself The contents of such a Data Field shall be agreed by the AMG When necessary, the use of the Reserved Expansion Data field, for a given category, will be described in a separate document from the ASTERIX Category definition document. This document will be available on the EUROCONTROL Web Site ( and a reference to it will be present near the appropriate ASTERIX Category definition document As of Edition 2.2 of Part 1 of the ASTERIX documentation the Reserved Expansion Field shall no longer be used. Because of the presence of the length of each individual ASTERIX record, it is possible to add new data items at the end of the UAP in order to further evolve the specification of an ASTERIX category. This makes the use of the mechanism of the Reserved Expansion Field no longer necessary. Edition: 2.4 Released Issue Page 27

29 4.3.7 Field Organisation In a Record, Data Fields shall be sent in the order of increasing FRNs The minimum length of the FSPEC field shall be one octet, which allows the composition of Records consisting of any combination of Data Fields with FRNs from one up to and including seven When Data Fields with FRNs greater than seven have to be transmitted the FSPEC extension mechanism shall be used. This is achieved by assigning a special meaning to the LSB of any FSPEC octet. The LSB, when set to one, signals the continuation of the FSPEC field with at least one further octet, until finally an octet is encountered with the LSB set to zero. The LSB in the FSPEC field is called the Field Extension Indicator (FX). NOTE - For illustrative purposes two examples of Record Structures are shown in Figure 5. The first example contains a Record with a single-octet FSPEC, whereas the second one highlights a case with a multi-octet FSPEC In order to illustrate all elements of ASTERIX Record composition an example is depicted in Figure 6 where FSPEC bit-14 is dedicated to the SP feature. Page 28 Released Issue Edition: 2.4

30 STRUCTURE OF THE FIELD SPECIFICATION (FSPEC) bit 1 bit 2 bit 3 bit 4 bit 5 bit 6 bit 7 bit 8 bit 9 bit 10 bit 11 bit 12 bit 13 bit 14 bit 15 bit 16 F1 F2 F3 F4 F5 F6 F7 FX F8 F9 F10 F11 F12 F13 F14 FX etc F1 to F7: FIELD PRESENCE INDICATOR = 0 Data Field not present = 1 Data Field present FX : FIELD EXTENSION INDICATOR = 0 No Field Specification extension = 1 Following octet contains a Field Specification extension EXAMPLE OF ONE-OCTET FSPEC F1 F2 F3 F4 F5 F6 F7 FX DATA FIELD (1) DATA FIELD (4) DATA FIELD (7) FSPEC RECORD EXAMPLE OF A MULTI-OCTET FSPEC F F F F F F F F F F F F F F F F F F F F F F F F X X X DATA FIELD (1) DATA FIELD (5) DATA FIELD (9) DATA FIELD (20) FSPEC RECORD Figure 6 - Field Sequencing Organisation Edition: 2.4 Released Issue Page 29

31 Figure 7 - Overall Record Structure Page 30 Released Issue Edition: 2.4

32 5. CONVENTIONS 5.1 Bit Numbering All bit positions within a one octet field shall be numbered right to left from one to eight For a field consisting of n octets (with n>1): the octets shall be numbered left to right from one to n; the bit positions shall be numbered right to left from one to n x With an FSPEC field the following exceptions for bit positions shall apply: in a one-octet FSPEC the bits will be numbered left to right from one to eight; in a FSPEC consisting of p octets (with p>1) the bits will be numbered left to right from one to px Data shall be presented to the application at the receiving end in the same order as generated at the transmitting end. 5.2 Binary Values Negative values shall be represented in two's complement form. 5.3 Time Management Time stamping shall be expressed as Co-ordinated Universal Time (UTC). Edition: 2.4 Released Issue Page 31

33 6. ASTERIX ADDRESSING SCHEME 6.1 General 6.2 Syntax In order to avoid ambiguity, every system shall have a unique identification in an area where ASTERIX is used for the exchange of data. To allow for flexible adaptation of the system configuration to user requirements, virtualisation of an ASTERIX system shall be permitted resulting in the allocation of more than one SIC to a physical ASTERIX system. The allocation of the SAC remains the responsibility of the AMG. The ASTERIX System Identifier format shall be composed of two subfields as illustrated below: SAC SIC Field Name Element Type Field Size 6.3 Formats SAC System Area Code Binary One octet SIC System Identification Code Binary One octet System Area Code (SAC) The SAC field shall consist of an eight-bit number assigned to a geographical area or a country The SAC field format shall be as illustrated below: b b b b b b b b where b represents a binary digit System Identification Code (SIC) The SIC shall consist of an eight-bit number assigned to every system (surveillance station, processing system, server, etc.) located in the geographical area or country defined by the SAC. In case of virtualised surveillance systems, more than one SIC may be assigned to the same physical system The SIC field format shall be as illustrated below: b b b b b b b b where b represents a binary digit. Page 32 Released Issue Edition: 2.4

34 6.4 Assignment of the Systems Identifiers System Area Codes One SAC should be assigned to each country. NOTE - When needed, more than one SAC may be assigned to a single country, for example to differentiate between civil and military applications Assignment of SACs shall be co-ordinated by the AMG. NOTE - The up-to-date list of SACs is published on the EUROCONTROL Web Site ( System Identification Codes The individual SICs shall be assigned by the State concerned within the area identified by the SAC applying national arrangements. In case of virtualisation of ASTERIX Systems, more than one SIC may be allocated to the physical system Within one geographical area or country identified by a SAC, up to 256 individual codes (SICs) can be assigned. Edition: 2.4 Released Issue Page 33

35 7. ASTERIX MIGRATION POLICY 7.1 General The ASTERIX migration policy allows the co-existence and support of two or even more consecutive versions of a particular part of the EUROCONTROL Specification for Surveillance Data Exchange. It shall be applicable to standard categories, within the range Description Application Domain The ASTERIX format can be used to convey various information related to surveillance. An application domain is a particular application of ASTERIX, such as the transmission of mono-surveillance target reports or the transmission of monosurveillance service messages The ASTERIX migration policy allows the definition of 32 application domains that shall be identified by an initial Category number between 0 and 31. Each application domain shall be described in one and only one part of the ASTERIX Specification Version Management For a given application domain, the version of the corresponding Category definition shall be identified by its reference number and its edition date. In order to avoid any mis-interpretation of data, any new version of a part shall be allocated a Category number different from the previous one, according to the rule below: NOTE - Cat(N+1) = ( Cat(N) + 32 ) Mod 128 This approach allows the coexistence of up to four versions of a same part Recommendation In order to limit the number of simultaneous versions of a same part, the publication of a subsequent version should not be within a timelapse of typically five to ten years. Page 34 Released Issue Edition: 2.4

36 Example of Monoradar Service Messages Exceptions This application domain covers sector crossing and other messages used to provide information on the status of a Primary, Secondary or Mode S radar station. It is described in detail in Part 2b. The initial Category number allocated to this application domain is 002. The next version of this Category will be Category 034, followed by versions 066, 098 and then returning again to 002. On the basic premise that a version is applicable for ten years, this will provide half a century for the old Category 002 to disappear before a new version with the same Category number is created Categories 000 and 032 There will not be any subsequent versions of Category 000. Therefore, Category 032 is not the next version of Category 000, but is related to a different application domain. The next versions of Category 032 will be 064, 096 and then again Monoradar Target Reports: Categories 001, 016 and 048 This application domain covers the messages carrying plots and tracks issued by Primary, Secondary and Mode S radar stations. The initial Category number allocated to this application domain was 001. As primary and non-mode S secondary stations were already operational while Mode S was still under development, it was decided to split this application domain into two separate categories: 001 for primary and non-mode S secondary surveillance, and 016 for Mode S surveillance. As Mode S is now a mature technology, the decision was taken to combine all monoradar target reports into a single category, category 048, which is the next version of both categories 001 and 016. The next versions of category 048 will be 080, 112, 016 and then again 048. Edition: 2.4 Released Issue Page 35

37 7.2.3 Modifications Modifications to existing categories shall be performed in a way that interoperability is maintained ( backwards compatibility ). This rule shall be respected to the maximum extent possible, but can only be guaranteed to specifications which have reached the status Released Issue. For documents in status Working Draft or Draft backwards compatibility cannot be guaranteed as they are still under development and may need to be modified substantially during this process. Implementing ASTERIX categories that are not yet released is at the risk of the implementer Modifications, which would result in non-interoperable implementations, shall be withheld and collected during a five to ten years period for implementation in the next version, which then re-uses the eldest Category number from the cyclic pool Recommendation Minor modifications, not leading to interoperability problems, should be implemented at intermediate points in time (in the last version, thus not creating a new version). NOTE - In ASTERIX categories defined before edition 2.2 of Part 1 of the ASTERIX specification, the Reserved Expansion Field feature provides an escape mechanism to introduce modifications at an early stage, before proceeding to a new version. Page 36 Released Issue Edition: 2.4

38 ANNEX A Traceability between ASTERIX Specifications and Commission Implementing Regulation (EU) No 1207/2011 of 22/11/2011 A.1 General Commission Implementing Regulation (EU) No 1207/2011 of 22/11/2011 lays down requirements for the performance and interoperability of surveillance for the Single European Sky. ASTERIX as data format for the exchange of surveillance related data is fully consistent with the relevant requirements of the Regulation therefore it may be used by the stakeholders in the implementation of these requirements. In order to facilitate the implementation as well as the demonstration of compliance, Annex A.2 provides the traceability between the relevant regulatory requirements and content of the ASTERIX Specification. To be considered compliant with the interoperability requirements of the regulation the basic principles as laid down in Part 1 of ASTERIX have to be respected and the ASTERIX categories have to be implemented as described in the respective definitions. To be compliant with the interoperability requirements of the regulation it is assumed that the appropriate surveillance infrastructure has been implemented. Edition: 2.4 Released Issue Page 37

39 A.2 Compliance Matrix Commission Implementing Regulation (EU) No 1207/2011 Regulatory Requirements ASTERIX Requirements Generic interoperability requirements As attachments to this EUROCONTROL specification, the ASTERIX category definitions (containing the detailed format descriptions of the various ASTERIX categories) are considered as Means of Compliance to Commission Regulation No 1207/2011 only as long as they are implemented following the version as published on the ASTERIX website. ( Annex III: Surveillance data exchange requirements referred to in Article 5(1): Identification of data source Annex III: Surveillance data exchange requirements referred to in Article 5(1): Identification of the type of data Annex III: Surveillance data exchange requirements referred to in Article 5(1): Time stamping requirements Data source identifier (SAC/SIC) present in all ASTERIX categories. Category indication present in all ASTERIX blocks. Time of Day (expressed in UTC) present in all ASTERIX categories. Table 1 - Compliance matrix Page 38 Released Issue Edition: 2.4

40 ANNEX B ASTERIX Categories managed by the AMG The following table contains a list of ASTERIX categories in the standard range (0 127) and the purpose for which they are assigned. This list reflects the status at the date of publication of this specification. For the latest available information please refer to EUROCONTROL s ASTERIX website at For all categories listed in this Annex, the blocking mechanism as described in chapter above may be applied. Category Application 000 Time Synchronisation Messages 001 Monoradar Target Reports 002 Monoradar Service Messages 003 Air Traffic Situation Picture 004 Safety Net Messages 007 Directed Interrogation Messages 008 Monoradar Weather Data 009 Composite Weather Reports 010 Monoradar Surface Movement Data 011 SMGCS Data 017 Mode S Surveillance Coordination Function Messages 018 Mode S Data Link Function Messages 019 Multilateration System Status Messages 020 Multilateration Target Reports 021 ADS-B Reports 022 TIS-B Management Messages 023 CNS/ATM Ground Station Service Messages 024 ADS-C Messages 025 CNS/ATM Ground System Status Reports 032 Data provided by Users to an SDPS 034 Monoradar Service Messages (Successor of category 002) 048 Monoradar Target Reports (Successor of category 001) 061 SDPS Session and Service Control Messages 062 System Track Data 063 Sensor Status Messages 065 SDPS Service Status Messages Table 2 - ASTERIX Categories managed by the AMG Edition: 2.4 Released Issue Page 39

41 ANNEX C ASTERIX Categories coordinated with the AMG The following ASTERIX categories, outside the standard range of categories, have been coordinated with the AMG and their evolution will be agreed with the AMG. This list reflects the status at the date of publication of this specification. For the latest available information please refer to EUROCONTROL s ASTERIX website at For all categories listed in this Annex, the blocking mechanism as described in chapter above may be applied. Category Application 128 C 3 I Messages 150 Flight Data Messages 151 Association Messages 152 Time Stamp Messages 153 Special Purpose Messages 204 Recognised Air Picture 239 Foreign Object Debris Detection System 240 Radar Video Transmission 247 Version Number Exchange 251 Supplemental Data (Birdtam) 252 Session and Service Control Messages 253 Remote Station Monitoring and Control Information Table 3 - ASTERIX Categories coordinated with the AMG Page 40 Released Issue Edition: 2.4

42 ANNEX D ASTERIX Categories without Blocking The following ASTERIX categories will follow the provisions of chapter above, which means that it is not allowed to combine multiple ASTERIX records in a single block. For the latest available information please refer to EUROCONTROL s ASTERIX website at Category Application 015 Independent Non-Cooperative Surveillance Systems (reserved) 238 Service Prediction Reports Table 4 - ASTERIX Categories without Blocking Edition: 2.4 Released Issue Page 41

43 EUROCONTROL November 2016 European Organisation for the Safety of Air Navigation (EUROCONTROL) This document is published by EUROCONTROL for information purposes. It may be copied in whole or in part, provided that EUROCONTROL is mentioned as the source and it is not used for commercial purposes (i.e. for financial gain). The information in this document may not be modified without prior written permission from EUROCONTROL.