mg50539000013e6_b.doc

PREPARED BY

BOEING

CS SEIT IPT Becky Gaede SW IPT Mark Kostelic

AUTHORITY

WBS 440

16 August 2010

SUBJECT

PSDR/NR

SOFTWARE DESIGN DOCUMENT

FOR THE

POSITIONAL TRAINING EMULATOR

OF THE GLOBAL POSITIONING SYSTEM

CONTRACT NO. F04701-96-C-0025

ADP SEQUENCE NO. 118-5

Prepared for:

U.S. AIR FORCE

HEADQUARTERS SPACE & MISSILE SYSTEMS CENTER

LOS ANGELES, CA 90009-2960

Prepared by:

BOEING

SPACE AND INTELLIGENCE SYSTEMS

2201 SEAL BEACH BLVD.

SEAL BEACH, CA 90740

Distribution D: Distribution authorized to DOD and US DOD contractors only. (Reason: Administrative or Operational Use) (Date of Determination: 28 September 1995). Other requests for this document shall be referred to NAVSTAR Global Positioning System Joint Program Office (SMC/CZ).

WARNING: This document contains technical data whose export is restricted by the Arms Export Control Act (Title 22, U.S.C. 2571 et seq.) or Executive Order 12470. Violation of these export control laws is subject to severe criminal penalties. Dissemination of this document is controlled under DOD directive 5230.25 and AFI 61-204. Include this notice with any reproduced part of this document.

DESTRUCTION NOTICE: For classified documents, follow DOD 5220.22M, National Industrial Security Program Operating Manual. For unclassified limited documents, destroy by any method that will prevent disclosure of the contents or reconstruction of the document.

FORM 3935-G-1 REV 1-97 (Word 7.0) Document Revision & Version History

Notices

The following terms are trademarks, registered trademarks, or service marks of other companies and organizations. Each term is the property of its respective owner.

Contents 11.

Scope

11.1 Identification

11.2 System Overview

11.2.1 PTE Mission

21.3 Document Overview

21.3.1 Conventions

32.

Referenced Documents

32.1 Government Documents

32.2 Non-Government Documents

63.

PTE Software Design Decisions

63.1 System

63.1.1 Reuse

63.1.2 Single Universe

63.1.3 Time Source

63.1.4 Security

73.1.5 Student Monitoring

83.1.6 Virtual Network Computing

83.2 Instructor Control

83.2.1 User Interface

93.2.2 Training Scenario

93.2.3 Ghost Operations

93.2.4 Script Players

103.2.5 Unconditional Script Execution

103.2.6 Model Data Viewer(MDV)

103.3 Sim

103.3.1 Infrastructure Overhaul

113.3.2 Model Dispatching

113.3.3 Flat File Database

113.4

AEP

113.4.1 Master Control System (MCS) Time Manipulation

133.4.2 AEP - MCS State Save and Restore

154.

PTE Software Architecture Design

154.1 Software Components

154.1.1 PTE Software Component Relationships

174.1.2 Instructor Control Component

204.1.2.1 IC Scenario Director

224.1.2.1.1 Script Player

244.1.2.2 Student Monitor

254.1.2.3 Model Data Viewer

284.1.2.4 Script Composer

284.1.2.5 Directive Generator

294.1.2.6 PTE System Supervisor

304.1.2.7 IC Database Description

324.1.3 Sim Component

334.1.3.1 Sim Executive

334.1.3.1.1 Sim Executive Activation

334.1.3.1.2 Sim Executive Comm Channels

334.1.3.2

TRICS

334.1.3.3 Space Sim

344.1.3.3.1 SV Models

344.1.3.3.2 Flight Software Use

344.1.3.3.3 SV Anomalies

344.1.3.3.4 Space Sim Activation

354.1.3.3.5 Space Sim Comm Channels

354.1.3.4 Environment Sim

354.1.3.4.1 Env Anomalies

354.1.3.4.2 Env Sim Activation

354.1.3.4.3 Env Sim Comm Channels

354.1.3.5 Ground Sim

354.1.3.5.1 Ground Sim Models

374.1.3.5.2 Ground Sim Anomalies

374.1.3.5.3 Ground Sim Activation

374.1.3.5.4 Ground Sim Executable Name

374.1.3.5.5 Ground Sim Comm Channels

374.1.3.6 Sim Database

404.1.4 AEP Component

404.1.4.1 AEP Database Save and Restore

404.1.4.2 Instructor Control Executor

404.1.4.3 Ghosting

414.1.4.4 Positional Training Database Support

424.2 Concept of Execution

424.2.1 System Modes

424.2.1.1 Crew Mode

424.2.1.2 Positional Mode

424.2.2 System States

434.2.2.1 Start

444.2.2.2 Load

444.2.2.3 Pause

444.2.2.4 Run

444.2.2.5 Speed

444.2.2.6 Save

454.2.2.7 Quit

454.2.3 System Training Scenario Data

464.2.4 Execution Flow

484.2.4.1 Simulated Signal

484.2.4.1.1 S-Band Uplink Message

494.2.4.1.2 L-Band Tracking Message

494.2.4.1.3 S-Band Downlink Message

504.2.4.1.4 L-Band Downlink Message

504.2.4.2 AEP/Ground Equipment Interaction

684.2.4.3 Execution Control

704.2.5 Hardware – Software Allocation

714.2.5.1.1 Server Overview

724.3 Interface Design

735.

Software Item Detailed Design

735.1 PTE Components Detailed Design

735.1.1 Instructor Control Detailed Design

735.1.1.1 Scenario Director

755.1.1.1.1 Scenario Director Window (GUI)

775.1.1.1.2 Scenario Director State Engine

915.1.1.1.3 Director Data Store

925.1.1.1.4 Communications Channels

985.1.1.1.5 Log Manager

1005.1.1.1.6 Scenario Description

1015.1.1.1.7 SD Panel Control

1025.1.1.2 Script Player

1045.1.1.2.1 Script Player Interface

1065.1.1.2.2 Script Player GUI

1085.1.1.2.3 Script Player State Engine

1245.1.1.2.4 Player Data Store

1285.1.1.2.5 SP Hookup

1295.1.1.2.6 Directive Generator Manager

1315.1.1.2.7 Sim Time Keeper

1325.1.1.2.8 SD Panel Control

1335.1.1.3 Student Monitor

1375.1.1.4 Model Data Viewer

1385.1.1.4.1 MDV Main

1405.1.1.4.2 MDV Manager

1415.1.1.4.3 MDV State Machine

1415.1.1.4.4 MDV Idle

1425.1.1.4.5 MDV Start

1425.1.1.4.6 MDV Run

1435.1.1.4.7 MDV Quit

1435.1.1.4.8 MDV Displays

1445.1.1.4.9 MDV Data Store

1455.1.1.5 Script Composer

1475.1.1.5.1 Script Composer GUI

1495.1.1.5.2 Script Class

1525.1.1.5.3 SC Controller Class

1565.1.1.5.4 Directive Parser Class

1585.1.1.5.5 Directive Definition Class

1605.1.1.6 Directive Generator

1615.1.1.6.1 Directive Generator GUI

1625.1.1.6.2 DG Controller class

1655.1.1.6.3 Directives class

1665.1.1.6.4 Parameters class

1685.1.1.6.5 Target class

1705.1.1.6.6 Timing class

1715.1.1.7 PTE System Supervisor

1715.1.1.7.1 Simeng processes

1715.1.1.7.2 Mission1 processes

1715.1.1.8 Instructor Control Database Description

1765.1.2 Sim Detailed Design

1765.1.2.1 Processes

1765.1.2.1.1 External Communication

1765.1.2.1.2 Inter-Process Communication

1775.1.2.2 Simulation Master Executive

1785.1.2.2.1 Control Loop

1805.1.2.2.2 Units

1895.1.2.3 Simulation Domain Model Executives

1905.1.2.3.1 Control Loop

1925.1.2.3.2 Model Dispatching

1935.1.2.3.3 Units

2015.1.2.3.4 Model_Data_Viewer

2015.1.2.4

TRICS

2025.1.2.4.1 Trx_Clock

2025.1.2.4.2 Trx_Comm_Center

2035.1.2.4.3 Trx_Directive

2045.1.2.4.4 Trx_Directive_Registry

2045.1.2.4.5 Trx_Environment_Variables

2055.1.2.4.6 Trx_Events

2055.1.2.4.7 Trx_Initial_Conditions

2065.1.2.4.8 Trx_Ipc_Glossary

2075.1.2.4.9 Trx_Log

2075.1.2.4.10 Trx_Messenger

2085.1.2.4.11 Trx_Model

2095.1.2.4.12 Trx_Models

2095.1.2.4.13 Trx_Model_Data_Collector

2105.1.2.4.14 Trx_Model_Data_Viewer

2115.1.2.4.15 Trx_Msg_Dispatcher

2115.1.2.4.16 Trx_Msg_Registry

2125.1.2.5 Simulation Domain Models

2125.1.2.5.1 Space

2235.1.2.5.2 Environment

2245.1.2.5.3 Ground

2255.1.2.6 Sim Database

2255.1.2.6.1 Structure

2265.1.2.6.2

CML

2305.1.2.6.3 Config

2315.1.2.6.4 Mimage

2315.1.2.6.5 Other

2315.1.2.6.6 Scenario

2325.1.2.6.7 Time Stamp

2325.1.2.6.8 Ground Configuration

2325.1.2.6.9 Player Items

2385.1.2.6.10 Operation

2425.1.3 AEP Detailed Design

2425.1.3.1 Classes

2435.1.3.1.1 SERV_pte_ice

2435.1.3.1.2 SERV_pte_string_util

2435.1.3.1.3 SERV_sched_dir_handler

2445.1.3.1.4 SERV_pte_thread_channel_executor_service

2455.1.3.1.5 SERV_pte_thread_channel_executor

2475.1.3.1.6 SERV_pte_thread_channel_executor_client

2475.1.3.1.7 SERV_pte_thread

2495.1.3.1.8 SERV_pte_time_control

2515.1.3.1.9 SERV_pte_cmd

2525.1.3.1.10 SERV_pte_cmd_initializer

2525.1.3.1.11 SERV_pte_thread_channel_listener

2535.1.3.1.12 SERV_pte_thread_command_queue

2545.1.3.1.13 SERV_pte_daemon

2555.1.3.1.14 SERV_pte_parser

2555.1.3.2 SERV_pte_msg

2565.1.3.2.1 SERV_pte_external_script_mgr

2575.1.3.2.2 SERV_pte_msg_socket

2585.1.3.2.3 SERV_pte_msg_swbus

2605.1.3.3 AEP Scenarios

2605.1.3.3.1 Daemon Delete

2615.1.3.3.2 Daemon Delta Save

2625.1.3.3.3 Daemon Full Save

2635.1.3.3.4 Daemon Load

2645.1.3.3.5 Daemon Sync

2655.1.3.3.6 Delete

2665.1.3.3.7 Delta Save

2675.1.3.3.8 Full Save

2685.1.3.3.9 Load

2695.1.3.3.10 Sync

2705.1.3.3.11 Pause

2715.1.3.3.12 Quit

2725.1.3.3.13 Run

2735.1.3.4 Speed

2745.1.3.5 Time

2755.1.3.6 Ack

2765.1.3.7 Dir

2775.1.3.8 Log

2785.1.3.9

KGR

2795.1.3.10 KI17 Cardholder

2805.1.3.11 KI17 Pegasus

2815.1.3.12

KIT

2825.1.3.13 List

2835.1.3.14 Memimage

2845.1.3.15 MS Clockerror

2855.1.3.16 Sv List

2865.1.3.17 Ping

2875.1.3.18 Svdata

2885.1.3.18.1 Sync Time

2896.

Requirements Traceability

2967.

Notes

2967.1 Technical Notes

2977.2 Acronyms

3007.3 Technical Glossary

List of Appendices

10.

APPENDIX A: SCRIPT LANGUAGE DESCRIPTION.

A-1

10.1 Introduction A-2

10.2 Script Execution A-2

10.3 Directive Semantics A-2

10.4 Script Control Syntax A-5

10.5 Directive Examples A-5

10.6 Script Examples A-5

11.

BACKUS-NAUR FORM DEFINITION

A-7

11.1

DEFINITIONS

A-7

12.

NAMING CONVENTIONS

A-8

12.1 Positions A-8

12.2 GA Designations A-8

12.3 MS Designations A-8

13.

SIM DIRECTIVES

A-10

13.1

SV IIA

A-10

13.2

SV IIR

A-17

13.3

SV IIF

A-23

13.4

GA

A-30

13.5

MS

A-32

13.6 Env A-33

13.7

EUA

A-34

13.8 Ex A-34

14.

AEP-MCS DIRECTIVES

A-44

List of Figures

1Figure 1: PTE System Diagram

13Figure 2: PTE Time Manipulation

16Figure 3: PTE SW Component Relationships

18Figure 4: Instructor Control - High Level Structure

19Figure 5: Instructor Control Interfaces

21Figure 6: Scenario Director GUI

22Figure 7: Instructor Player GUI

24Figure 8: Script Player GUI

24Figure 9: Student Monitor GUI

26Figure 10: IIF SV MDV Display

26Figure 11: Attitude and Orbit MDV Display

27Figure 12: Inertial Space View MDV Display

27Figure 13: IIF EPS MDV Display

28Figure 14: Script Composer GUI

29Figure 15: Directive Generator GUI

30Figure 16: IC Database Folder Structure

32Figure 17: Sim Components

43Figure 18: PTE System States

45Figure 19: Training Scenario contents

46Figure 20: Training Scenario relationships

47Figure 21: Detailed Execution Flow

51Figure 22: Ground Simulation OS/Comet interfaces

52Figure 23: Interface between the remote site workstation and the Red VME processor

54Figure 24: Operational interface between the remote site workstation and the MS VME processor

60Figure 25: Excerpt of cmt_gctool.cnf file

62Figure 26: Excerpt from the arts_ports file

65Figure 27: Excerpt from the gams_ports file

67Figure 28: Execution Control

68Figure 29: PTE System Configuration

72Figure 30: Scenario Director Process Overview

76Figure 31: SD Software State Diagram

101Figure 32: Script Player Design Diagram

107Figure 33: Script Player State Transition Diagram

131Figure 34: Student Thin Client console

132Figure 35: Thin client connectivity

132Figure 36: Determine student logged on at which DISPLAY ID

132Figure 37: Call to MCS database for roster information

133Figure 38: Call to start x11vnc servers

134Figure 39: Example x11vnc servers

135Figure 40: Model Data View Component Interaction

136Figure 41: Model Data Viewer - State Transition Diagram

144Figure 42: Script Composer State Diagram

174Figure 43: Sim External Communication

175Figure 44: Simulation Inter-Process Communication

177Figure 45: Sim Master Executive Control Loop

178Figure 46: Simulation Master Executive Units

179Figure 47: Simulation Master Executive Associations

189Figure 48: Model Executive Control Loop

190Figure 49: Model Dispatching

192Figure 50: Simulation Domain Model Exec Units

193Figure 51: Simulation Domain Model Executive Associations

224Figure 52: PTE Database Top Level Structure

238Figure 53: Sample Complete SV 53 Configuration and DB Files

240Figure 54: AEP Main Class Diagram

258Figure 55: AEP Daemon Delete

259Figure 56: AEP Daemon Delta Save

260Figure 57: AEP Daemon Full Save

261Figure 58: AEP Daemon Load

262Figure 59: AEP Daemon Sync

263Figure 60: AEP Delete

264Figure 61: AEP Delta Save

265Figure 62: AEP Full Save

266Figure 63: AEP Load

267Figure 64: AEP Sync

268Figure 65: AEP Pause

269Figure 66: AEP Quit

270Figure 67: AEP Run

271Figure 68: AEP Speed

272Figure 69: AEP Time

273Figure 70: AEP Ack

274Figure 71: AEP Dir

275Figure 72: AEP Log

276Figure 73: AEP KGR

277Figure 74: AEP KI17 Cardholder

278Figure 75: AEP KI17 Pegasus

279Figure 76: AEP KIT

280Figure 77: AEP List

281Figure 78: AEP Memimage

282Figure 79: AEP MS Clockerror

283Figure 80: AEP Sv List

284Figure 81: AEP Ping

285Figure 82: AEP Svdata

286Figure 83: AEP Sync Time

LIST OF TABLES

15Table 1 - Software Components

53Table 2 - Partitioning

238Table 3 - Memory Image Files Required For Initialization

1. Scope

1.1 Identification

This Software Design Document (SDD), SDD-PTE, describes the software design for the Architecture Evolution Plan (AEP) MCS, Instructor Control (IC) and STAR Sim (Sim) components of PTE.

1.2 System Overview

PTE is a tailored combination of the Global Positioning System (GPS) Operational Control System (OCS) Architecture Evolution Program (AEP) Version5.5, and the GPS Satellite Training and Rehearsal (STAR) Simulator (Sim) and Instructor Control (IC), see Figure 1, PTE System Diagram.

Figure 1: PTE System Diagram

PTE Mission

The mission of the PTE is to provide both crew and positional training for the GPS Space Segment and Operational Control System. The PTE supports 50SW/50OSS Unit Qualification Training, Recurring Training, and 50OGV Evaluation of 2SOPS Basic and Advanced Operator positions. In crew mode, the PTE supports training of six crew members. In positional mode, the PTE accommodates up to ten students of the same position type simultaneously. The PTE also provides Instructor/Evaluators the means to create and run various scenarios to accomplish all training task objectives.

1.3 Document Overview

This document is unclassified.

Section 1 - Scope identifies this document, its purpose, a brief system description, and an overview of the contents of this document.

Section 2 - Referenced Documents lists the documents referenced by this document.

Section 3 - PTE Software Design Decisions presents an overview on IC, and an overview of the new features of Sim and AEP for PTE, and decisions affecting how major features would be implemented.

Section 4 - PTE Software Architecture Design gives a general description on all the features and components that make up the PTE as well as scenario diagrams.

Section 5 - Software Item Detailed Design describes the design of each component of PTE.

Section 6 - Requirements Traceability provides the traceability between the software components and necessary internal requirements as governed by the Rapid Prototyping Process.

Section 7 - Notes contains notes and a glossary of acronyms, abbreviations, and definitions used in this document.

Conventions

Sim refers to STAR Sim, IC refers to Instructor Control, and AEP refers to AEP-MCS throughout this document, and are abbreviated to increase readability.

This Software Design document describes the as-built software baseline for the IC, AEP and Sim components of PTE.

2. Referenced Documents

2.1 Government Documents

GV-3222-005

Rev A GV-3222-005 Software Design Description (SDD) Standard Requirements

2.2 Non-Government Documents

Rev G 12/09/2004 Software Development Plan (SDP) for the Global Positioning System Block IIF

Rev B 08/18/2005 Software Requirements Specification for the System Simulator (SIM) of the GPS Block IIF Rel 2

Rev A 7/3/2007 Software Requirements Specification for the System Simulator CSCI of the Global Positioning System Block IIF-Rel 3

Rev NEW 1/21/2009 Software Design Document for the System Simulator CSCI of the Global Positioning System Block IIF-Rel 3

Rev NEW 11/16/2007 Software User's Manual for the System Simulator CSCI of the Global Positioning System Block IIF- Rel 3

Rev B 04/02/2003 Software Design Description for the Satellite Control Processor (SCP) CSCI of the Global Positioning System Block IIF

Rev A 05/01/2007 Software Design Description for the Navigation Data Unit (NDU) CSCI of the Global Positioning System Block IIF

Release 3 Rev New 7 July 2005 NAVSTAR Global Positioning System (GPS) System Specification for the System Simulator (SIM) Element of the GPS Control Segment

Rev D 02 February 2009 Software Requirements Specification for the Telemetry, Tracking, and Command CSCI of the Global Positioning System Block IIF – V5.5

Rev NEW 10/10/2006 Software Design Description for the System Simulator CSCI of the Global Positioning System Block IIF Rel 2

Rev D 7/19/2010 Software Requirements Specification for the Positional Training Emulator of the Global Positioning System Block IIF

Rev NEW 01/13/2009 Interface Design Document for the Positional Training Emulator of the Global Positioning System Block IIF

Rev C 3/11/2010 Software Version Description for the Positional Training Emulator of the Global Positioning System Block IIF

Rev B 11/17/2006 Software Design Document for the LADO Simulation CSCI of the Global Positioning System Block IIF - Rel 1

Rev A 13 February 2009 Software Design Document for the Telemetry, Tracking and Command CSCI of the Global Positioning System Block IIF-V5.5 Appendix F Ground Antenna & Monitor Station Host VME Interface Control Document (ICD)

3. PTE Software Design Decisions

The following sections discuss the decisions made in designing PTE. Section 3.1 refers to system wide design decisions. Section 3.2 refers to IC; Section 3.3 refers to Sim; and Section 3.4 references AEP.

3.1 System

The PTE System control is provided by a GUI designed specifically for the use of an instructor to orchestrate training sessions. This section contains information on Reuse, the Single Universe, Time Source, Security, and Virtual Network Computing.

Reuse

The PTE system reuses the AEP operational software and proven IIF STAR Sim/GSS models to provide the realistic behavior required for effective training. The PTE AEP is augmented to use simulation time and to support training features such as load, pause, fast-forward, and save. The original Sim master executive is adapted to interface with the new Instructor Control user interface. The adaptation uses a new communication architecture that provides for communication between the simulation executive and user interface, between the simulation executive and models, and between models.

Single Universe

Because the operational AEP supports a single GPS universe (one Kalman filter, one Master Schedule), and because of the need for a PTE system to be deployed as soon as possible, the decision was made to preserve the single universe concept. For details refer to PTE Key Decision Worksheets, PTE-KDW-09 and PTE-KDW-020.

Time Source

To support coordinated non-real time capabilities such as pause and fast-forward, the simulation maintains and communicates the system time and delivers it to IC and AEP. The IC and AEP components are expected to sync their time to the simulation time.

Security

PTE is designed for, and implemented in, a closed network environment, with no external connectivity to any other network or system. All instructors and students granted access to the PTE systems hold security clearances and are authorized to use the systems through unique logon accounts and passwords.

The communication security features for the legacy systems, Sim and AEP, have been “grandfathered in” and will continue to use TCP/IP and remote shell (rsh) unsecured. Instructor Control is newly developed, has a higher security requirement, and uses secure shell (ssh) for remote shell commands and will port forward TCP/IP messages through ssh tunnels.

The instructors for the PTE system logon through the PTE Instructor Control PC (IC PC) and validate their accounts through Windows XP Professional. From there, the instructor starts the PTE Instructor Control application and enters a passphrase from the main application window. This will validate the instructor position via secure shell (ssh) using a private/public key transaction through a previously defined secure tunnel with the PTE Sun/Solaris server. Once validated, the passphrase will be stored in memory only for future transactions during this session.

When needed, Instructor Control will access a windows command-line interface to initiate a ssh command to the Sun/Solaris server to stop the Sim, start the Sim, and/or retrieve scenario information from the Sim.

The passphrase stored in memory is used to decrypt a private key, stored within the instructors Windows environment, which is used to encrypt a randomly generated session key. The PC initiates a secure tunnel with the Sun/Solaris server. The server then authenticates the transaction with authorized public keys available to it and establishes the tunnel. This session key is used to secure the tunnel communications.

At no time is a password or User ID to be transmitted in the clear to/from PC/Windows client and Sun/Solaris server, and all transactions will be validated and encrypted.

Other TCP/IP communications (i.e. Sim/AEP control and logging channels, MDV channels, TV channels, and Student Monitoring data) will also be port forwarded through the established ssh tunnel.

Students can log on to the AEP system from thin client terminals and be verified through SERV shell protocols and be assigned an AEP role. This role (PSO, SSO, SVO, etc.) limits access and permissions to AEP functionality. At no time will students have access to the IC PC or Sim servers.

Student Monitoring

Instructor monitoring of student actions on their Consolidated Operators Support Environment (COSE) workstations is required from the Instructor Control PC. This ability was accomplished through the use of Virtual Network Computing (VNC).

Virtual Network Computing

Student Monitoring is necessary to visually monitor the student’s actions on their AEP COSE displays. The technology chosen for student monitoring early in PTE design was VNC. Other options, such as hardware switching and remote management applications, were researched and determined to be lacking, either in security, capability, or both.

VNC has several advantages over available hardware solutions -- such as no additional equipment (i.e. 20 channel video A/B switch), no additional cabling or power requirements, and no changes to classroom layout and associated documentation or drawings.

Of the multiple VNC software options available, two were found to be capable of supporting PTE’s need for the capability to view workstations from a Sun/Solaris 8 operating system, through Sun Ray thin client architecture, to a Windows XP operating system. There were:

RealVNC (commercially available through a Boeing approved software distributor) x11vnc (open source software, available from the Sun supported Remote Control Toolkit.)

Extensive experiments with RealVNC exposed severe CPU utilization problems on the Sun/Solaris server side, while x11vnc had very low CPU needs. Since x11vnc has no Windows XP support, RealVNC was our choice for the client software while x11vnc is used for the server software.

3.2 Instructor Control

The PTE user interface is provided by a new component called Instructor Control(IC). IC provides the user with displays and functions specific to controlling the operation of the system: loading training scenarios, starting and pausing execution control, speed control, and State Saves. Communication with the Sim and AEP is accomplished through directives that can be scripted or generated on demand. Scripts can be created off-line and executed prior to being used during an actual training session.

Instructor Control is designed to allow operation of the simulation without AEP in the loop. The software can be switched to use stubs for either or both Sim and AEP which allows flexibility in testing. The interface allows Sim and AEP activity logs to be monitored.

User Interface

The user interface of PTE is designed to provide an instructor the ability to control the combination of Sim and AEP for the purpose of delivering training. Instructor Control provides execution control of PTE. This includes the ability to start and end the execution of PTE, to select scenario data, to configure Sim and AEP, the ability to run and to pause the advancement of simulation time, and the ability to set the speed of advancement of simulation time (fast forward). PTE can Save/Restore its execution state, and IC provides the control for these actions.

Instructor Control also provides the means to issue directives to Sim and AEP that control behavior and perform operations. For instance, directives can be sent to Sim to simulate anomalous behavior of GPS satellites. Directives can be sent to AEP to perform operations such as scheduling contacts or creating reference trajectories. These AEP operations are called ghost operations because they would normally be performed by crew members, but for training purposes they are initiated via IC. Instructor Control provides the means to issue these directives from predefined scripts, or to select and issue directives during execution.

Instructor Control also provides information for conducting training and to monitor execution behavior by displaying control status and logging responses from Sim and AEP. Displays are provided by IC to view the behavior of Sim models. IC provides the ability to monitor student performance by allowing the instructor to view the displays of selected student workstations.

Instructor Control provides tools to support the use of PTE. A tool is provided that permits the composition of scripts or directives; another tool is provided to manage scenario data.

Training Scenario

The term training scenario refers to the data to be used by IC, Sim, and AEP in running a training session. The training scenario data for IC includes identification of the data sets to be used by Sim and AEP for the training session, and can include scripts to be used for the training session. PTE can only be loaded with one training scenario at a time.

Ghost Operations

For conducting positional training it may be necessary for the instructor to perform certain AEP operations that would normally be performed by other positions of a crew than the positions being trained. These operations are called ghost operations. Instructor Control provides the capability to initiate the execution of certain AEP Perform Files via directive. At times it may be necessary to execute other Perform Files and respond to Perform File prompts in order to conduct positional training. For these cases the instructor is provided with a COSE workstation in order to perform these operations. See Key Decision Worksheet, PTE-KDW-017 (Ghost Operations).

Script Players

Instructor Control provides the means to individually control the training of up to ten students at a time. This is done by providing ten Script Players. Each Script Player can be configured to execute scripts for a designated Crew Position, Space Vehicle, Ground Antenna site, and Monitor Station site. Scripts can be composed with parameterization for Crew Position, Space Vehicle, Ground Antenna site, and Monitor Station site. When these scripts are executed the Script Player fills in the values for these parameters. Each Script Player also collects and displays the log messages associated with directives having the designated parameter values. This allows the training of individual students to proceed independently of the progress of other students. Each Script Player also allows the instructor to select and send directives during a training session that are targeted for the resources the student is controlling.

Unconditional Script Execution

A decision was made to only support unconditional script execution. There is no provision to conditionally execute directives in a script: no conditional waiting, branching, or looping. Directives in scripts are automatically executed in sequence. However, it is possible for the Instructor to manually jump to any directive in a script and resume execution from that point. See Key Decision Worksheet, PTE-KDW-014 (Defer Conditional Script Execution).

Model Data Viewer(MDV) The GPS System Simulator provided a capability to view data directly from the simulator models. This feature was called Live Model Display. Instructor Control provides a similar capability to view data directly from Sim models. This capability is provided in Instructor Control by components called Model Data Viewers. The legacy Live Model Display feature presented model data in a table format. Model Data Viewers present data using the graphic visualization features of LabVIEW.

3.3 Sim

The Sim models GPS space and ground assets: the space assets are the block IIA, IIR, IIRM, and IIF satellites; the ground assets include GA’s, MS’s, Automated Remote Tracking Station (ARTS), and National Geospatial-Intelligence Agency Model (NGA). Environmental effects on the space and ground model behavior are provided by the Environment simulation which includes Sun, Moon, Earth, and atmospheric effect models.

Infrastructure Overhaul

The GSS legacy infrastructure providing external interface functionality and model dispatching is replaced with new executive control and communication software designed to interface with the new PTE Instructor Control user interface. Simulations from the IIF STAR Sim and GSS are adapted to operate within the new simulation infrastructure.

Model Dispatching

To enhance repeatability, the GSS legacy non-deterministic, model-as-task dispatching scheme was replaced with a pre-determined, fixed sequence method.

Flat File Database

The legacy Simulator database was a combination of Oracle RDBMS and UNIX flat-files. All data items contained in the PTE Database are independent, non-relational system parameters and this data characteristic makes the use of a relational database unnecessary.

The PTE simulation databases are organized by ground and vehicle systems. This data organization is facilitated by a UNIX directory structure corresponding to each of the various sub-systems and by vehicle block types. Within each UNIX system directory are multiple ASCII text files containing numerous parameter values.

The file naming convention makes locating data simple by using a pre-defined system mnemonic (EPS, NAV, RCS, TCS, etc) as part of the file name.

A typical file also has an internal contents convention (comma delimited) containing the following:

a) A simulation parameter value

b) A label for the parameter

c) A default parameter value

d) The data type (i.e., an integer, floating point number, boolean, or string)

e) Units of measurement

f) The minimum allowable range value

g) The maximum allowable range value

3.4 AEP

The AEP software is augmented to use simulation time and accept directives to support required training features such as pause, fast-forward, and ghosting actions. The AEP augmentation is designed to be transparent to the AEP user with the exception being the GA, MS and ARTS displays that identify replicated sites used for positional training.

Master Control System (MCS) Time Manipulation

A Time Manipulation technique for the MCS component of PTE was developed to enable instructors the ability to control training scenario sequencing from the Instructor Control component.

The following MCS Time Manipulation capabilities were needed to provide instructor-control of the timing of scenario execution:

· Scenario Pause

· Scenario Resume

· Scenario Slow/Fast Forward (0.5x, 2x, 3x, 5x, 10x)

· Scenario Time Jump to pre-defined checkpoints

· Time jump needs to be integrated with DB/file restore functionality The ability to jump back or ahead to a previously defined check point is provided in conjunction with the database Save/Restore capability. PTE takes advantage of the encapsulation of time and timers in the services layer of the AEP Services CSCI to establish a PTE MCS simulated time. The time manipulation function keeps track of a simulation time offset and broadcasts that time to all servers. System time remains unchanged and continues to be synchronized via NTP. The PTE MCS maintains synchronization of PTE MCS simulated time with the simulated time provided by the Sim within a tolerance of 500 ms. Other features that manipulate simulated time are pause, speed, and run.

PTE time manipulation is illustrated in Figure 2.

Figure 2: PTE Time Manipulation

AEP - MCS State Save and Restore

The MCS component of PTE needs to provide a State Save/Restore capability to enable the creation of multiple checkpoints by the PTE instructor and the restart of the PTE from the designated checkpoints for training purposes.

All databases are Saved/Restored by the instructor for:

· Call-up of pre-defined training scenarios/checkpoints

· Training scenario repeatability The following MCS State Save/Restore capabilities are required:

· Save/Restore Oracle database files

· Save/Restore non-Oracle data files

· Perform application re-start

· Accomplish Save or restore within design goal of ~ 15 min The decision was to adopt the streamlined Oracle and non-Oracle restore functions because of significant speed up of Save/Restore function compared to repeatability.

The two Save/Restore capabilities provided are:

· Full Save/Restore to create checkpoint or initialize training session

· Delta Save/Restore for use during a scenario to create quick Save points, these are temporary Saves that only persist during scenario execution.

While Full and Delta Saves/Restores are supported, the underlying techniques are identical; however, the load times for full and delta Saves/Restores still need continual analysis.

4. PTE Software Architecture Design

The following sections describe the components that make up the PTE Architecture. Section 4.1.2 refers to the Instructor Control (IC) component; Section 4.1.3 the STAR Sim (Sim) component; Section 4.1.4 refers to the AEP-MCS component.

4.1 Software Components

Table 1 lists the PTE software components, their purpose and development type.

Table 1 - Software Components

PTE Software Component Relationships

The relationships between the PTE software components and with external data providers are illustrated in Figure 3. Each of the component databases is an independent entity that can contain comparable data originating from a common source such as the SV factory.

Figure 3: PTE SW Component Relationships

Instructor Control Component The Instructor Control component provides the interface and control mechanisms for conducting training using PTE. The Instructor Control programs run on the Instructor Control PC and are implemented using LabVIEW. Instructor Control consists of two main programs, the Scenario Director and the Script Composer described below.

1. Scenario Director: The program for starting Sim and AEP, loading training scenarios, controlling execution, executing scripts of directives for Sim and AEP, manually executing directives, and logging messages from AEP and MCS. Scenario Director uses three other programs:

· Script Player: Programs for loading and configuring scripts, controlling the execution of scripts, and displaying log messages associated with scripts. The Scenario Director can operate up to ten Script Players for students, as well as an additional script player for the Instructor. The Script Player also uses the Directive Generator (see below).

· Model Data Viewer: Programs for displaying data from Sim models (Space Vehicles, Ground Antennas, and Monitor Stations).

· Student Monitor: Program to monitor selected student COSE displays.

2. Script Composer: The program for composing scripts of directives for Sim and AEP.

· The Script Composer and the Script Player (above) both use a program called the Directive Generator. The Directive Generator is a tool for selecting and configuring directives to be sent to Sim and AEP MCS to control their behavior.

The high level structure of these programs is shown in Figure 4.

Figure 4: Instructor Control - High Level Structure

Instructor Control provides a graphical user interface for the instructor. IC has an interface with Sim and AEP which is used to send control requests and directives, and receive responses and log messages. A database consisting of text files is accessed by IC on the PC. IC drives the classroom clock with the simulation time. The IC/PC can monitor student COSE displays, and can be shown on the overhead projector in the classroom. These interfaces are shown in Figure 5: Instructor Control Interfaces .

Figure 5: Instructor Control Interfaces

4.1.1.1 IC Scenario Director

Scenario Director is the main GUI for Instructor Control (see Figure 6 Scenario Director GUI.) It facilitates the selection of an existing scenario, starting of Sim/MCS using that scenario, and controls the pace of the training run. Scenario Director also indicates whether or not each site in the scenario has completed startup, manages the Script Player windows, initiates the use of Model Data Viewers and is used to start Student Monitoring.

OAC Connect Tab

Figure 6: Scenario Director GUI

4.1.1.1.1 Script Player

The Script Players are intended to load and control scripts of Sim and MCS directives to moderate the flow of the training scenario. These scripts are created by the Script Composer (see Section 4.1.2.4 ) and can be loaded, run through, paused, stepped through one directive at a time, or abandoned to load another script.

Each Script Player has the ability to call a Directive Generator (see Section 4.1.2.5) to generate and send a directive, outside of a script.

The Script players log a sub-set of the information which is logged on the Scenario Director main window. The log entries are filtered by the parameters selected on the Script Player. Logs can be cleared, saved, and printed.

Instructor Player

The Scenario Director window (see Figure 7: Instructor Player GUI) contains an Instructor Player in the lower half of the window. This Instructor (Script) player is intended to run scripts whose directives apply scenario-wide, and therefore do not need to be run repeatedly (otherwise, for regular Script Players, up to ten times, once for each Script Player). The Instructor player does not have parameters, as its scripts will not apply directly to a specific position, SV, GA, or MS; otherwise it is exactly like a numbered Script Player.

The Directive Generator called from the Instructor Player is constrained to only the options selected which are to be used in the scenario, loaded and running on Scenario Director.

The Instructor Player does not have a log of its own, as it has no parameters to filter the log messages.

Figure 7: Instructor Player GUI

Script Player – Numbered (1-10) Each numbered Script Player (Script Player 1-10) has a set of parameters that can be selected to affect the contents of the script (see Figure 8: Script Player GUI). Scripts are generated with generic placeholder parameters which are replaced by the parameters selected on the Script Player window. This creates the ability to write just one script which can be applied to up to ten different situations (i.e., student specific situations).

The Directive Generator, called from a numbered Script Player, is constrained to the models that are selected in the parameters for the Script Player.

Figure 8: Script Player GUI

4.1.1.2 Student Monitor

The Scenario Director GUI is used to open the Student Monitor Application (see Figure 9, Student Monitor GUI). Student Monitor serves two purposes. First, it lists student roster information, and second, it monitors the contents of a student’s display. The roster information, logon and MCS role, are listed under each set of COSE display icons. To view the contents of a selected COSE display, the instructor just clicks the icon with the mouse, drags it up to the Instructor Display icon, and a new window opens on the IC PC with that display shown.

Figure 9: Student Monitor GUI

4.1.1.3 Model Data Viewer

Model Data Viewers (MDVs) are components of IC that display selected model data from Sim. There are MDVs for five classes of Sim models:

MDV IIA – for viewing data from IIA Space Vehicle models

MDV IIR – for viewing data from IIR Space Vehicle models

MDV IIF – for viewing data from IIF Space Vehicle models

MDV GA – for viewing data from Ground Antenna models

MDV MS – for viewing data from Monitor Station models

MDVs provide a similar capability as is provided by the Live Model Display of the GPS System Simulator.

MDVs are started from the Scenario Director. An MDV requests that Sim open a TCP/IP channel for the transmission of data for a specific instance of a model class: for instance, a specific IIF Space Vehicle, or a specific Ground Antenna site. The MDV then permits the user to select particular sets of model data called MDV Data Sets: for instance, data for the Electric Power System of an IIF Space Vehicle. After being requested, the MDV Data Sets are periodically sent to an MDV. The following screen shots (Figures 10 – 13), show examples of MDV displays to illustrate MDV functionality.

The structure of the five kinds of MDVs is the same. The MDVs for Space Vehicles (blocks IIA, IIR, and IIF) present a common display for orbit and attitude state vectors.

Figure 10: IIF SV MDV Display

Figure 11: Attitude and Orbit MDV Display

Figure 12: Inertial Space View MDV Display

Figure 13: IIF EPS MDV Display

4.1.1.4 Script Composer

The Script Composer is a stand-alone application that is used to create and edit scripts (see Figure 14: Script Composer GUI). These scripts are stored in the Script Collection; see the IC Database Description, section 4.1.1.9. The content of a script is constrained by the script language definition and a pre-defined set of directives; refer to Appendix A of this document, the Script Language Description. The Script Composer allows the adding of directives, control statements, and comments; editing of lines already in the script; and re-ordering of lines within the script. Adding directives is accomplished using the Directive Generator.

Figure 14: Script Composer GUI

4.1.1.5 Directive Generator

The Directive Generator (see Figure 15: Directive Generator GUI ), is another application that reads directive configuration files, and presents a series of ordered lists of directives to the user. When the user selects a directive, input fields for appropriate arguments to the directive will be presented. When a directive in the script is selected for edit, Directive Generator will then display the directive as already selected, with the appropriate arguments pre-populated.

Figure 15: Directive Generator GUI

4.1.1.6 PTE System Supervisor

The PTE System Supervisor (PSS) is used to connect to simeng and mission1 servers to view startup and shutdown status of the various PTE scenarios. Additionally, PSS allows the instructor to bring the AEP servers up and down (from run level 3 to 4 and back.)

4.1.1.7 IC Database Description

Instructor Control uses a database of folders and files on the IC PC. The structure of this database is shown in the following figure.

Figure 16: IC Database Folder Structure The parts of this database are defined as follows:

The PTE.ini file specifies parameters that configure IC component applications and point to associated resources.

The Scenario Collection folder contains a sub-folder for each scenario that is run by the Scenario Director. A scenario folder contains a Scenario Descriptor file that identifies the Sim and AEP initial condition data for the scenario, and identifies the Scripts for the scenario.

The Script Collection folder contains Script files that list directives to be executed by Script Players.

The Instructor Control Private folder contains files that specify directives that can be included in Scripts and sent by Script Players to Sim and AEP.

The Logs folder contains log files generated by the Scenario Director.

The Help Files folder contains html files that provide user help documentation for Instructor Control components.

A Scenario directory is created for each saved scenario. A standard naming convention will be used for scenario directory names. Scenario directory names will be unique.

Sim Component

The Sim component and its external connections are depicted in Figure 17: Sim Components. The Sim models the GPS Block IIA/IIR/IIR-M/IIF satellites, ground sites, and the physical environment in which the satellites operate. Real and imaginary constellations are supported to meet the needs of both crew and positional training for on-orbit operations. While not needed for the PTE mission, the IIF satellite model includes support for Launch and Early Orbit (LEO) and disposal. Sim application control is driven by the IC user interface. Sim satellites and ground equipment are managed by COSE operators. Sim is a software simulation that does not require hardware in the loop.

Figure 17: Sim Components Sim Executive

The Sim Executive executes as a single process and is responsible for overall Sim control. Control requests and directives from Instructor Control (IC) can be passed to the Space, Environment, and Ground simulations. IC expects the simulations to acknowledge all control requests. The executive passes the current simulation time to IC and AEP once per second. User visibility into internal simulation activity is provided by log messages sent to IC. The operator using IC selects directives to control which logs to keep.

4.1.1.7.1 Sim Executive Activation

Instructor Control activates the executive by issuing a remote shell or secure shell invocation. The invocation consists of the executable name “sim_exec” followed by a base port (channel) number. The executive stays active until it receives a Control Request to quit.

4.1.1.7.2 Sim Executive Comm Channels

On activation, the executive establishes the Control and Log channels used for communicating with IC. The executive then connects to the channel established by AEP that is used for delivering simulation time. After the simulation models are activated, the executive connects to their Control Channels.

4.1.1.8 TRICS

The Tools, Reuse, Infrastructure, Channel Services (TRICS) component is a collection of software units used by all components. Tools provided include a model data viewer generalization, logger, hex converter, bit and byte manipulation utilities, string utilities, and date/time utilities. The Reuse units include a subset of the Booch software components. The Infrastructure collection includes a clock class, environment variables interface, directive and directive registry classes, and abstractions for messenger, event handler, and model objects. Channel Services is made up of a Comm Center class that consists of client, server, receiver, and transmitter classes.

4.1.1.9 Space Sim

The Space Sim component provides multiple space vehicle (SV) simulation. The number of SV’s included in a simulation session is determined by the Scenario selected by the operator at startup. Each simulated SV executes as a single process. SV processes communicate with other components using TCP/IP. Communication within an SV process is by direct call.

4.1.1.9.1 SV Models

Each SV process contains an Orbit model along with SV component models pertinent to the SV block type. The IIA/IIR/IIR-M SV component models inherited from GSS are conjoined. Conditional branching is used to determine which path to take depending on the block type of the SV instance. All IIF SV component models are specific to IIF. The following components are modeled:

· Attitude (ATT)

· Crosslink Transponder Component (CTS)IIF

· Electrical Power Component (EPS)

· L-Band Component (LBS)

· Navigation Component (NAV)

· Nuclear Detonation Detection Component (NDS)

· Orbit Component (Orbit)

· Reaction Control Component (RCS)

· Satellite Control Processor (SCP) IIF

· Satellite Processor Unit (SPU)IIR

· Thermal Control Component (TCS)

· Telemetry, Tracking and Control (TTC)

4.1.1.9.2 Flight Software Use

The IIF SCP CSCI and NDUC CSCI source code is wrapped into the SCP and NAV models. The wrapping allows the software to communicate with the hardware models through…