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. The payload customer choosing to utilize a portable computer is responsible for the development, testing, and verification of the required software. The SSP is responsible for integration of the customer-provided software into the STS mission operations. The SSP will establish a configuration management process for the user interface elements of customer-provided POC payload software. Associated user interface documentation, payload emulation software, and the media (diskette) on which software is loaded are included in this process. The POCCB has the responsibility for implementation of user interface configuration management for payload applications.

The following definitions apply to this document. 'User' is defined as crew or ground control personnel. 'User interaction' is defined as monitoring or commanding the payload. The 'user interface' includes menus, displays, keystrokes, messages, prompts, crew inputs, and similar means whereby the user can interact with the payload.

1.1 PURPOSE

The purpose of this addendum is to identify clarifications, additional requirements, and exceptions to the procedures specified in the POCCB POC Software Management Plan, or POCSMP (formerly the Crew Procedures Management Plan (CPMP), Appendix J, Portable Onboard Computer Management Plan). This addendum provides supplemental direction and guidelines for user interface and media configuration control specific to payload applications. The structure of this addendum corresponds directly to the contents of the POCSMP.

1.2 SCOPE

The scope of this addendum is limited to software applications developed by payload customers and operated on portable onboard computers. The payload customer may be any government organization (including DOD), a NASA contractor, or a commercial organization. Portable onboard computers, or POC, include the SSP-provided PGSC, other SSP-supplied portable microcomputers, and customer-supplied portable microcomputers. The procedures contained in this addendum will be the responsibility of the NASA-JSC Cargo Integration & Operations Branch.

2.0 DEFINITIONS AND ACRONYMS

2.1 DEFINITIONS

No additional definitions

2.2 ACRONYMS

CPCB - Crew Procedure Control Board

POCCB - Portable Onboard Computer Control Board

POCSMP - Portable Onboard Computer Software Management Plan

3.0 GUIDELINES AND POLICIES

The NASA-JSC Cargo Integration & Operations Branch, Project Engineer (PE) (or Payload Engineer) oversees the integration of customer-provided portable onboard computer software into Space Shuttle mission operations. The following section describes the policies and guidelines, additional to those specified in the main body of the POCSMP, to be used by the PE to implement user interface integration.

3.1 CPCB RESPONSIBILITIES

Refer to Section 3.1 of the POCSMP.

3.2 POC CONTROL BOARD RESPONSIBILITIES

Refer to Section 3.1 of the POCSMP.

3.3 PROJECT ENGINEER RESPONSIBILITIES

The following defines responsibilities for the payload PE :

a. Establishment of delivery templates for documentation, training

software, payload emulators (when required), and payload flight

software. (Must follow POCCB requirements.)

b. Validation of the user interface for all nominal and malfunction

applications.

c. Maintenance of all payload UIV records.

d. Coordination and close-out of user interface discrepancies.

3.4 BRANCH RESPONSIBILITIES

Reference Section 3.3.1 (Division Responsibilities, Operations Division, Cargo Integration & Operations Branch) of the POCSMP.

3.5 CUSTOMER RESPONSIBILITIES

The payload customer is responsible for the following POC payload software development and testing activities :

a. Providing software required to monitor and control the payload.

b. Verification of payload software prior to delivery to the SSP. This

verification should be done using an SSP-provided flight-like model

of the microcomputer to be flown, interfaced to actual or flight-

like payload hardware.

c. Compatibility of customer-developed software with the SSP-provided

hardware.

d. Configuration control over software development and modifications.

e. Delivery of software and associated documentation to the NASA-JSC SSP. The customer must notify NASA of changes to the user interface and provide updated software for integration.

f. Preparation of flight software loads on flight-certified diskettes.

g. Delivery of flight software on flight-certified disks to the payload

PE.

4.0 SOFTWARE TYPES AND LEVEL OF CONTROL

Payload applications are always considered non-MOD developed code as defined in Figure 6-1, POC Software Validation Definitions, of the POCSMP. This definition also applies when an MOD organization develops code for a payload customer.

4.1 SOFTWARE IDENTIFICATION

Software Identification should follow industry standards.

5.0 PAYLOAD USER INTERFACE CONTROL PROCESS

5.1 482 APPLICABILITY

Reference Section 7.3 of the POCSMP. Once placed under CPCB control, changes to the user interface must be submitted by the customer to NASA in a time frame consistent with the deadlines of the 482 process. Configuration control is implemented by NASA to provide a means for documenting and correcting discrepancies, and authorizing NASA use of a new or modified user interface as delivered by the customer. NASA use of the software and user interfaces generally involves payload-related training and flight products, such as FDF procedures and ground support software and documentation.

Configuration control is not, in general, intended to be used to pre-approve a user interface change prior to its being implemented by the customer. Typically, a user interface change, whether proposed by the customer or by SSP, should be coordinated and agreed upon by all involved organizations, (project engineer, crew, and customer) prior to development by the customer.

Following development, the customer submits the modified user interface to the payload PE who prepares a 482. Approval of the 482 authorizes use of the user interface at JSC for training or procedure development activities. Pre-approval of a user interface change (in the form of an interim approval pending final submittal) may be sought from the SSP under two circumstances : when the customer/project engineer has reason to believe that the CPCB may disapprove the change (e.g. significant late changes), or when there is significant disagreement within the SSP, or between the SSP and the customer, over a proposed change.Following completion of the software and user interface development process, the customer prepares and delivers flight software. The flight software is then baselined at the POCCB using the procedures described in this addendum and the main body of POCSMP. (Prior to baselining, only procedures described in this addendum apply).

5.2 INITIATING A 482 FOR POC SOFTWARE CHANGES

Reference Section 7.3, JSC Form 482, of the POCSMP. Anyone may submit a CR applicable to the user interface of a payload application. All proposed changes must be signed by the initiator's organization representative.

A complete CR package should include the following items :

a. A completed 482

b. Two copies of the revised software on floppy disks

c. One copy of the software is for payload Project Engineer validation

d. Two copies of the payload emulator (if required)

e. Redlined pages of the most recently published FDF book(s)

* Note : Additional requirements are levied if the changes affect the SMS Model.

5.2.1 User Interface Change Definition

The definition of a user interface change includes, but is not limited to, the following :

a. Change in the content or location of screen messages, windows,

parameter labels or menus

b. Change in keystroke sequences used to initiate software or payload

functions

c. Any change in the flow, timing, or speed of operations that are

noticeable on the computer screen

d. Any change in audible indications (tones)

e. Any change to font or to representation of data which are presented

on the user interface (e.g. graphic displays)

f. Any changes to user interface-associated documentation

g. Any changes to titles or labels on displays.

In general, any change to the 'look and feel' of the software will be considered a user interface change. All user interface changes should be consistent with the user interface programming standards and guidelines. (Reference Addendum B of the POCSMP.)5.2.2 Software Changes Not Affecting the User Interface

Changes made to the customer-developed payload software, payload emulator or supporting documentation which in no way affect the user interface but which the customer wishes to have distributed to the JSC operations community will be submitted to the FDF Management Office without a CR. There are two exceptions to this policy: (1) when the SSP has prepared a general purpose model (GPM) of the payload for use in Shuttle Mission Simulator training; and (2) when the customer requests a late change (defined as after baseline of the flight software). Changes falling within these exceptions will require CPCB approval before implementation.

5.3 SOFTWARE DELIVERY DEADLINES

Reference Section 8.2 of the POCSMP.

5.4 APPEALS

Reference Section 7.3.1 of the POCSMP.

5.5 COPYRIGHTS

Reference Section 7.4 of the POCSMP.

5.6 USER INTERFACE DISCREPANCY REPORTING

Since the software user interface is an extension of written payload interface procedures, discrepancies will be reported in the same manner as for the written procedures. Prior to the Flight Operations Review (FOR) mail-out, payload/user interface or documentation discrepancies will be reported to the payload PE . Between the FOR mail-out and the occurrence of the FOR, Discrepancy Notices or DNs will be prepared and submitted to document software interface or documentation discrepancies. Subsequent to the FOR, discrepancies will be reported via submittal of Crew Procedures Change Requests, Form 482, to the CPCB.

6.0 POC SOFTWARE PROCESSING

Reference Section 8 of the POCSMP.

7.0 DOCUMENTATION

Reference Section 9 of the POCSMP.

Section page

1.0 PURPOSE B-1

1.1 SCOPE B-1

2.0 WINDOWS STANDARDS AND GUIDELINES B-1

2.1 INITIALIZATION B-3

2.1.1 Hard Disk Boot B-3

2.1.2 Floppy Disk Boot B-4

2.2 ACCESS TO DOS B-4

2.3 COMMAND AND FUNCTION EXECUTION B-4

2.4 COMMAND ACKNOWLEDGMENT B-4

2.5 RAPID SHUTDOWN B-5

2.6 HELP FUNCTIONS B-5

2.6.1 User Help Function Conventions B-6

2.7 SOFTWARE VERSION IDENTIFICATION B-6

2.8 DATA INPUT B-6

2.9 OUTPUTS B-7

2.10 ENHANCED USER OPTIONS B-7

2.11 PROGRAM STATUS AND MALFUNCTION INFORMATION B-7

2.12 MESSAGES AND PROMPTS B-8

2.13 MISCELLANEOUS GUIDELINES B-8

3.0 GUIDELINES FOR DOS B-10

3.1 DATA INPUT B-10

3.2 COMMAND AND FUNCTION EXECUTION B-11

3.3 OUTPUTS B-11

3.4 DISPLAY AND MENU CONVENTIONS B-11

3.5 USER HELP FUNCTION CONVENTIONS B-12

3.6 ENHANCED USER OPTIONS B-12

3.7 PROGRAM STATUS AND MALFUNCTION INFORMATION B-12

3.8 MESSAGES AND PROMPTS B-13

4.0 SUMMARY OF KEYSTROKE CONVENTIONS B-14

4.1 REQUIRED KEYSTROKE CONVENTIONS B-14

4.2 RECOMMENDED KEYSTROKE CONVENTIONS B-14

1.0 PURPOSE

User interface programming standards and guidelines have been developed to provide SSP customers with an efficient and flexible environment for development of POC applications. The approach used to develop these standards relies on using industry standards and a minimum of mandatory requirements which could constrain software development flexibility. The emphasis has been placed on establishing guidelines designed to achieve the following mission success objectives :

a. Efficient use of flight crew time while on-orbit.

b. Efficient use of flight crew and flight controller training time.

c. Minimize training.

d. Consistent input and output formats.

e. Maximize the probability and degree of mission success.

f. Efficient data entry.

g. Protection from catastrophic errors, such as loss of most or all of the data.

h. Provide a flexible software development environment.

1.1 SCOPE

The following standards and guidelines are applicable to all software developed for use on an SSP POC. The SSP is currently using an IBM ThinkPad 755C (called the 486 PGSC). Because the SSP currently has selected IBM-compatible machines as the PGSC, the use of DOS and Windows is assumed. Programs running under UNIX on a PGSC are encouraged to follow the DOS and Windows guidelines as much as possible. Although these guidelines specifically do not apply to COTS software, whenever possible, COTS software consistent with these guidelines is preferable to software which is not. Guidelines for UNIX and X-Windows may be developed later.

2.0 WINDOWS STANDARDS AND GUIDELINES

Industry standards have been developed in many user interface guides and it would be wasteful to repeat the work or copy the complete results here. The evolution towards Windows based operating systems and the current use of Microsoft Windows 95 (or later versions) on the PGSC dictate that new applications be programmed to operate in a Windows environment whenever possible. The document "The Windows Interface : An Application Design Guide", Microsoft Corporation, 1992, is the primary source for defining the standards and guidelines for Windows Interfaces. Its principles easily apply to DOS applications in most situations; i.e. good DOS applications resemble Windows applications. It is strongly recommended that anyone developing programs for PGSCs read this document, abbreviated WIADG, beginning with the introduction. To easily see examples of successful implementation of these guidelines, try using such COTS products as MS Office. The Astronaut Office uses these products, Word, Excel, Powerpoint, for example, as their standard office software and crews are likely to be most familiar with the WIADG conventions these products use. (* Note : For additional information on developing Windows applications, refer to the Microsoft Developers Network, http://www.microsoft.com/msdn .)

This document contains guidelines and standards for DOS PGSC applications. A number of these guidelines conflict with the WIADG. For example, DOS PGSC programs were required to use a certain keystroke sequence for toggling tones, however that choice conflicts with the WIADG. New development projects should use the WIADG and this document as their primary source for development guidelines. Please feel free to contact the MOD POCCB Chairman at (281) 244-5790, or write to POCCB Chairman, Mail Code DO34, NASA/JSC, Houston, TX 77058 with questions.

As the WIADG document admits, it is not a complete set of guidelines. New situations will arise in which interface decisions will need to be made. A thorough understanding of the existing documentation will assist in making good decisions. In any case, common sense will always be invaluable in implementing whatever guidelines are used.

The following are broad guidelines for developers :

• Coordinate regular reviews and demos of displays and user interfaces with the crew and flight control team as early as possible in the development cycle.

• Use standard STS nomenclature in display.

• Provide or display only data important to mission success and significant in terms of crew interface.

• Protect data from inadvertent errors and hardware failures (with range checking on input, frequent saves to small files, etc.)

• Icons for submenus can be included in the application's .exe file and do not have to be in a separate .ico file.

• The customer will be assigned specific directories where all files of the application(s) will reside, including DLLs which would typically be in the Windows and/or Windows System directories.

• An application cannot modify .ini files in the windows subdirectory.

• An application may only use one timer.

• Applications must use standard DOS Read/Write commands.

• Applications cannot be TSR (Terminate/Stay Resident) programs.

• For DOS applications, no more than 1.5MB of extended memory (this includes the COMMAND.COM file) is available.

• Applications need to be compatible with STS startup files (e.g. config.sys, autoexec.bat) and use no more than 540K conventional RAM.

For purposes of clarity, the "Notation for Keys and Key Combinations" guidelines from the WIADG, Introduction, page xi, as appropriate for this document are repeated here :

• Key names appear in capitals; for example, CTRL or SHIFT.

• Simultaneous key combinations are linked by plus signs; for example, CTRL+B or CTRL+SHIFT+B. This notation indicates that the user should hold down the CTRL key while pressing the B key; or hold down the CTRL and SHIFT keys while pressing the B key.

• Sequential key combinations are linked by commas; for example : ALT,F. This notation indicates that the user should press and release the ALT key, and then press and release the F key.

This notation will be used for describing key strokes in this document and is the standard notation for Flight Data File procedures as well.

2.1 INITIALIZATION

Initialization is an orderly procedure which must be followed to ensure proper operation of the POC and the software package. Automatic initialization from data files or available data streams is desirable and may also include opening files for logging data, keystrokes, or recording application messages. A message should be presented with the names of the data files to the user as part of the program initialization and termination status. If the user is presented with options during initialization the consequences of the selection should be displayed before user action is required.

In the event that the application is unexpectedly restarted without first having gone through a normal shutdown, there should be a method for the application to determine the state of any equipment to which it interfaces and report that to the user. The application should be responsible for its own recovery as much as possible.

There are two rebooting techniques :

1. Warm boot - CTRL+ALT+DEL

2. Cold boot - Power off, wait five seconds, power on

A warm boot resets registers, closes files, clears memory, and sets everything to its initial state. A cold boot does the same things, but also performs a diagnostic check first.

2.1.1 Hard Disk Boot

Unstow the PGSC and connect to the appropriate power source. Power on the PGSC. The PGSC will automatically boot to the hard disk. Most applications on the hard disk will be made accessible through the use of icons in the Windows Program Manager screen (including DOS applications). The Program Manager and its options are controlled by the POCCB.2.1.2 Floppy Disk Boot

The 486 PGSC will automatically try to boot from a floppy in the floppy drive upon power up.

2.2 ACCESS TO DOS

Applications should not require the crew to access DOS at any time. Once the computer has been initialized the software should not terminate to DOS. If DOS level commands are required, developers should include a file manager option that allows only the DOS level commands required for proper operation of the application. The commands issued are to be limited to keystrokes or menu selections.

2.3 COMMAND AND FUNCTION EXECUTION

a. Minimize the number of keystrokes or mouse movement needed to perform simple or routine functions and commands.

b. Order the items in any menu in some logical order, either by importance or usage.

2.4 COMMAND ACKNOWLEDGMENT

The command-message-acknowledge sequence shall be used for all command executions that have a substantial impact on mission success. The rationale for this requirement is to prevent inadvertent command execution by the crew. Substantial impact on mission success includes, for example, rapid shutdown, discontinuing data collection, erasing data or abandoning work prematurely resulting in significant lost time.

The use of an arm-fire command execution sequence such as ALT+RETURN has been used extensively in previous PGSC DOS applications to protect against inadvertent commands in the zero-g environment. It is desirable that no single keystroke be able to substantially affect program operation. In the Windows environment the use of arm-fire for commands is satisfied by using the mouse, menu commands, or shortcut key sequence of greater than one keystroke. (Note : When Windows warning messages are produced, the user will acknowledge with a single keystroke, <Enter> .)

The following is an example of this approach for a DOS application with no mouse capability.

Sample menu :

Options

Continue Continue to next process step

Save Save current data and continue processing

Quit Terminate run, do not save data, and return to main

menu

Exit Terminate run, save data, and return to main menu

Example of user actions :

1) User selects 'Quit' from menu using mouse or ALT+Q .

2) Selection is followed by the message :

"Program termination requested, data will not be saved. Press ALT+RETURN to confirm."

3) User selects ALT+RETURN to confirm.

For an application with mouse capability, step 2 could be :

2) Selection is followed by the message :

"Program termination requested, data will not be saved."

The two buttons might be : 'OK' and 'Cancel' , with the default being Cancel.

2.5 RAPID SHUTDOWN

A rapid shutdown function must be provided in applications that generate data needing to be saved or that connect to any external device. The rapid shutdown functions will provide the crew with the capability to rapidly discontinue operation of an experiment in an orderly manner. The orderly shutdown should be designed to save accumulated data and preserve mission success to the greatest extent possible, consistent with an expeditious shutdown. This capability would be used in the event of a mission contingency that requires immediate crew attention and termination of middeck or payload activities. The rapid shutdown function should terminate operation of the application within 15 seconds.

In all applications, the rapid shutdown function will be a command-message-acknowledge sequence initiated by SHIFT+F4. Previous to this version, CTRL+ALT+ESC was used by PGSC DOS programs. A rapid shutdown request should be followed by a message requesting confirmation. A DOS application should display :

"You have requested RAPID SHUTDOWN of this application. <Mention consequences.> Press ALT+RETURN to confirm."

A Windows application should display :

"You have requested RAPID SHUTDOWN of this application. <Mention consequences.> Do you wish to continue ?"

Include buttons 'Yes' and 'No' ,or 'OK' and 'Cancel?' . The default in each case should be to cancel the rapid shutdown.

2.6 HELP FUNCTIONS

Help information should be provided for all programs. Help information must be provided if CTRL, ALT, SHIFT, or function key activated commands are available from a display and not explained on the display. The preferred approach to providing help information about a display is to include action and keystroke explanations on the display itself. However, if display space constraints make on-screen help information impractical or if additional information is desirable, help information may be provided by use of help windows or displays or if absolutely necessary by using a cue card. Use of cue cards should be avoided.

2.6.1 User Help Function Conventions

The software developer should provide the capability for on-screen user help whenever possible. To minimize training, this Help capability should use the Windows Help System.

a. The Help system should, at a minimum, provide a brief explanation on all menu selections.

b. Include a prompt message when requesting an action from the crew. The prompt should direct the user to the appropriate action or indicate that a choice of actions is available. Pertinent information should be included in the Dialog box.

2.7 SOFTWARE VERSION IDENTIFICATION

Software shall be identified by a version number and effective date. The version and effective date should be assigned by the organization responsible for software development and follow industry standards. Each time a software update is delivered to the POCCB, the version number must be incremented and a new effective date established. The effective date should indicate the date after which the new software version is considered to be the baseline. The appropriate version and effective date should be displayed on the floppy disk label, if applicable, and must be accessible somewhere in the program (usually in Help/About... menu/menu-item). If flight specific data is required the flight ID, version number, and effective date should be displayed.

2.8 DATA INPUT

a. If data is needed in an application, it should be accessed directly or automatically rather than by crew input. If crew input is required, a reference to the data source should be displayed on-screen. (e.g. A static display can be applied to indicate the SPEC or GPC display number where the data can be found).

b. To the extent possible, verify crew inputs and provide out-of-limits response messages and instructions to re-enter data.

c. Offer default values for inputs. When possible, provide numeric input units and valid range limits on the input display screen. Values should be fully editable with all the normal editing keys available: RIGHT and LEFT ARROW, HOME, END, and BACKSPACE. TAB, SHIFT-TAB, PGUP, PGDN, and RETURN should all be used per the WIADG for navigating between values and Dialog boxes.

d. Lock out or trap invalid keystrokes. For example, if valid menu selections include only ALT+A, ALT+B, and ALT+C, the application should provide some indication that an invalid input has been made.

e. The software developer should consider providing an internal clock update capability in the software application. The PGSC internal clock is set to GMT prior to launch with an accuracy delta of about five seconds per day. If greater accuracy is desired, an internal update capability should be accessed and the crew should be instructed to check clock accuracy regularly. In addition, the PGSC internal clock is powered by the internal battery pack during stowage prior to launch and may require resetting if the battery pack should discharge.

2.9 OUTPUTS

a. The amount of data presented and displayed should probably be proportional to the amount of crew training and on-orbit time. Therefore, it is important to carefully consider which data to provide and/or display to the crew. Data which is most important to mission success and the crew interface should receive priority and emphasis. Additional data, which may be interesting or has a lower potential for being useful, should be placed in secondary displays or be optionally available.

b. Use graphic displays and limit tabular displays to focus on important crew interface information.

c. Output displays which extend to more than one screen or window at a time should be scrolled with the arrow keys and PgUp/PgDn.

d. Reference frame, units and other pertinent information should be displayed to the user on the output screen. Select the appropriate units for displaying your data. If more than one set of units are used, the user should be able to select which is used.

2.10 ENHANCED USER OPTIONS

The program developer should keep in mind that the user's general computer knowledge and familiarity with software applications may vary from extensive to minimal, and the amount of time available for the crew to train with an application is very limited. The above guidelines have been established with this in mind.

In some cases, however, the user may be very knowledgeable in computer applications. For this user, the developer should enhance user operation by providing the capability to use shortcut keys and allow the user to move more quickly through the program.

Also the developer may allow the user to add or remove elements of the display. This allows the experienced user to focus on what is important at any given moment.

2.11 PROGRAM STATUS AND MALFUNCTION INFORMATION

a. Tones may be used to indicate parameter out-of-limit conditions or other situations that require crew attention. However, tones may not be the sole source for drawing crew attention to the PGSC (WIADG, Miscellaneous Topics, page 213). The ambient noise environment of the Space Shuttle is such that a tone may not always be audible. Other means should also be employed, such as dialog boxes or blinking status indications. A means to toggle the tones on and off must be provided. The recommended shortcut key sequence is CTRL+T .

b. A brief program status indication should generally be placed at the top of the screen. This should include at least the program name and perhaps the current mode of operation, MET, and/or experiment time.

c. For more complex programs, the use of a status page to summarize the status of various systems is recommended.

d. Informational messages should generally be placed at the bottom of the display. Flashing messages are useful to draw attention. A method to easily disable flashing displays should be provided.

e. Error or fault messages should either be at the bottom of the display, or if important, may perhaps deserve a dialog box of their own.

f. A fault summary page (FSP) is an important feature that can be included in POC software and also referred to as an Error Log file. The FSP should contain a listing of all error messages encountered while the program is executing. The fault messages should be numbered, time-stamped, and saved as they occur. The FSP serves as a guide for attempting to solve anomalies and may also help determine if the cause of a problem was POC hardware, software, or non-POC equipment.

2.12 MESSAGES AND PROMPTS

a. Keep messages short and concise.

b. Do not display many messages at the same time.

c. Do not rely on messages as the only means of achieving or preventing a critical response as they may not always be read the first time.

d. Use messages and prompts to indicate when an action is required and what the action should be.

e. Provide a message indicating that a command or function is in progress if the time to the response is significant; for example, loading a large initialization file. Always try to minimize time spent by the user waiting for input/output displays.

2.13 MISCELLANEOUS GUIDELINES

The following are clarifications or extensions to the WIADG :

a) Dialog boxes should have borders to help distinguish them from the background.

b) Applications with multiple screens which might normally be used at the same time should have default sizes and positions which make sense. Newly created windows should not be opened with random sizes and positions if there is a default which makes sense.

c) Status indications should be close to the text describing them or the action they status.

d) The PGSC is a VGA active matrix color screen. Developers should be sensitive to the tradeoffs between populating a screen with useful information and simply putting too much in a small space. Common sense will be important here. The information, alpha-numerics or graphics, must be useful ! Easily read numbers on multiple screens will do more to ensure mission success than one screen containing every bit of information, but difficult to read or understand.

e) Buttons should be neither excessively large, requiring too much real estate, nor too small, causing problems with legibility and difficulty with activation. Also, they should all be accessible via keyboard entries.

f) Information shall not be displayed solely by color (WIADG, Miscellaneous Topics, p213). For example, it may be used to draw attention to certain features on the screen, but simply changing the color of a feature may not be used as the only cue for something which requires user action or notice.

g) Whenever possible, the mouse shall not be the only means of implementing an action (WIADG, Introduction, page x). All application options should be accessible using menus and should implement the ALT+(underlined letter) technique for accessing menu options. In addition to menu options, frequently used commands should have a button or a shortcut key sequence defined for the experienced user. All shortcut keys must be defined either next to their menu option or in a master list in the Help utility.

h) Automated processes should be utilized as much as possible when developing applications. Some experiments and applications lend themselves naturally to this. However, to take advantage of the crew's ability to interact in real time with an experiment or process, it is advisable to include the options to perform all actions or tasks manually, if required. Because the opportunity to fly experiments or development projects in space is limited, it may also make sense to include some sort of experiment diagnostics software, either as a part of the primary application or as a separate program. Such a package may permit the crew to achieve mission success by troubleshooting the problem independently or working in conjunction with the experimenter. Including such features as diagnostics and saving files with keystroke audits may be particularly appropriate for contingency operations or for infrequently manifested applications. These capabilities might then be scrubbed should the application become certified or used routinely.

i) Incorporate the ability for external hardware connection ports to be changed from within the application. The application should provide user-selectable configurations, in which data can be accepted from multiple serial ports (COM1, COM2, etc.).

3.0 GUIDELINES FOR DOS

The user interface guidelines established in this section are intended to provide software developers with some insight into unique aspects of the microcomputer/user interface in the SSP environment. Incorporation of these guidelines into applications, to the degree that it is practical, optimizes the crew interface. The SSP recognizes the need to maintain a flexible environment for software development. These guidelines may not be applicable in all cases and the developer is encouraged to identify incompatibilities early in the development process. Early identification of incompatibilities allows effective coordination with the user and flight control community and ensures an optimum user interface. In general, the software developer should keep in mind the following broad guidelines when developing applications :

a. Get early coordination with the crew and flight control team.

b. Provide or display only data which is important to mission success

and is significant in terms of the crew interface.

c. Protect data against inadvertent errors and hardware failures.

Use these guidelines to the extent practical for your application and bring inconsistencies to the attention of the crew and flight control community.

3.1 DATA INPUT

a. If required data is available in an application, the data should be

accessed directly rather than by crew input.

b. To the extent possible, verify crew inputs and provide out of limits

response messages and instructions to reenter data. (See Section

3.8, Messages and Prompts .)

c. Offer default values for inputs. When possible, provide numeric

input units and valid range limits on the input display screen.

d. Lock out or trap invalid keystrokes. For example, if valid menu

selections include only ALT+A, ALT+B and ALT+C, other

keystrokes should not be allowed. The application should either not

respond until a valid input is provided or it should provide an

invalid input response message. (See Section 3.8, Messages and

Prompts .)

e. The software developer may wish to consider providing a mission

elapsed time (MET) or Greenwich mean time (GMT) update capability

in the software application. The PGSC internal clock accuracy is

5 sec/day. If greater accuracy is desired, an MET/GMT update

capability should be provided and the crew should be instructed to

check clock accuracy regularly. In addition, the PGSC internal

clock is powered by the internal battery pack during stowage prior

to launch and may require resetting if the battery pack should

discharge.3.2 COMMAND AND FUNCTION EXECUTION

a. The use of menus to execute program functions and commands is

preferred over other means of execution such as the use of function

keys, Alt or Control key combinations, or command lines. In some

cases, the use of menus will not be possible and the use of these

other means of function or command execution will be necessary.

When these other means are used, on-display messages or prompts and/

or help screens called by F1 are strongly recommended or required.

b. Minimize the number of keystrokes needed to perform simple or

routine functions and commands.

c. Order the items in any menu from most important (or most used) at

the top to least important (or least used) at the bottom.

d. Use the ALT+RETURN combination to select irreversible menu

selections.

e. Major functions and commands with a potential to significantly

impact mission success should use the key-message-key approach to

command execution described in section 2.4 .

3.3 OUTPUTS

a. Data presented and displayed is proportional to crew training and

on-orbit time. Therefore, it is important to carefully consider

which data to provide and/or display to the crew. Data which

is most important to mission success and the crew interface should

receive priority and emphasis. Additional data, which may be

interesting or has a lower potential for being useful, should be

placed in secondary displays or be optionally available.

b. Use graphic displays and limit tabular displays to focus on

important crew interface information.

c. Output displays which extend to more than one screen or window at

a time should be scrolled with the arrow keys.

d. Reference frame, units and other pertinent information should be

displayed to the user on the output screen.

3.4 DISPLAY AND MENU CONVENTIONS

a. Provide menu-driven paths to the previous displays. Enhancements

for the more advanced user are also encouraged. (See Section

3.6, Enhanced User Options.)

b. Use ESC to return to the previous display. In the event that

program termination could result in loss of significant work, a

warning message indicating the potential loss of data and

requiring a confirmation response (e.g. ALT+RETURN) prior

to continuation, should be provided. (See Section 3.8, Messages and

Prompts.) In general, program termination menu selections should be

provided in the program base menu to allow termination with and

without a data save capability.

c. Use the arrow keys to move up and down menu selections.d. The PGUP and PGDN keys may also be used to move forward and

backwards in a series of menus. The use of ESC to return to

the previous display should also be available.

3.5 USER HELP FUNCTION CONVENTIONS

The software developer should provide the capability for on-screen user help whenever possible.

a. Provide descriptive names and brief explanations for menu

selections as part of the menu.

b. Include help screens for ALT, CTRL, or FUNCTION key activated

commands which do not have on-screen explanations.

c. Include a prompt message when requesting an action from the crew.

The Prompt should direct the user to the appropriate action or

indicate that a choice of actions is available.

3.6 ENHANCED USER OPTIONS

The program developer should keep in mind that (1) the prior general computer knowledge and familiarity of the user with software applications may vary from extensive to minimal, and (2) the amount of time available for the crew to train with an application is very limited. The above guidelines (such as providing menu paths throughout the program and providing extensive on-screen help capabilities) have been established with this in mind.

In some cases, however, the user may be very knowledgeable in computer applications. For this user, the developer may want to enhance user operation by providing the capability to shortcut menu systems and allow the user to move more quickly through the program.

a. Provide ALT, CTRL, and/or FUNCTION key-based commands that

bypass (but do not replace) menu driven activities.

b. Allow ALT+LETTER selection from menus. In this case, highlight

the letter that makes the selection. For example :

Copy - use ALT+C

Erase - use ALT+R

c. Allow the user to add or remove elements of the display. This

allows the experienced user to focus on what is most important

at the particular time.

3.7 PROGRAM STATUS AND MALFUNCTION INFORMATION

a. Tones may be used to indicate parameter out-of-limit conditions or

other situations that require crew attention. If tones are used,

CTRL+T must be available from all displays to disable/enable

the tone.

b. Brief program status indicator should generally be placed at the

top of the screen. These could include current mode of operation,

mission or experiment elapsed time.

c. For more complex programs, the use of a status page to summarize

the status of various systems is recommended.

d. Error or fault messages should generally be placed at the bottom

of the display. Such flashing messages are useful to draw

attention to the message.

e. The fault summary page (FSP) is an important feature that can be

included in POC software. The FSP should contain a listing of all

error messages encountered while the program is executing. The

FSP serves as a guide for attempting to solve anomalies encountered.

The FSP may also help determine if the cause of a problem was POC

hardware, software, or non-POC hardware. The fault messages should

be numbered and/or time-stamped and saved as they occur. This FSP

inclusion may help identify any error(s)/anomalies) and assist in

their elimination on future flights.

f. The POC application should be written to allow maximum data

retention and recovery since a reboot may have to be performed at

any time.

There are two rebooting techniques :

1. Warm boots - CTRL+ALT+DEL

2. Cold boots - Power off, wait 5 seconds, power on

A warm boot resets registers, closes files, clears memory, and sets

everything to its initial state. A cold boot does the same things,

but also performs a diagnostic check first. A cold boot is

mandatory when moving between payload and STS applications.

3.8 MESSAGES AND PROMPTS

a. Keep messages short and concise.

b. Do not display many messages at the same time.

c. Do not rely on messages as the only means of achieving or preventing

a critical response (they are not always read the first time).

d. In general, messages should be located at the bottom of the page.

e. Use messages and prompts to indicate when an action is required and

what the action should be.

f. Provide a message indicating that a command or function is in

progress if the time to the response is significant (e.g. loading

a large file). Always try to minimize time spent by the user

waiting for input/output displays.4.0 SUMMARY OF KEYSTROKE CONVENTIONS

These conventions apply to software developed specifically for a POC. COTS software does not need to meet these requirements and recommendations.

4.1 REQUIRED KEYSTROKE CONVENTIONS

a. CTRL+ALT+ESC - Rapid shutdown

b. F1 - help

c. CTRL+T - Toggle tones on/off

4.2 RECOMMENDED KEYSTROKE CONVENTIONS

a. ALT+S Save data, continue running application

b. ALT+X Save data, exit application

c. ALT+Q Quit application without saving data. Requires

confirmation

d. ALT+LETTER Select corresponding menu choice

e. ALT+RET Confirm an entry or menu selection

f. UP DN Move up or down within a menu

g. PGUP PGDN Move between menus or displays

h. ESC Return to previous menu or display

Organizations seeking to develop and subsequently manifest software for the STS POC should adhere to the following development process. (Note : Payload customers should only follow those items denoted by asterisks '*'. Payload customers should also adhere to the requirements and guidelines described in the Payload Applications and Project Engineer Responsibilities, Addendum A of the POCSMP.)

L 120 Days

A Submit POCCB Change Request (CR) to POC Coordinator. Reference the USA PH&G. (See Section 7.1, POCCB CR)

B Make presentation of CR to POCCB

C Receive approval and validation requirements from POCCB to begin development

*D Review list of generic POC software and

POCCB-provided DLLs for use by all applications (contact POC Coordinator)

*E Ensure compliance with User Interface Programming Standards and Guidelines

(Addendum B of POCSMP) during development process

*F Ensure software meets General POC Guidelines and Policies in Section 4 of the POCSMP

and hard drive configuration constraints as outlined in Section 5.1 of the POCSMP

*G Contact FDF to begin development of crew operating procedures, if required.

H Submit items required by POCCB for validation (summarized below), according to the level

assigned. (See POCSMP, Section 6.2, POC S/W Validation Definitions.)

I. Receive POCCB CR approval to manifest software for flight

J. Submit POC hardware requirements list to POC Coordinator

Upon POCCB approval for a specified flight, the following milestone dates apply :

(Also see POCSMP, Table 8-II, POC Software Delivery Deadlines)

L - 120 Days * Contact FDF coordinator to incorporate crew operating procedures into

appropriate FDF document (if required)

~ L - 90 Days * Submit software to POC Coordinator for integration into PGSC Training Load if

software will reside on an STS-controlled hard drive.

1. For COTS applications required to assist developed s/w, supply license

agreement for the 45 copies required by POCCB to meet training

and flight objectives. (See POCSMP, Section 7.4, Copyrights)

2. 482 Change Request. 482 may add S/W to generic

bookshelf of STS software for all flights (See POCSMP, Section 7.3, Generic and Flight-Specific Configurations)

3. Changes Required to the Baseline PGSC configuration

4. Users Guide (See POCSMP, Section 9, POC S/W Documentation

Requirements and Guidelines)

5. Copy of Executable

6. File listing of software and installation instructions for integration into

STS flight load * Submit flight certified diskettes with flight software if a floppy-only application. (See

POCSMP, Section 8.4, Floppy Disks for Flight)

* Follow POCCB Configuration Management Policies for Baselined Software. (See

POCSMP, Section 7.3, JSC Form 482 )

* If a STS Hard Drive Load is required for KSC IVTs :

1. Contact POCCB SSP co-chairman to ensure COTS licenses are available to support test

2. Coordinate loading of STS Hard Drive with POC Coordinator

~ L - 50 Days * Deadline for submittal of software to POC Coordinator for integration into

PGSC Flight Load

* Submit Software Requirements Compliance Letter to POCCB Chairman (See POCSMP, Section 8.1.2)

* If Flight load testing desired, schedule date with POC Coordinator

(Prior to loading of flight hardware)