Presented to: MPAR Working Group By: Garth Torok, Weather Processors Group, Aviation Weather Directorate Date: 21 June 2007 Federal Aviation Administration

Presented to: MPAR Working Group

By: Garth Torok, Weather Processors Group, Aviation Weather Directorate

Date: 21 June 2007

Federal AviationAdministrationMultifunction Phased

Array Radar

MPAR Concept of Operations (CONOPS)

Multi Function Phased Array Radar2Federal Aviation

Administration21 June 2007

MPAR CONOPS

• Being developed in response to MPAR Working Group Action Item # 2007-1.1 “Using NGATS CONOPS

as a model, develop an MPAR CONOPS rough draft”



MPAR CONOPS Working Group

• Chair– Mark Weadon, OFCM

• Members– Bob Saffle, NWS– Daniel Melendez, NWS– Garth Torok, FAA– Bob Blasewitz, FAA

• May require participation by subject matter experts across disciplines (weather, Surveillance, defense)



CONOPS Influence

Concept of Operations (CONOPS)

Concept of Operations (CONOPS)

Operational Requirements (User Needs)

Operational Requirements (User Needs)

Performance Requirements

(Characteristics)

Performance Requirements

(Characteristics)

Drives

Drives

Radar System Architecture &

Design

Radar System Architecture &

DesignDrives

MPAR Cost

Drives

Scale



CONOPS - Decision Paths• Document content and organization considerations

– Evaluated multiple CONOPS examples• NGATS CONOPS• NGATS Weather CONOPS• Surveillance and Broadcast Services CONOPS (i.e., ADS-B)• Future Terminal Area CONOPS (i.e., DTASS)• CONOPS and Operational Requirements for WSR-88D Dual Polarization• Business Continuity Plan En Route Services CONOPS• NAS CONOPS• Others

– Explored different templates• FAA Operational Concept Template, Version 1.0 (May 1999)• FAA NAS Systems Engineering Manual• NWS Operations and Services Improvement Process (OSIP) Concept of

Operations and Operational Requirements Template



FAA’s System Engineering Manual (SEM) - CONOPS Hierarchy

Where does the MPAR CONOPS

fall?

Answer:Tailored hybrid of CONOPS

and CONUSE



FAA’s System Engineering Manual (SEM) - CONOPS Hierarchy

• CONOPS (Service-Level) – Provides conceptual insight into a particular service of the integrated operational

environment (e.g., nav, surv, comm)– Identifies current shortfalls and future needs– Identifies capabilities required for a specific service (without identifying specific

technologies)– May use Operational Scenarios to illustrate desired operational concept– Provides a user perspective– Not system specific

• CONUSE– Extension of CONOPS with emphasis on specific system and its operating

environment– Describes functional characteristics (i.e., stakeholder’s needs) of a proposed

system from a user perspective– Tells a story using visual forms (diagrams, illustrations, graphs) and storyboards– Describes the user’s general system goals, mission, function, and components

• MPAR CONOPS– Hybrid of a CONOPS and CONUSE



Concept Document Outline1. Introduction

1.1 Service or System Identification1.2 Document Overview1.3 Service or System Overview1.4 References

2. Operational Need2.1 Current Service or System2.2 Current Support Environment2.3 Operational Problems2.4 Objectives and Scope2.5 Capability Shortfalls2.6 Existing Operations Requiring Change 2.7 Constraints2.8 User

3. Service or System Justification3.1 Potential Benefit of New or Modified Service3.2 Description of Desired Change3.3 Change Priorities3.4 Assumptions and Constraints

4. Proposed Service or System4.1 Objectives and Scope4.2 Proposed Service or System Description4.3 Proposed Support Environment4.4 Modes of Operation4.5 User4.6 Operational Policies and Constraints

5. Operational Scenarios6. Impacts

6.1 Impact on Current Operations6.2 Organizational changes Required

Appendix A – Glossary and AcronymsAppendix B – OSED (Oper. Serv. and Envir. Descr.)

Describes current problem space (operational situation and shortfall)

Provides description of the new system and the benefit it will provide

Provides description of the proposed system and its characteristics

Operational Scenarios to help better describe concept

Provides description of impact to operations and the organization



Operational Scenarios



RADAR CONTROL, LOGIC & PROCESSING

DST

AUTOMATION SYSTEM (ADS-B Track correlation)

4-FACEMPAR ANTENNA

RADAR DISPLAY

7

DATAASSIMILATION

1

2

3

4

5

6

8

8

8

1A

Flow of Radar Data/Environmental Data Records (EDRs)

Control of Radar Scanning

7

Feedback Loop

DST

DST

NUMERICAL WEATHER PREDICTION

SWIMGIG

ENTERPRISESVC

5. RADAR DATA TO NWP FOR INGESTION VIA DATA ASSIMILATION6. DATA TO DISPLAY FOR HUMAN INTERPRETATION7. RESULTS FROM NWP FED BACK TO CONTROLLERS FOR MANUAL/AUTOMATIC ADJUSTMENT OF SCAN STRATEGY 8. PROCESSED DATA FED THROUGH ENTRPRISE SERVICES TO DECISION SUPPORT TOOLS (HUMAN OR MACHINE)

1. SIGNAL TO ANTENNA ADAPTING SCAN PATTERN1A. DATA FROM ANTENNA IS PROCESSED INTO EDRs2. AIRCRAFT POSITION INFO TO ADS-B FOR CORRELATION WITH COOPERATIVE REPORTED TRACKS3. AIRCRAFT MISMATCHES FLAGGED TO MPAR AS “TARGETS OF INTEREST” 4. PROCESSED RADAR DATA (AC AND WEATHER) SENT TO USERS VIA NETWORK SYSTEMS



Working Group Tasks

• Define Document scope, organization, and outline• Develop Operational Scenarios and other visual

forms to facilitate understanding of MPAR operation

• Identify agency mission shortfalls that should be addressed by this solution

• Expect MPAR CONOPS to be a “living” document• Working Group Meeting tentatively scheduled for

July– Baseline organization of document– Finalize initial operational scenarios– Begin assigning sections to individuals/agencies



Issues/Decision Points

• How should the document be bound?• What capability is the solution required to

deliver?• Need to identify additional agency SMEs

(e.g., DHS, DOD, etc.) to provide input



Milestones/Dates

Documents

Presented to: MPAR Working Group By: Garth Torok, Weather Processors Group, Aviation Weather Directorate Date: 21 June 2007 Federal Aviation Administration