Attachment 3 - Draft SIR - Section J - SMR4 to Surface Surveillance System IRD.v3.1 (Release).docx

Federal Aviation Administration

Interface Requirements Document Surface Movement Radar, Model 4 (SMR4) To Airport Surface Detection Equipment, Model X (ASDE-X) and Airport Surface Surveillance Capability (ASSC) NAS-IR- nnnnnnnn June 28, 2022

DRAFT

Approval Signatures

Revision Record

Table of Contents

List of Figures

List of Tables

DRAFT

Page v Scope This IRD provides the design requirements for the interface between the Surface Movement Radar, Model 4 (SMR4) and the FAA Surface Surveillance System (SSS) – including both Airport Surface Detection Equipment, Model X (ASDE-X) and Airport Surface Surveillance Capability (ASSC). This interface uses the ASTERIX formatted messages for all communications. Changes in the interface require coordination among all recipients.

Summary The ASDE-3 Surface Movement Replacement (3SR) program will replace the ASDE-3 radars in the NAS with a newly acquired radar known as SMR4.

ASTERIX messages are exchanged between the systems on two redundant Local Area Network (LAN) interfaces. Figure 11 depicts the general architecture of the interface between the SMR4 and the Surface Surveillance System. Both systems are responsible for maintaining the redundant interface link to ensure reliable communications between the systems.

The simplified network interfaces shown are for informational purposes only as they are not within the scope of this document.

DOCUMENTATION NOTES:

· In this document, “must” indicates a mandatory requirement.

· In this document, “may” and "should" indicates a desirable but not mandatory function or characteristic.

· In this document, text denoted by “Note” is explanatory and editorial and is not part of the interface requirements.

· In this document, “Surface Surveillance System” or “SSS” refers to both ASDE-X and ASSC.

· Appendix B contains a Verification Requirements Traceability Matrix.

Figure 11: SMR4 to Surface Surveillance System Configuration System Responsibility List The following subsystems are affected by this IRD:

Table 11: System Responsibility List

Applicable Documents The following documents form a part of this IRD to the extent specified herein. In the event of conflict between the documents referenced herein and the contents of this IRD, this IRD will be considered the superseding requirement.

Government Documents

Non-Government Documents

Document Sources Electronic Industries Alliance Documents Copies of Electronic Industries Alliance (EIA) standards may be obtained from the Electronic Industries Alliance, Technology Strategy and Standards Department, 2500 Wilson Boulevard, Arlington, VA 22201-3834, or by calling (703) 907-7500, or through their web site at http://www.ecianow.org/.

ISO/IEC Documents Copies of International Standards Organization (ISO)/International Electrotechnical Commission (IEC) documents may be obtained from American National Standards Institute, 11 West 42nd Street, 13th Floor, New York City, NY 10036. Telephone: (212) 642-4900, Telefax: (212) 398-0023, Email: info@ansi.org Web sites: http://www.ansi.org or http://www.iso.org IEEE/ANSI Documents Copies of Institute of Electrical and Electronics Engineers (IEEE)/American National Standards Institute (ANSI) documents may be obtained from IEEE Computer Service, 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ 08855-1331, or by calling (800) 701-4333 (in the U.S. and Canada), or (732) 981-0060 (outside of the U.S. and Canada), or through their standards web site at: http://www.ieee.org/web/standards/home/index.html IETF Standard (RFC) Documents Copies of the Internet Engineering Task Force (IETF) Standard (RFC) documents may be obtained through the web site: http://www.rfc-editor.org/rfc-index2.html EUROCONTROL Documents Copies of EUROCONTROL documents may be obtained through the web site: http://www.eurocontrol.int/services/specifications-documents

Interface Requirements General Requirements This IRD provides the requirements for the SMR4 interface with the FAAs Surface Surveillance Systems. Unless otherwise specified, all requirements apply to both the SMR4 and the Surface Surveillance System.

This is a system-to-system interface using the transmission of ASTERIX Data using Internet Protocol (IP). See: http://www.eurocontrol.int/asterix. Therefore, no human system interface requirements are included. The interface provides a fully redundant physical link between the SMR4 and the Surface Surveillance System as illustrated in Figure 11. The design provides for the following:

· A two-way interface between the SMR4 and the ASDE-X system, or between the SMR4 and the ASSC system for the exchange of Target Data, Status Messages, and Control Messages.

· The data is provided on redundant LAN interfaces.

The I/O panels at the top of the Surface Surveillance System is the point of demarcation between the SMR4 and the Surface Surveillance System. The SMR4 is responsible for all connections and cables up to the I/O panel. The networks are cross connected via direct on-site cable.

The SMR4 system will incorporate redundant LANs to interface to the Surface Surveillance System redundant LANs. Each system’s online operational channel will send identical data on both LAN interfaces to the collocated system via the direct LAN interface. If a standby channel is available, neither system’s standby channel will send data on the interface.

[SMR4-IRD001] ASTERIX messages must be in accordance with the EUROCONTROL Specification for Surveillance Data Exchange - Part 1 All Purpose Structured EUROCONTROL Surveillance Information Exchange (ASTERIX), EUROCONTROL-SPEC-0149, Edition 3.1 dated 11/23/2021.

[SMR4-IRD002] Surveillance data messages must be formatted as ASTERIX Category 010 Monosensor Surface Movement Data messages (CAT10) in accordance with the EUROCONTROL Category 010 Specification, SUR.ET1.ST05.2000-STD-07-01, Edition 1.1, dated 27 March 2007.

[SMR4-IRD003] Video messages must be formatted as ASTERIX Category 240 Radar Video Transmission messages in accordance with the EUROCONTROL ASTERIX Category 240 Specification, EUROCONTROL-SPEC-0149-240, Edition 1.3, dated 13/05/2015.

[SMR4-IRD004] Monitoring and Control Messages must be formatted as ASTERIX Category 253 Remote Monitoring and Control messages in accordance with the EUROCONTROL Category 253 Specification, Edition 11, dated 08 February 2021.

Security Requirements Protection for the interface is provided through the physical and personnel security measures in accordance with the National Institute of Standards and Technology (NIST) Recommended Security Controls for Federal Information Systems and Organizations 800-53 rev 4. Security requirements are defined in the System Specifications for the SMR4, ASDE-X, and ASSC.

Functional Requirements Functional Design Requirements Table 31 summarizes the data flow between the SMR4 and the Surface Surveillance System.

Table 31: ASTERIX Message Type by Source

Application Processes and Message Requirements The SMR4 and the Surface Surveillance Systems have one or more applications that provide for the transmission and reception of the radar and control messages to the collocated system. The details of each system’s application are within their respective System Design documents.

Identification of Each Application Process [SMR4-IRD005] Destination multicast addresses must be site adaptable for each LAN interface.

[SMR4-IRD006] Transport layer port numbers must be site adaptable for each data stream.

[SMR4-IRD007] Data Streams must be transmit using the delivery scheme shown in Table 32.

Table 32: Data Streams – SMR4 Source

Application Process Capability Requirements The SMR4 and Surface Surveillance System application processes are still held to their respective accuracy, throughput, latency, and availability requirements. The details of each system’s application are within their respective System Design documents.

[SMR4-IRD008] The SMR4 must only pass incoming data with approved source IP addresses, destination IP addresses, protocols, and port numbers.

[SMR4-IRD009] The SMR4 must log occurrences of reception of unapproved source IP addresses, destination IP addresses, protocols, and port numbers.

[SMR4-IRD010] The SMR4 must block incoming Transmission Control Protocol (TCP) connection attempts from unapproved IP addresses and port numbers.

[SMR4-IRD011] The SMR4 must log incoming TCP connection attempts from unapproved IP addresses and port numbers.

Message Content Requirements The SMR4 outputs and the Surface Surveillance System’s receives and process radar data in accordance with Section 3.1 .

Common ASTERIX Message Requirements The following requirements apply to all categories of ASTERIX identified in this IRD.

[SMR4-IRD012] ASTERIX Data Blocks must be generated with a site adaptable maximum size of up to 1494 bytes.

Note: The max packet size is 1500 bytes. This requirement is for the Application Layer and the Presentation Layer adds 6 bytes for the Sequence Number and CRC-32.

[SMR4-IRD013] The ASTERIX Data Block must be defaulted to a maximum size of 506 bytes.

[SMR4-IRD014] All spare bits in an ASTERIX Record must be set to zero.

[SMR4-IRD015] Data Item applicability for an ASTEREX record must be determined as described in Table 36 through Table 38.

[SMR4-IRD016] ‘Compulsory’ Data Items must be included in every ASTERIX Record.

[SMR4-IRD017] ‘Compulsory if available’ Data Items must be included in an ASTERIX Record when data is available.

[SMR4-IRD018] ‘Not used’ Data Items must be excluded from an ASTERIX Record.

[SMR4-IRD019] Data Items identified in the Field Specification (FSPEC) of each ASTERIX Record which are compliant with ASTERIX Category’s UAP must be parsed.

[SMR4-IRD020] All ASTERIX messages must be timestamped with an accuracy of less than or equal to 10 milliseconds relative to Coordinated Universal Time (UTC) time.

[SMR4-IRD021] The SMR4 must prioritize the order of message transmission using the following prioritization: 1. Cat010 North Marks 2. Cat010 Target Reports 3. Cat010 Operational Status 4. Cat240 Monobit Video 5. Cat253 Detailed Status Report ASTERIX Category 10 Message Requirements [SMR4-IRD022] The SMR4 must populate Category 010 ASTERIX messages in accordance with Table 36.

[SMR4-IRD023] The Surface Surveillance System must receive Category 010 ASTERIX messages in accordance with Table 36.

SMR4 Target Report [SMR4-IRD024] The SMR4 must output Target Reports to the Surface Surveillance System as Category 010 ASTERIX messages.

[SMR4-IRD025] The SMR4 Time of Day for a Target Report must be the time that the antenna is pointed at the calculated target boresight azimuth.

[SMR4-IRD026] The SMR4 must use True North as Local Geographical North for all Target Reports using an azimuth reference.

[SMR4-IRD027] The SMR4 must provide the measured plot position without extrapolation for all Target Reports providing a position.

[SMR4-IRD028] The SMR4 must populate Data Item I010/042 (Position in Cartesian Coordinates) with the measured plot position centroid using Cartesian Coordinates expressed in the Radar Plane.

[SMR4-IRD029] The SMR4 must set Data Item I010/170 (Track Status) CST field (Bits 5 and 6) to a value of 0.

[SMR4-IRD030] The SMR4 must set Data Item I010/170 (Track Status) TCC field (Bit 3) to a value of 0.

[SMR4-IRD031] The SMR4 must set Data Item I010/170 (Track Status) STH field (Bit 2) to a value of 0.

[SMR4-IRD032] The SMR4 must include the information from Table 33 in Data Item I010/SP (Special Purpose) for each target plot and for each primitive associated with the target plot.

Table 33: SMR4 Plot Data

SMR4 North Mark [SMR4-IRD033] The SMR4 must output North Marks to the Surface Surveillance System as Category 010 ASTERIX messages.

[SMR4-IRD034] The SMR4 Time of Day for a North Marker must be the time that the face of the antenna is pointed at True North.

SMR4 Operational Status Report [SMR4-IRD035] The SMR4 Operational Status Report musts be formatted as ASTERIX Category 010 Periodic Status Messages.

[SMR4-IRD036] The SMR4 must populate I010/550 (System Status) NOGO Field (bits 7 and 8) based on the overall SMR4 summary state.

ASTERIX Category 240 Message Requirements (SMR4 Monobit Video) [SMR4-IRD036] The SMR4 must populate Category 240 ASTERIX messages in accordance with Table 37.

[SMR4-IRD037] The Surface Surveillance System must receive Category 240 ASTERIX messages in accordance with Table 37.

[SMR4-IRD038] The SMR4 must output processed Monobit Video to the Surface Surveillance System as Category 240 ASTERIX messages.

ASTERIX Category 253 Message Requirements [SMR4-IRD039] Category 253 ASTERIX messages must be populated in accordance with Table 38.

[SMR4-IRD040] Category 253 ASTERIX messages must be received in accordance with Table 38.

SMR4 Detailed Status Report [SMR4-IRD041] The SMR4 must output a Detailed Status Report to the Surface Surveillance System at a rate of once per second.

[SMR4-IRD042] At a minimum, the SMR4 detailed Status Report must contain the information indicated in Table 34.

Table 34: SMR4 CAT253 Detailed Status Report

· Transceiver Performance Monitor

· Antenna Performance Monitor

· Processor Performance Monitor

Surface Surveillance System [SMR4-IRD043] The Surface Surveillance System must send a System Status message to the SMR4 at a rate of once per second.

[SMR4-IRD044] The Surface Surveillance System Status message must be formatted as Category 253 ASTERIX messages.

[SMR4-IRD045] The Surface Surveillance System must send command and control messages to the SMR4 as Category 253 ASTERIX messages.

[SMR4-IRD046] The Surface Surveillance System must send Closed Region messages to the SMR4 as Category 253 ASTERIX messages.

The Surface Surveillance System provides command and control of the SMR4 will be documented in the SMR4 to Surface Surveillance System Interface Control Document (ICD). Table 35 includes the minimum subset of commands that are expected to be included in the design.

Table 35: SSS CAT253 Command Examples

User Application Profile and Standard Data Items ASTERIX messages are allocated to a Standard User Application Profile (UAP) consisting of Data Fields. Data Fields within an ASTERIX message are associated with a Field Reference Number (FRN) and are populated with Data Items. The UAP can be considered a control table attached to the message assembly/disassembly program resident in the processing system. Some Data Items are compulsory while others are optional. At transmission time, not all the Data Fields (Data Items) need be output.

The following tables define the Standard Data Items for ASTERIX Categories 010, 240 and 253. Each Data Item is defined as Compulsory (C), Compulsory if Available (C/A), Optional (O) or Not Used (X) which are defined in Section 6.1.

Category 010 (Surface Movement Data) UAP The Category 010 data sent from the SMR4 to the Surface Surveillance System includes Target Reports, North Marks, and Operational Status. SMR4 Category 010 Surface Movement Data will be formatted as defined in the following table.

Table 36: SMR4 Cat010 User Application Profile and Construction

Compulsory: (C) Compulsory if Available: (C/A) Optional: (O) Not Used (X)

· 1I010/270 Orientation is optional.

Category 240 (Radar Video Transmission Messages) UAP SMR4 Category 240 Radar Video Transmission Messages must be formatted as defined in the following tables.

Table 37: Cat240 SMR4 Radar Video Transmission UAP

Compulsory: (C) Compulsory if Available: (C/A)

Video Summary Message Video Message

· 1Either Item I240/040 or I240/041 must be present in each Video Message

· 2Either Item I240/050 or I240/051 or I240/052 must be present in each Video Message

Category 253 (Monitoring and Control Messages) UAP SMR Category 253 Monitoring and Control messages will be formatted as defined in the following tables.

Table 38: Cat253 Monitoring and Control Messages UAP

Compulsory: (C) Compulsory if Available: (C/A)

System Status Message

Relationship among Messages

Quality of Service Requirements The Quality of Service requirements, including accuracy, throughput, latency and availability requirements are specified within the FAA-E-XXXX SMR4 specification.

Error Handling Requirements The following represent requirements of the application error handling for processed Data Units.

[SMR4-IRD047] The Surface Surveillance System must detect degradation in SMR4 data latency using ASTERIX Records that contain a valid Time of Day Data Item.

[SMR4-IRD048] The Surface Surveillance System must discard duplicate packets detected using the Sequence Number embedded in the Data Unit.

[SMR4-IRD049] The Surface Surveillance System must report discontinuity in Sequence numbers in the monitoring of the Surveillance Data not attributed to Surveillance System channel reconfiguration or system cold/warm starts.

Note: If the SMR4 uses multiple channels, the SMR4 does not need to synchronize Sequence Numbers between channels since the Source IP address will be different for each channel. Discontinuity in sequence numbers can either be from missing or out of order packets.

[SMR4-IRD050] ASTERIX Records must be validated using the CRC-32 embedded in the Data Unit.

[SMR4-IRD051] ASTERIX Records must be validated using the Length contained in the ASTERIX Data Block.

[SMR4-IRD052] Invalid ASTERIX Records must be discarded as determined by the ASTERIX Data Block CRC-32 and Length.

[SMR4-IRD053] The Surface Surveillance System must report discarded ASTERIX Records in the monitoring of the Surveillance Data.

[SMR4-IRD054] ASTERIX Records that contain ‘Not Used’ Data Items must be accepted.

Interface Summary Table Table 31 in Section 3.2 summarizes the data flow between the SMR4 and the Surface Surveillance System.

Protocol Implementation The local IP-Based network between the SMR4 and the Surface Surveillance System consists of direct (point-to-point) LAN connectivity between the two systems and provides IP Services per FAA-STD-039C standard titled: “National Airspace System (NAS) Open System Architecture and Protocols.” The communications protocols allow computers from different vendors, using different operating systems, to exchange data. This data transfer is accomplished over data networks using various protocols. The complete set of protocols necessary for such communication is referred to as a protocol suite. This IRD references requirements to the Open Systems Interconnection (OSI) 7-layer model, as shown in Figure 31.

Figure 31: OSI 7 Layer Model Application Layer Service An ASTERIX Record encodes the information of a single Radar Target or a single Service Message. A unique SIC/SAC is assigned to each radar site and is utilized in all ASTERIX Records sent on the interface.

The ASTERIX Data Block supports the packing of multiple ASTERIX Records of the same type per ASTERIX construction rules in the Eurocontrol document Part 1 All Purpose Structured EUROCONTROL Surveillance Information Exchange (ASTERIX), EUROCONTROL-SPEC-0149, Edition 3.1 dated 11/23/2021. The Data Unit will only contain one ASTERIX Data Block.

[SMR4-IRD055] The SMR4 must have a site adaptable SIC code for Surveillance Data output on the interface.

[SMR4-IRD056] The SMR4 must have a site adaptable SAC code for Surveillance Data output on the interface.

[SMR4-IRD057] The entire ASTERIX Record which is compliant with ASTERIX Category’s UAP must be parsed.

[SMR4-IRD058] Each Data Item indicated by the ASTERIX Category’s UAP must be parsed.

[SMR4-IRD059] The Surface Surveillance System must be coded such that valid ASTERIX formatted messages will not cause a fault.

Note: This condition can occur if the radar software has been upgraded and the new software reports a FRN that the UAP designates as 'not used' for that radar type.

[SMR4-IRD060] When recording SMR4 Surveillance Data messages, the Surface Surveillance System must record all Data Items in the ASTERIX Record even if the Data Item is not used.

Presentation Layer Each ASTERIX Category packet data is preceded by a 2-byte unsigned sequence number and followed by a 4-byte dCRC-32 as illustrated in Figure 32. The sequence number is independently incremented for each port and wraps to zero after counting to 65535.

Figure 32: Presentation Layer Data Unit The Data Unit serves the following functions:

· Applies a unique number to each packet for determining if packets are lost between the SMR4 and the Surface Surveillance System.

· Provides error detection of the application elements that may occur in transmission between the SMR4 and the Surface Surveillance System.

[SMR4-IRD061] ASTERIX Data Blocks must be encapsulated as shown in Figure 32.

[SMR4-IRD062] The SMR4 must send the same Data Unit to two separate LAN interfaces.

[SMR4-IRD063] The Surface Surveillance System must monitor the availability of the two separate LAN interfaces for each Surveillance System.

Packet Sequence Number [SMR4-IRD064] The SMR4 must maintain a 2-byte unsigned Sequence Number independently for each Data Stream.

[SMR4-IRD065] The SMR4 must increment Sequence Numbers by 1 independently for each Data Stream.

[SMR4-IRD066] The SMR4 must assign the Sequence Number for each Data Stream to the next ASTERIX Data Block in line for transmission.

[SMR4-IRD067] The SMR4 must wrap the Sequence Number to 0 following Sequence Number 65535.

CRC-32

[SMR4-IRD068] A 4-byte CRC-32 must be transmit with each ASTERIX Data Block as illustrated in Figure 32.

[SMR4-IRD069] The CRC-32 must be computed as described in Appendix B.

Transport Layer Services [SMR4-IRD070] UDP must be used for all Data Units on the interface.

[SMR4-IRD071] All transport layer protocols in accordance with IETF RFC 1122 must be implemented.

[SMR4-IRD072] UDP for the transport layer must be implemented in accordance with IETF RFC 768 for ASTERIX Categories 010, 240 and 253.

[SMR4-IRD073] The SMR4 must support IP Version 4 as a configuration item for the network layer in accordance with IETF RFC 791.

[SMR4-IRD074] The SMR4 hardware must be IP Version 6 capable as a configuration item for the network layer in accordance with IETF RFC 2460, as well as IETF RFC 2464, 4291, and 4443.

[SMR4-IRD075] Address Resolution Protocol (ARP) must be implemented in accordance with IETF RFC 826.

[SMR4-IRD076] Protocol Independent Multicast (PIM) – Sparse Mode must be supported as defined in RFC 4601.

[SMR4-IRD077] The SMR4 must support IETF RFC 950, internet standard subnetting procedure.

[SMR4-IRD078] Transport layer protocol must be implemented in accordance with FAA-STD-39C and FAA-STD-042B with guidance of FAA-HDBK-004.

[SMR4-IRD079] The SMR4 must support IETF RFC 2236, Internet Group Management Protocol, Version 2 must be supported.

[SMR4-IRD080] The Surface Surveillance System must support IETF RFC 2236, Internet Group Management Protocol, Version 2.

Naming and Addressing The Surveillance Data listed in Table 31 will be provided across the interface. Figure 11 illustrates the fully redundant interface between the SMR4 and the Surface Surveillance System.

If equipped with multiple channels, only one of the SMR4 channels will be on-line at any given time and only the on-line channel will transmit data. The on-line channel will transmit UDP data to both Surface Surveillance System LAN A and Surface Surveillance System LAN B using separate IP addresses but the same port numbers.

[SMR4-IRD081] The SMR4 hostname(s) must be configurable.

[SMR4-IRD082] The SMR4 must utilize unique IP multicast addresses compatible with the Surface Surveillance System.

[SMR4-IRD083] The SMR4 must utilize unique IP source addresses compatible with the Surface Surveillance System.

[SMR4-IRD084] The SMR4 must provide redundant network paths for the interface with the Surface Surveillance System.

[SMR4-IRD085] All messages from the SMR4 to the Surface Surveillance System must be output simultaneously on both redundant Internet Protocol networks.

Physical Requirements / Characteristics The physical requirements for the SMR4 networking hardware is described below.

Electrical Power and Electronic Characteristics Ethernet crossover cables are not required for this interface.

[SMR4-IRD086] Electrical connection requirements for this Ethernet interface must be as specified in IEEE Std 802.3-2015.

[SMR4-IRD087] The LANs must support auto-negotiation of 100BASE-T and 1000BASE-T protocols as defined in IEEE Std 802.3-2015 for this interface.

Connectors [SMR4-IRD088] LAN cables at the demarcation points must be terminated with 8-position, 8-contact modular connectors (8P8C T568A pinout using an RJ-45 connector).

[SMR4-IRD089] Ethernet LAN connectors must be wired per TIA/EIA-568-C T568A.

[SMR4-IRD090] Ethernet LAN cables must be terminated with category 6 compliant terminations.

Wire/Cable [SMR4-IRD091] The SMR4 must provide 4 Ethernet cables to connect the physical interface.

[SMR4-IRD092] All cables located in the plenum area must be plenum rated.

[SMR4-IRD093] The LAN cable provided to the demarcation points must be 8-wire, 4-pair, 100 ohm, 24 AWG, Unshielded Twisted Pair (UTP).

[SMR4-IRD094] All cabling must be Cat 6 conforming to the specifications of ANSI/TIA-568.

[SMR4- IRD095] Each individual LAN cable must be less than 295 feet in length.

[SMR4- IRD096] The total length including any patch cords must be less than 328 feet.

[SMR4- IRD097] Equipment cables must be in accordance with NFPA 70, National Electric Code; FAA-C1217, Electric Work, Interior standards; and FAA Order 6950.22, Maintenance of Electrical Power and Control Cables.

Grounding The requirements in this section only apply to newly installed equipment.

[SMR4- IRD098] All equipment must adhere to FAA-STD-019E, Lightning and Surge Protection, Grounding, Bonding and Shielding Requirements for Facilities and Equipment.

[SMR4- IRD098] All network equipment must adhere to American National Standards Institute/Institute of Electrical and Electronics Engineers (ANSI/IEEE) Standard 1100-2005, Recommended Practice for Powering and Grounding Electrical Equipment.

Fasteners [SMR4-IRD100] Fasteners must be in accordance with FAA-G-2100J, Section 3.3.1.5.3.

Electromagnetic Compatibility [SMR4-IRD101] Electromagnetic emission and susceptibility of the equipment must be in accordance with Code of Federal Regulations Title 47 Part 15, for Class A digital devices for unintentional radiators.

Quality Assurance Provisions Test and Evaluation will be in accordance with the following documents:

· Acquisition Management System (AMS)

· Test and Evaluation Process Guidelines

· Test and Evaluation (T&E) Handbook

· Order NG 1810.8A (formerly CT 1810.8), FAA William J. Hughes Technical Center’s Test and Evaluation Policy Responsibility for Verification The Federal Aviation Administration (FAA) is responsible for developing and implementing the verification of requirements for each project. The FAA may delegate verification activities to other FAA organizations, independent contractors, and/or the major prime contractor.

Special Verification Requirements There are no special verification requirements.

Verification Requirements Traceability Matrix Verification methods are: Analysis (A), Demonstration (D), Inspection (I), and Test (T), as defined below:

Analysis: This is a method in which hardware or software designs are compared with known scientific and technical principles, procedures, and practices to estimate the capability of the proposed design to meet the mission and system requirements.

Demonstration: This is a method in which qualitative determination of properties is made for a configuration item, including software and/or the use of technical data and documentation. The items being verified are observed, but not quantitatively measured, in a dynamic state.

Inspection: This method is used to determine compliance without using special laboratory equipment, procedures, or services and consists of nondestructive static-state examination of hardware, software, and/or technical data and documentation.

Test: This is a method in which performance is measured during or after the controlled application of functional and/or environmental stimuli. Quantitative measurements are analyzed to determine the degree of compliance. The process uses standardized laboratory equipment, procedures, and/or services.

Appendix C contains the VRTM which provides additional clarification on the verification methods, how each requirement is to be verification and at what stage the verification will occur.

Preparation for Delivery This Section is not applicable for this IRD.

Notes Definitions

Delimit application elements or to aggregate for transmission elements of like type Identify application elements Provide error detection of the application elements that may occur in transmission between the SMR4 and the Surface Surveillance System

Abbreviations and Acronyms

Appendix A – General ASTERIX Message Formats A.1 Message Structure The ASTERIX Data Block contains the ASTERIX Data Category (Cat) and Length Indicator (LEN) fields and one or more ASTERIX records (FSPEC and the specified Field Reference Numbers (FRN)) of the same Report type (e.g., Radar Target Report).

A.1.1 General The application data to be transferred consists of an ASTERIX Data Block which includes:

(1) A one-Byte field (Cat) indicating the Data Category for records in this Data Block

(2) A two-Byte field (LEN) indicating the total length (in Bytes) of the ASTERIX Data Block, including this field, Data Category field, and all the Records.

(3) One or more Record(s) containing data of the same Data Category

The SMR4 will implement the packing of multiple ASTERIX Records in one ASTERIX Data Block as long as:

· The size of the Data Unit (header included with Payload (ASTERIX Data Block)) doesn’t exceed the maximum application layer size limit. The maximum application layer site limit is a site adaptable parameter with a default setting of 512 bytes.

· The packing period ensures that the SMR4 latency is met.

A depiction of the ASTERIX Data Block structure is provided in the Figure A1. Each Record is of variable length, but aligned on a Byte boundary.

Figure A1: ASTERIX Data Block Structure A.1.2 Data Field Formats To achieve transmission efficiency, contents of the Data Blocks are packed efficiently. This is achieved by sequencing of Data Fields within a Record. Ordered Field Sequencing is the standard method applied in Record composition. This structure is defined as follows:

(1) The leading part of the Record is a variable length field FSPEC. The FSPEC is a table of contents in the form of a bit sequence, where every individual bit signals the presence or absence of a well-defined Data Field assigned to it.

(2) The FSPEC is immediately followed by a variable number of contiguous Data Fields in the order of increasing FRN.

The relationship between the FSPEC bits, Data Fields and Data Items is established in the User Application Profile (UAP).

The minimum length of the FSPEC is one Byte, 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 that seven have to be transmitted, the FSPEC extension mechanism is used. This is achieved by assigning a special meaning to the Least Significant Bit (LSB) of the FSPEC Byte. The LSB, called the Field Extension (FX) bit, when set to one, signals the continuation of the FSPEC field with at least one further Byte, until finally a Byte is provided with the FX bit set to zero.

Appendix B – CRC-32 Algorithm

The CRC-32 algorithm has been derived from: Fletcher, J.G., “An Arithmetic Checksum for Serial Transmissions,” IEEE Transactions on Communications, Vol. COM-30, No. 1, January 1982, pp. 247-252.

The following symbols are used:

C0, C1, C2, C3 are variables used by the algorithm;

“i” is the number (i.e., position) of a Byte within the Data Unit;

“L” is the Length of the Data Unit; and “Xj” is the value of the “jth” Byte of the Extended 32-bit Checksum Parameter (in transmission order)

Arithmetic Conventions:

a. Addition is performed in modulo 255.

b. The Extended 32-bit Checksum is created by the following algorithm:

1. The Extended 32-bit Checksum Parameter value field set to ZERO will be set up

2. Initialize C0, C1, C2 and C3 to ZERO;

3. Process each Byte in the Data Unit sequentially from i=1 to “L” -4 (excluding the CRC) by:

a) adding the value of the Byte to C0; then

b) adding the value of C0 to C1, C1 to C2, and C2 to C3;

4. Set the Bytes of the Extended 32-bit Checksum parameter as follows:

a) X0 = 255-(C0 + C1 + C2 + C3)-1;

b) X1 = C1 + 2*C2 + 3*C3;

c) X2 = 255-(C2 + 3*C3)-1; and

d) X3 = C3;

c. The Extended 32-bit Checksum is validated as follows:

1. Initialize C0, C1, C2 and C3 to ZERO;

2. Process each Byte in the Data Unit sequentially from i=1 to “L” by:

a) adding the value of the Byte to C0, then

b) adding the value of C0 to C1, C1 to C2, and C2 to C3;

3. If, when all the Bytes have been processed, one or more of the variables C0, C1, C2 or C3 do not have the value ZERO, then the Checksum validation has failed.

Appendix C – Verification Requirements Traceability Matrix The following information pertaining to the VRTM is taken from the FAA/WJHTC Test and Evaluation Handbook, Version 3.0.

Each program requirement contained in the VRTM is assigned one or more of the following test verification method(s):

· Demonstration (D): Verification that is accomplished by operation, adjustment, or reconfiguration of items performing their designed functions under specific scenarios. The items may be instrumented and quantitative limits of performance monitored, but only observational data rather than actual performance data is required to be recorded for verification. Demonstration is often used to verify compliance with requirements in servicing, reliability, maintainability, transportability, and human factors engineering.

· Test (T): Verification that is accomplished, with or without instrumentation, through systematic exercising of the application item under appropriate conditions with the collection, analysis, and evaluation of quantitative data.

· Analysis (A): Verification that is accomplished through use of one or more of the following analysis techniques to prove that an item meets specified requirements:

a. Mathematical representation such as math models, algorithms, and equations

b. Charts

c. Graphs

d. Circuit diagrams

e. Data reduction/recording

f. Representative data (may include data collected from previous or other equipment and system verifications)

· Inspection (I): Verification that is accomplished by a visual examination of the item, reviewing descriptive documentation, and comparing the appropriate characteristics with predetermined standards to determine conformance to requirements without the use of laboratory equipment or procedures. Examples of verification by inspection are:

a. Visual analysis of the item under test, such as displays, cables, and processors.

b. Reviewing descriptive documentation such as Contract Data Requirements List (CDRL) items, vendor data, and engineering drawings.

c. Comparing the appropriate characteristics with a predetermined or reference standard such as FAA standards, other standards, and SOWs.

The VRTM that follows contains 3 test events:

· In-Plant DT – Performed by the Contractor.

· On-Site DT – Performed by the…