2018-08-03 E-IDS_DraftSIR_Attachment_J.1_SSD.pdf

FAA-E-XXX

Version 1.0

April 29, 2018

NOTE: This draft, dated April 29, 2018 prepared by AJM-212, has not been approved and is subject to modification. DO NOT USE PRIOR TO APPROVAL.

Initial Draft

System Specification

For Enterprise Information Display System (E-IDS)

SD-PMO-02-EIDS-17-002

Version 1.0, April 29, 2018

Responsible Organization:

AJM-212, Air Traffic Management Programs, E-IDS

Comments, suggestions, or questions on this document should be addressed to:

Federal Aviation Administration

AJM-212

600 Independence Avenue SW

Washington, DC 20591

E-IDS Initial Draft System Specification Version 1.0

SD-PMO-02-EIDS-17-002 April 29, 2018 ii

THIS PAGE LEFT INTENTIONALLY BLANK

iii

CHANGE RECORD

Version Description of Change Date

1.0 Initial draft of the document for the Draft SIR release April 29, 2018 iv

TABLE OF CONTENTS

1 SCOPE

2 APPLICABLE DOCUMENTS

2.1 General

2.1.1 FAA Documents

2.1.2 FAA Specifications, Standards, and Handbooks

2.1.3 Non-FAA Government Documents

2.1.4 Non-Government Documents

2.2 Order of Precedence

3 REQUIREMENTS

3.1 System Description

3.1.1 Operational Concept

3.1.2 High Level Operational Concept

3.1.3 Notional Architecture

3.2 System Operations

3.2.1 System States and Modes

3.2.2 System Configuration

3.2.3 Monitor & Control

3.2.4 Fault Isolation and Restoral

3.2.5 Certification

3.2.6 System Data Recording

3.2.7 System Support

3.3 Functional Capabilities

3.3.1 Computer Human Interface (CHI)

3.3.2 Data Administration

3.3.3 Display Configuration and Presentation

3.3.4 General Data Processing

3.3.5 Data Retention

3.3.6 Data Type Handling, Processing, and Display

3.3.7 Other System Functionality

3.3.8 Business Process Capability

3.4 Integration & Interfaces

3.4.1 Telecommunications

3.4.2 Information Transfer and Transformation

3.4.3 System Interfaces

3.4.4 SWIM Compliance

3.4.5 Non-NAS Interfaces

3.5 System Performance Requirements

3.5.1 Full Configuration of E-IDS

3.5.2 Design Workload

3.5.3 Response Time

3.5.4 System Capacity

3.5.5 Reliability, Maintainability, and Availability (RMA) Requirements

3.6 Physical Integration and Employee Occupational Safety & Health (EOSH)

3.6.1 Environmental

3.6.2 Land and Facility

3.6.3 Employee Safety and Health

3.7 Information System Security (ISS)

3.7.1 Access Control

3.7.2 Audit and Accountability

3.7.3 Configuration Management

3.7.4 Identification and Authentication

v

3.7.5 Maintenance

3.7.6 Media Protection

3.7.7 System Communication Protection

3.7.8 System Information and Integrity

3.8 Transition

3.9 System Design

3.9.1 Hardware

3.9.2 Centralized Processing Capability

3.9.3 Local Processing Capability

3.10 Continuity of Operations

4 QUALITY ASSURANCE

4.1 Verification

4.1.1 Verification Phases

4.1.2 Verification Methods

5 PREPARATION FOR DELIVERY

5.1 Preservation and Packaging

5.2 Quality System Requirements

5.2.1 Material Evaluation

5.2.2 Quality Conformance Evaluation

5.3 Verification Requirements Traceability Matrix

6 NOTES

APPENDIX A: ACRONYMS AND GLOSSARY TERMS

A.1 List of Acronyms A.2 Glossary

APPENDIX B: E-IDS VOID APPLICATION

APPENDIX C: E-IDS ROLES AND RESPONSIBILITIES

APPENDIX D: VERIFICATION REQUIREMENTS TRACEABILITY MATRIX

vi

TABLE OF TABLES

Table 1-1: Items in Work Table 3-1: E-IDS Data Types Table 3-2: AWOS-C/ASOS Data Table 3-3: RVR Display Information Table 3-4: ASOS VOID Data Table 3-5: E-IDS Full Configuration Table 3-6: User Activity Rates Table 3-7: Input Message/Data Rates at NDC Table 3-8 Output Message Data Rates at NDC Table B-1: E-IDS VOID DEC Special Graphics Set Table B-2: E-IDS VOID ASCII Graphics Set (Left Half) Table B-3: Control Character Table B-4: Sequence to Select Character Sets Table B-5: E-IDS VOID Character Sets Table B-6: Codes Sent by E-IDS VOID Arrow Keys Table B-7: Codes Sent by E-IDS VOID Numeric Keyboard Keys Table B-8: Codes Sent by E-IDS VOID Function Keys Table B-9: E-IDS VOID Application Cursor Controls Table B-10: E-IDS VOID Application Erase Functions Table B-11: E-IDS VOID Application Display Functions Table B-12: E-IDS VOID Application Keyboard Sequences Table D-1: VRTM Column Descriptions

TABLE OF FIGURES

Figure 3.1-1: E-IDS To-Be Program-Level Architecture High-Level Concept Figure 3.1-2: E-IDS Notional Architecture Figure 3.3-1: Sample Display of RBDT Data Figure 3.3-2: Depiction of RVR Information Display for Two Runways Figure 3.3-3: RVR LVAT Setting Capability Display Figure 3.3-4: Menu Options for Entering LVATs

1 SCOPE

The Enterprise Information Display System (E-IDS) will consolidate the existing stove-piped

IDSs into a common NAS-wide platform and integrate the capability into the Federal Aviation

Administration (FAA) Service Oriented Architecture (SOA) infrastructure using modern data formats and communication systems. E-IDS will replace En Route Information Display System

(ERIDS), Air Traffic Control Specialist (ATCS) Auxiliary Information Display (AAID), Information Display System (IDS Model 4 (IDS-4)), Automated Surface Observing System

(ASOS) Controller Equipment-Information Display System (ACE-IDS), and the NAS

Information Display System (NIDS).

E-IDS will be deployed in a segmented fashion with Segment 1, Phases 1 and 2, and Segment 2.

The segmentation approach for development and deployment addresses end-of-life issues for legacy IDSs and aligns with service delivery schedules of interfacing System-Wide Information

Management (SWIM) services.

This version of the SSD contains the requirements for Segment 1, Phases 1 and 2. Segment 2 requirements that are known are included as well. Requirements have an attribute for Segment and Phase for tracking in the Verification Requirements Traceability Matrix (VRTM) (Appendix

D). Requirements allocated for Segment 1, Phase 2 (S1P2) and Segment 2 (S2) are also marked inline in the document. Additional requirements for S1P2 and Segment 2 will be added in future releases of the SSD.

In Segment 1 Phase 1, the enterprise infrastructure will be established, including the National

Data Centers at the Network Enterprise Management Center (NEMC), integration with SWIM infrastructure and Aeronautical Information Management Modernization Aeronautical Common

Service (AIMM ACS), connectivity through the NAS Enterprise Security Gateway (NESG) with external users, and establishment of Remote Monitoring and Logging System (RMLS) and the

NAS Cyber Management System (NCMS) interfaces. Additionally, the system will interface with local sensors at Terminal facilities to process weather information. The software will include the core functionality for displaying local weather products and basic filtering/searching.

Information managed and displayed will also include Notices to Airmen (NOTAMs) and Special

Activity Airspace (SAA) schedules and status from AIMM ACS, runway status and Pilot

Reports (PIREPs). During this initial phase, deployment will target several operational clusters in the Terminal domain, at Terminal Radar Approach Controls (TRACONs), Airport Traffic

Control Towers (ATCTs), and Combined Center Radar Approach Controls (CERAPs), as well as several Air Route Traffic Control Center (ARTCC).

In Segment 1 Phase 2, the software functionality will be expanded for data correlation, dynamic screen sharing, and other new enterprise capabilities. New system functionality will enable

PIREP dissemination via Weather Message Switching Center Replacement System (WMSCR).

Additional SWIM interfaces will be added to receive weather products from Common Support

Services – Weather (CSS-Wx) and Traffic Management Initiative (TMI) information from

Traffic Flow Management Data (TFMData) Flow Information Service. Deployment will complete installations at the remaining Terminal and En Route facilities including the Alaska

ARTCC and oceanic sectors that currently have IDSs.

In Segment 2, the enterprise software will be updated with any capabilities needed by the

Oceanic sectors, the Flight Service Stations, and the ATSCC. New SWIM Services will be added as available, such as NAS Common Reference (NCR), TBFM Metering Information Service

(MIS), and TFDM Terminal Publication (TTP). Deployment will continue to additional Oceanic sectors, Alaska Flight Service Stations (FSSs) and the Air Traffic Control System Command

Center (ATCSCC).

The requirements stated herein provide the Government’s minimum functional system requirements for E-IDS. It has been developed in accordance with FAA-STD-067, Standard

Practice Preparation of Specifications.

The E-IDS Program is currently reviewing and assessing the requirements in preparation for the

Final Draft SSD to be released with the Screening Information Request (SIR) and the Final SSD, to be approved as part of the Final Investment Decision (FID).

Requirements and other content that is associated with open action items or issues are marked with a TBR, to reflect that they are “to be resolved” or “to be refined”. These are tracked in

Table 1-1.

Table 1-1: Items in Work

TBR ID Area Item Description

TBR-01 Interface Specifications Interface specifications for E-IDS are in development; references will be updated.

TBR-02 Monitor & Control Monitor & Control requirements will be revised after further development of Maintenance ConOps.

TBR-03 System Data Recording Details of System data recording will be provided, including data items to be recorded, with a description, basis, and frequency.

TBR-04 Performance Measures Data recorded for system performance measurements will be further defined.

TBR-05 Second Level Engineering Second Level Engineering requirements will be revised after further development of Maintenance ConOps.

TBR-06

[S1P2]

Position Reconfiguration Position Reconfiguration requirements will be revised to add functionality for the logic of handling inherited settings and potential settings in conflict.

TBR-07

[S1P2]

Data Correlation Functionality for data correlation will be further defined.

TBR-08 Security Audit Archive Archive storage period requirements will be verified.

TBR-09 SWS Interface Whether the SWS sends the same data that is sent over the existing DASI and SAWS interfaces will be confirmed, in which case the display and error handling requirements in those sections will be applicable to SWS interface.

TBR-10 AWIPS Interface The connection between E-IDS and AWIPS is under review;

this could be a centralized interface.

TBR-11 Static Data Requirements for static data will be revised, including source of information, frequency of update, estimated size and update method.

TBR-12

[S1P2]

CSS-Wx Products CSS-Wx Products display and processing requirements will be revised.

TBR-13

[S1P2]

TMI Information TMI display and processing requirements will be revised.

TBR-14

[S1P2]

PIREPs PIREPs generation, distribution and submission requirements will be revised.

TBR-15

[S2]

AIREPs AIREPs generation, distribution and submission requirements are under development.

TBR-16

[S2]

Hazardous Weather Advisories

Requirements for submitting Hazardous Weather Advisories to CSS-Wx are under development.

TBR-17 ASOS Ready Reference Guide

The reference to the ASOS Ready Reference Guide will be replaced with an updated source.

TBR-18 Electronic Messaging Requirements for functionality for electronic messaging is under further development, including use of default forms and broadcast messages.

TBR-19 Timers Functionality for timers was added in a recent release of NIDS;

requirements are under development for E-IDS.

TBR-20 Business Process Capability

Requirements for Business Process Capability and Rules will be revised.

TBR-21 System Performance System Performance requirements will be revised based on results of ongoing performance analysis.

TBR-22 System Configuration Counts

Count of workstations, sites and local interfaces are being verified and updated, the requirements will be revised accordingly.

TBR-23 Design Workload Design Workload will be revised based on results of ongoing performance analysis.

TBR-24 RMA RMA requirements will be revised based on results of ongoing analysis.

TBR-25 Access Control Groups Access Control groups are under further development.

TBR-26 PII Data PII definition and applicability to E-IDS will be clarified

TBR-27 Glossary Glossary terms and definitions are under further development.

TBR-28 Roles and Responsibilities Roles and responsibilities are under further definition, particularly for differentiation of local and national roles.

TBR-29 VRTM Requirement verification methods and traceability are under development.

2 APPLICABLE DOCUMENTS

2.1 General

The documents listed in this section are specified in sections 3, 4, or 5 of this specification. This section does not include documents cited in other sections of this specification or recommended for additional information or as examples. While every effort has been made to ensure the completeness of this list, document users are cautioned that they must meet all specified requirements of documents cited in sections 3, 4, or 5 of this specification, whether or not they are listed.

2.1.1 FAA Documents

TBR-01: Interface specifications for E-IDS are in development; references will be updated.

Document Name Document Title

E-IDS RMLS IRD E-IDS to Remote Monitoring Logging System Interface Requirements Document, Version, Date.

RVR to E-IDS IRD Runway Visual Range to E-IDS Interface Requirements Document, Version, Date.

SWS to E-IDS IRD Surface Weather System (SWS) to E-IDS Interface Requirements Document, Version, Date.

SAWS to E-IDS IRD Stand Alone Weather Sensors (SAWS) to E-IDS Interface Requirements Document, Version, Date.

DME DASI to E-IDS IRD DME DASI to E-IDS Interface Requirements Document, Version, Date

RBDT to E-IDS IRD Systems that use a Ribbon Display Terminal (RBDT) to E-IDS Interface Requirements Document, Version, Date.

AWOS-C to E-IDS IRD Automated Weather Observing System (AWOS)-C to E-IDS Interface Requirements Document, Version, Date.

ASOS to E-IDS Automated Surface Observing System (ASOS) to E-IDS Interface Requirements Document, Version, Date.

AWIPS to E-IDS Advanced Weather Interactive Processing System (AWIPS) to E-IDS Interface Requirements Document, Version, Date.

FDIO to E-IDS Flight Data Input/ Output (FDIO) System to E-IDS Interface Requirements Document, Version, Date.

ACS Data Service WSRD Aeronautical Information Management Modernization S2 (AIMM S2) Aeronautical Common Service (ACS) Data Service Web Service Requirements Document (WSRD), Release 3 Version 3.4 Final, Washington, DC, April 2017.

ACS Data Query WSDD AIMM S2 ACS Data Query Service Web Service Description Document (WSDD), Release 3 Version 3.1 Final, Washington, DC, September 2016.

ACS Web Feature Service

WSDD

AIMM S2 ACS Web Feature Service WSDD, Release 3 Version 3.1 Final, Washington, DC, September 2016.

ACS Data Subscription

WSDD

AIMM S2, ACS Data Subscription WSDD, Release 3 Version 3.1 Final, Washington, DC, September 2016.

CSS-Wx WCS WSDD CSS-Wx Web Coverage Service Web Service Description Document Volume I, Rev A, Washington, DC, May 2016.

CSS-Wx WFS WSDD CSS-Wx Web Feature Service Web Service Description Document, Volume II, Rev A, Washington, DC, May 2016.

CSS-Wx WMS WSDD CSS-Wx Web Map Service Web Service Description Document, Volume III, Rev A, Washington, DC, May 2016.

TFMData JMSDD Traffic Flow Management Data Service (TFMData) Java Messaging Service Description Document (JMSDD), Version 2.0.5 Final, Washington, DC, February 2016.

WMSCR Publish PIREP Service JMSDD

WMSCR Publish Pilot Weather Report (PIREP) Service Java Messaging Service Description Document, Washington, DC, March 2014.

E-IDS ConOps Concept of Operations for Enterprise Information Display System, Version 2, Washington, DC, October 2017.

E-IDS ISS Assessment Information Systems Security Assessment for Enterprise Information Display System, Washington, DC, August 2017.

E-IDS CHI Thin Spec E-IDS CHI Thin Spec, Washington, DC, April 2018.

2.1.2 FAA Specifications, Standards, and Handbooks

The following specifications, standards, and handbooks form a part of this document to the extent specified herein. Unless otherwise specified, the issues of these documents are those cited in the solicitation or contract.

Document Name/Number Document Title

FAA HF-STD-001B Human Factors Design Standard (HFDS), Atlantic City, NJ, December 2016.

FAA-HF-STD-003 Alarms and Alerts in the Technical Operations Environment, Atlantic City, NJ, August 2009.

FAA-HF-STD-008 Air Traffic Control Traffic Control Tower Alert Standard, Washington, DC, August 2014.

FAA-HF-STD-009 Technical Operations Graphical User Interface Standard, Washington, DC, January 2017.

FAA-HF-STD-010 Color Use in Air Traffic Control System Displays, Washington, DC, December 2017.

FAA-STD-019E CHG 1 Lightning and Surge Protection, Grounding, Bonding and Shielding Requirements for Facilities and Electronics Equipment, Washington, DC, February 2016.

FAA-STD-045A National Airspace System (NAS) Communications Security Protocols and Mechanisms, Washington, DC, March 1995.

FAA-STD-049 Fiber Optic Telecommunication Systems and Equipment, Washington, DC, February 1994.

FAA-G-2100H Electronic Equipment, General Requirements, Washington, DC, May 2005.

FAA Order 1050.10D Environmental Pollution Control and Abatement at FAA Facilities, Washington, DC, November 2015.

FAA Order 1050.17A Environmental Compliance for Air Traffic Organization, Washington, DC, November 2012.

FAA JO Order 1370.98 ATO IT Infrastructure Requirements for Non-FAA Connectivity, Washington, DC, April 2007.

FAA JO Order 1370.101 ATO Information Security Incident Reporting and Response Policy, Washington, DC, December 2007.

FAA Order JO 1370.114 Implementation of FAA Telecommunications Infrastructure (FTI) Services and Information Security Requirements in the NAS, Washington, DC, January 2012.

FAA Order JO 1370.117 National Airspace System (NAS) Internet Protocol (IP) Addressing Policy, Washington, DC, January 2014.

FAA Order 1370.121 Information Security and Privacy Program & Policy, Washington, DC, December

FAA Order 1375.1E Information/Data Management, Washington, DC, November 2011.

FAA Order 1600.75 Protecting Sensitive Unclassified Information, Washington, DC, February 2005.

FAA Order 1600.78 Personal Identity Verification (PIV) Card and other Identification Cards, Washington, DC, May 2010.

FAA Order 3900.19B Occupational Safety and Health Program, Washington, DC, April 1999.

FAA Order JO 3900.64 Air Traffic Organization Electrical Safety Program, Washington, DC, May 2013.

FAA Order JO 3900.67 Air Traffic Organization Hazardous Energy Control (Lockout/Tagout) Program, Washington, DC, June 2015.

FAA Order 6030.20F CHG 1 Electrical Power Policy, Washington, DC, April 2012.

FAA Order 6470.33B Control of Power and Space, and Environment Interfaces at En Route Air Traffic Control Facilities, Washington, DC, May 2011.

FAA Order 6950.2D CHG 1 Electrical Power Policy Implementation at National Airspace System Facilities, Washington, DC, October 2003.

FAA Order JO 6980.25E Maintenance of Batteries for Standby Power, Washington, DC, November 2015.

FAA Order JO 7210.3AA Facility Operation and Administration, Washington, DC, September 2017.

FAA Order JO 7340.2H Contractions, Washington, DC, March 2018.

FAA Order JO 7400.10 Special Use Airspace, Washington, DC, February 2018.

NAS Security Advisory for USB Drives

NAS Security Advisory for USB Drives, Washington, DC, February 2013.

2.1.3 Non-FAA Government Documents

The following other Government documents, drawings, and publications form a part of this document to the extent specified herein. Unless otherwise specified, the issues of these documents are those cited in the solicitation or contract.

Document Name/Number Document Title

29 CFR 1910 Occupational Safety and Health Standards (General Industry), Washington, DC.

29 CFR 1910 Subpart S Occupational Safety and Health Administration (OSHA) Standards, Electrical, Washington, DC.

29 CFR 1910.145 Specifications for Accident Prevention Signs and Tags, Washington, DC.

29 CFR 1910.147 Occupational Safety and Health Standards, General Environmental Controls, Control of Hazardous Energy (Lockout/Tagout), Washington, DC.

29 CFR 1910.303 Occupational Safety and Health Administration (OSHA) Standards, Design Safety Standards for Electrical Systems, General Requirements, Washington, DC.

40 CFR Subchapter C, Parts 50-97

Protection of the Environment, “Clean Air Act”, Washington, DC.

40 CFR 700-766 Protection of the Environment, “Toxic Substances Control Act” (TSCA), Washington, DC.

FISMA Federal Information Security Management Act of 2002 (FISMA), Title III of the E- Government Act of 2002, Washington, DC, December 2002.

NIST FIPS 199 Standards Standards for Security Categorization of Federal Information and Information Systems, Gaithersburg, MD, February 2004.

NIST FIPS 200 Standards Minimum Security Requirements for Federal Information and Information Systems, Gaithersburg, MD, March 2006.

NIST SP 800-81-2 Secure Domain Name (DNS) Deployment Guide, Gaithersburg, MD, September 2013.

OMB M-06-16 Protection of Sensitive Agency Information, Washington, DC, June 2006.

2.1.4 Non-Government Documents

The following documents form a part of this document to the extent specified herein. Unless otherwise specified, the issues of these documents are those cited in the solicitation or contract.

Document Name/Number Document Title

ANSI Z535 American National Standards Institute (ANSI), Safety Alerting Standards, Rosslyn, VA, September 2011.

Internet Protocol Postel, J., Internet Protocol, STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, https://www.rfc-editor.org/info/rfc791.

IPv6 Specification Deering, S. and R. Hinden, Internet Protocol, Version 6 (IPv6) Specification, STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, https://www.rfc-editor.org/info/rfc8200.

NFPA 70 National Fire Protection Association (NFPA), National Electrical Code®, Quincy, MA, 2017.

NFPA 70 Article 110.26 National Fire Protection Association, National Electric Code®, Spaces About Electrical Equipment, Quincy, MA, 2017.

NFPA 70E National Fire Protection Association, Standard for Electrical Safety in the Workplace, Quincy, MA, 2015.

NFPA 90A National Fire Protection Association, Standard for Installation of Air-Conditioning and Ventilating Systems, Quincy, MA, 2015.

TCP Standard Postel, J., Transmission Control Protocol, STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, https://www.rfc-editor.org/info/rfc793.

2.2 Order of Precedence

In the event of a conflict between the text of this document and the references cited herein, the text of this document takes precedence. Nothing in this document, however, supersedes applicable laws and regulations unless a specific exemption has been obtained.

3 REQUIREMENTS

3.1 System Description

3.1.1 Operational Concept

E-IDS provides advancements in technology and information services to modernize the display and aggregation of supplemental information to operators. FAA Air Traffic Management (ATM) service providers use this information to supplement their primary (radar) displays. As described in the Concept of Operations, E-IDS will:

• Be a single, cross-domain system (e.g., supporting various Traffic Flow Management

(TFM), Air Traffic Control (ATC), and support operations) with a modern, upgradeable display that provides auxiliary static and real-time information in various formats for

ATM service providers in FAA facilities.

• Receive information from many different authoritative sources, such as CSS-Wx via

SWIM and FAA-approved websites, as well as through legacy interfaces.

• Provide integrated information from the different sources and facilitate the organization and accessibility of the different types of information, such as through filtering, searching, displaying items simultaneously, and prioritizing multiple windows for a specific operation with minimal manual effort.

• Support easy user manipulation of the display (e.g., panning, zooming, and scrolling) and printing of information.

• Provide templates for support personnel to define and customize a structured hierarchy for the information, as well as a reporting capability for reviewing page usage information over time.

• Support digital information and modern document formats and be extensible to receive new types of information.

• Automatically update information, hierarchy, and shortcuts to reduce the need for manual data entry where possible.

• Route information that has been manually entered (e.g., the controller entering PIREPs of turbulence), to the appropriate positions and systems for approval and subsequent dissemination.

• Indicate when information has been updated to support the situation awareness of all E-

IDS users.

• Provide an access control capability, modern telecommunications and systems interfaces, and high reliability and availability characteristics, as well as common maintenance procedures and training materials across the applicable domains in the NAS.

• Support continuity of operations by providing required operational position information to any other properly configured position in the NAS.

Sample operational scenarios illustrating the roles, responsibilities, and capabilities associated with these E-IDS operations are described in the E-IDS Concept of Operations. These scenarios represent examples of E-IDS being used by specific ATM service providers in flight service stations, terminal, en route, oceanic, and CERAP facilities, for air traffic management and for system support. The scenarios illustrate nominal and off-nominal operations from the perspective of ATM service providers and how they interact with E-IDS.

The operational concept for E-IDS includes various types of users, including operational users

(e.g. Air Traffic Controllers, Weather Specialists, and Traffic Managers), Data Administrators, Tech Ops personnel, and Second Level Engineering. Appendix C provides a description of the roles and responsibilities on E-IDS.

3.1.2 High Level Operational Concept

The E-IDS operational concept is illustrated in the program-level Operational View (OV-1) shown in Figure 3.1-1. In this figure, the infrastructure layer shows the telecommunications, NAS enterprise messaging services, and timing services. The next two layers show how E-IDS accesses enterprise information from SWIM-enabled information services. In the E-IDS layer, a single common display is used across all positions, facilities, and domains and direct access is enabled to receive information from the Department of Defense (DoD) legacy IDSs and weather sensors. The top air traffic services layer provides standard and timely access to information across the NAS.

Figure 3.1-1: E-IDS To-Be Program-Level Architecture High-Level Concept

E-IDS is expected to increase ATM service provider productivity by reducing the time to access information needed by operational and support personnel. Incorporating an enterprise-wide platform will improve the safety of the NAS and the efficiency of flight-specific ATC operations by providing faster access to specific information on the display.

3.1.3 Notional Architecture

The FAA-approved architecture approach for E-IDS is for an enterprise-level data center capability (referred to as the National Data Centers (NDCs)) to collect, store, correlate and distribute information from authoritative sources to operational facilities for display. The NDCs consist of two instances of the E-IDS application hosted on an FAA-owned virtualized platform, the Integrated Enterprise Services Platform (IESP). At any given time, one of the two E-IDS

NDCs is operational, with data synchronization between the two sites. The E-IDS NDC provides the sole conduit to SWIM Business Services, RMLS, and NCMS).

The local sites are equipped with a Facility Server that accesses the NDC’s application interface over the OPS-IP network to receive data. At sites with local interfaces, the Facility Server processes sensor information and forwards to the E-IDS NDC. The Facility Server connects to E-

IDS Workstations to display data to the users.

A notional architecture for the facilities and central processing is shown in Figure 3.1-2. The notional architecture is the FAA’s preferred architecture, although there are other architecture options that might satisfy the E-IDS specifications.

Figure 3.1-2: E-IDS Notional Architecture

3.2 System Operations

3.2.1 System States and Modes

SSD-1

The system must have the following operating states:

a. Normal/Operational

b. Offline

c. Standby

d. Diagnostic/Test

e. Training

f. Degraded

g. Failed

3.2.2 System Configuration

SSD-2

The system must provide the capabilities to receive, upload, and install software (e.g., online and from electronic media).

SSD-3 The system must operate with multiple versions of software.

Note: Local facilities have up to 6 months to install a software release. At a given time, some facilities will be on the older version of the software release (N-1), while the rest are on the current version of software (N). When a new version is released (N+1), the system will need to handle all three software versions in operations.

SSD-4 The system must distribute software to designated components.

SSD-5 The system must load software to designated components.

SSD-6 The system must provide the capability for the software to disable drives for removable media.

SSD-7 The system must provide a capability to define user positions for each facility.

SSD-8 The system must provide a capability to define operational clusters.

SSD-9 The system must provide a capability assign each facility to an operational cluster.

SSD-10 The system must provide a capability for configuring data feeds to ingest for each facility.

SSD-11 The system must provide a capability for configuring SWIM business service connections.

SSD-12 The system must provide a capability to define subscription parameters for each SWIM business service.

SSD-13 The system must provide a capability to suspend or cancel a SWIM business service subscription.

SSD-14 The system must provide a capability to define system components.

SSD-15 The system must provide a capability to define performance thresholds for system components.

SSD-16 The system must provide a capability for defining interface configuration parameters.

Note: These interfaces include the legacy surface sensors, such as DASI and RBDT.

SSD-17 The system must allow configuration of FDIO data types and location identifiers for display at a facility and at each position at that facility.

Note: See Section 3.3.6.8 FDIO Data.

SSD-18 The system must allow definition of an expiration time period parameter for automatic deletion of FDIO data, for each FDIO data type.

Note: See Section 3.3.6.8 FDIO Data.

SSD-19 The system must allow enabling/disabling of FDIO data auto-delete functionality based on the expiration time period parameter.

Note: See Section 3.3.6.8 FDIO Data.

SSD-20 The system must allow enabling/disabling of FDIO data auto-delete functionality based on detecting expiration information in the data string.

Note: See Section 3.3.6.8 FDIO Data.

SSD-21 The system must allow configuration of whether or not persistent display of RVR-related alert/alarms can be manually overridden.

SSD-22 The system must allow definition of Ribbon Display Terminal Identification Numbers

(RBDT ID).

SSD-23 The system must allow selection of the RBDT ID.

SSD-24

The system must have a parameter to enable or disable transmit of the Status Byte for each

RBDT ID.

SSD-25 The system must allow selection of data to display from systems that use RBDT.

SSD-26

The system must allow the selection of any one of the twenty-four (24) display pages to be associated with a particular position for data from systems that use RBDT.

SSD-27

The system must include a parameter for expiration time period for data from local interfaces, including systems using RBDT and ASOS.

Note: Data is valid for a given amount of time (e.g. 30 seconds). If an update does not come in by that period, the data is considered expired.

SSD-28 The system must allow definition of text names of AWIPS products.

SSD-29 The system must allow selection of an ASOS for the ASOS VOID application.

SSD-30 The system must allow the user to exit the interface configuration capability editing function without saving the changes or impacting the operational capabilities of the interface.

3.2.3 Monitor & Control

TBR-02: Monitor & Control requirements will be revised after further development of

Maintenance ConOps.

3.2.3.1 Monitor

SSD-31 The system must monitor and display hardware component status at all locations.

SSD-32 The system must monitor and display software component status at all locations.

SSD-33 The system must monitor and display network component status at all locations.

SSD-34 The system must monitor and display interface status at all locations.

SSD-35 The system must monitor and display hardware component performance at all locations.

SSD-36 The system must monitor and display software component performance at all locations.

SSD-37 The system must monitor and display network component performance at all locations.

SSD-38 The system must provide enterprise status information in a hierarchical manner at the centralized processing locations.

SSD-39 The system must monitor the connectivity between the centralized processing and SWIM business services.

SSD-40 The system must monitor the connectivity between the centralized processing and NAS

Enterprise Messaging System (NEMS).

SSD-41 The system must monitor the connectivity between the centralized processing and RMLS.

SSD-42 The system must monitor system components without degradation to the operational functionality.

SSD-43 The system must provide a capability to store and track planned outage schedules.

SSD-44 The system must provide a capability to define performance thresholds for hardware, software and network components.

3.2.3.1.1 Fault Detection

SSD-45 The system must detect hardware, software, and network component failures.

SSD-46 The system must detect interface failures.

SSD-47 The system must detect when a component’s performance approaches the defined threshold within a defined parameter.

SSD-48 The system must detect when a component’s performance exceeds the defined threshold.

3.2.3.1.2 Event Notification

SSD-49 The system must provide system component failure notifications.

SSD-50 The system must provide system interface failure notifications.

SSD-51 The system must provide notifications when system components change states, including:

a. Normal/Operational

b. Offline

c. Standby

d. Diagnostic/Test

e. Training

f. Degraded

g. Failed

SSD-52 The system must provide users status information of subscribed SWIM service interfaces.

SSD-53 The system must notify the user of successful connection to a SWIM business service.

SSD-54 The system must notify the user of successful connection to NEMS.

SSD-55 The system must notify the user of successful connection to each local interface.

SSD-56 The system must provide a notification when a component’s performance approaches the defined threshold within a defined parameter.

SSD-57 The system must provide a notification when a component’s performance exceeds the defined threshold.

SSD-58 The system must allow users to communicate scheduled maintenance notices before any planned outage.

3.2.3.2 Remote Monitoring

SSD-59

The system must provide component status and performance information to the Remote

Monitoring and Logging System (RMLS) for all locations for the following:

a. Hardware

b. Software

c. Networks

d. Interfaces

SSD-60 The system must report status to RMLS in accordance with the approved interface specification.

3.2.3.3 Control

SSD-61 The system must accept inputs to assign the following operational states to system components:

a. Normal/Operational

b. Offline

c. Standby

d. Diagnostic/Test

e. Training

f. Degraded

g. Failed

SSD-62 The system must provide the following control capabilities for hardware components:

a. Power up

b. Power down

c. Restart

SSD-63 The system must accept inputs for:

a. System initiation

b. System diagnostics execution

c. System recovery actions

d. System shutdown

SSD-64 The system must assign default states to system components as defined by system configuration parameters during system initiation.

3.2.4 Fault Isolation and Restoral

SSD-65 The system must provide capabilities to recover from short-term disruptions by accessing stored data.

SSD-66 The system must ensure that access control information is recovered after a system failure.

SSD-67 Upon restoration after a system failure, the system must test the integrity of the system and stored data.

SSD-68 The system must recover from failure of data collection with no loss of data.

SSD-69 The system must recover from failure of data processing with no loss of data.

SSD-70 The system must recover from failure of data distribution with no loss of data.

SSD-71 The system must process all recovered messages after a restart.

3.2.5 Certification

SSD-72 The system must provide a certification capability.

SSD-73 The system must accept inputs to execute system certification

3.2.6 System Data Recording

TBR-03: Details of System data recording will be provided, including data items to be recorded, with a description, basis, and frequency.

SSD-74 The system must automatically record system status at adapted intervals.

SSD-75 The system must automatically record system events (e.g., state changes, failures).

SSD-76 The system must provide a tool to manually record (log) maintenance actions and system events.

SSD-77 The system must log all data update events.

SSD-78 The system must record events that may lead to faults of any components and devices.

SSD-79 The system must record component failures.

SSD-80 The system must record interface failures.

SSD-81 The system must record data that allows system performance to be measured against defined metrics.

TBR-04: Data recorded for system performance measurements will be further defined.

SSD-82 The system must log system activity data.

SSD-83 The system must log data queries.

SSD-84 The system must log data subscription activity.

SSD-85 The system must log all error messages.

SSD-86 The system must log all data storage activities (create, update, delete).

SSD-87 The system must log all transactions for business processes/workflow.

SSD-88 The system must record auditing information on database maintenance functions taken.

SSD-89 The system must log all user actions (e.g., entering PIREPs, sharing information).

SSD-90 The system must time stamp events for use in audit record generation.

SSD-91 The system must provide a historical replay capability using stored data.

SSD-92 The system must have a local processing capability to aggregate, process, and filter logs prior to forwarding to the centralized processing capability.

SSD-93 The system must record auditing information on data maintenance functions taken.

SSD-94 The system must log data related to the recovery from system failure.

SSD-95 The system must track all user activity statistics.

SSD-96 The system must provide an event log for monitoring system health.

3.2.7 System Support

3.2.7.1 First Level Maintenance

SSD-97 The system must provide capabilities to troubleshoot the local interfaces.

SSD-98 The system must provide a capability to capture and display raw data received from an interface.

SSD-99 The system must provide a capability to save the data captured during interface testing.

SSD-100 The system must provide a capability to troubleshoot system hardware, software and network component failures.

SSD-101 The system must perform automated diagnostics on all system components.

SSD-102 The system must have a remote access capability to local facilities from the centralized capability.

SSD-103 The system must have a remote access capability to local facilities from other local facilities.

Note: For example, this would allow troubleshooting of a Tower from a TRACON.

3.2.7.2 Second Level Engineering

TBR-05: Second Level Engineering requirements will be revised after further development of

Maintenance ConOps.

SSD-104 The system must provide capabilities for operational testing, verification, and validation of software releases.

SSD-105 The system must provide on-line software and hardware diagnostic tools for second-level engineering, including, remote diagnostic and resolution support.

SSD-106 The system must provide an integrated tool for:

a. Software Configuration Management

b. Software Development

c. Data Backup and Restoral

d. Data Archiving

e. System Security accounts, files, and audit logs analysis

SSD-107 The system must include automated tools for generating, collecting, and analyzing system error, failure, status, and processing trace files.

SSD-108 The system must include hardware and software tools required to support diagnostics of the system software, hardware, and interfaces.

SSD-109 The system must include Data Reduction and Analysis (DR&A) tools.

SSD-110 The system must provide the capability to retrieve and sort archived information by, at a minimum: time, date, universally unique identifier (UUID), and entry type.

SSD-111 The system must provide a Graphical User Interface (GUI) for specified users to perform audits on all system activities and changes made to data.

SSD-112 The system must provide a tool for users to access archived data.

Note: Data is archived for use in post-analysis activities.

SSD-113

The system must provide a tool for users to perform analysis and generate reports from archived data, including:

a. System performance (e.g., FAA Telecommunications Infrastructure (FTI) usage and failure rates).

b. Page usage information over various time periods to allow the prioritization of information hierarchy.

c. Information usage over user-specified time periods to identify unused data.

SSD-114 The system must include capacity and response measurement tools.

SSD-115 The system must include software tools to create, edit, test and store source code.

SSD-116 The system must include tools for software test, analysis, and debugging.

SSD-117 The system must include tools for test, analysis, and debugging of site configurations, including the capability to mimic a site.

SSD-118 The system must include software library tools to maintain system source and object code.

SSD-119 The system must include tools for managing hardware component updates.

SSD-120 The system second-level support function must replicate the operations, communications, and interfaces of any operational sites.

SSD-121 The system second-level support function must satisfy the established response time requirements for site support.

SSD-122 The system second-level support function must provide centralized software development, maintenance, test, file management, and configuration management for users.

SSD-123 The system second-level support function must provide simulated operational test capabilities to users.

SSD-124 The system second-level support function must distribute software and configuration data to individual sites based on user input.

SSD-125 The system second-level support function must distribute configuration, recorded, and report data from individual sites based on user input.

3.3 Functional Capabilities

3.3.1 Computer Human Interface (CHI)

SSD-126 The system must adhere to the E-IDS CHI Thin Spec document.

SSD-127 The system CHI must comply with FAA-HF-STD-010, Color Use in Air Traffic Control

System Displays.

SSD-128 The system CHI must comply with FAA-HF-STD-008, Air Traffic Control Tower Alert

Standard.

SSD-129 The system CHI must comply with FAA-HF-STD-009, Technical Operations Graphical

User Interface Standard.

SSD-130 The system CHI must comply with FAA HF-STD-001B, Human Factors Design Standard, section 5.6 Computer-Human Interface.

3.3.2 Data Administration

Standardization of user displays is achieved through the use of templates. These are managed by the Data Administrators. Within a facility, areas are defined for sets of positions. A position follows a particular template. DAs manage the definition of templates and the assignment of positions to templates.

3.3.2.1 Data Administration Tools

SSD-131 The system must control access to the Data Administration Tools through privileges.

SSD-132 The Data Administration Tools must be accessible locally and centrally.

SSD-133

[S1P2]

The system must provide Data Administration Tools to specify the correlation of data sets.

Note: Correlation of data sets includes geospatial and temporal correlation and could include PIREPs and volumetric weather information with approach plates, NOTAMs or weather with other types of map data, Special Activity Airspace (SAA) information with maps and charts, and airport and airspace status and planned changes with maps and charts.

SSD-134 The Data Administration Tools must support the import of documents and images.

SSD-135 The Data Administration Tools must allow the selection of the method for receiving updates from each data source:

a. Automatically according to specified update procedures

b. Manually in response to notification.

SSD-136 The Data Administration Tools must support the creation of an indexed location within a document that can be accessed from a shortcut.

SSD-137 The Data Administration Tools must support the transferring of indexed locations within a document to an updated version of the same document.

3.3.2.2 Templates and Position Settings

SSD-138 The system must include a distinct Home Screen Template for each User Type (e.g., CPCs, FLMs, TMCs, Data Administrators, Tech Ops).

SSD-139 The Home Screen Templates must adhere to the E-IDS CHI Thin Spec document.

SSD-140 The System must include a distinct Data Type Template for each Data Type.

Note: A Data Type is the collection of individual datum of the same kind, e.g., approach plates, NOTAMS, RVR. The Data Type Template provide the default content and display characteristics that appear on the Home Page or a distinct area.

SSD-141 The Data Type Templates must adhere to the E-IDS CHI Thin Spec document.

SSD-142 Each Home Screen Template must define, at least, the following:

a. Types of data displayed by default

b. Format of displayed data

c. Default location of each displayed data type

d. Shortcuts/links to Sub-Screens that display information not presented on the Home

Screen

e. Other navigation features

SSD-143 Each Data Type Template must define, at least, the following:

a. Type(s) of data displayed by default

b. Format of displayed data

c. Default location for display on the screen

d. Shortcuts/links to Sub-Screens that display related information, if any

e. Other navigation features

SSD-144 The system must support the creation of Position Settings based on Home Screen

Templates and Data Type Templates.

SSD-145 Position Settings must define the following:

a. A default Home Screen

b. Access permissions

c. Data filtering parameters for the Home Screen and Data Types (Filters may include relevant airports, sectors, regions, times, or other applicable items)

d. Data sources for the Home Screen and Data Types

e. Alarm, alert, and notification and alert settings

f. Default zoom levels for static information (e.g., documents, charts)

g. The flow of information for certain data types

SSD-146 A Position Setting must be assignable to one or more user workstations.

SSD-147 A Position Setting must be assigned to a prior to initialization.

SSD-148 The Home Screen in the Position Setting must be displayed upon user workstation initialization.

3.3.2.3 Template Tools

SSD-149 The system must provide Data Administration Tools to manage the collection of templates/models.

SSD-150 The system must provide the capability for version control of templates for each position.

SSD-151 The system must provide Data Administration Tools to create a new Home Screen based on existing Home Screen.

Note: The DA is not required to start from a blank template to create a Home Screen.

SSD-152 The Data Administration Tools must support the assignment of filtering parameters for the

Home Screen and Data Types.

Note: Filters may include relevant airports, sectors, regions, times, or other applicable items.

SSD-153 The Data Administration Tools must support adding and deleting custom shortcuts to a

Home Screen that are linked to particular indexed data or data feeds.

SSD-154 The system must provide the capability to resize each distinct area independently of other distinct areas.

3.3.2.4 Position Settings Tools

SSD-155 The system must provide Data Administration Tools to create, modify, save, test, delete, and restore Position Settings.

Note: These tools are provided for use at facilities to create Positions Settings and assign them to user workstations. These tools may be used by non-Data Administrators (for example, Air Traffic System Specialists (ATSSs or Tech Ops) or staff at Second Level

Engineering at the Tech Center) based on privileges. These tools will not be capable of modifying or adding to system code.

SSD-156 The Data Administration Tools must support the assignment of a Home Screen (based on a

Home Screen Template) to Position Settings.

SSD-157 The system must provide Data Administration Tools to assign a Position Settings to a user workstation.

SSD-158 The Data Administration Tools must support the assignment of Data Types (based on Data

Templates) to Position Settings.

SSD-159 The Data Administration Tools must support the assignment of access permissions to

Position Settings.

SSD-160 The Data Administration Tools must support the assignment of data sources to Position

Settings.

SSD-161 The Data Administration Tools must support the assignment of notification settings to a

Position Settings.

3.3.3 Display Configuration and Presentation

3.3.3.1 Presentation of Information

SSD-162 The system must present information in multiple distinct areas (e.g., windows, panels, modals, dialog boxes) on the screen.

Note: The initial format of the information in the distinct area will be controlled by the

Position Settings. The Position Settings will be created through the use of Data Templates.

SSD-163 The system must provide the capability to open or close each distinct area independently of other distinct area.

SSD-164 The system must support the presentation of information in a distinct area with various aspect ratios and within various height and width dimensions.

SSD-165 The system must provide the capability for users to toggle between open distinct areas

(e.g., via tabs).

SSD-166 The system must include tools for users to organize information within each distinct area including but not limited to:

a. Sort

b. Hide/show

c.…