UM_XDN-ES010006101UM06_A.doc

7/29/2019 UM_XDN-ES010006101UM06_A.doc

1/49

ATMAS Division UNCLASSIFIED ES010006101UM06E184

Issue A

Date: 27/03/2003

ROMANIA PROJECT

XDN CSCI

SOFTWARE USER MANUAL

CDRL No. :

ISSUED BY :

Alenia Marconi Systems S.p.A.Via Tiburtina Km 12.400 - Roma

ITALY

The copyright in this document is the property ofAlenia

Marconi Systems S.p.A.The document is supplied on theexpress understanding that it is to be treated as confidential

and that it may not be copied, used or disclosed to others in

whole or in part for any purpose except as authorized in

writing byAlenia Marconi Systems S.p.A .

This document contains a total of 50 pages

UNCLASSIFIED Page

1

TEMP-UK (ATC-Km 12.400) rev 6

7/29/2019 UM_XDN-ES010006101UM06_A.doc

2/49


Issue A

Date: 27/03/2003

DOCUMENT SECURITY CLASSIFICATION:

This document is intended for the use of the recipient only, and for communication to such persons as may

be required to be acquainted with its contents in the course of their duties.

The recipient, and any other person to whom the recipient has communicated the contents of this document,

shall treat this document in accordance with the requirements of Alenia document Security Instructions,

15 February 1992.

Any person others the authorised holder upon obtaining possession of this document, by finding or

otherwise, should forward it by registered post, together with his name and address, in a sealed envelope to:

Ufficio Sicurezza

Alenia Marconi systems S.p.A.

Via Tiburtina 12.400

00131 Roma

ITALY

Any questions arising from this document should be addressed to:

Simonetta Di Domenico

Alenia Marconi Systems S.p.A.

Air Traffic Management & Airport Systems DivisionVia Tiburtina, Km 12.400 - 00131 Roma

ITALY

Telephone +39-06 4150-2612

Fax +39-06 4131133 / 4131436 / 4131091

UNCLASSIFIED Page

2

7/29/2019 UM_XDN-ES010006101UM06_A.doc

3/49


Issue A

Date: 27/03/2003

Issue Authority

Prepared by : ......................................................

(Simonetta Di Domenico)

Date:

Approved by:

(Project Leader)......................................................

(Antonio Mattogno)

Date:

Checked by:

(QA Responsible)

......................................................

(Sergio Pignotti)Date:

Authorised by:

(Project Manager)

......................................................

(Sergio Arceri)Date:

UNCLASSIFIED Page

3

7/29/2019 UM_XDN-ES010006101UM06_A.doc

4/49


Issue A

Date: 27/03/2003

REVISIONS RECORD SHEET

This sheet is a record of revisions to this document.

Issue/AL Date Revised Pages Document Change Note

(DCN)

A 27/03/2003 First Issue

UNCLASSIFIED Page

4

7/29/2019 UM_XDN-ES010006101UM06_A.doc

5/49


Issue A

Date: 27/03/2003

TABLE OF CONTENTS

1. SCOPE.......................................................................................................................................................................6

1.1 IDENTIFICATION................................................................................................................................................6

1.2 CSCI OVERVIEW.............................................................................................................................................6

1.3 DOCUMENTOVERVIEW.......................................................................................................................................7

2. REFERENCED DOCUMENTS..............................................................................................................................8

3. GLOSSARY..............................................................................................................................................................9

4. INTERFACES DESCRIPTION......................................................................................................................... ...10

4.1 INTERFACES TOWARDSTHESYSTEMCOMPONENTS...................................................................................................10

4.2 INTERFACES TOWARDSTHESYSTEM OPERATORS..............................................................................................12

5. ORDERS..................................................................................................................................................................13

6. ORDERS LIST........................................................................................................................................................28

7. DIAGNOSTICS......................................................................................................................................................29

7.1 OVERVIEW..............................................................................................................................................29

8. ERRORS..................................................................................................................................................................37

8.1 OVERVIEW..............................................................................................................................................37

9. FAULT TOLERANCE..........................................................................................................................................39

10. START-UP DESCRIPTION................................................................................................................................40

11. FUNCTION CONFIGURATION.......................................................................................................................41

12. APPENDIX A..................................................................................................................................................... ...42

UNCLASSIFIED Page

5

7/29/2019 UM_XDN-ES010006101UM06_A.doc

6/49


Issue A

Date: 27/03/2003

1. SCOPE

1.1 IDENTIFICATION.

The Software User Manual of XDN CSCI.

Approved identification number:E000XDN0-01SUM

Document title:

Software User Manual for the XDN CSCI of SATCAS: System and CSCI abbreviations: SATCAS: ALENIA Air Traffic Control Automatic System

Radin: Radar Interface XDN: Radar Interface CSCI for Open targets

1.2 CSCI OVERVIEW.

Radin Function is a part of SATCAS and is allocated on the Radar Front End node (RFE Alpha

computer) of a SATCAS Operative Site (OPS).

The purpose of XDN CSCI is to receive the radar data sent by several Radar Head Processors (RHPs),

generally allocated on remote radar sites, convert them from Asterix to one of the Alenia Marconi Systems

(AMS) standard formats (e.g. Ale_std_95), if it is foreseen by the site configuration, and finally send them

on LAN.

The kind of messages XDN can process are the following:

North;

Sectors;

Mono-radar targets (Plots and Tracks);

Weather Maps.

The main goals achieved by Radar Interface are:

Translation of received radar data from Asterix to AMS formats;

Conversion of received radar data Coordinates and Speed components;

Substitution of the received data HDLC protocol with UDP or IOL one;

Application of Input and Output filters.

UNCLASSIFIED Page

6

7/29/2019 UM_XDN-ES010006101UM06_A.doc

7/49


Issue A

Date: 27/03/2003

1.3 DOCUMENT OVERVIEW.

This Software User Manual describes all orders accepted by the XDN CSCI, providing, where necessary,

useful examples; furthermore it provides a description of all XDN diagnostic messages.

This manual includes the following chapters:

Scope:introduces this document and the XDN CSCI

Referenced Documents:

lists the documents and reference material used to develop this manual

Glossary:

lists the abbreviations, acronyms and mnemonics used in this manual Interfaces Description:

describes the XDN interfaces to the SATCAS components and to the System operator

Orders:

provides the description of all orders accepted by XDN CSCI

Orders List:

provides the alphabetic list of all orders accepted by XDN CSCI

Diagnostics:

describes all diagnostic messages issued by XDN CSCI, grouped by severity levels

Errors:

describes all fatal exceptions XDN CSCI may raise Fault Tolerance:

describes the fault tolerance features of XDN CSCI

Start-Up Description:

describes the start-up phase of XDN CSCI

UNCLASSIFIED Page

7

7/29/2019 UM_XDN-ES010006101UM06_A.doc

8/49


Issue A

Date: 27/03/2003

2. REFERENCED DOCUMENTS.

The following documents are referred in this Software User Manual:

Software Requirements Specifications Addendum for the XDN CSCI

(E000XDN0-01SRSA01)

UNCLASSIFIED Page

8

7/29/2019 UM_XDN-ES010006101UM06_A.doc

9/49


Issue A

Date: 27/03/2003

3. GLOSSARY

Alpha function

SSR mode and code

radar identifier

AMS Alenia Marconi Systems

ASTERIX All Purpose Structured EUROCONTROL Radar Information Exchange

ATC Air Traffic Control

CMS Control and Monitoring System

CP Central Processor

CSCI Computer Software Configuration Item

DARD Direct Access to Radar Data

DP Display Processorhex. hexadecimal

HDLC High-level Data Link Control

IOL Input Output Lan

LAN Local Area Network

LSB Least Significant Bit

LT Local Track

MRT Multi Radar Tracking

N.M. Nautical Miles

NSV Node SuperVisor

OPS Operative Site

PSR Primary Surveillance Radar

RDP Radar Data Processor

RDS RaDar Site

RHP Radar Head Processor

SATCAS ALENIA Air Traffic Control Automatic System

SMD System Messages Dispatcher

SRS Software Requirements Specification

SSR Secondary Surveillance Radar

SUM Software User Manual

TRH TRacks Handler

UDP User Datagram ProtocolXDN Radar Interface for Open targets

UNCLASSIFIED Page

9

7/29/2019 UM_XDN-ES010006101UM06_A.doc

10/49


Issue A

Date: 27/03/2003

4. INTERFACES DESCRIPTION

This chapter describes Radins interfaces to the Satcas components and the System operator.

4.1 INTERFACES TOWARDS THE SYSTEM COMPONENTS

4.1.1 RFE COMPONENTS

The following components are allocated, together with XDN CSCI, on the RFE node, so their elaboration

is concurrent; they all communicate with XDN through the Operating System primitives.

NSV (Node Supervisor)

This basic CSCI is present on each computer in the System; its main task is to handle the peripheral boards

and the connected hardware devices (e.g. hard disk, partner RFE).

SMD (System Messages Dispatcher)

This basic CSCI is present on each computer in the System; its main task is to dispatch the messages

related to the monitoring (e.g. diagnostics) and control (e.g. orders) of the System.

RFE Hard Disk

The hard disk of RFE is used by XDN to store the configuration parameters of the Function and run-time

modifications of configuration and filtering parameters.

4.1.2 MONO-RADAR DATA PRODUCERS

Live mono-radar data are produced by several RHP Nodes.

TRH (Tracks Handler)

The TRH CSCIs are generally allocated on RHP nodes, in remote sites close to radar antenna (but they

could also be allocated on the RFE itself); they send to XDN the following synthetic radar data through

serial lines:

Plots (untracked targets)

Tracks (LTs)

Antenna north crossings Weather maps

When allocated on RFEs, TRHs and XDN communicate through duplicated serial lines using HDLC

(LAP-B or Datagram) protocol.

UNCLASSIFIED Page

10

7/29/2019 UM_XDN-ES010006101UM06_A.doc

11/49


Issue A

Date: 27/03/2003

The following actions are performed by the XDN CSCI on the received input data:

conversion from Asterix to AMS standard formats;

application of Input Filters (depending on position or SSR code); conversion of data Coordinates and Speed components, in order to refer the output

data to the same System Centre;

application of Output Filters (depending on position);

substitution of HDLC protocol with UDP or IOL one;

sending of data on LANs to their end users.

If the format conversion is not foreseen by the site configuration only the last two activities are performed.

If coordinates and speed conversion is not foreseen by the site configuration the third and fourth activities

are not performed, otherwise the conversion is performed through the use of configuration messages,

received from LAN, sent by MRT or Display Functions.

Filters application is order dependant, it is the operator to decide if the received data have to be filtered or

not.

4.1.3 XDN DATA USERS

The users of XDN data are components allocated on different nodes such as OPS and DP; they all

communicate with XDN through duplicated LANs using Ethernet (UDP level) protocol.

DPs (Display Processors)The DPs are generally allocated on OPS nodes, in the System Center site.

When the System is in DARD mode, DP nodes:

send to XDN the radar configuration messages after receiving from it the

configuration request messages;

Either in DARD or in MRT mode the DP nodes receive and present on graphical monitors the radar data

sent on LAN by XDN CSCI.

MRT (Multi Radar Tracking)

The MRT Function is generally allocated on OPS nodes, in the System Center site.

When the System is in MRT mode, MRT Function:

sends to XDN radar configuration messages after receiving from it the

configuration request messages;

receives and elaborates radar data sent on LAN by XDN CSCI;

sends on System LANs towards the DPs System data obtained from the mono-

radar ones received from XDN.

UNCLASSIFIED Page

11

7/29/2019 UM_XDN-ES010006101UM06_A.doc

12/49


Issue A

Date: 27/03/2003

4.1.4 RFE SLAVE NODE

There is a messages exchange between the two RFE nodes, in order to keep the configuration parameters

aligned.

XDN partner

At the end of the start-up phase the Slave XDN sends the Master one a message asking for parameters

alignment, then the Master XDN sends the alignment message containing all the configuration parameters.

As a result of these activities the two nodes have the same configuration parameters in order to avoid

problems in case of node role change.

During run-time the alignment is kept by allowing orders execution on both nodes, so every parameters

change is notified by SMD Function to both nodes.

4.2 INTERFACES TOWARDS THE SYSTEM OPERATORS

The interfaces to the System operator, where it can address orders to the XDN CSCI (e.g. to modify on-line

XDN parameters, to enable XDN functionalities) and read diagnostic and statistical messages produced by

the XDN CSCI, can be:

any I/O console in the OPS

and/or

a dedicated Monitoring and Control subsystem (CMS) in the OPS, where the

operator can also check, through synoptical drawings, the logical status of XDNCSCI.

In both cases, access control and messages dispatching are performed by SMD CSCI.

4.2.1 XDN ORDER SYNTAX

Every order addressed to the XDN must fit the following syntax pattern:

[" "] 0{" "}4

Where:

3{}3

XDN

3{}3

1{}8

UNCLASSIFIED Page

12

7/29/2019 UM_XDN-ES010006101UM06_A.doc

13/49


Issue A

Date: 27/03/2003

5. ORDERS

XDN orders allows the operator to:

Verify the status of input and output lines;

Define and apply filters to the input data, based on their position or SSR

code;

Verify if the conversion of coordinates and speed components is foreseen

by the site configuration;

Insert new configuration parameters to use in coordinates and speed

components conversion;

Define and apply a positional filter to the processed data before are sent on

LAN.

5.1.1.1 LSD (Line Status Display)

Purpose: This order collects informations about the status of input and output lines.

Syntax: LSD

Effects:The following table is presented:

INP SEN STA - LAN PORT STA

Where:

INP : Input line identifier, logical name of the channel (e.g. PL01, PL10) :

PL is the prefix for HDLC lines;

01, 10 is the peripheral number in the system.

SEN : Input channel identifier, usually the first two digits are the radars biliteral

identifier, the third is the number of the channel (e.g FM1, FM2)

LAN : Output Lan identifier, logical name of the channel (e.g. IP01, IP03):

IP is the prefix for Lans using UDP protocol;

01, 03 is the peripheral number in the system.

PORT : UDP port identifier, the value must be included between 5201 and 5232.

STA : Represents the lines status, the allowed values are ON or OFF.

Restrictions: None

Comments: The table shows the status of input and output lines and the association

UNCLASSIFIED Page

13

7/29/2019 UM_XDN-ES010006101UM06_A.doc

14/49


Issue A

Date: 27/03/2003

between the input lines and the UDP ports on the output LANs.

UNCLASSIFIED Page

14

7/29/2019 UM_XDN-ES010006101UM06_A.doc

15/49


Issue A

Date: 27/03/2003

5.1.1.2 IGS (Input Geographical filter Set-up)

Purpose: This order allows the operator to define a presentation window for the specified

radar in the specified angular sector or in all sectors at one time.

The window size is determined as follows:

in azimuth, by the sectors size (22.5 degrees);

in range by two values of distance from the radar center.

Syntax: IGS /ALL

Where:

: biliteral identifier of the addressed RDS;

: angular sector, allowed values between 0 and 15;

ALL: the window will be defined on all sectors at the same time;

: geographical window number, allowed values 0 or 1;

: minimun distance from the radar center, allowed values between 0

and 512.00 N.M.;

: maximun distance from the radar center, allowed values between 0

and 512.00 N.M..

Effects:A geographical window will be defined for the specified radar on the specifiedSector.

Restrictions: It is possible to define up to two windows for each angular sector.

The minimum distance of one window must be lower or equal to the maximum one

of the same window. However the distance values must not be greater than 512.00.

Comments: It is possible to modify the window parameters by inserting the order again with

new distance values for that window.

Use the IGD order to verify the window definition.

Examples: The following order defines a geographical window, starting 100.00 N.M. from theradar centre and ending 200.00 N.M. from it, on the first angular sector of the

radar site named RR :

IGS RR 0 0 100.00 200.00

The next order defines another window, starting 300.00 N.M. from the

radar centre and ending 400.00 N.M. from it, on all angular sectors of the radar

site named RR :

IGS RR ALL 1 300.00 400.00

UNCLASSIFIED Page

15

7/29/2019 UM_XDN-ES010006101UM06_A.doc

16/49


Issue A

Date: 27/03/2003

5.1.1.3 IGD (Input Geographical filter Display)

Purpose: This order collects informations about the geographical filter status and

parameters.

Syntax: IGD

Where:

: biliteral of the addressed RDS


INPUT GEOGRAPHICAL FILTER TABLE : Radar

FILTER IS DISABLED

FIRST WINDOW SECOND WINDOW

SECT D.MIN D.MAX D.MIN D.MAX STATUS

Where:


SECT: angular sector expressed on two digits from 00 to 15;

D.MIN: minimun distance from the radar center;

D.MAX: maximum distance from the radar center;

STATUS: filter status, enabled/disabled (ENA/NOT-ENA).

Restrictions: The minimum distance of one window must be lower or equal to the maximum one

of the same window. However the distance values must not be greater than 512.00.

The table can be shown only for one radar at one time.

Comments: The initialization value (0.00) is presented in the distance fields if a window has

not been defined.

The second line of the heading depends on the input filter status which can be

modified through the IGF order.

Examples: The following order allows to show the table referred to the RR radar site:

IGD RR

UNCLASSIFIED Page

16

7/29/2019 UM_XDN-ES010006101UM06_A.doc

17/49


Issue A

Date: 27/03/2003

5.1.1.4 IGF (Input Geographical Filter)

Purpose: This order allows the operator to enable/disable the input data filtering

for the specified radar in the specified angular sector or in all sectors at one time.

Syntax: IGF /ALL ON/OFF

Where:


: angular sector, allowed values between 0 and 15;

ALL: the window will be defined on all sectors at the same time;

ON: enables the geographical filtering;

OFF: disables the geographical filtering.

Effects:If the filter has been enabled, all data coming from the specified radar whose

position is included in the specified sector, but not in the geographical window, are

not sent on LAN.

If the filter has been disabled, all data coming from the specified radar whose

position is included in the specified sector are sent on LAN.

Restrictions: If the filter has already been enabled/disabled no action is performed.

Comments: Use the IGD order to verify the filter status.

Examples: The following order enables the geographical filter on the first sector of the radar

site RR:

IGF RR 0 ON

The following order disables the geographical filter on all the sectors of the radar

site RR:

IGF RR ALL OFF

UNCLASSIFIED Page

17

7/29/2019 UM_XDN-ES010006101UM06_A.doc

18/49


Issue A

Date: 27/03/2003

5.1.1.5 IMS (Input Mode-Code filter Set-up)

Purpose: This order allows the operator to define a set of Mode-Codes to filter, that is not to

be presented.

Syntax: IMS

Where:


: Mode-Code identifier in one of the following notations:

MABCD

MABC*

MAB**

Where:

M = Mode, allowed values 1, 2, A, B, D;

ABCD = Code digits in octal notation;

* = wildcard character

Effects:The inserted Mode-Code is added to the list of Mode-Codes to be filtered, that is

not to be sent on LAN, of the specified radar.

Restrictions: It is possible to insert up to 16 Mode-Codes for each radar.

If the list is full it is necessary to delete one of the elements before the insertion of

a new one, the orderDMC allows to do it.

The Mode-Codes must have the proper notation otherwise the insertion is not

performed.

Use the IMD order to verify the Mode-Codes inserted.

Comments: Every new Mode-Code inserted is added at the end of the list.

No checks are performed to avoid the insertion of a Mode-Code more then once.

Examples: The following order inserts an element, the code A1234, to the list

of Mode-Codes to filter of the radar site named RR :

IMS RR A1234

UNCLASSIFIED Page

18

7/29/2019 UM_XDN-ES010006101UM06_A.doc

19/49


Issue A

Date: 27/03/2003

5.1.1.6 IMD (Input Mode-Code filter Display)

Purpose: This order collects informations about the Mode-Code filter status and parameters.

Syntax: IMD

Where:



INPUT MODE-CODE FILTER TABLE : Radar rd

FILTER IS DISABLED

POS VALUE

Where:

rd: biliteral of the addressed RDS

POS: position in the Mode-Code list expressed on two digits from 00 to 15;

VALUE: Mode-Code value.

Restrictions: The Mode-Code to filter must be found at the beginning of the list while the free

elements must be at the end of it.

The table can be shown only for one radar at one time.

Comments: The initialization value (FFFFF) is presented to state that the element has not

been set.


modified through the IMF order.


IMD RR

UNCLASSIFIED Page

19

7/29/2019 UM_XDN-ES010006101UM06_A.doc

20/49


Issue A

Date: 27/03/2003

5.1.1.7 IMF (Input Mode-Code Filter)

Purpose: This order allows the operator to enable/disable the input data filtering.

Syntax: IMF /ALL ON/OFF

Where:


ALL: the order must be executed for all RDSs;

ON: enables the Mode-Code filtering;

OFF: disables the Mode-Code filtering.

Effects:If the filter has been enabled, all data coming from the specified radar whose

Mode-Code is included in list of those to filter are not sent on LAN.

If the filter has been disabled, all data coming from the specified radar are sent on

LAN without considering their Mode-Code.


Comments: Use the IMD order to verify the filter status.

Examples: The following order enables the Mode-Code filter on the radar site RR:

IMF RR ON

The following order disables the geographical filter on all the radars:

IMF ALL OFF

UNCLASSIFIED Page

20

7/29/2019 UM_XDN-ES010006101UM06_A.doc

21/49


Issue A

Date: 27/03/2003

5.1.1.8 DMC (Delete Mode-Code)

Purpose: This order allows the operator to delete one or all of the Mode-Codes from the list

related to the specified radar.

Syntax: DMC / ALL

Where:

: biliteral of the addressed RDS;

: position of the Mode-Code in the list, allowed values 0 - 15;

ALL: the order is executed on all the Mode-Codes in the list.

Effects:The Mode-Code having the specified position in the list of the radar is deleted.

Restrictions: The order acts only on one radar at one time.

Comments: The deletion is performed by overwriting every element, starting from specified

position, with the one that follows, the last element of the list is set equal to the

initialization value (FFFFF).

If all the Mode-Codes have to be deleted, the element of the list are overwritten

using the initialization values (FFFFF).

Examples: The following order deletes the first element from list of Mode-Codes to filter of

the radar site named RR :

DMC RR 0

The following order deletes all the elements from list of Mode-Codes to filter of


DMC RR ALL

UNCLASSIFIED Page

21

7/29/2019 UM_XDN-ES010006101UM06_A.doc

22/49


Issue A

Date: 27/03/2003

5.1.1.9 CCP (Change Configuration Parameters)

Purpose: This order allows the operator to define a set of configuration parameters to be

used for input data conversion instead of the Default ones if it is not possible to

receive the configuration messages from LANs.

Syntax: CCP

Where:


: X coordinate of the radar site with respect to the OPS

stereographic plane; LSB = 1/16384 N.M. (6 hexadecimal digits);

: Y coordinate of the radar site with respect to the OPS

stereographic plane, LSB = 1/16384 N.M. (6 hexadecimal digits);

: Coefficient to take into account the variability of earth radius at

different latitudes (0 < C < 1); LSB = 2-15 (4 hexadecimal digits);

: Coefficient depending on X, Y and the earth conformal radius;

LSB = 2-31 (4 hexadecimal digits);

: Coefficient depending on X, Y and the earth conformal

radius;

(1 < K < 2); LSB = 2 -14 (4 hexadecimal digits);

: Angle between the RDS plane and the OPS plane;LSB = 1 B.A.M. (4 hexadecimal digits);

: Azimuth of the radar site in the common OPS plane;

LSB = 1 B.A.M. (4 hexadecimal digits);

: Angular deviation of the radar antenna from its local geographical

north; LSB = 1 B.A.M. (4 hexadecimal digits);

Effects:A new set of parameters, to be used in the conversion of the received data position

and speed components, will be defined and stored for the specified radar.

Restrictions: C and A parameters must respect the following conditions:

C = 0x4000

Comments: The definition of a set of configuration parameters, different from the Default one

is needed if these are not correct. The new parameters will be used to perform the

conversion of the input data position and speed components if it is not possible to

receive them through a Configuration message send by MRT or DP on LAN.

The use of the operators defined configuration parameters as well as of the

Default ones is allowed through the orderESC.

The parameters inserted through the CCP order will be overwrittenas soon as a

Configuration message is received or anotherCCP order is given.

UNCLASSIFIED Page

22

7/29/2019 UM_XDN-ES010006101UM06_A.doc

23/49


Issue A

Date: 27/03/2003

Examples: The following order allows to insert or modify the configuration parameters for


CCP RR 000000 00000 7FFF 0000 4000 0000 0000 0000

5.1.1.10 SCP (Show Configuration Parameters)

Purpose: This order collects informations about the geographical configuration parameters.

Syntax: SCP

Where:



CONFIGURATION PARAMETERS TABLE : Radar

ROTOTRASLATION IS ENABLED

DEFAULT CURRENT

X:Y:

C:

A:

K:

BETA:

GAMMA:

DEVIA:

Comments: The Default column shows the initial configuration parameters.

The Current column contains the actual parameters used in data coordinates

Conversion.At start-up data in the two column are the same, during the run-time the

parameters shown in the Current column can be overwritten by those contained

in the Configuration message, sent by Radin data users if received, or by those

inserted by the operator through the CCP order.

Restrictions: The order allows to show the table only for one radar at one time.


SCP RR

UNCLASSIFIED Page

23

7/29/2019 UM_XDN-ES010006101UM06_A.doc

24/49


Issue A

Date: 27/03/2003

5.1.1.11 ESC (Enable Standard Configuration)

Purpose: This order allows the operator to enable/disable the use of the Default or user

defined parameters for input data coordinates and speed components conversion.

Syntax: ESC /ALL ON/OFF

Where:


ALL: the orders affects all radars;

ON: enables the use of the Default or user defined parameters for input

data coordinates conversion;OFF: disables use of the Default or user defined parameters for input

data coordinates conversion;

Effects:If input data coordinates and speed components conversion is not foreseen by

Radin Function configuration, no action will be performed as a result of the ESC

order, otherwise there are the following possibilities:

If the use of parameters is enabled, the elaboration of input data is

started for the specified radar(s), until now they were refused;

If the use of parameters is disabled, the elaboration of input data is

stopped for the specified radar(s) and they are refused;

Restrictions: The ESC .. OFF order must not be inserted if data processing in progress and the

coordinates and speed components conversion is performed using the configuration

parameters received from LAN, in fact this causes the refuse of input data until the

next configuration message is received with a consequent loss of data.

Comments: This order is useful if data conversion has to take place on Radin Function and no

Configuration messages have been received.

Examples: The following order allows the use of the Default or user defined parameters for

the RR radar site:

ESC RR ON

The following order allows disables the use of the Default or user defined

parameters for ALL radar sites:

ESC ALL OFF

UNCLASSIFIED Page

24

7/29/2019 UM_XDN-ES010006101UM06_A.doc

25/49


Issue A

Date: 27/03/2003

5.1.1.12 OGS (Output Geographical filter Set-up)

Purpose: This order allows the operator to define a presentation window centered on the

System Center.

The window size is determined by the semi-distances from the System center along

the Cartesian axises and two height thresholds.

Syntax: OGS

Where:

: semi-distance from the System Center along the X axis;

: semi-distance from the System Center along the Y axis;

: Height lower limit;

: Height higher limit.

Effects:A geographical window, centered on the System center, will be defined.

Restrictions: It is possible to define only one window.

The height values must be included between 1000 and 99999 feet.

The height lower limit must be less or equal than the higher one.

Comments: The distances are expressed in Nautical Miles while the heights in feet.

It is possible to modify the window parameters by inserting the order again with

new distance and height values.

Use the OGD order to verify the window definition.

Examples: The following order defines a geographical window of 200 N.M. along the X axis

and 4000 along the Y one, with height included between 10000 and 20000 feet.

OGS 100.00 200.00 10000 20000

The next order modifies the previous window increasing its extension along the X

axis up to 300 N.M.:

OGS 150.00 200.00 10000 20000

UNCLASSIFIED Page

25

7/29/2019 UM_XDN-ES010006101UM06_A.doc

26/49


Issue A

Date: 27/03/2003

5.1.1.13 OGD (Output Geographical filter Display)

Purpose: This order collects informations about the output geographical filter status and

parameters.

Syntax: OGD


OUTPUT GEOGRAPHICAL FILTER TABLE

FILTER IS DISABLED

X_distance : Y_distance :

Height_min : Height_max :

Where:

X_distance: semi-distance from the System Center along the X axis;

Y_distance : semi-distance from the System Center along the Y axis;

Height_min : Height lower limit;

Height_miax: Height higher limit.

Restrictions: The height lower limit must be lower or equal to the higher one.

Comments: The initialization value (0.00) is presented in the distance fields if a window has

not been defined.


modified through the OGF order.

Examples: The following order allows to show the table:

OGD

UNCLASSIFIED Page

26

7/29/2019 UM_XDN-ES010006101UM06_A.doc

27/49


Issue A

Date: 27/03/2003

5.1.1.14 OGF (Output Geographical Filter)

Purpose: This order allows the operator to enable/disable the output data filtering.

Syntax: OGF ON/OFF

Where:

ON: enables the geographical filtering;

OFF: disables the geographical filtering.

Effects:If the filter has been enabled, all output data whose position is not included in the

geographical window, are not sent on LAN.If the filter has been disabled, all output data are sent on LAN without considering

their position.


Comments: Use the OGD order to verify the filter status.

Examples: The following order enables the output geographical filter:

OGF ON

The following order disables the output geographical filter:

OGF OFF

UNCLASSIFIED Page

27

7/29/2019 UM_XDN-ES010006101UM06_A.doc

28/49


Issue A

Date: 27/03/2003

6. ORDERS LIST

Lines Status Display LSD

Input Geographical filter Set-up IGS /ALL

Input Geographical filter Display IGD

Input Geographical Filter IGF /ALL ON/OFF

Input Mode-Code filter Set-up IMS

Input Mode-Code filter Display IMD

Input Mode-Code Filter IMF /ALL ON/OFF

Delete Mode-Code DMC /ALL

Change Configuration Parameters CCP Show Configuration Parameters SCP

Enable Standard Configuration ESC /ALL ON/OFF

Output Geographical filter Set-up OGS

Output Geographical filter Display OGD

Output Geographical Filter OGF ON/OFF

UNCLASSIFIED Page

28

7/29/2019 UM_XDN-ES010006101UM06_A.doc

29/49


Issue A

Date: 27/03/2003

7. DIAGNOSTICS

7.1 OVERVIEW

The XDN CSCI provides on-line diagnostic messages, relevant to all XDN functionalities, which are used

to inform the operator about special events occurred during the XDN operation.

Diagnostic messages are displayed using the following format:

HH:MM:SS RDN:

Where:

HH:MM:SS: is the time associated to the event

: {

7/29/2019 UM_XDN-ES010006101UM06_A.doc

30/49


Issue A

Date: 27/03/2003

7.1.1 LEVEL 0

7.1.2 LEVEL 1

7.1.2.1 RDN: ALIGNMENT TIMER NOT CREATED, CODE: H

Event: The creation of the timer used to send the alignment request messages

from the Slave to the Master RFE nodes is failed.

Action: Check thereturned result code to know the cause of the failure.

7.1.2.2 RDN: ATX CONVERSION WARNING - CODE

Event: A problem occurred in the Asterix message conversion performed

through the Asterix Library.

Action: Check thereturned code to know the cause of the problem.

7.1.2.3 RDN: BUFFER ORDER NOT AVAILABLE - ORDER NOT SENT

Event: The creation of a buffer to send the LSD or IGD table to SMD was not successfull.

Action: Verify if memory resources are available.

7.1.2.4 RDN: CLOCK STATUS NOT OK. CLOCK DESYNCHRONIZED

Event: The Node is not synchronized with the System clock.

Action: Verify the clock status and connection.

7.1.2.5 RDN: ERROR NO FREE MODE-CODE LOCATIONS, INSERTION NOT PERFORMED

Event: It was impossible to insert a new Mode-Code value to filter

because the maximum allowed number of Mode-Codes has been

reached for the radar, actually it is 16.

Action: Delete one of the Mode-Codes inserted to add the new one.

7.1.2.6 RDN: HIM FAULT PU

Event: Received a message from NSV CSCI indicating that the specified input peripheral is in

FAULT status.

Action: Verify the status of the line connection.

7.1.2.7 RDN: LAN TRANSMISSION OFF - PORT RESULT CODE H

Event: The transmission of data on the specified LAN was not successfull.


UNCLASSIFIED Page

30

7/29/2019 UM_XDN-ES010006101UM06_A.doc

31/49


Issue A

Date: 27/03/2003

7.1.2.8 RDN: PATH NOK - RESULT CODE H

Event: Received a reply to the Create path message indicating that the creation of the path

with the input line failed.


7.1.2.9 RDN: PATH LAN NOK - RESULT CODE H


with IOL0 for the specified LAN failed.


7.1.2.10 RDN: PATH LAN PORT port NOK - RESULT CODE codeH


with UDP for the specified LAN and Port failed.


7.1.2.11 RDN: PATH SMD NOK - STATUS MESSAGE NOT SENT

Event: The path with SMD Function has not been created so it is impossible

to send the Status message.

Action: Restart Radin Function.

7.1.2.12 RDN: PATH SMD NOK - ORDER ACK NOT SENT

Event: The path with SMD Function has not been created so it is impossible

to send messages including tables to be presented on the I/O console.

Action: Restart Radin Function.

7.1.2.13 RDN: PATH SMD NOK RESULT CODE H

Event: Received a reply to the Create path message indicating

that the creation of the path with SMD failed.


7.1.2.14 RDN: POOL EMPTY (LAN) MESSAGE NOT SENT

Event: It was impossible to send messages on LAN because

there were no buffers in the Functions LAN pool.

Action: Verify if there are problems with the LANs or with the receiving Functions, finally

verify if Radin Function is operative. If necessary stop Radin Function and restart.

UNCLASSIFIED Page

31

7/29/2019 UM_XDN-ES010006101UM06_A.doc

32/49


Issue A

Date: 27/03/2003

7.1.2.15 RDN: POOL EMPTY (LINE-PIPE) CNF MESSAGE NOT SENTEvent: The Configuration message sending on serial line failed due to the a

lack of buffers in the LINE pool.

Action: Verify if the input lines status, if they are operative, verify if Radin Function is operative.

If necessary stop Radin Function and restart.

7.1.2.16 RDN: POOL EMPTY (SMD)

Event: It was impossible to send messages to SMD because

there were no buffers in the Functions SMD pool.

Action: Verify if SMD Function is in overflow status.

7.1.2.17 RDN: PU OFF


OFF status.

Action: Verify if data are sent on the line.

7.1.2.18 RDN: PU ON


ON status.

Action: None.

7.1.2.19 RDN: RECEIVED STATUS PL MSG WITH RX STATUS = .

Event: Received a message from NSV CSCI indicating an unknown receiving status for the

specified input HDLC peripheral.

Action: Check the status received to know the cause of the problem.

7.1.2.20 RDN: RX STATUS = FOR - STATUS OFF

Event: Received a message from NSV CSCI indicating that the receiving status of the

specified input HDLC peripheral is OFF.

Action: Check the status received to know the cause of the problem.

7.1.2.21 RDN: RX STATUS ON FOR

Event: Received a message from NSV CSCI indicating that the receiving status of the

specified input HDLC peripheral is ON.

Action: None.

UNCLASSIFIED Page

32

7/29/2019 UM_XDN-ES010006101UM06_A.doc

33/49


Issue A

Date: 27/03/2003

7.1.2.22 RDN: SELECT REPLY FROM NOT OK - RESULT CODE H

Event: Received a reply to the Select message indicating that the selection of the

specified input line failed.


7.1.2.23 RDN: SELECT TIMER NOT CREATED, CODE: H

Event: The creation of the timer used to send the Select messages to IOL Function is failed.


7.1.2.24 RDN: SMD REPLY NOK - RESULT CODE H

Event: Received a wrong reply to a message sent to SMD via path having a wrong message type.


The received buffer is released to the Functions specific pool of buffers.

7.1.2.25 RDN: STATUS MESSAGE NOT SENT

Event: It was impossible to send the Status message to SMD because

there were no buffers in the Functions SMD pool.

Action: Verify if SMD Function is in overflow status.

7.1.2.26 RDN: TRH LINK OFF ---> - MESSAGE NOT SENT

Event: Impossible to send the Configuration message on serial line because

the path with the input line has not been established or the input line

is in OFF status.

Action: Verify the input line connection.

7.1.2.27 RDN: UNABLE TO OPEN THE BINARY CONFIGURATION FILE

Event: It was impossible to open the Binary configuration file in order

to read or update the configuration parameters.

Action: Verify the existence and correctness of the file in the current directory.

7.1.2.28 RDN: WARNING MODE-CODE POSITION OVER THE MAXIMUM

ALLOWED

Event: The value of Mode-Code position inserted in the DMC order was not allowed,

it must be included between 0 and 15.

Action: Insert the order again with the correct position parameter.

UNCLASSIFIED Page

33

7/29/2019 UM_XDN-ES010006101UM06_A.doc

34/49


Issue A

Date: 27/03/2003

7.1.2.29 RDN: WARNING THE MODE-CODE WAS NOT INSERTED

Event: The Mode-Code position inserted in the DMC order was not used,so no action has been performed.

Action: Verify the position of the Mode-Code to delete throgh the IMD order.

7.1.2.30 RDN: WARNING: Unexpected message from NSV

Event: Received a message from NSV Function not expected by Radin Function.

Action: The message will be sent back to the sender Function.

7.1.2.31 RDN: WRONG CONFIGURATION MESSAGE RECEIVED FOR RADAR :

Event: Received a Configuration message MRT or DP Functions via LAN

with wrong C and/or K parameters.

Action: Verify the geographical parameters included in MRT and DP configurations,

in particular it must be:

C = 0x4000

7.1.2.32 RDN: WRONG GEOGRAPHICAL WINDOW IDENTIFIER

Event: The Geographical window identifier inserted in the IGS command is not allowed,

it must be 1 or 2.

Action: Insert the command again with the correct window value.

7.1.2.33 RDN: WRONG MESSAGE TYPE FROM LAN H

Event: Received a message from LAN not expected by Radin Function.

Action: Verify the kind of message received through the type shown.

However it will be sent back to the sender Function.

7.1.2.34 RDN: WRONG MAXIMUM DISTANCE

Event: The distance parameter inserted in the IGS command is not allowed,

it must be at least equal to the minimum one but not more than 512.00 N.M..

Action: Insert the command again with the correct distance values.

7.1.2.35 RDN: WRONG MINIMUM DISTANCE

Event: The distance parameter inserted in the IGS command is not allowed,

it must be at least equal to zero but not more than the maximum distance one.

Action: Insert the command again with the correct distance values.

UNCLASSIFIED Page

34

7/29/2019 UM_XDN-ES010006101UM06_A.doc

35/49


Issue A

Date: 27/03/2003

7.1.2.36 RDN: WRONG MESSAGE FORMAT

Event: There are syntax errors in the order inserted,Action: Check the correct order syntax, looking for the position of blank characters,

the presence of ON or OFF as last parameters of some orders and

the number of parameters allowed.

7.1.2.37 RDN: WRONG ORDER LENGTH

Event: The number of characters inserted for the order is less than the minimum allowed.

Action: Check the correct order syntax and insert it again.

7.1.2.38 RDN: WRONG PARAMETERSEvent: Wrong parameters inserted in the OGS order.

Action: Check the correct order syntax and insert it again.

7.1.2.39 RDN: WRONG PROTOCOL

Event: The configured receiving protocol for the input lines is not correct.

Action: Verify the protocol type in the site configuration file.

7.1.2.40 RDN: WRONG RADAR IDENTIFIER

Event: The Radar identifier inserted in the command is not included in thesite configuration or different from ALL.

Action: Check the allowed radar identifiers and insert the command again.

7.1.2.41 RDN: WRONG SECTOR IDENTIFIER

Event: The Sector parameter inserted in the IGS or IGF orders is not allowed,

it must be included between 0 and 15 or equal to ALL.

Action: Check the correct command syntax and insert it again.

7.1.2.42 RDN: WRONG SELECT REPLY RECEIVED FROM IOL ON : CODEH

Event: Received a reply to a select message sent to IOL for the specified LAN

indicating that the operation failed .


7.1.2.43 RDN: WRONG WRITE ON - RESULT CODE H

Event: Received a reply to a message sent on serial line indicating that the operation failed.


UNCLASSIFIED Page

35

7/29/2019 UM_XDN-ES010006101UM06_A.doc

36/49


Issue A

Date: 27/03/2003

UNCLASSIFIED Page

36

7/29/2019 UM_XDN-ES010006101UM06_A.doc

37/49


Issue A

Date: 27/03/2003

8. ERRORS

8.1 OVERVIEW

The XDN CSCI provides several exceptions, relevant to all XDN functionalities, which are used to inform

the operator about fatal events occurred during the XDN operations.

The exception codes are listed below with an explanation of their meaning to allow the operators to know

the cause of the problem which generated the exception itself; the codes are in hexadecimal notation.

CODE DESCRIPTION

1D00 Not Used

1D01 Not Used

1D02 A second Go message has been received from NSV at start-up while waiting for the Net

message.

1D03 A second Net message has been received from NSV at start-up while waiting for the first Go

message.

1D04 Found NSV message pool empty while trying to send a Create path or console message.

1D05 Found SMD message pool empty while trying to send a Create path message.

1D06 Found LAN message pool empty while trying to send a Create path message with UDP or

IOL or a Select message with IOL.

1D07 Found LINE message pool empty while trying to send a Create path or Select message withIOML Function.

1D08 An error occurred in the creation of the path with NSV Function.

1D09 An error occurred in the creation of the path with SMD Function.

1D0A An error occurred in the creation of the path with the output Lans (UDP or IOL Functions).

1D0B An error occurred in the creation of the path with the input pipe devices.

1D0C An error occurred in the creation of the path with the input HDLC Lines.

1D0D An error occurred in the creation of the path with the input MODM Lines.

1D0E Received a Reply with error code from the input line devices.

1D0F Received a Reply with error code from the output line devices.

1D10 Received an unexpected Reply or a Reply to a Go message with error code from NSV.

1D11 An error occurred during the creation of a Mailbox.1D12 An error occurred during the creation of a buffers pool.

1D13 The configured input data protocol is unknown.

1D14 There is a mistake in the Function configuration related to the input or output lines or to the

UDP ports identifiers.

1D15 Received an unknown message or a Go message with a wrong Node Role value from NSV.

1D16 Unknown peripheral identifier included in the received Go message.

UNCLASSIFIED Page

37

7/29/2019 UM_XDN-ES010006101UM06_A.doc

38/49


Issue A

Date: 27/03/2003

CODE DESCRIPTION

1D17 Tried to send a too long console message to NSV (data length > 452 bytes).

1D18 The format of the input data to be converted is not allowed.

1D19 Unknown UDP port received in the message from LAN, indicates the message source.

1D1A An error occurred during the creation of a timer (IOL Select or Slave Node Alignment).

1D1B The ASCII or Binary configuration files have not been found in the current directory.

1D1C It was impossible to create the Binary configuration file in the current directory.

1D1D An error occurred during the reading of a configuration parameter from the ASCII file.

UNCLASSIFIED Page

38

7/29/2019 UM_XDN-ES010006101UM06_A.doc

39/49


Issue A

Date: 27/03/2003

9. FAULT TOLERANCE

The RFE redundant configuration (MASTER/SLAVE) guarantees the continuity of Radin data output in

case of failure of one RFE node; the SLAVE Radin is aligned to the MASTER one for the configuration

and radar data conversion parameters and is ready to substitute the MASTER one as soon as the latter is

switched off or undergoes an unrecoverable fault.

The Radin Functions alignment is kept through the messages exchange performed during the start-up phase

and during run-time through the notification to both nodes of the orders which modify the configuration or

radar data conversion parameters.

After the power recovery, by reading from the RFE hard disk the configuration file, XDN CSCI is able torestore the previous values of all parameters liable to be modified by order.

UNCLASSIFIED Page

39

7/29/2019 UM_XDN-ES010006101UM06_A.doc

40/49


Issue A

Date: 27/03/2003

10. START-UP DESCRIPTION

When the XDN CSCI is started the following messages are displayed on the RFE I/O console:

RDN: GO_MESSAGE RECEIVED ( START-UP)

RDN: NETWORK MESSAGE RECEIVED

They notify to the operator the reception of the GO and Network messages from NSV.

Then XDN goes on in its start-up activities, including:

Reading of the file containing the configuration parameters; Creation, if not present, of a binary file to store the configuration parameters and

their on-line modifications;

Activation of communication path with SMD CSCI;

Activation of communication paths with IOML CSCI in order to activate and start

the input HDLC serial lines;

Activation of communication paths with IOL or UDP CSCIs in order to activate

the ouput LANs.

After the start-up has been carried out, XDN receives messages about the input lines status presenting one

of the following diagnostics for each line:

RDN: RX STATUS ON FOR

or

RDN: RX STATUS = FOR - STATUS OFF

About XDN start-up it must be pointed out that:

If coordinates and speed components conversion has to be executed by XDN CSCI, all the

received radar data coming from one Radar Head are discarded until the first configuration

message for that radar is received;

Geographical data conversion is performed using the parameters contained in the receivedconfiguratin messages;

Because filtering parameters modifications are always stored in the RDN.BIN file onto the

hard disk, it must be deleted if XDN has to start with the default values, in this case the

configuration parameters are read from the RDN.DAT file, that can be modified only off-line;

The Slave XDN Function discard all the received radar data without performing any

elaboration on them.

UNCLASSIFIED Page

40

7/29/2019 UM_XDN-ES010006101UM06_A.doc

41/49


Issue A

Date: 27/03/2003

11. FUNCTION CONFIGURATION

Radins Function default configuration parameters are included in an ASCII file usually named RDN.DAT

and stored onto the hard disk of the node where Radin is present.

This file is modifiable only off-line through an editor and includes the following kind of data:

Number and Size of the buffers forming the four pools of Radins Function, used to

send messages towards NSV and SMD Functions and towards Input and output lines;

RFE nodes identifiers;

Number of input and output lines;

Input channels identifiers, input protocol type, input lines identifiers, UDP portscorresponding to the input lines on the output LANs, bit masks to select the input and

output data the Function can process;

Output LANs identifiers, LANs multicast addresses;

Format of the received radar data;

Format of the radar data sent on LANs;

Orders class identifier, Orders names and number;

Identifier of the LAN managing Function;

Identifiers of the UAP of the input Asterix data and of the output converted data;

Number and identifiers of the configurad radars;

Flag indicating if the received data Rototraslation is foreseen or not;

Flag indicating if the radar has to be considered as already configured or not;

Radars geographical parameters;

Mode code filter status and values;

Input geographical filter status and values;

Output geographical filter status and values;

In Appendix A is included an explanation of the ASCII file structure and composition.

UNCLASSIFIED Page

41

7/29/2019 UM_XDN-ES010006101UM06_A.doc

42/49


Issue A

Date: 27/03/2003

12. APPENDIX A

The labels in brackets [] and those at the left of the symbol = must not be modified because they have

to be recognized by the program, the operator can modify only the right operands. Comments can be

inserted after the ; character, they can be placed at the end of the lines or on new ones.

RDN CONFIGURATION FILE

Author : Tiziano CasciolaComment: Radin ConfigurationDate : 14/09/2001Site : Romania - Bucarest

Description : Number and size of the buffers constituting the pools used to send messages to NSV andSMD Functions and to the Input and Output lines.A size of 512 bytes is enough to contain messages received from and sent to NSV andSMD Functions, it is also enough to contain the input radar data received through HDLCserial lines.A size of 1536 bytes is the maximum one for buffers to be sent on LAN.

[Buffer_Pools]; number size

NSV_pool = 100 0x200

SMD_pool = 100 0x200

LINE_pool = 100 0x200

LAN_pool = 300 0x600

Description : RFE node identifiers, they are the same set for NSV Function.

[Node_id]; Node-A - Node-B - Node id. according to NSV, three alphanumerical characters

Name = RF1 RF2

Description : Number of the input and output peripheral lines.Actually there can be at most 32 input lines and 2 output LANs.

[Num_lines]Input = 16 ; Input lines' number

7/29/2019 UM_XDN-ES010006101UM06_A.doc

43/49


Issue A

Date: 27/03/2003

Description : Miscellaneous informations about the input lines and their correspondingUDP ports on the output LANs, as follows:

OT1: Input Channel identifier. Usually formed by the radar biliteral identifierand a numerical, 1 or 2 to indicate respectively the Main and Reserve

channels.

1 : Input data protocol type.Allowed input protocols:

PIPE = 0 (AMS data formats) HDLC = 1 (Asterix data format) MODM = 2 (AMS data formats)

PL01: Input line identifier.The first two characters identifies the type of the input peripheralsaccording to the protocols in particular:

PL is associated to the HDLC protocol MM is associated to the MODM protocol 4 blanks are needed in case of PIPE.

The last two digits identifies the number of the input peripheral.

0x1451: Number identifier of the UDP port associated to the input peripheral,meaning that all data received from the input line are sent on LANtowards the specific UDP port.There can be at most 32 UDP ports, associated to the input lines, from the5201 to the 5232 (0x1451 to 0x1470 in hexadecimal notation).

0x106 : IOML bitmask to Select the Asterix categories Radin wants to receive. 0x106 means that Categories 1, 2 and 8 are received.

10 : Lan receiving mask to allow the elaboration of the Configuration messagessent from MRT and DP.

0 means that Radin will not process the Configurationmessages.

[Line_parameters]Line_1 = "OT1" 1 "PL01" 0x1451 0x106 10; OTOPENILine_2 = "OT2" 1 "PL02" 0x1452 0x106 10

Line_31 = " " 1 "PL " 0x145F 0x106 10;Line_32 = " " 1 "PL " 0x145F 0x106 10;

UNCLASSIFIED Page

43

7/29/2019 UM_XDN-ES010006101UM06_A.doc

44/49


Issue A

Date: 27/03/2003

Description : Output LANs identifiers and UDP multicast address.If IOL CSCI is used to send data on lan, the multicast addresses can be set to 0x0

[Output_lan]Lan_A = IP01 0xE00900FC ; LAN id. and Multicast address, 0x0 is IOL is usedLan_B = IP03 0xE00902FC

Description : Format identifiers of radar data received through the input lines.Allowed input formats:

ale_std = 0 ale_std_95 = 1 ASTERIX = 2 russia = 3

[Input_formats]Format = 2 2 2 2 2 2 2 2 0 0 0 0 0 0 0 0

Description : Format identifiers of radar data sent on LANs by Radin.Allowed output formats:

ale_std = 0 ALE_STD_95 = 1 ASTERIX = 2 russia = 3

[Output_formats]Format = 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0

Description : Number OF Radins orders, identifiers of the orders and of the orders class.Listed below there is a list of all Radin orders.

[Orders]Number = 16Ord_Class = XDN

Name = LSD RDO RDI IMS IMD IMF DMC IGS IGD IGF CCP SCP ESC OGS OGD OGF

Description : Type of the interface with the output LANs.The allowed values are:

0 : UDP interface 1 : IOL interface

[IOL_UDP_manager]Type = 0; Output LANs manager. 0 = UDP - 1 = IOL

UNCLASSIFIED Page

44

7/29/2019 UM_XDN-ES010006101UM06_A.doc

45/49


Issue A

Date: 27/03/2003

Description : Interface with the ASTERIX Library (ATL CSCI).The two parameters are bit masks representing the iUser Application Profile according to

which are codified the input data and the output format to which the Asterix Library has toconvert radins input data.

[Atx_interface]UAP = 0x01out_layout = 0

The UAP parameter is divided into two nibbles as follows: The Higher Nibble represent the Users Application Profile used whoseallowed values are:

0 : UAP CIAMPINO 1 : UAP GRECIA 2 : UAP 2000

The Lower Nibble represents the expected output format of the data, theallowed values are:

0 : MODMLAYOUT 1 : BUFFERLAYOUT 2 : RDSMODMLAYOUT 3 : RDSBUFFERLAYOUT 4 : MKSMODMLAYOUT 5 : MKSBUFFERLAYOUT 6 : RDSMKSMODMLAYOUT 7 : RDSMKSBUFFERLAYOUT

The out_layout parameter represents the interface with the new Asterix Library (ATL),it will be assigned to the "outputlayout" parameter passed to the Library. It is divided intotwo bytes as follows:

The Higher Byte represents a bit mask where: The MSB high indicates the presence of MARA andMODMheaders in the output buffer containing converted data,

otherwise, no header is present, only radar data. The following bit high indicates that the Unit of Measureare The following bit high indicates that the Unit of Measureare those of the M.K.S. system, otherwise the Standard systemis used.

The Lower Byte represents the expected output format of the data

converted by the Asterix Library like it was in the interfaces withthe other versions of the Library.

0 : MODMLAYOUT 1 : BUFFERLAYOUT 2 : BYPADS99LAYOUT(only multi-radar data cat. 62 &63)

The compatibility with the existing versions of the Library (CTL,XLF) is obtained byassigning Zero to the constant.

Description : Number and biliteral identifiers of the configured radars.

UNCLASSIFIED Page

45

7/29/2019 UM_XDN-ES010006101UM06_A.doc

46/49


Issue A

Date: 27/03/2003

[Radar_info]Number = 8; Radar number

Name = "OT" "MA" "ME" "BA" "CL" "PU" "SO" "TO" ; Radar identifiers

Description : Flag indicating if the data coordinates and speed conversion of the input data is foreseen.It applies to Plots, Tracks and Meteo vectors sent from all radars.The allowed values are:

0 : No conversion has to be performed 0xFF : Data conversion has to be performed

[Rototraslation]Status = 0xFF; 0xFF = Rototraslation Enabled - 0 = otherwise

Description : Flag indicating if Radin Function has to start elaborating the received data, performingthe coordinates and speed conversion, even if no Configuration message has been receivedfrom LAN, in this case Radins Default geographical parameters are used to convertthe received data.The allowed values are:

0 : Radin is not self-configured 0xFF : Radin is self-configured

[Self_configuration]; Radar 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16Status = 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF0xFF 0xFF 0xFF

Description : Default geographical parameters of all configurable radars, actually 16 at most.The first ten parameters can be obtained through Parconf (see the description of the CCPorder in the present document for an explanation of the parameters), the last two arereserved for future implementations.The following restrictions have to be taken into account, it must be:

C = 0x4000

[Geo_parameters]; X Xr Y Yr C A K Beta Gamma

Devia Spare1 Spare 2Radar_1 = 0x0000 0x0000 0x0000 0x0000 0x8000 0x0000 0x4000 0x0000 0x00000x0000 0x0000 0x0000

Radar_16 = 0x0000 0x0000 0x0000 0x0000 0x8000 0x0000 0x4000 0x0000 0x00000x0000 0x0000 0x0000

Description : Status and values of the input Mode-Code filter.

UNCLASSIFIED Page

46

7/29/2019 UM_XDN-ES010006101UM06_A.doc

47/49


Issue A

Date: 27/03/2003

Allows to define for each radar up to 16 Mode-Codes that cannot be presented on thescreen.

The Status can be: 0 : Filter not Enabled for the radar; 0xFFFF: Filter is Enabled for the radar.

The Mode parameter can assume the following values: 0xFFFF that is the initialization value; 0x0020 Mode 1 0x0040 Mode 2 0x0060 Mode A 0x0080 Mode B 0x00A0 Mode D

The Code parameter can assume the following values: 0xFFFF that is the initialization value; Each digit included between 0 and 7 (octal notation); The F character is allowed in the last 2 digits substituting thewildcard character *.

;Mode_code_filter[Mode_code_filter_Radar1]Status = 0Mode = 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF

Code = 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF

[Mode_code_filter_Radar16]Status = 0Mode = 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFFCode = 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF

UNCLASSIFIED Page

47

7/29/2019 UM_XDN-ES010006101UM06_A.doc

48/49


Issue A

Date: 27/03/2003

Description : Status and values of the input geographical filter.

Allows to define for each of the configurable radars, two presentation windows for each ofthe 16 angular sectors in which is divided a radar scan.Range_min1 and Range_max1 allow to define the first window while Range_min2 andRange_max2 allow to define the second one.The range values are in N.M., the initialization value is 0.00.

The Status can be: 0 : Filter not Enabled for the sector ; 0xFFFF: Filter is Enabled for the sector.

The following restrictions have to be taken into account, it must be: Range_min = 0.00 N.M. Range_max

7/29/2019 UM_XDN-ES010006101UM06_A.doc

49/49


Issue A

Date: 27/03/2003

The following restrictions have to be taken into account, it must be: Range_min