Transcript Ground Controller Project

Sponsor & Organization:
Professor Larry Bernstein
SSW 540 Fundamentals of Software Engineering
Stevens Institute of Technology
School of Systems Engineering & Engineering Management
Castle Point on Hudson
Hoboken, NJ 07030
1
Overview
Project Value

The Ground Controller will identify, track, and predict the impact location of a Space
Capsule during its re-entry process to ensure prompt recovery.
Project Description

The Ground Controller operates as a tracking computer for the re-entry of a Space
Capsule.

It consists of one ground-based radar unit for surveillance and capsule detection,
tracking, and impact projection.

It also has a Communications Relay Group for communications support to other systems
that need capsule location and impact prediction.

An Information Coordination Center controls the Ground Controller and coordinates its
operation with other controllers and higher level Space Command Authorities.

The Ground Controller has a Control Computer, which is responsible for performing the
tracking, impact projection, as well as other of the system’s major command and control
functions.

The Ground Controller will execute impact predictions when the Space Capsule
descends from 400,000 feet to 100,000 feet, and a new projection will be computed
every ten (10) seconds.

Recovery ships are deployed based on the Ground Controller’s predictions and they will
use their splash detection radar systems to confirm impact.
2
Overview – Cont.
Project Constraints

The Ground Controller uses equipment originally designed for the Patriot System that protected
against Iraqi Scuds.

The Control Computer used is based on a 1970s design with relatively limited capability to perform
high precision calculations: It cannot compute roots of a function nor invert a matrix. Integration can
only be approximated with finite difference equations, therefore polynomial filters are used for
tracking and surface impact projection.

The Ground Controller will execute impact predictions when the Space Capsule descends from
400,000 feet to 100,000 feet, and a new projection will be computed every ten (10) seconds. The
last six (6) projections are used to smooth the results, so that there is a new projection provided at
least every minute.

The system will use a range-gate algorithm to identify and track the Space Capsule. If the rangegate finds an object within the calculated range-gate area, it confirms that it is a Space Capsule. The
range-gate provides a prediction of where the capsule will next appear as a function of the known
velocity and time of the last radar detection.

To predict where the Space Capsule’s trajectory; time, velocity, and gravity are expressed as real
numbers. Velocity is expressed as a whole number and a decimal. Time is kept continuously by the
system’s internal clock in tenths of seconds, but is expressed as an integer.
Project Directions

The Ground Controller is part of an infrastructure of many Ground Controllers used to identify,
predict, and track Space Capsule re-entry and impact location. The Ground Controller interacts with
an Information Control Center to coordinate with other controllers and other higher level Space
Command Authorities.
3
Measurable Operational Value (MOV)

The Ground Controller will improve Space Capsule impact
location predictions by 90% and increase recovery time by
50%.

The Ground Controller is designed to be a stand-alone unit.
For the intended purpose, it is mounted to a ship, although it
is quite versatile and may be mounted on any sort of
platform.
It has a well designed interface and allows for optimal
interaction from a human operator.
The Ground Controller interacts with an Information Control
Center, which also communicates with network of Ground
Controllers and other higher level Space Command
Authorities. This ensures prompt deployment of recovery
ships to the projected Space Capsule impact location.



4
Project Management & Organization Structure

We have eight people on our team. Every member has been assigned a
role on the project based on their area of expertise.

The team meets at least once a week (more often when necessary) and
communicates virtually between meetings.

Team Member Roles & Responsibility:
 Pedro H Curiel – Program Manager / Architect
 Amber Gell – Systems Engineer
 Jerrod Magoon – Systems Engineer
 Wayne Haufler – Software Engineer / Architect
 Tim Fisher – Analyst
 Byron Prelow – Certified Test Conductor/Test Planning Coordinate
Drafter/Pro-E
 Khoa Nguyen – Configuration Management Manager
 Anh Dang – Configuration Management Manager
5
ISS
Capsule
GBR system tracking capsule
Radar Range
Range Gate
Range gate tracking (every 10 sec)
Capsule
projected
path
Range gate tracking (every 10 sec)
& Impact Prediction (every 1 min)
400 Kft
5 degree re-entry angle
100 Kft
GBR
0 ft
6
Use Case Scenarios
Use Case 1: Scan for capsule
Brief Description: Scan area specified by ICC for capsule re-entry. GC ship is deployed to approximate location
Actors: internal: GC Operator, Control Computer (CC), Ground Based Radar (GBR) and a Communications Relay Group (CRG) external:
Information Control Center (ICC)
Trigger: Radar detects object within range
Preconditions:

GBR has been restarted just before mission starts

Radar is charged

Sea ship providing adequate power

ICC online
Nominal: Start Radar scanning. Detect potential target base on strength of return signal.
Off-nominal:

Computer shuts down – go with backup

Radar detects more then one target – Ignore other objects and only track capsule.
Post-conditions: Detect enabled and system sets up an analysis of the object. Data is collected and time log book is recorded.
Use Case 2: Detect capsule
Brief Description: The GC determines if the object detected is in fact the space capsule analyzing the objects features.
Actors: internal: GC Operator, Control Computer (CC), Ground Based Radar (GBR) and a Communications Relay Group (CRG) external:
Information Control Center (ICC)
Trigger: Radar sends characteristics info of object detected to CC
Preconditions:

Computer is up and running properly

Sea ship provides adequate power

GC operator is present

Target appears in the distance
Nominal: After an object is detected the system analyzes it for qualities (its speed, size, etc.) After analysis its determined if it matches the
capsule characteristics stored in memory. ICC is notified of object detection.
Off-nominal:

Object is determined to not be capsule – continue with another scan

Object cannot be determined – operator makes the necessary decision consulting with ICC
Post-conditions: GC determines incoming object is capsule and system is prepared to activate “range gate” to anticipate next capsule location
and continue tracking. Data is collected.
7
Use Case 3: Track capsule location
Brief Description: By using the “range gate “within the GC radar an area in the air space is calculated on where the system should look next for the capsule.
By analyzing the capsule known velocity and time the range gate predict where the capsule will appear next.
Actors: internal: GC Operator, Control Computer (CC), Ground Based Radar (GBR) and a Communications Relay Group (CRG) external: Information
Control Center (ICC), space capsule
Trigger: Incoming object is verified as capsule
Preconditions:

Computer is up and running properly

Sea ship providing adequate power

Operator is present

Target is identified as capsule
Nominal: Computer analyzes incoming capsule and determines its velocity and the time of last radar detection. Both time and velocity are expressed as real
number. The range gate filters out info about airborne objects outside its calculated area and only process the information needed to track capsule.
The range gate area is predicted to continue tracking and logging data.
Off-nominal:

System failure – velocity and time cannot be calculated

The predicted location is clearly off - operator makes necessary adjustments
Post-conditions: Range gate performs calculation and anticipates location every 10 seconds. Data is collected
Use Case 4: Calculate capsule impact location
Brief Description: After the range gate has been logging position data since detection and capsule has reached descent range between 400 to 100 kft
computer will start calculating impact locations once every minute with the last 6 range gate location predictions.
Actors: internal: GC Operator, Control Computer (CC), Ground Based Radar (GBR) and a Communications Relay Group (CRG) external: Information
Control Center (ICC), space capsule
Trigger: Range gate has confirmed capsule location within 400 to 100 kft of surface
Preconditions:

ICC communications online

GC Operator is present

Access to past range gate calculations
Nominal: Impact locations are calculated once every minute by using the last 6 location points. Impact location calculation is communicated to ICC
Off-nominal:

System failure – go with backup

Tracking is off - the operator makes the necessary adjustments

Last minute confirmation of object being tracked is not capsule – communicate with ICC
Post-conditions: Capsule impact location is adequately predicted and communicated to ICC every minute when capsule is between 400 to 100 kft of
landing. ICC deploys recovery ship and confirms capsule location. Data is collected.
8
Use Case 5: Collect data for post mission analysis
Brief Description: After the process is complete all the data is collected for the mission. It is analyzed for any problems or
concerns. Any changes are made and the operator and engineer are informed of them. A time log is kept for every step of
the mission.
Actors: internal: GC Operator, Control Computer (CC), Ground Based Radar (GBR) and a Communications Relay Group (CRG)
external: Information Control Center (ICC),
Trigger: Capsule has been recovered
Preconditions:

A time log has been completed every step of the mission

A large amount of data has been collect to be analyzed

Computer system ready for analysis is up and running
Nominal: After the mission is complete the analyst obtains all the necessary data to do is analysis of the mission. The operator
informs the analyst of any problems to look for and any changes that may have to be made. The analyst looks at the data
to develop an analysis report. Any problems or discrepancies are reported to the operator and engineer to make the
necessary changes on the GC.
Off-nominal:

Not all times are recorded for the mission – estimates are made and fault is corrected

System failure – go to backup
Post-conditions: Any problems are reported and necessary changes are made to the GC after the analysis. Also, accuracy of
the impact location is recorded. System is shut down.
9
Process View
Scan
(GBR)
Detection &
Identify
Tracking & Verify
(Range gate)
- Radar pulses
to locate
capsule
- Reflected pulse is
compared to make
sure its capsule
- calculation for next
position prediction and
verify its capsule
Projection
- Use last 6 tracking
points for an impact
prediction every minute
Communica
tion (CRG)
- Let know ICC latest
impact prediction
Database
ROM
Database
- Characteristics
of space capsule
- To save once every
10 second sampling
- To
save impact
predictions 1
per minute
10
Logical View
ICC
Physical View w/o Processes
CRG
GC
Comm Relay Group
Ground Control
GBR
Ground Based Radar
CC
RG
Control
Computer
Range Gate
11
ICC
Logical View
with SW Objects in Pipeline Architecture
CRG
GC
Comm Relay Group
Ground Control
GBR
Ground Based Radar
CRG
_Rep
CC
Control
Computer
Comm
RG
_Rep
Comm
CC
_Rep
RG
Scan
Range Gate
Scan
Pulse
Cmds
Radar
_Rep
Tracking
Position_
Predictions
UI
every 10 secs
Projectio
n
Impact_
Tracking
Predictions
Range
_Gate
every 60 secs
Identify
Signal
_Gate
Tracking
Detection
Altitude
_Gate
Blip
12
Logical View
ICC
with Stored Arrays
CRG
GC
Comm Relay Group
Ground Control
GBR
Ground Based Radar
CRG
_Rep
Comm
CC
Control
Computer
RG
_Rep
Comm
RG
Scan
Range Gate
CC_Rep
Scan
Pulse
Cmds
Radar
_Rep
Tracking
Position_
Predictions
UI
every 10 secs
Projectio
n
Impact_
Predictions
every 60 secs
Last 6
Blips
Tracking
Identify
Range
_Gate
Signal
_Gate
Range
_Gates
Referenc
e_Signal
Tracking
Detection
Altitude
_Gate
Blip
Blips
13
Logical View
ICC
with Exec for Querying Stored Arrays, Setting Parms
CRG
GC
Comm Relay Group
Ground Control
GBR
Ground Based Radar
CRG
_Rep
Comm
CC
Control
Computer
RG
_Rep
Comm
RG
Scan
Range Gate
CC_Rep
Scan
Pulse
Cmds
Radar
_Rep
Tracking
Position_
Predictions
UI
Exec
every 10 secs
Projectio
n
Impact_
Predictions
every 60 secs
Last 6
Blips
Tracking
Identify
Range
_Gate
Signal
_Gate
Range
_Gates
Reference
_Signal
Tracking
Detection
Altitude
_Gate
Blip
Blips
14
Logical View
ICC
with Exec for nonPipelined, Centralized Arch
CRG
GC
Comm Relay Group
Ground Control
GBR
Ground Based Radar
CRG
_Rep
CC
Control
Computer
Comm
RG
_Rep
RG
Range Gate
Position_
Predictions
UI
Pulse
Cmds
CC_Rep
Radar
_Rep
Exec
every 10 secs
Projectio
n
Impact_
Predictions
every 60 secs
Last 6
Blips
Range
_Gate
Signal
_Gate
Range
_Gates
Referenc
e_Signal
Altitude
_Gate
Blip
Blips
15
Physical View
GC Box
•
GC is Composed of
○
Control Computer (CC),
○
Ground Based Radar (GBR)
 which includes the Range Gage (RG)
computer and a
○
Communications Relay Group (CRG) to
communicate with the Information Control Center
(ICC).
GBR Box
Range Gate
Tracking &
Verify
Scan
(GBR)
CC Box
Detection
& Identify
Capsule
Characteri
stics ROM
Projection
Capsule
Position
Database
Communicati
on to ICC
(CRG)
Capsule Impact
Prediction
Database
16
Statement of
Software Requirements

Caveat: Lacking knowledge of the existing legacy software architecture, this set of
software requirements necessarily assumes or imposes an architecture on top of or in
partial replacement of the existing legacy architecture. This approach is likely to result in
incompatible architecture match and/or minimal software reuse. A few objects are noted
with “(wrapper around existing code)” where it seems that might work.

…

RG’s Blip object
Blip object’s “new” method, when invoked, shall send a message to the Blips
object (Note: Blips object different from Blip object), appending a Blip record
with timestamp to an ever-growing chronological record.
 Blip object’s “new” method, when invoked, shall send a copy of itself (Blip
record) to the Altitude_Gate object, the next object in the pipeline.


RG’s Altitude_Gate object


The Altitude_Gate object shall receive a Blip object.
The Altitude_Gate object shall compute the capsule’s altitude from data in the
Blip.
 The Altitude_Gate object shall flag the Blip object as being “TrackingBracking”
when altitude is between 400,000 feet and 100,000 feet.
 The Altitude_Gate object shall send the Blip object to the SignatGate.
 …
Statement of
Software Requirements

WARNING: If each arrow is implemented by invoking (calling) the destination
object’s method by the source object, then the circuit path of arrows within RG
would result in something like a “Circular Call Reference Error”. These should be
implemented with a nonblocking message passing mechanism.
…


RG’s Blip object
In Blip object’s “new” method,

Call Blips object’s Store method (Note: Blips object different from Blip object),
○



which pushes the Blip record with timestamp to a limited stack data structure, an ever-growing
chronological record.
Call Altitude_Gate’s Check method with a copy of the Blip record
RG’s Altitude_Gate object
In Altitude_Gate object’s Check method,




Receive Blip data record
Check inputted Blip data for validity
if Valid_data is True
Call computeAltitude to do that from data in the Blip.
○
○

Alt = Range * sin 5 degrees
if Alt <= 400,000 ft AND Alt >= 100,000 ft
○



sin A = a / c = Alt/Range;
Blip.Tracking = False
Blip.Tracking = True
(where Blip.Tracking is a boolean field called Tracking in the Blip record)
Call Signal_Gate’s Check method with the Blip data record.
Development View
Scan (GBR)
Presentation Layer
GUI
Detection & Identify
Tracking & Verify
(Range Gate)
Presentation Layer
Presentation Layer
GUI
GUI
ICC Communication
Projection
Presentation Layer
GUI
Physics Layer
Physics Layer
Physics Layer
Physics Layer
Algorithm
Components
Algorithm
Components
Algorithm
Components
Algorithm
Components
Data Layer
Data Layer
Data Layer
Data Access
Layer
Components
Data Access
Layer
Components
Data Access
Layer
Components
(CRG)
Presentation Layer
GUI
Data Layer
Data Access
Layer
Components
19
Development View - Data
Capsule Characteristics ROM
Table
Schema
Stored Capsule
Characteristics
Capsule Position Database
Table
Schema
Stored
Procedures
Stored
Capsule
Location
Log
Reference_Signature
Re-Entry Angle or Elevation
Velocity
Expected Parametric
“Shape” of Signal Envelope
Capsule Position or ‘Blip’
TimeStamp
Predicted Signature Box:
Azimuth_Left
Azimuth_Right
Elevation_Top
Elevation_Bottom
Range
Capsule Impact Prediction
Database
Table
Schema
Stored
Procedures
Stored
Capsule
Impact
Prediction
Log
Impact_Prediction
TimeStamp of Impact
Range (relative to radar)
Expected Iimpact Oval:
Focal_x, Focal_y
SemiMajorAxis
SemiMinorAxis
20
Function Points
Complexity of Components
UFP
Low
5
x3=
Average
EI
7
15
EO
1
EQ
2
1
x3=
3
ILF
5
5
x7=
40
EIF
1
Total
16
x4=
x5=
1
High
AFP
x4=
1
x6=
6
21
x5=
1
x7=
7
7
x4=
4
x10=
x7=
1
x6=
7
x15=
40
x10=
10
10
85
21
ICED-T Metrics
Metric
Value
Comments
Intuition
3
Designed for use by Gov’t Agency; Operators highly
trained; Operated using detailed procedures
Consistency
3
Strong dependence on pre-planned procedures
reduces the need for high consistency
Efficiency
3
Low time criticality before entry allows low efficiency;
high time criticality during entry required high
efficiency
Durability
5
Extremely time-critical functions and consequences
of failure require the utmost in reliability
2
Few, if any, functions of the software will be used
that are not pre-planned and built into procedures.
Thoughtful functions become required ones if
needed.
Thoughtfulness
22
Development Schedule and
Gantt Chart








COCOMO method was used for schedule estimations
16 Unadjusted Function Points
Assumption of using the C programming language
Total Lines of Code (LOC) = 1664
Applying the 1.664 KLOC to the Effort equation
Assuming we have Embedded Software
Effort = 6.63 Staff Months
Due to the fact that we are students, working professionals in
separate fields, have families and are involved in other social
activities. We estimated that each of us can spend 8 hours per
week.
23
At 8 hours/week/student
 1 Staff Week = 40 hours = 5 Student Weeks
 Since there are generally 4 weeks in a month
 1 Student Month = 4 x 5 Student Weeks = 20 Student
Weeks
 In general, 20 weeks = 5 months
 Therefore, 1 Student Month = 5 Staff Months
 Once this was found, we applied to our Effort equation:
 Student Months = 5 x 6.63 Staff Months = 33.16
 Our team is made up of eight people:
 33.16 Student Months / 8 Students = 4.15 Months
 Therefore, we estimate that this project can be
completed within 5 months of the start date.

24
Gantt Chart
25
Test Plan
Cooperative Testing
 Chosen as first test to be performed by our team.
 Fosters cooperation amongst subsystem
designers.
 Use of test beds which were provided by the
original system testers.
 Helps to eliminate problems before software is
seen by external test team.
26
Unit Testing
Allows us to test each module/use case
individually
 Scan (scan for capsule)
 Detection & identify (detect capsule)
 Tracking & verify (track capsule location)
 Projections (calculate capsule impact location)
 Communication (collect data for post-mission
analysis)
 All test data and Test results will be kept with the
module’s source code.

27
Stress & Regression Testing

Stress Testing
 Test software detection mode up to 800,000 ft to analyze
behavior.
 Test impact predictions/projections beyond 100,000 ft –
400,000 ft range.
 Allows us to see how software will behave under
“abnormal” operating conditions

Regression Testing
 Ensure original software features still function the same
with changes.
 Use test cases from original software on current versions
 Inform team of any problems existing due to changes in
software.
 Inform team if software ran correctly.
28
System/Integration Testing

Testing connections between the
following:
 ICC to CC system
 CC system to RG
 RG to GC.
 GC to RG
 RG to CC system
 CC system to ICC
29
Configuration Management
Deliverable Items

All Acquisition, Design, Development, Production, Operation, Support and Maintenance
Decision Making:


















Requirements Traceability Matrix (RTM, DOORS, CRADLE, CORE, etc.)
Software Development Plan (SDP)
Software Standards & Procedure Manual (SSPM)
Software Requirements Specifications (SRS)
Interface Design Document / Interface Requirements Specification (IDD / IRS)
Software Development Files (SDF)
Software Requirements Trace Matrix (SRTM)/Software Requirements Verification Matrix (SRVM)
Software Test Documents, SW Test Plans, SW Test Reports (STD, STP, STR)
Software Design Documents (SDD)
Software (including all interfaces, simulators, emulators, drivers, etc.)
Government Provided Software(GPC)
3rd Party Code/ Contractor Supplied Software (CSS)
○
(i.e; developed by universities, research labs, etc.)
SW Environment (Compliers, linkers, GUI builders, CASE tools, project planning tools, CM Tools, debuggers,
SW Licenses and maintenance)
Commercial Off-the-Shelf (COTS) Software, Free & Open Source Software (FOSS)
Software Version Description / Software Product Specification (SVD / SPS)
Government Furnished Information (GFI)
All Contract Data Requirements Lists/ Supplier Data Requirement Lists (CDRLs/SDRLs)
“Official” deliverable items must be delivered from CM.
30
Configuration Management
CM PROCESS
CONTRACT / RFP
CONFIGURATION CHANGE MANAGEMENT
CONFIGURATION IDENTIFICATION
•
•
•
•
•
•
CM PLANNING
• CM PROCESS
• CI PLAN
• DOC PLANNING
• ESTABLISH AND ENFORCE
CHANGE PROCEDURES
• MAINTAIN BASELINE
• ADMINISTRATE CHANGE
UPDATES
CHANGE IDENTIFICATION
DOCUMENT ESTABLISHED CIs
SELECT DOC TYPES AND FORMATS
RELEASE / CONTROL TDP
BASELINE IDENTIFICATION
SERIALIZATION IMPLEMENTATION
IDENTIFICATION CRITERIA AND RULES
• DEFICIENCY
• ENHANCEMENT
• REQUIREMENT MODIFICATION
ANALYSIS
CHANGE PREPARATION
•
•
•
•
• PREPARE CHANGE DOCUMENT
• TECHNICAL REVIEW
SOFTWARE
HARDWARE
• CSCI 1
• CSCI 2
• CSCI 3
• HWCI 1
• HWCI 2
• HWCI 3
SCHEDULE
COST
CHANGE DEFINITION
IMPACT
CONFIGURATION CONTROL BOARD
CUSTOMER / CONTRACT
PROCESS & APRV
DOCUMENTATION
VAULT
Lifecycle Support
•
Operations and
Maintenance
•
Supply &
Support
EVALUATE
CHANGE
DRAWING
VAULT
SHIPMENTS
• DELIVER PRODUCT TO
CUSTOMER
• VALIDATE USABILITY
APPROVE
?
NO
CUSTOMER / CONTRACT
PROCESS & APRV
YES
S/W VAULT
CONFIGURATION
AUDITS
INCORPORATE CHANGE
• UPDATE SYSTEM BASELINE
• CONDUCT AUDITS FCA, PCA
• SELF-ASSESSMENT
AUDITS
• QUALITY PROGRAM
AUDITS
MAINTAIN RECORDS
• AS-BUILT DATA
• PROVIDE REPORTS
CONFIGURATION
STATUS ACCOUNTING
• VERIFY CHANGE
INCORPORATION
• RECORD AS-BUILT
• PRODUCE TRACEABILITY
OF CHANGES
• PROVIDE STATUS
• COLLECT AND ANALYZE
METRICS
•AS DESIGNED DATA
•AS MAINTAINED
FCA - Functional Configuration Audit
PCA - Physical Configuration Audit
RFP – Request for Proposal
CSCI – Computer Software Configuration Item
HWCI – Hardware Configuration Item
31
Major Elements of CM
Change Control
Procedures, including
verification of change
implementation
Specification,and
Test Procedure
Revisions
Change Criteria
Configuration
Change Control
Change control and
review organizations
Configuration
Verification
Records
Change Status
Records
Status
Accounting
Specifications
Major
MajorElements
Elements
ofof
Configuration
Configuration
Management
Management
First Article
Inspection
32
Identification of
Changes to
Data Items
Baselines
Identification of
Product Acceptance Data release
Requirements
Identification
Requirements
Product Description
Files of Change
Authorizations and Records
Approvals
Formal
Qualification
Configuration
Item
Identification
Product Configuration
Identifiers
Configuration
Audits
Physical Configuration
Audits/Reviews
Functional Configuration
Audits/Reviews
Coding Standard
NASA SOFTWARE CODING STANDARD GUIDES:
•To assure high quality, reliability and safety, the following NASA Software Coding
Standard will be used as guide for coding practices:
NASA- JSC27209: C Coding Standard for the Orbiter Interface Unit (OIU) Project.
NASA-JSC
ISS SIGI Attitude Processor: C Coding Style Guide
NASA-JSC
C Coding Standard for the X-38/V201 GN&C Flight Software
• Dynamic memory allocation (e.g., use of functions calloc() and malloc())
shall[42] not be used, in order to reduce the risk of memory leaks and
promote a fixed memory model.
• Module execution rate shall[72] not be assumed to be a constant unless it is
running in a deterministic, real-time system.
• Header files shall[81] not be nested
•Concurrent programming shall[83] not be used
33
NASA Standards & Processes
The software development life cycles shall compliance with the following Standards
and Processes:
NASA-STD-0005 NASA Configuration Management (CM) Standard
NPD 2820.1 NASA Software Policies
NPR 1441.1 NASA Records Retention Schedules
NPR 7120.5 NASA Program and Project Management Processes and Requirements
NPR 7150.2 NASA Software Engineering Requirements
NASA-STD-8719.13 Software Safety Standard
NASA-STD-2202-93 Software Formal Inspections Standard
NASA-GB-8719.13 NASA Software Safety Guidebook
NASA-GB-A201 Software Assurance Guidebook, September 1989
NASA-GB-A301 Software Quality Assurance Audits Guidebook, December 1990
NASA-GB-A302 Software Formal Inspections Guidebook, August 1993
IEEE 730-2002 IEEE Standard for Software Quality Assurance Plans
ISO/IEC 12207:1995 Software life cycle processes
ISO 90003:2000 Quality Management And Quality Assurance Standards –
Part 3: Guidelines For The Application of ANSI/ISO/ASQC 9001:1994
To The Development, Supply, Installation And Maintenance Of Computer Software
ISO 10007:2003 Quality management systems - Guidelines for configuration management
IEEE 982.1-1988 IEEE Standard Dictionary of Measures to Produce Reliable Software
IEEE 1012-1998 IEEE Standard for Software Verification and Validation
IEEE Std. 1028-1997 IEEE Standard for Software Reviews
IEEE Std. 828-1998 IEEE Standard for Software Configuration Management Plans
ANSI/EIA-649-1998 National Consensus Standard for Configuration Management
EIA-649-A 2004 National Consensus Standard for Configuration Management
GEIA Standard 836-2002 Configuration Management Data Exchange and Interoperability
Build Plan
CSCI/
FUNCTION
BUIL
D2
1
3
CSCI A
FUNCTION X
FUNCTION Y
FUNCTION Z
CSCI B
FUNCTION X
FUNCTION Y
FUNCTION Z
CSCI C
FUNCTION X
FUNCTION Y
FUNCTION Z
CSCI A
THREAD
1
THREAD
2
THREAD
3
BUILD 1
BUILD 2
THREAD 1
CSCI B
BUILD 1
BUILD 2
CSCI C
BUILD 1
BUILD 3
THREAD 2
THREAD 3
THREAD 1 CONSISTS OF:
CSCI A BUILD 1
CSCI B BUILD 1
THREAD 2 CONSISTS OF:
CSCI A BUILD 2
CSCI B BUILD 2
CSCI C BUILD 1
THREAD 3 CONSISTS OF:
CSCI A BUILD 3
CSCI B BUILD 2
CSCI C BUILD 2
BUILD 2
Experience indicates that a typical thread requires about three months
completely integrating and testing.
35
DEMONTRATION BUILD PLAN
1/5/2009
1/12/2009
Assess CM Capability & Initial Requirements
Establish Configuration Management Plan
1/28/2009
2/23/2009
Work with SPM & SPE to identify the CM Baseline Software R1
Establish CM Build Scripts R1 with the Developers
2/25/2009
3/7/2009
3/8/2009
Document and Establish The CM Baseline Software R1
Execute Build Scripts R1
Release Baseline Software R1 For Testing & Demo
ENGINEERING BUILD RELEASE PLAN
3/9/2009
Collecting Change Request process to modify the CM Baseline software R1
3/11/2009
Change Request Approval Process
3/12/2009
Work with SPM & SPE to identify the CM Baseline Software R2
3/14/2009
Establish CM Build Scripts R2 with the Developers
3/15/2009
Document and Establish The CM Baseline Software R2
3/16/2009
Execute Build Scripts R2
3/17/2009
Release Baseline Software R2 For Testing, Debug and System Integration Test
3/18/2009
Collecting Change Request process to modify the CM Baseline software R2
3/20/2009
Change Request Approval Process
3/31/2009
Work with SPM & SPE to identify the CM Baseline Software R3
4/1/2009
Establish CM Build Scripts R3 with the Developers
4/2/2009
Document and Establish The CM Baseline Software R3
4/8/2009
Execute Build Scripts R3
4/9/2009
Release Baseline Software R3 For System Integration Testings
36
FINAL RELEASE PLAN
4/9/2009
Collecting Change Request process to modify the CM Baseline software R3
4/11/2009
Change Request Approval Process
4/20/2009
Work with SPM & SPE to identify the CM Baseline Software R4
4/21/2009
Establish CM Build Scripts R4 with the Developers
4/22/2009
Document and Establish The CM Baseline Software R4
4/30/2009
Execute Build Scripts R4
5/1/2009
Release Baseline Software V4 For Engineering Acceptance Testing
5/1/2009
Start CM Audit the Deliverable CM Baseline, Tools, Document and artifacts.
5/1/2009
Archive the Deliverable CM Baseline Software R4 products & all associated CM Items.
5/3/2009
Deliverable CM Baseline Software R4 and the associated CM items to customers
5/4/2009
Formal Customer Acceptance Testing to sell-off the products
5/5/2009
Lesson Learned Process to close out the project
37
Back up
38
Physics-Related Questions



Given that “the control computer used is based on a 1970s designed with relatively limited capability to
perform high precision calculations”, there is a concern that the computer AND the radar might not be able
to handle the much larger numbers and distances involved in this capsule-tracking problem compared to a
relatively local missile tracking problem.
What is the Range of the Radar?
 Answer: http://www.army-technology.com/projects/patriot/
 The radar system has a range of up to 100km.
What is the expected straight line Range of a capsule when it is some 400KFT altitude uprange from its
ballistic impact point (where current capsule velocity vector intercept s the earths surface), given an
expected 5 degree reentry angle?

Would this Range distance put the capsule beyond the horizon?

Given a silly simplifying assumption of a flat earth, trigonometrically,
sin A = a / c = Alt/Range; Range = Alt/sinA = 400K / sin 5 degrees = 4,589,485 ft = 4,600 KFT = * 0.3048 m/ft
= 1,398 km
cos A = b/c = ground range / beam range; gnd range = cos A * beam range= cos 5 * 4,589,485 ft =
4,572,020.9 ft

Is expected max range within max radar range?

Is expected max range representable within available floating point data type,
Max unsigned integer representable is 2^24 - 1 = 16,777,216 -1 = Hex 100 0000 – 1 = FF FFFF
but what would be the maximum representable Floating Point in 24 bit word?
Is a 48 bit double precision available?



No,
1,400 km > 100 km
39
Radar Range Too Short
ISS
Capsule
Radar Range
Local Horizontal
Range Gate
Range gate tracking (every 10 sec)
Capsule
projected
path
5 degree re-entry angle
1,400 KM
400 Kft
100 KM
Radar Max Range
100 Kft
5 degree re-entry angle
GBR
0 ft
40
Systems/Software vs. Hardware CM
SW CM
• Software Product Spec
SW & HW CM
(SPS)
• CM Plan
• Software Version
Description (SVD)
• ECPs, SCNs, NORs
• COTS Software
Inventory
• Status Accounting
• FCA/PCA
Agenda/Reports
• Baselines
ECP - Engineering Change Process
SCN – Specification Change Notice
NOR – Notice of Revision
41
HW CM
• Technical Drawings &
Data Package
• As-Built Configuration
List
Program Baselines
Contract
Requirements
Types of Program Baselines (description of the product at a specific point in time)

Functional Baseline (FBL): initially approved documentation describing a system’s
functional characteristics and the verification required to demonstrate the
achievement of those specified characteristics. It is the Customer expectation – what
we have been contracted to build – requirements. Types of documents that describe
a FBL include:
 Final System Specifications (I.e; Performance Spec, Aspec)

Allocated Baseline (ABL): initially approved documentation describing an item’s
functionality characteristics that are allocated from those of a higher level
configuration item, interface requirements with interfacing configuration items,
additional design constraints (Contractor System, Hardware and Software Specs) and
the verification required to demonstrate the achievement of those specified
characteristics. Types of documents that describe a ABL include:
 Interface Requirement Specs
 Software Requirements Specs
 Hardware Requirements Specs

Product Baseline (PBL): consists of the initially approved documentation describing
all of the necessary functional and physical characteristics of the configuration item
and the selected functional and physical characteristics designated for production
acceptance testing and test necessary for support of the configuration item. In
addition, to this documentation, the product baseline of a configuration item may
consist of the actual equipment and software. It is the accepted “As-built” product.
Types of documents that describe a PBL include::
 Design Documents
 Test Reports
 FCA/PCA Report
 Product Specifications
Design & Test
42