• Author / Uploaded
• Ivan Milosevic

Citation preview

---

AIRCOM® ServerPlatform Administrator Guide March 21, 2018 Version 6.9

ASP Administrator Guide Version 6.9a

T HIS IS AN EXTERNAL DOCUMENT AND DATA PROTECTION DOES APPLY. SITAONAIR reserves the right to make changes to this document at any time without prior notice.

Last revision date: March 21, 2018 © SITA / SITAONAIR 2000 DATA PROTECTION STATEMENT The information and data provided herein shall not be duplicated, disclosed or disseminated by the recipient in whole or in part whatsoever without prior permission from SITAONAIR. Should a contract be awarded as a result of this information or where information and data is used in the performance of a contract such contract would include an appropriate condition governing the extent to which the recipient may duplicate, disclose or disseminate the information and data provided. This restriction does not limit the right of the recipient to use the information contained in the data if it is obtained from another source without restriction.

All rights reserved

2

ASP Administrator Guide Version 6.9a

TABLE OF CONTENTS 1.

SCOPE .............................................................................................................................................................. 13 IDENTIFICATION ........................................................................................................................................ 13 SYSTEM OVERVIEW ................................................................................................................................... 14 TERMS AND ACRONYMS ............................................................................................................................ 15 APPLICABLE DOCUMENTS ......................................................................................................................... 16 1.4.1. SITAONAIR Documents .................................................................................................................. 16 1.4.2. Non-SITAONAIR Documents .......................................................................................................... 17

2.

GENERAL INFORMATION ......................................................................................................................... 18 USERS ........................................................................................................................................................ 18 Local Users ..................................................................................................................................... 18 External Users................................................................................................................................. 19 Logging In Read-Only Mode........................................................................................................... 19 EDITING MODES ........................................................................................................................................ 20 2.2.1. List and Tree Navigation................................................................................................................. 21 SYSTEM LIMITS ......................................................................................................................................... 22 2.3.1. General Messages Length Limits .................................................................................................... 22 2.3.2. Templates Limits (for downlink, uplink and ground messages) ...................................................... 22 2.3.3. Other System Limits ........................................................................................................................ 23 MAIN WINDOW ......................................................................................................................................... 24 2.1.1. 2.1.2. 2.1.3.

3.

FLIGHT TRACKING ADMINISTRATION ................................................................................................ 29 FLIGHT TRACKER SETUP ............................................................................................................................ 29 FLIGHT TRACKER DISPLAY OPTIONS & MAP ICONS ................................................................................... 29 3.2.1. Display ............................................................................................................................................ 31 3.2.1.1. 3.2.1.2. 3.2.1.3. 3.2.1.4.

3.2.2.

4.

Map Elements ..................................................................................................................................................... 31 Flight Stage Colors ............................................................................................................................................. 32 Clusters ................................................................................................................................................................ 32 World Map Center Longitude ............................................................................................................................ 32

Layers.............................................................................................................................................. 33 MAP ANIMATIONS ...................................................................................................................................... 33 UPDATE FIR/UIR INFORMATION ............................................................................................................... 34

TEMPLATES ADMINISTRATION .............................................................................................................. 35 4.1.1.

TEMPLATES WINDOW ................................................................................................................................ 35 Categories and Predefined Templates ............................................................................................ 35

4.1.1.1. 4.1.1.2. 4.1.1.3. 4.1.1.4. 4.1.1.5. 4.1.1.6. 4.1.1.7.

4.1.2. 4.1.3. 4.1.4. 4.1.4.1. 4.1.4.2. 4.1.4.3. 4.1.4.4. 4.1.4.5.

4.1.5.

SITAONAIR

Downlink From Aircraft .................................................................................................................................... 35 Uplink From External User ................................................................................................................................ 37 Uplink From Local User .................................................................................................................................... 38 Uplink Computer-Generated.............................................................................................................................. 39 Ground From External User............................................................................................................................... 40 Ground From Local User ...................................................................................................................................42 Ground Computer-Generated ............................................................................................................................ 43

Typical Message Processing ........................................................................................................... 43 Template Core Functions ................................................................................................................ 46 Templates Description .................................................................................................................... 50 General Panel ...................................................................................................................................................... 52 Records Panel ..................................................................................................................................................... 59 Fields Panel ......................................................................................................................................................... 63 Advanced Panel .................................................................................................................................................. 72 Templates From Local User............................................................................................................................... 77

Template Models ............................................................................................................................. 78

iii

2001VLLYSUM138

ASP Administrator Guide Version 6.9a

4.1.5.1. 4.1.5.2. 4.1.5.3. 4.1.5.4. 4.1.5.5.

Formatting Datetime Fields ............................................................................................................................... 84 Model Character Conversion ............................................................................................................................. 84 Model Properties................................................................................................................................................. 85 CRC Calculation ................................................................................................................................................. 87 Models used as SQL queries .............................................................................................................................. 89

4.1.6. 4.1.7.

Template Field Definition Wizard ................................................................................................... 90 Template Record Definition Wizard ................................................................................................ 95 TEMPLATES DISTRIBUTION ...................................................................................................................... 101 4.2.1. Dynamic Groups ........................................................................................................................... 105 4.2.2. Downlink Templates Distribution Specifics .................................................................................. 105 4.2.3. Uplink Templates Distribution Specifics ....................................................................................... 107 4.2.4. Uplink Templates User Copy Specifics ......................................................................................... 108 4.2.5. Ground Templates Distribution Specifics ..................................................................................... 110 4.2.6. Function Description .................................................................................................................... 112 4.2.7. Data Description........................................................................................................................... 113 TEMPLATES PERMISSIONS WINDOW ........................................................................................................ 114 4.3.1. Function Description .................................................................................................................... 115 4.3.2. Data Description........................................................................................................................... 116 DOWNLINK ACKNOWLEDGEMENT ........................................................................................................... 116 4.4.1. Data Description........................................................................................................................... 117 AIRPORT DISTRIBUTION WINDOW ........................................................................................................... 118 4.5.1. Function Description .................................................................................................................... 120 4.5.2. Data Description........................................................................................................................... 120 5.

AIRCRAFT ADMINISTRATION ............................................................................................................... 122 AIRCRAFT TRACKING AND UPLINK MANAGEMENT ................................................................................. 122 AIRCRAFT TRACKING AND UPLINK HOLD PERIODS ................................................................................. 122 FLEET CONFIGURATION WINDOW ........................................................................................................... 122 5.3.1. Function Description .................................................................................................................... 123 5.3.2. Data Description........................................................................................................................... 125 5.3.3. How To .......................................................................................................................................... 127 5.3.3.1. 5.3.3.2. 5.3.3.3. 5.3.3.4.

Define the aircraft type if not available in the list .......................................................................................... 127 Define the ACARS MU if not available in the list ......................................................................................... 127 Define Event Handling for the entire fleet ...................................................................................................... 127 Get the complete fleet configuration in a comma-delimited text file............................................................ 127

AIRCRAFT TYPES WINDOW ..................................................................................................................... 128 Function Description .................................................................................................................... 128 AIRCRAFT LOCKOUT MANAGEMENT WINDOW ....................................................................................... 130 5.5.1. Data & Function Description ....................................................................................................... 131 ACARS MU WINDOW ............................................................................................................................ 132 5.6.1. Function Description .................................................................................................................... 133 HONEYWELL ENCRYPTION CONFIGURATION WINDOW ........................................................................... 134 DFM FLIGHT ROUTES EVENT HANDLING WINDOW ................................................................................ 140 5.8.1. Function Description .................................................................................................................... 142 DFM FREQUENCY SETS WINDOW ........................................................................................................... 149 5.9.1. Function Description .................................................................................................................... 150 FLIGHT E VENTS HANDLING WINDOW ..................................................................................................... 152 5.10.1. Function description ..................................................................................................................... 153 5.10.2. Available events ............................................................................................................................ 153 5.4.1.

5.10.2.1. 5.10.2.2. 5.10.2.3. 5.10.2.4. 5.10.2.5.

5.10.3.

SITAONAIR

Enter / leave area .............................................................................................................................................. 154 Flight Route - Alerting (FR-A) ........................................................................................................................ 155 Lateral deviation ............................................................................................................................................... 156 No reported position ......................................................................................................................................... 157 Vertical deviation ............................................................................................................................................. 157

Action sets ..................................................................................................................................... 160

iv

2001VLLYSUM138

ASP Administrator Guide Version 6.9a

5.10.4. Available actions ........................................................................................................................... 160 AFDAS FAULT MANAGEMENT WINDOW................................................................................................ 162 5.11.1. Function Description .................................................................................................................... 163 5.11.2. Data Description........................................................................................................................... 165 AFDAS FAULT NOTIFICATION WINDOW ................................................................................................ 167 5.12.1. Function Description .................................................................................................................... 168 5.12.2. Data Description........................................................................................................................... 168 SEQUENCER WINDOW ............................................................................................................................. 169 5.13.1. Sequencer Concepts ...................................................................................................................... 170 5.13.2. Sequences Steps............................................................................................................................. 171 5.13.3. Function Description .................................................................................................................... 174 5.13.4. Data Description........................................................................................................................... 176 6.

USERS ADMINISTRATION ....................................................................................................................... 177 6.1.1. 6.1.2. 6.1.3. 6.1.4.

USERS AND GROUPS WINDOW................................................................................................................. 177 Function Description .................................................................................................................... 179 User Data ...................................................................................................................................... 180 Advanced Options ......................................................................................................................... 187 User Types .................................................................................................................................... 191

6.1.4.1. 6.1.4.2. 6.1.4.3. 6.1.4.4. 6.1.4.5. 6.1.4.6. 6.1.4.7. 6.1.4.8. 6.1.4.9. 6.1.4.10. 6.1.4.11. 6.1.4.12. 6.1.4.13. 6.1.4.14. 6.1.4.15. 6.1.4.16. 6.1.4.17. 6.1.4.18.

6.2.1.

Local Users ....................................................................................................................................................... 192 Groups ............................................................................................................................................................... 192 Desks .................................................................................................................................................................193 Type B ............................................................................................................................................................... 194 TCP .................................................................................................................................................................... 195 MQSeries Application ...................................................................................................................................... 195 MSMQ Application .......................................................................................................................................... 195 E-Mail Users and Lotus Notes......................................................................................................................... 196 File ..................................................................................................................................................................... 199 FTP .................................................................................................................................................................... 202 Printer ................................................................................................................................................................ 203 SMS ................................................................................................................................................................... 204 Database ............................................................................................................................................................ 205 Loopback........................................................................................................................................................... 206 AFTN.................................................................................................................................................................207 FlightPlanner Address ...................................................................................................................................... 207 Fax ..................................................................................................................................................................... 207 ATC Center ....................................................................................................................................................... 208

USER RIGHTS AND ROLES ....................................................................................................................... 208 User Rights Window...................................................................................................................... 209

6.2.1.1.

List of User Rights............................................................................................................................................ 210

ROLES WINDOW ...................................................................................................................................... 214 PROFILES WINDOW ................................................................................................................................. 216 6.4.1. Impersonating a profile................................................................................................................. 218 ACCOUNT POLICIES WINDOW ................................................................................................................. 220 6.5.1. Function Description .................................................................................................................... 221 6.5.2. Data Description........................................................................................................................... 221 7.

SYSTEM ADMINISTRATION .................................................................................................................... 225 7.1.1. 7.1.2.

SYSTEM PARAMETERS WINDOW ............................................................................................................. 225 Function Description .................................................................................................................... 226 Data Description........................................................................................................................... 227

7.1.2.1. 7.1.2.2. 7.1.2.3. 7.1.2.4. 7.1.2.5.

SITAONAIR

General Tab ....................................................................................................................................................... 227 Database Tab..................................................................................................................................................... 230 Message Handling Tab ..................................................................................................................................... 236 Tracking Tab ..................................................................................................................................................... 241 Third Parties Tab .............................................................................................................................................. 245

v

2001VLLYSUM138

ASP Administrator Guide Version 6.9a

7.1.2.6. 7.1.2.7. 7.1.2.8.

Flight Assignment Tab ..................................................................................................................................... 250 SATCOM Tab................................................................................................................................................... 252 FlightPlanner Tab ............................................................................................................................................. 254

SYSTEM MONITORING ............................................................................................................................. 256 DATA LINK SERVICE PROVIDERS WINDOW ............................................................................................. 256 7.3.1. Function Description .................................................................................................................... 257 7.3.2. Data Description........................................................................................................................... 257 VALUE LOOKUP TABLE WINDOW............................................................................................................ 259 7.4.1. Function Description .................................................................................................................... 261 7.4.2. Data Description........................................................................................................................... 262 7.4.3. Value List Browsing ...................................................................................................................... 263 VHF STATIONS ....................................................................................................................................... 264 7.5.1. Function Description .................................................................................................................... 265 7.5.2. Data Description........................................................................................................................... 266 7.5.3. Display of Stations on the Map ..................................................................................................... 268 7.5.4. Station Import ............................................................................................................................... 268 7.5.4.1.

Station Overwrite Rules ................................................................................................................................... 270

CUSTOM F IELDS WINDOW ....................................................................................................................... 271 7.6.1. Function Description .................................................................................................................... 272 7.6.2. Data Description........................................................................................................................... 272 8.

MISCELLANEOUS....................................................................................................................................... 273 8.1.1. 8.1.2. 8.1.3.

9.

EVENT HANDLING WINDOWS .................................................................................................................. 273 Function Description .................................................................................................................... 274 Configurable Events ...................................................................................................................... 275 Notification Message Examples .................................................................................................... 278

FUNCTION REFERENCE ........................................................................................................................... 279 9.1.1.

MESSAGE DISTRIBUTION AND NOTIFICATION ......................................................................................... 279 Distributing Messages Based on Dynamic Flight Assignments .................................................... 279

9.1.1.1. 9.1.1.2. 9.1.1.3. 9.1.1.4.

9.1.2. 9.1.2.1. 9.1.2.2. 9.1.2.3.

9.1.3. 9.1.3.1. 9.1.3.2.

9.1.4. 9.1.4.1. 9.1.4.2.

9.1.5. 9.1.5.1. 9.1.5.2. 9.1.5.3.

9.1.6. 9.1.6.1. 9.1.6.2.

9.1.7. 9.1.7.1. 9.1.7.2.

9.1.8. 9.1.8.1.

SITAONAIR

What is the Dynamic Flight Assignments Feature ......................................................................................... 279 Involved Configuration .................................................................................................................................... 279 Sending Dynamic Flight Assignment Messages ............................................................................................ 282 How to Use Dynamic Flight Assignment ....................................................................................................... 283

Uplink Message Storing ................................................................................................................ 285 What is Uplink Message Storing ..................................................................................................................... 285 Involved Configuration .................................................................................................................................... 285 How to Track Stored Uplink Messages........................................................................................................... 286

Mailbox Message Notification ...................................................................................................... 287 What is Mailbox Message Notification........................................................................................................... 287 Involved Configuration .................................................................................................................................... 287

Deactivating Message Distribution to a User ............................................................................... 288 What is Message Distribution Activation ....................................................................................................... 288 Involved Configuration .................................................................................................................................... 288

Performing Direct Type B Addressing .......................................................................................... 288 What is Direct Type B Addressing .................................................................................................................. 288 Involved Configuration .................................................................................................................................... 289 How to Use Direct Addressing ........................................................................................................................ 289

Enhanced Uplink Routing ............................................................................................................. 289 What is Enhanced Uplink Routing .................................................................................................................. 289 Involved Configuration .................................................................................................................................... 291

Uplinks Hold & Wait Options ....................................................................................................... 292 What is the Uplinks Hold & Wait ................................................................................................................... 292 Involved Configuration .................................................................................................................................... 293

Uplink Delivery Status Notification (Uplink Acknowledgement) .................................................. 293 What is Uplink Delivery Status Notification .................................................................................................. 293

vi

2001VLLYSUM138

ASP Administrator Guide Version 6.9a

9.1.8.2.

9.1.9. 9.1.9.1. 9.1.9.2.

9.2.1.

9.2.2.

9.2.3.

Flight Plan Providers and Content................................................................................................................... 300 Matching to a Tracked Flight........................................................................................................................... 303 Flight Plan and Pre-Departure Clearance (PDC) ............................................................................................ 304

Callsign Handling ......................................................................................................................... 304

9.2.3.1. 9.2.3.2.

9.2.4.

Flight Identifier vs Callsign ............................................................................................................................. 304 Mapping Flight Identifiers to Callsigns .......................................................................................................... 305

Canceling Queued Uplink Messages............................................................................................. 306

9.2.4.1. 9.2.4.2. 9.2.4.3.

9.2.5. 9.2.6.

What is a Cancelled Uplink ............................................................................................................................. 306 Involved Configuration .................................................................................................................................... 306 How to Cancel Uplinks .................................................................................................................................... 306

Duplicate Message Handling ........................................................................................................ 306 Dynamic Frequency Management (DFM) .................................................................................... 308

9.2.6.1. 9.2.6.2.

9.2.7.

What is DFM?................................................................................................................................................... 308 Involved Configuration .................................................................................................................................... 309

FE Interface .................................................................................................................................. 313

9.2.7.1. 9.2.7.2.

9.2.8.

Positions reported on the ground ..................................................................................................................... 313 Fuel On-Board (FOB) Range Rings ................................................................................................................ 314

FE Offline Mode............................................................................................................................ 314

9.2.8.1. 9.2.8.2.

9.2.9.

What is FE Offline Mode? ............................................................................................................................... 314 Involved Configuration .................................................................................................................................... 314

ETA Changed Event and Notification ........................................................................................... 315

9.2.9.1. 9.2.9.2.

9.2.10. 9.2.10.1. 9.2.10.2.

9.2.11. 9.2.11.1. 9.2.11.2. 9.2.11.3. 9.2.11.4. 9.2.11.5.

9.2.12. 9.2.12.1. 9.2.12.2.

What is ETA Changed Event & Notification?................................................................................................ 315 Involved Configuration .................................................................................................................................... 315

Fuel Conservation Monitoring (FCM) .......................................................................................... 316 What is FCM? ................................................................................................................................................... 316 What to Configure to Use FCM? ..................................................................................................................... 316

Using the Sequencer...................................................................................................................... 318 What is the Sequencer? .................................................................................................................................... 318 Constructing a Sequence .................................................................................................................................. 320 Demonstration Sequence: Auto-request position reports............................................................................... 322 Demonstration Sequence: Auto-request position reports and alerts if no positions..................................... 324 Demonstration Sequence: Send init data in order .......................................................................................... 327

Using Flight Route - Alerting (FR-A) ........................................................................................... 331 What is FR-A? .................................................................................................................................................. 331 Involved Configuration .................................................................................................................................... 332

MAINTENANCE ........................................................................................................................................ 342 Setting-up Database Archiving ..................................................................................................... 342

9.3.1.1. 9.3.1.2. 9.3.1.3.

9.3.2. 9.3.3.

What is Database Archiving ............................................................................................................................ 342 How is Database Archiving Used.................................................................................................................... 343 How to Setup and Configure Database Archiving ......................................................................................... 343

Configuring the ASP Purge and Archiving Job ............................................................................ 343 Important Notice Regarding Purge and Archiving Job ................................................................ 344

9.3.3.1. 9.3.3.2. 9.3.3.3.

Purge .................................................................................................................................................................. 344 Archiving........................................................................................................................................................... 345 Monitoring ........................................................................................................................................................ 345

EXTERNAL SYSTEM INTERFACES ............................................................................................................. 346 Connecting to an External Database ............................................................................................ 346

9.4.1.1.

SITAONAIR

Downlink and Ground Messages Affecting Tracking.................................................................................... 296 OOOI Flight Stages Transitions ...................................................................................................................... 297 Identification of Flight Data in OOOI Messages............................................................................................ 298

Flight Plan Handling .................................................................................................................... 300

9.2.2.1. 9.2.2.2. 9.2.2.3.

9.4.1.

What is Excessive Downlink Detection .......................................................................................................... 294 Involved Configuration .................................................................................................................................... 295

TRACKING AND FLIGHT FOLLOWING ....................................................................................................... 296 Tracking an Aircraft from ACARS and Non-ACARS Messages .................................................... 296

9.2.1.1. 9.2.1.2. 9.2.1.3.

9.3.1.

Involved Configuration .................................................................................................................................... 294

Excessive Downlink Detection ...................................................................................................... 294

Connecting using stored procedures................................................................................................................ 347

vii

2001VLLYSUM138

ASP Administrator Guide Version 6.9a

9.4.1.2. 9.4.1.3.

9.4.2. 9.4.2.1. 9.4.2.2. 9.4.2.3.

9.4.3. 9.4.3.1. 9.4.3.2. 9.4.3.3.

9.4.4. 9.4.4.1. 9.4.4.2. 9.4.4.3.

9.4.5. 9.4.5.1. 9.4.5.2. 9.4.5.3.

9.4.6. 9.4.6.1. 9.4.6.2. 9.4.6.3. 9.4.6.4. 9.4.6.5.

9.4.7. 9.4.7.1. 9.4.7.2. 9.4.7.3.

Connecting using free text queries .................................................................................................................. 349 Solving a real-life problem with the database connector ............................................................................... 351

Writing Files to Another Server .................................................................................................... 364 ASP File/Printer Connector Service Configuration ....................................................................................... 364 Destination Folder Configuration .................................................................................................................... 367 ASP User and Distribution Configuration ...................................................................................................... 370

Enabling MIAM Application Support ........................................................................................... 372 What is MIAM .................................................................................................................................................. 372 Involved Configuration .................................................................................................................................... 372 How to Use MIAM ........................................................................................................................................... 378

Enabling MCCA Application Support ........................................................................................... 378 What is MCCA ................................................................................................................................................. 378 Involved Configuration .................................................................................................................................... 379 How to Use MCCA .......................................................................................................................................... 381

Honeywell Encryption and User Defined Formats ....................................................................... 382 What is Honeywell Encryption ........................................................................................................................ 382 Involved Configuration .................................................................................................................................... 382 Message Display ............................................................................................................................................... 385

FANS Decoding............................................................................................................................. 387 What is FANS ................................................................................................................................................... 387 Involved Configuration .................................................................................................................................... 387 ADS-C Samples ................................................................................................................................................ 389 AFN Samples .................................................................................................................................................... 393 CPDLC Samples ............................................................................................................................................... 395

FlightPlanner ................................................................................................................................ 397 What are FlightPlanner and FlightPlanner Map ............................................................................................. 397 Involved Configuration .................................................................................................................................... 397 EFB Configuration ........................................................................................................................................... 399

APPENDIX A: XML OUTPUT FORMAT ............................................................................................................ 401 APPENDIX B: MIAM XSD .................................................................................................................................... 404 Send.Request XML Example ...................................................................................................................... 409 Send.Multicast.Request XML Example ...................................................................................................... 410 Send.Status XML Example .......................................................................................................................... 411 Send.LocalStatus XML Example................................................................................................................. 411 Receive.Indication XML Example ............................................................................................................... 411 APPENDIX C: DIAL ENGINE PRO CONFIGURATION FOR SATCOM DIALING ..................................... 412 Installation of Dial Engine Pro ..................................................................................................................... 412 Configuration of Dial Engine Pro ................................................................................................................. 412

SITAONAIR

viii

2001VLLYSUM138

ASP Administrator Guide Version 6.9a

List of Figures Figure 2.1: Tree & List Structures........................................................................................................................... 21 Figure 2.2: Main Window for Administrators ......................................................................................................... 24 Figure 3.3 – FlightTracker Display Options Dialog - Display .............................................................................. 30 Figure 3.4 - FlightTracker Display Options Dialog – Layers (with weather layers) ......................................... 31 Figure 4.5: Templates – Downlink Folder Panel .................................................................................................. 50 Figure 4.6: Templates – Downlink From Aircraft General Panel ....................................................................... 51 Figure 4.7: Templates – Filter Criteria Dialog ....................................................................................................... 58 Figure 4.8: Template Edit Message Guide............................................................................................................ 58 Figure 4.9: Templates – Downlink From Aircraft Records Panel ....................................................................... 59 Figure 4.10: Templates – Downlink From Aircraft Fields Panel ......................................................................... 63 Figure 4.11 Range Validation Value Properties ................................................................................................... 70 Figure 4.12 Lookup Table Value Properties ......................................................................................................... 71 Figure 4.13: Templates – Data Format .................................................................................................................. 71 Figure 4.14 Templates – Downlink Advanced Options ....................................................................................... 72 Figure 4.15 Templates – Uplink Advanced Options ............................................................................................ 75 Figure 4.16 Templates – Ground Advanced Options .......................................................................................... 76 Figure 4.17: Templates – Uplink From Local User Fields Panel ....................................................................... 78 Figure 4.18: Templates – Downlink From Aircraft Model Panel......................................................................... 79 Figure 4.19: Character Conversion Window ......................................................................................................... 85 Figure 4.20: Model Properties Dialog .................................................................................................................... 85 Figure 4.21: Field Definition Wizard Window (1 of 3) .......................................................................................... 90 Figure 4.22: Field Definition Wizard Window (2 of 3) .......................................................................................... 91 Figure 4.23: Field Definition Wizard Window (3 of 3) .......................................................................................... 94 Figure 4.24: Record Definition Wizard Window (1 of 4) ...................................................................................... 95 Figure 4.25: Record Definition Wizard Window (2 of 4) ...................................................................................... 98 Figure 4.26: Record Definition Wizard Window (3 of 4) ...................................................................................... 99 Figure 4.27: Record Definition Wizard Window (4 of 4) .................................................................................... 101 Figure 4.28: Downlink Distribution Window ........................................................................................................ 102 Figure 4.29: Downlink Distribution Window, in normal view, flipped view and selected only view ............. 104 Figure 4.30: Uplink Distribution Window.............................................................................................................. 107 Figure 4.31: Uplink Copy Distribution Window – From External User ............................................................ 109 Figure 4.32: Uplink Copy Distribution Window – From Local User ................................................................. 109 Figure 4.33: Uplink Copy Distribution Window – Computer-Generated ......................................................... 110 Figure 4.34: Ground Distribution Window – From External User..................................................................... 111 Figure 4.35: Ground Distribution Window – Computer-Generated ................................................................. 111 Figure 4.36: Uplink Templates Permissions Window ........................................................................................ 115 Figure 4.37: Downlink Acknowledgement Window ............................................................................................ 117 Figure 4.38: Airport Distribution Window ............................................................................................................. 119 Figure 4.39: Downlink Templates Distribution Window – Airport Distribution Dynamic Groups ................. 119 Figure 5.40: Fleet Configuration Window ............................................................................................................ 123 Figure 5.41: Fleet Configuration – Find a String ................................................................................................ 125 Figure 5.42: Fleet Configuration – Find True/False ........................................................................................... 125 Figure 5.43: Aircraft Types Window ..................................................................................................................... 128 Figure 5.44: Aircraft Lockout Management Window.......................................................................................... 131 Figure 5.45: ACARS MU Window......................................................................................................................... 133 Figure 5.46: Honeywell Encryption Configuration - Aircraft List....................................................................... 135 Figure 5.47: Honeywell Encryption Configuration - Tables Sets ..................................................................... 138 Figure 5.48: Honeywell Encryption Configuration – Message Type Sets ...................................................... 140 Figure 5.49: Flight Routes Event Handling Window – Folder .......................................................................... 141 Figure 5.50: Flight Routes Event Handling Window – Flight Route ................................................................ 141 Figure 5.51: Flight Routes Event & Actions Dialog ............................................................................................ 145 Figure 5.52: Dynamic Frequency Management – Frequency Sets Window .................................................. 149 Figure 5.53: Flight Events Handling Window ...................................................................................................... 152

SITAONAIR

ix

2001VLLYSUM138

ASP Administrator Guide Version 6.9a

Figure 5.54: Flight Events Handling Window - Enter / leave area ................................................................... 154 Figure 5.55: Flight Events Handling Window – Flight Route - Alerting ........................................................... 155 Figure 5.56: Flight Events Handling Window - Lateral deviation ..................................................................... 156 Figure 5.57: Flight Events Handling Window - Lateral deviation ..................................................................... 157 Figure 5.58: Flight Events Handling Window - Vertical deviation .................................................................... 158 Figure 5.59: Vertical deviation valid altitude range ............................................................................................ 159 Figure 5.60: Flight Events Handling Window - A 2nd action set ...................................................................... 160 Figure 5.61: AFDAS Fault Management Window .............................................................................................. 162 Figure 5.62: AFDAS Fault Notification Window.................................................................................................. 167 Figure 5.63: Sequencer Window .......................................................................................................................... 169 Figure 6.64: Users and Groups Window – Local User ...................................................................................... 177 Figure 6.65: Users and Groups Window – External (File) User ....................................................................... 178 Figure 6.66: Users and Groups Window – Group User Type .......................................................................... 178 Figure 6.67: Users and Groups Window – Advanced Options for Local User ............................................... 187 Figure 6.68: Users and Groups Window – Advanced Options for File User .................................................. 187 Figure 6.69: Users and Groups Window - Advanced Options for FTP User.................................................. 188 Figure 6.70: Users and Groups Window – Advanced Options for Email/Notes User ................................... 188 Figure 6.71: Users and Groups Window – Email Subject Editor ..................................................................... 198 Figure 6.72: Users and Groups Window – Date/Time Format Editor ............................................................. 198 Figure 6.73: Users and Groups Window – How to send message in email attachment .............................. 199 Figure 6.74: Users and Groups Window – File Name Editor ........................................................................... 201 Figure 6.75: Users and Groups Window – Date/Time Format Editor ............................................................. 201 Figure 6.76: Users and Groups Window – Numeric Sequence Format Editor .............................................. 201 Figure 6.77: SMS user ........................................................................................................................................... 204 Figure 6.78: Database user ................................................................................................................................... 205 Figure 6.79: Traffic Log Window – Message Loopback Sequence ................................................................. 206 Figure 6.80: User Rights window.......................................................................................................................... 209 Figure 6.81: Roles window (Role tab) .................................................................................................................. 214 Figure 6.82: Roles window (Users tab)................................................................................................................ 215 Figure 6.83: Profiles window (Profile tab)............................................................................................................ 217 Figure 6.84: Profiles window (Users tab) ............................................................................................................ 217 Figure 6.85: Indicator of impersonating mode .................................................................................................... 218 Figure 6.23: Mailbox preferences while impersonating ............................................................................................ 219 Figure 6.24: Mailbox filters while impersonating ..................................................................................................... 219 Figure 6.25: Manage Filters window while impersonating ....................................................................................... 219 Figure 6.89: Account Policies Window – AIRCOM® ServerPlatform Authentication ................................... 220 Figure 6.90: Account Policies Window – LDAP Authentication ....................................................................... 221 Figure 7.91: System Parameters – General ....................................................................................................... 227 Figure 7.92: System Parameters – Database .................................................................................................... 230 Figure 7.93: System Parameters – Message Handling..................................................................................... 236 Figure 7.94 System Parameters – Tracking ....................................................................................................... 241 Figure 7.95 System Parameters – Third Parties ................................................................................................ 245 Figure 7.96 System Parameters – Flight Assignment ....................................................................................... 250 Figure 7.97: System Parameters – SATCOM Data ........................................................................................... 252 Figure 7.98: Data Link Service Providers (DSP) Window................................................................................. 256 Figure 7.99: Value Lookup Tables Window ........................................................................................................ 260 Figure 7.100: Value Lookup Tables Window – Value List ................................................................................ 261 Figure 7.101: Lookup Tables - Find String.......................................................................................................... 262 Figure 7.102: Value Lookup Tables Window – Value Browsing ...................................................................... 263 Figure 7.103: Value Lookup Tables – New Message Value List ..................................................................... 263 Figure 7.104: VHF Stations Window .................................................................................................................... 264 Figure 7.105: VHF Stations – FlightTracker Map ............................................................................................... 268 Figure 7.106: VHF Stations – Overwrite Validation ........................................................................................... 270 Figure 7.107: Custom Fields Window .................................................................................................................. 271

SITAONAIR

x

2001VLLYSUM138

ASP Administrator Guide Version 6.9a

Figure 8.108: Event Handling Window – Downlink Templates Folder ............................................................ 273 Figure 8.109: Event Handling Window – Downlink Templates ........................................................................ 273 Figure 9.110: Dynamic Flight Assignment Template ......................................................................................... 281 Figure 9.111: My Flights Window ......................................................................................................................... 284 Figure 9.112: Dynamic Frequency Management Configuration ...................................................................... 309 Figure 9.113: Example of inherited and native events & actions for a route.................................................. 310 Figure 9.114: Alert notifications for FR-A advisories and warnings................................................................. 337 Figure 9.6: Alert notifications for FR-A advisories and warnings............................................................................ 341 Figure 9.116: Customer database connection using stored procedures ........................................................ 347 Figure 9.117: MIAM Type B User – Configuration ............................................................................................. 373 Figure 9.118: MIAM Downlink Template ............................................................................................................. 374 Figure 9.119: MIAM Downlink Distribution .......................................................................................................... 375 Figure 9.120: MIAM Uplink Templates ................................................................................................................ 375 Figure 9.121: MIAM Ground Templates .............................................................................................................. 376 Figure 9.122: MIAM Ground Distribution ............................................................................................................. 377 Figure 9.123: MCCA Type B User – Configuration............................................................................................ 379 Figure 9.124: MCCA Ground Templates ............................................................................................................. 381 Figure 9.125: MCCA Ground Distribution............................................................................................................ 381 Figure 9.126: CFG message from FlightPlanner ............................................................................................... 398 Figure 9.127: EFB File User .................................................................................................................................. 399 Figure 9.128: Enable flight plan to EFB ............................................................................................................... 399 Figure A-9.129: AircomSrvMsg Schema - level ............................................................................ 402 Figure A-9.130: AircomSrvMsg Schema - level............................................................................ 403

List of Tables Table 1-1: AIRCOM® ServerPlatform client User Roles..................................................................................... 14 Table 1-2: Terms and Acronyms ............................................................................................................................ 15 Table 2-3: Management Functions......................................................................................................................... 28 Table 4-4 Template Categories and Message Sources ...................................................................................... 43 Table 4-5 Templates – Core Functions ................................................................................................................. 49 Table 4-6 Templates – General .............................................................................................................................. 57 Table 4-7 Template Records Panel ....................................................................................................................... 62 Table 4-8 Templates – Data components of the Fields panel............................................................................ 69 Table 4-9: Templates – Field Localization Methods ............................................................................................ 70 Table 4-10: Data Format Functions ....................................................................................................................... 71 Table 4-11 Templates – Downlink Advanced Options ........................................................................................ 74 Table 4-12 Templates – Uplink Advanced Options ............................................................................................. 76 Table 4-13: Templates – Model Data Description................................................................................................ 80 Table 4-14: Templates – Model Insert Toolbar..................................................................................................... 83 Table 4-15: Templates – Model Field Character Conversion ............................................................................. 84 Table 4-16: Templates – Model Properties ........................................................................................................... 87 Table 4-17: Templates – Field Wizard Last Step Context .................................................................................. 92 Table 4-18: Templates – Field Wizard Data ......................................................................................................... 93 Table 4-19: Templates – Field Wizard Functions................................................................................................. 93 Table 4-20: Templates – Record Wizard Step 2 Context ................................................................................... 96 Table 4-21: Templates – Record Wizard Step 2 Data & Functions................................................................... 97 Table 4-22: Templates – Record Wizard Step 4 Data & Functions................................................................. 100 Table 4-23: Distribution Functions........................................................................................................................ 113 Table 4-24: Distribution Data ................................................................................................................................ 114 Table 4-25: Templates Permissions Data ........................................................................................................... 116 Table 4-26: Downlink Acknowledgement Data ................................................................................................... 118

SITAONAIR

xi

2001VLLYSUM138

ASP Administrator Guide Version 6.9a

Table 4-27: Airport Distribution Functions ........................................................................................................... 120 Table 4-28: Airport Distribution Data .................................................................................................................... 121 Table 5-29 Fleet Configuration Functions ........................................................................................................... 125 Table 5-30 Fleet Configuration Data .................................................................................................................... 126 Table 5-31: Aircraft Types Functions ................................................................................................................... 128 Table 5-32: ACARS MU Functions....................................................................................................................... 133 Table 5-33: Honeywell Encryption Configuration Functions ............................................................................. 134 Table 5-34: Flight Route Event Handling Functions .......................................................................................... 142 Table 5-35: DFM Frequency Sets Functions ...................................................................................................... 150 Table 5-36: AFDAS Fault Management Functions ............................................................................................ 164 Table 5-37: AFDAS Fault Data ............................................................................................................................. 166 Table 5-38 AFDAS Fault Notification Functions................................................................................................. 168 Table 5-39: AFDAS Fault Notification Data ........................................................................................................ 168 Table 6-40: Users Functions ................................................................................................................................. 180 Table 6-41: User Data ............................................................................................................................................ 186 Table 6-42: Advanced Options – Local Users .................................................................................................... 189 Table 6-43: Advanced Options – File and FTP Users ....................................................................................... 190 Table 6-44: Advanced Options – Email / Notes Users ...................................................................................... 190 Table 6-45: User Types.......................................................................................................................................... 191 Table 6-46: User Rights Functions ....................................................................................................................... 209 Table 6-47: User Rights Functions ....................................................................................................................... 216 Table 6-48: User Rights Functions ....................................................................................................................... 218 Table 6-49: Account Policies Functions .............................................................................................................. 221 Table 6-50: Account management Data .............................................................................................................. 222 Table 6-51: Password Rules Data........................................................................................................................ 222 Table 6-52: Password Rules Data........................................................................................................................ 223 Table 7-53 Systems Parameters – General Data .............................................................................................. 228 Table 7-54 System Parameters – Database Data ............................................................................................. 235 Table 7-55 Systems Parameters – General Data .............................................................................................. 240 Table 7-56 System Parameters – Tracking Data ............................................................................................... 244 Table 7-57 System Parameters – Third Party Data ........................................................................................... 249 Table 7-58 System Parameters – Flight Assignment Data............................................................................... 252 Table 7-59 System Parameters – SATCOM Data ............................................................................................. 253 Table 7-60: Data Link Service Providers Functions........................................................................................... 257 Table 7-61 Data Link Service Providers Data .................................................................................................... 258 Table 7-62: Value Lookup Table Functions ........................................................................................................ 262 Table 7-63: Value Lookup Table Information...................................................................................................... 262 Table 7-64: VHF Stations Functions .................................................................................................................... 266 Table 7-65: VHF Stations Data ............................................................................................................................. 267 Table 7-66: Custom Fields Functions .................................................................................................................. 272 Table 7-67: Custom Fields Data ........................................................................................................................... 272 Table 8-68: Event Handling Functions................................................................................................................. 275 Table 8-69: Event Handling – Downlink Template Events Descriptions......................................................... 276 Table 8-70: Event Handling – Uplink Template Events Descriptions.............................................................. 276 Table 8-71: Event Handling – Ground Template Events Descriptions ........................................................... 276 Table 8-72: Event Handling – Fleet Template Events Descriptions ................................................................ 277 Table 8-73: Event Handling – Sequencer Events Descriptions ....................................................................... 277 Table 9-74: Aircraft Tracking and Flight Stages Handling ................................................................................ 300

SITAONAIR

xii

2001VLLYSUM138

ASP Administrator Guide Version 6.9a

1. Scope Identification This document is the manual for the AIRCOM® ServerPlatform administrator. It contains all information needed by the administrator users to configure, manage and understand the functions available to them in this software package. The normal operator functions are described in [S4a] "AIRCOM® FlightMessenger User Guide" and [S4b] "AIRCOM® FlightTracker User Guide" documents. The main sections of this document are the following: •

Scope: This section; general introduction of the document.

•

General Information: Generalities about the AIRCOM® ServerPlatform client that are useful to understand the concepts presented in this document.

•

Administration Reference (multiple sections): Description of all windows and all functions available to the system administrators, allowing them to perform system configuration activities. The administrator reference is centered on individual windows and their respective functions, not the interactions between windows.

•

Function Reference: As opposed to the previous section, the function reference centers around the main features of AIRCOM® ServerPlatform, how they work and how/where they are configured across the different ASP client windows. This is a good place to start to understand new features of AIRCOM® ServerPlatform.

13

ASP Administrator Guide Version 6.9a

System Overview The AIRCOM® ServerPlatform client software allows the user to interact with the SITAONAIR AIRCOM® ServerPlatform application database to view his/her messages received from aircraft, send and track uplink messages to aircraft as well as viewing the current tracking information for all active aircraft. Many more functions will be discussed later in this document. The AIRCOM® ServerPlatform is still evolving to add and enhance such functions as system supervision as well as many small function enhancements making the AIRCOM® ServerPlatform an ideal ACARS message processing system. The AIRCOM® ServerPlatform client provides two major user profiles Operator User Profile

This profile allows an operator user to view and send messages, view certain configuration items as well as aircraft tracking information. Operation usage is described in the document “AIRCOM® FlightMessenger User Guide”.

System Administrator Profile

This profile includes all the functionality available in the Operator User profile plus all configuration items maintenance, system monitoring and supervision functions available to the system administrator users. Table 1-1: AIRCOM® ServerPlatform client User Roles

14

ASP Administrator Guide Version 6.9a

Terms and Acronyms ACARS ADLT AFDAS AIRCOM® AN ASD BATAP CRC DFM DSP eDFP EFB ETA ETD FANS FCM FDE FE FI FlightTracker GES GUI LDAP MA MAS MCCA MIAM MSN ODBC RF RGS SITA SMI SMS TEI UTC VDL VHF

Aircraft Communications Addressing and Reporting System AIRCOM® Datalink Traffic Handling applications that encompass the following elements: XASP, CAAS, DHP and VMMS. ACARS Fault Detection and Alerting System SITA VHF and Satellite Air-Ground Communication Service Aircraft registration, also known as Aircraft Number or Aircraft Long Reg Aircraft Situation Display: deprecated, now called "FlightTracker" Type B Application to Application Protocol Cyclical redundancy check Dynamic Frequency Management Data link Service Provider EFB Datalink Front-end Processor Electronic Flight Bag Estimated time of arrival Estimated time of departure Future Air Navigation Systems Fuel Conservation Monitoring Flight Deck Event Flight Explorer Flight number, also known as Flight Identifier New flight following & map display tool, successor of the ASD and FlightMonitor Ground Earth Station Graphical User Interface Lightweight Directory Access Protocol Message assurance TEI Message ASsurance Multi-Channel Communication Api (Airbus) Media Independent Aircraft Messaging Message Sequence Number Open Database Connectivity Radio Frequency Remote Ground Station Société Internationale de Télécommunications Aéronautiques Standard Message Identifier Short Message Service Text Element Item Universal Time Coordinated VHF (Very High Frequency) Digital Link Very High Frequency Table 1-2: Terms and Acronyms

15

ASP Administrator Guide Version 6.9a

Applicable Documents

1.4.1.

SITAONAIR Documents

[S1]

AIRCOM® ServerPlatform Hardware and Software Prerequisites Installation Guide 2001VLLYSUM134

[S2]

AIRCOM® ServerPlatform Installation and Configuration Guide 2001VLLYSUM132

[S3]

AIRCOM® ServerPlatform Monitoring Guide 2000VLLYSUM01081

[S4a] AIRCOM® FlightMessenger User Guide 2001VLLYSUM137 [S4b] AIRCOM® FlightTracker User Guide [S4c] AIRCOM® FlightPlanner User Guide [S5]

(This document)

[S6]

AIRCOM® ServerPlatform Disaster Recovery and Mirroring Guide 2010VLLYSUM693

[S7]

AIRCOM® ServerPlatform Supplemental MIAM Guide

16

ASP Administrator Guide Version 6.9a

1.4.2.

Non-SITAONAIR Documents

[E1]

Air-Ground Character-Oriented Protocol Specification, AEEC specification 618-4

[E2]

Data Link Ground Systems, Standard and Interface Specification (DGSS/IS) AEEC Specification 620-4

[E3]

Pre-Departure Clearance Application Segment Specification, FAA Derived from ARINC document number 12880 Revision H, September 29, 1999

[E4]

MEDIA INDEPENDENT AIRCRAFT MESSAGING (MIAM) ARINC Specification 841

[E5]

Multi-Channel Communication Api (MCCA) AIRBUS specification Issue 1.8 - 23 Oct 2012

[E6]

Interoperability Requirements for ATS Applications Using ARINC 622 Data Communications (FANS 1/A Interop Standard), RTCA/DO-258A, April 7, 2005 (or newer versions)

17

ASP Administrator Guide Version 6.9a

2. General Information This section presents a few generalities about the AIRCOM® ServerPlatform client that are useful to understand the concepts presented in this document. The next sections of this document describe all functions available to the system administrators, allowing them to perform system configuration activities. Starting with the version 6.0, the windows and configuration elements requiring administrative privileges are visible only to the users who have administrative rights to these, as configured by the users' administrator in the "Users and Groups" window. Configuration elements, such as templates, for which administrative rights are required, are not available to users without those rights, not even just to view.

Users Many types of users can be configured to interact with the AIRCOM® ServerPlatform system for their daily operations. The users that interact with the system via the AIRCOM® ServerPlatform client are considered “Local” users and are the only ones that can use the Client user interface. The other types of users or applications are considered “External” users. External users interact with the Server component of the system via designated links or protocols: Type B users or applications (MATIP/TCP links for example), IBM WebSphere MQ (MQSeries) users, Lotus Notes or SMTP/POP3 e-mail based users, files, printers, SMS and others. Both “External” and “Local” users must be defined via the AIRCOM® ServerPlatform client.

2.1.1.

Local Users

Local users must be authenticated before being able to use the AIRCOM® ServerPlatform client and so, must identify themselves with their username and password at login. The operations they are allowed to perform on the system depend on the rights configured for them by the system administrator. For a tight monitoring of the security events happening on the system, different events are logged about local user Client sessions: 1) users that login, 2) users that log off, and 3) any failed login attempts. These are security-class events logged in the “Event Log” for monitoring purposes.

18

ASP Administrator Guide Version 6.9a

2.1.2.

External Users

Although external users cannot use the Client user interface to interact with the system, they still have to be defined in order for the system to: • Define distribution rules involving them. • Know how to deliver the downlink or ground messages distributed to them. • Trust and authenticate them for access right to send uplink or ground messages. • Determine what messages each user can send. The passwords associated with the external users, even if not used to log into the ASP client, can be used to authenticate the users trying to communicate with the ASP server. Passwords are transmitted via specific identifiers (%%PWD=[password]%% for example) inserted in the incoming messages. However, the account policies and password rules do not apply to external users, only to local users. For the specific message syntax for external users to communicate with the system, refer to document [S3].

2.1.3.

Logging In Read-Only Mode

Getting the message “You are about to connect to a database in read-only mode.” means that the user just logged to a database with an SQL login account having limited write permissions (typically having the "db_denydatawriter" database role), not to be confused with the ASP local user accounts, which means no data can be added or modified. This has indeed precedence over any administrative user rights that an AIRCOM® ServerPlatform user account may have. However, the need to have such a read-only access to an AIRCOM® ServerPlatform database is not needed anymore since version 5.4. It was primarily supported to avoid write access to a replicated database, which could have damaged it and prevent successful recovery, but since version 5.4 replication has been replaced with mirroring. A mirror database is not accessible until it becomes the principal, so there is no risk to damage it.

19

ASP Administrator Guide Version 6.9a

Editing Modes Most of the administrative windows may be used in one of three modes: view, modify and add modes. Only a few ones present information that can only be modified or deleted. A window is in view mode when it is first opened and whenever the corresponding administrator presses either the Save or Cancel buttons while in add or modify modes. It gets into modify mode after pressing the Modify button until Save or Cancel is pressed and similarly, it gets into add mode after pressing the New button. In view mode, the administrator may add a new item and modify or delete an existing one. Save and Cancel buttons are disabled. In modify mode, the administrator may change any of the current information about the edited item. In some circumstances, it is possible to edit multiple items in the same modify “session” before saving or canceling. The Save, Cancel and Close buttons are always available. In add mode, it behaves like in modify mode, with the exception that all data is initialized as empty and always only one item at a time is created. If the window is closed using any available means, when in add or modify mode, the administrator is prompted, advising that changes may not have been saved and has the choice to either continue and possibly loose changes or cancel the close operation and get the possibility to save. A popup menu is generally available over the windows’ corresponding list of items to edit. The available commands are a duplication of the toolbar commands (typically New, Modify, Delete, Save, and Cancel). Their availability is identical to the toolbar commands. Only the commands appropriate to the context are displayed in the popup menus.

20

ASP Administrator Guide Version 6.9a

2.2.1.

List and Tree Navigation

The following navigation and sorting rules apply to all tree and list structures similar to the ones showed below.

Figure 2.1: Tree & List Structures

Users can navigate through the trees using the keyboard as well as the mouse. UP ARROW and DOWN ARROW keys cycle downward through all expanded nodes. Nodes are selected from left to right, and top to bottom. At the bottom of the tree, the selection jumps back to the top of the tree, scrolling the window if necessary. RIGHT ARROW and LEFT ARROW keys also tab through expanded nodes, but if the RIGHT ARROW key is pressed while an unexpanded node is selected, the node expands; a second press will move the selection to the next node. Conversely, pressing the LEFT ARROW key while an expanded node has the focus collapses the node. If a user presses an ANSI key, the focus will jump to the nearest node that begins with that letter. Subsequent pressings of the key will cause the selection to cycle downward through all expanded nodes that begin with that letter. For lists with columns, pressing an ANSI key behaves the same as in a tree, but the matching is performed only on the first column when more than one is displayed. Clicking on one of the column header sorts the list alternatively in ascending and descending order according to that column, and a sort icon shows the currently sorted column and the sort order applied. Columns may always be enlarged to display data not completely visible (i.e. when ‘…’ are shown to the right of the data). Locate the mouse over one of the edge of the column headers and once the cursor changes, drag the column to enlarge or reduce it. If the total width of the columns is larger than the list width, then a horizontal scrollbar appears at the bottom of the list.

21

ASP Administrator Guide Version 6.9a

System Limits This section shows the main system limitations that administrators shall be aware of when working with the AIRCOM® ServerPlatform system, especially regarding the size limits of different type of messages.

2.3.1. •

General Messages Length Limits

Maximum message length for processing: 120 KB (122,880 characters) by default, configurable up to 4 MB (4,194,304 characters) The AIRCOM® ServerPlatform system can handle and process messages up to 100,000 characters long by default. This value can be increased to 4M characters by configuration in the AircomSrv.ini file and will allow the Message Processor and the File, MSMQ and MQ Series connectors to handle large messages. The protocols used by AIRCOM® ServerPlatform to communicate with the network and the external users may however impose some more stringent limits (in particular: Type B communications).

•

Maximum Type B message length: 3,832 characters The BATAP and Type B messaging and its network impose limits of 3840 characters for all messages transmitted over it, including headers, and that leaves 3832 characters for the actual text of the messages, starting at the destination line (QU [...]). Messages sent by AIRCOM® ServerPlatform over Type B links, if they exceed this limit, are truncated before being sent, even if the system could process longer messages.

•

Maximum AEEC 620 messages length: 3,520 characters (free text only) The messages sent over the network for delivery to aircraft (uplinks) must respect AEEC 620 standard and the free text (the portion starting with “dash-space-space” that will be sent to the aircraft) must not exceed 3520 characters. The free text portion of the uplink messages sent by AIRCOM® ServerPlatform, if it exceeds this limit, is truncated before being sent to the network.

2.3.2.

Templates Limits (for downlink, uplink and ground messages)

•

Maximum number of field definitions: 1000

•

Maximum number of record definitions: 20

•

Maximum length of a single field or single record occurrence: 50,000 characters

•

Maximum number of total fields + record occurrences identifiable in a message: 10,000 This limit represents the sum of all fields and record identified in a message when processed.

•

Maximum model text length (unformatted definition): same as configured max message length

22

ASP Administrator Guide Version 6.9a

2.3.3. •

Other System Limits

Maximum number of recipients for message distribution: 200 When receiving a downlink or ground message, the ASP server can generate and distribute a maximum of 200 messages to end-users, all possible distribution methods combined. If this limit is exceeded, only the first 200 will receive a copy of the message and an event will be logged for the lost distributions.

•

Maximum memory allocation for message distribution: 120 Mb When receiving a downlink or ground message, the ASP server can generate and distribute messages to end-users for a maximum of 120 Mb, all possible distribution methods combined. If this limit is exceeded, the number of recipients will be reduced until reaching the limit of 120 Mb.

•

Maximum number of downlink distribution additional criteria: 2000 When receiving a downlink message, the ASP server can handle a maximum of 2000 simultaneous distribution criteria for a given template. This is the sum of all criteria that need to be resolved to generate the final list of recipients for a message. An event is logged if this internal limit is exceeded.

•

Mailbox maximum number of messages that can be trashed/restored, marked as read/unread, or printed at once: 1000

•

For a Mailbox message longer than 100,000 characters, the “Wrap text” and “Show control chars” features are disabled.

•

Maximum number of messages that can be forwarded at once: 250

•

Maximum size of selected messages to be forwarded at once: 12 MB

23

ASP Administrator Guide Version 6.9a

Main Window Below is what the Main window looks like for a user with all administrative user rights.

Figure 2.2: Main Window for Administrators

All windows described for the operator user profile (see document [S4a] "AIRCOM® FlightMessenger User Guide") can also be available to system administrators. A system administrator is a user that has at least one of the available management user rights enabled. The most critical user rights regarding security are the following: Manage users, Manage roles and rights, Modify account policies, and Modify system parameters. Any user can get a warning at login about failed login attempts using his account. This is configurable in the Account Policies. However, only the Manage users, and Modify system parameters administrators will get warnings at login about a license that is about to expire.

24

ASP Administrator Guide Version 6.9a

Here is a summary of what configuration can/must be managed and defined by a system administrator by going through the main window toolbar and menus. Function

Description

Downlinks button

Dropdown accessing the configuration items needed for downlink messages processing.

Templates

Launches the Downlink Templates window to view and manage the templates used for the processing of downlink messages. Requires the right Manage downlink templates.

User Distribution

Launches the User Distribution window to configure the distribution of downlink templates to users and groups along with their associated model for reformatting. Requires the right Modify downlink distribution and acknowledgement.

Acknowledgement

Launches the user Acknowledgement window to configure the downlink templates acknowledgement rules. Requires the right Modify downlink distribution and acknowledgement.

Airport Distribution

Launches the Airport Distribution window to manage the distribution lists used in the distribution to the "Airport - Origin" and "Airport - Destination" dynamic groups. Requires the right Manage airport distribution.

Uplinks button

Dropdown accessing the configuration items needed for uplink messages processing.

Templates

Launches the Uplink Templates window to view and manage the templates used for the processing of uplink messages. Requires the right Manage uplink templates.

Aircraft Distribution

Launches the Aircraft Distribution window to configure the distribution of uplink templates to aircraft along with their associated model for reformatting. Requires the right Modify uplink distribution and permissions.

User Copy

Launches the User Copy window to configure the distribution of uplink copies to be sent to users or groups. Requires the right Modify uplink distribution and permissions.

User Permissions

Launches the User Permissions window to configure the user permissions associated with each uplink template. Requires the right Modify uplink distribution and permissions.

Grounds button

Dropdown accessing the configuration items needed for ground messages processing.

Templates

Launches the Ground Templates window to view and manage the templates used for the processing of ground-to-ground messages. Requires the right Modify ground distribution and permissions.

25

ASP Administrator Guide Version 6.9a

User Distribution

Launches the User Distribution window to configure the distribution of ground templates to users and groups along with their associated model for reformatting. Requires the right Modify ground distribution and permissions.

User Permissions

Launches the User Permissions window to configure the user permissions associated with each ground template. Requires the right Modify ground distribution and permissions.

Aircraft button

Dropdown accessing aircraft configuration and status data.

Fleet Configuration

Launches the Fleet Configuration window to view and manage the aircraft used in the system – in particular those to which uplinks can be sent. Requires the right View aircraft (Manage aircraft to configure aircraft).

Aircraft Lockout Management

Launches the Aircraft Lockout management window to define aircraft lockout; that is period over which an aircraft is hidden from view to users not allowed to view locked aircraft. Requires the right Manage aircraft lockout.

Aircraft Types

Launches the Aircraft Types window to manage available aircraft types (typically ICAO/IATA designation) and their parameters. Requires the right Manage aircraft.

ACARS MU

Launches the ACARS MU window to manage the list of ACARS MU used in the aircraft definition. Requires the right Manage aircraft.

Honeywell Encryption

Launches the Honeywell Encryption window to manage the encryption configuration used for the aircraft that support and use encryption of certain types of messages using Honeywell avionics built-in encryption mechanism. Requires the right Manage aircraft and the license option Honeywell Encryption.

DFM Flight Routes Event Handling

Launches the Dynamic Frequency Management – Flight Routes Event Handling window to manage the routes flown by the aircraft and the event handling attached each one, in particular those related to the Dynamic Frequency Management (DFM) feature. Requires the right Manage DFM and the license option DFM.

DFM Frequency Sets

Launches the Dynamic Frequency Management – Frequency Sets window to define the Auto-Tune and Scan Table frequencies that will be sent to aircraft when some DFM events are triggered. Requires the right Manage DFM and the license option DFM.

Flight Events Handling

Launches the Flight Events Handling window to configure flight events and actions that will be triggered by these events. Requires the right Manage flight events.

AFDAS Fault Management

Launches the Fault Management window to configure the faults for different Boeing aircraft types. Requires the right Manage AFDAS faults and the license option AFDAS.

26

ASP Administrator Guide Version 6.9a

AFDAS Fault Notification

Launches the Fault Notification window to configure the fault notifications and escalations to users when they are raised. Requires the right Manage AFDAS faults and the license option AFDAS.

Sequencer

Launches the Sequencer window to configure sequences on aircraft. Requires the right Manage sequences and the license option Sequencer.

Users button

Dropdown accessing users related configuration.

Users and Groups

Launches the Users and Groups window to manage the local users (of the client), external users (e-mails, applications & systems), groups and desks. This is core to the operation and security of the system. Requires the right Manage users, which should be attributed to a selected few administrators only.

User Rights

Launches the User Rights window to configure the permissions configurations for all user accounts. It also allows assigning users to roles. See section 6.2.1 for more details. Requires the right Manage roles and rights, which should be attributed to a selected few administrators only.

Roles

Launches the Roles window to manage the roles that can be attributed to users. Giving roles to users allow an easier and more predictable permissions management than giving individual user rights. Permissions can be attributed to each role and then local user accounts can be given different roles. See section 6.3 for more details. Requires the right Manage roles and rights, which should be attributed to a selected few administrators only.

Profiles

Launches the Profiles window to manage the profiles that can be attributed to users. Profiles allow sharing –and enforcing-- user related configurations such as preferences and filters. See section 6.4 for more details. Requires the right Manage profiles.

Account Policies

Launches the Account Policies window to manage global accounts and password management rules. The use of LDAP authentication can also be defined there. Requires the right Modify account policies, which should be attributed to a selected few administrators only.

System button

Dropdown accessing system related configuration.

System Parameters

Launches the System Parameters window to manage many parameters essential to the system operation, such as tracking, message handling and database. Requires the right Modify system parameters. Along with users and account management, this right should be given to selected and knowledgeable administrators as many of these settings have significant impact on the system operation.

System Monitoring

Launches the System Monitoring window to manage the e-mail notifications sent when processes and configured links change statuses. Requires the right Modify system monitoring.

27

ASP Administrator Guide Version 6.9a

Data Link Service Providers (DSP)

Launches the DSP window to manage the datalink service providers used to communicate to aircraft over ACARS. Requires the right Manage DSP.

Value Lookup Tables

Launches the Value Lookup Tables window to manage the value conversion tables such as ICAO or IATA city codes. Requires the right Manage lookup tables.

VHF Stations

Launches the VHF Stations window to manage the list SITAONAIR owned and customer added VHF/VDL stations used to communicate with aircraft. Requires the right Manage VHF stations.

Custom Fields

Launches the Custom Fields window to configure the custom fields that can be used as field types in templates such that their value is tracked with the rest of the aircraft data. Requires the right Manage custom fields.

Exit button

Closes the AIRCOM® ServerPlatform client, AIRCOM® FlightTracker and AIRCOM® FlightPlanner. Table 2-3: Management Functions

28

ASP Administrator Guide Version 6.9a

3. Flight Tracking Administration FlightTracker Setup The use of FlightTracker is subject to a license. In complement to the FlightTracker, there are also optional licenses to get access to weather information and map layers, alerting and areas definitions within the FlightTracker. The weather license includes a number of seats, limiting the number of users allowed to view weather information simultaneously. You may use the Client System Parameters window, general tab to verify the presence of the FlightTracker and related license options. The FlightTracker option must also be installed when running the Client setup for it to be available, and it is not in the default setup options, it has to be selected through custom installation. Therefore, it is recommended to install the FlightTracker only on the computers where users are expected / allowed to use the FlightTracker. Running FlightTracker requires access to http://static.arcgis.com/ and http://services.arcgisonline.com/, Esri’s online map servers. If those servers cannot be reached, FlightTracker will open in offline mode and will still be functional, but the map will however not display. Please refer to document [S2], section “Internet Options for FlightTracker Map and FlightPlanner Map” in case of problems displaying the map. There is a set of display options that can be managed only by a system parameters administrator and this is discussed in the next section. All other preferences are configurable per user. Please refer to document [S4b] for details.

FlightTracker Display Options & Map Icons Display options are divided in two large areas, Display and Layers, and the display area is sub-divided into four areas: map elements, flight stage colors, clusters, and map settings. They apply to all users and they can be set only by an administrator having the Modify system parameters user right. Refer to document [S4b] for the complete description of the FlightTracker window. The preview button allows seeing on the map the result of the settings changes, without saving them yet. If the changes are not as desired, further customizations can be

29

ASP Administrator Guide Version 6.9a

performed or at any time cancel will revert to the settings before the dialog was opened and close the dialog. Save applies the currently configured settings, saves them and closes the dialog. Note that while the dialog is opened, although it will always stay on top of the FlightTracker window, it does not prevent from going back to the FlightTracker and interact with it, like for example panning or zooming the map to better see the impac t of the new settings using the preview button.

Figure 3.3 – FlightTracker Display Options Dialog - Display

30

ASP Administrator Guide Version 6.9a

Figure 3.4 - FlightTracker Display Options Dialog – Layers (with weather layers)

3.2.1. 3.2.1.1.

Display Map Elements

This is a list of object that can be seen on the map and for which the color is configurable. Click on the colored square to open a color picker dialog and edit the color as desired. What differentiates the flown route from the planned route is the line color. Thus we recommend selecting different colors that will make it easy to identify over the map. There are three airport icons with different shapes for which the line color can be selected: an empty square for the origin or departure airport, an empty circle for the destination or arrival airport, and numbered triangle(s) for the alternate airport(s). The default color for new areas is configurable. Refer to document [S4b] for information about areas. The grid lines color will change the color of the lines when showing the grid lines layer.

31

ASP Administrator Guide Version 6.9a

3.2.1.2.

Flight Stage Colors

These colors affect the aircraft icon according to the flight stage the aircraft is in. Notice that the aircraft symbol is always white and it is the background color of the icon that changes. For the planned flight stage, instead of showing an aircraft symbol, the icon shows a white P letter. Also, although not apparent in the Display Options dialog, the aircraft symbol in these icons orient the nose of the aircraft towards the heading of the aircraft when the latter is moving and its heading is known; otherwise the aircraft points toward the North.

3.2.1.3.

Clusters

A cluster is a group of aircraft represented by the cluster icon, a black hexagon with in its center the number of aircraft contained in the cluster. A cluster group includes aircraft that are at approximately 20 pixels from one another, thus the more you zoom in, the fewer clusters you will find on the map, and the remaining clusters will most probably contain less aircraft. To stop using this clustering mechanism, uncheck the “Use clusters to group aircraft” in this section. When moving the mouse over a cluster, a popup similar to a tooltip will show a short label for each aircraft in the cluster, and this popup can be pinned, to stay always visible, or can be floating and disappear like a tooltip when the mouse is moved away. The two “Cluster max label height” settings allow deciding what will be the height in pixels for these pinned and floating popup labels.

3.2.1.4.

World Map Center Longitude

The world map center longitude is the longitude at which the map is centered for the builtin World view. It can be adjusted by steps of 10 degrees between -180 to +180 degrees. The default is 0, Greenwich. For polar projections, modifying this value will display the selected longitude at the bottom for the north projection, and at the top for the south pole projection.

32

ASP Administrator Guide Version 6.9a

3.2.2.

Layers

The layers tab presents all map layers available to users. Essentially, it provides some read-only information about each layer: a name, a short description, whether it is an animated layer, and if it exists for multiple flight levels. Besides that, one or two configurable settings are available: a check box allows deciding if the layer is to be available to users or not, and for some layers only, it is possible to select which unit will be used for display; for example the Wind Speed layer (a weather layer) allows selecting knots, miles/h, km/h or meters/s as display units. Layers are grouped logically and at least the two AIRCOM® ServerPlatform basic groups are listed: Navigation and ACARS Data Coverage. These include static layers such as major world airports, Flight Information Regions (FIR), Upper Information Regions (UIR), SITAONAIR VHF/VDL and satellite coverage. Additional weather layers can be added when subscribing to the ASP weather provider, DTN. The additional layers allowed as per the account with the provider are also listed in logical groups such as Surface Observations, Radar, … As for the general Display options, any changes performed to layers options are global and apply to all users. Note that the preview function is not available for the Layers settings.

Map animations When zooming in or out on the map, or when panning, the map movements are animated by default, that is: transitioned with intermediate imaged between the initial and final map display. This shows fluid map movements on local desktops but often shows choppy and slow over remote connections because of intermediate images being transmitted. For that, the map animations are turned off when connected through a remote desktop connection, Citrix or a cloud environment. Shall you want to keep those animations enabled or to always disable them regardless of the current environment, please contact AIRCOM® support at [email protected].

33

ASP Administrator Guide Version 6.9a

Update FIR/UIR information To update contact number and comments for a given FIR or UIR, you can use the script "Set ContactPhone and Comments in FIR.sql", available under "Tools\Upgrade" folder in the installation directory. To use this script, you have to open it and replace the following parameters: • : The FIR Code of the region you wish to update • : The Sub-Area of the region you wish to update • : The Level of the region you wish to update ▪ 0 : Both FIR and UIR ▪ 1 : FIR ▪ 2 : UIR • : The phone information for the region you wish to update (size limit: maximum 100 characters) • : The comments for the region you wish to update (size limit: maximum 1000 characters) Once updated, run the script on the AIRCOM® ServerPlatform database.

34

ASP Administrator Guide Version 6.9a

4. Templates Administration Templates Window The Downlink Templates, Uplink Templates, and Ground Templates windows are available through the Main window ‘Downlinks’, ‘Uplinks’, and ‘Grounds’ dropdown buttons, or their equivalent via the Operations menu. It allows an administrator with the rights Manage downlink/uplink/ground templates to view and maintain corresponding message templates and models. If a template is marked as ‘Active’, all changes made in this window will take effect immediately after a save operation is completed. If marked as inactive, the template will not be considered in AIRCOM® ServerPlatform operations.

4.1.1.

Categories and Predefined Templates

Templates are divided in: • 3 types: Downlink, Uplink, and Ground. • 4 possible message sources: From Aircraft, From External User, From Local User, and Computer-Generated. The message categories are explained below, and they are organized per message type and source. Some templates are predefined in the system (stored in the “Predefined folder”) and cannot be created or deleted; they preexist in the system. They can however be modified for the airline’s needs. To help identify the predefined folder, its icon includes a lock.

4.1.1.1.

Downlink From Aircraft

Downlink From Aircraft templates are used to identify one type of downlink message received from an aircraft and to extract the data it contains. The template is the main criterion used for distribution to local and external users, as configured in the "Downlink Distribution" window. The models created with the template can then be used to rearrange the information in a different format for distribution to specific users. Category No Special Handling (typical)

Description Designates a typical downlink message requiring standard handling. Most downlink templates fit in this category.

35

ASP Administrator Guide Version 6.9a

Category ADS-C

AFN

CPDLC

Fault Report (AFDAS)

Media Advisory

OOOI

PDC Request

Description Designates an Automatic Dependent Surveillance - Contract (ADS-C) message based on the ED-100A specification containing information such as aircraft position and meteorological data. The decoding of its content is performed using a predefined field “ADS-C Decoded” or “ADS-C Preview” in user defined models. These models can be used for distribution of decoded ADS-C messages to users. Designates an ATS Facilities Notification (AFN) message based on the ED100A specifications containing information on aircraft datalink capabilities and address information exchange. The decoding of its content is performed using a predefined field “AFN Decoded” or “AFN Preview” in user defined models. These models can be used for distribution of decoded AFN messages to users. Designates a Controller Pilot Data Link Communications (CPDLC) message containing information about communications from the aircraft to an Air Traffic Controller (ATC). The content of these messages is encoded and the use of this template category allows the decoding of its content using the predefined field “CPDLC Decoded” in models. Thus the encoded content of the message is pre-formatted but the user can add other information before or after in its custom models. This decoding is provided for information only as AIRCOM® ServerPlatform should not be used as the gateway between the aircraft and the ATC for CPDLC communications. Designates a "real time" or "present leg" fault report message used by the ACARS Fault Detection and Alerting System (AFDAS). Faults identified in this message are monitored and appropriate notifications are sent as configured in the "Fault Configuration" window. Care must be used when defining records and fields for the faults to be properly processed. Designates a Media Advisory (MED) message used to mark establishment or loss of media (SAT or HF). Specify a field of type Media Status with value ES or EH to indicate SAT or HF acquisition and with value LS or LH to indicate loss of SAT or HF. Designates a downlink message that marks the change of flight stage for the originating aircraft to either one of the “Init”, “Out”, “Off”, “On”, “In” or “Summary” stage. OOOI messages are critical for ASP to track a flight along its different stages and consequently update the aircraft’s flight data. It is not necessary to send all 6 flight stages for an aircraft (the “Off” and “On” stages are sufficient) as long as those used are received in the right sequence. Otherwise the system will raise out-of-sequence events, reset the aircraft’s flight data and start over for a new flight. The category “OOOI” for ground templates is equivalent to this one although, when both downlink and ground OOOI are received for the same flight, it’s the flight data from the downlink that has precedence. Designates the downlink message that will trigger the sending of the predeparture clearance uplink, of category "PDC", matching the flight reported by the aircraft, if received. If no matching PDC is found at that moment, the predefined uplink "PDC Not Received" will be sent instead. For the request to work, the flight’s origin airport, Flight Identifier and ETD must be known, from being specified in this downlink or in one received previously. PDC uplinks can be repeated if this downlink is received more than once.

36

ASP Administrator Guide Version 6.9a

Category Post Flight Report

SVC Service Message

Default Template (predefined)

Service Check (predefined)

4.1.1.2.

Continuity

Description Designates a Post Flight Report (PFR) message containing maintenance and fault status information. The decoding of its content is predefined and the only available model is generated automatically at message reception. The user distribution can then use the "Predefined" model or "(raw)" to distribute it without reformatting. Designate a template that will match a service message (SVC) as the result of an undelivered uplink from a DSP that does not support MAS messages or for an uplink sent by another system than ASP. SVC messages, because they don't include DT and TE lines, can only be matched by templates of this category and will never match other templates even if defined with the "SVC" or wildcard SMIs. Likewise, templates of this category can only match messages with SMI "SVC". They can however be specialized by defining different SubSMIs in the freetext of the message. One SVC template pre-exists in the Downlink Templates root folder by default but additional ones can be created as needed. This allows for the configuration of fields, models and distribution to have a specialized handling of SVC messages. The AIRCOM® ServerPlatform does not use SVC for its processing. Predefined template “(default 620 message)” selected by default when a received downlink matches no other configured downlink template. This allows for the configuration of models and distribution as to have a default handling for all downlink messages. Predefined template “Service Continuity Check” used by SITAONAIR to test downlink message processing at customer premises. Template matching the service continuity downlinks from SITAONAIR, using a fictitious aircraft, to monitor the status of the connection and basic health of the system. This template must specify the auto-reply uplink template "Service Continuity Reply".

Uplink From External User

Uplink From External User templates are used to identify one type of uplink message received from an external user or application and to extract the data it contains. The template allows the identification of data from an AEEC 620 format message or a Type B / plain text message to be reformatted into a valid uplink message sent to an aircraft. The template must be configured in the "Uplink Distribution" window to be sent to the desired aircraft. Models can be used if reformatting is needed and the association of the right model for each aircraft is configured in the "Uplink Distribution" window. Category No Special Handling (typical) Flight Plan

Description Designates a typical uplink message requiring standard handling. Most uplink templates fit in this category. Designates a Flight Plan message sent by a flight operation system such as AIRCOM® FlightPlanner, Lufthansa LIDO or other compatible system. Flight Plan messages are decoded upon reception to be displayed in the FlightTracker or FE interface windows and used for the extrapolation or aircraft positions. Flight plan messages may be sent to the aircraft or not, based on the uplink distribution, without affecting their decoding by the system.

37

ASP Administrator Guide Version 6.9a

Category PDC

Description Designates a Pre-Departure Clearance (PDC) message sent by an Air Traffic Service Provider (ATSP) for a given flight. Upon reception of a message matching this template, an automatic PDC ack (category "Ground Computer-Generated - PDC acknowledgement") is sent back to the ATSP confirming the support of the PDC uplink. PDC can be configured to be validated against flight plans received by ASP before the PDC.

Default Template (predefined)

4.1.1.3.

The PDC category performs an automatic acknowledgement systematically sent back to the external user that sent the PDC message, according to the PDC specification (refer to document [E3]). The ack. message formatting is predefined, but it requires identifying specific fields in the incoming PDC message, these being the aircraft number (or flight identifier), the PDC Sequence Number, and the Proposed Departure Time. When selecting the PDC category, the Auto-Reply Ground Template gets disabled as it is unused and the Message Format is automatically set to Type B as per specification, the incoming PDC message is expected to be a non-AEEC 620 message. However, it is still possible to handle an incoming PDC message in the AEEC 620 format, should it be ever required. Predefined template “(default 620 message)” selected by default when a received message matches no other configured uplink template from external user, as long as it contains a valid 620 header. This allows for the configuration of models and distribution as having a default handling for all uplink messages.

Uplink From Local User

Uplink From Local User templates are used by local users to format and send an uplink message to one or many aircraft using the AIRCOM® ServerPlatform client. The template must define the fields to be requested to the user and the models specify how to organize them in the final uplink for each aircraft. The use of models is mandatory and the association of the right model for each aircraft is configured in the "Uplink Distribution" window. Category No Special Handling (typical) User Ack. to Downlink

Position Report Request (predefined)

Description Designates a typical uplink template appropriate for most user-generated uplinks to aircraft. Designates an uplink template to be used for the manual acknowledgement of downlink messages by local users. The users required to acknowledge the downlinks must be configured in the "Downlink Acknowledgement" window. Predefined template “Position Report Request” used to generate an uplink request to an aircraft for it to send a position report downlink, as to update its position in AIRCOM® ServerPlatform's tracking and FE interface. The template is used whenever a local user calls the Airplane's menu option "Request Position" from the FE interface. The template is also available when sending a new uplink message using the ASP client New Uplink window (provided the user has the proper template permissions).

38

ASP Administrator Guide Version 6.9a

4.1.1.4.

Uplink Computer-Generated

Uplink Computer-Generated templates are used for the automatic generation of an uplink message to an aircraft. No fields can be defined at the template level, but the models are mandatory to properly format the outgoing messages. The computer-generated templates must also be configured in the "Uplink Distribution" window with a model for each aircraft that can receive this type of message. Category No Special Handling (typical)

Event Handling Response

ADS-C Contract Request (predefined) Air-Air Dynamic Routing (predefined)

Auto-Acknowledgement (predefined)

Frequency Auto-tune (predefined)

Frequency Update (predefined)

Scan

PDC Not Received (predefined)

Table

Description A template used by the system to send an automatic message to an aircraft upon reception of a downlink from it, an event handling action or an action from the Sequencer. To enable this mechanism, this computer-generated template can be configured as the auto-reply template in a downlink template, as a "Reply to aircraft" action in any event handling action or with a "send uplink" action from the Sequencer. A template used by the system to send uplinks when an event is raised by the event handling mechanism. To enable this mechanism, this template must be defined in the “Reply to Aircraft” or “Uplink to Aircraft” for downlink template or fleet event handling. For more details on Event Handling, refer to section 8.1 Event Handling Windows. Predefined template “ADS-C Contract Request” used to send an ADS-C contract request uplink to an aircraft. It is used when managing ADS-C contracts through FlightTracker Map’s ATC panel. Predefined template “Air-Air Dynamic Routing” used to send an uplink to one or many aircraft after the reception of downlinks matching templates configured for air-to-air messaging. To do so, the triggering downlink templates must use fields of type "Air-to-air Uplink" and specify the desired "Address by" option. Predefined template “Auto-Acknowledgement” used to send an automatic acknowledgement uplink to the originating aircraft of a received downlink. It is used for every downlink template configured with the "automatic acknowledgement" option in the Downlink Acknowledgement window. Predefined template “Frequency Auto-tune” used to force-tune an aircraft to a predetermined VHF frequency based on its route, stage and specific position, as configured in the windows related to dynamic frequency management. The models configured under this template must include the field {@TUNE FREQUENCY} to work. A license with the DFM option is needed to get this template. Predefined template “Frequency Scan Table Update” used to load a predetermined VHF frequency scan table in an aircraft's MU based on its route, stage and specific position, as configured in the windows related to dynamic frequency management. The models configured under this template must include the field {@SCAN FREQUENCIES} to work. A license with the DFM option is needed to get this template. Predefined template “PDC Not Received” sent by the system when a PDC is requested (downlink template of category "PDC Request") by an aircraft but a matching PDC uplink cannot be found, based on the Flight Identifier, origin airport and ETD. The model text configured for the

39

ASP Administrator Guide Version 6.9a

Category

Position Report Request (predefined)

4.1.1.5.

Description uplink is meant to tell the pilot that a PDC for his flight does not exist following his request. Predefined template “Position Report Request” used to automatically request a position report from the aircraft (REQPOS). The template is used whenever a local user uses the "Request Position…" option from the Aircraft Tracking, FlightTracker or FE interface window.

Ground From External User

Ground From External User templates are used to identify one type of ground message received from an external user or application and to extract the data it contains. The template allows the identification of data from an AEEC 620 format message or a Type B / plain text message to be reformatted into a ground message sent to other users. The template must be configured in the "Ground Distribution" window to be sent to the desired users. Models can be used if reformatting is needed and the association of the right model for each user is configured in the "Ground Distribution" window. Category No Special Handling (typical) ADS-C

AFN

Description Designates a typical ground message requiring standard handling. Most ground templates fit in this category. Designates an Automatic Dependent Surveillance - Contract (ADS-C) message based on the ED-100A specification containing information such as aircraft position and meteorological data. The decoding of its content is performed using a predefined field “ADS-C Decoded” or “ADS-C Preview” in user defined models. These models can be used for distribution of decoded ADS-C messages to users. ADS-C messages from the ATC are uplink messages, but these uplinks should not be sent to the aircraft; this is done by the ATC. By defining a ground template of category ADS-C, these uplinks are matched as ground messages and can be distributed to users for information only. Designates an ATS Facilities Notification (AFN) message based on the ED100A specifications containing information on aircraft datalink capabilities and address information exchange. The decoding of its content is performed using a predefined field “AFN Decoded” or “AFN Preview” in user defined models. These models can be used for distribution of decoded AFN messages to users. AFN messages from the ATC are uplink messages, but these uplinks should not be sent to the aircraft; this is done by the ATC. By defining a ground template of category AFN, these uplinks are matched as ground messages and can be distributed to users for information only.

40

ASP Administrator Guide Version 6.9a

Category CPDLC

Dynamic Flight Assignments

EFB Integration

EFB XML

Flight Plan

FlightPlanner Schedule

Description Designates a Controller Pilot Data Link Communications (CPDLC) message containing information about communications from an Air Traffic Controller (ATC) to the aircraft. The content of these messages is encoded and the use of this template category allows the decoding of its content using the predefined field “CPDLC Decoded” in models. Thus the encoded content of the message is pre-formatted but the user can add other information before or after in its custom models. This decoding is provided for information only as AIRCOM® ServerPlatform should not be used as the gateway between the ATC and the aircraft for CPDLC communications. CPDLC messages from the ATC are uplink messages, but these uplinks should not be sent to the aircraft; this is done by the ATC. By defining a ground template of category CPDLC, these uplinks are matched as ground messages and can be distributed to users for information only. Designates a message sent by a flight operation system (such as a DFLT message from LIDO) that specifies a list of flights for one or many days in advance and their assignments to responsible and master desks. Flying aircraft are then attached to their matching assignments and the distribution of templates to "Flight Assignment Desks" is dynamically adjusted. See section 9.1.1, "Distributing Messages Based on Dynamic Flight Assignments" for a general description of the feature and how to configure it completely. Designates an Electronic Flight Bag (EFB) Integration template allowing AIRCOM® ServerPlatform to process GraFlite flight plans, NOTAMS and Weather Surface in XML format; the integration module aggregates the GraFlite XMLs into a single Aircraft Management Technologies (AMT) ComputerFlightPlan. The AMT compliant XMLs follow the XML Schema Definition (XSD) defined by AMT to allow the ASP and FlightMan to communicate for the EFB solution. A specific document "EFB Supplemental Information Guide" is available for more details. Specific ground template reserved for EFB XML decoding. The message that matches this template must respect and refer to one of the AEEC 633 predefined XML schemas. AIRCOM® ServerPlatform will convert an incoming EFB XML message into a name-value pair list from the XML content. This can be re-injected into the ASP using distribution and if another uplink or ground template matches that name-value pair message, it can be decoded, formatted using models and distributed as desired. Designates a Flight Plan message sent by a flight operation system such as AIRCOM® FlightPlanner, Lufthansa LIDO or other compatible system. Flight Plan messages are decoded upon reception to be displayed in the AIRCOM® FlightTracker or FE interface windows and used for the extrapolation or aircraft positions. Flight plan messages received as ground messages may be sent to other users or not (but not to the aircraft), based on the ground distribution, without affecting their decoding by the system. Designates a message containing one or many Flight Schedule records created either manually or by third-party applications. A Flight Schedule can then be used by flight planning dispatchers to create flight plans. Record fields are usually comma-separated in a predefined format, providing both mandatory and sometimes optional details defining a flight. FlightPlanner Schedule messages are received and validated by AIRCOM® FlightMessenger and provided to AIRCOM® FlightPlanner for flight planning processing.

41

ASP Administrator Guide Version 6.9a

Category FlightPlanner Schedule Update

OOOI

Default Template (predefined)

4.1.1.6.

Description Designates an Ad-hoc Schedule Message (ASM). ASM is a standard message format defined as part of IATA Standard Schedules Information Manual (SSIM), allowing airlines to electronically exchange information on a deviation from the basic flight schedule. Based on the action identifier as part of the message, the flight schedule is created, amended, cancelled or reinstated. FlightPlanner Schedule Update messages are received and validated by FlightMessenger and provided to FlightPlanner for flight planning processing. Designates a ground message that marks the change of flight stage for the referenced aircraft to either one of the “Init”, “Out”, “Off”, “On”, “In” or “Summary” stage. OOOI messages are critical for ASP to track a flight along its different stages and consequently update the aircraft’s flight data. It is not necessary to send all 6 flight stages for an aircraft (the “Off” and “On” stages are sufficient) as long as those used are received in the right sequence. Otherwise the system will raise out-of-sequence events, reset the aircraft’s flight data and start over for a new flight. The category “OOOI” for downlink templates is equivalent to this one although, when both downlink and ground OOOI are received for the same flight, it’s the flight data from the downlink that has precedence. Predefined templates “(default 620 message)” and “(default non-620 message)” selected by default when a received message matches no other configured ground template from external user. The first one is matched if the received message contains a valid 620 header, otherwise the second. This allows for the configuration of models and distribution to have a default handling for all 620 and non-620 ground messages.

Ground From Local User

Ground From Local User templates are used by local users to format and send a ground message to other users or applications using the AIRCOM® ServerPlatform client. The template must define the fields to be requested to the user and the models specify how to organize them in the final messages for each user. The use of models is mandatory and the association of the right model for each user is configured in the "Ground Distribution" window. Category No Special Handling (typical)

Description Designates a typical ground template appropriate for user-generated ground messages.

42

ASP Administrator Guide Version 6.9a

4.1.1.7.

Ground Computer-Generated

Ground Computer-Generated templates are used for the automatic generation of a ground message to external users or applications. No fields can be defined at the template level, but the models are mandatory to format the outgoing messages. The computer-generated templates must also be configured in the "Ground Distribution" window with a model for each user that can receive this type of message. Category No Special Handling (typical)

Description A template used by the system to send an automatic message back to an external user or application upon reception of an uplink from it. To enable this mechanism, this computer-generated template can be configured as the auto-reply template in an uplink template or with a "send ground" action from the Sequencer. ETA Update Predefined template “ETA Update” used to format the Estimated Time of Arrival (ETA) changed notifications sent to users. The model(s) configured under this template can use the predefined fields {@ETA} and {@ETA PREVIOUS} to report the change in ETA to the users. See section 9.2.9 for more details. PDC Acknowledgement Predefined template “PDC Acknowledgement” used to send an automatic (predefined) acknowledgement to a Pre-Departure Clearance (PDC) message sent by an Air Traffic Service Provider (ATSP). The model configured under this template must respect the format expected by the ATSP and include the field {@PDC - PARTICIP CODE} which will take a ‘Y' or ‘N' value based on if the PDC uplink can be honored or not. Auto-Ack to Uplink Template used to send a formatted acknowledgement to users when an Failed uplink message has failed to be delivered to the aircraft. Models of this template can include the predefined fields {@UPLINK STATUS CODE} and {@UPLINK STATUS DESC} explaining the reason for the non-delivery of the uplink; {@UPLINK ID} to relate the original uplink if a field had been designated as type "Uplink ID" in the uplink template and {@UPLINK /MA} to recover the /MA in the original uplink, if the was one, otherwise the one used by ASP. To receive this acknowledgement, recipient users must have their uplink delivery notification format set to “Using Uplink Ack templates”. Auto-Ack to Uplink Template used to send a formatted acknowledgement to users when an Success uplink message has been successfully delivered to the aircraft. To receive this acknowledgement, recipient users must have their uplink delivery notification format set to “Using Uplink Ack templates”. Table 4-4 Template Categories and Message Sources

Some categories like “Downlink From Aircraft - ADS (745)” or “Downlink From Aircraft Post Flight Report” use a predefined reformatting, hence not requiring defining Records and Fields, nor models. Therefore, for such a category, the Records and Fields tabs are hidden. Also, some data components are displayed only for some specific template categories (e.g. OOOI Type only for “Downlink From Aircraft – OOOI”, no Template Identifiers for “Downlink From Aircraft – Default”).

4.1.2.

Typical Message Processing

43

ASP Administrator Guide Version 6.9a

To position the template role in the system’s message processing, here is a summary of typical downlink message processing: 1. An incoming downlink comes from an aircraft. 2. AIRCOM® ServerPlatform tries to match that message with one of the defined template. 3. If a match is found, then it looks for the list of users to which the message should be distributed. 4. For each message recipient, it looks for an associated model for that template. 5. If a model is associated, it reformats the message accordingly. 6. ASP distributes to the user the reformatted message whenever available; otherwise it distributes the original, raw message. The only case where the two raw and reformatted messages are distributed is for users of the local user type. 7. If any acknowledgement applies, ASP flags the user marked as the acknowledgement user (within the distribution process), and formats and sends any configured automatic acknowledgement to the originating aircraft. As another example, here is a summary of typical uplink from external user message processing: 1. An incoming uplink comes from an external user, like an application, to AIRCOM® ServerPlatform. 2. ASP tries to match that message with one of the defined Uplink Templates. 3. If a match is found, then it looks for a specific model of that template associated to the aircraft specified as the end destination of the message. 4. If a model association is found, it reformats the message accordingly. Generally, the reformatting purpose is to make the uplink a valid AEEC 620 and compatible with a specific aircraft avionics requirement to avoid uplink rejection. 5. ASP either sends the reformatted message (a model was found) or the original message as-is (distribution configured to send the raw message and the original message is a valid AEEC 620) to the aircraft, or it does not send anything (no distribution configuration found). To complete message-handling configuration, other elements need to be managed in addition to the templates and models themselves. This is summarized below and will be described further in this document. • Distribution to users and user groups based on various criteria (downlink and ground). • An acknowledgement specification for each specific template (downlink only). • Distribution to airports of downlink messages based on the departure and arrival airports of the current flight for the aircraft sending the message (downlink only). • Distribution to aircraft, where model reformatting is often essential (uplink only).

44

ASP Administrator Guide Version 6.9a

•

Template permission granting to users in order to control for specific users which type of messages will be processed or not (uplink and ground).

The following sub-sections describe the totality of what a user may encounter for any of the template types and sources. When some data or function is not available, it is because it does not apply to the context, and when it applies only in a specific context, it will be mentioned. Before getting into the details of each component of a template, here is the description of the core template functions.

45

ASP Administrator Guide Version 6.9a

4.1.3.

Template Core Functions1

The window is based on a folder tree structure in which the root item (‘Downlink Templates’, ‘Uplink Templates’, or ‘Ground Templates’) is fixed. Underneath the root folder, the templates administrators can organize templates into any custom folder structure they desire. The following is the window-wide core functions description. Function Refresh (F5)

Find (Ctrl-F), Find Next (F3)

Wizard On/Off

New

1

Description It is available both in View and Edit (Add/Modify) modes. In Edit mode, allows refreshing data that is independent of templates, but that is used while defining template components. The data elements refreshed are: list of users used to define the template owner, the acknowledgement level which depends on the settings established via the Downlink Acknowledgement window (Downlink Templates only) and the list of Lookup Tables that are used in the definition of template and model fields. Also refreshes the message guide display if any manual changes have been performed in the field or record configuration. In View mode, in addition to refreshing data that is independent of templates, it also refreshes the complete list of folders, templates, and models. Allows searching for template properties (name, category, active flag, priority, flight stage, SMI and SubSMI, and send on-hold uplinks flag). The Find dialog adjusts its display according to the ‘Search In’ selection data type. The string search occurs anywhere in the data element string (e.g. searching for ‘B7’ in ‘B777’ or ‘B747’ is a match). The search is by default case insensitive, unless the ‘Match Case’ option is checked. As long as the Templates window stays opened, the ‘Find What’ lists the searched strings history since the window was opened for quick pick. The keyboard key combination ‘Ctrl-F’ opens or brings to the front the Find dialog. The ‘F3’ key performs a ‘Find Next’ (same as the button in the dialog) on the last specified search criterion, no matter if the dialog is opened or not. The search cycles through the matching faults. The ‘Find’ function is available in view mode or in edit modes. Toggle button allowing enabling or disabling the fields and records definition wizards. It does not apply to model or folder selections. When the wizard is on (pushed in), clicking the ‘Field’, ‘Record’, or ‘Define’ button launches the corresponding wizard while when wizard is off, the same action manually creates a new blank field of record. Dropdown button with three options available: 1) New Template, 2) New Model, and 3) New Folder. The dropdown button is enabled when in view mode (when opening the window or after the save or cancel button has been pressed), while it is disabled when in add or modify mode (after a new or modify button has been pressed). Pressing this button switches to add mode. The dropdown button options will be disabled if not available. For example, when the user selects the root of the tree (left side of the window), no new model may be created because the system does not know to which template it should add the new model. However, creating a new template is always possible, except when the parent folder is the reserved “Predefined Templates” folder; no predefined templates can be created. If the dropdown button itself is clicked (not one of its options), the default option executed and is indicated by the button tool tip text.

Refer to Figure 4.6 for a view of most of the elements described in this section. 46

ASP Administrator Guide Version 6.9a

Function New Template

New Model

New Folder

Duplicate

Modify

Delete (Del)

Description Enabled when in view mode, while it is disabled when in add or modify mode. It switches to add mode. Creates a new template, either under the currently selected folder or under the parent folder if the selection is a template (other than a predefined template), with default name ‘New Template’. Enabled when in view mode, while it is disabled when in add or modify mode. It switches to add mode. Creates a new model with default name ‘New Model’; either under the currently selected template or under the parent template if the selection is a model. Note that models can be created for any predefined template. Enabled when in view mode, while it is disabled when in add or modify mode. Does not switch to add mode, stays in view mode. Creates a new folder, either under the currently selected folder or under the parent folder if the selection is a template or model, with default name ‘New Folder’, and the folder name is immediately editable, allowing changing it on the fly. The folder creation cannot be cancelled. Once created, to get rid of a folder, it must be deleted. Duplicates the current tree selection – a template with its models or a model and its content. Note that folders and predefined templates cannot be duplicated. It is disabled when a folder or a predefined template is selected. Otherwise enabled when in view mode (when opening the window or after the save or cancel button has been pressed), while it is disabled when in add or modify mode (after a new or modify button has been pressed). After duplication, the duplicated template is selected in view mode, and its name is changed “Copy of [original template name]” and made unique if required, while the model names and all other configuration is identical to the original template. Duplicating a model directly changes the model name to “Copy of [original model name]” (still made unique as needed) and selects the duplicated model in view mode. Modifies the current tree selection – a template, a model or a folder name. Note that when modifying a folder name, the operation stays in view mode and the change is directly saved – not through a Save operation. Enabled when in view mode, while it is disabled when in add or modify mode. It switches to modify mode only when modifying a template or model. It is disabled if not available. For example, cannot modify the root folder, or if there are no templates or folders defined. Note that even though the predefined folder and the predefined templates cannot be deleted or new ones cannot be created, they all can be modified, including their names and content. Deletes the current tree selection – a template, a model or a folder and its content. Note that folders may contain templates, models, and other folders. Enabled when in view mode, while it is disabled when in add or modify mode. Deleting does not affect the operation mode – always stays in view mode. It is disabled if not available. For example, cannot delete the root folder, or if there are no templates or folders defined. A confirmation dialog box will request user approval prior to proceeding with a template or model deletion. When deleting a folder, additional confirmations are required – either delete sub-folders and templates (with their models) all at once or confirm template deletions individually. When doing individual confirmations, it is always possible to delete all at once the remaining sub-items or to cancel the operation at any time. The folder initially being deleted will effectively get deleted only if all sub-items got deleted.

47

ASP Administrator Guide Version 6.9a

Function Save

Description Enabled when in add or modify mode, while it is disabled when in view mode. Switches to view mode if the save operation is successful. It saves the current template or model changes. No save required modifying a folder name. Most validation occurs at save time, like mandatory data not specified or invalid values, and the user is advised via a message dialog. Depending on the criticality of the validation, it may allow saving anyway or it may prevent saving a force a corrective action prior to saving.

Cancel

Distrib(ution)

Permis(sions)

Ack(nowledgeme nt) Airport (Distribution)

Close (Ctrl-L) Expand

Collapse

Event Handling

Among these validations, one special validation warns about a possible duplicate identification between templates. The validation cannot certify the duplication (e.g. if the same SubSMI value is used at different locations in two different messages), but it is important to review these because if a real identification duplication exists, then message processing may not behave as expected and some messages will not match the desired template. Enabled when in add or modify mode, while it is disabled when in view mode. Switches to view mode and cancels any changes made to the current template or model. It does not apply to folders. Launches the Downlink User Distribution, Uplink Aircraft Distribution, or Ground User Distribution window, depending on the context, allowing management of all distribution rules. Launches the Uplink Permissions or Ground Permissions window, depending on the context, allowing management of all user template usage privileges. A user may send to AIRCOM® ServerPlatform, or use ASP to send messages that match only the templates for which he/she has been granted the permission. It applies only for the uplink and ground message types. Launches the Downlink Acknowledgement window allowing management of acknowledgement rules for all downlink templates. It applies only for the downlink message type. Launches the Airport Distribution window allowing management of all airport distribution, destination users and Type B address lists per airport. Airport distribution is occurs when a downlink message is received from an aircraft which is tracked with known departure and arrival airports. If these airports are configured with distribution lists, then the message is distributed accordingly. It applies only for the downlink message type. Closes the Templates window. This command expands either the currently selected tree item or the full tree if the ‘All’ check box was checked. As opposed to clicking the ‘+’ signs next to a tree item or double-clicking the item, the expand command expands all subfolder levels rather than just the first level. This command collapses either the currently selected tree item or the full tree if the ‘All’ check box was checked. It is equivalent to clicking the ‘-’ signs next to a tree item or double-clicking the item. Defines all possible events’ handling actions for downlink, uplink, or ground templates. The folder level event handling is saved immediately when exiting the events handling window, while the template level event handling is saved with the corresponding save operation (refer to section 8.1 for more details). Event handling defined at the folder level applies to all sub-items (other folders and templates) by inheritance. However, at any sub-level, it is always possible to set the “Override Parent Handling” option and define specific handling actions just for one or a few sub-items. All applicable events and actions are available at any

48

ASP Administrator Guide Version 6.9a

Function

Convert

Description level in the tree, except the “Invalid Message” event, which may only apply to the root folder “Downlink Templates”. Event handling applies to all message types, but the list of available events vary depending on the context. This command converts the selected template from its current category to another valid category. The category to convert to is selected via a dialog presenting only valid conversion choices. Please note that template category conversion may lead to data losses if not used with care (e.g. models may get deleted). It is important to read messages that may popup during the conversion, advising about such situations. When converting a template to the category “Downlink From Aircraft – OOOI”, the user has to choose the flight stage for which the template applies, because the flight stage in an OOOI template is mandatory. Table 4-5 Templates – Core Functions

Status bar panels: The status bar has two additional panels for Templates: Fourth Panel from Left: Displays the current template definition wizard status (on or off). It does not apply to models. Fifth Panel from Left: Displays the number of templates. Popup menus are also available for Templates administrator users. One of the popup menus available throughout the window is a duplication of the toolbar commands. The best approach is to try the right mouse button over the different window regions and explore these popup menu shortcuts. A few exceptions provide commands via popup menus that are uniquely accessible via these popup menus. Only the commands appropriate to the context are displayed in the popup menus. These specifically apply to some data controls, they are available only in Add or Modify modes, and will be detailed within the next subsections. The following subsections will present each of the main components of Templates, and when applicable, specify cases where it applies only to some, not all, template contexts.

49

ASP Administrator Guide Version 6.9a

4.1.4.

Templates Description

When a template is selected, the window is divided into up to four tabs or panels: 1) General, 2) Records, 3) Fields, and 4) Advanced. Some specific template categories will present only two panels because they do not support field and records.

Figure 4.5: Templates – Downlink Folder Panel

The tree displayed on the left side of the window (Figure 4.5) is the key navigation control to scroll through, select and view existing templates and models. The root of the tree is generic, while its children are all templates in the system (may be organized within folders) and each template has its models as children (if any). Selecting the root or any other folder displays the folder panel on the right, selecting a template displays its information on the right panel while selecting a model displays its information in a different right panel discussed in the next section. Folders marked with a lock means they cannot be deleted and/or renamed. The root folder cannot be deleted and renamed, while the predefined folder can be renamed. The lock helps finding that predefined folder if ever it has been renamed.

50

ASP Administrator Guide Version 6.9a

Figure 4.6: Templates – Downlink From Aircraft General Panel

The most generic templates (e.g. Downlink from Aircraft or Uplink from External User) have their information spread into the data panels listed in Figure 4.6: 1) General, 2) Records, 3) Fields, and 4) Advanced. A help icon describing what the current template category does and means is available next to the category name; just leave the mouse over the question mark (see above) to show the tooltip. A common text field exists in each panel: the ‘Message Guide’ text box. This text box is used to highlight in a message guide (if any specified) the result of the various data definitions performed (SMI, SubSMI 1/2/3, Records and Fields). The message guide is not required to define a template; it is just a way to view and validate the result of the definition and to greatly help in the process of defining a template. However, if no message guide is specified, the user will have to define data without the help of the various wizards available only when a message guide exists (and when “Wizard On” is selected in the Toolbar). In other words, the user will have to work in manual mode, and of course refreshing the display would be useless without a message guide. There are two ways to define or change the message guide and it will be discussed later in this section. 51

ASP Administrator Guide Version 6.9a

Now what happens when the message guide (assuming one is defined) is refreshed to highlight data definition? For each individual data element that can be highlighted (i.e. SMI, SubSMI 1/2/3, Records and Fields) the system will search for it in the message guide as per the corresponding definition. A few things might then happen. The best case is when everything is found and highlighted where it is expected, which means the template is correctly defined (at least for the message guide displayed) in the respective message guide text boxes. It brings the point that the message guide used should as much as possible illustrate all data content cases that the template shall cover. In other cases, for specific data (e.g. the SubSMI), the data is found in the message guide but it does not correspond to what was expected. This could mean two things: the data definition is wrong or the message guide used to illustrate that definition is incomplete. This case is the main reason for highlighting, i.e. to get a visual cue that something is wrong. Another case could be that the data is simply not found, generally leading to a dialog box popup indicating the data not found and the reason why it was not found. In the latter case, no corresponding highlighting will be visible in the message guide text box. Note that each time a different template is selected in the tree, all its data is displayed in the right panels, including a refresh of the message guides, so leaving many incorrectly defined templates in the tree may be annoying when navigating through them, because dialog boxes will pop-up each time it gets selected; but on the other hand, this helps identify potential template problems. Now, let’s discuss the each data panel of a template, starting with the general parameters.

4.1.4.1.

General Panel

Figure 4.6 presented before illustrates the template General panel and will be referred to in this section. The following describes the data components of the General panel. Data Category (label)

Name (text)

Description The name of the template category. Categories are organized around four possible sources for the messages the templates represent: From Aircraft, From External User, From Local User, or Computer-Generated. Refer to section 4.9 for more details. The blue question mark next to the category allows viewing a description of the category; just move the mouse over it and leave it still. The name of the currently selected template. It defaults to “New Template” for a new template and it is mandatory before saving (must not be empty). It also must be unique among the list of all templates, and if not, a dialog will advise upon saving.

52

ASP Administrator Guide Version 6.9a

Data Active (option)

AEEC 620 Format (option)

Priority (list and icon)

Description When checked, this option makes the template valid for operations and the system considers it. Otherwise, the template is ignored. The default is active. The option is useful to save templates that are not completely defined or that have not been tested yet. Note that an inactive template is displayed with a grayed template icon in the tree. When checked, this option indicates that the messages intended to match this template are of the AEEC 620 format specification. If not, the message would be of pure Type B format or simply a plain text message. However, note that for downlink messages, the format is always AEEC 620, which explains why the option is always checked and grayed out for downlink templates. A message of AEEC 620 format is a message with header (QU, Originator, SMI, TEI lines, and optionally a DT line) and free text while a message of Type B format is a message with only a QU and Originator lines followed by free text. A flag set to indicate that messages matching the template are of the specified priority. The five priority levels are (from lowest to highest): (none) No priority (default selection) Take note Low

Template Owner (list)

Auto-Reply Uplink Template (list)

Auto-Reply Ground Template (list)

Flight Stage (list)

Acknowledgement (options)

Medium High The priority levels are identified using the same icons as in the User Mailbox window (see document [S4a]). A configured AIRCOM® ServerPlatform local user specified as the owner of the template. Typically the creator of the template and the person to consult in case of problems with that template. List of all uplink templates of category ‘Uplink Computer-Generated - AutoReply to Downlink’, that may be used to automatically reply to the aircraft that sent downlink messages matching the current template. This template will be used only if auto-reply is configured and required. It applies only for the downlink message type. List of all ground templates of category ‘Ground Computer-Generated Auto-Reply to Uplink’, that may be used to automatically reply to the user that sent incoming uplink messages matching the current template. This template will be used only if auto-reply is configured and required. It applies only for the uplink message type. A list of supported flight stages sorted in the predefined logical sequence (i.e. INIT, OUT, OFF, ON, IN, SUMMARY) in which they should be received. This value is displayed only if the message category is “Downlink from Aircraft – OOOI” or “Ground From External User – OOOI”. The flight stage defaults to blank. Data is set automatically according to the acknowledgement settings of the current template (the controls are read-only). For a new template, it will always be unchecked. Afterwards, each time the acknowledgement settings of the current template will be changed (Downlink Acknowledgement window), it will automatically reflect in these data controls after a Refresh or the next time the window is opened. It applies only for the downlink message type.

53

ASP Administrator Guide Version 6.9a

Template Identification (list)

List of all applicable template identifiers. For downlink templates, there is one SMI, three SubSMI, and lists of aircraft registration numbers and aircraft types available to uniquely identify a message to a template. Identifiers may not all be used, and whenever saved, lower SubSMI are moved up to avoid having holes in the SubSMI definition. In other words, if SubSMI 2 is not defined, but SubSMI 3 is defined, at save time, SubSMI 3 will become SubSMI 2. Also, any SubSMI may be moved up or down the definition sequence if ever desired using the ‘Move Up/Down’ buttons. SMI (text): Standard Message Identifier, a single 3 characters value. It is mandatory before any downlink template or any AEEC 620 uplink or ground template can be saved, because it is the basis of AEEC 620 message differentiation. The value of the SMI must be found in the header of AEEC 620 messages to match the template. However, there is the wildcard character ‘?’ that can be used to match any SMI valid character. Hence, an SMI defined as ‘???’ would match any message. Of course, the wildcard character shall be used with care. The SMI can be automatically set using the ‘Define’ button if the Wizard is on and the message guide is a valid AEEC 620 message (uses the message guide to find the SMI) or the value can be set manually. SubSMI (definition): Second, third, and fourth level SMI to further differentiate messages. The value must be found in the messages to match the template. No wildcard characters are allowed for SubSMI and they are defined in the same way as fields (see section 0, Fields Panel). Their value and definition can be set using the ‘Define’ button if the Wizard is on and the message guide is not empty (brings up the field wizard described later) or it can be set manually. Definition parameters are described further below. When the message format is AEEC 620, the SubSMI are not mandatory, but when it is not and that identifiers are required (e.g. a Type B uplink from external user), then the SubSMI 1 is mandatory. Template filters: Matching templates can be filtered according to the sender of the message we are trying to match as additional filter criteria. These criteria are aircraft or aircraft types for downlinks and external users for uplinks and grounds. For example, for a downlink message coming from aircraft “A”, a template is found for which the SMI and SubSMIs match, then the aircraft criteria (if any) must match the sending aircraft “A”, otherwise this template will be ignored as not matching the message. However, if no additional criteria are defined, only the SMI related identifiers are used to identify a match. For downlinks, both aircraft registration numbers and aircraft types can be specified as filter criteria, while uplink and ground templates allow specifying configured external users. In the case of downlinks, the filter criteria are considered in the order from the most specific to the most generic: aircraft, aircraft sub-type, and aircraft type. This is important if say one template would match due to the aircraft type matching, and the other due to the aircraft registration matching; in this scenario the 2 nd template with aircraft registration matching would be the final match (i.e. more specific than aircraft type). Multiple criteria can be specified for each filter type, and as soon as one of these criteria matches the sender of the message, the template can qualify for a match. Defined criteria are displayed to the right of the identification list (comma-separated), but they are edited using the Define button which opens

54

ASP Administrator Guide Version 6.9a

Data

Value

SubSMI field definition (text and numeric): Define: SMI field

Description a specialized selection dialog (see Figure 4.7: Templates – Filter Criteria Dialog). In conclusion: The template identification process considers the SMI and SubSMIs first, and when additional filter criteria are defined, only messages meeting these criteria will qualify to match the template. A text field specifying either the three (3) characters SMI value or a SubSMI value (up to 50- characters). As opposed to other template fields, the template identifiers require a specific value in order to uniquely identify the template that matches a message. These values are therefore compared to the text at the equivalent position in incoming messages. If a value is deleted, it deletes the corresponding SMI or SubSMI field. SubSMI field definition parameters (besides the value text) are the same as for fields definition from the Fields tab. The way to define fields’ localization applies to both SubSMI and Fields from the Fields panel (see section 0, Fields Panel ). It automatically finds the three SMI characters in the message guide, generally starting with the character, but always following the originator line of a valid AEEC 620 message, e.g. .QXSXMXS 272229. If an SMI is already defined, it will redefine it upon user confirmation. If no message guide is defined, the button is grayed out.

Define: SubSMI fields

The SMI can also be defined manually by typing the SMI characters directly in the SMI value text box next to the Template Identification list on the General tab. Any following refresh will highlight it if it matches the message guide. It launches the Field Wizard (see section 4.1.5.3) with the field name predefined only when Wizard is turned on (Wizard button pushed in). If a SubSMI is already defined, it will redefine it using the wizard results, if the wizard completes successfully. If no message guide is defined, the button is grayed out.

Define: Filter

Move Up/Move Down

The SubSMI can also be defined in manually by typing the SubSMI characters directly in the SubSMI value text box next to the Template Identification list on the General tab and by setting the desired localization data. Any following refresh will highlight it if it can be found and matches the message guide. It launches the Edit Template Identification Filter dialog (see Figure 4.7: Templates – Filter Criteria Dialog) which shows all existing elements specific to the filter type (aircraft registration or nose numbers, aircraft types or external user names). It allows selecting multiple filter criteria. Disabled when not applicable, these buttons allow moving SubSMI definitions up or down between the 3 possible indexes. The SMI cannot be moved.

55

ASP Administrator Guide Version 6.9a

Data Message Guide (text)

Wrap Text

Browse

Edit

Clear

Description Text box holding a message guide (or message example) used to illustrate data definition results using highlighting. Red, blue, green, and magenta colors; red and blue for delimiters and identifiers, green and magenta for data. The same guide is used in the three template data panels (General, Records and Fields). However, they are used to highlight different elements of the template. The General one highlights the SMI and SubSMI fields. It is also from the General that the message guide can be changed, cleared or edited for the entire template (changes will take effect in the three data panels). The selected field in the ‘Template Identifiers’ list is marked as bold and underlined in the message guide, including any red delimiter or identifier. The latter delimiter and/or identifier are only visible when specifically selecting one of the possible fields. Otherwise, only the field value is highlighted in magenta (no bold and no underline). The wrap text option allows forcing the Message Guide box to wrap or not its content. The default value is no wrapping. The option also applies to the message display in the record and field panels (when applicable). Used to launch the Traffic Log Viewer in order to find a valuable message to set in the message guide. If no perfect message is found, the user can choose one that is the closest to what is needed and then edit it using the ‘Edit’ button described below. From the Traffic Log window, use the appropriate button (either ‘DN Temp.’, ‘UP Temp.’, or ‘GND Temp.’) to return to the Templates window and set the message guide of the currently edited template (requires a user confirmation). Note that the Templates window will be in a “browsing” state (i.e. waiting for a response from the Traffic Log window) as long as the user will not save or cancel the template for which the browse button was clicked, or as long as the Traffic Log window ‘[XXX] Temp.’ button will not have been pressed. However, this does not prevent the user from continuing editing in the Templates window because the browsing operation is totally asynchronous. Used to edit the message guide currently displayed via an edit dialog (see Figure 4.8: Template Edit Message Guide). The dialog offers special insert functions available from a popup menu over its text box. These functions allow inserting any ASCII character like the character typically appearing in front of the SMI and a full AEEC 620 or Type B (uplink and ground message types only) message template in which variables delimited by the ‘< >’ characters should be replaced by realistic data. The dialog can also be used, for example, to paste a message copied from the Mailbox Message Viewer using the copy (Ctrl-C) command. Used to clear, after user confirmation, the contents of the message guide.

56

ASP Administrator Guide Version 6.9a

Data Delete

Description When right clicking with the mouse over the message guide text box while in add or modify edit mode, a popup menu may appear, depending where the cursor is in the box. Whenever the cursor is over a highlighted series of characters (i.e. SMI or SubSMI), the ‘Delete’ function is displayed. This is one way to delete an identifier field. Moreover, as long as the cursor is over some field highlighting in the message guide (not necessarily with the complete field selected), the ‘Delete’ function will still show and work the same. On the other hand, if there is a manually made selection that covers the field, but also goes beyond (in non-highlighted areas), then the ‘Delete’ function will not be available. Another way to delete a field is either to manually delete the value string or to right click over the corresponding identifier in the ‘Template Identification’ list and select ‘Delete’. You can also select the value text (occurs when left clicking in the text box), right click the mouse and select the ‘Delete’ option.

Copy message guide

Deleting a field using any of the above methods automatically clears all the field localization data defined below the value text box. Using Ctrl-A (select all) and Ctrl-C (copy), it is possible to copy a message guide even in view mode, i.e. no need to modify a template and open the edit message guide dialog. Table 4-6 Templates – General

The SubSMI fields are defined very similarly to the other fields in the Fields panel. Please refer to “Table 4-8 Templates – Data components of the Fields panel” for details on the data located to the right of the Template Identification list. For your reference, here is the dialog used to edit template filter criteria. Check the desired items individually, using multiple selection, or using the Check All / Uncheck All buttons. The “Show Selected Only” allows viewing only the currently checked items and the “Selected Count” identifies the number of checked items. The dialog opens with the currently defined filter criteria already checked and changes are returned to the template definition when clicking OK. Cancel ignores any changes made since the dialog was opened.

57

ASP Administrator Guide Version 6.9a

Figure 4.7: Templates – Filter Criteria Dialog

Figure 4.8: Template Edit Message Guide

Before going to the records and fields panels’ description, note that the number of currently defined records and fields is displayed in the respective tabulation caption; hence without having to click on the tabs, it is possible to know how many records and/or fields are already defined.

58

ASP Administrator Guide Version 6.9a

4.1.4.2.

Records Panel

Figure 4.9 presented below illustrates the template Records panel and will be referred to in this section.

Figure 4.9: Templates – Downlink From Aircraft Records Panel

The concept of record and record block: A record block is a set of record instances grouped together and has one start and one end. A record is one instance of record (one occurrence) within a record block, which content is specific fields that repeat in each occurrence. Therefore, the block shall be delimited first and then each record occurrence shall be identifiable within the record block. Only then it will be possible to define fields within one record occurrence, and this is described in the next section.

59

ASP Administrator Guide Version 6.9a

The following describes the data components of the Records panel. Data Message Guide (text)

Existing Records (list)

Record Name (text)

Block Start Identifier (text) Block Delimiter (text) Block Delimiter Occurrence (numeric) Block Start offset (numeric) Block End offset (numeric)

Description Same content as the General panel message guide, but with two differences: (1) It cannot be changed, cleared, or edited from this panel. (2) Highlighting is for record blocks and the first record occurrence only. Records are highlighted as follows: • Block start and end identifiers, as well as delimiters (if any) are highlighted in red. • Record instances start identifiers or separators are highlighted in blue. • The first record occurrence is highlighted in green (if it can be located with a definite start and end). The currently selected record in the records list (described below) is marked as bold and underlined (i.e. any record block delimiter/identifier, record instances separator/identifier and first occurrence of record). Only the currently selected record has its identifiers/delimiters (if any) displayed in red and blue. Otherwise, only the first record occurrence data is highlighted in green, without any bold and underline. List of existing record names. Not editable directly, however used to browse through existing records. Names in the list are updated as soon as the Record Name text has been edited. An item is inserted in the list in one of two ways: successfully completing the Record Wizard (using the ‘Record’ button when Wizard is on) or manually using the ‘Record’ button when Wizard is off. Name of the record, which defaults to ‘New Record’ when adding a new one. Duplicate names are not authorized and automatically prevented. In other words, if a user creates a record with name “New Record” and that this name already exists, it will automatically change the name to “New Record_1”, and so on. The Record Name cannot be empty. If emptied by the user, it will be filled with “New Record” (or “New Record_1”, …). Also, record names starting with the character “@” are not allowed as this is a reserved character for predefined fields in models. Similar to the SubSMI ‘Start Identifier’ described in section 4.1.4.1, but now applies to identify the start of the record block. Similar to the SubSMI ‘Delimiter’ described in section 4.1.4.1, but now applies to identify the start of the record block. Similar to the SubSMI ‘Occurrence’ described in section 4.1.4.1, i.e. the occurrence of delimiter after which the record block starts. Similar to the SubSMI ‘Offset’ described in section 4.1.4.1, but now applies to identify the start of the first record occurrence within the record block, relative to either the Block Start Identifier or to the start of the message free text. Similar to the SubSMI ‘End offset’ described in section 4.1.4.1, but now applies to identify the end of the record block, relative to either the Block End Identifier or to the end of the message free text.

60

ASP Administrator Guide Version 6.9a

Data Block End Identifiers (text) & Until End (true/false)

Record Identifier (text)

Record (text)

Start

Separator

Record Occurrence (numeric)

Record Length (numeric) New Record (Record button)

Duplicate Record

Description Same as for the block start identifier, but this time it marks the end of the record block. Once found in the message, it is interpreted that the record block ends just before the end identifier, i.e. no record occurrences can be found beyond the block end identifier. Up to three (3) different end identifiers can be specified in conjunction with the “Until End” option. When parsing a message to identify a record block with multiple end identifiers, the first valid end identifier found in the message starting from the block’s start identifier is the one used (i.e. the left-most identifier found in the message). Ultimately, if none of the end identifiers are specified or found, but the “Until End” option is checked, the block ends at the end of the message. If none of the options are set, the warning “Cannot find end of record block” raises when trying to display the record block. This is equivalent to the Block Start Identifier, but for each record occurrence. After the record start identifier (if defined) starts the content of the record (i.e. fields). The fields offset, when defined in this context will be relative to the position immediately after the Record Start Identifier. This is equivalent to the Block End Identifier, but for each record occurrence. After the record separator (if defined) starts the next record occurrence. Being a separator, the last record occurrence may not have such a separator at its end since it does not have to separate itself from the next record occurrence; depending whether or not the record block end is identifiable by other means. Number of occurrences of records within the record block. The minimum is one if record occurrences need to be defined. However, for example, if the record block and its record occurrences lengths are fixed, the number of occurrences may not need to be specified in order to correctly locate all components of the record block and its records. Similar to the SubSMI ‘Length’ described in section 4.1.4.1, but now applies to mark the length of the full record block. Using a Block End Identifier indicates a dynamic block length. Hence, the length should be zero in this case. Enabled both when Wizard is on or off. When Wizard is on, it launches the Record Wizard (see section 0), while when Wizard is off it adds a blank new record in the records list. Right clicking over the existing records list also provides a New Record option. Also refer to section 0 for the list of ways to define a record block. Note that record blocks can only be defined in the free text portion of a message. This function is available via buttons and/or popup menus. This function is available when right clicking over the existing records list. It allows creating a copy of the selected record. All record data is copied into a new list entry, but the record name is made unique with the addition of a digit (e.g. duplicating a record named ‘New Record’ will insert an entry named ‘New Record_1’ with the same data as the original record). This function can be used to rapidly define similar records by duplicating an existing one and, manually make small changes. This function is available via buttons and/or popup menus.

61

ASP Administrator Guide Version 6.9a

Data Delete Record

Highlighting

Description When right clicking with the mouse over the message guide text box while in add or modify edit mode, a popup menu may appear, depending where the cursor is in the box. Whenever the cursor is over a highlighted series of characters (i.e. record component), then the ‘Delete Record’ function is displayed. This is one way to delete a record block. The other is to select a record block in the existing records list and right click (still in add or modify edit mode). The ‘Delete Record’ function is available and acts the same (removes record from the list and refreshes highlighting in message guide). When left clicking in the text box over a highlighted piece of record block, the complete block gets selected. Then right clicking the mouse will show the ‘Delete Record’ function, which of course will apply on the currently selected record block. If there is a manually made selection that covers the record block but also goes beyond (in non-highlighted areas), then the ‘Delete Record’ function will not be available; it requires the exact record block selection to be available. This function is available via buttons and/or popup menus. If highlighting does not display as expected, closely verify the definition of each and every data element of the record definition. Go into Manual Mode, play around with some values and refresh to see the impact. Some data element combinations may simply make no sense, leading into a non-sense highlighting. Typically, if the end of a record (or field) cannot be determined from the specified data, it will most probably extend data highlighting until the end of the Message Guide (or until the end of the Record Block for fields within a Record Block). This function is available via buttons and/or popup menus. Table 4-7 Template Records Panel

The record's block delimiter, start identifier, and end identifier, as well as the record start identifier and separator support escaped characters for non-printable characters (decimal codes 0 to 31) like \r\n for carriage return and line feed.

62

ASP Administrator Guide Version 6.9a

4.1.4.3.

Fields Panel

Figure 4.10 presented below illustrates the template Fields panel and will be referred to in this section.

Figure 4.10: Templates – Downlink From Aircraft Fields Panel

The following describes the data components of the Fields panel, as well as the SubSMIs & Fields localization definition, which behave very similarly (differences are highlighted). Data Message Guide (text)

Description Same content as the General panel message guide, but with two differences: (1) cannot be changed, cleared or edited from this panel, (2) highlighting is for fields only. Fields are highlighted as follows: • Start and end identifiers, as well as delimiters (if any) are highlighted in red. • Field data is highlighted in magenta. The currently selected field in the fields list (described below) is marked as bold and underlined (i.e. the field data and identifiers/delimiters). Only the currently selected field has its identifiers/delimiters (if any) displayed in red. Otherwise, only the field data is highlighted in magenta, without bold and underline.

63

ASP Administrator Guide Version 6.9a

Data Existing Fields (list)

Field Name (text)

Field Type (list)

Aircraft Long Reg Aircraft Short Reg Flight Identifier Field Types

Description List of existing field names and their type. Not editable directly, however used to browse through fields and display specific field data and highlighting. The content of the list is updated as soon as the Field Name, Field Type, or containing Record properties have been edited. An item is inserted in the list in one of two ways. Defaults to ‘New Field’ when adding a new one. Duplicate names are not authorized and automatically prevented. In other words, if a user creates a field with name “New Field” and this name already exists, it will automatically change the name to “New Field_1”, and so on. The Field Name text box cannot be empty. If emptied by the user, it will be filled with “New Field” (or “New Field _1” …). Also, field names starting with the character “@” are not allowed as this is a reserved character for predefined fields in models. List of all field types defined in the system and applying to the type of messages (downlink, uplink, or ground), with the ‘Alphanumerical’ field type as default. The selected field type lets the system perform specific processing associated to the field type, and not all field types apply to all message types (e.g. “Aircraft Long Reg” (AN), “Flight Identifier” (FI) only apply to Uplink, Air-to-air Uplink only applies to Downlink and Dynamic Distribution applies to both Downlink and Ground, and so on). A few field types are specially prefixed (e.g. "PDC -", "AFDAS –", "FP –") and these are used and listed only in the context of the message category indicated by the prefix. For uplink messages from external users of format Type B only (i.e. non-AEEC 620), either an “Aircraft Long Reg” (aircraft registration, tail number or AN), “Aircraft Short Reg” (aircraft nose number) or a “Flight Identifier” (FI) is required to be able to proceed and send the outgoing uplink to the desired aircraft. These fields are defined as any other fields using the “Aircraft Long Reg”, “Aircraft Short Reg”, or “Flight Identifier” field type in the Fields panel. For the AEEC 620 format, the fields are not required, as the system knows where to find them in the TEI line of the AEEC 620 header. Note that if an incoming uplink is received that has only a “Flight Identifier” defined (without an “Aircraft Long Reg” or “Aircraft Short Reg”), the system handles that FI following the rules listed below (the FI value is made up of the IATA or ICAO airline code, the flight number and an optional suffix considered only for Pre-Departure Clearance uplinks, e.g. BLR700702, BLR = ICAO airline code, 7007 = flight number, 02 = suffix): • For its internal use, the system first parses the FI based on the IATA or ICAO airline code (see DefaultOperator value in AircomSrv.ini) and always converts it to its IATA equivalent. • If the flight number is less than 4 characters, the system pads the missing characters (see FIUplinkPadding value in AircomSrv.ini). • If no “Aircraft Long Reg” or “Aircraft Short Reg”, is specified in the received incoming uplink (and the FIOnlyUplinkSupport value is set to ‘Y’ in AircomSrv.ini) the system attempts to find the associated aircraft by browsing its tracking data. If a match is found, the uplink is sent normally. If a match cannot be found, the uplink remains pending until a downlink is received with the matching FI in it and then it is sent. • If the uplink cannot be sent before the validity period is reached, the uplink is dropped and an appropriate confirmation message is sent to the originator user, as required.

64

ASP Administrator Guide Version 6.9a

Data Value Properties button – Numeric field Range Validation

Description When a field of a type numerical is selected, the button opens the Value Properties dialog with range validation settings, initialized with the proper existing values (see Figure 4.11). Applies to numeric fields only (i.e. any field type considered numeric, like Numeric, Fuel, Altitude). Four values define the range checking that may be performed. The system will report out of range values as per the limits specified here. The lowest value defines the limit below which the value is considered in error on the low side. Above this value up to the second value is considered a warning on the low side. Then between value 2 and value 3 is the normal range. Above value 3 and below value 4 (highest value) is the warning range on the high side. Finally, above value 4 is the error range on the high side.

Value Properties button – Alphanumeric field Lookup Table (list)

Note that a validation is performed when clicking OK making sure that upperbound values are actually higher than lower-bound values (i.e. 10 > 5 > 2.5 > 0) and that valid numeric values are entered. If this is not the case a dialog advises the user to correct the situation. The Clear function resets all values to 0, meaning no validation to perform, and Cancel ignores any changes. When a field of a type allowing lookup tables is selected, the button opens the Value Properties dialog with lookup table settings, initialized with the proper existing values (see Figure 4.12). A lookup table at the template level can be specified only for field types alphanumeric (or custom fields alphanumeric), origin airport, destination airport, and true/false type of fields (like APU status, and engine x status). In the dialog, the dropdown list presents all lookup tables defined in the system via the Value Lookup Tables window. When a lookup table is defined for a field, it means that when finding the field value, it will be searched among the corresponding lookup table items for a match. Basically, when a lookup table is specified, if a match is found for that field, the ‘converted’ value is the one displayed in the Message Viewer instead of the original field value. The first checkbox “Use to convert values before storing it” is used for field types that trigger special processing and that end up being stored for tracking purposes. With the box unchecked, the original value is stored for processing. With the box checked, the value is converted and then stored, which means the processing is done using the converted value. The check box is grayed out for fields that allow using lookup tables but that do not support special processing (like pure alphanumerical fields). Note that alphanumerical custom fields (refer to section 7.6, Custom Fields Window) do get stored and thus allow pre-conversion. Also, if the selected lookup table is a values list (see section 7.4.2, Value Lookup Table Window - Data Description), this checkbox is not available and grayed out. Regarding fields used in models, it is always the original value that is used to format models. In order to convert the value in models, it is the model’s level lookup table for that field that must be set. Lookup tables specified at the template level have no incidence on model formatting.

65

ASP Administrator Guide Version 6.9a

Data

Data Formats (Format button & list)

Address by (list)

Description The second checkbox “Use value list as additional criteria in distribution” makes the current field visible in the list of additional criteria in the distribution window (available for downlink and ground messages). This allows filtering distribution of the message based on the field’s value (see section 4.2.2, Downlink Templates Distribution Specifics, “Value for:” description). The button brings up the Data Format dialog presented below (see Figure 4.13), initialized with the proper existing format. Formats can be specified (i.e. visible) only for field types of data types date & time, latitude and longitude and the format list appears immediately below the field type when applicable. Address by can be specified (i.e. visible) only for field type Dynamic Distribution and Air-to-air Uplink and the list appears immediately below the field type when applicable. For these field types, the field holds some addressing data and the message that contains such a field should be "dynamically" redistributed to these addresses. To allow for the provision of many addresses of the same type, the field can easily be planned to be located within a record with a certain number of occurrences or with valid record delimiters. In the end, for example a pilot may enter a certain address in a downlink message to make sure it gets routed to that address. This distribution means is handled in conjunction with the Downlink Distribution lists to ensure unique delivery to end users. Air-to-air Uplink is used to redirect the downlink message as an uplink to the aircraft. It uses the predefined uplink template "Air-Air Dynamic Routing" with the model associated to the addressed aircraft to format the message as a valid uplink. Dynamic Distribution is used to forward the message as-is to various ground users. Address by values for Dynamic Distribution (none) Default value that needs to be replaced by a useful value. Local User A local user username to forward the message to that user’s mailbox. Email An email address. Lotus Notes A Lotus Notes address. Type B A Type B address; 7 characters. Now that local users and groups can have a Type B address, messages can be dynamically directed to these user types using Type B dynamic distribution. Address by values for Air-to-air Uplink (none) Default value that needs to be replaced by a useful value. Aircraft Long Reg Aircraft registration or tail number. Aircraft Short Reg Aircraft's nose number.

66

ASP Administrator Guide Version 6.9a

Data

Units

Mandatory (option)

Record (list)

Location Start Identifier (text)

Description Flight Identifier

Flight Identifier (FI) - if no aircraft is currently flying that flight, the message is queued and it will show as an FI-only entry in the aircraft tracking. Call Sign Call sign - requires the aircraft to be currently tracked such that the call sign can be matched to the proper aircraft. Units can be specified only for field type Altitude, Fuel, and Speed and the list appears immediately below the field type when applicable. A field of a type that does not support data formats, dynamic distribution and units will show a disabled units list by default. Units are used to tell the system in which units are expressed values extracted from a message. There is also a multiplier value next to the unit list, which is used for example to represent altitude in 100 feet: unit is feet and multiplier is 100. Within the system (like aircraft tracking), altitude is displayed in feet, while fuel display units can be configured via system parameters (see section 7.1.2.1, General Tab). Speed is not currently displayed; it is however fed to the FE interface. Option specifying whether the field is mandatory or not. A mandatory field requires the field value to be found in messages matching the template; otherwise an event is logged about it and the “Downlink Template Error” event handling is triggered, if configured. No error will be raised if the field is not mandatory. In any case, the value of a missing field is left blank when used in output models. List of all records defined for the current template. The selected item in the list represents the record in which the current field is located (i.e. repeated in each occurrence of the record). By default, the record selection for a new field is ‘(none)’. The list of records is updated as soon as a change occurs in the record panel. When a field is defined within a record, the parameters like identifiers, offset, etc. are searched for and defined relative to the start of each record occurrence of the container record. Indicates where to look for the field, i.e. in the free text area of the message or in the TEI line of the AEEC 620 message header. Indicates the characters to look for within a message to find the field data. This is used when the field is identified by a prefix and is not at a fixed position within the message. For example, “/TXI” could be a start identifier after which data will start. This indicates that we must search for “/TXI” in the message to identify the field. It is definitely preferable that this identifier be unique, else unexpected interpretation may result in certain circumstances.

67

ASP Administrator Guide Version 6.9a

Data End Identifiers (text) & Until End (true/false)

Description Same as for the “start identifier”, but this time it marks the end of field data. This is used when field data has dynamic length. Once found in the message, it is interpreted that the field data ends just before the “end identifier”. For SubSMIs, only one “end identifier” is supported, but for fields, up to three (3) different “end identifiers” can be specified in conjunction with the “Until End” option.

Start offset (numeric)

End offset (numeric)

Length (numeric)

Delimiter (text)

Occurrence (numeric)

New Field (Field button)

When parsing a message to identify a field with multiple “end identifiers”, the first valid “end identifier” found in the message starting from the field’s “start identifier” is the one used (i.e. the left-most identifier found in the message). Ultimately, if none of the “end identifiers” are specified or found, but the “Until End” option is checked, the field ends at the end of the message or at the end of the record if the field is located within a record.. If none of the options are set and that no other data such as the field length allows determining where the field ends, the warning “Cannot find end of field” is raised when trying to display the field. Indicates the number of characters to be skipped in order to find the field data. If there is no start identifier defined, then the offset indicates an offset from the beginning of the free text. If there is an identifier field, then the offset will be taken from the end of the start identifier. This field is calculated when using wizards. It allows specifying a field that would start at a fixed position within a message. Indicates the number of characters to be skipped from the end of the field in order to find where the field data ends. If there is no end identifier defined, then the offset indicates an offset from the end of the free text. If there is an end identifier field, then the offset will be taken from the beginning end of the end identifier. It allows specifying a field and skipping some end characters like a CRC. Indicates the length of the field data. It will be set to zero for dynamic length fields (those requiring an end identifier). Else, it specifies the data length from the offset to the end of data. A specific sequence of characters, up to 50, that locates the field, similarly to the start identifier, but with the concept of occurrence. The occurrence must be different from 0 when using the delimiter to locate a field, else nothing will be found. Number of occurrences of the delimiter character to skip before finding the field data. For example, an occurrence set to 5 means the field data starts after the fifth delimiter character has been found in the message free text (the offset is also considered in this case). When the Wizard option is on it launches the Field Wizard (see section 4.1.5.3) to define a new field in the template. When the Wizard is off, it adds a new blank field in the fields list to let the user define it manually. Refer to Table 4-9: Templates – Field Localization Methods for the list of methods to define a field (same as for the SubSMI). Note that fields can either be defined in the TEI line or in the free text portion of a message, but the definition methods vary depending on the location.

68

ASP Administrator Guide Version 6.9a

Data Duplicate Field

Description This function is available when right clicking over the existing fields list. It allows creating a copy of the selected field. All field data is copied into a new list entry, but the field name is made unique with the addition of a digit (e.g. duplicating a field named ‘New Field’ will insert an entry named ‘New Field_1’ with the same data as the original field). This function can be used to rapidly define similar fields by duplicating an existing one and, manually make small changes. Also, to convert or display the same field differently in a model, the user must define a different field (with a different name) at the template level using the ‘Duplicate Field’ function2. Delete Field When right clicking with the mouse over the message guide text box while in add or modify edit mode, a popup menu may appear, depending where the cursor is in the box. Whenever the cursor is over a highlighted series of characters (i.e. field component), then the ‘Delete Field’ function is displayed. This is one way to delete a field. The other is to select a field in the existing fields list and right click (still in add or modify edit mode). The ‘Delete Field’ function is available and acts the same (removes field from the list and refreshes highlighting in message guide). When left clicking in the text box over a highlighted piece of field, the complete field gets selected. Then right clicking the mouse shows the ‘Delete Field’ function, which of course applies on the currently selected field. If there is a manually made selection that covers the field but also goes beyond (in non-highlighted areas), then the ‘Delete Field’ function will not be available; it requires the exact field selection to be available3. Field Name Changes When field names are changed, it may have an impact on the models of the template, if it includes the affected field. In this case, the system transparently handles the coherence between the template field and all template models as follows:  If a field is deleted and was used in some model, these will be updated to remove the field from the model text and from the model list of fields (see next section for details about models).  If a field is renamed and was used in some model, these will be updated to reflect the change in the model text. Table 4-8 Templates – Data components of the Fields panel

The field's delimiter, start identifier, and end identifier, as well as the SubSMI values support escaped characters for non-printable characters (decimal codes 0 to 31) like \r\n for carriage return and line feed. Note that when a field is located in the TEI line, it is assumed that the field can be located in one of two ways only: 1) a pair of start and end identifiers or 2) a start identifier and a fixed data length.

2

Refer to section 4.1.4.5 for more details on Models definition. The exact selection is required because overlapping fields may be defined and to make sure to delete the desired field, the exact field must be selected prior to deletion. Note that if two fields exactly overlap (same start and same end position), then the first one found gets deleted and highlighting stays for the instance left. 3

69

ASP Administrator Guide Version 6.9a

In the free text, there are six ways to locate a field: Data Combinations of start and end identifiers (including until end4)

Description length = 0 offset from start identifier delimiter empty occurrence = 0 Start identifier and fixed data length end identifiers empty (until end not checked) offset from start identifier delimiter empty occurrence = 0 Fixed data position and end identifiers start identifier empty (including until end) length = 0 offset from start of free text delimiter empty occurrence = 0 Fixed data position and length start and end identifiers empty (until end not checked) offset from start of free text delimiter empty occurrence = 0 Delimiter and end identifiers (including start identifier empty until end) length = 0 occurrence of delimiter > 0 offset from delimiter occurrence Delimiter and fixed data length start and end identifiers empty (until end not checked) occurrence of delimiter > 0 offset from delimiter occurrence Table 4-9: Templates – Field Localization Methods

The below presents the Value Properties dialog used to configure range validation for numeric fields or lookup tables for alphanumeric fields:

Figure 4.11 Range Validation Value Properties

SubSMI fields, as opposed to regular fields, do not support multiple end identifiers and the “until end” of message option. 4

70

ASP Administrator Guide Version 6.9a

Figure 4.12 Lookup Table Value Properties

The below example presents the Data Format dialog for a date/time field type:

Figure 4.13: Templates – Data Format

Many characters can be used to define a format, and each differs based on the context. Rather than describing all possible characters here, the user is advised to use the ‘Help’ menu that lists all possible formatting characters in the appropriate context. Complete data formats strings may therefore be composed by adding formatting elements from the ‘Help’ menu, or typed by hand using the available formatting elements. Only the date/time data formats display a result example; other data formats do not. Here is how the functions behave in the template field context: Function OK

Cancel Clear

Description Confirms the format, closes the window and when returning to the Fields panel, it will try to match an existing format. If it does, it will select the existing format; otherwise it creates a new format in the list and selects it. Even though an existing format was being modified, a new one will be created and the original one will stay. The system purges unused formats at the same time it performs mailbox and log purges. However, note that some formats are predefined in the system and they will never get purged (e.g. HHNN); only those created by users get purged. Only closes the window without any change. Leaves the window opened and clears the format text box. Table 4-10: Data Format Functions

71

ASP Administrator Guide Version 6.9a

4.1.4.4.

Advanced Panel

Figure 4.14 Templates – Downlink Advanced Options

The following describes advanced data available for downlink templates. Data Override default message type

Description The default message type displayed in logs and users’ mailbox is showing the template name and is configured as “{@TEMPLATE NAME}”. Checking this option allows overriding that default and specifying what the template manager wants to. Note that the default message type does not contain anymore the model name as it used to, but it may be added easily if still desired.

Message type

This advanced option is available for all template types: downlink, uplink, and ground. The message type displayed for messages matching a template can now be configured and it can include predefined field as well as custom field values. The user may type text to show in the message type and valid fields using the naming “{@FIELD NAME}”. For the complete list of fields allowed and for easier message type definition, use the Edit button (see below). A useful way to use this feature, among others, is to specify flight related information in the message type, such as the aircraft, flight number, departure / arrival airport codes… The message type is displayed in the users’ mailboxes especially in the message header area. Therefore, selecting a useful message type for templates makes the message reading much more meaningful in the users’ mailboxes, much like an email subject.

72

ASP Administrator Guide Version 6.9a

Data

Edit (Message type)

Description This advanced option is available for all template types: downlink, uplink, and ground. Opens the "Message Type Editor" which allows the "Message type" to be configured using most predefined fields and custom fields through drag and drop.

To the right of the dialog, choose between predefined and custom fields, then pick one from the list and drag and drop it to the leftmost text area. Fields show in blue when they are valid. The user may also type in a field or any other text directly in the text area. A sample result is displayed at the bottom, resolving fields with sample values. Right-clicking in the text area offers a few options such as copy & paste, but also Edit format when right-clicking over a field that allows a format, such as date & time fields. Edit format offers a simple dialog to specify the related format.

Any inserted field will be replaced by the appropriate value when the message type is resolved. If a field doesn't have a value when resolved, the value used is a single dash "-" character and not blank to ensure the message type doesn't end up empty.

73

ASP Administrator Guide Version 6.9a

Data Trim trailing CR + LF

Description When checked, tells the Server to trim any trailing carriage return & line feed pairs at the end of incoming messages, i.e. before any reformatting occurs. If a model is later used to reformat the message and that the model adds trailing CR + LF, these will not get trimmed. This option is grayed out when not applicable like for templates of source from local users. This advanced option is available for all template types: downlink, uplink, and ground. Allow distribution of multiple When checked, it enables a special button in the distribution models to the same user window allowing adding more than one distribution rule for this template and for a single user recipient using different models. XML message type & sub-type These values are used as attributes in the element when this template is distributed to users configured with XML output. Refer to Appendix A for details about the XML schema used with the AIRCOM® ServerPlatform. Hold & Wait Options Refer to section 9.1.7 for details. Start hold period for uplinks When checked, indicates that messages matching the template, when received, start an uplinks hold period for the aircraft that sent the message. Start and stop are exclusive for a single template, i.e. when start is checked, stop hold is disabled. Hold uplink priority The uplinks hold period holds messages of this priority and lower. Hold for Hold uplinks for this number of minutes, starting with the reception of a message matching the template. Hold until flight stage Hold uplink starting with the reception of a message matching the template until the flight stage is reached, and optionally wait a number of minutes after the stage has been reached. In case the flight stage is never reached (at least never reported to the AIRCOM® ServerPlatform), a maximum number of minutes timeout has to be specified (defaults to 60 minutes). Stop hold period When checked, indicates that messages matching the template, when received, stop any currently active uplinks hold period for the aircraft that sent the message. Start and stop are exclusive for a single template, i.e. when stop is checked, start hold is disabled. Send all waiting uplinks When checked, indicates that messages matching the template, when received, send all uplink messages that are in waiting state for the aircraft that sent the message. Refer to uplink templates advanced options for details on waiting uplink messages (Table 4-12). FE Interface – Send applicable When checked, indicates that receiving a message matching the data template sends any data contained in the message FE Interface – Generate FE event When checked, indicates that receiving a message matching the template generates the event specified as “Event identifier” and sends it to FE. You can then configure FE to take different actions (add to event list, voice notification, zoom, etc.) when this event is received. FE Interface – Event identifier Event number sent to FE when receiving a message matching the template. FE should provide you with the range of events that your system is allowed to generate. Table 4-11 Templates – Downlink Advanced Options

74

ASP Administrator Guide Version 6.9a

Figure 4.15 Templates – Uplink Advanced Options Data Wait Options Panel Send uplink

Override maximum wait time (on-hold timeout)

Description Determines when the uplink is queued for sending to the aircraft and if a delay must be added to the wait. The possible options are: - On reception/creation: Uplink queued right after being received from an external user or created by a local user. - On flight stage: Uplink queued when the selected flight stage is reached but not after. - On or after flight stage: Uplink queued when the selected flight stage is reached or is passed. - When triggered by the Sequencer (external user only): Uplink queued only after being triggered by the Sequencer with a "send uplink" action. The uplink must already have been received and be waiting for the "send uplink" action to succeed. By default, the on-hold timeout (in minutes) from the System Parameters applies (can be seen as grayed out value when the option is unchecked). Checking the option allows overriding the default value for the current message(s). The on-hold timeout tells the system how long an uplink can stay in the “UP: On-Hold” status before being reactivated. If the on-hold timeout expires, the system will process it as an expired message, and send the appropriate notification back to the originating user.

75

ASP Administrator Guide Version 6.9a

Data Override validity

Description By default, the validity time (in minutes) from the System Parameters applies (can be seen as grayed out value when the option is unchecked). Checking the option allows overriding the default value for the current message(s).

The validity time tells the system for how long an uplink is considered valid and should be retried if an aircraft is unreachable for a long period of time. If the validity time is exceeded and the uplink has not been successfully delivered, the system considers the message as expired and stops trying sending it. An appropriate notification will be sent back to the originating user if its configuration requires so. IMPORTANT NOTE: The message validity count down only starts when an uplink message is active and ready to be sent to the aircraft (i.e. is not in the “UP: On-Hold” status). Uplink Routing Options Panel Use DSP If different than "(any)", this setting forces the use of the selected DSP –and only that DSP– to transmit the uplink, therefore bypassing the normal routing logic. Use this setting only if you know that the uplink can be delivered only over the selected DSP (like Data3 over QXS) but leave to "(any)" for all other uplinks. Table 4-12 Templates – Uplink Advanced Options

Figure 4.16 Templates – Ground Advanced Options

Ground template advanced options are the same as the "General" and " FE Interface" options described for downlink templates (see section 0,

76

ASP Administrator Guide Version 6.9a

Advanced Panel).

4.1.4.5.

Templates From Local User

Templates “From Local User” provides the framework to write New Uplink and New Ground messages. Therefore, this category of template is really focusing on the Fields panel to provide the list of fields for which the user will have to enter values when writing its messages. No Template Identifiers are requested and records do not make sense in this context. Additionally, the fields play a different role than for other template sources: they are user input fields. For this reason, there are only two possible field types: alphanumeric and numeric, the data formats act as data entry input masks, and the lookup table is used to browse for a value to insert in the message being written. Note that the data format and lookup table apply only to the alphanumeric field type, while the length property (present only in From Local User templates) applies to both field types, as long as there is no data format or lookup table specified. The length specifies the number of characters a user may enter, and zero means no limit. It is important to understand the role played by the lookup table selection in the case of templates from local users. This lookup table is used as a value list in the New Message window allowing the user to pick a value from a predefined list. Thus, it does not matter if the selected lookup table is marked as ‘value list’ or not, in any case, only its ‘Value’ is used and listed in the New Message window. To have the user input value converted in the generated message after preview one must specify a lookup table for the desired field in the model used to do the reformatting. Note that to perform value conversion in the formatted message, it does not need to be a value list field in the template (and thus in the New Message field list); it only needs to be an alphanumerical field. The field list ‘Order’ column specifies the order in which the fields will appear in the New Message window Edit panel - the order value of one shows up first. The fields’ order is managed using the ‘Move Up’ and ‘Move Down’ buttons just below the field list. Added fields are appended – they take the largest order value, and deleting a field automatically reorders the remaining fields. Note that if the field list is sorted by its ‘Order’ column, changing the fields’ order automatically sorts the list to reflect the change, while if the list is not sorted by ‘Order’, than the moved field stays in place and only its order value is modified.

77

ASP Administrator Guide Version 6.9a

Figure 4.17: Templates – Uplink From Local User Fields Panel

4.1.5.

Template Models

The tree displayed on the left side of the window (Figure 4.18) is the key navigation control to scroll through the models. Models are always children of a template. A model allows presenting a raw message from a certain source into a readable format for the destination; this can be as simple as only forcing a maximum line length to a deep reformatting of the information. It includes both predefined fields and fields coming from the parent template inserted as variables (delimited by the ‘{ }’ characters) in the model text. Additionally, each field from the parent template has a set of parameters allowing a certain level of formatting and conversion. When the model is specified via the appropriate Distribution window for a user, a user group, or an aircraft (see section 4.2), the model serves to generate a specific reformatted message based on the incoming message that matched the model’s parent template. All model variables are then replaced by actual values from the message and formatting and conversions rules are processed.

78

ASP Administrator Guide Version 6.9a

Figure 4.18: Templates – Downlink From Aircraft Model Panel

The following describes the data components of the model panel. Data Model Name (text)

Default (option)

To EFB XML Model Text (text)

Description Name of the model, defaulting to ‘New Model’ when adding a new one. Duplicate names are not authorized within the same template scope. For models of different templates, having identical names is not a problem at all. When checked, this option makes the model the default one among all models of the parent template. When the first model of a template is created, the default property is set to true automatically; otherwise, the default is set to false. The option is useful to make the model being pre-selected when configuring distribution for the parent template (see section 4.2). Note that the default model of a template is displayed with a red model icon in the tree. Convert to an EFB compliant XML. EFB model guides must be used. Model text being built. This will be the reformatted message once all variables will have been replaced by their values and that all formatting rules such as alignment or padding will have been applied. The model text content can be copied any time using the keyboard shortcut Ctrl-V while the model text is selected.

79

ASP Administrator Guide Version 6.9a

Data Non-Predefined Fields (list)

Field Type (label) Alignment (list)

Field Length (numeric) Decimal Settings (numeric & text)

Value Conversion (Operator/Operand) Toggle 0/1 Values (option) Lookup Table (list)

Character Conversion (list)

Description List of all fields coming from the model’s parent template (red in the model text). A specific field may be inserted many times in the model text, but it appears only once in this list. The only way to insert the same field twice with different formatting parameters would be to go to the template, create a new field identical to the previous one (will be forced to have a different name, but could be for example FIELD and FIELD_1; see section 0, Duplicate Item popup menu), and then come back to the model and insert this new field. Then define the formatting parameters as desired. All displayed formatting parameters apply to the selected field in this list. Displays the field type as per the corresponding DT field’s field type for the selected model field. Applies to both field formats - numeric and alphanumeric. Choices are ‘Left’ and ‘Right’ alignment. This is combined with ‘Field Length’ for alphanumeric fields and with ‘Decimal Settings’ for numeric fields, in order to properly align data from the field. Applies to alphanumeric fields only. It represents the maximum number of characters displayed for the value of the selected field. The default value is 0, meaning no padding performed. Applies to numeric fields only. Composed of three elements  # digits: Maximum number of digits before the separator to be displayed. The default value is 0.  Separator: Either comma ‘,’ or dot ‘.’ to mark the decimals.  # decimals: Maximum number of decimals after the separator. The default value is 0. Apply to numeric fields only. Used in pair to define a simple linear conversion function that will be applied to the raw field value. The result of the equation will be displayed. Allows inverting On/Off type of values, i.e. for example if 1 means false and 0 means true, it can be inverted to be 1 = True and 0 = False Applies to alphanumeric fields only. Even though a lookup table has been defined at the template field level, it has no impact on model formatting. If no lookup table is identified for a model field, the raw or original value is displayed in the reformatted message, while if a lookup is specified, the ‘convert to’ value is used. Note that lookup tables marked as ‘value list’ cannot be used for conversion purposes. Special note about templates from local user’s lookup tables: At the model level there is no behavior difference, that is the model field lookup table, if specified, is still used to convert the user input value to the lookup ‘convert to’ value. Again, this applies no matter if the template field had or not a lookup table configured at the template level (refer to document [S4a], New Message Window section, message fields list for more details). A list of character replacement mapping can be defined for any template field in the model. Mapping is defined on a one-to-one character basis, i.e. one character at a time. For example, to replace a carriage return by a space (ASCII 032), replace by . Note that the character is not allowed. The maximum number of character conversions allowed for one particular field is 32 (i.e. max. 32 rows in the list). See section 4.1.5.2 for more details on Character Conversion. Table 4-13: Templates – Model Data Description

80

ASP Administrator Guide Version 6.9a

The following describes the functions of the model panel, available via a dropdown and a list of items to the left of the model text area. Component Insertion (dropdown & list): A dropdown list composed of the types of items that can be inserted in the current model. When a dropdown item is selected, the list located just below is filled with the corresponding items to insert. Selecting an item in the list and clicking the “+” button (or double-clicking on an item) inserts that specific component into the model text box at the current cursor position5. If the insertion point is over a protected region (i.e. colored area, meaning over an existing field), the insertion is blocked and a dialog tells the user to choose another insertion point. Note that to the right of the list, there is a splitter to resize the list area and also a hide/show bar allowing collapsing the insertion zone to maximize the model text portion. The following describes each possible item type to insert that may be available in the dropdown list: Data Fields

Record blocks

Record fields

Predefined fields

Description Displays the list of fields coming from the parent template that do not belong to a record block (one option per field). Displays (empty) grayed out if no such fields exist. Inserts {FIELDNAME} in the model text, ‘{’ being the opening field identifier and ‘}’ being the closing field identifier. Note that the ‘{ }’ delimited fields are red. Displays the list of record blocks coming from the parent template. Displays (empty) grayed out if no such blocks exist. Inserts ‘repeat’ or ‘array’ characters (‘{}’) with all fields defined in a record of that block (e.g. {}) (see Repeat characters below). Displays the list of record fields coming from the parent template and belonging to any record block (the block they belong to is identified between parentheses). Displays (empty) grayed out if no such fields exist. Inserts {FIELDNAME} in the model text, ‘{ }’ being the field identifier characters. Note that no repeat characters are inserted, i.e. the record will not be repeated if not inserted between existing ‘{}’ characters (see Repeat characters below). Displays a list of preset fields like “Aircraft Long Reg”, “Flight Identifer”, DTG, etc. that will be inserted into the model text, but in blue and starting with the character “@” (e.g. ‘{@DTG}’). The blue color and starting character indicate they are predefined fields. Such predefined fields will be replaced by a specific value (e.g. the aircraft number) that the system knows where to get within the message being reformatted. Such fields do not offer any special formatting parameters; they are replaced as is, except for DTG discussed in section 4.1.5.1.

5

When a selection is made, the insertion point (cursor position) is considered to be the position where the selection starts. 81

ASP Administrator Guide Version 6.9a

Data Custom fields

EFB model guides

ASCII character

Other

Description This item appears only if custom fields have been defined – refer to section 7.6, Custom Fields Window. It lists the custom fields available in the system, and once added to the model, the tracked value for that field and for the appropriate aircraft / flight will be inserted. If no value exists for that field, it will translate into an empty entry in the formatted output. Custom fields can be inserted in models of any type of template and they behave very similarly to predefined fields (prefixed the character “@” and blue colored). Displays the list of Electronic Flight Bag (EFB) model guides to be used when the model setting “To EFB XML” is set. It represents all the XML schemas supported by the system, to help build a model with the proper fields for EFB processing. Display a list of the ASCII characters allowing inserting any ASCII character from 1 to 127, including non-printable characters. Non-printable characters are inserted in their hexadecimal format between brackets, such as “{@x0D}” for carriage return. In model text, the carriage return (CR) and line feed (LF) characters are inserted individually. Displays up to 4 possible options: Array Zone, ASCII Character, AEEC 620 Template, and Type B Template. Array Zone will insert a pair of repeat characters separated by 2 spaces (‘{}’). Used to create a custom repeating area. AEEC 620 model guide will insert an AEEC 620 message template from the QU line to the free text area, with typical variables (‘{ }’), used as a start to produce an AEEC 620-like model. Type B model guide will insert a Type B message template from the QU line to the free text area, with typical variables (‘{ }’), used as a start to produce a Type B-like model (does not apply to uplinks). M3L model guide will insert a sample M3L AEEC 620 uplink with a valid 3L header at the start of the free text (available only if encryption is licensed and only in uplink models). When applicable, the guides slightly differ according to the source of the template. For example, a local user model would include the predefined field {@USER TEXT} while an external uplink model would include the predefined field {@FREETEXT QUOTE}.

82

ASP Administrator Guide Version 6.9a

Data Repeat characters (‘{}’)

Description They are green and everything between a pair of such characters is repeated sequentially, be it a record field, a stand-alone field or fixed, keyboard entered text. However, the number of repetitions is established by the element between the ‘{}’ that has the highest occurrence. Hence, except record fields, everything else has an occurrence value of 1. If mixed with a record field from a record with occurrence 2 and another record field (from a different record) with occurrence 3, then the whole set will be repeated 3 times. For example: Movmnt Time Fuel {} Where ‘{Movmnt}’, ‘{Time}’ and ‘{FOB}’ are fields defined within a record with a variable number of occurrences. As an example, a message received with four occurrences of that record would be reformatted like this: Movmnt Time Fuel OUT 0017 0288 OFF 0033 0282 ON 0335 0083 IN 0338 0080 Table 4-14: Templates – Model Insert Toolbar

Any other formatting text is entered using the keyboard. Keyboard entered text can be deleted normally using the Backspace/DEL keys. However, the c olored components inserted from the toolbar need to be removed using the ‘Delete Item’ popup menu (described below). Delete Field: When right clicking with the mouse over the model text box while in add or modify edit mode, two different popup menus may appear, depending where the cursor is in the box. In general, the Save, Cancel and Clear (see below) functions will be the only available menu options. However, whenever the cursor is over a highlighted series of characters (i.e. model variable, anywhere over a colored area), then the ‘Delete Field’ function is added. This is one way to delete one instance of model variable (‘ {…}’); the one selected. The other is to select a field from the list of ‘Non-Predefined Fields in Model’ and right click (still in add or modify edit mode). The ‘Delete Field’ function is also available from there and this time will remove all instances of the field variables highlighted in the model text. When the list is empty, the ‘Delete Field’ function is disabled. Other components present in the text box that must be deleted only from right clicking over the text box are: predefined variables (delimited by ‘ {@…}’, colored in blue) and arrays (delimited by ‘{}’, colored in green). For arrays, the user must click over one of the delimiters (green ‘{}’) to mark the whole array. When left clicking in the text box over a highlighted (colored) piece of a variable (‘ {…}’, ‘{}’), the complete component gets selected. Then right clicking the mouse shows the

83

ASP Administrator Guide Version 6.9a

‘Delete Field’ function, which of course applies on the currently selected component. Moreover, as long as the cursor is over some highlighting, the function will still show and work the same. On the other hand, if there is a manually made selection that covers the component but also goes beyond (in non-highlighted areas) then the ‘Delete Field’ function is not available. Clear Model Text: Allows clearing, after user confirmation, the complete model text and all the fields listed in the list of ‘Non-Predefined Fields in Model’. When the Model Text is empty, the ‘Clear’ function is not available.

4.1.5.1.

Formatting Datetime Fields

When inserting predefined or custom fields that are of the underlying type “datetime” into the model text (e.g. {@DTG}, {@ETA}, {@OFF TIME}, …) the fields’ output format can be determined. By default, any datetime field will use the “HHNN” format (hours-minutes). Taking the {@DTG} field as example: • A DTG field with default date\time formatting will look like this: {@DTG} • A DTG field with a configured formatting will look like this: {@DTG|dd/mm/yy hh:nn:ss}

where the pipe char “ |” separates the field name and its format. To configure a datetime field to a specific format, select a datetime field, right-click and select the ‘Modify Date Format’ option. A dialog will allow you to set the wanted format, with the Help menu allowing you to select from typical formats or from individual date and time building blocks.

4.1.5.2.

Model Character Conversion

Character conversion is performed using a popup menu specific to the Character Conversion list. When right clicking over the list, three specific menu options are available: New Conversion, Modify Conversion and Delete Conversion. These show-up only when editing a Downlink Model (not in View Mode). Option New Conversion

Description Opens the window showed in Figure 4.19 to define the character conversion. Disabled if: The maximum number of conversions has been reached. Modify Conversion Opens the window showed in Figure 4.19, with the ‘From’ and ‘To’ fields preset to the conversion to modify. An alternative is to double-click. Disabled if: No existing conversion selected in the list. Delete Conversion Removes the selected conversion from the list (will be saved when saving the model). An alternative is to use the Delete key. Disabled if: No existing conversion selected in the list. Table 4-15: Templates – Model Field Character Conversion

84

ASP Administrator Guide Version 6.9a

To select a ‘From’ character, either double-click or single-click and click the ‘From’ button. Then, perform the same for the ‘To’ character. The selected ‘From’ character is highlighted in yellow while the ‘To’ character is highlighted in green. Double-clicking again on a selected character removes the selection. It is possible to select a ‘From’ character without selecting a ‘To’ character; this is used to remove a character from the model field’s value. A removed character is indicated by the presence of “(none)” in the “Char To” column of the character conversion list of the model field definition. The ‘OK’ button confirms the conversion setting and is enabled only at least the ‘From’ field is set.

Figure 4.19: Character Conversion Window

4.1.5.3.

Model Properties

The model properties define parameters to be set for the final formatting of the messages generated.

Figure 4.20: Model Properties Dialog

85

ASP Administrator Guide Version 6.9a

These properties are separated into formatting maximums, message maximums and other. The formatting maximums are length constraints that affect the message formatting only; they do not generate any event logging. The message maximums are also length constraints that affect formatting, but also affect the message integrity and require a decision on the action to take if the constraints are not met; event logs are also always generated. The other properties, “include CRC check” and “force CAPS”, are flags used to activate simple options. All numeric properties may have a value of zero meaning that for the corresponding property, there is no constraint. Property Line length

Description Maximum number of characters allowed on one line of the free text portion of the message that will be produced using this model. When exceeded, the line is wrapped to a new line with a CrLf separator. The CrLf characters are not calculated in the total line length. The wrapping is “word sensitive”, meaning that it warps to the closest word. A word is identified by a space, dash, slash or backslash. When the word separator is dash, slash or backslash it stays with the preceding word. If no word separator exists before the line length is reached, the line is wrapped exactly at the line length. Spaces before a word wrapped to a new line or spaces after a word ending a wrapped line are trimmed.

Quote length

Number of lines

Total length

AEEC 620 special note: The first free text line of a message in 620 format always starts with ‘- ‘ and the free text starts after the second space. Line length wrapping is based on the free text only. Hence, if for example the line length is set to 50 and a word ends exactly at 50 characters, then the line will wrap and the first free text line of the message will really have 53 characters long plus the CrLf. Maximum number of characters allowed being pasted from the quoted original message (only applies to models having the MESSAGE QUOTE or FREETEXT QUOTE predefined field inserted into their model text). When replying or acknowledging a message or when distributing a message, this number of characters of the corresponding original message will be replacing the “QUOTE” field as part of the generated message free text. When exceeded, the message quote is truncated to the specified length before insertion into the message. Maximum number of lines allowed in the free text that is produced using this model. When exceeded, the specified action is performed and an event log is created. Splitting or truncating due to the number of lines will never cut in the middle of a word because the line length wrapping will have taken care not to cut words. Maximum number of characters allowed in the free text that is produced using this model. This includes: the generation of all fields (template fields and predefined fields) defined in the model (i.e. replacing fields with their corresponding values), and the free text entered directly in the model text.

86

ASP Administrator Guide Version 6.9a

Property

Description When exceeded, the specified action is performed and an event log is created.

Action when message maximums are exceeded

Split header / footer

Force CAPS CRC calculation OK

Cancel Clear

4.1.5.4.

Splitting or truncating due to the total length may cut in the middle of a word. For uplink models, this value maximum is 3520, the maximum number of characters allowed in a single uplink message (AEEC 620 specification). These actions are always accompanied with an event log. They are applied if any or both constraints fail. Truncate: Cut the message according to the most restrictive constraint. Split: Split the message in as many parts as required sending the full message (up to 99 parts). Each part can be headed and/or appended with a line specified by the split header and footer. The header and footer added line and characters are calculated in the respective constraints. Do not send: Simply drop the message processing at this point. Applies to the Split action only, and it is optional. The character # is used to insert in the message the current part number and ## is used to insert the total number of parts; otherwise the header and footer can contain custom text (e.g. “Part # of ##”). When set, the output message generated using this model will be completely capitalized. Otherwise, the original capitalization is conserved. See below. A minimum validation occurs and property changes are confirmed. The dialog closes and properties are ready to be saved with the model as a whole. If the model changes are cancelled, model properties changes are also cancelled. Cancels any changes to the model properties and closes the dialog. Clears all properties to their default values. Table 4-16: Templates – Model Properties

CRC Calculation

The CRC calculation option is used to append a cyclical redundancy check (CRC) value to messages sent to aircraft avionics or ground systems to ensure the integrity of messages during transmission. A message’s CRC is a 4-char value calculated from the freetext of the formatted message (or message part, if split) and appended at the end of the message. There are several CRC calculation algorithms based on different polynomial and settings so it is important to know the expected end format. ASP supports the following CRC calculations methods: •

622 for ATS messages: calculation used in AEEC 622 messages (ATS applications, including FANS’ AFN, ADS-B and CDPLC). This calculation relies on the presence of an “Imbedded Message Identifier” (IMI) information in the freetext for the CRC to be calculated, starting from the first character of the IMI.

87

ASP Administrator Guide Version 6.9a

•

CCITT standard (ITU-T): calculation for messages sent to/from the FMC that do not fall in the 622 category. The CRC is calculated from the start of the freetext. This is the calculation employed for most messages requiring a CRC.

•

CCITT straight: calculation which is a derivate of the CCITT standard based on the same polynomial but without the reversal of bits, bytes and swap of 4-b it nibbles (hence the “straight” designation). This calculation is used by some ground systems which don’t follow the standard calculation.

•

Auto-detect: the auto-detect is basically an automatic method of choosing the CRC between the 622 and the CCITT standard. If the message is identified as a 622 message (by the presence of an IMI at the beginning of the freetext), that calculation is used. Otherwise, the CCITT standard is used (the auto-detect will not select the CCITT straight calculation).

The calculation details are the following: Calculation details Initial value Reverse data bytes Polynomial Order Reverse CRC result before Final XOR Final XOR value Swap 4-bit nibbles in final value

622 n/a n/a 0x11021 on 17bit n/a

CCITT Standard 0xFFFF 16 bit yes 0x1021 on 16 bit yes

CCITT Straight 0xFFFF 16 bit no 0x1021 on 16 bit no

n/a n/a

0xFFFF 16 bit yes

0xFFFF 16 bit no

Where the steps are done in this order: 1. Initial value: initialize the register in which the CRC is calculated. 2. Reverse data bytes: reflect every bytes so that the LSB (least significant bit) becomes the MSB (most significant bit). 3. CRC calculation: calculate the CRC iteratively using the set polynomial on the length of the message. 4. Reverse CRC result before final XOR: reflect bytes again on the CRC register. 5. Final XOR Value: perform a final XOR with the CRC result. 6. Swap 4-bit nibbles in final value: reorder nibbles, that is: swap the high and low 4-bits nibbles in each calculated byte (e.g. if the calculations results in 0xF5A3, the swap will change it to 0x5F3A).

88

ASP Administrator Guide Version 6.9a

4.1.5.5.

Models used as SQL queries

When a template is distributed to a database user configured with a database link having query as command type, the database connector uses the model as an SQL query. The SQL query is run against the customer database defined in the database link. For more information about database links and command type, see document [S2] and look for Database Connector and Database Connection Type. There are several important considerations when writing SQL queries in models. First, the author should be aware of which data provider is configured in the database link. Not all SQL queries are interchangeable from one data provider to another. Another consideration is about curly brackets ({ and }). Some SQL instructions require them, but curly brackets cannot be typed in models because their usage is reserved for fields. For example, the ODBC CALL escape clause, which is used to execute a stored procedure using ODBC data provider, requires curly brackets. The clause looks like "{CALL ProcedureName (?,?)}". The workaround is, while editing the model, to select "ASCII character" in the drop down list, instead of "Fields", then to select "123 - {" or "125 - }", and click on the + button (or to double click on "123 - {" or "125 - }"). As an example, one could then enter as model text: {@0x7B}CALL MyProcedure ('{@FLIGHT IDENTIFIER}'){@0x7D}

A particular attention is required about single quotes (') when using fields containing text or date/time. Single quotes are not managed automatically. That means that a query like "INSERT INTO MyTable (MyColumn) VALUES ({@FLIGHT IDENTIFIER})" would not work because the field is not enclosed with single quotes. However, a query like "INSERT INTO MyTable (MyColumn) VALUES ('{@FLIGHT IDENTIFIER}')" should work (assuming the table exists, etc.). Still, if a field value contains one or more single quotes, the query, again, will not work. The only workaround is to configure the database link with stored procedures instead of queries. When inserting date/time fields, it is advised to explicitly set the format, a format that will be properly handled, database side, by an implicit or explicit conversion from text to date/time. See 4.1.5.1 for more information. The last concern is about database security. Any query may be run against the customer database configured in the link. This flexibility allows data to be deleted, for example, if enough rights have been granted. Also, if a field contains SQL instructions, there is a risk for them to be executed: this is called SQL injection. Sensitive data should be protected by the database administrator.

89

ASP Administrator Guide Version 6.9a

4.1.6.

Template Field Definition Wizard

This wizard is available from two different locations: the template General panel and Fields panel, when Wizard is on. It allows defining fields, but depending on the conditions in which it is called, it will define different type of fields: SubSMI (General panel) or Fields (Fields panel). The wizard is built into three steps and Step 1 defines the: ▪ field name ▪ value lookup table ▪ field type ▪ data format (always shown by default, disabled if not applicable) ▪ address by (field type set to "Dynamic Distribution" or "Air-to-air Uplink") ▪ units (field of data type date & time, latitude, or longitude) ▪ location of the field within the message: free text or TEI line When used to define fields within records, the location is fixed to free text and disabled. The location will determine the area where selections may be made in Step 3 and will provide context sensitive choices in Step 2. Coming back to Step 1, changing the location and pressing ‘Next’ will reset any selections made in the following steps.

Figure 4.21: Field Definition Wizard Window (1 of 3)

90

ASP Administrator Guide Version 6.9a

Note that the message displayed at each step is the message guide coming from the template in which the field is being defined. The colored areas indicate locations where fields are already defined. When defining fields, it is allowed to overlap field definitions. Hence colors are used only as a guideline to the user. This is not the case for records (see section 0). Also, a grayed background in the text box indicates the message is displayed for reference only, no selection from the user is expected. However, when the background is white, it indicates an area where the user is expected to perform a series of operations or selections (see Step 3 below). Step 2 provides the methods to define the field depending on the location selected in Step 1. Selecting one of the combined start and end of field methods listed will provide the final information needed to define the field in Step 3, i.e. the sequence of actions to take place in Step 3. Changing the method at any time and pressing ‘Next’ or ‘Back’ will reset any selections made in Step 3.

Figure 4.22: Field Definition Wizard Window (2 of 3)

91

ASP Administrator Guide Version 6.9a

Step 3 presents all that is needed to define the field according to the method selected in Step 2. It presents the appropriate buttons and data controls to be filled in accordance with the context, as defined in the table below. Context Defining a SubSMI Defining a field (within a record or not)

Start Identifier + End Identifier

Start Identifier + Fixed Length Start Identifier + Until End of Message or Until End of Record Start Identifier + End Identifier or Until End of Message or Until End of Record

Fixed Data Position + End Identifier Fixed Data Position + Fixed Length Fixed Data Position + Until End of Message or Until End of Record Fixed Data Position + End Identifier or Until End of Message or Until End of Record Delimiter\Occurrence + End Identifier

Controls Available in Last Step Name is fixed (cannot be changed). List of controls as per method selected (see below). Name Field Type Value Lookup Table Start Identifier Button Field Data Button End Identifier Buttons Start Identifier Button Field Data Button Start Identifier Button Data Start Button Start Identifier Button Data Start Button End Identifier Buttons Until End Check Box Data Start Button End Identifier Buttons Field Data Button Data Start Button

Data Start Button End Identifier Buttons Until End Check Box Delimiter Button Occurrence Value (calculated, no user input required) Field Data Button End Identifier Buttons Delimiter\Occurrence + Fixed Length Delimiter Button Occurrence Value (calculated, no user input required) Field Data Button Delimiter\Occurrence + Until End of Delimiter Button Message or Until End of Record Occurrence Value (calculated, no user input required) Data Start Button Delimiter\Occurrence + End Identifier or Delimiter Button Until End of Message or Until End of Occurrence Value (calculated, no user input required) Record End Identifier Buttons Until End Check Box Table 4-17: Templates – Field Wizard Last Step Context Data Name Field Type

Description Name of the field. Generally defaults to “New Field”, except for SubSMI in which case it displays SUBSMI1, 2, or 3 and is not editable. Field type of the field being defined, selected among a system pre-defined list. Defaults to ‘User Defined’, except for SubSMI in which case it is not visible at all.

92

ASP Administrator Guide Version 6.9a

Data Data Format

Address by

Value Lookup Table Field Location

Functions Undo Start Identifier

End Identifier

Until End

Field Data

Data Start

Delimiter

Occurrence

Description Data format applying to the currently selected field type of the field being defined, selected among a system’s predefined list. Defaults to ‘(none)’, except for SubSMI in which case it is not visible at all. If no data format is available for a specific field type, then the list is grayed-out and displays its ‘(none)’ selection. This list is only visible when the Field Type list selection is "Dynamic Distribution" or "Air-to-air Uplink", replacing the Data Format list (see section 0, Fields Panel for more details). Value conversion or expansion table in which to lookup in order to find the conversion. Defaults to ‘(none)’ and does not apply to SubSMI fields. Specifies if the field is located in the free text portion of the message or in the TEI line. Table 4-18: Templates – Field Wizard Data Description Allows resetting the step and start over, with the same method defined in the previous step. Requires a selection to be made (at least one character long) prior to pressing the button. Preferably, the selection should be unique. Anything else defined after will require being after the end of the start identifier. Selections ahead of this position will generate an error at the bottom of the window. Requires a selection to be made (at least one character long) prior to pressing the button. Preferably, the selection should be unique. This is generally the last selection to perform (when available on window). Selections must follow the previous selection made. Any of the three buttons can be used in any order and all identifiers do not need to be defined to go to the next step. When checked, indicates that the field may or does go up to the end of the message or record if within a record. If end identifiers are defined, until end applies only if the identifiers are not found. If there is no end identifier, field definition definitely goes to the end of the message. Requires a selection to be made (at least one character long) prior to pressing the button. The selection represents the data contained in the field. Selections must follow the previous selection made (if any). Requires positioning the cursor (no need to make a selection) prior to pressing the button. The cursor position or the start of the selection if one was made represents the start of the field data, no matter how the field data is delimited. The cursor position must follow the previous selection made (if any). Requires a selection to be made (up to 50 characters) prior to pressing the button. Anything else defined after will require being after the end of the delimiter. Selections ahead of this position will generate an error at the bottom of the window. This is a calculated value applying only when a delimiter is defined. It gets calculated after the delimiter has been defined (Delimiter button). It counts the occurrence of the selected delimiter relative to the start of the free text (delimiters do not apply when in the TEI line). Table 4-19: Templates – Field Wizard Functions

93

ASP Administrator Guide Version 6.9a

Text within which no field can be defined is grayed-out (e.g. if the location specified in Step 1 was free text, then everything before the free text will be dimmed; see Figure 4.23). The bottom of each step panel shows an empty rectangle. This area is used to display messages to the user such as when performing an invalid selection or when the wizard is loaded with an invalid message guide (e.g. no free text); see Figure 4.23.

Figure 4.23: Field Definition Wizard Window (3 of 3)

Only one data selection button is enabled at any time, which indicates what needs to be selected. It is only when the full sequence of data has been defined (all data selection buttons disabled) that the ‘Finish’ button will become available. Still, some final validation is performed when clicking the ‘Finish’ button, and if everything is fine, the wizard will terminate, returning the gathered data as a new field. Canceling at any time returns to the Templates window with no change compared to when the wizard was called.

94

ASP Administrator Guide Version 6.9a

4.1.7.

Template Record Definition Wizard

This wizard is available from one location: the template Records panel, when Wizard is on. It allows defining record blocks. The wizard is built into four steps and Step 1 provides the methods to define the start and the end limits of the record block. It also presents the default name of the record block: ‘New Record’, which can be changed anytime before the ‘Finish’ button is pressed (may come back with the ‘Back’ button anytime along the wizard execution). Record blocks may only be defined in the free text portion of a message; henc e, no location specification is needed.

Figure 4.24: Record Definition Wizard Window (1 of 4)

Step 2 presents all that is needed to define the record block limits according to the method selected in Step 1. It presents the appropriate buttons and data controls to be filled in accordance with the context, as defined in the table below. Context Block Start Identifier + Block End Identifier

Block Start Identifier + Until End of Message

Controls Available in Last Step Block Start Id Button Block Start Position Button Block End Id Buttons Block Start Id Button

95

ASP Administrator Guide Version 6.9a

Context

Controls Available in Last Step Block Start Position Button Block Start Identifier + Record Occurrence within Block Block Start Id Button Block Start Position Button Record Occurrence Value Block Start Identifier + Block End Identifier or Until End of Block Start Id Button Message Block Start Position Button Block End Id Buttons Until End Check Box First Record Start Identifier + Block End Identifier Record Start Id Block End Id Buttons First Record Start Identifier + Until End of Message Record Start Id Block Start Position Button First Record Start Identifier + Record Occurrence within Record Start Id Block Record Occurrence Value First Record Start Identifier + Block End Identifier or Until Record Start Id End of Message Block End Id Buttons Until End Check Box Delimiter & Occurrence + Block End Identifier Delimiter Button Delimiter Occurrence Value (calculated, no user input) Block Start Position Button Block End Id Buttons Delimiter & Occurrence + Until End of Message Delimiter Button Delimiter Occurrence Value (calculated, no user input) Block Start Position Button Delimiter & Occurrence + Record Occurrence within Block Delimiter Button Delimiter Occurrence Value (calculated, no user input) Block Start Position Button Record Occurrence Value Delimiter & Occurrence + Block End Identifier or Until End Delimiter Button of Message Delimiter Occurrence Value (calculated, no user input) Block Start Position Button Block End Id Buttons Until End Check Box Fixed Block Position + Block End Identifier Block Start Position Button Block End Id Buttons Fixed Block Position + Until End of Message Block Start Position Button Fixed Block Position + Record Occurrence within Block Block Start Position Button Record Occurrence Value Fixed Block Position + Block End Identifier or Until End of Block Start Position Button Message Block End Id Buttons Until End Check Box Table 4-20: Templates – Record Wizard Step 2 Context

96

ASP Administrator Guide Version 6.9a

Data & Functions Undo Block Start Id

Block End Id

Block Start Position

Until End

Record Occurrence

Record Start Id

Description Allows resetting the step and start over, with the same method defined in the previous step. Requires a selection to be made (at least one character long) prior to pressing the button. Preferably, the selection should be unique. Anything else defined after will require being after the end of the block start identifier. Selections ahead of this position will generate an error at the bottom of the window. Requires a selection to be made (at least one character long) prior to pressing the button. Preferably, the selection should be unique. This is generally the last selection to perform (when available on window). Selections must follow the previous selection made. Any of the three buttons can be used in any order and all identifiers do not need to be defined to go to the next step. Requires positioning the cursor (no need to make a selection) prior to pressing the button. The cursor position or the start of the selection if one was made represents the start of the first record occurrence, no matter how record occurrences are delimited *. The cursor position must follow the previous selection made (if any). * Record occurrence delimiting is addressed in Steps 3 & 4 of the wizard. When checked, indicates that the record block may or does go up to the end of the message. If end identifiers are defined, until end applies only if the identifiers are not found. If there is no end identifier, record block definition definitely goes to the end of the message. This is user-entered value specifying a fixed number of record occurrences within the block being delimited. When available on window, it is always the last data item to specify in this step of the wizard and the value may not be zero (at least one). The maximum number of occurrences is limited to 32. At this step of the wizard, the record start identifier is solely used to identify the start of the record block, not the start of the first record occurrence.

Requires a selection to be made (at least one character long) prior to pressing the button. Preferably, the selection should be unique up to where it is defined. Anything else defined after will require being after the end of the record start identifier. Selections ahead of this position will generate an error at the bottom of the window. Delimiter Requires a selection to be made (up to 50 characters) prior to pressing the button. Anything else defined after will require being after the end of the delimiter. Selections ahead of this position will generate an error at the bottom of the window. Delimiter Occurrence This is a calculated value applying only when a delimiter is defined. It gets calculated after the delimiter has been defined (Delimiter button). It counts the occurrence of the selected delimiter relative to the start of the free text. Table 4-21: Templates – Record Wizard Step 2 Data & Functions

Note that the message displayed at each step is the message guide coming from the template in which the record block is being defined. The color areas indicate locations where record blocks are already defined.

97

ASP Administrator Guide Version 6.9a

Also, a gray background in the text box indicates the message is displayed for reference only, no selection from the user is expected. However, when the background is white, it indicates an area where the user is expected to perform a series of operations or selections (see Step 2 & 4 below). Selecting one of the methods listed in Step 1 will provide the final information needed to define the record block in Step 2, i.e. the sequence of actions to take place in Step 2.

Figure 4.25: Record Definition Wizard Window (2 of 4)

Text that appears gray, italic and strikethrough is text within which no record block can be defined (i.e. everything before the free text in Step 2). The bottom of each step panel shows an empty rectangle. This area is used to display messages to the user such as when performing an invalid selection or when the wizard is loaded with an invalid message guide (e.g. no free text). Only one data selection button is enabled at any time, which indicates what needs to be selected. It is only when the full sequence of data has been defined (all data selection buttons disabled) that the ‘Next’ (Step 2) or ‘Finish’ (Step 4) button will become available. Still, some final validation is performed when clicking the corresponding button, and if everything is fine, the wizard will go to Step 3 from Step 2 or terminate from Step 4, returning the gathered data as a new record block.

98

ASP Administrator Guide Version 6.9a

Canceling at any time returns to the Templates window with no change compared to when the wizard was called. Once Step 2 has been completed, the ‘Next’ button becomes enabled (not the ‘Finish’ button yet). Once pressed, the ‘Next’ button triggers final validation of Step 2 and if successful, brings the window for Step 3. Step 3 is similar to Step 1, but this time all that needs to be defined is the record occurrences limits. There is one of four ways to delimit a record occurrence as seen in Figure 4.26.

Figure 4.26: Record Definition Wizard Window (3 of 4)

Record Separator provides a Record Separator button in Step 4. Record Start Identifier provides a Record Start Identifier button in Step 4. Record Fixed Length provides a Record Occurrence Value control in Step 4. Record Start Identifier and Separator provide both corresponding buttons in Step 4. This last case is slightly redundant in the sense that either one of the identifier or separator would be enough to identify each record occurrence, but specifying both (when possible) may help in clearly identifying the record block end in some specific cases and speeds up a little the record treatment.

99

ASP Administrator Guide Version 6.9a

Data & Functions Undo Record Separator

Record Start Id

Description Allows resetting the step and start over, with the same method defined in the previous step. Requires a selection to be made (at least one character long) prior to pressing the button. The record separator is a series of characters that marks the end of each record occurrence, including the last occurrence. Requires a selection to be made (at least one character long) prior to pressing the button. If the record start identifier had been defined in Step 2, the button will be disabled and the value previously defined will be used. The record start identifier is a series of characters that marks the start of each record occurrence.

Record Length

Often, when such an identifier exists and that it is unique prior to the first record occurrence, it can be used to identify the record block start as well as the first record occurrence. Requires a selection to be made (at least one character long) prior to pressing the button.

The selection length will define the record occurrences fixed length, which is calculated and displayed. Record Length Display of the resulting length selected after the Record Length button has been pressed. If the length seems incorrect, the Undo button may be used to perform the selection again. Table 4-22: Templates – Record Wizard Step 4 Data & Functions

100

ASP Administrator Guide Version 6.9a

Figure 4.27: Record Definition Wizard Window (4 of 4)

Once Step 4 has been completed, the ‘Finish’ button becomes enabled. Once pressed, the ‘Finish’ button triggers final validation of Step 4 and if successful, returns the gathered data as a new record block to the Templates window.

Templates Distribution Templates distribution applies to the three template types: downlink, uplink, and ground. Downlink and ground messages get distributed to users and user groups while uplink messages are distributed to aircraft. The Distribution windows are available from the Main client window using the ‘Downlinks’, ‘Uplinks’, or ‘Grounds’ dropdown buttons as ‘User or Aircraft Distribution’. The windows are also accessible from the Templates windows using the ‘Distrib.’ buttons, and via the Operations menu. The figure below shows the Downlink Templates Distribution window (the Uplink and Ground Template Distribution windows are similar but with some differences presented further in the section).

101

ASP Administrator Guide Version 6.9a

Figure 4.28: Downlink Distribution Window

To define distribution of messages, the following is prerequisite: 

Users and user groups to which downlink or ground messages should be sent (recipients) must have been defined in the ‘Users’ window.



Aircraft must be defined in the system for uplink distribution.



Templates, and optionally models, must exist in the system (although a few predefined templates are built-in the system and usable with distribution rules).

The window works around the two main lists: the ‘Recipients Users’ list on the left -hand side of the window and the ‘Distributed Templates and Models’ list at its right. When a user or group is selected in the ‘Recipient Users’ list, the ‘Distributed Templates’ that are checked are distributed to the recipient, or will be when appropriate, and formatted according to the configured model. An ‘Additional Criteria’ panel is also available for downlink templates to refine the distribution rules further (also available for ground templates from external users only, and for uplink copy for uplinks from external users and computer-generated). The ‘Show Templates’ dropdown list shows all sources of templates available for the context of the window. This is a type of filter that lists only the templates from the selected category, allowing for a clearer breakdown of the information. Below the ‘Show Templates’ dropdown, a note indicates whether the configuration for the selected template source represents an absolute or on-demand distribution. An absolute

102

ASP Administrator Guide Version 6.9a

distribution means that messages are always distributed to all recipients when the matching message is processed, while an on-demand distribution means that messages are distributed to some of the users (or aircraft) only when these are identified as recipients by other mechanisms such as auto-reply, addressing, or notification. As an example of on-demand distribution, if the ETA changed event occurs and it is configured to notify two users, these two users must be checked in the ground template distribution for the ETA update template (computer-generated template source) in order to know how to format the notification message. But if other users are checked in the ground distribution for the ETA update template, they will not receive the notification. It is the event handling configuration that decides who receives a message; the ground distribution only specifies the formatting to use when a user needs to be notified. Each template checked for distribution must be associated with one model out of those defined for each template, or ‘(raw)’ to distribute the message without formatting. The models listed with a ‘*’ next to them are the models configured as the “default” model for each template – they will be selected automatically when a template is checked. When no default model is configured for one template, the ‘(raw)’ model becomes the default model. Browsing through lengthy lists can be eased by representing the data differently using the buttons ‘Flip View’ and ‘Chk Only’ (selected only). When pressed, the ‘Flip View’ button flips two first and second lists around so that the distribution rules are displayed from the point of view of templates. In the flipped view, templates are in the left-hand side list while the users are listed in the right-hand side list, with checks associated with those configured to receive the selected template. The ‘Chk Only’ button filters down the distribution lists to only the items that are checked, thus leaving out those not configured for the selected recipient or template.

103

ASP Administrator Guide Version 6.9a

Figure 4.29: Downlink Distribution Window, in normal view, flipped view and selected only view

At all times, only one item (‘Recipient’ or ‘Template’ in flipped view) can be selected in the left-hand side list since the displayed distribution rules apply only to the selected item. When the selection is changed in the left-hand side list, a new set of distribution rules is loaded applying to the selected item only. Multiple selection is however possible in the other lists, using the ‘Ctrl’ and ‘Shift’ keys while selecting items, so that the check/uncheck actions can be applied to all selected. Remember that the lists’ content are loaded when the window is opened and does not update automatically if some users or templates are added while the window is opened. However, the content of all displayed lists can be refreshed anytime by pressing ‘Refresh’, available in View mode.

104

ASP Administrator Guide Version 6.9a

4.2.1.

Dynamic Groups

In addition to the configured users and groups, the downlink and ground distribution windows also list a distinct type of users: dynamic groups. These special groups allow the distribution of selected templates and models to groups of users & addresses that are determined dynamically during the processing of the messages. The supported dynamic groups are the following: 

Airport - Origin: Templates configured with this group as recipient will be distributed with the configured model to a list of recipients determined by the origin airport from which the related aircraft is flying. The airports must be configured in the Airport Distribution window, with their associated list of recipients. See Airport Distribution (section 4.5) for more details.



Airport - Destination: Same as the above but based on the destination airport the aircraft is flying to.



Flight Assignment Desks: This distribution is based on dynamic flight assignments which associates the daily flights to dispatcher’s desks so that the received messages for a given flight are distributed only to the dispatcher responsible for that flight. These assignments are received by ASP in a special “dynamic flight assignments” message and are visible to the dispatchers in the “My Flights” window. Dispatcher desk names are associated to ASP users in the “Users and Groups” window. See section 9.1.1 for the details of the feature.

4.2.2.

Downlink Templates Distribution Specifics

For downlink messages, only templates of the category ‘From Aircraft’ are available in the ‘Show Templates’ dropdown list. Users can be designated recipients of a message by being selected directly or through the selection of groups (displayed in bold) containing the said user. The order in which criteria are considered gives priority to the user over the group settings (when applicable) and for downlinks, to template/model over the other criteria. Hence, if a user belongs to a group and both the user and the group are set to receive a specific template, only one copy of the message will be sent to it and will use the model specified from the user distribution rule, not the one from the group, should they be different. For both downlink and ground distribution, users displayed in gray text are not active for distribution, meaning that although they can be used to configure distribution rules, these rules will be ignored until the users become active again (refer to section 6.1.2 User Data for more details).

105

ASP Administrator Guide Version 6.9a

Checking a template means that the recipient will receive all messages that match the template reformatted as per the specified model. Once such a template has been checked, the list of its models appears in the ‘Format with Model’ list and the selected model is displayed to the right of the template. If a default model is specified for the selected template, it will be selected right away; otherwise the ‘(raw)’ model will be chosen, meaning that the user will receive the message as received by the system, without reformatting. The ‘Additional Criteria’ panel allows for more specific distribution rules to be defined for a given template, based on the originating aircraft, a flight number, some specific origin/destination addresses, or specific field values (requires special configuration explained below). For each selected user-template pair, any two additional criteria from the following list can be defined: •

Aircraft: A downlink matching the selected template will be distributed to the associated recipient only if it comes from one of the aircraft selected in the ‘Aircraft’ list.

•

Aircraft Type: Distributed to the selected recipient if received from an aircraft of the selected types.

•

Flight Id: Distributed if received from one of the flight identifiers selected. Flight identifiers are managed from a contextual menu called by right-clicking in the ‘Flight Id’ list, offering the options to create a ‘New’ entry, to ‘Modify’ or ‘Delete’ one. The configured flights must include the two-character IATA airline code followed by a four-digit flight number. The system will convert the FI received with ICAO codes to IATA if needed and pad the number of digits to four as necessary. The wildcard character ‘?’ can also be used in place of a character as to match any letter and number in the received flight number from the aircraft. As an example, the flight number “XS03??” would match anything between “XS0301” and “XS0399” and the associated downlink would be distributed to the selected user.

•

Dynamic Flight Id: Deprecated. Functionality replaced by the dynamic group “Flight Assignment Desks” described in section 0 above.

•

Orig. Type B: Distributed to the selected recipient if the origin address of a downlink (second line of the Type B header) is amongst the selected Type B addresses in the ‘Orig Type B’ list. Like the Flight Id list, the Type B list is managed from a contextual menu called by right-clicking in the ‘Orig. Type B’ or ‘Dest. Type B’ list (the same addresses are used for the origin and destination routing rules).

•

Dest. Type B: Although most downlinks received by AIRCOM® ServerPlatform should be addressed directly to the Type B address associated to AIRCOM® ServerPlatform, it is possible for the system to process messages not directly addressed to it. In such a case, it may be useful to distribute traffic based on the destination address (first line of the Type B header) specified in a downlink message. This criterion allows such distribution.

•

Value for: : Allows distributing the message to users based on the value of specific fields within the received message. For such “Value for” criteria to be listed there is a required configuration to perform in templates. On a per template basis, for each field allowing defining a lookup table, open the Value Properties and check the option “Use value list as additional criteria in distribution”. Doing so will add an entry in the additional criteria dropdown list when that template is selected in the distribution, and the corresponding field’s lookup table value list will be available to fine tune the distribution. 106

ASP Administrator Guide Version 6.9a

When two ‘Additional Criteria’ are specified for a given user-template pair, the two rules can be associated by ‘Or’ or ‘And’ rules. The ‘Or’ association will distribute a downlink if any of the two criteria finds a match in the selected items; while the ‘And’ association will trigger the distribution only if both criteria are fulfilled. Also, the ‘Copy’ and ‘Paste’ buttons can be used to quickly replicate a set of criteria to other user-template pairs. The ‘Clear’ button will clear any additional criteria by reverting both to ‘(none)’.

4.2.3.

Uplink Templates Distribution Specifics

The ‘Uplink Distribution’ window is very similar in its use to the ‘Downlink Distribution’ window, without the ‘Additional Criteria’ panel. The ‘Uplink Aircraft Distribution’ serves to associate aircraft (rather than users) with the templates that they can receive and the model to use in each case. Unlike the downlink distribution window, a template associated with many aircraft doesn’t mean that a matching uplink will be distributed to all aircraft at once but rather that it will be sent to the aircraft designated in the original message using the models specified with the associated templates.

Figure 4.30: Uplink Distribution Window

The uplink distribution window covers templates of three different sources: ‘From External User’, ‘From Local User’ and ‘Computer-Generated’, selected by the ‘Show Templates’ dropdown list.

107

ASP Administrator Guide Version 6.9a

The uplink templates ‘From External User’ are those associated with messages received from users such as Type B users or applications, e-mail or Notes users, etc. – in short, any type of user that is not a local user. The models specified for these uplinks can be ‘(raw)’ only if the uplinks received from the external users are already valid AEEC-620 messages. Otherwise, a model must be used to generate a valid 620 uplink out of the information contained in the incoming uplinks. The uplink templates ‘From Local User’ are those employed by local users when they create new uplinks from the AIRCOM® ServerPlatform client application. Since no raw message exists in this case (no incoming uplink) every template must be associated with a model to be formatted properly. However, a convenient shortcut has been created in this case to distribute all templates from local users with their default model without requiring the configuration of every template individually. When the checkbox ‘Distribute all templates … using the default model’ is checked, every template from local user is considered selected for any aircraft and associated with the default model in all cases. Even a template created after the ‘Distribute all templates …’ has been checked will be distributed with its default model without the need to update the distribution configuration. The uplink templates ‘Computer-Generated’ are those automatically generated by the system in response of specific events, as configured: auto-replies, autoacknowledgements and air-air messages. Like the templates from local users, the computer-generated templates require a model to be associated with them in order to be distributed. Likewise, the checkbox ‘Distribute all templates …’ acts as a shortcut to distribute all computer-generated templates to any aircraft using the default model.

4.2.4.

Uplink Templates User Copy Specifics

The ‘Uplink Copy Distribution’ window is similar to the other distribution windows. It allows the distribution for templates ‘From External User’, ‘From Local User’ and ‘Computer Generated’. There is no model selection in this window because what is distributed is an exact copy (cc) of the uplink when sent to the aircraft for the first time. When distributing for templates ‘From External User’ or ‘Computer-Generated’, additional criteria are available and they work exactly the same as for downlink templates distribution. Note that the reason to have additional criteria for computer-generated templates is to allow receiving uplink copies only for some specific aircraft or flights.

108

ASP Administrator Guide Version 6.9a

Figure 4.31: Uplink Copy Distribution Window – From External User

Figure 4.32: Uplink Copy Distribution Window – From Local User

109

ASP Administrator Guide Version 6.9a

Figure 4.33: Uplink Copy Distribution Window – Computer-Generated

4.2.5.

Ground Templates Distribution Specifics

The ‘Ground Templates Distribution’ window is similar to the other distribution windows. It allows the distribution for templates ‘From External User’ and ‘Computer-Generated’. No templates ‘From Local User’ are listed there as the model to use is chosen by the local user at generation time. This choice is left to the end user because the recipients of ground messages are other users, not aircraft, and so the formatting does not need to be as strict. It also simplifies the distribution process for the administrator of the system since there is no need to configure the distribution for ground templates used by local users. When distributing for templates ‘From External User’, additional criteria are available and they work exactly the same as for downlink templates distribution.

110

ASP Administrator Guide Version 6.9a

Figure 4.34: Ground Distribution Window – From External User

Figure 4.35: Ground Distribution Window – Computer-Generated

111

ASP Administrator Guide Version 6.9a

4.2.6.

Function Description

The following describes functions of the Distribution window. Function Refresh

Save6

Description Refreshes the lists of templates, models, users, groups, aircraft and aircraft types whenever applicable. Refresh is available only in View mode. Allows displaying either the recipients or the templates to the left of the window, enabling browsing per recipient or template. This just changes the view of the configuration, not the configuration itself. Anything that is configured in one view is equivalently configured in the other view. In other words, we can talk about recipient-template pairs. Whenever an item in the right list is checked, it is in fact always linking a recipient to a template, no matter the ‘Flip View’ setting. Checked Only, when pushed in, displays only the selected items (i.e. templates, users, additional criteria) to the right of the window, and when pushed out, displays all available items. This function is available only in view mode. When editing, the display shows the complete lists of available items. Allows modifying the distribution configuration. The configuration of all recipient-template combinations can be modified and all changes will get saved or cancelled at once upon the next save or cancel operation. Saves any changes performed since the last modify operation.

Cancel6

Cancels any changes since the last modify operation.

Close

Closes the Distribution window.

Multiple Checking

Any lists with check boxes behave the same regarding multiple selections. It is important to note the difference here between selected and checked item. Selection is related to item highlighting, while check status is related to the check box status.

Flip View

Chk Only

Modify6

• • •

Copy/Paste

Ctrl-A selects all list items. Ctrl or Shift combined with mouse click allows multiple selections. Once a multiple selection is performed, setting or removing the check of any item in the selection applies the action to all selected items, i.e. add or remove check for all selected items. Hence, to do a select/deselect all, do a Ctrl-A and then check one of the unchecked items or remove the check for one of the checked items. Applies to downlink distribution only. Allows copying a set of ‘Additional Criteria’ and pasting it into other recipient-template selections. To copy the additional criteria from one template to another, select a user and template having the set of criteria to replicate and click ‘Copy’. Then select (no need to check) any other user-template pair, and click ‘Paste’. Any selection that was not already checked will become checked and all will have the same additional criteria settings as the last copied settings.

6

Modify, Save, and Cancel are available also via a context-sensitive menu obtained by right-clicking over the list to the left of the window. 112

ASP Administrator Guide Version 6.9a

Function Clear Distribute with another model to the selected entries

Description Applies to downlink distribution only. Clears the additional criteria settings for the current recipient-template selection. This button appears next to the ‘Format with Model’ dropdown list and allows adding another distribution rule for an existing pair of template – user selection. In essence, this means you can distribute the same message to the same user with different formats, typically based on some criteria like field values using additional criteria. To be allowed to configure such multiple distribution of the same template to the same user, the template requires a special configuration. On a per template basis, select the Advanced tab and check the “Allow the distribution of multiple models to the same user” option. The button will show next to the models dropdown only for templates with this configuration. This function applies only to downlink templates and ground templates from external users. The result of adding a new distribution rule using this button is to add an extra entry in the list above the model selection dropdown with the different models. It is not allowed to have two entries with the same model selection (including the no model “raw” selection when it applies). If an entry exists with multiple distributions, when one of the entries is unchecked, it is removed for the list. Table 4-23: Distribution Functions

4.2.7.

Data Description

The following describes the data components of the Distribution window. Data Show Templates (list)

Recipient Users or Destination Aircraft (list)

Distributed Templates and Models (list)

Description Lists message sources applicable to the context (e.g. only ‘From Aircraft’ for downlink). The selection allows filtering the templates list to a subset corresponding to templates of all categories of the selected source. This allows not only to ease template navigation, but also to enable contextsensitive options relating to the message source. For example, for Computer-Generated templates, the ‘(raw)’ entry in the model list does not apply, but it applies for templates From Aircraft or From External User. The left-most list on the window holds either users or aircraft defined in the system (by default). The ‘Flip View’ function may rather list templates. Recipient Users: Both users and groups are listed simultaneously. Two visual cues indicate if an entry is a user or a group: 1) a group is listed in bold and 2) a group has its User Type (second column) set to ‘Group’. Users’ Display Name is listed. Applies to downlink and ground distribution. Destination Aircraft: Lists aircraft identifiers and their type for all configured aircraft. Applies to uplink distribution. By default, the list is named ‘Distributed Templates and Models’, but when using the ‘Flip View’ function, it may take some other names like ‘Recipient Users and Models’ or ‘Destination Aircraft and Models’. Ultimately, this list is either the recipients list or the templates list, with the appended ‘Model’ column, indicating which model has been selected for any checked recipient-template pair.

113

ASP Administrator Guide Version 6.9a

Data Format with Model dropdown list

Additional Criteria (downlink distribution only)

Distribute all templates … using the default model (option)

Description Lists all models defined for the selected template. When checking a new recipient-template pair, the default model is selected, if existing, or the ‘(raw)’ entry, if defined in the context. The ‘Format with Model’ dropdown list allows the selection of any model defined under the selected template, including ‘(raw)’ when applicable which dictates how the message, distributed to a user or an aircraft, will be formatted. Selecting a model for non-checked item checks the item automatically. Saving a configuration without a model specified is not allowed; hence no recipient-template can be checked and saved with a blank model selection. Composed of two lists joined with a logical operator (and/or) defining any additional criteria to use for downlink distribution. To define these criteria applying to a recipient-template selection, the pair must have been checked. Each list presents the same content: the list of all possible additional criteria, i.e. aircraft identifiers, aircraft types, flight identifiers, destination and originator Type B addresses. Once an item is selected, another checklist appears below the criterion selection filled with the appropriate items (aircraft, aircraft types, flight identifiers, or Type B addresses). These new lists are used to configure the additional criteria. Refer to section 4.2.2 above for details about additional criteria. This option is available only when displaying templates ‘From Local User’ or ‘Computer-Generated’. When checked, it allows distributing all existing templates and future templates using their default model (if a default model is defined for it). If no default model is defined for a template, no distribution will occur for messages matching that template. When the option is checked, the checklist and the model list are disabled and nothing is checked, no model is showed as selected. It is understood that checking this option is equivalent to checking all templates and setting for each of them their default model, but in addition, it does not require maintenance when templates are added, because any new template is automatically included in that configuration. Table 4-24: Distribution Data

Templates Permissions Window Template user permissions apply to the two template types: uplink and ground. The configuration is telling the system, for each configured user, which templates (uplink or ground) it is allowed to use. In other words, if a user is not granted the permission to use a template, if it tries to send an uplink or a ground message (e.g. via email or Type B) matching that template, the message will not get processed and an event will be logged. For a message sent by a user to be processed and get to its configured destinations, the user must have the permission to use the template that matches the messages. For local users, it means that when they open the New Uplink or New Ground window, the only ‘From Local User’ templates available will be the ones for which they were granted permission.

114

ASP Administrator Guide Version 6.9a

The Template User Permissions windows are available through the Main client window ‘Uplinks’ or ‘Grounds’ dropdown buttons, ‘User Permissions’ option, from the Templates windows, ‘Permis.’ button, and via the Operations menu. The window allows an Uplink Distribution & Permissions, or Ground Distribution & Permissions administrator to view and maintain all corresponding permissions.

Figure 4.36: Uplink Templates Permissions Window

To define template user permissions, the following is prerequisite:  Users to which templates usage permissions are to be granted must have been defined.  The desired templates must have been defined.

4.3.1.

Function Description

Same as described in section 4.2.6 “Function Description”.

115

ASP Administrator Guide Version 6.9a

4.3.2.

Data Description

The following describes the data components of the Templates Permissions window. Data Show Templates (list)

Description Lists message sources applicable to the context (e.g. only ‘From External User’ or ‘From Local User’). The selection allows filtering the templates list to a subset corresponding to templates of all categories of the selected source. This allows easing template navigation. The originating users list holds all users defined in the system. The list can be displayed either to the right or to the left of the window (to the left by default) using the ‘Flip View’ function.

Originating Users (list)

Allowed Templates (list)

Allow all templates … for use by all users (option)

Note that only users (all user types) are listed, but no user groups. Templates permissions are granted to individual users only. Lists all templates of the appropriate type (uplink or ground) and source (see ‘Show Templates’ list above) defined in the system. Note that inactive templates are listed, allowing completing templates configuration before activating them. This option is available only when displaying templates ‘From External User’ or ‘From Local User’. When checked, it allows all users to use any existing template of the selected category and future templates.

When the option is checked, the checklist shows all the allowed templates as checked but the list cannot be edited. Table 4-25: Templates Permissions Data

Downlink Acknowledgement The Downlink Acknowledgement window is available through the Main client window ‘Downlinks’ dropdown button, ‘Downlink Acknowledgement’ option, from the Downlink Templates window, ‘Ack.’ button, and via the Operations menu. The window allows a Downlink Distribution & Acknowledgement administrator to view and maintain all downlink templates acknowledgement rules and therefore it is divided into two main areas: the list of templates on the left side of the window and the acknowledgement criteria on the right side of the window. Note that acknowledgement is based on downlink templates, i.e. all downlinks matching that template will have the same acknowledgement definition. To define acknowledgement of downlink messages, the following is prerequisite:  Local users that should acknowledge must have been defined (user groups cannot acknowledge and only local users can) and have that specific template added to their distribution configuration (see Downlink Templates Distribution window).  The downlink template to acknowledge must have been defined.

116

ASP Administrator Guide Version 6.9a

For each downlink template, the possible combinations of acknowledgement are:  No acknowledgement.  Automatic acknowledgement – the system will acknowledge using first, the autoacknowledgement uplink template if a model is configured for the considered aircraft (see Uplink Templates Distribution window), or if the latter is not configured, it will look for an uplink guide defined for the aircraft (see Fleet Configuration window). If none of the above is configured, then no auto-ack. will be performed and an event will be logged.  User acknowledgement – the user marked as ack. user will have an icon in its mailbox for each downlink message of the corresponding template.  Both automatic and user acknowledgement. Whenever the acknowledgement definition is changed for a specific downlink template, the change will eventually reflect in the Downlink Templates window (General panel, Acknowledgement options). Both the list of templates and the list of local users having that template in their distribution configuration may be refreshed anytime by pressing the ‘Refresh’ button, which is available only in View mode.

Figure 4.37: Downlink Acknowledgement Window

4.4.1.

Data Description 117

ASP Administrator Guide Version 6.9a

The following describes the data components of the Acknowledgement right most panel. Data Automatic Acknowledgement Ack. User List

Description When checked, indicates that messages of the selected template will generate automatic acknowledgement from the system. All individual users defined in the system AND that have the current downlink template selected in their own distribution configuration. No user groups are listed because groups cannot acknowledge downlinks.

By default, ‘(none)’ is selected, indicating that no human-made acknowledgement is required for the current message type. One and only one item may be selected at any time. Hence, if a user is selected, that user is requested to acknowledge the downlinks of the currently selected template. An ‘Ack’ icon will show in the user mailbox when the downlink is received. Table 4-26: Downlink Acknowledgement Data

Airport Distribution Window The Airport Distribution window is available through the Main client window ‘Downlinks’ dropdown button, ‘Airport Distribution’ option, and via the Operations menu. It allows an Airport Distribution administrator to view and maintain the airport distribution list of recipients. Operator profile users only have a “read-only” access while Airport Distribution administrators have “full” access to add, modify or delete recipients. All changes made in this window take effect immediately after a save operation is completed and are cancelled up to the last save operation if the cancel button is pressed. Airport distribution is used when a downlink template has a distribution rule defined for one of the two possible airport groups: origin or destination airport (see Figure 4.39). Once a message matching the template comes in, the airport code corresponding to the aircraft that sent down the message, corresponding to origin or destination is found in the aircraft tracking data. That code is looked for in the airport distribution configuration and, if found, the message gets redistributed to the defined list of recipients.

118

ASP Administrator Guide Version 6.9a

Figure 4.38: Airport Distribution Window

Figure 4.39: Downlink Templates Distribution Window – Airport Distribution Dynamic Groups

119

ASP Administrator Guide Version 6.9a

4.5.1.

Function Description

The following describes the available window functions. Function New (Ctrl-N) Modify (Ctrl-M) Delete (Del) Save (Ctrl-S)

Cancel (Ctrl-Z) Close (Ctrl-L)

Description Allows creating a new airport distribution list. Allows modifying an airport distribution list. Allows deleting the currently selected airport distribution list. Allows saving all modifications made to an airport distribution list. It is enabled only after either the Modify, New, or Delete button has been pressed. It is not allowed to create duplicate airport codes. Allows canceling any changes made in a New, Modify, or Delete operation. It is enabled only after either the Modify, New, or Delete button has been pressed. Closes the Airport Distribution window. Table 4-27: Airport Distribution Functions

Airport distribution lists are multi-edit, that is once a new, modify or delete operation has been performed, any other number of such operations can be carried out and they can all be saved or cancelled at once. Even deletions, although confirmed one by one, are definitely saved or cancelled upon the corresponding operation.

4.5.2.

Data Description

The following describes the window’s data components. Data List of all airport codes

ICAO

Description These are added when adding a new entry. The listed values match the ones in the ICAO and IATA text boxes described below. Duplicate ICAO or IATA codes are not allowed hence only one distribution list may exist per airport. An ICAO airport code (typically a city code, 4 characters). The code does not have to be valid (i.e. not found in the corresponding airport code Lookup Table). However, if not valid, the description next to it says “Invalid or unknown airport code (check code or ICAO lookup table)”. Otherwise, for a valid airport code, the description or expansion of that code is performed using the corresponding airport code Lookup Table. When typing an IATA code for which a corresponding ICAO code can be found in the IATA to ICAO lookup table and the ICAO code is empty, the ICAO code is automatically defined. Deleting the ICAO code clears the corresponding IATA code (if any). The ICAO code is mandatory. Duplicate ICAO (and/or IATA codes) are not allowed in the “List of all airport codes”, and duplication is verified during the save operation.

120

ASP Administrator Guide Version 6.9a

Data IATA

Description An IATA airport code (typically a city code, 3 characters). Behaves the same as the ICAO code just above. When typing an ICAO code for which a corresponding IATA code can be found in the ICAO to IATA lookup table and the IATA code is empty, the IATA code is automatically defined.

Checked users and groups

Additional Type B addresses

Deleting the IATA code does not clear the corresponding IATA code (if any) since the IATA code is not mandatory. List of all users and groups configured in AIRCOM® ServerPlatform through the Users and Groups window. Checked users will receive a copy of messages distributed to the airport, even though the user may not be physically located at the airport. This allows either defining airport users explicitly in ASP, if need be, and reuse them here, or to copy ASP users every time the airport receives a message. The “Show checked items only” allows seeing only checked users and groups, and it is always checked when in View mode. Text box to enter the list of Type B addresses, separated either by “,”, “;”, a space or a carriage return\line feed when typed-in. In any case, the addresses end up separated by “ ; ” for readability. During the save operation, the address list is parsed and validated. Each and every address must be a valid Type B address in order to allow saving, i.e. 7 characters between A and Z or between 0 and 9. If characters are entered in lower case, the system will automatically change them to upper case. Table 4-28: Airport Distribution Data

121

ASP Administrator Guide Version 6.9a

5. Aircraft Administration Aircraft Tracking and Uplink Management Tracked aircraft and uplink messages management is performed via the Aircraft Tracking window. The only available action is to cancel queued uplink messages for any aircraft, provided the administrator has the proper user rights: View aircraft tracking and Modify tracking data. To cancel queued uplink messages, refer to section 9.2.4, Canceling Queued Uplink Messages.

Aircraft Tracking and Uplink Hold Periods Uplinks hold periods for tracked aircraft can be managed via the Aircraft Tracking window. The only available actions are to start a hold period or stop a hold period for any aircraft, provided the administrator has the proper user rights: View aircraft tracking and Modify tracking data. To start an uplinks hold period, refer to section 9.1.7, Uplinks Hold & Wait Options.

Fleet Configuration Window The aircraft Fleet Configuration window is available through the Main window ‘Aircraft’ dropdown button, ‘Fleet Configuration’ option, and via the Operations menu. It shows all aircraft currently configured in the system by an administrator with the Manage aircraft right.

122

ASP Administrator Guide Version 6.9a

Figure 5.40: Fleet Configuration Window

5.3.1.

Function Description

The toolbar presents the core functions to configure the aircraft fleet. Function Refresh (F5)

Description Refresh (F5): Refreshes the displayed data content from the source database. If in view mode (see status bar at the bottom of the main window), the full list of aircraft and their data are refreshed, while if in add or modify modes, only the list of aircraft types, automatic acknowledgement guides and air/air guides are refreshed.

123

ASP Administrator Guide Version 6.9a

Function Find (Ctrl-F and F3)

Description Allows searching for an aircraft according to any of the data elements defining the aircraft. See Figure 5.41 and Figure 5.42 for string based and true/falsebased search. The Find dialog adjusts its display according to the ‘Search In’ selection data type. The string search occurs anywhere in the data element string (e.g. searching for ‘AL’ in ‘UAL’ is a match). The search is by default case insensitive, unless the ‘Match Case’ option is checked. As long as the Fleet Configuration window stays opened, the ‘Find What’ lists the searched strings history since the window was opened for quick pick. The keyboard key combination ‘Ctrl-F’ opens or brings to the front the Find dialog. The ‘F3’ key performs a ‘Find Next’ (same as the button in the dialog) on the last specified search criterion, no matter if the dialog is opened or not. The search cycles through the aircraft list and when a match is found, the matching aircraft is selected. The ‘Find’ function is available both in view and modify edit modes.

Export (Ctrl-E)

Exports the complete list of aircraft configuration data to a comma-delimited text file. The user is prompted to select the filename and location for the exported data. The default location is the data folder specified at the Client installation time and the default filename is of the form “fleet_[ddmmyy_hhmmss].txt” (e.g. fleet_090603_130526.txt) where “090603” is June 9, 2003 and “130526” is 13 h 05 min 26 sec (UTC time), the date and time at which the file was created. However, in remote access (i.e. via a Web browser), the filename is predefined to the default filename and the path is forced to the Client installation data folder on the server machine.

New (Ctrl-N)

To add a new aircraft, click ‘New’ from the toolbar or right-click over the list of aircraft and select ‘New’. The data is saved or cancelled upon the next save or cancel operation. To modify one or many aircraft simultaneously, select any aircraft and click ‘Modify’ from the toolbar or right-click over the aircraft and select ‘Modify’. Once in modify mode, any of the aircraft can be modified. All changes made to all aircraft will be saved or cancelled at once. To delete an aircraft, select it and click ‘Delete’ from the toolbar or right-click over the aircraft and select ‘Delete’. A confirmation is requested before proceeding, and if the aircraft being deleted is used by other configuration in the system, the confirmation dialog will inform the user. Once confirmed, the deletion is permanent and any configuration based on that aircraft is reset to “(none)”. To permanently save any pending changes, including any Event Handling setting changes, click ‘Save’ from the toolbar or right-click over the list of aircraft and select ‘Save’. To cancel any pending changes, including any Event Handling setting changes, click ‘Cancel’ from the toolbar or right-click over the list of aircraft and select ‘Cancel’. To close the Fleet Configuration window. If in add or modify mode, a confirmation is requested before closing to avoid losing any pending data changes. Opens the window to define the aircraft related event handling actions, applying to the complete fleet (refer to section 8.1 for details).

Modify (Ctrl-M):

Delete (Del)

Save (Ctrl-S)

Cancel (Ctrl-Z)

Close (Ctrl-L)

Event Handling Aircraft Types

Allows browsing and defining aircraft types configuration. Once back to the Fleet Configuration window, use the ‘Refresh’ function to see any changes performed to aircraft types.

124

ASP Administrator Guide Version 6.9a

Table 5-29 Fleet Configuration Functions

Figure 5.41: Fleet Configuration – Find a String

Figure 5.42: Fleet Configuration – Find True/False

5.3.2.

Data Description

Data

Description

List of aircraft

The list of all configured aircraft forming the customer’s fleet. The list also presents the airline, aircraft type and aircraft uplink group for quick reference and sorting purposes.

Aircraft registration

The aircraft registration identification or tail number composed of at maximum 7 characters and if shorter, it is typically prefixed with periods to make up a 7 characters identifier. The identifier must be unique among all configured aircraft and it is mandatory. Note, for example, that aircraft identifiers ‘..N-263’, ‘N-623’, and ‘N623’ are considered identical. Only alphanumerical characters are considered in comparing aircraft identifiers, in particular the dot being used for padding.

Nose Number

Alternate reference code to identify an aircraft and referred to as the ‘Nose Number’. The value is typically short but supports up to 10 characters. However, if the value is to be used with the FE, the value should not exceed 7 characters as it will be truncated when provided to FE. The nose number is available when writing new uplink messages to help identify aircraft. This is not a mandatory property of an aircraft.

Airline code

ICAO code (3 characters) or IATA code (2 characters) of the airline to which the aircraft belongs or for which the aircraft flies.

AESID

8 digits number identifier uniquely assigned to each aircraft, allowing communicating with it via satellite using the SATCOM feature described in document [S4a].

VHF/SAT/HFDL Equipped

Checked if the aircraft is VHF, SAT, or HFDL equipped, accordingly.

Aircraft type

User defined categorization of the aircraft (e.g. A320, B777). This is a value picked up from the existing configured aircraft types. To modify this list, use the button next to the drop down to open the Aircraft Types

125

ASP Administrator Guide Version 6.9a

Data

Description window. The aircraft type is used as a criterion for downlink distribution to users.

ACARS MU

Aircraft Communications Addressing and Reporting System Management Unit drop down list. This is a value picked up from the existing configured ACARS MU. To modify this list, use the button next to the drop down to open the ACARS MU window. The ACARS MU is used to define the proper format of scan table and frequency auto-tune message formats for a particular aircraft (refer to Dynamic Frequency Management or DFM).

Encryption enabled

Checked to mark an aircraft as being able to use the encryption type supported by its ACARS MU (see section 5.6), that is if the aircraft avionics supports message encryption. This check is available only with one of the possible encryption license options.

DFM enabled

Checked to mark an aircraft as being able to use Dynamic Frequency Management (DFM), typically if the aircraft avionics supports scan table updates and auto-tune messages. This check is available only with the DFM license option.

FANS enabled

Checked to mark an aircraft as being able to support FANS communications. This is required to be able to establish manual contracts with an aircraft through FlightTracker Map’s ATC panel.

ACMS

Aircraft Condition Monitoring System description (maximum 50 characters).

FMS

Flight Management System description (maximum 50 characters).

CMC

Central Maintenance Computer description (maximum 50 characters).

Engine

Engine description (maximum 50 characters).

Override default DSP

Overrides the default Data link Service Provider (DSP) defined in the Data Link Service Providers window for the current aircraft. This is used for uplink routing and only when the System Parameter – Uplink Message Handling “Use enhanced uplink routing” is set.

Allowed DSP list

Identifies the list of Data link Service Providers (DSP) the aircraft is allowed to communicate over. The default is all (i.e. all those defined in the Data Link Service Providers window), but a reduced specific set of DSP can be specified. This is used for uplink routing and only when the System Parameter – Uplink Message Handling “Use enhanced uplink routing” is set.

EFB

Information about the Electronic Flight Bag equipment on-board the aircraft.

Comments

Any additional comments related to the aircraft. Table 5-30 Fleet Configuration Data

126

ASP Administrator Guide Version 6.9a

5.3.3.

5.3.3.1.

How To

Define the aircraft type if not available in the list

Open the Aircraft Types window either using the button in the Fleet Configuration window or via the Main window toolbar or menu. Add the desired aircraft types. Go back to the Fleet Configuration and select ‘Refresh’ from the toolbar, no matter the current edit mode (add, modify, or view). The new aircraft types are now available in the list.

5.3.3.2.

Define the ACARS MU if not available in the list

Open the ACARS MU window either using the button in the Fleet Configuration window or via the Main window toolbar or menu. Add the desired ACARS MU. Go back to the Fleet Configuration and select ‘Refresh’ from the toolbar, no matter the current edit mode (add, modify, or view). The new ACARS MU is now available in the list.

5.3.3.3.

Define Event Handling for the entire fleet

Even though the event handling settings are common to the full fleet of aircraft, they can only be modified when in add or modify mode and they get saved with any save operation. Hence, either define a new aircraft or modify any of the existing aircraft, the ‘Event Handling’ button becomes available. Launch the “Event Handling” configuration window (section 8.1) using the button, perform the desired changes and select ‘OK’. Then, select ‘Save’ to permanently save the aircraft data and the event handling changes. Remember that if ‘Cancel’ is used, any event handling setting changes are also cancelled.

5.3.3.4.

Get the complete fleet configuration in a comma-delimited text file

This is what the ‘Export’ function does. Select the ‘Export’ toolbar option and provide the requested information in the “Export Fleet to File” dialog box, being the file name and location. Note that the default location is the Data folder specified at Client installation time and that the file name defaults to “fleet_[ddmmyy_hhmmss].txt” (e.g. fleet_090603_130526.txt) where “090603” is June 9, 2003 and “130526” is 13 h 05 min 26 sec (UTC time). Also, if running the Client remotely (Web access via a Web browser), the file name and location are predefined to the defaults (located on the remote server 127

ASP Administrator Guide Version 6.9a

effectively running the Client) and unchangeable (the user is not prompted for information). In any case, the user is told where the file was saved and what was the file name used.

Aircraft Types Window The Aircraft Types window is available through the Main window ‘Aircraft’ dropdown button, ‘Aircraft Types’ option, and via the Operations menu. It allows viewing all aircraft classifications, typically organized around their IATA/ICAO codes and it can be defined by an administrator with Manage aircraft right. The aircraft types are used to classify aircraft (Fleet Configuration window) and used as a possible downlink distribution criterion.

Figure 5.43: Aircraft Types Window

5.4.1.

Function Description

The following describes the available window functions. Function New (Ctrl-N) Modify (Ctrl-M) Delete (Del) Save (Ctrl-S)

Cancel (Ctrl-Z) Close (Ctrl-L)

Description Allows creating a new aircraft type. Allows modifying an existing aircraft type. Allows deleting the currently selected aircraft type. Allows saving all modifications made to an aircraft type. It is enabled only after either the Modify or New button has been pressed. It is not allowed to create duplicate aircraft types. Allows canceling any changes made in a New or Modify operation. It is enabled only after either the Modify or New button has been pressed. Closes the window. Table 5-31: Aircraft Types Functions

128

ASP Administrator Guide Version 6.9a

It is possible to define one level of sub-type mostly used to classify aircraft into a hierarchy of types. This provides an extra degree of flexibility in qualifying the aircraft in the fleet and it allows, among others, more flexible filtering. For example, one can filter to get all B744 in its fleet, no matter the B744 sub-type. Number of engines: The number of engines for this aircraft type. In addition to providing basic aircraft configuration information, the number of engines is used with the Fuel Conservation Monitoring (FCM) license option to gather and present engine data via the Aircraft Tracking window. ICAO aircraft type: ICAO aircraft type. This value is used to interface with FE and FRA. AFDAS fault group: Group of faults, defined via the Faults Management window that can be generated by this type of aircraft. This setting is available with the AFDAS license option. When creating a sub-type, the ICAO aircraft type and the AFDAS fault group default to the parent’s aircraft type values, if these were defined. Note there is no inheritance between an aircraft type and its sub-types for the number of engines. When creating a sub-type, the number of engines is blank and needs to be filled, and if a sub-type has no number of engines specified, it does not automatically uses the setting of the parent. FR-A category: Category of the aircraft to use when monitoring flight plans for the Flight Route Alerting feature. It defines the threshold that will be used for the monitored alarms. The FR-A categories are A, B and C and are defined as follows: •

Category A: commuter/regional aircraft

•

Category B: narrowbody aircraft (default when aircraft unknown)

•

Category C: widebody aircraft

Refer to section 9.2.12 “Using Flight Route - Alerting” below for the full details on the use of FR-A. This setting is visible only when the FR-A license option is set. “Downlink rate exceeded” event threshold (messages per minute): Maximum number of downlink messages per minute before flagging the aircraft of this type as sending excessive downlinks. This is associated with aircraft event handling which allows notifying users of the situation, sending an uplink to the aircraft and/or stopping distributing such downlinks. When the situation comes back to normal, users and the aircraft can also be notified.

129

ASP Administrator Guide Version 6.9a

Aircraft Lockout Management Window The Aircraft Lockout Management window is available through the Main window ‘Aircraft’ dropdown button, ‘Aircraft Lockout’ option, and via the Operations menu. It is accessible to users with the right Manage aircraft lockout. The window allows configuring "lockout" for aircraft over a period of time. It is typically used to hide the aircraft to non-authorized personnel in critical situations. When an aircraft is in a lockout period, it becomes invisible to users that do not have the right View data and messages from locked aircraft, as follows: •

Local users do not see the locked aircraft or data from the locked aircraft in their mailbox, in the aircraft tracking and FlightTracker windows as well as in the logs and reports. As such, they are also prevented from sending uplinks to the aircraft.

•

External users do not get distributed messages from the locked aircraft during its lockout period. Likewise, they are prevented from sending uplinks to the locked aircraft.

For that, it is advisable to review the View data and messages from locked aircraft user right before setting aircraft lock periods because it has impacts for these users, and it may have an external system suddenly stop receiving messages about a particular flight. If you want such a system or user to continue receive and send messages and follow a flight, it shall have the proper right. Other impacts are that not having the right to view locked aircraft for a local user means he will not be allowed to use the reports browser under the Logs menu because these could reveal undesired information about locked aircraft (this applies to users having the View logs user right). However, the log reports available directly from the event and traffic log windows are allowed because they already filter out locked aircraft.

130

ASP Administrator Guide Version 6.9a

Figure 5.44: Aircraft Lockout Management Window

5.5.1.

Data & Function Description

List of lock periods: The left-most list shows all currently defined lockout periods: aircraft registration, start and end date for the lock period. Many periods can be defined for the same aircraft, and it does not matter if the periods overlap. When the date’s columns show “(none)” it means there is no specific start and/or end date, so everything about the aircraft is hidden in one way or the other. Aircraft drop down list: List all aircraft registrations configured in the fleet configuration window. When creating a new lock period, you are invited to select an aircraft, but you can also type-in the first characters of an aircraft registration to auto-select it. When modifying an existing lock period, the aircraft cannot be changed. Send messages to FE: Allows sending messages to FE even though the aircraft is locked. From/To date & time: Through typing values or using the built-in calendar, specifies the range of time during which the aircraft is locked. Lock since… / until…: These checks allow hiding data all the way back to when data is available in the past and any new data in the future. For the lock until check, it also means anytime the aircraft flies, it is locked live, that is invisible to those not allowed in the aircraft tracking, flight following and send message interfaces. Comments: Any desired comments that can clarify why there is a lock on the aircraft for this period of time.

131

ASP Administrator Guide Version 6.9a

Refresh (F5): Refreshes the list of lock periods and the list of configured aircraft; available only in view mode. New (Ctrl-N): Adds a new lock period. Modify (Ctrl-M): Modifies the currently selected lock period. Delete (Del): Deletes the currently selected lock period after a user confirmation, Save (Ctrl-S): Saves changes. Cancel (Ctrl-Z): Cancels any pending changes Close (Ctrl-L): Closes the window. Context menu over the list of New/Modify/Delete/Save/Cancel options.

lock

periods:

Menu

presenting

the

ACARS MU Window The ACARS MU window is available through the Main window ‘Aircraft’ dropdown button, ‘ACARS MU’ option, and via the Operations menu. It allows viewing all ACARS MU used within the customer’s fleet, and it can be defined by an Aircraft fleet configuration administrator. The ACARS MU is used to classify aircraft (Fleet Configuration window), to def ine scan table update and frequency auto-tune message formats for Dynamic Frequency Management (DFM) handling, and to determine if an aircraft is equipped for message encryption (only with one of the possible encryption license options).

132

ASP Administrator Guide Version 6.9a

Figure 5.45: ACARS MU Window

5.6.1.

Function Description

The following describes the available window functions. Function New (Ctrl-N) Modify (Ctrl-M) Delete (Del) Save (Ctrl-S)

Cancel (Ctrl-Z)

Close (Ctrl-L)

Description Allows creating a new ACARS MU. Allows modifying an existing ACARS MU. Allows deleting the currently selected ACARS MU. Allows saving all modifications made (saves all new, modified, and deleted entries at once). It is enabled as soon as the New, Modify, or Delete button has been pressed. It is not allowed to create duplicate ACARS MU. Allows canceling any changes made (cancels all additions, modifications, and deletions at once). It is enabled as soon as the New, Modify, or Delete button has been pressed. Closes the window. Table 5-32: ACARS MU Functions

To enter in edit mode, perform any of the New, Modify, or Delete actions (via the toolbar or the list context menu). From then on, clicking modify is not required until the next save or cancel operation. Any entry can be modified by selecting it in the list and using the text box at the bottom of the window. Besides the MU’s name, a dropdown allows selecting the encryption type supported by the MU (if any). Note that if a fleet possesses the same ACARS MU but in different versions throughout the fleet’s aircraft, then different ACARS MU should be created and their version should be reflected in the MU’s name.

133

ASP Administrator Guide Version 6.9a

Also, specifying that an MU supports a certain encryption type does not mean that aircraft configured with that MU will effectively do encryption; it only says they are equipped to do so. . For an aircraft to be able to handle message encryption in the system it requires to be configured with an MU supporting encryption AND it must have the Encryption enabled flag set in the Fleet Configuration (see section 5.3.2).

Honeywell Encryption Configuration Window The Honeywell Encryption Configuration window is available through the Main window ‘Aircraft’ dropdown button, “Honeywell encryption’ option, and via the Operations menu. It allows configuring Honeywell encryption specific settings and it is available only if the Honeywell Encryption license option is set and if the user is an Aircraft and fleet configuration administrator. The following describes the available window functions. Function Refresh (F5) Modify (Ctrl-M) Save (Ctrl-S)

Cancel (Ctrl-Z)

Close (Ctrl-L)

Description Allows refreshing the data as well as the list of uplink templates (Message Types tab). It is available only in view mode, when not modifying data. Allows modifying an existing ACARS MU. Allows saving all modifications made: saves all modified and deleted entries at once, in all tabs. It is enabled as soon as the Modify button has been pressed. If a table set name, a message type set name or an SMI is empty, a warning will be displayed and save will be blocked. If one or more encryption tables are not valid, a confirmation will ask if you want to continue and save or cancel and review the data. Allows canceling any changes made: cancels all modifications and deletions at once, in all tabs. It is enabled as soon as the Modify button has been pressed. Closes the window. Table 5-33: Honeywell Encryption Configuration Functions

This window is composed of three tabs. The aircraft list presents all aircraft for which an ACARS MU supporting Honeywell encryption is configured. For each of these aircraft, it is possible to select a set of encryption tables to use for encryption / decryption and a set of message types to be encrypted / decrypted. Both of these sets are configured in the next two tabs. An icon may show up next to some aircraft registrations for the following reasons: 1) one or more encryption tables for the selected table set are invalid, and/or 2) the selected message type set has no SMI and no uplink template defined. This is just a visual cue to easily identify configuration that is invalid or missing important information. A tooltip explains what the problem is; just move the mouse over the icon.

134

ASP Administrator Guide Version 6.9a

Please note that to perform Honeywell encryption / decryption using AIRCOM® ServerPlatform, the on-board avionics must also have been properly configured to do so. For the on-board configuration, please refer to the appropriate Honeywell documentation.

Figure 5.46: Honeywell Encryption Configuration - Aircraft List

135

ASP Administrator Guide Version 6.9a

A few quick tips to manipulate the data: •

The grids are editable, thus double-clicking in a cell or selecting the cell and pressing F2 will enter in edit mode, and then pressing Enter will commit the change and exit edit mode. It is necessary to enter edit mode to perform changes, single clicking a cell just selects it. An exception is for cells with a drop down: clicking directly on the drop down arrow will immediately open the drop down and allow selecting an item.

•

Drop downs have a header allowing sorting its content by clicking on the header. Drop downs also allow typing a few characters which will auto-search the first matching entry.

•

To perform multi-selections – when allowed, e.g. to perform a batch deletion, use the Shift key and make sure to select rows using the row selector to the left of the row, otherwise you will only select cells and one row at a time.

•

When a cell is selected, its background color is slightly lighter than the regular highlight color. This is the current cell that will enter in edit mode if pressing F2. Note that F2 will not enter edit mode if a row is selected rather than a single cell.

•

There is a context menu accessible via mouse right-click over each grid where additions and deletions are permitted, allowing performing add and delete actions right from the grid.

•

It is also possible to delete selected rows using the Delete key.

The encryption tables tab presents sets of encryption tables used to encrypt or decrypt messages. To add a table set simply press the Add button (or use the context menu Add option), type a name for the table set and hit the Enter key or click elsewhere. To delete a table set select it using the row selector (left of the grid) and either use the Delete button, hit the Delete key or select the Delete option from the context menu by right-clicking over a message type set in the grid. An encryption table is a set of characters spread over a series of columns and is used by ASP to encrypt uplinks destined to Honeywell avionics or decrypt downlinks from Honeywell avionics. Each row index in this table corresponds to the decode key used to encrypt or decrypt a message. This decode key is specified by the aircraft in encrypted downlinks and randomly generated (between 1 and 9) by ASP for encrypted uplinks. The first row (0) is a reference row, thus when specifying a decode key of 0, no encryption is performed. In the case where an avionics would support multiple encryption tables, it can be configured by unchecking the “Single table encryption” check box. When doing so, it is possible to define up to 10 different encryption tables (indexed 0 to 9) using the dropdown box to display and configure each of the 10 tables. By default, the 10 tables are pre-

136

ASP Administrator Guide Version 6.9a

configured with 10 reference rows. Indeed, if the decode key specified points to a row identical to the reference row, it provides no encryption, as if a decode key of 0 was used. Note that the ground table(s) must be an inverted copy of the on-board table(s) (see Invert button below), thus each table should be properly configured relatively to what is loaded on-board the aircraft that will use this table set. When processing messages, the encryption table index used by ASP must be the same as the index currently configured on-board the aircraft. The aircraft should send a downlink containing the table index it currently uses. The table index can be extracted from the downlink and stored by ASP by defining a simple downlink template containing a field of type “Honeywell - Encryption Table Index”. When ASP will receive such a downlink, it will store and track the table index currently used by the aircraft. Similarly, a field of type “Honeywell - Encryption Enabled” in a downlink allows an aircraft to tell ASP that encryption has been turned off on-board the aircraft, thus disabling the encryption processing on the ground. Many table sets can be defined to address different aircraft configuration in the fleet. These can also be used to support gradual configuration changes among these aircraft. Finally, basic rules are applied to validate a table, and if a character in the table does not respect these rules, the corresponding cell’s background color will turn red with a tooltip explaining what is wrong. When at least one table has invalid cells for a table set, an icon will show up in the table set grid next to the name and a tooltip explains the problem. Invert: Invert needs to be used if the table configured is an exact copy of the table configured on-board the aircraft. If so, the table must be inverted, because the on-board and ground tables have to be an inverted version of each other. Import: Can be used to import an encryption table from a tab-delimited file into the currently displayed table. That is, each character separated by a tab character and each row on a different line. The grayed-out columns (e.g. column 0) need not be in the tabdelimited file; only the editable columns need to be present. The first row in th e file has to be the reference row and will be used to properly order the columns, thus they need not be in the exact order shown in the grid below. Pasting a table copied from a tabdelimited format is also supported (right-click over the table grid and select paste or CtrlV). Export: Can be used to export the currently displayed table to a tab-delimited file, each character / column separated by a tab and each row on a different line, with the first row being the reference row (index 0). Copying a table and then pasting it into a text file generates a tab-delimited format (right-click over the table grid and select copy or Ctrl-C).

137

ASP Administrator Guide Version 6.9a

Figure 5.47: Honeywell Encryption Configuration - Tables Sets

The message types tab presents sets of message types to encrypt or decrypt. To add a message type set simply press the Add button (or use the context menu Add option), type a name for the message type set and hit the Enter key or click elsewhere. To delete a message type set select it using the row selector (left of the grid) and either use the Delete button, hit the Delete key or select the Delete option from the context menu by right-clicking over a message type set in the grid. Downlinks to be decrypted are identified by their SMI. Typically, it would be M1L, the basic user defined downlink format. These messages can be different types of messages wrapped into an M1L format with a specified header containing, among others, encryption information needed by ASP to decrypt the downlink if needed to. This message is properly generated by the avionics when configured on-board the aircraft. When ASP receives a downlink from an encryption enabled aircraft (see ACARS MU section 5.6 and Fleet Configuration section 5.3) with an SMI included in this list as per the message type set associated to that aircraft (Aircraft List tab), ASP will parse the message and try to decrypt it. If successful, regular downlink processing will be applied on the decrypted message starting with template identification. If unsuccessful, an event will be logged and the downlink will be processed as-is. To add an SMI simply press the Add button (or use the context menu Add option), type a SMI and hit the Enter key or click elsewhere. To delete a SMI select it using the row selector (left of the grid) and either use the Delete button, hit the Delete key or right-click over a SMI in the grid and select the Delete option. For uplinks however, you may pick from the list of uplink templates defined in the system. These messages can be of many different types and will be wrapped by ASP into an M3L

138

ASP Administrator Guide Version 6.9a

uplink, the basic user defined uplink format, with the properly specified header containing, among others, encryption information needed to decrypt the uplink on-board the aircraft. When an uplink processed by ASP is listed here for an encryption enabled aircraft, ASP will analyze the resolved model configured for its distribution and try to identify a valid M3L format. The M3L format, among others, contains a customer message sequence number and an encryption decode key and can be of 5 different types (type code 1 to 5). If the model is a valid M3L ASP will at least generate a customer message sequence number for it. Then, if the type code found in the model is 3 or 5, these types support encryption. So if the “Encrypt” check box is set next to the template selection in the current configuration and the type code found in the resolved model is 3 or 5, ASP will generate a random decode key and encrypt the message. If the check box is not set for type codes 3 or 5, then the decode key will be 00 and the message will be sent as an M3L unencrypted message. Events will be logged when, for example, an uplink template is configured and “Encrypt” is checked, but say the resolved model is not a type code 3 or 5 M3L message, or if it is simply not an M3L format. In these cases, ASP will process the uplink as-is and log an event. To add an uplink template simply press the Add button (or use the context menu Add option), select the appropriate uplink template from the drop down, make sure the Encrypt check is set as desired and hit the Enter key or click elsewhere. To delete a template select it using the row selector (left of the grid) and either use the Delete button, hit the Delete key or right-click over a template in the grid and select the Delete option. Many message type sets can be defined to address different aircraft configuration in the fleet. These can also be used to support gradual configuration changes among these aircraft.

139

ASP Administrator Guide Version 6.9a

Figure 5.48: Honeywell Encryption Configuration – Message Type Sets

DFM Flight Routes Event Handling Window The Flight Routes Event Handling window is available through the Main window ‘Aircraft’ dropdown button, ‘Flight Routes Event Handling’ option, and via the Operations menu. It allows the configuration of flight routes and event handling used for the Dynamic Frequency Management (DFM) feature to a user having the right Manage DFM. The flight routes exist to specify events for the DFM option to perform defined actions at the appropriate time. DFM operates for a specific aircraft flying a specific flight route. When a configured event occurs for an aircraft flying the route, the actions defined for the event are executed. Ultimately, the purpose is to dynamically control which service provider is used by the aircraft to communicate with the ground.

140

ASP Administrator Guide Version 6.9a

Figure 5.49: Flight Routes Event Handling Window – Folder

Figure 5.50: Flight Routes Event Handling Window – Flight Route

141

ASP Administrator Guide Version 6.9a

5.8.1.

Function Description

The following describes the available window functions. Function Refresh (F5)

Find (Ctrl-F) Find Next (F3) New (Ctrl-N) Duplicate (Ctrl-D)

Modify (Ctrl-M)

Delete (Del)

Save (Ctrl-S)

Cancel (Ctrl-Z)

Close (Ctrl-L)

Description In view mode: refreshes the full list of folders and flight routes, along with areas, users, and frequency sets used when defining events and their actions. In edit mode: refreshes only areas, users, and frequency sets. Available in view mode only. Allows searching flight routes based on their basic properties: route name, active, departure and arrival airport codes and description. The Find does not allow searching through folders. Allows creating a new flight route or a new folder. Allows duplicating a flight route (cannot duplicate a folder) and all its associated events and actions. The newly created route is then in edit mode and inactive by default and can be saved or cancelled. The name of the duplicated route is automatically prefixed by “Copy (x) of “. Allows modifying an existing flight route or a folder. To modify only the name of a folder, it can be done using the “F2” keyboard shortcut when the folder is selected in the tree structure. To modify all other folder properties, use the Modify button or “Ctrl-M”. Allows deleting the currently selected flight route, or a folder and all its content after user confirmation. The confirmation is required on every delete, even though the deletion is really permanent with the Save operation.. Allows saving all modifications made since the last new or modified; delete is permanent once the confirmation dialog has been acknowledged. It is enabled as soon as the New or Modify, button has been pressed. Allows canceling any changes made since the last new or modify; delete is permanent once the confirmation dialog has been acknowledged. It is enabled as soon as the New or Modify button has been pressed. Closes the window. Table 5-34: Flight Route Event Handling Functions

The root folder named “Flight Routes” cannot be renamed or deleted. However, it can be modified including defining events and actions that all other folders and routes will inherit. Folder Definition A flight route folder is composed of the following data. Name: A name of maximum 50 characters used to identify the folder. The folder name is mandatory. Description: A short description of the folder (maximum 1000 characters). Flight routes events and actions: See events and actions definition topic below. Flight Route Definition A flight route is composed of the following data.

142

ASP Administrator Guide Version 6.9a

Active: A check that makes the flight route active or not for DFM handling. When the route is active, it is considered for DFM when a DFM enabled aircraft flies that route. Otherwise the route is ignored. Name: A name of maximum 50 characters used to identify the route. The route name is optional, but when specified, it must be unique among all configured routes. Description: A short description of the flight route (maximum 1000 characters). Departure / arrival airports: Two ICAO codes representing the origin and destination airports for the flight route. Next to the ICAO code field, the airport is named if it exists in the ASP ICAO airport lookup table; if the code is unknown, it displays “Invalid or unknown airport code (check code or ICAO lookup table)”. Missing codes can be added in the ICAO lookup table by a ‘Lookup tables and custom fields’ administrator. A duplicate route, that is with the same departure and arrival airports as an existing one, is allowed, but only one of these routes can be active at any time. Both airports are mandatory (even though the system does not know the airport, as long as a valid 4 characters code is specified) and the departure and arrival codes must be different. Airport codes allow the use of wildcard characters (‘?’). When wildcards are used, the codes can match a range of real airports. Here is an example of airport code specificity to determine in which order codes are matched to real airports. The below are listed from most specific to less specific. Basically, left-most characters have more weight than right-most ones. •

CYUL

•

CYU?

•

C???

•

????

The use of wildcards affect the rules stated above as follows: • An airport code with 4 characters containing 0 to 3 wildcards shows “Multiple airports” in place of the airport name. • An airport code with 4 wildcard characters shows “All airports” in place of the airport name. • The departure and arrival airport codes can be identical when they contain wildcards. Flight routes events and actions: See events and actions definition topic below. Events & Actions Definition

143

ASP Administrator Guide Version 6.9a

An event with its actions is created or modified through the Flight Route Event and Actions dialog (described below). However, the sum of all events for a route or folder is displayed in the Flight Route Events & Actions grid. When an event is defined for a folder, the purpose is to reuse the same event in all flight routes defined under that folder (see Events & Actions Inheritance topic below). Adding an event ( ): Use the Add event button, the “Ins” keyboard shortcut, or use the context menu (right-click over the grid). It opens the Flight Route Event and Actions dialog with the default event “At stage Init” selected and all actions unchecked. Once exiting the dialog with OK, a new event is created, and if it is the same as an existing inherited event (including the same event parameter if applicable), the inherited event is then overridden. Editing an event ( ): Use the Edit event button, the “F2” keyboard shortcut, double-click an event in the grid, or use the context menu (right-click over the grid). It opens the Flight Route Event and Actions dialog with the event and actions as currently set. When editing an existing event (inherited or already overridden) the event and its parameter (if applicable) cannot be changed. Only the event condition and the actions can be changed. When editing an inherited event, when exiting the dialog with OK, a new event is automatically created that overrides the inherited one. Removing an event ( ): Use the Remove event button, the “Del” keyboard shortcut when an event is selected and the grid has the focus, or use the context menu (right-click over the grid). For the remove behavior with inherited events, refer to the Events & Actions Inheritance topic below. All changes to events (additions, modifications, or deletions) are saved or cancelled at once with Save or Cancel operations. Events & Actions Inheritance Events and their actions can be created at a folder level. Although folder settings will never be used directly in the DFM handling, any route within a folder inherits the events and actions of all its parent folders. At any level along the way (in a folder or route), an inherited event can be overridden simply by editing the inherited event or creating a new event with the same parameter (like “Enter area China”). An event is overridden when the current level uses the same "flight route event" and "equipped with" as a parent folder, though with different actions. Inherited events are shown grayed out in the Flight Routes Events & Actions grid and the “Level” column is smaller than the level at which the route is defined (counting down from the root folder at level 1). Events defined at the current level (overridden or not) are in black with the “Level” column set to the current level. Events are always listed in the order in which they are inherited, from level 1 at the root folder to the last level at the event. When removing an overriding event, let’s say for a route, and the same event does not exist in a parent folder, the event is physically removed from the events grid. But if the 144

ASP Administrator Guide Version 6.9a

same event exists in a parent, the event turns grayed out with the level returned to where it was inherited from and the actions are those from the inherited event. To remove an inherited event without removing it from the parent (because we still want to inherit from it in other routes or folders), simply edit the event (or create a new event with the same parameter) and leave all actions blank. Flight Route Event & Actions Dialog This dialog allows editing one event with its actions. A few events require specifying a parameter like “At stage” which requires specifying the flight stage. All actions are available for any of the events. When checking an action, the associated parameter (if applicable) must be specified. The same event (like “Leave FE area Japan”) can coexist in the same route or folder as long as the condition is different (any, SAT or NO SAT). Hence, two entries for the same event with the same condition are not allowed. The condition filters whether or not an event will be triggered for some aircraft depending on their SAT equipped property. If an event occurs for a route flown by a SAT equipped aircraft, the event will fire if the event condition is any or SAT, similarly for non-SAT equipped aircraft, events will fire if the condition is any or NO SAT.

Figure 5.51: Flight Routes Event & Actions Dialog

145

ASP Administrator Guide Version 6.9a

Available events: At stage: Rose when an aircraft flying a route has sent a downlink for the specified flight stage (Init, Out, Off, On, In, or Summary). Diversion: Rose when an aircraft flying a route has diverted to a new destination while in flight (in the “Off” flight stage). The actions executed for this flight will continue to be based on the initial flight route despite the new destination. ARINC Downlink: Rose when a downlink has been received from a service provider attributed to ARINC (not configured as a “SITAONAIR DSP”). Enter area: Rose when an aircraft has entered the specified area configured in FlightTracker Map Area Manager window. Leave area: Rose when an aircraft has left the specified area configured in FlightTracker Map Area Manager window. Scan table uplink failed: Rose when a scan table uplink for a new frequency set failed to be delivered to the aircraft (and expired). Subsequent reject (REJ) messages are ignored. Scan table uplink successful: Rose when a scan table uplink for a new frequency set has been delivered successfully to the aircraft. Subsequent reject (REJ) messages are ignored. Auto-tune uplink failed: Rose when an auto-tune uplink for a new frequency failed to be delivered to the aircraft (and expired). Subsequent reject (REJ) messages are ignored. Auto-tune uplink successful: Rose when an auto-tune uplink for a new frequency has been delivered successfully to the aircraft. Subsequent reject (REJ) messages are ignored. ARINC Downlink from: Rose when a downlink has been received from a service provider attributed to ARINC (not configured as a “SITAONAIR DSP”) and that the VHF station from which it was received is an item in the selected lookup table. ARINC Downlink not from: Rose when a downlink has been received from a service provider attributed to ARINC (not configured as a “SITAONAIR DSP”) ”) and that the VHF station from which it was received is NOT an item in the selected lookup table..

146

ASP Administrator Guide Version 6.9a

Available actions: Notify users: Same action as for templates event handling, that is notify one or more users configured in AIRCOM® ServerPlatform by sending them a notification message stating the event that just occurred. Send scan table uplink with frequencies [x]: Sends an uplink message generated based on the predefined uplink template “Frequency Scan Table Update”, using the model assigned for distribution to the flying aircraft. The model “{@SCAN FREQUENCIES} predefined field is replaced by the proper scan table frequency string, which is determined using the frequency set specified as the action’s parameter. A scan table frequency set specifies different frequency string formats for different ACARS MU. Therefore, the proper frequency string is the one matching the ACARS MU of the flying aircraft. Send auto-tune uplink for frequency [x]: Sends an uplink message generated based on the predefined uplink template “Frequency Auto-tune”, using the model assigned for distribution to the flying aircraft. The model “{@TUNE FREQUENCY} predefined field is replaced by the proper auto-tune frequency string, which is determined using the frequency set specified as the action’s parameter. An autotune frequency set specifies different frequency string formats for different ACARS MU. Therefore, the proper frequency string is the one matching the ACARS MU of the flying aircraft. Send uplink [x]: Sends an uplink message based on any computer-generated uplink template of the generic category. Appropriate models and distribution must be set for the destination aircraft. Send event number [x] to FE: Sends the specified event number to FE. Refer to the FE help under 3rd Party Customized Events topic for details on events configuration. Change FE aircraft priority to [x]: Changes the aircraft priority tag in FE. To use the aircraft priority in FE, refer to FE Plane filters configuration or search for “priority” and “plane priority” in FE help system. Stop Dynamic Frequency Management (DFM) until end of flight: Stops all DFM processing for the current flight route and for the current flight. Event & Action Sequencing Events are triggered by the reception of downlink messages from the aircraft under DFM or from entering or leaving areas. In some circumstances, more than one event can be triggered simultaneously. The rules in event execution order and actions execution are stated below.

147

ASP Administrator Guide Version 6.9a

•

If more than one event is triggered for one situation, the events are processed in the order they are presented in the “Flight Route Event & Actions” dialog, from level 1 to 4.

•

The stop DFM action is always the last action to occur within a single event, and all subsequent events are dropped (e.g. a message triggers “At stage On” event and “Downlink from ARINC”, and “At stage On” includes a stop DFM action, the “Downlink from ARINC” event will be ignored).

•

After a stop DFM action, DFM processing is stopped. However, pending scan table update or auto-tune uplinks will be fully processed.

•

If more than one event is triggered for one situation, only the notify users and send event number to FE actions can be executed for multiple events. For the other actions, only the first occurrence of the action is executed, the one at the lowest level. For example, if an event at level 1 says to send scan table "All frequencies" and one at level 3 says to send scan table "North-America", it is the "All frequencies" scan table that will be sent if both events trigger at the same time.

•

If more than one event is triggered for one situation and the first event to be processed includes a send auto-tune action while the next event includes a send scan table action, the send scan table is always processed before the send autotune (except if the first event also includes a stop DFM, in which case the send auto-tune is processed and send scan table is ignored).

148

ASP Administrator Guide Version 6.9a

DFM Frequency Sets Window The DFM Frequency Sets window is available through the Main window ‘Aircraft’ dropdown button, ‘DFM Frequency Sets’ option, and via the Operations menu. It allows viewing all scan tables and auto-tune frequency strings for various flights and various ACARS MU avionics, and it can be defined by a Dynamic Frequency Management (DFM) administrator.

Figure 5.52: Dynamic Frequency Management – Frequency Sets Window

Scan table updates are used to enable/disable specific frequencies in an aircraft’s scan table such that some frequencies are not tried when the aircraft needs scanning its table to establish communication with ground stations. Example of frequency scan table update strings for different MU: D131550XA/E131725XS/D131550XS/D130750XS/D131450JD/E136850XS/D131450XA/D130600XS/D122900XS/D1 36925XA/E131550XB/D131725XA/D122900DA/D131450CA/D131725XA/D131475XC/

Or: /////////////////1/1/1/0/0/1/1/0/0/

An auto-tune message asks the aircraft to tune a specific frequency. Example of a typical frequency auto-tune string: 131550XS

149

ASP Administrator Guide Version 6.9a

When a DFM flight route event triggers a send scan table or a send auto-tune uplink action, the action parameter specifies a frequency set. The frequency set defines the same frequency settings in different formats such that the different avionics can interpret it correctly. The avionics equipment is the ACARS MU and each aircraft must have its ACARS MU property specified for the DFM actions to work. This way, the system knows which string format to use for each DFM enabled aircraft. If the frequency string is generic enough to be the same for all or most MU, it can be specified for “(any)” ACARS MU. For an aircraft with an MU that is not specified in a frequency set, if a frequency string for “(any)” MU is configured, it will be used.

5.9.1.

Function Description

The following describes the available window functions. Function Refresh (F5) New Auto-Tune New Scan Table (Ctrl-N) Duplicate (Ctrl-D)

Modify (Ctrl-M)

Delete (Del)

Save (Ctrl-S) Cancel (Ctrl-Z) Close (Ctrl-L)

Description In view mode: refreshes the full list of frequency sets along with ACARS MU. In edit mode: refreshes only ACARS MU. Allows creating a new frequency set of type auto-tune or scan table. The default if clicking the New button or using Ctrl-N is New Auto-Tune. Allows duplicating a frequency set and all its associated frequency strings. The newly created set is in edit mode and can be saved or cancelled. The name of the duplicated set is automatically prefixed by “Copy (x) of “. Allows modifying an existing frequency set. Once a new, modify of delete operation has been done, Modify is disabled until the next Save or Cancel operation. Allows deleting the currently selected frequency set after user confirmation. The confirmation is required on every delete, even though the deletion is only permanent with the Save operation. Allows saving all modifications made since editing started. It is enabled as soon as the New, Modify, or Delete button has been pressed. Allows canceling any changes made since the last new, modify, or delete operation. Closes the window. Table 5-35: DFM Frequency Sets Functions

The window is multi-edit, which means any editing operation like new, modify, or delete puts the window in edit mode and subsequent additions, modifications or deletions will all be saved or cancelled at the same time. Frequency Set Definition A frequency set is composed of the following data. Type: A frequency set is either defining scan table or auto-tune frequency strings. This type is determined by doing a New Scan Table or a New Auto-Tune and the type is only displayed in the list of frequency sets (left-most part of the window).

150

ASP Administrator Guide Version 6.9a

Name: A name of maximum 50 characters used to identify the frequency set. The name is mandatory. Description: A short description of the frequency set like “Enable SITAONAIR frequencies for the US but not 131550” (maximum 1000 characters). DFM frequency strings: See topic below. Frequency Strings Definition A frequency string applies to either a scan table or auto-tune uplink. For a scan table message, it specifies the frequencies to enable and those to disable in the aircraft’s avionics scan table. For an auto-tune message, it specifies the frequency to tune. Frequency strings are managed via the DFM Frequency Strings grid. ACARS MU: A dropdown listing the configured ACARS MU (refer to the ACARS MU window), and “(any)” (default selection for a new string). The “(any)” entry allows configuring a generic string used for any ACARS MU in case no string is defined for a specific ACARS MU. Only one string per ACARS MU (including “(any)”) is allowed per frequency set. Frequency String: A specific frequency string (maximum 512 characters). The frequency string is mandatory. Adding a string ( ): Use the Add button, the “Ins” keyboard shortcut, or use the context menu (right-click over the grid). It adds an empty string for “(any)” ACARS MU. Editing a string: Select an entry in the grid and change it. Removing a string ( ): Use the Remove button, the “Del” keyboard shortcut when an entry is selected and the grid has the focus, or use the context menu (right-click over the grid). It removes the strings from the grid. All changes to frequency strings (additions, modifications, or deletions) are save or cancelled at once with Save or Cancel operations.

151

ASP Administrator Guide Version 6.9a

Flight Events Handling Window The Flight Events Handling window is available through the Main window ‘Aircraft’ dropdown button, ‘Flight event handling…’ option, and via the Operations menu. It allows configuring actions to be executed whenever flight events happen, based on execution criteria. For the window to be available, FlightTracker Alerting license option and Manage flight events right are required. Depending on the event type, other license options may be required.

Figure 5.53: Flight Events Handling Window

'Flight Events Handling' completes the functionality offered by the 'DFM Flight Route Event Handling' window. In the current version, the two windows are still separated, but in the coming releases the DFM events and actions will be merged with those of this window. There are some differences between this 'Flight Events Handling' window and its DFM counterpart: •

In this window, an event is not a single occurrence but a lasting condition that raises and closes. It is raised on an aircraft when the event criteria are met and stays in that state as long as it is the case. When the event criteria are no longer met, the event closes.

•

The actions for the raise and close events are configured as part of the same event rather that separately for the raise and the close.

•

When an event is raised or closed, all action sets matching the aircraft with their execution criteria are executed instead of executing only the action set having the most restrictive execution criteria (the "route" in the case of DFM).

152

ASP Administrator Guide Version 6.9a

An event starts to be tracked by the system as soon as the first active action set is saved for that event. It is evaluated against all aircraft, even those not matching execution criteria. Adding an active action set to an event will not trigger raise actions for aircraft for which the event is already raised.

5.10.1. Function description The following describes the available window functions. Function Refresh (F5)

New event (Ctrl-N-E) New action set (Ctrl-NA) Modify (Ctrl-M)

Delete (Del)

Save (Ctrl-S)

Cancel (Ctrl-Z)

Close (Ctrl-L)

Description In view mode: refreshes the full list of events and action sets, along with aircraft and aircraft types. In edit mode: refreshes only aircraft and aircraft types. Allows creating a new event. The event type depends on the folder. Allows creating an action set to an event. Allows modifying an existing event or action set. When an event is modified, it may be raised on aircraft that were not matching former event criteria and it will be closed for aircraft no longer matching event criteria. Allows deleting the currently selected event or action set. When an event is deleted and alerts are still raised for that event, alert notifications are sent to update the Alerts notifications in FlightTracker Map. A deleted event is, or course, no longer tracked. It is enabled as soon as the New or Modify button has been pressed. Allows saving all modifications made since the button was pressed. If the operation was to add an event, then a first action set becomes editable in adding mode. It is enabled as soon as the New or Modify button has been pressed. Allows canceling all changes made since the button was pressed. Data is reloaded. Closes the window.

5.10.2. Available events For all event types, the configuration must be unique. For example, two Enter / leave area events cannot use the same area or two Lateral deviation events cannot have the same threshold.

153

ASP Administrator Guide Version 6.9a

5.10.2.1. Enter / leave area Enter / leave area events can be configured to identify aircraft entering and leaving any area defined in the FlightTracker Map. To configure Enter / leave area events, FlightTracker Areas license option is required.

Figure 5.54: Flight Events Handling Window - Enter / leave area

For the enter / leave area event to be raised or closed on a flight, the conditions are the following: •

The flight must be in the "Init" stage or at a later stage, on the ground or in-flight.

•

The aircraft must be inside the area, based on either a reported or estimated position.

•

If the area has an altitude lower or upper bound, or both, then the last known altitude of the aircraft must be inside those bounds. If no altitude has been reported in the flight, the event will not raise for altitude-bound areas, except when an area which has no lower bound (0 ft) includes the departure airport. An aircraft on the ground is considered within an area that has no lower bound.

•

If the area has a validity period, the event will raise for the aircraft within it only when the area is within its validity range. If the aircraft is already inside an area when its validity period starts, the event is raised. Likewise, if the aircraft is inside an area when its validity period ends, the event is closed.

154

ASP Administrator Guide Version 6.9a

5.10.2.2. Flight Route - Alerting (FR-A) Flight Route Alerting events are used to alert when weather conditions are identified on the flight plans received from a flight planning system for display on the FlightTracker Map. To configure Flight Route Alerting events, the Weather and the FR-A license options are required. The weather conditions that are monitored for the FR-A depend on the category of the aircraft flying the submitted flight plan and the alarms configured for it. There are two sets of alarms and thresholds defined for each category of aircraft: “advisory” (low thresholds) and “warning” (high thresholds). Both levels can be configured in the Flight Events Handling window, each with its own actions.

Figure 5.55: Flight Events Handling Window – Flight Route - Alerting

Once a flight plan is received and decoded by the system, it is submitted to DTN for monitoring. From thereon, any weather condition exceeding the set threshold, new or updated, is identified as an advisory and/or a warning that will raise the corresponding event and execute its actions. The monitoring of the flight plan continues for the duration of the flight, until landing, and will consider any modification made to that flight plan as well as delays to the flight and ETA updates. For the FR-A event to be raised or closed on a flight (planned or active), the conditions are the following: •

Your account with DTN (the weather provider) must include the FR-A option.

•

A flight plan with waypoint coordinates must be associated with the flight.

•

The flight plan must have been received from a flight planning system (decoded with a template) and not received from FlightAware (flight plans from FA are never submitted for FR-A).

•

The FRA_IN and FRA_OUT links must be connected and DTN’s service available. 155

ASP Administrator Guide Version 6.9a

•

Weather advisories or warnings must have been received for the flight plans submitted to FR-A.

Refer to section 9.2.12 “Using Flight Route - Alerting” below for the full details on the use of FR-A.

5.10.2.3. Lateral deviation Lateral deviation events are used to identify flights deviating laterally (sideways) from their flight plan using a configurable threshold in nautical miles.

Figure 5.56: Flight Events Handling Window - Lateral deviation

For the lateral deviation event to be raised or closed on a flight, the conditions are the following: •

A flight plan with waypoint coordinates must be associated with the flight.

•

The flight must be in the "Off" stage.

•

The flight must be at least 50 NM away from its departure and arrival airports – this allows flights to divert from their flight plan during takeoff and approach phases without raising alerts.

•

The flight must not have been diverted to an alternate airport.

•

The deviation must be greater than the configured threshold.

The lateral deviation is the calculated distance between the aircraft's last reported position and the closest segment on its flight plan (estimated positions are not used in this calculation).

156

ASP Administrator Guide Version 6.9a

5.10.2.4. No reported position The "No reported position" events are used to identify flights that did not report their position in a given delay using a configurable threshold in minutes. It is a simpler alternative to the Sequencer's "Position reported / not reported" condition which requires more configuration.

Figure 5.57: Flight Events Handling Window - Lateral deviation

The event starts being monitored from the moment the aircraft takes off, with the off time considered as the first position from which the "no reported position" is evaluated. The event then raises when the time of the last position exceeds the specified delay and closes when a new position is received or when the aircraft lands. The reported positions include every source of positions; either directly from the aircraft as ACARS, ADS-C, CPDLC positions or from a separate feed (such as FlightAware) as ADS-B or radar positions.

5.10.2.5. Vertical deviation Vertical deviation events are used to identify flights deviating above or below their planned altitude using configurable thresholds in feet.

157

ASP Administrator Guide Version 6.9a

Figure 5.58: Flight Events Handling Window - Vertical deviation

For the lateral deviation event to be raised or closed on a flight, the conditions are the following: •

A flight plan with waypoint coordinates and altitudes must be associated with the flight.

•

The flight must be in the "Off" stage.

•

The flight must be at least 50 NM away from its departure and arrival airports – this allows flights to divert from their flight plan during takeoff and approach phases without raising alerts.

•

The last reported position must be within 100 NM of its flight plan.

•

The flight must not have been diverted to an alternate airport.

•

The vertical deviation must be greater than the configured threshold, above or below its flight plan.

The vertical deviation is the calculated difference between the aircraft's last reported altitude and the planned altitude on the closest segment on its flight plan (estimated positions are not used in this calculation).

158

ASP Administrator Guide Version 6.9a

The "normal" altitude range depends on where the aircraft is on the flight plan and the configured thresholds. When flying between waypoints of equal altitude, the aircraft's normal altitude is that of the waypoints. When transiting between waypoints of different altitudes, the normal altitude is anywhere between the planned altitudes of the two waypoints (all the way to ground level if one of the waypoint is the departure or arrival airport). Waypoints that don't have an altitude specified or are marked as ascent (ASC) or descent (DSC) are considered to be between the waypoints that have an altitude. The vertical deviation is then calculated from the normal altitude after adding and subtracting the configured thresholds. Here is an example of what valid altitude ranges may looks like for a flight:

Figure 5.59: Vertical deviation valid altitude range

159

ASP Administrator Guide Version 6.9a

5.10.3. Action sets Action sets are a combination of execution criteria and actions. If execution criteria are met for an aircraft: •

When the event is raised, the raise actions (left hand-side panel) are executed for that aircraft.

•

When the event is closed, the close actions (right hand-side panel) are executed for that aircraft.

If many action sets of an event are executed at once for an aircraft, there are special rules depending on what the action is. The description of each action contains those rules.

Figure 5.60: Flight Events Handling Window - A 2nd action set

5.10.4. Available actions Notify user(s) Use this action to send notifications to selected users whenever the related event is raised or closed. The text of the notifications sent will include the event description and the relevant information that caused it to be raised or closed. By default, the users selected for the raise action are also selected for the close action but after that, you can always change the list of users separately.

160

ASP Administrator Guide Version 6.9a

If a given message causes several events to be raised or closed at the same time, the notify actions for all events will be executed. If the same user is configured in different notify actions, the event descriptions will be cumulated in one message. Raise alert Use this action to display alert notifications on the FlightTracker Map whenever the related event is raised and closed. The alerts raised on flights will be visible in the Aircraft Tracking and FlightTracker Map windows in the Alerts panel. On the FlightTracker map, alerts will also display as notifications on top of the map; colored with the level of the alert when raised, gray when closed. Alerts close when the condition leading to the event rising no longer exists, when a user manually closes it, when the flight completes or when the event is deleted by a user. Flights having alerts will be shown on the map and in the aircraft list with a colored circle around them. When multiple alerts are raised for the same aircraft, the color of the highest one will be used. Send uplink Use this action to send an uplink to the aircraft for which the event is raised or closed. The text of the uplink sent will include the event description and the relevant information that caused it to be raised or closed. If this action is executed from many action sets at once, every selected template will be sent to the aircraft, but only once.

161

ASP Administrator Guide Version 6.9a

AFDAS Fault Management Window The AFDAS Fault Management window is available through the Main client window ‘Aircraft’, ‘Fault Management’ option, from the Aircraft Tracking window, Faults (AFDAS) panel, ‘Management’ button, and via the Operations menu. The window allows a user with the right Manage AFDAS Faults to view and maintain all aircraft faults.

Figure 5.61: AFDAS Fault Management Window

ACARS Fault Detection and Alerting System (AFDAS) Fault Management applies only to Boeing aircraft. The configuration is providing the system with all the necessary aircraft fault definitions (e.g. severity, description, alarm thresholds), configured per fault group. It is important not to confuse aircraft type and fault group. Although the two concepts tend to look similar, a fault group is a separate entity. Each defined aircraft type (Boeing only for now) need to match an existing fault group in order for the system to find the appropriate faults reported by each aircraft; this is done via the Aircraft Types window (section 5.4). Each fault group can match many similar aircraft types. Aircraft transmit faults typically via either Present Leg Fault (PLF) or Real-Time Event (RTE) reports, for which proper downlink templates of the category “Fault Report (AFDAS)” must have been defined. These templates contain specific fields allowing the system to identify the reported faults, among others their occurrence time, to monitor them via the Aircraft Tracking window (refer to document [S4b]) and to notify users when fault occurrences reach configured thresholds.

162

ASP Administrator Guide Version 6.9a

There is no prerequisite to define fault groups and faults, but to be able to complete the notification and escalation user lists (via the AFDAS Fault Notification window, section 0), the users to notify must have been defined.

5.11.1. Function Description The following describes functions of the AFDAS Fault Management window 7. Function Refresh

Find (Ctrl-F and F3)

New Modify

Delete Save Cancel

7

Description In view mode, refreshes everything (fault groups, faults, notification and escalation lists), but in edit modes, refreshes only the notification and escalation lists. Allows searching for a fault code, description, type, or severity, as well as for a notification or escalation count or period. The Find dialog adjusts its display according to the ‘Search In’ selection data type. The string search occurs anywhere in the data element string (e.g. searching for ‘B7’ in ‘B777’ or ‘B747’ is a match). The search is by default case insensitive, unless the ‘Match Case’ option is checked. As long as the Fault Management window stays opened, the ‘Find What’ lists the searched strings history since the window was opened for quick pick. The keyboard key combination ‘Ctrl-F’ opens or brings to the front the Find dialog. The ‘F3’ key performs a ‘Find Next’ (same as the button in the dialog) on the last specified search criterion, no matter if the dialog is opened or not. The search cycles through the matching faults. The ‘Find’ function is available in view mode or in edit modes. Creates a new fault group with no existing faults. Can add as many faults as desired and save them all at once in a single save click. Modifies the currently selected fault group. Can edit all faults of a group in the same edit session (i.e. add, remove, or modify existing faults) and save or cancel the changes at once with a single save or cancel click. Deletes the currently selected fault group and all its faults. Requires a user confirmation. Saves any changes performed since the last new or modify operation. Cancels any changes since the last new or modify operation.

Most functions are also available via a context-sensitive menu obtained by right-clicking over the list of faults. 163

ASP Administrator Guide Version 6.9a

Function Import

Description Opens the Import Faults from File dialog, allowing selecting a fault text file to import its fault definition content into the system. Importing is allowed only in edit mode. The file format is as follows: • A ‘;’ indicates a commented line, ignored and not imported. • A comma separates field values. • Text fields like fault descriptions are delimited by “ ”. Long text fields like fault comments may span over multiple lines. File Format Example: ; AFDAS Fault Table for Group "B747" ; ; #fault_code, type, "description", severity(0-4), ; notif_count, notif_time, escal_count, escal_time, ; "comments ... (can span multiple lines)" ; #16000,CMC,"FLAP 26 VAC 3 INTERFACE 5 FAIL",1,2,24,3,48, "Maintenance Memo... Maintenance Tips... " #16002,CMC,"FLAP 26 VAC 3 INTERFACE 3 FAIL",3,2,24,3,48, "Maintenance Memo... Maintenance Tips... " ...

Export

Notify

Close Add Remove Clear Notifications…

Opens the Export Faults to File dialog allowing saving to a text file (formatted as for the Import function) the currently selected fault group. Exporting is allowed only in view mode. Opens the AFDAS Fault Notification window without any specific preselections (same as opening the window via the Main toolbar or Operations menu). The first fault group and the first fault are selected by default. Closes the AFDAS Fault Management window. Adds a new fault to the currently edited fault group. Removes the currently selected fault from the currently edited fault group. Removes all faults of the currently edited fault group. Requires a user confirmation. Opens the AFDAS Fault Notification window with the current fault group and current fault pre-selected, if available. Note that the current fault group and/or fault may not have been saved yet and may not be available from the Fault Notification window, in which case, the first fault group and fault are selected by default. Table 5-36: AFDAS Fault Management Functions

164

ASP Administrator Guide Version 6.9a

5.11.2. Data Description The following describes the data components of the AFDAS Fault Management window. Data Fault Code

Description A fault code is an alphanumerical code of a maximum of 10 characters. Aircraft manufacturers document these codes. Fault codes allow the use of wildcard characters (‘?’). When wildcards are used, a configured fault can match several faults codes. For a given fault code, the system searches the matching fault definition that is the most specific for it. For example, if fault code “16217” is raised, the system will consider the following fault definitions in this order and pick the first one matching: 16217  1621?  162??  1??17  1???7  ?????

Fault Type

Severity

Description Comments

Notification Thresholds

and

Escalation

Basically, left-most characters have more weight than right-most ones. Note that the code length is very important such that, for example, a 3-digit fault code will match only to 3-digit codes, and thus would not match a code like “?????”. The fault type is either FDE (Flight Deck Event) or CMC (Central Maintenance Computer). An FDE fault generally results from many combined CMC faults. The fault severity indicates the fault degree of importance, or criticality, as follows: (none) P5 - Normal (default selection) P4 -Note P3 - Low P2 - Medium P1 - High A relatively short description of the fault. Free text comment that could be used, for example, to describe a procedure in case the fault occurs, and/or to provide additional guidelines and details about the fault. The comments are displayed for each monitored fault occurrence via the Aircraft Tracking window (see document [S4b]). Each fault defines two types of thresholds: notification and escalation. Both thresholds represent the number of fault occurrences within a time period (expressed in hours). Hence, ‘2/48’ means that the threshold is reached when the fault occurs for a second time within 48 hours. Typically, notification thresholds are meant to raise first as a notification that something is wrong, and escalation thresholds rise later indicating that the problem persists and has not been resolved. However, it is very possible that escalation thresholds could rise before any notification, depending on specific configurations (e.g. Notification: 2/10, Escalation: 3/48, and the fault occurs once every 12 hours). In any case, notification and escalation thresholds are monitored via the Aircraft Tracking

165

ASP Administrator Guide Version 6.9a

Data

Notification and Escalation Users (lists)

Description window (see document [S4b]), and it is easy to know which thresholds have been reached or not. These are lists of users to be notified when either the notification or escalation threshold is reached. The lists are read-only from the AFDAS Fault Management window (for reference only) as they are configured using the AFDAS Fault Notification window (section 0).

Users displayed in gray text are not active for distribution, meaning that although they can be configured to receive fault notifications, they will not receive any notification until the users become active again. Table 5-37: AFDAS Fault Data

166

ASP Administrator Guide Version 6.9a

AFDAS Fault Notification Window The AFDAS Fault Notification window is available through the Main Client window ‘Aircraft’, ‘Fault Notification’ option, from the AFDAS Fault Management window, ‘Notify’ and ‘Notifications’ buttons, from the Aircraft Tracking window, Faults (AFDAS) panel, ‘Notifications’ button and via the Operations menu. The window allows a user with the right Manage AFDAS Faults to view and maintain all fault notifications and escalations.

Figure 5.62: AFDAS Fault Notification Window

ACARS Fault Detection and Alerting System (AFDAS) Fault Notification applies only to Boeing aircraft. The configuration is telling the system, for each configured user or group, which faults trigger notification and/or escalation to the user or group. In other words, if a fault reaches its configured threshold for notification for a certain aircraft, then the users or groups listed for notification of that fault receive an AFDAS notification message. Note that users or groups displayed in gray text are not active for distribution, meaning that although they can be configured to receive fault notifications, they will not receive any until they become active again (refer to section 6.1.2 User Data for more details). To define fault notifications, the following is prerequisite:  Users to notify must have been defined.  The desired faults must have been defined.

167

ASP Administrator Guide Version 6.9a

5.12.1. Function Description Same as described in section 4.2.6, Function Description, except for the Find functions described below. Function Find (Ctrl-F and F3)

Description Allows searching for a fault code, description, type, or severity, as well as for a notification or escalation count or period. The Find dialog adjusts its display according to the ‘Search In’ selection data type. The string search occurs anywhere in the data element string (e.g. searching for ‘B7’ in ‘B777’ or ‘B747’ is a match). The search is by default case insensitive, unless the ‘Match Case’ option is checked. As long as the Fault Management window stays opened, the ‘Find What’ lists the searched strings history since the window was opened for quick pick. The keyboard key combination ‘Ctrl-F’ opens or brings to the front the Find dialog. The ‘F3’ key performs a ‘Find Next’ (same as the button in the dialog) on the last specified search criterion, no matter if the dialog is opened or not. The search cycles through the matching faults. The ‘Find’ function is available in view mode or in edit modes. Table 5-38 AFDAS Fault Notification Functions

5.12.2. Data Description The following describes the data components of the AFDAS Fault Notification window. Data Fault Group (list)

Recipient Users (list)

Faults and Notification Types (list)

Notification Type (list)

Description Lists all available fault groups defined via the AFDAS Fault Management window (section 5.1). The selection allows filtering the faults list to a subset corresponding to the fault group. The fault group selection can only change in view mode. The recipients’ list holds all users and groups (all user types) defined in the system. The list can be displayed either to the right or to the left of the window (to the left by default) using the ‘Flip View’ function. List of all faults for the currently selected fault group. The right-most column displays the notification type that is configured for each fault – recipient user pair: Notify Only, Escalate Only, Notify + Escalate.

Using ‘Flip View’, the list becomes ‘Recipient Users and Notification Types’. A list with the three selections: Notify Only, Escalate Only, Notify + Escalate. Use this list to select the desired notification type for the selected faults (or recipients in ‘Flip View’). To set the same notification type rapidly to many different entries, select multiple entries and set the notification type. Table 5-39: AFDAS Fault Notification Data

168

ASP Administrator Guide Version 6.9a

Sequencer Window The Sequencer window is available under the "Aircraft" menu to users having the Manage sequences user right and the option enabled in their system's license.

Figure 5.63: Sequencer Window

The Sequencer serves to resolve problems involving the sequencing and timing of specific actions (such as sending messages) outside the normal flow of messages. With the Sequencer, unrelated messages about a given aircraft can be used together and, when the wanted criteria are met, sent in order to the aircraft or users. Used in conjunction with custom fields that grab data from incoming messages, the Sequencer can be used to build a consistent set of data about aircraft and later reuse it in messages generated on its cue. The types of problems that can be resolved with the Sequencer are, among others: •

Send messages (downlink, uplink or ground) outside of the normal flow of messages;

•

Raise and close custom conditions and alerts on a flight;

•

Accumulate data with custom fields and use it in a determined order;

•

Wait for the right context to do something;

169

ASP Administrator Guide Version 6.9a

•

Relate actions to actual or estimated OOOI times;

•

Notify specific users of the success or failure of actions.

5.13.1. Sequencer Concepts A sequence is a configurable set actions and criterias organized in steps (or activities) to produce wanted scenarios. Each step yields a binary result: either Successful (or true) or Failed (or false) that serves to decide which step should be run after that. This is the key to the Sequencer: the ability to decide what to do next, at each step, based on the result. Steps are placed one after the other but can be arranged, based on the result of the step, to continue to the next step, goto another step or end the s equence. There are 3 types of steps to compose a sequence: •

Action: A unitary action to execute for an aircraft and that will produce a successful or failed result. Actions can raise or close a custom condition on the flight, send an uplink or ground message (ex: send uplink "request position") or can wait for a configured amount of time (ex: wait for 10 minutes).

•

Evaluate if: Criteria are used as a decision point to branch to different steps. The set criteria are evaluated at the moment the step runs and produces a true or false result that will branch to different steps or end the sequence. Criteria can evaluate whether a particular message has been received (ex: uplink message received "loadsheet"), whether a given flight stage has been reached or not (flight stage < "Out"), or whether a given time is passed, not passed or right on the dot (Time is equal to "ETA" - 20 minutes).

•

Wait for: Criteria that will halt the sequence until they are realized. A timeout value can be configured so that it won't wait forever and timeout if the criteria are not realized in time. This is useful to make sure a sequence does things at the right time and when the criteria are appropriate. The criteria here are the same as "evaluate if" but will wait for those instead of giving an instantaneous result (ex: wait for downlink "flight plan request" or timeout after 60 minutes).

Sequences start and stop for an aircraft, by default, at the beginning of any new flight and end at the completion of that same flight, that is, when it actually clears for the next flight. Start and stop criteria can however be configured so that a sequence runs only while it is appropriate. The start criteria ensure that a given sequence won't do anything before proper criteria are in place (ex: flight stage = Off). Likewise, the stop criteria serve to make sure the sequence stops when the criteria are not appropriate to run that sequence

170

ASP Administrator Guide Version 6.9a

anymore (ex: flight stage >= On) and will stop at any step it is as soon as the stop criteria are realized. Each running sequence is attached to an aircraft and work on data that is related to that aircraft (messages, flight times, tracked data and custom fields). Messages used by the Sequencer must therefore always include an association to an aircraft, either by aircraft tail number (AN) or by flight identifier (FI) and optional flight data (orig, dest, ETD). There can be many sequences running at the same time for the same aircraft. Similarly, the same sequence can run independently for multiple aircraft, each one being at a different step in its execution based on where the aircraft is at in its flight. More details are available in section 0, on how to create sequences to resolve complex problems. Three demonstration sequences are also documented and explained.

5.13.2. Sequences Steps The following are the different types of steps you can use in a sequence. ACTION: A unitary action to perform for an aircraft and that will produce a successful or failed result. •

Raise condition + “custom condition name” with “alert level” This action raises a custom condition on the flight. For example, if no position has been reported for more than 15 min, the “No position report for more than 15 min” condition could be raised. The identifier of the custom condition is its name. It is possible to raise many conditions on a single flight, but the same condition may not be raised more than once for a given flight. To pursue with the example, it is possible to raise three conditions on the same flight like “No position report for more than 15 min”, “No position report for more than 20 min” and “No position report for more than 25 min”, but not three times the “No position report” condition. It is therefore suggested to use a descriptive condition name. When a condition is raised, a FlightTracker alert is not necessarily raised. The condition and the alert are two different concepts. However, it is possible to select an alert level other than “No alerting” that will shown in FlightTracker as a flight alert of the set level.

•

Close condition + “custom condition name” This action closes a custom condition on a flight. If the condition is active, it is closed. If an alert was raised with the condition and is still active, it is also closed. Conversely, manually closing an alert in FlightTracker does not close the condition. It is the responsibility of a sequence to close it. The sequence closing the condition may be another sequence than the one who raised the condition.

171

ASP Administrator Guide Version 6.9a

At the completion of the flight, that is, when it actually clears for the next flight, all remaining active custom conditions are closed automatically for that flight. •

Send uplink + {from external user, computer-generated} + “template name” With “from external user” selected: all uplink templates from external user of category “(none)”, “Flight Plan” and “Default” are listed. For this to work, the selected template must be configured with the wait option “when triggered by the Sequencer” so it is not sent right when received. When this action is executed, a message of that template has to be there “Waiting for sequencer” already. With “computer-generated” selected: all computer-generated uplink templates of category “(none)” are listed. When this action is executed, a new uplink using the selected template is created and sent.

•

Send ground message + {computer-generated} + “template name” + {to recipient list} With “computer-generated” selected (the only choice): all computer-generated ground templates of category “(none)” are listed. When this action is executed, a new ground message using the selected template is created and sent to the users in the {to recipient list}. The selected users must have a distribution configured in the ground templates distribution window.

•

Wait for + {x} + {second, minutes, hours}

The wait for action simply waits for the configured time, no matter what other events happen. EVALUATE IF: Uses criteria as a decision point to branch to different activities. The criteria are evaluated at the moment the step runs and produces a true or fals e result. Complex criteria can be created by adding criteria with "and" and "or" operators. •

Downlink / Uplink / Ground message + {received} + “template name” For downlink templates: all downlink templates are listed. For uplink and ground templates: all templates from external user are listed. Tests if a message has been received. The result of the criterion will be true if a message of the selected template has been received from (or about) the aircraft since the beginning of the current flight.

•

Flight stage + {=, >, =, ), equal or greater than (>=), smaller than (120 min (2 hours); "Off" >1200 min (20 hours); "On" >60 min; "In/Summary" >15 min. It represents the time from the last message received after which the aircraft is removed from the tracking table, in minutes. Before V3R2, this value was stored as the parameter "TrackingExpiryTimeoutSecs", in seconds, in the Aircomsrv.ini file. This value is now ignored by the Server and can be removed from the ini file. The new value in System Parameters is set to 900 minutes (15 hours) regardless of what was set in the Aircomsrv.ini file. You may want to review it if the value in the ini file was different than the default (56000 seconds). In aircraft tracking, display the “Last Update” value in bold when an in-flight aircraft has not sent a downlink or uplink after this time (minimum 1 minute). Represents the time period, expressed in minutes, after which, if an in-flight aircraft did not report its position, it is

242

ASP Administrator Guide Version 6.9a

Data

Automatic refresh period

Estimate aircraft position after

Description classified in the list of no position reporting aircraft in the FlightTracker window. Aircraft tracking automatic refresh period expressed in seconds. 0 means no automatic refresh, otherwise minimum 10 seconds. Tells if the position of aircraft should be estimated and, when checked, how much time after the last reported position from the aircraft. •

When the aircraft has a flight plan associated: its position is extrapolated on its flight plan, on or between waypoints, based on the ETA of each waypoint and estimated aircraft ahead/behind ETA at last reported position. The position method is then set to “flight plan extrapolation”. The extrapolation may ignore waypoints that are too close to the aircraft.

•

Even without a flight plan

Aircraft suspected mute timeout Active over satellite timeout

Active over HF timeout

When the aircraft has no flight plan associated, the type of extrapolation performed depends on the parameter “Even without a flight plan” described below. Two behaviors exist, depending if this option is checked or not: • Unchecked: position is still estimated but on the last RGS station used by a downlink, if that downlink was received after the configured delay. The position method is then set to “last station position”. • Checked: position is extrapolated on a great-circle line between the last reported position and the arrival airport using the ETA as the arrival time to estimate the aircraft's progress, as well as the estimated aircraft ahead/behind ETA at last reported position. This method is much less accurate than flight plan extrapolation since the system does not know the real route flown by the aircraft. The position method is then set to “great-circle extrapolation”. In both cases, the estimation starts only after the delay configured with “Estimate aircraft position after” if the option has been checked. In-flight aircraft with no downlinks received since this configured time (expressed in minutes) is considered mute. Aircraft tracking data is enhanced with a satellite active flag telling whether or not an aircraft can be considered currently under satellite coverage. Systematically, sometime after an aircraft reports ON or IN stage, the satellite active flag is reset. Aircraft tracking data is enhanced with a high frequency (HF) active flag telling whether or not an aircraft can be considered currently under HF coverage. Systematically, sometime after an aircraft reports ON or IN stage, the HF active flag is reset.

243

ASP Administrator Guide Version 6.9a

Data ETA changed event threshold

Description If the Estimated Time of Arrival (ETA) changes by at least this threshold (expressed in minutes) since it was last notified (or if it has never been notified yet), the “ETA changed” event is triggered. The minimum value is 1 minute. See section 8.1 for more details. Fuel Conservation Monitoring (FCM) Panel This panel is visible only with the FCM license option. Long taxi-out threshold If the taxi-out time exceeds this threshold (expressed in minutes), it triggers the "long taxi-out time" event (see Event Handling configured via Fleet Configuration). The minimum value is 1 minute. Long taxi-in threshold If the taxi-in time exceeds this threshold (expressed in minutes), it triggers the "long taxi-in time" event (see Event Handling configured via Fleet Configuration). The minimum value is 1 minute. At gate APU usage threshold Once at gate (before the OUT event and after the IN), if the APU run time exceeds this threshold (expressed in minutes), it triggers the "APU usage limit exceeded" event (see Event Handling configured via Fleet Configuration). The minimum value is 1 minute. Estimated and Scheduled Times Panel ETD & STD correspond to Allows deciding whether you want the Estimated Time of Departure (ETD) and Scheduled Time of Departure (STD) to correspond to the Out time (gate departure) or Off time (take off). ETA & STA correspond to Allows deciding whether you want the Estimated Time of Arrival (ETA) and Scheduled Time of Arrival (STA) to correspond to the On time (landing) or In time (gate arrival). Table 7-56 System Parameters – Tracking Data

244

ASP Administrator Guide Version 6.9a

7.1.2.5.

Third Parties Tab

Figure 7.95 System Parameters – Third Parties

This tab contains connection parameters and settings to interface with third parties data providers. Each interface requires a contractual agreement with SITAONAIR whom will then coordinate with the said data providers and return the proper credentials and settings to use for the connections. FlightAware is a flight tracking data provider that enhances AIRCOM® ServerPlatform's tracking. It provides ATC data such as flight plans, aircraft movements and aircraft positions obtained from multiple international sources. Aircraft positions include radar, ADS-B and MLAT positions as well as estimated positions when outside of FlightAware's coverage. The FlightAware data complements the data obtained from normal ACARS + ground sources and allows the tracking of aircraft that are not equipped with ACARS. SITAONAIR can provide more details about the FlightAware data provider and its coverage zones. AIRCOM® FlightMessenger receives data from FlightAware for the operator codes displayed in the General tab's "Operator Codes" list. If these include partner airlines, ASP receives ATC and position data for those too. As part of the agreement with FlightAware, it is possible for the airline to feed its own ACARS movements and positions to FlightAware for a greater accuracy of the tracking

245

ASP Administrator Guide Version 6.9a

and estimated positions. The ACARS data will serve only for the airline's private data feed but will not be available for public data sources. Configure a valid FlightAware account to view tracking data from FlightAware in the Aircraft Tracking and FlightTracker Map. DTN is a weather data & flight route alerting (FR-A) provider that enhances the FlightTracker experience with a rich set of map weather layers and weather information. The exact list of available weather layers depends on the package associated with the account at DTN, and the FlightTracker Display Options dialog as shown in section 0 describes those included in your account. Configure a valid DTN account and give the user right “View FlightTracker weather” to users to allow them viewing the weather data in the and FlightTracker Map. FE and its map, referred to in this document as FE interface, consists in a map provider alternative for flight following and weather display. The FE Interface section will show only if available in the license options. Data Description FlightAware – Flight Tracking Data Provider Panel User name The user name of the customer account to connect to FlightAware to obtain flight data. Password The password of the FlightAware account is mandatory and the confirm password must match before saving. Once saved, the displayed password does not reflect the length of the real password; it is just an indication that a password exists. Data from FlightAware The data that AIRCOM® ServerPlatform can obtain from FlightAware is flight plans, departures and arrivals, gate departures and arrivals, positions and estimated positions. Each of these can be turned on or off as desired. FlightAware will only send desired messages, except for messages containing estimated positions which will always be received. They will however be trashed if “Estimated positions” option is unchecked.

Data to FlightAware

Be sure to only check options that match your FlightAware license options. Otherwise, the connection to FlightAware will be refused and no traffic will be received. Primary and backup link names, as defined in the file CmLinks.ini, to communicate data to FlightAware. AIRCOM® ServerPlatform sends data to FlightAware only to allow FlightAware to compute more precise flight route extrapolations and allow proper flight/aircraft/flight plans associations.

246

ASP Administrator Guide Version 6.9a

Data Aircraft registration and flight identifier filter

Description A filter that can be configured to request from FlightAware only data for specific aircraft and/or flights. When this filter is configured, it is combined with the default airline filter based on the configured operator codes. The star (*) can be used as wildcard and the only allowed characters are alphanumerical. The various filter values can be comma or space separated, but they will all be normalized to space separated upon save. The field accepts a maximum of 1024 characters and each individual filter value’s length must be between 3 and 7 characters. Note that any invalid filter value that would not be captured by the save validation will be rejected by FlightAware and a corresponding event will be logged in the ASP Event Log. WARNING: Use the wildcard with care and also be mindful of the use of aircraft registrations vs flight identifiers within the filter, especially when combined with wildcards as this can easily request more traffic than desired. Remember that this filter adds up to the airline code filter (operator codes defined in the AircomSrv.ini file).

For more information on this filter, please refer to the following FlightAware documentation: https://flightaware.com/commercial/firehose/firehose_docu mentation.rvt and search for “idents”. DTN – Weather Data and flight route alerting (FR-A) Provider Panel User name The user name of the customer account to connect to DTN to obtain weather data or Flight Route Alerts. Password The password of the DTN account is mandatory and the confirm password must match before saving. Once saved, the displayed password does not reflect the length of the real password; it is just an indication that a password exists. FE Interface Panel This panel is visible only with the FE license option. Connection with FE back-end Type of connection used to interface with the FE back-end. In other words, the format and technology used to send data to the FE back-end. If none is specified, the FE will not receive any data from AIRCOM® ServerPlatform. The usual connection used is Type B (connecting using MATIP to FE). An alternative is to use File (connecting using FTP to FE). MSMQ and MQSeries connections cannot be used at the moment. MATIP or FTP connections are configured using the ASP server initialization files. Please

247

ASP Administrator Guide Version 6.9a

Data

Send to: …

Description contact your SITAONAIR representative or [email protected] for help regarding FE backend connection. For a Type B connection (MATIP), the usual address is: “ACYFEXS”. For a File connection (FTP), the usual file name is: [path name]\{YYYYMMDDHHNNSS}0.3PD.

Edit button

FE Interface version

Customer suffix Include version and customer suffix as header in messages

Use call signs

Use waypoint names Do not show success dialogs

Aircraft position persistence

Please, always confirm this parameter by contacting your SITAONAIR representative or [email protected]. When the connection to FE back-end is through file, to edit the file name the user may use the Edit button. This opens a File Name Editor which allows adding predefined fields or custom fields to the file name. For a detailed description of the file name editor, please refer to section 6.1.4.9. Read-only information about the currently used interface version to exchange data with the FE back-end for this release of AIRCOM® ServerPlatform. Usually set to the airline’s ICAO code to uniquely identify the airline at FE premises. Flag telling the ASP server to add the ASP – FE interface version and the customer suffix at the very beginning of messages sent to the FE back-end. Checked by default and should usually stay checked. When interfacing with FE, sometimes flights are referred to using call signs rather than flight numbers. Hence, by setting this flag and by setting a flight number to call sign mapping, it is possible to use a call sign rather than a flight number to display an aircraft in FE Interface. Please contact your SITAONAIR representative or [email protected] if you want to use this feature and want to know how to set the flight number to call sign mapping. When checked, the system uses waypoint names rather than coordinates when sending flight plans to FE. When checked, any success condition occurring from an action in FE, like uplink successfully sent, will not be displayed in the FE Interface. Only warnings and errors will be reported to the user. Aircraft displayed on the FE map based on ACARS positions normally (by default) persist on the map for 60 minutes, if no other positions are received, and then disappear. This period is configurable for the following flight stages: taxi-out, enroute, and taxi-in. For the taxi-out and en-route phases, that time defaults to 60 minutes, but the taxi-in phase now defaults to 5 minutes to avoid accumulation of at gate aircraft stationed at the various destination airports.

248

ASP Administrator Guide Version 6.9a

Table 7-57 System Parameters – Third Party Data

249

ASP Administrator Guide Version 6.9a

7.1.2.6.

Flight Assignment Tab

Figure 7.96 System Parameters – Flight Assignment

Data Operational times Next operational day starts […] after/before midnight UTC (was: Crossover time offset from midnight UTC)

Description Offset in hours and minutes from midnight UTC at which a flight assignment day starts, either before or after the actual UTC day. Determines when an operation day begins for the dynamic flight assignments, relative to midnight UTC. An offset value "after" midnight means that an operational day will start later than the UTC day, usually when most of the flight operations are in the western hemisphere. An offset "before" midnight means the operation day starts before the UTC day, typical of operations in the eastern hemisphere. It is important to match ASP's operational day with the Flight Dispatch system that provides the assignments to ASP, otherwise wrongly matched assignment will happen at the beginning or end of the operational days.

Show tomorrow’s flights […] before the next operational day

See section 9.1.1, "Distributing Messages Based on Dynamic Flight Assignments" for a general description of the feature and how to configure it completely. Period in hours and minutes before the next flight assignment day during which assignments for the next day will show in the My Flights list. Time before the next operational day during which the assignments for the next day become visible in the "My Flights" window. This parameter is just for display, it does not affect how ASP attaches assignments to flights.

250

ASP Administrator Guide Version 6.9a

Data Allow flights to initialize up to […] before the next operational day (was: Flight preparation buffer time)

Description Period in hours and minutes before the next flight assignment day during which an aircraft that's initializing for a flight can attach to an assignment that is scheduled for the next day (assuming that it will be the next day by the time it departs). This time period is useful for flights that depart very early in the operation day and for which the first initialization & flight preparation messages may be received at the end of the previous operational day. As an aircraft may be attached to a flight assignment from the first messages it sends, even before departure, ASP may need to consider that those messages relate to a flight which operation date is on the following day. It will do so if the first messages from an unattached aircraft are received within the initialization buffer before the next operational day. This effectively extends the assignments before its operational day into the day that precedes it.

Cancel delayed assignments […] after the next operational day (was: Automatically cancel delayed assignments […] after crossover time)

Time in hours and minutes after which a delayed flight assignment (not attached in the previous day) is cancelled in the next day as to never be flown. A time of 0 h 00 min means to cancel un-attached assignments right when the next day starts (no delay). With flight assignments that were delayed after not being flown, many of today's flights could get attached to delayed assignments from yesterday because the delayed assignments are still available. To avoid this, the “delayed” flight assignments are turned to “cancelled” when the cancel time is expired. This effectively extends the assignments after its operational day into the day that follows it.

Automatic operations Automatically repeat today’s assignments

Re-attach assignments when aircraft change before OFF (tail swap)

Take the assignments for one day and repeat the same ones as "Scheduled (R)" for the next day if they don't already exist. Assignments that should not be repeated must be cancelled the next day by assigning them to the no desk. When set, this parameter causes the assignments for today to be repeatedly scheduled into the following days, if the same assignment (FI, origin, destination) has not been explicitly set already by flight assignments messages. Repeated assignments will continue to be scheduled every day with the same FI, origin, destination and assigned desks but with the date of origin and operation set to the next day until assigned to "no desk" Allow one aircraft to attach a matching assignment that was already attached to another aircraft if it has not passed the

251

ASP Administrator Guide Version 6.9a

Data

Description OFF stage. This is typical of an aircraft change (tail swap) where a new aircraft takes a flight originally scheduled for another.

No desk (flight cancelled) No desk assignments

Sets the desk name that is used as “no desk” in the dynamic flight assignment messages, which is used to designate a flight that will not be flown for the related date and thus is assigned to no desk. Assignments for “no desk” are not repeated to future dates. Table 7-58 System Parameters – Flight Assignment Data

7.1.2.7.

SATCOM Tab

This tab contains the configuration items needed to operate the SATCOM cockpit voice dialer function in AIRCOM® ServerPlatform. This allows authorized users to select an aircraft from the Aircraft Tracking, the FlightTracker or the FE Interface and to initiate a phone communication with the aircraft cockpit, provided that this aircraft has its Aircraft Earth Station Identifier (AESID) configured (see section 5.3.2). This also requires having the Dial Engine Pro software installed (provided in the Support folder of the release media), and typically an access to analog phone line with an installed modem. Please refer to “Appendix C: Dial Engine Pro Configuration for SATCOM Dialing” for details on how to configure the Dial Engine Pro software.

Figure 7.97: System Parameters – SATCOM Data Data

Description

Customer PIN

The customer’s Personal Identification Number used in the voice communication dialing sequence to contact an aircraft via satellite. Any dialing prefix required by the local setup, such as ‘9’ to dial out from your company. This setting should also be used to set any international call numbers that are required when

Dialing prefix

252

ASP Administrator Guide Version 6.9a

Data

Wait for the phone service to answer and for the welcome and “Enter PIN” prompts to complete Wait for the “Enter AESID” prompt to complete

Voice network access number Exclude country code from access number when dialing Force to use one access number

Allow to choose between primary and secondary access numbers

Description calling out from your location. For example, if located in America calling to Europe, you need to dial “011”, thus the prefix could become “9011” if “9” is required to dial out. Inserts a pause when dialing to the aircraft such that the initial voice prompts have time to complete before the PIN is automatically dialed. The default is 16 seconds, but other choices are available. Inserts a pause when dialing to the aircraft such that the voice prompt asking to enter the AESID has time to complete. This pause is applied after the PIN has been dialed. The default is 6 seconds, but other choices are available. These are the options available regarding the access number to use to call in the SITAONAIR voice network. The access numbers are all stored with the country code, but when dialing to a local number, this code should be removed and thus this option should be checked. This is the default option. The administrator decides which number should be dialed when using SATCOM and this will be the number used automatically by any user using the SATCOM dialer. The number is specified via the Primary dropdown. This option requires the administrator to select two access numbers; any user using the SATCOM dialer will always be prompted to select one of the two numbers. The primary will be the default selection, but they will be able to select the secondary number if need be.

Allow to select any access number

With this option the administrator does not specify any primary or secondary access number. Any user using the SATCOM dialer will always be prompted to select the access number among all possible access numbers. Table 7-59 System Parameters – SATCOM Data

Once these settings have been set, you should test the SATCOM function to make sure that the delays and prefix, as well as “Exclude country code” settings are right for your location relative to the city/country you decided or allowed to call to. Known limitation: If you decide to allow users to select dynamically between a primary and secondary access number, or to select any access number, depending on your location and on the number selected, the prefix and “Exclude country code” settings may prevent some numbers to dial successfully. For example, if located in Montreal and allowing users to select any number, then to call the Montreal number you should check “Exclude country code” and possibly set the prefix to “9”. But to call to Singapore, you would need to set the prefix to “9011” and do not check “Exclude country code”. This cannot be managed at the moment. If this is your case, you may consider the option “Force to use one access number”, or select among primary and secondary numbers that would require the same prefix and country code settings.

253

ASP Administrator Guide Version 6.9a

7.1.2.8.

FlightPlanner Tab

This tab allows configuring aspects that relate to flight planning under FlightPlanner. It thus requires the FlightPlanner license option to be set, otherwise it will not be available.

Data Flight Plan Sending (RFP)

Description

AFTN origin addresses

The origin AFTN address(es) that can be used when sending a Replacement Flight Plan (RFP) to ATCs, chosen by the dispatcher.

Flight Plan Uplink Enable flight plan uplinks FMS route data FMS wind data Flight plan to aircraft printer

Check to enable flight plan uplinks to the aircraft. Check to enable FMS route data to be included in uplinks to the aircraft. Check to enable FMS wind data to be included in uplinks to the aircraft. Check to enable flight plans to be sent to aircraft printer.

254

ASP Administrator Guide Version 6.9a

Data Send uplinks through

Description Sets how uplinks will be sent.

AIRCOM® ServerPlatform, using the normal uplink mechanism SITAONAIR FlightPlanner Host, using Priority Type B addresses

This option is not available yet and will be in a future release of ASP. When choosing this option, flight plan uplinks are sent using SITAONAIR FlightPlanner Host. The message priority to use (QU, QK or QD) The Type B addresses of the DSPs through which flight plan uplinks will be sent.

Flight Plan EFB Enable flight plan to EFB EFB output file user

Check to enable sending flight plan to Electronic Flight Bag (EFB). Specifies the user, already configured as an AIRCOM® ServerPlatform file user, through which flight plans are to be sent for EFB systems.

Flight plans will be saved into the file user's "Receive From" directory so it is then read and processed by AIRCOM® ServerPlatform. Expiry time Sets the time period after which a flight plan sent to the EFB directory will be automatically deleted. FBOL connection for AWS weather charts Subscribe to AWS weather charts Check to enable subscribing to Flight Briefing Online Advanced Weather Service (FBOL AWS). User name, Password, Confirm The username and password of the account to uses to password authenticate to Flight Briefing Online Advanced Weather Service (FBOL AWS). Weather Alert Messages Number of METAR messages to be Sets the number of METAR (airport MET observation) displayed reports to be displayed for any given location(s) by default. Number of TAF messages to be displayed Number of days to keep messages Clean-up Mark as deleted when older than the specified number of days Flight programs and flight plans

Sets the number of TAF (Terminal Area Forecast) reports to be displayed for any given location(s) by default. Sets the number of days beyond which any message older than the entered value will be purged (permanently deleted). Check to automatically mark FlightPlanner records as deleted when the specified delay is reached. The number of days after which flight programs and flight plans are automatically marked as deleted. Note that protected flight plans will never be marked for deletion.

Schedules Do not process ASM messages having date of flight later than today + […] days

Sets the number of days beyond which any ASM message older than the entered value will be excluded. Leave unchecked to process all ASM messages regardless of their date of flight. ASM messages are processed through ground templates using the “FlightPlanner Schedule Update” category.

255

ASP Administrator Guide Version 6.9a

Data As part of Automatic Flight Program Ingest Overwrite existing flight program with ingest record, if applicable

Purge existing flight programs having date of flight later than today + […] days

Description Flight Program ingestion is done through ground templates using the “FlightPlanner Schedule” category. Check to overwrite flight programs if ever they already exist when ingesting records. Leave unchecked to skip records for which a flight program already exists. Flight programs are uniquely identified using their date of flight, flight number, STD, STA and departure/arrival airport. Sets the number of days beyond which any flight program older than the entered value will be purged (permanently deleted). This will only purge flight programs which are not allocated and do not have any flight plan under it.

System Monitoring Please refer to “System Monitoring” section of [S3] for more information.

Data Link Service Providers Window The Data Link Service Providers window is available through the Main window, via one of the following means: System dropdown button, Data Link Service Providers option, and via the Operations menu. This window allows a user with the right Manage DSP to configure the data link service providers used for the aircraft communications over ACARS.

Figure 7.98: Data Link Service Providers (DSP) Window

256

ASP Administrator Guide Version 6.9a

7.3.1.

Function Description

Function New (Ctrl-N)

Modify (Ctrl-M) Delete (Del)

Save (Ctrl-S) Cancel (Ctrl-Z) Close (Ctrl-L) Context menu

7.3.2.

Description Always enabled; can add a new DSP in view or modify mode. In any case, additions performed while in view mode enters the editing mode and they are committed upon the next save operation or rolled back on the next cancel. At least a unique DSP identifier must be specified for the new entry before doing anything else. Enabled only when in view mode; enters the editing mode and selects the current DSP identifier. Always enabled as long as there is a current DSP selection. The function deletes the current selection in the list of service providers. In any case, deletions performed while in view mode enters the editing mode and they are committed upon the next save operation or rolled back on the next cancel. A confirmation dialog box requests user approval prior to proceeding with each single DSP deletion’s to be done via another administrator account having the Modify system parameters right. Enabled only when in editing mode. Switches to view mode if the save operation is successful and saves all DSP changes, including additions and/or deletions. Enabled only when in editing mode. Switches to view mode and cancels any changes made to any DSP, including additions and/or deletions. Closes the Data Link Service Providers window. Right-clicking over the list of all DSP provides the “new / modify / delete / save / cancel” functions. Table 7-60: Data Link Service Providers Functions

Data Description

Data List of DSP

Description List important data about each DSP – quickly shows the current default DSP, identifies the SITAONAIR DSP, with their identifier and Type B address. The list can be sorted and note that the check boxes in the list are read-only; only values displayed to the right of the list are editable

DSP code

The Data Link Service Provider (DSP) code assigned in the AEEC 620 specifications that will be used to identify incoming messages as well as properly address outgoing messages. If you are not sure about this field please contact your service provider who will be able to supply this information. It is mandatory and must be unique. Indicate to the system which DSP is to be used as default when an uplink message is to be sent and no aircraft tracking information is available. It is also used as a fallback solution in case the uplink delivery of a message has failed on the primary path found in the aircraft tracking. Only one DSP can be defined as default (i.e. checked), all others must remain unchecked.

Default DSP

Satellite service ONLY

The service provider is exclusively or not exclusively a satellite provider (e.g. QXT is exclusively satellite while DDL is not).

257

ASP Administrator Guide Version 6.9a

Data eDFP

Type B Address

SITAONAIR DSP

Use /GL or /AP

Description eDFP stands for EFB Datalink Front-end Processor and is used only when having the MIAM license option. The eDFP checkbox identifies a Service Provider as MIAM IP enabled. It is used in conjunction with the MIAM module to identify MIAM over IP service providers as opposed to ACARS only service providers. When the eDFP checkbox is set, the MIAM module will optimize its internal timers and counters to take advantage of the higher throughput available over an IP connection. This field contains the Type B address of the DSP that will be used as destination address of uplink messages addressed to that service provider. If you are not sure about this field please contact your service provider who will be able to supply this information. It is mandatory. Indicate to the system which DSP belong to SITAONAIR. Check the box for the appropriate DSP identifiers. All others should remain unchecked. NOTE: At least one DSP must be SITAONAIR, but more than one may be defined. Used to force or not the use of GL (Ground Location) or AP (Airport) as location text element line item (TEI) in uplink messages.

/GL is not populated for Out-Up when the messages are sent to SITAONAIR with one exception, if Enhanced uplink routing is configured. In all the other cases the /GL will only be displayed for messages sent to non-SITAONAIR service providers. Wait {xx} before retrying a transmission The number of seconds to wait before retransmitting a failed uplink to the DSP. Maximum number of transmission retries The maximum number of times AIRCOM® ServerPlatform will attempt sending an uplink message to an aircraft via a specific DSP before considering that the route to the aircraft is failed. No response from DSP timeout It represents the safeguard timeout after which to retransmit uplinks if no response from the DSP has been received, in minutes. Before V3R2, this value was stored as the parameter "MsgExpiryTimeoutSecs", in seconds, in the Aircomsrv.ini file. This value is obsolete and ignored by the Server and can be removed from the “ini” file. The new value is set to 15 minutes regardless of what was set in the Aircomsrv.ini file. You may want to review it if the value in the “ini” file was different than the default (900 seconds). Default station range Used for stations owned by a service provider that is configured to use the owner default station range rather than their own range. Description Short descriptive of the service provider (e.g. QXT: SITAONAIR satellite). Table 7-61 Data Link Service Providers Data

258

ASP Administrator Guide Version 6.9a

Value Lookup Table Window The Value Lookup Table window is available through the Main client window ‘System’ dropdown button, ‘Value Lookup Tables’ option, and via the Operations menu. It allows a user with the right Manage lookup tables to manage value lookup tables, which are used by all message templates (downlink, uplink, ground) and models to specify the replacement of field values (e.g. expand an airport code into an airport full name). The expansion really occurs when viewing the message with the message viewer and in the process of reformatting such a message using a model. Lookup tables are specifically used when defining template and model fields. It is at the field level, inserted into a template or model that the field can refer to a lookup table to look for the field value. Consequently, for such a defined field, once matched to a data value in a real message, the real value will be searched in the specified lookup table. If the value is found it will be displayed in the viewer and/or replaced by the ‘convert to’ value specified in the table. Field value conversion using lookup tables can occur at two different levels. At the template level, a lookup table is used possibly for two reasons: 1) to display the converted value of a field in the Message Viewer (via the user’s mailbox) and 2) if the option “Use to convert value before storing it” is available and checked, the field value gets pre-converted and stored such that the converted value is used in the message processing rather than the original value. At the model level, a specific lookup table allows converting the message original value into the lookup ‘convert to’ value. The ASP server may need, in some circumstances, the Airports – IATA to ICAO predefined lookup table to be able to convert stations or airports 3 letter codes (IATA) to 4 letter codes (ICAO). Five predefined lookup tables are delivered with the system: Airports – IATA to Name, Airports – IATA to Name, Airports – IATA to ICAO, Airports – ICAO to IATA, and Satellite GES (includes the SITAONAIR and ARINC satellite stations codes and names). The content of these tables (values and convert to data) as well as the table names can be modified, but the tables themselves cannot be deleted (even if emptied by the user, when these tables are selected, the window delete button is disabled). However, the table Airports – IATA to ICAO is an exception: it cannot be modified because it is an exact reverse copy of the Airports – ICAO to IATA table. Thus any changes performed to the latter are automatically visible in the other table. Although it cannot be changed, the table is still required to allow proper code conversions within the system. Any other user-created lookup table can be totally managed (including deleted) by a Lookup tables and custom fields administrator. The latter predefined tables are used in particular to expand medium, and origin and destination station values.

259

ASP Administrator Guide Version 6.9a

Figure 7.99: Value Lookup Tables Window

260

ASP Administrator Guide Version 6.9a

Figure 7.100: Value Lookup Tables Window – Value List

7.4.1.

Function Description

The following describes the available window functions. Function Find (Ctrl-F and F3)

Description Allows searching for a lookup table entry according to either the value or the convert to string (see Figure 7.101). The Find dialog adjusts its display according to the ‘Search In’ selection data type. The string search occurs anywhere in the data element string (e.g. searching for ‘AL’ in ‘UAL’ is a match). The search is by default case insensitive, unless the ‘Match Case’ option is checked. As long as the Lookup Tables window stays opened, the ‘Find What’ lists the searched strings history since the window was opened for quick pick. The keyboard key combination ‘Ctrl-F’ opens or brings to the front the Find dialog. The ‘F3’ key performs a ‘Find Next’ (same as the button in the dialog) on the last specified search criterion, no matter if the dialog is opened or not. The search cycles through the ‘List of Table Items’ and when a

261

ASP Administrator Guide Version 6.9a

match is found, the matching entry is selected. The ‘Find’ function is available both in view and modify edit modes. Allows creating a new value lookup table. Allows modifying an existing value lookup table. Allows deleting the currently selected value lookup table. Allows saving all modifications made to a value lookup table. It is enabled only after either the Modify or New button has been pressed. Allows canceling any changes made in a New or Modify operation. It is enabled only after either the Modify or New button has been pressed. Closes the Value Lookup Table window. Table 7-62: Value Lookup Table Functions

New Modify Delete Save Cancel Close

Figure 7.101: Lookup Tables - Find String

7.4.2.

Data Description

The following describes the data components available in the Value Lookup Tables window. Data List of All Value Lookup Tables Value list only

Table Name List of Table Items

Description Lists all defined lookup tables by their name. When checked, the ‘convert to’ column of the value list is hidden (not deleted) such that only the value is used elsewhere in the system. Such a list cannot be used to perform value conversion. If the unchecked and ‘convert to’ data had been previously entered, that data is not lost. Notice that the predefined lookup tables (airport and satellite related) cannot be used as value list. The name given to the lookup table. List composed of two columns (grid):  Value: exact data found in a message that needs to be expanded or converted (maximum 200 characters).  Convert To: value to which the data found will be expanded when viewing and reformatting a message containing the value (maximum 2000 characters). The grid allows adding, deleting and modifying table items. All changes performed in the grid are saved or cancelled at once with the Save and Cancel operations. Table 7-63: Value Lookup Table Information

262

ASP Administrator Guide Version 6.9a

7.4.3.

Value List Browsing

Lookup Tables can be used to browse for a value. This is used when writing new messages via either the New Uplink or New Ground windows.

Figure 7.102: Value Lookup Tables Window – Value Browsing

A value is needed when a new message field is defined as a list of predefined values to pick from and it appears as follows in the new message windows (see “Field Two (alpha w/ lookup)”):

Figure 7.103: Value Lookup Tables – New Message Value List

263

ASP Administrator Guide Version 6.9a

How to get such a field when writing a new message? First of all it comes from an uplink or ground template Fields’ panel. The template has to be of the category “Uplink from Local User” or “Ground From Local User”. In the Fields panel, if a field has a Lookup Table specified then it will show as the above “Field Two”. The Value Lookup Table Browsing window will then open with only the specified table listed. The functions behave exactly the same as for the regular use of the Lookup Tables, except that only the ‘Modify’ function is allowed and that the ‘Close’ function is replaced by a ‘Return’ function. The ‘Return’ function does close the window, but it also returns the selected ‘convert to’ string as the selected value to the corresponding field in the calling new message window. Note that to select a value, you need to select a grid’s row using the ‘arrow’ indicator section to the left of the ‘List of Table Items’ grid (see Figure 7.102, ‘Inactive’ value). When creating lookup tables to use as value lists, make sure that the ‘value’ column is a key value that the users writing new messages will use to find the table entry they want, and that the ‘convert to’ column does hold the final string that will be inserted in the message being written.

VHF Stations The VHF Stations window is available through the Main window, via one of the following means: System dropdown button, VHF Stations option, and via the Operations menu. This window allows a user with the right Manage VHF stations to configure VHF and VDL stations.

Figure 7.104: VHF Stations Window

264

ASP Administrator Guide Version 6.9a

7.5.1.

Function Description

Function Refresh (F5) Find (Ctrl-F and F3)

Export (Ctrl-E)

Import (Ctrl-I)

Description Enabled only when in view mode; refreshes the displayed data content from the source database. The full list of stations and their data are refreshed. Always enabled; allows searching for a station according to any of the data elements defining the station. The Find dialog adjusts its display according to the ‘Search In’ selection data type. The string search occurs anywhere in the data element string (e.g. searching for ‘AL’ in ‘UAL’ is a match). The search is by default case insensitive, unless the ‘Match Case’ option is checked. As long as the VHF Stations window stays opened, the ‘Find What’ lists the searched strings history since the window was opened for quick pick. The keyboard key combination ‘Ctrl-F’ opens or brings to the front the Find dialog. The ‘F3’ key performs a ‘Find Next’ (same as the button in the dialog) on the last specified search criterion, no matter if the dialog is opened or not. The search cycles through the aircraft list and when a match is found, the matching station is selected. Enabled only when in view mode; exports the complete list of stations configuration data to a comma-delimited text file. The user is prompted to select the filename and location for the exported data. The default location is the data folder specified at the Client installation time and the default filename is of the form “Station_[ddmmyy_hhmmss].txt” (e.g. Station_090603_130526.txt) where “090603” is June 9, 2003 and “130526” is 13 h 05 min 26 sec (UTC time), the date and time at which the file was created. However, in remote access (i.e. via a Web browser), the filename is predefined to the default filename and the path is forced to the Client installation data folder on the server machine. Enabled only when in view mode; opens the Import Stations from File dialog, allowing selecting a station text file to import its stations configuration content into the system. To save the imported stations, click on the Save button or click Cancel to cancel changes. The file format is as follows: • A ‘;’ indicates a commented line, ignored and not imported. • A comma separates field values. • Text fields like fault descriptions are delimited by “ ”.

New (Ctrl-N)

Modify (Ctrl-M) Delete (Del)

Save (Ctrl-S)

The import rules and an import file format sample are documented below in section 7.5.4. Enabled only when in view mode; add a new station. Additions performed while in view mode enters the editing mode and they are committed upon the next save operation or rolled back on the next cancel. Station IATA and Frequency combination must be unique. Enabled only when in view mode; enters the editing mode. Always enabled as long as there is a current station selection. The function deletes the current selection in the list of stations. In any case, deletions performed while in view mode enters the editing mode and they are committed upon the next save operation or rolled back on the next cancel. A confirmation dialog box requests user approval prior to proceed with each single station deletion. Enabled only when in editing mode. Switches to view mode if the save operation is successful and saves all station changes, including additions and/or deletions. Most data validation is performed upon save.

265

ASP Administrator Guide Version 6.9a

Cancel (Ctrl-Z) Close (Ctrl-L) Context menu Locate station on Google map Locate station on FlightTracker map

7.5.2.

Enabled only when in editing mode. Switches to view mode and cancels any changes made to any station, including additions and/or deletions. Closes the VHF Stations window. Right-clicking over the list of all stations provides the “new / modify / delete / save / cancel” functions. Open the default web browser to the Google Maps web site automatically located at the specified latitude/longitude, zoomed in and in satellite map. Open the FlightTracker window (see document [S4b]) located at the specified latitude/longitude, zoomed in and in satellite map view. See section 7.5.3. Table 7-64: VHF Stations Functions

Data Description

Data List of Stations

Station code

Airport ICAO & Name

City Country Frequency

Station type Latitude (deg.)

Longitude (deg.)

Description List important data about each station – quickly shows the station code, operator, frequency, city and country where the station is located. The list can be sorted and the check boxes in the list are read-only; only values displayed to the right of the list are editable. The station IATA 3 letter code (upper case characters). It is mandatory and must be unique in combination with the frequency and operator. The station’s airport ICAO 4 letter code (upper case characters). When a valid code is specified and that the airport is configured in the Airport – ICAO to Name lookup table, then the name of the airport is also automatically displayed (read-only). This city where the station is located. The country where the station is located. The frequency used to communicate with the station. The format used is 999.999. It is mandatory and must be unique in combination with the station IATA. Station type VHF: Very High Frequency, VDL: VHF Digital Link. Latitude in degree where the station is located. The format can be either ADDMMSS (ex.: N350505) or ADDMM (ex.: N3505) or ADD.ddd (ex.: N35.083). This value must be valid to be able to save the station modifications. If the value is valid, the latitude in decimal will be shown. If the latitude in decimal is empty, it means the value entered is invalid. When saved, the format used is ADDMMSS. Longitude in degree where the station is located. The format can be either ADDDMMSS (ex.: W1064705) or ADDDMM (ex.: W10647) or ADDD.ddd (ex.: W106.783). This value must be valid to be able to save the station modifications. If the value is valid, the longitude in decimal will be shown. If the longitude in decimal is empty, it means the value entered is invalid. When saved, the format used is ADDDMMSS.

266

ASP Administrator Guide Version 6.9a

Data Latitude (dec.)

Longitude (dec.)

Operator

Description Latitude in decimal where the station is located. The format is [+/-]999.999. This value must be valid to be able to save the station modifications. If the value is valid, the latitude in degrees will be shown. If the latitude in degree is empty, it means that the value is invalid. Longitude in decimal where the station is located. The format is [+/-]999.999. This value must be valid to be able to save the station modifications. If the value is valid, the longitude in degrees will be shown. If the longitude in degree is empty, it means that the value is invalid. The operator of the station is one of the following predefined operators (subject to change over time). This is different from the associated DSP. There may be different DSP codes for the same operator, like QXJ or JDL for AVICOM. When an operator is selected, it filters the list of associated DSPs to only the ones allowed for this operator.

Associated DSP & description

Range Use DSP default station range

Comments

Data Link Service Provider (DSP) that is associated to the station. Used for Enhanced Uplink Routing (see section 9.1.6). The list is filtered according to the selected operator and to the currently configured service providers (see section 0). The description of the selected DSP is added below the DSP selection. This field is read-only because its value comes from the DSP configuration window. The listening range of the station on the specified frequency. This option is available only when an associated DSP is selected. When checked, the station will use the Station Provider owner range. When unchecked, the station will use the value entered under Range. Any comments or custom description of the station (maximum 2000 characters). Table 7-65: VHF Stations Data

267

ASP Administrator Guide Version 6.9a

7.5.3.

Display of Stations on the Map

The stations configured in the VHF Stations window are visible on the FlightTracker map if from the SITAONAIR operator. For the new and updated stations to be displayed, you may need to restart the ASP service “Base Service”. Clicking the Locate station on FlightTracker map link will bring you to it.

Figure 7.105: VHF Stations – FlightTracker Map

7.5.4.

Station Import

Configured stations can be exported to or imported from a file. It may be easier to update the stations’ list in an exported file and the reimport it back into ASP. The format of a stations import/export file is the following: ; Stations Configuration - If duplicated Station/Operator/Frequency trio exist in this file, you will be requested to choose which one to keep. ; ; "Station code (3 characters)","Airport ICAO code (4 characters)","City","Country","Comments","Region (deprecated)",Frequenc y,Longitude Decimal,Latitude Decimal,"Longitude Text","Latitude Text","Station type (VHF/VDL)",Range,"Associated DSP (3 characters)",Use Default Station Range (True/False) - default is True,Delete station (deprecated),"Operator code" ; "ABE","KABE","Allentown, PA","USA","","",136.850,-75.433333,40.65,"W07526","N4039","VHF",212,"",True,False,"SITAONAIR" "ABI","KABI","Abilene, TX","USA","","",136.850,-99.666667,32.4,"W09940","N3224","VHF",212,"",True ,False,"SITAONAIR" "ABJ","DIAP","Abidjan","Ivory Coast","","",131.725,-3.916667,5.25,"W00355","N0515","VHF",212,"",True,False,"SITAONAIR" "ABQ","KABQ","Albuquerque, NM","USA","","",136.850,-106.6,35.033333,"W10636","N3502","VHF",212,"",True ,False,"SITAONAIR" "ABY","KABY","Albany, GA","USA","","",136.850,-84.183333,31.516667,"W08411","N3131","VHF",212,"",True ,False,"SITAONAIR"

268

ASP Administrator Guide Version 6.9a

As long as the format is respected, the file can be modified and reimported back into ASP. This file can also be provided by SITAONAIR to update the stations to their most recent state. To do an import, follow the procedure: •

Click import from the VHF window’s toolbar.

•

Select the file to import. The default folder location is the data folder specified at the Client installation time.

•

At import, the user is asked if some user-customization that may have been done in the window should be overwritten or ignored (these are: associated DSP, comment and range). To protect the user-customizations, choose “Yes” the values will be ignored in the verification whether an imported station differs from an existing station.

•

If the import file contains duplication within the file, the user will be asked which one to keep. Station uniqueness is determined by three fields: the station code, its frequency and its operator. If these three items are identical for more than one station, it is considered the same station.

All stations in the import file that do not already exist will be automatically added without further user action required. The user must however take decisions for stations that do exist, but that are different from the equivalent stations in the import file.

269

ASP Administrator Guide Version 6.9a

7.5.4.1.

Station Overwrite Rules

Once the import file has been fully parsed and analyzed, all new stations have been added, existing stations with no differences are ignored and what is left are existing stations for which there are differences. These differences are presented in the Station Overwrite Validation dialog shown below.

Figure 7.106: VHF Stations – Overwrite Validation

It indicates the number of stations with differences and each of them has a check box checked by default. All checked items will be imported when the import button is pressed, thus the user may uncheck any station he does not want to overwrite. Each listed station presents a summary of the differences in the differences column of the grid, and when selecting one specific station, all fields for the original (existing) and new (from import file) stations are listed at the bottom to allow for a detailed analysis of the differences. If you then decide to import a station, by default all fields will be imported. IMPORTANT: Even if you indicated to ignore some fields at the beginning of the import (such as comments), if ever differences existed in other fields than the ignored ones, the station will be listed here and then, if you decide to import the station, ALL fields will be imported, the ignored fields for the comparison are not ignored when importing.

270

ASP Administrator Guide Version 6.9a

However, there are two exceptions to the above import all fields rule. First, the “Do not import comments” check box allows not importing comments at all Second, the check box “Try to keep existing DSP, if compatible with the operator” allows trying to keep the associated DSP unchanged when it is different in the import file, as long as that DSP is compatible with the station operator. Note that it is possible to specify different DSPs for some operators, like QXJ or JDL for the AVICOM operator. In the end, clicking Import will proceed with the import of all checked stations, and Cancel will abort the import. Both close this dialog, but Cancel returns into view mode in the VHF Stations window, while Import returns in modify mode. Therefore, as mentioned before, the user still has a chance to cancel the import changes at this point, or save them once and for all.

Custom Fields Window The Custom Fields window is available through the Main window, via one of the following means: System dropdown button, Custom Fields option, and via the Operations menu. This window allows a user with the right Manage custom fields to configure custom fields. A custom field is a user created field type that can be used in all template types supporting fields. When a template’s field type is that of a custom field, the matching field value is stored along with the data of the flight for which the message was received. This means fields can be named and typed to match specific needs of a customer. But even more interesting is the fact that these field values can be inserted in any message model via a special dropdown menu (the menu appears only if custom fields are defined). Because the custom field values are stored for a flight, these values can be shared within other messages via model formatting. As any other field in a template, depending on the custom field type, the templat e field properties will adjust, for example allowing lookup table definition for alphanumerical, allowing range validation for numerical or allowing date & time formats to be defined.

Figure 7.107: Custom Fields Window

271

ASP Administrator Guide Version 6.9a

7.6.1.

Function Description

Function Refresh (F5) New (Ctrl-N)

Modify (Ctrl-M) Delete (Del)

Save (Ctrl-S)

Cancel (Ctrl-Z) Close (Ctrl-L) Context menu

7.6.2.

Description Enabled only in view mode; refreshes the displayed data content from the source database. The full list of custom fields is refreshed. Enabled only when in view mode; add a new custom field. Additions performed while in view mode enters the editing mode and they are committed upon the next save operation or rolled back on the next cancel. Custom field names must be unique. Enabled only when in view mode; enters the editing mode. Enabled only when in view mode. The function deletes the current selection in the list of custom fields. Deletions are committed immediately after user confirmation. A confirmation dialog box requests user approval prior to proceed with each single custom field deletion. If the field is currently used in the system, a special confirmation dialog explains the impact of deleting the field and shows the templates currently using the field. Enabled only when in editing mode. Switches to view mode if the save operation is successful and saves the custom field changes. Most data validation is performed upon save. Enabled only when in editing mode. Switches to view mode and cancels any changes made to the custom field. Closes the window. Right-clicking over the list of all custom fields provides the “new / modify / delete / save / cancel” functions. Table 7-66: Custom Fields Functions

Data Description

Data List of custom fields

Field name Type

Description

Description List of all configured custom fields with their data type. The list can be sorted; only values displayed to the right of the list are editable. The field name up to 50 characters. Three data types are allowed for custom fields: alphanumerical, numerical, and date & time. The type selected should match the expected data type for that field in the messages it will be used within. Description of the custom field, typically to specify its usage. Table 7-67: Custom Fields Data

272

ASP Administrator Guide Version 6.9a

8. Miscellaneous Event Handling Windows The Event Handling windows are available from the Templates windows, the Fleet Configuration window and the Sequencer window via their respective ‘Event Handling’ buttons. It allows the configuration of handling rules and actions following specific events relating to the configured templates, aircraft or sequences. For example, the "Unknown aircraft" event allows actions to be configured whenever a downlink is received from an aircraft that is not defined in the fleet configuration. The events available in each context are described within the window itself. More details are also included in the following sections.

Figure 8.108: Event Handling Window – Downlink Templates Folder

Figure 8.109: Event Handling Window – Downlink Templates

273

ASP Administrator Guide Version 6.9a

8.1.1.

Function Description

The event handling configuration is hierarchical and tied to the window's folders structure. An event with configured actions in the root folder will apply to all folders and objects under it, unless overridden at a lower level. For example in the downlink templates, if the "unknown aircraft" event has the "notify user(s)" action configured with 5 recipient users at the root folder, it will apply to all templates under it without needing to be configured for each template. However, if one folder under it overrides the same event and configures different actions, the templates under that folder will inherit the actions from that folder. So if the event "unknown aircraft" for a given folder has its "notify user(s)" action changed to include 10 recipient users, all templates under that folder will notify those 10 users when a downlink from a unknown aircraft is received. When the same happens for the other templates, the notification will be sent to the 5 users configured for the root. These are the available functions in the event handling windows (based on the event selected, not action may be configurable): Function Override parent handling

Notify User(s)

Description The event handling definition of any object in a folder structure (template, sequence) is automatically inherited from its parent folder, which in turns inherits it from its own parent and so on. When the "Override Parent Handling" is checked for one event, a different configuration of actions is defined from that level down, applying to the folders and objects under it. Events can be overridden at any level, down to the last template or sequence which can then have its own settings no matter the parent hierarchy. The overriding applies to the selected event only; the events that are not overridden will preserve their inherited actions. Click the button to display a list of all system users to pick up from. The selected users will get an event notification via the corresponding folder of their mailbox (for local users) or via the proper means for the different user types (e.g. email). The notification describes the event that occurred and presents the original downlink message at the origin of the event, when applicable. Note that the number of currently selected users is always visible to the side of the button and that the selection dialog allows easily viewing only the currently selected users.

Reply to Aircraft

In the selection dialog, grayed out users are inactive for distribution at the moment. These users can still be selected or unselected, but when selected, they will not receive any event notification until their account becomes active for distribution again (refer to section 6.1.2 User Data for more details). Check the option and select an “auto-reply to downlink” uplink template from the list. This template will be used to automatically notify the sending aircraft of the event. Note that the option cannot be checked without selecting a template. For the template to be used, a model must be associated to it for the concerned aircraft in the Uplink Templates Distribution window. It is the model that is really used to format the uplink response. To see the list of applicable errors in the notification uplink, the MESSAGE ERRORS predefined field must be included in the model used.

274

ASP Administrator Guide Version 6.9a

Function Override parent handling

Do Not Distribute

Description The event handling definition of any object in a folder structure (template, sequence) is automatically inherited from its parent folder, which in turns inherits it from its own parent and so on. When the "Override Parent Handling" is checked for one event, a different configuration of actions is defined from that level down, applying to the folders and objects under it. Events can be overridden at any level, down to the last template or sequence which can then have its own settings no matter the parent hierarchy. The overriding applies to the selected event only; the events that are not overridden will preserve their inherited actions. When checked, this option prevents the execution of the regular Downlink Templates Distribution, as defined in the corresponding window, prevents any dynamic distribution and air-to-air uplinks (see section 0, " Fields Panel"), and prevents any airport distribution (destination distributed, origin distributed fields in the downlink template). Table 8-68: Event Handling Functions

In the Fleet Configuration window, the event handling is not hierarchical and the configured events apply to all aircraft.

8.1.2.

Configurable Events

The following is the description of all existing handled events. Not all events apply to all contexts (e.g. Suspected Mute Aircraft does not apply in the Downlink or Ground Template context). Using the Client, browse the different contexts to discover exactly what event applies to which context. The following is the description of all possible actions to take when an event is triggered. Not all actions apply to all events (e.g. Reply to Aircraft does not apply to the Unknown Aircraft event). Using the Client, browse the different events to discover exactly what action applies to which event. Downlink Template Event Invalid message Message handling error Unknown aircraft Downlink invalid date/time Out of Sequence Flight Stage Out of Range Field(s) Downlink template error Duplicate downlink Downlink from DSP '...'

Description An incoming message cannot be parsed or associated with an aircraft, user or template in the system. General message handling errors such as truncated downlink (QTB), distribution, acknowledgement or reply problems. A downlink has been received from an aircraft that is not defined in the fleet configuration. A downlink has been received with an invalid or outdated date/time field (DTG). A flight stage report message has been received out of the expected sequence. One or more fields, defined with a range checking, have a value outside the normal range. A downlink does not match a template, misses expected fields or has no destination recipient. The same downlink has been received twice in a row or more from the same aircraft. A downlink has been received from the specified Data Service Provider node.

275

ASP Administrator Guide Version 6.9a

Downlink Template Event Flight dispatch events

Description Events related to the dynamic assignment of flights to dispatcher desks such as assignment errors, unassigned flights, etc. Downlink from ARINC SAT Event being raised when a downlink is received via ARINC satellite. AFDAS fault report error There were some errors in the parsing of faults information, in a downlink of category "Fault Report (AFDAS)". Message trashed A message has been received but was trashed since it could not be processed or distributed as expected. Table 8-69: Event Handling – Downlink Template Events Descriptions Uplink Template Event Successful uplink delivery

Description The uplink message has been successfully delivered to the aircraft. Notified users will receive a successful uplink acknowledgement message based on their configuration (see Users & Groups window). Failed uplink delivery The uplink message has failed to be delivered to the aircraft. Notified users will receive a failed uplink acknowledgement message based on their configuration (see Users & Groups window). Message trashed A message has been received but was trashed since it could not be processed or distributed as expected. Table 8-70: Event Handling – Uplink Template Events Descriptions Ground Template Event Out of sequence flight stage Flight assignment errors

Description A flight stage report message has been received out of the expected sequence. Errors in the processing of a dynamic flight assignments message, such as an desk not matched to an ASP user. Flight dispatch events Events related to the dynamic assignment of flights to dispatcher desks such as assignment errors, unassigned flights, etc. Message trashed A message has been received but was trashed since it could not be processed or distributed as expected. Table 8-71: Event Handling – Ground Template Events Descriptions

276

ASP Administrator Guide Version 6.9a

Fleet Configuration Event Suspected mute aircraft Suspected deaf aircraft

ETA changed (by x min or more)

Downlink rate exceeded

Downlink rate normal

Description No downlinks have been received in a predefined period of time from an in-flight aircraft. The number of failed uplink retransmissions has exceeded the configured number of retries for the DSP used, as configured in the "Data Link Service Providers" window. A flight's Estimated Time of Arrival (ETA) has changed by the specified number of minutes (or more) since the last ETA changed event was raised (or since the original take off ETA if the event never occurred yet). The specified number of minutes is the “ETA changed event threshold” system parameter value. The ground template "ETA Update" is automatically used to notify the selected users. See section 9.2.9 for more details. The number of downlink messages per minute threshold for the aircraft (as per its aircraft type configuration, see section 5.4) has been exceeded. Allowed actions are: notify users of the situation, send an uplink to the aircraft and/or stop distributing the downlinks. When an aircraft faced a downlink rate exceeded event, and the situation comes back to normal (downlink rate per minute under the aircraft type threshold). Allowed actions are: notify users and/or the aircraft (send uplink). Downlink distribution returns to normal, if it were stopped, as soon as this event fires.

APU usage limit exceeded

This event is raised when an aircraft has been using it's APU at the gate longer than the configured threshold (System Parameters, Tracking tab, FCM panel). Long taxi-out time This event is raised when an aircraft has been in the taxi-out phase for longer than the configured threshold (System Parameters, Tracking tab, FCM panel). Long taxi-in time This event is raised when an aircraft has been in the taxi-in phase for longer than the configured threshold (System Parameters, Tracking tab, FCM panel). Table 8-72: Event Handling – Fleet Template Events Descriptions Description Sequence started Sequence started for an aircraft after its start condition got realized. Sequence stopped Sequence stopped for an aircraft after its stop condition got realized or a completed activity resulted in "stop". Sequence aborted Sequence aborted for an aircraft after a completed activity resulted in "abort". Activity success/true (with One activity completed with a successful or true result and has the "Notify" notify) box checked. Activity failed/false (with One activity completed with a failed or false result and has the "Notify" box notify) checked. Table 8-73: Event Handling – Sequencer Events Descriptions

Sequencer Event

277

ASP Administrator Guide Version 6.9a

8.1.3.

Notification Message Examples

INVALID MESSAGE: Unable to parse/decode incoming message from [.AN-VHA] INVALID MESSAGE: Message received from an unknown originator [Bob] INVALID MESSAGE: Unknown aircraft [.AN-VHA] MESSAGE HANDLING ERROR: Unable to retrieve an OOOI sequence number DUPLICATED DOWNLINK: Duplicated downlink received from [.AN-VHA] DOWNLINK TEMPLATE ERROR: No downlink template found for downlink with SMI [XXX] DOWNLINK TEMPLATE ERROR: No recipients for this downlink of type [Test Message] DOWNLINK TEMPLATE ERROR: Some fields are missing in downlink of type [Test Message] - OrigStation is missing - DestStation is missing OUT OF SEQUENCE OOOI: Bad OOOI sequence detected for [.AN-VHA], [OFF] received but was [ON] previously OUT OF RANGE VALUES: Some values are out of range in downlink [Test Message] for [.AN -VHA] - FuelOut value [17437] is abnormal (=50000) - FuelIn value [253] is in error (=50000) DOWNLINK FROM NODE ‘QXS’: Downlink received on provider node [QXS] from [.AN-VHA] DOWNLINK INVALID DTG: Date/time (DTG) too old in downlink from [.AN-VHA] DOWNLINK INVALID DTG: Invalid date/time (DTG) [270566] in downlink from [.AN-VHA] SUSPECTED MUTE AIRCRAFT: Aircraft [.AN-VHA] suspected mute, no downlinks received since 30 minutes SUSPECTED DEAF AIRCRAFT: Aircraft [.AN-VHA] suspected deaf, all available routes tried with no success

278

ASP Administrator Guide Version 6.9a

9. Function Reference Message Distribution and Notification 9.1.1. 9.1.1.1.

Distributing Messages Based on Dynamic Flight Assignments What is the Dynamic Flight Assignments Feature

The Dynamic Flight Assignments is a feature targeted at dispatchers and operational users to reduce the distribution of selected messages to only the user(s) responsible for a given flight on a given day, rather than to all users for all flights irrespectively. This allows a dispatcher user to receive the messages only for the flights it manages and keep the focus on those without being disturbed by unrelated flights. The flight assignments for a given day are provided to AIRCOM® ServerPlatform by a flight operation system such as LIDO with one or many successive messages matching a special ground template of category “Dynamic Flight Assignments”. The flight assignments messages must include the description of each flight on a daily basis and the dispatcher desk responsible for it. The processing of the message(s) will build the flight assignment table used for the distribution of templates configured with the “Flight Assignment Desks” dynamic group. The assignments can then be viewed and verified by the dispatchers from the “My Flights” window.

9.1.1.2.

Involved Configuration

System Parameters –Flight Assignment tab: Start by setting the controlling parameters for the feature in the System Parameters window. The main value to consider is the “Crossover time offset” which determines at what time an operation day begins for the flight assignments’ dates of operation. This value is midnight UTC by default but can be adjusted to accommodate the airline’s flight operation day and/or local schedules. With this parameter, an operation day can be set to begin at, say, 07:00 UTC (positive offset of 7 hours) and therefore end at 07:00 the following day. Other parameters dictate the behavior of the feature, as documented in the System Parameters window, section 0. Ground Templates – Dynamic Flight Assignment: To receive and process daily flight assignments, a ground template from external user of category “Dynamic Flight Assignment” is required. This template can be of any format as long as it allows ASP identifying the following field types for each individual flight assignment (each flight leg is a separate assignment):

279

ASP Administrator Guide Version 6.9a

•

Flight Identifier for Assignment: FI attributed to the flight, complete with operator code and flight number;

•

Departure Airport: ICAO or IATA code of the flight’s origin airport;

•

Arrival Airport: ICAO or IATA code of the flight’s destination airport;

•

Date of Operation: date at which the flight leg is scheduled to depart (OUT movement time);

•

Date of Origin (optional): date at which the first leg of a multi-leg flight is scheduled to depart;

•

Flight Assignment Desk: designation of the desk responsible for that flight on that day, which must match the “Dynamic flight assignment desk” of a configured user or group in the Users window. This is the user that will receive all messages distributed to the “Flight Assignment Desks” about that flight once it is attached to an active aircraft. All flights assigned to an desk on a given day are visible from the “My Flights” window.

•

Master Desk (optional): designation of the master desk overlooking the operation of that flight on that day. The master desk is not directly responsible for the flight and will not receive the distributed messages. However, it will be kept informed of flight assignment events and will have visibility of its flight assignments from the “My Flights” window.

The following picture provides a sample of a possible flight assignment message and the fields defined for it. The assignments list is covered by a “Flight Assignment” record block configured so that each line represents an individual record. Within that record, the fields required to define an assignment are configured, each with a fixed start offset and fixed length. The highlighted values in the first record are the following: FI (XS0062), Origin (ONT), Destination (ANC), Date Operation (18th of the current month), Date Origin (18th of the current month), Desk Responsible (I06) and Desk Master (YUL):

280

ASP Administrator Guide Version 6.9a

Figure 9.110: Dynamic Flight Assignment Template

Users and Groups – Desks configuration: The desk names used in the dynamic flight assignment messages need to be referenced to configured desks users. For that, the desks need to be configured as in the "Users and Groups" window and users need to be made members of the desks they're allowed to sign into. Before 6.4, it was users that needed to be configured as desks ("offices", back then) – systems with such users have had corresponding desks created automatically for each user being designated as an office. This has the effect of creating a new "Desk" user for each user and group that was configured as an office before, using the same name but with a "desk" suffix. Whenever users log into the system with an account that is allowed to sign-in one or many desks, they have access to the File > Desk menu and "My Flights" window, which allow them to choose the desk they will work into. The signed-in desk allows users to view messages sent and received by that desk and also to see the flights assigned to the desk when "My Flights" is pressed in. There should also be one of the configured desks that should be configured as the "Default master desk". The setting can be attributed to one desk only and designates one account to be the master desk by default, that is the desk to which a message or event will be sent if it cannot be sent to the normal responsible desk. This can happen in the presence of assignment errors or when aircraft are not yet attached to flight assignments. As such, the default master desk should be manned at all times to catch what is not received by other dispatchers.

281

ASP Administrator Guide Version 6.9a

Downlink & Ground Templates Distribution – Flight Assignment Desks: This is where the dynamic portion of the feature is exploited, by setting up the templates and models that must be distributed to the “Flight Assignment Desks” dynamic group. The distribution to that group is based on dynamic flight assignments which associates the daily flights to dispatcher’s desks so that the received messages for a given flight are distributed only to the dispatcher responsible for that flight. Downlink & Ground Templates – Event Handling: In the downlink and ground templates windows, it is now possible to configure event handling for dynamic flight assignments events, divided in two categories: •

Flight Assignment Errors (ground templates only): Errors in the processing of a dynamic flight assignments message, such as an desk not matched to an ASP user.

•

Flight Dispatch Events (ground and downlink templates): Events related to the dynamic assignment of flights to dispatcher desks such as assignment errors, unassigned flights, etc.

In the two event handling contexts, it is possible to configure notifications to “Flight Assignment Desks” which mean that the events raised under the set categories will be sent to the user or group responsible for that flight assignment as well as the master desk for it. In the event where no master desk is configured or an error prevents the normal desks to receive the event, it is the default master desk that will get it.

9.1.1.3.

Sending Dynamic Flight Assignment Messages

Once the configuration is completed, the feature becomes useful when “Dynamic Flight Assignments” messages are received from the flight operation system, thus building up the assignments table. Flight assignments can be sent to ASP in many successive small messages or in one big message; the assignment messages are additive, they don’t replace each other, they add up to one another. However, if a new flight assignment received from an assignment message corresponds to an existing one, the new one replaces the existing one. Flight assignments are considered the same when the four directing parameters correspond: FI, origin, destination and date of operation. If the responsible and/or master desk are different, the values are updated in ASP’s assignment table. Flight assignments can be provided to ASP for one or many days in advance, at any time during the operation day. To be ready in time and properly displayed, the flight assignments for the next operation day must be provided at least before the value set for the “Show tomorrow’s flights” in System Parameters. If the setting “Automatically repeat today’s assignments” is checked, the daily flight assignments of today will be repeated the same for tomorrow and with the same responsible + master desk, if not explicitly updated by a new flight assignment message. The same assignment will be repeated every day, as long as it’s not explicitly updated

282

ASP Administrator Guide Version 6.9a

from a fight assignment message, or set to “no desk”, in which case it will not be repeated. The next day’s flight assignments are therefore generally composed of explicitly updated assignments, from the flight operation system, and repeated assignments from previous days. Their initial status will be “Scheduled” and “Scheduled (R)”, respectively. In any case, assignments can be updated by having the flight operation system send another dynamic flight assignment message to ASP containing new or updated assignments (often referred to as “ad-hoc” changes). These will always have precedence over the existing ones and thus have immediate effect, even for active flights.

9.1.1.4.

How to Use Dynamic Flight Assignment

Once flight assignments have been received, the ASP server starts using them and tries to match each active aircraft to the available assignments by comparing the aircraft’s FI, origin, destination and departure time (estimated or actual) as soon as they are known. If a match is found, the aircraft is “attached” to the assignment, which becomes “Active”. From there, all messages distributed to the flight assignment desks are sent to the user(s) matching the assignment’s responsible desk. If an aircraft cannot be attached to an existing assignment, or if assignment problem occurs, appropriate events are raised and processed according to the event handling configured (for Flight Assignment Errors or Flight Dispatch Events). The normal life or an assignment is the following in ASP: • • •

Scheduled or Scheduled (R): Original assignment as received from the flight operation system or repeated by ASP for a successive day. Active: An aircraft has started using the same flight parameters as an assignment and has been attached by the server. The aircraft will stay attached for the duration of its flight, even if at some point is uses a different FI than the assignment, purposely or not. Completed: When the aircraft lands and normally complete its flight.

The completed assignments are removed from the assignment table at the end of the current day. If one assignment remains scheduled for the extent of the day it should be flown on without being attached to an aircraft, it becomes delayed at the end of its day of operation: •

Scheduled or Scheduled (R): Original assignment for the date of operation.

•

Delayed: Assignment was still unattached at the end of its date of operation. The assignment remains valid and usable if the matching aircraft departs on the following day, unless the assignment is cancelled manually.

If a scheduled or delayed flight is cancelled for a given day, any dispatcher user can open the “My Flights” window and set the assignment to "cancelled":

283

ASP Administrator Guide Version 6.9a

•

Cancelled: Flight assignment has been manually cancelled to indicate that no aircraft will fly that flight for that day of operation.

The server processing and the whole of the dynamic flight assignment feature come together in the “My Flights” window:

Figure 9.111: My Flights Window

My Flights: All of the assignments collected by ASP are visible in the “My Flights” window, available from the main toolbar to all users configured with a “Dynamic flight assignment desk”, “Default master desk” or part of a group configured as such. The My Flights window shows all flights assigned to the logged user’s desk, their statuses and attached aircraft, as controlled by the Server processing. See the “My Flight” window description in the User Guide for all the details about it. Normally, all flying aircraft should be attached to an assignment. Departing aircraft may not be attached right away as they may not provide their FI, origin, destination and ETD right in the first messages sent. However, aircraft passed the OUT flight stage should all be attached to an assignment. If it’s not the case, then assignments may need to be corrected by having the flight operation system resend updated assignments. Or an aircraft may be manually attached or detached to/from an assignment as to manually fix bad attachments. Aircraft Tracking: The Aircraft Tracking window also displays which is the responsible desk for all aircraft tracked by ASP.

284

ASP Administrator Guide Version 6.9a

9.1.2. 9.1.2.1.

Uplink Message Storing What is Uplink Message Storing

Uplink message storing is a system-managed process allowing retaining uplink messages processed by AIRCOM® ServerPlatform until specified conditions are met. It applies to uplink messages sent from both external users and local users (using the Client New Uplink Message window). The conditions to hold an uplink are: (1) wait until the destination aircraft reaches a specified flight stage (“send in stage” condition) and/or (2) wait for a specified period of time (“send after” condition), (3) wait until an aircraft can be identified to exactly match a FI-only uplink, with the optional combination of the following conditions: origin and destination airports, estimated time of departure (ETD) day. Possible situations handled by the system when at least one of the above on-hold conditions exists: An uplink message specifies an aircraft identifier: The message is put on-hold for the specified aircraft (see Aircraft Tracking window – Queued Uplink Messages panel) according to the specified conditions (send after and send in stage). When the conditions are met, the reactivated messages (leaving the “UP: On-Hold” status) are sent to the aircraft. However, if the messages stay on-hold for longer than their on-hold timeout, the system will process them as an expired messages, and send the appropriate notifications back to the originating users. An uplink message specifies only a flight identifier: If it does not exist yet, a temporary entry is created in the Aircraft Tracking window to track the specific flight identifier with its origin and destination airports and ETD (if specified). When a downlink is received that specifies the same flight identifier and that the ETD day and origin and destination airports match, then the aircraft identifier is assigned to the temporary flight identifier entry and the other on-hold conditions (send after and send in stage) are evaluated. If they are immediately met, the message is reactivated for sending; otherwise, it stays on-hold until conditions are met or until it expires (on-hold timeout exceeded). A downlink message matches a template configured with the advanced option ‘Send on-hold uplinks for the aircraft when this downlink is received’: All on-hold uplink messages listed for the tracked aircraft are immediately reactivated and processed for sending, no matter the on-hold conditions they were waiting for. This allows a pilot to request such on-hold messages waiting to be sent to his aircraft.

9.1.2.2.

Involved Configuration

System Parameters – Default uplink on-hold timeout: Set the default maximum time period for which any uplink message can be kept on-hold. When this time expires, the 285

ASP Administrator Guide Version 6.9a

corresponding uplink messages are expired. This default value can be overridden in two places: (1) the advanced options of the uplink template and (2) the New Uplink Message window advanced options dialog (uplink from local user). Downlink Template – Advanced options: Optionally set a downlink template as a “trigger” template to release all on-hold uplink messages for the aircraft having sent a downlink matching the template. Uplink Template – Advanced options: Optionally set the on-hold conditions that will apply to any uplink message generated using the template, and override the system’s default on-hold timeout. New Uplink Message – Advanced options: Optionally set the on-hold conditions for the message(s) being generated and override the on-hold timeout specified in the template used to generate the message. Uplink Template from external user with “Flight Stage + Delay” field: Define an uplink template with a field of type “Flight Stage + Delay” to specify the “send in stage” and “send after” on-hold conditions from within an uplink from external user. When sending such uplinks, the messages must specify the field values in one of the following formats: (1) [flight stage name] (e.g. “OFF”) (2) [time period in minutes] (e.g. “15”) (3) [flight stage name]+[time period in minutes] (e.g. “OFF+15”)

9.1.2.3.

How to Track Stored Uplink Messages

Go to the Aircraft Tracking window, Queued Uplink Messages panel and look for the “UP: On-Hold” status. Note that each entry of the tracking table at the top of the window may have associated queued uplink messages and that the ‘Queued Uplinks’ column shows how many there are.

286

ASP Administrator Guide Version 6.9a

9.1.3. 9.1.3.1.

Mailbox Message Notification What is Mailbox Message Notification

The user itself configures its own mailbox message notification. The function allows each user to be advised of any new messages received in their inbox. The notification consists of visual notification via a dialog box and/or the Client application’s icon flashing in the Windows task bar, and/or audio notification with a sound playing according to the highest priority among the priorities of the received messages. Refer to document [S4a] under User Preferences for more details.

9.1.3.2.

Involved Configuration

User Preferences: The ‘automatic mailbox refresh’ under the User Preferences General panel must be set to a non-zero value. Under the Notification panel, the user desired settings must be set. If none of the three visual and audio notification check boxes are checked for all priorities, no notification will ever occur. Remember that only downlink messages may have different priorities. All other messages, ground messages including forwarded messages have no priority and notification for these messages is therefore driven by the ‘No Priority’ settings in the User Preferences window. Windows sounds: A set of default sounds used for audio notification are installed in the AIRCOM® ServerPlatform data path, under the Sounds sub-folder. The sounds are identified according to the following naming convention: “ASP Notification [priority level] – [priority name]”. Any user on the computer can change the sounds by replacing the wave files (we recommend keeping a copy of the original sound files). It is VERY important to keep the same file names as the original sound files delivered with the system. Also, make sure to use a sound of reasonable duration and avoid wave files that could include other data than the sound itself (e.g. lyrics). A sound change will take effect for all users of the computer. If the same user runs the Client application from another computer, his preferences are unchanged, but the sounds for audio notification could be different.

287

ASP Administrator Guide Version 6.9a

9.1.4. 9.1.4.1.

Deactivating Message Distribution to a User What is Message Distribution Activation

It is possible to block any message distribution to users of any type without losing any existing distribution and permission configuration relative to these users. This is also effective if the user is part of a group: whenever the group is used for message distribution, the inactive users of the group will be ignored. This can be useful for example to perform tests and deactivate a user for which there is a configuration problem, to activate user distribution only when the configuration is fully completed for the user, or to stop message distribution while a user is on vacation. Such inactive for distribution users show a gray icon in the users tree and are seen as grayed out when used for distribution related tasks elsewhere in the system.

9.1.4.2.

Involved Configuration

Users and Groups window: No matter what the user type is, any user can be activated/deactivated for distribution simply by checking or not the ‘Active for distribution’ setting in the ‘User Data’ panel. No other configuration is required, and it is important to note that whatever existing distribution and permission configuration exist in the system, it is not lost due to a user being deactivated for distribution. The configuration is still available, but it cannot be changed and it is ignored when processing message distribution as long as the user is inactive. Whenever the user is reactivated for distribution, the existing configuration also becomes active.

9.1.5. 9.1.5.1.

Performing Direct Type B Addressing What is Direct Type B Addressing

Direct addressing means that a Type B message coming into AIRCOM® ServerPlatform is addressed (via the Type B header destination address) to a Type B address other than the ASP’s address. Only configured Type B users can achieve such a scenario and it requires proper configuration outside of the ASP. For example, have the SITA Mega Switch configure a range of addresses to be routed to a customer’s AIRCOM® ServerPlatform system, or have a customer application redirect messages addressed to some specific addresses to ASP via any of the available communication links to ASP.

288

ASP Administrator Guide Version 6.9a

Once a message with direct addressing is received by AIRCOM® ServerPlatform, the system checks that the sender has the user right Allow direct type B addressing and if so, the message is not processed by the system and is directly routed to the intended destination without any message alteration (no formatting) except for the Type B originator which could be altered depending on the sender “Send ground Type B messages as” setting. If the user does not have the right to perform direct addressing, the message is dropped with proper event logging.

9.1.5.2.

Involved Configuration

The addresses that will be used for direct addressing shall be configured in the appropriate external system to route the messages to the customer’s AIRCOM® ServerPlatform system. The ASP’s type B external user wanting to perform direct addressing needs to have the Allow direct type B addressing user right.

9.1.5.3.

How to Use Direct Addressing

Once configured, there is nothing more to do then sending a Type B message addressed as desired.

9.1.6. 9.1.6.1.

Enhanced Uplink Routing What is Enhanced Uplink Routing

When enhanced uplink routing is set (section 7.1, System Parameters window, General tab, Uplink Handling), new rules apply for uplink routing. Preferred Data Link Service Provider (DSP) Different mechanisms have been added to provide deeper control over DSP selection to communicate with aircraft. In particular, an aircraft can be allowed to communicate using only a subset of specific DSP and each aircraft can override the global default DSP that is used when an aircraft is not currently tracked by AIRCOM® ServerPlatform (section 5.1, Fleet Configuration). Also, for each configured DSP, it is possible to force either the AP (airport) or GL (ground location) text element item (TEI) to specify a medium to use when sending an uplink message (section 0, Data Link Service Providers); this is enforced only when one of the above TEI is present in the incoming message.

289

ASP Administrator Guide Version 6.9a

Station Management All SITAONAIR VHF and VDL stations delivered with AIRCOM® ServerPlatform can be managed using the VHF Stations window (section 7.5). It is possible to add, remove, and import/export stations, including other provider stations. A station can define its own range or it may use its owner’s DSP default range. To help verify a station’s coordinates, links to locate the station on the FlightTracker map or on “Google Maps” are available. Aircraft Satellite Communication Handling The aircraft “SAT equipped” flag plays a significant role by allowing or not messages over satellite media if the aircraft is satellite equipped or not (section 5.1, Fleet Configuration). Aircraft tracking data is enhanced with a satellite active flag telling whether or not an aircraft can be considered currently under satellite coverage. An aircraft becomes satellite active when it sends a downlink message via satellite or when it sends a media advisory message (MED) with the ES (establish sat) satellite acquisition field value. On the opposite, an aircraft leaving satellite coverage can send a MED message with the LS (lost sat) satellite acquisition field value. Systematically, sometime after an aircraft reports ON or IN stage (configurable), the satellite active flag is reset. A new downlink template category – Media Advisory is used for this purpose with a special Media Status field type. Additionally, a new user right (a subset of the Send uplink messages right) allows controlling whether or not users can send uplink messages via satellite. Aircraft High Frequency Data Link (HFDL) Handling The aircraft “HFDL equipped” flag plays a significant role by allowing or not messages over HF media if the aircraft is HFDL equipped or not (section 5.1, Fleet Configuration). HF media is used as the last routing alternative if both VHF and satellite are not available, and it can be available only when under ARINC coverage. HF is used for routing (if available) not only under enhanced uplink routing, but also under regular routing rules. Aircraft tracking data is enhanced with a HF active flag telling whether or not an aircraft can be considered currently under HF coverage. An aircraft becomes HF active when it sends a downlink message via HFDL or when it sends a media advisory message (MED) with the EH (establish HF) HF acquisition field value. On the opposite, an aircraft leaving HF coverage can send a MED message with the LH (lost HF) HF acquisition field value. Systematically, sometime after an aircraft reports ON or IN stage (configurable), the HFDL active flag is reset. A new downlink template category – Media Advisory is used for this purpose with a special Media Status field type.

290

ASP Administrator Guide Version 6.9a

Enhanced Uplink Message Handling The concept of outdated tracking is introduced allowing the tracking data to be considered obsolete after a configured time period while the aircraft is in flight (not on ground). In other words, if an aircraft has not sent any downlink to update its tracking data in the last, for example 15 minutes, the tracked aircraft position is considered obsolete and the aircraft position is from then on extrapolated using the flight plan data. The flight plan extrapolation is more precise than before using a between-waypoint position extrapolation and determining the closest available station (VHF or satellite) to send uplink messages to the aircraft. This enhanced uplink routing takes into account all configured items described above, like SAT communication restrictions and preferred DSP settings. LIDO Flight Plan Support LIDO flight plans are now supported in addition to FlightPlanner flight plans and can be identified using uplink templates of category “Flight Plan”. These can be used to feed the enhanced uplink message handling described above.

9.1.6.2.

Involved Configuration

System Parameters (section 7.1) First, in the General tab, Uplink Handling frame, check the “Use enhanced uplink routing” option. This enables the use the feature. In the Tracking tab, Aircraft Tracking frame set the “Time to outdated tracking” to know when to start extrapolating positions with the flight plan and set the “Active over satellite timeout” to know when to reset an aircraft satellite active flag after landing. Data Link Service Providers (DSP, section 0) Mark the DSP that are satellite only (like QXT); do not mark those that communicate both via satellite and VHF. Make sure you have set the desired default DSP. Select a default stations range in nautical miles for each DSP (optional). Set the “Use GL or AP” to your preference. VHF Stations (section 7.5) Review the configured stations. Add missing ones; modify the existing ones, especially to specify their owner (preconfigured SITAONAIR owned stations delivered with the software are already set to QXS), make them use the owner’s default range, and if required, review their latitude/longitude settings.

291

ASP Administrator Guide Version 6.9a

If you have many modifications to perform, an alternate way is to export the stations configuration to file, perform the changes in the exported file and import the file. Fleet Configuration (section 5.1) Make sure the “SAT equipped” and “HFDL equipped” flags are properly configured for all your aircraft. As desired, define specific lists of DSP with which each aircraft is allowed to communicate with; by default all configured DSP are allowed for all aircraft. As desired, review the “Override default DSP” for each aircraft. If set, it overrides the global default DSP configured in the DSP window. Users (section 2.1) Flight dispatch assignment: Go through the users and define the “User mapping” where appropriate to map these users to flight dispatch assignment identification (refer to the two following topics for more details). Send uplink rights: Also review the Send uplink messages and Send uplink messages over satellite user rights for users that should or not be allowed to send uplink messages and those that should or not be allowed to send messages over satellite medium. Downlink/Ground Templates (section 0) Downlink templates: If desired, define a template of category “Media Advisory” in which you define a field of type “Media Status” which value will be set to ES (SAT established), LS (lost SAT), EH (HF established), LH (lost HF) and when sent to AIRCOM® ServerPlatform will mark the aircraft as SAT active/HF active or not (see Aircraft Tracking in document [S4b]).

9.1.7. 9.1.7.1.

Uplinks Hold & Wait Options What is the Uplinks Hold & Wait

When a hold period is active for a given aircraft, it causes the uplink messages of the set priority (and lower) to be held in queue. The messages are sent when hold is stopped or when their priority exceeds the hold configuration. A hold period can be started and stopped either by receiving specific downlink message properly configured or manually via aircraft tracking with the proper user privileges. Uplinks sent with wait options will be waiting in queue until the applicable flight stage and wait time are passed or until a downlink configured to send waiting uplinks is received from the aircraft (waiting uplinks for this aircraft only are sent). The uplink validity timer starts only when the uplink leaves the waiting status. 292

ASP Administrator Guide Version 6.9a

9.1.7.2.

Involved Configuration

Uplinks Hold Downlink Templates (section 0) Hold & wait options (Advanced tab): You decide which template start and stop uplinks hold periods. For those that start a hold period, define the priority of uplink message that are affected and the condition to stop the hold period once it has been started. Aircraft Tracking (document S4) Right-clicking on an aircraft, a user with Modify tracking data right can start a new hold period or stop an existing one. Uplinks Wait Uplink Templates (section 0) Wait options (Advanced tab): You decide which template will be waiting for some conditions before being sent to the aircraft and you define these conditions (a flight stage reached and/or a time period elapsed). You can also override the global system parameter for the maximum wait time and the uplink validity. Any uplink sent through this template (from an external user or system or using the ASP client New Uplink window) will be queued and fall into waiting state until either the conditions are met or until a downlink is received matching a template with the option “Send all uplinks waiting for flight stage or time conditions”. Aircraft Tracking (document S4) By going to the Queued Uplink Messages tab, a user with View aircraft tracking right can see which uplink messages are waiting due to the template configuration above. Right-clicking on an uplink (like a waiting uplink), a user with Modify tracking data right can cancel that uplink.

9.1.8. 9.1.8.1.

Uplink Delivery Status Notification (Uplink Acknowledgement) What is Uplink Delivery Status Notification

Uplink delivery status notification (or uplink acknowledgement) is used to let users know if an uplink succeeded or failed to be delivered. First, uplink acknowledgements can be sent to users other than the uplink originator using new uplink template event handling functions. Second, local users can receive acknowledgements for uplinks sent by other

293

ASP Administrator Guide Version 6.9a

users or by themselves (instead of having to check back their Outbox). Third, the format of uplink acknowledgement messages is configurable, per user, to use classic acknowledgements (MAS and SVC messages, as appropriate) or configurable formats using models associated with the new predefined ground templates for successful and failed uplink notifications.

9.1.8.2.

Involved Configuration

User configuration: Most user types support the notification of uplink delivery status. A user can be notified for the uplinks he sent (when originator) or when he is configured to be notified of uplink success or failure events (see below). No matter why a user is notified, the notification received can be formatted in three different ways: the default “Classic Ack” (MAS and SVC messages, as appropriate), “Classic Ack with full quote” (same as classic ack but with full uplink quote – because classic ack is limited to a 220 characters quote length), or “Using Uplink Ack templates” (fully configurable using ground template models – see below). Uplink event handling: Two events for uplink templates can be notified to users, either Successful Uplink Delivery or Failed Uplink Delivery. “Uplink Ack” ground models: The computer-generated ground templates “Uplink Ack (failed)” and “Uplink Ack (success)” are used to allow users to receive uplink delivery notifications in different formats. These formats are configured by creating different models for these templates. Ground templates distribution: The computer-generated ground templates “Uplink Ack (failed)” and “Uplink Ack (success)” must be configured in ground distribution to the desired recipients when these users are configured to use the uplink notification format “Using Uplink Ack templates”. This is where the different models can be associated to the users to be notified.

9.1.9. 9.1.9.1.

Excessive Downlink Detection What is Excessive Downlink Detection

To detect aircraft that generate an excessive number of downlinks, the system uses a threshold value configured per aircraft type. This value must not be exceeded within any one minute in order to consider the rate as normal. The system monitors the number of downlinks and the time between each and when it detects that the rate configured for the corresponding aircraft type is exceeded, it raises

294

ASP Administrator Guide Version 6.9a

an event. It then continues monitoring and raises another event whenever the rate returns to normal. The events raised are aircraft related, thus actions attached to these events can be configured through the Fleet Configuration event handling (see section 8.1.2).

9.1.9.2.

Involved Configuration

Aircraft types: The maximum number of downlinks received in one minute to consider the downlink rate as normal for a particular aircraft type (see section 5.4). Fleet configuration event handling: Two events can be raised when an aircraft exceeds its aircraft type configured maximum rate threshold: “Downlink rate exceeded” and “Downlink rate normal” (see section 8.1.2).

295

ASP Administrator Guide Version 6.9a

Tracking and Flight Following 9.2.1.

Tracking an Aircraft from ACARS and Non-ACARS Messages

The tracking of an aircraft in the Aircraft Tracking window, the FlightTracker and the FE Interface can be based on both downlink messages (ACARS) and ground messages (non-ACARS). The combination of the two allows non-ACARS-equipped aircraft to be tracked in ASP and ACARS-equipped aircraft to benefit from additional ground information that would not be available from downlinks alone.

9.2.1.1.

Downlink and Ground Messages Affecting Tracking

The tracking of an aircraft is based on a few key messages which can be downlink or ground messages, matching templates designed to extract the relevant data in each. The messages used in the tracking of aircraft are the following: •

OOOI (OUT-OFF-ON-IN flight stages): The downlink or ground messages corresponding to flight stage changes from the aircraft or ground applications must be configured with templates of category “OOOI” set with the appropriate stage. They are the most important messages in the tracking of aircraft and allow AIRCOM® ServerPlatform to properly track a flight from its preparation to its completion, as well as transition into another flight. Although there are four common stages in the flight operation world, AIRCOM® ServerPlatform supports six:

•

•

•

•

•

Init (optional): To be configured, as possible, on the first downlink and/or ground message received from or about an aircraft in its preparation for a flight. This message should include at least the FI properly initialized for the flight and, ideally, the origin and destination airport. This allows the tracking table to be set early in the flight and flight assignments to be readily used for dynamic distribution of messages to the dispatchers. OUT (optional but recommended): To be configured on the OUT downlink from the aircraft and/or the equivalent ground movement message. At this stage, the ETD (estimated) is considered ATD (actual); its value is adjusted to the OUT time. OFF (mandatory): To be configured on the OFF downlink from the aircraft and/or the equivalent ground movement message. If a flight plan was provided for this flight (for the same FI, departure, arrival and an ETD in range), it is loaded at this point and the ETA of the waypoints and the flight identifier are updated in reference to the OFF time. ON (mandatory): To be configured on the ON downlink from the aircraft and/or the equivalent ground movement message. Touch-and-go messages should also be configured as ON messages as they imply that the aircraft has landed. IN (optional but recommended): To be configured on the IN downlink from the aircraft and/or the equivalent ground movement message. At this stage, the flight is considered completed and the ETA (estimated) is considered ATA (actual); its value is adjusted to the IN time. Gate-return and air-return messages should also

296

ASP Administrator Guide Version 6.9a

•

be configured as IN messages as they all imply that the aircraft has returned at the gate. Summary (optional): To be configured on the downlink and/or ground message received from or about an aircraft that includes summary data about the flight. This stage is completely optional and indicates the last stage of completion for a flight.

•

Position Reports: Position report messages do not require a special category, any downlink or ground message is considered a position report as long as its template includes fields of type “latitude” and “longitude” which are automatically considered to report the aircraft position. As such, be careful not to use the “latitude” and “longitude” field types for other coordinates that don’t represent the aircraft position since they will be interpreted as a position report anyhow. Position reports are used to update the position of the aircraft in the aircraft tracking window as well as the FlightTracker and FE Interface.

•

ADS Reports: Automatic Dependent Surveillance reports are downlink messages respecting the AEEC 745 specification and are considered as position reports. Their format must however be decoded with special templates of category “ADS-C”.

9.2.1.2.

OOOI Flight Stages Transitions

In general, the data about the flight leg currently flown –referred to as the “flight data”– is updated in the tracking table on the reception of a downlink, uplink or ground message that contains relevant flight parameters. The flight data comprises the current flight’s FI, its origin/destination, ETA/ETD (or ATA/ATD when known), OOOI flight stages, times & fuel, reported positions and flight plan. An aircraft flying one flight leg and then another will typically go through the following sequence:

No stage (Init)

Out

Off

In flight

On

In

(Sum)

(Init)

Out

Off

Between flights

- First downlink received, aircraft appears in the tracking table; - Initial flight stage is ‘no stage’; - Flight data (FI, departure, arrival & other) is initially empty; - It will build up as messages are received throughout the flight.

- Init received; - Flight data is reset; - It will build up for the new flight from here.

For an aircraft that’s not tracked initially, a new flight is initiated at the first downlink or uplink received for it. A new tracking entry is then created for that aircraft, with its initial flight stage left blank (–) and all flight data unset. The messages received after are used to update the flight data for the flight that’s being prepared. 297

ASP Administrator Guide Version 6.9a

When a downlink indicating the OUT stage is received, the aircraft is considered “inflight”. The ETD is set to the OUT time and becomes the ATD, the actual time of departure. Throughout the flight, the flight data is accumulated as messages are received so that the latest status is always visible from the Aircraft Tracking or FlightTracker window. If a message is received using a different FI than the current one (any downlink, uplink or ground message other than an OOOI message), it will not update the flight data to minimize the consequences of FI-glitches. When the aircraft completes its flight and sends it’s ‘IN message’, the aircraft is considered “between flights”. The ETA is set to the IN time and becomes the ATA. The flight data for that flight will remain available and messages received after that will still be used to update it, until a new flight is detected to begin. A new flight is considered to be initiated when a message is received with the following: •

An OOOI message indicating the start of a new flight or using a different FI than the current one (an out-of-sequence event will be raised if the message is unexpected at that point in the flight);

•

Any downlink or uplink (except FI-only uplinks) using a different FI than the current one while the aircraft is not in-flight (after the IN stage).

When one of the above messages is received, the flight data related to the previous flight is cleared (FI, OOOI stage, Departure/Arrival, ETA/ETD, position reports and flight plan) and the new flight parameters from the received message are used from there.

9.2.1.3.

Identification of Flight Data in OOOI Messages

As such, it is important to make sure that the right FI is used in the OOOI messages and that is sometimes tricky. Because of some airport not having complete ACARS coverage, it is possible that an aircraft lands, completes its flight, initializes for its next flight and takes off without transmitting any downlink in the process. Instead, the aircraft keeps them queued and transmits them when the ACARS coverage is recovered, one after the other. ASP then processes the messages and flight stages transitions in an accelerated way. Although this scenario is generally well handled by ASP, it is often tricked by the fact that the FI has changed in the flight transition. This causes the queued ON and IN messages for the previous flight to be transmitted using the FI of the new flight, sometimes even after the OUT and OFF messages of that flight. This can cause the new flight to be reset and its data to be lost. So to ensure the flight transitions work well and the tracking data is properly updated, one needs to make sure that the OOOI templates matching the said messages are well configured.

298

ASP Administrator Guide Version 6.9a

For that, ensure that the OOOI templates properly leverage the values contained in the messages by identifying them with the following field types: •

Flight Identifier: even if downlink messages contain the flight identifier in the 620’s /FI TEI, the value is often that of the new flight even for messages relating to the previous flight (above scenario). To resolve that, find the flight identifier or flight number of the flight in the freetext of the message and identify it with a field type “Flight Identifier”. The flight identifier in the freetext will remain of the previous flight even if the 620’s /FI has switched to that of the new flight and ASP will take the value from the “Flight Identifier” field over the one from the /FI. This works even when only the flight number is capture as “Flight Identifier” since ASP will complete it with the operator code configured with the aircraft in the Fleet window.

•

Departure Airport and Arrival Airport: on the ICAO or IATA codes of the airports.

•

Out/Off/On/In Time: time of the movement, usually in hours & minutes (HHNN). This serves to properly timestamp the movement despite of the message being received late.

•

ETA: to properly have the ETA displayed in the Aircraft Tracking or FlightTracker windows.

When both downlink and ground OOOI messages are received for the same flight stage, the data contained in the downlink has precedence. This means that if the downlink is received first, the flight data in it will be used to update the tracking table; when the ground is received after, the existing values will not be updated. When it is the ground message that is received first, the flight data will be used to update the tracking table but when the downlink is received after, the flight data from it will overwrite the values from the ground message. The full logic is based on the following table, where the effect of different messages is described. An “OOOI” message is any downlink that changes the OOOI flight stage for one aircraft. A “normal” message is any downlink or uplink that contains both an aircraft (AN) and flight identifier (FI) specified explicitly. Same FI as in the tracking Aircraft in flight (INIT, OUT, OFF or ON)

Different FI than in the tracking

OOOI for a previous stage - Flight data remains unchanged - Out-of-sequence event raised

OOOI for a previous stage - Flight data cleared first, then updated from message - Out-of-sequence event raised

OOOI for an equal or later stage - Flight data updated from message

OOOI for an equal or later stage - Flight data cleared first, then updated from message - Out-of-sequence event raised

299

ASP Administrator Guide Version 6.9a

Aircraft between flights (no stage, IN or SUM)

Normal message (not OOOI) - Flight data updated from message

Normal message (not OOOI) - Flight data remains unchanged - Break of FI event raised

OOOI for a previous stage - Flight data cleared first, then updated from message

OOOI for a previous stage - Flight data cleared first, then updated from message

OOOI for an equal or later stage - Flight data updated from message

OOOI for an equal or later stage - Flight data cleared first, then updated from message

Normal message (not OOOI) - Flight data updated from message

Normal message (not OOOI) - Flight data cleared first, then updated from message Table 9-74: Aircraft Tracking and Flight Stages Handling

9.2.2. 9.2.2.1.

Flight Plan Handling Flight Plan Providers and Content

The various flight plan providers (like AIRCOM® FlightPlanner, LIDO, Jeppesen) generate different flight plan formats. To extract the information from your flight plans, depending on the flight planning system used, uplink or ground templates of category "Flight Plan" must be defined. By using this specific category, it tells ASP that the message is indeed a flight plan, but it also makes available a series of specific flight plan field types that are used by the ASP to properly handle flight plans and their data. A flight plan template can be defined with many meaningful field types, however, only a handful are really mandatory for a flight plan to be decoded. This allows a wider range of flight plan provider systems to be supported, including those not even providing a waypoint list. Flight Plan Field Types Flight plan specific field types are prefixed by "FP - ", although some data found in flight plans could also be extracted from other types of messages, in which case the corresponding field type is not prefixed by "FP - ", but should still be used where appropriate when defining the flight plan. Following is a short description of these field types and their use in flight plan handling. Field Type Name ETD ETA

STD STA

Description & Role Estimated Time of Departure and Estimated Time of Arrival. These times are subject to regular updates when a flight faces delays or is ahead of schedule. The ETD is also very important in the flight plan matching to a tracked flight (see section 9.2.2.2). Scheduled Time of Departure and Scheduled Time of Arrival. These times, as opposed to the ETD & ETA, should not change. The scheduled times represent the time (and date) at which a flight 300

ASP Administrator Guide Version 6.9a

is supposed to fly. Say a flight is taking off every day at 22:30 in the evening, and the flight of June 10 gets delayed by 3 hours, then the ETD becomes June 11, 1:30, but the STD is always June 10, 22:30.

Aircraft Long reg Aircraft Short Reg Call Sign

Flight Identifier Departure Gate Departure Airport Arrival Airport Arrival Airport Alternate (1, 2 and/or 3) FP - Identifier FP - Waypoint Name FP - Waypoint Latitude FP - Waypoint Longitude FP - Waypoint ETA FP - Waypoint Flight Level FP - Waypoint Fuel FP - Waypoint Weight

The STD & STA are used with Fuel Conservation Monitoring (FCM) - Flight Analysis, to compare actual gate out and in times against the scheduled times. If they are not available, then the first ETD & ETA that were provided will be used instead. These three fields are used to specifically identify an aircraft that will fly the flight specified by the flight plan. When an aircraft is specified in a flight plan, it becomes a matching criterion, i.e. when it is time to match a flight plan to a tracked flight, the aircraft identification must also match (see section 9.2.2.2). Specifies the flight identifier. Obviously, the easiest and safest matching criterion. Field to extract the departure gate, which is displayed in Aircraft Tracking. These fields are used to specifically identify the departure, arrival and alternate airports. In addition to be displayed in tracking flight information, the flight airports play a capital role in flight tracking and in flight plan matching to a tracked flight. Field to extract a unique flight plan identifier, to be displayed in Aircraft Tracking. The "Waypoint …" series of fields are used to extract data about each waypoint listed in the flight plan. The waypoint fields have to be defined inside of a record that will capture the list of all waypoints including the departure and arrival airports (otherwise, they will be added as the first and last waypoints). All waypoint fields are optional in a flight plan template. However, to get the flight plan to properly show on the FlightTracker map, at least the waypoint's name, latitude and longitude must be defined. Waypoint ETAs defined with an appropriate time format allow for a good extrapolation of aircraft positions. Waypoint ETAs should be defined as the relative elapsed time from the takeoff time, in number of minutes (such as "NNNN") or in hours/minutes (such as "HH:NN"). Waypoint ETAs can also be defined as the absolute UTC time at which the aircraft should cross each waypoint. To be considered an absolute time, the waypoint ETAs must be defined with at least a "day" component (such as "DD HHNN"); month and year can also be specified but if not, they will be added automatically. In any case, the ETA times will be displayed in absolute time in FlightTracker and recalculated at off time from the difference between the planned ETD and the actual take off time.

301

ASP Administrator Guide Version 6.9a

Waypoint flight levels allow altitudes to be displayed in the FlightTracker's flight plan panel and be used to evaluate whether or not an aircraft is inside an area defined with an altitude range. Be careful in using the right units for the value: use "Feet x 1" if a straight altitude in feet but use "Feet x 100" if a flight level.

FP - First Waypoint Time FP - Taxi Fuel FP - Enroute Fuel FP - Alternate Fuel FP - Holding Fuel FP - Additional Fuel FP - Total Loaded Fuel FP - Take Off Fuel FP - Landing Fuel FP - Gate Arrival Fuel FP - Tanker Fuel Reserve Fuel FP - Zero Fuel Weight FP - Take Off Weight FP - Landing Weight FP – ETOPS Airport FP – ETOPS Distance

Waypoint fuel and weight can be specified as informational but are not used in any calculation. The first waypoint time field is used only with partial flight plans as the absolute time from which the new waypoints replace the ones from a previous flight plan. See section 9.2.2.2 below. The "Fuel …" series of fields are used to extract fuel data. These are used with Fuel Conservation Monitoring (FCM) - Fuel Analysis and tracking flight information. The reserve fuel is not prefixed by "FP -" because it is allowed to get it from other type of messages.

A series of fields used to extract data about weight, to be displayed in the FlightTracker. For information only. The ETOPS series of fields are used to extract data about each ETOPS listed in the flight plan. They must be defined, in pairs, inside a record. All ETOPS fields are optional for a flight plan template. Defining them will however allow populating data automatically when selecting the (From current flight plan) ETOPS set under ETOPS panel.

302

ASP Administrator Guide Version 6.9a

Mandatory Flight Plan Field Types • At least one of the following field type: FI, Aircraft Long Reg, Aircraft Short Reg, Callsign • Departure Airport • Arrival Airport • A departure time: ETD or STD • An arrival time: ETA or STA

9.2.2.2.

Matching to a Tracked Flight

When a flight plan is received, it is stored and the system tries to match it to a tracked aircraft & flight. If it does not match, it stays available to be matched later on. Flight plans can be updated anytime during a flight whether they are already matched to a tracked aircraft & flight or not. Matching a flight plan to a tracked aircraft or replacing an existing flight plan (flight plan update) both follow these rules: •

The received flight plan’s flight identifier (FI), departure airport and long registration number (AN, if specified) must match the corresponding values of the existing flight plan or of the tracked aircraft.

•

The ETD of the new flight plan must be between no more than 1 hour prior and 5 hours (configurable) passed the ETD of the existing flight plan or of the tracked aircraft. If no ETD has been received for a tracked aircraft, the actual departure time (OUT time), if available, is used as the comparison criterion.

Two more rules apply when a flight plan is used to replace a previously provided flight plan: •

If the STD field is configured in the flight plan template, a flight plan will be replaced only if its STD is exactly the same as the STD of the new one.

•

Partial flight plan replacements are only accepted while the aircraft is in flight (passed the OFF flight stage). Partial flight plans do not begin at the departure airport but from a waypoint along the route of a previous flight plan, defining only the waypoints from thereon. When the first waypoint of a partial flight plan corresponds to one in the previous flight plan, the replacement of waypoints is made from this point. When there is no correspondence, the replacement of waypoints is made from time defined as the "first waypoint time" field.

A waypoint is valid if it has at least a name or a lat/long or an ETA. Invalid waypoints are ignored and the rest of the flight plan is still processed. Alternatively, a flight plan can be

303

ASP Administrator Guide Version 6.9a

defined without a list of waypoints. In that case, the flight plan will be created from the departure and arrival airports only, with a great-circle trajectory in between.

9.2.2.3.

Flight Plan and Pre-Departure Clearance (PDC)

If the "Validate PDC with flight plan" setting is on (System Parameters, Message Handling tab, PDC Handling panel), uplinks of category PDC are tested against a flight plan to determine if a negative or positive response is sent to the FAA (using the PDC Acknowledgment predefined ground template). The PDC Departure Time value is compared to the flight plan ETD following the rules described in section 9.2.2.2. If no matching flight plan is found, the PDC message is trashed and a negative response is sent to the FAA. On the other hand, if the "Validate PDC with flight plan" setting is off, as soon as an uplink of category PDC is received, a positive response is sent to the FAA.

9.2.3.

Callsign Handling

9.2.3.1.

Flight Identifier vs Callsign

The flight identifiers and callsigns are two ways to identify flights to ASP and air traffic control: •

The flight identifier is the IATA identification of a flight composed by the 2-letter IATA code of the operator followed by the operator's given flight number of up to 4 digits: e.g. “XS0175”. The flight identifier is normally used in ACARS communications (as the /FI value in 620 messages) and in most airline-related messaging.

•

The callsign is the ICAO identification of the flight usually composed of the 3-letter ICAO code of the operator and the same flight number up to 4 digits: e.g. “SIT0175”. However, European ATC may require a different identifier to be used, in which case a completely different flight number will be given, this time with a 1 or 2-letter suffix: e.g. “SIT45AB”. This new callsign identifier will not match or even be similar to the flight identifier so a mapping is needed to relate the flight identifier with the callsign. The callsign is usually used in ATC messages and ADS-B and radar positions.

Flight identifiers are the primary way by which ASP tracks flights (completed with the AN, dep/arr airports and ETD or STD), callsigns are usually displayed for information only. And it would be that simple if all ACARS messages contained the proper flight identifier as their /FI value.

304

ASP Administrator Guide Version 6.9a

However, because of the constraint by which flights have to be identified by callsign to the ATC, the downlink messages sent by the aircraft often use the callsign as the /FI value in place of the real flight identifier. This “callsign as an FI” uses the IATA operator and the number from the callsign: e.g. “XS0175” or “XS45AB”. When only numerical, there is no problem because the number part of the callsign matches that of the flight identifier and there is no contradiction with the real flight identifier. But when the callsign contains letters, the number/letters part doesn’t match the real flight identifier and the mapping cannot be done. In releases before V6.8, this used to cause two different flights to be tracked, one using the flight identifier and one the callsign, each with only a portion of the whole flight data. From V6.8 on, ASP recognizes when a callsign is used as the FI and identifies it right away as a callsign; visible in the callsign box of the Aircraft Tracking and FlightTracker windows. If other messages later use the real commercial FI for the same aircraft, then the FI is added to the tracked data and displayed as the rightful FI. Even better, if the flight plan sent to ASP contains both the commercial FI and the callsign then the two values can be identified with the fields of type “Flight identifier” and “Call Sign” and ASP will use the mapping right from the start. Note that all other references to FI in the rest of the application (Traffic Log, Event Log, Mailbox) stays the same, the FI displayed is the one used by the aircraft, be it a real FI or a callsign.

9.2.3.2.

Mapping Flight Identifiers to Callsigns

AIRCOM® ServerPlatform can store the two values separately for the flights it tracks, however it has to know the mapping between the flight identifier and the callsign. This mapping can be provided in the following manners: •

By flight plan: The best and most reliable way is in the flight plan provided to ASP ahead of the flight. In the flight plan both values can be provided using fields of types “Flight Identifier” and “Call Sign”. When ASP matches the said flight plan to an aircraft, it will know both values and store them for the rest of the flight.

•

By FlightAware: FlightAware, like ASP, harmonizes the flight data from different sources into a consistent set of flights – as such, it often provides both the flight identifier and callsign values in the flight data sent to ASP. ASP then stores the info in its tracking.

•

By successive messages: The mapping between flight identifier and callsign can also be done by having the flight identifier used in some messages (say, ground messages) and the callsign in other messages (downlinks in the /FI) as long as all messages relate to the same aircraft (identified by the /AN value in 620 messages or by using the “Aircraft Long Reg” field type).

305

ASP Administrator Guide Version 6.9a

9.2.4. 9.2.4.1.

Canceling Queued Uplink Messages What is a Cancelled Uplink

A cancelled uplink is a queued uplink that has been marked for deletion by a user. The system then deletes the uplink, cleans and updates all dependent data (e.g. changes the status of the uplink in the user’s mailbox if it were sent from a local user), and sends appropriate uplink confirmations to the originating users as per the usual uplink confirmation rules.

9.2.4.2.

Involved Configuration

The user wanting to cancel an uplink must have the View aircraft tracking or View FlightTracker, and Modify tracking data user rights in order to be able to cancel uplinks. In addition, some uplinks must be queued (pending) for some tracked aircraft.

9.2.4.3.

How to Cancel Uplinks

Open the Aircraft Tracking window. To cancel all uplinks for a specific aircraft, select it in the top-most grid and right-click to select “Cancel All Uplinks” and confirm the operation. The number of queued uplinks is shown for an aircraft in the ‘Queued Uplinks’ column in the grid. To cancel specific uplinks, select the appropriate aircraft from the top-most grid, select the Queued Uplink Messages tabulation, and select one or more uplink messages. Rightclick, select “Cancel Uplink(s)” and confirm the operation.

9.2.5.

Duplicate Message Handling

It is a mechanism that detects downlink messages that are considered as a duplicate of a previously received message. Duplicated messages are trashed by the system and these can be easily identified in the traffic log looking for entries with status “Duplicated” ( ). Duplicate downlink message detection has always been done using the following rule: if a message has the same flight number, SMI, message sequence number (MSN) and data link service provider (DSP) as the last message from the same aircraft, the messages are considered duplicates.

306

ASP Administrator Guide Version 6.9a

Starting with V3R5, the above way to detect duplicates is still available, but an enhanced duplicate detection algorithm is introduced. First, duplicate message criteria are checked against a list of previous messages from the same aircraft (the list length and message expiry within the list are configurable). Second, the DSP is not considered in the duplication criteria anymore, and an SMI can be identified as equivalent to other SMI, making them identical for message duplicates analysis. Basic and enhanced duplicate message handling is configured through the System Parameters window (Tracking tab, section 7.1).

307

ASP Administrator Guide Version 6.9a

9.2.6. 9.2.6.1.

Dynamic Frequency Management (DFM) What is DFM?

DFM is a feature introduced in V4R1 to dynamically manage the frequencies used by the aircraft to tune VHF ground stations as to maintain them over SITAONAIR’s frequencies and not ARINC’s. The DFM controls the frequencies used by the aircraft by sending “scan table” and “auto-tune” uplinks at appropriate times as it travels across different coverage zones throughout its flight. As everything in AIRCOM® ServerPlatform, the DFM is very flexible and configurable. The moments to send the DFM uplinks can be set by configuration based on flight stages, geographical location of the aircraft and on various conditions collectively referred to as “events”. And with events, actions can be configured and executed once the events occur. The events and actions to be executed are bound to the route flown by the aircraft and so, all the DFM configuration is based around those routes. A route is an individual flight leg determined by its origin and destination airport, not by FI. The two directions of the same flight (go and return) are considered two separate routes. Any aircraft flying a given route will be bound by the same events and actions configuration. The events configurable for a given route are those that can require DFM actions: •

Aircraft at stage {Init, Out, Off, On, In, Summary};

•

Diversion from planned route (new destination airport);

•

Downlink received from ARINC;

•

Enter area {X};

•

Leave area {X};

•

Scan table {successful or failed};

•

Auto-tune {successful or failed}.

For each event, one or many of the following actions can be configured: •

Notify one or many users;

•

Send auto-tune uplink with {tune frequency};

•

Send scan table uplink with {scan frequencies};

•

Send event {number} to FE;

•

Change aircraft priority to {x};

•

Stop DFM until the end of the flight.

By defining areas corresponding to the locations where scan tables and auto-tune uplinks must be sent, the position of the aircraft (actual or estimated) entering or leaving those

308

ASP Administrator Guide Version 6.9a

areas triggers the appropriate actions. Areas can be defined in FlightTracker Map and requires the FlightTracker Areas license and the Manage FlightTracker areas user right. Refer to document [S4b] for further instructions.

9.2.6.2.

Involved Configuration

The DFM configuration is divided among different windows, with the “Flight Routes Event Handling” window being the central point for DFM events and actions, and other windows supporting the core configuration. The different elements relate to each other as described in the following diagram. FT Map Areas Flight Routes Event Handling

Brazil N-America Japan China …

Routes

Events

Brazil Inbound Miami - Rio Miami - Sao Paulo Santiago - Rio … Brazil Outbound Rio - Miami Rio - Santiago Sao Paulo - Miami … N-America - Japan Japan - N-America Japan - China China - Japan …

At stage Out At stage Off At stage On Enter FSD area Brazil Diversion Downlink from ARINC Scan Table Successful Scan Table Failed …

ACARS MU DLM700 M4.2 DLM900 101 DLM900 151 …

Actions Notify 5 users Send scan table Brazil Send auto-tune Brazil Send event 5555 to FSD …

DFM Frequency Sets Frequency Sets

Frequency Strings

In Brazil - Scan Table In Brazil - Auto-Tune In Japan - Scan Table In China - Scan Table In China - Auto-Tune …

(any) - E131725XS/E131550XS/D131450XA/… DLM700 M4.2 - /////////////////1/1/1/0/0/1/1/0/0/ DLM900 101 - E136850XS/D131450XA/D130600XS/… DLM900 151 - D131450XA/E131725XS/E131550XS/… …

Fleet Configuration

Uplink Templates Distribution

Aircraft

Type

ACARS MU

Aircraft

Template & Model

XS-AAA XS-AAB XS-BBA XS-BBB …

B747-400F B747-400F B757-200 B757-200

DLM700 M4.2 DLM700 M4.2 DLM900 101 DLM900 151

XS-AAA XS-AAB XS-BBA XS-BBB …

Frequency Auto-Tune - Model 900 151 Frequency Scan Table - Default Model Uplink to Display - Default Model Uplink to Printer - Default Model …

Uplink Templates Templates & Models Legend Blue box: DFM-specific configuration Gray box: Generic / common configuration

Predefined Templates Frequency Scan Table Default Model Model 900 151 Frequency Auto-Tune Default Model …

QU {@DEST TYPEB} .{@AIRCOMSRV TYPEB} {@ORIG DTG} M32 FI {@FI}/AN {@AN} - {@SCAN FREQUENCIES} QU {@DEST TYPEB} .{@AIRCOMSRV TYPEB} {@ORIG DTG} VMA FI {@FI}/AN {@AN} - FS1{@SCAN FREQUENCIES}

Figure 9.112: Dynamic Frequency Management Configuration

309

ASP Administrator Guide Version 6.9a

Each window works as follows. Flight Routes Event Handling Window The Flight Routes window is the one where the DFM behavior gets put into place. It contains all the routes on which dynamic frequency management should happen, the events for which things should be performed and the actions to take as a consequence. A given route (origin-destination pair) can have more than one possible configuration but only one can be active at any time – it will be the one used for aircraft flying it. The return flight for the same origin-destination pair has to be configured as a different route. Routes configuration is hierarchical. For each route, the events & actions can be configured at the route level for each individual route or, more simply, at a parent folder level so that all routes under it “inherit” the events & actions configured for it. This much simplifies configuration when different routes share commonalities (for instance: all routes from North-America to Brazil will need the same scan table uplink to be sent when entering Brazil) and the common events & actions can be configured only once, at a parent folder, rather than repeated for all routes. Then the route-specific events & actions can be configured at the route level, either by configuring new events & actions or by overriding inherited ones. Inherited events & actions are displayed in gray, native ones (including events overriding inherited ones) are displayed in Windows text color (typically black) with the “Override” box checked.

Figure 9.113: Example of inherited and native events & actions for a route

310

ASP Administrator Guide Version 6.9a

FlightTracker Map Area Manager Window In the routes configuration, the enter and leave area events are bound to geographical zones defined with the FlightTracker Map Area Manager window corresponding to the areas where DFM actions must be taken. When an aircraft enters and leaves an area, an event is generated with the details about the aircraft and the name of the related area. If the aircraft that generated the event is flying an active route using that area in an event, the associated actions are executed. The areas must however be configured in the FlightTracker Map Area manager window (see document [S4b] for further instructions). This configuration must also precede the configuration of routes and events for the area names to be available in the routes window. DFM Frequency Sets Window The Frequency Sets window is the place where all the possible scan table and auto-tune frequencies are defined, for all supported aircraft and MU. The configuration is two-folds: 1) All the wanted scan table and auto-tune frequencies must be defined for all the regions in the world for which DFM must take place. Frequency sets must be given a meaningful name so that what they do is clear to the administrator configuring the route events & actions (such as “Brazil – scan table” for the scan table frequencies that will enable 131.550 and disable unwanted frequencies). 2) For all given frequency sets, one or many frequency strings can be configured based on the format variations imposed by the different ACARS MU used across the aircraft fleet. Each frequency string expresses the same frequency set, just in the format needed for the related MU to accept it. If the same frequency string works for all types of aircraft across the fleet, than a single frequency string must be configured and associated with the ACARS MU “any”. If a frequency string is expressed differently for different aircraft, all variations must be configured and associated to possible ACARS MU mounted aboard aircraft defined in the Fleet window. The frequency strings for the auto-tune and scan table uplinks are configured separately, with frequency sets defined as type “scan table” or “auto-tune”. Auto-tune frequency strings only require the configuration of the frequency to auto-tune on. Scan table frequency strings require the list of all frequencies to be enabled and disabled. For example, the frequency set for scan table “Brazil” could be configured with two different frequency strings, one for ACARS MU “DLM 900” and one for “DLM 700”: • •

DLM 900 : E131725XS/E131550XS/D131450XA/D131550XA/D131550XB DLM 700 : 1/1/1/0/0/0/1/0/0/0

311

ASP Administrator Guide Version 6.9a

Fleet Configuration DFM has triggered two changes to the Fleet Configuration window: •

A DFM enabled checkbox controls whether an aircraft participates in DFM or not. By default, all aircraft have that setting turned off. Aircraft supporting DFM must therefore have their DFM enabled check ticked on before flying DFM routes. Otherwise, no DFM will take place even if the route flown by the aircraft is properly configured.

•

The other modification to the window is that the possible values for the ACARS MU parameter are taken from those configured in the ACARS MU window, as to ensure consistency across the fleet.

ACARS MU Window The ACARS MU window is a simple window to list all possible values for the MU installed across the fleet of aircraft. With DFM, these values take a more important meaning and consistency is important. The upgrade to V4R1 automatically takes the existing MU values in the fleet and populates them in the ACARS MU window. The ACARS MU window will therefore contain all MU values configured across the fleet. However, it is possible that this process reveals discrepancies such as having one MU being expressed as “DLM 900” for one aircraft and as “DLM-900” for others, although the intent was to designate the same MU. In such a case, one of the two MU variations must be chosen and the other deleted. Before doing so, however, the aircraft using the second variation must be modified to use the proper one. Computer-Generated Templates As part of the DFM functionality, two predefined computer-generated uplink templates are provided as part of the default delivery (referred collectively as the DFM templates): • Uplink Computer-Generated - Frequency Scan Table Update • Uplink Computer-Generated - Frequency Auto-tune The “Scan table” template shall be provided with the following default model: QU {@DEST TYPEB} .{@AIRCOMSRV TYPEB} {@ORIG DTG} M32 FI {@Flight Identifier}/AN {@Aircraft Long Reg} - {@SCAN FREQUENCIES}

The “Auto-tune” template shall be provided with the following default model: QU {@DEST TYPEB} .{@AIRCOMSRV TYPEB} {@ORIG DTG} M31 FI {@Flight Identifier}/AN {@Aircraft Long Reg} - {@TUNE FREQUENCY}

312

ASP Administrator Guide Version 6.9a

It is however possible, for a user with sufficient privileges, to create, modify and delete the models for both DFM templates (including the default one). The format to use for DFM uplinks shall be determined by the configuration of the “Uplink Templates Distribution” window, using the proper model formatting for each aircraft participating to DFM. This covers for the different SMI and free text formats required by the different aircraft.

9.2.7.

FE Interface

Some features of the FE Interface require or benefit from data provided by AIRCOM® ServerPlatform’s (ASP) ACARS data processing. The below presents a quick overview of these features and what needs to be configured on the ASP side to feed FE Interface.

9.2.7.1.

Positions reported on the ground

Aircraft can report positions while being on the ground, taxying on between the gate and runway. Aircraft can also report ADS-B positions on the ground which can be received by ASP through its connection with third-party providers. In any of these cases, ASP will display the aircraft on the ground at the reported position and share the data with FE. This feature used to be a licensed option called "Ground Movement Advisories" (GMA) without which positions on the ground would be trashed – this is no longer the case. Ground Positions Prerequisites 1) Aircraft avionics to generate position messages while on ground with sufficient accuracy (ideally not less than one thousandth of a degree) or ADS-B reporting while on the ground. 2) Configure the ASP downlink position report templates. The same templates as inflight position reports can be used, but the latitude and longitude fields’ format should be reviewed as it affects data accuracy. 3) Get and install detailed (zoomed-in) airport maps for the airports a customer flies to within FE Interface. Ground Positions Limitations Reported aircraft positions can operate with a limited level of accuracy and some sources of inaccuracies are: 1) The aircraft reported position accuracy, in other words the precision of the source data provided by the aircraft positioning system via its avionics, which is at best limited to one thousandth of a degree. 2) The FE Interface display accuracy limited to one thousandth of a degree. 3) The alignment accuracy of the detailed airport map over the FE Interface world map (could depend on the airport map provider). 313

ASP Administrator Guide Version 6.9a

Note that one thousandth of a degree corresponds to a maximum distance of 157 meters and varies with latitude.

9.2.7.2.

Fuel On-Board (FOB) Range Rings

FE Interface allows displaying an FOB range ring for an aircraft. This ring represents the maximum distance an aircraft can travel based on remaining fuel, at a defined speed. The remaining fuel is calculated as the FOB from which the reserve fuel is subtracted. AIRCOM® ServerPlatform can provide the specific reserve fuel of an aircraft to FE using the “Reserve Fuel” field type in a template. Any template category can include this field type, thus the reserve fuel can be specified from any source like a flight planning system, the pilot, or a ground operator using a specific message. It is important to specify the units for the reserve fuel value; this is done in the template’s field definition. Without this dynamic reserve fuel value, FE can only calculate the range rings based on a fixed reserve fuel value per aircraft type using a static text file. The computing and display of FOB range rings based on dynamic reserve fuel figures provided by ASP on a flight-by-flight basis requires the use of at least FE Client 9.1b.

9.2.8. 9.2.8.1.

FE Offline Mode What is FE Offline Mode?

The FE offline mode allows operating the FE Interface even when the FE Servers are not available or not accessible. The FE Client then takes its positioning and flight planning information directly from the AIRCOM® ServerPlatform database via ODBC when started using the ASP client “FE Offline” menu option under the FE main menu. Remember that for the FE to be available, the AIRCOM® ServerPlatform license key must include the FE option.

9.2.8.2.

Involved Configuration

A SQL stored procedure is required to operate the FE in offline mode. It can be obtained by contacting your AIRCOM® representative and specifying the subject “Stored Procedure for the FE Offline Mode”. The latest stored procedure works for FE 8.5 and higher. The following section must be added to the “FE.ini” file located under the FE Professional installation path. [ODBCINGEST] DBIP=IP address of the ASP database server DBName=Database name of the ASP database

314

ASP Administrator Guide Version 6.9a

DBLogin=User name used to log on the ASP database DBPw=Password used to log on the ASP database (not encrypted) DBSP=dbo.usp_FSDOfflineTracking (use FSDOfflineTracking for FE version 8.1)

The AIRCOM® ServerPlatform client needs to be restarted for the “FE Offline” menu option to appear in the FE drop-down menu.

9.2.9. 9.2.9.1.

ETA Changed Event and Notification What is ETA Changed Event & Notification?

The system can be configured to notify some users if the Estimated Time of Arrival (ETA) changes after takeoff. A minimum and configurable time difference between the new ETA and the previous one has to exist in order to notify, and the users to notify as well as the format of the notification messages are configurable. The “ETA changed” event is triggered if the ETA changes by at least the configured threshold since the event was last triggered (or since the original ETA). The previous ETA is then either the original take off ETA typically set via a flight plan, or the last in-flight ETA that has triggered an “ETA changed” event. In other words, if the current ETA is 10:00 at takeoff and the “ETA changed event threshold” is set to 10 minutes, if the ETA changes once to 10:07 (less than 10 minutes), no “ETA changed” event is raised. However, if it changes a second time to 10:15, then the “ETA changed” event is raised because it changed by 15 minutes compared to 10:00. In this case, the “ETA” predefined model field value is 10:15 and the “ETA PREVIOUS” field is 10:00. Then, if the ETA changes a third time to 10:27 (12 minutes difference with 10:15), another “ETA changed” event is raised with an “ETA” value of 10:27 and “ETA PREVIOUS” of 10:15. ETA changes are considered only after take-off because ETA update messages are meant to update the destination airport (that reserves “slots” for the aircraft) on delay or advance taken during the flight that were not accounted for in the original flight plan. ETA changes before the OFF movement are announced by updated flight plans and do not interest the destination airport until the aircraft has actually taken off.

9.2.9.2.

Involved Configuration

ETA changed event threshold: Expressed in minutes, this value must range between 1 and 999 minutes. It is the threshold that is used to raise the ETA changed event. The threshold is compared to the difference between the current ETA (upon an ETA update) and the last ETA that triggered the ETA changed event. If the event never occurred, it compares to the original take off ETA. ETA changed event: This is configured via the Fleet Configuration event handling and it can be used to notify users of the ETA change. The event name in the “Event Handling” dialog shows the currently configured “ETA change event threshold” value. When the

315

ASP Administrator Guide Version 6.9a

system detects that the ETA changed event should be raised, it processes the configured notification. ETA update predefined ground template: This template pre-exists and it cannot be deleted or duplicated. A default model also pre-exists and it can be edited. New models can also be added as needed. These models are used to format the ETA changed notification messages for different users. Using the predefined fields “ETA” and “ETA PREVIOUS” you can provide the previous and current ETA data in the notification message. The “ETA PREVIOUS” field provides the ETA when it was last notified (or the original take off ETA). ETA update ground distribution rules: In the ground distribution rules, click on Flip View, select computer-generated for “Show templates”, select the “ETA Update” template and select the users you expect will be notified. Then select the proper model for each user. You can use the keyboard Ctrl-A in the users list to select them all, check one of them and the default model will be used for each user. Or use “Distribute all templates ‘Computer-Generated’ using the default model”, but be advised that using this setting will apply to all computer-generated templates, not only the “ETA Update” template.

9.2.10. Fuel Conservation Monitoring (FCM) 9.2.10.1. What is FCM? Fuel Conservation Monitoring is a licensed feature adding value by collecting data regarding flight timeline and fuel all for all flight phases, allowing in-flight monitoring and post-flight analysis using reports. The ultimate goal is to identify processes and procedures that affect fuel efficiency and to promote actions that will generate fuel economy. The monitoring is performed through the Aircraft Tracking window, via two new tabs: Flight Analysis and Fuel Analysis. Post-flight analysis is performed using Crystal Reports custom reporting against the system's flight log. Note that the flight log history length is controlled via the System Parameters' "Purge & Archiving Job" configuration.

9.2.10.2. What to Configure to Use FCM? In order for FCM to be useful, some basic configuration needs to be performed, mostly linked to template configuration to extract proper data from key messages. First, make sure an uplink template of category "Flight Plan" is configured to extract planned time and fuel values, because these are essential to the FCM comparisons between planned and actual values. These comparisons are capital to the analysis that can lead to fuel economy. Refer to section 9.2.2.1, "Flight Plan Providers and Content" for more details on flight plan content. It is worth mentioning that the flight plan STD and STA

316

ASP Administrator Guide Version 6.9a

fields, if available, should be defined, otherwise, the original or first ETD and ETA specified when the flight started to be tracked will be used instead for gate out and gate in time comparisons. Second, make sure to extract actual data from proper downlink (or ground) messages using the appropriate templates and fields. The essential field types to use for FCM are: ETD, ETA, Out Time, Off Time, On Time, In Time, Fuel, APU Status, and Engine [*] Status. APU Status and Engine [*] Status are used specifically for FCM to indicate the current running status of each engine, but also to cumulate run time for each of them, per flight phase. Also, FCM provides comparisons and event notifications involving two sets of nominal time that need to be defined via System Parameters, Tracking tab. First there are the long taxi time thresholds (taxi-out and taxi-in). They are used to compare with actual taxi times, and by configuring actions for the corresponding events in Fleet Configuration (see section 5.3.3.3, "Define Event Handling for the entire fleet"); notifications can be sent when the actual taxi times exceed the nominal ones. Second, the "At gate APU usage threshold" is used to perform event handling notification when the APU run time exceeds the threshold when the aircraft is at gate, either at flight start or after gate in. To do so, configure actions for the corresponding event in Fleet Configuration (see section 5.3.3.3, "Define Event Handling for the entire fleet").

317

ASP Administrator Guide Version 6.9a

9.2.11. Using the Sequencer 9.2.11.1. What is the Sequencer? The Sequencer is a powerful tool in AIRCOM® ServerPlatform to accomplish tasks based on criteria that are not simply determined by the flow of messages. A sequence is a combination of actions and criteria organized in steps to perform a complex task. The Sequencer's general concept, the actions and criteria are described in section 5.13: "

318

ASP Administrator Guide Version 6.9a

Sequencer Window". This section focuses on the building of sequences to resolve real-life problems and their dependencies on other configurable elements in AIRCOM® ServerPlatform such as templates. Three demonstration sequences are described later in this section and can be used as starting point for other sequences: •

Auto-request position reports: Automatically request position reports to the aircraft if no position has been received within the previous 15 minutes.

•

Auto-request position reports and alerts if no positions: Automatically request position reports to the aircraft if no position has been received within the previous 15 minutes. Raises an alert if no position has been received within the previous 20 minutes. Closes the alert as soon a position is received.

•

Send init data in order: When the init request is received, request INIT data, FP, WINDS and PERF data to ground systems. Return the init response right away but hold the others until requested. When REQFP is received, send FP, WINDS and PERF in order separated by 1 minute intervals. Don’t send PERF if the aircraft is already in the air.

319

ASP Administrator Guide Version 6.9a

9.2.11.2. Constructing a Sequence Every action and activity yields a binary result, for an action: successful vs. failed; for criteria: true vs. false. That result shall then be used to determine what's to do next. With the steps results, a sequence can be organized to do things in order when everything goes as planned. Taking an example where a 4-step sequence is sending 4 different messages to the aircraft or to some users, a normal successful sequence would execute as follows: 1

2

3

4

End

However, if a failure occurs at step 3 because the related message cannot be delivered (distribution not configured, message not arrived, aircraft not under coverage, …), the failed result for that action can be set to go to step 5 instead of continuing so that something else is done, like notifying some users of the situation: Fails! 1

2

3

4 5

Abort

Criteria can also be used to steer a sequence in doing different actions based on the state of the aircraft and its messages. The same true and false step results can be configured for that. Using step results, sequences can even go back to previous steps and repeat actions if appropriate. Actions and criteria assembled together and linked by step results allow administrators to plan sequences to resolve many problems. Before configuring a new sequence, it helps to have a good understanding of: •

what needs to be accomplished exactly,

•

what messages will be received for that, and when,

•

what messages will be sent, in which order,

•

and what should be done if one of these messages is missing.

Incoming messages will have to be received and decoded with downlink, uplink and ground templates. Those messages can be sent right away to the aircraft and users, or serves only to obtain data stored in custom fields and not sent anywhere. Uplinks can be kept waiting for the sequencer to send them instead of being sent right away. Outgoing messages will have to be formatted using models. These can be models straight under the templates of the incoming messages if sent as soon as received. They 320

ASP Administrator Guide Version 6.9a

can also be models under computer-generated templates that will be sent by the sequencer only when required. In this case, data from incoming messages may be stored in custom fields temporarily and used in the computer-generated templates. If one of the expected message is not received (or if a configuration element like the distribution is missing), the action using it will fail. What should be done in this case should also be known. Use the failed activity result to abort the sequence (and most likely, notify some users) or branch to another step that will send backup messages to the aircraft or the users. When all that is determined, prepare a schematic representation of what should be done by the sequence and what should happen if any of the steps fails. Then number each of the steps, even those related to exceptions, and you will have a clear representation of your sequence. Here's a short example: Start when: Uplink “SOME DATA” received

Send ground message “REQ MORE DATA”

1

success

2

fail

Wait for ground message “MORE DATA” or timeout after 5 minutes

success

3

Send uplink “SOME DATA & MORE”

fail

4

Send uplink “MISSING DATA”

321

ASP Administrator Guide Version 6.9a

9.2.11.3. Demonstration Sequence: Auto-request position reports The first demonstration sequence is a pretty simple one which has for goal to automatically request position reports to the aircraft if no position has been received within the previous 15 minutes. Incoming and outgoing messages: •

Downlink template "Position Report": Template matching a position report sent by the aircraft. The data in it is used to display the aircraft position on the FlightTracker and FE maps. The aircraft should send it automatically but the FANS contracts don't always use the wanted frequency of 15 minutes.

•

Uplink template "Request Position" computer-generated: Template with a model that requests the aircraft to send one position.

Sequence parameters:

The start criterion for the sequence is that the aircraft is off:

The first step is not an action but a “wait for” activity:

No action is taken yet, the first step is just to wait for a position report downlink. The sequence will wait on that step until one is received from the aircraft. Note the "From this point only" checkbox which indicates that the criterion shall not consider position reports that might have been received before this step has run. If one position report is received, there is no need to request another one so no action should be taken. The result is therefore set to "goto step 1" which will do nothing else than wait again for a new position report.

322

ASP Administrator Guide Version 6.9a

In the case where no position report is received, the timeout is set to 15 minutes. If no position report is received within the time the step last started, the step will fail. The timeout result is therefore set to "continue" which will proceed to the next action:

The action is to send the computer-generated uplink "Request position". Since the template is computer-generated, the system just creates a new uplink every time the action is run; there is no need to wait for an external message or anything. The action will wait for the uplink to be delivered successfully to the aircraft before calling it a success. The sequence will remain at that step until that moment. If the the uplink is delivered successfully, the "action successful" result will then occur and will go back again to step 1 waiting for the next position report. If the uplink cannot be generated, sent or delivered (for any reason including uplink expiry), the action will fail and it's the "action failed" result that will get executed. In this case, the configuration is to go back to step 1 also but the "Notify" check will cause a notification to be sent to the recipients designated in the event handling settings for the "Notify on activity failed/false". Which means the wait / request cycle will continue even if one uplink did not succeed. The sequence will however end when the stop criterion is realized, which in this case is set to be the on stage:

So with only 2 steps in this sequence, it is possible to ensure an aircraft will send position reports at least every 15 minutes. And if positions are received more frequently than that, the sequence will run only on step 1 without ever sending a request position uplink. Obviously if something more fancy than that needs to be done when, say, the request position uplink fails, a step can be added to do something else and then return to step one. Or wait for a shorter period and retry the uplink again. The possibilities are pretty open.

323

ASP Administrator Guide Version 6.9a

9.2.11.4. Demonstration Sequence: Auto-request position reports and alerts if no positions The second demonstration sequence show another way to automatically request position reports to the aircraft if no position has been received for some time. However, if no position report is received soon after the request, a condition and an alert are raised. The condition and the alert are closed as soon as a position report is received. Because this sequence is relying on the “Position” criterion, instead of the “Position Report” template, all position sources are taken into account: ACARS, radar, ADS-B, etc. Only actual position reports are used; the estimated positions are ignored. Outgoing message: •

Uplink template "Request Position" computer-generated: Template with a model that requests the aircraft to send one position.

Sequence parameters:

The start criteria for the sequence is that no position is reported for more than 15 minutes since the aircraft is off:

As soon as the start criteria are matched, a position is requested from the aircraft:

A computer-generated uplink "Request position" is sent. Since the template is computergenerated, the system just creates a new uplink every time the action is run; there is no need to wait for an external message or anything. If the action fails, the “Notify” check will cause a notification to be sent to the recipients designated in the event handling settings for the "Notify on activity failed/false". However, the sequence continue anyway.

324

ASP Administrator Guide Version 6.9a

The step 2 wait for any of following criteria to come true (note the “OR” in the first column): either the aircraft landed, a position has been reported or no position has been reported for 5 additional minutes (20 minutes total):

When the first criterion of the step 2 is true, that means the aircraft landed so the sequence is ended:

When the second criterion of the step 2 is true, that means a position has been reported so there is no need to raise a condition: the steps 5 to 7 are skipped:

If the execution get at this point, that means no position has been reported for more than 20 minutes. In that case, a condition and an alert are raised to draw the attention of FlightTracker users on the flight:

325

ASP Administrator Guide Version 6.9a

The step 6 wait until the condition can be closed (note the “OR” in the first column): either the aircraft landed or a position has been reported:

The condition and the alert are then closed:

The step 8 wait for any of following criteria to come true (note the “OR” in the first column): either the aircraft landed (that may be already the case) or no position has been reported for more than 15 minutes:

When the first criterion of the step 8 is true, that means the aircraft landed so the sequence is ended. Otherwise, a position must be requested from the aircraft and that is why the step 1 is the next step:

326

ASP Administrator Guide Version 6.9a

And the last step is the "Stop criterion" that, in this case, does absolutely nothing. We cannot move the “Flight stage >= On” criterion from the steps 2, 3, 6 and 8 here because the condition would not be closed when the aircraft lands:

By duplicating this sequence, it is possible to enhance the tracking of missing position reports. For exemple, in the copy, change all occurences of “15 minutes” and “20 minutes” by “25 minutes” and “30 minutes” respectivly and change the alert level from “Medium” to “High”.

9.2.11.5. Demonstration Sequence: Send init data in order The third demonstration sequence is one that would be executed at a flight's initialization for B747 aircraft so that the right initialization messages are sent to the aircraft in the order it needs them, no matter in which order they have actually been received by AIRCOM® ServerPlatform. The trigger to that is the reception of the INIT REQUEST downlink from the pilot, containing the FI and the day of flight. That template is distributed to back end systems that will provide the wanted data to be sent to the aircraft; but with the order controlled by the sequencer. This is by no means the real sequence for B747 but rather one to use as example to demonstrate the various capabilities of the Sequencer. When the INIT REQUEST downlink is received, request INIT, FP, WINDS and PERF data to ground systems. Return the INIT RESPONSE right away but hold the others until requested. When FP REQUEST is received, send FP, WINDS and PERF at 1 minute intervals. Don’t send PERF if the aircraft is already off. Incoming and outgoing messages: •

Downlink template "INIT REQUEST": Contains the FI and day of operation. Distribution is set to 4 ground systems, each with its appropriate model, and each system will receive its part of the data: init data, flight plan, winds data and performance data. Each response will be captured by its own template.

•

Uplink template "INIT RESPONSE" from external user: Contains the init data response. Distributed to the aircraft with the proper model. This one is meant to be sent right when received so it is left to be sent normally without the Sequencer intervening.

•

Downlink template "FP REQUEST": Received when the pilot is ready to receive the flight plan and other flight initialization data.

•

Uplink template "FP" from external user: Contains the flight plan. Distributed to the aircraft with the proper model but not meant to be sent before a REQFP has been received from the

327

ASP Administrator Guide Version 6.9a

pilot. For that, the template's advanced parameters are set to send uplink "when triggered by the Sequencer" only. •

Uplink template "WINDS" from external user: Contains the winds data. Distributed to the aircraft with the proper model but meant to be sent only after the flight plan. The template is also set to be sent only "when triggered by the Sequencer".

•

Uplink template "PERF" from external user: Contains the performance data. Distributed to the aircraft with the proper model but meant to be sent only after the winds uplink, and only if the aircraft is still on the ground. Like the others, the template is set to be send "when triggered by the Sequencer".

•

Uplink template "MISSING DATA" computer-generated: This template is to be sent only if one of the other uplinks could not be sent to tell the pilot to contact the base to get the appropriate data.

Sequence: This sequence is meant to apply only, say, the B747 aircraft which require that order of messages. If other aircraft types required a different order, a similar sequence could be created (or duplicated) and arranged specifically for the applicable aircraft and aircraft types:

The sequence should start only when the "INIT REQUEST" downlink is received from the aircraft:

The INIT REQUEST downlink template is distributed to the back end systems already so there is nothing special to do in the Sequencer for that to happen. The systems receiving the requests should however return the wanted data, which will then match the appropriate templates already configured in the system: • • • •

Uplink template "INIT RESPONSE" Uplink template "FP" from external user Uplink template "WINDS" from external user Uplink template "PERF" from external user

The uplink template "INIT RESPONSE" is configured to be sent to the aircraft as soon as received. For that, the template's advanced settings use the default send uplink option: "on reception/creation".

328

ASP Administrator Guide Version 6.9a

The other 3 templates should be sent only after being requested by the pilot. Their advanced settings should therefore set to the send uplink option "when triggered by the Sequencer". They will therefore be received but kept waiting in queue instead of being sent right away to the aircraft. The next step is therefore to wait for the flight plan request downlink from the pilot:

With the “wait for” activity, the sequence will halt at this point until the "FP REQUEST" is received. Note that the "From this point only" checkbox is unchecked so that if the "FP REQUEST" has been received before this step started, it will turn true right away and continue. The timeout set for the wait is 10 minutes and the timeout result is to continue as well. This is set so that if the pilot has not requested its flight plan 10 minutes after its init (the start of the sequence), the flight plan and init messages will be sent anyway. So both results continue on. The next steps are therefore to send the "FP", the "WINDS" and the "PERF" uplinks one after the other. As the FMC needs some time to process each message, a wait 1 minute action is inserted between each message sent. Before sending the "PERF" uplink one “evaluate if” step has been added since it was said that the uplink should be sent only if the aircraft is still on the ground. If the early steps of the sequence have taken some time and the aircraft has taken off during that time (unlikely in this sequence, but there anyhow for the example), the "PERF" uplink will not be sent. So for all the uplink sending, we get the following steps:

329

ASP Administrator Guide Version 6.9a

In this sequence, there are no checks to confirm if the "FP", "WINDS" and "PERF" uplinks have been received before being sent by the send uplink actions. This means that the sequence assumes these have been received by the time the sequence gets to the send actions and that the uplinks are already "waiting for sequencer". If that is not the case when the send uplink action gets to execute, the action will fail and execute the "failed" result. If the action should wait for the related uplink to be received before being attempted, then a "wait for " step should be inserted before the send uplink action to confirm that the said uplink has been received. Note that all the above actions goto step 8 if failed. This is a simple way to send one uplink to the aircraft to tell it that some data has been missing and that, say, the pilot should contact the ground to get things resolved. This is accomplished by sending a "MISSING DATA" uplink that is computer-generated. This uplink is created by the system when required and doesn't rely on an external message being received first:

330

ASP Administrator Guide Version 6.9a

And the last step is the "Stop criterion" that, in this case, does absolutely nothing:

The sequence is set to end after step 5, 7 and 8 on specific results and does not need an explicit stop criterion. However, if the last step of the sequence were using "Continue" as a result, the continue would fall in the stop criterion which would be considered as a normal "End". And in any case, if a sequence has not ended at the moment the flight it's running for is terminated (or, in other words, that the next flight is starting and the flight data is cleared), all running sequences will be aborted, no matter where they are in their execution.

9.2.12. Using Flight Route - Alerting (FR-A) 9.2.12.1. What is FR-A? Flight Route - Alerting is a feature offered in collaboration with our weather partner DTN where flight plans received from a local flight planning system (excluding FlightAware) are monitored for specific weather conditions. Each time a new flight plan is received or an existing one is updated, the flight plan is sent to DTN for monitoring. There are two levels of conditions monitored: “advisory” for first level thresholds, “warning” for second level. The conditions monitored and their thresholds depend on the category of the aircraft flying the flight plans. Whenever weather conditions exceed the set thresholds over the flight plan route or its departure, arrival or alternate airports, the details of the conditions are sent back to FlightTracker with the appropriate “advisory” or “warning” levels. The flight plans monitored by FR-A are displayed with a thick colored line around their route and with colored shading on the airport symbols: green for normal, blue for advisory and purple for warning. The same conditions also raise events that can be actioned on in the Flight Event Handling window. Actions can be configured to execute when weather conditions, new 331

ASP Administrator Guide Version 6.9a

or updated, exceed the "Advisory" and "Warning" thresholds (raise event) or return below thresholds (close event). The notify user(s) action will send descriptive messages about the advisory and warning conditions along the flight plan. The raise alert will raise alerts conditions on the affected aircraft and show the notifications on the FlightTracker map. The configured actions will be executed for current and planned flights. Note that the users configured in the "notify users" action of the advisory events will also receive messages for the warning events, even if not part of the notified users list. Those configured in the warning events only will receive messages on warnings only, though they will include the advisory level descriptions as well.

9.2.12.2. Involved Configuration Prerequisites For FR-A to be usable, the Weather and the FR-A license options are required, as well as being activated on your DTN account. The same account is used for the normal weather displayed on the map and the FR-A, as configured in the System Parameters window, Third Parties tab. For the communication with DTN to be established and links opened, the “FR-A Connector” must be installed on the server platform. It requires no configuration as the DTN addresses are automatically connected to when the FR-A connector is started. Two links will be opened, called the LINK_FRA_OUT and the LINK_FRA_IN, both of which can be monitored from the status monitor page. Flight plans are monitored from the moment they are received and submitted to DTN, as planned flights, and during the duration of the flights they associate to, until landing. Whenever flight plan updates are received, they are re-submitted to DTN with the updated data. Flight plans are also updated at take-off to account for the new reference time and whenever the flight’s ETD (up to take-off) or ETA is updated. Only flight plans received from a flight planning system (decoded with a flight plan template) are submitted for FR-A; flight plans received from FlightAware are not. Aircraft Types and FR-A Categories The weather conditions that are monitored for the FR-A depend on the category of the aircraft flying the submitted flight plan and the alarms configured for it. There are 3 FR-A categories, defined as follows: •

Category A: commuter/regional aircraft

•

Category B: narrowbody aircraft (default when aircraft unknown)

•

Category C: widebody aircraft 332

ASP Administrator Guide Version 6.9a

The “FR-A category” is configured in the Aircraft Types window for each configured aircraft type. By default, each aircraft type is associated to FR-A “category B” so the setting must be reviewed to ensure that the proper category is set for each aircraft. The same default “category B” applies for flight plans that are not associated to an aircraft or one for which the aircraft type is known. This will cause flight plans for aircraft that are undefined or unknown to be submitted for monitoring as of category B aircraft, and later when associated to an active aircraft of a known category to be re-submitted for the corresponding category. Conditions Monitored The weather conditions monitored for each category are predefined in the system as per the tables below. There are route and airport conditions. There route conditions are those monitored along the route of the flight plan, defined by its waypoints. The waypoints combine to constitute flight segments, defined by the waypoints’ latitude, longitude, altitude, and time offset from the departure time (estimated before the off movement, actual after). The monitoring for conditions considers the ETA at each waypoint and the segments in between, adding a lateral tolerance of 20 NM on each side and a vertical tolerance of 4000 ft above and below. This means that weather conditions that are not directly on the flight plan route but within its tolerance will be reported as advisories or warnings on the flight plan. The conditions monitored for the route are the following: Route Conditions EDR turbulence

Type EDR 0.1 to 0.9

Operator >=

Icing

Category: Slight, Moderate, Severe

Thunderstorms

Yes / no

exists

Volcanic advisory

Yes / no

exists

>=

Level Advisory Warning Advisory Warning Advisory Warning Advisory Warning

Category A 0.3 0.4 Slight Moderate yes yes

Category B 0.4 0.5 Moderate Severe yes yes

Category C 0.4 0.5 Moderate Severe yes yes

333

ASP Administrator Guide Version 6.9a

There are also airport conditions which are used for the airports specified in the flight plan. This includes at minimum the departure and arrival airports but also the alternate airports if provided with the flight plan: departure alternate (aka: take-off alternate, TAL) and up to 3 arrival alternate airports. The airport’s coordinates are used for monitoring local weather conditions with an added tolerance radius of 50 NM. METAR and TAF reports for the airports are also used when available. The time reference for the departure and departure alternate (TAL) airports is the ETD and for the arrival and arrival alternates, the ETA. The conditions monitored for the airports are the following: Airport Conditions Value type & unit Observed or forecast Altitude: ft ceiling

Operator =

METAR

Flight Category: VFR, MVFR, IFR, LIFR

>=

TAF

Flight Category: VFR, MVFR, IFR, LIFR

>=

Observed precipitation

Precipitation type: Rain, Mix, Snow

=

Warning Advisory Warning Advisory Warning Advisory Warning Advisory Warning Advisory Warning

Category A 300 ft 200 ft 750 m (0.47 mile) 600 m (0.37 mile) 20 kts 25 kts 25 kts 30 kts MVFR IFR IFR LIFR Snow

Category B 300 ft 200 ft 750 m (0.47 mile) 600 m (0.37 mile) 20 kts 25 kts 25 kts 30 kts MVFR IFR IFR LIFR Snow

Category C 300 ft 200 ft 750 m (0.47 mile) 600 m (0.37 mile) 20 kts 25 kts 25 kts 30 kts MVFR IFR IFR LIFR Snow

The weather conditions and thresholds are predefined for the 3 aircraft categories in this release. If these do not correspond to your airline's need, they can be updated by using custom-designed scripts that will modify the data directly in the database. For that, you must engage AIRCOM® support at [email protected]. Flight plans are monitored from the moment they are received and submitted to DTN, as planned flights, and during the duration of the flights they associate to, until landing. Whenever flight plan updates are received, they are re-submitted to DTN with the updated data. Flight plans are also updated at take-off to account for the new reference time and whenever the flight’s ETD (up to take-off) or ETA is updated. Only flight plans received from a flight planning system (decoded with a flight plan template) are submitted for FR-A; flight plans received from FlightAware are not. Traffic Log For FR-A to be working, a special FR-A connection is maintained with DTN by the “FR-A connector”. The bi-directional connection is established by the FR-A connector first (out from the server) and then over a websocket for the incoming data. Both connections are encrypted so flight plans sent out and alerted on are not visible to others. 334

ASP Administrator Guide Version 6.9a

All exchanges with DTN are made using XML messages formatted and decoded by the FR-A feature and, like any other messages in and out of ASP, are logged in the Traffic Log.

335

ASP Administrator Guide Version 6.9a

The direction and message types logged for the FR-A are the following: Direction

Message type

Description

Out Gnd

FR-A Flight Plan Submission

The initial submission to DTN of a flight plan, along with the set of alarms to monitor and their threshold. These should be seen soon after the reception by ASP of new flight plans.

In Gnd

FR-A Flight Plan Created

The response from DTN confirming that the flight plan has been received and validated.

In Gnd

FR-A Flight Plan Tracked

The confirmation that the flight plan is being monitored for weather alerts.

In Gnd

FR-A Flight Plan Alerts

A set of advisory and warning alerts for a flight plan according to the thresholds sent at submission. ASP decodes these alerts and displays them on the FlightTracker map as well as raises the proper advisory and warning events from the Flight Event Handling configuration.

Out Gnd

FR-A Flight Plan Update

When an existing flight plan is already being tracked and an updated one is received, only an update of the flight plan is sent to DTN.

Out Gnd

FR-A Flight Plan Update Times Update of ETD and ETA times following a change of either value or the flight’s OFF movement sending the actual departure time for recalculation of alerts.

In Gnd

FR-A Flight Plan Updated

Confirmation that one of the above 2 updates has been received.

Out Gnd

FR-A Flight Plan Stop

Sent when a flight is landed or completed to inform DTN to stop monitoring the flight plan.

In Gnd

FR-A Flight Plan Untracked

Confirmation that a flight plan has stopped being monitored.

In Gnd

FR-A Flight Plan Error

Response by DTN to a submitted or updated flight plan where errors prevent the flight plan to be properly tracked. When such error is received, the flight plan will display with the yellow-brown error color on the FlightTracker map and no events will be raised for it. To see the error text, look at the “” element in the XML of the received error message. There are a number of errors that can happen in normal scenarios, and from which FR-A will recover. These are the following: • • • • •

Flight plan already exists Flight plan already being tracked No tracked Flight plan found for … No flight plan found for … Attempted to update with an identical flight plan

Other errors should not happen very often. However, if you think you receive too many of these error, please extract a sample of Traffic Log with a filter on MessageType “FR-A” (including all FR-A messages) and at least one hour of log preceding the error, and export it to pdf (using the Reports > Export function). Then send to [email protected].

On a system where many flights and many flight plans are received, this can create a significant volume of new messages. If these are annoying, they can easily be removed from filters by filtering out the FR-A messages types (Message type “FR-A” – exclude).

336

ASP Administrator Guide Version 6.9a

FlightTracker Map Flight plans that are monitored with FR-A are displayed on the FlightTracker map with a thick colored line around the flight plan and color-coded airports. The FR-A colors for the flight plan segments or airports are as following:

 Gray: flight plan submitted, waiting for response from DTN  Green: normal – no weather condition reported on segment or airport  Blue: advisory – there are one or many “first level” weather conditions reported  Purple: warning – there are one or many “second level” weather conditions reported  Yellow-brown: error – flight plan could not be monitored (see traffic log to find error message, if any), or no response has been received from DTN after 2 minutes of submission.

Each FR-A segment and airport can be clicked to display an infobox describing the condition of the clicked item, normal or with advisories or warnings.

Figure 9.114: Alert notifications for FR-A advisories and warnings

See document [S4b] for the details of the flight plan colors and alerts shown from the flight event handling.

337

ASP Administrator Guide Version 6.9a

Flight Event Handling The last step in the configuration of FR-A is to set some events to be alerted when FR-A conditions are detected on the submitted flight plans. In the Flight Event Handling window, the FR-A events can be created under the “Flight Route - Alerting” folder: •

FR-A [Advisory] will raise for flights where one or many advisory conditions are detected

•

FR-A [Warning] will raise for flights where one or many warning conditions are detected

See section 0 “

338

ASP Administrator Guide Version 6.9a

Flight Route - Alerting (FR-A)” above for how to configure these events. For each event, the two below actions can be configured: •

Notify user(s) to send messages describing the advisories and warnings detected on the flight plan route or its airports.

•

Raise alert to display an alert on the related flights with the affected items.

The Notify user(s) action will send a message to each user selected in the users list. The messages sent will describe where the advisories and warnings are on the flight plan. Alerts that are opened for the first time on a new or updated flight plan will show as “new” alerts. If updated alerts are received at a later time, the new ones will be shown with “new” and those that were already reported on will show as “continuing”. Likewise, if raised alerts later close, they will be shown as “closed”.

339

ASP Administrator Guide Version 6.9a

This is an example of a notification message for a flight from Paris to Montreal: Flight Route Alerting: update for flight [XS0025, LFPG‑CYUL], aircraft [AC‑0010/Category B]: Departure airport LFPG @ 03:31 Advisory (new): TAF En route Advisory (new): EDR Turbulence on LESLU‑(+3)‑GOBIKF Warning (new): Thunderstorms on TOC‑REDBY Advisory (continuing): EDR Turbulence on GOCYUL‑(+1)‑TOD Arrival airport CYUL @ 11:21 No advisory or warning received Alternate 1 airport CYMX @ 11:21 No advisory or warning received

In notifications messages, all the elements that are monitored as part of the FR-A are listed: route and airports. Those that don’t have alerts will show with “No advisory or warning received”. Airports that are not listed in the message are not monitored for that flight. The monitored elements are always listed in their chronological order with the flight plan: • • • • • • •

Departure airport Alternate departure airport (if included in flight plan) En route, with the list of segments affected Arrival airport Alternate arrival airport 1 (if included in flight plan) Alternate arrival airport 2 (if included in flight plan) Alternate arrival airport 3 (if included in flight plan)

Airports are identified by their ICAO code and monitored time (ETD for the departure airport(s), ETA for the arrival airport(s)) and listed with the name of the alerts opened for them: Departure airport LFPG @ 03:31 Advisory (new): TAF

For the en route element, only the segments that have alerts are listed, identified by their two waypoints. Whenever several segments have the same condition, they are combined on one line and identified by the first and last waypoints of the affected segments with the count of waypoints omitted in between. En route Advisory (new): EDR Turbulence on LESLU‑(+3)‑GOBIKF

340

ASP Administrator Guide Version 6.9a

The Raise alert action will raise an alert for the flights having advisories or warnings, as configured, to be seen by everyone. Wherever there are warnings, there will most often be advisories as well since they raised for lower thresholds that will be exceeded if the warning levels are hit. The alert notifications will show on the map and list the elements affected by alerts: Dep, TAL, En route, Arr, Alt1, 2, 3.

Figure 0.115: Alert notifications for FR-A advisories and warnings

341

ASP Administrator Guide Version 6.9a

Maintenance 9.3.1. 9.3.1.1.

Setting-up Database Archiving What is Database Archiving

Archiving is the process of moving messages, traffic log and event log entries from the online database to an archive database. Archived data is accessible and messages are even editable (delete or file a message, acknowledge status, read status) from the Client application as long as the archive database is well configured and accessible. All other AIRCOM® ServerPlatform configuration resides only on the online database. The system is fully functional when the archive database is disabled and it does not affect normal operation. The most important advantage of using archiving is reduced downtime for maintenance operations, especially for large databases. Because the online database will be significantly smaller and of predictable size, any maintenance like a new release upgrade will run faster than before. Any operation such as upgrade of the archive database will be able to run in the background without affecting the online operations. Another advantage resides in quicker data display in the Client when filtering in online mode due to the reduced amount of online data. On the other hand, querying in historical mode for larger amounts of data from the archive can run longer (configurable) without affecting the online operations performance. This is also true when generating reports. Hence the maximum number of data rows or records returned in historical filtering or to produce reports has been increased to 250 000 entries. A bonus effect of the archiving implementation is the ability to cancel queries at any time and get partial results in the user mailbox and log viewers. This is very useful for large and long historical queries.

342

ASP Administrator Guide Version 6.9a

9.3.1.2.

How is Database Archiving Used

When an archive is configured and active, the Client connects to the archive database at login, hence both online and archive database connection statuses are available from the application’s status bar. When requesting data and browsing through, it is transparent to the user whether data comes from the online or the archive data source, unless the archive is active but unavailable. If for any reason the archive database gets disconnected but is still active, the Client will try to reconnect automatically on demand, like when refreshing the mailbox. If it detects the archive database is unavailable, it will stop retrying on the next data refresh to avoid potential connection delays during regular operation, until the user refreshes the archive database status by clicking on the corresponding LED in the status bar; the LED is red when the archive is active but disconnected or unavailable, grey when the archive is not active, and green when active and connected. Data is retrieved from the archive database when a user wants to view either its mailbox or logs (traffic or event) in historical filter mode. When filtering in online mode, the filter is applied only to the online database and no data will ever be retrieved from the archive database even though the time span extends beyond what is available from the online data. This typically provides very good performances if the archiving period is not too long. When filtering in historical mode, data is retrieved from online and/or archive data sources as needed according to the filter time span.

9.3.1.3.

How to Setup and Configure Database Archiving

First, setup the archive database by referring to section Archive Database Creation of document [S2] for details. Second, configure the archive related database System Parameters and enable the archiving (section 0). Once configured, the archiving operation is performed by a task that moves the messages and logs to the archive database and/or deletes them according to the purge parameters. This task typically runs once a day and is scheduled though System Parameters (section 9.3.2).

9.3.2.

Configuring the ASP Purge and Archiving Job

The configuration of the purge and archiving is entirely done via the System Parameters window, Database tab, Purge and Archiving Job panel (refer to section 0 for detailed field descriptions).

343

ASP Administrator Guide Version 6.9a

Purge and archiving can be enabled or disabled individually, but when both are enabled they run sequentially in a single process. The process can be scheduled to run once a day at a specified time or it can be run manually directly from the System Parameters window ("Run Now" button). To run the job daily, specify the UTC time at which you want the job to start. It is highly recommended to set a time of low traffic and activity. For the parameters "Work on xx entries at a time, then wait yy ms", we recommend the default values of 5000 entries and 2000 ms. You would want to tune these values either to have the job run faster with reduced system performance or to take more time to complete with increased system performance.

9.3.3.

Important Notice Regarding Purge and Archiving Job

Be aware that the Purge parameters apply to both the Online and Archive databases and that data removed based on the Purge settings is permanently deleted and cannot be recovered. Also note that purge parameters will always have precedence over the “Archive after” setting. For instance, if the purge for Messages is set to 5 days and the “Archive after” to 10 days, messages will always be purged before reaching the Archive database.

9.3.3.1.

Purge

For the purge to run daily: 1) Select the data you want to purge by checking the corresponding items (user messages, traffic log, events, and flight logs). 2) Specify the number of days of data you want to keep for each of these data objects. 3) Review the scheduled time. 4) Press the "Enable" button (if not already enabled). 5) Save the changes. 6) The job will run at the next scheduled time, but you can test it immediately using the "Run Now" button.

344

ASP Administrator Guide Version 6.9a

9.3.3.2.

Archiving

For the archiving to run daily: 1) Check the "Archive logs and messages after" option. 2) Specify the number of days of data you want to keep in the online database; older data will be moved to the archive database. 3) Review the scheduled time. 4) Press the "Enable" button (if not already enabled). 5) Configure the archive (Archive Database Settings panel) and enable it (if not already enabled). 6) Test archive the connection ("Test Connection" button). 7) Save the changes. 8) The job will run at the next scheduled time, but you can test it immediately using the "Run Now" button.

9.3.3.3.

Monitoring

It is good practice to regularly verify that the job runs daily without problems to maintain a reasonable online database size and better system performance. To achieve this, use the "Last run" and "Status" fields in the Purge and Archiving Job panel. If the last run exceeds a day, it did not run. If the status is not green (successful), then open the Event Log and find the log entries for that last run (each job execution is logged even when successful). The event descriptions will indicate what failed or what was skipped, if any. Another useful piece of information is located in the Online Database Info and Archive Database Info panels System Parameters window, Database tab). These indicate the data and transaction log file sizes, the number of entries for the size intensive data and how many days old each of these include. This can be correlated to the purge and archive settings to validate that the job works as expected and diagnose any problems it may encounter.

345

ASP Administrator Guide Version 6.9a

External System Interfaces 9.4.1.

Connecting to an External Database

The database connector allows AIRCOM® ServerPlatform to connect to customer databases to insert or update data into them (write) and/or retrieve data from them (read). It can interact with the databases in either one of these two modes: "stored procedure" or "query", each described in the following section. Using a database connection to an external database is probably the best way to extend AIRCOM® ServerPlatform's capabilities into solving problems that cannot be solved with its built-in mechanisms. These are processes that often require some special business logic or data that extend beyond those of ASP. With the database connector, ASP can be connected to a database other than its own that provides both the needed business logic and the data it requires. Business logic is implemented through proper scripting and/or stored procedures while the underlying data is stored in tables appropriately designed for it. This process understandably requires some proper planning and design. When done properly, in collaboration with ASP administrators and database administrators (DBAs), some very powerful processes can be put in place. The interface to external database is flexible enough to allow complex problems to be resolved … or created. When using the database connector: •

Plan carefully.

•

Think about all the possible outcomes or mishaps: what if data already exists? what if data is missing? how long can this process take? etc.

•

Test the entire solution before taking it to prod.

•

And last, closely monitor the results once put in place.

The database connector supports two data providers: SQL Server and ODBC. The ODBC data provider allows connecting to almost any kind of database, including Oracle databases. The connector can connect to multiple databases simultaneously. However, for a given database link, at most one connection is opened at a time,

346

ASP Administrator Guide Version 6.9a

9.4.1.1.

Connecting using stored procedures

In the "stored procedure" mode the database connector relies on a pair of stored procedures created in the customer database to do write and read operations:

Write_Proc called when a message is sent to the database.

Customer database Write_Proc inMsg inTarget

Database Connector

IN IN

Table_A

Writes relevant data into the target tables.

Table_B

Looks into designated tables to see if data must be returned.

Returns confirmation code.

Read_Proc Read_Proc called at fixed interval.

outMsg OUT outSource OUT Returns a message if the wanted conditions are met.

Figure 9.116: Customer database connection using stored procedures

•

The “write” stored procedure is used when AIRCOM® ServerPlatform is set to distribute a message to the database connector so that the data it contains can update something in the target database. The Write procedure must therefore use the data contained in the message sent to it (possibly formatted using a model) and update the wanted tables. The same write procedure can be called from different database users so the distinction is provided by their unique "Send to: Target value".

•

The “read” stored procedure is used to get data from the database and make a message out of it. That message is then received as an incoming message into AIRCOM® ServerPlatform and decoded by a template that allows it to be sent wherever it needs to. The same read procedure can be associated with different database users so each is identified by their unique "Receive from: Source value".

If a process requires only writes or reads to be done, only one of the two directions can be defined. As such only the "Send to" or "Receive from" can be configured in the database user's configuration. Likewise, only the write or the read stored procedure can be defined in the CmLinks.ini file. Each stored procedure must be programmed & designed by the airline’s database administrator to do what it should with the messages it processes. This must be done in relation to the users, templates and models used in AIRCOM® ServerPlatform to send and receive messages via the database connector.

347

ASP Administrator Guide Version 6.9a

The advantage of the "stored procedure" mode is that once the format of outgoing and incoming messages has been determined, the stored procedures can evolve to do more complex operations or better interface with the underlying tables, as needed. This also ensures that the administrator of templates cannot execute operations out of those permitted by the stored procedures, thus better protecting the integrity of the database. CmLinks.ini file The configuration of the database connector is done in the CmLinks.ini file located on the server machine. A database connection in the "stored procedure" mode is designated by the parameter "CommandType=storedproc". The other configurable parameters are the database to connect to, the name of the "Read" and "Write" procedures and the read/write processing delays. This configuration is described in document [2]. Read and write stored procedures writing The writing of the Read and Write stored procedures is done by the customer and stored into the database to which the AIRCOM® ServerPlatform database connector connects. The two procedures can have any desired name but must have the following arguments: spAircomSrvReadProc( @outMsg varchar(MAX) OUTPUT, @outSource varchar(256) OUTPUT) spAircomSrvWriteProc( @inMsg varchar(MAX), @inTarget varchar(256))

The contents of the two procedures then depends on the problem to solve and the data that must be read from and written into the database for each message that can transit by the database connector. The “outMsg” and “inMsg” arguments must be character strings (for instance, VARCHAR in SQL Server) but can actually be of any size greater than 1. Similarly, the “outSource” and “inTarget” arguments can be of any size between 1 and 256 characters. An empty skeleton file called “DatabaseCnxDefaultProcs.sql” is installed with the ASP server under “...\Program Files (x86)\SITA\AIRCOM Server\bin\Scripts” to ease the creation of the two procedures. Users Window As for all external connections with AIRCOM® ServerPlatform, the connection to a customer database must be defined by users, configured in the “Users and Groups” window. The users to associate a customer database for stored procedure interactions must be of type “Database” and configured with at least one of the two “Send To” or “Receive From” parameters. Its “Link name” parameter must be set to a stored procedure mode link configuration defined in CmLinks.ini file.

348

ASP Administrator Guide Version 6.9a

More than one user can be associated with a single customer database in the "stored procedure" mode by use of unique “Send To” and “Receive From” parameters: •

“Send To: Target value for Write proc”: is the value that will be used for the “inTarget” argument of the Write procedure called to write the message to the database. Based on this value, the procedure can take different actions and write the data into the appropriate tables for the given target.

•

“Receive From: Source value from Read proc”: is used to associate incoming messages extracted by the Read procedure with a user in AIRCOM® ServerPlatform, when the “outSource” argument from the Read procedure matches the Receive From of a database user.

9.4.1.2.

Connecting using free text queries

Read query from file Any SQL query can be defined as read query to retrieve data from a database by specifying it in a local file. The file must be saved with a Unicode encoding: either UTF-8, UTF-16LE (little endian) or UTF-16BE (big endian) encoding. The BOM (byte order mark) is also required. After defining this query file, you just need to link it to one or several database links through the “InQueryFile” parameter in CmLinks.ini file. Note that this file is read before each read, so you can modify it dynamically without restarting the database connector. Dynamic write query from model Please refer to section 4.1.5.3 of this document to know how to define SQL queries in the models. Using the power of user/template/model association, a SQL query can be dynamically built just before sending a message to a database user. The result of this “configurable” query is then executed against a database. This allows you to almost do what you want with your customer database. You should test your query before integrating it in ASP, or you could be flooded by error logs and unsent messages in ASP queues. Result of queries Whenever a query is executed from a query file or from a model, if there is a result set containing at least one row of data, the result set is converted into text using an XML format, which is processed as an incoming message by AIRCOM® ServerPlatform. Here is an example of SQL Server query:

349

ASP Administrator Guide Version 6.9a

-- Empty table SELECT 1 WHERE 1 = 2; -- Many rows SELECT 1 AS X, 2 AS Y UNION ALL SELECT 2 AS X, 3 AS Y UNION ALL SELECT 3 AS X, 4 AS Y; -- Unnamed columns SELECT 'A', 'B' AS X, 'C';

Here is the incoming message that will be generated for that query:

1 2

2 3

3 4



A B C



The incoming message may then be handled by a template to do other actions related to the data extracted from the database. The XML format is a hierarchy always containing the “databaseConnector” root element, a “table” element for each table in the result set, a “row” element for each row in the table, and a “field” element for each column of the table. Most common database types are supported for field values. The output of Booleans is either “True”, “False” or empty (if the field is NULL). An ISO format is used for dates and times, for example: “2016-02-23 11:40:46”. For numbers, scientific notation is avoided whenever it is possible for them to be extractable as template fields. When the field is NULL or empty, the full end tag “” is always used, for it to be extractable as a template field:

350

ASP Administrator Guide Version 6.9a

When a type is not supported by the data provider, an error is raised. However, when a type is supported by the data provider, but is not supported by AIRCOM® ServerPlatform, the field value looks like this: Unsupported type: Byte[]

If a character string contains ‘’ characters, they will be encoded: a < b and c > d

Users Window As for database interactions using stored procedures, the connection to an external database must be defined by users, configured in the “Users and Groups” window. The users to associate an external database for query interactions must be of type “Database” and configured with empty “Send To” and “Receive From” parameters. Its “link name” parameter must be set to a query mode link configuration defined in CmLinks.ini file. More than one query mode user can be associated with a single customer database, by use of the “Link name” parameter. To do that, you need to map each user on different database links, which each connect to the same database.

9.4.1.3.

Solving a real-life problem with the database connector

There is no better way to learn a process than by doing it and this is the goal of this section. Using a real-life scenario, this section explores the ways to use the database connector to solve a process that ASP alone cannot. Goal:

Uplink connecting gates for a given airport The goal is to collect departure gate data for all flights and allow an aircraft about to land at an airport to request the connecting gates for all onward flights from that airport.

To do so, gate assignments are to be provided to ASP by ground-to-ground messages for each of the upcoming flights, ahead of their departure time. For this process, one message per flight will be assumed. Then the aircraft will request the connecting gates using a designated downlink message for the airport at which it is about to arrive. The result will be the list of all flights planned to depart from that airport, their destination, departure time and, of course, departure gate.

351

ASP Administrator Guide Version 6.9a

Step 1: Creating the table for the departure gates The data that needed for the process can be stored in a custom-created database called Gates (not AIRCOM® ServerPlatform’s database!) that contains only a single DepGates table, as follows: CREATE TABLE [dbo].[DepGates]( [FlightId] [varchar](7) NULL, [Dep] [varchar](4) NULL, [Arr] [varchar](4) NULL, [DepTime] [datetime] NULL, [DepGate] [varchar](10) NULL, [ID] [int] IDENTITY(1,1) NOT NULL ) ON [PRIMARY]

When populated with data, the DepGates table will look like this:

When a gate assignment message is received; the following will happen: •

Message is identified with a "gate assignment" ground template.

•

Values are extracted using appropriate fields.

•

Values are converted into an SQL query used in a model

352

ASP Administrator Guide Version 6.9a

Step 2: Connecting the database connector to the Gates database To access the Gates database, we must create a connection definition for the database connector in the CmLinks.ini file, as follows: [DBLINK_GATES_DB] CnxType=database DatabaseType=SQLServer ServerAddress=localhost DatabaseName=Gates AuthenticationMode=SQL CommandType=query ...

The above config also needs the SQLLogin and SQLPassword to be added (in encrypted form) and can include other optional parameters that will otherwise take default values. All the parameters are described in document [S2]. Then to use that connection, a Database user must be created and reference the same Link name:

This configuration without a “Send to” and “Receive from” means that no stored procs will be used by the DB connector to send or receive messages. Rather, the send will be done with direct SQL queries that will be executed against the target database and the receive will done by a template matching the data directly returned to ASP in an XML structure.

353

ASP Administrator Guide Version 6.9a

Step 3: Identifying and storing the departure gate data Let's start with the format of the message that contains the data for departing flights and their gate – we use a ground message received over a type B connection: QU ASRV1XS .YULTEST GATE XS1234 23 12:12 KYUL KLAX B13

The message is a non-620 ground message identifiable by its GATE prefix; for it we configure a template called Gate Announcement of category “Ground from External User” with the “AEEC 620” box unchecked. Only one SubSMI is needed on the GATE prefix. Then follows the Flight Identifier, the day and time of the departure, departure and arrival airports, then departure gate. Each important value is identified with template fields configured as follows:

Once the data has been identified, we will want to send it to the Gates database for storing by sending it to the database connector. For that, let’s use the capability of the connector to run a query directly written in the model of the message distributed to it. So under the newly created template, let’s create a model called SQL that will reuse the same fields as defined above. The model text is this: INSERT INTO [DepGates] ([FlightId],[Dep],[Arr],[DepTime],[DepGate]) VALUES ('{Flight}', '{Departure airport}', '{Arrival airport}', '{@ETD|YYYY-MM-DD HH:MM}', '{Departure gate}')

And if we use the data from the example message above, the query will be resolved as this: INSERT INTO [DepGates]

354

ASP Administrator Guide Version 6.9a

([FlightId],[Dep],[Arr],[DepTime],[DepGate]) VALUES ('XS1234', 'KYUL', 'KLAX', '2016-06-23 12:12', 'B13')

The template then needs to be distributed to the Gates Database user using the SQL model. When the above message is processed by ASP, the database connector will create the following entry in the DepGates table (ID irrelevant):

Step 5: Using the request from the aircraft to return the wanted data Assuming that a bunch of messages like the previous one have been received, the DepGates table will have populated itself with a number of flights departing from various airports. We get to the point where we want to handle the connecting gates request from the aircraft and use it to select the data we want to send back to the aircraft as an uplink. For the example, let’s take a simple format where the request has the following form: QU ASRV1XS .QXSXMXS M99 AN AC-0001/FI XS0027 DT QXS YUL1 000000 0000 - GATES CYUL

For which we create a downlink template called Connecting Gates Request that will identify the arrival airport (“CYUL”, above) with a plain alphanumerical field called Airport Requested. We then create a SQL model that will turn that into a query to extract the wanted data, as follows: SELECT * FROM DepGates WHERE [Dep] = '{Airport Requested}'

That would resolve once reformatted to this: SELECT * FROM DepGates WHERE [Dep] = 'CYUL'

And return from the DepGates table, say, 3 rows, as follows:

355

ASP Administrator Guide Version 6.9a

However, when returned by the database connector, the data is formatted into an XML structure, as follows:



XS0652 CYUL KLAX 2016-06-23 16:11:00 B35 1

XS0044 CYUL KATL 2016-06-23 17:19:00 A03 5

XS0252 CYUL KDFW 2016-06-23 21:57:00 D12 8



The result of the SELECT query, even if triggered by a downlink message, will come back to ASP as a new message that is to be captured with its own template. The header of the XML text has been made to identify the user name and the connection from which the data was received so a template’s subSMI could be matched to it. Step 6: Uplink data to the aircraft Now that the XML message is known, the goal is to catch it with an uplink template and format it up for the aircraft. Starting with the above XML as the message text, we create a new uplink template called Connecting Gates Response. Since we know that the username will be returned at the top of the XML message, we use it as the one and only SubSMI, like this:

356

ASP Administrator Guide Version 6.9a

Now we need to catch the data in the message to be able to return it to the aircraft. As always, the way to handle repeating data like the multiple flights is to use a record that will repeat for every row returned in the message. Let’s call the record Flights Info and configure it as follows:

357

ASP Administrator Guide Version 6.9a

And from the Flight Info record we identify the fields we need in each record occurrence:

That is all nice and the template catches all the connecting gate data there is. However, there remains a problem – you may have seen it already. The problem is that when you save the template, you get the below error:

In the data returned by the database connector, there is no aircraft registration or flight identifier to identify the aircraft to which to return the data to. This is normal since the SELECT query of step 5 returns only generic data that has no identifier back to the aircraft having made the request. To fix that, we’ll have to go back to step 5 and find a way to include the requesting aircraft’s data as part of the returned XML. In the meantime, let’s deactivate the uplink template temporarily and save it (because inactive, you can save the template even when it doesn’t contain all the mandatory field types).

358

ASP Administrator Guide Version 6.9a

Step 5-bis: Include the aircraft registration in the returned XML Looking back at step 5, the query to return the connecting gates data is correct and doesn’t need to be reviewed. However, we must find a way to have the aircraft registration, and preferably the flight identifier, to the query so that it is returned in some way in the XML data. It would also be nice to be able to recover the requested airport. Integrating the registration as one more column returned in the query would work but it would return the registration for every row returned, or not at all if no connecting gates are returned. So this is not an elegant, nor reliable solution. The better way is to make two separate queries to return the aircraft registration and message-specific data needed first, and then let the second query return the connecting gates data. A key element to leverage here is that SQL allows queries to be written with known return values already provisioned, without the need for a FROM clause reading from a table. Using that method, we can pre-set an aircraft registration, flight identifier and the requested airport in a query that will get them part of the returned XML. So from the single query that we had earlier, we can write the new model as two queries, with the first one using the data we want returned back: SELECT Aircraft = '{@AIRCRAFT LONG REG}', Flight = '{@FLIGHT IDENTIFIER}', AirportReq = '{Airport Requested}' SELECT * FROM DepGates WHERE [Dep] = '{Airport Requested}'

This will then return the following data:



AC-0001 XS0027 CYUL



XS0652 CYUL KLAX 2016-06-23 16:11:00 B35 1

...

The data we want is now part of the returned resultsets, in table 1 in the XML message.

359

ASP Administrator Guide Version 6.9a

Step 6-bis: Uplink data to the aircraft – really Going back to the uplink template Connecting Gates Response, we now need to update the message guide to the above. The SubSMI matching criteria doesn’t need to change. In the Records tab, the record block for Flights Info must have its start ID changed to . We know already that the table containing the aircraft registration will always contain only one row. For that, there is no need to define a record around it. However, it may be useful to do so anyway since it will isolate the fields from this table and prevent mismatches if ever fields with the same name are ever returned in other tables. For that, let’s add a Request Info record, defined as follows:

Then in the Fields tab, we can add the fields needed to properly identify the flight: aircraft registration, flight identifier and departure airport. Note that all fields are extracted from records, knowing that Request Info will have only one occurrence:

360

ASP Administrator Guide Version 6.9a

In the reality of this scenario, only the aircraft registration is needed to send the uplink back to the aircraft. At the time the connecting gates request will be made – just before the landing – there will be no ambiguity to which aircraft and flight the uplink must be returned. However, to include the flight identifier will just ascertain the uplink goes back while the aircraft is still flying the right flight. Now that all the data has been identified, the template can be reactivated and saved. All that remains is to take the data identified and format it in the wanted format for the aircraft, then set its distribution for the aircraft using it:

361

ASP Administrator Guide Version 6.9a

And so with the example data from CYUL, the result will be this: QU QXSXMXS .YANIKXS 050240 AGM AN AC-0001/FI XS0027 - Connecting gates at CYUL: XS0652 CYUL-KLAX: 2016-06-23 16:11:00 @ B35 XS0044 CYUL-KATL: 2016-06-23 17:19:00 @ A03 XS0252 CYUL-KDFW: 2016-06-23 21:57:00 @ D12 End

362

ASP Administrator Guide Version 6.9a

Step 7: Troubleshoot and refine solution So it took 3 templates and models, the database connector connected to a Gates database, a database user and some distribution and permission rules for all that to happen. But the solution still has its flaws. Now that the “happy path” scenario works, one has to consider how to resolve the following challenges: • In the returned data, arrange the query so that only the connecting gates in the next, say, 6 hours are returned (eliminating past flights or those too much in the future). • Connecting gates should not be accumulated forever; there should be a process somewhere in there to clean the expired flights. • If a flight is announced twice or if it is moved to another gate, the query should be done so that no duplicates are created in the database and that only the most upto-date info is kept in the Gates database. • The above scenario assumed that only one flight was announced in the Gate Announcement message; what if the message were to contain multiple gate assignments at once?

363

ASP Administrator Guide Version 6.9a

9.4.2. 9.4.2.1.

Writing Files to Another Server ASP File/Printer Connector Service Configuration

The ASP server “ASP File/Printer Connector” service requires changing from a “Local Service” to a “Network Service”. Go to the ASP server computer and open the Services panel.

To do this, first stop the service (right-click and select Stop). Right-click on the “ASP File/Printer Connector”, select “Properties” and select the “Log On” tab. Change “Log on as:” from “Local System account” to “This Account” and browse to Network Service.

364

ASP Administrator Guide Version 6.9a

Browse will bring up the “Select User” window below. Type “Network” in the object name box and click “Check Names”.

It will find the Network Service name, click “OK”.

The Network Service will populate both the Account and Password fields, click “OK”

365

ASP Administrator Guide Version 6.9a

Restart the service. It is now ready to write to a remote folder.

366

ASP Administrator Guide Version 6.9a

9.4.2.2.

Destination Folder Configuration

The destination folder must have the proper permissions to give access to AIRCOM® ServerPlatform. •

Connect to server using “Run”, browse to it via Windows Explorer, or remote connect.

•

Make sure you have a user dedicated to AIRCOM® ServerPlatform.

•

Browse to the folder in which you wish to write to from AIRCOM® ServerPlatform.

•

Right-click on the folder, select “Properties” and select the “Security” tab.

•

Click “Add…”.

367

ASP Administrator Guide Version 6.9a

•

Verify that “Computers” is checked using the “Object Types…” button.

•

Enter the name of the ASP server computer and click Check Names to validate.

•

Click “OK” and the ASP server is added to the folder for permissions.

368

ASP Administrator Guide Version 6.9a

•

Check the Write and Modify permissions as a minimum and click “OK”.

The folder permissions are properly set.

369

ASP Administrator Guide Version 6.9a

9.4.2.3.

ASP User and Distribution Configuration

Open the Users & Groups window and create a user of type File for the folder where data is to be written. Specify the “Send to: File name” with the fully qualified path, starting with \\ and the remote path including the file name. For example, name the file “MMYY.txt” to write one file per month, appending data in it until the next month.

The best way to avoid mistakes is to capture the fully qualified path of the destination folder by browsing “My Network Places”:

370

ASP Administrator Guide Version 6.9a

Save the user and distribute the desired messages for output to that folder & file by opening the proper template distribution window (say Downlinks) and configuring the distribution rules for the file user you just created.

Save the distribution rules and data will start flowing to the designated folder & file path.

371

ASP Administrator Guide Version 6.9a

9.4.3. 9.4.3.1.

Enabling MIAM Application Support What is MIAM

MIAM (Media Independent Aircraft Messaging) is a new communication protocol between ground applications / ground users / ground repositories and aircraft. This protocol is described in document [E4] that will allow avionic systems to exchange large volumes of data through bigger files than today’s maximum ACARS capacity (3360 bytes for downlink and 3520 bytes for uplink). The MIAM protocol also focuses on ACARS performance and efficient RF spectrum utilization. Currently, the MIAM Connector supports data exchange over the ACARS sub-networks that is via ACARS DSPs for communication with the aircraft. It implements the functional requirement described in document [S7]. To benefit from MIAM support and have access to MIAM configuration, the MIAM license option is required.

9.4.3.2.

Involved Configuration

It is required to configure a Type B user with the special handling set to “MIAM” option set to communicate with the MIAM connector. Step 1: Make sure the MIAM connector is installed with the appropriate AircomSrv.ini configurations. The steps are described in document [S2]. Step 2: Configure a MIAM Type B User, and select the Special Handling drop down to MIAM. Also select the Preferences as shown in the figure below.

372

ASP Administrator Guide Version 6.9a

Figure 9.117: MIAM Type B User – Configuration

Step 3: Select the appropriate user rights. •

Open the User Rights window and find the MIAM Connector User.

•

Select the following check boxes :

• • • • • • •

Send downlink messages Send uplink messages Send uplink messages over satellite Send ground messages Send ground messages to loopback users Allow direct type B addressing View data and messages from locked aircraft

Step 4: Verify the AircomSrv.ini settings. •

On the server machine, open the AircomSrv.ini file and locate the [MSGPROC] section.

373

ASP Administrator Guide Version 6.9a

•

Make sure that the parameter CapitalizeIncomingMessage is set to ‘N’. [MSGPROC] … CapitalizeIncomingMessage=N

•

If a change is required, restart the Message Processor service after saving your change.

Step 5: Make sure you have the appropriate Downlink, Uplink and Ground templates located in the Reference Database on your AIRCOM® ServerPlatform installation CD or package. The ASP DataSync tool may be required when upgrading from an earlier AIRCOM® ServerPlatform version in order to help transferring these templates. The templates are not predefined, so they can be tailored for your MIAM enabled applications. Downlink template

Figure 9.118: MIAM Downlink Template

374

ASP Administrator Guide Version 6.9a

Downlink distribution to the MIAM connector

Figure 9.119: MIAM Downlink Distribution

MIAM uplink templates

Figure 9.120: MIAM Uplink Templates

The MIAM uplink distribution must be set for all participating aircraft.

375

ASP Administrator Guide Version 6.9a

MIAM ground templates

Figure 9.121: MIAM Ground Templates

376

ASP Administrator Guide Version 6.9a

Apply the appropriate distribution to the ground templates.

Figure 9.122: MIAM Ground Distribution

377

ASP Administrator Guide Version 6.9a

9.4.3.3.

How to Use MIAM

Once configured, there is nothing more to be done. The aircraft and MIAM enabled applications will communicate without user intervention.

9.4.4.

Enabling MCCA Application Support

9.4.4.1.

What is MCCA

MCCA (Multi-Channel Communication API document [E5]) is a new communication protocol created and maintained by Airbus. The Multi-channel Communication API objectives are to: • • •

Define a homogeny communication system, transparent, with an abstraction of the real communication use. Define generic message usable for each platform. Integrate MIAM (Media Independent Aircraft Messaging) management

To benefit from MCCA support and have access to MCCA configuration, the MCCA license option is required.

378

ASP Administrator Guide Version 6.9a

9.4.4.2.

Involved Configuration

It is required to configure a Type B user with the special handling set to “MCCA” option set to communicate with the MCCA connector. Step 1: Make sure the MCCA connector is installed with the appropriate AircomSrv.ini configurations. The steps are described in document [S2]. Step 2: Configure a MCCA Type B User, and select the Special Handling drop down to MCCA. Also select the Preferences as shown in the figure below.

Figure 9.123: MCCA Type B User – Configuration

Step 3: Select the appropriate user rights. •

Open the User Rights window and find the MCCA Connector User.

•

Select the following check boxes :

•

Send downlink messages 379

ASP Administrator Guide Version 6.9a

• • • • • •

Send uplink messages Send uplink messages over satellite Send ground messages Send ground messages to loopback users Allow direct type B addressing View data and messages from locked aircraft

Step 4: Verify the AircomSrv.ini settings. •

On the server machine, open the AircomSrv.ini file and locate the [MSGPROC] section.

•

Make sure that the parameter CapitalizeIncomingMessage is set to ‘N’.

[MSGPROC] … CapitalizeIncomingMessage=N

•

If a change is required, restart the Message Processor service after saving your change.

Step 5: Make sure you have the appropriate Downlink, Uplink and Ground templates located in the Reference Database on your AIRCOM® ServerPlatform installation CD or package. The ASP DataSync tool may be required when upgrading from an earlier AIRCOM® ServerPlatform version in order to help transferring these templates. The templates are not predefined, so they can be tailored for your MCCA enabled applications.

380

ASP Administrator Guide Version 6.9a

MCCA ground templates

Figure 9.124: MCCA Ground Templates

Apply the appropriate distribution to the ground templates.

Figure 9.125: MCCA Ground Distribution

9.4.4.3.

How to Use MCCA

Once configured, there is nothing more to be done. The aircraft and MCCA enabled applications will communicate without user intervention.

381

ASP Administrator Guide Version 6.9a

9.4.5. 9.4.5.1.

Honeywell Encryption and User Defined Formats What is Honeywell Encryption

Honeywell encryption is provided by Honeywell on its avionics to encrypt the transmission of certain types of ACARS messages (aircraft to ground and vice-versa). The Honeywell specification states that M1L downlinks with header (1L label) and M3L uplinks (3L label) of type code 3 or 5 can be encrypted. These message formats include a free text header where a randomly generated decode key tells the system and the aircraft how to encrypt/decrypt messages. What is encrypted in the end is the content of the message that comes after the header. Please refer to the appropriate Honeywell documentation for more details. The AIRCOM® ServerPlatform implementation of the Honeywell encryption allows decrypting encrypted downlinks and encrypting selected uplinks such that the aircraft will be able to decrypt them. The configuration required to properly enable this function is described in the next section.

9.4.5.2.

Involved Configuration

License and user right To perform Honeywell encryption, the system needs to find the corresponding license option in the product’s license and to perform the encryption related configuration, an administrator must have the Manage aircraft user right. Honeywell encryption configuration This dedicated configuration window (see section 5.7) is located under the Aircraft main menu dropdown. It allows defining the encryption tables used by the different Honeywell equipped aircraft in the fleet as well as the types of downlinks to be decrypted and the types of uplinks to be encrypted. Downlink templates, Table Index and Encryption Enabled state The system needs to know what is the current encryption state on-board the aircraft and in the case it would use multiple encryption tables, it also needs to know what table index is currently used by the aircraft. To achieve this, two specific field types exist in ASP: “Honeywell - Encryption Enabled” and “Honeywell - Encryption Table Index”. These can be added to any downlink template in order to extract the current encryption state and current table index of the aircraft. The aircraft should send the information to the ground in order to properly initialize the values. If the encryption enabled state is off for a flight, uplinks will not be encrypted. However, when receiving downlinks from an aircraft configured with an ACARS MU supporting 382

ASP Administrator Guide Version 6.9a

Honeywell encryption and that the aircraft is encryption enabled in the Fleet Configuration, ASP will analyze the message for decryption (SMI, decode key) and if it determines that it is an encrypted message, it will automatically set the encryption-enabled tracked flag to true for this flight. Similarly, when the Table Index is unknown, ASP assumes table index 0, which will be valid when using single table configuration, and which is a guess when in multi-table configuration. In the latter case, an event will be logged to indicate the guessed index. If it is not the right index, a downlink decryption would fail or an encrypted uplink would fail decryption on-board the aircraft. Below are samples of encrypted downlinks. Fields are shown for information only, to help visually identify an encrypted downlink, but when a downlink has been encrypted by the avionics on-board the aircraft, ASP only needs the configuration in section 5.7 (encryption table and SMI M1L specified) to be able to decode the downlink. Sample M1L typical downlink message QU XXXXXXX .QXSXMXS 030001 .M1L FI XS1111/AN XS1234 DT QXS NAS1 030001 M14A - 00062241714FO(3 2:: Z382:2 L48 82 885 82LZY[until the end]

QU XXXXXXX .QXSXMXS 030000 .M1L FI XS1111/AN XS1234 DT QXS TVC1 030000 M11A - 00049241736Z35KJOZ533Y:,-R3XYR43VMOY: 47ZR)30RY:,R[until the end]

Where: • MU message sequence number 5 numeric digits = 00062 or 00049 • Type code 1 numeric digit = 2 • Report code 2 numeric digits = 41 • Stimulus code 1 numeric digit = 7 • Decode key 2 numeric digits = 14 or 36 • Encrypted content = FO … until the end, Z35 … until the end Uplink template models and distribution When processing uplinks for aircraft configured with an ACARS MU supporting Honeywell encryption (that is: encryption-enabled in the Fleet Configuration and for which the flight is also currently encryption -enabled, ASP will decide if it shall be encrypted based on the message template and the encryption configuration (see section 5.7). A last step is needed to allow for the encryption: the model used for distribution to the aircraft shall be a valid 3L message (using the M3L SMI). For details on the format, please 383

ASP Administrator Guide Version 6.9a

refer to the appropriate Honeywell documentation and to the model sample below. Note that in uplink models, when selecting “Other” in the insert options drop down, it is possible to insert an “M3L model guide” to start from. IMPORTANT: Split uplinks cannot be encrypted, they will be processed as-is. A split uplink is one for which the model properties are set such that the uplink would be split and sent in multiple parts. Sample M3L formatted model The key characters are shown in blue and explained below. QU {@DEST TYPEB} .{@AIRCOMSRV TYPEB} {@ORIG DTG} M3L AN {@Aircraft Long Reg}/FI {@Flight Identifier} - 56100003RLAF1MDISPATCH RLS #0991524,0026,05{Text Payload}

Where: • Customer message sequence number 5 numeric digits = 56100 • Reserved 1 numeric digit = 0 • Reserved 1 numeric digit = 0 • Type code 1 numeric digit = 3 • Ground report code 2 numeric digits = RL • Application message sequence number 2 numeric digits = AF • Uplink display/print format code 1 numeric digit = 1 • Annunciation level 1 alphabetic character = M • Title 0-23 alphanumeric characters = DISPATCH RLS #0991524 • Delimiter = , • Prompt & action codes 0-5 numeric digits = 0026 • Delimiter = , • Decode key 2 numeric digits = 05 The first important element is that the SMI must be M3L. Then the first 5 characters of the free text must be numeric representing the customer message sequence number (56100 in the sample) and ASP will generate its own sequence number (replacing the ones specified in the model) just before sending the message, thus the model could contain 00000 and it would not matter. The next single numeric (3 in the sample) is the type code. Type codes 1 to 5 are supported, but only type codes 3 and 5 allow encryption. The last 2 characters standing just before the free text to be encrypted (05 in the sample) represent the decode key used to encrypt the uplink. Only the second digit is used and it points to the index of the row to use in the current encryption table. ASP will randomly 384

ASP Administrator Guide Version 6.9a

generate the decode key just before sending the uplink and encrypt the rest of the message if the decode key is different from 0 (second digit). The decision to encrypt is NOT based on the decode key specified in the model but rather on the encryption configuration. Therefore, it could be always 00 in the model; it would not matter and it would not prevent encryption. The 2 commas present before the decode key are mandatory delimiters for the two fields preceding the decode key. Please refer to the appropriate Honeywell documentation for the rest of the header format description, but all that ASP needs to perform the encryption are the elements identified in blue. Note that other fields such as the title in red above) may very well come from template fields that you may decide to insert in the model. Encrypted downlink and message distribution When a downlink comes in as encrypted, the free text contains the 1L header and the encrypted payload of the message (the real content). Thus using the predefined field “Freetext Quote” in a model would return the header and encrypted content of the free text (i.e. the exact content received from the aircraft). To allow adding the decrypted version of the header and payload free text in a model, the predefined field “Decrypted Freetext Quote” should be used.

9.4.5.3.

Message Display

New uplink preview A local user that would send preview an uplink to be encrypted would see in the preview only the customer message sequence number and decode key as they were set in the model (could even be zeroes) and the free text payload would always be decrypted. It is only at the time of sending transmitting uplink that all these values will be generated and that the payload will be encrypted if needed to. Thus, in the users’ outbox and in the Aircraft Tracking’s queued uplinks, the message will be updated each time a transmission is tried according to the current encryption configuration and tracked values at that moment. In other words, the customer sequence number and decode key may change, and thus the encryption (if needed) will be performed again and may be different for two different transmissions. Mailbox uplinks display A local user that would send an uplink to be encrypted could see both the decrypted and encrypted versions of the uplink messages in his mailbox. When selecting an uplink the display option Encrypted is added to the dropdown. By default, the message is displayed decrypted to be user-readable, but selecting the Encrypted option displays the uplink in its encrypted format, if available, otherwise it shows “(no encrypted message available)”.

385

ASP Administrator Guide Version 6.9a

The customer message sequence number and the decode key, and thus the encryption of the message, may change each time the message is sent or resent, until it is successfully sent or until it expires. Aircraft Tracking queued uplinks display Similarly, when viewing queued uplinks in the Aircraft Tracking window, an Encrypted check box is available to view the encrypted version of the message, shown by default as decrypted. As for the mailbox, the customer message sequence number and the decode key, and thus the encryption of the message, may change each time the message is sent or resent. The Encrypted and Hex view check boxes can be combined when available. The “Encrypted” check box is enabled ONLY when there is an encrypted version available for a message viewed as decrypted. Traffic log display For the traffic log display of encrypted messages, outgoing messages are always logged as-is. That is if they were sent out in an encrypted version, they will be seen as encrypted without having to select the Encrypted check box. It is only incoming messages to be decrypted (downlinks) that are logged with both their encrypted and decrypted versions. In this case, the user views by default the decrypted version of the message and can alternately view its encrypted equivalent by selecting the Encrypted check box. For uplinks, because encryption is always performed just-in-time before each transmission, it means the incoming uplink never has an associated encrypted version of the message, and each uplink retransmission (out up) could potentially have a different encrypted version of the message (or no encryption version) depending on the current configuration at that specific moment. The Encrypted and Hex view check boxes can be combined when available. The Encrypted check box is enabled ONLY when there is an encrypted version available for a message viewed as decrypted.

386

ASP Administrator Guide Version 6.9a

9.4.6.

FANS Decoding

9.4.6.1.

What is FANS

FANS means Future Air Navigation Systems and is composed of AFN (ATS Facilities Notification), ADS-C (Automatic Dependent Surveillance Contract) and CPDLC (Controller Pilot Data Link Communications). Those are data link messages exchanged between an Air Traffic Controller (ATC) and an aircraft to automate a series of communications, such as departure clearance, deviations or position reports. There ar e a lot of possible message elements in FANS messages. These typically contain one message element per message, and in some cases many elements could be found in the same message. Possible message elements are defined in the specification document [E6]. AIRCOM® ServerPlatform allows decoding any of these message elements in both downlink and uplink messages. However, aircraft and ATC communications through FANS messages should not be managed by AIRCOM® ServerPlatform. These are directly sent to and from each of the involved parties, but when ASP is in copy of these messages their encoded content can be decoded and distributed to users for information only.

9.4.6.2.

Involved Configuration

Downlink templates To decode the content of FANS downlink messages, downlink templates of category AFN, ADS-C and CPDLC must be defined. There should be as many templates as there are different variations of content exchanged with ATCs, typically different message identifiers (SMI) and different avionics generating the messages. The following configuration can be used as a starting point: •

AFN messages from the aircraft are identified with a downlink template of category “AFN”. Their SMI is typically "FM?" and the first 3 chars of the freetext are "AFN”.

•

ADS-C messages from the aircraft are identified with a downlink template of category “ADS-C”. Their SMI is typically "FM?" and the first 3 chars of the freetext are "ADS”.

•

CPDLC messages from the aircraft are identified with a downlink template of category “CPDLC”. Their SMI is typically "FM?" (L,R or C) and the first 3 chars of the freetext are "AT1", “CC1” or “DR1”.

Ground templates (for uplinks)

387

ASP Administrator Guide Version 6.9a

Similarly, to decode the content of AFN, ADS-C or CPDLC uplink messages, ground templates of the corresponding category must be defined. Indeed, uplink messages not matching any uplink templates but matching a ground template will be handled as a ground message, and this is exactly what is desired with FANS uplinks. AIRCOM® ServerPlatform allows decoding FANS uplinks for distribution to users for information only. •

AFN messages to the aircraft are identified with a ground template of category “AFN”. Their SMI is typically "FM?" and the first 3 chars of the freetext are "AFN”.

•

ADS-C messages to the aircraft are identified with a ground template of category “ADS-C”. Their SMI is typically "FM?" and the first 3 chars of the freetext are "ADS”.

•

CPDLC messages to the aircraft are identified with a ground template of category “CPDLC”. Their SMI is typically "FMD" and "AT1", “CR1” or “DR1” follows the ATC center’s address in the first chars of the freetext (“/AA OAKODYA.AT1”).

ADS-C Contract Request (for uplinks) The “ADS-C Contract Request” computer generated uplink template is automatically created under the “Predefined Templates” folder. Two models are created by default and cover most common scenarios: “Uplink to MU” and “Uplink to FMC”. Additional models can however be created as desired. Each aircraft is associated, by default, to the “Uplink to MU” model. This can however be modified through the Uplink Templates Distribution window. Models In both downlink and uplink directions, the decoding is achieved by creating models for the templates and adding the predefined “ADS-C Decoded”, “AFN Decoded” or “CPDLC Decoded” field to the model text. These models are not predefined; however, each message element contained in the message is decoded as part of the “XXXX Decoded” value in a predefined format according to what this data represents (latitude/longitude, temperature, speed, etc.).

ADS-C AFN CPDLC

Preview field

Decoded field

{@ADS-C PREVIEW} {@AFN PREVIEW} {@CPDLC PREVIEW}

{@ADS-C DECODED} {@AFN DECODED} {@CPDLC DECODED}

Refer to the following sections for samples of preview and decoded fields.

388

ASP Administrator Guide Version 6.9a

9.4.6.3.

ADS-C Samples

Find here samples of typical ADS-C messages and the corresponding decoded content. Downlink free text: - ADS.N290UP0301DB84

Decoded ADS-C ({@ADS-C DECODED}): ADS DOWNLINK @ 23:21 From aircraft {aircraft} on flight {flight} to ATC 3‑ ACKNOWLEDGEMENT, contract request: 1

Preview line ({@ADS-C PREVIEW}) ACK, contract request: 1

389

ASP Administrator Guide Version 6.9a

Downlink free text: ADS.N290UP0702D28C1A7047CE418C1D0DFF560C005AC7CD4BB2FB84ABE748C7CD400E5038F9FFFC0F5039A23FFC10052 8DEF6 7228

Decoded ADS-C ({@ADS-C DECODED}): ADS DOWNLINK @ 23:01 From aircraft {aircraft} on flight {flight} to ATC 7‑ BASIC ADS REPORT Current position: Current altitude: Timestamp: Calculated position time: Figure of merit: TCAS: 13‑ PREDICTED ROUTE Next position: Next altitude: Next projected time: Next+1 position: Next+1 altitude:

3.969 / ‑175.353 31972 ft 99 seconds (1 minute 39 seconds) 23:01:39 (*) 2 or more nav units accuracy 6 (< 0.25 NM) operational 0.934 / ‑179.938 31956 ft 2994 seconds (49 minutes 54 seconds) ‑6.303 / 175.655 31956 ft

14‑ EARTH REFERENCE True track: Ground speed: Vertical rate:

‑134.38 deg (valid) 499.5 knots 16 fpm Descent

15‑ AIR REFERENCE True heading: Mach speed: Vertical rate:

‑134.38 deg (valid) 0.8360 mach 16 fpm Descent

16‑ METEOROLOGICAL Wind speed: True wind direction: Temperature:

5.0 knots ‑130.78 deg (valid) ‑33.25 deg C

(*) The calculated position time has been inferred from a time interval in seconds relative to the last hour. If the message was delayed by more than an hour, it is possible that the real position time was earlier.

Preview line ({@ADS-C PREVIEW}) BASIC ADS REPORT: 3.969 / -175.353

390

ASP Administrator Guide Version 6.9a

Downlink free text: -

ADS.N290UP1402D7241A95C7CE014C1D0DFF560C005AC7CD4BC2FB84ABE748C7CD40A1E3

Decoded ADS-C ({@ADS-C DECODED}): ADS DOWNLINK @ 23:00 From aircraft {aircraft} on flight {flight} to ATC 20‑ WAYPOINT CHANGE EVENT Current position: Current altitude: Timestamp: Calculated position time: Figure of merit: TCAS: 13‑ PREDICTED ROUTE Next position: Next altitude: Next projected time: Next+1 position: Next+1 altitude:

3.994 / ‑175.327 31968 ft 83 seconds (1 minute 23 seconds) 23:01:23 (*) 2 or more nav units accuracy 6 (< 0.25 NM) operational 0.934 / ‑179.938 31956 ft 3010 seconds (50 minutes 10 seconds) ‑6.303 / 175.655 31956 ft

(*) The calculated position time has been inferred from a time interval in seconds relative to the last hour. If the message was delayed by more than an hour, it is possible that the real position time was earlier.

Preview line ({@ADS-C PREVIEW}) WAYPOINT CHANGE EVENT: 3.994 / -175.327

Uplink free text: -

/A6 PIKCPYA.ADS.N270UP07020BCC0C010D0110016A4E

Decoded ADS-C ({@ADS-C DECODED}): ADS UPLINK @ 02:04 From ATC PIKCPYA to aircraft {aircraft} 7‑ PERIODIC CONTRACT, request: 2 Reporting interval: 832 seconds (13 minutes 52 seconds) Requested groups: 12‑ Flight ID (every 1 basic report) 13‑ Predicted route (every 1 basic report) 16‑ Meteorological (every 1 basic report)

Preview line ({@ADS-C PREVIEW}) PERIODIC CONTRACT, request: 2

391

ASP Administrator Guide Version 6.9a

Uplink free text: -

/A6 YQXE2YA.ADS.N304UP08030A2812B113217F20E9143454

Decoded ADS-C ({@ADS-C DECODED}): ADS UPLINK @ 02:06 From ATC YQXE2YA to aircraft {aircraft} 8‑ EVENT CONTRACT, request: 3 Requested events: 10‑ Lateral deviation 18‑ Vertical rate change 19‑ Altitude range Ceiling: 34300 ft Floor: 33700 ft 20‑ Waypoint change

(Threshold: 5.00 NM) (Threshold: 2832.00 fpm)

Preview line ({@ADS-C PREVIEW}) EVENT CONTRACT, request: 3

Uplink free text: -

/A6 BNECAYA.ADS.N270UP010B82

Decoded ADS-C ({@ADS-C DECODED}): ADS UPLINK @ 13:35 From ATC BNECAYA to aircraft {aircraft} 1‑ CANCEL ALL CONTRACTS AND TERMINATE CONNECTION

Preview line ({@ADS-C PREVIEW}) CANCEL ALL CONTRACTS AND TERMINATE CONNECTION

392

ASP Administrator Guide Version 6.9a

9.4.6.4.

AFN Samples

Downlink free text: -

AFN/FMHUPS63,.N573UP,,015932/FPON54522W115333,0/FCOADS,01/FCOATC,01D783

Decoded AFN ({@AFN DECODED}): AFN DOWNLINK @ 01:59:32 From aircraft {aircraft} on flight {flight} to ATC AFN CONTACT (FN_CON) Current position: Active:

54.870 / ‑115.555 No

Aircraft supports: ‑ ADS: Automatic Dependent Surveillance, version 1 ‑ ATC: Air Traffic Control Communication, version 1

Preview line ({@AFN PREVIEW}) AFN CONTACT

Downlink free text: -

AFN/FMHUPS63,.N573UP,,015944/FCPYWGE2YA,0C5D3

Decoded AFN ({@AFN DECODED}): AFN DOWNLINK @ 01:59:44 From aircraft {aircraft} on flight {flight} to ATC AFN COMPLETE (FN_COMP) Next ATC Center address: Reason:

YWGE2YA 0 ‑ Successful

Preview line ({@AFN PREVIEW}) AFN COMPLETE

Downlink free text: -

AFN/FMHUPS238,.N304UP,,010550/FRP0E33A

Decoded AFN ({@AFN DECODED}): AFN DOWNLINK @ 01:05:50 From aircraft {aircraft} on flight {flight} to ATC AFN RESPONSE (FN_RESP) Reason:

0 ‑ Successful

Preview line ({@AFN PREVIEW}) AFN RESPONSE Successful

393

ASP Administrator Guide Version 6.9a

Uplink free text: -

/A0 SINCXYA.AFN/FMHUPS166,.N303UP/FAK0,WSJC/FARADS,0/FARATC,00FD9

Decoded AFN ({@AFN DECODED}): AFN UPLINK @ 13:52:00 From ATC SINCXYA to aircraft {aircraft} on flight {flight} AFN ACKNOWLEDGEMENT (FN_AK) Reason: ICAO code:

0 ‑ Successful WSJC

Ground system supports: ‑ ADS: Automatic Dependent Surveillance Reason: 0 ‑ Successful ‑ ATC: Air Traffic Control Communication Reason: 0 ‑ Successful

Preview line ({@AFN PREVIEW}) AFN ACKNOWLEDGEMENT Successful

Uplink free text: -

/A0 YEGE2YA.AFN/FMHUPS63,.N573UP,,015935/FCAYWGE2YA,03DF6

Decoded AFN ({@AFN DECODED}): AFN UPLINK @ 01:59:35 From ATC YEGE2YA to aircraft {aircraft} on flight {flight} AFN CONTACT ADVISORY (FN_CAD) Next ATC Center address: Active:

YWGE2YA No

Preview line ({@AFN PREVIEW}) AFN CONTACT ADVISORY for YWGE2YA

394

ASP Administrator Guide Version 6.9a

9.4.6.5.

CPDLC Samples

Find here samples of typical CPDLC messages and the corresponding decoded content. Downlink free text: -

AT1.N573XSA451B2C272802080A487

Decoded CPDLC ({@CPDLC DECODED}): CPDLC DOWNLINK ID: 8 @ 20:27:11 From aircraft {aircraft} to ATC DATA TRANSFER (AT1) 965-

REQUEST CLIMB TO: FL350 DUE TO WEATHER

Preview line ({@CPDLC PREVIEW}) REQUEST CLIMB TO: FL350

Downlink free text: -

AT1.N570XS6606EE07035C3C

Decoded CPDLC ({@CPDLC DECODED}): CPDLC DOWNLINK ID: 12, REF: 3 @ 14:56:07 From aircraft {aircraft} to ATC DATA TRANSFER (AT1) 3-

ROGER

Preview line ({@CPDLC PREVIEW}) ROGER

395

ASP Administrator Guide Version 6.9a

Downlink free text: AT1.N275UPA0D6568C3D903B97435998075972A82438B0A2CEAD2243935A4D40EA430D156A890E655A94EAFE550500114 BA1

Decoded CPDLC ({@CPDLC DECODED}): CPDLC DOWNLINK ID: 1 @ 21:37:26 From aircraft {aircraft} on flight {flight} to ATC DATA TRANSFER (AT1) 48-

80-

POSITION REPORT: Current position: Current altitude: Current position time: Current speed:

23.448 / -153.855 FL370 21:37 .82M

Reported waypoint position: Reported waypoint altitude: Reported waypoint ETA:

CLUTS FL370 21:31

Next fix: Next fix ETA: Next+1 fix:

CEBEN 21:41 CIVIT

Destination ETA:

01:53

Temperature: Wind direction: Wind speed:

-47 deg C 270 deg 42 knots

DEVIATING: 2 NM, R OF ROUTE

Preview line ({@CPDLC PREVIEW}) POSITION: 23.448 / -153.855 (WP CLUTS)

Uplink free text: -

/AA OAKODYA.CR1.XS-SIT251562E8E5DA832CFE23

Decoded CPDLC ({@CPDLC DECODED}): CPDLC UPLINK ID: 10 @ 05:22:11 From ATC OAKODYA to aircraft XS-SIT CONNECT REQUEST (CR1) 163- FACILITY DESIGNATION: KZAK, LABEL A

Preview line ({@CPDLC PREVIEW}) CONNECT REQUEST: KZAK

396

ASP Administrator Guide Version 6.9a

9.4.7. 9.4.7.1.

FlightPlanner What are FlightPlanner and FlightPlanner Map

FlightPlanner is a component of the AIRCOM® ServerPlatform portfolio and allows, amongst others, defining flight programs and flight plans. Refer to document [S4c] for further details. FlightPlanner Map, on its end, is a flight planning tool that integrates with FlightPlanner to display flight plans, routes, tracks, FIRs and other flight planning artefacts over the world map developed using the OpenLayers map engine and map data from online map servers. Refer to document [S4b] for further details.

9.4.7.2.

Involved Configuration

Licenses FlightPlanner and FlightPlanner Map respectively require the FlightPlanner and FlightPlanner Map license options to be set. Download File Location All FlightPlanner files get stored in the Download Folder location defined in ASP System Parameters  General Tab  SITAONAIR FlightPlanner Host Connection section. SITAONAIR FlightPlanner Host Connection FlightPlanner needs a SITAONAIR FlightPlanner Host connection to be established in order to download data from the host. Refer to section 7.1.2.1 of the present document for information on how to configure this. FlightPlanner host connection is incorporated into ASP Base Service. When FlightPlanner is fully configured and the ASP Base Service is started, additional Host Connector events will appear in the Windows Event Log, especially one stating that "Start HostConnector Complete" User rights The Navigational Data\Manage navigational data user right must be granted to the user before downloading data from the SITAONAIR FlightPlanner Host using FlightPlanner. For information on how to download navigation data, refer to document [S4c]. FlightPlanner flight plan (CFG) template FlightPlanner allows creating flight plans that can eventually be tracked using FlightTracker. Flight plan generation process is out of scope for the present guide and is addressed within document [S4c], but it is important to understand the process that will allow converting a FlightPlanner flight plan to a FlightTracker flight plan.

397

ASP Administrator Guide Version 6.9a

When a flight plan is flagged as OFP (Operational Flight Plan) in Flight Planning Desk window, it will trigger the injection of the flight plan’s CFG message into the message processor. This needs to be templated so that the relevant fields can be used in FlightTracker.

Figure 9.126: CFG message from FlightPlanner

When looking at the traffic log, this message can be identified as a RELAY ground message coming from the FLIGHTPLANNER source. This message must therefore be handled by an uplink template for the tracking to kick in. The easiest way to do so is to select the message in the traffic log window and to click on the Template  Uplink template button in the toolbar. Clicking on Yes will then launch the New Uplink template wizard. Be sure to select the From External User type and to choose Flight Plan under the Special Handling field. Fields must then be defined to properly set FI, ETD, ETA, departure/arrival/alternate airports, waypoints (using a record), ETOPS (using a record), etc. For help on how to do so, consult section 9.2.2 in the present document.

398

ASP Administrator Guide Version 6.9a

9.4.7.3.

EFB Configuration

If the customer has an EFB application, you need to set up a file route from FlightPlanner. 1. Create a ASP file user to read the EFB files. You need to create suitable folders for Receive and Send locations. Receive from: Directory Path is the important element for this file user

Figure 9.127: EFB File User

2. Enable flight plan to EFB and use this file user to configure Flight Plan EFB section

Figure 9.128: Enable flight plan to EFB

399

ASP Administrator Guide Version 6.9a

3. Once this is activated and when the user flags a flight plan as OFP, there will be 3 files received in AIRCOM® ServerPlatform, which can be templated and forwarded to the EFB application

400

ASP Administrator Guide Version 6.9a

Appendix A: XML Output Format Messages generated for users configured with the “Send outgoing messages in XML” option are automatically wrapped in an XML envelope, independently of being distributed in raw or reformatted with models. The following is an example of a message matching a template called “OOOI OFF Report”:



2007-12-06T12:45:36 2007-12-06T12:44:21 .XS-EBA XS0004 A80 QXS CDG1 061414 M29A











QU ASRV1XS .QXSXMXS A80 AN .XS-EBA/FI XS0004 DT QXS CDG1 061414 M29A MVA SIT0004/20.XSEBA.LFPG AD1225/1245 EA0047 WSSS

Flight Departure Message (OFF) Date : 06/12/2007 GMT: 12:45:36 ---------------------------------------------------------------Flight Number : XS0004 (Aircraft Reg : .XS-EBA) Departing : LFPG - PARIS-CHARLES DE GAULLE,FRANCE Destination : WSSS - SINGAPORE/CHANGI,SINGAPORE ---------------------------------------------------------------Gate Push back Time : 1225 Take Off Time : 1245 ETA To Destination : 0047

Out-of-sequence OOOI Off for [.XS-EBA]: tracking data cleared and started over for new flight; the new flight is [XS0004] from [LFPG] whereas the tracked one was [XS0001] from [LFPG]



The data structure of the XML contents is depicted on the next page of this document. Its full content is described in the “AircomSrvMsg Schema.xsd” file, available in the AIRCOM® ServerPlatform installation package, under “Doc\XML”.

401

ASP Administrator Guide Version 6.9a

level:

Figure A-9.129: AircomSrvMsg Schema - level

402

ASP Administrator Guide Version 6.9a

level:

Figure A-9.130: AircomSrvMsg Schema - level

403

ASP Administrator Guide Version 6.9a

Appendix B: MIAM XSD An overview of the schemas of the MIAM XML messages is depicted in the next few pages. The full schemas contents are described in the “MIAM Schema v1.5.xsd” file, available in the AIRCOM® ServerPlatform documentation, under “Doc\XML”.

Figure B-1: MIAM Send.LocalStatus

404

ASP Administrator Guide Version 6.9a

405

ASP Administrator Guide Version 6.9a

Figure B-2: MIAM Send.Request

Figure B-3: MIAM Send.Status

406

ASP Administrator Guide Version 6.9a

Figure B-4: MIAM SendMulticast.Request

407

ASP Administrator Guide Version 6.9a

Figure B-5: MIAM Receive.Indication

408

ASP Administrator Guide Version 6.9a

Send.Request XML Example



RFTEST EST

SMI Source Ground true 4 true Yes 2011-04-18T13:32:00Z 2011-04-18T14:00:00Z

Acars uplink

UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi



CYUL YUL



XYSwvMQ+wbv6t56w7q1Kf5nLi30h3z22876xV9VQuHs=

Note: The Payload Content is Base64 encoded.

409

ASP Administrator Guide Version 6.9a

Send.Multicast.Request XML Example

SQ AC SQ ACZ2

RFTEST

9V-SFB

SMC Source Ground false 4 false Yes 2011-04-18T13:36:00Z 2011-04-18T14:00:00Z

Acars uplink

UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi



CYUL YUL



XYSwvMQ+wbv6t56w7q1Kf5nLi30h3z22876xV9VQuHs=

410

ASP Administrator Guide Version 6.9a

Send.Status XML Example



.RFTEST

SMI 123 true

CDG7 QXS VDL



Send.LocalStatus XML Example

124 true

Receive.Indication XML Example



EST .RFTEST

SQ0123

SMA 2011-04-18T13:40:33Z

MIAM Downlink

VGhpcyBpcyB0aGUgdGV4dCB0byBzZW5kLg0K

CDG7 QXS VDL



LUtk5TgXEKMwEVoS6b6k7co75pfTGzPuFBXtmBFlgn4=

411

ASP Administrator Guide Version 6.9a

Appendix C: Dial Engine Pro Configuration for SATCOM Dialing Installation of Dial Engine Pro Dial Engine Pro is installed via a setup application. Simply double-click on the file setup.exe located in the Support folder of the AIRCOM® ServerPlatform release media and the install program will guide through the installation. Configuration of Dial Engine Pro Use Windows Start | All Programs | Dial Engine Pro | Dial Engine to launch the configuration of the Dial Engine Pro (or right-click on the Dial Engine Pro icon in the Windows tray area if already running). Select the “General” tab. Under “Dialing Preferences”, select: • Check “Enable ‘Copy’ as a Dial command (from other docs)”. • Check “Accept dialing request from other applications”. • Check “Close Dialer on dropped line”. • Check “Enable Automatic Redial”.

Click “Set Params”. • Set the “Minimum and maximum number of digits of the selected number to be dialed” to 7 and 48 respectfully. • Click Done.

412

ASP Administrator Guide Version 6.9a

Click “General Preferences”. • Check “Show program’s icon in system tray”.

Select the “Advanced” tab. • Check “Dial using” and select the modem to use. • Uncheck “Dial first available line”. • Uncheck “Dial without modem”.

Select the “Expert” tab. • Check “Ignore Dialing Properties”. • Select “Tone Dial”. • Uncheck “Allow special characters”. • Check “Do not use Calling Card for local calls”. • Check “Conceal identity (when calling out)”. • Set the value of “Treat as International Call when # of digits >” to 50. • Select “Automatic busy detect”.

413