MM PDF

MAINTENANCE MANUAL
A-SMGCS
A3000
A-SMGCS A3000
Document no: 00-12-91.MM
Rev. 01 Approved – 2009-05-14
by
HITT Holland Institute of Traffic Technology B.V.

PO Box 717
7300 AS Apeldoorn
© HITT B.V.
THIS DOCUMENT CONTAINS PROPRIETARY INFORMATION WHICH SHALL NOT

BE USED FOR OTHER PURPOSES THAN THOSE FOR WHICH IT HAS BEEN
RELEASED, NOR BE REPRODUCED OR DISCLOSED TO THIRD PARTIES
WITHOUT THE PRIOR WRITTEN CONSENT OF HITT HOLLAND INSTITUTE OF
TRAFFIC TECHNOLOGY B.V., THE NETHERLAND
HITT PROPRIETARY, Rev. 01 Approved 2 of 228

Subject to restrictive legend on page 2
TABLE OF CONTENTS
HISTORY SHEET......................................................................................................12
REFERENCED DOCUMENTS ..................................................................................13
1. SCOPE .............................................................................................................14
1.1 Purpose and Audience............................................................................................................ 14
1.2 Document Structure ................................................................................................................ 14
1.3 Document Conventions........................................................................................................... 14
2. IMPLEMENTATION DETAILS .........................................................................16

2.1 System overview ..................................................................................................................... 16
2.1.1 System functional overview ............................................................................................. 16
2.1.2 System Users................................................................................................................... 18
2.1.3 System Start .................................................................................................................... 18
2.2 System functions ..................................................................................................................... 19
2.2.1 System Data flow ............................................................................................................. 19
2.2.2 External interface processing .......................................................................................... 21
2.2.2.1 ASIFIX ...................................................................................................................... 21
2.2.2.2 PLAMAS (Plan management interface).................................................................... 22
2.2.2.3 LIMAS (Airfield light interface) .................................................................................. 22
2.2.2.4 HYME (AWOS) ......................................................................................................... 22
2.2.3 SMR Video processing .................................................................................................... 23
2.2.3.1 Video processor........................................................................................................ 23
2.2.3.2 Video processing maps ............................................................................................ 24
2.2.4 Tracking ........................................................................................................................... 28
2.2.4.1 TargHITTint............................................................................................................... 30
2.2.4.2 TargHITT .................................................................................................................. 32
2.2.4.3 TFP ........................................................................................................................... 34
2.2.5 Traffic Presentation.......................................................................................................... 36
2.2.5.1 Traffic Display (TRADIS) .......................................................................................... 36
2.2.5.2 Traffic Monitor (TRAMON)........................................................................................ 36
2.2.5.3 HydroMeteo (HYMESET) ......................................................................................... 36
2.2.6 Maintenance functions ..................................................................................................... 37
2.2.6.1 Control and Monitoring (CMS) .................................................................................. 37
2.2.6.2 Radar Control and Monitoring (RACOMS) ............................................................... 40
2.2.6.3 Video Extractor Scope (VES) ................................................................................... 41
2.2.7 Supplementary functions ................................................................................................. 42
2.2.7.1 Recording and Replay (LOGIT)................................................................................ 42
2.2.7.2 Archiving data (ARCHIT) .......................................................................................... 43
2.2.7.3 Statistical Information Collector (SICO).................................................................... 43
2.2.8 Alerting Function: Runway Incursion Monitoring (RIM) ................................................... 44
2.2.8.1 RIM Single track conflicts ......................................................................................... 45
2.2.8.2 RIM Approach conflicts............................................................................................. 45
2.2.8.3 RIM Runway conflicts ............................................................................................... 46
2.2.8.4 RIM Crossing Runways conflict (optional)................................................................ 48
2.2.8.5 RIM Dependent Parallel Runways (optional) ........................................................... 49
2.3 System description .................................................................................................................. 52
2.3.1 Operating system............................................................................................................. 52
2.3.2 System Applications......................................................................................................... 52
2.3.2.1 Application Startup and Shutdown ........................................................................... 52
2.3.2.2 Application Reports................................................................................................... 52
2.3.2.3 Application Initialization ............................................................................................ 52
2.3.2.4 Application Communication ...................................................................................... 52
2.3.2.5 Application Configuration.......................................................................................... 52

2.3.2.6 Application Directories .............................................................................................. 53
2.3.2.7 Maps ......................................................................................................................... 53
2.3.2.8 Overview of configuration files and maps................................................................. 55
2.3.3 System Time .................................................................................................................... 59
2.3.4 System Directories........................................................................................................... 59
2.3.4.1 Directory structure hittsys ......................................................................................... 59
2.3.4.2 Directory structure CMS ........................................................................................... 61
2.3.5 System Redundancy........................................................................................................ 62
2.3.6 System Changes.............................................................................................................. 63
2.3.7 System Modes ................................................................................................................. 65
2.3.7.1 Operational mode ..................................................................................................... 65
2.3.7.2 Technical replay mode.............................................................................................. 65
2.3.7.3 Operational replay versus technical replay .............................................................. 65
2.4 System specific items.............................................................................................................. 67
2.4.1 Project settings ................................................................................................................ 67
2.4.2 Working positions............................................................................................................. 67
2.4.3 Sensor settings ................................................................................................................ 67
3. MAINTENANCE CONCEPT.............................................................................69
3.1 Introduction.............................................................................................................................. 69
3.2 Maintenance Organization Aspects ........................................................................................ 69
3.2.1 Responsibilities ................................................................................................................ 69
3.2.2 Management, Co-ordination and Administration ............................................................. 69
3.2.3 Maintenance Administration............................................................................................. 69
3.3 Maintenance types .................................................................................................................. 70
3.3.1 Preventive Maintenance .................................................................................................. 70
3.3.2 Corrective Maintenance ................................................................................................... 70
3.3.3 Adaptive Maintenance ..................................................................................................... 71
3.3.4 System Enhancement...................................................................................................... 71
4. MAINTENANCE FACILITIES...........................................................................72
4.1 Maintenance applications........................................................................................................ 72
4.2 Maintenance tools ................................................................................................................... 72
4.2.1 Linux environment (KDE)................................................................................................. 72
4.2.1.1 KDE-menu: HITT applications .................................................................................. 72
4.2.1.2 KDE-menu: System/Utilities ..................................................................................... 73
4.2.1.3 Burning files on CD or DVD ...................................................................................... 74
4.2.1.4 Standard Available Linux commands ....................................................................... 75
4.2.2 Eval-monitor ..................................................................................................................... 75
4.2.2.1 TargHITT-Interface (TargHITTint) ............................................................................ 76
4.2.2.2 TargHITT .................................................................................................................. 78
4.2.2.3 TFP ........................................................................................................................... 78
4.2.2.4 PLAMAS ................................................................................................................... 81
4.2.2.5 HYMESET ................................................................................................................ 82
4.2.2.6 ITRIP (optional)......................................................................................................... 83
4.2.2.7 Log eval output in a file............................................................................................. 83
4.2.3 COMMS-monitor .............................................................................................................. 83
4.2.3.1 Using the COMMS-monitor ...................................................................................... 83
4.2.4 Monitor Asterix ................................................................................................................. 85
4.2.5 LISTEN-script................................................................................................................... 86
4.2.6 Tcpdump command ......................................................................................................... 86
4.2.7 Commslog ........................................................................................................................ 87
4.2.8 Coordinate Converter (COCO) ........................................................................................ 89
4.2.9 Memory stick / USB disk .................................................................................................. 90
5. FAULT FINDING ..............................................................................................91

6. GENERAL MAINTENANCE.............................................................................95
6.1 Basic procedures .................................................................................................................... 95
G_1: Logging in on nodes........................................................................................................... 95
G_2: Distribute changes with autochanges ................................................................................ 95
G_3: Running configure.............................................................................................................. 96
G_3.1: Node configure................................................................................................................ 96
G_3.2: Hittsys configure ............................................................................................................. 97
G_3.3: Partial configure .............................................................................................................. 97
G_4: Determine the mode of a node .......................................................................................... 97
G_5: Changing the mode of a node ........................................................................................... 98
6.2 Replay of archived data .......................................................................................................... 98
G_6: Restoring archived data ..................................................................................................... 98
G_7: Setting up an operational replay session........................................................................... 99
G_8: Setting up a technical replay session .............................................................................. 100
6.3 Network connections ............................................................................................................. 101
G_9: Check network connectivity ............................................................................................. 101
7. ADAPTIVE MAINTENANCE ..........................................................................103

7.1 Radar video settings ............................................................................................................. 104
A_1.1: Maintain mask maps ..................................................................................................... 104
A_1.2: Maintain grass maps ..................................................................................................... 104
A_1.3: Maintain track maps ...................................................................................................... 104
7.2 Tracking settings ................................................................................................................... 104
A_2: Maintain coverage maps .................................................................................................. 104
A_3: Maintain semi-coverage areas ......................................................................................... 104
A_4: Maintain shadowing areas................................................................................................ 104
A_5: Maintain Non-Automatic Initiation areas .......................................................................... 105
A_6: Maintain blanking areas ................................................................................................... 105
A_7: Maintain RWY areas ........................................................................................................ 105
A_7.1: RDPS coverage areas................................................................................................... 105
7.3 Identification settings............................................................................................................. 105
A_8: Maintain IDT areas ........................................................................................................... 105
A_8.1: Maintain plan distribution............................................................................................... 106
7.4 Alert settings.......................................................................................................................... 106
7.4.1 Alert presentation........................................................................................................... 106
A_9.1: Maintain alert strings ..................................................................................................... 106
A_9.2: Maintain alert presentation ............................................................................................ 107
A_9.3: Maintain alert sounds .................................................................................................... 107
A_10: Maintain application parameters in maps....................................................................... 107
7.4.2 APM settings .................................................................................................................. 109
A_11: Maintain APM settings.................................................................................................... 109
A_11.1: Edit APM Area(s)......................................................................................................... 109
7.4.3 RIM settings ................................................................................................................... 110
A_12: Maintain RIM settings..................................................................................................... 110
A_12.1: Maintain RIM Areas..................................................................................................... 110
A_12.2: Maintain RIM Parameters ........................................................................................... 110
A_12.3: Maintain RIM sub functions ......................................................................................... 111
7.4.4 SID / Runway settings.................................................................................................... 111
A_13: Maintain SID / Runway settings ..................................................................................... 112
A_13.1: Update SIDs in TRADIS .............................................................................................. 112
A_13.2: Update SIDs in TFP (in alr.ini) .................................................................................... 112
A_13.3: Update SID/RWY alert lines (in alrareas.cgm)...................................................... 113
7.4.5 TCM settings .................................................................................................................. 113
A_14: Maintain TCM settings.................................................................................................... 113
A_14.1: Maintain Taxiway Topology......................................................................................... 113
A_14.2: Maintain TCM parameters........................................................................................... 115
7.4.6 RVM Settings ................................................................................................................. 116
A_15: Maintain RVM Settings................................................................................................... 116
A_15.1: Maintain RVM Airport Topology .................................................................................. 116

A_15.2: Maintain Restrictions ................................................................................................... 118
7.4.7 Stopbar settings ............................................................................................................. 119
A-16: Maintain stopbar settings ................................................................................................ 119
7.5 Pushback areas settings ....................................................................................................... 120
A_17: Maintain pushback areas settings .................................................................................. 120
7.6 TRADIS settings.................................................................................................................... 121
7.6.1 Traffic settings................................................................................................................ 121
A_21: Maintain track filters ....................................................................................................... 121
A_22: Maintain history dots ...................................................................................................... 121
A_23: Maintain Label Contents................................................................................................. 122
A_24: Maintain Label Scheme.................................................................................................. 122
A_25: Maintain Mosaic ............................................................................................................. 123
A_26: Maintain operational roles .............................................................................................. 123
A_27: Maintain stand names .................................................................................................... 123
A_28: Modify colours ................................................................................................................ 124
A_28.1: Add colour palette ....................................................................................................... 124
A_28.2: Remove colour palette ................................................................................................ 124
A_29: Maintain fonts ................................................................................................................. 125
A_30: Maintain Preset Areas .................................................................................................... 125
A_31: Maintain clock format ..................................................................................................... 126
A_32: Maintain about picture .................................................................................................... 126
A_33: Maintain System Status presentation............................................................................. 126
A_34: Add a map ...................................................................................................................... 126
A_35: Remove a map ............................................................................................................... 127
A_36: Make a map editable ...................................................................................................... 128
A_37: Maintain vehicles............................................................................................................ 128
A_38: Change columns in lists ................................................................................................. 128
A_39: Change list presentation................................................................................................. 129
A_40: Change menu presentation ............................................................................................ 129
A_41: Change maximum number of stored profiles ................................................................. 129
A_42: Change text that is used in dialogues ............................................................................ 130
7.7 SICO settings ........................................................................................................................ 130
A_60: Maintain SICO ................................................................................................................ 130
7.8 CMS settings ......................................................................................................................... 131
A_70: Modify CMS messages .................................................................................................. 131
8. CORRECTIVE MAINTENANCE.....................................................................133
C_1: Starting/Stopping/Rebooting Nodes................................................................................. 133
C_2: Reinstall software on a node............................................................................................ 133
C_3: Correct time synchronization............................................................................................ 133
C_4: Taking a radar into service/maintenance ......................................................................... 134
C_5: Modify SMR maps............................................................................................................ 134
C_6: Adapt display resolution to connected monitor ................................................................ 134
9. PREVENTIVE MAINTENANCE......................................................................135
9.1 Daily Maintenance................................................................................................................. 135
D_1: Check system status using CMS ..................................................................................... 135
9.2 Weekly Maintenance............................................................................................................. 135
W_1: Replace ARCHIT tape..................................................................................................... 135
W_2: Check report files ............................................................................................................ 135
W_3: Check External Interface with approach radar ................................................................ 136
W_4: Check Flight Plan Interface ............................................................................................. 139
W_5: Check time synchronization ............................................................................................ 141
9.3 Monthly Maintenance ............................................................................................................ 143
M_1: Check (and adapt) Video Alignment and Video Level of the SMR video ........................ 143
M_2: Check Linux processes.................................................................................................... 146
M_3: Check computer load....................................................................................................... 146
M_4: Check memory usage...................................................................................................... 148
M_5: Check disk space............................................................................................................. 148

M_6: Check redundancy........................................................................................................... 148
M_7: Check backup of changes ............................................................................................... 149
M_8: Check archit tape............................................................................................................. 149
M_9: Check on any core files ................................................................................................... 149
9.4 Yearly Maintenance .............................................................................................................. 149
9.5 Maintenance (Miscellaneous) ............................................................................................... 149
10. APPENDIX: TRAFFIC DISPLAY (TRADIS)...................................................150

10.1 Colour editor.......................................................................................................................... 150
10.2 Label editor............................................................................................................................ 151
10.3 Map editor ............................................................................................................................. 153
10.4 Track groups ......................................................................................................................... 153
10.5 Video Presentation ................................................................................................................ 154
10.6 Sensor Settings ..................................................................................................................... 156
11. APPENDIX: SYSTEM CONTROL (CMS PORTAL).......................................157

11.1 Navigation ............................................................................................................................. 158
11.2 Iconview ................................................................................................................................ 158
11.2.1 Open URL .................................................................................................................. 159
11.2.2 URL of HP ProLiant server......................................................................................... 159
11.2.3 Properties ................................................................................................................... 159
11.3 Treeview................................................................................................................................ 160
11.3.1 Applications ................................................................................................................ 162
11.3.2 System........................................................................................................................ 163
11.3.3 External ...................................................................................................................... 164
11.4 System Messages (Received Events) .................................................................................. 165
12. APPENDIX: RADAR CONTROL AND MONITORING (CMS RADAR) .........166

12.1 Radar details ......................................................................................................................... 167
12.2 Radar details header ............................................................................................................. 167
12.3 Radar details footer ............................................................................................................... 168
12.4 Tab States ............................................................................................................................. 168
12.5 Tab Settings .......................................................................................................................... 169
12.6 Tab BITE ............................................................................................................................... 170
12.7 Tab Errors & Warnings.......................................................................................................... 171
12.8 Tab PRF ................................................................................................................................ 172
12.9 Tab STC ................................................................................................................................ 173
12.10 Tab Sector ......................................................................................................................... 174
12.11 Tab Diversity...................................................................................................................... 175
12.12 Tab Profile ......................................................................................................................... 175
13. APPENDIX: REPLAY CONTROL (REPLAY GUI).........................................176

13.1 Replay control elements........................................................................................................ 176
13.1.1 Date/time selection..................................................................................................... 176
13.1.2 Replay control buttons................................................................................................ 177
13.2 Sessions................................................................................................................................ 178
13.3 Data Selection ....................................................................................................................... 178
13.4 Voice ..................................................................................................................................... 179
13.5 Messages .............................................................................................................................. 179
13.6 Status line.............................................................................................................................. 180
13.7 About ..................................................................................................................................... 180
14. APPENDIX: ARCHIVING DATA (ARCHIT) ...................................................181

14.1 Overview ............................................................................................................................... 181
14.2 ARCHIT Operation ................................................................................................................ 182
14.3 The ARCHIT GUI .................................................................................................................. 184
14.3.1 ARCHIT GUI Items..................................................................................................... 184

14.3.2 ARCHIT GUI Buttons ................................................................................................. 185
14.4 Start ARCHIT GUI ................................................................................................................. 186
14.5 Work with on-line tape information........................................................................................ 187
14.6 Work with tapes..................................................................................................................... 189
14.7 Work with ARCHIT scheduler ............................................................................................... 192
14.8 Reset ARCHIT....................................................................................................................... 193
14.9 ARCHIT Configuration .......................................................................................................... 194
14.9.1 Section ArchitSettings ................................................................................................ 194
14.9.2 Section ArchitSession ................................................................................................ 197
15. APPENDIX: VIDEO EXTRACTOR SCOPE (VES).........................................198

15.1 Overview ............................................................................................................................... 198
15.2 Starting the Video Extractor Scope ....................................................................................... 198
15.3 User interface ........................................................................................................................ 198
16. APPENDIX: ABBREVIATIONS......................................................................201
17. APPENDIX: PREVENTIVE MAINTENANCE CHECKLIST............................203

17.1 Checklist (example)............................................................................................................... 203
17.1.1 General....................................................................................................................... 203
17.1.2 Visual System Inspection ........................................................................................... 203
17.1.3 Operational Nodes ..................................................................................................... 203
17.1.4 System Nodes ............................................................................................................ 203
17.1.5 Track load................................................................................................................... 203
17.1.6 Recording and Replay Processors............................................................................. 203
17.1.7 Radar Data Processors .............................................................................................. 204
17.1.8 Check Redundancy .................................................................................................... 204
17.1.9 Remarks ..................................................................................................................... 204
17.2 Daily Maintenance Checklist ................................................................................................. 205
17.3 Weekly Maintenance Checklist ............................................................................................. 205
17.4 Monthly Maintenance Checklist ............................................................................................ 205
17.5 Yearly Maintenance Checklist............................................................................................... 206
18. APPENDIX: SMR ALIGNMENT POINTS.......................................................207
19. APPENDIX: MAPS.........................................................................................208
20. APPENDIX: CGM DESCRIPTION .................................................................209
21. APPENDIX: XML FILES.................................................................................212
INDEX......................................................................................................................227

LIST OF FIGURES
Figure 1: System functional overview.................................................................................................... 17

Figure 2: Data flow (operational) ........................................................................................................... 20
Figure 3: Video samples and threshold cells......................................................................................... 23
Figure 4: Detected object structure ....................................................................................................... 24
Figure 5: Video processing and tracking related maps ......................................................................... 26
Figure 6: SMR video processing maps (example) ................................................................................ 27
Figure 7: Targhitt maps (example) ........................................................................................................ 29
Figure 8: Overview of the CMS system ................................................................................................. 38
Figure 9: Overview of applications reports ............................................................................................ 40
Figure 10: Remote radar control facility................................................................................................. 41
Figure 11: RIM-RW approach conflict ................................................................................................... 46
Figure 12: RIM-RW Runway conflict, tracks moving toward each other ............................................... 47
Figure 13: RIM-RW Runway conflict, tracks moving in the same direction........................................... 47
Figure 14: RIM-RW crossing runways................................................................................................... 48
Figure 15: RIM-RW parallel runway usage ........................................................................................... 50
Figure 16: RIM-RW opposite runway usage ......................................................................................... 50
Figure 17: Initialization and configuration (example of the TFP-application) ........................................ 53
Figure 18: NTP Time Synchronization Overview .................................................................................. 59
Figure 19: Data flow (technical replay) .................................................................................................. 66
Figure 20: KDE-menu ............................................................................................................................ 72
Figure 21: KDE-menu HITT applications (example).............................................................................. 73
Figure 22 K3b-> New Data CD Project ................................................................................................. 74
Figure 23 K3b GUI................................................................................................................................. 74
Figure 24: Connection diagram Rack Manager..................................................................................... 95
Figure 25: ARCHIT Dialogue................................................................................................................. 99
Figure 26: Line to Reference Position ................................................................................................. 109
Figure 27: RIM map (simplified) .......................................................................................................... 110
Figure 28: Editing the taxiway topology............................................................................................... 115
Figure 29: Taxiway segments.............................................................................................................. 115
Figure 30: Editing the TRAMON topology ........................................................................................... 117
Figure 31: TRAMON segments ........................................................................................................... 117
Figure 32: Status LED's converters ..................................................................................................... 136
Figure 33: Reference point on VES..................................................................................................... 145
Figure 34: Zero-level of the video on VES .......................................................................................... 145
Figure 35: Colour editor ....................................................................................................................... 150
Figure 36: Label editor......................................................................................................................... 151
Figure 37: Label layout with columns .................................................................................................. 152
Figure 38: Track Groups...................................................................................................................... 154
Figure 39: Video Presentation Dialogue.............................................................................................. 155
Figure 40: Video Mosaic mechanism .................................................................................................. 155
Figure 41: Sensor settings................................................................................................................... 156
Figure 42: CMS Overview (example) .................................................................................................. 157
Figure 43: Status Propagation (in a Treeview) .................................................................................... 158
Figure 44: Menu selection (in a Treeview) .......................................................................................... 158
Figure 45: HP ProLiant servers (iLO-window) ..................................................................................... 159
Figure 46: Properties window .............................................................................................................. 160
Figure 47: Treeview ............................................................................................................................. 161
Figure 48: Application status Information of an item in Treeview........................................................ 162
Figure 49: Hardware Status Information of an item in Treeview ......................................................... 162
Figure 50: CMS Actions....................................................................................................................... 162
Figure 51: Application Instance ........................................................................................................... 163
Figure 52: Information of a processor.................................................................................................. 163
Figure 53: Information of an external device ....................................................................................... 164

Figure 54: System Messages .............................................................................................................. 165
Figure 55: CMS Radar overview ......................................................................................................... 166
Figure 56: CMS Radar details ............................................................................................................. 167
Figure 57: Tab Settings ....................................................................................................................... 169
Figure 58: Tab BITE ............................................................................................................................ 170
Figure 59: Tab Errors & Warnings....................................................................................................... 171
Figure 60: Tab PRF ............................................................................................................................. 172
Figure 61: Tab STC ............................................................................................................................. 173
Figure 62: Tab Sector .......................................................................................................................... 174
Figure 63: Blanking Sector .................................................................................................................. 174
Figure 64: Tab Diversity ...................................................................................................................... 175
Figure 65: Replay Control window....................................................................................................... 176
Figure 66: Date/time selection............................................................................................................. 176
Figure 67: Replay control buttons........................................................................................................ 177
Figure 68: Collapsed replay control window........................................................................................ 177
Figure 69: Tab: Session ...................................................................................................................... 178
Figure 70: Tab: Data Selection............................................................................................................ 179
Figure 71: Tab: Voice .......................................................................................................................... 179
Figure 72: Tab: Messages ................................................................................................................... 180
Figure 73: ARCHIT Operational Environment ..................................................................................... 181
Figure 74: ARCHIT Tape contents ...................................................................................................... 183
Figure 75: ARCHIT GUI - Main window............................................................................................... 184
Figure 76: ARCHIT sub-window Connect............................................................................................ 186
Figure 77: ARCHIT sub-window Session ............................................................................................ 188
Figure 78: ARCHIT sub-window Remove............................................................................................ 189
Figure 79: ARCHIT sub-window Restore ............................................................................................ 190
Figure 80: ARCHIT sub-window Archive ............................................................................................. 190
Figure 81: ARCHIT sub-window Erase................................................................................................ 191
Figure 82: ARCHIT sub-window Recreate .......................................................................................... 192
Figure 83: ARCHIT sub-window Reschedule cycles........................................................................... 193
Figure 84: Video Extractor Scope screenshot ..................................................................................... 198

LIST OF TABLES
Table 1: Supported ASTERIX interface categories ............................................................................... 21

Table 2: LOGIT Directories.................................................................................................................... 42
Table 3: Track classification .................................................................................................................. 45
Table 4: RIM-RW Approach Parameters............................................................................................... 46
Table 5: RIM-RW Runway Parameters ................................................................................................. 47
Table 6: RIM-RW Crossing Runway Parameters.................................................................................. 49
Table 7: RIM-RW Parallel Dependent Runway Parameters ................................................................. 50
Table 8: RIM-RW Parallel Dependencies.............................................................................................. 51
Table 9: List of configuration files and maps ......................................................................................... 58
Table 10: Directory structure hittsys ...................................................................................................... 60
Table 11: CMS directory structure......................................................................................................... 61
Table 12: Redundant Applications......................................................................................................... 62
Table 13: User Logins (auto/manual) .................................................................................................... 67
Table 14: Fault Finding for video and tracking ...................................................................................... 93
Table 15: Fault Finding for identification................................................................................................ 94
Table 16 Plan distribution parameters................................................................................................. 106
Table 17: RIM sub functions................................................................................................................ 111
Table 18: TCM Parameters ................................................................................................................. 116
Table 19: Label types .......................................................................................................................... 151
Table 20: Label fields........................................................................................................................... 153
Table 21: View Pane Status Colors..................................................................................................... 158
Table 22: Colours of Received Events ................................................................................................ 165
Table 23: Abbreviations ....................................................................................................................... 202
Table 24 SMR Alignment points .......................................................................................................... 207

HISTORY SHEET
HISTORY SHEET
REV DATE PCFno DESCRIPTION RESPONSIBLE
00 2009-05-05 - Derived from A-SMGCS 1.6 R. Piek
01 2009-05-14 114604-10 Implementation of project specifics R. Piek
114603-2

REFERENCED DOCUMENTS
REFERENCED DOCUMENTS
Reference Document Name Document ID

[FS] Functional Specification (FS) 00-08-21.FS
[SSDD] System Segment Design Document (SSDD) 00-08-21.SSDD
[VDD] Version Description Document (VDD) 00-12-91.VDD
[ID] Installation Document (ID) 00-12-91.ID
[OM] Operational Manual (OM) 00-12-91.OM

SCOPE
1. SCOPE
1.1 Purpose and Audience

This manual describes the maintenance activities necessary for A-SMGCS A3000..
Correct execution of the maintenance activities results in maximum availability of the system.
This manual is intended to be used by the maintenance personnel.
Note: Parameters that are not described in project delivered manuals must not be modified.
1.2 Document Structure

The document contains the following subjects:
• Chapter 1 (Scope) describes the scope of the document.
• Chapter 2 (Implementation Details) describes the implementation details relevant for the
maintenance activities.
• Chapter 3 (Maintenance concept) describes the maintenance concept and the organisation of
maintenance activities.
• Chapter 4 (Maintenance ) describes applications and tools available for maintenance
activities.
• Chapter 5 (Fault finding) contains fault finding tables.
• Chapter 6 (General maintenance) describes general activities of the maintenance engineer.
• Chapter 7 (Adaptive maintenance) describes the procedures to modify the systems behaviour.
• Chapter 8 (Corrective maintenance) describes the procedures for carrying out corrective
maintenance.
• Chapter 9 (Preventive maintenance) describes the procedures for carrying out period system
checks.
• Appendices, including:
o The Graphical User Interface (GUI) of applications for the maintenance engineer:
TRADIS (the maintenance part only), CMS, RACOMS, LOGIT, ARCHIT and VES.
o Abbreviations, listing the abbreviations that are used throughout this document.
o Directory Structure, describing the directories on the computer nodes that are
available in this A-SMGCS.
o Preventive Maintenance Checklist, containing the checklists to be filled during the
period preventive maintenance checks.
o CGM Description, describing the syntax of the CGM map-files that are used on the A-
SMGCS
o XML files, describing the syntax of the XML files that are used on the A-SMGCS.
1.3 Document Conventions

Text Style
The following text style conventions are used throughout this document:
• References are presented like this: (see Appendix: Traffic Display (TRADIS)) or see 4.2.2 Eval-
monitor)
• Text like this is used for definitions and to make keywords stand out in the text.
• Node types use this style: CMSP.
• Node names are written in lowercase, like this: ctp01.
• Keys on the keyboard are shown as <Enter>.
• Text like this is available in the index.
• File names and directory names are presented like this: /hittsys/tfpdata/tfp.ini
Directory names
Directory names can be either:
• Fully specified, such as /auto/changes/patches
• Relative to /hittsys, such as tfpdata/use
In other words: if a directory is not fully specified it is relative to /hittsys.

SCOPE
Command lines
Command lines are prefixed with a general prompt (>), like this:
> ps –efww
If a command line is entered as root, it is indicated with a ‘#’ symbol, like this:
# configure
Note that a command that must be entered in a telnet-session is indicated also with a ‘>’ symbol, like
this:
> sn on

IMPLEMENTATION DETAILS
2. IMPLEMENTATION DETAILS
This chapter describes implementation details which are relevant for the maintenance engineer.
Before studying any other document, first study:

• the Functional Specification (FS), refer to [FS].
• the System Segment Design Document (SSDD), refer to [SSDD].
The FS and SSDD documents give a good overview of the product and describe the system on the
highest level.
For example, the SSDD-document describes the system realization and identifies the software
(applications), the hardware (computers, network) and the interfaces.
The implementation details are subdivided into:

• system overview
• system functions
• system description
• project specific items
2.1 System overview
2.1.1 System functional overview

The following figure (Figure 1) functions as a ‘general functional overview’ diagram, and indicates the
environment (context) for the users of the system.
Figure 1 contains:
• the external connections,
• the (redundant) hardware and software components,
• the (graphical) user interfaces for controller and maintainer.

Figure 1: System functional overview

2.1.2 System Users

This section describes the relevant system users.
The A-SMGCS has been set up in a way that:

• Operational personnel (controller and aproncontroller) is allowed to carry out controller tasks,
but has no maintenance access;
• Technical personnel (hittsys, maintenance and root) is not allowed to carry out controller
tasks, but only has maintenance access.
The user Controller and Aproncontroller are automatically logged in on their nodes. Other users must
manually login with their user names. The corresponding passwords are listed in the Version
Document [ID].
• Operational personnel:
- controller: The controller user has controller access on TRADIS. The role controller is
fixed to a predefined number of positions and determine at system-configuration.
- aproncontroller: The apron controller user has apronontroller access on TRADIS.
The role apron controller is fixed to a predefined number of positions and determined
at system-configuration.
• Technical personnel:
- maintenance: The maintenance user is capable of:
Controlling and monitoring the system via CMS.
Full level Radar control and monitor functions.
TRADIS access in the maintenance mode.
- hittsys: The user hittsys is capable of accessing all A-SMGCS nodes. This user has
full access to HITT application configuration files and can use TRADIS as
maintenance user. To be used for fault finding, hittsys configure and system analysis.
- root: The user root is rarely used. This user has unlimited access to the system, and
is used during system-installation and when system-level changes are required. Also,
the node configure has to be executed as user root.
2.1.3 System Start

When powered-on the system starts automatically. On operational working positions, the operational
software is started automatically. On maintenance working positions, software can be started
manually.

2.2 System functions
2.2.1 System Data flow

Figure 2 shows a more detailed overview of the system with the main operational data flow and the
mapping of the software on the computers.
It also shows the replay data flow when recorded data is replayed.
Figure 2 is particularly useful for understanding the system and for fault finding.
The system functions of the components in Figure 2 are described in the following paragraphs. In
these descriptions all kinds of configuration files are mentioned (ini, xml, com, cgm-files). An overview
of these configuration files can be found in par. 2.3.2.8.

Data flow (operational)

SMR
comp. video
FDPS /
ARTAS Airfield GPS
MLAT MLAT Airport
Approach AWOS Lighting Time
status / system system data
tracker System Server
commands base
dig. video
ASTERIX Flight Stop
ACP, NP ASTERIX ASTERIX METAR data
CAT Bar
CAT 21 CAT 19/20
062/065 status
VP1
video samples
Radar Control Light
ADS-B MLAT Approach METEO
& Monitoring input (ASIFIX- input Conversion
Plan Conversion interface
(PLAMAS) Conversion
(RACOMS) (ADSBIN) MLAT) (ASIFIX) (HYME)
radar Hit & Treshhold (LIMAS)
status Processing
(HTP)
ADS-B MLAT Approach Meteo (FDPS)

reports reports reports reports Flight
plans
htp plots Tracks
(events)
Time
(ntp)
Tracker Interface
Tracking (TARGHITTINT)
(TARGHITT)
targhitt tracks 90, 91
digitised
Alerting / Identification / Fusion
video
(TFP)
41
system
Meteo settings tracks Traffic Monitor
(HYMESET) (TRAMON)
identification
commands
visibility runway/ alerts
taxiway alerts
runway closures connection flight
configu- status data Stopbar
ration -Commands
-Alerts
-Status
CMS
Traffic Monitoring HMI
Server
(TRADIS)
(CMS)
status /
commands
- - - - - (for test purposes only) - - -

analogue
audio MLAT approach
htp Data plots
plots (cat 19/20) visibility runway configuration meteo plans
Hardware dig. system
Sound targhitt Identified video stopbar
ADSB display tracks
sampler approach
(PICA)
tracks Data commands
(cat 21) tracks
samples
Audio Recording Statistics

Convertor
(LOGITSTC) digitized (LOGITREC) (SICO)
audio
text Events
file
tape
store
archived
data
Archiving Replay
(ARCHIT) (LOGITREP)
replay time RWY approach

config plots
radar flight
video data Targhitt CMS info
Audio system visibility tracks
ARCHIT View tracks
(Archiving) plots display replayed
(inputs (additional settings data / controls
as for technical alerts
Controller) inputs)
CMS SMR Traffic Monitoring CMSGUI

Archiving HMI Traffic Monitoring HMI Replay HMI
(RACOMSGUI) TRADIS (role: (via web
(ARCHITGUI) (TRADIS Replay) (REPLAYGUI)
maintenance) browser)
CMS Client Report Man. Job Control

On each node: (CMS) (REPMAN) (JCL)
ntpd
SW process SW process
In
Legenda: which is which is External
Hardware master/slave
always started system
configuration
running manually
Figure 2: Data flow (operational)

2.2.2 External interface processing

To interface with the various external systems (e.g. sensor equipment and the airport database
system), special interface processes (converters) are running on the Interface Processor (IP).
The interface processes convert data, represented in external data formats, into HITT internal data
formats and vice versa. The IP interfaces with:
• the approach radar (ASIFIX-RDPS)
• the MLAT system (ASIFIX-MLAT)
• the ADS-B system (ADSBIN
• the FDPS system (PLAMAS)
• the airfield light system (LIMAS)
• the airport database (PLAMAS)
• the airport automated weather observation system (HYME)
The CSCIs that are part of the IP are described in the following paragraphs.
2.2.2.1 ASIFIX
The ASTERIX Interface Fixer (ASIFIX) is a process used for converting the internal IFHITT messages
into ASTERIX messages and converting ASTERIX messages into IFHITT messages.
The following ASTERIX messages are supported:
Category Type Purpose

019 Input Mono-radar Surface Movement Data (radar and MLAT)
020 Input MLAT Target reports
021 Input ADS-B Messages
062 Input System Track Data
065 Input Surveillance data Exchange SDPS service status messages
Table 1: Supported ASTERIX interface categories
Initialisation:
Each ASIFIX-process is initialized by using two files i.e. for MSSR (approach plots) these are:
asifix_mssr_comms.sh and asifix_mssr.ini, which is used to specify for each ASTERIX
category among others, the input category, the type of ouput data, the type of input data, sensor id, the
max flight level and the mask map.
2.2.2.1.1 ASIFIX (RDPS/RDPS)

The ARTAS system provides approach reports (CAT 062/065) from the approach radar. The ASIFIX
process translates the information to the internal format.
2.2.2.1.2 ASIFIX (MLAT)

The Multilateration System (MLAT) provides multilateration tracks in ASTERIX category 20/21 format.
The ASIFIX-MLAT process translates the information to the internal format. The MLAT tracks are
filtered by coverage areas defined off-line, which also include a height filter based on flight level.
The tracks are sent to TargHITT for combination with other sources of plots and tracks.
ASIFIX-MLAT sends status and alarm information to the CMS Data Processing.
2.2.2.1.3 ADSBIN
The ADSBIN process receives ADS-B position information from the ADS-B System in ASTERIX
category 21 format. This information is then sent to the TargHITT function.
The transponder tracks are filtered by coverage areas defined off-line, which also include a height filter
based on flight level.
ADSBIN sends status and alarm information to the CMS Data Processing.

2.2.2.2 PLAMAS (Plan management interface)

The Plan Management Services (PLAMAS) is responsible for the interface with the FDPS system and
the airport database. The exact interface is a project specific effort.
Initialisation:
The plamas.ini file specifies among others, the data from the FDPS and the Gate Management
system.
2.2.2.3 LIMAS (Airfield light interface)

The Light Management System (LIMAS) is responsible for the interface with an airfield light system.
This interface provides e.g. input for the alerting functions, like the stop bar violation monitoring. The
interface is project specific, since there are several light system manufacturers.
Initialisation:
The limas.xml file specifies this interface.
2.2.2.4 HYME (AWOS)

The METEO conversion (HYME) is responsible for the interface with an airfield meteo system. This
interface is responsible for fetching and processing the AWOS messages.
Initialisation:
The hyme.xml file specifies this interface.

2.2.3 SMR Video processing
2.2.3.1 Video processor

The Video Processor (VP) digitises the analogue radar input video on a sweep basis. At the same time
the antenna azimuth count pulses are counted for direction information. Each video sweep is provided
with the actual azimuth count. This radar data is gathered in onboard memory for transportation to the
HTP-application.
Hardware configuration
The VP consists of a dedicated hardware board which is mounted in a PCI-slot of the RDP.
Before installation, the onboard jumper settings should be checked and possibly adjusted. The
jumpers control the input impedance of the analogue BNC-input signals. Two jumpers should be
placed for each input signal separately, as shown in the picture below. Refer to the [ID].
Video samples
The radar coverage area is divided in small segments, called video samples as depicted in Figure 3.
The size of the video sample is determined by:
• the antenna Azimuth Count Pulse (ACP) (usually 8192 pulses per revolution)
• the sample frequency. The video processor digitises the analogue video input in 8 bits (0...255
video levels), with a sample frequency of 40 MHz (equals 3,75m).
Note that only video in unmasked areas is processed.
The VP compares the received video to the local thresholds (see threshold cells). When the video
level exceeds the threshold level this is a hit. Hits are sent to HTP for processing.
Figure 3: Video samples and threshold cells
Threshold cells
The radar coverage area is divided in small segments, called threshold cells; each with an azimuth
size of 1.4 degrees (resulting in 256 cells in one revolution) and a range size of 8 video samples
(resulting in 512 threshold cells in range). For each threshold cell the video characteristics (mean and
deviation) are determined. These characteristics are sent to the HTP as clutter information.
Hit Threshold Processing (HTP)

The Hit and Threshold Processing (HTP) application processes the hit- and clutter information
(received from the VP) and produces hit information.

Low echo
strength
Object ring
Range
Plot
Medium echo
High echo strength Object
strength Object ring ring
Azimuth
Figure 4: Detected object structure

Object rings
The hit information is used to compose concentric object rings (see Figure 4). Adjacent hits with the
same range and echo strength are combined to one object ring. An object consists of one or more
adjacent object rings, which stand the range and echo strength dependent object detection criterions.
The object rings are sent to the display subsystem for raw video visualisation purposes.
Plot calculation
Object rings are also used for the plot calculation. A plot describes the object position, length, breadth,
heading and echo strengths. This plot information is sent to the tracking subsystem for tracking
purposes.
Clutter
The threshold cell clutter information is averaged with the clutter information of the surrounding
threshold cells. The averaged clutter is used for the threshold cell hit threshold level calculation, which
is sent back to the VP.
2.2.3.2 Video processing maps

Video processing maps describe the (SMR) areas where the radar video information from the SMR is
processed i.e. video on runway/taxiways (movement area) are processed differently (using other
extractor parameters) from video detected in grass areas (non-movement area).
The following areas can be distinguished:
Non-Movement area The non-movement area is area where video only (no tracks) is desired,
typically the grass areas.
The file vpgrass01.cgm is loaded into the RDP.
A separated threshold calculation (defined by the min_threshold in the
htp.ini) will be performed within this area.
Movement area The movement area is an area where video and possibly tracks are
desired, typically the pavement areas.
The file vpmask01.cgm is loaded into the RDP.
Threshold calculation (with a low threshold, resulting in high detection) will
be performed within this area.
Tracking area The tracking area is a part of the radar coverage area where tracks are
desired (hence plots must be calculated), typically a smaller part of the
movement area (e.g. excluding (parts of) the apron area).
Note that plots are used as input for the Targhitt-tracker to produce tracks.

The file vptrack01.cgm is loaded into the RDP.

A plot is only calculated if the object is (partly) located within the tracking
area.
Figure 5 illustrates the principle of processing SMR-radar data into:

• SMR video (movement and non-movement video)
• Tracks
that are presented on the TRADIS-display.
Figure 5 shows the various stages of this processing:

• video processing (by the VP and HTP),
• tracking (by Targhittint and Targhitt),
• creation system tracks (by TFP).
The lower part of Figure 5 shows the first stage of SMR video processing. SMR-video is ‘passed
through’ the non-movement area, movement area, and the tracking area (resp. the grass map, mask
map and the track map), and results in:
• SMR-video (movement-video and non-movement video) to TRADIS,
• Plots to the Targhitt tracker.
The SMR radar output that is:

• inside the grass map only is processed as ‘non-movement’ video and is shown on TRADIS as
‘non-movement’ video,
• inside the grass map and inside the mask map is processed as ‘movement’ video and is
shown on TRADIS as ‘movement’ video,
• inside the grass map, inside the mask map, and inside the track map are processed in HTP as
plots that are sent to the Targhitt-tracker,
• outside the grass map and outside the mask map is not further processed.
(For a description of the top part of Figure 5, refer to 2.2.4.)
Figure 6 shows an example of the video processing maps (movement area, non-movement area, and
the tracking area) in a geographical picture.

Figure 5: Video processing and tracking related maps

Figure 6: SMR video processing maps (example)

2.2.4 Tracking
Tracking is performed on input from various sources:
• Plots from the SMR radar
• Position reports (CAT 062/065) from the approach radar
• Position reports (CAT 019/020) from the MLAT system
• Position and identification information (CAT 021) from the ADS-B system
• Flight plan information from the FDPS system
To interface with the various external systems, special interface processes (converters) are running on
the Interface Processor (IP), see Figure 2: Data flow (operational) and par. 2.2.2 External interface
processing.
Tracking and track fusion is carried out by the TargHITT-application and the TFP-application.
The TargHITT-application is supported by the TargHITT-Interface (TargHITTint), which handles the

inputs and outputs of TargHITT.
TargHITTint receives:
• plots from the SMR radar(s),
• approach plots from approach radar(s),
• position reports and identification information from MLAT,
• position reports and identification information from ADS-B.
TargHITT delivers TargHITT tracks to TFP.
TFP receives:
• tracks from TargHITT,
• tracks from approach system,
• plans from flight plan system.
TFP uses these tracks for alerting and identification. TFP produces system tracks. These are tracks
with alert indications (where applicable). If a track is identified, the corresponding plan-id is
incorporated in the system track.
Targhitt acts differently in single or in multiple coverage areas:
Areas with single radar coverage

If TargHITT misses plots for a system track that is in the shadowing area, it will attempt to continue
the track. If TargHITT misses plots in a coverage area, it will terminate the track.
Areas with multiple coverage

If a target is detected in a multiple-covered area, then detections are expected from two or more
sensors. If only one sensor is detecting the target, the target is assumed to be a false target and will
be suppressed by TargHitt.
Tracking uses a number of maps, as shown in Figure 5. These maps are further described in the
following paragraphs.

semi-coverage
coverage
Semi-coverage
shadow
Nai area
Figure 7: Targhitt maps (example)

2.2.4.1 TargHITTint
TargHITTint uses a number of maps. Depending on the environment, some maps may be not-used.
Summary to Targhittint maps:
• blanking maps: areas in which plots are not processed in targhitt.
Blanking areas are used to suppress small plots (e.g. grass), thus requiring less regular
maintenance.
File: targhittint_blanking_areas_rad01.cgm
• non-automatic initiation maps: area in which plot will not be used by TargHITT for automatic
track initiation, meaning no new tracks are initiated inside this ‘nai’-area, but existing tracks are
maintained.
File: targhittint_nai_areas_rad01.cgm
The TargHITTint component contains input related functions:

• Conversion of HTP plots and Approach plots to one TargHITT plot type. To ensure that plots are
sent in the sector corresponding to their measured azimuth, plots can be buffered for a number of
sectors.
• Conversion of MLAT and ADS-B track messages to so-called surveillance reports.
• Conversion of Approach tracks to so-called transferred tracks. (not used)
• Selection of an active ‘sensor’ of a set of two or more redundant data streams. The selection is
based on the existence of data reception. If the active sensor does not send data (plots or tracks),
other sensors in the group can become active if still data is received for them.
• Guarding of the status of one sensor or a set of sensors. Provide a notification if the status
changes.
It also contains output related functions:

• Conversion from TargHITT track format to IFHITT system track format.
• Combining TargHITT track with additional input data related to the track. MLAT and ADS-B reports
can have information not useful for the tracker algorithm, but of any interest of some track data
client. This data (like, communication status) is stored in TargHITTint until the data is processed
and outputted by TargHITT.
• Filter output tracks dependent on the track classification
Online evaluation of the input status and the tracking process can best be done via the TargHITTint
evaluation functions.
2.2.4.1.1 Configuration file targhittint.ini

TargHITT is started with the file targhittint_ini.use, which is the generated file from targhittint.ini.
This file contains the references to the rest of the configuration files of targHITTint. It is recommended
not to change any of these files without consultation of HITT.
2.2.4.1.2 Blanking areas

Blanking areas can be used on system level and/or on radar sensor level. Currently the blanking areas
are used on radar sensor level only. Plots coming from the sensor will be suppressed in the defined
polygons.
An extra attribute called ECHO_THRESHOLD can be defined. In this case plots with an echo strength
smaller than the defined value will be suppressed.
In case of overlapping polygons the first defined polygon is leading. Example: If plots with echo
strength < 300 must be suppressed for the whole airport, and in a certain part of the airport plots with
echo strength < 1000 must be suppressed, the smaller polygon must be defined as first polygon in the
cgm file.
The cgm file consists of a polygon with the following APPLDATA statements
Syntax Description
APPLDATA AREA AREAID <nr> "<name>”; The blanking-area is identified with a number and
a logical name, For number convention see the
header of the cgm file below.

Syntax Description
APPLDATA AREA ATTRIBUTES " BLANKING " Identification type blanking area with optional a
[ECHO_THRESHOLD = <value>"]; value for the minimum echo strength.
Example of a blanking area:
BEGMF "HITT TDL Cgm::writeMap";

MFVERSION 1;
BEGPIC "testtarghittint_blanking_areas_sensor01";
SCALEMODE ABSTRACT, 1.0;
COLRMODE INDEXED;
BEGPICBODY;
%#### IDs of all areas in TargHITTint should be unique ####%
%#### System Blanking areas start with 1 ####%
%#### System Nai areas start with 50 ####%
%#### Sensor Blanking areas start with 101 for sensor 1 ####%
%#### etc ####%
%#### Sensor Nai areas start with 151 for sensor 1 ####%
%#### etc ####%
APPLDATA AREA AREAID 101 "General Threshold";
APPLDATA AREA ATTRIBUTES "BLANKING" "ECHO_THRESHOLD = 300";
LINECOLR 31;
LINEWIDTH 1;
LINETYPE 1;
INTSTYLE HOLLOW;
POLYGON
(-2759.4, -1334.27 )
(-2742.88, -4125.72 )
(-3666.42, -4013.12 )
(-3776.45, 789.654 )
(1857.55, 2850.56 )
(2928.79, 935.611 )
(790.811, -410.417 ) ;
ENDPIC;
ENDMF;
When this file is changed the process targHITTint must be restarted.
2.2.4.1.3 Non automatic initiation (NAI) areas

Non automatic initiation areas can be used on system level and/or on radar sensor level. Currently
these areas are not used at all. If plot is inside this area the plot will not be used by TargHITT for
automatic track initiation.
The cgm file consists of a polygon with the following APPLDATA statements
Syntax Description
APPLDATA AREA AREAID <nr> "<name>”; The nai-area is identified with a number and a
logical name, For number convention see the
header of the cgm file below.
APPLDATA AREA ATTRIBUTES " NAI "; Identification type blanking area with optional a
value for the minimum echo strength.
Example of a nai area:

MFVERSION 1;
BEGPIC "testtarghittint_nai_areas_sensor01";
COLRMODE INDEXED;
BEGPICBODY;
%#### IDs of all areas in TargHITTint should be unique ####%
%#### System Blanking areas start with 1 ####%
%#### System Nai areas start with 50 ####%

%#### etc ####%
%#### etc ####%
APPLDATA AREA AREAID 151 "Example NAI";
APPLDATA AREA ATTRIBUTES "NAI";
LINECOLR 31;
LINEWIDTH 1;
LINETYPE 1;
INTSTYLE HOLLOW;
POLYGON
(-2759.4, -1334.27 )
(-2742.88, -4125.72 )
(-3666.42, -4013.12 )
(-3776.45, 789.654 )
(1857.55, 2850.56 )
(2928.79, 935.611 )
(790.811, -410.417 ) ;
ENDPIC;
ENDMF;
When this file is changed the process targHITTint must be restarted.
2.2.4.2 TargHITT
TargHITT processes target reports received from one or more equally or different typed sensors and
executes the following main functions:
• Track continuation, by correlating incoming target reports to existing tracks.
• Track initiation, using multiple hypotheses tracking on not correlated target reports.
• Track dressing management, maintaining the track quality and classification.
• Environment assessment, maintaining area dependent clutter-, detection probability- and
systematic error estimations.
TargHITT maintains an accurate, continuous and up-to-date picture for all specified object categories.
TargHITT uses a number of maps. Depending on the environment, some maps may be not-used.
Summary of TargHITT maps:
• coverage maps: areas within which the sensor has actual coverage.
File: targhitt_coverage_areas_rad01.cgm
• semi-coverage maps: areas that do not have coverage (or that have poor coverage) and are
not of importance from a surveillance point-of-view, either because another sensor has good
coverage in that area or because the whole area is of non-interest. TargHITT uses the
difference of the coverage and the semi-coverage maps as the guaranteed coverage area.
For each area in the map a LAYER attribute may be specified:
LAYER=BOTTOM, meaning coverage areas have priority over this semi-coverage area
LAYER=TOP, meaning this semi-coverage area has priority over the coverage areas
By default LAYER=TOP is assumed.
File: targhitt_semi_coverage_areas_rad01.cgm
• shadowing maps: areas in which there may or may not be coverage, depending e.g. on the
size of the target, and where no other radar has good coverage. In these areas, tracks are
maintained as long as possible in order to bridge a coverage gap without loosing the track.
Examples of shadow area usage:
- bridge passages
- shielding of areas due to height differences on the airport
- shielding by buildings or trees
Note that larger objects may be detected while smaller objects are not detected.
Shadow areas are also used in areas where tracking is disabled (through the HTP
vptrack01.cgm), but tracks needs to be maintained/continued.
File: targhitt_shadow_areas_rad01.cgm
• RWY maps: areas containing the RWY-strips.
TargHITT uses special tracking attributes (e.g. for acceleration and for coupling with approach
track) for tracks inside these RWY areas. Although this file is optional, it is recommended to

provide this file.

File: targhitt_runway_areas.cgm
• APRON maps: areas indicating the APRONs.
TargHITT uses special tracking attributes, required for tracks close together inside these
APRON areas. (not used)
File: targhitt_apron_areas.cgm
Note: In a system with more than one sensor, it is important to define the SMR coverage maps for
TargHITT accurately, i.e. according to the true coverage of the individual SMR sensors. Meaning, a
coverage map for an individual SMR sensor shall never contain areas where no plots can be
expected. For example, if an object is detected by another sensor, TargHITT may classify this object
as false track, since there is a single detection in a ‘multiple’ coverage area.
These ‘uncertain’ areas should be covered at least by a semi-coverage area or a shadow area.
2.2.4.2.1 Configuration file targhitt.ini

TargHITT is started with the file targhitt_ini.use, which is the generated file from targhitt.ini.
This file contains the references to the rest of the configuration files of TargHITT. It is recommended
not to change any of these files without consultation of HITT.
2.2.4.2.2 Coverage map definitions

The different type of coverage maps in the cgm files must be identified with APPLDATA statements.
Every polygon must be identified with the following statement
APPLDATA AREA AREAID <nr> "<name>";
Note: <nr> must be unique.
The type of area must be identified with the following statement
APPLDATA AREA ATTRIBUTES <"COVERAGE"| "SEMI_COVERAGE"|"SHADOW">;
Example of a coverage cgm file:

MFVERSION 1;
BEGPIC "targhitt_coverage_areas_rad01.cgm"
COLRMODE INDEXED;
BEGPICBODY;
%--------------------------------------------------------------------%
% %
% PURPOSE : SMR coverage area for RADAR 1 %
% %
% %
% %
%--------------------------------------------------------------------%
APPLDATA AREA AREAID 1 "Coverage area";
APPLDATA AREA ATTRIBUTES "COVERAGE";
LINECOLR 9;
LINEWIDTH 1;
LINETYPE 1;
INTSTYLE HOLLOW;
POLYGON
(1803.6, 1675.79)
(1856.22, 1520.54)
(1861.02, 1498.21)
(1863.48, 1472.03)
(1805.3, 1779.19)
(1854.52, 1698.2);
ENDPIC;
ENDMF;
When these files are changed a configure for the targhittdata has to be performed (paragraph G_3:
Running configure) before TargHITT is restarted.
2.2.4.2.3 Runway Areas

This cgm file consists of one or more polygons (runway strips) with the following APPLDATA
statements:
Every polygon must be identified with the following statement
APPLDATA AREA AREAID <nr> "<name>";
Note: <nr> must be unique.
The type of area and the runway orientation must be identified with the following statement
APPLDATA AREA ATTRIBUTES "RUNWAY" <orientation>;
Note: the orientation of the runway is specified in degrees.
Example of the runway areas file (one runway defined only)

MFVERSION 1;
BEGPIC "targhitt_runway_areas";
COLRMODE INDEXED;
BEGPICBODY;
% --------------------------------------------------------------%
% Runway NO. 1 21L/03R orientation 210 %
% --------------------------------------------------------------%
APPLDATA AREA AREAID 1 "21L/03R";
APPLDATA AREA ATTRIBUTES "RUNWAY" 210;
LINECOLR 17;
LINEWIDTH 1;
INTSTYLE HOLLOW;
POLYGON
(-2577.04, -44.2265 )
(1188.65, 1346.21 )
(1205.23, 1287.83 )
(-2542.96, -104.877 );
ENDPIC;
ENDMF;
When this file is changed a configure for the targhittdata has to be performed (paragraph G_3:
Running configure) before TargHITT is restarted.
2.2.4.3 TFP
TFP consist of the following sub-processes:
• Multi Sensor Fusion (msf)
• Identification (idt)
• Alerting (alr)
• Area Penetration Monitoring (in function alr)
• Runway Incursion Monitoring (rim)
• Taxiway Collision Monitoring (tcm)
These processes use parameter-files (maps and ini-files), which are used by TFP (and its sub
processes):
• Maps (located in mapdata):
• MSF:
• (none)
• Identification:
• idtareas.cgm (contains the “identification” (IDT) area)
• alerting:
• alrareas.cgm (contains areas and lines used by the “Area Penetration
Monitoring” (APM), "Stop bar violation monitoring" (SVM),
"SID/RWY-monitoring" (SRM) and SICO.
• rimareas.cgm (contains area’s used by “runway incursion monitoring"
(RIM) for normal visibility)
• rimlvpareas.cgm (contains area’s used by RIM for low visibility
• tcmtopology.cgm (contains area defined for “taxiway collision monitoring

(TCM)”)
• ini files (located in tfpdata):
• MSF:
• msf_targhitt.ini (settings for “MSF”)
• tfp.ini (settings for “TFP”)
• Identification:
• idt.ini (settings for “IDT”)
• alerting:
• alr.ini (settings for the “ALR” function)
• rim.ini (settings for the “RIM” function)
• tcm.ini (settings for the “TCM” function)
• rulelists.xml (settings for enabling/disabling RIM sub functions)
When one of the system parameter files has been modified, the script “configure” in the tfpdata
directory has to be executed and the TFP has to be restarted to effectuate these files.
The maps and the ini files are described in the following paragraphs.
2.2.4.3.1 Multi Sensor Fusion (MSF)

Maintenance on the msf_targhitt.ini and tfp.ini is not needed and therefore not further
described.
2.2.4.3.2 Identification (IDT)

Flight plans can be received from external flight plan systems. They are received by PLAMAS, which
sends them to TFP. TFP attempts to match the identification code (SSR code, modeS address or
transponder ID) in the plan with the code that is actually transmitted by the aircraft or the vehicle. If
they match, the plan ID is coupled to the system track. This is called automatic identification.
TFP sends plans to TRADIS, where they are presented. A controller can also manually attach a plan
to an unidentified track. TFP maintains this identification.
The main function of the file idt.ini is management of flight plans. The moment of deletion of plans
(based on estimated times or actual times) can be specified here.
The file idtareas.cgm specifies IDT areas. If a track is lost inside an IDT area, the track
identification is placed in the Coast List of TRADIS. An identification in the Coast List can be used by
the Controller to manually re-identify a track when it reappears again after being lost.
2.2.4.3.3 Alerting (ALR)

Is described in par. 2.2.8.

2.2.5 Traffic Presentation
2.2.5.1 Traffic Display (TRADIS)

TRADIS is the graphical user interface to view and handle the traffic (video, tracks and plans).
TRADIS is highly configurable:
• Configuration settings are stored in tradis/xml and in tradisdata/xml, where the files
in tradis/xml should not be modified.
• Display-specific maps are stored in tradisdata/maps. These maps are used for
presentation purposes only.
• The free map (which can be edited by the Controller) is stored in tradisdata/usrmaps.
For the maintenance functions of TRADIS, refer to chapter 10.
2.2.5.2 Traffic Monitor (TRAMON)

TRAMON manages and distributes runway/taxiway segment status and monitors traffic for adherence
to runway/taxiway segment related restriction.
TRAMON is initialized by the tramon.xml file.
2.2.5.3 HydroMeteo (HYMESET)

HYMESET maintains the visibility settings. It can be controlled from a TRADIS application on the
operational working position(s). Parameters in the runway incursion function and Taxiway Collision
Monitoring depend on the actual visibility.
HYMSESET is initialized by the hyme.ini file.

2.2.6 Maintenance functions
2.2.6.1 Control and Monitoring (CMS)
2.2.6.1.1 CMS Overview

CMS consists of a redundant central CMS application (CMSSERVER), one or more CMS-GUIs, and
on every node a CMS client.
CMS:
• collects status information from the system, including its sensors, computers, network
equipment, printers and software applications
• provides the status (using colors to provide a severity indication)
• provides facilities to start and stop sensors, computers and software and to access sensor
settings.
The functionality of CMS is described in chapter 11.
Figure 8 shows the overview of the CMS system and depicts the major parts:
- On each node that needs to be controlled and monitored, a CMSCLIENT is installed, which:
- passes control commands from the CMS to JCL (e.g. to stop or start applications)
- monitors the applications (using SNMP),
- receives messages (traps) from REPMAN.
- A CMSSERVER is connected to the CMSCLIENTs.
- One or more CMS-GUIs can connect (via a webbrowser) to the CMSSERVER.
The CMSCLIENTs and the CMSSERVER are configurable via initialization files. For location of files,
refer to 2.3.4.2.
Note that, when the connection between the CMSCLIENT and CMSSERVER is lost, the CMSCLIENT
stores the reports, and when reconnected, these stored reports are sent to the CMSSERVER.
The node where the CMSSERVER is running, and the node(s) where the CMS-GUI(s) is(are) running
can be different from project to project.

Figure 8: Overview of the CMS system
2.2.6.1.2 Local Control and Monitoring

On each node, control and monitoring facilities are provided. These are the programs Job Control
(JCL) and Report Manager (REPMAN).
Job Control (JCL)

JCL is used to start and stop applications in a specified environment with specified configuration file.
JCL performs a number of tasks:
• checks whether applications are running, and if not, JCL restarts the application.
• performs a controlled start of the applications.
• performs a controlled stop of the applications.

During node startup JCL reads a node-specific file (node configuration file (refer to Figure 8), e.g.
dp_ncf on a DP), which specifies the applications that must be started and the sequence of starting
these applications.
Furthermore, when stopping a node, also the sequence of stopping the applications is specified in this
file.
Report Manager (REPMAN)

Reporting is depicted on a high level in Figure 8. Each software process uses events to output
messages for maintenance. These messages are sent to REPMAN. REPMAN collects these reports
and stores them in the node-report-file (log/<nodetype>.rep).
When a *.rep exceeds a defined maximum file size (defined in repmandata/repman.ini), the file
is moved to *.rip and a new *.rep file is created.
REPMAN sends messages (traps) to the local CMS-client, which in turn reports to the CMS-server. In
CMS, the messages are shown in the ‘Received events’-area. REPMAN uses a filter file
(repmandata/use/repman.msg) to determine which message it sends to the CMS-client (look for
‘true or ‘’false’) and to convert the mnemonic into a full text message. Figure 8 shows these message
flows. Here is where the high level description ends; for more detail, refer to Figure 9.
Report messages have the following standard format:

<host-name> <process-name> <time> <message-mnemonic> <arguments>
For example:
ctp01 tfp 2002/09/03 01:11:38.706 UTC I_MSF_SENSORGROUP_ONLINE 1
A message mnemonic starts with a severity indicator:

• I_: Informational, which means no operational impact
• W_:Warning, which means that the application may show abnormal behavior in the near future
• E_: Error, which means that the application will not function normally
• F_: Fatal, which means that the application will terminate
The message-mnemonic and its arguments are translated into a full text message using the file
repmandata/mnemonics_<application>.txt, where each entry has the following format:
<message-mnemonic > <TRUE|FALSE> <id> <text within quotes>
An example of such an entry in the repman.msg file to translate a report into a text message is:
I_MSF_SENSORGROUP_ONLINE TRUE 1200020 "I_MSF Sensor Group $1 online"
Where the first item is the message-mnemonic, the TRUE/FALSE flag indicates if the report needs to
be sent to CMS. The number indicates a unique (internal) number and the text between quotes is the
text as it will appear on the CMS report window.
Detailed description of application reports

Since CMS shows in the ‘Received events’ area messages with ‘stdout’ and ‘stderr’, the application
reporting is described here in more detail. Refer to Figure 9.
HITT-applications produce 3 types of output:

• standard output (stdout)
• standard error (stderr)
• reports that are generated by the HITT middleware called ‘Tell’
The stdout and stderr of each application are collected by JCL and JCL redirects this to REPMAN.
Note that, normally the applications should not create stdout or stderr messages, but only for
debugging purposes stdout/stderr can be used.
The Tell-reports of each application are stored per application in an <application-name>.rep file and
are also send to REPMAN.

REPMAN collects the Tell-reports plus the redirected stdout/stderr and stores this in the <node>.rep
file, and (depending on the contents of file repman.msg) sends traps to CMSCLIENT.
And to be complete, JCL:
• collects its stdout and stderr (produced by JCL itself) into the log/<node>.log file
• collects its Tell report (produced by JCL itself) into the log/jcl.rep file.
Note that this <node>.log and jcl.rep file contain less important data.
Figure 9: Overview of applications reports
2.2.6.2 Radar Control and Monitoring (RACOMS)

In the RACOMS-GUI the status of an SMR can be monitored and some functions of the SMR can be
controlled.
The radar control application RACOMS provides the remote radar control facility. It has a Graphical
User Interface (RACOMS-GUI) to make it easier to set the parameters of the radar. The RACOMS -
GUI interfaces with the TERMA SMR.
RACOMS is the CMS RACOMS proxy program on the RDP’s using the SNMP protocol and is
necessary because the radar itself is not SNMP manageable.

RDP CMS-node
Radar RACOMS RACOMS-GUI
SNMP
Figure 10: Remote radar control facility
For the maintenance functions of RACOMS, refer to chapter 12.
2.2.6.3 Video Extractor Scope (VES)

VES is used for tuning purposes of the HTP-application. Refer to chapter 15.

2.2.7 Supplementary functions
2.2.7.1 Recording and Replay (LOGIT)

System messages and operator commands are continuously recorded, also when running a replay.
The (LOGIT) recorder and replayer are separate applications. Recording is done for both operational
and technical replay, which means that the same recording files are used for both operational and
technical replay.
Recording files are stored on disk(s) in the RRP.
The following directories under /logdisks are relevant for recording and replay:
Directory Use
archive Contains information about the archiving sessions that has been
carried out.
recordings/oper/<date> The <date> directories contain the recording files of that day,
produced when the system was in operational mode.
recordings/techreplay/<date> The <date> directories contain the recording files of that day that
are used for technical replay.
restored/oper/<date> The <date> directories contain recording files that are restored
from archive. They are used for replay when the RRP is in
operational mode.
restored/techreplay/<date> The <date> directories contain recording files that are restored
from archive. They are used for replay when the RRP is in
technical replay mode.
Table 2: LOGIT Directories
Data is written in one-minute blocks, which makes them easy to address and select. The recorder
monitors the amount of free disk space. It will automatically delete the oldest recording files when the
amount of free disk space is below a specific minimum.
The minute files at least contain the following which are synchronously stored:
• SMR radar video;
• HTP plots;
• Approach plots,
• System tracks;
• Flight Plans;
• Operator actions;
• Identification commands;
• Alarms;
• Runway configuration;
• Analogue audio;
• Visibility.
The file names and directories are all based on UTC, a <date> directory from Table 2 would for
example be /20090505, where 2009 is the year, 05 the month and 05 the day.
When the replayer is run in operational mode, it replays data from an oper directory to operational
replay channels. When TRADIS is running in replay mode it connects to these channels.
When the replayer is run in technical replay mode, it replays data from a techreplay directory to
technical replay channels. Other nodes that are in technical replay mode connect to these channels.
Therefore multiple nodes are required for a technical replay session; see ‘G_8: Setting up a technical
replay session’.
Replay is attempted from the recordings directory. If it does not find the required recordings there,
it attempts to read them from the restored directory.

For the maintenance functions of the LOGIT, refer to chapter 13.
2.2.7.2 Archiving data (ARCHIT)

The information, that is continuously recorded on a hard disk by the LOGIT application, is periodically
copied to tape (automatically) by the ARCHIT application.
For this process, the system requires that the maintenance engineer replaces the tape periodically
(e.g. per week).
The number of tapes is determined by the period of time the operational end user requires that data
must be available on tapes.
Practically speaking, the maintenance engineer uses a set of tapes (like on a carrousel; tape1, tape2,
tape3, etc.) and periodically replaces the automatically ejected tape in the tape drive with the next tape
on the carrousel. After having used each tape, the oldest tape is reused again.
For the maintenance functions of the ARCHIT, refer to chapter 14.
2.2.7.3 Statistical Information Collector (SICO)

SICO receives System Tracks, Alerts and Plans. SICO records lines that are crossed, a subset of
alarms and updates of plan items. These events are written as separate lines into SICO-files. These
are ASCII-files (named YYYYMMDDhhmm with file extension xls or csv). SICO-files are written to the
directory /HITT/user/ESB/statisticdata.
A new SICO-file is created every hour. If more than a system parameter (SP_MaxFiles in
sicodata/rrpsico.ini) number of SICO-files exist, the oldest SICO-files are automatically
deleted.
Each line in a SICO-file contains a number of fields, separated by a delimiter (for example the ‘;’
symbol). The first line of such a file always lists the field names, separated by the same delimiter. The
resulting file can be easily imported into a spreadsheet or database application. The following file-
fragment gives an impression of such a statistics-file.
EventTime;EventName;EventType;Callsign
2005-01-26 08:15:23;"SB_15";"LineDown";"SAS1579"
2005-01-26 08:15:38;"D-A";"LineUp";
2005-01-26 08:15:57;"SB_27";"LineUp";"CIM126"
2005-01-26 08:15:58;"SB_3";"LineUp";"SAS207"
2005-01-26 08:16:01;"A12/30";"LineUp";"CIM126"
The fields and the events that are being recorded are defined in the file sicodata/gensico.ini
and the lines causing line crossing events are defined in the map alrareas.cgm.
The procedure ‘A_60: Maintain SICO’ describes how to control what is actually recorded.

2.2.8 Alerting Function: Runway Incursion Monitoring (RIM)

The system contains a number of alerting functions. The functionality of these alerting functions is
described in the operational manual [OM.TRADIS]. The possibility for the maintenance engineer to
adapt the alerting functions is described in the adaptive maintenance procedures (refer to 7.4 Alert
settings).
Since one of the alerting functions, meaning the RIM-alert, is the result of a complex process that
validates for various cases (approach conflict, runway conflict, crossing runway conflict, dependent
parallel runways), the details of the RIM-alert function and their parameters are described here in more
detail.
Runway Incursion Monitoring (RIM) is in fact a group of runway alerting function that produces alerts
for:
- RIM single track conflicts
• CA (Closed runway Approach),
• CD (Closed runway Departure),
• RD (Runway Direction conflict),
• OR (Object on Runway),
• AR (Assigned Runway mismatch),
• DA (Departure Aborted)
- RIM multiple track conflicts
• RW (RunWay incursion).
The subsequent paragraphs describe the cases for RIM single track conflicts and RIM multiple track
conflicts (RIM-RW) and their parameters. These parameters are defined in tfpdata/rim.ini. They
can be modified in order to change the behaviour of RIM. Note that there are separate parameters for:
• Alerts and pre-alerts and
• Normal and low visibility conditions.
This is described in the procedure section (see 7.4.3).
RIM Maps and Areas

For each runway, RIM uses an approach area, a runway area, a threshold and a line-up area. RIM will
investigate conflicts if a track is in an approach or a runway area, depending on the type of conflict.
The areas and thresholds for the runways are defined in a RIM -map. There are two separate RIM
maps: for normal and low visibility conditions.
Track Classification
RIM uses a number of track classifications to determine the intention of the track, allowing to detect
conflict situations.
From state To state Definition

outside approaching track is airborne and inside approach of used runway*
outside landing track is inside runway area
approaching landing track is inside runway area
approaching outside track is not in approach an is not on the runway and is
not in departure area and is airborne
landing landed track is on runway and speed is below
SP_MinimumLandingSpeed
landing outside track is not in approach an is not on the runway and is
not in departure area and is airborne
landed taxiing track not inside the runway area and is not airborne
and speed is below SP_MinimumAirborneSpeed
landed departed track is airborne or speed is above
SP_MinimumDepartedSpeed or
track is not on runway and speed is above
SP_MaximumTaxiingSpeed

From state To state Definition

taxiing line-up track is inside runway area, speed is below
SP_MaximumLineUpSpeed and track is not detected
as ‘vehicle’ by a collaborative sensor
taxiing departing track is inside runway area, speed is above
SP_MaximumTaxiingSpeed and track is not detected
taxiing outside track is not in approach an is not on the runway and is
airborne
line-up rolling track is inside runway area and speed is above
SP_MaximumLineUpSpeed
line-up taxiing track is not in the runway
rolling departing track is inside runway area and speed is above
SP_MaximumRollingSpeed
rolling taxiing track is outside runway area or rolling more than
SP_MaximumRollingScans
rolling line-up track is inside runway area, speed is below
departing taxiing track not inside the runway area and is not airborne
and speed is below SP_MinimumAirborneSpeed
departing departed track is airborne or speed is above
SP_MinimumDepartedSpeed
departing line-up track is inside runway area, speed is below
departed outside track is not in approach an is not on the runway and is
not in departure area
Table 3: Track classification
2.2.8.1 RIM Single track conflicts

Below a list is given when single track conflicts are generated.
1. If runwayUsage(T) = closed and classification(T) in {approaching,landing} ⇒ approach on closed

runway alert (RIM-CA).
2. If runwayUsage(T) = closed and classification(T) in {departing,departed} ⇒ departure from closed
runway alert (RIM-CD).
3. If identified(T) and hasAssignedRunway(T) and assignedRunway(T) ≠ usedRunway(T) and
classification(T) in {approaching,landing} ⇒ runway assignment alert (RIM-AR).
4. If classification(T) in {line-up,rolling,taxiing,landed} and previousClassification(T) in
{departing,departed} and classificationJustChanged(T) ⇒ departure aborted alert (RIM-DA).
5. If static(T) and track not in lineup area ⇒ static object on runway alert (RIM-OR).
6. If classification(T) in {line-up,rolling,taxiing,landed} and runwayAlligned(T,R) and runwayUsage(R)
= NotInUse ⇒ track uses runway in wrong direction alert (RIM-RD).
7. If classification(T) in {approaching,landing} and runwayAlligned(T,R) and runwayUsage(R) in
{NotInUse,Departing} ⇒ track uses runway in wrong direction alert (RIM-RD).
8. If classification(T) in {departing,departed} and runwayAlligned(T,R) and runwayUsage(R) in
{NotInUse,Landing} ⇒ track uses runway in wrong direction alert (RIM-RD).
9. if timeOnRunway(T) > SP_MaximumOnRunwayAge ⇒ track too long on runway alert (not used)
runwayUsage(T) : Runway mode

classification(T) : Classification of target as defined in Table 3: Track classification
runwayAlligned(T,R) : Track is aligned in runway direction R
2.2.8.2 RIM Approach conflicts

This case is checked for every single runway (so including the runways that are involved in crossing
and parallel runways). An approach alert is generated if there is a track on the runway (runway track,

T1) and another track is approaching (approach track, T2) and (see Figure 11) if the following
conditions are all true:
• T1 is closer to the threshold than SP_MinimumThresholdDistRwyTrack meters (D1).

• T2 is closer to the runway than SP_MinimumThresholdDistance meters (D2).
• The heading of T2 deviates no more than SP_ApproachHeadingDeviation degrees from
the runway.
• T1 is moving slower than SP_MinimumRwySpeedApproachConflict.
Figure 11: RIM-RW approach conflict

The parameters that are used in these conditions are described in more detail in the following table.
Parameter Description
SP_MinimumThresholdDistRwyTrack The distance between the runway track and the threshold
of the approach runway. If this parameter is greater than
the runway length, RIM reacts to all tracks on the runway.
If this parameter is smaller than the runway length, RIM
will not react if the runway track is at the far end of the
runway.
SP_MinimumThresholdDistance The distance between the approach track and the
threshold of the runway. With this parameter you can
specify the distance at which RIM reacts to an approach
conflict.
SP_ApproachHeadingDeviation If the heading of the approach track deviates more from
the runway than this parameter, RIM will not react. This
parameter is used to separate tracks passing the
approach area from actually approaching tracks.
SP_MinimumSpeedCheckAlignment If the speed of the runway track is below this parameter, it
is seen as a static object. This means that the track’s
heading is not taken into account if it is moving slower
than this parameter.
SP_MinimumRwySpeedApproachConflict If the speed of the runway track is greater than this
parameter, it is seen as a departing track and RIM will not
react to it.
Table 4: RIM-RW Approach Parameters
2.2.8.3 RIM Runway conflicts

A runway conflict is investigated if there are two tracks on the runway. RIM checks for the following 2
situations:
• tracks move toward each other,
• tracks move in the same direction.

These situations are checked for every single runway (so including the runways that are involved in
crossing and parallel runways). The system parameters that are used in the following situations are
described in Table 5.
Tracks moving toward each other

A runway alert is generated for two tracks (T1 and T2, see Figure 12) if the following conditions are all
true:
• The speed of T1 or T2 is greater than SP_MinimumSpeedRunwayIncursion
• The heading of at least T1 or T2 deviates no more than SP_RunwayHeadingDeviation
degrees from the runway.
• The distance (D) between T1 and T2 is smaller than SP_MinimumRunwayDistance
Figure 12: RIM-RW Runway conflict, tracks moving toward each other
Tracks in the same direction

A runway alert is generated for two tracks (T1 and T2, see Figure 13) if they move in the same
direction and if the following conditions are all true:
• The speed of T1 or T2 is greater than SP_MinimumSpeedRunwayIncursion
• T1 approaches T2 with a speed difference greater than
SP_MaximumRunwaySpeedDifference
• The heading of at least T1 or T2 deviates no more than SP_RunwayHeadingDeviation
degrees from the runway.
• The distance (D) between T1 and T2 is smaller than SP_MinimumRunwayDistance
Figure 13: RIM-RW Runway conflict, tracks moving in the same direction
The parameters that are used in these conditions are described in more detail in the following table:
SP_MinimumSpeedRunwayIncursion The minimum speed for the departure track. If the
departing track (T1) is moving slower than this value, RIM
will not generate an alert.
SP_MaximumRunwaySpeedDifference The maximum allowed speed difference between the two
tracks. This parameter can be considered as a safety
distance in speed.
SP_RunwayHeadingDeviation If the heading of the track deviates more from the runway
than this parameter, RIM will not react. This parameter is
used to prevent tracks (vehicles) crossing the runway
area.
SP_MinimumRunwayDistance The safety distance between runway tracks. If this
parameter is smaller than the runway length, RIM will not
react if the runway track T2 is at the far end of the
runway.RIM will react to all tracks on the runway if this
parameter is set to a value greater than the runway length.
Table 5: RIM-RW Runway Parameters

2.2.8.4 RIM Crossing Runways conflict (optional)

RIM will investigate crossing runway conflicts. Consider 2 crossing runways, R1 and R2. One track
(T1) is using R1 and another track (T2) is using R2, as shown in the following figure.
Figure 14: RIM-RW crossing runways
Both R1 and R2 can be used for arrivals and departures. RIM will consider the following basic
situations to check for crossing runway conflicts:
• R1 is used for departures
• R1 is used for arrivals
R1 is used for departures

If R1 is used for departures, RIM will generate a crossing runway alert if the following conditions are all
true:
• D1 is smaller than SP_DepartureCrossDistanceAlert
• And one of the following situations is valid:
• If T2 is on the ground (i.e. it has the classification Taxiing, Rolling, Landed or in
Lineup): D2 is smaller than SP_DepRwyNearCrossDistance
• If T2 is in the air (soon) (i.e. has the classification Departing, Departed, Landing or
Approaching: D2 is smaller than SP_DepAirNearCrossDistance
R1 is used for arrivals

If R1 is used for arrivals, RIM will generate a crossing runway alert if the following conditions are all
true:
• D1 is smaller than SP_ApproachCrossDistanceAlert
• One of the following situations is valid:
• If T2 is on the ground (i.e. it has the classification Taxiing, Rolling, Landed or in Line-
up): D2 is smaller than SP_AppRwyNearCrossDistance
• If T2 is in the air (soon) (i.e. has the classification Departing, Departed, Landing or
Approaching: D2 is smaller than SP_AppAirNearCrossDistance

SP_DepartureCrossDistanceAlert This parameter defines the safety distance to the runway
crossing for a departure track.
SP_DepRwyNearCrossDistance This parameter defines the safety distance between a
track on the ground (i.e. Taxiing, Rolling or Line-up) and
the runway crossing if another aircraft is departing on the
crossing runway.
SP_DepAirNearCrossDistance This parameter defines the safety distance between a
track in the air (i.e. Departing, Landing or Approaching)
and the runway crossing if another aircraft is departing on
the crossing runway.
SP_ApproachCrossDistanceAlert This parameter defines the safety distance to the runway
crossing for an approach track.
SP_AppRwyNearCrossDistance This parameter defines the safety distance between a
track on the ground (i.e. Taxiing, Rolling or Line-up) and
the runway crossing if another aircraft is approaching on
the crossing runway.
SP_AppAirNearCrossDistance This parameter defines the safety distance between a
track in the air (i.e. Departing, Landing or Approaching)
and the runway crossing if another aircraft is approaching
on the crossing runway.
Table 6: RIM-RW Crossing Runway Parameters
2.2.8.5 RIM Dependent Parallel Runways (optional)

RIM will investigate parallel runway conflicts for dependent runways. Table 8 lists parallel runway
dependencies. The combinations that are mentioned in this table are used by RIM to detect parallel
runway conflicts. RIM detects conflicts for runways that are used in parallel and opposite directions, as
depicted in Figure 15 and Figure 16.
RIM will generate an alert if the distance between tracks on the parallel runways becomes smaller than
a system parameter. The parameter is coupled to the use of the runways (approach or departure) and
their direction (parallel or opposite). These situations are described in the following two subsections.
Runways used in parallel direction

The following combinations are checked when the dependent runways are used in parallel directions.
Figure 15 shows depicts this situation.
• DEP/DEP (both are departure): a RIM alert is generated when the distance (D) between the
tracks is smaller than SP_DepDepInFront meters.
• APP/APP (both are approach): a RIM alert is generated when the distance (D) between the
tracks is smaller than SP_AppAppInFront meters.
• APP/DEP (the approach track moves toward a departure track): a RIM alert is generated when
the distance (D) between the tracks is smaller than SP_AppDepInFront meters.
• DEP/APP (the departure track moves towards an approach track): a RIM alert is generated
when the distance (D) between the tracks is smaller than SP_DepAppInFront meters.

Figure 15: RIM-RW parallel runway usage
Runways used in opposite direction

The following combinations are checked when the dependent runways are used in opposite directions.
Figure 16 depicts this situation.
• DEP/DEP (both are departure): a RIM alert is generated when the distance (D) between the
tracks is smaller than SP_OppDepDepInFront meters.
• APP/APP (both are approach): a RIM alert is generated when the distance (D) between the
tracks is smaller than SP_OppAppAppInFront meters.
• APP/DEP and DEP/APP: a RIM alert is generated when the distance (D) between the tracks is
smaller than SP_OppAppDepInFront or smaller than SP_OppDepAppInFront meters.
The difference between these parameters is not relevant in this situation, so they typically
have the same value.
Figure 16: RIM-RW opposite runway usage
SP_DepDepInFront This parameter defines the safety distance between two
tracks that are departing from runways in parallel use.
SP_AppAppInFront This parameter defines the safety distance between two
tracks that are approaching runways in parallel use.
SP_AppDepInFront This parameter defines the safety distance between an
approach and a departure track on runways in parallel
use.
SP_DepAppInFront This parameter defines the safety distance between a
departure and an approach track on runways in parallel
use.
SP_OppDepDepInFront This parameter defines the safety distance between two
tracks that are departing from runways in opposite use.
SP_OppAppAppInFront This parameter defines the safety distance between two
tracks that are approaching runways in opposite use.
SP_OppAppDepInFront This parameter defines the safety distance between an
approach and a departure track on runways in opposite
use.
SP_OppDepAppInFront This parameter defines the safety distance between a
departure and an approach track on runways in opposite
use.
Table 7: RIM-RW Parallel Dependent Runway Parameters

The runway dependencies are listed in the following table. RIM only checks for parallel runway
conflicts in these situations.
Parameter Track Classification * Track Classification

04L/04R (Parallel) 04L: Departing or Departed 04R: Approaching, Landing,
Departing or Departed
04L/04R (Parallel) 22L: Departing or Departed 22R: Approaching, Landing,
04L/22L (Opposite) 04L: Departing or Departed 22L: Approaching, Landing,
04L: Approaching, Landing 22L: Departing or Departed

04R/22R (Opposite) 04R: Departing or Departed 22R: Approaching or Landing
04R: Approaching, Landing 22R: Departing or Departed

* Classifications are defined in Table 3.
Table 8: RIM-RW Parallel Dependencies

2.3 System description

The technical realisation (the architecture) of the system is described here.
2.3.1 Operating system

The system is based on the Linux operating system.
For the version information refer to the [VDD].
2.3.2 System Applications
2.3.2.1 Application Startup and Shutdown

Applications on a node are monitored and controlled by Job Control (JCL). For more details, refer to
2.2.6.1 Control and Monitoring (CMS).
2.3.2.2 Application Reports

Application messages are sent to REPMAN. For more details, refer to 2.2.6.1 Control and Monitoring
(CMS).
2.3.2.3 Application Initialization

Most applications read configuration files when they are started. Such an 'ini-file' is specific for each
application.
Ini-files are text-based application-configuration-files. They can be in plain text format (with the
extension ‘*.ini’) or in XML-format. These ini-files can be edited with a plain text editor. Some
application characteristics can be tailored by changing ini-files.
Note that application parameters can also be stored as parameters in maps.
Ini-files are intended to be valid for all applications of the same type. This implies that ini-files often
contain variables that must be initialized. This initialization is carried out by the configure script.
2.3.2.4 Application Communication

The communication between applications (TARGHITT, TFP, etc) is done by HITT’s basic component
COMMS. Simular to the initialisation of applications by ini-files, also the COMMS for each application
is initialized by ini-files.
COMMS uses Messages and Handlers (at the application side) and Channels (at the network side).
COMMS can handle TCP Point-to-point and IP Multicast messages.
COMMS can also be used during fault finding to check if channels are ‘connected’ or ‘not connected’
(refer to 4.2.3.1) and if messages are exchanged between applications.
2.3.2.5 Application Configuration

Applications as well as the communication layers (COMMS) of the applications need to be configured
which is done by the configure script. The configure script converts the ini-files into use-files. Figure 17
shows as an example the initialization of the TFP-application and its COMMS-layer. Initialization is
done when starting an application.
When starting the TFP-application, the use-files are relevant (ini-files are not used then). At start-up,
both the TFP-application and the COMMS-layer are initialized by reading a use-file. In Figure 17 there
are a number of use-files (some for the operational mode, and some for the technical replay mode).
Which use-file is read, depends on the mode in which the node is running (see 2.3.7).
Figure 17 illustrates a node in operational mode; hence the *_oper.use files are read (and for that
reason the *techreplay.use files are greyed-out).

Figure 17: Initialization and configuration (example of the TFP-application)
Node configure
When configuring a node, the node configure-script is executed as user root.
The node configure-script first stops the applications on the node.
Then it checks for possible changes in the /auto/changes/patches directory and lets the user
decide if the changes must be made active or not.
After that, it configures application files and system files and converts the ini-file into a number of so
called use-files; for each mode of a node, one use-file is created. Note that use-files are in fact ini-files
in which all variables have been initialized. This is why you must never modify a use-file, since
changes will be overwritten by the configure script.
Finaly the node configure script restarts the applications on the node.
See G_3.1: Node configure.
Hittsys configure
When only a (small) change has been performed and not all applications on the node need to be
configured (and it is not desirable that applications are stopped and started), then the configure can be
run as user hittsys (in stead of user root). This will not stop the applications and only the application
files (located in /hittsys) are configured (the system files like /etc/hosts, /etc/services, etc. will not be
configured). After the configure, only the applicable application(s) must be stopped and restarted
manually using CMS or by killing and restarting the applications(s).
See G_3.2: Hittsys configure.
2.3.2.6 Application Directories

Applications and their configurations are stored in 2 separate directories: an application directory and a
data directory. The application directory is typically named like /hittsys/<applname> (e.g.
/hittsys/tfp). The data directory is typically named like /hittsys/<applname>data (for
example /hittsys/tfpdata). Use-files are stored under the ’use’ directory in the data directory.
2.3.2.7 Maps
Maps are written in CGM (Computer Graphics Metafile, see Appendix: CGM Description) which is a
textual representation of graphical objects.
Maps can be edited with the TRADIS map-editor (see Appendix: Traffic Display (TRADIS)). TRADIS
settings specify which maps may be edited by which user. Editing certain maps may be disabled by
omitting them from the Edit Maps dialogue in TRADIS. The procedure A_36: Make a map editable
describes how you can modify these settings.
Application data (APPLDATA) can be added to map-objects, see A_10: Maintain application
parameters in maps. This APPLDATA is described where relevant.

X/Y Positions in maps are expressed in meters, with respect to the System Centre, which is the Airfield
Reference Point (ARP).
Maps are divided into the following categories:

• SMR Maps: Maps that are used by the SMR radar to enable/disable presentation of video
and/or tracks. These maps are technically used by the RDP and CTP processor.
These maps are located in the directory: /hittsys/maskdata.
These maps are available on TRADIS in the SMR MAPS-tab of the Map selection option.
• Mosaic Maps: Maps that are used by TRADIS to display the correct video mosaic.
These maps are located in the directory: /hittsys/mosdata.
These maps are available on TRADIS in the SMR MAPS-tab of the Map selection option.
• Technical Maps: Maps that are used by the central (tracking and alerting) functionality
running on the CTP node, for example the coverage of approach radar.
These maps are located in the directory: /hittsys/mapdata.
These maps are available on TRADIS in the TECHNICAL-tab of the Map selection option.
• ILS Critical Maps: Contain maps that are used for presentation purposes only on the
TRADIS display. During critical use of the ILS (in low visibility (Cat III) mode), these areas
must be free of any traffic. Note that since ILS is located in the non-movement area
(grass), no tracking is performed and hence APM-alerting is not possible)
These maps are located in the directory: /hittsys/tradisdata/maps.
These maps are available on TRADIS in the ILS MAPS-tab of the Map selection option.
• Airport Maps: Airport maps that are used for presentation purposes on the TRADIS
display only.
These maps are located in the directory /hittsys/tradisdata/maps.
These maps are available on TRADIS in the AIRPORT tab of the Map selection option.
• Emergency Map: A map that contains the emergency crash map.
This map is located in the directory: /hittsys/mapdata.
• Local Free Map: A map that can be used to draw items for personal/local use.
This map is located in the directory: /hittsys/tradisdata/usrmaps.

2.3.2.8 Overview of configuration files and maps
The following table gives an overview of the most important configuration files in the system.
The following configuration items can be distinguished:
• data files (.ini, .com, .xml), on the left side in the table
• geographical maps (.cgm), on the right side in the table
For each configuration item, the table indicates:

• the directory,
• the file name,
• a reference to a description and/or a procedure to change the item,
• the application (CI) that uses the configuration item,
• the node(s) that must be configured after modification of the configuration item,
• for maps: the name used in TRADIS dialogues (to select, deselect or edit the maps),
• for maps: the name of the category in which maps are categorized in TRADIS.
Note that there are numerous maps that are used for ‘display purposes only’ and do not configure the
system (having no technical impact on the functional behaviour of the system).
For completeness, these maps are mentioned in this list, and are marked in a grey-background.

Node CI Dir Data files Ref. Dir Geographical maps Ref. Name on TRADIS
RDP HTP htpdata x_sp_1_htpini0x.com 2.2.2, (General description) 2.2.2
htpdata x_sp_1_minoff.com 9.3 maskdata vpgrass0x.cgm 7.1 SMR Maps - GRASS0x
htpdata x_sp_1_thfmin.com maskdata vpmask0x.cgm 7.1 SMR Maps - MASK0x
maskdata vptrack0x.cgm
7.1 SMR Maps - TRACK0x
IP ADSBIN adsbdata adsbin.ini 2.2.2 - - -
IP ASIFIX-MLAT asifixdata asifix_mlat.ini 2.2.2 mapdata mlatmask.cgm 2.2.2 Technical - COVERAGE MLAT
IP ASIFIX-RDPS asifixdata asifix_mssr.ini 2.2.2 <app>_mask.cgm 7.2 -

asifixdata asifix_systr.ini
IP ASIFIX-TISB asifixdata asifix_tisb.ini 2.2.2 - - - -
IP LIMAS lightdata/xml limas.xml 7.4.7 - - - -
IP PLAMAS plamasdata plamas.ini 2.2.2 - - - -
CTP HYMESET hymesetdata hymset.ini 2.2.5.3 - - - -
CTP TARGHITT targhittdata targhitt.ini 2.2.4.2 - (General description) 2.2.4.2 -

(+referenced ini files) mapdata targhitt_coverage_areas_rad0x.cgm 7.2 SMR Maps - TARGHITT COVERAGE 0x
mapdata targhitt_semi_coverage_areas_rad0x.cgm 7.2 SMR Maps - TARGHITT SEMI COVERAGE 0x
mapdata targhitt_shadow_areas_rad0x.cgm 7.2 SMR Maps - TARGHITT SHADOW 0x
mapdata targhitt_runway_areas.cgm 7.2 Technical - RUNWAYS
mapdata apron.cgm (optional) - Technical - TRACK APRON
mapdata rdps_coverage.cgm (optional) 7.2 Technical - COVERAGE RDPS
mapdata rdps_shadow.cgm (optional) - Technical - SHADOW RDPS
mapdata rdps_nai.cgm (optional) - Technical - RDPS NON INITIATION
CTP TARGHITT-INT targhittintdata targhittint.ini 2.2.4.1 - (General description) 2.2.4.1 -

mapdata targhittint_blanking_areas_rad0x.cgm - SMR Maps - TARGHITT BLANKING 0x
mapdata targhittint_nai_areas_rad0x.cgm (optional) - SMR Maps - TARGHITT NON INITIATION 0x
mapdata targhittint_system_nai_areas.cgm 7.2 Technical - TRACK NON INITIATION
mapdata targhittint_system_blanking_areas.cgm 7.2 Technical - TRACK BLANKING
CTP TFP tfpdata alr.ini 7.3, - (General description) 2.2.4.3 -
tfpdata idt.ini 7.4 mapdata alrareas.cgm 7.4 Technical - ALERTING
tfpdata msf_targhitt.ini mapdata rimareas.cgm 7.4 Technical - RIM
tfpdata rim.ini mapdata rimlvpareas.cgm 7.4 Technical - RIM LVP
tfpdata tcm.ini mapdata idtareas.cgm 7.3 Technical - IDT
tfpdata tfp.ini mapdata tcmtopology.cgm 7.4 Technical - TCM
tfp/xml rulelists.xml mapdata/use tcmtopology_out.cgm 7.4 Technical - TCM GEN
mapdata pushback.cgm 7.5 Technical - PUSHBACK

mapdata stands.cgm - Technical - STANDS TECHNICAL
mapdata predict.cgm (optional) - Technical - TRACK PREDICT
mapdata inhibit.cgm optional) -
CTP TRAMON tramondata/xml airportcomp.xml 2.2.5.2, airportdata airport-topology.cgm 7.4.6 Technical - TRAMON
restrictions.xml 7.4.6 airportdata/use airport-topology_out.cgm 7.4.6 Technical - TRAMON GEN
sysvars.xml
rwys.xml
DP TRADIS tradisdata tradis.ini 7.6.1, mapdata sectionarea.cgm 7.6.1 Technical - LABEL SCHEME
tradis/xml N- xml files 21 mapdata trackfilter.cgm 7.6.1 Technical - TRACK FILTER
tradisdata/xml mapdata stopbar.cgm 7.4.7 (Settings > Stopbars)
mosdata mos0x.cgm 7.6.1 SMR Maps - MOSAIC0x
DP TRADIS - - - tradisdata/maps references.cgm Technical - REFERENCES
tradisdata/maps OUTERCONTURE.cgm Airport - OUTER CONTURE
tradisdata/maps ISLANDS.cgm Airport - ISLANDS
tradisdata/maps app_lines.cgm Airport - APP LINES
tradisdata/maps arp.cgm Airport - ARP
tradisdata/maps buildings.cgm Airport - BUILDINGS
tradisdata/maps cl.cgm Airport - CENTRELINES
FOR DISPLAY PURPOSES ONLY

tradisdata/maps holdings.cgm Airport - HOLDINGS
tradisdata/maps mlat.cgm Airport - MLAT
tradisdata/maps pavement.cgm Airport - PAVEMENT
tradisdata/maps roads.cgm Airport - ROADS
tradisdata/maps roadnames.cgm Airport - ROADNAMES
tradisdata/maps rwy_id.cgm Airport - RWY ID
tradisdata/maps smr.cgm Airport - SMR
tradisdata/maps gates.cgm Airport - STANDS
tradisdata/maps gate_id.cgm Airport - STAND IDS
tradisdata/maps twr.cgm Airport - TWR
tradisdata/maps twy_id.cgm Airport - TWY ID
mapdata lightid.cgm (optional) Airport - LIGHT ID
tradisdata/maps 04R_ils_crit.cgm ILS Maps - 04R ILS
tradisdata/maps 22L_ils_crit.cgm ILS Maps - 22L ILS
tradisdata/maps 04L_ils_crit.cgm ILS Maps - 04L ILS
tradisdata/maps 22R_ils_crit.cgm ILS Maps - 22R ILS
tradisdata/maps 12_ils_crit.cgm ILS Maps - 12 ILS
tradisdata/maps 30_ils_crit.cgm ILS Maps - 30 ILS
tradisdata/usrmaps freemap1.cgm LOCAL FREE MAP
mapdata emergency.cgm EMERGENCY
RRP ARCHIT architdata archit.ini 14.9 - - - -
RRP SICO sicodata gensico.ini 2.2.7.3, - - - -

7.7
CMSP CMSSERVER /HITT/opt/cms/co cmsserver - - - - -

nfig/sysconfig
CMSP CMSCLIENT /HITT/opt/cms/co cmsclient 7.8 - - - -

nfig/sysconfig
CMSP CMSWEB /HITT/opt/cms/co cmsweb - - - - -
nfig/sysconfig
All General projectdata sensor.config 2.4.3 - - - -
projectdata settings.project
Table 9: List of configuration files and maps

2.3.3 System Time

Time synchronization in the system is essential for the correct working of the system, especially for the
multisensor fusion process. Therefore it is necessary to synchronize the time on each node with a
primary server containing the reference time.
NTP runs on every computer; synchronization is done on polling basis. NTP is used for time
synchronisation of the nodes within the system and to the external system, see figure below.
CTP01 is the primary server for the nodes within the A-SMGCS system. CTP02 is the secondary
server.
CTP01 is connected to the preferred server ts01. If ts01 fails, CTP01 is synchronising to ts02. If both
time servers fail, CTP01 is acting as a stand alone time server.
CTP02 is connected to CTP01 which is normally synchronised with the time server. If CTP01 fails,
CTP02 is synchronising with ts01. If ts01 also fails, CTP02 is synchronising to ts02. If ts02 also fails,
CTP02 is acting as a stand alone time server connected to its local clock and the other nodes will be
connected to CTP02.
The configuration of ntp is specified in the file /etc/ntp.conf of each node.
ts01 ts02 preferred server
secondary
server
ctp01 ctp02 VAN third

server
fourth
other server
nodes
A-SMGCS
Figure 18: NTP Time Synchronization Overview
2.3.4 System Directories

The complete HITT application on each node is located in the directory /hittsys.
Exceptions are
the CMS-application, see 2.3.4.2 Directory structure CMS
the LOGIT recording directory, see 2.2.7.1 Recording and Replay (LOGIT)
the SICO recording directory, see 2.2.7.3 Statistical Information Collector (SICO)
2.3.4.1 Directory structure hittsys

The directory hittsys is the home directory of user hittsys. The directory structure is shallow.
The directory structure on the nodes consist of two parts:

1. Common part, the same directory and files are present on all nodes
2. Node type specific part, the same directory and files are present on all nodes of the same type

(e.g. all DPs)

A global graphical presentation of the directory structure is:
/hittsys
Common Node Specific

directories Directories
directories
The directory structure is depicted in the following table. The common directories are in the upper part
of the table and are presented in a grey colour.
DP
Directory RDP IP CTP DP Maint. RRP CMSP
cmsdata x x x x x x x
commstls x x x x x x x
cores x x x x x x x
generaldata x x x x x x x
generaldata_atc x x x x x x x
geo x x x x x x x
geotrans, geotransdata x x x x x x x
ifhitt x x x x x x x
jcl, jcldata x x x x x x x
log, previouslog x x x x x x x
mibs x x x x x x x
projectdata x x x x x x x
repman, repmandata x x x x x x x
scripts x x x x x x x
testdata x x x x x x x
airportdata x x x
archit, architdata x
architgui, architguidata x
asifix, asifixdata x
coco, cocodata x x x
htp, htpdata x
hymeset, hymesetdata x
logit_gui, logitrep_guidata x
logit_rec, logitrecdata x
logit_rep, logitrepdata x
mapdata x x x x x
maskdata x x x x x
mosdata x x
plamas, plamasdata x
racoms, racomsdata x
racomsgui, racomsguidata x x
sico, sicodata x
targhitt, targhittdata x
targhittintdata x
tfp, tfpdata x
tradis, tradisdata x x
tramon, tramondata x
vesdata x x
Table 10: Directory structure hittsys

2.3.4.2 Directory structure CMS

The CMS-application is located in /HITT/opt/cms
As CMS must be able to run without the need for an actual application build, CMS and its components
are not located in the usual ‘/hittsys’ directory. It is located in the ‘/HITT’ directory. From there on, a
directory scheme is created. The directory structure looks like this:
CMS directory Contains

/HITT/opt/cms/etc "Ini-files" for CMSClient and CMSServer
/HITT/opt/cms/sbin The CMSClient and CMSServer binaries; configuration tooling
(cmsclient.config & cmsserver.config) is also loacated here
/HITT/opt/cms/config User-defined configuration
/HITT/opt/cms/tools Tools for test purposes
/HITT/opt/cms/plugins Available plugins
/HITT/opt/cms/log Log files from CMSClient and CMSServer
/HITT/opt/cms/cores Core files
Table 11: CMS directory structure
Changes to the CMS data files must be stored on the /auto/changes/patches/cmsdata
directory.

2.3.5 System Redundancy

The objective of redundancy is to eliminate single points of failure. The following means of redundancy
have been implemented in the system:
• A dual network (LAN A and B), physically separated. This means that each node is equipped
with two network connections, each connected to a separate LAN.
• On-line/off-line applications:
A number of applications is running in online/offline configuration. If an application is in on-
line/off-line configuration, it is running on multiple computer nodes (of the same type) and
preferably on physically different locations.
Applications that are in on-line/off-line configuration exchange heartbeats to inform the other
party (on-line or off-line) that it is alive. Example: when heartbeats are generated every 0.3
seconds by the on-line application and the heartbeat is missing for 0.8 seconds, the off-line
application becomes the on-line application. Only one application (the online application)
produces output.
The online application keeps the offline application up to date with the critical application data,
e.g. identification data, actual visibility and RWY-configuration.
• Replicated applications:
Other applications are replicated on multiple nodes of the same type. This means that there
are multiple sources of the same data. The receiving applications handle the double amount of
data (usually ‘first come, first serve).
The following table shows the redundancy types of the redundant applications:
On-line/off-line Replicated
HYMESET ASIFIX
TargHITT HTP
TargHITTint ITRIP (optional)
TFP LIMAS
TRAMON LogitREC
LogitREP
PLAMAS
SICO
TRADIS
Table 12: Redundant Applications

2.3.6 System Changes

Changes in the system need to be recorded and this is the responsibility of the System Administrator.
These changes (with respect to the installation set (on DVD)) are maintained in one central changes
directory.
This is /HITT/changes/patches located on one of the nodes in the system. Which node that is can
be determined by the following sequence of commands:
> cd /auto/changes (command is used here to have this link mounted)
> df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda7 6297208 3948644 2348564 63% /
tmpfs 1037736 0 1037736 0% /dev/shm
/dev/sda8 70764108 1741460 69022648 3% /HITT
/dev/sda5 23268 6089 15978 28% /boot
cmsp01:/HITT/changes 70764112 4469760 66294352 7% /auto/changes
>
In this example the /auto/changes is physically located on the CMSP01.
This directory has the same structure as /hittsys, which means that e.g.
/HITT/changes/patches/tradisdata contains the TRADIS data-files that differ from the
installation-DVD.
Each node links to this physical location on /auto/changes/patches, which means that changes
are accessible from each node. The configure script checks for changes from this directory.
Backup of changes:
Since the changes are only available on only one node, and in case this node might crash, every day
the /HITT/changes/patches directory on the CMSP01 is copied automatically as a backup to other
nodes.
This is done in the directory /HITT/user/……/backup_changes_directory/.
To find out on which nodes backup’s are created, use the command:
> grep PATCH_BACK */*
generaldata/general.patches:# specified in $PATCH_BACKUP_PROCESSORS
generaldata/general.patches:# input : $PATCH_BACKUP_PROCESSORS = list of
processors
generaldata/general.patches: if [ -z "$PATCH_BACKUP_PROCESSORS" ]
generaldata/general.patches: PATCH_BACKUP_PROCESSORS="rsp01 rrp01 ctp01
ctp02"
generaldata/general.patches: if [ ! -z "ècho -n ${PATCH_BACKUP_PROCESSORS}
|grep ${HOSTNAME_SHORT}`" ]
In this output you can see the variable PATCH_BACKUP_PROCESSORS, containing the nodes where
backups are made. This variable is used during the configure (but only when the configure is executed
as root).
About the time of day the backup is started, this is defined in generaldata/general.patches, for
example:
> view general.patches
(this list is shortened)
MINUTE="34" # 0-59 MINUTE
HOUR="2" # 0-23 HOUR
DAYOFMONTH="*" # 1-31 DAY OF THE MONTH
MONTHOFYEAR="*" # 1-12 MONTH OF THE YEAR
DAYOFWEEK="*" # 0-6 SUNDAY TO SATURDAY
Reinstallation of the node where the changes are stored:

Since the changes are available on one node, this node requires additional action when a new O.S.
and/or application software is installed.
The procedure for reinstalling the node that contains the /HITT/changes/patches directory is:
• install the LINUX O.S.,
• install the application software,

• copy the changes from one of the nodes (where backup have daily been performed) to the
changes directory of this newly installed node,
• run configure on the node

2.3.7 System Modes

A node can be in operational mode, or technical replay. The technical effect of a node being in a
specific mode is that it uses a dedicated set of communication channels. This means that only nodes
that are in the same mode will see each other.
• Operational mode is the default mode for every node. Operational Replay is also carried out
when the node is in operational mode. The procedure G_7: Setting up an operational replay
session describes how to setup operational replay.
• In technical replay mode, applications receive their input data from the replayer, rather than
from external systems. This mode is used to check and analyse configuration changes with
the same set of input.
2.3.7.1 Operational mode

Normally the processors are running in operational mode (mode: oper). In this mode the system is fully
operational and the display processors (DPs) show the traffic situation. The controller actions are
executed on the life data and communication of these actions to external systems takes place as
required.
Operational replay
Within the operational system mode it is possible to play back a recorded traffic situation at a replay
position. This can be done by using an operational replay graphical user interface and a TRADIS
traffic display on the replay position in operational replay-mode.
During operational replay, the operational functionality for the controllers, including redundancy,
continues without disturbance.
2.3.7.2 Technical replay mode

For test purposes (e.g. testing a modification of software, maps, or ini-files), one or more processors
can be started in technical replay (techreplay) mode. This means that redundant system parts are
used to create a separate system. Figure 19 shows an example of one Display Processor (DP), one
central processor (CTP), one Interface Processor (IP), and one Recording Replay Processor (RRP)
replaying the recorded data.
Note that creating this separate system is done in software only, and that physical network
connections are unchanged.
On this separate system in techreplay mode, tests can be performed, for example new system settings
or a new software build.
Switching to techreplay mode is described in G_5: Changing the mode of a node.
Processors started in techreplay mode expect data from the Replayer. Relevant recorded data can be
selected to be replayed.
2.3.7.3 Operational replay versus technical replay

There is a fundamental difference between operational and technical replay.
Operational replay reconstructs the traffic situation, and it has the possibility to reconstruct the
contents of a specific controller display.
Furthermore, the recording of data is not interrupted during an operational replay.
Technical replay replays data that is fed to the inputs of technical applications (e.g. in an CTP and/or
IP), with the intention to test new application releases or configuration or map changes.
During technical replay the operational recording on the RRP that is used for technical replay is
stopped.

Figure 19: Data flow (technical replay)

2.4 System specific items
2.4.1 Project settings

The following project specific interface selections are specified in the file
projectdata/settings.project.
Airport Reference Point:

Variable SYS_ORG is used in several parameter files. If the parameter is changed a configure needs to
be performed in the directories of the nodes and the nodes needs to be restarted (see configure in
G_3: Running configure).
2.4.2 Working positions

The following table lists the working positions on which users can login:
Node Login Role Other possible logins
dp03, dp04, dp05 auto controller
dp01 manual Any role
dp02 auto supervisor
Table 13: User Logins (auto/manual)
Explanation:
• auto in this table indicates automatic login (i.e. no username/password are required after
starting the node),
• manual indicates manual login.
2.4.3 Sensor settings

The following project specific sensor data are specified in the file projectdata/sensor.config.
It specifies among others:
• the location of each sensor,
• the sensor type,
• the height of the sensor,
• the revolution time of the sensor
If the sensor.config file is changed a configure needs to be performed (see configure in G_3:
Running configure).
For the conversion of lat/lon coordinates to x/y or visa versa the coco tool can be used, see 4.2.8
Coordinate Converter (COCO).

Example of the content of sensor.config:
# sysorg is expected to be the same for all sensor of one type (i.e. all surf. movement ra_dar sensors).
# Normally the system sensornr should be unique in this file. It is however possible to define extra processors
# as a replacement for an operational processor, for example an RSP or a test processor. However these 'replacement'
# processors should be defined BELOW THE OPERATIONAL PROCESSORS!!!!!.
# supported sensor types by targhitt:
# rad : primary ground movement radar (plots)
# : "rad" can not be called "rad_psr" YET and needs REFSYS changes
# rad_ssr : ssr ground movement radar (plots)
# rad_cmb : cmb ground movement radar (plots)
# app_rad_psr : primary approach radar (plots)
# app_rad_ssr : primary approach radar (plots)
# app_rad_cmb : primary approach radar (plots)
# rdps : approach radar (tracks)
# mlat
# adsb
# ais
# assumed is that the MC number in sensor.config is equal to the system sensor-id
# should be changed
# distinction between rad_pri and rad_app_pri will only have influence on default parameter set for targHITT
# For the updatetime of rdps sensors a - is used instead of the actual value
#
# Enter specific parameters for a sensor type in file projectdata/<sensortype>.settings.
#
# node local system (system) sensor multi sensor sensor sensor
# name sensor sensor sensor upd xpos ypos sys sys sensor shrte cast latitude longitude height
# name nr nr type time xpos ypos org_x org_y name name nr degr min degr min
rdp01 01 01 rad 1 -1605 217 0 0 smr_rdp1 R1 01 59 39.07452 17 54.31314 0
rdp02 01 02 rad 1 -1605 217 0 0 smr_rdp2 R1 02 59 39.07452 17 54.31314 0
rdp03 02 03 rad 1 826 1685 0 0 smr_rdp3 R2 03 59 39.865272 17 56.90028 0
rdp04 02 04 rad 1 826 1685 0 0 smr_rdp4 R2 04 59 39.865272 17 56.90028 0
rdp05 03 05 rad 1 1816 -386 0 0 smr_rdp5 R3 05 59 38.74971 17 57.953076 0
rdp06 03 06 rad 1 1816 -386 0 0 smr_rdp6 R3 06 59 38.74971 17 57.953076 0
ip01 01 08 rdps 5 13786 15123 0 0 MSSR-SITE1 RDPS1 01 59 47.0894 18 10.7502 0
ip01 01 15 mlat 1 200 300 0 0 mlatcps1_ip01 mlat1_1 01 0 0 0 0 0
ip01 01 19 adsb 2 200 300 0 0 adsbcps1_ip01 adsb1_1 01 0 0 0 0 0
ip02 01 20 adsb 2 200 300 0 0 adsbcps1_ip02 adsb1_2 02 0 0 0 0 0
#
# Sensors not used by targhitt
ip01 01 0 hyme - 0 0 0 0 meteo1 H1 01 2 9 99.99999 99 9.9999 0
ip02 01 0 hyme - 0 0 0 0 meteo1 H1 02 2 9 99.99999 99 9.9999 0
ip01 02 0 hyme - 0 0 0 0 Station_1 met1 03 9 99.99999 99 9.9999 0
ip01 02 0 hyme - 0 0 0 0 Station_2 met2 04 9 99.99999 99 9.9999 0

MAINTENANCE CONCEPT
3. MAINTENANCE CONCEPT
3.1 Introduction
Maintenance is assumed to be performed by the maintenance organisation of the owner of the system.
It is possible to establish a maintenance contract with the seller of the system.
The Control and Monitoring System interrogates the system at regular intervals for the status of e.g.
the antenna, the radar, the video processor, the workstations and each software process. When any of
these elements is not operational an indication is given.
Equipment can be delivered redundant, which means that a single failure will have no influence on the
operational functionality of the system (the redundant part will take over).
A daily check of the reports generated by the CMS should be sufficient to ensure the system is
available to the controllers.
3.2 Maintenance Organization Aspects
3.2.1 Responsibilities
Maintenance is the set of activities to keep the system available for the end-user during 24 hours a day
and 365/366 days per year. System availability depends on different parties like:
• The end-users, using the system in such a way that damage is prevented and reporting
failures in due time.
• The System Administrator, providing technical assistance (helpdesk), performing/organizing
maintenance and handling spare parts.
• An (subcontracted) organization, performing the maintenance activities.
• The original supplier of the system on request can assist with repair and knowledge support.
The actual arrangement of this support will depend on a maintenance contract.
3.2.2 Management, Co-ordination and Administration

Within HITT one point of contact (POC) will be appointed to co-ordinate the services during the
warranty period and in case of maintenance contract during the period of this contract.
This POC is the single point of entry for the customer, the HITT management and the assigned
personnel as far as the specific contract is concerned.
3.2.3 Maintenance Administration

Changes in the system need to be recorded at all times. This needs to be done by the System
Administrator in order to be able to recall at any moment the state of the system in terms of hardware,
software and documentation:
Hardware
The system is provided with serial numbers on all components. These S/N’s are recorded in the
Version Description Document [VDD].
Upon corrective maintenance the S/N of defective and replacing spare part has to be recorded.
Software
The system is installed with software that is supplied on software carrier (DVD’s). The software
versions are recorded in the Version Description Document [VDD].
Any changes in the software (either corrective or adaptive) have to be recorded and documented.
These changes are required in case of corrective maintenance, for example when replacing a
defective computer, first the original software is installed and then the software changes are
implemented.
Documentation
The system is provided with a set of documentation. Changes due to maintenance have to be
recorded in the documentation.

MAINTENANCE CONCEPT
During the warranty period HITT has to be informed and receive the documentation and file of any
change. This obligation will remain available when a software maintenance contract is in operation.
It is suggested to maintain a logbook to record maintenance activities.
In case software needs to be installed (for example after a disk crash), then the operating system
software and the application software need to be installed as described in [ID].
Software configuration control

Software configuration control requires a concise way of working. Here are some guidelines in keeping
track on changes in the system:
• Always make a plan first (why is a change necessary, which processors are involved, on what
processor will the change be implemented first, how will it be tested, etc.). Give it a reference
number so it can afterwards easily be referred to.
• Make a copy of the file(s) before changing anything (for example, make copies it with
extension '.org')
• Do the change on only one processor. While changing, add comments (including the
reference number of the change) in this file. Make sure you can undo all changes quickly (e.g.
by restoring the '.org'-files) in case the system must be available immediately for example in
case of operational emergencies.
• Test the change thoroughly.
• Store the changed files on the changes directory, see G_2: Distribute changes with
autochanges.
• Implement the change on the rest of the system and test it again on each processor involved,
see G_2: Distribute changes with autochanges.
• Inform the users about the changes made.
• Document the change: Indicate what files and in what lines these files have been changed and
where these files will be stored. Indicate which (system) documents have been changed, on
what pages and add the reference number near each and every change.
• Create a backup of the change.
3.3 Maintenance types

Maintenance can be divided into the following types:
• Preventive maintenance (regular activities to be performed according a checklist)
• Corrective maintenance (repair action triggered by an operational or technical failure)
• Adaptive maintenance (update of system parameters due the changed environmental
conditions and/or procedures)
• System Enhancement (addition of hardware, software, or functionality)
3.3.1 Preventive Maintenance

Preventive maintenance is a number of activities performed at regular time intervals with the aim to
reduce unwanted system down time.
The management of the maintenance organization can monitor the preventive maintenance via the
creation of a checklist. This checklist is created and maintained by the maintenance organization. The
maintenance engineer shall tick and sign per completed action. The checklist shall refer to the relevant
maintenance document of the manufacturer of the equipment.
Preventive maintenance covers both hard- and software.
3.3.2 Corrective Maintenance

Corrective maintenance is necessary to return a system (part) to operational state after a
malfunctioning.
The malfunctioning of a system (part) is either detected by the operational staff, the icon colour change
and status reports at the CMS or during preventive maintenance. Corrective maintenance covers both
hardware and software.
Hardware

MAINTENANCE CONCEPT
Localization of the defective Line Replaceable Unit (LRU) will be done from the CMS, via the fault
finding procedure or by the trained maintenance engineer interpreting the documentation and
schematics delivered with the system (part).
The moment of replacement of the defective LRU depends on the availability of redundant equipment,
the operational disturbance and the availability of a spare LRU.
The repair of the defective LRU depends on the availability of a service /repair contract and the new
price. Depending on the contract defective parts are exchanged immediately from stock or after being
repaired. The returned spare part is put into the depot again.
Software
Software error messages are continuously stored and can be analyzed at any time. But in case of a
(software) failure restarting one or more processes might solve a problem quickly. And after that, the
error loggings can still be analyzed to find out the cause of the failure.
Based on the analysis it can be concluded that further detailed investigations are necessary. In that
case, during warranty (and if contracted also after the warranty period) operational software can be
adapted by HITT to include specific search paths to further localize the software failure. After solving
the bug, the operational software will be patched. At delivery of a new software build all known patches
will be incorporated.
3.3.3 Adaptive Maintenance

Adaptive maintenance will be performed when the system behavior has to be adapted to changing
environmental circumstances.
The system is equipped with a set of parameter and map files. The parameter files can be edited with
the text editor that comes with the Operating System (e.g. for Linux the vi editor). The map files can be
edited with the map tool. Use the auto/changes directory to store the changed files and to make them
available for other relevant processors, see G_2: Distribute changes with autochanges.
NOTE: It is strongly advised to make a copy of the original file before any editing is done. This original
file can be used to replace the edited file, when the edit result is not as expected.
Good configuration management and the description of the adaptations in the files is required to keep
track of all modification and to ensure implementation of the required modification in new software
builds. Depending on maintenance contract, adaptive maintenance can be shared between HITT and
the System Administrator.
All maintenance activities must be followed by an overall system observation. Configuration changes,
mode changes and sensor settings must be checked by the maintenance engineer.
3.3.4 System Enhancement

System enhancements are additions of new system hardware or software to the system. In case of
system enhancements the system specification is always changed.
Examples of enhancements are:
• Addition of a Controller Working Position or Display Processor.
• New functionality, for example on-going improvements and development programs within
HITT, together with problem solving in other projects, result in new releases of software.
Enhancements can only be done by HITT and require an update of system documents and operational
manuals.

MAINTENANCE FACILITIES
4. MAINTENANCE FACILITIES
This part describes the maintenance facilities that are used in this maintenance manual:
- maintenance applications
- maintenance tools
4.1 Maintenance applications

The maintenance applications are:
• TRADIS (simular as used by the operational end user), is used to check the system
performance (in terms of video/tracking/plans) and to adapt the maps and TRADIS settings for
the Controller working positions, refer to Appendix: Traffic Display (TRADIS).
• CMS, is used to check system status and to control the running of processes and nodes, refer
to Appendix: system control (CMS portal).
• RACOMS, is used to check radar status and to control the different features of the radar, refer
to Appendix: Radar Control and Monitoring (CMS RADAR)
• LOGIT-Replay, is used to control the replay of recorded data, refer to Appendix: replay Control
(Replay GUI)
• ARCHIT, is used to control the archiving of recorded data to tape and the restore from tape,
refer to Appendix: Archiving data (ARCHIT)
4.2 Maintenance tools

The maintenance tools are:
• Linux environment (KDE)
• Eval-monitor (used in a LINUX Terminal-window)
• Comms-monitor (used in a LINUX Terminal-window)
• Asterix Monitor (used in a LINUX Terminal-window)
• Listen command (used in a LINUX Terminal-window)
• Tcpdump command (used in a LINUX Terminal-window)
• CommsLog (used in a LINUX Terminal-window)
• Coordinate Converter (COCO)
• Video Extractor Scope (VES)
• Memory stick / USB disk
4.2.1 Linux environment (KDE)

The linux environment is equipped with a graphical user interface, called KDE, having a KDE-menu:
Figure 20: KDE-menu
4.2.1.1 KDE-menu: HITT applications

On the maintenance display, the HITT-applications can be started from the KDE-menu.

Figure 21: KDE-menu HITT applications (example)
4.2.1.2 KDE-menu: System/Utilities

On the maintenance display, via the KDE-menu, various KDE-applications can be started:
• Terminal (System-Terminal-Terminal Program (Konsole))
• File Manager (System-FileManager-FileManager (SuperUserMode)
• File system (System-FileSystem-ViewDiskUsage (KDiskFree)
• Text editor (Utilities-Editor-Kate)
• ScreenCapture (Utilities-Desktop-ScreenCapture (Ksnapshot))
• Compare (Utilities-Diff/Patch (Kompare))
• CD/DVD Burn (Multimedia- K3b)
• Calculator (Kcalc) (Utilities-Kcalc) e.g. converting decimal to octal v.v. (use ‘Settings-
Logic’)
Applications in the KDE-menu can also be started from the Terminal prompt, e.g.
>kate&
>kcalc&
>konqueror&
Note that in Linux applications the network is transparent. This means that for example the file
manager, called Konqueror, is able to access files on other nodes in the network. Just enter in the
‘Location’ field:
fish://<nodename or ip-adres>
e.g. fish://ctp01
An exception to this network transparency is the K3b-burning application, which requires that files to
be written to CD/DVD are locally available on the node where the CD/DVD writer is located.
Note that the FileManager –window can be split (menu: Window – Split View Left/Right) and that files
can be dragged between these splitted views.

4.2.1.3 Burning files on CD or DVD

Files can be written to CD or DVD using the K3b application, which is part of the KDE desktop tools.
This program can be started from the KDE menu.
Note: Files to be written to CD/DVD must be available on the node where K3b is started; for example,
to write LOGIT-files to a CD/DVD, either start k3b on the RRP, or first copy the files from a RRP to the
local node.
• To start the K3B program, use the KDE menu, or enter K3b on the command line.
• Select ‘New Data CD project’.
Figure 22 K3b-> New Data CD Project
The upper part in the K3b GUI represents the directory structure of the local computer and the
lower part in the K3b GUI represents the files that have to be written to CD/DVD.
• Select in the upper part the files from the TOCD directory that has to be written to CD/DVD
and drag these files to the lower part of the GUI, see next figure.
Figure 23 K3b GUI
• When the files to be copied are in the “Current Projects” part, the button can be
pressed to start the burning procedure. A dialog will appear with settings for the write
procedure.

• Select the button in this dialog to start the writing to disk.
At the end of the session, the CD/DVD is ejected. The K3b program can be closed and the CD/DVD is
ready.
4.2.1.4 Standard Available Linux commands

In the Terminal-window, commands can be entered, e.g.
- standard available Linux commands like:
• ls –l
• ps –ef
• top
• df
• …many more…
- HITT specific commands like:

• telnet ctp01 eval-targhitt
On help on syntax of the Linux-commands, refer to the manual pages, e.g. ‘man ls’.
The HITT specific commands are described in this manual.
4.2.2 Eval-monitor
The eval-monitor is an application-specific telnet-interface that can be used to:
• check the functioning of an application
• read or change a system parameter for an aplication.
Commands for the eval-interface are application-specific. The available commands are shown when
entering the help (‘?’) command.
The general syntax to start the eval-monitor is:

> telnet <nodename> <service name>
To find out which of the applications can be evaluated, the service name for an application can be
found using the command:
> grep eval- /etc/services
eval-htp 51550/tcp # # HITT ENTRY
eval-tfp 51553/tcp # # HITT ENTRY
eval-logit 51554/tcp # # HITT ENTRY
eval-aramis 51555/tcp # # HITT ENTRY
eval-dis 51555/tcp # # HITT ENTRY
eval-plamas 51556/tcp # # HITT ENTRY
eval-jcl 51558/tcp # # HITT ENTRY
eval-repman 51559/tcp # # HITT ENTRY
eval-cms 51560/tcp # # HITT ENTRY
…and more…
This means that for example the LOGIT-application can be evaluated via the command:
> telnet ctp02 eval-tfp
Note that the <nodename> can be replaced by ‘0’ when the application is running on the current
node.
An eval-monitor provides a help-function (‘?’), which lists the possible commands.
The eval-monitor is terminated by typing ‘<Ctrl> ]’ and then ‘q’.
In the following paragraphs the most usefull eval-monitor tools are described.

4.2.2.1 TargHITT-Interface (TargHITTint)

You can check the TargHITT-Interface (TargHITTint) with its eval-monitor by:
> telnet ctp01 eval-targhittint
Escape character is '^]'.
*** Welcome to TargHITT INTERFACE evaluation
*** Version: TARGHITT_CVS_TAG: TARGHITT_2_2_RC3
>
Duplication Information
You can check the duplication status of TargHITTint with the du command. This shows the current
status and the last transition.
> du
duplication: ONLINE current mode is Online
online -> offline: 0
offline -> online: 1 last: Fri Mar 04 16:17:49.152448 2005
>
Sensor Status
The gr command gives you an overview of the defined sensors and their status. The following
fragment gives you an impression of the output.
> gr
------------------
radar1
ConnectionStatus : connected
Sensors: 1-REDUNDANT 2-ACTIVE
------------------
radar2
ConnectionStatus : connected
Sensors: 3-ACTIVE 4-REDUNDANT
------------------
>
Sensor Overview
The sn command gives you an overview of the sensors that contribute to tracking.
> sn on
------------------
Sensor info
Actual date/time: 2007/06/19 09:58:15.457
Sensor Sectors Status RevTime NorthDateTime Norths SNorths Targets
Activs Deacts Filter CorrId
------------------
1 32 ACTIVE 1.000 2007/06/19 09:58:14.362 495 0 15 1 0 0 0
2 32 REDUNDANT 0.996 2007/06/19 09:58:14.374 495 0 16 0 0 0 0
5 0 REDUNDANT 4.756 2007/06/19 09:58:12.656 104 0 23 0 0 0 0
6 32 ACTIVE 4.756 2007/06/19 09:58:12.656 104 0 23 1 0 0 0
13 0 TIMEDOUT 4.700F 1970/01/01 00:00:00.000 0 0 0 0 0 0 0
14 0 TIMEDOUT 4.700F 1970/01/01 00:00:00.000 0 0 0 0 0 0 0
------------------
> sn off (to stop the output of the ‘sn on’ command)
You can obtain more detailed sensor information by typing sn <sensor number>. The sensor
number corresponds to the numbers in the status overview. The following example shows the output
of the sn command. The indication “Targets last sc“ indicates that this sensor actually provides
plots, which suggests normal or at least partial function of the radar.
> sn 1
Ext sensor id : 1
Default revo T : 1.000
Plot outp laten: 8
Sensor group : 1
Sim sector intr: false

Keep sens alive: false

Revo T filt alp: 0.200
North T sim max: 0
Delta north ang: 0.000
Sectors last sc: 32
Sensor status : ACTIVE
Revolution time: 1.009 (Updated)
North date/time: 2007/06/19 09:58:43.341
Received norths: 524
Simulate norths: 0
Targets last sc: 16
Activates : 1
De-activates : 0
Filter status : 0
>
Evaluation sensor input

You can check that the input of TargHITTint from a specific sensor number (i.e. the number as seen in
‘sn on’ of the TargHITTint evaluation)
> st 1
> sensorId: 1 trackId: - xyPos: 944.89 -1438.12 loc:
somewhere status: - ssrCode: - addr: - time: 2007/06/19
09:59:10.758
sensorId: 1 trackId: - xyPos: 618.40 -1193.35 loc:
09:59:10.776
sensorId: 1 trackId: - xyPos: -286.73 -1887.15 loc:
09:59:10.878
09:59:10.879
09:59:10.886
09:59:10.940
09:59:10.962
...more…
> st off (to stop the output)
Evaluation of tracks sent to TFP

You can check all tracks sent from TargHITTint to TFP.
> tr all
sensorId: 1 trackId: 121 xyPos: 711.69 -1109.20 class: TRUE
sensorId: 1 trackId: 119 xyPos: 701.91 -1474.78 class: TRUE
sensorId: 1 trackId: 29 xyPos: -239.55 -1576.33 class: TRUE
...more…
The output can be stopped with the following command:

> tr off

To show more details of a specified trackid, use

> tr <trackid>
4.2.2.2 TargHITT
TargHITT can be checked through its eval-monitor. You can check if it receives all required sensor-
inputs and if it produces the required outputs.
You can check the TargHITT (TargHITT) by starting an eval-monitor by:
> telnet ctp01 eval-targhitt
Trying 10.89.1.31...
Connected to ctp01.
Welcome to TargHITT evaluation
Version: TARGHITT_CVS_TAG: TARGHITT_2_3_1 (build 20070603394), Jun 25 2007,
17:35:41
> Type '?' to get a list of commands
In this eval-session you can verify the following aspects:
You can check the duplication status of TargHITT with the du command. This shows the current
status, and the last transitions.
> du
STATUS : ONLINE
IDENT : 1
PRIORITY : 1
reliability : 1
offline switches : 0
online switches : 1
last offline switch: 04 Mar 16:17:46.968
last online switch : 04 Mar 16:17:48.612
>
Sensor Overview
The sensor overview on the TargHITT evaluation function shows the status of all sensors. This should
match with the status overview from TargHITTint.
> sn (as an example)
ident status sensorTp active revolutionT plots filter corrId
1 OPERATIONAL RADPR TRUE 1.00697E+00 20 NONE 0
2 NOT_CONNECTED RADPR FALSE 1.00000E+00 0 NONE 0
3 NOT_CONNECTED RADPR FALSE 9.93385E-01 0 NONE 0
4 NOT_CONNECTED RADPR FALSE 1.00000E+00 0 NONE 0
5 NOT_CONNECTED APPROACH FALSE 0.00000E+00 0 NONE 0
6 NOT_CONNECTED APPROACH FALSE 0.00000E+00 0 NONE 0
7 NOT_CONNECTED MLAT FALSE 0.00000E+00 0 NONE 0
19 NOT_CONNECTED ADS_B FALSE 0.00000E+00 0 NONE 0
20 NOT_CONNECTED ADS_B FALSE 0.00000E+00 0 NONE 0
>
Statistics
You can check the number of PR-plots, SSR-plots, CMB_plots (combined), False-tracks, Tentative-
tracks, and True-tracks.
> stats
PR plots SSR plots CMB plots False tracks Tentative tracks True tracks
44 0 0 9 1 29
4.2.2.3 TFP
You can check specific TFP aspects by starting an eval-monitor on it.

> telnet ctp01 eval-tfp

Trying 10.89.1.31...
Connected to ctp01.
*** TFP evaluation terminal ***

TFP_CVS_TAG: TFP_7_2_0 (build 20070629053), Jun 4 2007, 19:13:13
(type help for help)
On-line TFP : 1 ctp01
>
Sensor Overview
You can request a periodic sensor overview (sn on) to see if all sensors contribute. The sensor
overview terminates with sn off. When using the TargHITT tracker you should only see the sensors
(the TargHITT tracker) as shown in 4.2.2.1.
> sn on
** Sensor cmd accepted.

>
Sensor evaluation start time: Tue Jul 10 14:52:43.419980 2007 current

time: Tue Jun 19 09:55:37.469590 2007
Id Status Rev-Time Restart NrTrks AvTrks ExTrks Split Merge Wipe
Corr Init SrtIdent Name
41 offline 01,000 s 0 0 0 0 0 0 0 0 0 - Duplication tracks
90 F online 01,000 s 0 26 13.357 0 0 0 0 0 0 - TargHITT tracks ctp01
91 unknown 01,000 s 0 0 0 0 0 0 0 0 0 - TargHITT tracks ctp02
> sn off (to stop the output)
Duplication status
The duplication status of TFP can be checked with CMS, another option is the eval-monitor.
The eval-monitor of TFP can display the duplication information, as indicated in the following example.
It shows the heartbeat time, the number of switches and the number of missed heartbeats. If this last
output indicates that heartbeats are missing frequently you should check your network thoroughly for
lost packages.
> du i
** Duplication cmd accepted.
>
DUPLICATION INFORMATION
ON-LINE
Node name ctp01
Current time Wed Jan 26 08:17:15.489027 2005
Current Heartbeat time 0.3 (the heartbeat frequency)
Process start time Tue Mar 08 04:40:53.334945 2005
Evaluation start time Tue Mar 08 04:40:53.334942 2005
Reliability 10011
----------------------------
Last On-line switch Tue Mar 08 04:40:54.960447 2005
Number On-line switches 1
Last Off-line switch Tue Mar 08 04:40:53.334944 2005
Number Off-line switches 0
Number Priority switches 0
Number Reliability switches 0
----------------------------
Number Online heartbeats 0
----------------------------
Number Offline heartbeats 0
Highest priority received 0
----------------------------
Number Own heartbeats 0
----------------------------

number of delays of received online heartbeat ( > x * heartbeat-time)

2*: 0 | 3*: 0 | 4*: 0 | 5*: 0 | 6*: 0 | 7*: 0 | 8*: 0 | 9*: 0
>
Check EvaluationCounters
You can check various counters of the TFP-process.
> ec s 0
** EvaluationCounters cmd accepted.

>
NrOfRecvdTracks 2547842 NrOfRecvdOldTracks 0 NrOfRecvdLostTracks 13130

NrOfRecvdTrksOutsFlt 0 NrOfSupprLostTrack 0 NrOfRecvdTrksOffline 0
NrOfSupprAssoTracks 0 NrOfExpiredAssoTracks 2109
NrOfSynchrTracks 0 NrOfASynchrTracks 1749689 NrOfSynchrBatches 0
NrOfASynchrBatches 347151 Tentative 15449 NrSystemTracks/scan 22
> ec off (to stop the output)
Check identifications
You can show identifications i.e. identified plans and not-identified plans.
> di id to show all identifications
Or
> di id ADSB to show all ID’s having ‘ADSB’ (partly) in the callsign
> di off (to stop the output)
Check parameters
You can check the values of parameters.
> sp f to show all parameters
Or
> sp f alert to show all parameters having ‘alert' (partly) in the name
The values are shown in terms of File:, Dft:, Low:, and Up:, where
- File: value in ini-file and becomes actual value after a configure (error when beyond limits
Low/Up)
- Dft: is the default value as (hardcoded) in the executable; becomes actual value if no ini
exists
- Low and Up are the min/max values.
RIM status
You can check the actual status of RIM by typing the command ‘di ru’ (RIM Runway Overview). The
resulting overview shows which tracks are being monitored by RIM, as shown in the following
example:
> di ru
** Display cmd accepted.
Off-line TFP : 1 ctp01
>
Visibility = unknown
Nr of runways: 6
runway 30 orientation( 303.10 ) usage( Departure ) tracks:
Track 2956 { pos: ( -411.50, 237.34), heading: 213.49, speed: 7.31,
thresDist: -1569.28, Runway }
runway 12 orientation( 123.10 ) usage( Landing ) tracks:
thresDist: -1501.29, Runway }
runway 22L orientation( 221.06 ) usage( Closed ) tracks:
runway 04R orientation( 41.06 ) usage( Landing ) tracks:
Track 3840 { pos: ( -7050.86, -9089.14), heading: 315.00, speed: 99.81,
thresDist: 9318.16, Approach } ident: 3026
runway 22R orientation( 221.18 ) usage( Departure ) tracks:

thresDist: -987.81, Approach }

thresDist: 1407.72, Approach }
runway 04L orientation( 41.18 ) usage( NotInUse ) tracks:
> di off (to stop the output)
The overview shows you the number of runways, the runway usage and it shows which tracks are in
the approach area (Approach in the track information) or on the runway (Runway in the track
information).
Plan information
You can check planinformation by carrying out the following checks:
- Amount of lost plans:

Type the command ‘pl dr l’ to display the amount of lost plans. In an operational situation this
amount must be very low to zero.
- Amount of (un)identified tracks

Type the command
‘pl dr i’ to obtain an overview of identified tracks
‘pl dr u’ to obtain an overview of unidentified tracks
‘pl n <plan number>’ to obtain detailed plan information as shown in the following example:
> pl n 4074
** Plan cmd accepted.
Off-line TFP : 1 ctp01
Plan: 4074 Source: Ivs Keep: Idt UpdT: 14:07:33 25/04/2005 journeyId:
IP:DM:147::2005-03-29:DEP callsign: DAN147 aircraft type: B737 wtc: M
departure dest: EPWA dep: EKCH mode3A: 271 reg-nr: OYMRI gate: D2 etd:
09:45:00 29/03/2005 aoffbt: 09:50:00 29/03/2005 fdpsPlanStatus: active
tpIATA: 73G STO:09:45:00 29/03/2005 rwyPlan: 04R gtPass: D102 fromStd: D2
.U....taggedItems: FlNr(147) CCode(DM) SchStat(I) icao_route(WAW) ServType(J)
BusReq(N)
>
4.2.2.4 PLAMAS
You can check specific PLAMAS aspects by starting an eval-monitor on it.
telnet ip01 eval-plamas
Trying 10.89.1.51...
Connected to ip01.
*** Welcome to PLAMAS ***

PLMATC_CVS_TAG: PLMATC_2_0_0 (build 20090420695), Apr 21 2009, 10:05:47
> ed list
Distribution
Collection
Input
Input
Input
Output
The output of PLAMAS can be checked with the ‘ed output’ command:
> ed input (to verify the flight plans on the input of PLAMAS)

Evaluation Input started

Received input data:
<KEEP-ALIVE>ALIVE</KEEP-ALIVE>
Contents of parser dictionary:
<arrival>
<callsign>NDC303A</callsign>
<date-of-operation>2007-11-21</date-of-operation>
<ADEP>ESSA</ADEP>
<ADES>EKCH</ADES>
<movement-plan-status>A</movement-plan-status>
<aircraft-information>
<IATA-AC-type>M82</IATA-AC-type>
<ICAO-AC-type>MD82</ICAO-AC-type>
<wake-turbulence>M</wake-turbulence>
<aircraft>
<registration>SERDT</registration>
</aircraft>
... etc ...
The output of PLAMAS can be checked with the ‘ed output’ command:
> ed output (to verify the plans on the output of PLAMAS)
…insert output here..
Note that PLAMAS generates output only when either the ADEP or ADES is filled.
(ed off to stop the ed-output)
4.2.2.5 HYMESET
You can check specific HYMESET aspects by starting an eval-monitor on it.
telnet ip01 eval-hymeset
Trying 10.89.1.51...
Connected to ip01.
*** HYMESET evaluation terminal ***
( type help for help )

HYMESET_7_1_2 (build 20080125048) Jan 23 2008 10:06:22
> help
help Displays this help
info Shows general information
test Toggles extra output for testing purposes
spappl Shows general application system parameters
mvi Shows the manual visibility input
avd Shows the automatic visibility derivation
statrvrsensor Shows the received sensor information
sprvr Shows the system RVR system parameters
rwc Shows the runway configuration input
rws Shows the runway strip condition input
alarm Shows the equipment alarm input
abi Shows the airport broadcast info input
vis Shows the visibility info input
met Shows the meteo info input
dupl Shows if the application duplication status
spdupl Shows duplication system parameters

You can check the duplication status of Hymeset with the dupl command.
> dupl
--------------------------------------------------
Duplication information
--------------------------------------------------
Status: Duplication Online
--------------------------------------------------
>
4.2.2.6 ITRIP (optional)

This CI is not in the standard product but can be used for a specific project.
4.2.2.7 Log eval output in a file

In order to log the output of the evaluation into a file for further evaluation purposes, the following
commands needs to be executed.
hittsys@ip01:~> script <filename.txt>

Script started, file is <filename.txt>
Execute the telnet session as described in the previous sections.
hittsys@ip01:~> exit
Script done, file is <filename.txt>
hittsys@ip01:~>
The file <filename.txt> contains the output of the telnet session.
4.2.3 COMMS-monitor
The COMMS-monitor tool can be compared to an oscilloscope. In a hardware system, an oscilloscope
is used as a measuring tool to view electronic signals in electronic circuits.
Simular to viewing electronic signals, you can view messages, that an application actually sends or
receives, using the COMMS-monitor. The HITT applications (except HTP) communicate using
COMMS.
The COMMS-monitor interface offers commands to monitor these messages. The syntax for the
COMMS-monitor is identical for each comms applications.
4.2.3.1 Using the COMMS-monitor

The COMMS-monitor is available in a telnet-interface. The general syntax to start the COMMS-monitor
is:
> telnet <node name> <service name>
To find out the service name, use the command:

> grep comms- /etc/services
comms-htp 51200/tcp # # HITT ENTRY
comms-tfp 51202/tcp # # HITT ENTRY
comms-logit 51203/tcp # # HITT ENTRY
comms-tradis 51204/tcp # # HITT ENTRY
comms-plamas 51205/tcp # # HITT ENTRY
comms-jcl 51207/tcp # # HITT ENTRY
comms-repman 51208/tcp # # HITT ENTRY
…and more…
Another way to find out the service name is to look it up in the applicable comms-ini file of the
application, as is shown in the following example:

> grep Communication asifix_mlat_comms_ini_techreplay01.use

open CHANNEL TelnetChannel TelnetServer comms-asx01 [Communication]
>
Where “comms-asx-01” indicates the service name.
For example: to monitor the comms channel of PLAMAS:

> telnet ip01 comms-plamas
Trying 10.89.1.51...
Connected to ip01.
*** Welcome to Comms Control and Monitoring ***
Connected via channel CommsChannel
>
The COMMS-monitor provides a help function, providing the syntax per command. Type ‘help’ to get a
command overview.
A comms-monitor session is terminated by typing <Ctrl> ] and subsequently ‘q’.
The comms-monitor knows 2 basic types of commands, show and monitor:

• Show gives the static definitions of messages, handlers, channels and filters.
• Monitor dynamically monitors the actual data.
When you enter a command, only the first 3 characters are required. This means that you can
abbreviate monitor message into mon mes.
Show
The show command gives static definitions. You can use for example show message (or sho mes)
to list all messages:
> show message *
messageInfo SystemTrackBatch attached in
messageInfo targHITTTrack attached in
messageInfo ReportMessage attached out
messageInfo IdentifyJourney attached in
messageInfo ExchangeIdent attached in
messageInfo UpdatePlan attached in
messageInfo AsciiMsg attached inout
messageInfo GuardSysTrackOn attached in
messageInfo ConnectionStatusReport attached inout
messageInfo StopTrack attached in
messageInfo OfmRegister attached out
messageInfo Plots attached in
messageInfo 1119 attached in
messageInfo 1116 notAttached _
messageInfo 1100 notAttached _
…and more…
This shows if messages are attached to a channel (or not) and the type of message (in, out or inout).
Note that some old-style messages (having a number like 1119 in stead of a name) are available (for
backwards compatibility). E.g. the message 1119 contains compressed object rings of radar video,
and message 1100 are plots.
To show a particular message or a group of messages

(e.g. for telnet dp01 comms-tradis):
> show message Rings shows attachment of the video rings message
> show message Plots shows attachment of the plots message
> show message SystemTrack shows attachment of the systemtrack
message
> show inbound shows attachment of all inbound messages
> show outbound shows attachment of all outbound messages

To show information about the channels:

> show channel *
channelInfo CommsChannel created attached connected in: 3 out: 5 sbuf: 0
channelInfo channelMsfBatch created attached connected in: 0 out: 0 sbuf: 0
channelInfo channelTfpEval created attached notConnected in: 0 out: 0 sbuf: 0
This shows if channels are connected or notconnected and the number of messages on the input or
output. When the sbuf-value is not zero, this indicates a comms-problem (congestion).
To show a particular channel:

> show channel targhittTracks01
channelInfo targhittTracks01[0] created attached connected in: 2496062 out: 0
sbuf: 0
channelInfo targhittTracks01[1] created attached connected in: 1 out: 0
sbuf: 0
This shows that the channel providing the targhittTracks01 (coming from TargHITT-application running
on CTP01) are received via the dual LAN connections [0] and [1].
Monitor
With the comms-monitor you can monitor specific messages, but you can also monitor which
messages are using a specific channel. The monitor command sends the required actual messages to
the display. For example:
To monitor a message:
> monitor message ConnectionStatusReport
outMessage ConnectionStatusReport via handler ConnectionStatusHandlerFpl
Header : ^M^M ConnectionStatusReport^L 16ÛT 1114010598.169^V 1ÊOH^^
outMessage ConnectionStatusReport via handler ConnectionStatusHandlerFpl
Header : ^M^M ConnectionStatusReport^L 16ÛT 1114010603.166^V 1ÊOH^^
This shows the type (in/out/inout), the message, the handler, the message length, and the time the
message is sent/received (expressed in seconds, msec since Jan-01-1970).
You can stop the periodic output by typing monitor stop.
To monitor a channel:
> monitor channel targhittTracks01
> inMessage TargHITTTrack via channel targhittTracks01[0]
header : ^M^M TargHITTTrack^L 383ÛT 1181223755.559^V 1ÊOH^^
inMessage TargHITTTrack via channel targhittTracks01[0]
inMessage TargHITTTrack via channel targhittTracks01[0]
4.2.4 Monitor Asterix

ASTERIX data (consisting of primary, secondary, combined, overview, sector message and north
messages) can be monitored on the LAN using the asxdmp utility. In that case ASTERIX is dumped in
a readable format to console output. Different datatypes from different sources can be checked. The
script monitor_asterix in the asifix-data directory is a script that creates the ini files automatically
for the different types of data streams and sources and then the asxdmp utility is started with this
generated ini file.
The command-line utility is called under the hittsys account from the directory dfsasxdata on an IP.
The syntax is:
monitor_asterix <DataType> <ChannelNumber>.
An overview of the predefined datatypes and channels is provided by calling the utility without any
arguments, like in the following example:

> monitor_asterix
Usage: /monitor_asterix <datatype> [<channelnr>]
DataType can be:

smrplots, approachplots, systemtracks, status, rdps
Channel number can be:
1 for rdp01 or ip01
2 for rdp02 or ip02
Examples
./monitor_asterix systemtracks 1
./monitor_asterix systemtracks 2
./monitor_asterix status
./monitor_asterix rdps
Note that not all datatypes may be available in ASTERIX format. The output is dumped to stdout in
a readable format. The output can be stopped by typing <Ctrl> c.
4.2.5 LISTEN-script
To monitor the current data on a channel, type (on any node) the following command (as user hittsys):
> cd /hittsys/testdata/listen
> listen
This gives the following help information:
Usage: listen <datatype>
Data type can be:

adsb : ADSB data from ADSBIN process
mlat : mlat sensor data from ASIFIX
rdps : RDPS sensor data from ASIFIX
targhittint : targhittint sensor data from TARGHITTINT
st : SystemTracks from TFP
idt : Plan depot data from TFP

conn : Connection status from TFP (as shown also on TRADIS)
limas : Limas output to Display
visib : Meteo/visibility data from HYMESET

alarm : Alarms from TFP
Example: listen idt
The output of a listen command can be stopped by entering <Ctrl> c
4.2.6 Tcpdump command

Tcpdump is a standard Linux facility to view data on the network. The tcpdump command can be
entered from any node that is connected to the network.
The tcpdump command shows the headers of packets on the network that match a boolean
expression, e.g. a port number.
The port number can be found using the command:

> grep /tcp /etc/services | grep 'HITT ENTRY'
A part of this output is shown here:

htp-srt 51000/tcp # # HITT ENTRY

htp-rings 51001/tcp # # HITT ENTRY

htp-plots 51002/tcp # # HITT ENTRY
srt-tfp 51003/tcp # # HITT ENTRY
srt-tracks 51004/tcp # # HITT ENTRY
aramis-srt 51005/tcp # # HITT ENTRY
dis-srt 51005/tcp # # HITT ENTRY
aramis-tfp 51006/tcp # # HITT ENTRY
dis-tfp 51006/tcp # # HITT ENTRY
tfp-tracks 51007/tcp # # HITT ENTRY
ati-tracks 51009/tcp # # HITT ENTRY
plamas-tfp 51011/tcp # # HITT ENTRY
plamas-dis 51012/tcp # # HITT ENTRY
…and more…
Note 1: The tcpdump-command must be entered as user root.

Note 2: Use in the grep command: "udp" instead of "tcp" to show the udp port numbers.
The following example of the tcpdump command shows the htp-rings messages on the network on
port number 51001:
# tcpdump port 51001
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on nic0, link-type EN10MB (Ethernet), capture size 96 bytes
12:48:06.782549 IP rdp03.hitt.asmgcs.34883 > rad03liveoperrings.htp-ring: UDP, length: 1426
….more….
28 packets captured
28 packets received by filter
0 packets dropped by kernel
dp01:~ #
Note that the port number can be replaced by the service-name, e.g.
# tcpdump port htp-rings
For a detailed description of tcpdump refer to the manual pages on the node by typing:
man tcpdump
4.2.7 Commslog
The commslog utility can be used to extract recorded traffic-data in recording-files on a RRP. The
commslog-tool is able to read/show and filter a logit-file or a set of logit-files.
Optionally, a selection file can be used, containing the messages, message fields and field criteria to
define what needs to be extracted.
The basic syntax of commslog is:

> commslog [-v] -showFiles <LogFile> [[-msg <MessageFile>] [-select
<SelectionFile>]]
Where:
-v : verbose option
<LogFile> : name of the logfile
<MessageFile> : name of the MIG message specification file
<SelectionFile> : name of the file with specifications of data
selections and output formats
Note that you can use wildcards to specify logfiles. When you specify 2006082810*.LOGIT you will
get all recording files between 10:00 and 10:59.

Note that logit-files are binary-files and only the message-header is in a readable format.
To show the contents of a logit-file:

• First change to the directory where the logit-file(s) are located:
rrp01> cd /logdisks/recordings/oper/20070525
• To show only the message headers of one logit-file:
rrp01> /hittsys/commstls/commslog –showFiles 200705250920.LOGIT
This command shows the message headers (each line is a message header) in terms of:
message-name, message-length, UTC-time stamp (in sec.msec since 1/1/1970),
version_number
Note that messages like ‘1116’ (Rings) are old-style messages, more recent messages have a
name instead of a number.
• To show also the message contents of one logit-file:
rrp01> /hittsys/commstls/commslog –v –showFiles 200705250920.LOGIT
The –v option (verbose) results in showing the message header and the contents of the
message. It is shown in a hex-dump format.
• To show the message contents of one logit-file in a more readable format (better than
hexdump):
-msg /hittsys/ifhitt/ifhitt_mig.ini
(for more info on the file ifhitt_mig.ini, see below)
By specifying the definition file of the messages (ifhitt_mig.ini), the message contents is
‘translated’ into a more readable format where possible.
• To show the message contents of only a limited/predefined set of messages of one logit-file:
First create a file specifying those messages that must be shown. In the example below a file
/tmp/myselectfile is created.

-msg /hittsys/ifhitt/ifhitt_mig.ini -select /tmp/myselectfile
(for more info on the /tmp/myselectfile, see below)
By specifying the selection-file, only limited information is selected/filtered out of the logit-file.
Details of the message-format (in the ifhitt_mig.ini file):

rrp01> view /hittsys/ifhitt/ifhitt_mig.ini
and search for the section [SystemTrack] (by entering /\[SystemTrack]
This shows e.g.
- ifhitt yes meaning the SystemTrack is in the ifhitt-format
- a fixed part meaning the SystemTrack-message always contains x-pos, y-pos,
orientation, length, breadth, status, …
- an optional part e.g. a plan may be in the SystemTrack-message
Details of the selection file (/tmp/myselectfile file):

For more info on what can be specified in the selection file refer to the examples in the directory
/hittsys/testdata/listen (select_appplot.ini and select_systemtrack.ini).
Example 1: To show only the SystemTrack-messages :

[GeneralFormat]
showCommsHeader true
showMessageName false
showTimestamp timeSpec
formatType multiLine ;or oneLine
[SelectedMessages]
include message SystemTrack
Example 2: To show only the SystemTrack-messages in a specific format:

[GeneralFormat]
showCommsHeader false
formatType oneLine ;or multiLine
[SelectedMessages]
include message SystemTrack SelectSystemTrack Format
[SpecificFormat]
Format “Aircraft” elements trackNumber xPosition yPosition
[SelectSystemTrack]
trackNumber == 716
Example 3: To show only the DepotPlansMod-messages:

[GeneralFormat]
showCommsHeader false
;formatType oneLine ;default is multiLine
[SelectedMessages]
include message DepotPlansMod
When running:
rrp01> /hittsys/commstls/commslog –v –showFiles 200705250920.LOGIT -
msg /hittsys/ifhitt_mig.ini -select /tmp/myselectfile
this shows all depotplan-messages in a readable format.
Or,
rrp01> /hittsys/commstls/commslog –v –showFiles 200705250920.LOGIT -
msg /hittsys/ifhitt_mig.ini -select /tmp/myselectfile | grep callsign
this shows only the lines that contain "callsign"
Or,
-msg /hittsys/ifhitt_mig.ini -select /tmp/myselectfile >
my_outputfile
this redirects the output to the file "my_outputfile".
4.2.8 Coordinate Converter (COCO)

The Coordinate Converter (coco) tool is used to convert coordinates in different projection and date to
a systemcoordinate or to a coordinate in another projection/datum system.
The type of conversion is defined in the file cocodata/coco.ini.
The coordinates to convert are put in the file cocodata/convertpoints.ini.

If this parameter file is changed a configure needs to be performed for the cocodata directory of the
node (see G_3.3: Partial configure).
The cocodata configure results in the file cocodata/use/result.use in which the converted
coordinates are placed.
4.2.9 Memory stick / USB disk

A USB memory stick can be used to transfer files from/to the system. A memory stick is mounted in
the directory /media.
Note that in LINUX this is a hot plug-able device and no special action is needed to disconnect the
memory stick.

FAULT FINDING
5. FAULT FINDING
Fault finding or troubleshooting is a structured approach to find the cause of an error. It is important to develop a structural approach, because fault finding is
usually carried out in stressful circumstances.
Fault finding is based on the rule that every (visible) error or performance degradation is based by a certain cause. It is necessary to check this cause and to
take corrective action.
You should always check local controller settings before going into a thorough analysis.
Errors often cascade, which means that one error may cause other errors to be generated.
You should keep track of your checks and look for unexpected values or changes. No absolute values can be given for which processor load, memory or disk
usages are critical. Abrupt changes in any of these values, however, usually indicate a problem and require further investigation.
Table 14 shows a list of possible problems about video and tracks, together with one or more possible causes. Each cause can be checked. If the actual
cause has been determined, the corresponding action should be taken to correct the problem. The column 'Described in' refers to the paragraph in this
document that describes the action or procedure or to an external document, by means of a reference identification.
Problem Cause Check Action Procedure

No replay possible Minutes-files unavailable Availability of minute files on Restore recording files G_6: Restoring archived data (p.
recording directory 98)
RRP not running Check on CMS or by (Re)start the RRP C_1: Starting/Stopping/Rebooting
attempting to remote login Nodes (p. 133)
No traffic display on one Application on this DP Check state of DP and state of (Re)start TRADIS and/or DP Appendix: system control (CMS
DP stopped TRADIS with CMS portal)
Impossible to close TRAMON has stopped Status of TRAMON with CMS (Re)start TRAMON or IP Appendix: system control (CMS
segments portal)
No tracks and no video No connection between Check network connections Restore network cable(s) W_2: (p. 135)
at one DP DP and the LAN and check connectivity using
ping
Video and tracks are Swap of dual network Check network cabling Connect network cable(s) Refer to Installation document.
shown normally, but cables between DP and between DP and the LAN. according to installation
some commands (like the LAN. document.
identification) are not
possible on a DP.
No tracks, but video on (Applications on) CTP Check CTP and application (Re)start applications or Appendix: system control (CMS
all DP’s not running status with CMS CTP(s) portal)

FAULT FINDING
Time Synchronization Check time synchronization Correct time synchronization W_5: Check time synchronization
between CTP and (p. 141)
RDP’s not correct
No tracks and video on Antenna stopped Check antenna status and the In case of a serious antenna TERMA-SMR
all DP’s event log. problem refer to maintenance
documentation of the
When remote control antenna. After correction
and monitoring is not possible, switch the antenna on using
the radar is probable (locally) radar control.
put in
'local mode'
Radar TX/RX Check radar status and the In case of a serious radar TERMA-SMR
switched off event log. problem refer to maintenance
documentation of the radar.
When remote control and After correction switch the
monitoring is not possible, the radar on using radar control
radar is probable (locally) put program.
in 'local mode'.
No RDP’ s present or Check RDP status with CMS (Re)start the RDP’s Appendix: system control (CMS
applications on RDP’ s portal)
not running
Video and tracks Time synchronization Check time synchronization Correct time synchronization W_5: Check time synchronization
are not aligned between CTP and RDP’ (p. 141)
s not correct
C_3: Correct time synchronization
(p. 133)
Radar can not be Communication Restart RACOMS application Appendix: system control (CMS
remote controlled between radar and and try again. portal)
RACOMS disturbed
If no success [TERMA-SMR]
restart the communication on
the RxTx by resetting the
RxTx. If communication
still fails, check
communication
settings on RxTx

FAULT FINDING

Radar switched to Switch off the local mode TERMA-SMR
LOCAL MODE
No video in areas where The grass/mask map in Display grass/mask maps on Update grass/mask map(s) C_5: Modify SMR maps (p. 134)
it is desired or video in the video extractor is not TRADIS to check boundaries and configure the video
areas where it is not correct extractors
desired
No tracks in areas The track map in the Display track maps on TRADIS Update track map(s) and C_5: Modify SMR maps (p. 134)
where it is desired or video extractor is not to check boundaries configure the video
tracks in areas where it correct extractors
is not desired
Radar status alarms at radar problem Check radar status and the In case of a serious radar [TERMA-SMR]
TRADIS event log. problem refer to maintenance
documentation of the
When remote control and antenna.
monitoring is not possible, the After correction switch the
radar is probably (locally) put antenna on using radar
in 'local mode'. control.
Video and/or tracks Change of radar Observe individual track and Tune the radar picture M_1: Check (and adapt) Video
incorrectly oriented (e.g. magnetron corresponding video Alignment (p. 143)
changes)
No approach tracks or Interface connections Interface status of RDPS ping W_2: (p. 135)
no TTT window for with RDPS lost to check connectivity
approaching aircraft
Table 14: Fault Finding for video and tracking

FAULT FINDING

No flight plans on TRADIS Interface connections lost Interface status of FPL ping G_9: Check network connectivity (p.
to check connectivity 101)
W_3: Check External Interface(p.
136)
(Applications on IPs not Check IPs with CMS (Re)start IPs Appendix: system control (CMS
running) portal)
No automatic identification of Interface connections with Interface status of RDPS G_9: Check network connectivity (p.
inbound flights RDPS lost ping to check connectivity 101)
W_3: Check External Interface(p.
136)
Flight Plan status alarm at Interface connection lost Interface status of FPL ping G_9: Check network connectivity (p.
TRADIS to check connectivity 101)
Table 15: Fault Finding for identification

GENERAL MAINTENANCE
6. GENERAL MAINTENANCE
6.1 Basic procedures
G_1: Logging in on nodes

On all nodes the user can log in under the account of hittsys.
• On the CMSP nodes this can be done on the connected monitor.
• On the operational positions (DPs) it is not possible to login in as long as the TRADIS
application is running. These nodes can be accessed via remote login.
• Some nodes are locally accessible via a Rack Manager. The KVM switch is connected in the
system according to the following diagram. The KVM switch can be connected to a maximum
of 8 (or 16) nodes.
Figure 24: Connection diagram Rack Manager
The Rack Manager can be switched to one of the connected nodes by either using the pushbuttons 1
to 8 (or 16), or by using the ‘KVM-OSD’-button on the keyboard.
Most activities can be done as user maintenance or hittsys . The passwords for these usernames are
specified in [ID].
The user root is only required for running the ‘configure’ script and for mounting filesystems.
Logging in:
• Console login: type the username and password at the console login. A console login on an
operational working position as operator or supervisor automatically starts TRADIS.
• Remote login: use the secure shell (ssh <nodename>) command to login remote, as shown
in the following example:
> ssh dp02
*** This is a secure connection ***
Last login: Wed Nov 8 14:13:40 2006 from console
Welcome to the A3000 System.....
>
G_2: Distribute changes with autochanges

This procedure describes how to use the auto/changes -mechanism.
See also 2.3.6

GENERAL MAINTENANCE
System Changes.
Step 1: Make the change locally

You can make and test a change on a local node, e.g. modify an xml-file.
Step 2: Copy the change

Copy the change to the corresponding changes-directory in /auto/changes/patches, but be
aware that this needs to be done in the correct subdirectory.
For example, when you have changed a file in the directory tradisdata/xml of a node, go to the
/auto/changes/patches and go to that directory (if not present, create the directory):
cd /auto/changes/patches/tradisdata/xml
The copy command would look like this:

cp -p /hittsys/tradisdata/xml/<myfile> .
Now the changed file is accessible through /auto/changes/patches for all other nodes.
Step 3: Configure relevant nodes

Now, consider which nodes are using the changed file, see Table 9 List of configuration files and
maps.
Run configure (See G_3: Running configure) on each of these nodes and answer ‘y’ on the question
whether to copy the new file from /auto/changes/patches. A copy means that the local file is
renamed and the new file is copied. The original file will be renamed to the filename extended with a
date-time.org.
Example: When /auto/changes/patches contains a new file tradisdata/xml/<myfile>, the
original file will be renamed as: tradisdata/xml/<myfile>.<date>-<time>.org
G_3: Running configure

The script "configure" in the directory hittsys is used to create the correct files and variables that are
used by the different parts of the system. In these files the correct paths are set and files copied to
their destination. Normally this configure script is only used during reinstallation of the software on a
node in order to create all files necessary for the applications. There are two main types of configure:
the node configure and the hittsys configure.
See also 2.3.2.5 Application Configuration.
G_3.1: Node configure

All configure scripts available within the applications of this node will be executed and applications will
be stopped on this node. The configure script checks for changes on the autochanges-directory,
translates ini-files into use-files and subsequently restarts the HITT-applications on the node.
Be aware that configure restarts the node, which may influence the behaviour of the system.
A node configure is run in the following steps:
Step 1: Login as root

Configure must be run as root.
> su - (do not forget the minus)
password:
#
Step 2: Run configure

Configure is run from the directory /hittsys, which is not the home-directory of root. Therefore the
following commands must be executed:
# cd /hittsys
# configure
<configure messages>
Now the configure script will prompt for all differences between the node’s own directories and the
autochanges-directories. For each file you can accept the changed file (‘y’), reject the changed file
(‘n’), accept all changed files (‘all’) or view the differences between the local file and the file on

GENERAL MAINTENANCE
autochanges (‘s’). If you reject a change, it will remain in the autochanges-directory. This means that
you will be prompted again when you run configure again later. Note that configure only checks if files
are different. It will not take changed dates into account.
After handling all changes, the configure script will run and it will produce output to the screen. At the
end of the output you will see a log-filename with the result of the configure.
Step 3: Check the node

Configure will regenerate use-files and it will restart the node. Check that the node works as expected.
Check the configure log-file for errors after configure has completed.
G_3.2: Hittsys configure

When a small change is made and a full node restart is not wanted, you can use the hittsys configure.
This will not stop the applications and only the application files (located in /hittsys) are configured (the
system files like /etc/hosts, /etc/services, etc. will not be configured).
Step 1: Login as hittsys

> su - hittsys (do not forget the minus)
password:
>

> configure
<configure messages>
Now the configure script will prompt for all differences between the node’s own directories and the
autochanges-directories. For each file you can accept the changed file (‘y’), reject the changed file
(‘n’), accept all changed files (‘all’) or view the differences between the local file and the file on
autochanges (‘s’). If you reject a change, it will remain in the autochanges-directory. This means that
you will be prompted again when you run configure again later. Note that configure only checks if files
are different. It will not take changed dates into account.
After handling all changes, the configure script will run and it will produce output to the screen. At the
end of the output you will see a log-filename with the result of the configure.
Step 3: Check the node

The Hittsys onfigure will regenerate use-files but and it does not stop the applications.
After the configure, only the applicable application(s) must be stopped and restarted manually using
CMS or by killing and restarting the applications(s).
Check the log-files for errors after configure has completed.
G_3.3: Partial configure

The node configure (see G_3.1: Node configure) and the hittsys configure (see G_3.2: Hittsys
configure) can be limited to a given set of directories by setting the CONFIGURE_DIR variable.
For example the command:
export CONFIGURE_DIR="repmandata tradisdata"
entered before the configure command in step 2 will result in only executing the configure files of
repmandata and tradisdata.
G_4: Determine the mode of a node

During a test period you may want to check the mode of a node (e.g. on the test bench). You can do
this by checking the mode of the specific node in CMS.
Alternatively, you can use the following command:
ctp01:> ps -ef | grep TFP

hittsys 00:15:00 TFP -ini /hittsys/tfpdata/use/tfp_ini_oper.use
-comms /hittsys/tfpdata/use/tfp_comms_ini_oper.use...
>
In this output you can see that the node is in operational mode.

GENERAL MAINTENANCE
Note that if a node has been stopped (e.g. ctp stop), then the mode can not be determined in this way.
Then use the two commands below to determine the mode of a node:
> su – hittsys
> . ./settings.use (note the first dot!)
> env | grep –i mode
ALL_USED_MODES=oper test techreplay
DEFAULT_OPERATING_MODE=oper
OPERATING_MODE=oper
>
G_5: Changing the mode of a node

A node can be in operational mode or technical replay mode.
A mode can be chosen at the startup of a node. If no mode is specified at startup, the node will start in
operational mode. The general command to start, stop or restart a node or a process is
<node-type> start | stop | restart [process <name>]
This is shown in the following example (as user hittsys):
> dp restart
Stop node request in progress ...
The system is going to be stopped
Start node request in progress ..
The system is not running. Trying to start it
>
When a node is already started, its mode can be changed with the command
<node-type> change <mode> where mode can be oper (operational mode) or techreplay (for technical
replay). An example of this command (as user hittsys):
> dp change techreplay

Change node request
Stopping JCL (this could take a while) done
Operating mode set to techreplay
Starting JCL done
>
6.2 Replay of archived data
G_6: Restoring archived data

The Replayer can replay data that is on disk. The Replayer can not replay from tape. Therefore
archived data must be copied (restored) first from tape to disk. Restoring from tape to disk is done by
using the ARCHIT GUI.
Warning: before starting restore, make sure that the tape is write protected, otherwise it is
possible that archive starts automatically to re-use your tape for archiving of the current recordings
after you put in the tape and before you start restore.
When the ARCHIT GUI has started and a tape is inserted, ARCHIT automatically reads the tape
header and displays it in the Status bar (this may take a few minutes).
After double clicking the corresponding tape header in the tape list, the session list is shown.
When the tape is not in the tape list you can use the Scan button to retrieve the tape info from the tape
(this can take a long time).
After selecting one or more sessions in the session list, the option 'Restore' can be chosen. When
selecting OK in the restore dialogue, the recordings are being restored from tape to the 'restored'
directory on disk. By using the restore command, it is possible to copy sessions back from tape to disk
so they can be used for replay. The restore date is used to check if the correct tape has been inserted.

GENERAL MAINTENANCE
Figure 25: ARCHIT Dialogue

See Appendix: Archiving data (ARCHIT) for more information about ARCHIT.
G_7: Setting up an operational replay session

An operational Replay reconstructs the traffic (and the traffic display) of the moment at which it was
recorded.
Make sure that the node, where the replay will be started, and the desired RRP are running in
operational mode.
You will do this in the following steps:
Step 1: Start the Replay GUI

Start the Replay GUI (Replay Control) from the KDE / Hitt applications menu of the node, where the
replay will be started. See Appendix: replay Control (Replay GUI) on how to use the Replay GUI.
Step 2: Make sure recording files are present

The replayer will look for recording files in the directory /logdisks/recordings/oper or in /
logdisks/restored/oper. Verify that the period you would like to replay is present. You can do
this:
• by checking the contents of the directories (by using ls), or
• by clicking the Refresh button in the replayGUI, refreshing the available sessions shown in the
session list of the ReplayGUI.
If the required recording files are not present (i.e. not recently recorded), then look for these files on
the archive tapes and restore them from tape to disk (see G_6: Restoring archived data or Appendix:
Archiving data (ARCHIT)).

GENERAL MAINTENANCE
Step 3: Start TRADIS-replay

Start the TRADIS-replay application (Replay Traffic Display) from the KDE / Hitt applications menu of
the node, where the replay will be started.
Step 4: Start the replayer

In the replayGUI, select a replay session from the list (or manually enter a start date and start time)
and start the replayer.
Step 5: Select type of replay

You can choose between an active or passive replay:
• active replay is used to view the replay and be able to manipulate the presentation manually
(e.g. select range, zoom, etc.). Active replay is the default mode so nothing has to be selected
on the TRADIS replay menu.
• passive replay is used to watch the replay of one of the working positions. For passive replay,
select from the TRADIS replay menu the working position you want to watch (DP01, DP02,
etc.)
Note: The resolution of the monitor on the replay position must be the same as that of the working
position to be replayed in order to get exactly the same traffic view.
G_8: Setting up a technical replay session

During technical replay you will replay the inputs of the applications. You will typically do this to verify
changes in settings or maps.
Technical replay requires that nodes are switched into technical replay mode , which means that you
require at least one RRP (for the replayer), one CTP (for the tracker), one IP (for the interface
applications) the CMSP (for the replay GUI) and one node running TRADIS (could be the CMSP or a
separate DP).
The nodes that are in technical replay mode will ‘see’ each other on the network. The nodes that are in
technical replay are 'seperated' from the nodes that are in operational mode by using a different set of
data streams.
Step 1: Switch nodes into technical replay mode

Decide which nodes will participate in the technical replay. Login as hittsys and switch these nodes
into technical replay with the JCL-command: <node-type> change techreplay.
Step 2: Start the Replay GUI

Start the Replay GUI (Replay Control) from the KDE / Hitt applications menu of the CMSP.
Step 3: Make sure recording files are present

The replayer will look for recording files in the directory /logdisks/recordings/techreplay or
in /logdisks/restored. You can make a new directory on /logdisks/restored and store the
LOGIT files in this directory. This directory will also be present/visible in the session list of the replay
GUI.
Verify that the period you would like to replay is present. You can do this:
• by checking the contents of the directories (by using ls), or
• by clicking the Refresh button in the replayGUI, refreshing the available sessions shown in the
session list of the ReplayGUI.
If the required recording files are not present (i.e. not recently recorded), then look for these files on
the archive tapes and restore them from tape to disk (see Appendix: Archiving data (ARCHIT)).
Step 4: Start TRADIS

Start TRADIS (not in replay mode, but in normal operational mode) from the KDE / Hitt applications
menu of the CMSP.
Step 5: Start the replayer

Now select a replay session from the list or manually enter a start date and time and start the replayer.
See Appendix: replay Control (Replay GUI) on how to use the Replay GUI.

GENERAL MAINTENANCE
6.3 Network connections
G_9: Check network connectivity

The network connectivity can be easily checked by verifying that all nodes and applications are green
in the CMS-window.
When working remote a quick check on the network-connections can be done by the ping command.
This is done from the Linux command line.
Besides 'ping', the 'traceroute' and 'netstat' commands are useful. A number of variations (using
different arguments) are shown, used to get (step by step) more detailed information about the status
of the network.
For details about the commands, refer to the on-line documents ('manual pages').
Ping
The ping command checks if two hosts are connected by sending a default message of 56 data bytes
(The icmp-header of 8 bytes is added to this). The general format is ping <hostname> or ping
<ipaddress>.
Ping produces repetitive output, which is stopped by typing <Ctrl>c.
If you only want to check if a host is present use the option '-c 5' between ping and host/ip-address.
The command will then stop automatically after trying five times.
You can also use the argument ‘-R’ which shows the hosts/nodes that are passed by on the way to or
from the remote host. You can use this command to check the route-table.
You can choose a different message size with ‘-s <size>’ argument. You would use this command
to measure the throughput in case of a dialup network connection (less than 10 MBit/sec).
Traceroute
The traceroute command shows the nodes that are passed by on the way to a remote host. The route
is divided into steps, so this command can be used to discover which parts of a routed network are not
reached. If a node can not be reached, an '!N' is reported, instead of the time of delay.
Make sure to be logged in as root and use the command
# traceroute <remote host>
or
# traceroute <ip-address>
Netstat
Without any parameters, netstat gives an overview of the TCP gate-connections which are present or
constructed and the UDP gates to which is listened by any process. This command can be used by
both protocols so it's possible to display on which gate a report is expected. Netstat can accept a
number of arguments, which are shown here.
> netstat –a
Displays all, LISTEN state-gates are displayed too.
> netstat –i
Displays the state of an interface in terms of received messages and sends and displays the errors
which are discovered during receiving. Collisions are also displayed. The number of collisions and
errors must be small in an operational system.
> netstat –r
Displays the routing-table of the host.
In theory this is not only the static routes which are logged in /etc/sysconfig/network/routes
(and which can be checked by means of inspecting this file).
In an operational system, there must be no routes, other than logged in
/etc/sysconfig/network/routes.
The only route that is not in /etc/sysconfig/network/routes (but still in the listing of netstat)
is the one which is used for the HITT-network.
Use netstat -nr to prevent the networks and hosts in the listing from being translated to names
(and thus are displayed in a numerical form (dot notation)).

GENERAL MAINTENANCE
> netstat –s
Displays statistics per protocol. The used texts are describing statistics for each used protocol (IP,
UDP, TCP).

ADAPTIVE MAINTENANCE
7. ADAPTIVE MAINTENANCE
Adaptive maintenance is defined as the activities which need to be performed when the system
behaviour has to be adapted due to other circumstances (e.g. snow on the runway edges) or changed
requirements from the user (e.g. new maps or colour changes). Refer to Table 9: List of configuration
files and maps for the physical location of the files to be adapted.
The following adaptive maintenance occurrences are identified:

• Radar video settings:
• Adapt the masking maps
The masking maps for the movement area need to be updated when the situation on the
airport is changing, e.g. a taxiway is added or moved, new asphalt is created, or buildings or
other static objects are created on the airport.
• Adapt the grass maps
The grass maps (masking map for the non-movement area) needs to be updated when
buildings or other static objects are created in the non-movement area, or when the non-
movement area of the airfield is extended.
• Adapt the track maps
Track map needs to be updated, when static objects on the movement area are added or
deleted. Track maps is also updated in wintertime when heaps of snow are concentrated on
e.g. edges of taxiways or runways.
• Tracking settings:
• Adapt the coverage maps
• Adapt the semi-coverage maps
• Adapt the shadowing maps
• Adapt the non-automatic initiation maps
• Adapt the blanking maps
• Adapt the runway areas map
• Identification settings:
• Adapt IDT areas
When there are areas known that identified tracks often go lost e.g. due to obscuring an IDT
area can be created, together with a depot plan list. The operational user can easily re-identify
when the track is visible again.
• Alerting settings:
• Adapt the presentation of the alerts.
• Adapt Area Penetration monitoring (APM) settings
The APM map need to be changed when the operational user requires a new APM area.
The APM parameters need to be changed when operational user requires adapted prediction
times for warnings and alarms.
• Adapt Runway Incursion Monitoring (RIM) settings
The RIM map needs to be changed when a new runway is created or when the approach
procedure is changed in such a way that the approach area is changed. The RIM map can
also be changed when the operational user requires another geographical definition of the
runway (e.g. runway starts at a stopbar instead of the edge of the asphalt).
The RIM parameters need to be changed when the operational user requires other time
parameters for creating warnings and alarms (e.g. when the separation on landing aircraft is
allowed to be smaller).
• Adapt SID / Runway settings
• Adapt Taxiway Collision Monitoring (TCM) settings
The TCM map needs to be changed if the layout of the taxiway layout is changed.
The TCM parameters need to be changed when the operational user requires other warning
and alarm prediction times in either normal of low visibility.
• Adapt Restriction Violation Monitoring (RVM) settings
• Stopbar settings
• Pushback area settings
• TRADIS settings:
• Adapt traffic settings
• Adapt display settings

• Adapt map settings

• SICO settings
• CMS settings
7.1 Radar video settings
A_1.1: Maintain mask maps

Mask areas (MASK 0x)are maintained at the maintenance position using the map-edit tool in TRADIS,
see Appendix: Traffic Display (TRADIS).
When the change is completed, copy the changed map (maskdata/vpmask0x.cgm) to
/auto/changes/patches and configure the appropriate nodes (see procedure G_2: Distribute
changes with autochanges).
Refer to 2.2.3.2 for a description of this map.
A_1.2: Maintain grass maps

Grass areas (GRASS 0x)are maintained at the maintenance position using the map-edit tool in
TRADIS, see Appendix: Traffic Display (TRADIS).
When the change is completed, copy the changed map (maskdata/vpgrass0x.cgm) to
A_1.3: Maintain track maps

Track areas (TRACK 0x)are maintained at the maintenance position using the map-edit tool in
When the change is completed, copy the changed map (maskdata/vptrack0x.cgm) to
7.2 Tracking settings
A_2: Maintain coverage maps

Coverage areas (TARGHITT COVERAGE 0x) are maintained at the maintenance position using the
map-edit tool in TRADIS, see Appendix: Traffic Display (TRADIS).
When the change is completed, copy the changed map
(mapdata/targhitt_coverage_areas_rad0x.cgm) to /auto/changes/patches and
configure the appropriate nodes (see procedure G_2: Distribute changes with autochanges).
Refer to 2.2.4.2.2 for a description of this map.
A_3: Maintain semi-coverage areas

Semi-coverage areas (TARGHITT SEMI COVERAGE 0x)are maintained at the maintenance position
using the map-edit tool in TRADIS, see Appendix: Traffic Display (TRADIS).
(mapdata/targhitt_semi_coverage_areas_rad0x.cgm) to /auto/changes/patches and
A_4: Maintain shadowing areas

Shadowing areas (TARGHITT SHADOW 0x) are maintained at the maintenance position using the
map-edit tool in TRADIS, see Appendix: Traffic Display (TRADIS).
(mapdata/targhitt_shadow_areas_rad0x.cgm) to /auto/changes/patches and configure
the appropriate nodes (see procedure G_2: Distribute changes with autochanges).

A_5: Maintain Non-Automatic Initiation areas

NAI areas (TRACK NON INITIATION) are maintained at the maintenance position using the map-edit
tool in TRADIS, see Appendix: Traffic Display (TRADIS).
(mapdata/targhittint_system_nai_areas.cgm) to /auto/changes/patches and configure
A_6: Maintain blanking areas

Blanking areas (TRACK BLANKING) are maintained at the maintenance position using the map-edit
tool in TRADIS, see Appendix: Traffic Display (TRADIS).
When the change is completed, copy the changed map (mapdata/
targhittint_system_blanking_areas.cgm) to /auto/changes/patches and configure the appropriate
nodes (see procedure G_2: Distribute changes with autochanges).
A_7: Maintain RWY areas

RWY areas (RUNWAYS) are maintained at the maintenance position using the map-edit tool in
When the change is completed, copy the changed map (mapdata/targhitt_runway_areas.cgm)
to /auto/changes/patches and configure the appropriate nodes (see procedure G_2: Distribute
A_7.1: RDPS coverage areas

RDPS coverage areas (COVERAGE RDPS) define the coverage aeas of the approach radar.
RDPS tracks outside this area are not processed.
The COVERAGE RDPS map can be modified at the maintenance position using the map-edit tool in
Optionally a minimum and maximum height can be provided. Using the following APPLDATA:
APPLDATA FLTAREA MINIMUMHEIGHT <height in flightlevels>
APPLDATA FLTAREA MAXIMUMHEIGHT <height in flightlevels>
When the change is completed, copy the changed map (mapdata/rdps_coverage.cgm) to
7.3 Identification settings
A_8: Maintain IDT areas

When an identified track is lost inside an IDT Area, its plan will be placed in the COAST list, from
where it can be used for manual identification. The IDT Area is the collection of all polygons in the IDT
map.
The IDT Areas (IDT) map can be modified at the maintenance position using the map-edit tool in
When the change is completed, copy the changed map (mapdata/idtareas.cgm) to
/auto/changes/patches/mapdata and configure the appropriate nodes (see procedure G_2:
Distribute changes with autochanges).

A_8.1: Maintain plan distribution

Distribution of plans to the display is based on time windows. These windows are specified in the idt.ini
file, which is located at the CTP nodes in the directory tfpdata. In the table below the adjustable
parameters for the time-windows are listed.
For all the parameters, the following rule applies:

When for a plan the <Time field> incremented with the value of the corresponding parameter results in
a time in the past with respect to the current system time (in other words: when the Time field is older
than the corresponding DeletionDelay parameter), this will trigger the system to delete the
corresponding plan. <Time field> can be one of ATA, ETA, ATD, ETD, EOBT, AOBT or EOBT.
Parameter name Description Value

SP_AtaDeletionDelay Time field ATA in an arrival plan 15
SP_EtaDeletionDelay Time field ETA in an arrival plan 90
SP_AtdDeletionDelay Time field ATD in a departure plan 0
SP_EtdDeletionDelay Time field ETD in a departure plan 90
SP_EobtDeletionDelay Time field EOBT in a departure plan 90
SP_AobtDeletionDelay Time field AOBT in a departure plan 60
SP_TowEobtDeletionDelay Time field EOBT in a tow field 10
Table 16 Plan distribution parameters
7.4 Alert settings
7.4.1 Alert presentation

The presentation of alerts is determined in TRADIS.
A_9.1: Maintain alert strings

When an alert occurs the alert can be shown in the the label, the lists and in the alert list
The alert strings are defined in file: alerting.xml
For a description of this files refer to Appendix: XML files.
This file holds the alerting definition for several alerts as specified by: ‘alertInfo id’.
The following alerts are available (the mnemonic refers to the alertInfo id):
• RWM, RunWay incursion
• CAM, Closed runway Approach
• CDM, Closed runway Departure
• RDM, Runway Direction conflict (landing or departure)
• ORM, Static Object on Runway
• ARM, Assigned Runway mismatch
• DAM, Departure Aborted
• APM, Area Penetration
• SVM, Stopbar Violation
• TCM, Taxiway Collision
• SCM, Same Callsign
• SPM, Same Plan
• MCevent, Multiple flight Plan
• RVM, Restriction Violation
• CONN_STATUS, Connection status error
To change the alert strings change the following items for the applicable alert:
Item name Description

alert defines the alert message that appears in the alerts list. (%1
defines variables, typically it is replaced by the callsign)
typeInfo defines the alert abbreviation that is used in the track label

When the change is completed, copy the file to /auto/changes/patches and configure the appropriate
nodes (see procedure G_2: Distribute changes with autochanges).
A_9.2: Maintain alert presentation

Alerts are presented in the label and optionally in the alert list.
Whether the dedicated alert must be shown in the alert list is defined by the 'onlyOnObj' attribute.
Edit alerting.xml and set the attribute 'onlyOnObj' as follows:
• true, alert is only shown in the label
• false, alert is shown in both the label and the alert list.
The default value is: false.
When the change is completed, copy the file to /auto/changes/patches and configure the
appropriate nodes (see procedure G_2: Distribute changes with autochanges).
A_9.3: Maintain alert sounds

An alert can optionally be accompanied by an audible.
This section shows how to connect audible to an alert and to select the audible that must be sounded
for a dedicated alert.
The alerts are specifed in file: alerting.xml.

The audibles are defined in file: alertoutputs.xml
The relation between the alert and the audible is defined in file: alertinfooutp.xml.
For a description of these files refer to Appendix: XML files.
The sound scripts define the sound file to be played.

The sound scripts that are currenly available are defined in: /hittsys/tradisdata/wav and
/hittsys/tradis/wav. But also new sound scripts can be made. New sound script should be
created in: /hittsys/tradisdata/wav and should be in wav format.
To test the sound of a wav file enter: /usr/bin/aplay <name_of_sound_file>
When the change is completed, copy the file(s) to /auto/changes/patches and configure the
A_10: Maintain application parameters in maps

Application parameters defined in maps for areas and lines must be put in the so called APPLDATA
section of that map object. APPLDATA can be maintained by using a text editor like vi or by using the
map-edit tool in TRADIS (see Appendix: Traffic Display (TRADIS)). The editing of the dimensions of
the areas and lines are not described here, see the following chapter for that.
Here follows an example of a cgm file specifying a line and an area containing APPLDATA:
APPLDATA LINE LINEID 100 "L1";

APPLDATA LINE REFPOS (0.0, 15.0);
APPLDATA LINE SENDTOREFPASSINGS TRUE;
APPLDATA LINE SENDFROMREFPASSINGS FALSE;
APPLDATA LINE SENDTOSTRING "to Tower";
APPLDATA LINE SENDFROMSTRING "to Runway";
APPLDATA LINE LEXREC 5;
APPLDATA LINE BREREC 10;
LINE
(-1493.64, -1564.36)
(-1525.04, -1607.18);
APPLDATA AREA AREAID 1 "A1";

POLYGON
(-1428.07, -1713.84)
(-1054.36, -1304.78)

(-852.35, -1486.58)
(-1236.16, -1895.65);
Below the several APPLDATA parameters are explained.
Line
The APPLDATA of a line specifies the line id and the line name like this:
Note: the ids used for areas and lines must be unique. By default the line id range starts at
100.
Some extra APPLDATA parameters can be specified like:
- a reference position (REFPOS) which is used to determine the direction in which a line is
crossed. This position is expressed in meters from the ARP. It is convenient to use a
reference point that forms a large angle with the defined line.
Figure 26 shows the line to a given reference position (for this example from the line 05L to
the reference position at 8000,8000), indicating the line crossing direction towards the
reference point (SENDTOREFPASSINGS).
- the directions in which the line will be guarded (default is TRUE for both directions) for line
crossings (SENDTOREFPASSINGS and SENDFROMREFPASSINGS)
- per direction a direction description text which will be put in the line crossing event
(SENDTOSTRING and SENDFROMSTRING)
- the line extension on both sides of the line (LEXREC) where objects will be watched
- the breadth of the rectangle (BREREC) where objects will be watched
Area
The APPLDATA of an area specifies the area id and the area name
Note: the ids used for areas and lines must be unique. By default the area id range starts at 1.
Edit APPLDATA using vi:

When vi is used to edit the map, the APPLDATA parameters look the same as the given examples.
Application data is defined before the Line or Polygon (area) definition in the cgm-file. If you have
added a new area by using the map-edit tool in TRADIS, it will be added at the end of the file but it
does not contain APPLDATA.
When you have added a new area or line, it is convenient to copy the APPLDATA-lines from another
area or line and then modify the id and the name of the area or line. For alerting areas and lines it is
important to enter a unique area-id or line-id and a name. It is good practice to increment the area-id
or line-id from the previous area or line.
Edit APPLDATA using the TRADIS map-edit tool:

Select the map you want to alter the parameters from (e.g. ALERTING). In the map-edit toolbar, click
on the “Edit object or map properties” button and then select the alert line or alert area on the map.
Now a window should appear showing the APPLDATA parameters, these parameters can be altered.
Note that the keyword "APPLDATA" and the semicolon (;) at the end of the line must not be entered in
the appldata window.
When the change is completed, copy the changed map (e.g. mapdata/alrareas.cgm) to

Figure 26: Line to Reference Position
7.4.2 APM settings
A_11: Maintain APM settings

The APM function generates an alert if a track enters a restricted area. You can add or modify APM
areas as follows.
A_11.1: Edit APM Area(s)

The map that is used for APM contains areas and lines (used by other alerting functions). An area is
defined by a polygon (area) and specific attributes (APPLDATA), such as an identification number and
a name. The polygon is edited in the TRADIS map-editor.
The APPLDATA is edited in the map-file by using vi or by using the “Edit object or map properties” tool
of the TRADIS map-editor (see A_10: Maintain application parameters in maps).
Step 1: Backup the original file

In this procedure you will modify the file mapdata/alrareas.cgm. Go to the directory mapdata on
a technical working position and create a backup-copy of this file, e.g. by typing:
> cp alrareas.cgm alrareas.cgm.ORG.<date>
Step 2: Graphically edit the APM map

You can modify the alerting areas (ALERTING) at the maintenance position using the map-edit tool in
TRADIS (SEE Appendix: Traffic Display (TRADIS)). When you add a new area, it is common practice to
also add a text block directly beside it for identification purposes. Save the map and exit the editor.
Step 3: Add application data (optional)

See A_10: Maintain application parameters in maps
Step 4: Distribute the changes

When the change is completed, copy the changed map (mapdata/alrareas.cgm) to

7.4.3 RIM settings
A_12: Maintain RIM settings

The RIM function is executed for tracks that are present in the approach areas and runway areas,
using specific RIM - parameters . This paragraph describe how to maintain the RIM functionality. The
generic rules for RIM are described in XML-files. These should not be edited.
A_12.1: Maintain RIM Areas

You can edit the RIM map in TRADIS on the maintenance position. There are two RIM maps: one for
normal (RIM) and one for low visibility conditions (RIM LVP).
Centre Runway Line-up Threshold Approach

line area area line area
Figure 27: RIM map (simplified)
A RIM map contains the runway area, approach area, line-up area, centre line and threshold line for
each runway. The runways, approach areas and line-up areas are represented as polygons, identified
by APPLDATA. The centre lines and threshold lines are represented as lines. They are also identified
by APPLDATA.
Runway area: The runway area needs to be drawn so that all the asphalt of the runway (this is the
area with SMR coverage) does fit the polygon. The runway area runs up to the stopbar or holding line
(this can be different for normal and low visibility).
Approach area: The approach area starts at the edge of the asphalt of the runway and has a shape of
a trapezium. Make sure that there is no (big) overlap with the runway area, this will afect the alerting.
Line-up Area: The line up area needs to be placed on the spot where the aircrafts are lining up for that
runway, in this area objects are excluded for 'static object on runway' alerting. This can only be 1 area
per runway.
Threshold line: The threshold line needs to be placed on the runway threshold. This line is used in the
calculation of the "time to threshold" of an aircraft.
Runway centre line: The centre line is used for indicating the heading of the runway. It needs to be
placed in the centre of the runway.
After changing the RIM map, copy the changed map (mapdata/rim(lvp)areas.cgm) to
A_12.2: Maintain RIM Parameters

The characteristics of RIM are determined by areas and lines (for approach areas, runway areas, line-
up areas, centre lines and the threshold definitions) and by system parameters. This procedure
describes how RIM parameters can be changed. Do not change other parameters than those listed in
section 2.2.8

Alerting Function: Runway Incursion Monitoring (RIM).
The RIM parameters are defined in the file tfpdata/rim.ini on the CTPs. You will need to modify
the parameter(s) in this ini-file on a CTP.
In the ini-file, you will find 2 extensions of each of the given parameters.
• For normal and low visibility, the parameter-names are extended with Normal or Low
respectively.
• For pre-alerts, the names of the system parameters are prefixed with ‘PreAlert’, so the
variable SP_PreAlertMinimumThresholdDistance is used in pre-alerts.
After changing the file you must copy it to /auto/changes/patches/tfpdata and configure the
A_12.3: Maintain RIM sub functions

The RIM function consists of a number of sub functions.
The first RIM-function (RW) shall not be disabled, but the other functions can be individually disabled
by the maintenance engineer in the file tfp/xml/rulelists.xml on the CTP.
Alert name on Full name Functionname in

display rulelists.xml
RW (RunWay incursion) -
CA (Closed runway Approach) closedRwyAppAlert
CD (Closed runway Departure) closedRwyDepAlert
RD (Runway Direction conflict) rwyDirectionAlert
OR (Object on Runway) staticObjectAlert
AR (Assigned Runway mismatch) assignedRwyAlert
DA (Departure Aborted) departureAbortAlert
Table 17: RIM sub functions
The following example disables the function OR (Object on Runway):
Step 1: Modify the parameter(s)

Edit the file tfp/xml/rulelists.xml
Comment out the following 5 lines:
<Rule type="Alert" evtype="Simplex" priority="7" alarm="17">
<Condition
xlink:href="rimconditions.xml#xpointer(/rimconditions/condition[@id='staticObject
Alert'])" xlink:type="simple"/>
</Rule>
This is realized as follows:



After modifying the parameter(s), you must copy it to /auto/changes/patches/tfpdata/xml and
7.4.4 SID / Runway settings

When a track crosses a line (specified in alrareas.cgm) that indicates that a track is heading for a
runway to be used for departure, the SID in the plan of the track is checked according to the list of
SIDS belonging to that runway (defined in alr.ini). When there is a mismatch a SID/RWY alert is
given.

A_13: Maintain SID / Runway settings

SID / Runway Monitoring uses:
• A list of SID’s for each departure runway; defining the items in the pull-down menu in TRADIS
for the controller to select a SID; this is defined on the DP in the file deprwys.xml.
• A list of SID’s for each departure runway; for TFP to generate alerts; this is defined on the
CTP in the file tfpdata/alr.ini
• A number of alerting lines, triggering TFP that a track is heading for a runway; this is defined
on the CTP in the file mapdata/alrareas.cgm
A_13.1: Update SIDs in TRADIS

To add or remove a SID, belonging to a certain runway, the file deprwys.xml needs to be updated.
The file tradisdata/xml/deprwys.xml shows (in the example below) 2 runways (12 and 04R);
<depRwys>
<rwy id="12">
<sid id="RO1Q" />
<sid id="AB1Q" />
<sid id="TA1Q" />
</rwy>
<rwy id="04R">
<sid id="AR1B" />
<sid id="DU1B" />
<sid id="KO1B" />
</rwy>
</depRwys>
To add or remove a SID, just create or delete a line with the syntax
<sid id="SID_id_requested" />
in the appropriate runway section.
Note: When one or more SIDs is changed, be aware that the SID alerts needs to be updated as well
(in the file alr.ini), otherwise the SID/RWY violation monitoring functionality does not behave as
expected.
After the change, you must copy the file deprwys.xml to

/auto/changes/patches/tradisdata/xml and configure the appropriate nodes (see procedure
G_2: Distribute changes with autochanges). After a restart of TRADIS, the change is in effect.
A_13.2: Update SIDs in TFP (in alr.ini)

In the 'RWY/SID mapping' part of the file alr.ini the runways and the SIDs are defined.
When changing this file be aware of the following items:
• The runways need to be consistent with the names of the runways in the alrareas.cgm, see
A_13.3: Update SID/RWY alert lines (in alrareas.cgm)
• The SIDs need to be consistent with the ones defined in deprwys.xml, see A_13.1: Update
SIDs in TRADIS.
After the change, you must copy the file alr.ini to /auto/changes/patches/tfpdata and
Here follows the 'RWY/SID mapping' part of an example alr.ini file.
[RunwaySidMapping]
;this definition should match with the content of alrareas.cgm
; <rwy> <allowed SIDs>
12 R01Q AB1Q TA1Q
04R AR1B DU1B K01B

A_13.3: Update SID/RWY alert lines (in alrareas.cgm)

You can modify the SID/RWY alerting lines (ALERTING) at the maintenance position using the map-
edit tool in TRADIS, see Appendix: Traffic Display (TRADIS). When you add a new line, it is common
practice to also add a text block directly beside it for identification purposes.
The APPLDATA for SID/RWY alert lines contain an additional item: ATTRIBUTES "sid check" "<rwy>"
see the example below.
The APPLDATA is edited in the cgm-file by using vi or by using the “Edit object or map properties” tool
of the TRADIS map-editor (see A_10: Maintain application parameters in maps)
When the change is completed, copy the changed map (mapdata/ alrareas.cgm) to
Here follows an example of two SID/RWY alert line definitions in alrareas.cgm:
TEXT
(-959.328, 1001.41)
FINAL
"12";
APPLDATA LINE ATTRIBUTES "sid check" "12";
APPLDATA LINE LINEID 501 "SID/RWY 12";
LINECOLR 10;
LINE
(-1903.66, 1196.27)
(-981.812, 851.517);
TEXT
(-562.109, -190.246)
FINAL
"04R";
APPLDATA LINE SENDFROMREFPASSINGS TRUE;
APPLDATA LINE SENDTOREFPASSINGS FALSE;
APPLDATA LINE ATTRIBUTES "sid check" "04R";
APPLDATA LINE LINEID 502 "SID/RWY 04R";
LINE
(-861.896, -310.161)
(-524.635, -355.129);
7.4.5 TCM settings
A_14: Maintain TCM settings

Taxiway Collision Monitoring uses the airport’s taxiway topology and dedicated TCM parameters:
• The taxiway topology defines the segments and junctions of the taxiways.
• The TCM parameters determine the criteria for which TCM alerts are generated.
A_14.1: Maintain Taxiway Topology

The taxiway topology (tcmtopology.cgm) is drawn in a map (‘TCM’ on TRADIS), representing the
taxiways’ segments and junctions. When the configure script is executed, another script (make_tcm,
located in the directory mapdata) is executed, that converts the lines in this map into rectangular
areas with a predefined width. The result of the script is the file tcmtopology_out.cgm, which is the
map ‘TCM GEN’ on TRADIS. The areas in this TCM GEN are used by the TCM alerting function.
Step 1: Edit the TCM map

Edit the map (TCM) on the maintenance position.
Segments are represented by the (poly)lines in this map.
Junctions are marked by points on the lines, as shown in Figure 28.
A junction is a topology item where three or more segments meet.
At a junction:
• segment lines come together (less than 15 meters apart), marking the centre of the junction
• three or more points marking the end of the junction in each direction (thus defining the size of
the junction).

A line in the map may represent one single segment or multiple segments.
When creating a line,
• it may represent one single segment or multiple segments
• it automatically gets a name+sequence_number and a width; both as specified in the cgm
using APPLDATA.
When creating a junction, the following rules must be obeyed:

• Make sure that the points representing the centre are in close proximity (less than the earlier
specified number of meters); then the conversion algorithm will merge these points to one
junction.
• If a segment ends at the runway or the APRON area, it is not needed to add additional points
marking the size of the junction.
• A connection between two junctions requires that there is at least one segment (= 2 points)
between the two junctions (junctions can not be connected directly).
• The geographical map may in any direction not end with a junction; always end with a
segment.
When editing is finished, check for each taxiway segment that a minimum of three line segments
should be present between two junctions. Save the map and close the map editor.
Step 2: Change segment names

This step is optionally.
Segment names can be changed by adding APPLDATA to segments in the TCM file.
Therefor the following APPLDATA must be added before the polygon in the CGM file.
APPLDATA NAME <segment_name>; (Initial name is INIT)
Note 1: APPLDATA can also be entered during the map-edit session by selecting the properties of a
line and enter: NAME <segment_name>
Note 2: When changing a segment name using "APPLDATA NAME", this change is used for all the
names of the segments that follow (each segment gets a different sequence_number) in the file until a
new "APPLDATA NAME" is defined.
Step 3: Change segment width

This step is optionally.
The generated segments have a fixed width. It this width is not suffient, it can be changed by adding
the following APPLDATA to segments in the TCM file.
APPLDATA WIDTH <width>; (Initial width is 40 meter)
Note that APPLDATA can also be entered during the map-edit session by selecting the properties of a
line and enter:
WIDTH <width_value>

Figure 28: Editing the taxiway topology

Note:
When starting from scratch, use the TRAMON file (see A_15.1: Maintain RVM Airport Topology) as
starting point and execute the following steps:
1. Remove the runway centre lines (when present)
2. For segments that are connected with the runway, remove the line parts that are inside the
runway area.
3. For each junction:
Add a point to each connecting centre line. Typically this point is located approx. 20 meters
(half the width of the taxiway) from the centre of the junction. This point indicates the position
where the junction area starts.
Step 4: Run the configure script

Run configure (see G_3: Running configure) on the maintenance position. This causes the make_tcm
script to create the file mapdata/use/tcmtopology_out.cgm file; check this file by opening the
map TCM GEN in TRADIS. The result of the drawing of Figure 28 is shown in Figure 29. Note that the
two points in the centre of the junction in Figure 28 are recognized as one point. Check the generated
file, each junction should be represented by red segment blocks and between two connected junctions
a yellow segment is visible.
Figure 29: Taxiway segments

When the change is completed, copy the changed map (mapdata/tcmtopology.cgm) to
After the configure check that tfp has started without errors (check the log file of tfp, it might indicate
errors in the tcm map).
A_14.2: Maintain TCM parameters

The TCM parameters determine in which situations TCM alerts are actually generated. This procedure
describes which parameters are relevant.
Step 1: Adapt TCM parameters

Open the file tfpdata/tcm.ini on one of the CTPs for editing. You can modify the following
parameters for normal visibility mode:
Variable Description
SP_NormalPendingSeverityTime Number of seconds before predicted collision that a TCM
pre-alert is issued.
SP_NormalActualSeverityTime Number of seconds before predicted collision that a TCM
alert is issued.

Table 18: TCM Parameters
You can also edit the times for these parameters under low visibility conditions. In that case, the text
‘Normal’ is replaced by ‘Low’

When the change is completed, copy the changed file to /auto/changes/patches/tfpdata and
7.4.6 RVM Settings
A_15: Maintain RVM Settings

The functionality of Restriction Violation Monitoring (RVM) is determined by the definition of Closures
and Restrictions. These closures and restriction definitions use the segment names of the airport
topology.
RVM uses the airport topology and dedicated RVM parameters:

• The airport topology defines the segments (for taxiways and runways) and junctions.
• The RVM parameters determine the criteria for which RVM alerts are generated.
This paragraph describes how to modify restrictions.
A_15.1: Maintain RVM Airport Topology

The airport topology (airportdata/airporttopology.cgm) is drawn in a map ‘TRAMON’ on
TRADIS, representing the taxiways’ segments, junctions and runway segments. The configure script
runs another script that converts the lines in this map into rectangular areas with a predefined width.
These areas are used by the TRAMON alerting function. The result of the script is the file
airportdata/use/airporttopology_out.cgm, which is the map ‘TRAMON GEN’ on TRADIS.
Step 1: Edit the TRAMON map

Edit the TRAMON map on the maintenance position.
The lines in this map represent segments (for taxiways and runways). A segment is the part of the
taxiway/runway between two junctions. For each segment a separate line must be drawn as shown in
Figure 30. For taxiways each line may contain several points (forming a polyline) in order to be able to
create corners. For runway segments each line may only contain two points.
When the segment lines come together at a junction, make sure that the end points are in close
proximity (less than 15 meters); then the conversion algorithm will merge these close points.
When creating a TRAMON map from scratch, the centrelines map can be used as a starting point.
It is important that first the runway centerline segments are drawn (first lines to appear in the cgm file).
This is because the outer points of each runway centreline are also used in the runway definitions in
the file airportcomp.xml.
If the runway segments are not in the first part of the map and some other segments are removed from
the map, the point id's of the runway segments can change.
When the point id’s of the runway segments change (see the result in airporttopology_out.cgm after
the configure), airportcomp.xml must also be adjusted.
A segment is a piece of runway or taxiway between two crossings. So if you have a taxiway parallel to
the runway and a taxiway going from this parallel taxiway to the runway, this taxiway is considered as
one segment. It can be that the centreline of this taxiway splits just before the runway for a left turn
and a right turn, but these turns are not segments. Segments are parts of the airport that can be
closed for different reasons, for example construction work. So a segments of a few square meters
doesn't make sense.
When the drawing of all segments is finished, save the map and close the map editor.

Figure 30: Editing the TRAMON topology
Step 2: Run the configure script

Run configure (see G_3: Running configure) on the maintenance position. This causes a script to
create the airporttopology_out.cgm file; check this file by opening the map ‘TRAMON GEN’ in TRADIS.
Display the generated Tramon file (TRAMON GEN) and check this file for incorrect segments.
E.g. this happens when accidentally two points are located at the same location.
The generated Tramon file shows the point id’s for the start and end position of each polyline.
Together with the segment name which is built up using the start and end position. (e.g. segment with
name: P29-P49 starts at point P29 and ends at P49)
The result of the drawing of Figure 30 is shown in Figure 31. Note that the two points in the centre of
the junctions are recognized as one point.
Figure 31: TRAMON segments


When the change is completed, copy the changed map airportdata/airporttopology.cgm to

/auto/changes/patches/airportdata and configure the appropriate nodes (see procedure
G_2: Distribute changes with autochanges).
A_15.2: Maintain Restrictions

This procedure deals with the configuration of RVM (Restriction Violation Monitoring).
RVM knows closures and restrictions.
Closures are one or more segments that are closed for all taffic.
Closures can be enabled or disabled by the controller.
Restrictions are one or more segments that are restricted for some aircraft type.
Restrictions can only be enabled / disabled by the maintenance engineer, however the controller is
able to view the restrictions.
Restrictions can be defined directional, while closures always work in both directions.
An RV pre-alert is generated when an aircraft approaches such a closed or restricted segment.

An RV alert is generated when an aircraft enters a ‘closed’ segment or when a restricted aircraft is
entering a restricted segment in the restricted direction.
Restrictions are defined in the file airportdata/xml/restrictions.xml and can be edited by

the maintainer.
Step 1: Add a restriction

The file airportdata/xml/restrictions.xml can contain multiple restriction definitions. The
file has the following structure:
<restrictions xmlns:xsd="restrictions_1_00.xsd" version="1.00">

<restriction id="ID">
[< Restriction Definition >]

</restriction>
</restrictions>
Several restrictions can be defined in this file. A restriction is added by including a new
<restriction> construct. When a new restriction is added, the file could look like this:
<restrictions xmlns:xsd="restrictions_1_00.xsd" version="1.00">

<restriction id="ID 1">
</restriction>
<restriction id="ID 2">
</restriction>
</restrictions>
The Restriction Definition is defined is the following step.
Step 2: Modify a restriction

A restriction definition has two parts:
• attributes, specifying restricted aircraft-types

• segments that are restricted for the specified aircraft-types
Attributes have the following form, where combinations of aircraft type and IATA aircraft type can be
used:
<attrDef>
<aircraftType> [<A/C type>] </aircraftType>
<iataAcType> [<IATA A/C type>] </iataAcType>
</attrDef>
The applicable segments are specified after the attributes. They are defined in the following way:

<segments>
<segment id="[<Segment ID 1>]"/>
<segment id="[<Segment ID 2>]">
<dir>
<from>[<Point A>]</from>
<to>[<Point B>]</to>
</dir>
</segment>
</segments>
In which Segment ID1 is restricted in both directions and ID2 is only restricted from Point A to Point B.

Distribute the changes using the /auto/changes mechanism (see G_2: Distribute changes with
autochanges) and select "SETTINGS > RELOAD RESTR" on the TRADIS maintenance display.
Tramon will then use the changed restriction definitions to generate restriction violation alerts.
7.4.7 Stopbar settings
A-16: Maintain stopbar settings

Stopbars in the system are used to control/show the status of the individual stopbars and to give a
stopbar violation alert for traffic that crosses a lit stopbar. Line crossing events are detected by tfp and
send to limas. Limas checks if the line crossing concerns a lit stopbar for that direction, in which case a
stopbar violation alert is send to tradis.
The stopbar alert lines are defined in the file mapdata/alrareas.cgm and can be edited by the
maintainer. This map is used by tfp to detect line crossings.
The stopbar display lines are used for displaying the location of the stopbars and their status (indicated
by a colour) on tradis.
The stopbar light segments are defined in tradis xml files for display purposes.
The stopbar light segments are defined in limas xml files files for controlling and monitoring of the
segments.
Step 1: Maintain stopbar alert lines

The stopbar alert lines can be added, modified or removed by geographically editing the map
ALERTING on the maintenance position.
Here follows an exampe of the stopbar alert line definition:
%---------------------------------------------------------------------------%
% stop bar violation alarm lines %
%---------------------------------------------------------------------------%
LINECOLR 9;
FILLCOLR 7;
APPLDATA LINE LEXREC 5;
APPLDATA LINE BREREC 40;
APPLDATA LINE XUPPOS 0;
APPLDATA LINE YUPPOS 0;
APPLDATA LINE LINEID 1 "SB_1";
LINECOLR 8;
LINEWIDTH 1;
LINE
(-3324.32, -2775.59)
(-3368.55, -2828.95);
TEXTCOLR 10;
TEXTFONTINDEX 1;
TEXT
(-3500.88, -2830.09)
FINAL
"SB_1_A10";
Step 2: Maintain stopbar display lines

The stopbar display lines can be added, modified or removed by geographically editing the map
mapdata/stopbar.cgm on the maintenance position. Because this map is not present for display
selection it cannot be edited directly by the map editor. First copy the map stopbar.cgm to the LOCAL
FREE MAP and then edit this map by using the map editor. Make sure that the AREA ATTRIBUTES of
the stopbar definition in stopbar.cgm are the same as the LINEID name in
mapdata/alrareas.cgm. When finished editing, copy the edited freemap back again to
mapdata/stopbar.cgm to make the change active.
Here follows an exampe of the stopbar display line definition:
APPLDATA AREA ATTRIBUTES "SB_1";

LINECOLR 6;
LINEWIDTH 2;
LINE
(-3344.07, -2757.67)
(-3335.93, -2780.44)
(-3369.07, -2817.88)
(-3392.65, -2812.57);
Step 3: Maintain stopbar ids in tradis xml files

Update the list of stopbar id's in stopbars.xml to comply with the changes made to the stopbar lines.
Update the mapping of stopbar id's to stopbar groups in tradisdata/xml/ligthgroups.xml to
comply with the changes made to the stopbar lines.
Refer to Appendix: XML files for more information.
Step 4: Maintain stopbar ids in limas xml files

Update the list of stopbar id's in llsegmtable.xml, plsegmtable.xml, limasitems.xml and
lightconfig.xml to comply with the changes made to the stopbar lines. These files can be found
on directory lightdata/xml.

When the change is completed, copy the changed files to /auto/changes/patches and configure
7.5 Pushback areas settings
A_17: Maintain pushback areas settings

Pushback areas are used for automatic identification of outbound flights leaving the gate.
When a track is detected in a pushback area (each gate can have a pushback area), the plan
collection is searched for a plan with a matching gate and off block time. When a match is found the
track is automatically identified.
The pushback areas and its APPLDATA are defined in the file mapdata/pushback.cgm and can be
edited by the maintainer.
Step 1: Maintain pushback areas

The pushbackrareas can be added, modified or removed by geographically editing the map
PUSHBACK on the maintenance position.
Step 2: Maintain pushback area settings

Pushback area settings are specified in the application data section of each pushback area. These can
be modified with a text editor or with the map editor see A_10: Maintain application parameters in
maps.
Each area must at least contain the following APPLDATA lines before the POLYGON specification:
...
APPLDATA AREA AREAID 1 "A14";
APPLDATA AREA ATTRIBUTES "A14" "-60" "300" "1";
...
POLYGON
...

The attributes contain the following parameters:

• gatename, which must match with the AREAID name ("A14" in this example)
• startOffset, specifies the delta time (in seconds) before the AOBT that an automatic
identification may be performed (negative value)
• stopOffset, specifies the delta time (in seconds) after the AOBT that an automatic identification
may be performed (positive value)
• enabled, boolean specifying if the pushback area is enabled or not

When the change is completed, copy the changed file to /auto/changes/patches and configure
7.6 TRADIS settings
7.6.1 Traffic settings
A_21: Maintain track filters

Track filters can be used in TRADIS to switch off track labels in certain areas.
This can be very useful for busy areas, where the operator is not interested in the tracks or not in their
identification.
Step 1: Maintain filter areas

The filterareas can be added, modified or removed by geographically editing the map TRACK FILTER
on the maintenance position. Refer to: Table 9: List of configuration files and maps for the physical
location of this map.
Step 2: Maintain filter settings

Filter settings are specified in the application data section of each filter area. These can be modified
with a text editor or with the map editor see A_10: Maintain application parameters in maps.
Each area must at least contain the following lines before the POLYGON specification:
...
APPLDATA AREA AREAID 1 "NORTHERN APRON AREA";
APPLDATA PROP HIDE LABEL;
APPLDATA PROP OVERRIDE 1;
...
POLYGON
...
In these properties:
• the AREAID must be a unique number
• the area name is the name as it is displayed on TRADIS
• the property can be HIDE LABEL or HIDE ALL (both track and label)
• the property OVERRIDE is only used in combination with manual visibility setting: a low
visibility would override any track or label filtering (in case OVERRIDE=1)

When the change is completed, copy the changed file to /auto/changes/patches and configure
A_22: Maintain history dots

Edit the the maximum number of history dots, defined in
/hittsys/tradisdata/xml/trackdefs.xml.
This file has the following track sections:
• systemTrks, contains settings for system tracks
• sensyTrk, contains settings for sensor tracks (used for maintenance only)
The following parameter can be adjusted:

• maxHistorySize: the maximum numbers of history dots that can be presented for a track.
When the change is completed, copy the changed files to /auto/changes/patches and configure
A_23: Maintain Label Contents

Start TRADIS on the maintenance position and open the label editor (see 10.2 Label editor). Select the
appropriate label and edit its contents.
When the change is completed, copy the file tradisdata/xml/labels.xml to
A_24: Maintain Label Scheme

A label schemedefines the label angle and the length of the label line for specific label areas. These
label areas are defined in mapdata/sectionareas.cgm. The label scheme(s) for these areas are defined
in tradisdata/xml/labeloverlap.xml.
Step 1: Maintain label areas

Label areas can be added, modified or removed by editing the map LABEL SCHEME on the
maintenance position. Editing this map corresponds to editing mapdata/sectionarea.cgm.
Each area must be uniquely identified with an area id and an area name, as shown in this example.
These can be modified with a text editor. Each area must at least contain the following lines before the
POLYGON specification:
...
APPLDATA AREA AREAID 1 "AreaName";
...
POLYGON
...
The area id must be a unique number. The AreaName is used in the label scheme definition.
Step 2: Maintain label scheme settings

Label schemes are defined in the file tradisdata/xml/labeloverlap.xml. These label schemes
can be selected by the controller on TRADIS.
The file labeloverlap.xml contains a number of categories, grouped by <labelPosStrategy>.
The group with id="gndVector" applies to ground traffic window while the id=”appVector” applies
to the approach window. These groups contains the section <areaSchemes>, which can contain a
number of schemes. Each scheme is defined as follows:
<areaScheme id=”SchemeID” ... angle=”NNN” length=”NNN” ...>

...
<area id=”AreaName” angle=”NNN” length=”NNN”<area>
...
</areaScheme>
If a track is not inside any of the specified areas, these default values will be used as specified in the
display options dialogue of TRADIS.
Each areaScheme can contain label characteristics for each label area, as indicated in the example
above by “<area id=”AreaName” angle=”NNN” length=”NNN”<area>”.
In this line, the angle specifies the label angle in degrees and the length specifies the length of the
label line in pixels for the specific area.
Refer to Appendix: XML files for more information.


When the change is completed, copy the files mapdata/sectionareas.cgm and
tradisdata/xml/labeloverlap.xml to /auto/changes/patches/ and configure the
A_25: Maintain Mosaic

Mosaic areas determine in which areas TRADIS displays video from a specific radar. This overcomes
blurry video in areas with multiple coverage.
Mosaic areas only determine the display of video. They have no influence on tracking.
If video from one radar is missing, mosaicing is disabled and the video from the other radar is
displayed instantaneously.
Mosaic files are located in the directory mosdata.
Step 1: Modify the Mosaic map(s)

Modify the mosaic map(s) on the maintenance position. MOSAIC1 refers to the mosaic of radar 1, etc.

A_26: Maintain operational roles

The system knows different roles e.g.:
• Controller
• Maintenance
• Monitor
For each role the allowable items are defined.
The roles are defined in /hittsys/tradisdata/xml/userroles.xml
A role is identified by: <userrole id=
Step 1: Change allowable items

To remove an allowable item, remove the corresponding line for the userrole section.
To add an allowable item, add the corresponding line to the userrrole section.
Note: Instead of removing the line, it can also be placed between xml comments tags: <arrival>
<callsign>NDC303A</callsign>
<date-of-operation>2005-01-26</date-of-operation>
<ADEP>ESSA</ADEP>
<ADES>EKCH</ADES>
<movement-plan-status>A</movement-plan-status>
<aircraft-information>
<IATA-AC-type>M82</IATA-AC-type>
<ICAO-AC-type>MD82</ICAO-AC-type>
<wake-turbulence>M</wake-turbulence>
<aircraft>
<registration>SERDT</registration>
</aircraft>
... etc ...
> ed off (to stop the ed-output)
The output of PLAMAS can be checked with the ‘ed output’ command.
> ed output (to verify the plans on the output of PLAMAS)
> ed off (to stop the ed-output)
Note that PLAMAS generates output only when either the ADEP or ADES is filled.
IFHITT messages:
Use the listen utility (SEE 4.2.5 LISTEN-script) to check flight plans (sent by TFP) in the IFHITT
messages. The flight plans are sent from TFP to TRADIS in two ways:
• every minute, all plans in the depot are sent in one batch, and
• updates on plans are sent directly.
(Can be done on any node as hittsys)

> cd testdata/listen
> listen idt
IniFile : comms_ini.use
MigFile : -
MessageFile : /hittsys/ifhitt/ifhitt_mig.ini
stmpHandler: connected to theChannel1, ctp01:idt-dis, ctp01.hitt.asmgcs
stmpHandler: receive message = DepotPlansMod, length = 1347
stmpHandler: receive message stamp = 1182323067.055, time = 1182323067.056
stmpHandler: version = 1
Contents of message "DepotPlansMod" is:
DepotPlansMod.plan.planId = 772
DepotPlansMod.plan.sourceId = 3
DepotPlansMod.plan.inDepotReason = 3
DepotPlansMod.plan.planForObjectType = 0x01
DepotPlansMod.plan.ATD = 1182322964.788439 = 1.182323e+09
DepotPlansMod.plan.lastTimeOfUpdate = 1182322965.793129 = 1.182323e+09
DepotPlansMod.plan.includedPlans[0].planId = 771
DepotPlansMod.plan.includedPlans[0].sourceId = 0
DepotPlansMod.plan.includedPlans[0].inDepotReason = 3
DepotPlansMod.plan.includedPlans[0].destination = "EDDS"
DepotPlansMod.plan.includedPlans[0].callsign = "HLX8XD"
DepotPlansMod.plan.includedPlans[0].mode3A = 4063
DepotPlansMod.plan.includedPlans[0].placeOfDeparture = "EDDP"
DepotPlansMod.plan.includedPlans[0].registrationNumber = "DAGEE"
DepotPlansMod.plan.includedPlans[0].aircraftType = "B733"
DepotPlansMod.plan.includedPlans[0].wtc = 0x4d
DepotPlansMod.plan.includedPlans[0].SID = "NAMUB1Q"
DepotPlansMod.plan.includedPlans[0].direction = 0x02

DepotPlansMod.plan.includedPlans[0].planForObjectType = 0x01
DepotPlansMod.plan.includedPlans[0].journeyId = "IPHLX8XDEDDP0706200710"
DepotPlansMod.plan.includedPlans[0].ATD = 1182322920.000000 = 1.182323e+09
DepotPlansMod.plan.includedPlans[0].lastTimeOfUpdate = 1182322948.332908 = 1.182323e+09
DepotPlansMod.plan.includedPlans[0].EOBT = 1182323400.000000 = 1.182323e+09
DepotPlansMod.plan.includedPlans[0].flightRules = 0x01
DepotPlansMod.plan.insideFilterRules = 0x01
Note that some items in the plans must be interpreted directly, e.g. the wtc ‘medium’ is expressed as
‘0x4d’ (hex), and the SSR code is expressed in the plan in decimal and on TRADIS in octal.
W_5: Check time synchronization
The system is synchronised to a time source, see 2.3.3 System Time.

The time synchronization can be checked for the nodes in the system (using the ‘check_ntp’ script)
and per individual node (using the ntpq command).
Script check_ntp:
The synchronization can also be checked using a script that requires a ‘filter-string’.
> cd ./scripts
> check_ntp p0 (to check synchronization of nodes via the p0 network connection)
Checking time synchronisation for dp01.hitt.asmgcs
- prefered: OK
- backup: OK
Checking time synchronisation for dp01p02.hitt.asmgcs
- prefered: OK
- backup: OK
Checking time synchronisation for dp02.hitt.asmgcs
- prefered: OK
- backup: OK
Checking time synchronisation for dp02p02.hitt.asmgcs
- prefered: OK
- backup: OK
(…more info…)
Nodes checked, but not available:
- rsp01.hitt.asmgcs
- rsp02.hitt.asmgcs
(…and more…)
- rdp04.hitt.asmgcs
- rdp05.hitt.asmgcs
- rdp06.hitt.asmgcs
> check_ntp p1 (to check synchronization of nodes via the p1 network connection)
> check_ntp rdp01 (to check the synchronization of a individual node)

Checking time synchronisation for rdp01.hitt.asmgcs
- prefered: OK
- backup: OK
Checking time synchronisation for rdp01p02.hitt.asmgcs
- prefered: OK
- backup: OK
The time must be set manually if the offset is too big, this can be done by:
# date <MMDDhhmm>
#
If the confidence has not yet been determined, you should wait
ntpq-command:
To check if the NTP-process is active use the 'ps'-command as follows:
> ps aux|grep ntp
ntp 1499 0.0 0.3 1792 1784 ? 10:12 0:00 /usr/sbin/ntpd -U ntp

See C_3: Correct time synchronization when the ntpd deamon needs to be restarted.
To see if the current node is synchronised, use the 'ntpq -p' command on that node. Run this
command as root. This results e.g. on a DP0x in:
# ntpq -p
remote refid st t when poll reach delay offset
jitter
=============================================================================
*ctp01.hitt.asmgcs 10.16.1.62 2 u 51 256 377 0.151 7.924 5.105
+ctp02.hitt.asmgcs 10.16.1.62 2 u 139 256 377 0.186 -0.460 0.859
- The ' * ' indicates to which remote node the current node is synchronized with. Here it is
synchronized to ctp01. The offset indicates the time difference between ctp01 and the current
node, expressed in msec.
- The '+ ' indicates that the synchronization with this node is within the limits of synchronization and
that this node is a potential candidate for synchronization, in case ‘ * ‘ goes down.
- The ‘refid’ indicates the IP-adres of the time-source for the node. In the example, both ctp’s are
using the time-server (10.16.1.62).
- The ‘st’ indicates the stratum; the lower the value, the more reliable the time.
- when/poll: The ‘poll’-value indicates the polling frequency (in seconds). The ‘when’-value can be
used to calculate when the next polling takes place (poll minus when).
In the following situations, there may be no symbol (such as a * or +) before the remote node name:
• When the confidence is not yet determined, e.g. just after starting the node (i.e. the NTPD
deamon), or
• When the synchronization is not possible due to a too big offset.
To see if a remote node is synchronised, use the 'ntpq –p <node-name>':

# ntpq –p rdp01

9.3 Monthly Maintenance
M_1: Check (and adapt) Video Alignment and Video Level of the SMR video
The SMR supplies digital video. This implies that only the alignment of azimuth and range is needed (and
that adjustment of video gain and offset is not needed).
Furthermore, for a redundant radars (RxTx1 and RxTx2), the processing in the Radar Data Processor uses
different parameters per RxTx:
• RxTx-1: azaof1 and rapt1 alignment
• RxTx-2: azaof2 and rapt2 alignment
First make sure that the SMR is working correctly and tuned according the instructions of the supplier.
Be sure that RxTx-1 is the active radar.
Azimuth and range alignment:

The video and plots must be positioned correctly on the map in order to provide high position
accuracy. The alignment of video can be verified by checking that the video is exactly on the reference
point(s). If this is not the case, the azimuth and/or range must be corrected.
The azimuth and range adjustment is basically done in the TERMA radar system (see [TERMA]).
Afterwards, it can be checked on the TRADIS on the maintenance position and fine tuned by adjusting
parameters in HTP according to the procedure below.
Step 1: Check the alignment

Start TRADIS on the maintenance position. Select the map that contains the reference points.
In TRADIS, select the Display-Options > Video-tab. Switch on ’Show’ in the video section. Depending
on the location of the reference point(s), switch on ‘Non-movement area’ too. Select ‘Mosaic’ OFF and
select for at ‘Video Sensors’ SMR-1 only.
Zoom in on the reference point(s) and verify that the video and reference symbol is aligned. Proceed
to the following step for azimuth adjustment or to range adjustment.
Step 2a: Adjust azimuth

Keep TRADIS open and zoomed in on the reference point of the radar for which the adjustment is
done. Login on the RDP of the sensor for which the azimuth must be corrected. Once logged in on the
RDP as hittsys, start the Operator Communication tooling at the command prompt by typing:
opc
(An opc session is terminated by pressing the Control-C key combination).
Adapt the variable azaof1 (azimuth offset for RxTx1) until the video is aligned with the reference point.
The value can be requested by the following line (for RxTx1):
sp azaof1
A new value can be added by typing:

sp azaof1 <value>
Increasing of the value rotates the video picture clockwise.

Range of the parameter is 0 to 16383, (one step= 360 degrees/16384). The result of the changed
value is directly visible in TRADIS.
Step 2b: Register the values

Update the file htpdata/x_sp_1_htpini0x.com (where 0x stands for radar-site 0x) ), by setting
the new value for the azaof1 parameter. Change the azaof2 parameter to the same value. Copy the
file to /auto/changes/patches and ‘configure’ the appropriate nodes (see procedure G_2:
Check the change using opc as described in the previous steps.
The following step describes how to adjust the range.

Step 3a: Adjust range

The range adjustment is done in the HTP.
Login on the RDP of the sensor for which the range must be corrected. Once logged in on the RDP,
start the Operator Communication tooling at the command prompt by typing:
opc
Adapt the variable rapt1 (range offset for RxTx1) and rapt2 (for RxTx2) until the video is aligned with
the reference point. The value can be requested by the following line (for RxTx1):
sp rapt1
A new value can be added by typing:

sp rapt1 <value>
Increase of the value moves the picture towards the radar (the resolution of this adjustment depends
on the pulse width). The result of the changed value is directly visible in TRADIS.

Update the file htpdata/x_sp_1_htpini0x.com (where 0x stands for radar-site 0x) ), by setting
the new value for the rapt1 parameter. Change the rapt2 parameter to the same value. Copy the file to
Amplitude and offset adjustment:

The video amplitude and video offset must be tuned correctly in order to provide high detection
probability.
The video amplitude and offset can be checked by visualizing the video signal, generated by the radar,
on the Video Extractor Scope (VES), which is an application located on the CMSP.
See also Appendix: Video Extractor Scope (VES).
The VES image is displayed on the CMSP. By default, VES is started with a preselection which zooms
in on the reference point.

Figure 33: Reference point on VES
Step 4a: Adjust video offset (RAVO-adjustment (RAdarVideoOffset))

Start VES on the CMSP via the KDE-menu.
Check that the zero-level of the video is set to level zero of the VES, as illustrated in the bottom part of
VES.
Figure 34: Zero-level of the video on VES
Login on the RDP of the sensor for which the offset must be corrected. Once logged in on the
RDP, start the Operator Communication tooling at the command prompt by typing:
opc
The following steps must be taken when values via opc are changed:
1) For displaying the current values of RAVO (RAdar Voltage Offset)
sp ravo1
2) Changing a value:
sp ravo1 <value> // range: -1000 to 1000 (mV)
3) Adjust the ravo-value so that the lowest video level in the VES-gui has level zero.

Update the file htpdata/x_sp_1_htpini0x.com (where 0x stands for radar-site 0x), copy the file
Step 5a: Adjust video amplitude (RAVA-adjustment (RAdarVideoAttenuation))

Start VES on the CMSP via the KDE-menu.

The VES image is displayed on the CMSP. By default, VES is started with a preselection, showing the
reference point zoomed in. And in the lower-righthand side the maximum video is expressed in
number of levels.
RAVA adjustment is done to achieve an optimal detection level of 255 for the strongest video. For the
video amplitude adjustment, the reference point is used. The optimal level for the reference point has
been determined during the setup of the system, and is indicated by the horizontal cursor line in VES.
Login on the RDP of the sensor for which the video amplitude (in fact the gain) must be adjusted.
Once logged in on the RDP start the Operator Communication tooling at the command prompt by
typing:
opc
The following steps must be taken when values via opc are changed:
For displaying the current values of RAVA (Radar Voltage Amplitude)
sp rava1
Adjust the rava-value so that the video level of the echoes from the reference point reaches the
horizontal cursor line in VES.
Changing a value:
sp rava1 <value> // range: 500 to 8000 (mV)
After adjusting the video amplitude (rava), the video offset (ravo) needs to be verified one more time.

Update the file htpdata/x_sp_1_htpini0x.com (where 0x stands for radar-site 0x), copy the file
In case of a dual radar system: use the RACOMS-application to switch the radar to RxTx-2 and
repeat the same procedure; this time change parameters azaof2, rapt2, ravo2 and rava2.
M_2: Check Linux processes

You would check the running processes when in doubt about the performance of processes or nodes.
For this purpose, login as hittsys and carry out the command ps -ef | grep hittsys
The ps-command extracts all running processes; the grep-command filters on the presence of the text
'hittsys' in the output of the ps-command. The output displays the running HITT processes with the
consumed CPU-time.
Check that the process you are investigating is actually running.
Also check that the HITT-applications are started under Job Control (JCL). Check that the ppid
(parent process ID) of the HITT-application is equal to the pid (process ID) of JCL. If a process is not
started under JCL, it is uncontrolled. This could mean that problems with the application would not be
noticed.
M_3: Check computer load

The load on a computer can be measured by means of CMS, refer to Appendix: system control (CMS
portal).
The load of a Linux node also be measured using standard Linux utilities.
Top
top is used to present the processes running on the node, sorted on maximum cpu usage. This
overview is refreshed periodically. The refresh rate can be set by using the option '-s'.
The following example shows the output of top:

> top
top - 13:16:49 up 2 days, 1:19, 1 user, load average: 0.13, 0.06, 0.06
Tasks: 80 total, 2 running, 78 sleeping, 0 stopped, 0 zombie
Cpu(s): 2.8% us, 0.7% sy, 0.0% ni, 96.0% id, 0.0% wa, 0.0% hi, 0.5% si
Mem: 2075412k total, 825088k used, 1250324k free, 92272k buffers
Swap: 1052216k total, 0k used, 1052216k free, 265488k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

7493 hittsys 15 0 302m 294m 4068 S 3.0 14.5 20:27.56 targhitt
7479 hittsys 15 0 20448 15m 5832 S 2.3 0.8 16:20.95 tfp
7499 hittsys 15 0 8004 4416 3276 S 1.0 0.2 21:32.79 targhittint
7509 hittsys 15 0 33488 17m 7288 S 0.7 0.9 3:24.76 tramon
5016 root 15 0 107m 13m 6884 S 0.3 0.7 1:49.60 cmsclient
7504 hittsys 15 0 6080 3164 2480 S 0.3 0.2 0:30.70 hymeset
1 root 16 0 680 248 216 S 0.0 0.0 0:01.84 init
2 root RT 0 0 0 0 S 0.0 0.0 0:00.02 migration/0
3 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0
4 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/1
5 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/1
149 root 20 0 0 0 0 S 0.0 0.0 0:00.00 pdflush
The following single-character commands are available:

^L - redraw screen
q - quit
h or ? - help; show this text
d - change number of displays to show
e - list errors generated by last "kill" or "renice" command
i - toggle the displaying of idle processes
I - same as 'i'
k - kill processes; send a signal to a list of processes
n or # - change number of processes to display
o - specify sort order (size, res, cpu, time)
< - change sort to the current column -1
> - change sort to the current column +1
r - renice a process
s - change number of seconds to delay between updates
u - display processes for only one user (+ selects all users)
The output of the top command can be stopped by pressing 'q' or <Ctrl> C.
vmstat
The vmstat command displays statistics of virtual memory, processes and CPU-activity.
As an example, ‘vmstat 5 3’ displays 3 times a summary of what the system is doing every five
seconds. Note that the first measurement is not giving reliable data.
For a detailed description refer to the manual pages (man vmstat).
> vmstat 5 3
procs ---------memory---------- ---swap-- -----io---- --system-- ----cpu----

r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 0 261680 103672 1324248 0 0 2 18 60 11 0 0 99 0
0 0 0 261308 103672 1324248 0 0 0 23 335 771 0 0 100 0
1 0 0 261324 103672 1324248 0 0 0 22 337 766 1 0 99 0
>
uptime
The uptime command displays the current time, the amount of time since the system was last started,
the number of users logged into the system, and the load averages. The load average numbers give
the number of jobs in the run queue for the last 5 seconds, the last 30 seconds, and the last 60
seconds.
> uptime
3:39pm up 17:28, 1 user, load average: 0.24, 0.23, 0.20
>
Important: load average must not be over 1.

M_4: Check memory usage

The memory usage is checked with the free command, as shown in the following example.
> free
total used free shared buffers cached
Mem: 513556 316124 197432 0 123240 60508
-/+ buffers/cache: 132376 381180
Swap: 1058328 0 1058328
>
The example shows that 512 MB of physical memory is available, where approx. 316 MB are used and
approx. 197 MB is free.
M_5: Check disk space

Disk space on Linux file systems can be checked by the command df .
rrp01:~> df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda7 6297208 3784916 2512292 61% /
tmpfs 1037688 0 1037688 0% /dev/shm
/dev/sda8 70764108 1121164 69642944 2% /HITT
/dev/sda5 23268 6428 15639 30% /boot
/dev/sdb1 244188508 8899272 235289236 4% /logdisks
In this case the df-command shows:

• the file systems (or partitions) sda7, sda8, sdb1, etc.
• the disk or partition space (in terms of total, used and available blocks),
• the used percentage
• the mount point.
On each node the partition '/HITT' is the most frequently-used partition; it contains the application
software.
Furthermore, only on the RRP there is also the partition ‘/logdisks’, containing the recorded 'minute-
files'.
Note that in the example above there are two disks in the RRP;
- ‘a’ disk (containing the file systems sda7, sda8 and sda5)
- ‘b’ disk (containing the file systems sdb1).
Important:
Capacity over 90% requires action at short notice, capacity over 98% is alarming and requires
immediate action.
Because the maximum number of used blocks being 90% of the total number of blocks the capacity
can be over 100% (max. 111%).
M_6: Check redundancy

It is required to check the cause of unexpected online/offline transitions. These typically indicate a
problem. You will start by simply checking the redundancy status (i.e. online or offline) of all redundant
online/offline applications (see 2.3.5 System Redundancy). Subsequently you will analyze the cause of
abnormal transitions, if there are any.
Step 1: Check Redundancy status using CMS

CMS shows you the current redundancy status of an application. By clicking on the application’s info-
button it shows whether it is online or offline. If this is different from what you have expected, you
should check when the last transition has taken place, e.g. by checking the tfp.rep file in the
/hittsys/log directory on CTP0x.
Step 2: Check redundancy using the eval-monitor

The eval-monitors of the redundant applications allow a redundancy check from their eval-monitor
(See 4.2.2 Eval-monitor). These eval-monitors display the heartbeat frequency, the status (online or
offline), the last online/offline transition and the number of transitions since application startup. Record
the date/time of the last transition and proceed to the following step.
Step 3: Check redundancy from the report file

Each redundant application reports its status when it changes. You can lookup these specific
messages in the application report files. Check for keywords ONLINE and OFFLINE, e.g.
I_TFP_ONLINE. A transition is always preceeded by a specific action, which is either manual
(maintenance engineer has terminated the online application) or automatic (due to a missing
heartbeat). This action can mostly be seen in the application report file as well.
M_7: Check backup of changes

Check the automatic periodic backup of the /auto/changes directory on the CMSP01 to a number of
nodes (see PAR. 2.3.6).
M_8: Check archit tape

Check the recording on the archit tapes by randomly selecting one of the tapes, restore its data on the
RRP and perform an operational replay.
M_9: Check on any core files

Core files are files resulting from crashed applications. Core files can be used for the HITT software
engineer in finding out why an application has crashed.
The core files are stored in the directory hittsys/cores.
When core files exist, it is advised to rename the core to a unique name.
Therefore first find out which application generated it by entering the following command:
> file core
and then rename it by adding the application in the name, for example:
> mv core core_TRADIS_003
9.4 Yearly Maintenance

Check the presence of the spare parts.
9.5 Maintenance (Miscellaneous)

Other preventive maintenance activities are:
• Periodic maintenance on the SMR-system (e.g. antenna oil level).
Refer to the documentation of the radar supplier.
• Periodic cleaning of the tape drive (for the archiving tapes).
Refer to the technical documentation of the supplier of the tape drive for the frequency of
using a cleaning tape.

APPENDIX: TRAFFIC DISPLAY (TRADIS)
10. APPENDIX: TRAFFIC DISPLAY (TRADIS)

This chapter describes the only the TRADIS functionality that is especially available for the
maintenance user. The functionality for the operational users is described in the User Manual.
You can start the TRADIS on the maintenance position by choosing TRADIS in the Applications menu.
Note that TRADIS is started in a specific role, depending on the node on which it is started, e.g. on the
maintenance position TRADIS is started in maintenance mode.
10.1 Colour editor

Choose Background menu > Display options > Colour to open the colour editor, which is
shown in Figure 35.
Figure 35: Colour editor
Choose the Scheme (colour set) in which you would like to change a colour. Choose the colour from
the list (clicking the ‘+’ symbol or double-clicking opens the colour group). The current colour is shown
on the right hand side of this dialogue. You can change a colour by directly entering a value (for Hue,
Saturation and Value or Red, Green, Blue and Alpha (=transparency)) or by pointing to it in the colour
selection area.
Note that the scheme ‘Day’ and the scheme ’Night’ both have the same set of colours, only the values
for the colours can be different.
The colours defined in the colour group ‘Map’ are used in the Map-editor (for the line/text/fill colour).
The list of colours in the Map-editor (which is ordered numerical on colour number) is a subset of the
colours in the colour group ‘Map’ (which is ordered alphabetically).
Changing a colour of the ‘Map’ group in the Colour-Editor will change the corresponding colour in the
Map-Editor. This also applies when changing the scheme; this will change the corresponding colours
in the Map-Editor.

10.2 Label editor

For tracks that are identified by a plan, you can select what plan information to display in the label.
Logged in as role ‘Maintenance’, choose Background Menu > Display Options > Label to display the
label editor. This dialogue is shown in Figure 36.
Figure 36: Label editor
To edit a label, choose the Role and the Label. The following table gives an overview of the different
label types
Label type Description

Coupled to role
Arrival label Label of arriving flight displayed in main window
Departure label Label of departing flight displayed in main window
Default label Label of not identified object displayed in main window
Vehicle label Label of vehicle displayed in main window
Tow label Label of tow displayed main window
Aircraft label Label of aircraft without coupled plan displayed in main window
Not coupled to role (role=none)
Default quick/fixed label Quick/fixed label of not identified object displayed in main window
Arrival quick/fixed label Quick/fixed label of arriving flight displayed in main window
Departure quick/fixed label Quick/fixed label of departing flight displayed in main window
Tow quick/fixed label Quick/fixed label of tow displayed in main window
Distance line label Label of distance line
Distance line label, manipulation Label of distance line during manipulation
Approach arrival Label of arriving flight displayed in approach window
Approach departure Label of departing flight displayed in approach window
Approach arrival label with the focus Focus label of arriving flight displayed in approach window
Approach departure label with the focus Focus label of departing flight displayed in approach window
Transponder track label Label of transponder sensor track
Transponder track label with the focus Focus label of transponder sensor track
Radar track label Label of radar sensor track
Radar track label with the focus Focus label of radar sensor track
Table 19: Label types

For each role the labels are available in two versions: Normal and Focus label, which can be selected
in the label editor.
The selected Label layout is shown in the bottom section of the label editor. You can choose to
present labels in columns by checking the ‘Show columns’ checkbox. This option is typically used for
the quick/fixed look labels. Figure 37 gives an example of a label with column layout.
Figure 37: Label layout with columns
Selectable label fields

Using the field category selection, the fields are shown belonging to this field category.
The following field categories are available:
• Plan data, contains flightplan related data fields
• Track data, contains sensor related data fields.
• Distance and measurements, contains fields used by the label for the vector measurement.
• Text labels, contains fixed text strings that can be used to explain data fields.
• Technical plan data, contains technical flightplan related data fields.
• Technical track, contains technical sensor related data fields.
The following table gives an overview of the most used selectable fields with a description of the field.
Field name Description

Category: Plan Data
ADEP Airport of Departure
ADES Airport of Destination
AOBT Actual of block time
AONBT Actual on block time
ATA Actual time of arrival
ATD Actual time of departure
Call sign Call sign of aircraft/vehicle
Call sign or registration Call sign of aircraft/vehicle. When not present registration
number of aircraft/vehicle
Call sign or track number Call sign of aircraft/vehicle. When not present track number
of aircraft/vehicle
Call sign, presenting also the alert colours Call sign of aircraft/vehicle with alert indication
EOBT Estimated of block time
EONBT Estimated on block time
ETA Estimated time of arrival
ETD Estimated time of departure
Free text Free text from plan
Free text, shown when available Free text from plan, shown when available
From stand Tow from stand
IATA aircraft type Aircraft type by the IATA standard
Runway Used runway
Runway, shown when available Used runway, shown when available
Stand Used stand
Stand, shown when available Used stand, shown when available
To stand
Category: Track Data
Flight level Flight level of the aircraft
Heading Heading of the aircraft

SSR SSR code of aircraft

Speed Speed of aircraft/vehicle in meters per seconds
Speed in knots Speed of aircraft/vehicle in knots
Time to threshold Time before aircraft hits threshold
Track free text Free text coupled to track
Track free text, shown when available Free text coupled to track, shown when available
Track number Number given to track within the system
Category: Distance and measurement
Distance in KM Measured distance in kilometres
Distance in NM Measured distance in nautical miles
Distance in meters Measured distance in meters
Distance line bearing in deg. Bearing of the distance line in degrees
Table 20: Label fields
Add a field
Choose the desired Field Category and then drag-and-drop the desired field from the Fields list to the
position in the Label layout.
Move a field
Drag-and-drop a field in the Label layout to the desired position.
Delete a field
Select a field in the Label layout and click the red delete-button.
Distribute and activate the changes

The label editor is closed by selecting the OK button. The changes are then stored in the file:
labels.xml This file needs to be distributed to the DPs after which tradis must be retarted to activate
the changes. See also Appendix: XML files.
10.3 Map editor

The map editor that is used for maintenance is also used by the operational user. Therefore, refer to
the operator Manual [OM].
In the Map-editor the user (the operational user or maintainer) can (amongst others) change the
line/text colour and the fill colour. The selectable colours shown in the Map-editor can be changed by
the maintainer via DisplayOptions > Colour, see 10.1Colour editor.
10.4 Track groups

Track groups are used to enable the controller to filter out a group of vehicles i.e. filter out track label in
certain areas.
For this purpose,
- the controller can maintain a list with vehicles (as described in OM.TRADIS for controller)
- the controller can manually identify a track by assigning an item from the list with vehicles (as
described in OM.TRADIS for controller)
- the maintainer can create track filter areas (refer to 7.6.1)
- the maintainer can assign each item in the vehicle list to a vehicle-group (e.g. bus, grasscutter,
fuel), using Rolldownbar > Settings > Track Groups which results in the ‘Track Groups’
window.

Figure 38: Track Groups

First select a vehicle, next select one or more of the active groups. Or select a vehicle, next select one
or more of the available groups and select the <== button to move the selected group to the ‘Active
groups’ area.
If not assigned, the vehicles are automatically assigned to the group ‘other’.
When the OK button is pressed, the changes will be send to tfp. No files need to be distributed. (The
changes will get lost however when the CTPs are being reconfigured while the other CTPs are not
omline.)
Note: For the controller to use the track filter function, tracks need to be assigned as a vehicle. This
can of course be done manually by the controllers for each vehicle, but it is much more practical that
vehicles are identified automatically (requiring vehicles to be equipped with a transponder).
So, using the functionality of filtering out tracks labels for vehicles is only done when vehicles have a
transponder.
10.5 Video Presentation

Choose Background Menu > Display Options > Video to display the dialogue that is shown in
Figure 39. In this dialogue you can select a Mosaic.
The maintainer can also select plots, plot labels and video sensors. This is described in the following
paragraph.

Figure 39: Video Presentation Dialogue
Mosaic selection
A mosaic defines in which areas video must be shown from which radars. This mechanism is intended
to prevent double presentation of radar video. The mosaic mechanism is illustrated in Figure 40.
Situation A shows two radars with overlapping coverage. The default mosaic map in situation B is
optimized so that radar video is shown by the nearest radar. In situation C, the right (red) radar has
gone off-line, after which the backup mosaic map is automatically selected to maximize radar video
coverage of the remaining sensor.
Figure 40: Video Mosaic mechanism
A mosaic can be selected in the dialogue that is presented in Figure 39.

10.6 Sensor Settings

Choose Background Menu > Display Options > Sensors the sensors settings is used to
select the display of external sensor tracks, as shown:
Figure 41: Sensor settings
This dialogue allows you to select which system tracks you would like to display and from which
external sensors you would like to see tracks.
History dots can be switched on or off for the external sensors. History dots for system tracks can be
selected in the Track/Label section of the Display Options.

APPENDIX: SYSTEM CONTROL (CMS PORTAL)
11. APPENDIX: SYSTEM CONTROL (CMS PORTAL)

The CMS (Control and Monitoring System) portal can be started by choosing CMS portal in the
Applications menu of a maintenance working position. The web-browser is started and displays the
CMS portal as the example in Figure 42.
Figure 42: CMS Overview (example)
The CMS portal shows the information in the following elements (‘panes’):
• Navigation pane, to navigate between various type of views
• View pane, showing the Monitored Items
• Message pane, showing the latest system messages (Received Events)
A pane can be resized by dragging the separation line between two panes.
The CMS portal shows the status of components in the system. The status is presented by a colour,
according to the following scheme, for the view pane.

Colour Status Description

Green Up The item is operating normally.
Red Down The item is not working correctly.
Orange Marginal The item is starting-up or requires attention.
Grey Unknown The item is known to CMS, but its operational status is
unknown.
Table 21: View Pane Status Colors
Propagation of the status:

When an entry has a colour other than green, it means that one (or more) of its components have the
same colours. The highest operational impact is propagated to the next higher level, as shown in
Figure 43. It shows that the status of the application HYME propagates to the Applications and to the
IP01 node. This mechanism allows fast analysis down to application or component level.
Figure 43: Status Propagation (in a Treeview)
11.1 Navigation
In the Navigation pane, a view can be selected: Iconview or Treeview.
When a view is selected, it shows the status of the system on the highest level (CTP, IP, RRP, etc.).
After selecting a monitored items (e.g. DP), the view pane shows the monitored item on sub level (in
the example of the DP, the DP-applications are shown).
To return to the top level, select either the Iconview, the Treeview or the ‘…’ (below the About-item).
11.2 Iconview
The Iconview (on the highest level) looks like in Error! Reference source not found..
A right-click on an item results in a menu, as in Figure 44. The number of items in the menu depend on
the monitored item.
Figure 44: Menu selection (in a Treeview)

Menu items:
• Open: Opens the items. A single or double click on the items has the same effect.
• Open URL: This opens a web page with details as supplied by the (hardware) manufacturer
(Figure 45)
• Start/Stop: Starts or stops the item.
• Properties: The properties window shows technical details (uptime, load, etc.) of the item (Figure
46)
11.2.1 Open URL

The web page that is shown is part of the component as it was delivered by the manufacturer. For
example the web page of a printer, showing the printer status, out-of-paper, colour management, etc.
For more information, see the manufacturer’s documentation about the contents of the web page.
11.2.2 URL of HP ProLiant server

The URL of HP ProLiant servers is special, since there is a link to the Integrated Lights-Out service; in
short iLO.).
iLO is a standard feature of HP ProLiant servers. By using a separate (iLO) ethernet port attached to
the LAN, it is possible to access the iLO interface of the server. Using iLO, you can remotely maintain
your server; not only can you view the status of server components remotely, such as temperatures,
power supply and fan status, but also the server can be completely shut down and booted up again.
Performing such a cold start may recover the server if it is otherwise not accessible anymore.
Figure 45: HP ProLiant servers (iLO-window)
11.2.3 Properties
The properties window (Figure 46) shows information about the name, the uptime, memory size, load
value, software version, etc.

Figure 46: Properties window
11.3 Treeview
The Tree view can be selected in the Navigation pane and results in an overview of the system by
listing the items that a monitored by CMS portal (see Figure 47).

Figure 47: Treeview
To get more information on one entry in the list, you can open an entry by single clicking the expansion
button in front of it, or double-clicking the entry itself. The entry opens and you will see its components
(see Figure 47).
Each component contains the sub-entries:
o Applications.
o System (showing items such as load, memory, processor and uptime.)
As shown in Figure 47, the CMSP has an additional sub-entry:

o External (showing units printers, switches and time servers).
Information tab:
When in Treeview, then an Information tab is shown (Figure 48 and Figure 49). When you click an
entry in the Status Tree, you will read status information of the selected entry in the Information tab.
Figure 48 shows the status of an application instance.
Figure 49 shows of the status of a CPU.

Figure 48: Application status Information of an item in Treeview
Figure 49: Hardware Status Information of an item in Treeview
Actions-tab:
When in Treeview, then you can start or stop a node or an application be selecting the appropriate
instance-entry in the Status Tree and clicking the Start or Stop-button in the Actions-tab.
Figure 50: CMS Actions
11.3.1 Applications
Opening the entry Applications shows the applications running on the node. Opening one application-
entry shows the application instance or instances. (Some applications may be running on a node
more than once). As in Figure 51, there is one application instance (‘0’) for the TargHITT application.

Figure 51: Application Instance
11.3.2 System
Opening the entry System shows system information (see Figure 52) about the Operating System, the
average load, the physical memory and the uptime of the node.
Figure 52: Information of a processor

11.3.3 External
The status of external devices (such as printers, switches and time servers) can be observed via an
entry ‘External’ on the CMSP.
As an example, Figure 53 shows the information of the time server, showing among others the number
of satellites in view.
Figure 53: Information of an external device

11.4 System Messages (Received Events)

The message pane shows System messages in the Received Events area. Figure 54 gives an
example of system messages.
Figure 54: System Messages

The colour of the messages idicate the severity of the message in case.
Colour Severity Indicator Description

Black Informational INFO a normal situation like the start-up of a program
Black Debug DEBUG message for debugging purposes
Yellow Warning WARN a situation occurred which may require the
attention from the maintenance engineer, during
the next preventive maintenance action
Orange Error ERROR something happened that causes the
program/hardware to function incorrectly
Red Fatal FATAL the application terminated due to unrecoverable
problems
Table 22: Colours of Received Events

APPENDIX: RADAR CONTROL AND MONITORING (CMS RADAR)
12. APPENDIX: RADAR CONTROL AND MONITORING (CMS RADAR)

This chapter describes the RACOMS functionality that is available for the maintenance user for the
TERMA Scanter 2001 SMR-radar.
The CMS RADAR GUI is started by choosing Radargui (CMS RADAR) from the HITT applications
menu.
Figure 55: CMS Radar overview

If no data is received, then this is indicated by the ‘-‘ symbol.
If an SMR-radar supplies that information is unknown, the text ‘Unknown’ is displayed.
The Radar Overview shows:

• The name of the radar.
• The name of the host where the RADAR GUI -application is running. RACOMS is the proxy
software that communicates with the radar and supplies radar information to the Radar Overview.
In case of having more than one RDP for one SMR-radar, the host is automatically selected.
• Connection: This is the overall connection between RADAR GUI and the radar.
o Down: No connection between RADAR GUI and the radar ((either RACOMS-GUI is not
connected to RACOMS and/or RACOMS is not connected to Radar)
o Up: Connection between RADAR GUI and the radar is up.
o Marginal: Connection between RADAR GUI and RACOMS is up and the connection
between RACOMS and Radar is marginal (e.g. RACOMS has just started))
• Status: Overall status of the radar:
o Up: Radar is working.
o Down: Radar is not working.
o Unknown: The radar reports the status unknown and its status cannot be determined.
o Marginal: E.g. radar and/or RACOMS is starting up.
• Pulse width: The current pulse width of the radar.
• Antenna: The antenna is turning or not.
• Active RxTx: Only in case of a dual radar, the active transmitter is shown (Tx1 or Tx2). In case of a
single radar, this is not relevant.
• Tx1, Tx2 The state of the transmitter is shown, e.g. ON, Off, Standby.

12.1 Radar details

The radars can be controlled individually by clicking on one of the “Control” buttons in the Radar Overview.
Different radar brands have different parameters that can be monitored and altered. The following window
appears for Terma radars. Note that not all tabs may be available, based on the type of radar and or
configuration of the RADAR GUI.
Figure 56: CMS Radar details

The radar control consists of a header and footer. The main part is divided over a number of tab
pages, each with sub items to control the radar. These subjects shall be explained in the following
paragraphs. Note that Figure 56 shows an example for a dual radar configuration.
12.2 Radar details header

The hostname of the radar CMS application is displayed here. Select by means of another radar or
another interface to the same radar.
Default the active RxTx is set as the selected RxTx. The commands from the control window are send
to this RxTx. Also the states displayed on the control window are requested from this RxTX. If you
want to select the other (inactive) RxTx click the down arrow and select the required RxTx. From now
on all RxTx specific commands are sent to the newly selected RxTx and also the data is requested
from this selected RxTx.
In a dual system the active RxTx is displayed. It always reflects the result of the current active RxTx on
the “States” tab page. A dual receiver/transmitter tab holds the following values:
• RxTx1

• RxTx2
12.3 Radar details footer

The communication indicates the overall connection between this control window and the radar. The state
depends on the Communications as shown in the tab ‘ States’ and can be:
• ONLINE: Communication normal.
• OFFLINE: Communication error.
• MARGINAL: Communication between RACOMS and Radar is marginal.
The Reset button resets the user interface.

The Apply button is used to apply any changes made.
12.4 Tab States

The tab States (see Figure 56) shows the states of the radar and contains buttons to switch to another
state.
Mains ON or OFF:
The power supply of the radar (including antenna motor) can be switched ‘ON’ or ‘OFF’.
Antenna motor ON or OFF:

The antenna motor can be switched ‘ON’ or ‘OFF’.
Transmission ON, OFF, WARMING, Safety or Standby:

The active receiver/transmitter of the radar can be switched ‘ON’ or ‘OFF’. If the receiver/transmitter is
switched on, it takes some minutes before the magnetron is warmed up, during the time the status
displayed is ‘WARMING’ and the background colour is yellow. After this warming up period the status
becomes ‘ON’ and the colour changes to green.
Auto-switchover ON or OFF:
Switchover may be performed manually by switching the active RxTx. It is also possible to make the
system change the active transceiver automatically in case of an error in the active transceiver. The
auto-switchover can be switched ‘ON’ or ‘OFF’.
When an automatic switchover has occurred, the value of this control is set to ‘OFF’ and an automatic
switchover does not occur until the value of the parameter is changed manually.
The control of the radar and the radar itself are situated on different locations. The communication
between User Interface and Radar Site stands for the communication between these locations. The
communication between Radar Site and Radar stands for the communication between the computer
that connects the radar to the radar system and the radar itself. The possible states have the following
meaning:
• ONLINE: Communication normal.
• OFFLINE: Communication error.
Antenna polarisation (if available in the system):

The state of the polarization of the radar antenna is displayed (horizontal, vertical, or circular) and can be
manually switched.
Pulse width (if available in the system):

The state of the transmitted pulse width is displayed (short, medium or long) and can be switched manually.
The selected value will instantaneously be sent to the radar.
Auxiliary (if available in the system):

The radar has auxiliary inputs that can be used for general purposes, e.g to see if an electrical switch is
open or closed. The state of these auxiliary inputs is displayed (Open or Closed).
Communication
The state of the communication is displayed (Online, Offline, or Marginal).
There are three parts involved; hence two states are displayed:
• the state of the communication between the radar control window and RACOMS-software in the
RDP

• the state of the communication between the RACOMS-software and the radar. ONLINE:
Communication normal.
12.5 Tab Settings

The tab Settings shows the settings of the radar.
Figure 57: Tab Settings
Mains Off On Communication Fail (if available in the system):

The state of the Mains Off On Communication Fail of the radar is displayed (Available or Not Available) and
can be manually switched.
Digital Video Data Enable Delay (if available in the system):

The current value is displayed and can be manually changed.
Receiver Alarm Level

It specifies the minimum transmitted output power. If the actual output power is less than the minimum, the
radar generates an alarm.
Noise Threshold Level (if available in the system):

It specifies the noise threshold. A video level is less than this value is considered as noise and discarded.

12.6 Tab BITE
Figure 58: Tab BITE
The tab page BITE displays the actual Build-In Test Equipment values measured in the transceiver.
The displayed values are frequently updated with the last available measurements.

12.7 Tab Errors & Warnings
Figure 59: Tab Errors & Warnings
The tab page Errors & Warnings displays errors and warnings raised by the radar.
Every module button represents a specific part of the radar indicated by the text in the buttons. The
text colour of the error button, corresponding to s specific error or warning, changes from black to red,
to indicate the existence of an error or warning.
Clicking on an activated module button shows a list or errors or warnings in the error list. The scrollbar
can be used to scroll through the error list, the errors and warnings are frequently updated.

12.8 Tab PRF

The tab page PRF controls and monitors the Pulse Repetition Frequency.
Figure 60: Tab PRF
The Pulse Repetition Frequency value can range from:

800 – 8000 Hz in steps of 1Hz for PRF of Short Pulse.
600 – 3300 Hz in steps of 1Hz for PRF of Medium Pulse.
400 – 2200 Hz in steps of 1Hz for PRF of Long Pulse.
The Staggered PRF values correspond to the following stagger values:

Off : No staggering
2 % : From +1.5% and -2% from nominal PRI in 8 steps
4 % : From +3% and -4% from nominal PRI in 8 steps
8 % : From +6% and -8% from nominal PRI in 8 steps

12.9 Tab STC

The tab page STC controls and monitors the Sensitivity Timing Control.
Figure 61: Tab STC
The Sensitivity Timing Control values for Short, Medium and Long Pulse can range from -50 upto 50 dB in
steps of 1dB.

12.10 Tab Sector

The tab page sector controls and monitors the sector blanking settings.
Figure 62: Tab Sector
Four different user-defined sectors are provided. Every sector has positioning values for sector bearing and
width. For every sector the mode can be enabled or disabled.
Figure 63: Blanking Sector
Sector bearing will be used for positioning of a blanking sector. Sector bearing represents the angle in
degrees of the center of a blanking sector. The current value is shown and can be set from 0 up to 359
degrees with a step of 1 degree

Sector width can also be adjusted. The current value is shown and can be set from 10 up to 350 degrees in
steps of 1 degree.
The entered sector can be enabled or disabled for blanking by turning its mode On or Off.
Furthermore, the overall sector transmission of the four sectors can be enabled or disabled, by using the
sector transmission switch.
12.11 Tab Diversity

Settings for radars equipped with frequency diversity may be altered here. Note that this tab is usually not
available.
Figure 64: Tab Diversity
12.12 Tab Profile

All the settings made for this radar, like STC and PRF settings, can be stored into profiles. This way a group
of profiles can be established, and based on certain weather conditions or other external circumstances, an
appropriate profile for the radar may be selected, in order to increase the effectivness of the radar.

APPENDIX: REPLAY CONTROL (REPLAY GUI)
13. APPENDIX: REPLAY CONTROL (REPLAY GUI)

The Replay Control can be started by choosing ‘Replay rrp01 (Replay Control)’ in the Applications
menu of a maintenance or replay working position. This Applications menu may contain more menu
item to start replay control on other recording and replay nodes (if available in the system) e.g. rrp02.
Figure 65: Replay Control window

Figure 65 shows the Replay Control window. It consists of:
• An area (in the top part), to control the replay in terms of starting date and time, start, stop and
replay speed.
• An information area with tabs, displaying the recorded data that is available for replay,
selections to specify what data must be replayed, etc.
• A status line
At start-up, the Replay Control checks for recordings on the local node (in Figure 65 the rrp01 is the
local node) and displays the available recordings in the tab ‘Sessions’.
13.1 Replay control elements

The replay control elements in the upper part of the window are permanently visible, irrespective which
tab is selected or if the mini-dialog is selected, by clicking on the button with the triangle to the far right
of the control area.
13.1.1 Date/time selection

The moment to start the replay can be specified in two ways.
Either by setting the date and time (Figure 66) or by selecting a Session (see 13.2).
Setting the date and time can be done with the keyboard and the mouse. For example, select the day
(by highlighting it with the mouse, or selecting it by using the arrow left/right button) and then
increase/decrease the value (with the mouse or by using the arrow up/down button).
Figure 66: Date/time selection

13.1.2 Replay control buttons

The replay can be controlled in terms of starting, stopping, pausing and in selecting the replay speed
and replay direction (forward/backward). The replay control buttons are displayed in Figure 67.
Figure 67: Replay control buttons
(start) The replay is started with the Start button.
(pause) When running, it changes to indicate that the replay is currently running. The
button functions as the Pause button.
The replay is stopped with the Stop button.
The Replay speed bar controls the direction (forward/backward)

and the speed of the replay.
The increase forward or backward speed can be used to quickly find a
particular part of the recorded data.
Speed 1 is the normal speed, meaning the recorded data is replayed at the
same speed as it was recorded.
A speed, other than 1, results in replaying the data for a few seconds at
normal speed, then jump a few seconds (depending on the selected speed),
replay a few seconds at normal speed, jump a few seconds, etc.
The Replay speed indicator shows the speed that was selected; a negative
value indicates a backward direction.
The Collapse button is used to collapse the replay control window to a smaller
window (see Figure 68) with only the replay control buttons.
To return to the normal replay control window, the button is used.
Figure 68: Collapsed replay control window

13.2 Sessions
The tab Sessions displays the sessions that are available.
Figure 69: Tab: Session
A session is a consecutive recording, meaning between the start and end time (as displayed in the
Sessions-tab) there are no gaps; every second is available in the recording. A session can cover for
example more than a month.
For each session are shown: the start time, the end time, the path (directory) and the name (of the
mode of the system at the time of the recording).
The list of sessions can be sorted by selecting a column. Reselecting the same column changes the
sorting order (ascending/descending).
The Update button can be used to refresh the list of sessions.
A session can be selected with the mouse. The starting date and time are automatically filled in the
date and time fields in the upper part of the window.
13.3 Data Selection

The tab Data Selection displays the type of information that is selected to be replayed.

Figure 70: Tab: Data Selection

In Figure 70 items can be (de)selected for replay.
13.4 Voice
The tab Voice displays the type of information that is selected to be replayed.
Figure 71: Tab: Voice

In Figure 71 intems can be (de)selected for replay.
13.5 Messages
The tab Messages displays the commands that have been selected and messages from the system
about the state of the replay process.

Figure 72: Tab: Messages
New messages are added at the bottom of the list.

When new messages arise and the Messages tab is not selected, this is indicated by a red
exclamation sign: ‘ ! Messages’ in the Messages tab.
13.6 Status line

The status line at the bottom of the GUI always shows the last relevant message of the Messages list.
This line is not visible in the collapsed view of the GUI.
13.7 About
The tab About displays information about HITT and the software version that is currently used.

APPENDIX: ARCHIVING DATA (ARCHIT)
14. APPENDIX: ARCHIVING DATA (ARCHIT)
This chapter describes the ARCHIT functionality that is available for the maintenance user.
You can start ARCHIT on the maintenance position by choosing ARCHIT in the Applications menu.
14.1 Overview
ARCHIT is a standalone application that automatically archives mission critical data. The following
figure depicts the operational environment of ARCHIT.
rk
Netwo
Figure 73: ARCHIT Operational Environment
ARCHIT
ARCHIT is the actual backup and restore application.
ARCHIT schedules at which intervals files from the hard disk are written to tape and when the tape is
ejected from the tape drive.
ARCHIT reads it’s configuration from the ini-files and keeps a log of files written to tape in the tape info
files.
ARCHIT GUI
The ARCHIT GUI is the interface between the user and ARCHIT. The ARCHIT GUI connects to
ARCHIT using a network interface. This means that the ARCHIT GUI can run on another computer in
the network than the ARCHIT.
CMS
The status of ARCHIT is shown in CMS. ARCHIT also sends informational and error messages to
CMS. CMS presents the status and messages to the user.
Hard Disk
The hard disk contains the data that should be archived. Data on tape can also be restored back to the
hard disk.
Ini-files

ARCHIT’s behaviour is controlled by the parameters in the initialisation file. For example the
scheduling of the archiving and the list of files and directories to be archived can be configured (see
par. 14.9).
Tape Drive
The data is archived on tape.
Tape info files

ARCHIT keeps an on-line log of the tapes that have been created in tape info files. The information
stored in the tape info files can be accessed via the ARCHIT GUI (and can be removed by the user).
User
The user can control ARCHIT via the ARCHIT GUI. The user can also control and monitor the status
of ARCHIT in CMS. The use of CMS is described in Appendix: system control (CMS portal).
14.2 ARCHIT Operation

ARCHIT is an archiving tool used for archiving and restoring files and directories.
The purpose of this tool is to automatically store files in an archive at a regular interval. The interval is
defined by the cycle and session settings of ARCHIT. The archives are stored in the 'tar' format on
tape.
The files can be restored from tape when needed at a later time. The process of storing or restoring an
archive is called a session. A session consists of two main components. These are the archive and the
archive info file.
How ARCHIT Works

The working of ARCHIT can best be described by an example of a typical ARCHIT implementation.
Example:
ARCHIT is running on a Recording and Replay Processor. The data recorder application records
operational data and creates a new recording file every minute. On the same computer also a copy of
the operational maps are stored. Both the recording files and the maps must be backed up to tape at a
regular interval.
Suppose that ARCHIT is configured for one cycle per week (meaning usually one tape per week).
The tape will contain the recordings from Monday morning 09:00h untill next week’s Monday morning
08:59h. This is called a cycle.
ARCHIT can be configured to write files to tape every n-hours (e.g. 24 hours). This is called a
session.
In this example on Monday morning 09:00h ARCHIT will write the final session, holding the recording
files created during the past 24 hours and the operational maps to tape. After this, ARCHIT will write a
tape-info file to tape. When this writing is finished, the tape is ejected automatically from the tape drive
and the cycle ends.
The tape must be replaced with a next tape by the maintenance engineer. When the tape is loaded,
ARCHIT checks the tape to see whether the tape can be overwritten or not. It checks both the write-
protect switch on the tape and it checks the date in the tape label. If the tape is older than the expiry
time, than the tape can be overwritten.
Tuesday at 09:00h ARCHIT starts by first writing a tape label to the new tape and then archive the first
session i.e. write the first archive to tape (holding the recording files of 24 hours, created between
09:00h and 008:59h and the operational maps), followed by an archive info file. Then ARCHIT will wait
for 24 hours and write the next session.
The exact definitions of terms used are given below:
Cycle
A cycle is a period of time in which several sessions are archived, in most cases a cycle is bound to
one tape. If a cycle does not fit on one tape the cycle can be continued on a following tape. A cycle
can be either an hourly, daily, weekly or a monthly cycle. A cycle is used to arrange the data in a
logical order on tape.

Session
A session describes a period of time in which files and directories are stored in an archive. During a
session, a tape archive is created with all the stored files. An archive info file is also created to keep
track of the files and directories stored in the archive.
Archive
The archive consists of all the directories and files which are to be archived in the current session. An
archive is directly written to tape and is stored using the tar format.
Tape label
The tape label contains details of the tape: the version number of the ARCHIT that created this tape,
the tape number, the tape prefix, the tape creation time, and the hostname of the computer on which
this tape is created.
Tape
A tape is used for storing the archives and the session files. A tape starts off with a tape label ending
with an end of file (EOF) marker. This is then followed by 1..n sessions. Each session contains an
archive and an archive info file. The archive and the archive info files are each ended with an EOF
marker. A graphical representation of what the contents of a tape looks like is shown in the following
figure.
E E Archive E E E Archive E
Tape
Label
O
F
Archive 1 O
F
Info
File 1
O
F
..... O
F
Archive n O
F
Info
File n
O
F
Session
Figure 74: ARCHIT Tape contents
Expiration time
To protect the data on tape ARCHIT is configured with an expiration time. ARCHIT will not overwrite
tapes younger than the expiration time.
Tape eject
The tape is automatically ejected either at the end of a cycle or when the tape is full. After a tape eject
a blank or expired tape must be loaded into the tape drive.

14.3 The ARCHIT GUI

The ARCHIT GUI looks as follows:
Figure 75: ARCHIT GUI - Main window
14.3.1 ARCHIT GUI Items

The ARCHIT GUI contains the following items:
Tapes
The Tapes list shows the tapes of which the tape information is still on-line. The list is sorted on the
creation time of the tapes. When a cycle is written on more than one tape a sequence number is
added to the tape’s description.
Tape Info
The field Tape Info shows detailed information on the selected tape in the Tapes list.
Session List
The Session List shows the sessions on the selected tape. The session list is sorted on the creation
time of the sessions.
Button Bar
The Button Bar holds the controls of ARCHIT. The function of the buttons is described in more detail
further on in the document

History Window
The History Window shows the history of the commands given in the ARCHIT GUI.
Status Bar
The Status Bar shows the status of ARCHIT. The Status Bar is split up into two lines. The first line
shows the status of ARCHIT. The status can be “ready” or e.g. “Busy Archiving”, “Busy Restoring”, etc.
The second line of the Status Bar shows the Label of the tape that is currently in the tape drive.
14.3.2 ARCHIT GUI Buttons

Connect
Button Connect is used to (re)connect the ARCHIT GUI to the ARCHIT-application of an RRP.
Archive
Button Archive is used to manually archive additional data to the current tape.
Restore
Button Restore is used to restore one or more sessions from tape to hard disk.
Abort
Button Abort is used to abort ARCHIT’s current operation (e.g. abort a restore operation).
Erase
Button Erase is used to erase the entire tape that is in the drive.
Eject
Button Eject is used to eject the tape from the tape drive.
Scan
Button Scan is used to scan the tape for archive info-files and to restore the archive info files to hard
disk (and to see the tape information in the ARCHIT-GUI).
Remove
Button Remove is used to remove the online tape information on the hard disk of the selected tape.
Recreate
Button Recreate is used to recreate the tape i.e. create an exact copy of a tape, provided that the
recordings files are still present.
Reschedule
Button Reschedule is used to restart the scheduling of the tape i.e. redo the writing of one or more
cycles to tape (e.g. because of writing errors).
Exit
Button Exit exits the ARCHIT GUI.

14.4 Start ARCHIT GUI

Start ARCHIT GUI
The ARCHIT GUI can usually be started from the maintenance position by choosing Archiving
(ARCHIT) in the Applications menu.
Exit ARCHIT GUI

To stop the ARCHIT GUI, press button Exit.
Connect to ARCHIT
When the ARCHIT GUI starts, it connects to a default ARCHIT. To reconnect to an ARCHIT or to
connect to another ARCHIT:
• Press button Connect in the ARCHIT GUI
The following window will appear:
Figure 76: ARCHIT sub-window Connect
• Select the new host from the list

• Press button Ok to establish the connection
To abort connecting press button Cancel.

14.5 Work with on-line tape information

On-line tape information is information of tapes that have been created earlier. The on-line tape
information is available on the hard disk. This means that the information that was stored on tapes can
be viewed without having to load tapes in the tape drive.
View Tapes
An overview of on-line tape information is shown in the tape list. When the ARCHIT GUI connects to
ARCHIT the tape list is automatically filled.
Viewing tapes does not require any user action.
There are three columns in the tape list:

• Tape prefix
• Tape creation time
• Sequence number (when necessary)
View Tape Information

To view more detailed information on a particular tape:
• double click on the tape in the tape list
The tape info field will then be filled with the following information about this tape:
• The version number of the ARCHIT that created this tape
• The tape number (this number is used by ARCHIT)
• The tape prefix
• The tape creation time
• The hostname of the computer on which this tape is created
• Total amount of data on this tape
The session list will then be filled with a listing of the sessions on this tape. The session list is filled
with the following information:
• Session number
• Session start date
• Session start time
• Names of archives in the session (default: ‘Recordings’)
View session contents

To view the contents of a session i.e. the files stored in the session:
• double click on the session in the session list

The Session-window will appear:
Figure 77: ARCHIT sub-window Session
The session window shows the following information:

• Tape Label
• Session number
• Names of the archives in the session
• Size of this session
• Number of files in this session
• Session start date and time
• Session end date and time
• A listing of the files in this session listed by:
o File path and name
o File date and time
o File size in bytes

Remove Tape Info

On-line tape information can be removed from the hard disk. This operation cleans (for the selected
tape) the hard disk and also the overview in the tape list. Note that this operation does not delete any
data on tape. To remove the on-line tape info:
• Select a tape from the tape list
• Press button Remove
The Remove- window will appear:
Figure 78: ARCHIT sub-window Remove
• Press button Yes to remove the tape information
To abort removing the tape information press button No.
14.6 Work with tapes
General about cleaning a tape drive

Be aware that a tapedrive needs periodic maintenance, meaning that the head in the tape drive needs
to be cleaned. For this purpose, a special cleaning tape is needed.
How often a cleaning tape must be used depends on the how often the tapedrive is used, and
therefore there is no general rule for cleaning a tape drive, e.g. every week or month.
When a tape drive needs to be clean, this is indicated on the tape drive by a light that is lit.
Scan Tape
In case information of a tape is not on-line available, ARCHIT can scan a tape in the tape drive to read
the tape information. Scanning a tape is needed for example if tape information was removed
manually from hard disk (using the Remove-button), or if a tape was created on another computer. To
scan a tape for tape information:
• Load the tape into the tape drive
• Press button Scan
ARCHIT will now scan the tape for information. The tape list will be updated automatically.
To abort scanning the tape press button Abort
Restore from tape

ARCHIT is able to restore one or more sessions on tape back to the hard disk. This is needed if data
must be replayed that is no longer present on the hard disk.
To restore sessions from tape:
• Load the relevant tape into the tape drive
• Press button Scan to scan the tape for archive info-files and to copy the archive info files to
hard disk
• Double click on the tape in the Tape List
• Select one or more sessions in the Session List
• Press button Restore

The Restore-window will appear:
Figure 79: ARCHIT sub-window Restore
If desired change the path where the files will be restored (By default a path that is recognised by the
replayer is configured).
• Press button Ok to start restoring archives from tape
To stop preparing the restore press button Cancel

To abort a running restore process press button Abort
Archive
ARCHIT is able to archive additional data on a tape i.e. data that is not already archived automatically
in each session. ARCHIT only allows for additional archives to the current tape.
To manually archive data on tape:

• Press button Archive
The Archive-window will appear:
Figure 80: ARCHIT sub-window Archive
Enter :
Session name The name that is filled in here will be shown in the
session list.
Reference dir The reference directory indicates where the additional
archives to be archived are located. This parent directory
will be striped off the file path when writing these files to
the archive.
File/Dir list The list of files / directories that have to be put on tape.
• Press button Ok to start the Manual archive
To stop preparing the manual archive press button Cancel

To abort a running restore process press button Abort
Erase Tape
ARCHIT is able to erase the entire tape that is in the tape drive. To erase a tape:
• Load the tape into the tape drive
• Press button Erase
The Erase-window will appear:
Figure 81: ARCHIT sub-window Erase
• Press button Yes to erase the tape
To abort erasing the tape press button No
Eject Tape
To eject the tape in the tape drive:
• Press button Eject

14.7 Work with ARCHIT scheduler
Recreate a tape
ARCHIT is able to recreate a complete tape .e.g. when a tape was lost, or just to have another copy of
a tape.
ARCHIT will try to make an exact copy of the tape. An exact copy can only be guaranteed if the files
are still present, either in the restore directory or the original archive location. In addition to that the
files may not be modified since the last time they where archived. If files are not present or have been
modified then ARCHIT will report a warning message. The recreation of the tape will however
continue.
To recreate a complete cycle that spans more then one tape, then each tape has to be recreated
separately.
The recreated tape will not have the same tape label as the original tape. A different tape ID is used
and the suffix “COPY” is added to the tape label.
To recreate a tape:
• Insert an empty or expired tape into the tape drive
• Select the tape in the Tape list
• Press button Recreate
The Recreate-window will appear:
Figure 82: ARCHIT sub-window Recreate
• Press button Yes to start recreating the tape
To abort recreating the tape press button No
Reschedule cycles
ARCHIT is able to reschedule (restart) the current cycle or to restart at a specified cycle. This is mainly
useful when a tape is corrupted, e.g. causing write errors, and the tape drive must be cleaned.
Using the reschedule-function, ARCHIT can redo the complete cycle on a new tape.
It is also possible to start several cycles back. It is required that the files are still present in the original
archive location and that the files have not been modified since the last time they where archived.
Note: The difference with the recreate command is that the tape information of the rescheduled cycles
is overwritten, and the ‘normal’ tape label is used (in stead of having ‘Copy’ in the tape label).
It is not possible to use this feature to skip archiving cycles. It is only intended for archiving cycles
again for a second time.
To reschedule cycles:
• Insert an empty or expired tape into the tape drive
• Press button Reschedule

The Reschedule-window will appear:
Figure 83: ARCHIT sub-window Reschedule cycles
Enter :
How many cycles … The number of cycles to be rescheduled.
The tapes of the requested cycles will be
created again.
• Press button Ok to start recreating the cycle(s).
To abort recreating the cycles press button Cancel
14.8 Reset ARCHIT

In the event the ARCHIT scheduler stopped functioning properly it can be reset. To reset the ARCHIT
scheduler:
• Stop ARCHIT e.g. via CMS
• Remove the entire content the archiveinfo directory (using a Linux command) or move the
entire content of the archiveinfo directory to another location on the hard disk (refer to the ini-
file for the correct path)
• Start ARCHIT
When connecting with the ARCHIT GUI to ARCHIT now the tape list will be empty.
ARCHIT will reschedule the cycles between the expiration time (as defined in the ini-file) and present
time.

14.9 ARCHIT Configuration
The ARCHIT ini-file

Most aspects of ARCHIT’s behaviour can be controlled via the ARCHIT ini-file
(/hittsys/architdata/archit.ini).
The ini-file is split up into two sections:
• The configurable fields will be stored in section [ArchitSettings]
• Session information is stored in section [ArchitSession]
Parameters marked with a lock ( ) symbol may not be changed.
14.9.1 Section ArchitSettings
[ArchitSettings]
The section starts with:
[ArchitSettings]
archiveinfo directory
Parameter “archiveinfo directory” describes the path where ARCHIT stores the on-line tape
information.
Syntax:
archiveinfo directory <path>
Configuration example:
archiveinfo directory /logdisks/archive/oper
cycle
Parameter “cycle” describes the cycle configuration. ARCHIT can be configured to run a monthly,
weekly, daily or hourly cycle. Possible configurations are:
Syntax:
cycle <cycletime>
To configure :
a monthly cycle
cycletime = <monthly> <day of month> <time>
values M 0 – 31 00:00-23:59
a weekly cycle
cycletime = <weekly> <day> <time>
values W mon tue wed 00:00-23:59
thu fri sat
sun
a daily cycle
cycletime = <daily> <time>
values D 00:00-23:59
an hourly cycle
cycletime = <hourly> <hours>
values H 0-1024
Configuration examples :
cycle M 1 00:00
cycle W mon 00:00
cycle D 09:00
cycle H 12

ejection size
Parameter “ejection size” describes the number of megabytes that can be stored on a tape before it is
considered full.
Syntax:
ejection size <number of megabytes>
Configuration example :
ejection size 19600
error retry
Parameter “error retry” describes the number of seconds before a failed event – e.g. a failed archive
event – is retried.
Syntax:
error retry <number of seconds>
error retry 300
expiration time
Parameter “expiration time” describes the number of days before a tape may be overwritten by archit.
Syntax:
expiration time <number of days>
expiration time 31
label prefix
Parameter “label prefix” describes the string that is added to the tape label. The label prefix is shown in
the tape list.
Syntax:
label prefix <string>
label prefix ys-rrp101.lvts.ys
localtime
Parameter “localtime” describes whether localtime or UTC time is used. A value of 0 means that UTC
time and a value of 1 means that local time is used.
Syntax:
localtime 0|1
localtime 0
restore directory
Parameter “restore directory” describes the default path where files are restored. This path will also
appear in the restore sub-window.
Syntax:
restore directory <path>
restore directory /logdisks/restored/oper

tapedev nonrewind
Parameter “tapedev norewind” describes the device file to use for rewind.
Syntax
tapedev nonrewind <nonrewind tape device>
tapedev norewind /dev/nst0
tapedev rewind
Parameter “tapedev rewind” describes the device file to use for rewind.
Syntax:
tapedev rewind <rewind tape device>
tapedev rewind /dev/st0

14.9.2 Section ArchitSession
[ArchitSession]
The section starts with:
[ArchitSession]
arch
Parameter “arch” describes the archive that is written to tape. The arch statement may be used more
than once in the ini-file.
Syntax:
arch <string1> <string2> <number> [modified]
Where :
string1 Specifies the name of this archiving entry
string2 Specifies the name of the file or directory archive
number Specifies that the file or directory is saved every <number>
sessions
modified Only files modified since last time this data was archived
arch RECORDINGS /logdisks/recordings/oper 1 modified
arch MAPS /hittsys/mapdata 1
reference directory
Parameter “reference directory” describes where all the sessions to be archived are located. This
parent directory will be stripped off the file path when writing these files to the archive.
Syntax:
reference directory <path>
reference directory /logdisks/recordings/oper
session interval
Parameter “session interval” describes at what interval an archive session will be performed.
Syntax:
session interval <interval> <number>
where
interval Specifies that the interval is configured in days, hours or
minutes. The value of interval is D, H or M
number Specifies the amount of days, hours or minutes.
Configuration examples:
session interval D 2
session interval H 2
session interval M 120

APPENDIX: VIDEO EXTRACTOR SCOPE (VES)
15. APPENDIX: VIDEO EXTRACTOR SCOPE (VES)
15.1 Overview
The Video Extractor Scope (VES) is a tool for evaluating the level at which reference points (in fact
alignment points) are detected by the system.
And in systems where there is an analoque video signal from the radar fed into the RDP’s Video
Processor, the Video Extractor Scope is a tool for evaluating the gain and offset parameters (rava1/2,
ravo1/2) of the Video Extractor.
It visualizes the samples (not hits) of radar sweeps received from the HTP in a time/distance vs
voltage/video level diagram and also performs a number of measurements (minimum, maximum,
average and deviation of the voltage/video level of samples). Effectively, the Video Extractor Scope
shows how changes in the gain/offset parameters of the Video Extractor affect the sample data that
the Video Processor sends to the HTP.
15.2 Starting the Video Extractor Scope

The Video Extractor Scope is started on the maintainers working position via the KDE-menu (refer to
4.2.1.1).
15.3 User interface
4
5
6
73 82
10
Figure 84: Video Extractor Scope screenshot
The layout of the Video Extractor Scope window is shown in the screenshot above. Its user interface
elements will be described below. The numbers behind the elements correspond to the numbers in the
picture shown above. The Video Extractor Scope consists of the following user interface elements:

- Main display area (1): Video sample data and threshold data received from the HTP by the Video
Extractor Scope is drawn in this part of the Video Extractor Scope window. In addition, cursor lines
(11, 12) may be visible in the main display area if either the horizontal or the vertical cursor is
enabled. A grid divides the main display area in 10 divisions in each dimension for convenience.
- Scales (2): Only a part of the complete distance/time and voltage/video level ranges are shown in
the main display area. The scales show, which part of the range, is shown in the main display area.
Each scale shows the size of one grid division, the lower bound of the main display area and the
upper bound of the main display area. The LSB of these three values is the same. It depends on the
division size. For example, distances are expressed in ‘m’ if the grid division size is small and in ‘km’
if the grid division size is large.
- Zoom/off center-bars (3): The part of the complete distance/time and voltage/video level range
shown in the main display area can be changed using the zoom- and off center-bars. Using the
zoom-bar, the size of the area can be changed. Using the off center-bar, its position can be changed.
The position of the main display area can also be changed by pressing the control-key and clicking
on the main display area with the right mouse button. In that case, the grid-point closest to the mouse
cursor will become the new middle-point of the main display area. When the control-key is pressed,
the user can also draw a rectangle on the main display area with the left mouse button. As soon as
the left mouse button is released, this rectangle will become the new main display area.
- Undo/redo-buttons (4): When the size or the position of the main display area is changed using any
of the aforementioned methods, the original size and position can be restored using the left of these
two buttons (the undo-button). Any action that is undone in this way can be redone by clicking the
right of these two buttons (the redo-button). The Video Extractor Scope has a memory of 10 main
display area states.
- Drawing type button (5): The sample and threshold data shown in the main display area can be
drawn in three ways. By pressing this button, the user can select one of the following three methods:
1) Line view: Each sample is drawn as a single point. The x-coordinate of this point is the start of the
range quant of this sample. Straight lines connect successive samples.
2) Block view: Each sample is drawn as a horizontal line from the start of its range quant to the end
of its range quant. Again, successive samples are connected by straight lines.
3) Scatter view: Each sample is drawn as a single point like in the first method. However, the lines
between samples are not drawn because they are only approximations and clutter up the display.
- Threshold selection buttons (6): In addition to the sample data the thresholds for a particular
sweep can also be visualized in the main display area. Visualization of the following three types of
thresholds for the current sweep can be enabled and disabled separately:
1) Min: the minimum threshold values.
2) Dyn: the dynamic (calculated) threshold values.
3) Use: the threshold that is actually used (usually the maximum of the other two).
- Unit selection panel (7): Values related to the horizontal axis of the main display area can be
interpreted as distance from the radar or time between the start of a sample and the start of a sweep.
Likewise, values related to the vertical axis of the main display area can be interpreted as video level
after A/D conversion or as voltage before A/D conversion. The most convenient interpretation can be
selected using the unit selection panel.
- Sweep selection panel (8): If both range and angle selection are disabled in this panel, HTP selects
arbitrary sweeps to send to VES. If angle selection is enabled, only sweeps with an angle between
the lower and upper angle bounds are selected (angles are measured relative to radar north with the
HTP ‘azaof’ parameter taken into account). If range selection is enabled, only sweeps starting before
the lower range bound and ending after the upper range bound are selected. The LSB of the range
values depends on the lower range bound.
- Cursor selection panel (9): If the horizontal cursor is disabled, measurements are performed for
samples at a range that lies between the left side and the right side of the main display area. If the
horizontal cursor is enabled, measurements are performed for samples that lie between the lower
cursor value and the upper cursor value. If the vertical cursor is disabled, the video level of samples

included in the measurements is clipped against the bottom and the top of the main display area.
Otherwise, their video level is clipped against the lower and upper cursor value. Cursor values are
displayed in the main display area as horizontal and vertical lines (11,12). Cursor values can be
changed by changing their value in the cursor selection panel or dragging the corresponding lines
along the main display area with the left mouse button.
- Results panel (10): Measurements are performed over a period of time. The time is configurable via
the ini-file. The results of the measurements are displayed in this panel. The LSB of these values is
the same and depends on the minimum value. If no measurements are performed because no
sample data is visible between the cursor lines or the bounds of the window, the values are cleared.

APPENDIX: ABBREVIATIONS
16. APPENDIX: ABBREVIATIONS

Abbreviation Description
ACSw Antenna Control Switch
ADS-B Automatic Dependent Surveillance - Broadcast
ADSBIN ADS-B interface
ALR Alerting
ARCH Archive
ARP Airfield Reference Point
ARTAS ATM Surveillance Tracker and Server
ASCII American Standard Code for Information Exchange
ASIFIX ASTERIX to IFHITT interface
A-SMGCS Advanced Surface Movement Guidance and Control System
ASTERIX All Purpose Structured Eurocontrol Radar Information Exchange
BC Basic Components
CGM Computer Graphics Meta format
CMS Control and Monitoring System
CMSP Control and Monitoring System Processor
COMMS Communication software
COTS Commercial Off The Shelf
CPS MLAT Central Processing Station
CSM Identical Callsign Monitoring
C-SRA Critical Safety Restricted Area
CTP Central Tracking Processor
CWP Controller Working Position
DP Display Processor
E_ Error (in report)
F_ Fatal (in report)
FPL Flight Plan
GPS Global
GUI Graphical User Interface
HMI Human Machine Interface
HTP Hit and Threshold Processing
HW Hardware
HYME Hydro/Meteo
HYMESET Hydro Meteo Setting
I_ Informational (in report)
IATA International Air Transport Association
ICD Interface Control Document
ID Installation Document
IDT Identification
IFHITT Interface HITT library
IP Interface Processor
JCL Job Control
KVM Keyboard Video Mouse
LAN Local Area Network
LIMAS Light Management System
LOGIT Recording and Replay (log it)
LRU Line Replaceable Unit
MIB Management Information Base
MLAT Multi Lateration system
MM Maintenance Manual
MPP Message Push Protocol
NCF Node Configuration File
NTP Network Time Protocol
O_ Opaque (in report)

APPENDIX: ABBREVIATIONS
OM Operational Manual
OSM Occupied Stand Monitoring
PLAMAS Plan Management System
RCM Runway Closure Monitoring
RDP Radar Data Processor
REPMAN Report Manager
RIM Runway Incursion Monitoring
RRP Recording and Replay Processor
RVM Restriction Violation Monitoring
Rx/Tx X-band transceiver
RXS MLAT Receiving Station
SAM Secured Area Monitoring
SAMINT Secured Area Monitoring Interface
SDE Software Development Environment
SDP Software Development Processor
SICO Statistic Information Collector
SMR Surface Movement Radar
SNMP Simple Network Management Protocol
SSDD System/Segment Design Document
TB Test Bench
TCM Taxiway Collision Monitoring
TCP/IP Transmission Control Protocol / Internet Protocol
TFP Track Fusion and Processing
TIS-B Traffic Information Services - Broadcast
TRADIS Traffic Display
TRAMON Traffic Monitoring
TWP Technical Working Position
TXS MLAT Transmitting Station
VDD Version Description Document
VP Video Processor
W_ Warning (in report)
XANT X-band Antenna
XML Extensible Markup Language
Table 23: Abbreviations

APPENDIX: PREVENTIVE MAINTENANCE CHECKLIST
17. APPENDIX: PREVENTIVE MAINTENANCE CHECKLIST

This checklist is meant to track the preventive maintenance procedures.
17.1 Checklist (example)

Periodic preventive maintenance can be done by filling in the following items. Consider the check
below as an example. The checks can be completed with the actual type and number of computers,
system components, according to the actual system diagram.
Date Time Maintenance Engineer Signature
17.1.1 General
Discuss system performance and operation with the controller(s). Use remarks area under 17.1.9 for
comments.
17.1.2 Visual System Inspection

Item OK NOK Remarks
Displays, colour and contrast
Keyboards / mouse
Cabling
Connectors
Temperatures
Equipment (e.g. dust filters)
Equipment racks
17.1.3 Operational Nodes

Item dp01 dp02
Node operational
Used capacity of harddisk (partition) containing /hittsys % %
Load figure from uptime (last minute)
Check *.rep files for Error and Fatal messages
Empty log-files
Check time synchronization
Check running processes
Check LAN-connections
17.1.4 System Nodes

Item ctp01 ctp02 cmsp01
Node operational
Used capacity of hard disk containing /hittsys % % %
Check *.rep files for Error and Fatal messages
Empty log-files
Check time synchronization
Check running processes
Check LAN-connections
17.1.5 Track load

Item ctp01 ctp02
Number of system tracks
Reset of track counters
17.1.6 Recording and Replay Processors

Item rrp01
Used capacity of hard disk (partition) containing %
/logdisks
Avg. size of minute files (per day) last week
Check a tape by replaying some of its contents
17.1.7 Radar Data Processors

Item rdp01 rdp02
Check status of Video Processor
Radar picture tuned: y/n y/n
- Range correction value
- Azimuth correction value
Check connection between RDP-node and online CTP
17.1.8 Check Redundancy

TARG-
Item TFP
HITT
Number of online/offline switches during maintenance
interval
Check report file(s) for unintended online/offline
switches
17.1.9 Remarks

17.2 Daily Maintenance Checklist

Procedure Check Remark
D_1: Check system status using CMS
17.3 Weekly Maintenance Checklist

W_1: Replace ARCHIT tape
W_2: Check report files
W_3: Check External Interface with

approach radar
W_4: Check Flight Plan Interface
W_5: Check time synchronization
17.4 Monthly Maintenance Checklist

M_1: Check (and adapt) Video
Alignment and Video Level of the
SMR video
M_2: Check Linux processes
M_3: Check computer load
M_4: Check memory usage
M_5: Check disk space
M_6: Check redundancy
M_7: Check backup of changes
M_8: Check archit tape
M_9: Check on any core files

17.5 Yearly Maintenance Checklist


APPENDIX: SMR ALIGNMENT POINTS
18. APPENDIX: SMR ALIGNMENT POINTS

This appendix defines the alignment points as listed in Table 24 that are used for tuning of the SMR
radar. Table 24 specifes the alignment points and the parameters to be adjusted.
(to be defined during system installation)

Reference Point Azimuth [degrees] Range [m]
Table 24 SMR Alignment points

APPENDIX: MAPS
19. APPENDIX: MAPS
The Autocad maps are converted with respect to the following airport reference point (ARP):
(to be defined during system installation)

Latitude:
Longitude:

APPENDIX: CGM DESCRIPTION
20. APPENDIX: CGM DESCRIPTION
The syntax described in this chapter is a subset of the CGM-format. In this chapter only the concepts
used in the maps of this system are described. The display software uses only this subset.
Comments will be written between ‘%’-signs.
< ... >* 0 or more

< ... >+ 1 or more
< ... >o 0 or 1



APPENDIX: XML FILES
21. APPENDIX: XML FILES
This appendix gives an overview of the xml files that can be changed.
XML files that are not listed below, should not be changed.
The XML files can contain more data as described in the table below, but only items that are described may be changed.
This to avoid unexpected behaviour of the system.
After changing an xml file the indicated node(s) must be reconfigured to activate the change.
Filename Directory Description Re-configure

airport.xml tradisdata/xml Reference to topology xml file DP
Reference to airportcomp file
alertinfooutp.xml tradisdata/xml Relation between alerts in alerting.xml and alert outputs in DP
alertoutputs.xml. This must be defined for each alert.
alerting.xml tradisdata/xml General alerting configuration items: DP
• aliveSpan defines the timeout for alert which must not be
acknowledged. When an alert is not received again within the
aliveSpan (in seconds) it will be removed.
• ackAliveSpan defines the timeout (in seconds) for alerts
which must be acknowledged. If the alert is not acknowledged
within this timeperiode, it will be removed automatically.
AlertInfo specifies for each type of alert:

• ID identifies the alert, used for references from other xml file.
E.g. from alertinfooutp.xml.
• onlyOnObj true or false, this parameter must be set to true
when the alert needs only to be presented on the object only
(label and in arr/dep/ttt lists) and not in the alert window.
Default: false
• required (true or false, indicates if this alert is enabled on
default, see note 1),
• ackable (true or false, indicates if this alert can be terminated
if it is acknowledged).
• the warningThreshold and alarmThreshold, which apply to
the alert level received from the alerting function. These items
should not be changed unless the settings are also changed at
the sending application. (ALR, Tramon)
• terminateOnAck (true or false, indicates if this alert will be

APPENDIX: XML FILES
terminated after it is acknowledged).

• alert defines the alert message that appears in the alerts list.
(%1 defines variables, typically it is replaced by the callsign)
• typeInfo defines the alert abbreviation that is used in the track
label.
• priority defines the priority of the alert. The priority is used for
sorting the alert list in case multiple alerts are active. Highest
priority = 1.
Section alertInfoGrp:
• alertInfoGrp combines individual alerts. When combined the
activation of the group activates all individual alerts.
Section handlers:
• Handler this element maps the alerts on internally used alarm
identification. This element should not be changed.
Section listwnd defines the alert window:

• maxRows defines the maximum number of rows that the alert
window can display before scrollbars are shown. Note: For the
alert window this window must be set high in order to avoid a
scrollbar. Otherwise alerts could be hidden.
• hideWhenEmpty (true or false) indicates if the alert window
must be hidden when it is empty. alert can be terminated if it is
acknowledged).
alertoutputs.xml tradisdata/xml Specifies the available alert output sounds. There are several ways to DP
define the sound, however only one should be used.
An example of the preferred way of definition is:
<AlertOutput id="rimAlert">
<system>
<command>${TRADISSOUND_DIR}/sound_script_rim
</command>
<settings>
<count>1</count>
<interval>1</interval>
</settings>
</system>

APPENDIX: XML FILES
</AlertOutput>
• id is the identification of the alert output (used for references
from alertinfooutp.xml)
• command defines the location and name of the sound script
file.
AlertOutput with id: tttActions is used to automatically show the TTT

lists after a RIM alert occurs. It must contain for each TTT window:
• id refers to the TTT list as defined in trklist.xml
• constraint which refers to a condition in applconditions.xml
applconditions.xml tradisdata/xml Definitions of expressions that define the relation between TTT list id DP
and runway:
• condition id=”TTT… refers to the TTT list as defined in
trklist.xml
• determinedRwy defines the id of the runway id to which this
TTT window belongs.
Defines expressions to popup the correct TTT list after a RIM alert
• condition id=”rimA… contains an ‘AND’ expression for
condition rimAlertShowTTT (as defined in tttactions in
alertoutputs.xml) and the TTT expression in this file
This file should not be changed.

clock_defs.xml tradisdata/xml Defines the clock definition: DP
• clock id identifies the clock layout (is used in rolloutforms.xml)
• font id defines the font to be used (refer to the fonts.xml for a
description of the font definition)
• format defines the clock format to be used. Refer to the
manual page of strftime (man strftime) for a description of the
available formats.
• localtime (true, false) When true localtime is shown. When
false UTC time is shown.
Note: This setting only works when the Display Computer is
running in local time.
• border (true, false) Specifies whether a border must be drawn
around the clock field.
More clock definitions can be defined, however only one is used. (as

APPENDIX: XML FILES
defined in rolloutforms.xml)
colorids.xml tradisdata/xml Identifications of the colours that are used. DP
• category defines the group in which this colour is shown in the
colour editor. (this item should not be changed)
• descr defines the name to be used for this colour in the colour
editor. When empty the name as specified by the id is used.
• id defines the name that is used in the source code to access
this colour. (this item should not be changed)
colortables.xml tradisdata/xml This file contains colour rules. DP
ddsysstat.xml tradisdata/xml Definition of the system status in rolldown bar. DP
• id identifies the layout (is used in rolloutforms.xml)
• font defines the font to be used (refer to the fonts.xml for a
description of the font definition)
• offline.color defines the colour to be used when status is
offline.
• online.color defines the colour to be used when status is
nfline.
• showAlways (true, false) When false the status is only shown
in case a problem is detected, otherwise the status is always
shown.
display.xml tradisdata/xml Definition of location of the tradis related xml files. This file only needs DP
to be changed in case the file locations are changed.
editmaps.xml tradisdata/xml Defines which maps files may be changed. There maps are grouped DP
as follows:
• maps id "freeMaps" contain the maps that may be edited by
the maintenance engineer.
• maps id "controllerMaps" contain the maps that may be
edited by the controller
The maps id must correspond to the map id as specified in maps.xml
use/extsystem.xml tradisdata/xml Generated file that contains the sensor status used in rolldown bar. DP
This file is built using the extsystem.xml.xxx_include files.
It contains the for each external interface:
• exp.interval, defines the time interval in which a connection
status report is expected for this interface. If no connection
status is received within this time, the connection status error
is reported.
• id, defines the name that is expected in the connection status

APPENDIX: XML FILES
report that is received for this interface.

• pres, defines the name that is shown in the rolldown bar for
this interface.
Note: the external interface with id: SMR is not guarded using a
connection status report. For this interface the presence of the radar
video data is guarded.
fieldcats.xml tradisdata/xml Definition which fields (from fields.xml) belong to which flight category. DP
(used by label editor)
fields.xml tradisdata/xml Definition of label and list fields. This file should not be changed except DP
for the following fields:
• descr name of this field as it appears in the label editor
• txt is used for fixed strings that can be used in labels (e.g. to
prefix a variable like)
fontlists.xml tradisdata/xml Defines the fonts that can be used for label and map DP
There fonts are grouped as follows:
• fonts id="label" contain the label fonts out of which the user
can make a selection.
• fonts id="map" contain the map fonts that can be used in the
map editor.
fonts.xml tradisdata/xml Definition of all fonts which can be used: DP
• font id, is the identification of the font. It is used for references
from other xml files.
• family, defines the font family.
• point.size, define the point size
• italic, (true or false) When true the font is italic.
• char.set, not used.
A true type font must be used.

labeldefs.xml tradisdata/xml Definition which label in used for which condition. DP
labeloverlap.xml tradisdata/xml Label positioning strategies for: DP
• id identification of the label positioning strategy. The following
id are defined:
o gndVector defines the track label strategy for ground
movement windos
o appVector defines the track label strategy for
approach window

APPENDIX: XML FILES
o distline defines the track label strategy for distance

line label
o distline.manip defines the distance line label strategy
when updating the distance line.
o sensyTrk defines the track label strategy for the
sensor tracks (for maintenance)
The vectorAndArea element is used to define the label position

according to the area in which the track is located, thus avoiding label
overlap. It can contain several areaschemes..
An areaScheme defines:
• id defines the name of the label scheme, several label scheme
can be efined. The user can choose the label scheme to be
used.
• angle defines the default angle (in degrees) of the label (north
= 0 degrees)
• length defines the default length (in pixels) of the label
connector line.
• area id defines the name of the area. This name must
correspond with the appldata of an area in the label scheme
map.
• popupAngle defines the angle that is used when no label is
shown for this track and the track get focus so the focus label
must be shown.
• popupLength defines the length that is used when no label is
shown for this track and the track get focus so the focus label
must be shown.
The following items define the settings for the overlap prevention
mechanism:
• maxLength defines the maximum length for the label
connector line. (in pixels)
• maxStepX defines the maximum step site in pixels (in
horizontal direction) that is used to reposition the label in order
to prevent label overlap.
• maxStepY defines the maximum step site in pixels (in vertical
direction) that is used to reposition the label in order to prevent
label overlap.

APPENDIX: XML FILES
• maxStepBackX defines the maximum step size in pixels (in

horizontal direction) that is used to reposition the label in order
return to the default position.
• maxStepBackY defines the maximum step size in pixels (in
vertical direction) that is used to reposition the label in order
return to the default position.
• smoothTrans (true, false) When true the the transfer between
areaschemes is done with smooth update. When false the
label position is changed in update.
labels.xml tradisdata/xml Label definition. (output of label editor) DP

lightgroups.xml tradisdata/xml Defines the grouping of light elements e.g. stopbars. A stopbar group DP
can be selected individually by the tradis operator to be displayed or
not.
lists.xml tradisdata/xml List definition for TTT, track list, fpl, vehicle, vehicle-maint, coast, dep, DP
arr, tow, rwy config
Column definition for the different lists:
• list id, Identification of the list:
o alert: Alert list
o vehicle: Vehicle list
o coast: Coast list
o arrival: Arrival list
o departure: Departure list
o tow: Tow list
• column id, defines a column, it contains the following items:
o id name of the column as shown in the list. The
sequence defines the column sequence as shown in
the list.
o active (true of false) defines if column must be shown
by default (see note 1)
o optional (true of false) when true this column cannot
be hidden by the user.
o width width of the column (in characters)
o sortable . (true of false) when true this column is
sorted and the sorting order can be changed by the
user.
o reverse (true of false) when true the sorting order is
reversed. Only applicable when sortable=true.

APPENDIX: XML FILES
o field refers to the field definition in fields.xml

maps.xml tradisdata/xml Relation between local map name (as shown to the user) and physical DP
CGM map.
• Map id, holds the id for this map, this id is for reference
purposes from other xml files.
• Source, is a link to the physical location of this map
Activated maps are drawn on the tradis display in the order as they are
specified in this file.
Optionally the technical map category <techmapcats> can be defined
for each map. This is only applicable for maps that contain APPLDATA
statements. Do not change the techmapcat item.
maps.xml.rad_include tradisdata/xml Input file for configure which creates radar maps. DP
maptree.xml tradisdata/xml Relation between map groups and map ids. The sequence in a group DP
also defines the sequence of the maps as shown in the map selection
dialogue.
• group name, defines the map Group name as shown in the
map selection dialogue. Each group contains references to
maps.xml.
menus.xml tradisdata/xml Definition of menus: DP
• menu id, idenfies a menu the following menus are used:
o csMenu: Callsign menu
o bg_menu: Background menu of ground movement
window.
o app.bg_menu: Background menu of approach
window
o trkMenu: Track menu
o gateMenu: Gate menu used to modify gate.
o rwyMenu: Runway menu, used to modify runway.
o sidMenu: Sid menu, used to modify sid.
o newVehicle: Menu to add vehicle in vehicle list.
o vehicleMaintMenu: Menu for vehicle maintenance
o addArrFlight: Menu to add flight in arrival list.
o addDepFlight: Menu to add flight in departure list.
o addVehFlight: Menu to add vehicle in vehicle list.
o segmentViewMenu: Twy/Rwy segment menu
o setRwyMode: Menu to change the runway mode
• attr, defines the attribute that is shown as title in the menu.
• subtitle, name of the subtitle in the menu.

APPENDIX: XML FILES
• item txt, defines the name of the menu item.

• range, defines the range (in meters) of a predefined area
• alias, is used to allow this command only for defined roles (as
defined in allowableitems.xml)
• x, defines the centre position (in x direction) of a predefined
area
• y, defines the centre position (in y direction) of a predefined
area
• angle, defines the angle (in degrees, 0 = north) of a predefined
area
• maxRows, defines the number of rows to be shown
• maxChars, defines the width (in characters)
pal_defcolor.xml tradisdata/xml Pallete used for daylight colours. DP
(is changed by colour editor)
pal_defcolorM1.xml tradisdata/xml Colour definition for night colours. (is changed by colour editor) DP
palettes.xml tradisdata/xml Definition of the palettes that are available in the system. DP
Each palette defines:
• id, identification of the palette. This id should correspond with
the id as specified in the corresponding palette file.
• descr, name of the palette as it is shown to the user.
• palette.file, refers to the corresponding palette file.
profile.xml tradisdata/xml Defines profile related settings: DP
• maxEntries, defines the maximum number of profiles that can
manually be saved.
radars.xml_include tradisdata/xml Input file used by configure to create radars.xml file. DP
rolloutforms.xml tradisdata/xml Rollout form definition (rolldown bar): DP
• pinnedDown, (true, false) When true the rolldown is kept
visible.
• tip, defines the tool tip to be shown when the user hovers the
cursor over the element.
• menu id, defines the menu name
• item txt, define the name of a sub menu
• title, specifies the name of a menu item
• alias, is used to allow this command only for defined roles (as
defined in allowableitems.xml)
rwylists.xml tradisdata/xml Defines the look and feel of the runway configuration window: DP
• title, defines the name of the window as shown in the title bar

APPENDIX: XML FILES
rwystripplacement.xml tradisdata/xml Defines the drawing order of the runway strips. DP

rwystripviewdefs.xml tradisdata/xml Defines the colour rule for the runway strip. DP
rwys.xml tradisdata/xml Defines the relation between runway and runway strip. DP
The name of the strip must correspond with one of the rwyStrips as
defined in: airportdata/airportcomp.xml.
File is also present in tramondata/xml.
segmentviewdefs.xml tradisdata/xml Definition which segment look and feel. DP
segminteractions.xml tradisdata/xml Definition of the interactions on segments DP
stands.xml tradisdata/xml Contains the names of the stands at the airport. DP
sensormaptree.xml.rad_i tradisdata/xml Input file for configure to generate sensormaps.xml. DP
nclude
sensytrkdparts.xml.rdps_i tradisdata/xml Input file for configure to generate sensytrkdparts.xml. DP
nclude
sensytrkdparts.xml.senso tradisdata/xml Input file for configure to generate sensytrkdparts.xml. DP
r_include
spage.xml tradisdata/xml Definition of the display options dialogue: DP
The following items can be changed:
• descr, defines the name of a page.
• text, defines strings that are used in the dialogue.
stopbars.xml tradisdata/xml Definition of the stopbar ids DP
symbolschemes.xml tradisdata/xml Logic definition to select the correct track symbol. DP
This file can be used to overrule standard symbols.
The following symbol schemes are defined:
• id="ground" , defines the track symbols used in the ground
movement window.
This symbol scheme contains several symbol tables:
o id="Unfilled", contains the track symbols that are
used when the user has selected not filled track
symbols
o id="Filled", contains the track symbols that are used
when the user has selected filled track symbols
o id="SizedSymb", contains the track symbols that are
used when the user has selected sized track symbols

APPENDIX: XML FILES
• id="approach", defines the track symbols used in the

approach window
o id="Unfilled", contains the track symbols that are
used
A symbol table can contain several other symbol tables.
Each symbol table is evaluated from top till bottom. The first track
symbol is used from which the corresponding constraint is valid.
sysvars.xml tradisdata/xml Definition of system variables. Can be overruled by system DP
environment variables at defined at Linux level.
tpldefs.xml tradisdata/xml This file contains flightplan related settings: DP
• validTime, defines the timeout after which flightplans are
removed. This item should not be changed because flighplans
are removed by TFP.
Furthermore the tagged items (additional plan elements) can be
defined in this file:
o name, name of the tagged items that are used
o type, type of tagged item (=text)
The same file is present in tramondata/xml
tpllists.xml tradisdata/xml Look and feel definition of flightplan lists. DP
• maxRows, defines the maximum number of rows that are
shown before a scrollbar is used.
o title, defines the title as shown in the title bar of the list
trackdefs.xml tradisdata/xml Track related settings: DP
• track id, defines the track type, the following track types are
used:
o systemTrks, this are the tracks that are shown as a
result of the fusion process.
o sensyTrk, this are sensor track that are shown for
maintenance purposes.
• track valid time, defines the number of seconds after which
the track is removed when no update has be received for this
track.
• max history dots, defines the maximum number of history
dots that can be selected by a user.
trklists.xml tradisdata/xml Look and feel definition of time to threshold lists. DP
• maxRows, defines the maximum number of rows that are
shown before a scrollbar is used.
• title, defines the title as shown in the title bar of the list

APPENDIX: XML FILES
ttt_conditions.xml tradisdata/xml Conditions for TTT lists. DP

userroles.xml tradisdata/xml Definition which commands are allowed for the different users. DP
The following users are defined:
• id=controller, holds the allowable items for the controller role.
• id=aproncontroller, holds the allowable items for the
aproncontroller role.
• id=supervisor, holds the allowable items for the supervisor
role.
• id=maintenance, holds the allowable items for the
maintenance role.
• id=replay, holds the allowable items for the replay role.
• id=monitor, holds the allowable items for the monitor role.
The following allowable items can be defined:

• alert: enable / disable alerts, acknowledge alerts
• airportCtrl: Not used
• airportCtrlActions: Not used
• approach: Show approach window
• apronInteraction: can be used to define preset areas that can
only be used by apron controllers
• closuresWnd: Not used
• equipAlarm: Not used
• emergency: emergency button
• emergencyAlert: Not used (hijack etc)
• emergencyMap: allow the selection of the emergency map
• globalAlert: Not used.
• global.emergency: Not used
• identifyTrk: Allow (un)identification of targets.
• light: Not used
• lists: Allow to show the flightplan lists.
• localAlert: Not used (can be removed)
• maintenance: Allow maintenance related commands
• navAids: Not used
• QuitCmd: Allow to stop Tradis.
• replay: Allow replay related commands.
• restrictions: Allow to reload restrictions.

APPENDIX: XML FILES
• rwyCatMonitoring: Not used

• ShowDepTimerAction: Not used
• Segments: Allow actions on taxiway segments (e.g. close)
• stdInteraction: Allow standard actions like: zooming, map
selection, panning etc.
• supervisor: Allow colour/ label / mapeditor.
• tech.alert: Not used
• technicalmaps, when present this role is allowed to select
maps that are marked with this id in windowdefs.xml
• tplInteraction: Allows updates in flightplan data.
• twrInteraction: can be used to define preset areas that can
only be used by twr controllers
• visibility, Allow to change the visibility.
• video, allow radar video related actions
Note: the controller role extends the base role. (using the extends
keyword) The allowable items of the base role are defined in
tradis/xml/baseroles.xml.
The responsibilities section can contain:

• freeMaps: Allow to edit these maps as defined in
editmaps.xml.
• stopbar: Allow to control the stopbars
videosensors.xml.extract tradisdata/xml Input file for configure to generate videosensors.xml DP

or_include
videosensors.xml.radalias tradisdata/xml Input file for configure to generate videosensors.xml DP
_include
videosensors.xml.radinfo tradisdata/xml Input file for configure to generate videosensors.xml DP
_include
videosensors.xml.simspe tradisdata/xml Input file for configure to generate videosensors.xml DP
cradar_include
video.xml tradisdata/xml Definition of radar video related settings. DP
windowdefs.xml tradisdata/xml Defines the data that is shown in the ground movement and approach DP
windows:
• wnd.def id, defines the window type, the following types are
used:

APPENDIX: XML FILES
o traffic, contains the definition for the ground

movement windows.
o app, contains the definition for the approach window
• minRange, defines the minimum range that can be selected
(in meters)
• maxRange, defines the maximum range that can be selected
(in meters)
• mapgroups defines the map group that is enabled by default.
• maps, defines the maps that can be visualized in this window.
For the maps the following settings can be defined:
o select, defines if this map must be shown by default.
(see note 1)
o reference, is the reference to this map in maps.xml.
o selectable, defines that is map can only be selected
by roles for which this id defined in the
<allowableitems> section in userroles.xml.
windowdefs.xml.rad_inclu tradisdata/xml Input file for configure to generate wndsensormaps.xml DP

de
airportcomp.xml airportdata/xml Definition of runway strips using segment points. Used for RVM. DP, CTP
• rwyStrip id describes the name of the runway strip.
Is related with the runways as described in tradisdata/rwys.xml
• points, contains two point from the airport topology between
which the runway is located..
restrictions.xml airportdata/xml Definition of the restrictions: DP, CTP
• restriction id: name of the restriction
• attrDef, defines the ICAO aircraft type for which this restriction
is valid.
• segments, defines the taxiway segments that are restricted for
the defined aircraft types. (the segment ids must corresponds
with the segment names in the ‘TRAMON GEN’ map.
• dir, optional element which defines the direction of the
restriction. When omitted the restriction applies to both
directions. The ‘to’ and ‘from’ fields must correspond with the
points as defined in ‘TRAMON GEN’ map.
airport.xml tramondata/xml Definition of: CTP
Location of topology related files.
conditions.xml tramondata/xml Defines topolygy related conditions. CTP

APPENDIX: XML FILES

globcmddisp.xml tramondata/xml Definition of tramon prof dir and file. CTP
rwys.xml tramondata/xml Rwy and rwy strip relation CTP
Same file as in tradisdata.
sbus.xml tramondata/xml Settings for tramon duplication. CTP
sysvars.xml tramondata/xml System variables used by tramon. Can be overruled by system CTP
environment variables at defined at Linux level.
tpldefs.xml tramondata/xml Same file as in tradisdata. CTP
trackdefs.xml tramondata/xml System track settings. Same file as in tradisdata. CTP
tramon.xml tramondata/xml Definition of location of the tramon related xml files. This file only needs CTP
to be changed in case the location of files are changed.
Note 1: This only applies to the first time that Tradis is started for a dedicated role. After it has been started once, the settings are stored in the profile. This
profile is used every time Tradis is started.
Note 2: The actual colour that is used is defined by the track colour as defined in the colour editor.

INDEX
INDEX
A Errors .......................................................... 171
Abort ............................................................185 Expiration time .................................... 183, 195
Active RxTx..................................................167 External interface Approach Radar............. 136
Adaptive maintenance ...................................71 F
Alerting parameters .....................................107 Fault finding .................................................. 91
Antenna motor .............................................168 Fonts ........................................................... 125
Application directory ......................................53 Free (Command)......................................... 148
APRON maps ................................................33 G
Archit............................................................181 Gr.................................................................. 76
ArchitSession...............................................194 Grass areas ................................................ 104
ArchitSettings...............................................194 H
Archive .................................................183, 185 Heartbeats .................................................... 62
Auto/changes.................................................95 history dots.................................................. 121
Automatic identification..................................35 History dots ................................................. 156
Auto-switchover ...........................................168 Hittsys ........................................................... 95
B Hostname.................................................... 167
BITE .............................................................170 HYMESET..................................................... 82
Blanking areas .............................................105 I
Blanking maps ...............................................30 Identification code ......................................... 35
Build-In Test Equipment ..............................170 IDT Area...................................................... 105
C Ini-files........................................................... 52
Changes ..................................................63, 69 J
Changes directory..........................................63 JCL................................................................ 39
clock format .................................................126 L
clutter .............................................................24 label editor .................................................. 151
CMS ...................................... 37, 133, 148, 157 label scheme............................................... 122
COAST list ...................................................105 Line Replaceable Unit................................... 71
colour editor .................................................150 M
colour palette ...............................................124 Mains .......................................................... 168
Command Maps ............................................................. 53
Df..............................................................148 Mask areas ................................................. 104
Du...............................................................76 memory stick................................................. 90
Free ..........................................................148 Messages.............................................. 52, 135
Gr ...............................................................76 Mode ............................................................. 97
Monitor .......................................................85 Module button ............................................. 171
Netstat ......................................................101 Monitor .......................................................... 85
Ping ..........................................................101 Mosaic................................................. 154, 155
Show ..................................................84, 135 Mosaic areas............................................... 123
Sn ...............................................................76 movement area ............................................. 24
Top ...........................................................146 N
Traceroute................................................101 NAI areas .................................................... 105
Uptime ......................................................147 Netstat......................................................... 101
Vmstat ......................................................147 Network connectivity ................................... 101
Configure ...........................................52, 63, 96 Node configuration file .................................. 39
Connect .......................................................185 Non-automatic initiation maps ...................... 30
Corrective maintenance.................................70 Non-coverage areas ................................... 104
Coverage areas ...........................................104 non-movement area...................................... 24
Coverage maps .............................................32 NTP ............................................................... 59
Cycle ....................................................182, 194 O
D object rings.................................................... 24
Data directory ................................................53 Online/offline ................................................. 62
Df .................................................................148 Online/offline transitions ............................. 148
Du ..................................................................76 Operational mode ......................................... 65
E Operational Replay ....................................... 99
Eject .............................................................185 P
Ejection size.................................................195 Ping ............................................................. 101
Erase ...........................................................185 PLAMAS ....................................................... 81
Error list .......................................................171 Plan systems................................................. 35

INDEX
plot calculation ...............................................24 Start node ................................................... 162

Plots .............................................................143 Started ........................................................ 133
Point of contact ..............................................69 Status .......................................................... 157
Presentation of alerts...................................106 Stop application .......................................... 162
Preset areas ................................................125 Stop node.................................................... 162
Preventive maintenance ................................70 Stopped....................................................... 133
Processes ....................................................146 System enhancements ................................. 71
Propagated ..................................................158 System messages....................................... 165
R system tracks .............................................. 156
RACOMS .....................................................167 System tracks ............................................... 28
Radar Tuning ...............................................207 T
Recorder ........................................................42 Tape ............................................................ 183
Recording files ...............................................42 Tape info ..................................................... 184
Recreate ..............................................185, 192 Tape info files.............................................. 182
Redundancy...................................................62 Tape label ................................................... 183
Redundancy status ......................................148 Tapes list..................................................... 184
Reference directory .....................................197 TargHITT....................................................... 78
Remove .......................................................185 TargHITT tracks ............................................ 28
Remove Tape Info .......................................189 TargHITT-Interface ....................................... 76
Replayer ........................................................42 Technical Replay mode ................................ 65
Report files...................................................135 TFP ............................................................... 78
Reschedule..........................................185, 192 threshold cells ............................................... 23
Reset scheduler...........................................193 Time synchronization .................................... 59
Restore ........................................................185 Top .............................................................. 146
Root ...............................................................95 Traceroute................................................... 101
RWY areas ..................................................105 Track areas ................................................. 104
RWY maps.....................................................32 Track fusion .................................................. 28
S Tracking ........................................................ 28
Scan.............................................................185 tracking area ................................................. 24
Selected RxTx .............................................167 TRADIS......................................................... 36
Semi-coverage maps.....................................32 Transmission............................................... 168
sensors settings...........................................156 Transponder name........................................ 35
Serial numbers...............................................69 Troubleshooting ............................................ 91
Session ........................................................183 U
Session interval ...........................................197 Uptime......................................................... 147
Session list...................................................184 Use-files ........................................................ 53
Session number...........................................187 V
Severity ..........................................................39 Video ........................................................... 143
Shadowing areas .........................................104 Video alignment .......................................... 143
Shadowing maps ...........................................32 Video amplitude .......................................... 144
Show ......................................................84, 135 Video offset ................................................. 144
SICO ......................................................43, 130 video processing maps ................................. 24
Sn...................................................................76 video processor............................................. 23
Software configuration control .......................70 video samples ............................................... 23
SSR code.......................................................35 Vmstat ......................................................... 147
Standard error................................................39 W
Standard output .............................................39 Warnings..................................................... 171
Start application ...........................................162 Warranty ....................................................... 70

MM PDF

Uploaded by

Copyright:

Available Formats

MM PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MM PDF

Uploaded by

Copyright:

Available Formats

MAINTENANCE MANUAL

HITT Holland Institute of Traffic Technology B.V.

THIS DOCUMENT CONTAINS PROPRIETARY INFORMATION WHICH SHALL NOT

HITT PROPRIETARY, Rev. 01 Approved 2 of 228

REFERENCED DOCUMENTS ..................................................................................13

2. IMPLEMENTATION DETAILS .........................................................................16

HITT PROPRIETARY, Rev. 01 Approved 3 of 228

5. FAULT FINDING ..............................................................................................91

HITT PROPRIETARY, Rev. 01 Approved 4 of 228

7. ADAPTIVE MAINTENANCE ..........................................................................103

HITT PROPRIETARY, Rev. 01 Approved 5 of 228

HITT PROPRIETARY, Rev. 01 Approved 6 of 228

10. APPENDIX: TRAFFIC DISPLAY (TRADIS)...................................................150

11. APPENDIX: SYSTEM CONTROL (CMS PORTAL).......................................157

12. APPENDIX: RADAR CONTROL AND MONITORING (CMS RADAR) .........166

13. APPENDIX: REPLAY CONTROL (REPLAY GUI).........................................176

14. APPENDIX: ARCHIVING DATA (ARCHIT) ...................................................181

HITT PROPRIETARY, Rev. 01 Approved 7 of 228

15. APPENDIX: VIDEO EXTRACTOR SCOPE (VES).........................................198

16. APPENDIX: ABBREVIATIONS......................................................................201

17. APPENDIX: PREVENTIVE MAINTENANCE CHECKLIST............................203

18. APPENDIX: SMR ALIGNMENT POINTS.......................................................207

19. APPENDIX: MAPS.........................................................................................208

20. APPENDIX: CGM DESCRIPTION .................................................................209

21. APPENDIX: XML FILES.................................................................................212

HITT PROPRIETARY, Rev. 01 Approved 8 of 228

Figure 1: System functional overview.................................................................................................... 17

HITT PROPRIETARY, Rev. 01 Approved 9 of 228

HITT PROPRIETARY, Rev. 01 Approved 10 of 228

Table 1: Supported ASTERIX interface categories ............................................................................... 21

HITT PROPRIETARY, Rev. 01 Approved 11 of 228

HITT PROPRIETARY, Rev. 01 Approved 12 of 228

Reference Document Name Document ID

HITT PROPRIETARY, Rev. 01 Approved 13 of 228

1.1 Purpose and Audience

This manual is intended to be used by the maintenance personnel.

1.2 Document Structure

1.3 Document Conventions

HITT PROPRIETARY, Rev. 01 Approved 14 of 228

HITT PROPRIETARY, Rev. 01 Approved 15 of 228

Before studying any other document, first study:

The implementation details are subdivided into:

2.1 System overview

2.1.1 System functional overview

HITT PROPRIETARY, Rev. 01 Approved 16 of 228

Figure 1: System functional overview

HITT PROPRIETARY, Rev. 01 Approved 17 of 228

2.1.2 System Users

The A-SMGCS has been set up in a way that:

2.1.3 System Start

HITT PROPRIETARY, Rev. 01 Approved 18 of 228

2.2 System functions

2.2.1 System Data flow

HITT PROPRIETARY, Rev. 01 Approved 19 of 228

Data flow (operational)

ADS-B MLAT Approach Meteo (FDPS)

- - - - - (for test purposes only) - - -

Audio Recording Statistics

replay time RWY approach