ATS National Offload Project

ATS National Offload Project

ENROUTE & TERMINAL

CONSOLIDATED OFFLOAD SUPPORT SYSTEM

Battle Plan Version

5/15/1999

Executive overview (non-technical):

Relatively inexpensive, off the shelf, technology is now available that would allow us to meet administrative air traffic requirements concerning ATC performance information we use from air traffic control facilities.

We have historically been restricted to utilizing the actual operational computer systems in both the terminal and enroute field facilities for other than purely operational requirements. Examples are; controller position sign on and off, resource management analysis, aircraft management programs, system safety analysis, error investigation, and traffic counting. This restriction forced us into creating, making changes to, and maintaining other than operational software within our operational radar computer systems.

Every time we needed an enhancement or capability for traffic management, resource management, operational analysis, etc., we were forced to follow a long and sometimes costly process known as a national airspace system change proposal or NCP. The resultant computer modifications within the field operational computers are slow and arduous by today’s standards.

A solution has been discussed at many levels within the AOS, ARS, and AAT organizations for many years. Today, a simple desktop computer is capable of "intercepting" the flow of operational information that every air traffic radar control system produces while it is working. It is possible to "collect" or "offload" this stream of information without the operational computer knowing or caring about the collection process.

Once the raw information is out of the operational computer, it can be processed in a modern PC based automation environment by any air traffic organization that requires the information. By using this technique outside of the operational computer, the highly sensitive national airspace system is immune to any problems with administrative processes that require ATC operational performance information. Administrative systems can be modified at will, without the expense of protecting the NAS. And, most importantly, constant baseline changes and maintenance of operational software caused by administrative requirements become a thing of the past.

Table of Contents

Executive Overview of Project Concepts………………………….………1

Section 1. Objectives and Requirements Justification…………………….3

Section 2. Sample End State Architecture to clarify the project concept....5

Section 3. Project Battle Plan Methods of Operation……………………..7

Section 4. Project Ground Rules………………………………….………..8

Section 5. Project Performance Expectations…………………….….…...10

Sections 6-8. Phased Project Activity Objectives by SME Group….……11

SME Team 1………………………………………………………………11

SME Team 2………………………………………………………………15

SME Team 3………………………………………………………………18

SECTION 1

Air Traffic Service (ATS) Objectives and Justification of Requirements

Overall vision (technical):

· Provide a standard infrastructure that will enable the removal of all non-operational automation functions from the HOST (HOCSR), ARTS (STARS), and Micro EARTS primary and standby operational radar and flight data processors.

Primary benefits overview (technical):

· Will release the primary and secondary processors to function solely on operational radar and flight data functions and decrease the number of variables (software operations) that could negatively impact the NAS.

· Will create a common and "open architecture" point of ATC performance data collection for all administrative activities and many operational support activities that previously where accomplished inside the operational NAS.

· Will eliminate baseline changes to operational NAS systems caused by requirements of ATC mission critical administrative processes.

· Will redirect AOS support personnel into operational only system maintenance and enhancement and lower the overall costs.

· Will lower costs in several current categories. The primary category will likely be lower costs of developing code on modern platforms instead of the Host Computer System (HCS) and ARTS. Will eliminate the internal non-operational requirements of all future ATC radar processing systems.

· Will increase current and future levels of NAS safety due to the present day reductions in support resources and complexity caused by administrative functions inside the operational code.

· Will create an environment that is conducive to Agency IRM standardization, reengineering, and modernization of mission critical administrative activities.

· Will allow a multitude of FAA controllable, NAS system information distribution options for potential user benefit.

· Will dramatically increase the accuracy and lower the costs of the following initiatives; fee-for-service, cost accounting system feeds, AT portion of performance based organization.

· Will improve ATC training with new controller debrief systems.

Requirement:

The direct offload of radar tracking and flight plan data currently recorded by the Continuos Data Recorder (CDR) and System Analysis Recorder (SAR) into the administrative PC environment.

Scope:

The program office for Air Traffic Resource Management shall maintain software responsibility for field facility PC based offload systems in addition to its current administrative ATC software responsibilities.

ATS IRM authority shall have hardware responsibility for all administrative support PC based systems used by field Air Traffic and Airways Facilities in the administration of Air Traffic Control.

Affected Current NAS Systems:

1. ARTS IIe

2. ARTS IIIa

3. ARTS IIIe

4. MICRO EARTS

5. HOST

Note: ARTS IIa, AFSS Model 1, and AFSS OASIS systems will not be supported under this project. AFSS Model 1, and AFSS Oasis offload systems will be supported in a separate MSDT project.

Affected Future NAS Systems:

1. STARS

2. HOCSR / DSR

Project Plan Phase categories:

1. Short Term: Requires some current administrative processing to remain inside operational NAS computers.

2. Mid Term: Continues partial elimination of administrative processing inside operational NAS computers that could not be accomplished in the short term phase due to funding limitations and/or technical issues.

3. Long Term: Eliminates all requirements for administrative processing inside operational NAS computers.

SECTION 2

Possible project end state architecture concept

(technical, final offload stage goals)

ENROUTE

Physically intercept the data stream entering the SAR (HOST) or SARP (DSR/HOCSR).

TERMINAL

Physically intercept the data stream entering the CDR or ODS (ARTS) and ?? (STARS).

For each operational radar processing system, engineer a passive tap configuration that uses only the outbound transmit lines. Determine all possible affects to the NAS system resulting from conditions on the tap line, i.e physical severance, data buffer fillup/data no longer accepted.

If any hardware and or software device is necessary on the tap line to prevent negative affects detected during testing, the device must remain within Operational NAS configuration management.

The collection (offload) PC on the other end of the tap line shall be both hardware and software isolated from the NAS system. NAS operational configuration management ends at the tap line connection point to the offload PC. ATX administrative configuration management begins at the offload PC and extends to the facility administrative LAN.

The offload platform encompasses two stages. The first stage is a high performance processor that acts as an initial pre-parser. Suggest we have a small program in RAM that translates the byte for byte flow out of the relative NAS system raw format into standard ASCII. This would be the logical area to allow the stream (Now ASCII) to gather into packets of 50 bytes or whatever before moving to the stage two area if there is an infrastructure benefit for that.

Stage two on the platform distributes the data for the two primary requirement levels. Level one is the real time data requirement and level 2 is the non-real time or pure administrative data requirement.

Level 1 distribution is immediately routed out an eathernet card, or whatever, into a large hub concentrator with multiple jacks. Agency requirements that need level 1 access plug into the concentrator and parse out what they want for their business processes. The Associate Administrator for Air Traffic Services, ATS-1 shall determine Agency access for level 1 data services.

Level 2 distribution is written directly to file(s) on internal hard disk drives. The physical drives are on either the pre-parser or are on a separate PC called the "level 2 distribution PC". I would suggest that we write the data into at least two separate drives for redundancy. The files can close every 5 minutes? 10? half hour ? hour ? day at midnight?. Files are automatically overwritten on a predefined schedule depending on drive space and administrative retention requirements. Agency requirements that need level 2 access have network paths to the files as they close out. The files are copied off the hard drives and parsed on external administrative systems.

SECTION 3

Project Battle Plan Methods of Operation

Project Subject Matter Expert (SME) teams:

ATC operational NAS radar processing systems will be devided into 3 groups. SME teams will be formulated independently for each group and will not exceed 22 members per team. Team members are expected to be particularly progressive and open minded regarding non traditional ways of conducting business and accomplishing objectives.

Teams shall contain a majority percentage of field personnel with appropriate experience levels in their current system areas and direct system user experience to encapsulate the current field realities of day to day operations with their systems. Team LOB breakdowns will be roughly 45% AAT, 45% AAF/AOS, and 10% ARS.

Team 1: ARTS IIe and Micro EARTS

Team 2: ARTS IIIa, ARTS IIIe, and STARS

Team 3: HOST and HOCSR/DSR

Each SME team will work independently on the relevant phase objectives for their systems of responsibility.

Headquarters Triumvirate Steering Group (Top 3 Team)

Washington headquarters will facilitate overall project operations via a "Top 3" team that will include an ATC system expert from ATX, ATO, and AOS. One member of the top 3 team must include the national project lead and is subject to change based on overall project performance.

AAT-1 and AAF-1 have the authority to replace top 3 members based on performance.

The top 3 team delegates authority to make project activity decisions to the relative sme teams within the provisions of the battle plan ground rules.

FAA support organizations that are considered "stakeholders" and wish to be involved will each designate a single member to act as a requirements advisor to the top 3 team. Stakeholder advisors will not have any direct decision authority over sme teams. The top 3 team will pass on stakeholder issues and requirements to the relative sme teams for consideration as appropriate.

SECTION 4

Project Ground Rules

NAS configuration management shall be respected at all times during project activities. At no time shall any project action take place that could possibly jeopardize the safety of the NAS. SME teams shall consult with the top 3 team whenever a project action is considered to have a questionable or borderline NAS safety issue.

SME teams collectively shall have total authority on project objectives for offload system design, implementation plans, architecture, and COTS hardware. This authority shall not supersede ground rule #1. Accountability for that authority will be regulated via top 3 team authority to add or delete sme team members.

The ATX-400 MSDT will ultimately be responsible for the consolidated parser software and related ATC administrative software.

Email will be used as the formal medium for strategy discussions and issue discussions among sme

members. It is very helpful and expected that individual SME members will consult with non SME members regarding project issues and bring back insight to the team, but, SME members shall not bring outside experts into the formal email discussions. Only SME and top 3 members shall be listed in the address lines of ccmail. This will keep email traffic at a manageable level. When you consult with outside experts, forward them a copy of the email so that other SME’s are not bogged down with your off-line research. SME to SME email activity must be cc’d to the HQ project lead. Do not cc off-line email unless you consider the material to be disruptive to the group.

Telcons shall be used as the formal medium for all sme project decisions. Project decisions on the table left unresolved will be forwarded to the next email discussion week. The top 3 team will administrate each telcon from headquarters. SME’s participating on each telcon will have the authority to finalize project decisions if 80% or better of the participating SME’s concur with the decision on the table. There will be NO quorum minimum. Each SME will have previous knowledge of table items for the scheduled telcon. If you concur with the general consensus during the email period on all table items, you do not need to get on the telcon unless you want to. If no SME’s are on a telcon, the top 3 team will wrap up the project decisions on the table based on the email consensus.

Operational duties shall always take priority over project activity. If you are going to miss a critical telcon, SME’s may register their table votes via email with the project lead.

SME groups and the top 3 team shall conduct decided project activities via the most informal routes feasible. The only exception is when project activity impacts NAS configuration management, where formal procedures shall be followed. SME groups shall advise the top 3 team when "feathers" have been ruffled due to informal activity procedures so that HQ can run interference. The intent of this tactic is to gain maximum productivity within our limited SME time resources by not getting too hindered by traditional formal processes. Careful and tactful use of this in non safety related activities can be highly effective.

SECTION 5

Project Performance Expectations

SME teams:

· Maintain a professional attitude during email and telcon discussion periods.

· Abide by the project battle plan ground rules.

· Actively make your opinions known to fellow SME’s and the top3 team concerning all relevant aspects of project activities.

· Aggressively implement decided project activity.

· Advise your fellow SME’s and the top 3 team immediately when you suspect a project activity error has occurred.

Top 3 team:

· Maintain a professional attitude during email and telcon discussion periods.

· Abide by the project battle plan ground rules.

· Actively make your opinions known to relative SME groups concerning all relevant aspects of project activities.

· Aggressively safeguard SME members while in performance of project objectives.

· Keep the project lead informed of overall activity.

· Run political interference when project activities are being hampered by "stone-walling", "turf-protection", and other traditional derailing tactics.

Project lead:

· Maintain a professional attitude during email and telcon discussion periods.

· Abide by the project battle plan ground rules.

· Actively make your opinions known to fellow top 3 members concerning all aspects of project activities.

· Aggressively safeguard SME members while in performance of project objectives.

· Work STARS project activity.

· Keep ATX-1, ATO-1, ATA-1, AAT-1, AAF-1, and ATS-1 informed of overall project activity and measurable project performance.

· Track and review all SME email discussion traffic.

· Aggressively enhance political interference using all available alliances when project activities are being hampered by "stone-walling", "turf-protection", and other traditional derailing tactics.

· Keep FAA stakeholders informed of project activity issues on the table for scheduled telcons.

Stakeholders:

· Advise top 3 team members of project activity issues that are relative to their LOB requirements.

· Join the top 3 team during scheduled project activity telcons to maintain up to date knowledge of project developments.

SECTIONS 6 - 8

Phased Project Activity Objectives by SME Group

SME Team 1

Section 6a. Short Term Phase

ARTS IIe System

The overall short term phase objective for this system is to conduct groundwork analysis for the mid term phase passive all raw data tap implementation and leverage any existing offload system and or internal administrative software for a partial offload.

· Analyze hardware infrastructure of the operational system.

· Determine passive tap hardware point options.

· Analyze the CDR infrastructure.

· Identify any existing PC based taps on the system at any location nationally.

· Identify any internal administrative software processes running inside the system. i.e. SISO, Traffic count, etc.

· If no internal administrative processes running, then proceed directly to the mid term phase for this system.

· If any internal administrative software running, develop a PC based hardware plan to offload the administrative data produced internal to the ops system.

· Select a key site for testing that maximizes support and ease of planned implementation.

· Initiate a test case file.

· Identify parsing requirements for the MSDT.

· Develop a rapid test implementation plan.

· Implement the test plan at the key site.

· Assist MSDT with parser installation and output testing.

· Assist the top 3 team with the national PIP.

· Proceed to mid term phase this system.

MICRO EARTS

· Analyze hardware infrastructure of the operational system.

· Determine passive tap hardware point options.

· Analyze the CDR infrastructure.

· Identify any existing PC based taps on the system at any location nationally.

· Identify any internal administrative software processes running inside the system. i.e. SISO, Traffic count, etc.

· If no internal administrative processes running, then proceed directly to the mid term phase for this system.

· If any internal administrative software running, develop a PC based hardware plan to offload the administrative data produced internal to the ops system.

· Select a key site for testing that maximizes support and ease of planned implementation.

· Initiate a test case file.

· Identify parsing requirements for the MSDT.

· Develop a rapid test implementation plan.

· Implement the test plan at the key site.

· Assist MSDT with parser installation and output testing.

· Assist the top 3 team with the national PIP.

· Proceed to mid term phase this system.

Section 6b. Mid Term Phase

ARTS IIe

The overall mid term phase objective for this system is to implement a PC based full data passive tap and prepare the partial offload system for phase out.

· Determine best hardware tap point based on prep-work done in the short term phase.

· Determine tap infrastructure that guarantees one-way data flow.

· Develop a rapid test implementation plan. Leverage the existing PC based offload parser if practical.

· initiate a test case file for the same key site identified in the short term phase or have a good reason to select a different key site.

· Identify parsing requirements for the MSDT.

· Initiate National NCP.

· Implement the test plan at the key site.

· Assist MSDT with parser installation and output testing.

· Assist the top 3 team with the national PIP.

· Proceed to the long term phase for this system.

MICRO EARTS

The overall mid term phase objective for this system is to implement a PC based full data passive tap and prepare the partial offload system for phase out.

· Determine best hardware tap point based on prep-work done in the short term phase.

· Determine tap infrastructure that guarantees one-way data flow.

· Develop a rapid test implementation plan. Leverage the existing PC based offload parser if practical.

· initiate a test case file for the same key site identified in the short term phase or have a good reason to select a different key site.

· Identify parsing requirements for the MSDT.

· Initiate National NCP.

· Implement the test plan at the key site.

· Assist MSDT with parser installation and output testing.

· Assist the top 3 team with the national PIP.

· Proceed to the long term phase for this system.

Section 6 c. Long Term Phase

ARTS IIe

The overall long term phase objective for this system is to implement the external barcode SISO system Project Plan and integrate it into the full data offload system.

· Objectives steps to be determined.

MICRO EARTS

The overall long term phase objective for this system is to implement the external barcode SISO system Project Plan and integrate it into the full data offload system.

· Objectives steps to be determined.

SME Team 2

Section 7 a. Short Term Phase

ARTS IIIa

The overall short term phase objective for this system is to conduct groundwork analysis for the mid term phase passive all raw data tap implementation and leverage the ASCS offload system and existing internal administrative software for a partial offload.

· Analyze hardware infrastructure of the operational system.

· Determine passive tap hardware point options including Dimensions International CDR/ODS offload system or equivalent.

· Initiate a national NCP to transfer equipment responsibility of the "ASCS offload PC platform" to ATS IRM maintenance and to terminate NAS configuration management responsibility at the one way serial cable connection into the "ASCS offload PC platform".

· Select a key site for testing that maximizes support and ease of planned implementation.

· Initiate a test case file.

· Debate best options for the internal ARTS parsing patches to send data to the offload PC, keeping reclass requirements in mind.

· Select best internal ARTS parsing option.

· Debate best options for the external PC based track message and SISO parser to be installed on the offload PC.

· Transfer applicable source code and decided parsing requirements for MSDT integration.

· Debate best options for the network configuration of the offload PC and transmission of parsed data to the level 1 and 2 services.

· Design complete offload hardware and network archetecture.

· Assist MSDT with ASCS PC OS support software reconfiguration.

· Assist MSDT with new parser installation and output testing.

· Assist the top 3 team with the national PIP.

· Initiate procedures for any future changes made by AOS to the operational NAS software that affects serial output format to the offload PC platform be coordinated with the ATX-400 MSDT for parser modification..

· Proceed to mid term phase for this system.

ARTS IIIe

· Analyze hardware infrastructure of the operational system.

· Determine passive tap hardware point options including Dimensions International CDR/ODS offload system or equivalent.

· Determine if any pure operational functions being performed by PDPC.

· Determine if PDPC connection can be converted to passive tap.

· Initiate an NCP to convert PDPC connection to a passive tap, transfer equipment responsibility of the PDPC platform to ATS IRM maintenance, and terminate NAS configuration management responsibility at the one way serial cable connection into the platform.

· If the PDPC is determined NOT to be a valid offload candidate then design an alternate PC based infrastructure and implemenation plan.

· Select a key site for testing that maximizes support and ease of planned implementation.

· Initiate a test case file.

· Debate best options for the internal ARTS parsing patches to send data to the offload PC.

· Select best internal parsing option.

· Debate best options for the external PC based track message and SISO parser to be installed on the offload PC.

· Transfer applicable source code and decided parsing requirements for MSDT integration.

· Debate best options for the network configuration of the offload PC and transmission of parsed data to the level 1 and 2 services.

· Design complete offload archetecture.

· Assist MSDT with offload PC OS support software reconfiguration.

· Assist MSDT with new parser installation and output testing.

· Assist the top 3 team with the national PIP.

· Proceed to mid term phase for this system.

Section 7 b. Mid Term Phase

ARTS IIIa

The overall mid term phase objective for this system is to implement a PC based full data passive tap and prepare the partial offload system for phase out.

· Determine best hardware tap point based on prep-work done in the short term phase.

· Determine tap infrastructure that guarantees one-way data flow.

· Where an existing Dimensions International (DI) CDR offload system or equivalent system is already installed at the facility, develop an implementation plan to intercept the raw data flow while allowing it to continue to the DI PC platform. Note: The DI is beyond ops configuration management.

· Develop a rapid test implementation plan. Leverage the existing PC based offload parser if practical.

· initiate a test case file for the same key site identified in the short term phase or have a good reason to select a different key site.

· Identify parsing requirements for the MSDT.

· Implement the test plan at the key site.

· Assist MSDT with parser installation and output testing.

· Assist the top 3 team with the national PIP.

· Proceed to the long term phase for this system.

ARTS IIIe

The overall mid term phase objective for this system is to implement a PC based full data passive tap and prepare the partial offload system for phase out.

· Determine best hardware tap point based on prep-work done in the short term phase.

· Determine tap infrastructure that guarantees one-way data flow.

· Develop a rapid test implementation plan. Leverage the existing PC based offload parser if practical.

· initiate a test case file for the same key site identified in the short term phase or have a good reason to select a different key site.

· Identify parsing requirements for the MSDT.

· Implement the test plan at the key site.

· Assist MSDT with parser installation and output testing.

· Assist the top 3 team with the national PIP.

· Proceed to the long term phase for this system.

Section 7 c. Long Term Phase

ARTS IIIa and ARTS IIIe and STARS

The overall long term phase objective for this system is to implement the external barcode SISO system Project Plan and integrate it into the full data offload system.

· Objective steps to be determined.

SME Team 3

Section 8 a. Short Term Phase

HOST

The overall short term phase objective for this system is to design and implement a passive all raw data tap implementation for tracking, flight data, and SISO. For this phase, SISO data will become pass-through only. Modify Ze089 NLPL to accept and carry the SISO message only without error checking or processing of any kind. The unprocessed SISO messages will be intercepted by the offload system and processing will be accomplished on the administrative LAN computers. All feedback will be accomplished through PC terminals established in the areas.

· Analyze hardware infrastructure of the operational system.

· Determine hardware impact of DSR and HOCSR.

· Determine if prepratory work concerning the HID/LAN inability to capture AMP level data elements is accurate.

· Determine passive tap hardware point options that meet data capture requirements.

· Initiate Ze/f089 NLPL pass-through modification with contingency for failure of project objectives concerning the passive tap.

· Select best tap hardware point.

· Determine preselected key site of ZHU for testing is best option to maximize support and ease of planned implementation.

· Initiate a test case file.

· Initiate required national NCP’s

· Determine code leverage scope of ZHU special project activity for the native Host data preparser.

· Establish a preparser development plan.

· Initiate preparser data plan.

· Forward preliminary data format of preparsed stream to MSDT for consolidated parser preparation.

· Debate best options for the network configuration of the offload PC and transmission of parsed data to the level 1 and 2 services.

· Design complete offload hardware and network archetecture.

· Assist MSDT with offload PC configuration.

· Assist MSDT with new parser installation and output testing.

· Assist the top 3 team with the national PIP.

· Proceed to mid term phase for this system.

Section 8 b. Mid Term Phase

HOST / HOCSR(DSR)

The phase objectives for this system are to initiate the external barcode system to allow the complete removal of the last remnants of NLPL Zf089 from HOCSR.

· Objective steps to be determined.

Section 8 c. Long Term Phase

HOST / HOCSR(DSR)

Long term phase not required due to start point of system infrastructure and availability of already developed special project system leverage.