Ground Controller Project

Sponsor & Organization:

Professor Larry BernsteinSSW 540 Fundamentals of Software Engineering

Stevens Institute of TechnologySchool of Systems Engineering & Engineering Management

Castle Point on HudsonHoboken, NJ 07030

1

OverviewProject 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 range-gate 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

GBR system tracking capsule

100 Kft

400 Kft

Range gate tracking (every 10 sec)& Impact Prediction (every 1 min)

Range gate tracking (every 10 sec)

Radar RangeCapsule

ISS

Capsule projected path

GBR

0 ft

Range Gate

5 degree re-entry angle

6

Use Case ScenariosUse Case 1: Scan for capsuleBrief Description: Scan area specified by ICC for capsule re-entry. GC ship is deployed to approximate locationActors: 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 rangePreconditions: GBR has been restarted just before mission starts Radar is charged Sea ship providing adequate power ICC onlineNominal: 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 capsuleBrief 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 CCPreconditions: Computer is up and running properly Sea ship provides adequate power GC operator is present Target appears in the distanceNominal: 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 ICCPost-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 locationBrief 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 capsuleTrigger: Incoming object is verified as capsulePreconditions: Computer is up and running properly Sea ship providing adequate power Operator is present Target is identified as capsuleNominal: 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 adjustmentsPost-conditions: Range gate performs calculation and anticipates location every 10 seconds. Data is collected

Use Case 4: Calculate capsule impact locationBrief 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 capsuleTrigger: Range gate has confirmed capsule location within 400 to 100 kft of surfacePreconditions: ICC communications online GC Operator is present Access to past range gate calculationsNominal: Impact locations are calculated once every minute by using the last 6 location points. Impact location calculation is communicated to ICCOff-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 ICCPost-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 recoveredPreconditions: 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 runningNominal: 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 backupPost-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 ViewScan (GBR)

- Radar pulses to locate capsule

Detection & Identify

- Reflected pulse is compared to make

sure its capsule

Tracking & Verify(Range gate) - calculation for next

position prediction and verify its capsule

Projection- Use last 6 tracking points for an impact

prediction every minute

Communication (CRG)

- Let know ICC latest impact prediction

ROM- Characteristics of space capsule

Database- To save once every 10 second sampling

Database- To save impact

predictions 1 per minute

10

Logical ViewPhysical View w/o Processes

CC Control Computer

RGRange Gate

CRGComm Relay Group GBR

Ground Based Radar

ICC

GCGround Control

11

Logical Viewwith SW Objects in Pipeline Architecture

DetectionProjection

CommCC Control Computer

RGRange Gate

CRGComm Relay Group

CRG_Rep

RG_Rep

CC_Rep

Radar_Rep

Signal_Gate

Impact_Predictionsevery 60 secs

PulseCmds

Altitude_Gate

Range_Gate

Position_Predictions every 10 secs

Blip

UI

GBRGround Based Radar

ICC

Identify

ScanScan

Tracking

Tracking Tracking

Comm

GCGround Control

12

Logical Viewwith Stored Arrays

DetectionProjection


RGRange Gate

CRGComm Relay Group

CRG_Rep

RG_Rep CC_Rep Radar

_Rep

Signal_Gate

Impact_Predictions

every 60 secs

Reference_Signal

PulseCmds

Blips

Altitude_Gate

Range_Gate


Blip

Range_Gates

UI

Last 6 Blips


ICC

Identify

ScanScan

Tracking

Tracking Tracking

Comm

GCGround Control

13

Logical View with Exec for Querying Stored Arrays, Setting

Parms

DetectionProjection


RGRange Gate

CRGComm Relay Group

CRG_Rep

RG_Rep CC_Rep Radar

_Rep

Signal_Gate

Impact_Predictions

every 60 secs

Reference_Signal

PulseCmds

Blips

Altitude_Gate

Range_Gate


Blip

Range_Gates

UI

Last 6 Blips

Exec


ICC

Identify

ScanScan

Tracking

Tracking Tracking

Comm

GCGround Control

14

Logical View with Exec for nonPipelined, Centralized Arch

Projection

CC Control Computer

RGRange Gate

CRGComm Relay Group

CRG_Rep

RG_Rep CC_Rep Radar

_Rep

Signal_Gate

Impact_Predictions

every 60 secs

Reference_Signal

PulseCmds

Blips

Altitude_Gate

Range_Gate


Blip

Range_Gates

UI

Last 6 Blips

Exec


ICC

Comm

GCGround Control

15

Physical View

Scan (GBR)


Tracking & Verify

ProjectionCommunicati

on to ICC (CRG)

Capsule Characteristics ROM

Capsule Position Database

Capsule Impact Prediction Database

CC Box

GBR Box

GC Box

Range Gate

• 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).

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.

○ sin A = a / c = Alt/Range; Alt = Range * sin 5 degrees○ Blip.Tracking = False

if Alt <= 400,000 ft AND Alt >= 100,000 ft○ 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

GUI

Scan (GBR)

Algorithm Components

Presentation Layer

Physics Layer

GUI



Presentation Layer

Physics Layer

Data Access Layer

Components

Data Layer

GUI

Tracking & Verify (Range Gate)


Physics Layer

Data Access Layer

Components

Data Layer

GUI

Projection


Physics Layer

Data Access Layer

Components

Data Layer

GUI

ICC Communication (CRG)

Data Access Layer

Components

Data Layer

19

Presentation Layer Presentation Layer Presentation Layer

Development View - Data

Table Schema

Capsule Characteristics ROM Capsule Position Database Capsule Impact Prediction Database

Stored Capsule Characteristics

Stored Procedures

Stored Capsule Location

Log

Table Schema

Stored Capsule Impact

Prediction Log

Table Schema

Stored Procedures

Capsule Position or ‘Blip’TimeStampPredicted Signature Box: Azimuth_Left Azimuth_Right Elevation_Top Elevation_BottomRange

Impact_PredictionTimeStamp of ImpactRange (relative to radar)Expected Iimpact Oval: Focal_x, Focal_y SemiMajorAxis SemiMinorAxis

Reference_SignatureRe-Entry Angle or ElevationVelocityExpected Parametric “Shape” of Signal Envelope

20

Function PointsComplexity of Components

UFP Low Average High AFP

EI 7 5 x3= 15 x4= 1 x6= 6 21

EO 1 x4= x5= 1 x7= 7 7

EQ 2 1 x3= 3 1 x4= 4 x6= 7

ILF 5 5 x7= 40 x10= x15= 40

EIF 1 x5= x7= 1 x10= 10 10

Total

16 85

21

ICED-T MetricsMetric 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 3Low 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

Thoughtfulness 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.

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 PlanCooperative 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

individuallyScan (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 systemCC system to RGRG to GC.GC to RGRG to CC systemCC system to ICC

29

Configuration Management Deliverable Items

30

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.

APPROVE?

NO

YES

CONFIGURATION CONTROL BOARD

EVALUATECHANGE

CM PROCESS

CONFIGURATION IDENTIFICATION

• DOCUMENT ESTABLISHED CIs• SELECT DOC TYPES AND FORMATS• RELEASE / CONTROL TDP• BASELINE IDENTIFICATION• SERIALIZATION IMPLEMENTATION• IDENTIFICATION CRITERIA AND RULES

SOFTWARE

• CSCI 1• CSCI 2• CSCI 3

HARDWARE

• HWCI 1• HWCI 2• HWCI 3

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

CONFIGURATION AUDITS

• CONDUCT AUDITS -FCA, PCA• SELF-ASSESSMENT

AUDITS• QUALITY PROGRAM

AUDITS

SHIPMENTS

• DELIVER PRODUCT TOCUSTOMER

• VALIDATE USABILITY

INCORPORATE CHANGE

• UPDATE SYSTEM BASELINE

CM PLANNING

• CM PROCESS• CI PLAN• DOC PLANNING

CUSTOMER / CONTRACTPROCESS & APRV

• PREPARE CHANGE DOCUMENT• TECHNICAL REVIEW

CONFIGURATION CHANGE MANAGEMENT

CHANGE PREPARATION

CHANGE IDENTIFICATION

• DEFICIENCY• ENHANCEMENT• REQUIREMENT MODIFICATION

CUSTOMER / CONTRACTPROCESS & APRV

• ESTABLISH AND ENFORCECHANGE PROCEDURES

• MAINTAIN BASELINE• ADMINISTRATE CHANGE

UPDATES

ANALYSIS• SCHEDULE• COST• CHANGE DEFINITION• IMPACT

CONTRACT / RFP

DRAWING VAULT

DOCUMENTATION VAULT S/W VAULT

Lifecycle Support• Operations and

Maintenance• Supply &

Support

Configuration Management

31

FCA - Functional Configuration AuditPCA - Physical Configuration AuditRFP – Request for ProposalCSCI – Computer Software Configuration ItemHWCI – Hardware Configuration Item

32

Major Elements of CM

Configuration Change Control

Status Accounting

Configuration Item

Identification

Configuration Audits

Change Control Procedures, including verification of change implementation

Specification,and Test Procedure Revisions

Change Criteria Change control and review organizations

Formal Qualification

First Article Inspection

Physical Configuration Audits/Reviews Functional Configuration Audits/Reviews

Files of Change Authorizations and Approvals

Configuration Verification Records

Change Status Records

Product Description Records

Baselines Data release Identification Requirements

Identification of Changes to Data Items

Identification of Product Acceptance Requirements

Specifications

Product Configuration Identifiers

Major Elements of


Major Elements of


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 GuideNASA-JSC C Coding Standard for the X-38/V201 GN&C Flight Software

Coding Standard

• 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 & ProcessesThe software development life cycles shall compliance with the following Standards and

Processes:

NASA-STD-0005 NASA Configuration Management (CM) StandardNPD 2820.1 NASA Software PoliciesNPR 1441.1 NASA Records Retention SchedulesNPR 7120.5 NASA Program and Project Management Processes and RequirementsNPR 7150.2 NASA Software Engineering RequirementsNASA-STD-8719.13 Software Safety StandardNASA-STD-2202-93 Software Formal Inspections StandardNASA-GB-8719.13 NASA Software Safety GuidebookNASA-GB-A201 Software Assurance Guidebook, September 1989NASA-GB-A301 Software Quality Assurance Audits Guidebook, December 1990NASA-GB-A302 Software Formal Inspections Guidebook, August 1993IEEE 730-2002 IEEE Standard for Software Quality Assurance PlansISO/IEC 12207:1995 Software life cycle processesISO 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 SoftwareISO 10007:2003 Quality management systems - Guidelines for configuration managementIEEE 982.1-1988 IEEE Standard Dictionary of Measures to Produce Reliable SoftwareIEEE 1012-1998 IEEE Standard for Software Verification and ValidationIEEE Std. 1028-1997 IEEE Standard for Software ReviewsIEEE 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

CSCI AFUNCTION XFUNCTION YFUNCTION ZCSCI BFUNCTION XFUNCTION YFUNCTION ZCSCI CFUNCTION XFUNCTION YFUNCTION Z

CSCI/FUNCTION

BUILD1 2 3

THREAD1THREAD2THREAD3

CSCI A BUILD 1 BUILD 2 BUILD 3

THREAD 1 THREAD 2 THREAD 3

CSCI B

CSCI C

BUILD 1 BUILD 2

BUILD 1 BUILD 2

THREAD 1 CONSISTS OF: CSCI A BUILD 1 CSCI B BUILD 1THREAD 2 CONSISTS OF: CSCI A BUILD 2 CSCI B BUILD 2 CSCI C BUILD 1THREAD 3 CONSISTS OF: CSCI A BUILD 3 CSCI B BUILD 2 CSCI C BUILD 2

Experience indicates that a typical thread requires about three months completely integrating and testing.

Build Plan

35

DEMONTRATION BUILD PLAN

1/5/2009 Assess CM Capability & Initial Requirements

1/12/2009 Establish Configuration Management Plan

1/28/2009 Work with SPM & SPE to identify the CM Baseline Software R12/23/2009 Establish CM Build Scripts R1 with the Developers

2/25/2009 Document and Establish The CM Baseline Software R1

3/7/2009 Execute Build Scripts R1

3/8/2009 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/17/2009 Release Baseline Software R2 For Testing, Debug and System Integration Test







4/9/2009 Release Baseline Software R3 For System Integration Testings 36

FINAL RELEASE PLAN







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? No, 1,400 km > 100 km

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?

39

http://www.army-technology.com/projects/patriot/

Radar Range Too Short

100 Kft

400 Kft1,400 KM

Range gate tracking (every 10 sec)

Radar RangeCapsule

ISS

Capsule projected path

GBR

0 ft

Range Gate

Local Horizontal



100 KMRadar Max Range

40

41

Systems/Software vs. Hardware CM

HW CMHW CM

• Technical Drawings & Technical Drawings & Data PackageData Package

• As-Built Configuration As-Built Configuration ListList

SW CMSW CM• Software Product Spec Software Product Spec (SPS)(SPS)

• Software Version Software Version Description (SVD)Description (SVD)

• COTS Software COTS Software InventoryInventory

SW & HW CMSW & HW CM

• CM PlanCM Plan

• ECPs, SCNs, NORsECPs, SCNs, NORs

• Status AccountingStatus Accounting

• FCA/PCA FCA/PCA Agenda/ReportsAgenda/Reports

• BaselinesBaselines

ECP - Engineering Change ProcessECP - Engineering Change Process

SCN – Specification Change NoticeSCN – Specification Change Notice

NOR – Notice of RevisionNOR – Notice of Revision

42

Program BaselinesTypes 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

ContractContract

RequirementsRequirements

Design & TestDesign & Test