Required Navigation Performance Area Navigation (RNP RNAV) Flight Management File (FMF) Application Development Achievement through Collaboration OA Industry Day 17 October 2017 PMA-209 develops, integrates, and delivers avionics solutions that meet customer requirements, enable interoperability, and maximize affordability.
BLUF New strategies for development and integration of Required Navigation Performance Area Navigation (RNP RNAV) capability for Department of the Navy (DoN) aircraft are required to enable cost-wise solutions across multiple platforms that require similar capabilities Processes have been identified involving Open Architecture (OA) techniques to achieve cost avoidance DISCLAIMER: This brief covers a project that is in active stages of Source Selection and/or Competition. The briefing contains no Source Selection sensitive information and no information concerning the pending competition will be disclosed. Some questions/topics cannot be discussed. 2
Agenda Background Why Open Architecture (OA) and Future Airborne Capability Environment (FACE TM )? Technological Hurdles New Business Environment Product Line Engineering/Management How To Develop Previous Efforts/Lessons Learned Basic Acquisition Strategy Make or Buy? FMF Application Strategy FMF Application Functionality Platform Integration Requirements Intellectual Property Rights Response From Industry Independent Verification & Validation (IV&V) Lab/Multi Use Laboratory Environment(MULE) Wrap-Up/Final Thoughts Questions 3
Background What is Future Airborne Capabilities Environment (FACE TM ) Public-Private collaboration to establish value for both customer and supplier Establishes a standard common operating environment to support portable capability-based applications across Department of Defense (DoD) avionics systems Achieved by defining interfaces and processes (design and implementation) Provides Trade-Space for Intellectual Property (IP) rights to fit the requirement Government owns/manages data rights at the interfaces Protects Industry investment by allowing retention of IP to business logic of the capability Standards are platform, software and hardware agnostic FACE TM Conformant Application Definition (for this brief): A software module which enables a specific capability, whose interfaces and data modeling are conformant with the FACE TM standard to enable portability of a capability module across multiple platforms 4
Why OA and FACE TM? Increasing Cost of system development across DoN portfolio requires new strategies to reduce cost growth trends Development costs for RNP RNAV capability are projected to be approximately $50M for each platform Requires DoN to re-invest in creating same capability multiple times Limits competitive environment and opportunities Government has limited rights to majority of the system (must go to Original Equipment Manufacturer) Limits potential growth of the system (ease of upgrades/competitive environment) Directed by Senior Leadership Charter for the Definition, Roles, and Responsibilities for the Naval Aviation Open Architecture Strategy Signed by Commander, Naval Air Systems Command on 3 November 2015 Initial step in implementing a NAVAIR-wide OA process Example: Previous effort for platform integration of RNP RNAV, utilizing the traditional approach was $60M+, which proved to be unaffordable The value of OA has been recognized 5
Technological Hurdles? Can we use OA modular software in our legacy systems? Strategies to introduce an OA, FACE TM supporting environment into legacy systems: Insert into existing system with an appropriate translation layer/library Introduction of an Adjunct Processor YES!!! War-Fighting Platform Portable FACE application Portable FACE application FACE Computing Environment Existing Computer Hardware Avionics Networks Portable FACE application FACE Computing Environment New Computer Hardware NO!!! Is there FACE TM conformant hardware? FACE TM conformant hardware is a misnomer. If the platform provides hardware that can support FACE TM conformant operating system interfaces, it follows that the system can host FACE TM conformant software modules It is highly desired that a modular software architecture is utilized for partitioned software, but not necessary 6
New Business Environment FACE TM aligns with Better Buying Power initiatives Grows the competitive environment to achieve affordability and better control life cycle costs Incentivizes productivity and innovation in Industry and Government Reduces subsequent software development times through modularity and portability (capability driven development) Eliminates redundancy within Warfighter portfolios (software re-use) FACE TM Facilitates Enterprise Level Decision Making Ability to re-use applications across multiple platforms without cross-platform dependencies No need to invest multiple times for same capability Common operating environment and data architecture enables system of systems integration and interoperability Alignment and adaptation with new, existing, and evolving standards Business Case: More opportunities at lower cost 7
Product Line Engineering/Management Product-Centric Development vs. Product Line Engineering Legacy systems development process vs. New shared software modules development Good reference info: BigLever Software, Inc. (www.productlineengineering.com) Move away from many platform specific, stove pipe solutions Separate the hardware and software dependencies Goal: Have a single product or specification that can be modified if necessary to enable a common capability Likely DoN Model - Provide central management of common capabilities to provide efficiencies in: Procurement costs Requirements tracking and management Capability certification processes Sustainment Additional future common capability product lines have been identified by PMA-209 8
How To Develop Customer Product Delivery Requirements Capabilities Management Team Product Evaluation Product Development Team Process/Developmental Support Standards/Subject Matter Experts Refined Requirements Product Line Development Additional Customers 9
Previous Efforts/Lessons Learned Identified hurdles from previous PMA-209 efforts to develop RNP RNAV software module: Contracts and Specification Limited OA software specifications and requirements Result: Additional unplanned work to correct deficiencies Developers familiarity with the FACE TM standard and modular code Inadequate working knowledge of processes and techniques Result: Impacts to Cost/Schedule/Performance (C/S/P) Re-use of existing software Attempt to modularize existing monolithic Operational Flight Program code into FACE TM conformant software modules Result: Encountered unanticipated technical issues and difficulty. Caused additional impacts to C/S/P. 10
Make or Buy? Business Case Analysis (BCA) conducted for FACE TM Flight Management File (FMF) application Considerations Stability of requirements Commercial availability of the capability need Major points from the BCA process Data compiled from Rough Order of Magnitude (ROM) estimates and Requests for Information (RFIs) since 2012 relating to the development of an FMF application Integration costs for FMF application will vary depending upon the structure/architecture of existing platform avionics Do not expect integration costs to go down initially! Solutions generally break down into two categories (Make/Buy): Make: Contract to develop an application wholly owned by Government Buy: Lease a certified civil application 11
Make Option Concept: Vendors/NAVAIR will develop FMF Application (or set of associated modules) for one time cost/fee Re-use of existing software seems to be driving factor for cost and labor Limited offers for this solution (high risk associated with ROMs) Pros: DoN would save on licensing Able to compete the software for improvement without legal barriers Cons: DoN assumes all costs associated with software maintenance and FAA civil certifications (total cost of all these factors is currently unknown) Insufficient NAVAIR experience with FAA flight software development/certification process (not part of PMA-209 processes) NAVAIR would also be solely liable for software errors in an area in which there is no institutional experience/knowledge 12
Buy Option Concept: Buy FMF Application via a license which includes vendor support and maintenance options Possibility exists for short Non Recurring Engineering period Integration, test, and certification costs to be the same as Make option Pros: Provides the least amount direct labor to the Government in terms of development, maintenance and liability Allows the Government to leverage vendor expertise in terms of quality and certification of civil software systems Cons: Possible Government learning curve in managing this type of software leasing package Risk of unavoidable reoccurring maintenance costs required after initial buy PMA-209 Selected buy based upon Lowest Risk and Highest Return On Investment 13
FMF Application Strategy Major requirements documents DoN RNP RNAV Functional Requirements Document (FRD) describes system level solution PMA-209 is using primarily DO-283 and TSO-115 to capture software specific requirements for FMF Application FMF application will be conformant with the FACE TM Technical standard and include a FACE TM Data Model FMF application will be abstracted from any platform specific computing or sensing requirements (with the exception all vendors were informed they can expect a PPS GPS) Challenge: Bounding the functionality needed but allowing flexibility RTCA/DO-283: Minimum Operational Performance Standards for Required Navigation Performance for Area Navigation TSO-C115d: Required Navigation Performance Equipment using Multi-Senor Inputs 14
FMF Application Functionality Path Construction Constructs routes in accordance with RNP RNAV rules using procedures and waypoints extracted from the Navigation Data Base and/or user-defined fixes. Defines the precise path to be flown using Aeronautical Radio, Incorporated (ARINC) 429 leg types. Includes Direct-To, holding patterns, parallel offsets, etc. Provides Standard En-Route and Terminal Area Procedures: Standard Instrument Departures, Standard Terminal Arrival Routes, Radio Navigation (GPS) Approaches, etc. Guidance Computes vertical and horizontal deviations for external use by a Course Deviation Indicator and/or flight director/autopilot. May provide Speed guidance Aircraft State & Progress Continuously computes aircraft position, track, Actual Navigation Performance, and typical Progress Page data Alerting Generates required RNP RNAV alerts Navigational Database Ingestion (Digital Aeronautical Flight Information File) Will accept specific Type/Model/Series performance data (FMF app will only have generic fixed wing/rotary models) Localizer performance with vertical guidance (LPV) capable (platform sensor dependent) Provides the necessary foundation to enable aircraft to use IFR filing code of /G 15
Platform Integration Requirements Operator Machine Interface does not come with pre-built Control Display Unit pages, i.e. no Human Machine Interface Sensor Management Database Management Navigation Database Specific Aircraft Performance Data (Personality Module) Mission Patterns or Mission Management (No tactical operations) Data Concentrator Controls & Displays Platform system specific requirements are handled during integration process 16
Intellectual Property (IP) Rights Using OA and modular approaches allows Government to be flexible in IP contracting Only buy what you need Government Rights to all Parts of the software are unnecessary Only buy those IP Rights necessary to ensure integration into host environment (Minimal Government purpose rights) Includes additional software/coding required to wrap software to achieve FACE conformance Utilize existing software to the greatest extent possible; allow vendor to retain all rights to their IP RNP RNAV algorithms OA facilitates cost avoidance in this case 17
Response From Industry Previous History Initial RFI released in 2012 Previous platform RNP RNAV FACE TM Conformant software efforts (earlier discussed Lessons Learned) Original Equipment Manufacturers asked for estimates to integrate a Government RNP RNAV application Most recent RFI release in 2016 Released RFI for FMF and 11 responses received and reviewed (4Q FY16) Conducted FMF Industry day with 7 briefs from 8 companies (4Q FY16) Pre-solicitation released December 2016 Contained a draft Statement of Work and Specification 12 requests for the draft Specification 8 responses from industry Sources Sought April 2017 5 responses received (2 from small business) RFP released July 2017 Industry appears ready to support the FMF Application 18
IV&V Lab Desire to build and utilize a Government IV&V lab to support the procurement process and gain Government experience FMF app procurement contracting will ensure the vendor conducts IV&V Government IV&V lab testing to demonstrate/ensure portability of the application Actively planning with multiple competencies at NAVAIR Software enterprise wide attention and effort Finishing a Work Breakdown Structure to lay a functional foundation Exploring plan to convert un-used Government owned equipment and test benches to build OA IV&V lab Re-use and convert existing hardware Other spaces and support facilities possible 19
Multi-Use laboratory Environment (MULE) FACE Application Integration Support Lab (AIR 4.5) -OA Software IV&V and Product Support -FMF FACE App Project Avionics Product Support Lab (AIR 4.5) -Hardware IV&V -MCA Project Avionics SIL/SSA (AIR 4.5) -Avionics Hardware and Software Rehost and Integration -OFP/FMF/MCA Rehosting ASTARS (USNTPS) -NTPS Flying OA Test Environment -Possibility to collect actual in flight data Multiple efforts leveraging shared resources 20
Wrap-Up/Final Thoughts PMA-209 is pushing forward on OA Stovepipe system development is unaffordable Risk factors Capturing FMF application requirements/functionality at the correct level Weighing contracting options with offerer's software capabilities Opportunities for additional participants in FMF application Expect multiple vendors with supporting products Using this effort to refine process for how OA software will be developed What skill sets are needed (i.e. software logistics, functional architects) What organizational structures are needed What lab facilities are needed for Government Independent Verification & Validation MULE: Avionics Product Support Lab; FACE Application Integration Support Lab; Avionics Software Integration Lab (SIL) Working with United States Navy Test Pilot School to develop a flying SIL Don t think out of the box, make the box bigger 21
CNS/ATM POCs Anthony Stachowski Phone: 301-757-1539 Email: Anthony.Stachowski@navy.mil Susan Whitley Phone: 301-757-6457 Email: Susan.Whitley@navy.mil 22