ATP Robustness

<SECURITY RATING><LIVELLO SICUREZZA>

Doc N.XXXX………………….

Iss. …DRAFT.

PROGRAM:

Romanian ATC System Upgrading

ACCEPTANCE TEST PROCEDURE

Robustness and Functional Supplementary Tests

CDRL No. :

Program No. :

Contract Identification Code :

ISSUED BY :

SELEX Sistemi IntegratiVia Tiburtina km 12,4 - Roma

ITALY

The copyright in this document is the property of SELEX Sistemi

Integrati S.p.A. The document is supplied on the express

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 authorised in writing by SELEX Sistemi Integrati

S.p.A.

The total number of pages, included the eventual Appendixes and Annexes, is .. pages.

document.doc <SECURITY RATING><LIVELLO SICUREZZA>

Page 1Mod.


Doc N. XXXX………………….

Iss. …DRAFT.

SECURITY CLASSIFICATION

The following are the military classification levels for the documents from lowest to highest.

NON CLASSIFICATO CONTROLLATO UNCLASSIFIED NC

RISERVATO RESTRICTED R

RISERVATISSIMO CONFIDENTIAL RR

SEGRETO SECRET S

SEGRETISSIMO TOP SECRET SS

Editing, issue, custody, reproduction, diffusion and disposal of Classified documents must be done in conformity to the Internal Security Rules (“Regolamento Interno di Sicurezza”).


Page 2Mod.


Doc N.

Iss.

Validation

Prepared by :<Function>

..........................................................(Name Surname)

Verified/Approved by:<Function>

..........................................................(Name Surname)

Approved by:<Function>

..........................................................(Name Surname)

Checked by:<Function>

..........................................................(Name Surname)

Authorized by:<Function>

..........................................................(Name Surname)


Page 3Mod.


Doc N.

Iss.

REVISIONS RECORD SHEET

This sheet is a record of revisions to this document.

Issue Date Revised ParagraphsDocument

Change Note

Rev. A 20/02/02Rev. B 13/05/02 All

Rev. C 24/05/02 TST_Robustness_7, TST_Robustness_8, TST_Robustness_12, TST_Robustness_26, TST_Robustness_27 TST_Robustness_13, TST_Robustness_16, TST_Robustness_18, TST_Robustness_19, TST_Robustness_20, TST_MRT_10, TST_MRT_11, TST_MRT_14, TST_MRT_17, TST_REC_1, TST_REC_3, TST_PLB_1, TST_BCK_2, TST_CMS_6, TST_CWP_1, TST_CWP_7, TST_CWP_8

Rev. D 16/09/02 -TST_Robustness_9, ”Dropped”-TST_Robustness_27, “Moved in MRT Accuracy and Capability Tests”-TST_MRT_5, updated and re-inserted,-TST_MRT 10, 11,14, 15, 16, 17, 18,19, 21, 22, 23, “Moved into MRT Accuracy and Capability Tests”-Performed general editorial improvement

Rev. E 10/04/03 TST_Robustness_2, TST_REC _2, TST_PLB _5, TST_BCK _4, TST_BCK _5, TST_CWP _7, TST_CWP _4Removed TST_TCA_1, TST_TCA_2, TST_TCA_3; TST_PLB_1

First Issue

Rev. F 31/05/04 TST_Robustness_13, TST_Robustness_17 E04067Rev. G 05/10/04 TST_Robustness_1, 2, 3, 4, 7, 11, 12, 14, 15, 16,

17, 18, 23 TST_MRT_1, TST_CWP _4E040105

07/07/10All pages revised and doc updated to last Selex template. AGW>RFB switch test added


Page 4Mod.


Doc N.

Iss.

ABBREVIATIONS LIST

CODE DESCRIPTION

ACC Area Control Centre

ACD Advanced Common Database

ACK Acknowledge

ACL Arrival CLearance

ACR Arrival Clearance with Re-routing

AFTN Aeronautical Fixed Traffic Network

AIS Aeronautical Information Service

ALV Authorization LeVel

APP APProach control

ARR ARRival

ASF Assistant function

ASQ Arrival SeQuencing

ASS Assistant Controller

ATA Actual Time of Arrival

ATC Air Traffic Control

ATD Actual Time of Departure

ATI Actual Time of Inbound

ATM Air Traffic Management

ATO Actual Time Over

ATS Air Traffic Service

ATW Auxiliary Working Position

BRW BroWse

CNL CaNceL

CoMap Coordination Maps display

CSCI Computer Software Configuration Item

CWP Controller Working Position

DAIW Danger Area Infringement Warning

DARD Direct Access Radar Data

DCL Departure CLearance

DCR Departure Clearance with Re-routing


Page 5Mod.


Doc N.

Iss.

CODE DESCRIPTION

DEP DEParture list

DIS DISabled

DLA DeLAy departure

DMD Dangerous area Map Display

EMG EmerGency

EST ESTimate

ETA Estimated Time of Arrival / Estimated Exit Time from the feeding fix (in ACL order)

ETD Estimated Time of Departure

ETI Estimated Time of Inbound

ETL Estimated Time of Landing

ETO Estimated Time Over

EXE EXEcutive function

FCK Formality ChecK

FCN Flight data CaNcellation

FDM Flight Data Management

FDP Flight Data Processing

FIR Flight Information Region

FL Flight Level

FLD FLDA Displaying

FLDA FLight DAta page list

FLDI FLight DIrectory list

FPLM Flight Plan Message list

FTR File TeRmination

GlobMap Global Mps display

I/O Input/Output

ICAO International Civil Aviation Organization

INBFIX INBound (entry) FIX

INI INItialize

LND LANding report

LRW Landing RunWay

LSV LaSt leVel

LVA planned/cleared LeVel Assignment

MET METeorological


Page 6Mod.


Doc N.

Iss.

CODE DESCRIPTION

MIL MILitary

MNG MaNaGement

MPG Map Generation System

MRT Multi Radar Tracking

MSAW Minimum Safe Altitude Warning

NAVAID NAVigational AID

NM Nautical Miles

NOTAM Notice to AirMan

NVS NaVigator aid

OBT Off Block Time

ODS Operator input and Display System

ONL ON Line

OP Operational

OPRSUP OpeRational SUPervisor

PCN Planning Cancellation

PEN PENding tracks

PKB ParKing Bay allocation

PLB PlayBack

PLC Planning Controller

PLN PlaNning function

QNH Barometric pressure / enter QNH

RCL en-Route CLearance

RCR en-Route Clearance with Re-routing

RDP Radar Data Processing

REC RECording

REG REGistration number

REP Position REport

REV estimate REVision

RHP Radar Head Processor

RNG RaNGe scale

RWY RunWaY

SBY Stand-BY

SID Standard Instrumental Departure


Page 7Mod.


Doc N.

Iss.

CODE DESCRIPTION

SIG fir SIGmet

SMD System Messages Dispatching (CSCI)

SRL SSR code ReLease

SSR Secondary Surveillance Radar / SSR code assignment

STAR STandard Approaching Route

SUM Software User Manual

SUP SuPerVisor

SW SoftWare

TAS True Air Speed / change True Air Speed

TBD To Be Defined

TCA Traffic Conflict Alert

TKF TaKe-oFf report

TMA TerMinal Area

TMS Terminal Area management

TRW departure RunWay

TXT free TeXT

TWR control ToWeR

VDU Video Display Unit

VFR Visual Flight Rule

WTC WaTCher


Page 8Mod.


Doc N.

Iss.

TABLE OF CONTENTS

1. INTRODUCTION..................................................................................................................10

2. GENERAL CONDITION.......................................................................................................10

3. EXTENT OF THE TEST.......................................................................................................10

4. LIST OF INSTRUMENTS AND TOOLS...............................................................................10

4.1 TESTS DESCRIPTION.......................................................................................................114.1.1 TESTS LIST.....................................................................................................................114.2 SYSTEM ROBUSTNESS...................................................................................................144.3 FUNCTIONAL TESTS........................................................................................................24

5. tests results...........................................................................................................................51

LIST OF ANNEXES

ANNEX 01 – E184-02-1875ATP01TDR


Page 9Mod.


Doc N.

Iss.

1. INTRODUCTION

This document contains the supplementary tests to be done at the operative site to ensure that the performance of the part under test meets Selex Sistemi Integrati Technical Specification. The procedures described are a comprehensive check of the part under test.

The specifications contained in this document are current at the time of publication but may be subject to variation as a result of improvement.

The part under test will be in accordance with Selex Sistemi Integrati specifications at the time of manufacture.

2. GENERAL CONDITION

All tests will be performed in the normal environmental conditions of the sites as specified in the contract during the normal indoor operations.

All required personnel will be provided by Selex Sistemi Integrati.

The test will be done by a Selex Sistemi Integrati test team and demonstrated to the Customer's representative.

3. EXTENT OF THE TEST

The test will consist of the following:

- Robustness of system- Redundancy, commuting- Application functionality

Where applicable, for each test the parameters to be checked, the values to be obtained and the test procedures are described.

4. LIST OF INSTRUMENTS AND TOOLS

Not Applicable


Page 10Mod.


Doc N.

Iss.

4.1 TESTS DESCRIPTION

4.1.1 TESTS LIST

The supplementary acceptance tests list is the following:

TEST-ID TEST NAME

System Robustness

TST_Robustness_1 Fail simulation on MASTER nodeTST_Robustness_2 Fail simulation on SLAVE nodeTST_Robustness_3 Fail simulation on both nodesTST_Robustness_4 Start-up simultaneously both nodesTST_Robustness_5 Failure simulation of the LAN connection of the two serversTST_Robustness_6 Connection back of the cable between two serversTST_Robustness_7 LAN failure on the Master nodesTST_Robustness_8 LAN failure on the Slave nodesTST_Robustness_9 Procedure DroppedTST_Robustness_10 Reserve LAN failureTST_Robustness_11 System LAN Main/reserve role SwitchingTST_Robustness_12 Forced System LAN Switching after reserve LAN failureTST_Robustness_13 Failure of the Main LANTST_Robustness_14 Fail simulation of one Radar Head Serial LineTST_Robustness_15 Fail simulation of the Radar Head Serial Line Main LinkTST_Robustness_16 Manual switch from Main to Reserve of the radar serial lineTST_Robustness_17 Disseminator failure in DARD ModeTST_Robustness_18 Failure on one of the two mirrored Hard DiskTST_Robustness_19 Tape Unit failureTST_Robustness_20 System Start-up with only one LAN activeTST_Robustness_21 Time synchronisation TST_Robustness_22 Order performed towards FDP node from a different I/O ConsoleTST_Robustness_23 MST/SLV (Master/Slave role node selection) TST_Robustness_24 Data check in DARD Mode with Plotter function TST_Robustness_25 Whole system Start-upTST_Robustness_26 LAN Switch: Power Supply Off, Reset and Power OffTST_Robustness_27 Test moved into MRT Accuracy Test Documentation


Page 11Mod.


Doc N.

Iss.

Applications Functionality

TST_MRT_1 RTB (Display Radar Table)TST_MRT_2 RAC (Display Angular Corrections)TST_MRT_3 DEV (Change Angular Deviation)TST_MRT_4 CNF (Send Configuration Message)TST_MRT_5 Radar Heads Data Alignment (RAL and Manual Procedures)TST_MRT_6 Slave node AlignmentTST_MRT_7 Change of input of the line statusTST_MRT_8 RDR (Change Radar Line)TST_MRT_9 MRT data output (ASTERIX cat.62 and 63)TST_MRT_10 MRT functionality at radar coverage limit (moved in the MRT Accuracy Tests)TST_MRT_11 MRT fusion functionality (moved in the MRT Accuracy Tests)TST_MRT_12 DMP Order TST_MRT_13 LOA OrderTST_MRT_14 Target Doubling (moved in the MRT Accuracy Tests)TST_MRT_15 Two Parallel Tracks (moved in the MRT Accuracy Tests)TST_MRT_16 Two Crossed Tracks (moved in the MRT Accuracy Tests)TST_MRT_17 Aircraft co-ordinates correctness related with runway co-ordinates TST_MRT_18 Alarm on one track (moved in the MRT Accuracy Tests) TST_MRT_19 Track interrupted by one radar (moved in the MRT Accuracy Tests)TST_MRT_20 Parameters alignment between RADIN and MRTTST_MRT_21 (Procedure moved in the MRT Accuracy Tests)TST_MRT_22 (Procedure moved in the MRT Accuracy Tests)TST_MRT_23 (Procedure moved in the MRT Accuracy Tests)TST_AGW_1 STS (AEA Function Status)TST_AGW_2 Artas GTW/RFB Automatic TransitionTST_AGW_3 Artas GTW/RFB Manual Transition OrderTST_AGW_4 RFB/Artas GTW Manual Transition OrderTST_RFE_1 Simulation of crash of the Main LANTST_RFE_2 Simulation of crash of the DARD LANTST_RFE_3 Filter ordersTST_REC_1 Node role switching with recording session ONTST_REC_2 CHF Command when the tape is not loadedTST_REC_3 Automatic switching of the tapeTST_PLB_1 (Procedure moved in the Voice Reproducer Synchronization Tests)TST_PLB_2 Diagnostic on the CMS and on the PLB printing sessionTST_PLB_3 REV CommandTST_PLB_4 Wrong time on tapeTST_PLB_5 Assign a PLB file while it is already assigned to the recordingTST_BCK_1 Empty tapeTST_BCK_2 Back-up during node role switchingTST_BCK_3 Wrong save set loadedTST_BCK_4 Restore with the WR tape loadedTST_BCK_5 Restore the same save set twiceTST_CMS_1 Global ModeTST_CMS_2 Operative ModeTST_CMS_3 Technical nodeTST_CMS_4 DiagnosticTST_CMS_5 Time AlignmentTST_CMS_6 Log fileTST_TCA_1 (Procedure moved in the RPB/TCA Tests)


Page 12Mod.


Doc N.

Iss.

TST_TCA_2 (Procedure moved in the RPB/TCA Tests)TST_TCA_3 (Procedure moved in the RPB/TCA Tests)TST_CWP_1 Geographical co-ordinatesTST_CWP_2 Window circular positioningTST_CWP_3 Strip printer lack of paperTST_CWP_4 Passage from MRT to DARD and vice versaTST_CWP_5 Failure of the DARD LANTST_CWP_6 Change Mode A CodeTST_CWP_7 Automatic change of disseminatorTST_CWP_8 Meteo MAPS TST_CWP_9 Tracks presentation with the highest level of diagnostic enabled


Page 13Mod.


Doc N.

Iss.

4.2 SYSTEM ROBUSTNESS

TST_Robustness_1 Fail Simulation of a MASTER node

Purpose: Verify the correct behaviour of the system after a Master node fail simulation.

Execution: Switch off the Master node.

Result: The Slave node will switch to Master Alone.

Note: On the CWP’s there will be no loss of Radar data. Verify on the CMS the changed status of the nodes. Switch on the previous node and wait the alignment with the other node. Verify the correct alignment between the two nodes. No double targets on the CWP. STCA remain active.

TST_Robustness_2 Fail Simulation of a SLAVE node

Purpose: Verify the correct behaviour of the system after a Slave node fail simulation.

Execution: Switch off the Slave node. Modify some parameters. (This test is not applicable on FDPSL and FPPS).

Result: The Master node will switch to Master Alone.

Note: On the CWP’s there will be no loss of Radar data. Verify on the CMS the changed status of the nodes. Switch on the Slave node and wait the alignment with the Master node. Verify the correct alignment data between the two nodes included those changed during its stop. If, after the modification of the parameters into the Master Alone node, this node is switched off, it is necessary to start-up this one as first to maintain the new configuration; on the contrary, the last modification will be lost if the Slave node is the one to be started-up as first. Do not change parameters during start-up phase. No double targets on the CWP. STCA active.

TST_Robustness_3 Fail Simulation of both RDP nodes (Not Applicable)

Purpose: Verify the correct behaviour of the system after a fail simulation of both the RDP nodes in matched pair configuration.

Execution: Switch off both the nodes.

Result: The system will change in DARD mode.

Note: Each CWP continues to display its selected radar if it is disseminated. Verify on the CMS the changed status of the nodes. Verify the correct alignment between the two nodes after restarting. The test must be changed or dropped if overlaps a test in MRT fallback.


Page 14Mod.


Doc N.

Iss.

TST_Robustness_4 Start-up Simultaneously both Nodes

Purpose: Verify the system has the capability to start-up two nodes in configuration Master/Slave simultaneously.

Execution: Switch on both nodes.

Result: The fastest node will start as Master Alone and when the other will reach the start-up phase becomes Master.

Note: Verify on the CMS the changed status of the nodes. Verify the correct alignment between the two nodes. No double targets on the CWP. STCA active.

TST_Robustness_5 Fail Simulation of the Inter-Computer Serial Line of the two Servers

Purpose: Verify the correct behaviour of the system after a fail simulation of the Inter-Computer Serial Line of the two servers in Matched Pair configuration.

Execution: Take off the cable connection from one of the two servers.

Result: The node where the cable is disconnected goes in HALT and the other node becomes Master Alone.

Note: On the CWP’s there will be no loss of data. Verify on the CMS the changed status of the nodes.

TST_Robustness_6 Connecting back the Inter-Computer Cable of two Servers

Purpose: Verify the correct behaviour of the system after a connection back of the cable.

Execution: Connect back the cable and start-up the node.

Result: Verify that both nodes recover the Matched Pair Master/Standby functionality.

Note: On the CWP’s there will be no loss of data. Verify on the CMS the changed status of the nodes. Repeat the same procedures (5 and 6) to the other node.


Page 15Mod.


Doc N.

Iss.

TST_Robustness_7 LAN failure on the Master nodes

Purpose: Verify that the failure will be managed by the system without affecting the correct functionality of the system.

Execution: Take off the Main LAN from one of the Master node.

Result: There will be a misalignment of the node. If the node is the AGW (Artas Gateway), the system will be in RFB-C mode; if the node is the RFE the system maintain its whole functionality, if the node is either the FDP or RPB the functionality is stopped, if the node is a CWP that is disseminating a radar, this radar will be disseminated by the next CWP on the LAN. The system can recover its whole functionality either by manual switching of the Main LAN or by a manual node role switching.

Note: Verify on the CMS and CWP the changed status of the nodes. Connect back the LAN on Master node. The functionality will be recovered. Repeat this order for each typology of node. Verify the behavior of CAT 62,63 output.

TST_Robustness_8 LAN failure on the Slave nodes

Purpose: Verify that the failure will be managed by the system without affecting the correct functionality of the system.

Execution: Take off the Main LAN from one of the Slave nodes. (Note: This test is not applicable to the FPPS).

Result: There will be a misalignment of the relevant node without any problem for the system functionality.

Note: Verify on the CMS the changed status of the nodes. Connect back the LAN on Slave node. Repeat this order for each typology of node.

TST_ Robustness_9 Procedure Dropped

TST_Robustness_10 Reserve LAN failure

Purpose: Verify that the failure of the Reserve LAN will be managed by the system without affecting the correct functionality of the system.

Execution: Take off the Reserve LAN from the Master node. (Note: This test is not applicable to the FPPS).

Result: There will be no changes on the correct functionality of the system.

Note: Verify on the CMS the changed status of the nodes. Connect back the Reserve LAN on Master node and check the recovered configuration on the CMS. Repeat this test taking off the Reserve LAN on the Slave node.


Page 16Mod.


Doc N.

Iss.

TST_Robustness_11 System LAN Main/Reserve role Switching

Purpose: Change the operative LAN manually.

Execution: Perform the NWS order from the I/O console of the RDP and perform the order REL STA. ( This test is not applicable on the FPPS).

Result: Verify that the whole system have changed to the second LAN.

Note: Verify that there are not losses of data on the CWP. Verify on the CMS the changed status of the LAN’s. Repeat these orders from the CMS. No double targets.

TST_Robustness_12 Forced System LAN Switching after Reserve LAN failure

Purpose: Change the operative LAN manually even if the Reserve LAN of best node is in fault.

Execution: Take off the Reserve LAN cable from the Best Node Server. Perform the NWS order from the I/O console of the same node and perform the order REL STA. (This test is not applicable on the FPPS).

Result: Verify that the whole System have changed to the Reserve LAN and that the best node is now transferred to another computer. If the node is the master RDP, the system will be in DARD mode; if the node is the master FDP or master RPB the functionality is stopped, if the node is a CWP that is disseminating a radar, this radar will be disseminated by the next CWP on the LAN. The system could be recovering its whole functionality: either by manual switching of the Main LAN or by a manual node role switching. Force RFB to be best node, and also CWP.

Note: Verify on the CMS the changed status of the LAN’s. Repeat these orders from the CMS.

TST_Robustness_13 Failure of the Main LAN1

Purpose: Verify how the system can manage a failure of the Main LAN of the Best Node.

Execution: Take out the cable of the Main LAN of the Best Node from its switch. (This test is not applicable on the FPPS).

Result: Verify that in the system there is another best node and that the whole system remains working to the Main LAN. If the node is the master RDP, the system will be in DARD mode if the node is the master FDP or master RPB the functionality is stopped, if the node is a CWP that is disseminating a radar, this radar will be disseminated by the next CWP on the LAN. The system could be recovering its whole functionality: either by manual switching of the Main LAN or by a manual node role switching.

1 The system does not allow the explicit assignment of OPER (OPERative environment) mode to a LAN, it switches automatically only at a LAN switching. It is possible to assign to different LANs the REAL and PLB environments with command REL LAS from CMS. Note that having OPER and REAL modes working on different LANs leads to the loss of LAN redundancy. In this case the system becomes unstable, switching endlessly between MRT and DARD, and all the information on CWPs is lost.


Page 17Mod.


Doc N.

Iss.

Note: Verify on the CMS the changed status of the LAN’s. Repeat this test switching off all the Switches of the Main LAN (all nodes off) and verify that the whole system changes to the Reserve LAN.

TST_Robustness_14 Fail Simulation of one Radar Head Serial Lines

Purpose: Simulate a failure of the Radar Head data. Repeat the test three times.

Execution: Set in BYP, on the chosen radar, at least one CWP. Take off both the serial cables of the chosen radar head.

Result: Verify that the relevant radar data don’t arrive anymore and the tracks related to that radar head disappears from all the CWP’s.

Note: Verify on the CMS the changed status of the serial line. Connect back the cable and check that the radar data presentation is restored. No double targets.

TST_Robustness_15 Fail simulation of the Radar Head Serial Line Main Link

Purpose: Simulate a failure of the radar data for one of the Radar Heads. Repeat the test three times.

Execution: Set in BYP, on the chosen radar, at least one CWP. Take off the serial cable of the main link of the chosen Radar Head.

Result: Verify that the channel will change, that the data continue to arrive and the tracks related to that radar head are present on the CWP’s.

Note: During this test perform some commands towards the RHP. Verify on the CMS the changed status of the serial line. Connect back the cable. No double targets.

TST_Robustness_16 Manual switch from Main to Reserve of the radar data input channel

Purpose: To check the manual change of the radar data input channel.

Execution: From the CMS performs the manual switch of the radar serial line using the RCS command.

Result: Verify on the SDA Window of the CWP that the channel is changed, that the data continue to arrive and the tracks related to that radar head are present on all the CWP’s. No double targets.

Note: Verify on the CMS the changed status of the radar channel.


Page 18Mod.


Doc N.

Iss.

TST_Robustness_17 Disseminator failure in DARD Mode

Purpose: Simulate a failure of a CWP that is disseminating the data.

Execution: Switch off or reboot the CWP. Repeat this test three times.Result: Verify that the data continue to be presented in all CWP’s because of the occurred change

of the disseminator. Verify that the new disseminator of that radar data is the next available CWP on the list that has the possibility to disseminate that radar data. No double targets.

Note: The radar disseminator change procedure in the REAL operational environment is mainly in charge of the following activities:

1. it shall search for the physical unit responsible for dissemination in the table of nodes (DNSTB).

2. if the physical unit responsible for dissemination is not found, the disseminator change order shall be rejected and a diagnostic message produced.

3. it shall search for the radar to be disseminated in the table of radars (RDNTB).4. if the radar to be disseminated is not found, the disseminator change order shall be

rejected and a diagnostic message produced.5. if the disseminator change order is not concerning the REAL operational

environment, the disseminator change order shall be rejected and a diagnostic message produced.

6. it shall check if the disseminator physical unit is “first level” aligned.7. if the physical unit responsible for dissemination is not “first level” aligned, the

disseminator change order shall be rejected and a diagnostic message produced.8. If the physical unit assigned to the new dissemination is already disseminating

another radar, it shall disable the dissemination of the old radar from the RCHTB table and send the message RCIMG.

9. If the order is of dissemination disabling, it shall disable the dissemination.10. If the radar to be disseminated is already disseminated by another node, the latter

dissemination shall be disabled in the NSTAB table.11. it shall definitely assign the dissemination of the specified radar to the specified node.12. If the specified node is in the REAL operational environment, it shall transmit the

disseminator change message to DIS (a display sub-function) and DPS (a display sub-function).

13. it shall send the status message to XMD.14. it shall notify SYO (a display sub-function) of the order execution.

Verify on the CMS the changed status of the disseminator. Switch on the CWP.


Page 19Mod.


Doc N.

Iss.

TST_Robustness_18 Failure of one of the two mirrored Hard Disks

Purpose: Simulate a failure of one of the two-mirrored Hard disk and verify that the system continues to write to the second one without loss of data.

Execution: Take out one Hard Disk. After some minutes connect back the Hard Disk.

Result: Verify that the other Hard disk continues to write and after a reconnection of the failed one could be necessary to recover the all data following a procedure.

Note: Verify on the CMS the changed status of the Hard Disks. It is not necessary to stop the node to recover the Hard Disk. No data loss.

TST_Robustness_19 Tape Unit failure

Purpose: Simulate a failure of the tape unit during the Back-up.

Execution: After a recording session and during the back-up procedure, take off the cassette from the tape unit.

Result: Verify that the file recorded on the Hard Disk is still assigned to the Back-up waiting for a new tape mounted. After the mounting, the system will start again the Back-up session to the new cassette.

Note: The cassette that has been in fault cannot have a correct data saved for the last save-set. Repeat this test by unplugging the drive.


Page 20Mod.


Doc N.

Iss.

TST_Robustness_20 System Start-up with only one LAN active

Purpose: Simulate a system start-up with only one active LAN.

Execution: Switch off the switch in the equipment room (LAN Main). Switch on all the nodes available.

Result: Verify that the system will start-up to the only LAN available.

Note: Verify on the CMS the status of the LAN’s. Switch on the switch. Repeat this test switching off only the switch in operational room and switches in equipment and operational room. When not all the switches are off, the system has to start-up beginning from those nodes that are connected on the switch off.

TST_Robustness_21 Time synchronization

Purpose: To have all the nodes of the system synchronised also those sited in RDS sites.

Execution: Disconnect the GPS Clock from the RHP and then restart the application

Result: Verify that the time in the RDS site is the same in OPS site performing some orders. Verify also that the data continue to arrive and the tracks related to that radar head are present on all the CWP’s.

Note: Verify on the CMS the changed status of the GPS Clock serial line. Connect back the cable of the GPS to the RHP. Repeat this test taking off the GPS clock cable in OPS site. Repeat again this test switching off both GPS clock in RDS site and OPS site and input manually the new time either from one of the I/O Consoles or from the CMS.

TST_Robustness_22 Order performed towards FDP node from a different I/O Console

Purpose: Perform orders to the FDP node using the I/O Console of the RDP and the SLAVE RPB.

Execution: Type the order from the I/O Console of the RDP.

Result: Verify that the order will be performed.

Note: Repeat the same order from the I/O Console of the RPB node.


Page 21Mod.


Doc N.

Iss.

TST_Robustness_23 MST/SLV (Master/Slave role node selection)

Purpose: To verify the manual mode commutation between nodes in matched-pair configuration.

Execution: To switch from MASTER to SLAVE the order to be entered from the I/O console of the MASTER node is:

SLV

and press “RETURN”.If the order is acknowledged, the following diagnostic message will be displayed:

NSV: SWITCHING: MASTER ® STAND-BY

At the end of the switching, the following diagnostic message will be displayed:

NSV: END SWITCHING:MASTER ® STAND-BY

If the order is not acknowledged, the following diagnostic message is displayed:

XXX MST: INCONSISTENCE ORDER WITH MASTER STATUS OF NODE

To switch from SLAVE to MASTER the order to be entered is:

MST

and press “RETURN”.If the order is acknowledged, the following diagnostic message will be displayed:

NSV: SWITCHING: STAND-BY ® MASTER

At the end of the switching, the following diagnostic message will be displayed:

NSV: END SWITCHING:STAND-BY ® MASTER

If the order is not acknowledged, the following diagnostic is displayed:

XXX SLV: INCONSISTENCE ORDER WITH STANDBY STATUS OF NODE

Note: Repeat the test three times, after the complete recovery of new master node.


Page 22Mod.


Doc N.

Iss.

TST_Robustness_24 Data check in DARD Mode with Plotter function

Purpose: Verify on Plotter the data recorded during the DARD mode.

Execution: Start a session of recording. Perform the DRS order to put the system in DARD Mode. After some minutes, stop the recording session. Take the registration and make some check using the Plotter function.

Result: Verify that the data are correct both in MRT and in DARD Mode.

Note: None.

TST_Robustness_25 Whole system Start-up

Purpose: Verify the behaviour of the system starting-up all nodes at one time.

Execution: Switch off all the nodes of the system and switch them all on together.

Result: Verify that the whole system will start-up into 10 minutes.

Note: None.

TST_Robustness_26 LAN SWITCH main Power Supply Off, Reset and full Power Off

Purpose: Verify the behaviour of the system acting on the LAN switch of the Servers and CWP’s.

Execution: Switch off the Power Supply of the LAN SWITCH of the Servers. Reset the switch of the Servers. Switch off the LAN SWITCH of the Servers

Result: Verify that: after the first case the servers connected to that switch are misaligned to the rest of the system until the Reserve Power Supply enters in function, after the second case the servers connected to that switch can be misaligned to the rest of the system if the recovery time of the LAN SWITCH, after its reset, takes some seconds, after the third case the servers connected to that switch will be definitively misaligned to the rest of the system and a manual change of the LAN has to be performed.

Note: After the Switching On of the LAN SWITCH the system will recover the whole functionality. Repeat the test in the OPS room also.


Page 23Mod.


Doc N.

Iss.

TST_Robustness_27 (Test Procedure moved in the MRT Accuracy Tests)

4.3 FUNCTIONAL TESTS

TST_MRT_1 RTB (Display Radar Table)

Purpose: To verify the presentation on a table of the following information:

- Selected monoradar data source- Input lines status and selection- Number of LTs received (globally e per radar)- Number of STs actually in MRT database

Execution: On the I/O console of the master RFB input:

RFB RTB

and press “RETURN”.

Result: The following text is displayed:

RDS INPUT STATUS :

Total System Track :

Total Local Track :

System Mode :

MRT Role :

Function Status :

Function Status1 :

Input Source :

RDS LINE STATUS LOC. TRK A. SYN F. SYNWhere:

TOT. LT,TOT. ST: total number of LTs / STs actually in XMR database

System. Mode: DARD_C: commutation DARDDARD-F: (manually) forced DARDRDP: Artas Mode


Page 24Mod.


Doc N.

Iss.

RFB-C: commutation RFB RFB-F: (manually) forced RFB

MRT Role: node roleMST: MASTER or MASTER ALONE SBY: SLAVE (stand-by)

Function Status: internal statusNOT_READY : The function hasn’t system tracks

READY_TO_WORK : The function has system tracks OPERATIVE : The function has system tracks and send this to the

system

Function Status1: (valid only in if the function is configured in rfb mode)NOT_ALIGNED : the function doesn’t receive MRT tracksALIGNED : the function receives MRT tracks and the system tracks

numbers are alignedInput Source: monoradar data source

REAL: data are received from RHPs

RDS: biliteral of the connected RDS

LINE: identifier of the OPEN physical lineMA: identifies the line from RHP-ARS: identifies the line from RHP-B

STATUS: reception status of monoradar dataON: line is active, but north is not received yetOP: line is active and receives radar data OFF: XMR does not receive any radar dataBY: line has been set to BY status by RDR orderNU: line has been set to NU status by RDR order

LOC.TRK: number of LTs received from RDS in the last radar scan

A.SYNC: radar de-synchronization status from RDSON: radar is synchronized OFF: radar is not synchronized

F.SYNC: radar de-synchronization status forced by operatorON: radar is synchronized OFF: radar is forced in the desynchronized status by operator

Note: Perform the same test on the other node.


Page 25Mod.


Doc N.

Iss.

TST_MRT_2 RAC (Display Angular Corrections)

Purpose: This order displays, for each connected radar site, a log-book table containing the last seven angular deviations manually inserted (DEV order) or automatically computed by AMR (RAL order or at request of alignment).

Execution: RFB RAC

Result: The following table is presented for each radar site:

** Radar: <rd> Initial devia <XXX.XXXV> Deg ** DATE 0 {<date>} 7 TIME 0 {<time> } 7 DEVIA 0 {<devia>} 7

Where:

<rd>: bi-literal of the given RDS<XXX.XXXV>: Starting deviation value (in decimal degrees)XXX.XXX: value of deviationV: orientation of deviation

E: EastW: West

<date>: date of each modification<time>: time of each modification<devia>: value of each occurred modification (in decimal degrees)

Note: Repeat the same order on the Slave console to verify the alignment data.


Page 26Mod.


Doc N.

Iss.

TST_MRT_3 DEV (Change Angular Deviation)

Purpose: This order corrects the angular deviation of a radar antenna from its local geographical north, and communicates the new value to the given radar site.

Execution: RFB DEV <rd> B|D <devia>

Where:

<rd>: bi-literal of the addressed RDSB|D: specifies if the <devia> value is input in hexadecimal B.A.M.

or decimal Degrees.<devia>: HHHH if B|D=B (four hexadecimal digits)

DD.DDDl if B|D=D (five decimal digits, followed by E or W)

Result: The new deviation value is sent to the RADIN, in an updated configuration message.

Hard disk and stand-by RDP are aligned.

Note: The values are not sent if the OPEN channel of the addressed RDS is in NU status.Use RAC order to display the last seven angular deviations for each radar.

Examples: Next order sets to 10 B.A.M. the angular deviation of radar site OT:

DEV OT B 000A

Next order sets to - 00^ 45' 00" the angular deviation of radar site BU:

DEV BU D 00.750W


Page 27Mod.


Doc N.

Iss.

TST_MRT_4 CNF (Send Configuration Message)

Purpose: This order sends configuration message(s) from AMR to XDN(s); each configuration message includes the following parameters:

XR, YR, C, A, K, BETA, GAMMA, SO$RA

(Displayed by RCT order, modified by MCT order)

DEVIA

(Displayed by RAC order, modified by DEV and RAL orders)

Execution: RFB CNF <rd>|ALL

Where:

<rd>: bi-literal of the addressed RDSALL: if the order must be executed for all connected RDS

Result: The following order sends a configuration message to the radar site whose bi-literal is OT:

RFB CNF OT

The following order sends configuration messages to all connected radar sites trough the RFE Master node

RFB CNF ALL

Note: The values are not sent if the OPEN channel of the addressed RDS is in NU status.

Repeat the RAC order on both nodes console to verify the alignment data.


Page 28Mod.


Doc N.

Iss.

TST_MRT_5 Not Synchronised Radar Heads Data Alignment (RAL and Manual)

The alignment of a radar head data can be performed by an automatic procedure (RAL) or manually. The decision of choosing either one or the other procedure depends mainly upon the following conditions:

Presence of radar(s) provided of SSR Site Transponder, Presence of overlapped radar coverage between synchronised and non synchronised radars, Number of aeroplanes flying in the overlapped area. Experience of the System Specialist in performing MRT alignment

Upon the above said consideration the most suitable procedure of alignment will be adopted; in the following both the possible procedures are mentioned.

a) RFB Automatic Alignment (MRT RAL)

Purpose: To correct the angular deviations of each radar antenna from its local Geographical North

Execution: On the I/O console of the master RDP, input:

RFB RAL

Effects: The list of radars couples is scanned, and radars alignment algorithm is activated for two radars at a time; a positive / negative diagnostic (at level 3) concludes the alignment phase for each couple. The new deviations values are sent to the given radar sites, in updated configuration messages. The MASTER AMR performs radar alignment; at the end of the algorithm hard disk and stand-by RFB are aligned Use RTB and RCP orders to check the above conditions.

Note: As far as RAL command concerns, further checks have to be recalled: i.e. Related to “Beta”

o “Beta” value is changed,o Then, RAL command is issued,o “DEVIA” value is checked whether it modifies as consequence of “Beta”

value modification for the relevant radar under alignment. Related to a Test Transponder Coordinates

o The parameters of a Test Transponder will be modified in such a way to simulate a different angular position with respect to a radar,

o Then, RAL command is issued,o “DEVIA” has to compensate the simulated Radar Head rotation


Page 29Mod.


Doc N.

Iss.

b) RFB Alignment Procedure of Radar without Test-Transponder

Purpose: To correct the angular deviations of each radar antenna from its local Geographical North

Execution: Set in BYP all the radars that have not a Site Test-Transponder to be used as reference for

the alignment. Disable the Tracks output flow of the radar to be aligned, so that only the Plots of that

radar will be present. Chose on the CWP the radar to be aligned and enable its Plot presentation. Select on the relevant CWP the minimum Range Scale of presentation. Compare the System Track (ST) against the Plots of the radar under alignment. Minimize the difference between the System Track (ST) and the Plot using the “DEVIA”

order. Enable the Tracks output flow so that also that radar can contribute for the new System

Track. Set in OP status the radar that has been aligned.

Effects: The chosen radar is aligned and contributes for the System Tracks


Page 30Mod.


Doc N.

Iss.

TST_MRT_6 Slave Node alignment

Purpose: Verify the alignment of the data on Slave node after the start-up phase.

Execution: Switch off the Slave node.

Repeat the TST_MRT_3.

Switch on the Slave node and repeat the RAC command.

Result: Both Master node and Slave node have the same parameters.

TST_MRT_7 Change of the input line status

Purpose: Verify the line status change after failure simulation.

Execution: Make the RTB command on the RFB console.

Take off the both cable from the back of RFE node.

Make again the RTB command.

Result: The value related to the line status is changed from OP to off.


Page 31Mod.


Doc N.

Iss.

TST_MRT_8 RDR (Change Radar Line)

Purpose: To verify the modification of the logical status of input data, allowing the operator to perform:

- a logical disconnection (whole or partial) of one or more radar channels; - a de-synchronization of one or more radar.

Execution: On the I/O console of the Master RDP input:

RFB RDR <rd> <status> [<chan>]

where :

<rd> : bi-literal of the addressed RDS<status>: OP|BY|NU|SY|DG assigned logical status (see below)<chan>: M|R identifies the addressed channel; if omitted, the status of both

channels is assigned


Result: The addressed channel is set in one of the following status:

OP Radar data incoming from "OP" channels are normally elaborated (default value for all channels)

BY Radar data incoming from "BY" channels do not contribute to the kinematics of the STs, but they can only be displayed on DPs set in bypass mode on the given radar (if any)

NU Radar data incoming from "NU" channels are completely discarded

SY radar data contribute to the kinematics of the STs, but they can only be displayed on DPs set in bypass mode on the given radar (if any)

DG radar data incoming from "DG" radar contribute to the kinematics of the STs only for a time equal to the radar rotation time. After that all tracks are completely discarded.

The setting is written in the Hard Disk and the Stand-by RDP is aligned.

TST_MRT_9 RFB data output (ASTERIX cat. 62 and 63)

Purpose: Verify the correct data coming out by the serial line from the RDP node.

Execution: Connect a protocol analyser to the serial output of the RDP node.

Result: Verify that the data are the same described into the ICD document.


Page 32Mod.


Doc N.

Iss.

TST_MRT_10 MRT functionality at radar coverage limit

(moved in the MRT Accuracy Tests)

TST_MRT_11 MRT fusion functionality


TST_MRT_12 DMP order

Purpose: Verify the possibility to save a certain configuration.

Execution: Perform the DMP Order. Change one of the following parameters:

Couples, DEVIA and all the parameters included into the RCT Order.

Result: In the Hard Disk it will store the file with this change.

TST_MRT_13 LOA Order

Purpose: Verify the possibility to recover the previous configuration..

Execution: Perform the LOA Order and RFB CNF ALL Order.

Result: The old configuration is now working.

TST_MRT_14 Target Doubling (moved in the MRT Accuracy Tests)

TST_MRT_15 Two Parallel Tracks (moved in the MRT Accuracy Tests)

TST_MRT_16 Two Crossed Tracks (moved in the MRT Accuracy Tests)

TST_MRT_17 Aircraft co-ordinates correctness related with runway co-ordinates


TST_MRT_18 Alarm on one track (moved in the MRT Accuracy Tests)

TST_MRT_19 Track interrupted by one radar (moved in the MRT Accuracy Tests)


Page 33Mod.


Doc N.

Iss.

TST_MRT_20 Parameters alignment between RADIN and MRT

Purpose: Verify that the parameters in the system are the same

Execution: Change the XR parameter in the MRT. Send the configuration message using CNF command.

Result: Verify that on the RADIN (SCP) and MRT (RCT) the parameters changed are the same.

Note: Perform the orders also from the CMS.

TST_MRT_21 System Tracks Position Error in Circular Trajectory

(Procedure moved in the MRT Accuracy Test Procedures)

TST_MRT_22 Multi-radar tracker performance for Target in straight motion


TST_MRT_23 Multi-radar tracker performance for manoeuvring Target



Page 34Mod.


Doc N.

Iss.

TST_AGW_1 STS (AEA Function Status)

Purpose: To verify the presentation on a table of the following information:

- Rx Status- Node Role (Master or stand-by)- System Mode (RFB, RDP or DARD)- Input Lan- Total System Tracks- Configured Radars status

Execution: On the I/O console of the master AGW input:

MRT STS


TST_AGW_2 Artas GTW/RFB Automatic Transition

Purpose: To verify the ARTAS GTW/RFB Automatic Transition

Execution: Execute and verify the following steps:

1. ARTAS receives from each Radar i [ i=1…N ] a local track.

2. RFB receives from each Radar i [ i=1…N ] a local track.

3. The ARTAS creates its own system tracks from the local radar tracks and send them to the ARTAS GTW.

4. The RFB creates its own system tracks from the local radar tracks.

5. The ARTAS GTW performs the format conversion from ARTAS tracks format to AMS legacy format.

6. On the CWP, in the system data area, check by visual inspection that the data are received from ARTAS GTW

7. At a certain time T0 the ARTAS GTW is intentionally switched off.

8. On the CWP, in the system data area, check by visual inspection that the data are received from RFB.


Page 35Mod.


Doc N.

Iss.

Result: Verify that:

1. The following modes of operation (source) automatic transitions shall be provided:ARTAS Gateway → RFB.

2. The automatic transition from ARTAS Gateway to RFB shall occur, at a certain time T0, when ARTAS GTW source shall be no more available.

3. On the CWP, in the system data area, check by visual inspection that the data are received from RFB.

TST_AGW_3 Artas GTW/RFB Manual Transition Order

Purpose: To verify the ARTAS Gateway → RFB Manual Transition.







6. Check on the CWP that the system tracks are received from ARTAS GTW.

7. At T0 the ARTAS Gateway → RFB “manual transition order” is performed using REL RFB order;

8. Check that now on the CWP the system tracks are received from RFB


The following modes of operation (source) manual transitions shall be provided:ARTAS Gateway → RFB.- From T0 , RFB creates system tracks from the local radar tracks-

.


Page 36Mod.


Doc N.

Iss.

TST_AGW_4 RFB/Artas GTW Manual Transition Order

Purpose: To verify the RFB → ARTAS Gateway Manual Transition







6. Check on the CWP that the system tracks are received from RFB.

7. At T0 the RFB → ARTAS Gateway “manual transition order” is performed

8. Check that now on the CWP the system tracks are received from ARTAS Gateway.


The following modes of operation (source) manual transitions shall be provided:RFB → ARTAS Gateway.


Page 37Mod.


Doc N.

Iss.


Page 38Mod.


Doc N.

Iss.

TST_RFE_1 Simulation of crash of the Main LAN

Purpose: Verify the behaviour of the system if there is a crash of the Main LAN

Execution: Disconnect the cable of the Main LAN of the Master node.

Result: The system will remain in RFB MODE and all radar’s input LAN will switch on reserve. The full functionality is recovered by a manual node role switching.

Note: Verify on the CMS the changed status of the nodes. Connect back the LAN on the node.

TST_RFE_2 Simulation of crash of the DARD LAN

Purpose: Verify the behaviour of the system if there is a crash of the DARD LAN

Execution: Disconnect the cable of the DARD LAN of the Master node.

Result: The system will remain in RFB Mode.

Note: Verify on the CMS the changed status of the LAN’s.

TST_RFE_3 Filter orders

Purpose: Verify on the CWP’s the behaviour of these orders.

Execution: Perform the filter orders from the I/O console of the RFE. Perform the RTB order.

Result: On the CWP’s only the tracks belonging to the sectors not included in the filter orders are presented. Verify with the RTB order that the line has a decrease number of targets from the filtered line. Perform the same orders from the CMS.


Page 39Mod.


Doc N.

Iss.

TST_REC_1 Node role switching with recording session on

Purpose: Verify correctly switching nodes during the recording session active.

Execution: Insert the order with the following format:

REC RUN

After this command sequence on the I/O console, of Master node, make the command:

SLV

Result: The following controls are executed:

“RUN: RECORDING ALREADY IN RUN” is shown if REC is already running.

“RUN: ERROR IN EXECUTION” is shown in case of errors at command execution.

Once executed, “RUN: RECORDING IN RUN” is displayed and the recording starts to record on the Hard Disk. With the last command the Master node change its status in Slave status without compromise the recording session. Check the result on Playback.


Page 40Mod.


Doc N.

Iss.

TST_REC _3 Automatic switch of the swap area (HD1, HD2)

Purpose: Verify that reaching the maximum number of the savesets available for the swap area the system automatically switches to the other swap area.

Execution: During a recording session perform the change file order a number of times equal to the max_num_saveset_on_TAR parameter:

REC CHF (xx times)

Result: After the CHF order wait for “FILE CHANGED”. After reaching the last saveset on the first swap area the system automatically will write the next file on the second area.

Note: Before changing the file wait for the end of the Back-up (END OF BACKUP ON HD1).

Perform the same orders from the CMS. Check the result on Playback.

TST_PLB_1 Voice-Data Recorder synchronisation

(Procedure moved in the Voice Reproducer Synchronization Tests)


Page 41Mod.


Doc N.

Iss.

TST_PLB _2 Diagnostic on the CMS and on the PLB printing session

Purpose: Verify that the diagnostic presented on the CMS during the recording session is the same of that printed during the playback session.

Execution: Assign to the same sector more than one CWP in Playback mode. Assign the printer to the PLB function and start the PLB session with the orders:

PLB ASS SP01

PLB ENA SP

PLB RUN

Print on the CMS the LOG file related to the period of the PLB session.

Result: Both the PLB printed and the LOG file printed has the same diagnostic.

Note: Perform the same orders from the CMS. Verify that after configuring the CWP to the real world, the old configuration must be presented.

TST_PLB _3 REV Command

Purpose: To review the last “mm” minutes of PLAYBACK.

Execution: Insert the order with the following format:

PLB REV mm

and then press “RETURN”. (“mm” is the duration of the PLAYBACK review)

Result: If the PLAYBACK is not in PAUSE the diagnostic “COMMAND NOT IN SEQUENCE” is displayed.If the start time of the review is not available the diagnostic “TIME IS NOT ON TAPE” or “TIME IS NOT ON FILE” is displayedIf the command is executed the following diagnostics is displayed.

“PLAYBACK IN RUN”“PLAYBACK IN PAUSE”

Note: Verify that it is not possible to make orders regarding the real world meantime the CWP is in playback mode. The orders regarding the presentation can be performed. Perform the same orders from the CMS.


Page 42Mod.


Doc N.

Iss.

TST_PLB _4 Wrong time on file

Purpose: If a wrong time or date is written in the positioning order the system advice about the error.

Execution: With the order PLB INF check the correct date and time on the file and perform the positioning order putting a wrong time.

Result: The following diagnostic will appear on the CMS and on the RPB I/O Console :

REPRODUCER RUN NOT POSSIBLE

Note: Perform the same orders from the CMS.


Page 43Mod.


Doc N.

Iss.

TST_BCK _1 Empty tape

Purpose: Verify that after that a tape is initialised the cassette is empty.

Execution: Perform the following orders:

BCK ASS DT1 WR (PASSWORD)

BCK MOU DT1 INI

BCK DMO DT1

BCK DEA DT1

BCK ASS DT1 RD

BCK MOU DT1

Result: Verify that the tape cannot be read because empty.


TST_BCK _2 Back-up during node role switching

Purpose: Verify that, during a node switching there are no losses of data while the backup is running.

Execution: During a recording session perform the following order:

REC CHF

On the Master node perform:

SLV

After the switching perform:

REC INF

BCK INF DT1

Result: After the CHF order the old main file is locked to the BCK function and starts its file save on the tape. After the node switching verify, with the INF order, that the data saved on the tape are the same of what saved on the HD.

Note: Repeat the same test with a big change file. Perform the same orders from the CMS. Check the result on Playback. This test can be performed for backups on the local swap areas and for backups on tapes.


Page 44Mod.


Doc N.

Iss.

TST_BCK _3 Wrong saveset loaded

Purpose: Verify that the system shows a diagnostic if there is the intention to back-up a number of savesets greater than the allowed.

Execution: Perform the following order:

BCK INF HD1

BCK RST HD1 FXX FL5

Result: After the INF order it is possible to verify how many savesets are present on the swap area. With the RST order it is trying to restore a file that doesn’t exist on area. The following diagnostic will be displayed :

ERROR IN COMMAND


TST_BCK _4 Restore with the WR tape loaded

Purpose: Verify that it is not possible to restore a file from a tape assigned in write mode.


BCK ASS DT1 WR (PASSWORD)

BCK MOU DT1

BCK INF DT1

BCK RST DT1 FXX FL5

Result: After the ASS order the tape is assigned in write mode, After the MOU order the tape is mounted in write mode. With the INF order it is possible to verify witch file we want to restore. After the RST order the following diagnostic will be presented:

ERROR IN COMMAND



Page 45Mod.


Doc N.

Iss.

TST_BCK _5 Restore the same save set twice

Purpose: Verify that it is possible to restore a file from a swap aread into two different files.


BCK INF HD1 (or HD2)

BCK RST HD1 FXX FL4

BCK RST HD1 FXX FL5

Result: With the INF order it is possible to verify witch file we want to restore. After both the RST orders the following diagnostic will be presented:

ORDER EXECUTED

Verify that both files have the same file restored with the PLB INF command.



Page 46Mod.


Doc N.

Iss.

TST_CMS _1 Global mode

Purpose: Verify that, the CMS can perform all the orders foreseen in this session

Execution: Perform all the orders included in the menu bar.

Result: All the orders are correctly executed. Some effects are presented on the various screen of the CMS.

Note: From the other CMS it is not possible to make the same orders while global mode is set.

TST_CMS _2 Operative mode

Purpose: Verify that, the CMS can perform all the orders foreseen in this session



Note: From the other CMS it is possible to set the Technical mode.

TST_CMS _3 Technical mode

Purpose: Verify that, the other CMS can perform all the orders foreseen in this session



Note: From the other CMS it is possible to set the Operative mode.

TST_CMS _4 Diagnostic

Purpose: Verify that on the CMS is possible to see the diagnostic until level 7.

Execution: Perform the order UDL 7 ALL on all the nodes of the system from the free text menu of the CMS.

Result: Verify that all the nodes are producing diagnostic at level 7 and the CMS is able to show them.

Note: With the order UDL I ALL no diagnostic is produced by the nodes and displayed on the CMS.


Page 47Mod.


Doc N.

Iss.

TST_CMS _5 Time realignment

Purpose: Verify that after the start-up the CMS is able to present the correct time of the system.

Execution: Stop both the CMS and, after disconnecting the GPS units (also from radar heads) perform the STT order. After the system has the new time set, start-up both CMS.

Result: Verify that the new time is presented on the CMS.

Note: Put back the GPS units to have the correct time on the system.

TST_CMS _6 LOG file

Purpose: Verify that the CMS can store and print a LOG file.

Execution: From the CMS menu start a session of LOG and after a certain period stop with this session.

Result: Verify the diagnostic produced during the registration of the LOG file is presented and printed and it is the same of the diagnostic appeared on the VDU.

TST_TCA _1 Maximum number of maps

Test Moved in the RPB/TCA Tests

TST_TCA _2 TCA functionality test in Playback


TST_TCA _3 Double alarm on double target



Page 48Mod.


Doc N.

Iss.

TST_CWP _1 Geographical co-ordinates

Purpose: Verify the correct position of some known points.

Execution: Built a map in which are present some known points and install it on the CWP’s. Use the mouse to verify the correct their position on the screen.

Result: Verify that all points are presented correctly.

Note: Repeat this test using the Test Transponder position with delay = 0. Repeat this test on all the CWP’s.

TST_CWP _2 Window circular positioning

Purpose: Verify the correct behaviour of the CWP during a circular movement of the windows.

Execution: With the WB button, capture one of the window present on the screen and start to move it very fast in all the direction.

Result: Verify that there is no presentation problem during this test.

Note: Repeat this test on all the CWP’s.

TST_CWP _3 Strip printer lack of paper

Purpose: Verify that, if there is a lack of paper while some strips must be printed, the strips will be printed as soon as the device has the new paper carried on.

Execution: Take out the paper from the strip printer. Perform some orders on some flight plans to have some strips (ex. EST order, Take OFF) and put a new paper into the strip device.

Result: Verify that after the new paper is installed the previous strips will be printed.

Note: Repeat this test on all the CWP’s.


Page 49Mod.


Doc N.

Iss.

TST_CWP _4 Passage from MRT to DARD and Vice versa (Not Applicable for RDP/RFB)

Purpose: Verify that on the CWP’s there is no loss of information regarding the tracks and their correlated flight plans on selected radar if it is disseminated, during the passage from MRT to DARD and Vice versa.

Execution: Perform the following orders on the I/O console of the RDP :

DRS / MRS

Result: Verify on the CWP’s there is no loss of information on selected radar during the passage from MRT to DARD and vice versa.

Note: The FDP shall be operative during this test.

During the transition MRT->DARD all the SFPL correlated to the tracks outside the coverage of selected bypass radar will be lost and displayed into Coast List, while the tracks under coverage remain correlated.After the switch in MRT mode, the controller to recover the normal working condition shall act on the all tracks outside the coverage of selected bypass radar using the appropriate command (AoC for the tentative tracks and Correlate to correlate the pending tracks and flights in coast list).

TST_CWP _5 Failure of the DARD LAN

Purpose: Verify the reaction of the system if there is a failure of the DARD LAN in DARD Mode.

Execution: Switch off the switch of the DARD LAN.

Result: Verify that all the radar data are lost.

Note: It is necessary to have at least one of the RDP’s operative to recover the situation, otherwise it should be considered as a double fault.

TST_CWP _6 Change Mode A Code

Purpose: Verify the behaviour of the system after changing the Mode A code when a flight plan is correlated to the relative track.

Execution: Correlate a flight plan to a track and after that ask the pilot to change the Mode A Code.

Result: Verify on the CWP that the flight plan is still correlated to the same track and the new SSR Code is presented on the lists of that flight plan. .

Note: None.


Page 50Mod.


Doc N.

Iss.

TST_CWP _7 Manual change of disseminator

Purpose: Verify that there is an automatic change of disseminator after a manual switch of radar disseminator in one CWP.

Execution: Chose a CWP that is disseminating a certain radar and perform the DSC command to another radar.

Result: Verify that the previous radar disseminated is not disseminating anymore and the new chosen radar is disseminating. Verify on the CWP’s that the radar data coming from the radar are displayed into 10 seconds.

Note: None.

TST_CWP _8 Meteo MAPS

Purpose: Verify the possibility to select the Meteo Maps on the CWP.

Execution: Select primary radar. From the LDA of the CWP, select the MAP Menu and choose one of the six Meteo Maps available.

Result: Verify on the CWP that the Meteo Maps are presented in base of what selected.

Note: The line has to be connected to the port of the RFE node in witch it is foreseen the Meteo Channel.

TST_CWP _9 Tracks presentation with the highest level of diagnostic enabled

Purpose: Verify that there is no lost of tracks presentation if the highest level of diagnostic is enabled.

Execution: From the CMS perform the following orders:

OT1 UDL 7 ALL

OTR DLD 7 ALL

Result: Verify on the CWP that there are not lost of data and on the CMS the highest level of diagnostic coming from the radar selected are displayed.

Note: None


Page 51Mod.


Doc N.

Iss.

5. TESTS RESULTS

All the results obtained during the acceptance tests are reported into the Tests Data Record contained in Annex 01- E184-02-1875ATP01TDR.


Page 52Mod.

Date post:	04-Jan-2016
Category:	Documents
Upload:	tibicomsa
View:	216 times
Download:	0 times

ATP Robustness

Documents