mg50539000013e5_new.doc

For Official Use Only

CAGE CODE

2D605

NUMBER

MG50539000013E5

REV

NEW

DATE

13 Jan 2009

PAGE

ii

This page intentionally left blank.

DOCUMENT REVISION HISTORY

Revision

Date

Required Change

Sections Affected

CONTENTS

Paragraph Page

Scope

11.1 Identification

11.2 System Overview

11.2.1 PTE Mission

11.3 Document Overview

11.3.1 Conventions:

Referenced Documents

Interface Design

33.1 Interface Identification and Diagrams

43.1.1 Message Descriptions

43.2 Instructor Control / AEP MCS Interface Description

43.2.1 Channel Communications

53.2.2 Control Messages

73.2.3 Directive Messages

83.2.4 Time Messages

83.2.5 Log Messages

93.2.6 Data Management Messages

113.3 Instructor Control / Sim Interface Description

113.3.1

113.3.2 Control Messages

143.3.3 Directive Messages

143.3.4 Time Messages

153.3.5 Log Messages

153.3.6 Data Management Messages

173.3.7 Interface for Model Data Viewers

183.4 AEP MCS / Sim Interface Description

183.4.1

193.4.2 Time Message

193.4.3 Data Request Messages

Requirement Traceability

Acronyms and Abbreviations

3110 Appendix A Model data sets.

LIST OF TABLES

Paragraph Page

4Table 1 - SV Data Message Parameters

4Table 2 - KIT123 Configuration Message Parameters

4Table 3 - KGR28 Configuration Message Parameters

4Table 4 - KI-17 Cardholder Configuration Message Parameters

4Table 5 - KI-17 Pegasus Configuration Message Parameters

4Table 6 - Memory Image Message File Information

4Table 7 - MS Clock Error Message Formats

4Table 8 - MS Clock Error Message Parameters

LIST OF FIGURES

4Figure 1 - PTE Interface Design Overview

4Figure 2 – Component Interface Channels

1 Scope

1.1 Identification

This Interface Design document (IDD-PTE), establishes the design of the interfaces for three major components of PTE: Instructor Control (IC), Satellite Training and Rehearsal Simulator (STAR Sim), and Architecture Evolution Plan (AEP) Master Control Station (MCS). A complete identification of all the interfacing entities to which this IDD applies is provided in Figure 1.

1.2 System Overview

1.2.1 PTE Mission

The Positional Training Emulator (PTE) is an operationally realistic, closed-loop training emulator for 50th Operational Support Squadron (OSS) position training through the tailored combination of Architecture Evolution Plan/Master Control Station (AEP-MCS) and the Sim version of the GPS System Simulator. The Air Force 50th Space Wing has tasked Boeing to deliver the PTE in a classified software/hardware configuration that retains the realistic, closed-loop training capabilities inherent in the AEP/Sim combination but adds capabilities specific to positional training and instructor controls.

1.3 Document Overview

Section 1: Scope, provides an identification and description and outlines the purpose and content of this document.

Section 2: Referenced Documents, lists documents referenced in this document.

Section 3: Interface Design, presents an overview on AEP of PTE and decisions affecting how major features would be implemented.

Section 3.1: Instructor Control / AEP-MCS Interface Description, presents the AEP to IC Interface.

Section 3.2: Instructor Control / Sim Interface Description, presents the Sim to IC Interface.

Section 3.3: AEP-MCS and Sim Interface Description, presents the Sim to AEP Interface.

Section 4: Requirement Traceability, establishes requirements traceability from each interface to the system requirements addressed by the interface design.

Section 5: Acronyms and Definitions, contains notes and a glossary of acronyms, abbreviations, and definitions for PTE.

1.3.1 Conventions:

SIM refers to STAR Sim, IC refers to Instructor Control, and AEP refers to AEP-MCS throughout this document and is abbreviated to increase readability. Message descriptions keywords are indicated in bold and variable names are indicated by italics. This interface design document provides the interface design baseline for the IC, AEP and Sim components of PTE. This document is unclassified.

2 Referenced Documents The following documents of the exact issues shown are referenced in this specification. The intent of these referenced specifications and standards is to augment the best commercial practices with those practices that improve product and process quality.

SS-SIM-614 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

MG50533001033E2 Release 3 Rev New 13 January 2006 Software Requirements Specification for the System Simulator of the GPS Control Segment

MG50532004023E2

Rev G 26 Nov 2007 Software Requirements Specification for the Telemetry, Tracking, and Command CSCI of the Global Positioning System Block IIF – V5.2

3 Interface Design PTE is a tailored combination of the Global Positioning System (GPS) Operational Control System (OCS) Architecture Evolution Program (AEP) Master Control Station (MCS), the GPS Satellite Training and Rehearsal (STAR) Simulator (SIM), and Instructor Control (IC).

3.1 Interface Identification and Diagrams

Detailed information for each specific interface is described in the subsequent sections. Figure 1 shows the interfaces between the three major components of PTE. Figure 2 shows interface channel details.

Figure 1 - PTE Interface Design Overview

Figure 2 – Component Interface Channels

3.1.1 Message Descriptions

All messages adhere to these common conventions:

(1) Messages are ASCII character strings

(2) Messages are terminated by a Carriage Return (CR) and Line Feed (LF).

(3) Interpretation of message characters is case insensitive. The exception to this is for text enclosed within parentheses for parameter specification where the distinction of case is preserved.

(4) Parts of a message are delimited by a single space

3.2 Instructor Control / AEP MCS Interface Description

This section describes the interface between Instructor Control (IC) and the Architecture Evolution Plan (AEP) Master Control Station (MCS). This interface permits IC to control the operation of AEP and to send AEP directives. AEP sends simulation time messages and log messages to IC. All messages are composed of ASCII text.

AEP will be left running at run level 4 (AEP is up and running). Communications between IC and AEP is accomplished using TCP/IP.

3.2.1 Channel Communications

There are two TCP/IP channels: the Control Channel and the Log Channel. AEP is the server for these channels and IC is the client. The port number for each channel is assigned as an offset from a base number:

Control Channel port number offset = 3 Log Channel port number offset = 4 The Control Channel is bi-directional and carries four kinds of messages:

(1) Control Messages

(2) Directive Messages

(3) Time Messages

(4) Data Management Messages

Control Messages permit IC to request operational actions from AEP such as Load, Save, Pause and Run. Control Messages include the response from AEP for these requests. Directive Messages are sent from IC to AEP to invoke the execution of Perform Files, and include the response from AEP when a perform file completes execution. Time messages are sent from AEP to IC to enable the IC to monitor synchronization with SIM. Data Management Messages handle the management of initial condition data.

The Log Channel is uni-directional and carries Log Messages from AEP to IC.

3.2.2 Control Messages

Control Messages are used by IC to control AEP operation. A control request is sent from IC to AEP, and a response is expected back from AEP to IC. The control request from IC starts with the term “con”. The control response from AEP starts with “con”. Each control action is completed before another is initiated.

3.2.2.1 Ping Control

Check the communication between IC and AEP.

control request = “con ping”

AEP responds with:

control response = “con pong”

Ping Control only occurs during startup. In the future Ping Control may be used periodically during operation to check communication.

3.2.2.2 Load Control

Load Control causes AEP to load an initial condition set with the given name. AEP and IC will be in the paused state upon completion of the load operation.

control request = “con load initial_condition_name”

There are two kinds of initial conditions: full_save and delta_save. In relation to AEP, a full_save initial condition contains a complete set of state data, and a delta_save initial condition primarily contains a set of state data differences. A delta_save can only be loaded after a full_save is in use.

For a delta_save_name, the term “.delta_#” is appended to the original full_save_name, where # indicates the sequence number of the delta save made with the full_save. All delta_saves will be deleted upon loading a full_save or quitting IC. Loading a delta_save will result in all future delta_saves that were taken at a later time being deleted.

If the load is successful, AEP will respond with:

control response = “con load_done sim_time” sim_time specifies the start time of the initial conditions. The form of sim_time is given in the Time Message description.

If the load fails, AEP responds with:

control response = “con load_failed”

3.2.2.3 Run Control

Run Control requests AEP to start processing with an advancing simulation time:

control request = “con run”

AEP responds with:

control response = “con running”

3.2.2.4 Pause Control

Pause Control causes AEP to pause the scenario: suspend processing at the given simulation time.

control request = “con pause sim_time” sim_time specifies the time at which the pause will become effective. The form of sim_time is given in the Time Message description. The time for the pause will be the current simulation time plus an interval estimated to account for the process of pausing.

AEP responds with:

control response = “con paused”

3.2.2.5 Speed Control

Speed Control causes AEP to change the rate at which it advances simulation time. The speed is the ratio of the passage of simulation time to real time. Note: Pause control must be done before speed control.

control request = “con speed ##.#”

AEP responds with:

control response = “con speed_changed”

AEP and IC are in the paused state after the speed is changed.

3.2.2.6 Full Save Control

Full Save Control causes AEP to perform a full save. Note: Pause control must be done before full save control.

control request = “con full_save full_save_name”

Full_save_name specifies the name to be given to the full set of saved state data. This saved data also constitutes an initial condition with the same name.

If the save is successful, AEP will respond with:

control response = “con save_done”

AEP and IC are in the paused state after the save is completed.

If the save fails, AEP will respond with:

control response = “con save_failed”

3.2.2.7 Delta Save Control

Delta Save Control causes AEP to perform a delta save. Note: Pause control must be done before delta save control.

control request = “con delta_save delta_save_name”

Delta_save_name specifies the name to be given to the set of saved state data. For a delta_save_name, the term “.delta_#” is appended to the original full_save_name, where # indicates the sequence number of the delta save made with the full_save. This saved data also constitutes an initial condition with the same name.

If the save is successful, AEP will respond with:

control response = “con save_done”

AEP and IC are in the paused state after the save is completed.

If the save fails, AEP will respond with:

control response = “con save_failed”

3.2.2.8 Quit Control

Quit Control causes the AEP to halt the scenario and delete any delta_save data that was created for this scenario.

control request = “con quit”

AEP does not send a response to this request.

3.2.3 Directive Messages

Directive messages are sent from IC to AEP. AEP directives are used to invoke the execution of Perform Files. The directive message begins with the term “dir”.

directive request = “dir source_tag position_tag mcs_action”

The source_tag identifies the particular Script Player that sends the directive request. AEP must include the source_tag in the directive response so that the response can be routed to the Script Player that issued the directive. The position_tag identifies the AEP operator position that is to be associated with log messages related to the execution of the Perform File invoked by the directive. The mcs_action designates the Perform File to be executed by AEP, and provides parameter values. The syntax for position_tag and mcs_action are defined in the Software Design Document for the Positional Training Emulator of the Global Positioning System Block, Appendix A - PTE Script Language Description (MG50539000013E5). The directive response begins with “dir”.

When AEP successfully completes a directive it responds with:

directive response = “dir done source_tag” where source_tag is the same as that given in the directive request.

If the directive cannot be completed successfully, then AEP responds with:

directive response = “dir failed source_tag”

In addition to indicating the failure in the directive response, AEP sends a log message, with alarm status, identifying the failure.

3.2.4 Time Messages

A Time Message provides a time stamp that is sent from AEP to IC so that IC can monitor AEP time synchronization. Time Messages are only sent by AEP when the mode is “running,” that is, when simulation time is being advanced. AEP sends a Time Message once per simulation second.

time message = “time sim_time” sim_time specifies the simulation date and time. The format is:

“YYYY/DDD/HH:MM:SS.SSSS”.

3.2.5 Log Messages

Log messages are sent from AEP to IC to provide the instructor with appropriate feedback on student actions and AEP processing.

log message = “position_tag status sim_time text”

The position_tag identifies the AEP operator position which should associated with the log message, and is used by IC to route the log message to the Script Player handling the position. The syntax for position_tag is defined in the Software Design Document for the Positional Training Emulator of the Global Positioning System Block, Appendix A - PTE Script Language Description (MG50539000013E5). Status indicates the appropriate attention the log message is to be given.

Status = “A” or “W” or “E” or “I”

A = alarm

W = warning

E = event

I = information sim_time is used to simulation time stamp the log message using the format given in the Time Message section.

Text contains the text of the Log Message.

3.2.6 Data Management Messages

Data Management messages handle the management of initial condition data in AEP/MCS terms known as Check Points. These messages are passed on the Control Channel. It can be assumed that a training session will not be in progress when these messages are used. These messages start with the term “dat”. These messages are used to realize three operations: “List”, “Sync”, and “Delete.” In order to use these messages, communications must be established between IC and AEP using the “con ping” and “con pong” protocol mentioned above. Communications are terminated when IC sends a “con quit”.

3.2.6.1 List Operation

The List operation provides IC with a list of Check Points available to AEP. IC first sends the request:

request = “dat list”

AEP responds with a series of messages where each message specifies the name of a Check Point as follows:

response = “dat list check_point_name” where check_point_name is the name of a Check Point

When the listing of Check Point names is complete, AEP sends:

response = “dat list done”

If at any point AEP cannot continue the List operation, then AEP sends:

response = “dat list failed”

3.2.6.2 Sync Operation

The Sync operation creates a new Sim Scenario (and state data) based on a given AEP Check Point. IC manages this operation by causing AEP to send state and other data to Sim corresponding to a given Check Point. Sim creates a temporary scenario using the AEP data; loads, synchronizes and saves the resulting scenario. The data transferred from AEP to Sim is known as “sync” data in that it synchronizes the new Sim Scenario with an AEP Check Point. IC sends AEP a request to prepare to sync using a given Check Point as follows:

request = “dat sync prepare check_point_name” where check_point_name is the name of a Check Point

AEP responds with:

response = “dat sync ready”

IC then directs SIM to proceed with requesting information from AEP to accomplish the Sync operation. SIM notifies IC when the data transfer is complete. (See Section 3.2.6.2.)

At any time AEP can send IC a message indicating a failure it has detected in the Sync operation:

response = “dat sync failed”

3.2.6.3 Delete Operation

The Delete operation is used to delete a specified AEP Check Point. IC sends the request:

request = “dat delete check_point_name” AEP deletes the specified Check Point and responds with:

response = “dat delete done”

If AEP fails in deleting the Check Point, then the response is:

response = “dat delete failed”

3.3 Instructor Control / Sim Interface Description

This section describes the interface between Instructor Control (IC) and Sim. This interface permits IC to control the operation of Sim and to send simulation directives. Sim sends simulation time messages and log messages to IC. An interface between IC and Sim is used to transfer data from Sim that is used by the Model Data Viewer components of IC. All messages are composed of ASCII text.

IC initiates the execution of SIM using SSH. Communications between IC and SIM is accomplished using TCP/IP.

3.3.1 Channel Communications

Excluding communications for Model Data Viewers, there are two TCP/IP channels: the Control Channel and the Log Channel. The communications for Model Data Viewers is described in section 3.3.7 of this document. The server for these channels is Sim, and IC is the client. The port numbers for these channels are assigned as an offset from a base number:

· Control Channel port number offset = 0

· Log Channel port number offset = 1 The Control Channel is bi-directional and carries four kinds of messages:

(1) Control Messages

(2) Directive Messages

(3) Time Messages

(4) Data Management Messages

Control Messages permit IC to request operational actions from SIM such as Load, Save, Pause and Run. Control Messages include the response from SIM for these requests. Directive Messages are sent from IC to SIM to invoke the performance of SIM directives that change the behavior of simulation models, such as injecting anomalies. Time Messages are sent from SIM to IC to keep IC synchronized to simulation time. Data Management Messages handle the management of initial condition data.

The Log Channel is uni-directional and carries Log Messages from SIM to IC.

3.3.2 Control Messages

Control Messages are used by IC to control SIM operation. A control request is sent from IC to SIM, and a response is expected back from SIM to IC. The control request from IC starts with the term “con”. The control response from SIM starts with “con”. Each control action is completed before another is initiated.

3.3.2.1 Ping Control

Ping checks the communication between IC and SIM:

control request = “con ping”

SIM responds with:

control response = “con pong”

Ping Control only occurs during startup. In the future Ping Control may be used periodically during operation to check communication.

3.3.2.2 Load Control

Load Control causes SIM to load the initial condition with the given name, and prepare for execution. SIM and IC must be in a paused state upon completion of the load operation.

control request = “con load initial_condition_name”

There are two kinds of initial conditions: full_save and delta_save. In relation to AEP, a full_save initial condition contains a complete set of state data, and a delta_save initial condition primarily contains a set of state data differences. In relation to SIM, the saved state information is the same.

For a delta_save_name, the term “.delta_#” is appended to the original full_save_name, where # indicates the sequence number of the delta save made with the full_save. All delta_saves will be deleted upon loading a full_save or quiting. Loading a delta_save will result in all future delta_saves being deleted.

If the load is successful, SIM will respond with:

control response = “con load_done sim_time”

Sim_time is a simulation time that specifies the start time of the initial conditions. The form of sim_time is given in the Time Message description.

If the load fails, SIM responds with:

control response = “con load_failed”

3.3.2.3 Run Control

Run Control requests SIM to start propagating simulation time:

control request = “con run”

SIM responds with:

control response = “con running”

3.3.2.4 Pause Control

Pause Control causes SIM to halt simulation propagation at the given simulation time:

control request = “con pause sim_time”

Sim_time specifies the time at which the pause is to become effective. The form of sim_time is given in the Time Message description. The time for the pause will be the current simulation time plus an interval estimated to account for the process of pausing.

SIM responds with:

control response = “con paused”

3.3.2.5 Speed Control

Speed Control causes SIM to change the speed of simulation. The speed is the ratio of the passage of simulation time to real time. Note: Pause Control must be done before Speed Control.

control request = “con speed ##.#”

SIM responds with:

control response = “con speed_changed”

SIM and IC are in the paused state after the speed is changed.

3.3.2.6 Full Save Control

Full Save Control causes SIM to perform a full save. Note: Pause control must be done before full save control.

control request = “con full_save full_save_name”

Full_save_name specifies the name to be given to the set of saved state data. This saved data also constitutes an initial condition with the same name.

If the save is successful, SIM will respond with:

control response = “con save_done”

SIM and IC are in the paused state after the save is completed.

If the save fails, SIM will respond with:

control response = “con save_failed”

3.3.2.7 Delta Save Control

Delta Save Control causes SIM to perform a delta save. Note: Pause control must be done before Delta Save Control.

control request = “con delta_save delta_save_name”

Delta_save_name specifies the name to be given to the set of saved state data. For a delta_save_name, the term “.delta_#” is appended to the original full_save_name, where # indicates the sequence number of the delta save made with the full_save. This saved data also constitutes an initial condition with the same name.

If the save is successful, SIM will respond with:

control response = “con save_done”

SIM and IC are in the paused state after the save is completed.

If the save fails, SIM will respond with:

control response = “con save_failed”

3.3.2.8 Quit Control

Quit Control causes SIM to halt and the SIM application to be terminated.

control request = “con quit”

SIM does not send a response to this request.

3.3.3 Directive Messages

Directive messages are sent from IC to SIM. SIM directives are use to inject simulated anomalies, change model parameters, and issue SV commands. The directive message begins with the term “dir”.

directive request = “dir source_tag sim_target sim_action”

The source_tag identifies the Script Player that is sending the directive request. Sim will include the source_tag in the directive response so that the response can be routed to the Script Player that issued the directive. Sim_target designates the Space Vehicles (SV), Ground Antennas (GA), Monitor Stations (MS), or SIM Executive (EX) that are the object of a directive. Sim_action names the SIM directive to be performed, along with specifying parameter values using name-value pairs. The syntax for sim_target and sim_action is defined in the Software Design Document for the Positional Training Emulator of the Global Positioning System Block, Appendix A - PTE Script Language Description (MG50539000013E5). The directive response begins with “dir”.

· When SIM successfully completes a directive, it responds with directive response = “dir done source_tag” where source_tag is the same as that given in the directive request.

· If the directive cannot be completed successfully, then SIM responds with:

directive response = “dir failed source_tag”

In addition to indicating the failure in the directive response, SIM will send a log message, with alarm status, identifying the failure.

3.3.4 Time Messages

A Time Stamp is sent from Sim to IC to keep IC synchronized with SIM. Time Messages are only sent by SIM when the mode is “running,” that is, simulation time is being advanced. SIM will send a Time Message once per simulation second.

time message = “time sim_time”

Sim_time specifies the simulation date and time. The format is:

“YYYY/DDD/HH:MM:SS.SSSS”

3.3.5 Log Messages

Log messages are sent from SIM to IC to provide the instructor with appropriate information about the progress of the simulation.

log message = “source status sim_time text”

Source specifies the simulation object that originated the log message: SV, GA, MS, or EX.

source = “sv sv_id” or “ga ga_id” or “ms ms_id” or “ex”

Sv_id, ga_id, and ms_id are defined in the Software Design Document for the Positional Training Emulator of the Global Positioning System Block, Appendix A - PTE Script Language Description(MG50539000013E5).

Status indicates the appropriate attention the log message is to be given.

Status = “A” or “W” or “E” or “I”

A: alarm

W: warning

E: event

I: information sim_time is used to simulation time stamp the log message using the format given in the Time Message section.

Text contains the text of the Log Message.

3.3.6 Data Management Messages

Data Management Messages handle the management of initial condition data. In SIM this data consists of SIM Scenario files and state data files. These messages are passed on the Control Channel. It can be assumed that a training session will not be in progress when these messages are used. These messages start with the term “dat” and are used to realize two operations: “list” and “sync”. In order to use these messages, communications must be established between IC and Sim using the “con ping” and “con pong” protocol mentioned above. Communications are terminated when IC sends a “con quit”.

3.3.6.1 List Operation

The List operation provides IC with the list of Sim Scenarios. IC first sends the request:

request = “dat list”

SIM responds with a series of messages where each message specifies the name of a SIM Scenario as follows:

response = “dat list sim_scenario_name” where sim_scenario_name is the name of a SIM Scenario

When the listing of Scenario names is complete, SIM sends:

response = “dat list done”

If at any point SIM cannot continue the List operation, then SIM sends:

response = “data list failed”

3.3.6.2 Sync Operation

The Sync operation is used to create a Sim Scenario (and state data) based on a given AEP Check Point. IC manages this operation by causing Sim to create a prototype SIM Scenario based on information obtained from AEP for a designated AEP Check Point. Then IC directs SIM to load the prototype SIM Scenario, synchronize models, and perform a full save under the name provided by IC.

IC will have first directed AEP to prepare for the sync operation using a designated Check Point. IC then sends SIM a request to prepare the prototype SIM Scenario by obtaining scenario information from AEP:

request = “dat sync prepare”

When the SIM is done preparing the prototype SIM Scenario it responds with:

response = “dat sync ready”

IC now requests that the prototype SIM Scenario be loaded, models synchronized, and a full save be performed with the given sim_scenario_name:

request = “dat sync synchronize sim_scenario_name” When SIM has completed creating the new SIM Scenario it responds with:

response = “dat sync done”

At any time SIM can send IC a message indicating a failure it has detected in the Sync operation:

response = “dat sync failed”

3.3.6.3 Delete Operation

The Delete operation is used to delete a specified SIM Scenario. IC sends the request request = “dat delete sim_scenario_name” SIM deletes the specified SIM Scenario and responds with:

response = “dat delete done”

If SIM fails in deleting the SIM Scenario, then the response is:

response = “dat delete failed”

3.3.7 Interface for Model Data Viewers

The interface for Model Data Viewers (MDVs) passes data from SIM models to the MDV components of IC. There are MDVs for Space Vehicles (blocks IIA, IIR/IIR-M, and IIF), Ground Antennas, Monitor Stations, and the Environment. This data is passed on a set of TCP/IP channels reserved for MDV communications. An MDV uses the Control Channel to request that SIM open a MDV channel for data from a designated model. SIM responds to the request by opening a TCP/IP channel as server, and identifying the channel to the requesting MDV. The MDV then uses this channel to request that SIM start sending a selected set of model data (MDV Data Set) to the MDV. The SIM sends the selected MDV Data Sets periodically. The update period of MDV Data Sets can be adjusted using an environment variable for SIM. The MDV can request that SIM stop sending a MDV Data Set. The messages used for this communication are described in the following sections.

3.3.7.1 MDV Channel Request Messages

IC MDVs use the Control Channel to request that SIM open an MDV channel for data from a designated model:

control request = “dir source_tag ex open_mdv_channel(target=target_name[,id=entity_id])” Source_tag is used by the MDV to identify itself for responses on the Control Channel. Target_name specifies the desired class of model: sv, ga, ms, or env. Entity_id specifies the specific instance of that model. For Space Vehicle (SV) models, this would be the sv ID: a number from 1 to 32. For Ground Antenna (GA) and Monitor Station (MS) models, this would be the site designation: such as “kwajg”. For the Environment (ENV), no ID is required.

The SIM opens an MDV channel and responds with:

control response = “dir_done source_tag port=port_number” where port_number is the number of the TCP/IP port that has been opened by SIM.

If SIM cannot open the channel for any reason, then SIM responds with:

control response = “dir_failed source_tag”

When an IC MDV is closed, the following message is sent to SIM to close the channel:

control request = “dir source_tag ex close_mdv_channel(target=sv,id=entity_id)” SIM does not respond to this request.

3.3.7.2 Model Data Set Selection Messages

An IC MDV uses a MDV Channel to request that SIM starting sending a designated MDV Data Set:

request = “dir source_tag ex select_mdv_data(select=mdv_data_set_name[,list=telemetry_id])” The mdv_data_set_name identifies the MDV Data Set to be supplied by SIM. MDV Data Sets are identified in Appendix A(Data Sets). The list parameter is only used for telemetry MDV Data Sets and list the desired telemetry measurands by telemetry_id.

If the SIM can start sending the selected MDV Data Set, then the SIM responds with:

response = “dir_done source_tag” Otherwise the SIM responds with:

response = “dir_failed source_tag”

3.3.7.3 MDV Data Set Messages

Using a MDV Channel, SIM sends MDV Data Set messages to a MDV. These messages contain requested model data. These messages are sent as a single TCP “line” terminated by a CR/LF. The messages contain a header and one or more data groups. The header is defined as follows:

Header = “mdv_data_set_name time;”

Where mdv_data_set_name is the name of the MDV Data Set and time is the sample time of the data in YYYY/DDD/HH.MM.SS.SSSS format.

Data groups are separated by semi-colons. A data group is a string of values with values delimited by a single space.

The contents of MDV Data Sets are specified in Appendix A(Data Sets).

3.4 AEP MCS / Sim Interface Description

In the PTE system, Sim simulates the external network and satellite constellation that the operational OCS interfaces with. The AEP exchanges data with the Sim using the same data formats and protocols as the OCS. The AEP interface with Sim is based on the existing interface with the GPS System Simulator (GSS) that is documented in the SDD-TTC-637, Appendix F (VME ICD) and the applicable OCS interface control documents (ICDs). This IDD defines the additional interfaces between AEP and Sim that are particular to PTE.

3.4.1 Channel Communications

AEP uses, and is the server for, one TCP/IP channel called the Control Channel. The port number for the Control Channel is assigned an offset to a base port number:

Control Channel port number offset = 2 The basic purpose of the Control Channel is to enable SIM to request and receive scenario data from AEP. It is also used by SIM to provide time synchronization to AEP.

The Control Channel is bi-directional and carries three kinds of messages:

(1) Request Messages – SIM to AEP

(2) Data Messages - AEP to SIM

(3) Directive Error Messages - AEP to SIM

3.4.2 Time Message

The Time Message is a time stamp sent from SIM to AEP to keep AEP synchronized with SIM. Time Messages are only sent by SIM when the mode is “running”: that is simulation time is being advanced. SIM will send a Time Message once per simulation second.

time message = “time sim_time”

Sim_time specifies the simulated date and time. The format is “YYYY/DDD/HH:MM:SS.SSSS”.

No acknowledgement is expected from AEP to SIM.

3.4.3 Data Request Messages

Data Request Messages are used by SIM to request scenario data from AEP. A data request is sent from SIM to AEP, and a response is expected back from AEP to SIM. The control request from SIM starts with the term “dat”. The data response from AEP also starts with “dat”. Each data request is completed before another is initiated.

3.4.3.1 Sync Time Message

This SIM message requests that AEP send a scenario synchronization time. Sync_Time is the scenario (Check Point time) start time common to all scenario SVs and other assets.

Message Request (SIM to AEP):

Request Synch Time Message = “dat get_sync_time”

This message contains zero parameters.

Message Response (AEP to SIM):

Request successful:

AEP responds with the message below once and is applicable to all subsequent SVs and other assets. DDD is the Julian Day.

Synch Time Messages = “dat put_sync_time YYYY/DDD/HH:MM:SSSS”

This message contains one parameter, the time stamp per the above format as one contiguous string.

Request failed:

If AEP is unable to create or send the scenario synchronization time to SIM, then AEP sends the message below.

Synch Time Error Message = “dat put_sync_time failed”

This message contains one parameter indicating that the get_sync_time message failed.

3.4.3.2 SV List Message

This message requests that AEP provide a list of operational SV Identification numbers.

Message Request (SIM to AEP):

Request SV List Message = “dat get_sv_list”

This message contains zero parameters.

The term “list” as used in this interface is different from the IC usage (list of scenario names and list of check point name). In the AEP-SIM message interface, “list” or “sv_list” is a collection of integer numbers identifying each SV in the scenario.

Message Response (AEP to SIM):

Request successful

AEP responds with the SV list message below. This message contains one parameter. Embedded within the single parameter is a series of comma delimited SV identification numbers.

AEP sends list of SVs = “dat put_sv_list n1,n2,n3,…,nn” The format of the SV numbers is: “n1,n2,n3,…,nn” where n1, n2 through nn are the Vehicle Identification numbers of all operational vehicles in the AEP database.

Request failed

AEP responds with this message if it is unable to send the SV list in its database. This message contains one parameter indicating that the get_sv_list message failed.

AEP List of SVs Error message = “dat put_sv_list failed”

3.4.3.3 SV Data Message

This message requests that AEP provide synchronization data for a specific SV.

Message Request (AEP to SIM):

Send SV Data message = “dat get_svdata nn”

This message contains one parameter, where nn is the integer Identification number of a specific vehicle.

Message Response (AEP to SIM):

Request successful

AEP responds with the following data message.

SV Data Message = “dat put_svdata nn, x_position, y_position, z_position, x_velocity, y_velocity, z_velocity, clock_error_Bias, clock_error_Drift, clock_error_Drift_Rate, K1_solar_pressure, K2_solar_pressure, propellant_mass, active_afs_id, active_afs_type, IRON_number, PRN_number” Assumptions:

· Clock Error values are for the “Active Clock”.

· The number of digits of precision is a desired value. SIM can function with a smaller precision than shown in Table 1 below.

· This message contains one parameter. Embedded within the single parameter is a series of comma separated parameter values as delineated in Table 1.

Table 1 - SV Data Message Parameters

Request failed

This message indicates that AEP is unable to send the requested data values for SV nn.

SV Put Data Error Message = “dat put_sv_data nn,failed”

This message contains 2 comma delimited parameters which together indicate that the get_svdata message for a specific SV failed, and where nn is the integer Identification number of a specific vehicle.

3.4.3.4 KIT 123 Configuration Message

This message requests that AEP provide SIM the KIT123 configuration data for a specific SV.

Message Request (SIM to AEP):

Send KIT-123 configuration message = “dat get_kit123_config nn”

This message contains one parameter, where nn is the integer Identification number of a specific vehicle.

Message Response (AEP to SIM):

Request successful

Ground Config KIT123 Data Message = “dat put_kit123_config nn, primary permuter_address, pattern, secondary_permuter_address, pattern” Assumptions:

· The term “pattern” is a fictitious test pattern.

· This message contains one parameter. Embedded within the single parameter is a series of comma separated parameter values as delineated in Table 2 below.

Table 2 - KIT123 Configuration Message Parameters

This message indicates that AEP is unable to send the requested data values for vehicle nn.

AEP KIT123 Data Error Message = “dat put_kit123_config nn,failed”

This message contains 2 comma delimited parameters which together indicate that the get_kit123_config message for a specific SV failed, where nn is the integer Identification number of a specific vehicle.

3.4.3.5 KGR28 Configuration Message

This message requests AEP provide SIM the KGR28 configuration data for a specific SV.

Message Request (SIM to AEP):

Send KGR28 configuration message = “dat get_kgr28_config nn”

This message contains one parameter, where nn is the integer Identification number of a specific vehicle.

Message Response (AEP to SIM):

Request successful Ground config KGR28 Data Messages = “dat put_kgr28_config nn, primary permuter_address, pattern, device” Assumptions:

· The term “pattern” is a fictitious test pattern.

· This message contains one parameter. Embedded within the single parameter is a series of comma separated values delineated in Table 3 below.

Table 3 - KGR28 Configuration Message Parameters

Put KGR28 Data Error Message = “dat put_kgr28_config nn,failed”

This message contains 2 comma delimited parameters which together indicate that the get_kgr28_config message for a specific SV failed, where nn is the integer Identification number of a specific vehicle.

3.4.3.6 KI-17 Cardholder Configuration Message

This message requests that AEP provide SIM the KI-17 cardholder configuration data for a specific SV.

Message Request (SIM to AEP):

Send KI-17 cardholder configuration message = “dat get_ki17_cardholder_config nn”

This message contains one parameter, where nn is the integer Identification number of a specific vehicle.

Message Response (AEP to SIM):

Request successful Ground config KI-17 Cardholder Data Messages = “dat put_ki17_cardholder_config nn, num_records, key_index, algorithm_type, SV_slot_id, pattern” Assumptions:

· The term “pattern” is a fictitious test pattern.

· This message contains one parameter. Embedded within the single parameter is a series of comma separated parameter values delineated in Table 4 below. The number of records indicates how many sets of comma delineated data are contained in the data message. This is variable depending on the record type.

Table 4 - KI-17 Cardholder Configuration Message Parameters

FFFFFFFFFFFFFFFF

Put KI-17 Cardholder Data Error Message =

“dat put_ki17_cardholder_config nn,failed”

This message contains 2 comma delimited parameters which together indicate that the get_ ki17_cardholder_config message for a specific SV failed, where nn is the integer Identification number of a specific vehicle.

3.4.3.7 KI-17 Pegasus Configuration Message

This message requests that AEP provide SIM the KI-17 Pegasus configuration data for a specific SV.

Message Request (SIM to AEP):

Send KI-17 pegasus configuration message =

“dat get_ki17_pegasus_config nn”

This message contains one parameter, where nn is the integer Identification number of a specific vehicle.

Message Response (AEP to SIM):

Request successful Ground config KI-17 Pegasus Data Messages = “dat put_ki17_pegasus_config nn,num_records, key_index, algorithm_type, SV_slot_id, pattern”

Assumptions:

· The term “pattern” is a fictitious test pattern.

· This message contains one parameter. Embedded within the single parameter is a series of comma separated parameter values delineated in Table 5 below. The number of records indicates how many sets of comma delineated data are contained in the data message. This is variable depending on the record type.

Table 5 - KI-17 Pegasus Configuration Message Parameters

Put KI-17 Pegasus Data Error Message = “dat put_ki17_pegasus_config nn,failed”

This message contains 2 comma delimited parameters which together indicate that the get_ ki17_pegasus_config message for a specific SV failed, where nn is the integer Identification number of a specific vehicle.

3.4.3.8 Memory Image Message

This message requests that AEP transfer NAV processor and Control processor memory data for a specific SV in the constellation. The transfers are in the form of binary files, with data, file names and file sizes dependent on the SV block type. A single request is sent for an individual SV. The AEP response is the transfer of binary files as shown above. The files are dependent on SV Block Type. Table 6 shows the data type and file names for each block type:

Request Message (SIM to AEP):

Memory Image Data Message = “dat get_mem_image nn”

· This message contains one parameter “nn”, the integer identification number of a specific vehicle.

Response Message (AEP to SIM):

Request successful SIM receives the message below upon completion of memory image file transfers (NAV/MDU/NDU and SPU_A-B/SCP depending on block type) to SIM for the SV in the previous request.

Memory Image Transfer Done Message = “dat put_mem_image nn”

· This message contains one parameter, the Identification number (integer) of a specific vehicle.

Table 6 - Memory Image Message File Information

NAV Processor

Control Processor

SPU_B

SVnn_MI_SPU_A.bin

SVnn_MI_SPU_B.bin

The binary memory image files are transferred to server “simeng” and stored in directory /sim/sync/memimage/. This directory will not change unless the change is mutually agreed to.

This message indicates that AEP is unable to send/transfer the requested memory image files.

Memory Image Transfer Error Message = “dat put_mem_image nn,failed”

This message contains 2 comma delimited parameters which together indicate that the get_mem_image message for a specific SV failed, where nn is the integer Identification number of a specific vehicle.

SIM requires the .bin version of the memory image binary files, not the .UMI version. The SPU_A/B .bin files must contain non-zero GSP (Ground Selectable Parameters) values reflecting the current state of vehicle’s SPU (Spacecraft Processor Unit) memory at synchronization time. All memory image binary data is transferred (“rcp” for example) as a physical file.

(Note: A detailed definition of memory address ranges for NAV, SPU and MDU (Mission Data Unit) data is contained in Appendix A.)

3.4.3.9 MS Clock Error Message

This messages requests that AEP transfer clock error values for the Monitor Station defined by the mnemonic “xxxxxx”.

Message Request (SIM to AEP):

Monitor Station Clock Errors Message = “dat get_ms_clockerror xxxxxx”

“xxxxxx” represents the maximum number (six) of character for the Monitor Station mnemonic. The minimum number of characters is four. The table below shows the current Monitor Stations mnemonics and representative messages for which this data may be required:

Table 7 - MS Clock Error Message Formats

Note: The naming convention for Monitor Stations is the same as defined in the Software Design Document for the Positional Training Emulator of the Global Positioning System Block, Appendix A - PTE Script Language Description (MG50539000013E5). Clock error values for the positional Monitor Stations CAPEM_0 to CAPEM_9 are currently not required.

Response Message (AEP to SIM):

Request successful Monitor Station Clock Errors Data Message =

“dat put_ms_clockerror xxxxxx,clockerror_Bias,clockerror_Drift”

· The formats for the two field items are described in the table below. The number of digits of precision is a desired value. SIM can function with a smaller precision than shown.

Table 8 - MS Clock Error Message Parameters

This message indicates that AEP is unable to process the request to send clock error data for the Monitor Station “xxxxxx”.

Monitor Station Clock Data Error Message = “dat put_ms_clockerror xxxxxx,failed”

This message contains 2 comma delimited parameters which together indicate that the get_ms_clockerror message for a specific MS failed.

4 Requirement Traceability

See MG50539000013E2, the Software Requirements Specification for the Positional Training Emulator of the Global Positioning System Block IIF.

5 Acronyms and Abbreviations

10 Appendix A Model data sets.

Appendix A is presented in a separately bound and delivered unclassified document.

� EMBED Word.Document.8 \s ���

GS Control,�S Band Uplink Data

Sim Time, GS Status, S Band Downlink Data, MS Data

Responses, Sim Time, logging

Responses, Sim Time, logging

Control�Directives

Sim

Role: Model IIA/IIR/IIR-M/IIF SV’s, GAs, ARTS, NGS, MSs, and Ext I/F Environment (Sun, Moon, Earth, Atmosphere, etc.).

Platform: Sun Servers

AEP

Role: Command and Control of simulated GPS SV’s and operation of Nav Mission.

Platform:…