Billy G. Olsen, PEHydrologist In Charge

NWS – ABRFC – Tulsa, OK

NWS RFCSERVICE BACKUP

DISCUSSION

HIC CONFERENCE

31 July 2008

POINT OF DISCUSSION

Current circumstances in AWIPS-II & CHPS planning activities provide a refreshing opportunity to address NWS RFC Service Backup

Potential for RFC service backup to finally go mainstream with national support

How do we take advantageof this opportunity?

CURRENT RFC SERVICE BACKUP STATUS

Various unique local/regional hardware and data ingest/dissemination configurations

One commonality is RFC self-backup

Systems are not supported nationally

RFC BACKUP OPERATIONS NATIONAL PLANNING TEAM

Post-Katrina

Chartered May 2006 (Feb 07, Mar 07, Jan 08)

Currently on hold based on AWIPS-II uncertainties

NATIONAL PLANNING TEAMTEAM CHARTER FOR RFC BACKUP OPERATIONSVision: A robust operational scheme which supports operational backup of River Forecast Centers (RFC)

in time scales of hours to weeks.

Mission: Review current national and regional policies and procedures for RFC backup operations. Define necessary operational concepts for RFC backup. Identify operational and system requirements to implement the operational concepts. Develop the OSIP Stage 2 Concept of Operations (ConOps) and Operational Requirements Document (ORD).

Scope of Authority/Limitations: Team will review NWSI 10-2201, Backup Operations, and appropriate Regional Supplements. Team will review the Hurricane Katrina Service Assessment, especially the findings and recommendations related to RFC Backup, as well as the report on LMRFC backup operations compiled by a sub-team. Team should consider lessons learned and past practices from previous RFC backup operations, as well as various operational concepts, including Service Backup, Computational Backup, Local Backup, and others as appropriate, in developing an RFC Backup ConOps Team will consult with internal and external partners and customers, as needed Organizational allegiances among the team members must not be allowed to influence either the evaluation or the recommendations The team will make decisions by consensus The team will solicit/incorporate minority opinions if decisions are not reached by consensus No travel expenses will be authorized Team membership will be comprised of representation from OHD, OCWWS/HSD, NWS Regions, and OST.

Termination Date: The team will complete its work within 6 months of its formation.

Success Criteria/Deliverables: Deliver a Concept of Operations (ConOps) and Operational Requirements Document (ORD) which will constitute the OSIP Stage 2 documentation

Commencement & Termination Date:• The team will be formed and commence activities by March 9, 2007 and deliver its final report and briefing by September 31, 2007Team Membership – Representatives From:SR – Eric Jones, Senior Forecaster, LMRFC, Team LeaderCR – John Halquist, DOH, NCRFCWR – Harold Opitz, HIC, NWRFCAR – Dave Streubel, Senior Hydrologist, APRFCER – Joe Heim, Senior Forecaster, OHRFCOCWWS – Randy Rieman, Senior Support HydrologistOHD – Jon Roe, Chief, OHD Software Engineering Branch, or designeeOST – TBD

OSIP 07-056 River Forecast Center (RFC) Backup Initiative

IWT Lead:Randy Reiman OCWWS/HSD

Current IWT Members:

OHD, John Halquist (CR), Harold Opitz (WR), Robin Radlein (AR), Joe Heim (ER), Jeff Zimmerman (OCWWS/HSD), Leroy Spayd (OCWWS), Albert Mongeon (OOS/MLAD), Brian Doerk (OCIO), Jim Lane or designee (OS&T)

Latest Review Team Meeting Notes:

Conditions: (1) Clarify SON to be more direct about goals, and to include linkages to related projects: AWIPS Evolution - #04-005, RFC Archive Server Tech Refresh Initiative - #07-054, and RFC AWIPS Configuration #07-059 (2) Revisions to Project Plan to include additional team members, clarify objectives, address AWIPS related risk factors, linked projects, and other revisions.

Recommendation: Conditional ApprovalStrategic Priority:Moderate; Operational: High

Latest Gate Meeting Notes:

Virtual Gate 1; January 17, 2008. Gatekeepers [D. Manning (ER), A. Edman (WR), D. Carpenter (AR), D. Page (OHD), C. Diaz (OS), R. Billingsley (SR), M. Hudson (CR) M. Paese (OPS), D. Jones (OST)]

Disposition: ApproveVote break down: approve - ER,CR,WR, SR, OPS, OS, OST, OHDconditionally approve AR...ensure the scope of the project is clear. Is the intent to develop a COOP for RFCs or not. If so concerned this is not the right venue. SON and PP should clearly state the intention of the project.CR suggested the capability used at eht NCRFC and MBRFC should be looked at as a possible solution in the future stages.

OSIP 07-056 INTEGRATED WORK TEAM (IWT)

Organization Identify Lead Role

OCWWS/HSD Randy Rieman IWT Lead

Southern Region Eric Jones, Senior Forecaster, Lower-Mississippi RFC Team Member

OHD Jon Roe, Hydrologic Software Engineering Branch Team Member

Central Region John Halquist, Development Operations Hydrologist (DOH), North Central RFC

Team Member

Western Region Harold Opitz, Hydrologist in Charge (HIC) North-West RFC Team Member

Alaska Region Dave Streubel, Senior Hydrologist, Alaska-Pacific RFCRobin Radlein Supervisory Hydrologist

Team MemberTeam Member

Eastern Region Joe Heim, Senior Forecaster, Ohio RFC Team Member

OCWWS Leroy Spayd  Management Oversight

OCWWS/HSD Jeff Zimmerman OCWWS/HSD Lead

OOS/MLAD Albert Mongeon Team Advisor

OCIO Brian Doerk Technical Advisor

OS&T Jim Lane or designee Technical Lead

OSIP Analyst Chris Holte (OHD) Project Support

RELATIONSHIP OF CHPS AND RFC BACKUP

FEWS design offers local high availability system as well as on/off site backup capability

Experience with UK & European systems

Flexible system allows working within a budget

Synchronization relates to IHFS & OFS “type” data

At first glance…bandwidth appears manageable

CHPS AND RFC BACKUP --- See CHPS WIKI Page ---

CHPS AND RFC BACKUP - Preferred Configuration

CHPS AND RFC BACKUP - Flexibility

FCST Shell& MasterControllerOn OnePlatform

CHPS AND RFC BACKUP

Standby atOther RFC

CHPS AND RFC BACKUP – Fully Synchronized Operator Client

RELATIONSHIP OF AWIPS-II AND RFC BACKUP

Concept of Operationsand

Operational Requirements

AWIPS Thin ClientOSIP Number: 08012

July 21, 2008

Steve Schotz - NWS/OST/PPD/SPB - Team Lead Ronla Henry - NWS/OST/SEC/DB Bill Ward - NWS/PR/ES&SD Duane Carpenter - NWS/AR/ESSD Heath Hockenberry - NWS/OCWWS/MSD/FPWSB Cyndie Abelman - NWS/OCWWS/MSD/AWSB Scott Jacobs - NWS/NCEP/NCO/SIB Richard Jesuroga - OAR/GSD Sher Schranz - OAR/GSD Eric Howieson - NWS/SR/SOD/SIB Mark Mollner - NWS/WR/SSD Josh Watson - NWS/ER/SSD Michael Graf - NWS/OCWWS/MSD/AWSB Gregory Noonan - NWS/CR/MSD

AWIPS-II THIN CLIENTThe Advance Weather Interactive Processing System-II (AWIPS-II) will provide a robust and flexible infrastructure for NWS forecast operations. Upon deployment, AWIPS-II will provide the functional equivalent of today's baseline software through AWIPS-I Operational Build (OB) 9. Currently, AWIPS-I does not include integrated enterprise solution to support the following missions: Center Weather Service Units (CWSUs) Weather Service Offices (WSOs) Incident Support Specialists (ISS) including Incident Meteorologists (IMET) NCEP Centers to partially support their Continuity of Operations (COOP) requirements and remote access requirementsThese program areas require remote access to AWIPS capabilities to support their mission requirements.The purpose of this AWIPS Thin Client project is to develop and deploy an integrated thin client solution that will satisfy the NWS enterprise requirements for remote access to AWIPS-II capabilities. The thin client capabilities must support the operational needs of the mission areas defined above. NWS has an existing thin client capability provided by FX-Net. However, FX-NET only partially addresses NWS AWIPS remote access requirements. In addition, FX-Net is built on the original AWIPS-I architecture. Without an integrated thin client capability, NWS would be forced to maintain and enhance the original AWIPS-I baseline or enhance FX-NET to interface with the AWIPS-II baseline. This would duplicate software O&M efforts.

The Thin Client project planning and development will be led by the NWS in partnership with the NOAA Earth System Research Laboratory, Global Systems Division (GSD) and Raytheon Technical Services (RTS), the AWIPS-II prime contractor. Once developed, the thin client will become part of the AWIPS-II baseline and supported by RTS, accordingly.

The Thin Client project is part of the second phase of the AWIPS Technology Infusion project (OSIP 04-005) that extends the AWIPS-II architecture to all levels of NWS operations.

4.3 NCEP ScenariosUser: All NCEP forecastersAction: Continuity of Operations Plan (COOP) ImplementationThe National Centers have requirements to maintain the level of product creation during a COOP event. The Centers would use the Thin Client during the transition period from the main site to the backup site. In some short-lived situations, the use of the Thin Client may be preferable to fully activating the backup site.

AWIPS-II THIN CLIENT

NCEP plans to use for backup (COOP)

Thin Client Schedule07/01/08

I.High-Level Schedule

Major Deliverable(s) - OSIP Stage Milestone

Deployment – Stage 5 3Q FY11

Development – Stage 4 FY10

Applied Research, Technical Requirements, Business Case Analysis – Stage 3 FY09

Concept of Operations and Operational Requirements Document (ConOps) – Stage 2 FY08

I.FY08 Proposed Stage 2 Schedule

AWIPS-II THIN CLIENTSCHEDULE – OSIP 08-012

OSIP Deliverable Date

Gate 2 Disposition 9/30/08

Gate 2 Team Review 9/19/08

OST Gate 2 Internal Review 9/12/08

Final Draft ConOps to OSIP Site 9/5/08

IWT Draft ConOps Comments Due 8/22/08

Second Draft ConOps Document including Requirements Section 8/07/08

Telecon to Brain Storm Requirements (if needed) 7/29/08

Telecon to Review Consolidated Sections 1-7 and Brain Storm Requirements 7/22/08

First Draft Sections 1-7 (Sans requirements) 7/18/08

RFCs NeedTo ActNow !

AWIPS-II THIN CLIENTTECHNOLOGY QUESTIONS

Thin clientFrom Wikipedia, the free encyclopedia

A thin client (sometimes also called a lean or slim client) is a client computer or client software inclient-server architecture networks which depends primarily on the central server for processing activities, and mainly focuses on conveying input and output between the user and the remote server.

In contrast, a thick or fat client does as much processing as possible and passes only data for communications and storage to the server.

Many thin client devices run only web browsers or remote desktop software, meaning that all significant processing occurs on the server. However, recent devices marketed as thin clients can run complete operating systems such as Debian GNU/Linux, qualifying them as diskless nodes or hybrid clients.As a consequence, the term "thin client", in terms of hardware, has come to encompass any device marketed as, or used as, a thin client in the original definition – even if its actual capabilities are much greater. The term is also sometimes used in an even broader sense which includes diskless nodes. [1]

RFC BACKUP IN THE CHPS / AWIPS-II ENVIRONMENT

?

SOME OPTIONS ARE…

WHERE DO WE GO FROM HERE?

A) Sort out bureaucracy (teams / projects)

B) Re-Start National RFC Backup Team (liaison w/CAT & Thin Client Teams)

1) Same team as previously (National RFC Bkup)2) Same team as OSIP IWT 07-056 (RFC Bkup)3) Add new team member(s) from CAT RFC(s)4) Form new team

C) CAT becomes responsible for RFC Backup planning (liaison w/Thin Client Team & RFCs/Regions)

D) Add an RFC Rep to Thin Client Team (liaison w/CAT & RFCs/Regions)

E) Other ideas

---END---