System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
SIEMENS TRAFFIC CONTROLS LIMITED
Sopers Lane,
POOLE, Dorset.
BH17 7ER.
SYSTEM/PROJECT/PRODUCT:
VAX/VMS UTC
SYSTEM TEST SPECIFICATION
FOR A
VAX/VMS UTC SYSTEM
 SIEMENS PLC 1995. All rights reserved.
The information contained herein is the property of Siemens PLC and is supplied without liability
for errors or omissions. No part may be reproduced or used except as authorized by contract or
other written permission. The copyright and the foregoing restriction on reproduction and use
extend to all the media in which this information may be embodied.
SYSTEST.DOC
Issue 11.0 Page 1-1
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
ISSUE STATE
Note :-
Source of documents is shown under Type as below.
1=Paper, 2=VAX, 3=Microfilm, 4=CALTEXT Disc, 5=DECmate Disc,
6=Paper Insert, 7=MAC Disc, 8=LIFESPAN, 9=SUN, 10=Other - add note.
Current Document Issue State: 08.00
The document comprises the following components :Module Name
Section
666YJ16940ZZ
Pages
Module
Issue
Type File Name
i - ix
08.00
8
SYS_TEST.WM
666YJ16940AA
1
1-2
08.00
8
SYS_TESTAA.WM
666YJ16940BA
2
1-3
08.00
8
SYS_TESTBA.WM
666YJ16940CA
3
1-9
08.00
8
SYS_TESTCA.WM
666YJ16940DA
4
1 - 31
08.00
8
SYS_TESTDA.WM
666YJ16940EA
5
1 - 22
08.00
8
SYS_TESTEA.WM
666YJ16940FA
6
1-9
08.00
8
SYS_TESTFA.WM
666YJ16940GA
7
1 - 71
08.00
8
SYS_TESTGA.WM
666YJ16940HA
8
1 - 60
08.00
8
SYS_TESTHA.WM
666YJ16940IA
9
1 - 46
08.00
8
SYS_TESTIA.WM
666YJ16940JA
10
1-2
08.00
8
SYS_TESTJA.WM
666YJ16940KA
11
1-6
08.00
8
SYS_TESTKA.WM
666YJ16940LA
12
1 - ??
08.00
8
SYS_TESTLA.WM
666YJ16940MA 13
1
08.00
8
SYS_TESTMA.WM
666YJ16940NA
1 - 53
08.00
8
SYS_TESTNA.WM
SYSTEST.DOC
14
Issue 11.0 Page 1-2
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
CONTENTS
1.
INTRODUCTION........................................................................................................... 1-1
1.1 Purpose........................................................................................................................ 1-1
1.2 Scope........................................................................................................................... 1-1
1.3 Related Documents ...................................................................................................... 1-1
2.
GENERAL DESCRIPTION ............................................................................................ 2-1
2.1 Introduction ................................................................................................................. 2-1
2.2 Approach ..................................................................................................................... 2-1
2.3 Assumptions ................................................................................................................ 2-1
2.4 System Configuration................................................................................................... 2-1
2.5 Data Configuration....................................................................................................... 2-2
2.6 Command Entry........................................................................................................... 2-3
3.
FUNCTIONAL TESTS ................................................................................................... 3-1
3.1 Introduction ................................................................................................................. 3-1
3.2 System Control and Configuration................................................................................ 3-1
3.3 Operator Facilities........................................................................................................ 3-2
3.4 System Data................................................................................................................. 3-3
3.5 Junction and Pelican Control and Monitoring ............................................................... 3-3
3.6 Other Street Equipment Control................................................................................... 3-5
3.7 Display, Status and Listing ........................................................................................... 3-6
4.
SYSTEM CONTROL AND CONFIGURATION TEST DEFINITIONS......................... 4-1
4.1 UTC System Start Up .................................................................................................. 4-1
4.2 UTC System Time ....................................................................................................... 4-1
4.3 Timetables ................................................................................................................... 4-4
4.4 CASTs....................................................................................................................... 4-10
4.5 Command Journal ...................................................................................................... 4-14
4.6 Software Integrity Faults............................................................................................ 4-16
4.7 Terminal Faults .......................................................................................................... 4-16
4.8 Operator Fault Clearance ........................................................................................... 4-18
4.9 Operator Reply Intervention....................................................................................... 4-19
5.
4.10
Data Transmission Faults - Message Transfer ......................................................... 4-20
4.11
System Log ............................................................................................................ 4-22
4.12
Temporary Disabling of Input and Output .............................................................. 4-27
OPERATOR FACILITIES TEST DEFINITION ............................................................. 5-1
SYSTEST.DOC
Issue 11.0 Page i
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
5.1 Command Entry........................................................................................................... 5-1
5.2 Dial Up Terminals ........................................................................................................ 5-8
5.3 Roving Terminal ........................................................................................................ 5-12
5.4 LAT Terminals........................................................................................................... 5-13
5.5 Wall map and System Indication Panel ....................................................................... 5-14
6.
DATA ENTRY TEST DEFINITIONS ............................................................................ 6-1
6.1 System Data................................................................................................................. 6-1
6.2 Terminal and User Data Preparation............................................................................. 6-5
6.3 Baseline Data ............................................................................................................... 6-6
7.
JUNCTION AND PELICAN CONTROL AND MONITORING TEST DEFINITIONS . 7-1
7.1 Junction interface ......................................................................................................... 7-1
7.2 Pelican Facilities......................................................................................................... 7-14
7.3 Master Cycle Counter ................................................................................................ 7-15
7.4 Signal Co-ordination by Fixed Time Plans .................................................................. 7-15
7.5 Plan Preparation and Amendment............................................................................... 7-21
7.6 Green Waves.............................................................................................................. 7-30
7.7 Manual Waves ........................................................................................................... 7-34
7.8 Automatic Plan Selection ........................................................................................... 7-36
7.9 Signal Co-ordination by SCOOT ................................................................................ 7-47
8.
7.10
Change and Display of SCOOT Parameters ............................................................ 7-50
7.11
SCOOT Translation Plans ...................................................................................... 7-65
7.12
Equipment Monitoring ........................................................................................... 7-68
7.13
Plan Compliance Faults .......................................................................................... 7-69
7.14
Controller Checks .................................................................................................. 7-73
OTHER STREET EQUIPMENT CONTROL TEST DEFINITIONS ............................ 8-80
8.1 Collection of Traffic data ........................................................................................... 8-80
8.2 Congestion Detection................................................................................................. 8-87
8.3 Car Park Information Sub-System .............................................................................. 8-89
8.4 Diversion Control System ........................................................................................ 8-108
8.5 Fog Detection .......................................................................................................... 8-121
8.6 SCOOT Detectors.................................................................................................... 8-121
8.7 Other Equipment Faults ........................................................................................... 8-124
8.8 Operator Control of Special Facilities....................................................................... 8-127
8.9 Tidal Flow Scheme Control...................................................................................... 8-128
9.
DISPLAY STATUS AND LISTINGS TEST DEFINITIONS.......................................... 9-1
SYSTEST.DOC
Issue 11.0 Page ii
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
9.1 Mono Displays............................................................................................................. 9-1
9.2 Colour Graphic Displays ............................................................................................ 9-21
9.3 Screen Dumps to Printer ............................................................................................ 9-30
9.4 Listings ...................................................................................................................... 9-31
9.5 Log OTU Replies to Disc........................................................................................... 9-34
9.6 Data File Archiving .................................................................................................... 9-36
9.7 Parameter Displays..................................................................................................... 9-38
9.8 SCOOT Event Driven Messages ................................................................................ 9-40
10. MAN-MACHINE INTERFACE TEST DEFINITIONS................................................. 10-1
10.1
Logging on and off to the System........................................................................... 10-1
10.2
Basic Window Manipulation................................................................................... 10-2
10.3
UTC Command Compatibility ................................................................................ 10-2
11. GRAPHICS EDITOR TEST DEFINITIONS................................................................. 11-1
12. HARDWARE AND POWER FAILURE TEST DEFINITIONS .................................... 12-1
12.1
System Re-start after H/W Crash............................................................................ 12-1
12.2
Disc Failure............................................................................................................ 12-1
12.3
System Re-start after Power Failure ....................................................................... 12-2
12.4
System Re-start after Power Failure - Networked Systems ..................................... 12-2
13. NETWORKED COMPUTERS TEST DEFINITIONS .................................................. 13-1
13.1
Introduction ........................................................................................................... 13-1
13.2
Networking Facilities ............................................................................................. 13-1
SYSTEST.DOC
Issue 11.0 Page iii
System Test Specification for a VAX/VMS UTC System
1.
INTRODUCTION
1.1
Purpose
666/YJ/16940/000
This document defines a procedure to test the requirements, operation and
performance of the VAX/VMS UTC system. The procedure tests the compliance of
the system against MCE 0360C (ref. 1.3.4(a)) and the system requirements (ref.
1.3.1(a)).
1.2
Scope
This document applies only to the VAX/VMS Baseline UTC system. The tests are to
be completed prior to the system being shipped. The tests are for the benefit of
project management only and to satisfy the Engineering department that the system is
acceptable for release from the factory; they do not represent any form of customer
acceptance testing.
A separate detailed test schedule exists for the SCOOT 2.4 subsystem (ref 1.3.2(b)).
This tests the operation of the SCOOT kernel and its interface with the UTC system.
A number of these SCOOT 2.4 tests appear unaltered in this document. They will be
accompanied by a reference and, in these schedules, they test certain SCOOT facilities
from the point of view of a UTC system incorporating SCOOT.
1.3
Related Documents
1.3.1
Parent Document
1.3.1(a)
666/UH/16940/000
Issue 3.0
1.3.2
Kindred Documents
1.3.2(a)
666/SN/16940/xxx
VAX/VMS UTC Factory Acceptance Test Schedule
1.3.2(b)
666/YJ/16066/038
SCOOT 2.4 Factory Release Test Schedule.
1.3.2(c)
666/UN/16940/xxx
VAX/VMS UTC Site Acceptance Test Schedule.
1.3.2(d)
666/HB/16940/xxx
VAX/VMS UTC Operators Handbook.
1.3.2(e)
666/HD/16940/xxx
VAX/VMS UTC Database Preparation Handbook.
1.3.2(f)
666/UH/16940/xxx
Customer Requirements Specification.
1.3.2(g)
666/SA/16066/027
Dial Up Terminals.
1.3.2(h)
666/SD/19507/000
Specification for Test Data for VAX UTC Systems
1.3.2(i)
667/SA/19529/000
SSDD for VAX/VMS Networked UTC System.
SYSTEST.DOC
Requirements Specification for a VAX/VMS UTC System,
Issue 11.0 Page 1-1
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
Where 'xxx' is the three digit number which uniquely identifies these documents on a
per system basis. '000' identifies the Baseline system.
1.3.3
Children Documents
None
1.3.4
Other Documents
1.3.4(a)
MCE 0360C
Specification.
Department of Transport. Urban Traffic Control - Functional
1.3.4(b)
666/KE/16066/000
UTC Glossary of Terms.
1.3.4(c)
666/SA/16066/038
SCOOT 2.4 Sub-system Design Document.
1.3.5
Abbreviations and Definitions
For a list of definitions used in association with STCL UTC systems see reference
1.3.4(b). For others see the glossary of terms in MCE 0360C, reference 1.3.4(a).
SYSTEST.DOC
Issue 11.0 Page 1-2
System Test Specification for a VAX/VMS UTC System
2.
GENERAL DESCRIPTION
2.1
Introduction
666/YJ/16940/000
This document specifies the Factory Test procedure for the VAX/VMS UTC system.
This procedure tests the ability of the software to drive the hardware and to respond
to inputs from the hardware. It represents the first stage in the system evolution in
which hardware and software are tested together.
This document incorporates some tests relating to the SCOOT subsystem which are
identical to tests in the SCOOT 2.4 FRT schedules. However they are included here
to test the UTC/SCOOT facility rather than the SCOOT Kernel.
UTC/SCOOT interface tests are included to test the ability of the SCOOT subsystem
to interface successfully with the fixed time UTC system. This test is included for the
same reason as in the SCOOT 2.4 FRT schedules.
In the main the tests apply to a single-computer UTC system i.e. a combined
TMC/TCC. Where applicable tests have been extended to cover facilities which are
valid for networked systems i.e. a Traffic Management Computer (TMC) and one or
more Traffic Control Computers (TCC). In addition a set of tests is included which
applies only to networked systems (see section ).
2.2
Approach
The approach taken throughout the tests is to initiate changes in the quiescent system
using an operator terminal or via external inputs e.g. vehicle detectors, and monitor
the results. This will done in one or more of the following ways :
(a) interrogating the system data,
(a) observing messages output on the system terminals,
(a) observing the changes in controller state, test boxes,
(a) observing the changes in "live update" pictures,
(a) using the MONI,DIPM and OVRB operator commands to monitor OTU control
and reply data and in the case of the OVRB facility to modify data.
(a) using the Instation Test Set (ITS) as for (e) above.
2.3
Assumptions
The basic assumptions for the start of system test are :
(a) all new software has been tested at module level in a stand-alone environment,
(a) all re-used software has been tested in a system environment,
(a) all hardware components have been tested in isolation,
(a) the data has been prepared and is available on the hard disc.
2.4
System Configuration
The hardware configuration for the system test procedure depends on the particular
system but should include a representative selection of equipment. The definitive list
SYSTEST.DOC
Issue 11.0 Page 2-1
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
for each system should be found in the CRS (Reference ). The list should also include
any controllers required for testing.
2.5
Data Configuration
The test data is defined in a separate document ref. .
Test data will have been created which will contain examples of all the features
required to perform system test. It should contain, at the minimum, the following
features:
• a timetable for every day of the week.
• a weekly and yearly timetable.
• 4 sub-areas/SCOOT regions.
• 4 green wave routes, to include at least 1 controller in each sub-area.
• 4 diversions.
• at least one controller configured with the DF bit.
• a number of controllers configured with the TTDAY option in the FBACK macro
in controller timings to restrict the number of checks which are executed as a result
of an operator command.
• three terminals:
1 off PC terminal
Command level = 16
Unsolicited output disabled
1 off VT320 or VT420
Command level = 7
Unsolicited output enabled
1 off VT320 or VT420 + LA75 Printer
Command level = 1
Unsolicited output enabled
• the following live update pictures:
one or two pictures showing representations of all the available test equipment, one of
the pictures containing the first and last controller IRNs.
For the SCOOT 2.4 tests the following additions to the database will be necessary:
(a) A single equipment node, for these tests a node with a single intersection.
(a) A multi-equipment node. For these tests the following multi-equipment node
must be set up:
Junction 1
A
BD
CN
AA
Node stages
1
2
3
+
Junction 2
A
B
ED
C
SYSTEST.DOC
Issue 11.0 Page 2-2
System Test Specification for a VAX/VMS UTC System
Node stages
1
2
3
666/YJ/16940/000
4
For each of the 4 stages requested by SCOOT the UTC system will calculate which
set of 'pseudo stages' must be run on the node. The possible 'pseudo stages' are as
follows:
(i) J1 = A
J2 = A
(i) J1 = B
J2 = B
(i) J1 = A
J2 = E
(i) J1 = C
J2 = E
(i) J1 = A
J2 = C
(i) J1 = C
J2 = C
Thus a request for SCOOT stage 3 may result in 'pseudo stage' c or d running,
depending on the demand at the junction 1. Similarly replies received from the
street indicating either of the 'pseudo stage' conditions c or d will be passed to
SCOOT as a confirmation of SCOOT stage 3.
(a) A node with a removable stage.
(a) A pair of nodes A and B with a normal link (a) between them, a further link
(b) is upstream of node B. Link (b) is defined as a congestion link for link (a).
(a) A filter link modelling a demand-dependent UTC stage.
(a) A filter link modelling a filter movement that is always given.
(a) A node where one or more links receive a "double green" during each cycle.
2.6
Command Entry
Use novice command entry to enter most commands. Check that suitable prompts are
output for fields. Check that invalid field types are identified as incorrect and a range
of valid input possibilities are output.
These tests demonstrate the ability to name a CAST, to add and delete commands
SYSTEST.DOC
Issue 11.0 Page 2-3
System Test Specification for a VAX/VMS UTC System
3.
FUNCTIONAL TESTS
3.1
Introduction
666/YJ/16940/000
The purpose of these tests is to ensure that the system will provide the facilities
required by MCE 0360C (ref. 1.3.4(a)) and the system requirements (ref. 1.3.1(a)).
The tests will be carried out on the equipment configuration as specified in
accordance with section 2.4.
The functional tests are, in the main, organised according to the sub-sections in the
requirements specification, MCE 0360C. The tests are ordered such that they
correspond with the order of the System Requirements Specification (ref. 1.3.1(a)).
Additional tests which deal specifically with networked systems are defined in section
3.2
System Control and Configuration
3.2.1
System Start-up
Section : 4.1
This test shows the ability of the system to start up in an orderly manner and run the
traffic system. It also tests the timetable optimisation process.
3.2.2
Time Setting
Section : 4.2
The tests in this section prove the compliance of the system with MCE 0360C,
requirement 7.3.
3.2.3
Simulator
Section : 4.3
This test verifies that the Outstation Simulator software is operating correctly so that
it may be used in subsequent tests.
3.2.4
Free Time
Section : 4.4
This test checks the limits of the operational capacity of the System.
3.2.5
Timetables
Section : 4.5
This test verifies the behaviour of timetables allowing them to be confidently used in
subsequent tests.
3.2.6
CASTs
Section : 4.6
These tests demonstrate the ability to name a CAST, to add and delete commands
from CASTS, and to list the contents of a CAST.
SYSTEST.DOC
Issue 11.0 Page 3-1
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
Tests are also included to show that CASTs may be actioned from the timetable or by
operator command.
3.2.7
Journal File
Section : 4.7
These tests prove the correct functioning of the journal system.
3.2.8
Reply analysis
Sections 4.8 to 4.12 and 4.14.
These tests prove the compliance of the system with MCE0360C, requirement 4.3.1.
The tests prove the ability of the system to detect and report faults in outstation reply
data, including the complete failure of data transfer to and from an outstation and
equipment faults on both junctions and pelicans.
The tests also prove the operator commands available to set faults, isolate and inhibit
reply analysis of equipment.
3.2.9
System Log
Section : 4.7
This test verifies that a continuous log is produced of all significant activity of the
System and that this log may be interrogated to determine the state of the System or
its components at a given time.
3.3
Operator Facilities
3.3.1
General Operator Interface
Section : 5.1
These tests prove the functions of command entry, command line editing and
selection, the rejection of invalid input and the output of an appropriate error
message. The terminal facilities as defined by the database are also proved along with
the snap shot printing facility associated with real time displays.
3.3.2
Dial-up Terminals
Sections : 5.2 and 5.3
These tests shows the capability of the system to handle terminals connected to the
system via an auto answer modem with special attention to the security aspects.
3.3.3
LAT Terminals
Section : 5.4
This test demonstrates the use of a terminal server to connect a UTC terminal to the
Traffic System.
3.3.4
Wall Map and Alarm Panel
SYSTEST.DOC
Issue 11.0 Page 3-2
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
Section 5.5.1
The wall map and Alarm panel facilities are tested here to prove the correct operation
of lamps and indicators for use in subsequent tests.
3.3.5
VDU Status Line
Section 5.5.2
This test demonstrates the ability of the status line to mimic the Alarm panel with
regard to system and operational alarms, and the watchdog.
3.4
System Data
3.4.1
Data Entry
Sections : 6.1 and 6.2
This test comprises a data preparation session using the DBAS operator command.
The data preparation handbook (ref. 1.3.2(e)) describes the use of this facility and
should be used when conducting the test.
The three aspects of the procedure - edit, preparation and build - are tested; invalid
data is introduced and this is rejected in the preparation phase; all source files are
amended in some way in order to produce new system data; the system is restarted
using the new data in order to observe the effects of the changes.
3.4.2
Baseline Data
Section : 6.3
This test demonstrates the ability to change certain operational parameters which are
part of the System Data but which are not entered during Data preparation.
3.5
Junction and Pelican Control and Monitoring
3.5.1
VA Detector Faults
Section : 7.1.1
The response of the System to Faults in the local VA detection of controllers is
checked.
3.5.2
Remote Reconnect
Sections : 7.1.2 and 7.1.3
The facility which allows a junction to be automatically reconnected and for its faults
to be cleared when an engineer attends the controller is checked.
3.5.3
Traffic Signal Control
Sections : 7.1.4 to 7.1.9
These tests demonstrate some facilities available on Controllers which may be
controlled by the System other than planed traffic control.
SYSTEST.DOC
Issue 11.0 Page 3-3
System Test Specification for a VAX/VMS UTC System
3.5.4
666/YJ/16940/000
Pelican Facilities
Section : 7.2
Facilities available on pelican controllers other than planned traffic control are tested.
3.5.5
Signal Co-ordination by Fixed Time Plans
Section : 7.4
These tests prove the compliance of the system with MCE 0360C, requirements 4.1,
6.3, 6.4, 6.5, 6.9.
In particular they prove the ability of the system to:
(a) store a number of plans (up to a pre-defined total).
(a) implement and cancel plans by timetable and by operator command.
(a) enable the operator to make temporary amendments to the plans.
(a) start/stop plans according to a pre-defined priority.
(a) initiate plan 0 for a controller operating in any mode.
The tests make use of the following operator commands PLAN XPLA LIPT DIPM VARY OFST LSTS
3.5.6
Plan Preparation and Amendment
Section : 7.5
These tests prove the ablity of the Traffic System to create and modify fixed-time,
SCOOT, green-wave and temporary plans for junction and pelican controllers.
3.5.7
Emergency Vehicle Priority
Section : 7.6
These tests prove the compliance of the system with MCE 0360C, requirement 4.4
(Green Waves). Green waves are started by operator command (GWAV) or by
remote request. The effect of the green wave on a number of controllers is monitored
using the MONI command.
The position of green waves in the priority hierarchy of plan types is tested.
3.5.8
Manual Waves
Section : 7.7
These test prove the ability of the Traffic System to execute manual waves.
3.5.9
Automatic Plan Selection
Section : 7.8
These tests prove the ability of the Traffic System to select a fixed time plan
according to data received from flow detectors.
3.5.10
Signal Co-ordination by SCOOT
SYSTEST.DOC
Issue 11.0 Page 3-4
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
Section : 7.9 to 7.11
These tests prove the compliance of the system with MCE 0360C, requirement 4.2.
The tests cover:
(a) implementing SCOOT control on a junction or a region by operator command
and timetable event.
(a) showing the priority of SCOOT plans with respect to fixed time plans.
The following operator commands are tested CHDC DCOU SCOO NODT REIN XSCO SSSU LLCF FLOW WEEK OPFD
3.5.11
Equipment Monitoring
Section : 7.12
These tests prove the ability of the Traffic System to constantly monitor juntion and
pelican controllers for their correct operation.
3.5.12
Plan Compliance
Section : 7.13
The ability of the System to monitor and report on whether controllers are following
plans correctly is tested.
3.5.13
Traffic Signal Controller Test Sequencing
Section : 7.14
These tests prove the compliance of the system with MCE0360C, requirement 4.3.2.
The tests prove that the controller monitoring routines will correctly identify faulty
controllers (i.e. controllers whose operational timings are different from those stored
in the computer).
3.6
Other Street Equipment Control
3.6.1
Count and Occupancy detection
Sections : 8.1.1 and 8.1.2
The various facilities relating to vehicle count and occupancy data collection and the
presentation of the data obtained are tested.
3.6.2
Data file Transfer to PC and Conversion
Sections : 8.1.3 to 8.1.5
This test proves the the capability of the system to transfer a file to a suitably
configured PC and converting to a database format.
3.6.3
Congestion Detection
Section : 8.2
SYSTEST.DOC
Issue 11.0 Page 3-5
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
This test proves the ability of the Traffic System to monitor the data received from
queue detectors.
3.6.4
Car Park Operation
Section : 8.3
This test proves the capability of the system to gather information from car park count
sites and to use this information to control variable message signs.
3.6.5
Diversions
Section : 8.4
These tests prove the compliance of the system with MCE 0360C paragraph 4.8
(excluding 4.8.5).
Diversion signs are introduced and removed by means of operator command (INTD,
REMD), timetable and remote request. The effect of faulty essential and non-essential
signs is tested.
3.6.6
Fog Detection
Section : 8.5
These tests prove the ability of the System to detect fog monitoring equipment and
adjust lamp intensity on configured controllers.
3.6.7
SCOOT Detector Faults
Section : 8.6
The ability of the System to monitor and report faults in SCOOT detectors is tested.
3.6.8
Other Equipment Faults
Section : 8.7
These tests deal with fault reports which are not dealt with under other headings.
3.6.9
Operator Control of Special Facilities
Section : 8.8
This test proves the the ability to call and cancel special facilities and to inhibit/enable
their use.
3.6.10
Tidal Flow Control
Section : 8.9
These tests prove the ability of the System to control tidal flow schemes.
3.7
Display, Status and Listing
3.7.1
Mono Graphic Displays
SYSTEST.DOC
Issue 11.0 Page 3-6
System Test Specification for a VAX/VMS UTC System
3.7.1(a)
666/YJ/16940/000
Monitoring and Testing
Sections : 9.1.1 to 9.1.5
These tests prove the compliance of the system with MCE 0360C, paragraph 4.3.4.
The tests use an operator command to monitor the control and reply data from any
selected OTU. Successful completion of these tests will enable the MONI, DIPM and
OVRB commands to be used extensively in subsequent tests.
3.7.1(b)
Validation displays
Sections : 9.1.6 to 9.1.13
These tests demonstrate the software available to assist in Validation and Fine tuning
of SCOOT Links, Nodes and Regions.
3.7.2
Picture Preparation and Display
Section : 9.2.1 to 9.2.4
The GENP command is used to create a pictorial representation of intersections and
other equipments using the procedure defined in the Operator's Handbook, (ref ).
The PICT command is used to call up the pictures created by the GENP command
and observations are made on the displayed data.
3.7.3
Time-Distance Display Diagram
Sections : 9.2.5 to 9.2.8
These tests check the operation of the TDDD facility.
3.7.4
VEGA Display
Sections : 9.2.9 and 9.2.10
This test checks the VEGA display of demand and queues on a link.
3.7.5
Automatic Display Cancelling
Section : 9.2.11
This test proves that displays may be configured to cancel automatically after a
specified time.
3.7.6
Screen Dumps to Printer
Section : 9.3
The ability of the System to make screen dumps to both monochrome and colour
printers is tested.
3.7.7
Listings
Sections : 9.4
This test tests the operator commands for listing traffic data to screens and printers.
SYSTEST.DOC
Issue 11.0 Page 3-7
System Test Specification for a VAX/VMS UTC System
3.7.8
666/YJ/16940/000
Log OTU
Section : 9.5
The facility for recording the control and reply data sent between the instation and
outstations is tested.
3.7.9
Archiving
Section : 9.6
The ability to archive certain data on magnetic tape for later retrieval and analysis is
tested.
3.7.10
SCOOT Parameter Displays
Section : 9.7
This test demonstrates the display of data from the SCOOT data areas.
3.7.11
SCOOT Event Driven Messages
Section : 9.8
This test demonstrates and tests the production of messages containing information
from the SCOOT algorithm.
3.7.12
Hardware and Power Failure
Section : 10
These tests prove the compliance of the system with MCE 0360C, requirement 7.
The ability of the system to recover from a number of power failure situations is
tested. The use of the journal file in recovering the state of the system prior to the
power failure is also tested.
3.7.13
Networked Systems
Section : 11
These are additional tests for a UTC System which consists a number of computers
linked together in a network. There are two possible configurations A Traffic Management Computer (TMC) and up to eight Traffic Control Computers
(TCCs),
A combined Traffic Management and Control Computer and up to eight further
Traffic Control Computers (TCCs).
SYSTEST.DOC
Issue 11.0 Page 3-8
System Test Specification for a VAX/VMS UTC System
4.
SYSTEM
CONTROL
DEFINITIONS
4.1
UTC System Start Up
AND
666/YJ/16940/000
CONFIGURATION
TEST
Reference : MCE 0360C paragraph 7.4, VAX SRS 2.4.1
T04-00100
Purpose:
Action:
Result:
To demonstrate the orderly start up of the traffic control system.
At the computer console restart computer.
The computer restarts and loads the traffic software and data
automatically and then starts the traffic system.
T04-00200
Purpose:
Action:
To re-start the UTC/SCOOT system in the middle of the day to test the
optimisation process of events in the timetable.
Ensure that a test timetable is available which contains a number of linked
and non-linked events. In particular it should contain the following (a) A PLAN event followed by an SCOO event; a CHCK event followed
by a LSTF event.
(a) A PLAN event followed by a XPLA event.
Re-start the system at a suitable time after the above events are due.
Result:
When the system starts, the timetable is optimised so that events which
"cancel each other out" are not executed, but unlike events are always
executed.
T04-00300
Purpose:
Action:
Result:
4.2
To demonstrate that SCOOT messages are disabled during start up.
Arrange for the System to be halted with SCOOT messages still running.
Restart the System.
The SCOOT messages are not restarted until the journal has been run.
UTC System Time
Reference : MCE 0360C paragraph 7.3 VAX SRS 2.4.2
4.2.1
General Tests
T04-00400
Purpose:
Action:
To demonstrate that invalid command lines for the TIME command are
rejected.
Enter the following commands (a) TIME 24:01
(a) TIME 16:00 29-FEB-87
SYSTEST.DOC
Issue 11.0 Page 4-1
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
(a) TIME 23:59 31-APR-89
(a) TIME 15:30 25 APR 88
(a) TIME 1200
(a) DATE 29-FEB-87
(a) DATE 31-APR-89
(a) DATE 31/11/89
(a) DATE 06/31/89
Result:
The commands will all be rejected with appropriate error messages.
T04-00500
Purpose:
Action:
Result:
Action:
Result:
To demonstrate the use of the TIME command to change the system date
and time.
Enter the current time and date with the TIME command. Use the TIME
command with no parameters to display the new time.
The system time is displayed correctly. If a clock display is connected to
the system this displays the same time.
Change the system time by more than 1 hour and 1 day using the TIME
command. Display the time using the TIME command.
The amended time is displayed correctly both on the terminal and on the
systems indication panel. If a clock display is connected to the system this
displays the same time. The timetable is re-scanned and the mode of
control appropriate to the time of day is implemented.
T04-00600
Purpose:
Action:
Result:
Action:
Result:
To demonstrate the use of the DATE command to change the system
date.
Enter the current date with the DATE command. Use the DATE
command with no parameters to display the new date.
The system date is displayed correctly. If a clock display is connected to
the system this displays the same time.
Change the system time by more than 1 week using the DATE command.
Display the time using the DATE command.
The amended date is displayed correctly. If a clock display is connected to
the system this displays the same time. The timetable is re-scanned and the
mode of control appropriate to the time of day is implemented.
T04-00700
Purpose:
Action:
Result:
SYSTEST.DOC
To show that the GMT to BST and BST to GMT changes are carried at
the date and time defined in the data.
Set the system time and date to 5 minutes before the GMT to BST change
as defined in the data.
At the defined time the system time is incremented by one hour. If a clock
display is connected to the system this displays the same time.
Issue 11.0 Page 4-2
System Test Specification for a VAX/VMS UTC System
Action:
Result:
666/YJ/16940/000
Set the system time and date to 5 minutes before the BST to GMT change
as defined in the data.
At the defined time the system time is decremented by one hour. If a clock
display is connected to the system this displays the same time.
T04-00800
Purpose:
Action:
Result:
To show that a fault is logged when there is a discrepancy between the
software an calendar clock and that the software clock is reset at 2am.
Before the time is changed start a stopwatch and record the traffic system
time at which it was started.
Using the DCL TIME command change the software clock's time, and
hence the traffic system time to shortly before 0200.
Display the time from the traffic system using #TIM both before and after
0200.
After at most one minute from changing the software clock a message is
output indicating the fault. This is recorded in the system log. LSTF will
show that the condition has been logged in the fault log.
At 0200 the software clock and hence the traffic system time is
resynchronised with the calendar clock. The new system time should be
the same as the time at which the software clock was initially changed
plus the elapsed time on the stopwatch. A message is output to the
System Log indicating by how much the two clocks differed. This should
be the same as the amount by which the software clock was initially
changed. If a clock display is connected to the system this displays the
correct time.
T04-00900
Purpose:
Action:
Result:
Action:
Result:
4.2.2
To check that the system caters automatically for leap years.
Set the time and date to 23:55 on 28-FEB-91. Allow the time to pass
through midnight.
The date changes to the 1-MAR-91.
Set the time and date to 23:55 on 28-FEB-92. Allow the time to pass
through midnight.
The date changes to 29-FEB-92.
Networked Systems
T04-01000
Purpose:
Action:
Result:
Action:
Result:
SYSTEST.DOC
To test that time and date updates are reflected on all computers in a
networked system.
Change the time and date at a terminal connected to the TMC.
The command is accepted and the time and date changed on the TMC. A
message is sent to all TCCs to reflect the new time and date. If a clock
display is connected to the system this displays the correct time.
Repeat the above action at a terminal connected to a TCC.
The time and date are changed as previously.
Issue 11.0 Page 4-3
System Test Specification for a VAX/VMS UTC System
Action:
Result:
Action:
Result:
4.2.3
666/YJ/16940/000
Kill the system on TCCA. Change the system time on the TMC and wait
for the new time to be distributed to all TCCs. Re-start TCCA.
TCCA is restarted with the correct system time.
Repeat the above action using the TMC.
As above.
Free Time Monitoring - General Tests
T04-01500
Purpose:
Action:
Result:
To monitor the free time available when the simulation system is running.
Run the free time monitoring software.
The free time on average shall be such that the performance requirements
for the system are met i.e.
(a) The system shall acknowledge operator commands within 3 seconds
of entry and commence data display within 6 seconds of the request.
(a) No more than 1% of SCOOT optimisation or SOFT actions shall be
missed in any one hour.
T04-01600
Purpose:
Action:
Result:
4.2.4
To monitor System performance when heavily loaded.
Use data containing the maximum number of facilities that the system is
designed for.
Arrange for the maximum number of simultaneous System facilities to be
active. This should include facilities which heavily load the System.
The System performance is not degraded below the results in the previous
test.
Free Time Monitoring - Networked Systems
T04-01700
Action:
Result:
4.3
Repeat the above sub-tests on all TCCs and the TMC.
As above.
Timetables
Reference : MCE 0360C paragraph 6.3, 6.5, 6.9, VAX SRS 2.4.4
4.3.1
OUTT Command - Invalid Command Lines
T04-01800
Purpose:
Action:
To prove that invalid command lines for the OUTT command are
rejected.
Enter the following commands (a) OUTT 21
SYSTEST.DOC
Issue 11.0 Page 4-4
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
(a) OUTT 1 2
(a) OUTT aaaaaa
where aaaaaa is an invalid SCN.
(a) OUTT bbbbbb 21
where bbbbbb is a valid SCN.
(a) OUTT cccccc 7 99:59-NOW where cccccc is a valid SCN
(a) OUTT WEAK
(a) OUTT YEER
Result:
4.3.2
The commands are all rejected with appropriate error messages.
Timetable Event Display
Reference: MCE 0360C paragraph 6.3, 6.5, 6.9, VAX SRS 2.4.4
T04-01900
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
4.3.3
To display the contents of any specified timetable.
Enter the command : OUTT
The current day's timetable is listed on the operators VDU. The entries
can be checked against the timetable data. A marker will indicate the next
due timetable event.
Enter the command : OUTT 1
Timetable number 1 is listed on the operators VDU. The entries can be
checked against the timetable data.
Enter the command : OUTT 20
Timetable 20 is listed on the operators VDU. The entries can be checked
against the timetable data.
Enter the command : OUTT WEEK
The list of timetables usually used for each day of the week are output.
Enter the command : OUTT YEAR
A list of the day of year timetables is output.
Modifying Timetables
Reference: VAX SRS 2.4.4
T04-02000
Purpose:
Action:
Result:
Action:
Result:
SYSTEST.DOC
To show that a timetable may be edited.
Enter data preparation using the DBAS command. Select options to edit a
time of day timetable. Add some valid and invalid events. Attempt to
prepare the timetable.
The timetable is not prepared and messages describing the reasons for
rejecting the invalid commands are output.
Remove the invalid actions. Re-prepare the timetable.
The timetable prepares successfully.
Issue 11.0 Page 4-5
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T04-02100
Purpose:
Action:
Result:
To show that a new timetable may be introduced while the system is on
line.
At a traffic prompt enter the command UPDA TIMETABLES.
The System is rescheduled according to the new timetables. The new
mode of control should reflect any differences in the new timetables.
T04-02200
Purpose:
Action:
To show that the timetables are rescheduled when the time is changed.
Change the using the TIME command in the following manners:
(a) To an earlier time on the same day
(a) To a later time on the same day
(a) To a previous day
(a) To a subsequent day
Result:
For each case the timetable which is valid for that time and date will be
scanned from the beginning to the specified time and the correct mode of
control implemented.
In each case listing the current timetable will show that the correct 'Next
Event' is being pointed to.
T04-02300
Purpose:
Action:
Result:
Action:
Result:
To show that all commands which should be available in timetables are.
Referring to the list of available timetable commands in the operators
handbook, create a timetable or set of timetables containing examples of
all available commands.
The timetables prepare correctly.
Allow the timetables to run and execute all the events. Make sure that the
System Log printer records all timetable activity.
All timetable commands are actioned and the responses correspond with
the recorded activity on the System log printout.
T04-02400
Purpose:
Action:
Result:
Action:
Result:
SYSTEST.DOC
To show that certain timetable events are only actioned when they occur
in real time.
Arrange for a timetable to run which contains commands which only
actioned in real time.
The events are actioned correctly.
Use the TIME command to change to a time before the commands in
question were actioned and then to change back to the correct time.
On moving forward in time the commands in question are not actioned as
the timetable is rescheduled.
Issue 11.0 Page 4-6
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T04-02500
Purpose:
Action:
Result:
To show that there is minimum delay between the scheduled time of a
timetable event and its actual implementation time.
Observe the delay between the scheduled time and the actual
implementation time as the timetable is executed.
The events are actioned at the nearest second to their scheduled time.
T04-02600
Purpose:
Action:
Result:
4.3.4
To show that timetable events scheduled for the same time are actioned in
the order in which they occur in the timetable.
Use a timetable with several events all scheduled for the s same time.
Observe the order of implementation and the delay between the scheduled
time and the actual implementation time as the timetable is executed.
The events scheduled for the same time will be actioned in the order in
which they occur in the timetable with a delay related to the number of
simultaneous events.
Networked Systems Timetables
T04-02700
Purpose:
Action:
Result:
4.3.5
To show that timetable events are only executed on the TCC to which
they are applicable.
Use a timetable with listing and control events which are only applicable
to one particular TCC, and other events which contain wild-card
equipment (the timetables are global to all TCCs and the TMC).
If an event does not apply to any equipment on a TCC then it is not
executed on that TCC.
Those events which contain wild-card equipment are executed on all the
relevant computers and are executed at the same time.
Day of Week and Day of Year Timetables
Reference: VAX SRS 2.4.4
T04-02800
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
SYSTEST.DOC
To show that the Day of Week timetable may be modified.
Use data preparation to modify the day of week timetable to use a
different set of time of day timetables. Include some errors. Attempt to
prepare the timetables.
The timetables are rejected with errors.
Correct the errors and re-prepare the timetables.
The timetables prepare successfully.
Enter an UPDA TIMETABLES command at a traffic prompt.
The new time of day timetable is implemented.
Issue 11.0 Page 4-7
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T04-02900
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
To show that the Day of Year timetable may be modified.
Use data preparation to modify the day of year timetable to use different
time of day timetables from those specified in the day of week timetable
on several days including the current day. Include some errors. Attempt to
prepare the timetables.
The timetables are rejected with errors.
Correct the errors and re-prepare the timetables.
The timetables prepare successfully.
Enter an UPDA TIMETABLES command at a traffic prompt.
The time of day timetable specified in the day of year rather than the day
of week timetable is implemented.
T04-03000
Purpose:
Action:
Result:
To show that the timetable is implemented correctly at UTC System start
up.
Kill the System using the KILL command. List the Operator Journal to
find the time of the last command. Allow enough time to elapse for a
number of timetable events to become due. Restart the system and
carefully note, using the System Log if necessary, the timetable events
which are actioned before the system reaches a quiescent state.
It should be found that only those timetable events scheduled to occur
after the time of the last Journal entry and before the current time are
actioned. The timetable is not actioned from the beginning.
T04-03100
Purpose:
Action:
Result:
To show what happens when the System cannot find a timetable on
startup.
Modify the data so there are no entry in the day of week or day of year
timetables for the current day. Clear the Journal and restart the System.
On restart all equipment remains under local control as can be shown by
LSTS commands.
T04-03200
Purpose:
Action:
Result:
To show that a new timetable is selected at midnight.
Change the time to close to midnight. Use an OUTT command to
determine the current timetable. Allow the System to pass through
midnight. Determine the current timetable again. Check the day of week
and day of year timetables.
The timetable changes and is consistent with the day of week and day of
year timetables.
T04-03300
Purpose:
SYSTEST.DOC
To show what happens when the System cannot find a new timetable at
midnight.
Issue 11.0 Page 4-8
System Test Specification for a VAX/VMS UTC System
Action:
Result:
4.3.6
666/YJ/16940/000
Modify the data so there are no entry in the day of week or day of year
timetables for the next day. Move the time to close to midnight.
At midnight a message indicating that the System cannot find a timetable
is output and all equipment remains under its existing state of control.
Substitution of Timetable
Note:
Before starting this sequence of tests the tester should ensure that a
different timetable has been constructed for each day of the week and that
these daily timetables are called by the Day-of-Week timetable. A
minimum of 5 daily timetables should be available.
T04-03330
Purpose:
Action:
Result:
Action:
To show that only valid timetable numbers are accepted by the SUTT
command and that invalid timetable numbers are rejected.
Ensure that a normal timetable is running on the System before starting
the sequence of tests by using the OUTT command.
Enter SUTT 'n' - where 'n' is an invalid timetable.
The system will reply "nominated timetable 'n' does not exist"
Enter SUTT 'n' - where 'n' is a valid timetable.
Use the OUTT command to check:
(a) the expected timetable is running
(a) timetable events have been actioned
(a) the next event is indicated
Result:
The system will change from the current timetable to the new timetable.
T04-03340
Purpose:
Action:
Result:
To show that a timetable which has been introduced using a SUTT
command is substituted by another timetable which is called by a
subsequent SUTT command.
Enter SUTT 'n' where 'n' is a valid timetable.
Use the OUTT command to check that the expected timetable is running.
Enter SUTT 'n' where 'n' is a valid timetable and is a different timetable
from that which was previously running.
Use the OUTT command to check that the expected timetable is running.
The System will change from the current timetable to the new timetable.
T04-03350
Purpose:
Action:
SYSTEST.DOC
To show that a timetable which has been introduced using a SUTT
command is cancelled by the XSUT command.
Enter SUTT 'n' where 'n' is a valid timetable.
Use the OUTT command to check that the expected timetable is running.
Enter XSUT.
Use the OUTT command to check that the expected timetable is running.
Issue 11.0 Page 4-9
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
The System will change from the current timetable to the timetable
specified in the Day-of-Week timetable.
T04-03360
Purpose:
Action:
Result:
To show that a timetable which has been introduced using a SUTT
command is replaced by the timetable which is specified by the Day-ofWeek timetable at midnight.
Enter SUTT 'n' where 'n' is a valid timetable.
Use the OUTT command to check that the expected timetable is running.
Change the System time to 23:59:00 using TIME command.
After the time has passed through midnight use the OUTT command to
determine the number of the currently running timetable.
When the time reaches 00:00:00, i.e. midnight, the timetable active will
change to the timetable called for by the current plan.
T04-03370
Purpose:
Action:
Action:
Result:
Action:
4.4
To show that a timetable which has been introduced using a SUTT
command is replaced by the timetable which is specified by the Day-ofWeek timetable for the current day after either a System restart or update.
Enter SUTT 'n' where 'n' is a valid timetable and is not the time table
specified in the Day-of-Week timetable for the current day.
Using the SUTT command change the current timetable to any valid
timetable. Use the OUTT command to ensure that the new timetable is
active. Halt the traffic System for a short period and initiate a restart.
When the system has restarted use the OUTT command and check that
the timetable called by the SUTT command is now no longer active and
the timetable running is the one appropriate to the current day of the
week.
Repeat the above test but rather than halting the System use the UPDA
command to cause a System re-start. Note that it will be necessary to
enter DBAS to modify a data item and re-prepare the data before issuing
the UPDA command.
CASTs
Reference : VAX SRS section 2.4.5
4.4.1
General Tests
T04-03400
Purpose:
Action:
SYSTEST.DOC
Demonstrate the ability to name and list a CAST.
Use the NCAS command and supply the relevant CAST number and
CAST name. Check that:
(a) A CAST name of up to 40 characters may be entered.
(a) The LCAS command shows that the CAST mnemonic is equal to the
CAST name up to the first space character.
(a) The CAST name may be changed several times.
Issue 11.0 Page 4-10
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
(a) A NCAS command with the same name as an existing CAST is
rejected.
(a) A CAST name may not begin with a numeric character.
Tests (a), (b) and (c) are successful. In tests (d) and (e) the command is
rejected.
T04-03500
Purpose:
Action:
Result:
Demonstrate the ability to insert entries into CASTS.
Using the ICAS command and with reference to the operators handbook
for commands allowed in CASTs perform the following tests:
(a) Enter new commands at the start of the CAST (specifying an entry
number of 0).
(a) Enter new commands in the middle of the CAST (specifying an entry
number in the middle of the existing range). Show that the new
command is entered after the entry number specified.
(a) Enter new commands at the end of the CAST (specifying no entry
number).
(a) Attempt to enter new commands with an entry number greater than
the highest existing entry.
(a) Use the LCAS command to check that the commands have been
entered correctly into the CAST. Use the ACAS command to check
that both the old and new commands are correctly actioned when the
CAST is run.
Tests (a), (b) and (c) are successful. The command in test (d) is rejected.
The new entries appear in the correct place in the CAST and are
successfully actioned when the CAST is executed, all the original entries
in the CAST are unaffected.
T04-03600
Purpose:
Action:
Result:
To show that commands entered into CASTs are checked for validity.
Attempt to enter a number of incorrect or malformed commands into
CASTs.
The commands are rejected.
T04-03700
Purpose:
Action:
SYSTEST.DOC
Demonstrate the ability to delete entries from CASTS.
Using the DCAS command perform the following tests:
(a) Delete a CAST entry at the start of the CAST (specifying an entry
number of 1).
(a) Delete a CAST entry in the middle of the CAST (specifying an entry
number in the middle of the existing range).
(a) Delete a CAST entry at the end of the CAST (specifying the highest
existing entry number).
(a) Attempt to delete a CAST entry which is outside the available range.
Issue 11.0 Page 4-11
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
(a) Use the LCAS command to check that the commands have been
deleted from the CAST. Use the ACAS command to check that the
deleted commands are not actioned when the CAST is run.
Tests (a), (b) and (c) are successful. The command in test (d) is rejected.
The deleted entries are no longer actioned when the CAST is executed.
T04-03800
Purpose:
Action:
Result:
To demonstrate that a CAST may be actioned either from the timetable or
by operator command.
Use the ACAS command directly to test the operator capability. Include
an ACAS command in the timetable to test the timetable capability. The
CAST should be identified by both its number and its mnemonic for each
case i.e. 4 tests in all.
The appropriate CAST is actioned in each case, all the commands are
consecutively actioned according to the CAST list. For timetable invoked
CASTs the CAST contents are optimised before it is actioned along with
other commands in the timetable, therefore if commands in the CAST
repeat commands already actioned in the timetable these will be optimised
out. Thus not all commands in the CAST may be actioned explicitly
although the overall effect will be to produce the system state required by
the CAST. The CAST is actioned at the appropriate time of day.
T04-03900
Purpose:
Action:
Result:
To demonstrate that all commands available in a CAST will be correctly
actioned from a CAST.
Use the ICAS command to insert the following commands with
appropriate parameters into a CAST or set of CASTs:
CHAN
CLOS
DEMA
DIMO
GULP
IHPC
MESS
OPEN
OPFD
PLAN
SCOO
SLOF
NODT
XDEM
XDIM
XGUL
XIHP
XMES
XPLA
XSCO
XSLO
Action the CAST or CASTs by operator command and check that each of
the commands is executed correctly.
All commands are executed correctly.
T04-04000
Purpose:
Action:
Result:
4.4.2
To show that commands which modify CASTs are not allowed in
timetables.
Attempt to include ICAS DCAS & NCAS commands in a timetable.
The CAST modifying commands are identified as being in error and the
timetable fails to prepare.
Networked Systems
Reference : VAX SRS 2.10.12
SYSTEST.DOC
Issue 11.0 Page 4-12
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T04-04100
Purpose:
Action:
Result:
To demonstrate that CAST data is global to the whole System.
Ensure that the TMC is on-line and links to all TCCs are "up". Modify
CAST 1 by entering ICAS, DCAS and NCAS commands at terminals
connected to the TMC and to each TCC. Following each command enter
an LCAS 1 command at all terminals.
Changes to the CAST database are reflected on all CPUs when the
commands have been accepted.
T04-04200
Purpose:
Action:
Result:
To demonstrate that CAST commands are rejected if the TMC is off-line.
Disconnect the TMC from the Ethernet. Enter ICAS, DCAS and NCAS
commands at terminals connected to each TCC.
The commands are all rejected.
T04-04300
Purpose:
Action:
Result:
Action:
Result:
To demonstrate that the CAST database is updated automatically when a
TCC is re-connected to the network, if the CAST data has been changed
whilst it was off-line.
Disconnect TCCB from the network. Enter ICAS, DCAS and NCAS
commands at terminals connected to TCCA and the TMC.
The commands are accepted and the new data is present on TCCA and
the TMC. A message is output to indicate that the update could not be
made on TCCB.
Re-connect TCCB.
The new CAST data is transferred to TCCB and is available immediately.
T04-04400
Purpose:
Action:
Result:
Action:
Result:
To demonstrate that CAST data is updated on a TCC following a re-boot.
Stop the UTC system on TCCA. Enter ICAS, DCAS and NCAS
commands at terminals connected to TCCB and the TMC.
The commands are accepted and the new data present on TCCB and the
TMC. A message is output to indicate that the update could not be made
on TCCA.
Re-start TCCA and list the CAST data.
The updated CAST data is now present on TCCA.
T04-04500
Purpose:
Action:
SYSTEST.DOC
To demonstrate that commands within a CAST are only executed on the
TCC controlling the specified equipment.
Create, or edit, a CAST with commands
(a) for equipment controlled by TCCA only,
(a) for equipment controlled by TCCB only,
(a) that are applicable only to the TMC,
Issue 11.0 Page 4-13
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
(a) for wild-card equipment controlled by a number of TCCs.
Execute the CAST from an operator terminal and from the timetable.
Commands are only executed on the TCC controlling the specified
equipment. Global commands are executed at the same time.
T04-04600
Purpose:
Action:
Result:
Action:
Result:
To demonstrate that CAST data may be validated on a remote computer.
Ensure that all computers are online. At a terminal connected to TCCB
enter CAST data specifying equipment on TCCA, TCCB etc. Both valid
and invalid data should be entered.
The data is validated and the CASTs are updated as appropriate.
Disconnect TCCB from the network. Repeat the above action.
Any data for TCCB is rejected with the message "No computer available
to process command".
4.5
Command Journal
4.5.1
Clear and List Journal File (CJNL & LJNL) Commands
Reference : VAX SRS section 2.4.6
T04-04700
Purpose:
Action:
To prove that the system rejects invalid command lines for the LJNL
command.
Enter the command lines (a) LJNL MO
(a) LJNL 5
Result:
The commands are rejected with appropriate error messages.
T04-04800
Purpose:
Action:
To list the commands in the journal file using the LJNL command.
Refer to the SMDD and the operator journal for a list of commands which
are written to the journal.
Amend the system time to 19:00.
Enter a series of operator commands of both journalled and nonjournalled type.
Refer to the timetable for other commands which should be written in the
journal.
Enter the command - LJNL
Result:
SYSTEST.DOC
The contents of the journal file is listed on the terminal. The contents can
be verified from the list in the SMDD. Events and commands will have
been "optimised" i.e. if 2 commands "cancel each other out" the first one
will not appear in the journal. Commands which have been optimised will
not have a time against them so they can be distinguished.
Issue 11.0 Page 4-14
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T04-04900
Purpose:
Action:
Result:
To show that a clear journal command is inserted in the journal when a
CJNL command is entered.
Enter : CJNL
Enter : LJNL
All commands have been removed from the journal.
T04-05000
Purpose:
Action:
Result:
Action:
Result:
4.5.2
To show that the Journal is optimised at midnight, when the Journal is
90% full and at startup.
Add commands to the Journal some of which cancel each other out.
Verify with LJNL that the commands appear in the journal. Also note that
commands appear at the beginning of the journal without times against
them. These are commands which have already been optimised
Let the System pass through midnight. List the journal again.
After the journal has been optimised all the remaining commands will not
have times against them and all commands which previously cancelled
each other out will have been rationalised. A message is output indicating
how full the journal is. This will usually be a small percentage of capacity.
Repeat this test for a journal which becomes 90% full and for a startup.
The Results are the same as before. for a start up it should be noted that
the commands in the journal are executed but not journalled. That is the
journal will not be found to be duplicated after is has been used.
Networked Systems Journal Files
Reference : VAX SRS 2.10.10
T04-05100
Purpose:
Action:
Result:
Action:
Result:
To demonstrate that journal files are local to each TCC and TMC.
(a) On each TCC enter an LJNL Hnnnnn command.
Each TCC has its own journal file and the entries in the journal refer to
local equipment or system-wide equipment only.
(b) List the journal file on TCCA from a terminal attached to the TMC
and one attached to TCCB, specifying the computer SCN for TCCA.
The file is listed as in (a).
T04-05200
Purpose:
Action:
Result:
To demonstrate that the journal file on the TMC is empty.
Enter an LJNL H99999 command at a TMC terminal.
The journal file is empty.
T04-05300
Purpose:
SYSTEST.DOC
To demonstrate that all journal files can be listed.
Issue 11.0 Page 4-15
System Test Specification for a VAX/VMS UTC System
Action:
Result:
4.6
666/YJ/16940/000
Enter an LJNL command at TCC and TMC terminals.
The journal files for all computers are listed in turn.
Software Integrity Faults
Reference : VAX SRS section 2.4.8
T04-05400
Purpose:
Action:
Result:
To prove that if the 'one second completion' process fails to run then the
system will stop transmitting to the OTUs.
Use the DCL command SHOW PROCESS SCHED to determine the
process ident of the one second process. Use the DCL command STOP
PROCESS/IDENT=xxxxxxxx, where xxxxxxxx is the process ident
obtained using the first command.
(a) The watchdog lamp is illuminated
(b) No control bits are sent to the OTUs.
(b) The MONI display is not refreshed
(b) The System time is not updated.
Action:
Result:
4.7
Re-start the traffic computer using the computer front panel.
The fault condition is removed.
Terminal Faults
Reference : MCE 0360C paragraph 7.10
VAX SRS 2.4.10
T04-05500
Purpose:
Action:
To confirm that the traffic systems continue to operate when a terminal is
faulty.
Simulate a terminal fault by switching off a terminal.
Wait for up to one minute until the system next tries to communicate with
this terminal.
Results : A warning message is output to the other terminals.
Action:
Result:
The remainder of the system operates normally.
Switch the terminal on again.
The terminal powers up and is again functional.
T04-05600
Purpose:
Action:
To observe the effect of unexpected/unsolicited control and other
characters while the hard copy printer is in the process of output.
Set the hardcopy printer to the following states, in turn,
(a) listing a source file,
(a) listing a MONI display,
SYSTEST.DOC
Issue 11.0 Page 4-16
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
(a) listing the system log,
(a) listing system messages i.e. SCOOT/UTC output.
Result:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
For each of the above states switch off the power to the printer.
No alarm is raised. Data is lost while the power is switched off. On
reconnecting the power, no recovery measures are necessary.
For each of the above states enter repeated CTRL-S commands.
The first command suspends the output; subsequent commands are
ignored.
Enter a CTRL-Q command within 40 seconds of the CTRL-S.
The listing re-starts; no data is lost while the CTRL-S was active.
For each of the above states switch the printer to off-line.
The data is lost. No system recovery procedures are required when the
printer is switched back to on-line.
For each of the above states arrange for the "paper-out" fault to occur and
leave the system in this state overnight.
The data is lost. No system recovery procedures are required when the
paper is re-loaded.
T04-05700
Purpose:
Action:
To observe the effect of unexpected/unsolicited control and other
characters while the colour VDU is in the process of output.
Cause the colour VDU to display in turn the following,
(a) a MONI display,
(a) a TDD display,
(a) a VEGA display,
(a) a live update picture (PICT command).
Result:
Action:
Result:
Action:
Result:
For each of the above switch off the power to the terminal.
No alarm is raised. Data is lost while the power is switched off.
For each of the above states enter repeated CTRL-S commands.
The first command suspends the output; subsequent commands are
ignored.
With the CTRL-S active, enter a CTRL-Q command.
The listing re-starts; no data is lost while the CTRL-S was active.
T04-05800
Purpose:
Action:
Result:
SYSTEST.DOC
To observe the effect of unexpected/unsolicited control and other
characters while the VT series VDU is in the process of output.
Repeat T04-05700 for the VT series VDU, using the monitor, plan
monitor and count detector flow displays .
As above.
Issue 11.0 Page 4-17
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T04-05900
Purpose:
Action:
Result:
Action:
Result:
To show that if the traffic computer goes 'down' whilst outputting a
VEGA display, the display terminal is set up correctly when the system
comes back on line. (When outputting a VEGA display, the terminal is
put into a different mode, which would not allow traffic commands to be
processed correctly).
Start a VEGA display as in the previous tests.
Halt the system.
The traffic computer goes 'down'.
Re-start the traffic computer.
Enter a traffic command at the terminal where the VEGA output was
previously displayed.
The command is actioned correctly, i.e. the terminal has been re-set to the
correct mode.
T04-06000
Purpose:
Action:
Result:
To attempt to print two simultaneous MONI displays (Ref. FAN 91).
Request two different MONI displays on two terminals. Press CTRL-P
simultaneously on both terminals.
Hardcopy prints are produced for both displays. One print is delayed until
the first has finished and the two are not interleaved.
T04-06100
Purpose:
Action:
Result:
4.8
To suppress output on all terminals simultaneously using CTRL-S
commands.
Activate some SCOOT messages to ensure that there is some output.
Enter a CTRL-S command on all terminals. Leave the system for at least
one hour.
The system continues to function whilst the terminals are disabled. Output
can be restored with the CTRL-Q command.
Operator Fault Clearance
Reference : VAX SRS 2.4.11
T04-06200
Purpose:
Action:
Result:
Action:
SYSTEST.DOC
To show that faults may be cleared from the System only on equipments
to which the terminal being used has access.
Modify the configuration for a terminal such that it does not have access
to all subareas. Introduce some faults on equipments in one of the
restricted subareas. Include faults which isolate linked equipment.
Attempt to clear the faults using XFLT on the terminal which does not
have access to the subarea in which the faults exist.
The XFLT commands are rejected.
Move to a terminal which has access to all subareas or modify the
configuration of the present terminal. Check which faults exist in the fault
Issue 11.0 Page 4-18
System Test Specification for a VAX/VMS UTC System
Result:
4.9
666/YJ/16940/000
log. For a given equipment determine, from the timetable and journal, its
state of control if there were not a fault on it. Remove the fault and clear
it on the System using XFLT.
The fault is cleared in the fault log. A message that the fault has been
cleared is output to the terminal and the system log. The equipment is
returned to its currently requested mode of operation. If other linked
equipments were isolated then they are also returned to control.
Operator Reply Intervention
Reference : VAX SRS 2.4.11
T04-06300
Purpose:
Action:
Result:
To prove that an intersection can be isolated by operator command.
Enter the ISOL command for a controller which has no faults currently
reported against it and is currently under control ie. stage force bits are
being sent to it.
The controller is isolated and the force bits are no longer sent to it.
T04-06400
Purpose:
Action:
Result:
To prove that an intersection isolated by operator command and can be
de-isolated by operator command.
Enter the XISO command for a controller which was previously isolated
by operator command.
The controller is de-isolated and normal control is resumed.
T04-06500
Purpose:
Action:
To show that the operator may report faults against an equipment by the
use of the FLTY command.
Repeat for a selection of equipment types and fault categories.
a) Enter:
FLTY aaaaaa bbb
where aaaaaa is an equipment SCN and bbb is a fault
category (see ref for details)
b) Enter:
Result:
Action:
Result:
LSTF aaaaaa where aaaaaa is as above
Each fault is set against the equipments and is displayed when the LSTF
command is entered unless automatically cleared by the system ie.
transmission faults.
For each fault set enter:
XFLT aaaaaa 0
where aaaaa is as used above
The operator imposed faults are removed.
T04-06600
Purpose:
SYSTEST.DOC
To prove that the analysis of replies from an equipment can be inhibited
by operator command.
Issue 11.0 Page 4-19
System Test Specification for a VAX/VMS UTC System
Action:
Result:
Action:
Result:
Action:
Result:
4.10
666/YJ/16940/000
Repeat for a selection of equipment types
(a) Enter:
IHRW aaaaaa where aaaaaa is an equipment SCN.
(a) Cause a fault to occur on that equipment ie. extended inter-green for
an intersection
No faults are reported against the equipments.
For each equipment used above
(a) remove the fault
(a) enter XIHR aaaaaa
where aaaaaa is as above.
(a) re-introduce the fault
The fault is reported.
For each fault introduced above, remove the cause of the fault and clear
the fault by operator command
The fault entry is removed from the log.
Data Transmission Faults - Message Transfer
References : MCE 0360C paragraph 4.3.1.2, 4.3.1.3 and VAX SRS section 2.4.12
T04-06700
Purpose:
Action:
To check what happens when there has been a complete OTU failure for 3
or more seconds.
(a) Use the command MONI to check that control and reply bits are
being sent and received correctly from a chosen OTU.
(b) Use the command LSTF to check that no faults are currently
recorded for this piece of equipment.
(b) Simulate a complete OTU failure by switching off the OTU mains
supply for at least 3 seconds.
(b) Repeat the LSTF command within 30 seconds of reconnecting th
OTU to confirm the fault has been logged.
Result:
(a) The MONI display shows the failure of the OTU replies for the
disconnection period.
(b) Control equipment on this OTU is isolated.
(b) The corresponding white wall map lamp(s) change to flashing.
Action:
Result:
Wait 30 seconds
The OTU is re-connected.
T04-06800
Purpose:
Action:
SYSTEST.DOC
To check what happens when there has been intermittent OTU
transmission failures for 15 seconds in any one 3 minute period.
(a) Use the command MONI to check that control and reply bits are
being sent and received correctly from a chosen OTU.
Issue 11.0 Page 4-20
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
(b) Use the command LSTF to check that no faults are currently
recorded for this piece of equipment.
(b) Simulate an intermittent OTU failure by switching off the OTU mains
supply for periods of less than 3 seconds to give an accumulated total
of 15 seconds of failure in a 3 minute period.
(b) Repeat the LSTF command within 3 minutes of reconnecting the
OTU to confirm the fault has been logged.
Result:
(a) The MONI display shows the failure of the OTU replies for 3
seconds.
(b) Control equipment on this OTU is isolated.
(b) The corresponding white wall map lamp(s) change to flashing.
Action:
Result:
Wait 3 minutes.
The OTU is re-connected.
T04-06900
Purpose:
Action:
To show what happens when there have been intermittent OTU failures
for 15 seconds in a 1 hour period.
(a) Use the command MONI to check that control and reply bits are
being sent and received from a chosen OTU.
(b) Use the command LSTF to check that no faults are currently
recorded for this piece of equipment.
(b) Simulate an intermittent OTU failure by disconnecting the
transmission line to the OTU for up to 2 seconds.
(b) Repeat this with a 3 minute interval between each disconnection, until
15 intermittent OTU failures have occurred.
Result:
(a) The MONI display shows the intermittent failure of the OTU replies.
(b) Once 15 one second failures have been counted an appropriate
message is output on the terminals.
(b) Control equipment on this OTU is isolated.
(b) The corresponding wall map lamps change to flashing white.
T04-07000
Purpose:
Action:
Result:
To show what happens when OTU transmissions are restored following
an occasional intermittent OTU failure.
Leave the transmission line connected for 1 hour and use the command
LSTF to check that the fault has been cancelled.
After 1 hour, a fault cleared message is output and the fault cleared from
the current log.
T04-07100
Purpose:
SYSTEST.DOC
To show what happens when there have been intermittent OTU failures
for less than 15 seconds in a 1 hour period.
Issue 11.0 Page 4-21
System Test Specification for a VAX/VMS UTC System
Action:
666/YJ/16940/000
(a) Use the command LSTF to check that no faults are currently
recorded for the OTU to be tested.
(b) Simulate an intermittent OTU failure by disconnecting the
transmission line to the OTU for up to 2 seconds. Repeat this 2 or 3
times with at least 4 minutes between each disconnection.
(b) Using the LTEC command examine the transmission fault count for
the OTU.
Result:
(a) No fault message is output on the terminals when the transmission
faults occur.
(b) Control equipment on this OTU is not isolated.
(b) The corresponding wall map lamps are unchanged.
(b) The fault count for the OTU is less than 15.
T04-07200
Purpose:
Action:
Result:
To show that the time values in the above tests are configurable.
Change the time values for reporting and clearing data transmission faults
in the database. Repeat the tests T04-06700 to T04-07100.
The various time values change to those requested.
T04-07300
Purpose:
Action:
Result:
To show that a transmission error report is produced every hour.
Cause some transmission errors to occur but not enough to cause an
isolation.
One the next hour a list will be output indicating the OTUs which have
had transmission errors in the last hour and the number of such errors.
T04-07400
Purpose:
Action:
Result:
To show what happens if an F bit remains constant for three minutes.
Using OVRB or the Simulator arrange for an F bit for an outstation under
control to remain constant for 3 minutes.
After 3 minutes the outstation is isolated.
T04-07500
Purpose:
Action:
Result:
4.11
To show what happens if 3 permanent F bit faults are present at any
instant in time.
Using OVRB or the Simulator arrange for F bit on each of 3 outstations
under control to remain constant for 3 minutes.
The reinitialisation of the watchdog will cease and therefore all
communication with on street equipment will cease.
System Log
Reference : VAX SRS 2.4.13
SYSTEST.DOC
Issue 11.0 Page 4-22
System Test Specification for a VAX/VMS UTC System
4.11.1
666/YJ/16940/000
General Tests
T04-07600
Purpose:
Action:
Result:
To demonstrate that all operator commands affecting the control and
operation of on-street equipment and all System messages are recorded in
the System Log.
(a) At a traffic terminal with a directly attached printer enter a selection
of commands some of which affect the control of on street equipment
and some of which do not.
(b) Cause faults to occur on the test controllers or by use of OVRB.
Analyse the hardcopy of the log for the period of the test.
(a) All valid operator commands which affect the control and operation
of on street equipment will appear in the Log together with the
number of the terminal on which each was entered.
(a) Commands which do not affect system control, for instance display
commands, do not appear in the Log.
(a) The response to operator commands is not recorded in the log.
(a) All fault messages that appeared on the operators terminal appear in
the Log together with the day, time, SCN, location or type of
equipment, fault category and message text.
(a) All unsolicited information messages that appeared on the operators
terminal appear in the Log with the day, time and message text.
(a) The last time the System was restarted a message appears in the Log
including the day, time and date.
T04-07700
Purpose:
Action:
Result:
Action:
Result:
To show that sensible action is taken if the Log becomes full.
Arrange for the space available for the Log to become almost full.
A warning message is output to the operator.
Determine the oldest entry in the log. Add entries until the log wraps
around.
The oldest entries are deleted and the latest entries are included.
T04-07800
Purpose:
Action:
Result:
To observe what happens when the specified limit for the storage of log
files is reached.
Arrange that log files exist back to the earliest date allowed. modify the
time forwards to the next day and allow the System to pass through the
time at which file deletions are made.
A message is output stating which log file has been deleted.
T04-07900
Purpose:
SYSTEST.DOC
To show that the System Log may be listed in whole or by various parts.
Issue 11.0 Page 4-23
System Test Specification for a VAX/VMS UTC System
Action:
666/YJ/16940/000
Enter the following commands:
(a) LOGO
(a) LOGO date
Where date is a date before today but later than the
date the configured number of days in the database for retaining data
before that.
(a) LOGO date Where date is a date before today and earlier than the
date the configured number of days in the database for retaining data
before that.
(a) LOGO time1-time2
Where time1 is a time in the past and time2
is another time between the first time and now.
(a) LOGO value Where value is a fault category.
(a) LOGO utcscn
(a) LOGO scscn
(a) LOGO utcscn value
(a) LOGO utcscn date
(a) LOGO utcscn time1-time2
(a) LOGO value date
(a) LOGO value time1-time2
(a) LOGO date time1-time2
(a) LOGO utcscn value date
(a) LOGO utcscn value time1-time2
(a) LOGO utcscn date time1-time2
(a) LOGO value date time1-time2
(a) LOGO utcscn value date time1-time2
(a) LOGO scscn value
(a) LOGO scscn date
(a) LOGO scscn time1-time2
(a) LOGO scscn value date
(a) LOGO scscn value time1-time2
(a) LOGO scscn date time1-time2
(a) LOGO scscn value date time1-time2
Result:
The following output should be produced in each case :
(a) The log for the current day up to the current time.
(a) The entire log for the specified date.
(a) A message indicating that there is no data for the specified date.
(a) The log for the current date between the specified times.
SYSTEST.DOC
Issue 11.0 Page 4-24
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
(a) All log entries for the current day referring to the specified fault
value.
(a) All log entries for the current day referring to the specified UTC
SCN.
(a) All log entries for the current day referring to the specified SCOOT
SCN.
(a) Entries referring to both the specified UTC SCN and fault value.
(a) Entries referring to the specified UTC SCN on the specified date.
(a) Entries referring to the specified UTC SCN between the specified
times on the current date.
(a) Entries referring to the specified fault value on the specified date.
(a) Entries referring to the specified fault value between the specified
times on the current date.
(a) All entries on the specified date between the specified times.
(a) Entries referring to the specified UTC SCN together with the
specified fault value on the specified date.
(a) Entries referring to the specified UTC SCN together with the
specified fault value between the specified times on the current date.
(a) Entries referring to the specified UTC SCN between the specified
times on the specified date.
(a) All entries on the specified date between the specified times referring
to the specified fault value.
(a) Entries referring to the specified UTC SCN together with the
specified fault value between the specified times on the specified date.
(a) Entries referring to both the specified SCOOT SCN and fault value.
(a) Entries referring to the specified SCOOT SCN on the specified date.
(a) Entries referring to the specified SCOOT SCN between the specified
times on the current date.
(a) Entries referring to the specified SCOOT SCN together with the
specified fault value on the specified date.
(a) Entries referring to the specified SCOOT SCN together with the
specified fault value between the specified times on the current date.
(a) Entries referring to the specified SCOOT SCN between the specified
times on the specified date.
(a) Entries referring to the specified SCOOT SCN together with the
specified fault value between the specified times on the specified date.
If at any point a system halted or restarted message appears in the log
then the keyboard bell will sound.
SYSTEST.DOC
Issue 11.0 Page 4-25
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T04-08000
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
4.11.2
To show that System Log files may be archived and retrieved.
Using VMS transfer a selection of stored System Log files from the
System disc onto tape.
The files are successfully transferred.
Allow the System to automatically delete the stored log files from disc.
Attempt to do a LOGO command for the deleted files.
The data is no longer available.
Using VMS Transfer System Log files from tape back to the System disc.
Display a Log using the LOGO command.
The Log data is again available.
Networked Systems
Reference : VAX SRS 2.10.9
T04-08100
Purpose:
Action:
Result:
To demonstrate the storage of the System log on the TMC.
With the TMC on-line and linked to both TCCA and TCCB, enter a DCL
command
to
inspect
the
System
Log
file
directory,
UTC_OUTPUT:[SYSTEM_LOG], at a terminal connected to TCCA .
There is no current log file (SYSTEM.LOG) present.
T04-08200
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
To demonstrate the storage of the System log on the TMC.
(a) Enter a LOGO command for the current day at a terminal connected
to TCCA .
The System Log entries for the current day are listed out. There are
entries for equipment in sub-areas and regions controlled by both TCCA
and TCCB.
(b) Repeat the LOGO command for the current day at a terminal
connected to TCCB.
The listing is the same as that in (a), above.
(c) Enter a LOGO command for the previous day at a terminal connected
to TCCA.
The System Log entries for the previous day are listed out. There are
entries for equipment in sub-areas and regions controlled by both TCCA
and TCCB.
T04-08300
Purpose:
Action:
Result:
SYSTEST.DOC
To demonstrate the storage of the System Log when the TMC is offline.
Disconnect the TMC. Execute commands and timetable events on the
TCCs which would cause messages to be written to the system log.
Since the TMC is offline the messages are not put in the system log (it is
not possible to interrogate the local logs on the TCCs).
Issue 11.0 Page 4-26
System Test Specification for a VAX/VMS UTC System
Action:
Result:
Action:
Result:
666/YJ/16940/000
Re-connect the TMC.
All messages which were stored on the TCCs are transferred to the TMC
and are printed on the System Log printer as they are received on the
TMC.
Enter a LOGO command on the TMC, TCCA and TCCB to list the
current days entries.
All messages, including those which were added when the TMC was
offline are present, although they may not be in chronological order.
T04-08400
Purpose:
Action:
Result:
To demonstrate that local log storage is secure on a TCC.
Repeat the above test and whilst the TMC is offline reboot one of the
TCCs.
As above, all the log messages are stored on the TCC and are transferred
when the TMC is re-connected.
4.12
Temporary Disabling of Input and Output
4.12.1
MAIN/OFFC COMMANDS
T04-08500
Purpose:
Action:
Result:
To prove that the OFFC command causes all terminals to ignore all input
except the MAIN command.
Issue OFFC command.
All commands issued from any terminal, other that MAIN, are rejected.
T04-08600
Purpose:
Action:
Result:
To prove that the OFFC command turns off the wall map display.
Monitor the wall map display memory area using the WALLDIS program
and check that the display of wall map data is being updated correctly.
Issue OFFC command.
All wall map display bits should be set to zero and remain so.
T04-08700
Purpose:
Action:
To prove that the MAIN command, when issued after an OFFC
command, causes all terminals to accept normal command input.
(a) Issue OFFC command.
(b) Issue MAIN command.
(b) Type in a variety of commands from each terminal connected to the
System.
Result:
SYSTEST.DOC
All commands issued from any terminal should be accepted.
Issue 11.0 Page 4-27
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T04-08800
Purpose:
Action:
To prove that the MAIN command, when issued after an OFFC
command, turns on the wall map display.
(a) Monitor the wall map display memory area using the WALLDIS
program and check that the display of wall map data is being updated
correctly.
(b) Issue OFFC command.
(b) Issue MAIN command.
Result:
4.12.2
All wall map display bits should be updated as normal after the MAIN
command has been issued.
TROF/XTRO Commands
T04-08900
Purpose:
Action:
Result:
To verify that the TROF command disables the output of System
(unsolicited messages) to the specified terminal.
Select a terminal or printer which is outputting System messages.
Issue a TROF Txxxxx command (where Txxxxx is the SCN of the
selected terminal device).
The System output ceases.
T04-09000
Purpose:
To verify that the XTRO command re-enables the output of System
messages after a TROF command has been issued.
Action:
Select a terminal or printer which is outputting System messages.
Issue a TROF Txxxxx command (where Txxxxx is the SCN of the
selected terminal device).
After output has ceased issue a XTRO command.
The System output resumes.
Result:
SYSTEST.DOC
Issue 11.0 Page 4-28
System Test Specification for a VAX/VMS UTC System
5.
OPERATOR FACILITIES TEST DEFINITION
5.1
Command Entry
5.1.1
Operator Facilities
666/YJ/16940/000
Reference : VAX SRS section 2.5.1
T05-00100
Purpose:
Action:
Result:
To show that commands at the $ prompt are passed to the operating
system which gains use of the terminal until its processing is finished.
Use a selection of VMS commands at a traffic terminal.
The Commands behave in the same manner as though the traffic System
were not there although there may be some reduction in processing speed.
Output on the terminal from VMS is not interrupted by traffic System
output.
T05-00200
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
To show what happens when command entry is interrupted by output.
To produce a large amount of output start an M35 message for a node.
Output is produced every second.
Type a prompt and wait.
The prompt remains on an otherwise blank line above the status line for a
certain amount of time after which the input line starts to scroll up the
screen the bottom line is used for display.
Attempt to enter a command without first issuing a prompt.
The keystrokes are rejected with a bell.
Enter a prompt and an incomplete command and again wait.
The input line scrolls up the screen after a while and the command entry is
aborted.
Enter a prompt and a complete command line.
The message output will scroll above the input line.
Use Return to send the command to the System.
The input line will scroll up with the rest of the screen. There may be
several lines of output before an 'ACCEPTED' message is produced.
T05-00300
Purpose:
Action:
SYSTEST.DOC
To prove that invalid command mnemonics are rejected by the system.
At the operators terminal enter the following commands (a) a selection of 4 letter mnemonics that do not appear in the list of valid
commands in the Operators Handbook (ref. ) or form a part of the
alternative "standard" command list,
(a) a selection of 2 and 3 letter mnemonics,
Issue 11.0 Page 5-1
System Test Specification for a VAX/VMS UTC System
Result:
Action:
Result:
666/YJ/16940/000
All the commands are rejected and an error message is written to the
terminal.
(a) Invalid commands are not echoed to any other terminal.
(a) The command lines are not written in the journal file (use the LJNL
command to confirm this).
At the same terminal enter a selection of 4 letter mnemonics that contain at least 1 control character,
a selection of 4 letter mnemonics that contain at least 1 escape sequence.
The escape and control sequences are not accepted and are rejected with
a bell. Any command mnemonics which are valid otherwise will be
accepted and actioned.
T05-00400
Purpose:
Action:
Result:
To show that the Traffic System accepts commands in both upper and
lower case.
Enter a selection of valid traffic commands in both upper and lower case
and a mixture of upper and lower case.
All the commands are accepted and actioned irrespective of case.
T05-00500
Purpose:
Action:
Result:
To show that error messages are given for incomplete commands issued
at the the expert prompt.
Enter a selection of commands at the expert prompt which have missing
parameters.
The commands are rejected as incomplete.
T05-00600
Purpose:
Action:
Result:
To prove that spurious characters are not generated by mechanical
actions.
Unplug and re-attach the terminal keyboard.
The actions do not generate characters on the command line.
T05-00700
Purpose:
Action:
Result:
Action:
Result:
SYSTEST.DOC
To change the "mode" of a PC terminal whilst typing a command line and
prove that this action does not have an adverse effect on the system.
Enter part of a valid command line; change the terminal set up via ALT-S
and put the terminal into VT100 mode.
Return to Techex mode via ALT-S.
The command line is re-displayed in its previous state.
Complete the command line and hit ENTER.
The command is accepted as displayed on the screen i.e no "hidden"
characters have been introduced into the command line by the action of
entering the alternate mode.
Issue 11.0 Page 5-2
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T05-00800
Purpose:
Action:
Result:
Action:
Result:
To prove that a terminal/user can only enter and have accepted those
commands whose command level is less than or equal to the command
level assigned to the terminal/user. The commands and their command
levels are defined in ref .
At each terminal enter the commands at or below the command level
assigned to that terminal, or to the user logged on to the terminal.
Each command is accepted and action is taken by the system.
At each terminal enter the commands above the command level assigned
to that terminal, or to the user logged on to the terminal.
Each command is rejected and the system takes no action.
T05-00850
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
To show that the operator can list the facilities and commands available to
which he has access.
At the traffic prompt enter the command :
INFO
A list of available facilities and commands is displayed.
Enter a number of these commands.
Enter a number of commands that are not available on this terminal.
The commands are accepted.
The commands are rejected.
Enter the following commands :
INFO Tnnnnn
INFO user-id
where :
nnnnn
is a valid terminal SCN
user-id
is a valid user id
The commands and facilities for both are displayed.
T05-00900
Purpose:
Action:
Result:
Action:
Result:
SYSTEST.DOC
To prove that a terminal can be configured not to display unsolicited
output.
Generate a fault either by use of test hardware or by the operator
command FLTY.
The fault is reported immediately on the hardcopy output device and on
those terminals configured for unsolicited output. No output is generated
on the terminal configured for solicited output only.
If the terminal is configured for unsolicited output, but does not have a
user currently logged on, then no output is generated on the terminal.
On the terminal list the current unacknowledged faults using the LSTA
command.
The fault reported for the OTU above appears in the output.
Issue 11.0 Page 5-3
System Test Specification for a VAX/VMS UTC System
5.1.2
666/YJ/16940/000
Logging-on to the Traffic System
Reference: VAX SRS 2.5.3
T05-01000
Purpose:
To demonstrate the actions necessary to gain access to the System
through a password protected terminal.
Action:
(a) Using any directly connected terminal, which is not defined in the
Terminal data, and is not currently logged-on to the Traffic System,
press <CR>.
Result:
The System responds with the prompt "Enter Username :"
Action:
(b) Enter an invalid Username and/or password.
Result:
The data is rejected and the prompt "Enter Username :" is re-displayed.
Action:
(c) Enter a valid Username and password.
Result:
The data is accepted.
The current system "logo" is displayed and unsolicited messages start to
appear on the terminal screen.
An entry is written in the system log with the dynamic terminal SCN and
the User.
Action:
(d) Enter a WHAT T00000 command.
Result:
All the directly connected terminals and remote terminals with Users
currently logged in are listed, including the local terminal. User names are
listed where appropriate.
T05-01100
Purpose:
Action:
Result:
To demonstrate that the terminal type is identified correctly.
At the terminal used in T05-01000 above, enter display commands e.g.
PICT, VEGA, MONI, DIPM, TDDD, and check that the display appears
correctly on the screen.
The system identifies a PC and a VT-series terminal correctly.
T05-01200
Purpose:
Action:
Result:
To demonstrate that output can be re-directed to a newly-logged in
terminal.
At a different terminal enter listing commands to re-direct output to the
terminal used above.
The listings appear on the correct terminal.
T05-01300
Purpose:
Action:
Result:
SYSTEST.DOC
To demonstrate that SCOOT event driven messages can be re-directed to
a newly-logged in terminal.
At a different terminal start a number of SCOOT event driven messages
on the terminal used above.
The messages appear on the correct terminal.
Issue 11.0 Page 5-4
System Test Specification for a VAX/VMS UTC System
5.1.3
666/YJ/16940/000
Logging-off the Traffic System
Reference: VAX SRS 2.5.3
T05-01400
Purpose:
To demonstrate the actions necessary to exit the System through a
password protected terminal.
Action:
(a) At the terminal used above, enter an ENDS command.
Result:
A log-off message appears on the terminal.
An entry is written in the System Log to indicate that the user has logged
off.
No further unsolicited messages appear on the terminal.
Action:
(b) At another terminal enter a WHAT T00000 command.
Result:
The list of terminals does not include the one used in (a).
T05-01500
Purpose:
Action:
Result:
To demonstrate that output cannot be re-directed to a logged off terminal.
At a different terminal enter listing commands to re-direct output to the
terminal used above.
The command is rejected since the terminal SCN no longer exists.
T05-01600
Purpose:
Action:
Result:
5.1.4
To demonstrate that SCOOT event driven messages are cancelled when a
terminal is logged off.
Start SCOOT event driven messages at a terminal which is logged in to
the system. Log out at the terminal with the event driven messages still
active.
The log out is recorded in the system log together with an XMES
command to cancel the event driven messages. SCOOT event driven
messages are no longer output to the terminal.
Inactivity Timeout
Reference: VAX SRS 2.5.3 (12), (13)
T05-01700
Purpose:
Action:
Result:
SYSTEST.DOC
To demonstrate that terminals at which a user is logged on, and which are
not used for a period of time, will be automatically logged off.
At two different remote terminals log-in USER1 and USER2. Leave the
terminals with the Traffic System prompt for 10 (U) minutes.
After 5 minutes, a warning message will appear on both terminal screens.
After a further 5 minutes both Users will be logged off the Traffic System.
Messages will be written to the System Log that the Users have been
logged off.
Issue 11.0 Page 5-5
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T05-01800
Purpose:
Action:
Result:
5.1.5
To demonstrate that logged-on terminals with an active display are
subject to a longer timeout period.
At two different remote terminals log-on USER1 and USER2. For
USER1 start a live update picture (PICT). For USER2 start a MONI
display. Leave the terminals for 60 minutes.
After 30 minutes both the displays are still active.
After a further 30 minutes both displays will be cancelled and both Users
will be logged off the Traffic System. Messages will be written to the
System Log that the Users have been logged off.
Terminal Configuration
Reference: VAX SRS 2.5.1
T05-01900
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
To prove that the terminals accept only the type of commands and output
specified in the terminal configuration database.
Check the database, and amend if necessary, to configure the 4 test
terminals as follows :
(a) for SCOOT I/O only,
(a) for UTC I/O only,
(a) for DCL commands only,
(a) allowing all forms of I/O
Attempt to enter SCOOT commands on the UTC and DCL terminals.
The commands are rejected.
Attempt to enter UTC commands on the SCOOT and DCL terminals.
The commands are rejected.
Attempt to enter DCL commands on the SCOOT and UTC terminals.
The commands are rejected.
T05-02000
Action:
Result:
5.1.6
Repeat the above test using 4 user accounts configured as for the
terminals and terminals requiring users to log-on.
As above.
Novice Command Entry
Reference: VAX SRS 2.5.1
T05-02100
Purpose:
Action:
SYSTEST.DOC
To show that a method of command entry is available which gives
assistance at each stage of entry of the command.
The requirements of this test are satisfied by inputting as many commands
as possible during testing using the novice prompt.
Issue 11.0 Page 5-6
System Test Specification for a VAX/VMS UTC System
Result:
5.1.7
666/YJ/16940/000
Each available Operator command should have been input one parameter
at a time at the novice prompt.
Incorrect parameters should be included.
Sensible responses are given when partial commands are entered correctly
or incorrectly. When a full command has been entered the response of the
System should be the same as if the complete command had been entered
at the expert prompt.
On-line Command Help
Reference: VAX SRS 2.5.1
T05-02200
Purpose:
Action:
Result:
Action:
Result:
To Show that on-line help is available for all system facilities.
Use the HELP command on its own.
A list of available commands is produced.
Use the HELP command with all of the commands appearing in the
Operators Handbook (ref ).
Basic syntax, example commands and a description of the action of the
keyword will be displayed.
T05-02300
Purpose:
Action:
Result:
Action:
Result:
5.1.8
To show that on-line help is available during database preparation.
(a) Enter Database Preparation and note that whenever the ESC key is
offered as an option then help is available.
(b) Work through all the menus and attempt to obtain help from each of
them.
Help is available and correct.
Access and read each of the help screens available in the Forms based part
of Data Entry.
The information is available and correct.
Command Line Editing
Reference : VAX SRS 2.5.2
T05-02400
Purpose:
Action:
Result:
Action:
SYSTEST.DOC
To prove the facilities provided to allow the editing of the current
command line.
Enter a command line on a VT series terminal with an invalid command
mnemonic and fields, do not press carriage return. Using the left and right
cursor keys and the backspace key to delete the character to the left of the
cursor, alter the command line to contain a valid command mnemonic and
data fields.
The cursor moves as requested and the characters are deleted as
requested.
Press carriage return.
Issue 11.0 Page 5-7
System Test Specification for a VAX/VMS UTC System
Result:
Note :
666/YJ/16940/000
The command is accepted by the system and the requested action is
carried out.
This test should be repeated on all the terminals connected to the System.
T05-02500
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
To prove a previously entered command line can be recalled modified and
re-entered.
Enter an invalid command line and fields on a VT series terminal and
press carriage return.
The command is rejected and no further action is taken by the system.
Press cursor up.
The command line just entered is re-displayed.
Using the left and right cursor keys and the backspace key to delete the
previous character alter the command line to contain a valid command
mnemonic and fields.
The cursor moves as requested and the characters are deleted as
requested.
Press carriage return.
The command is accepted by the system and the requested action is
carried out.
T05-02600
Purpose:
Action:
Result:
Action:
Result:
5.2
To prove any one of 20 previously entered command lines can be recalled
and reentered to the system.
Repeat test T05-02400 20 times, each time for a different command.
The 20 commands are accepted and the actions carried out by the system.
Using the up and down cursor keys select one of the previous 20
command lines and press carriage return.
The command is accepted by the system and the requested action is
carried out.
Dial Up Terminals
Reference : VAX SRS 2.5.3
Note :
The database should be set up for a number of remote users where :(a) one is configured for UTC commands and UTC output only;
(a) one is configured for SCOOT commands and SCOOT output only;
(a) one is configured with all facilities enabled, including OVRB, but not
dial back;
(a) one is configured with dial back.
T05-02700
Purpose:
SYSTEST.DOC
To demonstrate that a connection may be established between a remote
terminal and the System for a terminal without dial back.
Issue 11.0 Page 5-8
System Test Specification for a VAX/VMS UTC System
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
666/YJ/16940/000
Enable dial up access using the command DIAL ALL at a terminal
directly connected to the System. Use the normal command at the remote
terminal for establishing a connection to the system.
The connection is established without further operator intervention.
Enter an incorrect User I.D. and Password when prompted.
Access is denied and the operator re-prompted.
Enter a valid User I.D. with an incorrect password when prompted.
Access is denied and the operator re-prompted.
Enter an incorrect User I.D. and password.
Access is denied and the connection is terminated.
Re-establish the connection and this time enter the correct User I.D. and
password for a user with all facilities except dial back.
A message indicating that the terminal has access to the System is
produced on all suitably configured terminals and printers and sent to the
System log. A 'welcome' message and the copyright notice is output on
the remote terminal.
T05-02800
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
To show that the terminal has the required level of access.
Verify that all the facilities configured - UTC commands, SCOOT
commands and OVRB - are available and that DCL commands are not
available. Enter some invalid commands and key sequences
The correct facilities are available and function correctly. Invalid inputs do
not terminate the connection.
Initiate OVRB on a directly connected terminal and then attempt to use
OVRB for the same equipment on the remote terminal.
OVRB is rejected on the remote terminal with a suitable message. Other
commands may be entered.
Cause at least one UTC message and at least one SCOOT message to be
generated by the System.
All messages generated are also output on the remote terminal.
T05-02900
Purpose:
Action:
Result:
Action:
Result:
To show that a call may be terminated by command from the remote
terminal.
With a remote terminal connected enter the command ENDS at a normal
terminal.
The command is rejected.
Enter ENDS at the remote terminal.
The call is terminated. The connection may only be re-established by
repeating the full login procedure.
T05-03000
Purpose:
SYSTEST.DOC
To show that facilities are correctly enabled/disabled according to the
User I.D. in use.
Issue 11.0 Page 5-9
System Test Specification for a VAX/VMS UTC System
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
666/YJ/16940/000
Following tests T05-02700 to T05-02900 establish a connection for a
user with only UTC commands and UTC output enabled. Attempt to use
a number of UTC commands, including OVRB, and a number of SCOOT
commands.
The UTC commands are accepted and actioned normally except OVRB,
which is rejected. All the SCOOT commands are rejected.
Cause at least one SCOOT message and at least one UTC message to be
generated by the System.
Only the UTC messages appear on the remote terminal.
Terminate the current session using ENDS and re-connect with a User
I.D. configured for only SCOOT commands and SCOOT output. Attempt
to use a number of SCOOT commands and a number of UTC commands
including OVRB.
All the SCOOT commands are accepted and actioned normally. The UTC
commands including OVRB are rejected.
Cause at least one SCOOT message and at least one UTC message to be
generated by the System.
Only the SCOOT messages appear on the remote terminal.
T05-03100
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
To show that access to the operating system may be gained by
configuring dial back for a remote terminal.
Make sure that the telephone number where the remote terminal modem
is connected is configured as the dial back number for one of the remote
users. Log in as that remote user.
After the password has been entered the System terminates the connection
and dials back to the remote terminal. The remote terminal is then
connected to the system and the message output.
Attempt to enter both Traffic System and Operating System commands at
the remote terminal.
Traffic System commands for which the user is configured are accepted
and Operating System commands for which the user has sufficient priority
are accepted.
Disconnect using the ENDS command.
Both the DCL login and the modem connection are terminated.
T05-03200
Purpose:
Action:
Result:
Action:
Result:
SYSTEST.DOC
To demonstrate control of dial up access from an instation terminal.
Establish a connection to the dial-up modem and login using a valid User
I.D. and Password. If more than one dial-up modem is available then
connect to a second using a different User I.D. Enter the DIAL command.
All connected users are listed.
Disable the/a connected remote user with the command
XDIAUSER_ID
The remote user is immediately disconnected. If a second remote user is
connected then that user is not affected.
Issue 11.0 Page 5-10
System Test Specification for a VAX/VMS UTC System
Action:
Result:
Action:
Result:
Action:
Result:
666/YJ/16940/000
Attempt to reconnect from the remote terminal using the now disabled
USER_ID.
After the password has been entered a message 'access disabled' is output
and the connection is broken.
Re-enable the user with the command DIAL USER_ID and attempt to
connect as the re-enabled user.
The connection is successful.
Enter the command XDIA ALL on a directly connected terminal.
All connected users are disconnected and no further logins are allowed.
T05-03300
Purpose:
Action:
Result:
Action:
Result:
To demonstrate the behaviour of dial up terminals when the System goes
off line.
With a remote terminal connected KILL the System.
The call is disconnected. No further connections are possible - the modem
does not answer the call.
Restart the System.
All User I.D.s are disabled until enabled by the DIAL command.
T05-03400
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
SYSTEST.DOC
To demonstrate that whenever the connection is broken other than by
ENDS and XDIA all commands active on the remote terminal are
cancelled and the user is disconnected.
Connect to the System using a non-dialback User I.D. then break the
connection by removing the modem telephone plug from the telephone
socket.
After a few seconds a disconnect message for the user will be output on
the log printer and all UTC output terminals. After a few more seconds
DTR will be set high again (visible on Quattro modems) enabling
subsequent connections.
Connect to the System and enter the LOGO command. While the log
output is in progress pull the modem phone plug from the phone socket.
After a few seconds the user is disconnected.
Connect to the System and call up a SURV display. While the display is
active break the connection as above.
After a few seconds the user is disconnected.
Connect to the System and start a link validation display (LVAL). Before
the screen initialisation is complete break the phone connection.
After about five seconds the user is disconnected.
Connect to the System and start a link validation display (LVAL). When
the screen has been initialised and fields are being updated break the
phone connection.
After a few seconds the user is disconnected.
Connect to the System and call up a picture using the PICT command.
When the picture is complete break the phone connection.
Issue 11.0 Page 5-11
System Test Specification for a VAX/VMS UTC System
Result:
Action:
Result:
666/YJ/16940/000
After a few seconds the user is disconnected.
Connect to the System using a dial-back User I.D., login via DCL then
break the phone connection.
The user is disconnected and the DCL login is also cancelled.
T05-03500
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
To demonstrate that several dial-up users can be simultaneously
connected to Systems with more than one modem, without interference.
Connect to one modem and login. Connect to a second modem and
attempt to login using the same User I.D.
The second login is rejected with a 'user already logged in' message.
Establish a connection for two separate remote terminals using different
User I.D.s. Type ENDS at one.
The remote terminal at which ENDS was entered is disconnected while
the other is unaffected.
Re-establish the second connection. Break the connection on the other
modem by removing the modem phone plug from its socket.
The user for the broken connection is disconnected. The other is
unaffected.
Re-establish a second connection. Execute a number of commands on
both remote terminals - different and same commands together.
A command on one terminal does not affect the other except where the
command can only run on one terminal at a time (eg. OVRB for the same
equipment).
T05-03600
Purpose:
Action:
Result:
5.3
To demonstrate the operation of the terminal/user inactivity timeout.
Connect to the System. After 5 or 10 minutes enter a command then do
not press any keys on the remote terminal.
After the user configurable timeout period from the last key stroke the
user is disconnected.
Roving Terminal
Reference : VAX SRS 2.5.3
Note :
SYSTEST.DOC
Tests for the Roving terminal itself are contained in a separate document.
If a Roving Terminal is to be supplied then it should if possible be tested
with the system.
If the customers Roving Terminal is not available then the in-house or
another similar one should be tested with the system.
Currently dial back does not work with a Roving Terminal as the System
cannot deal with the behaviour of Reverse 971 VMACS.
The majority of the tests for the operation of the Roving Terminal are
implicit in the Dial-Up Terminal Tests. The following tests cover the
exceptions.
Issue 11.0 Page 5-12
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T05-03700
Purpose:
Note :
Action:
To demonstrate that the user is disconnected when the line is broken due
to a weak signal to the roving terminal.
The roving terminal modem may lock up when a weak signal causes the
line to break. If this happens the roving terminal modem must be switched
off then on using the power switch on the handset.
Repeat test T05-03400 but to break the line remove the RS232
connection to the outstation modem from the roving terminal.
Result: The results should be as described in T05-03400.
T05-03800
Purpose:
Action:
Result:
Action:
Result:
5.4
To show that data is displayed correctly on the roving terminal.
Set up a User I.D. with the status line enabled and connect with this
identity.
The status line is displayed at the bottom of the screen. The remainder of
the screen scrolls up when commands are entered, without affecting the
status line. The status line is updated correctly.
Call up a number of displays on the roving terminal, including MONI,
LVAL, RFTD and NFTD.
The displays are formatted to the roving terminal screen size and are
updated correctly.
LAT Terminals
Reference : VAX SRS 2.11
T05-03900
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
SYSTEST.DOC
To demonstrate System access through terminals connected to a Terminal
Server.
At a terminal connected to a Terminal Server, hit the return key.
The "Local>" prompt is displayed.
Enter the command "Show Services".
The System responds with a list of the computers attached to the local
Ethernet and their current "state".
For the required computer, enter the command "C TCCn", where TCCn is
one of the services listed in response to the previous command.
The System responds with the UTC login prompt.
Follow the procedure for logging on at a password-protected terminal.
Check that the terminal is attached to the required computer and enter
some local and system-wide commands.
The terminal behaves like a directly connected terminal.
Log off from the System and using the same terminal connect to the TMC
and each TCC in turn. Confirm that each time the connection is made to
the correct computer.
Issue 11.0 Page 5-13
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T05-04000
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
To demonstrate what happens when an LAT terminal is unplugged from
the terminal server.
Using the same terminal as above, log on to a TCC and start some event
driven messages. Unplug the terminal from the terminal server.
After a short period a message is written to the system log to indicate the
loss of communication.
Re-connect the terminal.
If the terminal is re-connected within the timeout period the messages will
re-appear, otherwise the terminal will be logged off. An LAT terminal
operates in the same way as a directly connected terminal if it is physically
unplugged.
Repeat the above sub-test for :
(a) a live update picture,
(a) a MONI/OVRB display for equipment controlled by a remote TCC,
The displays are aborted and there is no connection to the Traffic System.
T05-04100
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
To demonstrate what happens when an LAT terminal session is
disconnected.
At an LAT terminal, start a number of SCOOT event driven messages.
Hit the BREAK key and enter a command to disconnect the session.
A message is written to the system log to indicate that the user has logged
out; the event driven messages no longer appear on the screen.
Repeat the above with different displays present on the LAT terminal.
All displays are cancelled; the log out message appears in the system log.
Log into the system again and re-start each of the displays.
All displays may be re-started i.e. there has been a "clean" shut down on
the terminal.
T05-04200
Purpose:
Action:
Result:
Action:
Result:
To demonstrate what happens when a terminal server is unplugged from
the Ethernet.
Log in at a number of terminals connected to the same terminal server and
start different displays on each terminal. Disconnect (physically) the
terminal server from the Ethernet.
All the users are logged off the system and messages are written to the
system log for each user.
Re-connect the terminal server.
The terminals remain logged off.
5.5
Wall map and System Indication Panel
5.5.1
Wall Map and Alarm Panel
SYSTEST.DOC
Issue 11.0 Page 5-14
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
Reference : VAX SRS section 2.5.4
Note :
5.5.1(a)
These tests only test the standard facilities available on all Systems with
these facilities. Other more System specific tests may be written for
systems that include these facilities.
General Tests
T05-04300
Purpose:
Action:
Result:
Action:
Result:
To prove that the wall map may be tested by operator command.
Enter the TEST MAP operator command.
All wall map lamps are extinguished and then after 4 seconds all wall map
lamps are lit. This is repeated continuously.
Enter the command XTES MAP.
The test stops and normal operation is resumed.
T05-04400
Purpose:
Action:
Result:
Action:
Result:
To prove the driving of the Alarm panel.
Enter the TEST ALM operator command.
Any existing audible and visual alarms are turned off, the system alarms
(both audible and visual) are turned on. After four seconds the system
alarms (both audible and visual) are turned off and the operational alarms
(both audible and visual) will be turned on for four seconds. The above
will be repeated until the operator command XTES SIP is entered.
Enter the command XTES ALM.
The Alarm panel will be returned to normal operation and any alarms
present at the start of the test which have not been acknowledged will be
re-displayed.
T05-04500
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
5.5.1(b)
To show that the audible alarm may be disabled.
(a) Enter the command AUDI BOTH to turn both audible alarms on.
(b) Enter the command XAUD SYS
(c) Cause a system alarm to occur.
There is no audible alarm.
Enter the command XAUD OP. Cause an operational alarm to occur.
There is no audible alarm.
Enter the command AUDI OP.
The audible Operational alarm sounds.
Enter the commands XAUD BOTH and AUDI SYS.
The operational audible alarm is silenced and the audible system alarm
sounds.
Networked Systems
SYSTEST.DOC
Issue 11.0 Page 5-15
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
Reference : VAX SRS 2.10.8 (3)
T05-04600
Purpose:
Action:
Result:
To demonstrate the testing of SIP lamps on one or more computers.
Enter a TEST SIP command on the TMC.
The command is accepted and all lamps are flashed together.
T05-04700
Purpose:
Action:
Result:
To demonstrate the testing of SIP lamps on the local TCC.
Enter a TEST SIP H01000 command on TCCA.
The command is accepted and the local lamps only are lit (in turn).
T05-04800
Purpose:
Action:
Result:
To demonstrate the testing of remote SIP lamps.
Enter a TEST SIP H02000 command on TCCA.
The command is accepted and lamps for TCCA are lit.
5.5.2
VDU Status Line and associated alarm panel indicators
5.5.2(a)
General Tests
Reference : VAX SRS 2.5.4
T05-04900
Purpose:
Action:
Result:
Action:
Result:
Note :
To show that the VDU status line when configured for a terminal may be
turned on and off by operator command.
At a terminal with the status line enabled type CNTRL D.
The status line removed from the display.
Type CNTRL D
The status line is re-displayed.
Before continuing all the alarms should be cleared. This may be quite
difficult. Clear all external faults and perform an ACKD; the system alarm
should disappear from the status line and the alarm panel. Once the LSTF
list is clear both the system and operational alarms should have
disappeared.
The audible alarm should be enabled.
T05-05000
Purpose:
Action:
Result:
Action:
SYSTEST.DOC
To show system and operational alarms are correctly displayed.
Cause an operational alarm to be raised by entering the REIN command.
The operational alarm field blinks reverse video. The operational alarm
panel lamp flashes and the audible alarm gives a continuous tone.
Enter the command ACKD
Issue 11.0 Page 5-16
System Test Specification for a VAX/VMS UTC System
Result:
Action:
Result:
Action:
Result:
Action:
Result:
666/YJ/16940/000
The operational alarm field stops blinking and changes to normal video.
The alarm panel lamp becomes steady. The audible alarm stops
Cause a system alarm to be raised by disconnecting an out-station.
The system alarm field blinks reverse video. The alarm panel light flashes
and the audible alarm gives an interrupted tone.
Enter the command ACKD
The system alarm field stops blinking and remains reverse video. The
alarm panel light becomes steady. the audible alarm stops.
Reconnect the out-station and clear the fault.
The system alarm field changes to normal video. The alarm panel light is
extinguished
T05-05100
Purpose:
Action:
Result:
To show that the watchdog status is correctly displayed.
Remove the watchdog connection from the rear panel.
The WDOG indication appears.
T05-05200
Purpose:
Action:
Result:
5.5.2(b)
To show the time and date are updated correctly.
Observe the time and date fields shown on the display and compare them
to the value displayed by the DATE command.
The values match.
Networked Systems
Reference : VAX SRS 2.10.8 (2)
T05-05300
Purpose:
Action:
Result:
To demonstrate the acknowledgement of alarms on one or more
computers.
Enter an ACKD command on the TMC.
The command is accepted and alarms on both TCCs are cancelled. Check
the alarms on the status line, on the SIP (if present), and the output of a
LSTA command.
T05-05400
Purpose:
Action:
Result:
SYSTEST.DOC
To demonstrate the acknowledgement of alarms on one or more
computers.
Generate a number of faults on both TCCs.
Enter an ACKD H01000 command on TCCA.
The command is accepted and alarms on TCCA only are cancelled. Check
the alarms on the status line, on the SIP (if present), and the output of a
LSTA command.
Issue 11.0 Page 5-17
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T05-05500
Purpose:
Action:
Result:
Purpose:
To demonstrate the acknowledgement of alarms on one or more
computers.
Generate a number of faults on all TCCs.
Enter an ACKD command on TCCB.
The command is accepted and alarms on all TCCs are cancelled. Check
the alarms on the status line, on the SIP (if present), and the output of a
LSTA command.
To demonstrate operation of the status line on a Traffic terminal.
Reference : VAX SRS 2.10.14
T05-05600
Action:
Result:
Action:
Result:
Action:
Result:
Ensure that there are no system or operational faults for equipment
controlled by TCCA.
Generate a system alarm by setting a fault on equipment controlled by
TCCB.
The status line on all terminals, including those not connected to TCCB,
displays a system alarm.
Acknowledge the alarm on any terminal, specifying equipment H02000.
The status line on all terminals, including those not connected to TCCB,
displays the acknowledged system alarm.
Clear the fault on TCCB.
The status line on all terminals, including those not connected to TCCB,
shows no system alarm.
T05-05700
Action:
Repeat the above test generating an operational alarm.
Result:
As above, the status lines on all terminals reflect the same, system-wide
alarm state.
SYSTEST.DOC
Issue 11.0 Page 5-18
System Test Specification for a VAX/VMS UTC System
6.
DATA ENTRY TEST DEFINITIONS
6.1
System Data
6.1.1
Data Preparation - General
666/YJ/16940/000
Reference: VAX SRS section 2.6
Note :
When executing this test, the engineer should refer to the Operators
handbook (ref 1.3.2(d)) and the Data Preparation Manual (ref 1.3.2(e)),
for details of the preparation procedure.
T06-00100
Purpose:
Action:
Result:
Action:
Result:
To commence the data preparation session.
At a terminal directly connected to the computer enter the command DBAS
The data preparation command file is invoked and a menu of options is
displayed.
Attempt to enter the same command on a second terminal.
The command is rejected with a warning message that the program is
already active.
T06-00200
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
To prepare UTC data.
From the edit menu select the Edit UTC Data option.
The UTC FMS menu is displayed.
Select the "Equipment Data" sub-option.
Change the UTC equipment data file using the forms based data entry.
Both valid and invalid data should be input.
Return to the top level menu.
From the Process menu select and process the forms data.
The UTC equipment data is prepared and the invalid data is rejected.
Correct the invalid data and re-prepare the UTC equipment data in line
with the specification in paragraph 2.5.
All data is accepted.
T06-00300
Purpose:
Action:
SYSTEST.DOC
To prepare SCOOT data.
Return to the Edit menu and select the SCOOT data option.
Repeat the actions of test T06-00200 to change and prepare SCOOT
data.
In particular set up the following conditions Specify a maximum cycle time for a node which is less than the minimum
cycle time for the region. This should be rejected.
Issue 11.0 Page 6-1
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
Specify a "removable" stage in the translation plan. This should be
accepted.
SCOOT data is prepared.
T06-00400
This test has been superceded.
T06-00410
Reference: VAX SRS 2.7.4(5) & (6)
Purpose:
Note :
To prepare fixed time plans.
The normal mode for executing plan preparation is from the UTC Traffic
prompt using the command : PPRP. Plan modification and preparation
can only be called from the Process menu of Data Preparation when one
or more equipments (Junction or Pelican) or Equipment Word formats
have been modified such that one or more existing plans become invalid.
Action:
(a) From the Edit menu, select Junction data and modify a controller to
add or remove a stage or change a stage to/from demand dependent.
A plan should exist for this junction which will become invalid after
these modifications.
Action:
(b) Enter the Process menu, select the "Correct errors in plan data"
option which should now be available.
(a) Press return to process the plans.
The System gives an error message for the above plan corresponding to
the changes made.
Correct the plan to eliminate the errors and process again.
Result:
The plan is processed without error.
Action:
(a) Exit from data preparation and enter the command :
Result:
Result:
Action:
Result:
UPDA
(b) After the plans have been updated, start data preparation again by
entering the command :
DBAS
(b) Select the process option from the main menu.
The Plan correction option is no longer available from the menu.
Execute some of the tests detailed in T07-04520 to T07-4580 for on-line
plan preparation for junction and pelican controllers.
The results are the same as for tests T07-04520 to T07-4580.
T06-00500
This test has been superceded.
T06-00520
Purpose:
SYSTEST.DOC
To prepare Green Wave data.
Issue 11.0 Page 6-2
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
Note :
The normal mode for executing plan preparation is from the UTC Traffic
prompt using the command : PPRP. Green wave plan modification and
preparation can only be called from the Process menu of Data Preparation
when one or more green wave plans become invalid.
Action:
(a) From the Edit menu, select Junction data and modify a controller
with a non-demand-dependent stage that is called in one of the green
wave plans and alter the stage such that is demand-dependent. Save
and process the data.
Result:
Action:
Result:
Action:
Result:
(b) Still from the process menu, select the "Correct errors in plan data"
option which should now be available.
(b) Press return to process the plans.
The System gives an error message for the above green wave plan
corresponding to the changes made.
Correct the junction data or modify the plan to send a DX or Dn bit to
eliminate the errors and process again.
The plan is processed without error.
Execute some of the tests detailed in T07-04570 for on-line plan
preparation for green waves.
The results are the same as for tests T07-04570.
T06-00600
Purpose:
Action:
Result:
Action:
Result:
To prepare further UTC data.
Return to the Edit menu and edit timetable and message data including
some errors.
From the Process menu select the timetables which have been modified
and the message texts and process them.
The data is processed and invalid data rejected.
Correct the invalid data and reprocess.
The data is successfully processed.
T06-00700
Purpose:
Action:
Result:
To attempt to input invalid responses to the data preparation prompts.
Follow the actions of the previous tests making invalid responses to the
prompts e.g. numbers out of range, letters in place of numbers etc.
All the responses are rejected and the prompts re-issued.
T06-00800
Purpose:
Action:
Result:
To use the HELP file whilst doing data preparation.
Repeat tests T06-00200 to T06-00700 via the HELP command file.
The results are the same as for T06-00200 to T06-00700.
T06-00900
Purpose:
SYSTEST.DOC
To list the source data.
Issue 11.0 Page 6-3
System Test Specification for a VAX/VMS UTC System
Action:
Result:
666/YJ/16940/000
From the top level menu select the option to list source data. From the list
menu make a selection of data to be printed. List the data to a terminal
and printer.
All system data source files can be selected and listed on the system
printer or the current terminal. At the head of each listing is included the
time, date and User ID (or terminal ID) of the last person to make
changes.
T06-01000
Purpose:
Action:
Result:
To attempt data preparation listing when the system is online.
Start the traffic system. When the system is online, run data preparation
again and attempt to output a listing to the printer.
Data preparation continues; the listing request is actioned.
T06-01100
Purpose:
Action:
Result:
6.1.2
To show the system data is updated by operator command.
At a terminal enter the UPDA command.
The newly prepared data is installed and the system re-started if the new
system data are other than plans or timetables.
Data Preparation - Networked Systems
Reference: VAX SRS 2.10.6
T06-01200
Purpose:
Action:
Result:
To show that invalid data is rejected.
Attempt to enter, and prepare, the following data :
(a) UTC/SCOOT Data
- 9 TCCs
- TMC with SCN not = H99000
- A car park with signs and detectors controlled by different TCCs
(a) Plan Data - a green wave plan including junctions controlled by more
than 1 TCC.
All data is rejected with appropriate error messages.
T06-01300
Purpose:
Action:
Result:
To prepare data for a single TCC.
Amend UTC/SCOOT data for one TCC and select the prepare option for
a single TCC.
Data is only prepared for the selected TCC. This can be confirmed by
examining the creation date/time of the latest database files in the TMC
sub-directory.
T06-01400
Purpose:
SYSTEST.DOC
To prepare data for a partial system.
Issue 11.0 Page 6-4
System Test Specification for a VAX/VMS UTC System
Action:
Result:
6.2
666/YJ/16940/000
Set the value of MAX_LICENSED_CPU to one more than the number of
computers available. Select the option to prepare data for all TCCs.
A warning message is output to indicate that there is no data for the
"extra" TCC.
Terminal and User Data Preparation
Reference : VAX SRS 2.5.1 (22), 2.5.3 (2), (9), (10), (11)
T06-01500
Purpose:
Action:
Result:
Action:
Result:
To demonstrate the procedure necessary to gain access to the Terminal
and User Configuration facility.
Log on to TCCA as USER1 and enter a TUAC command.
The command is rejected as it is only allowed on the TMC.
Log off TCCA and log on to the TMC as USER1. Enter a TUAC
command.
The command is accepted and the Terminal and User Preparation main
menu is displayed.
T06-01600
Purpose:
Action:
Result:
To demonstrate the set up and preparation of terminal data.
Select the Terminal option following a TUAC command. Enter terminal
data and confirm that the data will not prepare without error unless :
• there is a log printer connected to the TMC.
• all SCNs must be of the form Tnnyyy (T01000 not allowed)
Data prepares without any errors.
T06-01700
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
To demonstrate the set up and preparation of User data.
(a) Enter a TUAC command and select the USER option. Add :
USER2 Access Level = 14 Sub-Areas = All
USER3 Access Level = 8 Sub-Areas = (any 3)
USER4 Access Level = 1 Sub-Areas = None
The data is accepted and prepares without error.
(b) Delete the USER1 data and re-prepare.
The data is rejected since there must be at least one User account with
level 16 access at all times.
(c) Restore USER1 data. Enter invalid user names (too long, invalid
characters), passwords (ditto), sub-areas etc.
All invalid data is identified correctly and is rejected.
T06-01800
Purpose:
SYSTEST.DOC
To demonstrate the update of User and Terminal data on all TCCs.
Issue 11.0 Page 6-5
System Test Specification for a VAX/VMS UTC System
Action:
Result:
666/YJ/16940/000
When all User and Terminal data has been successfully prepared, enter a
UPDA USERS command on the TMC.
The new data is sent to all TCCs; each TCC must shut down and re-start
with the new data. This can be verified by logging on to a TCC as one of
the new Users and entering a WHAT T00000 command.
T06-01900
This test has been superceded.
T06-01950
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
To show that a user can change the access level on any command.
(a) Use the same USER1 to USER4 terminal setups as defined in tests
T06-01600 and T06-01700.
(b) Log on to the system as USER2 and attempt to enter commands
whose default values are level 16, such as CHCK, MAIN, OFFC and
TUAC.
(c) Log on as USER3 and attempt to enter some commands whose
default levels are greater than 8.
(d) Repeat for USER4 for commands with default levels greater than 1.
All the commands are rejected.
(e) Enter the TUAC command and select the option to alter the
command level of an operator command.
(f) Alter some of the command levels of the commands tested in (b) to
level 14 and repeat the test.
(g) Alter some of the command levels of the commands tested in (c) to
level 8 and repeat the test.
(h) Alter some of the command levels of the commands tested in (d) to
level 1 and repeat the test.
All the commands are accepted.
Correct all commands to their default levels and process the data.
The command levels return to their default values.
6.3
Baseline Data
6.3.1
Baseline Data - General
Reference : VAX SRS 2.6
T06-02000
Purpose:
Action:
SYSTEST.DOC
Show that data may be recorded in and listed from the baseline database.
Using the command RUBA add and modify information in the baseline
database. Show that all parameters which may be used to set up baseline
data will be accepted under the RUBA command. List the contents of the
baseline database using the LUBA command and ensure that all the values
entered appear in the list. Listings should make use of both forms of the
LUBA command i.e. a) a full listing of all data, and b) a snapshot listing
Issue 11.0 Page 6-6
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
of one parameter for various single and wildcarded SCNs. The following
parameters must be entered under the RUBA command:
a
BIAS - L
n
CGIF - L
aa
CGOF - L
b
CGWT - L
o
CLIF - L
bb CLWT - L
c
DETU - D
p
DFOF - L
cc DGEL - L
d
DGSL - L
q
ELAG - L
dd ETHR - A
e
FDWN - R
r
FTHR - A
ee GGAI - L
f
GSAT - L
s
INCY - L
ff
INMQ - L
g
INOF - L
t
INSP - L
gg JNYT - L
h
MAXC - R
u
MINC - R
hh MFBI - N
i
OFWT - L
v
QCMQ - L ii
SFBI - N
j
SJNY - D
w
SLAG - L
jj
SMAN - D
k
SMAX - L
x
SMIN - L
kk SMUL - L
l
SPEN - A
y
SSAT - L
ll
STOC - L
m
TRAF - A
z
TREN - R
Where the letters A, L, N, R, S, indicate if the parameter affects Area,
Link, Node, Region, or Stage information.
The iformation recorded against particular links, nodes etc. is displayed
when the baseline database is listed. All the parameters in the list are
accepted and included in the baseline database. The current data is not
affected.
T06-02100
Purpose:
Action:
Result:
Show that not all parameters which may be changed by operator
command are permitted in the baseline database.
Using the command RUBA attempt to add information into the baseline
database using the list of commands below. Show that the RUBA
command will not allow these parameter values to be included in the
database:
(a) ADJU - A
(a) CYOS - R
(a) CYFX - N
(a) DSTS - D
(a) FCYT - R
(a) OFST - N
(a) SPLT - N
All the commands are rejected.
T06-02200
Purpose:
Action:
SYSTEST.DOC
Show that the baseline database is implemented when the SCOOT subsystem is re-initialised or the system restarted.
Re-initialise the SCOOT sub-system. Check for all the parameters entered
into the baseline database in test T06-02000 that the correct values have
Issue 11.0 Page 6-7
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
been implemented subject to any modification by the journal or timetable.
Restart the system and again check that values are implemented.
The parameters are set to their values in the baseline database.
T06-02300
Purpose:
Action:
Result:
Action:
Result:
6.3.2
To show the effect of changes in the configuration of the SCOOT system
on baseline data.
For a link which has parameter values set in the baseline database, delete
the link from the SCOOT source data and use database preparation to
create a new SCOOT database. Restart the system.
When the baseline commands for the deleted link are encountered a fault
message is displayed, the commands are ignored and are flagged as faulty.
Reconfigure the link into the SCOOT database. Re-initialise the SCOOT
sub-system.
When the baseline commands for the reinstated link are encountered they
are actioned and are no longer flagged as faulty.
Baseline Data - Networked Systems
Reference: VAX SRS 2.10.11
T06-02400
Purpose:
Action:
Result:
To demonstrate that Baseline data is local to each TCC.
At a TCC terminal enter a series of RUBA commands for SCOOT
equipment which is local to the TCC, and for SCOOT equipment which is
on a remote TCC.
All valid commands are accepted.
T06-02500
Action:
Result:
Enter a RUBA command for an Area level parameter with at least one
TCC off-line.
The command is rejected as all TCCs must be available to receive the
update.
T06-02600
Action:
Result:
Enter a LUBA command with no parameters, at any terminal.
Baseline data for the whole system is listed on the TMC printer.
T06-02700
Purpose:
Action:
Result:
SYSTEST.DOC
To demonstrate that a single TCC may have its SCOOT database reinitialised.
Enter a REIN H01000 command on TCCA.
The SCOOT sub-system on TCCA goes off-line, the SCOOT database is
re-initialised and the SCOOT sub-system comes back on-line. All other
TCCs are unaffected.
Issue 11.0 Page 6-8
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T06-02800
Purpose:
Action:
Result:
SYSTEST.DOC
To demonstrate that a all TCCs may have their SCOOT databases reinitialised.
Enter a REIN command on TCCA, with no hardware parameter.
The SCOOT sub-system on all TCCs goes off-line, the SCOOT database
is re-initialised and the SCOOT sub-system comes back on-line.
Issue 11.0 Page 6-9
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
7.
JUNCTION AND PELICAN CONTROL AND MONITORING TEST
DEFINITIONS
7.1
Junction interface
7.1.1
VA Detector Faults
Reference : MCE 0360C paragraph 4.3.1.11. VAX SRS 2.7.1
T07-00100
Purpose:
Action:
Result:
Action:
Result:
To ensure that, when a DF reply bit is returned by an intersection
controller, appropriate messages are produced.
Call up a MONI display for a controller equipped with DF facilities, and
operating under plan control.
Produce a DF bit by setting the appropriate switch on a test set or a
controller simulator box.
Check that DF is now being returned. Use the 'LSTF' command after 3
seconds to confirm that the controller now has a detector fault.
The DF bit is returned for 3 seconds and then a 'Detector fault' message is
output. The associated non-isolating fault wall map lamp flashes.
Clear the detector fault using the XFLT operator command.
The non-isolating fault wall map lamp is extinguished. After 3 seconds the
fault is re-reported and the associated non-isolating fault wall map lamp
flashes.
T07-00200
Purpose:
Action:
Result:
To ensure that a detector fault is reported when a controller is operating
under local control.
Repeat sub-test T07-00100 using a controller under local control.
The detector fault is reported as above.
T07-00300
Purpose:
Action:
Result:
To prove that detectors faults are not reported when a controller is
isolated by TX fault.
Repeat test T07-00100 using a controller isolated by TX fault.
The fault is not reported.
T07-00400
Purpose:
Action:
Result:
7.1.2
To prove that a detector fault is reported when a controller is isolated by
"signals stuck" fault.
Carry out test T08-12000 to isolate a controller by signals stuck fault.
Repeat test T07-00100.
The detector fault is reported.
Junction Remote Reconnection
SYSTEST.DOC
Issue 11.0 Page 7-1
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
Reference : MCE 360C paragraph 4.3.1.5 VAX SRS 2.7.1
T07-00500
Purpose:
Action:
Result:
Action:
Result:
7.1.3
To check that the presence of the RR bit is detected and that whilst
present, the junction is removed from computer control.
(a) Call up a MONI display for a junction with the RR bit available.
Check that a plan or similar mode of control is active.
(b) Using the test set or otherwise introduce one or more non-isolating
fault conditions on the junction.
(b) Simulate the RR bit.
The junction is shown to be remote attended and any control information
previously being sent out is terminated.
Remove the RR bit.
The junction is reconnected to the system. The previous fault conditions
present are cleared and the junction resumes normal operation.
Pelican Remote Reconnection
Reference : VAX SRS 2.7.2
T07-00600
Repeat the test T07-00500 for junction remote reconnection facility, using
an appropriate pelican controller (or simulator). Verify that the pelican
RR bit fulfills the same functions as the junction RR bit.
7.1.4
SD Bit Stuck
Reference : VAX SRS section 2.7.1
T07-00620
Purpose:
Action:
SYSTEST.DOC
To show that the SD1 bit is monitored for continuous output and a nonisolating fault raised if it is returned for more than a configured time.
(a) In the "System Wide Variants" screen of Data Preparation, set the
time for a fault to be raised on the SD1 bit being continuously set to 1
hour.
(b) Create a junction reply word format to include the SD1 bit, also
checking this bit is displayed in the HELP text.
(b) Set up a controller with this format and a fixed-time plan with an
alternative sequence event.
(b) Process the data and enter the command :
UPDA
(b) After the system has updated, ensure there are no isolating faults on
the controller.
(b) Put the controller on to the fixed-time plan with the alternative stage
sequence by operator control.
(b) Set up OVRB on the controller and overwrite the SD1 bit, noting the
start time.
Issue 11.0 Page 7-2
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
After 1 hour a "permanent demand for alternate stage sequence" fault is
raised on the controller. The controller is not isolated. This message is
included in the system log.
T07-00630
Purpose:
Action:
Result:
To show that the above fault is cleared when the SD1 bit is absent for
more than 3 seconds.
Cancel the SD1 bit overwrite in the previous test, noting down the time.
After 3 seconds the fault is cleared.
T07-00640
Purpose:
Action:
Result:
7.1.5
To show that the above fault can be cleared by an operator command.
(a) Repeat test T07-00620 (e) to (g)
(b) After one hour the fault is raised again
(b) Enter the command :
XFLT Jnnnnn 412
where nnnnn is the SCN of the controller
(a) The fault is cleared.
(b) With overwrite on the SD1 bit continuously maintained, the fault is
raised again after a further 1 hour.
Test Facility bit (TF)
Reference : VAX SRS section 2.7.1
T07-00660
Purpose:
Action:
Result:
To prove that presence of the TF test facility bit for three or more
seconds generates a system alarm.
(a) Create a junction reply word format to include the TF bit, also
checking this bit is displayed in the HELP text.
(b) In data preparation modify the reply bit format of a controller to use
this format.
(b) Process the data and enter the command : UPDA.
(b) Overwrite the controller reply bits using OVRB such that the TF bit
is permanently set.
After 3 seconds a system alarm is raised and a "controller under
maintenance test facility" message is written to the system log.
T07-00670
Purpose:
Action:
Result:
7.1.6
To prove that the absence of the TF test facility bit for three or more
seconds generates a "maintenance test facility finished" message.
Cancel the overwrite of the TF bit.
After 3 seconds a "maintenance test facility finished" message is written to
the system log.
Junction Dimming Override
SYSTEST.DOC
Issue 11.0 Page 7-3
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
Reference : VAX SRS section 2.7.1
T07-00700
Purpose:
Action:
Result:
Action:
Result:
To check that, when a dimming override command is called up by the
timetable, an SO control bit is set to override the solar cell control for
intersection controllers.
(a) Call up a MONI display for the first and last controllers in the IRN
list.
(b) Check that the current day's timetable includes the DIMO and XDIM
events. Set the system time, using the TIME command to at least 2
minutes before the DIMO event.
(b) Set some controllers in local mode.
(a) The SO bit is clear.
(b) The LSTS command for the controller does not list the solar dimming
override as being operational.
Call up MONI displays for some of the controllers in local mode. Wait for
the DIMO timetable event to occur.
(a) The SO bit is set.
(b) The LSTS command for the controller show that solar dimming
override is operational.
T07-00800
Purpose:
Action:
Result:
7.1.7
To ensure that, when the timetable cancels the dimming facility, the SO
bit is no longer sent out.
With the MONI display still active from the previous test and the SO
control bit being sent, set the system time to at least 2 minutes before the
XDIM command. Wait for the XDIM event to occur.
The SO bit is no longer transmitted.
LSTS no longer lists the solar dimming override as being operational.
Green-wave Active (GA) bit
Reference : VAX SRS section 2.7.1
T07-00820
Purpose:
To show that a controller configured with the GA control bit will receive
with this bit when a green wave is active on that equipment.
Action:
(a) Configure two or more controllers with the GA control bit and create
or modify two green-wave plans. The first plan should include all
these controllers and the second should have all except one
controller.
Result:
SYSTEST.DOC
(b) Set up MONI or DIPM displays on two of the controllers.
(b) Implement the first green-wave plan using the GWAV command.
Both controllers are sent the GA bit immediately the green-wave is
started. After each junction is dropped from green-wave control the GA
bit is removed.
Issue 11.0 Page 7-4
System Test Specification for a VAX/VMS UTC System
Action:
7.1.8
666/YJ/16940/000
(a) After the green wave has completed, set up the MONI or DIPM
displays to show one controller from the second green-wave plan and
the controller not in this plan.
Result:
(b) Implement the second green-wave plan using the GWAV command.
The controller in the green-wave plan is sent the GA bit as before. The
controller not in the plan does not receive the GA bit.
Action:
(a) Repeat the test with the first green wave.
Result:
(b) When one or more of the controllers is operating under green-wave
control, cancel the green wave with the XGWA command.
When the command is accepted by the system all the controllers in the
green-wave plan return to their previous mode of control and their GA
bits are cancelled.
Solar Bright (SB) bit checking
Reference : VAX SRS section 2.7.1
T07-00840
Purpose:
To prove that a junction controller configured with the SB reply bit and
no corresponding SO control bit operates correctly.
Action:
(a) Set up an OVRB screen for a controller configured with the SB reply
bit and no SO control bit.
Result:
Action:
Result:
(b) Override the SB bit with one.
(b) Set the system time to 02:59 using the TIME command.
(b) Wait for the time to reach 03:00.
After 3 seconds a "lamps not dimming" fault is raised and written to the
system log.
(a) Cancel the fault on the controller.
(b) Override the SB bit with 0.
(b) Set the system time to 11:59 using the TIME command.
(b) Wait for the time to reach 12:00.
After 3 seconds a "signals not on full brightness" non-isolating fault is
raised and written to the system log.
T07-00850
Purpose:
Action:
Result:
Action:
To prove that a controller configured with the SB reply bit and SO
control bit operates correctly.
Cancel any faults on the controller.
Repeat test T07-00840 for a controller configured with the SO control
and SB reply bit. Ensure the SO bit is not set.
As for test T07-00840.
(a)
Cancel any faults on the controller.
(b) Set the system time to 12:00.
SYSTEST.DOC
Issue 11.0 Page 7-5
System Test Specification for a VAX/VMS UTC System
Result:
Action:
Result:
666/YJ/16940/000
(b) Ensure the SB bit is being returned from the controller.
(b) Enter the DIMO command for this controller.
The SO control bit is transmitted to the controller.
After a short period the SB reply bit is received.
Repeat the above test, but override the SB reply bit with 0.
After 3 seconds a "lamps not dimming" non-isolating fault is raised and
written to the system log.
T07-00860
Purpose:
Action:
Result:
7.1.9
To prove that a pelican controller configured with the SB reply bit
operates correctly.
Repeat tests T07-00840 and T07-00850 with a pelican controller.
As for tests T07-00840 and T07-00850.
DR reply bit checking
Reference : VAX SRS section 2.7.1
T07-00900
Purpose:
Action:
Result:
To prove that the system monitors the operation of demand dependent
stages when a controller is under local control.
(a) Using OVRB for a junction which has demand dependent stages
configured.
(b) Overwrite the stage reply bit for the demand dependent stage with
zero.
(b) Overwrite the stage demand reply bit with one.
Within 241 seconds the fault is reported.
T07-01000
Purpose:
Action:
Result:
To prove that the system monitors the operation of demand dependent
stages when a controller is under fixed time plan or SCOOT control.
Using OVRB for a junction which has demand dependent stages
configured.
(a) Overwrite the stage reply bit for the demand dependent stage with
zero.
(a) Overwrite the stage demand reply bit with one.
Within one plan cycle the fault is reported for fixed time control and
within 241 seconds for SCOOT.
T07-01100
Purpose:
Action:
SYSTEST.DOC
To prove that the system will not cause a demand dependent stage to be
called if the demand is not present when the demand dependent stage
event is reached in the plan.
Using OVRB for a junction which has demand dependent stages
configured overwrite for 3 seconds the stage demand reply bit with the
Issue 11.0 Page 7-6
System Test Specification for a VAX/VMS UTC System
Result:
7.1.10
666/YJ/16940/000
value one when the controller is on a stage other than the demand
dependent stage.
The demand dependent stage is not called during the next plan cycle.
Operation of Part-Time Signals
Reference : VAX SRS 2.7.1
T07-01200
Purpose:
Action:
Result:
Action:
Result:
To prove that part-time signals may be controlled by operator command.
At a terminal enter the command :
SLOF aaaaaa
where aaaaaa is the SCN of a part-time signal (The
SCN may be wildcarded).
Using the MONI command confirm the correct state of the SL bit (as
defined in the data) for signals on is sent to the controller.
At another terminal enter the command:
XSLO aaaaaa
where aaaaaa is as above.
Using the MONI command confirm the correct state of the SL bit (as
defined in the data) for signals off is sent to the controller.
T07-01300
Purpose:
Action:
To prove that part-time signals may be controlled by timetable command.
Repeat T07-01200 with the SLOF and XSLO commands being timetable
events.
T07-01400
Purpose:
Action:
To prove that part-time signals may be controlled by CAST.
Repeat T08-01200 with the SLOF and XSLO commands being included
in CASTS.
T07-01500
Purpose:
Action:
Result:
Action:
Result:
SYSTEST.DOC
To prove that if part-time signals do not reply with stage confirm bits
within the configured number of seconds of a XSLO request a fault is
reported.
At a terminal enter the command :
XSLO aaaaaa
where aaaaaa is the SCN of a part-time signal.
At another terminal use OVRB overwrite G1 and G2 (or OL if available)
with one.
Using the MONI command confirm the correct state of the SL bit (as
defined in the data) for signals on is sent to the controller. After 4 seconds
a fault is reported.
Terminate the OVRB
The fault is automatically cleared.
Issue 11.0 Page 7-7
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T07-01600
Purpose:
Action:
Result:
Action:
Result:
To prove that if part-time signals do not reply with simultaneous G1 and
G2 stage confirm bits within ??? seconds of a SLOF request a fault is
reported.
At a terminal enter the command :
SLOF aaaaaa
where aaaaaa is the SCN of a part-time signal.
At another terminal use OVRB overwrite G1 with zero.
Using the MONI command confirm the correct state of the SL bit (as
defined in the data) for signals off is sent to the controller. Within 120s a
fault is reported.
Terminate the OVRB and check that simultaneous G1 and G2 (or OL) is
returned.
The fault is automatically cleared.
T07-01700
Purpose:
Action:
Result:
7.1.11
To prove that if part-time signals do reply with simultaneous G1 and G2
stage confirm bits or OL bit whilst SL is present for signals on a fault is
reported indicating the signals are off despite SL.
At a terminal enter the command :
SLOF aaaaaa
where aaaaaa is the SCN of a part-time signal.
At another terminal use OVRB to overwrite G1 and G2 (or OL) with one.
Using the MONI command confirm the correct state of the SL bit (as
defined in the data) for signals on is sent to the controller. Within 120
seconds of the simultaneous G1 and G2 (or OL) a fault is reported.
Hurry Call (HC) bit operation
Reference : VAX SRS section 2.7.1
T07-01800
Purpose:
To ensure that, when the HC bit is returned by an intersection controller,
the controller is isolated and appropriate messages are produced.
Action:
(a) Call up a MONI display for a controller that is equipped with a test
switch for the HC reply bit and confirm that the HC reply bit is not
being returned.
Result:
(b) Using the instation test set switch force the HC bit for the controller
to be sent.
(b) Use the 'LSTF' command to confirm that the controller is now
isolated and has a HC detected.
The HC bit shall be returned for 3 seconds and then a 'Hurry Call
Detected' message shall be output.
T07-01900
Purpose:
SYSTEST.DOC
To ensure that, if within four minutes the HC bit is no longer returned the
appropriate messages are produced.
Issue 11.0 Page 7-8
System Test Specification for a VAX/VMS UTC System
Action:
Result:
666/YJ/16940/000
With the MONI display still active from test T07-01800 use the test set to
remove the HC reply bit.
A 'Hurry Call Removed' message shall be output after the HC bit has
disappeared for 3 seconds.
T07-02000
Purpose:
Action:
Result:
Action:
Result:
To ensure that, when the HC bit is returned by an intersection controller
for more than four minutes a 'hurry call overrun' fault is declared and
appropriate messages are produced.
(a) Call up a MONI display for a controller that is equipped with a test
switch for the HC reply bit and confirm that the HC reply bit is not
being returned.
(b) Using the test switch force the HC bit for the controller to be sent.
(b) Use the 'LSTF' command to confirm that the controller has a HC
detected fault.
The HC bit shall be returned for 3 seconds and then a 'Hurry Call
Detected' message shall be output.
Wait for four minutes.
After four minutes a 'Hurry Call Overrun' message shall be output.
T07-02100
Purpose:
Action:
Result:
7.1.12
To ensure that, if after four minutes the HC bit is no longer returned, a
message is produced indicating the HC bit has cleared.
With the MONI display still active from the previous test use the test
switch to remove the HC reply bit.
A 'Hurry Call Removed' message shall be output after the HC bit has
disappeared for 3 seconds.
Gap Out (GO) bit operation
Reference : VAX SRS 2.7.1
T07-02130
Purpose:
Action:
To prove that when the gap out bit is sent with two or more stage force
bits, only one of the designated stages should be returned by the
controller.
(a) From the Edit UTC data option in data preparation set up a test
controller with 4 or more stages. All stage-to-stage transitions should
be set as valid and the bit format set up with the GO bit.
(b) Process the data, exit data preparation and from the -prompt enter :
UPDA
(b) After the UTC system restarts, create or modify a fixed-time plan
using the command PPRP to include one event with more than two
stages forced and the gap out facility implemented. The previous
event should be a single force bit with one of these stages. If any of
the stages in these two event is demand dependent they should have
their individual demand Dn bits set or general demand DX set.
SYSTEST.DOC
Issue 11.0 Page 7-9
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
(b)
(b)
(b)
(b)
Result:
Action:
Result:
Action:
Result:
7.1.13
Process the plan and exit from plan preparation.
Implement the plan for this controller
Monitor the controller on a DIPM display
Four minutes after implementing the plan start the OVRB display for
the controller.
(b) When the controller leaves the stage prior to the event with the GO
bit and the effective stage has passed through its minimum green
period, overwrite the reply bits with intergreen for the required
period and then one only of the other stages in the event.
No error is raised by the UTC system.
Repeat item above but overwrite the reply bit with intergreen and then
one of the other stages in the event before the minimum green has
completed.
A minimum green error message is raised for the controller.
(a) Cancel overwrite in OVRB and any faults on the controller that are
raised.
(b) Repeat item (a) above but overwrite the reply bits after the intergreen
period with a stage not defined in the GO event.
A plan compliance fault is raised for the controller.
Pedestrian Inhibit (PI) bit
Reference : VAX SRS 2.7.1
T07-02150
Purpose:
Action:
Result:
To ensure that when the PI pedestrian inhibit bit is present for a junction
for more than 3 seconds a non-isolating fault is raised.
Set up a junction to have the "PI" bit in its reply word and operating on a
fixed-time plan.
Ensure there are no faults on the junction.
Using the overwrite facility in OVRB, set the PI bit.
After 3 seconds a "pedestrian stage inhibited" non-isolating fault is raised
and a message output to the terminal and system log.
T07-02160
Purpose:
Action:
Result:
To ensure that when the PI pedestrian inhibit bit is absent for a junction
for more than 3 seconds the fault shall be automatically cleared.
Cancel the OVRB overwrite of the PI bit.
After 3 seconds a "pedestrian reconnected" message is output to the
terminal and system log and the fault is cleared.
T07-02170
Purpose:
Action:
SYSTEST.DOC
To ensure that plan compliance checking shall continue when the
pedestrian stage inhibited fault is active on a junction.
Ensure there are no faults on the junction and it is operating on a fixedtime plan.
Issue 11.0 Page 7-10
System Test Specification for a VAX/VMS UTC System
Result:
Action:
Result:
7.1.14
666/YJ/16940/000
Using the overwrite facility in OVRB, set the PI bit.
After 3 seconds a "pedestrian stage inhibited" non-isolating fault is raised
and a message output to the terminal and system log.
If necessary, wait for four minutes since starting the fixed-time plan.
Create a plan compliance fault for the junction by setting the reply stage
bits to a different stage to that being forced.
A plan compliance fault is raised.
Controller Time Synchronization
Note :
Reference : VAX SRS 2.7.1
If day-of-week checking is not enabled for the controller under test then
use tests T07-02300 to T07-02500 otherwise use tests T07-02550 and
T07-2570.
T07-02200
Purpose:
To prove that invalid command lines for the SYNC operator command
are rejected by the system.
Action:
At an operators terminal enter the following commands (a) SYNC Xnnnnn attempt to synchronise a single OTU,
(a) SYNC Jnnnnn attempt to synchronise a single controller.
The commands are rejected with appropriate error messages.
Result:
T07-02300
Purpose:
Action:
Result:
To prove the correct operation of the group timer synchronisation facility.
(a) Call up a MONI display on different terminals for two junctions with
the SG/SR facility.
(b) Prepare to simulate the SR reply bit on one of the two junctions.
(b) Input the SYNC command.
(b) Simulate the SR reply bit for at least 3 seconds after the control
sequence has been transmitted.
On the MONI displays the 101 bit sequence is sent out to both
controllers. The SR reply simulation is seen on only one MONI. A
message is output to indicate that the SYNC has failed for the controller
whose SR bit was not replied.
T07-02400
Purpose:
Action:
SYSTEST.DOC
To prove the correct operation of the controller real time clock
synchronisation facility.
(a) Call up a MONI display on different terminals for two junctions with
the TS/CS facility.
(b) Prepare to simulate the CS reply bit on one of the two junctions.
(b) Set the system time to 2 minutes before the specified daily
synchronisation value. Wait for 2 minutes.
Issue 11.0 Page 7-11
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
(b) Simulate the CS reply bit for at least 3 seconds after the control
sequence has been transmitted.
On the MONI displays the 101 bit sequence is sent out to both
controllers. The CS reply simulation is seen on only one MONI. A
message is output to indicate that the synchronisation has failed for the
controller whose CS bit was not replied.
T07-02500
Purpose:
Action:
Result:
To show that if the CS or SR reply bit is subsequently returned at the
wrong time of day no message is output.
Use an instation test set or otherwise to force the CS and SR bits for
suitable controllers to 1.
No messages are output and system operation is unaffected.
T07-02550
Note :
Purpose:
Action:
Result:
Purpose:
Action:
Result:
Before carrying out tests T07-02550 to T07-02570 a junction configured
with the TS control and CS reply bits must be set up. The durations of the
reply times for each day of the week should be set up as follows:
(a) Monday
3 seconds
(a) Tuesday
6 seconds
(a) Wednesday 9 seconds
(a) Thursday
12 seconds
(a) Friday
15 seconds
(a) Saturday
18 seconds
(a) Sunday
21 seconds
The times given above are subject to a tolerance of plus or minus second.
To demonstrate that replies which are out of range are rejected and an
appropriate error message output.
Use the OVRB screen to set the CS reply bit for a period of less than 2
seconds.
The "invalid day of week" message is output.
To demonstrate that replies which are out of range are rejected and an
appropriate error message output.
Use the OVRB screen to set the CS reply bit for a period of more than 22
seconds.
The "invalid day of week" message is output.
T07-02570
Purpose:
Action:
Result:
SYSTEST.DOC
To demonstrate that if a CS reply bit duration is other than that for the
current day of the week an appropriate error message is output.
Use the OVRB screen to set the CS reply bit for a period which is valid
(i.e. in the range 3 to 21 seconds) but which is different from that which
should be sent according to the current day of week as given by the
System date.
The "wrong day of week" message is output.
Issue 11.0 Page 7-12
System Test Specification for a VAX/VMS UTC System
7.1.15
666/YJ/16940/000
Other Bits
Reference : VAX SRS 2.7.1
T07-02600
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
To demonstrate the correct functioning of FM, FC, LL & LC controller
bits.
Observe a junction Monitor display with FM and LL control bits.
Implement a FALLBACK plan on this junction.
The FM bit is set and the corresponding FC bit is then returned.
Clear the FC bit using OVRB.
After 4 seconds a fault will be reported
Set the FC bit again.
The fault is not cleared.
Use an operator command to clear the fault.
The fault is cleared.
Implement an INHIBIT plan on the junction.
The LL control bit is set and the corresponding LC bit is returned.
Override the LC bit.
The system does not process the LC bit and therefore nothing happens.
T07-02700
Purpose:
Action:
Result:
Action:
Result:
To show the reaction of the system to controller fault bits.
Set the following bits individually or in combination for a junction.
(a) LO
lamps off
(a) LF1
lamp fault
(a) LF2
lamp fault (if configured)
(a) MC
Manual control
(a) CF
Controller fault
After 3 seconds continuous presence of a bit a fault is logged and a
message output.
Clear the bit or change the combination of bits.
After 3 seconds of each bit clearing the corresponding fault is cleared and
a message output.
T07-02750
Purpose:
Action:
Result:
SYSTEST.DOC
To show the correct operation of the user defined remote request type.
Enter data preparation, UTC data edit, and add the remote request bits
SP1 to SP8 to an OTU with vacant bit positions. Save and process the
data. Update the data.
The data is processed and updated successfully.
Issue 11.0 Page 7-13
System Test Specification for a VAX/VMS UTC System
Action:
Result:
Action:
Result:
7.2
666/YJ/16940/000
Display an OVRB screen for the above controller. Overwrite one of the
user-defined remote request bits with a one.
After 3 seconds a "remote request on" message is output to the fault log
and an operational alarm is raised.
Cancel the overwrite.
After 3 seconds a "remote request off" message is output.
Pelican Facilities
Reference : VAX SRS 2.7.2
T07-02800
Purpose:
Action:
Result:
To prove that the system monitors the operation of pelican controllers
with respect to pedestrian demands (WC reply bit) when the pelican is
under local or SCOOT control.
Using OVRB for a pelican which has the WC bit configured.
(a) Overwrite the GX bit with one.
(a) Overwrite the WC bit with one.
Within 180 seconds a pelican demand not being met a fault is reported.
T07-02900
Purpose:
Action:
Result:
To prove that the system monitors the operation of pelican controllers
with respect to pedestrian demands (WC reply bit) when the pelican is
under fixed time plan control.
Using OVRB for a pelican which has the WC bit configured.
(a) Overwrite the GX bit with one.
(a) Overwrite the WC bit with one.
Within one plan cycle a pelican demand not met fault is reported.
T07-03000
Purpose:
Action:
Result:
To prove that a pelican operates if the WC bit is present.
Repeat tests T07-02800 and T07-02900 with the GX bit operating
normally.
The Pelican goes to the pedestrian stage within one cycle each time the
WC bit is present.
T07-03100
Purpose:
Action:
SYSTEST.DOC
To ensure that the system will detect when a pelican controller has failed
to return a GX reply bit for longer than the permitted length of time and
then take the appropriate action.
(a) Call up a MONI display for a pelican controller.
(b) Check that the controller is not isolated and that a normal plan is in
progress.
(b) Use a test set to simulate the actions of the controller in following the
PV control bits of the plan.
Issue 11.0 Page 7-14
System Test Specification for a VAX/VMS UTC System
Result:
7.3
666/YJ/16940/000
(b) After a cycle of normal operations stop following the control bits and
leave the GX reply bit absent for a complete cycle.
(b) Use the 'LSTF' command to confirm that the controller now has a
signals stuck fault.
After 60 seconds the controller shall be isolated, a 'Signals stuck' message
shall be output and the alarm sounded.
Master Cycle Counter
Note : This is transparent to the user.
7.4
Signal Co-ordination by Fixed Time Plans
7.4.1
LIPT command - invalid command lines
Reference : MCE 0360C paragraph 4.1.14 VAX SRS 2.5.1, 2.7.4 & 2.9.4
T07-03200
Purpose:
Action:
Result:
7.4.2
To prove that invalid command lines for the LIPT command are rejected.
Enter the following operator commands :
(a) LIPT
(a) LIPT aa
where aa is an invalid plan number,
(a) LIPT aa bbbbb
where aa is a valid plan number, bbbbb is a
valid SCN,
(a) LIPT bbbbb aa
where aa is an invalid plan number, bbbbb is a
valid SCN,
(a) LIPT bbbbb aa
where aa is a valid plan number, bbbbb is an
invalid SCN,
(a) LIPT bbbbb aa c
where aa, bbbbb are valid parameters and c is
a digit or letter.
The commands are all rejected with appropriate error messages.
PLAN Command - Invalid Command Lines
Reference : MCE 0360C paragraph 4.1.14 VAX SRS 2.5.1, 2.7.4
T07-03300
Purpose:
Action:
SYSTEST.DOC
To prove that invalid command lines for the PLAN command are rejected.
Enter the following command lines :
(a) PLAN
(a) PLAN Taaaaa bb
(a) PLAN Aaaaaa bb
where aa is an invalid sub-area,
(a) PLAN Aaaaaa bb
where aa is a valid sub-area and bb is an
invalid plan number.
(a) PLAN A00000 bb
where bb is plan which is not enabled for
all sub areas by operator command.
Issue 11.0 Page 7-15
System Test Specification for a VAX/VMS UTC System
Result:
7.4.3
666/YJ/16940/000
The commands are all rejected with appropriate error messages.
Listing of stored plans
Reference : MCE 0360C paragraph 4.1.14 VAX SRS 2.9.4
T07-03400
Purpose:
Action:
Result:
7.4.4
To prove the use of the LIPT operator command to list out plan timings.
Enter LIPT operator commands to list out plan timings for :
(a) a single sub-area,
(a) the current running plan,
(a) a single intersection,
(a) a single Pelican.
(a) all sub-areas
(a) all intersections
(a) all pelicans
The requested plan timings are listed on the operators terminal. The
values may be checked against the data source files for plans.
Fixed Time Plan Lines
Reference : VAX SRS 2.7.5
T07-03500
Purpose:
Action:
Result:
To prove that all possible plan line formats are available.
Plan lines including the following points should be prepared.
(a) Containing 16 events.
(a) Cycle time of 255 seconds.
(a) All the possible stage sequences for a given controller.
(a) Specific (Dn) demand for all demand dependant stages.
(a) General demand (DX) for the demand dependant stages.
(a) Containing Nominate and Add pairs.
(a) Containing alternative stage sequences.
(a) Containing the gap-out (GO) bit.
All these forms are available.
T07-03600
Purpose:
Action:
SYSTEST.DOC
To show that the various forms of plans can be used to control junctions.
Observe a junction with a DIPM display as the following plans are
imposed on it :
(a) A plan containing 16 events.
(a) A plan containing a smaller number of events.
Issue 11.0 Page 7-16
System Test Specification for a VAX/VMS UTC System
Result:
7.4.5
666/YJ/16940/000
(a) A plan with a cycle time of 255 seconds.
(a) Plans with all the valid stage sequences for the junction.
(a) Plans containing n-1 demand dependant stages, where n is the number
of stages on the controller.
(a) Plans containing n-1 individually forced demand dependant stages,
where n is the number of stages on the controller.
(a) Plans containing general demand (DX) to a demand dependant stage
to force all demand dependant stages.
(a) Plans giving the time for a non-run demand dependant stage to the
previous and subsequent stages.
(a) Plans containing alternative stage sequences dependant on the state of
the SD reply bits.
(a) Plans containing the GO bit associated with two or more stages.
All the plans behave as required.
Plan Selection by Operator
Reference : MCE 0360C paragraph 4.1.11, 6.4 VAX SRS 2.7.4
Note :
In the following sub-tests MONI displays should be set up for the first and
last controller IRNs in the area and, if possible, a live update graphics
display for these.
The tests should check that the plan is actioned in the controller within 30
seconds of the command being input and that there is a delay of no more
than 6 seconds between the first and last controllers receiving the new
control data.
Initially, all controllers should be running the appropriate timetable
invoked plan.
T07-03700
Purpose:
Action:
Result:
To prove the selection of fixed time plans by operator command.
Ensure that no high priority plans are running.
Enter a PLAN command to select a new plan for a single sub-area.
Messages are written to the VDU to indicate that the timetable plan has
been cancelled and the new plan started.
Use the LSTS command to verify that the sub-area is operating under the
new plan.
T07-03800
Purpose:
Action:
Result:
SYSTEST.DOC
To prove that the operator plan takes priority over any timetable plan
changes.
With the plan introduced by T07-03700 still active, use the TIME
command to adjust the system time to 2 minutes before a timetable plan
change is due for the same sub-area.
Wait for 2 minutes.
A message appears on the VDU to indicate that a plan change is due, but
the operator plan is not changed.
Issue 11.0 Page 7-17
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T07-03900
Purpose:
Action:
Result:
To prove that a second PLAN command by the operator will override the
first.
With the plan introduced by T07-03700 still active, enter a further PLAN
command to select a different plan on all sub-areas.
The new plan is started on all sub-areas and messages are written on the
VDU to indicate that the previous plans have been cancelled and the new
plan started.
T07-04000
Purpose:
Action:
Result:
Action:
Result:
To prove that a manual plan can be cancelled by an operator command.
With the plan introduced by T07-03900 still active, enter an operator
command (XPLA) to cancel the plan on one specified sub-area.
The operator plan is cancelled and the specified sub-area reverts to the
timetable plan. Messages appear on the VDU to confirm this.
Use the LSTS command to check that the timetable plan is now active.
Enter the XPLA command to cancel the plan introduced by T07-03900
on all sub-areas
All sub-areas revert to the timetable plan.
T07-04100
Purpose:
Action:
Result:
Action:
Result:
To prove that plan 0 can be selected by operator command
Enter the PLAN command to select plan 0 on one sub-area.
Use the MONI command to monitor the controllers in the chosen subarea.
All controllers in the chosen sub-area are operating in local mode. No
control bits are being sent to those controllers.
Use the XPLA command to cancel plan 0 in the chosen sub-area.
The controllers in the chosen sub-area revert to the timetable plan.
T07-04200
Purpose:
Action:
Result:
Action:
Result:
To overlay a timetable plan with the same operator plan.
Check the fixed time plan that is currently selected by the timetable.
Enable SCOOT for the sub-area using the SCOO command for the
appropriate region.
Enter an operator command to select the same fixed time plan to override
the SCOOT plan.
The fixed time plan takes priority over the SCOOT plan.
Cancel the operator plan with a XPLA command.
The SCOOT plan is reinstated and a message appears on all terminals.
T07-04300
Purpose:
SYSTEST.DOC
To show that plan changes may be implemented by CAST
Issue 11.0 Page 7-18
System Test Specification for a VAX/VMS UTC System
Action:
Result:
7.4.6
666/YJ/16940/000
Set up CASTs to impose new plans and remove plans from various
controllers. Implement these CASTs both by Operator command and by
timetable.
The plan changes behave in the same manner as if they had not been
included in a CAST.
Smooth and Abrupt Plan Changes
Reference : VAX SRS
T07-04320
Purpose:
Action:
Result:
Action:
Result:
To show that a smooth fixed-time plan change occurs on a controller
when the current and new plans have the same cycle time and both plans
have an overlapping period where the same control bits are sent.
Carry out the following actions :
(a) Prepare or modify two fixed-time plans for one controller that is not
isolated such that they both have same cycle time and there is a
period of at least one second where the same stage is forced in both
plans.
(a) Process both plans and implement the first using the PLAN
command.
(a) Display the controller on DIPM on one monitor and MONI on
another (if available).
(a) After four minutes action the second plan using the PLAN command.
During the overlap period of the two plans DIPM shows the plan change
occurs. Both DIPM and MONI show that the same stage continues until
the next event occurs in the new plan and the stage has completed its
minimum green time.
(a) Modify a timetable to include both of the above plan events with at
least five minutes between each event.
(b) Alter the time to just before the first event.
(b) Display the controller on DIPM.
As for the previous test.
T07-04340
Purpose:
Action:
Result:
SYSTEST.DOC
To show that an abrupt plan change occurs on a controller when the
current and new fixed-time plans have the same cycle time and both plans
have no overlapping period where the same control bits are sent.
(a) Prepare or modify two fixed-time plans for one controller that is not
isolated such that they both have same cycle time and there is no
period where the same stage is forced in both plans.
(b) Process both plans and implement the first using the PLAN
command.
(b) Display the controller on DIPM on one monitor and MONI on
another (if available).
(b) After four minutes action the second plan using the PLAN command.
The second plan is implemented immediately.
Issue 11.0 Page 7-19
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T07-04350
Purpose:
Action:
Result:
To show that an abrupt plan change occurs on a controller when the
current and new fixed-time plans have different cycle times.
(a) Prepare or modify two fixed-time plans for one controller that is not
isolated such that they have different cycle times.
(b) Process both plans and implement the first using the PLAN
command.
(b) Display the controller on DIPM on one monitor and MONI on
another (if available).
(b) After four minutes action the second plan using the PLAN command.
The second plan is implemented immediately.
T07-04360
Purpose:
Action:
Result:
Action:
Result:
7.4.7
To show that an abrupt plan change occurs on a controller that is not
isolated when the current and new plans are of different types.
(a) Implement a valid fixed-time plan on a controller.
(b) After four minutes action a green-wave plan which has an event for
this controller using the GWAV command.
The controller changes to green-wave control when at its event action
time.
Repeat the test for the a number of other combinations of different plan
types between :
(a) Fixed-time.
(a) Local control.
(a) SCOOT.
(a) Green-wave.
The controller changes abruptly to the new mode of control.
Pelican Facilities
Reference : VAX SRS 2.7.4, 2.7.8
T07-04400
Purpose:
Action:
Result:
SYSTEST.DOC
To demonstrate use of the PX bit to simulate pedestrian demand.
Perform the following :
(a) Select a pelican controller which has a plan involving use of the PX
bit.
(a) Monitor the chosen pelican controller using the MONI command.
(a) Using the PLAN command select the appropriate plan for that
pelican.
(a) Check that the PX bit is enabled at the same time as the PV bit is
disabled to open the pedestrian demand window.
(a) Wait until the end of the demand window.
(a) The PX bit is enabled at the same time as the PV bit is disabled.
Issue 11.0 Page 7-20
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
(b) The GX bit is absent soon after in response to the simulated demand.
(b) The PX bit is disabled at the same time as the PV bit is enabled.
T07-04500
Purpose:
Action:
Result:
7.5
Plan Preparation and Amendment
Note :
7.5.1
To demonstrate use of varied durations of pedestrian window within a
pedestrian plan.
(a) Select a pelican controller which has a plan involving use of two
different window durations.
(b) Monitor the chosen pelican controller using the MONI command.
(b) Using the PLAN command select the appropriate plan for that
pelican.
(b) Check that the PV bit is disabled at the times in the plan which denote
the start of the demand window.
(b) Check that the PV bit is enabled at the times in the plan which denote
the end of the demand window.
(b) Cause pedestrian demands both inside and outside the limits of each
window.
(a) The PV bit will respond as requested by the pelican plan.
(b) For any demands within the window limits the GX bit is absent soon
after in response to the demand.
(b) No action is taken for any demands outside the window limits.
Section 6.1 contains tests for plan correction and modification as part of
the data preparation process. This section details tests carried out for a
new system and through the operator command PPRP.
On-line Plan Preparation
T07-04510
Purpose:
Action:
Result:
To show that invalid command lines for the PPRP command are rejected.
Enter the following commands from the "-" prompt :
(a) PPRP nnn
where nnn is an invalid plan number
(a) PPRP t nnn
where nnn is a valid plan number and t is
an invalid plan type
(a) PPRP emmmmm nnn
where e is an invalid equipment type,
mmmmm is a valid SCN, and nn is a valid
plan
(a) PPRP emmmmm t nnn
where emmmmm is a valid equipment and
SCN, t is a valid plan type and nnn is an
invalid plan number
The commands are all rejected with the appropriate error messages.
T07-04520
Purpose:
SYSTEST.DOC
To prepare fixed-time plans.
Issue 11.0 Page 7-21
System Test Specification for a VAX/VMS UTC System
Action:
Result:
Action:
SYSTEST.DOC
666/YJ/16940/000
From the UTC traffic prompt enter the command :
PPRP
The on-line plan preparation screen is displayed.
Edit selected plans with both valid and invalid data. In particular, set up
the following conditions :
(a) For an intersection, set two successive stages to be the same. This
should be accepted.
(a) For a pelican, set the cycle time equal to the minimum cycle time
allowed (minimum green to vehicles + the "NOT GX" period). This
should be accepted.
The following requirements should be borne in mind when producing test
plans and examples produced which adhere to and violate each point.
(a) A plan shall consist of an Intersection SCN, a cycle time and for each
step in the plan a "stage action" and a start time;
(a) A stage action shall consist of one or more stage identifiers, "A" to
"H", optionally underlined, followed by an optional "!";
(a) At least one event in a plan must contain only one stage force bit;
(a) The start time of each stage is zero or greater and less than the cycle
time;
(a) The start time of a stage is at least one second greater than the
previous stage;
(a) The duration of each stage is not less than the stage minimum green
plus the preceeding inter-green;
(a) The cycle time is greater than the sum of each stage's upper minimum
green and preceeding upper inter-green time + 5 seconds;
(a) The durations of alternative stage sequences are the same;
(a) Only one alternative stage sequence is allowed;
(a) The cycle time is less than 256 seconds;
(a) All stages configured on a controller do no have to be mentioned in
the plan. Any missing stages are designated as omitted;
(a) Only the stage to stage transitions specified by the user in the UTC
System data can occur;
(a) Any stages flagged as demand dependant by the user in the UTC
System data have either :• The stage is underlined, indicating that either the stage D bit
(where configured), should be sent with the F bit, otherwise
the DX bit should be sent with the F bit.
• The stage is not underlined, indicating that the stage F bit
should be sent by itself. This is known as a nominate stage
action. This must be followed by an added stage action
indicating that the same stage F bit should be sent together
with that for the nominate stage. Together these are known as
a nominate-add pair. An added stage action is a non-demand
dependent stage. The result is that if the demand dependent
stage does not operate its time should be given to the added
stage.
Issue 11.0 Page 7-22
System Test Specification for a VAX/VMS UTC System
Result:
Action:
Result:
Action:
Result:
Action:
Result:
666/YJ/16940/000
(a) Plans which have multiple demand dependent events or gap-out
events may be marked such that timing errors are ignored.
(a) Individual plan events may be marked such that plan compliance is
inhibited.
(a) Up to 10 previous plans can be selected from a list of historical plan
data.
For Pelican plans the following requirements should be tested :
(a) Each 'non-green to vehicle' stage is not less than the minimum limits
set in the system data for the controller,
(a) Each 'vehicle green' stage is greater than or equal to the specified
minimum limit.
Invalid data in some of the above requirements will not be accepted at the
data entry stage (for example - cycle time greater than 256 seconds). The
remainder will raised as faults when processed.
From the Process Menu select the plans which have been modified and
process them.
The plans are prepared in turn and the invalid data is rejected with
messages indicating the error.
Correct the invalid data and re-prepare the rejected plans in line with the
specification in paragraph 2.5.
All plans are accepted.
Enter the command :
UPDA PLANS
After a short delay the processed plans are installed and used by the
system.
T07-04530
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
To show that timings checks can be inhibited for a plan.
Edit a previously created fixed-time plan. Press the return key.
The plan is accepted with no error message.
(a) Edit the same plan, modifying one or more events such that minimum
green plus intergreen values are less than the values defined in the
controller timings data.
(b) Press the return key.
An error message is output and the plan is not created.
Inhibit timings checks for the plan. Press the return key.
No warining message is output and the plan is accepted.
T07-04540
Purpose:
Action:
SYSTEST.DOC
To show plan compliance checks can be inhibited for a complex event in a
plan.
(a) Create a test controller in data preparation with 4 stages, such that
stages B, C and D are demand- dependent and the data format
contains the GO bit. Set a minimum green time of 15 seconds for
each stage and all intergreens as valid with values of 5 seconds.
Issue 11.0 Page 7-23
System Test Specification for a VAX/VMS UTC System
Result:
Action:
Result:
666/YJ/16940/000
(b) Create the following fixed-time plan for the controller:
CY 100, A 0, BCD!* 20, BCD* 60, D 80
(b) Process the plan and implement it for this controller.
(b) Set up an OVRB screen on a terminal and DIPM on another.
(b) After 4 minutes have elapsed, when the first complex event is reached
overwrite the reply bits with intergreen for 5 seconds and then stage
B.
(b) At 40 seconds on the cycle counter in DIPM, overwrite the reply bits
with intergreen for 5 seconds and then stage C.
(b) At 61 seconds of the cycle counter reply with intergeen, cancelling
overwrite after 2 seconds.
No fault is raised.
(a) Modify the above plan such that plan compliance inhibit is removed
from both the complex events.
(b) Process the plan and ensure that it is implemented.
(b) Repeat the previous test, items (d) to (g).
A plan compliance fault is raised.
T07-04550
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
To show that multiple pelican events may be created with less than the
minimum timings between each event when marked as "no timings
checks" in plan preparation.
Enter plan preparation and edit an existing pelican plan with two events in
the cycle. Process the plan.
No message is output and the plan is processed successfully.
Modify the plan such that the time between events is less than the
minimum not-green to vehicles plus the minumum green to vehicles
values. Process the plan.
An error is raised and the plan is not created.
Re-edit the same plan but mark it for non-checking of timings. Process the
plan.
The plan is processed without any messages.
T07-04560
Purpose:
Action:
SYSTEST.DOC
To show that optional parameters may be used to modify plans.
Enter the following command lines using the "-" prompt :
(a) PPRP Jnnnnn
where nnnnn is a valid junction SCN
(a) PPRP Pnnnnn
where nnnnn is a valid pelican SCN
(a) PPRP ennnnn t
where ennnnn is a valid equipment SCN
and t a valid plan type
(a) PPRP ennnnn t mmm
as above, with mm a valid plan number
for type t
(a) PPRP ennnnn mmm
as above, without the plan type. mmm
can be within the range 0 to 137,
Issue 11.0 Page 7-24
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
inclusive.
T07-04570
Purpose:
Action:
Result:
Action:
Result:
To prepare green wave data.
(a) From the "-" prompt enter the command :
PPRP GREENWAVE nnn where nnn is a valid green wave plan
number
(b) Attempt to include the following invalid data :
• A delay greater than 750 seconds
• A leaving window value greater than 255 seconds.
• More than one stage force bit.
• A GO bit.
• A demand-dependent stage without a specific demand or DX bit
present.
• An alternative stage sequence.
• More than one event for an equipment.
• A second line repeating one equipment, with different times.
(b) Press return to process the plan.
Invalid data is rejected with suitable messages.
Correct the invalid data. Reprocess the green wave plan.
The plan prepares successfully.
T07-04580
Purpose:
Action:
Result:
Action:
Result:
Action:
To prepare SCOOT translation plan data.
(a) From the "-" prompt enter the command :
PPRP SCOOT nnn
where nnn is a valid SCOOT translation
plan number
(b) Attempt to include the following invalid data :
• for multi-nodes, one or more controllers are on SCOOT
control and others in local mode.
(b) Press return to process the plan.
Invalid data is rejected with suitable messages.
Correct the invalid data. Reprocess the plan.
The plan prepares successfully.
(a) Start data preparation, and from the Edit SCOOT data option change
the removeable stage on a node or the equipment SCNs on a node
such that a translation plan will become invalid.
(b) Process the data and exit data preparation.
(c) From the "-" prompt enter the command :
• PPRP SCOOT nnn
SYSTEST.DOC
where nnn is the SCOOT translation plan
number modified above.
Issue 11.0 Page 7-25
System Test Specification for a VAX/VMS UTC System
Result:
Action:
Result:
7.5.2
666/YJ/16940/000
(d) Press return to process the plan.
Invalid data is rejected with suitable messages.
Correct the invalid data. Reprocess the plan.
The plan prepares successfully.
Non-operational system plan preparation
Note :
These tests correspond to installing a new system on the VAX, where
there is no current traffic system operating.
T07-04590
Purpose:
Action:
Result:
7.5.3
To ensure that plan preparation can be executed from a non-operational
system.
Force a non-operational system by executing the following :
(a) Enter "KILL H01000"
(a) Change to the "$" prompt
(a) Enter :
SET UIC [174,0]
SET DEF UTC_COM
@TR_UNINS
(a) Start data preparation by :
@DATA_PREP
(a) Choose the Process menu, Plan correction option.
(a) Alter some plans as described in test T07-04520.
(a) Process the plans
As for test T07-04520.
Temporary Plan Amendments
Reference : MCE 0360C paragraph 6.5 VAX SRS 2.7.5
T07-04600
Purpose:
Action:
Result:
SYSTEST.DOC
To show invalid command lines are rejected for VARY commands.
Enter the following command lines using the "-" prompt:
(a) VARY
(a) VARY Jaaaaa
where aaaaa is an invalid SCN
(a) VARY Jaaaaa A+10 B-10
where aaaaa is a valid SCN
(a) VARY Jaaaaa A+1 B-1 00:67 where aaaaa is a valid SCN
(a) VARY Jaaaaa hh:mm
where aaaaa is a valid SCN not
currently under fixed time control
and hh:mm is a valid time.
The commands are rejected with the appropriate error message.
Issue 11.0 Page 7-26
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T07-04630
Purpose:
Action:
Result:
To show that VARY can only be performed on an equipment on a fixedtime plan.
Attempt to implement VARY on a junction under the following
conditions :
(a) isolated by fault or link-list;
(a) SCOOT plan;
(a) Green wave plan;
(a) local plan (by timetable or operator control).
The commands are rejected with the appropriate error message.
T07-04650
Purpose:
Action:
Result:
Action:
SYSTEST.DOC
To show that when the VARY display is active for an equipment, this will
be terminated if the plan changes.
For a junction with both fixed-time and translation plans carry out the
following :
(a) Create two events in the current timetable :
• implement a fixed-time plan
• the second event to occur five minutes later, implementing a
SCOOT plan.
(a) Process and update the timetable.
(a) Alter the time to that of the first event.
(a) When the first event has been implemented enter :
• VARY Jnnnnn where nnnnn is the SCN of the junction
(a) Modify the events on the display
(a) Wait for the second event to occur
When the second event occurs the VARY display is cancelled and an
appropriate message is displayed.
For a junction with both fixed-time and green wave plans carry out the
following :
(a) Create one event in the current timetable to implement a fixed-time
plan
(a) Process and update the timetable.
(a) Alter the time to that of the first event.
(a) When the first event has been implemented enter :
VARY Jnnnnn
where nnnnn is the SCN of the junction
(a) Modify the events on the display
(a) From another terminal enter the command :
GWAV Gnnnnn
where nnnnn is a valid green-wave SCN
which an event for the equipment in the
VARY display
Issue 11.0 Page 7-27
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
When the green wave event occurs for the junction the VARY display is
cancelled and an appropriate message is displayed.
T07-04700
This test has been superceded.
T07-04800
This test has been superceded.
T07-04900
Purpose:
Action:
Result:
To show that stage durations may be modified by the VARY command,
so long as the duration changes sum to zero and no stage minimum green
times are violated.
(a) For an intersection under fixed time control display the current plan
using the LIPT command.
(b) Monitor the operation of the intersection using the DIPM command.
(b) Enter the command :
VARY Jaaaaa
where aaaaa is the SCN as used in the LIPT and
DIPM commands above.
The on-line plan preparation screen is displayed with the requested SCN
and test plan 1.
T07-05000
This test has been superceded.
T07-05100
This test has been superceded.
T07-05200
This test has been superceded.
T07-05300
Purpose:
Action:
Result:
To show that the VARY command entered with a removal time causes
the equipment to revert to the current timetabled mode of operation.
Repeat T07-04900 with the additional optional time parameter set to 5
minutes after the command is entered.
The VARY is removed at the specified time.
T07-05400
Purpose:
Action:
SYSTEST.DOC
To show that the VARY command may be entered with a removal time of
up to 22 hours.
Repeat T07-04900 with the optional time parameter set to just over 22
hours after the command is entered.
Issue 11.0 Page 7-28
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
The VARY is rejected.
T07-05500
Purpose:
Action:
Result:
To show that a new VARY command entered with or without a removal
time overrides previous commands entered with removal times.
While a VARY with a removal time is active enter another VARY
with/without a removal time.
The new VARY takes over immediately.
T07-05600
Purpose:
Action:
Result:
To prove the above actions for all possible plan action types.
Repeat the tests in this section for junctions whose plans contain the
following:
(a) a single demand action
(a) an all-demands action
(a) a nominate and add pair
(a) an omitted stage
As for the previous tests.
T07-05700
This test has been superceded.
T07-05740
Purpose:
Action:
Result:
To show that on-line plan preparation can view but not modify a
temporary plan.
(a) Enter the following command :
(b) PPRP ennnnn TEST
where ennnnn is an equipment with a plan
modified in the previous tests
(b) Attempt to alter the plan
The plan is displayed but an appropriate error message is displayed when
an attempt is made to modify it.
T07-05760
Purpose:
Action:
Result:
SYSTEST.DOC
To show that the latest 5 plan amendments can be edited for a single
controller.
(a) For a controller that is not isolated, implement a valid fixed-time plan
with the PLAN command.
(b) Modify the plan by VARY and process it
(b) Repeat the process a further 5 times, using some of the historical
plans for the initial values.
(b) Examine the historical list of plans after each change
A new historical plan line is created for each modification.
After the 5th modification, the earliest historical plan is eliminated.
Issue 11.0 Page 7-29
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T07-05770
Purpose:
Action:
Result:
7.5.4
To show that an amended plan will be implemented smoothly if there is an
overlapping period in which the same control bits are sent by the original
and modified plan.
(a) For a controller that is not isolated, implement a valid fixed-time plan
with the PLAN command.
(b) Display the controller on DIPM on one monitor and MONI on
another (if available).
(b) Modify the plan by VARY such that one stage has at least a one
second overlap period in the original and altered plan.
(b) Process the plan and exit from VARY
During the overlap period of the two plans DIPM shows the change from
the original fixed-time to the modified plan. Both DIPM and MONI show
that the same stage continues until the next event occurs in the new plan
and the stage has completed its minimum green time.
Replacement of temporary changes
Reference : MCE 0360C paragraph 6.9 VAX SRS 2.7.5
T07-05800
Purpose:
Action:
Result:
To prove that a temporary plan change (VARY) can be deleted by
operator command.
Use the XPLA command to replace the temporary plan amendments made
in the tests in section , tests T07-04600 to T07-05600.
Use the LSTS command to confirm that the temporary amendments have
been removed.
Use the DIPM display to confirm the timings of the current running
plan(s).
All plans revert to their timetable plan settings.
7.6
Green Waves
7.6.1
Green Waves - General
Reference : MCE 0360C paragraph 4.4.1 VAX SRS 2.7.6
T07-05900
Purpose:
Action:
SYSTEST.DOC
To prove that green waves can be introduced by means of a remote
request.
Check that an appropriate timetable plan is running for the current day
and time.
Call the green wave routes in turn using the OTU switches designated as
remote requests, or the simulator.
Observe the operation of one or more intersections on the route using a
live update display.
Check the stage timings against the green wave timings in the data.
Issue 11.0 Page 7-30
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
The green waves run on intersections for the correct times.
Appropriate messages are displayed when a green wave is initiated and
finishes.
The green wave control is imposed within three seconds of the request.
This can be shown by observing a DIPM display while the request takes
place.
Where a route running bit is allocated it is returned.
When the green wave finishes the intersections on the route are placed on
the plan timings which were in force before the green wave was started.
T07-06000
Purpose:
Action:
Result:
To prove that a green wave route can be extended past the normal
timeout time by re-requesting the same green wave.
Call a green wave route and let it run for 30 seconds. Repeat the call for
the same route and check the extension of the plan running time.
The green wave finishes when the timeout time for the latest green wave
request for that plan has been reached. A message is displayed showing
when this has occurred.
T07-06100
Purpose:
Action:
Result:
To prove that if an intersection is contained within two green wave
routes, then if both these routes are started, the intersection will run to the
timings for the first green wave to arrive at the intersection.
Display a live update picture for the relevant intersection.
Start a green wave by remote request.
Start a second green wave using a junction in the first green wave.
The timings appropriate to the first green wave to arrive are implemented.
T07-06130
Purpose:
Action:
Result:
SYSTEST.DOC
To show that if a controller is unable to change directly to the green wave
stage then it shall cycle the controller on minimum greens until the green
wave is reached.
Create or edit a controller data in data preparation with 4 or more nondemand dependent stages and the only permitted stage changes to be in a
cyclic order, A to B, B to C, etc.
Create or modify a fixed-time plan for this controller with a cycle time of
120 seconds or greater and all stages called in a sequential order.
Implement it by timetable.
Create a green wave plan for this controller using stage A with a start
delay of 40 seconds or greater and a window of 60 seconds or more.
Monitor the controller using the DIPM diplay.
Implement the green wave in such a manner that stage A will have just
finished on the fixed-time plan 30 seconds before it should be start in the
green wave.
30 seconds before the event the controller will be forced to cycle through
the minimum greens until it reaches the green wave stage.
Issue 11.0 Page 7-31
System Test Specification for a VAX/VMS UTC System
Action:
Result:
Action:
Result:
666/YJ/16940/000
Repeat the above test with the controller set to local plan by timetable.
30 seconds before the event the controller will be forced to cycle through
the minimum greens until it reaches the green wave stage.
Modify the above controller such that all transitions are allowed and
repeat the previous tests.
30 seconds before the stage is due the controller will be forced to the
green wave stage.
T07-06170
Purpose:
Action:
Result:
Action:
Result:
To show that an optional clearance stage can introduced after the green
wave stage.
Create a green wave plan with an a green wave stage followed by a
different clearance stage, such that the transition is valid. Allow sufficient
time in the clearance stage to include the intergreen time and minimum
green. Process the plan. Introduce the green wave by the GWAV
command.
The green wave runs with the green wave and clearance stages as defined
in the plan.
Change the duration of the clearance stage such that its duration is 2 or
more seconds less than the sum of the preceding intergreen and minimum
green timings. Process the plan.
The plan is rejected with a warning message.
T07-06200
Purpose:
Action:
Result:
Action:
Result:
7.6.2
To show that the available green waves can be listed.
Enter the command :
WHAT G00000
A list of all green wave SCNs on the system and their names will be
displayed on the terminal screen.
For one or more of the green wave SCNs produced above enter the
command.
LSTG <SCN>
Each equipment in the route is listed together with its offset from the start
of the route, the stage used and its duration.
GWAV Command - Invalid Parameters
Reference : VAX SRS section 2.5.1 & 2.7.6
T07-06300
Purpose:
Action:
SYSTEST.DOC
To prove that invalid command lines for the GWAV command are
rejected.
Enter the following commands a) GWAV
b) GWAV Gaaaaa where aaaaa is an invalid green wave SCN.
c) GWAV Gaaaaa STOP
Issue 11.0 Page 7-32
System Test Specification for a VAX/VMS UTC System
Result:
7.6.3
666/YJ/16940/000
The commands are all rejected with appropriate error messages.
Operator-introduced Green Waves
Reference : VAX SRS section 2.7.6 & 2.5.1
T07-06400
Purpose:
Action:
Result:
To prove that green waves can be introduced by operator command.
Repeat tests T07-05900 to T07-06200 introducing green waves by
operator command instead of by remote request.
The results will be the same as for tests T07-05900 to T07-06200.
T07-06500
7.6.4
Purpose:
Action:
To prove that green waves can be cancelled by operator command.
Use the GWAV command to introduce a green wave route.
Before the green wave has completed enter an XGWA command.
Result:
The green wave is cancelled and the controllers revert to the default plan.
Green Wave Priority
Reference : MCE 0360C paragraph 4.1.4, 4.4.1.7
VAX SRS 2.7.6
T07-06600
Purpose:
Action:
Result:
Action:
Result:
7.6.5
To prove that a green wave request takes priority over timetable, operator
and SCOOT plans.
Select a green wave route from the data with at least 4 controllers in 3
different sub-areas.
Set the controllers so that one is under timetable plan control,
one is under operator plan control,
one is under SCOOT plan control,
one is isolated due to fault.
Start the selected green wave using the GWAV command.
All controllers at the appropriate offset change to the selected stage for
the green wave.
Cancel the green wave using the GWAV command.
The controllers revert to their original plans.
Green Wave Display
Reference : VAX SRS 2.7.6
SYSTEST.DOC
Issue 11.0 Page 7-33
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T07-06700
Purpose:
Action:
Result:
7.6.6
To show that a green wave may be displayed using TDD.
Set up TDD to show all the controllers on a green wave route. Start the
green wave on one terminal while observing the TDD display on a PC.
The display corresponds with the green wave plan.
Multiple Green Waves
Reference : MCE 0360C paragraph 4.4.1.6
VAX SRS 2.7.6
T07-06800
This test has been superceded.
T07-06810
Purpose:
Action:
Result:
7.6.7
To prove that up to 32 green waves can be operational at the same time.
Prepare 33 green wave plans, each with one or more junction or pelican
controllers used exclusively on that plan. Use the same start delay for all
controllers and a window duration of 180 seconds.
Start each green wave in succession using the GWAV command.
The first 32 green waves are accepted and run to completion. The last
command entered is rejected with an appropriate message.
Green Waves on Networked Systems
Reference : VAX SRS
T07-06820
Purpose:
Action:
Result:
To show that a green wave can chain a further 3 green waves on different
TCCs.
Note :
This test requires a network of four TCC computers.
Ensure that the links to all four TCCs are functioning.
Create green wave plans for three TCCs that contain valid street
equipment and the SCN of a green wave on another TCC. The associated
plan for a green wave SCN on TCC1 should call a green wave SCN on
TCC2, whose associated plan contains the SCN of a green wave on
TCC3. Finally the associated green wave plan on TCC3 should contain
the SCN of a green wave on TCC4.
Implement the green wave on TCC1 by the command GWAV.
All four green waves run on all the equipment specified.
7.7
Manual Waves
7.7.1
Manual Waves - General
Reference : VAX SRS
SYSTEST.DOC
Issue 11.0 Page 7-34
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T07-06850
Purpose:
Action:
Result:
To show that invalid parameters for the MWAV command are rejected.
Enter the following command lines :
MWAV
MWAV nn where nn is an invalid green wave plan number
MWAV Jnnnnn
where nnnnn is a valid intersection SCN
MWAV nn >Tmmmmm
where nn is a valid green wave number and
mmmmm a valid terminal SCN
MWAV nn where nn is an unconfigured green wave plan number
(a) to (d) are rejected with appropriate error messages. (d) is rejected with
a "no equipment on route" message.
T07-06860
Purpose:
Action:
Result:
Action:
Result:
To show that a manual wave can only be called from a terminal with
command level 12 or greater.
Enter MWAV on a terminal with command level 11 or lower.
The command is rejected.
Enter MWAV on a terminal with command level 12 or greater.
The command is accepted and the manual wave screen is displayed.
T07-06870
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
SYSTEST.DOC
To show the operation of a manual wave.
Select a valid green wave plan such that all equipment on the plan is not
isolated.
Implement the manual wave using the MWAV command.
Set various faults on one equipment.
The manual wave display is shown. An asterisk is displayed to the left of
the faulty equipment. If it is isolated the asterisk flashes.
Clear the faults on the equipment.
The asterisks are removed.
Select a junction by scrolling up and down the display and press the PF1
key (F1 on a PC terminal). Display the same junction on a MONI display.
The SCN and required stage are shown in bold. A "manual control
started" message is output on the system log for the selected equipment.
The stages on the controller cycle through their minimum greens until the
stage is reached, then the current stage is displayed in bold. The timer
decrements once per second and the required stage is forced on the
MONI display. When the counter reaches zero the manual wave force bits
terminate, the junction returns to its previous mode and a "manual control
finished" message is output for the controller.
Select a junction in the manual wave display and press the PF1 key.
Wait for the timer to decrement to 10.
Before the timer decrements to 1, press the PF1 key.
Issue 11.0 Page 7-35
System Test Specification for a VAX/VMS UTC System
Result:
Action:
Result:
Action:
Result:
7.7.2
666/YJ/16940/000
After a few seconds press the PF3 key.
The SCN and required stage are displayed in bold and manual control
starts on the controller as in the previous test.
The timer value starts to flash.
The timer value is reset to 180 and then starts to decrement.
The manual wave is cancelled on the equipment and a "manual wave
control finished" message is output.
Start a green wave which includes equipment on the MWAV display.
Attempt to select manual control on an equipment that is under green
wave control.
An audible beep is output each time the PF1 key is pressed and manual
control cannot be selected.
With one manual wave display active, enter the MWAV command on
another terminal.
The command is not accepted.
Manual Waves - Networked Systems
T07-06880
Purpose:
Action:
Result:
Action:
Result:
7.8
To show the effect of a disconnected link between the TMC and a TCC.
On a networked system with a TMC and one or more separate TCCs start
a manual wave on a terminal directly connected to the TMC.
The manual wave is started, faulty equipment is flagged, the current stage
is updated and a message is output to the system log. When the manual
wave is terminated a message is output to the system log,
Repeat the above test and disconnect the TMC from a TCC while the
manual wave is running.
The manual wave starts as for the previous test and when the TMC and
TCC are disconnected the display shows "xxx" in the timer field for all
equipment connected to the TCC. For each of these equipment that was
under manual control a "manual control cancelled - link down" message is
output.
Automatic Plan Selection
Reference : VAX SRS 2.7.7
7.8.1
Automatic Plan Selection Test data
T07-06900
Purpose:
Action:
Result:
Action:
SYSTEST.DOC
To set up test data.
Enter the DBAS command.
Data preparation will be invoked.
Define 5 flow detectors in a group for a particular sub-area.
Define 5 queues in a second group for the same SCN.
Issue 11.0 Page 7-36
System Test Specification for a VAX/VMS UTC System
Action:
Result:
7.8.2
666/YJ/16940/000
Define 5 occupancy detectors in a third group for the same SCN.
Define a queue delay for each of the queues.
Define a STANDARD value for each of the flow detectors - this is the
value which the 'running average' flow must reach in order to cause the
UP/DOWN counter to be incremented/decremented.
Define a THRESHOLD value for each of the flow detectors - this is the
value which must be reached by the UP/DOWN counter in order to set
the flow detector 'ON'.
Define UP and DOWN thresholds for each occupancy detector - these are
the values the averaged occupancy must reach in order to turn on /off
congestion.
Define a SMOOTHING FACTOR (%) for each occupancy detector. This
is the percentage of the current occupancy and 100% of the averaged
occupancy used to calculate the new average occupancy.
Define the APS PLAN PRIORITY, APS PLAN MASK and APS PLAN
GROUPS as follows:
Priority(low-high) 1 2 3 4 5 6
Plan number
15 14 13 12 11 10
(1-29)
APS PLAN MASKS
Sub area Priority Mask (+=or,.=and,Q,V,O)
15
6
V
15
5
Q
15
4
O
15
3
V.Q
15
2
V.O
15
1
V.Q.O
APS PLAN GROUPS
Sub area Trigger Detector SCNs
Queue Group
15
1
-----Occupancy Group 15
1
-----Volume Group
15
1
-----Process and install the data on the relevant UTC computer.
The new data will now be ready for use.
Start APS
T07-07000
Purpose:
Action:
Result:
SYSTEST.DOC
To ensure that APS is not currently running.
Enter the LSTS command for the sub-area containing the detectors set up
for APS above.
APS will not now be active for these sub-areas.
Issue 11.0 Page 7-37
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T07-07100
Purpose:
Action:
Result:
To start APS for the sub-area previously set-up.
Enter the SAPS command for the sub-area containing the detectors set up
for APS above.
APS will now be active for this sub-area.
7.8.3
Selection by one detector in a group
7.8.3(a)
Volume detectors
T07-07200
Purpose:
Action:
Result:
To check that an APS plan change will be triggered when one of the flow
detectors belonging to a group of flow detectors causes the volume
detector counter to turn on.
Simulate a continuous flow on one of the flow detectors in group 1 > the
'one minute count threshold start value'.
Plan 10 will be activated by APS after the 'up/down threshold start value'
number of minutes.
T07-07300
Purpose:
Action:
Result:
To check that the selected plan will revert to that required by the
timetable when no APS activation is requested.
Immediately reduce the flow of vehicles at the detector.
The flow detector counter will be turned off.
The priority level will be reduced by 1 every N minutes until it reaches
zero (where N is the configured value).
At each priority level the appropriate plan will be selected.
T07-07400
Purpose:
Action:
Result:
To check that an APS plan change will be triggered when more than one
of the flow detectors belonging to a group of flow detectors causes the
volume detector output to turn on.
Simulate a continuous flow on three of the flow detectors in group 1 > the
'one minute count threshold start value'.
Plan 10 will be activated by APS after the 'up/down threshold start value'
number of minutes'.
T07-07400
Purpose:
Action:
Result:
SYSTEST.DOC
To check that the selected plan remains selected as long as one of the
group of detectors is on, and is causing the volume detector output to
remain on.
Immediately reduce the flow of vehicles at two of the detectors in the
group.
The plan selected by APS will remain selected, since one of the counters
is still causing the flow detector counter to remain on.
Issue 11.0 Page 7-38
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T07-07500
Purpose:
Action:
7.8.3(b)
To check that the selected plan will revert to that required by the
timetable when no APS activation is requested.
Reduce the flow of vehicles at the third detector in the group.
The priority level will be reduced by 1 every N minutes until it reaches
zero (where N is the configured value).
At each priority level the appropriate plan will be selected.
Queue detectors
T07-07600
Purpose:
Action:
Result:
To check that an APS plan change will be triggered when a queue is
detected at one of the queue detectors belonging to a group of APS queue
detectors.
Simulate a queue on one of the queue detectors.
The queue detector counter will be turned on.
Plan 11 will be activated by APS.
The relevant queue detector wall map lamp will be lit.
The operational alarm lamp will light.
T07-07700
Purpose:
Action:
Result:
To check that the selected plan will revert to that required by the
timetable when no APS activation is requested.
Immediately simulate a clearance of the queue.
The queue detector counter will be turned off after the the time defined
for the delay counter.
The relevant queue detector wall map lamp will go out.
The priority level will be reduced by 1 every N minutes until it reaches
zero.
At each priority level the appropriate plan will be selected.
T07-07800
Purpose:
Action:
Result:
To check that an APS plan change will be triggered when queues are
detected at all of the queue detectors belonging to a group of APS queue
detectors.
Simulate a queue on all five of the queue detectors.
The queue detector counter will be turned on.
Plan 11 will be activated by APS.
T07-07900
Purpose:
SYSTEST.DOC
To check that the APS plan remains selected as long one or more queues
are detected at queue detectors belonging to a group of APS queue
detectors.
Issue 11.0 Page 7-39
System Test Specification for a VAX/VMS UTC System
Action:
Result:
666/YJ/16940/000
Simulate a clearance of three of the queues.
The plan selected by APS will remain selected, since the queue detector
counter is still being caused to remain on.
T07-08000
Purpose:
Action:
Result:
To check that the APS plan remains selected as long one or more queues
are detected at queue detectors belonging to a group of APS queue
detectors.
Simulate a clearance of all but one of the queues.
The plan selected by APS will remain selected, since the queue detector
counter is still being caused to remain on.
T07-08100
Purpose:
Action:
Result:
7.8.3(c)
To check that the selected plan will revert to that required by the
timetable when no APS activation is requested.
Simulate a clearance of all the queues.
The queue detector counter will be turned off after the the time defined
for the delay counter.
The priority level will be reduced by 1 every N minutes until it reaches
zero.
At each priority level the appropriate plan will be selected.
Occupancy detectors
T07-08200
Purpose:
Action:
Result:
To check that an APS plan change will be triggered when congestion is
detected by an occupancy detector belonging to a group of APS
occupancy detectors.
Simulate a congestion on one of the occupancy detectors.
The occupancy detector counter will be turned on.
Plan 12 will be activated by APS.
T07-08300
Purpose:
Action:
Result:
7.8.4
To check that the selected plan will revert to that required by the
timetable when no APS activation is requested.
Immediately simulate a clearance of the congestion.
The occupancy detector counter will be turned off after the the time
defined for the delay counter.
The priority level will be reduced by 1 every N minutes until it reaches
zero.
At each priority level the appropriate plan will be selected.
Combined flow, queue and occupancy detection
NOTE: The following two tests should be carried out sequentially.
SYSTEST.DOC
Issue 11.0 Page 7-40
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T07-08400
Purpose:
Action:
Result:
To check that the correct APS plan change is triggered when
- one of the flow detectors belonging to a group of flow detectors causes
the volume detector counter to turn on;
AND
- a queue is detected at one of the queue detectors belonging to a group
of APS queue detectors.
Simulate a continuous flow on one of the flow detectors in group 1 > than
the 'one minute count threshold start value'.
Simulate a queue on one of the queue detectors in group 2.
The queue detector counter will be turned on.
Plan 11 will be activated by APS.
Once the threshold value has been reached the UP/DOWN counter will be
incremented each minute.
Plan 12 will be activated by APS after the 'up/down threshold start value'
number of minutes', i.e. when the volume detector output is turned on.
Plan 13 will be activated on the next cycle.
T07-08500
Purpose:
Action:
Result:
To check that the correct APS plan change is triggered when:
- one of the flow detectors belonging to a group of flow detectors causes
the volume detector counter to turn on;
AND
- a queue is detected at one of the queue detectors belonging to a group
of APS queue detectors;
AND
- congestion is detected by one of the occupancy detectors belonging to a
group of APS occupancy detectors.
Continue simulating a continuous flow on one of the flow detectors in
group 1 equal to the 'one minute count threshold start value'.
Continue simulating a queue on one of the queue detectors.
Simulate congestion on one of the occupancy detectors.
The occupancy detector will be turned on (group 3).
Plan 14 will be activated by APS since the THRESHOLD value has
already been reached and the volume detector output is turned on.
Plan 15 will be activated on the next cycle.
T07-08600
Purpose:
Action:
Result:
SYSTEST.DOC
To check that a higher priority APS plan will be immediately selected.
Simulate the disappearance of the queue from the queue detector, and
congestion from the occupancy detector.
The queue detector counter will be turned off.
Issue 11.0 Page 7-41
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
The flow detector counter will remain on.
Plan 10 will be activated by APS on the next cycle.
T07-08700
Purpose:
Action:
Result:
Action:
Result:
7.8.5
To check that if the nominated APS plan is of a lower priority than the
current APS plan, the APS plan with a priority of one less than the current
plan will be selected.
Simulate a continuous flow on one of the flow detectors equal to the 'one
minute count threshold start value'.
Wait until the volume detector counter is turned on.
Plan 10 will be activated by APS when the volume detector output is
turned on.
Simulate a queue in the queue groups and congestion in the occupancy
group.
The queue detector counters for both groups will be turned on.
Since all groups are now active, the nominated APS plan will be plan 15
with a priority of 1 (lowest). The APS plan with a priority of one lower
than the current plan will be selected i.e. plan 11.
After each subsequent cycle the plan with one priority lower will be
selected until eventually plan 15 is selected. The order of selection will be
11, 12, 13, 14, 15.
Selection by all detectors in a group
T07-08800
Purpose:
Action:
Action:
Result:
7.8.5(a)
To show that it is possible to specify that all detectors in a group must be
on before a plan is triggered by APS.
Re-define the trigger in the plan groups as follows:
APS PLAN GROUPS
Sub area Trigger Detector SCNs
Queue Group
29
0
-----Occupancy Group 29
0
-----Volume Group
29
0
-----Process and install the data on the relevant UTC computer.
The new data will now be ready for use.
Volume detectors
T07-08900
Purpose:
Action:
SYSTEST.DOC
To check that an APS plan change will be triggered if all of the flow
detectors belonging to a group of flow detectors causes the volume
detector counter to turn on.
Simulate a continuous flow on one of the flow detectors in the group >
the 'one minute count threshold start value'.
Issue 11.0 Page 7-42
System Test Specification for a VAX/VMS UTC System
Result:
Action:
Result:
666/YJ/16940/000
No plans will be activated.
Simulate a continuous flow on the other flow detectors in the group > the
'one minute count threshold start value'.
Plan 10 will be activated by APS after the 'up/down threshold start value'
number of minutes'.
T07-09000
Purpose:
Action:
Result:
7.8.5(b)
To check that the selected plan will revert to that required by the
timetable when no APS activation is requested.
Immediately reduce the flow of vehicles at one of the detectors.
The flow detector counter will be turned off.
The priority level will be reduced by 1 every N minutes until it reaches
zero.
At each priority level the appropriate plan will be selected.
Queue detectors
T07-09100
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
7.8.5(c)
To check that an APS plan change will be triggered when queues are
detected at all of the queue detectors belonging to a group of APS queue
detectors.
Simulate a queue on one of the queue detectors.
The queue detector counter will NOT be turned on.
Plan 11 will be activated by APS.
Simulate queues on all of the queue detectors in the group.
The queue detector counter will be turned on.
Plan 11 will be activated by APS.
Stop simulating the queue.
The queue detector will be turned off after the the time defined for the
delay counter.
The priority level will be reduced by 1 every N minutes until it reaches
zero.
At each priority level the appropriate plan will be selected.
Occupancy detectors
T07-09200
Purpose:
Action:
Result:
SYSTEST.DOC
To check that an APS plan change will be triggered when congestion is
detected by all the occupancy detector belonging to a group of APS
occupancy detectors.
Simulate a congestion on one of the occupancy detectors.
The occupancy detector counter will NOT be turned on.
No plans will be activated by APS.
Issue 11.0 Page 7-43
System Test Specification for a VAX/VMS UTC System
Action:
Result:
Action:
Result:
7.8.6
666/YJ/16940/000
Simulate congestion on all of the occupancy detectors.
The occupancy detector counter will be turned on.
Plan 12 will be activated by APS.
Immediately simulate a clearance of the congestion on one of the
detectors.
The occupancy detector counter will be turned off after the the time
defined for the delay counter.
The priority level will be reduced by 1 every N minutes until it reaches
zero.
At each priority level the appropriate plan will be selected.
Groups 'OR' option
T07-09300
Purpose:
Action:
To show that groups may be 'or'ed together.
Define a PLAN SELECTION MASK and APS PLAN LIST as follows:
Action:
Result:
Priority(low-high) 1 2 3 4 5 6
Plan number
15 14 13 12 11 10
(1-20)
APS PLAN MASKS
Sub area Priority Mask (+=or,.=and,Q,V,O)
15
6
V+Q+O
15
5
V.O
15
4
Q.O
APS PLAN GROUPS
Sub area Trigger Detector SCNs
Queue Group
1
1
-----Occupancy Group 1
1
-----Volume Group
1
1
-----Process and install the data on the relevant UTC computer.
The new data will now be ready for use.
T07-09400
Purpose:
Action:
SYSTEST.DOC
To check that the correct APS plan change is triggered when:
- one of the flow detectors belonging to a group of flow detectors causes
the volume detector counter to turn on;
OR
- a queue is detected at one of the queue detectors belonging to a group
of APS queue detectors.
Simulate a continuous flow on one of the flow detectors > than the 'one
minute count threshold start value'.
Issue 11.0 Page 7-44
System Test Specification for a VAX/VMS UTC System
Result:
Action:
Result:
Action:
Result:
666/YJ/16940/000
Simulate a queue on one of the queue detectors.
The queue detector counter will be turned on.
Plan 10 will be activated by APS.
Plan 13 will be activated by APS after the 'up/down threshold start value'
number of minutes', i.e. when the volume detector output is turned on.
Stop simulating the queue.
Plan 10 will be activated by APS on the next cycle.
Stop simulating the flow.
APS will no longer activate a plan and will cycle down to the scheduled
plan.
T07-09500
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
SYSTEST.DOC
To check that the correct APS plan change is triggered when:
- one of the flow detectors belonging to a group of flow detectors causes
the volume detector counter to turn on;
OR
- a queue is detected at one of the queue detectors belonging to a group
of APS queue detectors;
OR
- congestion is detected by one of the occupancy detectors belonging to a
group of APS occupancy detectors.
Simulate a continuous flow on one of the flow detectors > than the 'one
minute count threshold start value'.
Plan 10 will be activated by APS after the 'up/down threshold start value'
number of minutes', i.e. when the volume detector output is turned on.
Stop simulating the flow.
The priority level will be reduced by 1 every N minutes until it reaches
zero.
At each priority level the appropriate plan will be selected.
Simulate a queue on one of the queue detectors.
Plan 10 will be activated by APS.
Stop simulating the queue.
The priority level will be reduced by 1 every N minutes until it reaches
zero.
At each priority level the appropriate plan will be selected.
Simulate congestion on one of the occupancy detectors.
Plan 10 will be activated by APS.
Stop simulating the congestion.
The priority level will be reduced by 1 every N minutes until it reaches
zero.
At each priority level the appropriate plan will be selected.
Simulate a queue on one of the queue detectors and congestion on one of
the occupancy detectors.
Issue 11.0 Page 7-45
System Test Specification for a VAX/VMS UTC System
Result:
Action:
Result:
7.8.7
666/YJ/16940/000
Plan 12 will be activated by APS.
Stop simulating the congestion.
The priority level will be reduced by 1 every N minutes until it reaches
zero.
At each priority level the appropriate plan will be selected.
APS Test Mode
T07-09600
Purpose:
Action:
Result:
To ensure that APS is not running.
Enter the XAPS command for the sub-area containing the detectors set up
for APS above.
APS will now not be active for these sub-areas, if it was already active a
message will be output to indicate this.
T07-09700
Purpose:
Action:
Result:
Action:
Result:
To run APS in test mode for a sub-area previously set-up.
Enter the TAPS command for the sub-area containing the detectors set up
for APS above.
APS will now be active in test mode for this sub-area.
Repeat some of the APS tests defined above, entering flow and queue
values as parameters of the TAPS command instead of using the
simulators.
The results will be the same as above EXCEPT that messages will be
output to indicate the actions that would have been taken if APS had been
running live.
T07-09800
Purpose:
Action:
Result:
Action:
Result:
To show that APS cannot be run in test mode if it is already running 'live'
for the same sub-area.
Enter the SAPS command for a sub-area.
APS will be started for this sub area.
Enter the TAPS command for the same sub area.
An error message will be output indicating that APS is already running in
another mode.
T07-09900
Purpose:
Action:
Result:
SYSTEST.DOC
To show that APS test data cannot be entered if APS is not in test mode.
Ensure that APS is not running 'live' or in test mode for a selected subarea.
Enter the TAPS command with test data for the same sub area.
An error message will be output indicating that APS is not in test mode.
Issue 11.0 Page 7-46
System Test Specification for a VAX/VMS UTC System
7.9
Signal Co-ordination by SCOOT
7.9.1
Implementation of SCOOT by node
666/YJ/16940/000
Reference : MCE 0360C paragraph 4.2.3
VAX SRS 2.7.8
T07-10000
Purpose:
Action:
Result:
To confirm that, before SCOOT is implemented, the correct fixed time
plan is in operation, unaffected by any new timings generated by the
SCOOT model.
Use the DIPM command on a junction capable of being controlled by
SCOOT to show the current fixed time plan number in operation and that
the junction is being controlled in the compliance with the plan.
Use the SEES display for the equivalent node to show that SCOOT is still
making stage change decisions and then use the VALU IMPL command
to confirm that SCOOT is aware that its timings are not being
implemented.
The stages being sent out to the street should be those of the current
fixed-time plan not those chosen by SCOOT.
T07-10100
Purpose:
Action:
Result:
To confirm that SCOOT control may be implemented on a node by
operator command.
Select SCOOT control on a node (which is not isolated by fault) by use of
the SCOO command from an operator's terminal.
Use the VALU IMPL command to confirm that SCOOT control is now
implemented. On other terminals use the DIPM display and SEES
SCOOT monitor display to show that the junction (and equivalent node)
is being given stage requests determined by SCOOT and that the stage
control bits being sent to the street are those given by SCOOT.
T07-10200
Purpose:
Action:
Result:
To confirm that SCOOT control may be removed from a node by
operator command.
Cancel SCOOT control on the node above by use of the XSCO
command.
Use the VALU IMPL command to confirm that SCOOT control is no
longer implemented. Use the DIPM display and SEES SCOOT monitor
display to show that the junction (and equivalent node) has reverted to
stage requests determined by the current timetable fixed-time plan. The
stage control bits being sent to the street are those given by the current
fixed-time plan.
T07-10300
Purpose:
SYSTEST.DOC
To confirm that SCOOT control may be implemented on a node by
timetable event.
Issue 11.0 Page 7-47
System Test Specification for a VAX/VMS UTC System
Action:
Result:
666/YJ/16940/000
Modify the system time to 3 minutes before a SCOO event for a node in
the current timetable. When the event time has passed use the VALU
IMPL command to confirm that SCOOT control is now implemented.
Use the DIPM display and SEES SCOOT monitor display to show that
the junction (and equivalent node) is being given stage requests
determined by SCOOT. The stage control bits being sent to the street are
those requested by SCOOT.
T07-10400
Purpose:
Action:
Result:
To confirm that SCOOT control may be removed from a node by
timetable event.
Modify the system time to 3 minutes before a cancel SCOOT control
event (XSCO) for a node. When the event time has passed use the VALU
IMPL command to confirm that SCOOT control is no longer
implemented.
Use the DIPM display and SEES SCOOT monitor display to show that
the junction (and equivalent node) has reverted to stage requests
determined by the current timetable fixed-time plan. The stage control bits
being sent to the street are those given by the current fixed-time plan.
T07-10500
Purpose:
Action:
Result:
7.9.2
To confirm that SCOOT control may be imposed or removed from a node
by CAST.
Repeat tests T07-10100 to T07-10400 for SCOO and XSCO commands
contained in casts both by operator and by timetable.
The same results are obtained as before. In particular SCOOT control
imposed from a CAST input as an operator command behaves as operator
imposed SCOOT control and similarly for a timetable imposed CAST.
Implementation of SCOOT by Region
Reference : MCE 0360C paragraph 4.2.3
VAX SRS 2.7.8
T07-10600
Purpose:
Action:
Result:
To confirm that SCOOT control may be implemented on a region by
operator command.
Select SCOOT control on a region by use of the SCOO command.
A message showing that SCOOT control has overlayed the current fixedtime plan is displayed. Use the VALU IMPL command to confirm that
SCOOT control is now implemented on all nodes of the (equivalent)
region(s). On other terminals use the DIPM display and SEES SCOOT
monitor display to show that each junction in the region is being given
stage requests determined by SCOOT.
T07-10700
Purpose:
SYSTEST.DOC
To confirm that SCOOT control may be removed from a region by
operator command.
Issue 11.0 Page 7-48
System Test Specification for a VAX/VMS UTC System
Action:
Result:
666/YJ/16940/000
Cancel SCOOT control on a region by use of the XSCO command.
A message is displayed showing that SCOOT control has terminated. Use
the VALU IMPL command to confirm that SCOOT control is no longer
implemented on any node in the equivalent region(s). Use the MONI
display and SEES SCOOT monitor display to show that each junction in
the region has reverted to stage requests determined by the current
timetable fixed-time plan.
T07-10800
Purpose:
Action:
Result:
To confirm that SCOOT control may be implemented on a region by
timetable event.
Modify the system time to 3 minutes before a SCOO event for a region in
the current timetable. When the event time has passed use the VALU
IMPL command to confirm that SCOOT control is now implemented.
A message showing that SCOOT control has overlayed the current fixedtime plan is displayed. The stage control bits being sent to the street are
those given by SCOOT.
T07-10900
Purpose:
Action:
Result:
To confirm that SCOOT control may be removed from a region by
timetable event.
Modify the system time to 3 minutes before a cancel SCOOT control
event for a region. When the event time has passed use the VALU IMPL
command to confirm that SCOOT control is no longer implemented.
A message is displayed showing that SCOOT control has terminated. The
stage control bits being sent to the street are those given by the current
fixed-time plan.
T07-11000
Purpose:
Action:
Result:
7.9.3
To confirm that SCOOT control may be imposed or removed from a node
by CAST.
Repeat tests T07-10600 to T07-10900 for SCOO and XSCO commands
contained in casts both by operator and by timetable.
The same results are obtained as before. In particular SCOOT control
imposed from a CAST input as an operator command behaves as operator
imposed SCOOT control and similarly for a timetable imposed CAST.
SCOOT Implementation in the Hierarchy of Plan Requests
Reference : MCE 0360C paragraph 4.1.4.1
VAX SRS 2.7.8
T07-11100
Purpose:
Action:
SYSTEST.DOC
To confirm that timetable plan change requests are not implemented while
a junction is under SCOOT control.
Place a junction under SCOOT control then modify the system time to 3
minutes before a plan change event that applies to this junction. When the
event time has passed use the VALU IMPL command to confirm that
Issue 11.0 Page 7-49
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
SCOOT control is still implemented. Use the DIPM display and SEES
SCOOT monitor display to show that the junction (node) is still under
SCOOT control.
A message is displayed showing that the background plan has changed but
has not been implemented. The stage control bits being sent to the street
are those given by SCOOT.
T07-11200
Purpose:
Action:
Result:
To confirm that pending timetable plan change requests are implemented
once a junction is removed from SCOOT control.
Cancel SCOOT control on the junction used in the previous test. Use the
VALU IMPL command to confirm that SCOOT control is no longer
implemented. Use the DIPM plan display and SEES SCOOT monitor
display to show that the junction (node) has reverted to fixed-time
control.
A message is displayed showing that the most recent plan change request
has been implemented. The stage control bits being sent to the street are
those given by the fixed-time plan.
T07-11300
Purpose:
Action:
Result:
To confirm that an operator plan change request will supersede SCOOT
control.
Place a region under SCOOT control then use the PLAN command to
implement an operator plan change on equipments within the region. Use
the VALU IMPL command to confirm that SCOOT control is no longer
implemented. Use the MONI display to show that all junctions are now
under fixed-time control.
A message is displayed showing that the plan change has been
implemented. The stage control bits being sent to the street are those
given by the operator's fixed-time plan.
T07-11400
Purpose:
Action:
Result:
To confirm that SCOOT control which has not been explicitly cancelled
will be re-implemented when a manual plan is cancelled.
Cancel the manual plan on the equipments used in the previous test. Use
the VALU IMPL command to confirm that SCOOT control is
implemented once more. Use the MONI display to show that each
junction is now under SCOOT control.
A message is displayed showing that the region is once more under
SCOOT control.
7.10
Change and Display of SCOOT Parameters
7.10.1
Change and Display of Area level Parameters
Reference : VAX SRS 2.7.8
SYSTEST.DOC
Issue 11.0 Page 7-50
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T07-11500
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
Test each of the area level parameters in turn by operator command. The
following list of commands must be tested:
ADJU - check detector counts mode flag.
ETHR - faulty empty fault threshold for detectors.
FTHR - faulty full fault threshold for detectors.
SPEN - network stop penalty.
TRAF - detector empty checking status.
For each changeable value the following set of tests should be performed:
Use the VALU command to display the parameter:
VALU XXXX
(where 'XXXX' is one of the 4-character mnemonics
from the above list)
The parameter for the SCOOT area is displayed on the terminal. The
setting can be confirmed by using the SEES command.
Use the CHAN command to alter the parameter value. Check the value
has changed using the VALU command and the SEES display. Issue the
command:
CHAN XXXX V
(where 'V' is a valid value)
The parameter value changes as directed.
Use the CHAN command to alter the parameter value but using an invalid
value. Issue the command:
CHAN XXXX V
(where 'V' is an invalid value)
The command is rejected.
T07-11600
Purpose:
Action:
Result:
Test each of the area level parameters in turn by timetable event. The
same commands as in test T07-11500 must be tested.
For each of the changeable parameters include commands in the timetable
and in CASTs to display, modify, and then redisplay the value (at suitably
spaced intervals). Allow the timetable to action the event. Monitor the
value before and after the event is actioned using the operator VALU
command and SEES display.
The results are the same as those produced by the equivalent operator
commands.
T07-11700
Purpose:
Action:
Result:
SYSTEST.DOC
To demonstrate the display only commands at area level.
Use the VALU command to display value of the list of parameters given
below. Show that none of the parameters can be used with the CHAN
command.
AELG - Area End Lag.
ASLG - Area Start Lag.
The parameter value is listed when the VALU command is issued. The
CHAN command is rejected.
Issue 11.0 Page 7-51
System Test Specification for a VAX/VMS UTC System
7.10.2
666/YJ/16940/000
Change and Display of Region Level Parameters
Reference : MCE O360C paragraph 4.2.5, 4.2.6, 4.2.7,
VAX SRS 2.7.8
T07-11800
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
SYSTEST.DOC
Test each of the region level parameters in turn by operator command.
The following list of commands must be tested:
CYOS - status of cycle time optimiser.
FCYT - forced value for cycle time.
FDWN - cycle time optimiser fast down flag.
IRCT - initial region cycle time.
MAXC - maximum region cycle time.
MINC - minimum region cycle time.
TREN - cycle optimiser saturation threshold.
For each changeable value the following set of tests should be performed:
Use the VALU command to display the parameter for all regions:
VALU XXXX R* (where 'XXXX' is one of the 4-character mnemonics
from the above list)
The parameter for all regions is displayed on the terminal. The setting can
be confirmed by using the SEES command for individual regions.
Change the value for 1 region using the command:
CHAN XXXX Raa V
(where 'aa' is a valid region and 'V' is a valid
value)
The value is changed in the data area and can be confirmed with the
VALU and SEES commands.
A message is written to the SCOOT lineprinter to confirm that the change
has been implemented.
The command is recorded in the Command Journal. For FCYT two
CHAN's are recorded - MINC and MAXC.
Repeat the above procedure for all regions using the command
CHAN XXXX R* V (where 'V' is a valid value)
The values are changed for all regions.
Repeat the above procedure and attempt to use an invalid region
parameter
CHAN XXXX N** V
(where 'V' is a valid value)
The command is rejected.
Repeat the above procedure and attempt to use a series of invalid
parameter values
CHAN XXXX R* V (where 'V' takes a series of invalid values)
The commands are rejected.
Issue 11.0 Page 7-52
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T07-11900
Purpose:
Action:
Result:
Test each of the changeable Region level parameters in turn by timetable
event.
For each of the changeable parameters listed in test T08-11800 include
commands in the timetable and in CASTs to display, modify and then
redisplay the value (at suitably spaced intervals). Allow the timetable to
action the event. Monitor the value before and after the event is actioned
using the operator VALU command and SEES display.
The results are the same as those produced by the equivalent operator
commands.
T07-12000
Purpose:
Action:
Result:
7.10.3
To demonstrate the display only commands for regions.
Use the VALU command to display the value of the parameter given
below. Show that it can not be used with the CHAN command.
RCYT - cycle time optimiser fast down flag.
The parameter value is listed when the VALU command is issued. The
CHAN command is rejected.
Change and Display of Node Level Parameters
Reference : MCE O360C paragraph 4.2.5, 4.2.6, 4.2.7,
VAX SRS 2.7.8
T07-12100
Purpose:
Action:
Result:
Action:
SYSTEST.DOC
Test each of the node level parameters in turn by operator command
excluding the translation plan change commands already tested above.
The following list of commands must be tested:
CYFX - cyclic fixed time.
FORC - forced cycling status.
MFBI - model feed-back inhibit.
NSST - named stage start time.
OFST - status of offset optimiser.
SFBI - split feed-back inhibit.
SPLT - status of split optimiser.
TPLN - stage translation plan.
For each changeable value the following set of tests should be performed:
Use the VALU command to display the parameter for all nodes:
VALU XXXX N* (where 'XXXX' is one of the 4-character mnemonics
from the above list)
The parameter for all nodes in all regions is displayed on the terminal. The
setting can be confirmed by using the SEES command for individual
nodes.
Change the value for 1 node using the command:
Issue 11.0 Page 7-53
System Test Specification for a VAX/VMS UTC System
Result:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
666/YJ/16940/000
CHAN XXXX N01111 V (where 'V' is a valid value)
The value is changed in the data area and can be confirmed with the
VALU and SEES commands.
A message is written to the SCOOT lineprinter to confirm that the change
has been implemented.
Repeat the above procedure for all nodes in one region using the
command:
CHAN XXXX RBN* V
(where 'V' is a valid value)
The values are changed only for those nodes in the specified region.
Repeat the above procedure for all nodes in all regions using the
command
CHAN XXXX N* V (where 'V' is a valid value)
The values are changed for all nodes in all regions.
Repeat the above procedure and attempt to use an invalid node
parameter:
CHAN XXXX N** V
(where 'V' is a valid value)
The command is rejected.
Repeat the above procedure and attempt to use a series of invalid
parameter values
CHAN XXXX N* V (where 'V' takes a series of invalid values)
The commands are rejected.
T07-12200
Purpose:
Action:
Result:
Test each of the node level parameters in turn by timetable event,
excluding the translation plan change commands already tested above.
For each of the changeable parameters listed in test T07-12100 include
commands in the timetable, and in CASTs, to display, modify and then
redisplay the value of the parameter for all nodes in one region (at suitably
spaced intervals). Allow the timetable to action the events.
The results are the same as those produced by the equivalent operator
commands.
T07-12300
Purpose:
Action:
SYSTEST.DOC
To demonstrate the display only commands for nodes.
Use the VALU command to display the value of the list of parameters
given below. Show that none of the parameters can be used with the
CHAN command.
IMPL - implementation status.
MPCY - minimum practical cycle time.
NCYT - node cycle time.
NSTG - named stage.
PLAN - last cycles stage lengths.
SRST - stage removable status.
Issue 11.0 Page 7-54
System Test Specification for a VAX/VMS UTC System
Result:
7.10.4
666/YJ/16940/000
The parameter value is listed when the VALU command is issued. The
CHAN command is rejected.
Change and Display of Stage Level Parameters
Reference : VAX SRS 2.7.8
T07-12400
Purpose:
Action:
Result:
To change the default stage length of the named stage by operator
command.
Each of the default stage lengths at a node are changeable.
A change to the default for one stage will affect the default lengths of the
remaining stages. A rule is used whereby the remaining time (positive or
negative) after a default length change is divided amongst the remaining
stages in the cycle up to but not including the named stage. The remaining
time is divided between the remaining stages in proportion to their relative
length at the time the command was issued.
The default length of the stage immediately before the named stage in the
cycle may not be changed by operator command, the value required may
be attained by changing the values of the other stages appropriately.
Attempt to change the default stage length for the named stage of a node
by issuing the command CHAN DEFS. Check that the value is limited by
the expected minimum and maximum for the stage. Using the VALU
command and the SEES display check that the default length of the
named stage has been adjusted correctly and that the remaining time
(either positive or negative) has been added to or subtracted from the
default lengths of the remaining stages in proportion.
The value is changed as directed. Values outside the minimum to
maximum range are rejected. The remaining default stage lengths are
adjusted in proportion.
T07-12500
Purpose:
Action:
Result:
Action:
Result:
SYSTEST.DOC
Change default stage lengths of stages other than the named stage.
Change the default stage length of the stage immediately following the
named stage. Check that values are only permitted between the minimum
and maximum for the stage, check also that the remaining time is divided
between the remaining stages in proportion up to but excluding the named
stage.
The changes are implemented as directed. Values outside the minimum maximum range are rejected. The remaining time is divided between the
other stages in the cycle as expected.
For a node with more than 4 stages change the default stage length of a
stage which is separated from the named stage by another stage i.e. if
there are 5 stages A, B, C, D, E, and A is the named stage adjust stage C.
Check that the value is limited by the maximum and minimum for the
stage. Check that the remaining time is divided between stages further on
in the cycle only and up to the named stage (i.e. stages D and E in the
example).
The stage is adjusted appropriately with a valid value, the remaining time
is split between stages further on in the cycle up to the named stage in
proportion.
Issue 11.0 Page 7-55
System Test Specification for a VAX/VMS UTC System
Action:
Result:
666/YJ/16940/000
Attempt to change the default stage length of the stage immediately
before the named stage.
The command is rejected, this default length may not be changed
explicitly by operator command.
T07-12600
Purpose:
Action:
Result:
Show that default stage lengths may be changed by timetable event.
For each of the changeable parameters in tests T07-12400 to T07-12500,
insert commands into the timetable, and in CASTs, to display, modify and
then redisplay the parameter value (at suitably spaced intervals). Allow
the event to be actioned.
The event is actioned at the appropriate time. Invalid values are rejected
by timetable preparation. The changes are implemented in the same way
as under operator control.
T07-12700
Purpose:
Action:
Result:
7.10.5
To demonstrate the display only commands for stage level parameters.
Use the VALU command to display value of the list of parameters given
below. Show that none of the parameters can be used with the CHAN
command.
MAXS - maximum stage length.
MINS - minimum stage length.
The parameter value is listed when the VALU command is issued. The
CHAN command is rejected.
Change and Display of Link Level Parameters
Reference : MCE O360C paragraph 4.2.6, 4.2.7,
Purpose:
SYSTEST.DOC
VAX SRS 2.7.8
T07-12800
For normal or entry links test each of the link level parameters in turn by
operator command. The following list of commands must be tested:
BIAS - offset bias.
CGIF - congestion importance factor
CGOF - congestion offset.
CGWT - congestion weighting.
CLIF - congestion importance factor for a congestion link.
CLWT - congestion weighting for a congestion link.
DFOF - default offset.
DGEL - double green end lag.
DGSL - double green start lag.
ELAG - end lag.
GGAI - gate gain.
GSAT - gate saturation.
Issue 11.0 Page 7-56
System Test Specification for a VAX/VMS UTC System
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
SYSTEST.DOC
666/YJ/16940/000
INCY - inhibit cycle time optimiser for a link.
INMQ - inhibit maximum queue checking.
INOF - inhibit offset optimiser for a link.
INSP - inhibit split optimiser for a link.
JNYT - journey time.
MDSL - main downstream link.
OFWT - offset weighting.
QCMQ - clear time for maximum queue.
SLAG - start lag.
*
SMAX - SOFT maximum saturation occupancy.
*
SMIN - SOFT minimum saturation occupancy.
SMUL - split weighting multiplier.
*
SOFT - change status of the SOFT algorithm.
SSAT - split weighting saturation.
STOC - saturation occupancy.
Note: The three parameters marked with '*' are for links configured for
SOFT. If a link is configured for SOFT the SOFT algorithm may be
switched on for that link using the CHAN SOFT command.
For each changeable value the following set of tests should be performed:
Change the value for 1 link using the command:
CHAN XXXX N01111F V (where 'V' is a valid value)
The value is changed in the data area and can be confirmed with the
VALU and SEES commands.
A message is written to the SCOOT lineprinter to confirm that the change
has been implemented.
Repeat the above procedure for all links on one node using the command:
CHAN XXXX N33312* V (where 'V' is a valid value)
The values are changed only for those links on the specified node.
Repeat the above procedure for all links on all nodes in one region using
the command:
CHAN XXXX RBCN** V (where 'V' is a valid value)
The values are changed only for those nodes in the specified region.
Repeat the above procedure for all links on all nodes in all regions using
the command:
CHAN XXXX N** V
(where 'V' is a valid value)
The values are changed for all the links in the system.
Use the VALU command to display the 'XXXX' for all links on all nodes:
VALU XXXX N** (where XXXX is one of the 4-character mnemonics
from the above list)
The current value of 'XXXX' for all links on all nodes in all regions is
displayed on the terminal. The setting can be confirmed by using the
SEES command for an individual link.
Issue 11.0 Page 7-57
System Test Specification for a VAX/VMS UTC System
Action:
Result:
Action:
Result:
666/YJ/16940/000
Attempt to use an invalid link parameter in a change command:
CHAN XXXX RDLN* V (where 'V' is a valid value)
The command is rejected.
Repeat the above procedure and attempt to use a series of invalid
parameter values
CHAN XXXX N** V
(where 'V' is an invalid value)
The commands are rejected.
T07-12900
Purpose:
Action:
Result:
Test each of the link level parameters listed in test T07-12800 in turn by
timetable event.
Include commands in the timetable, and in CASTs, to display, modify and
then redisplay the 'XXXX' for all links on all nodes in one region (at
suitably spaced intervals). Allow the events to be actioned.
The results are the same as those produced by the equivalent operator
commands.
T07-13000
Purpose:
Action:
Result:
Action:
Result:
For filter links only a restricted set of the link level parameters are
available for change and display. The following list of commands must be
tested:
CGIF - congestion importance factor
ELAG - end lag.
GGAI - gate gain.
GSAT - gate saturation.
INCY - inhibit cycle time optimiser for a link.
INSP - inhibit split optimiser for a link.
JNYT - journey time.
SLAG - start lag.
SMUL - split weighting multiplier.
SSAT - split weighting saturation.
STOC - saturation occupancy.
For each changeable value the following set of tests should be performed:
Repeat the tests listed against test T07-12800.
Results as for test T07-12800.
Issue all the remaining commands from the list in test T07-12800 for a
filter link to ensure that they are rejected.
The commands are accepted but a null report is generated.
T07-13100
Purpose:
SYSTEST.DOC
To demonstrate the display only commands for links.
Issue 11.0 Page 7-58
System Test Specification for a VAX/VMS UTC System
Action:
Result:
7.10.6
666/YJ/16940/000
Use the VALU command to display the link status and link used. Show
that these parameters cannot be used with the CHAN command. These
tests should be attempted on both all link types. Issue the commands:
VALU LSTS N01111A
CHAN LSTS N01111A VALUE
VALU LNKU N01111A
CHAN LNKU N01111A VALUE
The values are listed when the VALU commands are issued. The CHAN
commands are rejected.
Change and Display of Detector Level Parameters
Reference : VAX SRS 2.7.8
T07-13200
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
SYSTEST.DOC
Test each of the detector level parameters in turn by operator command.
The following list of commands must be tested:
DETU - Detector used.
DSTS - Detector status.
SJNY - SOFT journey time.
SMAN - SOFT detector mandatory.
(c) and (d) are only for SOFT detectors
For each changeable value the following set of tests should be performed:
Use the VALU command to display the 'XXXX' for all detectors on all
links on all nodes:
VALU XXXX N*** (where XXXX is one of the 4-character mnemonics
from the above list)
The current value of 'XXXX' for all detectors on all links on all nodes in
all regions is displayed on the terminal. The setting can be confirmed by
using the SEES command for an individual detector.
Change the value for 1 detector using the command:
CHAN XXXX N01111F1 (where 'V' is a valid value)
The value is changed in the data area and can be confirmed with the
VALU and SEES commands.
A message is written to the SCOOT lineprinter to confirm that the change
has been implemented.
Repeat the above procedure for all detectors on one link using the
command:
CHAN XXXX N33312F* V (where 'V' is a valid value)
The values are changed only for those detectors on the specified link.
Repeat the above procedure for all detectors on all links on all nodes in
one region using the command:
CHAN XXXX RBCN*** V (where 'V' is a valid value)
The values are changed only for those detectors in the specified region.
Issue 11.0 Page 7-59
System Test Specification for a VAX/VMS UTC System
Action:
Result:
Action:
Result:
Action:
Result:
Purpose:
Action:
Result:
666/YJ/16940/000
Repeat the above procedure for all detectors on all links on all nodes in all
regions using the command:
CHAN XXXX N*** V
(where 'V' is a valid value)
The values are changed for all the detectors in the system.
Repeat the above procedure and attempt to use an invalid detector
parameter
CHAN XXXX RDLN* V (where 'V' is a valid value)
The command is rejected.
Repeat the above procedure and attempt to use a series of invalid
parameter values
CHAN XXXX N*** V
(where 'V' is an invalid value)
The commands are rejected.
T07-13300
Test each of the detector level parameters listed in test T07-13200 in turn
by timetable event.
Include commands in the timetable, and in CASTs, to display, modify and
then redisplay the parameter for all detectors on all links on all nodes in
one region (at suitably spaced intervals). Allow the events to be actioned.
The results are the same as those produced by the equivalent operator
commands.
T07-13400
Purpose:
Action:
Result:
Action:
Result:
7.10.7
To demonstrate the display only commands for detectors.
For a particular SCOOT detector use the VALU command to display
value of the interval detector fault accumulator. Show that this parameter
cannot be used with the CHAN command. Repeat the test using a
wildcarded SCN to show the value for a number of detectors. Issue the
commands:
VALU IACC SCN
CHAN IACC SCN VALUE
The values are displayed when the VALU command is issued. The CHAN
command is rejected.
For a particular SCOOT detector use the VALU command to show the
detector status. Show that this parameter cannot be used with the CHAN
command. Repeat the test for a wild-carded detector SCN. Issue the
commands:
VALU DUDD SCN
CHAN DUDD SCN VALUE
The values are displayed when the VALU command is issued. The CHAN
command is rejected.
Node Transfer
Reference : VAX SRS 2.7.8
7.10.7(a)
Node Transfer - General
SYSTEST.DOC
Issue 11.0 Page 7-60
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T07-13500
Purpose:
Action:
Result:
To prove the facility to change the region of a SCOOT node by operator
command.
Enter the commands
SEES Naaaaa Rbb Rcc
where Naaaaa is the SCN of the first node in
a region, Rbb is its current region, Rcc is the region to be transferred to.
On another terminal enter :
NODT Naaaaa Rcc where Naaaaa is the SCN of the node to be
transferred and Rcc is the SCN of its new region.
N.B. The new region's cycle time must be greater than the node's
minimum cycle time and not greater than the node's maximum cycle time.
The node is transferred to its new region and the "SEES" display is
updated. The command VALU RccN* shows that the node is included in
region cc, the the command VALU RbbN* shows the node has gone from
region bb. The node counts for the 2 regions change correctly. The
"SEES" display shows that the stage length are scaled up or down
proportionally within the constraints of the MINS, MAXS.
T07-13600
Purpose:
Result:
To prove that invalid parameters are rejected for the NODT command.
SEES Naaaaa
where Naaaaa is the SCN of the node to be
transferred and note its current region.
on another terminal enter :
NODT Naaaaa Rbb where Naaaaa is the SCN of the node to be
transferred and Rbb is the SCN of an undefined region.
The NODT command is rejected and the region on the "SEES" display is
not updated.
T07-13700
Purpose:
Action:
Result:
Show that node transfer will not work where the destination region and
the node(s) to be transferred have inconsistent cycle times, i.e. the
minimum cycle time of the node to be transferred is greater than the
current cycle time of the region into which it is being transferred.
For a node and regions as described above attempt to execute a NODT
command.
The command is rejected.
T07-13800
Purpose:
Action:
Result:
SYSTEST.DOC
To show node transfer is available from the timetable.
Repeat T07-13500 with the NODT command inserted in the timetable.
As for T07-13500.
Issue 11.0 Page 7-61
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T07-13900
Purpose:
Action:
Result:
7.10.7(b)
Show that the NODT command may be used to move all the nodes from
one region into another and subsequently restore them to the original
region.
For a region with a small number of nodes issue repeated NODT
commands for each of the nodes. The nodes may be transferred either all
to the same region or to different regions. Use the SEES display to show
the status of the nodes in question. When the region has been completely
emptied restore the nodes again using NODT.
The nodes are successfully transferred and restored.
Node Transfer - Networked Systems
T07-14000
Purpose:
Action:
Result:
7.10.8
To show that a node may not be transferred to a region which is
controlled by a different TCC.
Enter a NODT command for a node in a region controlled by TCCA, to
move it to a region controlled by TCCB.
The command is rejected.
UTC/SCOOT interface
Reference : VAX SRS section 2.7.8
T07-14100
Purpose:
Action:
SYSTEST.DOC
Check UTC/SCOOT interface.
Monitor the following information for a particular SCOOT node. A multiequipment node is advised so that the effects on more than one equipment
can be monitored where appropriate. This should apply to all of the tests
in section 7.9.8.
Information transmitted out from SCOOT:
stage requests.
detector status.
translation plan requests.
Information received by SCOOT:
stages run.
detector occupancy data.
green wave indication.
hurry call indication.
NODE SCOOT IMPL flag.
NODE RLY IMPL flag.
Set the M35 message running and the monitor display for the junction.
Cause some of the "input to SCOOT" conditions to occur either by
operator command or using real or simulation hardware. Change the
detectors state using the CHAN command.
Issue 11.0 Page 7-62
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
The contents of the M35 message agrees with the Monitor display. The
transmitted data will be generated under all circumstances. Detector data
is received by SCOOT every second. If a green wave or hurry call is
active on the test node the stages returned to SCOOT may not be those
requested by SCOOT, the NODE SCOOT IMPL and NODE RLY IMPL
flags will change state (this is tested in detail later) appropriately under
these conditions. The UTC system reports detector faults and clears them
in line with the SCOOT system.
T07-14200
Purpose:
Action:
Result:
Check UTC/SCOOT interface with equipment running under local
control.
For an equipment running under local control monitor the stages run and
passed back to SCOOT. Also monitor the stages being requested by
SCOOT and the NODE RLY IMPL and NODE SCOOT IMPL flags.
Bring the equipment under SCOOT control and ensure that it follows the
SCOOT requested stage sequence with minimum delay.
The stages requested and stages run should not generally agree when the
equipment is running under local control. The NODE RLY IMPL flag is
set to 1, the NODE SCOOT IMPL flag is set to 0. Once the equipment is
brought under SCOOT control it goes to the stage requested by SCOOT,
allowing for minimum intergreens and minimum intervening stages (the
NODE SCOOT IMPL flag changes from 0 to 1).
T07-14300
Purpose:
Action:
Result:
Check UTC/SCOOT interface with green wave active.
For an equipment with an active green wave monitor the stages run and
passed back to SCOOT. Monitor the stages being requested by SCOOT
and the implementation flags as before. In addition monitor the status of
the GREEN WAVE flag. Cancel the green wave and ensure that SCOOT
regains control of the equipment with minimum delay.
The equipment will follow the stage timings in the green wave plan. Thus
the SCOOT stage requests will be ignored whilst the green wave is active,
(the NODE SCOOT IMPL flag will go from 1 to 0 when the green wave
is activated, the GREEN WAVE flag will go from 0 to 1). Once the green
wave is cancelled and assuming SCOOT control is active the equipment
goes to the stage requested by SCOOT, allowing for minimum intergreens
and minimum intervening stages. (the NODE SCOOT IMPL flag changes
from 0 to 1, GREEN WAVE flag goes to 0).
T07-14400
Purpose:
Action:
Result:
SYSTEST.DOC
Check UTC/SCOOT interface with controller checks active.
For equipment with controller checks active SCOOT control information
will not be sent to the equipment on the node. Check that the SCOOT
stage requests are ignored under controller checks and that the equipment
performs the controller check sequence instead. Monitor the
implementation flags as before. Once controller checks are complete
ensure SCOOT control is resumed with minimum delay.
The equipment will perform the controller checks specified. SCOOT
control information is not transmitted to the equipment on the node.
(NODE SCOOT IMPL flag goes to 0). SCOOT stage requests will
Issue 11.0 Page 7-63
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
continue to be transmitted across the UTC/SCOOT interface, and the
actual stages run under controller checks will be sent back to SCOOT.
Once controller checks are complete for the node SCOOT control
resumes allowing for minimum intergreens and intervening stages.
(NODE SCOOT IMPL = 1).
T07-14500
Purpose:
Action:
Result:
Check UTC/SCOOT interface with a diversion plan running.
For equipment with an active diversion plan monitor the stages run and
passed back to SCOOT. Monitor the stages being requested by SCOOT
and the implementation flags as before. Cancel the diversion and ensure
that SCOOT regains control of the equipment with minimum delay.
The equipment will follow the stage timings in the diversion plan. Thus
the SCOOT stage requests will be ignored whilst the diversion is active.
(NODE SCOOT IMPL flag goes from 1 to 0). Once the diversion is
cancelled and assuming SCOOT control is active the equipment goes to
the stage requested by SCOOT, allowing for minimum intergreens and
minimum intervening stages. (NODE SCOOT IMPL flag goes from 0 to
1).
T07-14600
Purpose:
Action:
Result:
Check UTC/SCOOT interface when an operator imposed fixed time plan
is running.
Impose a fixed time plan using the operator interface. Monitor the
implementation flags as before. Subsequently cancel the fixed time plan.
The equipment follows the fixed time plan, SCOOT control information is
not passed to the equipment. (NODE SCOOT IMPL flag goes from 1 to
0). The actual stages run are still passed back to SCOOT across the
interface. When the fixed time plan is cancelled SCOOT control resumes
for the equipment, allowing for minimum intergreens and minimum
intervening stages. (NODE SCOOT IMPL flag goes from 0 to 1).
T07-14700
Purpose:
Action:
Result:
Check UTC/SCOOT interface with timetable imposed fixed time plan
running.
Issue an XSCO command to stop the implementation of SCOOT onstreet. Allow a timetable fixed time plan change event to occur and check
that a test equipment follows the fixed time plan. Monitor the state of the
implementation flags as before. Using the SCOO command allow SCOOT
to regain control and demonstrate the fact.
Communication continues across the UTC/SCOOT interface, the test
equipment follows the timetable imposed fixed time plan whilst SCOOT
implementation is disabled. (NODE SCOOT IMPL flag goes from 1 to 0).
Once SCOOT control is enabled the equipment follows the requested
SCOOT stages, allowing for minimum intergreens and minimum
intervening stages. (NODE SCOOT IMPL flag goes from 0 to 1).
T07-14800
Purpose:
SYSTEST.DOC
Check UTC/SCOOT interface with equipment isolated by operator
command.
Issue 11.0 Page 7-64
System Test Specification for a VAX/VMS UTC System
Action:
Result:
666/YJ/16940/000
Issue an ISOL command to isolate equipment on a particular SCOOT
node. Check that the equipment follows the local (i.e. controller specified)
plan. Monitor the state of the implementation flags as before. Using the
XISO command allow SCOOT to regain control and demonstrate the
fact.
Communication continues across the UTC/SCOOT interface, the
equipment follows the local plan whilst isolated, (both NODE SCOOT
IMPL and NODE RLY IMPL flags go from 1 to 0). Once the isolation is
cancelled the equipment follows the requested SCOOT stages, allowing
for minimum intergreens and minimum intervening stages. (NODE
SCOOT IMPL and NODE RLY IMPL flags go from 0 to 1).
T07-14900
Purpose:
Action:
Result:
Check UTC/SCOOT interface with equipment isolated by hardware
failure.
Disconnect an OTU from the instation hardware. Monitor the state of the
implementation flags as before. Subsequently reconnect the OTU and
clear the fault, allow SCOOT to regain control and demonstrate the fact.
Communication continues across the UTC/SCOOT interface, (both
NODE SCOOT IMPL and NODE RLY IMPL flags go from 1 to 0).
Once the OTU is reconnected the equipment on it follows the requested
SCOOT stages, allowing for minimum intergreens and minimum
intervening stages. (NODE SCOOT IMPL and NODE RLY IMPL flags
go from 0 to 1).
T07-15000
Purpose:
Action:
Result:
Check UTC/SCOOT interface on a multi-equipment node with controller
checks active and when isolated.
Repeat tests T07-14400, T07-14800 and T07-14900 using a multiequipment node with only one equipment affected by the controller
checks or isolation.
In each case SCOOT control is suspended for the duration of the test and
resumed once the test is complete, i.e. the same result as for a single
equipment node.
7.11
SCOOT Translation Plans
7.11.1
Change and Display of Translation Plans
Reference : VAX SRS 2.7.9
T07-15100
Purpose:
Action:
SYSTEST.DOC
To check the correct start up timings are in use for the time of day.
Use the OUTT command to determine the SCOOT translation plan
number appropriate to the current date and time. Use VALU for IRCT,
NSST, and DEFS. Switch SCOOT off in all regions using XSCO. Use the
REIN command to reset all SCOOT timings back to their initial values.
Once the initialization has finished use the VALU TPLN command to
confirm that the correct SCOOT translation plan is in operation. Use the
MONI or DISP command to observe the translation of SCOOT requests
to UTC actions. SCOOT should come on again if requested in the
Issue 11.0 Page 7-65
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
timetable. Use the VALU PLAN command for selected nodes to confirm
the cycle time and stage action times. Include a double cycling node.
Check also that the stage start times give lengths in the correct
proportions when compared to the default stage lengths. Use VALU for
IRCT, NSST, and DEFS. CHAN these values and repeat.
A message is displayed showing that SCOOT control has been switched
off. A further message is displayed when the timings have been reinitialized. The values of the start-up plans subsequently displayed agree
with the current state of the values displayed by VALU for IRCT, NSST,
and DEFS. The stage requests are translated into UTC actions as shown
in the current translation plan.
T07-15200
Purpose:
Action:
Result:
To check that translation plans can be changed by operator command
without switching SCOOT off or losing control at a node.
For a multi-equipment SCOOT node as described in section 7.9.8 :
Use the SEES display to show the state of a SCOOT region and a link
and a node within the region. With SCOOT control implemented in this
region change translation plan by use of the CHAN TPLN command to a
plan with non-local data. Show that SCOOT implementation is not
cancelled although the link and node translation plan parameters do
change, if necessary. Use the VALU TPLN command to confirm that the
new translation plan is in operation.
Also use the MONI display for both junctions on the node and the SEES
display for the node to confirm the correct operation of the translation
from SCOOT stages to UTC stages for the translation plans. Show that
both junctions can have separate translations.
The data values displayed confirm that the new translation plans are now
in operation and that there has been no discontinuity in SCOOT control.
T07-15300
Purpose:
Action:
Result:
To check that translation plans can be changed by timetable event without
switching SCOOT off or losing control at a node.
Include in the timetable commands to display the current translation plan,
change the translation plan, and redisplay the translation plan (at suitably
spaced intervals). Modify the system time to 3 minutes before the
translation plan change event for a given region in the current timetable.
Use the SEES display to show the state of the region and a link and a
node within the region. With SCOOT control implemented in this region
wait until the translation plan change event has passed. Show that
SCOOT implementation is not cancelled although the node translation
plan parameters do change, if necessary. Use the operator VALUTPLN
command to confirm that the new translation plan is in operation.
The data values displayed show the change from old to new translation
plan and that there has been no discontinuity in SCOOT control.
T07-15400
Purpose:
SYSTEST.DOC
To confirm that SCOOT plans may not be selected by the UTC plan
change command.
Issue 11.0 Page 7-66
System Test Specification for a VAX/VMS UTC System
Action:
Result:
666/YJ/16940/000
Use the 'PLAN' command to attempt to select a plan associated with a
SCOOT translation plan.
The command is rejected.
T07-15500
Purpose:
Action:
Result:
Purpose:
Action:
Result:
To change from a non-local to a local plan and vice-versa using the
CHAN TPLN command.
For a multi-equipment node as defined in section running under SCOOT
control use the CHAN TPLN command to select a translation plan which
sets one of the junctions to local control. Subsequently select a translation
plan which sets both junctions to local control. Finally change to a
translation plan where the translations are not local on either junction.
Initially the node is running under SCOOT control, after the first change
of translation plan the VALU IMPL command shows SCOOT is still
being implemented on the node, however using the MONI and SEES
displays for the 2 junctions shows one junction running in local mode.
Following the second change of translation plan the VALU IMPL
command shows SCOOT is no longer implemented on the node.
Following the final change of translation plan SCOOT control is restored.
T07-15600
Check the correct operation of removable stages.
Select a node which has a removable stage which is used as the start or
end stage of a link. Use VALU DEFS, ELAG and SLAG to inspect.
Select a translation plan in which the removable stage is removed. Use
CHAN TPLN when the node is just starting the stage to be removed.
Check that SCOOT does not request the removable stage in the next
cycle and that the stage count parameter is reduced by one. Check that the
UTC stages run correspond to the SCOOT stage requests and the new
translation plan. Also ensure that appropriate adjustments are made to the
start or end stage and the used status of the link. Use VALU DEFS,
ELAG and SLAG. Check CHAN for these also.
The translation plan is loaded correctly and the correct UTC stages are
run. SCOOT no longer requests the removable stage. Adjustments are
made to the link parameters as described above. VALU for DEFS, ELAG
and SLAG do not mention the removed stage. CHAN for these works in
the new situation.
T07-15700
Purpose:
Action:
Result:
SYSTEST.DOC
To show that translation plans may have more than one UTC stage
associated with a SCOOT stage.
two or more normal UTC stages
a number of normal UTC stages plus one or more demand dependant
stages.
a Nominate Add pair
Select in turn translation plans for junctions that include the above types
of plan. Monitor the behaviour of the translation plan on a DIPM display.
All except the last of the UTC stages run as a fixed length stages of length
given by the difference between the action times of each pair. The length
of the last stage may be modified by SCOOT. If a demand dependant
Issue 11.0 Page 7-67
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
stage is included as any but the last stage then it will either run as a fixed
length stage or its time will be given to the previous stage. The Nominate
Add pair should raise both stage bits with a delay equal to the difference
in action times. Whichever stage actually runs may have its length altered
by SCOOT but only if the Nominate Add pair is the last pair in a SCOOT
stage with multiple UTC stages.
7.12
Equipment Monitoring
7.12.1
Junction Monitoring
Reference : VAX SRS 2.7.10
T07-15710
Purpose:
Action:
Result:
To show that response to demand for demand dependant stages is
monitored.
Using OVRB arrange for a DR bit to be returned but for the requested
stage not to be returned within a plan cycle.
A demand stage not serviced error message is output. The fault log is
updated and a message sent to the System log.
T07-15720
Purpose:
Action:
Result:
To test that intergreen times below or above their nominal values by more
than the time defined in the data are identified and reported.
Modify a selection of intergreen times for intersections so that they fall
outside their nominal values by more than the defined tolerance, by either
altering the data values or by changing the intergreen times in the
controllers. Put these intersections under various modes of control.
This test should be done for a controller with a single set of timing data
and another with different upper and lower timings.
An intergreen timings fault is reported.
T07-15730
Purpose:
Action:
Result:
To test that under fixed time control stage green times below or above
their plan values by more than the time defined in the data are identified
and reported.
For an intersection on fixed time control manually follow the plan using
OVRB for a number of cycles. Then return some stages for more than the
configured number of seconds greater or less than the planned time.
A green timing fault is reported.
T07-15740
Purpose:
Action:
SYSTEST.DOC
To test that under local control stage green minimum times are monitored
against the defined data.
For an intersection on local control use OVRB to return a stage for less
than the configured number of seconds minus the stage green tolerance
value.
Issue 11.0 Page 7-68
System Test Specification for a VAX/VMS UTC System
Result:
7.12.2
666/YJ/16940/000
This test should be done for a controller with a single set of timing data
and another with different upper and lower timings. The lower minimum
stage value should be used for the second case.
A minimum green timing fault is reported.
Pelican Monitoring
T07-15750
Purpose:
Action:
Result:
To test that pelican green to vehicle times are monitored against the
defined data.
For a pelican controller clear the GX bit before its minimum time minus
the tolerance value has expired.
A minimum green timing fault is reported.
T07-15760
Purpose:
Action:
Result:
To test that pelican non-green to vehicle times are monitored against the
defined data.
For a pelican controller reset the GX bit before its minimum absence time
minus the tolerance value has expired. Monitor the equipment using
DIPM.
This test should be done for a pelican with a single not-GX limit and
another with upper and lower limits. The lower limit value should be used
for the second case.
A minimum non-green to vehicle timing fault is reported. The DIPM
display should show both upper and lower not-GX times for the second
equipment.
T07-15770
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
7.13
To test the monitoring of pelican operation.
Set a pelican to have a permanent demand over night between 19:00 and
07:00.
The System log will show that after 6 hours a permanent demand fault
was logged.
Clear the fault manually.
The fault is cleared.
Repeat the permanent demand fault. Clear the fault by clearing the
demand.
The fault is cleared.
Plan Compliance Faults
Reference : MCE 0360C paragraph 4.3.1.6. VAX SRS 2.7.11
Note :
SYSTEST.DOC
The CRS section 2.4.25(j) defines action of the system for each fault type
ie. whether the fault is isolating. For each isolating fault the isolating fault
wall map lamp for the equipment will flash and for all other faults the nonisolating fault wall map lamp will flash. The lamps will continue to flash
Issue 11.0 Page 7-69
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
until an ACKD command is entered, when they become steady. The lamps
are extinguished when the fault is cleared.
T07-15800
Purpose:
Action:
Result:
Action:
Result:
To confirm that a 'Plan compliance' fault is reported if the controller
changes to an incorrect stage.
Call up a MONI display for a controller.
Check that the controller is not isolated and that a normal plan is in
progress.
If necessary, wait until 4 minutes have elapsed since the controller last
changed plan or had a fault cleared.
After several cycles of normal operation, and while the controller is not in
an intergreen, use a test set to change the stage reply bit to zero for one
second only.
Repeat using the test set to change the stage reply bit to an incorrect
stage reply bit.
Repeat d) using the test set to change the stage reply bit to permanent, i.e.
more than 180 seconds continuous presence.
In each case a plan compliance error message is output. The fault log is
updated and a message sent to the system log. Any relevant wall map
lamps operate. The system stops sending control data to the controller
within 2 seconds of the fault being detected by the system.
While the controller is in an intergreen cause it to be stuck in intergreen
for more than 48 seconds.
A plan compliance error message is output. The fault log is updated and a
message sent to the System log. Any relevant wall map lamps operate. A
further message is output and the controller isolated if any of the faults
persist for more than 4 consecutive seconds.
T07-15900
This test has been deleted. See section .
T07-16000
Purpose:
Action:
SYSTEST.DOC
To confirm that a 'Plan compliance' fault is not produced during the four
minute period following a traffic plan change involving the controller
under test.
Call up a live update (PICT) display for a controller.
Check that the controller is not isolated and that a normal plan is in
progress.
Enter the command 'PLAN' to change plan for this controller.
Use a test set to simulate the actions of the controller in following the
control bits of the plan.
After a cycle of normal operation, and while the controller is not in an
intergreen, change the stage reply bit to something other than the force bit
being sent out.
Repeat e) periodically during the next 4 minute period, but avoiding the
'signals stuck' message (which will isolate the controller).
Issue 11.0 Page 7-70
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
Use the LSTF command to confirm that the controller does not get a plan
compliance fault until 4 minutes have elapsed since the plan change.
A plan compliance fault is not reported until a period of 4 minutes has
elapsed since a plan change.
T07-16100
This test has been deleted. See section .
T07-16200
This test has been deleted. See section .
T07-16300
This test has been deleted. See section .
T07-16400
This test has been deleted. See section .
T07-16500
This test has been deleted. See section .
T07-16600
This test has been deleted. See section .
T07-16700
Purpose:
Action:
Result:
Stage Transition Inhibited.
Call up a MONI display for a controller.
Check that the controller is not isolated and that a normal plan is in
progress.
If necessary, wait until 4 minutes have elapsed since the controller last
changed plan or had a fault cleared.
Hold a 'G' bit using a test set, after the 'F' bit is dropped by the plan.
A plan compliance fault is reported.
T07-16800
Purpose:
Action:
SYSTEST.DOC
To ensure that the system will detect when a pelican controller has failed
to follow the correct plan.
Call up a MONI display for a pelican controller.
Check that the controller is not isolated and that a normal plan is in
progress.
If necessary, wait for 4 minutes to have elapsed after the last plan change
or fault clearance.
Issue 11.0 Page 7-71
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
Use a test set to simulate the actions of the controller in following the PV
control bits of the plan.
After a cycle of normal operations switch the GX bit to the absent state at
a time when the PV control bit is present.
Use the 'LSTF' command to confirm that the controller now has a plan
compliance fault.
3 seconds after losing the GX bit while the PV control bit is still present
the controller shall be isolated, a 'Plan compliance' message shall be
output and the alarm sounded.
T07-16900
Purpose:
Action:
Result:
To ensure that the system will detect when a pelican controller has failed
to respond to a pedestrian demand.
Call up a MONI display for a pelican controller.
Check that the controller is not isolated and that a normal plan is in
progress.
If necessary, wait for 4 minutes to have elapsed after the last plan change
or fault clearance.
Use a test set to simulate the actions of the controller in following the PV
control bits of the plan.
After a cycle of normal operations leave the GX bit present when there is
pedestrian demand and the PV bit has cleared.
Use the 'LSTF' command to confirm that the controller now has a plan
compliance fault.
5 seconds after losing the PV bit while the GX reply bit is still present the
controller shall be isolated, a 'Plan compliance' message shall be output
and the alarm sounded.
T07-17000
Purpose:
Action:
Result:
SYSTEST.DOC
To test the Inhibit Plan Compliance Fault Isolation command IHPC by
confirming that control data will continue to be sent to a controller that
has produced a plan compliance fault.
Call up a MONI display for a controller.
Issue a IHPC 120 command for the controller.
Check that the controller is not isolated and that a normal plan is in
progress.
If necessary, wait until 4 minutes have elapsed since the controller last
changed plan or had a fault cleared.
After several cycles of normal operation, and while the controller is not in
an intergreen, use a test set to change the stage reply bit to zero for one
second only.
A plan compliance error message is output and control data continues to
be sent to the controller.
Issue 11.0 Page 7-72
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T07-17100
Purpose:
Action:
Result:
To test the Cancel Plan Compliance Fault Isolation command XIHP by
confirming that a controller which had previously had plan compliance
fault isolation inhibited is now isolated by a plan compliance fault.
Call up a MONI display for a controller.
Issue a IHPC 120 command for the controller.
Check that the controller is not isolated and that a normal plan is in
progress.
If necessary, wait until 4 minutes have elapsed since the controller last
changed plan or had a fault cleared.
After several cycles of normal operation, and while the controller is not in
an intergreen, use a test set to change the stage reply bit to zero for one
second only. Verify that the appropriate fault messages are output and
that the controller is not isolated.
Cancel the faults by use of the XFLT command.
Cancel plan compliance fault isolation inhibit by issuing a XIHP 120
command for the controller.
Wait until 4 minutes after the fault was cleared.
After several cycles of normal operation, and while the controller is not in
an intergreen, use a test set to change the stage reply bit to zero for one
second only.
A plan compliance error message is output and the controller is isolated.
T07-17200
Purpose:
Action:
Result:
To test the facility to list all controllers which have Plan Compliance Fault
Isolation inhibited.
Issue IHPC 120 commands for a number of controllers.
Issue an LSTS 12 command to obtain a list of those controllers which
have plan compliance fault isolation inhibited.
A list of controllers is output which shows those controllers which have
had plan compliance fault isolation inhibited.
T07-17300
Purpose:
Action:
Result:
To verify that the plan compliance fault isolation inhibit commands (IHPC
and XIHP) are journalled.
Issue IHPC 120 commands for a number of controllers.
Issue XIHP commands to cancel the IHPC commands just entered.
Examine the journal by use of the LJNL command.
All the IHPC and XIHP commands issued are shown in the journal.
7.14
Controller Checks
7.14.1
Timetable Controller Checks - General
SYSTEST.DOC
Issue 11.0 Page 7-73
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
References: MCE 0360C paragraphs 4.3.2.1, 4.3.2.2, 4.3.2.3, 4.3.2.5, 4.3.2.6, 4.3.2.7,
4.3.2.8, 4.3.2.9.
VAX SRS 2.7.12
Note :
The results of the tests T07-17400 to T07-17800 and T07-18100 to T0719000 should be observed by using the monitor display (MONI) to show
the control and reply bits for controllers being tested. A live update
display (DIPM) should also be used to show the timings for greens and
intergreens as they occur and to compare with the timings made by the
controller monitoring software. The following results should be confirmed
when tests are done on timetable controller checks and operator initiated
checks:
Minimum Green and Intergreen Test - it should be observed that the DX
and F bits are set for each stage in turn which appears in the sequence
defined in the data for this test and that these are set during the intergreen
for the previous stage;
Maximum Green Test - It should be observed that the F bits are cleared
and DX is set to allow all stages to run to their maximum.
T07-17400
Purpose:
Action:
Result:
SYSTEST.DOC
To prove that (overnight) tests will correctly identify and report faulty
controllers.
The timings of the controllers connected to the system should be modified
so that they are outside the acceptable tolerances specified in the data.
(These controllers may have the intergreen and minimum green times
changed or the data stored in the computer may be modified). The
following controller timings and replies should be modified :
An incorrect SB bit should be set for at least one controller.
Minimum green times - a selection of stages should have their minimum
green times increased or decreased from their nominal values. The
transmission of F and D bits and the receipt of the appropriate G bits are
checked.
This should be checked for up to 8 stages on one controller.
Intergreen times - a selection of intergreen times should be increased or
decreased from their nominal values. The times which are changed should
be those in the normal cyclic stage sequence adopted by the controller
when all stages have demand.
Maximum green times - a selection of maximum green times should be
increased or decreased from their nominal values. This should be checked
for up to 12 stages on one controller.
Configure some controllers in the system for secondary maximum green
times and make some incorrect.
Configure some controllers in the system with the fallback cycle time
parameter set to NSNT.
Messages are displayed with the time when checks start and finish.
All faults are correctly identified and the appropriate messages output.
A message is output for all controllers on which no fault was found.
When checks on a controller have been completed or terminated the
control bits are cleared and the controller is returned to its normal
operating mode for the time of day.
Issue 11.0 Page 7-74
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
Checks are not performed on those controllers with the NSNT parameter
set.
Each timing is checked only once against the defined data and hence
discrepancies will be reported only once.
Controllers with discrepancies are not isolated
T07-17500
Purpose:
Action:
Result:
To test that green times more than the configured number of seconds
below their valid minima are identified and reported.
Put an intersection on timetable plan 0.
Start Controller Checks.
Simulate a green time less than the nominal value using a test box in place
of a controller.
An error message is output whenever the green time is out of range. The
error message displays the faulty stage and times.
T07-17600
Purpose:
Action:
Result:
To test that if controller checks fails to complete before a cancel
controller checks event in the timetable, the checking is suspended at that
point and is resumed from last controller checked when the next
controller checks request is made from the timetable.
Set up a timetable with a CHCK command followed by a XCHC
command 5 minutes later and in the next days timetable another CHCK
command.
Set the system time to 2 minutes before the first CHCK event.
Controller checks runs for 5 minutes reporting those controllers checked.
Checking is suspended until the next day and is then resumed from the last
controller checked (This can be confirmed by examining the results from
T07-17400) until controllers have been processed. A controller will not be
tested again until the System has attempted to test all controllers which
are not faulty or isolated.
T07-17650
Purpose:
Action:
SYSTEST.DOC
To show that if a higher priority control mode is called on a junction or
junctions during controller checks then controller checks is suspended on
this equipment. When all other junctions have been checked then
controller checks will attempt to check this equipment again.
Edit or modify a timetable to include controller checks. Select two
controllers that have their test bit set to be checked by controller checks.
Ensure that both are operating under fixed-time plan.
Change the system time to one minute before the controller timings event
in the timetable.
Before controller checks reaches the first of the controllers to be tested,
implement a higher mode of control, which can be :
- A hurry call
- A green wave
- A manual wave
Issue 11.0 Page 7-75
System Test Specification for a VAX/VMS UTC System
Result:
Action:
Result:
666/YJ/16940/000
- An operator imposed plan
For the second controller, wait for controller checks to start on this
equipment, but interupt it with one of the above control methods before it
completes.
Before controller checks terminates on the system, ensure that the higher
modes of control on both controllers has terminated.
After the last controller has completed the normal sequence of controller
checks, these two controllers are checked.
Repeat the test using one of the above controllers, but maintaining it on
an operator imposed fixed-time plan until controller checks has
terminated.
After controller checks terminates, an appropriate message is output.
T07-17700
Purpose:
Action:
Result:
7.14.2
To show that the results of controller checks can be listed in SCN order.
Use an existing timetable, or create a new one, with a SORT command
scheduled for approx. 30 mins. after a CHCK command.
The SORT command is actioned and controller checks data is listed in
SCN order on the spooling printer.
Timetable Controller Checks - Networked Systems
T07-17800
Action:
Result:
7.14.3
Repeat the above test with the TMC offline.
The command is rejected with the message "No computer available to
action this command".
Operator Controller Checks - Invalid Command Lines
Reference : MCE 0360C paragraph 4.3.2.4 VAX SRS 2.7.12
T07-17900
Purpose:
Action:
Result:
To prove that invalid command lines for the CHCK command are
rejected.
Enter the following commands CHCK
CHCK Jaaaaa
where aaaaa is an invalid controller SCN.
CHCK Iaaaaa
CHCK Paaaaa
where aaaaa is a valid pelican SCN.
CHCK Jaaaaa bb
where aaaaa is a valid controller SCN.
The commands are all rejected with appropriate error messages.
T07-18000
Purpose:
SYSTEST.DOC
To prove that invalid command lines for the XCHC command are
rejected.
Issue 11.0 Page 7-76
System Test Specification for a VAX/VMS UTC System
Action:
Result:
7.14.4
666/YJ/16940/000
Enter the commands XCHC Jaaaaa
where aaaaa is a invalid controller SCN.
XCHC Paaaaa
where aaaaa is a valid SCN.
The commands are all rejected with appropriate error messages.
Operator Controller Checks
Reference : MCE 0360C paragraph 4.3.2.4 VAX SRS 2.7.12
T07-18100
Purpose:
Action:
Result:
To test the correct operation of operator controller checks.
A check is initiated on a selection of controllers, using the manual control
facilities (CHCK).
The results found during the timetable controller checks (T07-17400 to
T07-17800) are repeated except as follows, for those controllers for
which the TTDAY option has been set in the data (see section ),
maximum green faults will not be detected.
T07-18200
Purpose:
Action:
Result:
To test that operator initiated controller tests may be terminated at any
time by the command XCHC.
The operator will start controller checks on a single controller with the
CHCK command and after a short time enter the XCHC command.
A message is displayed immediately indicating that checks have been
terminated on the controller specified in the CHCK command.
T07-18300
Purpose:
Action:
Result:
Action:
To test that if a green wave plan is requested on a controller then checks
will be abandoned if they are running on that controller.
Start checks on a controller with the CHCK command. Use the GWAV
command to start a green wave plan for the same controller.
When the green wave plan is started the checks terminate on the
controller and a suitable message is output.
Cancel the green wave plan using a GWAV command or allow it to run to
completion.
T07-18400
Purpose:
Action:
Result:
SYSTEST.DOC
To show that if an emergency vehicle priority plan is running, controller
checking will not be started on controllers on the green wave route.
start a green wave running as described in test T07-05900.
Enter the CHCK command to start controller checking on one of the
junctions on the green wave route.
Controller checking will not be started on the junction because it is on a
green wave route which is active. An appropriate message is output.
Issue 11.0 Page 7-77
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T07-18500
Action:
Result:
Purpose
To test that the presence of simultaneous G1 and G2 reply
bits cause controller checks to abandon tests on a controller.
Checks shall be started on a controller with the CHCK operator
command. The G1 and G2 reply bits shall be made to appear by switching
the signals off. This shall be confirmed by using monitor to examine the
reply bits.
This fault causes the checks to be abandoned on the controller. A message
is output reporting the reason for termination.
T07-18600
Purpose:
Action:
Result:
Reference: MCE 0360C 4.3.2.12.
To test that controller checks will function normally when there is a
detector fault on a controller.
Simulate a detector fault on a test controller by setting the DF reply bit,
and start checks on that controller using the CHCK operator command.
The results are the same as when there were no detector faults.
T07-18700
Purpose:
Action:
Result:
Reference: MCE 0360C 4.3.2.14.
To test that checks will be abandoned when there is an intermittent OTU
data failure.
Simulate an OTU fault condition, whereby intermittent data transmission
errors occur, by switching off the controller's OTU for a short period (less
than 15 seconds). Check the transmission failures on a MONI display.
Controller Checks are abandoned with an appropriate message.
T07-18800
Purpose:
Action:
Result:
To check that no fault messages are produced when there are no faults,
just a test completed message.
Repeat test T07-18100 with no faults present.
No fault messages are output. An appropriate completed message is
displayed when checks have finished on the controllers.
T07-18900
Purpose:
Action:
Result:
To show that if a controller is isolated by fault then controller checking
will not be started.
Simulate a fault on a controller which causes it to be isolated. Start checks
on the controller using the CHCK command.
Controller checks are not started whilst the controller is isolated.
T07-19000
Purpose:
SYSTEST.DOC
To show that if an OTU is isolated by TX fault then controller checking
will not be started.
Issue 11.0 Page 7-78
System Test Specification for a VAX/VMS UTC System
Action:
Result:
SYSTEST.DOC
666/YJ/16940/000
Isolate an OTU by removing the data link and causing a TX fault. Start
checks on a controller in the OTU using the CHCK command.
Controller checks are not started whilst the controller is isolated.
Issue 11.0 Page 7-79
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
8.
OTHER STREET EQUIPMENT CONTROL TEST DEFINITIONS
8.1
Collection of Traffic data
8.1.1
Count Detection including SCOOT loops
Reference :VAX SRS 2.8.3(1)-(5)+(7)
T08-00100
Purpose:
Action:
Result:
To show that a scale factor may be applied to count data.
Enter a FLOW command for 2 detectors with different scale factors.
simulate the same number of changes of state of the least significant count
bit of both detectors.
The flows recorded should reflect the different scale factors.
T08-00200
Purpose:
Action:
Result:
Action:
To prove that a faulty detector will terminate a link calibration.
Attach a SCOOT detector simulator to the selected OTU. At a terminal
enter an SSSU command to start the survey of SCOOT data. Before the
survey has completed (i.e. within one hour of the start), set the OTU with
detector under test as "faulty" - using OVRB.
An alarm message is output to tell the operator that the calibration has
been stopped.
Clear the fault on the detector and any associated links.
T08-00300
Purpose:
Action:
Result:
Action:
Result:
To calibrate a SCOOT link.
Use the software simulator producing flow at a constant rate of LPU.
Start a new SCOOT survey and allow it to run to completion.
At the end of one hour a message is output to inform the operator that the
survey has completed. Note the number of LPU.
Enter an ASLD command specifying the link and count detector used
above and enter a vehicle count.
The system calculates and stores a conversion factor for the link.
T08-00400
Purpose:
Action:
Result:
Action:
SYSTEST.DOC
To prove that a faulty detector will terminate a link calibration.
Attach a SCOOT detector simulator to the selected OTU. At a terminal
enter an SSSU command to start the survey of SCOOT data. Before the
survey has completed (i.e. within one hour of the start), set the OTU with
detector under test as "faulty" - using OVRB.
An alarm message is output to tell the operator that the calibration has
been stopped.
Clear the fault on the detector and any associated links.
Issue 11.0 Page 8-80
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T08-00500
Purpose: To display the link conversion factors calculated in T08-00300.
Action:
Result:
Enter an LLCF command for the detector used in test T08-00300. Using
the numbers noted in T08-00300 calculate the factors.
The expected conversion factor is displayed on the terminal.
T08-00600
Purpose: To confirm the conversion factor calculated in T08-00300.
Action:
Result:
Using the software SCOOT simulation program input a known but
different rate of LPUs/hour on the link used in test T08-00300.
Using the conversion factor obtained in T08-00300 manually calculate the
expected vehicle count.
Enter a FLOW command to display the current vehicle count for the
chosen detector
The current vehicle count is displayed and should be within rounding
tolerance of that obtained in the manual calculation.
T08-00700
Purpose:
Action:
Result:
Action:
Result:
To prove the capacity of the system for calibrating SCOOT links.
Start 16 SCOOT surveys with SSSU commands for SCOOT links with
detectors which are OK.
All commands are accepted and the surveys started.
While the 16 surveys are active, enter one more SSSU command for a
different link.
The command is rejected since the maximum number of SCOOT surveys
are already active.
T08-00800
Purpose:
Action:
Result:
To prove the capacity of the computer to store vehicle count data and
ability to update files for missed days.
List the count data files directory and see that there are files of the
maximum age as defined in the database. Allow the system to pass
through midnight. List the count data files directory and see that there are
files of the maximum age only.
The number of files did not increase, a file for the latest date was added
and for the oldest date was deleted.
T08-00900
Purpose:
Action:
Result:
Action:
SYSTEST.DOC
To display one day's vehicle count data. SURV command and FLOW
command.
Enter a SURV command for a date for which there is no data
The message displayed on the terminal indicates no data is available.
Enter SURV command for a date for which there is no partial data the
previous week.
Issue 11.0 Page 8-81
System Test Specification for a VAX/VMS UTC System
Result:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
666/YJ/16940/000
The data is displayed with absent and partial counts marked. The data is
displayed in intervals as specified in the VAX SRS 2.8.3(2).
Data for the previous week should exist for this test. Set the system date
to 2 days in the future, or a date such that data exists for the same day of
the previous week.
Enter the SURV command.
Enter the FLOW command.
The data for both commands is displayed with substitute counts marked.
The data is displayed in intervals as specified in the VAX SRS 2.8.3(2).
Enter a FLOW command for 4 different detectors.
The data is displayed and updated in real time.
Enter a FLOW command for a faulty detector.
A message indicates no data is available.
Enter a FLOW and SURV command for invalid detector SCNs.
A message indicates the SCN are invalid.
T08-01000
Purpose:
Action:
Result:
Action:
Result:
To display one week's vehicle count data. WEEK command.
Enter a WEEK command.
The data for 7 days counts are show on the screen as hourly counts.
Enter a WEEK command for a date 7 days in the future.
The message indicates no data is available.
T08-01100
Purpose:
Action:
Result:
To prove the capacity of the system to store weekly summary files.
List the weekly summary files directory and see that there are files of the
maximum age as defined in the system data. allow the system to pass
through midnight from saturday to sunday. List the weekly summary files
directory and see that there are files of the maximum age only.
The number of files did not increase. A file for the latest week was added
and for the oldest week was deleted.
T08-01200
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
8.1.2
To display a complete previous day's vehicle count data. OPFD command.
Enter an OPFD command for a date when data exists.
Hourly counts and analysis are output to the printer.
Enter an OPFD command for a detector SCN that does not exist.
The message indicates the SCN does not exist.
Insert an OPFD command in the timetable.
Hourly counts and analysis are output to the printer.
Occupancy Detection
SYSTEST.DOC
Issue 11.0 Page 8-82
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
Reference :
T08-01250
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
8.1.3
To display one day's vehicle occupancy data. SURV and FLOW
commands.
For a count detector configured with an occupancy bit, enter the
following commands :
FLOW COUNT Dnnnnn
FLOW COUNT 15 Dnnnnn
FLOW OCCUPANCY Dnnnnn
FLOW OCCUPANCY 15 Dnnnnn
5 minute count data for the detector is displayed, with absent, substitute
and partial counts marked.
As before, for 15 minute interval.
5 minute occupancy data, as above.
15 minute occupancy data, as above.
Repeat the same test for a detector not configured with an occupancy bit.
The FLOW COUNT commands show data as before. The FLOW
OCCUPANCY commands do not display data and give an appropriate
message.
Repeat test T08-00900, but including OCCUPANCY in the command
line. Do this for detectors configured with and without an occupancy bit.
As for T08-00900 for detectors configured with the occupancy bit. No
data is displayed for detectors without the occupancy bit and an
appropriate message is output.
Data file transfer to PC
Reference : VAX SRS section 2.8.3(6)
Note:
SYSTEST.DOC
The 8 character name of the file which is created on the destination PC's
disk by the TXDF command is of one of the following forms:
Weekly data :
Count Data DWddmmyy.vvv
Car Park Occupancy Data OWddmmyy.vvv
where : ddmmyy
is the day, month and year of the Monday of the
week whose data is contained with in the file.
vvv is the file transfer version number.
Daily data :
System log SYddmmyy.LOG
Count data DDddmmyy.TCn
where : ddmmyy
is the day, month and year when the data was
collected.
TCn is the number of the TCC.
OTU data :
Issue 11.0 Page 8-83
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
OTU log data
Xnnnnn.LOG
where : nnnnnis the SCN of the OTU.
T08-01300
Purpose:
Action:
Result:
Action:
Result:
To prove that the latest weekly count data file can be transferred to a PC
workstation.
At a PC workstation connected to the computer enter the command:
TXDF COUNT_DATA
The workstation enters KERMIT server mode and the file is transferred.
Once the transfer is complete the workstation returns to terminal
emulation.
Use ALT-X on the PC to exit the terminal emulation. List the directory of
the PC disc.
A file with the same name as the weekly summary file in the computer will
have been placed on the PC disc.
T08-01350
Purpose:
Action:
Result:
Action:
Result:
To prove that the count data file for a specified week can be transferred to
a PC workstation
At a PC workstation connected to the computer enter the command:
TXDF COUNT_DATA dd-mmm-yy
where dd-mmm-yy is the date of
previous week's data file.
The workstation enters KERMIT server mode and the file is transferred.
Once the transfer is complete the workstation returns to terminal
emulation.
Use ALT-X on the PC to exit the terminal emulation. List the directory of
the PC disc.
A file with the same name as the weekly summary file in the computer will
have been placed on the PC disc.
T08-01400
Purpose:
Action:
Result:
Action:
Result:
Action:
SYSTEST.DOC
To prove that if the workstation is disconnected from the host computer
during file transfer, the transfer is aborted and when the terminal is
reconnected normal operation is resumed.
At a PC workstation connected to the computer enter the command:
TXDF COUNT_DATA dd-mmm-yy
Disconnect the workstation by removing the RS232 connection.
After 20 seconds the workstation indicates the transfer has been aborted
and after 2 minutes the system reports the terminal as being faulty.
Reconnect the RS232 connection to the workstation.
After 30 seconds the system clears the terminal fault.
Confirm the workstation has resumed normal operation by entering a
selection of operator commands which should include at least one semigraphical display command ie. VEGA.
Issue 11.0 Page 8-84
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T08-01450
Purpose:
Action:
Result:
Action:
Result:
To prove that the latest car park occupancy data file can be transferred to
a PC workstation
At a PC workstation connected to the computer enter the command:
TXDF CAR_PARK_DATA
The workstation enters KERMIT server mode and the file is transferred.
Once the transfer is complete the workstation returns to terminal
emulation.
Use ALT-X on the PC to exit the terminal emulation. List the directory of
the PC disc.
A file with the same name as the weekly summary file in the computer will
have been placed on the PC disc.
T08-01500
Purpose:
Action:
Result:
Action:
Result:
To prove that the count data file for a specified week can be transferred to
a PC workstation
At a PC workstation connected to the computer enter the command:
TXDF CAR_PARK_DATA dd-mmm-yy where dd-mmm-yy is the date
of previous week's data file.
The workstation enters KERMIT sever mode and the file is transferred.
Once the transfer is complete the workstation returns to terminal
emulation.
Use ALT-X on the PC to exit the terminal emulation. List the directory of
the PC disc.
A file with the same name as the weekly summary file in the computer will
have been placed on the PC disc.
T08-01520
Purpose:
Action:
Result:
Action:
Result:
To prove that the count and occupancy data file for a specified day can be
transferred to a PC workstation.
At a PC workstation connected to the computer enter the command:
TXDF DAILY_COUNT dd-mmm-yy
where dd-mmm-yy is a
previous day's data file.
The workstation enters KERMIT server mode and the file is transferred.
Once the transfer is complete the workstation returns to terminal
emulation.
Use ALT-X on the PC to exit the terminal emulation. List the directory of
the PC disc.
A file with the name as defined at the beginning of this section for daily
count data will have been placed on the PC disc.
T08-01540
Purpose:
Action:
SYSTEST.DOC
To prove that the system log for a specified day can be transferred to a
PC workstation.
At a PC workstation connected to the computer enter the command:
Issue 11.0 Page 8-85
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
TXDF LOG dd-mmm-yy
Result:
Action:
Result:
where dd-mmm-yy is a
previous day's date.
The workstation enters KERMIT server mode and the file is transferred.
Once the transfer is complete the workstation returns to terminal
emulation.
Use ALT-X on the PC to exit the terminal emulation. List the directory of
the PC disc.
A file with the name as defined at the beginning of this section for a
system log will have been placed on the PC disc.
T08-01560
Purpose:
Action:
Result:
Action:
Result:
8.1.4
To prove that the logged OTU data for a specified OTU can be
transferred to a PC workstation.
Start logging an OTU by means of the command :
LOTU Xnnnnn
where nnnnn is a valid OTU SCN
After a short period terminate the logging by the command :
XLOT Xnnnnn
using the same SCN as above
At a PC workstation connected to the computer enter the command:
TXDF OTU_DATA Xnnnnn
for the same SCN
The workstation enters KERMIT server mode and the file is transferred.
Once the transfer is complete the workstation returns to terminal
emulation.
Use ALT-X on the PC to exit the terminal emulation. List the directory of
the PC disc.
A file with the name as defined at the beginning of this section for logged
OTU data will have been placed on the PC disc.
Data file transfer to PC - Networked Systems
T08-01600
Action:
Result:
8.1.5
Repeat the tests in section on a PC connected to each of the TCCs and on
one connected to the TMC.
The TXDF command is available on all TCCs. The file is transferred from
the TMC through a TCC to the PC.
Data File Conversion on a PC
T08-01620
Purpose:
Action:
SYSTEST.DOC
To prove that a count data file transferred to a PC is correctly converted
into a form which can be read into a PC based spreadsheet or database
management package.
Run the off-line file conversion program and select the weekly detector
count data for conversion into a dBase format file.
Using dBaseIII, dBaseIV or a database program that reads this
format, read the converted data file.
Issue 11.0 Page 8-86
System Test Specification for a VAX/VMS UTC System
Result:
Action:
Result:
666/YJ/16940/000
The database program succesfully reads the file. The data displayed by the
database program should agree with the data as shown on a UTC System
terminal.
Repeat the same conversion in the previous test for the following data :
Car Park occupancy data
Daily count data
As for the previous test.
T08-01640
Purpose:
Action:
Result:
8.2
To prove that converted data can be read by a PC-based Lotus 1-2-3
compatible spreadsheet program.
Start the spreadsheet program which should be capable of reading both
dBaseIII/IV and Lotus 1-2-3 format files. Import one of the dBase files
created in the previous test.
The spreadsheet program succesfully imports the file. The data displayed
should agree with the data as shown on a UTC System terminal.
Congestion Detection
Reference : VAX SRS section 2.8.2
T08-01700
Purpose:
Action:
Result:
Action:
Result:
To show that congestion is detected by Queue detectors.
Arrange for a Queue detector bit to be high for at least two seconds.
An operational alarm will be generated and a message output.
Arrange for the Queue detector bit to clear for more than 2 seconds.
The fault is cleared and a message produced.
T08-01800
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
SYSTEST.DOC
To show that alarms can be inhibited for queue detectors when configured
plans are running.
Choose a queue detector which has had a list of fixed time plans
configured. Set the whole area to run on one of the listed fixed time plans.
Set the queue bit high for three seconds.
The alarm is not generated but the message is produced.
Set the queue bit low for three seconds.
A message is produced.
Set the whole area to run on a plan which is not listed. Set the queue bit
high for three seconds.
The alarm is generated and the message is produced.
Set the queue bit low for three seconds.
The alarm is cancelled and a message is produced.
Set the subarea containing the detector to run on one of the listed fixed
time plans. Set the queue bit high for three seconds.
Issue 11.0 Page 8-87
System Test Specification for a VAX/VMS UTC System
Result:
Action:
Result:
Action:
Result:
Action:
Result:
666/YJ/16940/000
The alarm is not generated but the message is output.
Set the queue bit low for three seconds.
A message is produced.
Set the subarea containing the detector to run on a plan which is not
listed. Set the queue bit high for three seconds.
The alarm is generated and the message is output.
Set the queue bit low for three seconds.
The alarm is cancelled and a message is produced.
T08-01900
Purpose:
Action:
Result:
Action:
Result:
To show that congestion is detected by occupancy detectors.
Select a number of count detectors which have occupancy detection with
their thresholds set to different levels. Using the simulator increase the
occupancy of each detector in turn to increasing levels.
As each threshold is reached an operational alarm is generated and a
message output.
Decrease the occupancy of each detector in turn.
As each decreasing threshold is reached a message is output and the alarm
is cleared.
T08-01920
Purpose:
Action:
Result:
Result:
Action:
Result:
Action:
SYSTEST.DOC
To modify the congestion alarm values for an occupancy detector.
Obtain the current values for the Congestion Alarm Clear Percentage
(CACP) and Congestion Alarm Set Percentage by entering the following
commands :
VALU CACP Dnnnnn
and
VALU CASP Dnnnnn
where Dnnnnn is a count detector configured with an occupancy bit.
Enter the following command to alter the CASP parameter to a value
below the CACP value displayed :
CHAN CASP Dnnnnn VALUE
The command is accepted. The new value of CASP is now set to the same
as CACP.
Repeat the command entering a value greater than 100.
The command is rejected with a error message.
Repeat the command with VALUE set to the same as the CACP value.
Return the CASP parameter to its original value.
The commands are accepted.
Enter the following command to alter the CACP parameter to a value
above the CASP value displayed :
CHAN CACP Dnnnnn VALUE
Issue 11.0 Page 8-88
System Test Specification for a VAX/VMS UTC System
Result:
Result:
Action:
Result:
666/YJ/16940/000
The command is accepted. The new value of CASP is now set to the same
as CACP.
Repeat the command entering a value less than 1.
The command is rejected with an error message.
Repeat the command with VALUE set to the same as the CASP value.
Return the CACP parameter to its original value.
The commands are accepted.
8.3
Car Park Information Sub-System
8.3.1
Opening and Closing of Car Parks
Reference : VAX SRS section 2.8.5
T08-02000
Purpose:
Action:
Result:
To close a type 2 car park.
Set the car park state to SPACES.
Enter the CLOS command for a type 2 car park.
The car park state will change to CLOSED.
The STCS command shows the car park as CLOSED by
operator/timetable override.
A message will be output to the terminal and written to the system log
indicate that the car park has closed.
The associated "named" type signs state will depend on the other car
parks in the group. If this is the only car park in the group or the other car
parks are faulty or closed then the signs will show CLOSED.
The associated "entrance" type signs will show the appropriate legend
(SPACES or FULL).
The associated "city" type signs will treat the car park as CLOSED.
T08-02100
Purpose:
Action:
Result:
Action:
Result:
To show that the correct status is assigned to a type 2 car park when it is
closed.
a) Simulate a closed car park by entering the CLOS command.
b) Simulate a car park fault condition by setting the DF reply bit for the
relevant detector using the OVRB command for the same car park.
The car park status will change from CLOSED to FAULTY.
Clear the DF bit using the OVRB command.
The car park status will return to CLOSED.
T08-02200
Purpose:
Action:
SYSTEST.DOC
To open a type 2 car park.
Enter the OPEN command for the type 2 car park closed in test T0802000.
Issue 11.0 Page 8-89
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
a) The car park state will change from CLOSED to the appropriate
legend, shown by the STCS command.
b) A message will be output to the terminal and written to the system
log to indicate that the car park has opened.
c) The associated "named" type signs will show the appropriate legend.
d) The associated "entrance" type signs will show the appropriate
legend.
e) The associated "city" type signs will treat the car park according to
its current state.
T08-02300
Purpose:
Action:
Result:
To test the response to a type 3 car park closing.
a) Use OVRB to set the CC bit to close a car park.
b) Use OVRB to change the vehicles present count.
a) The car park state will change to CLOSED, shown by the STCS
command.
b) A message will be output to the terminal and written to the system log
to indicate that the car park has closed.
d) The associated "named" type signs state will depend on the other signs
in the group.
e) The associated "entrance" type signs states will be set to cause the
appropriate legend to be displayed.
f) The associated "city" type signs will treat the car park as CLOSED.
T08-02400
Purpose:
Action:
Result:
Action:
Result:
To show that the correct status is assigned to a type 3 car park when it is
closed.
a) Simulate a closed car park by setting the CC reply bit for a type 3 car
park, using the OVRB command.
b) Simulate a car park fault condition by setting the DF reply bit for
the relevant detector using the OVRB command for the same
car park.
The car park status will change from CLOSED to FAULTY.
Clear the DF bit using the OVRB command.
The car park status will return to CLOSED.
T08-02500
Purpose:
Action:
Result:
SYSTEST.DOC
To test the response to a type 3 car park opening.
a) Set the car park state to SPACES.
b) Use an outstation test set to clear the CC bit to open a car park.
c) Use the outstation test set to change the vehicles present count.
a) The car park state will change from CLOSED to the appropriate state.
b) A message will be output to the terminal and written to the system log
to indicate that the car park has opened.
Issue 11.0 Page 8-90
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
c) The associated "named" type signs will depend on the other signs in the
group.
d) The associated "entrance" type signs will show the appropriate legend.
e) The associated "city" type signs will treat the car park according to its
current state.
T08-02600
Purpose:
Action:
Result:
Action:
Result:
8.3.2
To show that the correct status is assigned to a type 4 car park when it is
closed.
a) Simulate a closed car park by setting the CC reply bit for a type 4 car
park, using the OVRB command.
b) Simulate a car park fault condition by setting the CE reply bit using
the OVRB command for the same car park.
The car park status will change from CLOSED to FAULTY
Clear the CE bit using the OVRB command.
The car park status will return to CLOSED.
Car Park threshold values
Reference : VAX SRS section 2.8.5
T08-02700
Purpose:
Action:
Result:
To test for the correct response when threshold values are passed.
a) Use a OVRB or CHAN VEHC to change the vehicles present count so
that each threshold value is exceeded.
b) Repeat for all thresholds on each type of car park
a) The car park state will change.
b) A message will be output to the terminal and the system log to indicate
the new car park state. Check that associated signs show the correct
state.
T08-02800
Purpose:
Action:
Result:
Action:
Result:
To show that threshold values may be changed by the user.
Using the CHAN command modify the threshold values of a number of
car parks of each type. Attempt to change some thresholds to invalid
values. Also, in one case, remove the almost full state by setting the
almost full thresholds to zero.
The valid thresholds are accepted and the invalid ones rejected.
Repeat the test using various threshold values.
The car park states change and the messages are output at the new
thresholds.
T08-02900
Purpose:
SYSTEST.DOC
To show that the car park capacity may be set by the operator up to 1999
vehicles.
Issue 11.0 Page 8-91
System Test Specification for a VAX/VMS UTC System
Action:
Result:
Action:
Result:
Action:
Result:
8.3.3
666/YJ/16940/000
For a car park which is FULL, use the CHAN CAPA command to
attempt to reduce the capacity of the car park below the full threshold.
The command is rejected.
Increase the capacity of the car park. Using CHAN VEHC increase the
number of cars in the car park to above the old capacity.
No error is produced and VALU VEHC shows that the requested number
of vehicles are in the car park.
Attempt to set a car park capacity to 2000.
The command is rejected.
Car Park Occupancy Faults
Reference : VAX SRS section 2.8.5
T08-03000
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
To demonstrate car park occupancy faults for type 2 and 3 car parks.
Using OVRB on an entrance detector for a type 2 or type 3 car park,
cause the occupancy to go above the capacity.
An alarm is generated a fault logged and a message output.
Using OVRB on an exit detector for the car park, cause the occupancy to
fall below the capacity and clear the fault.
The fault is cleared.
Cause the occupancy to go below zero.
An alarm is generated a fault logged and a message output.
Cause the occupancy to rise above zero and clear the fault.
The fault is cleared.
T08-03100
Purpose:
Action:
Result:
Action:
Result:
To demonstrate car park occupancy faults for type 4 car parks.
Cause the BCD code returned to a type 4 car park to change by more
than the configured number in less than the configured time.
A System alarm is generated a fault reported and the car park set to
FAULTY.
Clear the fault. Set the BCD Reply to an invalid code.
Within 5 seconds a fault is set on the car park.
T08-03200
Purpose:
Action:
Result:
SYSTEST.DOC
To demonstrate the occupancy on System startup.
For a car park of each type which does not have a fault determine the
occupancy. Also note the current value in the Weighted average table.
Restart the System. Determine the occupancy of the test car parks after
the restart.
The type 2 and 3 car parks will have the occupancy assigned from the
weighted average table. Type 4 car parks take the occupancy from the
current BCD count.
Issue 11.0 Page 8-92
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T08-03220
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
To show that type 2 and 3 car parks are monitored for no change in
vehicle counts over a configured period.
Select or create a type 2 or 3 car park with one entry and one exit
detector. Set the vehicle count stuck time to 1 hour.
Change the system time to any value between 19:00 and 05:59
Override the VC bits on the two detectors with the same value such that
the car park occupancy remains constant.
Wait for one hour.
No fault is raised.
Change the system time to any value between 07:00 and 17:59 and repeat
the test.
After one hour a non-isolating fault is raised and an appropriate message
is output.
Change the state of the VC bit on one of the detectors.
The fault is cleared.
T08-03230
Purpose:
Action:
Result:
To show that a type 4 car park is monitored for no change in vehicle
counts over a configured period.
Repeat test T08-03220 for a type 4 car park. The number of vehicles is
fixed by overwriting the BCD counts from the car park reply bits.
As for test T08-03220.
Car Park Groups
Reference : VAX SRS section 2.8.5
Note :
This test requires at least five car park groups each containing at least one
car park of each type. Each group should have at least one CITY type
sign associated with it and one group should have an Entrance type sign
associated with it. The state of car park groups may be determined by
monitoring the state of the associated City or Entrance signs.
T08-03300
Purpose:
Action:
Result:
To show that the requested states for named and entrance signs are the
same as the car park group state and car park entrance state respectively.
N.B. This test allows the following test to be performed correctly
Determine from the database the bit pattern associated with each state of
named signs and Entrance signs. Using DIPM (Display and Process
Monitor) check that for each state and entrance state of a group of car
parks the correct sign state is demanded.
The Group states and sign states correspond.
T08-03400
Purpose:
SYSTEST.DOC
To demonstrate the states of car park groups.
Issue 11.0 Page 8-93
System Test Specification for a VAX/VMS UTC System
Action:
Result:
666/YJ/16940/000
Considering just one car park group adjust the occupancy or state of the
car parks in that group such that:
only one has a SPACES state
none have SPACES and one is ALMOST FULL
none have SPACES or ALMOST FULL and one is FULL (N.B. some
may be CLOSED or FAULTY)
none have SPACES ALMOST FULL or FULL and one is CLOSED
(N.B. some may be faulty)
all are FAULTY
all have an entrance state of FULL
The status of the group is SPACES.
The status of the group is ALMOST FULL.
The status of the group is FULL
The status of the group is CLOSED
The status of the group is FAULTY
The entrance state of the group is FULL (in all other cases the entrance
state is SPACES)
T08-03500
Purpose:
Action:
Result:
SYSTEST.DOC
To show that City signs go to the correct states depending on group
states.
For a City sign with 3 associated car park groups. Set the states of the
groups so that they compare in turn with each of the following list.
car park group 1 state is SPACES
groups 2 & 3 are in any state.
car park group 2 state is SPACES
group 1 is not SPACES group 3 is any state
car park group 3 state is SPACES
groups 1 & 2 are not SPACES
car park group 1 state is ALMOST FULL
groups 1 to 3 are not SPACES
car park group 2 state is ALMOST FULL
group 1 is not SPACES or ALMOST FULL group 3 is not spaces
car park group 3 state is ALMOST FULL
groups 1 to 3 are not SPACES
all car park groups are CLOSED
all car parks are FULL
The City signs are set to the following corresponding states. this can be
verified by checking the bit pattern associated in the database with each
sign state.
GROUP 1 SPACES
GROUP 2 SPACES
Issue 11.0 Page 8-94
System Test Specification for a VAX/VMS UTC System
Action:
Result:
Action:
Result:
666/YJ/16940/000
GROUP 3 SPACES
GROUP 1 ALMOST FULL
GROUP 2 ALMOST FULL
GROUP 3 ALMOST FULL
FULL
Repeat this test for a City sign associated with two groups only ie
omitting states (c) and (f).
The same as before except omitting states (c) and (f).
Set one of the car park groups to be FAULTY. Repeat the test.
The FAULTY car park group behaves according to a preset default state,
determined at system build time, for calculating sign states.
T08-03550
Purpose:
Action:
Result:
Action:
Result:
8.3.4
To ensure that when a car park state is overridden by operator command
the state of the car park group changes accordingly.
Use the CARP command to change the state of various car parks within a
group.
The state of the car park group reflects the state of all the car parks within
the group regardless of the source of the state.
Use the XCAR command to remove the operator override.
The state of the car park group becomes that derived from the occupancy
states of the car parks within the group.
Car Park States
Reference : VAX SRS section 2.8.5
T08-03600
Purpose:
Action:
Result:
Action:
To show that car parks move between states when expected.
For a car park which has SPACES increase the occupancy until it is one
greater than the almost full increasing threshold.
The car park state changes to ALMOST FULL.
Increase the occupancy to one greater than the full increasing threshold.
Result:
Action:
Result:
Action:
Result:
The car park state changes to FULL.
Reduce the occupancy to one below the full decreasing threshold.
The car park state changes to ALMOST FULL.
Reduce the occupancy to one below the almost full decreasing threshold.
The car park state changes to SPACES.
T08-03700
Purpose:
Action:
SYSTEST.DOC
To show that a delay may be associated with a move to a less full state.
Associate a delay in the range 0 to 7 minutes with a car park. Repeat the
previous test.
Issue 11.0 Page 8-95
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
When the car park is taken from FULL to ALMOST FULL and from
ALMOST FULL to SPACES there is a delay of the configured time
between the occupancy changing and the car park state changing.
T08-03800
Purpose:
Action:
Result:
Action:
Result:
To show that the Entrance state changes when expected.
Increase the occupancy to the Entrance threshold.
The Entrance state changes from SPACES to FULL.
Decrease the occupancy to one below the Entrance threshold.
The Entrance state changes from FULL to SPACES.
T08-03850
Purpose:
To show that the state of a car park can be overridden by the use of the
CARP command.
Action:
For a car park which has a state of spaces use the CARP Cxxxxx FULL
command to change the occupancy level of the car park.
Result:
The occupancy state of the car park shows full.
Action:
The above test should be repeated for the following cases:
Actual State Overridden State
Spaces
Almost full
Almost full Spaces
Almost full Full
Full
Spaces
Full
Almost full
Results:
In each case the occupancy state of the car park agrees with the
overriding state.
T08-03860
Purpose:
Action:
Result:
Action:
Result:
SYSTEST.DOC
To show that the state of a car park reverts to its correct state, as
determined by its occupancy level, when the operator override of car park
state is removed by use on the XCAR command.
For a car park which has a state of spaces use the CARP Cxxxxx FULL
command to change the occupancy level of the car park.
Check that the state of the car park has changed correctly.
Issue the XCAR Cxxxxx command to cancel the operator override of car
park state.
The occupancy state of the car park reverts to the correct state as
determined by its occupancy level.
Issue various combinations of CARP and XCAR commands.
In each case the occupancy state of the car park reverts to the correct
state as determined by its occupancy level.
Issue 11.0 Page 8-96
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T08-03880
Purpose:
Action:
Result:
8.3.5
To show that the STCS command displays the current vehicle count and
occupancy of a car park.
Enter the STCS command for a car park.
The display show the current status of the car park, the number of
vehicles, and the occupancy as a percentage of the number of vehicles
divided by the capacity.
Car Park signs
Reference : VAX SRS section 2.8.5
T08-03900
Purpose:
Action:
To show that sign legends may be controlled by operator commands.
a) Use the SSTO command to override the current sign state for a sign.
b) Repeat for all types of sign.
Result:
The sign state shall change to the state selected.
T08-04000
Purpose:
Action:
Result:
To show that the operator override of a sign remains in force until it is
cancelled.
Change the car park status.
The sign state shall not change and the message "Sign change not
implemented: override in force" shall be output.
T08-04100
Purpose:
Action:
Result:
To show that operator imposed sign override can be cancelled.
Cancel the sign state override by using the XSST command.
The sign shall show the state as determined by the state(s) of the car
park(s) which drive the sign.
T08-04200
Purpose:
Action:
Result:
To show that the state of an individual sign may be controlled by
timetable.
Repeat tests T08-03900 and T08-04100 using commands in the timetable.
Same effect as before.
T08-04300
Purpose:
Action:
Result:
SYSTEST.DOC
To show the response to a sign fault.
Simulate a sign fault by changing the sign reply bits, using OVRB, so that
they do not correspond with the control bits.
The "Sign invalid reply state" message will be output to the terminal and
be written to the system log after the configurable delay time (30 seconds)
Issue 11.0 Page 8-97
System Test Specification for a VAX/VMS UTC System
Action:
Result:
666/YJ/16940/000
has elapsed since the change of state (or after 2 seconds if there has been
no change of control state).
Enter the LSTF command for the faulty sign.
The fault message will be output.
T08-04400
Purpose:
Action:
Result:
Action:
Result:
To test that a sign fault can be cleared.
Clear the sign fault by using the XFLT command to reset sign.
The sign shall show the state as determined by the status of the car
park(s) which drive the sign.
Enter the LSTF command for the faulty sign.
The fault message will no longer be output.
T08-04500
Purpose:
Action:
Result:
Action:
Result:
To test the response when there is a car park sign OTU fault.
Simulate an OTU fault by disconnecting the power supply to the car park
sign OTU or by using OVRB.
a) A "Sign isolated" message shall be output and be written to the system
log for each sign on the OTU.
b) An OTU transmission fault message shall also be output.
Enter the LSTF command for the faulty OTU, and for each of the signs
The fault messages will be output.
T08-04600
Purpose:
Action:
Result:
Action:
Result:
To test the response when a car park sign OTU fault is cleared.
a) Reconnect the power supply to the car park sign OTU.
b) Use the XFLT command to clear the OTU fault from the current log.
The sign shall show the state as determined by the status of the car
park(s) which drive the sign.
Enter the LSTF command for the faulty OTU, and for each of the signs
The fault messages will no longer be output.
T08-04700
Purpose:
Action:
Result:
Action:
Result:
SYSTEST.DOC
To test the response to the SM bit being set (sign in manual mode).
a) Use OVRB to set the SM bit for a city sign.
a) A "Sign in manual mode" message will be output to the terminal and
written to the system log.
b) The instation will stop sending control data to the sign, which will be
isolated.
Reset the SM bit.
A "Sign manual mode cancelled" message and a "Sign reconnected"
message will be output.
Issue 11.0 Page 8-98
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T08-04800
Purpose:
Action:
Result:
To test the response to the SL bit being set (sign lamp failure).
a) Use OVRB to set the SL bit for a sign.
b) After a short interval reset the SL bit.
a) A "Sign lamp failure" message will be output to the terminal and
written to the system log.
b) When the SL bit is reset a "Sign lamp failure cleared" message will be
output.
T08-04850
Purpose:
Action:
Result:
8.3.6
To test that the SIGO command amends the group search order which is
used to determine the state of a city sign. In this case the aspect shown by
the sign is dependent upon which car park group is the first one in the list
of groups to have spaces.
Set up a city type car park sign to show different aspects which
correspond to the different groups associated with the sign having the
state of spaces.
Set the occupancy levels of the car parks in each group so that some of
the groups are full and some have spaces.
Use the SIGO command to change the search order of the groups.
The sign aspects change according to the search order.
Car Park Sign Exercising
T08-04850
Purpose:
Action:
Result:
To prove that a sign exercising command issued by an operator sends the
appropriate sequence of control bits to a sign and responds with
appropriate messages during and on completion of the exercising of a
single sign.
Monitor the control and reply bits for a sign by use of the MONI screen.
Issue a CHSI Sxxxxx command.
The correct sequence of control bits is transmitted and on completion of
exercising an appropriate message is shown.
Should the sign be faulty the sign is reported as such and exercising
halted.
T08-04860
Purpose:
Action:
SYSTEST.DOC
To prove that a sign exercising command issued from a timetable sends
the appropriate sequences of control bits to each of the signs in turn and
responds with appropriate messages during and on completion of the
exercising of a single sign.
Amend a timetable to include a CHSI command for a suitable time of day
and divert (using the > operator) its output to a printer.
Monitor the control and reply bits for a number of signs by use of
MONI screen displays.
Issue 11.0 Page 8-99
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
Sign exercising starts at the appointed time and the correct sequence of
control bits is transmitted to each sign and on completion of exercising an
appropriate message is shown.
Any signs which are found to be faulty are reported with appropriate
fault messages. On becoming faulty the exercising of that sign should
cease and exercising of the next sign should start.
T08-04870
Purpose:
Action:
Result:
To prove that a the XCHS command halts the exercising of signs which
has been initiated by operator command.
Issue a CHSI Cxxxxx command.
After a short delay Issue a XCHS command.
Sign exercising stops when the XCHS command is received by the
System.
T08-04880
Purpose:
Action:
Result:
8.3.7
To prove that a the XCHS command halts the exercising of signs which
has been initiated by a timetable command.
Amend a timetable to include a CHSI command for a suitable time of day
and divert (using the > operator) its output to a printer.
Monitor the control and reply bits for a number of signs by use of MONI
screen displays.
Issue a XCHS command.
Sign exercising stops when the XCHS command is received by the
System.
Car Park faults
Reference : VAX SRS section 2.8.5
T08-04900
Purpose:
Action:
Result:
Action:
Result:
SYSTEST.DOC
To test the response when a detector fault occurs in the car park barrier
equipment. Type 4 car parks only.
Set the CE bit to one using the outstation test set.
a) A "car park barrier fault" message will be output to the terminal and be
written to the system log.
b) "Named" signs will depend on the other signs in the group. If these are
all faulty then a default value will be used for the sign state.
c) "Entrance" signs will show the last correct state.
d) "City" signs will treat the car park as FAULTY.
Enter the LSTF command for the faulty car park.
The fault message will be output.
Issue 11.0 Page 8-100
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T08-05000
Purpose:
Action:
Result:
Action:
Result:
To test the response when the car park barrier equipment ceases to be
faulty.
Using the outstation test set, reset the CE bit to zero.
a) A "car park barrier fault cleared" message will be output to the
terminal and be written to the system log.
b) The signs will reflect the current car park state.
Enter the LSTF command for the faulty car park.
The fault message will no longer be output.
T08-05100
Purpose:
Action:
Result:
Action:
Result:
To test the response when there is an OTU fault on car park barrier
equipment.
Simulate an OTU fault on car park barrier equipment by disconnecting the
power supply to the car park OTU.
a) The car park state shall become faulty.
b) An error message will be output to the terminal and written to the
system log.
c) The "named" signs will show a state dependent on the other car parks
in the group.
d) The "Entrance" signs will sho the last correct state.
e) The "City" signs will treat the car park as faulty.
Enter the LSTF command for the faulty OTU.
The fault message will be output.
T08-05200
Purpose:
Action:
Result:
Action:
Result:
To test the response when an OTU fault is cleared.
Reconnect the power supply to the car park OTU. Use the 'XFLT'
command to clear the OTU fault.
a) The car park state will be restored and a message indicating the current
state will be output.
b) The signs will reflect the current car park state.
Enter the LSTF command for the faulty OTU.
The fault message will no longer be output.
T08-05300
Purpose:
Action:
Result:
SYSTEST.DOC
To test the response when a car park detector fault occurs on a type 2 car
park.
Set the DF bit for the relevant detector for a type 2 car park using the
outstation test set.
a) An appropriate car park faulty message will be output and be written
to the system log.
Issue 11.0 Page 8-101
System Test Specification for a VAX/VMS UTC System
Action:
Result:
666/YJ/16940/000
b) A "detector faulty" message will be output and be written to the system
log.
b) "Named" signs will be dependant on the other signs in the group.
b) "Entrance" signs will show the last correct state.
b) "City" signs will treat the car park as faulty.
Enter the LSTF command for the faulty detector.
The fault message will be output.
T08-05400
Purpose:
Action:
Result:
Action:
Result:
To test the response when the car park detector ceases to be faulty.
Using the outstation test set, clear the DF bit.
a) An appropriate car park fault cleared message will be output and be
written to the system log.
b) A "detector fault cleared" message will be output and be written to the
system log.
b) The signs will reflect the current car park state.
Enter the LSTF command for the faulty detector.
The fault message will no longer be output.
T08-05500
Purpose:
Action:
Result:
Action:
Result:
To test the response when there is an OTU fault on type 2 car park
detector equipment.
Simulate a type 2 car park detector OTU fault by disconnecting the power
supply to the detector OTU.
a) The car park state will become faulty.
b) An error message will be output to the terminal and written to the
system log.
b) The "entrance" signs will show the last correct state.
b) The "named" signs will depend on the other car parks in the group.
b) The "city" signs will treat the car park as if faulty.
Enter the LSTF command for the faulty OTU.
The fault message will be output.
T08-05600
Purpose:
Action:
Result:
Action:
Result:
SYSTEST.DOC
To test the response when an OTU fault is cleared.
a) Reconnect the power supply to the OTU.
b) Use the XFLT command to clear the OTU fault.
a) The car park state will be restored and a message indicating the current
state will be output to the terminal and be written to the system log.
b) The signs will reflect the current car park state.
Enter the LSTF command for the faulty OTU.
The fault message will no longer be output.
Issue 11.0 Page 8-102
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T08-05700
Purpose:
Action:
Result:
Action:
Result:
To test the response when a car park detector fault occurs on a type 3 car
park.
Set the DF bit for the relevant detector for a type 3 car park using the
outstation test set.
a) An appropriate car park faulty message will be output to the terminal
and be written to the system log.
b) A "detector faulty" message will be output to the terminal and be
written to the system log.
b) "Named" signs will depend on the other car parks in the group.
b) "Entrance" signs will show the last correct state
b) "City" signs will treat the car park as faulty.
Enter the LSTF command for the faulty detector.
The fault message will be output.
T08-05800
Purpose:
Action:
Result:
Action:
Result:
To test the response when the car park detector ceases to be faulty.
Using the outstation test set, clear the DF bit.
a) An appropriate car park fault cleared message will be output and be
written to the system log.
b) A "detector fault cleared" message will be output and be written to the
system log.
b) The signs will reflect the current car park state.
Enter the LSTF command for the faulty detector.
The fault message will no longer be output.
T08-05900
Purpose:
Action:
Result:
Action:
Result:
To test the response when there is an OTU fault on the type 3 car park
detector equipment.
Simulate a type 3 car park detector OTU fault by disconnecting the power
supply to the detector OTU.
a) The car park state will become faulty.
b) The "entrance" signs will show the last correct state.
b) The "named" signs will show a state dependent on the other car parks
in the group.
b) The "city" signs will treat the car park as faulty.
Enter the LSTF command for the faulty OTU.
The fault message will be output.
T08-06000
Purpose:
Action:
SYSTEST.DOC
To test the response when an OTU fault is cleared.
a) Reconnect the power supply to the OTU.
Issue 11.0 Page 8-103
System Test Specification for a VAX/VMS UTC System
Result:
Action:
Result:
8.3.8
666/YJ/16940/000
b) Use the XFLT command to clear the OTU fault.
a) The car park state will be restored and a message indicating the current
state will be output.
b) The signs will reflect the current car park state.
Enter the LSTF command for the faulty OTU.
The fault message will no longer be output.
Car Park vehicle counts and weighted averages
Reference : VAX SRS section 2.8.3
T08-06100
Purpose:
Action:
Result:
Action:
Result:
To show that vehicles entering and leaving the car park are correctly dealt
with.
Enter the CHAN VEHC command to set the number of vehicles in the car
park to 0.
The number of vehicles in the car park will be set to 0.
a) Simulate entry and exit of vehicles to and from a car park using a count
detector simulator to simulate an appropriate car park entry count
detector.
b) Periodically use the car park display commands to display the number
of vehicles currently in the car park.
The displayed number of vehicles in the car park will be the same as the
actual simulated number of vehicles in the car park.
T08-06200
Purpose:
Action:
Result:
To show that the Weighted average table is correctly output.
Enter the command WAVC Cnnnnn where nnnnn is a valid car park SCN
for each car park on the system.
For each car park there is a value for each one hour period for each day of
the week.
T08-06300
Purpose:
Action:
Result:
Action:
Action:
Result:
Action:
SYSTEST.DOC
To show that the weighted averages table is updated.
Enter the WAVC command for a type 2 car park.
The weighted averages values will be output.
Note the values for a selected time and day.
Set the date and time forward to the next hour (which ends in the 30th
minute) boundary.
The weighted averages value will be updated according to the formula:
new value = ((existing value x week no) + current number of vehicles in
car park)/(week no +1)
week no is used to weight the value up to a maximum of 7.
Repeat several times.
Issue 11.0 Page 8-104
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
as the previous result.
T08-06400
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
To show that the weighted averages table is used on a type 2 car park
when the fault is cleared on a faulty car park.
Enter the WAVC command for a type 2 car park.
The weighted averages values will be output.
Note the values for a selected time and day.
Set the DF bit for the car park detector, using the OVRB command.
An appropriate car park faulty message will be output to the terminal and
be written to the system log.
A "detector faulty" message will be output to the terminal and be written
to the system log.
Set the date and time forward to that previously selected.
Clear the car park detector DF bit.
An appropriate car park fault cleared message will be output and be
written to the system log.
A "detector fault cleared" message will be output and be written to the
system log.
Enter, after the next 15 minute boundary, the VALU VEHC command to
list the number of vehicles in the car park.
The number of vehicles should be equal to the relevant value in the
weighted averages table.
T08-06500
Purpose:
Action:
Result:
8.3.9
To show that the weighted averages table is used on a type 3 car park
when the fault is cleared on a faulty car park.
Repeat T08-06400 for a type 3 car park.
The results are as for T08-06400.
Car Park Queue detection
Reference :
T08-06530
Purpose:
Action:
Result:
Action:
SYSTEST.DOC
To show that the queueing time for a car park can be displayed.
In the UTC data preparation form for count detectors create, for a car
park, a single type 3 car park queue detector.
Attempt to enter values in the occupancy and queue times that are not in
an increasing sequence.
The values are rejected.
Set the smoothing factor to 100 and the 4 range parameters to values such
as :
Range
Occupancy Time (minutes)
Issue 11.0 Page 8-105
System Test Specification for a VAX/VMS UTC System
Result:
Action:
Result:
666/YJ/16940/000
1
1 to 25
3
2
26 to 49
10
3
50 to 74
20
4
75 to 100 30+
Set up an OVRB display for the detector and prepare to toggle the VO bit
on and off. For an occupancy of 100% the number of changes in a period
of 32 seconds should be 25. Do not exceed this frequency.
On another screen set up a PICT display containing the car park.
Start to toggle the VO bit such that an occupancy value in each range is
simulated. For example, for range 1 simulate 5 changes per 32 seconds,
which should give an occupancy of 20%. Maintain each range for at least
3 minutes.
Enter the STCS command for the car park at regular intervals.
The PICT and STCS displays should show queue time values equivalent
to the percentage occupancy set up in the above table.
Repeat the above test for a count detector type 4.
As for the previous tests.
T08-06550
Purpose:
Action:
Result:
Action:
Result:
To show that the high occupancy values for each range of an occupancy
queue detector can be altered from the system prompt.
Enter the following commands :
CHAN CQT1 Dnnnnn val1
CHAN CQT2 Dnnnnn val2
CHAN CQT3 Dnnnnn val3
CHAN CQT4 Dnnnnn val4
where :
Dnnnnn is the SCN of the detector in test T08-06530.
val1, val2 val3 and val4 are ascending values in the range 1 to 100.
The commands are accepted.
Repeat the test but using values that are not in an ascending order, greater
than 100 and negative values.
The commands are rejected.
Car Park timetable and operator commands
Reference : VAX SRS section 2.8.5
T08-06600
Purpose:
Action:
Result:
SYSTEST.DOC
To show that car park/car park sign status commands can be actioned
from a timetable.
List the timetable which contains commands for car parks.
The timetable should contain all the car park status commands which may
be actioned from a timetable. i.e.
Issue 11.0 Page 8-106
System Test Specification for a VAX/VMS UTC System
Action:
Result:
666/YJ/16940/000
CLOS - close car park;
OPEN - open car park;
STCS - list status of car park or car park sign;
SSTO - impose or remove a car park sign state;
SIGO - change car park sign group search order;
CARP - change car park status
Set the time and date in order to cause the timetable to be run, and to
select the relevant car park commands.
The commands will be run as appropriate.
T08-06700
Purpose:
Action:
To demonstrate the operator change and display commands for car parks.
For each of the parameters:
Almost full increasing threshold
(AFDT)
Almost full decreasing threshold (AFIT)
Car Park capacity
(CAPA)
Full increasing threshold
(FDTH)
Full decreasing threshold
(FITH)
Green/red entrance threshold
(GRET)
Vehicle count
(VEHC)
Perform the following tests:
Result:
a) Display the current value using the VALU command.
a) Change to another valid value using the CHAN command.
a) Attempt to change to an invalid value using the CHAN command.
Test (a) and (b) display and change the parameter value as directed. The
command in test (c) is rejected.
T08-06750
Purpose:
Action:
Result:
Action:
Result:
Action:
SYSTEST.DOC
To demonstrate the operator car park state override command.
For a car park with an occupancy level which gives a state of spaces use
the CARP command to set the car park state to full and almost full.
The car park acquires the new state. If the car park does not have an
almost full state any CARP command which attempts to set it to almost
full is rejected.
Repeat the previous tests with various combinations of initial car park
states and CARP commands.
The commands are accepted of rejected, as appropriate.
Use the XCAR command to remove the operator override of car park
state.
Issue 11.0 Page 8-107
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
The car park state becomes that which is determined from its current
occupancy level.
T08-06800
Purpose:
Action:
Result:
To demonstrate the timetable change and display commands for car parks.
For each of the parameters from the previous test repeat the same test
actions but with the commands included in the timetable (at suitably
spaced intervals).
Test (a) and (b) display and change the parameter value as directed. The
command in test (c) is rejected by timetable preparation.
T08-06900
Purpose:
Action:
Result:
8.3.10
To demonstrate the change and display commands for car parks in
CASTs.
Attempt the previous two tests with the commands included in CASTs.
The same results are achieved.
Car Park Occupancy Recording
T08-06950
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
To show that the occupancy of a car park is correctly recorded.
Use the CHAN VEHC command to set the number of vehicles in the car
park to 0.
Use the count detector data from the entrance and exit count detectors to
derive the occupancy of the car park for a number of quarter hour
periods.
Use the CPOC Cxxxxx TOD to output the current day's occupancy data.
The two sets of occupancy data should agree.
Allow the System to run for a number of days in order to accumulate
historic count and occupancy data.
Use the CPOC Cxxxxx <day> and CPOC Cxxxxx <date> commands to
output historical car park occupancy data.
Compare the occupancy values with those derived from the relevant count
detector data.
The two sets of occupancy data should agree.
Use the CPOC Cxxxxx >Txxxxx to output the car park occupancy data to
a hard copy terminal.
The hard copy data agrees with that shown on a VDU.
8.4
Diversion Control System
8.4.1
INTD/REMD/SSTO commands - invalid command lines
Reference : MCE 0360C paragraph 4.8.2 VAX SRS 2.8.6
SYSTEST.DOC
Issue 11.0 Page 8-108
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T08-07000
Purpose:
Action:
Result:
To prove that invalid command lines for the INTD operator command are
rejected by the system.
At an operators terminal enter the following commands INTD
INTD Uaaaaa Ubbbbb
where aaaaa and bbbbb are both valid
diversion SCNs.
INTD Uccccc
where ccccc is a non-existent diversion SCN.
The commands are rejected with appropriate error messages.
T08-07100
Purpose:
Action:
Result:
To prove that invalid command lines for the REMD operator command
are rejected by the system.
At an operators terminal enter the following commands REMD
REMD Uaaaaa Ubbbbb
where aaaaa and bbbbb are both valid
diversion SCNs.
REMD Uccccc
where ccccc is a non-existent diversion SCN.
The commands are rejected with appropriate error messages.
T08-07200
Purpose:
Action:
Result:
8.4.2
To prove that invalid command lines for the SSTO operator command are
rejected by the system.
At an operators terminal enter the following commands SSTO
(missing parameters)
SSTO Taaaaa
(invalid SCN)
SSTO Vaaaaa OPEN (invalid parameter)
SSTO Vaaaaa ON 99 (too many parameters)
The commands are rejected with appropriate error messages.
Operator-introduced Diversions
Reference : MCE 0360C paragraph 4.8.2, 4.8.6 VAX SRS 2.8.6
T08-07300
Purpose:
Action:
Result:
SYSTEST.DOC
To prove that it is possible to start up to the configured number of
diversions by operator commands
Enter the operator command INTD Uaaaaa
where aaaaa is a valid diversion SCN.
A message appears on the VDU to indicate that the diversion has been
started.
Issue 11.0 Page 8-109
System Test Specification for a VAX/VMS UTC System
Action:
666/YJ/16940/000
Using the MONI command for each of the OTUs in the diversion in turn,
check that the control bit to the diversion sign (equipment type V) is
being sent.
Repeat for the other diversions defined in the database.
T08-07400
Purpose:
Action:
Result:
Action:
Result:
To prove that it is possible to end a diversion by operator command.
Enter the operator command REMD Uaaaaa
where aaaaa is the diversion started in T08-07300
above.
A message appears on the VDU to indicate that the diversion has stopped.
Use the MONI command to observe that the diversion sign bit is no
longer being sent to the OTUs.
Repeat the REMD command above.
The "accepted" message appears on the VDU and no further action is
taken.
T08-07500
Purpose:
Action:
Result:
Action:
Result:
To prove that if an essential sign is faulty then the diversion cannot be
introduced.
Select a diversion sign that is defined as "essential" in the database and
use a simulator to set a fault on the sign. This can be done by changing the
reply and control bits so that they are not the same.
The faulty sign is reported on all VDUs and is entered in the system log.
Enter the INTD command for any diversion that includes the faulty sign.
The diversion is rejected with an appropriate message.
T08-07600
Purpose:
Action:
Result:
To prove that if a diversion is operating and the essential sign develops a
fault then the diversion is cancelled.
Start the diversion described in T08-07300.
Set a fault on the essential sign as described in T08-07600.
The diversion is cancelled when the faulty sign is detected.
T08-07700
Purpose:
Action:
Result:
To prove that a faulty non-essential sign does not affect the diversion.
Repeat sub-tests T08-07500 and T08-07600 setting the fault on a nonessential sign.
The diversion is not affected by the fault.
T08-07800
Purpose:
Action:
SYSTEST.DOC
To prove that if a sign is detected as faulty for less than 3 seconds the
fault is not reported and hence has no effect on the diversion.
Use an instation test set to simulate a faulty sign for 2 seconds only.
Issue 11.0 Page 8-110
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
The fault is not reported.
T08-07900
Purpose:
Action:
Result:
To prove that a sign is not monitored for 30 seconds after a state change.
Start a diversion and then immediately simulate a fault on an essential sign
on that diversion. Sustain the fault for more than 30 seconds.
The fault is not reported until 30 seconds after the diversion was started.
The diversion is also terminated when the faulty sign is detected.
T08-08000
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
To prove that the setting of a diversion sign can be overwritten by
operator command.
Ensure that there is no diversion active.
Enter the operator command "SSTO Vbbbbb" where bbbbb is a valid
diversion sign SCN, to display the current state of the diversion sign
The current state is listed on the VDU. This can be checked with a MONI
display of the relevant OTU.
Enter a SSTO command to change the state of the diversion sign.
The MONI display shows that the state has changed.
Enter a SSTO command to restore the state of the diversion sign.
The MONI display shows that the state has changed.
T08-08100
Purpose:
Action:
Result:
Action:
Result:
To attempt to change the state of a diversion sign by operator command
when a diversion is active.
Start a diversion using the INTD command.
Enter a SSTO command to change the state of a non-essential sign in the
diversion.
The command is accepted and the state changed; the diversion is not
affected.
Enter a SSTO command to change the state of an essential sign in the
diversion.
The command is accepted and the diversion is cancelled.
T08-08200
Purpose:
Action:
Result:
SYSTEST.DOC
To show that an operator imposed sign state may be cancelled by
operator command.
Make sure that at least three diversion signs have operator imposed states
different from their normal condition for the current state of the system.
For one of the signs enter the command :
XSST <SCN>
The operator imposed state for the sign concerned is cancelled. This can
be verified by observing the relevant MONI display. It should be verified
that the other signs with operator imposed states are not affected.
Issue 11.0 Page 8-111
System Test Specification for a VAX/VMS UTC System
Action:
Result:
8.4.3
666/YJ/16940/000
Enter the command :
XSST V00000
All operator imposed diversion sign conditions are removed.
Timetable-introduced Diversions
Reference : MCE 0360C paragraph 4.8.2, 4.8.6 VAX SRS 2.8.6
T08-08300
Purpose:
Action:
Result:
8.4.4
To prove that diversions may be introduced and removed from the
timetable.
Repeat sub-tests T08-07300, T08-07400 and T08-07900 starting and
stopping diversions using INTD, REMD and SSTO commands from the
timetable.
The results will be the same as for associated sub-tests.
Remote requests for diversions
Reference : MCE 0360C paragraph 4.8.2, 4.8.6
VAX SRS 2.8.6
T08-08400
Purpose:
Action:
To prove that diversions may be introduced and removed by remote
requests.
Using a switch box attached to an OTU, select a switch to represent a
request for a diversion i.e. to set the RC reply bit in the OTU data.
Repeat sub-tests T08-07300 and T08-07400 using the switch to start and stop the
diversion.
Result:
As for the associated sub-tests.
T08-08500
Purpose:
Action:
Result:
8.4.5
To prove that diversions may be introduced and removed by remote
requests, where the remote request is associated with a lifting bridge.
Using a switch box attached to an OTU, select a switch to represent a
request for a diversion with lifting bridge i.e. to set the RC reply bit in the
OTU data.
Repeat sub-tests T08-07300 and T08-08100 using the switch to start and
stop the diversion.
As for the appropriate sub-tests with the additional alarms and messages
associated with the lifting bridge operation. NB. Only operational audible
alarm can be cancelled by ACKD whilst the bridge is raised the lamp may
only be cancelled when the bridge is once more open to traffic.
Diversions and Plan Changes
Reference : MCE 0360C paragraph 4.8.3
VAX SRS 2.8.4
SYSTEST.DOC
Issue 11.0 Page 8-112
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T08-08600
Purpose:
Action:
Result:
To prove that it is possible, from the timetable, to introduce and cancel a
diversion at the same time that a plan change is taking place.
Add the following pairs of temporary events to the current timetable, each
pair having the same time of execution a) INTD, SCOO
b) REMD, XSCO
c) INTD, PLAN
d) REMD, XPLA
In all cases, both commands are actioned in the order in which they
appear in the timetable and there is no adverse effect on the system.
T08-08700
Purpose:
Action:
Result:
8.4.6
To prove that it is possible, by operator command, to introduce and
cancel a diversion at the same time that a plan change is taking place.
Using a number (at least 2) of terminals, enter simultaneous operator
commands for plan change and diversions e.g. INTD and PLAN, REMD
and XPLA etc.
As for the timetable, the commands are actioned with no adverse effect on
the system.
Interdependent Diversions and Plan Changes
Reference : VAX SRS 2.8.6
T08-08800
Purpose:
Action:
Result:
Action:
Result:
SYSTEST.DOC
To introduce a diversion of type 0 (signs only).
Enter the INTD command to introduce a diversion of group 0 type 0.
a) The diversion will be started.
b) The signs on the diversion will be changed after the specified delay.
b) The wall map lights for the diversion route will light up.
b) The wall map lights for the diversion signs will light up, at the same
time as the signs are switched on.
b) There will be no plan change.
Enter the INTD command to introduce another diversion in group 0 type
0.
a) The diversion will be started.
b) The signs on the diversion will be changed after the specified delay.
b) The wall map lights for the diversion signs will light up, when the signs
change state.
b) The wall map lights for the diversion route will light up.
b) There will be no plan change.
Issue 11.0 Page 8-113
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T08-08900
Purpose:
Action:
Result:
Action:
Result:
To remove the diversions of type 0.
Enter the REMD command to remove one of the previously started
diversions.
a) The diversion type will be cancelled.
b) The signs on the diversion route will be changed after the specified
delay.
b) The wall map lights for the diversion route will go out.
b) The wall map lights for the diversion signs will go out, when the signs
change state.
b) There will be no plan change.
Enter the REMD command to remove one of the previously started
diversions.
a) The diversion type will be cancelled.
b) The signs on the diversion route will be changed after the specified
delay.
b) The wall map lights for the diversion route will go out.
b) The wall map lights for the diversion signs will go out, when the signs
change state.
b) There will be no plan change.
T08-09000
Purpose:
Action:
Result:
To show that if an essential sign goes faulty the diversion containing it
will not be started.
a) Cause an essential sign contained in diversion group 0 type 0 to go
faulty by setting the relevant OTU faulty.
b) Enter the INTD command to introduce this diversion.
a) The diversion will not be started.
b) A relevant error message will be output.
c) The system audible alarm will be sounded.
d) The system alarm lamp on the alarm panel will flash.
T08-09100
Purpose:
Action:
Result:
SYSTEST.DOC
To show that if an essential sign goes faulty whilst an operator introduced
diversion containing it is active, the diversion will be cancelled.
Enter the INTD command to introduce diversion group 0 type 0.
a) The diversion will be started.
b) The signs on the diversion will be changed after the specified delay.
b) The wall map lights for the diversion route will light up.
b) The wall map lights for the diversion signs will light up when the signs
are turned on.
b) There will be no plan change.
Issue 11.0 Page 8-114
System Test Specification for a VAX/VMS UTC System
Action:
Result:
Action:
Result:
666/YJ/16940/000
a) Cause an essential sign contained in this diversion to go faulty by
setting the relevant OTU faulty.
a) The diversion will be cancelled.
b) The relevant wall map light will go out.
b) The diversion sign wall map lights will go out when the sign changes
state.
b) A relevant error message will be output.
b) The system audible alarm will be sounded.
b) The system alarm lamp on the alarm panel will flash.
Clear the diversion sign fault by clearing the OTU fault.
The diversion will not be re-introduced.
T08-09200
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
To show that if an essential sign goes faulty whilst a timetable introduced
diversion containing it is running, the diversion will be cancelled and reintroduced when the essential sign fault is cleared.
a) Select a timetable containing an introduce diversion command.
b) Set the time so that the diversion will run within a short time.
The diversion will be implemented.
Set an essential sign on the diversion route to faulty by setting the relevant
OTU faulty.
a) The diversion will be cancelled.
b) An error message will be output to the terminal.
b) The system audible alarm will be sounded.
b) The system alarm lamp on the alarm panel will flash.
Clear the sign fault by clearing the OTU fault.
The diversion will be re-introduced.
T08-09300
Purpose:
Action:
Result:
Action:
Result:
To show that a diversion introduced by a timetable command cannot be
cancelled by an operator command.
a) Select a timetable containing an introduce diversion command.
b) Set the time so that the diversion will run within a short time.
The diversion will be implemented.
Try to cancel the diversion by entering the operator command REMD for
the relevant diversion.
a) The diversion will not be cancelled.
b) A message will be output informing the operator that the timetable
command cannot be overridden with an operator command.
T08-09400
Purpose:
SYSTEST.DOC
To set up the time and date for the interdependent diversion tests.
Issue 11.0 Page 8-115
System Test Specification for a VAX/VMS UTC System
Action:
Result:
Action:
Result:
NOTE:
666/YJ/16940/000
Enter the DATE command and set the day to a Monday.
The day will be set to a Monday.
Enter the TIME command and set the time to the start of the first time
sector.
The time will be set to the beginning of time sector 1 (AM peak).
a) the time must stay within time sector 1 for the interdependent diversion
tests, until the time command is used to re-set the time.
b) The DISP command should be used to monitor the plan changes for
sub-area 29 (for example use J2921) throughout the tests.
T08-09500
Purpose:
Action:
Result:
To introduce interdependent diversions.
Enter the INTD command to introduce diversion group 1 type 1.
a) Group 1 will go to state 1.
b) Diversion type 1 in group 1 will be started.
b) The wall map lamp for the diversion route will light up.
b) The signs on diversion route 1 will be changed after the specified
delay.
b) The wall map lamps for the diversion signs will light up, when the signs
change.
b) Plan 1 for sub-area 29 will be introduced after a 1 minute delay.
T08-09600
Purpose:
Action:
Result:
To remove the diversion.
Enter the REMD command to remove diversion 1.
a) Group 1 will go to state 0.
b) Diversion type 1 in group 1 will be cancelled.
b) The wall map lamp for the diversion route will go out.
b) The signs on diversion route 1 will be changed after the specified
delay.
b) The wall map lamps for the diversion signs will go out, when the signs
change state.
b) The timetable plan due at the current time will be introduced after a
delay of 0.5 mins.
T08-09700
Purpose:
Action:
Result:
SYSTEST.DOC
To introduce and remove interdependent diversions in various sequences.
Enter the INTD command to introduce diversion group 1 type 1.
a) Group 1 will go to state 1.
b) Diversion type 1 in group 1 will be started.
b) The wall map light for the diversion route will light up.
Issue 11.0 Page 8-116
System Test Specification for a VAX/VMS UTC System
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
SYSTEST.DOC
666/YJ/16940/000
b) The signs on diversion route 1 will be changed after the specified
delay.
b) The wall map lights for the diversion signs will light up, when the signs
change.
b) Plan 1 for sub-area 29 will be introduced after a 1 minute delay.
Enter the INTD command to introduce diversion group 1 type 3.
a) Group 1 will go to state 4.
b) Diversion type 3 in group 1 will be started.
b) The wall map light for this diversion route will light up.
b) Diversion type 1 in group 1 will be cancelled.
b) The wall map light for this diversion will go out.
b) The signs belonging to diversions 1 and 3 will be changed after the
specified delay times.
b) The wall map lights for the diversion signs will go on for the
introduced diversion and go out for the cancelled diversion, when the
signs change state.
b) Plan 4 for sub-area 29 will be introduced after a delay of 4 minutes.
Enter the INTD command to introduce diversion group 1 type 3.
The command will be rejected.
Enter the INTD command to introduce diversion group 1 type 2.
a) Group 1 will go to state 2.
b) Diversion type 2 in group 1 will be started.
b) The wall map light for this diversion route will light up.
b) Diversion type 3 in group 1 will be cancelled.
b) The wall map light for this diversion route will go out.
b) The signs on the diversion routes 2 and 3 will be changed after the
specified delay times.
b) The wall map lights for the diversion signs will change state as
appropriate (i.e. those for type 2 will go on, those for type 3 will go
off).
b) Plan 2 for sub-area 29 will be introduced after a 2 minute delay.
Enter the INTD command to introduce diversion group 1 type 2.
The command will be rejected.
Enter the INTD command to introduce diversion group 1 type 1.
a) Group 1 will go to state 3.
b) Diversion type 1 in group 1 will be started.
b) The wall map light for the diversion route will light up.
b) The signs on the diversion routes 1 and 2 will be changed after the
specified delay.
b) The wall map lights for the diversion signs will light up, when the signs
change state.
b) Plan 3 for sub-area 29 will be introduced after a delay of 3 minutes.
Issue 11.0 Page 8-117
System Test Specification for a VAX/VMS UTC System
Action:
Result:
666/YJ/16940/000
Enter the REMD command to cancel diversion group 1 type 1.
a) Group 1 will go to state 2.
b) Diversion type 1 in group 1 will be cancelled.
b) The wall map light for the diversion route will go out.
b) The signs on the diversion route will be changed after the specified
delay.
b) The wall map lights for the diversion signs will go out, when the signs
change state.
b) Plan 2 for sub-area 29 will be introduced after a 2.5 minutes delay.
T08-09800
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
SYSTEST.DOC
To show that more that one diversion can run at a time.
Enter the INTD command to introduce diversion group 3 type 1.
a) Group 3 will go to state 1.
b) Diversion type 1 in group 3 will be started.
b) The wall map lights for the diversion route will light up.
b) The signs on the diversion route 1 will be changed after the specified
delay.
b) The wall map lights for the diversion signs will light up, when the signs
change state.
b) Plan 1 for sub-area 15 will be introduced after a delay of 0.5 minutes.
Enter the REMD command to cancel diversion group 1 type 2.
a) Group 1 will go to state 0.
b) Diversion type 2 in group 1 will be cancelled.
b) The wall map light for the diversion route will go out.
b) The signs on the diversion route will be changed after the specified
delay.
b) The wall map lights for the diversion signs will go out, when the signs
change state.
b) The timetable plan for the current time of day will be introduced for
sub area 29, after a delay of 1.5 minutes.
b) A relevant message will be output to indicate the end of the diversion
(plan) for sub-area 29 after the delay of 1.5 minutes.
Enter the REMD command to cancel diversion group 3 type 1.
a) Group 3 will go to state 0.
b) Diversion type 1 in group 3 will be cancelled.
b) The wall map light for the diversion route will go out.
b) The signs on the diversion route will be changed after the specified
delay.
b) The wall map lights for the diversion signs will go out, when the signs
change state.
b) The timetable plan for the current time of day will be introduced for
sub area 15, after a delay of 1 minute.
Issue 11.0 Page 8-118
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
b) A relevant message will be output to indicate the end of the diversion
(plan) for sub-area 15 after the delay of 1 minute.
T08-09900
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
To use time sector 2.
Enter the TIME command and set the time to the start of the second time
sector (PM peak period - 16:00).
The time will be set to the beginning of time sector 2.
Enter the INTD command to introduce diversion group 1 type 1.
a) Group 1 will go to state 1.
b) Diversion type 1 in group 1 will be started.
b) The wall map lights for the diversion route will light up.
b) The signs on diversion route 1 will be changed after the specified
delay.
b) The wall map lights for the diversion signs will light up, when the signs
change state.
b) Plan 3 for sub-area 29 will be introduced after a 1 minute delay.
Enter the REMD command to cancel diversion group 1 type 1.
a) Group 1 will go to state 0.
b) Diversion type 1 in group 1 will be cancelled.
b) The wall map light for the diversion route will go out.
b) The signs on the diversion route will be changed after the specified
delay.
b) The wall map light for the diversion signs will go out, when the signs
change state.
b) The timetable for the current time of day will be introduced after a
delay of 0.5 minutes.
T08-10000
Purpose:
Action:
Result:
Action:
Result:
SYSTEST.DOC
To use time sector 3.
Enter the TIME command and set the time to the start of the third time
sector.
The time will be set to the beginning of time sector 3 (OFF-peak, 08:00).
Enter the INTD command to introduce diversion group 1 type 1.
a) Group 1 will go to state 1.
b) Diversion type 1 in group 1 will be started.
b) The wall map light for the diversion route will light up.
b) The signs on diversion route 1 will be changed after the specified
delay.
b) The wall map lights for the diversion signs will light up, when the signs
change state.
b) Plan 5 for sub-area 29 will be introduced after a delay of 1 minute.
Issue 11.0 Page 8-119
System Test Specification for a VAX/VMS UTC System
Action:
Result:
666/YJ/16940/000
Enter the REMD command to cancel diversion group 1 type 1.
a) Group 1 will go to state 0.
b) Diversion type 1 in group 1 will be cancelled.
b) The wall map light for the diversion route will go out.
b) The signs on the diversion route will be changed after the specified
delay.
b) The wall map lights for the diversion signs will go out, when the signs
change state.
b) The timetable plan for the current time of day will be introduced after a
delay of 0.5 minutes.
T08-10100
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
SYSTEST.DOC
To use a different day, i.e Thursday.
Enter the DATE command and set the day to a Thursday
The day will be set to a Thursday.
Enter the TIME command and set the time to 11:48 (just before the end
of the first time sector(AM peak period)).
The time will be set to 11:48.
Enter the INTD command to introduce diversion group 1 type 1.
a) Group 1 will go to state 1.
b) Diversion type 1 in group 1 will be started.
b) The wall map light for the diversion route will light up.
b) The signs on diversion route 1 will be changed after the specified
delay.
b) The wall map lights for the diversion signs will light up, when the signs
change state.
b) Plan 1 for sub-area 29 will be introduced after a delay of 1 minute.
Wait for the time to change past 11:50 (time sector 3 (OFF PEAK)).
Plan 5 for sub-area 29 will be introduced.
Enter the TIME command and set the time to 19:00 (beginning of the
second time sector(PM peak period)).
Plan 3 for sub-area 29 will be introduced.
Enter the REMD command to cancel diversion group 1 type 1.
a) Group 1 will go to state 0.
b) Diversion type 1 in group 1 will be cancelled.
b) The wall map light for the diversion route will go out.
b) The signs on the diversion route will be changed after the specified
delay.
b) The wall map lights for the diversion signs will go out, when the signs
change state.
b) The timetable for the current day will be introduced for sub area 29
after a delay of 0.5 minutes.
Issue 11.0 Page 8-120
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T08-10200
Purpose:
Action:
Result:
Action:
Result:
8.5
To start a remotely requested diversion.
Set the relevant bit in the OTU reply word for a remote request diversion,
using the OVRB command.
The relevant diversion will be activated.
Clear the relevant bit in the OTU reply word for the remote request
diversion, using the OVRB command.
The diversion will be cancelled.
Fog Detection
Reference :
T08-10250
Purpose:
Action:
Result:
Action:
Result:
To show the operation of a fog detection remote request.
a) Define a fog detection remote request on an OTU, configure for one
sub-area.
b) On this sub-area create or edit two or more junctions configured with
solar override and solar bright bits.
b) Create another two junctions with the same bits on another sub-area.
b) Monitor one junction from each sub-area on MONI displays.
b) Set up an OVRB display for the OTU with the remote request, and
override the remote request with a 1.
b) After a period monitor the other junctions on the configured and
unconfigured sub-areas.
After 3 seconds an appropriate message is output to the system log. The
solar override bit is sent to the controllers on the configured sub-area and
solar bright is returned after a few seconds. The displays show the
junctions on the other sub-area are unchanged.
Cancel the override of the remote request.
After 3 seconds an appropriate message is output to the system log. The
solar override bit is removed and solar bright is no longer returned after a
few seconds on the junctions in the configured sub-area. The junctions on
the other sub-area remain unchanged.
8.6
SCOOT Detectors
8.6.1
SCOOT Detector Faults
Reference : VAX SRS section 2.8.7
T08-10300
Purpose:
SYSTEST.DOC
To confirm that a SCOOT detector goes to the suspect state when it has
been unoccupied for the required period of time.
Issue 11.0 Page 8-121
System Test Specification for a VAX/VMS UTC System
Action:
Result:
666/YJ/16940/000
a) Check the correct receipt of the simulated SCOOT detector
information, using the OTU Monitor display. Use the VALU DSTS
command to check that the detector is currently clear of faults.
b) Set the detector simulator to indicate zero occupancy. After a period
of 6 minutes repeat the VALU DSTS command.
The detector changes to the suspect state.
T08-10400
Purpose:
Action:
Result:
To confirm that a SCOOT detector goes to the faulty state when it has
been unoccupied for the required period of time.
Leave the detector simulator used above unoccupied for the configured
number of minutes.
The detector changes to the faulty state and a suitable message is output.
T08-10500
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
To confirm that a faulty/empty or suspect/empty SCOOT detector cannot
be returned to its normal state by operator command until it is no longer
unoccupied.
Use either the command XFLT or the command CHAN DSTS to attempt
to clear the detector fault.
The detector status only changes from faulty to the suspect state.
Repeat the clear command.
No change is observed in the detector status.
Resume normal replies to the detector.
After about 1 minute of valid replies the detector state changes to OK and
a fault clear message is output.
T08-10600
Purpose:
Action:
Result:
To confirm that a SCOOT detector goes to the suspect state when it has
been continuously occupied for the required period of time.
a) Check the correct receipt of the simulated SCOOT detector
information, using the OTU Monitor display (MONI). Use the VALU
DSTS command to check that the detector is currently clear of faults.
b) Set the detector simulator to indicate continuous occupancy. After a
period of 3 minutes repeat the VALU DSTS command.
The detector changes to the suspect state.
T08-10700
Purpose:
Action:
Result:
SYSTEST.DOC
To confirm that a SCOOT detector goes to the faulty state when it been
continuously occupied for the required period of time.
Leave the detector simulator used above occupied for the configured
amount of time.
The detector changes to the faulty state and a suitable message shall be
output.
Issue 11.0 Page 8-122
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T08-10800
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
To confirm that a faulty/full SCOOT detector cannot be returned to its
normal state by operator command until it is no longer fully occupied.
Use either the command XFLT or the command CHANDSTSNaaaaabn
OK (where aaaaabn is the SCN of the detector) to attempt to clear the
detector fault.
The detector status only changes from faulty to the suspect state.
Repeat the clear command.
No change is observed in the detector status.
Resume normal replies to the detector.
After about 1 minute of valid replies the detector state changes to OK and
a fault clear message is output.
T08-10900
Purpose:
Action:
Result:
To show that the SCOOT detector fault thresholds and delays are
configurable.
Repeat tests T08-10600 to T08-10800 with different thresholds including
the limit values.
The expected results as defined by the new thresholds are obtained.
T08-11000
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
8.6.2
To demonstrate the behaviour of detectors when an OTU is faulty.
Cause a fault on a test OTU by removing its power supply while
monitoring the corresponding junction on a DIPM display.
The replies from the detectors go permanently high but the state of the
detectors is not changed immediately. They then behave as though they
were continuously occupied as in tests T08-10600 and T08-10700.
Remove the fault condition.
Normal replies resume from the detectors. There is no change of state.
Clear the fault to suspect with XFLT.
The detector becomes suspect and after a short time of normal replies
becomes OK.
SCOOT Detector Checking
Reference : VAX SRS section 2.8.7
Note :
Each of these tests takes 1 hour to complete; they may be left to run in the
background while other tests are taking place so long as the system is not
stopped or the time changed. Also, for tests several timetable commands
need to be set up in advance. Details of these can be obtained by reading
the tests before taking any actions.
T08-11100
Purpose:
Action:
SYSTEST.DOC
To start SCOOT detector checking by operator command.
Enter the CHDC command from an operator's terminal.
Issue 11.0 Page 8-123
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
The command is rejected.
T08-11200
Purpose:
Action:
Result:
To start SCOOT detector checking from the timetable and verify the
operation of the OFF adjust mode.
Insert a temporary CHDC event into the timetable.
Using the CHAN command, set the ADJU parameter to ON and then to
OFF to reset the day counter.
Wait for one hour after the CHDC event is started.
Enter a DCOU command to list the results of the checking.
The results of the detector checking are listed on the SCOOT line printer.
T08-11300
Purpose:
Action:
Result:
To start SCOOT detector checking from the timetable and verify the
operation of the ON adjust mode.
Insert a temporary CHDC event into the timetable.
Using the CHAN command, set the ADJU parameter to ON.
Wait for one hour after the CHDC event is started.
Enter a DCOU command to list the results of the checking.
The results of the detector checking are listed on the SCOOT line printer.
T08-11400
Purpose:
Action:
Result:
To start SCOOT detector checking from the timetable and verify the
operation of the OVERRIDE adjust mode.
Insert a temporary CHDC event into the timetable.
Using the CHAN command, set the ADJU parameter to OVERRIDE.
Wait for one hour after the CHDC event is started.
Enter a DCOU command to list the results of the checking.
The results of the detector checking are listed on the SCOOT line printer.
8.7
Other Equipment Faults
8.7.1
Signals Stuck
Reference : MCE 0360C paragraph 4.3.1.7. VAX SRS 2.8.8
T08-11500
Purpose:
Action:
SYSTEST.DOC
To ensure that the system will detect when a controller is stuck on a stage
for longer than the permitted length of time and take the appropriate
action.
a) Ensure that the controller does not have signals stuck inhibit set.
b) Select a plan for the controller, using the PLAN command. Call up a
MONI display for the controller
Issue 11.0 Page 8-124
System Test Specification for a VAX/VMS UTC System
Result:
Action:
Result:
666/YJ/16940/000
b) After a cycle of normal operations set the control bits (using an
instation test set) to cause the controller to stay on the same stage for
more than 180 seconds.
After 180 seconds:
a) a 'Signals stuck' message is output;
b) the controller is isolated;
c) the corresponding wall map lamps flash.
Enter the LSTF command for this controller.
The controller is shown to be isolated and to have a signals stuck fault.
T08-11600
Purpose:
Action:
Result:
To check that the 'Signals stuck' check is not carried out while the
controller is under local control.
a) With the MONI display still active from the previous test, cancel the
control bit override and clear the stuck fault.
b) Check that the controller comes back under computer control.
b) Select plan 0 for the controller to put it in local mode.
b) Use the instation test set to leave a reply bit stuck on the same stage
for more than 180 seconds.
A 'Signals stuck' message is not produced.
T08-11700
Purpose:
Action:
Result:
To ensure that the system will detect when a controller is stuck on an
intergreen for longer than the permitted length of time and take the
appropriate action
a) Call up a MONI display for a controller.
b) Check that the controller is not isolated and that a normal plan is in
progress.
b) Use the instation test set to simulate the reply bits from the controller.
b) After a cycle of normal operations leave the controller reply bits clear
to simulate an intergreen for more than 48 seconds.
b) Use the 'LSTF' command to confirm that the controller now has a
signals stuck on intergreen fault.
After 48 seconds the controller is isolated, a 'signals stuck' message is
output and the corresponding white wall map lamps flash.
T08-11800
Purpose:
Action:
SYSTEST.DOC
To check that the 'Intergreen stuck' check is still carried out when a
controller is under local control.
a) With the MONI display still active from the previous test, clear the
stuck fault and check that the controller comes back under computer
control.
b) Wait for 2 or 3 cycles.
Issue 11.0 Page 8-125
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
b) Cause the controller to become under local control by selecting a local
plan.
b) Leave the controller stage reply stuck on intergreen for more than 48
seconds.
b) Check that an 'Intergreen stuck' message is produced.
b) Use the command 'LSTF' to confirm that the controller is now under
local control.
After 48 seconds of intergreen an 'Intergreen stuck' message is output and
the corresponding white wall map lamp flashes.
T08-11900
Purpose:
Action:
Result:
8.7.2
To show that all signals stuck checks are inhibited when a controller is
isolated by a fault.
Repeat sub-tests T08-11500 to T08-11800 with the controller isolated by
a fault.
Whilst the controller is in this state the signals stuck conditions are not
detected or reported.
G1/G2 reply bits
Note:
The reconnection time is a parameter whose value is set by SPCL in the
configuration file. The usual value for this parameter is 3 seconds. Before
starting this sequence of tests determine which is the correct value for the
System being tested.
Reference : MCE 0360C paragraph 4.3.1.4. VAX SRS 2.8.8
T08-12000
Purpose:
Action:
Result:
To ensure that, when simultaneous G1 and G2 reply bits are returned by
an intersection controller, the controller is isolated and appropriate
messages are produced.
a) Call up a MONI display for a controller operating under plan control.
b) Generate simultaneous G1/G2 reply bits by switching the lamps off or
operating the appropriate switches on a test set.
b) Check that G1/G2 are now being returned.
b) Use the LSTF command to confirm that the controller is now isolated
due to lamps off/manual control.
a) The G1/G2 bits are returned for 3 seconds (or other reconnection time)
and then a 'G1/G2 both set in reply' message is output.
b) The controller is isolated.
c) No control bits are being sent out.
d) The corresponding white wall map lamp flashes.
T08-12100
Purpose:
SYSTEST.DOC
To ensure that, when the simultaneous G1 and G2 reply bits are no longer
returned, the controller is reconnected and appropriate messages are
produced.
Issue 11.0 Page 8-126
System Test Specification for a VAX/VMS UTC System
Action:
Result:
666/YJ/16940/000
With the MONI display still active from the previous test and the G1 and
G2 reply bits being returned, switch the lamps back on or restore the
appropriate switches on the test set.
'G1/G2 disappeared' message appears once the G1 and G2 bits have
disappeared for 3 (or other value) seconds, the controller is reconnected
and control bits are again sent to the controller. The corresponding wall
map lamp is extinguished.
T08-12200
Purpose:
Action:
Result:
To prove that simultaneous G1/G2 bits are detected when a controller is
operating under local control.
Repeat sub-tests T08-12000 and T08-12100 for a controller operating in
local mode.
The results are as above.
T08-12300
Purpose:
Action:
Result:
8.8
To prove that simultaneous G1/G2 bits are detected when a controller is
isolated by fault.
Repeat sub-tests T08-12000 and T08-12100 for a controller isolated by
fault.
The new fault is reported.
Operator Control of Special Facilities
Reference : VAX SRS 2.8.1
T08-12400
Purpose:
Action:
Result:
To show invalid command lines are rejected for CSFY, XCSF, SFNO and
XSFN commands.
Enter the following command lines:
CSFY
CSFY Faaaaa
where aaaaa is an invalid SCN
XCSF
XCSF Faaaaa
where aaaaa is an invalid SCN
SFNO
SFNO Faaaaa
where aaaaa is an invalid SCN
XSFN
XSFN Faaaaa
where aaaaa is an invalid SCN
The commands are rejected with the appropriate error message.
T08-12500
Purpose:
Action:
SYSTEST.DOC
To show that a special facility bit may be set by operator command.
Monitor a valid special facility bit and enter the command:
CSFY
Faaaaa where aaaaa is a valid SCN.
Issue 11.0 Page 8-127
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
The special facility bit is seen to be set.
T08-12600
Purpose:
Action:
Result:
To show that a special facility bit may be cancelled by operator command.
Repeat test T08-12500 and then enter the command :XCSF
Faaaaa where aaaaa is as above.
The special facility bit is seen to be cleared.
T08-12700
Purpose:
Action:
Result:
To show that a special facility bit may be set and cancelled by timetable
event.
Add :
CSFY Faaaaa
followed 5 minutes later by a
XCSF Faaaaa
to the timetable. Set the system time to 3 minutes before the CSFY event
and monitor the special facility bit.
The special facility bit is set at the requested time and then cleared 5
minutes later.
T08-12800
Purpose:
Action:
To show that a special facility bit setting (by timetable event or operator
command) may be inhibited by operator command.
Enter the command :SFNO Faaaaa
where aaaaa is the same as test T08-12500.
Repeat test T08-12700.
Result:
Action:
Result:
The special facility bit is not set.
Repeat test T08-12700.
The special facility bit is not set.
T08-12900
Purpose:
Action:
To show that the setting of a special facility inhibited by operator
command may be re-enabled by operator command.
Enter the command :-
XSFN Faaaaa
where aaaaa is as in T08-12800
Repeat test T08-12500.
Result:
Action:
Result:
The special facility bit is set and cleared as requested.
Repeat test T08-12700.
The special facility bit is set and cleared as requested.
8.9
Tidal Flow Scheme Control
8.9.1
UTC System Taking Control of Tidal Flow Scheme (TFS)
SYSTEST.DOC
Issue 11.0 Page 8-128
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
Reference : VAX SRS
T08-13000
Purpose:
Action:
Result:
To prove that the UTC System takes control of the TFS when setting
flow to inbound.
Monitor TFS OTU using MONI screen
Use XTID Lxxxxx command to place TFS in local control
Check that with TFS in local control no bits are replied to the UTC
System
Set TFS to Inbound with command TIDL Lxxxxx IN
Check that CL and S2 bits are sent and that CC and C2 bits are replied.
Check the status of the TFS using the TIDL Lxxxxx command.
The System should take control of the TFS and set it to inbound.
T08-13100
Purpose:
Action:
Result:
To prove that the UTC System takes control of the TFS when setting
flow to outbound.
Monitor TFS OTU using MONI screen
Use XTID Lxxxxx command to place TFS in local control
Check that with TFS in local control no bits are replied to the UTC
System
Set TFS to Outbound with command TIDL Lxxxxx OUT
Check that CL and S3 bits are sent and that CC and C3 bits are replied.
Check the status of the TFS using the TIDL Lxxxxx command.
The System should take control of the TFS and set it to outbound.
T08-13200
Purpose:
Action:
Result:
8.9.2
To prove that the UTC System takes control of the TFS when setting
double cross.
Monitor TFS OTU using MONI screen
Use XTID Lxxxxx command to place TFS in local control
Check that with TFS in local control no bits are replied to the UTC
System
Set TFS to double cross with command TIDL Lxxxxx XX.
Check that CL and S1 bits are sent and that CC and C1 bits are replied.
Check the status of the TFS using the TIDL Lxxxxx command.
The System should take control of the TFS and set it to XX.
UTC System Control of TFS Changes of Aspect
SYSTEST.DOC
Issue 11.0 Page 8-129
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T08-13300
Purpose:
Action:
Result:
To prove that the appropriate UTC System command causes the TFS
Aspect to change from Inbound to XX.
Monitor TFS OTU using the MONI screen
Ensure that TFS is receiving and replying Inbound (bits S2/C2).
Issue command TIDL Lxxxxx OUT
Watch for S3 bit to be sent and the C2 reply bit to disappear.
After 60 seconds (during which time the move over arrow would be
shown on street) the C1 reply bit (=XX) is seen with the C3 bit appearing
after a further 180 seconds.
Use TIDL Lxxxxx command to check that System now believes TFS to
be set to XX
The TFS should change from Inbound to XX with no fault messages
occurring.
T08-13400
Purpose:
Action:
Result:
To prove that the appropriate UTC System command causes the TFS
Aspect to change from Outbound to XX.
Monitor TFS OTU using the MONI screen
Ensure that TFS is receiving and replying Outbound (bits S3/C3).
Issue command TIDL Lxxxxx XX
Watch for S1 bit to be sent and the C3 reply bit to disappear.
After 60 seconds (during which time the move over arrow would be
shown on street) the C1 reply bit (=XX) should be seen.
Use TIDL Lxxxxx command to check that System now believes TFS to
be set to XX
The TFS should change from Outbound to XX with no fault messages
occurring.
T08-13500
Purpose:
Action:
Result:
SYSTEST.DOC
To prove that the appropriate UTC System command causes the TFS
Aspect to change from XX to Outbound.
Monitor TFS OTU using the MONI screen
Ensure that TFS is receiving and replying XX (bits S1/C1).
Issue command TIDL Lxxxxx OUT
Watch for S3 bit to be sent and the C1 reply bit to disappear.
Check that the C3 reply bit (=Outbound) appears within 3 seconds.
Use TIDL Lxxxxx command to check that System now believes TFS to
be set to Outbound.
The TFS should change from XX to outbound with no fault messages
occurring.
Issue 11.0 Page 8-130
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T08-13600
Purpose:
Action:
Result:
To prove that the appropriate UTC System command causes the TFS
Aspect to change from XX to Inbound.
Monitor TFS OTU using MONI screen
Ensure that TFS is receiving and replying XX (bits S1/C1).
Issue command TIDL Lxxxxx IN
Watch for S2 bit to be sent and C1 reply bit to disappear.
Check that the C2 reply bit (=Inbound) appears within 3 seconds.
Use TIDL Lxxxxx command to check that System now believes TFS to
be set to Inbound.
The TFS should change from XX to outbound with no fault messages
occurring.
T08-13700
Purpose:
Action:
Result:
To prove that the appropriate UTC System command causes the TFS
Aspect to change from Inbound to Outbound.
Monitor TFS OTU using MONI screen
Ensure that TFS is receiving and replying Inbound (bits S2/C2).
Issue command TIDL Lxxxxx OUT
Use MONI to watch for the S3 bit to be sent and the C2 bit to disappear.
Watch for the C1 reply bit (=XX) to to appear after 60 seconds(during
which time the move over arrow is shown on the street).
After a further 180 seconds watch for the C3 reply bit to appear.
Use TIDL Lxxxxx command to check that System now believes TFS to
be set to Outbound.
The TFS should change from inbound to outbound with no fault messages
occurring.
T08-13800
Purpose:
Action:
Result:
SYSTEST.DOC
To prove that the appropriate UTC System command causes the TFS
Aspect to change from Outbound to Inbound.
Monitor TFS OTU using MONI screen
Ensure that TFS is receiving and replying Outbound (bits S3/C3).
Issue command TIDL Lxxxxx IN
Use MONI to watch for the S2 bit to be sent and the C3 bit to disappear.
Watch for the C1 reply bit (=XX) to to appear after 60 seconds(during
which time the move over arrow is shown on the street).
After a further 180 seconds watch for the C2 reply bit to appear.
Use TIDL Lxxxxx command to check that System now believes TFS to
be set to Inbound.
The TFS should change from outbound to inbound with no fault messages
occurring.
Issue 11.0 Page 8-131
System Test Specification for a VAX/VMS UTC System
8.9.3
666/YJ/16940/000
TIDL Command Issued Too Soon After Previous Command
Note:
Once a TIDL command has been issued and received by the local
controller the controller will complete its move to the demanded aspect
regardless of any countermanding commands being issued by the UTC
System. Furthermore a new aspect has a minimum duration.
T08-13900
Purpose:
Action:
Result:
To prove a TIDL command which is issued too soon after a command to
change from outbound to inbound is rejected.
Ensure that TFS is receiving and replying Outbound (bits S3/C3) and has
been doing so for at least its minimum aspect time.
Issue command TIDL Lxxxxx IN
At various times during the next 8 minutes issue the following commands
:
TIDL Lxxxxx OUT
TIDL Lxxxxx XX
XTID Lxxxxx
Commands issued before an aspect change has been completed and the
final aspect run for its minimum time are rejected with suitable error
messages.
T08-14000
Purpose:
Action:
Result:
To prove a TIDL command which is issued too soon after a command to
change from inbound to outbound is rejected.
Ensure that TFS is receiving and replying Inbound (bits S2/C2).
Issue command TIDL Lxxxxx OUT
At various times during the next 8 minutes issue the following commands,
each of which should be rejected with a suitable error message:
TIDL Lxxxxx IN
TIDL Lxxxxx XX
XTID Lxxxxx
Commands issued before an aspect change has been completed and the
final aspect run for its minimum time are rejected with suitable error
messages.
T08-14100
Purpose:
Action:
SYSTEST.DOC
To prove that a TIDL command which is issued too soon after a
command to change from inbound to XX is rejected.
Ensure that TFS is receiving and replying Inbound (bits S2/C2).
Issue command TIDL Lxxxxx XX
At various times during the next 4 minutes issue the following commands,
each of which should be rejected with a suitable error message:
TIDL Lxxxxx OUT
TIDL Lxxxxx IN
Issue 11.0 Page 8-132
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
XTID Lxxxxx
Commands issued before an aspect change has been completed and the
final aspect run for its minimum time are rejected with suitable error
messages.
T08-14200
Purpose:
Action:
Result:
To prove a TIDL command which is issued too soon after a command to
change from outbound to XX is rejected.
Ensure that TFS is receiving and replying Outbound (bits S3/C3).
Issue
Commands issued before an aspect change has been completed and the
final aspect run for its minimum time are rejected with suitable error
messages.
T08-14300
Purpose:
Action:
Result:
To prove a TIDL command which is issued too soon after a command to
change from XX to outbound is rejected.
Ensure that TFS is receiving and replying XX (bits S1/C1).
Issue command TIDL Lxxxxx OUT
At various times during the next 4 minutes issue the following commands,
each of which should be rejected with a suitable error message:
TIDL Lxxxxx IN
TIDL Lxxxxx XX
XTID Lxxxxx
Commands issued before an aspect change has been completed and the
final aspect run for its minimum time are rejected with suitable error
messages.
T08-14400
Purpose:
Action:
Result:
8.9.4
To prove a TIDL command which is issued too soon after a command to
change from XX to inbound is rejected.
Ensure that TFS is receiving and replying XX (bits S1/C1).
Issue command TIDL Lxxxxx IN
At various times during the next 4 minutes issue the following commands,
each of which should be rejected with a suitable error message:
TIDL Lxxxxx OUT
TIDL Lxxxxx XX
XTID Lxxxxx
Commands issued before an aspect change has been completed and the
final aspect run for its minimum time are rejected with suitable error
messages.
TFS Urgent Fault Reporting
SYSTEST.DOC
Issue 11.0 Page 8-133
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T08-14500
Purpose:
Action:
Result:
To prove that when the TFS Urgent Fault bit it set an appropriate
message is output by the UTC System and that the equipment is isolated.
Monitor TFS OTU using OVRB screen
With TFS under UTC System control use OVRB to set the UF bit.
The System should isolate the TFS controller and output a suitable error
message.
T08-14600
Purpose:
Action:
Result:
8.9.5
To prove that when the TFS Urgent Fault bit is cleared an appropriate
message is output by the UTC System.
Monitor TFS OTU using OVRB screen
Use OVRB to Set the UF Bit.
Wait for the output of the resultant fault messages.
Use OVRB to clear the UF bit.
Issue the command XFLT Lxxxxx to indicate clearance of the fault and
allow the System to start sending control bits to the TFS once again.
The System should output a suitable message to indicate clearance of the
UF bit.
TFS Power Failure Simulation
T08-14700
Purpose:
Action:
Result:
To prove that when all 3 sign aspect rely bits are sent the UTC System
reports a TFS power failure and isolates the TFS controller.
With TFS under UTC System control use OVRB to set C1, C2 and C3
bits for more than 3 seconds to simulate a power failure.
The UTC System should isolate the TFS controller and output a suitable
error message.
T08-14800
Purpose:
Action:
Result:
8.9.6
To prove that when all 3 sign aspect reply bits (C1, C2 and C3) are not
set to 1, after a power failure, the UTC System outputs a message which
indicates that power has been restored to the TFS controller.
With TFS under UTC System control use OVRB to set C1, C2 and C3
bits for more than 3 seconds to simulate a power failure.
Use OVRB to Clear all but one of the TFS controller bits C1, C2 or C3.
The UTC System should report the restoration of the power supply to the
TFS controller with a suitable message.
Unexpected TFS Aspect Reply Confirmation
SYSTEST.DOC
Issue 11.0 Page 8-134
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T08-14900
Purpose:
Action:
Result:
8.9.7
To prove that when aspect reply bits other than the correct one are replied
the TFS controller is isolated and the UTC System outputs a suitable
error message.
Monitor TFS OTU using OVRB screen
Issue command TIDL Lxxxxx OUT
When the System sends the Outbound (S3) bit and use the OVRB facility
to reply C3.
Use OVRB to reply C1 (Inbound) for more than 3 seconds.
The test should be repeated for combinations of:
Sending Outbound reply XX
Sending Inbound reply OutBound
Sending XX reply Inbound
Sending XX reply Outbound
Sending Inbound reply XX
In each case the System should isolate the TFS controller and give a
suitable error message.
TFS Illegal Aspect Change
T08-15000
Purpose:
To prove that a change of TFS aspect directly from Outbound to Inbound
causes the TFS controller to be isolated and the UTC System to output a
suitable fault message.
Action:
Check that the TFS is running Outbound.
Issue the command TIDL Lxxxxx IN.
After 60 seconds use OVRB to reply C2 to simulate the TFS changing
directly from Outbound to Inbound without going through the XX stage.
The System should isolate the TFS and output a suitable error message.
Result:
T08-15100
Purpose:
Action:
Result:
8.9.8
To prove that a change of TFS aspect directly from Inbound to Outbound
causes the TFS controller to be isolated and the UTC System to output a
suitable fault message.
Check that the TFS is running Inbound.
Issue the command TIDL Lxxxxx OUT.
After 60 seconds use OVRB to reply C3 to indicate that the TFS has
changed directly from Inbound to Outbound without going through the
XX stage.
The System should isolate the TFS and output a suitable error message.
TFS Aspect Reply Bit Disappearing Whilst Aspect is being Forced
SYSTEST.DOC
Issue 11.0 Page 8-135
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T08-15200
Purpose:
Action:
Result:
To prove that if the Outbound aspect reply bit disappears whilst
Outbound is being forced the TFS controller is isolated and the UTC
System outputs a suitable fault message.
Monitor TFS OTU using OVRB screen
Ensure that
4 minutes use OVRB to remove C3.
The System should isolate the TFS and issue a suitable error message.
T08-15300
Purpose:
Action:
Result:
To prove that if the Inbound aspect reply bit disappears whilst Inbound is
being forced the TFS controller is isolated and the UTC System outputs a
suitable fault message.
Monitor TFS OTU using OVRB screen
Ensure that the TFS is running Inbound.
After more than 4 minutes use OVRB to remove C2.
The System should isolate the TFS and issue a suitable error message.
T08-15400
Purpose:
Action:
Result:
To prove that if the XX aspect reply bit disappears whilst XX is being
forced the TFS controller is isolated and the UTC System outputs a
suitable fault message.
Monitor TFS OTU using OVRB screen
Ensure that the TFS is running XX.
After more than 4 minutes use OVRB to remove C1.
The System should isolate the TFS and issue a suitable error message.
Running On of TFS Aspect Reply Bit
T08-15500
Purpose:
Action:
Result:
To prove that the UTC System command detects the running on of an
outbound aspect beyond its maximum time when it should have changed.
Monitor TFS OTU using OVRB screen
Ensure that the TFS is running Outbound.
Issue the command TIDL Lxxxxx IN.
Use OVRB to keep the same reply bit pattern
The System should isolate the TFS and issue a suitable error message
after 3 seconds.
T08-15600
Purpose:
Action:
SYSTEST.DOC
To prove that the UTC System command detects the running on of an
inbound aspect beyond its maximum time when it should have changed.
Monitor TFS OTU using OVRB screen
Issue 11.0 Page 8-136
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
Ensure that the TFS is running Inbound.
Issue the command TIDL Lxxxxx OUT.
Use OVRB to keep the same reply bit pattern
The System should isolate the TFS and issue a suitable error message
after 3 seconds.
T08-15700
Purpose:
Action:
Result:
8.9.9
To prove that the UTC System command detects the running on of the
XX aspect beyond its maximum time when it should have changed.
Monitor TFS OTU using OVRB screen
Ensure that the TFS is running XX.
Issue the command TIDL Lxxxxx OUT.
Use OVRB to keep the same reply bit pattern
The System should isolate the TFS and issue a suitable error message
after 3 minutes.
Occurrence of TFS Minor Fault
T08-15800
Purpose:
Action:
Result:
8.9.10
To prove that the UTC System reports the occurrence of a minor fault in
the TFS.
Monitor TFS OTU using OVRB screen
Ensure that the UTC System and the TFS are operating normally, i.e. not
changing aspects and not isolated.
Use OVRB to set the MF bit true.
The UTC System should report occurrence of the minor fault and not
isolate the TFS.
Violation of TFS Inter-Aspect Time
T08-15900
Purpose:
Action:
Result:
SYSTEST.DOC
To prove that the UTC System detects the violation of an inter-aspect
time, with a too-short time, during the change of aspect from outbound to
inbound.
Monitor TFS OTU using OVRB screen
Ensure that the TFS has been running Outbound for more than its
minimum aspect time.
Issue the command TIDL Lxxxxx IN.
After 50 seconds use OVRB to reply C1 to indicate that the TFS has
changed to XX.
The UTC System should issue a suitable error message to indicate interaspect time violation has occurred and isolate the TFS controller.
Issue 11.0 Page 8-137
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T08-16000
Purpose:
Action:
Result:
To prove that the UTC System detects the violation of an inter-aspect
time, with an excessive time, during the change of aspect from outbound
to inbound.
Monitor TFS OTU using OVRB screen
Ensure that the TFS has been running Outbound for more than its
minimum aspect time.
Issue the command TIDL Lxxxxx IN.
Use OVRB to remove the Outbound reply bit (C3) when S2 is received.
After 65 seconds use OVRB to reply C1 to show that TFS has changed to
XX.
The UTC System should issue a suitable error message to indicate interaspect time violation has occurred and isolate the TFS controller.
T08-16100
Purpose:
Action:
Result:
To prove that the UTC System detects the violation of an interaspect
time, with a too-short time, during the change of aspect from inbound to
outbound.
Monitor TFS OTU using OVRB screen
Ensure that the TFS has been running Inbound for more than its minimum
aspect time.
Issue the command TIDL Lxxxxx OUT.
After 50 seconds use OVRB to reply C1 to indicate that the TFS has
changed to XX.
The UTC System should issue a suitable error message to indicate interaspect time violation has occurred and isolate the TFS controller.
T08-16200
Purpose:
Action:
Result:
SYSTEST.DOC
To prove that the UTC System detects the violation of an inter-aspect
time, with an excessive time, during the change of aspect from inbound to
outbound.
Monitor TFS OTU using OVRB screen
Ensure that the TFS has been running Outbound for more than its
minimum aspect time.
Issue the command TIDL Lxxxxx OUT.
Use OVRB to remove the Inbound reply bit (C2) when S3 is received.
After 65 seconds use OVRB to reply C1 to show that TFS has changed to
XX.
The UTC System should issue a suitable error message to indicate interaspect time violation has occurred and isolate the TFS controller.
Issue 11.0 Page 8-138
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
9.
DISPLAY STATUS AND LISTINGS TEST DEFINITIONS
9.1
Mono Displays
9.1.1
Operator Monitoring - MONI and OVRB
References : MCE 0360C paragraph 4.3.4 and VAX SRS section 2.9.1
T09-00100
Purpose:
Action:
Result:
To prove that the system will reject invalid command lines for the MONI
and OVRB commands.
Enter the following command lines (a) #MONI
(not enough parameters)
(a) #MONI J
(incomplete SCN)
(a) #MONI Tbbbbb
(bad equipment type)
(a) #MONI abbbbb
where a is a valid equipment type letter and
bbbbb is an invalid SCN.
(bad SCN number)
(a) #MONI abbbbb ccc
(too many parameters)
(a) #MONI Haaaaa bbb
where aaaaa is an invalid computer SCN
and bbb is a valid in-station address
(invalid computer SCN)
(a) #MONI Haaaaa bbb
where aaaaa is a valid computer SCN and
bbb is an invalid in-station address.
(invalid address)
(a) #OVRB
(not enough parameters)
(a) #OVRB J
(incomplete SCN)
(a) #OVRB Tddddd
(bad SCN letter)
(a) #OVRB addddd
where ddddd is an invalid SCN.
(bad SCN number)
(a) #OVRB addddd eee
(too many parameters)
(a) #OVRB Haaaaa bbb
where aaaaa is an invalid computer SCN
and bbb is a valid in-station address.
(invalid computer SCN)
(a) #OVRB Haaaaa bbb
where aaaaa is a valid computer SCN and
bbb is an invalid in-station address.
(invalid address)
The commands are all rejected with appropriate error messages.
T09-00200
Purpose:
Action:
SYSTEST.DOC
To show that it is possible to monitor, on a VT series terminal, the control
and reply words being sent between the instation and an OTU.
(a) Use the command MONI to call up a display on the VT series of the
control and reply bits for a chosen test OTU.
Issue 11.0 Page 9-1
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
(b) After an interval of approximately 30 seconds enter the key sequence
Control P to produce a hard copy dump.
(b) Cancel the display by entering a traffic prompt and repeat the
command for an OTU which is defined but currently set to invalid.
Result:
The displays and hard copy dumps are produced and include:
(a) The OTU description, SCN and transmission system address.
(a) The mnemonic of each bit on the display and the SCN of the
equipment to which it belongs.
(a) control and 16 reply bits for a single transmission system address.
(a) A new line on the display for every time the control and reply bits
change state.
(a) The display has room for at least 12 lines of data simultaneously
displayed.
The instation test set should be used to verify the contents of the MONI
display. The display contains the time which is continuously updated on
the Terminal.
T09-00300
Purpose:
Action:
Result:
Action:
Result:
To show that a screen dump of a MONI display may be made when a plan
compliance fault occurs.
Start a MONI display for a junction. Enter the key sequence Control F.
Arrange for a plan compliance fault to occur on the monitored junction.
The time is underlined to indicate that the plan compliance capturing
facility is active. When the compliance fault occurs there is a 10 (B)
second pause to allow a few more control and reply words to be output
before the screen is dumped to the system printer.
Repeat this test for a pelican.
A similar result is obtained.
T09-00400
Purpose:
Action:
Result:
To show that it is possible to monitor, on a colour graphics terminal, the
control and reply words being sent between the instation and an OTU.
Repeat T09-00200 using a PC terminal.
As for sub-test T09-00200.
T09-00500
Purpose:
Action:
Result:
To call up a MONI display by reference to individual items of equipment
on an OTU.
Repeat T09-00200 for other equipment types attached to the same OTU,
e.g. SCOOT detector, Diversion sign, Intersection.
As for sub-test T09-00200.
T09-00600
Purpose:
SYSTEST.DOC
To call up a MONI display by reference to an instation address.
Issue 11.0 Page 9-2
System Test Specification for a VAX/VMS UTC System
Action:
Result:
666/YJ/16940/000
Repeat T09-00200 and T09-00300 using the Haaaaa bbb form of
parameters, where aaaaa is a valid computer SCN and bbb is a physical
address on that computer
As for sub-tests T09-00200 and T09-00300.
T09-00700
Purpose:
Action:
Result:
To show that several similar or different MONI displays may run on
different terminals at the same time.
Start MONI displays on all the terminals attached to the system including
at least one duplicate pair.
All the commands are accepted and the displays run successfully.
T09-00800
Purpose:
Action:
Result:
To demonstrate that OVRB displays are available for the same
equipments as the MONI displays.
Repeat sub-tests T09-00200 to T09-00600 inclusive.
As for sub-tests T09-00200 to T09-00600 inclusive. An "override mode"
message is written to the system log when each command is entered. On
terminating the command an "override mode cancelled" message is
written to the system log.
T09-00900
Purpose:
Action:
SYSTEST.DOC
To demonstrate that OVRB is capable of modifying control data.
(a) call up an OVRB display for a configured test OTU.
#OVRB Xaaaa0
(b) using an instation test set verify that the display matches the data
being sent to and received from the OTU.
(b) using the left and right cursor keys move the cursor to select the bits
to be modified in the control word.
(b) use the 0 key to reset bits and the 1 key to set bits.
(b) use the space bar to deselect a bit and move right one bit.
(b) use the delete key to move left one bit and deselect.
(b) use the up key to select a bit and set it to zero.
(b) use the up key to toggle 0/1 a bit already selected.
(b) use the down key to deselect a bit.
(b) use the F1 (PF1 on VT series terminals) key to start a continuous
overwrite.
(b) use the F3 (PF3 on VT series terminals) key to stop the continuous
overwrite.
(b) use the F2 (PF2 on VT series terminals) key to cause a single shot
overwrite for one second.
(b) use the F4 (PF4 on VT series terminals) key to hide bits on
equipment not already selected. Use it again to reveal the bits.
Issue 11.0 Page 9-3
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
Using the in-station test set verify the over-written bits are sent to the
OTU. An "override mode" message is written to the system log when
each command is entered. On terminating the command an "override
mode cancelled" message is written to the system log.
T09-01000
Purpose:
Action:
Result:
To demonstrate that OVRB is capable of modifying reply data.
(a) call up an OVRB display for a configured test OTU.
#OVRB Xaaaa0
(b) using an instation test set verify that the display matches the data
being sent to and received from the OTU.
(b) using the left and right cursor keys move the cursor to select the bits
to be modified in the control word.
(b) use the 0 key to reset bits and the 1 key to set bits.
(b) use the space bar to deselect a bit and move right one bit.
(b) use the delete key to move left one bit and deselect.
(b) use the up key to select a bit and set it to zero.
(b) use the up key to toggle 0/1 a bit already selected.
(b) use the down key to deselect a bit.
(b) use the F1 (PF1 on VT series terminals) key to start a continuous
overwrite.
(b) use the F3 (PF3 on VT series terminals) key to stop the continuous
overwrite.
(b) use the F2 (PF2 on VT series terminals) key to cause a single shot
overwrite for one second.
(b) use the F4 (PF4 on VT series terminals) key to hide bits on
equipment not already selected. Use it again to reveal the bits.
At another terminal, use MONI to display the same address as that being
over-written and verify that the reply bits are being modified as requested.
An "override mode" message is written to the system log when each
command is entered. On terminating the command an "override mode
cancelled" message is written to the system log.
T09-01100
Purpose:
Action:
Result:
To show that no more than one OVRB display may be active on any one
address at any time.
Start an OVRB display for one address. At a different terminal attempt to
start the same OVRB display.
The command is rejected.
T09-01200
Purpose:
Action:
SYSTEST.DOC
To show that more than one OVRB display may be active on different
terminals as long as they are for different addresses.
Start several OVRB displays on different terminals each for a different
address.
Issue 11.0 Page 9-4
System Test Specification for a VAX/VMS UTC System
Result:
Action:
Result:
9.1.2
666/YJ/16940/000
All the displays start successfully. An "override mode" message is written
to the system log when each command is entered.
Verify that all the displays can simultaneously overwrite control and reply
data.
There is no interaction or degradation of performance. On terminating the
command an "override mode cancelled" message is written to the system
log.
Operator Monitoring - Networked Systems
Reference: VAX SRS section 2.10.8 (5)
T09-01300
Purpose:
Action:
Result:
Action:
Result:
To demonstrate that OTU Monitor displays are available on remote
terminals.
(a) At a terminal connected to TCCA enter a MONI command for an
intersection in a sub-area controlled by TCCB.
The command is accepted and the correct display produced. This may be
confirmed by displaying the same data on a terminal connected to TCCB.
(b) Repeat action (a) at a terminal connected to the TMC.
The command is accepted and the correct display produced.
T09-01400
Purpose:
Action:
Result:
To demonstrate that the OTU overwrite facility is available on remote
terminals.
Repeat tests T09-00900 and T09-01000 at a terminal connected to TCCA
for equipment controlled by TCCB.
The OVRB operates as specified previously.
T09-01500
Purpose:
Action:
Result:
9.1.3
To demonstrate that a screen dump to a remote terminal which is not online will not stop the system.
For this test it is necessary to configure a terminal on TCCA with its black
and white printer attached to the TMC. Disconnect the TMC from the
system and start a MONI (or OVRB) display on the terminal connected to
TCCA. Enter CTRL-P to print the contents of the screen.
No printout is produced since the printer is off-line, and there is no
adverse effect on the system i.e. the MONI display continues and there
are no error messages in the log.
The Display Plan Monitor (DIPM) Facility
T09-01600
Purpose:
Action:
To show that invalid command lines are rejected.
Enter the following invalid command lines (a) #DIPM
SYSTEST.DOC
(not enough parameters)
Issue 11.0 Page 9-5
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
(a) #DIPM J
(incomplete SCN)
(a) #DIPM Tbbbbb
(bad SCN letter)
(a) #DIPM abbbbb
where a is a valid equipment type letter and
bbbbb is an invalid SCN. (bad SCN number)
(a) #DIPM abbbbb cc dd
(too many parameters)
(a) #DIPM Jaaaaa bb
where aaaaa is an invalid junction SCN and
bbb is a valid plan number. (invalid junction
number)
(a) #DIPM P
(incomplete SCN)
(a) #DIPM Paaaaa
where aaaaa is an invalid pelican SCN
numeric. (bad SCN number)
The commands are all rejected with suitable messages.
T09-01700
Purpose:
Action:
Result:
To show that the DIPM display is produced correctly.
Enter the DIPM command for a valid junction SCN.
A display is produced which includes:
(a) The junction SCN number.
(a) The transmission system address
(a) The SCOOT node number
(a) The junction name
(a) The day date and time which is continuously updated
(a) The current timetable number and name.
(a) The Control and reply bit allocations and the last seconds data
including the OTU status bit
(a) The current plan number and an entry in brackets dependent on the
way the plan was selected.
(a) The current plan line with the current stage forced highlighted.
(a) The offset into the current cycle against the word 'Counter'.
(a) The stage which is actually running
(a) The words 'New plan' and a prompt for investigating the timings of
other plans.
(a) The cycle times or LCL (Local) for each plan for this controller.
(a) The timetable events due for this controller for the rest of the day
with the event time and the plan to change to.
(a) A record of the previous intergreens and stage durations for at least
the past 12 stage changes. This is driven from the reply bits and
updates in real time.
(a) At least 12 of the faults currently associated with the junction. These
are cut short to fit the display.
SYSTEST.DOC
Issue 11.0 Page 9-6
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
All the static information should be cross checked and the information
that is updated in real time should be checked.
T09-01800
Purpose:
Action:
Result:
Action:
Result:
To show that Stage timing or plan cycle times may be displayed.
Enter 'T'.
The junction stage timing matrix giving minima, maxima, intergreens and
allowed transitions is displayed in place of the plan cycle times.
Enter 'P'.
The display reverts to the plan cycle times.
T09-01900
Purpose:
Action:
Result:
Action:
Result:
To show that the plan line may be in terms of durations or action times
Enter 'D'.
The current plan is displayed in terms of stage durations. The stage letters
become lower case.
Enter 'O'.
The current plan reverts to being displayed in terms of stage change times
and the stage letters are in capitals.
T09-02000
Purpose:
Action:
Result:
To show that other plan timings may be displayed.
Enter a number between 1 and the maximum number of fixed time plans.
The timing of the selected plan are displayed below the current plan.
T09-02100
Purpose:
Action:
Result:
To demonstrate the timetable event display.
With a DIPM display up for a junction or pelican, on timetable plan, note
that up to nine timetable plan changes for the rest of the day are displayed
giving the time due and the plan to change to.
Allow the system time to pass through one of these events.
The plan line is updated to the new plan and the timetable event display
scrolls up with the event that has just occurred disappearing.
T09-02200
Purpose:
Action:
Result:
SYSTEST.DOC
To show that fault messages are displayed for the junction.
Cause a plan compliance fault to occur on the junction being monitored
by using an OVRB at another terminal to return an incorrect stage.
The incorrect bit is seen in the reply bits. The Monitor shows the duration
of the incorrect stage. Messages appear under 'Fault Messages' indicating
a plan compliance fault and that the junction has been isolated. The
current plan message indicates that the junction is isolated by fault.
Issue 11.0 Page 9-7
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T09-02300
Purpose:
Action:
Result:
To check what happens on the DIPM display when a plan change occurs
by operator command.
Clear the faults and make sure the junction is on the current timetable
plan. At another terminal impose an operator plan on the subarea of the
junction being monitored.
The current plan is updated to the new plan , with 'Operator' in brackets
after the plan number.
T09-02400
Purpose:
Action:
Result:
To check what happens on the DIPM display when a plan change occurs
by timetable event.
Check that the junction is on the currently selected timetable plan.
Advance time to the just before the next timetable event. Wait for the
timetable event to occur.
At the time of the event the plan changes to the required plan and the list
of timetable events is updated so that the next due event is at the top.
T09-02500
Purpose:
Action:
Result:
To check what happens on the DIPM display when a plan change occurs
by VARY.
Check that the a junction to be displayed is on the currently selected
timetable plan. Do a DIPM for the junction.
Enter a VARY command suitable for the plan in use at another terminal.
The Varied plan is implemented in the intergreen before the first stage in
the plan. The DIPM plan display changes to the varied plan and the text
notes that it is on 'plan 37 (varied)'.
T09-02600
Purpose:
Action:
Result:
To check what happens on the DIPM display when a plan change occurs
by OFST.
Check that the a junction to be displayed is on the currently selected
timetable plan. Enter a DIPM for the junction.
Enter an OFST command suitable for the plan in use at another terminal.
The Offset plan is implemented in the intergreen before the longest stage
in the plan. The DIPM plan display changes to the new plan and the text
notes that it is on 'plan 37 (varied)'.
T09-02700
Purpose:
Action:
Result:
SYSTEST.DOC
To show that the DIPM display is available on all terminal types except
hard copy terminals.
Attempt to repeat tests T09-01600 to T09-02600 on all available terminal
types. ie VT420, Colour PC, Roving Terminal, Hard copy terminal.
All the DIPM facilities are available on all terminals except hard copy
terminals.
Issue 11.0 Page 9-8
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T09-02800
Purpose:
Action:
Result:
To show that several similar or different DIPM displays may be run on
different terminals at the same time.
Start DIPM displays on all the available suitable terminals with two
displays being of the same junction.
All the displays run without interaction or degradation of performance.
The displays of the same junction are identical and update at the same
time.
T09-02900
Purpose:
Action:
Result:
To show that a DIPM display may be terminated by entering the traffic
prompts.
Enter both '#' and '-' to terminate DIPM displays.
The displays are terminated.
T09-03000
Purpose:
Action:
Result:
9.1.4
To show that a DIPM display may be used for pelicans.
Repeat tests T09-01600 to T09-02600 for a pelican SCN.
The same results are obtained as for junctions.
The Display Plan Monitor (DIPM) Facility - Networked Systems
Reference: VAX SRS section 2.10.8 (5)
T09-03100
Purpose:
Action:
Result:
Action:
Result:
9.1.5
To demonstrate that Plan Monitor displays are available on remote
terminals.
(a) At a terminal connected to TCCA enter a DIPM command for an
intersection in a sub-area controlled by TCCB.
The command is accepted and the correct display produced. This may be
confirmed by displaying the same data a terminal connected to TCCB
(b) Repeat action (a) at a terminal connected to the TMC.
The command is accepted and the correct display produced.
Live Update Display of Detector Counts (FLOW)
T09-03200
Purpose:
Action:
SYSTEST.DOC
To demonstrate the FLOW command.
Attempt the following commands:
(a) #FLOW
(not enough parameters)
(a) #FLOW D
(incomplete SCN)
(a) #FLOW Jaaaaa
where Jaaaaa is a valid junction SCN
(bad SCN)
Issue 11.0 Page 9-9
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
(a) #FLOW Dbbbbb
where bbbbb is an invalid SCN (bad
SCN)
(a) #FLOW D00000
(wildcarding not allowed)
(a) #FLOW Daaaaa D
where Daaaaa is a valid detector SCN
(incomplete SCN)
(a) #FLOW Daaaaa Dbbbbb
where Dbbbbb is an invalid SCN (bad
SCN)
(a) #FLOW Daaaaa Dbbbbb
Dccccc Deeeee Dfffff
Where the parameters are all valid
detector SCNs (too many parameters)
T09-03300
Purpose:
Action:
To demonstrate the FLOW command for producing a continuously
updated display of detector counts.
Enter a FLOW command for
(a) one
(a) two
(a) three
(a) four
different detectors.
Data is displayed for respectively one, two, three and four detectors.
Initially the 5 minute count data collected during the previous 60 minutes
is displayed. the display is updated every time more data is available. The
display contains the time which is continuously updated.
Enter a traffic prompt.
Result:
Action:
Result:
The display is terminated.
Enter a FLOW command for a faulty detector.
A message indicates no data is available.
Action:
Result:
T09-03400
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
SYSTEST.DOC
To show that the count display indicates if data was not available.
Start a Flow display for a single detector. Simulate valid data to the
detector for a count period.
At the end of the period the count is displayed.
Simulate valid data for part of a period then set time forward to just
within the end of the period so that data is not recorded for some part of
the period.
At the end of the period the partial count is displayed with a 'c' against it
to indicated that data was unavailable for part of the period.
Set the OTU with the count detector on it Invalid for an entire period.
A count of zero will be output to with a 'c' against it to indicate that data
was unavailable for the entire period.
Issue 11.0 Page 9-10
System Test Specification for a VAX/VMS UTC System
Action:
Result:
Action:
Result:
9.1.6
666/YJ/16940/000
Set the OTU valid but simulate the DF bit on the counter for part of a
period.
At the end of the period the partial count is displayed with an 's' against it
to indicated that data was unavailable for part of the period due to a fault
condition.
Set the DF bit for an entire count period.
A count of zero will be output with an 's' against it to indicate that data
was unavailable for the entire period due to a fault condition.
Link Validation Display
Reference : VAX SRS section 2.9.1
T09-03500
Purpose:
Action:
Result:
To demonstrate the LVAL command.
Attempt the following commands:
(a) #LVAL
(not enough parameters)
(a) #LVAL N
(incomplete SCN)
(a) #LVAL Jbbbbb
(bad SCN)
(a) #LVAL Nbbbbb
where bbbbb is a valid SCN. (Wrong SCN
type)
(a) #LVAL NbbbbbB cc
B is a letter. (too many parameters)
(a) #LVAL NaaaaaB
where aaaaa is an invalid node SCN and B is
a valid link. (Bad SCN)
(a) #LVAL NaaaaaB
where aaaaa is an valid node SCN and B is
an invalid link. (Bad SCN)
(a) #LVAL Naaaaa*
where aaaaa is an valid node. (Wildcarding
not allowed)
(a) #LVAL N**
(Wildcarding not allowed)
All these commands are rejected with suitable messages.
T09-03600
Purpose:
Action:
Result:
SYSTEST.DOC
To Demonstrate MONITOR mode in the LVAL display.
Enter an LVAL command for a valid link SCN.
After a pause a display is produced with the following features:
On the first line
(a) Link SCN
(a) Region SCN
(a) SCOOT implementation flags (IMPL and RPLY).
(a) The SOFT status of the link
(a) The model feedback inhibit flag (MFBI)
Issue 11.0 Page 9-11
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
(a) Whether the link is being validated or monitored
(a) The date and time which is continuously updated
On the second line:
(a) The region cycle time
(a) The saturation occupancy (STOC)
(a) The journey time (JNYT)
(a) The Queue Clear Time Max Queue (QCMQ)
(a) The start lag (SLAG)
(a) The end lag (ELAG)
(a) The raw data values for up to three detectors for the link, updated
once a second.
On the third line:
(a) Any error messages which may occur
(a) The current state of the link, show as:
'G' (inverse video): lights green,
'R' : lights red,
'E' : lights green with exit blocked.
(a) The number of vehicles in the queue.
(a) A representation of the queue waiting at the stop line, scaled
according to MAXQ*STOC. The area from the stop line to the front
of the queue contains spaces; the queue is displayed as solid blocks.
The rest of the display:
(a) a counter which increments whenever a new line of data is displayed
and resets if a SCOOT parameter changes.
(a) The length of the queue in vehicles at start of green, from SCOOT
(updated every cycle)
(a) The queue clear time from SCOOT (updated every cycle)
(a) A field for the length of queue in vehicles input from the street.
(a) A field for the queue clear time input from the street
(a) An estimated value of the STOC calculated from the records which
are marked VALID.
(a) A VALID field used to indicate which of the data records are valid
for the purpose of estimating STOC values. This defaults to 'N'.
(a) A comment field of up to thirty characters. If a SCOOT parameter
has been changed, the parameter and its new value automatically
appears here. If the SCOOT parameter was changed externally , an
asterisk ('*') follows.
The SCOOT parameter fields will update in real time when the parameter
changes.
The display will be able to display up to the last 9 values of queue length
and queue clearance time from the SCOOT model.
SYSTEST.DOC
Issue 11.0 Page 9-12
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T09-03700
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
To show that the LVAL display updates correctly in monitor mode.
Using another terminal verify that the SCOOT parameters on the LVAL
display are correct.
Using the MONI display for the same junction verify that the detector
replies on the LVAL display are correct.
Start the M14 message for the same link as the LVAL display. Verify that
the queue display is correct.
Verify that the queue length and clear time from SCOOT are correct and
appear at the correct times by comparing the LVAL display with the M10
and M11 displays for the same link.
All the entries on the LVAL display are independently verified.
Change the implementation status of the link being monitored by LVAL
using CHAN and SCOO/XSCO at another terminal.
Also use CHAN to change STOC, JNYT, QCMQ, SLAG and ELAG.
The relevant fields on the LVAL display change to the new values.
Write protect the disc using the front panel switch on the computer.
A message appears on line 3 of the LVAL display indicating that the disc
is unavailable.
Release the switch.
The message disappears.
T09-03800
Purpose:
Action:
Result:
Action:
Result:
To demonstrate the LVAL display in validation mode.
Enter CTRL-V to put the display into validation mode. Use the cursor to
move about the fields which may be edited. These are STOC, JNYT,
QCMQ, SLAG, ELAG, Street queue length, street queue clear time, the
VALID field and the comment field.
The cursor moves to the allowed fields and wraps round the screen up
and down and side to side.
Move the cursor to each of the SCOOT parameters in turn on the second
line and refer to the Operators Handbook ref. to determine the ranges for
each value and test them. On another terminal use the VALU command to
confirm that the changes have occurred in the SCOOT database.
The parameters can be changed and correct values are accepted. After
each change the record counter is reset and the queue clear times from
any records on the display are not included in future calculations of the
estimated STOC. When the next line of output occurs in the lower half of
the display then a comment is automatically included in the comment field
indicating which parameter has changed and its new value.
T09-03900
Purpose:
Action:
SYSTEST.DOC
To show that the LVAL display may be used to validate a link.
With the display in validate mode wait until just after a new line of data
has been output. Move the cursor to the Street Qlen column. Enter a
Issue 11.0 Page 9-13
System Test Specification for a VAX/VMS UTC System
Result:
Action:
Result:
value the same as the one produced by SCOOT. Enter a queue clear time
in the same manner. Move to the 'Valid' field and change the value to 'Y'.
An estimated STOC will be produced. It should have the same value as
the STOC on line two.
Repeat this test using Queue clear times for the street which are above or
below those from SCOOT.
Estimated STOCs are produced. It should be verified that this is
calculated from the formula:
sum of model queue clear times *
sum of street queue clear times
Action:
Result:
Action:
Result:
666/YJ/16940/000
Saturation Occupancy
(STOC) from the SCOOT database
Change the STOC on line two of the display. Continue entering queue
clear times.
The change of STOC appears in the comment line. The record counter is
reset to 1. It should be ascertained that the estimated STOC calculation
only includes Queue Clear values since the last change of STOC (or any
other SCOOT parameter value).
Enter some queue clear times with VALID set to 'N'. Include comments in
the comment field with lengths up to the field length.
These times are are not included in the estimated STOC calculation. The
comments are entered as typed.
T09-04000
Purpose:
Action:
Result:
Action:
Result:
To edit validation data.
Use the cursor keys to move back to a previous Qlen value and change it.
The subsequent estimated STOCS are recalculated.
Move to a comment field and edit it.
the field can be edited.
T09-04100
Purpose:
Action:
Result:
Action:
Result:
To refresh the screen.
Enter CTRL-R
The screen is refreshed.
Enter CTRL-W
The screen is refreshed.
T09-04200
Purpose:
Action:
Result:
Action:
Result:
SYSTEST.DOC
Termination of LVAL due to a fault.
Cause a fault on the SCOOT link.
The program terminates and a message is produced.
Restart LVAL and put it in validation mode. Cause a programmed System
shut down using the UPDA command.
The program terminates and notifies the operator.
Issue 11.0 Page 9-14
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T09-04300
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
Operator termination.
Start LVAL and use CTRL-V to change to validation mode. Attempt to
terminate the program by entering:
(a) CTRL-Z
(a) '#'
(a) '-'
The program is not terminated.
Enter CTRL-V to return the program to monitor mode.
The program ends. Any SCOOT parameters which have been changed by
the operator and have become new database values will be listed on the
screen after program termination. Check that changes to SCOOT
parameters are also recorded in the System log.
Repeat this test but terminate the program using the '#' or '-' prompts.
The same result is achieved.
T09-04400
Purpose:
Action:
Result:
To show that the LVAL display is available on all terminal types except
hard copy terminals.
Attempt to repeat tests T09-03500 to T09-04300 on all available terminal
types. ie VT420, Colour PC, Roving Terminal, Hard copy terminal.
LVAL is available on all terminals except hard copy terminals.
T09-04500
Purpose:
Action:
Result:
Action:
Result:
9.1.7
To show that several LVAL displays may be used as long as they are on
different terminals and for different links.
Start an LVAL display on one terminal. Try to start an LVAL display on
another terminal for the same link.
The second command is rejected.
Repeat tests T09-03500 to T09-04300 for two displays running on
different terminals and different links.
The same results are obtained for each link and there is no interaction of
the displays.
Link Validation Display - Networked Systems
T09-04600
Purpose:
Action:
Result:
9.1.8
To demonstrate that remote LVAL displays are possible.
At a terminal connected to TCCB, start an LVAL display for a link
controlled by TCCA. Repeat the above sub-tests.
The feature operates in the same way as a local LVAL display.
Node Fine Tuning Display
SYSTEST.DOC
Issue 11.0 Page 9-15
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
Reference : VAX SRS section 2.9.1
T09-04700
Purpose:
Action:
Result:
To show that invalid commands are rejected.
Enter #NFTD ScSCN where ScSCN is an invalid SCOOT node SCN
Enter #NFTD ScSCN where ScSCN is not a SCOOT node SCN
Both commands are rejected with appropriate error messages.
T09-04800
Purpose:
Action:
Result:
Action:
Result:
To show that the Node Fine Tuning Display produces correct information
for fine tuning a node.
Enter the command :
#NFTD ScSCN
where ScSCN is a valid SCOOT Node SCN which
is under SCOOT control with all links in use.
The top half of the screen shows the date and time which is continuously
updated, the SCOOT parameters Node name, region name,
implementation status, reply status, region cycle time, node cycle time,
cycle time force state, trend flag, fast down flag as live update fields and
the stage times for the node from the M17 message with the current stage
highlighted in reverse video. The bottom half of the screen shows data for
upstream links of the specified node:
(a) The link letter is displayed followed by '+' if currently green or '-' if
green and exit blocked.
(a) The green time for the last completed stage.
(a) The length of queue at the stop line (in vehicles)
(a) The queue at start of green (in vehicles)
(a) The queue clear time
(a) The percentage saturation
(a) The number of vehicles forming a standing queue
(a) The offset of a link in relation to its upstream node.
(a) The STOC value from the database for the link.
Refer to the relevant SCOOT messages (M05, M08, M10, M11, M14,
M17) and relevant database values using another terminal and compare
them to the values displayed on the NFTD screen.
The values agree and change at the correct times. The '+' or '-' indicates
correctly which links are currently green.
T09-04900
Purpose:
Action:
Result:
Action:
Result:
SYSTEST.DOC
To test further behaviour of the Node fine tuning display.
Set one of the detectors on the link faulty.
The link letter changes to inverse video.
Clear the fault on the link.
The link letter changes back to normal video.
Issue 11.0 Page 9-16
System Test Specification for a VAX/VMS UTC System
Action:
Result:
666/YJ/16940/000
Arrange for the down stream link of a link to be exit blocked by altering
the simulation on the main down stream detector.
When the link is green a '-' appears rather than a '+'.
T09-05000
Purpose:
Action:
Result:
Action:
Result:
To terminate the display
Bring an NFTD display up. Enter The traffic prompt '#'
The display terminates.
Repeat the test using '-' and CTRL-Z to terminate the display.
The display terminates.
T09-05100
Purpose:
Action:
Result:
To show that the NFTD display is available on all terminal types except
hard copy terminals.
Attempt to repeat tests T09-03500 to T09-04300 on all available terminal
types. ie VT420, Colour PC, Roving Terminal, Hard copy terminal.
The display is available on all terminals except hard copy terminals.
T09-05200
Purpose:
Action:
Result:
9.1.9
To show that similar or different NFTD displays may run on different
terminals at the same time.
On all suitable terminals start NFTD displays at least two, but not all, of
which should be for the same node.
All displays run successfully and there is no interaction or degradation in
performance. Displays for the same node are identical an update at the
same time.
Node Fine Tuning Display - Networked Systems
T09-05300
Purpose:
Action:
Result:
9.1.10
To show that remote NFTD displays are available.
At a terminal connected to TCCA enter an NFTD command specifying a
node controlled by TCCB.
The display is produced and operates exactly as for a local node.
Region Fine Tuning Display
Reference : VAX SRS section 2.9.1
T09-05400
Purpose:
Action:
SYSTEST.DOC
To show that the Region Fine Tuning Display produces correct
information for fine tuning a region.
Enter the command :
#RFTD ScSCN
where ScSCN is a valid SCOOT region SCN which
has SCOOT control implemented.
Issue 11.0 Page 9-17
System Test Specification for a VAX/VMS UTC System
Result:
Action:
Result:
666/YJ/16940/000
The top half of the screen shows the date and time which is continuously
updated, the SCOOT parameters region name, max cycle time, min cycle
time, cycle time optimiser status, trend flag status, fast down flag status
and the last 10 cycle times for the region. The CYO PERIOD (time
between cycle optimisations) and TIMER (time since last cycle
optimisation) for the region are displayed indicating how long it will be
before the next update to the bottom half of the display. The SCOOT
parameters are update in real time if they change.
• The bottom half of the screen shows data for nodes in the region,
which is updated every Cycle optimiser cycle. Up to 4 nodes per line
can be displayed. The data shown for each node is:
• The node SCN,followed by (if applicable for the node):
FS - forced single cycling.
D - double cycling.
FD - forced double cycling.
• The new and old values of MPCY (minimum practical cycle time),
followed by (if applicable):
'+' - value has increased from previous value
'-' - value has decreased from previous value
Refer to the relevant SCOOT messages and relevant database values
using another terminal and compare them to the values displayed on the
RFTD screen.
The values agree and change at the correct times.
T09-05500
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
To test further behaviour of the Region fine tuning display.
Allow the display to stay up for several cycle optimiser periods and
change the simulated detector replies to change the minimum practical
cycle time for each node.
The MPCYs change on the display and indicate whether they have
increased or decreased.
Force some nodes to single cycle and some to double cycle.
The letters FS or FD appear respectively after the node SCN.
For a node which is not forced manipulate the MPCYs for the region so
that it double cycles.
The letter D appears after the node SCN.
T09-05600
Purpose:
Action:
Result:
Action:
SYSTEST.DOC
To terminate the display
Bring an NFTD display up. Enter The traffic prompt '#'
The display terminates.
Repeat the test for '-' and CTRL-Z
Issue 11.0 Page 9-18
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T09-05700
Purpose:
Action:
Result:
To show that the RFTD display is available on all terminal types except
hard copy terminals.
Attempt to repeat tests T09-05400 to T09-05600 on all available terminal
types. ie VT420, Colour PC, Roving Terminal, Hard copy terminal.
The display is available on all terminals except hard copy terminals.
T09-05800
Purpose:
Action:
Result:
9.1.11
To show that similar or different RFTD displays may run on different
terminals at the same time.
On all suitable terminals start RFTD displays at least two, but not all, of
which should be for the same region.
All displays run successfully and there is no interaction or degradation in
performance. Displays for the same node are identical and update at the
same time.
Region Fine Tuning Display - Networked Systems
T09-05900
Purpose:
Action:
Result:
9.1.12
To show that remote RFTD displays are available.
At a terminal connected to TCCA enter an NFTD command specifying a
region controlled by TCCB.
The display is produced and operates exactly as for a local region.
Link Monitor Display (LMON)
Reference : VAX SRS section 2.9.1
T09-06000
Purpose:
Action:
SYSTEST.DOC
To demonstrate the LMON command
Enter the following commands:
(a) #LMON
(not enough parameters)
(a) #LMON N
(incomplete SCN)
(a) #LMON Jbbbbb
(bad SCN)
(a) #LMON Nbbbbb
where bbbbb is a valid SCN. (Wrong SCN
type)
(a) #LMON NbbbbbB cc
B is a letter. (too many parameters)
(a) #LMON NaaaaaB
where aaaaa is an invalid node SCN and B
is a valid link. (Bad SCN)
(a) #LMON NaaaaaB
where aaaaa is an valid node SCN and B is
a invalid link. (Bad SCN)
(a) #LMON Naaaaa*
where aaaaa is an valid node SCN and B is
a valid link. (Wildcarding not allowed)
(a) #LMON N**
where aaaaa is an valid node SCN and B is
Issue 11.0 Page 9-19
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
a valid link. (Wildcarding not allowed)
(a) #LMON NaaaaaA
Where NaaaaaA is a valid link which is not
a normal or entry link.
All these commands are rejected.
T09-06100
Purpose:
Action:
Result:
To demonstrate the Link Monitor Display
Enter the command #LMON lnkSCN, where lnkSCN is a valid normal or
entry link.
A display is produced containing live update fields for the SCOOT
parameters, saturation occupancy, journey time, maximum queue
clearance time, split optimiser status, offset optimiser status and cycle
time optimiser status for the link or associated structures.
Up to 20 seconds of SCOOT loop data is displayed in a horizontal field
with the most recent data on the left.
T09-06200
Purpose:
Action:
Result:
Action:
Result:
To show that the display may be terminated by entering a traffic prompt.
With the display active enter the '-' prompt.
The display is terminated.
Restart the display. Enter the '#' prompt.
The display is terminated.
T09-06300
Purpose:
Action:
Result:
Action:
Result:
To show that a set of link level SCOOT messages may be started and
stopped using the single numeric 'hot key' associated with the message.
For each message use the associated 'hot key' to start the message.
The M14, M10, M11, and M08 messages are started and displayed in the
lower part of the screen.
Use the 'hot key' for each message again.
The messages are stopped.
T09-06400
Purpose:
Action:
Result:
9.1.13
To demonstrate that LMON can cope with up to three detectors.
Start LMON displays on links with 2, 3, and 4 detectors.
For 2 and 3 detectors the display shows each detector on a separate
horizontal line. With four (or more) detectors the fourth (and subsequent)
detector's information is not displayed.
Link Monitor Display (LMON) - Networked Systems
T09-06500
Purpose:
SYSTEST.DOC
To show that remote LMON displays are available.
Issue 11.0 Page 9-20
System Test Specification for a VAX/VMS UTC System
Action:
Result:
666/YJ/16940/000
At a terminal connected to TCCA enter an NFTD command specifying a
link controlled by TCCB. Repeat the above sub-tests.
The display is produced and operates exactly as for a local link.
9.2
Colour Graphic Displays
9.2.1
Picture Preparation
Reference : VAX SRS section 2.9.2
T09-06600
Purpose:
Action:
SYSTEST.DOC
To test the semi-graphical picture generation software.
This test takes the form of an operator session which exercises the
facilities of the picture generation software. Instructions for the use of
picture generation are contained in the operators handbook (ref. XXX).
(a) No details of the test will be specified here, it is left to the discretion
of the test engineer. However the test should involve at least the
following:
(a) delete an existing picture,
(a) edit an existing picture,
(a) create a new picture. This picture should contain at least one example
of all the field types. If necessary a second picture may be created.
(a) give a title to a picture.
See also section 2.5 for more details of the pictures required for system
test.
The following facilities should be exercised:
(a) Use of up to 8 foreground colours
(a) Use of up to 8 background colours
(a) Steady and flashing objects
(a) Use of single screen refresh key
(a) Left, right, up, down and home cursor keys.
(a) deletion of a structure created.
(a) moving and modifying a structure created
(a) Saving a picture
(a) listing of available pictures
(a) deleting a picture
(a) exiting from picture creation without saving
The following background structures should be constructed and modified.
(a) A line (lengthen, shorten, rotate, position to middle or edge of
character position)
(a) An arrow (lengthen shorten and rotate)
(a) Text (Positioned horizontally, Vertically or at 45 degrees to the
horizontal in either direction)
(a) Semigraphics
Issue 11.0 Page 9-21
System Test Specification for a VAX/VMS UTC System
Result:
9.2.2
666/YJ/16940/000
(a) Graphics
(a) Rectangle (lengthen, widen)
The following Live update fields should be created.
(a) Car Park
(a) Date
(a) Detector
(a) Diversion Sign
(a) Junction
(a) Parking Sign
(a) Pelican
(a) Plan
(a) Queue Detector
(a) Special Facility
(a) Stage
(a) Time
(a) Region
(a) Node
(a) Link Status
(a) Link Green
(a) Link Congestion
(a) SCOOT Detector
Background fields should be associated with 'Symbolic' Stages. There
should be:
(a) There should be a symbolic for a junction with 8 stages.
(a) There should be symbolics for junctions pelicans and special facilities.
(a) There should be symbolic stages using all of the background fields
(a) The SCN associated with a symbolic should be changed
(a) A symbolic stage should be created by copying an existing one.
(a) The command to list all symbolics should be used.
(a) There should be a symbolic for car park sign state display.
All the fields and structures are available and behave correctly.
Picture Preparation - Networked Systems
Reference: VAX SRS section 2.10.8 (6)
T09-06700
Purpose:
Action:
SYSTEST.DOC
To demonstrate that pictures can be created containing equipment
controlled by more than 1 TCC.
Enter a GENP command at the TMC. Modify an existing picture to
include equipment (junctions, pelicans, car parks etc.) controlled by
different TCCs.
Issue 11.0 Page 9-22
System Test Specification for a VAX/VMS UTC System
Result:
9.2.3
666/YJ/16940/000
All valid SCNs are accepted and a new picture file is created. At the end
of the GENP session the new picture file and directory file are sent to all
TCCs and are available for display.
Picture Display
Reference : VAX SRS section 2.9.2
T09-06800
Purpose:
Action:
Result:
Action:
Result:
9.2.4
This test proves the ability of the system to display fixed and live update
data in a picture created by the procedure in test T09-06600.
Use the LSTP command to list the pictures which are currently available
in the system.
Enter a PICT command using a non-existent picture number.
A "No such picture file" message appears on the operator VDU.
Enter a PICT command for a picture which is on the list.
The requested picture is displayed. The active plan number and other live
update data can be checked by reference to the timetable and by use of the
MONI command. Symbolic
Picture Display - Networked Systems
Reference : VAX SRS section 2.10.8 (6)
T09-06900
Purpose:
Action:
Result:
Action:
Result:
9.2.5
To demonstrate the display of multi-computer pictures.
With all the TCCs and the TMC on-line, display the picture created in T906800 on terminals connected to each of the computers.
Identical pictures are displayed on each terminal. Live update data
changes concurrently on each display.
Disconnect the link to one of the TCCs.
The display on the disconnected TCC shows only local data; data from all
other TCCs is replaced by "!" symbols.
On other TCCs and the TMC all data is displayed with the exception of
that from the disconnected TCC, which appears as "?".
TDD Diagram - Create, Modify, Delete and Display
Reference : VAX SRS section 2.9.2
T09-07000
Purpose:
Action:
Result:
SYSTEST.DOC
To list the diagrams currently available in the database.
At an operators terminal enter the command TDDD H0n000
where n is the current computer.
The TDD program enters the initialisation mode and a list of the diagrams
currently available in the database is displayed.
Issue 11.0 Page 9-23
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T09-07100
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
To create a new TDD diagram.
In the "initialisation" mode enter the command SETUP n
where n is not on the list of available diagrams.
An "empty" set-up screen is displayed
Enter data in the diagram fields using the cursor keys as described in
Appendix G of the Operators Handbook (ref. XXX).
Enter data for controllers which are in at least 4 different sub-areas.
For each of the field types check that invalid data is rejected, e.g.
equipment type can only be J or P.
A new TDD diagram is created.
Move the cursor up to the command line and enter the command SETUP
The list of available TDD diagrams is displayed, including the diagram just
created.
Repeat the above procedure and create a second new diagram, using the
command
SETUP m.
T09-07200
Purpose:
Action:
Result:
To show that up to 20 junctions and pelicans may be defined on one
diagram with a distance of between 0 and 2000 metres from a zero point.
Create a diagram with the maximum of 20 junctions and pelicans and
distances up to the maximum 2000 metres from the zero point.
The diagram is accepted.
T09-07300
Purpose:
Action:
Result:
To show that up to 40 TDD diagrams may be created.
Repeat the procedure in the previous test to create a total of 40 TDD
diagrams. Attempt to create a 41st.
40 diagrams are successfully created. The 41st is rejected.
T09-07400
Purpose:
Action:
To modify an existing TDD diagram.
Enter the command -
SETUP n
Result:
Action:
Result:
The TDD diagram "n" data is displayed.
Modify the data fields, deleting some fields, changing the values of others.
The diagram is modified and the new version saved.
T09-07500
Purpose:
SYSTEST.DOC
To delete an existing TDD diagram.
Issue 11.0 Page 9-24
System Test Specification for a VAX/VMS UTC System
Action:
Result:
Action:
Result:
9.2.6
666/YJ/16940/000
Whilst in the set-up mode, move the cursor to the command line and enter
the command DELETE m where m is the diagram created in T9-07100 above.
The diagram is deleted. Use the "SETUP" command to list the available
diagrams to confirm this.
Enter the command EXIT
The TDD control program exits and the prompt is displayed.
TDD Diagram - Monitor Mode
Reference : VAX SRS section 2.9.2
T09-07600
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
To prove that invalid parameters are rejected in "initialisation" mode.
Enter the command TDDD
The TDD control program is entered and the list of available diagrams in
the database is displayed.
Enter the command QUIT
The command is rejected.
Enter the command DSPLY
The command is rejected.
T09-07700
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
SYSTEST.DOC
To display data in "monitor" mode.
Enter the command MONITOR n
where n is the first diagram created in T09-07100
above.
The TDD program enters "monitor" mode.
Check the data being displayed for each controller. Check that each subarea is displayed in a different colour.
Controllers in local mode, undergoing controller checks and under
SCOOT control are identified.
Enter the DIPM command for a junction on the display. Check the stage
times shown on the TDD display are the same as those shown on the plan
monitor display.
Within the TDD display limits the values are the same.
Attempt to enter the DELETE command.
The command is rejected since it is not available in "monitor" mode.
Issue 11.0 Page 9-25
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T09-07800
Purpose:
Action:
Result:
Action:
Result:
9.2.7
To vary the display parameters in "monitor" mode.
Use the CYCLE sub-command to vary the cycle time on the axis.
Change the cycle time to show that it may be taken up to 400 seconds
with the display scaled accordingly. Reduce it so that the descriptive text
is displayed for the controllers.
Use the AUTO sub-command to enable and disable the auto-cycling
mode.
Use the GRID sub-command to switch the grid in and out.
Use the CRUISE sub-command to display the cruise gradient. Test the
cruise gradient in the range 10 to 240 km/hr.
The commands are accepted and the displays changed as required. The
scale limits are correct.
Enter the command EXIT or type a "-"
The TDD control program exits and the prompt is displayed.
TDD Diagram - Predict Mode
Reference : VAX SRS section 2.9.2
T09-07900
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
Action:
Result:
To prove the rejection of invalid sub-commands in "predict" mode.
Enter the command TDDD followed by the sub-command PREDICT n.
The TDD control program enters the "predict" mode.
Enter the sub-command DELETE
Command is rejected as it is not available in "predict" mode.
Enter the PLAN sub-command with invalid plan and sub-area numbers.
Command is rejected.
Enter the GWAV sub-command with an invalid route number.
Command is rejected.
T09-08000
Purpose:
Action:
Result:
9.2.8
To prove the correct actioning of valid sub-commands.
Enter a number of PLAN and GWAV sub-commands for valid plans, subareas and routes.
The commands are accepted and the displays changed accordingly.
Time-Distance Diagram, Networked Systems
Reference : VAX SRS section 2.10.8 (7)
SYSTEST.DOC
Issue 11.0 Page 9-26
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T09-08100
Purpose:
Action:
Result:
Action:
Result:
To demonstrate that the equipment specified in a Time-Distance Diagram
must all be controlled by the local TCC.
(a) Enter a TDDD command at a terminal connected to TCCA.
The command is accepted. When in SETUP mode the picture directory
contains only those pictures (if any) which have previously been created
on TCCA.
(b) Attempt to create a diagram with intersections and pelicans which are
in sub-areas controlled by TCCB.
All equipment in sub-areas not controlled by TCCA is rejected.
T09-08200
Purpose:
Action:
Result:
Action:
Result:
To demonstrate that the TDDD command may be entered at the TMC in
certain circumstances.
(a) At a terminal connected to the TMC enter a TDDD command with
no parameter.
The command is rejected since the TMC does not control any equipment.
(b) At a terminal connected to the TMC enter a TDDD command with a
parameter H01000.
The command is accepted and the TDD directory for TCCA is displayed
when in setup mode.
T09-08300
Purpose:
Action:
Result:
9.2.9
To demonstrate that the TDDD command can specify a remote TCC.
At a terminal connected to TCCA enter a TDDD command with a
parameter H02000.
The command is accepted and the TDD directory for TCCB is displayed
when in setup mode.
SCOOT VEGA Display
Reference : SRS section 2.9.2
T09-08400
Purpose:
Action:
SYSTEST.DOC
To show that the VEGA command may be used to display the demand
and queues on a specified normal or entry link which is not associated
with a demand dependent UTC stage.
Use the command VEGA on a single SCOOT link. Monitor the display
for one cycle. Use the CHAN command to modify parameters including
QCMQ, JNYT, STOC and FCYT for the link/region in question and
check the effect on the display. To check the change to FCYT wait for a
change in cycle time. Check reds/greens against the M14 event driven
message. Check queue size also using M14. Ensure that the offset
optimiser is active on the link and that both positive and negative offset
changes can occur without display corruption or excessive updating.
Issue 11.0 Page 9-27
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
Note: Changes of QCMQ, STOC and cycle time will cause the VEGA
display to be re-plotted. Changes in offset or split will not cause the
display to be re-plotted.
The required display is produced and is updated every 4 seconds (except
when the link is suspended) or when the value of a significant parameter
changes. The scales for each histogram reflect the current values of the
QCMQ, STOC and the cycle time.
T09-08500
Purpose:
Action:
Result:
To show that the VEGA display behaves correctly for links associated
with a demand dependent UTC stage.
Repeat the above test simulating demand for the demand dependent stage
on selected cycles only.
When the demand is present, the link is shown to change colour when the
demand dependent stage is called. With no demand the link changes
colour only if the following stage runs and causes a colour change. For
both possibilities, the display is seen to "suspend" (i.e. no updates occur)
during the period when the SCOOT model is suspended for the link.
Updates continue when the UTC stage actually run is reported to the
SCOOT sub-system. The display will react to changes in parameter values
and to optimisations as described above.
T09-08600
Purpose:
Action:
Result:
To demonstrate that a VEGA diagram will indicate if the state of the
lights is green and the main downstream link is exit blocked.
Start a VEGA diagram for a particular link. Using the OVRB command
indicate a standing queue on the downstream link during a green to link
period i.e. exit blocking. Activate the M08 event driven message and
monitor the EXITB parameter which indicates when the exit to the link is
blocked. Monitor the VEGA display. Subsequently remove the standing
queue simulation and check that the VEGA display returns to normal.
The M08 message parameter EXITB changes from 0 to 1 to indicate exit
blocking. The flow bars updated on the display are shown in magenta to
indicate the exit-blocked condition. The flow bars updated on the display
return to green once the downstream link is no longer blocked. (M08
EXITB parameter goes from 1 to 0).
T09-08700
Purpose:
Action:
Result:
SYSTEST.DOC
To show that the VEGA command may be used to display the demand on
a filter link.
Use the command VEGA on a single SCOOT filter link. Monitor the
display for one cycle. Use the CHAN command to modify parameters
including JNYT and STOC for the filter link in question and check the
effect on the display. Check that only the flow histogram is shown and
only updated during the green to the filter.
The required display is produced and is updated every 4 seconds, when an
optimization takes place, or when the value of a significant parameter
changes. Only the flow histogram is updated.
Issue 11.0 Page 9-28
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T09-08800
Purpose:
Action:
Result:
9.2.10
To show that VEGA diagram may be used to display up to 4 diagrams
and a mixture of normal and filter links.
Invoke a VEGA display with the following mixtures of normal and filter
links:
(a) 4 normal links
(a) 3 normal links and 1 filter.
(a) 2 normal links and 2 filters.
(a) 1 normal link and 3 filters.
(a) 4 filter links
For each of the combinations repeat tests T09-08400 and T09-08700.
The VEGA display is produced correctly for each combination of links.
The effects of changing parameter values and exit blocking are as for
single VEGA displays. Where filter links are displayed only the flow
histogram is shown and only updated during the green to the filter.
SCOOT VEGA Display - Networked Systems
Reference : VAX SRS section 2.10.8 (7)
T09-08900
Purpose:
Action:
Result:
To demonstrate that all links in a 4-way VEGA display must be in regions
controlled by the same TCC.
Enter a VEGA command specifying 4 links which are in regions
controlled by TCCA and TCCB.
The command is rejected.
T09-09000
Purpose:
Action:
Result:
Action:
Result:
9.2.11
To demonstrate that remote VEGA displays are available.
(a) At a terminal connected to TCCA enter VEGA commands specifying
1 and 4 links which are in regions controlled by TCCB.
The command is accepted and the correct displays produced.
(b) Repeat action (a) at a terminal connected to the TMC.
The command is accepted and the correct displays produced.
Automatic Display Cancelling
Reference : VAX SRS section 2.9.1
T09-09100
Purpose:
Action:
SYSTEST.DOC
To show that the system may be configured such that the MONI, OVRB,
FLOW, DIPM, LVAL, NFTD & RFTD displays cancel after a defined
number of minutes.
Configure the system such that The displays cancel:
(a) after 0 minutes
Issue 11.0 Page 9-29
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
(a) after 2 minutes
(a) after 15 minutes
Start each display in turn and leave for the configured number of minutes.
(a) The displays are cancelled immediately it is started
(b) The displays are cancelled after 2 minutes
(b) The displays are cancelled after 15 minutes
9.3
Screen Dumps to Printer
9.3.1
Operator Facilities
Reference : VAX SRS section 2.9.3
T09-09200
Purpose:
Action:
Result:
To prove that the displays produced by the MONI, OVRB and DIPM
commands can have snap shot dumps made of the display and sent to a
monochrome printer.
For each of the above commands call up the display and press CTRL and
P simultaneously.
At the monochrome printer associated with the terminal a print out of the
display when CTRL P was typed is printed.
T09-09300
Purpose:
Action:
Result:
To show that simultaneous dumps to the printer are queued and output
consecutively.
Using as many terminals as are available send screen dumps to the printer
using Control P from all simultaneously.
The Dumps are printed one after the other. (There is no interleaving)
T09-09400
Purpose:
Action:
Result:
To prove that the displays produced by the PICT, TDDD and VEGA
commands can have snap shot dumps made of the display and sent to a
colour printer.
For each of the above commands call up the display and press CTRL and
P simultaneously.
At the colour printer associated with the terminal a print out of the display
when CTRL P was typed is printed.
T09-09500
Purpose:
Action:
Result:
SYSTEST.DOC
To prove that the system will not try to dump Colour displays to an
inappropriate printer.
Attempt to dump the displays produced by PICT TDDD and VEGA to
the printer when a colour printer is not configured in the System.
Control P has no effect in this case.
Issue 11.0 Page 9-30
System Test Specification for a VAX/VMS UTC System
9.4
Listings
9.4.1
Listings - General
666/YJ/16940/000
Reference : VAX SRS section 2.9.4
N.B. Some of these tests may be duplicated elsewhere in this document.
T09-09600
Purpose:
Action:
Result:
To show that it is possible to list unacknowledged faults.
Enter the command
#LSTA.
Any unacknowledged faults are listed on the terminal at which the
command was entered.
T09-09700
Purpose:
Action:
Result:
To show that it is possible to list certain count detector data.
Enter the commands:
(a) #LTSD Dnnnnn
where Dnnnnn is a count detector SCN
(a) #LSTD D00000
(a) The last hours flow, the percentage occupancy and the congestion
state for the particular count detector are listed.
(b) The information above is listed for all count detectors on the system.
T09-09800
Purpose:
To show that the current faults may be listed by SCN and fault category.
Action:
Enter the following commands:
(a) #LSTF
(a) #LSTF J00000
(a) #LSTF Jnnnnn
where Jnnnnn is an existing junction with
faults on it.
(a) #LSTF f00
(a) #LSTF fff
where fff is a fault category for which there
are faults.
(a) #LSTF Jnnnnn fff
where Jnnnnn is a junction with fault number
fff on it.
(a) All faults on the system are listed to the terminal on which the
command was entered.
(b) All faults on all junctions are listed to the terminal on which the
command was entered.
(b) All faults on the junction in the command are listed to the terminal on
which the command was entered.
(b) All faults in the wildcarded fault category are listed to the terminal on
which the command was entered.
Result:
SYSTEST.DOC
Issue 11.0 Page 9-31
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
(b) All faults in the given fault category are listed to the terminal on
which the command was entered.
(b) Any faults in the given fault category on the given equipment are
listed to the terminal on which the command was entered.
T09-09900
Purpose:
Action:
Result:
To show that green wave routes may be listed.
Enter the command #LSTG Gnnnnn where Gnnnnn is a valid green
wave route.
Each equipment on the route is listed together with its offset from the
start of the route, the stage used and the duration of the stage.
T09-10000
Purpose:
Action:
Result:
Action:
To show that Active SCOOT event driven messages may be listed.
Start a selection of SCOOT event driven messages which are only output
in frequently. (so that it is difficult to tell whether they are running or not).
Messages associated with the Cycle optimiser and congestion would be
suitable.
Enter the command #LSTM
A list of the active SCOOT event driven messages is output. Even if they
are not currently producing any output.
Stop the messages.
T09-10100
Purpose:
Action:
Result:
To show that available picture files may be listed.
Enter the command #LSTP.
The Titles of existing picture files are listed to the terminal on which the
command was entered.
T09-10200
Purpose:
Action:
Result:
SYSTEST.DOC
To show that the status of junction or pelican controllers may be listed.
Enter the following commands.
(a) #LSTS Ann000
where nn is a valid subarea.
(a) #LSTS Jnnnnn
where Jnnnnn is a valid junction SCN.
(a) #LSTS
(a) #LSTS s
where s is one of the status categories.
(a) #LSTS J00000 s
The status categories are listed for the requested equipments.
(a) The status of all junctions and pelicans in subarea nn is listed.
(a) The status of the given junction is listed.
(a) The status of all junctions and pelicans is listed.
(a) All junctions and pelicans in state s are listed.
Issue 11.0 Page 9-32
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
(a) All junctions in state s are listed.
T09-10300
Purpose:
Action:
Result:
To show that the status of car parks may be listed.
enter the following commands:
(a) #STCS C00000
(a) #STCS Cnnnnn where Cnnnnn is a valid car park SCN.
The Occupancy, Thresholds and overall state are shown for:
(a) All car parks
(a) This particular car park.
T09-10400
Purpose:
Action:
Result:
To show that the transmission error counts since the last hour boundary
may be displayed.
Enter the command #LTEC.
The transmission error counts since the last hour boundary are displayed.
N.B. Baseline data is fully tested in section
T09-10500
Purpose:
Action:
Result:
9.4.2
To demonstrate redirection of output.
Repeat tests T09-09600 to T09-10400 using the parameter >T01nnn as
the last parameter to the command, where nnn is the terminal number of:
(a) A terminal of a different type to the one issuing the command.
(a) A hard copy terminal.
The output is redirected to the requested terminal.
Listings - Networked Systems
T09-10600
Purpose:
Action:
Result:
Action:
Result:
To demonstrate the listing of data from more than 1 TCC.
Enter a number of listing commands e.g. LSTG, LLCF, LSTD, LSTF,
LSTS, VALU, for equipment controlled by more than 1 TCC.
Reports are produced and data is grouped in IRN order by equipment
type within each TCC.
Repeat the above with one or more TCCs offline.
Data is listed from the TCCs which are online. A message "No computer
available to process the request" is output for each TCC which is offline.
T09-10700
Purpose:
SYSTEST.DOC
To demonstrate the action of CTRL-O on terminal output.
Issue 11.0 Page 9-33
System Test Specification for a VAX/VMS UTC System
Action:
Result:
Action:
Result:
666/YJ/16940/000
At a terminal connected to TCCA start a LOGO listing for the full system
log. When the listing is under way, enter a CTRL-O command on the
terminal.
The listing is aborted immediately.
Repeat the above procedure with the following commands :
LSTD LSTG LSTF LSTS STCS WHAT LSTA
In each case wild card parameters should be used so that data is fetched
from all computers.
All listings are aborted immediately.
T09-10800
Purpose:
Action:
Result:
To demonstrate that a partial timetable listing can be produced from a
remote computer.
Enter an OUTT command at a terminal connected to TCCA, specifying
only SCNs controlled by remote TCCs.
Only those timetable events involving the specified SCNs are listed.
T09-10900
Purpose:
Action:
Result:
To demonstrate that multi-computer listing commands may be entered in
the timetable.
Choose a timetable (or create a new one) with a number of listing
commands for wild card equipment. The output should be directed to
terminals on different computers.
All the listings are produced correctly.
T09-11000
Purpose:
Action:
Result:
9.5
To demonstrate that listings may be re-directed to a terminal on a remote
computer.
At a terminal connected to TCCA enter a WHAT command for
equipment controlled by TCCA and re-direct the output to a terminal
connected to TCCB.
The listing is produced on the remote terminal.
Log OTU Replies to Disc
Reference : VAX SRS section 2.9.5
T09-11100
Purpose:
Action:
SYSTEST.DOC
To prove that up to 4 different in station addresses can be monitored
independently and the control and reply data stored in separate disc files.
Enter the commands :
LOTU H01000 1
LOTU H01000 2
LOTU H01000 3
LOTU H01000 4
Issue 11.0 Page 9-34
System Test Specification for a VAX/VMS UTC System
Result:
Action:
Result:
Action:
Result:
Action:
Result:
666/YJ/16940/000
LOTU H01000 5
The first 4 commands are accepted the fifth one is rejected.
Enter a MONI command for the each address above and once the screen
has filled request a snap shot dump.
4 print outs covering each address for a defined time.
Terminate the logging with the following commands :
XLOT H01000 1
XLOT H01000 2
XLOT H01000 3
XLOT H01000 4
For each XLOT command the system acknowledges that the logging has
been terminated.
Use the DLOT command to print for each address the time period
covered by the MONI prints.
4 print outs are obtained which match the MONI prints with regard to the
control/reply data and the bit definitions.
T09-11200
Purpose:
Action:
Result:
To show that outstations may be referred to by SCN in the LOTU
command.
Repeat test T09-11100 using an SCN of the form Xnnnnn where nnnnn is
a valid Outstation SCN.
The same results are obtained as before.
T09-11300
Purpose:
Action:
Result:
To show that an attempts to log equipment connected to an outstation are
accepted.
Enter LOTU commands for equipments other than outstations or
computer addresses.
The commands are accepted.
T09-11400
Purpose:
Action:
Result:
Action:
Result:
SYSTEST.DOC
To show that logging will be carried out for the specified time or 24
hours.
Enter a LOTU command with a finish time. Wait for the finish time to
pass. Enter a DLOT command for the same OTU.
The output shows that logging stopped at the specified time.
Enter a LOTU command without a removal time and leave it for over 24
hours. Enter a DLOT command.
The logging finished 24 hours after the start time.
Issue 11.0 Page 9-35
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T09-11500
Purpose:
Action:
Result:
Action:
Result:
To show that logging is terminated or not started if free disc space drops
below 1500 blocks.
Start a log. Arrange for the free disc space to drop below 1500 blocks.
The log which is running is terminated with an informative message.
Attempt to start another log.
The command is rejected.
T09-11600
Purpose:
Action:
Result:
To show that only one log file may be kept per outstation/address.
For an outstation for which a log already exists as shown by the DLOT
command enter another LOTU command.
A message is output that the old file has been deleted. A DLOT after the
new log has finished will only show data for the most recent command.
T09-11700
Purpose:
Action:
Result:
To show that LOTU files are deleted automatically a fixed number of days
after creation.
Create a number of LOTU files on different days. Advance time more
than the configured number of days for which the earlier files are
preserved.
The files whose lifetime has expired are deleted and messages output to
indicate this.
T09-11800
Purpose:
Action:
Result:
9.6
To show that DLOT may not be used for an OTU for which a LOTU is
still running.
Enter a LOTU commands for an OTU. While the log is still active Enter a
DLOT command.
The command is rejected.
Data File Archiving
Reference : VAX SRS section 2.9.6
T09-11900
Purpose:
Action:
Result:
SYSTEST.DOC
To show that System log and count data information may be archived.
Using DCL, copy System log and count data from the System disc to
tape. Verify that it is possible to transfer log and count data to tape within
the file lifetime such as to produce a continuous magnetic LOG and count
archive.
The data is successfully archived.
Issue 11.0 Page 9-36
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T09-12000
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
To show that System log and count data information may be retrieved
from archive.
Using DCL, copy System log and count data from an archive tape back to
the System disc. Use the LOGO and OPFD commands to verify that the
data has been retrieved.
The required data is retrieved intact.
Allow the System to pass through midnight.
The Archiver program runs at or near midnight and deletes all System log
and count files over the age limit specified in the database. messages are
output for each file deleted.
Use LOGO and OPFD to verify that the archive files are no longer
present.
The LOGO and OPFD command lines to view the files that were retrieved
are now invalid.
T09-12100
Purpose:
Action:
Result:
To show that Database source and object files may be archived.
Using the @BACKUP indirect command file, select the options to archive
the database source and object files.
The files are successfully archived.
T09-12200
Purpose:
Action:
Result:
Action:
Result:
To show that Database source and object files may be retrieved. (retrieve
a different, easily verifiable, object file).
Using the @BACKUP indirect command file, select the options to
retrieve the database source and object files.
Using database preparation it may be verified that the database source
files have been retrieved.
Enter an UPDA.
It may be verified that the database in use is now different.
T09-12300
Purpose:
Action:
Result:
To show that picture files may be archived.
Use DCL to archive PICTure files to tape. Delete them from the System.
The files are transferred to tape and deleted from the System.
T09-12400
Purpose:
Action:
Result:
SYSTEST.DOC
To show that picture files may be retrieved.
Use DCL to retrieve picture files from tape back onto the System disc.
Use PICT to confirm that the pictures have returned. The behaviour of
files with the same name is defined by the VMS operating system.
The files have returned and may be used.
Issue 11.0 Page 9-37
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T09-12500
Purpose:
Action:
Result:
To show that car park information files may be archived.
Archive car park information files to tape using DCL commands. Delete
the files from the System disc.
The files are archived and removed from the System disc.
T09-12600
Purpose:
Action:
Result:
To show that car park information files may be retrieved.
Retrieve car park information files from tape using DCL commands.
Ascertain that the files are available for use.
The files have returned and are available for use.
T09-12700
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
To show that changing of the date and or time by operator command does
not adversely affect data archiving.
DATE commands to move the time backwards by several days. Examine
the LOG and Count file directory.
Existing LOG and Count files will be unaffected unless there are any files
existing which are older than the maximum permitted file lifetime.
Existing files which are now in the future will be overwritten as time
proceeds.
Move time forwards by less than the number of days file lifetime of either
LOG or Count data.
Existing LOG and Count files remain until the Archiver program runs at
or near midnight. Then all LOG and Count files which are older than the
file lifetimes in the system data are deleted.
Move time forwards by more than the number of days file lifetime of
either LOG or Count data.
All LOG and Count files apart from the current day's are deleted on the
next run of the archiving program
9.7
Parameter Displays
9.7.1
UTC SEED Display
Reference : VAX SRS section ???
T09-12750
Purpose:
Action:
SYSTEST.DOC
To demonstrate the correct functioning of the SEED display for all UTC
equipment types.
For each of the following UTC equipment types in turn invoke a multiple
SEED display of the form :
SEED tnnnnn tmmmmm ...
where t is a single valid equipment type and nnnnn and mmmmm are valid
SCNs.
Issue 11.0 Page 9-38
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
(a) C - Car Park
(a) D - Count Detector
(a) E - Ethernet Port
(a) F - Special Facility
(a) H - Computer
(a) J - Junction controller
(a) L - Tidal Flow controller
(a) P - Pelican controller
(a) Q - Queue detector
(a) S - Car Park Sign
(a) T - Terminal
(a) U - Diversion
(a) V - Diversion sign
(a) X - OTU
(a) Y - OMU
(a) Z - Remote request
Check, where possible, that the values on the display agree with the
database.
All values are displayed correctly and agree with the database.
T09-12760
Purpose:
Action:
Result:
9.7.2
To demonstrate the correct functioning of the SEED display for
combinations of UTC equipment types.
Repeat test T09-12750 by invoking a multiple SEED display of the form :
SEED annnnn bmmmmm ...
where a and b are different valid equipment types and nnnnn, mmmmm,
etc. are valid SCNs.
Check, where possible, that the values on the display agree with the
database.
All values are displayed correctly and agree with the database.
SCOOT SEES display
Reference : VAX SRS section 2.9.2
T09-12800
Purpose:
Action:
SYSTEST.DOC
To demonstrate the correct functioning of the SEES display for each of
the SCOOT data types.
For each of the following SCOOT data types in turn invoke a multiple
SEES display of the form :
SEES Nnnnnn Nmmmmm ...
where Nnnnnn and Nmmmmm are valid SCOOT SCNs.
Issue 11.0 Page 9-39
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
(a) Area
(a) Region
(a) Node
(d) Link
(d) Stage
(d) Detector
Check in each case that the values on the display agree with the database,
both by using the VALU command and examining the SCOOT database
listing. In the case of values which may have been changed by the SCOOT
system while on-line use the VALU command only to check the current
value.
All values are displayed correctly and agree with the database and/or the
VALU command.
T09-12900
Purpose:
Action:
Result:
9.8
To show that mixtures of different SCOOT data types can be displayed at
the same time, and that this does not affect the values displayed.
Invoke a SEES display with the following combinations of SCOOT data
types:
(a) A detector & a region.
(a) A stage & a link.
(a) A link & the area.
(a) A node & a region.
(a) A region & a stage.
(a) The area & a node.
Check in each case that the values displayed are correct in comparison
with the database. Each test should be tried both with the data items
related e.g. the node being in the region, and unrelated e.g. the node not
within the region.
In all cases the values displayed agree with the database and/or the VALU
display.
SCOOT Event Driven Messages
Reference : MCE 0360C paragraph 4.2.4, 4.2.6
VAX SRS section 2.9.8
For the duration of this test care should be taken to determine the exact state of the
items of equipment used. This should include such details as the implementation status
and translation plan for nodes and the consequent inclusion in/exclusion from the
mode of stages, links and detectors. Some of the above conditions may need to be
varied in order to obtain message output. Some should be varied in order to
demonstrate the effects on messages where this is appropriate.
T09-13000
Purpose:
Action:
SYSTEST.DOC
Check operation of model (M) messages.
Test each of SCOOT model messages in turn, supplying parameters as
required. Where external inputs are needed these will be provided if
possible using real or simulation hardware. The following list of messages
must be tested:
(a) M01
Issue 11.0 Page 9-40
System Test Specification for a VAX/VMS UTC System
Result:
SYSTEST.DOC
666/YJ/16940/000
(a) M02
(a) M03
(a) M04
(a) M05
(a) M06
(a) M07
(a) M08
(a) M09
(a) M10
(a) M11
(a) M12
(a) M14
(a) M15
(a) M16
(a) M17
(a) M18
(a) M19
(a) M20
(a) M21
(a) M22
(a) M23
(a) M24
(a) M25
(a) M26
(a) M27
(a) M30
(a) M31
(a) M32
(a) M33
(a) M34
(a) M35
In addition the following link level messages should be attempted for filter
links:
M02, M08, M10, M11, M12, M14, M30, M31, M32
Each message is output at its correct frequency and with all parameters as
described in the operators manual - reference . The subset of messages for
links are correctly produced for a filter link.
Issue 11.0 Page 9-41
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T09-13100
Purpose:
Action:
Result:
Action:
Result:
To check that event driven message output may be switched off by
operator command.
Enter the LSTM command.
The currently active SCOOT event driven messages are displayed.
Use the 'XMES' command to cancel output of the various messages given
in the list of active messages. Ensure that messages can be cancelled
individually and in groups by waiting for further output after only some
messages have been cancelled. Also check that messages may be cancelled
using wildcarded SCNs. Repeat the XMES command until all the active
messages have been cancelled. Use the LSTM command to show that no
event driven messages are active.
The cancelled messages are no longer produced when model decisions
take place. The cancellation of particular messages does not affect other
still active messages. Cancellation of messages using wild-carded SCNs
also has no adverse effect. Once all the active messages have been
cancelled the LSTM command produces no output.
T09-13200
Purpose:
Action:
Result:
To confirm that event driven messages may be output to selected
terminals by timetable command.
Modify the system time to 3 minutes before a MESS event for one of the
model messages listed above in the current timetable. Wait for the time to
pass the event time and monitor the output on the terminal specified in the
command. Confirm that the message is now active using the LSTM
command on the terminal in question.
Messages are produced on the required terminals when model decisions
take place. LSTM shows the message is active.
T09-13300
Purpose:
Action:
Result:
To confirm that output of event driven messages may be cancelled by
timetable command.
Modify the system time to 3 minutes before an XMES event in the current
timetable for the same model message as in the previous test. Wait for the
time to pass the event time and monitor the lack of output on the terminal
specified in the command. Use the LSTM command on the terminal in
question to show that the message is no longer active.
Messages are no longer produced on the required terminals. LSTM shows
the message is no longer active.
T09-13400
Purpose:
Action:
SYSTEST.DOC
Check operation of detector and link fault (W) messages.
Test each of detector/link fault messages in turn, supplying parameters as
required. Where external inputs are needed these will be provided if
possible using real or simulation hardware. The following list of messages
must be tested:
(a) W01
Issue 11.0 Page 9-42
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
(a) W02
(a) W03
(a) W04
(a) W05
(a) W06
(a) W07
(a) W08
(a) W09
(a) W10
In addition the following link level messages should be attempted for filter
links:
W01, W05, W06, W07, W08, W09, W10
Each message is output at its correct frequency and with all parameters as
described in the operators manual - reference . The subset of messages for
links are correctly produced for a filter link.
T09-13500
Purpose:
Action:
Result:
To show that the detector and link fault (W) messages may be:
(a) switched off by operator command;
(a) output to selected terminals by timetable event;
(a) cancelled by timetable event.
Repeat tests T09-13100, T09-13200 and T09-13300.
As for tests T09-13100, T09-13200 and T09-13300.
T09-13600
Purpose:
Action:
SYSTEST.DOC
Check operation of split optimiser (S) messages.
Test each of split optimiser messages in turn, supplying parameters as
required. Where external inputs are needed these will be provided if
possible using real or simulation hardware. The following list of messages
must be tested:
(a) S01
(a) S02
(a) S03
(a) S04
(a) S05
(a) S10
(a) S11
(a) S12
(a) S13
(a) S14
(a) S15
Issue 11.0 Page 9-43
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
(a) S16
(a) S17
(a) S18
(a) S19
(a) S20
(a) S21
In addition the following link level messages should be attempted for filter
links:
S03, S05, S11, S12, S15, S16, S17, S18, S19, S20, S21
Each message is output at its correct frequency and with all parameters as
described in the operators manual - reference . The subset of messages for
links are correctly produced for a filter link.
T09-13700
Purpose:
Action:
Result:
To show that the split optimiser (S) messages may be:
(a) switched off by operator command;
(a) output to selected terminals by timetable event;
(a) cancelled by timetable event.
Repeat tests T09-13100, T09-13200 and T09-13300.
As for tests T09-13100, T09-13200 and T09-13300.
T09-13800
Purpose:
Action:
Result:
Check operation of offset optimiser (O) messages.
Test each of the offset optimiser messages in turn, supplying parameters
as required. Use the software simulator to cause changes in offset
optimisation. The following list of messages must be tested:
(a) O01
(a) O02
(a) O03
(d) O04
(d) O05
(d) O06
(g) O07
(g)
In addition the following link level messages should be attempted for filter
links:
O02, O04, O05, O06
Each message is output at its correct frequency and with all parameters as
described in the operators manual - reference . The subset of messages for
links are correctly produced for a filter link.
T09-13900
Purpose:
Action:
SYSTEST.DOC
To show that the offset optimiser (O) messages may be:
switched off by operator command;
output to selected terminals by timetable event;
cancelled by timetable event.
Repeat tests T09-13100, T09-13200 and T09-13300.
Issue 11.0 Page 9-44
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
As for tests T09-13100, T09-13200 and T09-13300.
T09-14000
Purpose:
Action:
Result:
Check operation of cycle time optimiser (C) messages.
Test each of the cycle time optimiser messages in turn, supplying
parameters as required. Where external inputs are needed these will be
provided if possible using real or simulation hardware. The following list
of messages must be tested:
(a) C01
(a) C02
(a) C03
(d) C04
(d) C05
(d) C10
(g) C11
(g) C12
(g) C13
(j) C14
(j) C15
(j) C16
(m) C17
(m) C18
(m) C19
(p) C20
(p) C21
(p) C22
(s) C23
(s) C24
(s) C30
(v) C31
(v) C32
(v) C40
In addition the C30 and C40 messages should be attempted for filter links.
Each message is output at its correct frequency and with all parameters as
described in the operators manual - reference . The subset of messages for
links are correctly produced for a filter link.
T09-14100
Purpose:
Action:
Result:
To show that the cycle time optimiser (C) messages may be:
(a) switched off by operator command;
(a) output to selected terminals by timetable event;
(a) cancelled by timetable event.
Repeat tests T09-13100, T09-13200 and T09-13300.
As for tests T09-13100, T09-13200 and T09-13300.
T09-14200
Purpose:
Action:
SYSTEST.DOC
Check operation of error (E) messages.
Attempt to test the three error messages in turn:
(a) The E01 message is output when an internal stack overflow occurs in
the cycle optimiser phase A.
(a) The E02 messages is output due to overflow in interval occupancy;
short term profile; long term profile; interval occupancy accumulator;
mean modulus accumulator or because fixed offsets are not attained
because of offset ring.
(a) The E03 message is output if incorrect stage transitions occur at a
node.
As all these error messages occur as a result of fault conditions being
detected in the SCOOT kernel software it may be necessary to make data
Issue 11.0 Page 9-45
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
changes to simulate the fault and cause the messages to be output. The
E02 and E03 messages should be tested on filter links if possible.
Each message is output with parameters as described in the operators
manual - reference .
T09-14300
Purpose:
Action:
Result:
To show that the error (E) messages may be:
(a) switched off by operator command;
(a) output to selected terminals by timetable event;
(a) cancelled by timetable event.
Repeat tests T09-13100, T09-13200 and T09-13300.
As for tests T09-13100, T09-13200 and T09-13300.
T09-14400
Purpose:
Action:
SYSTEST.DOC
To show that event driven message output may be redirected to another
terminal.
For a selection of event driven messages use the final additional parameter
of the form T01nnn to the command line, where nnn is a terminal number
on the system, to redirect the output to:
(a) A terminal of a different type
(a) A hardcopy terminal
Issue 11.0 Page 9-46
System Test Specification for a VAX/VMS UTC System
10.
MAN-MACHINE INTERFACE TEST DEFINITIONS
Note :
10.1
666/YJ/16940/000
In this section, the left mouse button on the MMI (Man-Machine
Interface) system is used unless described otherwise.
Logging on and off to the System
T10-00100
Purpose:
Action:
Result:
Action:
Result:
To log on to the system via a terminal with the man-machine interface.
(a) Restart the MMI terminal by pressing the CTRL, ALT and DEL keys
on the PC terminal.
(b) Enter the Username and Password in the login window that appears
on the screen. These should be the same as used to logon through a
non-MMI terminal.
(b) Move the mouse cursor to the OK button and click the left button
once or press the Enter key.
A UTC window appears with a main menu and a number of secondary
windows.
Move around the workspace and click when the mouse pointer is on one
of the windows.
The window is highlighted in the active window colours.
T10-00200
Purpose:
Action:
Result:
Action:
SYSTEST.DOC
To show that the user can move around the workspace with the mouse
and modify the windows that are displayed.
(a) Choose a window that has two buttons in the top right-hand corner.
Click on the right hand button (the small square).
(b) Click on the same button again.
(b) Click on the other button with the small dot.
(b) Select the icon and double click on it rapidly with the left mouse
button.
(a) The window is maximised (i.e. increases in size to fill the whole
workspace window).
(b) The window returns to its original size.
(b) The window is minimized to a small icon.
(b) The window returns to its original size.
(a) Select a window and click on the button in the top left-hand corner.
Select the following options :
(b) Minimize. Subsequently double-click on the iconised window.
(b) Maximize.
(b) Size. Move the mouse cursor to one of the corners or sides and then
move it to a different position. Click once on the mouse button.
(b) Close.
Issue 11.0 Page 10-1
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
(a) The window is iconised (reduced to a small icon in the main
workspace). After double-clicking on this icon the window returns to
its original size.
(b) The window fills the whole workspace.
(b) The borders follow the mouse and the window is altered to the new
size.
(b) The window is closed.
T10-00300
Purpose:
Action:
Result:
Action:
Result:
10.2
To show that the user can configure his working environment and restore
this on subsequent logins.
Modify the current configuration by changing such items as border,
window border colours, icon placement and colours. Choose the restart
option and confirm that the current settings should be saved.
The window manager restarts with the options as selected.
In the main menu bar, Options / Automatic Startup, alter the list of
items to be included and confirm by placing the mouse cursor over the
OK button and clicking. In the session manager menu, select Session/End
Session and confirm.
The session terminates and the Username and Password are requested.
After entering these, the session restarts with the windows defined in the
list of items above.
Basic Window Manipulation
T10-00400
Purpose:
Action:
Result:
To show that a traffic command can be entered by the menu option, by
the UTC Command Entry window and via a DECterm window.
(a) Select a command from the menu system and add any necessary
parameters for its correct execution.
(b) Enter the same command with parameters via the UTC Command
Entry window. If only one instance of the command is allowed at any
one time, close the previous window.
Both windows open in exactly the same manner.
T10-00500
Purpose:
Action:
Result:
10.3
To show that iconised windows are continuously updated with data.
Start a number of windows with constantly updating data, such as MONI,
VEGA, DIPM. Iconise each one of them. After a few minutes doubleclick on each to restore them to their previous sizes.
The screens show data has been output to them even while iconised.
UTC Command Compatibility
Note :
SYSTEST.DOC
These tests are intended to prove the compatibility of commands entered
via the MMI menus and command options and the non-MMI command
entry. Within the MMI there are three modes of entering commands :
Issue 11.0 Page 10-2
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
(a) Selection of the command from the top-level menu
(a) Entering the command in the UTC Command Entry window
(a) Creating a DECterm window and entering the command in the same
manner as the non-MMI command mode.
(a) To run the tests two terminals are required - one DEC VT or IBM
PC compatible terminal running under the CTERM terminal
emulator, and an MMI terminal.
T10-00600
Purpose:
Action:
Result:
Action:
Result:
Action:
Result:
To show that the DIPM command entered on any of the above terminal
types are compatible with each other.
(a) From the main pull down menu of the MMI screen select the DIPM
command and enter a valid intersection SCN in the Equipment SCN
dialogue box and confirm by clicking on the OK or Apply box.
(b) Via the UTC Command Entry window enter the DIPM command
with the same intersection SCN.
(b) Create a DECterm window by choosing the UTCterm option. When
the window is created enter the UTC command DIPM, preceded by
the '-' prompt, and with the same intersection SCN.
(b) On a DEC VT terminal or IBM PC compatible terminal running
under the CTERM terminal emulator, enter the same command.
(a) to (c) open windows in the MMI screen with the DIPM display.
(d) shows a DIPM display with the same information and time as the
above windows.
Eliminate one of the windows a) or b) above, which are identical. In each
of the remaining windows enter the same commands to alter the
information displayed. The commands are described in the Operator
Handbook. i.e. 'P' and 'T', 'U' and 'L', 'D
Identical information is displayed in all the windows and DEC VT or PC
terminal.
Permit the DIPM displays to run for a number of minutes and monitor the
output on the different screens.
All the screens display the same information and the time is updated in all
windows within a fraction of a second.
T10-00700
Purpose:
Action:
SYSTEST.DOC
To test the compatibility of other UTC commands.
Perform tests in a similar fashion to T10-00600 for the following UTC
information and monitoring commands, using combinations of permitted
and incorrect parameters and testing the facilities described in the
Operators Handbook, reference :
(a) OVRB - note that the same SCN cannot be called on more than one
screen at a time. Either use different SCNs or test the same SCN on
one screen/window at a time.
(a) MONI
(a) LOTU
Issue 11.0 Page 10-3
System Test Specification for a VAX/VMS UTC System
Result:
Action:
Result:
SYSTEST.DOC
666/YJ/16940/000
(a) XLOT
(a) DLOT
(a) LOGO
(a) LSTF
(a) LSTA
(a) LIPT
(a) SEES
(a) SEED
(a) WHAT
(a) INFO
(a) LSTG
(a) LSTS
(a) OUTT
(a) EDAV
(a) LJNL
(a) LTEC
(a) FLOW
(a) OPFD
(a) WEEK
(a) LSTD
(a) LJNL
(a) WAVC
Identical information is displayed in all the windows and DEC VT or PC
terminal.
Repeat the first test for some of the following fault-related commands,
noting down the commands and parameters used in the tests :
(a) FLTY
(a) XFLT
(a) IHRW
(a) XIHR
(a) IHPC
(a) XIHP
(a) ISOL
(a) XISO
(a) DISO
(a) XDIS
(a) DEMA
(a) XDEM
Identical information is displayed in all the windows and DEC VT or PC
terminal.
Issue 11.0 Page 10-4
System Test Specification for a VAX/VMS UTC System
Action:
Result:
Action:
Result:
Action:
Result:
Action:
SYSTEST.DOC
666/YJ/16940/000
Repeat the first test for some of the following access commands, noting
down the commands and parameters used in the tests :
(a) AUDI
(a) XAUD
(a) MAIN
(a) OFFC
(a) DIAL
(a) XDIA
(a) TROF
(a) XTRO
(a) XSPO
(a) PRIN
(a) XPRI
Identical information is displayed in all the windows and DEC VT or PC
terminal.
Repeat the first test for some of the following controller commands,
noting down the commands and parameters used in the tests :
(a) FALL
(a) XFAL
(a) LLNK
(a) XLLN
(a) DIMO
(a) XDIM
(a) SLOF
(a) XSLO
Identical information is displayed in all the windows and DEC VT or PC
terminal.
Repeat the first test for some of the following miscellaneous equipment
commands, noting down the commands and parameters used in the tests :
(a) TIDL
(a) XTID
(a) CSFY
(a) XCSF
(a) SFNO
(a) XSFN
(a) XSST
(a) STCS
Identical information is displayed in all the windows and DEC VT or PC
terminal.
Repeat the first test for some of the following car park and sign
commands, noting down the commands and parameters used in the tests :
Issue 11.0 Page 10-5
System Test Specification for a VAX/VMS UTC System
Result:
Action:
Result:
Purpose:
Action:
Result:
Action:
SYSTEST.DOC
666/YJ/16940/000
(a) OPEN
(a) CLOS
(a) CPOC
(a) CARP
(a) SIGO
(a) SSTO
(a) XSST
(a) STCS
Identical information is displayed in all the windows and DEC VT or PC
terminal.
Repeat the first test for some of the following plan, APS, diversion and
green wave commands, noting down the commands and parameters used
in the tests :
(a) PLAN
(a) XPLA
(a) GWAV
(a) XGWA
(a) TAPS
(a) SAPS
(a) XAPS
(a) INTD
(a) XINT
Identical information is displayed in all the windows and DEC VT or PC
terminal.
To test the compatibility of UTC management commands.
Perform tests in a similar fashion to T10-00600 for the following UTC
management commands, using combinations of permitted and incorrect
parameters :
(a) DBAS - only one can be performed at a time
(a) UPDA - test each window/screen individually
(a) TUAC
(a) PPRP
(a) KILL
(a) OJNL
(a) CJNL
(a) TIME
(a) DATE
Identical information is displayed in all the windows and DEC VT or PC
terminal.
Repeat the first test for some of the following UTC CHAN and VALU
parameters, noting down the commands and parameters used in the tests :
Issue 11.0 Page 10-6
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
(a) AFDI
(a) AFIT
(a) CAPA
(a) FDTH
(a) GRET
(a) VEHC
(a) CACP
(a) CASP
(a) SMOO
(a) VLAG
(a) GWPL
(a) CQT1
(a) CQT2
(a) CQT3
(a) CQT4
Identical information is displayed in all the windows and DEC VT or PC
terminal.
T10-00800
Purpose:
To test the compatibility of SCOOT commands.
Action: Perform tests in a similar fashion to T10-00600 for the following SCOOT
commands, using combinations of permitted and incorrect parameters :
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
Action:
SYSTEST.DOC
SCOO
XSCO
NODT
RUBA
LUBA
LMON
LVAN
RFTD
(a) NFTD
(a) VEGA
(a) GULP
(a) MESS
(a) XMES
(a) REIN
Repeat for some of the following SCOOT CHAN and VALU parameters,
noting down the commands and parameters used in the tests :
(a) ADJU
(a) CDSL
Issue 11.0 Page 10-7
System Test Specification for a VAX/VMS UTC System
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
(a)
SYSTEST.DOC
666/YJ/16940/000
ETHR
SETH
SPEN
TRAF
SLAM
CLAM
GSMO
CYOS
FCYT
FDWN
IRCT
MAXC
MINC
TREN
CYFC
FORC
MFBI
OFST
SPLT
TPLN
DEFS
BIAS
CGIF
CGOF
CGWT
CLIF
DFOF
DGEL
ELAG
GGAI
INCY
INMQ
INOF
JNYT
MDSL
QCMQ
SLAG
SMIN
STOC
Issue 11.0 Page 10-8
System Test Specification for a VAX/VMS UTC System
Result:
SYSTEST.DOC
666/YJ/16940/000
(a) DETU
(a) DSTS
(a) SMAN
Identical information is displayed in all the windows and DEC VT or PC
terminal.
Issue 11.0 Page 10-9
System Test Specification for a VAX/VMS UTC System
11.
666/YJ/16940/000
GRAPHICS EDITOR TEST DEFINITIONS
SYSTEST.DOC
Issue 11.0 Page 11-1
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
12.
HARDWARE AND POWER FAILURE TEST DEFINITIONS
12.1
System Re-start after H/W Crash
T12-00100
Reference : VAX SRS 9.3.3
Purpose:
Action:
Result:
Action:
Result:
12.2
To confirm that the control system shuts down safely following a
computer processor failure.
(a)Simulate a hardware failure on a traffic computer by pressing the front
panel 'halt' button to stop the processor.
(b) Use the instation test set to monitor the modem output on one
address.
(a) The transmission hardware will detect the fault without delay and
isolate the outstation equipment from the computer. The bits on the
monitored address will all go low. The LEDs on the modem boards
will become steady indicating that no data is being transmitted.
(b) The terminals will cease updating and accepting commands and will
not output any message.
(c) The relevant watchdog lamp on the main alarm panel will light up.
Release the halt button by pressing it again. Re-start the traffic computer
by pressing the 'restart' button on the front panel.
The traffic system will restart.
Disc Failure
Reference : VAX SRS 9.3.3
T12-00200
Purpose:
Action:
Result:
Action:
To confirm that system will fail if the system disc is unavailable.
Make the system disc unavailable by depressing the 'ready' button on the
front panel.
The system may continue to operate for a time until VMS requires disc
access at which point the system will crash.
Halt the processor from the front panel. Release the disc ready button to
enable the disc and restart the system from the front panel.
T12-00300
Purpose:
Action:
SYSTEST.DOC
To simulate the effect on the system of a complete failure of a Winchester
disc requiring recovery from backup tapes.
(a) Shut down the UTC system by using the KILL command.
(b) Purge the files.
(b) Press the write protect button, on the winchester disc.
(b) Run the BACKUP utility as described in the operators manual (ref ),
to save the traffic system programs and data from the Winchester to
TK70 tapes.
Issue 11.0 Page 12-1
System Test Specification for a VAX/VMS UTC System
Result:
12.3
666/YJ/16940/000
(b) Use the VMS INITIALIZE command to reformat the disc and hence
erase its contents.
(b) Press the "re-start" button on the computer and confirm that the
system will not run.
(b) Run the BACKUP utility from TK70, to restore the traffic system
from TK70 tape back to the disc.
(b) Start up the traffic system, and verify that the system is operational.
The relevant traffic computer will run correctly, although some transient
data, such as detector counts may have been lost for the period when the
computer was unavailable.
System Re-start after Power Failure
Reference : MCE 0360C paragraph 4.2.10 VAX SRS 9.4.3
T12-00400
Purpose:
Action:
Result:
12.4
To prove the recovery of the system after a power failure.
Note the current state of the system with respect to operational plans and
controller states.
Switch off the power to the traffic computer.
After a period of 5 minutes restore the power.
The VMS re-boot program is invoked and the traffic system is re-started
automatically.
When the system has reached a quiescent state, check the the operational
plans are the same as those before the power failure, allowing for the
command journal and any timetable changes.
System Re-start after Power Failure - Networked Systems
T12-00500
Purpose:
Action:
Result:
SYSTEST.DOC
To prove the recovery of the system after a power failure.
Repeat the above test by switching off the power to all computers in the
networked system, and then restoring the power to all at the same time.
All units recover to their previous state, with a links up, within 15 minutes
of the power restore.
Issue 11.0 Page 12-2
System Test Specification for a VAX/VMS UTC System
13.
NETWORKED COMPUTERS TEST DEFINITIONS
13.1
Introduction
666/YJ/16940/000
These tests should be executed with as many TCCs configured into the system as
there are computers available. At some stage it will be necessary to execute some, at
all, of the tests with a TMC and eight TCCs i.e. the maximum system size. The data
item, MAX_LICENSED-CPU, should be set to the number of computers available.
13.2
Networking Facilities
13.2.1
TMC Functions
Reference : VAX SRS 2.10.1
T13-00100
13.2.2
Purpose:
Action:
To demonstrate the UTC functions available on a TMC.
Use TDU commands to display the active and installed processes.
Result:
There are no Traffic Control processes active/installed on the TMC.
TCC Functions
Reference : VAX SRS 2.10.2 (1)
T13-00200
Purpose:
Action:
Result:
13.2.3
To demonstrate the UTC functions available on a TCC.
At a terminal connected to a TCC enter each of the following commands :
DBAS, GENP, TUAC
All the commands are rejected as they are only available on the TMC.
TCC Offline
Reference : VAX SRS 2.10.8 (4)
T13-00300
Purpose:
Action:
Result:
13.2.4
To demonstrate that operator commands are rejected if the TCC
controlling the specified equipment is offline.
Halt TCCA or disconnect it from the Ethernet. At terminals connected to
TCCB and the TMC enter some or all of the following operator command
specifying equipment in sub areas and regions controlled by TCCB :
PLAN VEGA TDDD SCOO LSTS DISO
DEMA IHRW DIMO
The commands are all rejected with the error message "No computer
available to process the command.
Connectivity and Computer Re-Start
SYSTEST.DOC
Issue 11.0 Page 13-1
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
Reference : VAX SRS 2.10.4, 2.10.13
This test demonstrates the operation of the system when one or more
Control or Management computers are off-line or disconnected from the
network.
T13-00400
Purpose:
Action:
Result:
Action:
Result:
To demonstrate the effect of a TCC being removed from the network.
With all TCCs and the TMC on-line switch off the power to TCCA.
A message is written to the system log that TCCA is no longer on-line.
The status line display on all 'live' terminals shows that the link to TCCA
is down.
Enter listing commands with wild-card parameters covering equipment
controlled by all TCCs. Enter command to change the state of equipment
on TCCA.
All commands involving equipment controlled by TCCs produce the
message "No computer available to process this command".
T13-00500
Purpose:
Action:
Result:
To show that updates made on the TMC whilst a TCC is off-line are
available to the TCC on re-start.
Ensure that the TMC and all TCCs are on-line and connected to the
network.
Enter a KILL command for TCCA and wait until the system is offline.
On the TMC :
- create and edit GENPIC picture files,
- edit and prepare UTC/SCOOT data,
- edit and prepare plan data,
- edit and prepare timetable data,
- edit and prepare message data,
- edit and prepare terminal and user data.
Enter an UPDA command and wait for the TMC and all TCCs (except
TCCA) to re-start. Confirm that the new data is available on all
computers.
Re-boot TCCA
When TCCA is re-booted the new data files are transferred from the TMC
and TCCA re-starts with all the latest data.
T13-00600
Purpose:
Action:
SYSTEST.DOC
To show that updates to system-wide data made in a TCC whilst another
TCC is off-line are available to the TCC on re-start.
Ensure that the TMC and all TCCs are on-line and connected to the
network.
Enter a KILL command for TCCA and wait until the system is offline.
Issue 11.0 Page 13-2
System Test Specification for a VAX/VMS UTC System
Result:
666/YJ/16940/000
On TCCB enter commands to modify CAST data ie ICAS, DCAS,
NCAS.
Confirm that the modified CAST data is available on the TMC and on all
other TCCs (except TCCA).
Re-boot TCCA.
When TCCA is re-booted the new CAST data is transferred from the
TMC and TCCA re-starts with all the latest data.
T13-00700
Purpose:
Action:
Result:
To show that updates made on the TMC whilst a TCC is disconnected
from the network are available to the TCC on re-start.
Ensure that the TMC and all TCCs are on-line and connected to the
network.
Disconnect TCCA from the network
On the TMC :
- create and edit GENPIC picture files,
- edit and prepare UTC/SCOOT data,
- edit and prepare plan data,
- edit and prepare timetable data,
- edit and prepare message data,
- edit and prepare terminal and user data.
Enter an UPDA command and wait for the TMC and all TCCs (except
TCCA) to re-start. Confirm that the new data is available on all
computers.
Reconnect TCCA.
When TCCA is re-connected a message is output stating that there is a
data mis-match between TCCA and the rest of the system. The new data
files are transferred from the TMC and are used when TCCA re-starts.
T13-00800
Purpose:
Action:
Result:
SYSTEST.DOC
To show that updates to system-wide data made on a TCC whilst another
TCC is disconnected from the network are available to that TCC when it
is re-connected.
Ensure that the TMC and all TCCs are on-line and connected to the
network.
Disconnect TCCA from the network
On TCCB enter commands to modify CAST data ie ICAS, DCAS,
NCAS.
Confirm that the modified CAST data is available on the TMC and on all
other TCCs (except TCCA).
When TCCA is reconnected the new CAST data is transferred rom the
TMC and TCCA has access to all the latest data.
Issue 11.0 Page 13-3
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T13-00900
Purpose:
Action:
Result:
13.2.5
To show that the TMC may be stopped and restarted without any adverse
effect on th system.
Ensure that the TMC and all TCCs are on-line and connected to the
network.
At the TMC enter a KILL command and wait for the TMC to go offline.
All commands are accepted and actioned.
Synchronisation
T13-01000
Purpose:
Action:
Result:
13.2.6
To demonstrate the synchronisation of fixed time plans on equipment
controlled by different TCCs.
Start DIPM displays for two different controllers on two different TCCs,
each having the same cycle time and operating a fixed time plan.
The offset within the cycle of each controller, as shown on the display, is
the same showing that controllers are synchronised over the whole
system.
Data Archiving
Reference : VAX SRS 2.10.8, SSDD 2.11
Purpose:
To demonstrate that local data files are transferred from a TCC to the
TMC at pre-defined times.
T13-01100
Action:
SYSTEST.DOC
For a selected TCC note the created/modified dates of the baseline data
files,
UTC_OUTPUT_:[BASELINE]BASELINE.ARE,
UTC_OUTPUT_:[BASELINE]BASELINE.REG,
UTC_OUTPUT_:[BASELINE]BASELINE.NOD,
UTC_OUTPUT_:[BASELINE]BASELINE.LNK,
UTC_OUTPUT_:[BASELINE]BASELINE.STG,
UTC_OUTPUT_:[BASELINE]BASELINE.DET,
on the local TCC and those of the corresponding TMC files,
UTC_OUTPUT_:[BASELINE]BASELINE.ARE.TCn,
UTC_OUTPUT_:[BASELINE]BASELINE.REG.TCn,
UTC_OUTPUT_:[BASELINE]BASELINE.NOD.TCn,
UTC_OUTPUT_:[BASELINE]BASELINE.LNK.TCn,
UTC_OUTPUT_:[BASELINE]BASELINE.STG.TCn,
UTC_OUTPUT_:[BASELINE]BASELINE.DET.TCn.
Enter a RUBA command for equipment controlled by the TCC, specifying
Area, region, Node, Link, Stage and detector parameters.
Issue 11.0 Page 13-4
System Test Specification for a VAX/VMS UTC System
Result:
Action:
Result:
666/YJ/16940/000
The local files are modified immediately, but not the TMC files.
Wait for 15 (b) minutes without entering any more RUBA commands.
If no further RUBA commands have been entered for a period of 15 (B)
minutes the TCC files are transferred to the TMC.
T13-01200
Action:
Result:
Action:
Result:
For a selected TCC note the created/modified date of the LPU
Conversion data file,
UTC_OUTPUT_:[LPU_CONV_DATA]LPUCONV.DAT,
on the local TCC and that of the corresponding TMC file,
UTC_OUTPUT_:[LPU_CONV_DATA]LPUCONV.TCn.
Enter an ASLD command.
The local file is modified immediately, but not the TMC file.
Wait for 5 minutes without entering any more ASLD commands.
If no further ASLD commands have been entered for a period of 5 (B)
minutes the TCC file is transferred to the TMC.
T13-01300
Action:
Result:
Repeat the above test using a SSSU command in place of the ASLD
command.
The TCC file is transferred to the TMC as soon as the SCOOT survey is
finished.
T13-01400
Action:
Result:
For a selected TCC note the created/modified date of the TDD picture
file,
UTC_OUTPUT_:[TDD]DISTIM.DAT,
on local TCC and that of the corresponding TNC file,
UTC_OUTPUT_:[TDD]DISTIM.TCn.
Enter a TDDD command and create a new diagram.
The local file is modified immediately and transferred to the TMC.
T13-01500
Action:
Result:
SYSTEST.DOC
For a selected TCC note the created/modified date of the Car Park
Weighted Averages file,
UTC_OUTPUT_:[CPR_AVERAGES]CRPAVS.DAT
on the local TCC and that of the corresponding TMC file,
UTC_OUTPUT_:[CRP_AVERAGES]CRPAVS.TCn
Wait until next hour boundary.
The local file is updated and then transferred to the TMC.
Issue 11.0 Page 13-5
System Test Specification for a VAX/VMS UTC System
666/YJ/16940/000
T13-01600
Action:
Result:
For a selected TCC note the created/modified date of the SCOOT Cyclic
Detector Checks file,
UTC_OUTPUT_:[CDC]CDCDATA.DAT
on the local TCC and that of the corresponding TMC file,
UTC_OUTPUT_:[CDC]CDCDATA.TCn
Enter a CHDC command and wait for the accumulation period to be
competed ie one hour.
The local file is updated and then transferred to the TMC.
T13-01700
Action:
Result:
SYSTEST.DOC
For a selected TCC (TCCA) observe the detector data files in directory,
UTC_OUTPUT_:[DETECTORS.SOURCE]
on the TCC and in directory,
UTC_OUTPUT_:[DETECTORS.DAY]
on the TMC, at 23:59 (or similar).
Wait until 00:30
The TCC file DDxxxxxx.TCA has been transferred to the TMC and
stored in the DAY sub-directory. Any daily files in the TCC older than the
configurable storage time (eg 7 days) have been deleted. The weekly file
on the TMC,
UTC_OUTPUT_:[DETECTORS.WEEK]DWxxxxxx.TMC
has been updated with data from the latest daily file.
Issue 11.0 Page 13-6