NPOESS Data Exploitation (NDE)
Preliminary Design Review
November 21, 2006
NSOF Building 4231 Suitland Road Room 2001
Welcome
-J. Silva
PDR Agenda
8:00 a.m.
Welcome
8:15 a.m.
Introduction/Background
9:00 a.m.
Project Overview
10:45 a.m.
NDE Context and Hardware
11:15 a.m.
Algorithm Development
12:00 p.m.
Lunch
1:00 p.m.
Data Handling System
2:30 p.m.
IT Security
3:00 p.m.
Communications Study
3:40 p.m.
Closing Remarks
4:00 p.m.
PDR Board Review of RFAs
3
Agenda
8:00 a.m.
Welcome
• Introduction/Background J. Silva
8:15 a.m.
Introduction/Background
• Mission & Design Drivers
J. Silva
9:00 a.m.
Project Overview
• Architectural Overview
G. Goodrum
10:45 a.m.
NDE Context and Hardware
• Data Products
T. Schott
11:15 a.m.
Algorithm Development
12:00 p.m.
Lunch
1:00 p.m.
Data Handling System
2:30 p.m.
IT Security
3:00 p.m.
Communications Study
3:40 p.m.
Closing Remarks
4:00 p.m.
PDR Board Review of RFAs
4
NDE Design Review Board
– Chairperson: Vanessa Griffin, (NESDIS/OSD) Ground Systems Division
Chief
– Mike Mignogno (NESDIS/OSD) Polar Program Manager
– Mike Tanner (NESDIS/HQ) Senior Program Advisor
– Reginald Lawrence (NESDIS/OSDPD), Environmental Satellite Processing
Center Chief
– David Benner (NESDIS/OSDPD) Satellite Services Division Chief
– Mitch Goldberg (NESDIS/STAR) Satellite Meteorology and Climatology
Division Chief
– Joseph Mulligan (NOAA/IPO) NPOESS Interface Data Processing Segment
Lead
– Kevin Schrab, Ph.D. (NWS) Satellite Product Improvement Manager
– Brian Gockel (NWS/OST/SEC) Systems Engineer
– Lt. Amanda Bittinger (NESDIS/STAR) Satellite Oceanography and
Climatology Division
– Charles MacFarland NESDIS/OCIO Representative
5
Request for Action
Briefing Title:
Slide Number:
_________________________________________
Comment/ Question:
•
•
•
RFAs are available on tables at back of room
RFAs to be submitted to a Review Board Member
All RFAs are due today by the end of the meeting
(4:00 p.m.)
– Please state your questions clearly
– Review Board will disposition RFAs
_________________________________________
Background on Comment or Question:
•
Board Members are requested to convene to
disposition RFAs
_________________________________________
Team response:
___________________________________________
Submitted by: _________
6
The NDE IT Design Team
Configuration
Management
Management Team
Jim Silva
Gary Sloan
Tom Bishop
Geof Goodrum
Raj Khanna
Gary Roth
Tom Schott
Algorithm I/F Design
Maurice McHugh
Tony Conrad
OSDPD Product Leads
Bill Reupke
STAR Product Leads
Krishna Tewari
Emily Graham
ESPC CM Team
Requirements
Geof Goodrum
Stan Cutler
Lou Fenichel
Raj Khanna
Jim Silva
Ed Wilson
IDPS I/F Design
Geof Goodrum
Raytheon
Peter MacHarrie
Ed Wilson
System Modeling
Ann Al-Jazrawi
Stan Cutler
Geof Goodrum
Barbara Hickman
Raj Khanna
Peter MacHarrie
Gary Roth
Hongming Qi
CLASS I/F Design
Brian Merandi
Peter MacHarrie
Ann Al-Jazrawi
ESPC Architecture
Tom Bishop
Brian Callicott
Wendy Holmes
Barbara Hickman
Comm. Study
Barbara Hickman
Rich Mumaw
Tom Suhrstedt
Customer Reps
7
Today’s Objective
• Objectives: To ensure that NDE’s design concepts are
consistent with NPOESS and NOAA architectures and
that NDE plans are feasible
• NDE Design Review Board roles and responsibilities:
– Review NDE system conceptual design
– Review project plans necessary to reach Critical Design Review
(CDR) in August 2007
– Review strategies (acquisition, development, testing,
implementation, transition)
– Assess risks
– Request actions that will improve NDE designs and plans
8
Assessment Criteria
• Does the proposed preliminary design satisfy the contractual
requirements?
• Has the overall system framework been clearly presented?
• Has the functionality been appropriately allocated to
subsystems?
• Have the interfaces between subsystems and to external
entities, including users, been identified?
• Have the security features and controls been defined?
• Have delivery strategies been defined for the subsystems (build,
buy, reuse)?
• Are the plans and schedules leading to CDR feasible?
9
Background Documents
•
NDE Requirements &
Performance Measures
–
–
–
–
–
–
–
Software Engineering
Infrastructure
•
Systems Management
Data Retention & Archive
Interfaces
Operational Product Generation
Communications
& Distribution
See NDE Web site:
http://projects.osd.noaa.gov/nde
Project Plan v.2
–
–
–
–
–
–
–
Scope
Organizational Views
Roles and Responsibilities
Project Approach
Schedule
Acquisition Strategy
Budget
• Concept of Operations
–
–
–
–
–
–
Scope
Justification
System Concepts
Operational Scenarios
Impacts
Analysis of Proposed
System
10
NDE Design Review
Board:
Review Calendar
Date
Deliverable
Tasked
Nov 21
Requests for
Action (RFA)
Review Board
Dec 15
Action
Responses to
Board and
Chairperson
NDE
Design Team
Jan 26
Final Report
Design Board
Chairperson
11
Agenda
8:00 a.m.
Welcome
• Introduction/Background
8:15 a.m.
Introduction/Background
• Mission & Design Drivers J. Silva
9:00 a.m.
Project Overview
• Architectural Overview
G. Goodrum
10:45 a.m.
NDE Context and Hardware
• Data Products
T. Schott
11:15 a.m.
Algorithm Development
12:00 p.m.
Lunch
1:00 p.m.
Data Handling System
2:30 p.m.
IT Security
3:00 p.m.
Communications Study
3:40 p.m.
Closing Remarks
4:00 p.m.
PDR Board Review of RFAs
J. Silva
12
Mission
The NPOESS Data Exploitation (NDE) will
provide critical environmental products
derived from NPP and NPOESS
observations to NOAA’s operational
community in near-real time
13
Capabilities Assessment:
NDE’s Δs
Current State
Target State
Orbital Processing
Δ
Δ
Δ
Granule Processing
Stove-pipe Applications
Processing
Δ
Centralized Data Processing
Bolted-on Security
Security Compliant w/ Standards
300 GB/day Distribution
Δ
Δ
Δ
Heritage Instruments
Δ
New Instrument Technologies
DMSP + POES
End-to-End Control
100 GB/day Ingest
NPP + NPOESS
Post-processing
~2.5 (NPP) TB/day Ingest
~6 TB/day Distribution
14
NDE Project:
Capabilities Assessment
Current State
Orbital Processing
• Orbital Processing
• Near-real time = 156
minutes from observation to
product
Target State
Δ
Granule Processing
• Granule (data structure)
Processing
• Instrument specific
• SafetyNet
• “Continuous” ingest
• Near-real time = <30
minutes
• All data packaged as HDF5
NDE systems must adapt to all new input
formats, alter formats to user needs, take
advantage of improved latency
15
NDE Project:
Capabilities Assessment
Current State
Stove-pipe
Applications Processing
Target State
Δ
• Stove-pipe Applications
Processing
• Duplicated, redundant
functionality
• High cost of management
& control
Centralized IT Architecture
• Centralized IT Architecture
• Reusable objects
• Database Technologies &
Data Management
• Common CM, testing, and
transition processes
• Common toolsets
• Centralized management and
control
NDE will establish latest proven technologies
and manage them in 3 basic environments:
Development, System Test, Operations
16
NDE Project:
Capabilities Assessment
Current State
300 GB/day Distribution
• Product benefits realized by
relatively small customer base
• Limited number of
dissemination options
• “orders” require developer
intervention
• FTP (pull) in most cases
Δ
Target State
~6 (tbc) TB/day Distribution
• Increase customer base
(increase benefits)
• Online subscriptions
• GUIs
• More Dissemination Options:
•Push, pull, network, fiber,
internet, etc.
NDE to establish a Communications Architecture in
collaboration with NOAA’s Network Advisory
Committee (NAC) and AWIPS
17
The Transition Challenge
• Environmental satellite industry challenge
– NESDIS history: ~ 2 ½ years from data availability, through
research, to provision of products to operational users (R2O)
• All new NOAA projects must have Transition Teams and
submit Transition Plans for approval
– NDE submitted plans (MIRS, CrIS/ATMS, Sea Surface
Temperature) developed with SPSRB oversight
• NDE’s Goals
– Minimize IT obstacles as algorithms migrate through
development, test, and operational environments
– Work with end users to prepare operations for products
18
NDE Milestone Plan
19
Agenda
8:00 a.m.
Welcome
• Introduction/Background
J. Silva
8:15 a.m.
Introduction/Background
• Mission & Design Drivers
J. Silva
9:00 a.m.
Project Overview
• Architectural Overview
G. Goodrum
10:45 a.m.
NDE Context and Hardware
• Data Products
T. Schott
11:15 a.m.
Algorithm Development
12:00 p.m.
Lunch
1:00 p.m.
Data Handling System
2:30 p.m.
IT Security
3:00 p.m.
Communications Study
3:40 p.m.
Closing Remarks
4:00 p.m.
PDR Board Review of RFAs
20
NDE System Objectives
• Disseminate NPOESS Data Records to NOAA Operational Community
• Generate and disseminate tailored NPOESS Data Records (versions of
NPOESS Data Records in previously agreed alternative formats and views)
• Generate and disseminate NOAA-unique products (augmented environmental
products constructed from NPOESS Data Records)
• Deliver NOAA-unique products, product processing elements, and associated
metadata to CLASS for long-term archiving
• Provide services to customers, including NDE product training, product
enhancement, and implementation support across NOAA
• Provide software for NPOESS Data Record format translation and other data
manipulations
21
NPOESS Data Exploitation (NDE)
Mission Context Diagram
NOAA Environmental Satellite Processing Center
(ESPC)
NPOESS
Ground
System
Data Records (xDRs)
NOAA Unique
Products
Tailoring
Tools
Data Records
(xDRs)
NPOESS will
deliver more than
100 different data
records (xDRs)
xDRs
Climate
Climate
Community
Community
Tailoring Tools
NOAA-Unique Products
NPOESS
Data
Exploitation
(NDE)
Tailored
Products
Data Records
NOAA Unique
(xDRs)
Products
CLASS
CLASS
Near
NearReal-time
Real-time
Customers
Customers
22
Scope & Requirements
NDE Phasing
Requirements &
Preliminary Planning
Preliminary
Design
Deployment Lifecycle
Critical
Design
Release
Release
Release
Release
Closeout
• Design, develop and implement
– Development Environments for
NPP/NPOESS
– System Test Environment for
NPP/NPOESS
– Operational Environment for NPOESS
23
Vision:
3 Environments, Common Standards
Environmental Satellite Processing Center
NDE
Development
Environment
NDE
System
Test/Backup
Environment
NDE
Operational
Environment
Shared Capabilities, Common Standards
24
Design Considerations
•
•
•
•
Algorithm modularity
Reuse
Centralization
Scalability
25
IDPS / NPP & NDE Integration
Timeline
CUT
SWIC
Complete Complete
4/21/06
7/7/06
1.4 CDW
11/14/05
CUT
ACI ATP 8/30/05
Seg Preliminary
QUALNDE
Int DesignLite
NPP
Launch
9/30/09
NDE-NPP
Integration
NDE System Test
Environment
ACI CDW 2/23/06
NPP Sys Test / Sys
Readiness Activities
…
ACI CUT
Performance Analysis & Prototyping
BAR
10/12/06
B1.5:
NDE Critical
Design
Continuous Segment INT
IDPS Algorithm Sci2Ops
ACI Design
Performance:
Qual lite
Complete
2/28/07
BAR
Prep
Site HW
Procure /
Initial HW
PrePre-Ship
Procure
SWIC 10/1/07
FAT
Alg FO
CUT
Seg Int 1/4/08
CDW Deadline Complete Complete
Int
Qual
Complete
1/11/07 3/30/07 5/30/07 7/27/07
Complete 4/11/08
10/30/07
4/4/08
Detailed
Design
CUT
SWIC
Cont Segment INT
IDPS Algorithm Sci2Ops
Seg
Int
QUAL
FAT Int
B1.4:
SWIC
Seg Int
Complete
11/10/06
NESDIS
SAT/
FAT
AFWA
Complete
SIT
6/27/08 9/30/08
FAT
A-SAT
N-SAT
Final
Perf
Verif
3/30/09
(TBR)
FAT Install and Prep
Site Installs and Prep
Characterization Updates/Final Verif
Small algorithm changes to SPCR work-off
O&S
Late/large algorithm changes
2Q2005
3Q2005 4Q2005 1Q2006 2Q2006 3Q2006 4Q2006 1Q2007 2Q2007 3Q2007 4Q2007 1Q2008 2Q2008 3Q2008 4Q2008 1Q2009
26
Concepts in work
Note: New NPP IPAC Verification events (Performance Verification) not yet Planned
Risk Handling and Mitigation
Assessment of impact and project plans
Stakeholders
Risk
Database
Likelihood &
Impact
Inputs
NDE
Preliminary
Risks
Risk
Survey
Prioritized
Risks
Risks & Risk
Handling
Analysis of
Consequences
Identify Risk
Handling &
Mitigation
NDE
Objectives
•
NDE Risk
Management
Plan and
Assessment
FY05
OMB 300
Risks
Mitigating steps in NDE’s current plans
–
–
–
–
–
–
–
•
Develop a risk management plan
For IT work, schedule control via earned value
management
Develop lifecycle cost and benefit estimates
Develop the project budget
Plan for needed resources
Design systems to support reliability requirements
Monitor NOAA and DoC security requirements
New risk mitigating activities
–
–
–
Develop and implement a quality management plan
to address system and data quality, quality assurance,
and quality control.
Develop and implement NDE continuity plans that
are coordinated among participating organizations.
Coordinate development of preliminary (pre-launch)
data with the IPO and instrument designers
27
Risk Management Summary
• Risks management plan will be
revised as risks are handled,
new risks are identified, or
stakeholder views change
– Continued input from
stakeholders and other
sources
– Developers have a critical
responsibility to identify
issues, risks, and challenges
and their potential impact on
operations
• Preliminary design review will
identify issues and challenges
for key design elements
28
Agenda
8:00 a.m.
Welcome
• Introduction/Background
J. Silva
8:15 a.m.
Introduction/Background
• Mission & Design Drivers
J. Silva
9:00 a.m.
Project Overview
• Architectural Overview
G. Goodrum
10:45 a.m.
NDE Context and Hardware
• Data Products
T. Schott
11:15 a.m.
Algorithm Development
12:00 p.m.
Lunch
1:00 p.m.
Data Handling System
2:30 p.m.
IT Security
3:00 p.m.
Communications Study
3:40 p.m.
Closing Remarks
4:00 p.m.
PDR Board Review of RFAs
29
Product Definitions
• Products delivered by NPOESS contractor
– xDRs
•
•
•
•
Raw Data Records (RDR)
Sensor Data Records (SDR)
Temperature Data Records (TDR)
Environmental Data Records (EDR)
– Intermediate Products (IP)
– Pre-planned Product Improvements (P3I)
• Products produced by NOAA using xDR
information
– Tailored xDRs and IPs
– NOAA Unique Products (NUPs)
30
NPOESS Products Requirements
Integrated Program Office (IPO)
Requirements Document
NPOESS Integrated
Operational Requirements
Document (IORD – II)
Dec 10, 2001
Contract Document
NPOESS Technical
Requirements Document
Deliverables
Sensor,
Temperature,
Environmental
Data Records
(xDRs)
NPOESS Data Exploitation (NDE)
NDE Product Matrix
NOAA Mission
Goal Needs
(CORL)
Line Office
Needs
NDE Product Development
Current
Polar
Products
(1) Tailored xDRs
(2) NOAA-unique
products (NUPs)
31
Products
Sample from Mission Goal
Line Office
Mission Goal Review
Version of Product Matrix
(CORL items in gray)
Master, W&W, Climate, Ecosystems, C&T spreadsheets
Motivation: Develop NPOESS products to meet all NOAA user requirements
32
NPP Product Summary
NPP
Totals
Data Records (xDRs/IPs/P3I)
39
NOAA Unique Products
59
Totals
98
33
Acquisition Strategy
Emphasis POES Mission Continuity
• Nunn-McCurdy process restructured
NPOESS acquisition efforts
– POES mission continuity might rely on NPP
data operationally
CALENDAR
YEAR 05 06
PM
07
N
08
09 10 11
12
N’
13
14
15
16
17
18
19
20 21
22
23 24
25
C1 (-)
NPP
34
Define NPP Products
• POES and EOS Mission Continuity
– Essential that we address these products
• Development products
– Under development and could go operational
prior to NPP launch
• New products
– Never provided to user community and not
under development within NESDIS
35
NPP Mission Continuity Products
NOAA-Unique Products
Tailored Products
CrIS Thinned Radiances
SST Anomalies
ATMS Radiances
Total Precipitable Water (ATMS)
Coral Reef Degree Heating
CrIS Radiances
Snow Cover (ATMS)
Coral Reef Bleaching
VIIRS Radiances
Precipitation Type/Rate (ATMS)
Tropical Rainfall Potential
OMPS Radiances
Surface Emissivity (ATMS)
Vegetation Fraction
Cloud Mask
Cloud Liquid Water (ATMS)
Hazard Support (Tropical)
Sea Surface Temperature (SST)
Sea Ice Cover/Concentration
Hazard Support (Volcano)
Ozone Profile
Snow Water Equivalent (ATMS)
Total Ozone (CrIS)
Ozone Total Column
Ice Water Path (ATMS)
Blended Ozone
Snow Cover
Land Surface Temperature
Outgoing Longwave Radiation
Imagery
Temperature Profiles (ATMS)
Outgoing Longwave Radiation
Ocean Color/Chlorophyll
Moisture Profiles (ATMS)
Absorbed Radiation
Vegetation Index
Blended Snow Cover
Rainfall Prediction
Active Fires
Harmful Algal Blooms
Tropical Cyclone Intensity
Atmospheric Temperature Profile
Regional Ocean Color
Tropical Rainfall Potential
Atmospheric Moisture Profile
Blended SST
Vegetation Fraction
Aerosol Optical Thickness
Surface Type & Vegetation Cover
Surface Albedo
Cloud Cover/Layers
36
NPP Development Products
NOAA-Unique Products
Tailored Products
CrIS Cloud Cleared Radiances
Aerosol Particle Size
Clear Sky Radiances (VIIRS)
Cloud Top Temperature
Polar Winds (VIIRS)
Cloud Top Pressure
Vegetation Health
Land Surface Temperature (VIIRS)
Vegetation Moisture
Drought Indices
Vegetation Thermal Conditions
Leaf Area Index
Fire Potential
SST (AVHRR-like)
Aerosol (AVHRR-like)
Carbon products
37
NPP New Products
NOAA-Unique Products
Tailored Products
Integrated xDRs at CrIS Resolution
Cloud Base Height
Cloud Liquid Water Path (VIIRS)
Cloud Effective Particle Size
Cloud Ice Water Path (VIIRS)
Cloud Optical Thickness
Cloud Top Temperature (VIIRS)
Cloud Top Height (VIIRS)
Inversion Strength and Height
Ice Surface Temperature
Net Heat Flux
Sea Ice Characterization (VIIRS)
Suspended Matter
Atmospheric Pressure Profile
38
Agenda
8:00 a.m.
Welcome
8:15 a.m.
Introduction/Background
9:00 a.m.
10:45 a.m.
11:15 a.m.
• Project Overview
G. Sloan
• Requirements Mgmt
L. Fenichel
• Development Approach
E. Wilson
• Tool Selection
E. Wilson
Project Overview
NDE Context and Hardware
Algorithm Development
12:00 p.m.
Lunch
1:00 p.m.
Data Handling System
2:30 p.m.
IT Security
3:00 p.m.
Communications Study
3:40 p.m.
Closing Remarks
4:00 p.m.
PDR Board Review of RFAs
39
A Reminder
Parts of NPP, NPOESS, and NDE are
subject to:
– ITARs (International Trafficking in Arms
Restrictions)
– “NOFORN” Classification
40
Topics
•
•
•
•
•
•
•
Requirements Management
Development Approach
Algorithm Development
Data Handling System
IT Security
Data Distribution
The Way Forward
41
Master Phasing Schedule
42
NDE Baselined Documents
Document
Status
NDE Concept of Operations
Draft Delivered 8/24/2006
Draft Delivered 11/7/2006 (Incorporated RIDS from Peer
Review)
NDE Federal Enterprise
Architecture
Draft Delivered 8/24/2006
NDE Data Distribution
Conceptual Design
Draft Delivered 8/24/2006
NDE Stake Holder Survey
Summary Status 2006
Draft Delivered 8/24/2006
Draft Re-Delivered 8/28/2006
NDE Network Services Design
Draft Delivered 8/24/2006
NDE System/Subsystem Design
Description
Draft Delivered 8/24/2006
NDE Logical and Geographical
Connectivity Design
Draft Delivered 8/24/2006
Standards for NDE Algorithm
Development, Delivery,
Integration & Test
Draft Delivered 8/24/2006
43
NDE Baseline Documents
(Cont’d)
Document
Status
Project Plan
Draft Delivered 8/2004
Draft Delivered 8/2005
Draft Delivered 8/2006
Draft Delivered 11/2006
NDE Systems Requirement
Specification
Draft Delivered 11/7/2006
NDE Configuration Management
Plan
Draft Delivered 5/18/2006
Draft Delivered 6/30/06
Draft Delivered 8/30/2006
Risk Management Plan
Delivered 7/14/2006
44
Management Approach
• Staff the NDE Design Team with experienced
professionals
• Use design tools
• Prototype of Development Environment
– IBM p570 using AIX
• Use NPP as the NDE risk reduction mission
• Maximize use of COTS and GOTS (minimize
custom code)
• Collaborate with similar, current projects
• Develop prototypes to validate requirements and
design
• Sell-off requirements as early as possible
45
Lessons Learned from NASA’s
EOSDIS Core System
• Integrate Algorithms with the Data Handling System early in the life
cycle
• Test the system under full operational load – data driven systems
behave in strange ways
• Build in Operator Dashboard and System Metrics for reporting
– NetIQ and CA’s Unicenter are candidates
• Configuration Parameters
– Put in Database for change control, audit trail
– Document CPs, min/max values, default, suggested values
• Use “Rolling Wave” technology refresh approach
– Constant effort
– Keeps budgets flat – no large peaks every 5 years
• Just in Time Hardware buys
46
NDE Design Assumptions
• All NDE users are registered users
• Users get data by entering an NDE subscription
• Subscriptions have two types
– Standing Order (no expiration date)
– Ad-Hoc (covers a limited time period)
• Subscription to NOAA-unique products to be archived to CLASS will
be determined by Archive Review Board
• NDE will subscribe to all IDPS xDRs (in lieu of implementing
complex logic using IDPS API to order only xDRs needed)
• NDE will not distribute RDRs in near-real time to users (exception:
Telemetry)
– Users will need to request RDRs from CLASS
• Product latency is customer and product specific
47
Data Access
• NDE will flag customers as authorized for data or
not during data denial
– Use Initial Joint Polar System (IJPS) Data Denial
Implementation Plan for initial authorization guidance
• NDE will maintain a customer database that will
contain sufficient attributes in order to set flag
• Restricted data will be delayed for subscriptions
from unauthorized customers
– Timeliness more an issue for NPOESS than NPP
• Only authorized users will be notified of data
access status
– End User License Agreement with customer restricts
redistribution
48
Agenda
8:00 a.m.
Welcome
8:15 a.m.
Introduction/Background
9:00 a.m.
10:45 a.m.
11:15 a.m.
• Project Overview
G. Sloan
• Requirements Mgmt
L. Fenichel
• Development Approach
E. Wilson
• Tool Selection
E. Wilson
Project Overview
NDE Context and Hardware
Algorithm Development
12:00 p.m.
Lunch
1:00 p.m.
Data Handling System
2:30 p.m.
IT Security
3:00 p.m.
Communications Study
3:40 p.m.
Closing Remarks
4:00 p.m.
PDR Board Review of RFAs
49
Requirements
Management Matrix
ID
Section
SRS203
3.14.10
SRS94
SRS201
Requirement
Development Lifecycle Tools - The Contractor will specify
a suite of proven development lifecycle tools to enhance
NESDIS capabilities in performing developmental and
software maintenance tasks. The documentation will
demonstrate that the selected tools are widely supported
in the remote sensing software industry and the most
likely to be known by future NESDIS support staff.
Technologies in this category are: CASE tools, modeling
tools, 4th Generation Languages, Testing tools, and
Requirements Tracking tools.
Contract
SE3
3.14.6
SEI Capability Maturity Model - The Contractor shall design
the System so that its management capabilities can be
evaluated in terms of the Software Engineering Institute's
(SEI) Capability Maturity Model (CMM), with the goal of
Level 2 certification during proposal evaluation and Level
3 certification three years after contract award.
SM1
3.14.8
NOAA IT Best Practices - The System shall be designed
and built with NOAA IT "Best Practices" guidance from the
NESDIS Information Technology Architecture Team (ITAT).
SE8
50
Requirements Management –
The Process
• Define Business Objectives
• Contained in Contract Requirements Matrices under Desired
Outcomes and Performance Standard columns
• Additional Objectives detailed in the Concept of Operations
• Automate Requirements Analysis, maintain Traceability (Use DOORS)
• Reduce Ambiguity
• Contractual Requirements reviewed, System Requirements Spec
(SRS) created
• Derive Requirements to further capture NDE functionality
• Use Case Driven Process
• Cause/Effect Tables
• Automate using UML compliant tools
• Domain Expert Reviews and Refinements
• Several Iterations
• Capture and Formalize Detailed Requirements
• Test Cases generated
• ‘Final Round’ of Domain Expert Reviews
51
NDE Requirement Allocations
Allocations
Number of SRS
Requirements
Customer Services
16
Ingest
24
Production
26
Distribution
25
Product Management
22
Common Services (Infrastructure)
50
System Monitoring and Control
22
Security
1
Documentation
12
52
NDE Requirements
Traceability
ID
Section
Short Title
Contract
Allocation
Use
Case
Test
Case
SRS62
3.2.1.3.2
SARSAT Telemetry from IDPS
XF1
Ingest
UC101
TC25
SRS63
3.2.1.3.3
ADCS Data from IDPS
XF1
Ingest
UC101
TC26
SRS58
3.2.1.3.4
Product Subscriptions to
IDPS
XF1
Ingest
UC102
TC44
SRS101
3.2.2.3.1
Available Data Product
Projections
PG5
Production
UC181
TC124
SRS102
3.2.2.3.2
Available Data Product
Aggregations
PG6
Production
UC182
TC131
• Maintained in DOORS Tool with Active Links to other NDE Documents
• Telelogic Tool Suite (DOORS, TAU Developer)
• Use Cases Mapped
• Test Cases Mapped
• Test Results Tracked
53
Challenges Matrix
Challenge
Related
Requirement
Impact
Mitigation
Maintain Requirements
Traceability throughout the
Project Life Cycle
(SRS201) 3.14.8
NOAA IT Best
Practices
Potential testing gaps
and schedule delays as a
result
Use of Tools
(SRS201/Automated Tool
Suite)
Full specification of NDE
System Elements and
Components
N/A
Cost, quality, schedule
Employ a methodology
(SRS204) where domain
experts are involved early
in the process, delivery at
CDR
54
Agenda
8:00 a.m.
Welcome
8:15 a.m.
Introduction/Background
9:00 a.m.
10:45 a.m.
11:15 a.m.
12:00 p.m.
• Project Overview
G. Sloan
• Requirements Mgmt
L. Fenichel
• Development Approach
E. Wilson
• Tool Selection
E. Wilson
Project Overview
NDE Context and Hardware
Algorithm Development
Lunch
1:00 p.m.
Data Handling System
2:30 p.m.
IT Security
3:00 p.m.
Communications Study
3:40 p.m.
Closing Remarks
4:00 p.m.
PDR Board Review of RFAs
55
Development Approach
Requirements
ID
Section
SRS204
3.10.1
The Contractor shall identify a widely accepted software
engineering methodology to be used on the project.
SE12
3.14.6
The Contractor shall design the System so that its
management capabilities can be evaluated in terms of the
Software Engineering Institute's (SEI) Capability Maturity
Model (CMM), with the goal of Level 2 certification during
proposal evaluation and Level 3 certification three years
after contract award.
SM1
3.9.2
The Contractor shall evaluate candidate System Elements
for operational fitness using Unit, Integration, Regression,
Stress (load), and End-to-End System testing.
SE4
3.9.2.1
Each algorithm for creating NOAA-Unique products will be
described in terms of explicit, expected test results prior to
the installation of the NOAA-supplied algorithm on the
operational product generation system. The NOAA-Unique
algorithms must satisfy these test requirements.
PG8
3.11.6
The Contractor shall cooperate with algorithm developers
to identify System Test procedures, standards, and the
criteria to be applied in determining a system elements'
fitness for operational status.
SE4
SRS94
SRS172
SRS173
SRS182
Requirement
Contract
56
Development Approach
Requirements Based Testing
What is it?
Requirements Based Testing (RBT) is a System Implementation
Methodology that
Substantially Reduces the Risk of
Building the Right System to the “Wrong” Requirements !
Why are we Concerned about That ?
–
–
–
–
Over half all software project defects originate in the requirements phase
82% of application re-work is related to requirements errors
Only 54% of initial project requirements are actually realized
Requirements problems account for 44% of project cancellations
Statistics by James Martin and others, taken from “Eliminate the Testing Bottleneck”, Borland White
Paper, August, 2006, p. 4.
57
The Methodology of
Requirements Based Testing
(RBT)
It’s about Testing as an Integral Step of Implementation -- not a Separate
Phase
– Design Tests before Designing the Software -- the Test Cases become the
Ultimate Statement of the Develops’ Requirements
– Iterate the Requirements-to-Test Case Loop with Users and Domain
Experts until they concur that successful Test Execution will produce the
result they want – not necessarily what they originally specified!
…to insure that:
• What we Build is What we Say
• and What we Say is What we Mean
58
Traditional Implementation
Hand-Off Phases
Natural Language
Requirements
Design
Test Plans
Code
• Analysts talk to Domain Experts to express Natural Language
Requirements
• S/W Designers Interpret these into Design, which is then interpreted into
Code
•Independent Test Team Interprets Requirements to develop Test Plans
The Result: Unresolved ambiguities and inconsistencies between what
was developed, what is tested, and what is really needed!
59
RBT Focuses on Formalized
Requirements & Test Cases
Requirements Analysts
Users
Create
Logical Test
Cases
Create Formal Req’ts
from Natural Language
Review/Fix Req’ts &
Logical Test Cases
Formal Req’ts
and
Test Case
Repository
Study Logical Test Cases
Review Design versus Validated
Test Cases
Review Code versus Validated
Test Cases
Developers
Domain Experts
Review/Fix/Validate Req’ts
& Logical Test Cases
Study Logical Test Cases
Complete Physical Test Cases
Test Experts
60
Sample Technique for
Formalized Requirements
REQ’T ID
SRS80
CAUSES



System is in Degraded Operations Mode
Customer meets Pre-Defined Criteria [TBD]
Customer has Pending Data Request
EFFECTS


Pending Data is distributed to
Customer
Customer’s Pending Data
Subscriptions are Ignored while
Degraded Operations Mode
persists
62
Development Approach
Challenges
Challenge
Related
Requirement
Impact
Mitigation
Build the NDE Systems as
we Say, and Say what we
Mean them to Be
SRS94, SRS173,
SRS182
Unresolved ambiguities
and inconsistencies
between what gets
developed, what gets
tested, and what is really
needed!
Utilize Requirements
Based Testing (RBT)
Methodology
Find a Suite of
Development Tools that
Support the RBT
Implementation Workflow
SRS203
Worst case: develop
RBT artifacts manually
(using only Excel, Visio,
Word) and develop a
homegrown database to
track baselines, team
member updates, and
requirements to test
traceability
Identify the Development
Functionalities needed to
Support RBT; establish
Criteria to Evaluate Tools’
performance w.r.t the
Functions, taking into
account interoperability
between Tools in a
Candidate Suite
63
Agenda
8:00 a.m.
Welcome
8:15 a.m.
Introduction/Background
9:00 a.m.
10:45 a.m.
11:15 a.m.
• Project Overview
G. Sloan
• Requirements Mgmt
L. Fenichel
• Development Approach
E. Wilson
• Tool Selection
E. Wilson
Project Overview
NDE Context and Hardware
Algorithm Development
12:00 p.m.
Lunch
1:00 p.m.
Data Handling System
2:30 p.m.
IT Security
3:00 p.m.
Communications Study
3:40 p.m.
Closing Remarks
4:00 p.m.
PDR Board Review of RFAs
64
Tool Selection Requirements
ID
Section
Requirement
Contract
SRS93
3.8.3.2
The NDE Processing System Design will use COTS and
Open Source software where it is possible, practical, and
approved by the Government.
SE10
SRS203
3.14.10
The Contractor will specify a suite of proven development
lifecycle tools to enhance NESDIS capabilities in
performing developmental and software maintenance
tasks. The documentation will demonstrate that the
selected tools are widely supported in the remote sensing
software industry and the most likely to be known by
future NESDIS support staff. Technologies in this
category are: CASE tools, modeling tools, 4th Generation
Languages, Testing tools, and Requirements Tracking
tools.
SE3
SRS215
3.10.2
The contractor shall develop the data processing
elements of the future NDE system using the latest
proven technologies (programming languages, CASE
tools, object repositories, data base management
systems, etc.) that are appropriate for remote sensing
data processing.
SE13
65
IT Development Tools
Functional Categories
SUMMARY OF FUNCTIONAL CATEGORY SCORES
1. Interoperability (with respect to a Suite, and with Common Interchange Tools)
0
2. Requirements Specification & Maintenance
0
3. Configuration Management
0
4. Requirements Verification
0
5. Engineering Management/Team Support
0
6. General Architectural Design and Modeling
0
7. Data Modeling
0
8. Business Process Modeling
0
9. Software Analysis, Design, and Construction
0
10. Extensibility
0
11. User Interface
0
12. OS/Network Support - Tool Server
0
13. Tool Administration & Vendor Support
12
14. Documentation, Training, and Ongoing Education
0
15. Vendor Comprehension & Licensing Offer
0
67
Tool Selection Methodology
• Goal:
– To Define a Process for Trade-Off Comparisons
between IT Development Tools
• That:
– Establishes a Consistent Approach regardless of
the Individuals performing the Evaluation
– Produces Quantitative Results for Comparison and
Justification
– is Conducted as Objectively as Possible
• . . . and can also be applied to:
– Architecture Operational Components
– Science Development Tools
68
Sample Section
IT Development Tool
Evaluation Worksheet
13. Tool Administration & Vendor Support
13.1
13.2
13.3
13.4
13.5
13.6
13.7
12
Ease of Installation
(server/client combined)
50
<none>
0
10
Degree of Site/User
Configurability
50
<none>
0
10
Vendor includes personal
tool setup assistance in the
purchase price
90
<none>
0
10
Number of Release Defects
Reported by Vendor
50
<none>
100
0
Number Un-reported Defects
uncovered during Evaluation
of Release
80
<none>
10
0
Number of old versions of
the tool currently supported
65
Enter
the
number:
1,2,3,4…
0
5
Vendor provides online help
support tool
50
<none>
0
10
69
We Attempt to Establish an
Evaluation Framework that is
as Objective as Possible
• We evaluate each tool with respect to all functional categories, and
develop our own profile of a tool’s capabilities – giving each tool a
numeric score for each functionality
• For a suite of tools, we calculate functional category scores by
combining scores for all tools in the suite for each category:
Suite Functional Score = Min(Tool Scores) for a
Common Function
“weakest link”
Suite Functional Score = Max(Tool Scores) for a
Specialized Function
“strongest component”
• Similar approach applied to:
- Science Development Tools - Architectural Components -
K. Tewari
A. Al-Jazrawi
70
IT Development Tool Suites
Under Consideration
IBM Rational:
Requisite Pro, Clear Case, Clear Quest, Software Architect, (Test
Manager)
Telelogic:
DOORS, Synergy CM, Synergy Change, System Architect, Tau
Developer, (Rhapsody), … plus Mercury Test Director
Borland:
Caliber DefineIT, Caliber RM, Silk Central, Together, StarTeam
71
Tool Selection Challenges
Challenge
Related
Requirement
Impact
Mitigation
Find a Suite of
Development Tools that
Interoperate smoothly,
allowing us to move from
step to step or backwards
without manual cut-andpaste transfer of data
SRS203
Vendor Tool Suites are a
mix of in-house products
and products from buyouts, not as well
integrated as heralded;
members of some suites
don’t even run on the
same set of platforms
Our evaluation
methodology makes
special provisions to
evaluate a Suite as a
whole; Tool
Interoperability is scored
w.r.t the Suite Context;
Suite score for that and
other common functions
is taken to be the
“weakest link” of the
Suite members
Find a Suite of
Development Tools that can
be expected to be
supported several years
into the future.
SRS203
IT Tool development is
currently a very dynamic
area with many
contenders, some of them
with outstanding new
products
Our evaluation criteria
include vendor stability
factors, as well as
number years experience
with the tool (e.g. after a
buyout); our down-select
list is composed of 3 of
the most well-known,
stable vendors in this
field.
72
Tool Selection Challenges
Challenge
Business Process
modeling tools are closely
tied to their vendor’s
middleware for collection
of information to feed the
model; they are not
interchangeable to other
vendors’ middleware
Related
Requirement
SRS215
Impact
Mitigation
It could be that our first
choice for modeling NDE
business activities would
force us toward middleware
that might be inadequate
for our near real-time
requirements
We will evaluate the
middleware architectural
components first, as that
component will have the
broadest impact on
overall system
performance; however,
before making a final
decision we will evaluate
the Business Process
tools to check that we
aren’t forced toward an
unacceptable product;
we may have to balance
the gap in tools with the
gap in architectural
components.
73
Agenda
8:00 a.m.
Welcome
8:15 a.m.
Introduction/Background
9:00 a.m.
Project Overview
10:45 a.m.
11:15 a.m.
• Context
G. Roth
• Environments
G. Roth
• Hardware
G. Roth
NDE Context and Hardware
Algorithm Development
12:00 p.m.
Lunch
1:00 p.m.
Data Handling System
2:30 p.m.
IT Security
3:00 p.m.
Communications Study
3:40 p.m.
Closing Remarks
4:00 p.m.
PDR Board Review of RFAs
74
NPOESS Context Diagram
AFWA
(Air Force
Weather Agency)
(Supports NPP)
FNMOC
NPOESS
NESDIS
(Fleet Numerical
Meteorology and
Oceanography Center)
(National Polar-orbiting Operational
Environmental Satellite System)
(National Environmental
Satellite Data and
Information Service)
(IDPS)
(Supports NPP)
NAVOCEANO
(Naval Oceanographic
Office)
75
IDPS Context Diagram
SDS
(Science Data
Segment)
(NASA)
NSIPS
(NPOESS Science
Investigator-led
Processing System)
(cal val)
NESDIS
IDPS
(Interface Data
Processing Segment)
(at NOAA)
ESPC
SAN
NDE
CLASS
(Comprehensive Large
Array-data Stewardship
System)
(archive)
76
NDE Context Diagram
Users
ESPC
(Environmental Satellite Processing Center)
IDPS
(at NOAA)
NDE
CLASS
(LTA)
(Long Term Archive)
Algorithm
Developers
(STAR)
(Center for Satellite
Applications and Research)
77
NDE Environment Requirements
ID
Section
SRS83
3.14.3
SRS237
SRS85
SRS84
SRS86
Requirement
Contract
The System shall be designed to support Operational,
System Test, and Development Environments.
SE2
3.14.3.1
The Contractor shall provide an Operational Environment
design that lowers the cost and risks of generating and
distributing NPOESS-derived products to customers.
SE2
3.14.3.2
The System shall provide the capability to support the
development of the Data Handling System and the
development and integration of Scientific Algorithms in a
segregated Development Environment.
I3
3.14.3.3
During the NPP mission, the System Test Environment will
be segregated in a manner that supports "QuasiOperational" product generation and distribution (QuasiOperational is defined as 24 X 7 automated product
generation and distribution with 8 X 5 Science and
Operations support services).
I1
3.14.2.3
- During the NPP mission, the System will have the capability
to support product volumes of 4 TB/day.
- During the NPOESS C1 mission, the System will have the
capability to support product volumes of 8 TB/day.
- During the NPOESS C2 mission, the System will have the
capability to support product volumes of 12 TB/day.
I1
78
NDE System
•
IT Development Environment
– Where the Data Handling System (DHS) is developed
•
Science Development & Integration Environment
–
–
–
–
–
•
System Test Environment
–
–
–
–
•
Science Algorithm Development Environment
Science Algorithms may be delivered from STAR Collaborative Environment (CE)
Algorithms integrated with Data Handling System (DHS)
Algorithm Performance Tuning
Functional, end-to-end testing of NDE System
Stress Testing, Regression Testing and Operations Acceptance Testing
System and Algorithm Performance Testing
Serves as Backup for Operations Environment
Augmented to make products during NPP (quasi-operational)
Operations Environment
–
–
–
–
DHS and Algorithms
High Availability
Low NDE Latencies
High Product Volume
79
NDE System
Science
Algorithm
Development &
Integration
Environment
IT Development
Environment
System
Test
Environment
Configuration
Management
Environmental Satellite Processing Center
Operations
Environment
(NPOESS)
NDE
Development
Environment
NDE
System
Test/Backup
Environment
NDE
Operational
Environment
Shared Capabilities, Common Standards
80
DHS Promotion & Integration Process
Science
Algorithm
Development &
Integration
Environment
IT Development
Environment
4
DHS
Delivery
2
System
Test
Environment
DHS Build
Delivery
3
5
6
Request for
DHS Build
DHS Delivery
Request for DHS
Promotion Delivery
Operations
Environment
(NPOESS)
1
Configuration
Management
DHS Promotion
to Operations
81
Algorithm Promotion &
Integration Process
STAR
Collaborative
Environment
(SCE)
Science
Algorithm
Development &
Integration
Environment
IT Development
Environment
2
1
Algorithm
Build Delivery
System
Test
Environment
3
Algorithm Delivery
Request for Algorithm
Promotion Delivery
4
Operations
Environment
(NPOESS)
Request for
Algorithm
Build
Configuration
Management
Algorithm Promotion
to Operations
5
NDE
82
Hardware: Design &
Development Environment
(Phase 1)
ESPC
Network
CITS Administration LAN
StorNext
Design
Development Environment & CM
Automated Tool Servers
Storage
Processing
Dell PE1850 Servers
ESPC SAN Expansion
IBM p570
Dual 3.0GHz
146 GB SATA Drives
16 x 2.2 GHz CPUs
4 GB RAM
2.33 TB (usable)
32 GB RAM
2 Win2003 & 1 RHEL4
StorNext FS Server
AIX 5.3
42U Rack
42U Rack
42U Rack
83
“Rolling Wave” Capacity &
Upgrade Planning
Data
Direct
Networks
Disk
Storage
N
Data
Direct
Networks
Disk
Storage
+
IBM
p570
N
Operations
n
IBM
p570
+
SAN Disk
Storage:
Ingest &
Distribution
n
CPUs:
Processing
& Database
N + n < 2N
additional capacity
84
IBM Virtualization
Virtual I/O Server
Dynamically resizable
6
CPUs
4
6
CPUs CPUs
Ethernet
sharing
Virtual I/O
paths
Hypervisor
PLM partitions
Manager
Server
LPAR 1
AIX 5L V5.2
LPAR 2
AIX 5L V5.3
PLM agent
PLM agent
Hypervisor
AIX 5L V 5.3
AIX 5L V5.3
Storage
sharing
AIX 5L V5.3
IVM
AIX 5L V5.3
i5/OS AIX 5L AIX 5L
Linux V5R3** V5.2
V5.3
Linux
Micro-Partitioning
Linux
Virtual I/O
server
partition
2
1
CPUs CPU
AIX 5L V5.3
1
CPU
– Shared Ethernet
– Shared SCSI and
Fibre Channel-attached disk
subsystems
– Supports AIX 5L V5.3 and
Linux* partitions
Micro-Partitioning
– Share processors across
multiple partitions
– Minimum partition 1/10th
processor
– AIX 5L V5.3, Linux*, or i5/OS**
Partition Load Manager
Unmanaged
partitions
LPAR 3
Linux
– Balances processor and
memory request
Managed via HMC or IVM***
* SLES 9 or RHEL AS 4 and above
**Available on selected p5-570, p5-590 and p5-595 models
***IVM on p5-560Q and below
85
NDE Design Challenges
Related
Requirement
Impact
Mitigation
IDPS requires use of
StorNext to write to ESPC
SAN vs ESPC security
zones
Imposed on NDE by
IDPS and ESPC
Multiple NDE hosts also
need to “see” the same
file system on the ESPC
SAN that IDPS uses;
therefore NDE is also
required to use StorNext
as its metadata server
ESPC (Brian Callicott) is
pursuing technical
solution
Processing multiple read &
writes to & from SAN
(utilizing StorNext) may not
meet product latency
requirements
SRS 133
3.2.5.4
Data Product
Latency Table
CD9
File I/O to/from SAN may
not meet latency
requirements.
Early testing of StorNext
from IDPS to the ESPC
SAN and early interface
testing of StorNext from
the ESPC SAN to NDE.
Potential risk of not having
a Product Technical
Baseline and model may
impact the ability to
correctly size the number
of CPUs, RAM, Disk, and
internal networks required
to meet latency
requirements.
SRS 133
3.2.5.4
Data Product
Latency Table
CD9
Insufficient hardware
sizing of future System
Test and Operations
Environments or
increased spending to
overcompensate for lack
of information
Challenge
Develop a Product
Technical Baseline and
model with Product
Development Lead Tom
Schott
86
Agenda
8:00 a.m.
Welcome
8:15 a.m.
Introduction/Background
9:00 a.m.
Project Overview
10:45 a.m.
11:15 a.m.
Building Blocks and Hardware
• Research to Operations
M. McHugh
• SADIE
K. Tewari
Algorithm Development
12:00 p.m.
Lunch
1:00 p.m.
Data Handling System
2:30 p.m.
Communications Study
3:30 p.m.
Closing Remarks
4:00 p.m.
PDR Board Review of RFAs
87
Research to Operations
• GOAL: Faster, more efficient transition of research
to operations.
• HOW: By facilitating interaction between STAR and
NDE developers
– Similar:
• Standards;
• Configuration management (CM) tools;
• CM procedures.
– Common:
• Libraries, error handling, development and visualization tools etc.
– Compatible
• Architectures.
88
Similar Environments
STAR Collaborative
Environment (SCE)
NDE
Environments
STAR IT
Advisory
Committee
Compatible
Architectures
NDE Architect
STAR
Configuration
Management
Group
Standards and
Processes
NDE Design
Team
STAR
Developers
STAR CM
Group
Software, Libraries
and Tools
NDE Design
Team
89
Research to Operations
STAR Collaborative Environment (SCE)
Create the Delivered
Algorithm Package
(DAP) for an algorithm
Integrated
Product Team
Send DAP to the SADIE
90
Research to Operations
STAR Collaborative Environment (SCE)
Create the Delivered
Algorithm Package
(DAP) for an algorithm
Integrated
Product Team
Send DAP to the SADIE
91
Science Algorithm Development and
Integration Environment (SADIE)
Receive DAP from
outside of SADIE
Place received DAP under
configuration management
(CM) control
Ensure DAP has
correct format
CM Manager
Baseline the DAP
Integrated
Product Team
Compile algorithm
Execute algorithm
using its DAP
Integrate algorithm into
Data Handling System
NDE
Development
Team
92
Science Algorithm Development and
Integration Environment (SADIE)
Receive DAP from
outside of SADIE
Place received DAP under
configuration management
(CM) control
Ensure DAP has
correct format
CM Manager
Baseline the DAP
Integrated
Product Team
Compile algorithm
Execute algorithm
using its DAP
Integrate algorithm into
Data Handling System
NDE
Development
Team
93
Science Algorithm Development and
Integration Environment (SADIE)
Receive DAP from
outside of SADIE
Place received DAP under
configuration management
(CM) control
Ensure DAP has
correct format
CM Manager
Baseline the DAP
Integrated
Product Team
Compile algorithm
Execute algorithm
using its DAP
Integrate algorithm into
Data Handling System
NDE
Development
Team
94
Science Algorithm Development and
Integration Environment (SADIE)
Receive DAP from
outside of SADIE
Place received DAP under
configuration management
(CM) control
Ensure DAP has
correct format
CM Manager
Baseline the DAP
Integrated
Product Team
Compile algorithm
Execute algorithm
using its DAP
Integrate algorithm into
Data Handling System
NDE
Development
Team
95
Science Algorithm Development and
Integration Environment (SADIE)
Receive DAP from
outside of SADIE
Place received DAP under
configuration management
(CM) control
Ensure DAP has
correct format
CM Manager
Baseline the DAP
Integrated
Product Team
Compile algorithm
Execute algorithm
using its DAP
Integrate algorithm into
Data Handling System
NDE
Development
Team
96
SCIENCE ALGORITHM DEVELOPMENT
AND INTEGRATION ENVIRONMENT
(SADIE)
Receive DAP from
outside of SADIE
Place received DAP under
configuration management
(CM) control
Ensure DAP has
correct format
CM Manager
Baseline the DAP
Integrated
Product Team
Compile algorithm
Execute algorithm
using its DAP
Integrate algorithm into
Data Handling System
NDE
Development
Team
97
Science Algorithm Development and
Integration Environment (SADIE)
Receive DAP from
outside of SADIE
Place received DAP under
configuration management
(CM) control
Ensure DAP has
correct format
CM Manager
Baseline the DAP
Integrated
Product Team
Compile algorithm
Execute algorithm
using its DAP
Integrate algorithm into
Data Handling System
NDE
Development
Team
98
System Test Environment
Install Algorithm
Test Algorithm
CM Manager
Promote to Operations
Operations Environment
Integrated
Product Team
Install Algorithm
NDE
Development
Team
Monitor Algorithm
Performance
ESPC CCB
99
System Test Environment
Install Algorithm
Test Algorithm
CM Manager
Promote to Operations
Operations Environment
Integrated
Product Team
Install Algorithm
NDE
Development
Team
Monitor Algorithm
Performance
ESPC CCB
100
System Test Environment
Install Algorithm
Test Algorithm
CM Manager
Promote to Operations
Operations Environment
Integrated
Product Team
Install Algorithm
NDE
Development
Team
Monitor Algorithm
Performance
ESPC CCB
101
System Test Environment
Install Algorithm
Test Algorithm
CM Manager
Promote to Operations
Operations Environment
Integrated
Product Team
Install Algorithm
NDE
Development
Team
Monitor Algorithm
Performance
ESPC CCB
102
System Test Environment
Install Algorithm
Test Algorithm
CM Manager
Promote to Operations
Operations Environment
Integrated
Product Team
Install Algorithm
NDE
Development
Team
Monitor Algorithm
Performance
ESPC CCB
103
Agenda
8:00 a.m.
Welcome
8:15 a.m.
Introduction/Background
9:00 a.m.
Project Overview
10:45 a.m.
11:15 a.m.
Building Blocks and Hardware
• Research to Operations
M. McHugh
• SADIE
K. Tewari
Algorithm Development
12:00 p.m.
Lunch
1:00 p.m.
Data Handling System
2:30 p.m.
Communications Study
3:30 p.m.
Closing Remarks
4:00 p.m.
PDR Board Review of RFAs
104
Science Algorithm Development &
Integration Environment (SADIE)
• Has similar components and configuration as the IT,
System Test, and Operational environments
• Uses common CM and Defect Tracking tools as other
environments
• Accessible locally and remotely to algorithm developers
• Supports development, integration with DHS & test of
new algorithms and those delivered from STAR
Collaborative Environment (SCE)
• Supports a suite of software development and science
tools (COTS, GOTS, etc.)
• Receives Delivered Algorithm Package (DAP) from SCE
105
SADIE
• SCE users receive
- Access and training in use of SADIE
- Defect Reports
• Supports development of additional science tools and
applications (i.e., validation of products, determination of
coefficients, etc.)
• Supports trouble-shooting of product generation failures
in System Test and Operational Environments
• Supports algorithm functional and regression testing
• Supports fine tuning of algorithms for meeting latency
goals in System Test and Operational Environment
106
Candidate Science Development
& Integration Tools
•
•
•
•
•
•
•
•
•
•
ArcExplorer
ArcInfo
ArcView
CDAT
EDGEIS
Geomatica
GeoTIFF
GrADS
HDF4 Tools
HDF5 Tools
•
•
•
•
•
•
•
•
•
•
IDL/Envi
IMSL
MATLAB
McIDAS
netCDF
OPeNDAP
PV-WAVE
SAS
TeraScan
WXP
107
Science Algorithm Development,
Delivery, Integration & Test
Standards
• Algorithm Development Standards
– Example: Use Similar Development and Test Environments
• Algorithm Delivery Standards
– Example: Standardized Algorithm Delivery Package
• CM and Defect Tracking Standards
– Example: Algorithm Developers and NDE use same CM and Defect
Tracking Tools
• Algorithm Input Standards
– Example: Production Rules Not Hard-coded in Science Algorithms
• Algorithm Processing Environment Standards
– Example: Customized Toolkit Containing Utilities
• Algorithm Output Standards
– Example: Common File Format for All NOAA-Unique Products
108
Design Challenges
Challenges
Related
Requirement
Agreement on Standards…
Adherence to Standards…
SE14
• Provide low NDE Latency
times for products
(minutes)
• NDE Latency largely
determined by algorithm
performance
• Algorithms are developed
by another part of NESDIS
and sometimes in another
environment
SRS 10 3.3.3
Impact
Mitigations
Delays in research to
operations
Collaboration w/STAR
Fail to achieve major goal
of NDE
• Integrate algorithms
and DHS as soon as
possible
• Algorithm Development,
Delivery, Integration and
Test Standards being
developed jointly with
STAR
• Make STAR
Collaborative
Environment and SADIE
as alike as possible to
facilitate Delivered
Algorithm Package (DAP)
109
Agenda
8:00 a.m.
Welcome
8:15 a.m.
Introduction/Background
9:00 a.m.
Project Overview
10:45 a.m.
NDE Context and Hardware
11:15 a.m.
Algorithm Development
12:00 p.m.
Lunch
1:00 p.m.
Data Handling System
2:30 p.m.
IT Security
3:00 p.m.
Communications Study
3:40 p.m.
Closing Remarks
4:00 p.m.
PDR Board Review of RFAs
110
Agenda
8:00 a.m.
Welcome
8:15 a.m.
Introduction/Background
9:00 a.m.
Project Overview
10:45 a.m.
NDE Context and Hardware
11:15 a.m.
Algorithm Development
12:00 p.m.
Lunch
• External Interfaces
E. Wilson
1:00 p.m.
Data Handling System
• DHS Architecture
E. Wilson
2:30 p.m.
IT Security
• Common Services
P. MacHarrie
3:00 p.m.
Communications Study
• Subsystem Design
A.Al-Jazrawi
3:40 p.m.
Closing Remarks
4:00 p.m.
PDR Board Review of RFAs
111
External Interface Requirements
ID
SRS243
SRS244
SRS10
Section
Requirement
Contract
3.3.1
IDPS Data Acquisition - The System shall provide the
capability to acquire all xDRs, Intermediate Products,
SARSAT Telemetry, A-DCS, ancillary, and auxiliary data
and metadata from IDPS.
XF1
3.3.2
External Ancillary Data Acquisition – The System will
provide the capability to configure ancillary data
acquisition streams from external sources.
PG9
3.3.3
Data Product Retrieval - The NOAA-Unique and Tailored
Products generated by NDE shall be made available to
customers by placement in locations where data can be
extracted within a time not to exceed the time specified in
the Data Product Latency Table.
XF3
112
External Interface
Requirements
ID
Section
Requirement
Contract
SRS137
3.3.4.1
Archive Data Used for Functional Testing - Metadata and
ancillary data, as well as Intermediate , NOAA-Unique, and
Tailored Products used in documented Functional Tests,
will be sent to CLASS.
DA5
SRS138
3.3.4.2
Retrieve Data From CLASS - The System will have the
capability to retrieve data from CLASS.
DA9
MMC Interface Through ESPC - ESPC Operations shall
provide an interface between NDE and the NPOESS
Mission Management Center (MMC) such that 100% of the
NDE inquiries to the MMC and NDE replies to MMC reuests
are received by the MMC in a time not to exceed that
specified in the ICD, and that 100% of the notifications and
inquiries from the MMC to NDE are received by NDE in a
time not to exceed that specified by the ICD.
XF9
SRS140
3.3.5
113
External Interface
Requirements
ID
SRS141
SRS142
SRS235
Section
Requirement
Contract
3.3.6
Service Requests to IPO - An interface for NDE service
requets to the IPO shall be provided such that 100% of the
NDE service requests intended for the IPO are delivered to
IPO and 100% of the IPO responses to NDE service
requests are received by NDE.
XF10
3.3.7
Service Requests to IDPS - The System shall provide the
capability to enable the ESPC/NDE Operations Staff to
communicate with the IDPS Operations Staff.
XF11
3.3.8
ESPC Trouble Tickets - The System shall provide the
capability to interface with the ESPC Trouble Ticket
system.
SM16
114
NDE Context: Operational
Environment (NPOESS)
Applicant Registration &
Customer Support Dialogues
xDRs, IPs, NUPs,
Tailored Products, ADCS
Data, SARSAT Tlm
NPOESS
Status
NPOESS
MMC
ESPC
NDE Work
Requests,
Status
METOP
NAVOCEANO
External
Ancillary Data
Delivery
Consolidated
Reports
IDPS
Customer
Profiles
Customers
Status Reports
MMC
Messages
Ancillary
Data
ESPC
Operator
Dialogues
NDE
Subscription/Status
Requests
NDE
OPS
Subscription Requests/
Approvals
ARWG Approved NUPs
PALs
CLASS
Retrieved Data
xDRs, IPs, SARSAT Tlm, ADCS Data
Ordering & Tracking Messages
Recovery Datasets
Logs
IDPS Operator Dialogues
COOP
Repository
115
Sample Interface
Operational IDPS
xDRs
Intermediate Products (IPs)
SARSAT Telemetry
ADCS Data
IDPS
Data Delivery Messages
Delivery Consolidated Reports
IDPS Catalog/File Descriptors
NDE
OPS
Data Orders
IDPS Operator Dialogues
116
Summary of External
Interface Documents (1/2)
Interface Control Documents (ICDs):
•
•
•
•
•
•
•
Environmental Satellite Processing Center (ESPC)
NPOESS Mission Management Center (MMC)
Interface Data Processing Segment (IDPS)
External Suppliers of Ancillary Data (METOP, NAVOCEANO,…)
Program Area Lead (PAL) Handbook
Comprehensive Large Array-data Stewardship System (CLASS)
Continuity of Operations Plan (COOP) Repository
117
Summary of External
Interface Documents (2/2)
Service Level Agreements (SLAs):
•
•
•
•
•
•
National Weather Service (NWS)
National Ocean Service (NOS)
United States Mission Control Center (USMCC)
United States Global Processing Center (USGPC)
Any Customer Requiring “Denied” Data
Any Customer Requiring System Status Reports
Standard End User License Agreement (EULA)
• All Other Customers
Customers’ User Guide
• All Customers
118
Design Challenges
Challenge
Supporting simultaneous
Quasi-Operations as well as
System Test modes
Defining the interface with the
CIP
Reqt
SRS84
J-I1
Impact
Mitigation
Customer satisfaction, system
performance, operational quality
Staffing plan, design trades
Incomplete design
Continuance of Operations Plan
119
Agenda
8:00 a.m.
Welcome
8:15 a.m.
Introduction/Background
9:00 a.m.
Project Overview
10:45 a.m.
NDE Context and Hardware
11:15 a.m.
Algorithm Development
12:00 p.m.
Lunch
• External Interfaces
E. Wilson
1:00 p.m.
Data Handling System
• DHS Architecture
E. Wilson
2:30 p.m.
IT Security
• Common Services
P. MacHarrie
3:00 p.m.
Communications Study
• Subsystem Design
A.Al-Jazrawi
3:40 p.m.
Closing Remarks
4:00 p.m.
PDR Board Review of RFAs
120
DHS Architecture Requirements
ID
SRS93
SRS203
SRS215
Section
Requirement
Contract
3.8.3.2
The NDE Processing System Design will use COTS and
Open Source software where it is possible, practical, and
approved by the Government.
SE10
3.14.10
The Contractor will specify a suite of proven development
lifecycle tools to enhance NESDIS capabilities in
performing developmental and software maintenance
tasks. The documentation will demonstrate that the
selected tools are widely supported in the remote sensing
software industry and the most likely to be known by
future NESDIS support staff. Technologies in this
category are: CASE tools, modeling tools, 4th Generation
Languages, Testing tools, and Requirements Tracking
tools.
SE3
3.10.2
The contractor shall develop the data processing
elements of the future NDE system using the latest
proven technologies (programming languages, CASE
tools, object repositories, data base management
systems, etc.) that are appropriate for remote sensing
data processing.
SE13
121
Requirements Focus on the
NDE Perimeter
NDE Perimeter
UseCase3
*
UseCase2
*
*
*
UseCase1
*
*
User Scenarios
*
*
UseCase4
Test Cases
page 1
122
Defining What’s Inside NDE
(Functions, Data, Activities)
NDE Perimeter
read by
AlgorithmProductInput
reads
Product
Algorithm
AlgorithmStatus
SpatialCoverageArea
creates
isAlgorithmOutput
created by
ProductName
<Undefined>
QualityStandard <Undefined>
ProductType
<Undefined>
describes
Product Metadata
defines
defines
Metadata
MetadataType
<Undefined>
CoreMetadata
<Undefined>
AdditionalMetadata <Undefined>
ProductFile
Identifier_1 <pi>
Algorithm
describes
FileMetadata
is created by
creates
is defined by
AlgorithmExecutionOutput
instantiates
IDEF0
AlgorithmExecution
File
FileName
reads
EnqueueTime
<Undefined>
is AlgorithmExecutionInput
read by QualityData
CompletionTime <Undefined>
CreationTime
Status
<Undefined>
Archived
<Undefined>
<Undefined>
<Undefined>
<Undefined>
E-R
Activity
123
Overview of the Data
Handling Subsystems
1.0 Customer
Services
2.0 System
Monitoring
& Control
• Customer
Subscription
Web Service
• MMC
Message
Handling
•PAL
Subscription
Approval
Web Service
• Process &
Component
Monitoring &
Control
• Customer
Status
Reporting
Web Service
•Mode Switch
& Failover
Management
3.0 Product
Management
4.0 Ingest
5.0
Production
6.0 Distribution
7.0 Common
Services
• Algorithm
Definition Web
Service
• Receive &
Store Data
• Processing
Manager
• User Data
Transmission
• Enterprise
Service Bus
• Product
Definition Web
Service
• Receive
IDPS Delivery
Messages &
Consolidated
Reports
• Production
Scheduler
(Rule
Based)
•Archive to
CLASS
•Relational
Data Base
Management
System
• Data Cleanup
•Rule
Management
• System
Logs
• Recovery
Datasets
124
Functional Categories for
Architecture Operational
Components
•
•
•
•
•
•
•
•
•
•
•
•
•
Interoperability
Customer Service Framework
System Monitoring and Control
Product Processing (Ingest, Production, Distribution) Service Framework
Database Management
Business Process Specification
Security Policy Enforcement
Network Availability & Performance Monitoring
Administrative User Interface
OS/Network Support – Tool Server
Component Administration & Vendor Support
Documentation. Training, and Ongoing Education
Vendor Comprehension & Licensing Offer
125
Service Framework
Candidates
BEA:
Tuxedo, Weblogic, Aqualogic
IBM:
Websphere
Oracle:
Fusion
Note: Business Process Modeling capabilities are spread between IT
Tools (modeling) & Components (performance data accumulation)
126
DHS Architecture Challenges
Challenge
Integrating Middleware with
CASE tools
Related
Requirement
Impact
SRS215
Maintainability of design
Mitigation
Prototyping, early
testing, staffing
127
Agenda
8:00 a.m.
Welcome
8:15 a.m.
Introduction/Background
9:00 a.m.
Project Overview
10:45 a.m.
NDE Context and Hardware
11:15 a.m.
Algorithm Development
12:00 p.m.
Lunch
• External Interfaces
E. Wilson
1:00 p.m.
Data Handling System
• DHS Architecture
E. Wilson
2:30 p.m.
IT Security
• Common Services
P. MacHarrie
3:00 p.m.
Communications Study
• Subsystem Design
A.Al-Jazrawi
3:40 p.m.
Closing Remarks
4:00 p.m.
PDR Board Review of RFAs
128
Common Services Requirements
ID
SRS89
SRS215
SRS159
SRS87
Section
Requirement
Contract
3.14.1.3
Starting with the NPOESS-C1 mission, the NDE Operational
Environment shall not be interrupted for more than 2 hours
in any 24 hour period and no more than 4 hours in any 30
day period.
SE2
3.10.2
Use Proven Technologies - The contractor shall develop the
data processing elements of the future NDE system using
the latest proven technologies (programming languages,
CASE tools, object repositories, data base management
systems, etc.) that are appropriate for remote sensing data
processing.
SE2, SE13
3.6.2
Scalability - The Operations, System Test, and Development
Environments will be scalable--that is, additional capacity
(throughput, latency, performance) can be added to it as
needed without redesign of the system infrastructure. It
will be scalable from the initial system to support NPP up
through a system to support the simultaneous operations
of NPOESS-C1 and NPOESS-C2.
I1
3.2.5.2
Provide Automatic Failover - The System shall provide an
automatic failover capability that will re-create a fully
functioning configuration from a failed configuration with
no more than 1% of the tasks requiring manual
intervention.
DD5
129
DHS Architecture
Product/Customer/System Mgmt
DHS GUIs
Database
Event Service Bus
Distribution
Production
Ingest
Data Handling Subsystems
NDE
130
Initialization
Initialize:
•Algorithms
•Product-Generation
Rules
•Customers
•Subscriptions,
•System Mode (i.e.
Data Access)
Product/Customer/System Mgmt
DHS GUIs
Database
Event Service Bus
Distribution
Production
Ingest
Data Handling Subsystems
NDE
131
Data Driven
Input
Events
Output
Events
Product/Customer/System Mgmt
DHS GUIs
Database
Event Service Bus
Product
Distribution
and
Notification
Distribution
Production
Files
Arrive at
Landing
Zone
Ingest
Data Handling Subsystems
NDE
132
RDBMS Evaluation
• Database (Oracle, DB2)
– Scalability, availability, disaster recover and spatial data types
and functions narrows vendors to Oracle, DB2
– Highest ranked within industry standard transaction benchmarks
(about 1,600 transactions per second / per CPU)
– Both provide clustering approaches for high availability
– Both provide disaster recovery using database replication
• Decision
– In-house developed spatial benchmark testing the performance
and precision of spatial data types and functions
133
Spatial Benchmark
(1 week simulation)
Input
Events
Output
Events
Product/Customer/System Mgmt
DHS GUIs
Database
Event Service Bus
260,000 xDRs / Day
/ Satellite
173,000 NUPs & TPs
/ Day / Satellite
Product
Distribution
and
Notification
Distribution
Production
(NPOESS-Like)
MODIS,
OMI Data
MADIS Data
Ingest
Data Handling System (DHS)
NDE
Ingest * 3
Production * 5
433,000 / Day / Sat.
134
Benchmark: File Level
Spatial Qualification
• Limit algorithms execution by the spatial
area of the input file. (e.g. Coastal and
CONUS products)
• Distribute product to customer only when
the file’s geographic area intersects the
subscription’s geographic area of interest
135
Benchmark: Gazetteer
• “Names” a geographic location
• Sources: USGS and National Geospatial-Intelligence
Agency (NGIA)
• Purpose
– Serves as an alternate method to specify a
geographic filter on a product or subscription
– Provide labels for mapped images (i.e. label ports on
products for C&T customers)
136
Benchmark: Event
Gazetteer
• Names an Event
– Geographic and temporal location of an event
• Event Variable
– Present Weather
– Present Weather
– 24Hr Accum. Precip.
Value or Range
‘Fog’
‘Volcanic Ash’
0.175m - .300m
• Sources (EPA, MADIS)
• Purpose
– Provides a means of producing or distributing a
product in response to an event that has not yet
happened, but might in the future.
– Provide additional optional data layers overlapping
the geographic a temporal area of the product
137
Benchmark: Pixel Level
Spatial Qualification
• Store geo-location data in the RDBMS
– Limited Addt’l data (i.e. Cloud Mask, Land/Sea Mask,
Sensor Zenith)
• Purpose
– Method of determining whether to produce or
distribute based on Cloud Free in an entire
geographic area
– Determining whether to execute blending algorithms
– Simplifies the development of new tailored products
(i.e. subsetting) by providing filenames and pixel
locations to tailoring tools
138
NDE Data Model
• Product Development View
– Supports development of data to define products and “plug”
algorithm into NDE
• Operations View
– Supports Ingest, Storage, Archive, Production, Distribution,
System Metrics
• Card Catalog View
– Supports ingest, quality control, order specification, archive.
• Science Data View
– Supports product tailoring, algorithms, SOA enabler
– Alternatives: Relational View, J-METOC, CDM
– Selecting: Relational
139
Design Challenges
Challenge
COOP requirements for
NPOESS need to be
determined
Related
Requirement
Impact
Mitigation
Part of ESPC overall
COOP requirements
Needed to identify the
details of the database
replication
implementation
G. Goodrum resolving
this issue
140
Agenda
8:00 a.m.
Welcome
8:15 a.m.
Introduction/Background
9:00 a.m.
Project Overview
10:45 a.m.
NDE Context and Hardware
11:15 a.m.
Algorithm Development
12:00 p.m.
Lunch
• External Interfaces
E. Wilson
1:00 p.m.
Data Handling System
• DHS Architecture
E. Wilson
2:30 p.m.
IT Security
• Common Services
P. MacHarrie
3:00 p.m.
Communications Study
• Subsystem Design
A.Al-Jazrawi
3:40 p.m.
Closing Remarks
4:00 p.m.
PDR Board Review of RFAs
141
Related Requirements
ID
Section
Requirement
Contract
SRS215
3.10.2
Use Proven Technologies - The contractor shall develop the
data processing elements of the future NDE system using
the latest proven technologies (programming languages,
CASE tools, object repositories, data base management
systems, etc.) that are appropriate for remote sensing data
processing.
SE2, SE13
SRS169
3.8.3.4
Modularity - The NDE System Elements shall be designed so
that Scientific Algorithms are invoked as objects.
SE5
SRS168
3.8.3.3
Reusability – The NDE System Elements shall be designed
to be reused in other Satellite Data Processing applications.
SE2
3.10.2.1
Use a 4GL - The Contractor shall develop the data
processing elements of the future NDE system using tools
that will support the ability to alter executable components
without altering source code.
SE14
SRS217
142
Service Oriented Architecture
(SOA) for NDE
• NDE drivers for considering a Service-Oriented
Architecture (SOA)
– High availability system, need to be able to
update components without bringing system
down
– New products and algorithms need to be
easily added to the system
– Each launch requires scaling up of the system
capabilities
– Future NDE functionality will be easily added
as services
143
Service Oriented
Architecture (SOA)
• ”Black-box” design - In an SOA environment, resources
on a network are made available as independent
services with defined interfaces
• In a SOA, processes and services are flexible and can
be easily added and rearranged
• The SOA architecture style is geared to provide
enterprise business solutions that can change on
demand
• The SOA software architecture is based on the key
concepts of an application front-end, service, service
repository, and service bus.
• Business functionality is provided by services used by
application front-ends and other services or even servers
144
SOA Specification
• OASIS (Organization for the Advancement of
Structured Information Standards) is a not-forprofit, international consortium that drives the
development, convergence, and adoption of ebusiness standards.
• The OASIS Reference Model for Service
Oriented Architecture V 1.0 was approved as an
OASIS Standard in 2006.
• Specification available at: http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=
soa-rm
145
Elements of SOA
Elements of SOA, by Dirk
Krafzig, Karl Banke, and
Dirk Slama. Enterprise
SOA. Prentice Hall, 2005
146
Developing Services
• The following are architectural principles for the design
of services
– Service Encapsulation – information hiding and breaking a
program into distinct features
– Service Loose coupling - Services maintain a relationship that
minimizes dependencies
– Service contract - Services adhere to a communications
agreement
– Service abstraction - Services hide logic from the outside world
– Service reusability - Logic is divided into services with the
intention of promoting reuse
– Service statelessness – Services minimize retaining
information specific to an activity
– Scalability – ability to handle growing amounts of work or be
easily enlarged
147
Enterprise Service Bus
Custom/Existing
Applications
Internet
HTTP
Service
Orchestration
Presentation
and Portals
Enterprise Service Bus (Routing and
Transformation Services)
Data
Services
Web
Services
DB
148
NDE Data Handling System
(DHS) Design Status
• Major System Subsystems/Services have been
identified
• Basic use case diagrams have been modeled
and used to define much of the problem domain
• Data Flow Diagrams have been created
• Entity Relationship Diagrams (ERDs) developed
149
Customer View of NDE
Customer works with PAL
to define desired products
NDE starts algorithms
when requested inputs
for products are available
Algorithms to produce
these products
are defined in NDE
Products are
made available
for the user
Users select the products
they want to receive via a
web interface
Products are removed from
the NDE based on
predefined cleanup rules
150
Customer Request View
• Data products are defined by a Product Area Lead (PAL)
– Defined tailored and NOAA unique product parameters
– Format
– Input data sources
• Users log in and subscribe to Data Products (ad hoc or
standing)
• User Request View provides access to a list of products
available
– Optional parameters include
•
•
•
•
•
Spatial coverage area
Data quality thresholds
Compression options
Delivery options – FTP push or pull, etc.
Notification options – web-based GUI planned, other possible
options
151
NDE Subsystems
Product
Management
Customer
Services
Distribution
Ingest
System
Monitoring
& Control
Production
Common
Services
152
Customer Services
Subsystem
• User Registration Web Service
– User accesses registration form via web browser, enters identification
information, and submits request
– The user registration request is stored in NDE DB waiting for operator
approval
• User Subscription Web Service
– User logs in and accesses subscription web page, selects data for
subscription or ad-hoc request and submits request
– Request is automatically approved unless it exceeds configurable NDE
order limits
– User can view approved subscription/ad-hoc requests
• User Status Reporting Web Service
– The user logs and can receive information on all orders requested by
the user in the system for the past 72 hours
– Authorized users can receive system status information
• Customer help requests/ESPC interfaces/roles to be
defined in working groups planned in January
153
Customer Services Subsystem
Activity Workflow Diagram
154
Customer Services Subsystem
Activity Workflow Diagram
155
Customer Services
Subsystem
• Registration Approval Web Service
– The operator logs into the operator account using a web browser
– The operator receives user registration information
– Based on input from NDE Manager the operator grants or denies
the registration request
• Subscription Request Approval Web Service
– The operator logs into the operator account using a web browser
– The operator receives user order information
– Based on information from the Product Area Lead (PAL) the
operator grants, edits, or denies the Subscription request
• Archive to CLASS Web Service
– Archive algorithms
– Archive data – based on guidance from the Archive
Requirements Working Group (ARWG)
156
Customer Services Subsystem
Workflow Activity Diagram
157
Customer Services Subsystem
Workflow Activity Diagram
158
Product Management
Subsystem
• Product Definition Web Service
– Web-based GUI allows the different data types handled by NDE
to be defined or modified
– XML ingest of parameters currently considered in design
– Alternatively, an installation script can be used to enter initial set
of data products
• Algorithm Definition Web Service
– Web-based GUI allows processing parameters for algorithms to
be entered into the NDE database
– Parameters include
• Production Rules to be used in selecting input data
• Expected outputs
• Expected size of inputs and outputs
• Expected processing time
– XML skeleton generation for Algorithm Definition parameters
currently considered in design
– XML ingest of Algorithm Definition currently considered in design
159
Product Management Subsystem
Day N
GranuleA1
GranuleA
Day N
8h
10h
12h
14h
GranuleB2
GranuleB3
GranuleB
GranuleB1
AlgorithmA
AlgorithmA
AlgorithmA
AlgorithmA
GranuleC
GranuleC
GranuleC
GranuleC
Example Production Rules
160
Ingest Subsystem
• Receive and Store Data Service ingests data from IDPS
and other sources
– A data delivery message is received from IDPS or other files
received on SAN will have controls written to detect file
appearance and initiate the Receive Data Service for processing
– Verifies the data is on the NDE SAN
– Performs and enables validation functions – checksum, quality
flag checks as input to problem notifications, file size check
– Requests retransmit if file fails checksum/size validations
– Inserts granule metadata into NDE database
– Inserts spatial metadata into NDE Database
• Receive IDPS Consolidated/Data Delivery Report
–
–
–
–
Consolidated Data Delivery Report is sent to NDE SAN
ESB configured to generate an event when report is received
Report is compared with granules received by NDE
Missing files are requested from IDPS
161
Ingest Subsystem Activity
Diagram
162
Ingest Subsystem Activity
Diagram
163
Production Subsystem
• Production Scheduler Service - selects algorithms to
execute when data is available
– Executes Production Rules
– Retrieve needed data from CLASS LTA
– Schedule ready algorithms by sending a message to the
Production Server subsystem
• Processing Manager Service – manages NDE
algorithms’ execution when their inputs are ready
–
–
–
–
Runs Tailoring
Reports algorithm execution statistics
Monitors algorithm execution
An algorithm writes data to NDE Production Processing Landing
Zone area to be ingested into the NDE
164
Production Subsystem
Activity Diagram
165
Distribution Subsystem
• Archive to CLASS Service sends data to the CLASS
• Initiated when a message is received from another Subsystem
– Sends data indicated in message to CLASS
– Receives status back from CLASS
• User Data Transmission Service forwards data products to users
–
–
–
–
–
Calculates checksum
Compress (gzip, lossy, lossless, etc) data if required
Pushes data to user if required
Stages data to pull location if required
Implements Data Denial
• Data Cleanup Service removes old data from the NDE SAN
– Reads NDE DB for products that exceed the maximum cleanup interval
or exceed maximum user defined cleanup interval
– Verifies data has been archived to CLASS
– Verifies data has been sent to all requesting users
– Deletes data from SAN
– Updates NDE Database to remove metadata/spatial metadata
166
Distribution Subsystem
Activity Diagram
167
Distribution Subsystem
Activity Diagram
168
Distribution Subsystem
Activity Diagram
• Included in Cleanup Rules
– Exceeds maximum cleanup interval for NDE
– Exceeds maximum user window
– NOAA Unique Granules are removed when
• Archived to CLASS
• Distributed to Users
– Non-NOAA Unique Granules are removed
when
• Distributed to Users
– SAN Full Check will cause removal earlier
169
NDE DHS Challenges
Challenge
Impact
Mitigation
Validating system actors
and their roles
User acceptance
Working groups with
PALs
Defining web services for
use by the PALs, Users,
NDE Engineer, and other
roles we identify
Ineffective and
inefficient web service
displays interfacing
with DHS
Prototyping
Defining interfaces
Performance
ICD Working Groups
Transition of legacy
algorithms
Cost, schedule,
performance
Standards
Defining user notification
methods
User needs unmet
Working with PALs
Customer feedback
170
Agenda
8:00 a.m.
Welcome
8:15 a.m.
Introduction/Background
9:00 a.m.
Project Overview
10:45 a.m.
NDE Context and Hardware
11:15 a.m.
Algorithm Development
12:00 p.m.
Lunch
1:00 p.m.
Data Handling System
2:30 p.m.
IT Security
3:00 p.m.
Communications Study
3:40 p.m.
Closing Remarks
4:00 p.m.
PDR Board Review of RFAs
• IT Security
B. Callicott
171
NDE Security Requirements
ID
Section
SRS160
3.7.1
Requirement
The Contractor shall follow ESPC (DoC/NOAA/NESDIS)
procedures and policies for securing ESPC systems.
Contract
SA5
172
Security Considerations
• Security is incorporated and addressed from the initial planning and
design phase
• Multiple, overlapping protection approaches are used ensuring the
failure or circumvention of any individual protection approach will not
leave the system unprotected
• NIST 800-27A “Engineering Principles for Information Technology
Security (A Baseline for Achieving Security), Revision A” has been
followed
• Establishment of a Plan of Actions and Milestones (POA&M) that
lays out the resources and milestones to achieve full compliance
with NIST 800-53 controls
• Patch Management procedure in development and will be
implemented as one of the POA&Ms
• ESPC CCB process has been modified to require ISSO approval of
all configuration changes to ensure the system remains secure and
documentation is up to date
173
Stage 1 Network Diagram
Outside of ESPC
ESPC Secure Network
File: ESPC Security Zones v15.vsd
NSOF
Enterprise
Connections Must Initiate From Higher Zone to Lower Zone (or In-Zone)
1Gbps
VPN Server
Cisco 3060 Pair
System # 5001
VPN Security
Zone
2nd Vendor
Firewall Pair
100Mbps
Switch
100Mbps
ESPC
Firewall
Pair
Internal-Initiated Traffic to All Zones
Except Admin, Following Higher to
Lower Rule
IDS
Sensor
1Gbps
Cisco 4507
DMZ
Public
Security
Zone
IDS
Sensor
1Gbps
Cisco 4507
Cisco 3745
Juniper FW
DMZ 2
Partner
Security
Zone
IDS
Sensor
Security
Level 35
IPS
Pair
External-Initiated Traffic to Public
and NSOF Staging Zones Only
1Gbps
1Gbps
Cisco 6506
NSOF
Staging &
Migration
Zone
NSOF
Temp
Fiber
FB-4
Security Level
30
1Gbps
Security
Level 25
IDS
Sensor
Cisco 6506
DMZ 3
Developm
ent, PreOps, Test
&
Integration
Security
Zone
Security
Level 55
1Gbps
IDS
Sensor
100Mbps
IDS
Sensor
Cisco 6506
Cisco 4507
Inside
Production
Ingest
Security
Zone
Administ
ration
Security
&
Admin
Security
Zone
Security
Level 99
Security
Level 100
Fiber-Channel SAN
174
Stage 2 Network Diagram
Outside of ESPC
ESPC Secure Network
File: ESPC Security Zones v15.vsd
NSOF
Enterprise
IDPS
Connections Must Initiate From Higher Zone to Lower Zone (or In-Zone)
1Gbps
VPN Server
Cisco 3060 Pair
System # 5001
VPN Security
Zone
100Mbps
Switch
100Mbps
ESPC
Firewall
Pair
Internal-Initiated Traffic to All Zones
Except Admin, Following Higher to
Lower Rule
IDS
Sensor
1Gbps
Cisco 4507
DMZ
Public
Security
Zone
IDS
Sensor
1Gbps
Cisco 4507
Cisco 3745
Juniper FW
DMZ 2
Partner
Security
Zone
IDS
Sensor
Security
Level 35
1Gbps
Cisco 6506
VPN Server Cisco
3015 for Dev Only
IPS
Pair
NDE Development
Zone
External-Initiated Traffic to Public
and NSOF Staging Zones Only
1Gbps
1Gbps
Cisco 6506
NSOF
Staging &
Migration
Zone
NSOF
Temp
Fiber
FB-4
Security Level
30
1Gbps
2nd Vendor
Firewall Pair
Security
Level 25
IDS
Sensor
Cisco 6506
DMZ 3
Developm
ent, PreOps, Test
&
Integration
Security
Zone
Security
Level 55
1Gbps
IDS
Sensor
100Mbps
IDS
Sensor
Cisco 6506
Cisco 4507
Inside
Production
Ingest
Security
Zone
Administ
ration
Security
&
Admin
Security
Zone
Security
Level 99
Security
Level 100
Fiber-Channel SAN
175
VPN Zone
• Associates roles with individuals, allowing individuals
to only access certain systems in certain zones
• One subnet of public IPs for VPN on Outside Subnet
• Juniper Network Admission Control Appliance (NAC)
for verifying compliance prior to network access,
specified for future deployment
• Compliant with US Department of Commerce IT
Security Program Policy and Minimum
Implementation Standards Revised June 30, 2005
• Compliant with U.S. Department of Commerce
Unclassified System Remote Access Security Policy
and Minimum Implementation Standards
176
Stage 2 – Development Zone
• ESPC security controls and configuration
management processes will apply, one C&A for
the ESPC/NDE system
• Removes developers from the National Critical
production environment as a risk reduction approach
• Improves collaboration with non-OSDPD developers
• Systems dedicated to development – will not be
used operationally
• Data acquisition and distribution through drop boxes
in Public Zone
• Development programmer access through VPN
Server for Development Only
177
NDE Security Challenges
Related
Requirement
Impact
Mitigation
IDPS requires use of
StorNext to write to ESPC
SAN vs ESPC security
zones
Imposed on NDE by
IDPS and ESPC
Multiple NDE hosts also
need to “see” the same
file system on the ESPC
SAN that IDPS uses;
therefore NDE is also
required to use StorNext
as its metadata server
ESPC (Brian Callicott) is
pursuing technical
solution to allow
StorNext FS to run
securely in the stage 3
system for file sharing
between zones
Moving from stage 2 to
stage 3 requires
implementing some legacy
design into the NDE
architecture
NDE architecture
will serve as
technical refresh for
non-legacy ESPC
systems
Legacy design ESPC
systems will require
modification to move into
stage 3
POA&Ms will be created
and resources assigned
to address these legacy
subsystems
Unless compatibility
issues are resolved,
ESPC may suffer reduced
throughput
Initially, Cisco will
attempt to resolve
incompatibilities;
firmware upgrades must
be well-coordinated; long
term a single FC-switch
vendor should be
selected
Challenge
Brocade and Cisco FiberChannel Switch
incompatibilities
ESPC must be able
to properly interface
with external
organizations over
fiber-channel for
data delivery
178
Agenda
8:00 a.m.
Welcome
8:15 a.m.
Introduction/Background
9:00 a.m.
Project Overview
10:45 a.m.
NDE Context and Hardware
11:15 a.m.
Algorithm Development
12:00 p.m.
Lunch
1:00 p.m.
Data Handling System
2:30 p.m.
IT Security
3:00 p.m.
Communications Study
3:40 p.m.
Closing Remarks
4:00 p.m.
PDR Board Review of RFAs
• Infrastructure Design
B. Hickman
• NOAANet Efforts
B. Hickman
• Distributed Volumes
B. Hickman
179
NDE Telecommunications
Task Introduction
ID
Section
SRS216
3.2.3.4.1
Short Title
Trade Study Alternatives
Contract
CD5
• NDE telecommunications infrastructure design
• Updated status of NOAA migration toward a One-NOAA
NOAANet
• NDE Distribution volumes to users 2007-2020 and Section
Summary
180
Risk Reduction
Telecommunications Options
• Flexible Extensible Switch Based NDE Design
Options scale multiple selectable layers of
redundancy for COOP
– Each of the 4 Options offer progressively increasing:
• component redundancy (power supply, board,
chassis, switch, and WAN) to seamlessly meet
operational failover contingencies
• scaled firewall protection and security context
organization, aggregation, and management
• Maintains optimum compatibility with ESPC
Operations:
– ESPC Consolidation of IT Architecture
– IPV6 Migrations
181
182
183
184
185
Agenda
8:00 a.m.
Welcome
8:15 a.m.
Introduction/Background
9:00 a.m.
Project Overview
10:45 a.m.
NDE Context and Hardware
11:15 a.m.
Algorithm Development
12:00 p.m.
Lunch
1:00 p.m.
Data Handling System
• Infrastructure Design
B. Hickman
2:30 p.m.
IT Security
• NOAANet Efforts
B. Hickman
3:00 p.m.
Communications Study
• Distributed User Volumes
B. Hickman
3:40 p.m.
Closing Remarks
4:00 p.m.
PDR Board Review of RFAs
186
Data Distribution Design
Challenges
• Stakeholder Interviews, Model creation, & PAL
product profiling
• Current ESPC not able to handle NDE order of
magnitude increased loads
• DoC and NOAA security requirements limit
design options, particularly the SAN
• Consolidated approach needed to develop
infrastructure to handle NDE distribution to users
187
Data Distribution - WAN
• NOAA has 12 legacy hub-and-spoke networks
• Accelerate migration to a unified NOAANet to
achieve increased capacity, MPLS any-to-any
topology, cost-efficiency
• Washington DC MAN recently upgraded by
NWS Qwest solution
– DWDM high speed ring with access to distributed
sites via MPLS Cloud
• Leverage Internet2 possibilities
• NWS, NEXRAD, & CLASS provide precedents
for NDE design consideration
188
Overview of August 2006
Peer Review Slides
• Slides depicting Internet2 opportunities
– Lambda Rail MBone could support Multicast and other Real time
protocol studies for NDE
Abilene 10 Gbps Network
LambdaRail Network (LRN)
Source: http://abilene.internet2.edu/maps-lists/





35 Connectors (connect directly to the Abilene network)
26 International Peers
6 Federal Peers (DREN, Esnet, NISN, NREN, vBNS, USGS)
244 Participants
147 Sponsored Participants
189
Legacy Washington DC
MAN
Abilene/
Internet2
Internet
HCHB
OC12
Qwest
Gaithersburg
NASA GSFC
Greenbelt
Univ. of MD
College Park
(NOAA
MAXGate)
U N I V E R S I TY
Circuits likely to need
capacity upgrade for
NDE volumes
TLS
Domain
287
Verizon
All 10
Mbps
NOAA HQ
SSMC
NSOF
Suitland
Germantown
WWB
Camp Springs
FOB
Suitland
TLS Domain 26
Verizon
10 Mbps
100 Mbps
1000 Mbps
1000 Mbps fiber
(leased from Fibergate)
Landover
Colesville Road
Silver Spring
Wayne Avenue
Silver Spring
Based on information in Statement of Need
DG1330-05-RP-1038, Amendment 0004, Section C
190
NWS 2006 Upgrade to
Washington DC MAN
NSOF
NWS Logical Network Design in 2006
191
NWS 2009 Projected Growth
NSOF
NWS Logical Network Design in 2009
192
Agenda
8:00 a.m.
Welcome
8:15 a.m.
Introduction/Background
9:00 a.m.
Project Overview
10:45 a.m.
NDE Context and Hardware
11:15 a.m.
Algorithm Development
12:00 p.m.
Lunch
1:00 p.m.
Data Handling System
2:30 p.m.
IT Security
Infrastructure Design
B. Hickman
3:00 p.m.
Communications Study
• NOAANet Efforts
B. Hickman
3:40 p.m.
Closing Remarks
• Distributed Volumes
B. Hickman
4:00 p.m.
PDR Board Review of RFAs
193
August 2006 Peer Review
Update
• Large number of slides showing Legacy and
Nextgen satellite comparison charts
• Projected volumes did not include:






Latency
Overhead
Surge
Firewall delay
Encryption delay
Compression delay
• Distributed Delivery slides to follow do reflect
(all but firewall delay) scaling for throughput
• Nunn-McCurdy changes revising estimate
basis and model refinements
194
OverArching NDE Models Basis
• xDR (RDR, SDR, EDR, & IP) sizing model
establishes IDPS delivery to NOAA NDE SAN
• xDR model outputs drive NOAA Product
model inputs
• NOAA Product model tracks legacy/next
generation traffic growth and required
distribution to identified End-users
• Orders of magnitude larger than legacy
systems
• Large number of significant distributed users
195
Predicted Domestic Traffic
NDE
Customer/Stakeholder
Customer
Destination Location
(All distribution
originates from NSOF)
20072009
Traffic
(Mbps)
2013
Traffic
(Mbps)
2015
Traffic
(Mbps)
2018
Traffic
(Mbps)
2020
Traffic
(Mbps)
NOAA/NOC
Silver Spring, MD
625
717
1,373
2,875
4,083
NWS/TOC
NWS/NCEP
NWS/AWIPS
ORA (NCWCG)
ESPC
([email protected])
Silver Spring, MD
Silver Spring, MD
Silver Spring, MD
College Park, MD
466
563
369
37
534
645
423
43
1,023
1,236
810
81
2,142
2,588
1,696
171
3,042
3,675
2,409
242
College Park, MD
375
430
824
1,725
2,450
365
72
287
418
137
549
801
288
1,150
1,677
408
1,633
2,382
25
29
55
115
163
375
135
68
25
68
25
3,520
430
155
78
29
78
29
4,394
824
298
149
55
149
55
8,419
1,725
623
311
115
311
115
17,627
2,450
885
442
163
442
163
25,032
ESPC (USMCC <SARSAT
& A-DCS>)
NDE CIP
CLASS
NMFS
NOS
NOAR
NMAO
Dept. of Agriculture
FAA
Dept. of State
TOTALS
NSOF Suitland, MD
TBD
NSOF Suitland, MD
Silver Spring, MD
Silver Spring, MD
Silver Spring, MD
Silver Spring, MD
Washington, DC
Washington, DC
Washington, DC
NSOF Suitland, MD
196
197
198
199
Trade Outcomes
• Commercial satellites are band-limited
• MPLS savings realized by distributed, low bandwidth
networks (T-1 and below OC3) in range of 25%-40%
– SONET still found to be the most cost effective for distributed
networks of OC3 rates and above
 Multicast or alternative ‘One-Many’ technologies must be
established at customer edges and in the commercial
clouds to reduce NDE redundant loads
 Dense Wave Division Multiplexing (DWDM) can run very
large (~40 Gbps) traffic volumes simultaneously over the
same (1Gbps) fiber land lines
200
Bandwidth Reduction
Recommendations
Technologies
Strategies
IP multicast
Lossless compression
Lossy compression
IBM General Parallel File
System (GPFS)
 Real-time protocols
 Threaded & other highly
parallel processing
methods
• Reduced resolution
requests
• Reduced aerial coverage
requests
• Reduced frequency of
requests
• Updating (transmitting)
only the ‘new data’ for
composites
• Increasing product
requests over data
requests

•
•
•
201
Summary
• NDE Telecommunications Design for NSOF
flexible and extensible to scale appropriately and
meet all throughput requirements
• Current NAC feedback:
– NDE & NWS can add capacity to new Qwest DWDM ring
– NDE to apply for HPCC prototyping of Internet2 (Abilene &
Lambda Rail)
• Real time protocols, one-to-many (Multicast) solutions, and enabling
technologies prior to C1 launch
• Work with NCEP (model assimilation), vendors (e.g., CISCO, IBM,
Oracle, etc.), & COTS providers (e.g., ESRI, ITTVIS, SSEC,
Mathworks, etc.)
– Specific NAC solution recommendations to NDE regarding
connectivity to distributed National & International end-users
expected by March 2, 2007 (NLT June 2007)
202
NDE Telecommunications
Design Challenge Mitigation
Challenge
Related
Requirement
Impact
Mitigation
To define NOAA Enterprise
solution
3.2.3.4.1 - Trade
Study Alternatives
Higher cost, lower
performance, schedule
risk
Outreach - OSD, ITAT, &
NAC
NAC to recommend
solution by 3/2/07
High NDE Data/Product
Volumes & Large
Distributed customer base
3.2.3.4.1 - Trade
Study Alternatives
Unable to meet customer
product requirements
HPCC prototype study
IP multicast
Real-time protocols
Threaded & other highly
parallel processing
methods
Location of CIP
3.2.3.4.1 - Trade
Study Alternatives
Single point of failure
AFWA, CDA-W
alternatives under
consideration – TBD
before C1 Launch
IPV6 Migration
3.2.3.4.1 - Trade
Study Alternatives
Inadequate performance
HPCC protocol & one-tomany prototype studies
203
Agenda
8:00 a.m.
Welcome
8:15 a.m.
Introduction/Background
9:00 a.m.
Project Overview
10:45 a.m.
NDE Context and Hardware
11:15 a.m.
Algorithm Development
12:00 p.m.
Lunch
1:00 p.m.
Data Handling System
2:30 p.m.
IT Security
3:00 p.m.
Communications Study
• What’s Next
G. Sloan
3:40 p.m.
Closing Remarks
• Technical Challenges
G. Goodrum
4:00 p.m.
PDR Board Review of RFAs
• Closing Remarks
J. Silva
204
The Road to CDR
•
•
•
We have a resource-loaded schedule and an EAC
Maintain current staffing through CDR
NPP Build Cycle: Development Environment (PDR)
–
–
–
–
–
•
•
NPP Build Cycle: System Test Environment (post PDR)
Document updates and baselining
–
–
–
–
–
–
–
•
IT Development Environment
Science Algorithm Development & Integration Environment
Configuration Management Control Processes
Tools Analysis and Selection
Product Technical Baseline
CM Plan
Concept of Operations
QA Plan
Project Plan
System Requirements Specification
System/Subsystem Design Specification for NPP
FEA Mapping
Prototyping
–
–
–
Subscription
Ingest
Production
205
Agenda
8:00 a.m.
Welcome
8:15 a.m.
Introduction/Background
9:00 a.m.
Project Overview
10:45 a.m.
NDE Context and Hardware
11:15 a.m.
Algorithm Development
12:00 p.m.
Lunch
1:00 p.m.
Data Handling System
2:30 p.m.
IT Security
3:00 p.m.
Communications Study
• What’s Next
G. Sloan
3:40 p.m.
Closing Remarks
• Technical Challenges
G. Goodrum
4:00 p.m.
PDR Board Review of RFAs
• Closing Remarks
J. Silva
206
Technical Management
Challenges
Strategies
Volume, widely distributed customers,
low latency, diversity and inadequacy
of current networks
Develop ‘enterprise’ solutions in collaboration
with AWIPS and NAC
- Different communities (IT, Users,
Science Developers)
- Design (algorithms as objects
supported by IT elements)
- ‘Requirements Based Testing’ for IT
- PALs to work with science users to develop
acceptance criteria and test specs
System Design
Tendency to prototype and implement
too early in life cycle
Quality Management: Monthly government
review of design work products
Security Policy
Changing policy over the project life
cycle
Work with ESPC ISSO, IT Security Team, and
ESPC management
- SAN switch interoperability
- Customer Readiness
- Work with NPOESS External Interface
Working Group
- Establish “Systems Integration Manager” to
coordinate transition teams by product line
Networks
Testing
External
Interface
207
Agenda
8:00 a.m.
Welcome
8:15 a.m.
Introduction/Background
9:00 a.m.
Project Overview
10:45 a.m.
NDE Context and Hardware
11:15 a.m.
Algorithm Development
12:00 p.m.
Lunch
1:00 p.m.
Data Handling System
2:30 p.m.
IT Security
3:00 p.m.
Communications Study
• What’s Next
G. Sloan
3:40 p.m.
Closing Remarks
• Technical Challenges
G. Goodrum
4:00 p.m.
PDR Board Review of RFAs
• Closing Remarks
J. Silva
208
Program Management
Challenges
Strategies
- Continuity of current operations
- Exploitation of new products
Establish “Systems Integration Manager” to
coordinate transition teams by product line
NESDIS, Line Offices, Other Centrals,
Standards Bodies, Goal Teams,
Budget Examiners
Monthly Team Meetings with NESDIS, NPOESS
& Centrals Working Groups, Product Workshops
for Goal Teams & Line Offices, actively seek CIO
& ITAT guidance, dedicate resources to budget
exercises
- IT developers to IT operators and
maintainers
- Algorithm developers to algorithm
maintainers
Develop new estimating and scheduling
procedures with STAR & OSDPD
- FY08 deficit, FY09 threatened
- Flat-lined thereafter
- Prioritize FY08/FY09 allocations & redirect
resources accordingly
- Continue to seek plus-ups for product
development
Schedule
NPP/NPOESS program milestones
are NDE constraints
Plan for readiness ~ 6 months prior to
NPP/NPOESS milestones
Resources
- HR: Contractors dedicated to NDE
- Infrastructure: Potential
underutilization (e.g. NPP/NPOESS
delays)
- HR fold contractors into operational support
- Infrastructure (scalable, extensible architecture)
209
Transition to
Operations
Stakeholder
Comm.
Responsibility
Transfer
Budget
Review Calendar
2006 Date
Nov 21
Dec 6
Dec 15
Deliverable
Tasked
Requests for Review Board
Action (RFA)
Action
NDE
Responses to Design Team
Board
Chairperson
Final Report Design Board
Chairperson
210
Happy Thanksgiving!
211
Agenda
8:00 a.m.
Welcome
8:15 a.m.
Introduction/Background
9:00 a.m.
Project Overview
10:45 a.m.
NDE Context and Hardware
11:15 a.m.
Algorithm Development
12:00 p.m.
Lunch
1:00 p.m.
Data Handling System
2:30 p.m.
IT Security
3:00 p.m.
Communications Study
3:40 p.m.
Closing Remarks
4:00 p.m.
PDR Board Review of RFAs
• RFA Review
V. Griffin
212
Descargar

Slide 1