Portable Onboard Computer

Software Management Plan

__________________________________________________________

Operations Division

Baseline

November 1997

NASA

National Aeronautics and Space Administration

Lyndon B. Johnson Space Center

Houston, Texas

Section Page

1.0 INTRODUCTION 1-1

1.1 PURPOSE 1-1

1.2 SCOPE 1-1

1.3 AUTHORITY 1-2

1.4 ACCESS AND CHANGE NOTIFICATION PROCESS 1-2

2.0 DEFINITIONS AND ACRONYMS 2-1

2.1 DEFINITIONS 2-1

2.2 ACRONYMS 2-3

3.0 RESPONSIBILITIES 3-1

3.1 BOARD RESPONSIBILITIES 3-1

3.2 POSITION RESPONSIBILITIES 3-3

3.3 DIVISION RESPONSIBILITIES 3-5

3.3.1 Operations Division 3-5

3.3.2 Flight Design and Dynamics Division 3-5

3.3.3 Avionics Systems Division 3-5

4.0 GUIDELINES AND POLICIES 4-1

5.0 PGSC HARDWARE CLASSIFICATIONS AND USAGE

RULES/CONSTRAINTS/GUIDELINES 5-1

5.1 PGSC HARD DRIVE CONFIGURATION 5-1

5.1.1 STS-Controlled Hard Drive Rules/Constraints/

Guidelines 5-1

5.1.2 Payload-Controlled Hard Drive Rules/Constraints/

Guidelines 5-2

5.2 PGSC CONFIGURATION/CLASSIFICATION 5-2

5.2.1 Standard Configurations 5-3

6.0 POC SOFTWARE SOURCE CONTROL AND VALIDATION LEVELS 6-1

6.1 POC SOFTWARE SOURCE CONTROL 6-1

6.2 POC SOFTWARE VALIDATION DEFINITIONS 6-1

7.0 POC SOFTWARE CONFIGURATION MANAGEMENT 7-1

7.1 POCCB CHANGE REQUEST FORM 7-3

7.1.1 Appeals 7-3

7.2 DISCREPANCY REPORTING 7-3

7.3 JSC FORM 482 7-3

7.3.1 Appeals 7-4

7.4 COPYRIGHTS 7-4

8.0 STS POC SOFTWARE PROCESSING 8-1

8.1 POC SOFTWARE ASSIGNMENT 8-4

8.1.1 PGSC Users Letter 8-4

8.1.2 Software Requirements Compliance Letter 8-4

8.2 SOFTWARE DELIVERY DEADLINES 8-12

8.3 VIRUS SCANNING AND DETECTION POLICY 8-14

8.3.1 Training Support 8-14

8.3.2 Flight Support 8-14

8.4 FLOPPY DISKS FOR FLIGHT 8-14

8.5 LOADING OF POC FLIGHT SOFTWARE 8-16

8.5.1 Loading of PGSC Test Software 8-16

8.6 LATE SOFTWARE CONFIGURATION CHANGES 8-16

8.7 POST FLIGHT RECORDS 8-17

9.0 POC SOFTWARE DOCUMENTATION REQUIREMENTS

AND GUIDELINES 9-1

9.1 USER GUIDE 9-1

9.1.1 Introduction 9-1

9.1.2 Operations 9-1

9.1.3 Windows, Menus and Forms 9-1

9.1.4 Nominal Messages and Associated Procedures 9-1

9.1.5 Off-Nominal Indications and Associated Procedures 9-1

9.1.6 On-Screen Help 9-2

9.1.7 Data Displays 9-2

9.2 POC SOFTWARE VALIDATION AND DSI RECORDS 9-2

Addendum

A PAYLOAD APPLICATIONS AND PROJECT ENGINEER RESPONSIBILITIES

B USER INTERFACE PROGRAMMING STANDARDS AND GUIDELINES

C CHECKLIST FOR THE STS POC SOFTWARE DEVELOPMENT PROCESS

TABLE Page

5-I PGSC CLASSIFICATION SUMMARY 5-3

7-I APPLICABLE CONFIGURATION MANAGEMENT FORMS 7-2

8-I STS POC SOFTWARE GENERIC MILESTONE TEMPLATE 8-3

8-II POC SOFTWARE DELIVERY DEADLINES 8-13

Figure Page

6-1 POC SOFTWARE VALIDATION DEFINITIONS 6-2

6-2 EXAMPLE USERS ACCEPTANCE MEMO 6-3

7-1 POCCB CHANGE REQUEST FORM 7-5

7-2 JSC FORM 482B-1 (i.e. 482) 7-6

7-3 EZ 482 FORM 7-7

8-1 STS POC SOFTWARE PROCESSING RESPONSIBILITIES 8-2

8-2 PGSC USERS LETTER 8-6

8-3 SOFTWARE REQUIREMENTS COMPLIANCE LETTER (FOR S/W

WITH STS HARD DISK LOAD) 8-10

8-4 SOFTWARE REQUIREMENTS COMPLIANCE LETTER (FOR S/W

NOT WITH STS HARD DISK LOAD) 8-11

8-5 SSP PGSC DISKETTE LABEL (3 1/2" DISKETTE) 8-15

This document presents the management process, policies, and guidelines under which Portable Onboard Computer (POC) software is developed for and/or integrated into the SSP in accordance with the POC Policy defined in SSP Directive No. 138 .

POC software configuration management is a two tier process. The first level addresses operational concepts, technical details, software/ hardware interface issues, and application development. The second level is the software version configuration for operational use on a specific flight. Flight configuration is managed on par with the remainder of the FDF as documented in Appendix D of the Crew Procedures Management Plan (CPMP JSC-19207).

POC software is defined as software which executes or resides on a POC hardware platform. It specifically excludes software contained within the Orbiter General Purpose Computer (GPC) or Spacelab Command and Data Management Systems(CDMS).

POC software may require active participation to operate or may require no user interaction other than initiating and/or halting the execution of the program. The first is referred to as 'crew interactive software' and the latter as 'non-interactive software'. Shuttle crew and ground control operations may interface with either interactive or non-interactive software.

1.1 PURPOSE

The purpose of the POC Software Management Plan (POCSMP) is to provide direction and establish guidelines for control of all POC software. This includes development, production, and configuration management. The main body of this document defines the processes, policies and guidelines applicable to all POC software applications. The addendums to this document will provide additional details.

1.2 SCOPE

The procedures contained in this document will be used to acquire and manage software for use on any SSP POC. This plan is applicable to NASA, payload customers and contractor support groups engaged in provision or utilization of POC software. Note that software development, testing, validation, and configuration control for customer-provided software is a customer responsibility with Portable Onboard Computer Control Board (POCCB) oversight. Likewise, POC software provided for non-operational purposes (i.e. crew morale, public relations, etc.) is the responsibility of the provider with POCCB oversight.

1.3 AUTHORITY

The POCCB is a joint SSP/MOD board which is the controlling authority for POC hardware configuration, software integration, software configuration, and SSP POC hardware/software procurements via NSTS 07700, Volume IV, Book 1 . In addition, the POCCB will establish and maintain requirements for POC hardware configurations and software applications in compliance with the SSP POC policy documented in NSTS 07700, Volume II, Book 2, SSPD No. 138 .

1.4 ACCESS AND CHANGE NOTIFICATION PROCESS

The master copy of the POCSMP) document shall be maintained by the POCCB and the current version is accessible from the official POCCB Internet web page ( http://fltproc.jsc.nasa.gov/poccb/ ). Paper distribution of the POCSMP is limited but a copy can be requested through the POC Coordinator.

The POCCB will notify the POC community of new version releases of the POCSMP through the electronic mail, POCCB Agenda distribution list. When a new version of the POCSMP is released, the document will be updated on the POCCB web page.

2.1 DEFINITIONS

Application - A specific collection of executable code and associated files that together form a software package having a special use or purpose.

Application manager - The technical person who coordinates activities affecting a specific application(s) and is the single point of contact responsible for that application.

Common software - POC software available for use with all applications (e.g., operating system, basic input/output system (BIOS), utilities, accessories, etc.).

Data source information (DSI) - DSI records provide an accountable source (audit trail) for each parameter contained within flown POC software elements. These records may be used for investigation purposes in the event of an in-flight anomaly.

Data Source parameter - Data or a set of data that is a characteristic property of a system, component, or operation and which can be assigned a name and dimensional value.

Electronic flight data file (EFDF) - PGSC software which electronically displays, executes, or computes information which replicates or is similar to that contained in the paper FDF. Trajectory-related software is a special sub- category of EFDF.

Interactive POC software - That which requires active crew involvement to operate.

482 (Form 482, Crew Procedures Change Request) - A JSC form used to request changes to the FDF and to allow as much visibility and control as required to ensure accurate procedures, timelines, and reference data for training and flight. The scope of 482 applicability is extended to cover POC software, including the addition/deletion of software applications, associated procedures, and other crew interface items.

Non-interactive POC software - POC software which does not require the crew to actively interface with it other than booting the computer and commencing/halting execution of an application.

Orbit operations software - POC software which is nominally executed during the on-orbit phase of flight and is not payload- or trajectory-related software. This includes electronic FDF- and NASA-sponsored detailed test objectives (DTO's).

Office of Primary Responsibility (OPR) - The organization which is assigned responsibility for a particular function or activity, specifically those relating to a POC software application.

Payload-controlled hard drive - POC hard drive that is the sole responsibility of the payload. It is not restricted to any STS guidelines.

Payload software - POC software which is developed for use with an SSP payload. It may be interactive or non-interactive and may or may not directly interface with the middeck, flight deck or payload bay experiment for which it was designed.

PGSC - Payload and General Support Computer. A type of POC flown on Shuttle flights.

POC - Portable Onboard Computer. Crew operated automated processing hardware and related peripherals that are not a fixed part of the Orbiter or payload systems. This includes the Payload and General Support Computer (PGSC), the hand-held calculator, and other carry-on calculating/computing devices.

POCCB - Portable Onboard Computer Control Board

POCCB CR - Portable Onboard Computer Control Board Change Request

POC Coordinator - The (DO3) individual assigned to integrate POC-related activities for a specific flight.

POC software - Software which is executed from a POC. This excludes all software which is contained within the GPC's, CDMS or other fixed onboard computer system.

POC software media - The hardware on which POC software is loaded (i.e. floppy disks, hard disks, CD ROMs, etc.). Any expendable media is also under the control of the CPCB and may be modified via a 482 CR.

Shared PGSC - PGSC that is used to operate STS and payload software. Its configuration is nominally managed by STS.

Software validation (SV) - Testing of a particular POC software application to ensure proper execution.

STS-controlled hard drive - A POC hard drive that is the responsibility of the STS and adheres to STS guidelines and constraints.

STS software - Software developed for SSP use on portable onboard computers.

Time-dedicated PGSC - A PGSC that is allocated to SSP or payload operations at specific mission intervals.

Trajectory software - POC software which computes or contains trajectory-related data or flight crew support functions.

User interface - Software application displays, menus, functional keystrokes, messages, prompts, tones, required crew inputs, and other similar means by which the crew or ground operations personnel interact with the POC software.

User interface validation (UIV) - Testing of a POC software application user interface to demonstrate expected crew/machine interaction. UIV specifically excludes actual code validation.

2.2 ACRONYMS

482 Four-eighty-two (JSC Form 482B-1, Crew Procedures Change Request, i.e. Form 482)

API Application Programming Interface

BIOS Basic Input/Output System

CAPCOM Capsule Communicator

CDMS Command and Data Management System

CDPA Controlled Document Preparation Area (facility)

COTS Commercial-Off-the-Shelf (software)

CPCB Crew Procedures Control Board

CPMP Crew Procedures Management Plan

CR Change Request

DLL Dynamic Link Library

D/O Deorbit

DoD Department of Defense

DOS Disk Operating System

DSI Data Source Information

DTO Detailed Test Objective

EFDF Electronic Flight Data File

FAO Flight Activities Officer

FCECCB Flight Crew Equipment Configuration Control Board

FD Flight Director

FDF Flight Data File

FDF OPS Flight Data File Operations

GMT Greenwich Mean Time

GPC General Purpose Computer

HD Hard disk

IDD Interface Definition Document (NSTS 21000-IDD-486)

IPT Integrated Product Team

KSC Kennedy Space Center, NASA

MB Mega Byte

MCC Mission Control Center

MET Mission Elapsed Time

MICB Mission Integration Control Board

MOD Mission Operations Directorate, NASA-JSC

OPR Office of Primary Responsibility

PGSC Payload and General Support Computer

PH&G United Space Alliance, POC Software Loads, Product Handbook & Glossary

PIM Payload Integration Manager

PL Payload

POC Portable Onboard Computer

POCCB Portable Onboard Computer Control Board (to the CPCB)

POCCB CR Portable Onboard Computer Control Board Change Request

POCSMP POC Software Management Plan

PRCB Program Requirements Control Board

PV Procedures Validation

RAM Random Access Memory

SMS Shuttle Mission Simulator

SpOC Space Operations Computing

SSP Space Shuttle Program

SV Software Validation

S/W Software

TIPS Thermal Impulse Printing System

TSR Terminate/Stay Resident

UIV User Interface Validation

POC software-related activities are primarily performed by members of the Operations Division with appropriate support from the Training Division, Astronaut Office, Engineering Directorate, and other NASA organizations and contractors. Each organization is responsible for designating a single point of contact to act as a representative for their organization relative to their POC software interests and responsibilities.

3.1 BOARD RESPONSIBILITIES

PRCB

The Space Shuttle Program Requirements Control Board is the controlling authority for SSP requirements. The POCs are provided by the SSP. The PRCB has delegated the authority and responsibility for POC hardware and software configuration control to the POCCB. The PRCB has approved a Core Crew Equipment list that includes manifesting two PGSC-486s and the associated hardware for STS operations. The boards/teams described below operate under the authority of the PRCB.

IPT

The Integrated Product Team (IPT), chaired by the Flight Manager, will consolidate flight-specific programmatic decisions across the flight preparation and product processes. The IPT is responsible for the concurrence of additional POC equipment needed (above the core) to support DTO, RME, Crew Support Objectives, etc. The IPT ensures proper storage availability, power consumption, etc. for Shuttle flights. The POCCB is responsible for supporting IPT meetings and providing POC technical system configurations for all Shuttle Flights. Any/All POC equipment is coordinated with the IPT chairperson for proper stowage/power allocations.

FCECCB

The FCECCB is responsible for baselining SSP requirements applicable to flight crew equipment, flight crew equipment specification requirements, and acceptable flight crew equipment configurations. The POCCB supports the FCECCB with a listing of the STS POC equipment needed for each Shuttle flight. This list of STS POC hardware is properly manifested via the FCECCB. Also, new hardware configurations from the POCCB are also reviewed/approved via the FCECCB to ensure proper hardware certification.

CPCB

The Crew Procedures Control Board (CPCB) is the governing body for the establishment of guidelines and policies pertaining to the development, control, publication, fabrication, and validation of the SSP crew procedures.

The POCCB uses the CPCB's change control process (JSC Form 482) to baseline POC software and document changes that are made to POC software after it is under configuration control. Flight-specific POC software is under configuration control at approximately 90 days prior to launch when the software training load becomes available.

Representatives of the CPCB convene as required to disposition Form 482s that are controversial, affect safety-of-flight, or have not been dispositioned after 30 days from the 482 initialization date.

POCCB

The POCCB is a joint SSP/MOD board which is the controlling authority for the Portable Onboard Computer (POC) hardware configuration, software integration, software configuration, and SSP POC hardware/software procurements via NSTS 0700, Volume IV, Book 1 . The POCCB will establish and maintain requirements for POC hardware configurations and software applications in compliance with the SSP POC policy documented in NSTS 07700, Volume II, Book 2, SSPD No. 138 .

The POCCB will establish and implement policies for coordinating POC software integration and STS POC software development. The POCCB also manages overall STS PGSC flight software, defines configuration control requirements, establishes guidelines for software compatibility, determines level of validation required, identifies supported commercial off-the-shelf (COTS) software (operating system, word processors, modem packages, etc.), directs the development and maintenance of POC software utilities (file compression, etc.), defines POC software interface standards, monitors POC software logistics activities, manages STS hard drive resources, and coordinates POC hardware requirements.

The POCCB will elevate to the PRCB any/all required POC policy changes, any unresolved POC issues that need mediation, and procurement matters affecting flight hardware/software.

The following four (4) documents produced and maintained by the POCCB have been established as quality records that document the responsibilities and processes of the POCCB :

1. POCCB monthly meeting minutes (accessible from the official POCCB Internet web page http://fltproc.jsc.nasa.gov/poccb)
2. PV Records produced for each POC flight software load (contact the POC Coordinator assigned to the particular flight - see official POCCB web page)
3. STS PGSC software manifest list produced for each flight (accessible from the POCCB web page)
4. Load verification checklist that is completed for the STS PGSC software load on each flight (contact the POC Coordinator assigned to the flight)

3.2 POSITION RESPONSIBILITIES

POCCB Chairmen

The POCCB chairmen have the overall responsibility for the implementation of the POCSMP. The chairmen resolve any conflict that jeopardizes the goals of this plan or elevate the conflict to the appropriate level for resolution.

Organization Representative

A representative is responsible for representing their organization in activities surrounding the POC Control Board. Any organization involved with POC software or POC utilization may be represented, regardless of whether or not that organization has a permanent member on the POCCB.

Application Manager

Each software application has a technically qualified application manager (or equivalent) designated by the branch to which the software responsibility is assigned.

Application Managers are responsible for complete coordination of new or

modified software releases or other data that affect their software.

This includes coordination, as required, with contractors, customers,

and other NASA organizations.

Application Managers are responsible for validation of new releases and/or associated data files.

POC Coordinator

The POC Coordinator is responsible for the flight unique coordination and integration of all POC software that will reside on an STS PGSC hard disk (versus 'payload dedicated' PGSC hard disk). The POC Coordinator works with all the POC users on a flight to create an integrated hardware/software usage plan. The POC Coordinator tracks all POC and associated hardware requirements as well as providing real-time flight support as necessary.

Space Operations Computing Team (SpOC)

The SpOC Team has the responsibility for providing technical and software support for crew support programs including Worldmap, Deorbit, and CG Manager, as well as other utilities provided for the crews. Software support consists of providing custom software, training, and trouble-shooting problems in the SMS.

Boeing Flight Equipment Processing Contract (FEPC), PGSC Group

The Boeing FEPC PGSC Group is responsible for the pre-flight checkout and preparation of PGSC flight hardware. The FEPC PGSC Group is also responsible for the maintenance of PGSC flight and training hardware. The FEPC PGSC Group will maintain the inventory of Class III PGSCs and associated hardware available for loan through the POCCB SSP Co-Chairman.

FDF Manager

The NASA Flight Data File (FDF) Subsystem Manager is responsible for ensuring the integration of POC software and hardware into the FDF systems and processes. The FDF Manager will ensure that POC-related items manifested as part of, or with, the FDF are correctly configured according to applicable directives and governing forums (CPCB, POCCB, FCECCB, IPT).

FDF Coordinator

The FDF Coordinator for a particular mission is responsible for ensuring the proper configuration of that mission's FDF for simulations and for flight. The FDF Coordinator works with the POC Coordinator to ensure that various FDF documents (e.g. FDF Structure Sheet, FDF Status Sheet, FDF Contents List, and FDF Manifest) and FDF procedures (e.g. Orbit Ops C/L) contain correct information pertaining to POC software.

The FDF Coordinator also monitors POC activities required to meet scheduled FDF milestones.

FDF Book Manager

Designated FDF Book Managers are responsible for ensuring published

procedures are available for crew operation of POC equipment and

software per CPMP Appendix A and the flight-specific FDF structure

sheet.

All FDF Book Managers are responsible for ensuring that any reference to

POC software applications are valid, current and documented with other

cross-references in the Procedures validation records. Additionally, the Book Manager assigned to the Consolidated Configuration Definition (Config) Book, or its equivalent, is responsible for ensuring the flown software version and media content in that book is current for configuration management purposes.

Flight Activities Officer (FAO)

The FAO is responsible for monitoring PGSC activities during the mission

(actual flight and simulations) and responding to the crew or MCC

personnel request for assistance on availability or use of POC

hardware/software. The FAO will work with the POC Coordinator,

Application Managers and others as required to provide this support.

This is a MCC front room position.

3.3 DIVISION RESPONSIBILITIES

3.3.1 Operations Division

Mission Operations and Procedures Branch (DO3)

The Mission Operations and Procedures Branch is responsible for coordinating the overall POC software configuration. This effort includes coordination, integration, and loading of POC hardware; directing the development and maintenance of POC software utilities; loading flight software on the flight computer hard disks; monitoring POC software and hardware logistics activities; and maintenance of simulator and trainer POC software. Extensive programming support for STS PGSC software is also provided (such as Deorbit and World Map). This may include training support and maintenance for these applications

Flight Planning Branch (DO4)

The Flight Planning Branch certifies the Flight Activities Officer (FAO) flight controller. The FAO has the responsibility of understanding POC software and serves as the real-time point of contact for POC software related issues.

Cargo Integration and Operations Branch (DO5)

The Cargo Integration and Operations Branch will provide the primary interface between payload customers and NASA, pertaining to POC software. The Cargo Integration and Operations Branch will also be responsible for the appropriate user interface validation. Additionally, any payload-to-user interface created within NASA will be validated through this branch.

3.3.2 Flight Design and Dynamics Division

The Flight Design and Dynamics Division is responsible for providing technical support for software and documentation related to trajectory. Their concurrence is required for trajectory-related software.

3.3.3 Avionics Systems Division

The Avionics System Division is responsible for modification and flight certification of all POC hardware items.

The POCCB adheres to guidelines set forth in the PGSC Policy, SSP Directive No. 138 . To assist policy implementation, the POCCB has established general guidelines to ensure consistency of software load preparation and use from flight to flight. These guidelines are as follows :

1. MAXIMIZE USE OF COTS PRODUCTS - It is advantageous to utilize applications/technology that have been time tested and proven to be dependable in the general computing industry. These are preferred over newly released or customized applications/technology with minimal shelf life.

2. MAXIMIZE CODE RE-USE - The POCCB will create a configuration controlled pool of POCCB approved software libraries primarily through the use of Windows Dynamic Link Libraries (DLLs). Software development, testing and validation costs are reduced if functions of an application are recompiled as DLLs and not re-written. (Contact POC Coordinator for existing DLLs.)

3. MINIMIZE CREW TRAINING - Whenever possible, the POC software used for flight and training will be the same as that used in the crew office to minimize the need for additional crew training.

4. SINGLE STS FLIGHT LOAD - Every effort will be made to produce only one flight specific load on the hard drive. Also, it is highly desirable to minimize the use of unique hardware and software configurations.

5. SOFTWARE BACK-UPS REQUIRED - At least two instances of any software will be manifested on separate media, either with additional floppy disks or loaded onto two or more hard drives.

6. PAYLOAD SOFTWARE ON STS HARD DRIVES - Every attempt will be made to integrate payload software on STS hard drives. This will allow for multiple backups and simplifies crew use.

7. VALIDATION OF PAYLOAD SOFTWARE - The validation of payload software is the responsibility of the customer, i.e. the POCCB does not perform validation of P/L (Class 4) software. (See Section 6.2 of the POCSMP)

8. STS PGSC NETWORK USE - No POC customer will be allowed to monopolize use of the onboard STS PGSC network during flight. Except for expected, nominal network operations (Orbiter Communications Adapter (OCA) file transfers, crew family mail retrieval/delivery, etc.), use of the network must be coordinated with and approved by the POCCB.

5.1 PGSC HARD DRIVE CONFIGURATION

PGSC hard drive configuration is controlled to ensure compatibility of applications with the hardware, operating system and each other. There are two classifications of PGSC hard drives : STS-Controlled and Payload-Controlled. Each class may be further defined as 'shared' or 'dedicated' depending upon the software configuration and will be constrained accordingly. (See Table 5-I)

The nominal configuration is an STS-controlled hard drive that contains STS and Payload software, thus 'shared'. This configuration provides hardware and software redundancy, minimizes crew training time, and potentially reduces the number of PGSCs required. Payload applications that are a part of the STS controlled hard drive must adhere to the guidelines set forth in Section 5.1.1 .

A Payload-controlled hard drive, whether shared or dedicated, is the responsibility of the payload, thus, not restricted to the STS guidelines set forth in Section 5.1.1 . However, the payload controlled hard drive must follow the rules/constraints/guidelines set forth in Section 5.1.2 .

5.1.1 STS-Controlled Hard Drive Rules/Constraints/Guidelines

The following rules are given as a means of controlling and standardizing the use of an STS-controlled hard drive for customer applications. Any deviations from those listed must be negotiated through the POCCB prior to the basic software load drop around launch minus 90 days (L-90 days).

Rules/Constraints/Guidelines :

1. Applications must use standard DOS Read/Write commands.

2. STS reserves approximately 350 MB for its own use. The remaining

space is available for Payload customer use. (190 MB assuming 540 MB

HD, or 460 MB assuming 810 MB HD)

3. The customer will be assigned specific directories where all files

of the application(s) will reside.*

4. Applications need to be compatible with STS startup files (e.g.

config.sys, autoexec.bat)

5. Applications must be compatible with MS-Windows 95 (including DOS

modes)

6. Applications can use any of the STS-provided DLLs (includes custom

and COTS) resident on the PGSC.*

7. Applications requiring a serial interface should be written to

address the PGSC serial ports via standard Windows API calls (let windows handle IRQ's, etc.).*

8. For DOS applications, no method currently exists to print to the

Thermal Impulse Printing System(TIPS).

* Check with the POC Coordinator for the flight-specific configuration.

5.1.2 Payload-Controlled Hard Drive Rules/Constraints/Guidelines

A payload-controlled hard drive is the responsibility of the Payload Customer. This includes : hard drive loading, testing, check-out, validation, and post-flight hard drive backup, etc.

The following rules apply to PL-controlled hard drive :

1. The flight hard drive will be provided to the customer with minimal

DOS and ThinkPad utilities and drivers. No other software will be

provided by STS.

2. The payload customer is required to virus scan the PL-controlled hard

drive using the JSC-standard virus scanning application (latest

application version and signature files provided by the POC

Coordinator upon request).

3. The payload customer is required to provide a compliance letter to

the POCCB by L-30 days indicating completion of this requirement (see

Figures 8-3 and 8-4).

4. PL-controlled hard drives requiring access to the STS-network must

follow the policy defined in Section 4, guideline #8 .

5.2 PGSC CONFIGURATION/CLASSIFICATION

PGSCs are categorized as 'Time-dedicated' or 'Shared' machines depending on the software to be loaded and its operational use. Each machine type may consist of either an STS-controlled or Payload-controlled hard drive. The type of PGSC a customer is assigned is determined by the IPT. Listed below are the definitions of the PGSC classifications.

Machine / Hard Drive	Definition
'Time Dedicated' / STS-Controlled	Dedicated to STS operations. Contains STS software only. Configuration managed by STS. (Very rare)
'Shared' / STS-Controlled	Operates STS and PL software. Configuration managed by STS. PL software will adhere to rules outlined in Section 5.1.1 (Most common)
'Time Dedicated' / PL-Controlled	Dedicated to PL operations. Contains PL software only. Configuration managed by the PL.
'Shared' / PL-Controlled	Shared between payloads. Configuration managed by designated PL.

Payload customers assigned to a time-dedicated machine with a Payload- controlled hard drive are solely responsible for their PGSC, and are responsible for loading all software onto the hard disk (floppy B/U versions are very highly recommended). If the payload software is assigned to a machine with an STS-controlled hard drive, it will reside on the STS PGSC hard disk and will have floppy backups only if necessary. It is highly desirable that the payload software be manifested as part of the STS load for increased redundancy and efficient training. Table 5-I provides a summary of the above information.

Customer must request from the POCCB SSP Co-Chairman.

Payload applications may run from floppy disk(s) and stores data to floppy disk(s) or other storage media.

POCCB has oversight responsibility to ensure a control process is in place and functioning.

5.2.1 Standard Configurations

The standard hardware configurations, serial port parameters, PGSC cables, etc., are controlled by the PGSC Interface Definition Document (IDD), NSTS-21000. The standard configurations are :

1. Undocked

2. PCMMU/RS-422

3. OCA/RS-422

4. OCA/PCMMU

5. OCA/Proshare

Reference the PGSC IDD for any changes to this list.

6.1 POC SOFTWARE SOURCE CONTROL

The three sources of POC software are COTS, MOD in-house developed code, and non-MOD developed code. Configuration control and procedures validation (PV) requirements are levied against the POC software just as these requirements are levied against the paper FDF. The POCCB will not maintain direct control of any non-MOD-provided software code; however some control will be placed on the user interfaces affected by the code.

Procedures and reference information required to activate, deactivate, operate, and maintain the portable computers and associated software/hardware are documented in the FDF. Any non-flown procedures, data and user interfaces are documented for control purposes in the appropriate user guides.

6.2 POC SOFTWARE VALIDATION DEFINITIONS

The POCCB assigns all software a validation level that is based on a determined level of criticality with respect to mission success. Figure 6-1 outlines each validation classification and the associated requirements. The OPR is responsible for determining the level of effort required to validate the contents of an application.

For Class 3 and above, a user acceptance memo will be required for new applications, major revisions (eg. change to functional capabilities and/or crew interface), or upon POCCB request. See Figure 6-2 for an example of a

user acceptance memo.

* Note : All STS hard drives will contain Class 3 (or above) software. Also, see Figures 8-3 and 8-4 for examples of the Software Requirements Compliance Letter.

Date: September 27, 1995

To: J. Lenio/DO35, STS-74 Lead Portable Onboard Computer (POC) Coordinator

From: G. Bourland/EV2

Subject: STS-74, DTO-829 (Plume Impingement Contamination) Flight Software Validation, Level 3

PIC PGSC flight software (Version 1.0) has been validated for functionality and performance. The PIC PGSC flight software was executed on a Class I PGSC/expansion unit that was interfaced to the PIC flight hardware. This integrated test demonstrated that the software executed correctly.

The functionality of the PIC PGSC flight software has been evaluated and approved for flight on STS-74 by the STS-74 crew members.

________original signed____________ _______original signed________

1. McArthur G. Bourland

STS-74 MS3 Software Developer

There are three aspects of POC software configuration management :

1. Authority to proceed with acquisition (in-house development, purchase, etc.) of new software or major rework of existing software

2. Acceptance of the new or re-worked software as part of the 'approved-for-flight' software library

3. Manifesting software from the library for a specific flight.

Formal processes exist for requesting new applications, changing existing common software or changing software that relates to the trajectory, payloads or orbit operations. The POCCB Change Request form, the Crew Procedures Change Request (JSC Form 482B-1), and the EZ 482 (MOD Form 482EZ) are used to ensure the necessary review, visibility, approval, and record of the software configuration baseline and any changes to the baseline. Table 7-I outlines which form is required in a given situation. Figures 7-1, 7-2, and 7-3 show each of the forms. Changes to the procedures in the paper FDF related to PGSC software will be processed in accordance with Appendix D of the CPMP.

* MOD Form EZ 482 may be submitted for routine updates.

7.1 POCCB CHANGE REQUEST FORM

The POCCB Change Request (POCCB CR), Figure 7-1, is used to assess requirements and commit resources for NASA development, validation, and/or support of software intended to be flown. It is also kept as a matter of record for certain customer provided applications. This form is also required for any new software planned to be flown on STS-controlled POCs and should be submitted as early as possible to begin the process for making the software available for flight. The United Space Alliance POC Software Loads Product Handbook & Glossary (PH&G) should be referenced when making POC software design inputs to the POCCB. Also refer to Addendum C of the POCSMP, 'Checklist for the STS POC Software Development Process'.

The POCCB CR may be initiated by anyone associated with providing or using POC software, and is submitted to the POCCB for disposition. The POCCB considers the validation required for the request and whether enough time is available to complete the development prior to its designated flight. This form is completed at the POCCB after everyone agrees to support the validation required, impacts, etc. for the initiator's proposed software. The form is signed by the POCCB Chairman with concurrence from the board members, if applicable.

Submittals of a POCCB CR for software requiring development or validation support should be accomplished as early as possible.

1. Appeals

In the event that all of the concerned parties do not agree with the recommended disposition for a POCCB CR, the change may be appealed to the PRCB.

7.2 DISCREPANCY REPORTING

A Discrepancy Report (DR) will be written when a POC hardware or software problem is discovered. The POCCB is responsible for the final disposition of all POC DRs. If a waiver is requested in response to a DR, it must be submitted for open discussion at the POCCB. If an operations note (ops note) accompanies a waiver, it too must be submitted to the POCCB for dispositioning.

The POCCB is responsible for maintaining the POC DR process. The POC DR process is defined in JSC 28015, PGSC Discrepancy Reporting Procedures. A POC DR can be filed by anyone accessing the official POCCB web site ( http://fltproc.jsc.nasa.gov/poccb , 'DR Database' ).

7.3 JSC FORM 482

JSC Form 482 and the EZ 482 Form (Figures 7-2 and 7-3) are used as the official configuration management tools for baselining, making version changes, procedural changes, and data changes to POC software. Change requests to POC software affecting crew procedures, interfaces or training observe the same 482 deadlines and cutoffs as 482s submitted against any FDF document. (Reference Appendix D of the CPMP for a detailed description on Form 482 processing.) Those changes that do not affect any of these

items observe a L-10 (vice L-30) day 482 cutoff deadline. Post L-10 days,

the 482 cutoff criteria given below are in effect for all FDF changes,

including software updates :

1. prevents or lessens crew/vehicle hazard (Safety-of-Flight)

2. significantly enhances possibility of mission success

3. Implements program-level redirection

1. significantly conserves resources (crew time, prop, etc.).

Generic and Flight-specific Configurations

The following paragraphs break down the requirements for generic and flight-specific files.

Generic : All software that is intended to become a part of the generic bookshelf of STS software, whether it be in-house developed or COTS, must be initially baselined with a regular 482. This 482 will provide a title, dates, time stamps, files, file sizes, version numbers, a description of the software's capabilities, its intended use, and the initial version number. Subsequent 482s must be submitted for updates to the approved software.

Flight Specific : A 482 must be submitted by the OPR for each new application and version upgrade. If a 482 is approved for multiple flights, a new 482 only has to be submitted if the software application changes, i.e. version update to the software.

Concurrent with the initial training load drop for a given flight (L-90 days), the POC Coordinator will submit an EZ 482 to the FDF Book Manager, baselining all of the software that is currently part of that flight's software load. This EZ 482 will list all POC software for the flight and include dates, time stamps, files, file sizes, and version numbers for all the flight specific software. System configuration and startup files are treated as flight specific files (i.e. config.sys, autoexec.bat, system.ini, win.ini, etc.). Subsequent changes to flight specific software load must be made via another EZ 482.

7.3.1 Appeals

In the event that all of the concerned parties do not agree with the recommended disposition of a 482, the change may be appealed to the CPCB for final disposition. All 482s that are outside of the scope of the CPCB, such as some hardware changes, are forwarded to the appropriate Configuration Control Board (POCCB, IPT, etc.)

7.4 COPYRIGHTS

Numerous copies of flight software may be required to support training,

validation, development, etc. for SSP missions. This will necessitate obtaining site license permits or procuring the required number of copies needed for COTS software. As a minimum this will usually be 45 copies for software that is flying on multiple flights and considers a license necessary for every copy of the application, regardless of whether the copies are being run simultaneously. For software only flying on one flight, 20 copies/licenses are required. NASA or any contractor support group engaged in utilization or development of POC software will not knowingly duplicate or distribute any copyrighted software without the proper authorization.

In addition to controlling the software on an STS POC, the POCCB controls the process for receiving, updating, and archiving STS POC software. See Figure 8-1 for a high-level overview of how STS POC software is processed for flight.

This section establishes the POCCB policies and guidelines for receiving and processing software to be loaded on an STS POC for flight. These policies and guidelines assure a uniform processing procedure, help ensure software integrity, provide required support for Shuttle crew training, and allow for proper management of software before and after a Shuttle flight.

Also refer to Table 8-I for generic milestones for STS POC software.

8.1 POC SOFTWARE ASSIGNMENT

POC software assignments are controlled by the POCCB to ensure compatibility with the hardware, operating system and other applications. The generic STS PGSC software load provided by the POCCB consists of the operating system and STS specific applications. The following paragraphs discuss assignments for STS and payload software.

STS Software

The majority of software is integrated into the STS software load installed on PGSCs. If the software is part of the STS load, no floppy backups will be required. If the software will run off a floppy disk, then a backup copy of the floppy disk will be required for flight.

Payload Software

Payload specific software assignments depend upon the type of computer they are given, which is determined by the IPT. The distinguishing characteristics of each type of computer are given in Section 5.2 .

If the payload is granted a payload-controlled computer and/or hard drive, they are responsible for the loading and testing of the software. The payload is also responsible for providing backup floppy diskette if required.

If the payload software is assigned to an STS-controlled POC, it will reside on the hard disk with the STS software and will have floppy backups only if necessary. It is highly recommended that payload software be manifested as part of the STS load for increased redundancy and efficient training.

8.1.1 PGSC Users Letter

The POC Coordinator will issue a letter around L-165 days to all organizations that plan on having their software integrated into the STS software load. This letter outlines requirements and delivery dates in order for the software to be properly incorporated into the STS load. This letter is known as the PGSC Users Letter and is shown in Figure 8-2 .

8.1.2 Software Requirements Compliance Letter

All organizations supplying flight software for either the STS POC or a non-STS POC must provide a letter to the POCCB (through the POC Coordinator assigned to the flight) that states their compliance with the following conditions :

• their software has adhered to requirements and guidelines stated in the POCSMP

• their software has been properly tested and validated for flight

• their software has been properly integrated into the STS POC software load by the POC Coordinator (* only if this software is to be loaded on the STS flight POCs)

• the software is properly virus scanned by the customer (if required)

• any changes to their software must comply with procedures and schedules established by the SSP CPCB (* only if this software has been loaded on a STS POC)

This software compliance letter must be delivered to the POCCB by L-30 days. Examples of this letter are shown in Figures 8-3 and 8-4 .

8.2 SOFTWARE DELIVERY DEADLINES

POCCB software delivery deadlines are established to ensure timely processing, mature software, and technical visibility of POC flight software. Table 8-II outlines these delivery deadlines and associated milestones. If any prior coordination with other organizations is required, that time must be factored into this template.

8.3 VIRUS SCANNING AND DETECTION POLICY

The POCCB has established a policy for detecting viruses. The rules and regulations for this process are discussed in the following sections.

8.3.1 Training Support

Any person with a POC in their use is responsible for executing virus detection software on the computer(s) according to the following constraints :

1. Perform before and after each use, even if the computer is not removed from the training facility.. This includes any time the POC is not in the property custodian's immediate control (i.e. classes, lessons, simulations or after any repairs). Note : Due to timing constraints, it is only necessary to virus scan a POC once a day in the SMS.

2. Perform on new POCs brought into the training facility.

3. Perform on floppy disks prior to use in the training facility.

All property custodians are responsible for their respective machines and for keeping up to date with the most current MOD virus scanning software. * NOTE : The POCCB is not responsible for providing updates to this software. If a virus is detected, contact the MOD Computer Security Officer (DP3).

8.3.2 Flight Support

The POC Coordinator will virus scan all software loaded on the STS PGSC flight hard disks. The FDF OPS group is responsible for virus scanning the flight diskettes that are to be stowed with the FDF.

For hard drives and floppy disks not manifested as part of the FDF, the customer is responsible for virus scanning their software media with the current MOD-approved virus detection utility. This virus detection software will be provided by the POC Coordinator, if required. A statement that the customer has properly virus scanned their software media must be included in the Software Requirement Compliance letter to be sent to the POCCB chairman (see Section 8.1.1). The compliance letter will state that the hard drive and floppy disks were scanned for viruses and none were detected. If a virus was detected, the procedures used to destroy the virus must be included with the compliance letter. See Figures 8-3 and 8-4 for examples of this compliance letter.

8.4 FLOPPY DISKS FOR FLIGHT

The floppy disk's OPR is responsible for informing the POCCB of the number of disks required for software and/or data collection if the diskettes are to be stowed in the FDF for flight. The proper labeling information for those disks is provided in the PGSC Users Letter shown in Figure 8-2. The customer will notify the POC Coordinator and deliver to the FDF Ops Office the appropriately labeled, flight-certified, FDF "Prime" and "Backup" sets of diskettes by the deadlines outlined in Section 8.2 . A materials certificate of compliance is

Write

Disk ID Protect

NATIONAL AERONAUTICS and

SPACE ADMININSTRATION

FLIGHT DATA FILE

LBJ Space Center

Houston TX 77062

POC Software

Title

Version Disk ___ of

Set

Loaded By

WARNING: This software is for official use only. It may contain licensed, proprietary or personal information. Permission to duplicate must be obtained in writing from DO3/FDF Management Office.

also required. A Test Preparation Sheet (TPS) may be required to transfer

the diskettes from the customer to the FDF Ops Office.

Ground copies (for crew training) of the customer-provided flight diskettes will be produced by FDF OPS/CDPA. The delivered Flight diskettes will be the actual disks stowed on the Orbiter to avoid any errors that may occur during the copy process.

If updates to the Flight diskettes are required, the customer is responsible for contacting the POC Coordinator and the FDF Ops/CDPA office to update their diskettes. The OPR must also submit a Form 482. All diskettes flown with the FDF are archived and controlled by the CDPA.

For floppy software stored with the FDF, the FDF Ops Office will deliver the following sets of disks to the appropriate

facility :

Master - this set of diskettes is copied from the Flight diskettes provided by customer and stored as the official ground copy of the software

Training - this set of diskettes is copied from flight diskettes and will be used to update the training facilities

Prime and Aux Flight - this set of diskettes is provided by the customer and will be flown with the FDF

Backup Flight - this set of diskettes is provided by the customer. This set is a backup to the Prime and Aux flight diskettes that are kept on the ground.

8.5 LOADING OF POC FLIGHT SOFTWARE

POC Coordinators will perform the loading of software on STS flight POCs. The flight loading will be performed in the Boeing FEPC PGSC Lab at approximately L-43 days. Loading of a payload-controlled hard drive is the responsibility of the payload customer. Floppy disk loading is performed by the OPR.

All POC flight hardware must meet flight certification criteria established by the FCECCB. Customers providing their own POC flight hardware are responsible for the certification of that hardware. Appendix G of the CPMP lists materials which have been certified (along with the manufacturer's name and part number). By using items listed in Appendix G, the customer can be assured of certification. Only a certificate of compliance from the source (vendor, manufacturer, etc.) is required.

8.5.1 Loading of PGSC Test Software

A payload organization that requires a flight-like PGSC, expansion chassis, hard drives, etc. to support their testing/validation (e.g. KSC Integration and Validation Tests) must request this SSP-provided hardware through the POCCB. The POC Coordinator for that particular flight will install the STS software load on the hard drive(s) if required for the tests. The payload is responsible for receiving and returning the hardware to the Boeing FEPC PGSC Lab.

8.6 LATE SOFTWARE CONFIGURATION CHANGES

Upgrades and Updates

An update capability exists to allow approved mandatory modifications to the POC software after it has been loaded on the flight computers. The software update(s) must be coordinated through the POC Coordinator assigned to that flight and approved by the POCCB. The deadline for submitting the update software and the required Form 482 is L-10 days. The POC Coordinator will be responsible for testing the software update with the STS POC flight load. The software update will be included on a PCMCIA update hard disk that will be packed and stowed in the FDF locker. An FDF errata package is also annotated to show that an update will be performed.8.7 POST FLIGHT RECORDS

Copies of the POC flight software and data flown with the FDF will be made and stored in the CDPA. The following procedures will be followed :

The contents of all STS-controlled POC hard disks are copied post-flight to Jazz cartridges, tape, or other current backup media by the POC Coordinator assigned to the flight

Copies of the flown payload floppy diskettes are made post-flight by the CDPA if requested by the diskette's OPR. The flown diskettes are archived by the CDPA unless the POCCB is requested by the customer to release the diskettes for investigation/analysis.

The rationale for making these copies is to :

Save on-orbit changes to software

Troubleshoot anomalies post-flight.

9.1 USER GUIDE

All MOD and non-MOD developed software applications (other than COTS) loaded on the STS POCs require a detailed users guide. A basic version of the users guide must be submitted to the POCCB/POC Coordinator at the L-90 days, training software load deadline. Any changes to the users guide must be incorporated and delivered by the L-50 days, flight software load deadline. (See Section 8.2, Table 8-II, POC Software Delivery Deadlines).

The users guide provides crewmembers and ground support personnel with all information needed to use the software application on the POC. A description the requirements for each section of the application's users guide is provided below. This format should be used whenever possible, with sections added or deleted where applicable. A detailed and complete on-line help file(s) may be submitted as a users guide

9.1.1 Introduction

Provide a brief overview of the role of the software application.

9.1.2 Operations

Provide an overview of the operations that are controlled or monitored by the application. Provide a step-by-step flow of operations where possible.

9.1.3 Windows, Menus and Forms

Provide specific examples of all windows, menus, and forms. A description of each display should be provided and key features should be emphasized. Item selections should be described and all data entry requirements for these items should be indicated.

9.1.4 Nominal Messages and Associated Procedures

Any message that could be displayed by the application during the application's operation should be documented in this section. The form and screen location of these messages should be indicated. Messages which require specific actions by the user should receive special emphasis. All procedures associated with these messages must be documented in this section.

9.1.5 Off-Nominal Indications and Associated Procedures

Any indication provided by the application to the user that notes an off-nominal condition detected by the application will be documented in this section. For each of these messages or audible indications, a malfunction procedure should be provided. Malfunction procedures displayed by the application should also be documented in this section.9.1.6 On-Screen Help

A complete listing of all help menus, screens, and displays should be given in this section whenever possible. For extensive help listings, an appendix should be attached and referenced in this section.

9.1.7 Data Displays

All data representation capabilities of the application should be documented in this section. Examples of specific types of displays should be included. Explanations for the data displays should be included when applicable.

9.2 POC SOFTWARE VALIDATION AND DSI RECORDS

A complete validation and DSI record is maintained for all POC software and presented at the MOD PV/DSI review prior to each flight (~ L-25 days). All POC software must be validated. There must also be an accountable audit trail established for each Orbiter system parameter and operational systems parameter (including internal code) contained within each validated software element. These requirements apply equally to new, existing, or modified software applications. * Note : Payload customers are responsible, as the end user, for certifying any PCDECOM data with their application. Also, payload customers providing software need only certify that the PV was accomplished. DSI records are encouraged, but not required.

Section page

1.0 INTRODUCTION A-1

1.1 PURPOSE A-1

1.2 SCOPE A-1

2.0 DEFINITIONS AND ACRONYMS A-1

2.1 DEFINITIONS A-1

2.2 ACRONYMS A-2

3.0 GUIDELINES AND POLICIES A-2

3.1 CPCB RESPONSIBILITIES A-2

3.2 POC CONTROL BOARD RESPONSIBILITIES A-2

3.3 PROJECT ENGINEER RESPONSIBILITIES A-2

3.4 BRANCH RESPONSIBILITIES A-2

3.5 CUSTOMER RESPONSIBILITIES A-2

4.0 SOFTWARE TYPES AND LEVEL OF CONTROL A-3

4.1 SOFTWARE IDENTIFICATION A-3

5.0 PAYLOAD USER INTERFACE CONTROL PROCESS A-3

5.1 482 APPLICABILITY A-3

5.2 INITIATING A 482 FOR POC SOFTWARE CHANGES A-4

5.2.1 User Interface Change Definition A-4

5.2.2 Software Changes Not Affecting the

User Interface A-5

5.3 SOFTWARE DELIVERY DEADLINES A-5

5.4 APPEALS A-5

5.5 COPYRIGHTS A-5

5.6 USER INTERFACE DISCREPANCY REPORTING A-5

6.0 POC SOFTWARE PROCESSING A-5

7.0 DOCUMENTATION A-5

1.0 INTRODUCTION

Portable onboard computers, such as the Space Shuttle Program (SSP) provided Payload and General Support Computers (PGSC), are available to payload customers to support real-time payload operations. Th