Introduction

This site contains the Product Identification Registration function for Flight Information Services-Broadcast (FIS-B), an automated, digital data link system.  The system will provide non-control, advisory information needed by pilots to operate more safely and efficiently in the National Airspace System and in international airspace.  FIS provides to pilots the necessary weather graphics and text, Special Use Airspace (SUA) information, Notices to Airmen (NOTAMs), and other information. 

The purpose of this site is to provide the means to manage FISDL product identifiers throughout their lifecycle.  Products under development will be issued ids to indicate they are developmental, not operational, products.  When a product developer has obtained operational status for a product, it will be given a unique operational id.

Participants must register before they can enter this site.

System Overview

An operational FIS-B system architecture includes the five processes or functions illustrated in Figure 1.  These are:  

(1)     collection of FIS source information from various sources;

(2)     processing and formatting the data where appropriate into FIS-B products;

(3)     processing (and segmenting) FIS-B products into APDUs for data link transmission;

(4)     broadcasting the digitally-coded data into coverage volumes in the airspace; and

(5)     receiving, decoding and displaying the data by avionics onboard the aircraft for the

         pilot’s review or other applications. 

 

Figure 1 illustrates the FIS-B architecture from a protocol stack view.  Both the hardware/processing view and protocol stack views are intended to be notional, that is, they do not place requirements on specific ground or avionics implementations. 

Top

Figure 1 FIS-B Data Link System

FIS-B data link systems use a one-way broadcast protocol.  It is “one-way” in the sense that information flows only from the server to the receiving aircraft without the need for the aircraft to request information from the server, nor to acknowledge receipt.  It is typically “non-addressed” in the sense that information provided by the server is not addressed to a specific aircraft, but is rather intended for the benefit of any aircraft that may be in the coverage volume.  These characteristics make the broadcast protocol well suited to provide information that is of interest to a large portion of the aircraft in the coverage volume.  In addition, the simplicity of the protocol translates into lower costs for both avionics and ground infrastructure.

Referring to step 4 of Figure 1, the basic concept is that servers will repetitively broadcast a wide assortment of FIS data into their coverage volumes.  The servers cannot know if all the aircraft receiving the broadcast captured all the data without error, or would they know when additional aircraft enter the coverage volume and are in need of information.  The key to the operational effectiveness of FIS-B is to ensure that the scope of the product list and the repetition intervals of the products are suited to the needs of the users in the broadcast coverage volume.

In describing the primary functions of the FIS-B avionics, it is helpful to group them into continuous and discrete functions.  When within the coverage volume, FIS-B avionics would be expected to monitor the FIS-B frequency (or frequencies) to receive, decode, and store data as the broadcast server issues them.  The FIS-B avionics would also be expected to automatically manage the contents of an onboard FIS database in which the received data are stored.  Such management functions would include sorting the data for later retrieval by the pilot or other applications, purging old information that no longer applies and passing information directly to the pilot.  It is assumed that these functions would operate more-or-less continuously in the background without any need for direct pilot management.

The more discrete functions of the FIS-B avionics are those associated with the interaction between the database and the pilot (through some form of I/O device) or another application.  They are discrete in the sense that they are usually prompted by an action of the pilot (or application).  An example is a pilot-initiated query of the database to obtain the latest surface observation for an airport of interest.  Another example would be the query of the database by an application to portray weather graphics on a moving map display.

Top 

Background

This part of introduction provides background on the FIS-B Product Registry.  The FIS-B Product Registry provides a publicly accessible source for listing the Product Identifiers contained in an APDU Header along with the description of the APDU Payload encoding for the associated FIS-B Product Files.

The APDU is comprised of two elements; the APDU Header followed by the APDU Payload.  The APDU Header fields contain information necessary for the receiving avionics to process, store, and display an FIS-B Product File contained in the APDU Payload.  The APDU Payload fields contain all or segmented portions of an FIS-B Product File.

This FIS-B Product Registry may be used by any data link communications service that employs the APDU format specified in this MASPS. The FIS-B Product Registry contains the following key items:

1.      Product Identifier listing.  The Product Identifiers are a data field in the Product Descriptor Field in the APDU Header

2.      APDU Payload encoding (or reference source for propriety products) for the associated FIS-B Product Files

3.      FIS-B data link listing of all registered networks that are using the APDU format.

4.   Application procedures for requesting additions or updates to the FIS-B Product Registry.

Top

Last Updated: April 29, 2008