top - download
⟦0d8a5e8bc⟧ Wang Wps File
Length: 8186 (0x1ffa)
Types: Wang Wps File
Notes: Map. Perfor.Req.to Sub.sy
Names: »0122A «
Derivation
└─⟦2c0571bd0⟧ Bits:30005816 8" Wang WCS floppy, CR 0005A
└─ ⟦this⟧ »0122A «
WangText
…02…CPS/TCN/0013
…02…19800801…02……02…#
MAPPING OF PERFORMANCE REQUIREMENTS
TO SUBSYSTEMS…02……02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 INTRODUCTION .................................
2 PERFORMANCE REQUIREMENTS .....................
3 MAPPING OF REQUIREMENTS ......................
3.1 EQUIPMENT AVAILABILITY ...................
3.2 TRAFFIC THROUGPUT ........................
3.3 SYSTEM RESPONSE TIMES ....................
3.4 SYSTEM OPERATIONAL INTEGRITY .............
3.5 SYSTEM REQUIREMENTS RELATED TO 240 HOURS
VERIFICATION TEST ........................
3.6 SYSTEM REQUIREMENTS RELATED TO 60 DAYS
VERIFICATION TEST ........................
1̲ ̲ ̲I̲N̲T̲R̲O̲D̲U̲C̲T̲I̲O̲N̲
The approach is described as follows: The relevant
performance requirements as found in CPS/210/SYS/0001
will be listed.
It is then attempted to map the requirements to subsystems.
Major subsystems are:
- hardware (H/W)
- firmware (F/W)
- software (S/W)
2̲ ̲ ̲P̲E̲R̲F̲O̲R̲M̲A̲N̲C̲E̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
Performance requirements may be listed as follows:
- Equipment availability
- traffic throughput
- system response times
- system operational integrity
- system requirements related to 240 hours verification
test.
- Software Requirements related to 60 days verification
test
3̲ ̲ ̲M̲A̲P̲P̲I̲N̲G̲ ̲O̲F̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
An attempt will be made to map performance requirements
to specific modules.
A specification of performance requirements implies
a specification of functional requirements as well.
3.1 E̲Q̲U̲I̲P̲M̲E̲N̲T̲ ̲A̲V̲A̲I̲L̲A̲B̲I̲L̲I̲T̲Y̲
These requirements are first of all applicable to the
hardware subsystems and they shall be verified through
independent tests (sec. H/W verification test of section
4.2.1 of CPS/210/SYS/0001).
It is, however, necessary to provide the proper hardware,
firmware and software in order to locate errors and
initiate reports or actions necessary to fulfil the
overall availability requirements for the system.
Requirements for availability will thus reflect to
the error handling modules as a requirement for
- detection of error
- timely reporting or corrective action
In certain cases, like measuring temperature of environment,
detection and associated reporting (e.g. a bell) is
all hardware supported.
In many other cases the error may be detected by hardware
but the further handling is done by firmware and software.
One such case is detection of missing power to subsystems
and the involvement of the SSC where the necessary
evaluation shall be performed by firmware.
Requirements shall be defined for SSC firmware:
- types of procedures (error evaluation, reporting
and/or automatic action)
- timing performance
Firmware requirements shall also be defined for line
protocols in LTU's. Such requirements shall specifically
call for device status reporting and quote the necessary
timing requirements.
Status reporting referring to LTU's themselves shall
be considered an inherent part of requirements for
TDX and I/O channel protocol.
It is an additional requirement, however, that the
status reporting is supported to the level of application
software: Requirements shall be defined for TDX handlers
and I/O handlers (one for each device type).
Errors in a PU or in connection with one I/O bus may
require switchover to backup PU: Requirements shall
be defined for system and application software to support
check pointing between PU's for reestablishment of
terminal traffic situation to the extent this is not
covered by the TDX or I/O channel protocols (see section
3.2 for overall requirements). The system software
interface to application software shall be clearly
defined.
In short: A complete set of on line and off line diagnostic
modules shall be defined.
3.2 T̲R̲A̲F̲F̲I̲C̲ ̲T̲H̲R̲O̲U̲G̲H̲P̲U̲T̲
Requirements are in this case related to the CAMPS
system as a whole.
The best approach is probably to specify a reasonable
set of requirements for each type of TDX and I/O channel,
including all system software, firmware and hardware.
The application is then responsible for the final performance.
It is also a possibility to split the requirements
as follows
- Application software
- System software, including
- File Management System
- Terminal Handling System
- Device Handlers
- TDX and I/O channel hardware and firmware (incl.
LTU and DEVICE).
3.3 R̲E̲S̲P̲O̲N̲S̲E̲ ̲T̲I̲M̲E̲
Response time requirements may be applied in the same
manner as throughput requirements in section 3.2.
3.4 S̲Y̲S̲T̲E̲M̲ ̲O̲P̲E̲R̲A̲T̲I̲O̲N̲A̲L̲ ̲I̲N̲T̲E̲G̲R̲I̲T̲Y̲
Operational integrity is defined in section 3.2.8.3.b
of CPS/210/SYS/0001.
This requirement calls for error handling additional
to the error handling in section 3.1: In case of a
hardware ("equipment") error, error detection, reporting
and possible automatic actions shall be sufficient
to reestablish the system not only in a manner to secure
the system (=hardware) availability, but also to a
degree where loss or non recoverable destruction of
messages or internal transactions is practically impossible.
Further, messages may not be misdirected.
Consequently there is a requirement for
- definition of the error detection and the equipment
status reporting necessary to recover after an
equipment error
- definition of detailed requirements to the application
and system software: Integrity of operations as
defined in 3.2.8.3 shall be maintained during a
throughput load as defined in 3.4.1.2 of CPS/210/SYS/0001.
This overall requirement implies with close approximation
that n̲o̲ ̲m̲e̲s̲s̲a̲g̲e̲ ̲o̲r̲ ̲i̲n̲t̲e̲r̲n̲a̲l̲ ̲t̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ is
1. lost wholly or in part, or
2. misdirected, or
3. corrupted
as a result of an equipment error within a 60 days
period (see section 3.6)
It is recommended, however, that integrity of operation
is "proved on paper":
It shall be shown that error detection and status reporting
and associated error handling software is sufficient
to assure that single (multiple simultaneous errors
shall, as in case of equipment availability, not be
considered) equipment errors, giving rise to loss,
corruption or misdirection of messages or internal
transactions, do not occur more often than corresponding
to 1 out of 10…0e…7…0f… messages and transactions.
3.5 S̲Y̲S̲T̲E̲M̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲ ̲R̲E̲L̲A̲T̲E̲D̲ ̲T̲O̲ ̲2̲4̲0̲ ̲H̲O̲U̲R̲S̲ ̲V̲E̲R̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
̲T̲E̲S̲T̲.̲
A 240 hours (accumulated) software verification test
shall be conducted in plant.
Hardware errors due to equipment which does not comply
with availability requirements shall not influence
this test (test time during such errors shall not be
accounted for).
Section 4.2.2.2 of CPS/210/SYS/0001 defines the test
requirements: These requirements do not give rise to
any additional functional and performance requirements.
3.6 S̲O̲F̲T̲W̲A̲R̲E̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲ ̲R̲E̲L̲A̲T̲E̲D̲ ̲T̲O̲ ̲6̲0̲ ̲D̲A̲Y̲S̲ ̲V̲E̲R̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
̲T̲E̲S̲T̲.̲
Section 4.2.2.4 of CPS/210/SYS/0001 defines the requirements
for this test which shall be conducted on site (SHAPE
= first site only).
This test shall not depend on hardware which does not
comply with the availability requirements, i.e. the
test shall not be repeated in such cases (but obviously
interrupted).
A 60 days test will give an indication of integrity
of operation as discussed in section 3.4 but it is
not a proof (and an attempt to make it a proof is not
recommendable).
N̲o̲ ̲s̲o̲f̲t̲w̲a̲r̲e̲ ̲f̲a̲i̲l̲u̲r̲e̲ shall occur during the 60 days
test; the following definition of software failure
may be useful:
A software failure has occurred if the conditions for
integrity of operation (section 3.4) are not met (provided
equipment stays within required availability and only
single equipment errors occurs).
