GOS

Gate Operating System (GOS)
Manual
Note: This page is blank for convenient double-sided printing.
GOS Safegate Group
Manual Date: August 2010
Document: _GOS_INTRODUCTION Version: 1.3
GATE OPERATING SYSTEM (GOS)

CHAPTERS AND APPENDICES
CONTENTS
Section Description
Preface Introduction
CHAPTER 1. SYSTEM DESCRIPTION
Appendix A. System Topology
Appendix B. Redundant GOS Server
Appendix C. Camera Integration
Appendix D. Interface (Options)
CHAPTER 2. INSTALLATION
Appendix A. System Configuration
Appendix B. Interface (Options)
CHAPTER 3. OPERATION
Appendix A. GOS Features (Options)
Appendix B. GOS Access Manager
Appendix C. GOS Reporter
Appendix D. ICD Example FIS (Option)
CHAPTER 4. MAINTENANCE
Appendix A. GOS Fault Finding Guide
CHAPTER 5. DRAWINGS (Option, if available)
Page 1 of 6
CONFIGURATION SUMMARY
The manual includes chapters/appendices with descriptions for available product options as follows:
• General Options - common to most gates/sites.
• More Options - specific to gates/sites.
Note: Some information may not be relevant to a specific gate/site. You can also check with project or
site management for options included in the specific configuration for a gate/site.
The table is a guide to the some of the product options available. The configuration summary column
can be used as a reference guide to find option information relevant for a specific gate/site.
Product Options Configuration Summary

General Options
Communication GOS and A-VDGS
Docking Monitoring and Control
Event Log Files
Automatic Upload Safedock Docking Log Files
Automatic Upload Safedock Configuration Files
More Options
Redundant Servers Yes or No
Interface Yes - OPC, CDI, other
or No
Connection to external systems Yes - FIS, TMS, RIDS, NTP
or No
Camera Yes or No
Interlock (Stand Adjacency Rules) Yes or No
Concentrator Yes or No
Modem rack Yes or No
Other Yes or No
Page 2 of 6
COPYRIGHT
© Copyright 2010 by Safegate Group. All rights reserved. This item and the information contained
herein are the property of Safegate Group. No part of this document may be reproduced, transmitted,
transcribed, stored in a retrieval system, or translated into any language or computer language in any
form or by any means otherwise, without the expressed written permission of Safegate Group,
Djurhagegatan 19, SE-213 76 Malmö, Sweden.
HISTORY
Version Date Description
1.0 July 2008 First Release (Standard)
1.1 June 2009 Second Release (Template, Interfaces)
1.2 January 2010 Third Release (Feature update)
1.3 August 2010 Fourth Release (Feature update)
ORIGINAL DOCUMENTS
The following is a list of original documents used to create this manual.
File Name Description

_GOS_INTRODUCTION Introduction General Safety Information
1_ GOS_SYSTEM_DESCRIPTION CHAPTER 1. SYSTEM DESCRIPTION
1A_GOS_SY_Topology Appendix 1A. Airport Topology
1B_GOS_SY_Redundant Appendix 1B. Redundant Server
1C_GOS_SY_Camera Appendix 1C. Camera Integration
1D_GOS_SY_Interface Appendix 1C. Interface (Options)
2_ GOS_INSTALLATION CHAPTER 2. INSTALLATION
2A_GOS_IN_SystemConfig Appendix 2A. System Configuration
2B_GOS_IN_Interface Appendix 2B. Interface (Options)
3_ GOS _OPERATION CHAPTER 3. OPERATION (Options)
3A_GOS_OP_Features Appendix 3A. Features (Options)
3B_GOS_OP_Access_Manager Appendix 3B. Access Manager
3C_GOS_OP_Reporter Appendix 3C. Reporter
3D_GOS_OP_ICD_Example_FIS Appendix 3D. ICD Example FIS (Option)
4_ GOS _MAINTENANCE CHAPTER 4. MAINTENANCE
4A_GOS_MA_FaultFindGuide Appendix 4A. Fault Finding Guide
5_GOS_DRAWINGS CHAPTER 5. DRAWINGS list (Options)
Note: This page is to be updated with every authorised change to the manual.
Page 3 of 6
INTRODUCTION
This manual has been compiled to give the reader an understanding of installation, operation and
maintenance (IOM) procedures of the GOS Gate Operating System, with a focus on safety and
efficiency.
Note: Some documents in this manual may include blank pages for convenient double-sided printing.
The manual includes chapters with contents for quick access to information as follows:
Introduction
Information about copyright, version history, original documents used to create this manual, a general
contents list for quick access to information. Contents are also included at the beginning of each of the
main chapters for quick access to information. There is also an abbreviations list.
Chapter 1 – System Description

A system overview of the constituent system parts with a detailed technical description. A description
of system architecture and the software and hardware components involved.
Note: Appendix documents may be included with this chapter if required.
Chapter 2 – Installation
Guidance to system installation engineers with references to software programming instructions,
calibration procedures and cross references to the Maintenance chapter.
Chapter 3 – Operation
A system operation and user interface description.
Chapter 4 – Maintenance
A system designed to minimize maintenance downtime. The chapter also includes high-level
maintenance procedures and fault diagnosis information.
Chapter 5 – Drawings
This chapter contains drawings and parts lists.
Note: This is an option if available or requested.
Page 4 of 6
ABBREVIATIONS
Abbreviation Description
AC Alternate Current
ACC Apron Control Centre
ACFS Aircraft
ACTYP Aircraft type
ALB Aircraft Loading Bridge
APA Aircraft Parking Aid
APACC Aircraft Parking Aid Central Computer
ATA Actual Time of Arrival
ATD Actual Time of Departure
A-VDGS Advanced Visual Docking Guidance System (see also DGS or Safedock)
CCR Communication Concentrator Unit of APACC
CDB Central Database
CDI Common Docking (guidance system) Interface
CL Centre Line
CMS Control & Monitoring System
COTS Commercial Off-the-shelf Items
CPU Central Processing Unit
CR Communication Room
CU Control Unit of Docking System
DC Direct Current
DGS Docking Guiding System (see also A-VDGS or Safedock)
ESD Electrostatic Discharge
ETA Estimated Time Of Arrival
ETD Estimated Time Of Departure
FAT Factory Acceptance Test
FIDS Flight Information and Display System
FIS Flight Information System
GBMS General Building Management System (maintenance system)
GMS Gate Management System
GOS Gate Operating System, same as APACC
HMI Human Machine Interface
IB Information Broker, an interface between CDB and other systems
ICD Interface Control Document
I/O Input/ Output
IOM Installation Operation Maintenance
ISO International Standardisation Organisation
IT Information Technology
LCC Life Cycle Cost
LCD Liquid Crystal Display
LED Light Emitting Diode
Page 5 of 6
LRU Line Replaceable Unit
MDT Mean Down Time
MTBF Mean Time Between Failure
MTTR Mean Time To Repair
NTP Network Time Protocol
OLE Object Linking and Embedding (see also OPC)
OPC OLE for Process Control. A standard for data exchange between
computers.
PBB Passenger Boarding Bridge
QCP Quality Control Plan
RAM Random Access Memory
RH Relative Humidity
RIDS Ramp Information Display System
RVR Runway Visual Range
SAT Site Acceptance Test
SBU Safety Back-up
SMGCS Surface Movement Guidance & Control System
S/N Serial Number
SQL Structured Query Language
STA Scheduled Time of Arrival
STD Scheduled Time of Departure
TCP/IP Transmission Control Protocol/Internet Protocol
TMS Technical Management System
U/S Unserviceable/ Out of Service
UPS Uninterruptible Power Supply
Page 6 of 6
Document: 1_GOS_SYSTEM_DESCRIPTION Version: 1.3
CHAPTER 1
SYSTEM DESCRIPTION
CONTENTS
Section Description Page No.
1. INTRODUCTION ........................................................................................................... 2
1.1 GENERAL ......................................................................................................... 2
2. USING A CENTRAL DOCKING & GUIDANCE SYSTEM ............................................ 2
2.1 GENERAL PURPOSES .................................................................................... 2
3. SYSTEM ARCHITECTURE ........................................................................................... 4
3.1 GENERAL STRUCTURE .................................................................................. 4
3.2 GOS SYSTEM COMPONENTS ....................................................................... 4
3.3 CONFIGURATION OF SOFTWARE ................................................................ 6
3.3.1 General ........................................................................................................ 6
3.3.2 Gos Software Module Architecture/Description (Options) .................... 6
4. STANDARD FEATURES .............................................................................................. 9
4.1 GENERAL ......................................................................................................... 9
4.2 DOCKING MONITORING AND CONTROL ..................................................... 9
4.2.1 General ........................................................................................................ 9
4.3 GOS EVENT LOG FILES ................................................................................. 9
4.3.1 General ........................................................................................................ 9
4.4 AUTOMATIC UPLOAD OF SAFEDOCK DOCKING LOG FILES .................... 9
4.4.1 General ........................................................................................................ 9
4.5 AUTOMATIC UPLOAD OF SAFEDOCK CONFIGURATION FILES................ 9
4.5.1 General ........................................................................................................ 9
4.6 SAFEDOCK MAINTENANCE ........................................................................... 9
4.6.1 General ........................................................................................................ 9
5. ENHANCED FEATURES (OPTIONS) ........................................................................ 10
5.1 GENERAL ....................................................................................................... 10
5.2 REDUNDANT GOS SERVERS ...................................................................... 10
5.3 INTERFACE TO EXTERNAL SYSTEMS ....................................................... 10
5.3.1 FIS Interface ............................................................................................. 10
5.3.2 TMS Interface ........................................................................................... 10
5.4 STAND IMAGES FROM CAMERA ................................................................. 10
5.4.1 General ...................................................................................................... 10
5.5 INTERLOCK FUNCTION ................................................................................ 10
5.5.1 General ...................................................................................................... 10
6. INSTALLATION........................................................................................................... 11
6.1 GENERAL ....................................................................................................... 11
Page 1 of 12
1. INTRODUCTION
1.1 GENERAL
The Safegate concept for central Docking & Guidance Control is called the Gate
Operating System (GOS). GOS is a multi-user system, based on Microsoft Windows
XP operating system.
The GOS concept is briefly described in this SYSTEM DESCRIPTION, with a focus
on the main functions.
GOS Maintenance is described in the MAINTENANCE chapter.
Operation of the GOS system, Docking Control and Monitoring, is described in the
OPERATIONS chapter.
Maintenance of a Safedock Advanced Visual Docking Guidance System (A-VDGS),
can also be carried out from the GOS system. For more information, see the Safedock
manual MAINTENANCE chapter.
Items or features stated as optional or option(s) are available from Safegate but may
not be part of the delivery, depending on the system configuration ordered.
A GOS system normally includes standard features. Chapter 3, OPERATION
appendix FEATURES includes all features for delivery standard and/or more option(s)
available for ordering.
Note: Some information may not be relevant to a specific gate/site. You can also
check with project or site management for options included in the specific
configuration for a gate/site.
2. USING A CENTRAL DOCKING & GUIDANCE SYSTEM

2.1 GENERAL PURPOSES
Using GOS gives the operator a detailed view of all the Stands and the Safedock
systems at the Airport and an option of central docking control, event
monitoring/logging and maintenance.
The possibility to interface to other computer systems at the airport provides access to
data such as Scheduled Flight information. A Flight Information System (FIS) may
also be updated with actual time of arrivals and departures for statistics and billing
purposes and more.
Safedock systems can also be a part of a Ramp Information Display System (RIDS).
GOS is used for the general purposes described in the table below:
General Purposes Realisation
- Central Stand Monitoring The GOS Monitor
- Central DGS Error Log The GOS Logging Feature
- Central System Event Log The GOS Logging Feature
- Docking Log The DGS Logging Feature
- Central Maintenance of DGS The Stand Configuration Utility and the
Stand Config PrintOut Utility
- Status Report to a Central Interface GOS – CMS (option)
Maintenance System
- Airfield Lighting Control Interface GOS – SMGCS (option)
- Push-back info to Ground Radar Interface GOS – SMGCS (option)
- Stand Area Monitoring The GOS Camera Interface and Stand
Image logging (option)
Page 2 of 12
At arrivals the following functions are realised with the GOS system:
Functions at Arrivals Realisation

- Capture of Aircraft Type to be docked Data Entry at a GOS Workstation
Data gained from a FIS connection*
- Check of Aircraft Type to be docked Data gained from a FIS connection*
to a specified Stand
- Capture of Flight No. Data Entry at a GOS Workstation
Data gained from a FIS connection
- Capture of Registration/Tail No. Data Entry at GOS Workstation (option)
Date gained from a FIS connection*
- Initiation of the Docking Procedure Entry of a Command (aircraft type) from
a GOS Workstation or automatically on
data gained from a FIS connection
- Capture of Blocks On Time GOS – interface to FIS (option)
- Display of flight information GOS – interface to FIS (option)
At departures the following functions are realised with the GOS system:
Functions at Departures Realisation

- Capture of Flight No. Data Entry at a GOS Workstation
- Capture of Registration/Tail No. Data Entry at GOS Workstation
- Capture of Blocks Off Time GOS – interface to FIS (option)
Note: * Depending on site configuration or options.
Page 3 of 12
3. SYSTEM ARCHITECTURE
3.1 GENERAL STRUCTURE
The Safegate GOS concept is a multi-user system, based on Microsoft’s Windows XP
operating system with a Windows 2003 server.
Control and Monitoring of all connected Safedock A-VDGS systems is performed by
GOS, which uses an Ethernet LAN for communication with each Safedock.
Commands from GOS are made to put Safedock in the operational modes required,
and as soon docking status has changed, a transaction will be created by Safedock
and sent to the Central Computer system, and automatically distributed to all GOS
nodes.
At any one time, all subsystems have the total information about status of all Safedock
systems, at terminals and at remote Stands.
Furthermore, the status of external systems such as the Aircraft Loading Bridge and
other equipment on the apron can be reported to GOS.
The Central Docking Control System, or GOS, comprises one or several Work
Stations, used for maintenance and operation of the Safedock units, and also one
Server/Concentrator, communicating with each Safedock and with other Airport
Systems, such as FIS and the Central Maintenance System (CMS).
3.2 GOS SYSTEM COMPONENTS
A GOS server may be used for the logical connection to external systems and for a
central database. The server also controls the connection to the docking systems. The
Safedock systems are connected to the GOS via an Ethernet LAN or serial
communication media.
GOS workstations at separate locations are used for Airfield Stand Monitoring and
Docking Control and for updating Scheduled Flights and System dependent
parameters and maintenance of Safedock systems.
The physical communication media, preferably used, is Ethernet 10/100Mz with
TCP/IP protocol.
An example of an Airport System integrated with GOS is illustrated in figure 1 – GOS
SYSTEM TOPOLOGY. For more information, see the examples in appendix A.
Page 4 of 12
Common Data Network/Ethernet LAN
Patch cables to horizontal

network outlets, 10BaseT / RJ 45
GOS
Workstation 1 Operation & Maintenance
GOS
Server
Ethernet LAN
HUB HUB HUB HUB
………………….
SDK SDK SDK SDK
# SAFEDOCK units
connected to Ethernet LAN
External Systems, option
FIS/
Gate Management System or FIS
GMS
CMS Central Maintenance System (CMS)
NTP NTP Time Server (if available)
FIGURE 1 - GOS SYSTEM TOPOLOGY
Page 5 of 12
3.3 CONFIGURATION OF SOFTWARE

3.3.1 General
GOS is a multi-user system, based on Microsoft’s Windows XP operating system.
GOS system comprises a set of software modules that can be executed in one or
several Personal Computers (PC), connected to data networks.
GOS Software is mainly built around two items, called GosKrnl and GosMMi, which
are common to all subsystems, and one configuration file for each subsystem, called
GOS.INI. GosKrnl also uses a number of modules (DLLs and EXE files). The GOS.INI
file on each PC specifies the modules that will be used on each PC.
The following information is a description of each individual item in the GOS system.
This is further illustrated in figure 2 – SOFTWARE CONFIGURATION.
3.3.2 Gos Software Module Architecture/Description (Options)

The following is a short description of all software modules available for configuration.
Note: Some of the modules are options and may not be included in a specific site
GOS system configuration.
(a) Gosinstall.exe
Installation program used to install GOS software on each computer.
(b) GOSMMI.exe
GOSMMI.exe is a monitor program used to monitor and control the
Safedock system. It also displays the layout of the airport.
GOSMMI.exe interfaces to GOSKRNL.EXE. The two programs are
completely separated from each other. For GOS communication to
work correctly, it is not necessary to run GOSMMI.exe. GOSMMI.exe
is only run when monitoring and control is required.
However GOSMMI.exe receives all information from GOSKRNL.EXE,
which has to be running for GOSMMI.exe to work.
(c) GOSKRNL.EXE
GOSKRNL.EXE manages all communication between Safedock and
GOS nodes. GOSKRNL.EXE is the program which starts the GOS
system. When GOSKRNL.EXE is started, it loads a number of
modules (DLL and EXE files). GOSKRNL.EXE also reads
configuration information from a file called GOS.INI to find out what
files are to be loaded/used.
(d) GOS.INI
The GOS.INI file is unique for every GOS PC. From this file, the GOS
application receives its start–up parameters.
The file is read by the GOS application at start up (including both
GOSKRNL.EXE and GOSMM.EXE).
The file contains information such as whether the computer should
act as a GOS server, act as a GOS workstation, which stand
connections to activate, or whether time synchronisation shall be
made on the Safedock units from GOS.
(e) GOSUTIL.DLL
This is a resource file for all modules in a GOS system. It contains the
interface between GOSKRNL.EXE and its modules (SAFEDOCK.DLL
and COMLIDGS.DLL).
(f) SERVICELINK.DLL
This module allows GOSMMI.EXE to connect to GOSKRNL.EXE.
This link can also be used when other stand-alone programs need to
connect to GOSKRNL.EXE.
Page 6 of 12
(g) SAFEDOCK.DLL , SD_UDP.DLL, SD_TCPID.DLL and COMLIDGS.DLL

These modules manage the communication between GOS and
Safedock/Loop system. When a Safedock system is used, the
SAFEDOCK.DLL (Serial communication) or
SD_UDP.DLL/SD_TCPID.DLL (Ethernet LAN) module is used. When
a Loop system is used, the COMLIDGS.DLL module is used.
(h) SETTIME.DLL
This module manages the time synchronisation of the Safedock real-
time clock.
(i) SETUPCAL.DLL
This module manages a remote connection to Safedock with
SDConfig.exe.
(j) NETHUB.DLL
This module makes a PC computer act as the GOS server. Every
GOS system needs to have one server. When information is send
from a Concentrator to the server, it is the responsibility of the GOS
server to update the GOS workstation.
(k) NETNODE.DLL
This module makes a PC computer act as a GOS workstation. A
GOS system can have several workstations connected.
(l) DBKERNEL.EXE
This module communicates with the GOS database and provides
Safedock with flight information (schedules dockings)
(m) INTERLOCK.DLL
This module evaluates rules about what aircraft are allowed to dock
at a stand based on the status of adjacent stands.
(n) SCHEDULELINK.DLL
This module will schedule Safedock with flights received from FIDS. It
will also create Blocks On/Off messages after arrival/departure
dockings, which will then be forwarded to FIDS by the LAN module
(Extip3Client).
(o) EXTIP3.DLL
This module will receive flight information from FIDS. It will also send
Blocks On/Off messages to FIDS. Stand statuses can also be
reported to a maintenance system from this module.
(p) GOSFLIGHTDBLINK.DLL
This module is an internal flight database used in the GOS system.
All flights are stored in RAM or in a MySql database depending on
selected configuration type.
Page 7 of 12
FIS
FIGURE 2 - SOFTWARE CONFIGURATION
Page 8 of 12
4. STANDARD FEATURES
4.1 GENERAL
This section describes standard features included in a GOS system.
4.2 DOCKING MONITORING AND CONTROL
4.2.1 General
The primary purpose of the GOS system is Docking Control and Monitoring. At any
GOS subsystem the airport layout with stands and docking systems can be displayed
and monitored.
The Docking Control and Monitoring function is fully explained in the OPERATIONS
chapter.
The following commands are available:
• Open Stand
• Start of Docking
• Activation of a Scheduled Docking
• Park On
• Park Off.
4.3 GOS EVENT LOG FILES

4.3.1 General
Event Log files are created once per day with information and statistics which can be
used for monitoring/maintenance of the Safedock systems.
A docking procedure contains several events, which are stored with time stamps, for
example: DGS Ready; Active (aircraft, flight); Docking (aircraft, flight); Parked (aircraft,
flight, Reg No).
The name of a log file will be the year/month/day (date), with the format YYMMDD.log.
The files are stored automatically, one per day, and for a configurable period of time,
default period is thirty-two days. After the period has expired a file is automatically
deleted.
For more information, see the OPERATIONS chapter Event Logging facility.
4.4 AUTOMATIC UPLOAD OF SAFEDOCK DOCKING LOG FILES
4.4.1 General
Each docking with a Safedock generates a docking log. The docking log will
automatically be dumped to GOS at the end of each docking procedure, where it will
be retained for 30 days.
4.5 AUTOMATIC UPLOAD OF SAFEDOCK CONFIGURATION FILES
4.5.1 General
To store a backup of each Safedock unit configuration, the configuration files
(centreline and gate configuration) will automatically be dumped to GOS from
Safedock when the configuration has been updated in a Safedock unit.
4.6 SAFEDOCK MAINTENANCE
4.6.1 General
The maintenance tool, Sdconfig, used to configure/upgrade Safedock can be used
from a GOS Maintenance computer. For example, it can be used to perform a
centralized program upgrade in Safedock system at a site, thereby shortening
maintenance time.
Page 9 of 12
5. ENHANCED FEATURES (OPTIONS)

5.1 GENERAL
GOS functions can be enhanced with features such as:
• Redundant GOS servers
• FIS Interface
• TMS Interface
• RIDS Interface
• Support for cameras installed in Safedock systems
• Interlock
• and more.
5.2 REDUNDANT GOS SERVERS
To provide a more reliable GOS system, redundant servers can be used.
For more information, see Appendix B.
5.3 INTERFACE TO EXTERNAL SYSTEMS
5.3.1 FIS Interface
The GOS system can be connected to FIS to exchange flight information.
FIS will provide GOS with arrival and departure flight information and GOS will report
Block On/Off events to FIS upon successful arrival/departure docking.
5.3.2 TMS Interface
GOS can be connected to the Technical Management System (TMS) to provide TMS
with system status information of the various GOS and Safedock systems installed at
a site.
5.4 STAND IMAGES FROM CAMERA
5.4.1 General
Cameras can be installed with the Safedocks at the Stands. A separate Ethernet LAN
connection is required for communication to the GOS system. A PC computer or GOS
workstation is used for the presentation of any stand (Safedock/camera) images. One
or several Images can be displayed at a time.
Stand images can be synchronised with the docking monitoring function of GOS. For
example, when the Safedock has captured an approaching aircraft, the transmission
of stand images could be automatically started and logged, until the aircraft has come
to a parked position. For more information, see Appendix C.
5.5 INTERLOCK FUNCTION
5.5.1 General
With this feature, Start of docking for a stand can be blocked for operation based on
selected aircraft type and current status of adjacent stands.
Upon start of docking, either from GOS or locally from the operator panel, the GOS
system will evaluate, based on the status of adjacent stands, whether or not docking
shall be allowed.
The interlock evaluation is based on a series of blocking rules, which are configured
for each stand in GOS.INI. Whenever start of docking is requested, all the rules for
that stand must be evaluated, and if any of them are not fulfilled, the docking request
is denied. If GOS is unavailable upon start of docking, Safedock will ask the local
operator for a manual confirmation of the docking procedure. If no rules are specified
for the selected stand, the docking will always be allowed.
Page 10 of 12
Evaluation performance:
(a) A blocking evaluation can be done in the following states (for adjacent
stands): Active, Docking, Downgrade, Parked, Parked Last Bags, Interlock
Timeout, Interlock Unknown and Request interlock.
(b) A blocking evaluation can be done for the following errors: 13, 14, 15, 21, 23
and 24.
WARNING! FOR OTHER ERRORS, EVALUATION CANNOT BE DONE. IF
THE LOCAL OPERATOR TAKES FULL RESPONSIBILITY FOR SAFETY
ISSUES THE DOCKING PROCEDURE MAY BE CONFIRMED.
(c) A blocking evaluation cannot be done in the following statuses: Comm error,
Unknown, Emergency stop and Maintenance.
For other statuses, a stand is considered as empty, and docking will always be
allowed.
6. INSTALLATION
6.1 GENERAL
GOS workstations are normally installed at desks. The GOS server could be installed
in a cabinet, if required.
Power lines/outlets and System Earth lines shall be available close to the cabinet and
the PC desktop units.
Normally a LAN connection, 10/100BaseT, shall be available for the GOS server and
at each GOS workstation.
Page 11 of 12
Page 12 of 12
Document: 1A_GOS_SY_Topology Version: 1.3
CHAPTER 1: APPENDIX A
A GOS SYSTEM TOPOLOGY AND HARDWARE UNITS - EXAMPLE
CONTENTS
1.1 GOS SYSTEM TOPOLOGY (AN EXAMPLE) .................................................. 2
1.2 GOS HARDWARE SUB-UNITS (AN EXAMPLE) ............................................. 3
1.2.1 General ........................................................................................................ 3
1.2.2 GOS Server Hardware Items example ..................................................... 3
1.2.3 GOS Concentrator Items (used if non- LAN configuration) .................. 4
1.2.4 GOS Workstation Hardware Items ........................................................... 4
Page 1 of 4
1.1 GOS SYSTEM TOPOLOGY (AN EXAMPLE)

System components and their interconnection are shown in the following examples.
Ethernet LAN, 10BaseT connections
Patch cables to horizontal

network outlets, 10BaseT / RJ 45
GOS
Workstation 2 Operation
GOS
Workstation 1 Maintenance
GOS
Server
10BaseT / Cross-over cable (1)
Concentrator
(option)
Patch cable per modem (15)
Modem Rack
(option)
Option: Asynchronous
current loop 2-pair lines,
connected to SAFEDOCK
SAFEDOCK LAN Connections
FIGURE 1 - GOS SYSTEM TOPOLOGY
Page 2 of 4
1.2 GOS HARDWARE SUB-UNITS (AN EXAMPLE)

1.2.1 General
The GOS system is built up with the following components
(a) GOS Server
(b) Concentrator (if no LAN connection to Safedock exists)
(c) GOS Workstation for Docking Control
(d) GOS Workstation for Safedock Maintenance.
1.2.2 GOS Server Hardware Items example
Part No Qty Equipment Supplier

N/A 1 Optiplex GX240 1.6 GHz Tabletop Computer Dell
N/A 1 32 MB ATI Rage Ultra video card Dell

N/A 1 Documentation Optiplex ENGLISH Dell
N/A 1 3.5” Floppy Drive Dell
N/A 1 256MB RAM, Memory Dell
N/A 1 20.0 GB IDE Hard Drive Dell
N/A 1 20x48 Speed IDE CD ROM Reader/Writer Dell
N/A 1 Integrated 10/100 3COM Network card Dell
N/A 1 Keyboard, English Dell
N/A 1 MS PS/2 Mouse Dell
N/A 1 MS Windows 2000 Pro, SP2 ENG CD Dell
NTFS file system
34-1002 1 Extra LAN card 10 Mb Direktronik
N/A 1 Monitor: E771-17” Dell
SW621A-R2 1 Serv Switch (for Monitor, keyboard and Black Box

mouse) Corp.
RMK 19M 1 Rack Kit for Serv Switch Black Box
Corp.
EHN 151-0005 2 Serv Switch Cable (1,5 meters) Black Box
Corp.
EHN 151-0010 2 Serv Switch Cable (3 meters) Black Box
Corp.
Safeg4603 1 Floor cabinet Rittal
Note: A patch cable, 10BaseT/RJ-45, will be needed on site for the connection of
the Server to the LAN.
Page 3 of 4
1.2.3 GOS Concentrator Items (used if non- LAN configuration)

38-0001 0 Wall Cabinet Direktronik
38-0071 0 Cover Plate (accessory to Cabinet) Direktronik
SAFE4603 0 Floor Cabinet Rittal

24-0500 0 Rocket LAN (16 RS-232 COM ports), VS1000 Comtrol
24-0505 Rocket LAN Expansion (16 ports), VS1100 Comtrol
(Cable to main unit included)
05-6231 0 Patch cable 1m (cross-over cable, for the Direktronik
connection between the Concentrator and the
Server)
05-6239 0 Patch cable 10m (cross-over cable) Direktronik
RV-1 0 Modem Rack Frame with Power Supply Ritex
Mains: 230VAC, 50 Hz
R-1 0 Modem R-1 Ritex
590160 0 Modem Cable Safegate
1.2.4 GOS Workstation Hardware Items

N/A 2 Optiplex GX240 1.6 GHz Tabletop Computer Dell
N/A 2 32 MB ATI Rage Ultra video card Dell

N/A 2 Documentation Optiplex ENGLISH Dell
N/A 2 3.5” Floppy Drive Dell
N/A 2 256MB RAM, Memory Dell
N/A 2 20.0 GB IDE Hard Drive Dell
N/A 2 20x48 Speed IDE CD ROM Dell
N/A 2 Integrated 10/100 3COM Network card Dell
N/A 2 Keyboard, English Dell
N/A 2 MS PS/2 Mouse Dell
N/A 2 MS Windows 2000 Pro, SP2 ENG CD Dell
NTFS file system
N/A 2 Monitor: E991-19” Dell
Note: A patch cable, 10BaseT/RJ-45 connectors, will be needed (length to be

specified according to site conditions) for the connection of the server/workstation to
the LAN. Alternatives may be as follows:
(a) Cat5 Cable, 10metres, grey Part No. 05-6260, Direktronik
(b) Cat5 Cable, 20 metres, grey Part No. 05-6271, Direktronik.
Page 4 of 4
Document: 1B_GOS_SY_Redundant Version: 1.3
SYSTEM DESCRIPTION: APPENDIX B

REDUNDANT GOS SERVER
CONTENTS
1. SCOPE .......................................................................................................................... 2
2. TECHNICAL CONCEPT ............................................................................................... 2
2.1 GENERAL ......................................................................................................... 2
3. OPERATION .................................................................................................................. 4
3.1 SYSTEM START UP ........................................................................................ 4
3.1.1 General ........................................................................................................ 4
3.1.2 File Synchronization at Start up ............................................................... 4
3.1.3 Flight Synchronization at Start up ........................................................... 4
3.2 NORMAL SYSTEM OPERATION..................................................................... 4
3.2.1 General ........................................................................................................ 4
3.2.2 Continuous File Update............................................................................. 4
3.2.3 Continues Flight Update ........................................................................... 5
3.2.4 Connection to External Systems .............................................................. 5
3.2.5 Connection to Internal Systems ............................................................... 5
3.3 SYSTEMS SWAPPING DURING NORMAL OPERATION .............................. 5
3.3.1 General ........................................................................................................ 5
3.3.2 Swap Criteria .............................................................................................. 5
3.3.3 File Updates ................................................................................................ 5
3.3.4 Re-connection to External Systems ........................................................ 5
3.4 SYSTEM STATUS DISPLAY ON GOS HMI ..................................................... 6
Page 1 of 6
1. SCOPE
This document is a functional description of the redundant Central Docking Computer
System/GOS, being the gateway between Safedock systems and external control and
monitoring systems with a central location.
2. TECHNICAL CONCEPT
2.1 GENERAL
The Central Docking system consists of two redundant GOS servers. These two
servers will work in parallel. When both computers are running, one of them will be the
Active server and the other one will be the Standby server.
The Active server will handle the communication with all external systems, while the
Standby server will be logically disconnected (by software) from external systems.
If the Active server for any reason goes down, the Standby Server will become the
Active server and re-establish connection with external systems.
For the two servers, to determine the overall status, Keep-Alive transactions are sent,
once per second, in both directions between the Active server and the Standby
server, using the external network.
Active-to-Standby swap time will depend on IP disconnect and reconnect time of the
external systems. Disconnect and reconnect time regarding Safedock units is
approximately 15-60 seconds. Data from a Safedock will be buffered during this time,
as the GOS server gets data by a polling method.
The figure below is a state diagram, illustrating Computer A and Computer B states,
being Main, Standby or a Failing units.
Computer A Start Computer B
StandBy StandBy
do/ Exchange Status do/ Exchange Status

do/ Synchronice DB do/ Synchronice DB
Yield Swap Yield Swap
Main Main
do/ Exchange Status do/ Exchange Status

do/ Update StandBy DB do/ Update StandBy DB
Fail Fail
Fail Fail
FIGURE 1 - GATEWAY STATES
Page 2 of 6
The figure below is a detailed state diagram of computer A or B.
Start
StandBy
Init
do/ Deactivate Gateway (Links)
Main found[ First time ]

Gateway Status Monitor
Sync
do/ Send Status Standby DB
do/ Receive Status
Main found No Main found in random time
Main
No other main[ First time ]

Gateway Status Monitor Init
do/ Send Status do/ Activate Gateway (Links)

do/ Receive Status
FIGURE 2 - SWAP CONDITIONS AND ACTIVITIES
Page 3 of 6
3. OPERATION
3.1 SYSTEM START UP

3.1.1 General
When a server computer starts up, it will enter the Standby mode and try to exchange
Status information with the other server computer. If no Active server is found on the
network after a random period of time, the computer will become the Active server
and establish connection with external systems. If an Active server already exists on
the network, the newly started server will enter Standby mode, and a data
synchronization operation between the two servers will be initiated (described below).
This is the initial procedure at start up for both computers.
Note: Database synchronization described below only takes place when a database
is used in the GOS system.
3.1.2 File Synchronization at Start up
When the standby server connects to the active server, the standby server will start to
synchronize some of its file directories with corresponding file directories on the active
server. The directories to be synchronized are configurable.
The following files are to be synchronized:
(a) GOS event log file, ”date.log”
These files will be copied from the Active server to the Standby server only if
the file on the Active server is newer.
(b) Safedock configuration files, ”standname.gte” and “standname.sdc”
(c) Safedock log files, ”standname_date_time.sdl”.
3.1.3 Flight Synchronization at Start up
(a) GOS equipped with SQL Database
Through a replication mechanism, the Standby server will be populated with
flight data from the Active server.
(b) No SQL database used
When GOS is connected to a FIS system providing GOS with current
arrival/departure flight information prior to docking, all flights sent to GOS are
double-stored in the Safedock system. Upon start-up the newly ACTIVE
server will collect current flights (arrival and departure) from each Safedock.
3.2 NORMAL SYSTEM OPERATION

3.2.1 General
This is the scenario where both servers are up and running. One server is the Active,
and the other one is Standby.
3.2.2 Continuous File Update
During normal operation certain file updates take place between the two servers. The
Active server will notify the Standby server about file updates that take place on the
Active server. The Standby server will then copy (read) the updated/new files from the
Active server.
The following files will be updated:
(a) GOS event log file
(b) Safedock Log
(c) Safedock configuration files (.gte and .sdc files)
Page 4 of 6
3.2.3 Continues Flight Update

(a) GOS equipped with SQL Database
During normal operation the database on the Standby server will be updated
by the Active server.
(b) No SQL database used
Each flight sent to GOS for a specific stand double-stored in the Safedock
system.
Note: Limitation - Unsent Blocks On/Off records are only buffered in RAM on
the Active server until successfully sent to FIS. Thus, if the Active server
breaks down buffered messages will be lost.
3.2.4 Connection to External Systems
The Active server will establish connection to external systems. External systems are
Safedock units and FIS. The Standby server will be disconnected from all external
systems.
3.2.5 Connection to Internal Systems
Internal Systems means workstations, built on the GOS concept. These are all
connected to both the Active and the Standby Central Computer. Only the active
server sends HMI information. The workstation only sends commands to the active
server.
3.3 SYSTEMS SWAPPING DURING NORMAL OPERATION

3.3.1 General
This is the scenario where the Standby server no longer detects the Active server on
the network, or in the case that both servers detect each other as being the Active
server.
3.3.2 Swap Criteria
(a) If the Standby server does not receive any Keep-Alive transactions within five
seconds from the Active server, the Standby server will switch state and
become Active. This may be due to the following:
(i) Computer break-down or Power failure
(ii) LAN Adapter break-down
(iii) One or several software items are not running properly. However the
NTP client cannot be tested this way.
(b) Both servers detect each other as being Active: The server with the fewest
connections to Safedock units will yield and become Standby.
3.3.3 File Updates
Servers will perform the same file synchronization as within a system start up, as
described previously.
3.3.4 Re-connection to External Systems
When a system swap has occurred, and both servers have found their roles (Active
and Standby), both servers will then perform the same action as within normal system
operation. The connection to each external system will be performed according to the
respective interface specification.
Any Blocks On/Off data sent to GOS, during the time when neither of the two servers
had connections to Safedock systems, will be lost.
Page 5 of 6
3.4 SYSTEM STATUS DISPLAY ON GOS HMI

The current system status for both servers can optionally be displayed in the GOS
monitor software GOSHMI during operation.
When configured on Maintenance workstations and/or servers, there will be two status
buttons visible on the screen, representing the Active and the Standby server. In case
of a system swap or a hardware failure, the status buttons will start to flash and will
continue to do so until acknowledged by the user.
The Server Status Display is described in chapter 3. OPERATION.
Page 6 of 6
Document: 1C_GOS_SY_Camera Version: 1.3
SYSTEM DESCRIPTION: APPENDIX C

CAMERA INTEGRATION
CONTENTS
1. INTRODUCTION ........................................................................................................... 2
1.1 GENERAL ......................................................................................................... 2
2. EXTENDED FUNCTIONALITY OF GOS ...................................................................... 2
2.1 PURPOSES OF USING GOS........................................................................... 2
2.2 VIEWING AND LOGGING STAND IMAGES USING CAMERAS .................... 3
2.2.1 General ........................................................................................................ 3
2.2.2 Camera ........................................................................................................ 3
2.2.3 Communication .......................................................................................... 3
2.2.4 GOS Monitor screen .................................................................................. 3
2.2.5 Image Logging ........................................................................................... 4
3. SYSTEM ARCHITECTURE ........................................................................................... 4
3.1 GENERAL ......................................................................................................... 4
3.2 SYSTEM SUB-UNITS ....................................................................................... 4
3.2.1 General ........................................................................................................ 4
3.2.2 Camera Hardware ...................................................................................... 4
3.3 GOS TOPOLOGY ............................................................................................. 4
3.3.1 GOS Sub-Units Interconnection ............................................................... 4
4. CONFIGURATION......................................................................................................... 6
4.1 CONFIGURING THE CAMERA ........................................................................ 6
4.2 CAMERA SPECIFICATION .............................................................................. 6
Page 1 of 6
1. INTRODUCTION
1.1 GENERAL
The Central Docking Control System or Gate Operating System (GOS) can be
upgraded with Cameras for Stand Surveillance.
This document describes how to upgrade the infrastructure, LAN, needed and how to
integrate the Stand Surveillance system, the Cameras, and the associated software in
the GOS system.
2. EXTENDED FUNCTIONALITY OF GOS
2.1 PURPOSES OF USING GOS
Main purposes of using GOS are as earlier and according to the tables below,
updated with the Stand Surveillance Feature, highlighted below.
General Purposes Realisation

- Central Stand Monitoring The GOS Monitor
- Central DGS Error Log, System The GOS Logging Feature

Event Log and Docking Log
-
- Central Maintenance of SAFEDOCK The Stand Configuration Utility and the
Stand Config PrintOut Utility
- Status Report to a Central Interface GOS – CMS (option)
Maintenance System
- Airfield Lighting Control Interface GOS – SMGCS (option)

- Push-back info to Ground Radar Interface GOS – SMGCS (option)
- Stand Surveillance The Stand Images Viewing and

Logging Feature, using digital
Cameras
At arrivals the following functions are realised with the GOS system:
Functions at Arrivals Realisation

- Capture of Aircraft Type to be docked Data Entry at GOS Workstation
- Check of Aircraft Type to be docked Data gained from a FIS connection*
to a specified Stand
- Capture of Flight No. Data Entry at GOS Workstation (option)
Data gained from a FIS connection
- Capture of Registration/Tail No. Data Entry at GOS Workstation (option)
Date gained from a FIS connection*
- Initiation of the Docking Procedure Entry of Command (aircraft type) from
GOS Workstation
- Capture of failures The Stand Images Viewing and
Logging Feature, using digital
Cameras
- Capture of Blocks On Time GOS – interface to FIS
-
Page 2 of 6

-
- Managing the Stand event PARKED Entry of Command from GOS
after an aircraft ground movements Workstation.
At departures the following functions are realised with the GOS system:
Functions at Departures Realisation
- Capture of Flight No. Data Entry at GOS Workstation
- Capture of Registration/Tail No. Data Entry at GOS Workstation
- Capture of Blocks Off Time GOS – interface to FIS
- Display of flight information GOS – interface to FIS
- Managing the Stand event PARK Entry of Command from GOS

OFF after an aircraft ground Workstation
movements
*Note: ‘FIS connection’ means a FIS workstation or, optionally, a data interface FIS-
GOS.
2.2 VIEWING AND LOGGING STAND IMAGES USING CAMERAS

2.2.1 General
Optionally, cameras can be installed with the Safedock systems at the Stands. A
separate Ethernet LAN connection is required for the communication to the GOS
system. For maximum throughput 100BaseFX is needed.
2.2.2 Camera
A digital camera will be used, sending stand area images, one per second (for
example) to one or several PC-monitors (or GOS workstations) connected to a
network. The camera will work as a ‘Stand image server’, using TCP/IP
communication to the Monitor PCs and GOS, the Camera clients.
Resolution is 320 x 240 pixels, normally, but can be set to 640 x 480 as well.
Stand image resolution and frequency depends on the availiable network loading and
disc storage capacity.
2.2.3 Communication
The camera system is connected to an Ethernet LAN 10-100 Mbps using an RJ-45
connector, (CAT 5 cable from camera to hub, maximum 90 metre, is not included in
the standard delivery of material). Load on the network would be approximately 10 kB
data per image and client. For more information, see to the Camera Specification
section.
2.2.4 GOS Monitor screen
A PC computer or GOS workstation is used for the presentation of images from any
Stand/Camera. One or several Images can be displayed at the same time (maximum
4 pictures can be displayed simultaneously).
Page 3 of 6
2.2.5 Image Logging

Stand images can be synchronised with the docking monitoring function of GOS. For
of stand images could be automatically started and logged, until the aircraft is in a
parked position.
Depending on disc space available and image back-up frequency, stand images could
be retrieved from docking events back in time.
3. SYSTEM ARCHITECTURE
3.1 GENERAL
All Safedock status transactions are distributed around the GOS system nodes, over
an Ethernet LAN, and at the same time, all subsystems have complete information
about the status of all Safedock systems at all the connected terminals and remote
stands.
Some stands may be equipped with digital Cameras, which are connected to a LAN,
sending stand images to the GOS system. These images can be monitored, and are
also automatically logged during a docking sequence until completed.
3.2 SYSTEM SUB-UNITS
3.2.1 General
The main components of GOS systems are PC computers. Several workstations may
be connected to a LAN for multi-client usage. Cameras are also connected to a LAN
at each stand, where the stand area can be viewed from any GOS workstation.
The physical communication media is preferably Ethernet 10-100 MHz with TCP/IP
protocol.
3.2.2 Camera Hardware
The following hardware is used.
Item Qty Materials Notes

1 Camera Axis 211 Axis
2 Camera housing HPV42K0A017 Axnet AB
3.3 GOS TOPOLOGY

3.3.1 GOS Sub-Units Interconnection
The following figure illustrates docking systems updated with cameras, connected to
an Ethernet LAN. In this case the docking systems have previously been installed
using 2-pair communication lines, handled by GOS Concentrators and short haul
modems.
If a LAN is available at installation, docking systems are connected according to the
10BaseT specification.
Page 4 of 6
An example of Sub-Units and their interconnections are shown below.
12 Safedock units
Fibre Hub
12 Cameras*
10BaseT (max 90 metres)
GOS workstation
Fibre Hub GOS server

<128 Stands/Safedock
Concentrator
16 Stands/Safedock
Concentrator
32 Stands/Loop DGS
Fibre to AUI Converter/Transceiver
Hub (max 90 metres) 16 Cameras*
Fibre 10BaseT
Concentrator 16 Safedock
(Ethernet COM)
Units previously installed

*Note: A central location for the Hub is needed, as max line length of CAT 5 cable is 90 meters.
‘Ethernet COM’ means 16 COM ports connected to the Ethernet LAN, which can be expanded to 64
ports.
FIGURE 1 - SUB-UNITS AND INTERCONNECTIONS
Page 5 of 6
4. CONFIGURATION
4.1 CONFIGURING THE CAMERA
For more information, see the Safedock manual kit for a description of how to
configure the camera in the Safedock unit.
For more information, see the GOS manual kit for a description of how to configure
GOS for camera operation.
4.2 CAMERA SPECIFICATION
For more information, see current documentation for “AXIS 211/211A Network
Camera” from Axis Communication AB at www.axis.com.
Page 6 of 6
Document: 1D_GOS_SY_Interface Version: 1.3
SYSTEM DESCRIPTION: APPENDIX D

INTERFACE – (OPTIONS)
CONTENTS
1. INTRODUCTION ........................................................................................................... 2
1.1 ABBREVIATIONS ............................................................................................. 2
1.2 OBJECTIVE ...................................................................................................... 2
1.3 PROTOCOL ...................................................................................................... 3
1.3.1 Overview ..................................................................................................... 3
1.3.2 OPC Data Access Server .......................................................................... 3
1.4 A-VDGS IN A STANDARDIZED CONTROL SYSTEM..................................... 4
1.4.1 Overview ..................................................................................................... 4
1.4.2 A-VDGS in Operational Mode ................................................................... 4
1.4.3 A-VDGS in Maintenance Mode ................................................................. 5
2. REDUNDANCY ............................................................................................................. 6
2.1 OVERVIEW ....................................................................................................... 6
2.2 OPERATION ..................................................................................................... 6
Page 1 of 6
1. INTRODUCTION
1.1 ABBREVIATIONS
Abbreviations are used in this document.
A-VDGS Advanced Visual Docking Guidance System (also Safedock or
DGS)
BTA Best time for arrival
BTAD Best time available for arrival or departure. This is the most
accurate time available in the FIS system when an aircraft arrives
or departs to/from a gate. CDI uses this time internally to determine
when it’s time to initiate a docking procedure.
BTD Best time for departure
CDI Common Docking guidance system Interface
DGS Docking Guidance System (also Safedock or A-VDGS)
FIS Flight information system
ICD Interface control Document
OLE Object Linking and Embedding
OPC OLE for Process Control. A standard for data exchange between
computers.
STA Scheduled time of arrival
STAD Scheduled time for a flight, arrival or departure.
STD Scheduled time of departure
TMS Technical management system (Maintenance system)
1.2 OBJECTIVE
The objective of this document is to give a detailed description of how an external
application, such as TMS or FIS can get access to VDGS status and flight data using
an OPC interface, CDI (Common Docking guidance system Interface).
The overall architecture of the systems and the interface between them is described in
the following diagram:
TMS
A-VDGS (OPC Client)
CDI TMS
A-VDGS
(OPC Server) (OPC Client)
A-VDGS FIS
(OPC Client)
Note: There may be multiple TMS clients connected to each Safedock A-VDGS for
status and error information, but there may only be one client for flight information for
each CDI.
Page 2 of 6
1.3 PROTOCOL
1.3.1 Overview
All Safedock systems are connected to the common CDI system, which acts as a
common point of access to the Safedock units from other systems, such as FIS.
Safedock status and flight data is exchanged between the CDI and the external
system using an OPC Data Access 3.00 (OPC-DA) interface, where the CDI is acting
as an OPC-DA server.
The CDI uses OPC-DA to publish the current status and error code for each individual
Safedock device to connected clients. Multiple clients can subscribe to this
information from each Safedock. The CDI also accepts control commands, text
commands, and flight schedule data and delivers blocks on/off events via OPC-DA.
This data exchange only accepts one connection. The CDI OPC server can run on the
Windows XP platform. The CDI can be run in a redundant configuration to avoid
single point of failure.
1.3.2 OPC Data Access Server
The OPC-DA Server is compliant to the OPC Foundation Data Access Custom
Interface Standard Version 3.00 and is validated using OPC Foundation compliance
tools.
Page 3 of 6
1.4 A-VDGS IN A STANDARDIZED CONTROL SYSTEM

1.4.1 Overview
A Safedock system has two distinctly different working modes: operation and
maintenance. The operational mode is when a Safedock is used to assist in the
parking of aircraft and maintenance mode is when the Safedock system is configured
to be able to operate.
1.4.2 A-VDGS in Operational Mode
This interface represents the sum of required functionality by all of the Safedock
systems. Some of the data is not be needed by all docking guidance systems, as it is
needed/provided only by the more advanced Safedock systems.
The interface should include the following basic operations and data:
• Activate/deactivate a docking operation.
In addition, the interface should contain the following optional operations and data, as
may be required by some docking guidance systems:
• Aircraft type
• Flight number
• Aircraft tail registration number
To support extended functions of the Safedock A-VDGS, the interface could also
include:
• Text display commands to the Safedock.
The interface shall also allow a Safedock to report basic status such as:
• Ready
• Active
• Error
The interface can also allow optional advanced information that can be provided by
some docking guidance systems:
• Out of Service/Maintenance
• Aircraft parked
• Aircraft block on/off
• Aircraft type expected/parked
• Flight number
• Tail registration number
The similarities and relative simplicity of the Safedock operational mode for docking
guidance means that the operator can relatively quickly be trained/gain knowledge for
the Safedock system used at each particular stand the control system operates.
Page 4 of 6
1.4.3 A-VDGS in Maintenance Mode

Safedock A-VDGS systems are based on very different technologies such as Laser,
Camera, or Optical parallax. Some systems also support various value-adding
functions, such as apron scanning, multiple centrelines and text display.
The big difference in technology and capability means that the different docking
guidance systems have very different needs and procedures for installation and
configuration. In addition, an A-VDGS system is an advanced piece of equipment that
requires special training for the maintenance personnel that shall perform
configuration and support of the units. This may be different for the different types of
Safedock A-VDGS systems.
All of these factors mean that it is impossible to find a common ground for a
maintenance system for A-VDGS units. There is always a need for system specific
maintenance or configuration operations and a need for trained personnel for the
configuration and maintenance of these systems. Any attempt to standardize this is
likely to result in limiting the abilities and future development of the A-VDGS systems
and their maintenance tools by forcing the manufacturers to keep within the limits
allowed by the standardization.
A-VDGS A-VDGS A-VDGS
...
(redundant A-VDGS Communication Gateway)

A-VDGS Communication Gateway
Ifc: OPC-DA Ifc: A-VDGS

(Server) Maintenence
IAS / SCADA Server
IAS IAS IAS A-VDGS

Work- Work- Work- Maintenance and
station station ... station Configuration
workstation
SYSTEM ARCHITECTURE FOR A-VDGS,

RUNNING IN AN IAS/SCADA CONTROLSYSTEM.
Redundancy in the system can be achieved by making the A-VDGS a redundant

application running on 2 hardware units. The connectivity between the gateway and
the individual A-VDGS units is a standard network, which also can be built in a
redundant ring topology to avoid single point of failure situations.
In the system, there can be zero to many IAS workstations connected at any given
time.
Page 5 of 6
2. REDUNDANCY
2.1 OVERVIEW
Redundancy on A-VDGS data is provided by having two parallel CDI systems. One
CDI is active and has connections to the individual A-VDGS units while the other is in
stand-by mode, synchronized with data from the active CDI. Upon a failure of the
active CDI, the standby unit is ready to immediately take over the full operation of the
system.
TMS
A-VDGS (OPC Client)
A-VDGS CDI-A TMS

(Active) (OPC Client)
A-VDGS FIS
CDI-B
(Stand-by) (OPC Client)
2.2 OPERATION
Redundancy is made possible, with support from IAS, by having the CDI servers
reporting a data quality value together with the exported data. The Active server
always reports perfect quality, while the standby server reports bad quality on its data
items.
Both CDI servers are normally available, and the quality of the data is used to
determine what data to be used by the applications. To make this transparent to the
end application (users), the IAS system includes support for redundancy. IAS sees
both CDI systems and only allows the one with best quality available to its
applications.
Redundancy structure:
CDI Servers IAS system Applications
CDI-A OPC Client 1

OPC Server 1
Redundant TMS/FIS/ …
DI-Object
CDI-B OPC Client 2
OPC Server 2
In the IAS system:

- Two OPC Client objects need to be configured in IAS, each connected to one of
the redundant CDI OPC Server. Configuration of scan groups and attributes/block
reads/block writes should be mirrored.
- One Redundant DI Object needs to be configured in IAS to use the two OPC
Client objects as DI Source. The scan groups and attributes/block reads/block
writes should be mirrored from the OPC Client objects.
- The underlying IAS application(s) communicates with the OPC servers through
the Redundant DI Object, making the actual CDI servers transparent to the
application.
Page 6 of 6
Document: 2_ GOS_INSTALLATION Version: 1.3
CHAPTER 2
INSTALLATION
CONTENTS
1. INTRODUCTION ........................................................................................................... 3
1.1 GENERAL ......................................................................................................... 3
1.2 INSTALLING WINDOWS XP-PRO/2003-SERVER .......................................... 4
1.2.1 General ........................................................................................................ 4
1.2.2 Configuration Settings .............................................................................. 4
1.2.3 GOS configuration ..................................................................................... 5
2. GOS APPLICATION SOFTWARE ................................................................................ 6
2.1 SOFTWARE PACKAGE STRUCTURE ............................................................ 6
2.2 GOS DATABASE SETUP (OPTION)................................................................ 6
2.2.1 General ........................................................................................................ 6
2.2.2 Installing MYSQL Database ...................................................................... 6
2.2.3 Installing MySql Administration Tools .................................................... 7
2.2.4 Creating the Database ............................................................................... 7
2.3 GOS SOFTWARE SETUP ................................................................................ 9
2.3.1 DB Express Setup ...................................................................................... 9
2.3.2 Standard GOS Software Setup ................................................................. 9
2.3.3 Non-Standard Interface Software ............................................................. 9
2.3.4 GOS Access Manager Setup .................................................................... 9
2.3.5 SDK Maintenance Software Setup ........................................................... 9
2.4 SHARED DIRECTORIES ............................................................................... 10
2.5 DEVICE DRIVER INSTALLATION FOR DEVICEMASTER-RTS................... 10
2.5.1 Hardware Installation............................................................................... 10
2.5.2 Software Driver Installation .................................................................... 10
2.6 COM-PORT TEST .......................................................................................... 11
2.7 GOS KERNEL AS A SERVICE....................................................................... 11
2.7.1 General ...................................................................................................... 11
2.7.2 Configuring the GOS Kernel Service ..................................................... 11
2.7.3 Verifying the GOS Service Set-up .......................................................... 11
2.8 CAMERA SOFTWARE ................................................................................... 12
2.8.1 General ...................................................................................................... 12
2.8.2 Installing Camera Software ..................................................................... 12
2.8.3 Configuring Camera in Safedock ........................................................... 12
2.9 USER RIGHTS AND PASSWORD ADMINISTRATION ................................. 12
2.9.1 General ...................................................................................................... 12
2.9.2 Creating Windows Users ........................................................................ 13
2.9.3 Creating GOSHMI Users .......................................................................... 13
2.10 CONFIGURING AUTO LOGON ..................................................................... 13
2.11 TIME SYNCHRONIZATION OF COMPUTERS ............................................. 13
2.11.1 General ...................................................................................................... 13
2.11.2 Configuring the NTP Client ..................................................................... 13
Page 1 of 16
3. BASIC VERIFICATION OF SOFTWARE CONFIGURATION .................................... 14

3.1 GENERAL ....................................................................................................... 14
3.2 VERIFICATION OF GOSKRNL SOFTWARE ................................................. 14
3.2.1 Verifying the GOS.INI file Configuration................................................ 14
3.2.2 Verifying the Gos Kernel Service User Set-up ...................................... 14
3.2.3 Verifying the Automatic Service Start-up .............................................. 14
3.2.4 Verifying File Synchronization Between Servers ................................. 14
4. VERIFICATION OF DATABASE SOFTWARE ........................................................... 15
4.1 GOS DATABASE CONNECTION TEST ........................................................ 15
4.2 VERIFICATION OF SAFEDOCK CONFIGURATION SOFTWARE ............... 15
4.2.1 Connection Test ....................................................................................... 15
Page 2 of 16
1. INTRODUCTION
1.1 GENERAL
This manual is an instruction that shall be used when system software has to be re-
installed, for example after the resolution of a hardware or software failure.
The following installation instructions are included:
(a) OS related parameters of GOS server and workstations
(b) Configuration of HMI
(c) Installation of GOS application software
(d) Time Synchronization of Computers
(e) User Rights and Password Administration
It is assumed that maintenance personnel are familiar with MS Windows. Regarding

installation of the operating system, configuration data only is provided in instructions.
For the installation of GOS specific components such as GOS software, creation of
GOS users and time synchronization of computers, an installation program called
Gosinstall.exe is provided.
The installation program together with other GOS software is provided on a CD ROM.
Note: It is recommended to perform the installation in the order as described in the

manual.
Page 3 of 16
1.2 INSTALLING WINDOWS XP-PRO/2003-SERVER

1.2.1 General
Each GOS computer delivered by Safegate is supplied with an installation CD as
provided by the computer equipment manufacturer. This CD-ROM shall be used
whenever the Windows Operating System (or Windows XP-Pro/2003-Server OS)
needs to be re-installed. It is recommended not to make any special Windows
configurations that may interfere with the GOS operations. It is also recommended
NOT to install any added features that may be available on the CD-ROM that will not
be used on the GOS computer.
Configuration settings only will be described in this manual.
1.2.2 Configuration Settings
1.2.2.1 Computer Name, Workgroup, and Organization:
The GOS software installation does not require any special names of the GOS
computers. Instead, it relies on the installer to determine the GOS installation type for
the target computer for GOS operations as desired for that computer. If there are no
computer names given to the GOS server and/or GOS workstations, the list below
provides some suggested names.
Name and Organization:
Name: Same as computer name (see below)
Organization: ‘Name of the airport’
Computer and Workgroup name (recommended names):
Computer Names: Suggested computer names are shown below (your
system administrator can supply alternate names).
GOSSERVER1 For main GOS-Server
GOSSERVER2 For redundant GOS-Server (if
used)
GOSWS1 For GOS-Workstations
GOSWS2
GOSWS3...
GOSMAINT
Workgroup Name: If no name was provided by your system administrator,
it is recommended to use: GOS.
1.2.2.2 GOS Installation Types
The GOS installation types will be listed in the computer type selection screen of the
GOS software installation procedure. The installer should select the correct type as
determined for the target computer where the software will be installed. In general,
the software is common for all GOS installation types, although the configuration
changes depending on the GOS operations are as desired for that computer.
The list below provides some examples of GOS installation types:
GOS_Server1: Main GOS server.
GOS_Server2: Alternate/redundant GOS server (if supplied).
MaintDock: GOS workstation, allows view of GOS/A-VDGS status,
activation of aircraft docking, and maintenance.
GOS_MaintOnly: GOS workstation, allows view of GOS/A-VDGS status and
maintenance (no aircraft docking).
GOS_MonitorDock: GOS workstation, allows view of GOS/A-VDGS status and
activation of aircraft docking.
GOS_MonitorOnly: GOS workstation, allows view of GOS/A-VDGS status.
Page 4 of 16
1.2.2.3 Network Card Setup

Any GOS computer will have at least one network card or built-in Ethernet hardware
(with RJ45-port). It is a standard recommendation to have two Ethernet connections
in the GOS-Server: one for the GOS network to all GOS workstations and
concentrator units and another for the external connections to FIS and/or NTP. The
network setup varies from site to site based upon customer preference, network
configurations, and/or network security.
The following are suggestions for use of the network card in a typical GOS system:
Network Card 1 (GOS computers): Use for GOS/A-VDGS LAN
Network Card 2 (FIS LAN): Use for external connections such as FIS,
NTP and more.
Note: IP addresses and other network details may also be assigned and configured
by the network manager or system administrator.
1.2.2.4 Hard Disk Setup
The NTFS file-system shall be used on all GOS computers to allow proper operation
and file-sharing restrictions.
1.2.2.5 Users and Administrator Password Setup
See the User Rights and Password Administration section in this document.
1.2.3 GOS configuration
Each GOS Computer executes the same GOS application software, but with different
types of configurations, depending on its specific functionality in the GOS system.
The GOS.INI file determines the configuration, and especially the HMI layout.
For more information, see the configuration procedure is as described in Appendix A.
Page 5 of 16
2. GOS APPLICATION SOFTWARE

2.1 SOFTWARE PACKAGE STRUCTURE
The application software package for the entire GOS system is delivered on a CD
ROM, and must be installed on each GOS computer.
Each computer shall have its own directory for software found on the CD ROM
(unique software only if required). The CD ROM also contains a COMMON directory
where software files common to all PCs in the GOS system reside.
GOS software is built around items called GosKrnl and GOSHMI, which are common
to all subsystems, and one unique configuration file for each subsystem, called
GOS.INI. GosKrnl also uses a number of modules (DLLs and EXE files). The GOS.INI
file on each PC specifies the modules that will be used on each PC.
Other files/drivers essential to the GOS system are also included in the directories.
Software package Name
(a) GOS Kernel GosKrnl.exe
(b) GOS Monitor/HMI: GosMmi.exe
(c) Configuration File for each PC Gos.INI
(d) GOS modules for each PC DLLs and EXE files
(e) Driver files essential to GOS
2.2 GOS DATABASE SETUP (OPTION)
2.2.1 General
The GOS server/servers have an SQL database installed, which is used to store flight
information received from a FIS system.
Setting up the GOS database includes the following steps:
(a) Installing MySql database
(b) Installing MySql Administarator
(c) Installing MySql Query Browser
(d) Creating the GOS database.
2.2.2 Installing MYSQL Database
Log on to Windows as user Administrator on the server (the database shall only be
installed on the server/servers).
Start Gosinstall.exe and select the Install MySql Database option and click START.
The following settings shall be made throughout the installation:
(a) Setup Type: select Typical
(b) MySql Sign-up: select Skip Sign-Up
(c) Select Configure the MySql Server now
(d) Select Standard configuration
(e) Select Install As Windows Service and accept default service name.
(f) Select Launch the MySql Server automatically
(g) Select Include Bin Directory in Windows path
(h) Select Modify Security Settings
(i) Enter the password: manager for root user
(j) Uncheck Enable root access from remote machines
(k) Uncheck Create An Anonymous Account
(l) Click Finish to complete the installation.
Page 6 of 16
2.2.3 Installing MySql Administration Tools

Together with the MySql database, a set of user tools are supplied that can be used
when working with the database. For more information, see MySql documentation for
a complete description of how to use the tools.
Start Gosinstall.exe and select the Install MySql Administration Tools option,
press START and follow instructions that appear.
2.2.4 Creating the Database
2.2.4.1 Creating an SQL connection to the database
The GOS application needs an SQL connection to be able to communicate with the
database.
Create an SQL connection to the database

Perform the following to create the connection to the database.
(a) Start MySql Query Browser from the
Programs\MySQL menu and a dialog
window appears.
• If this is the first time the program is
being run proceed to step (b) to
create a SQL connection.
• If the program has previously been
run, select from the Stored
Connection drop down menu, the
connection Local host and proceed
to step (e).
(b) To create the SQL connection, press

the … button as in previous window
and an Options window appears.
(c) Click Add new Connection,
using the Connection Parameters
tab, enter information in the fields:
Connection: Local host
Username: root
Password: manager
Hostname: localhost
Port: accept default
Type: accept default
Schema: GOSDB
(d) Click Apply to create the new connection, click Close to exit the configuration
wizard and continue with the log on procedure using the newly created
connection.
(e) Enter the password, manager, and click OK to log on to the database.
If requested, accept to create GOSDB schema.
(f) From Windows, browse to a bat file located on the installation CD in directory
Software\Common\Sqlscript\MySqlCreateGosDb.bat.
Double-click the file to load several sql script files into the editor at once.
If no error message appears in the dialog footer, the scripts ran without a problem.
Page 7 of 16
Generate the database

• To create the database and its tables, run the file MySqlCreateGosDb.bat using
Windows Explorer.
The path to the file/directory location is: CDROM:\Software\Common\Sqlscript.
Note: This file may require 10 – 20 seconds to run, information appears when
completed.
Set up Replication (if redundant GOS servers are used with MySql)
If the server is to use MySql replication, the following steps must be performed:
(a) Using notepad.exe, open the file my.ini in the MySQL installation directory,
c:\Program Files\MySQL\MySQL Server 5.0.
(b) Find the section [mysqld] (Note: do not confuse with the section named [mysql])
and insert the following lines directly after the [msyqld]-header:
#enable bin-log
log-bin=mysql-bin
server-id=1
relay-log=relay-bin
#don’t start slave threads
skip-slave-start
expire_logs_days=20
master-connect-retry=30
(c) If installing server A, set the server-id value to 1, as in the example above.
If installing server B, the value must be set to 2.
(d) Save and close the file.
(e) Restart the server.
Page 8 of 16
2.3 GOS SOFTWARE SETUP

2.3.1 DB Express Setup
The GOS application uses a third-party component to communicate with the
database. Install the software as follows:
(a) Start Gosinstall.exe.
(b) Select Install Core Labs MySql Driver.
(c) Click START.
(d) Follow instructions that appear and accept default settings during the installation.
2.3.2 Standard GOS Software Setup
• Log on to Windows as an Administrator.
If GOS software (previous version) already exists, it must be shut down before any
new software can be copied. Perform the following on each GOS computer:
(a) Shut down the GOSMMI application by pressing Alt and F4 keys and confirm
the action. The GosKrnl service will be automatically shut down by the installation
program.
(b) Install software as follows:
(i) Start the program Gosinstall.exe.
(ii) Select Install GOS Software.
(iii) From the drop down menu, select desired computer to install software for.
(iv) Click START.
2.3.3 Non-Standard Interface Software
Whenever GOS is interfacing to an external system using interface software other
than Safegate standard, the installation program will be setup to allow installation of
the required software as follows:
(a) Start the program Gosinstall.exe.
(b) Select Install <name of ifc> Software.
(c) Click START.
(d) Follow instructions and accept default settings during the installation.
2.3.4 GOS Access Manager Setup
Whenever GOS HMI uses centralized access handling (a log on to GOSHMI is
required for access to the system) the tool GosAccessManager.exe is used when
creating system users.
Install the software as follows:
(b) Select Install GOS Access Manager Software.
(c) Click START.
2.3.5 SDK Maintenance Software Setup
Safedock maintenance software can be installed in the GOS system. It is
recommended that maintenance software is only installed on a separate GOS
Maintenance computer specifically dedicated for Safedock maintenance.
Install the software as follows:
(b) Select Install SDK Maintenance Software.
(c) Click START.
Page 9 of 16
2.4 SHARED DIRECTORIES

Directories to be shared become shared automatically when the GOS software is
installed. The directories to be shared are defined in GOSINSTALL.INI.
Note: If redundant servers are used, the user running the Goskrnl service (normally
the Administrator) must have full rights to the GosShared share (location: <Gos App.
Dir>\GosShared. For more information, see the Windows operating system for a
description of how to assign rights to a network share.
2.5 DEVICE DRIVER INSTALLATION FOR DEVICEMASTER-RTS
The GOS-Server establishes communication to each DGS via DeviceMasters-RTS
(LAN to Serial Communication device otherwise known generically as the GOS
Concentrator Unit), which is connected to a LAN. Each device is equipped with 1, 4,
8, 16 or 32 serial ports each configurable for RS232, RS485, or RS422
communications. It is possible to have any combination of these devices or individual
port configuration. However, the individual port configuration MUST match that as
required for the serial communication signaling to the A-VDGS.
2.5.1 Hardware Installation
Each device is connected to a local network switch or router via Ethernet patch-cable
on the DeviceMaster-RTS Ethernet-port labeled UP. Alternately, a DeviceMaster-
RTS unit can be connected directly to the GOS-Server or a laptop computer to the
Ethernet-port labeled DOWN for troubleshooting and/or configuration of the device.
Note: The device driver must be installed first.
2.5.2 Software Driver Installation
Details of the DeviceMaster-RTS software installation are found in the document
manual RTS_Guide.pdf, located in the DeviceMaster-RTS folder on the GOS
Software Installation CD-ROM. The document describes how to install the device
drivers and configure the DeviceMaster-RTS devices to assign its ports as standard
Windows COM-ports.
For more information, see the sections NS-Link Installation and Configuration,
Installing the NS-Link Device Driver, and Adding Devices After Initial
Installation.
Adobe Acrobat Reader can be found in the AdobeReader directory on the CD-ROM
or the latest version can be downloaded from www.adobe.com.
2.5.2.1 General Configuration Settings
Go to Windows/Device Manager/Multi-port serial adapters by double-clicking the
device to configure:
(a) COM PORT: 5 for the first serial HUB.
Note: Other HUBs shall start at next available port (COM1 through COM4 should
be excluded from these setups).
(b) When the GOS-Server and the DeviceMaster are on the same network segment,
it is recommended to configure the DeviceMaster-RTS to use MAC-addressing
for communications between it and the GOS-Server.
When the GOS server and the DeviceMaster reside on different network
segments, the unit must be setup to use TCP-IP addressing. The latter also
applies when two or more network cards are used in the server.
(c) KeepAlive Timeout Period: 15.
Page 10 of 16
2.6 COM-PORT TEST

Every COM port can be tested with a Loop Back test. A loop back plug shall be
connected to the target port to be tested at the DeviceMaster-RTS unit, typically
located in a remote telecom room. Testing a COM-port is made using the
Wcom32.exe program provided with the Comtrol utilities.
Test a COM-port as follows:
(a) Place the loop back plug on the selected DeviceMaster-RTS port.
(b) Open the Test Terminal - access via Start/All Programs/ Comtrol/ Utilities/
Test Terminal (Wcom2).
(c) Select the target COM-port (assigned to A-VDGS) from the File/Open menu.
(d) Test a RS232-port via the menu selection Port/ Loopback Test, the result of the
test appears when completed.
(e) Test a RS422-port via the menu selection Port/ Send and Receive Test Data –
the test sends a repetitive character pattern from A-Z as A, AB, ABC, and so on.
If the port is OK, the data stream will be shown on the screen as sent.
(f) Close the com port.
2.7 GOS KERNEL AS A SERVICE
2.7.1 General
The GOS kernel, called GosKrnl.exe, shall be executed as a service in all GOS sub
stations – server(s) and the workstations.
The installation program installs the GOS Kernel service automatically when the
software is installed.
2.7.2 Configuring the GOS Kernel Service
If configuring a GOS server and redundant servers is to be used, the service must be
configured to be started by the local Administrator and not the Local System account,
which is default. The servers log on to each other and this cannot be accomplished if
the service is configured to be started by the Local System account.
Configuration can be done as follows:
(a) From Windows/Control Panel, select the Administrative Tools.
(b) Double-click Services.
(c) Double-click GosKrnl - ignore any error messages.
(d) Select the Log On tab.
(e) Select This account.
(f) Click Browse, select the Administrator and click OK.
(g) Enter the current password and confirm.
(h) Click OK and exit.
Note: The service must also be configured, as above, whenever the password for the
Administrator account is changed, otherwise the service will fail to start at next restart.
2.7.3 Verifying the GOS Service Set-up
Refer to the section where software verification is described.
Page 11 of 16
2.8 CAMERA SOFTWARE

2.8.1 General
Before any camera features can be used on a GOS computer, an Active X
Component must be installed.
2.8.2 Installing Camera Software
• To install the component, start Gosinstall.exe, select the Install AXIS Camera
Control option and press START. Follow instructions and accept default settings.
2.8.3 Configuring Camera in Safedock
Refer to the Safedock manual kit for a description on how to configure the camera.
2.9 USER RIGHTS AND PASSWORD ADMINISTRATION
2.9.1 General
Users and passwords are created in the system and on specific computers.
The installation program is used to create the users, except the administrator, which is
automatically created during installation of Windows.
An example of users, passwords and computer names:
Computer:
User Name: administrator gosuser dgsmaint
Password: manager gosuser dgsmaint
GOS_SERVER1: X X X
GOS_SERVER2: X X X
GOSWS_MONITOR: X X X
GOSWS_MONITORDOCK: X X X
The user - administrator is created automatically on every GOS computer during

Windows installation. Maintenance work on the GOS system concerning reinstallation
of network card, rocket port card, Windows, GOS software is carried out by the
Administrator.
The user - gosuser can run the GOS-application (Monitoring or Docking Control and
Monitoring) from the workstation(s).
The user - dgsmaint can perform central maintenance on each Safedock system
through GOS.
Note: To improve system reliability/performance, do not configure Auto Logon on
GOS-Server computers.
Page 12 of 16
2.9.2 Creating Windows Users

The users for the GOS system are created with the installation program. The
installation program reads the PC user configuration from the file GosInstall.INI. The
specified user is then created, and the necessary rights are set on the configured
directories. During the installation procedure, a series of batch files are run during the
installation process. In case of any error during installation, the batch files stop for the
user to view output messages as they appear on the screen.
Create Windows users

(a) Start Gosinstall.exe from the CD ROM.
(b) Select Setup users.
(c) Press Start.
(d) Select the computer to create users for. The program creates users, set user
rights and display created users once finished.
Note: If redundant servers are used, the user running the Goskrnl service (normally
the Administrator) must have full rights to the ‘GosShared’ share (location: <Gos App.
Dir>\GosShared. Refer to the Windows operating system for a description of how to
assign rights to a network share.
2.9.3 Creating GOSHMI Users

A set of application users, controlling the user access to the GOS system, can be
created using the GosAccessManager tool. Refer to the GOS Access Manager
appendix for a detailed description of how to use this tool.
2.10 CONFIGURING AUTO LOGON
Auto Logon can be configured on Workstations if desired. The installation program
can be used to configure Auto Logon.
Note: To improve system reliability, do not configure Auto Logon on GOS server
computers.
2.11 TIME SYNCHRONIZATION OF COMPUTERS
2.11.1 General
The real time clock on each PC is synchronized through the use of Windows XP built-
in time synchronization system called Windows Time Service.
The GOS computers time is synchronized to the Airport master clock, if one exists.
2.11.2 Configuring the NTP Client
(a) Start Gosinstall.exe from CD ROM.
(b) Select Setup Windows Time Service, and click START.
(c) Click STOP SERVICE (this may take some time).
(d) Select Client.
(e) Enter DNS name or IP address of the server(s) from which to synchronize.
(f) Click APPLY to enter the information into the registry.
(g) Click START SERVICE (this may take some time).
(h) Click EXIT when finished.
The time synchronization can be verified by changing the system time on the
computer, and then restarting. The system time synchronizes to one of the
synchronization resources after a restart.
Note: Other NTP options do not work with Windows XP and 2003 Server OS.
Page 13 of 16
3. BASIC VERIFICATION OF SOFTWARE CONFIGURATION

3.1 GENERAL
This is a general description is of the verification process using an overall installation
check for each individual GOS computer.
3.2 VERIFICATION OF GOSKRNL SOFTWARE
The configuration of the GOS software is verified with several steps, by starting the
application in different ways.
3.2.1 Verifying the GOS.INI file Configuration
If changes have been made to the GOS.INI file or starting the application for the first
time, it is recommended to start the GosKrnl.exe program in a non-service mode. Any
serious error to the configuration will cause a dialog box to appear with an error
message.
Error examples are missing files in the program directory, allocation of non-existing
communication ports or erroneous aircraft configuration. If no errors or dialog boxes
appear, it can be assumed the configuration is working correctly and without error.
3.2.2 Verifying the Gos Kernel Service User Set-up
To verify that the user configured to start the service is able to do so, the service can
be manually started from the service panel. If the service starts without an error
message the configuration is working correctly.
3.2.3 Verifying the Automatic Service Start-up
Since GosKernel is running as a service, it starts automatically whenever the PC is
restarted. To verify this, restart the PC, log on to Windows and start the GOSMMI
application. If GOSMMI starts without immediate shut-down or closing, it indicates
that the GOS-Kernel has started correctly.
The GOSMMI application is started as follows:
• From windows, go to C:\GOS or via shortcut-link on the desktop, if found, select
GosMMI.exe to start the GOS Monitor application program.
The GOS MMI shows a screen layout of the airport where the A-VDGS gates are
located along with their status, if all gate are configured and operating correctly.
3.2.4 Verifying File Synchronization Between Servers
The GOS servers synchronize configuration files such as docking logs and Safedock
configuration files during operation. The Standby server is notified of any file updates
on the active server and automatically copies them.
To verify synchronization is working correctly:
(a) Stop the Standby server and remove the files in folder, <Gos App.
Directory>\GosShared.
(b) Start the Goskrnl service on the Standby server.
(c) Verify files are copied from the active server.
Note: It may take approximately 20 seconds before file synchronisation starts.
Possible causes for failure:
• Incorrect IP-Address assignment between the servers – Check GOS.INI.
• GosKrnl service is being run by a windows system user – set it up to be run by the
Administrator or a user with administration rights.
• GosKrnl service user does not have full access rights to the network share
GosShared – grant the user full access.
Page 14 of 16
4. VERIFICATION OF DATABASE SOFTWARE

4.1 GOS DATABASE CONNECTION TEST
To verify that GOS can access the Database, a flight arriving can be inserted into the
database. Use the FIS system or a FIS simulator to insert a new flight arriving into the
database for a known stand. Use current time for STA and ETA.
Within a minute the stand becomes scheduled with the newly inserted flight. This
verifies that GOS can connect to the database and process flights.
4.2 VERIFICATION OF SAFEDOCK CONFIGURATION SOFTWARE
4.2.1 Connection Test
To verify the Stand Configuration Software (SdConfig.exe) can be connected to a
Safedock A-VDGS through GOS:
(a) Start SdConfig.exe program.
(b) Select the REMOTE mode.
(c) Set the IP-Address of the GOS-Server to connect to.
(d) Set the IP-Address of the Stand/Gate-ID as shown on the GOS-MMI screen.
For more information, how to use the SdConfig.exe program see the Safedock
Manual.
Page 15 of 16
Page 16 of 16
Document: 2A_GOS_IN_SystemConfig Version: 1.3
INSTALLATION: APPENDIX A
GOS SYSTEM CONFIGURATION
CONTENTS
1. SCOPE .......................................................................................................................... 2
2. GOS CONFIGURATION ............................................................................................... 2
2.1 GENERAL ......................................................................................................... 2
2.2 GENERAL APPLICATION SETTINGS ............................................................. 3
2.3 AIRCRAFT IN SYSTEM .................................................................................... 4
2.4 AIRCRAFT AT STAND CONFIGURATION ...................................................... 5
2.5 CHANGING THE IP ADDRESS ON A GOS SERVER ..................................... 6
2.5.1 Required Changes in the Server’s INI file ............................................... 6
2.5.2 Required Changes in the Workstation’s INI file ...................................... 6
2.6 CHANGING THE IP ADDRESS ON A WORKSTATION .................................. 6
2.7 SAFEDOCK AND CAMERA IP ADDRESSES ................................................. 6
3. STAND NAME CONFIGURATION ............................................................................... 7
3.1 GENERAL ......................................................................................................... 7
3.2 SAFEDOCK CONFIGURATION ....................................................................... 7
3.2.1 Com Id Configuration ................................................................................ 7
3.3 GOS INI FILE CONFIGURATION..................................................................... 7
3.3.1 General ........................................................................................................ 7
3.3.2 GOS/Safedock Communication ................................................................ 8
3.3.3 GOS HMI Stand Name................................................................................ 9
3.3.4 Aircraft at Stand Configuration .............................................................. 10
3.3.5 Miscellaneous Sections .......................................................................... 10
4. IATA CODE AND AIRCRAFT CONFIGURATION ..................................................... 11
4.1 GENERAL ....................................................................................................... 11
4.2 GOS INI FILE CONFIGURATION................................................................... 11
4.2.1 Updating IATA/ICAO codes .................................................................... 11
4.2.2 Updating the Aircraft Menu ..................................................................... 12
4.2.3 Aircraft at Stand Configuration .............................................................. 12
5. INTERLOCK CONFIGURATION ................................................................................ 13
5.1 GENERAL ....................................................................................................... 13
5.2 CONFIGURATION EXAMPLES ..................................................................... 14
6. CAMERA CONFIGURATION...................................................................................... 15
6.1 IP ADDRESS CONFIGURATION ................................................................... 15
6.2 PICTURE VIEWING ........................................................................................ 15
6.3 PICTURE LOGGING ...................................................................................... 15
Page 1 of 16
1. SCOPE
This document describes maintenance of the GOS.INI file, which is unique for every
GOS PC. From this file, all GOS related applications receive their parameters at start-
up.
The GOS.INI file contains several sections, not described in this manual. These
sections are for internal usage of the GOS system and are not to be modified by the
user.
This document also describes configuration of the following:
(a) HMI layout for workstations.
(b) Stand Name assignments.
(c) IATA code and aircraft definitions.
2. GOS CONFIGURATION
2.1 GENERAL
The GOS.INI file is built up around several sections. Each section contains one or
more configuration settings for the system. Each setting consists of an ItemName to
identify the item and a set of values for the item, for example
[SECTIONNAME]
ItemName=value1, value2, ..., value n
Note: ItemName must be unique for each line within the section.
The following is also to be considered:

• At the beginning of the GOS.INI file, there is an information header to describe the
file version, changes made and when they were made. After every change, this
header is to be updated.
• TAB characters are not to be used in the INI file.
• SPACE characters are not to be used in SECTIONNAMEs or ItemNames.
• If you place a semicolon in front of a statement, the GOS software ignores the
line, for example ;TIME_INFO =UTC
• For changes to take effect, the GOSKRNL and GOSHMI applications must always
be restarted.
Page 2 of 16
2.2 GENERAL APPLICATION SETTINGS

The section APPLICATION controls several functions of the system.
Item Name Value Description

SYSTEMSTATUS= YES Whether system status (active/standby)
NO shall be reported or not to GOS MMI.
ACTIVE_VISIBLE= YES Only relevant if SYSTEMSTATUS =YES.
NO Whether to display ‘Active Server’ button on
screen or not.
If NO is configured, the status button will
only appear on screen when a status
change occurs, and disappear when a user
confirms the event.
STDBY_VISIBLE= YES Only relevant if SYSTEMSTATUS =YES.
NO Whether to display ‘Standby Server’ button
on screen or not.
If NO is configured, the status button will
only appear on screen when a status
change occurs, and disappear when a user
confirms the event.
ACTIVE_POS= x-pos, Position on screen for ‘Active Server’
y-pos button.
STDBY_POS= x-pos, Position on screen for ‘Standby Server’
y-pos button.
TIME_INFO= UTC Whether to display the time in UTC or LTC
LTC format.
If neither UTC nor LTC is configured, the
time will not be displayed at all.
OPERATOR= YES Whether to allow PARK ON/OFF and SHUT
NO DOWN from GOS
ALLOWSTARTDOCK= YES Whether to allow start of docking or not from
NO GOS (OPERATOR=YES must be used
here)
ALLOWACTIVATE= YES Whether to allow start of scheduled docking
NO or not from GOS (OPERATOR=YES must
be used here)
SEND_RAMP_COMMAND YES Whether to allow Open/Close Ramp to be
NO sent from GOSMMI
SEND_FREE_TEXT YES Whether to allow to send free text to DGS
NO from GOSMMI
SEND_LAST_BAGS YES Whether to allow to send Parked Last Bags
NO from GOSMMI
SEND_DEICING_SYMBOL YES Whether to allow to send Deicing text from
NO GOSHMI.
Page 3 of 16
2.3 AIRCRAFT IN SYSTEM

The aircraft name displayed for each aircraft type is controlled by the BUTTONS
section.
The BUTTONS section lists all aircraft types, and assigns them to a unique GOS
Aircraft ID. The GOS.INI file must be updated on every GOS PC for any changes to
take effect.
Syntax:
GosAircraftName=N, N, GosAircraftID, N, Manufacturer
GosAircraftName:
The name of this aircraft type displayed in GOS HMI.
GosAircraftID:
Aircraft ID for this aircraft type. Each aircraft type defined in the SAFEDOCK
system has a unique ID assigned to it. This ID is used to synchronize the GOS with
the configuration data in the DGS.
Manufacturer:
Aircraft manufacturer text displayed in GosHMI
The ‘N’ parameters are for internal use, and should not be modified.
Example:
[BUTTONS]
A30B=5,1,1,1,Airbus
A310=4,1,2,1,Airbus
A320=2,1,3,0,Airbus
Page 4 of 16
2.4 AIRCRAFT AT STAND CONFIGURATION

Any attempt to activate a docking procedure, using an aircraft type not configured at
the Safedock, will result in an error generated by the Safedock.
To avoid sending commands containing aircraft types not configured at a specific
Stand, the GATECONFIG section can be used to specify all aircraft types configured
at each Stand. Only the aircraft types listed are displayed in the HMI for the selected
Stand.
This can be useful to set up on a GOS Workstation.
Syntax:
RecId=StandName, AircraftName_1, ..., AircraftName_n
RecId:
A unique name (preferably based upon the stand name) to identify the entry.
StandName:
The name of the Stand for which the configuration is being specified. This name
must match the name for one of the Stands specified in the GATES section.
AircraftName:
A list of names of the aircraft types allowed for docking at this Stand. Each aircraft
name must have a matching entry in the BUTTONS section.
Note:
The configuration for a single Stand can be divided into more than one line, simply
by making another line containing the same ‘StandName’ but different ‘RecId’, with
the next part of the aircraft list.
If no entry exists for a Stand, all aircraft types will be allowed in the docking
commands sent to the Safedock at that Stand.
Example 1:
[GATECONFIG]
A01A=A01,B 727,B 767-300,A 300,A 330,B 757,B 777-200,L 1011,L 1011-500
Example 2: (The StandName A02 binds the two lines together into the same Stand)
[GATECONFIG]
A02A=A02,B 727,B 767-300,B 747,B 747SP,A 300,A 330,A 340,B 757,B 777-200
A02B=A02,B 737, B 767-300,M 90,M 80
Page 5 of 16
2.5 CHANGING THE IP ADDRESS ON A GOS SERVER

2.5.1 Required Changes in the Server’s INI file
Changing the IP Address on the servers affects the keep-alive communication and file
replication on the servers.
The following sections must be updated in the servers INI files:
[SYSTEMMONITOR] – Keep-Alive communication
ADDR=192.168.2.35
PORT=5000
[SYSTEMSYNC] – File replication

ADDR=192.168.2.35
PORT=5050
The ‘ADDR’ field in both sections must specify the IP address of the other server.
The ‘PORT’ field defines the TCP port number, used by the server to listen for
connection attempts from other server.
Note: It is important for the port number to be the same on both servers.
2.5.2 Required Changes in the Workstation’s INI file
Restart GOSMMI, stop the connection and enter in the new IP addresses to the
servers.
2.6 CHANGING THE IP ADDRESS ON A WORKSTATION
It is the workstation responsibility to connect to the servers. Therefore changing the IP
address on a workstation has no impact on the configuration of other parts of the
system.
2.7 SAFEDOCK AND CAMERA IP ADDRESSES
Safedock Ethernet/camera options are configured/supplied with default IP addresses
for example:
Ethernet/Tibbo - 192.168.1.121, see 3.3.2 GOS/Safedock Communication on page 8,
Camera/Axis - 192.168.1.90, see 6 Camera configuration on page 15,
for more information, see the Safedock Manual, Installation Appendices.
Page 6 of 16
3. STAND NAME CONFIGURATION

3.1 GENERAL
A change of stand requires changes in different parts of the system. The following is a
description of where changes are required:
• SAFEDOCK Configuration.
• GOS.INI on all computers.
3.2 SAFEDOCK CONFIGURATION
3.2.1 Com Id Configuration
The parameter Com Id in the ‘Setup Parameters’ dialog must be set using
SdConfig.exe.
The following image is an indication of where to find this parameter.
The field Com Id must be unique for each Safedock, and can be set to any value
between 1-93 and 96-223 (94 and 95 are reserved for other purposes).
The Com Id value is also to be set for GOS, as described in the following texts.
Note: The name of the Stand can optionally be displayed in the Safedock pilots
display. The fields ‘Stand No’ and ‘Stand name’ determine what is to be displayed.
What is displayed here is not essential to the system functionality. However it is good
practice to display the actual Stand name to avoid confusion.
3.3 GOS INI FILE CONFIGURATION
3.3.1 General
The following functions in GOS are dependent on the Stand Name:
• Communication between GOS and SAFEDOCK units.
• GOS HMI layout configuration.
• Aircraft at Stands.
• GOS Database.
Page 7 of 16
3.3.2 GOS/Safedock Communication

Communication between GOS and SAFEDOCK units are set up by several
configuration scripts in the GOS.INI file. There is a COMM_LINKS section listing all
stands available and a section STAND_kk for each individual Stand.
Syntax of COMM_LINKS:
StandID = LinkName
StandID:
A unique name identifies the stand. This name can, if required, be the same as that
found in the GATES section, the Stand and the communication link are be tied
together by the ComId of theStand. Each Stand listed has its own section, listing
the communication parameters to use.
LinkName:
The name for the communication link to the stand, available communication links
are SAFEDOCK for serial communication and SD_TCPIP/SD_UDP for network
communication.
Syntax of each StandID section:

The name of each section must match the StandID listed in the COMM_LINKS
section. Each section can contain the following items:
PORT = <TCP Port Number>
The Ethernet converter in the Safedock is configured to listen for
connection attempts from GOS on this TCP port.
ADDR = <IP Address>
IP Address of an Ethernet converter in a Safedock. Configuration of
Ethernet controller is described in the Safedock Manual, Chapter 2,
Appendix C.
LOG = <YES/NO>
Flag to indicate if this link automatically gathers Safedock log files at the
end of each docking procedure.
FirstLastGosID =<FirstComId, LastComId>
Indicates which Safedock this link communicates with.
<FirstComId, LastComId> corresponds to the ComId used in the GATES
section and in the SAFEDOCK setup. For a point-to-point
communication, the FirstComId and LastComId match.
Page 8 of 16
Example:
[COMM_LINKS]
STAND_A01=SD_TCPIP
STAND_A02=SD_TCPIP
.
.
[STAND_A01]
PORT=50101
ADDR=192.168.2.35
FirstLastGosID=1,1
LOG=YES
[STAND_A02]
PORT=50101
ADDR=192.168.2.36
FirstLastGosID=2,2
LOG=YES
Description of example:
The lines STAND_A01=SD_TCPIP and the section [STAND_A01] work together. The
string STAND_A01 points out a specific Stand, and must be equal in both places.
(The string STAND_A01 only binds the two sections together, but it’s essential, for an
easy understanding, that a name similar to the actual Stand name is used).
3.3.3 GOS HMI Stand Name
The symbols and parameters of the GOS HMI are configured under the section
GATES. The following example includes some parameters with the Stand name, used
in the HMI.
Syntax:
StandName=n,n,n,n, n,n,n,n, n,n,n,n, n,n, n,n, ComId, n
Stand Name:
The stand name - this is displayed in the stand symbol in the HMI and must match
the Stand name used in the GOS database.
Com Id:
The unique communication ID identifies this Stand and must be the same as the
ComId used in the Safedock.
The ‘n’ parameters are for internal use, and should not be modified (specifies the
location of stand symbol, centre line and aircraft types on the screen).
Example:
[GATES]
A57=0,0,0,0, 0,0,0,0, 70,15,50,50, 0,0, 0,0, 157,0
A55=0,0,0,0, 0,0,0,0, 120,15,50,50, 0,0, 0,0, 155,0
A53=0,0,0,0, 0,0,0,0, 170,15,50,50, 0,0, 0,0, 153,0
Page 9 of 16
3.3.4 Aircraft at Stand Configuration

To avoid sending commands containing aircraft types not configured in the A-VDGS,
the GATECONFIG section can be used to specify all aircraft types configured at each
Stand.
If this feature is used and an entry in the GATES section, or in the BUTTONS section,
is updated, changes must also be made in the GATECONFIG section.
Configuration of this section is as described in section 2.
3.3.5 Miscellaneous Sections
A series of configuration sections are used for miscellaneous purposes.
Some examples are as follows:
3.3.5.1 MMILINK
The MMILINK section defines the Stands, for which the GOS HMI monitors status.
Syntax:
Defines the range of Stands, by ComId, to be monitored at this HMI.
Example:
[MMILINK]
FirstLastGosID=1,157
3.3.5.2 SETUPCAL
The SETUPCAL configuration section defines the Stands, for which a remote between
SAFEDOCK and SDCONFIG is allowed.
Syntax:
Defines the range of Stands (by ComId) to be controlled.
PORT=PortNo
Defines the TCP port number (used by SETUPCAL.DLL) to listen for connection
attempts from SDCONFIG.
Example:
[SETUPCAL]
FirstLastGosId=1,157
PORT=4500
3.3.5.3 Time Synchronization
The following sections define the Stands, which have time synchronization by GOS.
Syntax:
Defines the range of Stands (by ComId) to be time synchronized.
Example:
[SETTIME]
FirstLastGosID=1,157
Page 10 of 16
4. IATA CODE AND AIRCRAFT CONFIGURATION

4.1 GENERAL
An update of IATA codes or aircraft types requires changes in different parts of the
system. The following indicates where changes are required.
• GOS.INI on all GOS computers.
4.2 GOS INI FILE CONFIGURATION
4.2.1 Updating IATA/ICAO codes
The IATA_NAME section is used when GOS is interfacing to FIDS. When FIDS sends
IATA/ICAO codes to GOS, the IATA codes have to be converted to valid SAFEDOCK
IDs.
By using the IATA_NAME section it is possible to configure the GOS system so that
several IATA/ICAO subtypes are converted to one generic aircraft type, when sent to
Safedock. The following is an example:
[IATA_NAME]
A 300=AB2,AB3,AB4,AB6,ABF
A 310=310,312,313,31F
A 319=319
Etc.
Every entry has the format: DGS_NAME =FIDS_1, FIDS_2,k#

Where
(a) DGS_NAME
The name of the DGS Aircraft. This name must match the name for one of the
names specified in the BUTTONS section.
(b) FIDS_1
The IATA code of the aircraft as reported by the FIDS link. Several codes stated
on the same line are all converted to the same aircraft type when sent to
Safedock.
Every conversion that exists in this section must also exist in the BUTTONS section.
If this section is not present, the conversion will be made directly from the BUTTONS
section.
Page 11 of 16
4.2.2 Updating the Aircraft Menu

The aircraft name displayed for each aircraft type is controlled by the BUTTONS
section. If an aircraft name is updated in the BUTTONS section (left column), it must
also be updated in the IATA_NAME section.
The BUTTONS section lists all aircraft types, and assigns them to a unique GOS
Aircraft ID. The GOS.INI file must be updated on every GOS PC for any changes to
take effect.
Syntax:
GosAircraftName=N, N, GosAircraftID, N, Manufacturer
GosAircraftName:
The name of this aircraft type as displayed in GOS HMI.
GosAircraftID:
Aircraft ID for this aircraft type. Each aircraft type defined in the SAFEDOCK
system has a unique ID assigned to it. This ID is used to synchronize the GOS with
the configuration data in the A-VDGS.
Manufacturer:
Aircraft manufacturer text displayed in GosHMI
The ‘N’ parameters are for internal use, and should not be modified.
Example:
[BUTTONS]
A-300=5,1,1,1,Airbus
A-310=4,1,2,1,Airbus
A-320=2,1,3,0,Airbus
4.2.3 Aircraft at Stand Configuration
To avoid sending commands containing aircraft types not configured at the A-VDGS,
the GATECONFIG section can be used to specify all aircraft types configured at each
Stand.
If this feature is used and an entry in the BUTTONS section is updated, changes must
be also be made in the GATECONFIG section.
For more information, see section 2 of this manual.
Page 12 of 16
5. INTERLOCK CONFIGURATION
5.1 GENERAL
The module INTERLOCK.DLL evaluates rules for what aircraft are allowed to dock at
a stand, based on the status of adjacent stands.
Every aircraft type has a class designation, which ranges from A-Z, where earlier
letters always indicate a smaller (with regard to wingspan) aircraft. For example, class
A aircraft are always smaller than class C aircraft.
The interlock information contains a series of blocking rules for each stand, where
each rule identifies an aircraft class, the blocking stand and the smallest aircraft class
for the stand that blocks a docking. The interlock rules are placed in the
[INTERLOCK] section of GOS.INI, and the syntax for the rules is as follows:
StandItem=,SelectedStand, SelectedAc(BlockingStand:BlockingAc), {Comments},
[AC1,AC2,….;AcClass;Stand1,Stand2,….], [AC3;AcClass;Stand3]
Where:
StandItem Unique index in INI file
SelectedStand The name of the stand for which a rule applies
to (to match any of the names as in GOSMMI)
SelectedAc The smallest aircraft class at the selected
stand this rule applies to. The rule is valid for
aircraft of this and all higher classes, any rule
for class A applies to ALL aircraft types, a rule
for class D apples to aircrafts of class D-Z.
BlockingStand The name of a stand which can block
operations at this stand.
BlockingAc The smallest aircraft class at the blocking
stand that can block an operation of the
selected aircraft. If there is an aircraft of this
class or higher at the blocking stand, the rule
is fulfilled and the requested docking is
blocked. A blocking aircraft of class A
therefore means any aircraft at the blocking
stand blocks the requested operation.
{} Free Text field. Any text within brackets is
treated as a comment, and can be placed
anywhere in the interlock rule.
[AC1,AC2,…;Class;stand1:stand2,….] Redefinition of class designator.
Example 1: If A310 is parked at stand D42 and stand D44

D42=D42, [A310;B;D44] requests to start docking, the A310 is to be
redefined as a class B type.
Example 2:
D44=D44, [A310, B737;D;D42,D46] If A310 or B737 is parked at stand D44 and
stand D42 or D46 requests to start docking,
the A310/B737 is to be redefined as a class D
type.
Note: Exception rules are only to be used

when necessary to redefine the class types.
Note: A rule for a stand can be divided into two lines in the GOS.INI file.
Page 13 of 16
Example:
D42_A=D42, A(D44:C), [AC1;B;D44]
D42_B=D42, B(D46:F), [AC2;C;D44]
The class configuration is done in the [BUTTONS] section.
Example:
[BUTTONS]
B737=3,3,7,0,Boeing,C
B 747=2,3,8,1,Boeing,E
5.2 CONFIGURATION EXAMPLES
B737 = class B, B747 = class D
Stand1=S1,A(Stand2:A) Any aircraft at stand 2 blocks operations at
stand 1.
Stand2 =S2, A(Stand1:A), 1. Docking at stand 2 is blocked if there is an
C(Stand3:E) aircraft at stand 1.
2. Docking a C type or bigger aircraft at stand
2 is blocked if there is an E-type or bigger
aircraft at stand 3.
Stand3=S3, E(Stand2:C) Docking an E type or bigger aircraft at stand 3
is blocked if there is a C-type or bigger aircraft
at stand 2. All smaller aircrafts are always
allowed to dock.
Redefinition example:
Stand2=S2, C(Stand3:E) In general, docking a C type or bigger at stand
Stand3=S3, 2 is blocked if there is an E-type or bigger
E(Stand2:C),[B747;D;Stand2] parked at stand 3.
However, docking a C-type or bigger at stand
2 when a B747 is Parked at stand 3 is
allowed, as the B747 on stand 3 was
redefined as a class D type when stand 2 is
docking.
Note: If there are no blocking rules configured, docking is always allowed.
Page 14 of 16
6. CAMERA CONFIGURATION
6.1 IP ADDRESS CONFIGURATION
In order to communicate with the camera at each stand, IP Address for each camera
must be known by GOS. This is configured in the [CAMERA_IP] section according to
the format: Stand=Camera IP Address.
[CAMERA_IP]
24=192.168.2.20
32=192.168.2.22
….
6.2 PICTURE VIEWING
Setup the following in the [APPLICATION] section to affect the behaviour of GOSMMI.
CAMERA=YES Enables real time picture viewing in GOSMMI.
PICTURELOG=YES Allows to view stored camera images from
disk from GOSMMI.
POPUP_ON_ERROR=YES Camera window pop-up appears in GOSMMI
upon error from a Safedock.
MAX_CAMERA_FORMS=4 Maximum number of camera forms allowed to
be open at the same time in GOSMMI.
6.3 PICTURE LOGGING

In the [FEATURE_LINKS] section, GOS can be configured to upload camera images
automatically during a docking.
Add the following line to the [FEATURE_LINKS] section:
PICTURE_LOG= PICTURE_LOG
Create a section [PICTURE_LOG] and add the following:
SERVICE=CAMERALOG Loads Cameralog.exe upon start of GOS.
FirstLastGosID=1,161 Stands where camera pictures are saved.
PICT_AFTER_STOP=5 Number of pictures to record after docking is
finished.
LOGDAYS=7 Number of days to store camera images on
disk.
Note: Make sure necessary disk space is
available for the required configuration.
ACTIVE=NO States to start/not start camera recording for.
DOCKING=YES
DOWNGRADE=YES
BLOCKED=NO
ERROR=YES
Page 15 of 16
Page 16 of 16
Document: 2B_GOS_IN_Interface Version: 1.3
INSTALLATION: APPENDIX B
INTERFACE – (OPTIONS)
CONTENTS
1. CDI INTERFACE (OPTION) .......................................................................................... 2
1.1 INSTALL CDI AND SUPPORT TOOLS ............................................................ 2
1.1.1 Previous Installation .................................................................................. 2
1.1.2 GOS Installation Utility .............................................................................. 2
1.1.3 Standard GOS System............................................................................... 3
1.1.4 CDI Server ................................................................................................... 3
1.1.5 MySQL Database........................................................................................ 4
1.1.6 GOS Flight database.................................................................................. 7
1.2 MYSQL DRIVER ............................................................................................... 7
1.2.7 OPC access to the computer .................................................................... 8
2. GOS/AGL BRIDGE INTERFACE (OPTION) ................................................................ 9
2.1 INTRODUCTION............................................................................................... 9
2.2 APPLICATION SETUP ..................................................................................... 9
2.2.1 .NET Framework Installation .................................................................... 9
2.2.2 Application and Service Installation ........................................................ 9
2.2.3 Application and Service Configuration ................................................... 9
2.3 APPLICATION STARTUP ................................................................................ 9
2.4 CONFIGURATION OPTIONS......................................................................... 10
Page 1 of 12
1. CDI INTERFACE (OPTION)

CDI Interface software is installed with a set up application, GOS Installation Utility,
on a computer with Windows XP or Win 2K.
Note: If the CDI server exists/has previously been installed on the computer, it must
be removed before a new installation.
To run the CDI Server, a number of system parts are required.
When all system parts are installed/configured, the computer must be enabled to
accept OPC connections from other computers.
1.1 INSTALL CDI AND SUPPORT TOOLS
1.1.1 Previous Installation

Check if a previous CDI installation exists in the program list on the computer:
• From Windows, go to the Start/Control Panel/Add or Remove programs, select to remove the
previous CDI installation (if it appears in the list) and restart the computer, if required.
1.1.2 GOS Installation Utility
Install CDI Interface software using the set up
application, on a computer with Windows XP
or Win 2K.
(a) Insert the installation CD into your
computer disk drive.
(b) Right-click on the CD icon and select to
open the disk.
(c) Double-click Gosinstall.exe to start the
GOS Installation Utility.
(d) Select an option and click Start.
(e) See the instructions in the following steps
for the required system parts:
• Standard GOS system.
• CDI Server.
• MySql Database server.
• GOS flight database.
• MySql Driver.
Page 2 of 12
1.1.3 Standard GOS System
• If a standard GOS System does not exist, see the GOS Manual Installation chapter.
1.1.4 CDI Server
Install the CDI Server:

(a) From the GOS Installation Utility, select Install
CDI Server.
(b) Click Start and follow the instructions that
appear.
(c) Use the default destination folder (usually
acceptable) or browse to another folder.
(d) Use the default destination folder (usually

(e) Select Everyone.
(f) Click Next.
(g) Click Next to confirm and start the installation.
Page 3 of 12
1.1.5 MySQL Database
Install the MySQL Database:

(a) Select Install MySQL Database from the GOS
Installation Utility.
(b) Click Next.
(c) Select Typical installation.
(d) Click Install.
Page 4 of 12
(e) Select Skip Sign-Up.
(f) Select Configure the MySQL Server now.

(g) Click Finish.
(h) Click Next.
(i) Select Standard Configuration.

(j) Click Next.
Page 5 of 12
(k) Select Install as Windows Service, with

Service Name: MySQL (default) and select
Launch the MySQL Server automatically.
(l) Select Include Bin Directory….
(m) Click Next.
(n) Click Modify Security Settings to set up a root

user.
(o) Enter the word, manager - as the password and
once again to confirm it.
(p) Click Next.
(q) Click Execute to perform the configuration.
Page 6 of 12
1.1.6 GOS Flight database
Create the GOS Flight database:

(a) Browse to the directory Common\Sqlscript on
the installation disk.
(b) Double-click on the MySqlCreateGosDb.bat file
to run it.
1.2 MYSQL DRIVER
Install MySQL Driver:

(a) Select Core Labs MySQL Driver from
the GOS Installation Utility.
(b) Click Next.
(c) Select I accept the agreement.

(d) Click Next.
Page 7 of 12
(e) Use the default destination folder (usually

(f) Click Next.
(g) Select Full installation.

(h) Click Next.
(i) Click Install.
1.2.7 OPC access to the computer
The computer must be enabled to accept OPC connections from other computers.
This procedure is available at:
http://www.opcactivex.com/Support/DCOM_Config/dcom_config.html
Page 8 of 12
2. GOS/AGL BRIDGE INTERFACE (OPTION)

2.1 INTRODUCTION
This information describes how to install and configure GOSAGLBridge.
2.2 APPLICATION SETUP
The following steps must be taken prior to usage.
2.2.1 .NET Framework Installation
.NET Framework v2.0 is required for the bridge to run. Use the supplied file
dotnetfx.exe to install it. If necessary, first install Windows Installer 3.0 in order to be
able to install .NET Framework v2.0.
2.2.2 Application and Service Installation
Run setup.exe. It will install the application at the desired location. Also, a windows
service named GOSAGLBridgeService is installed, but not started. If the application is
already installed, it has to be uninstalled prior to installation of the new application.
This should be presented as an alternative to the user upon installation. If not,
uninstall it manually using “Add or Remove Programs” from the control panel. The
application is listed as “GOSAGLBridge”.
2.2.3 Application and Service Configuration
The application can be run either as a stand-alone application or as a windows
service. There are two configuration files, one for each alternative.
• The stand-alone application is configured with
GOSAGLBridge.ConsoleWindow.exe.config
• The Windows service is configured with GOSAGLBridge.Service.exe.config
In the configuration file, there are several important settings to be changed. A full list
of settings and their description is listed in Section 4, which also specifies the
minimum settings needed to make the bridge work.
2.3 APPLICATION STARTUP
Once configured, the service can be started by double clicking on
GOSAGLBridge.ConsoleWindow.exe. It opens a console window that lets the user
control the service. Type start and press enter to start the service. The console
window can then be closed by typing exit. The service will continue to run in the
background and if the console program is started again, it will reconnect to the service
and display the missed log messages. Enter “?” to get a list of commands available.
The service can be started automatically on windows startup. The service is listed as
GOSAGLBridgeService in windows services. Choose startup type “automatic”.
The application can also be run without a service. Run the

GOSAGLBridge.ConsoleWindow.exe with command line argument noservice.. In this
mode, the log configuration cannot be changed and the application will terminate as
soon as the user presses a key. This startup method may be useful for testing and for
locating errors.
Page 9 of 12
2.4 CONFIGURATION OPTIONS

This section describes the configuration files
GOSAGLBridge.ConsoleWindow.exe.config and GOSAGLBridge.Service.exe.config.
Before starting the bridge, these settings must be changed: GOSAdress,

AGLAddress, AGLPort, GosIniFileLocation.
Name Default Value Description

LogFile C:\Program Where the log file is stored. Make sure
Files\Safegate\Safe it is a valid directory, or that file logging
gate is turned off, otherwise the service will
LampMonitor\Logs\ terminate without any error message.
LampMonitor.log
GOSAddress 127.0.0.1 IP-address to GOS
GOSPort 10100 Port to GOS

LogDebug True Display and log debug output.
LogWarning True Display and log warning output.
LogFilePerDay True Start a new log file each day.
LogToFile False Store log messages in a file. Make sure
LogFile has a valid value.
LogToEventLog False Store log messages in the event log.
LogError True Display and log error output.
LogTrace False Display and log trace output.
LogInfo True Display and log information output.
LogMaxFileSize 2000000 The maximum size of a log file, before
another file is created.
LogFileAgeLimit 32 How many days log files are kept.
GOSReconnectionTime 5 The number of seconds to wait before
attempt to reconnect to GOS upon a
failed connection.
GOSHeartbeatTime 35 The number of seconds to wait for a
heartbeat from GOS before
reconnecting.
AGLReconnectionTime 5 The number of seconds to wait before
attempt to reconnect to AGL upon a
failed connection.
DgsActive_AcceptedErrors ERR_ID_FAIL The errors which will trigger a
ERR_GATE_BLOC DGS:Active message, and not
KED DGS:NotActive
ERR_VIEWBLOCK
ED
ERR_BRIDGE_IN
ERR_BRIDGE_UP
ERR_APRON_BLO
CKED
AGLAddress 127.0.0.1 A collection of addresses to AGL
172.20.11.16 servers. The application will try connect
to both adresses.
Page 10 of 12
Name Default Value Description

AGLMaxResponseTime 5 The number of seconds to wait for a
StandAreaStatus response from AGL
when sending StandAreaCommands.
AGLMaxManualResponseTime 60 The number of seconds to wait for
GL_ON, when received GL_PENDING
ParkonTimeout 30 The number of seconds to keep lights lit
after a ParkOn
DGSNotActiveTimeout 120 The number of seconds to keep lights lit
after a DGS:NotActive
DepartureTimeout 120 The number of seconds to wait before
turning on GL lights after SWL lights
have been lit. If specified to 0, wait
forever. If using manual lead-in-lights,
this parameter is not used.
ParkoffTimeout 60 The number of seconds to keep lights lit
after a ParkOff
ManualOperationTimeout 30 The number of seconds to keep lights lit
after a Deactivate LeadIn Lights
AGLSendTries 3 The number of send tries toAGL. The
stand will move to state AGLError when
AGL does not respond after these tries.
AGLPort 1509 The ports used to connect to the
1509 different AGL servers. Set different port
values on the bridge on the other
computer. Each AGL server has two
ports open.
GosIniFileLocation C:\GOS The path to gos.ini
Dubai\gos.ini
StopArrivalTimeout 30 The number of seconds to keep lights lit
after operator has deactivated arrival
(only when in state Arrival)
ManualOperationCancelledTimeout 30 The number of seconds to keep lights lit
after DGS:NotActive when in state
Manual Operation
Page 11 of 12
Page 12 of 12
Document: 3_ GOS _OPERATION Version: 1.3
CHAPTER 3
OPERATION
CONTENTS
1. SCOPE .......................................................................................................................... 3
2. DOCKING MONITORING ............................................................................................. 4
2.1 GENERAL ......................................................................................................... 4
2.1.1 GOS Standard System............................................................................... 4
2.1.2 Co-operation with External Systems ....................................................... 4
2.2 GOS STARTUP AND VDU SCREEN LAYOUT ............................................... 5
2.3 HELP MENU SYSTEM ..................................................................................... 6
2.4 EVENT AND STATUS DISPLAY ...................................................................... 7
2.4.1 Stand Status Display ................................................................................. 7
2.4.2 Stand Status Box ..................................................................................... 11
2.4.3 Safedock A-VDGS Error Codes .............................................................. 12
2.4.4 System Event Windows........................................................................... 13
3. GOS AND SAFEDOCK EVENT LOGS....................................................................... 14
3.1 GOS EVENT LOG........................................................................................... 14
3.1.1 View a GOS Event Log File ..................................................................... 14
3.2 DGS DOCKING LOG FILES ........................................................................... 17
3.2.1 Viewing and Print-Out ............................................................................. 17
3.3 AUTOMATIC UPLOAD OF SAFEDOCK CONFIGURATION FILES.............. 17
3.4 CLOSING DGS FOR MAINTENANCE ........................................................... 17
3.5 DISPLAY OF A-VDGS TYPE.......................................................................... 18
3.6 SAFEDOCK MAINTENANCE USING SDCONFIG ........................................ 18
4. DOCKING CONTROL ................................................................................................. 19
4.1 DOCKING COMMANDS ................................................................................. 19
4.1.1 Log On ...................................................................................................... 19
4.1.2 Command menus ..................................................................................... 20
4.1.3 First time start up, administration and creating users ........................ 21
4.1.4 Starting a Docking Procedure ................................................................ 22
4.1.5 Activating a Scheduled Docking ............................................................ 23
4.1.6 Inserting a Scheduled Flight ................................................................... 24
4.1.7 Displayed statuses during docking ....................................................... 25
4.1.8 Shut down................................................................................................. 26
4.1.9 Park On ..................................................................................................... 26
4.1.10 Park Off ..................................................................................................... 26
4.2 CAMERA ......................................................................................................... 27
4.2.1 Viewing Live Images ................................................................................ 27
4.2.2 Viewing Recorded Images ...................................................................... 27
4.3 ADJACENT STAND INTERLOCK .................................................................. 28
4.3.1 Important Things to Know ...................................................................... 28
5. FIS INTERFACE .......................................................................................................... 29
5.1 BASIC FUNCTIONALITY ................................................................................ 29
Page 1 of 34
5.2 ARRIVAL PROCEDURE ................................................................................. 29

5.3 DEPARTURE PROCEDURE .......................................................................... 29
5.4 RIDS INFORMATION ..................................................................................... 30
5.5 SPECIAL OPERATIONAL PROCEDURES .................................................... 30
5.5.1 Unprocessed Arriving Flight .................................................................. 30
5.5.2 Unsuccessful Docking ............................................................................ 30
6. CMS INTERFACE (OPTION) ...................................................................................... 31
6.1 CMS SYMBOLS FOR SLW AND LIL (OPTION) ............................................ 31
6.2 CMS - SWL STATES (OPTION) ..................................................................... 32
6.3 GOS CMS FUNCTIONALITY ......................................................................... 33
Page 2 of 34
1. SCOPE
The Gate Operating System/GOS has two separate Man-Machine-Interfaces.
1. The Docking Monitoring program, named GOSMMI.
2. The Scheduled Flight Management Tool, named SFM.
Sections 2 and 3 of this document are descriptions of the Docking Monitoring &
Control MMI.
Section 4 describes the man-machine interfaces for updating Scheduled Flights and
Stand parameters.
(a) The table A_FLIGHT contains information about scheduled active flights. The data
is used for starting the docking and departing procedures at the Stands and is
also used for displaying relevant flight information during these procedures.
(b) The table STAND contains information mainly about process start times, related
to scheduled flight arrivals and departures at a Stand. Each stand A-VDGS status
is also a part of this database table.
A special MMI is used for SAFEDOCK maintenance, and is described in the Safedock
Manual Chapter 4 MAINTENANCE.
Page 3 of 34
2. DOCKING MONITORING
2.1 GENERAL
2.1.1 GOS Standard System
The Gate Operating System (GOS) comprises of from one to several PCs,
communicating with the Safedock A-VDGS, at each stand. All Safedock units at the
airport can be monitored from each GOS system node, such as a GOS workstation or
the GOS server.
This section describes Docking Monitoring & Control, which is one of the User
Interfaces (UI) or Man Machine Interfaces (MMI) at a GOS workstation.
For maintenance purposes the system also includes an Event Log feature, giving a
history of all events at the Stands and within the GOS system itself.
2.1.2 Co-operation with External Systems
GOS includes an internal database for automatic control of scheduled flights. The
database can be created or updated from MMI software, installed on a GOS
workstation in for example an Apron Control Centre (ACC).
An external FIS/GMS system is connected to GOS for automatic insertion and
updates of scheduled flights.
The FIS connection can also be used for displaying flight information at the stand
assigned for an arriving or departing flight.
Page 4 of 34
2.2 GOS STARTUP AND VDU SCREEN LAYOUT

The operator at a GOS node uses a PC workstation with Microsoft Windows XP
based software for monitoring the docking operations at each Stand.
The application GOSMMI is used to view the GOS Monitor airport layout.
Start GOSMMI to view the GOS Monitor airport layout

(a) After logging on as a GOS user, go to
Windows Start Menu/Program and
select the GOSMMI program.
The first time the program starts, enter
IP addresses to the GOS servers in the
address fields.
(b) At the next program start-up, the

program automatically tries to connect to
specified sources after a few seconds.
Note: The connection attempt can be

stopped by clicking the Halt Connection
button, if required.
The VDU screen displays a picture of the airport layout with symbols for all the
Stands, which are connected to the central system GOS.
The following is an example:
AIRPORT STAND LAYOUT EXAMPLE
Page 5 of 34
2.3 HELP MENU SYSTEM

The GOSHMI has a built-in help system that can be displayed by pressing the F1
key.
GOS HELP EXAMPLE
GATE SYMBOL LEGEND EXAMPLE
Page 6 of 34
2.4 EVENT AND STATUS DISPLAY

2.4.1 Stand Status Display
During a docking procedure, the status of a stand is changed several times. All of
these changes are displayed on the screen by stand number tags changing colour,
and by aircraft symbols appearing on stand centrelines.
Note: Image examples may differ depending on site configuration.
Page 7 of 34
Stand Status Display Image examples

Ready
Green Stand tag, black number, black centreline: 128
Stand is Ready. The Stand is empty but not
confirmed to be used yet. This status will appear
automatically after a pushback procedure.
Ready Open
Green Stand tag, white number, black centreline: 128
Stand is Ready Open. The Stand is empty and
confirmed to be used by a local or GOS operator.
Active docking
Yellow Stand tag, black number, yellow centreline: 128
Stand is active. The docking system is waiting for
the aircraft to dock.
< OR >
Interlock Request
Yellow Stand tag, black number, yellow centreline:
Docking Request status. Operator has selected an
aircraft, which is checked against the GOS server.
Docking is started immediately if allowed.
< OR >
Down grade
Yellow Stand tag, black number, yellow centreline:
Stand is in down grade mode. The docking has
been started, but the visibility is low due to heavy
fog, rain or snow.
Parked
Blue Stand tag, white number, black centreline,: 128
Parked status. The aircraft has reached its stop
position.
Communication Error
Pink Stand tag, black number, black centreline: 128
Communication error. The communication with
the docking system is interrupted.
VDGS Error
Pink Stand tag, white number, black centreline: 128
The Visual Docking Guidance System (VDGS) has
an error status.
VDGS not connected
Pink Stand tag, black number, yellow centreline: 128
The VDGS is not connected.
Page 8 of 34

Maintenance mode
Brown Stand tag, white number, black centreline:
128
Maintenance status. Stand is occupied for
maintenance activities. Remote activation of
docking procedures is not allowed.
< OR >
Closed for Maintenance
Brown Stand tag, white number, black centreline:
Closed for Maintenance. The stand is closed for
remote access due to planned maintenance
activities. The VDGS remain available for local
operations.
Emergency Stop Activated
Red Stand tag, white number, black centreline: 128
The VDGS Emergency Stop is activated to not
allow start of docking.
< OR >
Stand Interlocked
Red Stand tag, white number, black centreline:
An interlock request has been evaluated to not
allow start of docking.
Blocked
Grey Stand tag, red number, black centreline: 128
Blocked by Interlock Adjacency Rule.
Interlock Status Unknown

Grey stand tag, dark red number, black centreline: 128
The interlock request could not be evaluated by
GOS.
< OR >
Interlock Timeout
Grey stand tag, dark red number, black centreline:
GOS has not responded to the Interlock request
within a certain time (time is configured in DGS)
Scheduled Arrival (from flight source feed)

Blue stand tag, yellow number, yellow centreline: 128
Stand is Scheduled for docking but not confirmed
by operator at a Stand. Docking is started
immediately when confirmed by local operator.
Scheduled Departure (from flight source feed)

Blue stand tag, black number, black centreline: 128
Scheduled departure status (Only with standard
interface to FIS). An aircraft is parked at the Stand.
The aircraft is planned to depart shortly.
Page 9 of 34

Parked, Last bag
Blue stand tag, white number, black centreline: 128
position.
Aircraft Departing
Blue stand tag, red number, black centreline: 128
Departing. The aircraft is no longer present at its
parked position, but may still be within the gate
area.
Parked – Deicing mandatory
White stand tag, blue number, black centreline: 128
position. Deicing is mandatory.
Page 10 of 34
2.4.2 Stand Status Box

The status of a Safedock unit at a stand can be viewed by selecting the stand number
tag.
When the tag is selected, a small box, with status information, appears next to the tag.
Stand Status Box Image example

In the image example, a number of
Stands have been selected, and
information in the status boxes can be
viewed. When the Stand tag is
selected again, the status box
disappears.
The system indicates the following aircraft/flight information in the status box under
the aircraft type field.
(a) If started by the local stand operator, the text ”- LOCAL” is displayed in the status
box under the aircraft type (as flight number is not available).
(b) If started by the GOS operator, the text ”- GOS” is displayed in the status box
under the aircraft type, if flight number is not available.
(c) If flight number is available, this is displayed instead of “- GOS”.
(d) If both flight and registration number are available, the flight number is displayed
as default. Flight and Registration number can be alternatively displayed by
clicking in the status box under the aircraft type field.
Page 11 of 34
2.4.3 Safedock A-VDGS Error Codes

In case of an error with the Safedock system, an associate code is displayed with the
error message in the status box and in the log file.
The code represents the following error types for the Safedock system:
Safedock Error Codes Description

‘00’ - No error This code is sent when the system has not an error
status
‘01’ - Laser error Laser does not send data, time-out during scan
‘02’ - Mirror error Stepper motor with mirror are not moving, or
home position is not found
‘03‘ – Auto-calibration error Calibration check unsuccessful
‘04’ – Installation data error Calibration data are not present, calibration
might not be done
‘05’ – Profile error Profiles of a specific aircraft type could not
be loaded into memory
‘06’ - Flash error Not in use, not required or obsolete function.
‘07’ - Loop error Not in use, not required or obsolete function.
‘08’ – Configuration error Aircraft is not configured for the Stand;
Invalid stop position or reference (others than nose,
door or nose wheel)
‘09’ - Door blocked Aircraft is not allowed to dock to the selected door
‘10’ – Display error A severe error with the LED matrix display is
Detected
‘11’ - CU Restarted Controller/CPU has restarted previously
‘12’ - ID failed Identification of the selected aircraft has failed.
‘13’ – Docking too fast Aircraft is approaching too fast
‘14’ – Bridge not in (option) Aircraft Loading Bridge is not drawn in, if configured
‘15’ –Bridge not up (option) Aircraft Loading Bridge is not in upper position
‘16’ – Parameter error Stand parameters could not be loaded
‘17’ – Anomalous Abort Aircraft is lost just before stop position
‘18’ – Operator Panel error No communication with operator panel
‘19’ – Emergency Stop error Emergency stop circuitry is not working
‘20’ – Laser Amp error Not in use, not required or obsolete function.
‘21’ – Stand Blocked The DGS view of the Stand area is blocked.
‘22’ – Undefined Centreline Undefined/Invalid centreline
‘23’ – View Blocked Laser view through the window blocked
‘24’ – Apron Blocked Object detected during apron check
‘25’ – Walktest Required Walktest is required due to changes in configuration
‘26’ – Temp Out of Range The temperature in the system is to high or to low.
‘27’ – Laser Safety Error Safety circuitry of laser has not a correct time
constant or does not control the laser.
‘99’ – Communication Error Communication between DGS and GOS is broken
Page 12 of 34
2.4.4 System Event Windows

All events and errors of the docking systems, the central Gate Operating System, and
the communication to external systems can be configured to be displayed in separate
event windows.
SYSTEM EVENT WINDOW EXAMPLE
Each type of event can be configured to generate an audible alarm. By default no

alarm sound is generated. Configuration is done in the GOS.INI file.
The alarm button indicates if the audible alarm feature is enable or disabled on the
local PC. By changing the state of the alarm button to disabled/enabled, the audible
alarm will be turned off/on.
Any message generating an audible alarm also causes the window title screen to start
flashing indicating a new message has arrived.
Each window is resizable and movable on the screen. The window can be collapsed/
expanded by clicking the button in the upper right corner.
The window can also be docked to the edge of the screen. When docked, the window
expands whenever the mouse pointer hovers over the control and disappears again
as the pointer leaves the window area.
Acknowledge message(s) Image example

A message/all messages can be
manually removed from the window
by right clicking on the message
and selecting
Acknowledge/Acknowledge All,
as in the example.
Windows and functionality

Server Status window Current status for Active and standby server
is displayed.
Error codes A possible error message for a Safedock is
displayed. A new error overwrites an existing
error. The error remains until confirmed by an
operator.
A-VDGS statuses Current status of each Safedock is displayed.
A new status overwrites an existing status.
Page 13 of 34
Windows and functionality

Interface statuses (Options) Interface connection statuses (FIS, TMS and
more) are displayed. A new status overwrites
an existing status.
3. GOS AND SAFEDOCK EVENT LOGS

3.1 GOS EVENT LOG
All GOS events and errors, subsystems (docking systems) and communication to
external systems, if any, are monitored and logged for maintenance purposes.
Information includes the following:
(a) Safedock A-VDGS system errors.
(b) Safedock A-VDGS events associated with the docking procedure.
(c) Commands from GOS.
(d) Docking Sequence record - distance and lateral position of aircraft (Option).
(e) Billing Events, for example Block-On/Off time at stands.
The name of the log file is based on the current date, with the format YYMMDD.log.
The GOS event log files are stored in the ‘log’ directory.
The file is stored automatically for a limited number of days (specified in GOS.INI).
When the limit is reached, the file is automatically erased.
3.1.1 View a GOS Event Log File
The Event Log Files are mainly for maintenance monitoring and diagnostic purposes.
View a GOS Event Log File Image examples
(a) Select from the entire system or a specific stand for one of the log file views as follows:
• GOS Monitor menu - for the entire GOS
system.
Right-click outside any stand selector and
select a view with events from the entire
GOS system.
• Stand... menu – for a specific stand.

Right-click on a stand symbol selector and
select a view with events (restricted) for the
specific stand only.
Page 14 of 34

(b) Select from one of the available View… commands:
• View Log File - a view of the entire content of the log file.
• View Blocks On/Off - a view containing only park on/off events.
• View Command History - a view containing only operator commands.
(c) Open a log file:

• the log file for today or
• any other log file from the speed bar menu.
View Log File

This view includes the entire content of the log
file such as stand events, GOS system events,
events associated with external systems, for
example FIS, Commands and Blocks On/Off
events.
View Blocks On/Off

This view includes only park on/off events.
Page 15 of 34

View Command History
This view includes only operator commands.
Page 16 of 34
3.2 DGS DOCKING LOG FILES

The DGS Log is an extended version of the Short-log.
The DGS Log automatically dumps to GOS at the end of the docking procedure,
where it is retained for 32 days default. This is configurable in GOS.INI.
From the path C:\Gos\Log on the server(s), each A-VDGS has its own sub directory
where log files are stored. The sub directories have the same name as the stand
symbols in the GOS MMI application.
3.2.1 Viewing and Print-Out
The DGS log files and the Short log files, may be viewed and printed out with the
program Stand Configuration Print-Out Utility (STANDCONFIGPRINT.EXE).
This Utility program is described in the Safedock A-VDGS Manual, Chapter 4
MAINTENANCE.
To store a backup of each Safedock configuration, the configuration files (centreline
and gate configuration) are automatically dumped to GOS from Safedock when the
configuration has been updated in the Safedock.
From the directory C:\Gos\Log on the server(s), each Safedock has its own sub
directory where the configuration files are stored. The sub directories have the same
name as the stand symbols in the GOS MMI application.
Note: The minimum requirement is for Safedock version 5.65 and GOS system
version 3.1.0.
3.4 CLOSING DGS FOR MAINTENANCE
The stand can be closed for remote access due to planned maintenance activities.
Only local operation and maintenance operations using SdConfig are allowed in this
state. All other communication is blocked.
Close for Maintenance Image examples

(a) Select Close for Maintenance from the drop down
menu.
Once maintenance is finished, the stand can be opened

for operation.
(b) Select Open after Maintenance from the drop down
menu.
Page 17 of 34
3.5 DISPLAY OF A-VDGS TYPE

The GOSHMI can be configured to display the type of A-VDGS installed on a stand.
The information is available by right-clicking on the stand symbol.
The first line in the drop down menu displays the stand name together with type
information (Stand F4 Type 2).
The text displayed is configurable in GOS.INI on the local computer.
3.6 SAFEDOCK MAINTENANCE USING SDCONFIG
Maintenance on Safedock units can be performed from GOS using the utility SdConfig
software (SDCONFIG.EXE).
(a) From a workstation, log on to Windows as a maintenance user - dgsmaint.
(b) From Windows Explorer, go to the shared network folder - SDK on the server.
(c) Start SdConfig.exe by double-clicking on the filename.
Note: For more information, see the Safedock A-VDGS Manual Chapter 4
MAINTENANCE.
Page 18 of 34
4. DOCKING CONTROL
A Safedock A-VDGS system at a stand can be controlled from the local Operator
Panel (OP) on the apron or from a GOS workstation. The local control operator panel
and the GOS always work in parallel. However the GOS workstation has additional
data entry features.
4.1 DOCKING COMMANDS
4.1.1 Log On
A user must be logged on to perform docking control functions of the GOS system.
Without being logged on, current status can be displayed, local operation at the stand
is allowed and the Log File can be viewed.
Note: In order to prevent unauthorised personnel from operating the system, such as
control of a Safedock unit, a password (option) is available as a system setting.
Log On to the GOS system Image examples

(a) Log On in one of the following ways:
• Right click anywhere on the screen
and select Log On from the drop
down menu.
• Select a particular stand and select

Log On from the drop down menu.
Note: If required, enter a user ID and a

password.
Page 19 of 34
4.1.2 Command menus

After logging on as a defined user, command menus are available by clicking on the
screen or a particular stand.
Use command menus Image examples

From the GOS Monitor select a
command, such as Log Off.
Use commands available for the

specific Stand..., such as Ready.
Page 20 of 34
4.1.3 First time start up, administration and creating users

At first time GOS system start up, the original supervisor logs on as follows:
User ID - safegate
Password - gos (original password)
Note: Once a new user or supervisor has been assigned, the original user and
password is removed. It is therefore important to first assign a new supervisor and
password, before a new user is defined.
The new supervisor can then create other users (or other supervisors) and assign
them passwords.
The user or supervisor can be, for example the name of the person (in plain text), who
is to operate, and the password is a secret code for each individual.
The main difference between a supervisor and a user is that the supervisor has the
power to decide who is to be authorised as a user.
Create/remove supervisors/users Image examples

(a) Log on as a supervisor and click anywhere on
screen for the GOS Monitor to appear.
(b) Select Administration to create new/remove

supervisors and/or users.
To create new supervisor or user:

(c) From the Supervisor or Users area, click New
and enter the user name and password.
(d) Click OK when finished.
To remove a supervisor or user:

• From the Supervisor or Users area, select the
name in the respective list, click Remove and
OK when finished.
To log off:
• Select Log Off when supervisor tasks are
completed.
Page 21 of 34
4.1.4 Starting a Docking Procedure

A docking procedure can be started from GOS, or from the apron (Safedock A-
VDGS/Operator Panel).
Start a docking procedure Image examples

(a) When using GOS, right-click over a
stand and a command menu appears.
This menu indicates which commands
are allowed for the selected stand.
(b) Before Start-of-docking can be
performed from the GOS system, select
the Open Stand command.
Note: This procedure is for safety
reasons, as the tower operator can not
personally inspect the stand area before
such an order.
(c) Click Yes to confirm and send the

command to Safedock.
Note: From the menu, commands
displayed are allowed. Every command
requires confirmation by the operator.
(d) Clicking StartDock in the command

menu.
(e) Select Manufacturer and Aircraft Type
from the drop down menu.
(f) Click Yes to confirm and the command
is sent to Safedock.
Page 22 of 34
4.1.5 Activating a Scheduled Docking

When the stand has been scheduled with a flight (usually received from a FIS
system), the operator has the possibility to activate the docking system with the
scheduled flight information.
Activate a scheduled docking Image examples

(a) From GOS, right-click over a stand and
the command menu appears.
(b) Click Activate in the menu to start the
docking.
(c) Click Yes to confirm the command and

send to Safedock.
Page 23 of 34
4.1.6 Inserting a Scheduled Flight

If FIS is unavailable and no flights are sent to GOS, the flights can be inserted from
the GOSMMI instead.
Insert a scheduled flight Image examples

(a) From GOS, right-click over a stand and
select Schedule Flight.
(b) Select A/C Type.
(c) Select Arr/Dep (Arrival or Departure
flight).
(d) Enter Flight No. (number)
(e) Enter Reg. No. (registration number, if
one exists)
(f) Select STAD time (scheduled time of
arrival/departure).
(g) Select ETAD time (estimated time of
arrival/departure).
(h) Click Schedule Docking to send the
flight for further processing.
Note: The ETAD time determines when the

flight is to be scheduled. Default
configuration is set to 10 minutes before
ETAD time.
For example, setting the ETAD time to one
hour ahead of current time causes the flight
to be scheduled in 50 minutes.
Page 24 of 34
4.1.7 Displayed statuses during docking

4.1.7.1 Command (latest)
The latest command made from GOS is displayed with the user identity on the bottom
line of the GOS Monitor screen, as in the following example.
LAST COMMAND EXAMPLE
4.1.7.2 Active or Docking

The activated stand state changes to Active or Docking. Based on information from
the GMS, Flight No and Aircraft type, information appears in the status box, if this
pop-up menu field is selected.
GOS MMI STATUS BOX
4.1.7.3 Parked
When a docking is completed, the stand status changes to Parked.
DOCKING COMPLETED MENU EXAMPLES
Page 25 of 34
4.1.7.4 Safedock Operator Panel

If GOS is not working, or the tower operator has stated the wrong aircraft type, the
operator at the apron can always start a docking procedure from the Safedock
Operator Panel (at the apron/bridge), by selecting from the aircraft type(s) from the
profiles in the menu(s) and pressing the Enter button.
The GOS system indicates (in the GOS Monitor status window) the source of the Start
Docking command.
If a docking is started from the Safedock Operator Panel, based on information from
the GMS/FIDS, the Flight No., information is displayed in the status box under the
aircraft type.
4.1.8 Shut down
Shut Down can be used if there is a
reason for turning off the Safedock A-
VDGS unit. A typical reason could be a
last minute change of Stand, where the
aircraft is to arrive at another Stand than
first selected.
Note: The GOS operator must confirm
the command before it is sent to
Safedock.
SHUT DOWN MENU EXAMPLE
4.1.9 Park On
Select Park On and the aircraft type from the drop down menu for a manual park on
procedure.
Note: The GOS operator must confirm the command before it is sent to Safedock.
When GOS has a connection to a FIS system and a flight is associated with the
operation (Safedock is scheduled for arrival with a flight received from FIS), a Blocks
On transaction is sent to FIS.
4.1.10 Park Off
When the Safedock is parked with an aircraft, Safedock periodically scans the stand
area for the departure of the aircraft, and when the aircraft is no longer detected at the
stand the Safedock automatically changes to Ready state.
Alternatively, select Park Off from the drop down menu for a manual Park Off
procedure.
Note: The GOS operator must confirm the command before it is sent to Safedock.
If GOS includes connection to a FIS system and a flight is associated with the
operation (Safedock is scheduled for departure with a flight received from FIS), a
Blocks Off transaction is sent to FIS.
Note: Local Blocks On/Off transactions (no flight information available from FIS) can
also be reported to a FIS system, if configured to do so. This is an option which
depends on the interface between GOS and FIS.
Page 26 of 34
4.2 CAMERA
4.2.1 Viewing Live Images
Live images can be view from the GOSHMI if a camera is installed in a Safedock.
View live images from a Safedock Image example

• Right click over a stand symbol
and select View Camera from the
drop down menu. A camera
window appears on screen
showing live images from the
selected stand.
4.2.2 Viewing Recorded Images

The GOS system can be configured to record dockings, which then can be viewed
from the GOS HMI.
View recording(s) from a Safedock Image examples

(a) Right click over a stand symbol
and select View Camera Log file
from the drop down menu.
(b) Click one of the following:
1. Open today’s recordings
(select, view recording(s) for
current day, selected stand).
2. Open any recording
(select, view available
recording(s), selected stand). 1 2 3 4
3. About/Info.
4. Close.
(c) Once a camera recoding has

been opened, it can be viewed or
stepped through one picture at a
time by using the available
buttons as follows:
1. Play/Pause
2. Stop 1 2 3 4
3. Back
4. Forward
Page 27 of 34
4.3 ADJACENT STAND INTERLOCK

4.3.1 Important Things to Know
In order for the interlock functionality to work correctly, it’s important that the Safedock
systems are holding correct status. If an aircraft is manually towed in to a stand, a
manual Park On must be made from GOS or from the operator panel to put the stand
in correct status. The simulated stands must be manually Parked On from the
GOSMMI. Thus, any stand which has an aircraft parked must be in Parked state.
More information about the interlock feature can be found in the System Description
chapter.
Page 28 of 34
5. FIS INTERFACE
5.1 BASIC FUNCTIONALITY
FIS sends arrival and departure flight information to GOS prior to arrival/departure.
One arrival and/or one departure flight at a time per stand is sent to GOS (not the
complete flight scheduled in advance). Therefore, a new flight sent from FIS overrides
any existing flight for a stand.
GOS sends Block On/Off events to FIS upon successful arrival/departure.
5.2 ARRIVAL PROCEDURE
1. Before the aircraft arrives at the gate, after touchdown, FIS sends a flight to GOS.
2. When the flight is within the time window for start of docking (configurable: default
is 10 minutes before best time available of arrival or BTA) and Safedock is ready
to accept the flight (in Ready and Scheduled status), GOS schedules Safedock or
starts Safedock with the flight (schedule or start of docking is configurable in
GOS).
Note: A scheduled docking needs to be activated from GOS or from the local
Safedock Operator Panel at the gate.
3. Upon successful docking, a Block On message is sent to FIS.
• As long as the docking system has not been activated, FIS can update the flight
(change stand, new aircraft, new registration number and more).
• If Safedock is in a status, for example maintenance or error, that the arrival flight
cannot be accepted, GOS does not Schedule the Safedock with the flight.
However, if Safedock changes to a status in which it can accept the flight, then
GOS schedules the Safedock unless the flight is too old.
Note: The time when a flight is considered to be old is configurable.
5.3 DEPARTURE PROCEDURE
1. Before departure, FIS sends a departure flight to GOS (10 minutes before best
time available of departure or BTD).
2. When the flight is within the time window for start of scanning (configurable:
default is 10 minutes before BTD) and Safedock is Parked, GOS schedules
Safedock with the flight and start Park Off detection.
3. Upon successful departure of the aircraft, a Block Off message is sent to FIS.
• As long as the docking system remains Parked, FIS can update the departure
flight.
• If Safedock is in a status, for example Ready, Maintenance or error, that the
departure flight cannot be accepted, GOS does not schedule Safedock with the
flight. However, if Safedock changes to a status in which it can accept the flight,
then GOS schedules the Safedock unless the flight is too old.
Page 29 of 34
5.4 RIDS INFORMATION

Ramp Information Display System (RIDS) is based on the flight information received
from FIS prior to each docking, the system can be configured to display text
messages on Safedock some time before start of docking. The following text
information is currently available: Main flight number, ETAD or STAD and Count down
time to Arrival or Departure, for example:
ARRIVAL DEPARTURE
Note: The line on the Safedock display where a specific text is displayed is
configurable in GOS.
5.5 SPECIAL OPERATIONAL PROCEDURES
There are other operational procedures for a GOS operator using a connection to a
FIS system, for example unprocessed arriving flight or an unsuccessful docking.
5.5.1 Unprocessed Arriving Flight
If a Safedock unit is in status Scheduled (GOS monitor/grey) it remains so until:
• A start of docking or cancellation (OFF) is selected from the Operator Panel or
• The Shut Down command is used from GOSMMI or
• The flight becomes too old.
Note: Default configuration considers a flight to be old when the time passes
ETAD + 30 minutes.
5.5.2 Unsuccessful Docking
If for any reason the docking was unsuccessful, the GOS operator or bridge user
carries out a manual Park On command to make it possible to process the next
departing flight. Therefore, every docking attempt must end with PARKED status at
the A-VDGS.
Page 30 of 34
6. CMS INTERFACE (OPTION)

The GOS workstation shows the actual state of specific airfield lighting systems such
as Stand Warning Lights (SWL) and LIL Lead-In Lights (LIL), as reported by the
Control Monitoring System (CMS). The colours used for different states are
dependent on site configuration requirements according to a configuration file.
6.1 CMS SYMBOLS FOR SLW AND LIL (OPTION)
Examples of shapes and colours of the indications are as follows:
1. Frame around the button shows status of Stand Warning Lights (SWL)
1.1 SWL off 1.2 SWL on 1.3 SWL in alarm 1.4. Stand disabled
Default RGB: Default RGB: Default RGB: Default RGB:

192, 192, 192 51, 204, 51 255, 0, 255 255, 102, 0
2. Inner area of the button shows status of Lead-In lights (LIL)
2.1 LIL off 2.2 LIL on 2.3 LIL in alarm 2.4 Stand disabled
Default RGB: Default RGB: Default RGB: Default RGB:

192, 192, 192 0, 255, 0 255, 0, 255 255, 102, 0
2.5 LIL on pending
Default RGB:
0, 128, 128
Page 31 of 34
GOS Overview example

The approximate location, orientation and size of the light indications are shown by
aircraft symbol/ the symbolic centre line:
6.2 CMS - SWL STATES (OPTION)

Each symbol includes inner and outer areas, where colours (options) reflect the status
in the system.
When a state is received from Airfield Guard Lights (AGL) that is not specified in the
tables the symbol remains unchanged.
Page 32 of 34
6.3 GOS CMS FUNCTIONALITY

Specific functionality is designed for CMS interface in GOS.
1. When the GOS workstation detects the absence of an active AGL interface, it
marks all gates as in alarm (error).
2. AGL-related commands are logged in the GOS log, with user- and host name, as
available.
3. Error handling is implemented within GOS for both Arrival/Departure processes
are to include modified states as follows:
Error Standard GOS CMS Interface

Active arrival During an active arrival, if In case of a non-transient
A-VDGS enters an error error during an active
state, then GOS initiates arrival (A-VDGS has been
a timeout of 120 seconds activated), the lights shall
and switches off SWL & be switched OFF only
LIL for that particular with a manual input to
stand. GOS.
Normal operation shall
resume if the A-VDGS
goes from COM-error to
parked state in this
scenario. (No other errors
can go directly to the
parked state as a ready-
state always comes in-
between).
Active departure During an active In case of a non-transient
departure if A-VDGS error anytime after an
enters an error state then operator has activated the
GOS automatically departure procedure,
commands Lead-in LIL lights shall be
lights ON and initiates a switched ON only with a
timeout of 120 seconds manual input to GOS.
and switches off SWL & Once an error occurs, the
LIL for that particular light shall remain
stand. unchanged until an
operator either stops the
departure procedure, or
manually activates LIL.
No lights shall be turned
off until an operator gives
the command to do so.
For more information, see site specific ICD documentation.
Page 33 of 34
Page 34 of 34
Document: 3A_GOS_OP_Features Version: 1.3
OPERATION: APPENDIX A
GOS FEATURES (OPTIONS)
CONTENTS
1. GENERAL ..................................................................................................................... 2
1.1 GOS SYSTEM TOPOLOGY ............................................................................. 2
1.2 REDUNDANT SERVERS ................................................................................. 2
1.3 COMMUNICATION BETWEEN GOS AND DGS ............................................. 2
1.4 OPERATING SYSTEM SOFTWARE................................................................ 2
2. STANDARD FEATURES .............................................................................................. 3
2.1 DOCKING MONITORING AND CONTROL ..................................................... 3
2.2 GOS EVENT LOG FILES ................................................................................. 3
2.3 AUTOMATIC UPLOAD OF SAFEDOCK DOCKING LOG FILES .................... 3
2.4 AUTOMATIC UPLOAD OF SAFEDOCK CONFIGURATION FILES................ 3
2.5 ERROR WINDOW ............................................................................................ 3
2.6 STATUS WINDOW ........................................................................................... 3
2.7 INTERFACE WINDOW ..................................................................................... 4
3. OPTIONAL FEATURES ................................................................................................ 5
3.1 CAMERA (OPTION) ......................................................................................... 5
3.2 INTERLOCK FUNCTION (OPTION)................................................................. 5
3.3 SAFEDOCK MAINTENANCE (OPTION) .......................................................... 5
3.4 INTERFACE TO EXTERNAL SYSTEMS (OPTIONS)...................................... 5
3.4.1 Flight Information System (FIS) ............................................................... 5
3.4.2 Technical Management System (TMS) .................................................... 5
3.4.3 Ramp Information Display System (RIDS) .............................................. 5
3.4.4 Network Time Protocol (NTP) ................................................................... 5
3.4.5 Control & Monitoring System (CMS)........................................................ 5
3.5 UPS STATUS (OPTION) .................................................................................. 6
3.6 CLOSED FOR MAINTENANCE (OPTION) ...................................................... 6
3.7 IASS SYSTEM INFO TEXT (OPTION) ............................................................. 6
3.7.6 Functional design ...................................................................................... 6
3.8 GOS WORKSTATION SYMBOLS .................................................................... 7
Page 1 of 8
1. GENERAL
This document is a description of functional variations (options available) in the GOS
system. The features described are related to the following categories:
(a) GOS system setup
(b) Operating system software
(c) Redundant servers
(d) Communication interface between GOS and DGS
(e) Standard GOS features
(f) Camera
(g) Connections to external systems
1.1 GOS SYSTEM TOPOLOGY
A GOS system layout example can be found in System Description Appendix A
Topology.
1.2 REDUNDANT SERVERS
Redundant GOS servers are used to increase system reliability. A more detailed
description can be found in System Description Appendix B Redundant GOS Server.
1.3 COMMUNICATION BETWEEN GOS AND DGS
Safedock A-VDGS is connected to GOS using an Ethernet LAN or Serial
Communication.
1.4 OPERATING SYSTEM SOFTWARE
Server: Windows 2003
Workstation: Windows XP Pro.
Page 2 of 8
2. STANDARD FEATURES
This section describes standard features included in a GOS system.
2.1 DOCKING MONITORING AND CONTROL
The primary purpose of the GOS system is Docking Control and Monitoring. At any
GOS subsystem the airport layout with stands and docking systems can be displayed
and monitored. The Docking Control and Monitoring function is explained in the
OPERATIONS chapter.
2.2 GOS EVENT LOG FILES
Event Log files are created once per day, and used for statistics and maintenance of
A-VDGS.
A docking procedure contains several events, which are stored with time stamps, for
example DGS Ready; Active (aircraft, flight); Docking (aircraft, flight); Parked (aircraft,
flight, Reg No).
The name of a log file will be the date of the day, using the format YYMMDD.log
The files are stored automatically, one per day, and are stored for a configurable
period of time. Default period is thirty-two days. After the period has elapsed, files are
automatically deleted.
The Event Logging facility is explained in the OPERATIONS chapter.
2.3 AUTOMATIC UPLOAD OF SAFEDOCK DOCKING LOG FILES
Each docking with a Safedock generates a docking log. The docking log is
automatically dumped to GOS at the end of each docking procedure, where it is
retained for 30 days.
To store a backup of each Safedock configuration, the configuration files (centreline
and gate configuration) are automatically dumped (saved) to GOS from Safedock, as
a configuration is updated in a Safedock.
2.5 ERROR WINDOW
The error window is modified with functionality as follows:
• When a new error is reported by Safedock, it appears in the error window with
white text on a red background. This message replaces any previous error
message for that stand.
• When a new communication error with a Safedock is reported, it appears in the
error window as an error message for information only, with black text on a red
background.
• When a new error appears, the audio alarm is activated, if enabled.
• When there are no unacknowledged errors in the list, the audible alarm is
deactivated.
• If an error is rectified or removed at the Safedock, an acknowledged error
message is removed from the window but an unacknowledged error remains.
• When the error is acknowledged, it changes colour to white text on a grey
background for errors and black text on grey background for communication
errors.
• An error that has already been rectified or removed from the Safedock is removed
from the error window immediately when acknowledged.
• The actual colour scheme for messages in the error window is configurable, as in
the .INI file.
2.6 STATUS WINDOW
There is no need to acknowledge status messages. It is not possible to acknowledge
or remove messages from it.
Page 3 of 8
Status messages mirror the current status at each stand, except for error states, when
the information is in the error window only.
2.7 INTERFACE WINDOW
There is no need to acknowledge interface status messages. There is no command
menu in the status window.
Interface status messages always mirror the state of the interface.
Page 4 of 8
3. OPTIONAL FEATURES
GOS includes optional features available for specific site requirements.
3.1 CAMERA (OPTION)
Cameras are installed in the Safedock units at the stands. A GOS workstation is used
for the presentation of images from any stand camera.
Stand images are synchronised with the docking monitoring function of GOS. For
of stand images may be automatically started and logged, until the aircraft comes to a
parked position.
A more detailed description can be found in the System Description Appendix C
Camera Integration.
The Docking Control and Monitoring function is explained in the OPERATIONS
chapter.
3.2 INTERLOCK FUNCTION (OPTION)
With this feature, start of docking for a stand may be blocked for operation based on
the selected aircraft type and the current status of adjacent stands.
For more information, see the System Description chapter.
3.3 SAFEDOCK MAINTENANCE (OPTION)
Safedock unit maintenance can be performed from GOS using the software
SDCONFIG.EXE.
This Utility program is described in the Safedock Manual, MAINTENANCE chapter.
3.4 INTERFACE TO EXTERNAL SYSTEMS (OPTIONS)
Interfaces to external systems are available as options according to specific site
requirements in a separate Interface Control Document (ICD).
For more information, see site ICD documentation.
3.4.1 Flight Information System (FIS)
The GOS system is connected to a FIS to exchange flight information.
FIS provides GOS with arrival and departure flight information and GOS reports Block
On/Off events to FIS upon successful arrival/departure docking.
For more information, see the site FIS Interface Control Document.
3.4.2 Technical Management System (TMS)
The GOS is connected to a TMS to provide TMS with system statuses for the various
GOS and Safedock systems installed on a site.
For more information, see the site TMS Interface Control Document.
3.4.3 Ramp Information Display System (RIDS)
The GOS is connected to a RIDS to provide GOS with text messages that are
displayed on the A-VDGS.
For more information, see the site RIDS Interface Control Document.
3.4.4 Network Time Protocol (NTP)
All GOS computers are synchronizing time against an airport master clock using NTP.
3.4.5 Control & Monitoring System (CMS)

The GOS workstation shows the actual state of specific airfield lighting systems such
as Stand Warning Lights (SWL) and LIL Lead-In Lights (LIL), as reported by Control &
Monitoring System (CMS). The colours used for different states are dependent on site
configuration requirements according to a configuration file.
Page 5 of 8
3.5 UPS STATUS (OPTION)

For A-VDGS units equipped with UPS, there is a new icon in the graphic
representation of the unit. This icon, for example a flashing battery, appears for any
gate using UPS rather than mains power.
3.6 CLOSED FOR MAINTENANCE (OPTION)
GOS includes a Closed for Maintenance function using a GOS workstation.
The status is managed by the individual communication links to A-VDGS units.
The A-VDGS units continue to be available for local operations.
The communication link overrides any state reported by the actual A-VDGS with this
status in GOS.
3.7 IASS SYSTEM INFO TEXT (OPTION)
GOS manages IASS system text messages formatted according to the principle
outlined in version 4.0 of the specification.
3.7.6 Functional design
IASS system text messages or info texts appear automatically for each gate, as a
user points the mouse above a particular gate symbol.
• IASS system text message may also include A-VDGS text messages.
• IASS system text is divided into the following subsystems, and each of these
subsystems has a fixed set of states. Some of the subsystems can exist in
multiple, up to 4, instances at a stand.
An incoming IASS message is a string with system code and status code for each
of the systems.
The subsystems and their states are:
- IASS Local [IL]
 Red [R]
 Orange [O]
 Green [G]
- PLB (1-4) [PLx]
 On [I]
 Off [O]
 Maintenance [M]
 Auto [A]
- GPU 400Hz (A-D) [4x] *
 On [I]
 Off [O]
- GPU 400Hz Pit [4P]
 Fully Open [O]
 Fully Closed [C]
- PCA (A-D) [Px] *
 On [I]
 Off [O]
- PCA Pit (A-D) [PPx]
 Fully Open [O]
 Fully Closed [C]
- AHU (A-D) [Ax] *
 On [I]
 Off [O]
Page 6 of 8
* Note: These codes differ from the version 4.00 specification. The codes are based
on the actual data found in the IASS feed.
The codes used for the system/status is indicated in brackets [code]. For multi-
instance systems, the system subID is marked with an x and can have the values 1-4
or A-D only.
For example, the message - ILRPL1OPL2O4AI4BI4PCPAIPPACAAO
appears as: ILR, PL1O, PL2O, 4AI, 4BI, 4PC, PAI, PPAC, AAO,
and is reported as an info text:
Line Message
3 IASS Local: Red
4 PLB 1:Off 2:Off
5 400Hz A:On B:Off
6 400Hz Pit: Fully Closed
7 PCA A:On
8 PCA Pit A:Fully Closed
9 AHU: Off
Sample messages:
ILOPL1OPL2O4AI4BI4PCPAIPPACAAO
ILGPL1OPL2OPL3O4AI4BI4CI4DI4PCPAIPBIPPACPPBCAAIABO
3.8 GOS WORKSTATION SYMBOLS
GOS workstation symbols are based on a name, a status and a colour scheme.
GOS workstation symbols have on/off capability (for UPS).
Page 7 of 8
Page 8 of 8
Document: 3B_GOS_OP_Access_Manager Version: 1.3
OPERATION: APPENDIX B
GOS ACCESS MANAGER (OPTION)
CONTENTS
1. INTRODUCTION ........................................................................................................... 2
1.1 GOS ACCESS MANAGER ............................................................................... 2
2. INSTALLATION............................................................................................................. 3
2.1 INSTALL GOS ACCESS MANAGER ............................................................... 3
3. MENUS AND COMMANDS .......................................................................................... 4
3.1 NAVIGATE MENUS AND COMMANDS ........................................................... 4
4. USING GOS ACCESS MANAGER ............................................................................... 7
4.1 START GOS ACCESS MANAGER AND LOGIN ............................................. 7
4.1.1 Start GOS Access Manager ...................................................................... 7
4.1.2 Login ........................................................................................................... 7
4.2 EDITING USERS GROUPS AND CREDENTIALS .......................................... 8
4.2.1 Create, update or delete users ................................................................. 8
4.2.2 Create, rename or delete user groups ..................................................... 8
4.2.3 Create, rename or delete stand groups ................................................... 9
4.2.4 Create, rename or delete credentials ....................................................... 9
4.3 CONFIGURE USERS, GROUPS, STANDS AND CREDENTIALS................ 10
4.3.1 Select groups membership ..................................................................... 10
4.3.2 Select users for a group .......................................................................... 10
4.3.3 Select credentials for a user group........................................................ 10
4.3.4 Select stands for a stand group ............................................................. 10
4.3.5 Select individual stands for a credential group .................................... 11
4.3.6 Select stand groups for a credential group .......................................... 11
4.3.7 Select credentials for a credential group .............................................. 11
5. MORE INFORMATION ................................................................................................ 12
5.1 DOCUMENTATION ........................................................................................ 12
5.2 REFERENCES AND TRADEMARKS ............................................................. 12
5.3 TERMINOLOGY.............................................................................................. 12
5.4 LANGUAGE .................................................................................................... 12
Page 1 of 12
1. INTRODUCTION
1.1 GOS ACCESS MANAGER
GOS Access Manager is a tool to manage user credentials, such as setting up
administration and user rights and privileges for airport personnel in a Gate Operating
System (GOS).
GOS Access Manager benefits to GOS
users are:
• Reduced lead times for system
changes.
• Changes can be made for specific
site requirements.
• Strengthened ownership of the
purchased system with control over
system configuration.
• Improved management efficiency
with internal resources and less
traffic disturbance.
This document includes information how to install and use GOS Access Manager on a
computer with Microsoft Windows XP.
Note: GOS Access Manager software releases are subject to the latest development
improvements and may differ to the information and image examples used in this
document.
Software images and menu selections (Arial Bold font) used in instructions are
examples from the software language used for creating this document, English UK.
These examples may therefore not to be localised in any translated revisions of this
document if the software is not available in the corresponding language for translation.
Page 2 of 12
2. INSTALLATION
GOS Access Manager is installed with a setup application, on a computer with
Windows XP.
2.1 INSTALL GOS ACCESS MANAGER
(a) Insert the installation CD into your computer disk drive

and open the CD.
(b) Double-click Gosinstall.exe.
(c) Select Install GOS Access Manager.
(d) Press Start and follow the instructions that appear.
Note: Click Accept to install Microsoft .NET
Framework 2.0. This message does not appear if it is
already installed on your computer.
Page 3 of 12
3. MENUS AND COMMANDS

GOS Access Manager includes a number of menus, tabs, entry fields, commands and
views. Commands are based on standard Windows application commands specifically
adapted for GOS Access Manager.
The following menus with commands are available:
3.1 NAVIGATE MENUS AND COMMANDS

Menus, tabs, commands Description Examples
File Menu command
Exit Close the program.
Database Menu command
Reread data from database Reload system configuration
information.
About Program, version and more
information.
Click OK to close.
Users Tab views and commands

Existing users Select from a list of users to edit
or view information.
Edit user Entry fields and commands to
create, update and delete users.
User name Enter a user name.
Password Enter a user password.
Verify password Enter the same user password
for confirmation.
Create user Create a user with the
information in the entry fields.
Update selected user Select an existing user, edit user
information in the entry fields
and click to update.
Delete selected user Select an existing user and click
to delete.
Group membership View the groups to which a user
belongs.
Select user group Select an existing user, and use
to select from available user
groups to belong to.
Page 4 of 12

User groups Tab views and commands
Existing user groups Select from a list of user groups
to edit or view information.
Edit user group Entry fields and commands to
create, rename and delete user
groups.
Group name Enter a user group name.
Create group Create a group with the
information in the entry field.
Rename selected group Select an existing group, edit the
group name in the entry field
and click to rename.
Delete selected group Select an existing group and
click to delete.
Users in group View the users in the group.
Select users Select from existing users for
group membership.
Credentials for group Select from existing stand
credentials for the group.
Select credentials Select an existing group, and use
to select from available rights
for the group.
Stand groups Tab views and commands

Existing stand groups Select from a list of stand groups
to edit or view information.
Edit stand group Entry fields and commands to
create, rename and delete stand
groups.
Group name Enter a stand group name.
Create group Create a stand group with the
information in the entry field.
Rename selected group Select an existing stand group,
edit the stand group name in the
entry field and click to rename.
Delete selected group Select an existing stand group
and click to delete.
Stands in group View the stands in the stand
group.
Select stands Select from existing stands for
stand group membership.
Page 5 of 12

Stand credentials Tab views and commands
Existing stand credentials Select from a list of stand
credentials to edit or view
information.
Credential name Enter a stand credential name.
Create stand credential Create a stand credential with
the information in the entry
field.
Rename selected credential Select an existing stand
credential, edit the stand
credential name in the entry
field and click to rename.
Delete credential Select an existing stand
credential and click to delete.
Included stands Select the tab for a list of
existing stands credentials for
stand group membership.
Select stands Use to select stands for
included stands.
Included stand groups Select the tab for a list of stand
groups to edit or view
information.
Select stand groups Use to select stand groups for
included stand groups.
Included credential types Entry fields and commands to

create, rename and delete stand
groups.
Select credentials Use to select credentials for
included credential types.
Page 6 of 12
4. USING GOS ACCESS MANAGER

GOS Access Manager is designed with an intuitive user interface and logical
functionality.
4.1 START GOS ACCESS MANAGER AND LOGIN
4.1.1 Start GOS Access Manager
• Double-click on the desktop icon or

• Go to Start\Programs\GOS Access Manager to start the
program.
4.1.2 Login
Enter information:
(a) User name
(b) Password
(c) Server, if required or different from localhost.
Page 7 of 12
4.2 EDITING USERS GROUPS AND CREDENTIALS
4.2.1 Create, update or delete users

• Click the Users tab.
Create a new user:

(a) Enter a new user name, password and verify the
password.
(b) Click Create user.
Update an existing user:
(a) Select an existing user.
(b) Change information in the entry fields.
(c) Click Update selected user.
Note: When renaming a user only, no new password information
is entered for the password to remain the same.
Delete a user:
(a) Select an existing user.
(b) Click Delete selected user.
4.2.2 Create, rename or delete user groups

• Click the User groups tab.
Create a new user group:
(a) Enter a new group name.
(b) Click Create group.
Rename an existing user group:
(a) Select an existing user group.
(b) Change the name in the entry field.
(c) Click Rename selected group.
Delete selected group:
(a) Select an existing user group.
(b) Click Delete selected group.
Page 8 of 12
4.2.3 Create, rename or delete stand groups
• Click the Stand groups tab.

Create a new stand group:
(a) Enter a new stand group name.
(b) Click Create group.
Rename an existing stand group:
(a) Select an existing stand group.
(c) Click Rename selected group.
Delete selected group:
(a) Select an existing stand group.
(b) Click Delete selected group.
4.2.4 Create, rename or delete credentials

• Click the Stand credentials tab.
Create a new stand credential:
(a) Enter a new stand credential name.
(b) Click Create stand credential.
Rename existing stand credentials:
(a) Select an existing stand credential.
(c) Click Rename credential.
Delete selected credential:
(a) Select an existing stand credential.
(b) Click Delete credential.
Page 9 of 12
4.3 CONFIGURE USERS, GROUPS, STANDS AND CREDENTIALS
4.3.1 Select groups membership

(a) Click the Users tab.
(b) Select an existing user group.
(c) Click Select user groups.
• From Available user groups, click to select or
• From Selected user groups, click to remove.
(d) Click Close when completed.
4.3.2 Select users for a group

(a) Click the User groups tab.
(b) Select an existing user.
(c) Click Select users.
• From Available users, click to select or
• From Selected users, click to remove.
4.3.3 Select credentials for a user group

(a) Click the User groups tab.
(b) Select an existing user group.
(c) Click Select credentials.
• From Available credentials, click to select or
• From Selected credentials, click to remove.
4.3.4 Select stands for a stand group

(a) Click the Stand groups tab.
(b) Select an existing stand group.
(c) Click Select stands.
• From Available stands, click to select or
• From Selected stands, click to remove.
Page 10 of 12
4.3.5 Select individual stands for a credential

group
(a) Click the Stand credentials tab.
(b) Select an existing stand credential.
(c) Click the Included stands tab, in the lower window.
(d) Select an existing stand from the list.
(e) Click Select stands.
• From Available stands, click to select or
• From Selected stands, click to remove.
(f) Click Close when completed.
4.3.6 Select stand groups for a credential
group
(c) Click the Included stand groups tab, in the lower
window.
(d) Select an existing stand group from the list.
(e) Click Select stand groups.
• From Available stand groups, click to select or
• From Selected stand groups, click to remove.
4.3.7 Select credentials for a credential group
(c) Click the Included credential types tab, in the lower
window.
(d) Select an existing credential type from the list.
(e) Click Select credentials.
• From Available credentials, click to select or
• From Selected credentials, click to remove.
Page 11 of 12
5. MORE INFORMATION
5.1 DOCUMENTATION
This document aims to give personnel an insight into the benefits of using the GOS
Access Manager tool and a guide to general use that is logical and intuitive.
5.2 REFERENCES AND TRADEMARKS

GOS, GOS Access Manager are trademarks of Safegate Group.
Other products and company names mentioned herein may be the trademarks of their
respective owners.
Any rights not expressly granted herein are reserved. All illustrations and images are
for illustration only and may not accurately depict the actual product.
5.3 TERMINOLOGY
This document includes a selection of terms, words and abbreviations.
Term or word Abbreviation Comment
Gate Operating system GOS

Technical Writer TW
Product Leader PL
5.4 LANGUAGE
Original documentation is created in English (U.K.).
Note: Software images and menu selections (Arial Bold font) used in instructions are
For more information, see www.safegate.com.
Page 12 of 12
Document: 3C_GOS_OP_Reporter Version: 1.3
OPERATION: APPENDIX C
GOS REPORTER (OPTION)
CONTENTS
1. INTRODUCTION ........................................................................................................... 2
1.1 GOS REPORTER ............................................................................................. 2
1.2 DOCUMENTATION .......................................................................................... 2
2. INSTALLATION............................................................................................................. 3
2.1 INSTALL GOS REPORTER ............................................................................. 3
3. MENUS AND COMMANDS .......................................................................................... 3
3.1 NAVIGATE MENUS AND COMMANDS ........................................................... 3
4. USING GOS REPORTER ............................................................................................. 4
4.1 USE GOS REPORTER ..................................................................................... 4
4.1.1 Start GOS Reporter .................................................................................... 4
4.1.2 Login ........................................................................................................... 4
4.1.3 Create and use a log view (query) ............................................................ 4
4.1.4 Log view examples .................................................................................... 5
5. MORE INFORMATION .................................................................................................. 6
5.1 DOCUMENTATION .......................................................................................... 6
5.2 REFERENCES AND TRADEMARKS ............................................................... 6
5.3 TERMINOLOGY................................................................................................ 6
5.4 LANGUAGE ...................................................................................................... 6
Page 1 of 6
1. INTRODUCTION
1.1 GOS REPORTER
GOS Reporter is a tool for airport personnel using a Gate Operating System (GOS) to
generate reports. Reports are generated by making queries against the GOS log.
GOS Reporter requires the following GOS functionality:

• MySql database connection.
• DbLogger functionality activated.
- DbLogger writes system log entries into the table syslog in the database.
- Syslog is the table from which GOS Reporter extracts data.
The following common queries are supported:

• Statuses for all gates/the status of a specific gate between two dates (from/to).
The information is sorted and/or filtered by status:
(a) Aircraft
(b) Flight
(c) Tow-in
(d) Gate
(e) Error type
• Errors for all gates/a specific gate between two dates (from/to). The information is
sorted and/or filtered by error type.
• Blocks On/Off for all gates/a specific gate between two dates (from/to). The
information is sorted and/or filtered by blocks on/off.
• Free text searches in error messages.
Note: Other queries can be supported, if required.
1.2 DOCUMENTATION
This document includes information how to install and use GOS Reporter on a
computer with Microsoft Windows XP.
Note: GOS Reporter software releases are subject to the latest development
improvements and may differ to the information and image examples used in this
document.
Software images and menu selections (Arial Bold font) used in instructions are
Page 2 of 6
2. INSTALLATION
GOS Reporter is installed with a setup application, on a computer with Windows XP.
2.1 INSTALL GOS REPORTER
(a) Insert the installation CD into your computer disk drive

and open the CD.
(b) Double-click GosReporterSetup.exe.

(c) Click Next to continue, follow the instructions that
appear.
Note: Click Accept to install Microsoft .NET
Framework 2.0. This message does not appear if it is
already installed on your computer.
(d) When Installation Complete appears, click Close.
3. MENUS AND COMMANDS

GOS Reporter includes a number of menus, entry fields, commands and views.
Commands are based on standard Windows application commands specifically
adapted for GOS Reporter.
The following menus with commands are available:
3.1 NAVIGATE MENUS AND COMMANDS

Menus, commands Description Examples
File
New Query Create a new log view.
Open Query Open previously saved view.
Exit Close the program.
Page 3 of 6
4. USING GOS REPORTER

GOS Reporter is designed with an intuitive user interface and logical functionality.
4.1 USE GOS REPORTER
4.1.1 Start GOS Reporter

• Double-click on the desktop icon or
• Go to Start\Programs\Safegate\GOS Reporter to start
the program.
4.1.2 Login
(a) Enter login information to start the program.
• User name.
• Password.
• IP Address or host name of Server 1 and 2.
(b) Click OK.
Note: At first start up the Server field is empty. User name,
password and server information is verified with a users
table in the GOS database. When verified GOS Reporter
starts.
If only one GOS server is used, the Server 2 field is left
empty.
4.1.3 Create and use a log view (query)
(a) Select File, Log View.
(b) Select From: and To: dates for the query, if required.
(c) Select Main type.
(d) Select Sub type, if required.
(e) Select Aircraft, if required.
(f) Select Gate, if required.
(g) Select Flight, if required.
(h) Click Execute query to create the log view.
The following options are also available:
• Preview – preview the current log before printing.
• Print – print the current log view.
• Open query – open a previously saved log view.
• Save query – save a log as a file (.que) in a folder:
C:\Program Files\Safegate\GOS Reporter\Query.
• Export results – export a log to a file (.txt) in a folder:
C:\Program Files\Safegate\GOS Reporter\Export.
Note: For more information, see the following examples.
Page 4 of 6
4.1.4 Log view examples

• Open a previously saved query.
• Save the current query.
• Change a filter for a query.
• Change a sub type for a query.
• Export a query as a (.txt) file.
Page 5 of 6
5. MORE INFORMATION
5.1 DOCUMENTATION
This document aims to give personnel an insight into the benefits of using the GOS
Reporter program and a guide to general use that is logical and intuitive.
5.2 REFERENCES AND TRADEMARKS
GOS, GOS Reporter are trademarks of Safegate Group.
Other products and company names mentioned herein may be the trademarks of their
respective owners.
Any rights not expressly granted herein are reserved. All illustrations and images are
for illustration only and may not accurately depict the actual product.
5.3 TERMINOLOGY
This document includes a selection of terms, words and abbreviations.
Term or word Abbreviation Comment
Gate Operating system GOS

Technical Writer TW
Product Leader PL
5.4 LANGUAGE
Original documentation is created in English (U.K.).
Note: Software images and menu selections (Arial Bold font) used in instructions are
document if the software is not available in the corresponding language fro translation.
For more information, see www.safegate.com.
Page 6 of 6
Document: 3D_GOS_OP_ICD_Example_FIS Version: 1.3
OPERATION: APPENDIX D
ICD EXAMPLE - FIS (OPTION)
CONTENTS
1. INTRODUCTION ........................................................................................................... 2
1.1 OBJECTIVE ...................................................................................................... 2
1.2 PROTOCOL ...................................................................................................... 2
1.3 SCOPE .............................................................................................................. 2
2. FIS INTERFACE ............................................................................................................ 3
2.1 BASIC FUNCTIONALITY .................................................................................. 3
2.2 ARRIVAL PROCEDURE ................................................................................... 3
2.3 DEPARTURE PROCEDURE ............................................................................ 3
2.4 RIDS INFORMATION ....................................................................................... 4
2.5 SPECIAL OPERATIONAL PROCEDURES ...................................................... 4
2.5.1 Unprocessed Arriving Flight .................................................................... 4
2.5.2 Unsuccessful Docking .............................................................................. 4
2.6 IMPORTANT GOS A-VDGS SYSTEM FUNCTIONALITY ............................... 4
3. ESTABLISHING A CONNECTION AND RECOVERY ................................................. 5
3.1 LINK INITIALISATION ...................................................................................... 5
3.2 LINK FAILURE AND RECOVERY .................................................................... 5
4. APPLICATION PROTOCOL ......................................................................................... 5
4.1 GENERAL ......................................................................................................... 5
4.2 MESSAGE HEADER ........................................................................................ 5
4.3 MESSAGE DATA .............................................................................................. 5
4.3.1 General ........................................................................................................ 5
4.3.2 Available Message Types ......................................................................... 7
4.3.3 Available Data Elements with Attributes ................................................. 8
5. DETAILED MESSAGE DESCRIPTION AND EXAMPLES ........................................ 10
5.1 GENERAL ....................................................................................................... 10
5.2 KEEP ALIVE FROM IP SERVER ................................................................... 10
5.3 ACKNOWLEDGEMENT MESSAGE............................................................... 10
5.4 BASIC FLIGHT FROM FIS ............................................................................. 11
5.5 CANCELLATION/DELETION/DIVERSION OF A FLIGHT FROM FIS ........... 12
5.6 STAND UPDATE FROM FIS .......................................................................... 13
5.7 AIRCRAFT UPDATE FROM FIS .................................................................... 13
5.8 AIRCRAFT REGISTRATION NUMBER UPDATE FROM FIS ....................... 13
5.9 TIME UPDATE FROM FIS .............................................................................. 13
5.10 BLOCKS ON/OFF FROM GOS ...................................................................... 14
Page 1 of 14
1. INTRODUCTION
1.1 OBJECTIVE
This is an example of a site Interface Control Document (ICD). For more information,
see site specific ICD document, if available.
The objective of an ICD document is to give a detailed description of how an external
application can get access to GOS, for example the flight database in order to
read/write flight data.
1.2 PROTOCOL
The transport protocol is TCP/IP. The application protocol is XML.
1.3 SCOPE
This document describes all functions required to provide access to the GOS flight
database for GOS clients.
• Establishing a connection and recovery
• Message format definition
• The method used for monitoring the data link (keep-alive)
• The method used to read flight data from the database
• The method used to insert/update flights into the database
• Error handling
System topology is according to the illustration below.
GOS Active Ethernet LAN External Client

Server DB System
GOS Standby
Server DB
(optional)
Page 2 of 14
2. FIS INTERFACE
2.1 BASIC FUNCTIONALITY
GOS operates in two major modes regarding flight information handling:
Immediate mode or Buffered mode.
1. In immediate mode, GOS handles only one arrival and one departure per stand at
a time and any new flight information overrides the current flight information for
that stand. It is important for FIS to only deliver current flight information, as a new
flight sent from FIS overrides any existing flight for a stand.
2. In buffered mode, GOS stores multiple flights per stand and selects the current
flight for operation based on the Safedock state and flight activation time. In this
mode, FIS can also send a full day of planned flight operations and update them
later as events, such as delays and stand changes. GOS selects and uses flights
as they approach their event window.
It is important FIS sends arrival and departure flight information to GOS in good time
before a flight enters its activation window. The actual size of the activation window is
configured to match the operational procedures at the airport.
GOS sends Block On/Off events to FIS upon successful arrival/departure.
2.2 ARRIVAL PROCEDURE
1. It is important for FIS to send flight information to GOS in good time before an
aircraft arrives at the gate. GOS includes a setting (default 10 minutes) for best
known time of arrival (BTA).
2. When the flight is within the time window for start of docking and Safedock is
ready to accept the flight (in Ready, Ready Open and Scheduled status), GOS
schedules DGS or start DGS with the flight (schedule or start of docking is
configurable in GOS).
Note: A scheduled docking needs to be activated from GOS or from the local
Safedock Operator Panel at the gate.
3. Upon successful docking, a Block On message is sent to FIS.
• As long as the docking system has not been activated, FIS can update the flight
(change stand, new aircraft, new registration number and more).
• If Safedock is in a status, for example maintenance or error, that the arrival flight
cannot be accepted, GOS does not Schedule the Safedock with the flight.
However, if Safedock changes to a status in which it can accept the flight, then
GOS schedules the Safedock unless the flight is too old.
2.3 DEPARTURE PROCEDURE
1. It is important for FIS to send flight information to GOS in good time before an
aircraft departs the gate. GOS includes a setting (default 10 minutes) for best time
available for departure (BTD).
2. When the flight is within the time window for start of scanning and Safedock is
parked, GOS schedules DGS with the flight or start Park Off detection.
3. Upon successful departure of the aircraft, a Block Off message is sent to FIS.
• As long as the docking system remains Parked, FIS can update the departure
flight.
• If Safedock is in a status, for example Ready, Maintenance or error, that the
departure flight cannot be accepted, GOS does not schedule Safedock with the
flight. However, if Safedock changes to a status in which it can accept the flight,
then GOS schedules the Safedock unless the flight is too old.
Page 3 of 14
2.4 RIDS INFORMATION

Ramp Information Display System (RIDS) is based on the flight information received
from FIS prior to each docking, the system can be configured to display text
messages on Safedock some time before start of docking. The following text
information is currently available: Main flight number, ETAD or STAD and Count down
time to Arrival or Departure, for example:
ARRIVAL DEPARTURE
Note: The line on the Safedock display where a specific text is displayed is
configurable in GOS.
2.5 SPECIAL OPERATIONAL PROCEDURES
There are other operational procedures for a GOS operator using a connection to a
FIS system, for example unprocessed arriving flight or an unsuccessful docking.
2.5.1 Unprocessed Arriving Flight
If a Safedock unit is in status Scheduled (GOS monitor/grey) it remains so until:
• A start of docking or cancellation (OFF) is selected from the Operator Panel or
• The Shut Down command is used from GOSMMI or
• The flight becomes too old.
Note: Default configuration considers a flight to be old when the time passes
ETAD + 30 minutes.
2.5.2 Unsuccessful Docking
If for any reason the docking was unsuccessful, the GOS operator or bridge user
carries out a manual Park On command to make it possible to process the next
departing flight. Therefore, every docking attempt must end with PARKED status at
the A-VDGS.
2.6 IMPORTANT GOS A-VDGS SYSTEM FUNCTIONALITY
1. The flightID provided by FIS makes a flight unique for the GOS system. Therefore,
updates to a flight must have the same flightID otherwise it is treated as a new
flight. It is FIS responsibility to make sure the ID provided is unique for each flight.
2. GOS uses the supplied BTAD time internally to decide when it is time to initiate a
docking. Therefore it is important the time as accurate as possible (+-10 min) and
any updates at FIS are reflected to GOS.
3. No Blocks On/Off messages are delivered to FIS if corresponding
arrival/departure information was missing. Prior to docking.
Page 4 of 14
3. ESTABLISHING A CONNECTION AND RECOVERY

3.1 LINK INITIALISATION
The GOS system acts as a TCP client and the FIS system acts as a TCP server.
The server shall use a static IP address, which will be known by the client system.
Upon initial connection the client tries to connect to the server. When the connection
is established, the server starts sending keep-alive messages to the client to maintain
the connection.
3.2 LINK FAILURE AND RECOVERY
In case of a link failure or the lack of keep-alive messages from the server, the client
immediately disconnects and tries to establish a new connection.
The reason for a link failure can be a LAN failure or a computer breakdown in any of
the systems.
If at any time the link fails, the client keeps on trying to re-establish the connection to
the server.
4. APPLICATION PROTOCOL
4.1 GENERAL
The application protocol used for data exchange between the server and its clients
conforms to the XML standard. A header precedes each XML data block with
information about the size of the XML block.
4.2 MESSAGE HEADER
The header has the following format:
Header Field name Data Description
Byte type/Value
1 Start identifier # Identifies start of record
2-5 Data size Numeric The length of the following XML data
block
Note: The ‘Data size’ field shall always be left adjusted and ‘space’ padded to its full
field size.
4.3 MESSAGE DATA

4.3.1 General
The following table is an overview of a sample message structure.
Note: Every XML data block is preceded with a message header described above.
A sample message structure

<?xml version =”1.0” encoding=”UTF-8”?>

<GOS_Data xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”>
<[Message Type] version=[value] msgId=[value]>
……
……
</[Message Type]>
</GOS_Data>
Page 5 of 14
Detailed element description

GOS_Data Root node of the message – common to all messages
[Message Type] Any message type and its data are populated in this node.
Available message types are described below.
version Defines the version of the message type
msgId A unique message ID created by the sender of a message. The
message ID will be included in a reply message
(acknowledgement) sent by the receiver. It can be used by the
sender to identify the result of an operation (if message arrived
or not).
General data type description

Date/Time All date/time elements used through the document are in UTC
elements and according to XML standard date/time format: YYYY-MM-
DDTHH:MM:SS
Example 2006-10-31T08:15:00
Empty data Data elements containing empty values will be inserted into the
elements database as an empty string (where an empty string is allowed).
When it’s desired to clear a previous time value in a ‘dateTime’

field, the ‘xsi:nil’ attribute shall be set to true.
Database fields marked as NULL will not be included in XML

messages delivered to a sub system.
Example where regNo is cleared <regNo></regNo>

Example where etad is cleared <etad xsi:nil=true></etad>
Left out data For data elements being left out in an XML message,
elements corresponding database records will be unaffected upon
update/insert.
Page 6 of 14
4.3.2 Available Message Types

Common message types used in various XML message are defined in this section.
Message Types Description

KeepAlive Reported at regular intervals by the IP server to a
client to announce its presence. The message will
include a value, in seconds, indicating the
minimum time a client shall wait for keep-alive to
arrive before reconnecting to the server.
Message_Ack Common Acknowledgement message sent as a

reply to a previous operation.
Example:
GOS client sends a flight to server and server
acknowledges received message.
GOS sends Blocks On/Off message to FIS and
FIS acknowledges received message.
FIS_Flight_Ex Sent from FIS to GOS when a flight shall be stored

in the database.
FIS_StandUpdate Sent from FIS when the stand needs to be

updated for a flight.
FIS_AircraftUpdate Sent from FIS when the aircraft type needs to be

updated for a flight.
FIS_AircraftRegNoUpdate Sent from FIS when the aircraft registration

number needs to be updated for a flight.
FIS_TimeUpdate Sent from FIS when the estimated or actual time of

arrival/departure needs to be updated for a flight.
FIS_FlightOperation Sent from FIS when a flight needs to be

cancelled/deleted/diverted etc.
GOS_BlockTimeFlight_Ex Flight movement Blocks On/Off record reported

from GOS to FIS after Park On/Off of an aircraft
to/from a stand. This Blocks record is based on
flight information earlier received from FIS.
GOS_BlockTimeGround Ground movement Blocks On/Off record reported

from GOS to FIS after park On/Off of an aircraft
to/from a stand. This record is reported when no
corresponding arrival/departure flight is available.
Page 7 of 14
4.3.3 Available Data Elements with Attributes

Common data elements used in various XML message are defined in this section.
Element name Description

acType Aircraft type (ICAO or IATA codes used)
arrDep Arrival/departure indicator (mandatory when inserting a new
flight).
A – Arrival
D – Departure
atad Actual time of arrival or departure Format is according to XML
standard
blockTime Time the aircraft arrived or departed at the gate. Only valid for
status 1 or 2. Format is according to XML standard.
codeShareFlightN List of code share flight numbers belonging to a main flight sent
umbers to GOS. This information can be displayed on DGS prior to
docking.
errorCode Common error code used in various messages. The meaning
of each individual code is described in the example section for
respective message.
errorText Common error text.
etad Estimated time of arrival or departure. Format is according to
XML standard. This time is used to by GOS to schedule the
flight to Safedock.
flightID Forms a unique index to identify a flight in the system. A FIS
system shall insert data into this field that uniquely identifies the
flight.
flightNo Flight number as originally supplied by FIS or manually created
by a GOS client.
flightstatus Informs about the status for a flight. The following values are
valid:
A – Active flight (active in system)
C – Cancelled flight ((ignored by system until set back to Active
state – flightStatus=A).
D – Deleted flight (flight marked as D in DB will never be
reported to a client).
H – Hidden flight (for internal use, flight marked as H in DB will
never be reported to a client).
N – Non operational/Delayed (ignored by system until set back
to Active state – flightStatus=A).
ipAddress Common IP Address variable
ipPort Common IP port number variable
lastRecord Common type used to determine if last record has been
received in a series of record. Ex. A data block is too big to fit
within a single XML block, and therefore must be divided into
several blocks before being sent to a client.
miscellaneousInfo Miscellaneous data fields that can be used by an external
system to store valuable information normally not part of
standard GOS data.
Example: FIS sends a flight to GOS and stores a record
counter in the MISC1 field. This value will be reported back to
FIS upon Blocks On. See message examples for data format.
Page 8 of 14
Element name Description

parkedInfo Informs when a flight arrived at the gate or departed from the
gate (created by GOS).
ports List of ports a flight will visit on its way to the final destination.
This information can be displayed on DGS prior to docking.
processflag Internal flag: Informs if a flight is still in use or not by the
system. A processed flight will be ignored by the GOS system
in terms of flight scheduling.
For instance; as long as an arrival flight has not yet been
parked at the gate the flight will be marked as non processed.
Upon Park On at the gate the flight will be market as
processed. The same goes for Park Off (set to processed).
N or empty value – not processed
Y – processed
(A processed flight can be reinstated by setting the process flag
to N)
regNo Aircraft registration number
remark Can be populated by FIS for information purposes.
reply Common variable used to inform if a record is sent as a reply to
a previous request or if it’s a spontaneous record due to an
update for example. The following values exists:
Y – it’s a reply to a previous query
N – it’s a spontaneous record due to a possible update
stad Scheduled time of arrival or departure. Format is according to
XML standard. This time is used by GOS to create a unique
identifier for the flight, STAD is not used for scheduling the
flight to Safedock.
stand Assigned stand for flight
station IATA code of the airport
status 0 - not yet parked, 1 - parked, 2 - parked off
statusCode Common status code field. The meaning of each individual
code is described in the example section for respective
message.
statusText Common status text field
towIn (attribute) Tow-in operation or not (by default all dockings are non tow-in
docking)
0 – normal docking (non tow-in)
1 – tow-in docking (A/C moved to stand by tractor)
type Common type field used in various messages to specify type of
operation/type of message.
versionCounter Common version counter. As the name implies this value
keeps track of the current version of the data. As soon as data
is modified in the system, this counter will be updated (handled
by server).
Page 9 of 14
5. DETAILED MESSAGE DESCRIPTION AND EXAMPLES

5.1 GENERAL
This section contains sample messages. These messages are used as a general
guidance. They do not form part of the formal specification, since the message
structures are defined by the XML Schemas (XSDs).
5.2 KEEP ALIVE FROM IP SERVER
An example which shows how the IP server sends a keep-alive message to the client,
the frequency of this message will be configurable.
<GOS_Data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<KeepAlive version=”1.0” msgId=”0”>
<timeout>60</timeout>
</KeepAlive>
</GOS_Data>
Detailed element description

KeepAlive 60 – Value, in seconds, indicating the minimum time a client
shall wait for keep-alive to arrive before reconnecting to the
server.
5.3 ACKNOWLEDGEMENT MESSAGE

An example which shows an acknowledgement message sent as an answer to a
previously received record.
Note: All messages may not require ACK. When an ACK is required, it is specified in
the message example/description for respective message.
<Message_Ack version=”1.0” msgId=”25”></Message_Ack>
</GOS_Data>
The ‘msgId’ is to be as originally supplied in the record, which generated the

acknowledgement.
Page 10 of 14
5.4 BASIC FLIGHT FROM FIS

An example which shows a flight record sent from a client to the server for storage
into the database.
Note: Used for both Insert and Update. Individual updates of items such as Aircraft
type, Stand number and Time are described later in this document.
<FIS_Flight_Ex version=”1.0” msgId=”25”>
<station>MIA</station>
<flightID>12345</flightID>
<flightNo>SK 445</flightNo>
GOS_BlockTimeGround: <station>MIA</station>
<arrDep>A</arrDep>
<stand>15</stand>
<etad>2006-09-11T09:00:00</etad>
<atad>2006-09-11T09:00:00</atad>
<regNo>REG123</regNo>
<acType towIn=”0”>A320</acType>
<remark>Delayed 15 minutes</remark>
<codeShareFlightNumbers>
<f>SK456</f>
<f>LH234</f>
<f>TK345</f>
</codeShareFlightNumbers>
<ports>
LAX
MIA
DEN
</ports>
</FIS_Flight_Ex>
</GOS_Data>
1. When an update is made to an existing flight the ‘flightID’ element is to be as

originally supplied. Therefore, any updates to this element are treated as a new
flight.
2. The server responds with an acknowledgement to this operation.
3. Code share flight numbers are to be provided if it is desired to display such
information on A-VDGS prior to docking.
4. Port information can be provided if it is desired to display such information on A-
VDGS prior to docking.
Page 11 of 14
5.5 CANCELLATION/DELETION/DIVERSION OF A FLIGHT FROM FIS

A cancellation/delete/diversion or reactivation of cancelled/diverted flight is similar to
an update operation. The value of the ‘flightStatus’ field determines the type of
operation performed.
The following examples outline how to perform the various operations.
1. The ‘flightID’ element identifies the flight.
2. The server responds with an acknowledgement to this operation.
Cancellation of flight:
<FIS_FlightOperation version=”1.0” msgId=”25”>
<flightStatus>C</flightStatus>
</FIS_FlightOperation>
</GOS_Data>
Diversion of flight:
<flightStatus>N</flightStatus>
</GOS_Data>
Removal of flight:
<flightStatus>D</flightStatus>
</GOS_Data>
Note: A cancelled or diverted flight can be brought back into operation by setting the
flight status to Active (flightStatus=A).
Page 12 of 14
5.6 STAND UPDATE FROM FIS

The following message can be sent to GOS when it is desired to update the stand for
a flight. GOS responds with an acknowledgement to this operation.
<FIS_StandUpdate version="1.1" msgId="25">

<stand>A35</stand>
</FIS_StandUpdate>
</GOS_Data>
5.7 AIRCRAFT UPDATE FROM FIS

The following message can be sent to GOS when it is desired to update the aircraft
type for a flight. GOS responds with an acknowledgement to this operation.
<FIS_AircraftUpdate version="1.1" msgId="25">
<acType towIn="0">A320</acType>
</FIS_AircraftUpdate>
</GOS_Data>
5.8 AIRCRAFT REGISTRATION NUMBER UPDATE FROM FIS

The following message can be sent to GOS when it is desired to update the aircraft
registration number for a flight. GOS responds with an acknowledgement to this
operation.
<FIS_AircraftRegNoUpdate version="1.1" msgId="25">
</FIS_ AircraftRegNoUpdate >
</GOS_Data>
5.9 TIME UPDATE FROM FIS

The following message can be sent to GOS when it is desired to update the
arrival/departure time for a flight. GOS responds with an acknowledgement to this
operation.
<FIS_TimeUpdate version="1.1" msgId="25">

<timeType>ETAD</timeType>
<time>2007-11-15T11:35:00</time>
</FIS_TimeUpdate>
</GOS_Data>
Page 13 of 14
5.10 BLOCKS ON/OFF FROM GOS

The following example shows a flight movement blocks on/off record sent from GOS
to FIS. Supplied flight information is as originally supplied by FIS.
<GOS_BlockTimeFlight_Ex version=”1.0” msgId=”25”>
<flightNo>SK 445</flightNo>
<arrDep>A</arrDep>
<stand>15</stand>
<regNo<REG123</regNo>
<acType>A320</acType>
<blockTime>2006-09-11T08:56:23</blockTime>
</GOS_BlockTimeFlight_Ex>
</GOS_Data>
The following example shows a ground movement blocks on/off record sent from
GOS to FIS.
<GOS_BlockTimeGround version=”1.0” msgId=”25”>
<arrDep>A</arrDep>
<stand>15</stand>
<acType>A320</acType>
<blockTime>2006-09-11T08:56:23</blockTime>
</GOS_BlockTimeGround>
</GOS_Data>
Note: FIS responds with an acknowledgement to these operations, where the ‘msgId’
is to be as originally supplied by GOS.
Page 14 of 14
Document: 4_GOS_MAINTENANCE Version: 1.3
CHAPTER 4
MAINTENANCE
CONTENTS
1. INTRODUCTION ........................................................................................................... 2
1.1 SCOPE .............................................................................................................. 2
1.2 MAINTENANCE ON THE ETHERNET LAN ..................................................... 2
1.3 GENERAL PRECAUTIONS .............................................................................. 2
2. CORRECTIVE MAINTENENACE ................................................................................. 3
2.1 FAULT FINDING AND RECTIFICATION ......................................................... 3
2.2 REPLACEMENT OF MALFUNCTIONING UNITS............................................ 3
2.3 SOFTWARE INSTALLATION ........................................................................... 3
3. PREVENTIVE MAINTENANCE .................................................................................... 3
4. FAULT FINDING GUIDE ............................................................................................... 3
4.1 COMM ERROR ON ALL STANDS ................................................................... 3
4.1.1 Step-by-step troubleshooting ................................................................... 3
4.2 COMM ERROR ON A SINGLE DGS - LAN CONNECTION ............................ 4
4.2.1 Step-by-step troubleshooting ................................................................... 4
4.3 COMM ERROR ON A SINGLE DGS – CURRENT LOOP MODEM ................ 4
4.3.1 General ........................................................................................................ 4
4.3.2 Step by step trouble shooting .................................................................. 4
4.4 HARD DISK/OPERATING SYSTEM FAILURE ................................................ 5
4.5 NTP CONNECTION ERROR............................................................................ 5
4.6 GOS HMI FAILS TO START............................................................................. 5
4.6.1 Step by step troubleshooting ................................................................... 5
Page 1 of 6
1. INTRODUCTION
1.1 SCOPE
This document is a maintenance description of a central Docking Control System,
called Gate Operating System (GOS). The system topology is described in the
System Description Appendix A and includes both GOS servers and workstations with
connections to external systems via an Ethernet LAN.
This description includes:
• Corrective Maintenance
• Preventive Maintenance
• A Fault Finding Guide
1.2 MAINTENANCE ON THE ETHERNET LAN
An Ethernet LAN is used to communicate with Docking Systems and external
computer systems. For more information, see the Safedock Manual Installation
Appendix C Communication.
1.3 GENERAL PRECAUTIONS
The GOS system is built with a standard type of PC computers, which require
minimum maintenance.
Before commencing any maintenance activity, the following precautions must be
considered:
CAUTION: PROTECTION AGAINST ELECTROSTATIC DISCHARGE
The transfer of static electricity causes ESD damage when electronic components are
handled. It is essential to protect components from electrostatic discharge to avoid
damage and extra costs incurred for service and production.
The following is recommended:
• All ESD- sensitive materials must be stored in ESD- safe area.
• All ESD- sensitive components must be stored in protective packages.
• Apply a conductive band around your wrist and connect it to ground before
touching any electronic component.
WARNING! ISOLATE THE POWER SUPPLY PRIOR TO UNDERTAKING ANY
MAINTENANCE ACTIVITY.
Page 2 of 6
2. CORRECTIVE MAINTENENACE
2.1 FAULT FINDING AND RECTIFICATION
The Docking Guidance Central Computer (GOS) does not execute any run time
diagnostic tests. System operation is monitored from GOS workstations, and a failure
on the Server or LAN is reported as a COMM Error of the Docking System. Possible
causes of other errors and recommended actions to be taken are presented in the
Fault Finding section.
2.2 REPLACEMENT OF MALFUNCTIONING UNITS
GOS is built using conventional rack mounted PC computers with a back plane and
plug-in electronic boards.
It is presumed that replacement of electronic boards in GOS system PCs is
elementary maintenance work and therefore is not described in this manual.
For more information, see PC manufacturer documentation or website.
2.3 SOFTWARE INSTALLATION
Procedures for GOS software installation, reinstalling or upgrading software are
described in the Installation chapter.
3. PREVENTIVE MAINTENANCE
The GOS system is built with a standard type of PC computers, which require minimal
preventive maintenance.
Database housekeeping is carried out automatically.
The following parameters should be checked three times per year:
• Check Memory Usage by the Windows XP/2003 Task Manager.
• Check available hard disk space. More than 1GB is always to be available.
If any anomalies are found, the system is to be restarted and old log files deleted.
4. FAULT FINDING GUIDE
4.1 COMM ERROR ON ALL STANDS
If the system shows a communication error with all docking systems, the problem
most probably resides on the GOS Server, which is handling the communication.
Another possible cause may be there is no longer a workstation connection to the
GOS Server.
4.1.1 Step-by-step troubleshooting
(a) Make sure the PC is running.
(b) Check the network according to the Safedock Manual Installation Appendix C.
(c) Check network cable(s) and network adapter board(s).
(d) Send a PING test to any available PCs in the network. If the ping returns, the
hardware is working correctly.
(e) Check the service Goskrnl.
(f) Stop the service Goskrnl, and restart Goskrnl.exe from Windows Explorer. If
communication is established with Safedock units, it is an indication that service
settings are incorrect. Stop Goskrnl.exe, and reinstall the service Goskrnl.
For more information, see the INSTALLATION chapter.
Page 3 of 6
4.2 COMM ERROR ON A SINGLE DGS - LAN CONNECTION

When GOS is connected to a Safedock, GOS polls Safedock for its current status
continuously. Therefore, if Safedock does not receive any questions from GOS,
Safedock never responds.
4.2.1 Step-by-step troubleshooting
(a) Confirm (at the apron) that the Safedock is running.
(b) Check the Ethernet Converter in the Safedock:
Find the IP Address for the converter in the GOS.INI file.
Remove the converter from the Safedock and connect it to a GOS Maintenance
PC with a crossover cable.
Perform a PING test to the converter. If the converter replies, it is OK. This test
also verifies the functionality of the PC.
If the PC and converter are OK, the problem may reside in the network cable
between PC and the Safedock.
(c) Check the Network according to the Safedock Manual Installation Appendix C.
(d) Check Motherboard/configuration and cables in the Safedock:
The mother board is equipped with LEDs (D2-D10) for monitoring communication,
two of these LEDs are for GOS communication.
Check transmit and receive LEDs are blinking.
If these LEDs are not blinking, it may indicate a motherboard is at fault or there is
a cable fault between the motherboard and the converter.
If the receive LED only is blinking, it indicates that Safedock receives signals but
does not recognise them. This is a typical scenario when the CPU is replaced and
the Stand is configured with an incorrect COM ID.
4.3 COMM ERROR ON A SINGLE DGS – CURRENT LOOP MODEM
4.3.1 General
When GOS is connected to a Safedock system, GOS polls Safedock units for current
status continuously. However, if a Safedock does not receive any questions from
GOS, a Safedock never responds. Due to this situation, troubleshooting should
always start from GOS working towards Safedock units and finally back to GOS
again.
4.3.2 Step by step trouble shooting
There are LEDs on the modem monitoring DCD (data carrier detect), Transmit and
Receive signals.
(a) From GOS, start by checking if the Transmit LED is blinking. If it is, GOS is
sending data to the modem. If the LED is not blinking, the problem may reside
between the PC and the modem.
(b) Check the patch cable and the cable between the PC and the concentrator.
(c) Run a LOOP BACK test between the PC and the concentrator.
Note: A loop back plug is required.
(d) Run a LOOP BACK test between the PC and modem.
If there are not any apparent problems this far, it can almost certainly be assumed
that communication between the PC and Modem is OK. The next step is to verify
how far the transmit signal is sent.
(e) Check the DCD LED. If it is lit on the GOS side and on the Safedock side, it is a
good indication that the communication line between the two modems is OK.
(f) From Safedock, check the receiver LED. If it does not blink, the problem may be
the modem or the line. Start by replacing the modem. If there is still no blinking,
the communication line may be at fault. When measuring a communication line, it
is preferred to measure the resistance on the line (temporarily join the two wires at
the remote end to make a loop, for example resistance should not be more than
400 ohms depending on length of line).
Page 4 of 6
(g) The mother board is also equipped with LEDs (D2-D10). Two of these LEDs are
for GOS-A-VDGS communication.
Check the transmit and receive LEDs are blinking. If not, the motherboard may be
at fault or the cable between the motherboard and modem fails. If the receiver
LED only is blinking, Safedock receives signals but does not recognise them. This
is a typical scenario when the CPU is replaced and the stand is configured with an
incorrect COM ID.
If the receive and transmit LEDs are blinking on the motherboard, continue to
check the transmit LED on the modem. If it is blinking, measure the resistance on
the transmit line.
4.4 HARD DISK/OPERATING SYSTEM FAILURE
If a PC fails to start up or suddenly goes down, it is an indication that the hard drive or
the operating system is corrupted.
(a) PC goes down and fails to restart.
(b) Replace the hard disk, and reinstall the operating system according to the
installation manual.
(c) If it can be verified that the hard disk is OK, reinstall only the operating system.
(d) Reinstall GOS application software.
4.5 NTP CONNECTION ERROR
If the computer is unable to synchronize its time with the NTP server or master clock,
a system message is sent to the Windows system log.
Note: If two synchronization sources are used there are two messages in the log.
(a) Verify the network connection to the master clock.
(b) Run a PING test to the NTP server. If ping gets through, hardware is OK.
(c) Verify that the master clock is functioning correctly.
(d) Verify this by checking the functionality of another system, which uses the same
synchronization software and source/master clock for synchronisation.
(e) Reconfigure the time service according to the installation manual.
4.6 GOS HMI FAILS TO START
For the GOS HMI to run, it requires the program GOS kernel (GOSkrnl) to run.
If GOS HMI is started, and the airport layout is displayed on screen only for a short
period of time, it is an indication that Goskrnl.exe is not running.
4.6.1 Step by step troubleshooting
(a) Check the service Goskrnl.
(b) Stop the Goskrnl, and restart Goskrnl.exe from Windows Explorer. If GOS HMI
starts up, it is an indication that the service settings are incorrect for autostart.
(c) Stop Goskrnl.exe and reinstall the Service.
Page 5 of 6
Page 6 of 6
Document: 4A_GOS_MA_FaultFindGuide Version: 1.3
MAINTENANCE: APPENDIX A
GOS
FAULT FINDING GUIDE
1. GOS SERVER
Symptom Possible Cause Action to Rectify
1.1 COMM ERROR, ALL CONCENTRATORS

‘Comm error’ on all Safedock Concentrators not running. Start the concentrators.
A-VDGS units.
Network connection failed. Check network connection
cable, network, network
adapter board.
1.2 COMM ERROR, CONCENTRATOR
‘Comm error’ on all Safedock Concentrator not running. Start the concentrator.
A-VDGS units connected to the
concentrator.
Concentrator not accessible See GOS Concentrator.
through network.
1.3 COMM ERROR, SAFEDOCK A-VDGS
‘Comm error’ on a single See GOS Concentrator. See GOS Concentrator.
Safedock A-VDGS unit.
1.4 AODB CONNECTION ERROR
Entry in GOS log file: GOS unable to access network. Check network connection
HKSFD – OraGos-Stand cable, network, network
Logon/connect- ORA-12154: adapter board.
TNS:could not resolve GOS
Entry in GOS log file: GOS unable to connect to Check AODB servers.
HKSFD – OraGos - AODB server.
TFG/connect to AODB_P_1,
AODB_P_2,
AODB_S_1, AODB_S_2.
1.5 SAFEDOCK A-VDGS ERROR

‘Error nn’ reported at stand. Safedock A-VDGS unit error See fault finding, Safedock A-
VDGS.
Entry in NT Event Viewer NTP client is unable to connect Check network connection
Application Log: to NTP server. cable, network, network
NTP Could not connect adapter board.
1.7 HARD DISK FAILURE

Entry in NT Event Viewer Hard disk failure. Replace the hard disk.
System Log:
Bad sectors ‘diskName’.
Page 1 of 4
2. GOS CONCENTRATOR
2.1 COMM ERROR, SERVER

Comm error on all Safedock A- Concentrator not accessible Check network connection
VDGS units not connected to through the network. cable, network, network
this concentrator. adapter board.
Comm error on a single Safedock A-VDGS unit not Activate Safedock A-VDGS
Safedock A-VDGS unit. running. unit.
Safedock A-VDGS unit modem Check/replace Safedock A-
failure. VDGS unit modem.
Communication line error. Check/Repair communication
line.
Serial port (Rocket port) Perform serial port loop back
connector board failure. test according to Rocket port
documentation. Replace serial
port connector board.
Serial port (Rocket port) board Replace serial port board.
failure.
VDGS.

System Log:
Page 2 of 4
3. GOS WORKSTATION (ACC)
3.1 COMM ERROR, SERVER

Comm error on all Safedock A- Workstation not accessible Check network connection
VDGS units. through the network. cable, network, network
adapter board.
‘Comm error’ on a single See GOS Concentrator. See GOS Concentrator.
Safedock A-VDGS unit.
VDGS.

System Log:
3.6 SFDUPD CONNECTION ERROR
Error message at start of Workstation unable to connect Check network connection
SFDUPD program: to database at GOS server. cable, network, network
TNS: Unable to connect to adapter board.
destination Alias: GOS.
Page 3 of 4
Page 4 of 4
Drawings Date: August 2010
Document: 5_GOS_DRAWINGS Version: 1.3
CHAPTER 5
DRAWINGS (OPTION)
CONTENTS
This chapter contains drawings and parts lists, as an option if available or requested.
Note: If the Drawing Number column is empty, drawings and parts lists are not available or have not
been requested.
Drawing Title Drawing Number

GOS System Layout
GOS Server and Communication Hub

Product Configuration File
Component Placement and Assembly
Internal Connection Diagram
External Connection Diagram
GOS Workstation
Page 1 of 2
Drawings Date: August 2010
Document: 5_GOS_DRAWINGS Version: 1.3
Page 2 of 2
Check in to the future
How many aircraft can your controlling not only ground To a larger extent than today’s
airport handle today? movements but also air traffic systems, A-SMGCS will rely on
Can this number be increased close to the airport is of the automated processes to give both
without adverse effects on the highest interest. pilots and traffic controllers exact
airport’s safety level? The International Civil Aviation information about positions and
It is a known fact that traffic Organization (ICAO) already directions. Safegate Group
volume will rise in the foreseeable describes A-SMGCS, Advanced delivers complete A-SMGCS
future. More movements will Surface Movement Guidance and solutions already, as well as all
demand monitoring of the entire Control System, as the answer to vital parts relating to it.
airport. Requirements will be the future modern airport need to Safegate Group can check your
sharpened and the development control the entire airport space in airport into the future
of an integrated system one superior system. – today!
Singapore
singapore@safegate.com
+65 6289 6893
Safegate Group HQ Australia Finland India Spain

Djurhagegatan 19 australia@safegate.com finland@safegate.com india@safegate.com spain@safegate.com
SE-213 76 Malmö, Sweden +61 (0)3 9720-3233 +358 (0)20754 7700 +34 917 157 598
Phone: +46 (0)40 699 17 00
Fax: +46 (0)40 699 17 30 China France Qatar UK
E-mail: market@safegate.com china@safegate.com france@safegate.com qatar@safegate.com uk@safegate.com
+8610-85275297 +33 (0)1 49 53 62 62 +974 436 9628 +44 (0)20 8594 2747
Dubai Germany Russia USA

dubai@safegate.com germany@safegate.com russia@safegate.com usa@safegate.com
+971 4 332 30 07 +49 (0)231 9776754 +7 495 917 4614 +1 763 535 92 99
Safegate Group offers solutions for increased safety, efficiency and environmental benefits to airports around the world. The company was founded in 1973
and has its headquarters in Malmö, Sweden. Safegate Group has over 70 partners around the globe in order to be close to its customers. The latest members
of Safegate Group, Thorn AFL and Idman, have both over 40 years of experience in airfield lighting solutions for airports and heliports worldwide. Safegate
Group´s complete range of products and services, a “one-stop shop”, provides solutions to customers and airborne travellers around the globe.
For more contact information and details:
www.safegate.com

GOS

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

GOS

Diunggah oleh

Hak Cipta:

Format Tersedia

Gate Operating System (GOS)

GATE OPERATING SYSTEM (GOS)

CHAPTER 1. SYSTEM DESCRIPTION

Appendix A. System Topology

Appendix B. Redundant GOS Server

Appendix C. Camera Integration

Appendix D. Interface (Options)

Appendix A. System Configuration

Appendix B. Interface (Options)

Appendix A. GOS Features (Options)

Appendix B. GOS Access Manager

Appendix C. GOS Reporter

Appendix D. ICD Example FIS (Option)

Appendix A. GOS Fault Finding Guide

CHAPTER 5. DRAWINGS (Option, if available)

Product Options Configuration Summary

File Name Description

Chapter 1 – System Description

2. USING A CENTRAL DOCKING & GUIDANCE SYSTEM

Functions at Arrivals Realisation

Functions at Departures Realisation

Note: * Depending on site configuration or options.

Common Data Network/Ethernet LAN

Patch cables to horizontal

SDK SDK SDK SDK

External Systems, option

CMS Central Maintenance System (CMS)

NTP NTP Time Server (if available)

FIGURE 1 - GOS SYSTEM TOPOLOGY

3.3 CONFIGURATION OF SOFTWARE

3.3.2 Gos Software Module Architecture/Description (Options)

(g) SAFEDOCK.DLL , SD_UDP.DLL, SD_TCPID.DLL and COMLIDGS.DLL

FIGURE 2 - SOFTWARE CONFIGURATION

4.3 GOS EVENT LOG FILES

5. ENHANCED FEATURES (OPTIONS)

1.1 GOS SYSTEM TOPOLOGY (AN EXAMPLE)

Ethernet LAN, 10BaseT connections

Patch cables to horizontal

10BaseT / Cross-over cable (1)

Patch cable per modem (15)

SAFEDOCK LAN Connections

FIGURE 1 - GOS SYSTEM TOPOLOGY

1.2 GOS HARDWARE SUB-UNITS (AN EXAMPLE)

1.2.2 GOS Server Hardware Items example

Part No Qty Equipment Supplier

N/A 1 32 MB ATI Rage Ultra video card Dell

N/A 1 Monitor: E771-17” Dell

SW621A-R2 1 Serv Switch (for Monitor, keyboard and Black Box

1.2.3 GOS Concentrator Items (used if non- LAN configuration)

Part No Qty Equipment Supplier

SAFE4603 0 Floor Cabinet Rittal

1.2.4 GOS Workstation Hardware Items

Part No Qty Equipment Supplier

N/A 2 32 MB ATI Rage Ultra video card Dell

Note: A patch cable, 10BaseT/RJ-45 connectors, will be needed (length to be

SYSTEM DESCRIPTION: APPENDIX B

Computer A Start Computer B

do/ Exchange Status do/ Exchange Status

Yield Swap Yield Swap

do/ Exchange Status do/ Exchange Status

FIGURE 1 - GATEWAY STATES

The figure below is a detailed state diagram of computer A or B.

do/ Deactivate Gateway (Links)

Main found[ First time ]