SOFTWARE. REQUiREMENTS SPECIFICATION FOR THE FLIGHT … · 2019. 5. 1. · This Software Requirements Specification details the software requirements for the FS CSCI. The FS CSCI

-..

. ' . . r· \:ti''-. (. ·.\ r . · ·-!t·�-· -

SOFTWARE. REQUiREMENTS SPECIFICATION

FOR THE • . , •• t

. • � >· \. - • � ·� •• , •. • • • •

DEEP SPACE PROGRAM SCIENCE:.EXPERIMENT (DSPSE)

FLIGHT SOFTW ARlt" CSCI

June 1, 1992

. Prepared for: Naval Re�.

earch Laboratory, Code 8100

Washington, D.C. 20375-5000

Prepared by:

DSPSE Flight Software Development Team

..!---- ---

'l . -�--·.'

'i

, i \.I

_,_ .

·�

. . , . , -·-

.. - -�

�· .

·-

'·

-; .... � : ·.

· ...... ' . ... ·. , • · '• '

•:'.

. , , ; . : 1 . .. ..

,. , ,I

.:. :.: ··. t! f . . . -�

. .• . ·. ·.L .••

. �-:� .. : . ,.

.. �

.

.. , . . : · ...

· .•.· .

. .. , . ···l} ;

' . . . - � . . _..,_: .

. � .. - .

... . ... . . . . .. . .

.:-:_r.• • • . . - .... . ... ' ' .

.:· · · · ··z ·: ... ;

.. . . ' ·�·�: . . . . .

. �-_; .• . : : � ' � • • ' .. 7. . . • . .

·r

• ,i

\ ·.'

.· -� -

. -.- �

iO

. ·;·

.....

_j_ .. I ' 1

1.1 1.2 1.3

TABLE OF CONTENTS

SCOPE . . . . ... . . ..... . .... . . . .. . .. . . . . . . . . . . ... . . . . . .. . . . .... . . . . . 3

Identification . . . . . . . . . . . . . . . . . . . . . ...................... . . . . . . . . . . . . . . . . . . . . . . . . . . 3 CSCI Overview ..... . ............. .............. .. ............................... 3 Document Overview . ... . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . ......... . . ..... . . . . . . . 3

2 APPLICABLE DOCUMENTS .........•.................•...... 5 2.1 Government Documents ... . . . . . . . . ........ . . . . . . ... . . . ..... ... . . . ... . . . . . . . . . .. 5 2.2 Non-Government Documents ........................ ............... ....... .... 5

3

3.1 3.1.1 3.1.1.1 3.1.1.2 3.1.2 3.1.2.1 3.1.2.2 3.2 3.2.1 3.2.1.1 3.2.1.2 3.2.1.3 3.2.2 3.2.2.1 3.2.2.2 3.2.2.3 3.2.3 3.2.3.1 3.2.3.1.1 3.2.3.1.2 3.2.3.1.3 3.2.3.2 3.2.3.3 3.2.3.3.1 3.2.3.3.1.1. 3.2.3.3.1.2. 3.2.3.3.1.3. 3.2.3.3.2 3.2.3.3.2.1. 3.2.3.3.2.2. 3.2.3.3.2.3. 3.2.3.3.3 3.2.3.3.3.1. 3.2.3.3.3.2. 3.2.3.3.3.3. 3.2.3.3.4 3.2.3.4 3.2.3.4.1 3.2.3.4.1.1. 3.2.3.4.1.2. 3.2.4

ENGINEERING REQUIREMENTS •..••..•...•.•• ••.•....••... 6

FS External Interface Requirement ... .......... ... ........ . . . . . . . . . . ... . . ..... 6 Software/liard ware Interfaces . . . . . ... .... . . ........ . . . . . . . . ... .......... . . . ... 6 Hardware Inputs .............................. . ................. ................. 6 Hardware Outputs .. . . ........... ... . . . ; ......................................... 7

Flight/Ground Software Interfaces ....... . . . . . . . .. . . . ... . . . ... . . . . . . . . ... . . .. . 7

Command Interfaces ... . . . . . .. . . . . . . . . . .. .' ...................................... 7

Tel emetry Interfaces ............................................................. 7

CSCI Capability Requirements ........ . . . .... . .... . . . . ...... . . . . . . . . . . ........ 8 Executive Capability Requirements . .. . . . . . . . .......... . . . . . ... . . . ....... . .... 8 Executive Input Requirements . . . . . . . . . . ... . . . ... . . . . . . . . . . . ...... .... . ... . . . . . 8 Executive Processing Requirements . . . . . . . .. . .. . . ... . ... . . . ...... . . . . . . . . ... . 8 Executive Output Requirements .. . ....... . .......... . . . . ... ...... . ............ 9 Prom and System Initialization Capability Requirements ................... 9 PROM and System Initialization Input Requirements ....................... 9 PROM and System Initialization Processing Requirements . . . . .... . . . ... . . 9 Prom and System Initialization Output Requirements ....................... lO

Command Processing (CMDPROC) Capability Requirements . ... . ... . ... 10 CMDPROC CSC Description ............................. ............... ...... 10 Command Types ... . . . ....... . . . . . . . . . . ...... . . ........... . .. . . . . . . . . . . ... . . .... 10 Command Definitio n s ... ........ ........................ .................•...... 11 Command Functions ... . . . . . ... . . . . . . . . . . . . . . . . . ...... . . . ... . . ... . .. . . . . . . . . . . .. 11 CMDPROC CSC External Interface Requirements . . . . . . . . . . . . . ... . . . . . . . . . 12 CMDPROC CSC Capability Requirements .. . ... . . . . ... . . . . . ... . . . . .... . . . . . 12 Real Time Commands . . . . ..... . . . : .............................................. 12 Real Time Command Input ........ .-............................................ 12 Real Time Command Processing ... . . . .............. . . ... . . . . . . . . . . . . . . . . . . . . . 12 Real Time Command Output . . ........ . . . . . . . . ......... ........ ... . . . . . . ....... 13 Stored Commands ...................... ................ .... ..................... 13 Stored Command Input. . .••. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Stored Command Processing . . . . . .. .. ............ . . . . . . . . .. . . . . . . . . . . . ... . . ... 13 Stored Command Output . . . .. . . . . . � . . . . . . . . . . . . . . . . . . . . . . ..... . . . . . . .. . . . ... ... 14 Event Driven Commands ..... . . ... .......... . . . . . . . . . . .... .. . . ... .. . . .. . . ....... 14 Event Driven Command Input . . . . . . . . . . . . ............. . . . . . .. . .... . . .. . . . . .... 14 Event Driven Command Processing . . . ... . ............ . . . . . . . . . . . . . . . . . . . . .. . 14 Event Driven Command Output . .. . . . . . .............. . . ... . .. . . ... . . . . . .. . . . . . 15 Command Output Procedures .................................................. 15 CMDPROC CSC Data Elements ... . . ............ . . . . . . . . . . . . . . . . . ... . . . . . . . . . 15 Command Record Descriptor . . . . . . . ... . . . . . ........... . . . . . . . . ... . . . . . . . . . . .. . 15 Command Record Fields . .. ........ . . . . ............ . . . . . . . . ...... . ... . . . . . . . . . . 15 Command Record Size . .... ... . . . . . . . ........ . .. ... . ..... . . . . . .. . . ...... . . . . . . . 16 TELEMETRY PROCESSING (TLMPROC) CSC .. . ... . . . . . . . . . ... . . . ... . 16

3.2.4.1

3.2.4.1.1

3.2.4.2

3.2.4.3

3.2.4.3.1

3.2.4.3.1.1.

3.2.4.3.1.2.

3.2.4.3.1.3.

3.2.4.3.2

3.2.4.3.2.1.

3.2.4.3.2.2.

3.2.4.3.2.3.

3.2.4.3.3

3.2.4.3.3.1.

3.2.4.3.3.2.

3.2.4.3.3.3.

3.2.4.4

3.2.4.4.1

3.2.4.4.1.1.

3.2.4.4.1.2.

3.2.4.4.2

3.2.4.4.2.1.

3.2.4.4.2.2.

3.2.4.4.3

3.2.4.4.3.1.

3.2.4.4.3.2.

3.2.5

3.2.5.1

3.2.5.2

3.2.5.3

3.2.5.3.1

3.2.5.3.2

3.2.5.3.3

3.2.6

3.2.6.1

3.2.6.2

3.2.6.3

3.2.6.3.1

3.2.6.3.2

3.2.6.3.3

3.2.7

Requirements 3.2.7.1

3.2.7.2

3.2.7.3

3.2.8

3.2.8.1

3.2.8.2

3.2.8.3

3.2.9

3.2.9.1

3.2.9.2

3.2.9.3

3.2.10

1LMPROC CSC Description . . . . . . .. . . . . . . . . . . . .. . . .. . . .. . . . . . . . . . . . . . . . . . ... . 16

Telemetry Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . ; ...... 16

1LMPROC CSC External Interface Requirements . . . . .. . . . . . . . . . . . . . . -...... 16

TLMPRQC CSC Capability Requirements ........................... � ... .... 16

Telemetry Acquisition . . . ........................................................ 16

Telemetry Acquisition Input ...............................................•.... 16

Telemetry Acquisition Processing . . ... . . . . . . . . . . . . . . . . . . . . . . ... . . . . .. . . . . . . . . . 17

Telemetry Acquisition Output .... . . . . . . . . . . . . . . . . . . ... . . ..... . . . . ..... ... -...... 17

Telemetry Reduction . . . . . . . . ......... . . . . . . .. . . . . . . . . . . . . . . . . . ...... . . . . .... . . . . .17

Telemetry Reduction Input . . . .. . . . . . . . . . ........... . . . . . . . . . . . . . . . . . .. . . .. . . .. . 17

Telemetry Reduction Processing . . . . .... . . . . . . .... .. . . . . . . ... . . . ...... . .. . . . . . 17

Telemetry Reduction Output . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Telemetry Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Telemetry Logging Input . .. . . . . . . . . . . . .. . . . .. . . . ..... . . . . . . . .. . . . . . . . . . . . . . . . . . 18

Telemetry Logging Processing . . . . . . . . . . . . . . . ... . . . . . . . . . . . .... . . . . . ... ... . . . . 18

Telemetry Logging Output . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . ... . . . . . . . . . . . . . . . . . 18

1LMPROC CSC Data Elements . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . 19

Analog Record Descriptor . . ... . . . ... . ... . . . . . . . . . . . . . . ... . . . . . . . .. . . . . . . .. . . .. . 19

Analog Record Fields . . . . . . . . . . . . . . . . . . . . . . . . . ....... . . . . . .. . . .. . . . . . . . . . . . . . . . . 19

Analog Record Size . . . . . . . . . .. . . . . . . . . . . . ... . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . 19

Discrete Record Descriptor . . . .. . . .... . . . . ... . .... . . . ... . . . . ... . . . . . . . . . ... . . . . . 19

Discrete Record Fields . .. . . . . . ....... . . . . . . . . . ... . . . ............. . . . . . . . . . . . . . .. 20

Discrete Record Size . . . . . . . . ... . ....... . . . . . . . . . . . . . . . . ............. . . ... . . . . . . . 20

Derived Record Descriptor . . . .... .. . . . . . . . . . . . . . . . . . . . . . .. . . .. . . . . . . . . . . . . . . ... 20

Derived Record Fields . . . . . .. . . . . . . . . . . . . . . .. . .. . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . _ 20

Derived Record Size . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . 20

COMMAND INPUT (CMDIN) CSC ....................................... .. 20

CMDIN" CSC Description . . . . . . . . . . . . . . . . . . . . .. . . .. . . .. . . . . . . . . . .. . . ...... . . . . . 21

CMDIN" CSC External Interface Requirements . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . 21

CMDIN CSC Capability Requirements ....................................... 21

CMDIN Inputs . ............ ............ ............ ............ .................. 21

CMDIN" Processing . . . . . . . . . . . . . ... . ............... . . . ... . . . . . . . . . . . . . . . . . . . . ... 21

CMDIN" Outputs . . . . . . . . . . . . . . . . . . . .... . . . . . . . . . . . . . .. . . .. . . . . . . ... . . . . . . . . . . . . . . 21

Telemetry Output (1LMOUT) CSC . . . . . . . . . . . . . . .. . . . .. . ....... . ... . . . . . . . . . . 21

1LMOUT CSC Description ......... . . ......... . . . . . . . . . .. . . . . . . . . . . .. . . ... ... . 21

1LMOUT CSC External Interface Requirements ............................ 21

1LMOUT CSC Capability Requirements . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 21

CMDIN Inputs . . . . . . .. . ..... . ...... ....... ..... . . . . . . . . ........ . ......... . . . . . ... 21

CMDIN" Processing . . . . . . . . . . . . . .. . . .. . . . . ....... . . . . . . . . . . . . . .... . . . . . . . . . . . . . . 22

CMDIN" Outputs . . . . . . .. . . . . . . . . . . . . . .. . .... . . . . . . . . . . . . . . . . . ... . . . . . . .. . . .. . . . .. 22

Guidance, Navigation, & Control (GNC) Executive Capability 22

GNC Executive Input Requirements . . . . . ... . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . .. . 22

GNC Executive Processing Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

GNC Executive Output Requirements . . .. . . . . . . . . . . . .. . . .. . . . . . . . . . . . . . . . . .. . 23

Attitude Determination Capability Requirements . .. . . . . . . . . . . . . . . . . .. . .. . . . . 23

Attitide Determination Input Requirements . . . .. . . . . . . .... . . . . . . . .. . . . . . . . . . . . 23

Attitide Determination Capability Requirements ........ . . . . . . . . . . ..... . . . . . . 24

Attitide Determination Output Requirements ....... . . . . . . . . . . . . . . . . . ... . . . ... 25

Attitude Control Capability Requirements . . . . . .. . . ... . . . . . . . . . . . . . . . . . . . . . . . . 25

Attitide Control Inputs . . . . . . . . . .......... . . . . . . . .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Attitide Determination Capability Requirements . . . ... . . . .. . . . . ... ... . . . . . . . . 25

Attitide Control Output Requirements ......................................... 26

Autonomous Navigation Capability Requirements . . . .......... . . . . ... . . . . . . 26

3.2.10.1 3.2.10.2 3.2.10.3

-3.2.11 -3.2.11.1 3.2.11.2 3.2.11.3 3.2.12 3.2.12.1 3.2.12.2 3.2.12.3 3.2.13 3.2.13.1 3.2.13.2 3.2.13.3 -32.14 3.2)4.1 3.2.14.2 3.2.14.3 3.2.15 3.2.15.1 3.2.15.2 3.2.15.3 3.2.16 3.2.16.1 3.2.16.2 3.2.16.3 3.2.17 3.2.17.1 3.2.17.2 3.2.17.3 3.3 3.4 3.5 3.5.1

. 3.5.2 3.6 3.7 3.8 3.9 3.10 3.11 3.12

4

4.1 4.2

5

6

Autonomous Navigation Input Requirements ................................ 26 Autonomous Navigation Processing Requirements . . . . ..... . . . . . . ... . . . .... 27 Autonomous Navigation Output Requirements . . . ... ... . .. . . . . ... . . ... . . . ... 27 Terminal:Guidance and Control-Capability Requirements .............. .... 27 Terminal Guidance and Control Input Requirements ... .. . . . . .... . . . . .. . . . . 28 Terminal Guidance and Control Processing Requirements ................. 28 Terminal Guidance and Control Output Requirements ...................... 28 Sensor Control and Data Processing Requirements . ..... . .. . . . . . . .. . ....... 28 Sensor Control and Data Processing Input Requirements .... . .. . ..... .. . . . 28 Sensor Control and Data Processing Processing Requirements .. . ........ 29 Sensor Control and Data Processing Output Requirements . . . . . . . .... . .. . . 29 Delta V Control Requirements . . ... ... . . . . . . . . . . . . . . . . ... . . . .. . . . . . . .... ....... 30 Delta V Control Input Requirements . . . .. . . . . .. . . . . . . .. . . . ... . . . . . . . . ...... . . . 30 Delta V Control Processing Requirements . . . . . . . . .. . . . . . . . . . . . ... . . . .... . .. . 30 Delta V Control Output Requirements . . .. . . . . . . . . . . . . . . . . . . ... . . . .. . .... . . . . . 30 Solar Array Control Capability Requirements . . . . . . . . . . . . .... .. . . . . . .. . .. ... 30 Solar Array Control Input Requirements .. . . . .. . . . . . . . .. . . . ... . . . . . . . .. . . . ... 31 Solar Array Control Processing Requirements . . . . . . . .... . . . . . . . . . . . . . . . . . . . 31 Solar Array Control Output Requirements . . . . . . . . .. . . . .. . . . . . . . . . . . . . . . . . . . . 31 Memory loads and dumps Capability Requirements . .. . .. . ... . . ............ 31 Memory Load and Dump Facility Input Requirements . .. . . . . . . . .. . . . . . .... 31 Memory Load and Dump Facility Processing Requirements ............... 31 Memory Load and Dump Facility Output Requirements . ................... 32 Event Logging and Distribution Capability Requirements .................. 32 Event Logging and Distribution Input Requirements ... . ..... . . . .... .. . ... . 32 Event Logging and Distribution Processing Requirements ................. 32 Event Logging and Distribution Output Requirements ...................... 32 Processor Health and Status Capability Requirements ...................... 33 Processor Health and Status Input Requirements .. . . . .. . .. . . . .. . . .... . . . .. . 33 Processor Health and Status Processing Requirements ..................... 33 Processor Health and Status Output Requirements ........ . . ................ 33 CSCI Internal Interfaces . . . . . .. . ... . . . . . . . . . . . . . . . . . . . . . . ... . ... . . ... .. . .. ... ... 34 CSCI Data Element Requirements .......................... ................... 34 Adaption Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . .. . ... . . .. . . ..... . .... 34 Installation-dependent Data . . . . . . . . . . . ... . . . . . . . . . . . . ..... . ... . . . . .. ... . ..... . . . 34 Operational Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . ... 35 Sizing and Timing Requirements . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . ... . . . . . . . . . 35 Safety Requirements . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . ... . . . .. . . 35 Security Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . 35 Design Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . 35 Software Quality Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . ... . . . . . . . . . . . . . . . .. . 35 Human Performance/Human Engineering Requirements ................... 35 Requirements Traceability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... ... . . .... . . . . . . . . 35

QUALIFICATION REQUIREMENTS 36

Qualification Methods . . . ... ..... . . ... . . ........ . . . . ... . ...... ... ...... . . ...... . . 36 Special Qualification Requirements . . . . . . . . . . . ... . . . . .. . . .. .. ... . . . . . . . .. .... . 36

PREPARATION FOR DELIVERY 37

NOTES 38

1 SCOPE

1. 1 Identification

This specification establishes the requirements for the Deep Space Program Science Experiment (DSPSE) Flight Software (FS) CSCI. This Flight Software CSCI is composed of all the software executing on the spacecraft controller and sensor controller processor modules on the DSPSE spacecraft.

1. 2 CSCI Overview

The DSPSE software is partitioned into three segments; Flight Segment, Ground Segement, and Mission Operations Segment. The Flight Segment consists of all software which will reside onboard the DSPSE spacecraft. The Ground Segment consists of all ground station software including the Transportable Ground Station (TGS), Electrical Aerospace Ground Equipment (EAGE), and Electrical Launch Support Equipment (ELSE) which provides for command, control, and testing of the DSPSE spacecraft and launch vehicle. The Mission Operations Segment consists of all software for Mission Operations and Data Analysis. This specification details the software requirements for the Flight Segment. The software requirements for the Ground Segment and the Mission Operations segment are documented separately.

The Flight Segment is composed solely of the Flight Software (FS) CSCI. This Software Requirements Specification details the software requirements for the FS CSCI. The FS CSCI is composed of the following Computer Software Components (CSCs):

1. Executive (0/S services, Device Drivers, Interrupt Handling, Initialization)

2.. Prom Capability an.d System Initialization

3. Command Processing

4. Telemetry Processing

5. Command distribution

6. Telemetry distribution

7. Guidance, Navigation, and Control Executive

8. Attitude Determination

9. Attitude Control

10. Autonomous Navigation

11. Terminal Guidance and Control

12; Sensor Control and Data Processing

13. Delta V Control

14. Solar Array Control

15. Memory Loads and Dumps

16. Event Logging and Distribution

17. Processor Health and Status.

18. GMT Maintenance

5

I

i \.

1. 3 Document Overview

The purpose of this document is to identify the specific. requirements for the Flight Software CSCI. The document is organized in a manner consistent with the guidelines established by DIMCCR-80025A. This document is organized into TBD sections and TBD appendices.

Section 2 identifies other documents which are relevant to the DSPSE Flight Software requirements. Section 3 defines the detailed performance and interface requirements. Section 4

identifies the qualification requirements for test and verification. Section 5 specifies the specific requirements for software delivery. Section 6 contains notes.

Each requirement has an identifier associated with it that shall be used throughout the development process to track the requirement The convention used for these identifiers is as follows:

FSI_nnnn - Interface Requirement

FSA_nnnn - Adaptation Requirement

FSC_nnnn - Capability Requirement

FSD_nnn -Design Constraint Requirement

FSE_nnnn - Data Element Requirement

FSQ_nnnn - Quality Requirement

FSZ_nnnn - Sizing and timing Requirement

FSS_nnnn- Security Requirement

FST _nnnn - Qualification Requirement .

6

( \

2 APPLICABLE DOCUMENTS

2.1 Government Documents

The following documents of the exact issue shown form a part of this specification to the extent specified herein. In the event of conflict between the documents referenced herein and the contents of this specification, the contents of this specification shall be considered a superseding requirement.

SPECIFICATIONS

1. SSD-D-XXXXXXXX DSPSE Flight Algorithms , Date TBD.

STANDARDS

TBD.

DRAWINGS

TBD.

OTHER PUBLICATIONS

None.

Copies of specifications, standards, drawings, and publications required by suppliers in connection with specified procurement functions should be obtained from the contracting agency or as directed by the contracting officer

2.2 Non-Government Documents

The following documents of the exact issue form a part of this specification of the extent specified herein. In the event of conflict between the documents referenced herein and the contents of this specification, the contents of this specification shall be considered a superseding requirement.

SPECIFICATIONS:

1. SSD-D-XXX:XXXXX DSPSE Flight/Ground Interface Control Document, Date TBD.

1. SSD-D-:XXXXXXXX DSPSE Flight Hardware/Software Interface Control Document , Date TBD.

3. SSD-D-XXXXXXXX Data Formats Documents , Date TBD.

STANDARDS:

TBD.

DRAWINGS:

None.

OTHER PUBLICATIONS:

None.

7

3 Engineering Requirements

3 .l FS External Interface Requirement

The Flight Software (FS) CSCI interfaces with both the flight hardware and the ground software. The interfaces are detailed in the DSPSE Software/Hardware ICD and DSPSE Flight/Ground ICD respectively. Figure 3.1-1 provides a diagram of all the Flight Software CSCI external interfaces

3.1.1

- -

. _jeoEi I -· ....

solar_anay_cmd"s�-- •·-

.,...-"'--

sun_data Salsa

Figure 3.1-1

Software/Hardware Interfaces

The specific commands for each software/hardware interface is specified in detail in the DSPSE Flight Hardware/Software Interface Control Document

3.1.1. 1

FSI_

FSI_

FSI_

FSI_

FSI_

FSI_

FSI_

FSI_

FSI_

Hardware Inputs

The FS CSCI shall accept raw, uncompressed Star Tracker, UVNis, LIDAR, LWIR, and SWIR sensor data (i.e. pixel images) from the Data Handling Unit for image processing.

The FS CSCI shall accept and utilize the Star Tracker, UVNis, LIDAR, LWIR, and SWIR sensor status data for command verification of the sensors.

The FS CSCI shall collect telemetry data via the local telemetry interface card. Telemetry shall be collected as specified in the DSPSE Software/Hardware ICD.

The FS CSCI shall accept and process attitude and velocity increments from the Inertial Measurement Unit (IMU) for attitude determination and control. (The IMU provides 3 components of attitude and velocity increments for changes from inertial reference to spacecraft fixed reference).

The FS CSCI shall accept and process the sun sensor data to determine the current sun angle.

The FS CSCI shall be capable of retrieving data from the mass storage device onboard the spacecraft.

The FS CSCI shall accept the reaction wheel speed

The FS CSCI shall receive indication of TTI rocket firing and separation.

The FS CSCI shall accept and process the current reaction wheel speed.

8

FSI_ The FS 'CSCI shall accept and .process propellant tank pressure (if necessary to adjust control system parameters)

3 .1.1. 2 Hardware Outputs

FSI_ The FS CSCI shall control the Star Tracker, UV Nisual, LIDAR, L WIR, and SWIR sensors through the Synchronous Addressable Serial Interface (SASI) bus.

FSI_ The FS CSCI shall control the filter wheels and camera gain for the UVNisual, L WIR, and SWIR sensors through the Synchronous Addressable Serial Interface (SASI) bus.

FSI_ The FS CSCI shall distribute local commands via the local command interface card. Local commands shall be distributed as specified in the DSPSE Software/Hardware lCD.

FSI_ The FS CSCI shall issue commands to the ACS/RCS subsystem via the local ACS/RCS interface card for controlling the reaction control thruster.

· FSI_ The FS CSCI shall issue commands to the Solar Array Controller for controlling the angle of the spacecraft solar array panels relative to the sun.

FSI_ The FS CSCI shall be capable of storing data to the mass storage device onboard the spacecraft.

FSI_ The FS CSCI shall issue commands to control the reaction wheel speed.

3 .1. 2 Flight/Ground Software Interfaces

3 .1. 2.1 Command Interfaces

The FS CSCI shall accept and processing the following commands from the ground:

FSI_ Spacecraft epoch (position and velocity in TBD inertial coordinates at specified time)

FSI_

FSI_

FSI_

FSI_

FSI_

FSI_

3.1.2.2

FSI_

FSI_

FSI_

FSI_

Asteroid epoch (position and velocity in TBD inertial coordinates at specified time)

Delta V command: time of execution; desired attitude at time of firing; velocity increment to be achieved

Attitude mode command: time; attitude mode; if applicable, desired attitude

Filter wheel positions and camera gains for UV/visual, SWIR, and LWIR sensors

Requests for image data collection for UV /visual, SWIR, and L WIR sensors.

Enable/disable commands: autonomous navigation; autonomous terminal guidance and control; autonomous scheduling; solar array control; momentum dumping; automatic gain control of sensor cameras

Telemetry I�terfaces

Periodic outputs are (rates are TBD):

Estimated spacecraft attitude

Computed spacecraft position and velocity

Autonomous navigation updates to spacecraft position and velocity

Aperiodic outputs are:

Attitude control mode transitions

9

FSI_ Actual delta V's achieved

FSI_ Software detected errors and anomalous conditions

FSI_ Autonomous updates to asteroid position and velocity

3. 2 CSCI Capability Requirements

3.2.1 Executive Capability Requirements

The Flight Software Executive provides the following capabilities underlying tasking, messaging, and software control features for the spacecraft software system. The Executive is responsible to prioritize tasks, deliver message from task to task, and to respond to interrupts, as well as task switching capabilities for the flight software system. Included as part of the executive software are the device drivers for the various subsystems. The executive will manage all tasks which are present onboard the spacecraft

3.2.1.1 Executive Input Requirements

The Executive Processing Module shall accept the following external stimuli :

FSI_ External Device interrupts from various interrupt sources on board the Flight Hardware Subsystems. ( All Interrupt Sources TBD )

The Executive Processing Module shall accept the following internal stimuli :

FSI_ Software Tasking request from operating modules of the flight software.

FSI_

FSI_

3.2.1.2

FSC_

FSC_

FSC_

FSC_

Memory Allocation request from operating tasks in the flight software or from uploaded software modules.

Exception Interrupts and software interrupts generated by the execution of the flight software code.

Executive Processing Requirements

The Executive Processing Module shall provide for Task Management capabilities. This management must include multi-tasking capabilities, which includes priority scheduling and sequencing. The Executive Processing Module must provide the various task with start, stop, and suspend commands.

The Executive Processing Module shall provide for Intertask Communication between the various modules which are running in the processor. The communication may be accomplised in several different manners which include shared memory, message queses, pipes, and signals. Exclusion may also be specified by a task so that during desired periods of time other modules may not access messages which it is modifying.

The Executive Processing Module shall provide for Memory Management Facilities, which include allocation, deallocation, and boundary definition for all task involved in the flight software system. The executive shall handle allocating needed memory at task startup, and also provide for memroy error handling procedures.

The Executive Processing Module shall provide for Interrupt Services. These services will include 'C' interrupt handling routines, interrupt masking, lock &

unlock functions, exception handling, and interrupt communication with other tasks present in the software system. Nested Interrupts will be allowed, and the Executive Processing Module provides the means for processor state storage and recovery.

10

FSC_

FSC_

The executive module shall provide for-interfaces to the real-time timer. This will include providing for a Watchdog Timer with any task may reference in order to use for syncronization and control functions. The timer interface will be provides as part of the executive along with the

The Executive Processing Module shall provide Device Drivers for all the interfaces between the flight software process modules and the satellite system hardware. The drivers will provide needed calls and status for each of the various driver types. A list of device drivers is shown below (PRELIMINARY) along with their primary TYPE Description.

Driver

Timer Interface

SASI Bus Driver

Sensor Data Interface

Spacecraft Telemetry

Spacecraft Commanding

IMUDriver

Solar Array Driver

ACS/RCS

EPS Driver

TYPE

Internal Peripheral Control

Command Driver with Status

Block Oriented Data Reception with Cmd Setup





Command & Data Reception


3. 2 .1. 3 Executive Output Requirements

The Executive shall generate the following external stimuli :

FSI_ Device Driver outputs necessary to interface the software process request with the hardware on board the satellite. (ALL Drivers are TBD).

The Executive shall generate the followng internal stimuli :

FSI_ A response to a task allocation call with the proper status to the asking process. This output will indicate any error in task allocation.

FSI_ A response to a task request for memory allocation shall be return to the requesting task. This output will indicate any error in memory allocation or illegal memory request.

3.2.2 Prom and System Initialization Capability Requirements

The PROM and System Initialization software includes all the software which needs to reside in DSPS� spacecraft at system startup. This software must be on board in PROM and provide for the system startup procedures, default control capabilities, and safe system configuration without any ground intervention.

3.2.2.1 PROM and System Initialization Input Requirements

The PROM and System Initialization Module shall accept the following external stimuli :

FSI_ System Reset and Powerup will cause a restart of the flight software code which reside in the systems PROM memory in the satellite hardware.

11

/ - FSI_ System Reset Command (from ground)

The PROM and System Initialization Module shall accept the following internal stimuli:

3.2.2.2

FSC_

FSC_

FSC_

FSC_

FSC_

3.2.2.3

NONE

PROM and System Initialization Processing Requirements

The Executive Kernel will reside in the Hardware PROM along with all necessary kernel setup and initialization routines. This code shall contain all needed software startup code for the system hardware.

At startup Hardware Checkout and Status software will determine the operability of the flight hardware system, and report any problem to the error logging subsystem.

An initial Memory Map will be setup at system startup. This code will reside in the PROM of the Flight Hardware and will be a part of the initial hardware setup which takes place at system power up.

An initial Satellite Control function must be present in the PROM on-board the satellite. This Control must be defined as well· as any thruster & other control functions which must take place to place the satellite in a known safe-state at startup or during recovery.

A Status Logging capability must exist in the PROM in order to notify the results _

of the initial startup of the satellite software and hardware system. This status logging will output results to Event Logging and Distribution System.

Prom and System Initialization Output Requirements

The PROM and System Initialization Module shall ouput the following external stimuli :

FSI_ Shall notify the Error Logging Facility and store any system errors which occur during startup and initialization.

The PROM and System Initialization Module shall output the following internal stimuli :

FSI_ The desired self test stimulus to the various hardware peices in the satellite hardware in order to test the operability of all on board system. This will include memory tests, interface checking, response checking, and checksum of code segement to determine the validity of the on-board memory, and will stimulate recover if on-board memory is determined to be incorrect (TBD) { MAY USE Bulk Storage to hold copies of PROM memroy }

3.2.3 Command Processing (CMDPROC) Capability Requirements

3.2.3.1 CMDPROC CSC Description

The CMDPROC CSC is required to perform the high level command interpretation functions for the DSPSE program. More specifically, the CMDPROC CSC provides the real time, stored, and event driven command interpretation functions.

The CMDPROC CSC command requirements are divided into three functional areas for the purpose of defining its functional and performance characteristics:

a. Real Time Command Function; b . Stored Command Function; c. Inference Engine Function.

12

3.2.3.1.1 Command Types

The Cl\IDPROC CSC supports the following command types:

a. Internal Commands; b. Physical Commands; c. External Commands.

Internal commands provide directives to control the operation of the CMDPROC CSC or other CSCs executing along with the Cl\IDPROC CSC. Internal commands which are executed by the Cl\IDPROC CSC include such commands as:

a. Accepting and verifying DSPSE script and database uploads; b. Readout specified DSPSE memory such as scripts, rules, and database records; c. Manage Scripts.

A Physical command is one which controls a physical interface or device. Included in this type of command are the following:

a. High level discrete commands such as relay drivers; b. Low level discrete commands such as TIL level pulses; c. Serial or magnitude commands.

An external command is one which is sent from the processing equipment that is executing the CMDPROC CSC to another physical device that is external to the CMDPROC CSCs processing device. An example of this type of command are those that are issued to devices connected to a 1553B multiplexed data and control bus.

3.2.3.1.2 Command Definitions

The Cl\IDPROC CSC supports command processing in three different scenarios. The processing scenarios are defined as follows:

a. The CMDPROC CSC supports commands and command data that are executed immediately. These types of commands are known as real time commands. The CMDPROC may receive individual or multiple real time commands in a single command packet.

b. The CMDPROC CSC supports commands and command data that are stored in memory accessible to the processing equipment that is executing the CMDPROC CSC. These types of commands are known as stored command scripts.

c. The CMDPROC CSC supports actions such as commands and command data that are

executed as a result of predefined events. These types of commands are known as event driven commands.

·

The CMDPROC CSC processes commands that are identified by logical identifiers. These logical identifiers are translated into a formatted command prior to distribution to the destination device.

13

3.2.3.1.3 Command Functions

The CMDPROC CSC Real Time Command Function executes all real time comniands which come to the CMDPROC CSC. If the real time command is for the CMDPROC CSC, it is executed upon receipt. If an internal command is addressed to another CSC, the CMDPROC will route the command to the appropriate CSC. External commands are routed to the CSC that provides external bus interface services.

The CMDPROC CSC Stored Command Function manages the storage of command scripts and executing these scripts from within DSPSE memory. These scripts, which are stored in the 'Script and Rule' partition, are executed by ground command or based on scheduled timers.

The CMDPROC CSC Inference Engine Function supports special processing (such as commanding) in response to events which can occur during DSPSE operations. The events and the actions taken in response to the events are defined by rules. The events that can be monitored by rules include such things as interrupts, telemetry values, or command execution.

3.2.3.2

TBD

CMDPROC CSC External Interface Requirements

3.2.3.3 CMDPROC CSC Capability Requirements

3 .2. 3. 3 .1 Real Time Commands

3. 2. 3. 3 .1.1. Real Time Command In put

FSI_ The CMDPROC CSC Real Time Command Function shall accept commands and command data from the C:rviDIN CSC.

3. 2. 3. 3 .1. 2. Real Time Command Processing

FSC_ The C:rviDPROC CSC Real Time Command Function shall execute all physical real time commands.

FSC_ The CMDPROC CSC Real Time Command Function shall execute internal real time commands immediately after the command is received. These commands shall control the following C:rviDPROC CSC functions:

a. Start, initialize, pause, reset, and halt the stored command function.

b. Start, pause, and halt the inference engine function.

c. Stop a currently scheduled/executing script.

d. Load, delete, and dump stored command scripts.

e. Load, delete, and dump stored rules.

f. Load, delete, modify, and dump database records.

g. Select C&T database.

h. Configure Tuning/Strategy{frace Parameters ..

14

FSC_ The CMDPROC CSC Real Time Command Function shall process real time commands with priority over the processing of any stored command scripts, and event driven commands.

FSC_ The CMDPROC CSC Real Time Command Function shall process all pending real time commands before any stored command scripts, or event driven command processing is resumed.

FSC_ The CMDPROC CSC Real Time Command Function shall not interrupt the processing of an individual stored command instruction, but rather shall accept and process the real time command when the stored command instruction has completed execution.

FSC_ The CMDPROC CSC Real Time Command Function shall accept script and rule uploads at the DSPSE uplink data rate.

FSC_ The CMDPROC CSC Real Time Command Function shall accept C&T database uploads at the DSPSE uplink data rate.

3. 2. 3. 3 .1. 3. Reill Time Command Output

FSI_ The CMDPROC CSC Real Time Command Function shall distribute the real time commands in the order that they are received.

FSI_ The CMDPROC CSC Real Time Command Function shall distribute internal commands to the appropriate CSCs within the DSPSE.

FSI_ The CMDPROC CSC Real Time Command Function shall forward external commands to the appropriate data distribution esc.

3.2.3.3.2 Stored Commands

3.2.3.3.2.1. Stored Command Input

FSI_ The CMDPROC CSC Stored Command Function shall retrieve stored commands and command data from the Script and Rule Partition in DSPSE processing equipment memory .

. 3.2.3.3.2.2. Stored Command Processing

FSC_ The CMDPROC CSC Stored Command Function shall interprete scripts which include commands and control instructions that:

FSC_

FSC_

a. Control execution flow;

b. Issue a script call, transferring control to that script and then returning upon completion;

c. Delay, wait, pause, or halt script execution;

d . Synchronize with another script;

e. Schedule a script for independent execution;

f. Evaluate a rule;

The CMDPROC CSC Stored Command Function shall execute all physical stored commands.

The CMDPROC CSC Stored Command Function shall execute a stored script when a command is received instructing the CMDPROC CSC to execute the script.

15

FSC_

FSC_

FSC_

The CMDPROC CSC Stored Command Function .. ·shall schedule a stored command script for execution based on a specified delta time relative to the spacecraft time standard.

The CMDPROC CSC Stored Command Function shall schedule a stored command script for execution on an absolute time basis with respect to the spacecraft time standard.

The CMDPROC CSC Stored Command Function shall begin executing the stored command script no sooner than the specified execution time and no later than TBD milliseconds following the specified time referenced to the spacecraft time standard.

The C:MDPROC CSC Stored Command Function shall support the concurrent execution of -qp to eight stored command scripts.

3.2.3�3.2.3.

FSI_

Stored Command Output

The CMDPROC CSC Stored Command Function shall distribute commands contained within a stored command script in the order in which they appear in the script.

FSI_

FSI_

3.2.3.3.3

The CMDPROC CSC Stored Command Function shall distribute internal commands to the appropriate CSCs within the DSPSE processing equipment that is executing the CMDPROC CSC.

The CMDPROC CSC Stored Command Function shail shall forward external commands. to the appropriate data distribution esc.

Event Driven Commands

3.2.3.3.3.1. Event Driven Command Input

FSI_

FSI_

FSI_

FSI_

3.2.3.3.3.2.

FSC_

The CMDPROC CSC Inference Engine Function shall accept interrupt event notifications from interrupt service routines.

The CMDPROC CSC Inference Engine Function shall accept telemetry event notifications from the 1LMPROC CSC Telemetry Reduction Function.

The CMDPROC CSC Inference Engine Function shall obtain mission constraint rule information from the C&T database during logical command processing.

The CMDPROC CSC Inference Engine Function shall obtain commanding event information from P1e C&T database during logical command processing.

Event Driven Command Processing

The CMDPROC CSC Inference Engine Function shall process rules in response to events. These events shall include the following:

a. External interrupts;

b . Occurrence of a particular value for a discrete telemetry item in the C&T database;

c. Occurrence of a value within a defined range for an analog telemetry item in the C&T database;

d . Occurrence of a logical command being processed by CMDPROC CSC;

16

FSC_ The CMDPROC CSC Inference Engine Function shall process rules which are composed of two parts: the premise and the action. If an item in the premise

. changes, the CMDPROC CSC Inference Engine Function shall evaluate the condition specified in the premise of the rule. If the premise condition evaluates to true, the action portion of the rule shall be scheduled.

FSC_

FSC_

FSC_

FSC_

The CMDPROC CSC Inference Engine Function shall support a priority ordered queue to process the rules scheduled.

The CMDPROC CSC Inference Engine Function shall execute scheduled rules in order of highest priority to lowest priority. Any stored command script scheduled from a rule action shall be processed in accordance with the normal stored command script scheduling algorithm.

The CMDPROC CSC Inference Engine Function shall evaluate mission constraints in the mission constraint rule list of a command database record prior to di stribution whenever the command is processed. If a mission constraint rule evaluates to true, the action specified in the mission constraint rule is executed. The command being processed can be rejected in the action. If a command is rejected by a mission constraint rule, the command shall not be executed.

The CMDPROC CSC Inference Engine Function shall execute rules with the priority assigned at the time the rule was defined.

3.2.3.3.3.3. Event Driven Command Output

FSI_ The CMDPROC CSC Inference Engine Function shall distribute commands contained within a rule in the order in which they appear in the rule.

FSI_ The CMDPROC CSC Inference Engine Function shall distribute internal commands to the appropriate CSCs.

FSI_ The CMDPROC CSC Inference Engine Function shall forward external commands to the appropriate data distribution esc.

3.2.3.3.4 Command Output Procedures

1BD

3.2.3.4

FSE_

FSE_

FSE_

3.2.3.4.1

3.2.3.4.1.1.

FSE

CMDPROC CSC Data Elements

The CMDPROC CSC Command And Telemetry database shall reside in the C&T database partition in the DSPSE global memory.

The CMDPROC CSC Command And Telemetry database shall define the individual logical command actuators that the CMDPROC CSC will control.

The CMDPROC CSC Command And Telemetry database records that support mission constraint rule lists shall allocate space for a list of mission constraint rule identifiers.

Command Record Descriptor

Command Record Fields

The Command And Telemetry Database command record descriptor shall include the following data fields:

a. Record type;

17

b. Run time flags;

c. Mission constraints rule list pointer;

d. Forward rule list pointer;

e. Backward rule list pointer;

f. Serial data word storage;

g. Serial data parity or discrete command level indicator;

h. Address of the command interface;

i. Command interface channel number;

j. Output driver ID;

3.2.3.4.1.2. Command Record Size

The command record descriptor is expected to have a nominal size of 26 by tes. The nominal · record size is provided to aid in determining DSPSE memory requirements. The size may vary to

accommodate processor word alignment requirements and the addition or deletion of data fields.

3.2.4 TELEMETRY PROCESSING (TLMPROC) CSC

3.2.4.1 TLMPROC CSC Description

The TLMPROC CSC is required to perform the telemetry monitoring functions for the DSPSE. More specifically, the TLMPROC CSC provides the telemetry acquisition, telemetry reduction, and telemetry logging.

The TLMPROC CSC telemetry requirements are divided into three functional areas for the purpose of defining the functional and performance characteristics:

a. Telemetry Acquisition Function; b . Telemetry Reduction Function; c. Telemetry Logging Function;

3.2.4.1.1 Telemetry Functions

The TLMPROC CSC Telemetry Acquisition Function acquires data from the DSPSE analog to digital converters and discrete telemetry interface. The acquisition function routes the collected telemetry data to the Telemetry Reduction function of the TLMPROC CSC and to the TLMOUT esc.

The TLMPROC CSC Telemetry Reduction Function processes the telemetry data collected by the acquisition function so the data can be used by the CMDPROC CSC. The Telemetry Reduction Function filters the telemetry data by removing unchanging data.

The TLMPROC CSC Telemetry Logging Function provides the capability to store telemetry data on board the DSPSE space vehicle for delayed transmission to a ground support facility.

3.2.4.2

1BD

TLMPROC CSC External Interface Requirements

18

3.2.4.3 TLMPROC CSC Capability Requirements

The.lLMPROC CSC shall collect, process, and store telemetry data according to the following requirements.

3.2.4.3.1

3.2.4.3.1.1.

FSI_

3.2.4.3.1.2.

FSC_

FSC_

3.2.4.3.1.3.

FSI_

FSI_

3.2.4.3.2

3.2.4.3.2.1.

FSI_

FSI_

Telemetry Acquisition

Telemetry Acquisition Input

The Telemetry Acquisition function shall accept telemetry data from the DSPSE analog to digital converters and digital data interfaces.

Telemetry Acquisition Processing

The Telemetry Acquisition function shall be capable of sampling 128 analog telemetry items per second.

The Telemetry Acquisition function shall be capable of sampling 128 bits of digital telemetry data per second.

Telemetry Acquisition Output

The Telemetry Acquisition function shall output telemetry data to the Telemetry Reduction function of the TLMPROC CSC.

The Telemetry Acquisition function shall output telemetry data to the TLMOUT esc

Telemetry Reduction

Telemetry Reduction Input

The TLMPROC CSC Telemetry Reduction Function shall accept telemetry data from the analog to digital converters, discrete telemetry input devices, and serial telemetry physical devices that are a part of the processing equipment that is executing the TLMPROC CSC.

The TLMPROC CSC Telemetry Reduction Function shall accept telemetry data which includes data produced by other CSCs executing within the processing equipment that is executing the TLMPROC CSC.

FSI_ The TLMPROC CSC Telemetry Reduction Function shall accept telemetry data which includes data produced by other subsystems that are external to the processing equipment that is executing the TLMPROC CSC.

FSI_ The TLMPROC CSC Telemetry Reduction Function shall accept and process telemetry data at a minimum rate of TBD bits per second.

3.2.4.3.2.2. Telemetry Reduction Processing

The TLMPROC CSC Telemetry Reduction Function shall process each telemetry item by doing the following:

FSC_ The TLMPROC CSC Telemetry Reduction Function shall query the C&T database to determine the value of the reject flag. If the flag is set, the telemetry item shall be discarded without further processing.

-

19

FSC_

FSC_

FSC_

FSC_

For telemetry logging .purposes, the. TLMPROC CSC Telemetry Reduction Function shall query the C&T database to determine if the item is selected for entry in the telemetry storage log. If the item is a candidate for logging, the TLMPROC CSC Telemetry Reduction Function shilll compare it to the previously stored value in the database to determine if a significant change has occurred based on the Telemetry Log Aperture in the C&T database. If a significant change has occurred, TLMPROC CSC Telemetry Reduction Function shall center the Telemetry Log Aperture about the new value and route the telemetry item to the TLMPROC CSC Telemetry Logging Function. If a significant change has not occurred the item will not be entered in the Telemetry Storage Log.

For telemetry data filtering purposes, the TLMPROC CSC Telemetry Reduction Function shall compare the received raw value for the specified item to the previous raw value for a significant change. The Change Detection Aperture from the C&T Database shall be used to evaluate for significant change.

The TLMPROC CSC Telemetry Reduction Function shall, if a significant change has not occurred, discard the item with no further processing.

The TLMPROC CSC Telemetry Reduction Function shall, if a significant change has occurred, store the new value in the C&T database telemetry record and shall notify the CMDPROC CSC of such event

FSC_ The TLMPROC CSC Telemetry Reduction Function shall, if the telemetry item is an analog, convert the value to engineering units using the coefficients specified by the C&T Database record for that item. The TLMPROC CSC Telemetry Reduction Function shall store the value in engineering units in the database record.

FSC_ The TLMPROC CSC Telemetry Reduction Function shall evaluate the alarm limit values if they exist in the C&T database for all analog telemetry items. The resulting alarm state, if any, shall be stored in the database record.

3.2.4.3.2.3. Telemetry Reduction Output

FSI_ The TLMPROC CSC Telemetry Reduction Function shall output telemetry data to the Telemetry Logging Function of the TLMPROC CSC.

FSI_ The TLMPROC CSC Telemetry Reduction Function shall send telemetry event notifications to the CMDPROC CSC whenever a monitored telemetry sensor changes value significantly.

3.2.4.3.3 Telemetry Logging

3.2.4.3.3.1. Telemetry Logging Input

FSI_ The TLMPROC CSC Telemetry Logging Function shall receive telemetry data from the TLMPROC CSC Telemetry Reduction Function.

3.2.4.3.3.2. Telemetry Logging Processing

FSC_ The TLMPROC CSC Telemetry Logging Function shall maintain a telemetry storage log which resides in memory accessible to the DSPSE processing equipment.

FSC_ The TLMPROC CSC Telemetry Logging Function shall store normalized telemetry data in the telemetry storage log.

20

FSC_ The TLMPROC CSC Telemetry Logging Function shall, as a default, terminate the storage of telemetry data when storage space is exhausted.

3.2.4.3.3.3. Telemetry Logging Output

FSI_

FSI_

3.2.4.4

FSE_

FSE_

FSE_

FSE_

3.2.4.4.1

3.2.4.4.1.1.

FSE_

The TLMPROC CSC Telemetry Logging Function shall periodically output a telemetry message indicating the status of the Telemetry Log. This message shall indicate whether telemetry logging is currently active and whether the partition is full.

The TLMPROC esc Telemetry Logging Function shall output the contents of the Telemetry Log to the TLMOUT CSC.

TLMPROC CSC Data Elements

The TLMPROC CSC Command And Telemetry database shall reside in the C&T database partition in the DSPSE global memory.

The TLMPROC esc Command And Telemetry database shall define the individual telemetry sensors that the TLMPROC CSC is to be responsible for moiritoring.

The Command and Telemetry ·database records shall support forward and backward rule lists.

The TLMPROC CSC Command and Telemetry database records that support forward and backward rule lists shall allocate space for a list of rule identifiers. A database item's forward rule list shall include the identifiers of each rule that references the database item in its premise.

Analog Record Descriptor

Analog Record Fields

The Command And Telemetry Database analog record descriptors shall include the following data fields:

a. Record type;

b . Run time flags;


d. Forward rule list pointer;


f. Bit length of item;

g. Engineering value storage;

h. Telemetry Reduction option flags;

i. Alarm level indicator;

J. Engineering unit conversion coefficient group ID;

k. Raw value storage;

1. 'Center' value storage;

m. Change detection aperture;

n. Telemetry logging aperture;

21

o. Alann limits.

3.2.4.4.1.2. Analog Record Size

Analog record descriptors are expected to have a nominal size of 76 bytes. The nominal record size is provided to aid in determining DSPSE memory requirements. The size may vary to accommodate processor word alignment requirements and the addition or deletion of data fields.

3.2.4.4.2

3.2.4.4.2.1.

FSE_

3.2.4.4.2.2.

Discrete Record Descriptor

Discrete Record Fields

The Command And Telemetry Database discrete record descriptor shall include the following data fields:

a. Record type;

b. Run time flags;


d. FoiWard rule list pointer;


f. Bit length of item;

g. Current value storage;

h. Telemetry Reduction option flags;

i. Alarm level indicator.

Discrete Record Size

Discrete record descriptors are expected to have a nominal size of 24 bytes. The nominal record size is provided to aid in determining DSPSE memory requirements. The size may vary to accommodate processor word alignment requirements and the addition or deletion of data fields.

3.2.4.4.3 Derived Record Descriptor

3. 2. 4. 4. 3 .1. Derived Record Fields

FSE_ The Command And Telemetry Database derived record descriptor shall include the following data fields:

a. Record type;

b. Run time flags;


d. FoiWard rule list pointer;


f. Current value storage (2 words);

g. Telemetry Reduction option flags;

h. Alarm level indicator.

22

3.2.4.4.3.2. Derived Record Size

Derived record descriptors are expected to have a nominal size of 26 bytes. The nominal record size is provided to aid in determining DSPSE memory requirements. The size may vary to accommodate. processor word alignment requirements and the addition or deletion of data fields.

3.2.5 COMMAND INPUT (CMDIN) CSC

3.2.5.1 CMDIN CSC Description

The CMDIN CSC accepts and validates uplink data from the link interface hardware. Valid uplink data are routed to the CMDPROC CSC for functional processing. Uplink data that does not pass validation tests are discarded.

3.2.5.2

1BD

CMDIN CSC External Interface Requirements

3.2.5.3 CMDIN CSC Capability Requirements

3.2.5.3.1 CMDIN Inputs

The CMDIN shall accept uplink data received via the link interface hardware in accordance with the specifications identified in the Hardware/Software Interface Control Document.

3.2.5.3.2 CMDIN Processing

CMDIN shall validate uplink data. Uplink data validation shall consist of (1) verifying that a proper authenticate count has been received and (2) verifying that the uplink data are error free using the error detection data contained within the uplink data. If uplink data can not be validated, the CMDIN shall discard it and report the event in the downlink telemetry.

The authenticate count shall be validated by comparing the count contained in the uplink data with the count contained in a non-volatile 32-bit register that is used to store the expected authenticate count.

If the count received in the message matches the register, the count shall be considered validated. If the received count and the register do not match the command shall be considered invalid.

C:MDIN shall increment the authenticate count register each time uplink data is validated.

The authenticate count register shall be initialized in TBD manner.

The error detection code shall be validated in TBD manner.

CMDIN shall maintain TBD status information for inclusion in the housekeeping telemetry.

3.2.5.3.3 CMDIN Outputs

CMDIN shall output validated uplink data to the CMDPROC CSC for functional processing.

23

3. 2. 6 Telemetry Output (TLMOUT) CSC

3.2.6.1 TLMOUT CSC Description

The TLMOUT CSC formats telemetry data received from the TLMPROC and CMDPROC CSC and then outputs the data to the housekeeping telemetry interface hardware.

3.2.6.2

TBD

TLMOUT CSC External Interface Requirements

3.2.6.3 TLMOUT CSC Capability Requirements

3.2.6.3.1 TLMOUT Inputs

TLMOUT shall receive raw telemetry data packets from the TI...MPROC CSC.

TLMOUT shall receive internal telemetry data packets from the TLMPROC CSC. Internal telemetry data consists of derived or status telemetry items that are generated by other DSPSE CSCs.

TLMOUT shall receive internal telemetry data packets from the CMDPROC CSC.

3.2.6.3.2 TLMOUT Processing

· TLMOUT shall format the telemetry data packets into housekeeping telemetry frames for incorporation into the downlink telemetry. The format of the housekeeping telemetry frames shall be specified in the TBD document.

Each housekeeping telemetry frame shall include a 16-bit frame synchronization pattern.

Each housekeeping telemetry frame shall include a frame counter.

Each housekeeping telemetry frame shall include the current uplink status.

Each housekeeping telemetry frame shall include the current spacecraft time.

The current authenticate count shall be included in each housekeeping telemetry frame.

The housekeeping telemetry frame shall include a frame counter.

3.2.6.3.3 TLMOUT Output

TLMOUT shall output housekeeping telemetry frames to the link interface hardware in accordance with the specification contained in the Hardware/Software Interface Control I;Jocwnent.

·

3.2. 7 Guidance, Navigation, & Control (GNC) Executive Capability Requirements

The GNC Executive coordinates requests for attitude control and pointing; generates desired spacecraft attitude; if enabled, schedules attitude control based on on-board estimates of spacecraft position and mission phase; and monitors reaction wheel status for momentum dumping.

24

3.2.7.1 GNC Executive Input Requirements

The GNC Executive shall accept the following external stimuli:

FSI_ Attitude control mode request (from ground)

FSI_ Pointing direction (from ground)

FSI_ Autonomous scheduling enable/disable (from ground)

FSI_ Mission phase (from ground)

FSI_ Reaction wheel speed

FSI_ Flags for translunar rocket bum and separation

The GNC Executive shall accept the following internal stimuli:

FSI_ Line-of-sight vectors and rates from spacecraft to earth, sun, and moon (from Navigation Function)

FSI_

FSI_

FSI_

FSI_

FSI_

3.2.7.2

FSC_

FSC_

FSC_

FSC_

Attitude control mode request and pointing direction (from Navigation, Delta V Control, or Terminal Guidance and Control Functions)

Slew maneuver request (from Terminal Guidance and Control Function)

Attitude control jet firing durations (from Attitude Control Function)

Delta V thruster firing durations (from Delta V Control Function)

Imaging flag, sensor imaging or not (from Sensor Processing and Control Function)

GNC Executive Processing Requirements

The GNC Executive shall process all attitude control mode requests. Mode switching logic shall be that shown in Figure TBS. Requests which would result in an illegal mode transition shall be ignored but their occurrence shall be reported as an error message in the telemetry at the earliest possible time.

The GNC Executive shall modify attitude control parameters, e.g. gains, as necessary for mode changes and changes to spacecraft inertial properties. Updated estimates of spacecraft mass, e.g., and moments of inertia shall be maintained from: firing of the translunar rocket; separation of the spent rocket; firing of the attitude control jets; and firing of the delta V thruster.

The GNC Executive shall monitor reaction wheel speed to determine he need for momentum dumping or failure of a reaction wheel. Momentum dumping shall be done when either of the following conditions is met:

a. The speed of any one reaction wheel exceeds TBD while the attitude control mode is one of the following: TBD.

b. The speed of any one reaction wheel exceeds TBD while the attitude control mode is one of the following: TBD. Note: the speed limit for a will be smaller than for b but will have a more restrictive set of control modes.

If a reaction wheel failure is detected by TBD logic or indicated by the ground, a flag shall be set so that the Attitude Control Function is aware of the failure and the event shall be reported as an error message in the telemetry as soon as possible.

25

FSC_

FSC_

FSC_

3.2.7.3

The GNC Executive shall supply the desired attitude and rate to the Attitude Control Function except when the attitude control mode is Active Nutation Control, Despin, or Lifeboat.

When the capability is enabled, the GNC Executive shall schedule the attitude control modes passed on the Spacecraft/Earth/Sun/Moon geometry and the mission phase. This logic is TBD.

The GNC Executive Function shall be perfoniled TBD times per second.

GNC Executive Output Requirements

The GNC Executive shall generate the following external stimuli:

FSI_ Error messages (to telemetry)

The GNC Executive shall generate the following internal stimuli:

FSI_ Attitude control mode (to Attitude Control, Attitude Determination, Delta V

Control, and Solar Array Control Functions)

FSI_

FSI_

FSI_

Desired attitude and rate (to Attitude Control Function)

AttitUde control parameters (to Attitude Control Function)

Reaction wheel failure flags (to Attitude Control Function)

3.2.8 Attitude Determination Capability Requirements

The Attitude Determination Function uses data from the IMU and star tracker to estimate spacecraft attitude; during spin-stabilized flight, it estimates spin rate and nutation.

3.2.8.1 Attitide Determination Input Requirements

The Attitude Determination shall accept and process the following external stimuli:

FSI_ Delta rotation data (from IMU)

The Attitude Determination shall accept and process the following internal stimuli:

FSI_ Attitude control mode (from GNC Executive Function)

FSI_ Star tracker data: image tim�, star locations in sensor frame, star intensities, and star tracker ID (from Sensor Processing and Control Function)

3.2.8.2

FSC_

Attitide Determination Capability Requirements

Attitude Determination shall process IMU and star tracker data at the frequencies h . th fi ll . bl s ownm e o oWing ta e.

Attitude Control Mode IMU Rate (Hz) Star Tracker Rate (Hz)

Spin Up TBD TBD

Active Nutation Control 50 N/A

Spinning TBD TBD

De spin TBD TBD

Acquisition TBD TBD

Earth Pointing TBD TBD

26

Sun Pointin_g_ TBD TBD

Moon Pointing TBD TBD

Asteroid Pointing TBD '

TBD

Slew TBD N/A

Delta V Pointing TBD TBD

Arbitrary Pointing_ TBD TBD

Momentum Dump TBD TBD

Lifeboat

FSC_

FSC_

FSC_

FSC_

3.2.8.3

TBD TBD

The llv1U data shall be processed to estimate spacecraft angular velocity relative to inertial space (3 components in spacecraft- fixed frame) and attitude relative to TBD inertial frame (quaternions).

Star locations and intensities shall be correlated with an internal star catalog to determine sensor attitude at the time the image was taken. Sensor attitude shall be

converted to spacecraft attitude according to which star tracker was used to collect the data.

The star tracker data shall be used to update the attitude and gyro drift estimates. As the star tracker data will defme attitude as it was some short time ago, it shall be

necessary to maintain asuitable time history of attitude estimates. Upon completion of astar tracker attitude estimate, that estimate shall be compared with the appropriate value from the time history. H the difference is within TBD limit, the current estimate will be updated by TBD logic. H the difference exceeds the limit, the star tracker estimate will be ignored and an error message will be output to the telemetry.

After entering the Despin Mode, the estimated attitude will be reset to that obtained from the star tracker as soon as the total angular velocity is less than TBD.

Attitide Determination Output Requirements

The Attitude Determination shall generate the following external stimuli:

FSI_ Attitude, body-fixed rates, and gyro drifts (to telemetry)

FSI_ Error messages (to telemetry)

The Attitude Determination shall generate the following internal stimuli:

FSI_ Attitude (to Attitude Control, Terminal Guidance and Control, Delta V Control, Sensor Processing and Control, and Solar Array Control Functions)

FSI_ Body-fixed rates (to Attitude Control Function)

FSI_

3.2.9

Star tracker data request (to Sensor Processing and Control Function)

Attitude Control Capability Requirements

The Attitude Control Function operates reaction wheels and control jets to control spacecraft attitude in a variety of different attitude control modes. Various modes satisfy different mission requirements.

27

3.2.9.1 Attitide Control Inputs

The Attitude Control shall accept the following external stimuli:

Non�

The GNC Executive shall accept the following internal stimuli:

FSI Attitude control mode (from GNC Executive Function)

FSI

FSI

FSI

FSI_

FSI_

3.2.9.2

FSC_

FSC_

FSC_

FSC_

FSC_

FSC_

FSC_

FSC_

FSC_

FSC_

FSC_

FSC_

FSC_

Attitude and body-fixed rates (from Attitude Determination Function)

Desired attitude and rates (from GNC Executive Function)

Spin rate, nutation angle, and phasing (from Attitude Determination Function)

Attitude control parameters, e.g. gains (from GNC Executive Function)

Reaction wheel failure flags (from GNC Executive Function)

Attitide Determination Capability Requirements

Attitude Control Processing shall execute the attitude control laws for each of the control modes described below.

Spin Up: Spins the spacecraft in preparation for the translunar rocket firing. Desired spin axis is along spacecraft longitudinal axis. Spin orientation in inertial space will be defmed by upload from ground. Control is via attitude control jets.

Active Nutation Control: Reduces nutation after spaccecraft has been spun up but before firing the translunar rocket Control is via attitude control jets.

Spinning: No active control during translunar rocket firing.

Despin: Recover from spin stabilized mode or launch vehicle tip-off rates. Goal is zero angular rotation rate. Control is via attitude control jets and/or reaction wheels depending on magnitude of initial rates.

Acquisition: Initial attitude acquisition after launch; recover from spin stabilization; or large attitude transition (e.g. from Earth Pointing to Sun Pointing). During attitude transitions, the TBD axis of the spacecraft shall not be pointed within TBD degrees of the sun. Control will be via the reaction wheels.

Earth Pointing: the high gain antenna is pointed at the center of the earth. Control is via the reaction wheels.

Sun Pointing: the TBD axis of the spacecraft is pointed at the sun. Control is via the reaction wheels.

Moon Pointing: the TBD axis of the spacecraft is pointed at the center of the moon. Control is via the reaction wheels.

Asteroid Pointing: the TBD axis of the spacecraft is pointed at the asteroid. Control is via the reaction wheels.

Slew: used during the asteroid flyby to rapidly repoint the sensors after the time of closest approach. Control is via the control jets.

Delta V Pointing: controls spacecraft attitude during firing of the delta V thruster. Control is via the attitude control jets.

Arbitrary Pointing: points the spacecraft in an arbitrary, ground commanded, direction. Control is via the reaction wheels.

28

FSC_

FSC_

FSC_

Momentum Dump: despins reaction wheels by firing attitude control jets to generate opposing torques while maintaining spacecraft attitude. Dump is complete when all reaction wheel speeds are below TBD.

Lifeboat: quasi inactive mode which is used to preserve resources (power and control jet fuel). Body axis rates are maintained between broad limits of: TBD.

If a reaction wheel failure is indicated, the control logic shall utilize the corresponding control jet instead.

3.2.9.3 Attitide Control Output Requirements

The Attitude Control shall generate the following external stimuli:

FSI_ Reaction wheel speed increase/decrease commands

FSI_ Attitude control jet on/off commands

The Attitude Control shall generate the following internal stimuli:

FSI_ Control jet firing duration (to GNC Executive Function)

3.2.10 Autonomous Navigation Capability Requirements

The Navigation Function propagates the spacecraft orbit from an uploaded epoch; determines lineof-sight vectors from the spacecraft to the earth, sun, and moon; and does autonomous navigation processing.

3.2.10.1 Autonomous Navigation Input Requirements

The Autonomous Navigation shall accept the following external stimuli:

FSI_ Spacecraft epoch (from ground)

FSI_ Autonomous navigation enable/disable flag (from ground)

The Autonomous Navigation shall accept the following internal stimuli:

FSI_ Actual achieved delta V (from Delta V Control Function)

FSI_

FSI_

3.2.10.2

FSC_

FSC_

FSC_

Autonomous navigation measurement (from Sensor Processing and Control Function)

Asteroid position update (from Terminal Guidance and Control Function)

Autonomous Navigation Processing Requirements

The spacecraft and asteroid orbits shall be propagated from epochs supplied by the ground and possibly modified by the Terminal Guidance and Control Function. The spacecraft orbit shall be corrected for all actual delta V maneuvers. Positions of the earth, sun, and moon shall be computed from TBD algorithms.

LOS vectors and rates from spacecraft to earth, sun, and moon shall be computed.

The autonomous navigation subfunction shall have 3 states: disabled; test; and enabled. In the disabled state, no autonomous navigation calculations shall be done. In the test or enabled state, the autonomous navigation algorithms will be computed and in the enabled state, the results shall be incorporated into the onboard estimate of spacecraft ephemeris.

29

FSC_ he autonomous navigation subfunction shall determine the type of sensor measurement it wants and the specific sensor it wants to make the measurement. The measurements will be the angular separation between a star specified by this function and either the lunar limb, lunar centroid, or earth centroid. Once a measurement has been identified, autonomous navigation shall request an attitude change to point the spacecraft in the proper direction. After the spacecraft has stabilized in that direction, autonomous navigation shall issue a request for the measurement Upon receipt of the measurement it shall cancel its attitude request.

3.2.10.3 Autonomous Navigation Output Requirements

The Autonomous Navigation shall generate the following external stimuli:

FSI_ Spacecraft position and velocity in TBD inertial frame (to telemetry)

FSI_ Autonomous navigation estimates of position and velocity (to telemetry)

The Autonomous Navigation shall generate the following internal stimuli:

FSI_ LOS vectors and rates from spacecraft to earth, sun, and moon (to the GNC Executive and the Sensor Processing and Control Functions)

FSI_ Spacecraft/sun LOS (to Solar Array Control Function)

FSI_ Attitude mode request and desired attitude (to GNC Executive Function)

FSI_ Autonomous navigation measurement request (to Sensor Processing and Control Function)

3. 2.11 Terminal Guidance and Control Capability Requirem�nts

Terminal Guidance and Control Function includes all special processing associated with the asteroid flyby. Initial calculations will be based on an upload from the ground of the relative spacecraft/asteroid position and velocity. When the spacecraft gets close enough to detect the asteroid on its sensors, the spacecraft/asteroid relative motion estimates will be updated. This will result in an update to the spacecraft pointing to track the asteroid.

As the spacecraft nears the asteroid, the LOS rates may become too great for the spacecraft to maintain pointing. If this happens, this function will command a slew maneuver which produce a rapid spacecraft rotation such that the asteroid image can be recaptured after the closest approach.

This same function can be used to track the upper stage after separation by uploading the appropriate relative position and velocity estimate. The primary difference is that the relative range will always be increasing and the slew maneuver will be unnecessary.

3.2.11.1 Terminal Guidance and Control Input Requirements

The Terminal Guidance and Control shall accept the following external stimuli:

FSI_ Target relative position and velocity (from ground)

FSI_ Autonomous operations enable/disable (from ground)

The Terminal Guidance and Control shall accept the following internal stimuli:

FSI_ Target location (from Sensor Processing and Control Function)

FSI_ Attitude (from Attitude Determination Function)

30

3 . 2.11.2

FSC_

FSC_

3.2.1 1.3

Terminal Guidance and Control Processing Requirements

A simple propagator shall be used to predict the target relative motion. When the estimated range reaches TBD, a request for sensor racking of the target shall be issued. When such tracking data is received, it shall be used to update the relative motion estimator.

Predictions shall be made of the maximum angular rates andaccelerations to be expected as the spacecraft passes the target. If the rates or accelerations will exceed the spacecraft capabilities, a slew maneuver shall be commanded. The slew maneuver shall be computed so that the target can be reacquired after the closest approach and that the non-tracking portion of the flyby shall be equally space before and after the closest approach.

Terminal Guidance and Control Output Requirements

The Terminal Guidance and Control shall generate the following external stimuli:

PSI_ Reports of autonomous operations (to telemetry)

The Terminal Guidance and Control shall generate the following internal stimuli:

PSI_ Request for target data (to Sensor Processing and Control Function)

PSI_ Attitude mode request and desired attitude (to GNC Executive Function)

PSI_ Slew maneuver request (to GNC Executive Function)

3 .2.12 Sensor Control and Data Processing Requirements

This function provides the interface to all the imaging sensors. It activates the sensors to collect an image and, if requested by another function, processes that image to extract celestial objects (stars and the asteroid) or make autonomous navigation measurements. If enabled, it monitors image intensity and controls camera gain. It also passes filter wheel position commands on to the sensors. ·

3.2.12.1 Sensor Control and Data Processing Input Requirements

The Sensor Control and Data Processing shall accept the following external stimuli:

PSI_ Filter wheel position commands (from the ground)

FSI_ Automatic gain control enable/disable (from the ground)

PSI_ Manual camera gain settings (from the ground)

FSI_ Requests for image data (from scheduler)

PSI_ Camera image data (from sensors)

The Sensor Control and Data Processing shall accept the following internal stimuli:

PSI_ Star tracker data request (from Attitude Determination Function)

FSI_ Autonomous navigation data request (from Navigation Function)

PSI_ arget data request (from Terminal Guidance and Control Function)

FSI_ Spacecraft to sun, earth, and moon LOS vectors (from Navigation Function)

PSI_ Attitude (from Attitude Determination Function)

31

3.2.12.2

FSC_

FSC_

FSC_

FSC_

FSC_

FSC_

FSC_

FSC_

3.2.12.3

Sensor Control and Data Processing Processing Requirements

Upon request for data from a particular sensor, that sensor shall be commanded to collect an image. As soon as image data is available, it shall be processed to provide the desired outputs as identified below:

Star tracker data request: positions in sensor coordinates of 5 brightest stars; intensities; and star tracker ID

Autonomous navigation data request: angle between specified star and either the lunar limb, lunar centroid, or earth centroid as specified in the request

Target data request: target intensity and position in sensor coordinates.

If the image request was for star tracker data but did not indicate which of the two star trackers to use, this function shall select the star tracker whose FOV is less obscured by the sun, earth, and moon. The logic for this selection is TBD.

When requested to track the asteroid, sensor images shall be obtained at least TBD. As soon as the target can be detected from the star background, the target position shall be reported to the requesting function. Position updates shall be continued at the above rate.

Requests to collect an image, manually set a camera gain, or change filter wheel position shall be passed on to the appropriate sensor.

When automatic gain control is enabled, the image data from that sensor will be processed to adjust the camera gain.

Sensor Control and Data Processing Output Requirements

The Sensor Control and Data Processing shall generate the following external stimuli:

FSI_ Filter wheel position (to sensor and telemetry)

FSI_ Image collection commands

FSI_ Camera gain settings (to sensor and telemetry)

The Sensor Control and Data Processing shall generate the following internal stimuli:

FSI_ Star position and intensity data, star tracker ID (to Attitude Determination Function)

FSI_

FSI_

FSI_

3.2.13

Autonomous navigation measurement (to Navigation Function)

Target position (to Terminal Guidance and Control Function)

Imaging flag, sensors imaging or not (to GNC Executive and Solar Array Control Functions)

Delta V Control Requirements

This function controls all delta V maneuvers except the translunar injection which is done with a solid rocket. All other delta V's use a liquid propellant thruster. This function will accomplish delta V maneuvers which are requested by the ground. It will request the attitude control system to point the spacecraft in the proper direction, turn the thruster on, monitor the actual delta V achieved from the IMU accelerometer data, and turn the thruster off. The actual delta V which was achieved is reported in the telemetry.

32

3.2.13.1 Delta V Control Input Requirements

The Delta V Control shall accept the following external stimuli:

FSI_ Delta V maneuver request: magnitude, direction, and time (from ground)

FSI_ IMU accelerometer outputs

The Delta V Control shall accept the following internal stimuli:

FSI_ Attitude control mode (from GNC Executive Function)

FSI_ Attitude (from Attitude Determination Function)

3.2.13.2

FSC_

FSC_

FSC_

3.2.13.3

Delta V Control Processing Requirements

Delta V Control shall initiate an attitude change sufficiently prior to a delta V

maneuver to allow for the attitude to change and stabilize. It shall monitor spacecraft attitude to insure it is within TBD before turning on the delta V thruster.

During the thruster firing, Delta V Control shall monitor the IMU accelerometer outputs and the spacecraft attitude at a TBD rate. Based on a TBD algorithm, it shall modify the commanded spacecraft attitude and turn off the thruster at the proper time so as to achieve the desired velocity correction.

The actual acceleration and attitude time histories shall be reported in the telemetry.

Delta V Control Output Requirements

The Delta V Control shall accept the following external stimuli:

FSI_ Thruster on/off commands

FSI_ Actual delta V: on time, off time, and body-fixed acceleration and attitude time histories (to telemetry)

The Delta V Control shall accept the following internal stimuli:

FSI_ Attitude mode request and desired attitude (to GNC Executive Function)

FSI_ Actual delta V magnitude and direction (to Navigation Function)

FSI_ Thruster firing duration (to GNC Executive Function)

3.2.14 Solar Array Control Capability Requirements

Solar Array Control rotates the solar array to minimize the solar incidence angle. It has two modes: fine and coarse. The fine mode is used when solar array motion will have no adverse effects on the mission and the array rotation is kept within a small tolerance of the optimum. The coarse mode is used when it is desirable not to move the solar array unless the incidence angle is far from the minimum.

3.2.14.1 Solar Array Control Input Requirements

The Solar Array Control shall accept the following external stimuli:

None.

The Solar Array Control shall accept the following internal stimuli:

FSI_ Imaging flag, sensors imaging or not (from Sensor Processing and Control Function)

FSI_ Spacecraft/sun LOS (from Navigation Function)

33

FSI_

FSI_

3.2.14.2

FSC_

FSC_

3.2.14.3

Attitude (from Attitude Determination Function)

Attitude control mode (from GNC Executive Function)

Solar Array Control Processing Requirements

The solar array control mode shall be selected as a function of the imaging flag and the attitude control mode in accordance with the TBD table.

The optimum solar array rotation angle shall be computed from the spacecraft/sun LOS and the spacecraft attitude. If the difference between the optimum and current angles is greater than the TBD (mode dependent) limits, the array shall be commanded to the optimum angle.

Solar Array Control Output Requirements

The Solar Array Control shall generate the following external stimuli:

FSC_ Solar array rotation command

The Solar Array Control shall generate the following internal stimuli:

None

3.2.15 Memory loads and dumps Capability Requirements

A Memory Load and Dump Facility shall be present in the Startup Flight Software. This process shall provide for the loading of the random access memory on-board the satellite. This memory shall be used by the initial software system as the code and data which is to be executed during satellite operations. Also the dumping of data and code memory may be requested via command.

3.2.15.1 Memory Load and Dump Facility Input Requirements

The Memory Load and Dump Facility shall take the following external stimuli :

FSI_ Commands from the Command Interface Subsystem which request either a Memory Dump or a Memory Load of a section of the flight hardware random access memory. (These Commands are TBD, along with Memory Ranges and breakdown ).

FSI_

3.2.15.2

FCI_

FCI_

FCI_

3.2.15.3

Shall receive framed memory blocks which ·are to be placed in memory during a Memory Load Command operation.

Memory Load and Dump Facility Processing Requirements

Shall respond to a Memory Upload Command by computing a checksum of the memory loaded from the command and comparing it with the uploaded checksum value.

·

If the proper checksum is found, then the Memory Loads and Dump Facility will load the requested memory with uploaded memory contents, and indicate success to the Logging Facility.

Shall respond to a Memory Dump Command by computing a checksum of the memory partition which is to be dumped. After the checksum has been found the process shall send to the Telemetry Subsystem the memory contents followed by the checksum to be recorded or transmited.

Memory Load and Dump Facility Output Requirements

The Memory Load and Dump Facility shall provide the following external stimuli :

34

..

FSI_ Error messages to the Logging Subsystem which indicate problems in the memory load or dump process. For example, illegal access, memory failure, etc.

The Memory Load and Dump Facility shall generate the following internal stimuli :

FSI_ A checksum value of the memory data which has been requested to be dumped.

FSI_ Memory contents in response to Dump Command.

3 .2.16 Event Logging and Distribution Capability Requirements

The Event Logging and Distribution Facility shall provide for the receiving a logging of process status, errors, and messages which will be logged and available to be read stored and retreived by the telemetry system. A process may report errors, illegal conditions, or other import status information. Processes may request for certain message types to be routed to them when they occur.

3.2.16.1 Event Logging and Distribution Input Requirements

The Event Logging and Distribution Facility shall take the following external stimuli :

FSI_ Shall receive uplink command which will request a dump of the message log to the downlink system, and will respond by distributing the data to be delivered to the telemetry system.

The Event Logging and Distribution Facility shall take the following internal stimuli :

FSI_ Shall receive message inputs from other processes which are to be logged and distributed.

FSI_

3.2.16.2

FSC_

FSC_

3.2.16.3

Shall receive requests from processes which require notification of specific error types, and will provide for distribution to those processes.

Event Logging and Distribution Processing Requirements

The Event Logging and Distribution Facility will receive messages from the various processes in the Flight software system, will determine the message type, log the message in its memory partition, and do any automatic distribution which is required.

The Event Logging and Distribution Facility will receive message dump commands from the command system, and respond by delivering memory contents to the telemetry system along with a checksum.

Event Logging and Distribution Output Requirements

The Event Logging and Distribution Facility shall provide the following external stimuli :

FSI_ Shall send memory contents and checksum to Telemetry system when a request is made to dump.

The Event Logging and Distribution Facility shall provide the following internal stimuli :

FSI_ Shall send messages to processes which have requested notification of events which have occured and been logged.

3. 2.17 Processor Health and Status Capability Requirements

The Processor Health and Status Facility shall be responsible to monitor the health and status of all flight hardware components to the extent which is possible. The process shall notify the concerned processes and Error Logging Facility of any problems or unusual occurences which

35

are detected. The process shall not impede with the operation of all other flight software processes.

3.2.17 .1 Processor Health and Status Input Requirements

The Processor Health and Status Facility shall take the following external stimuli :

FSI_ Shall receive ON/OFF Configuration command from CommanQ. system process.

FSI_ Shall receive special test request from Command system.

The Processor Health and Status Facility shall take the following internal stimuli :

FSI_ Shall receive special test request from flight software processes.

3.2.17 .2

FSC_

FSC_

FSC_

FSC_

FSC_

3.2.17.3

Processor Health and Status Processing Requirements

The Processor Health and Status Facility shall do a continuous background check of memory, processor, peripherals, timer operation, and any other interface circuits which may be tested, without interference to the other processing modules on board the spacecraft. (EXACT TESTS TBD)

The Processor Health and Status Facility shall respond to a OFF command which will turn off the background checking process and will indicate the activity to the Event Logging system.

The Processor Health and Status Facility shall respond to a ON command which will turn on the background checking process and will indicate the activity to the Event Logging system.

The Processor Health and Status Facility shall respond to special test commands which are received from the Command system in order to verify the operation or non-operation of specific hardware (TBD ). The process will test and notify the Event Log of the results.

The Processor Health and Status Facility shall respond to special test commands which are received from another process in the system in order to verify the operation or non-operation of specific hardware (TBD ). The process will test and notify the Event Log of the results.

Processor Health and Status Output Requirements

The Processor Health and Status Facility shall take the following external stimuli :

FSI_ shall notify the Telemetryt system of any errors in subsystems. (TELEMETRY ITEMS TBD)

The Processor Health and Status Facility shall take the following internal stimuli :

FSI_ Shall notify the Event Log of any events, including errors, special test results, and illegal conditions, which take place during background checking operations.

3.3 CSCI Internal Interfaces

This paragraph shall identify the interfaces between the capabilities identified above. Each internal interface shall be identified by name and project-unique identifier and a brief description of each interface shall be provided, including a summary of the information transmitted over the interface. Internal interface diagrams depicting data flow, control flow, and other relevant information may be used to aid in this description.

36

..

3. 4 CSCI Data Element Requirements

This paragraph shall specify the information identified below, as applicable:

a. For data elements internal to the CSCI:

(1) Assign a project-unique identifier to the data element

(2) Provide a brief description of the data element

(3) Identify the Units of measure required for the data element, such as seconds, meters, kiohertz, etc.

(4) Identify the limit/range of values required for the data element (for constants provide the actual value)

(5) Identify the accuracy required for the data element

(6) Identify the precision or resolution required for the data element in terms of significant digits

(7) For data elements of the CSCis internal interfaces:

Identify the interface by name and project-unique identifier

Identify the source capability of the data element by name and project-unique identifier

Identify the destination capability of the data element by name and project-unique identifier

b. For data elements of the CSCfs external interfaces:

(1) Identify the data elements by project-unique identifier

(2) Identify the interface by name and project-unique identifier

(3) Identify the source or destination capability of the data element by name and project-unique identifier

(4) Reference the Interface Requirements Specification in which the interface is specified

3. 5 Adaption Requirements

This paragraph shall be divided into the following subparagraphs to specify the requirements for adapting the CSCI to site-unique conditions and to change in the system environment.

3.5.1 Installation-dependent Data

This subparagraph shall describe the site-unique data required by each installation. Examples of such data are: site latitude and longitude, radar ranges and areas of coverage, and prescribed safety limits. In addition, this subparagraph shall identify the CSCI capabilities in which these data are used.

3. 5. 2 Operational Parameters

This subparagraph shall describe parameters required by the CSCI that may vary within a specified range according to operational needs. Examples of such data are: allowable trajectory deviations, navigation set model numbers, airplane performance characteristics, interaction/isolation of sorties, missle performance characteristics. This subparagraph shall identify the CSCI capabilities in which these data are used.

37

I

3. 6 Sizing and Timing Requirements

This paragraph shall specify the amount and, if applicable, location of internal and auxiliary memory and the amount of processing time allocated to the CSCI. This paragraph shall specify the resources required of both memory and the central processing unit (CPU) for the CSCI.

3. 7 Safety Requirements

This paragraph shall specify safety requirements that are applicable to the design of the CSCI, with respect to potential hazards to personnel, property, and the physical environment.

3. 8 Security Requirements

This paragraph shall specify security requirements that are applicable to the design of the CSCI, with respect to potential compromise of sensitive data.

3. 9 Design Constraints

This paragraph shall specify other requirements that .constrain the CSCI design, such as the use of a particular processing configuration, etc.

3.10 Software Quality Factors

This paragraph shall be divided into the following subparagraphs, as appropriate to specify each software quality factor identified in the contract or derived from a higher level specification. For each quality factor required, the method of compliance shall be specified along with the requirements for that factor.

3.11 Human Performance/Human Engineering Requirements

This paragraph shall specify the applicable human factors engineering requirements for the CSCI. . These requirements shall include, as applicable, considerations for:

a. Human information processing capabilities and limitations

b . Foreseeable human errors under both normal and extreme conditions

c. Implications for the total system environment (include training, support, and . operational environment)

3.12 Requirements Traceability

This paragraph shall contain mapping of the engineering requirements in this specification to the requirements applicable to this CSCI in the SSS, PIDS, or CIDS. This paragraph shall also provide a mapping of the allocation of the CSCI requirements from the SSS, PIDS, or CIDS to the engineering requirements in this specification.

38

'

4 Qualification Requirements

This section shall be divided into the following paragraphs to specify the qualification methods and any special qualification requirements necessary to establish that the CSCI satisfies the requirements of section 3 and 5.

4. 1 Qualification Methods

This paragraph shall specify the qualification methods to be used to ensure that the CSCI requirements of section 3 and 5 have been satisfied. A table similar to Table 1 may be used to present this information. Qualification methods inclucie:

a. Demonstration. The operation of the CSCI (or some part of the cscn that relies on observable functional operation not requiring the use of elaborate instrumentation or special test equipment

b. Analysis. The processing of accumulated data obtained from other qualification methods. Examples are interpretation or extrapolation of test data.

c. Inspection. The visual examination of CSCI code, documentation, etc.

4. 2 Special Qualification Requirements

This paragraph shall be divided into appropriate subparagraphs to specify special requirements associated with qualification of the CSCI. This paragraph shall identify and describe, if applicable, special tools, techniques (e.g. test formulas, algorithms), procedures, facilities, and acceptance limits. For each special test the following information shall be specified:

a. A project-unique identifier for the test

b. The paragraph number(s) of the capability requirement(s) to which the test applies.

c. A description of the test, such as peak-load stress test for 24 hr. duration

d. The level of test (CSU, CSC, CSCI, segment, or system level).

39

'

/

'- _/

S Preparation for Delivery

This paragraph shall specify the type and characteristics of the delivery media for the CSCI (e.g., 8 track magnetic tape 1600 BPI, 150 megabyte disk). In addition, this section shall specify the labeling, packaging, handling, and classification marldng requirements for the media, including the CSCI name and project-unique identifier. Any unique delivery requirements shall also be specified in this section.

40

)

.,

6 Notes

This section shall contain any general information that aids in understanding this document (e.g., background information, glossary). This section shall include an alphabetical listing of all acronyms, abbreviations, and their meanings as used in this document.

41