groundwave emergency network: final report · program work element no no 6730 task no unit...
TRANSCRIPT
ESD-TR-89-193 MTR-104S4
Software Quality Assurance of the Groundwave Emergency Network:
Final Report
By
A. M. Haley T. E. Hutchinson
Mav 1989
Prepared for
Deputv Director for Strategic Command, Control & Communications Systems Program Office Electronic Systems Division
Air Force Systems Command United States Air Force
Hanscom Air Force Base, Massachusetts
AFGL/SULL Research Library Hanscom AFB, MA 01731-5000
Approved for public release; distribution unlimited.
Project No. 6730
Prepared b\
The MITRE Corporation Bedford, Massachusetts
Contract No. F19628-86-C-0001
AbAi\o- ~>
When U.S. Government drawings, specifications or other data are used for any purpose other than a definitely related government procure- ment operation, the government thereby incurs no responsibility nor any obligation whatsoever; and the fact that the government may have for- mulated, furnished, or in any way supplied the said drawings, specifications, or other data is not to be regarded by implication or otherwise as in any manner licensing the holder or any other person or conveying any rights or permis- sion to manufacture, use, or sell any patented invention that may in any way be related thereto.
Do not return this copy. Retain or destroy.
REVIEW AND APPROVAL
This technical report has been reviewed and is approved for publication.
LORELEI A. KREBS, Major, USAF Deputy Program Manager, GWEN
FOR THE COMMANDER
V^t£
GERALD G. IVERSON, Colonel, USAF Director, Strategic Command, Control & Communications Systems Program Office
UNCLASSIFIED SECURITY CLASSIFICATION OF THIS PAGE
REPORT DOCUMENTATION PAGE la REPORT SECURITY CLASSIFICATION
Unclassified lb RESTRICTIVE MARKINGS
2a. SECURITY CLASSIFICATION AUTHORITY
2b DECLASSIFICATION DOWNGRADING SCHEDULE
3 DISTRIBUTION/AVAILABILITY OF REPORT
Approved for public release; distribution unlimited.
4 PERFORMING ORGANIZATION REPORT NUMBER(S)
MTR-10454 ESD-TR-89-193
5 MONITORING ORGANIZATION REPORT NUMBER(S)
6a NAME OF PERFORMING ORGANIZATION
The MITRE Corporation
6b OFFICE SYMBOL (If applicable)
7a NAME OF MONITORING ORGANIZATION
6c. ADDRESS (City. State, and ZIP Code)
Burlington Road Bedford, MA 01730
7b ADDRESS (City. State, and ZIP Code)
3a. NAME OF FUNDING /SPONSORING ORGANIZATION
Deputy Director (continued)
8b OFFICE SYMBOL (If applicable)
ESD/SZG
9 PROCUREMENT INSTRUMENT IDENTIFICATION NUMBER
F19628-86-C-0001
8c. ADDRESS (City. State, and ZtP Code)
Electronic Systems Division, AFSC Hanscom AFB, MA 01731-5000
10 SOURCE OF FUNDING NUMBERS
PROGRAM ELEMENT NO
PROJECT NO
6730
TASK NO
WORK UNIT ACCESSION NO
n TITLE (include Security Classification)
Software Quality Assurance of the Groundwave Emergency Network: Final Report
'2 PERSONAL AUTHOR(S) Haley, A. M., Hutchinson, T. E.
13a TYPE OF REPORT Final
13b. TIME COVERED FROM TO
14 DATE OF REPORT (Year, Month, Day) 1989 May
15 PAGE COUNT 100
16 SUPPLEMENTARY NOTATION
' 1 COSATI CODES
FIELD GROUP SUB-GROUP
18 SUBJECT TERMS (Continue on reverse if necessary and identify by block number)
GWEN Software Quality Assurance Verification and Validation
19 ABSTRACT (Continue on reverse if necessary and identify by block number) MITRE carried out a Software Quality Assurance (SQA) effort for the Groundwave Emergency Network's Thin Line Connectivity Capability system during the early period of its development. The process included desktop analyses, simulations, and execution of the major portions of the software leading to formal qualification testing by the contractor. As a result, the contractor was alerted to potential omissions and incorrect implementations of the software, culminating in a final implementation that was es- sentially error-free. An important lesson learned from this type of effort is the need for early and thorough involvement of and interaction between contractor and SQA personnel.
20 DISTRIBUTION/AVAILABILITY OF ABSTRACT
D UNCLASSIFIED/UNLIMITED S SAME AS RPT D OTIC USERS
21 ABSTRACT SECURITY CLASSIFICATION
Unclassified 22a NAME OF RESPONSIBLE INDIVIDUAL
Pamela J. Cunha 22b TELEPHONE (Include Area Code)
(617) 271-2844 22c OFFICE SYMBOL
Mail Stop D13 DD FORM 1473, 84 MAR 83 APR edition may be used until exhausted
All other editions are obsolete SECURITY CLASSIFICATION OF 'HIS PAGE
UNCLASSIFIED
UNCLASSIFIED
8a. for Strategic Command, Control & Communications Systems Program Office
UNCLASSIFIED
ACKNOWLEDGMENTS
This document has been prepared by The MITRE Corporation under Project No. 6730, Contract No. F19628-86-C-0001. The contract is sponsored by the Electronic Systems Division, Air Force Systems Command, United States Air Force, Hanscom Air Force Base, Massachusetts 01731-5000.
The authors wish to acknowledge the following engineers for their contributions to the SQA effort: B. Barrett, D. Black, J. M. Cronin, M. V. Feeney, M. D. Gates, P. J. Nesky, and H. C. Reith, Jr.
We also wish to acknowledge the personnel of DSD Laboratories, Inc., of Wakefield, Massachusetts, and K. McClanahan, in particular, for their independent and timely assessment on the completeness and accuracy of GWEN software product specifications.
A special thanks to L. S. Meyer for her careful review and valuable suggestions, which greatly enhanced the content of this document, and to D. M. Reilly for sacrificing her personal time to provide word processing support.
111
EXECUTIVE SUMMARY
In 1984, MITRE initiated a Software Quality Assurance (SQA) effort for
the mission-critical software of the Groundwave Emergency Network.
Preliminary work, was directed toward establishing a secure area for the
"hands-on" examination of the various releases of the contractor-developed
software. This laboratory, equipped with a VAX-11/730, microprocessor
development workstations, and various tools for the examination of the
software, allowed us to expand the software monitoring work that would
normally have been conducted by MITRE.
The complement of GWEN software is comprised of 11 Computer Program
Configuration Items (CPCIs) totaling approximately 30,000 lines of code in
FORTRAN and 30,000 lines in Assembly language, and each line of code re-
ceived a detailed examination. All specifications and test procedures were
reviewed and a detailed desktop analysis of the code was performed for each
CPCI as it was received. Several of the CPCIs were executed first in a
microprocessor simulator residing on the VAX and then in emulation on the
microprocessor development workstations. A test node station, designed by
MITRE to be functionally identical to the node being built by the contrac-
tor, was constructed from commercial microprocessor components, and the
software was also executed on this station.
For each CPCI release, we prepared a detailed assessment of its com-
pleteness and correctness down to the module level and then used this
assessment to ensure schedule realism for the completion of software devel-
opment. Because we had first executed or examined the code for all of the
CPCIs, we were well prepared for the formal qualification testing of the
software, having a full understanding of the test procedures and the ex-
pected results.
After assuring ourselves of the functional completeness of the soft-
ware, we assessed the correctness and robustness of the algorithms. For
example, we verified that the timing for packet decryption and for packet
routing was sufficient and that the function could be accomplished within
the real-time constraints of the GUEN system. We also tested the external
interface portions of the algorithms to assure their correct operation. As
part of this process, we verified the correct implementation of the TRANSEC
algorithm and acquired a thorough understanding of the special use of the
KG-84A cryptographic device in the GWEN system.
In some cases, such as the implementation of virtual circuits in the
Network Control CPCI, we noted that early releases were incomplete, and
during subsequent formal qualification testing, we noted that several fea-
tures remained to be demonstrated or tested. After substantial work by the
prime contractor, these deficiencies were corrected in the final version of
the delivered software. During this SQA process, we discussed our findings
directly and informally with the individual software developers. This
direct and open communication allowed us to exchange information about the
software and assist the contractor in identifying any "bugs," or short-
falls, in functionality.
Table 10 presents, on a CPCI-by-CPCI basis, the major findings from
the desktop analyses of the software, while table 13 summarizes the memory
usage of each CPCI. During the SQA effort, we tracked the increase in
memory usage from release to release, and in several instances, we alerted
the contractor to usage that would exceed the specification. To remedy
this, the contractor used higher density memory boards for some CPCIs, and
applied for and was granted a waiver in other cases.
During our examination of the CPCI for the Maintenance Terminal that
is resident in an HP-85B desk-top computer, we noted that its use for sta-
tion initialization and synchronization is time-consuming. Since the
vi
hardware is no longer manufactured, we believe it should be replaced by a
newer, faster computer. As part of our SQA effort, we demonstrated the
rehosting of this software to such a computer.
We also considered converting the portion of GUEN software in Assembly
language, approximately 50 nercent, to an approved higher-order language.
Our analyses and calculations support such a conversion as both feasible
and desirable.
As a result of the SQA conducted on GWEN, it is clear that early in-
volvement of contractor, Government, and SQA personnel is essential. Of
course, the appropriate paragraphs covering these activities must be in-
cluded in the Statement of Work, to the contractor. The increased interac-
tion between the GWEN prime contractor and the MITRE SQA personnel proved
to be very beneficial, since it resulted in a final implementation of the
software that was essentially error-free.
VII
TABLE OF CONTENTS
SECTION PAGE
1. Introduction 1
1.1 Purpose 1 1.2 Components of GWEN 1
1.2.1 Relay Nodes 4 1.2.2 Input/Output Stations 4 1.2.3 Receive-Only Stations 5 1.2.4 GWEN Maintenance Notification Center 5 1.2.5 TRANSEC Rekey Station 6 1.2.6 Maintenance Terminal 6
1.3 GWEN Software 6
2. Software Quality Assurance 11
2.1 MITRE Software Quality Assurance Task 11 2.2 Software Quality Assurance Procedures 14 2.3 Software Quality Assurance Test Environment 16
2.3.1 Microprocessor Development System 16 2.3.2 VAX 11/730 Computer System 18 2.3.3 Software Quality Assurance Node Testbed 20 2.3.4 Software Quality Assurance Software Simulation 20
3. Software Analysis Methodologies and Summary of Findings .... 31
3.1 Software Evaluation and Findings 31 3.2 Software Trouble Reports 32
3.2.1 Activities 32 3.2.2 Summary of Findings 34
3.3 Desktop CPCI Audits 41 3.3.1 Activities 41 3.3.2 Summary of Findings 42
3.4 VAX and Microprocessor Development System Test Environment 50 3.4.1 Activities 50 3.4.2 Summary of Findings 57
3.5 MITRE Node Test Environment 65 3.5.1 Activities 65 3.5.2 Summary of Findings 67
3.6 Software Code Maintainability 69 3.6.1 Activities 69 3.6.2 Summary of Findings 69
IX
TABLE OF CONTENTS (Concluded)
SECTION PAGE
4. Conclusions and Recommendations 73
4.1 Conclusions 73 4.2 Recommendations 75
Glossary 77
Bibliography 81
LIST OF ILLUSTRATIONS
FIGURE PAGE
1 Network Components 3
2 GWEN Computer Software Specification Tree 10
3 SQA Process/Task Relationship 17
4 MITRE Software Quality Assurance Test Environment 19
5 GWEN Station Architecture 21
6 MITRE Node Configuration Chassis Interface Diagram 25
7 TRANSEC Configuration 26
8 CIL System Configuration 26
9 GWEN Software Quality Assurance Tasks 29
10 Software Trouble Report Data Sheet 33
11 Software Trouble Report Statistics 38
12 Software Trouble Reports by CPCI (as of 1 October 1987) 38
13 Compilation/Assembly of FORTRAN 8086 Code 52
14 Assembly of 8085/8086 Assembly Code 53
15 Microprocessor Development System Configuration 1 54
16 Microprocessor Development System Configuration 2 55
17 Microprocessor Development System Configuration 3 56
18 MITRE Node Hardware Configuration for HMI and NC CPCIs 66
XI
LIST OF TABLES
TABLE PAGE
1 GWEN CPCI Preliminary Statistics 9
2 SQA Task Efforts by CPCI 13
3 Chassis Construction: TRANSEC/NCP 22
4 Chassis Construction TIP I/O 23
5 Chassis Construction: BITE 24
6 Software Trouble Reports (April 1986 to October 1987) 36
7 Software Trouble Report Breakdown by CPCI (as of 1 October 1987). 37
8 Software Trouble Report Monthly Origination Basis (as of 1 October 1987) 39
9 Software Trouble Reports Rate of Closure (January 1985 - September 1987) 40
10 GWEN CPCI Desktop Audit Findings 43
11 Preliminary ROM and RAM Memory Sizing (April 1985) 58
12 GWEN Drawer Board Assignments, Memory Expansion 59
13 CPCI Memory Usage (November 1987) 60
14 ROM (Program) Memory Configuration (November 1987) 61
15 RAM (Data) Memory Configuration (November 1987) 62
XII
SECTION 1
INTRODUCTION
1.1 PURPOSE
This report describes the work performed during MITRE's Software
Quality Assurance (SQA) efforts on the Groundwave Emergency Network (GWEN)
software development and qualification. The objective of the SQA effort
was to provide a means of accomplishing in-depth testing and review of
GWEN's mission-critical software prior to formal qualification testing by
the contractor. The effort was initiated by MITRE's Survivable
Communications Department (D95) in 1984, and was completed in January 1988.
An introductory review of the GWEN network components and software is
followed by a description of the Software Quality Assurance facility
(section 2) that was established to support the SQA undertaking. Section 3
outlines the methods used to evaluate the software and summarizes the
findings. Conclusions and recommendations are given in section 4.
Detailed discussions on analysis and testing of individual computer program
configuration items are presented as appendices under separate cover.
1.2 COMPONENTS OF GWEN
The Groundwave Emergency Network is a packet-radio military communica-
tions system developed by the U.S. Air Force. Its mission is to provide
survivable and enduring communications for the command and control of stra-
tegic forces in the continental United States. Approximately 30 military
bases and eight command centers and sensors will be connected by the basic
Thin-Line Connectivity Capability (TLCC) network.
The system employs low-frequency (LF) groundwave propagation between
unmanned relay nodes (RNs) in a store-and-forward, packet-switched network.
In addition to the LF relay nodes, there are two other classes of stations
within GWEN: Input/Output (I/O) and Receive-Only (RO). The RO stations
receive LF signals directly from the relay nodes. The I/O stations are
connected to the two nearest RNs by two-way ultrahigh frequency (UHF) line-
of-sight radio links. Finally, two subsystems support GWEN operation: the
TRANSEC (Transmission Security) Rekey Station (TRS) and the GWEN Mainte-
nance Notification Center (GMNC). Both subsystems are connected to the
network through an I/O station at Headquarters, Strategic Air Command. The
TRS supports network security while the GMNC monitors network operations,
security, and maintenance status.
The Thin-Line Connectivity Capability is comprised of 56 relay nodes,
eight Input/Output stations, 30 receive-only stations, the GWEN Maintenance
Notification Center and the TRANSEC Rekey Station. For the Final Opera-
tional Capability (FOC), it is envisioned that there will be an increase in
the total number of RNs and I/O and RO stations which will enhance the net-
work's survivability and connectivity to all strategic forces. General
Electric/RCA (formerly RCA) Government Communications Systems is the prime
contractor for the TLCC phase of GWEN. Portions of the software were sub-
contracted to TRW. MITRE is the general system and Software Quality
Assurance engineer supporting the Electronic Systems Division, SZG in the
acquisition of GWEN.
The GWEN network components are presented in figure 1. As can be
seen, the relay nodes are the backbone of the GWEN packet network. The
message injection/reception and control stations comprise the message
network. The GWEN components are further described below.
Figure 1. Network Components
1.2.1 Relay Nodes
In TLCC there are two types of relay nodes: nonaccess RNs and access
RNs. Both types of relay nodes are located at unmanned, fixed sites.
Nonaccess RNs receive packets from other RNs via LF radio links and in turn
rebroadcast packets at LF to other RNs and to RO stations located within
their areas of propagation. The LF portion of the relay nodes operates in
a half-duplex mode; i.e., the LF receivers are blocked when the LF trans-
mitters are active. LF signals transmitted from the RNs are broadcast at
2 kilowatts effective radiated power. They propagate using the groundwave,
which is dependent on ground conductivity, and are potentially receivable
by any correctly tuned receiver within the propagation distance. Access
RNs have the additional capability to receive messages from I/O stations
via UHF radio access links, to relay packets via LF radio links to other
RNs, and to then deliver the messages to the I/O stations via UHF radio
links. The UHF radio links operate in a full-duplex mode independent of
the LF half-duplex mode of operation.
1.2.2 Input/Output Stations
At I/O stations, authorized commanders can initiate critical messages
for transmission to other I/O and RO stations. Warning messages from sen-
sors are also originated at the I/O stations. At the I/O, Network Control
(NC) software converts the message into packets, determines the communica-
tions protocol, and TRANSEC-encrypts each packet. User data traffic in-
jected at the GVEN I/O station can consist of messages addressed to a
single I/O (point-to-point), to a group of I/Os (point-to-multipoint) or to
all I/Os and ROs (broadcast). The point-to-point/multipoint traffic among
I/Os is carried on virtual circuits employing hop-by-hop and end-to-end
acknowledgments along paths automatically established by the Network Con-
trol software. Messages using the virtual circuits can be of varying
lengths up to a maximum length of 880 characters (16 packets). The network
transports these messages in fixed-length "packets" of 644 bits. Broadcast
messages consist of a single packet only.
The critical messages can originate from sensor systems, from pro-
cessors of other systems connected to GWEN via the external interface ports
on the GWEN terminal at an I/O, or from manual inputs on keyboards of the
GWEN system. Messages received by the I/O stations are delivered to these
processors or are printed out for use by the GWEN operator. Conversational
messages may also be originated at the I/O stations' keyboards.
The data portion of each packet is COMSEC-encrypted at the source I/O
with a KG-84A and is not decrypted until it reaches its destination. Each
packet is also TRANSEC-encrypted by every I/O station and relay node before
it is transmitted/retransmitted.
1.2.3 Receive-Only Stations
The R0 station receives I/O station-originated messages from the RNs
over multiple LF links. The messages are printed out for use by the GWEN
RO operator. ROs receive broadcast messages only.
1.2.4 GWEN Maintenance Notification Center (GMNC)
The GMNC is a subsystem that supports GWEN operation. It is dependent
upon its colocated GWEN I/O station at HQ SAC for its message interface
with the GWEN network. The GMNC originates automated and manual messages
to monitor network performance. It also receives information from the sta-
tions and nodes on the status of security and physical conditions, subsys-
tem components, and maintenance actions. The GMNC is able to generate
statistical maintenance data and to monitor GWEN maintenance actions.
1.2.5 TRANSEC Rekey Station (TRS)
The TRS is also a support subsystem which is colocated at the HQ SAC
I/O station. The TRS is used for both local and remote "rekeying" of
TRANSEC encryption equipment at the GWEN nodes. The TRS software generates
and maintains cryptovariables used by the GWEN system, and delivers them to
the nodes and stations either by transmitting them over GWEN via the colo-
cated I/O station (remote rekeying) or by placing the cryptovariables in
KYX-15 devices for maintainer personnel to introduce into the nodes (manual
rekeying). Besides rekey operations, the TRS supports reload operations.
The TRS provides a method whereby selected Network Control reloadable site
initialization parameters may be modified remotely over the network, elim-
inating the need to dispatch a maintainer to the site.
1.2.6 Maintenance Terminal
The Maintenance Terminal (MT) is support equipment used by maintenance
personnel to initialize and synchronize each GWEN station when bringing
them on-line. The MT consists of an HP-85B small personal computer that
uses tape cartridges which contain site-specific data. The software for
the MT was developed in BASIC and was regarded as a computer program
component of the Built-in Test Equipment (BITE) program.
1.3 GWEN SOFTWARE
The GWEN software has a top-down, modular design. The system software
is currently written in Assembly language (65 percent), FORTRAN (30 per-
cent), and BASIC (5 percent). Two higher-order languages, FORTRAN and
JOVIAL, were specified by the Government as acceptable for use as the pri-
mary application software language for GWEN. Of the developed software,
only that developed in FORTRAN is compliant with the Government's approved
higher-order languages. RCA's use of Assembly was driven by coding re-
quirements to support binary operations, I/O instructions, interrupt con-
trol, register save/restore operations and other similar tasks which were
not conducive to FORTRAN coding practices.
The GWEN software is comprised of 11 major computer programs, called
Computer Program Configuration Items (CPCIs), that support the five network
components. The following eight Computer Program Configuration Items sup-
port the relay nodes, I/O and RO stations:
• COMSEC Interface Processor (CIP)
• TRANSEC Control Processor (TCP)
• TRANSEC Front End (TFE)
• TRANSEC Variable Processor (TVP)
• Human-Machine Interface (HMI)
• Network Control Processor (NCP)
• Built-in Test Equipment (BITE)
• Maintainer Terminal (MT)
The remaining three CPCIs support the TRS and GMNC:
• Rekey Crypto Variable Controller (RCVC)
• Rekey Operator-Machine Interface (ROMI)
• GWEN Maintenance Notification Center (GMNC)
RCA subcontracted the development of the Human-Machine Interface and the
Network Control CPCIs to TRW's Redondo Beach, California, facility; the
GWEN Maintenance Notification Center CPCI was subcontracted to the TRW
Colorado Springs, Colorado facility.
The GWEN software is implemented throughout the network in a distri-
buted microcomputer arrangement. The software that executes all functions
required by the RNs, I/Os, and ROs resides at the nodes and stations in
EMM/SESCO's SECS family of microcomputers. For the Maintainer Terminal
CPCI, the software resides in an HP-85B device. The microcomputers are
housed in RCA-designed chassis (drawers) within each node or station's
equipment rack. Software for the GMNC subsystem, colocated at the SAC I/O
station, runs on a VAX 11/730. The TRS subsystem, also colocated at SAC,
runs on the EMM/SESCO SECS family of microcomputers.
Table 1 presents the function, locations, type of processor, and
software developer for each of the 11 CPCIs. Also given are preliminary
sizing statistics, including memory capacities and lines of source code
written in FORTRAN (F), BASIC (B) and Assembly (A). Figure 2, the Computer
Software Specification Tree, identifies the development and product speci-
fications against which the individual CPCIs were evaluated, and illus-
trates their relationships to higher-level and adjacent specifications.
The MITRE SQA effort, centering around the 11 CPCIs, included exten-
sive "desktop" review of the software and software documentation, as well
as testing, simulation and execution of the major portions of the software
during its development. The next section discusses MITRE's Software
Quality Assurance task and the establishment of the MITRE SQA facility.
Table 1. GWEN CPCI Preliminary Statistics
CPCI Function Locat ion Processor Memory Lines
of Code Developer
HMI HMI at I/O Station
I/O SECS 86/10
128K EPROM 256K RAM
2,950F 3,025A
TRW
CIP COMSEC Interface
I/O, RO SECS 80/544
16K EPROM 16K RAM
3.125A RCA
NC Network Protocols
I/O, RN
RO, SECS 86/10
128K EPROM 256K RAM
2,900F 3,025A
TRW/RCA
TCP TRANSEC Control
I/O, RN
RO, SECS 88/10
32K EPROM 4K RAM
1,580A RCA
TVP TRANSEC Variable Maintenance
I/O, RN
RO, SECS 88/10
32K EPROM 4K RAM
1,700A RCA
TFE LF/UHF Comm I/F
I/O, RN
RO, SECS 80/544
16K EPROM 16K RAM
1,470A RCA
BITE Status Monitoring & Reporting
I/O, RN
RO, SECS 80/10A
32K EPROM 4K RAM
3,000A RCA
MT Terminal Initialize & Synch
I/O, RN
RO, HP-85B 128K RAM 2,400B RCA
GMNC Status Display & Reporting
GMNC VAX 11/730
2MB RAM 4,000F 8,060A
TRW
ROMI Rekey Operator- Machine Interface
TRS SECS 86/10
128K EPROM 256K RAM
2.000F 2.000A
RCA
RCVC Rekey Crypto Variable Controller
TRS SECS 86/10
128K EPROM 256K RAM
1,065F 1.130A
RCA
TRANSEC REKEY
STATION
8564323 S4
REKEY CRYPTO VARIABLE CONTROL
PROCESSOR
8567295 SPS
REKEY OPERATOR-
MACHINE INTERFACE
PROCESSOR
8567296 SPS
GWEN SYSTEM
SPECIFICATION
ESD-CWEN-1
SOFTWARE REQUIREMENTS SPECIFICATION
8564397
APPX I CLASSIFIED
APPX II SOFTWARE INTERFACE CONTROL
DOCUMENT
GWEN MAINTENANCE NOTIFICATION
CENTER
8564373 CPDS
HUMAN- MACHINE
INTERFACE
8564373 | CPDS
CLASSIFIED ADDENDUM TO APPX II
COMSEC INTERFACE
PROCESSOR
8564369 S4
GWEN MAINTENANCE NOTIFICATION
CENTER
8564348 CPPS
HUMAN- MACHINE
INTERFACE
8564349 CPPS
NETWORK CONTROL
8564370 CPDS
COMSEC INTERFACE
PROCESSOR
8564345 S4
TRANSEC COMPUTER PROGRAMS
8564368 S4
BITE COMPUTER PROGRAM
8564372 CPDS
NETWORK CONTROL
8564342 CPPS
S4: SOFTWARE SYSTEM/SUBSYSTEM SPEC
SPS: SOFTWARE PRODUCT SPEC
CPPS: COMPUTER PROGRAM PRODUCT SPEC
CPDS: COMPUTER PROGRAM DEVELOPMENT SPEC
TRANSEC FRONT
END
8564343 SPS
BITE COMPUTER PROGRAM
8554346 CPPS
TRANSEC CONTROL
PROCESSOR
8564340 SPS
TRANSEC VARIABLE
PROCESSOR
8564341 SPS
Figure 2. GWEN Computer Software Specification Tree
10
SECTION 2
SOFTWARE QUALITY ASSURANCE
2.1 MITRE SOFTWARE QUALITY ASSURANCE TASK
The GWEN Software Quality Assurance (SQA) effort was initiated at
MITRE in May 1984 to provide verification and validation of the GWEN
computer software. The definition of the MITRE Quality Assurance task, was
to:
• Provide extensive review of software documentation, document
problem areas, identify solutions and track their resolution;
• Perform in-depth testing of the RCA/TRW software;
• -onduct an extensive review of mission-critical software
algorithms;
• Attend and/or observe RCA/TRW technical reviews, unit testing,
hardware/software integration, CPCI and system-level formal
qualification testing.
In order to accomplish this task, MITRE would conduct, in the follow-
ing sequence,
• A detailed review of the GWEN CPCI development and product
specifications;
• An examination of software listings and Program Design Language
(PDL);
11
• An evaluation of the contractor's COMSEC, TRANSEC, and physical
security design;
• Individual line-by-line execution of the software;
• Functional testing of the code against the requirements;
• Functional testing of the code implementation;
• CPCI software testing on hardware.
The actual preparations for the SQA effort were initiated at the time
the contract and SOW were generated for the Thin-Line Connectivity Capa-
bility phase of the GWEN program. Following contract award to RCA in Sep-
tember 1983, MITRE began to gather the necessary resources. This included
the creation of a secure, "closed" area in H-Building at the MITRE/Bedford
complex, and acquisition of computers which were compatible with the ones
used by RCA for software development and hardware/software integration.
The MITRE SQA commitment included four contract engineers and two
MITRE members of the technical staff (MTS). Contractors were assigned to
the SQA facility full-time, while the MITRE engineers' involvement was in
the area of 50 to 75 percent of their available time. The SQA commitment
lasted several years, well beyond the effort normally expended by MITRE in
monitoring software development integration and testing. The intensive
hands-on effort lasted over two years. During the initial 12 months, the
software development and the qualification testing of the individual CPCIs
were completed. The SQA contract engineering support was then scaled down
to two engineers for the next nine months and finally, one contract engi-
neer for the remaining five months. Analysis of residual software issues
identified during DT&E and IOT&E was performed by MITRE MTS.
12
MITRE's efforts in accomplishing the SQA tasks fell into four major
areas of activity: performing desktop audits of individual CPCIs, com-
piling and simulating the CPCI software, establishing a nodal testbed for
testing the software, and determining the maintainability of the software
at the code level. Table 2 summarizes the scope of the SQA effort for each
CPCI. Section 2.2 explains the verification and validation procedures that
MITRE applied to its Software Quality Assurance efforts. Section 2.3
describes the test environment that was created to carry out various as-
pects of the tasks.
Table 2. SQA Task Efforts By CPCI
CPCI Software Quality Assurance Task Effort
Desktop Simulation Node Test Maintenance
NC X X X X
HMI X X X X
GMNC X X
BITE X X X X
MT X X X
ROMI X X
RCVC X X
TCP X X X
TVP X X X
TFE X X X X
CIP X X X X
13
2.2 SOFTWARE QUALITY ASSURANCE PROCEDURES
For any contract, the function of quality assurance provides a planned
and systematic set of actions designed to ensure that the system's software
will conform to established requirements and standards. Software quality
assurance involves numerous verification and validation (V&V) activities
that both the software development and SQA contractors perform during the
various stages of the system's evolution, from software design through
formal qualification testing.
As a routine task in the design and development of the GWEN system,
RCA followed all of the quality assurance procedures in accordance with
relevant Government documents. MITRE, for its SQA effort, focused on a
subset of these procedures that were relevant to the specific MITRE soft-
ware validation tasks. The procedures used by MITRE included:
• Requirements List Generation - A process of extracting a list of
requirements from requirement or design documents to be used as
input for other SQA activities.
• Requirement Traceability Analysis - A process of verifying the
traceability between two requirements or design documents by
ensuring that all requirements in the lower-level documents have
their basis in a higher-level document.
• Critical Algorithm Analysis - A process of evaluating selected
algorithms to ensure conformance with system objectives.
• Interface Analysis - The process of evaluating the completeness and
compatibility of system, subsystem, and module-level interface
definitions.
14
• Traceability Analysis - A process of verifying that the test
scenarios defined in the test procedures provide for complete and
rigorous testing against the requirements.
• Database, Source Code, Program Design Language (PPL) and Develop-
ment Test and Evaluation - For the database, a process of evaluat-
ing the requirements, design and physical characteristics. For the
source code and PDL, a process of analysis to ensure adherence to
applicable standards and coding practice, correct implementation of
interfaces, the absence of abnormal return and error procedures,
and efficient implementation of call sequence parameters. For
development test and evaluation, a process of evaluating unit level
integration, software component level integration, system level
integration and operational levels of testing through the processed
test plan/procedures analysis and review, test witnessing and test
results evaluation.
• Design-to-Code Traceability - A process of verifying that the
source code correctly implements the Computer Program Configuration
Item (CPCI) as described in the requirements and detailed design
documents.
• Formal Review and Audit Support - The overall V&V process of sup-
porting formal reviews and audits of the CPCIs through the applica-
tion of military standards, Department of Defense and Military
Department regulations, and through the requirements of the State-
ment of Work.
• Document Discrepancy Report Preparation - A process of recording
problems discovered during analysis of a document, identifying
proposed solutions and tracking the disposition of the problem.
15
2.3 SOFTWARE QUALITY ASSURANCE TEST ENVIRONMENT
The MITRE SQA facility was configured and equipped to examine software
execution at the module level, analyze critical timing constraints and
determine compliance with the Government's developmental requirements. To
this end, MITRE acquired two Hewlett-Packard (HP) microprocessor develop-
ment systems (MDSs) with a full suite of 8080/8085, 8086, and 8088 emulat-
ors, a Tektronix 8550 microprocessor development system with a limited
suite of 8080/8085 emulators, and a Digital Equipment Corporation VAX
11/730 computer system, First System (FS) software construction tools and
Boston Systems Office (BS0) software development tools. Hardware required
to build a three-chassis (TRANSEC/NCP, TIP 1/0 and BITE) node testbed was
also acquired.
Ancillary support equipment for the facility included an HP-1631D
logic analyzer, an HP multichannel internal software analyzer, an Analogic
DATA 6000 digital storage scope, a Data 1/0 29A Universal PROM programmer
and several IBM PC and AT computers. The SQA facility allowed detailed
examination of the RCA/TRW software operating in a simulated and in a GWEN
hardware environment. Figure 3 provides a pictorial representation of the
SQA process in relation to the associated MITRE task efforts.
2.3.1 Microprocessor Development Systems
Three microprocessor development systems were employed to provide
complete software analysis of the CPCI under examination. By using the
three MDS workstations within a basic configuration, MITRE engineers were
able to monitor the individual processing of three CPCIs concurrently, as
well as their node interaction with other CPCIs.
16
| IR-757 ]
/SOURCE \ I conr 1 VAX
11/730 MICROPROCESSOR
DEVELOPMENT SYSTEM
RCA- EQUIVALENT
NODE V RECEIVED J
VERIFY PROGRAM DEVELOPMENT
LANGUAGE (PDL) —fr COMPILE SOURCE
CODE —•
EXECUTE IN MICROPROCESSOR
SIMULATORS —» EXECUTE IN REAL
ENVIRONMENT —» INTEGRATE CPCIs
INTO NODE
• COMPARE BS/C5
• UNIT DEVELOPMENT FOLDERS
• LISTINGS
• COMPLETENESS
• SIZING
• STANDARDS
• LOGIC VERIFICATION
• INTERFACES
• SOFTWARE ANALYSIS
• TIMING ANALYSIS
• LOGIC ANALYSIS
• INTERPROCESSOR COMMUNICATION
• NODAL FUNCTIONALITY
• NODAL THRUPUT/TIMING
Figure 3. SQA Process/Task Relationship
The following items comprised the HP 64000 MDS software testing
equipment provided in the GWEN SQA facility:
• HP 64000 MDS workstation with keyboard, 12-slot card cage, CRT and
dual floppy disk drives;
• HP 8086 emulation subsystem which includes emulator controller,
8086 pod, 128K memory board, analysis board;
• HP 8088 emulation subsystem which includes emulator controller,
8088 pod, 64K memory board, analysis board;
• HP 8085/8080 emulation subsystem which includes emulator control-
ler, 8085 and 8080 pods, analysis board;
17
• HP Software State Analyzer which provides the details of the
software execution (e.g., timing, bus interaction, memory usage,
CPU states, and interaction);
• HP 15-megabyte Winchester hard disk;
• Line printer.
The following items, which are similar in nature to the HP 64000 MDS,
comprised the Tektronix 8550 MDS provided in the GWEN SQA facility:
• TEK 8500 MDS workstation with keyboard, a model 8301 microprocessor
development unit with 32K of emulation memory;
• TEK 8501 data management unit;
• TEK 8080 and 8085 emulation control pods.
2.3.2 VAX 11/730 Computer System
The final major portion of the GWEN SQA facility was the Digital
Equipment Corporation VAX 11/730 computer system, which consists of three
megabytes of on-line RAM memory, a 121-megabyte fixed hard disk, a 10.4-
megabyte removable hard disk, a nine-track tape drive, six video display
terminals, one printer, application software which supported software
creation from source code to executable format, and software for debugging
and simulation of the GWEN CPCI processors. Additional information on the
VAX-installed software applications is presented in section 3.
The interconnectivity of the microprocessor development systems with
the VAX 11/730 computer system is presented in figure 4.
18
VT 220/240
a A
VAX 11/730
HP64100A
DISK DRIVE
• 8086,8088 EMULATOR
8085 EMULATOR
<s&T^
LINE PRINTER
15MB HARD DISK
=G HP64100A
^^^^Ji 8086/8088 EMULATOR
8085 EMULATOR
A&T^ TEK8550
• EMULATOR 8080
EMULATOR
&T £ Figure 4. MITRE Software Quality Assurance Test Environment
19
2.3.3 Software Quality Assurance Node Testbed
Once the SQA microprocessor development systems and VAX facility were
established, the next stage was to create a node testbed. Several alterna-
tive node configurations were reviewed. Based on the complexity of the
software, the operator interaction and the network processing requirements,
MITRE designed and configured three Intel-based chassis to be functionally
identical to an RCA I/O station. The decision to build functionally iden-
tical units rather than using actual RCA chassis was driven by the non-
availability of RCA engineering chassis to support the SQA effort. With
the exception of the LF transmit/receive functions of the RN, the UHF
transmit/receive functions of the I/O, and the GWEN Maintenance Notifica-
tion Center and TRANSEC Rekey Station support subsystems, the entire sta-
tion architecture was incorporated into the MITRE SQA node design (see
figure 5).
The three chassis (TRANSEC/NCP, TIP I/O and BITE) were designed to be
functionally equivalent to the RCA hardware. The development of the test-
bed provided MITRE with the capability for in-depth analysis of the COMSEC
(Communication Security) interfaces, Network Control software, TRANSEC
hardware/software and critical timing requirements of the GWEN relay nodes.
The three chassis configurations, including the Intel boards and the
corresponding RCA hardware boards, are presented in tables 3, A, and 5 for
the TRANSEC/NCP, TIP I/O, and BITE chassis, respectively. Figure 6 pre-
sents the chassis interfaces within the MITRE testbed node.
2.3.A Software Quality Assurance Software Simulation
In two functional areas, TRANSEC and COMSEC Interface Logic, there
were no commercial equivalents for the boards being manufactured by RCA to
military specifications. Accordingly, to simulate the TRANSEC Control and
Variable Processors and TRANSEC-KG functions, and the COMSEC Interface
20
LF TRANSMIT
UHF TRANSMIT
ERROR DETECTION
AND CORRECTION
TRANSEC KG
1
TRANSEC VARIABLE
PROCESSOR
PRINTER
LF RECEIVE
-—^-— -—
TRANSEC CONTROL
PROCESSOR
T
NETWORK CONTROL
PROCESSOR
COMSEC INTERFACE
LOGIC (BLACK)
RED/BLACK FILTER
COMSEC INTERFACE
LOGIC (RED)
1
HUMAN- MACHINE
INTERFACE
UHF RECEIVE
TRANSEC FRONT-END
BUILT-IN TEST
EQUIPMENT
ERROR DETECTION
AND CORRECTION
CYCLIC REDUNDANCY
CHECK
KG-B4A
COMSEC INTERFACE „, PROCESSOR (
RED/BLACK FILTER
GWEN MAINTENANCE NOTIFICATION
CENTER
i TRANSEC
REKEY STATION
.J NOT INCLUDED IN MITRE SQA NODE DESIGN
Figure 5. GWEN Station Architecture
21
Table 3. Chassis Construction: TRANSEC/NCP
Slot# Description RCA Board MITRE
Intel Board
1 - - -
2 EDAC E-FXA '
3 TVP E-FXB
4 TCP (MEMORY) E-FXC
5 TCP (KG) E-FXD iSBC 88/25*
6 TCP (CPU) E-FXE >
w/iSBC 302
7 R/B FILTER E-FXF
8 BLACK I/O 1 E-FXG
9 BLACK I/O 2 E-FXH (
10
11
TFE (CPU)
TFE (I/O)
80/544 1
80/544 J iSBC 544
12 NCP 86/10 iSBC 86/12A
13 NCP RAM 80/056A iSBC 056A
14 NCP ROM 80/164 iSBC 464
15 NCP ROM 80/164 iSBC 464
* Simulal :ion of boards required
22
Table 4. Chassis Construction: TIP I/O
Slot# Description RCA Board MITRE
Intel Board
1 Power Supply Equip.
(RCA) -
2
3
CIP (CPU)
CIP (I/O)
80/544 ^
80/544 ) iSBC 544
4 HMI COMM 80/534-2 iSBC 534
5
6
HMI COMM (not used)
;
7
8 HMI (expansion ) _
9 HMI RAM 80/056A iSBC 056A
10 HMI ROM 80/164 iSBC 464 (2)
11 HMI (CPU) 86/10 iSBC 86/12A
12 CIL (RED) (RCA) -
13 R/B FILTER (RCA) -
14 CIL (BLACK) (RCA) iSBC 544*
15 -
uired * Simula tion of boards req
23
Table 5. Chassis Construction: BITE
MITRE Slot # Description RCA Board Intel Board
1 I/O STATUS (RCA) -
2
3
4
CLOCK GEN (RCA) -
BITE RAM/ROM 80/164 iSBC 464.028A
5
6
7
BITE (CPU) 80/10A iSBC 80/10B
UHF MODEM (RCA) _
8 UHF MODEM (RCA) -
9 I/O UHF (RCA) -
Logic (CIL) function, we used Intel boards having similar hardware capa-
bilities and MITRE-developed software. The TRANSEC hardware configuration,
presented in figure 7, is comprised of four processors and the TRANSEC-KG.
The TRANSEC simulation software was developed utilizing Intel 8086 Assembly
language, which was compatible with the RCA-developed TVP, TCP, and TKG
functions. The simulation software was developed on the VAX 11/730 system
using First System's 8086 assembly and the BSO simulator. It provided full
transmission/reception path cyclic redundancy check (CRC), encryption/
decryption, error detection and correction (EDAC) functions and interface
control to and from the NC and TRANSEC Front End (TFE) hardware.
The COMSEC Interface Logic hardware configuration, shown in figure 8,
included two processors and the COMSEC interface module and KG-84A crypto-
graphic device. The simulation software was developed with Intel 8085
Assembly language due to the hardware-intensive nature of the CIL func-
tions. This simulation was necessary because RCA was manufacturing unique
24
IH-760 |
NOT INCLUDED IN MITRE SQA NODE DESIGN
LF TRANSMIT
—x
UHF TRANSMIT
ERROR DETECTION
AND CORRECTION
LF RECEIVE
UHF RECEIVE
. r
TRANSEC KG
TRANSEC VARIABLE PROCESSOR
TRANSEC FRONT-END +f
TRANSEC CONTROL
PROCESSOR
ERROR DETECTION
AND CORRECTION
NETWORK CONTROL
PROCESSOR I _j i j__ _T]MMEC/M^CHASSI£_ 1
CYCLIC REDUNDANCY
CHECK
COMSEC INTERFACE
LOGIC (BLACK)
I I
KG-84A
RED/BLACK FILTER
COMSEC INTERFACE
LOGIC (RED)
PRINTER
COMSEC INTERFACE „,
PROCESSOR (
I
RED/BLACK FILTER
HUMAN- MACHINE
INTERFACE
TERMINAL KEYBOARD/
DISPLAY (EMULATOR) 2
TIP I/O CHASSIS
EXTERNAL INTERFACE
(EMULATOR)
BUILT-IN TEST
EQUIPMENT
_BJlESh!lSI!.S—
Figure 6. MITRE Node Configuration Chassis Interface Diagram
25
IR-761
TO COMSEC INTERFACE LOGIC
CYCLIC REDUNDANCY
CHECK
NETWORK CONTROL
PROCESSOR
4—fr
ERROR DETECTION
AND CORRECTION
TRANSEC CONTROL
PROCESSOR
<—• TRANSEC
FRONT END PROCESSOR
FROM " RECEIVERS
» r T
TRANSEC ERROR DETECTION
AND CORRECTION
VARI/ PROCE
kBLE SSOR
TRANSEC-KG TO
^TRANSMITTERS
IR-762J
Figure 7. TRANSEC Configuration
A FPOM/Tn ^ - « A » « A
NETWORK CONTROL
PROCESSOR
HUMAN- COMSEC INTERFACE
PROCESSOR B „
COMSEC INTERFACE
LOGIC B > MACHINE R INTERFACE *
A
i i i
<
i A/B
r
KG-84A B
TO/FROM TRANSEC CONTROL PROCESSOR
Figure 8. CIL System Configuration
26
boards to perform the CIL functions (red/black filter interface and message
header bypass). Since Intel does not build similar CIL boards, MITRE used
an Intel board with equivalent hardware capabilities and wrote a software
simulation of the RCA CIL board.
The COMSEC Interface Logic acts as the communications interface be-
tween the COMSEC Interface Processor (CIP), the KG-84A cryptographic device
and the Network. Control Processor. Figure 8 illustrates the CIL system
configuration processing flow. The data flow from the Network. Control Pro-
cessor to the Human-Machine Interface is reflected in the "A" data path.
The reverse flow, Human-Machine Interface to the Network Control Processor,
is reflected in the "B" data path.
In addition to the preceding functional areas, the HMI's Alpha/Graphic
Plasma Display Terminal (PD-3500) was not available from the contractor to
support the SQA effort. Software was developed to emulate, on an IBM PC,
the PD-3500 display terminal and its interface to the HMI CPCI. The emula-
tion software (System Resource Program (SRP)) provided a real-time operat-
ing shell which, when established in the PC-DOS environment, allowed execu-
tion of the HMI's menu displays, message origination/reception and off-line
test data analysis. The SRP operating system contains a number of user-
callable routines that perform functions normally associated with an
operating system. These routines fall into six basic functional blocks:
initialization, I/O processing, interrupt processing, semaphore event flag
processing, time processing and system exit. In addition to the user-
callable routines, there are a number of routines used by the SRP for task
control and interrupt processing, which, when used together with DOS rou-
tines, make a complete environment for the execution of HMI's display
terminal applications programs. Utilizing the SRP software functions,
MITRE subsequently developed the External (System) Network Simulator Device
Driver and the BITE Device Drivers. Both of these simulation driver pro-
grams made use of the real-time processing application derived from the SRP
software.
27
Figure 9 summarizes the progression of tasks in the SQA facility. In
order to compensate for delays in receiving the contractor-unique hardware
used in the COMSEC Interface Logic, the TVP and the TCP, we developed the
CIL simulation and investigated techniques for simulating operation of the
TCP and TVP. The individual CPCIs were downloaded from the VAX onto the
respective boards and combined (see figure) to form the BITE, TRANSEC/NCP
and TIP drawers. The assemblage of the three drawers formed the MITRE
node. This node was exercised to verify the correct performance of inter-
CPCI interfaces and to demonstrate various nodal requirements. These tasks
were carried out simultaneously with RCA's effort, represented in the upper
portion of the figure. Our evaluations and results are the subject of
section 3.
28
TRANSEC CONTROL
PROCESSOR CPCI
RCA NODE
RCA HARDWARE CHECKOUT
TRANSEC VARIABLE
PROCESSOR CPCI
FINAL SOFTWARE
QUALITY ASSESSMENT
BUILT-IN TEST
EQUIPMENT (BITE) CPCI
BITE DRAWER
FRONT END
TRANSEC FRONT
END CPCI
TRANSEC/ NETWORK CONTROL DRAWER
NETWORK CONTROL
CPCI
MITRE NODE
COMSEC INTERFACE LOGIC (CIL) SIMULATION
INTEGRATE CIL&
KG-84A CPCI
KG-84A COMSEC
COMSEC INTERFACE
PROCESSOR CPCI TRANSEC
INTERFACE PROCESSOR
DRAWER .—| HUMAN-
MACHINE INTERFACE
CPCI
Figure 9. GWEN Software Quality Assurance Tasks
29
SECTION 3
SOFTWARE ANALYSIS METHODOLOGIES ND SUMMARY OF FINDINGS
3.1 SOFTWARE EVALUATION AND FINDINGS
The evaluation of the GWEN software for the SQA effort was divided
into the following activities:
• Preliminary Statistical Analysis of Software Trouble Reports
(STRs);
• Desktop Audits of Specifications, Source Code, Program Design
Language (PDL), and Test Procedure Audits;
• VAX and Software Simulation Test Environment;
• MITRE Node Test Environment;
• Software Code Maintainability Analysis.
The level of the SQA effort completed for each individual CPCI was
proportional to the RCA and TRW software development effort, the
availability of software for the SQA effort, the level of risk each CPCI
represented to the overall GWEN system, and the availability of SQA assets.
As a minimum, all CPCIs received STR statistical analyses, desktop audits,
and software code maintainability analyses. Due to their size, selected
CPCIs (i.e., HMI and NC) required dedication of the VAX 11/730 in order to
build and run them in simulation. Smaller CPCIs were built and run in
simulation concurrently.
31
The individual SQA activities, with a summary of major findings, are
presented in the following paragraphs. Detailed discussions and findings
pertaining to the analysis of the individual CPCIs are presented as appen-
dices to this report (published separately). To assist the reader, the
appendix topics are listed below.
Appendix A Computer Program Configuration Item Check. List
Appendix B COMSEC Interface Processor (CIP) CPCI
Appendix C TRANSEC Processor (TCP, TFE, TVP) CPCIs
Appendix D TRANSEC Rekey Station (ROMI, RCVC) CPCIs
Appendix E Human Machine Interface (HMI) CPCI
Appendix F Network Control Processor (NCP) CPCI
Appendix G Built In Test Equipment (BITE)/Maintenance Terminal
(MT) CPCI
Appendix H GWEN Maintenance Notification Center (GMNC) CPCI
3.2 SOFTWARE TROUBLE REPORTS
3.2.1 Activities
The evaluation and analysis of RCA's Software Trouble Reports (STRs)
was accomplished through detailed technical review of all STRs generated by
RCA against GWEN software. The configuration control procedures for the
processing of the STRs was additionally reviewed to determine the Govern-
ment's role and responsibility in the resolution of the open issues. All
STRs were maintained in a central library to provide a comprehensive base-
line from which the statistical analysis was derived. Figure 10 shows a
Software Trouble Report data sheet.
32
IR-763
SOFTWARE TROUBLE REPORT
STR NUMBER: DATE ISSUED: VERSION BUILD
CPCI: (BITE. CIP. CMNC. HMI, NC. PLD. RCVC. ROMI. TCP. TFE. TUP. OTHER)
PROBLEM IDENTIFIED DURING: (SWI, HSI. POT. FQT, OPERATION, OTHER)
PROBLEM TITLE:
PROBLEM DESCRIPTION: (If more spact required, us* attachment)
REFERENCE DOCUMENT:
NAME:
PARA:
LOCATION: PHONE*:
ANALYSIS AND PROPOSED SOLUTION: (If nor* space n*etj«d. us* attachment)
ROUTINES CHANCED:
SPECIFICATION/DOCUMENTS REQUIRING CHANCE:
ANALYST NAME: PHONE* DATE
TEST METHOD: TEST RESULTS: SQA CERTIFICATION:
DATE:
APPROVAL REQUIRED BY UM: SCCB CCB: SCLE«: STR CLOSED BY RELATED STR: STR DISPOSITION: IMPLEMENTED
(UM.SCCB.CCB) SCCB
SCCB MTC DATE: CCB MTC DATE:
STATUS: STATUS DATE.
•
Figure 10. Software Trouble Report Data Sheet
33
3.2.2 Summary of Findings
The Software Trouble Report statistical analysis was completed as an
integral part of the individual CPCI analysis. However, for purposes of
this report, our findings and observations resulting from the STR analysis
are presented as preparatory information to the CPCI assessments-
As of 20 December 1987, a total of 998 Software Trouble Reports had
been generated by the contractor. The configuration control procedures
employed by the contractor for processing STRs is documented in the GWEN
Software Configuration Management Plan, COMSEC/TRANSEC, Revision 3, dated
25 January 1985, which was approved by the Government on 19 February 1985.
During our analysis of the STR configuration control procedures, we
note that the Government was not a member of the Software Configuration
Control Board (SCCB). The SCCB was delegated the responsibility for the
evaluation and disposition of all proposed changes to approved software
development specifications and to all software code which had been approved
for software integration. As such, it should be stated that the final
solutions which supported the closure of an STR represented only the con-
tractor's position or objectives and did not reflect the Government's posi-
tion, nor its approval or disapproval of the STR resolution. Ue further
noted that the majority of the STRs were initiated upon the contractor's
analysis of test results following testing at the module level, the compo-
nent (CPM, CPC) level, the CPCI integration level, the Government Formal
Qualification Test (FQT) level, and the GWEN hardware/software integration
level. Nevertheless, we found that the STR methodology employed by the
contractor provided the necessary configuration control and traceability of
corrective actions for the software problems and discrepancies that were
identified.
From January 1985 to January 1988, the number of Software Trouble
Reports had a constant growth. Rather than try to analyze all the STRs, an
34
intermediate software development period, April 1986 to October 1987, was
selected for the purpose of this evaluation. This period coincides with
the peak software development and testing phase. During the period of
evaluation, a total of 625 Software Trouble Reports were originated. A
breakdown of these STRs by status is shown in table 6.
By graphing the total number of STRs versus the open STRs over the
period April 1986 to October 1987 (figure 11), the trend can be seen. The
obvious trend is the increase in the total number of STRs; more important-
ly, however, is the almost constant value for the "open" STRs at any one
time. While the number of open STRs remained around or below 50, the
"approved" STRs were consistently at a level of approximately 100 STRs
above the open STRs. This indicated that a conscious effort was being made
by the software developer to keep the open STRs to a minimum and to take
swift action on new STRs. It should be noted that SCCB approval of STRs
indicates that the software fix had been implemented in the development
versions of the software. For formal closure of these approved STRs by the
SCCB, a satisfactory response from the hardware/software integration test-
ing engineers was required.
The spread of the STRs across the CPCIs was also considered. Table 7
presents STR status data for the individual CPCIs as of 1 October 1987. As
can be derived from this data and seen in figure 12, the CPCI having the
greatest number of STRs (410) is the Network Control (NC). This high con-
centration was expected since the NC is the most complex CPCI. It inter-
acts with all other CPCIs and possesses the greatest number of interfaces.
Additionally, the TRW-developed NC virtual circuit (VC) software design was
completely reworked and rewritten by RCA following the TRW delivery. Four
other CPCIs, all having 50 or more STRs generated against them, were the
HMI, TCP, CIP and TFE with 87, 69, 59 and 51 STRs, respectively. In the
case of these four CPCIs, the STRs were generated mainly because of
discrepancies identified during the hardware/software integration testing.
The remaining six CPCIs accounted for less than 16 percent of all STRs
35
Table 6. Software Trouble Reports
(April 1986 to October 1987)
Date Closed + Open + Approved + Rejected + Withdrawn =. Total
04/29/86 214 38 54 31 18 355 05/01/86 214 41 57 31 18 361 05/13/86 231 40 44 31 20 366 05/21/86 233 42 52 31 19 377 08/27/88 387 54 62 31 19 399 09/10/86 390 23 27 33 47 517 09/17/86 397 26 45 35 49 552 09/24/86 400 26 53 35 51 565 10/08/86 404 27 72 35 52 590 10/16/86 404 33 85 35 52 609
10/22/86 405 32 89 35 53 614 10/29/86 405 40 105 35 53 638 11/05/86 405 38 120 35 53 651 11/12/86 418 35 124 35 54 666 11/14/88 423 34 128 35 55 675 11/19/86 426 36 131 35 55 683 11/25/86 438 35 130 35 58 696 12/03/86 441 35 165 35 58 734 12/09/86 441 30 172 35 59 737 12/10/86 455 10 165 42 65 737 12/17/86 510 9 109 42 68 738
12/24/86 527 11 115 42 68 763 01/02/87 527 10 116 42 68 763 01/08/87 529 11 116 43 70 769 01/14/87 549 10 102 43 71 775 01/21/87 559 13 93 43 73 780 01/28/87 566 15 87 43 73 784 02/04/87 571 20 87 43 73 794 02/11/87 571 23 95 43 73 805 02/18/87 571 20 104 43 76 814 02/25/87 571 20 109 43 76 819
03/02/87 571 16 123 43 81 834 03/11/87 571 14 130 43 83 841 03/18/87 606 13 96 43 87 845 04/01/87 622 22 88 43 90 865 04/16/87 635 22 81 43 90 871 04/22/87 666 21 53 43 91 874 04/29/87 668 21 54 A3 92 878 05/06/87 674 21 56 43 92 886 05/13/87 680 22 56 43 92 893 06/03/87 690 25 59 43 94 911
36
Table 6 (Concluded)
Date Closed + Open + Approved + Rejected + Withdrawn - Total
06/10/87 694 25 56 43 95 913 06/17/87 695 24 62 43 95 919 06/24/87 713 25 44 43 95 920 07/08/87 721 26 41 45 95 928 07/15/87 721 24 44 45 95 929 07/29/87 729 25 43 45 95 937 08/05/87 734 26 48 45 95 948 08/12/87 737 22 54 46 97 956 08/19/87 744 20 51 46 98 959 08/26/87 752 19 51 46 98 966 10/01/87 783 12 27 52 106 980
Table 7. Software Trouble Report Breakdown by CPCI
(as of 1 October 1987)
CPCI Closed + Open + Approved + Rejected + Withdrawn = Total X
BITE 16 1 0 1 1 19 1.9 CIP 51 0 1 4 3 59 6.0 GMNC 18 6 7 6 5 42 4.3 HMI 65 1 2 4 15 87 8.9 MT 35 0 0 2 3 40 4.1 NC 342 2 3 18 43 410 41.8 R0MI 6 0 1 0 0 7 0.7 RCVC 23 0 6 0 5 34 3.5 TCP 58 0 0 9 2 69 7.0 TFE 48 0 0 1 2 51 5.2 TVP 19 0 0 0 2 21 2.1
Other 141 14.4
TOTAL 980
37
1000
4/30/86 5/31/86 9/30/86 10/31/86 11/30/86 12/31/86 1/31/87 2/28/87 3/31/87 4/30/87 5/31/87 6/30/87 7/31/87 9/30/87
DATE
Figure 11. Software Trouble Report Statistics
500-
400-
H ft 300- cc CO 9
200-
410
Figure 12. Software Trouble Reports by CPCI (as of 1 October 1987)
38
generated. The "Other" entry in table 7 refers to STRs that are related to
the GWEN consolidated database necessary for correct station initialization.
Information was also gathered on the number of STRs originated on a
monthly basis. This information, presented in table 8, reflects the period
from January 1985 through September 1987. We note that the greatest number
of new STRs were generated during the October through November 1986 period,
which coincides with the redesign of the NC's virtual circuit function.
On an average, an STR was closed 73 days after it had been initiated.
To obtain a greater understanding of closure time for an STR, the average
number of days until closure, analyzed by quarter originated, was calcul-
ated. The average number of days to close out an STR ranged from a low of
18 to a high of 133. Table 9 provides this information.
Table 8. Software Trouble Report Monthly Origination Basis
(as of 1 October 1987)
Month Number Month Number Month Number
Jan 85 3 Jan 86 20 Jan 87 26 Feb 85 5 Feb 86 22 Feb 87 48 Mar 85 4 Mar 86 25 Mar 87 25 Apr 85 21 Apr 86 52 Apr 87 12 May 85 31 May 86 50 May 87 30 Jun 85 56 Jun 86 44 Jun 87 23 Jul 85 21 Jul 86 36 Jul 87 16 Aug 85 13 Aug 86 31 Aug 87 23 Sep 85 33 Sep 86 49 Sep 87 16 Oct 85 15 Oct 86 72 Nov 85 16 Nov 86 79 Dec 85 25 Dec 86 38
39
Table 9. Software Trouble Report Rate of Closure
(January 1985 - September 1987)
Average Days Until Dat e ST R is Closed by Quarter
Jan 1 , 1985 18 Feb 1 , 1985 46 Mar 1 , 1985 115 60 Apr 1 , 1985 27 May 1 , 1985 52 Jun 1 , 1985 86 55 Jul 1 , 1985 100 Aug 1 , 1985 92 Sep 1 , 1985 82 91 Oct 1 , 1985 118 Nov 1 , 1985 133 Dec 1 , 1985 70 107
Jan 1 , 1986 85 Feb 1 , 1986 92 Mar 1 , 1986 77 85 Apr 1 , 1986 79 May 1 , 1986 48 Jun 1 , 1986 77 68 Jul 1 , 1986 63 Aug 1 , 1986 115 Sep 1 , 1986 113 113 Oct 1 , 1986 79 Nov 1 , 1986 57 Dec 1 , 1986 38 58
Jan 1 , 1987 123 Feb 1 , 1987 66 Mar 1 , 1987 87 92 Apr 1 , 1987 55 May 1 , 1987 49 Jun 1 , 1987 51 52 Jul 1 , 1987 37 Aug 1 , 1987 21 Sep 1 , 1987 18 25
Overall average - 73 days
40
3.3 DESKTOP CPCI AUDITS
3.3.1 Activities
As the first step in the SQA process, desktop audits were conducted on
each of the Computer Program Components (CPCs) which comprise the
individual CPCIs. The applicable documents upon which the audits were
based, and which delineate the individual CPCI requirement baselines, are
identified in the bibliography. The users' requirements are delineated in
the individual CPCI development and product specifications: the Software
Requirement Specification; the COMSEC Software System/Subsystem Specifica-
tion and the Software Product Specification for COMSEC/TRANSEC-designated
CPCIs; and the Computer Program Development Specification and the Computer
Program Product Specification for non-COMSEC/TRANSEC-designated CPCIs. The
user requirements were checked against the system-level requirements de-
fined in ESD-GWEN-1 and the contractor's requirement qualification test
matrices. The goal of cross-referencing the development requirements with
the contractor's requirement qualification matrices was to provide trace-
ability down to the qualifying test case.
The code itself, which had been loaded onto the VAX 11/730, was
examined manually on a line-by-line basis and compared to the associated
Program Design Language contained within the respective CPCI product speci-
fication. Checklists derived from MIL-STD-483 and ESD-TR-84-171 (Vol. Ill)
for the Computer Program Product Specifications (CPPS), from NSAM 81-3 for
the Software Product Specifications (SPS), and from ESD-GWEN-1 for the com-
puter programming (design, construction, and sizing) requirements, were
utilized to determine how well the individual CPCI product specifications
and CPCIs themselves complied with the requirements of the standards and
CDRL. The evaluation checklists used in reviewing the CPPS, SPS and the
CPCI source code are presented in appendix A under separate cover. As part
of the analysis of the COMSEC/TRANSEC CPCIs, the contractor's cryptographic
41
principles and protective alarm software/hardware design, the TEMPEST secu-
rity design, and the failure modes and related alarm notifications were
assessed against the requirements of NACSIM 5100A, NACSEN 5112 and KAG
30A/TSEC.
3.3.2 Summary of Findings
Table 10 presents, on a CPCI-by-CPCI basis, the major findings from
the MITRE review of the development and product specifications and our
source code analysis. Complete descriptions of each CPCI audit are pre-
sented under separate cover in appendices B through H.
We found that all of the CPCIs contained numerous discrepancies be-
tween the PDL and code, errors in the programming logic and violations of
conventional programming styles. Instances in which the source code dis-
agreed with the in-line comments were also found by MITRE. Omissions,
inconsistencies and/or erroneous data identified during the evaluation of
the individual CPCI product specifications were recorded as part of our
findings.
The final contractor-implemented designs for each of the CPCIs were
found to contain minor deviations from the authenticated development
specifications, including sizing of the RAM and ROM memories and conflicts
with the criteria specified in the Government-approved documents. Also,
the instructions and user manuals were incomplete and did not comply with
the Government's instructions for their preparation and content. These
minor deviations were generally resolved by the Government's granting of a
waiver to the contractor. After technical interchange meetings with the
contractor, relevant comments made by ESD/MITRE were resolved by the
contractor, and the specifications, manuals, and other documents were
approved.
42
to bO c
•r-l
C •rH Pu
T3
< Q. O 4-J
CO <u Q
U Ou, u z w :»
cu —i
-O
E-
bO c f—1 s C
4J X) • rH o Cfl • J 06 T3 -H O 9) (0 u 0) c Q O C 4-. cu C • T> rH w 3 O Cu OS CO rH u u
rH 3 a. c r-i •H ^-N W 3 o u -O • OH X o rrj 4-1 4-1 73 O W 4-> CO CO 3 H «1 h U cu o > CO B •* C C 4J r 3 CU CO o 313« X N 3 4-i a) CO 8 Q. Li ai co OUCH) o Li M •H co -H a 4-" O M-l C CJ s* at o 4-> o cu H^J3 C CU rH Li O -H • o o
c a bo 4-1 bo (0 CJ 1 O •o 3 **-l bo Ll 4-1 u c CO U 4-i •H CU CO Li o o cu 4-i c a. o bo»H • c CO 4-> CO 4-> J3 -H O -H CO CO Ll -H c *J c O CO bo O cu c 0) •H O W > M-4 rH 3 O rH 4-i O •H -H rH CO C -ri 3 •rt 4-> C (OS c 14-1 at a 4-» Ll -ri -o w 4-1 at •H 4-> rH • 1 •HTJ 0) at -H JQ 4-> a. 4-> O 4-1
01 CO cj .* co co M CO 4-1 0) T3 oi a to u 3 o Ot (0 * a> u o CJ 4J > M CD rH C E 01 >-> > rH 01 CO Ll Qu CJ s^.
OT Ot O -H Li . a> o u bo cu O E C —i 4-> • Ll J3 3HH bO t«o>u a w j= c Li CO (0 CO O. (0 b0j3 01 4-1 01 Ll 4-14-1 CO M-H Z c co u 14-1 a o c at <: co 3 Li -H 1 J3 3 C O O • •H 03
•H co a. co a» oi co bO CO z bo co r^ OHO c at cu 4-1 4-> T5 CO M bo 4-> Ll 0) T3 12 COO) >» >»rH C bO Ll o o -o C ai u 4-> nj co o 4-> 4-» a O Li TJ CO CJ (0 M "O (0 3 e c c
•H El) CO >, u c c (0 •H a.-os co C rH J3 H III rH (0 PM CO WH CO WHO) •r4 C 4-1 ^ > CU CO 73 CO •rH -O B
M-l 3 O CD 0) -H CO a; o (0 CO 5 w ai -H . at (0 •H O CJ >> O H rH UW cu a> u 3 J= cu co -a 3 co cu a 4-1 -O -H Z ai 4-1 01 fO *4 -H o u LJ 0) •H O 4V U •H o bo*o • u 4-1 ti C U O CO C O *4 C3 U <J 4-i at -H co CO CJ c C CO (0 4-i Cu e w -
bOO 3 3 Li 4H CO 01 CO c •H C Li > C -H CO rH > 3 •H bo at • •H a. <u 4-i 0) .* 3 4-1 3 a> 4-" O O "O o L, 4-. u cu 4.- a.u H bom co o. en m w U II) CO CT Li CO U Li bO Li CJ o co cu JO 4-i 4-> CO B • cu 3 JO *-< x co c
cu J M •r4 Oi O JO CU Ll rH fO a o -H a co o s s 11 OH
a o ^ Q CO < CO rH CO 14-1 < a w co js M Cu T3 O rH C/5 O •rH
• • • , . . . • • t <H CM CO -* m vO r- rH CM CO -*
01 >» >, TJ Z rH H O 3 aa -o
\ O « a 1 M H 0) 11 4-1 as co CO a. o O CO co o < bu < "-> <
rH CO o Z H 0) 1 O m i m > c >mN < CM D -rH OS C* O
H CM co U rH
a J Ort CO
o o CO CO
W Q rH 1 CO 1 I-t «H - M C* CM a ea m r^ r~ vo M >» 1 r-. <S in CM >»
w fOfOH CO ON 0> C3S >• CM CO c -» <* CO *J3 >* -* CO v© CO CO •* 0 \C NO r-- \0 CO -» co ** r» vo
•H in in vo M m «* vo sr vo vo in 4-J Hooeom M CO \D r-t m »o m m co (0 1 CO in i co m co co o 22 • * •> • CO Z CO
•H woo. M O w • • • o UH :» z z o z • So • o o z •H cj z CO o CJ z o z z CJ 1 C/5 10 4-> Z Z z z u a a a, H 1-1 Cu Q 10 to H Z a. IOCUDHO co cu z C/i M >tf Cu © Cu
oo DJ U U Ct,
o
OiUD W c/3 W CO Pu CJ
c M o o e CO
•rt 4-» O O M-l 4-1 (0 -H U Ll a 4-1 to cu c H CO z 4-. 3 Z 4-> o c
pL. 33 10 O M
M o H CL CLl z 1H
u H O
A3
x CU 3 C
C o u
co bo c
•H -o c
-o 3 < a. o 4->
co 0) Q
CJ> CM u z §
& CU 4->
O -H CO -H 1 *-> CO Z U CU CU c
ra i cu 5} > C J3 -H CU X 1 *J x :* • H 4-1 IH bfl C l-l C i-H CJ CO CD *•> e ra co CU —i <- 0) S X 3C-H bow>, bocu
DL, O u *-> <c in »-> u O-H e s u co e JC a, o c u -H *J o U C -i-l o cu •<-* *->
*w a.M a: co w-i n-i bora c u E 4-» u • N o^a>r-( o. ra e o o bOC b0CUCUO3X-HU
CJ WH • 3 11 V J3 fH •»-» C-rtO •H4->HC*-'CUC0O C > • CU CO X CO O. -C O Jrf CO • •H « « coco oxi H-I • OfcHH CU >>*-" CU U OOC CrHrHC (0 -H -O Bl 3 -H H CO
•HVO ft«£ *« SO «rt O 0 o-os-H raboc^tii-isocu 4-> CJ E O CJ 1M C X • > 4J4J.H -.I c co curac^ucuzc ««oonidrtwc«)rtu now wracubo u u cu co co 3 cu 4-1 .H 4J CJ CU > O rt U O CU " U «J ra J3 h C O bOS CU 0"0 3 C30CCU4JU Ah c c a. O 4->| -H Wt S UWfl CO"
co cu CJ u -r-i cu m a. *-> > 4-> cu -H co u - o • c -H u ai -ora bO E l-i a. j: V O C X C X Be w O >W bOX) C0«N-H^4-iCU >% C CU -H U>UC0C*CUi-lOC CU l-i -IH Ohiw CU CU •H3CJO><Cu4->
•H HO« o ra os B ra CJ ra I-H34-" ^> U O COi-liH CO CO era C-HM-H TJ Q. C «-l O t» H CL-C Q. O O H 91 U i-H 3 CU CUC WUK C BH CU > CO 05 O » M • B «*-l B xi cu ra i-i E - i-i co o
bocucur-tu ra co -cuecu-n •rl •H ra i >> BHJHOOO'O'H 3 & W *-> O .C CU rH i-H Cu CU tJC P* CJS^Xi WBB B'QH-H^ h
4J4-I-0 (U c-H CO*-1 > ^ >*-l CJ •'-' *-> o o •H4J^CCO OOCU-rt 4-"Q. >» CJ l-l CU > -rt *J 3 CU ^ CO -H <u CU-HrHOOCflOC'OCOCJCCUCU**-' I4<U W££ IITI u WIM O C CU u tj>5oa.coai -HOJEI-IOCO COCO >(JH B U'H fi'H 01 bO
i-i OID-H-HCUOOWIIOJIJ'OII •H U cOJIU^OHUfl o*->cu4-'*JO>no'4-i>rHocbobo>>cuoo.a)^>ocBi*-i>co u ei HKinwsMidwao'rtC •HCUl-iOCOECi-ICUEC^CO CCUCJ03CUUCUvOWUCUSC»0 U A V h OA >iOHT} O O 91 U MCrtZSXW-OC0C/>E-i.C}'HMS O OZ> tlH<(9U A>n UU£ B
• • • • • «-l CN CO -a- m
• • • vo r^ co
< cu CJ >»
T3 «2H O 2 x
^ O •g as B M C H CU CU M-l CO 0M CO Q. O O CO O < to <J
r-\ CO cj CU CU 1 o to > C >ON CU T-1 pj a\ o Q U H CN CO
O
CK as i o o o r~ r- m r~
CO m m .-H m c -* sr en -* o v© v© -* vO
•H m m vo m 4M HCOOOIOCO id 1 00 u 55 • •
•H w o o • o Bxxec M-l •H u z u i co co Z 0) Q Q CM H X a. toS AiOBi
C/3 UUUhU
C o
•H 4-1 rt co
C CJ r-l o •H O
•H C CJ 4-> 3 O a B *J
c E O 3 O l-l fa U CU
M CM
O CJ £ Z c_>
44
-o cu 3 C
C o o
co bo a
T3 C
•r-l
-a 3 <
O *-> CO cu
Q
O a. U z I
R)
M-l CO o »-» o a c
cu co VJ CO <v •- CU U «•» M-l T3 >» C i-t *-> >N 1-4
cfl CU -H O "O U j= O -O -O C 0) a > u * m o -HO cu nj .e bfl
CU I CU CU CU J3 A > "O f-^ *•" Ul N -H «J JB9 e u cu o co bo co 4-1 •o J) co it a -HI—I o y • •H (0 JC U «-• box) co cu n It W ON r-l 0.-0 *-> •n CJ a >4JIMOCOC o aiT) T3 3 U CO -H CU >'H B 01 -C z rt *•" ecu.-i«Bcu JS o CTObO H B C « O D1T3 > c w BH B J=CU*-'0 -o wa,ccU-H303y3CU cu 1 O -in flj -g - CO *-> -C 0) Q.T-1 J3 4J (fl -H 1 *-> CO -C cu CO 'H « O >i 51 *-" CO CO c OSBwDUugiCMU
Q CO E CO r-l O r-l -H CU 4-> r-i
*->OCOrH-HC CU -rl •iH u 3 Q) H-I .rl -H rH (-1 -i-i C CO J3 (0 rO u -o y i-n e u 3 S •v £ VU O Cl (0 w -HSH iJ « « U O • H -H (( 4-> *-> -H o 4->i-HCUQ.CCC'C ffl c n) O bom u 3 <4-i y cu -co y -e B
C-O-H O CU C "O CJ o co oo-H u r- cu 3 4-> >»C«UCrH-H 3C CJ >o uwcoy'ocuAoou U -H c
CO .o cu .o <o i4->cooraco4-> CU CO Q. Q, CO O > CT> «J > •l-l bo CU « C 'H J) W CU r-l CO c-rt cucu*->a*Hcoi-icu CO c •O J « W 'H T) U <• C (0 0) •r-i ooyyy co cu i _o "O CO
•H CU (H N 'O fl W 01 -H £ c Wwffl X O 3 « h Bffi (0 cu cu T3 NTJ-HH C< 1-1 (0 "O •t-' •r-l VONVbh'03-H • O 4-1 4-> •rl C •H «£ A o -MSOSO +-> •o 3 >o a« o u wflu « e y •
•rl HJBS W<rl y O *•> ' 3 U CO 4-> I to <J CU 3 X •a <u C CO RM •rl C *-• • 43 CO U T3 O co *-> eoc uo cu a 01 c
4JU 0J CO "O U CU "O U cu u CU CO r-i CU y O U UM> cu cu 4-< O >» 3CU • iVi-HH i >>o > UCCUB O «u CO (0 > r-i CO -H <u Q.C0 aC W£ 3 «-> r-l CO O r-l so^cy «yrH2£
*jycoTHO(d<U(«< y Mblt-lOrHUU -o
•H a •H 4-> M taoocuocue>"o*-'43co e co co a co e
CHHH B CJ O —I B CU cu u U -r-l C cu •HCU3CU3C0CUBSCUU >-i cu 3 CO -H (1 -H CU -C r-l 3 O > "V > "V > U (U T3 JDCOO > U.HCU>BtUUtJ>*-'3 U *-< y c ovovokiouatih cu cu ^x:j=C3J30CCU-HO CU O c o O-D STifl au o oi « o-.n to BHUDBwWHBl** u e M y
ON d r-l
r-t
cu >. T5 r-l O -O
>s O B u cu cu u-i co Q. O CO O 13 <
i-H CO z CU cu l o > c < co CU -H u m O -J « r-l
o CO ON c CO o -*
•rl vO 4-1 r-i m ed 1 00 Cl 25
•H M • y-i 5 o •H u z U i cu Q CO a CO 02 w
m c O O
c O -H o a ^
•H co y 4-1 1 cu y •rl *-> c >-> o 3 C U fa < CM
M cj cm CM CJ o H
45
IU 3 B
•H 4J C o u
CO bo c
•r-l -o c
01
X c0 H
co bfl C
•c C
0)
M CD Q. O
CD "3 O u
01 CD > c CD •!-(
W c o
CO
CD a, 00
c o
u c 3
G 0) > CO
(0 14 co o •3 bO 01 -
c CD to • *-» CO 4-i 44 CD • C 4J 0) . 01 • O) x CJ 0) 4-> B H o> co •H J -rH CD CD *3 CD -3 x •rH B H CJ •H 4-» 3 rH X T5 4-1 Q CO rH C 0) X a) o r-i o 0) 0) CO CO •3 4-i 01 •H O-i CO Q.-H 4J
01 > <u 4-» O •H rH 14 -o X CD M 4-1 4-> -H • <w B x a) o > X i-> Q. 14 QJ 01 4J l-i CO CO T3 C C -3 B O 3 CD •M > s co -o E CO E O C a >, bo CD 0" CD C CJ O E
cfl CD j- c >> E o o •H >> a -a CO cfl CD "3 E •3 CO T5 C 14 01 C X u 3 CO l-i O C rH 14 CD c 3 > -4 C 0) •H 01 -H rH
•H T3 o O C -H O l-l 3 4-i rH CD rH 0) -H 4-< Q,
o 10 i—l 4-1 4-1 4-1 •l-l rH E CD o CO CO «• E a CO T3 4-1 • CO E
-o *-> 4-. 3 o C c CO CD 4-1 4-1 4-> CO E E U O -H CO 0) HH 5) C O 0) •H rH -H C E 01 CO 4J 3 O -r-i • CD CJ 4-r 4-4 4->
N "3 01 £ (-1 -o 1 (0 O >H CD CO 4J y bO •3 C C 1 >> •H C E CO 0) td M 2 4-1 •H CO l-i C X CO CD CD C rH CD CD CD 44 U rH 3 S • 3 01 a DO C 4J CO l-l 0) l-l 4-> 4-1 (A X -H O 4J -3 E rH CD •H O O CD >. 4-» o 5 o •H CD CD 3 3 CO CO 4-1 01 -H E Or > 4-1 M-l CJ "3 H CO co rH o o "3 U > 4-4 ^ •3 CO rH O CO O 3 O 0) 0) c X i •o -3 CD CO CD C CO • O CD 4-> Q. C CJ U
wo y 4-1 3 •rt Q CO < TJ B CD 14 3 CO 0) X cj C B O 4-4 CD CD CO 3 CU i-l OJ 00 0) CO iH O CD CO 4_> © CD O "H CD 44 U
T3 > id bOr-H 03 -O u W rH 01 3 -a 4-1 U C CD u g 3 4-1 4-> O
O c a > CU (0 3 • X i-i •a CD cj o s a. Q. C CO CD -4 Cj 4-> 4-1 -H a N 4-1 S-.-0 CO CJ <0 oiiii 3 o. O -H C rH -3 O
c 4-i bO o -o •H 01 X o rH -i-l E CJ 14 CO CO 4J CO rH -H Q. CD 14
bo CD O bO u OJ H u E CD X CO • CD CD CD C 3 CD bO S E X) U
c E 3 "O •i-< O.TJ X > B CD CO X > "3 l-i 0) 4J > C CO O X 0) •H a.-o xi -3 o w 0) r—1 CO O "3 3 CJ CD t-> nj CD -H X CJ 3
bO O CD 0) 01 o 3 • OJ U (0 I—1 CO •rH o O co C CD CO 4-> •3 > CD C *-• O bO<H X T3 > i to r-1 •H l-l rH 4-J CJ l-i 14 14 14 X -H CO (0 -H CO C 3 CD X o n c a; 3 3 0) CD 01 CO CD CD 0> 3 4-> W 4-4 X CD
XI > 3 0) s U 0) s T3 o- > C X CJ CD E > X <-> C rH •H *& *3 *3 *3
CD 01 4-* x OJ cfl Oi rfl O 0) CD •H CO O X 3 CD 4-> CD 4-4 O rH C CO O C C C Q "3 co H u 3= X C s: M C/0 rH rH rH 4-J Z C O H O O A 3 CO U (0 CO Cfl
m
o ro
ca O u o < -<t CO <r H n sO <m Csl <•
m <t m v£) <r ve r~. CO ^s m VO CO in oo u~l 00 CO • • • O
• o o z O Z 2 z z:
00 H S ^r Cu C7 0-i CyO in 6u u
-I
H X E CD CO CO
-) < Z
I o <c o OS rH
I z w • S o cj 2
l Q W 00 OS Cd OO
CO U rH co <r \o m en <•
vo m u-i co co
• O o 2 2
c/o s* O-i CrO in
o en
i <H
o -<r rsl ro m •* r~ vo v£> u-| in co co
• 3 O 2 2
H £ O OL, IJ4 U
o o a.
oo i
CD I r-i
O X 4-> CO Q.-H >% 14 l-i CO < o >
o l-l 4-1
c o o
X E CD CO CO <
o
a r- O ON CO
Hin vo i co m 2 co
o ro
I <; ro en a"v -<r •1-HC1 ro co -* •^- r~ vx vx \o in m m co co co
CJ I a
CO www
o • z o 2
c/3 0(5 ~T
• • O O O 2 2 2
S CO H X Cu O 04 C/3 Pu C_>
E E O 0)
CJ o •v to pti 4-1 3= U 33 CD "»» 4-> Cv, C
O Cu u
C4 >
w DM H
A6
0) 3 C
C o cj
co bo c
•H T5 c
•rH E*
-o 3 < Q. O 4-r
CO <u Q
CJ
OJ i—I X
03 H
"3 e
0> 0) CO >> . CH • *-> o o> U IH O >H c o 4-T •tj CO >% CO "O bO
•H U -H C • 01 X >« > 4-r > 0> C H-1 co co • 01 •O 4-1 o» o X *-> 'rt « O -H A a 4>> ca *w 1-1 c O 4-1 C >»-H x 4-1 H44 E 4-r . N co c at o o o O O O rH X O -H O CO CO)
•H a* •<-* c 4-1 •H 01 0> > rH 01 CO X C/l X 0) T5 c CJ co TH to c 4-J vee ri >vh X co e a o
•3 ^v a en § u O U B u w o U X 01 O 0) rH 01 01 o *-> u e s c o 3 4-> X -rH > C > tJ 4-r C > CO • 1 o X C O O 01 In X CO O 01 o O CO O O C CU CJ C o s ^ u a J-' W 4-1 3 CO CO co o •O 4-> rH O 1 0) C 01 o CO O •"-• -rH 01 CD 01 tl CO 3 -H B ~ 4-r >-, 0) «-i u u c c CO 6 rH N CO 4-1 -t-" C U N-' 0) 4-r C *-> co xi r-i co -H •rH CO CO X -rH -rH O •H O co *-* co co o -H
3 01 3 TJ C O C (0 c X B -H > "3 -H CJ -H -rH U -O O O 4-r CT •rH a O 4-r (0 4-r bOH *-> •H 4-r "3 0) B -H 4-r »
co C *J -i-i 1 0) T3 o •H -H O C rH CO l-l T5 -H 4-1 "O m bO ro 4-1 4-i u o 10 U Ur\y 3 • O CO CO rH -H 0) 4-r 01 c TJ 4-1 rH 0) H US Q 0) • o -o
bO 4-4 X l-l -3 N CX
•H C C «H 01 XI bO VO^Fhwio bOTJ O -H 01 4-r •3 O S'O »« CO bfl > 3 ^ CO CO -t-1 •H -H 4-1 0) C B rH B C •H O -H CO c •o a o a; co CO 4-r O "3 CO "V -rH 3 C
•H 4-r 4-1 "o 9 > • 3 •rH MISCw 3 U V Ot O 01 *-> CJ -H ex co c ou .H -o I_I *-> IH o crx *-> T3 B C "3 b0*3 3 O
N e co o <-> i a. B CO -H •H'O (J W • O 01 C CO -3 01 >> •H Xi C Z o o c e • *-• ai u at 4-r kl U •H -H -rt U 0) tH a> rH 4-r X "3 CO Ed
(0 -H 01 C -rH S o ex •HTI W a« -a x CO O O 4-r 4-1 CO bO bO 4-r 3 £ H CO • rH 01 -H (0 4-r 0> 4) « w CO -rH CO CL CO • O 4-T
•H U i—1 (TJ rH CJ 81 •H rH )-l CJ U O "3 4-r U (0 3 4-r 0) 3 3 CJ O 4-r o a. O. 1 0> U rHCU30C03rH 01 U rH C O bOW Jrf 3 •H MEI SO C U CU l-l "O CO 3 Q.T3 3 X 01 ItOJOIiBI/lUli CH O 3 O CO •iH o UOIOOIUOIVO < o o. >•© H O «< « w
Ed -H CX4-J rH CO -J CO H cO CJ M CJ W .J a Bi > S'Of M h O « z o
CO <r H Csl H fsj
oi >> •3 rH
O X ^ CJ a o U 9 M 0> 4-1 CO CO o. o CO < o •2 < -> eo
rH CO z z <U 0)
> c 1 o
< o J:8 V -<H CJ o o >a- O -J OS on
o co
CJ 1 CM vO vO r*. •* oo •*
as CM
O CO
CJ 1 00 CM vo in CM r>- -a- oo m i
CO npiHcn co en IH o m c -t>tcn>* «* »• co co in o vo vo r^ \o \o '•o r^ vo o
•1-1 in in vo m in m vo «H co 4-r <H eo oo in oo r-i oo oo m oo vo a) 1 00 i eo r-4 a z • • Z • • • 00
•H w o o • o 5 z z o z Ed o o • o 4-1 _» z z c z • •H cj Z CJ Z O o 1 CO 00 x 1 CO CO X Z at Q Q Or H X Q Q OH t- X a. UO DM O, O 0- CO OH OH O OH X V] M O U 0- O
bO bO C C -H
Ed U CJ Ou CJ 5
e o
1 -rH |
c •rH H •H 4-r C o U U C CO -H 01
•l-l CO O O M N CO CJ t* 3 H a. •H X C V 4-r -rH 01 CU rH CO e CO C OS H CO -o c 3 4-1 O •H -rH C 01
Gh IOZ4 CO 4-r CO 4-r
M H cj E- DM CJ
>-r pa £
47
0) 3 C
C Q a
co bO c
"O C
•rH Cu
4-J 4-1
rH • *-> a cu CO CO CO 3 0) -o a* u O • CU r-\ rd C 3 O -O cu cu > z C "4-1 • > 3
O O -H •• o J3 -H O -H X u-i CU CU -o .C -H C >4-t C "O O 4-i 14-1 4-> t-i >, o U •co o o O " 'H m 1W O C 1 •H a t—i *-> n) C ai B 9 O ** O «H -H tfl O y-i -w c rd u 0) -C T3 O C8 > CO 3 C "O W 4-> o c o u o *-> -C oj 4-i e cu cu
u o •" u ai i CU -H OJ OH 4-1 bO-O CU -H 1-1 - *-> O C to V 3 J to "O *-> *-> Q. 3 • 6 J3T) 4J 14 • rd
co co a) cj> s bOQ c -H c« c CJ .e cu -H 3 cu e 4-4 co > cu e cu s cm • c rd a. O CJ M CO -H 4-J ng bO 4J !> -H CU XJ 4-1
O-HJSHIUSO> •H *J -H flj 4H •H O bO CO O (0 U rH ht-l •H 4-> > O CJ MH 4-> O >4H CU > y-l > CJ 3 SB 0> o 4-> c o cu I-H - o CJ e -H co -H -O >> 0> O -H CO CJ'H"0 B-Ci-H <U CO C •w O ^N-O c -o cu -—1 IH V WU rd o e w co a u 3 CU O O-W o VO C rH cu IJ •<-> rd T3 >4H O rd C ^ l-i C U Q CO •H a. o oi CJ to cu 4-1
O. U CU CJ U -H CU 3 M ft! 4-1 o u j-i >, o> i cu 01 O ~ CO T> T3 1 b0r-l *-> > B Ou rj > o i-H O 4-i O i-H vH rH bO M«u > fl C OO C U 1 ^ ca 0) *4-i 3 O 1 -Q 4-i a. C C B B B 10 w b III OO fl rH 4J M > jO 4-1 01 (0 B
•H •H - cu > i a. > E CO i-l It BH cu 01 >> MH -H TJ o • TJ BCSJBO --O.J -H cu r~ rd ui cu 4-1 TS rH ~ "O -H IH C u c C S r VQ » BQ-O CO • bO^x cu *-> c 1 CO «H u « c o
•H rd 4-< O nib HI B B rd <H rH C CO • •r^ C O CU J3 > •iH -H C* U iu (8T3H P U <U O EH |J CU Ss"0 O > CU OI X 4-1
MO*' C^-l CO .* 3 .C -rt <TJ o -oco o) CO •HTJ O 0) 4-1 W 4-1 4-i rd >> O co rt Li ig w u u B X -H U 4J 4-1 « OJ BTJ « o n CJ 4-1 01 U 01 S 0) 0) O U «J
a.cocD'T3ra'0»3 CXI-H < *J o » >. c •r-l cd co cu o 4-4 -o cu c
M B > H « C< rd cu CJ 3 IJ CJ -H CU u cu 3CUUC ^ E 0) cu u rd H H 1 0) •H rH CO 4-4 i-i B
u O A MS >.w O h *-> o o h as CJrHCUCCO'HSU O 3 O 01 » O h III U h 10 Z CU CU CO CJ nj Q--3 CU -H CJ CO ft) CJ CJ oxscauocucco >>x o ar -H o 1-4 a. o oi JS « -H 4.. c o
Cu 4-> .ri 3 Q. 4-< > 3-H O c/3 U z O H Q T3 4-1 cd o .o H MH x co H T>
• • en sr
• • • rH CM CO
• • rH
01 >» T3 Z i-H 5E O 3 xi 3
•x o OS E 05 u H cu p 01 U-l OS co OS a o O CO o o Ob< —) Ex.
rH CO o z <u a; 1 o o 1 o > c 30* < o CU .rH OS o o u o a -J Ei -» CO
o CO
oca i oo OQ CM CO 00 CM co CT> r- r- -* I
OS CM
a r--
CO M*l f) H ro 00 ON c en ~* -* co ~» -* CO o -* vo vo r^ vo co vr
•H lOinifnom-t vO 4-4 .H in oo oo uo co \o rH m cd 1 CO 00 m i oo CJ Z • • • • 00 2
•H Cd O O O • O Qu * IM 5 z z z o z • 5 o •H u z o o z
CJ i w oo co x Z 1 o a Q Q a, H X Q CO a. CO Ok M 0M O OU S CO OS co HUhUhUD
•-0
Cd CO
cu 1 c
M -H oi -e
c a. CJ o >> CO O rd
•iH co n *-> X 4-> 3 rH IH >. o *- Q. O 01 l-i c rd co a. Jai O 3 4-> •!-! CU CU 4-1
Cm CO Q OS OS rd
M u M O cm • X
o o u OS
48
-a <v
-a 3
o c o o
en bO c
..H -o c
-o 3
<c a. o 4->
Ji en
a
o a. o z I
id
ItH 01 o o -o
rH 4-> -O c en oi i >. J3 01 c o e a n M
rH fl 4J 4-1 rH bO rH -H •H bo 3» -H 4-> 01 -HO C rH a u 4-< >rt > C • 4-> i-i c a* oi rt •H b T) ed en 4-> y oi bo
rH > 4-- E-i B » C_> 01 B y rH « e c O -H 0) u -y y -H
O. 3 O en JS 01 4H JS O OIH^ s OJ -o a -H en JS -ri 4-> 14H 4_i . _Q Q, y O (0 4-> 4-1 • c • c en By CJ O J T3 HJ 01 CO C u y -rt t-H y en y »H JS C JS < 0) rH 4-1 MH 01 O C I utifl y
•n 4-> Z > -O 3 • U O -0*4-1 •H j>i z w y o 4-> 3 o oi -o >» <fl 'H 4->y_o-Hoyei-i
3 o S tn - y o w « w 1 *y o <-* JS a c 01 en H 0) 01 6 JO C QJ X l-i 0J B
y -H • 01 o OrHCJ C D.y4-> U JS bo u •-. U -Q 1 O £ 01 U
•n C W C « 01 oi en a oi 4-« Q a bo 4-1 -ri y en w ft oi to u e -H » e y u en c c co bO 3 4-" -O JS *-> U 03 3 o en Oi y y w -H -H 4-> c rH c O 3 01 C 01 < 4-> -H en en > •H XJ j>d « o nj
•H U O U O 0) _c ei u-ri oi c > f« >»T3 y JS o c -o i-i nj 4-1 s 4-> u 3 m B -H o in y ja c y *•> u c 0) rH 0) 0) o tl rH y u y JS nj JS n) y
•H ci >> o -o 4-> jS 4-> oi en c en "o o "O 4-J Ph •H i—I 0) 01 flj 3« SB en IJ -n oi bo y y y y y c
> JTJT3 « <j U 4-> C 4J4J t| W U'W'C'H >. U • B 01 en >.05 -o oi tn tn -H a. y -ri y o C -n OJ oi "o oi en oi wh 01 4-1 01 -H a 3rH3rHI-iy>>4H
txS tn 0) en <v c c_> TH DS rH c c tn rt ua.eya.uBOO C W rH H 4-> O •rl TH -rl C C i_i B y B y i u
X -n < 3T3J CO* rt 4J o y o u o o a. c E-i MH T3 01 OQ Oi *J <u 3 o oi 4-i ci y y y o cc v c o nbtj >> >T3rH B SClcHi
01 Si O C J= cctncjsyo-H
CM CO rH CM CO -3-
a> >> >% TJ i-i Z rH o JQ •C J3
-S O S Cd E u 01 H 0) 01 *4-l en CC en a. o en O en o < >-> 0u <
i-H en z 0> 01 O i m o > c o < vo CO 0> -rt o U O rH o J CM OS rH rH
O o CO CO
CQ 1 CO S3 1 CO -» uo CM a >* m CM CO CQ vO vo <*"^ ON ^ 1 *"N r- PQ co in VO r^ CT* ^N 1 >^»
to cocoo>r^OcMCJ\OU <T> co co <y> MHtNH>OH c >*cMCMin>r^><^> CO CM ** CM in xr^ SOM o ^£>COI^P^UvOOCMO -» co vo r» r~ O vo o CM O
•1-1 m-^-vo^asmoSi^os vo>a-mvovoosinci5r--ptf 4-1 oo vo in in co vo Hirnocoin m co vo flj m oo co i* UB in >-8 i co m co CC ^3 <Ji in <J3 o • CO -co Z co • CO
•H O • • i-t O \~t M w . o • • u o o o 14-1 z • o oizr • x » o • z o o > z > • > •r« o z z o o o o CJ z o z Z O V o u a tn Z OJZP4Z OS 1 Z W OS Z OS Z 0! 01 Q en H w X >^ >•' Qt/3 a tOH v/JE w N—' a. H-*(lO OH X t/5 PS sr M Oi o a. z
en CL, e/) en £ u 5 u in tn OI tn
>> c
Cv, O S
01 01 o c Cl J«! -H o «d 4-> rH
•H I4H O nj O 4-» U N h h <J OI 0U 01 4-> c 4-> 5M C C 3 c 05 01 O £ M u bo o
M u u > a, u o 05
49
Contractor documents relating to the COMSEC and TRANSEC security areas
and their impact on acceptable software implementation were also reviewed.
Since the contractor's submissions of these documents were behind schedule,
and when initially submitted were incomplete, the Government was at risk.
However, no significant design deficiencies were identified, and after dis-
cussions and technical interchange meetings with the contractor, the docu-
ments were finally approved. Detailed discussion of these issues may be
found in appendices C and D in a separate report.
3.A VAX AND MICROPROCESSOR DEVELOPMENT SYSTEM TEST ENVIRONMENT
3.4.1 Activities
Compiling and simulating the GWEN software in the SQA laboratory gave
us insight into the sizing of each individual CPCI, its software execution,
critical path and timing functioning, and its design. The review and vali-
dation of the GWEN TRANSEC algorithm and the packet processing algorithms
in the NC received special attention.
Once the source code was received from the contractor and had been
through a desktop audit, it was assembled into Intel-formatted Absolute
code. A suite of First Systems products (FORTRAN and cross-assembler com-
pilers; linker and locator) was used for compilation of the FORTRAN and
Assembly code. The code output from the First Systems tools was then down-
loaded through the Boston System Offices (BSO) "Converter" for execution
within the BSO "Simulator" on the VAX 11/730, or it was downloaded to the
HP64000 Microprocessor Development System or the EPROM programmer for exe-
cution on the MITRE node hardware. The compilation and assembly of the
FORTRAN source code and the Assembly source code utilizing the First Sys-
tems and BSO tools are presented in figures 13 and 14, respectively.
50
The Boston Systems Office software is a complete family of software
development tools which were installed on the VAX 11/730 in the SQA
facility. These tools included 8085 and 8086 cross-assemblers and symbolic
debuggers, format and object file conversion utilities, cross-linkage (link
and locate) editors and linkage librarian programs. The utilization of
these software tools permitted easy transportability of the RCA-developed
source programs into the MITRE SQA facility for analysis and testing, and
full debugging of the operating software within the CPCI microprocessor
application. Memory manipulation commands (both RAM and ROM), any instruc-
tions, program jumps, interrupts, and input/output instructions were easily
tested and traced. Cross-linkage editors, load maps and formatted ASCII
text were used to generate listings to verify the locations of the program
sections and global symbols in the absolute load module which was developed
during the linkage process.
Based on the GWEN software architecture presented in figure 5, MITRE
developed three distinct configurations utilizing the Microprocessor
Development Systems. Figures 15, 16, and 17 show the three configurations
employed by MITRE during the SQA effort. In the figures, the location of
the HP64000 workstation containing the software state analyzer identifies
the CPCIs under which critical timing and throughput requirements were
assessed: the Network Control Processor, the Human-Machine Interface Pro-
cessor, and the TRANSEC Control Processor. With the two HP6A000 and the
Tektronix 8550 Microprocessor Development Systems, and an HP 1631D Logic
Analyzer equipped with additional 8080 and 8085 emulators, MITRE had the
capability to monitor the message flow and processing within the entire
GWEN 1/0 node testbed. The TRANSEC simulation was developed and used to
assess the strength of the RCA-developed TRANSEC algorithm. The C0MSEC
Interface Logic simulation was developed and used to test the operational
functioning and integrity of the CRYPTO bypass mode of operation between
the C0MSEC Interface Processor and the Network Control.
51
FORTRAN SOURCE
£
INTEL 8086 SOURCE
FIRST SYSTEMS FORTRAN COMPILER
£
I FIRST
SYSTEMS CROSS-
ASSEMBLER
8086 OBJECT
CODE
T FIRST
SYSTEMS LINKER
T INTEL
FORMAT ABSOLUTE CODE (8086)
£ DOWNLOAD TO MDS OR EPROM PROGRAMMER -EXECUTES ON NODE
HARDWARE
1 BSO
CONVERTER
DOWNLOAD TO MDS OR EPROM PROGRAMMER -EXECUTES ON NODE
HARDWARE
1 BSO
SIMULATOR
£
I EXECUTES ON
VAX 11/730
Figure 13. Compilation/Assembly of FORTRAN 8086 Code
52
IR-769
INTEL 8085/8086
7 BSO
CROSS- ASSEMBLER
T BSO
FORMAT CODE
BSO CONVERTER
I
1 BSO
SIMULATOR
DOWNLOAD TO MDS OR EPROM PROGRAMMER -EXECUTES ON NODE
HARDWARE
J. EXECUTES ON VAX 11/730
Figure 14. Assembly of 8085/8086 Assembly Code
53
IR-770
ERROR DETECTION
AND CORRECTION
TRANSEC FRONT-END
BUILT-IN * TEST
EQUIPMENT
i»
\ \
4 •>
ERROR DETECTION
AND CORRECTION
N.
t \8085 s
TRANSEC KG
TRANSEC CONTROL
PROCESSOR
\ I *- -*
P
"\ TEKTRONIX
t \ CYCLIC REDUNDANCY
CHECK
WORKSTATION
\ /
TRANSEC VARIABLE
PROCESSOR NETWORK CONTROL
PROCESSOR
\ 808 •
- i \
, < COMSEC INTERFACE
LOGIC (BLACK)
\ r >
HP64000 WORKSTATION W/SOFTWARE
STATE ANALYZER V J
\ KG-84A *\
1
\ i \
\ \ \ \ \
f \ \ \ \ \ \
r RED/BLACK
FILTER RED/BLACK
FILTER
t i i
COMSEC INTERFACE
LOGIC (RED)
t COMSEC
INTERFACE PROCESSOR i PRINTER * \
\
f V \B088
V \ HUMAN-
MACHINE INTERFACE
8085 N^
v \ r
HP64000 WOR KST/ TION
Figure 15. Microprocessor Development System Configuration 1
54
IR-771 |
ERROR DETECTION
AND CORRECTION
TRANSEC KG
I •4 •>
TRANSEC VARIABLE
PROCESSOR
TRANSEC CONTROL
PROCESSOR
I NETWORK CONTROL
PROCESSOR
COMSEC INTERFACE
LOGIC (BLACK)
TEKTRONIX WORKSTATION
I RED/BLACK
FILTER
s s. aoesX
COMSEC INTERFACE
LOGIC (RED)
PRINTER
I COMSEC
INTERFACE ... PROCESSOR {
-4 » HUMAN-
MACHINE INTERFACE
TRANSEC FRONT-END
ERROR DETECTION
AND CORRECTION
BUILT-IN TEST
EQUIPMENT
N8065
8068
CYCLIC REDUNDANCY
CHECK
HP64000 WORKSTATION
KG-84A
RED/BLACK FILTER
.»_ 8086
HP64000 WORKSTATION W/SOFTWARE
STATE ANALYZER
Figure 16. Microprocessor Development System Configuration 2
55
IR-772
ERROR DETECTION
AND CORRECTION
TRANSEC FRONT-END
BUILT-IN * TEST
EQUIPMENT
" ERROR
DETECTION AND
CORRECTION
1 I i
8080 TRANSEC
KG TRANSEC CONTROL
PROCESSOR i L
/
CYCLIC REDUNDANCY
CHECK
r
TEKTRONIX
' \ WORKSTATION
TRANSEC VARIABLE
PROCESSOR NETWORK CONTROL
PROCESSOR /
6068/ /
i i
/ COMSEC
INTERFACE LOGIC
(BLACK)
/ s HP64000
WORKSTATION W/SOFTWARE
STATE ANALYZER V J
KG-84A
1
i i
t RED/BLACK
FILTER RED/BLACK
FILTER
t i i
COMSEC INTERFACE
LOGIC (RED)
t COMSEC
INTERFACE PROCESSOR i PRINTER
t V >
\ 8065 HUMAN-
MACHINE INTERFACE
v
8086"""""
r ^ HP64000
V VORK STATIO NJ Figure 17. Microprocessor Development System Configuration 3
56
3.4.2 Summary of Findings
Detailed assessments of the GVEN software ROM and RAM utilization were
prepared and provided to ESD for information and to the contractor for cor-
rective action. Our initial findings are summarized in table 11. We iden-
tified potential deficiencies in the memory expansion capabilities within
the CIP, TFE, TVP, NC and HMI CPCIs. Table 12 identifies the GVEN drawer
board assignments which supported our conclusions. Presented in tables 13,
14, and 15 are the final ROM and RAM utilization figures which represent
the contractor's solution to the preliminary memory sizing deficiencies.
In addition to verifying ROM and RAM sizing requirements of the individual
CPCIs, we identified several other problems within the NC CPCI which were
forwarded to RCA for resolution. These problems included:
• Possible return of memory packet processing allocation to the
caller without deallocating the buffer used to store the packet.
This rendered that block of memory unusable and could have led to
eventual depletion of the free memory pool.
• Incorrect modification of interrupt service routine prior to its
being written to the Programmable Interrupt Timer (PIT).
• Use of stack pointers within the executive service routine, PIEM.
Stack pointers are prone to errors caused by hardware interrupts,
which require retrieval of objects from the stack that are out of
the normal sequence (i.e., below the top of the stack).
57
Table 11. Preliminary ROM and RAM Memory Sizing
(April 1985)
Meets CPCI Used Install 50% Req Expand 100% Req Maximum Req
ROM (Program) Memory Sizi ng
BITE 7.71K 32K 11.57K 00K 23.14K 64K No CIP 11.90K 16K 17.85K 00K 35.70K 64K Yes TCP 10.45K 32K 15.67K 00K 31.34K 1000K No TVP 7.71K 32K 11.57K 00K 23.14K 1000K No TFE 8.31K 16K 12.47K 00K 24.94K 64K Maybe NC 98.85K 128K 148.28K 128K 298.56K 1000K Yes HMI 104. UK 128K 156.17K 128K 312.34K 1000K Yes
RAM (Data) Memory Sizing
BITE 0.55K 4K 0.82K 00K 1.64K 64K No CIP 7.17K 16K 10.75K 00K 21.50K 64K Maybe TCP 0.95K 4K 1.43K 00K 2.86K 1000K No TVP 1.50K 4K 2.25K 00K 4.50K 1000K Maybe TFE 1.03K 16K 1.53K OOK 3.08K 64K No NC 75.07K 256K 112.58K OOK 225.15K 1000K No HMI 220.00K 256K 330.00K 256K 660.OOK 1000K Yes
Used - Current assessment of the CPCI size.
Install - Memory installed on board that will accommodate final version of software.
50% Req - Requirement specified in ESD/GWEN-1 that memory capacity installed on board shall exceed amount occupied by final version of software by 50 percent.
Expand - Capability for additional memory expansion without board or drawer redesign.
100% Req - Requirement specified in ESD-GWEN-1 that the memory board shall be capable of supporting twice as much memory as the 50 percent requirement amount.
Maximum - Maximum memory the CPU processor can address (ROM and RAM together).
Meets Req - Quick indicator of whether CPCI is or is not meeting GWEN memory requirements.
58
Table 12. GWEN Drawer Board Assignments, Memory Expansion
Drawer Slot Board Description Board Type
TIP I/O 1 Power Supply Equip RCA Design 2 CIP Processor 80/544 3 CIP I/O 80/544 4 HMI Communication 80/534-2 5 HMI Communication (not used) 6 (spare) 7 (spare) 8 HMI Expansion 9 HMI RAM 80/056A
10 HMI ROM 80/164 11 HMI Processor 86/10 12 CIL Red RCA Design 13 Red/Black Filter RCA Design 14 CIL Black RCA Design 15 (spare)
TRANSEC/NC 1 (not used) 2 EDAC Board E-FXA 3 TCP Memory E-FXB 4 E-FXC E-FXC 5 TCP KG E-FXD 6 TCP Processor E-FXE 7 Red/Black Filter E-FXF 8 Black I/O #1 E-FXG 9 Black I/O #2 E-FXH
10 TFE Processor 80/544 11 TFE I/O 80/544 12 NC Processor 86/10 13 NC RAM 80/056A 14 NC ROM 80/164 15 NC ROM 80/164
BITE 1 I/O Status Board RCA Design 2 Clock Generator RCA Design 3 (spare) 4 BITE RAM/ROM 80/164 5 BITE Processor 80/10A 6 (spare) 7 UHF Modem RCA Design 8 UHF Modem RCA Design 9 I/O UHF Board RCA Design
59
Used
Table 13. CPCI Memory Usage
(November 1987)
Used Maximum Installed CPCI Version ROM : RAM ROM : RAM ROM : RAM
BITE 7.05 2715 : 750 8K : IK 4K : IK CIP 7.17 11911 : 6582 16K/32K : 16K/32K 16K/32K : 16K/32K GMNC 5.11 NA : 139400 NA : 5MB NA : 2MB HMI 7.19 120072 : 243518 256K : 256K 192K : 256K MT 7.40 NA : 108215 58K(1) : 438K 58K(1) : 128K(2) NC 7.32 142470 : 128173 256K : 256K 192K : 256K RCVC 6.03 39259 : 78219 256K : 256K 64K : 256K x2 ROMI 6.02 101698 : 91903 256K : 256K 128K : 256K TCP 7.20 7192 : 992 32K : 4K 16K : 4K TFE 7.20 6078 : 1112 16K/32K : 16K/32K 8/32K : 16/32K TVP 7.17 4844 : 828 32K : 4K 8K : 4K
Current assessment of the size of the CPCI,
Maximum - Maximum memory the CPU processor can address (both ROM and RAM together).
NA - Not Applicable.
(1) ROM is not available for use to the user. (2) RAM consists of 64K internal and 64K external.
Note: Double-density boards are used only for HMI and NC. Unit size is in bytes.
60
Table 14. ROM (Program) Memory Configuration
(November 1987)
Chip Type Used Insta lied: Requ ired CPCI (Quantity) Memory Expansion 50* Exp : 100% Exp Remarks
BITE 2716(2) 2715 4096 : 8194 4072.5 : 8145 CIP 2764(2) 11911 16384 : 16384 17866.5 : 35733 1
27256(1) 11911 32768 : 32768 17866.5 : 35733 •
GMNC NA NA : NA NA : NA HMI 27128(12) 120072 196608 : 262144 180108 : 360216 1,2 MT NA NA : NA NA : NA NC 27128(12) 142470 196608 : 262144 213705 : 427410 1.2 RCVC 27128(4) 39259 65536 : 262144 58889 : 117777 ROMI 27128(8) 101698 131072 : 262144 152547 : 305094 1,2 TCP 2764(2) 7192 16384 : 32768 10788 : 21576 TFE 2764(1) 6078 8192 : 16384 9117 : 18234 1
27256(1) 6078 32768 : 32768 9117 : 18234 TVP 2764(1) 4844 8192 : 32768 7266 : 14532
Used
Installed
Expansion
Req 50% Exp
- Current assessment of the size of the CPCI.
- Available memory installed on board.
- Total memory available without board redesign.
- Requirement specified in ESD-GWEN-1 that memory capacity installed on board shall exceed amount occupied by final version of software by 50 percent.
Req 100% Exp - Requirement specified in ESD-GWEN-1 that the memory board shall be capable of supporting twice as much memory as the 50 percent requirement amount.
Remarks 1
2
*
- Board being upgraded to use 27256 bit memory chip to meet 100 percent requirement.
- 50 percent requirement met by populating entire board with current memory chip type.
- Cannot meet 100 percent requirement.
Note: Unit size is in bytes,
61
Table 15. RAM (Data) Memory Configuration
(November 1987)
Chip Type Used Installed: Requ Lred CPCI (Quantity) Memory Expansion 502 Exp : 1002 Exp Remarks
BITE 6508(8) 750 1024 : 1024 1125 : 2250 *
CIP 6116(8) 6582 16384 : 16384 9873 : 19746 1 64-02M(4) 6582 32768 : 32768 9873 : 19746 2
GMNC 1394000 2M : 5M 2091000 : 4182000 *
HMI 4164(32) 243518 262144 : 262144 365277 : 730554 3 MT 108215 131072 : 448512 162322.5 : 324645 4 NC 4164(32) 128173 262144 : 262144 192259.5 : 384519 3,5 RCVC 4164(32) 78219 262144 : 262144 117329 : 234658 3 ROMI 4164(32) 91903 262144 : 262144 137855 : 275710 3,6 TCP 6116(2) 992 4096 : 4096 1488 : 2976 TFE 6116(8) 1112 16384 : 16384 1668 : 3336
64-02M(4) 1112 32768 : 32768 1668 : 3336 TVP 6116(2) 828 4096 : 4096 1242 : 2484
Used
Installed
Expansion
Req 50% Exp
- Current assessment of the size of the CPCI.
- Available memory supplied with board.
- Total memory available without board redesign.
- Requirement specified in ESD-GWEN-1 that memory capacity installed on board shall exceed amount occupied by final version of software by 50 percent
Req 100% Exp - Requirement specified in ESD-GWEN-1 that the memory board shall be capable of supporting twice as much memory as the 50 percent requirement amount.
Remarks 1 2 3 4
5
6
Use 64-02M chips to meet 100 percent requirement. Only 30K (30720) of the RAM is addressable. 44 chips/board: 32 for RAM & 12 for EDAC. 50 percent & 100 percent requirements met by installing additional (external) 64K memory modules. Slot #15 in TRANSEC/NC drawer used to provide an additional 256K to meet the 100 percent requirement. Extra slot, XA14, used to provide an additional 256K to meet the 100 percent requirement. Cannot meet 50 percent and 100 percent requirements.
Note: Unit size is in bytes.
62
Utilizing the Boston System Office 8086 symbolic debugger running on
the VAX 11/730, we accomplished a detailed analysis of the GUEN software
queue structures. The VRTX executive program, together with the individual
CPCI executive augmentation code written by RCA and TRW, provided the CPCIs
with multitasking management, memory allocation, and intertask, communica-
tions and synchronization. We found that in the RCA-developed CPCIs, the
VRTX augmentation routines were consistent with the requirements of the
CPCIs. TRW developed the HMI and NC CPCIs. We found that while the HMI
used the executive service augmentation code properly, it was overused in
the NC, with many nonessential routines and calls. Another point which we
noted during our analysis of the queue structure was TRW's use of recursive
calls within the module design. This implementation is not straightforward
and made debugging and maintenance of the code more difficult. We dis-
cussed our concerns with RCA who agreed to restructure the TRW design to
make it consistent with the NC requirements.
A detailed analysis of the RCA system timeline was completed in April
1986. The results verified that the NC does initiate the proper transfers
to the TCP in the proper sequence and with relative timeliness, according
to the RCA system timeline. Additional discussions on the RCA system time-
line and its relationship to the MITRE measurements and findings are pre-
sented under separate cover in appendix F.
Throughput limits for input and output of messages within the BITE
CPCI were never defined as a specific development requirement. MITRE's
preliminary testing identified a potential problem with the BITE design,
which uses a ring buffer as a temporary storage media. Under a stress
condition ("stress" defined as the input and output of message traffic at a
sustained processing rate of one message in each direction every 2/3
second), our preliminary testing identified a potential for the ring buffer
to saturate, resulting in the overwriting of traffic on the ring. RCA was
reluctant to test this requirement as it was not a specific development
requirement. Accordingly, we wrote a program for use in the SQA facility
63
which stressed the BITE, making it receive and originate a file of 100
messages at a sustained rate of one message in each direction every 2/3
second. The program was executed in the SQA facility, using the actual
BITE code developed by RCA. Several scenarios of the test were run, all
of which determined that the BITE performed properly and was able to handle
the node's traffic as well as the maintainer terminal traffic under the
stress conditions. Additional information related to this test effort is
presented under separate cover in appendix G.
Taking the same instructions utilized by RCA in the development of the
GWEN TRANSEC algorithm (derived from the classified appendix to the GWEN
Statement of Work), we developed our own TRANSEC algorithm which was
incorporated into the TRANSEC simulation and downloaded into the MDS envi-
ronment. Test inputs for our simulator were obtained from RCA, along with
copies of their TRANSEC algorithm test results. After executing our simu-
lator with RCA's test inputs, a comparison was made of MITRE's and RCA's
actual results. We found both sets of results to be identical, providing a
high level of confidence that RCA had correctly implemented the algorithm
and provided the required level of TRANSEC strength. To complete our
assessment, our test results were compared to NSA's (the original test
input supplier) expected results. These were also in agreement. Based on
all results of the TRANSEC algorithm tests, we advised ESD that RCA's
TRANSEC algorithm would provide the level of protection required by ESD-
GWEN-1 and the GWEN contract.
The CRYPTO bypass mode of operation was tested on the MITRE-developed
CIL simulation software. The simulation software, together with the COMSEC
Interface Processor software, was downloaded from the VAX into the MDS
environment. Using the MDS we verified that RCA's COMSEC Interface Logic
design would allow message header bypass to the Network Control from the
COMSEC Interface Processor, would properly validate the header portion of
the test message and would maintain the integrity of the red/black message
processing between the CIP, the KG-84A and the NC. By having used the CIL
64
simulation to replicate the RCA CIL board design, we were able to advise
ESD with a high level of confidence that RCA's software correctly imple-
mented the message header validation and bypass, while retaining the integ-
rity of the message red/black, communication.
3.5 MITRE NODE TEST ENVIRONMENT
3.5.1 Activities
MITRE's GVEN node testbed environment is a replica of a GWEN Input/
Output station, running GWEN software on commercially available Intel
microcomputer boards. Some of the GVEN hardware was custom-designed by RCA
(TRANSEC functions for encryption/decryption, red/black, filtering, EDAC and
CRC) and could not be constructed with off-the-shelf Intel boards. In
these cases, MITRE used Intel-equivalent boards and simulated the custom
RCA functions with MITRE-developed software.
The MITRE node configuration, presented in figure 18, shows the HMI
(8086), CIP (8085), CIL simulator and the NC simulator in HP64000 emulation
memory. Intel hardware boards were used for these processors, but the CPCI
CPUs and associated memory were emulated by the HP64000 Microprocessor
Development System to provide visibility into the processors during debug,
integration and analysis. Both the HMI plasma display and the HMI external
network simulator were simulated with MITRE-developed software executed on
IBM personal computers.
65
§
o<;
I I < a. -I X
Hi Q. C.
H § a.
o
5^
8£g 9F >
< _1 CO 9 2°
S _i </> £ = >-
!|
cr cc cc cr OOOO a. a. a. a.
£1 0 = U_ CO
H
%
u o
B o
n3
C o u QJ
M
I U 03
01
1
x<s!Sa x3<2ocg Q.Q(i!=.
01 1-1
3, •H cm
• * rt rr*
ujZio
66
The node test environment continued to evolve over the life of the
SQA effort. The NC Driver Interface (NCDI) was developed and designed to
operate on an Intel 86/12A single-board computer and act as the interface
between the NC driver (IBM-PC) and the NC. The NC driver supported
transfer of an interval's worth of packets to the NC and received an NC
packet every 2/3 second. The driver displays and records in a log file all
data communicated to and from the driver and the NC. NC software was
burned into PROM, installed in an Intel 86/12A board and initialized as a
Relay Node.
The BITE processor was integrated into the node. A switching matrix
was developed which supported toggling of the LRU reporting status leads to
the BITE. Utilizing this capability, the BITE was stressed to verify its
throughput and reporting capabilities.
The results and findings of the above SQA efforts were then compiled,
a report generated and the findings discussed with the GWEN Program Office
and the contractor.
3.5.2 Summary of Findings
The following specific areas of concern within the HMI CPCI were
tested with the test configuration presented in figure 18:
• Power-on processing and self-test;
• Site-specific data initialization;
• Communication between the COMSEC Interface Processor and the
Human-Machine Interface.
67
We determined that the HMI's RAM control and internal processing test
functions contained several deficiencies. On power-up the HMI did not
access each of the RAM chips for proper initialization. This resulted in
the EDAC system's indicating an error had occurred. We recommended to the
contractor that the HMI software be modified to support proper RAM chip
initialization.
A second issue uncovered during the node testing of the HMI was the
limited site-specific data processing ability of the HMI processor. At a
sustained rate of one packet from the NC every second, we found that the
HMI processor was never able to complete initialization because the ini-
tialization data was being overwritten by the incoming data. By varying
the input rate of initialization data (10 seconds per packet) to the HMI,
we found that the HMI was able to initialize properly and consistently.
Analysis of this problem revealed that although the HMI acknowledged (ACK)
or did not acknowledge (NACK) each initialization packet from the main-
tenance terminal, the MT processing of the ACK or NACK requires only 0.5 to
1 second before the MT will originate the next packet. The HMI, on the
other hand, requires between 2 to 6 seconds to fully process the received
packet. The problem was discussed with RCA and resulted in RCA's incor-
porating a throttling scheme into the HMI initialization processing.
In the last area addressed in this test effort, communication between
the CIP and HMI, we noted that upon receipt of a Transaction Descriptor
(TD) from the CIP, the HMI validated the TD. It was found that if the TD
was not valid, the message was discarded by the HMI with no notification to
the CIP. With no mechanism to recover a discarded message or to recover an
initialization packet count, the HMI would fail. Discussions with RCA
resulted in the inclusion of full message ACK/NACK and recovery protocol
between the HMI and CIP processors. Additional discussions and findings
pertaining to the execution of GWEN software in the node testbed for the
individual Computer Program Configuration Items are presented under sepa-
rate cover in appendices B through H.
68
3.6 SOFTWARE CODE MAINTAINABILITY
3.6.1 Activities
The maintainability of the CPCI at the code level is based on three
major points. First is simplicity of implementation. The program should
be implemented in the most clear and concise manner possible. Long-term
maintenance will be less time-consuming if the source code stays within
established programming conventions. Unique data manipulations and complex
algorithms, while functionally correct, may confuse the personnel respon-
sible for software maintenance. Second, all supporting documentation
should be clear, concise and complete. Code modifications and annotations
must be reflected within the documentation. These code annotations should
provide maintenance personnel with a primary source of information regard-
ing the program's operation. Third is the use of modular top-down design.
Implementing a single function per module allows a particular function to
be changed without impacting the entire CPCI.
While addressing maintainability, we also performed a detailed review
of the contractor-defined modification and verification procedures pre-
sented in each CPCI's Computer Program Maintenance Manual. Finally, as a
part of the overall software maintainability assessment, we examined the
feasibility of converting the majority of the GWEN software (implemented in
Assembly by RCA) into an HOL. We examined the constructs in the delivered
software and performed trial compilations with several FORTRAN and "C"
compilers.
3.6.2 Summary of Findings
We found in general that the GWEN CPCIs could not be easily main-
tained. Although the contractor utilized a top-down design, the design
69
documentation for the individual CPCIs (i.e., Computer Program Product and
Software Product Specifications and the Computer Program Maintenance
Manuals) were insufficient in terms of level of technical detail. Numerous
modules exceeded sizing limitations imposed by the GWEN Statement of Work
and ESD-GWEN-1. We also noted that the oversized multitasking modules were
difficult to follow and/or modify since their interfaces and affected
registers were not clearly recognizable.
Another concern we identified to the contractor was the use of "hard-
coded" values for value range checks and loop counters. If these hard-coded
values were to require a coding change, it would be both time-consuming and
costly due to the necessity of a line-by-line code replacement.
In the HMI, the mailbox algorithm was poorly documented. Additionally,
the integer values for the control sequence and ASCII values for the screen
values were not adequately defined.
Within all CPCs, lack of a standard usage was noted in naming conven-
tions to indicate digits and/or variable names as parameters. Module head-
ers were incomplete and in some cases missing; nested assembly procedures
were called from outside of the CPC.
The Computer Program Maintenance Manuals did not identify the required
command files which are essential for the compilation of an individual CPCI
source code into an executable file. Instructions to guide the Government
programmers in making modifications of the source code were incomplete and
would require in-depth knowledge of the contractor's software development
practices. The procedures as reviewed needed extensive revision to be com-
pliant with the Government requirements, and these revisions were required
of the contractor.
In the MT CPCI, poor computer program design and inconsistency between
the program's documentation and the code were major concerns. Programming
70
language limitation of the selected hardware, the HP-85B, required the use
of HP's Enhanced BASIC as the CPCI development language. This language is
not an approved Higher-Order Language (HOL), cannot meet the Government's
software design and construction requirements, and is poorly documented.
However, since the operational and maintenance concept was based on the use
of the MT as designed, a waiver for the use of BASIC was requested. In
order to support the request and in response to concerns about the HP-85B,
we sought alternate choices for the MT. We analyzed the current version of
the MT software and converted it to run on a newer, faster personal compu-
ter, the HP-IPC. We demonstrated a significant increase in speed. We also
used both computers to demonstrate improvements in software maintainability
that would be available with either the HP-IPC in BASIC or a typical PC (for
example, the IBM PC) in another HOL. While the waiver for the use of BASIC
was granted, newer hardware may soon be selected by Government logistics
personnel as a replacement for the HP-85B.
An additional concern was noted within the NC CPCI. In the Assembly
routines, some of the IF constructs were coded with a conditional "jump"
followed immediately by an unconditional jump. The coding of the uncondi-
tional jump was unclear. It was felt that in all of the routines where this
coding practice was found a single conditional jump would have been suffi-
cient, in addition to being more efficient, clear, and concise.
Within the GMNC, the General-Purpose Interactive Display System (GIDS)
documentation for the GIDS utility library CPC did not define the GIDS flow
and its interaction with the other GMNC CPCs. For maintainability, it was
important that the GMNC program documentation present a comprehensive design
to include fully defined inter-task and inter-processor descriptions.
We found in our HOL conversion feasibility study that the most suitable
conversion language is "C", due to low code expansion and wide availability
71
of production-quality compilers. These findings were also used to support a
Pre-Planned Product Improvement
that was done in December 1986.
Pre-Planned Product Improvement (PI) plan for GVEN HOL software conversion
Detailed discussions and findings pertaining to our analyses of indi-
vidual Computer Program Configuration Item maintainability are presented
under separate cover in appendices B through H.
72
SECTION 4
CONCLUSIONS AND RECOMMENDATIONS
4.1 CONCLUSIONS
The GWEN SQA effort provided a superior method for understanding the
actual software design and documentation process. It provided an early and
ongoing examination of the individual CPCI Program Design Language (PDL) and
source code, and allowed comparison of the PDL with the code. However, it
also reinforced the point that for a successful SQA effort, software must be
received by MITRE and reviewed as soon as it has been unit-tested and placed
under configuration control by the contractor. Doing this provides a major
benefit of positive and open communication with the contractor and early
feedback, of findings from MITRE to the contractor. This reduces potential
delay in the development schedule and/or the accrual of additional cost. In
this case, the SQA effort provided MITRE personnel with solid experience on
the adequacy of formal qualification test plans/procedures and a detailed
knowledge of the hardware environment and the qualifying test scenarios,
benefits that would be useful on any program.
The thrust of the SQA effort concentrated on verification of each
CPCI's implementation completeness, correctness, readability, and maintain-
ability. Completeness was determined via analyses which revealed that the
source code was generally well-written and satisfied the requirements as
delineated in the GWEN Software Requirements Specification, the Software
System/Subsystem Specifications (for TRANSEC/COMSEC-designated CPCIs), and
the Computer Program Development Specifications (for all other CPCIs). We
verified the development requirements/source code analysis by correlating
the source code at the Computer Program Component (CPC) level with the re-
quirements traceability matrices of the TRANSEC/COMSEC-designated CPCIs'
73
Software Product Specifications and with the Computer Program Product Spe-
cification for all other CPCIs. Correctness was judged in terms of corre-
lation with higher-level documents and consistency with the PDL. Modules
were identified where discrepancies existed between the source code and the
PDL. The readability evaluation revealed that many modules were deficient
in header information.
Within the Network Control CPCI, we verified that the GWEN critical
timing requirements could be met by the software. Our examination of the
NC and HMI queue structures and their handling of messages identified an
absence of a buffer overflow processing protocol that would ensure that
high-precedence traffic would be delivered to the user. We additionally
identified several potential problem areas within the queue structure
design which, during periods of heavy traffic processing, could impact
compliance with the Government's specified time constraints. We recom-
mended that formal Government acceptance of the NC and HMI software include
stress testing of the queue structures.
Several security concerns were identified within the TRANSEC CPCIs.
The specific areas addressed were of a classified nature and related to the
CPCIs' software design and hardware/software integration and qualification
testing. RCA, in response to our SQA findings, revised their software
design, their software/hardware integration effort, and expanded the quali-
fication test procedures.
We tracked the memory allocation in hardware and software, identifying
early on that the contractor's hardware design would not be compliant with
the Government's memory expansion requirements. We recommended that the
contractor develop a memory allocation work-around plan utilizing new
higher-density boards.
Specific problem areas identified during the review of the individual
CPCIs are addressed in detail in the respective CPCI appendices, to be
74
published in a separate volume. These issues were discussed in detail with
ESD and the contractor. Corrective actions were subsequently agreed upon
between ESD, RCA and MITRE, and all have been fully implemented.
4.2 RECOMMENDATIONS
For future SQA efforts, early involvement of contractor, Government
and SQA personnel is essential. The inclusion of Statement of Work para-
graphs that identify the SQA effort, selection of the SQA group or
contractor, definition of the scope of effort with supporting milestones,
and the selection of the facilities to perform SQA need to be completed
prior to the contractor's commencement of software development.
A specific concern for GVEN is the need for replacement of the Mainte-
nance Terminal HP-85B hardware and source code as expeditiously as pos-
sible. The current hardware is no longer manufactured by the vendor and
requires HP-copyrighted software to download and execute the contractor-
developed MT CPCI.
Conversion of the GUEN software as a Pre-Planned Product Improvement
(P I) to an approved Higher-Order Language (HOL) may be useful. Our cal-
culations on the cost and schedule for this effort, previously documented
in March 1986, support conversion to an HOL as both feasible and desirable.
75
GLOSSARY
ACK Acknowledgment ACSN Advance Change/Study Notice ADD Algorithm Description Document ADQ Administrative Queues AFOTEC Air Force Operational Test and Evaluation Center ASM Assembly Language ATP Acceptance Test Procedure
BITE Built-in Test Equipment BP Base Pointer BSO Boston Systems Office
CDR Critical Design Review CDRL Contract Data Requirements List CIL COMSEC Interface Logic CILS COMSEC Interface Logic Simulator CIP COMSEC Interface Processor COMSEC Communications Security CONUS Continental United States COTS Commercial Off-The-Shelf CPC Computer Program Component CPCI Computer Program Configuration Item CPDS Computer Program Development Specification (B-5) CPM Computer Program Module CPMM Computer Program Maintenance Manual CPPS Computer Program Product Specification (C-5) CPU Central Processing Unit CRC Cyclic Redundancy Check. CRT Cathode Ray Tube CRVM Cross-Reference Verification Matrix CVP Cryptographic Verification Plan CVR Cryptographic Verification Report
ECP Engineering Change Proposal EDAC Error Detection and Correction EPROM Electrically Programmable Read-Only Memory ESD Electronic Systems Division
FIFO First In, First Out FOC Final Operational Capability FOR FORTRAN FQT Formal Qualification Test FS First Systems
GIDS General-Purpose Interactive Display System GMNC GWEN Maintenance Notification Center
77
GLOSSARY (Continued)
GVMSOS GWEN GWPF
HLT HMI HOL HP HQ
I/O I CD IEC IEMATS IOC ITMCS
LF LF/CR LRU
MDS MT
GMNC'S GIDS VMS Operating System CPC Groundvave Emergency Network GMNC'S GIDS Word Processing Function CPC
Halt Human-Machine Interface Higher-Order Language Hewlett-Packard Headquarters
Input/Output Interface Control Document Interstate Electronics Corporation Improved Emergency Message Automated Transmission System Initial Operational Capability Inter-task Message Communications System
Low Frequency Line Feed/Carriage Return Line-Replaceable Unit
Microprocessor Development System Maintainer Terminal
NACK No Acknowledgment NCDI Network Control Driver Interface NCP Network Control Processor NCPD Network Control Processor Driver NORAD North American Air Defense Command
OJCS
P3I PDL PIDS PIT PLDC PPI PQT PROM
QA
Office of Joint Chiefs of Staff
Pre-Planned Product Improvement Program Design Language Prime Item Development Specification Programmable Interrupt Timer Permanent Low Duty Cycle Programmable Peripheral Interface Preliminary Qualification Test Programmable Read-Only Memory
Quality Assurance
R/B RAM
Red/Black Random Access Memory
78
GLOSSARY (Continued)
RCVC Rekey Crypto Variable Controller RN Relay Node RO Receive Only ROM Read-Only Memory ROMI Rekey Operator-Machine Interface
4 S Software System/Subsystem Specification SAC Strategic Air Command SCCB Software Configuration Control Board SFA Security Fault Analysis SOW Statement of Work SPO System Program Office SPS Software Product Specification (C-5) SQA Software Quality Assurance SRP System Resource Program SRS Software Requirement Specification STR Software Trouble Report
TCP TRANSEC Control Processor TD Transmission Descriptor TEMSS Test and Evaluation Message Signal Simulator TEK Tektronix TFE TRANSEC Front End TIM Technical Interchange Meeting TLCC Thin Line Connectivity Capability TOD Time of Day TRANSEC Transmission Security TRS TRANSEC Rekey Station TTL Transistor-Transistor Logic TVP TRANSEC Variable Processor
UHF UM UUT
Ultrahigh Frequency Users Manual; Unit Manager Unit Under Test
VC Virtual Circuit V&V Verification & Validation VRTX Real-time operating system
79
BIBLIOGRAPHY
Standards:
MIL-STD-483
MIL-STD-1753
MIL-STD-52779A
NACSEM 5112
NACSIM 5100A
KAG-30A/TSEC
NSAM 81-3
Configuration Management Practices for Systems, Equipment, Munitions and Computer Programs
FORTRAN DOD Supplement to American National Standards X3.9-1978
Software Quality Assurance Program Requirement
Nonstop Evaluation Techniques
Compromising Emanations Laboratory Test Standard Electromagnetics
Compromising Emanations Standards for Cryptographic Equipment
NSA/CSS Software Product Standards Manual
21 Mar 1973
9 Nov 1978
1 Aug 1979
Apr 1975
Jul 1981
Jan 1971
26 Jul 1979
Other Applicable Documents:
X3.9-1978
ESD-GWEN-1
ESD-TR-84-171
8564324
8564350B
8564397D
Programming Language FORTRAN, American National Standards Institute, New York, NY
System Specification for Groundwave Emergency Network, Rev. A
Handbook for Evaluation and Life Cycle Planning for Software, Vol. Ill: Reviews, Audits and CPCI Specifications
Algorithm Description Document for GWEN Thin Line Connectivity Capability System
Computer Program Timing and Sizing Data for GWEN Thin Line Connectivity Capability System
Software Requirement Specification for GWEN Thin Line Connectivity Capability (including change dated 16 Nov 1987)
3 Apr 1978
23 Sep 1983
1 Feb 1983
7 Mar 1985
6 Mar 1986
9 Feb 1987
81
BIBLIOGRAPHY (Continued)
8564397D Appendix I to SRS for GWEN Thin Line Connectivity Capability (including change dated 16 Nov 1987)
8564397E Appendix II to SRS for GWEN Thin Line Connectivity Capability
8564397D Addendum to Appendix II
8564372C Built-in Test Equipment Computer Program Development Specification (including change dated 30 Aug 1985)
8564346 Built-in Test Equipment Computer Program Product Specification (including change dated 24 Sep 1987)
8567318 Built-in Test Equipment Formal Qualification Test Procedures
8564346-30 Built-in Test Equipment Computer Program Maintenance Manual
8564369A COMSEC Interface Processor System/Subsystem Software Specification
8564345B COMSEC Interface Processor Software Product Specification
8567322 COMSEC Interface Processor Formal Qualification Test Procedures
8564345-30 COMSEC Interface Processor Computer Program Maintenance Manual
8564392C GWEN Maintenance Notification Center Prime Item Development Specification (including change dated 20 Feb 1986)
8564373B GWEN Maintenance Notification Center Computer Program Development Specification for GWEN (Part I)
8564373B GWEN Maintenance Notification Center Computer Program Product Specification for GWEN Thin Line Connectivity Capability (Part II)
9 Feb 1987
9 Oct 1987
20 Nov 1987
19 Dec 1984
1 Apr 1985
13 Sep 1985
11 Sep 1987
17 Dec 1984
25 Sep 1987
17 Apr 1986
15 Sep 1987
26 Sep 1985
19 Dec 1985
17 Sep 1987
82
BIBLIOGRAPHY (Continued)
8567317 GWEN Maintenance Notification Center Formal Qualification Test Procedures
8564348-30 GWEN Maintenance Notification Center Computer Program Maintenance Manual
8564348-28 GWEN Maintenance Notification Center Users Manual
8564371E Human-Machine Interface Computer Program Development Specification
8564371E Human-Machine Interface Computer Program Product Specification for GWEN TLCC
8567316 Human-Machine Interface Formal Qualification Test Procedures (Part 1)
8567316 Human-Machine Interface Formal Qualification Test Procedures (Part 2)
8567316 Human-Machine Interface Formal Qualification Test Procedures (Part 3)
8564349-30 Human-Machine Interface Computer Program Maintenance Manual
8564349-28 Human-Machine Interface Users Manual
8564372C Maintainer Terminal Computer Program Development Specification (including change dated 30 Aug 1985)
8564346 Maintainer Terminal Computer Program Product Specification (including change dated 24 Sep 1987)
8567318 Maintainer Terminal Formal Qualification Test Procedures
8163055-30 Maintainer Terminal Computer Program Maintenance Manual
8163055-28 Maintainer Terminal Users Manual
14 Jan 1986
14 Sep 1987
30 Oct 1987
12 Nov 1985
30 Mar 1988
17 Jul 1986
12 Aug 1986
21 Oct 1987
14 Sep 1987
9 Sep 1987
19 Dec 1984
1 Apr 1985
13 Sep 1985
14 Sep 1987
14 Oct 1987
83
BIBLIOGRAPHY (Continued)
8564370G Network. Control Computer Program Development Specification (Part I)
8564370B Network. Control Computer Program Product Specification (Part II)
8564315 Network Control Formal Qualification Test Procedures
8564370-30 Network Control Computer Program Maintenance Manual
8564368C TRANSEC System/Subsystem Software Specification (TRANSEC Control Processor, TRANSEC Variable Processor and TRANSEC Front End)
8564340B TRANSEC Control Processor Software Product Specification
8567321A TRANSEC Control Processor Computer Program Configuration Item FQT Procedures
8564340-30 TRANSEC Control Processor Computer Program Maintenance Manual
8564343A TRANSEC Front End Software Product Specification
8567319 TRANSEC Front End Computer Program Configuration Item Formal Qualification Test Procedures
8564343-30 TRANSEC Front End Computer Program Maintenance Manual
8564334B TRANSEC Relay Station Prime Item Development Specification (including change dated 6 Nov 1987)
8567295 TRANSEC Rekey Station Software Product Specification (Rekey Crypto Variable Controller)
10 Jun 1986
5 Oct 1987
7 Oct 1987
23 Sep 1987
17 Dec 1984
15 Sep 1987
11 Jul 1986
14 Sep 1987
18 Sep 1987
21 Mar 1986
11 Sep 1987
6 Feb 1987
25 Oct 1987
84
BIBLIOGRAPHY (Concluded)
8567296 TRANSEC Rekey Station Software Product Specification (Rekey Operator Machine Interface)
8564323B TRANSEC Rekey Station System/Subsystem Software Specification (Rekey Operator Machine Interface and Rekey Crypto Variable Controller)
8567576 TRANSEC Rekey Station Formal Qualification Test Procedures (Rekey Operator Machine Interface and Rekey Crypto Variable Controller)
8567295-30 TRANSEC Rekey Station Computer Program Maintenance Manual
25 Oct 1987
30 Oct 1987
27 May 1987
24 Sep 1987
8567296-28 TRANSEC Rekey Station Users Manual
8564341B TRANSEC Variable Processor Software Product Specification
8567320 TRANSEC Variable Processor Computer Program Configuration Item Formal Qualification Test Procedures
8564341-30 TRANSEC Variable Processor Computer Program Maintenance
25 Sep 1987
28 Sep 1987
8 Dec 1986
14 Sep 1987
85