View
49
Download
0
Category
Tags:
Preview:
DESCRIPTION
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. Ground Controller Project. Overview. Project Value - PowerPoint PPT Presentation
Citation preview
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
CommCC 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
Position_Predictions every 10 secs
Blip
Range_Gates
UI
Last 6 Blips
GBRGround Based Radar
ICC
Identify
ScanScan
Tracking
Tracking Tracking
Comm
GCGround Control
13
Logical View with Exec for Querying Stored Arrays, Setting
Parms
DetectionProjection
CommCC 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
Position_Predictions every 10 secs
Blip
Range_Gates
UI
Last 6 Blips
Exec
GBRGround Based Radar
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
Position_Predictions every 10 secs
Blip
Range_Gates
UI
Last 6 Blips
Exec
GBRGround Based Radar
ICC
Comm
GCGround Control
15
Physical View
Scan (GBR)
Detection & Identify
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
Detection & Identify
Algorithm Components
Presentation Layer
Physics Layer
Data Access Layer
Components
Data Layer
GUI
Tracking & Verify (Range Gate)
Algorithm Components
Physics Layer
Data Access Layer
Components
Data Layer
GUI
Projection
Algorithm Components
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
Configuration Management
Major Elements of
Configuration Management
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/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? 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
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
5 degree re-entry angle
5 degree re-entry angle
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
Recommended