1 / 25

PETAL II and II Extension Maastricht Multi-stack Implementation Lessons Learnt

PETAL II and II Extension Maastricht Multi-stack Implementation Lessons Learnt. Prepared by Gustaaf Janssens/Konrad Koebe Maastricht UAC. TOPICS. What Do We Mean by Multi-Stack? Why Multi-Stack ? What Are Multi-Stack Design Considerations ? MUAC Ground Architecture

irving
Download Presentation

PETAL II and II Extension Maastricht Multi-stack Implementation Lessons Learnt

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. PETAL II and II ExtensionMaastricht Multi-stack ImplementationLessons Learnt Prepared by Gustaaf Janssens/Konrad Koebe Maastricht UAC

  2. TOPICS • What Do We Mean by Multi-Stack? • Why Multi-Stack ? • What Are Multi-Stack Design Considerations ? • MUAC Ground Architecture • MUAC Schedule Achievements • How Do We Test ? • What Are Our Lessons Learnt ? • Next Steps • Conclusions

  3. What Do We Mean by Multi-Stack ? • Accommodating Existing Specifications for AGDL • NEAN Extension (Prototype VDL4) • FANS-1/A • ATN SARPs • Aim • Communicate With Any Avionics Equipment Using One Of The Specifications

  4. Why Multi-Stack ? • PETAL-II Project Needs for MUAC • Operations - Hide AGDL Technology for User • Operational Requirements Validation Independent From AGDL Technology • Quick Implementation • Project Has to Compete With Daily Life Activities at an Operational Centre • Take Advantage of Existing Operational Avionics Equipment • Encourage ATN SARPs based Air and Ground Implementations

  5. Design Constraints (1) • Fit In MUAC Existing Ground Structure • HMI, FDPS, Gateways • Add Functionality in HMI and FDPS, Add AGDL Gateway • HMI • Add to Normal Controller Presentation and Interface • FDPS • Based on ATN SARPs Ground End User Applications Definitions • AGDL Gateway • Single Access Point for FDPS • Access Points for Underlying AGDL Technologies

  6. Design Constraints (2) • Evolutionary Development • Next Step Building on Results of Predecessor

  7. Controller HMI Controller HMI Controller HMI Controller HMI Flight Data Processing System ATM Services 9705 BER P2GW (PETAL 2 GATEWAY) NEAN GWY FANS-1/A GWY ProATN ES 9705 PER ProATN ROUTER SITA VDL2-ATN NEAN Maastricht Multi-stack GROUND End System (1)

  8. Maastricht Multi-stack GROUND End System (2) Controller HMI Controller HMI Controller HMI Controller HMI Flight Data Processing System - Flight plan / address association - ATN SARPs (ICAO 9705) CM, ADS, CPDLC - All datalink service logic and dialogue control 9705 BER P2GW P2FEP NFEP - Aircraft address/state - ASE emulation CM, CPDLC, ADS - Conv. to NEAN specs. FAFEP - Aircraft address/state - ASE emulation CM, CPDLC, ADS - Conv. To FANS specs ALLA- P2PI - Aircraft address/state - BER-PER Conversion. 9705 PER NEAN Server FANS-1/A Gateway ProATN - ASEs: CM, CPDLC, ADS - ATN Router

  9. Design Constraints (3) • P2GW • Holds and Manages Addressing Data • Buffers FDPS from Unexpected communications • MADAP Msg= {Msg ID, Infra ID+24bits+FID+Reg.Mark+9705-BER-Msg} • Hides Communication and Network Specifics from FDPS

  10. Design Constraints (4) • AGDL Applications implemented • CM, ADS, CPDLC • FDPS AGDL Services Using these Applications • CM: DLIC Acceptance • ADS: ADS demand (FLIPCY), ADS periodic (CAP) • CPDLC: (ACL, ACM, AMC) • FDPS Functionality Used for AGDL • Manages Flight plan Operational Status • DLIC acceptance and ADS, CPDLC requests • Terminates CPDLC, ADS

  11. Design Constraints (5) • Controller Authorisation • Only Controlling Sector handles CPDLC • FDP Controls Sequence Extraction • Next internal or external sector (NDA) identities • Controls Automatic Flight Plan Action • CMContact at OLDI ABI event • CPDLC (NDA) at OLDI ACT event • Extracts Information for Controller HMI • radar picture and tabular display • Provides Authorised Input Sequences and Guidance on Controller HMI

  12. MUAC Schedule Achievements (1) • NEAN IN 4/98 • FANS 1/A 2/99 • P2GW - BAC1/11 using ATIF/SATCOM, P-II message set. 5/00 • MC-P2GW-BAC1/11 Flight using ATIF/SATCOM, P-IIe message set. 9/00 • Application Testing: FDPS-Avionics 11/00 • FDPS, P2GW Ready 3/01

  13. MUAC Schedule Achievements (2) • FANS1/A ONLINE: P-IIe Message set 4/01 • NEAN OUT 4/01 • CERTification Testing Support 5/01 • Non Revenue Flights 6/01 • MUAC-RUAC Shadow Flight 7/01 • Revenue Flight 8/01

  14. MUAC Technical Achievements (1) • ICAO 9705 Compliant FDPS Implementation • Usage of ATN, FANS1/A and Prototype VDL4 • First Fully Certified ATN avionics • CPDLC Flights May1998-June2001 = 8455 (FANS/NEAN) • Test Infrastructure • Test Methodology

  15. How Do We Test (1) ? • Test Approach • Local Tests • HMI, FDPS, P2GW • End-to-End Application Tests: • FDPS- Other ATC Centre - Avionics • grounded avionics • airborne avionics • Operational Observation • Overview of Our Test Configurations

  16. P2GWEMUL FAME AGDG-FANS PSF FDPS EMUL AFAME AGDG ATN NON REV

  17. MAASTRICHT UAC Control Centre P2GW PROATN End System PROATN R FDPS LAN LAN PIIe Operational Observation B767 CPDLC Services VIA ATN/VDL Mode 2 VDL M2

  18. What Are Our Lessons Learnt (1) ? • Step by Step Implementation • NEAN • Validation of Technical Concept and Architecture • FANS 1/A • Validation of ‘Multi Stack’ Concept • HMI, FDPS Independent From AGDL Technology • ATN SARPs • Validation of SARPs Compliant Implementation • Additional Operational Messages and Stack Functions • Lessons • More Testing Effort due to Regression Testing ?

  19. What Are Our Lessons Learnt (2) ? • ATN SARPs Implementation Tests • Early Feedback = Early Application Error Detection and Correction • BAC1-11 Test Flights • ATIF-ground Testing • End-to-End Application testing • No Application Errors Detected During CERT, Non-Revenue and Revenue Flights

  20. What Are Our Lessons Learnt (3) ? • Local Tests as Much as Possible • Avionics Emulators • Test Automation • Protocol Test facilities • External Testing is Expensive • Test Setup • Test Execution • Time Consuming • Good Test Objectives and Strategies

  21. What Are Our Lessons Learnt (4) ? • Future Requirements for Test Tools and Strategies • Reference Test Tools Required • Available For All Implementers • Common Development • A lot of Tools exist. Usable to further develop ? • Reference Test Objectives and Strategies • Separate Test Network Required • Connect Test Systems • Intra Centre Test • Avionics Tests

  22. Next Steps (1) • Complete PETAL-IIe • System Safety Assessment • Document Lessons Learned • Consolidate Documentation • Evaluate Test Automation (GEODE) • New Project (P2L = PETAL To LINK2000+) (in approval and initiation phase)

  23. Next Steps (2) • P2L Objectives • Maintain a State of the Art Implementation of the Existing AGDL Implementation. • Ensure Safety of all Operational Systems • Increase the Number of aircraft applying AGDL Services (FANS, ATN) • Support the LINK 2000+ Project • Enabler for aircraft to equip. • Enabler for other Centres • Enabler for COMS • Enabler for Test and Validation tools - Common Development and Support.

  24. CONCLUSION • MULTI STACK CONCEPT WORKS ! • SERVE MORE AIRCRAFT • CONNECT TO NEIGHBOUR ATC CENTRES THANK YOU PARTNERS FOR THE COOPERATION !

More Related