top - download
⟦eab66e578⟧ Wang Wps File
Length: 34401 (0x8661)
Types: Wang Wps File
Notes: CPS/210/SYS/0001
Names: »0601A «
Derivation
└─⟦468384ecf⟧ Bits:30006005 8" Wang WCS floppy, CR 0040A
└─ ⟦this⟧ »0601A «
WangText
…02…CPS/210/SYS/0001
…02…820115…02……02…
CAMPS SYSTEM REQUIREMENTS
…02…ISSUE 3.5…02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
3.5 DESIGN AND CONSTRUCTION REQUIREMENTS .....
274
3.5.1 General ..............................
274
3.5.1.1 Equipment Produced by CR .........
274
3.5.1.2 Equipment Produced by Subcontrac-
tor ..............................
274
3.5.1.3 Products From Other Suppliers ....
275
3.5.2 Special Requirements for the CAMPS
System ...............................
275
3.5.2.1 Environmental Testing ............
275
3.5.2.2 Utility Outlet Sockets ...........
276
3.5.2.3 Materials ........................
276
3.5.2.4 Interchangeability ...............
276
3.5.2.5 Bench Handling ...................
277
3.5.2.6 Cover Plates .....................
277
3.5.2.7 Cabling and Fittings .............
277
3.5.2.8 Flux and Soldering ...............
278
3.5.2.8.1 Flux .........................
278
3.5.2.8.2 Soldering ....................
278
3.5.2.9 Ventilation and Cooling ..........
278
3.5.2.10 Electromagnetic Compatibility ....
279
3.5.2.11 Test and Repair ..................
279
3.5.2.11.1 Accessibility ...............
279
3.5.2.11.2 Test Points .................
280
3.5.2.12 Consumable Parts ................
280
3.5.2.13 Safety ...........................
280
3.5.2.13.1 Regulations .................
280
3.5.2.13.2 Personnel Safety ............
280
3.5.2.13.3 Equipment Safety ............
281
3.5.2.13.4 Grounding ...................
282
3.5.2.14 Nameplates and Product Marking ..
282
3.5.2.15 Controls ........................
283
3.5.2.16 Acoustic Noise ..................
283
3.5.11 Software Engineering Requirements ...
283
3.5.11.1 Systems Principles ..............
283
3.5.11.2 System Software .................
285
3.5.11.3 Application Software ............
287
3.5.11.3.1 Implementation ..............
288
3.5.11.4 Software Maintenance and Modifi-
cation ...........................
290
3.5.11.5 Support Software .................
290
3.5.11.5.1 CSSI Resident Support
Software .....................
291
3.5.11.5.2 Factory Test Software ........
292
3.5.11.6 Software Integrity ...............
293
3.5 D̲E̲S̲I̲G̲N̲ ̲A̲N̲D̲ ̲C̲O̲N̲S̲T̲R̲U̲C̲T̲I̲O̲N̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
3.5.1 G̲e̲n̲e̲r̲a̲l̲
The following section defines the general design and
construction requirements applicable to CAMPS.
3.5.1.1 E̲q̲u̲i̲p̲m̲e̲n̲t̲ ̲P̲r̲o̲d̲u̲c̲e̲d̲ ̲b̲y̲ ̲C̲h̲r̲i̲s̲t̲i̲a̲n̲ ̲R̲o̲v̲s̲i̲n̲g̲ ̲A̲/̲S̲
a) The CR produced equipment is designed and produced
according to CR standard.
b) This standard is based on the following NATO standards:
1) NGTS 45 General Manufacturing Requirements.
2) NGTS 50 Design, Construction and Installation
Criteria for electrical and electronic
material.
3) NGTS 40 Environmental Test Methods.
c) CR standards are currently updated in order to
incorporate improvements in technology.
d) Maintenance of CR standards are performed under
configuration management and supervised by CRs
Quality Assurance department.
e) All standards and their maintenance may be inspected
by customers Quality Assurance Representative.
3.5.1.2 E̲q̲u̲i̲p̲m̲e̲n̲t̲ ̲P̲r̲o̲d̲u̲c̲e̲d̲ ̲b̲y̲ ̲S̲u̲b̲c̲o̲n̲t̲r̲a̲c̲t̲o̲r̲s̲
a) The sub-contractor supplying equipment to CAMPS
may propose the use of other standards, on condition
that adequate documentary evidence is provided
to demonstrate that the alternative standards are
at least equivalent in scope and depth of coverage
to this requirement section.
b) These proposals, if made, will take the form of
formal contract change proposals. They will not
be undertaken prior to contracting officer approval.
If the contracting officer does not approve, such
proposals shall not be implemented.
3.5.1.3 P̲r̲o̲d̲u̲c̲t̲s̲ ̲F̲r̲o̲m̲ ̲O̲t̲h̲e̲r̲ ̲S̲u̲p̲p̲l̲i̲e̲r̲s̲
a) Equipment supplied by OEMs not quoted as sub-contractors
- i.e. standard equipment from stock - is chosen
in accordance with the requirements stated compared
to the specification given by the OEMs.
b) Quality Assurance shall check and ensure that the
quality of such equipment fulfill all requirements
in respect of:
1) performance (in accordance with specifications
given by manufacturer)
2) durability
3) stability under extreme working condition
4) maintainability
3.5.2 S̲p̲e̲c̲i̲a̲l̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲ ̲f̲o̲r̲ ̲t̲h̲e̲ ̲C̲A̲M̲P̲S̲ ̲S̲y̲s̲t̲e̲m̲
a) In this section is mentioned a number of requirements
special for the CAMPS project.
b) In case of conflict with the standards mentioned
in 3.5.1 above, the following standards shall supersede.
3.5.2.1 E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲a̲l̲ ̲T̲e̲s̲t̲i̲n̲g̲
The methods of NGTS 40 shall be used for environmental
testing where they are applicable to CAMPS requirements.
As testing limits shall be used the appropriate environmental
characteristic from section 3.4.3.
3.5.2.2 U̲t̲i̲l̲i̲t̲y̲ ̲O̲u̲t̲l̲e̲t̲ ̲S̲o̲c̲k̲e̲t̲s̲
Utility outlet sockets for the operation of test equipment
etc. shall be located in close proximity to all major
racks or cabinets. Installation of utility outlets
will be the responsibility of purchaser.
3.5.2.3 M̲a̲t̲e̲r̲i̲a̲l̲s̲
Materials used for encapsulation and embedment shall
be selected for their electrical, operational, environmental
and storage characteristics. Hard curing compounds
to hold replaceable parts are prohibited. (Parts soldered
to terminals, printed wiring boards etc. are not considered
replaceable in this context).
3.5.2.4 I̲n̲t̲e̲r̲c̲h̲a̲n̲g̲e̲a̲b̲i̲l̲i̲t̲y̲
a) Modular hardware construction should be used wherever
feasible.
b) The items shall be designed to use the minimum
number practicable of the different types of electrical
cable, connectors, component and accessories.
c) Electrically identical units, assemblies, subassemblies
and replaceable parts shall be physically interchangeable
without modification of such items or of the equipment.
d) Interchangeable items shall be as defined in specifications,
drawings, and/or documentation to permit their
installation as interchangeable units, assemblies,
subassemblies, and parts without regard to the
source of manufacture or supply.
e) Provision shall be made for design tolerances such
that items having the dimensions and characteristics
permitted by the item specification may be used
as replacement without selection or departure from
the specified equipment performance.
3.5.2.5 B̲e̲n̲c̲h̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
Smaller assemblies and sub-assemblies normally subject
to bench repair shall be capable of withstanding being
dropped onto a hard surface on all faces from a 30…0e…o…0f…
angle, using any one edge of the unit as a pivot, without
any physical, electrical or electronic damage.
3.5.2.6 C̲o̲v̲e̲r̲ ̲P̲l̲a̲t̲e̲s̲
Cover plates shall have a minimum of fasteners consistent
with normal mechanical strength requirements. All such
fasteners should preferably be of the "captive" type.
3.5.2.7 C̲a̲b̲l̲i̲n̲g̲ ̲a̲n̲d̲ ̲F̲i̲t̲t̲i̲n̲g̲s̲
For wiring and cabling the following shall apply:
a) Where inter-connecting cabling between assemblies
is run in steel conduit or in shielded cables,
electrical continuity of the conduit or shielding,
as appropriate, shall be ensured to permit the
correct grounding.
b) Wiring shall be identified by colour coding, numbering,
or by other feasible means such as marking of terminals
at both ends of lead. All wires shall carry corresponding
identification numbers at each end. Colour coding
for chassis wiring shall be comforming to good
engineering practice.
c) Where bus bars are used for interconnection between
assemblies and subassemblies they may be colour
coded to permit quick identification.
d) Cables and wires or similar connectors shall carry
a CR parts number. These numbers shall be the same
numbers as given in the as-built drawings and in
the maintenance and operating manuals.
3.5.2.8 F̲l̲u̲x̲ ̲a̲n̲d̲ ̲S̲o̲l̲d̲e̲r̲i̲n̲g̲
3.5.2.8.1 F̲l̲u̲x̲
Rosin fluxes conforming to recommended engineering
practices shall be used for making electrical electronic
connections. For fluxing purposes, a soldered joint
the functions of which are both a mechanical and an
electrical connection (for example in grounding applications
through a chassis) shall be considered an electrical
connection.
3.5.2.8.2 S̲o̲l̲d̲e̲r̲i̲n̲g̲
All soldered connections shall be clean and smooth
in appearance. Sufficient solder shall be used to ensure
a continuous strong concave fillet feathered into the
base metals. Flux or other foreign residue must be
removed. The insulation of soldered wires shall not
show damage from the heat of the soldering operation.
Discolouration is permitted, but not charring, cracking,
decomposition and distortion.
3.5.2.9 V̲e̲n̲t̲i̲l̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲C̲o̲o̲l̲i̲n̲g̲
a) Intake cooling air, if considered necessary, shall
be filtered such that the pressure within the associated
cabinet is higher than the ambient pressure outside.
The cooling air should preferably be exhausted
to the atmosphere at the top of the cabinet.
b) Resonance effects and vibrations because of the
ventilation and cooling shall not cause any deterioration
of equipment performance.
c) The distributed cooling systems in the CR produced
equipment may be supplied with air filters of a
nominal thickness of 2.5 cm.
3.5.2.10 E̲l̲e̲c̲t̲r̲o̲m̲a̲g̲n̲e̲t̲i̲c̲ ̲C̲o̲m̲p̲a̲t̲i̲b̲i̲l̲i̲t̲y̲
a) When installed the electromagnetic radiation of
the equipment shall comply with the COMSEC requirements
as described in AMSG 720 A and in para. 3.4.5 of
this specification.
b) When installed the different units, assemblies,
and subassemblies shall be able to perform as intended
in the presence of electromagnetic radiation from
other parts of CAMPS. Furthermore, they shall be
able to function in a radiation environment from
other system within the limits specified in 3.5.2.10.a
above.
3.5.2.11 T̲e̲s̲t̲ ̲a̲n̲d̲ ̲R̲e̲p̲a̲i̲r̲
3.5.2.11.1 A̲c̲c̲e̲s̲s̲i̲b̲i̲l̲i̲t̲y̲
a) Connections to parts inside removable container
shall be allowed to run through the container by
threading provided the container has a very low
failure rate.
b) Only chassis and assemblies contained within cabinets
or consoles shall be mounted on withdrawal slides
if they require removal or replacement during normal
maintenance and repair actions.
c) Plug-in boards and modules shall be provided with
a suitable removal tool, if they are not equipped
with build-in ejectors/extractors.
3.5.2.11.2 T̲e̲s̲t̲p̲o̲i̲n̲t̲s̲
a) Testjacks can be of the banana plug type.
b) Test points/tracing points for monitoring voltage/currents
and measuring/injecting signals/wave forms shall
only be provided to the extent they form part of
the maintenance/repair concept.
3.5.2.12 C̲o̲n̲s̲u̲m̲a̲b̲l̲e̲ ̲P̲a̲r̲t̲s̲ ̲
All fluids, life limited parts, and any other comsumable
parts required for continuous operation of the equipment
shall be kept to a minimum both in number and quantities
required.
3.5.2.13 S̲a̲f̲e̲t̲y̲
All necessary safeguards shall be taken during the
design, development, production and installation of
the equipment to ensure safety of operating and maintenance
personnel from electrical and mechanical hazards.
3.5.2.13.1 R̲e̲g̲u̲l̲a̲t̲i̲o̲n̲s̲
a) The actual site installations in the different
host nations shall be made in accordance with the
appropriate National Safety Regulations of the
country concerned according to installation drawings
as approved by the purchases.
b) The equipment itself and its associated power cabling
shall comply with the National Safety Regulations
of the country of origin for the equipment.
3.5.2.13.2 P̲e̲r̲s̲o̲n̲n̲e̲l̲ ̲S̲a̲f̲e̲t̲y̲
a) Interlocks or key locks shall be incorporated where
appropriate to prevent any major assembly carrying
high tension voltages from being opened by unauthorised
personnel.
b) With the equipment assembled and set up for operation,
personnel shall be protected from contact with
potentials in excess of 30 volts to ground, chassis
or frame, including potentials or charged capacitors.
c) Relevant notice and markings on equipment or documents
are to be provided to draw the attention of operating
and maintenance personnel to points where dangerous
voltages may be encountered.
d) Where a voltage of 50 or more volts is exposed
during the maintenance activities a suitable warning
shall be provided. It should be made according
to the following principles:
1) "DANGER (xxx) VOLTS WHEN COVER REMOVED" (in
aluminium or white lettering l.5 cm high on
a red background) where (xxx) is the nominal
voltage.
2) "DANGER HIGH VOLTAGE (xxx) VOLTS" where (xxx)
is the nominal voltage.
3) "CAUTION (xxx) VOLTS. DISCONNECT POWER BEFORE
REMOVAL OF COVER" where (xxx) is the nominal
voltage.
3.5.2.13.3 E̲q̲u̲i̲p̲m̲e̲n̲t̲ ̲S̲a̲f̲e̲t̲y̲
a) Circuit breakers or switches which operate to make
or break AC power lines shall make or break all
conductors at the same time. The neutral wire in
three-phase circuits shall not pass through any
fuse.
b) Fuses and circuit breakers shall be provided within
the equipment as required for protection of the
equipment from damage due to overload. Each major
assembly shall be individually protected so that
a fault in one major assembly cannot damage any
other major assembly.
c) All fuses and circuit breakers should be located
such that they are readily accessible. Fuses shall
incorporate a visual system of failure indication.
3.5.2.13.4 G̲r̲o̲u̲n̲d̲i̲n̲g̲
a) The grounding system shall provide effective protection
for personnel and material against insulation defects.
It shall be arranged so that there are three separate
and isolated ground circuits, namely:
1) AC power neutral
2) Equipment frame ground
3) Signalling and control ground
b) The AC power neutral shall provide a return for
the primary current so that the equipment frame
ground is used only to establish a safety ground
and is not used as a normal current grounding element.
No place in the equipment or power filters shall
the AC power neutral be connected directly to equipment
frame ground.
c) All panels, drawers and other sub-assemblies, whether
fixed or removable, shall be fastened, or connected
to the associated frame, in a manner that ensures
they are securely grounded.
d) The signalling and control ground is to be routed
via the interconnecting wires and cables as appropriate.
3.5.2.14 N̲a̲m̲e̲p̲l̲a̲t̲e̲s̲ ̲a̲n̲d̲ ̲P̲r̲o̲d̲u̲c̲t̲ ̲M̲a̲r̲k̲i̲n̲g̲
A nameplate giving the serial number, SHAPE contract
number, date of manufacture, manufacturers name and
address and principal characteristics, where appropriate,
shall be attached in a prominent position on each major
assembly.
3.5.2.15 C̲o̲n̲t̲r̲o̲l̲s̲
The type and layout of controls shall be such as to
avoid an interruption of service or change of operational
mode as a result of accidental bumping, touching or
catching of clothing.
3.5.2.16 A̲c̲o̲u̲s̲t̲i̲c̲ ̲N̲o̲i̲s̲e̲
The maximum sound level due to noise emitted from the
equipment shall be less than 70 dB (A) when measured
under free field conditions by a precision sound level
meter located at a point 2 meters distant from the
noise source, and at the height at which the maximum
reading of the meter is obtained. The measuring instrument
shall be in accordance with IEC publication 179 second
edition 1973.
The contents of 3.5.3 to 3.5.10 of issue 1 is contained
3.5.1 and 3.5.2 in sunsequent issues.
3.5.11 S̲o̲f̲t̲w̲a̲r̲e̲ ̲E̲n̲g̲i̲n̲e̲e̲r̲i̲n̲g̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
3.5.11.1 S̲y̲s̲t̲e̲m̲s̲ ̲P̲r̲i̲n̲c̲i̲p̲l̲e̲s̲
Fundamental properties of the software which shall
be considered in depth during the design, development
and production are its quality, integrity and flexibility.
The software shall meet the operational requirements
together with the requirements for ease of maintenance
and modification. The software shall be structured
in a clearly identifiable hierarchical way to ensure
that the integrity and reliability requirements of
this specification are met. At the same time it shall
be readily expandable and must provide the facilities
specified below in such a way that the tasks of future
modification, error elimination and maintenance are
facilitated.
a) The software shall be provided as a complete, well
structured system consisting of three s̲u̲b̲-̲s̲y̲s̲t̲e̲m̲s̲:̲
1) The system software comprises all the software
(i.e. the program code, permanent data, pre-set
work space, etc.) which is required to be resident
in or accessible to the system during its operation.
The system software shall provide the services
to the applications software.
2) The support software comprises all off-line
software required to support the implementation,
modification, testing and maintenance of the
operational system.
3) The applications software is defined as the
software providing the functional capabilities
called for in this specification.
b) The software, in conjunction with the hardware,
shall be designed to detect and limit the effect
of hardware faults which occur in the system. Upon
detection of the fault, action should be taken
to:
1) Report the fault.
2) Optimize the remaining system operational capabilities
while the fault persists.
c) The system design shall seek to maintain maximum
isolation and independence between units of all
types during program design and implementation
and during on-line operation of the system. Facilities
shall be provided by the hardware/software structure
to enforce the isolation between modules during
system run-time such as detection of program access
to an incorrect area of memory, or attempts to
make use of a machine facility to which it should
not have access.
d) In the construction of program code, clarity of
meaning shall be a major consideration. When writing
the program code comments shall be inserted to
aid comprehension and improve the readability.
e) It is mandatory that no instruction and constants
of the system software are modified during execution.
If it is done the circumstances must be well documented
and the program listing must contain complete cross-referencing
comments. In the applications software the use
of this technique shall be unacceptable.
f) The data areas of a module shall be logically contiguous
and all exchange of data between different modules
shall take place either through well defined shared
data areas or by a parameter passing.
g) The minimum program language requirements for the
software is an assembly language providing relocatable
code, symbolic addressing, and a sub-routine or
procedure concept. A macro facility is desirable
but not mandatory. The use of a high level language
is highly desirable for application programs and
desirable for system software.
h) The software shall be carefully documented in parallel
to the design during the production phase. The
documentation shall form part of the deliverable
software package and conform to the software documentation
standards specified elsewhere in this document.
3.5.11.2 S̲y̲s̲t̲e̲m̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
a) The system software facilities must allow the applications
software to be structured in terms of functional
modules.
b) The system software shall include the following
general facilities in some form:
1) Multi-programming and scheduling at run time,
i.e. the provision of a set of processes or
equivalent entities as the basic entities to
which processor time, store and other system
resources are allocated at run time.
2) Store management, i.e. facilites for permanently
or dynamically allocating areas of core store
and backing store to processes or their equivalents
in a secure manner; for initializing data areas
securely when required; and for obtaining permanent
or dynamic access to such areas when required;
for ensuring the secure duplication of data
when required.
3) Device control and interrupt response, i.e.
standardized interfaces between hardware devices
(including traffic channels) and applications
software, such that the system software is
wholly responsible for the immediate control
of hardware device interfaces.
4) Inter-process interfaces, i.e. facilities for
securely passing activations and data between
processes over standardized interfaces.
5) Fault handling, e.e. facilities for the detection,
location and containment of software and hardware
faults: for ensuring the secure duplication
of data when required by applications or system
software in case of fault conditions; for maintaining
system operation and data integrity during
fault incidents (in conjunction with applications
software); and for providing adequate reports
of fault incidents for subsequent diagnosis
and correction of the faults.
c) The system software shall be implemented as a well-structured
suite of code and data modules incorporating sufficient
hardware protection and software checking to ensure
that:
1) The system software itself can achieve and
maintain the status of high integrity, trusted
code with respect to the applications software.
2) The structures present in the applications
software are maintained and enforced at all
stages of development, integration and run
time operation.
Preferably, the system software shall reside
in "read-only" memory.
d) The support element of the system software must
allow the secure preparation, editing, compilation,
linkage, module testing, integration, realtime
testing, system testing and incorporation into
run time operation of new or modified source code
modules. Any disturbance caused to the operational
system by each of these procedures should be minimal
and well defined. The support software shall include
facilites for maintaining and accessing any required
off-line libraries of procedures, data declarations,
macros, etc.
e) The use of the word secure in section 3.5.11.2
refer to requirements stated in section 3.4.5.7
and 3.5.11.
3.5.11.3 A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The application software shall be provided as well-structured
modules. The application software is to provide, in
conjunction with the system software, all the functional
capabilities called for in this specification. The
application software for each installation shall be
identical or, as a minimum, generated from a common
library of program routines.
a) O̲v̲e̲r̲a̲l̲l̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲. The applications code and data
shall be structured in a hierarchical manner into
a well defined set of functional modules and units
at different functional levels and with distinct
data areas for each transaction processed by the
system.
The ways in which the various applications software
modules are multi-programmed at run-time (i.e.
recursive/re-entry or "fresh copy", etc.) shall
be clearly defined.
Communication between modules shall wherever practicable,
take place via standardised system facilities such
as interprocess calls and procedure calls. The
sharing of data areas between two or more units
or modules handling different transactions shall
be avoided and the situations in which such sharing
takes place shall be clearly defined. It shall
be a design aim to ensure that whenever data is
transmitted across an inter-module interface, the
data is in a compact, well defined form.
Sufficient validity checks must be applied at appropriate
points in the applications software and/or system
software at compile time, and/or runtime to ensure
that the integrity requirements will be met, attention
being paid to maintaining efficiency.
The process of integrating a module into the system
shall not require recompilation of the other elements
of the system.
b) M̲o̲d̲u̲l̲e̲s̲ ̲o̲f̲ ̲A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲. It shall be a
design aim that each functional module of applications
software should satisfy the following criteria:
1) Provide a well defined function or group of
functions at some hierarchical level in the
software system, i.e. can be implemented as
self-contained programming task given a functional
specification, interface specifications of
any external modules and data structures to
which it must refer.
2) Has well defined, compact input and output
interfaces.
3) Can be separately compiled/assembled.
4) Hides its decisions from other modules (e.g.
it allows access to internal data structures
only through one access mechanism provided
by the module).
3.5.11.3.1 I̲m̲p̲l̲e̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
a) U̲s̲e̲ ̲o̲f̲ ̲L̲a̲n̲g̲u̲a̲g̲e̲s̲
If a high level language is used, the use of assembly
language in the applications software shall be
confined to small well defined units and where
practicable embodied either in macros or library
procedures. In any case the use of assembly/machine
code should be restricted to the following circumstances:
1) Interfacing to system software calls.
2) Providing realtime critical facilities where
code produced by the high level language compiler
is too inefficient.
3) Implementing essential facilities not provided
by the high level language or the rest of the
system.
b) P̲r̲o̲g̲r̲a̲m̲s̲
It is mandatory that programme instructions shall
not be modified during run time and that within
each applications software module the programme
code and constants should be segregated from the
modifiable data. It is highly desirable, that,
wherever practicable, each segment of applications
code or data should be accessed and protected by
appropriate hardware facilities at run time. The
direct use of or access to absolute store addresses
by applications programmes should be reduced to
a minimum. Synchronization processes shall take
place at clearly defined points in the programme.
To maintain security and accountability, reservation
and release of shared resources, such as data areas,
must only take place at clearly defined points
in the applications programme.
c) M̲o̲d̲u̲l̲e̲ ̲S̲i̲z̲e̲ ̲C̲o̲n̲s̲t̲r̲a̲i̲n̲t̲s̲
The function of each module should be readily understandable.
As a rule, no module shall contain more than 250
source statements unless approved by CR QA internally
and notification to SHAPE. It shall be a design
aim to limit the number of modules, exceeding the
250 line limit to 5% of the modules. Each module
must implement a CAMPS function or function(s)
as specified in this document. Any requirement
which would lead to implementation of a module
unable to satisfy this constraint must be sub-divided
into more manageable units. It is essential that
any constraints imposed on the module size by compilers,
loading methods, store management arrangements,
etc., must be clearly defined and adequate methods
for dealing with these constraints must be defined
and implemented.
d) M̲a̲n̲/̲M̲a̲c̲h̲i̲n̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
In addition to the levels of command and control
specified elsewhere in this specification for supervision/operation,
and control for engineers limited facilities shall
be provided at operational sites for control of
system software. Provisions shall be made for dead
start, warm start, and cutover to an updated version
of the control software, the latter without affecting
the operational user facilities. In addition, the
supervisor shall have facilites to record the
current state of the machine for diagnostic purposes
on a loadable medium in a secure manner, e.g.,
raw dumps on a hardcopy printer are not acceptable.
This facility shall be available without affecting
user operational facilities.
3.5.11.4 S̲o̲f̲t̲w̲a̲r̲e̲ ̲M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲a̲n̲d̲ ̲M̲o̲d̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The systems software shall be structured in a way that
will permit the addition or deletion of applications
units throughout the operational life of the system.
The degree of flexibility should at least be sufficient,
to allow:
a) Changes in format, new formats, changes in format
tolerances, improvements in man/machine interfaces,
and the accommodation of more CAMPS hardware.
b) Processing information which may be subject to
change, for example, specific character strings
such as security examining groups, which are searched
for during analysis, should wherever possible,
be held in specific data tables rather than embodied
in the program source code in order to preclude
unnecessary compilation/assembly of program modules.
3.5.11.5 S̲u̲p̲p̲o̲r̲t̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
a) The support software includes all off-line software
required to support the implementation, modification
testing and maintenance of the on-line system.
All support software shall be available at the
CAMPS software support installation (CSSI), while
only that related to installation of changes and
assisting in fault finding is necessary at the
operational sites.
b) Any disturbance caused to the operational system
by use of the support software shall be minimal
and well defined. New code and data shall be transferred
to an operational installation on a machine readable
medium generated at the CSSI.
3.5.11.5.1 C̲S̲S̲I̲ ̲R̲e̲s̲i̲d̲e̲n̲t̲ ̲S̲u̲p̲p̲o̲r̲t̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
At the CSSI site the support software shall as a minimum
accommodate the following functions:
a) Compilation/assembly shall be accomplished on the
CSSI system. Appropriate diagnostics shall be provided
when compilation/assembly cannot be carried out
successfully. Compilers/assemblers must make adequate
provision for insertion of programmers' comments.
b) Library maintenance - routines for the creation
and maintenance of the programs and other libraries
as applicable.
c) Data conversion shall be made for the transcription
and re-formatting of data from disc to floppy disc
and vice versa.
d) A debugger shall be provided at the CSSI. This
debugger shall together with a facility for simulation
of modules under test aid the programmer in testing.
The debugger shall support insertion of breakpoints,
dumps of registers and memory. Further the following
shall be supported from the terminal conducting
the test.
1) Display of memory or register dumps on the
console, VDU, and/or medium speed printer.
2) Updating the contents of main memory areas
and registers.
3) Transcription of the main memory contents to
or from backing store.
4) Loading of programs to be tested.
5) Program initiation and termination.
6) Deletion of main memory contents.
7) Recording of software modules being accessed
during test.
e) Loaders, editors and other utility programs which
are necessary to facilitate the compilation assembly
and testing of program changes in an efficient
and timely manner.
f) A cross reference listing tool which allows the
determination of which modules might be affected
by a programme change.
g) At the CSSI site a test and integration facility
shall be provided which in conjunction with other
CR supplied equipment can run the software module
under test as if it was part of an operational
CAMPS.
3.5.11.5.2 F̲a̲c̲t̲o̲r̲y̲ ̲T̲e̲s̲t̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
a) At the CR factory a factory-test simulator shall
be provided to run the software under test emulating
the operational CAMPS environment.
b) The standard test environment shall be provided
by simulation of pseudorandom operational environment
in the factory such that:
1) All input channels are loaded to at least 0.5
Erlangs for low speed channels and 0.3 Erlangs
for medium speed channels.
2) The traffic input on the channels shall be
representative of the message traffic which
will be encountered in an operational environment,
including traffic corrupted by transmission
media failure and noise.
3) The following traffic sources shall generate
simulated traffic in accordance with the throughput
requirements in section 3.4.1.2.1.
- Message preparation facilities.
- Traffic exchanged with ACE CCIS facilities.
- Traffic exchanged with SCARS II.
- Traffic associated with message service
and operator distribution control facilities.
c) The simulation shall be performed under the restraints
defined below:
1) All of the following stores are loaded to at
least 0.75 of the design capacity.
- In-transit store for messages being processed.
- Queue storage.
- Message on-line storage.
2) At least 0.9 of all available output channels
shall be open.
3) All operator positions shall be manned so that:
- action can be taken with respect to situations
which arise in the equipment. The action
taken shall be that appropriate to an operational
environment.
- all available commands are used to exercise
the equipment.
3.5.11.6 S̲o̲f̲t̲w̲a̲r̲e̲ ̲I̲n̲t̲e̲g̲r̲i̲t̲y̲
a) Re-loadable copies of all the software in binary
form shall be held on backing store (e.g. disc,
magnetic tape on-line to the system) to permit
replacement of the software if it is suspected
of being corrupt.
b) Each module should contain credibility check to
contain the effects of corrupt or inaccurate data
to the extent this does not introduce redundant
processing which will decrease the system throughput.
c) It shall be a design aim that wherever possible
the consequence of a single software fault incident
will not affect more than one transaction. The
detection of an inconsistency indicating a fault
shall initiate a report and the re-processing from
a validated check-point in an attempt to recover
with a minimum of discontinuity. Only after further
failures should major recovery or operator intervention
action be invoked.
