top - download
⟦fbcb04d57⟧ Wang Wps File
Length: 18360 (0x47b8)
Types: Wang Wps File
Notes: CPS/SDS/001
Names: »1358A «
Derivation
└─⟦27ec2f823⟧ Bits:30006056 8" Wang WCS floppy, CR 0088A
└─ ⟦this⟧ »1358A «
WangText
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
4.5 CAMPS SYSTEM SUPPORT FUNCTIONS ...........
198
4.5.1 System Support Functions only at
Factory ..............................
198
4.5.1.1 Hardware Test Package ............
199
4.5.1.2 Standard Software Test Package ...
201
4.5.1.3 System Software Test Package .....
203
4.5.1.4 Factory Test Simulator Configura-
tion (TDS) .......................
206
4.5.2 System Support Functions at the CSSI
Site, but not at all Sites ...........
210
4.5.2.1 Software Maintenance .............
213
4.5.2.2 Data Base Generation .............
218
4.5.2.3 System Generation ................
222
4.5.2.4 Configuration Control ............
224
4.5.3 System Support Functions at all Sites
224
4.5.3.1 M&D Software .....................
224
4.5.3.2 Off-Line Utilities ...............
224
4.5.4 Generalized Test Monitor .............
225
4.5 C̲A̲M̲P̲S̲ ̲S̲Y̲S̲T̲E̲M̲ ̲S̲U̲P̲P̲O̲R̲T̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲S̲
The CAMPS System Support Functions are non-operational
tools used in the development, test, and verification
of the operational CAMPS Hardware and Software.
They are grouped in:
System Support Functions only at factory (described
in 4.5.1).
System Support Functions at CSSI site, but not at all
sites (4.5.2).
System Support Functions at all sites (4.5.3).
Common for these is a generalized test monitor described
in 4.5.4.
4.5.1 S̲y̲s̲t̲e̲m̲ ̲S̲u̲p̲p̲o̲r̲t̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲ ̲o̲n̲l̲y̲ ̲a̲t̲ ̲F̲a̲c̲t̲o̲r̲y̲
The System Support Functions at Factory are tools developed
to:
- test the CAMPS hardware configuration
- Hardware Test Package
- test the CAMPS modifications to standard system
software
- Standard Software Test Package
- test the CAMPS defined system software
- System Software Test Package
- test performance of the integrated CAMPS hardware
and software
- Factory Test Simulator
The development tools for application and system software
are identical to those described for the CSSI site
below except for a Factory based Z80 micro processor
Software/firmware development and test equipment.
4.5.1.1 H̲a̲r̲d̲w̲a̲r̲e̲ ̲T̲e̲s̲t̲ ̲P̲a̲c̲k̲a̲g̲e̲
The Hardware Test Package consists of software to support
the integration of DSMT hardware and hardware for site
1-16.
The structure of the software is shown in fig. 4.5.1.1-1.
For each HW module a Test Module is defined. The Test
Module is capable of execution of all specified functions
of the HW module. Test modules return their results
to a calling test program.
Test modules are integrated into testers.
Testers implement sequences of tests. Input is obtained
from disc and VDU, output is made on disc, line printer
and VDU.
Testers are executed under the test monitor (sec. 4.5.4).
They may be executed one by one (interactive or automatic
testers) or in sequences (automatic testers only).
Figure 4.5.1.1-1…01…HARDWARE TEST PACKAGE STRUCTURE
4.5.1.2 S̲t̲a̲n̲d̲a̲r̲d̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲T̲e̲s̲t̲ ̲P̲a̲c̲k̲a̲g̲e̲
The Standard Software Test Package consists of software
to support the test of standard DAMOS software i.e.:
Kernel
I/O Control (minus Device and Line Control)
Storage and File Management
The structure of the software is shown in figure 4.5.1.2-1.
For each SW module a Test Module is defined. The Test
Module is capable of causing the execution of all specified
single functions of the SW module. Test of sequences
(e.g. send + receive in process communication) involves
execution of more than one Test Module.
Test modules are integrated into testers. Testers consist
of one or more processes (in DAMOS sense) in order
to exercise the software components.
Tester are executed under the test monitor (see 4.5.4).
They may be executed one by one (interactive or automatic
testers) or in sequences (automatic testers only).
Figure 4.5.1.2-1…01…Standard Software Test Package Structure
4.5.1.3 S̲y̲s̲t̲e̲m̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲T̲e̲s̲t̲ ̲P̲a̲c̲k̲a̲g̲e̲
The System Software Test Package consists of software
to support the test of CAMPS extensions to system software
i.e.:
I/O Control (Device and Line Control)
CAMPS System Functions
SSC Software
The structure of the software is shown in figure 4.5.1.3-1
and 2.
Figure 4.5.1.3-1 shows the configuration for test of
CAMPS System Functions and device and Line Control.
For the device and Line Control test a line test interface
is implemented transporting the data to/from the closed
loop connected line.
Figure 4.5.1.3-1…01…System Software Test Package Structure (-SSC Part)
Figure 4.5.1.3-2…01…System Software Test Package Structure of SSC Part
4.5.1.4 F̲a̲c̲t̲o̲r̲y̲ ̲T̲e̲s̲t̲ ̲S̲i̲m̲u̲l̲a̲t̲o̲r̲ ̲C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲(̲T̲D̲S̲)̲
The Factory Test Simulator Configuration consists of
software and hardware to support test of the operational
CAMPS. The test is performed by emulating the operational
CAMPS environment.
The configuration is shown in figure 4.5.1.4-1. The
Test Drive System (TDS) emulates the terminal and external
interfaces of CAMPS.
The TDS is used in 3 phases (see figure 4.5.1.4-2).
P̲r̲e̲-̲T̲e̲s̲t̲ Prepare test sequences and analyse by script
compiler
T̲e̲s̲t̲ Execute test with logged output
P̲o̲s̲t̲-̲T̲e̲s̲t̲ Print out of selected test results
Details of the On-Line Test Controller is shown in
figure 4.5.1.4-3.
Figure 4.5.1.4-1…01…Factory Test Simulator Configuration
Figure 4.5.1.4-2…01…Test Drive System Use
Figure 4.5.1.4-3…01…TDS On-Line Controller
4.5.2 S̲y̲s̲t̲e̲m̲ ̲S̲u̲p̲p̲o̲r̲t̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲ ̲a̲t̲ ̲C̲S̲S̲I̲ ̲S̲i̲t̲e̲,̲ ̲b̲u̲t̲ ̲n̲o̲t̲ ̲a̲t̲ ̲a̲l̲l̲
̲S̲i̲t̲e̲s̲.̲
At the CSSI site development and test of all application
software is supported. The configuration is shown in
figure 4.5.2-1 for hardware and figure 4.5.2-2 for
software.
The Terminal Operating System controls the execution
of processes in the CSSI development PU. At start up
and for resource allocation the TOS is commanded from
the system console, where load and execution of processes
in the variable configuration may be commanded from
either the VDU or the System Console.
The configurations in question are:
a) Software Maintenance with
1) Software Development
2) Software Unit Test
3) Software Operational Test
b) Data Base Generation
c) System Generation
d) Configuration Control
Figure 4.5.2-1…01…CSSI Development Configuration
Figure 4.5.2-2…01…CSSI Software Configuration
4.5.2.1 S̲o̲f̲t̲w̲a̲r̲e̲ ̲M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲
The Software Maintenance Function consists of 3 major
tasks:
- Software Development
- Software Unit Tests
- Software Operational Tests
The Software Development configuration is presented
in figure 4.5.2.1-1.
It consists of:
- An editor manipulated from a VDU for modification
of and introduction of new software
- A compiler directed by edited compiler directives.
Files containing standard lay out of tables, data
elements, error codes etc. are merged-in at compile
time.
- A linker resolving external references for all
modules including definition of segmentation for
shared modules. Link is directed by the VDU controlled
link directive file.
- A Test System Generator being able to generate
load modules for Operational Software for Unit
Test, Operational Software for Operational Test
and testers for Unit Tests and Operational Tests.
All output produced by the Software Development Configuration
is kept in Listing Libraries with hardcopies upon request.
The Source is kept in 3 levels of libraries (figure
4.5.2.1-2) one for each of
Released Modules
Tested Modules
Development Modules
Released Modules are modules having passed a formal
test. They are placed in a library of software under
configuration control.
Figure 4.5.2.1-1…01…CSSI Software Development
Tested Modules are modules having passed a package
test conducted by the team responsible for software
development. They are kept in a library for tested
modules.
Development modules are administrated by individuals
performing software development. They are kept as development
libraries.
Software unit test is performed in the configuration
shown in figure 4.5.2.1-3.
The TESTER1 to TESTERN functions as environment applications.
The TESTER1 may via the DEBUGGER insert breakpoints
in the Software under Test. Furthermore, the TESTER1
to N may access disk files for input and output and
system software for operational interfaces to the software
under test.
Software operational test is performed in a configuration
similar to the one shown in figure 4.5.2.1-3. The "Software
under test" is an integrated package and the Testers
must be so designed that this integrated package can
interface only via operational interfaces. The Debugger
is in this case only used as trouble shooter.
Figure 4.5.2.1-2…01…Software Libraries
Figure 4.5.2.1-3…01…Unit Test Configuration
4.5.2.2 D̲a̲t̲a̲ ̲B̲a̲s̲e̲ ̲G̲e̲n̲e̲r̲a̲t̲i̲o̲n̲
The initial data base for each site is generated at
the CSSI site (or initially at factory).
Data base generation is at two levels. First level
is a generation of all common data for all sites. This
is shown in figure 4.5.2.2-1. The common data base
generation consists of Table Generator, VDU Format
Generator and Predefined Message Generator.
The Table Generator operates on a card formatted input.
At the CSSI site the input is from VDU, at factory
it may be from punched cards as well. The Table Generator
outputs tables in the format used in the operational
software, maintenance SW being able to modify and print
tables as at operational sites.
The VDU Format Generator supports generation of VDU
formats for use by the Format Handler of the IO control
SW.
The Predefined Message Generator supports generation
of predefined messages for use by operational software.
Figure 4.5.2.2-1…01…Data Base Generation Common System Data
The Common System Data generated are:
PLA table
AIG and AG table
SIC table (without SDLs)
VDU formats
Predefined Messages
Second level of Database generation is generation of
Site Specific Data partly by adaptation of Common System
Data. Figure 4.5.2.2-2.
The PLA table, the AIG table and the SIC tables are
copied to an intermediate version for update by table
maintenance software (similar to on-line SW).
The RI table, SDL table, SCD table, user profiles and
terminal profiles are input via the Input file for
the Table generator. Table generation is performed
into the above intermediate version.
The Configuration Table Generator generates tables
with definitions of
External Channels
Terminals
Other peripherals
Memory Administration
Disk Storage Administration
Software Configuration
VDU Formats and Predefined Messages are copied from
the Common Data.
Figure 4.5.2.2-2…01…Data Base Generation Site Specific Data
4.5.2.3 S̲y̲s̲t̲e̲m̲ ̲G̲e̲n̲e̲r̲a̲t̲i̲o̲n̲
System Generation is performed on basis of the software
released as described in 4.5.2.1, on basis of the Data
base generated for the sites and on basis of Factory
produced system software. Figure 4.5.2.3-1 gives an
overview.
The application software is selected from the total
set of application software.
The System Software is configured to accept the specified
(software configuration) application software. The
System Software consists of the Processor Unit System
Software and the LTU Down-line- Loaded Micro Processor
Software.
The Site Specific Data are copied without processing.
Output from System Generation is input for the Configuration
Control.
Figure 4.5.2.3-1…01…System Generation site Generation
4.5.2.4 C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲
The Configuration Control Software controls a log of
the history of each site in terms of systems generated.
For each system track is kept of which versions of
the application and system software has been used in
the generation.
4.5.3 S̲y̲s̲t̲e̲m̲ ̲S̲u̲p̲p̲o̲r̲t̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲ ̲a̲t̲ ̲a̲l̲l̲ ̲S̲i̲t̲e̲s̲
At all sites the non-active processor units may be
configured into an off-line utility configuration and
into a maintenance and diagnostics (M&D) configuration
(when errors have occurred).
4.5.3.1 M̲&̲D̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The M&D configuration is not a configuration in a software
sense. It represents a set of loadable, executable
software each appropriate for diagnostic of single
or group of hardware modules. To prevent interruption
of operations the hardware tested by this means is
isolated from the operational hardware. See also section
4.3.
4.5.3.2 O̲f̲f̲-̲L̲i̲n̲e̲ ̲U̲t̲i̲l̲i̲t̲i̲e̲s̲
The off-line utility configuration is similar to the
CSSI Software configuration figure 4.5.2-2 except that
all communication is performed via the watchdog and
not with a separate VDU/line printer.
The utility configuration is used to copy files (programs
and data) to and from the Floppy Disc, to perform print
out of memory dump file and print out of performance
data/trace file collected on-line.
4.5.4 G̲e̲n̲e̲r̲a̲l̲i̲z̲e̲d̲ ̲T̲e̲s̲t̲ ̲M̲o̲n̲i̲t̲o̲r̲
The Generalized Test Monitor controls the execution
of automated and manual tests as well as the set up
of a test and print out of the test results.
Test software is developed using the software maintenance
as described in 4.5.2.1. Test data is produced by the
editor, test sequences are produced by the editor and
verified by the test sequence compiler (Refer fig.
4.5.4-1).
Tests are organized in libraries one for each test.
The library contains names of files used
- TESTDEF definition of test
- System files (in copy) for use in test
- One file for each of possible parallel executed
test sequences SEQ....
- One file for each of the load modules for TESTERS,
TST....
- Names of files used as data input for TESTERS.
- Names of files with expected output from tests.
- Name of library of executed test data. Each of
these libraries identifies one set of output plus
a log file for the test.
Figure 4.5.4-1…01…Generalized Test Monitor Library Structure
This structure allows to
- Use the same TESTER in various tests with the same
or with different test data
- Specify dynamic load and execution of TESTERS
- Execute in parallel TESTERS with internal synchronization
- Record output data from each pass (to be deleted
after proper verification)
The Test Monitor controls only the configuration and
execution of tests, the logical contents of the tests
resides fully within the TESTERS and the test data.
The Test Monitor controls the tests in this rather
rigid manner in order to be able to trace the result
after execution of a test.
Tests may be fully automatic or interactive/automatic.
It is possible interactively to specify test steps
to be executed and it is possible to select parts of
the automatic sequences.
Tests may run on disk-file input/output only or may
include interactive input and operator verification
of output.
In order to allow complete documentation of tests desired
input, expected output is presented for the operator
by the TESTERS when interactive tests are conducted.
The TESTDEFinition consists of control commands for
sequences. This includes commands for load of testers
and execution of sequences (parallel or in chain).
Sequences define execution of steps for one Tester
(each Tester is subdivided into subtests executed in
steps) and synchronization of sequences (signal to
other sequence, wait for other sequence).
Testers, test data, and test results are kept in 3
levels of libraries corresponding to individual responsibility,
development team responsibility and under configuration
control. This corresponds to the levels of control
on the software (figure 4.5.2.1-2) and allows a controlled
execution of operational test, because the test procedure
is approved and under configuration control.
